DRIVR Part 6: The future ain't what it used to be

You know that giant projection TV that was still at your parents' house long after you went away from college? It's crazy to think that at one time that was the pinnacle of home entertainment technology. Pair that sucker with an HD DVD player and a bumper pool table, and you've got yourself a proper rec room. But unfortunately, obsolescence is an inevitable part of selecting hardware. It also can bite when it comes to selecting protocols or even software. Things get especially painful when you're dealing with a fleet and you have to perform every upgrade 65,535 times (pretty sure there's a word for this).

But wait, aren't we doing most of our computations in a single location, aka the big brain, aka Ozyvandias? While we still need decent processing on the vehicle, the requirements will be much more relaxed, leading to cheaper hardware and a more stable setup. If we discover a new algorithm that lets us safely use the bike lane to get through rush hour (share the road!) but requires 30% more processing power than we currently have available, we only have to upgrade the hardware in Ozyvandias. In fact, we would only need a partial upgrade, as for the most part our original hardware would be adequate. Any time a vehicle decides to "Go Go Gadget green lane" we can handle their computations on the fancy machines.

Can we take this one step further? Did Grizzly Adams have a beard? Why should we settle just for being nimble in the hardware domain? Why not extend this to software as well. Remember, our vehicles get their instructions by means of messages coming from Ozyvandias. They don't care how these instructions were created, just as long as they arrive on time. Now you better believe that we'll design Ozyvandias with a decentralized architecture in order to maximize robustness and up-time, which likely means that the many processes populating Carnia will be communicating via messages as well. As long as there is a common protocol shared by the processes, then they can be written in whatever language is most suitable for the task. They don't even have to be run on the same type of operating systems. This flexibility will allow us to tailor the software to each requirement, as opposed to trying to find one solution that simply has the fewest drawbacks. Of course, it's possible that the customization causes more problems than it solves, but it's tough to make predictions, especially about the future. So we'll give it a try and see what happens. No matter what, we'll always have Paris.

Do you want to know more, but just can't wait for the next post? Drop me a line, so I can disappoint you in person!

- Greg

The story continues with Part 7: On your marks