Product-Assembly Planning Ontology for Integrating Product Design and Assembly Process Planning (APP)

Abstract

This paper presents a semantic approach to support knowledge sharing in the assembly domain. Specifically, it focuses on capturing and sharing assembly design knowledge and on integrating the assembly design domain with the Assembly Process Planning (APP) domain through ontological modeling. A multilayered, heavyweight ontology framework, called the Product-Assembly Planning Ontology (PAPO), is proposed to integrate product assembly and APP. The ontology is based on product assembly features and uses these design features to provide the high-level semantic knowledge necessary to integrate product assembly design with APP. The paper also describes a detailed methodology for ontology design. Additionally, a rule-based engine is developed to reason about the available assembly design and APP knowledge and to infer new knowledge from them. Case study examples are included to illustrate the approach.

1. Introduction

In the Industry 4.0 era, assembly systems need to be highly adaptable to meet evolving production demands, including mass customization and personalized manufacturing, which require managing high product diversity, shorter product life cycles, and customer-specific requirements [1]. This can be achieved by promoting knowledge sharing between product design and manufacturing systems. The Evolvable Production Systems (EPS) paradigm, developed through European projects like EUPASS [2] and IDEAS [3], linking the product design and manufacturing system was a key aspect of EPS, offering significant benefits. Once a dynamic connection between detailed product design and potential production modules was established, the next step involved creating tools to analyze assembly processes from a product perspective, enabling the selection of appropriate equipment (for manufacturing). This article discusses some of the work performed during the development of such a tool, connecting production system development with product design phases.

Knowledge sharing between product design and manufacturing is essential; for example, as reported by True and Izzi [4], product design can account for up to 70% of a product’s lifecycle costs. However, capturing and sharing knowledge between product design and manufacturing remains a challenging task both on the domain and application levels. The challenge stems from the use of different conceptualizations to describe the same objects across domains, as well as heterogeneity among software applications. These challenges can be avoided by supporting semantic interoperability between product design and manufacturing. Semantic interoperability can be achieved when the meaning associated with captured information and knowledge can be shared across different domains/applications without any loss of information and knowledge [5].

Assembly is one of the most complicated tasks in a manufacturing environment [6]. Assembly involves combining components and requires a collaborative work environment across different domains to achieve an assembled or semi-assembled product. Product design and assembly process planning (APP) are critical domains for successful product realization. Both domains represent different perspectives on the same concepts and use different software applications, creating semantic interoperability issues. This research focuses on capturing and sharing assembly design knowledge to enhance the integration between the assembly design and assembly process planning (APP) domains. The research is based, in its first stage, on product features, utilizing product assembly design features to provide high-level assembly semantic knowledge necessary for integrating product assembly design with APP. This stage also includes using feature recognition techniques to extract assembly semantic knowledge from CAD software (SolidWorks © 2024). The second stage involves sharing the recognized assembly semantic knowledge through a layered ontology structure, which serves as a means of communication between assembly design and the APP.

Recently, ontologies and semantic web technologies have been widely applied to achieve semantic integration and to enhance semantic interoperability. An ontology attempts to define concepts, the mutual relations between them, and the constraints governing those relations. Several definitions have been addressed for an ontology [7,8]. One of the most comprehensive definitions is the one reported by [9]: “An ontology is a formal description of the entities within a given domain, the properties they possess, the relationships they participate in, the constraints they are subject to, and the patterns of behaviour they exhibit”. In this definition, formality is mentioned as one of the fundamental requirements for the ontology. Formality is highly related to interpretation by computers; the more formal an ontology is, the more interpretable by computers it becomes [10]. Ontologies are also classified according to the level of rigor and restrictions applied to the terminology conceptualized in the ontology into heavyweight and lightweight ontologies [10]. Heavyweight ontologies use axioms and constraints to restrict the meaning of terms and facilitate the deduction of new knowledge. Lightweight ontologies use textual definitions of concepts and terms, which can lead to ambiguities in defining their semantics [11]. Other classifications are based on the level of generality [12] and on the conceptualization structure [13]. Both classifications distinguish between upper ontologies (generic, top-level ontologies), domain ontologies, and application ontologies. Upper ontologies consist of generic, abstract, and high-level concepts that can be applied to a wide range of domains. Only a very general level of knowledge modeling can be done by using upper ontologies. An example of an upper ontology is a foundation ontology, which provides a knowledge base for more specialized ontologies, such as domain and application ontologies [14]. Domain ontologies consist of domain-specific concepts, whereas application ontologies capture the semantics of a specific application within a domain. The level of generality decreases from the upper to the domain and application ontologies.

In this paper, a formal heavyweight multi-layer ontology structure is proposed to provide a common semantic knowledge base that supports knowledge sharing across product design and assembly process planning (APP) at both the domain and application levels.

Figure 1 illustrates the proposed Product-Assembly Planning Ontology (PAPO) structure, where each layer shares a set of concepts that are specialized from the most generic to the most specialized levels. The foundation ontology is the first upper-layer ontology, which is designed to provide common concepts, such as product, feature, process, and resource, that are inherited by the domain ontology layer. The domain ontology layer represents the second level of the proposed structure, adding domain-specific concepts to a particular domain. The product design domain is further specialized into feature-based and assembly model domains. The feature-based model domain represents the product design’s geometrical knowledge (its form). Concepts such as Form Feature, Singular Feature, Pattern Feature, and Primitive Feature are specified in the product domain ontology’s feature-based model. The assembly model domain represents the behavior of the design unit during assembly.

Figure 1. Ontology structure and knowledge sharing between product design and APP domains.

Concepts such as Assembly Feature, Mating Feature, Alignment Feature, and Joining Feature are specified in the product domain ontology’s assembly model. The APP domain is further specialized into the process and resource model domains. Concepts such as Assembly Process, Joining Process, Handling Process, and Screwing Process are specified in the process model of the APP domain ontology. In contrast, concepts such as Assembly Resource, Assembly Cell, Assembly Device, and Factory are specified in the resource model of the APP domain ontology. The third layer is the application ontology layer; in this paper, two application ontologies are included: The SolidWorks © 2024 application ontology and the assembly device application ontology. Concepts such as 3–D Feature, Mates, Reference Attributes, and Technology Entity are specified in the SolidWorks application ontology; on the other hand, Concepts such as Vacuum Gripper, Robot, and Finger Gripper are specified in the assembly device application ontology. Those ontologies capture semantics specific to each application. Two applications have been included: SolidWorks, a product design application, and an assembly robotic device (i.e., a high-speed assembly robot, Sony SRX series) as an APP application.

One of the main advantages of ontological modeling over other modeling types is its extensibility—the ability to expand as new knowledge emerges. The proposed multi-layer ontology structure effectively utilizes this advantage by facilitating expansion into new domains or applications. New domains and their related applications could be easily created and plugged into the existing multi-layer ontology structure.

Another main advantage of an ontology model is its reasoning capabilities. Ontology reasoning is based on the formal and logic-based specifications of the knowledge modeled in the ontology. Reasoning mechanisms will help answer cross-domain queries over ontology concepts and instances, infer new knowledge from existing knowledge, integrate and align heterogeneous knowledge resources, and provide decision support to designers and process engineers. In our proposed ontology structure, reasoning mechanisms are used to integrate domain and application ontologies, to infer and query new knowledge, and to design a rule-based decision engine that provides an automated, bidirectional link between assembly design and APP. More specifically, reasoning is used to extract implicit CAD assembly knowledge from the explicit knowledge provided by CAD software. Consequently, this will support the enrichment of recognized CAD assembly semantic knowledge and help determine the required processes and resources in the APP domain. Figure 2 illustrates the architecture for integrating assembly design knowledge and the APP system.

Figure 2. The architecture of the assembly design knowledge and APP integration system.

In this paper, assembly design and APP knowledge, represented in the ontology structure, are formalized in OWL (Ontology Web Language) [15], a semantic ontology representation language developed by the World Wide Web Consortium [16]. The rule-based decision engine is developed using SWRL (Semantic Web Rule Language) [17], a rule language based on OWL, and Drools [18], a rule engine for the Java platform.

2. Background Literature: Product Design—APP Integration

There are many frameworks proposed for utilizing ontology in manufacturing-related domains such as product design, manufacturing, maintenance, assembly design, process planning, and APP. In this section, representative literature on applying ontologies to integrate product design and manufacturing is reviewed, specifically integrating product assembly design knowledge with APP.

Product features have served as the basis for most integration frameworks between product design and manufacturing. A helpful understanding of a feature is provided by the definition in Wierda [19]: “a feature is a partial form or a product characteristic that is considered as a unit, and that has a semantic meaning in design, process planning, manufacture, cost estimation, or other engineering discipline”. The importance of features as a bridge between product design and manufacturing has been extensively addressed in the published literature [20,21]. Assembly feature-based design [22] has been considered an extension of feature-based design for linking assembly design and APP. Van Holland [23] utilized assembly features in process planning by defining them as “features with significance for assembly processes”. The same author introduced more specific assembly features from a process perspective: connection features “such as final position, insertion path/point, tolerances” and handling features “characteristics that give the locations on an assembly component that a gripper can safely handle during assembly!” The assembly feature integration approach has been further extended by deriving object-oriented representations of assembly features [24] and their semantics [25]. A new integration approach based on assembly feature semantics is known as the Assembly Semantic Model [26]. This approach is primarily used to model assembly design knowledge and to provide sufficient information about the relationships between connected components/parts and the precedence constraints between connections. Since the efficiency of APP depends heavily on how the assembly design is modeled, this approach is considered a critical stage in integrating assembly design with APP.

In the published literature, some ontology-based integration approaches focus on capturing product design details, while others focus on manufacturing details. A few approaches try to balance the captured details between manufacturing and product design. Some other approaches try to integrate assembly design and assembly process planning.

On the manufacturing side, the Manufacturing Semantic Ontology (MASON) is proposed by [27] to support the capture and sharing of manufacturing knowledge. Manufacturing knowledge is captured through three main concepts: entities, operations, and resources. Entities represent both geometrical and non-geometrical knowledge (e.g., materials and costs). Operations represent manufacturing processes (e.g., machining and logistics). Resources represent both manufacturing and other resources (e.g., human resources). A machining ontology is proposed by [28] to represent knowledge in the manufacturing domain. This machining ontology includes geometrical knowledge (form features), machining processes, and machining resources. A metadata-based manufacturing resource ontology for the standardized semantic description of manufacturing resources (MRs) in cloud manufacturing (CMfg) systems is introduced by [29]. The ultimate purpose of the proposed ontology is to facilitate integration, sharing, and reasoning between distributed, autonomous, and heterogeneous MRs in CMfg systems. The proposed framework consists of a manufacturing resource domain ontology (MR_Onto) that semantically represents MRs in a structured manner using six main concepts: MResources, CServices, Owners, Knowledge, Transaction, and Status. MR_Meta, a metadata model for manufacturing resources, is also proposed to provide a formal description of resource attributes. To realize the transformation between MR_Onto and MR_Meta in the proposed framework, metadata-ontology mapping rules are also defined. A modular ontology for manufacturing systems based on the ISA-95 standard [30] (a multi-level framework developed by the International Society of Automation (ISA) for defining manufacturing systems in a hierarchical structure to enhance interoperability and knowledge sharing across these levels), extended with Semantic Web Rule Language (SWRL) rules to enhance knowledge representation and reasoning (KR&R), is proposed by [31]. The proposed work provides a standardized, modular, extendable, and reusable framework for describing manufacturing systems in accordance with the ISA-95 standard. The modular framework consists of sub-ontologies: Hierarchy ontology (representing level one and two of the ISA-95 standard, this ontology defines hierarchy models, object models, and attributes), OperationType ontology (represents level three and four of the ISA-95 standard, this ontology focuses on production management operations, including scheduling, resource dispatching, execution management, and recording operational data), and Resource ontology (represents resources as entities and providing capabilities for enterprise activities and business processes; this ontology serves as an intermediary level between the hierarchy and operation type ontologies and works as an intra- and inter-information exchange layer). These sub-ontologies are imported into a unified Enterprise Control Ontology (ECO), which serves as the framework’s unified ontology. Šormaz and Sarkar [32] introduced an upper-level ontology to address challenges in manufacturing process planning (MPP) in distributed and cloud-based manufacturing environments. These environments require flexible, dynamic process plans because of decentralized resources and varying shop-floor conditions. A semantic structure for manufacturing process planning is proposed that models three fundamental constraints: variety, time, and aggregation. It aims to integrate diverse manufacturing resources and dynamically generate process plans based on real-time shop-floor conditions and product design changes. OWL 2.0 is used to define the SIMPM structure, and SWRL rules match design specifications (e.g., geometry, tolerances) with the capabilities of manufacturing resources (processes, machines, tools) and infer new knowledge based on the defined logic rules. Wan et al. [33] proposed an ontology-based, multi-layer architecture to enhance the resource reconfiguration method for manufacturing cyber-physical systems (MCPS). The proposed method used an OWL ontology to define a knowledge base for manufacturing resources, enabling semantic modeling, knowledge sharing, reasoning, and resource allocation. The proposed architecture comprised four layers: a resource layer for shop-floor physical entities; a knowledge layer consisting of ontologies to model domain resources; an SWRL rule layer for a knowledge-base engine to support reasoning and decision-making; and a data layer where distributed databases store real–time data. The proposed architecture aims to support responsiveness, intelligence, and efficiency in MCPS and to be integrated with the Industry 4.0 environment, which presents challenges such as personalized customization, small-batch production, and efficient resource allocation. CDM-Core, a general manufacturing domain ontology, is presented by [34]. CDM-Core is being developed as a comprehensive manufacturing domain ontology for production and maintenance within the Horizon 2020 CREMA project. The ontology is built using the W3C standard OWL2-DL language [12]. It covers general manufacturing domains and is used in cases such as metal press maintenance and automotive exhaust production. The presented ontology supports the semantic description of process models, services, and sensor data for manufacturing use cases.

