Towards computer supported inclusion and integration of ... - CiteSeerX

Towards computer supported inclusion and integration of life cycle processes in product conceptualization based on the process tree Paper for ‘Automation in Construction’ by Wilhelm F. (Wilfred) van der Vegte, Jeroen P.W. Pulles, Joris S.M. Vergeest Keywords Product design, conceptual design, process modeling, life cycle representation, computer-aided design Abstract Development of computer support in design is showing several shifts in focus over the latest decades. This paper relates to the shifts from detail design to conceptualization, from artifact geometry definition only to the inclusion of process knowledge and from isolated aspects to integrated aspects. It discusses a possible solution for simultaneous consideration of life cycle process aspects during conceptual design using the process tree representation. Integrating process aspects can be considered a preparation for an integrated representation of artifact and process aspects to be used in an front-end environment for conventional CAD detailing systems

1 Introduction Currently, computer support in industrial design is particularly highly developed where artifact modeling during detail design is considered. Progress, although not equally advanced, has also been made in the fields of process modeling in the detailing stage and artifact modeling in conceptual design. Computer support for process modeling during conceptualization however, has been undervalued so far–especially where industrial product design is concerned. In order to incite developments in this direction, three issues should be considered: (1) extension of process modeling–which is already partly covered in detail design–into conceptual design; (2) integration of process description and artifact description; (3) integration of the various aspects of process description. Ad (1): A typical characteristic of conceptualization as opposed to detail design is that usually precise input during modeling is hardly possible. This problem has already been recognized in shape modeling for describing artifacts (Van Dijk 1995), where designers usually prefer to keep open the opportunity for changes at a later stage. The issue also applies to process considerations: when conceptualizing a product, the designer has a more general idea about the product-related processes than during detailing. He has some first ideas of how the product is going to be manufactured, how it is going to be used, how it is expected to behave etc., in other words, what the product’s so-called life cycle is going to be like. Anticipating during conceptual design, the designer might want to record, or to model, his preliminary decisions concerning such processes. All of this is particularly useful if the work that has been done during conceptual design–in both artifact and process modeling–can be conveyed to detail design, e.g. to an existing CAD system. Ad (2): Integration of process description with artifact description seems to be a logical proposition. Artifacts and processes obviously coexist: whereas an artifact and its geometry manifest themselves in space, processes–while related to the artifact–manifest themselves in time, more specifically as a change. Ad (3): CAD systems increasingly treat the various artifact-detailing aspects in an integrated way. Processes on the other hand, both in conceptual design and detailing, still only exist in isolated representations based on specific process knowledge related to sub-domains (Van der Vegte 2000). However, generally, a design concept, contrary to a detailed design, is not just a view but rather a totalistic notion.

Because of the achievements already obtained in detailed artifact modeling, an obvious approach for further integration is to relate each of the isolated process representations to the artifact representation. However, to avoid the inconvenience of fragmented views during conceptualization and to minimize translations and conversions, we propose to integrate the process representations first, then relate the integrated process representation to the integrated artifact representation. It is assumed that, both in conceptual and detailed modeling, this will also facilitate the eventual development of integrated Artifact Process Models as indicated in the illustration. Thus, we arrive at the issue we want to address in this paper: how can we integrate the description of processes from different parts of the life cycle in conceptual product modeling? In this article, the so-called process tree or life-cycle tree, which is a semi-structured checklist for requirements, is pushed forward as a possible treatment. The article focuses on application by designers or project managers in a product development environment, rather than on the theoretical foundations. We will propose an extended and more structured extension of the process tree to help designers overcome the current limitations in support for conceptual process modeling.

study present situation production

develop product

existing products competitors design product build prototype test prototype

find manufacturers production preparation production quality control packaging storage distribution

price fixing advertizing sales advising supplying purchasing

putting objects in cabinet

use

getting objects out of cabinet

cleaning

maintenance repair

