2.1. Reusability, adaptation, and interoperation

We define reusability as the ability to reuse an analysis model for the same application (typically with minor changes to one or more input parameters) by someone other than the model developer. Adaptation is defined as the ability to easily reuse or modify an analysis model developed for one application for another similar or related application. Interoperability is defined as the ability of independently developed models or analyses to be easily applied or combined for use in a hybrid application that involves multiple distinct analyses. This section deals with the existing approaches to reusability, adaptation, and interoperability problems. Most of these solutions are ad hoc and unsatisfactory, in a large measure because of the lack of suitable computer science foundations for addressing the underlying fundamental issues from which the problems arise.

Reusing or adapting an analysis model is a knowledge-intensive process, and to date, manufacturing enterprises have had very limited success in capturing, archiving, and reusing knowledge in a computational environment. Organizations resort to offline documentation of the design and analysis assumptions. Apart from offline documentation, the next most prevalent approach for overcoming this problem is automated transformation of data or code, such as by a macroprocessor or similar tools, for example, GenVoca (Batory et al., 1994). These, however, tend to be programming language or platform specific and unable to assure uniform, complete, or consistent transformations. Moreover, these existing approaches lack two critical features required of adaptation in engineering applications: the ability to capture both the nature and intent of adaptation, and the ability to combine or sequence adaptations and to recognize (in)compatibilities among them.

One of the most common concerns among manufacturing enterprises is the persistent lack of data portability and interoperability (Brunnermeier & Martin, 1999). Major CAD vendors that provide a complete package of tools [product data management (PDM), CAD, computer-aided manufacturing, FEA, etc.] have a distinct advantage in the market simply because interoperability concerns are lessened, even though one or more of the individual software components may be inferior to others in the market. Hence, this means that an interoperable solution these days requires organizations to lock into a single monolithic computational environment in lieu of a suite of application tools, each one being optimally suited for the specific task at hand.

The problem of interoperability has been addressed in areas apart from FEA. The most notable contribution has been in the area of PDM. Szykman et al. (2000) have proposed a foundation for interoperability in the next generation product development systems. They have made efforts to integrate data exchange standards such as ISO 10303-104 (1994), known as STEP (standard for the exchange of product model data) into the existing generation of software tools. This system addresses the lack of formal product representations such as function, behavior, and structure, which are the shortcomings in the existing PDM systems. These existing systems concentrate mainly on database-related issues and do not place any emphasis on information models for artifact representation.

Earlier work by de Kleer and Brown (1983), Iwasaki and Chandrasekaran (1992), Alberts and Dikker (1992), Chandrasekaran et al. (1993), Henson et al. (1994), Goel et al. (1996a, 1996b), Qian and Gero (1996), Ranta et al. (1996), and Umeda et al. (1996) on product information representation has helped in the high-level division of artifact information into form, function, and behavior. Szykman et al. (2000) have developed on this high-level division to obtain a core-level representation consisting of objects and relationships with flow, function, form, geometry, material, behavior, specification, and artifact as the various classes representing them. Utilizing this type of a product representation would provide a rich source of knowledge that could be utilized in the development of the product. Although not in the area of engineering analysis, the fundamental concept of a formal information structure that, when instantiated, represents knowledge about a particular domain that can then be operated upon by computers and humans alike is a key component to how we propose to solve problems involving reusability, adaptation, and interoperability of engineering analysis models.

2.2. Knowledge-based systems and ontologies in engineering analysis

In this section we focus on research that has been done to develop knowledge-based systems for engineering analysis, with particular focus on FEA, and on the development of ontologies for supporting knowledge base systems in engineering. Surprisingly, relatively little work has been done in this area, although it has been over 20 years since the development of the rule-based expert system, MYCIN, in the field of medical diagnostics (van Melle, 1978; Clancey, 1983).

