Modernizing Passenger Information Displays for a Regional Transit Organization

Overview

A regional public transportation organization responsible for delivering transit services across a large metropolitan area was working to modernize the technology supporting passenger information displays throughout its system.

The organization’s existing display environment relied on legacy architecture and processes that had become increasingly difficult to maintain. As part of a broader technology modernization roadmap, the transit organization wanted to establish a more flexible approach for delivering both static and real-time information to passengers while creating an architecture that could be more easily maintained and expanded over time.

Oakwood Systems Group was engaged to help design and implement a modern passenger display solution built around BrightSign devices, web-based content, APIs, and existing transit data sources. Rather than approaching the effort as a simple hardware replacement, Oakwood worked with the organization to create a repeatable application and integration architecture that could serve as a foundation for future display modernization across the transit system.

Business Challenge

Passenger information displays sit at the intersection of several different technologies. Physical display hardware must remain reliable in the field, while the applications behind those displays need access to accurate information from operational systems and must be able to present that information consistently to passengers.

The organization’s existing ARCH display environment had accumulated legacy behaviors and operational dependencies that made modernization more complex than simply replacing screens.

The transit organization needed to address several interconnected challenges.

Existing display functionality had to be preserved while the underlying architecture was modernized. Some displays required relatively static information, while others depended on real-time operational data. The new environment therefore needed to support multiple content models without creating separate, difficult-to-manage solutions for each use case.

The organization also needed to continue using information already available through its Galaxy platform and other internally developed data sources. That created an integration challenge: information from existing transit systems needed to be transformed and exposed in a way that modern display applications and devices could reliably consume.

Hardware was another consideration. The organization planned to transition to BrightSign devices, requiring the application architecture to account for device configuration, network connectivity, content rendering, remote management, page refresh behavior, and error handling.

Finally, the transit agency did not want to solve only the immediate display requirement. The project needed to establish a technical pattern that could be repeated as additional displays and locations were modernized.

Solution

Oakwood approached the initiative as both an application modernization and systems integration project.

The engagement began by assessing the existing display environment, target locations, infrastructure readiness, content requirements, and available data feeds. Oakwood worked with the organization’s technical teams to identify which information could be reused from Galaxy and other custom transit systems and to determine the requirements for both static and real-time passenger displays.

From that discovery work, Oakwood designed a new web-based display architecture capable of supporting content rendered through BrightSign devices.

A key component of the solution was the development of a sign-facing API architecture. Rather than tightly coupling displays directly to underlying operational systems, API endpoints could provide a defined interface between source systems and the passenger-facing application layer. Oakwood designed the required data transformations for operational information such as transit delay and ticketing data and mapped existing data-entry interfaces to the appropriate integration points.

The display application architecture was designed to support both static and dynamically generated pages. Oakwood defined how content would be rendered, how pages would refresh automatically, how content rotation would operate, and how the application should respond when errors or unavailable data were encountered.

Oakwood then developed the initial display experiences, including static display pages and an API-driven display capable of presenting real-time information. The team implemented the supporting API endpoints and data integrations and configured BrightSign LS425 devices according to the new architectural standards.

Device management was incorporated into the design as well. Configuration profiles were established using the BrightSign management ecosystem, providing the transit organization with a more consistent approach to provisioning and operating the devices.

Testing extended beyond the individual web pages. Oakwood validated the APIs, display applications, data feeds, device behavior, content accuracy, refresh logic, and the overall end-to-end experience before pilot deployment.

The initial implementation included two static display scenarios and one dynamic display scenario, allowing the transit organization to validate the architecture across different passenger information requirements before applying the model more broadly.

Once the pilot environment was ready, Oakwood supported production deployment, device configuration, integration validation, and end-to-end testing. The engagement also included operational training, technical documentation, deployment guidance, configuration instructions, and knowledge transfer so the organization’s internal teams could support the environment following implementation.

Outcome

The project provided the transit organization with more than a replacement for its aging passenger displays. It established a modern application and integration foundation for how passenger-facing information can be delivered throughout the transit system.

By separating the display experience from underlying operational systems through web applications and APIs, the architecture provides a more maintainable approach for connecting passenger displays to existing transit data. Static and real-time information can be supported within a common architecture rather than through isolated display solutions.

The use of standardized BrightSign configurations, web-based content, defined APIs, documented data transformations, and repeatable deployment procedures also creates a clearer operational model for managing the environment.

Just as importantly, the pilot was designed as a repeatable modernization pattern. The organization can use the architecture, application components, device standards, testing approach, and deployment guidance established during the engagement as a starting point for expanding display modernization to additional locations and use cases.

For a public transportation organization where passenger information depends on the reliable interaction of hardware, applications, APIs, networks, and operational data, the engagement created a more flexible technical foundation for continuing that modernization over time.