**1. Introduction**

To face nowadays intense global competition, companies require manufacturing systems to be more flexible, adaptable, reactive and interoperable. This circumstance, together with the development of new information and communication technologies, such as Service-Oriented Computing (SOC)/Service-Oriented Architecture (SOA) or Cloud Computing and Web Services, has given rise to the emergence of several manufacturing technical and operational paradigms such as Digital Manufacturing, Reconfigurable Manufacturing, Service Manufacturing or Cloud Manufacturing, among others [1–5].

To be able to cope with the above-mentioned characteristics and to encourage collaboration in complex current manufacturing systems, a more reactive, adaptable and distributed Process Planning with an enhanced connection to production scheduling and product design is required [6–8]. The need that Process Planning has these characteristics and that is configured as a central element in an integrated product-process-resource system, was already stated many years ago, from one of the first proposals by the authors of [7] up to the proposal of a framework for the Collaborative and Integrated Development of Product, Process and Resource (CIDP2R) process [8,9]. In order to reach high levels of integration and adaptability, the proposal by the authors of [8,9] is based on a service-oriented architecture and locates Process Planning as a central activity interacting with Design and Production Planning and Control activities. In addition, this last proposal fosters an approach based on (central part of Figure 1): (a) a unified activity model valid for any process planning activity; and (b) a unified product-process-resource information model. This information model is based on a feature concept able to consistently support the development of solutions to meet functional requirements in the different involved domains (product design, manufacturing process planning, inspection process planning, etc.) at any abstraction/specialization level.

**Figure 1.** Functional architecture of the Collaborative and Integrated Development of Product, Process and Resource (CIDP2R) process [8].

These feature-based approaches are also the basis of recent works in the newest and current Cloud-based Design and Manufacturing contexts. The need of a feature-based approach together with service-oriented architectures for data exchange in Cloud-Based Design and Manufacture contexts is stated in [10]. Similarly, cloud and feature-based Functional Blocks (FB) technologies to develop a Cloud Distributed Process Planning system that works as a central service aimed at increasing responsiveness and adaptability in current collaborative environments is adopted in [3]. However, all these proposals make use of a very specific feature concept and highlight the need of a generic feature concept able to support frameworks such as the previously mentioned CIDP2R one.

The unified activity model developed in the CIDP2R (Figure 1) considers the integration of the activities and their relationships in two dimensions [11]. One of the dimensions refers to the development process maturity and distinguishes three levels: aggregate, supervisory and operational. The second dimension refers to the perspective and takes into account the product, the needed process plans and the required resources. In [11], the supervisory level and process planning activities are thoroughly described, and particularly the manufacturing and inspection processes integrationin order to encourage the use of new in line inspection (in and post process) capabilities, especially on-machine measurement, to obtain even real-time performance information and improve system reactivity. This has been in increasing need in recent years, due to the appearance of hybrid machines that combine processing technologies (e.g., subtractive and additive manufacturing) with new measurement technologies.

The requirement of a generic feature concept to support the CIDP2R process, led to the proposal of the Unified Application Feature (UAF) framework, which includes the definition of a generic Application Feature, and which will be briefly reviewed in the next section [12]. In addition, a Specification Feature, such as a specialization of the Application Feature, was proposed in [13]. This Specification Feature considers geometry with defects to support all the activities of the CIDP2R process where the consistent representation and treatment of dimensional and geometrical variations is essential: product specification, process (manufacturing and inspection) specification, and resource assignment. Additionally, in the same work, a system-oriented and tolerance-driven artefact model was also defined, where the workpiece is understood as a part of an assembly (assembly model), valid for all the product life cycle phases (final product assembly, machining process assembly, inspection process assembly), which is required to achieve unification.

According to the above, and in addition to the definition of a specific feature for the inspection domain, this work aims to prove that the UAF framework, based on the proposed Application Feature, has the sufficient generality to provide the required flexibility in order to define feature specializations. These Application Feature specializations are not only in the product domain, but also in the process planning and resource assignment and configuration domains.

