A framework for developing engineering design ontologies within the aerospace industry

Abstract

This paper presents a framework for developing engineering design ontologies within the aerospace industry. The aim of this approach is to strengthen the modularity and reuse of engineering design ontologies to support knowledge management initiatives within the aerospace industry. Successful development and effective utilisation of engineering ontologies strongly depends on the method/framework used to develop them. Ensuring modularity in ontology design is essential for engineering design activities due to the complexity of knowledge that is required to be brought together to support the product design decision-making process. The proposed approach adopts best practices from previous ontology development methods, but focuses on encouraging modular architectural ontology design. The framework is comprised of three phases namely: (1) Ontology design and development; (2) Ontology validation and (3) Implementation of ontology structure. A qualitative research methodology is employed which is composed of four phases. The first phase defines the capture of knowledge required for the framework development, followed by the ontology framework development, iterative refinement of engineering ontologies and ontology validation through case studies and experts’ opinion. The ontology-based framework is applied in the combustor and casing aerospace engineering domain. The modular ontologies developed as a result of applying the framework and are used in a case study to restructure and improve the accessibility of information on a product design information-sharing platform. Additionally, domain experts within the aerospace industry validated the strengths, benefits and limitations of the framework. Due to the modular nature of the developed ontologies, they were also employed to support other project initiatives within the case study company such as role-based computing (RBC), IT modernisation activity and knowledge management implementation across the sponsoring organisation. The major benefit of this approach is in the reduction of man-hours required for maintaining engineering design ontologies. Furthermore, this approach strengthens reuse of ontology knowledge and encourages modularity in the design and development of engineering ontologies.

Keywords:

• knowledge management
• ontology
• modular
• engineering design
• aerospace

1. Introduction

Within engineering design, the art of managing knowledge effectively is rapidly becoming an exciting and vibrant field of practice as aerospace organisations are realising that knowledge is the key to performance (Firestone and McElroy 2003). It has been established that one of the major issues within conventional knowledge management is lack of accurate integration between organisation strategy, processes and technology (Wong 2005; Pitt and MacVaugh 2008). Many of the techniques within conventional knowledge management are often stand-alone approaches that fail to incorporate effective knowledge management into the business and engineering processes, tools and platforms of an organisation (Jackson 2010).

However, in recent years, the engineering community (i.e. researchers and industry experts) has developed increased interest in the creation and maintenance of engineering ontologies to support the management of knowledge within engineering activities (Kitamura and Mizoguchi 2007; Dadzie et al. 2008; Hawker 2010; Lin et al. 2010). An ontology, as defined in literature (Kitamura and Mizoguchi 2007; Chungoora and Young 2010), is a formal specification of a shared conceptualisation of a domain of interest to a group of users. Ontologies has played a major role in enabling the interoperability of heterogeneous sources and has supported the creation of a shared and common agreement of meaning between diverse domains (Na and Neoh 2007; Dadzie et al. 2008; Zhang et al. 2013). However, the successful development and effective utilisation of such ontologies strongly depends on the method/framework used to develop them. Though many methods and frameworks exist for developing and maintaining ontologies, there is still no clear link between ontology development frameworks and aerospace engineering design activities. There is a need to utilise best practices from other ontology development methods and establish a framework linking ontology development to engineering design. In addition, due to the complexity of engineering knowledge, modularity in ontology design is a key performance indicator in developing engineering ontologies. Recently, it was identified that attempts made to develop ontologies for product and service design resulted into a massive ontology, which clearly lacked modularity due to bad ontology design and lack of domain experts’ involvement (Fowler, Reul, and Sleeman 2008). Lack of modularity in ontology design significantly provides limitations to the degree of ontology reuse, which is often one of the key reasons for developing ontology models.

Furthermore, the complexity of designing and manufacturing flight vehicles within the aerospace industry often require careful understanding and balance between technological advancements, design constraints, best practice knowledge, customer requirements, management and cost. There are several trade-offs required to be made including interdisciplinary and multidisciplinary types of knowledge required to be brought together to support decision-making. Complexities in aerospace product design often arise from diverse elements (Inden et al. 2014). Many arbitrary and ternary relationships exist between multiple elements of knowledge within engineering design. These include relationships between components that are composed of a single product, processes, activities and machine tools used to develop each component including specialist skill-set required for executing design activities. Chandrasegaran et al. (2013) presents the importance of studying the evolution, challenges and future of knowledge representation in product design systems. The authors suggest that there are different dimensions in classifying knowledge namely, formal and tacit, product and process, and compiled and dynamic, which represent high-level generic classification for product design knowledge. Figure 1 illustrates a lower level classification of key knowledge types and knowledge sources, often required to perform engineering design activities within the aerospace industry.

Figure 1. Required knowledge types and sources in engineering design.

From a system’s perspective, it is imperative to identify core elements within product design activities. Understanding the interconnections and interrelations between these elements provide powerful insight into product attributes and characteristics which can be accessible at a generic or specific level (Shehab et al. 2013). Defining domain structures and interrelations between elements in product design should be the focal point of concentration when attempting to thoroughly manage complexity in engineering design activities. Thus, developing an ontology framework that encourages modular ontology architectural design will significantly aid the understanding and realisation of managing complex product design knowledge. This is achieved through the definition of modular and self-contained engineering design ontologies that aim to capture complex relationships between knowledge types, and ensure knowledge reuse in product design processes and toolsets. This research project is in collaboration with a large aerospace organisation with specific case studies and research application to the combustor and casing engineering design environment.

2. Related work and research scope

The following section describes general ontology methods, tools and languages used for ontology development. The literature is reviewed to identify research gaps preventing a well-defined integrated ontology framework, specifically for engineering design in the aerospace industry.

Ontology development has many similarities to standards development processes. Standard methodologies like the Framework for Analysis, Comparison and Testing of Standards enables the facilitation of standards taking it through a number of phases namely conception, development, deployment and testing which is similar to stages used within ontology development methods (Witherell et al. 2013). However, computer-aided standard development tools are lacking unlike ontology development which is supported with several methods, tools and languages. The focus of this review is on ontology development methods.

The Uschold and King (1995) ontology method involves four major guidelines: (1) identify the purpose for developing the ontology; (2) build the ontology; (3) integrate with existing ontologies and finally (4) document the ontology. The authors also suggest three strategies for identifying the main concepts within the ontology domain. The first is a top-down approach, the second strategy is the bottom-up approach and lastly the middle-out approach which firstly identifies the most important concepts within the domain and derives generalised and specialised concepts (Corcho, Fernandez, and Gomez-Perez 2003). However, the third approach is often never used in ontology development (Öhgren and Sandkuhl 2005). Furthermore, Ahmed, Kim, and Wallace (2007) identified that the Uschold and King ontology method is specifically created for integrating a variety of software tools which makes it a domain-specific approach for ontology development.

The METHONTOLOGY (Fernandez and Gomez 2002) is known as one of the most mature ontology development methodologies as suggested by many authors (Corcho, Fernandez, and Gomez-Perez 2003; Öhgren and Sandkuhl 2005). It is fairly detailed, involves the whole ontology process and has an integration aspect. However, it lacks guideline for collaborative ontology development and for software developers who require ontologies in their IT systems.

Noy and McGuinness (2001) suggest that there is no single correct way or procedure for building or extending an ontology. They suggest the iterative approach unlike other reviewed ontology methodologies in which the ontology development is taken through a number of phases before reaching its final stage. The first step in their methodology consists of determining the scope of the domain, which is followed by identifying whether to incorporate existing ontologies. After this step, a list of terminologies and class hierarchy is then produced. After the classes are defined, the properties of each class are specified along with their constraints and cardinalities, which include their range and domain. Finally, the instances of the classes are created.

