Monday, June 5, 2006

OSGi for Industrial Devices

At the moment I am sitting in the train coming back from a consultancy job. A mid-sized company in Holland is developing a control system for their high end analytical devices. The devices are for a highly specialized market; the amount of knowledge that goes into these instruments is staggering. I was asked to review the architecture because their new architecture is based on OSGi technology.

At the end of the day I got a very enthusiastic tour of the company. I was shown all the different systems and the myriad of adapters that they can add to the core device. All these adapters must be supported by the software, using the standard OSGi Device Management. It is really cool to see all that stuff work in practice. Getting paid for learning so much new domain knowledge!

As you probably have noticed, I am not allowed to tell which manufacturer, or what he actually produces, because the company wants to keep the use of OSGi confidential. This is unfortunately true for many OSGi applications. It is always really hard to see these incredibly interesting applications of OSGi technology and then have to keep silent. I would love to tell you about the solutions they found to the hard problems of device control in high end technology.

Higher end devices are a perfect space for OSGi technology. We developed the specification for small embedded devices that are focused on consumer electronics. However, adoption of OSGi technology in this space is not high because of the eternal trade off between Bill Of Material (BOM) cost and development cost. When you intend to produce 100.000 devices, a single dollar saved in the BOM translates to 100.000 dollars in development. The extra requirements that the OSGi/Java puts upon the device (higher end CPU, more Flash, and more dynamic memory) are therefore often seen as prohibitive. I am not sure the arguments are still that valid, a Megabyte of Flash nowadays costs 2 dollar cents, but the consumer electronics is a very conservative industry. In these markets OSGi technology will not find large scale adoption until the end users start demanding it or providers like telcos see that they can generate money by selling electronic services.

However, as my visit showed, the level above consumer electronics thinks that the OSGi proposition is very interesting. In the higher end markets, the BOM is easily dwarfed by development and management cost. When your market is 600 devices a year and you have to feed a thousand mouths, the cost for a few megabytes and a faster processor is trivial. For these devices, using OSGi technology should almost be a no-brainer. High end embedded devices show a lot of diversity; in certain cases almost every configuration is unique. Any experienced person knows that this poses a nightmare for software maintenance. Trying to integrate this type of diversity in a single static image is just not workable. So far, only component systems can cope well with this problem and the OSGi Service Platform is the premier component system in the market. The OSGi technology for industrial devices can reduce development cost, simplify management, and opens up new business cases.

I do not think this goes unnoticed by many companies. During almost every trip I make I hear another story of a company that has been using OSGi for years. Most companies are proud about it but do not seek publicity. I think it is a character trait of embedded people to just get it done and not talk too much about it. There are also other reasons. For some companies it is such a strategic advantage that they do not want their competition to learn about their use of OSGi.

From my experience, I expect that in the next two years a lot of stories will surface where people tell how they successfully used OSGi technology to control many, many high end embedded devices. If you apply OSGi technology in an interesting environment, and you can talk about it, let me know. I’d love to write some articles about cool applications with OSGi technology.

Peter Kriens

No comments:

Post a Comment

Blog Archive