Redesign Support Framework for Complex Technical Processes

UNIVERSITAT POLIT` ECNICA DE CATALUNYA Departament de Llenguatges i Sistemes Inform`atics Redesign Support Framework for Complex Technical Processes Iv´an L´opez Ar´evalo Thesis submitted to obtain the degree of Ph.D. in Artificial Intelligence Supervisors: Dr. Arantza Aldea Corrales Dr. Ren´e Ba˜nares-Alc´antara Barcelona, Spain, November 2005. Redesign Support Framework for Complex Technical Processes Copyright c °2005 by Ivan L´opez Ar´evalo. Dedicated to my family, for always being there. a mi familia, por estar siempre ahi. Acknowledgements I would like to thank all those people who have made this thesis possible. I would like to thank my supervisors Drs. Arantza Aldea Corrales and Ren´e Ba˜nares-Alc´antara for their confidence, guiding, support, time and effort that they spent during this thesis. Also, I would like to thank Drs. Mat´ıas Alvarado and Leonid Sheremetov for their support and inspired my decision to work in the field of Artificial Intelligence. I am also indebted to the reviewers who were available to read and comment an earlier version of this thesis that made the final version so much better. I thank the invaluable contribution of Dr. Laureano Jim´enez and Antonio Rodr´ıguez in the area of Chemical Engineering Process Design. Their penetrating and constructive criticisms and discussions have contributed greatly to the completion of this work. This work has been mainly supported by the Department of Computer Engineering and Mathematics of the University Rovira i Virgili. I am indebted to all the members and staff for providing financial support and resources, particularly the members of the Banzai Group. My sincerest thanks and acknowledgement to my family for their support and encouragement. Thanks my parents for their unconditional support during these years. Especially I wish to thank my wife, Joria, for all her kind support and for all her time and activities sacrificed. Without the support in one way or another of all these people I would probably have never finished this work. To all of them, thanks. Barcelona, Spain, November 2005. Iv´an L´opez Ar´evalo v Abstract Industrial processes require periodic evaluations to verify their correct operation, both in technical and economical terms. These evaluations are necessary due to changes in the markets, and in safety and environmental legislation. In order to satisfy these demands it is necessary to investigate process alternatives that allow the optimal use of existing resources with the minimum possible investment. This task is known as ”redesign”, which is a procedure to determine possible changes to an existing process in order to improve it with respect to some metric, such as economical, environmental, safety, etc. A redesign support framework for technical processes is proposed in this thesis. This framework employs a multiple-model hierarchical representation of the process to be redesigned together with a case-based reasoning engine that helps to decide which elements of the process should be modified. The framework consists of four main stages: acquisition of the design description, candidate identification, generation of alternatives, and adaptation and evaluation. The original process is modelled hierarchically exploiting means-end and part-whole concepts, and thus knowledge about the behaviour, structure, function and intention of each part of the process is automatically generated and stored. Given the new specifications or requirements that the process must fulfil, the system finds the parts of the process which must be redesigned and a case library is used to obtain alternative process sections which can be adapted to substitute parts of the original process. Therefore, the proposed framework allows to model the process, to identify process components suitable for redesign, to obtain alternative components, and finally, to adapt these components into the original process. This procedure can be seen as a reverse engineering activity where abstract models at different levels are generated from a detailed description of an existing process to reduce its complexity. The framework has been implemented and tested on the Chemical Engineering domain. vii CONTENTS Acknowledgements v Abstract vii 1 Introduction 1 1.1 Researchcontext ................................ 1 1.2 Motivation.................................... 3 1.3 Researchgoals.................................. 4 1.4 Researchproposal................................ 5 1.5 Contributions .................................. 5 1.6 Scopeofwork.................................. 6 1.7 Thesislayout .................................. 7 2 The process of redesign 9 2.1 Introduction................................... 9 2.2 Redesigningeneral............................... 10 2.2.1 The Design-Redesign relationship . . . . . . . . . . . . . . . . . . . 10 2.2.2 Typesofredesign............................ 13 2.3 The general (re)design approach . . . . . . . . . . . . . . . . . . . . . . . 15 2.3.1 Conceptual models in (re)design . . . . . . . . . . . . . . . . . . . . 16 2.3.2 The role of function in the design process . . . . . . . . . . . . . . . 18 2.3.3 Thedesignprocess ........................... 19 2.3.4 Thedesignobject ........................... 22 2.4 Redesignapproaches .............................. 27 2.4.1 Generic approaches in Engineering . . . . . . . . . . . . . . . . . . 28 2.4.2 Mechanical Engineering . . . . . . . . . . . . . . . . . . . . . . . . 28 2.4.3 Electrical and Electronic Engineering . . . . . . . . . . . . . . . . . 29 2.4.4 Chemical Engineering . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.5 Chapterconclusions............................... 32 ix LIST OF TABLES 4.1 Balance equations and state constraints for flow functions. . . . . . . . . . 67 6.1 Equipments and functions of the ammonia production process. . . . . . . . 119 6.2 Identified candidates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 6.3 Cause and consequence units. . . . . . . . . . . . . . . . . . . . . . . . . . 127 6.4 Used values in the similarity computations. . . . . . . . . . . . . . . . . . . 128 6.5 Result of the global similarity computation for meta-reactor-3. . . . . . . . 130 6.6 Values of meta-reactor with 56% of similarity. . . . . . . . . . . . . . . . . 131 6.7 Values of meta-reactor with 43% of similarity. . . . . . . . . . . . . . . . . 132 6.8 Values of meta-reactor with 37% of similarity. . . . . . . . . . . . . . . . . 133 6.9 Identified candidates related to increase purity. . . . . . . . . . . . . . . . . 134 6.10 Cause and consequence units of candidates related to increase purity. . . . 135 6.11 Values of meta-separator-4. . . . . . . . . . . . . . . . . . . . . . . . . . . 137 6.12 Result of the global similarity computation for meta-separator-4. . . . . . . 138 6.13 Values of meta-separator with 61% of similarity. . . . . . . . . . . . . . . . 139 6.14 Identified candidates related to increase conversion. . . . . . . . . . . . . . 139 6.15 Cause and consequence units of candidates related to increase conversion. . 140 6.16 Values of heat exchanger-2 (E-102). . . . . . . . . . . . . . . . . . . . . . . 141 6.17 Result of the global similarity computation for heat exchanger-2 (E-102). . 142 6.18 Values of heat exchanger with 69% of similarity. . . . . . . . . . . . . . . . 143 D.2 Result of the global similarity computation for T-101 (vapour absorption column) in the Acetaldehyde process. Inlet function: inlet/reaction, Outlet function: outlet/reaction .................................166 D.3 Result of the global similarity computation for MU2-2-temperature (heater) in the Acetone process. Inlet function: tank, Outlet function: tubular reactor 168 D.4 Result of the global similarity computation for MU11-3-separation (liq liq extractor) in the Acrylic Acid process. Inlet function: vapour absorption/trayed, Outlet function: trayed/trayed ...........................170 D.5 Result of the global similarity computation for MU14-3-reaction (tubular reactor) in the Bencene process. Inlet function: tmp change, Outlet function: separation ...............................172 xvii D.6 Result of the global similarity computation for MU3-2-temperature (heat exchanger) in the Cumene process. Inlet function: inlet/tubular reactor, Outlet function: outlet/flash ................................174 D.7 Result of the global similarity computation for T-101 (trayed) in the DiMethyl Ether process. Inlet function: valve, Outlet function: outlet/pump . 176 D.8 Result of the global similarity computation for MU7-3-separation (trayed) in the Ethanol process. Inlet function: tank, Outlet function: outlet/outlet . 178 CHAPTER ONE Introduction In this chapter a brief introduction to the research presented in this thesis and its context is given. The research context is described to place the problem. The motivation behind the research is defined, which focuses on the redesign of technical complex processes. The research objectives and scope of the work are presented in general terms to define the specific area of application. Finally the chapter ends with a description of the layout of the thesis. 1.1 Research context Nowadays the design and development of new products or modification of existent ones (redesign) is a key and fundamental element to enhance innovation and competivity of industrial companies. Design has an increasing importance to differentiate one product from another. In general, design is the process of specifying a description of a product that satisfies a set of requirements [Umeda 90]. Redesign is the process of changing the description of an existent product (original design) to satisfy a new set of requirements [Brown 98]. Design engineering includes both design and redesign. In the literature we can find diverse terms to refer design and redesign, such as preliminary, conceptual, functional, creative, routine, non-routine, personified, parametric, innovative, etc., but the characteristic activities of the global design engineering can be divided as follows [Subba-Rao 99], see Figure 1: 1 2INTRODUCTION 1.2 •Conceptual (re)design, the phase where the global goals, requirements and operation of the product are established based on abstract concepts. The research presented in this thesis deals with this aspect. •Detailed (re)design, the phase where the results of the conceptual design are used to physically implement a product. ideas, objectives, desired functions, functional requirements, etc. product design-description final product Conceptual design Detailed design Figure 1.1: Product design path. Design engineering involves a wide range of activities. Some of them require human intelligence to process the information. Design engineering can appear in a broad variety of domains, from the assembly of brakes to complex industrial plants and from simple chips to the most advanced super computers. Both design and redesign consist of two main elements: the (re)design process and the (re)design object. The (re)design process involves all the (re)design activities performed over the (re)design object, which is the subject entity to be (re)designed. In engineering domains is common to refer to the (re)design object as the artefact. An artefact is a type of product to denote physical and technical devices. The (re)design process is characterised by the map between functional requirements to structural requirements. Thus, design and redesign involves different types of reasoning and different sources of knowledge. In other words, both can be considered as a dialectic process between goals (what it is desired) and possibilities (real constraints), directed to the satisfaction of functional specifications and performance [Stephanopoulos 90b]. At the moment only few general theories for the systematic and rigorous development of the procedure of product design exist, as Quality Function Deployment [Sullivan 86] or the General Design Theory [Tomiyama 87]. 1.2 MOTIVATION 3 1.2 Motivation The industry deals with complex technical processes where its behaviour is mainly predicted by means of complex numerical simulators; the redesign of such processes is a common task. Nowadays for a very mature technology redesign represents the 75% of industrial projects [Grossmann 00]. The redesign of a process is sometimes necessary when certain time has passed from its implantation or when they must adapt to economical, technological, or environmental requirements. The redesign is not part of the maintenance stage but must be considered into the process’s life cycle. Although a systematic methodology of redesign does not exist, most of the existing methodologies have been centred in solving some aspects of the redesign process such as: •Increment production capacity, •Increment production efficiency, •Enhance quality of products •Reduce energy consumption, •Reduce pollution, •Implement new technologies, or •Implement control and safety considerations. From a general point of view, the redesign is done typically in three steps: designdescription acquisition (modelling), problem analysis (diagnosis) and proposal of modifications (generation of alternatives). In real redesign situations, human designers intuitively create mental abstract models by removing superfluous information about the process. Such models are based on functions of the equipment1of the process and its context. From the early 60’s, Artificial Intelligence techniques have been used for design, such as constraint-based systems, case-based reasoning, model-based reasoning, planning, neural networks, and genetic algorithms. Although in these approaches the modelling and simulation of the processes has been solved in acceptable way, another problem has been 1In the rest of the document the term equipment or device is used to refer the physical items within the process (also named plant or artefact) being modelled. Examples of equipment are compressors, mixers, reactors, etc. Examples of process are hydraulic system of cars, electrical circuits, industrial plants, etc. 4INTRODUCTION 1.3 generated, the used knowledge representations require so detailed information that sometimes it is difficult to understand. Although several redesign frameworks exist [Akin 82, Mitchell 83, Howe 86, Fischer 87, Mostow 89, Goel 91, Bras 92, Stroulia 92a, Chandrasekaran 93, French 93, Brazier 96, Eldonk 96, Pos 97, Price 97, Umeda 97, Gero 98, Culley 99, Culley 99, Kitamura 99, Kraslawski 00, Grossmann 00, Arana 01, Maher 01], we are interested in one that considers: •Cognitive aspects to reduce the complexity of complex processes and facilitate its understanding. •Functional and teleological concepts to enhance the redesign activities (modelling, diagnosis, and generation of alternatives). •Of “general” (not exclusive) application, i.e., it may be applied to support several redesign objectives in a same domain, and not only one. 1.3 Research goals Taking into account the previous mentioned situation, the main objective of this research is to obtain a support framework to assist the human designer in the redesign of complex technical processes. The structure of this framework must be based on the common redesign activities performed by human designers on real redesign situations. Therefore, the framework must able to reduce the complexity of the processes to be redesigned, and therefore facilitate the redesign activities. In order to obtain the framework, more specific objectives of this research have been identified, which purposes are described as follows: 1. Modelling of the redesign process. The redesign steps must be identified according to how human designer made them. This must be based on a hybrid approach from redesign, modelling, human computer-interaction, and reasoning issues. These steps must be directed toward manipulate and modify the object of redesign. 2. Use of models to reason about the object of redesign. Since the redesign object (complex technical process) is the core of the redesign approach, then it must be modelled taking into account cognitive aspects to reduce its complexity. The aim is to facilitate its manipulation and consequently to enhance the redesign activities in the overall redesign process. 1.5 RESEARCH PROPOSAL 5 3. Suggestion of equipment to be modified and adapted. By using the approach considered in the two previous points, appropriate reasoning tasks must be integrated into the framework to identify the equipment to be modified and to obtain similar ones from other processes. 4. The framework must be tested in real situations. The framework must be applied to a real redesign domain to demonstrate its suitability and evaluate its performance. 1.4 Research proposal The framework may be obtained integrating model-based reasoning and case-based reasoning techniques. Using model-based reasoning the original process can be modelled hierarchically. Using case-based reasoning alternative process parts can be obtained from other processes, which have to be adapted into the original process. In a detailed view, the framework would allow the process to be modelled, the process sections suitable for modification can be identifed, and the alternative parts must be obtained, adapted and evaluated. The redesign activities will be guided by an approach means-end and part-whole following the inverse sense of the activities made during the original design of the process. The idea is to reason at abstract levels on the function of the equipment in similar way to the reasoning made in the beginning of the original design (without worrying temporarily about the implementation of equipment). This can be seen as a reverse engineering activity, which employs a hierarchical representation of the process at different levels of abstraction to reduce the complexity of the process. The framework is implemented in Chemical Engineering domain due to the complexity of the processes involved and the interaction with experts in the area. This thesis is multidisciplinary, several chemical engineers experts in design have contributed with ideas, discussions, and suggestions to carry out this research. At same time, a Chemical Engineering PhD thesis [Rodr´ıguez-Mart´ınez 05] has been obtained with contributions of this work. 1.5 Contributions The main goal of this thesis is to obtain a redesign support framework for complex processes. To do this, we proposed the use of hierarchical multiple models to facilitate the 6INTRODUCTION 1.6 redesign activities. Thus, the framework focused on conceptual redesign issues where abstract models are employed. The processes are modelled hierarchically based on their functions and goals. Thus, the primary contributions of this thesis can be summarised as follows: •A novel redesign framework that combines model-based reasoning and case-base reasoning techniques has been designed, implemented and tested (see Chapters 4, 5, and 6). This framework enables the designer to work directly with the conceptual design of an existing process (i.e. a process already in operation) to automatically generate abstract multiple-models which can be modified to develop alternative process designs. The procedure can be seen as the reverse engineering approach “replay and modify”. This model-based approach provides an appropriate way of combinining hierarchical and functional modelling to represent and reason about complex processes. The hierarchical case-based approach provides a systematic way of reusing the sections of previous processes. •The use of Multimodelling and Multilevel Flow Modelling approaches to integrate mental abstract models about the behaviour of processes in the redesign activities (see Chapter 3, 4, and 5). These models provide a more intuitive vision of reasoning on each task to be performed, and thus the redesign activities are enhanced (see Chapter 6). These modelling approaches have been applied successfully in diagnosis and control domains in other investigations; we have applied them to redesign complex processes with acceptable and interesting results (see Chapter 6 and Appendix D). These contributions have been reported on several publications (see Appendix E). 1.6 Scope of work The proposed redesign framework has to be able to deal with complex technical processes. In this sense, the type of processes we are referring to, need to be clarified. Thus, the following assumptions about processes were considered in this research: 1. The complexity of the process must be high. Complex in the sense that the process is composed by several interrelated equipment which behaviour may consist on several hundreds of non-linear equation systems. 1.7 THESIS LAYOUT 7 2. Complex numerical simulators can be used to model the behaviour of the process. 3. The process is already implemented, which means there is a design solution that satisfies the original requirements of such process and the process is in operation. 4. Human designers can understand the process intuitively identifying its functional sections. That means that internal equipment of the process can be grouped based on functions and goals using an ontological commitment. 5. The process can be represented by functional abstract concepts. In other words, the domain has a well-defined structure about the functions of the processes. Any domain, which can be symbolically modelled, is representable by using the knowledge representation scheme used. 1.7 Thesis layout This thesis consists of seven chapters and five appendixes. The remainder is structured as follows: In Chapter 2 the relevant literature on (re)design is presented. This is to give a context of the relationship between design and redesign and how both share common features, as the structure of the process (the required steps) and the manipulation of the object of interest. Artificial Intelligence contributions to (re)design are also presented, both in the (re)design process as in the (re)design object. Finally some of the most relevant redesign approaches in some engineering domains are presented. In Chapter 3 the theoretical background to structure the (re)design process and to manipulate the (re)design object is described. The structure of the (re)design process extends the general engineering process. To enhance the manipulation of the (re)design object a hierarchical modelling approach is presented exploiting cognitive and functional concepts. The theoretical issues regarding the manipulation of (re)design object only involve modelling. The manipulation approaches are described in the next chapter because they are not directly related either to the (re)design process or the (re)design object. In Chapter 4 the proposed redesign framework is presented. The modelling approaches presented in Chapter 3 are used to structure the redesign process and to show how the manipulation of the redesign object is performed. Thus, how the redesign process guides the redesign object manipulation is illustrated. All these issues are presented from a general point of view. 14 THE PROCESS OF REDESIGN 2.2 the redesign task, subtle differences exist that have an impact on how the task can be performed and what kinds of knowledge are involved. Focusing on the differences of the types of redesign [Pos 97], there are three relevant differences that are described bellow: 1. The design description. Two aspects can be distinguished: •The fixedness of the structure of the design description. On one hand, the structure of the design description can be completely fixed during redesign, and only the values assigned to parameters can be altered (this leads to parametric redesign), on the other hand, there are situations where changes to the structure of the design description are not limited. For example by changing software components. •The nature of the information in the design description. On one hand, the design description can purely describe the current status of the design, whereas on the other hand the design description includes a complete plan of design steps resulting in the current design. The latter results in a form of redesign called derivational analogy [Mostow 89, Carbonell 86], while the former is the subject of redesign approaches that directly modify the current design description [Goel 91, Pos 97]. 2. The requirements of the design description. These can be classified by following two aspects: •Operationality of requirements. Requirements are operational if their truth can be automatically derived from the design description by some inference method. Depending on the application domain, it must be necessary to express needs and requirements only with operational requirements or through nonoperational requirements. •The local or global nature of requirements. Sometimes, modifications to a single component or parameter are required, which are named local requirements. In contrast, global requirements are applicable to properties of the complete design. 3. The nature of the adaptation knowledge. The adaptation knowledge employed in the redesign process allows that some adaptations are possible or suitable. Again, there are two aspects which the adaptation knowledge can be characterised: •The knowledge intensity of the adaptation knowledge. On one hand there are purely search-based approaches, like constraint satisfaction or evolutive algorithms. On the other hand there are purely knowledge-based approaches like case-based design. 2.3 THE GENERAL (RE)DESIGN APPROACH 15 •The generality of the adaptation knowledge. This means the applicability of the adaptation knowledge, the application-specific strategies, and very general strategies like “divide-and-conquer”. Most of the issues mentioned above have been formulated in the context of design problems rather than redesign [Wielinga 97, Bernaras 94]. There are a variety of research works referring to design or redesign; from (re)design of abstract (for example, components in software engineering) to physical entities (for example, a reactor in chemical engineering) for a general review see [Brown 97], for some details see [Akin 82, Mitchell 83, Howe 86, Fischer 87, Mostow 89, Goel 91, Bras 92, Stroulia 92a, Chandrasekaran 93, French 93, Brazier 96, Eldonk 96, Pos 97, Price 97, Umeda 97, Gero 98, Culley 99, Culley 99, Kitamura 99, Kraslawski 00, Grossmann 00, Arana 01, Maher 01]. In this thesis, the issue of physical entities, which is commonly named Engineering Design is tackled. In the literature the term Engineering Design is applied to design or redesign of physical systems (processes, devices, equipment, etc.). Also, in this thesis the point of view considering the redesign as a phase of the reuse process of design is adopted, where similar methods and strategies can be applied to both design and redesign using the appropriate specialisations. Some researchers use the term (re)design indistinctly in order to refer to design or redesign instead of using such concepts in an isolated manner. Also in this thesis this term is adopted. 2.3 The general (re)design approach As mentioned before, the design problems in different domains share a common core of skills and knowledge. In this sense, in (re)design can be identified two relevant aspects, one is the (re)design process and the other is the (re)design object. The former is related to cognitive issues and the latter is closely related to physical modelling and manipulation issues. Commonly, design is considered an activity involving human expertise. Within design several methods and techniques are used in (re)design process. From a general perspective, the process of design is generic, occurs in many areas with some little variations. The objective is to find a configuration of certain elements (design objects) that, combined in one artefact, performs required functions [Alberts 93b, Blessing 99]. This subsection is divided into five subsections, in the first (§2.3.1), general issues about models commonly used are described. The next section (§2.3.2), the role of function in 16 THE PROCESS OF REDESIGN 2.3 the (re)design process is examined in more detail. In section §2.3.3, relevant works on (re)design process are presented describing how influence the work of the last review. Finally in section §2.3.4, research contributions on the (re)design object are described remarking therelated areas to this thesis, model-based reasoning and case-based reasoning. 2.3.1 Conceptual models in (re)design Models in design and redesign are particularly important to guarantee that they represent the intentions for which they were created. In general, the models are abstractions of the reality that guarantees communication of ideas by joining concepts, aggregations and relations [Bridge 97]. Akin [Akin 82] outlines that the representational aspects to determine the utility of a model in design are: •The represented information must be in a level of abstraction suitable for its intention. •The contents must be on such way that they are compatible with the expected results according to the mental representations of the designer. •The model must be consistent with the reality that it tries to reflect. A substantial amount of research has focused on defining models of design [French 85, Tomiyama 87, Treur 89, Brown 89, Chandrasekaran 90, Gero 90a, Takeda 90a, Alberts 92, Vescovi 93, Ohsuga 97, Brown 97]. Most of this research highlight that the modelling of the functionality (or properties) of the design object description is an important aspect of the overall design process. Particularly in Engineering Design it is possible to represent explicit knowledge in (re)design by means of modelling functions of artefacts. This facilitates the systematisation of the reasoning and some tasks of (re)design. The reasoning based on functions allows abstracting information of the design on the same way as it is made in the reasoning of the initial stages of the design. The process of design of an artefact starts with the conceptual or functional design followed by the basic design and the detailed design [Stephanopoulos 90a]. Within these, the functional design plays the central role since it guarantees the quality of the design and the innovation of the product [Umeda 97, Culley 99]. The idea of function is fundamental in design since the work of the designer is to design artefacts that must achieve explicit functions [Chandrasekaran 00]. 2.3 THE GENERAL (RE)DESIGN APPROACH 17 Functional modelling is useful to model the object of (re)design, this modelling of objects enhance the formulation of (re)design strategies and the overall (re)design process. Functional modelling “hide” sections of the artefact structure at a lower abstraction level facilitating the manipulation of the artefact description. In the (re)design object subsection (see §2.3.4) a discussion of functional modelling is presented. Most research work on (re)design considers redesign as a knowledge-intensive field; wherein the processes (e.g., tasks) performed, descriptions of sequencing of processes, descriptions of the information within the system, and knowledge employed to perform a task are explicitly modelled most of the time by means of knowledge-based systems. These modelling frameworks try to model the (re)design so the (re)design object as well as the (re)design process are understandable by humans. To do this, the (re)design needs and how humans use the object specifications to propose a reasonable (re)design approach need to be understood [Leveson 00]. Reasoning strategies employed in (re)design are derivatives or extensions of the commonly named problem-solving methods (some authors refer it as problem-solving strategies) -see [Rist 95]-. Examples of strategies are hypothesis and test [Hempel 66, White 05], pattern recognition [Doyle 62, Kirsch 64, Mitchell 97], skeletal plan refinement [Friedland 85, Tu 89], heuristic classification [Clancey 85], propose and revise [Goel 89], propose critique modify [Chandrasekaran 90], decision tree search [Raiffa 68, Qi 92], means-ends analysis [Newell 63, Rasmussen 86], and reasoning by analogy [Gick 80, Gentner 83]. Thus, the knowledge engineer needs to formulate an explicit model, either implicit/ explicit or formal/informal, of expertise that can be thought of as an integration of two types of models: a domain model and problem solving method model. The domain model corresponds to the (re)design object and the problem solving method model corresponds to the (re)design process. Work on domain modelling, has only recently attracted the attention of knowledge based system researchers [Stephanopoulos 90a, Schoen 91, Gruber 93, Skuce 93, Sowa 95, Kitamura 98, Fensel 01b, Gomez-Perez 04]. The problem solving method determines how those entities in the model will be used in the actual problem solving process. That is, a problem solving method model contains knowledge that is procedural in nature whereas a domain model contains declarative knowledge about the target domain. Domain specific concepts, relationships, and knowledge pertaining to them are captured in the domain model through ontologies [Chittaro 93, Kitamura 99, Fensel 01b, Kuraoka 03]. In several domains, particularly physical domains, the modelling paradigm named compositional modelling, which was originally proposed by Falkenhainer and Forbus [Falkenhainer 91] has predominated. Independently of models and strategies employed in the (re)design, it is important that such data and knowledge can be recorded in a consistent manner for the future under- 18 THE PROCESS OF REDESIGN 2.3 standing of the (re)design. This constitutes the named (re)design rationale, which is next described. 2.3.2 The role of function in the design process Functions in design play the central role since it guarantees the quality of the design and the innovation of the product [Umeda 97, Culley 99]. Function is regarded as what a design object is supposed to do; it is a manageable representation of the overall behaviour of the object [Price 98]. Some authors define function as an abstraction of its intended behaviour strongly related to its context [Gero 90a, Goel 92, Stroulia 92a, Chittaro 93, Brown 97, Chandrasekaran 00]. One of the most relevant strategies of design has been proposed by Chandrasekaran by means of functional concepts, this strategy is named Propose-Critique-Modify [Chandrasekaran 90]. Also, Chandrasekaran describes the importance of functions in design activities by means of his Functional Representation framework [Chandrasekaran 93]. Initially the designers think in functions before they are concerned with specific properties. Functions can exist at different levels of abstraction, depending on the design phase that one is in and the current focus of design interest. In preliminary design phases, functions usually are independent of working principle, whereas in later design phases, when the functions have been detailed, they become more and more dependent on the working principles that has been selected. In the following, a distinction between three levels or categories of functions is made: •General functions. [Keuneke 91, Lind 94, Kitamura 98, Bo 99] proposed a restricted list of general functions dealing with the transformation of matter, energy and/or information, which are independent of the working principle. •Specialised functions or sub-functions. Act on flows, forces, moments etc., independent of the working principle. •Working principle dependent function. Salomons [Salomons 95] define it as the realisation of a specialised function (by means of physical phenomena). Several alternative solutions for fulfilling working principle dependent functions can exist without changing the working principle itself. A lot of research has been carried out to investigate the role of function in the design process, particularly to assist the designer in the more conceptual levels of the design process, i.e. focusing on the first two categories of functions. These two categories are 2.3 THE GENERAL (RE)DESIGN APPROACH 19 often referred to as the “systems model of functions” because they are closely related to systematic design approaches. 2.3.3 The design process Several researchers have studied the design process, overviews are provided in [Libardi 88, Finger 89, Ullman 92, Brown 98]. The design process is a complex and not yet well understood cognitive process conducted by humans [Salomons 95]. The design process is related to the process of actions and decisions that are taken during design in order to arrive at completed product design. Models of design processes provide a structured description of a process of design. The models differ in their underlying formalisations and have been represented in structures such as: •blackboard architectures [Ball 92], •algorithms [Alberts 93b], •SOAR [Steier 91], •task models or problem solving methods [Brown 89, Brazier 94, Wielinga 97], or •agent architectures [Dunskus 95, Berker 96, Lander 97]. The following models of the design process can be distinguished [Finger 89, Salomons 95]: Prescriptive models The prescriptive models are sometimes referred to as underlying models for methodical or systematic design approaches [Salomons 95]. In these models the design process consists of several main phases: the problem definition phase, the conceptual design phase, the embodiment or structure design phase and the detail design phase. In the problem definition phase, the design problem is described and its requirements and specifications are generated, validated and reformulated. In the conceptual design phase the functions that have to be fulfilled are discerned through mapping the requirements of the definition phase to a more realisable description. During embodiment design, working principles are translated from the conceptual realisable description to the definition of real equipment. After embodiment design has finished, detail design of each individual equipment can start. During this design phase, each equipment is fully detailed by means of its real-world properties such as dimensions, compositions, positioning and restrictions. Another perspective is described by Alberts [Alberts 93a], he describes it as a synthesis process. Original requirements and basic generic elements are input of the design process, 20 THE PROCESS OF REDESIGN 2.3 and final requirements and product descriptions are output of the design process. This perspective on engineering design includes the manipulation of requirements (and the manipulation of a product description) but does not explicitly include objectives on the design process itself. Descriptive models Descriptive studies of the design process revealed that in practice design is not conducted in such a strict top-down manner as suggested by the previously described prescriptive approaches. Sometimes designers switch from more conceptual design actions to more detailed design actions and vice versa, merging top-down and bottom-up strategies [Stephanopoulos 90b] in similar way like protocolary flows by means of transition states. Ohsuga [Ohsuga 97] proposes a model of design which features both the manipulation of a design object description as well as strategic knowledge on the management of this process. Two kinds of knowledge are identified in this model: knowledge applied directly to the model being designed, and knowledge to guide and control the exploration or search process. An extension of this model investigates the manipulation of sets of requirements in interaction with users [Sumi 97]. An experience-based approach is taken, allowing users to explore the space of requirements. Smithers [Smithers 92] proposes another model in which both the manipulation of requirements and the manipulation of design object descriptions are discerned. From his viewpoint of design as exploration, both the exploration of possible sets of requirements as well the exploration of possible design object descriptions are explicitly modelled. Opportunistic design Opportunistic design is a different view where designers survey a problem by suggesting critical areas in the design and making some tentative decisions about how the functions concerned may best be achieved [French 93]. This is very similar to the descriptive models of the design process. Opportunistic design contrasts to methodical, systematic design [French 93]. Here the design depends on the mental models and skills of the designer. Decision support problem Bras [Bras 92] has looked upon the design process as a decision support problem. Bras derives two fundamental equations which are used to model decision based design. Design processes are modelled using a set of fundamental entities. The quality of the design support problem (design support process) is modelled and improved by using axioms of Suh [Suh 90]. The design process has also been viewed upon as a constraint satisfaction process [Serrano 87, Thornton 93]. During design, constraints are continually being 2.3 THE GENERAL (RE)DESIGN APPROACH 21 added, deleted and modified. Ullman made the following classification of constraints: introduced, given and derived [Ullman 91]. The introduced constraints are introduced by the designer during the design process through domain knowledge. The given constraints are constraints external to the design process, as introduced by e.g. product specifications. The derived constraints are introduced through a design decision. In same manner, Arana et al. [Forster 97a, Arana 00, Arana 01] proposes other application of constraints in the DEKLARE project (which is explained in the next subsection). Theorem problem solving process From a mathematical foundation perspective, Takeda et al. [Takeda 90a, Takeda 90b, Takeda 94a] has been viewed design as a theorem solving process in their extended General Design Theory [Tomiyama 87]. The General Design Theory is based on axiomatic set theory, proposes a logical framework for design processes to construct a general structure of intelligent CAD systems. Design is viewed as a mapping from functional space to attribute space. Takeda et al. define design and design processes in terms of logic and explain how a design process is formed under given knowledge. This clarifies what kind of inferences should be prepared and when they are used in design processes. Human learning process Within the FBS (Function-Behaviour-Structure) framework [Gero 04] Gero and Kannengiesser have seen the design process as a human learning process. This time, Gero and his colleagues define design as purposeful, constrained, decision making, exploration, and learning activity. Here the designer operates within a context, which partially depends on the designer perception of purposes, constraints, and related contexts. These perceptions change as the designer explores the emerging relationships between assumed designs and the context as the designer learns more about possible designs. The difference between the described on descriptive models and this work is that latter is related to the learning aspect of design, focusing on that form of learning which relates to exploration, that is modifying the problem spaces defined in the former approach. In that manner the designer can changed his/her decisions. Multiagent design Taking advantage of multiagent systems several authors have worked on the collaborative aspect of the (re)design process. Several authors have addressed this aspect by means of Multiagent Systems, this class of systems are named Multiagent Design System (MADS) [Marco 94, Lander 97, Maguire 98, Shakeri 98, Batres 99, Zhao 01, Wood 01, DeLoach 04]. These design approaches generally combine automated software components with human decision-makers, making necessary to provide support for both human and computational participants in the design process. Personal-assistant agents provide support to humans within the overall process design, combining diverse sources and types 22 THE PROCESS OF REDESIGN 2.3 of information and reasoning. Most of work in building MADS applications has focused on sharing information and data among agents. However, it is equally important that agents coordinate their activities during the design process to produce quality designs and effective use of resources [Lander 97]. Multiagent Systems provide theories of control and coordination between agents to tackle parallel activities imposed in concurrent design, the objective is obtain a globally cooperative behaviour. In this later sense, MADS applications include conflict-management techniques. Modelling language for design Within a more specific field, in the named “process engineering”, Stephanopoulos et al. [Stephanopoulos 90b, Stephanopoulos 90a, Christopher 95] have proposed a modelling language called MODEL.LA for conceptualisation of processing systems. The author claims that MODEL.LA allows a) to enhance the procedure for defining process models and the documentation of contextual data and knowledge, such as assumptions and simplifications, and b) have a procedure to build process models without dictating the modelling work too early with some algorithm solving the problem. MODEL.LA provides a framework for declarative knowledge (“what is”) but it does not model design process (“how to”). 2.3.4 The design object The design object is the central “actor” object that receives the attention during the overall design process. This can be a model of an equipment, artefact, process or system. Traditionally, the design object was created by technical drafts; but with the advent of computers, the design object has become a computer model that can be shown, modified and deleted easily. Thus, several models (models of artefacts) have been used in design. A human designer can model a single object from different points of view. That is, they can get some different models from it and use them, but the important point is that they still regard these models as representation of the same object [Takeda 94b]. The objective is transfer information between different models. Some authors [Rasmussen 86, Douglas 88, Hoover 91, Lind 94, Turton 98, Leveson 00] have observed that abstractions of the design object are important during the design process to manipulate design objects. In this sense, Hoover [Hoover 91] has observed that: •the design object evolves through abstractions and refinements. •abstractions and refinements are selected opportunistically and are characterised by 2.3 THE GENERAL (RE)DESIGN APPROACH 23 the designer focusing on a few aspects of the design object at a time. •refinements are made within the framework of abstractions. During the design process, the level of detail both decreases and increases. •conceptual, layout and detailed stages are not distinct steps in the design process. These observations are in accordance with the descriptive and opportunistic views of the design process. Note that both top-down and bottom-up strategies are employed to obtain these observations. The use of abstractions in design is addressed later in Chapter 3. Several research work have been developed about (re)design object manipulation. According to these works, the most relevant approaches in this issue are model-based design and case-based design, which are following briefly presented. 2.3.4.1 Model-based design One of the most used approaches in the manipulation of the (re)design object is modelbased design which really is a branch of model-based reasoning (MBR) applied to (re)design. Model-based reasoning constitutes a set of techniques applied in several domains and used to create models and reasoning about them. Mainly the most used issue of MBR has been to model functions on equipment, devices, processes, systems. Within this aspect, the compositional modelling technique has been strongly used. The compositional modelling approach was described by Falkenhainer and Forbus [Falkenhainer 91, Falkenhainer 92]; is an approach to construct a model of an artefact on the basis of a description of the artefact and a query about the composition of the artefact. Queries are not further manipulated, but strategies are employed for reconstruction of models. Extensions have been proposed by Nayak and Joskowicz [Nayak 96] within the manipulation of design parts of models. Although it is not considered to be a design or redesign task, compositional modelling can be viewed from that perspective. In other words, compositional modelling is a technique to model equipment by means of simpler components (sometimes named blocks). Thus, in compositional modelling, components are used to describe the structure of more abstract artefacts. In this approach the task that a process performs (i.e., its ‘functionality’) is composed of smaller components. The components correspond to processes that modify the flows. Relationships of events on components give an explicit order about the behaviour of the system. From a cognitive point of view, can be considered as an intuitive technique to construct complex systems. 30 THE PROCESS OF REDESIGN 2.4 Maulik et. al. [Maulik 92] propose the use of optimisation techniques to redesign CMOS analog circuits. The optimisation approach is guided by three principles. First equations that describe device characteristics are encapsulated and separated from equations that describe the performance of the circuit topologies. Secondly, constrained optimisation techniques are employed to synthesise the redesigned-scaled CMOS circuit. Finally, constrained optimisation allows the solution of some final constraints over specific variables. The requirements for the design of an analog block are usually formulated in terms of bounds of specified performance parameters (gain, bandwidth, voltage, etc.). Analytical expressions are employed to represent the functional performance in terms of small-signal model parameters, and in terms of design variables. The analytical equations replace the circuit simulations. Umeda et. al. [Umeda 92, Umeda 94] consider the potential functions of the components of an artefact to redesign it. The architecture consists of sensors, which monitor the machine, and a model-based reasoner diagnoses faults and plans repairs. The system generates a FBS (Function-Behaviour-State) model based on the design object, and then searches the model for candidate redundant function. The FBS model consists of a function hierarchy that represents the designer’s intentions, and a behaviour network that describes how the function hierarchy is realised. The system first tries a control type strategy that adjusts various machine parameters. If the strategy fails the system applies a strategy based on functional redundancy, it uses the potential functions of existing parts in a slightly different way from the original design. Heo et. al. [Heo 98] present a redesign approach of digital electronic systems by means of evolutive programming. They use directed acyclic graphs known as task flow graph (TFG) to represent the redesign object. Each node of the graph represents computational tasks; an edge represents a transfer of data. The design process consists of five tiers: a) system-level design, b) architectural design, c) logic design, d) circuit design, and e) physical design. During the design process, the information flows in both direction of the hierarchy (top-down and bottom-up). The architecture of this approach receives as input a task flow graph and an existing design for the TFG, as output gives a new design specification. The existing design may be specified as a partial design where some design decisions are hard or soft depending on the necessity of it appearing in the final design. 2.4.4 Chemical Engineering The (re)design of chemical processes is made with the purpose of adapting existing processes to changes in economic, technological or environmental requirements. In the eight- 2.5 REDESIGN APPROACHES 31 ies mainly were significant advances on saving energy by means of two constraint-based approaches: a) pinch methodology (analysis to determine the minimum consumption of energy in a process. [Tjoe 86, Smith 87, Linnhoff 88]) and b) mathematical programming on synthesis and design of processes [Papoulias 83, Pistikopoulos 87, Vaselenak 87]. In the nineties Gundersen [Gundersen 90] made a revision of systematic methods of redesign of processes, which are the broadly tackled. In such revision he emphasised two important observations: •Most of the projects in the industry of processes were redesign projects. •The systematic methods of redesign of processes are based on methods of design of processes. Doherty et. al. [Fischer 87] develop a systematic procedure of redesign by means of opportunistic searches; the procedure considers modifications in the structure of the flowsheet (in other words is a flowsheet) and in the dimension of equipment. Kirkwood et. al. [Kirkwood 88] implement a methodology of redesign by means of an expert system by using heuristic rules to construct hierarchical structures. Nelson and Douglas [Nelson 90] develop a systematic procedure considering alternative reaction routes; the procedure is hierarchical and provides guides to identify viable processes. Rapoport et. al. [Rapoport 94] propose an algorithm to design units of process by means of the redesign of already existing ones. The algorithm consists of hierarchical levels and heuristic rules; this approach is similar to synthesis of processes. Han et. al. [Han 95] develop an approach based on agents to synthesis of processes; they model the process of design like a set of tasks that can be executed by agents. Also have been developed systems to satisfy economic, environmental and safety constraints. Kraslawski et. al. [Kraslawski 00] develop a methodology centred on the identification and elimination of bottlenecks in reaction and separation sections. Sylvester et. al. [Sylvester 00] optimise processes within the concept of Greener Process3. Hertwig et. al. [Hertwig 01] apply techniques of MINLP (Mixed-Integer Non-Linear Programming) to optimise configuration of processes. Pasanen [Pasanen 01] developed a tool in which a methodology for conceptual design of processes is implemented. This is called Phenomenon Driven Process Design (PDPD). This methodology focuses on the systematisation of conceptual design of chemical processes; in other words, in the manipulation and documentation of conceptual models. Uerdingen et. al. [Uerdingen 01] present a “screening” method based on an analysis of the flow path pattern. They use performance indicators to rate the economic impact of each equipment in the flow path. 3Methodology of design in environmental contexts by means of the development of models to estimate costs of waste products and selection of solvents 32 THE PROCESS OF REDESIGN 2.5 2.5 Chapter conclusions In the literature there is a lot of work about (re)design and reviews about specific issues of (re)design. This gives the idea that (re)design can be tackled from different perspectives. The review presented in this chapter was conceived from two ideas: •present the methods and techniques usually employed in (re)design, and •present some research work of mechanical, electrical and chemical engineering areas. The former point is with the aim of giving a general outlook of (re)design in some theoretical manner. This distinguish the most relevant issues in (re)design: a) the (re)design process and b) the (re)design object. These aspects have been explained deeper to emphasise the general guidelines employed in some research. This have been reviewed to understand what is necessary to propose a redesign support framework. Complementary to the former point, the latter point gives a shallow perspective of some research in mechanical, electrical and chemical engineering. This last review is presented to describe practical applications in engineering. Design is considered an activity involving human expertise. Within (re)design several methods and techniques have been used in its stages. The general (re)design approach can be seen as global process composed of two general issues: •(Re)design process. Here, the reasoning strategies used have been: generate-andtest, means-end analysis, problem decomposition, search methods and constraint satisfaction and conflict resolution. •(Re)design object. Here different techniques have been used to model the object: object-oriented, frames, semantic networks, bond-graphs, AND/OR trees, firstorder logic, and equation systems. In general terms, the overall (re)design approach can be more or less complex depending on the modelling approach employed in the modelling of the (re)design object. The (re)design object is the central “actor” and receives the attention during the overall design process. As mentioned earlier, most of the redesign work has been developed in the context of the design problems. In this thesis the approach adopted is considering redesign as phase of the reuse process of design. The important point is to reduce the differences between the original design description and the new set of requirements. In few words, the redesign approaches generally follow common steps. Normally in a general (re)design process, 2.5 CHAPTER CONCLUSIONS 33 the first step is to obtain the design description. The design description contains all the data necessary to model the redesign object. From this description the part to be modified or replaced must be identified. Then new design descriptions can be generated by means of insertion and/or adaptation of new or existent equipment to the original design description. Some approaches include the systematisation of the evaluation step to verify the suitability of the generated design descriptions. This depend on the availability of integrating a simulator of the artefact to know its behaviour. Other approaches do not systematise this step and the designer must simulate the artefact by hand in external simulators. With respect to the (re)design object two important aspects can be distinguished: a) the modelling and b) the manipulation. These aspects can be tackled by two promising and extensively employed approaches, Functional Representation and Case-Based Reasoning respectively. As has be remarked, functions play an important role in redesign because facilitate the modelling of the redesign object. The modelling of the redesign object affects the overall redesign process. Independently of the redesign strategy, the activities in the stages of any approach of redesign are facilitated if they are made by means of functionsbased reasoning. Initially the designer conceives the design of an artefact based on the function or functions that must be carried out according to certain requirements. In redesign the designer can modify these functions to obtain an alternative design. In other words, the conception of the original functions can be identified tracing the decisions made in the original design of the artefact with the aim of modifying them to obtain an alternative design. The previous issue can be achieved by means of application of functional representation. The Functional Representation can, by means of abstractions, manipulate design descriptions; this would help the systematisation of redesign activities. An aspect to emphasise of the Functional Representation is its capacity to manipulate qualitative (abstract) representations that allow to abstract granular information. Thus, Functional Representation allows to generalise information about the components of an object to redesign by means of hierarchical representations. Therefore, abstract functional representations of an artefact in previous design can offer to designer ideas of how modify the current design description. One of the most employed techniques in the modification of the (re)design object is casebased reasoning (CBR). Case-based reasoning uses abstractions of acquired experiences in the solution of previous problems to solve new ones. The manipulation of qualitative representations and the possibility of reuse previous experiences have extended the use of case-based reasoning as a viable approach in (re)design. One important characteristic of case-based reasoning not employed in (re)design (at least not found in the literature revised) is the use of hierarchical representations. Then, since that Functional Represen- 34 THE PROCESS OF REDESIGN 2.5 tation allows represent design descriptions hierarchically, these representations would be properly managed by hierarchical Case-Based Reasoning to obtain promising alternative design descriptions from other artefacts. In the following chapter the theoretical background to support the above issues (both (re)design process and (re)design object) is presented. This background has been selected according to deal with issues of complex technical processes. CHAPTER THREE Modelling as part of the redesign process The modelling approaches used to build our redesign framework are explained in this chapter. That involves the modelling approach employed to describe the redesign process and the redesign object. As human designer plays an important role in redesign, hierarchical modelling approaches that reflect designer cognitive issues are described. We claim that these modelling approaches facilitate the manipulation of the redesign object and consequently the redesign activities performed in the redesign process stages. 3.1 Introduction The previous chapter presented a review of the literature of redesign and related fields. This chapter describes the most promising approaches that have been selected by taking into account cognitive aspects (how human designer works to redesign a complex system). Although talking about redesign is similar to talk about design, in this chapter only the term redesign will be used. We must also bear in mind that talking about redesign process is similar to talk about the general reasoning strategy used in the redesign. In a similar way, referring to redesign object is similar to referring to the modelling and manipulation approaches of the redesign object. Since manipulation strongly depends on the modelling approach used, first, we will talk about modelling issues, in the following chapters the manipulation will be discussed. 35 36 MODELLING AS PART OF THE REDESIGN PROCESS 3.3 In the previous chapter the main aspects of redesign were described: the redesign process and the redesign object. Next section (§3.2) presents the approach employed to model the redesign process. Section §3.3 deals with issues of modelling of the redesign object by considering utility and complexity of the information available. Finally in section §3.4 the hierarchical modelling approaches used in this thesis are described. 3.2 Modelling the redesign process In general, the redesign process is based on human skills, particularly on modelling and reasoning capabilities, i.e., on the reasoning strategy (also known as problem-solving method) employed [Pos 97]. Thus, following the basic system engineering principles, a designer models and manipulates the object to be redesigned to obtain suitable alternatives, which satisfy the new requirements. The overall redesign process depends on the problem-solving strategy used. The redesign approach of this thesis is based on the basic concepts of systems engineering process, shown in Figure 3.1. The logical structure of this process provides a good and simple base for problem solving in redesign. Its structure allows us, by means of iterations, to increase gradually the complexity of the redesign alternatives by generating solutions at different levels of detail. The redesign process can be viewed as a subset of the larger system engineering process. In this perspective, each artefact can be viewed as an integrated whole even though it is composed of diverse specialised components. In order to start the redesign process, the problem must be specified in terms of objectives that the original artefact must satisfy and the criteria that can be used to rank the alternative designs. Then a synthesis process takes place and the results are a set of alternative designs. Each of these alternatives is analysed and evaluated in terms of the predefined objectives and design criteria. Finally one alternative is selected to be implemented. The process is highly iterative; the results from later stages are fed back to early stages to modify objectives, criteria, design alternatives. Design alternatives are generated through a process of analysis of system composition. The designer breaks down the system (artefact) into a set of subsystems (components), together with the functions and constraints imposed upon the individual subsystem designs. These aspects are analysed with respect to desired system performance features and constraints. The process is iterative until an acceptable design alternative is achieved. At the end of this process all components must be described in such detail that an implementation of the whole object can be performed. 3.3 MODELLING THE REDESIGN OBJECT 37 Identify objectives and criteria Generate alternative designs, Identify subsystem functions and constraints Evaluate alternatives against objectives and criteria Select one alternative for implementation Figure 3.1: The basic systems engineering process. 3.3 Modelling the redesign object As was mentioned in the previous chapter, the redesign object1is the central point of all redesign activities. Thus, the adequate understanding of the redesign object is essential; this understanding depends strongly on the mental models of the human designer. Usually designers communicate their ideas more easily in terms of abstract, high-level descriptions to describe complex concepts [Price 03]. Therefore, certain amount of specific knowledge that “explains” those abstract concepts and translates them into more basic requirements is needed. The description of the redesign object can be done in many different ways, depending on the context and purpose for which the description is to be used. For example, in the early phases of redesign, highly abstract descriptions (e.g. qualitative or causal) might be helpful, whereas in later phases, more detailed and quantitative descriptions provide more suitable information. Thus, the use of adequate representations of the conceived ideas and models is essential. In this sense, the use of computer tools is fundamental to support the designer. From an Artificial Intelligence perspective, the redesign object can be modelled following the ideas stated in Qualitative Physics. The purpose of Qualitative Physics is to model qualitatively the behaviour of physical systems [Hayes 79, Forbus 88] taking into account the notion of causality2. Within Qualitative Physics there are two basic approaches, the 1The term redesign object means a physical system/process. 2The notion of causality plays an important role in the understanding of phenomena and consequently processes. It concerns with aspects of causes and consequences. 38 MODELLING AS PART OF THE REDESIGN PROCESS 3.3 Theory of Confluences of de Kleer and Brown [de Kleer 84] and the Qualitative Process Theory of Forbus [Forbus 84]. In the Theory of Confluences [de Kleer 84] a system (or device or artefact) is viewed as a collection of physically interconnected components. The behaviour of a component is specified by internal laws which are often decomposed into distinct states or operating regions. Each device has a number of ports through which interaction between other components occur. The theory is based on a bottom-up approach centred on components. In the Qualitative Process Theory (QPT) [Forbus 84] the behaviour of physical systems is modelled by a collection of processes which describe continuous changes. This theory is based on a process centred approach. Processes are the equivalent to the differential equations that describe system dynamics. The main advantage of Qualitative Process Theory over the Theory of Confluences is that it provides a simpler notion of causality. In the Qualitative Process Theory, processes are the source of all changes, while in the Theory of Confluences, the changes arise from the interaction of the involved equations, a change is propagated by these constraints. Mainly both theories are based on structural and behavioural knowledge. Considering the notion of function, some researchers [Sembugamoorthy 86, Goel 89, Franke 92, Keuneke 91, Chittaro 93, Iwasaki 93] have extended such theories. They attempt organise the knowledge in a domain by means of functional concepts. The main claim of these approaches is that functions and intentions can provide important additional information for understanding and reasoning about the structure and behaviour of physical systems. In addition other researchers have directed they extentions to hierarchical modelling by means of different aggregation levels [Liu 91, Rajamoney 91] or different aproximations [Weld 86, Kuipers 87, Struss 91, Falkenhainer 91] to organise the knowledge. Independently of the tools and representations employed, several authors [Fischoff 78, Checkland 81, Jaffe 91, Vicente 92] suggest that two important aspects must be addressed if computer tools are used to tackle activities of complex systems: •Content, the semantic information that should be contained in the representation given the goals and tasks of the users, and •Structure, how to design the representation to facilitate that the user can extract the required information. The content gives the basic issues to understand the information about the redesign object. Independently of the amount and complexity of the information, the designer can 3.3 MODELLING THE REDESIGN OBJECT 39 conceive, in general terms, the objectives of the redesign object. The structure concerns to the organisation of information. Commonly, the amount of redesign object information is enormous, and contains data that sometimes is not relevant to the redesign activities. Thus, the necessary and more useful information about the redesign object must be selected. These two aspects are described in more detail in the next two sub-sections. 3.3.1 Content The designer should decide what information should be in the design specification according to the task that he/she must perform. In this sense, to obtain a suitable design specification the basic system theory [Bertalanffy 50] must be taken into account. The system theory defines a system (in the context of this thesis, an artefact, device or equipment) as a set of components that act together as a whole to achieve some common goal, objective, or purpose. The components are all interrelated and are, either directly or indirectly, connected to each other. The system state at any moment is the set of relevant properties describing the system at that time. The system environment is a set of components (and their properties) that are not part of the system, but which behaviour can affect the system state. It is important to notice that a system is always a model, an abstraction conceived by the human designer and that it can have several interpretations. For the same system, a designer may see a different purpose than the original designer and may also focus on different relevant properties. Thus, there are a set of multiple “right” system models or specifications. In this way, to ensure consistency and enhance communication, a system model should define [Jaffe 91, Leveson 00]: •System boundaries, •Inputs and outputs, •Components, •Structure, •Relations between components, and •Purpose (or goals) of the system. all these properties should be included in the whole system model along with a description of the aspects of the environment that can affect the system state. Most of the aspects listed are already included in several modelling approaches. However, the last topic of the 46 MODELLING AS PART OF THE REDESIGN PROCESS 3.4 These functions can be used to describe information flows. There are also some specific information flow functions: •observer, the capability of a system to translate physical observations to information. •decision maker, represents the decision-making capabilities of a system. •actor, represents the capability of a system to turn information into physical consequences. In addition to the flow functions, some organisational functions are used. They are concerned with expressing support and control: •network, which is used to group a flow structure and connect it to a goal. •manager, which describes control and supervisory systems, including human operators. 3.4.1.3 Flow structures Flow functions may be connected each other into flow paths or flow structures. These structures are used to model how mass, energy, or information flows from function to function. In fact, flow functions always belong to a flow path and never can be used in isolate manner. A flow structure is a graph of connected flow functions. The functions can be connected via three different types of relations: •mass flow connections, •energy flow connections, •information flow connections. The given description of MFM is based on [Lind 90]. It should be noted that the later versions of MFM differ in the descriptions of control systems and information flow [Lind 94, Lind 99]. Comprehensive discussions of the MFM concepts are given in the works of Lind [Lind 90, Lind 96]. The relations between MFM models and other model categories are discussed in other references of the author [Lind 90, Lind 94]. 3.4 THE HIERARCHICAL MODELLING APPROACHES 47 3.4.2 Multimodelling Multimodelling is mainly derived from the DEVS (Discrete Event System Specifications) multiformalism of Zeigler [Zeigler 79]. Ziegler presents a mathematical ground helping to handle the aggregation problem. The idea of multimodelling has its roots within the work in combined simulation modelling. Combined modelling has traditionally referred to a integration of discrete-event and continuous modeling within the same system description. First Pritsker [Pritsker 74] implemented combined modelling in the GASP modeling language. Cellier [Cellier 79] developed an approach to combined continuous/discrete-event models implemented in a GASP language extension. Praehofer [Praehofer 91] extended the DEVS (Discrete Event System Specification) [Zeigler 79] to provide a formalism and a simulation environment for specifying combined continuous/discrete-event models. In order to meet multimodelling requirements, Fishwick proposed the integration of modelling approaches of Artificial Intelligence and Simulation [Fishwick 92a]. He considered the object-oriented approach of multimodelling [Fishwick 91, Fishwick 92b] as natural approach of combine knowledge at different levels. He was based on Artificial Intelligence qualitative concepts as envisionment [de Kleer 84] and landmark [Kuipers 87]. Thus, Fishwick introduced a new methodology called Object-Oriented Physical Modelling (OOPM) [Fishwick 97] to extend the classical object-oriented analysis and design methods in use in the simulation community. His approach has similar goals to the work of Falkenheiner and Forbus [Falkenhainer 91] So, a multimodel is considered as a composition of different homogeneous or heterogeneous submodels at several abstraction levels. This approach helps the building of hierarchical models of real-world systems which cannot be simulated easily by using one monolithic model [Fishwick 93, Fishwick 95]. The Multimodelling approach [Brajnik 90, Chittaro 92, Chittaro 93] is characterised by the representation of many diverse, explicit models of a system, which are used in a cooperative way in specific problem solving tasks. The fundamental assumptions about knowledge modelling and reasoning mechanisms in the Multimodelling approach do not identify a unique way of representing a physical system and reasoning about it. On the contrary, the Multimodelling approach is an abstract and general framework that allows for a variety of specific implementations. In this sense, similar approaches have been proposed for several researchers [Weld 92, Struss 92, Iwasaki 92, Loia 97, Leitch 99, Struss 99, Coghill 01, Snooke 02], but we are based on the work of Chittaro et al. The fundamental concepts in Multimodelling are: 48 MODELLING AS PART OF THE REDESIGN PROCESS 3.4 1. Ontologies. The descriptions of entities in the real system. Two types of ontologies can be distinguished: •Object-centred ontology. The real world is made up of individual objects whose properties can be stated in an objective, context independent and general way. •System-centred ontology. The real world is made up of systems, intended as organised units, whose elements cannot be defined in isolation. 2. Representational assumptions. This issue concerns about what to represent of the real system in the model. This involves two basic aspects: •The scope of the model, i.e., the aspects of the real system which are considered relevant to the purpose of the model. •The precision of the model, i.e., the degree of accuracy of the representation 3. Epistemological types. The type of knowledge represented in the model. These types can be: •Structural. The knowledge about system topology, i.e., the equipment that constitute the system and how they are linked. •Behavioural. The knowledge that describes how equipment work and interact in terms of the physical quantities (variables and parameters). •Functional. The knowledge about the role of equipment plays in the physical processes in which they take part. This knowledge relates the behaviour of the system to its goals, and deals with functional roles, processes, and phenomena. •Teleological. The knowledge about the goals assigned to the system by its designer and about the operational conditions that allow their achievement through correct operation. •Empirical. The knowledge concerning the explicit representation of the system properties through empirical associations (such as observation, experimentation, and experience). This knowledge may include subjective competence that usually human experts acquire through direct interaction with the system. 4. Aggregation levels. The degree of granularity of the represented knowledge. For a physical system several models featuring different aggregation levels may be identified. Taking into account the concepts described, ontological, representational, epistemological, and aggregation links may be established between the models of a same system. Each link relates one model to the others by connecting explicitly corresponding knowledge 3.5 CHAPTER CONCLUSIONS 49 elements in different models. Therefore, there are two restrictions in the organisation of models, which are the following: •Models must be separated. Any individual model may encompass only one specific choice about ontology, representational assumptions, epistemological types, and aggregation levels. •Models must be interconnected. Any individual model must be explicitly and properly interconnected to others with appropriate ontological, representational, epistemological or aggregation links. According to the specific problem-solving task considered, different types of knowledge may be useful at different times and with different roles. Therefore, their representation must be separate as much as possible. 3.5 Chapter conclusions In this chapter the description of the modelling approaches used and extended in this thesis were shown. First, the approach employed to model the redesign process has been presented in subsection §3.2. Later, the theoretical basis of the approaches employed on the redesign object is explained in subsection §3.3. The existing redesign approaches, based on formal or informal theories, have as objective to obtain design alternatives. Depending on the context, these approaches contain certain number of stages. Basically these approaches follow the basic system engineering principles. These principles give a good base to obtain a suitable logical structure of reasoning. The specialisation of these principles depends on the application domain. Thus, we decided to take these principles as the basis to propose a redesign framework. Our objective is to obtain a framework that operates with functional abstract concepts to support conceptual redesign activities. A redesign approach can be very detailed, or not, depending on the modelling approach used in the redesign object. The easiness of manipulation of redesign object affects the redesign activities, which affect the overall redesign approach. Thus, it is important that the modelling approach applied on the redesign object represents the information in a coherent and helpful form. Hierarchical modelling is a good modelling approach especially to model complex systems. In redesign, the amount of information is enormous, and may become unmanageable if it 50 MODELLING AS PART OF THE REDESIGN PROCESS 3.5 is not represented properly. Therefore, the designer should organise the information on several levels of detail. In physical domains this kind of modelling can be performed by means of the modelling of functions. In essence, functions are abstractions of fundamental knowledge (structure and behaviour knowledge). In this manner, functional modelling satisfies the hierarchical modelling issues. Taking into account the cognitive point of view (i.e., how a designer works), the functional modelling approaches selected are Multilevel Flow Modelling (MFM) and Multimodelling. The aim of MFM is to provide a systematic basis for using means-end and whole-part decompositions in the modelling of complex systems. Thus, a system is described in terms of goals, functions and the physical components. At the same time, each of these descriptions can be given on different levels of whole-part decompositions. Thus, this approach reflects the natural way (high level of abstraction) how a human designer creates models about the system. In the same sense, the Multimodelling approach states that the addition of a cognitive point of view enhances the representation of information and the reasoning strategies used. Similar to the MFM approach, Multimodelling allow to represent information on several abstraction levels based on four basic concepts: ontologies, representational assumptions, epistemological types and aggregation levels. The difference between these approaches is that, while MFM is focused on high-level abstractions, Multimodelling is focused on intermediate levels of abstractions, dealing and explaining physical phenomena. We propose to integrate these two modelling approaches as is described in next chapter where the redesign framework is presented. The framework is guided by the system engineering process principles. The described hierarchical modelling approaches are used as the modelling approach employed in the framework. The aim is to obtain a redesign framework for complex technical systems. In this sense, high and intermediate levels of abstractions will be employed in the manipulation of the redesign object. CHAPTER FOUR The Redesign Framework In this chapter the proposed redesign framework is described in detail. The theories described in the previous chapter are extended to clarify the cognitive view of the framework. Thus, extending the general engineering process the proposed redesign framework is structured. The main stages of the framework are explained taking into account the modelling approach, which is the core of the overall framework. Diagnosis and case-base approaches are included in the framework to facilitate the redesign activities. 4.1 Introduction As was explained in the previous chapter, cognitive issues about how humans model complex systems must be considered. Section §4.2 of this chapter gives a general description of the overall process; the methodologies described in Chapter 3 are related. Then, in section §4.3 the redesign framework is presented, each one of the main stages is described in detail. Implementation issues are not provided in this chapter, only the theoretical base of the framework. The particular implementation of the framework will be specific to the domain of application. 51 52 THE REDESIGN FRAMEWORK 4.2 4.2 General description In the redesign of complex systems the modelling approach employed is crucial to facilitate the redesign activities in the overall redesign stages. The appropriate modelling of the redesign object gives a better understanding of what and how to perform the redesign. The inclusion of the cognitive point of view has been considered an important aspect to identify the most important functions and sections within a process. This gives an approximation to the intentions of the human designer when he/she performs redesign. Human designers model complex processes by using mental models about it. Intuitively the designer organises such mental models hierarchically for a better understanding of the process. The Multilevel Flow Modelling (MFM) [Lind 90, Lind 94, Lind 99] and the Multimodelling [Brajnik 90, Chittaro 92, Chittaro 93] approaches are able to represent how the human designers behave during the redesign process. Thus, as part of this thesis, the Multilevel Flow Modelling (MFM) and Multimodelling approaches were applied to redesign of complex processes. MFM can be used for high-levels of abstractions and Multimodelling is more suitable for the intermediate and lower levels. Thus, the structure and behaviour of the equipment are abstracted using the Multimodelling approach and then this abstraction is mapped to the MFM approach. The bridge between both approaches are the functions for the equipment in the domain. This functional modelling is the basis to manipulate the process during all the redesign process. System engineering principles are considered as basis to structure the redesign framework. The framework extends the basic structure adapting it to the redesign of technical processes. Each stage of the redesign process is formed by simpler tasks. These tasks correspond to conceptual redesign, i.e., the tasks do not consider directly all details of real equipment in performance. As mentioned earlier, the general objective of this framework is obtain an alternative process design at the conceptual level. This is based on the following ideas about how human designers behave: 1. The sections of the process can be identified in similar way as the designer does it in the original design. 2. Abstracts concepts of the equipment should be taken into account when the process is modelled. 3. Similar sections of the current process can be extracted from other processes to guide the modifications/substitutions in the current process. 4.2 GENERAL DESCRIPTION 53 4. The human designer may evaluate the suggested sections until the redesign objectives are satisfied. The main idea is to model hierarchically the process and reason by using functional abstract concepts. In this way the designer can “navigate” in top-down and bottom-up directions in the representation in similar way as when the designer creates its mental models about the process. The first step is to obtain the design description1. The best way is to extract this data is from a simulator. In this way, human errors in the data acquisition are avoided. An interface between the simulator and the redesign framework is required. Then, with these data is possible to model the process. Each equipment is modelled by means of structural, behavioural, functional and teleological models (as states the Multimodelling approach). Depending on the function of each equipment the most important functional sections of the process are identified. Equipment with lower functional importance are grouped with the most important ones. Thus, a hierarchy of the functional sections of the process is generated. This represents a tree-structure graph where the root denotes the most important functional section of the process, the rest of functions help it to achieve the goal of the overall process. When the hierarchical representation of the existing system has been generated, the designer must identify the most promising equipment/sections to be modified or substituted according to the new specifications imposed to the system. This is supported by a diagnostic algorithm using the functional abstract models identified in the modelling process. When the appropriate equipment or section has been chosen, similar equipment or sections can be extracted from a case library based on such equipment or section. This is done using a case-based reasoning approach. The human designer may evaluate the most promising retrieved equipment or sections until a suitable alternative process design that fulfills the new specifications is obtained. Note that this is an abstract conceptual alternative design that has not been physically implemented yet. We have decided combine the model-based and case-based techniques for a better management of abstract data. The model-based approach is useful for deal with the generation of the process representation because provide a good base to generate abstract models. But for suggest alternative models it would require a complex rule-based system with a high-consistent rule base for a complete validation of entire models. It requires rules of general aplication in the domain for a good performance, which is not always possible. 1The design description is an abstract representation about the process to be redesigned. 54 THE REDESIGN FRAMEWORK 4.3 Instead the case-based approach, from a technical point of view, is a psychologically reasonable technique for model human reasoning by using past experiences. It do not require ”standardised” codified principles (globally accepted in the domain) for give results, it can provide approximated results by using ”light” models of the domain. In summary, in the reasoning for suggest alternative models the model-based approach requires complete knowledge and the case-based approach not. However, if the models of a domain can be formalised the case-based approach can be omitted and the model-based approach can be applied completely in the overall redesign framework 4.3 Redesign stages As mentioned above, the structure of the proposed redesign framework is based on the structure of the general engineering process. The stages of the general engineering process have been divided according to redesign tasks. The redesign framework proposed is shown in the Figure 4.1. Structure/ Behaviour Simulator data acquisition the most similar unit/meta-unit Human Designer candidate identification to modification/substitution functional ontology functional units/meta-units library redesign heuristics of processes retrieving units/meta-units new requeriments computing adaptation costs Structure/ Behaviour/ Function/ Teleology Design-description acquisition Candidate Identification Generation of alternatives Adaptation and evaluation of alternative processs designs Generation of cases Functional identification functional units identification functional meta-units identification equation systems satisfaction Reasoner Figure 4.1: Proposed redesign framework. From an abstract point of view, there are three actors that play an independent role in this framework: 1. The simulator. The commercial software used to obtain the design description of the 4.3 REDESIGN STAGES 55 process and to implement and evaluate the generated alternative process designs. In this part only structural and behavioural information is manipulated. 2. The reasoner. The software modules required to model the process, identify the suitable equipment/section to be modified and obtain similar equipment/sections based on the selected equipment/section. In this part structural, behavioural, functional, and teleological information is manipulated. 3. The human designer. The human designer provides the input to the system and interprets the results. According to the general engineering process, four general redesign stages are identified: 1. Design-description acquisition. This stage is composed of two substages: •Data acquisition. The data of the process is obtained from a specialised simulator to avoid human errors in the introduction of data and to save time. •Functional analysis. With the extracted data, the process is modelled. Functional equipment identification and functional section identification are performed. 2. Candidate identification. Given the modelled process, the redesign criteria, and the human designer expertise, the most suitable candidates for modification or substitution are identified. 3. Generation of alternatives. Based on the identified candidates at the previous stage, similar ones are extracted from a library of equipment/sections of other processes. 4. Adaptation and evaluation. The most similar extracted equipment/sections are adapted into the process to evaluate its performance in the overall process. This is an iterative cycle that finishes until an appropriate alternative process design is obtained according to the new established objectives. Mapping the stages of the redesign framework to stages of the basic systems engineering process, the corresponding stages can be described as follows: 1. Identification of objectives and criteria. This stage covers the design-description acquisition and the identification of candidates stages of the framework. 2. Generation of design alternatives. This stage is similar to the obtaining alternatives and adaptation stages in the framework. 62 THE REDESIGN FRAMEWORK 4.3 Function Teleology Structure Function Teleology Structure Function Teleology Structure Behaviour detail - + Behaviour Behaviour Figure 4.6: Abstraction of a process. Thus, a process is represented as a tree. At the same time, this tree is composed of subtrees. A subtree represents a meta-unit (functional section). The union of all subtrees denotes the overall process. Every sub-tree also represents a flow structure with a coherent objective, the goal of the functional section. The aim of this abstraction process is not the generation of abstract models for the qualitative simulation of the process. In the redesign framework, the simulation is an activity that only can be performed with specialised and external simulators. This is a topic out of the scope of this thesis. The main objective of the modelling stage is to obtain a qualitative and complete knowledge representation at different levels of detail3. 4.3.2 Candidate identification The aim of this stage is to get the suitable unit or meta-unit to be modified to fulfill the redesign objectives. To perform this task, the design description of the process and the specification of the requirements that the process must satisfy are required. Some redesign approaches consider this stage as the first stage in the redesign process. In a first instance, the redesign must be focused on a process variable. Once the variable is identified, a diagnostic algorithm is used to identify the units/meta-units affecting such process variable. This reasoning process is based on the functions identified at the functional analysis stage. For that reason the ontology used must specify the process variable involved in every function of the process. In the redesign framework, this stage 3Complete in the sense that involves all the desired characteristics of the knowledge representation in redesign activities. 4.3 REDESIGN STAGES 63 is composed of two substages: specification of redesign requirements and identification of the suitable unit or meta-unit for modification or substitution. 4.3.2.1 Specification of redesign requirements In this stage the human designer must specify the new requirements that the process must satisfy. The content of a redesign specification is illustrated in Figure 4.7. Two categories of redesign requirement can be identified: functional requirements and physical requirements. A design specification always contains a single functional requirement; it may also contain a set of physical requirements. Functional requirement Function to be provided Redesign requirements Physical requirement Preferences values on process variables Figure 4.7: Content of redesign specification. A functional requirement represents an abstraction of the intended behaviour of the product. It can be a general, specific, or working function. There is no direct association between the function that has to be provided and the physical mechanism that provides it. A design specification should never be specific about the intended behaviour of a product. Physical requirements represent an abstraction of the physical process variables, which satisfy the functional requirement specified in the design specification. It denotes preferences about the designer intentions regarding some aspect of the process. For example, a physical requirement may be related to the value of a process variable. A preference for a value may mean to set thresholds according to the desired effect in the overall process. The redesign specification can be represented by the functional and physical requirements or only by physical requirements. For example “Increase pressure of water in 120 kPa” or “Increase concentration of the main product”. 64 THE REDESIGN FRAMEWORK 4.3 A redesign specification is a means (goal) which is defined in terms of functions that must be embodied in a process in order to provide some higher level functionality. The functions that define a redesign specification, generally, have a number of context relations defined between them. These context relations describe how the parts in the process that provide these functions, should be configured to achieve the redesign specification. Thus, the units/meta-units which function or process variables may be involved in the achievement of the redesign specification must be identified, they are named candidates. 4.3.2.2 Identification of candidates The design description and the new specifications are used to identify the possible candidates for modification or substitution. To perform this task, the framework employs a diagnostic algorithm based on the functional concepts identified in the functional analysis. Diagnosis helps us to detect “faulty” components in the process. In other words, those components that do not satisfy the global performance of the process. We consider that units or meta-units affected by the redesign specification are “faulty” because its current performance will contradict the new redesign specification. Thus, the aim of this stage is to identify the units or meta-units that affect the process variables represented in the redesign specification. The diagnostic algorithm returns an ordered list of units or meta-units. Because the diagnostic algorithm operates over abstract functional concepts, no simulation is required. The diagnostic algorithm does not return the exact unit or meta-unit responsible for the “faulty” behaviour, it returns a list of units/meta-units that do not fulfill the global performance of the process represented by the redesign specification. The human designer is responsible for choosing, from the resulting list, the appropriate unit/meta-unit that has to be modified or substituted into the process. Since this unit/meta-unit is connected to others by a flow path (Figure 4.8), the “cause” and “consequence” units/meta-units also must be identified. These units/meta-units are defined as follows. definition: Cause unit/meta-unit is(are) the unit(s)/meta-unit(s) situated before the current unit/meta-unit in the flow path. They are responsible to provide the appropriate operational conditions to the involved process variables in the function of the unit/meta-unit of interest. 4.3 REDESIGN STAGES 65 unit affecting variable X unit affecting variable Y unit of interest affecting variable X unit affecting variable X cause unit consequence unit Not cause unit Figure 4.8: Cause and consequence units/meta-units for variable X. definition: Consequence unit/meta-unit is(are) the unit(s)/meta-unit(s) situated after the current unit/meta-unit in the flow path. They are the unit(s)/meta-unit(s) affected by the operational conditions given by the unit/meta-unit of interest. Both, the cause and the consequence units/meta-units, are not necessarily the closest neighbours. The diagnostic algorithm employs the causal relationship of the process variable involved in the functions to find these units/meta-units. A unit/meta-unit can receive several process variables, but its behaviour may affect only one, see Figure 4.8. Given the selected unit/meta-unit, similar units/meta-units are retrieved from other processes. Any of the retrieved units/meta-units may substitute the selected unit/meta-unit or can be used to modify it. The modification or substitution depends on the operational conditions provided by the identified cause and consequence units/meta-units. The diagnostic algorithm employed is described next. The diagnostic algorithm The diagnostic algorithm employs functional models with a very high level of abstraction, combined with a teleological representation of goals (or purposes) of the process. This algorithm is an extention of the work of Larsson [Larsson 96]. The inputs come from structural, behavioural, functional models, and the redesign specification introduced by the human designer. As was mentioned before, the redesign specification concerns to functional and behavioural 66 THE REDESIGN FRAMEWORK 4.3 information, structural and teleological information is not given explicitly. Our framework uses values from simulated behavioural models. Flow values are assigned to the attributes of the appropriate flow functions according to the functional ontology. Diagnosis operates over these flow values. The knowledge representation used must relate every function to the notion of flow (mass and energy), i.e., the process variables involved in the achievement of the function. Thus, the relationships between flow structures and functions of a process are described by teleological relations, which connect the flow structures into a graph, built at the modelling stage. This allows the diagnostic reasoning to be implemented as search in the graph structure. The model of the process (the redesign object) consists of several connected flow functions, which aims to fullfil a set of objectives (and goals). A flow function within this structure is primarily responsible for the achievement of a specific objective, while others serve to assist that function. It is possible to make explicit such differences between flow functions of the same flow structure by referring to main functions and assisting functions, respectively. The integrity of main functions is often accomplished by the behaviour of other components or subsystems performing assisting functions. This is relevant in the causal analysis performed by the diagnostic algorithm. The purpose of a process (i.e. the intention of its function) is a result of the interaction of its components in a specific way to achieve overall goals, by means of causal interactions. Flow functions can be evaluated using two types of constraints defined in relation to their port variables and state variables [Lind 90]. The first type of constraints are the socalled balance equations prescribing the basic normal behaviour in terms of mass and energy conservation laws formulated in relations to the input and output port variables of flow functions. The second type of constraints, the so called state constraints, prescribe the intended operational performance of flow function in relation to their respective state variables. The balance equations and the state constraints describe different levels of process constraints. The former refers to the correct workings of the individual components (no leaks etc.) while the latter refers to intended behaviour of the mass and energy transformation processes that have to be maintained by means of proper management of the flow structures. The two types of constraints are formulated as shown Table 1. Here, the means-end dependencies are explicitly represented. Therefore, when a certain process variable does not have the appropriate operational conditions, the function fails and the goal is not achieved (i.e., a fault occurs). The model provides information on which functions may be faulty, and, thus, in which component a reason for failure can be found. 4.3 REDESIGN STAGES 67 Flow Function Balance Equation State Constraint Transport Fin = Fout Flow <= F <= Fhigh Storage PFout =PFin + dV / dt Vlow <= V <= Vhigh Balance PFin =PFout Barrier Fin = Fout = F F = 0 Source Fout = Funknow + dV / dt Vlow <= V <= Vhigh Sink Fin = Funknow + dV / dt Vlow <= V <= Vhigh Table 4.1: Balance equations and state constraints for flow functions. The operational conditions for flow functions might be in a normal or working state, or have a fault. Thus, based on the operational conditions it is possible to define discrete qualitative states of flow functions in relation to the constraints defined in Table 4.1. The possible abnormal states for each flow function are defined in Appendix B. By using the defined ontology, several qualitative states can be identified over such concepts (process variables) in a process. These states represent the performing state of a flow function. Then, these states denote failures on flow functions that do not satisfy the redesign specification. Some of them are directly connected to primary sources of error, but others may be secondary. In a failure state it is vital to separate the primary from the secondary failures. The fault diagnostic algorithm must have a way of finding out the failure states of the components corresponding to the different flow functions. Thus, each flow function may have a question to be asked, or a test to be performed, in order to investigate the failure state of the function. Search strategy The general model of the process (the redesign object) consists of information about the goals of the process, how these goals are achieved by networks of functions, how the functions depend on subgoals, and how they are performed by equipment. The fault diagnosis can be implemented as a search in the model graph. The fault diagnostic algorithm traverses the MFM graph (the hierarchical model of the process), and when it arrive to single flow functions it uses diagnostic questions4(con4A diagnostic question is associated with each flow function to relate it with a possible fault. Examples of diagnostic questions are: Is important the value of variable X in this function ?, Must be considered 68 THE REDESIGN FRAMEWORK 4.3 sidering values of process variables) to find the failure state of those flow functions. Depending on the answers (or values of variables), parts of the flow model may not have to be crossed. The algorithm is combined with an analysis of operating conditions and consequence propagation, which is performed incrementally as information comes in, and alternates with the diagnostic algorithm. The simple rule for successful matching of diagnosis and consequence propagation (i.e., guessing of consequences), is that every flow function should have either a diagnostic question/values of variables or be subject to guessing. The specific topics of the diagnostic search are as follows: 1. The user selects a goal for diagnosis (specified by the functional and physical requirements). If this is in top-level, the whole model (and thus the whole process) will be investigated. However, the goal chosen can also be a subgoal, in which case only a section of the process will be diagnosed. 2. The search propagates downwards from the goal, via achieve relations, into the connected network of flow functions, each of which is now investigated. 3. Each flow function may have a diagnostic question, which is asked in order to find out whether the corresponding physical component is currently performing the function, i.e., whether the function is available or not. Alternatively, there can be a rule or relation to an equipment, where information about the working order of the function can be found. 4. The appropriate state of the flow function is set, and the state analysis and consequence propagation algorithms are activated. 5. If a flow function conditioned by a subgoal is found to be at fault, or has no way to be checked, the connected subgoal is recursively investigated. However, if a function is working, this part of the sub-tree is skipped. This simple fault diagnostic method is very efficient and fast because the propagation is in the direction of static connections. Additionally the model graphs used are small making the traverse path very short. Thus neither global search, pattern matching, nor conflict resolution are needed, and the algorithm is very efficient with fast execution. 4.3.3 Generation of alternatives The aim of this stage is to obtain similar units (equipment) or meta-units (sections) to adapt them into the current process based on the suitable unit/meta-unit identified by minimal magnitude in variable Y ? 4.3 REDESIGN STAGES 69 the human designer at the last stage. The best way to obtain similar units/meta-units is from similar processes. With the adaptation of any retrieved unit/meta-unit into the process of interest, then the alternative process design is obtained, which is the final goal of the redesign framework. An appropriate approach to perform this stage is case-based reasoning (CBR) because its philosophy is the reuse of past experiences on new situations [Aamodt 94]. In addition, the complete cycle of CBR corresponds exactly to the remaining stages of the redesign framework. Thus, in this stage, only a part of the CBR cycle will be explained, the rest will be explained in the section §4.3.4. 4.3.3.1 The case-based reasoning approach Case-based reasoning is a computational paradigm based on the idea that adapting solutions that were used to solve old problems can help to solve similar problems [Aamodt 94]. Therefore, a CBR system requires: •a cases library where each case describes a problem and a solution to a particular problem, and •a similarity engine to compute the similarities between cases. A CBR system consists of four essential stages [Aamodt 94], as shown in Figure 4.9: 1. Retrieve, where the most similar cases (source cases) to the new problem specifications (target case) are retrieved from the case library. 2. Reuse, where the retrieved cases are modified with the aim of solving the target case. 3. Revise, where the adapted source cases are verified to determine their capability to the target case. 4. Retain, where the best adapted case is saved into the case library if it solves the new problem. 4.3.3.2 Case-based reasoning in the redesign framework Starting with the selected unit/meta-unit at the candidate identification stage, similar units/meta-units can be retrieved from other processes. The retrieved unit/meta-unit 70 THE REDESIGN FRAMEWORK 4.3 Figure 4.9: Stages of the CBR cycle [Aamodt 94]. 4.3 REDESIGN STAGES 71 which functional and teleological models are the most approximate to the functional and teleological models of the unit/meta-unit of interest is adapted. This process requires that the performance and operational conditions of the cause and consequence units/metaunits associated with the retrieved unit must be similar to the original case. The structure of the CBR system is shown in Figure 4.10. The reasoning process to obtain alternatives in the framework corresponds to the retrieve stage of CBR and the adaptation and evaluation stages in the redesign framework correspond to the reuse, revision and retention stages of the CBR cycle. Structure/ Behaviour most similar unit/meta-unit functional ontology functional units/meta-units library retrieving units/meta-units computing adaptation costs Generation of alternatives Adaptation and evaluation of alternative processs designs equation systems satisfaction redesign heuristics of processes Simulator Structure/ Behaviour/ Function/ Teleology (Retrieve stage) (Adaptation and evaluation stages) Retention stage Generation of cases Functional identification functional units identification functional meta-units identification Human Designer Figure 4.10: The CBR system in the framework. As was described previously, the overall process was modelled as a graph denoting a hierarchy of functions. Therefore hierarchical case-based reasoning [Branting 95, Smyth 01] is requried. Hierarchical CBR is an approach in which abstract solutions produced during hierarchical problem solving are used to assist case-based retrieval, matching, and adaptation [Branting 95]. 4.3.3.3 Definition of cases Based on the levels of abstraction, two kinds of cases are distinguished (see Figure 4.11): •ground cases. Cases located at the lowest level of abstraction, units (real equipment), 78 THE REDESIGN FRAMEWORK 4.3 The teleological model denotes features of the intention or goal of the unit/meta-unit. In such way, those features are totally related between them. Unsupervised changes on these features may cause indirectly the aim of a totally different intention. Therefore, this shows that the intention depends strongly on the structural, behavioural and functional models. Consequently the computation of this feature involves, in abstract manner, the mentioned models concerning the intention. In the second cycle, functional and hierarchical local similarities are computed. The functional similarity is obtained by using the symbolic and numerical similarity measures of the functional features of the target and source cases. The most relevant aspects of such description are shown in Figure 4.15. Functional features Functions of the unit Input functions Output functions Number of input functions Number of output functions Figure 4.15: The functional similarity measurements. In this way, the functional models denote the function of the current unit/meta-unit and the functions of its neighbours. We expect to obtain units/meta-units with at least the same specific function of the unit/meta-unit of interest. Changes on neighbour functions may not affect directly its performance. At the same time, hierarchical similarity is obtained. This is done only in meta-units because a meta-unit is a tree-like structure, while a unit is not. Ideally the best option, in this measure, is to obtain meta-units containing similar units/meta-units at similar abstraction levels. The hierarchical similarity is obtained from the abstract description of the functional structure of parents and children. The considered aspects are shown in Figure 4.16. Finally, the promising units/meta-units are obtained by calculating the global similarity measure in the third cycle. This applies the Euclidean algorithm described in Equation 4.1. The teleological, functional and hierarchical similarities computed over every extracted unit/meta-unit are used in this cycle. The more similar units/meta-units are represented by the higher scores of combining these local similarities. Thus, as final result, a set of cases is obtained which contains meta-units (with its corresponding units/meta- 4.3 REDESIGN STAGES 79 Hierarchical features Number of levels Number of functions Involved functions Parent functions Children Functions Figure 4.16: The hierarchical similarity measurements. units) or units. The set is ranked according to the global similarity between the target case (the unit/meta-unit of interest) and the source cases (the retrieved units/meta-units). 4.3.4 Adaptation and evaluation The reuse, revision, and retention stages of the CBR cycle correspond to the adaptation and evaluation stages at the redesign framework (Figure 4.10). Although the retention is not an explicit stage of the framework, is carried out in this stage. The aim of the reuse stage is the adaptation of the most similar cases into the process. The aim of the revision stage is the evaluation of the performance of the adapted case into the process. Both stages are not systematised in the redesign framework, the human designer must carry them out manually using the specialised simulator employed in the data acquisition. The adaptation is highly domain-dependent and requires online simulation of the process to verify its correct performance. Since information of abstract cases can not be used directly, the adaptation and revision stages must use information of ground cases (real equipment on the simulator). Consequently to carry out both stages it is necessary to simulate the overall process. These stages are carried out almost at the same time on the simulator. The human designer simultaneously must fit the ground cases with the process variables involved. To facilitate the adaptation, for each retrieved case, adaptation costs are computed to suggest to the human designer the adaptability of the chosen unit/meta-unit into the current process. 80 THE REDESIGN FRAMEWORK 4.3 The adaptation cost The adaptation cost is based on the differences of the selected unit (source case) and the cause and consequence units/meta-units identified in the Candidate Identification stage (see section §4.3.2). In this way, all the units/meta-units at the inlet and outlet path (of the unit/meta-unit of interest) in the process are taken into account. Thus, the adaptation cost is a normalised numerical value denoting the difference on the values of the process variables involved in the performance of the unit/meta-unit of interest and the values of the process variables involved in the performance of the neighbour units/meta-units. For example, it will be easier to adapt a unit/meta-unit with small differences on its inlet temperature that one with large differences on the same temperature. Equation 4.6 shows the calculation of the adaptation cost: adaptation cost = 1 −"1 p p X i=1 "|source valuei−α valuei| range ## (4.6) where, iis the process variable, αis a cause or consequence unit, range is the absolute value of differences between the upper and lower boundary of the range where source valueiand αvalueifall, and pis the number of process variables. The adaptation cost has a value between 0 and 1. Values close to zero mean the adaptation is difficult. With the computed adaptation cost the human designer can operate over the process on the simulator. The designer experience is determinant because modifications on equipment may affect the overall performance of the process. The modification of the original process, based on the adaptation of a retrieved case, generates an alternative of the process for every unit/meta-unit adapted. This alternative is known as alternative process design. The final activity is to store the adapted cases in the case library for future alternative process design generation. When an abstract case is adapted into the process, it represents a new case that must be stored in the case library. The storing process is similar when new units and meta-units are generated in the modelling stage of the framework. In this task the alternative process design is not retained entirely, only the cases (units or metaunits) obtained/derived from the case library. It is important to maintain the consistency 4.4 CHAPTER CONCLUSIONS 81 of the adapted case and its relations to the overall process, such as neighbour functions, information of connections, information of the goal, etc. 4.4 Chapter conclusions This chapter has described our approach to conceptual redesign. Basically the redesign process is as follows. The input to the redesign process is the models of the process that has to be redesigned. Based on these models and the new requirements that the process must fulfill, the equipment (or section of the process) which can not achieve the overall performance of the process are identified. Those equipment or sections must be modified or substituted. To do this, similar equipment from other processes must be obtained to adapt them into the process. Thus, the human designer can test several alternative equipment (or connections of equipment) until the desired performance of the overall process is found. Therefore this chapter presents a novel perspective of the redesign process. The framework is based on the well-known general engineering process. The novelty is the approach used in the knowledge representation. Since our aim is the redesign of complex technical processes, we propose the use of a modelling approach taking into account cognitive aspects. The modelling approach is based in an extension of the Multilevel Flow Modelling [Lind 90, Lind 94, Lind 99] and Multimodelling [Brajnik 90, Chittaro 92, Chittaro 93] approaches. The cognitive basis is necessary for a better understanding of the process and consequently a better managing of complexity in all the redesign activities. We propose the use of structural, behavioural, functional and teleological models to represent the equipment of a process exploiting means-end relationships. Based on these models the process (the redesign object) can be represented hierarchically. The hierarchical representation simplifies the process using approximations at several levels of detail. Such representation facilitates the identification of the suitable parts of the process to be modified or substituted. In order to assist to human designers during conceptual redesign the computer tool employed needs be to capable of reasoning about the fundamental (structure and behavioural information) and interpretative (functional and teleological information) aspects of the process. Thus, the proposed framework is composed of the following stages: designdescription acquisition, candidate identification, generation of alternatives, and adaptation and evaluation. The framework can be applied to well-structured functional domains. Although the framework deals with complex technical process, not embedded simulations 82 THE REDESIGN FRAMEWORK 4.4 are performed in the framework. The core of the modelling approach of the framework exploit functional and teleological models emphasising the no function in structure principle. The redesign framework proposed in this chapter no tackles a specific domain. In the next chapter the implementation of the framework in the domain of Chemical Engineering is presented. CHAPTER FIVE Implementation of the framework The implementation issues of the redesign framework are given in this chapter. The processes considered are from the Chemical Engineering domain. The software modules of the main stages of the redesign framework are described. The implementation includes the major complete algorithms. 5.1 Introduction In this chapter the implementation of the redesign framework is given. The framework has been applied to the Chemical Engineering domain by two reasons; the first was because the research was developed in a multidisciplinary group of Computer Science and Chemical Engineering people. Therefore, common ideas about the framework were applied to this thesis and in the thesis obtained in Chemical Engineering [Rodr´ıguez-Mart´ınez 05]. The second was because the assumptions given in section §1.4 (scope of the work) were fulfilled for the issues involved in a chemical plant. These contributed in generating and improving others assumptions in the Chemical Engineering thesis [Rodr´ıguez-Mart´ınez 05]. The stages of the redesign framework were described in Chapter 4. These stages are now implemented over chemical processes (a chemical plant can be constituted of one or more chemical processes). Thus, firstly in section §5.2 a brief introduction to some aspects of chemical processes is given to the reader to get a better understanding of why the domain was chosen and how the framework developed can be applied. 83 84 IMPLEMENTATION OF THE FRAMEWORK 5.2 Some assumptions and limitations are highlighted in section §5.3 concerning the design process and the type of chemical processes to understand the ontological concepts employed. Chemical processes are the object to be redesigned, and the idea of complex system is completely fulfilled by this kind of technical processes as this processes has several equipment (each one with a specific task) connected by streams. Therefore, the used concepts of the domain contitute the ontology decribed in section §5.4. Based on the ontological assumptions, the elements of the generic data structure used in the software modules are presented in section §5.5. The software modules of the redesign framework for chemical process domain are presented in section §5.6. These have been implemented in Java [Sun 05], additional libraries have been used such as JESS1[JESS 04], Ozone2[Ozone 03], and The Selection Engine3[Wetzel 00]. The interaction with the user is done through a graphical interface to facilitate the interpretation of results. The main framework described in the previous chapter could be applied to other processes but not this implementation as it is specific to chemical process redesign. 5.2 General aspects of Chemical Engineering Chemical Engineering is the branch of engineering that is concerned with the design, construction and operation of the plants and machinery used in industrial chemical processes [Britannica 05]. It is one of the broadest fields of engineering, this breadth stems from the fact that the discipline is founded on mathematics and on all the basic sciences, namely, chemistry, physics, as well as biology, making it a truly interdisciplinary field of study [WPI 05]. Thus, by applying science, mathematics, and economics Chemical Engineering converts starting materials or chemicals into more useful forms. That is done through operations called chemical processes, which often consist of many separated and independent steps. Such chemical processing results in thousands of products that are part of virtually every aspect of our lives [Biggs 03], such as: •Oil industry, 1JESS (Java Expert System Shell) is the Java version of CLIPS (C Language Integrated Production System). 2Ozone is an Object Oriented Data Base Manager implemented entirely in Java. It allows all the data base operations by using Java objects. 3The Selection Engine is an open source case-based reasoning engine written in Java. It provides basic matching for numbers, strings and booleans. 5.3 GENERAL ASPECTS OF CHEMICAL ENGINEERING 85 •Foods and drinks, •Chemical and allied products, •Household products (washing powder,...), •Process plant manufacture and construction, •Personal care (cosmetics, moisturisers,...), •Pharmaceutical (aspirin, hormones, drug delivery,...), •Materials (silicon chips, porous media, catalysts,...). Thus, Chemical Engineering deals with the development and application of manufacturing processes in which chemical and physical transformation of raw materials is carried out to obtain valuable products. This involves all aspects of design, testing, scale-up, operation, control, and optimisation, and requires a detailed understanding of the several “unit operations” (equipment of the process), such as distillation, mixing, and biological processes, which make these conversions possible. Conservation of mass, momentum, and energy transfer along with thermodynamics and chemical kinetics are applied to analyse and design all “unit operations”. These processes cover from the nano-scale (design of catalysts, or molecular design of drugs) to the meso-scale (petroleum refinery) to the global-scale (air pollution modelling and control). Constantly, new methods are developed or adapted to manage energy resources as well as commercial consumer products. This involves the (re)design of reliable, cost effective manufacturing plants and implement pollution control systems. Then, new technologies are researched, developed, or applied to improve the design of systems and products. Within Chemical Engineering, there are several working areas such as heat transfer, fluid dynamics, chemical reaction kinetics, thermodynamics, separation operations, materials science, process control, and plant design. A recent area is Process Systems Engineering, which is concerned with the understanding and development of systematic procedures for the design and operation of chemical processes, ranging from microsystems to industrial scale continuous and batch processes [Grossmann 00]. Our research has been focused in this area. As mentioned in Chapter 2, redesign of chemical process have been carried out in two directions: optimisation of energy consumption, and synthesis and design of processes. The implementation of our redesign framework will be explained considering the latter direction. The novelty of our approach is that Model-Based Reasoning has been combined with Case-Based Reasoning to redesign chemical process. 86 IMPLEMENTATION OF THE FRAMEWORK 5.3 5.3 Process design assumptions With the aim to situate the reader in the field of implementation, some assumptions must be described, basic assumptions about the process of redesign and ontological assumptions are described in this subsection. 5.3.1 Basic assumptions The design process can not be seen as a kind of general routine activity suitable to be fully computerised [Ba˜nares-Alc´antara 95]. Fortunately, recent work has placed the human designer in a central role in process design and, as a consequence, a more realistic view concerning process design and AI has arisen [Ballinger 94, Han 95]. Thus human beings are crucial in the development of the redesign framework. The chemical process has been viewed as an artefact, which is the result of human interference with the nature by taking spontaneous phenomena under control or forcing non-spontaneous processes. Thus, the design process has been characterised as follows: •Redesign is a creative activity. This issue limits on how process design is systematised and how “detailed” a level is attainable. It does not follow that the design activity for building methodologies did not contain a good amount of generic features. •Redesign requires decision-making. The properties of a chemical process are directly related to the human decision making which makes it an artefact. Every artefact may have a purpose given to it by its designer or user and, consequently, a performance. While the behaviour is ultimately dictated by the fundamental laws of natural phenomena, the other features of the process are a direct result of human decision making. •Redesign is a human, goal-oriented activity. How the target is described dictates most of the activities carried out with the model. Thus the methodology of process design will crucially depend on the generic model of the chemical process adopted. 5.3.2 Ontological assumptions When a redesign task is expressed in a tractable mathematical form suitable to be processed by a computer, abstractions are required. These abstractions are based on assumptions and simplifications. Thus, the resulting solution has only limited significance. These 5.4 THE FUNCTIONAL ONTOLOGY 87 abstractions are crucial in the process of redesign because we are designing something that does not exist. Deep knowledge and experience helps the human designer to approximate the credibility of the mathematical tools relative to the specific problem at hand as well as to select other appropriate tools required and knowledge needed for reliable decision making. Thus, the implementation of the concepts of the proposed redesign framework is based on the following ontological commitments. •The chemical processes typically operate at steady-state. That means that values of variables do not change with respect to time. •A chemical process is constituted of real and abstract units. The abstract units are the sections of the process that appear as atomic elements in conceptual models. All real equipment can be viewed as descendants of the generic real equipment. •A generic real equipment can be modelled as an object having four attributes: structure, behaviour, function and teleology. These attributes are necessaries and sufficient to describe all the properties of any real equipment. 5.4 The functional ontology Since the framework requires functional concepts, a crucial point is to define the type of functions we are using. These concepts give us the idea about how redesign is viewed in the Chemical Engineering domain. We have identified several concepts about redesign of chemical process. These are mainly concerning to the functions achieved by the equipment of the chemical process (named unit operations in Chemical Engineering) and its related issues. This decision was adopted based on two aspects: •Historically it has been recognised that it is possible to define a chemical process as a collection of unit operations connected with more elementary ones. •The systematic study of the individual unit operations leads to the development of mathematical models and methods to compute their behaviour in simulators. The functional ontology obtained is formed by high-level and low-level concepts in a similar way to the SUMO (Suggested Upper Merged Ontology) ontology structure [Niles 01]. SUMO structures the concepts using meta-concepts, where terminology of general purpose is situated at higher levels, while terminology to specific domains is situated at lower levels. The ontology developed has extended generic concepts of SUMO such as process, 94 IMPLEMENTATION OF THE FRAMEWORK 5.6 In real redesign situations the first task is to simulate the process of interest in the simulator. The next task is to obtain the description of the process, which is the first task performed by the modelling module. After that, the following modules can operate based on such descriptions. 5.6.1 The hierarchical modelling module Its aim is to obtain the hierarchical representation of the process. The obtained representation is crucial for the following modules. Two tasks are carried out in this module: data acquisition and functional identification. In Figure 5.6 the flow diagram of the modelling module is shown in general terms denoting the most important submodules. Assign functional concepts based on the functional hiearchy Assign teleological descriptions Functional Identification Identify functional concepts Aggregate the unit/meta-unit to input or output depending of functions Abstraction Process Generate a new abstraction level Identify inputs and outputs of process Assign streams Eliminate connection loops Connect Units Identify types of equipments Create units and assign data File Parser Stablish connection with case library Identify functions Store Cases Close connection Store cases in corresponding group Data file from simulator Display components in graphical interface Store/retrieve in common data base Figure 5.6: Flow diagram of the modelling module. 5.6.1.1 The data acquisition module The data can be acquired directly from the process simulator. In our case, we have employed the Hysys simulator [Hysys 04]. This simulator is broadly employed in the simulation of chemical processes as much in industry as in universities. Hysys allows 5.6 THE SOFTWARE MODULES 95 extracting information by means of its Application Program Interface (API). In general terms, since all the information generated by the simulator is not required, a filter to identify the useful data was implemented [L´opez-Ar´evalo 02, L´opez-Ar´evalo 03a]. Thus, the data acquisition is focused mainly on the process units and its streams, which are the composing elements of the flowsheet5. The process units are the equipment that carry out the conversion of the input (mass/energy)into the desired output product. The streams are the connections between equipment or between equipment and its external environment. The extracted information concerns the structure and behaviour of the process. An example of extracted information from the simulator is shown in Appendix A, more detail in [L´opez-Ar´evalo 03c, L´opez-Ar´evalo 03b, L´opez-Ar´evalo 04]. From the simulation point of view this information is incomplete, but from redesign point of view it is consistent because it comes from a reliable source. Irrelevant information for redesign is not considered. Finally, a data file is obtained containing all the information extracted from de simulator (see Appendix A). Note that the equipment do not contain information about the process variables. They mainly contain information about the type of equipment and which are its input and output streams. The streams contain the values of such variables. Thus, this data file represents structural and behavioural data. The software module that gets this data is called HEAD (Hysys ExtrAction Data) [L´opez-Ar´evalo 02, L´opez-Ar´evalo 03a]. 5.6.1.2 Functional identification module This module receives as input the data file generated in the previous module to identify the functions of each equipment. Based on such functions the functional sections of the process are identified. As mentioned earlier (Functional identification subsection in Chapter 4), initially the original equipment are represented by the named units, the functional sections are represented by the named meta-units. As output this module returns a hierarchical representation of the process with a tree-like structure. The grouping strategy is based on the functional importance of units and meta-units. The tree represents a tree of metamodels because it contains units, which encapsulate structural, behavioural, functional and teleological models. This task is carry out by the AHA! (Automatic Hierarchical Abstraction tool) prototype [L´opez-Ar´evalo 03a, L´opez-Ar´evalo 03c, L´opez-Ar´evalo 03b, L´opez-Ar´evalo 04]. AHA! has been implemented in Java and JESS [JESS 04]. The main elements of AHA! are: •The knowledge base contains heuristic rules obtained from the Chemical Engineering 5The flow diagram of the process. 96 IMPLEMENTATION OF THE FRAMEWORK 5.6 literature of design of processes and from human designer experiences. Specifically applying the Douglas [Douglas 88] and Turton [Turton 98] methodologies. •The data base contains facts concerning information of the units and meta-units of the process of interest. These are introduced to the data base when the units/metaunits are created. Since the aim is to obtain a hierarchical representation of the process, the original knowledge of the process must be abstracted preserving the most important functions and goals. In such manner, a consistent classification strategy must be employed to highlight such functions and goals. The classification strategy employed is described in more detail in the rest of this subsection. Classification strategy In the data acquisition stage all the types of equipment have been identified. This identification corresponds to real class of equipment in the process. Each equipment has been designed to carry out certain function. Of course within each equipment certain physicochemical phenomena and processes occur to achieve such function, but we are interested only in the function performed by the equipment. Then we have classified the functions as is shown in Figure 5.7 following the concepts of functions described in the Functional unit identification subsection in Chapter 4. Each specific function denotes the type of physical effect occurred into the real equipment. One or more broad function6can be related to any function in the hierarchy as it can take part in several physical phenomena, but only one function is important in the performance of the process (see Figure 5.8, where the functions in bold font denote the designer intention). Since the functional classification shown in Figure 5.7, a process can be interpreted as follows: 1. By equipment. This corresponds to the classes of equipment (Level3 - Working Functions) such as, pumps, heaters, coolers, etc. Specific details of the type of equipment are not considered. This interpretation may be obtained directly from flowsheet in the simulator and corresponds to the first representation of the process. 2. By processes. This corresponds to the subprocess achieved by groups of equipment. It can be considered that “more important” functions are achieved. At the same 6A broad function denotes a MFM/Multimodelling function, see section §4.3.1 in Chapter 4. 5.6 THE SOFTWARE MODULES 97 Continuos Stirred Tank Reactor Plug Flow Reactor Tubular Reactor Tank Liquid Liquid Extractor Flash 3-Phase Separator Trayed Packed Vapour Absorption Column Liquid Absorption Column Gas Adsorption Column Liquid Adsorption Column Cristalliser Leacher Dryer Membrane Heater Heat Exchanger Cooler Compressor Pump Valve Expander Mixer Splitter Reaction Decantation Extraction Distillation Absortion Absortion Stripping Cristallisation Leaching Drying Filtration Heating Cooling Pressure increment Pressure decrement Flow increment Flow decrement Reaction Separation Temperature change Pressure change Flow change Evaporator Condenser Process Unit Rotary Type Piston Type Total Condenser Partial Condenser Total Evaporator Partial Evaporator 1-n plates General Function Specific Function Working Function Type of equipment Figure 5.7: The hierarchy of functions. 98 IMPLEMENTATION OF THE FRAMEWORK 5.6 Reaction Decantation Extraction Distillation Absortion Absortion Stripping Cristallisation Leaching Drying Filtration Heating Cooling Pressure increment Pressure decrement Mixing Splitting Reaction Separation Temperature change Pressure change Flow change Process Unit General Function Specific Function barrier balance sink source barrier transport sink source barrier balance balance sink transport barrier source balance balance balance transport barrier barrier source storage storage storage storage storage storage storage storage storage storage storage Exchanging balance Figure 5.8: MFM and Multimodelling functions in the functional hierarchy. 5.6 THE SOFTWARE MODULES 99 time connected subprocesses can achieve larger subprocesses. This interpretation may be obtained from Level 1 and Level 2, (General and Specific Functions). Both classifications (Figures 5.7 and 5.8) have been implemented as JESS rules. The former is carried out when units are created from the data file. The latter is carried out when the process is functionally abstracted. To illustrate an example of a JESS rule, one of the rules “to eliminate flow change units” is shown in Figure 5.9. ;******************************************* ; ABSTRACTION IN THE FLOW-CHANGE LEVEL ;******************************************* ;;*********************************************************** ;; START ABSTRACTION OF UNITS CORRESPONDING TO CURRENT LEVEL ;;*********************************************************** (defrule get_flow_change_units (level flow) ?units_to_abstract<-(device (name ? name) (functional $?funcion&:(eq (nth$ 1 $?function) "flow")) (name_stream_out $?output_stream) (name_stream_in $?input_stream) (abs ~yes) (reference_object ?ref)) => (assert (units_abs_nivel_actual (reference ?ref) (input_streams $?input_streams) (output_streams $?output_streams) (inlet_hierarchy flow) (copied no) (num_input_streams (length$ $?input_streams)) (num_output_streams (length$ $?output_streams)) (funcion (nth$ 3 $?function)))) (modify ?units_to_abstract (abs yes)) ) Figure 5.9: One of the rules to group flow change units to more important functions. Knowledge representation The input data file is introduced to a parser to recognise the corresponding data to each equipment and the units are automatically generated. After each unit is created, its corresponding facts are introduced to the knowledge base. As an example, the corresponding functional concepts assigned to a pump are shown in Figure 5.10. The goal assigned to the pump concerns knowledge about it and features of its neighbours. Such knowledge is represented by means of keywords. Thus, the goal it is formed by two parts: •The set of pairs keyword-value (Figure 5.11). 100 IMPLEMENTATION OF THE FRAMEWORK 5.6 (defrule assign_functional_concepts_pump ?eq_pump <-( device (pump ?type_equipment) (working_function $?wfunction) => (modify ?eq_pump (general_function "pressure_change") (specific_function "pressure_increment") (working_function "pump") (mfm_function "transport")) Figure 5.10: Assignation of functional concepts to a pump. [TYPE_PHASE] = value [ROLE_INLET_STREAM] = value [NAME_EQUIPMENT_INPUT] = value [NAME_EQUIPMENT_OUTPUT] = value [NAME_INLET_STREAM] = value [WHO_X_CONNECTED_TO_OUTPUT] = value [DELTA_PRESSURE] = value Figure 5.11: The keywords of pressure change units. •The structured values of keywords in human understanding format (Figure 5.12). "Increases the pressure in [DELTA_PRESSURE] kPa of [ROLE_INLET_STREAM] stream (name/phase: [NAME_INLET_STREAM]/[TYPE_ PHASE]) to provide the conditions required [WHO_X_CONNECTED_TO_OUTPUT] ([NAME_EQUIPMENT_OUT-PUT])." Figure 5.12: The goal of pressure increment in human reading format. Note that the keywords correspond to the complete specific function, which involves pump, compressor, expander, or valve. The keywords must be present on all units of this specific function although its value can be null. For that reason some keywords may not appear in the goal description. The representation of the modelled process is given to the user by means of a graphical interface for better understanding (p.ex. see Figure 6.2 in Chapter 6). The graphical interface has been implemented by means of the Swing package of Java. 5.6 THE SOFTWARE MODULES 101 Knowledge abstraction After the first representation of the units has been obtained, these units must be abstracted to reduce the complexity of the overall process. This is carried out by means of an aggregation process. The construction of the models in the previous step started with detailed models of the units. Now these units are aggregated to generate “super” units (called meta-units), which will simplify the process. Aggregation is defined as the action of combining several components into one bigger component without eliminating any of the variables or equations that define the models of the abstracted components. An example of aggregation is shown in Figure 5.13. Mixer Reactor Str-25 Str-31 Str-37 Str-45 Mixer Reactor Str-25 Str-31 Str-37 Str-45 Meta-Reactor a) Units b) Meta-unit Figure 5.13: Aggregation of units. The aggregation process has been implemented by using heuristic rules taken from the literature and the expert designers in the chemical process design. This aggregation heuristic establishes a functional order over the functions of the units. The heuristic considers the main sections of a chemical process [Turton 98]. These sections are represented by the general functions of the hierarchy of functions. The functional order denotes the importance of the functions in the achievement of the overall goal of the process. Changes on that order generate different redesign results. This functional order is shown in Figure 5.14. Reaction Separation Temperature change Pressure change Flow change Functional importance +- Figure 5.14: The functional importance order. Considering only one level of representation, units with high functional importance “overlap” units with lower functional importance. Then the latter are considered auxiliary functions of the former. In other words, the formers are primary functions and the latter are secondary functions. Then, the heuristic rules denote a grouping mechanism where units with high functional importance “absorb” units with lower functional importance. Thus 102 IMPLEMENTATION OF THE FRAMEWORK 5.6 in a next representation (a new level in the hierarchical representations of the process), only the “survivors” units and meta-units are represented. Thus, the grouping mechanism was implemented following the algorithm shown in Figure 5.15. The algorithm is an encapsulation of the functional order (Figure 5.14). The case library is filled at the same time the units and meta-units are generated. Case library As mentioned in Chapter 4, the ground cases are the units created during the first representation of the process, at the abstraction level 0. The abstract cases are the meta-units created during the functional section identification. Mainly the function and goal of the unit/meta-unit represents the description of the case and the overall unit/meta-unit represents itself the solution of the case (Figure 5.16). Since the case library may contain several complete chemical processes, the amount of ground and abstract cases may be large. In this sense, a simple representation of the case library is not enough. In this case, the flattening of the information contained in a unit/meta-unit is not a good option. In addition, quick access to relevant cases is necessary. Then the use of an Object Oriented Data Base Manager (OODBM) is an appropriate option to enhance the storing and retrieving process. Thus, the interaction with the case library is carried out using the OODBM named Ozone [Ozone 03]. Indexing The organisation of cases into the library of cases is performed according to the type of function of the unit/meta-unit. The aim is to structure the case library in a similar way as the hierarchy of functions (see Figure 5.7). In this way, five general groups can be distinguished: reaction, separation, temperature change, pressure change, and flow change. Within each group, units and meta-units are grouped based on its specific function. There are not distinctions between units and meta-units with the same specific function. This organisation scheme allows to store cases from several processes considering only the function of the unit/meta-unit. Both storing and retrieving processes are carried out quickly. The algorithm to start the organisation of the case library is shown in Figure 5.17. Although complete chemical process may be stored, it is not our intention to retrieve such processes entirely. We are interested only in retrieving specific parts (units or meta-units) as suggestion to the designer. 5.6 THE SOFTWARE MODULES 103 aggregation_process input: = the first representation of the process ; only units output: = the process represented at several abstraction levels begin global_set_of_functional_sets: = all the units arranged into groups while ( there is more than one element in global_set_of_functional_sets ) functional_group := set of units with minor functional importance in global_set_of_functional_sets while (exists units in functional_group) component_to_aggregate := choose one unit from functional_group ; depending of type of component_to_aggregate, the ; component_to_aggregate may be grouped with the input ; or output units/meta-units aggregation_direction := input or output set_elements_to_meta-unit := elements at aggregation_direction while ( number of elements at set_elements_to_meta-unit > 0 ) element_to_meta-unit := next element of set_elements_to_meta-unit aggregate_units (component_to_aggregate, element_to_meta-unit, aggregation_direction) end-while remove component_to_aggregate from functional_group end-while generate a new abstraction level representing the remanent units/meta-units end-while end ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; aggregate_units ; component_to_aggregate is the unit to be absorbed, ; element_to_meta-unit is the unit that absorbs ; aggregation_direction is to whom the component_to_aggregate ; will be aggregated input := component_to_aggregate, element_to_meta-unit, aggregation_direction output := a new meta-unit created begin meta-unit := copy information from element_to_meta-unit aggregate structural, behavioural, functional and teleological information of component_to_aggregate to meta-unit depending on aggregation_direction assign meta-unit to component_to_aggregate as parent unit assign component_to_aggregate to meta-unit to as child unit functional_group = the functional_group of element_to_meta-unit remove element_to_meta-unit from functional_group add meta-unit to functional_group end Figure 5.15: The algorithm to group functions. 110 IMPLEMENTATION OF THE FRAMEWORK 5.6 obtain_alternatives input := the original case from the process, the case libary output := an ordered list of possible alternatives begin original_function := specific function of original case source_cases := extract from the case library cases with original_function original_goal := goal of original case source_goals := goals of source_cases list_teleological_similarities := compute_similarity(original_goal, source_goals) for each element in source_cases assign corresponding value from list_teleological_similarities end-for list_alternatives := compute_similarity(target_case, source_cases) end ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; compute_similarity input := the original case, the set of source cases output := an ordered list of similarity values begin similarity_criteria := specify values and preferences on attributes of the original case similarity_weights := specify weights on attributes of the original case gather max and min values on original case and source cases normalise values and weights to obtain target case based on similarity_criteria and similarity_weights determine max distance based on similarity_criteria and similarity_weights for each element in source cases score the element for each similarity criterion by: for each similarity criterion normalise values and weights end-for compute distances by: for each score distance := compute distance of element respect to target case end-for percent_similarity = ( 1 - (distance/max distance) ) * 100 end-for returned_list := rank elements by sorting on percent_similarity end Figure 5.22: Algorithm of the case-base reasoning module. 5.6 THE SOFTWARE MODULES 111 The returned list will contain cases ranked according to the percent of similarity. With the returned set of cases, adaptation costs are computed to suggest such cases to the designer. The implemented similarity measures are not described in depth in the algorithm. Of these, the most complex is described in the next subsection. 5.6.3.1 Similarity measures The similarity measures compute the similarity degree between two cases. They constitute the kernel of the similarity engine. Typically most CBR applications use these measures to compute distance between cases. In general, these measures use nearest neighbour search to compute distances. The similarity between two cases Ciand Cjcan be defined as complementary to their distance, as shows Equation 5.1. similarity(Ci, Cj) = 1 −distance(Ci, Cj) (5.1) where, distance is the global distance (with a normalised value -[0,1]- ) calculated for all the attributes of Ciand Cj. For example Equation 4.1 in the Case retrieval subsection of Chapter 4 (subsection §4.3.3.6) shows the computation of the distance by means of an Euclidean algorithm. In this way, two cases which are equal have the maximum similarity degree, i.e. 1, while two absolutely different cases have a minimum similarity degree, i.e. about 0. The similarity engine implement local and global similarity measures, which have been described in the section Generation of alternatives (§4.3.3 in Chapter 4). From these, the most simple is the numeric measure, the symbolic is into the named Inclusion Measure (using the bag/set data model), but the most complex is the hierarchical measure. In Chapter 4 (also in section §4.3.3), a short version of the hierarchical measure was presented, next, to get a better understanding, it is described in more detail. Hierarchical similarity measure This measure exploits the “semantic knowledge” in the hierarchy of functions to identify meta-units sharing common characteristics (see Figure 5.7). Note that this measure 112 IMPLEMENTATION OF THE FRAMEWORK 5.6 is applied over the tree functional structure of meta-units, applied over units the result is null. To illustrate this, consider the two meta-units shown in Figure 5.23. Meta-separator Meta-separator Meta-tmp_change Meta-separator Valve Separator Cooler Heater Mixer Meta-separator Meta-separator Meta-tmp_change Valve Cooler Separator Pump Figure 5.23: Functional structure of meta-units. Both are meta-separators, each one containing a meta-separator and meta-temp change meta-units. But with differences in the number and functions of its corresponding units (the abstraction level 0). Since goals of meta-units do not depend on the structural connections between its units, different structural configurations can achieve similar goals. But if structural configurations are similar then goals may be more similar too. Then, considering this, as both are meta-separators they may have close similar goals if their structural configurations are similar. Thus, it is necessary to consider the number of units and meta-units contained in a greater meta-unit. The similarity between two metaunits is reflected in how far apart its “internal” general functions are in the hierarchy of functions. Thus, we have implemented the Generalised Cosine-Similarity Measure (GCSM) [Ganesan 03] 5.2. sim(A, B) = −→ A·−→ B q−→ A·−→ Aq−→ B·−→ B (5.2) This measure uses the vector-space data model. Here, a collection (in our case, a collection of hierarchised functional concepts) is represented by a vector, with components along exactly those dimensions corresponding to the elements in the collection. This is a generalisation of the Cosine-Similarity Measure (CSM) taking into account hierarchies. CSM defines the similarity between two vectors to be the cosine of the angle between them, which is identical to the normalised inner product of the two vectors. The GCSM generalise the CSM taking into account hierarchies. Thus, the unit vector corresponding 5.7 CHAPTER CONCLUSIONS 113 to a leaf lis represented by −→ l. Now according to CSM, all leaf unit vectors are perpendicular to each other, which means that the dot product of any two of them is zero. The dot product of a unit vector with itself is equal to 1. For a formal discussion see [Ganesan 03]. 5.7 Chapter conclusions The redesign framework was applied to the Chemical Engineering domain due to the close collaboration between us and chemical engineers. Within this domain the processes fulfill the assumptions considered about the type of processes where the framework can be applied. Additionally, the domain allows a well structure of functions. Thus, the framework has been implemented according to the definition given in the previous chapter. The redesign knowledge was acquired from the literature and the expertise of the chemical engineers involved in this research. Suggestions about the interaction of human designer were considered in the implementation to get a useful tool. As result, a computer redesign aid tool has been obtained which interact with the designer and a simulator. The tool does not redesign processes either automatically or autonomously. The aim is to support human designers to understand a process and facilitate the redesign activities. Thus the entirely framework (shown section §4.3 of Chapter 4) is formed by the simulator, the tool implemented and the human designer. The implementation was carried out using the object-oriented approach. Thus, the Java language was employed. To get better implementation results and to save time, JESS [JESS 04], Ozone [Ozone 03], and The Selection Engine [Wetzel 00] have been integrated in the tool. These Java libraries were useful in the codification because its interoperability is transparent. To facilitate the reading of the chapter, only minimal source code was presented. Thus, the algorithms used were given to illustrate. In addition, the flow diagrams of each software module were presented to explain the logic of the implementation. Although the implementation already includes domain concepts, application examples are not given here. The performance and evaluation of this implementation is explained in the next chapter. 114 IMPLEMENTATION OF THE FRAMEWORK 5.7 CHAPTER SIX Results and Evaluation In this chapter the results are analysed and the evaluation of redesign framework is provided. The theoretical and practical bases described in the two previous chapters were applied to the Chemical Process domain. The ammonia production process is taken as case study. 6.1 Introduction In order to analyse the performance of the redesign framework, practical results are discussed and evaluated in this chapter. The framework was tested on over 50 chemical processes [L´opez-Ar´evalo 05a, L´opez-Ar´evalo 05b]. Technical changes on equipment were taken into account and some other issues such as economical costs, changes in pipes, environment impact, etc. were not considered. Although the framework was tested on several process, in this chapter, only the ammonia production process is used as case study. The chapter is organised as follows. Section §6.2 presents the ammonia production process to give a general idea of the case study. In section §6.3, the modelling process is illustrated to show the way in which functional sections are identified. Once the process representation was generated, the identification of candidates is done by selecting the unit/meta-unit to guide the generation of alternatives, as shown sections §6.4 and §6.5. Other results are presented in section §6.6. A discussion of results is given in section §6.7 and finally the chapter conclusions are given in section §6.8. 115 116 RESULTS AND EVALUATION 6.3 6.2 The ammonia production process We have selected as case study this process because is one of the most relevant chemical processes in the industry. Ammonia is one of the most important chemicals commodities because of its role in the production of fertiliser and hence of food. It is produced in over 80 countries worldwide with a volume of 130 million tonnes annually [GIA 04]. Approximately 85% of all ammonia produced is used in fertiliser production. Another usages include textile fibre processing, water purification, food production, etc. Ammonia is produced from water, nitrogen and energy. Energy usually comes from hydrocarbons, which also provide hydrogen. Nowadays natural gas is likely to be the main feedstock. As such, ammonia production can be viewed as a petrochemical process. The production of ammonia is a relatively clean process, where main emissions are carbon dioxide and oxides of nitrogen, both of which can be recovered or reduced to very low levels in modern plants. In this sense, no pollution problems may be considered. As ammonia is used in several ways, its production varies according to the needs of the industrial consumers. Thus, sometimes may it be necessary to scale up the production, to increase the purity, etc. In another ocasions is necessary to decrease energy costs since the major cost of ammonia production depends on the source of energy used. This represents situations where the plant must be adapted to the new requirements, i.e. the plant must be redesigned. Process model The primary feedstocks for production of ammonia are nitrogen and hydrogen gas. They react with an iron catalyst at high pressure and temperature (500◦C) to produce the ammonia. The process model used as case study was extracted from the examples library of Hysys simulator. The detailed model is shown in Figure 6.1 and it is described in more detail in [Hysys 04, L´opez-Ar´evalo 05a]. In this process, a hydrogen/nitrogen stream is fed to three catalytic reactors in serie (PFR-100, PFR-101, and PFR-102). The ammonia produced is fed to the separation section (V-100, V-101) to obtain a 99% pure product stream. Two heat exchangers (E102 and E-104) are used for energy recovery and two coolers (E-101 and E-103) are used to obtain appropriate separation conditions. The equilibrium mixture obtained in the reactor will contain more ammonia when the temperature is low and the pressure is high. Low temperatures affect the equilibrium favourably, but the reaction is too slow. Very high pressures, though favouring product creation, increase the costs of plant construction, and present a greater risk. 6.3 HIERARCHICAL MODELLING OF THE AMMONIA PROCESS 117 Figure 6.1: Flow diagram of ammonia production. 6.3 Hierarchical modelling of the ammonia process As was described in Chatpter 5, HEAD extracts the data from the Hysys simulator (Appendix A shows these data), then AHA! reads the data file provided by HEAD and asks user for the “roles” of chemical substances. These roles are used to generate the teleological descriptions. AHA! represents the first level of the process (abstraction level 0) as shown Figure 6.2. This GUI allows the user to interact in two ways, through menus and panels. The diagram panel (upper-right panel) allows the user to manipulate the process layout; the user can organise the components (equipment/sections) of the process according to its needs. The navigation panel (upper-left panel) is used to navigate into the levels of the process; abstraction levels and its corresponding components. The information panel (bottom panel) displays information about operations carried out in the prototypes. In general terms, the equipment of the process are interconnected (Figure 6.3). From a functional point of view, the general functions of the equipment are depicted in Figure 6.4. The generation of the abstract models is based on these functions. Table 6.1 summarises the type of equipment and its corresponding functions. The generation of meta-units starts by grouping the equipment with minor functional importance with equipment with higher functional importance. Thus, first the flow change 118 RESULTS AND EVALUATION 6.3 Figure 6.2: First representation of the ammonia production process. Mixer HtExch Splitter HtExch Separator Cooler Cooler Reactor Mixer Mixer Valve Valve Compressor Splitter Valve Separator Reactor Reactor Figure 6.3: Equipment of the ammonia production process. 6.3 HIERARCHICAL MODELLING OF THE AMMONIA PROCESS 119 Separation Temp_change Reaction Press_change Temp_change Temp_change Temp_change Press_change Separation Press_change Press_change Flow_change Flow_change Flow_change Reaction Reaction Flow_change Flow_change Figure 6.4: Functions of the ammonia production process. General Function Specific Function Working Function Label Flow change Flow increment Mixer MIX-100 MIX-101 MIX-102 Flow decrement Splitter TEE-100 TEE-101 Pressure change Pressure increment Compressor K-100 Pressure decrement Valve VLV-100 VLV-101 VLV-10 Temperature change Temperature increment Cooler E-101 E-103 Temperature exchange Heat Exchanger E-102 E-104 Separation Distillation Flash Separator V-100 V-101 Reaction Reaction Tubular Reactor PFR-100 PFR-101 PFR-102 Table 6.1: Equipments and functions of the ammonia production process. 126 RESULTS AND EVALUATION 6.4 Figure 6.9: Units composing the meta-reactor-3. variable. It may have low volume (lovol) state,which originates the low capacity of metareactor-3. Therefore, the unit associated to this function is identified as cause unit and the analysis in this direction finishes. Considering the stream-7, the function to analyse is a balance (TEE-100), which does not affects the variable. Then, the next function is analysed, which is a balance of temperature (E-102), which again does not affect directly the variable. The next function is storage (V-101), which affects the variable. This is another primary function affecting the concentration variable, it may have low volume (lovol) state. Then its associated unit is a cause unit and the analysis finishes. Now, forward analysis is carried out following the output stream of the functional group. The low capacity (locap) state of meta-reactor-3 originates a low flow (loflow) state and a low volume (lovol) state, and consequently affects the following source functions producing a low capacity (locap) state in such function. Thus, considering the stream-2, the function to analyse is a balance (MIX-101), which does not affect the concentration variable. The next function is source (PFR-102), which affects the variable, it may have low capacity (locap) state originated for the low capacity (locap) state of the meta-reactor-3. Then, the unit associated with this function is a consequence unit. Since is the closer primary function affected in the forward stream 6.5 GENERATION OF ALTERNATIVES 127 direction, the analysis finishes. Therefore, the identified cause and consequence units for meta-reactor-3 are shown in Table 6.3, which also represents the cause and consequence units for all the meta-units. Using this information the human designer can select any of the candidates to obtain similar alternatives in the case-based reasoning module, as is described in next section. Candidate Cause units Consequence units reactor-1 (PFR-100) separator-2 (V-101) reactor-2 (PFR-101) reactor-2 (PFR-101) reactor-1 (PFR-100) reactor-3 (PFR-102) reactor-3 (PFR-102) reactor-2 (PFR-101) separator-1 (V-101) meta-reactor-1 reactor-1 (PFR-100) reactor-3 (PFR-102) separator-2 (V-101) meta-reactor-2 reactor-2 (PFR-101) separator-1 (V-101) meta-reactor-3 reactor-1 (PFR-100) reactor-3 (PFR-102) separator-2 (V-101) meta-reactor-4 reactor-2 (PFR-101) separator-1 (V-101) meta-reactor-5 separator-2 (V-101) reactor-2 (PFR-101) meta-reactor-6 separator-2 (V-101) reactor-3 (PFR-102) meta-reactor-7 separator-2 (V-101) separator-1 (V-101) Table 6.3: Cause and consequence units. 6.5 Generation of alternatives With the results of the diagnosis module, the CBR module is used to obtain alternatives units/meta-units that may be adapted into the ammonia process. Again, the process representation shown in Figure 6.6 is used to denote the composition of meta-units; and the process representation shown in Figure 6.8 to denote the presence of units/meta-units in each abstraction level. Following the example of the meta-reactor-3 case and assuming that the designer has selected it to obtain alternatives to this meta-unit. Thus, meta-reactor-3 constitutes the original case with information shown in Figure 6.10. From the description of metareactor-3, the values used in the similarity computations are shown in Table 6.41). The human designer may assign weights (low, medium, and high) to these values to denote the importance of some attribute in the description and the designer preference in ob1Values are expressed in the International System of Units. 128 RESULTS AND EVALUATION 6.5 Process identificator: ammonia General function: reaction Specific function: reaction Working function: tubular_reactor Abstraction level: 2 Number inlet: 2 Number outlet: 1 Inlet function: reaction, flow_change Outlet function: reaction Goal: Increases production of ammonia (family: Nitrogen_Compound) in this second reactor in serie with the similar temperature and pressure than the previous reactor. With outlet temperature: 393.19º C and outlet pressure: 14970.05 kPa is achieved a conversion of: 99 % mass of Methane, Hydrogen and Nitrogen (family: Alkane, Inorganic_Compound, Inorganic_Compound) respectively in gas phase. Figure 6.10: Relevant data of the original case (meta-reactor-3). General values of Keyword values of goal meta-reactor-3 of meta-reactor-3 Process identificator: ammonia Type connection: serie General function: reaction Inlet temperature: 393.03 Specific function: reaction Inlet pressure: 14985.05 Working function: tubular reactor Inlet phase: gas Abstraction level: 2Outlet temperature: 393.19 Number inlet: 2Outlet pressure: 14970.05 Number outlet: 1Outlet phase: gas Inlet function: reaction, Conversion: 99 flow change Main product: ammonia Outlet function: flow change Reactant: methane, hydrogen, nitrogen Main product family: nitrogen compound Reactant family: alkane, inorganic compound, inorganic compound Table 6.4: Used values in the similarity computations. 6.5 GENERATION OF ALTERNATIVES 129 taining similar ones. With this preference the target case is obtained. By default medium weights are assigned to all attributes. Then, to simplify the example, no modifications on weights are performed and thus the target case is the original case. Although the total number of inlets and outlets is considered as numeric values, only the most important function at the inlet and the outlet are considered. In the above description, the inlet function has the value reaction and flow change. Only reaction is considered as it is more important to retrieve a source case with reaction as inlet function than flow change (see hierarchy of functions in Figure 5.7 in Chapter 5). The functional structure is shown in Figure 6.11. Thus, with the values of Table 6.4, units and meta-units with the same meta reactor valve reactor mixer meta reactor Figure 6.11: Functional structure of the target case (meta-reactor-3). specific function are extracted from the case library. The ground and abstract cases from the ammonia process are not considered in this search. The search returns 93 ground and abstract cases. The similarity computations are carried out over those extracted cases. Teleological similarity The teleological similarity is computed using the keyword values (see Table 6.4). That is, only similarities in the goals of the extracted source cases against the goal of the target case. Numeric and symbolic measures are employed (see the case retrieval section in Chapter 4). Thus, corresponding teleological similarities are assigned to each source case, it constitutes an additional value in the source case to employ in the global similarity computation. 130 RESULTS AND EVALUATION 6.5 Global similarity With the teleological value in each source case, the global similarity can be computed. Here functional and hierarchical similarities are calculated, the former by means of symbolic measure and the latter by means of the hierarchical measure. Assume that a threshold of 142was established to show the most similar source cases. Thus, the computed global similarities are summarised in Table 6.5. Rank Similarity Function Inlet Function Outlet Function 1 56 % reaction reaction separation tmp change 2 43 % reaction reaction pres change 3 37 % tubular reactor heater packed 4 31 % plug flow reactor valve separation/ cooler 5 30 % meta-reactor separation pres change 6 29 % tubular reactor reaction splitter 7 29 % reaction tmp change tmp change 8 27 % reaction tubular reactor tmp change 9 25 % reaction tubular reactor mixer 10 23 % tubular reactor tmp change separation 11 20 % plug flow reactor flow change cooler/ pres change 12 20 % reaction tmp change reaction 13 16 % reaction reaction tmp change 14 15 % reaction separation reaction Table 6.5: Result of the global similarity computation for meta-reactor-3. In Table 6.5 the percentage of similarity, the specific function, the inlet and outlet functions of the source case are shown. Given these results, the designer can take any of retrieved cases to adapt it and evaluate its performance in the simulator. Normally the designer chooses the most similar ones, which are presented next. 1. meta-reactor with 56% of similarity The values are given in Table 6.6. The functional structure is shown in Figure 6.12. 2This number may vary according to the human designer needs. In this case, for illustration and exemplification purposes, the number was stablished in 14 to show the 14 most similar cases. 6.5 GENERATION OF ALTERNATIVES 131 General values of Keyword values of goal meta-reactor of meta-reactor Process identificator: methanol Type connection: isolate General function: reaction Inlet temperature: 321.15 Specific function: reaction Inlet pressure: 4985.05 Working function: tubular reactor Inlet phase: gas Abstraction level: 2Outlet temperature: 373.47 Number inlet: 2Outlet pressure: 4870.52 Number outlet: 1Outlet phase: gas Inlet function: reaction, Conversion: 97 tmp change Main product: methanol Outlet function: separation Reactant: carbon dioxide, nitrogen Main product family: alcohol Reactant family: inorganic compound, inorganic compound Table 6.6: Values of meta-reactor with 56% of similarity. meta reactor separator reactor mixer meta reactor Figure 6.12: Functional structure of the meta-reactor with 56% of similarity. 132 RESULTS AND EVALUATION 6.5 2. meta-reactor with 43% of similarity The values are shown in Table 6.7. The functional structure is shown in Figure 6.13. General values of Keyword values of goal meta-reactor of meta-reactor Process identificator: ethylene Type connection: serie oxide Inlet temperature: 499.95 General function: reaction Inlet pressure: 2650.85 Specific function: reaction Inlet phase: gas Working function: tubular reactor Outlet temperature: 516.19 Abstraction level: 2Outlet pressure: 2615.05 Number inlet: 1Outlet phase: gas Number outlet: 1Conversion: 98 Inlet function: reaction Main product: ethylene oxide Outlet function: press change Reactant: ethylene, oxygen Main product family: alkene Reactant family: alkene, inorganic compound Table 6.7: Values of meta-reactor with 43% of similarity. meta reactor meta tmp-change reactor mixer meta reactor cooler valve Figure 6.13: Functional structure of the meta-reactor with 43% of similarity. 3. tubular-reactor with 37% of similarity The values are depicted in Table 6.8. The functional structure of this source case is null as it is a unit. The more similar cases represent tubular reactor working functions. The abstraction level varies from 0 to 2, cases with higher level have minor similarity. The number of inlets and outlets are very similar varying between 1 and 2. With respect to the inlet and outlet 6.5 GENERATION OF ALTERNATIVES 133 General values of Keyword values of goal tubular-reactor of tubular-reactor Process identificator: cumene Type connection: isolate General function: reaction Inlet temperature: 350.17 Specific function: reaction Inlet pressure: 3090.54 Working function: tubular reactor Inlet phase: gas Abstraction level: 0Outlet temperature: 350.01 Number inlet: 1Outlet pressure: 3075.26 Number outlet: 1Outlet phase: gas Inlet function: heater Conversion: 96 Outlet function: packed Main product: cumene Reactant: benzene, propene Main product family: alkene Reactant family: alkene, alkene Table 6.8: Values of meta-reactor with 37% of similarity. functions, the variation is pronounced in the second and third cases because both have 1 inlet and 1 outlet function. The first case has 2 inlet and 1 outlet functions as the target case. With respect to the goals of each case, there are several variations. The type of connection is the same, only in the second case with value serie. The variations on temperatures is clear in the first and second case because the outlet temperature is greater than the inlet. Temperature values are more similar in the first and third cases. Variations on pressures are more evident because the target case has values close to 15000 whereas the most similar value is of the first case with value close to 5000. The phase of the three cases is equal to target case, gas phase. The conversion values in the three cases are very similar to the target (99%), 97%, 98%, and 96% respectively. Obviously since the units are from different process, the chemical substances in the main product and reactant are different. In temperature and pressure, the range of values is also taken into account in addition to quantitative values. In the Chemical Engineering domain is not recommendable to compare these differences qualitatively. For example, the difference between 14985 and 14970 is small; also the difference between 2650 and 2615 is small. In both cases the quantitative difference is small, but the values have different order of magnitude, which is the most important characteristic in these differences. Finally, it is decision of the human designer to perform the appropriate adjustments in the above cases to adapt them into the ammonia process. To do this, he/she must take into 134 RESULTS AND EVALUATION 6.6 account the cause and consequence units identified in the candidates section (section §6.4). The alternatives are descriptions of already existing equipment; these are not description of prototypes that can be modified. Then, the three most similar retrieved cases were adapted into the ammonia process. Although each case required specific adjustments, the human experts considered as acceptable the alternatives proposed by the framework. Depending on the adapted case, its retention must be carried out by modelling again the entire process. The performance is similar to described in the modelling section (section §6.3). 6.6 Other results The framework was tested with other examples. Here, detailed steps are omitted illustrating only the most important ones. 6.6.1 Concentration variable Following the ammonia process, now that we are interesting in incrementing the purity of the main product (increment the concentration variable -the mass flow-). That means some waste must be removed from the produced substance (main product). The MFM function related to increment the amount of mass (purity of products) is storage linked to separators. Therefore, the diagnosis module returns from the search process in the hierarchical representation (see Figure 6.8) the results shown in Table 6.9 and Table 6.10. Abstraction level Identified components 5 meta-separator-6 4 meta-separator-5, meta-separator-4 3 meta-separator-3, meta-separator-2 2 separator-1, meta-separator-1 1 separator-2 Table 6.9: Identified candidates related to increase purity. From Table 6.10 the expert can see that outlet process-1, outlet process-4, and outlet process-5 are considered as consequence units. The search algorithm considers the inlets and outlets as units will null functions but with source and sink MFM functions 6.6 OTHER RESULTS 135 Candidate Cause units Consequence units separator-1 (V-101) separator-2 (V-100) reactor-1 (PFR-100) reactor-2 (PFR-101) reactor-3 (PFR-102) outlet process-5 separator-2 (V-100) reactor-3 (PFR-102) separator-1 (V-101) outlet process-1 outlet process-4 meta-separator-1 reactor-3 (PFR-102) separator-1 (V-101) outlet process-1 outlet process-4 meta-separator-2 reactor-3 (PFR-102) separator-1 (V-101) outlet process-1 outlet process-4 meta-separator-3 separator-2 (V-100) reactor-1 (PFR-100) reactor-2 (PFR-101) reactor-3 (PFR-102) outlet process-5 meta-separator-4 reactor-3 (PFR-102) separator-1 (V-101) outlet process-1 outlet process-4 meta-separator-5 separator-2 (V-100) reactor-1 (PFR-100) reactor-2 (PFR-101) reactor-3 (PFR-102) outlet process-5 meta-separator-6 reactor-3 (PFR-102) reactor-1 (PFR-100) reactor-2 (PFR-101) reactor-3 (PFR-102) outlet process-1 outlet process-4 outlet process-5 Table 6.10: Cause and consequence units of candidates related to increase purity.