Abstract
Product lifecycle management provides a framework for information sharing that promotes various types of decision-making procedures. For product lifecycle management to advance towards knowledge-driven decision support, then this demands more than simply exchanging information. There is, therefore, a need to formally capture best practice through-life engineering knowledge that can be fed back across the product lifecycle. This article investigates the interoperable manufacturing knowledge systems concept. Interoperable manufacturing knowledge systems use an expressive ontological approach that drives the improved configuration of product lifecycle management systems for manufacturing knowledge sharing. An ontology of relevant core product lifecycle concepts is identified from which viewpoint-specific domains, such as design and manufacture, can be formalised. Essential ontology-based mechanisms are accommodated to support the verification and sharing of manufacturing knowledge across domains. The work has been experimentally assessed using an aerospace compressor disc design and manufacture example. While it has been demonstrated that the approach supports the representation of disparate design and manufacture perspectives as well as manufacturing knowledge feedback in a timely manner, areas for improvement have also been identified for future work.
Keywords
Introduction
As engineering enterprises seek to expand their product portfolios into the global arena, a multitude of information is generated at various stages of the product lifecycle. The resourceful use of this information helps organisations stay competitive within the changing marketplace by supporting knowledge-driven decision making. The latter is reliant on the effectiveness with which knowledge sharing across business functions is managed. For example, appropriately captured knowledge originating from the design, production and service of previous product versions can be reused and tailored to meet the future planning requirements in new product development.
Manufacturing companies are nowadays deploying a range of software solutions to improve the visibility of information and support interactions within and across groups. The implementation of product lifecycle management (PLM) software represents one such initiative. However, because PLM toolkits lack the adequate support for reasoning about information structures and how to efficiently reuse these structures to enable decision making, this implies that PLM accounts for a relatively narrow success in offering some breadth of information support. 1 Hence, knowledge that should in fact be cross-functional remains latent and in tacit form within its individual design and production groups.
Consequently, the interoperability of valuable knowledge across design and manufacturing stages cannot be readily achieved using PLM toolkits alone. In the context of this work, the term interoperability refers to the ability to promptly and accurately share computer-interpretable knowledge across multiple application systems. This lack of interoperability across design and manufacture implies that cross-functional communication very often remains largely reactive and the achievement of timely exchanges continues to be a difficult task.
Ontologies are machine-interpretable models of shared domains of interest and constitute a subset of the underlying technologies for information and knowledge support. 2 They also provide a basis for sharing meaning in computational form. 3 For these primary reasons, ontologies possess attractive properties as far as knowledge capture and sharing are concerned in PLM. Various contributions have demonstrated that the semantic value of the captured knowledge is dependent on the expressiveness of the ontology language used.4,5,6 In production engineering, heavyweight (i.e. expressive) ontologies are favoured3,6,7 as they are accompanied with logic-based reasoning mechanisms that carefully prescribe the semantics, behaviour and conditions present within information structures. Expressive ontologies thus impart the ability to configure knowledge models for improved decision making. 7
This article investigates the interoperable manufacturing knowledge systems (IMKS) approach. The latter exploits the capabilities of expressive ontologies to configure PLM systems, in order to offer ground breaking potential in manufacturing knowledge support and sharing. Moreover, the investigation has been scoped around an aerospace compressor disc design and manufacturing perspectives. A part family and feature-based understanding has been utilised to enable the feedback, into design realisation, of key manufacturability rules that have a direct implication on the design of the product. This is analogous to the coordination and sharing of critical information as key characteristics that carry crucial product semantics throughout the product lifecycle. 8
The article is structured as follows: ‘Towards knowledge-driven decision making in PLM’ provides an overview of the IMKS approach and analyses related work. ‘Formal ontologies to capture design and manufacturing knowledge’ then explores the various facets of exploiting expressive ontologies to capture, specialise and verify knowledge. This leads to a demonstration of the IMKS approach, followed by relevant discussions and conclusions.
Towards knowledge-driven decision making in PLM
This section presents an overview of the traditional approaches that have been utilised to support information sharing in PLM. The IMKS approach and its contributions are then highlighted, followed by a review of more recent and related methods that include the combination of PLM and knowledge-based techniques.
Traditional approaches to information sharing in PLM
The process of information sharing has traditionally been based on the exploitation of a common schema, or product master model 9 that enforces a rigid structure to meet the integrated information modelling needs in design and manufacture. This method of ensuring information sharing can be problematic in a number of ways since, e.g. multiple information viewpoints are required by design and manufacturing engineers.10,11 Furthermore, engineers generally tend to have their own preferred terms that are confined to their specific problem domains and as such, alternative representations and definitions of concepts are inevitable. 6
Traditional approaches to information sharing in PLM have been largely driven by software systems that focus on integration, as they support a common platform for the management of product-related information with mechanisms to capture the essential workflows required to achieve collaborative design and manufacture.12,13 An example of this has been realised in the development of a STEP (standard for the exchange of product model data) and extended markup language (XML)-enabled PLM platform capable of integrating several customised design tools, such as computer-aided design (CAD) and computer-aided engineering (CAE) instruments that have been developed in-house. 14 The platform supports the management of flows of information that are critical to the design process of turbomachinery.
In line with this, the evolution of PLM systems has also witnessed a shift from the utilisation of data models to information models as methods of designing and implementing these systems. This has been realised in line with the need to move from simply geometry-based product information towards more meaningful feature interactions required for describing the multiple viewpoints of the features of a product in relationship to the type of part being modelled.10,11,15
Furthermore, it is understood that the utilisation of information models for developing PLM systems, although suitable from an integration perspective, falls short of the ability to foster interoperability.16,17 Hence, there is a number of extensions required by PLM systems and the following research questions, pertinent to the context of this article, intend to address the related extensions.
What constitutes a suitable approach to progress towards meeting the interoperability requirements of self-describing PLM applications?
To what extent is it possible to capture and reuse formalised knowledge, as opposed to simply data and information, in the product lifecycle to help make useful and timely decisions for benefiting product development?
To what extent can a progression towards rigorous semantic-based approaches support the requirements for meeting product, process and resource lifecycle management? 18
Overview of the IMKS approach
The IMKS approach 19 has been proposed as an effort towards tackling the research questions identified in ‘Traditional approaches to information sharing in PLM’. The approach explores radically new methods by extending PLM into a richer knowledge-sharing base to support the capture, sharing and verification of multiple sources of manufacturing knowledge in a dynamic environment. Figure 1 identifies a high-level view of the IMKS approach, which is further developed in ‘Formal ontologies to capture design and manufacturing knowledge’ of this article.