The rest of this paper is organised as follows. In Section 2, a generic specification feature model developed by the authors in previous work is briefly summarized. Section 3 presents the proposal of an Inspection Feature, as a subtype of Specification Feature, which enables Supervisory Inspection Plan specification and validation based on the inspection assembly, resulting from the assembly of the subject part for inspection and the measurement resource (including fixture, probe, equipment, etc.). Finally, Section 4 concludes with a summary of the main contributions and indicates some future work.

#### **2. Background and Methodology**

Traditionally, the dimensional and geometrical specification exercises are carried on the assembly corresponding to the final product and their objective is to establish and validate product functionality through the geometric specification of all its individual parts. However, along the different product lifecycle stages, each of these parts participates in other assemblies required for its realization (manufacturing and inspection). These process assemblies (manufacturing and inspection) that are established for process plan specification, analysis and validation (inspection blueprints), in addition to the part, include the resources on which the part is fixtured in the different process set-ups. Therefore, a feature-based framework for specification is necessary to enable, in a dual and consistent manner, a uniform product and process plan specification considering, analyzing and validating two different types of assemblies: product and process assemblies (manufacturing and inspection).

Before presenting the Feature-based Framework for Geometric Specification, in the first part of this section, a general review of feature concept and feature-based modeling frameworks is carried out. One of the generic featured-based frameworks used for geometric specification and aimed at fulfilling the requirements of a consistent product and process plan specification, is summarized in the second part of this section. This framework has been presented in prior published authors' work [12,13]. The third part of this section presents the parts of the framework for geometric specification that includes a geometry model, a specification feature model and an assembly model. Finally, the section ends with a summary of the methodology used to develop and validate the proposal of an Inspection Feature.

#### *2.1. Literature Review on Features Definitions and Modeling Frameworks*

The feature is a concept that was incorporated in the design and development of technical systems by the end of the last century, especially in the Computer Aided Design and software product line engineering fields. In the first one, a feature represents the engineering meaning of the geometry of a part or assembly [14]. In the second one, feature modeling is a common approach to manage variability supporting the establishment of a product line configuration that meets multiple, and often contradictory, requirements [15]. However, in recent decades this approach from the software domain was progressively applied to the management of technical systems, and particularly to mechatronics systems [16]. This fact has been fostered by the customised mass production paradigm, since feature

modeling offers a transparency for capturing and visualizing optional and alternative conceptual design solutions that the traditional requirement specification process does not provide [17].

If the feature concept and definition in specialised literature is analyzed, it can be noted that the feature usually depends on the context of the application domain and that, additionally, the concepts used remain still ambiguous and very often contradictory, even when the domain context is perfectly established. The consistency of the meaning given to the feature in different engineering areas was analyzed in [18], concluding that the feature concept has been employed with very different representation purposes such as an abstract concept, a set of properties, the material it is constituted of, a component structure, etc. Although the authors of [18] reveal this reality, the reason for it is not explained. From this paper author's perspective, the reason for this reality is that during the design exercise (intent) the engineer needs the support of different entities, although they should be unified to ensure consistency.

In addition, feature generic definitions and frameworks aimed at unifying the concept and the development of feature-based models and to support the interoperability among the applications can be found in all domains, from the most specific to the most general ones. A very general definition describes the feature like *anything about the thing being designed that's from interest* [19]. Based on this definition [19] establishes three types of feature: *Functional, Behavioural and Structural Feature*. Other authors define more specifically the feature as: (1) *An information object (feature type), always related to an artefact, that specifies engineering intent* [18]; (2) *A property that is relevant to some stakeholders and is used to discriminate between concept instances.* In the case of technical systems, these properties can be structural (e.g., shape, size), behavioural (e.g., an operation mode) and functional (e.g., cruise control of a car) [20]; or (3) *As abstractions or groupings of requirements describing structural, behavioural or functional properties of a system that are relevant and understandable for different stakeholders* [21].

