You screech into the airport parking lot, desperate to find a spot so you can dash into the terminal to be scanned, probed, patted, and wanded—hopefully, before your flight takes off. What you see before you, in space after occupied space, are impediments to reaching your destination. But a group of researchers from Old Dominion University (ODU), in Norfolk, Va., see something different: a datacenter.

That’s right. In the spirit of waste not, want not, cars will no longer simply sit idle when their owners jet off to other cities or spend all day in office buildings. Engineers want to use your Internet-connected car as a cloud computing resource. Cars’ powerful on-board computers, ample storage, reliable wireless Internet connectivity, will be put to work as part of ad hoc datacenters that tackle computing jobs the way a bricks-and-mortar facility would.

Well, not exactly. A paper published in the March edition of IEEE Transactions on Intelligent Transportation Systems describes schemes for assigning computing jobs to cars—taking into account that, unlike a permanent datacenter, these four-wheeled computing resources could be driven away at any time. The ODU researchers also characterize how likely it is that a pending number-crunching job would have to be restarted from scratch because the vehicles in charge of the task were called upon to do something else, like provide transportation.

The vehicular cloud setup they envision has a few givens: Each car operates as a virtual machine, and is equipped with a virtual machine monitor that strikes a balance between what the car is capable of, what it’s currently doing, and the system needs; the vehicular cloud is set up in a parking lot that can accommodate thousands of cars; the lot is almost always nearly full, so that there are always at least two cars available to handle an incoming user job; and there is a mechanism that automatically identifies an available car the instant it enters the parking lot, and alerts the other car or cars with which it is sharing a task when it’s about to exit.

Because it’s impossible to predict exactly when a driver will return, the ODU researchers considered several redundancy schemes and presented two in detail. Under the first strategy, each job is assigned to two cars selected from the available cars in the lot. Car 1 and Car 2 operate independently, each trying separately to complete the job. If one of them drives off the lot before the task is finished, the remaining car recruits a new partner. Recruitment entails making a copy of the state of its guest virtual machine, selecting a new partner, and downloading the saved data. That way, if say Car 1 was halfway done when Car 2 left, Car 1 and Car 3 would both pick up at the halfway mark instead of at square one.

The second instantiation the researchers describe has a much higher fault tolerance built in. Each job is assigned to three cars. If Car 1 were to leave, one of the remaining two would handle the recruiting tasks. But what if, while Car 2 is saving the state of its virtual machine, Car 3 leaves too? Car 2 would simply recruit two available cars instead of one. If Car 1 leaves, and then Car 2 leaves before its recruiting job is done, Car 3 would fill the recruiter role, copying itself and pulling in two new partners.

It’s possible, under either a two-car or three-car work arrangement, for the ball to be dropped. But the likelihood can be vastly different. In simulations, the Old Dominion researchers discovered that even in the best-case scenario they looked at—an average vehicle residency of 8 hours—the mean time to failure for two-car work groups never exceeded 250 hours. Three-car groups, on the other hand, could go more than 4000 hours between instances where all three are driven out of the parking lot before any one of them has had a chance to save its work and hand off a copy to a fourth car.

It makes you wonder why you’d ever assign a task to just two cars. Puya Ghazizadeh, who was a PhD student at Old Dominion when he co-authored the paper, explains that, “Short jobs that are not too memory or network intensive are safe to do with two cars. They can be completed well before it’s likely that both of the cars would leave.” Just as important, says Ghazizadeh, is that, “Using two cars lets you maximize the utilization of the computing resources.” In other words, you can get more mileage out of a given number of cars in a parking lot.

Ghazizadeh, who is now a computer science professor at Millersville University, in Pennsylvania, says the juice is definitely worth the squeeze. “Whatever you can do on a traditional cloud, you can do with a group of cars.” Asked what a vehicular cloud comprising a thousand cars could do if it were working on all cylinders, he said, “It depends on the type of jobs you have. Simulation for bioinformatics, which requires a lot of intense computation, is much different than something simple, like converting old documents to PDFs.” Ghazizadeh explains that not only do memory intensive or network intensive jobs take longer to perform, they also make the recruiting process take longer because there’s a lot of data to copy and transfer to another car’s virtual machine.

Source article by Willie D. Jones in IEEE Spectrum
http://goo.gl/rg9Zth
http://spectrum.ieee.org/cars-that-think/transportation/advanced-cars/whats-the-year-make-and-model-of-your-vehicular-cloud
Posted 17 Mar 2016 | 13:30 GMT