Keywords

1 Introduction

The complexity of Product Development Process (PDP) has increased over the years to meet the customer’s needs. This process requires continuous information sharing with different groups within institutional boundaries as well as across multiple organisations. Thus, the current PDP’s approaches of information exchange have been based on the product master models, as detailed in [1, 2]. These approaches have a strict information structure, but mistakes and misinterpretation issues have been identified across different PDP phases [3, 4]. This occurs because PDP has a set of transdisciplinary activities and multiple viewpoints that generate semantic obstacles without interoperability. The lack of interoperability is expensive for several globally distributed companies as discussed by [5].

Several resourceful efforts have been fostered to integrate solutions, following product master models through the definition of common information models. This is the way that international standards have been providing basis for product information exchange, e.g. STEP PLCS (ISO 10303). Related works such as OntoSTEP [6], OntoSTEP-NC [7], PRONOIA [8], and Semantic Annotation applied to PLM [9] indicate that there is a tendency to explore the use of Semantic Web ontology languages, like the Web Ontology Language (OWL), to model the knowledge of product models. However, a significant problem is to work with multiple domains since it is necessary to find effective and technical methods for semantically map information across related domains during the PDP. It is also evident that current works do not entirely address the rules to establish an analysis of product requirements, defined by the costumer alongside the product design and manufacturing. Product requirements define the constraints and characteristics of a product and its information must be effectively shared across different phases of PDP without losing any meaning [10].

Based on this context, this paper proposes a model-driven ontology concept to formally structured a product design and manufacturing interoperability system and the establishment of the main rules for the information and knowledge sharing to achieve the semantic interoperability in the PDP. Thus, the main contributions of this research are highlighted as: (i) improvement in product design and manufacturing information and knowledge sharing; (ii) interoperability between multiple domains; (iii) continuous analysis of product constraints across the PDP.

2 Technological Background

Product Life Cycle (PLC) describes every phase a product goes through, from the first definition into retired and disposal. It is composed by different phases such as: (i) Conception; (ii) Development; (iii) Manufacturing/Production; (iv) Utilization/Maintenance; and (v) Retirement/Disposal. While PLC has a holistic view of whole phases of Product, PDP has a set of multidisciplinary activities structured to transform market opportunities, customers’ needs and technological constraints in products [2]. PDP is complex because information from multiple knowledge fields are simultaneously shared and exchanged through heterogeneous groups that may jointly function in institutional limits and across multiple organisations [11]. Although, PDP has a full view of product, providing information support to different phases of product development, misinterpretation and mistakes has been identified in it, highlighting mainly in the design and manufacturing phases [12]. According to Rozenfeld et al. [2], the activities of design and manufacturing are most costly (85% of product final cost). Therefore, in a modern PDP, design and manufacturing information and knowledge handling must be efficiently shared across different phases of PDP.

This is a typical semantic interoperability problem for which the meaning associated to the captured information and knowledge must be effectively shared across systems without any loss of the meaning and intent of the information and knowledge during the exchange process [13]. The most common way to support information sharing has been to explore integrated solutions through defining common information models [14, 15]. In this way, improved information sharing is being investigated through constructing formal ontologies [16] in different domains of application such as engineering, medicine, dentistry, business, etc. Some related works.

Gruber [17] originally defines ontology as an “explicit specification of conceptualization”. Another important definition is provided by ISO 18629:2005 [18] that ontology is “a lexicon of specialised terminology along with some specification of the meaning of the terms in the lexicon”, where lexicon is the vocabulary of a language. Ontologies can be classified according to their degree of expressiveness. Simple ontologies, for example, involving only taxonomy of concepts and basic relations, are referred to as lightweight ontologies. Ontologies with concepts and relations as a lightweight ontology enriched with axioms in the form of constraints are classified as heavyweight ontology. According to [19], axioms are used to clarify the intended meaning of the terms gathered on the ontology. However, ontologies are usually limited to the purpose of its application and it has limited reusability outside the scope of its application. Thus, ontology integration is an important task to achieve different levels of integration. Ontology integration is the process of finding commonalities between two different ontologies O and O′ and deriving in a new ontology O″ [19]. Based on this, three approaches for combining heterogeneous ontologies can be distinguished: (i) Ontology Inclusion; (ii) Ontology Mapping; and (iii) Ontology Merging.