transporting carrying placing open cabinet required shelves make accessible place objects close cabinet open cabinet required shelves make accessible close cabinet getting objects out of cabinet cleaning putting objects in cabinet inspect lubricate adjust demount replace parts mount

Figure 1 Process tree of a cabinet for elderly and physically challenged people, from Roozenburg (1995)

2 Process trees and similar conceptual process modeling techniques in literature To assess the current state of the art in life cycle trees, the following issues should be addressed: (1) What is a process tree currently used for? (2) What do the various process trees encountered have in common, what is represented in the process tree, and in what way are process trees related to processes? (3) Are there any similar representations that can also be used for modeling processes; what are the respective advantages and disadvantages compared to process trees and how can they provide inspiration for a better inclusion of process descriptions in conceptual design? 2.1 Current use of process trees Figure 1 shows an example of a process tree from Roozenburg (1995). As can be seen, it is a listing of items representing the various stages in the existence of a product. In industrial design, compilation of a process tree is often put forward as a means for generating a requirements listing. Usually, the field of application is the beginning of product development in industrial design, but it has been pushed forward for mechanical engineering purposes as well (Franke, 1975). Process trees are also frequently used as a guidance for the assessment of environmental impact (e.g. Kurakawa, 1996). Additionally, we mention process planning as one of the purposes of (partial) process

trees. For instance, similar trees are used in manufacturing and assembly planning or in methods anticipating the production process during design (e.g. Boothroyd 1994). 2.2 Analysis of common properties in process trees In literature, the following observations can be made concerning process trees: (i) they contain items in a hierarchical structure, (ii) items sharing the same ‘parent’ are listed chronologically; (iii) items are expressed in natural language rather than formal expressions or symbols (iv) items mostly describe some change taking place, rather than describing subsequent discrete states of something, and (v) this change takes a usually unspecified time span. Because of the change involved, we could say that process trees primarily represent processes. However, this is not applied consistently: the item ‘required shelves’ in figure 1 is not a process but a partial artifact description. In other examples, items like ‘product policy’ or ‘hygienics’ occur. These are certainly not processes – we would rather address them as ‘aspects’. As far as the items do represent processes, we can also specify observation (iii) more precisely by noting that the language describing the item (or process) nearly always includes a verb, like in figure 1 ‘develop’, ‘repair’ or ‘cleaning’. The items ‘production’ and ‘sales’ are nouns, but they can easily be replaced by the verbs ‘produce’ and ‘sell’ respectively. 2.3 Other process modeling representations Process trees are not unique in the use of hierarchy, chronological arrangement and natural language for process descriptions. Other more standardized process representations showing these characteristics to some extent, are function block diagrams in conceptual mechanical engineering (e.g. Pahl 1988) and IDEF0 information flow models found in business process modeling and systems engineering (Ross 1977, Marca 1987). Function block diagrams use blocks containing a partial natural sentence including a verb to describe the transformations to be performed by a technical system. The over-all transformation process is hierarchically decomposed into more concrete sub-processes. Because of the central role of transformations in this approach, processes are depicted as flows from block to block with each block transforming input into output. The methodology assumes a direct link from process to artifact: a sufficient solution for the intended artifact can be derived from the process representing the original need for transformation. Since the process represented in the function block model is an a-priori abstraction of the anticipated artifact, it is not possible to include life-cycle processes other than the transformations to be performed by the technical system. Another closely related problem is that function block modeling is inappropriate when the product–like the cabinet in the example–does not autonomously perform a transformation process. In fact, many products do not perform transformation processes, or not essentially, as Warell (1999) pointed out. IDEF0 information flow modeling is used for analysis and synthesis of ‘systems’ in general, as it is primarily used for understanding a system before its implementation is envisioned (Marca 1987). Again, blocks usually feature a partial natural sentence with a verb. But in IDEF0, the arrows representing the flow into and out of the blocks do not only represent input and output, but also a ‘mechanism’ making the performer of the process explicit and ‘controls’ dissociating the constraints on transformation functions from other input. These additions make the syntax of IDEF0 more generally applicable than the syntax of function blocks. Another important distinction is the absence of method to directly derive artifacts from the IDEF0 model. This is a disadvantage in product design.

