Evaluating the Expressive Power of 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.

The primary goal for asynchronous event handling (AEH) in the Real-Time Specification for Java (RTSJ) is to have a lightweight concurrency mechanism. However the RTSJ neither provides a well-defined guideline on how to implement AEH nor requires the documentation of the AEH model used in the implementation. Also the AEH API in the RTSJ are criticized as lacking in configurability as they do not provide any means for programmers to have fine control over the AEH facilities, such as the mapping between real-time threads and handlers. For these reasons, it needs the refactoring of its application programming interface (API) to give programmers more configurability. This paper, therefore, proposes a set of AEH related classes and interfaces to enable flexible configurability over AEH components. We have implemented the refactored configurable AEH API using the new specifications on an existing RTSJ implementation and this paper shows that it allows more configurability for programmers than the current AEH API in the RTSJ does. Consequently programmers are able to specifically tailor the AEH subsystem to fit their applicationspsila particular needs.

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.

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.

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.

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

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.

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

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

Real-time systems are notoriously difficult to design and implement, and, as many real-time problems are safety-critical, their solutions must be reliable as well as efficient and correct. While higher-level programming models (such as the Real-Time Specification for Java) permit real-time programmers to use language features that most programmers take for granted (objects, type checking, dynamic dispatch, and memory safety) the compromises required for real-time execution, especially concerning memory allocation, can create as many problems as they solve. This paper presents Scoped Types and Aspects for Real-Time Systems (STARS) a novel programming model for real-time systems. Scoped Types give programmers a clear model of their programs’ memory use, and, being statically checkable, prevent the run-time memory errors that bedevil the RTSJ. Adopting the integrated Scoped Types and Aspects approach can significantly improve both the quality and performance of a real-time Java systems, resulting in simpler systems that are reliable, efficient, and correct.

Both Java and the Real-time Specification for Java contain concurrency-related constructs that are easily abused or simply misunderstood by a programmer without sufficient knowledge of multi-threading. This article lists a number of those constructs and shows how they are avoided in Ada. Many of the mistakes arise when a programmer confuses exclusion synchronization and condition synchronization. The article opens with an explanation of those concepts.