The stages of the Pinto and Martins (2004) ontology method are: specification, conceptualisation, formalisation, implementation and maintenance. The ontology method was specifically created for the integration of ontologies which makes it a domain-specific approach. As suggested by the authors, the purpose of the ontology is firstly identified in the specification stage. In the formalisation stage, the concepts as well as the semantic relations are described. The representation stage is then used to represent the ontology using an ontology-based language. The last stage of the methodology incorporates a maintenance stage. A limitation of the Pinto and Martins (2004) ontology method is that it has one overall evaluation stage, while few ontology methods (Ahmed, Kim, and Wallace 2007) propose an evaluation step for each stage of the ontology development.

Ahmed, Kim, and Wallace (2007) ontology development method is perhaps the only ontology method tailored to engineering design. A six-phase methodology for developing engineering design ontologies has been identified as follows: identify root concepts of taxonomies, identify existing taxonomies, create taxonomies, test for application, build thesaurus of terms and refine integrated taxonomy. Ahmed, Kim, and Wallace (2007) define research methods and a clear evaluation step for each stage of the ontology method. The purpose of this ontology method is for searching, indexing and retrieving engineering design knowledge which also makes it a domain-specific approach for ontology development. However, the authors have suggested that the ontology method could be used for other purposes. The engineering design-integrated taxonomy ontology has been developed as a result of following the methodology and has been quantified in two aerospace organisations. However, it is not clear how the ontology method has incorporated modular architectural ontology design which is of crucial concern within the aerospace industry.

Furthermore, a variety of ontology tools and languages exist within the engineering ontology community. The first ontology tool developed is the OntoLingua server from the Knowledge System Laboratory at Stanford Laboratory. It was built to support ontology development with a web based form application (Farquhar, Fikes, and Rice 1997). Ontosaurus was developed in parallel with OntoLingua by the Information Sciences Institute at the University of South California (Zaid and Lau 2013). OntoSaurus consists of two components. The first is the ontology server which uses loom as its knowledge representation language. The second component is a web browser for navigating loom ontologies. Translators from loom to OntoLingua exist. The Open University then developed WebOnto (Domingue, Motta, and Corcho Garcia 1999), which is an editor for creating Operational Conceptual Modelling Language ontologies. The main capability of WebOnto over other available tools is that it was the first ontology tool to enable collaborative ontology editing between domain specialists, knowledge engineers and managers. The aforementioned tools and platforms mentioned, thus far, are all platform-specific to a language and were strictly created for research activities and not for commercial purposes. Thus, they had low technology readiness level. In addition, these tools did not also provide extensible facilities (Zaid and Lau 2013).

In recent years, a new generation of ontology tools and languages has emerged. The requirements and purpose of these new brands of ontology tools and languages were to provide stronger capability in ontology development. These ontology tools and languages have been developed as integrated and robust environments to provide technological support to knowledge-driven systems. They possess extensible architectures in which new plug-ins and add-ons can be integrated to provide additional functionalities to the platform. These advanced ontology tools include Protégé, WebODE and OntoEdit.

Protégé 4.2 (2013) ontology toolkit was developed by the standard medical informatics. Protégé is an open source, platform-independent application with an extensive architecture that allows for plug-ins and exploitation of different ontology languages (i.e. XML, RDF and OWL). WebODE (OEG 2014) was developed in the Artificial Intelligence Lab from the Technical University of Madrid (UPM). Like Protégé, WebODE also has an extensible architecture. However, it is not a stand-alone platform but acts as a web server with a web interface which enables access of ontologies via web services. OntoEdit was developed by the AIFB in Karlsruhe University and has similarities with the aforementioned ontology tools. It also has an extensible plug-in architecture and provides functionalities for browsing and editing ontologies. In addition, it introduces inference engines capable of processing and inferring new knowledge in an ontology (Sure et al. 2002). The Neon ontology toolkit was developed to support the reuse and reengineering of ontology resources and collaborative ontology development (Suárez-Figueroa et al. 2008). The Neon toolkit possesses an extensive architecture and supports the integration of multiple plug-ins and functions. Recently, an online survey was carried out in which ontology development tools were assessed based on different criteria. Participants included ontology tool users from biomedical, media, linguistics, information system design, business, travel and many other sectors. The survey revealed that 75% of the respondent mainly used Protégé as their ontology platform of choice (Rahamatullah and Khondoker 2010), making it the most dominant ontology tool in the ontology community. The survey also revealed that 40% of the respondents were from the information system design sector.

Furthermore, due to the vast interest of the semantic web, languages for the development of ontologies have significantly increased. The W3c formed a working group to create a new ontology language (Berners-Lee 2001) for the semantic web named OWL (Web Ontology Language). The W3c extended OWL with new features and OWL2 is currently in the process of being released into ontology platforms and reasoners such as Protégé, Pellet and RacerPro (W3c 2012). It has been established that several families of ontology knowledge-based representation exists. Formalisms representations such as frame-based languages (F-Logic) (Wang et al. 2004), description-based logic languages (Baader, Horrocks, and Sattler 2007) and common logic which is an ISO standard (ISO/IEC 24707 2007), altogether forms different level of expressiveness for ontological representation for semantic applications.

All of the ontology methods reviewed neglected the practice of modular ontology development. This means that rather than having a massive ontology to cover a domain, it is necessary to abstract and generalise concepts into separate ontologies in order to allow for better flexibility, modularisation and maintainability. The literature has identified that none of the ontology approach is fully matured if compared to a software engineering methodology like waterfall, incremental, rapid application development, Agile or knowledge-based engineering (KBE) methodologies like MOKA and Common KADS. There is no widely adopted approach or standard for ontology development, and there is lack of practical ontology methods for supporting the engineering design process (Darlington and Culley 2008; Lim, Liu, and Lee 2011). The literature has identified that many of the ontology development attempts in product design are commonly technology oriented (Kim, Manley, and Yang 2006; Gunendran and Young 2009; Bock et al. 2010; Chungoora and Young 2010; Panetto, Dassisti, and Tursi 2012). There is lack of research projects focused on bridging the gap between ontology-based frameworks and engineering design activities.

The literature further revealed that most of the ontologies developed in the aerospace industry (e.g. SAMULET: Strategic Affordable Manufacturing in the UK through Leading Environmental Technologies) were focused on manufacturing engineering ontologies (Usman et al. 2013), and engineering design ontologies were often neglected. Though attempts have been made to develop ontologies for product design activities, they were often not detailed enough to accurately represent product design. Additionally, it was discovered that attempts made to develop ontologies (IPAS project: integrated product and service) for product design resulted into a massive ontology which lacked modularity due to inefficient design (Butters and Ciravegna 2010) and lack of domain experts’ involvement (Fowler, Reul, and Sleeman 2008). Thus, there is lack of comprehensive engineering design ontologies in the literature and its application in the aerospace industry. Furthermore, the authors observed that there is lack of a framework to enable development of engineering design ontologies within the aerospace industry. Though many methods exist for developing ontologies, they are not fully matured and tailored to be adopted in product design. In a recent critical review of semantic technologies (Agyapong-Kodua et al. 2013), it was identified that ontology frameworks often do not specify pre-development and post-development phases of ontology design activities. Most of the research undertaken within the scope of product design has mainly focused on the development and implementation of semantic technologies (Sanya and Shehab 2014). Little has been done to address the methodological frameworks used to develop ontologies in support of engineering design. Though engineering ontologies has been developed as proposed in the literature, its application has been limited. It has been identified that majority of the developed ontologies in industry have been applied to broad businesses and do not possess the same level of granularity and detail often required for mechanical design (Kim, Manley, and Yang 2006; Sanya, Shehab, and Roy 2010; Kirisis et al. 2013). The scope of this research is to develop an ontology-based framework that is tailored to engineering design activities and encourages modularity in ontology design. A case study approach is employed in which modular engineering design ontologies are developed within the aerospace combustor and casings product design environment and are reused to support multidisciplinary project initiatives within the aerospace organisation.