The IMKS approach.
Based on Figure 1, there are three main contributions that this work targets, notably:
the exploitation of a core ontology and specialisation mechanisms to address the interoperability requirements of various viewpoints across PLM;
the ability to capture formalised semantics and knowledge using mathematically-rigorous and explicitly encoded, i.e. heavyweight, ontologies;
the verification and feedback of knowledge from manufacturing stages to product design stages using ontology-based mechanisms.
Lightweight versus heavyweight approaches
The representation of knowledge in computational form is largely dependent on the level of rigour with which the semantics (i.e. meaning) that describe the knowledge can be modelled.
There are two types of ontology approaches that can be followed in order to model semantics. They are notably referred to as ‘lightweight’ and ‘heavyweight’ methods. Lightweight ontologies, e.g. data and information models, consist of simple representations that involve taxonomies of concepts and relations and assume that the meaning associated with concept terms is fully understood, agreed and, therefore, readily interpretable. 4 On the other hand, heavyweight ontologies, i.e. knowledge-based models, consist of both lightweight structures as well as formal axioms that support the definition of the semantics of terms used for computer-based knowledge representation.4,6 Therefore, heavyweight (i.e. expressive) ontologies are preferred for ensuring greater confidence behind the meaning of formalised knowledge.
Ontologies of core concepts
Prior work6,7,20 has demonstrated that an ontology of well-defined core concepts can serve as a foundation for the sufficiently flexible development of domain-specific concepts, such as those pertinent to feature-based design and manufacturing planning viewpoints. Thus, the IMKS approach allows the derivation of specialised knowledge bases as repositories for designers and planners alike, without the need to commit to a fixed master model. In that sense, the heavyweight ontology dimension of this work builds on top of the current perceived advantages of applying formal ontologies within a PLM context to aid the process of semantic interoperability and knowledge exchanges.3,6,7,21,22
There is a vital benefit to the development of specialised concept definitions from a core set of concepts, in order to suit different stages of the product lifecycle without enforcing a single structure. A common semantic foundation provides a means of verifying across knowledge bases since meaningful mappings and concept lineages can be identified across the design and production perspectives. 23 This basis constitutes another crucial facet of the IMKS approach in being able to support manufacturing knowledge-sharing mechanisms into design realisation.
Combined PLM and knowledge-based approaches
The exploration of ontology-driven PLM systems is a relatively recent research area 22 but is quickly gaining consideration both at research and industry level. Earlier work5,24,25 has shown that the shift towards ontology-based approaches can start to support the capture of semantics of product data and various types of product features. A wider appreciation of PLM, coupled with knowledge-based approaches, appears in more recent efforts. Raza et al. 26 have applied ontologies within the PLM system at Ford in order to enable the reconfiguration of the assembly line to meet changing requirements, where product and resource data in Teamcenter 27 have been translated into the web ontology language (OWL). 28 It is to be noted that most current related work in ontology-driven PLM systems29–31 employ OWL as ontology language.
This, therefore, raises an important concern from the point of view of semantic knowledge capture and sharing. It has been shown that OWL is limited in representing complex manufacturing constraints and process semantics.3,6 Furthermore, although some efforts have utilised OWL with rule languages,25,32 these rule languages do not benefit from full first-order logic constructs. They, therefore, fall short of the required expressive power and reasoning mechanisms to accurately encode and infer over PLM subject matter.
From the perspective of developing core ontologies that then specialise into different viewpoints across the product lifecycle, important understandings have been proposed. The contribution by Kesavadas et al. 33 acknowledges the use of formal ontologies to progressively capture design and manufacturing concepts. Other authors22,34,35 have identified the potentials of using upper level and core ontologies from which to relate PLM structures. Unfortunately, these approaches either still lack the level of semantic rigour or need to be further explored in order to be industrially viable.
Zhan et al. 31 have investigated ontologies to share knowledge regarding product data in CAD. Ontology mapping mechanisms have also been specified as a means of knowledge verification across systems. On the other hand, Lee and Suh 36 have explored a multi-layered approach to PLM using ontologies. Each layer encompasses a specific product viewpoint in PLM and each exploits axioms, knowledge maps and specialised domain knowledge. The latter approach, which uses the Prolog language, reflects one of the infrequent cases in which first-order logic models have been created for PLM.
An important observation regarding similar work is that while the intention to progress towards interoperable decision-making systems is present, little attempt has been made at exploiting truly rigorous semantic definitions. Furthermore, a significant proportion of efforts have concentrated on the representation of product design information and the capture of design intent, thereby leaving a gap in knowledge verification from manufacturing-intensive functions into design stages.
Formal ontologies to capture design and manufacturing knowledge
Building blocks of the IMKS approach
Figure 2 identifies the vital building blocks of the IMKS approach, both from a functional and an implementation perspective. The ontology development methodology provides a route from domain modelling to knowledge sharing by first including the definition of lightweight ontology models of the necessary core concepts, design and manufacturing domains (Figure 2A). The mechanisms for specialising the design and manufacturing domains also need to be elicited (Figure 2B). The lightweight ontology entities, together with the necessary semantic constraints (Figure 2C), are transformed and captured in heavyweight format, resulting in explicitly encoded ontologies (Figure 2D).

