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
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.