Domain Ontology Compliant Semi-automated Conceptual Product Design

Ontology Summit, March 2016

Kevin Lynch, Raytheon Missile Systems Engineering

Randall Ramsey, Raytheon Missile Systems IT

Matthew Schmit, Georgia Tech Aerospace Systems Design Laboratory

Complex System Design

• Growth in systems complexity has increased risk and development time to unacceptable levels overpast 50 years• Augustine’s Law: by “…the year 2054, the entire defense budget will purchase just one tactical aircraft”

• Complex defense systems required to respond to new, rapidly evolving threats• Requires systems to be designed with higher degree of adaptability

2

Why is design of complex defense systems lagging behind?

?

Background

Motivation

Implementation

Case Study

Conclusion

Current Approach to Managing Complexity• MIL-STD-499A systems engineering process as

employed today• Un-modeled and undesired interactions lead to emergent

behaviors during integration

• Resulting architectures are single point designs

• Conventional V&V techniques not scalable to highlycomplex or adaptable systems

• Redesign becomes economically expensive and timeconsuming

• Point solutions not easily adaptable

• Not feasible to consider large number of configurations

3

Component

Testing

Subsystem

Testing

Verification &

ValidationSystem Layout

Subsystem

Design

Component

Design

Fabricate & Assemble

*Source: DARPA

Re-Design

Defense acquisition process and design of complex defense systems must

be revolutionized

Background

Motivation

Implementation

Case Study

Conclusion

Better Buying Power (BBP)• Department of Defense (DoD) initiative first

introduced in 2010• Aim is to “restore affordability and productivity in

defense spending”

• Initiatives include:• Promoting competition• Incentives for increasing innovation in design• Eliminating redundancies within defense portfolios• Mandating affordability as a requirement

• Currently on BBP 3.0• Includes ongoing efforts from previous iterations• Added emphasis on innovation in design and efficiency

4

Courtesy of www.procas.com

One response to BBP initiative is the application of Model-Based Systems

Engineering (MBSE) techniques to design of complex defense systems

Background

Motivation

Implementation

Case Study

Conclusion

Model-Based Systems Engineering (MBSE)• Models are used as a means of information

exchange• Model is defined as any “physical, mathematical,

or otherwise logical representation of a system orprocess”

• Exchange information within and across differentdesign domains

• Component model library (CML) is required, forMBSE design to become feasible• Contains models for entire system, stretching across multiple design domains• Component models should at least include the following information:

• The nature of the model (e.g. computational, descriptive, etc.)• Supporting metadata such as assumptions and limitations• Inputs/outputs of any computational model• Data and information to describe a components cyber-physical behavior, performance, and interface capabilities

• Ontology can be used for CML to drive consistency in the way terms are defined

5

Notional component model library

Background

Motivation

Implementation

Case Study

Conclusion

MBSE Approach• Virtually design, manufacture, and verify complex defense systems

• Multi-fidelity models• Increase adaptability of design process

• One of the goals is to enhance design space exploration• Consider wider variety of designs to achieve the design requirements

6

Component Model Library

Foundry-Style Manufacturing – Virtual

Prototyping

Virtual Verification

Establish DesignSpace Final Concept

Design space refinement is still required for MBSE

Background

Motivation

Implementation

Case Study

Conclusion

Design Space Refinement Technique

7

Define Conceptualize Prototype Test & CertifyUnderstand

Conceptual Design Preliminary Design Detailed Design

Subject Matter

Experts

Establish Design

Space

Refine Design

Space

Select Promising

Concepts

Evaluate

Concepts

Iterate

Matrix of Alternatives

(IRMA)

Background

Motivation

Implementation

Case Study

Conclusion

How can we efficiently store this information within a component model library so that

it can be extracted for use in design space refinement and exploration?

Interactive Reconfigurable Matrix of Alternatives

• Design space of complex system represented through functionaldecomposition

8

System

System Components

Component Functions

Design Alternatives

Major components or disciplines that system can be broken down into (e.g., seeker system, aerodynamics)

Design decisions that must be made to allow system component to properly achieve desired

function or task

Different options available to achieve each function

System Components

Component Functions