2.4 Adaptation of the process tree for process modeling The literature survey shows that lifecycle trees offer a potentially promising starting point for integrated representation and modeling of product related processes. The quasi-natural language used for conceptualization of the elements in the tree makes it easy to create and edit a process tree and also facilitates communication about the product related processes. However, because of its lack of consistency and its limited expressiveness where dedicated process modeling is concerned, it will need some modifications. We will use the process tree as a starting point to include and integrate process descriptions in product conceptualization. We aim at a Life Cycle Process Model (LCPM) based on extending the naturallanguage based syntax of the process tree, making its constituents explicit and unambiguous. It should also allow a smooth transition from process to artifact as in function block modeling, yet for a broader range of artifacts. Because of the analogous use of elements from natural language in function block diagrams and IDEF0, interchangeability with these other modeling techniques will be kept in mind as well. 2.5 Requirements From the discussion in the previous sections, the following requirements can be gathered for the LCPM as a process tree based representation including and integrating process description: 1. The LCPM should be suitable for covering the description of processes from the entire lifecycle of a product; 2. A designer should be able to model and edit the LCPM in a practical way; 3. The LCPM should encourage or force the designer to make process knowledge explicit; 4. It should be possible to relate process descriptions directly or indirectly to an artifact model.

3 Conceptual solution: general content and structure of the life cycle process model For the contents and structure of the life-cycle we take the process tree as a starting point. In the LCPM, the ‘leaves’ in the process tree are named process knowledge carriers, which for short will be referred to as ‘carriers’. The structure of the LCPM is given by (A) the hierarchical decomposition or classification of the carriers and (B) their sequence. 3.1 contents of the life cycle tree For the content of the carriers we start with the conjecture that natural language and the presence of a Verb are basic elements. Revisiting the examples found in literature we will look for the appearance of other elements from the syntax of sentences in natural language. Considering Subject | Verb | Direct Object | Adverbial Phrase

(1)

the common syntax of an uncomplicated sentence in natural language (‘Subject’ and ‘Direct Object’ to be interpreted in a grammatical sense), with Subject | Verb

(2)

as the minimal form, it can directly be seen that in the example of figure 1 the Subject is always missing but that a Direct Object (e.g. ‘prototype’, ‘object’) and/or an adverbial phrase (‘out of cabinet’, ‘accessible’) is sometimes included. This observation could be made in every process tree we encountered in literature.

