Real-Time Specification For Java Research Articles

Java in Robotics: Bridging Software Development and Hardware Control

This research examines how Java bridges robotics software development with hardware control. The main goals are to assess Java's performance in robotic system integration, identify its drawbacks, and suggest ways to improve it. JRobotics, LeJOS, and ROSJava, are reviewed using secondary data to determine their effects on hardware interface, real-time performance, and data processing. According to major studies, Java's platform freedom and modularity enable software and hardware integration. Real-time performance, hardware interface, and memory management remain issues. The Real-Time Specification for Java (RTSJ) and specialized libraries provide partial solutions but need additional development. Policy implications include investing in Java library improvements and improving Java developer-robotics researcher cooperation. Research and optimization will improve Java's position in robotics, making robots more efficient and versatile.

Research and Application of the IOT Gateway Based on the Real-Time Specification for Java

The Internet Of Things (IOT) gateway plays an important role in connecting the traditional information network and network aware, in view of the present people use outdated development ways to realize Internet gateway software proposed a scheme of using real-time Java technology. This paper uses ARM cortex-A57 architecture of AMD Opteron 1100 processor as the core to build IOT gateway system hardware platform, through the gateway to realize remote monitoring of underlying device. The IOT gateway adopts "Internet + Sensor Network / FieldBus Technology" network schemes to realize wired / wireless data exchange, and use the fully compatible Real-Time Specification for Java (RTSJ) of the WebSphere Real Time development platform to achieve the Internet gateway protocol conversion and the design of the two layers network communication software to ensure the IOT gateway security real-time communication. Finally, this paper gives the implementation technique and application of the gateway.

Eliminating object reference checks by escape analysis on real-time Java virtual machine

The real-time specification for Java (RTSJ) makes Java to be a real-time programming language. However, the RTSJ’s memory management system is more complicated than J2SE’s. The assignment rules of RTSJ, which prevent the creation of dangling references, must be checked by real-time Java virtual machines (JVMs) at run-time. These frequent run-time object reference checks introduce significant time overheads and unpredictable execution time, which has great impact on real-time systems. This paper presents an equivalence class based, context sensitive and flow insensitive escape analysis algorithm that effectively eliminates unnecessary run-time reference checkpoints of RTSJ programs. The optimization framework has been implemented in an open-source real-time JVM namely jRate and evaluated by CD$$_x$$, a relative authority real-time Java benchmark suite. The results show that this optimization algorithm eliminates more than 90% static reference checkpoints, removes about 50% run-time reference checkpoints on average , and improves the run-time performance of average 3.13%, max 8.93%.

Resource management policies for real-time Java remote invocations

A way to deal with the increasing cost of next generation real-time applications is to extend middleware and high-level general-purpose programming languages, e.g. Java, with real-time support that reduces development, deployment, and maintenance costs. In the particular path towards a distributed real-time Java technology, some important steps have been given into centralized systems to produce real-time Java virtual machines. However, the integration with traditional remote invocation communication paradigms is far from producing an operative solution that may be used to develop final products. In this context, the paper studies how The Real-Time Specification for Java (RTSJ), the leading effort in real-time Java, may be integrated with Java’s Remote Method Invocation (RMI) in order to support real-time remote invocations. The article details a specific approach towards the problem of producing a predictable mechanism for the remote invocation–the core communication mechanism of RMI–via having control on the policies used in the remote invocation. Results obtained in a software prototype help understand how the key entities defined to control the performance of the remote invocation influence in the end-to-end response time of a distributed real-time Java application.

Diseño de un Software de Intermediación de Comunicación para Sistemas Distribuidos de Tiempo Real Críticos en Java