Building blocks of the IMKS approach.
Another important building block is associated with the understanding and formal specification of the mappings that hold across the specialised design and manufacture concepts (Figure 2E). With this in place, it then becomes possible to define knowledge verification constraints (Figure 2F) that interact with the design and manufacture concepts to provide a basis for the interpretation and sharing of product lifecycle knowledge (Figure 2G).
From an implementation perspective, IMKS utilise ontologies, mappings and knowledge verification constraints that are encoded in the knowledge frame language (KFL). 37 The latter is a heavyweight ontology language based on the common logic standard 38 and possesses superior expressiveness and provision for deductive reasoning mechanisms when compared with OWL-based technologies. 6 The defined ontologies, present at the knowledge architecture level, are deployed using the Highfleet integrated ontology development environment (IODE) 39 (Figure 2H).
A PLM platform, that uses Siemens Teamcenter 27 and NX CAD 40 applications, is configured from the ontologies implemented in the IODE (Figure 2I). In addition to this, new graphical user interfaces (GUIs) have to be designed for use in the NX environment so as to communicate shared knowledge at a user level. The interpretation and sharing of knowledge is assisted by the GUIs and a Java application programming interface (API) to enable interactions between the PLM and knowledge-based platforms (Figure 2J).
Lightweight model of the manufacturing core ontology
Figure 3 introduces the manufacturing core ontology (i.e. ontology of core concepts), which is first captured as a unified modelling language (UML) class model. The diagram identifies general categories of information, the core types of concepts (i.e. classes) that fall within these categories and important associations (i.e. relations) across concepts. The fundamentals of this ontology involve the notion of part planning using part families and features,15,41 where sufficient flexibility in the formal meaning of concepts has been accommodated to support the improved configuration of design and manufacturing solution.

