What is Real-time CORBA?

See also:  What is CORBA?

CORBA, as a standard, has continued to evolve over the last decade, and has been accepted by many industries as the preferred middleware solution as evidenced by the large industry involvement within the Object Management Group (OMG). Some of the most exciting standards development has come from the Real-time, Embedded, and Specialized Systems Platform Task Force of the Object Management Group in the form of CORBA enhancements designed for the real-time and embedded developer.

A team of diverse companies, including representatives from telecommunications, aerospace, and CORBA vendors jointly authored the Real-time CORBA Specification. OIS was a key contributor in the development of the specification, co-authoring and taking a leading role in pushing the specification to completion. The development of the specification was complex as there were many different viewpoints of the concepts of soft and hard real-time requirements and what types of behavior the communication protocols needed to ensure end-to-end predictability in a real-time system. Consequently, different perceptions still exist about soft and hard real-time requirements and the components required to ensure end-to-end predictability. The end result of the standardization effort was agreement that the standard would be based on the concepts necessary to support fixed priority scheduling.

End-To-End System Predictability
However, the priority connection is only one factor, of many, in determining real-time behavior. Each system component must maintain consistent priority aware behavior. If any part of the system exhibits non-predictable behavior, it will affect the entire system. The following illustrations highlight the system components that can affect system predictability.

Fixed Priority Scheduling
Fixed priority scheduling consists of determining static priority levels for each task based on a scheduling methodology such as rate monotonic analysis (RMA) or deadline monotonic analysis. This is not to say that priorities cannot change, but that priorities are assigned at system initialization and are not changed dynamically except to manage concurrent access to a system. The secret to real-time CORBA is how to expand the notion of priority in a single processor at a system level.

Real-time CORBA introduces a piece of data called Real-time CORBA Priority. Real-time CORBA Priority specifies how to relate native operating system priority throughout the system in a consistent manner, and how to handle communication requests from the client application, through the middleware layer, over the network, and up to the server application without unexpected priority inversions. When a client invokes an operation to a server, the client's native operating system priority is mapped to a Real-time CORBA Priority, and the new priority is mapped as part of the message to the server. The following illustration shows the real-time priority mapping function of the client/server application, through a CORBA implementation.

When the Server receives a message, the server-side ORB maps the priority to the server's operating system native priority level, and invokes the operation on the server at the same relative priority level as the client. The resulting effort is a distributed priority inheritance, providing end-to-end predictability in the same manner that would be expected for an operation to occur in a single process.

Priority Banding
The Real-time CORBA Specification also introduced the concept of priority-banded connections. Priority banded connections allow the software developer to separate different types of traffic by priority, and to dedicate separate connections between the client and server for each priority "band", where a band can encompass any set of CORBA Priority levels. This allows greater predictability for traffic, where there may be a mix of real-time and non real-time data on the communications transport at any given time. Priority banding also helps to bound and minimize the chances for any priority inversions.

A critical component of system behavior is the network, with the transport mechanism selected affecting predictability and performance, as well as the Quality of Service (QoS) parameters. Since many real-time systems require either higher performance or greater predictability than currently available through TCP/IP, OIS has developed a number of proprietary methods allowing different protocols within their CORBA implementation. In the ORBexpress Product Line, we provide the ability to plug in other transports, regardless if they are streaming/non-streaming or reliable/non-reliable.

Resource Management
Real-time systems also need to manage their resources in such a way that each application is able to utilize system resources according to their needs, and in overload situations, according to priority. These resources may be operating system threads, memory, or communication endpoints, or they may be network bandwidth. The Real-time CORBA Specification provides open interfaces into the resources controlled by the CORBA middleware.

Thread Pools
The Real-time CORBA Specification has interfaces allowing applications to configure the transport and thread pools used for the servant implementation. This allows the application to ensure that high priority connections have dedicated resources, and to ensure that there are no unbounded blocking periods based on the resource usage by the lower priority applications. The introduction of the Real-time CORBA mutex as part of the standard ensures that shared resources are protected in a consistent, priority-aware manner throughout the system.

Real-Time Distributed Systems
Developing predictable, schedulable distributed systems is a special challenge for any systems developer regardless of the distribution infrastructure. Beyond the obvious dependence on the Real-Time Operating System (RTOS) to provide a predictable thread scheduling, distributed systems depend on additional systems variables beyond the scheduling of a single processor. These additional variables include the performance characteristics of other system components:

• Bus or network protocol stack implementation
• Bus or network adapter firmware
• Bus or network media

In addition, classic real-time scheduling theory such as rate monotonic analysis (RMA) does not encompass the scheduling of multiple processors, much less the scheduling of multiple processors and multiple support bandwidth. Distributed system designers face a difficult task in determining the scheduling of the processors, busses and networks for the systems.

The use of CORBA in real-time and embedded systems provides both the distributed communication as well as the framework for enabling the incremental replacement of system components. CORBA provides the location transparency for the objects within a system. This allows for changes in object location without system re-architecture. Systems can be prototyped as monolithic, simulated on a network, and deployed on an airframe bus. The location of the system objects can be determined via actual system benchmarks. CORBA also abstracts the communications transport. New products can be built with better transport technologies without rebuilding existing software.

In the past, real-time CORBA had difficulty in achieving deterministic characteristics within a given system architecture. However, new generation ORBs, such as ORBexpress, have been designed specifically to minimize the ORB memory footprint and bound the latencies inherent within a system.

Predictable CORBA
Most of the challenge in building a predictable ORB is the inherent difficulties in building any type of predictable distributed systems. An ORB designed, implemented, and tested with predictable behavior as a primary goal can provide system developers the requisite support for developing and deploying schedulable distributed systems.

The OMG has continued to advance these efforts by introducing and enhancing CORBA standards targeted for those systems requiring predictable behavior, such as embedded and real-time systems.

Soft Real-Time CORBA
Soft real-time systems favor optimization of typical performance over worst-case performance, and typically do not require definite upper bound latency on the operations. The soft real-time ORBs typically strive for high throughputs and provide some type of mechanism to control resources. While priority inversions should usually be avoided, but in this case, there is not as much emphasis within a soft real-time scenario.

Hard Real-Time CORBA
Hard real-time systems require a definite upper bound for the latency of critical operations. Developers of hard real-time distributed CORBA systems must be able to determine the least upper bound of remote operations. This is possible if the RTOS, ORB, and the transport (bus or network) all use predictable, schedulable logic. Using an unpredictable transport protocol, or a non real-time system, precludes even the most predictable ORB from achieving bounded, end-to-end invocation latencies.

However, if a well-constructed ORB is given a predictable operating system (i.e. a real-time operating system) and a deterministic transport, the expected end result is a bounded, end-to-end invocation between a client and server.

In order to achieve these bounded communication results, the ORB must:

• Respect the priorities between client and server for resolving resource contention during the processing of a CORBA invocation
• Bound the duration of thread priority inversions during end-to-end processing
• Bound the latencies of operation invocations.

Only by designing a hard real-time system, including these critical components, will the designer achieve the hard real-time results expected.