Writing

Feed Software, technology, sysadmin war stories, and more.

Friday, July 13, 2012

If the software industry built railroad maintenance trucks

I saw something interesting not too long ago. There was a pickup truck rolling down one of the railroads here in town. It had these special metal wheels underneath which allowed it to ride on the rails just like a train. I assume they could be lifted out of the way for driving on a road like a normal vehicle. It seemed pretty clever.

It makes me wonder what a railroad maintenance pickup truck would look like if it was built by the software industry. I mean, clearly, this is a computer vision problem. Let's start with a standard truck with four tires. You need cameras front and rear to drive the steering inputs since otherwise it's too hard to stay centered. If you veer off to either side, your tires will hit the rails.

So, version 1.0 would strap a camera to the front and back and put a huge computer in the truck bed. Then it would steer for you while you were on the rails. Let's say the programmers managed to pull this much off. You'd still have a miserable ride, what, with all of the bouncing on those ties. The programmers never had this problem since their dev environment had rails on a concrete floor, not actual rails which were nailed into railroad ties.

This would lead to version 2.0, where now the shocks were also connected to this even larger computer system. Its cameras would figure out the spacing of each railroad tie and would adjust the shocks on that axle to balance out the bump. That way, the wheels might still be bumping along, but the human inside would have a nice ride.

Then someone tried to use it at night and realized the headlights aren't powerful enough, and the system gave up. That brought us version 3.0 with extra lights directed down at the ground right where the front camera is pointing just so it can work at night. This was okay, but then someone tried to go in reverse and found out the hard way that their stock backup lights weren't bright enough. Version 3.1 added a second set of lights on the back just to illuminate the tracks back there.

The engineers were feeling pretty good. They had a system which could work at night, forward or backwards, and it gave a nice smooth ride down the railroad ties while not bumping the rails.

Then, one night, someone took out one of the trucks and happened to go through a crossing right as an 18 wheeler rolled through. Kaboom. Why was the semi in the crossing, you ask? Easy. The crossing gates weren't down. Why didn't they come down? Well, when a train comes through, it effectively connects one rail to the other, so the crossing can know it's coming.

Your whizbang pickup truck v3.1 isn't touching the rails at all, and so it doesn't make any connection. When you roll up to the intersection on the railroad, the vehicle traffic on the crossing road has no idea you're even coming.

Several lawsuits later, the developers come back with a plan to upgrade every crossing to support radio receivers. Then they add radio transmitters to their trucks so they can warn crossings to lower the gates. Version 4.0 is released and is hailed as an epic development and improvement in safety. Millions of dollars are spent upgrading crossings to add the radio receiver in addition to the existing track sensing logic.

A couple of days after version 4.0 is deployed to the fleet, bug reports start coming in. It seems crossings are triggering when there's no train or work truck coming, and strangely, it happens at the top of the hour just like clockwork. After a lot of head-scratching, someone figures it out. It turns out that the third harmonic of some local radio transmitter is equal to the frequency the railroad is using, and every time that station broadcasts the BEEP at the top of the hour (kids, ask your parents), it's strong enough to trigger the gates.

Clearly, this is just a matter of the radio protocol being too simple. The engineers know what to do about simplicity: design it out! So, they go back and come up with a digitally encoded scheme which will never be confused by a single tone. This works fine, but it requires higher transmitter power on the trucks in order to ensure reliable decoding.

They ship this as version 5.0.

By now you should know that something crazy happens with this one. Indeed, something does. Because they've boosted the transmitter power, the trucks can now reach crossing receivers all over the valley instead of just the one or two near them. Any time someone takes one of these trucks out to do a work order, ALL of the crossings from Redwood City to Fremont to Gilroy come down and stay down until that worker is done.

It's insanity! Heads start rolling. The engineers know exactly what to do, though. They point out that their new digital protocol allows for much more data to be conveyed. They'll just put a GPS receiver on the truck, and add that to the data burst. Then, the crossing receivers can just ignore any truck that's too far away. That way, it doesn't matter how strong the signal is, since it won't trigger unless your location is within a small circle surrounding the crossing.

GPS support ships as version 6.0. Things work pretty well.

Then, one day, someone takes one of these trucks up to San Francisco. As anyone who's ridden Caltrain knows, there are several tunnels on way up there. Inside those tunnels, you get no GPS reception. Instead of sending old data or not sending anything at all, the transmitter sends a placeholder: (0, 0).

The next crossing hears the truck coming and looks at the latitude and longitude: 0 degrees north, 0 degrees west. Well, that can be ignored! After all, that puts the truck out in the middle of the Atlantic ocean, and this crossing is right here in San Francisco!

You can guess what happens after that.

Sometimes, more layers of more and more technology is just not the answer, no matter how "revolutionary" or "groundbreaking" it may be.