If we want to consider whether the syntactical elements from natural language as suggested in (1) are really useful for describing carriers, apparently the Subject needs attention first. It looks as if it is a questionable element, since although it is considered one of the primary constituents of a sentence in natural language, it is missing, not only in process trees but also in Function Block Modeling. This is not to say that there is no Subject: for every item it seems possible to unambiguously assign a Subject: ‘workshop builds prototype’, ‘end user puts objects in cabinet’, ‘cabinet makes [objects] accessible’. Note that the Verb is inflected to obtain natural language. Apparently, in the process trees observed the Subject is always (consciously or unconsciously) made implicit, although it is not constant and it is obviously possible to make it explicit. This is different in function block modeling, in which the Subject is implicit because it is constant, i.e. always the technical system. By making the Subject explicit we could use it for filtering out those processes which have the product itself as its Subject and which can therefore be treated the same way as is done in function block modeling. As a general rule for processes, it is suggested that the Subject should be mentioned if it is variable. For convenience, it can be agreed on that by default, the Subject is the same as that of the previous carrier or the parent carrier in the classification if it is omitted. The Verb is, like the Subject, one of the primary constituents of a sentence; it is also one of the primary means of expressing what is happening in a process. By grammatical definition, a verb is a word used to express an action or state of being. Generally, if a verb describes a process, it expresses some kind of action: the verb ‘to be’, for instance should not appear in a process description. The next constituent of (1) is the Direct Object. In everyday use, this is also called ‘object’, but to avoid confusion with ‘objects’ in programming, or with ‘artifacts’, we use the stricter grammatical term here. The Direct Object is transformed by The Subject carrying out the Verb. Intuitively, it is equivalent to the Input in function block modeling and IDEF0. In natural language, the difference or change between Input and Output is implicitly described in the Adverbial Phrase, for instance ‘User | sets | button | to “on” position’. Additionally, the Adverbial Phrase can contain conditional elements or prescripts, which are equivalent to the Controls in IDEF0: ‘according to drawing’ or ‘if power is on’. So for conformity we decompose the Adverbial Phrase into Change Descriptor | Control Descriptor to make the conditional elements explicit. 3.2 structure of the life cycle process model The carriers are subdivided hierarchically according to a decomposition of relevant life-cycle processes. For now, we assume that the decomposition can be provided by the human mind of the designer, but we should have in mind that a system of prescribed decomposition rules will benefit processing by a computer. For the highest decomposition level of carriers, the generic processes also frequently used in process trees may be used: production, distribution, use and disposal. The design or development process can be included in the highest level as well, as the predecessor of production. A carrier like ‘design process’ sometimes refers to only one process carried out once for all specimens or instances that will exist of a particular type of artifact. In other carriers, each instance has its own process. In design practice, usually an example process is envisioned as a generalized or idealized process valid for every single instance. As in the process tree, the highest level can be decomposed into sub-processes represented by more detailed carriers, together embodying all knowledge about their parent plus the knowledge about intermedi-

ate changes contributing to the change affected by the parent. This decomposition can be continued until a virtually arbitrary level of detail is obtained. It is expected that there is a relationship between the level of detail needed for the carriers and the level of detail needed in the artifact model. Carriers of the same hierarchical rank sharing the same parent are arranged, or at least listed, in a sequence. Like in the process tree, carriers should be listed chronologically, or if several sequences are possible, at least in a sequence which is chronologically plausible. Issues like overlapping, arbitrary or repetitive process sequences and are dealt with in the next section.

4 Further elaboration We conclude with some of the more interesting details of the LCPM: (1) internal relationships within carriers: between Subject, Direct Object, Verb and Change Descriptor; (2) additional internal properties: occurrence and modality; (3) relationships between carriers: parent-child and sequential relationships. 4.1 Internal relationships within carriers The internal relationships between the constituents of a carrier can be summarized as follows: The Verb is a choice from the methods available to the Subject that can be used to effectuate the change in the Direct Object as described by the Change Descriptor. The relationship between Direct Object and Change Descriptor is the most interesting, because it embodies the observable change. The Change Descriptor contains a new Direct Object (if the Direct Object is transformed into something else) or the state change of the Direct Object. Concerning state changes, ideally, the Change Descriptor should only contain the new state of the Direct Object, because the previous state of the Direct Object is likely to be the output of a preceding carrier. When defining an LCPM using natural language, it is not always obvious what the previous state of the Direct Object should be derived from. In a computer implementation, the software should be able to keep track of this, so that in the computer internal representation the Change Descriptor only has to contain the new state of the Direct Object. Both the Subject and the Direct Object contain one or more elements participating in the carrier. We consider these elements to be of the type ‘participant’. Both the Subject and the Direct Object can contain participants in the appearance of humans, artifacts, natural objects (e.g. raw materials) etc. Direct Objects can also contain participants in the appearance of information or energy. The Subject performs the process. Therefore, the Subject can only consist of one or more participants capable of performing something, as a combination or on its own. This can be a (part of) the artifact that is to be designed as well as something or someone else, such as the end-user, the index finger of the enduser, the company, the company worker and the drill, etc. Information and energy are considered to be incapable of performing a process; they can only be processed. The Direct Object, like the Subject, is not limited to consisting of only one participant. It may contain energy and/or information, e.g.: ‘the cutting tool, the tool path specification and the energy conducted by the shaft’. Note that, in IDEF0, an item called ‘tool path specification’ would probably considered to be a control element. Since, for the time being, the control descriptor is limited to temporal aspects, it is included in the Direct Object here. As indicated before, the Verb should express an action. In a system configuration inspired by function block modeling, a predefined set of 23 typically active verbs for technical systems can be used (Pahl 1988). Sometimes it is appropriate to compose the Verb from more than one actual verb, for instance ‘cut and polish’ or ‘join or mix’. In this case it is necessary that the verbs relate to all of the other constituents of the carrier. Generally, this type of carrier can be decomposed into carriers containing the separate verbs.

