Refactoring Asynchronous Event Handling in the Real-Time Specification for Java

The Real-Time Specification for Java (RTSJ) is silent on multiprocessor issues. It attempts not to preclude multiprocessor implementations but provides no direct support. Many areas of the RTSJ leave an implementation considerable freedom on how it provides the defined functionality. One such area is the asynchronous event handling (AEH) model. Events are fired and associated handlers are scheduled for execution in response; handlers have defined scheduling parameters and deadlines. The primary goal of the AEH model is to support a lightweight real-time concurrency model. Hence handlers, in general, do not have dedicated threads. Rather, the implementation is responsible for ensuring that all handlers meet their deadlines. Typically real-time threads are assigned to execute handlers by the implementation. This paper discusses the issues associated with implementing the AEH model on multiprocessor systems. The emphasis here is on achieving a lightweight model. A model is lightweight if it is able to meet the deadlines of all handlers with as few as possible real-time threads. In the RTSJ this is made more complicated because asynchronous event handlers are allowed to suspend themselves (for example, by waiting on a monitor condition). Such handlers are called blocking handlers. Most of an implementation's freedom comes from being able to optimize the support for those handlers that do not block. The paper first examines all possible releasing sequences of non-blocking handlers on multiprocessor systems. Based on this, it proposes an efficient and scalable AEH mapping model for multiprocessor systems, which limits the number of real-time threads even in the worst case while retaining the schedulability of the system. The proposed model is then examined to prove its safety and liveness requirements using a model checking tool, UPPAAL. The verification and simulation results of the model indicate that the safety and liveness requirements are satisfied. Most importantly, this paper derives the proposed model's greatest lower and least upper bounds of real-time threads required to execute a given number of non-blocking handlers. The greatest lower bound is equal to the number of processors, and the least upper bound is equal to the number of processors times that of the priority levels in the system. In the model, the number of real-time threads required to execute a given number of non-blocking handlers is restricted to between these two bounds depending on the releasing sequence of handlers. Even in the worst case, the model requires the least upper bound of real-time threads which is, in most cases, considerably less than the actual number of handlers in the system. This, in turn, enables the proposed model to be efficient and scalable by reducing time and space overheads, compared with a traditional 1:1 AEH mapping model where each handler is mapped to a single thread.

Region-Based RTSJ Memory Management: State of the art

This paper illustrates how the real-time specification for Java (RTSJ) can be modified to allow applications to implement more flexible scheduling. The proposed approach is a two-level scheduling mechanism where the first level is the RTSJ priority scheduler and the second level is under application control. Minimum, backward-compatible changes to the RTSJ specification are discussed to motivate the required interface. The only assumptions made about the underlying real-time operating system are that it supports pre-emptive priority-based dispatching and that changes to priorities have immediate effect.

The Real-Time Specification for Java (RTSJ) [13] is becoming a popular choice in the world of real-time and embedded programming. However, RTSJ introduces many non-intuitive rules and restrictions which prevent its wide adoption. Moreover, current state-of-the-art frameworks usually fail to alleviate the development process into higher layers of the software development life-cycle. In this paper we extend our philosophy that RTSJ concepts need to be considered at early stages of software development, postulated in our prior work [2], in a framework that provides continuum between the design and implementation process. A component model designed specially for RTSJ serves here as a cornerstone. As the first contribution of this work, we propose a development process where RTSJ concepts are manipulated independently of functional aspects. Second, we mitigate complexities of RTSJ-development by automatically generating execution infrastructure where real-time concerns are transparently managed. We thus allow developers to create systems for variously constrained real-time and embedded environments. Performed benchmarks show that the overhead of the framework is minimal in comparison to manually written object-oriented applications, while providing more extensive functionality. Finally, the framework is designed with the stress on dynamic adaptability of target systems, a property we envisage as a fundamental in an upcoming era of massively developed real-time systems.

New languages, programming disciplines, operating systems, and software engineering techniques sometimes hold considerable potential for real-time software developers. A promising area of interest-but one fairly new to the real-time community-is object-oriented programming. Java, for example, draws heavily from object orientation and is highly suitable for extension to real-time and embedded systems. Recognizing this fit between Java and real-time software development, the Real-Time for Java Experts Group (RTJEG) began developing the real-time specification for Java (RTSJ) in March 1999 under the Java Community Process. This article explains RTSJ's features and the thinking behind the specification's design. The goal of the RTJEG, of which the authors are both members, was to provide a platform-a Java execution environment and application program interface (API)-that lets programmers correctly reason about the temporal behavior of executing software.

