 |
 |
 |
 |
| |
|||||
|
|
|
Home > News & Events > MITRE Publications > The MITRE Digest > | |||||||||||||||||||
| RT CORBA Technology July 2001
MITRE Influences Industry Standards In operating its Federally Funded Research and Development Centers, and in accordance with its articles of incorporation, the MITRE Corporation supports its customers in the federal government with intellectual property. It does not manufacture products or provide services routinely available from industrial contractors. Instead, its research teams develop technology in the form of concepts and prototypes. To make that technology directly available to commercial companies or other organizations so that it will ultimately become available, affordable, and supportable for our sponsors—thereby increasing the value and impact of our work—MITRE engages in several different modes of technology transfer. These include sharing knowledge at conferences, licensing technologies for non-governmental use, making software available through Open Source, and influencing industry standards. An excellent example of how MITRE seeks to transfer technology by influencing industry standards is its work, primarily for the United States Air Force, with real-time CORBA
CORBA (Common Object Request Broker Architecture) is, in the words of the Object Management Group™ (OMG™), the body that has established it as a standard, "an open, vendor-independent specification for an architecture and infrastructure that computer applications use to work together over networks. Interoperability results from two key parts of the specification: OMG Interface Definition Language (OMG IDL), and the standardized protocols GIOP and IIOP. These allow a CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, to interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network." "Real time" is a term that, in the world of computing, is generally used to describe systems or problems where the value of a computation's result depends not just on its accuracy but on when it is available. A real-world example of a real-time system, the one for which MITRE has developed most of its innovations in real-time CORBA and to which MITRE has been most insistent that those innovations be applied, is AWACS—the Airborne Warning and Control System. Case Study AWACS—the Airborne Warning and Control System—was designed, with MITRE as general system engineer, to defend against a bomber threat. But by the time of production it was already clear that the Soviet Union was not going to launch a nuclear attack against the United States from an aircraft carrier sitting off the coast of North Carolina. MITRE employees were instrumental in finding another mission for AWACS—as mobile, survivable surveillance station and command and control center. Originally designed to patrol up and down the coast of the United States, AWACS aircraft would now be employed in a theater. AWACS could be sent up with a squadron of F-15s engaged in an air defense mission, with AWACS not only for looking for targets but directing its fighters against other aircraft. It could also conduct surveillance on ships at anchor or underway. Today, AWACS is even employed enforcing no-fly zones and in drug interdiction. All these activities stress the system in new ways and create an ongoing demand for greater flexibility. Unfortunately, the AWACS mission computing system was not built with the modern concept of "open architecture" so that it would be highly flexible and allow changes to be made easily. When it was first developed in the 1960s and '70s, computers could not easily survive in an aircraft. The technology of the time was such, moreover, that they had nothing near the processing capacity needed to conduct the AWACS mission effectively. So the designers of AWACS took the military version of an IBM 370 mainframe and used its architecture as a template to turn a general-purpose computer into a computer specifically designed to support the AWACS mission. Rather than using an operating system, the AWACS mission computer runs about a half-million lines of an AWACS dialect of an archaic language called Jovial directly on the IBM hardware. What today we would do through high speed, general-purpose network connections such as Ethernet and TCP/IP, AWACS does entirely with custom-designed hardware and software. To create the real-time responsiveness and the very predictable, understandable behavior over time demanded by certain aspects of its mission, the AWACS computer uses a method called a cyclic executive. A time line identifies a major cycle and several minor cycles. Programmers assign tasks to particular time slots within the cyclic executive; every x number of milliseconds the program is interrupted and starts again. They also lay out exactly which software tasks fit into which slots as they write out instructions. What this technique does not do is provide much ability to modify the software at reasonable cost. You not only need to be concerned with entering the proper function programmed into the code but with finding the place where the instructions you have written will actually be able to execute at the proper time. You also have to be concerned that you don't offset all the other times so that the other things that are necessary to happen begin to work at the wrong time. This makes the software very complicated to update in response to new mission requirements. Add the complicating factor that the system has just about run out of memory, and any change becomes problematic. Despite how well the legacy systems of AWACS actually did conduct the mission, satisfying thousands of requirements, the Air Force finally decided, about three years ago, to replace its old software and monolithic architecture to enable the mission computing system to support the AWACS program's continually evolving requirements. But replacing the entire AWACS mission software in one block upgrade was an unrealistic proposition. After all, AWACS is a weapon tasked by the commanders in charge, who expect AWACS to be up in the sky all day every day without interruption. Doing a wholesale replacement was considered extremely risky, not to speak of too expensive. So MITRE suggested an incremental approach and, together with the System Program Office, identified a series of smaller steps. Case Study For the first incremental step, the MITRE team decided to leave most of the legacy software in place but provide improved functionality in specific areas, to be implemented by attaching modern computer hardware running new software to the existing system. The primary functionality improved in the first step arose from inserting a new tracker to replace one of the weaker areas of the mission software. The tracker takes all of the sensor measurements and integrates them to form a path on the screen that the operator uses to find out where the target aircraft has come from and to guess where it's going. Using new technology, real-time UNIX, and modern computers, and introducing standards where before there were none, the team managed to build this in a way that allowed the tracker to understand and satisfy the timeliness functions and put fresh track in the database while meeting the deadlines. Other incremental changes to the system were also included: some single-board computers for the servers, a switched local area network, and additional servers and workstations. Because the Air Force couldn't afford a complete mission computing system upgrade, and because there was still a need to interface with pieces of hardware that were very time sensitive, the software needed to be able to account for that and react to those situations. So instead of using hard-coded software for the changes, the MITRE team decided upon building something more open and generic, which they defined as having what they identified as the five independencies: location independence, temporal independence, operating system independence, hardware independence, and language independence. Customizing the AWACS Computers with Open Architecture MITRE proposed and the program is designing a new architecture based on local area networking, commercial single-board computers (Power PCs), and commercial Sun and UNIX operating systems. Instead of a mainframe computer running all the AWACS mission computing functions, such as driving the user interface displays and performing tracking, weapons control, and communications, these functions would operate on different workstations. Each operator console, instead of being just a display terminal, as it is today, would be an intelligent engineering workstation. Computer-intensive tasks like the tracking function would run on their own computers; some of the other, less computer-intensive functions, like communications and weapons control, might be patched up into a separate computer called a mission computer. Instead of a single mainframe there would be one tracking computer, one mission software computer, and 14 operator workstations. Real-time (RT) CORBA is an augmentation to basic CORBA. OMG's intention in developing RT CORBA is two-fold. From a technical perspective, it provides a convenient mechanism for enabling distributed communications in time-critical environments. Using RT CORBA, an engineer can address directly the interoperability, scalability, availability, and performance issues that so frequently cripple complex, time-critical, mission-critical systems such as AWACS. From a business perspective, having RT CORBA become a widely supported, commercially available, open standard helps ensure long-term cost effectiveness and open competition, resulting in commercially available products that allow software engineers to construct systems that are more predictable in their dynamic behavior. OMG's intentions for developing RT CORBA are entirely congruent with MITRE's intention of transferring its own development of RT CORBA technology to the public sector.
MITRE was attempting to introduce the new technology into a world where new technologies are not easy accepted. MITRE was challenging the traditional contractor's approach: "I can build general purpose software and ignore the timing requirements—if it doesn't work I'll just get faster computers." That approach, particularly because they were going to be doing the replacement piecemeal, would not provide the openness, flexibility, and reliability they needed. Moreover, MITRE was truly trying to embrace acquisition reform. Instead of delivering the first software in eighteen months, team members intended, from the outset, to do lots of prototyping to discover what worked and what didn't and, every three to six months, build another iteration of the software that would eventually yield the final system. That, too, heightened the need for flexibility and generic software. If a system is to be changed every four months, it can't take four months to integrate it—that would leave no time to create any functionality or make any improvements. It would have to take days or hours to integrate, not the years most contractors were used to. This represented a profound change in business and government acquisition practice and a radically new way of introducing modern improvements into an extremely legacy-based development environment. But the Air Force agreed with MITRE, and so began the update phase known as Step One. Case Study Where did RT CORBA come from? Early on in the formulation of CORBA, MITRE recognized the value of having a standard method for performing object-oriented distributed communications. Technical attributes such as location transparency and operating system and programming language independence would be extremely useful. MITRE's Evolvable Real-Time Systems Mission-Oriented Investigation and Experimentation (MOIE), initiated in 1993, provided an early look at the issues from the perspective of our customers. Given that we have these real-time systems, like AWACS, that are expensive to maintain and in need of an architecture that would allow upgrading to be performed more cheaply and quickly, what would we have to do to make them easy to modify and evolve? MITRE very quickly began writing requirements for object-oriented design and object-oriented abstractions. Halfway into the project a few members of the team recognized that they were dealing with something a whole lot like CORBA but that had real-time behavior grafted onto it. Several of them began looking at what it would require to take the CORBA model, which already had significant engineering behind it, and extend it, adding real-time behavior. Then, in 1995, a couple of MITRE people working with a researcher from the University of Rhode Island presented a short paper at a conference in India in which they laid out some thoughts about how one could make CORBA operate in real time. That stimulated discussion in the community, which prepared a foothold for the next—and, for MITRE, critical—step. MITRE has for a considerable time been a highly visible and influential non-vendor member of the Object Management Group™ (OMG™). Founded by 11 companies in 1989 "to create a component-based software marketplace by hastening the introduction of standardized object software," OMG now has over 800 members. Its charter includes establishing "industry guidelines and detailed object management specifications to provide a common framework for application development. Conformance to these specifications will make it possible to develop a heterogeneous computing environment across all major hardware platforms and operating systems." In addition to the MITRE employees who serve on or chair Special Interest Groups (SIGs), Dr. Mark Maybury, Executive Director of MITRE's Information Technology Center, is a member of OMG's Architecture Board, which manages the consistency and technical integrity of work produced by the other main OMG bodies. Around a year after their paper, those two MITRE employees joined in a petition to OMG to establish a SIG to develop specifications so that OMG could publish standards for real-time extensions to CORBA. Getting the SIG established involved lobbying at meetings as well as going to member companies and winning their support. OMG is a consensus-based organization; the organization does nothing that its members don't want it to do. After a gestation period of about nine months, the RT SIG held its first meeting in July 1996. During the first year and a half, with a MITRE person co-chairing and another MITRE person one of the most active contributors, the SIG put out a white paper describing proposed characteristics of real-time CORBA. An Emerging Standard Doug Jensen, a Consulting Scientist at MITRE, undertook to ensure that the next step, a Request for Proposal (RFP), would lead to a real-time CORBA spec that was truly effective, especially for command and control systems. That was not an easy task, he says, given the pressure from the vendor community to minimize the impact on their current products. "There was a three-way push and pull: mainstream ORB vendors who would just as soon have it go away but given that it wouldn't tried to water it down as much as possible; the hard-core real-time community who wanted it to be really real-time; and the telecom community, which has a somewhat different set of requirements for real-time. We ended up with a compromise RFP that satisfied all three communities." But the initial RFP showed the strain of the disparate communities coming together and struggling to communicate. To produce a more coherent RFP that still satisfied all three communities, Jensen and two other respondents worked for about two weeks on a "lean, mean" and limited RFP. After a few modifications were made, everyone concurred, so that recast RFP became official on September 26, 1997. Here MITRE did something interesting and unique. OMG requires that any company responding to an RFP sign a letter that obligates it to have a product on the market within one year of having the specification adopted by OMG. MITRE is not a vendor, and so has no intention or possibility of fielding CORBA products, and hence has no place in this proposal process, although writing specs is typical MITRE work. MITRE approached OMG and proposed teaming with as many of the respondents as would accept us so that MITRE could participate in the proposal process and in the subsequent consolidation, and have a good opportunity to influence the emerging standard. One of the proposing teams agreed, so now MITRE had a role in preparing one of the proposals. The SIG collected more than a dozen responses from vendors, then sat them down in private and asked them to consolidate their proposals into one. Jensen proved instrumental in protecting Air Force interests and carrying the day for some of the requirements that MITRE and the Air Force deemed absolutely critical. Step One had designed in a proprietary real-time ORB developed by the contractor. But once there was a standard, the Air Force mandated that AWACS would have to conform to that standard. Following up on their AWACS product experience, the contractor initially planned to come out with a standards-based version of their project. After some effort to do so on their own, however, they changed their business strategy and entered a business relationship to potentially merge their ORB with a very good commercial standard ORB from Objective Interface Systems, Inc. (OIS). OIS is still considering this merger of technologies and will make a decision based on customer demand. The result is likely to be one of the first ORBs to come to market that complies with the real-time standard completely. Case Study The real-time CORBA specified in version1.0 differs from CORBA in that it has mechanisms for understanding and responding to priorities. Normally, when tasks have deadlines, you try to do the one with the shortest deadline first because it's in the greatest danger of being missed. But real-time operating systems don't support the concept of deadlines directly. They have a much simpler concept of priority. Users have to convert their deadlines into priorities, and the operating system tries to run things in priority order. The 1.0 specification is predicated upon fixed priorities, and applies to systems in which you can assign priorities to your tasks before you turn the system on. The applications and the environment in which they execute are well enough understood that you know in advance all the possible programs and applications that will run. You know how to assign the appropriate priorities to them so that, when you do turn on the system, things will run in the right order and the system will work the way you want it to work. This describes perfectly only very small and simple environments where the future is predictable, where you know not just every application that's going to run and what hardware would be appropriate for it but all the circumstances that could possibly arise. There is indeed an important niche where those assumptions are reasonable approximations to reality, and where you can assign fixed priorities to all your tasks, asking simply, will I meet my timing requirements or will I not? But for even moderately complex environments, as we scale up toward enterprise computing and such dynamic systems as command and control, the less technology exists in the real-time community upon which to draw, and the more we need to switch strategies. The operators of AWACS actually do know all the programs that are going to run. What they do not know is the environment in which they will run, what kind of and how many targets they'll be tracking, what kind of mission they'll be going on, who the bad guys are, and where they are. Of course, some aspects of AWACS are static. The radar antenna inside that 30-feet-in-diameter, 6-feet-high rotodome atop the aircraft has a 10-second period. No matter what happens there is software that will run every 10 seconds to accommodate the mechanical rotation of the antenna, and that is so whatever the environment in which the system operates. But the environment itself is unknown. Fixed-priority real-time CORBA is not particularly effective in the dynamic aspects of AWACS. To address the current needs of MITRE's customers, real-time CORBA specifically designed to handle the unexpected—dynamic real-time CORBA—is what is needed. Tom Wheeler, co-leader of MITRE's Department of Real Time and Performance Engineering, suggests the following example. Go to check in for a flight at the airport and you'll likely find two lines at the airline counter—one for first class passengers and another for everyone else. But the airline might decide that it's less important to differentiate class and more important that they don't have people miss flights. So they might decide to process the passengers whose flights are leaving next before they process the other passengers. Then there might be four lines, and the line you get in, and how many staff are processing that line, might be based on when your flight is leaving. Now you, as a traveler, are dynamically assigned a priority based on the urgency of your timing request.
MITRE is a strong advocate of such dynamic real-time scheduling approaches to provide much more scalable solutions. Whereas more than a dozen vendors tried to reconcile their points of view on the fixed priority, 1.0 version of real-time CORBA, the dynamic scheduling version, an attempt to make real time more generally applicable, involves only five vendors, all with largely the same point of view. These five vendors, together with Doug Jensen, have written a draft proposal for a dynamic scheduling real-time CORBA ORB dated October 6, 1999. Largely as a result of MITRE's influence, it includes two technologies that MITRE believes are essential to the building of command and control systems, and upon which all its Real Time and Performance Engineering Department's work in command and control is predicated. The first of these is distributed threads. A thread is a schedulable entity that runs on hardware and executes programs; you can think of it as the history of the movement of the execution point. Unlike a regular thread, a distributed thread can span multiple processes and multiple computers (nodes) on a network, carrying its deadlines and priorities with it from node to node. The second keystone technology upon which the department focuses actually consists of two related scheduling technologies. The first is the idea of a scheduling framework into which different, application-specific scheduling algorithms can be plugged, since one size does not fit all when it comes to scheduling algorithms. The second piece of scheduling technology that the department is developing and utilizing is a particular class of scheduling algorithms that can plug into the scheduling framework, called "utility function"-based algorithms. Such algorithms are intended to address the complex reality that most real-time computing systems must function as dependably as possible in a dynamically uncertain environment. Utility function scheduling algorithms can provide optimal predictability of timeliness, given real-world circumstances, whereas conventional real-time scheduling algorithms perform very badly in degraded and overloaded situations. Case Study Despite the advantages of dynamic scheduling, the developmental work for AWACS implemented static scheduling poDistributed Threads CS is a mission-critical system, MITRE really wanted to do things in a proven manner that the engineers knew well. And real-time CORBA 1.0 went a good way toward fulfilling the need for flexibility and open interfaces. It provided a capacity to handle preemption of lower priority tasks by higher priority tasks ones. It allowed team members to stop worrying about how to build a mechanism to communicate among tasks and on what computer a given task would run. It satisfied most of their timing requirements, so that the recipients of AWACS surveillance might have a comprehensive picture and know where the enemy is rather than where the enemy used to be. Step One encountered difficulties during the development of the software, which could not be made sufficiently reliable for fielding. These difficulties could not be overcome within the specified window of opportunity necessary to ensure installation of Step One into the AWACS while maintaining only the two standard fleet configurations. Because AWACS aircraft are constantly in use but few in number, the warfighters who operate and depend upon AWACS could not support the three different AWACS configurations that would have resulted from the Step One installation delay. Step One did not go to production as a fielded baseline. However, most of the difficulties have been corrected and Step One continues to be used in a development laboratory as a test bed for experimentation and testing. Despite the decision not to field Step One, the contractor is still supportive about using real-time CORBA. The Air Force has taken the lessons learned from Step One and applied them to the next major AWACS block upgrade, Block 40/45. The Block 40/45 upgrade will replace legacy hardware and software and migrate to an open systems architecture based on RT CORBA. Production is expected to start in 2007. CORBA–Common Object Request Broker Architecture–is a commercial standard solution for object communication in a distributed environment. Objects, in this context, are encapsulations of both data and behavior, so they act as autonomous things amounting to real-world objects. One can talk about a software object as if it had the characteristics of a human being or a particular tool or a piece of machinery, whereas in traditional, functional software one is really talking about function.
The Object Management Group™ (OMG™), the not-for-profit corporation whose reason for existing is to own and mature CORBA and related technologies, describes the Object Request Broker™ (ORB™) as "the middleware that establishes the client-server relationships between objects. Using an ORB, a client can transparently invoke a method on a server object, which can be on the same machine or across a network. The ORB intercepts the call and is responsible for finding an object that can implement the request, pass it the parameters, invoke its method, and return the results. The client does not have to be aware of where the object is located, its programming language, its operating system, or any other system aspects that are not part of an object's interface. In so doing, the ORB provides interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnects multiple object systems." To accomplish that CORBA uses a language-neutral interface definition language (IDL™) that is part of the CORBA standard. Different methods allow an object to find what it wants to find in a manner that is network transparent. If you want to find an object that will do something for you and you know its name you can query the naming service–for example, Where is the object called accounting subroutine? The naming service will return a pointer to where it is and the broker will use that to communicate and pass the messages back and forth. With a trader service, you don't need to know the name of an object, just how to describe it–for example, I need to find a mapping package with maps showing xyz. The trading service will check a database to see if any other object is registered that will provide that, in effect brokering between objects whose names you don't necessarily know. The Technology Transfer and DII COE The Defense Information Infrastructure Common Operating Environment (DII COE) is a major DOD, multi-service standardization effort owned by the Defense Information Systems Agency (DISA). It arose from the desire to enhance interoperability and reduce the costs of supporting every operating system developed for DOD command and control (C2) systems. But while OMG tries to standardize by specifying requirements, so that anyone can compete to build a better product, DII COE tries to down-select. It picks and gives its blessing to only particular products. A DII COE component is very prestigious for a vendor, and makes it far more likely that the DOD developers will use that vendor's part because they'll have far less resistance from the government. Typically, if a DII COE-compliant component exists with the capability a developer needs, the developer is required to use it. DII COE sets some standards. Participants then try to find products that meet those standards so that DII COE can offer a list of approved products to the DOD community. DII COE, then, is as much a process as it is a standardization By 1996, the armed services had recognized that critical C2 missions had stringent real-time requirements that could not be satisfied solely by products approved by DII COE. In the summer of 1997, John Maurer, co-leader of MITRE's Department of Real Time and Performance Engineering, began on their behalf his articulate and successful advocacy for DISA to charter a DII COE real-time technical working group (TWG). Its aim would be to develop common requirements and recommendations for products that could potentially add real-time capabilities to DII COE's approved list. The Air Force designated the AWACS program office as executive agent for DII COE real-time extensions. Soon, the TWG, together with the DII COE real-time integrated product team (IPT) that embodied the AWACS program office's authority, began the process of identifying requirements and recommending products for the joint real-time Command and Control community. In this context, MITRE was able to encourage the adoption of RT CORBA as the distributed computing standard. Given a number of operating systems available that could potentially meet the requirements for real-time extensions, AWACS and the Army Crusader program proposed as the DII COE standard the operating system that they intended to use. AWACS put its resources (and MITRE's) behind promoting it to DISA and qualifying it for DII COE. Through the TWG, Maurer is currently working with DISA to have two real-time, commercial ORBs based on the CORBA standard that look a whole lot like MITRE's AWACS solutions approved for use in DII COE by October of this year. These products will likely be used in a variety of programs in addition to AWACS, including Upgraded Early Warning Radar, the Army Advanced Field Artillery Tactical Data System, the Joint Tactical Terminal, and the Joint Tactical Radio System. Thus, technology originating in MITRE's labs has moved into AWACS and is now on the verge of being transferred elsewhere within DOD. And, says Doug Jensen, consulting scientist at MITRE and foremost proponent of dynamic real time, "when dynamic real-time CORBA is available, DII COE will add it to its bag of tricks."
Page last updated: March 25, 2001 | Top of page |
Solutions That Make a Difference.® |
|
|
