Although OSGi was designed with embedded systems in mind, its current support is insufficient for coping with one main characteristic of many embedded systems: real-time performance.
OSGi defines a reference framework on which application providers may deploy applications, called bundles in OSGi’s terminology, which use other bundles and export their services to other bundles. OSGi is Java centric and inherits its pros and cons. On the one hand, it means that bundles may use a large number of APIs that help develop new services. On the other, the developer also has to deal with other Java’s issues related to poor efficiency and performance, garbage collection interference and other sources of delay.
One of the key requirements for the success of OSGi is standardization. As long as the initiative maintain a coherent and updated description of the basic services included in a reference implementation and define different profiles for specific domains, the interoperability among different applications and platform implementers will be preserved.
This initiative should be dynamic and consider that new domains, not considered at its first design, may appear. One of these new environments is real-time systems. To date, OSGi does not target directly at having specific support for real-time performance in its core or as some restricted profile.
In hard real-time applications a deadline is a typical real-time requirement. Smart home  offers us many examples of real-time applications such as TV and home surveillance systems. Many digital TVs use multimedia software stacks to reduce deployment costs and improve adaptability to new formats. On them, the primary goal is to deliver certain amount of frames per second (20 FPS) while keeping a low loss ratio.
Other applications with real-time performance requirements have sensors spread throughout the home, notifying the home owner about intruders. In this case, the response may have tight constraints on reaction time to the intruder (to avoid certain attacks) which may involve actions such as: take a picture of the intruders, send it to the Internet and notify the owner about new intruders.
Unfortunately, OSGi is not particularly well-equipped for real-time because the platform itself and many of its bundles are Java programs and inherit Java’s issues with real-time. These issues include: a fuzzy priority scheduling; the garbage collectors, which introduce high latency and overhead; and the byte- code execution model which is slow when compared against C/C++ native applications. Some sources of unpredictability are more relevant than others due to the special architecture of OSGi.
One of these mechanisms is the class loader of Java. In OSGi class loaders are essential to support multiple versions of a bundle to exist in a virtual machine. However, many times class loading is discarded from real-time phases due to its higher unpredictability.
The provision of real-time performance in Java is being addressed by the real-time Java community. This global effort contributes techniques used in real-time systems to Java’s programming model and defines specific approaches to issues stemmed from the use of Java in real-time. To date, it has produced a specification, the Real-Time Specification Java (RTSJ). However, the integration of real-time Java and OSGi is still an open issue that requires significant effort to become a real-time OSGi technology.
This article analyzes different key issues in providing OSGi with real-time Java performance covering motivational issues, and different integration ways and challenges stemmed from the integration. It also contributes a general framework for introducing real-time performance in OSGi, which is called the TROSGi framework.
The framework uses real-time Java virtual machines and RTSJ: The Real-Time Specification for Java. The adoption of this framework allows cyber-physical systems to experience real- time Java performance in their applications. The framework introduces several integration levels for OSGi and RTSJ, and specific real-time OSGi services. An empirical implementation was carried out using standard software, which was extended with the new defined services.
To read this external content in full, download the complete paper from the author archives at the University of Cantabria (Spain)