Although, ontologies create semantic formalisms, a expressive problem is how to work with multiple ontologies of multiple domains to provide an effective mapping information across them [20]. Ontology mapping has been a key direction to tackle semantic heterogeneity issues across ontologies, intending to promote semantic interoperability. Several categories of ontology mapping methods have been suggested [21, 22], but there is a common consensus over the types of methods that can be applied. These types are: (i) Merging; (ii) Transformation; (iii) Alignment; and (iv) Articulation. Related works as [21, 22] present significant results on using matching techniques that use the semantics of logic-based systems, which employ upper ontologies. Therefore, this work uses the structure of product development process, ontologies and ontologies mapping ontologies to extract and enrich information to support the information sharing across PDP design and manufacturing phases in a transdisciplinary environment and in accordance to the customer’s needs.

3 Interoperable Product Design and Manufacturing System Concept

Semantic interoperability is achieved when the meaning associated to the information and knowledge captured in computational form can be effectively exchanged across systems without losing any meaning and intent of the information and knowledge during the exchange process [13]. Additionally, IEEE [23] defines interoperability as the capacity of two or more systems to exchange information and to use the information that has been shared. Therefore, it is necessary to develop model-driven to semantic interoperability that provides balance and integrates multiple domain work and developers team with distinct viewpoints to allow the information exchange in a computational form across different phases of PDP.

In this context, Fig. 1 depicts the Interoperable Product Design and Manufacturing System (IPDMS) concept to support the information exchange in a computational form across three different phases of PDP. The concept uses a semantically well-defined core of concepts and constraints to instantiate the information in the application view and link them to with the semantic rules. Thus, the architecture of IPDMS is composed by four views: (i) Foundation View; (ii) Application View; (iii) Semantic Reconciliation View; and (iv) Constraints View. The three phases of PDP are exposed on Detail A of Fig. 1: (i) Conceptual Design Phase; (ii) Tooling Design Phase; and (iii) Manufacturing Design Phase. IPDMS works based on formal models and semantic reconciliation trough the semantic mapping concepts. The implication of each part of the IPDMS concept is next explained.

Fig. 1.
figure 1

Architecture of the Interoperable Product Design and Manufacturing System (IPDMS) Concept.

Full size image

3.1 Foundation View and Application Domain View

The Foundation View (FV), detail B of Fig. 1, gathers and expressively represents concepts of different domains in a formal models at a relatively high level of abstraction. FV has Product Design Core, Tolerances Core, Materials Core, Manufacturing Core, etc. Common Logic Based formalism is used to govern the way that the concepts can be formalised at the computational level.

In this way, we are using the ontologies approach to structure the FV, but we are not building ontologies. Thus, two distinct procedures to formalize the concepts based on ontological approaches are been used: (i) standards and information model in UML structure are formalize in a lightweight representation; and (ii) representations already published in ontology libraries, such as [DAML, OWL: Library, JOWL, DBpedia] are analysed and integrated to the FV. For both procedures, it is used Web Ontology Language (OWL) [24] with axioms rules in Semantic Web Rule Language (SWRL) [25].

The cores in FV can be individually specialized in the Application Domain View (ADV) to meet the needs of specifics Product Design and Manufacture domains. Thus, the ADV was structured in Product Model and Manufacturing Model, as illustrate in Detail C of Fig. 1. A product model may be defined as an information model that stores information related to a specific product. The same occurs with the manufacturing model that has specific information related to the method to perform the product. According to [13], product and manufacturing models have key role on PDP because they hold and share product information that are generated, used and maintained over the process of design, manufacturing, production, maintenance and disposal. Figure 2 illustrates an example of three specialisations from the FV to the ADV to create the semantic links between concepts and a specific product.