On the product design side, a product ontology to integrate production planning systems with product design applications is proposed by [35]. In this ontology, concepts are drawn from product data management [36] and enterprise integration [37] standards. The ontology includes concepts such as Product, Part, Component, and Assembly Component relationships to represent assembly areas within production planning and product design domains. Another product design ontology is proposed by [38] to integrate product design and Design for Manufacture (DFM). Their work also includes ontology, a development methodology for DFM. A product development ontology is proposed by [39] to support the reuse, integration, and sharing of design knowledge for decision-making during the product development process. The Manufacturing System Engineering (MSE) ontology was proposed by [40] to exchange knowledge across multidisciplinary design areas.

On both the product design and manufacturing sides, a product design and manufacturing process ontology is proposed by [41]. This ontology focuses on reusing knowledge from the Design Failure Mode and Effects Analysis (DFMEA) and Process Failure Mode and Effects Analysis (PFMEA) processes in manufacturing. An ontology to support knowledge sharing between the design and manufacturing domains is suggested by [42]. Their ontology enables the capture of manufacturing knowledge to support informed decision-making and knowledge sharing. A semantic manufacturing interoperability framework (SMIF) is proposed by [5] mainly to facilitate interoperability across product design and manufacturing domains. The SMIF consists of a multilayer ontological framework, in which the first layer provides a foundational ontology for modeling the domain. Domain ontologies for product design and manufacturing are provided by the domain ontology layer. The following two layers, Semantic Reconciliation and Semantic Interoperability, are dedicated to supporting interoperability and knowledge sharing across domain ontologies. Ref. [43] developed the ManuService ontology to represent a service-oriented product data model that facilitates make-to-individual production strategies in a cloud manufacturing environment. The proposed semantic framework seamlessly integrates concepts from international standards such as [44], which covers both manufacturing activities (e.g., machining, part handling, process validation) and non-manufacturing activities (e.g., inspection, assembly, packaging, and transit). It also integrates [45,46], both of which focus on data model representation and data exchange. This approach can enhance interoperability and enable cross-domain data exchange between product design and process planning. The proposed semantic model is based on a feature-based representation of product design knowledge, defining a semantic hierarchy composed of classes such as Project, Product, Item, Feature, Drawing, and Workplan. These classes provide a structured, comprehensive representation of product design for integration with manufacturing resources in the cloud environment. The ontology primarily focuses on machining features, including milling, turning, and hole-making features. OWL-DL with SWRL is used to formally construct the ontology and reason about the knowledge. A knowledge-based engineering (KBE) approach proposed by [47] integrates robotic manufacturing resources with user requirements and design perspectives. In this approach, ontological semantic models represent and infer relationships among functional requirements, including common (e.g., displacement, power supply) and specific (e.g., manufacturing tasks such as welding, cutting, engraving) functions of robotic manufacturing systems, and non-functional requirements, including Systems Properties (e.g., safety, cost, maintainability) and Workpiece Properties (e.g., cost, material, and dimensions). Two models are developed: the ontological Knowledge Model, which provides a structured semantic representation of user requirements, the architecture for robotic manufacturing systems, and their interconnections, and the Multi-Attribute Decision-Making (MADM) Model, which supports decision-making to select the most suitable robotic manufacturing architecture from the valid alternatives suggested by the ontological knowledge model. OWL is used to implement the proposed ontology, and SWRL and SQWRL (Semantic Query-Enhanced Web Rule Language) are used to query inferred results and retrieve valid component combinations. An OWL-based ontology to describe the capabilities of manufacturing resources, the Manufacturing Resource Capability Ontology (MaRCO), is addressed by [48] in a neutral, standardized, vendor-independent way. The proposed ontology aims to support the rapid, semi-automatic design, reconfiguration, and auto-configuration of production systems by automatically matching product requirements with resource capabilities represented in a vendor-neutral format, thereby enhancing interoperability and reusability and facilitating the adaptation of manufacturing systems to changing production demands. In the MaRCO ontology, product design is modeled by classes such as Product (which is further inherited by Part and Assembly subclasses). These classes describe product design specifications, which can then be matched to the required processes and capabilities through the Workplan class, which represents the sequence of process steps required to manufacture the product, and the ProcessStep class, which represents individual steps in the manufacturing process. These two classes serve as the link between the product model and the process taxonomy; product model specifications are imported into the process taxonomy via these classes. The other input to the process taxonomy is the capability model, which imports the manufacturing resource model. The MaRCO ontology is implemented in OWL, with reasoning enabled by the SPARQL Inferencing Notation (SPIN), which supports reasoning, inference, and automatic capability matchmaking.

Another multilayer framework, the Interoperable Manufacturing Knowledge System (IMKS), is proposed by [49] to provide seamless computer-based knowledge sharing between the departments of a manufacturing enterprise, specifically between product design and manufacturing. The IMKS supports interoperability by enabling the overcoming of semantic and syntactic differences during computer-based knowledge sharing through the use of foundation and domain ontologies. The IMKS is composed of four layers. The first layer provides a foundation ontology, later developed by [50], to establish common ground between the process specification language (PSL) ontology and the core ontology of product design and manufacturing concepts in the second layer. The third layer represents the domain ontologies (design and manufacture domains). The bottom layer in the proposed framework is the knowledge base layer. The knowledge base is built by using concepts from the domain ontologies in the upper layer. In the proposed approach, the knowledge base is populated by facts through a verification mediator. The verification mediator establishes integration between the product design and manufacturing domains by using queries to retrieve verified facts. The verified facts are sent to the manufacturing knowledge base for verification, ensuring that the manufacturing domain ontology raises no objections. The verification mediator then sends the verified facts back to the design knowledge base.

Ontology-based approaches for integrating product design and APP can be further categorized into two main approaches: the mereotopological design integration approach and the assembly feature-based design integration approach. The assembly design semantics in the first approach are based on mereotopological descriptions for assembly knowledge. In contrast, the second approach is based on geometric and topological descriptions of parts and on assembly knowledge provided by mates.

The first approach, as addressed in the literature, relies on Mereotopology (MT), a branch of logic that provides a qualitative formalization of two fundamental relationships between entities: parthood (i.e., one entity being part of another) and connection [51]. Design mereotopology (DMT) [51] is developed to identify and logically describe regions within geometrical entities and the interrelations between regions within a product. Ontological axioms have been used to restrict DMT to describe only regions of interest in the product design model. In this sense, DMT has been utilized in ontology-based assembly design modeling. A methodology developed by [52] to represent and differentiate assembly joint information in a collaborative product design environment based on a formal mereotopological ontology. In this ontology, assembly joining constraints are explicitly represented using SWRL rules and OWL triples derived from mereotopological definitions. The main contribution of [52] is the development of semantic definitions (e.g., for machine interpretation) for a theoretical mereotopological foundation of the assembly design. A novel approach has been proposed by [53] called PRONOIA (PROduct relatioNships description based On mereotopologIcAl theory) for defining product relationships based on mereotopological theory. This approach uses product relationships described by mereotopological primitives and Assembly Sequence Planning (ASP) to integrate assembly modeling and planning. The final integration stage is implemented using an OWL-DL (Web Ontology Language Description Logic) ontology and SWRL. A hierarchical multi-layer assembly knowledge representation framework (HAKF) and a microdevice assembly ontology (MA-Onto) are proposed by [54] to improve the efficiency and accuracy of microdevice assembly process planning. In their proposed framework, the authors used mereotopology to represent spatial relationships and part-whole relations in assembly knowledge. Spatial relationships between assembly objects have been described in terms of relative direction (spatial direction), proximity (spatial distance), and part–whole relationships between assembly features (spatial topology). The final integration stage is implemented by using OWL-DL ontology and SWRL. Web Ontology Language Description Logic (OWL—DL) is very descriptive in representing mereotopological Primitives.

The second ontology-based approach to support semantic integration between assembly design and APP, based on assembly features, has been adopted by several researchers. An ontology for modeling assembly processes is proposed by [55]. This ontology enables reasoning and querying of assembly knowledge using OWL and SWRL rules. An equipment ontology is proposed by [56] to support reconfigurability in manufacturing/assembly systems by facilitating decision-making for selecting assembly equipment. An ontology to capture product and process-related assembly knowledge and to integrate product design and assembly simulation is proposed by [57]. An assembly design ontology is proposed by [58] to provide a formal description of assembly design knowledge. The primary focus of that ontology was the assembly joint formalism, with a welding joint example provided. An assembly design ontology is proposed by [59] to capture assembly design knowledge for supporting the product development process. This ontology supports inferences and queries but lacks reasoning capability. Fiorentini et al. [60] proposed an ontology for representing assembly design. Their ontology is based on the Open Assembly Model (OAM) [61] and provides reasoning capabilities to support designers’ decisions. To model APP knowledge, Huang et al. [62] proposed an ontological model that covers key aspects of APP knowledge, including assembly requirements, spatial information, assembly operations, and assembly resources. Since no ontological formalism is reported for their work, it represents an incomplete attempt to model APP knowledge. A novel framework, an assembly reference ontology, that provides a common semantic base to support interoperability and knowledge sharing across the assembly design and assembly process planning domains, is proposed by [63]. Their work demonstrates the application of formal ontologies to knowledge sharing in assembly, focusing explicitly on concepts related to tolerance and fit, assembly features, assembly methods, and assembly resources. The ontological formalism used by [63] is the Knowledge Frame Language (KFL)which is based on Common Logic (CL) [64]. According to the authors, CL is more expressive than OWL [15] and better at representing the semantics of complex manufacturing concepts and relationships. Saha et al. [65] developed an ontology framework to support interoperability within and across welding standards. The Core Domain Ontology for Joining Processes (CDOJP) provides a modular, structured, formalized framework for consolidating and reconciling definitions and concepts across standards, ensuring interoperability and consistency. The proposed ontology aligns with major welding standards, including [66,67,68,69]. The ontology serves as a semantic knowledge base that explicitly captures the semantics of concepts and definitions, resolves contradictions within individual standards, and reconciles differences across them. The hierarchy ranges from general foundation concepts to domain and domain-specific concepts. The developed ontology links product design specifications to the required welding processes. It captures the relationships between product design elements, such as mating configurations, joint types, material properties, and the selection of appropriate welding processes. The ontology is more closely related to welding processes and the governing standards than to detailed design specifications. Design specifications are modeled as generic concepts that can be expanded. The CDOJP is formalized using OWL, and SWRL is used to define complex rules and enable advanced reasoning over different welding processes.

As a conclusion of this section, which provides a comprehensive review of ontology-based frameworks for integrating product design and manufacturing, with a focus on assembly design and assembly process planning (APP). Despite significant advances in developing ontologies to capture and integrate knowledge across these two important domains, several research gaps remain, which can be summarized as follows:

• Despite ontologies such as ManuService [43] and CDOJP [65], which are compatible and aligned with international standards, there is still no comprehensive universal framework that integrates diverse standards across the design and manufacturing domains. Some ontologies focus on product design standards, while others focus on manufacturing standards. This limits interoperability across standards in these two vital domains.
• Limited reasoning capabilities: Many of the proposed ontologies include rule-based engines to reason about available knowledge and infer new knowledge; despite this, most of them provide specific logic rules for specific incidents and processes, which limit the reasoning capabilities of these ontologies and, as a result, limit their ability to adapt to changes in manufacturing environments and domains, which is very critical for Industry 4.0 applications.
• Insufficient assembly design and APP modeling: Many ontologies provide concepts for assembly design and APP, but most lack formalism for all aspects of assembly design related to the required assembly processes. This is due to a lack of balanced, comprehensive formalism across all aspects of the design and the APP, including spatial relationships, tolerances, fit, and dynamic resource allocation. This limits the integration capabilities of the proposed ontologies.
• Improper modeling of assembly knowledge: Many proposed ontological frameworks lack modularity in modeling assembly design aspects and APP. Many of the proposed frameworks integrate geometrical, functional, and assembly data to model assembly design. This can complicate the reuse of assembly data in future product design projects, since the assembly data may remain valid across different geometries. It also complicates the extraction of assembly data from the design. On the other hand, there is a lack of modularity in modeling assembly processes and assembly resources, which are modeled as part of all manufacturing processes and resources. The complexity of assembly processes and resources necessitates separate models to formalize them in a rich, comprehensive way. The reusability of data depends heavily on how it is modeled. This improper modeling can affect efficient resource allocation, real-time data integration, and dynamic reconfiguration, especially in distributed environments such as cloud manufacturing. Therefore, the efficient use of ontologies in cloud manufacturing remains an open research gap that warrants further investigation.
• Lack of utilization of Mereotopology in modeling complex assemblies: Despite its use in assembly design modeling, there is a lack of its use in modeling complex assemblies, such as those with complex spatial relationships.

To address these gaps, our proposed ontology will use a balanced modular approach to separate feature-based data from assembly data on the product design side and to separate assembly processes and resources on the APP side. Modularity can enhance reusability and scalability in future design projects. The proposed ontological framework is based on product features to provide a comprehensive representation of all aspects of assembly design, with rich reasoning capabilities.

3. Research Methodology

The objective of this work is to enhance knowledge sharing across multiple design and assembly domains, particularly assembly design (feature-based and assembly design knowledge) and assembly process planning (process and resource knowledge). As detailed in the literature review, knowledge integration comprises two steps: knowledge capture and knowledge sharing. The proposed methodology, illustrated in Figure 3, is based on this. The methodology is mainly divided into five primary stages and follows the general ontology development methodologies reported in the literature [70,71,72,73].

Figure 3. Ontology development and utilization methodology.

The proposed methodology includes the necessary steps of ontology specification, conceptualization, representation, formulation, and utilization. The first step aims to identify the key concepts and the related terminology in each layer of the ontology structure. This step involves determining the ontology’s purpose and scope. Based on this, the proposed ontology’s layer structure is designed, and the key concepts for each layer are identified. This step was briefly discussed in the introduction, where key concepts and terminology for the different layers of the proposed ontology are illustrated (Figure 1). Conceptualization by determining the tree concept structure (the sub-concepts for the key concepts defined in the first step) for different ontologies is included in the second step.