One of the early applications of the MYCIN environment to nonmedical domains was a structural-analysis assistant that addressed some of the numerical modeling aspects of the problem using the heuristic classification problem-solving paradigm (Clancey, 1985). By incorporating a large number of heuristics, these systems can recommend problem specifications, analysis strategies, and program options, starting with a description of problem features. Under most circumstances, a domain expert and a knowledge engineer are locked away for months or years and return with a model and computer program, which are comparable in performance to human specialists (Grower, 1982). This method has produced several remarkable programs such as SACON (Bennett et al., 1978), PROSPECTOR (Duda et al., 1978), R1 (McDermott, 1980), and INTERNIST (Miller et al., 1982). Yet, maintenance of these rule-based systems has been difficult, as seemingly insignificant changes in the rule base can produce dramatic and unpredictable results (Musen, 2000).

Over a period of time a number of frameworks have been developed to support engineering analysis, such as the frameworks proposed by Shephard et al. (1990) and the knowledge-based assistance for finite element modeling proposed by Turkiyyah and Fenves (1996). These frameworks continue to have the problems of domain-specific knowledge tightly coupled with procedures and rules, making the systems difficult to maintain and extend. Object-oriented frameworks address this issue. Extensive work by Tomiyama et al. (1989), Zimmermann et al. (1992), Mackie (1992), and Dubois–Pelerin and Zimmermann (1993) have shown a complete representation of FEA models in object-oriented frameworks. This has led to the development of a number of semiautonomous systems, such as an automated system for the modeling and analysis of multichip modules by Sheehy and Grosse (1997) and Holzhauer and Grosse (1999). These researchers developed a hierarchical object-oriented database to represent the physical system at various levels of abstractions, such as user-defined physical system level and computer-generated physical and finite element model levels. Even though these systems have been restricted to certain application domains such as thermal or structural analysis of multichip modules, they demonstrated the improved efficiency and ease of applying blackboard architecture to integrate the various numerical and symbolic knowledge sources in an object-oriented framework. Peak (2000) proposed the X-Analysis Integration Technology system, which includes capturing design knowledge, transferring the same into reusable libraries, and deployment of these template analyses for the creation of a new analysis type. However, in this system, as well as the previous systems discussed above, there is no formal representational scheme for modeling knowledge. Therefore, these systems cannot be easily extended by methods that would operate on this knowledge, nor can modeling knowledge be easily explicated and exchanged with people or software agents.

The use of Java-based frameworks to support engineering analyses has become a recent trend (1997). This work includes Onyx (Reed & Afjeh, 1998), MOB-FEM (Shanbhag, 2001; Shanbhag et al., 2001), and FIPER (Rohl et al., 2000; Wujek et al., 2002). Onyx is a Java-based object-oriented application framework for aerospace propulsion system simulation that is capable of integrating advanced multidisciplinary and multifidelity analysis methods, dynamically constructing arbitrary simulation models, and distributing computationally complex tasks. This system provides a robust framework for interoperability between the different disciplines (structural, fluid, thermal, etc., referred to as phenomenon in this proposal) along with fidelity (0-D, 1-D, 2-D, and 3-D referred to as geometry in this proposal). However, the system requires a representation of these models to preexist in the database of components, and is restricted to aerospace propulsion systems. This system assumes the same kind of boundary, initial, and load condition when analyzing a particular component of a model. Hence, reusability, adaptability, and interoperability exists only in the context of a specific multidiscliplinary analysis problem. Onyx exploits the Java reflection capability in developing the analysis models but has no capability of intercession, unlike OpenJava (Tatsubori, 1999). Shanbhag et al. (Shanbhag, 2001; Shanbhag et al., 2001) developed an OpenJava application called MOB-FEM for automatically reusing finite element modeling knowledge. A separate Visual Basic tool, called TEK-FEM, with a graphical user interface was developed to extract modeling knowledge from a domain expert. This knowledge is then stored in a Microsoft Access backend database. Although the modeling knowledge extracted from the expert is based on a taxonomy similar to the one proposed by Finn et al. (1992), the knowledge was not represented or stored using a formal information structure. As a result, the researchers were forced to hardwire much of the functionality of the coupled TEK-FEM/MOB-FEM system for the specific problem used to demonstrate the methodology: thermal cooling FEA and subsequent mold ejection elastostatic FEA of a plastic part. FIPER, the result of a $21.5 million project effort funded primarily by NIST's Advanced Technology Program and a number of high technology companies, is a component-based Web-centric framework with a common protocol that to enable companies to “wrap” their engineering tools, data, and processes into the FIPER environment. This enables across the Web data exchange and access to various engineering tools that support product development. The architecture is based on Java and Sun's Jini software system. However, there is no across the Web knowledge exchange.