Distributed real-time embedded systems are becoming increasingly important to society. More demands will be made on them and greater reliance will be placed on the delivery of their services. A relevant subset of them is high-integrity or hard real-time systems, where failure can cause loss of life, environmental harm, or significant financial loss.Additionally, the evolution of communication networks and paradigms as well as the necessity of demanding processing power and fault tolerance, motivated the interconnection between electronic devices; many of the communications have the possibility of transferring data at a high speed. The concept of distributed systems emerged as systems where different parts are executed on several nodes that interact with each other via a communication network.Java's popularity, facilities and platform independence have made it an interesting language for the real-time and embedded community. This was the motivation for the development of RTSJ (Real-Time Specification for Java), which is a language extension intended to allow the development of real-time systems. The use of Java in the development of high-integrity systems requires strict development and testing techniques.However, neither RTSJ nor its profiles provide facilities to develop distributed real-time applications. This is an important issue, as most of the current and future systems will be distributed. The Distributed RTSJ (DRTSJ) Expert Group was created under the Java community process (JSR-50) in order to define appropriate abstractions to overcome this problem. Currently there is no formal specification.The aim of this work is to describe the design and develop a communication middleware that is suitable for the development of distributed hard real-time systems in Java, based on the integration between the RMI (Remote Method Invocation) model and the HRTJ profile. It has been designed and implemented keeping in mind the main requirements such as the predictability and reliability in the timing behavior and the resource usage.The design starts with the definition of a computational model which identifies among other things: the communication model, most appropriate underlying network protocols, the analysis model, and a subset of Java for hard real-time systems. In the design, the remote references are the basic means for building distributed applications which are associated with all nonfunctional parameters and resources needed to implement synchronous or asynchronous remote invocations with real-time attributes.The proposed middleware separates the resource allocation from the execution itself by defining two phases and a specific threading mechanism that guarantees a suitable timing behavior. It also includes mechanisms to monitor the functional and the timing behavior. It provides independence from network protocol defining a network interface and modules. The JRMP protocol was modified to include two phases, non-functional parameters, and message size optimizations. Although serialization is one of the fundamental operations to ensure proper data transmission, current implementations are not suitable for hard real-time systems and there are no alternatives. This work proposes a predictable serialization that introduces a new compiler to generate optimized code according to the computational model. The proposed solution has the advantage of allowing us to schedule the communications and to adjust the memory usage at compilation time.In order to validate the design and the implementation a demanding validation process was carried out with emphasis in the functional behavior, the memory usage, the processor usage (the end-to-end response time and the response time in each functional block) and the network usage (real consumption according to the calculated consumption).

Simulation of safety-critical, real-time Java: A case study of dynamic analysis of scoped memory consumption

For critical, real-time applications, scoped memory management in Real-Time Specification for Java (RTSJ) achieves a level of predictability not found in applications that use garbage collection techniques. However, a scoped memory model creates new challenges for developers. First, the reference rules between scopes constrain the design of the application’s memory model. Second, there is no abstract model for scoped memory that can be applied to different applications. Third, deciding on the appropriate number of scopes and which objects or threads should be allocated into those scopes are not straightforward tasks and require tools to assist. This paper presents a simulation of a railway control system executed on the Sun RTS2.2 virtual machine; it illustrates how simulation of critical safety real-time applications in Java can be used to investigate the implementation of possible scoped memory design models and their memory consumption in multi-threaded environments. The simulation demonstrates that a developer is able to compare and choose the most appropriate scoped memory design model that achieves the least memory footprint. Results showed that the memory design model with a higher number of scopes achieved the least memory footprint. However, the number of scopes per se does not always indicate a satisfactory memory footprint; choosing the right objects/threads to be allocated into scopes is an important factor to be considered.

Region-Based RTSJ Memory Management: State of the art

Developing a real-time system in Java requires awareness of memory behaviour in addition to software functional requirements. The Real-Time Specification for Java (RTSJ) introduces a scoped memory model to avoid garbage collection delays in critical real-time applications which need to meet hard real-time constraints. Scoped memory management has certain advantages over garbage collection in terms of predictability. However, developing a real-time application using scoped memory areas (regions) may suffer from both design and runtime errors. Moreover, from a memory footprint perspective, the inability to determine precisely how many scoped memory areas should be used and which objects or threads should be allocated into these scoped memory areas makes using RTSJ problematic for developing real-time systems. In this paper, a survey of the current approaches to improve scoped memory management and new emerging challenges in RTSJ scoped memory management model are presented. Categorizing those problems and challenges provides a picture of the issues researchers have yet to investigate and to support solutions for an optimal scoped memory model. Current approaches and a set of benchmarks used to evaluate current solutions are presented and new research questions in developing real-time Java systems using a scoped memory model are proposed.

A Dual Programming Model for Distributed Real-Time Java