3. Research methodology

This section defines a four-phased iterative research methodology employed in this study as presented in Figure 2. In phase one of this research study, process knowledge was captured within the engineering design and manufacturing aerospace case study domain to support the ontology framework development. The literature was employed in all phases of this research study to ensure reuse of existing ontologies. Furthermore, semi-structured interviews with domain experts and knowledge capture templates were used to develop ontologies relevant to engineering design. In phase two of this research study, the initial ontology framework was formulated, and the design and development of modular engineering ontologies was established. In phase three, the iterative development and refinement of engineering ontologies were achieved. This includes identification and continuous development of generic and specific-purposed engineering design concepts as well as elicitation of implicit and explicit relationships between ontology concepts. Though this research study was based at the aerospace combustions and casings engineering business function, emphasis was made to ensure the generalisability of the developed ontologies. In order to ensure generalisability, interviews with cross-domain experts were conducted. This ensured high-level ontology concepts were common across all engineering design activities within the aerospace industry. Validation of the ontology framework and engineering design ontologies were carried out in phase four of the research study. Experts’ opinion was captured to identify strengths and limitations of the framework and ontology development. Interviews and workshops were used for this purpose and led to the finalised development of engineering design ontologies to be implemented on a product design information platform.

Figure 2. Adopted research methodology.

4. Framework development

The framework consists of mainly three phases with tools and techniques to support each phase as illustrated in Figure 3. Each phase is composed of activities and subactivities. In the first phase, the ontology design and development are achieved ensuring best practices in literature (Ontology Summit 2007; Brusa, Laura Caliusco, and Chiotti 2008), and are considered in engaging domain experts and end users. In the second phase, ontology validation is accomplished. This includes iteration and refinement of the developed ontologies from domain experts’ perspective and ensuring cross-case synthesis with other engineering design domain to ensure the generalisability of the developed ontologies. In the third phase, the ontology structure and knowledge is implemented on a product design information-platform using an API (application programming interface) to ensure seamless integration into a product design information sharing platform.

Figure 3. Framework for developing modular engineering design ontologies in the aerospace industry.

The framework focuses on developing comprehensive and modular engineering design ontologies and identifying complex relationships between product design knowledge. The framework encourages knowledge engineers to consider modularity in ontology design and ensure reusability and validation of smaller, self-contained ontologies. The framework also considers the identification and representation of lower level relationships between concepts and instances rather than the high-level relationships commonly represented between concept and concept in ontology design. The middle-out approach has been employed to elicit the most important concepts within the combustor engineering design domain. The framework addresses the aforementioned challenges by providing a logical, iterative procedure to follow. The applicability of the framework is realised when applied on a product design information platform to aid the structure and accessibility of knowledge for product design engineers (end users). The novel contributions of the overall framework are as follows:

•	Modularity in ontology design and development for engineering activities.
•	Comprehensive engineering design ontologies with lower level represented relationships.
•	Ontologies that focus on representing product design knowledge from design engineers perspective.
•	Applicability of developed ontologies to support practical project initiatives.

The first phase of the framework has been implemented using an ontology-based platform. Protégé 3.5 was employed for this purpose. Protégé is an open source, platform-independent application with an extensive architecture that allows for plug-ins and exploitation of various ontology languages. The selection of Protégé ontology toolkit is based on the fact that it is commonly the most used ontology platform choice. This is based on a recent survey conducted where 75% of the respondent mainly used Protégé as their ontology platform of choice (Khondoker and Mueller 2010) due to its extensive architecture, open-source platform, plug-ins and maintenance support. The development and computational validation of the engineering design ontologies has been achieved using the Protégé platform. The ontology web language (OWL) is used for ontology representation. Ensuring modularity in the developed ontologies was initiated from the start; thus, separate and individual ontology modules were developed in order to reinforce reusability.

The second phase of the framework defines ontology validation activities. A series of semi-structured interviews and workshops with domain experts’ were employed to validate the product design ontology structure. Participants included several design and manufacturing experts in the aerospace sector. Performance metrics were employed for ontology validation. Metrics focusing on the quality attributes of ontology development were considered. Non-functional requirements such as ontology modularity, ontology usability, ontology generalisability, ontology scalability, ontology functionality and ontology applicability were evaluated and considered during the ontology validation phase. Computational validation is achieved using ontology reasoners. The reasoners enabled the appropriate verification of consistency within the developed ontologies. Sriram et al. (2011) suggest that there is an urgent need for researchers to develop knowledge base of best practices in ontology engineering, specifically addressing the evaluation aspects of ontology development to ensure ontology quality over time. Within ontology development, there is lack of systematic method for evaluating ontologies, and inadequacy exists for ontology verification and validation. Human review and the use of computational metrics have been identified as vital in achieving effective ontology evaluation. Ontologies are constantly evolving. Therefore, any ontology evaluation work done at a specific point of time must be reevaluated in future ontology versions. Thus, making the ontology evaluation process an iterative process of quality assurance indicates a need for extensibility measures and metrics. In the final phase of the framework development, the developed ontology is implemented on a product design information-sharing platform using an ontology application programmable interface (API) and is used to improve the structure and accessibility of product design information on a web-based platform.

5. Modularity in ontology design and development

Modularity in ontology design is often considered from a syntactic or semantic perspective (Bao 2008). However, the focus of the framework is on syntactic modularity which addresses the need to restructure large ontologies into smaller, self-contained and multiple compact modules. This enables well-controlled ontology interactions and ontology refinement and reuse. In order to achieve syntactic modularity in ontology design, the following elements were considered during the ontology design process:

Functionality: understanding what ontology will be used for prior to developing will determine how best to structure its content. This approach is often used in the software engineering object oriented paradigm (OOP).

Collaboration: identifying groups and departments working on the ontology will often determine how best to structure its module. This should be considered as reconciling semantic inconsistencies and conflicts will be made possible. Hiding information can help ontology designers focus on ontology modules that fit their expertise. In addition, ownership is encouraged if an ontology module is designed with separate groups in mind. For example, each engineering product design group in the aerospace industry has a responsibility of maintaining specific gas turbine product modules. This means a combustor engineering department will not have expertise on a compressor gas turbine product assembly. Though the high-level product ontology between departments may be similar, the lower level component and feature-specific details are often different.

Communication: modules of an ontology are often distributed physically. Understanding how the ontology will be consumed is also a contributing factor to its modular design. Thus, instead of transferring a large ontology into a single location, only the modules required should be transferred which will strengthen the partial reuse of an ontology saving reasoning power (Ensan and Du 2013) and reducing time consumption.

Understandability: an ontology is only useful if it can be understood by human users. Thus, understanding and comprehending ontology modules are factors to address when designing modular ontologies. Each ontology module should have domain-specific knowledge and should contain information specific only to the domain. Semantic relationships with other domains can then be established to broaden its applicability.

Reasoning: reasoning with an ontology knowledge-base is another contributing factor towards designing modular ontologies. The nature of the reasoning required will determine how best to structure the modular contents of an ontology (Zhang, Gu, and He 2014). Optimised description logic reasoners may fail if they have to reason over an ontology knowledge-base with thousands of concepts. By decomposing large ontologies into smaller and self-contained coherent ones, ontology reasoners will be significantly optimised.