Parallel to the development of these frameworks to support engineering analysis activities, researchers in the field of artificial intelligence began to uncover serious shortcomings with procedural rule-based expert systems. They discovered that subtle changes in the way the rules were organized produced dramatic changes in the expert system results (Buchanan & Shortliffe, 1984). It was clear that relationships existed among the rules that were difficult to determine by direct inspection of the knowledge base, and therefore, large production rule systems were difficult to maintain and problematic (Bachant, 1988). A way was needed to separate out operational knowledge, that is, problem-solving methods, from the domain knowledge upon which the problem-solving methods operate.

One of the most promising ways to separate and represent domain knowledge from operational or problem-solving knowledge is through the use of ontologies. A popular definition of ontology is the one offered by Gruber in 1993: ontology is an explicit specification of a conceptualization of a domain. It is a formal specification of the terms in the domain and the relations among them. Noy and McGuinness (2001) elaborate to define an ontology as a formal explicit description of domain concepts, often called classes, properties of each class, called slots, which describe the various features and attributes of the class, and restrictions on the properties or slots, called facets. The classes may be arranged hierarchically with subclasses inheriting properties from their superclasses and adding further specification with additional properties and facets. Ontologies represented or modeled in this manner are well suited for implementation using object-oriented languages.

When an ontology is populated with information that fills the properties of the classes, that is, instances of the class objects, it represents a knowledge base for that particular domain. One important distinction between an ontology-based knowledge tool and a pure object-oriented architecture is that, in the latter, problem-solving methods are interleaved with the knowledge structure, that is, class and instance objects. This has advantages in terms of permitting a good bit of flexibility regarding the semantics of encoded objects and making it straightforward for developers to include new functionality into the code. Yet, it is impossible to consider control–flow relationships separately from the data structures that comprise the object hierarchy or to view the data or knowledge model without being distracted by associated program code (Musen, 2000).

The development of ontologies for a wide variety of domains has been an active area of research in recent years. Extensive ontology libraries can be found at the Stanford's Knowledge Systems Laboratory (www.ontolingua.stanford.edu) and at DARPA's DAML ontology library (www.daml.org). Unfortunately, little work has taken place to date in developing formal ontologies for engineering and for engineering analysis modeling knowledge. However, there are a few notable contributions in this area. Dym and Levitt (1991) appear to be the first to propose taxonomies for engineering analysis modeling knowledge. The authors present a topology of engineering knowledge that includes fundamental or first principle knowledge, phenomenological knowledge, analytical model knowledge, numerical model knowledge, and even meta knowledge, such as goals, objectives, and intentions of the analysis model. They implement their knowledge topology in a LISP-based Life Safety Code Advisor, a prototype knowledge-based expert system for reviewing architecture designs for conformance with NFPA safety code. In a similar vein, Finn et al. (1992) proposes an intelligent modeling assistant based on a taxonomy of modeling idealizations for continuum-based analysis models, and subsequently proposes a system (CoBRA) for the development of a model of a physical system (called a physical model by the authors) adopting both case-based and model-based reasoning (Finn & Cunningham, 1994). They describe the generation of a model as the application of idealizations and simplifications of spatial, phenomenological, and temporal aspects. They have broken down the modeling simplifications into two categories: geometric and phenomenon. The four types of geometrical simplifications discussed by Finn et al. (1992) are dimensional reduction, geometric symmetry, feature removal, and domain alterations. Similarly, the phenomenon simplifications are reduced or removed. Phenomenon removal is the omission of an entire phenomenon from an analysis, while phenomenon reduction is the removal of a component of a phenomenon such as ignoring radiation in a heat transfer analysis.