Considering all the previous definitions, it can be concluded that the feature must always be understood as something that facilitates the specification and therefore, in order to do so, it must be perceived as an informational object that belongs to the design solutions space. In this design solutions space, two different sub-spaces can be distinguished: the design (functional) rationale one and the design (structural) components one. Both sub-spaces can be established at different abstraction levels. The feature is able to describe solutions either in one of them or in both (mapping the functional solution with the structural solution).

Moreover, instanced feature objects must always be described in a simplified way (label), according to [17] by a single word or a short line of text. This last circumstance and the fact that the feature is always related with the function (Functional Feature), with the technical product (Structural Feature), or with both, is the reason why the feature is frequently mistaken with a function and/or with a product. A car, a car impeller or a car body are instances of (functional) features at different conceptual levels present in the feature (tree) model representing the design intent (rationale) analysis. Likewise, an engine, a piston or a rod are also examples belonging to more specific analysis levels and that are linked with their embodiment, facilitating the relation with the components and their (structural) features, which represent the virtual product structure.

According to [22], the engineering community lacks a common way to represent features, which is suitable to support data sharing and interoperability between systems and communities. Two feature frameworks, both using Unified Modeling Language (UML) class diagrams, are highlighted by [22]: the Generic Feature proposed by [23] and the Unified Application Feature proposed by [12]. The Unified Application Feature (UAF) is the basis for this work and, therefore, it will be briefly described in the next section.

#### *2.2. Unified Application Feature Framework*

The UAF framework is based on the essential need that the feature encapsulates the design intent, as proposed by de PPO (Product-Process-Organization)model [24,25], and is enhanced with ideas from feature modeling techniques in software domain, such as FODA (Feature-Oriented Domain Analysis), and particularly, with the approach proposed by [15] who considers different types of feature. The UAF framework has been represented using UML class diagrams. The choice of UML as representing language is due to two main reasons. Firstly, UML is normally used in many engineering domains to describe a data model. Secondly, UML conceptual descriptions translate well to OWL, which is a language commonly employed to develop ontologies.

This framework defines a generic feature, the Application Feature [12,13], as a container of different feature categories, likewise other authors had already done [15,16]. The Application Feature is able to support any design solution, including the mapped functional and structural design solutions and independently of the abstraction/specialization level.

The proposed Application Feature, which is described in Figure 2 using a UML class diagram, is defined as an aggregation of other features (Object Feature). An Object Feature, which represents a valuable aspect for the stakeholders, is an information entity of one of the following four categories: (a) *Functional Feature*, which represents the way in which the artefact may interact with other systems. Therefore, it represents a functional solution for a functional requirement (resulting from, for example, product or process specification); (b) *Interface Feature*, which represents the artefact elements that play a port role in the interaction with other systems; (c) *Structural Feature*, which represents the artefact configuration, that is, the artefact components and their structural relationships (e.g., part of, composed of, formed by, etc.); and (d) *Parameter Feature*, which contains all other non-functional properties with required quantification by values or quality assignment (e.g., colour, weight, volume, etc.).

**Figure 2.** Updated basic structure of the Application Feature Model and its relation with the Product-Process-Organization (PPO) model.

Figure 2 also illustrates that the four Object Features are specializations of the three fundamental classes (*Component*, *Interface* and *Function*) of the PPO model. In this way, the fundamental classes inherit the properties of the PPO, easing collaborative work [24,25]. Additionally, the labels of the association relations established between the PPO classes determine the relationships typical of an engineering process driven by the design intent.

In contrast to [23], the UAF model also supports the feature-based description of the design solutions and, as can be seen in Figure 2, includes the relationship with the components hosting the features (*Artefact*) and the relationship with the functions (*Functional Requirement*) fulfilled by the features. In this sense, the proposed definition of the Application Feature is also in line with the concepts behind of the so-called Configurable Components used in product platform design that are understood as autonomous knowledge-carrying configurable generic subsystems [26]. Another shared characteristic of the Application Feature with the Configurable Components is that they allow component links through their interface and interaction elements. Thus, the Application Feature is an information object that enables product and manufacturing system (technical artefact) design based on

