Innovation Studio - Frequently asked questions

2024 Problem Statement Questions

In the case of similar or duplicate questions only one has been uploaded

General

Regarding the evaluation of the pilot's success, what specific key performance indicators (KPIs) will CTA use? Will these include metrics related to rider satisfaction? How will feedback from riders and operators be collected and factored into the evaluation?

Innovators should identify goals and KPIs for the pilot during the presentation to the panel of stakeholders and subject matter experts at CTA (Phase 2 Evalutation). These will depend on the nature of the specific innovation. However, during the scope and planning period, KPIs will be finalized with CTA. For customer facing projects, our survey team can assist with collecting rider feedback about the pilot.

For the pilot phase, is there a structured timeline for milestones and feedback sessions between CTA and pilot participants? How flexible is CTA in adapting the pilot's scope based on interim findings or unexpected challenges?  

The timeline will be outlined during the scope and planning period between CTA and the innovator. We will bake in milestone check-ins and scope renegotiation periods to allow for in-flight adjustments due to new findings. The pilot however should not exceed a year in total duration, so some degree of contingency should be accounted for.

What level of logistical and technical support can pilot participants expect from CTA during the setup, implementation, and operation phases of the pilot, including access to physical sites, technical resources, and data?

These pilots are envisioned to be a collaboration between CTA and the innovator. We will work to support innovator needs throughout the pilot. We have a full-time project manager dedicated to this support and will acquire technical resources as needed and available. Data related to the pilot work will be provided upon request for selected innovators.

How does CTA envision the collaborative process with pilot participants in terms of decision-making, problem-solving, and iterating on the solution based on real-world performance and user feedback? Are there designated points of contact within CTA who will be directly involved in supporting the pilot projects?   

During the scope and planning period, regular check-ins between CTA and the innovator will be scheduled to ensure continued alignment between the pilot and CTA goals and to discuss any adjustments needed for an in-flight pilot. There will be a designated project manager for the duration of the pilot and a committee of subject matter experts acting as stakeholders for the duration of the pilot.

In terms of system integration, what are the security protocols and data privacy standards that our solutions need to adhere to, ensuring the protection of transit users' information and system integrity?

Innovators should follow guidelines for the NIST 800-53 framework as it relates to cybersecurity standards. Additionally, CTA will require some visibility into any hardware installed on our system including, but not limited to the ability to perform a security assessment. Depending on the specifics of the proposal more strict security requirements may apply.

Right-of-Way Intrusion Detection

What is the CTA's current state of sensors, dashboards and alerts (centralized Alert ingestion) for above ground, street level, and underground? Would we have access to existing cameras and track sensors to integrate into the solution?   

CTA does not have an existing system for automated detection of ROW intrusion. Our stations are equipped with cameras. We will work to provide access to necessary systems/hardware for the purposes of the pilot for selected innovators. However, we cannot guarantee our existing cameras will have necessary coverage for the purposes of automated ROW detection and should be viewed as an augment to the pilot and not the primary mechanism.

Would we have access to the current control center to pull identity/location of trains?

CTA will work with selected innovators to provide them necessary access to any data, tools, or services needed for the implementation of the pilot. Please refer to the Train Tracker API for information about train arrival estimates: https://www.transitchicago.com/developers/traintracker/

Please provide details of current state networking (wired/wireless) at stations.

CTA Stations are equipped with a local hardwired network as well as cellular service.  

What is the preferred routing method of cables to and from peripherals and edge units?

Preferred cable routing methods vary by station. Details will be outlined during the scope and planning phase after pilots have been selected and specific stations identified for the pilot.

What is the minimum coverage distance for sensors in the pilot for intrusion detection system (e.g., whole length of line v. within certain distance of platform)?  

Sensors should be able to detect intrusion at the station and a few meters beyond station level at either side. As this pilot seeks, in part, to detect instances of a human on the tracks, the coverage range should extend beyond the platform to where a human could reasonably fall. Tracks between stations are outside of the expected scope.

Do you prefer automated classification of detected objects in real time?

A proposed solution should have systems to avoid false positives. As an example, if the solution proposed uses cameras with object classification machine learning models it should know the difference between a human and a train, but automated classification is not required or favored if the solution can function without.  

Will the solution need to integrate with a specific system for CTA's Operations team/center or local staff to receive alerts?

We are open to a variety of solutions for alerting CTA staff locally and at the control center and are not currently depending on a specific integration.

Will CCTV cameras be available for our solution to utilize?

