This paper describes the modeling of manufacturing process plans by proposing the extension to the Process Specification Language. First, we briefly describe a hierarchical nature of the process plan model which results from process planning activity. Few levels of hierarchy: part level, machine level, setup level, and process level were defined with the last, process level, being a level of atomic manufacturing processes. After the application-oriented description, we utilize the Process Specification Language (PSL) in order to provide formal definitions of described hierarchy, which is based on the usage of various resources in manufacturing and process planning. We extend the PSL activity to include resources with their roles in atomic processes and then build a hierarchy of PSL activities that correspond to the manufacturing process plans. We complement the hierarchical process plan model with two important considerations, namely, process sequence and ordering constraints and we illustrate how the model can accommodate them. The discussion of the proposed model is supported by an example.
Process planning primarily consists of “determining the most appropriate manufacturing and assembly processes and the sequence in which they should be accomplished to produce a given part or product according to the specifications set forth in the product design.” Selection of necessary processes is also the most complex phase of process planning, due to the subjective nature of the act of planning. Traditionally, manufacturing industries depended on the knowledge of craftsmen, artisans, and machinists for planning their production strategy. In variant type of process planning, templates of plans for common design specifications are stored and re-used for generating plans by matching the design requirements with the template specifications. In modern computer-aided process planning systems, generative type planning mainly focuses on capturing manufacturing best practices, standards and machinists' knowledge in reusable formats, which are referred to generate process plan from the design specification. In the area of CNC machining, such as drilling, milling, and turning, these type of knowledge may include the process-specific capability for generating features of particular quality and precedence among tasks, which is to be maintained for achieving the desired result, based on inherent constraint in the design and commonly prescribed ordering in the application of processes.
In this paper, we focus on two fundamental aspects of process planning, which are (1) aggregation of processes based on their attributes, such as resources and output of the process, (2) precedence among processes, stemming from the constraints in design specification and applicability of process. The domain-focused brief explanation of process plan representation is given in Section 3. The ontological commitment for the proposed resource-based aggregation and technological precedence between activities are discussed in section 4, based on the theory of manufacturing planning from our previous research work. The formal definitions of sub-types of activity based on the aggregation factors are presented in section 4.1, and process sequence in section 4.2. Then, various precedence constraints are discussed in section 4.3. Before we delve into these topics, we present a brief overview of previous researches on the topic of our interest, including semantic modeling of process flow based on Process Specification Language, which we heavily adopt in our proposed model.
The importance of the nonlinear process plan concepts including dynamic and flexible
process plans has been identified and considered as a benchmark for process planning
and integration by most of the research approaches [
Open assembly model (OAM) proposed by NIST, defines generic concepts to
integrate requirement, functional design, kinematic synthesis, and tolerance analysis
along with basic part and assembly information [
Process Specification Language (PSL), developed by Gruninger, describes such a
formal model for representing planning and scheduling problems, especially suited for
manufacturing industries [
While PSL is originally built for interoperability of process flow information among manufacturers and CIM software, generative process planning involves actual planning before such flow may be construed. In a dynamic shop-floor condition, these plans sometimes need to be re-generated or modified based on real-time conditions. In this type of scenario, canonical models of process plans are not enough as some level of flexibility should be achieved in dynamic process planning with good support of the rules and query system to the knowledge representation language. A semantic model of generative process plan should include the necessary planning criteria and constraint embedded in the plan in lieu of a mere collection of processes universals (Activity in PSL terminology). Based on this argument, we are going to present the semantic model for generative process plan in first-order logic, which heavily adopts the process flow related concepts from PSL, with an honest admission that such model may not be directly interpretable in the standard version of PSL.
Manufacturing planning mainly consists of a series of tasks, performed in a sequence to
manufacture a part with the desired quality. However, more often tasks from one step
need feedback from previous steps. Production management decision made at every
step influences the decision for subsequent steps. This inter-dependency among phases
of development is classically tackled by concurrent engineering. The main idea behind
concurrent engineering is to integrate various phases of the product life cycle, such as
design, manufacturing, assembly, quality assurance, and maintenance; so that the
designers can design the product keeping the manufacturability of the product in mind
(Design for manufacturing/Design for Assembly). In practice, this demands an
integrated system able to analyze the design data and compute the necessary processes,
machines, and tools necessary at the design time. Integrated Manufacturing Planning
tool (IMPlanner), developed by Sormaz and Khoshnevis (1999) addressed the
aforementioned inter-dependency among various planning variables [
IMPlanner uses a three-dimensional object-oriented model to represent the nonlinearity in manufacturing process planning (MPP) information, shown in Figure 1. In this model, various stages of non-linear MPP are filed along the aggregation dimension. At each aggregation level, a set of planning variables, such as (features, processes, machines, and tools) are selected to be part of the overall process plan.
At the bottom-most level, each process is identified based on the output it
produces. In this model, the most granular form of output of a manufacturing process is
a feature, which can be broadly defined as some special areas of interest in a part — “a
set of geometric entities (surfaces, edges, and vertices) together with specifications of
the bounding relationship between them and which have engineering function and/or
provide assembly aid” [
Moreover, planning variables at every aggregation level also vary along with variety and time dimension. Variety dimension captures alternative selections of planning variables for a certain manufacturing task, whereas the time dimension captures the temporal dependency among the planning variable values at every aggregation dimension. Such temporal ordering among processes at each aggregation level arises from constraints related to each aggregation factor. In this study, we model two fundamental precedence constraints: feature precedence and process precedence, which are presented in section 4.3.1and 4.3.2 respectively.
In this section, we present the model of the manufacturing process plan based on the ontological argument and present important definitions by extending PSL terminology. First, process hierarchy is described, which is followed by a discussion on process sequences and ordering constraints in the subsequent sections.
The general meaning of a process in manufacturing is polysemous in nature, as the contexts for the use of the word are often assumed in the purported meaning when we use the word in different situations. For example, a process may address a singular task to be performed as well as an entire series of processes undertaken for manufacturing a product. It is therefore required to classify process based on the difference in contexts. We argue that some combination of machine and fixture is always required whatever type of process is concerned. For example, for metal fabrication industry a CNC type machine (e.g. mill, drill lathe, stamp) along with an appropriate tool works on raw material, which is normally a stock, metal bar or rod, held in a specially designed fixture. The use of the machine is also compulsory in many other types of industrial processes, such as the injection molding machine in casting, and blenders in mixing, however, such statement may not be strictly asserted for the tool as the semantic distinctions between machine and tool is debatable and out of the scope of this document2. The fixture in the industrial process is responsible for holding the raw material, or in-process workpiece in the right position and orientation for the machine and the tool to operate on them. For example, the workpiece is placed in the orientation so that the tool path can cut the shape of the feature. The fixture may also be a rack, a conveyor belt, or a vessel when the scope is extended to a wider variety of manufacturing. The ubiquity of some kind of machine and fixture in manufacturing processes may be established by considering the situation for the simplest type the processes, take for example the manual packaging of an artifact, which needs a pair of dexterous hands (the machine) and at least a platform (the fixture) in order to carry out the packaging process.
In PSL, Axiom 16 dictates that an object can participateIn an activity only at those
timepoints at which both the object existsAt and the activity isOccurringAt, where an
activity-occurrence is the occurrenceOf a single activity [
The PSL Ontology uses the subactivity relation to capture the basic intuitions for
the composition of activities. Subactivity relationship is a transitive relationship which
holds between two activities [
StepActivity: Step is an atomic activity, i.e. no other activity can be a subactivity of StepActivity, in a process plan. An activity is a step activity if the output of a StepActivity is a single feature, i.e., no two features can be the output of the same StepActivity. This definition is based on the definition of working step in ISO 14649, however, while ISO 14649 is focused on CNC machining, this definition is its extension to other manufacturing processes.
∀ () ≡ () ∧ ∃, ℎ(, (, )) ∧ (∃′ (9) ∧ ( ≠ 9) → ∃′ ℎ(, (′, )) ∧ ( ≠ ′))
The predicate achieves is borrowed from the PSL axioms for fluent attached to the
occurrence [
SetupActivity: A SetupActivity is composed of one or more StepActivity, each of which is performed using the same fixture, i.e. no two StepActivity, which are subactivity of the same SetupActivity can use different fixture. Also every StepActivity under a SetupActivity works on features, which all belong to the same part. ∀J =J? ≡ =J? ∧ ∃ () ∧ =, J? → ∃ (, ) ∧ (∀99 ∃ (9) ∧ (9, 9) ∧ =9, J? ∧ (, ) ∧ (9, ) → ( = 9))
, where usesFixture is a sub-property of PSL is_participant_of and Fixture is a sub-type of Object. It should be mentioned here that this definition does not imply that all StepActivities with the same fixture have to belong to the same SetupActivity.
MachineActivity: A MachineActivity is a type of activity such that each of its subactivity is processes in the same machine, i.e no two activities, which are subactivity of the same MachineActivity, can be processed on two different machines. ∀M ℎ(M) ≡ (M) ∧ ∃J () ∧ (, M) → ∃ ℎ(, ) ∧ (∀9J9∃ (9) ∧ ℎ(9, 9) ∧ (9, M) ∧ (, ) ∧ (9, ) → ( = 9) , where usesMachine is a subproperty of isParticipantOf and Machine is a sub-type of Object.
PartActivity: A PartActivity is a type of activity such that each of its subactivity makes some change in the workpiece, targeted to make a single part, i.e no two subactivities of the same PartActivity can have output features belonging to two different parts. ∀P =P? ≡ =P? ∧ ∃ () ∧ =, P? → ∃ (, ) ∧ (∀9′ (9) ∧ =9, P? ∧ (9, ) → ( = 9)
Based on the aggregation factor, the activities at every level of the activity hierarchy can be classified as a type of complex activity, except for the StepActivity, which should always be an atomic or primitive activity. The hierarchy of activities may be formed by classifying the activities at each level as one of the activity types, described above. The aggregation hierarchy, shown in Figure 2, is for a simple part with four features. Table 1 shows the machines and tools participating in the instances of StepActivity and corresponding features achieved. The part will be completely done if all four of its features are processed successfully, each of which is the output of one of StepActivity shown as the leaves of the hierarchy. At the root of this hierarchy is PartActivity, which contains every required step as its subactivity. Two instances of MachineActivity are included for two types of CNC machine needed for generating four of its features. Under the MachineActivity, different SetupActivity(s) group step activities base on tool direction. Note that SetupAct1-A and SetupAct2-A have same tool direction, still distinct as they are applied to different machines.
The primary purpose of the aggregation in a manufacturing plan is to group steps under the same machine, tool, and other resources, so that the resource allocations, which are expressed at the complex activity level, can be deduced from atomic step level. The reason for such aggregation is that, whenever some resource is changed, there are other non-manufacturing activities required to accomplish that change (for example, if the machine is changed, some transport is necessary). Furthermore, the step activities can be grouped by resources as required. This is possible because PSL declares subactivity as transitive. For example, StepAct2 is a subactivity of SetupAct1B, which is, in turn, a subactivity of MachineAct1. Therefore, StepAct2 uses milling machine Mill1 and fixture Fixture2. On the other hand, one may query which steps can be allocated to Mill1 and find three answers Step1, Step2, and Step4.
The successor relationship between two occurrences of activity occurrences is the basis
of the occurrence tree in PSL. “The PSL successor relation associates occurrences with
each other to represent all temporal orderings of runtime execution of activities whether
they conform to a behavior specification or not, and even including orderings that are
physically impossible. The relation forms a tree where every occurrence has exactly
one successor for each activity, indicating the possibility of that activity happening next,
so the branches represent possible execution traces” [
It is apparent that without any constraint on the occurrence of the steps, every branch of the occurrence tree is a viable execution trace, or in other words, a possible plan for the part. However, ordering constraints may be applied based on the intrinsic and extrinsic ordering constraints stemming from participating resources to each StepActivity. For example, one may wish to work with a particular machine before going to other machines, or always perform all the steps using the same fixture together. In the presence of such constraints, only some of the branches of an occurrence tree can be regarded as a valid process plan. PSL provides minPrecedes and nextSubocc relationships for expressing ordering constraints among sub-occurrences of an occurrence.
Apart from these resource-based constraints, two other types of constraints govern the validity of a process plan. The first one stems from precedence imposed by the processing order among features of a part and type of processes to be applied for producing a feature.
Features (e.g. Hole, Slot, Pocket, Chamfers, and Bevel)
in product design can only be machined in a specific
order due to their overlapping spatial location (position)
and orientation (vector) [
As described in section 4.1, features are uniquely tied to the instances of StepActivity. Being primitive activities, the occurrences of the StepActivity instances constitute various branches of the corresponding occurrence tree. PSL prescribes the use of nextSubocc relationship among the subactivities of a complex activity to denote such precedence constraint strictly. During planning, the following axioms impose ordering constraints among the occurrences of the steps (primitive activity) based on the precedence constraints among features. In order to capture the constraints among the features, which is not itself temporal precedence and derived from the positioning and orientation of those features in the part design, a new predicate nextFeature is introduced. This new property can only be held between two features, generating a complete or partial ordering among the features. For example, the partial order among four features of the simple part shown in Figure 2 Figurtehe5:feFaetautruerseopfrseicmedpelencpearatmong is shown in Figure 5. It should be noted here that feature precedence is a minimal set of constraints that the product or part requires for their manufacturing, on the other side process precedence may include more constraints (some will be mention later). Based on this feature precedence, a temporal ordering may be applied among planned activities, using the following minPrecedes axiom. ∀, R, R9 (R, R9, ) → ∃, R, R9, , ′ (, ) ∧ (R, R) ∧ (R9, R) ∧ (R, ) ∧ (R9, )
9 ∧ ℎ(R, (, ) ∧ ℎ(R9, (, 9) ∧ (, 9)
For the activity composition shown in Figure 2, Slab1 is processed by Step1, Slab2 by Step2, Slot by Step4, and Hole by Step3. The constraints among the features can be translated to the order among the corresponding occurrences of these steps by the following facts.
occurrenceOf(“op”, “PartAct”) ∧ minPrecedes(“o3”, “o1”, “op”) ∧ minPrecedes(“o4”, “o2”, “op”) ∧ minPrecedes (“o4”, “o3”, “op”)
PSL suggests the relation legal to specify an atomic occurrence (occurrenceOf a primitive activity) o is an element of the ‘legal’ occurrence tree. A legal occurrence tree is the subtree of the complete occurrence tree, which captures both possible and impossible branches. For example,
(S , "4") ∧ (S ) → ℎ=V, ("2", )? ∧ ℎ=X, ("", )? ∧ (4, ("Slot ", )). This set of facts can also be deduced from the following rule by applying the minPrecedes axiom and avoiding the fluent predicate. ∀X (S , "4") ∧ (S ) → ∃, V, S (V, "Step2") ∧ (X, "Step3") ∧ (S , V, ) ∧ (S , X, ).
Similar rules can check the ordering constraint on occurrences of Step1, Step2, and Step3. The branches of the occurrence tree, in which every occurrence is legal then can be selected as a valid process sequence. The valid sequences are marked with green in the occurrence tree shown in Figure 3.
Similar to the precedence among features of the part, a valid process plan also needs to follow a particular ordering for the processes applied in order to make one feature meeting its specification. This sort of situation is normal for CNC machining, in which more than one machining step may be required in order to make the product feature in order to meet tolerance speculations such as dimension tolerance and surface finish, however, this may occur in another type of manufacturing depending on the definition of feature adopted. For example, multiple heat treatments may be required to harden a metal bar, a welded joint may require polishing before welding, and paint job may require a coating of primer before the color is applied. The precedence among process stems from the technological limitation of the machine and tool used in a particular manufacturing method, for example, a pilot hole needs to be drilled before drilling a deep hole with a strict straightness requirement in order to avoid the deflection of the drill bit under mechanical stress.
The precedence among processes is best handled if an intermediate object is generated for every step. Following this approach, we may generate intermediate features for the part design whenever more than one process is required to satisfy the specified tolerance requirements. This also corresponds to practice, as such partially completed part may need to be transported from one machine to another (e.g. from a lathe to heat treatment, then to a grinder if grinding operations are required). Those intermediate features become an integral part of the part model for manufacturing planning. Therefore, the extended part model is a union of manufacturing features for the part design and all intermediate features that were identified as necessary during the process selection procedure. In order to complete the extended part manufacturing model, it is necessary to consider the impact of intermediate features on the feature precedence network (FPN).
In order to generate the Extended FPN (EFPN), we will assume that the process selection procedure produced the processes for design features as shown in Figure 5. From the figure it is visible that to make Slab we need only milling process (M), while for the other three features we need two processes for each: for Hole we need twist drilling (Step3) and boring (Step3i), for Slot we need rough (Step4) and finish (Step4i) milling operations. The activity hierarchy for the corresponding EFPN is shown in Figure 6 by adding the intermediate features.
In order to accommodate the intermediate features, we need to extend our original aggregation to include another level of aggregation, which can combine steps having the feature outputs belonging to one feature specification. Every subactivity of this new type of complex activity FeatureActivity is targeted to the same feature specification. The specification of the feature is distinguished from an actual (physical) feature. The intermediate features are a distinct physical feature with different dimensions and properties, whereas the design feature is specified in the product design document. It is expected that only one of the intermediate features will match the specification, and thus may be called the final feature. In Figure 6, The activity hierarchy shown in Figure 5 is redrawn by introducing this new complex activity. The axiom of FeatureActivity is given below, in which the property specificationOf(fs,f) describes that feature f (possibly intermediate or final) is one of the features created in course of achieving the specification fs.
∀^ (^) ≡ (^) ∧ ∃ () ∧ (, ^) → ∃, , R ℎ=^, (, )? ∧ (R, ) ∧ (∀9, R9, 9 (9) ∧ (9, ^) ∧ ℎ=9, (9, )? ∧ (R9, 9) → (R9 = R))
The aggregation based on the feature can also be imposed on the occurrence tree using the required precedence among processes for subactivities of a FeatureActivity. For example, when applied as subactivity of the same FeatureAct3, twist drilling (Step3i) should precede boring (Step3), which can be stated as ∀B (B, "Boring") ∧ (B) → ∃_, (_, TwistDrilling")∧ occurrenceOf(o, "3") ∧ (B, _, )
This paper presents the manufacturing process plan representation in a first-order logic by extending a concept from the Process Specification Language (PSL). The primary contribution of the paper is the formal definition of complex activities based on the type of resources being used and the output of the activity. We have shown how these complex activities can be combined to make a hierarchical aggregation and representation of manufacturing process plans. After the basic model description, it has been augmented to accommodate two types of precedence, namely feature and process precedence, which act as constraints on the flow of the processes. This extension was presented using the PSL occurrence tree concept.
The model is illustrated with the help of simple mechanical design (called simple part), which has only four features and corresponding manufacturing steps. However, the proposed model did not go through formal validation using reasoning algorithms and case studies for a variety of situations. Therefore, future work with the model will include completion of formal representation and axioms in first-order logic (FOL), the model application on more realistic examples, and its verification using reasoners to answer typical manufacturing planning questions.