The future of OSGi in the Internet of Things

“Bosch Software Innovations GmbH, a wholly-owned subsidiary of the Bosch Group, intends to acquire the company ProSyst. Agreements to this effect were signed on February 13, 2015. ProSyst employs some 110 associates in Cologne, Germany, and Sofia, Bulgaria.”

This is the beginning of a press release that was published today. The acquisition, which is awaiting approval by the antitrust authorities, takes up several core issues related to the Internet of Things (IoT).

  • What is the right technology for the IoT?
  • How can a business ecosystem be developed based on open standards and open software?

Software companies, their people, their core competencies, their business models, and their development processes are closely bound up with their business environment. Getting all these factors right at the same time is a difficult undertaking, particularly in the young market of the IoT. ProSyst provides a great example: the company was a very early innovator in Java and OSGi technology for connected home systems. In 2003, BSH Hausgeräte GmbH (formerly BSH Bosch und Siemens Hausgeräte) launched the first ProSyst-based system on the market. At that time, consumers, and markets were not ready to cross the technology chasm; however, with smartphones now in everyone’s pockets and WiFi connectivity in their homes, we have since crossed that chasm. The recent CES in Las Vegas serves as an indicator that we have already hit the inflection point.

The acquisition of ProSyst is further testimony to the importance of the connected home market for Bosch. The importance of the connected home segment was also underscored by Robert Bosch GmbH’s becoming the sole shareholder of BSH Hausgeräte GmbH and establishing a consortium for connected homes with ABB and Cisco.

The right technology for the IoT

We believe that the technology ecosystem around Java, OSGi, and Eclipse IDE will play a dominant role in the IoT technology market. I probably don’t have to explain the wide use of Java, which currently has about nine million developers. Our system integrator partners Tech Mahindra, InfoSys, HCL, L&T Infotech, and RBEI (Robert Bosch Engineering and Business Solutions in India) support their customers with more than half a million Java developers.

Although Java’s role is undisputed, the future of OSGi (Open Service Gateway initiative) raises much more controversy in the developer community. Even though OSGi pros and cons are not new, one of my colleagues recently stated, “Personally, I think the discussion about OSGi or not will be endless.”

OSGi defines a Java service platform with a dynamic component model. This means software components can be remotely installed, started, stopped, updated, and uninstalled without rebooting the device. OSGi is defined by a set of specifications published by the OSGi Alliance. The reference implementation of the specs, called Equinox, is developed within the Eclipse community and also serves as the basis for the Eclipse IDE. Multiple other implementations exist today:

  • Felix (open source, Apache 2.0 license)
  • ProSyst (commercial license)
  • Concierge (open source, Eclipse Public License)
  • Knopflerfish (open source; makewave commercial offering incl. support plan also available)

The ProSyst implementation is often considered the one best suited for hardware with limited resources. Bosch currently uses both ProSyst mBS and the Felix implementation of the Apache foundation as the execution environment for M2M’s Agent Hub and Central Registry components.

OSGi technology has a wide range of other uses: Eclipse IDE, automotive telematics, industrial automation, building automation, PDAs, grid computing, and connected homes, for example. The technology itself is very mature, with the specs currently in their fifth version. However, it is also known for its steep learning curve and complex programming model. OSGi’s main advantage lies in its support for highly dynamic use cases where system components are expected to come and go at any time. This is reflected in the APIs and the programming model, which is initially unfamiliar to developers who are used to working with software that is deployed once, started up, and left in place for good. Our recipe to avoid these difficulties is to add additional layers: Device abstraction, automation abstraction, Information models, which are provided within e.g. ProSyst or Bosch IoT Suite.

But is there an OSGi alternative on the horizon for IoT gateways, devices, and backend? Of course – in fact, there are many! To name just a few:

  • Device integration or business integration on gateway
  • Device integration or business logic in backend

The JavaScript community is extremely dynamic and creative. In the wake of an initial storming phase, new technology might evolve. However, no standard components exist yet for managing software on gateways and edge devices, for instance. It is still too early to wager the investment of millions of devices produced every day on JavaScript and node.js. Don’t forget, the lifetime of IoT devices is five, ten, maybe even twenty years. If edge device or gateway technology wind up being dominated by Android’s Google or Apple’s iOS, we lack the required openness to build business ecosystems around it. Lua is a great language, but not adopted enough for a broad usage.

As of today, no technology is both more future-proven on IoT gateways and more mature than OSGi (except “real embedded” software in C, C++, and Assembler). Other industry players such as ABB, Cisco, GE, Deutsche Telekom, Oracle, and Hitachi are pursuing a very similar technological path. Which brings us to the business ecosystem question…

Open standards and open software for IoT

Compared to the other technologies above, OSGi is the only one with clearly defined specs and an open specification process behind them. ProSyst has played an important role in the OSGi Alliance since its first days in 1999, and in other open standardization bodies as well. The Eclipse ecosystem around open implementation is strong, and just a few days ago, Bosch Software Innovations contributed code to the Eclipse IoT Project Vorto to improve compatibility of information models in the IoT. Bosch is committed to an open platform approach for IoT, since we know that “nobody can do it alone”. The traditional value chain is not enough. Building up a vibrant business ecosystem in the IoT requires a value network of companies and (open source) communities as well as shared platforms based on open culture. Eclipse IoT is the first place to go for this.

Open cultures need a lot of trust. Trust you can build only with real people and real relationships. And the best way to do that is to come together and create a joint vision of the future possibilities in the IoT at the Bosch ConnectedWorld in Berlin, starting on February 17.

I hope to see you there or discuss your thoughts here in our blog!

Follow us live from Bosch ConnectedWorld
 

About the author

Stefan Ferber

Stefan Ferber

I am Senior Vice President for Engineering at Bosch Software Innovations GmbH in Germany – the Bosch Group’s software and systems house with responsibility for the Bosch IoT Suite – Bosch’s open IoT platform. In this role I represent Bosch in the board of the Eclipse Foundation, represented Bosch in the German “Industrie 4.0 Plattform”, and I am also a member of the European “Internet of Things Council“. Here I leverage more than twenty years experience in software development, software processes, software product lines and software architectures for embedded systems, computer vision, and IT domains. Before I was Product Manager for the Bosch eMobility Solution and therefore engaged internationally in the eMobility market, business models, standardization, and technology topics in Europe, Asia, and Australia. I also acted as Director of Bosch Corporate Systems Engineering Process Group and a technical expert for software engineering and software architectures mostly for automotive embedded software. I hold a Ph.D. and a diploma degree in Computer Science from the University of Karlsruhe, Germany and a MSc. in Computer Science from the University of Massachusetts Dartmouth, USA.