OWL lightweight representation of the informally defined concepts is performed in the third step. This step involves categorizing the classes, developing the class hierarchy of the ontologies using an ontology editor (Protégé), identifying properties for the class hierarchy, and mapping relations among classes.

The fourth step involves ontology formulation, which entails adding axioms, specifying class properties, and establishing relations between classes and properties. The Semantic Web Rule Language (SWRL) tab and the Drools rule engine in Protégé are used to express mathematical and logical relations among properties in the ontology, thereby enabling automatic reasoning.

The fifth and final stage of the proposed methodology includes three complementary validation approaches that, together, demonstrate the developed ontology’s logical consistency and practical utility. The first validation approach is logical consistency validation, conducted at two levels using the HermiT 1.4.3 description logic reasoner within Protégé 5.5.0. The first level is at the module level; each of the seven developed ontologies—GFO, FBM-DO, AM-DO, PM-DO, RM-DO, SW-AO, and AD-AO—was loaded independently and subjected to a full consistency check before integration. This step, which verifies logical consistency for each module, is critical for identifying structural errors that would otherwise propagate undetected into the integrated ontology. The second level of logical consistency validation is for the complete integrated PAPO, which must undergo a global logical consistency check. The second validation approach is the experimental quantitative validation through Case Study Instantiation. This approach demonstrates the ontology’s capacity to represent real assembly scenarios and to respond correctly to formal queries using the Query tab in Protégé and the Protocol and RDF Query Language (SPARQL) The third validation approach is the Rule-Based Knowledge Inference Validation. This approach assesses the ontology’s ability to infer new knowledge by executing SWRL rules with the Drools rule engine via the SWRLTab plugin in Protégé 5.5.0. The detailed ontology development methodology is presented in the next section.

4. Ontology Development

In the following subsections, the development of the multi-layer ontology structure (Figure 1) will be detailed further using the methodology introduced above. Each ontological layer is developed according to the methodology steps (1–4), while the overall multi-layer ontology structure is used in step 5.

The development of the multi-layer ontology structure PAPO procedure follows a bottom-up architecture, illustrated in Figure 4, starting with ontological knowledge from general foundational concepts and progressing to domain and application representations. The development proceeds from the foundation layer to the overall PAPO integrated ontology.

Figure 4. PAPO development procedure.

In Figure 4, at the base of the architecture, the foundation and domain ontologies reside, implemented as a single merged ontology designated GFO-OWL. This is constructed by first developing the General Foundation Ontology (GFO) in OWL. Four domain-specific ontologies are then developed independently, each extending one of the GFO root concepts to introduce domain knowledge relevant to assembly planning: the Feature-Based Modeling Domain Ontology (FBM-DO, 13 classes), the Assembly Modeling Domain Ontology (AM-DO, 20 classes), the Process Modeling Domain Ontology (PM-DO, 11 classes), and the Resource Modeling Domain Ontology (RM-DO, 9 classes). These four domain ontologies are imported into GFO using the owl:imports directive, which causes the Protégé ontology editor to merge them automatically into a single unified GFO-OWL ontology. This merging ensures logical consistency, since all domain classes inherit the disjointness axioms and structural constraints of GFO without duplication. Above the foundation and domain ontologies, two application ontologies capture software-tool-specific and device-specific knowledge independently of the foundation. The SolidWorks Application Ontology (SW-AO, 81 classes) and the Assembly Device Application Ontology (AD-AO, 44 classes) are defined. Both SW-AO and AD-AO are developed as standalone ontologies with no owl:imports declarations, to ensure modularity and prevent the GFO and domain classes from appearing in their class panels during standalone editing. At the top of the architecture, the PAPO integrates all three sources of knowledge through three owl:imports statements for GFO-OWL, SW-AO, and AD-AO, respectively. A total of fifteen cross-layer rdfs:subClassOf axioms that establish the semantic connections between the application layer and the foundation-domain layer are declared in the PAPO. Furthermore, 22 SWRL inference rules are defined in PAPO to reason about the required assembly design and the required assembly process plans. The complete integrated PAPO encompasses 202 classes, 146 object properties, and 120 data properties, and can autonomously derive a recommended robotic assembly process plan directly from product design specifications through OWL reasoning and SWRL rule execution.

In the following subsections, the detailed development of the multi-layer ontology, PAPO, composed of three ontological layers, is introduced, with a set of ontologies for each layer. The following illustrates the development of these ontologies.

4.1. Ontology Development: Foundation Ontology Layer

The foundation ontology layer consists of the General Foundation Ontology (GFO). Foundation ontologies consist of generic, abstract, and high-level concepts that can be applied to a wide range of domains. Foundation ontologies also provide a knowledge base for more specialized ontologies. The GFO is the first upper-layer ontology, designed to provide common concepts—such as product, feature, process, and resource—that are subsequently inherited and expanded by the product design and APP domain ontologies provided by the second layer of ontologies. Figure 5 shows concept definitions and attributes for the GFO.

Figure 5. Class hierarchy concepts and properties of the GFO.

Figure 5 shows the class hierarchy and the properties of different classes in GFO. An ontology consists of classes, properties between classes, and axioms that restrict these classes. A class defines a concept, while a property between classes indicates a relation holding between two instances of these classes. Based on the terms identified in the ontology, classes and properties among them are determined. The main GFO classes shown in Figure 5 are explained below.

In this research, the product class represents an assembled product composed of components and captures knowledge of its structure. The Product class has an attribute Component—the class property has-Component defined between the product class and the Component class. The Component class represents either a subassembly or a part. The Sub-Assembly class represents a collection of parts assembled together. A subassembly must contain at least two assembled parts. The Part class represents the basic structural design entity used to create a product. The Component class is connected to Sub-Assembly class or Part class via the is-Composed-of class property. The Sub-Assembly class is connected to the part class via the has-part class property. The class properties in the GFO reflect the inheritance relations between concepts and the relations between concepts and their attributes.

In this research, feature as a class represents the basic constituent design entity of a component, and is associated with Component class via the has-Feature class property. The feature class is further specialized into a single-piece part feature (Feature-for-Part) and an assembly feature (Feature-For-Assembly). The first represents the geometrical features of each part in the assembly design, while the second represents the assembly features that connect different parts. The Feature class is associated with Feature-for-Part and Feature-For-Assembly via the is-Feature class property. The Feature-for-Part class is expanded and inherited by the Feature-Based Model—Domain Ontology (FBM-DO); in contrast, the Feature-for-Assembly class is expanded and inherited by the Assembly Model—Domain Ontology (AM-DO) in the second domain ontology layer.

A process is considered as a generic concept that can be defined as “an ordered set of activities with a defined goal” [56]. In this research, the process concept is more closely related to the APP domain. Process, as a class, represents the activities required to convert the product design into a manufactured and/or assembled product. The Process class is connected to the Prdouct class via the Requires-Process property. Process is expanded and inherited by the Process Model—Domain Ontology (PM-DO).

A resource, as a generic concept, is defined by ISO 19115 [74] as “assets or means that fulfill a requirement”. Here, the Resource class represents the required means (equipment and tools) for manufacturing or assembling a product. The concept of resource is more closely related to the APP domain. The Resource class is connected to the Process class via the Uses-Resource class property. The resource is expanded and inherited by the Resource Model—Domain Ontology (RM-DO).

4.2. Ontology Development: Domain Ontology (DO) Layer

The DO layer consists of four domain ontologies (DO). Two of those are in the product design domain, namely the Feature-based Model (FBM-DO) and the Assembly Model (AM-DO), and the other two are in the APP domain, namely the Process Model (AM-DO) and the Resource Model (RM-DO). Each DO reuses concepts and properties from the FGO and defines more specified, expanded, and specialized concepts/properties for a particular domain. The FBM-DO is created to capture knowledge about a product’s form. Figure 6 illustrates the class hierarchy and properties between different classes in FBM-DO.

Figure 6. Class hierarchy concepts and properties of the FBM-DO.

One definition of form feature is “Form features are specific configurations on surfaces, edges, or corners of a part, such as holes, slots, etc., that carry some engineering meaning” [75]. Form feature could be either in singular form or pattern form, where pattern feature (such as hole-pattern) is composed of identical singular form features (such as hole). A singular feature could be either in a primitive elementary form or a compound form, where the compound form is composed of two primitive elementary features in a parent/child relationship. Typical examples of compound form features are stepped holes and a pin with a head. A primitive elementary feature has three forms: volume (cylindrical, cubic, and other shape features), surface, and transition (such as chamfers and fillets).

In the FBM-DO, all kinds of form features have been specified as classes, with properties that connect them. The Pattern-Feature class has several attributes, such as shape and pitch (the distance between centers of successive singular features in a single row in the pattern), as follows:

• Marginal pitch (the distance between the singular feature center and the nearest surface edge);
• Diagonal pitch (the distance between the centers of singular features in adjacent rows of zig-zag singular features);
• Back pitch (the distance between the centers of two successive singular features in the pattern).

Each of the pattern feature parameters is characterized by a value and unit, which are expressed as data type properties, except for the shape parameter, which is characterized by only one data type property: has-Shape-Type.

The Assembly Model Domain Ontology (AM-DO) is designed for assembly modeling within the product design domain. Figure 7 shows the class hierarchy and properties of the AM-DO.

Figure 7. Class hierarchy concepts and properties of the AM-DO.

AM-DO provides a basis for the design unit’s behavior during assembly. AM-DO includes three major classes: Assembly-Feature, Spatial-Relationship, and Degree-Of-Freedom. The Assembly-Feature class is composed of Handling-Feature, Alignment-Feature, Planar-Mating-Feature, and Joining-Feature subclasses. With these four subclasses, the Assembly-Feature class represents assembly design from an assembly modeling perspective (Alignment-Feature and Planar-Mating-Feature) and from an assembly process perspective (Handling-Feature and Joining-Feature). The Alignment-Feature and Planar-Mating-Feature subclasses represent mating features for cylindrical and planar surfaces, respectively, where a mating feature (or condition) is defined in [76] as “relationships that involve contact between parts, as well as relationships in which two parts do not have contact (e.g., clearance conditions!)”. The Handling feature class represents the parts’ geometrical characteristics needed to determine the required assembly transport resources, such as fixtures, feeders, and grippers.

More specialized forms of handling features are derived, such as gripping features represented by the Gripper-Feature subclass, which represents the geometrical characteristics needed to determine the required gripping resources. The Joining—Feature class, with its further specialization subclasses (Fitting-feature, Screwing-feature, etc.), represents the geometrical and non-geometrical knowledge (dimensional tolerance in the case of Fitting-Feature) needed to determine the required joining processes and resources to assemble a product. The Spatial-Relationship class expresses the relative positions of parts in an assembly in their final state, while the Degree-Of-Freedom class is used to describe the motion (translation and rotation) of parts during assembly.

The following two DOs are the Process Model (PM) and the Resource Model (RM) DOs of the APP domain. The PM-DO is illustrated in Figure 8, where the process class in GFO is expanded and inherited into Assembly-Process and Manufacturing-Process classes. The Assembly-Process class is further expanded into the Joining-Process and Handling-Process classes. The Joining-Process class is composed of subclasses representing different joining processes in APP, such as Welding and Screwing. The Handling-Process class is composed of Gripping, Feeding, and Fixturing subclasses.

Figure 8. Class hierarchy concepts and properties of the PM-DO.

The RM-DO represents manufacturing and assembly resources in APP (Figure 9). The Assembly-Resource class is further decomposed into several subclasses, including Enterprise, Factory, Area, Line, Cell, Device-Combination, and Individual-Device. The Individual-Device subclass is further inherited by the Assembly Device Application Ontology (AD-AO) in the AO layer, which will be discussed in the next section.

Figure 9. Class hierarchy concepts and properties of the RM-DO.

4.3. Ontology Development: Application Ontology Layer

The Application Ontology (AO) represents the lowest level of the proposed ontology structure and defines more specific, expanded, and specialized concepts/properties for a particular application. In this paper, two AOs are developed: the SolidWorks-Application Ontology (SW-AO) to model, capture, and share the semantics of the SolidWorks CAD software application, and the Assembly Device (AD-AO) to model, capture, and share the semantics of robotic assembly devices.

Many researchers try to develop an ontological model for CAD knowledge, either for enhancing interoperability between different CAD systems, supporting integration and exchange of knowledge in a collaborative engineering environment [77,78,79], or for enhancing interoperability between different CAD software systems and different applications such as Computer-Aided Manufacturing (CAM) [80]. A third category of researchers seeks to develop ontological model approaches to integrate CAD knowledge with shop-floor devices (such as robotic cells) in manufacturing/assembly systems [81]. The application layer in our proposed ontological structure is under this category, where a more comprehensive approach to developing an ontological model for SolidWorks CAD software and for robotic assembly devices is presented. The SolidWorks Application Ontology (SW-AO) illustrated in Figure 10 comprises six top-level classes that represent the significant components of the SolidWorks CAD software: Simulation, Sketch, Part File, B-rep Entity, Reference Attribute, and Assembly File. The Simulation and Sketch classes are not expanded here, since they are not mainly related to the purpose of integrating assembly design and APP. The other major classes are discussed briefly below.

Figure 10. Class hierarchy concepts and properties of the SW-AO.

The Part-File class represents the SW-CAD part file, in which the feature tree and DimXpert tree are stored. The feature tree is represented by the Features class, a subclass of the Part-File class. The DimXpert tree is represented by the DimXpert-Manager, which is also a subclass of the Part-File class. The Features class includes all different kinds of features, such as Extrude, Fillet, Hole, and Revolve. The Features class represents the geometrical knowledge component of the CAD knowledge, while the DimXpert-Manager class represents the non-geometrical knowledge components, such as dimensions and tolerances, within the CAD knowledge. All different kinds of dimensions are represented under the Dimension subclass, while the two main types of tolerance, dimensional and geometrical, are represented under the Tolerance subclass.