More-and-more, the use of Java as a programming language for real-time applications is becoming of interest in industrial middleware. This is mainly because it offers advantages for the programmer as reduced deployment times, increased portability, and a number of APIs that may be integrated in large distributed applications. This paper contributes a dual communication model for distributed real-time Java applications. Current efforts in distributed real-time Java [e.g., The Distributed Real Time Specification for Java (DRTSJ)] are mainly focused on remote invocations (R.I.) and set aside other valuable approaches such as distributed events. The proposed model offers two choices for developing distributed real-time Java applications (one based on R.I., and another on distributed events), which may be used to develop applications. Both models include an additional support for asynchronism in communications, a feature that may speed up their communication performance. This paper includes a description for the two models, the changes that are required in the current API to accommodate them, and an empirical evaluation of their performance on a reference implementation.

A Hardware Abstraction Layer in Java

Embedded systems use specialized hardware devices to interact with their environment, and since they have to be dependable, it is attractive to use a modern, type-safe programming language like Java to develop programs for them. Standard Java, as a platform-independent language, delegates access to devices, direct memory access, and interrupt handling to some underlying operating system or kernel, but in the embedded systems domain resources are scarce and a Java Virtual Machine (JVM) without an underlying middleware is an attractive architecture. The contribution of this article is a proposal for Java packages with hardware objects and interrupt handlers that interface to such a JVM. We provide implementations of the proposal directly in hardware, as extensions of standard interpreters, and finally with an operating system middleware. The latter solution is mainly seen as a migration path allowing Java programs to coexist with legacy system components. An important aspect of the proposal is that it is compatible with the Real-Time Specification for Java (RTSJ).

Non‐functional information transmission patterns for distributed real‐time Java

SUMMARYMany real‐time systems use preemptive priority‐based scheduling in their internals to guarantee certain real‐time performance. This includes technologies that range from The Real‐Time Specification for Java (RTSJ) to middleware like Real‐Time Common Object Request Broker Architecture (RT‐CORBA), which offers additional models and policies that blend client and server information. This decision eases the integration of real‐time admission tests and dispatching policies in these types of infrastructures. In this paper, we analyze different trade‐offs that emerge from the definition of different propagation models for distributed real‐time Java. The paper covers technological integration aspects as impact on interfaces and other practical issues mainly related to the performance that this model offers to a real‐time application and non‐functional overhead. The contribution described in the paper may help in the development of The Distributed Specification for Java (DRTSJ). Copyright © 2011 John Wiley & Sons, Ltd.

Asynchronous event handling and Safety Critical Java

SUMMARYOver the last few years, the Java Community Process (under the auspices of Java Specification Request 302) has been developing a subset of Java augmented by the Real‐Time Specification for Java (RTSJ) for use in safety critical systems. The concurrency model supported by Safety Critical Java (SCJ) relies almost exclusively on an event‐based model rather than on a thread‐based model. This paper reviews the advantages and disadvantages of the two models and gives the pragmatic reasons that SCJ has adopted the former model. It describes the SCJ approach and gives a simple example of how it can be used, illustrating the difference in style between the RTSJ and SCJ code. The paper then considers the compatibility of the SCJ model with the RTSJ. It argues that by basing the SCJ classes on the RTSJ's BoundAsyncEvent class, some inconsistencies exist between the SCJ and the RTSJ models. Furthermore, some of the optimizations that are possible when mapping handlers to server threads are inhibited, even though the programming restrictions necessary for these optimizations are imposed by the SCJ specification. A revised model is presented that has a slightly more complicated API but is more consistent with the RTSJ and allows the optimizations. However, there is a resulting increase in the necessary run‐time support, particularly for multiprocessor implementations. Copyright © 2011 John Wiley & Sons, Ltd.

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

An RTSJ-based framework for model-driven development in distributed control and automation

The development process of control and automation software appears to be unsatisfactory and many years behind the general-purpose software development process. Moreover, current software engineering practices cannot be applied without modifications to the control and automation domain. In this paper, the model-driven development (MDD) paradigm is adopted to define a framework for the development of control and automation software. The proposed framework integrates an evolving domain-specific modelling language with the emerging real-time specification for Java (RTSJ) to exploit the benefits of Object and Java technologies. An implementation model framework and a run-time environment are defined to allow function block (FB) based design specifications to be automatically transformed to RTSJ executable ones. The recently released IBM RTSJ implementation is used to demonstrate the effectiveness of the proposed framework. Performance measurements show the applicability of the proposed approach in the control and automation domain.

