ETA Blog

Every transit agency knows the drill. It’s 5:45 AM. Pull-out starts in fifteen minutes. A dispatcher is on the radio asking where Bus 412 is parked. A utility worker is walking the lot with a flashlight. Maintenance thinks it’s in the back row. Nobody’s sure.

For many transit agencies, onboard screens are a standard part of the rider experience. From next-stop information, route maps, and the occasional service alert, they display the info that reminds riders they are being taken care of. As someone relatively new to the transit technology space, I believe these screens have the potential to do much more as our tech continues to evolve. When paired with the right technology foundation, onboard infotainment can become a powerful operational and communication tool— one that improves service delivery, reduces operator workload, and creates measurable value for agencies.

Transit operations rarely go exactly as planned. Mechanical failures, farebox issues, vehicle accidents, or even a minor passenger injury can disrupt service and create stress for your entire operations team. That’s why ETA built a dedicated Transit Incident Management module inside our SPOT CAD/AVL platform.

Transit operations depend on people, from dispatchers and operators to supervisors and administrators. But when turnover hits, even the most experienced agency can struggle to keep service running smoothly. Without an easy-to-use CAD/AVL system, service disruptions, delayed responses, and training gaps become the norm. That’s why ETA designed SPOT, a browser-based platform built to keep service on track, no matter who’s at the controls. 

Universities face unique pressures: student and faculty ridership satisfaction, limited budgets, and the need for accurate data to secure funding. Outdated systems, consumer-grade tablets, and unreliable reporting only make things worse. 

Transit agencies aren’t just looking for new software—they’re looking for stability, transparency, and a partner that understands the realities of running a public transportation system. Too often, legacy CAD/AVL vendors sell a product and disappear until it’s time for renewal. Agencies are left dealing with downtime, unreliable hardware, and limited visibility into what’s really happening on the street.

Computer-Aided Dispatch Automatic Vehicle Location (CAD/AVL) is the backbone of modern transit management. The solution provides the tools to deliver safer, more reliable, and more efficient service. It powers digital tools to assign and manage vehicles, replacing traditional radio-based dispatch with a data-driven future-facing solution.

As American cities race toward cleaner, greener transportation, public transit agencies are at the forefront of adopting zero-emission buses. The two leading technologies-battery-electric (EV) and hydrogen fuel cell buses-each offer unique benefits and challenges. Drawing on robust data from the U.S. Department of Energy, agency case studies, and international trends, this post explores how agencies are charting the future of zero-emission transit.

In the past, deploying a new Computer-Aided Dispatch/Automatic Vehicle Location (CAD/AVL) system could take many months or even years. Today, however, modern technologies and advanced implementation techniques have dramatically shortened deployment times, allowing for faster and more efficient system installations.

In the world of public transit, understanding industry language is critical. Whether you’re evaluating new technology, reading procurement documents, or coordinating with vendors, transit acronyms and technical terms are everywhere. That’s why we built the ETA Glossary—a helpful resource to support transit professionals like you to quickly decode industry jargon.

Tally was inspired by my experience as a transit planner at LeeTran in Fort Myers, Florida. A year in as a transit planner, I was tasked with overseeing the average passenger trip length surveys for the fiscal year 2016-2017. At that time, LeeTran’s Automatic Passenger Counters (APCs) were not certified for National Transit Database (NTD) reporting, which forced us to use manual methods for collecting data on boardings and alightings. This labor-intensive process involved generating random trip selections, calculating distances between stops, and manually entering data into spreadsheets for analysis.

Accurate data collection is critical for transit agencies, especially when reporting to the National Transit Database (NTD). One essential measure is the Average Passenger Trip Length (APTL), which helps agencies calculate the distance passengers travel on average for each unlinked trip. Reporting APTL is a key part of ensuring compliance and maximizing funding from the Federal Transit Administration (FTA).

Customer references can make or break a transit agency’s choice for a Computer-Aided Dispatch (CAD) and Automatic Vehicle Location (AVL) system. These complex systems influence everything from service efficiency to rider satisfaction. Sifting through stacks of Request for Proposal (RFP) documents can be daunting, and agencies often think a handful of references will suffice. This blog post reveals why it’s crucial for transit agencies to request all of the vendors’ references, not just the standard three.

As the public transit industry continues to evolve, so do the regulatory requirements designed to ensure that transit agencies provide accurate and reliable data. One such development is the Federal Transit Administration’s (FTA) mandate for Automated Passenger Counters (APCs) certification by report year 2025. This change is poised to have a significant impact on how transit agencies manage and report ridership data. Let’s explore what this requirement entails, why it’s important, and how transit agencies can prepare for it.