the definition of the corresponding platforms. In addition, similarly to the Configurable Components, the Application Feature makes no distinction between the product artefact and the manufacturing system artefact, considering both in the same way (technical artefact). This allows for the establishment of interrelationships between product and manufacturing system Application Features by means of an Interaction Feature relating Interface Features of the Product and the Manufacturing System.

#### *2.3. Feature-Based Framework for Geometric Specification*

As has been mentioned, the geometric specification exercises are carried out on assemblies (product or process). These assemblies, which represent technical solutions for product or process functional requirements, are made of parts interacting through their geometric interfaces. The representation of these geometric interfaces for the specification exercise requires of appropriate geometry models in order to consider and limit the geometric variability. These geometry models are described in the first part of this section. The proposed geometry models are used in the Specification Feature Model presented in the second part of this section. Finally, the Assembly Model, which enables the establishment of a chain for each functional requirement, is presented.

#### 2.3.1. Geometry Model for Specification

During the product specification task, the designer works with imaginary geometries with defects of the parts of the product assembly. Based on these imaginary geometries and considering the geometrical conditions of the final product function, the designer carries out several simulation exercises on the product final assembly, with the aim of specifying permissible geometric deviations (tolerances) for each individual part of the assembly. Likewise, during the inspection process specification task, the planner works with imaginary geometries of the components of the measurement assemblies, devised solutions to measure the subject part of the inspection, and carries out different simulation exercises in order to specify the permissible uncertainties for the planned measurement assembly. In this way the appropriateness of the measurement assembly solutions (reference surfaces, fixture, probes, etc.) established to determine the GD&T (Geometrical Dimensioning & Tolerancing) characteristics specified for the subject part of the inspection is validated. The types of supported geometric defects need to be compatible with the selected simulation tool used and with the type of deviation that the measurement instrument or equipment is capable of extracting. Alike simulation exercises are also present in the specification of any manufacturing process, such as the machining process, with the aim of specifying the manufacturing systems (dimensional and geometrical) capabilities.

From all the above-mentioned, it can be gathered that process (manufacturing or inspection) specification exercises, similar to what the GPS (Geometrical Product Specification) standard establishes for product specification and its verification, are also based on the distinction between the real world, where several and different realizations of the part exist, and the imaginary models (surface models), used to represent those realizations. The GPS standard establishes a similar distinction for product specification and its verification [27] defining three types of surface models (nominal, skin and extracted).

Figure 3 shows the digital models with defects considered in this work that can be used in the different simulation tools and that are linked to the conceptual skin model. Two types of these surface models are considered: ideal models, which are defined by a parametrized equation, and non-ideal models, which can be defined by a set of surface patches (continuous) or by a set of points, segments or tessellation elements (discrete). In practice, it is unfeasible to obtain the non-ideal continuous model, since it would require a large amount of complex information. Therefore, discrete models, which are obtained by sampling on the real part, are used in the specification exercise. This discrete model is the one considered by GPS, and hence always assuming a measurement method based on discrete digitalization. The non-ideal models can be simplified to different ideal models. If the simplification process neglects the form and orientation defects of the surfaces, models with dimensional (linear) defects and models with angular (position) defects are obtained respectively. The simplification process can lead to skeleton models with defects, when the geometries participating in the functional condition of the assembly are geometric elements derived from surface elements. If the simplification process is applied to ideal models, substitution and/or reduction operators are involved. Extraction operators are the ones involved when simplifying from a non-ideal continuous model to a discrete model.

**Figure 3.** Geometry models for product/process specification.

