Traction motor, HVAC unit, AVL system?

If a transit agency runs its own motor shop for rebuilding traction motors, runs its own electronics shop for performing component-level repair of circuit boards, runs its own axle shop for rebuilding axles, why shouldn’t it be able to do the same for the software which is just as vital to everyday operation as axles and traction motors?

I recently came across a very interesting paper describing the successes of SEPTA’s Woodland Electronic Repair Shop. At SEPTA, the justification for in-house electronics repair is twofold: many components which come into the shop are not actually defective, and had they been sent to an outside shop for repair, time and money would have been wasted only for the outside shop to return the same “no trouble found” verdict, and, secondly, sending equipment to an outside shop is expensive—by SEPTA’s analysis, more than double the cost of operating an in-house electronics shop.

Transit agencies may not think of themselves as being technology-oriented, but the reality is that software systems are at the heart of so many things transit agencies do—from scheduling to passenger information to signals and communications. Agencies almost universally rely on vendor support for large software packages that perform a wide range of functions: scheduling, trip planning, real-time passenger information, and even safety-critical tasks in signalling and communications.

Yet in comparison to the nuts and bolts which keep the a transit system moving, most transit agencies have shockingly little control over their vital software. Being closed-source and proprietary, the agency is unable to develop its own bug fixes, patches, and new features, and may not even be able to export data in an open format. By controlling the availability of support and new features, the vendor dictates when the agency upgrades—and by using proprietary data formats and interfaces, the vendor all but guarantees that the agency will return to them instead of shopping around. This is the very same risk that SEPTA’s electronics shop seeks to mitigate:

At some point the vendor will no longer support their particular system and since you have always relied upon them for their parts you will have no choice but to go out for bid to get a new system or an alternately designed part to perform the same function.

When procuring new equipment, SEPTA demands access to schematics and test equipment, so that their repair shop can do its work. Without this access, the results are predictably poor. SEPTA found that costs for one class of parts had increased 94% over two years—an “astronomical” price increase at an agency used to inexpensive in-house repair. The explanation, from SEPTA’s engineering department, is depressing:

These are so expensive because SEPTA has no alternative but to purchase these parts from the OEM.

This is why our equipment specifications have a requirement that the Vendor provide SEPTA with all test equipment, documentation and training to allow us to repair the circuit boards in our electronic repair shop at Woodland. The CBTC project did not have a specification from Engineering, but rather was supplied for liquidated damages from the M4 program. It was understood from the beginning that SEPTA would not have the capability to repair the circuit boards.

The complexity and safety aspect of these boards prevents SEPTA from creating drawings and specifications that would allow an alternate supplier to produce these boards.

So, what is the parallel for a software project? Where an electronics shop has schematics, where a mechanical shop has blueprints, a software shop has source code and supporting tools. When a transit agency has access to the source code for a software system, they can perform their own in-house work on the system, on their own schedule, and with their own staff. New features are developed to meet the agency’s needs, not according to a vendor’s whims. Even if the agency elects to bring in contracted support to develop bug fixes or new features, they retain complete control over the process—and, more importantly, they own the end product.

Transit agencies may feel ill-at-ease at the prospect of getting into the business of software development, but the reality is that by bringing software skills in-house, they can realize the same gains as when they bring mechanical and electronic repair and overhaul in-house. In fact, the potential gains are even greater for software, when agencies use open-source software and actively participate in the surrounding community. Many of the fundamental problems of mass transit are the same from agency to agency, and software developed to solve a problem at one agency is very likely to be usable (at least in part) at other agencies.

PATCO open payment pilot launches

This week, PATCO and Cubic launched an open payment pilot on the PATCO Speedline, a rapid transit line which connects Philadelphia with southern New Jersey. This project, the third open payment program to be launched in the US (after the trials in New York City, and the UTA’s new fare collection system), is the first to include a prepaid card as an option for unbanked riders. Central to this program is a Visa prepaid card issued by The Bancorp Bank. The card can be used to pay transit fares in the same manner as PATCO’s existing FREEDOM Card, but, as an open-loop general-purpose reloadable card, it can also be used anywhere contactless cards are accepted—including other transit services.

The PATCO Speedline doesn’t operate in isolation; at one end it’s connected to SEPTA services in Philadelphia, and at the other end it’s connected to NJ Transit services, including the River Line and Atlantic City Line. Yet at present, there’s no integrated electronic fare collection where these agencies’ services connect; there is a discounted SEPTA fare available to PATCO Speeedline riders, but that requires buying a ticket from a PATCO ticket vending machine. To provide the best rider experience, applicable discounts should be applied automatically—and that requires that riders be able to use the same electronic fare media across the various systems.

As a matter of fact, open payment isn’t an absolute necessity for transit agencies to offer an integrated electronic fare collection system; after all, it’s now possible to travel from Quantico, VA to Hunt Valley, MD using only a SmarTrip card. However, providing that level of integration for SmarTrip requires that every participating transit agency use Cubic Nextfare (which as a practical matter also means using hardware from Cubic), and that all of the data be managed centrally. With open payment, that level of central coordination isn’t necessary.

Now, other agencies in the Philadelphia area, including SEPTA and NJ Transit, can deploy their own open payment systems, from vendors of their choosing, and they’ll be able to accept the same cards that are accepted on the PATCO Speedline as part of this pilot.

SEPTA has launched an informational site on their open payment plans, while NJ Transit continues to operate their part of the tri-agency trial that was conducted last year with MTA New York City Transit and PATH, so there is a very real possibility that riders will soon be able to transfer between all three agencies using a single card.
Continue reading PATCO open payment pilot launches

Reflective vests: not a target for terrorists; good for safety

In late May, the Philadelphia Inquirer reported on an ongoing dispute between SEPTA and the BLET, the union representing SEPTA’s railroad engineers. As reported by the Inquirer, this dispute (which is itself part of broader contract negotiations) centers on the requirement that engineers wear reflective vests on the job, not just while on or about the track, as is already required, but at all times.

SEPTA’s request doesn’t seem unreasonable, but the union’s not having any of it. Their first argument is that the vests are unfashionable; one engineer claims that “[w]e look like the Fruit of the Loom lemon in those things”. But they don’t stop there; the union also claims that engineers should not have to wear reflective vests because “[t]hey have identified for any potential terrorist who the locomotive engineer is”. The idea that a terrorist would single out an individual in a reflective vest sounds like what Bruce Schneier would call a movie-plot threat. Bluntly, it’s just not a credible argument against the vests—and neither is complaining about them being unfashionable.
Continue reading Reflective vests: not a target for terrorists; good for safety