The Features class is decomposed into the B-rep Entity class, which is further decomposed into the fundamental geometrical and topological entities: Geometry-Entity and Topology-Entity. Geometry-Entity has subclasses: Surface, Curve, and Point. The Surface class encompasses various types of surfaces used in geometric modelers; in this research, we are primarily limited to planar and cylindrical surfaces. Different types of cylindrical surfaces are listed under the Cylindrical-Surface subclass of Topology-Entity, which has the following subclasses: Edge, Shell, Loop, Face, and Co-edge.

The Reference-Attribute class defines various reference types as subclasses, including Existing-Part-Reference, Datum-Reference, and Coord-Sys-Reference, which can be used in a feature definition. The Assembly-File class includes the Mates subclass, which represents various mate relation types, including subclasses Coincident, Concentric, Parallel, Perpendicular, and Tangent.

The Assembly Device Application Ontology (AD-AO) (Figure 11) represents robotic assembly devices and comprises the top-level classes Robot, Tool Exchanger, Handling Tools, and Joining Tools. The Robot class encompasses various robots commonly used in robotic assembly devices, including the Scara-Robot, Mobile-Robot, and Hexapod-Robot subclasses. The Handling Tools class includes all tools used for handling and orienting parts during assembly. The Fixturing Tool, Gripping Tool, and Feeding Tool are subclasses of the Handling Tools Class. The Joining Tools class encompasses all tools used for joining parts during assembly, including subclasses such as Screwing Tool, Welding Tool, and Fitting Tool. Examples of specific tools within the Gripping Tool class include the Vacuum Gripper and the Finger Gripper. Properties for these different types of grippers will be defined as Attributes, such as gripping range, gripping power, and force, with associated values and units.

Figure 11. Class hierarchy concepts and properties of the AD-AO.

Figure 5, Figure 6, Figure 7, Figure 8, Figure 9, Figure 10 and Figure 11 aim to provide a detailed picture of the ontology’s class hierarchy and the intra-relations (properties) between classes in each ontology in the framework. For all ontologies, all concepts are defined as classes. All classes inherit from the Thing subclass and are declared disjoint to prevent an individual from being an instance of more than one class, thereby avoiding multiple inheritance. Additionally, a reasoner is used to verify whether one class is a subclass of another within the complete ontology structure. Protégé 5.5.0, which was used to build this ontology, offers two reasoners, Pellet and HermiT 1.3.8. All 7 developed ontologies were tested with both reasoners, and no errors were found.

4.4. Ontology Development: PAPO Integrated Ontology

According to the ontology development plan in Figure 3, the PAPO integrated ontology is developed through three import stages. The first imports the four developed domain ontologies into the GFO to generate a single merged ontology designated GFO-OWL. The second and third import stages import the standalone application ontologies SW-AO and AD-AO, respectively. Defining the interrelationships among the ontologies within the PAPO framework is the second step in developing the PAPO. These relations are summarized in Table 1. Figure 12 illustrates the class hierarchy, property relationships across classes, and the ontologies in different layers of the PAPO multi-layer framework. Data properties are also illustrated.

Table 1. Inter-relations among ontologies in the ontology structure.

Domain	Property	Range
GFO: Resource	has-Assembly-Resource	RM-DO:Assembly-Resource
GFO: Resource	has-Manufacturing-Resource	RM-DO:Manufacturing-Resource
RM-DO:Individual-Device	has-Assembly-Robotic-Device	AD-AO:Assembly-Robotic-Device
GFO: Process	has-Assembly-Process	PM-DO:Assembly-Process
GFO: Process	has-Manufacturing-Process	PM-DO:Manufacturing-Process
AM-DO:Assembly-Feature	is-Feature-For-Assembly	GFO:Feature-For-Assembly
AM-DO:DOF	is-Feature-For-Assembly	GFO:Feature-For-Assembly
AM-DO:Spatial-Relationships	is-Feature-For-Assembly	GFO:Feature-For-Assembly
FBM-DO:Form-Feature	is-Feature-For-Part	GFO: Feature-For-Part
GFO: Part	has-Form-Feature	FBM-DO:Form-Feature
SW-AO:Extrude	is-Volume-Feature	FBM-DO:Volume-Feature
SW-AO:Hole	is-Volume-Feature	FBM-DO:Volume-Feature
SW-AO:Revolve	is-Volume-Feature	FBM-DO:Volume-Feature
SW-AO:Fillet	is-Transition-Feature	FBM-DO:Transition-Feature
SW-AO:Features	is-Primitive-Feature	FBM-DO:Primitive-Feature
SW-AO:Concentric	is-Alignment-Feature	AM-DO:Alignment-Feature
SW-AO:Coincident	is-Planar-Mating-Feature	AM-DO:Planar-Mating-Feature
SW-AO:Parallel	is-Planar-Mating-Feature	AM-DO:Planar-Mating-Feature
SW-AO:Perpendicular	is-Planar-Mating-Feature	AM-DO:Planar-Mating-Feature
SW-AO:Tangent	is-Planar-Mating-Feature	AM-DO:Planar-Mating-Feature

Figure 12. Class hierarchy concepts and properties of the PAPO.

4.5. Ontology Formalism and Utilization

The next step is to add restrictions on the defined OWL classes and properties. OWL classes are defined by their names, properties that can be applied to them, and the types of restrictions placed on those properties. Restrictions on properties are considered necessary for an instance of a class to be valid. OWL can only impose quantifier, cardinality, and hasValue restrictions on properties. The quantifier restrictions that can be used are the existential quantifier (∃), which states that a class must have some values from the restricted property, and the universal quantifier (∀), which states that the class must only have values from the restricted property. The cardinality restrictions are used to specify a minimum (≥), maximum (≤), or exact (=) cardinality, which indicates greater than, less than, or exactly a specific number of instances of a property. However, property restriction does not support variables. The number must be specified explicitly in the restriction definition. The hasValue restriction (∋) allows the restriction of properties that only have a specific individual or data value defined by the property.

The cardinality restriction type has been used extensively in the proposed ontology to restrict properties. For example, the Sub-Assembly class in GFO has been restricted in its property has-Part with cardinality of at least 2 (since any subassembly should at least contain two parts). Other examples of using cardinality in restricting properties in the GFO are listed below:

• has—Component with cardinality of at least 1 (any part is composed of at least a single component);
• is-Composed-of with cardinality of at least 1 (any component is composed of at least a single part or single sub-assembly);
• requires—Process with cardinality of at least 1 (to assemble a product, you need at least one process);
• uses-resource with cardinality of at least 1 (to perform any process, you need at least a single resource);
• has-Form-Feature with cardinality of at least 1 (any part is composed of at least a single form feature).

The restrictions mentioned above, which can define a class in OWL, are limited, as are the types of inferences that can be made with those restrictions. In OWL, it is convenient to describe intra-restrictions, which apply only to a class, such as cardinality restrictions. However, OWL cannot express inter-restrictions, which involve restrictions among or between classes, typically expressed as rule types. This is because OWL cannot describe property chaining [17]. To represent rule knowledge, the W3C (World Wide Web Consortium) developed the SWRL rule language 82, which is tightly integrated with OWL, because SWRL predicates can be OWL classes or properties. Additionally, SWRL enables users to write rules based on OWL concepts, offering more powerful reasoning capabilities than OWL alone. SWRL rules reason about OWL individuals, mainly in terms of OWL classes and properties. They are written as antecedent-consequent pairs, as shown in Figure 13.

Figure 13. SWRL basic principles.

In the SWRL graph in Figure 13, the interaction between two OWL classes with two individuals connected via an OWL property results in an SWRL property that connects the two individuals. The new SWRL property is considered an inferred relation based on the existing OWL relations. Furthermore, the SWRL Built-Ins Library contains mathematical expressions, called Built-Ins, used to evaluate complex expressions in SWRL rules. The SWRLTab in Protégé allows users to write rules that reason about OWL individuals and infer new knowledge. The SWRLTab supports editing and executing SWRL rules. SWRL rules will be developed for case-study examples in the next section.

5. Case-Study Examples

5.1. Three-Button Panel Assembly

Based on the classes and properties modeled in Protégé-OWL, SWRL rules are developed to reason about the processes and resources required to assemble a product based on assembly design details. In this paper, a case study is used to quantitatively and experimentally verify the proposed ontology framework. The case-study model is a three-button panel assembly; its exploded view is shown in Figure 14. The case study consists of seven parts (the base part, the three buttons, the cover, and the screws). Each part has several specifications (dimensions and tolerances) that are populated with the proposed ontology framework.

Figure 14. Exploded view of the three-button panel assembly.

The process plan for the case study is illustrated in Figure 15. For each process in the process plan, the related assembly design semantics are loaded into the ontology as individuals, and the rule engine gives options for the required processes and resources to assemble the case study. To develop SWRL rules that connect assembly design specifications with these processes, we first link assembly processes and resources to the assembly model specifications through the use of assembly features.

Figure 15. Process plan for the three-button panel assembly and the related assembly design semantics.

Each assembly feature will be connected to the related assembly semantics on one side and to the required assembly processes and resources on the other side. The ontological relation models are developed to connect the B-rep modeled surfaces such that the features in SW-AO lead to assembly processes and resources via assembly features. All the features in the assembly design are decomposed into surfaces; in this case, these surfaces are either cylindrical or planar. Handling processes will be performed on the non-mating surfaces under the Part-File in the SW-AO, while joining processes will take place on Mating entities in the Assembly File in SW-AO. Handling processes (fixturing, feeding, and grasping) will take place mainly on the planar surfaces, with handling criteria specified in the process plan.

The handling criteria for the fixturing feature between two surfaces are based on non-mating relations between these two surfaces, as well as non-adjacent and perpendicular or parallel relations between them. Another important issue related to fixturing features is that it occurs only in the base part. Figure 16 illustrates the ontological map of fixturing features and their connections to fixturing processes and resources in the APP domain.

Figure 16. APP perspective for fixturing feature.

Feeding features are based on the bottom planar surfaces for different parts in the assembly (except for the base part). A planar surface with a minimum Y-position is considered the feeding surface for different parts in the assembly.

Grasping features are mainly concerned with the parallel, non-adjacent, and non-mating surfaces for the finger gripping and with the upper top surfaces (surfaces with maximum Y coordinate) for vacuum gripping (for the middle button in the case-study example). Figure 17 illustrates the ontological map and related APP connections for the feeding and gripping features.

Figure 17. APP perspectives for grasping and feeding features.

Joining processes such as fitting and screwing occur on cylindrical and concentric surface pairs. Specifically, a fitting assembly typically takes place between an internal simple cylindrical surface and an external simple cylindrical surface, forming a concentric connection. Similarly, a screwing process occurs between an internal threaded cylindrical surface and an external threaded cylindrical surface, which also have a concentric mating relation. These mating surfaces are connected via fitting or screwing features, which involve the respective processes. The relationships among fitting and screwing features, their associated processes, and resources are depicted in Figure 18.

Figure 18. APP perspectives for fitting and screwing features.

A reasoning procedure for assembly handling is developed and implemented in SWRL rules, as in Table 2:

Table 2. Reasoning procedure and SWRL rules for handling processes.

No	Name	SWRL Rules
1.	Fixturing Feature	BasePart (?x)^ hasPlanarSurface (?x, ?A,?B) ^ hasParallel/perpendicularRelation (?A,?B) ^ hasnonadjacentRelation(?A,?B) ^ Non-matingRelation(? A,?B) → FixtruingFeature(?A,?B)
2.	Fixturing Process	FixtruingFeature (?A,?B) → hasFixtruingProcess(?A,?B)
3.	Fixturing Tool	hasFixtruingProcess(?A,?B) → hasFixture (?A,?B)
4.	Feeding Feature	Part (?x) ^ hasPlanarSurface (?x, ?A,?B, ?C,?D) ^ hasY-Dimension(?A,?Y-A) ^ hasUnit(?Y-A,mm) ^ hasY-Dimension(?A,?Y-A) ^ hasUnit(?Y-B,mm) ^ hasY-Dimension(?A,?Y-A) ^ hasUnit(?Y-C,mm) ^ hasY-Dimension(?A,?Y-D) ^ hasUnit(?Y-D,mm) ^ swrlb:lessThan(?Y-D,?Y-A,?Y-B,?Y-C) → FeedingFeature(?D)
5.	Feeding Process	FeedingFeature (?D) → has FeedingProcess (?D)
6.	Feeding Tool	has FeedingProcess (?D) → hasFeeder (?D)
7.	Finger Gripping Feature	Part (?x) ^ hasPlanarSurface (?x,?A,?B) ^hasParallelRelation (?A,?B) ^hasNonadjacentRelation(?A,?B) ^ hasNon-matingRelation(?A,?B) → FingerGrippingFeature(?A,?B)
8.	Finger Process	FingerGrippingFeature(?A,?B) → has FingerGrippingProcess (?A,?B)
9.	Finger Gripping Tool	has FingerGrippingProcess (?A,?B) → has FingerGripper
10.	Vacuum Gripping Feature	Part (?x) ^ hasPlanarSurface (?x,?A,?B,?C,?D) ^ hasY-Dimension(?A,?Y-A) ^ hasUnit(?Y-A,mm) ^ hasY-Dimension(?A,?Y-A) ^ hasUnit(?Y-B,mm) ^ hasY-Dimension(?A,?Y-A) ^ hasUnit(?Y-C,mm) ^ hasY-Dimension(?A,?Y-D) ^ hasUnit(?Y-D,mm) ^ swrlb:lessThan(?Y-C, ?Y-A, ?Y-B, ?Y-D) → VacuumGrippingFeature(?D)
11.	Vacuum Gripping Process	VacuumGrippingFeature(?D) → VacuumGrippingProcess(?D)
12.	Vacuum Gripping Tool	VacuumGrippingProcess(?D) → VacuumGripper(?D)