Visualisation: smaller and self-contained ontologies can often strengthen ontology visualisation. In order to encourage modularity in ontology design, the ability to clearly visualise the content of an ontology knowledge-base should be addressed in the ontology design process.

6. Design and development of engineering design ontologies in the aerospace industry

This section presents the design and development of engineering design ontologies within the aerospace industry. In order to encourage modularity in ontology design, four main ontologies were developed for engineering design activities as presented in Figure 3. These are product ontology, process ontology, resource ontology and functional model ontology.

The product ontology describes a product hierarchical breakdown of the combustor product component. The high-level product ontology is generic to any product component in the aerospace industry. However, the lower level details are specific to the combustor and casing product component. The process ontology describes specific interdependent procedures and activities that consume one or more resources in the aerospace sector. These includes processes such as geometry creation process, analysis process, cost process, manufacturing process, inspection process and other types of engineering and business processes in the aerospace sector.

The resource ontology describes specific assets, services, roles and toolsets often required to execute a process within the aerospace industry. Specific emphasis is placed on developing concepts that accurately represent the tools and technologies employed by specific roles in the aerospace sector. Lastly, the functional model ontology represents a hierarchical definition of concepts that describes geometry and analysis models generated as a result of employing specific resources. The generation of models/outputs is crucial for engine products. Examples of these models are emissions models, air flow network models, acoustic models and many more.

The developed ontologies were focused on representing ‘concepts’ and not ‘terms’. In ontology development, a term is usually a concrete word used to express a concept. However, a concept is an idea that represents the meaning of the term or a notion that represents an abstract entity.

6.1 Development of engineering product ontology

A workshop was conducted with the combustor domain experts to enable design and development of the combustor product ontology. Experts involved in the development of the product ontology include principal design engineers, senior design specialist, aerothermal analysts, mechanical integrity technologists, integrated design and make engineer and process excellence lead. Best practices were adapted from the Noy and McGuinness (2001) ontology development approach and use-case scenarios were elicited from the participants to ensure appropriate development of the ontology. Prior to the product ontology design workshop, design experts were informed to bring along supporting materials. Materials such as engineering description reports, CAD drawings and other supporting documents were used to further verify the breakdown structure of the combustor product component. Table 1 describes the first step of the ontology development process which is mainly about understanding the domain and defining use-case scenarios from design experts’ perspective.

Table 1. Determining the domain and use-case scenarios for product ontology.

Step 1: Define use-case scenarios for the ontology
What is the domain?	• Combustor product knowledge in engineering domain
What can the ontology be used for?	• Understanding attributes and features of the combustor product component • Understanding the hierarchical breakdown structure of combustor product component • Improving a gas turbine power system product design and development by the use of specific combustor product knowledge
What questions should the ontology answer?	• What are the main components in a combustor assembly? • What types of features are required for each component in a combustor assembly? • Which are the common design styles for a combustor assembly? • What is the relationship between a combustor assembly, combustor component and combustor feature? • What are the important product features for effective combustor product component design?
Who will use and maintain it?	• It will be used by members of the combustor and casing team; design engineers and KBE engineers are responsible for developing combustor KBE design systems • It will be populated by design engineers and knowledge engineers • It will be maintained by combustor domain experts

Step 2: Consider reusing existing ontologies (if applicable)

Ontologies describing the combustor product breakdown structure within a manufacturing setting were not found.

Step 3: Define the ontology concepts and UML representation

Figure 4 illustrates a high-level UML meta-model for engineering product design. Various product ontologies already exist in the literature (Fenves et al. 2008; Lee et al. 2012; Panetto, Dassisti, and Tursi 2012; Ameri and Allen 2013). Product design ontologies to support system interoperability within manufacturing enterprises and supply chain (Tursi et al. 2009; Chungoora et al. 2013; Lu et al. 2013; Fortineau, Paviot, and Lamouri 2013) have been proposed in the literature. Thus, aspects of existing product design ontologies have been considered for this study. However, the focus of the product design ontologies developed in this study is geared towards the aerospace gas turbine engine domain, which is evident in the instances created.

Figure 4. High-level UML meta-model for engineering product design.

As illustrated in the UML class diagram, one aerospace gas turbine product has many engines (e.g. Airbus A350 aeroplane has 2 Trent XWB engines). One engine has many assemblies (e.g. turbines, combustor, fan and compressor) and one assembly has one design style (e.g. combustor assembly will have a rich-burn or lean-burn design style). One assembly has many components and one component has many features. The UML composition association notation was employed between the classes’ ‘component’ and ‘feature’. Composition is a type of association where the composite object is responsible for the creation and destruction of the related object. This means if the composite object is destroyed, so is the related parts, as the related parts have a ‘strong dependent’ relationship with the composite object. This is the case for concepts’ ‘component’ and ‘feature’. A feature can only be designed if components exist; examples of component features include holes, boss, bolts and lip. Figure 5 illustrates a high-level UML meta-model for aerospace gas turbine engine system. The engineering product model captures complex relationships between concepts that describe which features belong to which components and which components are associated to product assemblies. However, due to confidentiality, the lowerlevel combustor product ontology is not described in this paper.

Figure 5. High-level UML meta-model for aerospace gas turbine engine system.

Step 4 and 5: Identify concept to properties and concept to instance relationships

Figure 6 illustrates the combustor product ontology developed on the Protégé 3.5 platform. The product breakdown structure of the combustor is presented as captured from domain expert’s perspective. The identification and hierarchical breakdown of the combustor product ontology are known as lightweight ontologies. A detailed taxonomy of the combustor components, features and design styles are accurately reflected in the ontology development. For the combustor product ontology, object properties were developed to define explicit relationships between one or more concepts. Object properties such as ‘hasAssembly’, ‘hasComponent’, ‘hasDesignStyle’ and ‘hasFeature’, were developed to represent relationships between one or more concepts.

Figure 6. Concept and instance creation for combustor product tile component.

An instance is a specific realisation of a concept. Each realised specification of a concept is defined as the process of instantiation. The development of instances enabled the definition of complex relationships within the domain ontology. The combustor product design instances introduced lower-level relationships in the combustor product ontology. Defining relations between instances and concepts is often not employed in ontology development as many ontology development efforts focuses on high-level concept to concept relationships. However, in order to enable the design of heavy weight ontologies and to form the basis of a solid knowledge base, specifying relations between concepts and instances were considered in order to support the development of comprehensive domain ontologies capable of advanced functionalities.

Figure 6 illustrates an example of an instance creation (combustor tile product component) and its lower level relationship with the ‘feature’ concept. Over 100 instances were developed for the combustor product ontology in order to represent specific lower level relations between the combustor assembly, combustor component and combustor features (due to confidentiality, this will not be explained in detail). Instances inherit the ‘object properties’ and ‘data properties’ of the concept (i.e. class) they were derived from. For example, the tile product component inherits the ‘hasFeature’ object property of the concept ‘component’ as illustrated in Figure 6. The lower level relationships were defined for every assembly, component and feature of a combustor. This has been captured through interviews with combustor domain experts. If desired, the ontology could be populated and extended with more instances as required. However, the focus was on capturing and representing comprehensive knowledge for the combustor product ontology in order to implement the knowledge base on a product design information platform for navigation and structural purposes.

6.2 Development of engineering process ontology

