OSGi Based Hardware

Having worked with OSGi Technology for more years than I care to remember, it is still hard to understand that not all hardware has an embedded OSGi Framework. Ok, maybe not all, but it would really be nice to get rid of the dichotomy between native and Java code. Despite the fact that flash memory now costs cents per megabyte in large quantities, people still tell me that they cannot afford OSGi/Java for cost reasons. Maybe, I still think that they do not see how OSGi not only reduces many of the development and deployment costs, but it also provides an after sales revenue model.

Roland Berger, from Fraunhofer in Nürnberg, pleasantly surprised me by sending information about a prototype of their embedded hardware board with specifications that make it very suitable for many embedded applications: 180 Mhz ARM 9 CPU, 8 MB Flash, 32 MB SDRAM, Ethernet, USB, and serial and digital IO. Nice, but not spectacular. However, what makes it really cool is the fact that Fraunhofer will provide this with a full blown OSGi stack. This board will allow you to develop programs in Java in a fraction of the time of similar boards in native code. The board is still in development, but a ready OSGi based bored will probably cost around €100.

The board made me think (again) about embedded hardware and OSGi. The advantages of OSGi Frameworks seem so obvious. Why is there not much more hardware with OSGi Frameworks? Today, the complexity of software is so high, that the simplicity provide by OSGi/Java seems a no-brainer.

One key problem I can see is the dichotomy between native and Java. When I was working at Ericsson Research I was part of the e-box architecture team. I?d rather not relive the hours we spent fighting about which parts had to be done in Java and which had to be done natively in Linux. I lost a often because in 1998 we did not have many solutions like DHCP, DNS, SMTP, and others readily available in Java. Management therefore invariably chose the native solutions because my opponents could show something the next day, something I had to develop from scratch which took at least two days. My strongest argument was that the Java code had a much cleaner management model, which I still believe. However, this argument was voided because the drivers had no other choice then to be written natively anyway, requiring the more complicated management model anyway.

Eight years later, I think the situation has changed. Memory has become cheap, processors have become fast and today you can actually write many drivers in Java. A very exciting project is, for example, JNode, which builds a Java environment on the bare metal. Today, most of the interesting devices can be connected via USB. Since USB 2.0, this interface has become fast enough to support both high end devices like hard disks and low end devices like mouse devices. The architecture of the USB specification makes it possible to write the device drivers in Java. A USB device driver must be able to deliver and receive rather large buffers in a timely way, easy in reach of today?s hardware platforms. Combine this with the fact that USB devices are plugged in by end-users and you have a perfect application for OSGi Frameworks. A user connects a USB device and the host downloads a bundle with the correct driver. This is an acute problem in, for example, the car industry where USB is sometimes used to connect end-user devices like i-Pods into the car system. The diversity is staggering, no car manufacturer can hope to write custom drivers for all possible USB (or Bluetooth) devices.

Writing a USB or Bluetooth device driver in Java would be significantly simpler than doing the same thing in the Windows world or the Unix world. Better, if this model became popular, manufacturers could provide a single driver that ran on all platforms. I strongly believe in this model, but it would need companies that see a business case in this to make it true.

Peter Kriens
posted by Peter @ Tuesday, December 13, 2005