Although in recent literature discrete models to represent the geometry with defects have been proposed [28], the majority of the analysis methodologies and tools use ideal continuous geometries and geometric tolerancing models based on variational geometries that do not include form defects (Degree of Freedom–D.o.f., Small Displacement Torsor–SDT, etc.). Therefore, if the analysis is carried out using one of these techniques, the representation of the geometry with defects (skin model) is either an ideal surface, including location, orientation and size defects, or a skeleton model. During specification, transformation between different geometric models might be required. These transformations are ruled by an operator consisting of a set of GPS basic operations such as partition, extraction, filtration, association, reduction, etc.

#### 2.3.2. Specification Feature Model

The three specification exercises (product, manufacturing plan and inspection plan) involve the management of geometrical variability, although different names are used in each specification field: tolerance in product design, natural process tolerance (capability) in manufacturing and uncertainty in inspection. For that reason, the three specification exercises should be based on a unified feature model where the geometrical interface is represented using the same geometry model as described in the previous section. Based on this assumption, authors of this work proposed a unified Specification Feature (Figure 4) that will be briefly summarized in this section [13]. This feature aggregates the three types of object feature considered in any Application Feature: *Geometry Feature* (geometric interface), *Specification Structure* (structural elements) and *Condition* (functional geometrical condition for which the structural elements are a solution).

As Figure 4 shows, that the geometric interface contains, the nominal geometry (*Nominal Feature*) and additionally the representation of the deviations for this geometry (*Geometry with defects Feature*) in any of the tolerance models (GPS, TTRS, etc.) necessary to support the corresponding specification exercise. The *Geometry with defects Feature* aggregates three features: (1) *Extracted Feature*, which represents the geometry in the form in which it is extracted from part surfaces with defects; (2) *Substitute Feature*, which represents an ideal and continuous geometry related to the geometry with defects; and (3) *Reference Feature*, commonly known as Datum Feature, which represents an ideal geometry that positions extracted and substitution geometries. An *Extracted Feature* can be of two types: *Discrete Geometry* or *Envelope*. When it is a discrete geometry, it is made up of a set of points, segments or tessellation elements. Otherwise, if the extracted geometry is of type envelope, it is made up of a set of (two) trimmed ideal and continuous lines or surfaces enveloping, internally and/or externally, the real geometry with defects. This second type of extracted geometry is not considered by the GPS standard, where only extracted models able to support the way in which coordinate measurement machines take measures are considered.

**Figure 4.** Specification Feature Model (updated from [13]).

#### 2.3.3. Assembly Model for Specification

The geometry with defects (*Geometry with defects Feature*) of the Specification Feature, seen in Figure 5, is the central element of the Assembly Model for Specification. This is a key model in order to establish conditions on kinematic loops associated with a mechanical assembly (product or process simulation exercises). These loops are determined according to the different assembly configurations established by the set of joints between the geometric interfaces of the different components. Therefore, for the specification exercise a model including both the assembly architecture and the chains and functional conditions is required. The links in these loops establish the relationships between the geometric interfaces that may belong to the same or to different parts. These interfaces will be represented by the corresponding geometry with defects included in the Specification Feature previously described.

The model establishes the relationships between this geometry with defects and other concepts involved in the simulation exercises, such as the specification architecture and loops (*Specification Assembly Architecture* and *Chain*). In particular, an assembly is characterised by an architecture defined as an aggregation of all contact conditions (*Contact Condition*) between the geometry with defects of all features, either in the product or in the process assembly. The types of contacts considered in the model are *Floating*, *Fixed* and *Sliding Contact* [29]. The model also considers the non-contact conditions (*Non-Contact Condition*) that establish either a condition within the same part or a separation condition between two different parts. In addition, a *Chain* aggregates all the associations between the features including the information about the geometry with defects required to close the functional loop. From all links included in the *Chain*, just one of them is associated with the condition (*Condition*) to be fulfilled (either product or process condition), and the rest of the links will be associated with other conditions (contact or non-contact).

**Figure 5.** Assembly Model for Specification (updated from [13]).