The design and development of the engineering process ontology commenced. The aim was to capture key generic and specific types of engineering processes and activities conducted on the combustor product component. It was identified that many of the engineering processes are generic to all types of aerospace product, thus generalisability of the captured knowledge was achieved. A workshop with the combustor domain experts and process specialist experts was used as a channel for developing the engineering process ontology. Participants involved in the process development workshop include process quality and improvement lead, senior design specialist, aerothermal team lead, capability improvement engineer, capability acquisition engineer and process excellence lead. Table 2 outlines the scope definition and use-case scenarios considered for the engineering process ontology.

Table 2. Determining the domain and use-case scenarios for the combustor engineering process ontology.

Step 1: Define use-case scenarios for the ontology
What is the domain?	• Combustor process knowledge in manufacturing domain
What can the ontology be used for?	• Understanding engineering processes and key activities for a combustor product component • Understanding the hierarchical breakdown structure of design and manufacturing processes • Relating specific design and manufacturing process knowledge to product knowledge
What questions should the ontology answer?	• What are the key processes in a combustor design and manufacturing domain? • What are the different types of process analysis conducted in the context of aerospace engineering • Differentiating between manufacturing, inspection and assembly processes
Who will use and maintain it?	• It will be used by members of the combustor and casings team, process engineers, design analysts and KBE engineers responsible for developing combustor KBE design systems • It will be populated by process specialist, design analysts, process engineers and knowledge engineers • It will be maintained by combustor domain experts and other design and manufacturing experts as the engineering process ontology is generic to all types of product component in the aerospace sector

Step 2: Consider reusing existing ontologies (if applicable)

Ontologies describing comprehensive aerospace engineering processes within a design and manufacturing setting were not found.

Step 3: Define the ontology concepts and UML representation

Figure 7 illustrates the high level engineering process ontology for the combustor aerospace domain. As illustrated in the UML notation, the generalisation relationship is used to indicate supertype and subtype concepts. The subtype concepts such as design process, analysis process, manufacturing process, inspection process, assembly process and disposal process are specialised form of the super type concept engineering process. Figure 8 depicts a lowerlevel specialisation of the manufacturing process concept in the domain ontology. Hierarchical classifications of many types of engineering processes are captured in the domain ontology. The resource ontology uses the engineering process ontology and this aspect of the ontology development is explained in Section 6.3. As identified earlier, many of these are generic to all types of aerospace products, thus generalisability and reusability of the engineering process ontology is achieved.

Figure 7. High-level engineering process concepts for the manufacturing domain.

Figure 8. Low-level manufacturing concepts specialisation classes.

Figure 9 illustrates the combustor engineering process ontology developed on the protégé 3.5 platform. The engineering process breakdown structure of the combustor and other gas turbine product component in the aerospace industry is presented as captured from domain expert’s perspective.

Figure 9. Engineering process ontology in the aerospace sector.

Step 4 and 5: Identify concept to properties and concept to instance relationships

No properties and instances of classes were created for the engineering process ontology as it was designed to be consumed by the resource ontology. The engineering process ontology could have been designed as part of the resource ontology. However, an early decision was taken to encourage separate development in order to ensure modularity in the ontology design process.

6.3 Development of engineering resource ontology

A resource is a source of supply that produces benefit to an activity. Resource management is the effective and efficient deployment of organisation resources. The idea of resource management has been applied in many disciplines such as economics, computer science, biology, engineering and sustainability. It was essential to identify and elicit various types of resources that exist in the aerospace engineering community, as maximising benefits from such resources will yield satisfactory business results. The purpose of the engineering resource ontology was to identify key resources often consumed while performing engineering design activities. Comprehensive heavyweight ontologies were developed to accurately reflect the aerospace engineering design resource domain in comparison with the literature which lacked engineering design resource ontologies for product design. Additionally, interviews were held with resource managers, strategic IT architects and engineering team leads to fully understand how resources are managed and distributed across the aerospace engineering gas turbine workforce. Several functional team leads within the aerospace industry were engaged in order to understand resource management and resource allocation in the aerospace engineering industry. As a result, the ontology developed for this purpose had wider application than its intended purpose and was used to support resource management projects in the aerospace industry. Table 3 describes the first phase of the engineering resource ontology development which is mainly about understanding the domain and eliciting use-case scenarios for engineering product design resources.

Table 3. Determining the domain and use-cases for engineering resource ontology.

Step 1: Define use-case scenarios for the ontology
What is the domain?	• Engineering resource knowledge in aerospace product design domain
What can the ontology be used for?	• Understanding key resources employed for product design activities within the aerospace sector • Plan the order of resource deployment across the engineering workforce • Role-based computing (RBC) ensuring software specifications are currently aligned with IT hardware requirements for specific role-types • Ensuring the correct IT tools with the correct level of IT functionalities are provided to the correct engineering roles • Relating resource ontology to process ontology to understand what resources are consumed by engineering processes
What questions should the ontology answer?	• What are the key resources consumed in performing specific product design activities in an engineering context? • What key technological resources are consumed to perform engineering design activities? • What is the hardware specification for engineering software deployed for performing product design tasks?
Who will use and maintain it?	• It will be used by members of the resource management team (IT) and team leads, and KBE engineers are responsible for developing key design systems • It will be populated by resource specialist and knowledge engineers • It will be maintained by resource managers as the engineering resource ontology for product design activities is generic to all business functions in the aerospace industry

Step 2: Consider reusing existing ontologies (if applicable)

As part of the SAMULET project, high-level manufacturing ontologies were developed for the aerospace sector. These ontologies were well designed to cover the manufacturing engineering resource domain. Thus, they were used to support this research study. The SAMULET high-level manufacturing ontologies describe manufacturing resources such as manufacturing role, machine tool, cutting tool, fixture, controller and work pieces which have been reused in this research study.

However, no ontologies were discovered that represented the engineering design resource domain. An interview conducted with one of the SAMULET project lead coordinators identified that the project would have liked to explore ontologies for engineering design. However, due to time constraint, the ontologies developed were mainly attributed to the manufacturing engineering domain (Usman et al. 2013).

Therefore, the resource ontology developed in this research study focused on representing ontologies for engineering design resources. Additionally, lower level classes and instances representing both design and manufacturing resources were captured and instantiated to enable the development of heavy weight ontologies for the purpose stated in Table 3.

Step 3: Define the ontology concepts and UML representation

Prior to defining a hierarchy of classes for the aerospace design resource ontology, it was essential to identify and categorise the main types of resources consumed for product design activities. This classification of design resource knowledge was captured as a result of interviews conducted with resource managers within the aerospace industry. As presented in Figure 10, resources for product design activities include design roles, engineering IT tools used for performing product design activities, versions of these tools and tool capabilities including hardware platforms and operating systems. Engineering IT tools consist of tool types used for geometry creation, design aerothermal, stress and thermal analysis, cost engineering and project management. Tool versions define if tools are trial versions, research and technology versions, development versions or production versions.

Figure 10. Categorisation of design resources in the aerospace engineering industry.

Figure 11 illustrates a high-level UML class representation for the engineering design and manufacturing resource ontology. As defined in the UML notation, a supplier provides design and manufacturing resources. The supplier concept is specialised into domestic and external suppliers. Domestic suppliers are internal suppliers. Within the aerospace industry, there are many supply chains and it is often common that an aerospace organisation focuses on its core competencies while outsourcing other competencies to external suppliers.

Figure 11. Engineering resource ontology for the aerospace sector.

Specialisation of the manufacturing resource concept includes a definition of manufacturing roles, controller, machine tool, fixture, work piece, cutting tool and manufacturing facilities as identified in the SAMULET project (Usman et al. 2013). However, an attempt was made to identify and instantiate each of these concepts with practical industrial aerospace cases. Knowledge captured from the combustor and casing supply chain unit from manufacturing engineering experts were used for this purpose.