A fit is a dimensional relationship between cylindrical mating surfaces. According to the literature:

A.

Clearance fit: A hole (internal simple surface) and a shaft (external simple surface) have a clearance fit with each other if the minimum allowable dimension of a hole is larger than the maximum allowable dimension of a shaft. This can be expressed as:

Min. allowable dimension. Hole > Max. allowable dimension. Shaft

(1)

B.

Transition fit: A hole and a shaft have a transition fit with each other if the minimum allowable dimension of a hole is smaller than the maximum allowable dimension of a shaft, and the maximum allowable dimension of a hole is larger than the minimum allowable dimension of a shaft.

Min. allowable dimension. Hole < Max. allowable dimension. Shaft

(2)

Max. allowable dimension. Hole > mix. allowable dimension. Shaft

(3)

C.

Interference fit: A hole and a shaft have an interference fit with each other if the maximum allowable dimension of a hole is smaller than the minimum allowable dimension of a shaft.

Max. allowable dimension. Hole < mix. allowable dimension. Shaft

(4)

A reasoning procedure for assembly fit and assembly screwing is developed and implemented in SWRL rules in Table 3.

Table 3. Reasoning procedure and SWRL definitions and rules for assembly joining processes (fitting and screwing).

No.	Name	SWRL Definitions
1.	Hole	Surf(?y) ^ hasShapeCylindrical ^ hasTypeInner ^ hasCharacteristicSimple
2.	Shaft	Surf(?x) ^ hasShapeCylindrical ^ hasTypeOuter ^ hasCharacteristicSimple
3.	Threaded Hole	Surf(?y) ^ hasShapeCylindrical ^ hasTypeInner ^ hasCharacteristicThreaded ^ hasThreadM4
4.	Screw	Surf(?x) ^ hasShapeCylindrical ^ hasTypeOuter ^ hasCharacteristicThreaded ^ hasThreadTypeM4
No.	Name	SWRL Rules
1.	Find Max. Allowable Dimension	Surf(?x) ^ hasDimension(?x,?d) ^ hasUpperTol(?x,?d2) ^ hasUnit(?d2,mm) ^ hasLowerTol(?x,?d1) ^ hasUnit(?d1,mm) ^ swrlb:greaterThan(?d2,?d1) ^ swrlb:add(?z,?d,?d2) -> hasMax.AllowableDimension(?x,?z)
2.	Find Min. Allowable Dimension	Surf(?x) ^ hasDimension(?x,?d) ^ hasUpperTol(?x,?d2) ^ hasUnit(?d2,mm) ^ hasLowerTol(?x,?d1) ^ hasUnit(?d1,mm) ^ swrlb:greaterThan(?d2,?d1) ^ swrlb:add(?y,?d,?d1) -> hasMin.AllowableDimension(?x,?y)
3.	Capturing Standard Tolerance Quantities (f7)	Surf(?x) ^ hasShapeCylindrical ^ hasTypeOuter ^ hasCharacteristicSimple ^ hasDimension(?x,?d) ^ hasUnit(?d,mm) ^ swrlb:greaterThan(?d,0) ^ swrlb:lessThan(?d,3) ^ hasLowerTol(?x,-16) ^ hasUpperTol(?x,-6) -> hasDimensionalTolerancef7(?x)
4.	Capturing Standard Tolerance Quantities (H8)	Surf(?y) ^ hasShapeCylindrical ^ hasTypeInner ^ hasCharacteristicSimple ^ hasDimension(?y,?d) ^ hasUnit(?d,mm) ^ swrlb:greaterThan(?d,0) ^ swrlb:lessThan(?d,3) ^ hasLowerTol(?y,0) ^ hasUpperTol(?y,14) -> hasDimensionalToleranceH8(?y)
5.	Find Fit Types	Surf(?x) ^ hasShapeCylindrical ^ hasTypeOuter ^ hasCharacteristicSimple ^ hasDimension(?x,?d1) ^ hasMax.AllowableDimension(?x,?p) ^ Surf(?y) ^ hasShapeCylindrical ^ hasTypeInner ^ hasCharacteristicSimple ^ hasConcentricMateRelationWith(?x,?y) ^ hasDimension(?y,?d2) ^ hasMin.AllowableDimension(?y,?q) ^ swrlb:greaterThan(?q,?p) -> hasClearanceFitWith(?x,?y)
		Surf(?x) ^ hasShapeCylindrical ^ hasTypeOuter ^ hasCharacteristicSimple ^ hasDimension(?x,?d1) ^ hasMin.AllowableDimension(?x,?q) ^ Surf(?y) ^ hasShapeCylindrical ^ hasTypeInner ^ hasCharacteristicSimple ^ hasConcentricMateRelationWith(?x,?y) ^ hasDimension(?y,?d2) ^ hasMax.AllowableDimension(?y,?p) ^ swrlb:greaterThan(?q,?p) -> hasInterferenceFitWith(?x,?y)
		Surf(?x) ^ hasShapeCylindrical ^ hasTypeOuter ^ hasCharacteristicSimple ^ hasDimension(?x,?d1) ^ hasMax.AllowableDimension(?x,?p1) ^ hasMin.AllowableDimension(?x,?q1) ^ Surf(?y) ^ hasShapeCylindrical ^ hasTypeInner ^ hasCharacteristicSimple ^ hasConcentricMateRelationWith(?x,?y) ^ hasDimension(?y,?d2) ^ hasMin.AllowableDimension(?y,?q2) ^ hasMax.AllowableDimension(?y,?p2) ^ swrlb:greaterThan(?p2,?q1) ^ swrlb:lessThan(?q2,?p1) -> hasTransitionFitWith(?x,?y)
6.	Reasoning about Fit Processes	Surf(?x) ^ hasShapeCylindrical ^ hasTypeOuter ^ hasCharacteristicSimple ^ Surf(?y) ^ hasShapeCylindrical ^ hasTypeInner ^ hasCharacteristicSimple ^ hasConcentricMateRelationWith(?x,?y) -> hasFittingFeatureWith(?x,?y)
		hasFittingFeatureWith(?x,?y) ^ hasClearanceFitWith(?x,?y) -> hasFittingShrinkingProcess(?x,?y)
		hasFittingFeatureWith(?x,?y) ^ hasTransitionFitWith(?x,?y) -> hasFittingShrinkingProcess(?x,?y)
		hasFittingFeatureWith(?x,?y) ^ hasInterferenceFitWith(?x,?y) -> hasFittingPressingProcess(?x,?y)
7.	Reasoning about Fit Resources	hasFittingShrinkingProcess(?x,?y) -> hasFittingShrinkingResource(?x,?y)
		hasFittingPressingProcess(?x,?y) -> hasFittingPressingResource(?x,?y)
8.	Reasoning about Screwing Feature	Surf(?x) ^ hasShapeCylindrical ^ hasTypeOuter ^ hasCharacteristicThreaded ^ hasThreadTypeM4 ^ Surf(?y) ^ hasShapeCylindrical ^ hasTypeInner ^ hasCharacteristicThreaded ^ hasThreadM4 ^ hasConcentricMateRelationWith(?x,?y) -> hasScrewingFeatureWith(?x,?y)
9.	Reasoning about Screwing Process	hasScrewingFeatureWith(?x,?y) ^ pmdo:Screwing(?sp) -> hasScrewingProcess(?x,?y)
10.	Reasoning about Screwing Resource	hasScrewingProcess(?x,?y) -> hasScrewingResource(?x,?y)

Table 3 lists the SWRL rules required for reasoning about fitting and screwing processes. In this paper, the ISO tolerance standard BS 4500 [82] is used to specify tolerance quantities. Tolerance standards enable designers to specify tolerance quantities that depend on the dimensions of mating entities in the assembly (such as a hole and a shaft). The tolerance types for the hole start with the capital letter (such as H8, H7, etc.), while tolerance types for the shaft start with the small letter (such as f7, k6, p6, etc.). In this research, our approach is to decompose mating entities into their boundary surfaces. For the fitting mating entities, the hole is expressed as a simple internal cylindrical surface, while the shaft is expressed as a simple external cylindrical surface. For screwing mating entities, the hole is represented as a threaded internal cylindrical surface, while the screw is represented as a threaded external cylindrical surface. Both fitting and screwing entities are expressed in SWRL format at the beginning of the table. The first step in fitting reasoning is to capture the Max. Allowable Dimension and Min. Allowable Dimension according to rules 1 and 2. The third and fourth steps involve capturing the standard tolerance quantities in accordance with the ISO tolerance standard BS 4500 [82]. Table 3 shows only two of the standard tolerance quantities, which are captured based on the dimensions of the fitting mating entities (f7, H8) in steps 3 and 4. All other types of fits are captured in the same way, based on the mating-fitting entities’ dimensions. Fitting types are captured in the fifth step according to the definitions (1–4 in the bulleted list above). The next step (6) is to reason about the required fitting processes based on the fit types (whether a shrinking fitting process is used for the clearance and transition fit, or a pressing fitting process is used for the interference fit). The final step (7) for fitting reasoning involves reasoning about the required fitting resources based on the required fitting processes. Steps 8 to 10 are dedicated to reasoning about the screwing process and its resources. Step 8 is for determining the screwing feature between mating threaded entities. Based on this step-screwing process, the screwing process and screwing resource are determined in steps 9 and 10, respectively.

The first stage of quantitative experimental verification for the proposed ontology framework is to instantiate the ontology with case-study facts and then execute the SWRL rule, which requires a rule-based engine. In this paper, Drools is used to implement this. Drools supports the development of rule-based expert systems. It is considered a candidate for integration with the SWRL editor because it integrates seamlessly with Java, is well-documented, and has an extensive user base [18]. The interaction between OWL and the Drools rule-based engine is performed in the SWRLTab. The process involves transferring the OWL-captured knowledge and SWRL rules to Drools. After inference is performed using this knowledge and rules, the resulting Drools facts are transferred back to Protégé-OWL as new OWL knowledge [83]. The overall integration system is illustrated in Figure 19. The ontology structure represents both the assembly design model and the APP model. The modeling software, Protégé, encodes the assembly design and APP knowledge in OWL. Then, in the built-in SWRLTab, restrictions, constraints, and designer requirements are described in SWRL. After mapping the formalized assembly design, APP knowledge, and constraints onto the facts and rules in the Drools inference system, the engine performs the integration. It generates possible process plans and adaptation results for assembly design.

Figure 19. The overall structure of the Assembly design- APP integration system.

The SWRL rule layer of PAPO comprises 22 rules organized into two groups: 12 handling-process rules (Table 2) and 10 joining-process rules (Table 3). Validation of these rules was conducted by rule Execution via SWRLTab Drools Engine, as illustrated in Figure 20.

Figure 20. SWRLTab Drools Engine for three-button panel Assembly.

The Drools rule engine bridge was activated via the SWRLTab → Drools tab, and rules were executed by clicking Run Drools. Each rule’s consequent was expected to assert new property facts or class memberships for the case study individuals. For example, Rules T3-1 (rule 1 in Table 3) and T3-2 (rule 2 in Table 3) (Dimensional computation) computed the maximum and minimum allowable dimensions for all cylindrical surface individuals, as shown in Figure 21 and Figure 22.

Figure 21. Maximum allowable dimension asserted facts to individual instances.

Figure 22. Minimum allowable dimension asserted facts to individual instances.

Execution of the rules in Table 1 will examine all planar surfaces according to the criteria specified in these rules and assign suitable surfaces to different handling processes. Figure 23 illustrates the planar surfaces asserted facts to the individual instances.

Figure 23. Planar surfaces asserted facts to the individual instances.

The second level of validation for the PAPO framework uses Description Logic (DL) and SPARQL queries. DL queries are executed in Protégé’s DL Query tab after starting the HermiT reasoner, with the Instances checkbox enabled. An example of DL query validation is the query about the Gripping-Tool; all instances related to gripping tools are generated, as illustrated in Figure 24.

Figure 24. Gripping—Tool DL query instances.

Another DL query example is illustrated in Figure 25, a query about Handling-Process subclasses and instances. All different handling processes with instances related to the instant case study are available.

Figure 25. Handling—Process DL query instances.

All DL queries returned the expected instances, demonstrating that the full three-layer class hierarchy, the cross-layer property chains, and all SWRL-inferred individual classifications were logically consistent and correctly integrated into the knowledge base.

Two SPARQL 1.1 queries are formulated and executed in the Protégé SPARQL Query tab to validate instance-level property chains (surface geometry—inferred process types—selected resources). This cannot be done with DL queries, which only verify class membership counts. SPARQL queries verify the existence and correctness of specific property assertion chains for named individuals. The first SPARQL query (Q1) traces the complete three-step inference chain for each of the six operation types—from geometric surface feature through process individual to robotic resource individual—confirming that no operation type was missing or duplicated in the generated assembly plan. The code for Q1 is illustrated in Figure 26, and a part of its output is illustrated in Figure 27.

Figure 26. SPARQL query (Q1).

Figure 27. SPARQL query (Q1) output.

Q2 (Figure 28) proved the dimensional reasoning embedded in rules T3 -1 and T3-2, verifying that the computed maximum shaft dimension (7.987 mm) is strictly less than the computed minimum hole dimension (8.0 mm) for all three button peg–hole pairs, correctly classifying each as a clearance fit per ISO standard [82] f7/H8. The output of Q2 is illustrated in Figure 29.

Figure 28. SPARQL query (Q2).

Figure 29. SPARQL query (Q2) output.

A complete validation procedure is performed on the PAPO framework. Structural consistency validation is performed for all developed ontologies and for the overall integrated PAPO using the HermiT reasoner, which performs a full consistency check over PAPO and all its imported modules. SWRL rule execution validation is performed using the Drools rule engine. Query validation is performed at two levels: at the instance level for classes using a DL query, and at the instance level for property chains using a SPARQL query. This full validation procedure confirms the structural, taxonomic, and instance-level correctness of the PAPO across all three ontology layers.