Borst et al. (1994, 1995) have developed a set of formal engineering ontologies called PhysSys for dynamic physical systems. The set includes three ontologies (component, process, and engineering mathematics) with ontological projections that map components to processes and processes to engineering mathematics. PhysSys basically defines components as carriers of physical processes that can be represented mathematically with physical quantities and mathematical relations using Gruber's and Olsen's EngMath ontology (1994). The authors discuss the need to include metalevel information as attributes of engineering analysis models, and suggest validation information and modeling assumptions as examples of such knowledge. Their system captures this knowledge as text, but the authors acknowledge that a more formal structure is needed so that a support system for engineering modeling could actually reason about it.

3.1. Ontologies for representing engineering analysis modeling knowledge

Noy and McGuinness (2001) provide a step by step guide for developing an ontology. Based on their methodology, we have begun to develop an ontology that would be applicable to all engineering analysis models. This ontology draws upon some of the analysis modeling taxonomies and concepts presented by Tomiyama et al. (1989), Finn et al. (1992), Dym and Levitt (1991), Finn and Cunningham (1994), Sinha et al. (2001), and Paredis et al. (2001). Figure 2 shows our hierarchical categorization of types of analysis models. We first distinguish between physics-based and non-physics-based models. Physics-based models are predictive models of the physical behavior of a physical system, such as an engineered product or manufacturing process. Example of a non-physics-based model is a market analysis model that predicts the demand for a product. In this research we are focused on physics-based models, which we further subtype as empirical, lumped parameter or discrete, and continuum based, and our proposed ontologies are applicable to all physics-based engineering analysis models. Empirical models are models directly derived from experimental observations, such as response surface models or material behavior models derived from material testing. Lumped parameter or discrete models are mathematic models that consist of one or more interconnected model components with individual model component parameters lacking spatial dependency. Continuum-based or distributed models are mathematic models with one or more variables or parameters that are dependent upon one or more independent spatial variables. Continuum-based models are classified as analytical or numerical, depending on whether or not numerical techniques are needed to obtain the model solution. The class of numerical continuum-based models has a number of subclasses according to specific numerical techniques, such as boundary element method, finite element method, finite difference method, wavelet methods, and hybrid methods involving one or more of the previous methods. As new methods emerge, additional subclasses would be included here.

The class hierarchy of some engineering analysis model types. The proposed ontologies are applicable to all physics-based engineering analysis models.

In Table 1 we identify basic properties of all physics-based analysis models. The first column is the term employed to represent this modeling knowledge concept, the second column is the type of information contained in this concept, the third term is the cardinality of this information, and the fourth column lists constraints or other properties of this concept. The information is typed to facilitate computational representation and manipulation. An instance type means that this information is an instance or object of another class with separate properties that define that class. Cardinality is the number of values an instance of the term or property may take on. Note that a cardinality of multiple means this term supports multiple values, but it can be empty. A term with required multiple cardinality means that the term must contain at least one value. A term with required single cardinality means the term must and can only have one value.

Properties of engineering analysis models

The class of engineering analysis models has the basic properties of name (a string), creator (a string), creation date (a date), modifier (a string), modification date (a date), model version number (a floating point number), and model documentation (a string that provides links to technical reports, presentations, etc.). This information is similar to standard software engineering documentation. We assert that additional more abstract, or meta, knowledge needs to be formalized into an ontology to support engineering analysis modeling, as shown in Table 1. Specifically, all engineering analysis models have a purpose that describes what the overall goal of the model is in terms of strategic objectives of the engineering department. An engineering analysis should have a primary objective in terms of specific analysis results that are sought (i.e., specific engineering quantities of interest, such as maximum temperature, stress, deflection, response time, natural frequency, acoustic amplitude, power, energy, force, etc.), and possibly secondary objectives. Engineering analysis models are derived from physical systems, such as products, subassemblies, components, or manufacturing processes, and therefore, this information should be captured.

As Hazelrigg (1996) notes, analysis models have three fundamental properties: accuracy, resolution, and causality. Resolution is the ability of the model to differentiate between, or resolve, results for different values of input parameters, and causality is the ability of the model to help establish causal relationships between output parameters and input parameters. Therefore, in our ontology we include as fundamental properties of the analysis model class slots for expected accuracy, expected resolution, and expected causality. At this point it is not clear how to type these slots, that is, as numbers or perhaps as strings for qualitative information.