The main focus of the engineering resource ontology was to accurately reflect resources required for performing product design activities. Thus, a design resource concept was introduced specifying subconcepts such as design role, design tool, tool version, programme code and hardware platform. To describe the design resource ontology, one design role can use many design tools and one design tool has many tool versions. The notion between design tool and versions of a tool was important for this study. The composition UML notation was used to represent the relationship between a design tool and tool version as the concept tool version can only exist if there is a design tool object. Furthermore, it was identified that a design tool does not produce a tool capability; however, it is the version of a tool that is responsible for this activity. It was also identified that it is a version of a tool that runs on a specific hardware platform. One design tool will have many programme codes. It was identified that programme codes are essential in engineering design activities, especially for performing various types of aero, stress and thermal analysis. The design role was specialised into designer, analysts and manager. Analysts was further categorised into aero, stress, thermal and cost. The resource ontology imports the process ontology and functional model ontology to accurately reflect and represent which type of analysis is performed by each design tool and programme code, and which functional models are generated and produced as a result.

Step 4 and 5: Identify concept to properties and concept to instance relationships

For the engineering resource ontology, object properties were developed to define explicit relationships between one or more concepts. Object properties such as ‘hasProgramCode’, ‘hasToolVersion’, ‘runsOnHardwarePlatform’, ‘usesDesignTool’ and ‘providesResource’ were developed to represent relationships between concepts. Additionally, object properties such as ‘producesDesignModel’, ‘producesStageModel’ and ‘performsAnalysis’ were defined to reflect relationships between concepts within the engineering resource ontology and concepts within the imported engineering process and functional model ontologies.

In order to develop comprehensive relationships between concept and instances, specific instances of ‘DesignTool’, ‘DesignRole’ and ‘ProgramCode’ were created and used to specify which role uses which type of tools and programme codes. This was further expanded and for each design tool in the ontology, its relation with the engineering process, analysis types and roles were specified. This formed the basis of a heavyweight ontology model for the engineering design resource domain. Figure 12 illustrates the development of instances and relations with other ontology concepts. Over 400 instances were created specifying comprehensive and lower level relationships between concept and instances.

Figure 12. Instance creation of engineering design resource ontology.

6.4 Development of engineering functional models ontology

In the context of system and software engineering, a functional model is a structured representation of functions such as inputs, outputs and actions within a modelled subject area. The engineering functional model ontology aims to define engineering capability models produced during the gas turbine engineering design process. These models are produced through the consumption of many types of engineering resources as described in Section 6.3. An early decision was made to develop the functional model ontology independently of the resource ontology in order to encourage modularity in ontology design. Prior to developing the functional model ontology, process mapping activities for the combustor and casing preliminary and full concept definition phases were undertaken. One of the outputs of the process mapping activities was to identify key artefacts and models produced during the product design process. Functional models representing emissions, noise, air flow models, etc. were identified as a result of the process mapping activity. Thus, an ontology representing functional models was developed and validated with design experts. Table 4 describes the first step of the engineering functional model ontology development which is mainly about understanding the domain and defining use-cases for the ontology. As discussed, the developed ontology is consumed by the resource ontology as to define which engineering resource produces specific type of functional capability models. Therefore, there was no creation of specific instances for the engineering functional model.

Table 4. Determining the domain and use-cases for engineering functional model ontology.

Step 1: Define use-case scenarios for the ontology
What is the domain?	• Engineering functional model knowledge in aerospace product design activities
What can the ontology be used for?	• Understanding key functional models generated during the gas turbine engineering design process • Specifying and allocating resources to key functional models in the aerospace engineering design environment
What questions should the ontology answer?	• What are the key functional models produced in performing specific product design activities? • Which resources are employed to produce these key functional models?
Who will use and maintain it?	• It will be used by members of the resource management team (IT) and team leads, and KBE engineers are responsible for developing key design systems • It will be populated by design engineers and knowledge engineers • It will be maintained by design engineers, manufacturing engineers and key domain experts

Step 2: Consider reusing existing ontologies (if applicable)

Ontologies describing comprehensive aerospace functional models within a design and manufacturing setting were not found.

Step 3: Define the ontology concepts and UML representation

Figure 13 presents a high-level UML class representation of engineering functional model concepts developed in the ontology. The main concept in the ontology is the ‘model type’ concept which is specialised into ‘design model’ and ‘manufacturing model’. The manufacturing model is specialised into stage models which are specific models derived from an engineering master geometry model. The design model concept has subclasses of specialised models which include functional models produced for emissions, noise, acoustic, mechanical, thermal, stress, cost and aero analysis. The nature of these functional models is sensitive to the sponsoring aerospace organisation. Therefore, specialisation classes of these functional models will not be explained in this paper. The design and manufacturing resource concepts in the engineering resource ontology has been explicitly related to the design and manufacturing model concepts in the engineering functional model ontology. Over 50 key functional models have been developed as concepts in the ontology representing models for different aspects of product design activities. The focus of the ontology was to populate the design model concepts. It was agreed that the manufacturing stage model concepts will be populated and maintained by the relevant manufacturing experts. The introduction of manufacturing models in the ontology was to ensure ‘design for manufacture’ considered in the view of product design tasks. For each functional design model, its related data properties were defined which captured data input and output parameters for each model as identified in the process mapping task. Over 200 key data, properties for all identified functional models were developed as part of the functional model ontology.

Figure 13. Engineering functional model UML representation for the aerospace sector.

6.5 Overall formalisation of ontology model for engineering design

Figure 14 depicts the formalisation of the overall ontology model for engineering design activities as explained in the aforementioned sections. The design, development, validation and integration of modular ontologies enabled the creation of a comprehensive knowledgebase that has been employed in multidisciplinary product design projects. Key concepts for aerospace product design activities has been identified, represented and formalised in the overall ontology using knowledge elicitation techniques. Concepts defining the combustor product breakdown structure, design and manufacturing engineering processes, design and manufacturing resources, and key design artefacts and models is represented in the ontology development. The framework enabled the modular creation of engineering design ontologies in the aerospace industry. Additionally, the software engineering OO thinking was incorporated into the overall ontology development.

Figure 14. Overall UML model for engineering design ontology development.

6.6 Management and imports of engineering design ontologies

Figure 15 depicts the import and management of the developed ontologies and the modularity encouraged in the ontology design. As presented, the product ontology imports the geometry ontology (used for CAD automation) and process ontology. The resource ontology imports the process ontology and functional model ontology as described in the aforementioned sections. Additionally, the engineering design ontologies are referenced and identified using uniform resource identifier (URIs). Through URIs, sharing and reuse of ontologies becomes possible through the imports of ontologies from one source to another. When one ontology imports another, all of the classes, data properties, object properties and instance definitions of the imported ontology become available for use. The URI of the imported ontology is included in the list of ‘import statements’.

Figure 15. Engineering design ontology management and import.

6.7 Iterative development and refinement of engineering design ontologies

The engineering design ontology development required iterative refinement of the identified concepts. Prior to ontology formalisation, it was vital to standardise the terms used to represent concepts within the ontologies. Interviews commenced with engineering experts involved in the creation of the ontologies. The aim was to bring together design and manufacturing engineering experts that will be using the ontology to agree upon the ontology concepts. Interacting with many experts within the aerospace engineering industry has established that different forms of language communication (e.g. acronyms, synonyms and homonyms) has become an accepted phenomenon within design and manufacturing engineering disciplines over many decades. However, there is a need to capture the consequences of using some of these terminologies to describe concepts and identify the effect it has on product design activities. Refining and validating the ontology concepts involved assessing the meaning of each concept. The process and resource ontology developed incorporates manufacturing knowledge and associates with the manufacturing domain. Therefore, experienced design and manufacturing engineers were engaged in order to strengthen the vocabulary used to represent concepts within the ontology with a view to develop a common understanding of meaning.

