MITRE | The MITRE Digest | Model-Driven Engineering Allows New Design Methods to Improve an Existing Aircraft System

Model-Driven Engineering Allows New Design Methods to Improve an Existing Aircraft System

August 2010

There are times in the advancement of military technology when progress unexpectedly hits a bump in the tarmac to give new life to the old. Such is the case of a 25-year-old surveillance aircraft that was supposed to be replaced with an advanced design. But the new design was cancelled, and potential enhancements to the old plane are now being demonstrated using a process called model-driven engineering.

The E-8C Joint Surveillance Target Attack Radar System (known as Joint STARS) aircraft, a cooperative project of the U.S. Air Force and Army, provides ground surveillance to joint services commanders so they can conduct their operations. The E-8C is a modified Boeing 707-300 series commercial airframe that has a powerful radar and communications systems for intelligence, surveillance, and reconnaissance. It's been supporting ground troops since 1991 when it was first deployed in Operation Desert Storm. However, when new technology became available to counter emerging threats, the Air Force called in MITRE to help design the radar and battle management system for its replacement, the E-10A Multi Sensor Command and Control Aircraft.

MITRE has been the systems engineer for Joint STARS since its inception in 1985, working under a contract with the USAF Electronic Systems Center at Hanscom Air Force Base, Bedford, Mass. In designing the radar and battle management system for the E-10A, MITRE opted to use model-driven engineering (MDE), a relatively new computer-aided systems engineering process.

"For complex systems, MDE enhances the traditional design process that uses drawings and documents," says Tom Wheeler, a MITRE senior principal engineer who served as deputy chief engineer of the former 851st, Electronic Systems Group, Hanscom Air Force Base, Mass. MITRE chief engineer Charlie Arouchon and Wheeler led a team of 13 systems engineers using MDE for the E-10A and later the Joint STARS Radar Modernization (JSRM) projects for the E-8C.

"The drawings of circles and squares that represent components in the traditional systems engineering process give a static representation of a design," says Wheeler. "Yet a lot of our hard technical problems involve systems dynamics—how components interact with each other. We use MDE to convert those static pictures into a programming language that can be compiled like a regular software program. Such an executable model shows us how the parts interact during the design phase rather than waiting for software to be built."

In addition, MDE allows MITRE to bring the Air Force and the contractor into the decision-making process much earlier. "MDE lets us blend multiple disciplines in a project and collaborate with multiple organizations such as the contractor and the Air Force," notes Wheeler. "We can all work off the same data sets. The models and scenarios created by MDE can be understood by non-systems engineers and allows the Air Force to determine how and where it wants to have an operator in the loop and where it feels comfortable letting the computers make decisions."

"Collaborating system designers and users can see how the design comes to life," agrees David Campbell, a MITRE lead software systems engineer. Campbell was responsible for the radar subsystem and coordinated the team's interactions across the projects for the E-8C JSRM project. The core modeling team included Campbell and systems engineers, Ryan LaFortune, and Ray Clark.

Campbell points out that MDE is valuable for trying out scenarios. "For example, you can increase a radar system's tasking load to discover flaws in its design," he says. "MDE lets you look at tradeoffs much earlier in the design phase when it's less expensive to change things. That's especially important with a complex system like battle management. All of the interactions between automated and manual subsystems must be choreographed properly for the system to work. When problems in one subsystem pop up, they ripple through the whole system and affect other subsystems. If you can knock out those problems early in the design phase, you get a much higher quality product that's on time and within budget."

Campbell explains that a number of commercial vendors make model-driven engineering tools, but they're for small systems. Currently, no particular tool fits the bill for designing a complex system of systems. "Commercial tools have tradeoffs," he says. "When you're dealing with a complex system like a battle management or radar system, you're talking about 25 to 30 subsystems and hundreds of messages between those subsystems. If you try to jam everything into one model, it bloats up, and you can't run it."