Design Alternatives

Background

Motivation

Implementation

Case Study

Conclusion

Air Vehicle IRMA

Interactive Reconfigurable Matrix of Alternatives

• Design space of complex system represented through functionaldecomposition• Design space is represented by permutation of all possible configurations,

where a single design alternative is selected as a means to achieve eachcomponent function

• Selected design alternatives are colored green, while open design space isrepresented by all rows that have light blue cells remaining

9

Background

Motivation

Implementation

Case Study

Conclusion

Air Vehicle IRMA

Functional Decomposition in Protégé

• We have been developing an ontology for air vehicles in Protégé• Functional decomposition of air vehicle here is represented by hierarchy of classes in Protégé

• Incompatibilities are assigned using anobject property within Protégé (boxed inred)

• This allows us to capture the knowledgethat subject matter experts (SMEs) would

use when initially refining the designspace based on requirements

• Capturing this knowledge allows us toautomate the process

• Saves time in long run as tool is used andreused for multiple designs

10

Background

Motivation

Conclusion

Implementation

Case Study

Extraction Process

• From brief literature review, it was determined that Protégé does not have built in abilityto export ontology in a functional decomposition format

• Protégé ontology can be exported as RDF/XML, OWL/XML, and Latex file formats• RDF/XML file format had enough structure within the file to logically extract functional decomposition

• Process was developed to go from Protégé RDF/XML file to Dynamic IRMA• Extract functional decomposition• Restructure functional decomposition into proper hierarchy• Extract incompatibility relationships

11

Import Functional Decomposition

and Incompatibilities into IRMA

Start with RDF file

from Protégé ontology

Extract functional decomposition and all

incompatibilities of desired system

Functional Decomposition

Incompatibilities Table

Reconstruct Hierarchy of

Functional Decomposition

Background

Motivation

Implementation

Case Study

Conclusion

Air Vehicle Case Study• An ontology for a notional air vehicle was created within Protégé

• A parent class for an air vehicle was constructed

• Components of the air vehicle were assigned using “hadDirectComponent”object property• Components modeled include: seeker system, propulsion, aerodynamics, and control

actuation system

• Functional decomposition based on Fleeman’s Tactical Missile Design

• Notional design option incompatibilities built into ontology

12

Background

Motivation

Implementation

Case Study

Conclusion

Air Vehicle IRMA

Conclusions• Use of ontology-informed IRMA significantly reduces cost, cycle time, and

defects in Conceptual Product Design phase of complex defense systems

• Use of ontologies provides a dynamic means for semi-automating productconceptual design• Swapping domain ontologies automatically realigns IRMA to new product domain

• Same ontology for IRMA design space refinement can repurposed forsolving other problems• Representation of product space domain

• Product options with performance characteristics and features• Component/performance interdependencies and incompatibilities

• Ontology links to design domain models – interoperability & integration layeracross design, production, & test

13

Background

Motivation

Implementation

Case Study

Conclusion

14

Kevin Lynchkevin_j_lynch@raytheon.comhttps://www.linkedin.com/in/kevinjohnlynch

Randy Ramseyramsey@raytheon.comhttps://www.linkedin.com/in/rjramsey

Related Publications

“Semantic Design Space Refinement for Model-Based Systems Engineering,” in the 2016 IEEE International Systems

Conference, April 18-21, 2016, Orlando, Florida. [to appear]

“Ontology-driven Metamodel Validation in Cyber-Physical Systems,” in the 13th International Conference on

Information Technology New Generations (Model-Driven Engineering for Cyber-Physical Systems Track), April 11-13,

2016, Las Vegas, NV. [to appear]

“Ontology-enabled Cost Tradeoffs in Model Based Conceptual Missile Design,” in the 2016 AIAA Defense and Security

Forum, March 8-10, 2016, Laurel, Maryland.

Matt Schmitmschmit6@gatech.edu https://www.linkedin.com/in/rjramsey

This research was developed with funding from the Defense Advanced Research Projects Agency (DARPA). The views, opinions and/or findings expressed are

those of the author(s), and should not be interpreted as representing the official views of policies of the Department of Defense or the U.S. Government.