To illustrate a scenario, one of the concepts within the resource ontology was initially defined as ‘Tool’. It was identified that the term ‘Tool’ in manufacturing engineering is interpreted as a physical manufacturing device (e.g. chipless machining). However, the term ‘Tool’ in engineering design is often thought to be computer software, excel spreadsheet with macros or even a design method. Due to the variety of meanings and context, it was identified that the term ‘Tool’ in the resource ontology was not a suitable name for a concept by itself. Therefore, the term ‘Design Resource’ and ‘Manufacturing Resource’ were used as well as a subclassification into ‘Design Tool’ and ‘Machine Tool’ to represent both design and manufacturing engineering concepts. These terminologies were agreed and shared between both design and manufacturing engineers. In another scenario, it was often challenging distinguishing between a feature and a property on a component due to the many levels of granularity. In order to establish a common understanding of meaning, design and manufacturing engineers established that a property is associated at an assembly level, component level and feature level. Each level has its own distinct set of properties as well as inherited properties from other levels.

Furthermore, the instances of the concept ‘Inspection Process’ within the engineering process ontology were initially classified with that of the concept ‘Manufacturing Process’. This meant that inspection processes were considered as a type of manufacturing process. This is inherently true; however, the semantics of the vocabulary later proved that this is often false. There have been practical scenarios where a design was manufactured but due to geometry properties and constraints, it could not be inspected using any of the inspection methods (e.g. x-ray and co-ordinate measurement machining). Within product design, there is much emphasis on ‘design for manufacture’ but ‘design for inspection’ is often neglected because inspection processes are implicitly considered as part of manufacturing processes. For this purpose, it was necessary to establish manufacturing, inspection and assembly processes as separate and independent concepts in the engineering process ontology. Through the refinement phase, several aspects of the developed ontologies were validated for completeness and consistency in vocabulary and meaning.

6.8 Ontology knowledge-base to support decision-making in product design

The development of modular engineering design ontologies namely, (1) product design; (2) engineering process; (3) design and manufacturing resource and (4) functional model have been presented in the aforementioned sections of this paper. The next section addresses how the relevant knowledge and necessary relationships between the ontology modules are invoked and brought together to support specific design decisions in the aerospace industry. In order to achieve this, a rule-based modelling language is selected to integrate closely with the OWL-based ontologies. The semantic web rule language (SWRL) enabled the definition of declarative rules which can be used to invoke necessary relationships and infer knowledge required between multiple ontology domains. Furthermore, the SWRL rule base has domain specific built-ins which make it highly extensible and maintainable. The scalability and performance of SWRL rules for practical business applications has been verified in industrial case studies (Saa et al. 2012). Figure 16 illustrates how SWRL has been used to invoke the necessary knowledge relationships between multiple ontology domains to support a design decision in the aerospace industry. SWRL is used to model specific ontology relationships between the engineering product, process and functional model concepts, and instances, and then infers the computed output to the engineering resource ontology. For this particular example, the rule below establishes that for any Trent XWB product feature that has a combustor assembly, tile component and tile nut feature, and is manufactured using chipless machining and requires thermal analysis; the specific design resource tool to use as a consequent is SC03 with specific programme codes CD11 and CD12. This will aid the development of a two- or three-dimensional thermo mechanical model. The SWRL rule base expression is defined below:

productDescription(?x, ‘Trent XWB’)

∧ hasAssembly(?y, ‘Combustor’) ∧ hasComponent(?z, ‘Tile’) ∧

hasFeature(?y, ‘TileNut’) ∧ hasManufacturingProcess(?z, ‘ChiplessMachining’)

∧ hasFunctionalModel(?z, ‘Thermal’) →

designTool(?x, ‘SC03’) ∧ hasProgramCode(?z, ‘CD11, CD12’)

∧ designModel(?x, ‘Thermo Mechanical Model’)

Figure 16. Integration of ontology knowledge to support design decisions using SWRL.

In conjunction with SWRL, the java expert system shell (JESS) is also used to support the modelling of integration rules between modular ontologies. JESS is defined as a business rules engine and is capable of production runtime execution. As a result of using the JESS inference engine, SWRL rules become more adaptable and the whole system becomes dynamic with rules that adapt to change in data. JESS supports both forward and backward chaining inference-based approaches. Forward chaining starts with available data and then uses inference rules to extract more data which is often referred to as data-driven approach, while backward chaining works from the conclusion to reach a set of facts often referred to as the goal-driven approach. Several integration rules like the one explained above were developed to support design engineers in their decision-making process within an aerospace gas turbine environment.

7. Validation and benefits

Throughout this study conducted with an aerospace organisation, every utilised technique and approach presented in the framework was validated systematically with subject matter experts within the aerospace industry. A workshop was arranged to present the engineering design ontologies to 11 participants from the aerospace and software engineering sectors. Participants included knowledge management specialist, knowledge management team lead, semantic technologist, component family standards experts, engineering process specialists and senior design specialists. The strengths, benefits and limitations of the developed ontologies were identified. Excerpts of the questions addressed in this workshop are as follows:

•

What is the ‘industrial applicability’ of the knowledge captured within the ontology? Example of scale used to capture this: eight in this case means the framework is applicable with minor issues (80%) to engineering design ontology development activities from an expert perspective. This scale has been used to assess the remaining performance metrics. Additional comments on each performance metric were also provided by each expert.

Table

1	2	3	4	5	6	7	8	9	10
Not applicable	Applicable with major issues				Applicable with minor issues			Fully applicable

The taxonomy of the product ontology structure is currently used to support the navigation of information on a web-based information-sharing platform within the combustor engineering design domain of the sponsoring organisation. In addition, the engineering resource ontology describing product design resource (i.e. role types, toolsets, programme codes and tool capabilities) is currently used to support RBC which focuses on deploying and aligning the appropriate tools with the correct level of functionalities against the correct engineering roles at the sponsoring organisation. The engineering design resource ontology is also used to support an IT modernisation project which looks at planning the order in which product design systems are migrated and refreshed. Additionally, many of the lower level instances created for the engineering product, process, resource and functional model ontologies are currently used to support terminology recognition (TR) software. The ontologies created contain many common terminologies used in the aerospace industry and has potential to support a semantic search engine which transcends conventional keyword-based search. The knowledge base of the combustor breakdown ontology is also currently used to support KBE systems, especially KBE systems that adopt a model-driven architecture approach, due to the high level of abstraction employed in designing and developing the ontology knowledge base.

•	Is the ontology structure ‘comprehensive’ enough to be used for engineering design?
•	Please comment on the ‘generalisability’ of the ontology structure? Is it reusable across other business functions within the aerospace industry?
•	What are the framework strongest and weakest features?

Table 5 illustrates statistics of responses from 11 experts present at the ontology validation workshop. Key performance criteria for the framework from experts’ opinion were assessed, namely, (1) industrial applicability; (2) comprehensiveness; (3) generalisability; (4) scalability and (5) modularity.

Table 5. Validation of ontology framework using key performance assessment criteria identified by experts.

		Validation performance assessment criteria for ontology framework
No	Experts	Industrial applicability (%)	Comprehensive (%)	Generic (%)	Scalable (%)	Modular (%)
1	Chief of combustion and casings defence	90	50	80	60	75
2	Senior design specialist	90	80	70	70	75
3	Engineering manager (thermals)	60	60	80	70	80
4	Combustion and casings web designer	90	67	85	80	90
5	Integrated project team lead	85	80	89	60	75
6	Principal design engineer	80	80	70	60	80
7	Knowledge management specialist	90	70	90	70	80
8	Staff design modeller	80	40	70	70	75
9	Process excellence lead	70	60	60	60	75
10	Chief of quality and improvements	75	60	70	65	70
11	Associate fellow-knowledge management	90	70	75	70	80
Average		82	65	76	67	78

