tags:

views:

131

answers:

4

I have to architect a commercial vehicle fleet tracking system.

Each vehicle (a few 100, max a few 1,000) will have a GPS and satellite transmitter and will periodically report its position. Positions will be stored in a database and used to create a Google Map.

There will of course be other functionalities. Security, log in, etc and probably lots of interaction with other corporate databses (drivers start/stop time for salary purposes, etc).

Question: pure GoogleMaps is probably best implemented as a browser based app (Php & MySql?), but with the additional functionality of a commercial vehicle fleet tracking system, would it be better doing something PC based (Windows/Linux)?

Any other advice? Thanks

+10  A: 

I think with the capabilities of modern browsers, along with various mature client-side frameworks, we are witnessing an always thinning distinction between web and desktop interfaces.

You may want to take into consideration that a web application automatically solves some important problems for you:

  • Distribution: No need to distribute your application. Simply provide a URL.
  • Updates: Upgrading and fixing problems in your software will be easier and quicker if you distribute it through a web interface.
  • Security: Deriving from the above, you are able to fix security vulnerabilities more promptly.
  • Compatibility: Your application will be able to work on any operating system that can launch a web browser.

Last but not least, remember that the Google Maps API is not free for this type of application. Article 10.9.C of Google Maps API Terms and Conditions explicitly restrict using the standard Google Maps API for fleet management and asset tracking. You would need the Google Maps API Premier to legally use Google Maps for your application.

According to one unofficial source (dated April 2008), this would cost USD 10,000 per year, which entitles you to track 100 vehicles. If you exceed the 100 vehicles, you would need to add USD 24 per additional vehicle per year.

Daniel Vassallo
+1 Excellent considerations.
Paul Sasik
Thanks, Daniel. That helped clarify my thinking on alot of points.
Mawg
+2  A: 

Don't forget that you can always host a web control in a thick client app. This is actually trivial with .Net on the Windows platform with the IE control. You can also access the browser's DOM this way and do some neat things. So just because there's a strong web component to what you're doing you're not necessarily "stuck" writing a pure web app.

One big question is what kind of hardware you'll be able to put in the vehicles. Will they be laptops or small PCs with full fledged OSs or something more mobile like CE or a pared-down Linux distro?

Paul Sasik
Or even something smaller http://www.sparkfun.com/commerce/product_info.php?products_id=7917
kenny
@Paul: There are plenty of options for the hardware, ranging from cheap models which you can find on ebay to more advanced ones which are more reliable and can be reprogrammed completely. The better ones would normally consist of a GPS chip, a GSM chip capable of transmitting data over GPRS/3G, a number digital/analogue inputs to check for the status of the ignition, switches, temperatures, etc, all tied on a small motherboard with some RAM, a small flash drive and an ARM processor. You would be able to find others with digital outputs to use as actuators, cameras, etc.
Daniel Vassallo
@Daniel: That's correct, there are plenty of options. The issue is, which will be chosen? The choice of platform will have some effects on the architecture.
Paul Sasik
With some effort, I'm sure you can build a hardware independent architecture (Hardware == the GPS/GSM devices). Since not all hardware models can be reprogrammed to send the data in a specific format, and through a specific protocol, at most you would have to attach to the application some sort of 'driver' for each hardware model that transforms the stream of data into a standard format that the application can understand.
Daniel Vassallo
I was thinaking to try to grab free wifi if avilable, then fallback to 3g. But if there is no 3g coverage we will need to fall back to satelite.A fairly simple embedded control is no problem (maybe eCos, maybe embedded Linux). The satellite modem - which is required - can provide lat/long.
Mawg
+2  A: 

Google Maps is JavaScript based so you can do most things with it, e.g browser based, widgets, etc. However due to the licensing Google won't allow you to use it in anything other than an Internet environment unless you use there Enterprise License.

In terms of integrating it into other systems, its really difficult to say what's best without knowing what other software you are using, what protocols they use, are web services available, etc. I agree with Daniel though in that any distributed system not implemented in a browser better have some good reasons not to, simply because the benefits are substantial. You'll need to weight them up though with a full break down of all the different systems you will need to interact with and work out what fits best.

The great thing is that with it being JavaScript based you have a lot of flexibility in what you can do with it.

Alex
+2  A: 

Implement solution for the domain problems first. It means data storage, data transmission between vehicles and your system, methods of data analysis, aggregation and visualisation. These will likely to sit as a head-less system on a server and provide access to it remotely, in both directions: to input data and to query data.

Now, PC or Web is more related to presentation on a client side. You can make both if you like. Web client as well as desktop application can serve as a client to remote data and operational server.

mloskot