OSGi and Navigation
2006-04-19
One of the most exciting devices I know is a navigation system. I can still feel the awe for this technology despite understanding mostly how it works. It has something uncanny when you follow the instructions of a computer voice you end up right on the exact doorstep. It is amazing. Trying to explain how it works to people usually shows that most people think that the GPS satellites know exactly where you are. It makes you wonder how much people really worry about privacy invasion …
Navigation systems can exemplify why OSGi is important. Currently, all navigation systems that I know are closed boxes. The vendor provides a fixed set of functionality and that is it. However, this means that the navigation system works for the common tasks but not for more specialized tasks. The navigation system vendor has neither the money nor the knowledge to address an almost infinite need of requirements in the real world. These specialized tasks might address a smaller audience than the general tasks, however, the margins in addressing these smaller markets are usually much higher.
This is therefore a perfect example why these systems should have an OSGi Framework and a standardized interface to the navigation system. Allowing third parties to integrate seamlessly with a navigation systems enables third parties to build applications on top of it. Did you ever look at Google Maps? For example, a housing application, earthquakes, or even a game. This creativity and market opportunities are released because Google provides the access to the maps and other “details” while the developer can focus on his specialty. This model is obviously very successful for both parties. In this case Google gets to sell advertisements and the site gets some interesting new functionality.
This exact model is also possible with embedded devices. The only difference is that the vendor can make his profit more easily by selling the device and add-ons. For example, a real estate agent needs to drive a route when she shows a customer potential properties. A plain off the shelf navigation systems is awkward because then she must fill in all the addresses. A small bundle could make a world of difference. It could obtain the addresses from a database, convert them to the navigation system, create the route and provide all the details of the properties when the car approaches. This can seriously reduce the amount of work for the real estate agent, meaning she is willing to pay real money for such a service.
There are many more similar scenarios:
The key reason is of course fear for the future. There are some scary aspects in allowing other parties to use your device. You need more memory and a bigger CPU, which could be prohibitive in a highly competitive market. However, costs are never a problem when the user gets a significant advantage, unfortunately, he first has to see this advantage before believing it. Fortunately there are two trends that will make this feasible soon. Navigation systems are becoming commodities, which will make the vendors look for features, and the price of memory and CPUs is dropping faster and faster.
Another problem currently is that there is no standard API to manage the navigation system from another bundle. The reason that I wrote this blog because I started working on a Navigation Model Service for the OSGi Alliance which made me realize how much you could do with this API. And best of all, once there is a standard API, you might even run these navigation applications in your car as well as in your new OSGi Mobile Platform phone.
Peter Kriens
Navigation systems can exemplify why OSGi is important. Currently, all navigation systems that I know are closed boxes. The vendor provides a fixed set of functionality and that is it. However, this means that the navigation system works for the common tasks but not for more specialized tasks. The navigation system vendor has neither the money nor the knowledge to address an almost infinite need of requirements in the real world. These specialized tasks might address a smaller audience than the general tasks, however, the margins in addressing these smaller markets are usually much higher.
This is therefore a perfect example why these systems should have an OSGi Framework and a standardized interface to the navigation system. Allowing third parties to integrate seamlessly with a navigation systems enables third parties to build applications on top of it. Did you ever look at Google Maps? For example, a housing application, earthquakes, or even a game. This creativity and market opportunities are released because Google provides the access to the maps and other “details” while the developer can focus on his specialty. This model is obviously very successful for both parties. In this case Google gets to sell advertisements and the site gets some interesting new functionality.
This exact model is also possible with embedded devices. The only difference is that the vendor can make his profit more easily by selling the device and add-ons. For example, a real estate agent needs to drive a route when she shows a customer potential properties. A plain off the shelf navigation systems is awkward because then she must fill in all the addresses. A small bundle could make a world of difference. It could obtain the addresses from a database, convert them to the navigation system, create the route and provide all the details of the properties when the car approaches. This can seriously reduce the amount of work for the real estate agent, meaning she is willing to pay real money for such a service.
There are many more similar scenarios:
- Games using real world maps and positioning (maybe not such a good idea in a driving car)
- Destinations that move. For example navigating to a person, querying the position and then navigating to that person wherever he is.
- Traffic alerts
- Showing the position of other people
- Taxis, receiving the route from the dispatcher
- And so much more …
The key reason is of course fear for the future. There are some scary aspects in allowing other parties to use your device. You need more memory and a bigger CPU, which could be prohibitive in a highly competitive market. However, costs are never a problem when the user gets a significant advantage, unfortunately, he first has to see this advantage before believing it. Fortunately there are two trends that will make this feasible soon. Navigation systems are becoming commodities, which will make the vendors look for features, and the price of memory and CPUs is dropping faster and faster.
Another problem currently is that there is no standard API to manage the navigation system from another bundle. The reason that I wrote this blog because I started working on a Navigation Model Service for the OSGi Alliance which made me realize how much you could do with this API. And best of all, once there is a standard API, you might even run these navigation applications in your car as well as in your new OSGi Mobile Platform phone.
Peter Kriens
Add a comment