UML class model of the manufacturing core ontology.
The manufacturing core ontology model aims at providing an improved way for configuring design and manufacturing computer-based systems with a focus on interoperability. This is because various core concepts, central to the description of both design and manufacturing stages of the product lifecycle, have been captured and linked. Furthermore, the relationships specified in the model constitute the primary associations across the categories of information and provide fundamental semantic structures for capturing meaning. An example in which the manufacturing core ontology could be exploited is in the configuration of a CAD environment that is built upon the rationale of part families and features in design and manufacture.
Following this example, a design solution that has been generated using the ontology-configured CAD environment would be an instance of some specific type (i.e. subclass) of DesignPartFamily. At a model representation level used in the configured CAD environment, any type of DesignPartFamily holds DesignFeature types. Specific constraints and rules, established over types of part families and types of features, dictate how a design solution is instantiated. In other words, when some type of DesignPartFamily is instantiated into a design solution, the latter would hold all the conditions and knowledge previously captured at the type (i.e. class) level. The knowledge specialisation mechanisms, explored in this work, are further discussed in ‘Declaration of contexts, classes and relations’.
Likewise, the interactions between knowledge coming from the specialisation of ManufacturingMethod, ManufacturingResource and ManufacturingFacility enable the useful configuration of manufacturing solutions, i.e. instances of some types of ManufacturingPartFamily. On the other hand, the manufacturing core ontology supports the capture of more dynamic knowledge, pertinent to shop-floor processes within the RealisedPart domain. Altogether, the ontology presented here comprehensively models a backbone of core concepts that reflects important stages of the product lifecycle. This has been made possible thanks to a number of strands of work, including our long standing contributions towards the best practice organisation and sharing of manufacturing knowledge and substantial efforts coming from international standards.38,42–44
Heavyweight model of the manufacturing core ontology
Declaration of contexts, classes and relations
The UML class model of the manufacturing core ontology provides a roadmap of the necessary ontological entities that need to be formalised in KFL, in order to obtain a semantically rich ontology. KFL, as a knowledge representation language, possesses a rigorously defined meta-model that is instantiated into user-specific ontologies such as the manufacturing core ontology presented in this section. A user-specific ontology typically occupies a context (i.e. an identifier) that references all the classes, relations and integrity constraints that make up the ontology.
The basic structures of the manufacturing core ontology consist of the declaration of a context, classes and relations. The core ontology occupies a context that is declared in KFL as thus
:Ctx MLO
:Inst UserContext
:supCtx TopUserContext
:name “Middle Level Ontology”
The directive :Ctx captures the identifier for the context, in this case MLO, which is made an instance of UserContext and a sub-context of TopUserContext. A name can be assigned to MLO through the :name directive. Note that the manufacturing core ontology is being developed as a middle level ontology. This is because the ontology builds its entities on top of the system-defined context of the KFL meta-model. By using similar KFL directives, it is possible to capture taxonomies of classes and specify relations that hold across the individuals of these classes as prescribed in the UML class model of the ontology. These structures are essentially instantiated from the KFL meta-model.6,7,20
Semantic constraints
The declaration of semantic constraints is one of the fundamental strengths of heavyweight ontologies.6,7,20 Since the manufacturing core ontology comprises a set of well-defined core concepts, this implies that semantic constraints are required to catch the formal meaning of core concepts so that the integrity-driven specialisation of viewpoint-specific knowledge models can be ensured.
Semantic constraints can be captured by exploiting integrity constraints, which are logic-based axioms that help confine the formal interpretation of concepts in KFL ontologies. An example of an integrity constraint developed for the manufacturing core ontology is depicted as follows.
(=> (or (DesignFeature ?df)
(supTC ?df DesignFeature))
(or (not (exists (?fmm)
(and (FeatureManufacturing Method ?fmm)
(hasManufacturingMethod ?df ?fmm))))
(not (exists (?fmm)
(and (supTC ?fmm Feature Manufacturing Method)
(hasManufacturing MethodType ?df ?fmm))))))
:IC hard “A DesignFeature type/individual cannot have an associated FeatureManufacturingMethod type/individual, since the latter is only applicable to ManufacturingFeature types/individuals.”
The integrity constraint expression is intended to make core concepts fool proof when they are specialised. The axiom is stating that given a DesignFeature individual or subtype of DesignFeature, then it is not possible for these entities to be related to some individual or subtype of FeatureManufacturingMethod. This is because the latter is reserved exclusively for reasoning about individuals and subtypes of ManufacturingFeature. 20 Notice how the expression is appended with an :IC hard directive followed by the natural language interpretation of the integrity constraint. A hard integrity constraint, i.e. :IC hard, ensures that rigorous semantics are stored through compulsory conditions. This level of granularity of constraint on knowledge is currently not achievable in OWL-based approaches, hence the benefit of using a KFL approach over mainstream ontology languages to capture more expressive semantics.
Specialisation of knowledge models, mappings and verification
Specialisation mechanisms
In this section, a very simple part family and feature understanding is applied to illustrate specialisation mechanisms and those utilised for verifying cross-functional knowledge. Figure 4 identifies a product exemplar, highlighting the variations in the design and manufacturing interpretation of concepts pertinent to the definition of a part family. The latter denoted as the notion (A), and termed LboroDesignPF in the design perspective and LboroManufacturingPF in the manufacturing perspective, is one that comprises two feature concepts, namely (B) and (C). The feature concepts relate to concepts (D), (E) and (F), which serve as geometrical attributes of interest. These feature attributes are critical parameters relevant to both designers and manufacturing engineers alike and are, therefore, assumed to be consistently defined across the design and manufacturing perspectives.