Although developing to the application programming interface of an implementation of the real-time specification for Java (RTSJ) might typically be considered more for production than prototyping the APIs provide a such a high-level and abstract interface, especially in the temporal domain, that they are also useful for rapid prototyping. The design of the RTSJ attempts to provide temporal semantics such that real-time developers need not spend significant effort thinking about time. This sounds, at first, backwards, but on reflection one can see that it is a profoundly new and productive view of the real-time developer's task. The APIs allow an almost declarative style of informing the underlying system about the periodicity, frequency, phasing, and asynchronicity needed by the application domain requirements. During construction of instances of the Schedulable class the application simply states the periodicity, period (frequency), phasing, for the instance and the underlying machinery takes care of all temporal issues. My talk will first cover the RTSJ briefly, pointing out relevant and interesting sections and some of our innovations, such as the real-time garbage collector and then give a detailed discussion of the case study. We built a full feedback controller for a state-of-the-art industrial robot, the ABB IRB 340. This controller has a period of 1 millisecond and was fully realized in Java. The controller was constructed in about a month by 2 graduate students. A video of the demonstration of the IRB 340 at JavaOne 2007 can be found here, http://www.youtube.com/watch?v=xH1yUXd9krU.

The OSGi Framework, has proven ideal in developing dynamically reconfigurable Java applications based on the principles of Component-Based Software Engineering (CBSE) and Service-Oriented Architecture (SOA). One domain where OSGi has yet to make an impact is real-time systems. This is partly due to the fact that the OSGi Framework is based on standard Java, which is not suitable for developing such systems. Other reasons include the absence of various features such as temporal isolation, admission control, and a reconfigurable garbage collector (along with the associated analysis to determine the pace of garbage collection). Also, a number of features of the OSGi Framework increase the difficulty in determining the worst case execution time (WCET) of threads. This makes real-time analysis more difficult. This chapter discusses the problems associated with extending the OSGi Framework and integrating it with the Real-Time Specification for Java (RTSJ). The focus is on the design of a real-time version of the OSGi Framework (RT-OSGi) which is capable of deploying dynamically reconfigurable real-time Java applications.

Java's popularity, facilities and platform independence have made it an interesting language for the real time community. The RTSJ (real-time specification for Java) is a Java extension to allow the development of real-time systems. RTSJ does not supply any support for the development of real-time distributed systems. The goal of this work is to define support for this type of systems, based on RMI (remote method invocation). However, the high diversity of real-time systems implies that there is not a single RT-RMI definition that satisfies their requirements. This article presents the basics of two real-time RMI approaches: safety critical RMI, to support hard real-time and high integrity requirements, and quality of service RMI for soft real-time systems, which is based on resource reservation to provide some minimal required quality.

The goal of this paper is to evaluate the real-time specification for Java proposal by performing several case studies. These case studies include: an extensible general resource controller; atomic action support infrastructure; unbounded and imprecise computations. They have been used previously by the Ada community to evaluate the efficacy of the Ada concurrency and real-time models. Our results indicate that the Real-Time Specification for Java is expressive enough to cope with the demands of real-time concurrent programming. If it can be implemented efficiently, it will provide an alternative to Ada 95 for programming real-time systems.

The integration of real-time concepts into modeling tools and Java virtual machines and APIs are two problems addressed along last decade. Examples of standards addressing these problems are RTSJ (Real-Time Specification for Java) and MARTE (Modeling and Analysis of Real-time Embedded Systems). These standards, in general, have common fundaments (time predictability of software systems based on scheduling analysis methods and object-oriented languages).Model driven developments methods are based on the application of generators and transformations, on source models, to generate code and artifacts of specific run-time platforms. Common fundaments of RTSJ and MARTE make possible their integration in a common model-driven software development framework. But this integration requires the developments of generators and transformations, and the customizations of UML extensions for the specific run-time platform. Integration of UML profiles into code generations requires specific customizations of generators. This paper studies these problems and proposes solutions for the application of model driven development techniques to develop of RTSJ software systems.