4.2 Occurrence and modality There are two other, closely connected, items often taken into account when the contents of the life cycle process are considered: (a) the occurrence: how often will a carrier occur, either exactly, approximately, as a maximum or as a minimum and (b) the modality of the carriers: Will it occur anyway, should it occur or should it not occur? The occurrence and modality can be combined in an addition to the sentence elements in some form like [should/will/should and will] [occur] [minimally] [exactly/approximately] [n] [times] [and] [maximally] [exactly/approximately] [m] [times] with m • n • 0, where n = m is the special case in which there is no need for specifying a range. This is the default in case m is not specified. Examples of occurrence specifications for figure 1 could be: ‘The carrier take objects should occur minimally exactly 0 times and maximally approximately 50,000 times (in the life of a cabinet)’; ‘The carrier price fixing should occur exactly 1 time’, the carrier production should occur minimally exactly 10,000 times and maximally approximately 100,000 times (i.e. to produce between 10,000 and 100,000 cabinets). Events to be avoided are added using carriers in the form ‘The carrier protruding piece of the door of the cabinet hurts user should happen minimally exactly 0 times and maximally exactly 0 times’ (i.e. it should not happen). Carriers that should occur are related to processes that are planned by the designer, and for which it is not yet known how they are to be accomplished. Carriers that will occur anyway are related to the kind of processes that are predicted rather than planned and of which it is not yet known if they should or should not occur. Yet this kind of processes can be envisioned during conceptual design, so that they will be included in the LCPM. Results of simulations also belong in this category if their significance is not yet known. Carriers that should and will occur have been taken care of, i.e. if they should happen (m > 0), it is known how they are accomplished; if they should not happen (m = n = 0), it is known how they are prevented or avoided. During the design project, the share of ‘should and will’ carriers increases until, ideally, it eventually reaches 100%. As a matter of course, this status will not be reached during concept design. Therefore, it is required that editing of the LCPM can be continued during detail design. 4.3 Relationships between carriers Between carriers, parent-child relations and sequential relations are defined. The parent-child relationships between carriers are embodied in a classification. The relations are of the type ‘has a class’ and ‘has a specific’. ‘Has a class’ indicates the relation which the more specific processes have with their abstract process. Expressed in terms of the process tree in figure 1, ‘lubricate’ is a specific process inside the ‘maintenance’ process, hence ‘lubricate’ has the ‘has a class’ ‘maintenance’. From the point of view of the ‘maintenance’ process, there are a number of processes that adhere to it, among which ‘lubricate’. These are referred to in the ‘has a specific’ list. As a matter of fact, the contents of a parent carrier can be considered redundant as soon as the carriers specified in the level below have become definitive: it only carries structure related information about the place of its children in the LCPM. In practice it is usually uncertain when a specification has become definitive, and for the purpose of communication within the design project it seems useful to keep the contents of parents as well. The usage of the knowledge content can be reduced to serving as a name or a label for a branch. For instance, in figure 1, it is not necessary to further specify the item ‘cleaning’ if all