Example of simple part family and feature configurations.
Figure 5 identifies the approach for progressively specialising core concepts to support the creation of a knowledge model to represent the design perspective of the part family previously identified in Figure 4. The upper level ontology, i.e. ULO, context enfolds the KFL meta-model from which the manufacturing core ontology is instantiated.

Developing specialised knowledge models.
The specialised design ontology, which in Figure 5 occupies the dsn context, i.e. design context, is in essence both an instantiation of the ULO and a sub-model of the manufacturing core ontology. This is obvious from the class/sub-class relations that hold between classes defined within the MLO and dsn contexts, e.g. the Cylinder and RoundHole classes are subtypes of the core concept DesignFeature. These specialisation mechanisms imply that the semantics from the MLO context are inherited by the concepts within the dsn context.
On the other hand, relations defined in the manufacturing core ontology, such as hasFeatureType and hasFeatureAttributeType are simply reused for satisfying the design ontology. It is also important to notice that at the level of the specialised design ontology, assertions over classes are made in order to build an expressive model, e.g., the LboroDesignPF as a class holds two types of design feature classes in its definition namely Cylinder and RoundHole.
Hence, when the specialised design ontology is instantiated at the bottom level, the semantics from the third level, coupled with those from the MLO context, drive the integrity of the instantiated model. In the approach, the last level is reserved for software applications whose system structures are to be ontology-driven. For example, a user interacting with a CAD system would design a new part, that conforms to the part family configuration in Figure 4, by creating the individual LboroPart1706 (an instance of the class LboroDesignPF) that has the feature individuals Cylinder1 and RoundHole1, each with distinct feature attributes and values.
Mappings across design and manufacturing concepts
In order to enable knowledge verification, it is important to build mappings across design and manufacturing entities. The formalisation of these mappings needs an understanding of how PartFamily and Feature types overlap between the design and manufacturing perspectives. The KFL lines next illustrate how, by exploiting the mapsTo symmetric and transitive binary relation defined in the MLO context, cross-domain mappings can be stated for the PartFamily and Feature types in Figure 4. mfg is the context for entities in the manufacturing domain. The mappings shown are one-to-one in nature. However, more complex product representations can exist where many-to-one, one-to-many and many-to-many relationships are encountered.
(MLO.mapsTo dsn.LboroDesignPF mfg.Lboro ManufacturingPF)
(MLO.mapsTo dsn.Cylinder mfg.TurnedProfile)
(MLO.mapsTo dsn.RoundHole mfg.Bore)
Knowledge verification constraints
The ability to drive the feedback of manufacturing knowledge into design stages is dependent on the formalisation of cross-functional knowledge verification constraints as well as existing cross-domain mappings. The following KFL entry exemplifies a knowledge verification constraint using relevant entities from Figures 4 and 5, where knowledge associated with a design feature, critical from a manufacturing perspective, has been formalised. The knowledge verification constraint works in such a way that given an antecedent (i.e. ‘if’ statement), a consequent (i.e. ‘then’ statement) is checked against the knowledge base.
(=> (and (RoundHole ?hole)
(Diameter ?dia1)
(hasFeatureAttribute ?hole ?dia1)
(hasDimension ?dia1 (mm ?num1)))
(exists (?tool ?dia2)
(and (StandardDrillingTool ?tool)
(available ?tool)
(Diameter ?dia2)
(hasFeatureAttribute ?tool ?dia2)
(hasDimension ?dia2 (mm ?num2))
(lteNum ?num2 ?num1))))
:IC soft “*** RoundHole *** The nominal value of round hole diameter may not be less than the available minimum standard drill size. Since the selected hole diameter value is below the available minimum standard drill size, standard tooling and standard machining methods cannot be used.”
:hasCtx workshop1
The :IC soft message catches the natural language interpretation of the constraint. The message is intended to warn the designer of a potential concern, from a manufacturing point of view, related to the chosen diameter of a RoundHole (bottom level in Figure 5) if during design, the diameter of that feature happens to be less than the available minimum standard drill size.
Furthermore, a knowledge verification constraint needs to be made applicable to a specific context by using the directive :hasCtx. In this case, the term workshop1 is referring to one such context for knowledge verification. In general, enterprises that have multiple factories, each with its own machining and tooling capabilities, can have several knowledge verification contexts. For example, another context workshop2 could be present, in which entities from the dsn context would be referenced in a similar way but with different information on standard drilling sizes.
Demonstration of the IMKS approach
Compressor disc example
Figure 6 illustrates a test case based on an aerospace compressor disc, in which its design and manufacturing perspectives have been modelled and made to interoperate, using the IMKS approach. The rationale behind the selection of an aerospace compressor disc as a test case is that, while working with collaborators on the IMKS project, it became obvious that there were alternative representations of the disc during its design and manufacture stages. Furthermore, it was understood that it was almost impossible to fully standardise the CAD/CAM (computer-aided manufacturing) model of the disc as a route towards reconciling its design and manufacture representations. Therefore, the achievement of seamless knowledge exchanges to drive better CAD/CAM capability of the disc was still an area for improvement, which the IMKS approach could target.