We will work to provide access to necessary systems/hardware for the purposes of the pilot for selected innovators. However, we cannot guarantee our existing cameras will have necessary coverage for the purposes of automated ROW detection and should be viewed as an augment to the pilot and not the primary mechanism.

What is meant by processing information on the edge? Where should the intelligent system reside?

Ideally processing will happen on the device itself for any machine learning based detection to reduce latency and increase performance during high congestion periods like rush hour. This is not a hard requirement if you think your solution can tolerate this congestion without edge processing.

What actions does CTA expect its Operations team and/or local staff to take upon receipt of an intrusion detection alert?  

CTA will alert train operators and local staff to intervene and remediate the situation prior to a train entering the station including but not limited to halting oncoming train cars, conducting a visual inspection, reaching out to emergency services, and removing the person or object from the tracks.

What is CTA expecting in terms of alert latency? In other words, how long between actual event and alert of event is acceptable?  

Since this is an issue of safety, we are expecting low latency solutions – on the order of seconds or less.

Will CTA allow an on-site survey to determine hardware installation requirements before Phase II application submission?  

CTA’s stations are publicly accessible. Unfortunately, we are unable to allow for in-depth on-site surveying ahead of Phase II presentations. On-site surveying at select stations can occur during the scoping phase of the project.

What is the power, networking, and location requirements for storing hardware such as edge devices, lidar, and cameras in the stations? Please provide information on sample locations.

Hardware devices installed on the CTA system must be compatible with a 25-amp or 12-amp outlet with ground. Noise generated by hardware should not exceed 60dBA (measured at 1 meter) during normal operation. Wiring materials and coding must meet the requirements of the National Electrical Code (NFPA 70). Access to network requires a hardwired internet connection or cellular connection. Additional requirements may arise during the scope period depending on the specifics of the technology/solution.

Bus Stop Asset Monitoring

Can you provide the inspection form checklist of bus stop assets?

When doing bus stop asset inspections, we look at the following pieces of information:

  • Position relative to intersection
  • Routes served at stop
  • Type of shelter at stop
  • Type of Traffic Control Device at intersection
  • Accessibility condition at stop
  • Reinforced on-street pad at stop
  • Tactile sign installation
  • Unique artwork on bus stop sign
  • How the bus stop sign is installed
  • Where the bus stop sign is installed

Accessibility condition options are as follows:

  • Full accessibility at bus stop
  • Grass parkway at bus stop
  • Uneven/narrow landing at bus stop

The recorded condition of the bus stop assets include:

  • Good condition
  • Damaged
  • Vandalized
  • Moved
  • Worn
  • Other

How is bus asset data maintained at CTA?

This data is currently stored in a relational database.

Will bus camera data be available for adapting our solution for the pilot? 

CTA will work with selected innovators to provide necessary access to any data, tools, or services needed for the implementation of the pilot. This includes video data or any train/test data sets needed for machine learning.

What is the retention policy of CCTV from the buses?

We do not have a formal retention policy and cannot guarantee equal coverage across buses. We will work to retain necessary data for testing pilots or augmenting machine learning models or other software solutions in preparation for the pilot based on innovator needs.

Bus Real-Time Arrival Information Signage Expansion

Could CTA provide more detailed technical specifications, including data exchange formats, communication protocols, and any specific hardware or software interfaces required for the real-time transit sign solutions? Are there existing digital infrastructure or platforms with which the new signs must be compatible?  

We have existing signage using URL based configuration, XML, JSON, and proprietary software. New signs should run an OS of windows 10 IoT or Linux (Ubuntu >=16.04 or similar) and should be able to integrate with 3rd party CMS software.

How does CTA envision the integration process with existing transit management systems, particularly regarding real-time data feeds for bus arrivals? Are there any specific challenges or limitations in the current system that we should be aware of when developing our proposal?

CTA currently uses a custom API for bus arrival predictions.  Information about our Bus Tracker and using bus arrival predictions can be found here: https://www.transitchicago.com/assets/1/6/cta_Bus_Tracker_API_Developer_Guide_and_Documentation_20160929.pdf 

Are the data feeds available via GTFS-RT for vehicle positions, trip updates, and service alerts?

We currently use a proprietary API for real time vehicle location – documentation for the Bus Tracker API can be found here: https://www.transitchicago.com/assets/1/6/cta_Bus_Tracker_API_Developer_Guide_and_Documentation_20160929.pdf.

For service alerts, please refer to the CTA alerts API documentation: https://www.transitchicago.com/assets/1/6/cta_Customer_Alerts_API_Developer_Guide_and_Documentation_20160929.pdf

For additional information about CTA APIs, please refer to our developer page: https://www.transitchicago.com/developers/