Healthy public transportation services rely on sound data collection to secure the maximum funding from the federal government. Automatic Passenger Counter (APC) certification and Average Passenger Trip Length (APTL) survey are two distinct, yet related, processes that agencies employ to ensure they are accurately reporting the unlinked passenger trips (UPT) and passenger miles traveled (PMT) to the federal government.

Public transportation agencies face a constant challenge: optimizing service provision to meet the evolving needs of ridership. Traditionally, planning decisions relied on estimates and historical trends. However, the emergence of Automated Passenger Counting (APC) technology has ushered in a new era of data-driven decision making.

As technology continues its rapid advancement, the future of GTFS development is marked by a commitment to addressing real-world challenges and embracing emerging innovations. Recent contributions and pull requests to the GTFS repository demonstrate an ongoing effort to refine and enhance the specification.

Transit ITS Data Exchange Specification (TIDES) is a remarkable GTFS extension that delves into the realm of historical transit operation data. This repository provides data schemas and tools to support the access, management, and improvement of historical transit operations data, including vehicle operations, passenger activity, fare collection, and other similar data. TIDES bridges the gap between the past and present, allowing transit agencies to store and exchange historical data in a structured and standardized format. This opens a world of possibilities for transit providers, researchers, and developers.

Transit operators require their scheduling and operational systems to seamlessly work together. This synergy is most effectively attained through the adoption of open standards. Although GTFS has proven highly successful as an open standard, its primary purpose is to disseminate information to transit passengers, which means it lacks vital elements essential for transit providers.

GTFS has a rich history that reflects the evolution of public transportation data sharing. It emerged as a response to the challenges posed by fragmented and proprietary data formats, aiming to create a standardized way for transit agencies to share their information with developers and users.

The world of public transportation is undergoing a transformation, and at the heart of this evolution lie s the General Transit Feed Specification, or GTFS. As we kick off this multi-part blog series, we’ll embark on a journey to explore the depths of GTFS, uncover its significance, and reveal how it’s reshaping the landscape of public transit.

In the realm of mass transit technology, it is a rare occurrence to encounter a potential customer who enthusiastically praises their current CAD/AVL (Computer-Aided Dispatch/Automatic Vehicle Location) vendor. To put it simply, transit operators are often dissatisfied with their CAD/AVL vendor. According to our annual surveys of transit agencies, more than two-thirds express their discontent.

Introduction All-in-one tablets are unreliable and unsuitable for public transit applications. Instead, transit agencies must consider investing in transit-grade computers to record and display mission-critical information. Functioning onboard digital devices are essential to: improve operating efficiencies. automate NTD data collection. and enhance the rider experience. Though consumer-grade tablets and all-in-one Mobile Data Terminals (MDTs) with built-in touchscreen displays have become popular choices for transit agencies, these devices are not durable enough for harsh transit environments. In fact, 8 out of 10 transit agencies interviewed in 2023 have cited unreliable hardware as their primary challenge. Malfunctioning hardware is unacceptable for modern transit systems. In this blog, we will explore the reasons why tablets do not work for transit applications and discuss the advantages of using transit-grade computers with separate touchscreen MDTs. Consumer-grade tablets and all-in-one computers are designed for everyday use, but they fall short in the demanding conditions of transit environments. There are a few key reasons for this: Unreliable: Consumer-grade devices are not built to withstand the continuous vibrations, extreme temperatures, and harsh conditions common in public transportation systems. Over time, these factors lead to system failures and downtime. Consequently, agencies grow extremely frustrated with missed onboard announcements, loss of APC data, inaccurate NTD reporting data, and irritated riders due to incorrect bus arrival predictions. Unprotected: Transit agencies need to ensure the security of their systems and data. All-in-one solutions that combine processing and the touchscreen display are installed in exposed locations since the bus operator needs to interact with the system. This placement is more susceptible to theft and tampering, causing decreased system reliability and increased service disruptions. Upkeep: When these all-in-one devices fail during revenue service, it is inconvenient, time-consuming, and costly for transit agencies to manage. In this era of staffing shortages, transit agencies cannot afford to spend their time troubleshooting malfunctioning equipment as essential as MDTs. The Benefits of transit-grade computers with separate touch screen devices To address these challenges, transit agencies should consider using transit-grade computers with separate MDTs that do not have any processing responsibilities or complex operating systems. This design offers several advantages: Durability: Transit-grade computers are specifically designed to withstand the harsh conditions of transit environments. They are built with dependable connectors and housed in protective enclosures, ensuring reliability and longevity. Simple, functionally limited MDTs provide the bus operator with an intuitive driver interface and touch screen to interact with the system but do not impact bus operation or data collection. Security: By separating the touch screen display from the computer, a “dumb” terminal eliminates the risk of system failure or theft affecting the entire system. If the touch screen is damaged or stolen, the system can continue to operate without disruption. Simplified Maintenance: With a “dumb” terminal, updates and maintenance are managed centrally, reducing the burden on transit agencies and ensuring consistent performance across all devices. Cost-effectiveness: While the initial investment in transit-grade computers and touch screen MDTs may be higher than consumer-grade devices, the long-term benefits of reduced maintenance, increased reliability, and improved security make them a more cost-effective solution. Conclusion As transit agencies continue to embrace technology to enhance their operations, it is crucial to select devices that can withstand the harsh environments they will encounter. Consumer-grade tablets and all-in-one computers may seem like an appealing choice, but they are ultimately unsuitable for the demands of public transportation systems. Eventually, the bargain all-in-one solution will cost the transit agency unexpected time and money. By investing in transit-grade computers and touch screen MDTs, transit agencies can ensure the reliability, security, and longevity of their systems, ultimately providing a better experience for both operators and passengers.