Fig. 2.
figure 2

Link between foundation view and application domain view.

Full size image

3.2 Semantic Reconciliation View

Several transdisciplinary information are shared across different phases of PDP and need to be integrated to other models in the ADP to verify possible inconsistencies. In the event that these models need to interoperate with the intention of sharing knowledge, domain semantics need to be reconciled. Semantic Reconciliation View (SRV), detail D of Fig. 1, covers relevant applied ontology-based techniques enabling the reconciliation of domain semantics.

These techniques work segments of known ontology matching methods such as: (i) the computation of contexts for domain ontologies [26]; (ii) ontology mapping [21, 22]; and (iii) semantic alignment [27]. Based on this, Fig. 3 illustrates the basic concepts involved in the mapping of domain models at the SRV. The process of semantic reconciliation can be performed between pairs of models at a time, as can be encountered in almost all-current ontology mapping frameworks and methodologies [21]. Context Adjustment involves a first stage of contexts adjustments (namespaces in this case) of two domain models which are to be reconciled. Following this stage is a simple ontology intersection process, where both models are intact loaded on to a single specialise ontology. The last procedure in the SRV is the semantic alignment, where semantic mapping concepts are loaded into the intersected models.

Fig. 3.
figure 3

Stages of semantic reconciliation view.

Full size image

3.3 Constraints View

The Constraints View (CV), detail E of Fig. 1, gathers the restrictions for developing the product based on the Product Requirements defined by the customer’s needs and technological specifications. Requirement is a statement from the stakeholder’s needs to define a product; system or process characteristics and it must be unambiguous, clear, unique, consistent, stand-alone and verifiable [10]. Additionally, according to ISO/IEC 15288 [28], a requirement must be complete, coherent, unique, feasible, traceable and verifiable. Each requirement matches a single part of the future product, system or process and is grouped in an appropriate combination of textual statement views. Based on that, product requirements are used to create constraints rules to govern the way to develop the product and verify the consistency of the product design and manufacturing. Figure 4 presents the main concepts involved to add these requirements in the IPDMS.

Fig. 4.
figure 4

Phases of constraints view.

Full size image

Firstly, the main facts are manually mapped in the requirement statement and modelling in a Conceptual Graphical approach as discussed by [4]. For this modelling is used the ORM (Object Role Modelling) that is a fully communication oriented information modelling method rooted in NIAM (Natural language Information Analysis Method) [29]. According to [30], ORM has been used in ontology engineering to model domain ontologies. Thus, the product requirements in ORM are translated to heavyweight ontologies with axiomatic rules that are submitted to the semantic reconciliation view and matched in application domain view.

4 Case Study: Preliminary Results

An experimental system has been designed and performed to validate the Interoperable Product Design and Manufacturing System (IPDMS) model-driven approach and a rotational product was chosen to explore it. The product is a polystyrene cup with thermal conservation properties, as illustrated at the left side of Fig. 5. The figure also presents a simple demonstration of the IPDMS concept, supporting the information sharing from product concept design phase to product tooling design phase.

Fig. 5.
figure 5

IPDMS experimental demonstration system.

Full size image

This test case explores the material and dimension information sharing to reduce the problems with product shrinkage, which is inherent in the injection moulding process. Shrinkage occurs because the density of polymer varies from the processing temperature to the ambient temperature. According to [31], during the injection moulding, the variation in shrinkage creates internal stress. If the internal stress are high enough to overcome the structural integrity of the product, the product are going to wrap upon ejection from the mould or crack with external load during the extraction. Therefore, during the conception design and tooling design phases is necessary to share and transform information of the material properties and dimensions. This is a semantic obstacle because the meaning information found in the product concept must be effectively shared to product tooling design.