The paper addresses the issue of improving the performance of memory management for real time Java applications, building upon the Real-Time Specification for Java (RTSJ) from the Real-Time Java Expert Group. In a first step, a thorough analysis of the parameters influencing the performance of memory management together with ways of improvement are presented. The implementation of a memory management solution, which is compliant with the RTSJ and integrating the proposed improvements is then sketched.

: There is an increasing interest in recent years to use the Java(trade mark) programming language for implementing real-time systems. Recent advances in the Real-Time Specification for Java (RTSJ) have resulted in the introduction of new means for creating predictable real-time environments for Java programs. However, these new features also make the Java semantics more complex and the run-time behaviors of the Java programs more difficult to analyze. In this technical report, we describe a number of preliminary experiments we performed to study the features of the Sun Java Real-Time System (RTJ 1.0). We designed these experiments to verify the viability of the Real-Time Java language for the implementation of the Global Integrated Fire Control System (GIFC)-a component of the C2BMC element of the Ballistic Missile Defense System (BMDS). Our preliminary experiment shows that it is preferable to use only the Real-Time Java threads that use the heap memory and not the no-heap real-time threads for the GIFC software. However, such architecture cannot be implemented by using RTJ 1.0. Further experiments are needed to determine if the preferred architecture can be implemented with the upcoming RTJ 2.0, which will give programmers more control over the priority of the garbage collection.

[Abstract] The Operationally Responsive Spa ce (ORS) program envisions building a 6 day to support fast changing tactical missions. A key requirement would be the ability to rapidly compose the spacecraft that would perform both the needed mission - and spacecraft -oriented functionality using (PnP) enabled spacecraft components. To address this need, a service -oriented spacecraft architectural model is under development as part of the Air Force Research Laboratory (AFRL) Responsive Space Testbed effort to provide a reusable , reference infrastructure for Responsive Space. The Lockheed Martin ATC is pursuing the development of a Java -based distributed architecture environment that supports this service -oriented, reference spacecraft architectural model. A key component of th is approach involves a simulation architecture that is based on spacecraft services, much like the service -oriented models now widely used in the consumer marketplace, but is an evolutionary step to extend simulation to operations. To span the entire range from simulation to operations seamlessly, a single vertically integrated software architecture is needed. The Java -based distributed architecture provides such an environment with its evolution from desktop, to enterprise, to mobile devices, and now to real time systems. The Java environment addresses the complexity needed for operational simulations and ultimate deployment for integrated spacecraft flight and payload control systems. The Real Time Specification for Java (RTSJ) supports hard real time, s oft real time and non -real time processes all interoperating within the same virtual machine. Initial prototyping is being done using IBM's Real Time Java (RTJ) implementation of the RTSJ. The Java platform support several libraries, and one in particular, the JINI protocol, which supports the operation of dynamically changing networks of distributed services (and devices). Using JINI, running as a non -real time process within IBM's RTJ environment, provides the rich set of Plug -N-Play capabilities needed to demonstrate both automatic configuration, as would be needed for Assembly, Integration and Test (AI&T), as well as for operational fault tolerance and reconfigurability needed for on -orbit operations.

We propose a new, minimal specification for real-time Java for safety critical applications. The intention is to provide a profile that supports programming of applications that can be validated against safety critical standards such as DO-178B (1992). The proposed profile is in line with the Java specification request JSR-302: Safety Critical Java Technology, which is still under discussion. In contrast to the current direction of the expert group for the JSR-302 we do not subset the rather complex Real-Time Specification for Java (RTSJ). Nevertheless, our profile can be implemented on top of an RTSJ compliant JVM

Planetary science missions, such as those that explore Mars and Saturn, employ a variety of spacecraft such as arbiters, landers, probes, and rovers. Each of these kinds of spacecraft depends on embedded real-time control systems - systems that are increasingly being asked to do more as challenging new mission concepts are proposed. For both systems engineers and software engineers the large challenges are in analysis, design and verification of complex control systems that run on relatively limited processors. Project Golden Gate - a collaboration among NASA's Jet Propulsion Laboratory, Sun Microsystems Laboratory, and Carnegie Mellon University - is exploring those challenges in the context of real-time Java applied to space mission software. This paper describes the problem domain and our experimentation with the first commercial implementation of the real time specification for Java. The two main issues explored in this report are: (I) the effect of RTSJ's nonheap memory on the programming model, and (2) performance benchmarking of RTSJ/Linux relative to C++/VxWorks