the knowledge specified so far is included in its children. Still, the name ‘cleaning’ may be used as a collective denominator. Considering the redundancy of parent carrier contents, occurrence is treated as an exception. The occurrence of the parent process is used as a multiplicator for the occurrence of its children. If we specify a parent carrier to occur n times (e.g. ‘production’ occurs 10,000 times) and a child carrier is specified to occur m times (e.g. ‘insert screw’ 2 times), then m is considered to refer to only one occurrence of the parent carrier (i.e. for all 10,000 occurrences of ‘manufacturing’, ‘insert screw’ takes pace 2 * 10,000 = 20,000 times). The mutual sequential relationships between carriers are handled by the Control Descriptor, which is included in one of the carriers (for the time being—in an eventual computer internal representation, this potentially ambiguous allocation is not desirable). It can be a combination of an arbitrary number of temporal conditions written in some form like: [temporal condition 1] [and/or] [temporal condition 2] [and/or] [and/or] .... [temporal condition n] in which [temporal condition i, i = 1 .. n] = [from] [before / before or after / after] [start / finish] [of] [carrier 1] [until] [before / before or after / after] [start / finish] [of] [carrier 2] with [carrier 1] and [carrier 2] referring to other carriers belonging to the same parent as the carrier in which the temporal condition occurs. Perhaps it is also necessary to include external circumstances here, although these probably should be avoided if possible. [carrier 1] and [carrier 2] may refer to the same carrier. An example of a simple temporal condition is from after finish of ‘open cabinet’ until before start of ‘close cabinet’ for a process that is carried out when the cabinet described in figure 1 is open. As a default, there is only one temporal condition from after finish of [previous carrier] until before start of [next carrier], in which [previous carrier]and [next carrier] refer to the previous and the next carrier listed in the same branch, respectively. For now, we will not go into other than temporal conditions that could be included into the control descriptor.

5 Example Application and testing is restricted to the level of detail described in the previous section. We will demonstrate the application of the LCPM using a simple product: a pencil sharpener. Figure 2 shows the LCPM as it could be the result of modeling the life-cycle of the pencil sharpener somewhere during conceptual design. The syntax used is a provisional workaround to include those elements in the carriers that have been considered so far. Figure 3 shows what the product might look like after design.

Syntax: level NAME: Subject 9HUE 'LUHFW2EMHFW &KDQJH'HVFULSWRU &RQWURO'HVFULSWRU 0RGDOLW\ 2ccurrence Min 2FFXrrence Max Legend and shortcuts: CAPITALS refer to process knowledge carriers {...} = redundant description of parent carrier, does not have to be syntactically correct once = minimally exactly one time and maximally exactly one time never = minimally exactly zero times and maximally exactly zero times n times = minimally exactly n times and maximally exactly n times PREV = after finish of (PREVIOUS CARRIER on same level or if unavailable PREDECESSOR CARRIER of PARENT) NEXT = before start of (NEXT CARRIER on same level or if unavailable SUCCESSOR CARRIER of PARENT) according to production forecast = minimally approximately 100,000 times and maximally approximately 100,000,000 times (external) refers to carriers outside the LCPM considered. LIFE CYCLE PROCESS TREE: pencil sharpener 1 DESIGN: design team FRQYHUW NQRZOHGJH WRSHQFLOVKDUSHQHUGHVFULSWLRQ IURPDIWHUILQLVK of PREVIOUS PROJECT (external) until before start of PRODUCE VKRXOGRFFXURQFH 1 PRODUCE: {factories FRQYHUW UDZPDWHULDOVDQGVXSSOLHGSDUWVDQGSHQFLOVKDUSHQHUGHVFULption WRSHQFLOVKDUSHQHU IURP35(9XQWLO1(;7 VKRXOGRFFXU`DFFRUGLQJWRSURGXFWLRQ forecast 2 MANUFACTURE: {factories FRQYHUW UDZPDWHULDOVDQGSHQFLOVKDUSHQHUSDUWGHVFULSWLRQV WR pencil sharpener IURP35(9XQWLOEHIRUHVWDUWRI$SSEMBLY VKRXOGRFFXU`RQFH 3 MANUFACTURE PENCIL HOLDER: factory #1 FRQYHUW DOXPLQXPDQGSHQKROGHUSDUWGHVFULSWLRQ WR pencil holder IURP35(9XQWLOEHIRUHVWDUWRI$66(0%/