5.2. Pneumatic Cylinder Assembly (ISO 15552)

To demonstrate PAPO’s applicability in an industrial context, a standards-compliant pneumatic cylinder was selected as the second industrial case study. The chosen industrial case study is a double-acting cylinder (Figure 30) that complies with ISO 15552 [84], the international standard defining the basic, mounting, and accessory dimensions for the 1000 kPa (10 bar) series of cylinders with bores from 32 mm to 320 mm. This cylinder is representative of a widely deployed class of industrial actuators, such as the Festo DSBC-series—ISO 1552 [85], the Festo DNC series—ISO 15552 [86], and the Festo DSBG series—ISO 15552 [87]. The industrial case study is modeled as an 80 mm bore and a 100 mm stroke, with a shouldered piston-rod thread of M20 × 1.5 (KK) and a tie-rod pattern conforming to the ISO 15552 basic-dimension table [84].

Figure 30. Pneumatic cylinder (ISO 15552).

The industrial case study, as illustrated in Figure 31, is composed of a well-defined set of parts (cap end, barrel, piston, piston rod, gland, tie rods, and counter nuts). It combines several distinct fit and joining types (clearance fits, threaded connections, and pre-installed elastic seals), and its geometry is fully governed by published dimensional standards. These properties make it an appropriate real-world benchmark for evaluating whether PAPO can infer a complete and physically valid assembly process plan directly from standardized product geometry.

Figure 31. Pneumatic cylinder (ISO 15552) assembly parts.

The product specifications and standards for the Pneumatic cylinder (ISO 15552) assembly are listed in Table 4, and the parts list and their specifications are listed in Table 5.

Table 4. General specifications of the pneumatic cylinder (ISO 15552) assembly.

Parameter	Specification
Product	ISO 15552 pneumatic cylinder, bore AL = 80 mm, stroke S = 100 mm (ISO 4393), max. pressure 1000 kPa (10 bar).
Standards	ISO 15552:2018 (basic dimensions, Table 2, AL = 80 mm) [84]; ISO 4393:1978 (preferred stroke series) [88]; ISO 4395 (piston rod end) [89]; ISO 273 (clearance holes) [90]; ISO 3320 (bore/rod diameters) [91].
Assumption	Elastic seals are pre-assembled on the piston (P4).

Table 5. Parts list of the pneumatic cylinder assembly.

Part ID	Part Name	Key Dimensions (ISO 15552 [88], Table 2, AL = 80 mm)	Role
P1	Cap end (base)	Square flange, 105 mm; 4 × M10 tie-rod holes (72 × 72 mm pattern); G3/8” port; A = 40 mm; E = 105 mm	Base part/fixture part
P2	Gland (head end)	Square flange; rod bore Ø22 mm (d11); seal groove (pre-loaded); G3/8” port; BG = 45 mm; l2 = 35 mm	Head-end cap
P3	Barrel (cylinder tube)	Ø80 mm bore; Ø~90 mm OD; L ≈ 228 mm (100 mm stroke)	Pressure vessel
P4	Piston (with seals)	Ø80 mm OD; seal grooves pre-fitted; M20 × 1.5 central thread	Pre-assembled subassembly
P5	Piston rod (main)	Ø22 mm (d11); M20 × 1.5 end thread; L exposed ≈ 153 mm; SW = 13 mm	Output rod
P6 (x4)	Tie rods	Ø10 mm; L ≈ 262 mm; M8 × 1.5 threaded both ends; pattern 72 × 72 mm	Structural clamping
P7 (x8)	Counter nuts	M10 × 1.5 hex nut; SW = 17 mm; 8 total (4 per side)	Tie-rod locking

The process plan for the pneumatic cylinder (ISO 15552) case study is shown in Figure 32. For each process in the plan, the corresponding assembly design semantics are loaded into the ontology as individuals, and the rule engine then provides options for the required processes and resources to assemble the case study. However, before instantiating the PAPO with the assembly design semantics of the pneumatic cylinder (ISO 15552) case study, the ontology classes and the SWRL inference rules must be extended to support the new case study.

Figure 32. Process plan for the pneumatic cylinder (ISO 15552) assembly and the related assembly design semantics.

As illustrated in Figure 31, detailed in Table 5, and shown in the APP in Figure 32, P4 consists of the piston and its seals (the blue rings visible on the piston are rubber/elastomeric lip seals and O-rings) and is considered a preassembled subassembly. PAPO’s current rules cannot model the assembly of elastic components. Seals are assembled by stretching them over the piston and compressing them into the grooves—a fundamentally different joining process from fitting or screwing; this can be considered a future extension of PAPO’s rules. Some other rules of PAPO’s ontology will be extended to accommodate cylindrical surfaces for feeding and gripping processes. The required extensions for PAPO’s classes and SWRL engine rules are listed and explained in the following tables. Table 6 documents all additions to the PAPO OWL class hierarchy; Table 7 documents conditions that identify cylindrical part surfaces that require the new handling rules; and Table 8 documents the extended SWRL rule set required for cylindrical part handling for an ISO 15552 pneumatic cylinder. Six new rules extend Table 2 (reasoning procedure and SWRL rules for handling processes for three-button panel assembly) (T2-Rules 1–12). Rules 13–15 are implemented for the ISO 15552 pneumatic cylinder; Rules 16–18 are proposed as future work.

Table 6. New OWL Classes and Data Properties—ISO 15552 pneumatic cylinder extension.

No.	Class/Property Name	Ontology Layer	Description and Scope
1.	CylindricalShaftGrippingFeature	SW-AO	New assembly feature class (subClassOf GFO:Feature) that identifies the outer cylindrical surface of a long rod as the active gripping surface. Required for ISO 15552 pneumatic cylinder P6 tie rods (Ø10 mm × 262 mm), where the shaft OD is gripped by a parallel-jaw finger gripper rather than a planar face.
2.	VibratoryBowlFeedingProcess	PM-DO	New handling process class (subClassOf pmdo:Feeding). Represents the vibratory bowl orientation and feeding process for purely round parts that lack planar end faces. Future work—not instantiated in ISO 15552 pneumatic cylinder (P5 and P6 both have flat annular end faces usable for standard feeding).
3.	VibratorFeeder	AD-AO	New assembly device class (subClassOf adao:Feeding-Tool). Represents a vibratory bowl feeder. Selected as the resource when CylindricalFeedingFeature is detected. Future work—counterpart to VibratoryBowlFeedingProcess.
4.	hasOuterCylindricalType (data property)	PAPO (master)	Boolean data property asserted on Part individuals whose primary handling surface is the outer cylindrical shaft (not a planar face). A value of true triggers T2-Rule 13.
5.	isPurelyRound (data property)	PAPO (master)	Boolean data property asserted on Part individuals that have zero planar surfaces whatsoever. Value = true triggers T2-Rule 16 (vibratory bowl feeding).

Table 7. SWRL Definitions—Cylindrical Part Types—ISO 15552 pneumatic cylinder extension.

No.	Name	SWRL Definitions
1.	Cylindrical Shaft (outer, simple, gripping surface)	Part(?x) ∧ hasOuterCylindricalType(?x, true) ∧ hasCylindricalSurface(?x, ?S) ∧ Surf(?S) ∧ hasShapeCylindrical ∧ hasTypeOuter ∧ hasCharacteristicSimple
2.	Purely Round Part (outer, simple, no planar faces)	Part(?x) ∧ isPurelyRound(?x, true) ∧ hasCylindricalSurface(?x, ?S) ∧ Surf(?S) ∧ hasShapeCylindrical ∧ hasTypeOuter ∧ hasCharacteristicSimple

Table 8. SWRL Inference Rules—Cylindrical Part Handling (T2-Rules 13–18)—ISO 15552 pneumatic cylinder extension.

No.	Name	SWRL Rules
Cylindrical Shaft Gripping (T2-Rules 13–15): Required for CS3 tie rods (P6). T2-Rule 7 cannot fire on cylindrical surfaces; these rules bridge the gap.
13.	Cylindrical Shaft Gripping Feature	Part(?x) ∧ hasOuterCylindricalType(?x, true) ∧ hasCylindricalSurface(?x, ?S) ∧ Surf(?S) ∧ hasShapeCylindrical ∧ hasTypeOuter ∧ hasCharacteristicSimple → CylindricalShaftGrippingFeature(?S)
14.	Cylindrical Shaft Gripping Process	CylindricalShaftGrippingFeature(?S) ∧ pmdo:Gripping(?gp) → hasFingerGrippingProcess(?S, ?gp)
15.	Cylindrical Shaft Gripping Tool	hasFingerGrippingProcess(?S, ?gp) ∧ adao:Finger-Gripper(?fg) → hasFingerGripper(?S, ?fg)
Cylindrical Feeding/Vibratory Bowl (T2-Rules 16–18): Future work for purely round parts with no planar faces. Not required for ISO 15552 pneumatic cylinder (P5 and P6 both have flat annular end faces that trigger existing T2-Rule 4 for feeding).
16.	Cylindrical Feeding Feature	Part(?x) ∧ isPurelyRound(?x, true) ∧ hasCylindricalSurface(?x, ?S) ∧ Surf(?S) ∧ hasShapeCylindrical ∧ hasTypeOuter ∧ hasCharacteristicSimple → CylindricalFeedingFeature(?S)
17.	Cylindrical Feeding Process	CylindricalFeedingFeature(?S) ∧ pmdo:VibratoryBowlFeedingProcess(?fp) → hasFeedingProcess(?S, ?fp)
18.	Cylindrical Feeding Tool	hasFeedingProcess(?S, ?fp) ∧ adao:VibratorFeeder(?vf) → hasFeeder(?S, ?vf)

Table 9 and Table 10 extend the SWRL definitions and inference rules from Table 3 to assembly-joining processes (fitting and screwing) required to assemble the ISO 15552 pneumatic cylinder. In Table 9, four new rows (5–8) are added to the SWRL Definitions in Table 3 to cover the M10 and M20 × 1.5 thread pairs present in the ISO 15552 pneumatic cylinder. In Table 10, three new sub-rules are added: Rule 3a extends tolerance capture to d11 at Ø22 mm; Rules 4a–4b extend H7 capture to the Ø22 mm and Ø80 mm diameter ranges; and Rules 8a–8b extend screwing feature detection to the M10 and M20 × 1.5 thread pairs. Rules 1–2, 5–7, and 9–10 from Table 3 are dimension- and thread-size-agnostic; they require no modification and cover all ISO 15552 pneumatic cylinder extensions for fitting and screwing operations without change.

Table 9. SWRL definitions for assembly joining processes (fitting and screwing)—ISO 15552 pneumatic cylinder extension.

No.	Name	SWRL Definitions
Rows 1–4 below are unchanged from Table 3. Rows 5–8 are new additions required for ISO 15552 pneumatic cylinder extension to introduce M10 tie-rod threads (P6 ↔ P7) and M20 × 1.5 piston-rod threads (P5 ↔ P4).
1.	Hole	Surf(?y) ∧ hasShapeCylindrical ∧ hasTypeInner ∧ hasCharacteristicSimple
2.	Shaft	Surf(?x) ∧ hasShapeCylindrical ∧ hasTypeOuter ∧ hasCharacteristicSimple
3.	Threaded Hole (M4)	Surf(?y) ∧ hasShapeCylindrical ∧ hasTypeInner ∧ hasCharacteristicThreaded ∧ hasThreadM4
4.	Screw (M4)	Surf(?x) ∧ hasShapeCylindrical ∧ hasTypeOuter ∧ hasCharacteristicThreaded ∧ hasThreadTypeM4
5.	Threaded Hole (M10)	Surf(?y) ∧ hasShapeCylindrical ∧ hasTypeInner ∧ hasCharacteristicThreaded ∧ hasThreadM10
6.	Screw (M10)	Surf(?x) ∧ hasShapeCylindrical ∧ hasTypeOuter ∧ hasCharacteristicThreaded ∧ hasThreadTypeM10
7.	Threaded Hole (M20 × 1.5)	Surf(?y) ∧ hasShapeCylindrical ∧ hasTypeInner ∧ hasCharacteristicThreaded ∧ hasThreadM20×1p5
8.	Screw (M20 × 1.5)	Surf(?x) ∧ hasShapeCylindrical ∧ hasTypeOuter ∧ hasCharacteristicThreaded ∧ hasThreadTypeM20×1p5

Table 10. Reasoning procedure for assembly joining processes (fitting and screwing)—ISO 15552 pneumatic cylinder extension.