The overall average response of the 11 experts who reviewed the framework suggest that the performance assessment statistics for the framework are as follows: (1) 82% for industrial applicability (highly applicable to practical engineering design activities); (2) 65% for comprehensive ontology development as a result of employing the framework; (3) 76% for generalisability of ontologies (generic with minor issues); (4) 67% for scalability of developed ontologies and (5) 78% for ontology modularity meaning the framework encourages modularity in ontology design.

It was identified during the validation workshop that different ontologies often represent different communities of interest. Therefore, a centralist approach runs the risk of ignoring this and imposing monolithic solutions. However, the modular architectural design encouraged in the ontology framework ensures this does not happen as identified by experts 1, 3, 4, 6, 7 and 11. Experts suggest the framework offers high industrial applicability and generalisability of concepts captured within the ontology structure to other engineering design industries (e.g. automotive). Though the specific instances are tailored towards the aerospace gas turbine engineering sector, the high-level concepts are common across other types of product design industries as identified by experts 6–11. Though the ontologies seem comprehensive, the scalability and maintenance of the ontology needs to be assessed. This was of particular concern to experts 1, 5, 6 and 9. It was suggested that the ontologies developed should be tested in other engineering design supply chains to fully ascertain its scalability.

Within the aerospace sector, it was identified that the word ‘Ontology’ can be seen as quite imposing and abstract. Organisations may compound this difficulty by creating a mysterious inner circle on whose job it is to minister over the ontology. Senior design specialists (experts 1, 2, 6 and 8) suggested that mereology is more critical to component definition than an ontology. A taxonomy classification of the combustor product component has been captured as a lightweight ontology and it was identified that this could further enable the design and development of KBE systems as identified by experts 8 and 11. An interesting aspect of the ontology framework development is in the creation of concept to instances relationships. This next level of an ontology knowledge-base is often not addressed in ontology development. This is required to enable effective representation and management of knowledge complexity. As a result of this, the engineering design ontologies developed were used to empower the search capabilities of a patented semantic search engine known as TR as suggested by experts 7 and 11.

Furthermore, it was recognised that the background of individuals may distort the ontology structure. The ‘hacker’ mentality often does not see the value of analysis before action, which is often embodied in ontology-based approaches. However, there is a need to encourage communities of practices where members of the aerospace industry share ontology design and development best practices. Semantic technologists suggest that ownership must be pervasive. To encourage ownership and adoption, the tools and techniques of ontology-based engineering should be deployed horizontally across the enterprise and the framework should encourage this notion. It was identified that it would be of even greater benefit to the business in the long term if the engineering design ontologies were aligned across all of the computing systems proposed and developed, as this would provide greater leverage of information captured as identified by experts 1, 8 and 9. Furthermore, two case studies were conducted to implement the ontology structure on a product design information sharing platform. The purpose was to aid the navigation and structure of product design information on a web-based platform. Consequently, the applicability and generalisability of the ontology structure were ascertained and it was agreed for the ontology structure to be an aspect of a knowledge management strategy to be deployed across other aerospace engineering design business functions within the organisation to support engineers in their decision-making process.

8. Discussion

The implementation of engineering design ontologies has generated increased interests in the aerospace industry. Various project initiatives in the aerospace organisation are currently employing the developed ontologies as a channel to support decisions in product design activities. One of the engineering design ontologies that have generated interest in the aerospace sponsoring organisation is the resource ontology. Project initiatives like RBC and IT modernisation activity which focuses on correctly aligning software specifications to hardware platforms and skill types are employing the resource ontology to help plan the order, in which IT systems are migrated and refreshed. This enables the planning and deployment of hardware and software engineering design technologies across the aerospace organisation. Understanding the versions of design tools and aligning them with functional capability is crucial in identifying gaps in IT, especially within large blue-chip businesses. Thus, the resource ontology has enabled representation of resource complexity and is offering benefits in this aspect.

In highly specialised product design industries, where design data is paramount, effective and efficient, data access is required. To achieve this, there is need for a communication medium between design engineers and product design information on web-based platforms. The engineering design ontologies along with the framework described in this paper can be viewed as enabling this notion. Case studies were used to apply the developed ontologies to support the structure and accessibility of information. This notion was widely accepted by design engineers as a logical structure was provided using ontologies as the basis for searching for crucial engineering design information. As a product designer or product modeller, the component and feature-based ontology route was appropriate. Therefore, the product design ontology describing the breakdown structure of products was employed for this purpose. However, the lower level concepts and instances developed are more relevant for the combustor and casing engineering design product. It was essential for other engineering business functions to identify lower level concepts and instances describing their product component (e.g. compressor and turbine). Though the ontology development framework and high-level product design concepts were provided, ownership was encouraged in these engineering functions to accurately represent product assemblies, components and features of other gas turbine products.

Extending the ontology knowledge-base with other product design structures enhances collaboration capabilities, providing access to interdisciplinary and multidisciplinary knowledge. However, possible limitations may include consideration of ontology security measures across product design domain to ensure one domain is not allowed to alter the master ontology source of another domain. There might also be additional interface complexity which might increase the total cost of ownership.

From observations in engineering organisations, managing the integration of various knowledge types and knowledge sources is crucial for achieving effective knowledge management. Ontologies of a modular nature provide the means to manage such complexity. Frameworks like the one proposed in this paper should be encouraged in the engineering design community to ensure architectural design of modular ontology development. Such development will strengthen the reuse and maintainability of smaller self-contained ontologies. Furthermore, the ontologies proposed in this research study will be of interest to ontological practitioners in other industries.

9. Conclusions

This research study has presented a framework for encouraging modular architecture design for aerospace engineering design ontologies. Additionally, extensive engineering product, process, resource and functional model ontologies have been developed as a result which would be of interest to ontological practitioners within the engineering design community. In recent years, the engineering community has generated increased interest in the area of ontology-based management. However, there are lack of ontology development frameworks that bridges the gap between ontology design and engineering design activities. Particularly, ontologies created in engineering design are often designed without considering modularity in the ontology design process. Modular ontologies are crucial for modelling complex domain and should be fully addressed at the initial stage of ontology development. Considering and assessing the quality attributes of ontology design is an area that requires further investigation. This research has concluded that ontologies of a modular nature have potential for significant reuse. The ontologies developed in this study have been applied to support several project initiatives within the aerospace industry. Its main application is in the structure and access of relevant product design information on a web-based platform. Further applications involved employing the ontologies to support RBC and plan the order of IT deployment for hardware and software kits used by multidisciplinary roles within the aerospace industry.

The main benefit of using the framework to develop modular ontologies is in the reduction of lead time for maintaining ontologies. Reusability is enhanced with ontologies of a modular nature. Additionally, due to the validity and generalisability of the engineering design ontologies, other engineering projects could potentially benefit from the domain ontology structure. Additional research is required to further evaluate and explore other non-functional requirements and quality attributes of ontology design and development within aerospace engineering design activities. Integrating quality attributes with ontology design could enhance the potential facilitation of future interactions between IT systems and engineering design processes.

Acknowledgements

The authors would like to thank the Engineering and Physical Research Council (EPSRC) and case study organisation for funding this research project. We would also like to express our appreciation to the employees of the case study organisation for their cooperation and Sysemia Ltd for their time in validating aspects of this research study.