Using Sun’s Java Real-Time System to Manage Behavior-Based Mobile Robot Controllers

Implementing a robot controller that can effectively manage limited resources in a deterministic, real-time manner is challenging. Behavior-based architectures that decompose autonomy into levels of intelligence are popular due to their robustness but do not provide real-time features that enforce timing constraints or support determinism. We propose an architecture and approach for using the real-time features of the Real-Time Specification for Java (RTSJ) in a behavior-based mobile robot controller to show that timing constraints affect performance. This is accomplished by extending a real-time aware architecture that explicitly enumerates timing requirements for each behavior. It is not enough to reduce latency. The usefulness of this approach is demonstrated via an implementation on Solaris 10 and the Sun Java Real-Time System (Java RTS). Experimental results are obtained using a K-team Koala robot performing path following with four composite behaviors. Experiments were conducted using several task period sets in three cases: real-time threads with the real-time garbage collector, real-time threads with the non- real-time garbage collector, and non-real-time threads with the non-real-time garbage collector. Results show that even if latency and determinism are improved, the timing of each individual behavior significantly affects task performance.

Extending the concurrency model of the real‐time specification for Java

AbstractThe current RTSJ (Real‐Time Specification for Java) threading model is dualized: a programmer has to decide between the high predictability offered by the region‐based model and the flexibility offered by the garbage collection. So far, there is no unique type of thread which offers both the high predictability of a non‐heap thread and the flexibility of a real‐time thread in a single entity. Furthermore, this lack has a serious impact on the programmer who has to deal with new and sometimes non‐trivial to use mechanisms, such as specific queues of objects or new types of threads, in order to avoid the priority inversion caused by the garbage collector. In order to tackle the concern properly and provide an improved and more generalized programming model, the authors propose a simple extension to the current threading model named RealtimeThread++, in an attempt to introduce more flexibility in the RTSJ concurrency model. The paper describes the extension from several points of view: (i) the programmer, identifying scenarios that may benefit from it significantly; (ii) the real‐time Java technology perspective, identifying changes required in the current real‐time virtual machine to support it; and (iii) the accumulated experience, relating empirical results obtained from a software prototype that supports the extension. Copyright © 2010 John Wiley & Sons, Ltd.

Quantitative dynamic‐memory analysis for Java

AbstractSpace‐ and time‐predictability are hard to achieve for object‐oriented languages with automated dynamic‐memory management. Although there has been significant work to design APIs, such as the Real‐Time Specification for Java (RTSJ), and to implement garbage collectors to enable real‐time performance, quantitative space analysis is still in its infancy. This work presents the integration of a series of compile‐time analysis techniques to help predicting quantitative memory usage. In particular, we focus on providing tool assistance for identifying RTSJ scoped‐memory regions, their sizes, and overall memory usage. First, the tool‐suite synthesizes a memory organization where regions are associated with methods. Second, it infers their sizes in parametric closed form in terms of relevant program variables. Third, it exhibits a parametric upper bound on the amount of available free memory required to execute a method. The experiments carried out with a RTSJ benchmark, a real‐time aircraft collision detector, show that semi‐automatic, tool‐assisted generation of scoped‐based code is both helpful and doable. Copyright © 2010 John Wiley & Sons, Ltd.

Applying fixed‐priority preemptive scheduling with preemption threshold to asynchronous event handling in the RTSJ

AbstractThe primary goal of asynchronous event handlers (handlers for short) in the Real‐Time Specification for Java (RTSJ) is to have a lightweight concurrency mechanism. The emphasis here is on ‘lightweightness’ which should be achieved by having fewer real‐time threads (servers for short) to execute more handlers. However, it is generally unclear how to efficiently map handlers to servers. In this paper we first define the worst case scenario that demands the least upper bound of servers for self‐suspending and non‐self‐suspending handlers. Based on the worst case scenarios, it is proved that the number of servers required to execute a given number of non‐self‐suspending handlers depends on the number of priority levels, and not on the number of handlers. It is also shown that each self‐suspending handler is required to have its own server to prevent unbounded priority inversion. Based on these results we also propose to adapt the notion of preemption threshold to further minimize the number of priority levels in the system. We have extended the non‐self‐suspending asynchronous event handling (AEH) implementation to support the fixed‐priority scheduling with preemption threshold on an existing RTSJ implementation to show that the number of servers can be further decreased while feasibly scheduling a set of non‐self‐suspending handlers, regardless of the number of the handlers or the priority levels in the system. Copyright © 2010 John Wiley & Sons, Ltd.