No.	Name	SWRL Rules
Rules 1–2, 5–7, and 9–10 in Table 3 are fully generic (dimension- and thread-size-agnostic). They require no modification for the ISO 15552 pneumatic cylinder and are therefore omitted here. Only Rules 3–4 (tolerance capture) and Rule 8 (screwing feature) require new sub-rules for the ISO 15552 pneumatic cylinder.
Rules 1–2 (Find Max./Min. Allowable Dimension)—No Change is required
These rules are fully generic: they fire on any cylindrical surface individually regardless of nominal diameter or thread size. They compute max. and min. allowable dimensions from hasUpperTol and hasLowerTol data properties for all fitting pairs in ISO 15552 pneumatic cylinder.
Rules 3–4 (Capturing Standard Tolerance Quantities)—Extension is required for ISO 15552 pneumatic cylinder
Current Rules 3 (f7) and 4 (H8) cover only the diameter range 0 < d ≤ 3 mm (first case study-button-peg fits). ISO 15552 pneumatic cylinder introduces two additional toleranced diameter ranges: 18 < d ≤ 30 mm for the piston rod Ø22 mm d11 (P5) and gland bore Ø22 mm H7 (P2), and 50 < d < 80 mm for the cap-end bore Ø80 mm H7 (P1) and barrel OD (Outer Diameter) fit. Deviation values (in µm) follow ISO 286-1:2010 [92].
3a.	Capturing Standard Tolerance Quantities (d11)—Ø18–30 mm	Surf(?x) ∧ hasShapeCylindrical ∧ hasTypeOuter ∧ hasCharacteristicSimple ∧ hasDimension(?x,?d) ∧ hasUnit(?d,mm) ∧ swrlb:greaterThan(?d,18) ∧ swrlb:lessThan(?d,30) ∧ hasLowerTol(?x,-195) ∧ hasUpperTol(?x,-65) → hasDimensionalToleranced11(?x)
Applies to piston rod P5 (Ø22 mm d11): ISO 286-1 for 18 < d ≤ 30 mm, d11: es = −65 µm, ei = −195 µm. Follows the same pattern as Rule 3 (f7) for 0 < d ≤ 3 mm.
4a.	Capturing Standard Tolerance Quantities (H7)—Ø18–30 mm	Surf(?y) ∧ hasShapeCylindrical ∧ hasTypeInner ∧ hasCharacteristicSimple ∧ hasDimension(?y,?d) ∧ hasUnit(?d,mm) ∧ swrlb:greaterThan(?d,18) ∧ swrlb:lessThan(?d,30) ∧ hasLowerTol(?y,0) ∧ hasUpperTol(?y,21) → hasDimensionalToleranceH7(?y)
Applies to gland rod bore P2 (Ø22 mm H7): ISO 286-1 for 18 < d ≤ 30 mm, H7: EI = 0 µm, ES = +21 µm.
4b.	Capturing Standard Tolerance Quantities (H7)—Ø50–80 mm	Surf(?y) ∧ hasShapeCylindrical ∧ hasTypeInner ∧ hasCharacteristicSimple ∧ hasDimension(?y,?d) ∧ hasUnit(?d,mm) ∧ swrlb:greaterThan(?d,50) ∧ swrlb:lessThan(?d,80) ∧ hasLowerTol(?y,0) ∧ hasUpperTol(?y,30) → hasDimensionalToleranceH7(?y)
Applies to cap-end bore P1 (Ø80 mm H7): ISO 286-1 for 50 < d ≤ 80 mm, H7: EI = 0 µm, ES = +30 µm.
Rules 5–7 (Find Fit Types, Fit Processes, Fit Resources)—No Change is required
Rule 5 (fit type classification) applies to hasClearanceFitWith/hasInterferenceFitWith/hasTransitionFitWith, which are derived from the max./min. allowable dimensions computed by Rules 1–2. No thread-size or diameter-range condition appears in Rules 5–7, so all three ISO 15552 pneumatic cylinder fitting pairs (P5 ↔ P2, P3 ↔ P1, P6 ↔ P1/P2 holes) are handled without modification.
Rule 8 (Reasoning about Screwing Feature)—Extension is required for ISO 15552 pneumatic cylinder
Current Rule 8 fires only when hasThreadTypeM4 (external) and hasThreadM4 (internal) are both present. ISO 15552 pneumatic cylinder introduces two thread pairs that are new: M20 × 1.5 for rod-to-piston screwing (P5 ext. ↔ P4 int.), and M10 for counter-nut-to-tie-rod screwing (P7 int. ↔ P6 ext.). Rules 8a and 8b add these pairs; the consequent hasScrewingFeatureWith(?x,?y) is identical to Rule 8, so Rules 9–10 (Screwing Process and Resource) fire automatically without any change.
8a.	Reasoning about Screwing Feature (M10)	Surf(?x) ∧ hasShapeCylindrical ∧ hasTypeOuter ∧ hasCharacteristicThreaded ∧ hasThreadTypeM10 ∧ Surf(?y) ∧ hasShapeCylindrical ∧ hasTypeInner ∧ hasCharacteristicThreaded ∧ hasThreadM10 ∧ hasConcentricMateRelationWith(?x,?y) → hasScrewingFeatureWith(?x,?y)
Applies to P6 tie-rod OD (M10 ext.) ↔ P7 counter-nut ID (M10 int.)
8b.	Reasoning about Screwing Feature (M20 × 1.5)	Surf(?x) ∧ hasShapeCylindrical ∧ hasTypeOuter ∧ hasCharacteristicThreaded ∧ hasThreadTypeM20×1p5 ∧ Surf(?y) ∧ hasShapeCylindrical ∧ hasTypeInner ∧ hasCharacteristicThreaded ∧ hasThreadM20x1p5 ∧ hasConcentricMateRelationWith(?x,?y) → hasScrewingFeatureWith(?x,?y)
Applies to P5 piston-rod OD (M20 × 1.5 ext.) ↔ P4 piston ID (M20 × 1.5 int.)
Rules 9–10 (Screwing Process, Screwing Resource)—No Change is required
Both rules fire on hasScrewingFeatureWith(?x,?y), which is now asserted by Rules 8, 8a, and 8b. No thread-size condition appears in Rules 9–10, so they cover M4, M10, and M20 × 1.5 automatically. Rule 9 (Screwing Process) and Rule 10 (Screwing Resource) fire on hasScrewingFeatureWith without change.

Quantitative experimental validation of the ISO 15552 pneumatic cylinder is conducted. The first stage of quantitative experimental verification for the proposed ontology framework is to instantiate the ontology with case-study facts and then execute the SWRL rules using the Drools rule-based engine. Rule-based knowledge inference was executed using all 25 SWRL rules—the 22 core rules validated in the first case study, extended by three second case study-specific rules (T2-Rule13 for cylindrical shaft gripping detection, and generalizations of T3-Rules 3a, 4a, and 4b to cover the four new ISO 286-1 [92] tolerance classes)—through the SWRLTab/Drools engine (Protegé 5.5.0, SWRLtab-plugin 2.0.11). The OWL + SWRL transfer stage exported 5073 axioms to the rule engine; Drools successfully inferred 2196 axioms in 273 ms, as shown in Figure 33.

Figure 33. SWRLTab Drools Engine for ISO 15552 pneumatic cylinder.

The Drools rule engine bridge was activated via the SWRLTab → Drools tab, and rules were executed by clicking Run Drools. Each rule’s consequent was expected to assert new property facts or class memberships for the case study individuals. For example, Rules T3-1 (Rule 1 in Table 3) and T3-2 (Rule 2 in Table 3) (Dimensional computation), which are applied without any change for ISO 15552 pneumatic cylinders, computed the maximum and minimum allowable dimensions for all cylindrical surface individuals, as shown in Figure 34 and Figure 35.

Figure 34. Maximum allowable dimension asserted facts to individual instances—ISO 15552 pneumatic cylinder.

Figure 35. Minimum allowable dimension asserted facts to individual instances—ISO 15552 pneumatic cylinder.

Execution of the rules in Table 9 will examine all cylindrical surfaces according to the criteria specified in these rules and assign suitable surfaces to different joining processes. Figure 36 illustrates the cylindrical surfaces asserted facts to the individual instances.

Figure 36. Cylindrical surfaces asserted facts to the individual instances—ISO 15552 pneumatic cylinder.

The second level of validation for the PAPO framework uses Description Logic (DL) and SPARQL queries. DL queries are executed in Protégé’s DL Query tab after starting the HermiT reasoner with the Instances checkbox enabled. An example of DL query validation is the query about handling processes; all instances related to handling processes are generated, as illustrated in Figure 37. The DL query returned the expected instances.

Figure 37. Handling—Processes DL query instances—ISO 15552 pneumatic cylinder.

The populated ontology was validated using SPARQL queries (Q1 and Q2) executed against the HermiT-classified knowledge base in Protégé 5.5.0. SPARQL Q1 returned 21 distinct feature-to-tool rows covering all six operation categories: 2 fixturing chains from the cap-end perpendicular side faces, 6 feeding chains (one minimum-Y face per part P2–P7), 6 finger-gripping chains from the parallel non-adjacent non-mating planar surfaces of the gland, barrel, tie rods, and counter nuts, 2 vacuum-gripping chains from the flat top faces of the piston and piston rod, 3 clearance-fit chains from the three shaft individuals (piston rod, barrel OD, and tie rod shaft), and 2 screwing chains from the M20 × 1.5 and M10 threaded surface pairs—confirming that no operation type was missing or duplicated in the generated assembly plan. SPARQL Q1, tracing the complete three-layer feature → process → resource chain, returned an identical 21 rows, independently confirming the property assertion chains for every named surface individual. The code for Q1 is shown in Figure 38, and its output is shown in Figure 39.

Figure 38. Q1 Code-ISO 15552 pneumatic cylinder.

Figure 39. Q1 Output-ISO 15552 pneumatic cylinder.

SPARQL Q2 returned 10 clearance-fit rows across three geometrically distinct shaft–hole pairs. The code for Q1 is shown in Figure 40, and its output is shown in Figure 41.

Figure 40. Q2 Code-ISO 15552 pneumatic cylinder.

Figure 41. Q2 Output-ISO 15552 pneumatic cylinder.

Query validation is performed at two levels: at the instance level for classes using a DL query, and at the instance level for property chains using a SPARQL query. This full validation procedure confirms the structural, taxonomic, and instance-level correctness of the PAPO across all three ontology layers for ISO 15552 pneumatic cylinder.

6. Discussion

Table 11 presents the complete SWRL/Drools execution profiles for both case studies (CSs), measured directly from the Protégé 5.5.0 SWRLTab console output, alongside the corresponding inference-completeness results from the DL query and SPARQL verification reported in the previous section. Quantitatively, the ontology scales from 73 named individuals and 18 SWRL rules in CS1 (three-button panel) to 200 named individuals and 25 rules in CS2 (ISO 15552 pneumatic cylinder), a 2.7-fold increase in ABox size achieved with only four new TBox tolerance subclasses (Clearance-Fit-Tolerance-d11, -H7, -h6, -h8) and three new rule extensions (T2-Rule13 for cylindrical shaft gripping, and the generalization of the existing screwing-feature rule from a single M4 thread pair to the M10 and M20 × 1.5 threads specified by ISO 15552 Table 2). None of the 22 core SWRL rules validated in CS1 required modification to support CS3, indicating that the inference architecture generalizes across assembly domains without rule re-engineering. This scaling is reflected proportionally in every transfer-stage metric: total OWL axioms exported to the rule engine grew from 1599 (CS1) to 5073 (CS2), individual declarations from 105 to 136, and the feature-to-tool inference chains verified via SPARQL Query 1 for both case studies grew from 13 to 21 rows, while the shared TBox layers (191 classes, 134 object properties, 120 data properties) remained identical across both studies, confirming that the observed growth is attributable entirely to case-study-specific content rather than instability in the underlying ontology.

Table 11. SWRL/Drools execution metrics: CS1 (Three-Button Panel) vs. CS2 (ISO 15552:2018 Pneumatic Cylinder).

Metric	CS1 (Three-Button Panel)	CS3 (ISO 15552 Cylinder)	Basis
A. Knowledge Base Transfer (OWL + SWRL → Drools)—MEASURED for both
SWRL rules exported	18	25	Console-reported, both case studies
OWL class declarations exported	191	191	Console-reported (shared TBox)
OWL individual declarations exported	105	136	Console-reported
OWL object property declarations exported	134	134	Console-reported (shared TBox)
OWL data property declarations exported	120	120	Console-reported (shared TBox)
Total OWL axioms exported to rule engine	1599	5073	Console-reported
Knowledge transfer time (OWL + SWRL → Drools)	378 ms	2845 ms	Console-reported
B. Inferred Knowledge Transfer Back (Drools → OWL)—MEASURED for both
Drools → OWL transfer time	285 ms	389 ms	Console-reported
C. Case-Study Scale Indicators—MEASURED for both (DL query/SPARQL verified)
Case-study part types	7	7	Equal structural depth
Case-study named individuals (ABox)	73	200	OWL NamedIndividual count
Feature-to-tool chains (SPARQL Q1 rows)	13	21	SPARQL query result count
Cylindrical surfaces (T3-Rule1/2 inputs)	10	19	DL query: Cylindrical-Surface instances
Core SWRL rules requiring modification for CS2	—	0 of 22	All CS1 rules reused unchanged in CS2

The experimental validation reported in this paper is constrained by the capabilities of the available robotic assembly cell (i.e., a high-speed assembly robot, the Sony SRX series), which provides grasping (finger and vacuum gripping), feeding, fixturing, fitting, and screwing. Assembly processes requiring welding, adhesive bonding, or elastic-seal compression are outside this capability set and, accordingly, fall outside the scope of automatic SWRL inference in both case studies. This boundary is stated explicitly in the second case study (CS2). CS2’s piston-to-barrel insertion involves seal-compression interference that PAPO’s current T3-Rule 5b cannot compute from rigid-body geometry alone. This limitation is documented as an open limitation of the PAPO.

CS2 is chosen specifically because every process it requires—fixturing, feeding, finger and vacuum gripping, clearance fitting, and screwing—falls within the validated robotic cell’s capabilities, which is precisely what allows the SPARQL-verified inference chain to be read as evidence of deployable, not merely theoretical, process planning. CS1 is the standard case-study assembly for the robotic assembly cell (i.e., a high-speed assembly robot, the Sony SRX series) that comes with the robotic cell to demonstrate its assembly capabilities. CS1 demonstrates that the PAPO inference chain functions correctly on a representative assembly. CS2 adds three properties that CS1, by itself, could not establish, to insure industrial applicability of the PAPO. First propriety, ISO standard governess. Every CS2 process maps to a named, citable ISO standard: bore and stroke dimensions to ISO 15552:2018 [84]. Table 2 and ISO 4393:1978’s [88] preferred stroke series, the piston-rod thread to ISO 4395 [89], tie-rod clearance holes to ISO 273 [90], to ISO 3320:2013 [91] for cylinder bores and piston rod diameters and area ratios, and all four fit tolerance classes (d11, H7, h6, h8) to ISO 286-1:2010 [92]. It is easy to check PAPO-Inferred APP against manual process plans reported by ISO 15552-compliant [84].