We are working on a project that will allow us to support GTFS-RT as well as our proprietary API in the future.

Developers info page: (https://www.transitchicago.com/developers/bustracker/) specifies a 10K per day transaction limit. This would limit us to an update of requesting once every 10 seconds. Would it be possible to increase the limit to around 30k-40k transactions per day if chosen for this project?

Yes, we can increase the transaction limit for the purposes of the pilot.

Can CTA provide more insight into the desired accessibility features for the real-time signs, such as the types of audio announcements, visual aids, or tactile features that would best serve passengers with disabilities? Are there specific standards or guidelines, such as ADA compliance, that these features must meet?

We are open to various accessibility solutions including audio announcements, wayfinding support, and tactile aids. For information about ADAAG standards as it relates to signage please refer to https://www.access-board.gov/ada/guides/chapter-7-signs/ 

How important is inclusivity in the context of the real-time transit sign expansion, particularly for communities with limited access to mobile technology or those who rely heavily on public transit for their daily commutes? Are there particular demographics or locations that CTA aims to prioritize in this pilot?

The selection of where to physically deploy pilots will be carefully considered and will be a joint decision between the innovator and the CTA. This selection will be finalized during the scope and planning period after pilot selections have been made. Since these decisions will happen after selection, pilots will not be graded based on metrics of inclusivity or equity with regard to suggested sign placement.

Regarding the design of accessible features, does CTA have preferences or requirements for user interface (UI) and user experience (UX) design principles that ensure ease of use and comprehension for all riders, including non-English speakers and individuals with cognitive disabilities?

Design considerations and user experience, including for non-English customers and customers with disabilities is important to CTA. CTA UI and brand standards can be found here: https://www.transitchicago.com/developers/branding/  

Could you clarify the anticipated number of bus stops to be included in the pilot program for testing the real-time sign solutions, and how were these locations selected? Does CTA aim to cover a diverse range of environments, such as high-traffic areas, neighborhoods with different socioeconomic profiles, and stops without current real-time information?

We plan to work with innovators on the exact number of bus stops to test. The exact number will depend on a combination of what the innovator is willing to provide for a test and requirements related to installation, monitoring, and support. Our hope is to have a small sample to test that would include a mix of high-traffic and diverse socio-economic profiles.  

Does CTA have specific goals or requirements related to the sustainability and environmental impact of the real-time transit sign solutions, such as energy efficiency, materials used, or lifecycle carbon footprint? How important is the environmental aspect in the evaluation of pilot proposals?

While the CTA prioritizes sustainability and reducing its environmental impact, the 2024 Innovation Studio problem statement evaluation criteria has not identified environmental impact as one of the metrics for which proposals will be evaluated. To learn more about our environmental initiatives please refer to https://www.transitchicago.com/environment/ 

Can CTA please confirm that proponents will have access to Clever Devices GTFS-RT (or equivalent RT feed) feed without restriction?

CTA will work with selected innovators to provide them necessary access to any data, tools, or services needed for the implementation of the pilot. This includes increasing the API transaction limit up from 10,000 transactions per day.

Can CTA please confirm that this is the data source they are willing proponents to use or if there is any improvement expected in the quality of the GTFS-RT and/or predictions provided?

Documentation related to CTA’s bus arrival APIs can be found at: https://www.transitchicago.com/developers/

Documentation for the Bus Tracker API can be found here: https://www.transitchicago.com/assets/1/6/cta_Bus_Tracker_API_Developer_Guide_and_Documentation_20160929.pdf.

Can CTA please let us know if the GTFS-RT Alert Service is currently handled in the Clever Devices GTFS-RT feed?

CTA currently uses a proprietary API for alerts. Documentation about our alerts can be found at https://www.transitchicago.com/developers/alerts/  

Would CTA be involved in the project if minor installation at stops was required to set the system up? The work required would be equivalent to the work needed when timetables at stops are replaced at seasonal change. Would CTA personnel be involved in these minor changes or do the proponent have to be involved?

We are prepared to support selected innovators throughout the pilot. This includes potentially installing new technology/devices on our system under the guidance of the innovator.

With regards to the low cost of the technology we would like to test, would CTA be interested in testing the technology on one or two routes instead of only a couple of stops?

The expectation is that the innovator will cover the cost of this pilot unless financial support is strictly necessary (which would require internal review and approval). We would be open to exploring testing new technology on an entire route so long as it does not create financial burden for the CTA with regard to labor, operational overhead, or material costs beyond what would be incurred with testing the technology at a more limited number of stops.