A knowledge-based system for process family planning
Linda L. Zhang
IESEG School of Management (LEM-CNRS), Catholic University of Lille, Lille, France
Qianli Xu
Department of Product and Production Development, Chalmers University of Technology, Gothenburg, Sweden, and
Petri Helo
Logistics Systems Research Group, University of Vaasa, Vaasa, Finland
Abstract
Purpose– The purpose of this paper is twofold. First, it is to introduce a knowledge-based system for planning processes for families of final products, instead of component items, be they parts or assemblies. Second, it is to demonstrate the feasibility and potential of a prototypical system developed for planning processes families for truck families from a multinational company.
Design/methodology/approach– The authors first identify the challenges in planning process families, including data and knowledge representation and constraint handling. To accommodate these challenges, the paper adopts the integrated product and process structure (IP2S) and colored timed Petri nets (CTPNs) in the proposed knowledge-based process family planning system. On top of the IP2S and CTPNs, XML-based knowledge representation is employed to alleviate the difficulties in modelling complex product and process family data and planning knowledge while enabling information exchange across different operating platforms. In addition, in accordance with the correspondence between PNs and knowledge-based systems, a mechanism is designed to cope with the generation of production rules, which model constraints.
Findings– The proposed system is able to automatically generate production processes for customized products. At a higher level, such production processes provide input (e.g. operations, machines) to downstream activities for planning process details to manufacture component parts or component assemblies.
Research limitations/implications– Traditional trial and error approaches to planning processes limit production performance improvement when companies need to timely produce diverse customized products. Knowledge-based systems should be developed to help companies better plan production processes based on the available manufacturing resources.
Originality/value– Unlike most reported studies addressing either detailed process planning or assembly planning for component parts or component assemblies, this study tackles process planning for final products, in attempting to maintain production efficiency from a holistic view.
KeywordsProduct family, Process family, Petri nets, Knowledge-based system, Process planning, Product planning
Paper typeResearch paper
1. Introduction
In traditional approaches to planning production processes, the decisions made on the adoption of machines, operations, and operations precedence are often subjective depending on the intuitions and experiences of individual planners (Huanget al., 2004;
Tonget al., 2004). Different planners have different levels of skills and knowledge and
The current issue and full text archive of this journal is available at www.emeraldinsight.com/1741-038X.htm
JMTM 24,2
174
Received 17 August 2011 Revised 7 November 2011 15 February 2012 Accepted 27 February 2012
Journal of Manufacturing Technology Management
Vol. 24 No. 2, 2013 pp. 174-196
qEmerald Group Publishing Limited 1741-038X
DOI 10.1108/17410381311292296
different perspectives on products, thus often suggesting different production processes for same products. As a result, the production processes planned in this manner lead to many avoidable production changeovers on shop floors (Zhang and Rodrigues, 2009).
When the manufacturing environment involves simple products or a limited number of very similar product variants, the traditional approaches may still be a viable option, as evidenced by mass production. However, when the manufacturing environment is characterized by fast changes in product design and production volume, the traditional approaches fall short to adapt companies to plan such production processes that can produce a large number of customized products while obtaining production efficiency of the cohort, instead of individuals (Lennartsonet al., 2010).
In response to the increasing changes in product design, order quantity, price, and delivery lead time, manufacturing companies strive to quickly develop families of customized products at low costs. In this regard, the traditional approaches cannot be adopted to plan production processes in product family-based production environments, as discussed above. Consequently, it underscores the importance in developing solutions to planning production processes for product families, termed as process family planning, to support companies to produce diverse products while utilizing the available manufacturing capabilities (Schierholt, 2001; Williamset al., 2007). A process family refers to the set of production processes to produce the set of customized products belonging to a family (Zhang, 2007; Jiaoet al., 2007b).
The large number of customized products in a family lead to many different designs of component parts and assemblies, each of which requires its own processes. In addition, the customized products are to be produced by different production processes despite the similarities among them. In this regard, process family planning involves diverse data pertaining to both the product family and the process family to be planned.
Moreover, product diversity and the finite manufacturing resources existing on shop floors result in complex planning knowledge, such as the interconnections between product and process data. Process family planning necessitates such planning knowledge. Consequently, a fundamental issue in process family planning relates to the modeling of data and knowledge concerned. In planning production processes, many constraints and restrictions need to be considered in order to obtain feasible solutions.
These constraints are associated with design specifications, manufacturing requirements, and manufacturing capabilities (Bengtssonet al., 2009). In the context of product family production, due to the finite manufacturing resources and the short delivery lead time, more constraints are involved (Zhang, 2007). Thus, constraint handling suggests itself as another important issue in process family planning.
In view of the above fundamental issues, this study puts forward a knowledge-based system, named knowledge-based process family planning system (KbPfPSys), to support the automatic generation of production processes for given product families. In the KbPfPSys, to model large volumes of data pertaining to product and process families and planning knowledge, the eXtensible Mark-up Language (XML) is adopted. Besides data and knowledge representation, another reason motivating us to use the XML lies in its capability to facilitate information exchange among multiple operating platforms, be they within or across companies. The XML has been adopted by many researchers to develop prototypes and systems for dealing with problems from different domains (Bowen and Sahin, 2010; Choiet al., 2004; Simovet al., 2004). While these systems address, at most, planning process details for component parts or assembly if they do, none of them
Process family planning
175
handles planning production processes for final products at a higher level. This study thus tries to fill this gap by introducing the XML-based KbPfPSys for process family planning automation. The foundation for the XML-based data and knowledge representation is based on the integrated product-process family structure (IP2S) and the colored timed Petri net (CTPN) model of process family planning in Jiaoet al.(2007a), Zhang (2007) and Zhang and Rodrigues (2010). While the IP2S is for organizing product and process family data, the CTPN model is for capturing the dynamics of process family planning. In other words, the IP2S represents the static structure of process family planning; the CTPN models represent the dynamic process. Furthermore, in view of the diverse interconnections among product and process data, a mechanism is designed to accommodate the generation of the corresponding production rules in the KbPfPSys.
These production rules essentially model constraints involved in process family planning. As a result, constraint handling is facilitated in the KbPfPSys. The rule generation mechanism is designed by taking advantage of the analogy between PNs and knowledge-based systems discussed in Righini (1990).
The rest of this paper is structured as follows. An overview of the KbPfPSys is presented in Section 2, following which Section 3 addresses the issues associated with system development. In view of their importance, we discuss in detail the XML-based knowledge representation and production rule generation in Section 4. We apply the prototypical system developed to the truck families from an automobile company, and present the results in Section 5. Concluding remarks and avenues for future research end this paper in Section 6.
2. Overview of KbPfPSys 2.1 System overview
As shown in Figure 1, the development of the KbPfPSys entails activities at two stages:
knowledge base construction and knowledge deployment. While knowledge base construction is to accumulate and analyze companies’ existing product and process data and information for building a knowledge base, knowledge deployment is to apply the knowledge base to support process family planning.
Knowledge base construction starts from the large volumes of product and process data available in companies’ legacy systems. Typical such systems include material requirements planning, enterprise resource planning (ERP), product data management, and manufacturing execution system (MES). The data are analyzed in line with the requirements of modeling formalisms of IP2S and CTPNs. Moreover, the data and information about product hierarchies and routings of production processes are integrated and correlated with the elements of CTPNs. Subsequently, the characteristics of production processes are analyzed, contributing to production rule generation. The activities in knowledge base construction rely on a combined effort of experts having the knowledge of process planning and knowledge engineers possessing the capacity of model building. On one hand, involving both domain experts and knowledge engineers may incur certain investments; on the other hand, codifying the expertise in one knowledge base allows multiple people to access the required knowledge. It also enables to objectively plan process families with enhanced efficiency and consistency.
In the knowledge deployment stage, the KbPfPSys facilitates such planning activities as task description, plan/reasoning engine execution, and planning result presentation shown in Figure 1. Process planning is initiated in task description with given
JMTM 24,2
176
specifications of a product family or family members (for illustrative simplicity,
“specifications of a product family” instead of “specifications of a product family or family members” is used throughout the rest of the paper). Such specifications are associated with component items, parent-child relationships, quantity pers of component items, mapping relationships between component items and process elements, and manufacturing resources (e.g. machines, tools, fixtures). For a given product family, the production processes are automatically generated in plan execution. To achieve such automatic generation, plan execution thus involves the reasoning logic in accordance with the CTPNs and production rules. It addresses the determination of sub-manufacturing (or assembly) processes for component parts (or assemblies), the specification of operations and operations precedence, and the selection of manufacturing resources.
Finally, the production processes are presented. To enable a better understanding of the production processes from different aspects, several display formats, including Gantt chart, load capacity chart, and master report, are adopted.
To benefit from the past planning problem solving, the decision-making processes involved in knowledge deployment are recorded in a design history. The design history can be utilized to provide feedbacks to the knowledge base and its construction. If a planning task is successfully accomplished, all information involved in the decision-making process is stored as a record in the knowledge base. A user can retrieve the entire record or a part of it (e.g. the CTPN model, the set of production rules), and apply it to a similar planning task. Depending on the failure reasons, an unsuccessful
Figure 1.
An overview of the KbPfPSys
ERP MES
Raw data (products/processes) IP2S & CTPN
formalisms
Knowledge base construtionKnowledge deployment
Mechanisms of production rule
generation Expert
Knowledge base
(Structured knowledge about products/processes) Knowledge-
based planning Specifications of
product & process families
Production processes
Design history Description
Execution
Presentation Production planner
Process family planning
177
case may also provide feedbacks to knowledge base construction, in attempting to improve the formalisms of IP2S or CTPNs and the mechanism of production rule generation.
2.2 Functional modules of the KbPfPSys
The KbPfPSys has several functional modules, and accordingly performs a number of major functionalities, including visualization, modeling, and planning of product and process families (Figure 2). In the figure, the IDEF0 (integrated definition 0) is adopted to represent the inputs, outputs, support mechanisms, and controls of each functional module and relationships among functional modules (the readers may refer to www.
idef.com for the details of the IDEF0 as a modeling tool).
In practice, production planners are interested in viewing product and process data for initial knowledge and an overall picture. Thus, the first functional module – visualization of product and process families – attempts to accommodate the representation of data and information about families of products and production processes. The inputs of this module include large volumes of raw data existing in companies’ databases. In addition, it contributes to visualization of the outputs of the second functional module – the IP2S and CTPNs – as a result of product and process family modeling. While data pertaining to products take the form of bills of materials (BOMs), data relevant to production processes take the form of bills of operations (BOOs). As with a BOM representing component items and their parent-child relationships, a BOO is used to model both operations included in a production process and operations precedence. It is imperative to visualize data in an intuitive way so as to enable planners to easily comprehend the large amount of data and the diverse relationships among them. Therefore, in this study, both BOMs and BOOs are represented as trees, showing the compositional hierarchies of family members and routings of the corresponding production processes, respectively.
The output of the visualization module is well-structured product and process family data.
It works under the control of the access rights of different users and the display formats.
Figure 2.
Functional modules of the KbPfP
1 Visualization
2 Modeling
3 Planning Product &
process families
IP2S CTPNs BOMs & BOOs
Access rights
Display formats
IP2S
formalism CTPN
formalism
Rule generation mechanism
Production planners
Domain experts
Production processes Product
specifications Performance
criteria Request for new models
JMTM 24,2
178
The product and process family data organized above becomes input to the second module, modeling of product and process families. This module works under the control of the IP2S and CTPN formalisms. As supporting mechanisms, production planners and domain experts organize the data as the IP2S and CTPN models based on the corresponding formalisms. The outputs – IP2S and CTPNs – are stored in a database and can be visualized by users given their access right. In the last functional module:
planning of process families, the inputs are the specifications of a product family and the CTPNs from the previous stage. The outputs are the production processes to produce the given product family and/or the request for a new CTPN model. In the planning process, production planners may get involved to make decisions based on different performance criteria and rule generation mechanism (Section 4.3). Furthermore, in this module, production rules (i.e. “If-Then” rules) are automatically generated from the CTPN models based on the rule generation mechanism. These rules are used to specify output items for given input items. They also contribute to identifying possible machines and to determining the suitable one from multiple alternatives. Based on the production rules, production processes are generated in accordance with the specifications of a product family, and are evaluated against predefined performance criteria.
As the core functional module, planning of process families encompasses a number of steps contributing to the automatic generation of a process family for a given product family (Figure 3). Similarly, the IDEF0 is used to represent these major steps and their interconnections. The input to process family planning is product family specifications and CTPN models stored in the database. First, these specifications are used as criteria to search the CTPN model corresponding to the product family.
If the CTPN model exists, it is loaded to the server; otherwise, it indicates that the given products belong to a new family and that a new CTPN model has to be created.
The CTPN loaded to the server is initialized with respect to a set of parameters.
Figure 3.
Process family planning in the KbPfPSys 3.1
Search CTPNs
3.2 Load CTPN Models
3.3 Generate Production
Rules
3.4 Plan &
Evaluate Prodcution
Processes Product
specifications Stored CTPNs
Performance criteria Rule
generation mechanism Initialize
Search criteria
CTPNs
CTPNs
Production rules
Production planners Request for new models
Production processes
Process family planning
179
Production rules are subsequently generated by following the rule generation mechanisms. These rules are then used to carry out a series of “what-if” analysis, resulting in specific production processes.
3. System development 3.1 System architecture
To develop the proposed KbPfPSys, the typical three tier architecture is adopted.
As shown in Figure 4, the three tiers include:
(1) a data tier hosting various databases;
(2) a graphical user interface (GUI) tier capturing input data and presenting production processes generated; and
(3) the application tier governing the business logic.
The data tier has three main databases, including a product/process database storing the IP2Ss, a CTPN component database keeping modular components of CTPNs and a database containing complete CTPN models in relation to product and process families, and a database for storing production rules. These databases are knowledge intensive and
Figure 4.
The architecture of KbPfPSys
Graphical User Interface
Administration Browsing Modeling Planning
TCP/IP & SOAP Integrated Application Server
Accessibility maintenance
Input/Output
CTPN model Creation
Process Plan Generation
Rule Generation CTPN model
Retrieval Rule
Execution Engine
Rule Generation
Engine Inference Engine
Product/Proc ess Database
(IP2S)
CTPN Model Database
CTPN Component
Database JDBC/SQL
Cache
Production Rules (Knowledge Base)
UI TierApplication TierData Tier
JMTM 24,2
180
collectively constitute the knowledge base. In this study, Oracle 10, which is a relational database, is adopted to implement the data tier. The processes controlled by the integrated application server trigger the Structured Query Language commands to retrieve data through standard Java Database Connectivity ( JDBC) connection. The application tier handles the business logic and security (e.g. user authentication and access levels), thus offering a set of services that can be accessed from the GUI and external applications. It calls procedures and transactions, such as CTPN creation, production rule generation, and production process generation. Furthermore, it communicates with backend databases using JDBC. While implementation of business processes is accommodated by the integrated application server at the application tier, basic input and output operations are dealt with at the user interface. The GUI connects with the application tier through the standard Transmission Control Protocol/Internet Protocol (TCP/IP) Port 80 and uses Simple Object Access Protocol messages in communication.
3.2 Data maintenance
In the data tier, the product and process families are represented as records of IP2Ss.
Each record is related to a distinct XML-format dataset. The header of the dataset describes the basic characteristics of the product and process families, serving as the searching index and the entry point. The CTPN model database contains a set of data tables storing the CTPNs and their elements. Similarly, the CTPN table contains the CTPN models in the data table in the format of XML dataset. In addition to the CTPN model database, a CTPN component database is developed for modular CTPN components or small scale PN models. These PN components are the building blocks for constructing new, large-scale CTPNs. Such a mechanism will ease a designer’s modeling efforts because he does not have to start from scratch when designing new PN models.
3.3 Business processes
The business processes of the system are implemented by several modules in the application tier, as shown in Figure 4. At the top level, the integrated application server wraps up these modules and manages the connections among them. It first accepts requests from the GUI tier, then dispatches the accepted requests to the relevant modules, and last activates the relevant reasoning engines. Among all processes, there are several basic types, namely accessibility maintenance, data input/output, and CTPN model creation. The accessibility maintenance module governs the administrative aspect of data access (e.g. ownership, access right, data backup). The data input and output module provides such services as retrieval, visualization, and storage of data and CTPN components (or complete CTPN models). The CTPN creation module facilitates modeling of CTPNs of process families. It defines a suite of functions supporting model creation operations, such as addition and deletion of places, transitions, and arcs, addition and deletion of colors, modification of PN component properties, and consistence check.
In addition to the basic business processes, there are several advanced processes, including CTPN retrieval, production rule generation, and production process generation.
Unlike the basic ones, these advanced processes are knowledge intensive. They are supported by the rule generation engine and rule execution engine, which collectively play a similar role of the inference engine in a knowledge-based system.
Process family planning
181
3.3.1 CTPN retrieval. In planning production processes for a given product family, the CTPN retrieval module is activated first. As shown in Figure 5, the input product specifications may relate to product functions, product structures, and quantity pers.
Based on his knowledge about the given product family, a user may choose to manually retrieve the relevant CTPN model or use the key word search method. A manual retrieval is applicable when the user has certain knowledge about production processes of the product family. In this case, he can select a CTPN model from the list of candidates in the CTPN database. A key word search is necessary when the user is unfamiliar with the production processes, and thus is unable to directly select an appropriate CTPN model. In such a situation, the user is prompt to select a set of search criteria with respect to the input product specifications. The search criteria are basically key words associated with the product specifications, such as type of the product (e.g. steering wheel, cabinet) and key characteristics of the product (e.g. dimension, material). In accordance with these criteria, the retrieval module generates the query clauses that activate the search in the database, and retrieve the corresponding CTPN model.
3.3.2 Rule generation. The production rule generation module is responsible for transforming the CTPN models into executable production rules. The transformation is accomplished with the support of the rule generation engine by interpreting CTPN models retrieved. Given a CTPN model, the rule generation engine searches for the corresponding records of PN elements maintained in the respective data tables of Oracle 10. By following the rule generation mechanism, in accordance with each transition retrieved, production rules are generated by transforming:
. the expressions of input arcs into the left-hand-side (LHS) conditions; and
. the expressions of output arcs into the right-hand-side (RHS) consequences.
To capitalize on the advantage of Java: a platform-neutral programming language supporting rule-based systems (Gero, 1990; Sriram, 2002; Zha and Du, 2006), these production rules are written in XPath and embedded in data models.
3.3.3 Production process generation. The production process generation module is controlled by the rule execution engine in collaboration with the working memory (or the cache in Figure 4). The working memory contains a list of facts, which are either given facts of inputs or derived facts from an inference process. The production process generation involves a forward chaining procedural process. In the process, the facts in the working memory are first matched with the LHS conditions of the rule base. Based on the matching results, some rules are selected to fire. After firing the selected rules, new facts (i.e. RHS consequences) are created and the list of facts is updated.
In planning production processes, there are many alternative solutions when deciding on operations, operations precedence, and manufacturing resources. To determine the appropriate production processes, the production process generation module applies a selection mechanism to solve the conflicts resulting from the multiple
Figure 5.
CTPN retrieval process
Product family Specifications
x.1
Manual
Key Word Search Task list
JDBC Connection Prioritize
Query CTPN
Database
JMTM 24,2
182
alternatives when firing production rules. Moreover, it performs production rule simulation and evaluation by carrying out a series of “what-if” analysis. Such simulation and evaluation is in line with the input product specifications and planning requirements. And the analysis is controlled by a set of parameters corresponding to different priority schemes, such as the minimum number of changeovers, the minimum production lead times and costs, and the simplest manufacturing and assembly operations. Based on the analysis results, the production processes are determined.
3.4 Graphical user interface
In accordance with the functionalities of the KbPfPSys, the GUI tier is developed to facilitate system administration, information visualization, CTPN modeling, and process family planning. The browser provides an interface, through which existing data can be retrieved and visualized. The data are represented in different formats to provide multiple views and different granularities. Each format is supported by the corresponding mechanism. For example, the product and process data can be presented in either a tree format or a tabular format. While the former provides an intuitive overview of product and process hierarchies, the latter presents data details (e.g. items’ parameter values, manufacturing resources). The CTPN models can be visualized, created, and modified in an integrated interface shown in Figure 6. The elementary net elements, such as places, transitions, and arcs, are listed in the component pane. With these elements, the CTPNs are created in the drawing area with simple “drag-and-drop” operations. In addition to these elementary net elements, there are two elements, layer and import, contributing to the creation of CTPNs. The “layer” element allows the definition of CTPN hierarchy by organizing net elements into different levels in accordance with the positions of related items in the product hierarchy. Figure 6 shows a CTPN with two layers, where the lower-layer net being a colored token nested in the buffer places (p6) in the higher-level layer. The “import” element provides a mechanism to browse and import existing
Figure 6.
The interface for CTPN creation and visualization Component
pane
Attribute- value pane
Drawing area
Process family planning
183
sub-structures of CTPNs stored in the CTPN component database. The imported structure can be incorporated with the current model, thus alleviating the effort of model creation. The detailed properties of CTPN components are specified in the attribute-value pane. With his accessing right, a user may modify these properties of CTPN components.
In regard to production process generation, an interface is developed for users to specify parameters for rule generation and execution. As with the display of product and process data, the production processes generated are displayed in different formats (e.g. Gantt chart, bar chart). In addition, an administration interface is developed to facilitate the maintenance of user profiles and data accessibility.
4. Knowledge representation and processing
The importance of knowledge representation in knowledge-based systems has been reported (Mannistoet al., 1996; Zhanget al., 2005). Due to the involvement of large volumes of product and process family data and their complex relationships, the KbPfPSys is knowledge intensive. Thus, among all issues in system development, we focus on the representation of knowledge about process family planning. In addition, we discuss the mechanism developed for generating production rules. Such mechanism aims at improving efficiency and accuracy in developing and editing rules.
The knowledge involved in process family planning can be classified into two types.
Pertaining to product and process families, knowledge of the first type is organized into the IP2S. Contributing to process family planning, knowledge of the second type is structured as CTPNs. In view of the significance of the XML in dealing with the exchange and interoperability of complex knowledge structure, we adopt the XML to represent the IP2S and CTPNs.
4.1 Representation of IP2S
The XML schema is designed to represent the IP2S of a product family and the corresponding process family, thus assuming a hierarchical structure. It defines the building blocks of an XML document and a list of legal elements and attributes describing product items and operations in the IP2S of a product family.
Figure 7 shows the generic schema for the IP2S. In the scheme, elements are located at three levels. The top-level element is a product-process family (i.e. a product family and the corresponding process family). A product-process family is defined by a set of attributes, such as the product family code, the process family code, and the product order ID. In the second level, a BOM element describing product data and a process element modeling process data are located. In the third level, an item type is nested in the BOM element. And an operation element is defined under the process element. The type of an item that belongs to the BOM is either a part or an assembly. Each item is associated with a number indicating the quantity per as required by its immediate parent item. An operation element contains reference handlers to the corresponding item elements. In the figure, the attributes of elements can be either compulsory (e.g. the ID of an element) indicated by boxes with solid lines or optional (e.g. the description of an element) denoted by boxes with dashed lines.
The generic schema can be instantiated by specifying values of attributes of items in consideration. The instantiation produces process variants to fulfill given products.
For example, Figure 8 shows a part of a process variant derived from the IP2S schema of the corresponding product family. Two items, a steering wheel and an audio system
JMTM 24,2
184
package, are described. They are purchased material items of a truck cabinet, which has a BOM ID: 320. Both items are installed in the final process to assemble the truck cabinet.
For installing these two items, two assembly operations with IDs 0520-002 and 0520-003 are derived. Also derived are operations time, setup time, machine, and tool.
Figure 7.
The data structure of product and process family
Process family planning
185
4.2 Representation of CTPNs
Similar to the representation of the IP2S, the data structure of CTPNs and the corresponding XML schema are shown in Figure 9. A CTPN model consists of three element types, including places, transitions, and arcs. Each element has an ID, a name, and a description explaining its characteristics. Unlike IDs and names, element descriptions are optional. A place element is one of the four alternative types, including buffer places, item places, machine places, and generic machine places. In addition, a place is assigned to a set of color types, each of which refers to a set of colored tokens residing in the place. Each colored token is associated with an integer value indicating the total number of that token. A transition can be classified as one of three types: logical, reconfigurable, and timed transitions. For a timed transition, a time interval is assigned to specify the duration of the operation related to the transition. Both places and transitions are associated with input and output references, which represent the arcs connecting to them. As shown in the figure, these references are optional because the connections are explicitly defined by the attributes of arcs. If the input and output arc references present in a place or a transition, they are for the purpose of readability. An arc belongs to one of two types: normal and inhibitor arcs. As with a place, an arc is associated with a set of colors.
Based on this schema, Figure 10 shows a part of the CTPN in XML. The CTPN has a machine place that holds a token representing machinem1and an item place that hold a token modeling framef1. The places are connected to a timed transition, which represents an assembly operation included in the process to assemble the suspension system.
4.3 Production rule generation
As with any knowledge-based system, production rules are stored in the knowledge base. They play a major role in generating complete production processes for given product families. By following the consensus in the literature, we call the premise (or the antecedent part) of a rule the LHS and the conclusions (or the consequent part) the RHS.
By taking advantage of the analogy between PNs and production rule systems, production rules are generated based on CTPNs in the CTPN model database. For each Figure 8.
Generation of a process variant from the IP2S schema in Figure 7
JMTM 24,2
186
transition in a CTPN, there is a production rule generated. Three types of rules – machine selection rules, item specification rules, and operations execution rules – are defined, corresponding to three types of transitions: reconfigurable, logical, and timed transitions, respectively. Item specification rules determine the types (or families) of output items
Figure 9.
The data structure of CTPNs in the XML schema
Process family planning
187
to be produced for given input item families. They also determine the possible machines that can work on input item families to produce output item families. For given input items, machine selection rules specify machines to be adopted and their next available time. For given input items and machines, operations execution rules define operations to be performed, cycle times to be incurred, and output items to be produced. In line with the hierarchical nature of process family planning, these rules are organized into groups, each of which is responsible for specifying process elements for an item family. Thus, with the parent-child relationships among item families, these rule groups form multiple chains with each corresponding to one path of the IP2S, starting from the root node representing the final product family to a leaf node denoting a family of purchased components or raw materials.
The LHS and RHS of rules are generated based on the colored types of input and output places in general, and according to the following steps in particular.
Item specification rules:
(1) associate the material items in the LHS to the color types of the input buffer places of each logical transition;
(2) associate the output item family in the RHS to the color type of the output item place of each logical transition; and
(3) associate the possible machines to be adopted in the RHS to the color types of the input generic machine place of each logical transition.
Each item specification rule has the following format (in the natural language):
“IF material item a1is of type A AND material item b1is of type B, THEN the output item family is of type AB AND the set of machines to be adopted is m1and m2”.
Operations execution rules:
(1) associate the material items and machine in the LHS to the color types of the input buffer places and the input generic machine place of the logical transition of each timed transition;
(2) associate the output items in the RHS to the color type of the input item place of each timed transition;
(3) add the operation in relation to each machine in the RHS; and (4) add the corresponding operations cycle times in the RHS.
Figure 10.
An example of a CTPN generated from the schema in Figure 9
JMTM 24,2
188
While one rule is generated for each logical transition, multiple rules are generated for each timed transition. The general format of operations execution rules is as follows:
“IF material item of type A is a1AND material item of type B is b1AND machine m1is adopted, THEN output item to be produced is ab1AND operation to be adopted is O1
AND cycle time to be incurred is five time units”.
Machine selection rules:
(1) associate the material items in the LHS to the color types of the corresponding input buffer places of each reconfigurable transition;
(2) associate the machine in the LHS to the color type of the input machine place of each reconfigurable transition;
(3) associate the machine to be adopted in the RHS to the color type of the output generic machine place of each reconfigurable transition; and
(4) add the next available time of the machine adopted according to the cycle time and the current time in the RHS.
The general format of machine selection rules is as follows: “IF material item of type A is a1AND material item of type B is b1AND machine m1is available AND machine m2
is unavailable, THEN machine to be adopted is m1AND next available time of m1is current timeþcycle time”.
By considering the similarity inherent in the generation of three types of rules, we use an example to explain item specification rule generation. For transition t1in Figure 11(a), in accordance with the expression of arc (t1, p3), two rules shown in Figure 11(b) can be generated. Rule 53 can be interpreted as: “IF material item a1is of type A AND material item b1is of type B, THEN the output item family is of type AB AND the set of machines to be adopted is m1and m2”.
In addition to the above rules, another class of rules, termed as meta-rules, are developed to resolve conflicts (i.e. to decide on which rule to fire first) when conditions of multiple rules are simultaneously satisfied. The following criteria are employed in developing meta-rules when the optimal production processes are desired:
Figure 11.
Rule generation from a CTPN
(a) (b)
Process family planning
189
. minimum number of changeovers (reflected by the changes of manufacturing resources and operations);
. minimum production lead times and costs; and
. simplest manufacturing/assembly operations.
Rules for evaluating the performance of formed production processes with respect to lead times and costs are also developed and incorporated into the knowledge bases. An example is as follows: “IF lead time of producing an item x using process y is longer than an allowed time value, THEN process y is denied”.
5. Prototype application
A prototypical system has been developed, and is applied to production process planning for a truck family in a multinational automobile company (due to the company’s concern, its real name is not given). The diverse requirements from customers lead to a large variety of trucks to be designed and produced. In spite of the fact that the company uses product platforms to specify trucks for meeting diverse customer requirements, its production on the shop floor involves many avoidable and unnecessary changeovers because of the subjective planning practice.
Existing product and process data are analyzed a priori, resulting in the IP2Ss of truck families. Figure 12 shows the IP2S of the track family that is adopted in this case application (note, for both confidential purpose and illustrative simplicity, the data used throughout this case application is codified based on original ones). As shown in the
Figure 12.
The IP2S of the truck family
Truck Chassis
Qch
Wheel set
Qws
Cabinet
Qca
Power train
Suspension
Qsu
Engine
Qe
Gear box Frame
Qf
Front axle
Qfa
Rear axle Tire
Qt
Qrm Rim Body
Qbd
Qid
Audio package Qap
Interior decoration
Office package
Resting
package Radio
CD player
Qcd Qr
Speaker
Qs Qop
APap APca
APpt
APsp APcs
APfw APta
Legend:
Operation sequence
Operation Item
Qrp
Qpt
Qgb
Qra
JMTM 24,2
190
figure, product items of this truck family are arranged in a hierarchical structure. Each item has a quantity per (Qxy), representing the unit number required by the parent item at the immediate higher level. The material items are the inputs to assembly processes (denoted by circles). Each such process involves one or more than one assembly operations. For example, the assembly process APcs forming chassis has one assembly operation; the final assembly process APta involves two assembly operations.
Similarly, based on the analysis, the CTPN model of the truck family is constructed shown in Figure 13. The CTPN model has multiple levels in accordance with the truck family’s product hierarchy, thus capturing trucks’ production processes at different granularity levels. The net in the top-level models the final assembly process (i.e. the APta in Figure 12) to produce trucks. It has two timed transitions, t2and t6, representing the two assembly operations involved. The material items of the first assembly operation represented by transition t2are variants of cabinet and chassis modeled by colored tokens residing in buffer places p1and p2, respectively. The output item is the work-in-process sub-assembly of cabinet-chassis (ccassy) represented by colored tokens residing in place p7. The variants ofccassyand these of the wheel set represented by colored tokens residing in place p8 are the material items of the second assembly operation represented by transition t6. Two alternative sets of manufacturing resources are able to perform the first assembly operation. They are modeled by the two machine places, p14and p15. Similarly, places p10and p11are used to represent two alternative sets of resources carrying out the second assembly operation.
The colored tokens residing in places p1, p2, and p8are themselves CTPNs at the second level, as shown in the figure. These CTPNs represent the three assembly processes – APca, APcs, and APfw in Figure 12 – to produce the variants of cabinet, chassis, and wheel set, respectively. The explanation of the nested CTPNs and these at the following lower levels is the same as that of the CTPN at the top level.
While the generic routing embedded in the CTPN hierarchy is assumed by all production processes of existing and new trucks of this family, the specific production process of each truck can be obtained according to the given input product specifications.
Figure 13.
The CTPN model of process family planning for the truck family
Process family planning
191
To enable the automatic generation of production processes, the transitions of the CTPN model are transformed into production rules. The consistency and correlation of these rules are examined and confirmed by the company’s production planners. Figure 14 shows the interface of production rule generation and some rule examples in the bottom right part. The upper right part of the interface is the rule editing pane. Upon the selection of a transition in the CTPN, the content of a rule editing pane is updated. The
“level” indicates the position of the transition in the CTPN hierarchy. For instance,
“level 2” in the figure shows the transition in consideration is in a net at the second level of the CTPN hierarchy. The “status” is a switch allowing the user to manually turn the transition into an active or inactive mode. An inactive transition is not editable and cannot trigger a production rule. Such a mechanism is useful for debugging the rule generation process. The “product” indicates the output item of the transition. The
“approved” label shows the approval status of the rule. In this case application, a senior production planner determines whether or not a rule has been approved. The content of
“IF” and “THEN” clauses are automatically loaded with data associated with the transition. The user may choose to accept the data and generate a rule by clicking on the
“Add rule” button. In addition to generating rules based on CTPN models, the prototype allows a user to modify rules by editing the content of “IF” conditions and “THEN”
consequences.
For several trucks, given their specifications indicated in the corresponding customer orders, their production processes are generated. Along with production processes, production schedules and the status of manufacturing resources are generated as well (Figure 15). The operation order pane lists the sequence of individual operations, which are indexed by their work orders. The list also includes the product family in consideration, items, quantity pers of items, machines used, starting and completion time of operations.
To estimate the effectiveness of the KbPfPSys in relation to the company’s practice, performance evaluation of production processes obtained from two ways is conducted.
Figure 14.
Some examples of production rules generated
JMTM 24,2
192
Two key performance indicators, production lead time and machine utilization, are used.
In the evaluation, production processes for given customized trucks are first planned by two groups with each having three planners. The planners in group A obtain the production processes solely based on their personal skills and experiences. They do not follow systematic planning approaches and explicitly organized planning knowledge (as a matter of fact, such planning approaches and knowledge are not available in the case company, as mentioned earlier). The planners in group B use the prototypical system to generate the same number of production processes. The production processes from the two groups are further simulated using simulation software: Flexim (www.flexsim.com/).
The two performance indicators are calculated based on the simulation. Figure 16 shows a screenshot of the simulation.
The simulation result shows that the average lead times of the production processes from groups A and B are 4.1 weeks and 3.6 weeks, respectively. In this regard, the prototypical system achieves 12.2 percent reduction of production lead time. Average machine utilizations are 34.5 and 44.7 percent corresponding to production processes from groups A and B, respectively, (note, due to the high product variety, machine utilization is relatively low in both cases). Similarly, the prototypical system increases machine utilization by 26.9 percent. In accordance with these comparisons, the KbPfPSys is able to help planners plan such production processes than can avoid unnecessary changeovers in production and to identify the optimal routings from a large set of options.
It should be noted that the simulation model is just a simplified replication of the actual production system. Therefore, the statistics obtained from the analysis may not exactly reflect the system performance. However, from the example, it has proven that for a given product family, the KbPfPSys can generate optimal production processes that contribute to the efficiency of product family production.
Figure 15.
Production processes generated
Process family planning
193
6. Conclusions
In this study, we proposed a KbPfPSys to support the automatic generation of production processes for given product family members. System development is discussed with respect to system functions, databases, user interfaces, and business processes. Also discussed are data and knowledge representation and production rule generation. In the system, the XML is adopted to model the product and process family data and knowledge that are organized as the integrated product-process structure. Thus, the XML-based knowledge representation alleviates the difficulties in modeling complex product and process family data and planning knowledge while enabling information exchange across different platforms. To ease constraint handling by improving the efficiency and accuracy of developing and editing rules, the production rule generation mechanism is developed by considering the analogy between PNs and KBSs. Based on the rule generation mechanism, production rules are generated for given input product specifications. Subsequently, production processes are obtained by executing production rules. The prototype developed has been applied to plan production processes of a truck family in an automobile company. The application results in terms of production processes generated, capacity load chart, and production schedules have demonstrated the potential of the KbPfPSys to help companies objectively plan production processes to achieve product family production efficiency.
Two types of important technical data in product development are organized into BOMs and production processes. The importance of automatically generating both BOMs and production processes has been recognized (Salvador and Forza, 2004;
Steger-Jensen and Svensson, 2004). While the KbPfPSys contributes to planning production processes for product families, it leaves the generation of BOMs untouched.
In view of this limitation, an avenue for future research may be directed to extend the Figure 16.
Simulation results of the production processes generated
JMTM 24,2
194
KbPfPSys so that it can generate both BOMs and production processes for given customer orders. This type of advanced production engineering feature would be practical for future MES and ERP software packages. While in practice, it is true that some companies (e.g. car assemblers, computer assemblers) adopt an assembly-to-order strategy to produce final products, many companies carry out both manufacturing operations to fabricate component parts and assembly operations to assemble component assemblies and final products. In this study, the prototype application considers the assembly operations to produce truck families. In this regard, the possible future research may develop a comprehensive case study where both manufacturing processes of component parts and assembly processes of component assemblies and final products are involved.
References
Bengtsson, K., Lennartson, B. and Yuan, C. (2009), “The origin of operations: interactions between the product and the manufacturing automation control system”,Proceedings of IFAC Symposium on Information Control Problems in Manufacturing, Moscow, Russia, June.
Bowen, R.M. and Sahin, F. (2010), “A net-centric XML based system of systems architecture for human tracking”,Proceedings of the 5th International Conference on System of Systems Engineering, Loughborough, UK, June.
Choi, M.-J., Choi, H.-M., Hong, J. and Ju, H.-T. (2004), “XML-based configuration management for IP network devices”,IEEE Communications Magazine, Vol. 42 No. 7, pp. 84-91.
Gero, J.S. (1990),Knowledge-based Design Systems, Addison-Wesley, Reading, MA.
Huang, S.H., Liu, Q. and Musa, R. (2004), “Tolerance-based process plan evaluation using Monte Carlo simulation”,International Journal of Production Research, Vol. 42 No. 23, pp. 4871-91.
Jiao, J., Zhang, L. and Pokharel, S. (2007a), “Process platform planning for variety coordination from design to production in mass customization manufacturing”,IEEE Transactions on Engineering Management, Vol. 54 No. 1, pp. 112-29.
Jiao, J., Zhang, L., Pokharel, S. and He, Z. (2007b), “Identifying generic routings for product families in mass customization production based on text mining and tree matching”, Decision Support Systems, Vol. 43 No. 3, pp. 866-83.
Lennartson, B., Bengtsson, K., Yuan, C., Andersson, K., Fabian, M., Falkman, P. and Akesson, K.
(2010), “Sequence planning for integrated product, process and automation design”,IEEE Transaction on Automation Science and Engineering, Vol. 7 No. 4, pp. 791-802.
Mannisto, T., Peltonen, H. and Sulonen, R. (1996), “View to product configuration knowledge modeling and evolution”, Proceedings of the AAAI 1996 Fall Symposium on Configuration, 9-11 November, MIT, Cambridge, MA, pp. 111-18.
Righini, G. (1990), “FIRST: a Petri net-based system for simulation of complex distributed manufacturing systems”,Computer Integrated Manufacturing Systems, Vol. 3 No. 4, pp. 252-63.
Salvador, F. and Forza, C. (2004), “Configuring products to address the customization-responsiveness squeeze: a survey of management issues and opportunities”,International Journal of Production Economics, Vol. 91, pp. 273-91.
Schierholt, K. (2001), “Process configuration: combining the principles of product configuration and process planning”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing, Vol. 15 No. 5, pp. 411-24.
Simov, K., Simov, A., Ganew, H., Ivanova, K. and Grigorov, I. (2004), “The CLaRK system:
XML-based corpora development system for rapid prototyping”,Proceedings of the 4th International Conference on Language Resources and Evaluation, Lisbon, Portugal, May.
Process family planning
195
Sriram, R.D. (2002), Distributed and Integrated Collaborative Engineering Design, Sarven Publishers, Glenwood, MD.
Steger-Jensen, K. and Svensson, C. (2004), “Issues of mass customization and supporting IT-solutions”,Computers in Industry, Vol. 54, pp. 83-103.
Tong, K.W., Kwong, C.K. and Yu, K.M. (2004), “Intelligent process design system for the transfer molding of electronic packages”,International Journal of Production Research, Vol. 42 No. 10, pp. 1911-31.
Williams, C.B., Allen, J.K., Rosen, D.W. and Mistree, F. (2007), “Designing platforms for customizable products and processes in markets of non-uniform demand”, Concurrent Engineering: Research and Applications, Vol. 15 No. 2, pp. 201-16.
Zha, X.F. and Du, H. (2006), “Knowledge-intensive collaborative design modeling and support:
part II: system implementation and application”,Computers in Industry, Vol. 57, pp. 56-71.
Zhang, J., Wang, Q., Wan, L. and Zhong, Y. (2005), “Configuration-oriented product modeling and knowledge management for made-to-order manufacturing enterprises”, International Journal of Advanced Manufacturing Technology, Vol. 25, pp. 41-52.
Zhang, L. (2007), “Process platform-based production configuration for mass customization”, PhD dissertation, Nanyang Technological University, Singapore.
Zhang, L. and Rodrigues, B. (2009), “A tree unification approach to constructing generic processes”,IIE Transactions, Vol. 41 No. 10, pp. 916-29.
Zhang, L. and Rodrigues, B. (2010), “Nested colored timed Petri nets for production configuration of product families”, International Journal of Production Research, Vol. 48 No. 6, pp. 1805-33.
Corresponding author
Linda L. Zhang can be contacted at: l.zhang@ieseg.fr
JMTM 24,2
196
To purchase reprints of this article please e-mail:reprints@emeraldinsight.com Or visit our web site for further details:www.emeraldinsight.com/reprints