Efficient asynchronous event handling in the real-time specification for Java

The Real-Time Specification for Java (RTSJ) is becoming mature. It has been implemented, formed the basis for research and used in serious applications. Some strengths and weaknesses are emerging. One of the areas that requires further elaboration is asynchronous event handling (AEH). The primary goal for handlers in the RTSJ is to have a lightweight concurrency mechanism. Some implementation will, however, simply map a handler to a real-time thread and this results in undermining the original motivations and introduces performance penalties. However it is generally unclear how to map handlers to real-time threads effectively. Also the support for nonblocking handlers in the RTSJ is criticized as lacking in configurability as implementations are unable to take advantage of them. This article, therefore, examines the AEH techniques used in some popular RTSJ implementations and proposes two efficient AEH models for the RTSJ. We then define formal models of the RTSJ AEH implementations using the automata formalism provided by the UPPAAL model checking tool. Using the automata models, their properties are explored and verified. In the proposed models, blocking and nonblocking handlers are serviced by different algorithms. In this way, it is possible to assign a real-time thread to a handler at the right time in the right place while maintaining the fewest possible threads overall and to give a certain level of configurability to AEH. We also have implemented the proposed models on an existing RTSJ implementation, jRate and executed a set of performance tests that measure their respective dispatch and multiple-handler completion latencies. The results from the tests and the verifications indicate that the proposed models require fewer threads on average with better performance than other approaches.

A framework for flexible scheduling in the RTSJ

This article presents a viable solution to introducing flexible scheduling in the Real-Time specification for Java (RTSJ), in the form of a flexible scheduling framework. The framework allows the concurrent use of multiple application-defined scheduling policies, each scheduling a subset of the total set of threads. Moreover, all threads, regardless of the policy under which they are scheduled, are permitted to share common resources. Thus, the framework can accommodate a variety of interworking applications (soft, firm, and hard) running under the RTSJ. The proposed approach is a two-level scheduling framework, where the first level is the RTSJ priority scheduler and the second level is under application control. This article describes the framework's protocol, examines the different types of scheduling policies that can be supported, and evaluates the proposed framework by measuring its execution cost. A description of an application-defined Earliest-Deadline-First (EDF) scheduler illustrates how the interface can be used. 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 is that it supports preemptive priority-based dispatching of threads and that changes to priorities have immediate effect.

Measuring and policing blocking times in real-time systems

In real-time systems, the execution-time overrun of a thread may lead to a deadline being missed by the thread or even others threads in the system. From a fault tolerance perspective, both execution time overruns and deadline misses can be considered timing errors that could potentially cause a failure in the system's ability to deliver its services in a timely manner. In this context, the ideal is to detect the error in the system as soon as possible, so that the propagation of the error can be limited and error recovery strategies can take place with more accurate information. The run-time support mechanism usually deployed for monitoring the timing requirements of real-time systems is based on deadline monitoring, that is, the system calls specific application code whenever a deadline is violated. Recognizing that deadline monitoring may not be enough for providing an adequate level of fault tolerance for timing errors, major real-time programming standards, like Ada, POSIX and the Real-Time Specification for Java (RTSJ), have proposed different mechanisms for monitoring the execution time of threads. Nevertheless, in order to provide a complete fault tolerance approach for timing errors, the potential blocking time of threads also has to be monitored. In this article, we propose mechanisms for measuring and policing the blocking time of threads in the context of both basic priority inheritance and priority ceiling protocols . The notion of blocking-time clocks and timers for the POSIX standard is proposed, implemented and evaluated in the open-source real-time operating system MaRTE OS. Also, a blocking time monitoring model for measuring and policing blocking times in the RTSJ framework is specified. This model is implemented and evaluated in the (RTSJ-compliant) open-source middleware jRate, running on top of MaRTE OS.