The IPDMS experimental demonstration is illustrates in Fig. 5. The product dimensions and geometry are extracted from the product modelled in CAD (Computer Aided Design) and structured in a XML file as illustrated on detail A of Fig. 5. The XML file has the context alignment in the Semantic Reconciliation View that identifies the main concepts and search in the foundation view the core ontologies, detail B of Fig. 5, related to the information extracted from the CAD. In this test case, the ontologies specialized in the product model are material core ontology and design core ontology and the ontologies specialized in the manufacturing model are material core ontology and manufacturing core ontology. The core ontologies identified in the foundation view are specialized in the Product Model and in the Manufacturing Model of the Application View, as shown on detail C of Fig. 5 and instantiated with the specific information extracted from the CAD model.

Additionally Requirements, Specifications and Technological Constraints are added to the models through the constraint view, detail D of Fig. 5, such as: Material Name, Maximum Temperature, Liquid Type, Injection Process Type, etc. These new information are semantically reconciled and intersections occur between the constraint ontology and specialized ontologies. Thus, new semantic rules are established between the both ontologies through the SWRL (Semantic Web Rule Language) and shrinkage properties are embedded in the models. Moreover, concept mapping are established between the Product Model Ontology and Manufacturing Ontology Model as well as Semantic Rules in SWRL.

According to the set of formal information and rules defined in the specialized ontologies in product and manufacturing model, a new xml file is created and is responsible for the product tooling design, as show on detail E of Fig. 5. Part of the product tooling design can be automatically performed, respecting the rules of the shrinkage process, injection process and product dimensions and tolerance. Furthermore, constraints can be added to the model, as illustrated on Detail F of Fig. 5, such as: Machine type, Injection Pressure, Cooling Time, Melt Temperature, Mould Temperature, Holding Pressure. This new XML file is converted to a CAD file and the new 3D model with the tooling design is built.

This preliminary test case shows the performance of the IPDMS concept. The preliminary results show the potential of the semantic interoperability to reduce the semantic obstacles. In the test case, shrinkage issues were solved by a structured information exchange from the product design to manufacturing.

5 Conclusion

This paper presented the development of an Interoperable Product Design and Manufacturing System (IPDMS) concept that are able to exchange information from multiple domains across different phases of PDP in a semantic interoperability manner. The IPDMS supports the product developers, providing structured and formal information as well as transforming automatically information based on the knowledge added to the system.

The IPDMS concept uses a semantically well-defined core concepts and constraints, modelling in ontologies, to instantiate the information in the application view and constraint by semantic rules. The concept architecture has four different views: (i) Foundation View, (ii) Application View, (iii) Reconciliation View and Constraint View. The Foundation View has core concepts relating to PDP, such as: material core, design core, manufacturing core, dimensional tolerance, geometry tolerance, etc. The concept core is modelled in OWL language with semantic rules in SWRL. The core concepts are specialized in Application View in Product Model and Manufacturing Model and enriched with the detailed information of the product that is being developed. More information can be added to this model by the constraints view and all information are semantically reconciled and interrelated through the semantic reconciliation view.

This concept was evaluated in a preliminary test case. The product is a polystyrene cup with thermal conservation properties. In the evaluation process the concept potential to support the information sharing between the conceptual designs and tooling design to avoid the shrinkage issues was analysed. The 3D model information was extracted and submitted to the IPDMS concept. More information was added through the constraints view. In the IPDMS, instances, context alignment, ontologies intersection and mapping concepts were established to create a product and manufacturing ontology model specialized with semantic rules to design the product tooling. The results demonstrate the potential of this concept to reduce the semantic obstacles during the information sharing across the PDP. To extend this research work it is necessary to explore more variables simultaneously and more phases of the PDP in order to analyse the potential of this concept in working and sharing information from multiple domains across different phases of PDP.