Provision for manufacturing knowledge feedbacks.
A breakdown of the design and manufacturing feature concepts present on the disc (here viewed as a half cross-section about the axis) is portrayed. The parameterised model of the latter and its accompanying features are used as a basis for modifying existing designs and generating new product variants.
To accomplish this requires supporting the representation of relevant knowledge from the manufacturing perspective of the disc part family. The ability for so doing is reliant upon a number of factors. First, it is necessary to understand how manufacturing features are accumulated during the production sequence of the part family. In Figure 6, the sorts of machining operations for the compressor disc consist of the following.
Operation 30 (OP30): turn Head Form.
Operation 50 (OP50): turn Web Profile.
Operation 70 (OP70): rough and finish turn Circumferential Groove and Outer Profile. Turn End Face.
Operation 90 (OP90): finish turn Bolt Face and Limit Diameter both sides of disc.
Operation 110 (OP110): produce Bolt Holes. Mill Blade Loading Slot, Defender Slots and Blade Locking Slots in Circumferential Groove.
Operation 180 (OP180): turn Balancing Land.
Second, it is required to identify key manufacturing constraints that occur along the production sequence of the part family and establish what manufacturing feature(s) and feature attribute(s) participate in these constraints. For example, in Figure 6, a set of critical constraints occur during OP50 and OP70 and involving the Web Profile and Circumferential Groove features, respectively.
The third important factor demands understanding of direct mappings holding across the design and manufacturing features, so that the knowledge from the manufacturing constraints can be exploited in design stages. Figure 6 illustrates knowledge feeding back from the Circumferential Groove manufacturing feature towards its counterpart in the design perspective. The figure also depicts how manufacturing knowledge related to the Web Profile has an implication on five design features to which it maps, i.e. a one-to-many mapping exists in this case.
Specialised compressor disc ontology
The design and manufacturing perspectives of the compressor disc have been formalised and all concepts, pertinent to the understanding in Figure 6, have been specialised from the semantics of the manufacturing core concepts ontology. Figure 7 captures important structures within the implemented specialised compressor disc ontology. The IODE platform 39 has been used to deploy the ontologies.

Implementation of the specialised compressor disc ontology.
The diagram identifies a number of class specialisations such as (A) HPCDiscPF, i.e. high pressure compressor disc part family that is a subtype of the core concept DesignPartFamily and (B) CircumferentialGroove as a subtype of DesignFeature. Assertions over classes are also present, e.g. (C) a set of feature attribute types that relate to CircumferentialGroove and (D) the knowledge that HPCDiscPF holds CircumferentialGroove as feature type. Note also that CircumferentialGroove as a type of DesignFeature inherits core semantics dictating that it should have some associated Function (E). A mapping assertion is also present, which indicates that the CircumferentialGroove definitions in the design and manufacturing perspectives are matching concepts.
In a similar way, the manufacturing representation of the compressor disc can be captured. In Figure 7, two class specialisations (G) of the core concept ManufacturingPartFamily are present. ManufacturingFeature has been specialised into a number of feature types, relevant to the definition of the compressor disc manufacturing perspective, such as the highlighted WebProfile class (H). The latter is a required feature type for part family definitions (I). Furthermore, core semantics prescribe that subtypes of ManufacturingFeature require some type of manufacturing method and in this example WebProfile has a WebProfileFMM, i.e. a distinct feature manufacturing method for its production. Cross-domain feature mapping assertions (K) are also present together with knowledge verification constraints, (L) and (M) pertaining to CircumferentialGroove and WebProfile, respectively, to support the communication of manufacturing knowledge for improved decision making in design.
IMKS demonstration concept
The implementation of the specialised compressor disc ontology constitutes a key asset in being able to tailor an ontology-driven PLM environment. Figure 8 depicts the IMKS demonstration concept that exploits the combined use of a PLM software application with the investigated ontology-based approach, notably the following.

