Why TCIP sucks (and what can be done to fix it)

In the past few weeks, I’ve gotten a number of questions from a variety of sources about TCIP. Transit Communication Interface Profiles (TCIP) is ‘the FTA and APTA’s decades-old project that includes specifications for all manner of technology systems in the transit industry.’

If you want to stop reading now, just take my word that it’s not that great and rarely used. If you’re interested in learning why, and what I think should be done about it, read on.

What do you know about this?
As far as I know, I specified the interface for the largest deployment of TCIP in the world. I’ve read the spec cover to frustrating cover.

The origins of TCIP

“APTA TCIP is based on the earlier TCIP work performed by ITE, AASHTO, and NEMA and published as the NTCIP 1400-series standards.” If you follow NACTO, Streetsblog, or Strong Towns, you’ll wonder what those three groups had to do with it, and I would argue that you should rightfully be weary.

3 Reasons why TCIP Sucks
1. It was developed in the 90s with an eye towards then-existing technological constraints (see the presence of two binary encodings, ASN.1 and another quixotically implemented narrowband encoding). To maintain compatibility, all of the messages in TCIP inherit limitations of 80s technology. The translation of the standard into a more modern machine-readable encoding (XML) loses a fair bit of elegance.

2. “The TCIP documentation is extremely lengthy, and each version is contained within a series of Word documents. This document structure makes a comparison very cumbersome at best, impossible at worst.” Furthermore, these Word documents are both poorly formatted and so large they will choke even the most well-specced machine. Take a look at what is quite possibly the most important section of the document, the changelog.

3. If usage is any indication of the quality of the standard, then it is pretty poor. There is no real showcase implementation of the standard if the TCIP web page is anything to guide by. “While there are a number of projects that draw on TCIP, the standard is far from achieving its goals of providing intra- or inter-agency interoperability. While these goals might have been achieved in a few cases around the country, TCIP has seen nowhere near the adoption rate of GTFS.”

Fixing it

1. Make the documentation easier to deal with. The NTCIP (which is different than TCIP, but once enveloped it) has a great document for an introduction to that standard. The rest of TCIP should be broken off into smaller pieces depending on type and business area. The four volumes of TCIP cannot compare. Arguable, one of the volumes (an XML schema copy-pasted into a Word document) should not be a volume at all.

Furthermore, some comments in the aforementioned XML schema would be excellent.

2. Bring in some more modern encodings. The most common programming environment is now the web, and we’re now in an era where on-vehicle hardware and radio networks have matured immensely. Explicitly adopting RESTful JSON would clean this up.

3. Most controversially– deprecate the Passenger Information portion. SIRI is a much better supported option for small-scale information exchange. For exchange of information with the public (on revenue service only), GTFS is well supported and the de-facto standard. If this causes consternation, there is a precedent for US Federal standards to be replaced by international ones. The less-than-stellar FGDC CSDGM metadata standard has been superseded by the more well-organised ISO 191XX standards.

Note that I’ve suggested not deprecating the whole thing. There might be better options if you’re willing to look for them.

PS. This post owes a heavy debt to Landon Reed’s thesis.