To get a complete tool set, the MITRE team combined commercial software with a special plug-in it developed. The team used IBM's Rational Rhapsody tool suite to break down the battle management radar architecture into components or subsystems that could be worked on individually. Major parts of the architecture include sensor management, weapon target pairing, data management, and radar tracking.

The MITRE-designed plug-in, called the Distributed Modeling Profile (DMP) tool, enhances the operation of the Rhapsody software. The DMP tool uses the Java Messaging Service, an open messaging protocol, to create software that allows the different components to interact with each other seamlessly. "Our tool allows all of the subsets to represent a distributed complex system," says Campbell. "It runs them as a single federated model."

"During the E-10A design phase we learned a lot as we moved ahead, such as how to manage classified and unclassified parts of the design," says Campbell. "We created a fine model that represented a next-generation battle management design. It worked great, and we had an initial design review with the Air Force in 2007. We also kept track of lessons learned, the most important being the need to distribute the design across multiple models."

That's when the Air Force told MITRE and the contractor that there wasn't enough money to build the E-10A. Undaunted, the Air Force wanted to use the new E-10A technology to upgrade the E-8C. This would require extensive analysis of what the new capability, risks, and tradeoffs would be. Work on the E-8C upgrade started ramping up in 2009. Because of difficulties in hiring the contractor that year, MITRE volunteered to temporarily take on the contractor's role of systems engineer for this major upgrade.

In the beginning of the E-8C modernization, MITRE needed to know how much of the E-10A radar and battle management systems could be transferred to the E-8C. But MITRE first needed to understand the legacy E-8C design. The team decided to represent the E-8C's radar and battle management system in executable MDE models. This helped gain understanding of the legacy design and create a framework for investigating which parts of the E-10A design could be incorporated into the E-8C. This approach involved going through the 25-year old source code and its thousands of lines of FORTRAN and C code.

"There's no magic tool you can use to suck all the old software into our model," says Campbell. "We spent seven months going through the old code to understand it and create an executable UML [Unified Modeling Language] model that represented all the different subsystems of the legacy code." UML is a standardized general-purpose modeling language that was created by the Object Management Group, a non-profit international standards-setting organization. It includes a set of graphical notation techniques to create visual models of software-intensive systems.

Once Campbell's team represented the legacy design in UML, it could use the dynamic execution techniques of model-driven engineering to show the Air Force various models that represented combinations of the new E-10A design and E-8C's existing design. The models showed different design tradeoffs in risk analysis and complexity. For example, if the military needs a new capability like advanced sensor management, the models could identify required changes in legacy components. If manual processes needed to be automated, specific new components could be identified.

"You can start to derive the costs, risks, and the level of effort for these different tradeoffs," says Campbell. "The MDE process allows us to show Air Force decision makers all the communications and data that must flow from one component to another in order to complete a new task. If they ask for a new feature, they can see if they're asking something really hard or something that's easy by looking at the communication flow."

Because MITRE enhanced the MDE process with distributed executable modeling, models can realistically represent different types of communication patterns and scale them to increasingly larger systems of systems and number of users.

Systems engineers can use MDE to lay the foundation for future modifications. They now have a product that shows how to steadily replace the E-8C's systems, starting with the initial new components. "Our modeling helps us identify the lowest risk, lowest cost methods to give the most features," says Campbell.

"We can create a road map to replace the whole project end-to-end over time. We choose priorities based on what the customer wants. And it's an iterative process, allowing differences to be worked out among the contractor, the system program office, and the user."

According to Wheeler, "MDE requires a commitment to robust systems engineering. The MDE technology is evolving and improving, but the benefits are clear. It's a great vehicle for projects that need to be able to reason about large scale problems and to collaborate across multiple organizations."

	Solutions That Make a Difference.® Copyright © 1997-2013, The MITRE Corporation. All rights reserved. MITRE is a registered trademark of The MITRE Corporation. Material on this site may be copied and distributed with permission only.
	Privacy Policy \| Contact Us