IMKS demonstration concept.
Siemens Teamcenter: 27 This environment is used by a designer to initiate the retrieval of an HPCDiscPF individual. Teamcenter provides a platform for the organisation of part families and features.
Siemens NX: 39 This is the primary application with which the designer interacts in order to receive feedback on the manufacturability of a number of features. Once a part family individual has been retrieved from Teamcenter, the designer opens it in NX before making design changes. When a new design has been completed, the designer validates it according to existing manufacturing part family rules and constraints. These are held within the IODE.
All ontology structures, including the manufacturing core ontology and its specialisations into the design and manufacturing perspectives of the compressor disc, are held in the IODE. The Query and Facts Asserter tools are the IODE functionalities for interrogating and instantiating ontologies, respectively.
The interfacing of the compressor disc ontology with NX and Teamcenter can be achieved through the Java API. This is possible because most commercial CAD applications provide open API to help communicate information generated in the application. 32
Retrieving manufacturing-critical information
Figure 9(1) illustrates a compressor disc that has been modified in NX to accommodate changes in feature parameters, i.e. attributes, in order to satisfy a new set of design requirements for the disc. Once these changes are made, the validation stage is launched by selecting the Validate button. This action calls the Part Family and Feature Parameter Information dialog box and triggers a number of steps for retrieving manufacturing part family and manufacturing-critical design features and their parameters, as shown in Figure 9(2). The steps are as follows.

Part family and feature parameter information.
(A): The API communicates the design part family from NX and Teamcenter to the compressor disc ontology in the IODE.
(B): A KFL query is automatically generated to retrieve and display the associated manufacturing part family type(s).
(C): If there is more than one type of manufacturing part family the designer needs to select the appropriate one. This decision is largely dependent on the site or factory at which the part is to be produced. Selecting a manufacturing part family triggers another KFL query, which helps identify the design features that are critical from a manufacturing viewpoint.
(D): A further level of guidance is offered to the designer who can select a manufacturing-critical design feature to view its corresponding critical feature parameters. It is important to note that the ability to target the required knowledge is dependent on generating the right queries. In the approach, it is clear that manufacturing-critical entities always participate in knowledge verification constraints, and can therefore be referenced appropriately.
The designer then selects the Validate changes against manufacturing part family button to complete the retrieval of manufacturing-critical information.
Validating manufacturing-critical information
Within the scope of this work, the validation of manufacturing-critical information may be regarded as an approach that falls under the broader umbrella of verification, validation and accreditation (VV&A) techniques, 45 which are exploited to achieve the credibility and acceptance of a formal approach.
Once the retrieval of manufacturing-critical information has been performed, the validation of feature-relevant geometric values from the NX environment is then prompted. The following stages complete the validation of manufacturing-critical information as shown in Figure 10.