Tools to help your RFP to set realistic expectations and deliver a focused review. Over our history, ETA has submitted hundreds of proposals for mass transit technology RFPs. We’ve won some, we’ve lost some, and we’ve seen RFPs pulled without warning. Win, lose, or draw our practice is to reach out to transit agencies and ask for feedback about the RFP—our proposal, where we excelled, where we came up short, and what struggles the agency had during the process. That’s the nature of our industry. This last point serves as the subject for this article; what are the common challenges for proposal evaluation? Our 2018 transit agency survey discovered that comparing offerings was the “biggest source of stress” for those on proposal decision committees, followed by “determining value versus price” and “determining the importance of features.” These are all valid concerns—but easily fixed. The key to solving these issues starts with preparing the RFP itself. The same 2018 survey revealed that “preparation,” “creating technical requirements,” and “determining desired outcomes” were the top three headache-inducing tasks. For the most part, an RFP includes the following components: Cover letter or statement of interest Vendor information Proposed solution Strategy for implementation Warranty & support information Cost proposal Required forms Each section should ultimately contribute to the decision-making process. It’s not uncommon for an evaluation structure included in the RFP which looks something like this: Technical response: 20 points Price: 40 points Vendor qualifications: 20 points Organization of the proposal: 10 points Situational understanding: 10 points And that’s about it in terms of the breakdown and weighting of the proposal response. That’s all a decision committee relies on to score and rank their evaluation. The highest score wins, and to the victor goes the spoils. But what if the evaluation criteria are wrong? What if it’s weighted incorrectly? Why does price weigh more than the solution itself (40% of transit agencies use it as their primary decision factor) than the vendor’s track record (vendor experience is the primary factor for just 11% of transit agencies)? What mechanisms exist in your RFP for establishing value versus performance? Our 2019 survey revealed long-term performance (70.2%) must be part of the evaluation process. That certainly isn’t listed in the standard scoring criteria? Just 52 percent of transit agencies say that the intelligent transit system (ITS) they purchased lived up to expectations in our 2020 agency poll. The picture I’m painting here is that the defined evaluation criteria baked into RFP documentation are inherently flawed; they are not up to the task and are highly subjective. Why do so many agencies value long-term performance, but fail to include any sort of measurement tool within their evaluation structure? Why are nearly half dissatisfied with their ITS purchase? How do we change the evaluation so that it most accurately reflects the needs of the transit agency and delivers on the expected outcomes? Here are a few ideas to consider before you put together your RFP: Pre-proposal polling: Conduct an anonymous internal poll of your transit agency. If possible, include everybody. Everybody is drivers, mechanics, dispatchers, planners, customer support, and administration. Use this effort to discover hidden truths about your agency and potential issues. Look for potential areas of resistance. Find pain points in potential solutions. Include the ability for respondents to rank their answers to gauge priority and level of severity. We recommend Survey Monkey, DooPoll, or even use Microsoft Sharepoint to create your surveys and leverage these tools automatically tally the results. Conduct pre-RFP pricing research: We know that transit agencies (ETA included) keep a tight lid on their pricing structure. It’s a competitive industry, after all, and any advantage helps. This practice doesn’t mean they won’t provide you with ballpark figures for planning purposes. Use this information to A) understand the approximate cost for each component (ITS, APC, AVA, etc.), and B) evaluate cost against the amount of funding you have available. If possible, ask for an estimated ‘per vehicle cost’ to help account for hardware, installation, and recurring fees. This effort will help you set expectations before writing your RFP. It is better to know what you’re asking for and compare it to the final pricing. With this baseline pricing in mind, it will help establish expectations for what your agency cannot afford. It will also help you derive a better sense of value from your proposals. It may even cause you to think about how much weight you place on pricing in the overall evaluation hierarchy. Create a compliance matrix with priority values We’ve written before about the importance of including a compliance matrix as part of your RFP documentation. This approach is an excellent way to get answers about what a proposed system can and cannot deliver. What’s missing from the matrix is a correlation between features and their importance to the final solution. A compliance matrix evens the value across all items but does nothing to tell your evaluation committee how to weigh capabilities against price and competition. Including this information will help the vendor present prioritized solutions based on needs. For example, if your internal survey efforts reveal the following priorities: Cloud-based ITS Route and schedule management NTP reporting Automatic passenger counters Onboard Wi-Fi Then assign value to those features within your matrix (a scale of 1–10, perhaps?). The vendors responding to your proposal will understand what you value the most. They can also construct their proposal to prioritize some aspects over others and deliver more up-front value. A well-constructed spreadsheet may even include auto-calculation to help score each entry in advance. An entry in a compliance matrix theoretically might look like this, where “yes” answers to compliance earn full marks, where “no” responses don’t earn points, and “extra cost” applies a multiplier value to adjust the score to account for additional charges: Provide this spreadsheet as part of the RFP and ask vendors to complete it as part of their submission. Lock and hide those columns, cells, and worksheets from the file submitted to vendors. Reveal those fields after submission to see how a vendor stacks up based on their responses. Include in your calculations weighted penalties for unsupported systems. Proposal creation Now that you are adequately armed with priority preferences by role (via the internal survey), you will have more insight into how each business unit will react to your final choice. Additionally, you’ll have a sense of what you can afford and what systems to prioritize (using the ITS Price Estimator) and, ultimately, a point-by-point accounting of each vendor’s capabilities (courtesy of the weighted compliance matrix). With this information, you can create an RFP document that better captures the actual deliverables for your project and have the background data needed to conduct a proper evaluation. With this data in hand, you can quickly rule out submissions below a capability threshold that you identify before evaluating. The goal, after all, is to narrow down proposals quickly. This approach: Greatly assists in the preparation of the RFP Clearly defines the technical requirements It helps determine an agreed-upon, prioritized outcome Reduces internal debate process The process helps build a right-sized transit spec while avoiding common pitfalls and finding that vendor who will be your forever friend. Now that you’re ready to construct your RFP, you can focus on telling a precise story—your story—so that any vendor responding has a full grasp of everything your system needs to accomplish. Construct your RFP to follow a logical progression and use clearly-defined topics and industry-standard terminology. Avoid copying and pasting from other sources, which typically results in a messy, contradictory document. We recommend a sequence that follows this general approach: Introduction (overview of your agency and history) Objectives (description of the challenges you seek to resolve) Resources (provide details about your agency, e.g., number of vehicles, makes and model, installed hardware, contact points, who has the final say, etc. Scope (define every deliverable, feature, and intended use—a good place to include your compliance matrix) Submission requirements (we recommend the following:) Statement of interest About the vendor Technical proposal Implementation plan Warranty & support Price proposal Required forms A significant consideration in this process is to allow enough time for vendors to create a thoughtful response to your solution. A good rule of thumb is six to 12 weeks from the RFP’s issue (or street) date. We also encourage you not to put page limits on the proposal. These highly technical and complex systems allow the vendor the necessary time to explain the system and benefits thoroughly. Yes, this can lead to some lengthy proposals. Consider the amount of money you are about to spend and the consequences of selecting poorly. In this decision, we highly stress that you should err on the side of information. Short summaries could cause a potential vendor to omit details that could otherwise influence your decision one way or another—all to satisfy an arbitrary page count. The added information serves as a handy reference to answer any questions you may have. Proposal evaluation You’ve now laid the groundwork for your evaluation with all your pre-proposal work. The tools and concepts presented above provide your transit agency with enough background information to help identify potential vendors to look for before the issuance of the RFP—and then compare their response against the pre-RFP evaluation. More importantly, you have established a list of criteria based on priority gathered by stakeholders at all levels of your organization. Take your time to evaluate the results. Ask questions. Conduct pilot programs. Take the necessary steps to ensure that you’re making a comprehensive decision in your agency, taxpayers, and riders’ best interest.

Communication, not technology, determines the satisfaction with transit systems It is a rarity in the mass transit technology market when we strike up a conversation with a potential customer, and they sing the praises of their current ITS vendor. Let me say it another way—transit operators aren’t happy with their tech partners. According to our annual transit agency surveys, more than two-thirds are less than thrilled. The oddest part of this conversation is just how seldom their complaints don’t center on the technology itself but rather the quality of the after-sales support they receive—or lack thereof. You read that right; their issues are seldom with the product. The technology, for the most part, works fine. It’s the relationship with their vendor that has them pursuing new systems. So, what have transit operators so chaffed with the quality of their support? In general, the complaints we here typically fall into one of the following three categories: Responsiveness Time to resolution Frequency of interaction It’s a shame when the reason for severing a relationship and introducing tumult to their operations, staff, and riders has nothing to do with the performance of the technology itself. After all, technology IS supposed to highlight the vendor/client relationship. Right? Right? What are the elements of a quality support experience? Just as the technology on vehicles is a science, so is the art of supporting the client and product. ITS systems are complicated, with many moving parts, including hardware, software, configuration, and data components. As rigorously tested as these systems are, one errant setting or faulty component can kick off an intensive troubleshooting effort to narrow down the cause. So how does one turn complexity into a recipe for success? —A spirit of partnership The first consideration we address is that both vendor and customer must dedicate themselves to the support process. It’s a two-way street, and the client needs to understand their role in the performance of their technology; this includes: Performing routine maintenance Providing detailed information for troubleshooting Being proactive and vocal about the issues they experience Without that level of client-side participation, the support process can drag out far longer than anticipated and lead to frustration on both sides. Similarly, the vendor must actively support their product, providing routine progress updates, delivering on all promises made, and keeping their customers well-educated and informed. When something goes wrong, customers want to know that their concern has been addressed. They don’t want to submit a support request or question only to have days or weeks pass before any sort of reply is received—or worse yet, no response at all. Both sides must understand that the ownership experience requires that they join at the hip, with each entity supporting the other in as diligent and thorough a manner as possible. —Training and education ITS systems, like ETA’s SPOT^™ platform, are complex. Though much of the intricacy takes place behind the scenes and is never exposed directly to the customer, the need for formalized and ritual training is essential. Too often, the only training that a customer receives is at the launch of a new transit system. As the system evolves or employees transition to new opportunities, a gap between what was and what is forms, and the relevancy of that initial instruction become less relevant. Vendors must bake supplemental education into every technology deployment, including identifying the right cadence for “booster” training or situational instruction for new hires or when new features join the ITS solution. An online, self-service database is helpful for self-guided learning, and a guided program must be part of the process to ensure effective instruction. An additional consideration is to ensure that the training focuses on the systems relevant to the individual role or group function. To train the entire staff of a transit operation is pure folly if one expects employees to be able to identify which information is critical to the performance of their jobs. It’s normal for people to become inattentive, tired, and distracted when they feel disconnected from the source material. Role-based instruction is hyper-focused, relevant education based on the needs of a specific subset of transit staffers, e.g., drivers, dispatchers, planners, etc. This education approach delivers only the materials needed for that group to perform their tasks effectively. The staff learns high-level concepts about how their role fits into the larger picture and takes a deep dive into the technology and features they will use in their day-to-day tasks. The result is a more relevant, more precise training that encourages participation and retention. —Responsive input and feedback The answer to this question is far more nuanced than one would think. Transit technology—especially software—are complicated. It can take time to research an issue before a solution presents itself. Responsiveness by the client can go a long way to speeding up the process, but it isn’t the only factor. From a client’s standpoint, they want the system to work as designed. The “what and how” of the situation is often of little concern. They are, after all, transportation professionals—not software engineers. A client wants their vendor to be a partner in not only the performance of the system but the success it delivers to their operation. From a vendor standpoint, a responsive customer takes an active interest in providing timely feedback to the original inquiry. Have they performed the troubleshooting steps? Is the information they provide to the original or follow-up communications detailed and complete—or is it highly generalized, like “the mobile data terminal doesn’t work.” Both sides want a timely answer to the questions asked in most cases. It’s an observation that hardly falls within the realm of rocket science, but one that seems to be a common tripping point and trigger for a great deal of angst between agency and supplier. This reality is often the source of a great deal of friction between customer and vendor, which makes responsiveness even more critical to communicating the status of the concern and setting realistic expectations for a resolution. —Frequency of interaction The human factor is an essential and often overlooked aspect of the client/customer relationship. Consider for a moment the procurement process. In the beginning, contact is frequent. Sales representatives are attentive and in constant contact while negotiating the sale. Once signed contracts exist, the communication escalates further as the implementation teams coordinate with agency teams to finalize system design, schedule implementation, and conduct training. Once the vendor turns over the golden keys to the new technology, the vendor turns their attention to the next opportunity, and the shock of silence settles in. The transit operator is left to use the system. Speaking from the vendor viewpoint, this is the natural evolution of procurement. From the customer standpoint, however, the abrupt cessation of activity following the completion of a project can leave agencies feeling adrift; a “you got my money, and now you’re leaving?” situation. It’s not uncommon for technology vendors to see “no news” as “good news” when past projects are concerned. A neglected customer risks becoming an unhappy client, so it is of little surprise that they pursue higher-quality relationships at the contract end. Keeping those relationships strong and proactive with customer communication long after that initial flurry of activity becomes vital. Closing thoughts Providing quality customer service isn’t some uncrackable mystery. It’s rooted in common sense. If you are a client unhappy with your vendor, it’s probably time to pick up that phone and let your vendor know. If you’re a supplier, you had better take that call—or better yet, run through your list of accounts and touch base with those customers you haven’t spoken to in a while. Run through the list of concerns. Clear the air. Compare expectations to performance and set goals for measurement. At some point, both sides were ecstatic about this joint project—and it’s possible to reclaim that excitement. Try again to find common ground where communication becomes the norm; not the exception that only happens when conflict drives the discussion. It changes the tone from “this isn’t working” to “how can we resolve this together.”

Don’t overlook the “employee factor” when adopting new technology. See if this sounds familiar. You and a select group of co-workers have spent time researching, interviewing, and demoing a new technology or process to be implemented at your company. You’re certain that you have been thorough in your efforts. The solution checks every box and satisfies every need. It’s expensive, but the ROI is worth it. You sign the paperwork, establish a schedule, and when the day comes to flip the switch, your staff greets the new system with a collective shrug. Undeterred, you’re confident that once your employees will see the benefits and welcome this change into their work lives. Only that doesn’t happen. Months into deployment, the new technology isn’t being used as intended. The system isn’t generating the expected benefits. The staff are actively developing workarounds, or worse yet, trying to get the new system to perform like the old system. Tempers are flaring. Upper management is demanding answers. Did you buy a lemon? Or did you forget to include your staff in the procurement process? Did you forget to build anticipation and educate how this new system would improve their job satisfaction, make their lives easier, or address lingering performance issues? According to our annual survey to transit agencies, 80 percent of transit operations experience resistance from their staff or customers when adopting new technology or practices. When polled further, about this resistance, transit agencies believed that the quality of the vendor-provided training materials (56%) played a factor in poor adoption, and the inclusion of cheat sheets and user guides (42%) and options for supplemental training (38%) would be helpful in changing employee perceptions. While a well-trained staff can be important in wringing the best performance out of new technology investments, it’s not the only variable. In truth, there are three critical areas of technology adoption that must be addressed: The requirements of the technology (which problems will it solve) Generating excitement among riders (get transit customers excited about the change) Generating excitement among employees Transit agencies excel in the first two areas. In fact, our customers routinely ask us for marketing materials and strategies to engage with their riders and let them know what’s coming. When we include internal marketing materials for their staff, it’s a common response to hear “hmmm, I didn’t think about marketing to our employees. What a great idea.” The assumption, as we see it, is that whatever change is decided upon by leadership is that it will be readily embraced by employees. After all, change is coming, and they have little-to-no say in the matter. If they want a job, they’ll use the tools provided. The assumption is that employees understand what doesn’t work well, so any initiative that solves those concerns will be embraced. Except that’s not reality, and truth be told, your staff has their own ideas on how to solve challenges—which by default creates obstacles and roadblocks that need to be overcome. In our view, pre-marketing the change to staff is every bit as important as the quality of training and resources. Why? Because pre-marketing helps build anticipation by extolling more intimate benefits to the staff. It includes them in the conversation. It extolls more intimate benefits, provides ways of seeking more information, and begins that emotional transition from what is to what will be. Change is intimidating. We can’t just plop a new system or service in the laps of our employees and expect that they will be excited about it and embrace it without question. Take steps to bring your staff along in the process. Provide updates, answer questions, listen to concerns and feedback. If they feel involved, they will be more likely to embrace this new solution willingly rather than begrudgingly. And when the staff is onboard, that’s when meaningful change can really take off.

One of the more popular feature requests we receive for our SPOT™ ITS platform is digital pre-and post-trip inspection, also known as driver vehicle inspection reports (DVIR). It certainly seems that transit operators are eager to transition from manual or paper processes to connected digital logging and report solutions. Historically trip inspection involves four things: A driver A clipboard A pre-printed paper form A pencil or pen It’s a wonderfully simple process: a driver walks around a vehicle, looking for signs of damage, maintenance concerns, or any number of issues mandated by transit management. He documents his findings and turns the form over to a supervisor for followup. There are concerns, of course. A driver, late to start his route, may not give the inspection process the time it requires (pencil-whipping) and will miss some important safety items. An administrative assistant may not notice that she transposed some numbers when she use the inspection report to create a work order for the maintenance team. The documents themselves are easily lost or subject to the perils of office life, like spilled coffee or misfiling. And let’s not get started with how poor handwriting can impact an inspection report. These are among the many issues that digital inspection aims to solve: Eliminate transcription errors Minimize “pencil whipped” inspections Improve the ability of the maintenance teams to manage repairs and engage in proactive maintenance Improve vehicle safety Eliminate the expense of printing/reprinting maintenance forms Automatic notifications to maintence or fleet supervisors of potential issues The move from manual processes to digital inspections isn’t a concern among transit operations. They welcome it and all the benefits it brings to their agency. The software for implementing these inspections exists and is transit-tested. Making the switch to digital Deciding to make the switch is the easy part, now comes the hard part—which DVIR technology to choose? And this can be tricky because due to the current limitations of transit technology, there are some nuanced approaches to solving the trip inspection question. On the surface, it would seem obvious that every inspection solution would involve a portable device that a driver or maintenance team member would use to log the inspection. In truth, when ETA began exploring the creation of a DVIR solution, that’s exactly where we started—with a removable mobile data terminal (MDT). We quickly found out that a removable MDT ran into connectivity issues. No matter how securely that MDT was mounted on the bus or shuttle, the act of removing and reseating the device wore down the pin connector and charging cables over time. In just a matter of months, the removable MDT option became unusable and could no longer be counted on to provide data to the ITS or charge reliably. What about Qi chargers you ask? We explored that as well and found very few transit-tested ruggedized wireless charging options—an example of where the technology hasn’t matured to the point where its ready for prime time mass transportation. We explored a mounted MDT solution as well. This approach solved the communication and power issues, however it introduced other drawbacks to the solution. Inspections took longer, accuracy suffered, it was impossible to take photos of areas of concern, and drivers became more likely to “pencil whip” through the process which negated any benefit as a solution for safety or maintenance issues. We also took a deep dive into Bluetooth™ technology to see if strategically places switches on the vehicle would present drivers with a simpler inspection tool—each button would represent an inspection item. If an item was okay, set the switch to “yes,” if there was an issue, select “no.” It was an interesting approach, but lacked the detail necessary for meaningful followup by maintenance teams. Limitations of accurate Bluetooth^™ communication over distance also proved a challenging obstacle to overcome. Our journey forced us to take a step back and consider the factors that would influence the choice of DVIR solutions—not from a place of technology, but of real-world considerations. Understanding what a driver or maintenance team needed was a more important driver of choice than conquering the limitations of technology. We identified the following factors that are critical to address before a trip inspection is implemented: Device security: Do they store the inspection device in the vehicle or secure them elsewhere? Can they afford to replace trip inspection devices if they are damaged or stolen? How long is the replacement cycle for damaged or stolen devices? Data management: How will they manage the data collected? Will this data import require additional software development? What is the criticality of this data to other areas of the operation? Are there costs associated with processing and storing data? How long is data stored/accessible? Driver safety: Is there room on the vehicle to install the device? Would installation block driver access to other vehicle systems? Will installation obscure driver view of the road, doors, exits, etc.? Technology adoption: Is the solution easy to use? Does the solution present a significant learning curve for drivers, dispatchers, and maintenance teams? What will be the level of resistance toward the adoption of this feature? How might the system be exploited or subverted? Have all parties been consulted and included in the decision-making process? Our recommended solution Our path to DVIR discovery let us to a path that we hadn’t originally considered—the use of a rugged smartphone to handle inspections. The solution checks all the boxes: Puts an affordable portable device in the hands of drivers to log potential issues Protects data collection integrity by keeping MDTs secure and locked down Requires very little real estate within the driver cockpit to install a charging dock (or can reside in a driver’s pocket) Delivers hours of battery life Provides a secure platform from which to operate and allows the same device to be used elsewhere—such as VoIP It’s a simple, yet elegant solution that simplifies trip inspection and improves the safety and reliability of a transit fleet. It’s a solution that we our are proud to introduce to the market. If you’d like to learn more, please visit etatransit.com/pre-trip-inspection or call a member of our sales team at (800) 382-0917. Closing thoughts A pre-trip inspection solution can provide numerous advantages to transit operation and contribute to the overall safety and reliability of the fleet. Sometimes there is a gap between what software can do and the availability of hardware to support it. Nowhere is this more evident than the current state of driver vehicle inspection technology. Still, a transit agency may have to weigh the adoption of a DVIR solution against potential shortcomings that may not lead to a “right-fit” adoption. Our advice is to speak with your ITS provider and solicit outside vendors to take full stock of your available options before making that transition from paper to digital inspection. Once you find that ideal blend of technology and features, you’ll be amazed at how much your fleet will benefit from cost savings, reliability, and performance.

Maximize the efficiency of your automatic passenger counters for NTD certification-worthy results. By Matt Schroeder Director of Marketing, ETAs I am going to dispel a myth for your right off the bat. The FTA (Federal Transit Association) does not provide certifications for APC hardware. Never have, never will. Anyone that tells you that their brand of APCs has been certified is straight-up lying. It’s amazing to us just how many transit operators are under the misconception that there are specific brands of APC hardware blessed with a governmental seal of approval. APC suppliers may provide you with a process for certifying the counts generated by your automatic passenger counters, but that’s it. Certification of counts is a whole different beast. In general, the certification process entails two things: An APC benchmarking plan for the first year An APC maintenance plan for every three years You can read all about it here: NTD Policy Reporting Manual What defines a benchmarking plan? Benchmarking requires validation for unlinked passenger trips (UPT), and passenger miles traveled (PMT) data against a manual sample to prove the APC system’s accuracy. The process for reconciling this data includes: For agencies with fewer than 30 vehicles, the sample size must include at least 15 trips on APC-equipped vehicles. For agencies with 30 or more vehicles, the criteria changes to the larger of 15 trips or half the number of APC-equipped vehicles (up to 50 trips). In both instances, the trips do not need to be randomly selected and may spread over a year. We recommend that these samples include times of heavy ridership and the inclusion of at least one trip per vehicle type and APC model. A description of the agency’s APC systems and sampling procedures is also required. Should a trip be excluded or rejected from a provided sample, an explanation is required. Also to be included is documentation that accounts for the percentage of trips made that do not have valid APC data due to equipment malfunction, data corruption, failed verification checks, or any other reason. For manual counts that use data collection staff or onboard cameras, the FTA strongly recommends a data collector at each door during heavily loaded trips. It is appropriate to process APC data to correct for anomalies, just as it is reasonable to adjust for reporter data during the collection process. The goal is to compare manual and automatic counts to demonstrate equivalency or that any differences are justifiable. PMT calculations should utilize the same set of distances for all analyses. Should any differences exist (i.e., interstop), an explanation must be included with the provided data. Acceptable deviations in data are less than five percent for: Difference between manual vs. APC UPT counts Difference between manual vs. APC PMT counts If a transit agency uses APCs for both directly operated and purchased transportation services, a requirement for separate samples of each type of service exists. Verifying counts Automatic counting hardware is exceptionally precise, with most manufacturers boasting 95 to 98 percent accuracy. Despite this precision, errors can creep into the system, which is why the FTA does not certify the hardware itself. Simply put, nothing is going to deliver optimal accuracy out of the box. Configuration, tweaking, and adjustments are typical to account for environmental variables unique to every transit operation. The process of verifying your counts is quite simple. Option 1: Manual counts Your agency can have an employee ride every route and take manual counts to compare to those generated by the APC. This process quite literally involves a person with a clipboard taking note of who boards and alights at every stop, the pencil and paper method. Option 2:Digital counts If a vehicle has a mobile data terminal (MDT), the driver can use a built-in digital passenger counter to log passenger boardings and alightings. The data automatically uploads to the intelligent transit system for future review. Of the two, we recommend the MDT-based approach. It’s less prone to data entry errors, and the information is easily reviewable in any reporting or analytics software for side-by-side comparison against the APC-generated counts. Adjusting counts Once the necessary amount of historical count data is collected, you will work with your transit technology provider to develop a reporting algorithm that accounts for recurring variations in the information. This final step refines the configuration of your APC and subsequent analysis and allows for the consistent benchmarking required by the FTA for certification. It also serves as a diagnostic resource to evaluate the consistent performance of your hardware; a sharp increase or drop-off in counts could be an indication of a hardware error or mounting issue. Final words Adding automatic passenger counters is a great way to reduce manual processes and gather the critical data you need to understand passenger travel behavior. The process is not straightforward and requires a few essential steps to ensure that the counts you collect provide your agency with the reliable counts you need to make informed decisions and submit accurate reports to the National Transportation Database (NTD). It is essential to understand that the hardware is not certified by the FTA but rather the methodology for collecting, analyzing, and reporting the data that receive certification. This process takes time, but when working with a reliable transit technology provider, your new APCs will provide trustworthy information you can use to make informed operational decisions for years to come.

By Matt SchroederDirector of Marketing, ETAs

New sign technology is poised to remake transit stop communication

What’s also not a secret is that Millennials (and their younger Gen Z counterparts) are among the fastest-growing adopters of transit and the first generation not to view vehicle ownership as a status symbol. However, like car ownership is driven by the latest bells and whistles, public transit will be pushed by these younger generations who are used to having the latest technology and are comfortable with always being ‘connected’ to whatever they need, whenever they want it.

The RFP creation and evaluation process can be troublesome, but if a logical approach and sound strategies inform the type of responses you seek, then it need not be such a cumbersome effort.

Versatile payment collection capabilities simplify payment and meets the preference of the rider. While regular transit riders will likely stick to a single form of payment for their transit fares, periodic or impromptu riders will require flexibility in their fare transactions.

The e-paper solution has emerged in the transit space as a happy medium between the old-school LED signs and the colorful, yet expensive HD LCD screens.

By Matt SchroederDirector of Marketing, ETAs

Driver monitoring technologies exist to identify ineffective behaviors that could impact overall performance, increase rider satisfaction, and contribute to unsafe vehicle operation. Among the more popular solutions on the market include: speed tracking, excessive idle monitoring, schedule performance tracking, and collision avoidance.