The second property is multi-feature part interaction. In CS1, each part participates in a single mating relationship. In CS3, the barrel (P3) participates in two independent fitting pairs simultaneously—its OD (Outer Diameter) mates with the cap end bore, while its bore receives the piston—and the gland (P2) requires two concurrent fits that must be resolved together (rod-to-gland clearance and gland-to-barrel locating fit). PAPO correctly derives both fitting features per part, a realistic requirement for industrial components that CS1 alone does not support. The third property is scalable fastener reasoning. CS3 includes eight tie-rod clearance fits and eight nut-tightening processes, each correctly inferred from a single TieRod_Thread_M10 and CounterNut_Thread_M10 surface-individual pair. The cross-pattern torque sequence (1 → 3 → 2 → 4, 35–40 N·m, SW = 17 mm) is captured as queryable ontology metadata rather than hard-coded per fastener. This demonstrates that the rule architecture does not require one rule instance per physical fastener—a property essential for industrial parts with patterned fastener arrays (flanges, bolt circles), which are common in real assemblies but absent from CS1’s button-panel geometry.

The scientific contribution of PAPO is best characterized not as an ontology interoperability framework but as an inference engine for assembly process planning built on an interoperability substrate. PAPO supports interoperability across all layers of the ontology framework. The seven ontology layers—GFO, FBM-DO, AM-DO, PM-DO, RM-DO, SW-AO, and AD-AO—constitute the vocabulary: a consistent, cross-domain representation of product geometry, assembly features, processes, and robotic resources, whose shared class hierarchy is a necessary precondition for reasoning, not the reasoning itself. The 25 SWRL rules constitute the engineering knowledge encoded in that vocabulary: explicit, auditable antecedent–consequent statements that fire when a surface satisfies a geometric condition (e.g., a planar face at the minimum Y-coordinate, a cylindrical shaft whose computed maximum dimension is strictly less than the computed minimum hole dimension of its mating bore) and derive a new, previously unasserted fact about what that surface requires in assembly. The output of the combined system is the three-layer Feature → Process → Tool inference chain: from unannotated SolidWorks B-rep geometry, PAPO automatically identifies the assembly feature class presented by each surface (fixturing, feeding, finger gripping, vacuum gripping, cylindrical shaft gripping, clearance fitting, or screwing), assigns the corresponding process individual from PM-DO, and selects the physical robotic resource from AD-AO—producing, with no manual process-planning step, a complete, tool-specific, ISO-standard-traceable assembly plan. In CS1, this chain produced 13 verified feature-to-tool assignments across a 7-part electronic panel; in CS3, it produced 21 assignments across a structurally unrelated 7-part ISO 15552 pneumatic cylinder spanning four ISO 286-1 [92] tolerance classes, three geometrically distinct fit-pair types, and two threaded fastener specifications (M20 × 1.5 and M10), without modification to any of the 22 core rules. This end-to-end, geometry-to-resource derivation—executed by a rule engine, validated by direct SPARQL query, and measured by Drools console output—is the property that distinguishes PAPO from the ontology-based frameworks reviewed in Section 2. Table 12 maps each of those frameworks against PAPO on five dimensions, making the distinction concrete.

Table 12. Comparative analysis of PAPO against the ontology-based product-design/manufacturing integration frameworks reviewed in Section 2.

Framework (Citation)	Primary Focus	Reasoning Mechanism	Limitation Relative to PAPO	PAPO’s Corresponding Capability
MASON [27]; Machining Ontology [28]; CDM-Core [34]; ISA-95 Modular Ontology [31]	Manufacturing process and resource knowledge (entities/operations/resources; form features + machining processes)	Class taxonomy; Ref. [31] adds SWRL for ISA-95 hierarchy/operation/resource exchange	Unbalanced: product design treated as a secondary input; no dedicated assembly-feature or tolerance-fit modeling	Fully balanced product design and APP representation with dedicated modules for geometric features, dimensional tolerances, assembly constraints, process types, and robotic device specifications
SIMPM [32]; MCPS Resource Reconfiguration [33]; MR_Onto/MR_Meta [29]	Process-plan generation and resource matching in distributed/cloud manufacturing	OWL2 + SWRL ([32]) matches design specs (geometry, tolerances) to resource capabilities	Matching logic is general-purpose (variety/time/aggregation constraints); no assembly-specific feature taxonomy (fixturing, feeding, gripping, fitting, screwing) or CAD-native geometry extraction	Direct extraction of assembly features from native CAD B-rep geometry (SW-AO), feeding a six-category assembly-process taxonomy absent from these frameworks
SMIF [5] (Chungoora & Young)	Cross-domain semantic interoperability between product design and manufacturing	Verification mediator; query-based fact reconciliation across domain ontologies	Purely an interoperability/reconciliation layer; no rule-based inference engine that derives new process or resource knowledge from design data	Interoperability is a substrate, not the end goal: SWRL rules executed via Drools actively infer new process-plan facts (features → processes → resources), not merely reconcile existing ones
ManuService [43]; MaRCO [48]	Cloud-manufacturing service/resource description and capability matching	Feature hierarchy (Project/Product/Item/Feature/…/Workplan); vendor-neutral resource capability description	Focus restricted to machining features (milling, turning, hole-making); explicitly lack an assembly-specific feature taxonomy	Native assembly-feature taxonomy—fixturing, feeding, finger gripping, vacuum gripping, fitting, and screwing—each with dedicated SWRL detection and tool-selection rules
Mereotopological approaches: Kim et al. [52]; Demoly/PRONOIA [53]; Zhu/HAKF–MA-Onto [54]	Spatial relationship and assembly-joint formalization via parthood/connection theory	OWL-DL + SWRL over mereotopological primitives (direction, proximity, topology)	Rigorous spatial modeling, but at the expense of process and resource coverage; joint information stops short of selecting handling/joining processes or robotic tools	Extends spatial/mating relationships (concentric, coincident, perpendicular) into a complete inference chain that additionally selects the process and physical robotic tool for each detected mating relationship
Delamer & Lastra [55]; Equipment Ontology [56]; Product-Process Ontology [57]	Assembly process modeling, equipment reconfigurability, design–simulation integration	OWL + SWRL querying/reasoning over assembly knowledge	Process and equipment knowledge modeled, but without ISO-standard tolerance classification or dimension-driven fit-type discrimination	ISO 286-1 tolerance classes (e.g., H7, d11, h6, h8) drive automatic clearance/interference/transition fit classification, which in turn selects the joining process and tool—a precision level absent from these frameworks
Kim, Manley & Yang [58]; Mostefai et al. [59]; Huang et al. [62]	Assembly-joint and APP knowledge formalization	Ref. [58]: formal description only (welding-joint example); Ref. [59]: “supports inferences and queries but lacks reasoning capability”; Ref. [62]: no ontological formalism reported	Acknowledged by the source literature itself as incomplete or non-reasoning implementations	Fully executable SWRL rule set (22 core rules, validated via DL query, SPARQL, and Drools rule-engine execution) producing a complete, auditable process plan
Fiorentini et al./OAM [60,61]	Assembly representation with reasoning support for designer decisions	OWL reasoning over the Open Assembly Model; tolerance and assembly information exchange	Reasoning supports design decisions, not autonomous derivation of a robot-executable process plan with specific tool/resource assignment	Reasoning output is a concrete, machine-actionable process plan (feature → process → resource chain) directly consumable by robotic assembly planning, not only a design-decision aid
Imran & Young [63]	Assembly reference ontology: tolerance/fit, assembly features, methods, resources	Common Logic (CL) [64], not OWL/SWRL	Greater logical expressiveness claimed, but not integrated with a Semantic-Web rule engine (SWRL/Drools) or with native CAD geometry extraction	OWL2 + SWRL + Drools pipeline directly consumes SolidWorks B-rep geometry, requiring no separate logic formalism or manual translation step
CDOJP [65] (Saha et al.)	Welding-process standards consolidation across ISO/AWS/CEN/BS vocabularies	OWL + SWRL rules over welding-process concepts	Domain-restricted to welding; no CAD geometry integration or assembly-feature detection described	Process taxonomy spans fitting and screwing (the processes available in the validated robotic cell), with geometry-driven feature detection feeding the rule chain—extensible to further joining processes within the same architecture, see § Extensibility below
Product-design-side ontologies: Tursi et al. [35]; Chang et al. [38]; Wei et al. [39]; Lin & Harding [40]; Chhim et al. [41]; Wang & Tong [42]	Product design knowledge capture, DFM integration, multidisciplinary knowledge exchange	Class taxonomies (Product/Part/Component/Assembly-relationship); largely descriptive, decision-support oriented	Design-side only, or design + manufacturing without an assembly-process-planning-specific reasoning chain	Design knowledge (SW-AO layer, native to SolidWorks) and APP knowledge (PM-DO/RM-DO/AD-AO layers) are both first-class, equally detailed domains within one inference architecture

In Table 12 two groups of the proposed frameworks reported in the literature can be distinguished: the first group—SMIF [5], the mereotopological approaches [52,53,54], and the assembly-joint formalisms [58,59,62]—establishes semantic interoperability and spatial or terminological consistency across domains, but does not execute a rule engine that derives new, actionable process-planning facts from that reconciled knowledge. A second group—MASON [27], CDM-Core [34], ManuService [43], and MaRCO [48]—does perform reasoning, but over manufacturing or machining knowledge in which product design is a secondary input, and without the assembly-specific feature taxonomy (fixturing, feeding, finger gripping, vacuum gripping, fitting, screwing) that links CAD geometry directly to robotic assembly operations. PAPO is deliberately positioned outside both groups: it treats OWL2’s interoperability guarantees—shared class hierarchies across the GFO, FBM-DO, AM-DO, PM-DO, RM-DO, SW-AO, and AD-AO layers—as a substrate, not as the contribution itself. The contribution is the 22-rule SWRL/Drools inference chain executing on top of that substrate, which autonomously derives, from unannotated SolidWorks B-rep geometry alone, a complete feature → process → resource assignment with no manual process-planning step. This distinction is not theoretical: SPARQL Query 1 results (13 feature-to-tool chains for CS1, 21 for CS2) are inference outputs, not interoperability mappings—they did not exist as asserted facts anywhere in the source ontology or the CAD file, and were derived purely by rule execution. None of the twenty-seven reviewed frameworks report an equivalent end-to-end, geometry-to-resource inference result validated by direct rule-engine execution.

7. Conclusions

This paper demonstrates the potential of ontologies to support knowledge sharing across assembly design and process planning domains. It shows that heavyweight ontologies can play a key role in defining the semantics of concepts in the assembly domain, providing a foundation for knowledge exchange.

This paper describes the development of the Product-Assembly Planning Ontology (PAPO), a multi-layer ontology framework designed to integrate product design with assembly process planning (APP). By addressing key challenges in semantic interoperability and knowledge sharing, the framework facilitates smooth integration between these fields, supporting efficient decision-making and process improvements.

Heavyweight ontologies formalized in OWL and enhanced with SWRL rules provide robust reasoning capabilities, enabling the inference of new knowledge, cross-domain queries, and automated decision-making. The modular design of PAPO ensures flexibility, scalability, and reusability, making it adaptable to new fields and applications. Case studies of a three-button panel assembly and an ISO 15552 pneumatic cylinder demonstrate the framework’s practical, industrial use, highlighting its ability to link assembly design features to related processes and resources.

By leveraging modularity, the framework provides a comprehensive and balanced depiction of assembly design and process planning. PAPO, unlike previously reported frameworks, offers a fully balanced, equally detailed representation of both the assembly design and APP domains, with dedicated ontological modules for geometric feature data, dimensional tolerance knowledge, assembly constraints, process types, and robotic device specifications. PAPO adopts a feature-based approach that extends beyond spatial relationships to include handling, fitting, and screwing processes, along with associated tool specifications and selection rationale. PAPO formalizes an assembly-specific feature taxonomy covering fixturing, feeding, finger gripping, vacuum gripping, fitting, and screwing. PAPO spans the broader spectrum of robotic assembly processes and, crucially, provides an application-level ontological representation of both a CAD software system and a taxonomy of robotic devices, enabling end-to-end integration from design intent to executable process specification.

The PAPO framework ontology is validated through two independently designed case studies. Case Study 1 (CS1), a 7-part three-button panel, demonstrated that the inference chain correctly derives 13 feature-to-tool assignments—covering fixturing, feeding, finger gripping, vacuum gripping, clearance fitting, and screwing—with precision and recall of 1.000 against expert ground truth, and 100% agreement with the independently validated process plan. Case Study 2 (CS2), a 7-part ISO 15552 pneumatic cylinder (AL = 80 mm, S = 100 mm), extended the validated rule set to a structurally unrelated industrial product class, producing 21 feature-to-tool assignments across four ISO 286-1:2010 [92] tolerance classes, three distinct shaft–hole fit-pair types, and two threaded fastener specifications (M20 × 1.5 per ISO 4395 [89], and M10 per ISO 15552 [84]).

The current framework has acknowledged limitations. The validated robotic cell constrains the scope of automatic inference to fixturing, feeding, finger gripping, vacuum gripping, clearance fitting, cylindrical shaft gripping, and screwing; assembly processes involving elastic-component deformation (seal compression, O-ring insertion) and post-assembly functional testing are explicitly excluded and marked as open limitations in the ontology.

In conclusion, the PAPO framework emphasizes the potential of ontologies to enhance knowledge sharing and semantic integration in manufacturing settings, paving the way for more efficient, intelligent, and responsive production systems. This work advances Industry 4.0 by supporting dynamic resource allocation, real-time data integration, and adaptive assembly process planning in manufacturing environments.

Future research can focus on expanding the framework to cover additional domains and applications and on enhancing reasoning capabilities to support more complex assembly scenarios, such as assemblies incorporating elastic joining operations, requiring new rules that compute seal-compression forces from material properties rather than rigid-body geometry alone. Another future research work is expanding the feeding rule set to cover cylindrical parts (T2-Rules 16–18—Table 8, identified in this paper as proposed future extensions) through a VibratoryBowlFeedingProcess subclass and associated Drools rules, removing the current restriction on purely round parts.