We also include model robustness in our ontology. We define robustness as a measure of the stability of the engineering analysis model to variations in input parameters. It should be noted that if the model seeks to simulate an inherently unstable phenomenon, such as a flame, then instability in the results may be indicative of the physical system being simulated and not due to a lack of model robustness. Instability in computer-based analysis is often due to finite precision in digital computers, coupled with large differences in scales of physical quantities represented in the analysis model. Included in our definition of robustness is the degree to which the analysis tool (or macro that executes the analysis tool) has error trapping to detect if supplied input parameters are out of bounds. Analysis models may demand certain resource requirements in terms of software and hardware, and therefore, the analysis class could include these slots to specify this information as well.

All analysis models have a set of limitations that describe the applicability of the analysis model to a class of problems. Each limitation may be the result of one or more modeling idealizations and/or due to limitations of the analysis tool used to solve the analysis model. Each modeling idealization has justification knowledge to support the specific modeling assumption. Figure 3 shows the relationship between the Analysis Model, Limitation, Idealization, and Justification classes, as well as fundamental properties of each concept or class. Each concept has slots for specifying the name and description of an instance of the concept. For the sake of brevity, the property list for the Analysis Model class is abbreviated in the figure to include only the additional slot for storing limitations property. The complete list of properties of the Analysis Model class is given in Table 1. In addition to a Justification property, the Idealization class includes properties for specifying the effect the idealization has on accuracy, resolution, causality, and reducing the analysis modeling cost. Justification knowledge includes three properties for justifying the idealization based on heuristics, theory, or first-principle, and/or empirical observations.

The properties and relationships of the analysis model, limitations, idealization, and justification classes.

Analysis models are often comprised of components that may or may not map directly to physical components. Thus, we have included in our ontology a slot for specifying a list of model components that comprise the engineering analysis model. As in the model itself, model components may have specific limitations associated with the component. The component limitations are associated with instances of the idealization class with justification knowledge for each idealization.

All analysis models have inputs, either parameters or files containing input data, and outputs, either parameters or files containing output data. Input parameters and files have associated suppliers, whereas output parameters and files have associated recipients. Suppliers and recipients may be people, databases, or other software tools. Input parameters have constraints that restrict their values. Our ontology structure would support explicit representation of all of this information by having the model input parameter slot value be an instance of the input parameter class.

We can think of other modeling knowledge that may be important, especially to organizations with quality control processes imposed on the model development process. For example, the model may have a validation or critical risk reduction plan that seeks to address uncertainty with regard to validity of model idealizations or a certification level indicating the overall robustness and accuracy of the model. The ontology could capture the model development process itself, either informally by specification of model development steps as a property of the analysis model class using a text list or more formally by an instance of a process ontology. A process ontology has fundamental process properties, such as task, inputs for a task, outputs for a task, preceding task, following task, task resources required, and so forth.

3.2. Domain-specific EAM ontology research and development

In Section 3.1 we have broadly discussed the type of knowledge that might support all EAMs. Within this overall EAM class, there are subclasses of analysis models, as shown in Figure 2. Each of these subclasses of EAMs may have specific modeling knowledge that needs to be specified in a formal information structure. For example, continuum-based analysis models have the concept of geometry as defined by one or more spatial coordinates and have an underlying theory based on continuum mechanics, and therefore have a unique class of modeling idealizations related to spatial coordinates. For example, geometry itself can be idealized as 2-D or 1-D, geometric features can be ignored or modified, forces and constraints can be idealized as point loads, and so forth. Further, all but the simplest continuum-based models require numerical techniques, such as FEA, to solve. This introduces additional modeling knowledge related to discretization techniques and the specification of the proper numerical solution techniques. For example, in the finite element model analysis subclass discretization knowledge could include element types and meshing methodology.

Lumped parameter models have the concept of flow, such as energy or current, between components that are defined with specific input–output relationships. Therefore, lumped parameter models have idealizations regarding input–output black box behavior of interconnected functional components of the model. Underlying theory, such as control theory, supports these models. Empirical models have the concept of observations and measurement error. Statistical theory supports empirical models.