Validation results.
(A): The parameters and values gathered from NX are transferred using the API and populated into the compressor disc ontology in the IODE via the Facts Asserter.
(B): The populated facts are assessed against the knowledge verification constraints within the ontology.
(C): If there is an infringement of a knowledge verification constraint, then, any violated manufacturing feature related to that constraint is displayed in a new dialog box.
(D): The designer selects a violated manufacturing feature to display its corresponding design feature(s) that has participated in the infringement. In the example, the WebProfile is one such violated manufacturing feature and the participating design features are Cob and Rim.
(E): When the designer selects a participating design feature, such as Rim, the related parameter, i.e. design feature, attribute that has contributed to the violated manufacturing feature, is then displayed.
(F): A further level of knowledge feedback is supported when the designer selects a related parameter, e.g. OuterDiameter of the Rim. This knowledge comes from the implicated violation constraint, more specifically the message carried by the knowledge verification constraint. This message is vital for making the designer aware of the nature of the issue in the designed part.
(G): Using the validation results as a basis for decision making, the designer can choose to undo parameter changes. Another option is to accept the changes made by selecting Continue Anyway. However, this option is considered as not preferred as proceeding with changes, which are known to lead to manufacturing issues, can potentially have significant consequences during the product lifecycle. Another button, Find Alternative Solutions, has been incorporated as a means of guiding the designer towards further validation tasks, such as contacting a manufacturing engineer or performing a collision detection test to verify the suitability of different cutting tools for machining purposes.
Discussion
The approach discussed in this article has demonstrated a motivating concept towards the achievement of interoperability across the design and manufacture stages of the product lifecycle. This has been made possible through the exploitation of mathematically rigorous ontologies that have been encoded in heavyweight format, to formally describe the meaning of PLM system concepts. This implies that the IMKS approach has contributed to answering the first related research question (see ‘Traditional approaches to information sharing in PLM’).
However, the IMKS approach has yet to be extended and additional effort is, therefore, required in order to progress into a more comprehensive framework recommendation to achieve interoperable PLM system development. An interesting direction would be to relate, apply and exploit the key functional blocks of the IMKS approach (see Figure 2) in the context of the components of existing interoperability frameworks, such as the framework for enterprise interoperability 46 and the IDEAS interoperability framework, 47 among others.
Second, this work has specified a formal ontology of generic manufacturing concepts from which individual design and manufacture domains can be extended. Together with the experimented ontological mechanisms, notably semantic constraints, subsumption, mappings and knowledge verification constraints, the feasibility in the timely feedback of knowledge from the manufacturing stages into design stages has been shown. This, therefore, tackles the second research question (see ‘Traditional approaches to information sharing in PLM’) addressed in this article.
It is, nevertheless, understood that not all knowledge can be captured in computational form. Thus, the investigated approach does not intend to replace the engineer’s final decision, but exists as a means of supporting the exchange of general, agreed and recurrent knowledge at different points throughout the product lifecycle. Furthermore, the implications of how to maintain formal knowledge over time has fallen outside the scope of this work, thereby implying a need to address ontology and knowledge maintenance. There is also an ongoing need to drive the feedback of service knowledge, in addition to design and manufacturing knowledge, as there are clear and related challenges that still need to be overcome. 48
The IMKS approach has also demonstrated, within its scope and experimental boundaries, that a progression towards more rigorous semantic-based approaches can be of benefit for tackling the challenges in managing the ability to share product, process and resource knowledge. However, a confined scenario of process and resource knowledge affecting product parameters has been implemented, leading to the relatively limited achievement in tackling the third research question (see ‘Traditional approaches to information sharing in PLM’). Hence, further scenarios have to be identified and experimented so as to meet the needs towards approaches for the improvement of product, process and resource lifecycle management. 18
From a usability perspective, the development of the ontologies presently requires a knowledge architect who also needs to be familiar with the domain to be modelled (see Figure 8). It would be helpful to subsequently consider the implications of having intelligent interfaces for more intuitive ways of allowing non-ontology experts to interact with ontologies and generating manufacturability constraints and rules. Moreover, the ‘interpretation and sharing’ functional block of the approach (see Figure 2G) would require more effort for improving the workflows in the knowledge sharing module and the design of GUIs that participate in that module.
In addition to this, the implementation of the IMKS approach has portrayed appropriate interfacing capabilities across a set of vendor-specific applications. From the perspective of adaptability to different PLM and CAD systems, it is understood that the interfacing requirements across dissimilar platforms can be met, as long as the required APIs are documented and made available for the implicated PLM, CAD and ontology environments.
Conclusions
The adoption of methods similar to the IMKS approach shall provide an imminent positive impact on the way that multiple product lifecycle applications interact for delivering knowledge sharing capability at the right place and time.
However, it should not be forgotten that there exists a number of areas that deserve further attention, e.g. change management of current information-driven systems into knowledge-driven systems, ontology management, knowledge maintenance and through-life engineering knowledge feedback. Opportunities are also present for extending the current manufacturing core ontology into a much richer model with structures to capture, e.g. assembly, shop-floor and service, knowledge.
Finally, based on the understanding displayed in this work, it is possible to extrapolate that there are two main directions for further exploiting the IMKS approach. First, it can be utilised as a short term solution, targeting an incremental improvement that supplements existing PLM systems with an expressive ontological basis to provide meaning to PLM concepts and to harvest the benefits of semantic definitions and rule-bases.
The other possibility, which is for a longer term prospect with radical improvement, would be to utilise the IMKS approach as a method to deliver PLM system development from scratch. Instead of data and information models, the emphasis would be on logic-based knowledge models for system design and implementation. Regardless of the pursued direction, the advantages of knowledge over information and data would be gained, which is especially pertinent to complex manufacturing-centric ecosystems that generate product, process, resource and service knowledge.
Footnotes
Acknowledgements
We wish to thank our industrial partners, notably Rolls-Royce, Highfleet, Siemens, Ford and Emergent Systems, who have collaborated in the interoperable manufacturing knowledge systems (IMKS) project.
Funding
This work has been supported by the Engineering and Physical Sciences Research Council under project 253 of the Loughborough University Innovative Manufacturing and Construction Research Centre (IMCRC).
