Public Transit and the Internet of Recognition

Today, at the California Transit Association Conference, I had the pleasure of meeting Brad Cecil, Sr. Business Development VP at Cubic. I enjoyed the discussion because Brad asked some very important questions about AI, people-counting, and real-time networks. Brad has also written a number of compelling articles including this manifesto for TMaaS (Transit Management as a Service).

"These new platforms will rely instead upon cloud computing, SaaS and web services, mobile networking, and an Internet of Things approach to on-board systems. The emerging operations systems will also be software-oriented, not hardware-oriented, so they will be more easily deployed, scaled and updated." -- Brad Cecil

Brad is right; there's an obvious accelerating shift in dependence from hardware to software especially where mobility matters.

"... agencies have invested millions of dollars in hardware systems, and to further capitalize on those systems, they will essentially “double down” on the purchase and utilization of even more hardware systems. I call this the big hardware trap." -- Brad Cecil

Right again (see Newton's First Law). Some agencies will likely triple-down before they realize just how deep the quicksand is.

"...and in many cases, yet another piece of hardware – a ginormous on-board server called a vehicle logic unit (VLU) that is used to manage all the other hardware."

This is the passage where I would have loved to collaborate with Brad on his TMaaS manifesto.

The hardware calamity and the various independent point solutions intended to provide better safety, security, and convenience for passengers is a clear and present risk to strategic plans for all transit agencies. Indeed, this ever-increasing hardware complexity has a practical ceiling. It suggests a sea-change is very likely and disruption is probably going to happen soon. But it's not difficult to imagine what's next and we can handily sketch the computing climate that will ultimately validate Brad's hardware trap hypothesis.

Edge-First

Surprisingly, the TMaaS manifesto mentions nothing about edge-first architectures. The only way to do more, know more, provide deeper and more seamless integration of critical services in public transit is to position vastly more powerful computing capacity closer to passengers. In that sense, the assertion that a ginormous on-board server -- to manage all the other hardware -- misjudges a key and extremely successful approach to modern information architectures.

Public transit vehicles are rapidly becoming rolling data centers. And to achieve that, you need more computing power onboard. Tesla understands this pattern this very well. Powerful distributed computing is the single most important element in Tesla automobiles and all vehicles that must process and manage thousands of events every second. Public transit vehicles are no different; they must be able to act and react autonomously and with millisecond and even micro-second precision.

Edge-first architectures require GPUs, not CPUs. This is hardly the realm of "big servers". Rather, far different computing devices are necessary to not only manage and listen to the dozens, hundreds, and eventually thousands of sensors on vehicles, but to also provide a robust multi-TOPS computing climate for AI and the Internet of Recognition™.

Internet of Recognition™ (IoR)

The Internet of Recognition is a broader, smarter, massively scalable capacity to see the unseeable. It dwarfs the Internet of Things by many magnitudes.

How is this possible?

AI, machine learning, and machine vision are three core technologies that conspire to provide a limitless opportunity to see and embrace everything and everyone. In contrast, IoT is limited to devices that are specifically designed to integrate over IP networks.

Seeing the unseeable and recognizing patterns that are wholly unrecognizable by humans require that we employ AI to do the heavy lifting. This includes the ability see and alert on emergent situations such as violence, accidents, and even lost purses and phones.

Real-Time ... An Abused Term

Everyone tosses the "real-time" label around without any consideration of a precise definition. In the context of public transit, this is increasingly the case, yet few have actually changed anything about their integration architectures. They continue to use slow, resource-intensive RESTful APIs and other means of data conveyance that are generally performant, but hardly what you could claim as truly real-time. Furthermore, these protocols were never intended to be used to integrate truly real-time data and analytics. Lastly, these APIs erode the ability to convey increasingly complex event data over cellular networks.

In my view, the high bar of real-time architectures should be reserved to systems that actually meet sub-second performance. Everything else is at best, near-real-time and comparatively latent.

Recalibrated Hardware Trap

I think it's a good time for transit agencies to recalibrate their hardware plans, but not for the same reasons that the TMaaS Manifesto suggests. Indeed, we can all agree that the modernization of surveillance and other safety analytics in transit is long overdue. However, after a week at CTA, I could find no evidence that any vendor has charted a way through the hard ceiling created by an increasing number of disparate point solutions that fail to interoperate with modern communication protocols or factor in the Internet of Recognition.