This RFI response comes from a group of researchers at the University of Rhode Island and the U.S Navy’s NRaD laboratories. For the past 3+ years we have been developing a project called the Distributed Hybrid Database Architecture, which is designed to allow,

among other things, real-time access to distributed real-time databases through a CORBA environment. Developing real-time extensions to CORBA, within the open systems philosophy of adhering to standards such a CORBA and POSIX, has been a major effort in this project.

This RFI summarizes our current work, most of which is published in the accompanying five supporting documents (we refer to these as "Supporting Doc 1, Supporting Doc 2, etc. in the rest of this paper).

All of these documents and other work on real-time object-oriented databases, real-time object modeling, and CORBA can be found at our Web site:

The remainder of this RFI response follows the outline of Section 4 of the RFI.

Our requirements are derived primarily from military C3I applications, with which we have had extensive experience. Members of our team have been developing military C3I applications at NRaD for many years. Other members of our team have worked closely with the Naval Undersea Warfare Center and Lockheed/Martin in the development of

the C3I system of the Navy’s New Attack Submarine. Many of the New Attack submarine C3I requirements are described in Supporting Document 3. We just list our RT CORBA requirements in this section of our RFI response; we specify more details and justifications in Section 3 of Supporting Document 1 and in pages 25-32 of Supporting Document 2. The requirements of a RT CORBA system are:

1. A CORBA types for timing constraints, time, scheduling information, and quality-of-service.
1. Transmittal of real-time and quality-of-service requirements with method requests.
1. Use of a global priority by clients and servers.
1. Priority-based queuing and scheduling throughout the CORBA system.
1. Real-time events - that have the time that event occurred and have priority handling of events.
1. Priority inheritance in concurrency control and queuing.
1. Performance Polymorphism to support quality-of-service.
1. Real-time exceptions to allow handling of violations of timing and quality-of-service constraints.
1. Use of real-time operating systems with RT POSIX features.
1. Use of networks that support guarantees and/or high-confidence estimates of latencies.
1. Dynamic task allocation to nodes (a real-time "bind" based on quality-of-service).

Our approach to providing real-time capabilities in military C3I systems is to use a commercial off-the-shelf (COTS) ORB and Services that operate on a COTS operating system that adheres to the POSIX 1003.c standard, all of which are connected by a COTS network, preferably ATM. With this as a baseline, we have extended the CORBA system, as closely as possible within the OMG CORBA architecture, to support real-time. Our extensions take the form of libraries and header files, IDL files, for inclusion with CORBA clients and servers, some modifications to the ORB which have been implemented on Orbix using "filters", and several new Object Services to support real-time

Our approach to designing the (distributed, real-time) C3I system of the US Navy’s New Attack Submarine is described in Supporting Document 3.

We suggest that real-time CORBA technologies be grouped into the following four categories:

• Category 1 – Fixed participant set? Are the clients and servers predetermined at system startup, or can they dynamically come and go?
• Category 2 - Hard vs Soft Real-time. (We understand that time value is a more general way to express this Category but simply:) Does the CORBA system have to guarantee predictable timing behavior, or is best-effort sufficient?
• Category 3 - Performance. Does the CORBA system have to be stripped down to be optimized for fast performance (e.g. are some services by-passed to improve performance)?
• Category 4 – Exclusively Periodic Tasks? Are aperiodic clients allowed?

Most of our work has been in Dynamic, Soft Real-time that allows aperiodic tasks and has only limited parts of the application requiring high-performance. Thus, we believe that the requirements that we list in this RFI should be grouped under this characterization of RT CORBA categories.

Our prototype architecture consists of two workstations running POSIX 1003.1c compliant operating systems, connected by (preferably) an ATM network, with all entities in the system participating in a COTS CORBA system. Our current prototype uses Solaris 2.5 for the operating systems (on Sun Sparcs) and Orbix 2.0.1 MT as the CORBA software. The CORBA software has been extended with RT CORBA features described throughout this RFI response.

The more involved architecture of the Navy’s New Attack Submarine is described in Supporting Document 3.

Technology Dependencies

All of our extensions to CORBA and use of CORBA in C3I applications make the following assumptions:

• All nodes in the CORBA environment are using operating systems compliant with IEEE POSIX 1003.1c (real-time and multi-threading). In particular, we require priority-based CPU scheduling, multi-threading, semaphores, mutexes and condition variables, per-thread timers, shared memory, sockets and/or message queues, signal handling and control. These are detailed on pages 25-27 of Supporting Doc 2, and Section 3.2.1 of Support Doc 1.
• The network provides high-confidence estimates and/or guarantees of message latency. Page 26 of Supporting Doc 2 details this requirement. Section 3.2.1 of Supporting Doc 1 also mentions this dependency. All of Supporting Doc 4 addresses this issue by developing a Latency Service for an ATM network that allows clients or the ORB to query for latency information. Note that ATM is not required, but that it is the most promising network technology that we have found for providing the latency estimates and/or guarantees that are necessary.
• Clocks in the CORBA system are synchronized. This dependency is detailed on page 25 of Supporting Doc 2, and Section 3.2.1 of Supporting Doc 1. A solution to this using the NTP is presented on page 9 of Supporting Doc 5.
• Timed Distributed Method Invocations. This capability, its importance, and its many aspects are the subject of Supporting Doc 1. Aspects of this capability are detailed in Supporting Doc 2 on page 26 (Time Type, and Transmittal of real-time method invocation information) and page 27 (Real-Time Exceptions) . Implementation of this capability is the subject of Supporting Document 5.

We have been very careful in our work to stay within the OMG specifications whenever possible. For instance, our work has not changed the IDL language at all. Our changes to existing ORBs are relatively minor and focus on transmittal of real-time information and on enforcement of priority queuing at all places in the ORB. We have prototyped all ORB modification in Orbix without access to source code, but with minor additions as Orbix "filters", which indicates that our ORB modifications are relatively minor. We have modified two existing services (Event, and Concurrency Control), but have preserved their original interface and made only small, well-justified, extensions to their interface. Our modifications to the service semantics, however, are more substantial, as warranted by the new semantics required by real-time. We also have developed several new services (Global Priority, Global Time, Latency) and have preliminary designs for two others (ORB Guarantee Service, Real-Time Bind). We summarize these extensions and modifications here:

Real-time manager. The RT manager is a C++ class with most of the capabilities for Timed Distributed Method Invocations. It is described on page 8 of Supporting Doc 5.

Real-time Environment. The RT environment is a structure that we have defined and then specified in OMG IDL. We envision that this would be a standard type definition in RT CORBA systems. This structure is described on page 9 of Supporting Doc 5.

Real-Time Exceptions. Real-time exceptions are generated within the CORBA exception mechanism for violations of real-time and quality-of-service constraints specified in the RT Environment. The implementation of RT Exceptions is described on page 8 of Supporting Document 5.

Global Time Service. The global time service requires synchronized clocks and allows clients to query for the current time and be assured that the time is common (to within a bounded skew) and understood by all objects in the CORBA environment. This service is described on page 9 of Supporting Document 5.

Global Priority Service. This service translates timing-constraints (e.g. deadlines), importance specifications, and quality-of-service specifications to a single priority number that is meaningful relative to all priorities in the CORBA system. We have further augmented this service to all priorities to "age", which means that priorities increase as time passes, to allow for implementing dynamic earliest-deadline-first scheduling. The Global Priority Service is described on page 10 of Supporting Doc 5.

Distributed Real-Time Scheduling. This ORB modification requires that the ORB and all operating systems, networks, and other resource managers enforce priority-based scheduling and queuing using the global priority assigned by the Global Priority Service. Note that with appropriate choices of Global Priority assignment, that rate-monotonic scheduling can be performed.

Real-Time Event Service. This service extends the CORBA 2.0 Event Service by allowing events to indicate the time at which they occurred (for use in establishing timing

constraints relative to the events), and by allowing for prioritized events based on the Global Priorities described above. The RT Event Service is described on page 12 of Supporting Doc 5.

Real-Time Concurrency Control Service. This service extends the CORBA 2.0 Concurrency Control Service by allowing for priority inheritance (based on Global Priority), It is described on page 14 of Supporting Document 5.

Network Latency Service. This service allows for high-confidence estimates of message latency in a CORBA system. Currently it has been implemented on an ATM network with Orbix. . The service is described in Section 4 of Supporting Doc 4.

Real-Time Bind. This service has not been fully designed nor implemented, but is current work. It will provide for an "intelligent" bind which finds the appropriate server to which to bind a client based on real-time and quality-of-service specifications, including performance polymorphism. Performance Polymorphism is described on page 30 of Supporting Doc 2. We expect this service to be developed by the end of 1998.

As stated in the last section, all of our work relates to the ORB and Services, sometimes as extensions, sometimes as modifications, some times as new entities (Services). The details of these relationships are covered in our response on the previous page.

IEEE POSIX. As described in the previous "Dependencies" section of this RFI response, we assume that all operating systems are compliant with IEEE POSIX 1003.1c (real-time and multi-threaded operating system standard). We need many of the capabilities specified in this standard.

ATM. Although not required, the network latency server work we did assumes a network compliant with the ATM standard.

IP/Multicast. Our RT Event Service assumes IP/multicast capabilities (and eventually a reliable IP/multicast protocol).

SQL. Although not directly part of our RT CORBA work, we have done substantial work on extending SQL for real-time (and are original members and whitepaper authors of the ANSI working group on RT SQL). Supporting Doc 3 describes the use of CORBA to "wrap" a real-time database with an SQL standard wrapper. ODMG compliance is also interesting since much of our work has been in real-time object-oriented databases, but we have not investigated it fully yet.

The major limitation of our RT CORBA technology is its relative immaturity. We have a prototype system, built on Orbix, for most of the extensions that we have described (all except the RT Bind). We are working on integrating it into real C3I systems like the US Navy’s Next Attack Submarine, and the US Joint Forces JFLEX planning tool, but these systems do not employ our RT CORBA software yet.

Another limitation is that the new technology is not necessarily fast. Whenever possible, we tried to optimize our software for speed, since speed is often necessary in a real-time system. However, our approach has been that a fast CORBA environment may be necessary is some circumstances, but that it is often not sufficient. Enforcement of timing constraints can be a sufficient achievement. Thus, our work places higher importance on the specification and enforcement of timing constraints, than on fast computing. Consequently, our technology may not be suitable for high-speed applications. Performance numbers for ATM messages are included in Supporting Doc 4, but performance numbers for the other services are being done now and are expected in two URI Master’s thesis reports by the end of May 1997.

The status of our project is:

• We have published the supporting documents that are included.
• We have designed and prototyped all extensions described here, except for the Real-time Bind.
• We have initiated the project to design and prototype the Real-Time Bind service.
• We are performing tests on the prototype. These test results, along this detailed descriptions of the software, will be published in two URI Master’s thesis reports in May 1997.
• The RT CORBA software and documentation (including Unix Man pages) will be placed on our Web site and on a CD in April 1997. This software is entered in the "Orbix Awards" competition for CORBA software sponsored by Iona. We will deliver this all to Iona on April 1, 1997.
• We are integrating aspects of this work, particularly the ATM work, into the US Navy’s New Attack Submarine C3I system through the Naval UnderSea Warfare Center.
• We have initiated a project to implement the US Department of Defense Joint Forces JFLEX planning software on the RT CORBA System.
• We have wrapped a commercial real-time database in a CORBA environment and have initiated a project to wrap our real-time object-oriented database in our RT CORBA environment.

What are relevant RT features? This has been covered in the rest of this document.

What features support scalability to large numbers of objects? The fact that we allow a dynamic system in which objects can come and go, provides more flexibility for handling large numbers of objects than fixed, predetermined real-time systems. Also, all of our scheduling and queuing is dynamic and priority-based, so that it is not dependent on the number of clients or servers. In general, we believe our approach scales as well as CORBA itself. It may even scale better since it supports quality-of-service (described below) which allows for flexible, intelligent reduction of QoS when scaling causes excessive demand for resources.

What is our approach to modularity? Our main approach has been to adhere to open system philosophy: stay within standard interfaces where possible and assume underlying standard interfaces when possible. This supports modularity by facilitating plug-and-play of modules. We however, realize that we could go further in this area and have initiated discussions with Peter Krupp’s group at MITRE towards incorporating our work into their "frameworks" highly-modular CORBA.

What is our approach to QoS? We allow for specification of QoS parameters in the RT environment that gets passed with all requests. Currently, this specification is unused since we have not defined QoS parameters for servers yet. We also allow for QoS specifications on servers as described in Section 3.1 of Supporting Doc 1 and page 31 of Supporting Document 2. We further propose to support QoS through "performance polymorphism" where the ORB can select which method to invoke based on system state and QoS requirements. Performance polymorphism is described on page 30 of Supporting Doc 2. Our philosophy of QoS is described on page 22 od Supporting Doc 2.

We allow for QoS to be incorporated into our generation of a Global Priority, as described on pages 10-12 of Supporting Doc 5.

What is the relationship between the ORB and the OS and Communication System? The ORB must work with the OS and communication system to enforce global priority scheduling and queuing at all points. Our real-time extensions to the ORB assume real-time capabilities in the OS (all from POSIX 1003.1c) as described in several places in this response paper.

Is the technology compliant with CORBA 2.0? Yes, with extensions, as detailed throughout this response paper.

What is our approach to interoperability between RT and non-RT systems? We have had this listed as a requirement from the beginning, but are trying to understand and develop real-time first. Thus, we have no current concrete approach.

Is the technology integrated with existing commercials ORBs? Yes, with Orbix. We are giving our source code to Iona in April for them to consider for incorporation into their products.