Practical Grey-box Process Identification: Theory and Applications (Advances in Industrial Control)

Advances in Industrial Control

Other titles published in this Series: Digital Controller Implementation and Fragility Robert S.H. Istepanian and James F. Whidborne (Eds.) Optimisation of Industrial Processes at Supervisory Level Doris Sáez, Aldo Cipriano and Andrzej W. Ordys Robust Control of Diesel Ship Propulsion Nikolaos Xiros Hydraulic Servo-systems Mohieddine Jelali and Andreas Kroll Strategies for Feedback Linearisation Freddy Garces, Victor M. Becerra, Chandrasekhar Kambhampati and Kevin Warwick Robust Autonomous Guidance Alberto Isidori, Lorenzo Marconi and Andrea Serrani Dynamic Modelling of Gas Turbines Gennady G. Kulikov and Haydn A. Thompson (Eds.) Control of Fuel Cell Power Systems Jay T. Pukrushpan, Anna G. Stefanopoulou and Huei Peng Fuzzy Logic, Identification and Predictive Control Jairo Espinosa, Joos Vandewalle and Vincent Wertz Optimal Real-time Control of Sewer Networks Magdalene Marinaki and Markos Papageorgiou Process Modelling for Control Benoît Codrons Computational Intelligence in Time Series Forecasting Ajoy K. Palit and Dobrivoje Popovic Modelling and Control of mini-Flying Machines Pedro Castillo, Rogelio Lozano and Alejandro Dzul

Rudder and Fin Ship Roll Stabilization Tristan Perez Hard Disk Drive Servo Systems (2nd Edition) Ben M. Chen, Tong H. Lee, Kemao Peng and Venkatakrishnan Venkataramanan Measurement, Control, and Communication Using IEEE 1588 John Eidson Piezoelectric Transducers for Vibration Control and Damping S.O. Reza Moheimani and Andrew J. Fleming Windup in Control Peter Hippe Manufacturing Systems Control Design Stjepan Bogdan, Frank L. Lewis, Zdenko Kovaˇci´c and José Mireles Jr. Nonlinear H2 /H∞ Constrained Feedback Control Murad Abu-Khalaf, Jie Huang and Frank L. Lewis Modern Supervisory and Optimal Control Sandor A. Markon, Hajime Kita, Hiroshi Kise and Thomas Bartz-Beielstein Publication due July 2006 Wind Turbine Control Systems Fernando D. Bianchi, Hernán De Battista and Ricardo J. Mantz Publication due August 2006 Soft Sensors for Monitoring and Control of Industrial Processes Luigi Fortuna, Salvatore Graziani, Alessandro Rizzo and Maria Gabriella Xibilia Publication due August 2006 Practical PID Control Antonio Visioli Publication due November 2006 Magnetic Control of Tokamak Plasmas Marco Ariola and Alfredo Pironti Publication due May 2007

Torsten Bohlin

Practical Grey-box Process Identification Theory and Applications

With 186 Figures

123

Torsten Bohlin Automatic Control, Signals, Sensors and Systems Royal Institute of Technology (KTH) SE-100 44 Stockholm Sweden

British Library Cataloguing in Publication Data Bohlin, Torsten, 1931Practical grey-box process identification : theory and applications. - (Advances in industrial control) 1.Process control - Mathematical models 2.Process control Mathematical models - Case studies I.Title 670.4’27 ISBN-13: 9781846284021 ISBN-10: 1846284023 Library of Congress Control Number: 2006925303 Advances in Industrial Control series ISSN 1430-9491 ISBN-10: 1-84628-402-3 e-ISBN 1-84628-403-1 ISBN-13: 978-1-84628-402-1

Printed on acid-free paper

© Springer-Verlag London Limited 2006 MATLAB® and Simulink® are registered trademarks of The MathWorks, Inc., 3 Apple Hill Drive, Natick, MA 01760-2098, U.S.A. http://www.mathworks.com Modelica® is a registered trademark of the “Modelica Association” http://www.modelica.org/ DymolaTM is a trademark of Dynasim AB, Research Park Ideon, Lund 223 70, Sweden. www.Dynasim.se Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms of licences issued by the Copyright Licensing Agency. Enquiries concerning reproduction outside those terms should be sent to the publishers. The use of registered names, trademarks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant laws and regulations and therefore free for general use. The publisher makes no representation, express or implied, with regard to the accuracy of the information contained in this book and cannot accept any legal responsibility or liability for any errors or omissions that may be made. Printed in Germany 987654321 Springer Science+Business Media springer.com

Advances in Industrial Control Series Editors Professor Michael J. Grimble, Professor of Industrial Systems and Director Professor Michael A. Johnson, Professor (Emeritus) of Control Systems and Deputy Director Industrial Control Centre Department of Electronic and Electrical Engineering University of Strathclyde Graham Hills Building 50 George Street Glasgow G1 1QE United Kingdom

Series Advisory Board Professor E.F. Camacho Escuela Superior de Ingenieros Universidad de Sevilla Camino de los Descobrimientos s/n 41092 Sevilla Spain Professor S. Engell Lehrstuhl für Anlagensteuerungstechnik Fachbereich Chemietechnik Universität Dortmund 44221 Dortmund Germany Professor G. Goodwin Department of Electrical and Computer Engineering The University of Newcastle Callaghan NSW 2308 Australia Professor T.J. Harris Department of Chemical Engineering Queen’s University Kingston, Ontario K7L 3N6 Canada Professor T.H. Lee Department of Electrical Engineering National University of Singapore 4 Engineering Drive 3 Singapore 117576

Professor Emeritus O.P. Malik Department of Electrical and Computer Engineering University of Calgary 2500, University Drive, NW Calgary Alberta T2N 1N4 Canada Professor K.-F. Man Electronic Engineering Department City University of Hong Kong Tat Chee Avenue Kowloon Hong Kong Professor G. Olsson Department of Industrial Electrical Engineering and Automation Lund Institute of Technology Box 118 S-221 00 Lund Sweden Professor A. Ray Pennsylvania State University Department of Mechanical Engineering 0329 Reber Building University Park PA 16802 USA Professor D.E. Seborg Chemical Engineering 3335 Engineering II University of California Santa Barbara Santa Barbara CA 93106 USA Doctor K.K. Tan Department of Electrical Engineering National University of Singapore 4 Engineering Drive 3 Singapore 117576 Professor Ikuo Yamamoto Kyushu University Graduate School Marine Technology Research and Development Program MARITEC, Headquarters, JAMSTEC 2-15 Natsushima Yokosuka Kanagawa 237-0061 Japan

To the KTH class of F53

Series Editors’ Foreword

The series Advances in Industrial Control aims to report and encourage technology transfer in control engineering. The rapid development of control technology has an impact on all areas of the control discipline. New theory, new controllers, actuators, sensors, new industrial processes, computer methods, new applications, new philosophies}, new challenges. Much of this development work resides in industrial reports, feasibility study papers and the reports of advanced collaborative projects. The series offers an opportunity for researchers to present an extended exposition of such new work in all aspects of industrial control for wider and rapid dissemination. Experienced practitioners in the field of industrial control often say that about 70 – 80% of project time is spent on understanding and modelling a process, developing a simulation and then testing, calibrating and validating the simulation. Control design and investigations will then absorb the other 20 – 30% of the project time; thus, it is perhaps a little surprising that there is so little published on the formal procedures and tools for performing these developmental modelling tasks compared with the provision of simulation software tools. There is a very clear difference between these two types of activities: simulation tools usually comprise libraries of numerical routines and a logical framework for their interconnection often based on graphical representations like block diagrams of the actual steps needed to arrive at a consistent model but replicating observed physical process behaviour is a far more demanding objective. Such is the agenda underlying the inspirational work of Torsten Bohlin reported in his new Advances in Industrial Control monograph, Practical Grey-box Identification. The starting point for this work lies in the task of providing models for a range of industrial production processes including: Baker’s yeast production, steel rinsing (the rinsing of moving steel strip in a rolling-mill process), continuous pulp digestion, cement milling, an industrial recovery boiler process (pulp production process unit) and cardboard manufacturing. The practical experience of producing these models supplied the raw data for understanding and abstracting the steps needed in a formal grey-box identification procedure; thus, it was a project that has been active for over 15 years and over this period, the grey-box identification procedure was formulated, tested, re-formulated and so-on until a generic procedure of wide applicability finally emerged.

x

Series Editors’ Foreword

In parallel with this extraction of the fundamental grey-box identification procedure has been the development of the Process Model Calibrator and Validator software, the so-called MoCaVA software. This contains the tools that implement the general steps of grey-box identification. Consequently it is based on an holistic approach to process modelling that uses a graphical block-diagram representation but incorporates routines like loss function minimisation for model fitting and other statistical tools to allow testing of model hypotheses. The software has been tested and validated through its use and development with an extensive and broadly based group of individual processes, some of which are listed above. This monograph captures three aspects of Torsten Bohlin’s work in this area. Firstly, there is an introduction to the theory and fundamentals of grey-box identification (Part I) that carefully defines white-box, black-box and grey-box identification. From this emerge the requirements of a grey-box procedure and the need for software to implement the steps. Secondly, there is the MoCaVa software itself. This is available for free download from a Springer website whose location is given in the book. Part II of the monograph is a tutorial introduction and user’s guide to the use of the MoCaVa software. For added realism, the tutorial is based on a drum boiler model. Finally the experience of the tutorial introduction is put to good use with the two fully documented case studies given as Part III of the monograph. Process engineers will be able to work at their own pace through the model development for a rinsing process for steel strip in a rolling mill and the prediction of quality in a cardboard manufacturing process. The value of the case studies is two-fold since they provide a clear insight into the procedures of greybox identification and give in-depth practical experience of using the MoCaVa software for industrial processes; both of these are clearly transferable skills. The Advances in Industrial Control monograph series has often included volumes on process modelling and system identification but it is believed that this is only the second ever volume in the series on the generic steps in an holistic greybox identification procedure. The volume will be welcomed by industrial process control engineers for its insights into the practical aspects of process model identification. Academics and researchers will undoubtedly be inspired by the more generic theoretical and procedural aspects that the volume contributes to the science and practice of system identification. M.J. Grimble and M.A. Johnson Industrial Control Centre Glasgow, Scotland, U.K.

Preface

Those who have tried the conventional approaches to making mathematical models of industrial production processes have probably also experienced the limitations of the available methods. They have either to build the models from first principles, or else to apply one of the ‘black−box’ methods based on statistical estimation theory. Both approaches work well under the circumstances for which they were designed, and they have the advantage that there are well developed tools for facilitating the work. Generally, the modelling tools (based on first principles) have their applications to electrical, mechanical, and hydrodynamical systems, where much is known about the principles governing such systems. In contrast, the statistical methods have their applications in cases where little is known in advance, or when detailed knowledge is irrelevant for the purpose of the modelling, typically for design of feedback control. In modelling for the process industry, however, prior knowledge is typically partial, the effects of unknown input (’disturbances’) are not negligible, and it is desirable to have reproducibility of the model, for instance for the monitoring of unmeasured variables, for feed−forward control, or for long−range prediction of variables with much delayed responses to control action. Conceivably, ‘grey−box’ identification, which is a ‘hybrid’ of the two approaches, would help the situation by exploiting both of the two available sources of information, namely i) such invariant prior knowledge that may be available, and ii) response data from experiments. Thus, grey−box methods would have their applications, whenever there is some invariant prior knowledge of the process and it would be a waste of information not to use it. After the first session on grey−box identification at the 4th IFAC Symposium on Adaptive Systems in Control and Signal Processing in 1992, and the first special issue in Int. J. Adaptive Control and Signal Processing in 1994, the approach has now been reasonably well accepted as a paradigm for how to address the practical problems in modelling physical processes. There are now quite a number of publications, most about special applications. (A Google search for “Grey box model” in 2005 gave 691 hits.) However, the problems of designing tools for grey−box identification are many. Mainly, prior knowledge of industrial processes is usually diversified and primarily ill adapted to the purpose of the model making. It is in the nature of things that prior knowledge is more or less precise, reliable, and relevant (it may even be false). This raises a number of fundamental questions, in addition to the practical problems: How can I make use of what I do know? How much of my prior knowledge is useful and even correct, when used in the particular environment? What do I do about the unknown disturbances I cannot get rid of? Are my experiment data sufficient and relevant? How do I know when the model is good enough?

xii

Preface

It was the desire to find some answers to these questions that initiated a long−range project at the Automatic Control department of KTH. The present book is based on the results of that project. It stands on three legs: i) A theoretical investigation of the fundamentals of grey−box identification. It revealed that sufficiently many theoretical principles were available in the literature for answering the questions that needed to be answered. The compilation was published in a book (Bohlin, 1991a), which ended with a number of procedures for doing grey− box identification properly. ii) A software tool MoCaVa (Process Model Calibrator & Validator) based on one of the procedures (Bohlin and Isaksson, 2003). iii) A number of case studies of grey−box identification of industrial processes. They were carried out in order to see whether the theoretical procedure would also be a practical one, and to test the software being developed in parallel. Most case studies have been done by PhD students at the department under the supervision of the author. The extent of the work was roughly one thesis per case. This book will focus on the software and the case studies. Thus it will serve as a manual to MoCaVa, as well as illustrating how to apply MoCaVa efficiently. Success in grey−box identification, as in other design, will no doubt depend of the skill of the craftsman using the tool, and I believe that skill is best gained by exercise, and case studies to be a good introduction. In addition, there is a ‘theory’ chapter with the purpose of describing the basic deliberations, derivations, and decisions behind MoCaVa and the way it is constructed. The purpose is to provide additional information to anyone who wants to understand more of its properties than revealed in the user’s manual. This may help the user to appraise the strengths and weaknesses of the program, either in order to be able to do the same with the models that come out of it, or even to develop MoCaVa further. (The source code can be downloaded from Springer.) The focus is therefore on the applicability of the theories for the purpose of MoCaVa, rather than on the theories themselves. Still, the chapter involves some not elementary mathematics, but mathematics stripped from the painstaking exactness of strict mathematics. This too is motivated by a kind of ‘grey−box thinking’, this time to try and bridge the notorious gap between theory and practice. It would be futile trying to adhere to the code of strict mathematics when dealing with problems that cannot be solved in that way, and, in addition, meant to be understood by readers who are not used to strict mathematics. And, conversely, it would be impractical to try and solve all problems of grey−box identification by relying on intuition and reasoning alone, however clever. Therefore, the mathematics is interpreted in intuitive terms, and necessary approximations motivated in the same way, whenever the mathematical problems become unsurmountable, or an exact solution would take prohibitively long for a computer to process. The following is one of my favorite quotations: “The man thinks. The theory helps him to think, and to maintain his thinking consistent in complex situations” (Peterka). The method presented in this book for building grey−box models of physical objects has three kinds of support: A systematic procedure to follow, a software package for doing it, and case studies for learning how to use it. Part I motivates and describes the procedure and the MoCaVa software. Part II is a tutorial on the use of MoCaVa based on simple examples. Part III contains two extensive case studies of full−scale industrial processes.

Preface

xiii

How to Use this Book Successful grey−box identification of industrial processes requires knowledge of two kinds, i) how the process works, and ii) how the software works. Since the knowledge is normally not resident within the same person, two must contribute. Call them “process engineer” and “model designer”. The latter should preferably have taken a course in ‘Process identification’. Part I is for the “model designer”, who needs to understand how the MoCaVa software operates, in order to appreciate its limitations − what it can and cannot do. Part II is for both. It is a tutorial on running MoCaVa, written for anyone who actually wants to build a grey−box model. It is also useful as an introduction to the case studies, since it is based on two pervading simple examples. Part III is also for both. It develops the case studies in some detail, highlighting the contributions of the three ‘actors’ in the session, viz. the engineer, the model designer/ program operator, and the MoCaVa program. The technical details in Part III is probably of interest only to those working in the relevant businesses (steel or paper & pulp), but are still important as illustrations of the issues that must be considered in practical grey−box process identification. The style of parts II and III deviates somewhat from what is customary in text books, namely to use sentences in passive form, free of an explicit subject. The idea of the customary practice is that science and engineering statements should be valid irrespective of the subject. Unfortunately, the custom is devastating for the understanding, when describing processes where there are indeed several subjects involved. “Who does what” becomes crucial. Therefore, part II is written more like a user’s manual. In describing grey−box identification practice there is, logically, no less that five ‘actors’ involved: : The customer/engineer (providing the prior information about the physical process and appraising the result) : The model designer/user of the program tools (often the same person as the customer, but not if he/she lacks sufficient knowledge of the physical process to be modelled). : The computer and program (analyzing the evidence of the data). : The author of this book (trying to reason with a reader) : The reader of the book (trying to understand what the author tries to say). In order to reduce the risk of confusion when describing a grey−box identification session − a process that involves at least the first three actors − the following convention will be used in the book: The contributions of the different actors are marked with symbols at the beginning of the paragraph, viz.  for the operator (doing key pressing and mouse clicking),  for MoCaVa (computing and displaying the results), and  for the model builder (watching the screen, deliberating, and occasionally calculating on paper). It will no doubt help the reader who wants to follow the examples on a computer, that the symbol  states explicitly what to do in each moment, and the symbol  points to the expected response. There are also paragraphs without an initiating symbol − they have the ordinary rôle of the author talking to a reader. Also as a convention, Courier fonts are used for code, as well as for variables that appear in the code, and for names of submodels, files, and paths. HelveticaNarrow is used for user communication windows and for labels that appear in screen images.

xiv

Preface

The book uses a number of special terms and concepts of relevance to process identification. Some, but not all should be well−known, or self−explanatory to model designers, but probably not all. The “Glossary of Terms” contains short definitions, without mathematics, and some with clarifying examples. The list serves the same purpose as the ‘hypertext’ function in HTML documentation, although less conveniently. The contents in Part II is also available in HTML format. This form has the well− known advantage that explanations of some key concepts become available at a mouse click, and only if needed. In Part II explanations appear either under the headers Help or Hints, or else as references to sections in the appendix, which unavoidably means either wading through text mass (that can possibly be skipped), or looking up the appropriate sections in the appendix. In order to reduce the length of Part II the number of printed screen images is also smaller than those in the HTML document. MoCaVa is downloadable from www.springer.com/1−84628−402−3 together with all material needed for running the case studies. (The package also contains the HTML−manual as well as on−line help facilities.) This offers a possibility to get more direct experience of the model−design session. It would therefore be possible to use Parts II and III as study material for a course in grey−box process identification.

Acknowledgements The author is indebted to the following individuals who participated in the Grey−box development project: Stefan Graebe, who wrote the first C−version of the IdKit tool box, and later participated in the Continuous Casting case study. James Sørlie, who investigated possible interfaces to other programs. Bohao Liao, who investigated search methods. Ning He, who investigated real−time evaluation of Likelihood. Anders Hasselkvist, who wrote Predat. Tomas Wenngren, who wrote the first GUI. Germund Mathiasson and Jiri Uosukainen who wrote the first version of Validate. Olle Ehrengren, who wrote the first version of Simulate. Ping Fan, who did the Baker’s Yeast case study. Björn Sohlberg, who did the first Steel Rinsing case study. Jonas Funkquist, who did the Pulp Digester case study. Oliver Havelange, who did the Cement Milling case study. Jens Pettersson, who did the second Cardboard case study. Ola Markusson, who did the EEG−signals case study. Bengt Nilsson, who contributed process knowledge to the Cardboard case study. Jan Erik Gustavsson, who contributed process knowledge to the Recovery Boiler case study. Alf Isaksson, who participated in the Pulp Refiner and Drive Train cases, and headed the MoCaVa project between 1998 and 2001. Linus Loquist, who designed the MoCaVa home page.

Contents

Part I Theory of Grey−box Process Identification

1 Prospects and Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 White, Black, and Grey Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.1 White−box Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.2 Black−box Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.3 Grey−box Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.3 Basic Questions ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.3.1 Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.3.2 How to Specify a Model Set . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.4 ... and a Way to Get Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.5 Tools for Grey−box Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.5.1 Available Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.5.2 Tools that Need to Be Developed . . . . . . . . . . . . . . . . . . . . . . . 21 2 The MoCaVa Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 The Model Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Time Variables and Sampling . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Process, Environment, and Data Interfaces . . . . . . . . . . . . . . . 2.1.3 Multi−component Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.4 Expanding a Model Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 The Modelling Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Argument Relations and Attributes . . . . . . . . . . . . . . . . . . . . . 2.2.2 Graphic Representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Prior Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Hypotheses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Credibility Ranking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Model Classes with Inherent Conservation Law . . . . . . . . . . . 2.3.4 Modelling ‘Actuators’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.5 Modelling ‘Input Noise’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.6 Standard I/O Interface Models . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Fitting and Falsification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23 23 24 25 27 29 31 34 37 41 42 43 43 44 46 49 51

xvi

Contents

2.5

2.6 2.7

2.4.1 The Loss Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Nesting and Fair Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 Evaluating Loss and its Derivatives . . . . . . . . . . . . . . . . . . . . . 2.4.4 Predictor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.5 Equivalent Discrete−time Model . . . . . . . . . . . . . . . . . . . . . . . Performance Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Controlling the Updating of Sensitivity Matrices . . . . . . . . . . 2.5.2 Exploiting the Sparsity of Sensitivity Matrices . . . . . . . . . . . . 2.5.3 Using Performance Optimization . . . . . . . . . . . . . . . . . . . . . . . Search Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Applicability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.1 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.2 A Method for Grey−box Model Design . . . . . . . . . . . . . . . . . . 2.7.3 What is Expected from the User? . . . . . . . . . . . . . . . . . . . . . . . 2.7.4 Limitations of MoCaVa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.5 Diagnostic Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.6 What Can Go Wrong? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52 54 55 56 56 57 58 59 60 62 65 65 67 68 69 69 71

Part II Tutorial on MoCaVa

3 Preparations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Downloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.3 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.4 Starting MoCaVa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.5 The HTML User’s Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 The ‘Raw’ Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Making a Data File for MoCaVa . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77 77 77 77 77 78 78 78 78

4 Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.1 Creating a New Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.2 The User’s Guide and the Pilot Window . . . . . . . . . . . . . . . . . . . . . . . 85 4.3 Specifying the Data Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.3.1 The Time Range Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.4 Creating a Model Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.4.1 Handling the Component Library . . . . . . . . . . . . . . . . . . . . . . 89 4.4.2 Entering Component Statements . . . . . . . . . . . . . . . . . . . . . . . 90 4.4.3 Classifying Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 4.4.4 Specifying I/O Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 4.4.5 Specifying Argument Attributes . . . . . . . . . . . . . . . . . . . . . . . 98 4.4.6 Specifying Implicit Attributes . . . . . . . . . . . . . . . . . . . . . . . . 100 4.4.7 Assigning Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.5 Specifying Model Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.6 Simulating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 4.6.1 Setting the Origin of the Free Parameter Space . . . . . . . . . . . 103 4.6.2 Selecting Variables to be Plotted . . . . . . . . . . . . . . . . . . . . . . 104 4.6.3 Appraising Model Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Contents

4.7 4.8

xvii

Handling Data Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fitting a Tentative Model Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.1 Search Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.2 Appraising the Search Result . . . . . . . . . . . . . . . . . . . . . . . . . Testing a Tentative Model Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9.1 Appraising a Tentative Model . . . . . . . . . . . . . . . . . . . . . . . . 4.9.2 Nesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9.3 Interpreting the Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . Refining a Tentative Model Structure . . . . . . . . . . . . . . . . . . . . . . . . Multiple Alternative Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Augmenting a Disturbance Model . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking the Final Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminals and ‘Stubs’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Copying Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Effects of Incorrect Disturbance Structure . . . . . . . . . . . . . . . . . . . . . Exporting/Importing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . Suspending and Exiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.18.1 The Score Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resuming a Suspended Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking Integration Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

106 107 108 111 113 116 118 119 121 122 124 132 134 135 138 140 141 142 143 143

5 Some Modelling Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Modelling Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 The Model Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 User’s Functions and Library . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Rescaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Importing External Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Using DymolaZ as Modelling Tool for MoCaVa . . . . . . . . . 5.3.2 Detecting Over−parametrization . . . . . . . . . . . . . . . . . . . . . . 5.3.3 Assigning Variable Input to Imported Models . . . . . . . . . . . . 5.3.4 Selective Connection of Arguments to DymolaZ Models . .

147 147 148 153 154 159 160 166 170 173

4.9

4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20

Part III Case Studies

6 Case 1: Rinsing of the Steel Strip in a Rolling Mill . . . . . . . . . . . . . . . . . 6.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Step 1: A Phenomenological Description . . . . . . . . . . . . . . . . . . . . . . 6.2.1 The Process Proper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 The Measurement Gauges . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.3 The Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Step 2: Variables and Causality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 The variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Cause and effect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.3 Data Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.4 Relations to Measured Variables . . . . . . . . . . . . . . . . . . . . . . 6.4 Step 3: Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 Basic Mass Balances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.2 Strip Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

185 185 185 185 188 189 189 189 190 191 192 194 194 201

xviii Contents

6.5 6.6

Step 4: Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Refining the Model Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.1 The Squeezer Rolls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.2 The Entry Rolls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7 Continuing Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.8 Refining the Model Class Again . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.8.1 Ventilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.9 More Hypothetical Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.9.1 Effective Mixing Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.9.2 Avoiding the pitfall of ‘Data Description’ . . . . . . . . . . . . . . . 6.10 Modelling Disturbances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.10.1 Pickling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.10.2 State Noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.11 Determining the Simplest Environment Model . . . . . . . . . . . . . . . . . 6.11.1 Variable Input Acid Concentration . . . . . . . . . . . . . . . . . . . . 6.11.2 Unexplained Variation in Residual Acid Concentration . . . . 6.11.3 Checking for Possible Over−fitting . . . . . . . . . . . . . . . . . . . . 6.11.4 Appraising Roller Conditions . . . . . . . . . . . . . . . . . . . . . . . . 6.12 Conclusions from the Calibration Session . . . . . . . . . . . . . . . . . . . . .

203 206 206 211 213 215 215 217 217 219 222 222 223 225 225 225 229 233 233

7 Case 2: Quality Prediction in a Cardboard Making Process . . . . . . . . . 7.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Step 1: A Phenomenological Description . . . . . . . . . . . . . . . . . . . . . . 7.3 Data Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Step 2: Variables and Causality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1 Relations to Measured Variables . . . . . . . . . . . . . . . . . . . . . . 7.5 Step 3: Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.1 The Bending Stiffness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.2 The Paper Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.3 The Pulp Feed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.4 Control Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.5 The Pulp Mixing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.6 Pulp Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.7 The Pulp Constituents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6 Step 4: Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7 Expanding the Tentative Model Class . . . . . . . . . . . . . . . . . . . . . . . . 7.7.1 The Pulp Refining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7.2 The Mixing−tank Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7.3 The Machine Chests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7.4 Filtering the “Kappa” Input . . . . . . . . . . . . . . . . . . . . . . . . . . 7.8 Checking for Over−fitting: The SBE Rule . . . . . . . . . . . . . . . . . . . . . 7.9 Ending a Calibration Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.9.1 ‘Black−box’ vs ‘White−box’ Extensions . . . . . . . . . . . . . . . . 7.9.2 Determination vs Randomness . . . . . . . . . . . . . . . . . . . . . . . . 7.10 Modelling Disturbances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.11 Calibrating Models with Stochastic Input . . . . . . . . . . . . . . . . . . . . . 7.11.1 Determination vs Randomness Revisited . . . . . . . . . . . . . . . . 7.11.2 A Local Minimum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.12 Conclusions from the Calibration Session . . . . . . . . . . . . . . . . . . . . .

235 235 235 237 244 247 248 248 253 260 262 265 267 269 271 279 279 284 287 289 290 293 293 294 295 296 299 304 306

Contents

xix

Appendices

A Mathematics and Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.1 The Model Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 The Loss Derivatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.3 The ODE Solver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.3.1 The Reference Trajectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.3.2 The State Deviation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.3.3 The Equivalent Discrete−time Sensitivity Matrices . . . . . . . . A.4 The Predictor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.4.1 The Equivalent Discrete−time Model . . . . . . . . . . . . . . . . . . A.5 Mixed Algebraic and Differential Equations . . . . . . . . . . . . . . . . . . . A.6 Performance Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.6.1 The SensitivityUpdateControl Function . . . . . . . . . . . . . . . . A.6.2 Memoization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.7 The Search Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.8 Library Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.8.1 Output Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.8.2 Input Interpolators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.8.3 Input Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.8.3 Disturbance Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.9 The Advanced Specification Window . . . . . . . . . . . . . . . . . . . . . . . . B.2.1 Optimization for Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.2.2 User’s Checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.2.3 Internal Integration Interval . . . . . . . . . . . . . . . . . . . . . . . . . . B.2.4 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

313 313 316 317 317 318 318 321 322 322 326 327 330 330 331 331 331 334 335 337 337 338 338 339

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

1

Prospects and Problems

1.1 Introduction The task of making a mathematical model of a physical object, such as an industrial process, involves a diversity of problems. Some of these have traditionally been the subject of theoretical research and software development. Such a problem is “System identification”, typically defined as follows: “Given a parametric class of models, find the member that fits given experiment data with the minimum loss according to a given criterion” (Ljung, 1987). Now, the three “given” conditions concern anyone who intends to apply the software, whether that is in the form of theory, method, or computer program. Sometimes “given” means that prerequisites are built into the software, sometimes that they are expected as input from the user of the software. When one is faced with a given object instead, and possibly also with a given purpose for the model, it is certainly not obvious how to get the answers to the questions posed by identification software. It is therefore important that developers of such software do what they can to facilitate the answering. It is not necessarily a desirable ambition to make the software more automatic by demanding less from the user. He or she is still responsible for the quality of the result, and any input that a user is able to provide, but is not asked for, may be a waste of information and reduce the quality of the model. A better goal is therefore to make the software demand its input in a form that the user can supply more easily. Secondly, user input (both prior knowledge and experiment data) is often uncertain, irrelevant, contradictory, or even false. A second goal for the software designer is therefore to provide tools for appraising the user’s input. Admittedly, any software must have something ‘given’, but it makes a difference whether the software wants assumptions, taken for facts, or just hypotheses, that will be subject to tests. This motivates the decision to base MoCaVa on the ‘grey−box’ approach. The general and somewhat vague idea of grey box identification is that when one is making a mathematical model of a physical object, there are two sources of information, namely response data and prior knowledge. And grey−box identification methods are such methods that can use both. In practice, “prior knowledge” means different things. And generally, prior knowledge is not easy to reconcile with the form of the models assumed by a particular identification method. In fact, each method starts with assuming a model class, and each model class requires its particular form of prior knowledge. What one can generally do in order to take prior knowledge into account is to start with a versatile class of models, for which there are general tools available for analysis and identification, and try

4

Practical Grey−box Process Identification

and adapt its freedom, its ‘design parameters’, i.e., the specifications one has to enter into the identification program, to the prior knowledge. This means that the ‘grey−box identification methods’ tend to be as many and as diversified as the conventional identification methods, also starting with given classes of models. This makes it hard to delimit grey−box identification from other identification and also to make a survey of ‘grey box identification methods’. Neither is that the purpose of this chapter. Instead it is to survey the fundamentals the MoCaVa software is based on. A user of the program will conceivably benefit from an understanding of the purposes of the operations performed by various routines in the program. Generally, MoCaVa is constructed by specializing and codifying the general concepts used in (Bohlin, 1991a) and following one of the procedures derived in that book. In addition, the chapter will briefly discuss the prospects and problems of developing grey−box identification software further.

1.2 Black, White, and Grey Boxes Commercially available tools for making mathematical models of dynamic processes are of two kinds, with different demands on the user. On one hand there are Modelling tools, generally associated with simulation software (e.g., DymolaZ, http://www.dynasim.se/www/Publications.pdf ), which require the user to provide complete specification of the equations governing the process, either expressed as statements written in some modelling language, such as ModelicaX (Tiller, 2001), or by connecting components from a library. This alternative may be supported by combining the modelling tools with tools for parameter optimization (e.g., HQP, http://sourceforge.net/projects/hqp). Call this “white−box” identification. On the other hand there are “black−box” system identification tools (e.g., MATLABX System Identification Tool Box), which require the user to accept one of the generic model structures (e.g., linear) and then to determine which tools to use in the particular case, and in what order, as well as the values of a number of design parameters (order numbers, weighting factors, etc.). Finally, the user must interpret the resulting model, which is expressed in a form that is not primarily adapted to the physical object. Unless the model is to be used directly for design of feedback control, there is some further translation to do. Generally, the user has two sources of information on which to base the model making: prior knowledge and experiment data. “White−box” identification uses mainly one source and “black−box” identification the other. The strength of “white−box” identification is that it will allow the user to exploit invariant prior knowledge. Its weakness is its inability to cope with the unknown and with random effects in the object and its environment. The latter is the strength of “black−box” identification based on statistical methods, but also means that the reproducibility of its results may be in doubt. In essence, “black−box” identification produces ‘data descriptions’, and repeating the experiment may well produce a much different model. This may or may not be a problem, depending on what the model is to be used for. The idea of “grey−box” identification is to use both sources, and thus to combine the strengths of the two approaches in order to reduce the effects of their weaknesses. When following Ljung’s definition of “System identification”, and regardless of the ‘colour’ of the ‘box’, the designer of a model of a physical object must do two things, i) specify a class of models, and ii) fit its free elements to data. Call this “Model-

1 Prospects and Problems

5

ling” and “Fitting”. A method with a darker shade of ‘grey’ uses less prior knowledge to delimit the model class. Even if most available identification methods tend to be more or less ‘grey’, the following notations allow a formal distinction between the generic ‘white’, ‘black’, and ‘grey box’ approaches to model design. 1.2.1 White−box Identification Since both the model class definition and the fitting procedure are implemented as algorithms they can be described formally as functions: Model: F(u t, θ) → z(t|θ) Fitting: min θ E[y N, z N(θ)]

(1.1) (1.2)

The model designer specifies the model class F, which may contain a given number of unknown parameters θ. Given a control sequence u t (where the subscript denotes the input history from some initial time up to present time t), and the parameter vector θ, a simulation program allows the computing of the model’s response z(t|θ) at any time. Any unknown parameters θ are then estimated by applying an optimization program minimizing the deviation between measured response data y N and those components of the model’s output z N that correspond to the measured values. The deviation is measured by a given loss function E. The latter is usually a sum of squared instantaneous deviations, but various filtering schemes may be used to suppress particular types of data contamination. The following are some well−known obstacles to designing “white boxes” in practice: : Unknown relations between some variables: Engineers often do not have the complete mathematical knowledge of the object to be able to write a simulation model. : Too many relations for convenience: When they do have the knowledge, the result is often too complex a model to be possible to simulate with the ease required for parameter fitting. Many physical phenomena are describable only by partial differential equations. Simulation would then require supercomputers, and identification an order of magnitude more. (Car and airplane designers could possibly afford the luxury.) : Unknown complexity: It falls solely on the designer to determine how much of the known relations to include in the model. : Sensitivity to low−frequency disturbances: Comparing output of deterministic models with data in the presence of low−frequency disturbances generally gives poor parameter estimates. : Primitive validation: If one would try and use only literature values for parameters, or make separate experiments to determine some of them, in order to avoid the cumbersome calibration of a complex model and the usually expensive experimentation on a large process, this makes it the more difficult to validate the model. Remark 1.1. The sensitivity to disturbances can sometimes be reduced by clever design of the loss function. This requires some prior information on the object’s environment. Example 1.1 Consider a cylindrical tank with cross−section area A filled with liquid of density à up to a level z, under pressure p, and having a free outlet at the bottom with area a. The

6

Practical Grey−box Process Identification

tank is replenished with the volume flow f. According to Bernoulli’s law the variations in the level will be governed by the following differential equation: dz dt = − a zg + p à + f A

(1.3)

With u = (f, p) as varying control variables, the equation cannot be solved analytically, but given values of θ = (A, a, Ã, g), an ODE solver will be able to produce a sequence of values {z(kh|θ)|k = 1, , N} of z sampled with interval h. Hence F is defined as the ODE solver operating on an equation of some form like der(z) = −a*sqrt(z*g + p/rho) + f/A

with given constant parameters a,A,g,rho and variable control input p,f. With a recorded sequence of measurements y N = {y(kh)|k = 1,.. ., N} of the tank level z during an experiment with known, step−wise changing input sequences u N , it will be possible to set up and evaluate the loss function N

[y(kh) − z(kh|θ)] 2

E(u N, θ) =

(1.4)

k=1

for any given value of θ. Applying an optimization program, it will then be possible to minimize the loss function with respect to any combination of the parameters, and in this way estimate the values of any unknowns among (A, a, Ã), but not the value of gravity g. 1.2.2 Black−box Identification Defining this case is somewhat more complicated, since the task usually involves determining one or more integer ‘order’ numbers, the values of which determine the number of parameters to be fitted (Ljung, 1987; Söderström and Stoica, 1989): Model: F n(u t, ω t, θ n) → z(t|θ n) z(t|m, θ n) Predictor: P n(u t, y t−m, θ n) → ^ ^ Fitting: Q n = min θ E[y N, z N(m, θ n)] Test: Q n−1 − Q n < χ 2

(1.5) (1.6) (1.7) (1.8)

The designer cannot change F n, which is particular to the method, except by specifying an order index n. The latter normally determines the number of unknown parameters θ n. However, the model class accepts a second, random input signal ω t (usually ‘white noise’) in order to model the effects of random disturbances. For given order numbers the parameters θ n are estimated by minimizing the deviation between response data and m steps predicted output (usually one step) according to a given loss function E. The difference between the model and the predictor is that the latter uses previous, m steps delayed response data y t−m in addition to the control sequence u t for computing the predicted responses. The predictor P n is uniquely determined by F n. However, exact and applicable predictors are known only for special classes F n, and this limits the versatility of black box identification programs. Unknown orders n are usually determined by increasing the order stepwise, and stopping when the loss reduction drops below a threshold χ 2. A popular alternative is to use a loss function that

1 Prospects and Problems

7

weights the increasing complexity associated with increasing n, which allows minimization with respect to both integer parameters n and real parameters θ n (Akaike, 1974). The model classes are most often linear, but nonlinear black−box model classes are also used (Billings, 1980). The following are practical difficulties: : Restricted and unfamiliar form: Many engineers do not feel comfortable with models produced by black−box identification programs based on statistical methods. Mainly, the model structure and parameters do not have a physical interpretation, and this makes it difficult to compare the estimates with values from other sources. : Over−parametrization: The number of parameters increases rapidly with the number of variables, and even more so when the model class is nonlinear. This leads easily to ‘over−fitting’, with all sorts of numerical problems and poor accuracy. : Poor reproducibility: What is produced is a ‘data description’. If this is also to be an ‘object description’ the model class must contain a good model of the object. If it does not; if much of the variation in the data is caused by phenomena that are not modelled well enough by F n as effects of known input u t, the fitting procedure tends to use the remaining free arguments ω t and θ n to reduce the deviations. In other words, what cannot be modelled as response to control, will be modelled as disturbance. In this way even a structurally wrong model may still predict well at a short range. If the data sequence is long, the estimated parameter accuracy may even be high. This means that one may well get a good model, with good short− range predicting ability and a high theoretical accuracy, but when the identification is repeated with a different data set, an equally ‘good’ but different model is obtained. That will not necessarily mean that the object has changed between the experiments; it may be a consequence of fitting a model with the wrong structure. Generally, it will be difficult to get reproducibility with black−box models, unless the dynamics of the whole object are invariant, including the properties of disturbances, and the model structure is right. The basic cause of the poor reproducibility of black boxes, is that it is not possible to enter the invariant and object−specific relations that are the basis of white−box models. To gain the advantages of convenience and quick result, the model designer is in fact willing to discard any result from previous research on the object of the modelling. Remark 1.2. Adaptive control will conceivably be able to alleviate the effects of poor reproducibility, and benefit from the good predictive ability of the model, but this can be exploited only for feedback control of such variables that have online sensors. Monitoring of unmeasured variables, as well as control with long delays will still be hazardous. Remark 1.3. Tulleken (1993) has suggested a way to force some prior knowledge into black−box structures, thus making the models less ‘black’.

Example 1.2 With the same tank object as in Example 1.1, one could choose to ignore the findings of Bernoulli and describe the process as a “black box”. A linear model is the most popular first choice, but if one would suspect that the process is nonlinear, and also take into account some rudimentary prior knowledge (that a hole at the bottom tends to reduce the level), the following heuristic form would also be conceivable: dz dt = p 1 z + p 2 p + p 3 f − [p 4 z + p 5 p + p 6 f] α

(1.9)

8

Practical Grey−box Process Identification

Incidentally, this form contains the ‘true’ process, Equation 1.3, with p 1 = p 2 = p 6 = 0, p 3 = 1 A, p 4 = a 2 g, p 5 = a 2 Ã, and α = ½. But normally, that is not the case. A more likely, and ‘blacker’ form, would be dz dt = p 1 + p 2 z + p 3 p + p 4 f + p 5 z 2 + p 6 p 2 + p 7 f 2

(1.10)

This will define a deterministic black box of second order F n(u t, 0, θ n) → z(t|θ n), where n = 2, u = (f, p) and θ 2 = (p 1, , p 7). It can be processed as in Example 1.1. If the parameters are many enough, if measurements are accurate, and if the experiment is not subject to external or internal disturbance, the resulting model may even perform almost as well as the white box. If, however, the varying pressure p is not recorded, it might still be possible to use the following form

dz dt = p 1 + p 2 z + p 4 f + p 5 z 2 + p 7 f 2 + v dv dt = p 8 ω

(1.11) (1.12)

where ω is ‘white noise’, and v is ‘Brownian motion’ to model the unknown term p 3 p + p 6 p 2. Hence, θ 2 = (p 1, p 2, p 4, p 5, p 7, p 8). When models have unknown input it becomes necessary to find the one−step (or m−step) predictor associated with it, in order to be able to minimize the sum of squares of prediction errors. Exact predictors are known only for some classes of models. And even if the model belongs to a class which does allow a predictor to be derived, derivation is usually no simple task. However, black−box identification programs have already done this for fairly general classes of models that do allow exact derivation. One such class is the NARMAX (for Nonlinear Auto Regressive Moving Average with eXternal input) discrete−time model class (Billings, 1980) nz

na

nz

y(τ) +

nb

b νk P ν[u(τ − k)]

a νk P ν[y(τ − k)]= ν=1 k=1

ν=1 k=1

nc

+ c 0 w(τ) +

c k w(τ − k)

(1.13)

k=0

where τ is discrete time, and P k are known functions of u, for instance powers or Legendre polynomials, and w are independent Gaussian random variables with zero means and unit variances. The model has four order numbers, n = (n a, n b, n c, n z), where the first three are the orders of the dynamics of the system, and the fourth the degree of nonlinearity. Hence, the more common linear ARMAX model has n z = 1. The parameter array θ n is the collection of all a νk, b νk, and c k in Equation 1.13. Notice that Equation 1.13 contains only measured output y in addition to the input u, which is an essential restriction, but makes it easy to derive a predictor (which is why the class is defined in this way). Since the values of w(τ) can be computed recursively from Equation 1.13, and since E{w(τ|y τ−1)} = 0, the predictor follows directly as

1 Prospects and Problems ^

y(τ|τ − 1) nz

na

E{y(τ|y τ−1)}

nz

nb

a P ν[y(τ − k)] +

=−

b νk P ν[u(τ − k)]

ν k

ν=1 k=1 nc

+0+

9

ν=1 k=1

c k w(τ − k)

(1.14)

k=1

The prediction error is y(τ) − ^ y(τ|τ − 1) = c 0 w(τ), and the loss function is N

z N(1, θ n)] = c 20 E[y N, ^

w(k) 2

(1.15)

k=1

The special case of n c = 0 (NARX) is particularly convenient. Since the predictor in Equation 1.14 will then be a linear function in all unknown parameters, and the loss function therefore quadratic, this makes it technically easy to fit a large number of parameters. Now back to the original model, Equations 1.11 and 1.12. If, for simplicity, one assumes that the sampling is dense enough, then v(t + h) = v(t) + p 8 h w(t)

(1.16)

is a good approximation of t+h

v(t + h) = v(t) + p 8

ω(t) dt

(1.17)

t

and Euler integration yields z(t + h) = h[α(t) + β(t) + v(t)]

(1.18)

where α(t) = p 5 z(t) 2, β(t) = p 1 + p 2 z(t) + p 4 f (t) + p 7 f (t) 2 and is the backwards−difference operator. Take backwards differences of Equation 1.18 again, and insert Equation 1.16. Then 2

z(t + h) = h[ α(t) + β(t) + v(t)] = h[ α(t) + β(t) + h p 8 w(t)]

(1.19)

which yields z(t) = 2 z(t − h) − z(t − 2h) + h[ α(t − h) + β(t − h) + h p 8 w(t − h)] = (2 + p 2 h) z(t − h)+ (− 1 − p 2 h) z(t − 2h) + p 5 h z(t − h) 2 − p 5 h z(t − 2h)2 + p 4 h f (t − h) − p 4 h f (t − 2h) + p 7 h f (t − h) 2 − p 7 h f (t − 2h) 2 + p 8 h 3 2 w(t − h)

(1.20)

10

Practical Grey−box Process Identification

Assuming that the measurements are accurate enough to allow y(τ) to replace z(th) and with u(τ) = f (th), makes Equation 1.21 imbedded in 1.13, with P ν(u) ≡ u ν, n a = n b = n z = 2, n c = 0, a 11 = 2 + p 2 h, a 12 = − 1 − p 2 h, a 21 = p 5 h, a 22 = − p 5 h, b 11 = p 4 h, b 12 = − p 4 h, b 21 = p 7 h, b 22 = − p 7 h, c 0 = p 8 h 3 2. After a and b have been determined by minimizing Equation 1.15, the remaining parameter c 0 can be computed from the minimum loss. However, reconstructing the original parameters p from the estimated a, b, and c creates an over−determined system of equations; there are five unknown and nine equations. This can be solved too, for instance using a pseudo inverse, but still causes a complication, since the relations are case dependent and not preprogrammed into the identification package. If one would want to avoid even having to determine the order numbers, and setting up Equations 1.11 and 1.12, and hence also to reconstruct the parameters, it is possible to specify sufficiently large order numbers, and let the necessarily large order numbers be determined by the identification program. The SFI rule (for Stepwise Forward Inclusion) achieves this (Leontaritis and Billings, 1987). It is a recursive procedure:

The SFI rule: Initialize n a = n b = n c = n z = 0 While significant reduction, repeat For x ∈ (a, b, c, z), do Alternative order number: n → ν; ν x + 1 → ν x y N(1, θ ν)] Compute alternative loss: Q xν = min θ E[y N, ^ Find the alternative order number with the smallest loss: x = arg min x Q xν Test: If Q n − Q xν > χ 2 , then Q xν → Q n, ν x → n x, and indicate significant reduction

It is possible to design the loss function E and compute the χ 2 threshold in such a way that the decision of model order can be associated with risk values. The “Maximum−Power” loss function used by MoCaVa minimizes the risk for choosing a lower order when a higher order is correct. The threshold value χ 2 is based on a given risk for choosing the higher−order model, when the lower−order is the correct.

1.2.3 Grey−box Identification The formulation of “grey−box” identification as used in this book is similar to that of the black box: Model: F n(u t, ω t, θ n) → z(t|θ n) Predictor: P n(u t, y t−m, θ n) → ^ z(t|m, θ n) z N(m, θ n)] Fitting: Q n = min θ E[y N, ^ Test: Q n−1 − Q n < χ 2

(1.21) (1.22) (1.23) (1.24)

The only, but crucial difference is that the model class F n is no longer given by the method/program, but the designer is allowed to change it more freely, and in this way enter prior knowledge about the object of the modelling. How far this freedom will extend in practice depends on what the designer of a grey−box identification program finds it practical to include. Basic limiting factors are that prior knowledge must be

1 Prospects and Problems

11

able to convert into algorithms simple enough to allow i) simulation, ii) automatic derivation of at least an approximate predictor, and iii) fitting of parameters. The particular limitations imposed by MoCaVa will be specified below. Remark 1.4. Continuous−time white noise into nonlinear models has to be handled with care (Åström, 1970; Graebe, 1990b). In practice the equations have to be discretized, and ω replaced by discrete−time white noise w (Section A.1, Restriction #3). As would be expected, there are difficulties also with grey−box identification, some have been experienced using MoCaVa3 and its predecessors. Some may vanish with further development, others are fundamental and will remain: : Heavy computing: MoCaVa needs, in principle, to evaluate the sensitivities of all state derivatives with respect to all states and all noise variables for all instants in the time range of the data sample, and for deviations in all parameters that are to be fitted. And this must be repeated until convergence. And again, the whole process must be repeated until a satisfactory model structure has been found. In the worst case each evaluation requires access to the model, which altogether creates a very large number of executions of the algorithm defining the model. For other than small models the dominating part of the execution time is spent inside the user’s model. Since, the time it takes to run the user’s model once is not ‘negotiable’, the only option for improving the design of MoCaVa is to try and reduce the number of model accesses by taking shortcuts. However, since the model structure is relatively free, it is difficult to exploit special structural properties in order to be able to find the shortcuts, like the black−box methods are able to. A way that is still open is to have MoCaVa analyze the user−determined structure, in order to find such shortcuts. MoCaVa3 is provided with some tools to do this (see Section 2.5). : Interactive: It is difficult to reduce the time spent by the user in front of the computer, for instance by doing the heavy computing overnight. : Failures: More freedom means more possibilities to set up problems that MoCaVa cannot cope with. The result may be that the search cannot fit parameters, or worse, produces a model that is wrong, because the assumptions built into its design are not satisfied in the particular case. The ‘advanced’ options that may become necessary to use with complex models require some user’s specifications of approximation levels, and this adds another risk. The causes of failures are discussed in Section 2.7.6. : Stopping: Available criteria for deciding when to stop the calibration session are somewhat blunt instruments. When a model cannot be falsified by the default conditional tests, this may well be so because the user has run out of ideas on how to improve it. In that case unconditional tests will have to do. However, they do not generally have maximum power, and therefore have a larger risk of letting a wrong model pass. A user may have to supply subjective assessment, in particular by looking at ‘transients’ in the plotted residual sequences. : Too much stochastics: Stochastic models are marvellous short−range predictors, and therefore generally excel in reducing the loss, in particular with slowly responding processes. Technically, they have at their disposal the whole sequence of noise input to manipulate, in addition to the free parameters, in order to reduce the loss. However, they have a tendency to assign even some responses of known input to disturbances, if given too much freedom to do so. The result is inferior reproducibility, since disturbances are by definition not reproducible.

12

Practical Grey−box Process Identification

Example 1.3 Return again to the tank object, Equation 1.3, and assume that the varying pressure p has not been recorded during the experiment. Since the model class F n is not preprogrammed but defined by the user in each case, the user must enter code like der(z) = −a*sqrt(z*g + p/rho) + f/A

and, in addition, specify a model for describing the unknown p. The latter may well be a black−box (preprogrammed) model, unless one knows something particular about p, that does not let it be modelled by a black box. Since p is not in the data, the next step is to find a predictor for it, and for the output. When the model is nonlinear, an optimal predictor is usually not practical, but suboptimal predictors are. Most common are various types of EKF (for Extended Kalman Filter). Armed with such a predictor, it is possible to proceed as in the black−box case, although the mode of operation of the program will be different. Mainly, the EKF (which is preprogrammed) must call a function that defines the model class, and which depends on the entered code, and therefore must be compiled and linked for each case (like in white box identification, and like in any ODE solver in a simulation program). If, again for simplicity, the sampling interval h is short enough, and if the Brownian motion is used to model p, the discrete−time equivalent of the model will be z(t + h) = z(t) + h [− a z(t) g + p(t) Ã + f (t) A]

(1.25)

p(t + h) = p(t) + λ h w 2(t) y(t) = z(t) + σ w 1(t)

(1.26) (1.27)

where w i are uncorrelated Gaussian random sequences with zero means and unit variances, and σ and λ are parameters introduced to measure the average size of measurement errors and the average rate of change of the unknown pressure p. Unlike in Example 1.2, the measurements errors need not be small. It is convenient to use the state−equation form x(τ + 1) = G[x(τ)] + E w 2(τ) y(τ) = H x(τ) + σ w 1(τ)

(1.28) (1.29)

0 G(x) = x 1 + h[− a x 1 gx + x 2 Ã + u) A] , E = λ h 2

(1.30)

H= 1 0

(1.31)

where

The EKF in MoCaVa uses an observer of the following type: x(τ) = x(τ) + ~x(τ) y(τ) = C [x(τ) + ~x(τ)] e(τ) = y(τ) − ^ y(τ) x(τ + 1) = G[x(τ)] ~ x(τ + 1) = A(τ) ~x(τ) + K(τ) e(τ) ^

^

(1.32) (1.33) (1.34) (1.35) (1.36)

1 Prospects and Problems

13

where A(τ) = ∇ x G(x), C = H. The optimal filter gain K(τ) is computed using an algorithm that involves the solution R xx(τ) of the Riccati equation associated with Equations 1.28 to 1.31. Remark 1.5. It is more common to use G(x^) in Equation 1.35 instead of G(x), since this makes a better approximation, should the estimate ^ x drift far from the reference trajectory x. On the other hand, this will make the EKF more susceptible to large disturbances, and will thus increase the risk for instability. With Equation 1.35, both this and Equation 1.36 are stable as long as the model is, while a negative value of ^ x1 g + ^ x 2 Ã, for instance caused by a spurious value in y(τ), would cause a run−time error in the evaluation of G(x^). Notice that most matrices that are needed to handle the consequences of having an unknown input depend on τ, which means that the calculations generally take much more time than with a white box. The predictor is given by Equation 1.33, the prediction error by Equation 1.34, and the loss function is computed from Equation 2.23:

R e(τ) = σ 2 + C R xx (τ) C T

(1.37)

Q(θ) = 1 [log R e(k) + e(k) 2 R e(k)] 2 k=1

(1.38)

N

It is a function of θ = (a, A, Ã, λ, σ), which can therefore be estimated by an optimization routine, like in the white−box case. An option that can be copied from the black−box identification procedure is the estimation of model complexity, by testing whether all parameters are significant, or, alternatively, some could possibly be left out from the model. For instance, the SFI rule will work, and risk values for making a wrong decision can be computed.

1.3 Basic Questions ... MoCaVa has been conceived with the following scenario in mind: Suppose a production process is to be described by a dynamic model for simulation or other purposes. A number of submodels (or first principles or heuristic relations) for parts of the process are available as prior information, developed under more or less well controlled conditions. However, when the submodels are assembled into a model for the integrated process, all their input and output are no longer controlled or measured, and the environment is no longer the same as when the submodels were developed. In addition, unmodelled phenomena and unmeasurable input (disturbances) may effect the responses significantly. It is not known which of the submodels that are needed for a satisfactory model, or whether there will still remain unexplained phenomena in the data, when all prior information has been used. And, again, prior model information is more or less precise, reliable, and relevant. This raises a number of questions from a model designer: : How can I make use of what I do know? One usually knows some, but not all. And it may be a waste not to use it. : How much of my prior knowledge is useful, or even correct when used in the particular environment? Too much detailed knowledge tends only to contribute to the complexity of the model and less to satisfying the purpose for which it is made.

14

Practical Grey−box Process Identification

Formulas obtained from the literature are often derived and verified in an environment quite different from the circumstances under which they will be put to use. : What do I do about the disturbances I cannot eliminate? This is the opposite problem: too little prior knowledge. The response of an object is usually the effect of two kinds of input, known and unknown. Call the second “disturbances”. If one does not have a model for computing the unknown input, and cannot just neglect it, then some will obviously have to be assumed instead. : Are my experiment data sufficient and relevant? Can I use ordinary data loggings, obtained during normal production and therefore at little cost? Or do I have to make specially designed experiments (and lose production while it is going on)? : How do I know when the model is good enough? It may (or may not) be hazardous just to try and use the model for the purpose it was designed, for instance control, and see if it works. That depends of course on what it costs to fail. 1.3.1 Calibration Needless to say, none of the questions can be answered in advance. Considering the diversity of a user’s prior information, originating in a variety of more or less reliable sources, it is also very unlikely that one would be able to formulate, much less solve, a mathematical problem that, given prior input and data, would produce a ‘best’ model according to a given criterion (and thus be able retain the usual definition of the identification problem). However, it is possible to conceive a multistep procedure for making a model that satisfies many of the demands one may have on it, and taking the user’s prior knowledge into account. The steps in this procedure will require the solutions of less demanding subproblems, like fitting to data, and testing whether one model is significantly better than another. The literature offers principles and ideas for solving many of the subproblems, and a number of those have been compiled into a systematic procedure for grey−box identification (Bohlin, 1986, 1991a, 1994a). One of the procedures has also been implemented as a User’s Shell (IKUS) to IdKit (Bohlin, 1993). However, its principles are general and can be implemented with other tool boxes that are general enough and open enough. MoCaVa is based on two such ‘trial−and−error’ procedures, calibration and validation. The procedures operate on sets of models, since it is not given a priori how extensive the set has to be in order to satisfy the experiment data and the purpose of the model making. The calibration routine finds the simplest model that is consistent with prior knowledge and not falsified by experiment data. It is a double loop of refinement and falsification derived from basic principles of inference (Bohlin, 1991a):

Calibration procedure: While the model set is falsified, repeat Refine the tentative model set Fit model parameters Falsify the tentative model: Until falsified, repeat Specify an alternative model set If any alternative model is better, then indicate falsified

Notice that the procedure works with two sets and two models, namely tentative, which is the best so far, and alternative, which may or may not be better.

1 Prospects and Problems

15

The questions that have to be answered are now i) how to specify a model set, ii) how to fit a model within a given set, and iii) how to decide whether an alternative model is better than a tentative one. 1.3.2 How to Specify a Model Set The following first structuring of the model set F is motivated by the mode of operation of computers and common system software, like Unix and Windows. Assume there is a given component library {< i}, such that a given selection of its members will combine into a system defining an algorithm able to compute response values z(t), given input arguments. Define the model sets Model: F(u t, ω t, , ν , θ ν) Model structure: F(u t, ω t, , ν , ·) Model class: F(u t, ω t, , ·, ·) Model library: F(u t, ω t, ·, ·, ·)

(1.30) (1.40) (1.41) (1.42)

where

: A model library is the set of all models that can be formed by combining components < i . It is the maximum set within which to look for a model.

: A model class is a smaller set, defined by the argument , which is an array of indices of selected components.

: A model structure is an even smaller set, where also the free−space index ν is giv-

en. This determines the dimension of the free parameter space with coordinates θ ν. : A model is a single member in the model structure, selected by specifying also the values of the free coordinates θ ν. It includes all specifications necessary to carry out a simulation of the model given the control input, the random sequence, and the time range. Notice that this creates two means of refining a model set: with more components, or with more free parameters. Change of model class requires recompilation in order to generate efficient code, change of model structure and model does not. The definition also concretizes ‘prior knowledge’ as (hypothetical) algebraic relations between variables, and various variable attributes (like ranges, scales, values, and uncertainty). The case−specific model library contains prior knowledge of the object, while class and structure will depend also on the experiment data. The slightly more structured procedure becomes Calibration procedure: While the structure is falsified, repeat Refine the tentative model structure: → F(u t, ω t, ^, ^ ν , ·) ^ Fit model parameters: → F(u t, ω t, ^, ^ ν , θ ν) Falsify the tentative model: Until falsified, repeat If no more alternative structures, then expand the alternative model class: → F(u t, ω t, , ·, ·) Specify alternative model structures: → F(u t, ω t, , ν , ·) If any alternative model is better, then indicate falsified and assign → ^, ν → ^ ν

16

Practical Grey−box Process Identification

The procedure does fitting and testing of an expanding sequence of hypothetical model structures. It starts with those based on the simplest and most reliable components in the component library, for instance those based on mass and energy balances. The structure is then expanded by a procedure of ‘pruning and cultivation’: Hypothetical submodels (components) are augmented and the structure is tested again. Those who do not contribute to reducing the value of the loss function are eliminated. Those who do contribute become candidates for further refinement. The procedure is interactive: The computer does the elimination, and also suggests the most probable of a limited number of alternatives. The model designer suggests the alternatives. In this way a user of MoCaVa is given an opportunity to exploit his or her knowledge of the physical object and exercise the probably increasing skill in modelling, in order to reduce the number of tests of alternatives that would be needed otherwise. The construction is based on the belief that, even if it is difficult to specify the right model structure in advance, an engineer is usually good at improving a model, when it has been revealed where it fails. As a last resort it is possible to use empirical ‘black boxes’ to model such parts or physical phenomena of a process, that have been revealed as significant, but for which there is no prior knowledge. Example 1.4 Consider the following transfer function model z=

B 1(p|n b1) B 2(p|n b2) C(p|n c) ω P (u) + P (u)+ 2 1 D(p|n d) A 1(p|n a1) A 2(p|n a2)

(1.43)

where D(p|n) = d 0 + d 1 p + ööö + d n p n , and C, A i, B i have similar forms. P 1 and P 2 are polynomials, for instance Legendre polynomials, of first and second order, and ω is continuous white noise with unit power density. Then Equation 1.43 defines the model F(u t, ω t, , ν , θ ν) with = (1, 2, 3) (1.44) ν = (n a1, n b1, n a2, n b2, n c, n d) (1.45) θ ν = (θ a11, ööö , θ a1n, θ b11, ööö , θ b1n , θ a21, ööö , θ a2n, θ b21, ööö , θ b2n,θ c1, ööö , θ cn, θ d1, ööö , θ bn) (1.46) The point of the double indexing with and ν is that it allows the definition of a number of smaller model classes F(u t, ω t, , ·, ·), for instance: : Linear and deterministic: = (1), ν = (n a1, n b1) : Linear and stochastic: = (1, 3), ν = (n a1, n b1, n c, n d) : Nonlinear and deterministic: = (1, 2), ν = (n a1, n b1, n a2, n b2) plus a number of less likely alternatives. Notice that change of class changes the functions (differential equations) and hence the source code of the computer program, which means recompilation. Each class allows a number of model structuresF(u t, ω t, , ν , ·), defined by the values of the order numbers ν , which also determines the number of parameters in the model structure. Change of structure does not generally require recompilation, provided enough space has been allocated for a maximum order, or dynamic allocation is used. When also the values of the parameters are given, this defines the model.

1 Prospects and Problems

17

The model library F(u t, ω t, ·, ·, ·) is the set of model classes from which the user can pick one by specifying . Each transfer function in Equation 1.43 defines a component. If, as in this example, all can be combined, this generates eight model classes in the library, including the ‘null’ model class y = 0.

1.4 ... and a Way to Get Answers How does this answer the original questions from a model designer? : Question: How can I make use of what I do know? Answer: By entering hypotheses, and by specifying which of those to try next. : Question: How much of my prior knowledge is useful, or even correct when used in the particular environment? Answer: That is useful which reduces loss significantly. It is correct, if fitting its parameters yields values that do not contradict any prior knowledge. : Question: What do I do with the disturbances I cannot eliminate? Answer: Describe them as stochastic processes. : Question: How do I know when the model is good enough? Answer: There are two meanings of “good enough”: i) The model is not good enough for available data and prior knowledge, as long as it can still be falsified. ii) The model is good enough for its purpose, when the validation procedure yields a satisfactory result. : Question: Are my experiment data sufficient and relevant? Answer: They are, if the validation procedure yields a result satisfying the purpose of the model design. Remark 1.6. Valid logical objections can be raised against these rather flat answers. For instance, it is possible to conceive cases, where the experiment data is adequate for the purpose, but where the calibration procedure has failed to reveal errors in the model structure (because there are no better alternative hypotheses). It is also possible to conceive disturbances that do not let themselves be described by stochastic processes of the types available in the library, or at all. All hinges on the assumption that the model library will indeed allow an adequate modelling. Remark 1.7. Even if there are cases where it is theoretically correct to use the same data for calibration and validation (‘auto−validation’), it is generally safer to base the validation on a second data set (‘cross−validation’). Still, much of the results of the validation procedure hinges on the assumption that the second data set is demanding enough. If it is not, the validation procedure will not reveal an inadequate model. In fact, a failure will not be revealed until the model has been put to use and failed obviously. The costs related to the latter event, will therefore determine how much work to put into the validation process. For instance, paper machine control can afford to fail occasionally, Mars landers rather not at all. Remark 1.8. Logically, the calibration and validation procedures have little to do with one another, since the meanings of a “good model” are different. A model may well be good enough for such a limited purpose as feedback control, and thus easily validated in that respect, but still be unable to satisfy an extensive data sequence generated by a complex object. Conversely, a model satisfying a data sequence containing little dynamic information, may well satisfy that data, as well as all one knows about the object in advance, but still be unable to satisfy its purpose when validated with different and more damanding data.

18

Practical Grey−box Process Identification

1.5 Tools for Grey−box Identification The following is a list of what is needed for realizing the calibration and validation schemes: : A versatile class of models: So that it does contain a suitable model for the particular purpose. Models must be possible to simulate and fit conveniently. : A tool to restrict this class according to prior knowledge: This is the whole point of the grey box concept. It means that there must be some modelling tool, allowing the user to formulate the prior knowledge conveniently. Model class restriction is what identification is all about, and user−supportedrestriction is what grey−box identification is all about. : A tool to fit parameters: In order to find the model that agrees with data most. : A tool to falsify fitted models: In order to eliminate incorrect hypotheses about the object. : A tool to validate models: So that the model will not be more complicated than needed for the purpose. : A procedure to follow: In addition to the tool kit there is also a need for some kind of ‘handbook’ or ‘guide’ on how to build grey−box models using the tools. Again, grey−box model making is an interactive process: At each step, the software may or may not need more information from the user, or more data, depending on whether the result so far is satisfactory or not. Remark 1.9. The list leaves out the problem of what to do when no model is good enough for the purpose. An answer is to try and get better data, and there are methods for doing this in the literature, again valid for certain classes of models. MoCaVa does not support this. 1.5.1 Available Tools Some of the tools have been available for some time. Let’s look at what they can and cannot do, in order to find out what more is needed. Nonlinear State Models A reasonably general form that evades the subtleties of continuous−time stochastic differential equations, and lets itself be simulated is dxdt = G(x, u, p) + ω y = H(x, p) + w

(1.47) (1.48)

where x is the state vector, u is known control, ω and w are continuous and discrete ‘white noises’, and p are parameters. This is a rather versatile class that suits many physical processes, and is used, for instance, in the identification tool boxes in the Cypros (Camo, 1987), Matrixx (Gupta et al., 1993), IdKit (Graebe, 1990a−d; Graebe and Bohlin, 1992; Bohlin and Graebe, 1994a,b), and CTSM (Kristensen and Madsen, 2003) packages. Given models of this form the tools fit parameters p to given data. All use the Maximum Likelihood criterion, but different ways of fitting. The first two are commercial products. IdKit is not commercial; it has been used for case studies and has been developed into MoCaVa. Kristensen, Madsen, and Jørgensen (2004) use a somewhat more general form of Equation 1.48, where the variance of the ‘diffusion term’ ω may depend on u,p,t.

1 Prospects and Problems

19

What are the obstacles to a wider application of grey−box Maximum Likelihood identification tools? Mainly that they are difficult to use for other than experts. There are difficulties with : Modelling: Since one has usually to try a large number of structures before finding a suitable one, in particular with models of the complexity required by a full−scale industrial process, it becomes quite a tedious task to write all the models, and also to maintain the necessary housekeeping of all rejected attempts. : Setup and interpretation: It is easy to set up meaningless problems for the tools to solve (which they gladly do). It is more difficult to see whether the solutions are any good. : The state−differential equations also leave out important dynamical properties of some real objects, for instance those containing delays, or phenomena better described by partial differential equations, or containing hard discontinuities, like dry friction.

Modelling Tools They are tools to enter prior knowledge. Examples are SimulinkX (www.mathworks.com/products/simulink), Bond graphs (Margolis, 1992), DymolaZ (Elmqvist, 1978), Omola (Mattson et al., 1993), and ModelicaX (Tiller, 2001). SimulinkX is probably the most well known, and most adapted to the way control engineers like to describe systems. It generates the model−defining statements from block diagrams. The other are in principle model specification languages and tools, and they are normally combined with simulation programs that accept models defined in these particular languages. Sørlie (1994a, 1995a, 1996d) has shown a way to use Omola to write models for IdKit. It is still a considerable effort to write models in these languages, instead of directly in some programming language, such as M−files or C (in addition to the effort of learning a new language). However, the advantage of using a comprehensive modelling language is that it prevents the writing of inconsistent model equations. It is also possible to include extensive libraries of component models, thus simplifying the modelling. There is still no guarantee that the identification problems set up using these tools make sense. The languages were developed for simulation purposes. There are some problems with using them for grey−box identification: : Specialized languages: The languages are basic, and the user has to learn one of them. Like other computer languages they tend to develop into covering more and more objects, and this makes them more general and more abstract. Libraries may show a way out, but are of course limited by what the vendor finds it profitable to develop. In addition, since calibrating and validating a model is a much more demanding task than simulating it, the development tends to allow the writing of models increasingly less suitable for identification purposes. Again, more libraries may be a way out, if specialized to suit the identification purpose. : ODE solving and parameter optimization: There are special numerical problems associated with combining standard optimizers with efficient ODE solvers using step−length control. The numerical errors interfere. This means in practice that both integration and optimization will have to be done with extremely high numerical precision. There is at least one program (diffpar, Edsberg and Wikström, 1995) designed to do simultaneous integration and optimization. It handles only models without disturbances.

20

Practical Grey−box Process Identification

: Not predicting models: Grey−box identification is not simulation plus fitting, it is prediction plus fitting (and more). Modelling languages do not primarily produce predicting models. The difference is that a predictor uses past input and output to compute the next output, a simulator only past input. The difference is important when disturbances are important. Whenever it pays to have feedback control it also pays to use a predictive model, most obviously if the purpose is Model Predictive Control. Even if it is possible, in principle, to derive a predicting model from a simulating one, this is no easy task. It is known as ‘the nonlinear filtering problem’, and, in fact, only few cases have been solved so far. In practice it is not as bad as that, since approximating filters may be enough. Sørlie (1996) has investigated the possibilities of combining Omola with an Extended Kalman Filter.

Optimization Tools Classical optimization methods are those of Fletcher−Powell and Newton−Raphson type, and there are well developed computer libraries for doing the kind of continuous parameter optimization needed in both white, black, and grey−box identification. A particular prerequisite of model−fitting is that one cannot usually afford to evaluate the loss function a large number of times. Quasi−Newton methods are particularly effective for predictive models (Liao, 1989a). The reason is that one obtains the fast convergence of a second−order search method from evaluations of first−order derivatives of the model output. However, this enhances the search problem in more difficult cases: : Multiple minima: Global search methods, like the new and intuitively attractive method of ‘genetic programming’ tend to take an uncomfortably large number of loss evaluations. Alternatively, local search methods may have to be applied several times with different start values. : Discontinuities: The presence of discontinuities in the model’s parameter dependence ruins any search based on assumptions of continuity. Less serious, but still troublesome are discontinuities in parameter sensitivity. Validation and Falsification Once again, those tasks have basically different purposes: Falsification decides whether a model is good enough for the available data. Validation decides whether it is good enough for its purpose. A model can be both “false” and “valid”, as well as any other of the four possible combinations of the outcomes of the two tests. There are several quite general statistical tests for the falsification task, and most black−box identification packages support some of them, mainly ‘chi−square’ and ‘cross−correlation’ tests. They are typically used for order determination. Likelihood−Ratio tests are applicable to nonlinear models, and in addition have maximum discriminating power, i.e., they have the maximum probability of rejecting an incorrect model, for a given risk of rejecting a correct one. Validation is conventionally done by making a loss function that reflects the purpose of the modelling, evaluating the loss for the candidate model and see whether it is below a likewise given threshold. The simplest case is that when the modelling is done for control purposes, because a suitable loss is then the prediction error variance (when the model is evaluated using a different data sample). Remark 1.10. Falsification methods are sometimes found under the “validation” keyword in the literature.

1 Prospects and Problems

21

Calibration Procedure The procedure is a codification of the general approach scientist’s use when drawing conclusions from observations (which is the core of model making). In essence, the method adapts the rules to the case of state−vector models, and in this way lays a foundation for a user’s guide. Which can conceivably be implemented on a computer, and has been implemented in MoCaVa. 1.5.2 Tools that Need to Be Developed Generally, there are tools enough to make grey−box models, and evidence that it can be done in practice, if one knows how to use the tools. What remains is to make it easier. This is not without problems, however. The man−machine communication problem has to be considered. And communication has two directions: : User input: What prior information is it reasonable to ask from the user? The problem is enhanced by the fact that users in different branches of engineering have different ways of looking at models, and therefore different kinds of prior knowledge. This means that, ideally, there should be different man−machine interfaces for different categories of users. The interface implemented in MoCaVa is designed for process engineers, more than control engineers. : User support: The task which rests most heavily on the user is deciding what to do next, when a model has been found inadequate. What the computer can conceivably do to facilitate this is to present the evidence of the test results in a way that reveals at which point the model fails and that also is easy to understand. Unfortunately, general tests are rather blunt instruments in this respect. The result of a statistical test has the binary value of either “passed” or “failed” (in practice, it tends to be “failed”, since maximum−power statistical tests are honed to razor sharpness in that respect). However, there are some means to get more information out of testing a given model. An option in MoCaVa works in connection with the stepwise refinement and falsification of the model structure outlined above. It is based on an idea that can be illustrated by the following simple example: Assume that the current tentative structure is expanded by a free parameter p, whose value is known a priori to be positive. Instead of limiting the search to positive values, it is more informative to proceed as follows: Do not limit the search to positive values. Then the test has one of three possible outcomes as depicted in Figure 1.1: Hypothesis H 0 represents the tentative model (p = 0) and H 1 an alternative ( p ≠ 0). The particular case that there is an alternative but inadmissible model with a significantly lower loss Q(p < 0) means that H 0 is still rejected (since a better model does exist), but H 1 is not the one, and the alternative structure does not contain one. This gives two pieces of information to the model designer: 1) Continue the search for a better model, and 2) Use another model structure. In addition, the component of the total model to improve is the one containing the unsuccessful expansion. This determines whether a component is worth cultivating or not. In conclusion, statistical tests give a two−valued answer, but tests combined with prior structure knowledge may yield more. Remark 1.11. Notice that H 0 is rejected as soon as there is some alternative model H 1 within the alternative structure with a loss below the threshold χ 2. This means that there is no need to search for the alternative with the smallest loss, in order to test the tentative model, except when it cannot be rejected.

22

Practical Grey−box Process Identification

Q(p)

χ2

p H0 not rejected H0 rejected. H1 better

H0 rejected. H1 wrong

Figure 1.1. Illustrating the three possible results of falsification

Conditional and Unconditional Tests The rule used to decide whether a tentative model structure is falsified or not depends on the alternative structure, and is therefore ‘conditional’ on the alternative. ‘Unconditional’ tests do not assume an explicit alternative, but instead aim at testing the basic hypothesis that known and unknown input are independent. If not, there is obviously information in the input data that could be used to improve the estimation of the unknown input and thus the predicting ability of the model. The disadvantage of unconditional tests is that they are less discriminating, i.e., they let a wider range of similar models pass the test. This is so, because the set of implicit ‘alternatives’ is much wider. However, they are still applicable, when the model designer has run out of useful prior knowledge. The following modified calibration procedure takes into account the prospects offered by the various tests:

Calibration procedure: While there is a better model, repeat Refine the tentative model structure: → F(u t, ω t, ^, ^ ν , ·) ^ Fit model parameters: → F(u t, ω t, ^, ^ ν , θ ν) Test the tentative model: Until better model, repeat If no more alternative structures, then expand the alternative model class:→ F(u t, ω t, , ·, ·) Specify alternative model structures: → F(u t, ω t, , ν , ·) If an alternative model is significantly better, then indicate falsified If an admissible alternative model is significantly better, then indicate better model and assign → ^, ν → ^ ν If unfalsified, then test unconditionally: → falsified|unfalsified

2

The MoCaVa Solution

The analysis in chapter 1 outlines what the purpose of the model making would require MoCaVa to do. That must be reconciled, somehow, with the restrictions set by what a computer can do in reasonable execution time. MoCaVa therefore contains further restrictions in order to compromise between the two. In essence, MoCaVa makes use of the following tools: : State−vector models. : A new modelling procedure based on elementary MATLABX statements for user− defined relations, and library routines for some tasks common to all models. : Extended Kalman filtering to produce approximate predictors. : Newton−Raphson search. : Modified Likelihood−Ratio and correlation tests. : The general calibration procedure outlined in Section 1.5.2. : A collection of heuristic validation rules. Chapter 2 describes how these general tools are implemented, and motivates the restrictions that make it possible.

2.1 The Model Set A second compromise that must be made in the design of MoCaVa is that between the conflicting goals of versatility and convenience of the user’s modelling task. The model set used in MoCaVa is therefore structured further to adapt to common properties of industrial production processes, in particular to continuous transport processes. The latter may be characterized as systems of separate units, each one accepting flows of commodities from one or more preceding units, changing their properties, and feeding the product to one or more following units. Since there is an obvious cause−and−effect relationship between the input and output variables of the units, state−vector models (defined by assignment statements) are convenient to use in those cases. Secondly, the operation of an individual unit is generally a result of interaction between particular physical phenomena (at least ‘first principles’ are generally expressed in this way). Also the different phenomena may be described by submodels. A third common characteristic of production processes is that the operation of some units may be affected by the operations of other, control units. Instead of flows (mass or energy), they produce information input to the affected unit, but are still describable by the same type of submodel. In order to satisfy the requirements MoCaVa is able to administer the creation of submodels, and to connect them into systems.

24

Practical Grey−box Process Identification

Remark 2.1. Narrowing the area of easy applications necessarily makes the model set less versatile. In particular, it will not be convenient to model mechanical objects consisting of a large number of linked moving parts within the framework of MoCaVa. Remark 2.2. The assumption of causality between variables is crucial to the design of MoCaVa, and cannot be amended by a different user interface. The motivation for still requiring the direction of causality to be specified by the user (by entering assignment statements) is that in production processes causality is usually known from the construction of the process, that it is important prior knowledge, and that using it may prevent the program from processing mathematically feasible but unphysical alternatives. Example: An engineer knows whether an electric circuit is driven by current ( i R → V) or voltage ( V R → i), and so does the computer, if given an assignment statement. It does not know, if given only the equation i R = V, and will therefore have to keep both alternatives open. 2.1.1 Time Variables and Sampling One of the properties of production processes is that they seldom have regular and reliable sampling of all variables. There are gaps, outliers, different sampling frequencies, and possibly laboratory measurements at irregular intervals. In order to handle this IdKit (the subkit of MoCaVa doing the simulation and fitting) recognizes three time variables: : Physical time t (continuous) : Discrete time τ (equidistant) : Sampling time t k (discrete and irregular) Only physical time is used in the model equations and as sampling time in the data file. The discrete time is internal to IdKit and transparent to the user. Even so, its meaning is not irrelevant to the user, since it plays a rôle in the execution of the predictor associated with the model. When the loss function is evaluated, that is done in discrete time; the continuous−time model is integrated over consecutive intervals of fixed lengths h, called “time quantum”, in order to compute the residuals e(τ) the loss is based on. The relation between the discrete times and the corresponding physical times the model is accessed is t τ = t i + hτ, where t i is the startup time of the model, i.e., the time the state variables are initialized. The relation is depicted in Figure 2.1 together with its relation to the sampling times. h Continuous time

ti

t1 t2

t3 t4 t5

0 1 2 3 4 5 6

t6

tk

tN Discrete time

τ

Figure 2.1. Illustrating the relation between continuous and disrete time variables

The time quantum is an important design parameter, basically to be set by the user. Making it as large as possible reduces computing. However, its length is limited in two ways: i) It must not be longer than the shortest sampling interval, since residuals have to be evaluated at least each time there is a data point, and ii) it is limited by the longest range still allowing prediction with acceptable error of the relevant variables in the model, i.e., state and output. The default value of h is the shortest sampling interval,

2 The MoCaVa solution

25

i.e., the interval between the time markings in data records. If it becomes necessary to have a shorter value (because the model cannot predict that long), h must be an integer part of the shortest sampling interval. It follows that all sampling times must also be multiples of the time quantum. If the sampling is too irregular, it may be necessary to approximate for the sake of fast execution, for instance to adjust the sampling points to the nearest quantum point. The startup time is also a design parameter, with the restriction that the startup must be at least one time quantum before the first data in the sample, t i t 1 − h, which is also the default value (otherwise the first data point will not be taken into account). However, in cases where it may be difficult to find good values for the states to start with, for instance, one would like to start in steady state to avoid large start transients from the model, this can be achieved by specifying a starting time sufficiently far ahead of the first data point. Remark 2.3. In case the user is uncertain of the ability of the model to predict over the default time quantum, a feasible test is to cut the time quantum in half, and see if the loss function changes noticeably. Remark 2.4: Notice that the time quantum does not play the rôle of an integration step for the model’s ODE. Hence, it is not limited by the shortest time constant of the dynamic model. IdKit uses a stiff ODE solver capable of integrating longer intervals. 2.1.2 Process, Environment, and Data Interfaces A second restriction built into the model classes used in MoCaVa is also motivated by common properties of industrial production processes: Models are structured as the four−boxes system depicted in Figure 2.2. The purpose is to separate the modelling of the basically continuous−time process from those of its environment and the two computer interfaces, which must be modelled using both continuous and discrete time. The separation relieves the user of the more tricky task of writing hybrid models for conversion and disturbance generation. The only modelling that requires explicit entering of algebraic statements is that of the process proper (using only physical time). Modelling of the other blocks is done by selecting standard routines from a library. w y(k)

w(τ) Environment v(t) u

Experimenter

d (k)

Actuator

v(t) u(t)

Process

z(t)

Sensor

d y(k)

Data acquisition

Figure 2.2. Structure of the identification object (shaded area)

The following terminology will be used for the variables appearing in Figure 2.2: The output z(t) from the process is called “response”. The two kinds of input are “stimulus” u(t) and “disturbance” v(t), the difference being that stimulus is influenced by an external “control sequence” d u(k), while disturbances are not. Some of the re-

26

Practical Grey−box Process Identification

sponses, disturbances, and stimuli have sampling sensors attached to them, which produces “sensor output” y(k) = d y(k). The two random sequences are called “process noise” w(τ) and “measurement noise” w y(k). Remark 2.5. The terms “input” and “output” must be used with care. For instance, “stimulus” u(t) is input to the process proper, the box of most interest to the user, but it is an “output” from the “object”, which also includes the other boxes. The following generic forms of the block contents are a tradeoff between what needs to be modelled in normal processes and what can be handled conveniently by IdKit. The restrictions are discussed in Section A.1. The purpose of this is to provide a user with a list of the requirements that have to be satisfied a priori in order to render it worth while to try and use MoCaVa. Environment: dx v(t) dt = G v[x v(t), w(τ), p] v(t) = Z v[x v(t), p], t ∈ [t τ, t τ+1)

(2.1) (2.2)

Actuator: dx u(t) dt = G u[x u(t), u d(τ + 1), p] u(t) = Zu[x u(t), u d(τ), p], t ∈ [t τ, t τ+1)

(2.3) (2.4)

Process proper: dx z(t) dt = G z[x z(t), v(t), u(t), t, p] z(t) = Z z[x z(t), v(t), u(t), t, p], t ∈ [t τ, t τ+1)

(2.5) (2.6)

Sensor: y(k) = Zy[z(t k), v(t k), u(t k), w y(k), p]

(2.7)

Remark 2.6. The actuator requires a discrete−time input u d(τ) defined for each τ−value. If the time quantum is shorter than the sampling interval, or some data points are missing, the stimulus u d(τ) will have to be reconstructed from the data d u(k). This is done by linear interpolation, which may not always be satisfactory. The problem of a more ‘tailored’ interpolation between input data with irregular intervals is not solved in the current version MoCaVa3. The restrictions are compromises between the desire to allow a large time quantum h (for the sake of fast computing) and not to exclude too many common processes properties: : IdKit uses a special, stiff ODE solver, which does not have a variable integration step. It does however require that the small signal dynamics (local sensitivity matrices) change only little during a time quantum. Since no input u d(τ), w(τ) changes during a quantum, the restriction means that any rapid state changes during a quantum must be small enough to stay in a state interval where local linearization around the operating point is acceptable. Hence, changes in state variables are allowed to be steep or large, but not both steep and large within the same quantum interval. If they do, and if the rapid change is caused by random effects, then also the Discrete Extended Kalman Filter will break down. It is obviously impossible to predict anything at all with a reasonable meaning of the word, if states may jump around randomly with large increments. Neither would there be any hope of calibrating a model of such a process, unless some of its responses are sampled with

2 The MoCaVa solution

27

a much higher rate. The latter would then change the value of h and the result may again satisfy the requirement. : Only disturbances with frequency spectra below 1/2h are possible to model by the standard models in the MoCaVa library. The environment models create continuous−time disturbances v(t) from discrete−time random input w(τ), and cannot vary too fast. For instance, the simplest standard model, the “Brownian”, integrates a step function with Gaussian (0,1) random amplitudes normalized with a factor h −½. The normalization ensures approximately the same disturbance level, should the user change the value of of h. Remark 2.7. Earlier versions of IdKit supported certain classes of disturbances with larger bandwidths (such as ‘white noise’). Those disturbances must enter as terms added to the state derivatives. However, the modelling kit in MoCaVa3 does not allow them. Since the mathematics of high frequency noise into nonlinear ODE models has certain properties that may be unexpected to an engineer used to either white−box or linear black−box identification (Graebe, 1990b), the option would largely increase the risk of getting a nonsense result, without any diagnostic message. High−frequency disturbances whose variances do not depend on the state are reasonably safe. They may be allowed in future releases of MoCaVa, but then as an ‘advanced modelling’ option (see Section A.3). In practice, the restriction should not be a serious one. Since h is normally determined by the sampling frequency, the effects of much faster disturbances will not be possible to observe in the sampled response. They can therefore be ignored in the modelling, at least as long as their effects are dominantly linear. A troublesome case is when they are not. For instance, should their effects accumulate in a strongly nonlinear way, such as would be the case with heating due to, say, friction caused by an unknown and fast changing load (for instance a fast moving vehicle in rough terrain), then the effect would not be negligible. In that case something should be measured at sufficiently high rate, preferably the load. Remark 2.8. It has not been investigated what classes of random signals that are possible to generate by linear filters triggered randomly at discrete events. The frequency spectrum is certainly not limited by 1/2h. For instance, an oscillator would be able to make ‘music’ with a limited rate of change of notes, but without a limit to the highest note. Remark 2.9. An alternative to the ‘state−vector’ model is the ‘phase−variable’ model y(τ) = P(y τ−1, u τ, w τ, τ, p), where P is an invertible function, such that w(τ) = W(y τ, u τ, w τ−1, τ, p). The designer is required to reduce the number of noise sources to equal the number of measured variables, but that should be no problem in practice. More restricting is the fact that the designer must specify a “predictor model” P from the beginning, eliminating all unmeasured variables, for instance by using a likewise prespecified “observer”. However, if that can be done, the evaluation of the likelihood function will be straightforward (Bohlin, 1987b; Liao, 1989b−c, 1990). The model class is not implemented with MoCaVa3. However, an application has been published (Markusson and Bohlin, 1997; Markusson, 2002). 2.1.3 Multi−component Models The requirement of easy modelling of production processes requires a convenient handling of submodels and of their connections into systems. The following allows a further structuring of the general modelling concepts discussed in Section 1.3.2. : Model component: < i : Component library: F = {< i }

28

Practical Grey−box Process Identification

Parameter map: p i = I i(o i, ν i, θ i), with o i = I i(o i, ν i, 0) Model class: F = {< i, Ii|i ∈ } Model structure: F n = F ν = {< i, Ii, o i, ν i|i ∈ }, where n = Σ i|ν i| Model: M ν = {< i, Ii, o i, ν i, θ i|i ∈ } Model components are ordered in the library according to their given cause−and−effect relationships. Hence, activated components are executed in the order of decreasing number of their indices i. The Parameter map I i maps the infinite range of all free coordinate vector values θ i into the admissible range of the physical parameter vector p i belonging to the component. The parameter value o i corresponding to θ i = 0 is called the “origin”. The map is prior information, while o i, ν i, and θ i are not. The point of the mapping is that it allows the user to enter prior information on parameter ranges and to change the selection of parameters that are free to estimate. Typically, the entries of ν i take positive values only for those parameters in p i that are currently to be fitted and tested for deviation from the current origin o i. The free parameter index is an important user’s control variable in the interactive identification procedure. Parameters may be shared between components. Such a parameter belongs to the first component it is defined in (the one with the lowest number). The model class is defined by setting the activity index (requires automatic recompilation). It contains definitions of the activated components < i , sufficient to simulate the model when given in−data and parameter values. In addition, it contains the parameter maps I i . Setting also the origin o i and dimensions of the free parameter spaces, by the free− space indices ν i, makes the model class into a model structure. That is done without recompilation, and the values of o and ν , like , are not prior knowledge. The model is defined by also specifying the free coordinates. In addition to all information needed to simulate the model, it also contains information on how it was fitted to data. The latter yields information on its degree of dependence on the data sample. That number, n = Σ i|ν i|, is the number of parameter entries fitted to data, and used in MoCaVa as a measure of model complexity. It has an important rôle in the falsification procedure. Following the principle of parsimony, MoCaVa prefers models having low values of n, unless a model with a larger n has a significantly smaller loss. Remark 2.10. The required ordering of components is only partial: Components, whose operation depends on those of other components must have a smaller index. It is therefore irrelevant where in the library to place a new component, as long as that is after the last component it is designed to connect to. Placing components in the order they are created is therefore safe, unless it would contain a parameter that has been defined before, and, in addition, whose defining component may be deactivated and possibly replaced by another, previously created component. Remark 2.11. If an argument in an active component is shared, and the component it was defined in has been deactivated, this will mean an incomplete system. Rectifying this will require the re−definition of the active component to include certain specifications of implicit attributes. The restriction resembles that of the linking of object modules into an executable program: The linker will not accept undefined global variables. Some of the consequences of constructing counter−logical networks of components are detected by MoCaVa3, and result in error messages stating the cause. But possibly not all...

: : : :

2 The MoCaVa solution

29

2.1.4 Expanding a Model Class Expanding a model class is done by appending one or more components. The mechanism for connecting components is the following: Some of the time−invariantparameters or constants in a submodel are replaced by time−variable signals produced by other submodels placed upstream. Secondly, the place(s) in the target component(s) at which to connect the new source component’s output signals are defined already at the creation of the source component. Technically, this is done by giving the output signal of a source component the same name as the parameter it is to replace, when and if the source component is activated. The rationale for this construction is that it allows an intuitively appealing way of building a model. The user starts by hypothesizing the crudest model class that still makes sense (called the “root model class”), where all unknown quantities that may or may not be important are replaced by constants or parameters. Maybe that is enough, if input data contains little stimulus, or output data is much contaminated, and therefore will not allow the calibration of a better model. (One may even start with the simplest conceivable root model class y(k) = c + σ w y(k) , in case one would suspect that the experiment data may actually be quite useless.) In order to put the first hypothesis to test − that parameter variations are negligible − the model designer must conceive an explanation for the opposite event − that they do vary significantly − and describe the hypothetical source of the variation. Since it is likely that there are several parameters whose time invariance may be suspected a priori, MoCaVa provides for several alternative hypotheses to be tried out, each one in turn. It is also possible to try several alternative hypotheses simultaneously, or in combinations, although a need for the last option is less obvious. The new submodels normally contain new unknown quantities, that are first approximated by parameters, and then (possibly) need replacement by further submodels. Thus the refining proceeds until the model class becomes as complex as data allows, but not further. The model class grows like a tree, pruned and cultivated to satisfy the evidence of experiment data, but also sculptured according to the gardener’s preconception of what the tree ought to look like. The following are some consequences of the construction: : A component is not basically connected to another component, but to a parameter or constant. This means that if one would draw a block diagram of the system, then i) some of its output signals may connect to targets in several other components, if they share parameters, ii) a component may output several signals to the same or different components, iii) a component may receive signals from several source components. Hence, even if the model class in some respects grows like a tree, a block−diagram representation of it will not be a tree. It will more resemble a river system with tributaries, bifurcations and deltas. The subject of automatically drawing a block−diagram representation from component specifications will be treated in a separate section. : Information may be transferred between components also through the state variables, which may be shared. This means that unlike through the unidirectional signal channels, this information will allow feedback (upstream) in the partially ordered component set. However, since this information may only be output through the state derivatives, and consequently must first pass the integrator before it is input to another component, the construction will prevent a unintended creation of ‘algebraic loops’ (which is the point of the restriction). Feedback loops may of course also be modelled within components, but must then be resolved by the user to allow a description by assignment statements.

30

Practical Grey−box Process Identification

: In spite of this, MoCaVa3 allows direct feedback over components at the expense

of having to deal with algebraic loops. In such cases MoCaVa3 treats systems containing algebraic loops as ‘stiff differential equations’ with some very fast time constants (See Section 5.1 for an example). : The specifications of each component are independent of whether they will have connections to source components or not. Connecting a source component will need only an ‘activate’ decision, and requires no modification to the target component(s) it is connected to. This makes it possible to create a component once and for all and place it in a library. However, since connection is done by replacing a parameter or a constant in the target component, the latter must have a point to connect to. If there is no natural parameter to replace, the user must create one or more ‘stubs’, for instance in the form of zero constants to be added, or unit constants to be multiplied with, at places where he or she suspects a priori that a refinement might possibly be needed. This means that to the body of prior knowledge, exploited when writing equations for the component, belongs also the knowledge of where those equations are uncertain! Additive stubs are convenient means to prepare for a possible modification of a deterministic model with stochastic disturbances. Replacing multiplicative stubs with disturbances is a way to investigate whether nominally constant parameters are actually constant, for instance, the composition of the raw material fed into a process. : The component(s) defining the ‘root’ model class must always be active. This means that it is not possible to test whether the root model class is already unnecessarily complex. If one would want to try also a different root model class, this requires a new calibration session. Afterwards, it will be possible to compare the two models growing from the two root model classes. A feasible alternative would be to create a rudimentary root model and grow two ‘trunks’ from that. None of those consequences are serious obstacles to the convenient handling of a large number of alternatives. Denote by p i the array of parameters vectors in component #i, and let p i = (p 1,.. ., p i). Denote the other arguments in similar ways, except that x i = (x z1,.. ., x zi). Then the generic four−box component will be Environment: dx vi(t) dt = G vi[x vi(t), w i(τ), p i] v i(t) = Z vi[z vi(t), p i], t ∈ [t τ, t τ+1)

(2.8) (2.9)

Actuator: dx ui(t) dt = G ui[x ui(t), u d(τ + 1), p i] u i(t) = Z ui[x ui(t), u d(τ), p i], t ∈ [t τ, t τ+1)

(2.10) (2.11)

Process proper: dx zi(t) dt = G zi[x i(t), v i(t), u i(t), t, p i] z i(t) = Z zi[x i(t), v i(t), u i(t), t, p i] s i(t) = S zi[x i(t), v i(t), u i(t), t, p i], t ∈ [t τ, t τ+1) where s i ⊂ p i−1

(2.12) (2.13) (2.14)

Sensor: y i(k) = Z yi[z i(t k), v i(t k), u i(t k), w yi(k), p i]

(2.15)

2 The MoCaVa solution

31

The signal output s i must be a subset of the parameter set p i−1 in downstream components. Remark 2.12. Connections are restricted to the process proper in order to keep things simple. It would have been feasible also to allow connections between the other blocks. The form of the four−block submodel component primarily suits the modelling of individual units in a multi−unit production system. It is also general enough to allow the modelling of particular physical phenomena, as well as control equipment, even if not all four blocks will be needed in all cases. However, the motivation for the particular way of connecting components may appear to suit better to the second use of the component, that of refining a unit model by increasingly more detailed descriptions. This raises the question of how the models of units are to be connected. The answer is “by the same mechanism”. The motivation, however, is different: The mechanism is particularly efficient for modularizing a model when its structure is uncertain. Once the library has been provided with sufficient components, parts of models can be easily refined or replaced with an alternative hypothesis (by clicking on a menu). Even if the input flows from an upstream unit or the signals from control equipment are strongly variable, they have to be defined tentatively as “parameters” at the creation of the component(s) modelling the unit. When all the preceding units have also been defined, and connected, the input parameters will automatically become the output of the component(s) modelling the source unit(s), and no harm is done by originally calling them “parameters”. (Process engineers do not generally assume that “parameters” are constant, like system identifiers tend to do.) Now, even if one would like to model the whole series of units that constitute the production process, available data may not allow one to do that. For instance, it may be that the effects of what happens dynamically in the early units in the plant are too much filtered by the following storages and units to be possible to detect in the final response data. The same effect is caused by control equipment. In that case the output of a number of the upstream units may simply be replaced by constant parameters, and should therefore be deactivated in order to simplify the model. Secondly, even if the model of a source unit will never have to be deactivated, it may have to be replaced by another model. Placing the models of the units in separate components (instead of packing both a source and its target unit in the same component), will avoid duplication of equations. Generally, the higher the degree of modularization the easier to modify. Remark 2.13. A third motivation is that it facilitates debugging of large models: Start by running the root model only (and hence with constant parameter input). Even if its input would vary in normal operation, the test may reveal the presence of a ‘bug’ (for instance due to instability or a scale that is way off). Bugs are clearly easier to find in small models. Do the same when the next component is added. In this way the whole of a complex model will be debugged stepwise, and in each step one would know roughly where to look for the bug.

2.2 The Modelling Shell The purpose of the ‘modelling shell’ (ModKit) is to supply the user with some tools to create components of the form described above. This means no less than finding a ‘translator’ from the user’s reference frame to the form accepted by IdKit. As argued

32

Practical Grey−box Process Identification

above, it may be necessary to have different user interfaces for different branches of technology. The type of models used in SimulinkX are generated by connecting ‘boxes’ graphically, and specifying the contents of each box. This user interface suits control engineers. Since there is an obvious cause−and−effect relationship between the input and output of the boxes, this would also suit IdKit. However, a similar interface would be less suited to describing the type of connections between units in a production process, which is the purpose of the MoCaVa user’s shell. The dilemma may be expressed (somewhat unscientifically) like this: Control engineers do the connection of components into a system much like the programming of old−fashioned analog computers, by connecting the output signals from one component to the input terminals of other components. This suits also digital computers: Input variables to a subroutine cause output variables to change (according to an algorithm), which become the input of the next subroutine. Control engineers envisage their systems as based on signals. And there is an obvious causality between input and output. Process engineers envisage their processes as based on flows: Output flows (of mass or energy) from one unit become input flows to other blocks. However, flows have several properties, and it is not always that all properties of an output flow are caused by the corresponding properties of the input flows. Causality might be reversed, like in the following simple example: Example: Two mixing tanks in tandem (Figure 2.3): The three flows in and out of the tanks have two properties, flow rate f and concentration c. The concentrations are determined by the flow rates, which are determined by the pump speeds. Hence the flow rates are all input signals, in spite of the fact that two of them are properties of output flows. Process oriented graph of two tanks in tandem c0

c1

c2

f0

f1

f2

Equivalent graph for simulation purposes c1 c0 f1 f0 f1

c2

f2 Figure 2.3. Illustrating different graphic representations of the same model

The lower structure has two drawbacks: i) It is more complicated, and ii) it does not allow an object−oriented description of the flows. Instead one will have to split the two attributes of the same flow into two signals to accommodate for the fact that they have to enter the signal−oriented simulation blocks in different ways. The example demonstrates that there is a basic problem in displaying graphically a system of models of connected physical objects: In general, the input and output of the physical objects and their causal submodels do not correspond!

2 The MoCaVa solution

33

Remark 2.14. The difference is recognized in the theory of bond graphs, which is another way to create and visualize system models (Margolis, 1992). But bond graphs do not look like ordinary process engineer’s graphs either. It is also the reason for defining object−oriented modelling languages like ModelicaX (Tiller, 2001). In conclusion, a process engineer is used to seeing the upper graph. A control engineer is used to the lower graph. The software (IdKit) is based on functions implementing the lower graph. In addition, the three different reasons for modularizing a model, namely to allow convenient descriptions of process units, refinement or units, and control of units suggests several types of components. And there is some translation to do. It is done by means of the new concept of a “cell”, which is the element by which the user builds the structures. It is a slight modification of the relations defining a component; two input variables “feed” and “control” have been augmented to connect components. The cell may be represented graphically as in Figure 2.4.

Sensor output

Cell

SENSOR Response

Signal

PROCESS Parameters

Feed State STARTUP

Disturbance ENVIRONMENT Stimulus ACTUATOR

Data

Control

Figure 2.4. Illustrating the generic “cell” for building models of industrial production processes. A “signal” may connect to any of the three points indicated by dots.

Remark 2.15. The “cells” play the role of building blocks for the ‘body’ of the model. They are all complete and self−contained, have necessary connectors to the environment, and are able to ‘live their own lives’ (= be simulated) either as individual units or in interaction with other cells. They are also constructed to find the right other cells to connect to automatically. This means that a user trying out various stages of ‘evolution’ of the model body may tentatively add or remove a cell simply by activating or deactivating it, and without also having to specify where to connect it. Instead, the information has to be provided once, when the cell is built. Even if the cell may be represented graphically, the user input is not graphic. Instead, the cell is defined by classifying variables and specifying various attributes and interrelations, as follows.

34

Practical Grey−box Process Identification

2.2.1 Argument Relations and Attributes The prior information needed to define a component consists of argument relations (assignment statements) and argument attributes. The term “argument” will be used for variables, as well as for constants and parameters, where “parameters” may either stay constant or vary, depending on whether there is a connected source component or not. 2.2.1.1 Relations Between Arguments Argument relations (equations) are entered as series of assignment statements using a subset of MATLABX statements. The set is restricted in two ways: : It contains only elementary algebraic, for, if, and else statements and such elementary transcendental functions (sin, cos, tan, asin, acos, atan, exp, log, log10, sqrt) that are both in the standard C and M libraries. : The statements may involve only scalar arguments or explicitly indexed vector elements, for instance inletpressure(i). Vectors with fixed dimensions can be manipulated using for statements. There is a single addition to the syntax of MATLABX statements, viz. a time−differentiation operator D to be placed in front of a state variable. (See Section 4.4.2 for more detail.) There are several reasons behind the much restricted facilities for writing functions, when compared to what is offered by MATLABX statements: : One restriction originates in two somewhat conflicting strategic decisions in the design of MoCaVa: On one hand, to use MATLABX as platform and M−statements for entering user specifications (because MATLABX is believed to be more generally known to engineers), and on the other hand to use C for the time−critical calculations (because the execution of M−files is not fast enough in other than simple cases). It follows that M−statements have to be translated into C−statements automatically. The rudimentary translator in MoCaVa3 is therefore one bottleneck narrowing the set of models that can be handled. Neither can MoCaVa3 handle the translation into C of all possible variable types in MATLABX (for instance, C− structures are different from M−structures). Only scalars and vectors are translated. : A second, and more limiting restriction, originates in difficulties with generating predictors and fitting parameters, both tasks that are particular to grey−box identification: Both the predictor derivation and the loss evaluation use numerical differentiation, and to that is added various other approximations designed to gain speed, some of which also generate numerical errors. It follows in particular, that when the model residuals e(k|θ) are evaluated with slightly displaced parameter values θ, then the very long sequences of operations evaluating e(k|θ) must be exactly the same for each value of θ. From this follows that iterative loops cannot be allowed in the evaluation of the predictor (because they might stop after different numbers of iterations, however small the size of the displacement in θ). This means that loops cannot be allowed in the model statements, or in any function that statements may call. And from this follows that while statements, for instance, must be excluded. In all places in the complex processing of the model must loops either be avoided or controlled to a common number of iterations for all displacements of θ. Remark 2.16. The translation problems were avoided in an earlier all−C version of MoCaVa (used mainly within the department for the case studies). The user must

2 The MoCaVa solution

35

have a knowledge of how to write a C−function, but will then be able to exploit the scope of the C language freely. An ‘advanced’ modelling option is clearly a possibility in future versions of MoCaVa. Remark 2.17. Due to the ‘multi−shell’architecture of IdKit, where the user’s model is in the innermost layer, the strength of the ‘vectorization’ option in MATLABX cannot be exploited to advantage. The bulk of IdKit is a set of nested for loops with calls to subroutines. Since the model is nonlinear and recursive, it is not obvious how the operations are to be paralleled. Remark 2.18. The possibilities of using formula manipulation algorithms to replace some of the numerical differentiations in the derivation of the predictor have been investigated by Sørlie (1995c,1996a−c). It appears that formula manipulation will be efficient in only part of the predictor. Remark 2.19. A third argument for limiting the scope of the models is strategic: MATLABX will no doubt develop the scope of its M−language. If MoCaVa would have the ambition to cover the same scope, its M−to−Ctranslator would have to have the resources to follow the development, which is unlikely. For much the same reason, the possiblities of using Mex−functions or generic M−to−C translators for solving some of the translation problems have not been considered seriously. The bottom line is that it is very uncertain how much development of the modelling for simulation purposes, that can be handled also by the more demanding task of identification. (What about general hybrid systems?) Better then to restrict to a class MoCaVa has control over. 2.2.1.2 Sources of Input Arguments The IdKit model set (in equations 2.8−15) uses the following classes of arguments appearing in a model of the process proper (other arguments participate in the data and environment interfaces): : Input: state variable x, stimulus u, disturbance v, parameter p, constant c, time t. . : Output: state derivative x, response z, and signal s. The classification decides how the arguments are to be treated in the calibration process. In the modelling process (based on the “cell” in Figure 2.4) the user encounters the following argument classes instead: : Input: Control r, Feed q, Disturbance v, Parameter p, Constant c, and Time t. : Output: Response z. Their classification must be based on their meanings in the object being modelled, and belongs to the prior knowledge. The labels are set using the HelveticaNarrow fonts, in order to emphasize that they will appear in user communication windows. The motives for the choice of information asked from the user are the following: Since the connections of components into models may have to be changed frequently, this should be particularly easy to do. Connection of a component in MoCaVa is therefore done simply by activating it. The basis for this is prepared at the component definition by giving the signal output the same names as the parameters or constants they are to replace, if activated. Thus, the “signal” classification is done automatically. Also . the classes of “state” x and “state derivative” x are determined automatically from the names of the variables: A variable with a D in front of it is a state derivative, if there is also a variable with the same name. Secondly, the response of the model depends on how the stimulus u was generated, in particular on how the continuous signal behaves between the discrete time instants.

36

Practical Grey−box Process Identification

It is the user’s responsibility to provide at least partial information on that point. In industrial production processes there may be two kinds of stimulus: : Control: Actuator response to stepwise and known set point changes. : Feed: Input from an external known source. ”Known” means that there is a model for the source, normally dependent on filed input data. The third kind of input is : Disturbance: Input from an external unknown source. In all cases the user must enter some information about the source model. If the main source of information about a Feed or Control input is a data sequence, it may be possible to use one of the standard library models for interpolation between the sample points. The user is asked to select from a menu of interpolation formulas, or else indicate that the input is to be provided by another component. In case of Disturbance input, the only available source models are a number of stochastic library models. Remark 2.20. If the user would like to create an own stochastic model, this can be done by classifying the disturbance as Feed, then mark its source as User model, and write a source component having one of the standard ‘environment models’ as input. For instance, a positive disturbance d is generated by classifying d as Feed, indicating that d is to be defined by another component, writing the latter d = exp(v), and classifying v as Disturbance. An amplitude−limited disturbance may be created in a similar way, for instance using an atan function. The Parameter, Constant, Time, and Response classifications are the same as in the IdKit model: : Parameters may be either fitted, unchanged, or replaced by signals from other source components. : Constants may be unchanged or replaced by signals, but cannot be fitted. : Responses are all output variables of interest (e.g., for plotting) regardless of whether or not they have sensors attached to them. Conceptually, the classification should be easy to do for one who has written the statements. Technically, it is done by clicking on the appropriate classification for each entry in the displayed list of arguments. The re−classification into IdKit arguments is done automatically according to Table 2.1. Table 2.1. Relations between user and IdKit arguments

Classified as

Data assigned Active source Treated as

Feed Feed Feed Control Control Control Disturbance Parameter Parameter Constant Constant

no yes no no yes no

no no yes no no yes no yes no yes

parameter stimulus signal parameter stimulus signal disturbance parameter signal constant signal

2 The MoCaVa solution

37

2.2.1.3 Other Argument Attributes Arguments are defined automatically when they are entered, as in M−statements, and may have arbitrary names. However the arguments defined in this way also have a number of attributes that may be specified by the user, in case there is some prior knowledge contradicting the default values: : Variables associated with experiment data must be given references to their counterparts in the data file. : Most variables need scales, telling MoCaVa what variation to expect. They are needed for numerical differentiation and for setting the default scales when plotting a variable and some dependent variables. Scales are not required for Constants. However, they are required for Parameters, for the purpose of numerical differentiation. The values of scales are not critical. However, without scales it would not be possible to write equations in standard units (in order to avoid hazardous units conversions in components using mixed units). The ranges of the variables would vary too much for convenience. For instance, the thickness variation of the paper in a roll would vanish in comparison with its length. : Nominal values are required for Parameters and Constants. For Parameters they function as start values in a possible first fitting. : Ranges are optional, and most commonly used for such parameters that are known to be positive, and where a negative value could be expected to give low−levelrun− time errors. Other bounded parameters measure fractions of some variables values, and should therefore be confined to the range (0,1). : Scales, nominal values, and ranges are specified by editing the default values in a form displayed on the screen. Scales and nominal values may also be specified implicitly by entering an alphanumeric label. The option is necessary when the argument is a vector, and the nominal values of its elements differ. It is also convenient, when several arguments share scale or nominal value. Also arguments in different components may share scales or nominal values. The value of an implicit attribute must be entered in the first component it is introduced. Remark 2.21. Deactivating a component that defines an implicit attribute that is also used by other, active components gives an error message. The only way to rectify this is to rename the attribute in the first active component and enter its numerical value again. This is not entirely satisfactory, since it means that components are not fully independent of the model class created when connecting them. The problem is similar to that caused by shared state variables, although in this case it is clearly against logic to deactivate a component that would otherwise have computed the value of a state variable used by another component. All combinations of active components are not feasible also for other reasons (for instance all target components of active components must also be active) and it is necessary to exercise ones common sense also when selecting a combination. Expanding the class may be done with much less caution than changing the class in other ways, if arguments are shared. 2.2.2 Graphic Representations The components in MoCaVa are defined to include also the information needed to establish any of the possible connection patterns. The actual pattern is created when the participating components are activated. Thus, the system is defined without explicit reference to a graph. However, in order to give some feedback to the model maker MoCaVa generates a graph automatically from the component specifications and the activity index. The main motivation for this, as it would seem, ‘backwards’ way of defin-

38

Practical Grey−box Process Identification

ing connections is that, as argued above, this will simplify the connection process for the user. It also allows the construction of different types of graphs depending on the user’s preference. In particular, the user may shape the graph to distinguish between the three ways of refining a model, viz. by i) adding a physical unit feeding flows of matter or energy into a target, ii) adding a control unit entering signals to change the response of the target, and iii) adding a model of a physical phenomenon inside the target. Since the graphics generator by default enters Feed input from the right, and Control input from below, a series of units will be displayed as an array of boxes, with boxes representing control equipment appended below. This will make the graph look more like the upper graph in Figure 2.3. A source cell representing an internal refinement will be displayed as a box within the target box. Thus, refinement in several steps may result in ‘Chinese boxes’ with several layers, including subsystems of connected boxes within boxes. This too will be visually informative; a more refined unit will also appear more complex. The purpose of the construction is to facilitate the user’s understanding of how the various components may interact, and to corroborate this with the assumed operations in various parts of the actual production process. The point is that the classification should appeal to intuition, and therefore be quite easy to do in normal cases. If one wants a graphical representation of the model, and many do, then the block diagrams representing the physical object and the model should look alike. And that is particularly important in grey−box identification, since it concerns the possibility of entering prior structural information without misinterpreting its effect. However, the attempt in MoCaVa to satisfy this carries a logical restriction: Not all systems that can be defined as connections of cells can also be described graphically. For instance, a cell that has an output signal connected to a Parameter input, cannot also have another output connected to a Feed input − it is not possible to draw such a graph. Inadmissible classification results in diagnostic messages, and no graph. (It is also possible that there will be a garbled graph, and no message, since MoCaVa3 might not be able to diagnose all cases of inadmissible combinations of input classifications). The user may then try a better classification, or else proceed without a graph, since it is still possible to use the model for identification. Remark 2.22. It follows that the model classes that can be processed by MoCaVa is wider that those that might have been defined by drawing graphs. However, it is difficult to see a practical usefulness of this observation. And, again, it does not mean that MoCaVa would be able to handle any model class defined by SimulinkX. The component specification in MoCaVa accepts only a limited set of M−statements.And it is limited in a way that facilitates prediction and fitting. Remark 2.23. The setup and display of the graph is done by a separate user interface defined in the file NewDrawGraph.m. It may be suppressed by the user. Remark 2.24. A negative consequence of the emphasis on easy connection of cells is that the same cell cannot be used in several places. Each cell is basically an “instant”, i.e., a description of a particular unit or phenomenon, and it should therefore be known to the user what target parameter(s) it is associated with. For instance, models of technical units of the same kind must be copied and then given individual names to its input, output, and state variables. The deviation in design from what is common in simulation software is motivated by the different requirements: In simulation (and in white−box identification) the modelling of the total object should be easy. In grey−box identification it is even more important to be able to change the total model easily.

2 The MoCaVa solution

39

Since it is not obvious how to cater to both needs, MoCaVa puts the emphasis on the second one. Remark 2.25. MoCaVa3 has two options to facilitate reuse of model components: i) A “copy component” option, where the user may copy the equations, but change the names of the external arguments, and ii) allowing function calls of the form outputarguments = libfunction(inputarguments) among the component−defining statements. The functions may be either user defined or standard, as well as static or dynamic. 2.2.2.1 A Simple Example: Cascaded Tanks With the use of cells the graph of the two−tank example will look as in Figures 2.5−2.8 depending on how detailed one wants the display. The graphs are grey−scale images of those displayed by MoCaVa3. In all cases pulp0, pulp1, pulp2 represent the three flows in the upper graph of Figure 2.3. They have two properties flow rate and concentration (of pulp), and are therefore defined as arrays with two elements. The purpose of this is to keep the elements together, which will emphasize in the graph that they belong to the same physical object. Figure 2.5 illustrates a ‘root model’ consisting of the two tanks plus a rudimentary mechanism for supplying tank1 with pulp. The null hypothesis is that the flow rates f0, f1, f2 and the input concentration c0, as well as the start concentrations c10 and c20 are all constant parameters, possibly to be determined by fitting.

Figure 2.5. Graph of the root model of cascaded tanks

The components are defined as follows: tank2: M−Statements: Dc2 = (pulp1(1) * pulp1(2) − f2 * c2)/V2 pulp2(1) = f2 pulp2(2) = c2

Initialization: c2 = c20

Argument classification: pulp2 pulp1 f2 c20 V2

Response Feed Control Parameter Constant

tank1: M−Statements: Dc1 = (pulp0(1) * pulp0(2) − f1 * c1)/V1 pulp1(1) = f1 pulp1(2) = c1

Initialization: c1 = c10

40

Practical Grey−box Process Identification

Variable classification: pulp0 f1 c10 V1

Feed Control Parameter Constant

feed: M−Statements: pulp0(1) = f0 pulp0(2) = c0

Argument classification: f0 c0

Control Parameter

Figure 2.6 shows a slightly more detailed graph, where three rudimentary pump models have been added. The tank2, tank1, and feed components are unchanged. The null hypothesis is that all pumps are perfect (actual output equals reference input).

Figure 2.6. A more detailed graph of the root model

pump0 (similar for pump1 and pump2): M−Statements: f0 = fr0

Argument classification: fr0

Control

The presence of the new components obviously do not change the model’s response. They were added for two reasons: i) To show how graphs using both feed and control input will look, and ii) to create ‘stub’ components for possible refinement, should reference input fr0, fr1, fr2 not be constant and the pumps not be perfect. Figure 2.7 shows the case where the reference input of all flows are entered from a data file. This changes only the specification of input sources of the pump models.

Figure 2.7. The same model with input sources assigned

2 The MoCaVa solution

41

Input source model: fr0 fr1 fr2

Hold Hold Hold

fr0 fr1 fr2

fd0 fd1 fd2

Input data assignment:

Each pump model has now three arguments for speed. The distinction between them is the following: fd0 is the name of the recorded speed of pump0 in the data file, fr0 is the name of the (stepwise constant) continuous−time reference variable from the Hold function, and f0 is the signal from the pump model into the feed unit. The distinction becomes important whenever the pump or DAC conversion is not perfect. Figure 2.8 shows the case where one would want to emphasize that the modelling of the pumps are to be regarded as a refinement of the physical units they belong to. The following has been changed: Argument classification: f2 f1 f0

Parameter Parameter Parameter

Figure 2.8. The same model, displayed differently

Notice that the model structures corresponding to the graphs in 2.7 and 2.8 are the same, only the way the graphs are laid out differ. In contrast, the graphs in 2.5 and 2.6 correspond to slightly different models; 2.6 has three argument more, even if the models are equivalent in the sense that they have the same responses.

2.3 Prior Knowledge Grey−box identification hinges on prior knowledge as well as on data, and is necessarily interactive. And any interactive program is necessarily restrictive concerning the kind of prior knowledge it can receive. MoCaVa expects three types of prior information, viz. facts, hypotheses, and credibility ranking. The facts are values of constants and well established natural laws. Facts and hypotheses involve attributes of arguments as well as relations between them. They are used directly by the computer to construct the component library. The credibility ranking is used mainly by the human operator to determine in which combinations and in which order to test the various hypotheses. The computer uses that to build a structure from the selected components.

42

Practical Grey−box Process Identification

Remark 2.26: The building of a model resembles an evolutionary process in the sense that only successful systems survive. However, a difference is that the ‘mutations’ are not entirely random, but partially guided by the model maker. In this process the credibility ranking plays a key role in reducing the large number of unsuccessful trials that nature can afford but an engineer cannot. 2.3.1 Hypotheses The hypotheses determine structural and argument attributes. They state how arguments are related (hypothetically), and what one may know or guess about their likely values. 2.3.1.1 Structural Attributes Structural attributes are relations between defined arguments, argument class and dimension, and interface specifications to data and environment. Relations between arguments are entered as assignment statements (see Section 2.2.1). They are used by MoCaVa to create C source files for inclusion by the linker in the automatic generation of executable tasks for simulation and loss evaluation. The argument classes have been defined above. The classes are used, together with the argument dimensions, to build an interface between the user−named arguments and the generic identification tool box IdKit. The interface specifications apply to arguments classified as Response, Feed, Control, or Disturbance: All except Control require specification of whether a sensor is attached or not. The Feed and Control classifications require specification of the source of the input, and if that is a data file, also what standard routine to use for conversion from discrete−time input data to continuous−time stimulus. This includes interpolation between the sampling times, as well as possible filtering of contaminated data. The Disturbance classification requires specification of what standard routine to use for modelling the source of the random disturbance. Remark 2.27. Notice that in addition to the Response output also the Feed and Disturbance input may or may not have sensors attached to them. This allows the modelling of the case of measured random input, as well as the case of ‘input noise’ (see Section 2.3.5). 2.3.1.2 Argument Attributes Argument attributes are scale, nominal value, and range. The scales determine the default layout in plottings, as well as the sizes of small increments used in numeric differentiation. The scales of fitted parameters also have a third effect: They are used by IdKit to put weights on the deviation of an estimated parameter from its origin (see Section 2.4.1.2). The origin is either the nominal value or a previously fitted value. The weights function as soft barriers in order to implement the prior knowledge that parameters should not be much outside the range set by the scale, unless data says otherwise, and so strongly that the weights become overpowered. The ranges set hard boundaries to parameters. They are necessary for such parameters that must be bounded in order to make the model stable, or are input arguments in functions with limited domain of definition (such as sqrt), and that would cause run−time errors otherwise. Explicit ranges apply only to parameters. If necessary, other arguments must be limited in the definition statements, for instance using if statements for hard boundaries (e.g., overflow), or atan for soft boundaries (e.g., saturation).

2 The MoCaVa solution

43

The nominal values are the prior values of constants and such parameters that are not fitted to data. Otherwise they serve as start values in the search. 2.3.2 Credibility Ranking MoCaVa is designed to take into account that prior information is more or less reliable as well as relevant. The design distinguishes between structural uncertainty and parameter uncertainty: A hypothetical relation may or may not hold, and, independent of this, may or may not be significant for the calibration loss. Similarly, the prior (nominal) value of a parameter may or may not be accurate, as well as significant or insignificant. For instance, the most reliable are the facts, such as natural laws and models that build on first principles. Next come well tested heuristic relations between well defined variables, the element of uncertainty being a possible influence from the environment and the range of validity of the models. After that comes a range of relations modelling various hypothetical relations, ranging from, at one end, those based on engineering common sense of what physical phenomena that should be most important, to at the other end, just a hunch that there might well be a relation, although unlikely to be significant. The prior uncertainties affect the testing order, and it is partially the model designer’s responsibility to decide on the testing order (it is partial because several hypotheses may be tried in parallel). Thus, within each hypothetical model class the effects of free parameters are tested first. When the freedom of parameters have been exhausted the class is expanded by augmenting new hypothetical relations. The idea is that if a model designer has some basis to order his or her prior facts and hypotheses after some degree of credibility, at least partially, this can be exploited to reduce the calibration task. Now, the rationales for ordering the structural uncertainties and the argument uncertainties into ‘credibility rankings’ are different. It is reasonable to test the structural hypotheses in the following order: 1) Significant & reliable, 2) Significant & unreliable, 3) Insignificant & reliable, 4) Insignificant & unreliable. In contrast, the parameters are reasonably estimated in the order of 1) Significant & unreliable, 2) Insignificant & unreliable, 3) Significant & reliable, 4) Insignificant & reliable. The recommendation is self−evident as well as vague, and the point of making it here is to emphasize that the degree of accuracy and reliability of prior knowledge is also prior knowledge, and to point out how such knowledge can be used in structuring the model. 2.3.3 Model Classes with Inherent Conservation Law The following is a way to exploit the fact that matter and energy are preserved during transformation. If this conservation law is stated in a separate component, the latter may be retained in all models built by augmenting other components based of less reliable relations. The following is an example of such a construction. 2.3.3.1 Example: Chemical Reactor Models. It is a known fact that the mass fractions of different atoms in the constituents in chemical reactors are preserved during reactions. What is usually less well known are the reaction rates. This suggests that one try model classes of the forms in Figures 2 .9−11. The ‘root model’ contains only the balance equations, where f are the flows of constituents in and out of the reactor, m is a vector of constituents currently in the reactor,

44

Practical Grey−box Process Identification .

m = Cr f out = f in − Cr

.

m f out

r f in

f = (f in, f out) y = f + σw

y

σ

Figure 2.9. Root model with conservation law .

m f out

y

.

m = Cr f out = f in − Cr

r

r = R(m, f in, p)

f in

f = (f in, f out)

y = f + σw

m p

σ

Figure 2.10. Augmenting a reaction−rate model

and r is a vector of reaction rates. The matrix C is constant and known (provided one knows what reactions are going on in the reactor). The flows in and out of the reactor are measured, and a sensor model adds a white noise with rms−values σ. The first hypothesis is that reaction rates are constant. Start therefore by fitting y to data in order to estimate as many of the reaction rates in r as data permits. This is done by freeing one more parameter for each fitting task, either selected a priori, or else determined by trying several alternatives in parallel. In order to test the null hypothesis that reactions are in steady−state (r is constant), it is necessary to expand the model with a component containing a hypothesis of what might cause r to vary. Let r = R(f in, m, p)be a relation modelling this, i.e., the reaction rates may depend on the inflow, the concentrations in the reactor, and the known or unknown parameters p (Figure 2.10). It is conceivable that this will have to be expanded further, for instance by a temperature model, but the point is that all expansions will conserve the balance of matter. It may also be that the reactions are too complex for modelling, for instance in combustion processes. In such a case one may have to rely on a black−box Disturbance model for the expansion, in order to test the null hypothesis that the reactions are steady− state processes. The simplest black−box model with no known input is a Brownian . motion r = λw (Figure 2.11), but a number of input dependent models are also conceivable. 2.3.4 Modelling ‘Actuators’ The generic actuator model in Equations 2.3 and 2.4: dx u(t) dt = G u[x u(t),u d(τ), u d(τ + 1), p], u(t) = Zu[x u(t), u d(τ), p], t ∈ [t τ, t τ+1) defines an interpolation function between discrete−time data u d(τ) and u d(τ + 1). Hence, the model depends on the process that causes the input u(t) to vary in between, and must be determined a priori. The physical conditions are different for Control and Feed input:

2 The MoCaVa solution .

.

v

.

m f out

y

v

v = λw r=v

r

45

λ

.

m = Cr

f out = f in − Cr

f in

f = (f in, f out)

y = f + σw

σ

Figure 2.11. Augmenting a ‘black−box’ reaction−rate model

2.3.4.1 Control Input The typical case is digital control; the input u(t) is constant between the discrete points t τ, and the only thing to decide is whether it should be continuous to the right, u(t) = u d(τ), or to the left, u(t) = u d(τ + 1). Now, a natural sequence of events in digital control is the following: First, the control routine receives measurements y(t τ), computes a correction u d(τ), and sends it to the actuator. Then the logging routine sends the record y(t τ),u d(τ) to the file. This suggests continuity to the right (’hold’), i.e., u(t) = u d(τ). Remark 2.28. Notice that if the response to control is immediate, for instance y(t) = g u(t), this holds for t τ < t < t τ+1, but not for t = t τ. No control loop can have zero response time in both the forward and the back paths. A conceivable alternative to the sequence of events may occur if there are separated and un−synchronized routines for data logging and control: First, the logging routine sends the record y(t τ),u(t τ) to the file. Then the control routine retrieves the measurement y(t τ), computes the next set point u(t τ+1), and sends it to the actuator. This would suggest continuity to the left, u(t) = u d(τ + 1). In the worst case the sequencing may even change with time, depending on the priority rules in the process− control system. However, if the routines do not execute during a common cycle, then it is not likely that the data logging will occur in the narrow interval, where the independent control routine will execute, and u(t) ≠ u d(τ). Hence, even then u(t) = u d(τ) is to be preferred. If the actuator does not have a negligible response time, its model must be modified. MoCaVa offers a number of alternatives to model this case. 2.3.4.2 Feed Input In the typical case nothing is known about the source of the input in addition to the data sequence, which may also include measurement errors. (If more is known, it should be described in an augmented component). The interpolation will obviously have to be an approximation, and the choice of interpolation rule depends on the effect on the model response of the approximation error. When the object responds fast to input (compared to the time quantum), an instantaneous model will often be adequate, the only value of interest is u(t τ), and it is irrelevant what happens between the discrete times. Hence, the simplest assumption of a constant u(t) will do, but this time one will have to decide on two items: i) continuity

46

Practical Grey−box Process Identification

to the right or to the left, and ii) how to estimate the ‘true’ input. Leaving out the second problem for the moment, the deciding point for the first item is that in a noise−free case one would like to have u(t τ) = u d(τ), and this implies ‘hold’ again. The estimation problem remains however. Also when the object responds slowly it is often irrelevant what happens between the discrete times. However, if the ‘true’ input would also change slowly, a ‘hold’ model would generate a stair−case function which would cause a systematic delay. In such cases it seems better to interpolate linearly between the discrete points (if no more is known about the origin of the input data). The actuator model for this case will be dx u(t) dt = [u d(τ + 1) − u d(τ)] h u(t) = xu(t), t ∈ [t τ, t τ+1)

(2.16) (2.17)

However, this requires an additional state variable, which may become costly, if the input are many. The remaining case is that when the response of the object is such that it does matter what happens with the input between sampling points. The remaining option is then to use ‘black box’ models for interpolation. MoCaVa3 has only one model that can be used for the purpose: an approximative delay function with unknown delay time. When input data are noisy enough for this to be significant, there is usually not much point in asking what happens between the sampling intervals, and again a ‘hold’ function will be the answer. It follows also that if low−pass filtering of the input is the answer, the filter should be digital, i.e., the hybrid actuator will consist of a digital filter followed by a ‘hold’ function. However, the question of finding an estimate is much more difficult to answer, and it is not even clear that the answer is filtering. It will be the topic of the next section. Remark 2.29: The library routines available in MoCaVa3 for interpolation of Control input and interpolation and filtering of Feed input are defined in Section 2.3.6 Interpolators and Filters. 2.3.5 Modelling ‘Input Noise’ The following somewhat lengthy discussion will reflect on some of the intricacy of the problem of modelling unknown input to industrial processes. Some points may be repeated in several places using other words, and that is because I believe in the salutary effect of redundancy when transmitting through as imprecise a channel as one using natural language. However, using mathematics will not help to clarify things either, since the problem lies in its interface to the physical world. Theoretically, MoCaVa requires that the input to the ‘actuator’ be constant between sampling points, and known exactly. The requirement is typically satisfied when the input is actually generated by a computer and entered as ‘set points’ to the actuator. More often, however, the input to the process is known only partially, by sampling a continuous−time input originating in another process, not to be modelled. This creates a problem of reconstructing the continuous stimulus from discrete data, which, in addition, may be recorded with measurement errors. The two classifications of Control and Feed distinguish between the cases. The difficult case is that when the input is not known exactly, but measured with errors. This is known as “the problem of input noise” and is fundamental in identification from ‘historical’ or ‘operating data’, rather than from ‘controlled experiments’ (Bohlin, 1987). The actual input are unknown, and this, in turn, requires additional

2 The MoCaVa solution

47

models of the processes that caused the actual input to vary. If these processes are known and their set points have been recorded, this is a case of controlled experiment, and the set points are the input (known exactly). If the input processes are not known, then their models are part of the system to be identified, but the input (set points) to the whole model of object and input process are still known. However, if no set points have been recorded, it remains only the possibility of providing, no−input models for the sources of their variation, and if the latter are unknown too, it remains the possibility of hypothesizing a black−box model for the input behavior. The same holds for other unknown input, not directly associated with measurements, but whose effects will pass through the process proper, before any measured output is possibly responding. In order to formulate and solve the problem of ‘input noise’ it is necessary to assume something about the source of the ‘true’ input. The following are some feasible assumptions: : The input is band−limited: If the input does not contain frequencies above the Nyquist frequency 1/2h, then according to Shannon’s sampling theorem it is theoretically feasible to reconstruct the continuous input exactly from the sampled (Kuo, 1992). This is an intuitively rather surprising conclusion, but may on the other hand also be interpreted as an indication that the assumption is unlikely to hold in practice. The option is not supported in MoCaVa. : The input follows one of a number of interpolation formulas. If the formulas contain unknown parameters, they will be able to shape various behavior patterns between the sampling points (including delayed action), but the assumption is still that the pattern will be unchanged throughout the sample. A more severe limitation is that this does not solve the problem of ‘input noise’, since the continuous input and the discrete data will always agree at the sampling points, noise or no noise. However, MoCaVa supports a small number of interpolation formulas for low− noise cases. : The input is stochastic with a given structure: This may not seem to be a quite satisfactory assumption either, since the input is probably generated by a process that does not behave as any of the stochastic models available. However, assuming no further knowledge of the source there is no option left than to assume a black−box model with no input, either as a smooth function of time, or a stochastic model. When appraising the a priori credibility of the various assumptions, it would appear that one would be as credible or dubious as the other. But the advantage of the stochastic assumption is that it offers a way to deal with the problem of measurement errors. A theoretically correct way of dealing with the problem of ‘input noise’ (assuming a stochastic input) is to model the variables in agreement with what they really are, i.e., the ‘true’ input as unknown input, and the data as the known output of a sampling sensor; cases without exactly known input have only output data: dx v(t)dt = G v[x v(t), w(τ), p] v(t) = Z v[x v(t), p] y(k) = Zy[v(t k), w(k), p]

(2.18) (2.19) (2.20)

The quality that makes this work, in spite of the dubious assumptions behind, is the versatility of the stochastic model. The calibration includes an ‘inversion’ operation on the model; given output data, it does in effect estimate the actual unknown input, in addition to the unknown parameters. In essence, the predictor generated from it will function as an optimal low−pass filter for the measurements, and the estimated stimulus will follow the actual measurements as well as the estimated bandwidth of the stim-

48

Practical Grey−box Process Identification

ulus and the noise level will allow. And that is so, independent of what process actually caused the ‘true’ input. Thus, there are three kinds of unknown input (”disturbances”) and one may have to provide descriptions for all: : Measurement errors (added to the output of the object) : Measured input (unknown input to be included in the object model, in addition to known input) : Disturbance input (other unknown input to the object, or generated by an unmodelled process within the object). The difference between the second and third kind of input is that one but not the other will be available when the model will later be put to use, and none is available for the calibration. Remark 2.30. Notice that even if the intended use of the model does not allow the inclusion of disturbance input (e.g., open−loop prediction), they have still been there when the experiment data were recorded, and may therefore play a role in the calibration process. The idea is to model and calibrate the whole system of disturbance input, measurement process, and the process proper, but keep only the latter for the open− loop prediction purpose. Remark 2.31. In closed−loop prediction, also the disturbance models play a role (they are important when deriving a predictor), in addition to the model of the process proper. The difference is that in closed−loop prediction, measurements of both input and output variables are available, in addition to the reference input available to an open−loop predictor. The closed−loop prediction will generally be able to use these response values to estimate some of the unknown input, and thus improve the prediction. The improvement does of course depend on the prediction horizon, which in practice is determined by sampling rate and transport and measurement delays. 2.3.5.1 Time−saving Shortcuts The theoretically correct modelling has a practical drawback: Output variables cost much more computing than input variables. It may therefore be necessary to compromise. The observation that the predictors function as input filters gives a clue to how to do that: Replace the input with low−pass filtered values of the measurements. If the bandwidth of the input filter is unknown, then include an unknown parameter with those fitted to data. This will reduce the number of output and increase the number of input. If one would want more security (at the cost of more computing) there is also the possibility of combining an input filter with a measurement of its output. In this way the same data will be used twice: Once as input data for creating an estimate of the unknown input, and once again as output data for fitting the input filter to data. This double use of the same data is not in accordance with any theory, but intuitively plausible. Estimating data by filtering input data combined with feedback from measurements should not reasonably be inferior to estimating it only via feedback from measurements. The alternative replaces a stochastic input model with a deterministic one, which is less costly. It is also possible to make a further shortcut by first determining optimal filters for estimating individual input, by fitting to their measurements, and without involving any of the process model. This would be a loss of information only in the unlikely event that other output would hold more information about the input than the direct measurement of it. Once the filters have been fitted, the calibration may proceed based only on the filtered input, and without the costly ‘double’ use of the input data. In summary, the following are feasible ways to model a noisy input in MoCaVa:

2 The MoCaVa solution

49

: Classify as Disturbance, and assign a sensor. Fit source model and input sequence to output and input data: Theoretically correct, but costly.

: Classify as Feed and assign a data source. Fit source model to output data: Faster, but more hazardous.

: Classify as Feed and assign both a data source and a sensor. Fit source model to

output and input data: Intuitively better and less costly than the theoretically correct alternative. : Classify as Feed and assign both a data source and a sensor. Fit source model to input data only: It is the fastest alternative when the model is large. However, the loss of accuracy may or may not be negligible depending on the process. 2.3.6 Standard I/O Interface Models MoCaVa3 supports the following input interpolators, filters, and disturbance generators. Formulas and code are given in Section A.8. 2.3.6.1 Interpolators Interpolators are applicable when measurement errors are small: : Hold: This is a stepwise constant function continuous to the right. It describes an error−free actuator with negligible response time. It is also suitable for objects with responses that are fast enough to be described by instantaneous (algebraic) models. : Linear: A linear interpolation is suitable when the source of the measured input is unknown and slow−changing. : FirstOrder: It describes a case of digital control, where the actuator’s response time is significant. The time constant may be fitted. : SecOrder: It describes a case of digital control, where the actuator may overshoot. Time constant and overshoot may be fitted. : Delay: This function makes an exact time delay for ramp input. For other input it approximates a time delay, and should therefore be applicable under the same circumstances as the linear interpolator. It will be possible to fit a delay that may range over several time quanta, as well one that is a fraction of the quantum. Only Hold and Linear are true ‘interpolators’ in the sense that their output agree with their input at the sampling points. The other may lag behind. 2.3.6.2 Filters Filters are applicable to contaminated data, were it is less important what happens between sampling points. : LPFilter: This linear digital low−pass filter may be used when the ‘true’ input can be expected to change slowly. It is possible to fit the bandwidth to data. : NLFilter: This is a nonlinear filter for a case when the ‘true’ input normally changes slowly, but can be expected also to take occasional large steps. Linear filters with the narrow bandwidths required to suppress noise do not react with sufficient speed to step changes. The nonlinear filter has a gain that varies with the error amplitude, and thus responds fast to changes that are above a soft threshold. The latter may be fitted to the average noise level, if unknown. The standard models are admissible for different input classes: Control input may use Hold, FirstOrder, and SecOrder. They all assume a step input with no error. Feed input may use Linear, Delay, LPFilter, NLFilter, and Hold. The last alternativ is allowed, since it is less costly, and may be good enough in many cases.

50

Practical Grey−box Process Identification

Remark 2.32. The combination of assigning a sensor to Feed input and selecting one of the input models Linear and Delay is not admissible. Since the Linear interpolator agrees with the data at the sample point, there is no point in trying to fit the interpolator output to data. Neither is there a point in fitting the output of Delay; that would always yield a zero delay estimate. Remark 2.33: Both noise−suppressing filters are purely discrete−time,and produce step−wise constant output. When data are noisy, there is not much point in assuming some more sophisticated interpolation between end points that are uncertain anyhow. It also saves the overhead of continuous−time filter states that would have been required otherwise. Continuous−time states (used in FirstOrder, SecOrder, and Linear) are numerically costly, in contrast to the discrete states in the digital filters. Remark 2.34: It is in the nature of shortcuts that they are faster, more risky, and require some knowledge of the ‘geography’. The shortcut of using noise−suppressing filters is no exception. For instance, the filters may not work well for input data that are sampled irregularly or much more sparsely than the time quantum h. In that case MoCaVa computes the u d(τ)−sequencein Equation 2.4 by linear interpolation over the intervals of missing data d u(k), which means that the sequence that is filtered loses some of its character of ‘slow signal plus noise’ that the filter is designed for. This means that if one has to reduce the quantum for some reason, then the filter parameters cannot be expected to be unchanged. A safer (and more cumbersome) way of dealing with noisy data from sparse sampling is by modelling it as output data. Remark 2.35: A reasonable modelling strategy is to ignore the measurement errors to start with (select Hold), and later try better input models to see if that helps. Often the effects of high frequencies in upstream input are filtered naturally by passing through several downstream units, and do not show up in the output measured downstream. Hence spurious input into the model (from poor filtering of noisy data) will be filtered out by the model, and cause no harm. Remark 2.36: Usually, input filtering is a modelling task for which there is little prior knowledge, and one may have to try several filters. If each filter is given its own component, then it will be easy to change filters. It would be just as easy instead to edit the component that is the target for the input. However, in that case MoCaVa will no longer be able to keep a correct log of the hypothetical structures and how they score. 2.3.6.3 Disturbance Models MoCaVa3 supports three stochastic disturbance models: Brownian, Lowpass, and Bandpass. In order to select one of them it helps to have at least an idea of the general character of the actual physical disturbance. If nothing is known about its source, and no plotted data is available, one may have to try several models. Try first the simplest model, the Brownian, and take a look at the estimated disturbance that results from simulating the fitted model. This may reveal if the disturbance has any of the general characteristics assumed by the alternative standard models. All library models are dominated by low frequencies (compared with the Nyquist frequency 1/2h). : The Brownian model accumulates Gaussian random numbers, and makes a linear interpolation between the discrete values in order to create a continuous−time approximation of Brownian motion. It has one characteristic parameter, the average drift rate. Its general appearance is random drift with no given direction and no attraction to a ‘zero level’. It is a very robust disturbance, able to model most irregular low−frequency variation, including infrequent and large random steps.

2 The MoCaVa solution

51

: The Lowpass model makes a stepwise constant function from Gaussian random

numbers and then applies a first−order linear filter. The result varies randomly around zero, and has little power in frequencies above its bandwidth. It has two characteristic parameters, viz. bandwidth and rms−value. The bandwidth must be well below the Nyquist frequency. It is suitable for modelling low−frequency disturbances with the same general appearance throughout the sample, without a pronounced periodicity. : The Bandpass model makes a stepwise constant function from Gaussian random numbers and then applies a second−order linear filter with one pair of complex poles. It has three characteristic parameters, viz. rms−value, frequency, and bandwidth. Its general appearance is random variation with a dominating frequency, more or less pronounced. The dominating frequency must be well below the Nyquist frequency. It is suitable for modelling waves, effects of slow and poorly damped control loops, limit cycles, and clock−depending environmental effects. It would also be able to model vibration (for instance in a rolling mill), if the time quantum can be made small enough.

2.4 Fitting and Falsification The outcome of the test procedure decides whether or not a model structure is good enough to describe the data. With the requirement that the test should be maximally efficient, i.e., having maximum probability of rejecting a wrong hypothesis, this also determines the loss function to be used for fitting! The answer is to use the Likelihood Ratio test for falsification and the Maximum Likelihood criterion for fitting (Bohlin, 1991a). The following is a list of assumptions and restrictions leading to this result (see Bohlin, 1991a or 1994b for an analysis): 1) Popper’s principle of scientific discovery. This is the basis of the calibration procedure described in Section 1.3.1. 2) Statistical decision theory. Assuming that uncertainty may be described using probabilities makes it possible to define “risk” and to formulate a problem of finding the test procedure having the smallest risk of accepting a wrong hypothesis, i.e., an inadequate model structure. 3) Nested structures. The problem of minimizing risk can be solved, provided one has an alternative, wider model structure to compare with the one being tested, and that structure contains also the one to be tested. This is the basis for ‘refining’ the model structure by ‘expanding’ it in the way described in Section 1.3.2 “How to specify a model set”. 4) Parametric models. This assumption basically serves to reduce the unknown elements in a model to a finite number. (Even in ‘non−parametric’ methods it is possible to estimate only a finite number of parameters characterizing, for instance, an unknown frequency distribution.) 5) Long samples. This makes it possible to apply the “law of large numbers” and the “central limit theorem” in statistical theory to derive an explicit form of the likelihood function appearing in both the test criterion and in the fitting loss. The two optimality criteria will be: Fitting: Find M ν = arg min M Q(M, d|M ∈ F ν)

(2.21)

52

Practical Grey−box Process Identification

where F ν is the tentative model structure, d is the data sample and M ν the best model within this structure.

Testing: (2.22) If Q(M ν, d) − Q(M ν, d) > χ 2(|ν | − |ν |, β) 2 for some M ∈ F ν and ν ≥ ν , ≥ , then reject the model M ν

where χ 2(r, β) is the chi−square variable for r degrees of freedom and risk β. Notice that the same loss function Q appears in both. And since the function has a given form derived from quite general optimality criteria, this eliminates two conventional user’s tasks, viz. those of selecting a loss function (including the specification of weighting factors) and of selecting a test criterion. 2.4.1 The Loss Function The common loss function is N

Q(M, d) = 1 [log det R e(k|M, d) 2 k=1 + e(k|M, d) T R e(k|M, d)−1 e(k|M, d)]

(2.23)

where e(k|M, d) are the ‘residuals’, i.e., the errors incurred when predicting over the sampling intervals (t k−1, t k), and R e(k|M, d)is the covariance matrix of the prediction errors. Remark 2.37. The form of the loss function is that of the negative logarithm of a multivariate normal distribution, thanks to the “central limit theorem”. The chi−square threshold in the test is thanks to a theorem of Cochran (Wilks, 1962). Remark 2.38: Generally, noisy data require long samples to yield a satisfactory accuracy of the model. If the data sample is not long enough for the central limit theorem to be applicable, then the loss function is not necessarily the best one in the sense that it will give the test the maximum power. In addition, there is no convenient way to test if the sample is long enough for the asymptotic loss function to be optimal. However, it is still reasonable to use it also for short data samples, since the criterion still makes sense: It punishes the prediction errors weighted by their estimated accuracies. Thus, large factual errors e contribute heavily to the loss only if both measurements and the predictions are estimated to be accurate, when based on the model (otherwise the error may be more due to chance and therefore less informative). The term log det R e prevents an optimizer from minimizing the loss simply by reducing the weights R −1 e . Provided that it will still be possible to get an acceptable model out of the calibration procedure, even with a short sample, there is nothing to prevent one from specifying the criterion instead of deriving it from ‘higher’ principles. See (Bohlin, 1991a) for a further discussion on this point. 2.4.1.1 Normalized Loss The function defining Q(M, d) has an absolute value that is difficult to interpret, and that therefore makes little sense to a user. For one thing, it is not independent of the physical units of the sensor output. In fact, the value makes sense only in relations to other models.

2 The MoCaVa solution

53

In order to normalize the loss function define a ‘null’ model as y(t k) = Λ w y(k),

Λ = diag[rms(y)]

(2.24)

which can be interpreted as a model that contains no information from the data, except the rms values. The idea is to measure the loss of a model M relative to that of the null model. The latter has the loss N i (log Λ ii + ½)

Q0 =

(2.25)

i

where N i is the number of data from sensor #i. Subtracting this constant does not change the results of fitting or testing, but has the following advantages: : The normalized loss Q − Q 0 becomes independent of scale. : It is always negative (everything better than the ‘null’ model is a gain). : The value of exp[(Q − Q 0) N] defines a loss that lies in the range of (0,1); it is 1 for the null model and approaches 0 for a perfect model. 2.4.1.2 Weighted Loss The loss is a function of the unweighted Likelihood function, which assumes that nothing is known a priori about the values of θ. However, the prior knowledge entered by specifying parameter attributes places restrictions on likely ranges of variations in θ. The relations are given by the Parameter maps p = I(o, ν, θ), where p normally have physical meanings and attributes, while θ are scale−free coordinates. MoCaVa uses the following four mappings, depending on the intervals specified by the user: : No boundary: p = o + S p θ : Lower bound: p = p min + (o − p min) exp(βθ), where β = S p S 2p + (o − p min) 2 : Upper bound: p = p max − (p max − o) exp(− βθ),

where β = S p

S 2p + (p max − o)2

(1 + β 2), β = θ − α 1 − α 2 where c 1 = (p max + p min) 2, c 2 = (p max − p min) 2, α = (o − c 1) c 2 The mappings affect the likely ranges of θ in different ways. In the unbounded case the likely range is defined by the scale S p only, in the singly bounded cases by the scale, the bound and the origin, and in the doubly bounded case by the two bounds and the origin. However, in all cases it is not likely a priori that θ 2 1. Assume therefore the following a priori weight on the Likelihood function exp(− α θ 2 2), where α is a design parameter. The normalized and weighted loss function will be

: Upper and lower bound: p = c 1 − c 2 β

N

Q(M, d) = 1 [log det R e(k|M, d) 2 k=1 + e(k|M, d) T R e(k|M, d)−1 e(k|M, d)] N i (log Λ ii + ½) + α θ ν 2− 2 i

(2.26)

54

Practical Grey−box Process Identification

where M = ( , ν , θ ν). Remark 2.39. The weighted loss is also called the MAP (Maximum A Posteriori) criterion, since it maximizes the Likelihood of the θ−value after the data d has been obtained. The maximum a priori value is θ = 0. For long samples, the prior weighting normally has little effect. However, it prevents the estimates from drifting too far, which may otherwise happen when a bounded parameter tends to its boundary. 2.4.2 Nesting and Fair Tests A tentative structure F ν and an alternative structure F ν are ‘nested’ if F ν ⊂ F ν. When the condition is satisfied, the maximally efficient Likelihood−Ratio test can be applied. If the classes of the tentative and alternative structures are the same, = , the condition is simply ν > ν , i.e., the model structure is expanded within the class by freeing more parameters. If also the class is expanded, ⊃ , then nesting may still be possible. It is required that the null model in the alternative set be equivalent to the F(u t, w t, , p )≡ F(u t, w t, , o ) for all u t, w t. A tentative model, i.e., M (p ) sufficient condition is that the ‘origins’ of the parameters in the added component(s) have been set to their ‘null’ values, i.e., values that make the effect of the component(s) ‘null and void’. For instance, a factor in front of a component replacing a zero constant has a zero null value. When the nesting condition is satisfied, and there is more than one alternative, MoCaVa selects a modified ALMP (Asymptotic Locally Most Powerful) test by default (Bohlin, 1978). For models that are linear in the parameters the ALMP test can be interpreted as an LR−test,where the search for the best alternative model to be compared with the tentative model has been interrupted after one step (Söderström, 1981). With nonlinear parameter dependence, this does not hold, but the test that is implemented is still based on the loss reduction Q(M ν, d) − Q(M ν, d), and it is still called ALMP. The ALMP test not only avoids the time consuming search required by the LR test, but also allows several alternative structures to be tested in parallel. It is not as discriminating as the LR test, except when the difference between structures becomes small. However, that is the case where an efficient test is most important, while large differences have only to be detected sufficiently well by ALMP to surpass the threshold. Even when the nesting condition is satisfied the user has the option of overruling the default selection of the ALMP test in favour of the LR test. The reason is that ALMP is less safe than LR in nonlinear cases: The statistic is based on a single iteration, which is further based on a step length formula that is only partly reliable in nonlinear cases (see Section 2.4.3). There is a possibility that the step will overshoot, that the loss reduction will be negative, and consequently will not reject a wrong model. Hence, a negative loss reduction is an indication to the user to consider switching to the LR test. Null values do not always exist. When they do not, and the tentative model structure is to be tested against an alternative structure in a different model class, then the principle is different: It is to compare the losses of the best models within the two structures, and reject the tentative structure, if the alternative has a smaller loss. However, if the alternative is to be preferred, then it must not be more complex (according to the principle of parsimony), meaning that it must not have more free parameters. A comparison must be ‘fair’. The test may be interpreted as an LR test with no more degrees of freedom, i.e., with a zero threshold.

2 The MoCaVa solution

55

Remark 2.40. No method is known for computing a test statistic with not nested structures and different numbers of free parameters. When MoCaVa detects such a case, the cause of the ‘unfairness’ is displayed to the user, who is then given an opportunity to redefine the alternative structure. The simplest way is to reduce the number of free parameters. Algorithm 2.1. Setting up test Set up default test Check ‘nesting’ conditions: If nested, then select ALMP test Else check ‘fairness’ conditions: If fair, then select LR test Else indicate no valid test

2.4.3 Evaluating Loss and its Derivatives The following forms of the loss function and its derivatives with respect to coordinates θ in free parameter space are derived in Section A2: N

Q=

[γ T γ(k) + Á(k) T Á(k) 2] + α θ 2 k=1 N

Qθ =

2

− Q0

[γ T γ θ(k) + Á(k)T Á θ(k)] + α θ

(2.27)

(2.28)

k=1 N

[γ θ(k) T γ θ(k) + Á θ(k) T Á θ(k)] + α I

Q θθ ≈

(2.29)

k=1

where R e(k) = Γ(k) Γ(k) T , Á(k) = Γ(k) −1 e(k), γ(k) = log diag Γ(k), and Γ is lower left triangular. The matrices γ θ(k) and Á θ(k) are the gradients of the vectors γ(k) and Á(k) with respect to the vector θ, and γ is a constant vector. The right hand side of the Hessian Q θθ is a relatively inexpensive approximation of the exact value, since it can be evaluated without also computing the expensive second−order gradients Á θθ(k), γ θθ(k) in the full formula (Section A.2). However, it is valid only for long samples, and is a good approximation only when the model is close to a good model. Hence, there is motif for investigating whether it can reasonably be used also throughout the search for a good model. IdKit uses the Hessian for two purposes, viz. i) for computing the accuracy of parameter estimates, and ii) for determining the direction and step length in a Newton−Raphson search for values that make Q θ = 0. Fortunately (because one can hardly afford to use the exact Hessian), there are some favourable circumstances: : The parameter accuracy will not be needed until a good model has been found, and the approximation is valid. : When the search is far from the minimum, the exact Hessian will be of little use to a search method (the Newton−Raphson) that basically assumes a constant Hessian. However, the positive definiteness of the approximate Hessian will ensure that the steps taken always point in the direction of smaller loss values. : When the search is close to the minimum it will provide fast second−order convergence.

56

Practical Grey−box Process Identification

Remark 2.41. Considering how little that has been assumed about the model structure so far, I wonder if these fortunate circumstances are just pure luck, or if there is some hidden logic behind, still to be revealed. If, some day, someone will explain why it could not have been in any other way... Remark 2.42. Even if the direction of the next step in the search is guaranteed, its length is not. Far from the minimum both the exact and the approximate Hessian may cause step lengths both too short and too long to be of any use. This possibility will require modifications to the basic Newton−Raphson search rule (see Section 2.6). 2.4.4 Predictor It remains to find a way to evaluate the residuals and their covariances for a given model and data sample. Since the residuals are e(k) = y(t k) − y(t k|t k−1), the task is now to find a predictor P(k|M, d k) → y(t k|t k−1), R e(k). IdKit uses a version of the Extended Kalman Filter (Algorithm A.2 in Section A.4) to derive a class of approximate predictors P for the given model class F . They are valid in cases where prediction errors due to random disturbances are small enough to stay in the linear range when linearizing the model locally. There is no restriction on the size of errors caused by large stimuli and a wrong model. In principle, the algorithm predicts between two sampling points by applying a discrete−time Extended Kalman Filter as many times as there are time quanta in the sampling interval (normally once). It also computes the normalized residuals Á and residual variances γ needed to compute the loss and its derivatives in Equations 2.27 to 2.29. 2.4.5 Equivalent Discrete−time Model The object model in IdKit is obviously restricted by what an EKF can handle, most generally a nonlinear stochastic state−vector model in discrete time, but quasilinearizable with respect to its stochastic elements. This includes, in principle, equivalent discrete−time models obtained as solutions of ordinary differential equations with stochastic input, describing a sampled continuous−time object. However, in order to increase the efficiency of the algorithms in IdKit it is worth while to introduce more restrictions in the modelling, in order to allow more efficient algorithms for classes satisfying the restrictions, provided, of course, they seem acceptable in practice. The structural restrictions introduced in Section A.1 give the compact form dx = G[x, w(τ), u d(τ)] dt + E ω(τ) dω, t ∈ (t τ, t τ + h] η = Z[x, u d(τ)], where η = (z, v, u)

(2.30) (2.31)

where all except x, ω and η are constant during a quantum interval. Hence, a discrete− time equivalent can be obtained, in principle, by integrating the continuous−time model one quantum to obtain a relation between the initial values x(t τ), the constant input u d(τ),w(τ) and the next state x(t τ+1). Remark 2.43. Only the case of low−frequency disturbances ( E ω = 0, and all disturbance via w) is implemented in MoCaVa3, but Section A.3 shows a way to extend that to high−frequency direct state noise ω. The sensitivity matrices between the input and output of the continuous−time model (the user’s model) and the equivalent discrete−time model have a main rôle in the predictor. They are matrices of gradients (= derivatives) of all output with respect to

2 The MoCaVa solution

57

all input variables. They correspond to the ‘transition’ matrices in linear models. Computing them also takes the main part of the time of evaluating loss and its derivatives. The continuous−time sensitivities are .

G x(t) = ∂x(t) ∂x(t) . G w(t) = ∂x(t) ∂w(τ)

(2.32) (2.33)

and the discrete−time sensitivities .

H(τ) = ∂x(τ + 1) ∂x(t τ) A(τ) = ∂x(τ + 1) ∂x(τ) E(τ) = ∂x(τ + 1) ∂w(τ) C(τ) = ∂z(τ) ∂x(τ) F(τ) = ∂y(τ) ∂w(τ)

(2.34) (2.35) (2.36) (2.37) (2.38)

2.4.5.1 Linearization and Sampling Since a discrete EKF requires both linearization and sampling, there are two options: i) either linearize first and integrate after, or ii) integrate first and then linearize the nonlinear discrete−time equivalent. MoCaVa uses the first alternative, since this opens a very efficient way to handle ‘stiff’ systems: The linearized and sampled system is derived in (Section A.3, equations A.35 and A.39): xr(τ + 1) = x r(τ) + H(τ) G(τ) x(τ + 1) = A(τ) x(τ) + E(τ) w(τ) + w ω(τ)

(2.39) (2.40)

A(τ) = exp[G x(τ) h] H(τ) = G x(τ) −1 [A(τ) − I] E(τ) = H(τ) G w(τ)

(2.41) (2.42) (2.43)

where

The continuous−time sensitivity matrices are computed by numerical differentiation, and there are fast algorithms for evaluating the expressions in Equations 2.41 and 2.42 (Section A.3.3). They allow a wide range of eigenvalues, which characterizes normally ‘stiff’ systems. The DiscreteModel algorithm is defined in Section A.4.1, and carries out the following operations DiscreteModel [x r(τ), u d(τ), τ] → x r(τ + 1), η r(τ), H(τ), A(τ), C(τ), E(τ), F(τ) It appears at a single place in the Predictor algorithm (A.2), and is the only algorithm that needs access to the user’s model. The other statements in Predictor serve to reduce the effects of random disturbances.

2.5 Performance Optimization Basically, the sensitivity matrices H(τ), A (τ), C(τ), E(τ), F(τ) must be evaluated for each time quantum, each time requiring the evaluation of the user’s model dim(x) +

58

Practical Grey−box Process Identification

dim(w) + 1 times. And this has to be repeated dim( θ) + 1 times to yield one step in the search for the minimum loss. Since, running the model tends to dominate the computing in cases with large models, an investigation whether it would be possible to reduce the number of accesses to the user’s model seems well motivated. The prospects would also seem favourable: For instance, it is not likely that all the dynamic properties of a process would actually change at all times. Three possibilities of making shortcuts have been investigated, exploiting three expected sparsity properties of industrial production processes: : Sparse changes in dynamics: All entries in the sensitivity matrices do not change at all times. Normally, processes change their dynamic properties only in connection with changes in operating point. This suggests an option for predicting the values of sensitivity matrices instead of updating them by numeric differentiation and accesses to the user’s model. : Sparse parameter dependence: All entries in the sensitivity matrices do not depend on all free coordinates. This means that their values do not have to be recomputed for all displaced coordinate values θ i + δθ i. : Sparse sensitivity matrices: All output from all components do not depend on all input to all other components. For instance, state−transition matrices of systems without feedback over components are ‘triangular’ − the states of upstream components do not depend on what happens in downstream components. Neither do parallel feed or production lines influence each other. This means that all components in the user’s model do not have to be accessed for computing the output with displaced states or noise variables. Exploiting these possibilities requires additional routines, in the first case for detecting changes in the model dynamics, in the last two cases for analyzing the structure of the system of components. This will carry some overhead, which means that some models with dense structures or frequently changing dynamics will not benefit from using it. MoCaVa therefore offers the possibilities as ‘advanced user options’. 2.5.1 Controlling the Updating of Sensitivity Matrices In order to exploit the possibility of infrequently changing sensitivity matrices, a function SensitivityUpdateControl has been added in the algorithm computing the sensitivity matrices. The function does two things: 1) In a preceding ‘probing’ pass it analyses the model for significant changes in sensitivity matrices, and computes and stores information χ g needed to control the updating of the sensitivity matrices 2) In regular passes it updates the sensitivity matrices by prediction (and thus bypasses accesses to the user model) whenever χ g(τ) indicates this to be adequate. In essence, the function does the following (see Section A.6.1 for a more detailed description): : In the probing pass all sensitivity matrices Ψ(τ), Ψ ∈{H,A,C,E,F} are computed by numeric differentiation to be used as ‘data’ for the analysis. : The probing pass serves to create a predictor for the updating of sensitivity matrices. A ‘zero order hold’ would be simplest, meaning that matrix values are updated only when the computed values indicate that they have changed. However, a linear predictor is also manageable, based on the assumption that the sensitivity matrices are at most linear functions of the state and input arguments x and u within the range of argument variation during a time quantum. Setting up for a linear predictor obviously costs more overhead, but can also be expected to reduce the num-

2 The MoCaVa solution

59

ber of accesses. In order to find the slope of the extrapolating predictor it is necessary first to estimate the ‘curvature’ of the nonlinear model (which is a three−dimensional array). Hence, linear ‘models’ of the variations of the elements in a sensitivity matrix are set up Ψ ij(τ) = Ψ ij(τ − 1) + Å(τ) h Ψij + σ ij w ij(τ) and fitted to the {Ψ ij(τ)}−sequences in order to determine the curvature vectors h Ψij . The common input arguments in all models are Å(τ) [ x(τ) u(τ)], where is the backwards−difference operator. The fitting is done recursively, using a Kalman estimator. This avoids another probing pass. Variables are normalized with their scales in order to allow a comparison of the residual sizes. : At the end of the probing pass the residual sequences e Ψij (τ) = Ψ ij(τ) − Ψij(τ − 1) − Å(τ) h Ψij are first computed based on the final curvature estimates h Ψij and stored values Ψ ij and Å. They represent the prediction errors. Next are computed the p− percentiles e Ψp of e Ψ(τ), i.e., values such that p% of the residuals are larger, where p is a value specified by the user. The residuals and the percentiles are instrumental in deciding at what times to update Ψ(τ). The following rule is used: If Ψ

| e Ψ(τ)| > max(;.e , eΨp ), then mark Ψ(τ) for update, where ;.e Ψare thresholds set by the user. The motif for the double threshold is the following: The thresholds limit the error accepted without correcting the deviation. However, in difficult cases the user is also given the opportunity to limit the number of times the predictor accesses the model. That may raise the approximation errors above the specified, in which case the more tolerant threshold is displayed. The option may help the user to assess how difficult the case is, and avoid a situation where the computer becomes bogged down, trying to achieve an accuracy that is neither achievable nor actually needed at all times. Accurate calculations are normally needed only for the final model.

2.5.2 Exploiting the Sparsity of Sensitivity Matrices The user cannot affect the operation of these options in any way (except by activating or deactivating them), unlike with the SensitivityUpdateControl option. Neither is there any approximation involved. It is therefore less important for the user to know the details of how the options operate, and the following is a summary. 2.5.2.1 Independence of Parameter Perturbation “Memoization” is a simple and general technique to avoid computing the same value several times: Check if the sensitivity matrices have changed their values due to perturbed coordinates during the first pass, and create an indicator to be used in the next passes. The algorithm is defined in Section A.6.2. 2.5.2.2 Independence of State and Noise Perturbation In essence, an indicator matrix is constructed for each sensitivity matrix, which contains zeroes in places where there can be no sensitivity for structural reasons, and ones otherwise. The chain rule of differentiation is evoked to do that. It can be written as a recursive process running over the set of active components in the order determined by their cause−and−effect relationships (i.e., backwards in the component index): From the component models

60

Practical Grey−box Process Identification

s(i − 1) = S[i, x(i), w(i), s(i)] . x(i) = G[i, x(i), w(i), s(i)] y(i) = H[i, x(i), w(i), s(i)]

(2.44) (2.45) (2.46)

follows

∂S(i) ∂S(i) ∂S(i) δw(i) δx(i)+ δs(i)+ ∂w(i) ∂x(i) ∂s(i) ∂G(i) ∂G(i) ∂G(i) . δw(i) δx(i) + δs(i)+ δx(i) = ∂w(i) ∂x(i) ∂s(i) ∂H(i) ∂H(i) ∂H(i) δw(i) δx(i)+ δs(i) + δy(i) = ∂w(i) ∂x(i) ∂s(i) δs(i − 1) =

(2.47)

(2.48)

(2.49)

The formulas would allow the recursive computing (downstream) of all sensitivity matrices in the total model from those of each component. However, the following alternative is believed to be more efficient. Use the recursion to compute the indicator matrices, once and for all:

∂S(i) ∂S(i) ∂S(i) Bδw(i) Bδx(i)+ B Bδs(i)+ B ∂w(i) ∂x(i) ∂s(i) ∂G(i) ∂G(i) ∂G(i) . Bδw(i) Bδx(i) + B Bδs(i)+ B Bδx(i) = B ∂w(i) ∂x(i) ∂s(i) ∂H(i) ∂H(i) ∂H(i) Bδw(i) Bδx(i)+ B Cδs(i) + B Bδy(i) = B ∂w(i) ∂x(i) ∂s(i)

Bδs(i − 1) = B

(2.50)

(2.51)

(2.52)

where B is an ‘indicator’ operator replacing all nonzero elements with ones. The first step is to determine the nine indicator matrices for each component. This is done by analyzing the model structure to establish what component output depend on what input. Next, the sparsity routine loops over the recursion, once for each column in the indicator matrices, i.e., with Bδs = 0 and varying positions of single units in Bδx and Bδw as start values. The procedure yields the indicator matrices for the sensitivity . . dy dy functions B dx , B dx , B , B . dx dw dx dw Armed with this, the routine in ‘sparse’ mode operates with three consecutive screening processes, applied to each element in a continuous−time sensitivity matrix: 1) When the SensitivityUpdateControl routine has decided that a total sensitivity matrix must be updated, 2) and when the Memoization routine has decided that its value may deviate from one already computed, 3) and when the Sparsity routine has decided that its indicator is not zero, 4) and that the response element has not been computed already, only then will access be given to the relevant sequence of user−specified components for computing a response vector to the particular input variation.

2.5.3 Using Performance Optimization The success or failure of using the advanced options depends on the model structure, and with the SensitivityUpdateControl option also on the user’s specifications and the actual process generating the data. It is therefore important for the user to get a feel for what changing the specifications may achieve, and to obtain some indication from

2 The MoCaVa solution

61

the computer, by which he or she can appraise the effect. Since the purpose of all options are to reduce computing by reducing the number of accesses to the user’s model, and this can only be achieved at a cost, the indicators should reveal what reduction is achieved and at what cost. With the SensitivityUpdateControl option the cost is in the form of approximation errors, and the specifications change the approximation levels. The indicators should therefore reveal what approximation errors are actually achieved. Learning to use this option requires some exercise. On the other hand, the gain may be dramatic in cases that would otherwise be prohibitively cumbersome (as in the cases of “Bending stiffness of cardboard” and “Continuous pulp digester”). With the other options there is no approximation error, and the cost has the form of program overhead. There is no explicit cost indicator; a stop watch will be enough in all cases where performance optimization matters. 2.5.3.1 User’s Specifications With the SensitivityUpdateControl option the following specifications are required from the user: : Prediction error levels for the five sensitivity matrices H, A, E, C, F normalized with their scales. Default values are 10 −8 for H and 10−5 for the other sensitivity matrices, since the trajectory values need to be determined more accurately than the sensitivity matrices. : A limit for the percentage of accesses to the users model. Default value is no limit: ;.p = 1, i.e., 100%. : A value for the number of initial steps before the SensitivityUpdateControl is started. Default value is 5. No specifications are required with the other options. 2.5.3.2 Performance Indicators The following indicators appear on the screen while the model structure is being fitted: : Error thresholds in sensitivity matrices: e Hp, e Ap, e Fp , e Ep, e Cp, They are the error percentiles, if that is more than the specified thresholds. The latter eventuality indicates that care should be taken, either to accept the higher thresholds, or else to increase the percentage limit to the number of accesses. : Number of sensitivity matrices updated by access to the user’s model: n H2 , n A2 , n F2 , n E2 , n C2 . : Number of sensitivity matrices updated by extrapolation: n H1 , n A1 , n F1 , n E1 , n C1 . : Number of sensitivity matrices that need no updating: n H0 , n A0 , n F0 , n E0 , n C0 . The counter values indicate the degree of variation and predictability in the object dynamics. Notice that the first set of counters are limited by the percentage limit ;.p. Large values for the second set therefore suggest that the limit may have been set too low, in particular if the error levels have also increased. : Number of accesses to components in the probing pass, in the first fitting pass, and in consecutive passes: The user’s model is accessed one component at a time. Depending on the different degrees of dependence on parameters and other input the minimum number of accesses to the individual components vary. The latter cannot be exploited in the ‘probing’ and ‘first’ passes, since the input dependence is analyzed during the probing pass, and the parameter dependence during the first pass, where also loss derivatives are computed. Hence, the second set of values indicate

62

Practical Grey−box Process Identification

how much has been gained by the ‘sparsity’ option, and the third set indicate how much more has been gained by ‘memoization’. : Correction for approximation error: This is the difference between the exact loss computed in the probing pass, and that computed in the first fitting pass. It is used to correct all the following approximative loss values in the search. It is a measure of the overall accuracy. Since the threshold for a significant reduction of loss is at least 4, an approximation error much smaller than that should cause no concern.

2.6 Search Routine The search routine is basically Newton−Raphson with some elementary modifications to compensate for the fact that the Hessian is uncertain. The choice is motivated by the following circumstances: : Loss evaluations are expensive and must be few. : Once the gradient has been evaluated, an approximate Hessian adds little to the cost. : The approximate Hessian is positive definite. : Due to the special loss function the proper measure of convergence is the distance of the loss from the minimum (and not that of the parameters from the optimum). There is also a known and case−independent criterion for stopping the search. It involves the Hessian. The algorithm is given in Section A.7. The modified Newton−Raphson search suits the loss function used for the fitting, since it uses a non−negative definite approximation of the Hessian, computed from only first−order derivatives of the model residuals. For parameter values far from the optimum, and large variations in the residuals’ sensitivities to the free parameters, the estimate of the Hessian may however deviate much, causing the step taken towards the minimum to be inefficient or even counter−productive. For structures such that the residuals are affine (linear) functions of the free parameters, the search converges in one step, but normally it takes more. The number it takes depends on a number of design parameters for the search routine, and the setting of those requires some skill in difficult cases. Some guidlines are given in Section 4.8.1. Remark 2.44. The main reason for adhering to the Newton−Raphson procedure is that since loss evaluations dominate the computing, the advantage of few steps becomes paramount. Safer search routines take many more steps, and it is believed to be less frustrating for the user having to intervene at one more point, in an already interactive calibration procedure, and on rare occasions, than having to wait much longer in all cases for a wholly automatic procedure to finish. On the other hand, there is still the possibility of letting the program search over night, which means that here is a subject for further development. Example: The loss function for a simple stochastic model It turns out that the modified Newton−Raphson search method sometimes performs badly when both state−disturbance and measurement−disturbance variances are among the free parameters. In order to explain this it is helpful to analyze a simpler case where only the two variances are free parameters, namely

2 The MoCaVa solution

x(τ + 1) = a x(τ) + e 1(τ) y(τ) = x(τ) + e 2(τ) E{e 1(τ) 2} = r 1, E{e 2(τ) 2} = r 2, E{e 1(τ) e2(τ)} = 0

63

(2.53) (2.54) (2.55)

and let r1 and r2 be unknown (scalar) parameters. In order to compute the Likelihood function apply the (steady−state) Kalman filter. This yields K = r x r e = r x (r x + r 2) r x = a 2 (r 2 − K 2 r e) + r 1 ^ e(τ) = y(τ) − ^ x(τ) ^ x(τ + 1) = a [x^(τ) + K ^ e(τ)] Let

2

= r x r 2, η 2 = r 1 r 2. Inserting this into Equation 2.57 yields 2

Hence,

(2.56) (2.57) (2.58) (2.59)

2

(

2

+ 1) = a 2 [

2

(

2

+ 1) −

4

] + η2 (

2

+ 1)

(2.60)

satisfies 4

−

2

(η 2 + a 2 − 1) − η 2 = 0

(2.61)

with the solutions 2

= 1 [η 2 + a 2 − 1 2

(η 2 + a 2 − 1) 2 4 − η 2 ]

(2.62)

The logarithm of the likelihood function defined by Equation 2.23 is asymptotically log L(r 1, r 2) → − N [log r e + E{e^(t) 2} r e] 2

(2.63)

In order to compute the second term rewrite Equations 2.53 and 2.54 into operator form y(τ) =

q −1 e (τ) + e 2(τ) 1 − q −1 1

(2.64)

where q −1 is the backwards−shift operator. This is statistically equivalent to y(τ) = λ

1 − c q −1 w(τ) 1 − a q −1

(2.65)

for some values of (λ, c) that depend on the values of (r 1, r 2). From Equations 2.59 and 2.65 follows ^

e(τ) =

1 − c q −1 1 − a q −1 w(τ) y(τ)= λ −1 1 − a(1 − K) q −1 1 − a(1 − K) q

(2.66)

64

Practical Grey−box Process Identification

0.01 0 0

100 a=1

r1

c = 0.8

100

r2

Figure 2.12. Likelihood loss function for disturbance variances, logarithmic scale

Since 1 − K = (

2

+ 1) −1, the left member of Equation 2.66 has the variance

E{e^(t) 2} = λ 2

1 + c 2 − 2ac( 2 + 1)−1 1 − a 2( 2 + 1) −2

(2.67)

Inserting this into Equation 2.63, and noticing that adding a constant does not change anything of importance, yields the following loss function log L + const. N 2 ( 1 + c 2 − 2ac ( 2 + 1) −1 λ + log = 2 2 2 −2 1 − c ( + 1) ( + 1) r 2

Q(r 1, r 2) = − 2 lim

N→∞

2

+ 1) r 2 λ2

(2.68)

This yields the surface depicted in Figure 2.12, where 2 has been computed from Equation 2.62. The parameter scale is logarithmic, which agrees with the parameter map r i = exp(θ i). Hence, the figure is depicted as seen by the search routine, which is a function of θ. Apparently, it is far from quadratic, in particular for small values of r 2, which explains why the search routine has difficulties in estimating the direction and distance to the minimum. However, the form suggests the following recommendation: When assigning nominal values for the variances r 2 of measurement errors, choose a value one or two orders of magnitude above the estimated actual value! Not only will the decision be motivated because a substantial amount of modelling errors will probably add to the measurement errors, but too large start values will also make the search easier than too small start values.

2 The MoCaVa solution

65

A second recommendation based on the same figure is to keep the start values for the level of disturbances r 1 small.

2.7 Applicability The topic of this section are some issues of relevance to the decision of whether or not it would be worth while to try and use MoCaVa. In practice, much depends on experience, even if some hints to the type of problems that can be solved may be obtained from the case studies. Some of the contents are summaries and conclusions of what has been discussed in the previous sections, for the benefit of the readers who have skipped those sections. Some can be stated immediately: Do not use MoCaVa in cases with much data and large linear models of standard type, such as static or dynamic regression models. It will be slower than black−box packages. Do not use it for large mechanical or electro− mechanical systems, where disturbances are small and it is known what causes the dynamics. The user interface is not designed for this type of systems. Do not use it for objects whose dominating dynamical properties are discontinuous, for instance due to dry friction, dead zones, or saturation. The quasi−linearization will not work. Do not use it for objects whose proper modelling depends on a complicated geometry, and where a finite−element description is needed. The computing will be prohibitive. Use it for industrial processes of continuous type, where prior knowledge is partial and uncertain and disturbances are substantial. The long−rangepredicting ability and the possibility of monitoring unmeasured variables will be useful. Remark 2.45. Kristensen, Madsen, and Jørgensen (2004) have done a comparison between MoCaVa and CTSM. Their conclusions are that CTSM gains in estimation accuracy for large disturbances, and MoCaVa in speed and support functions for the user. 2.7.1 Applications The types and sizes of processes where MoCaVa will be applicable cannot be delimited a priori, but well exemplified by cases where the method has proved itself. The purpose of the case studies has been to test the theory and the software being developed in parallel, and to see what problems may appear in trying to apply the theory to practice. Table 2.2 summarizes the number of arguments involved, as crude measures of the sizes of the applications. “In” and “out” are the recorded variables. Table 2.2. Sizes of case models: Number of arguments

Case

in

out

states dist.

par.

Baker’s yeast Steel rinsing Pulp digester Cement milling Recovery boiler Bending stiffness EEG signals

2 4 2 2 7 16 0

4 5 3 2 2 2 2

4 10 70 2 1 8 19

25 31 25 6 6 25 9

1 5 3 0 1 2 2

The cases were selected as suitable for grey−box modelling, characterized by partial prior knowledge, some unknown input, and contaminated data. In most cases

66

Practical Grey−box Process Identification

physical data from either pilot plants or full−scaleproduction units have been analyzed using predecessors of MoCaVa. The following is a brief survey of case studies done within the grey−box identification program at KTH. Baker’s Yeast Production This is a bio−technical process. Data were collected during production of ‘mother yeast’ using a pilot plant at Jästbolaget in Sweden, normally used for that purpose and for experiments. Some prior knowledge of the nonlinear dynamics of yeast growth were available, but unknown variables, in particular the start conditions play a major role. The study revealed that a single internal unmeasured disturbance was the main cause of the large variations in the quality of the final product, and that this disturbance is observable (Fan, 1990; Fan and Bohlin, 1989). Steel Rinsing This is a process in industrial steel production. Data were collected from a full−scale production unit at the Domnarvet plant in Sweden. One of the four control variables was varied experimentally for the purpose of identification. Part of the dynamics of the process were known a priori, other parts were determined empirically. Unmeasured disturbances were significant (Sohlberg, 1991, 1992a, 1992b, 1993a, 1993b, 1998b; Bohlin, 1991b, 1994a). The case is the first of the two applications treated in Part III. Continuous Pulp Digester This is an industrial pulp production process. Data were collected during experiments on a full−scale production unit at the SCA Wifsta−Östrand plant in Sweden. Five inputs were varied by sequences of steps with different intervals. This is the largest of the case studies; modelling required five coupled nonlinear partial differential equations, and unknown disturbances play a major role. Applying a collocation method transformed the PDE into approximating ODE with 70 state variables. The study revealed that out of the three unmeasurable internal disturbances expected for physical reasons, one was the dominating source of model error in all measured output (Funkquist, 1993, 1994a−d, 1995). Cement Milling This is a subprocess in industrial cement production. Data were collected during experiments on a full−scale production unit at Lafarge Canada, Richmond. Two input were varied stepwise and two output measured. Some prior nonlinear structure knowledge has been used in the modelling. No disturbances were modelled (Havelange, 1995). The case study was the first to be carried out by someone who had not been involved in the design of MoCaVa. Recovery Boiler This is an industrial process in pulp production, recovering chemicals and energy from the pulp digesting process. The main physical process is combustion. Data were collected during normal production at the Husum and Värö plants in Sweden. Semi− physical modelling of the combustion process (involving chemical reactions as well as heat transfer and radiation) suggested a four−compartment, single−state, nonlinear model with seven input and three measured output. No disturbances were modelled. The study showed that a grey−box model predicted as well as a black box, but needed

2 The MoCaVa solution

67

fewer parameters. The study was discontinued (by a project deadline) before all information in the data were exhausted (Bohlin, unofficial internal report). Bending Stiffness of Cardboard This is the main quality variable of an industrial cardboard manufacturing process. Data were collected during normal production at the Frövi plant in Sweden. The nonlinear model has eight states, sixteen input, and two measured output. Two unmeasured disturbances also need to be modelled. The case is reviewed in Chapter 7 (Bohlin, 1996; Petterson et al, 1997, Pettersson, 1998). EEG Signals This is a physiological process; the signals are obtained by placing electrodes on the human scalp. In essence, some hypotheses about the source of the electrical processes in the brain producing the signals were tested. Simulated data were used, as well as physiological data recorded at the University of Houston, Texas. The model is nonlinear and purely stochastic with no evoked input. The particular method used to compute the likelihood loss has not yet been not implemented in IdKit (Markusson and Bohlin, 1997, Markusson, 2002). Other Applications of the Method The following projects are some ‘offsprings’ of the grey−box program. : Mould level control in continuous casting (Graebe, Elseley, and Goodwin, 1992). : Pulp refiner (Allison, Isaksson, and Karlström, 1995) : Air−cooling process for steel strips (Spännar and Sohlberg, 1997) : Monitoring and failure diagnosis in steel strips (Sohlberg, 1998a) : Paperboard properties (Bortolini, 2001) : Indirect measurement of steel strip temperature (Spännar, Wide, and Sohlberg, 2002) : River control (Sohlberg and Särnfelt, 2002) : A heating process (Sohlberg, 2003) : Drive train identification (Isaksson and Lindkvist, 2003). 2.7.2 A Method for Grey−box Model Design MoCaVa is a tool for setting up and solving the tasks of calibrating and validating models. However, making a mathematical model of a physical object involves also other tasks. For instance, the model designer must produce the data and propose a reasonable mathematical framework for the modelling. For one thing, he or she must decide what variables are interesting to measure and record. That will in fact define the object, by delimiting it from the environment (carving it out from the rest of the universe). It will save much work later, if it is also possible to anticipate which of the variables will have the largest influence on the response. This prior knowledge is needed for designing a ‘root’ model class to start from. If this class involves too many variables, there will be uncomfortably many possible relations between those variables to test and reject. As should not be surprising, there are no clear rules on how to do the preparations for using MoCaVa, when one is faced with an industrial process or other physical object. But the following procedure has been some support in the case studies. It involves five steps, of which MoCaVa offers support for the last three: 1) Phenomenological description: Make a verbal, graphical, or other mental description of the object and experiment conditions. This serves to delimit the object of the modelling.

68

Practical Grey−box Process Identification

2) Variables and causality: Translate the description into a system of causal dependences between defined variables, for instance in the form of a block diagram. This may introduce internal variables that are not measured, or random disturbances (real or fictitious). The step serves to eliminate a number of otherwise mathematically possible relations between the object’s input and output variables. It also creates a skeleton structure on which to hang any prior knowledge about the (usually internal) variables and the relations between them. 3) Mathematical modelling: Specify known relations between variables, including parametrization, or choose structure for unknown relations, including disturbances. If it is not known how many, or what relations that are needed, be prepared instead to create several hypothetical model structures with increasing detail. But not before an improvement is called for, based on the results of the next step. Start with the simplest conceivable model structure, containing the most well−founded relations. 4) Calibration: Find the simplest model that is not falsified by experiment data. This involves fitting to data and tests of significance. The results are measures of uncertainty and credibility, and usually cause a return to step 3. 5) Validation: Confront the model with independent data. If the calibrated model is more complex than the purpose requires, then reduce the model. If it is inadequate, then get more experiment data. If that is not possible, then accept a less ambitious purpose. Notice that calibration and validation follow different rules for when to end the sessions. They may be formulated as : The scientist’s rule: Proceed until the model explains the data. : The engineer’s rule: Proceed until the model satisfies the purpose. Remark 2.46. The recommendation to find the best model that data allows (”the scientist’s rule”) before looking for the simplest model that satisfies the purpose (”the engineer’s rule”) may seem somewhat ‘roundabout’, in particular when the end result is a much simpler model than the one calibrated, and particularly if the latter has been found with considerable effort. Why not go directly to validation? Hjalmarsson (2005) argues that calibrating before validating gives the best accuracy of the final model. Remark 2.47. The task may also be to calibrate a model purchased from an outside vendor. An obstacle is then that the model structure is fixed by the program, and it may or may not be difficult to reduce its complexity. A conceivable solution would be to redesign MoCaVa to accept external models. However, that is only possible if it is also possible to derive a predictor, like in deterministic models. The EKF needs the state− transition matrices, which are not available, unless the states of the external model are available. The last condition is satisfied by the model generator in DymolaZ, which allows MoCaVa to accept model structures from that external source (Section 5.3). 2.7.3 What is Expected from the User? How convenient is it to use MoCaVa? Certainly not as easy as with a black−box method, for instance the MATLABX Identification Tool Box. In summary, a user of MoCaVa must be able to do the following: : Define one or more submodels in the form of state equations. : Classify the input arguments in the equations as either feed, control, disturbances, parameters, constants, or time. : Specify various attributes of some of the arguments, such as scales, nominal values, and ranges.

2 The MoCaVa solution

69

: Assign data to the control variables, and pick suitable standard models for interpolating between sampled input data.

: Pick suitable standard models for disturbances. : Determine the sequence of execution of the submodels. : Suggest one or more alternative submodels to augment, when the current tentative model structure has been rejected as inadequate.

: Specify one or more purposes, if that is other than finding the simplest model that

agrees with available data and prior knowledge. A user does not have to know: : All submodels, in particular not those of disturbances. : Which of the known submodels that are needed. : The values of all parameters. : The number of parameters to calibrate. : A fitting criterion. : A falsification criterion. : A purpose, provided the simplest model that satisfies data and prior knowledge will suffice. 2.7.4 Limitations of MoCaVa

Basically, MoCaVa cannot handle : Models with discontinuities. But the program may still work well with models having a small number of discontinuities in derivatives. : Implicit models (where causation has to be determined automatically). But the idea is that causality is prior knowledge, which will save tests. : Continuous models with delayed states. But delayed input variables can be modelled approximately using a library routine. : General discrete−time or hybrid models: But simple hybrid models with a deterministic discrete−time parts can be treated, for instance a continuous process connected with digital input filters or controllers. : Distributed−parameter systems: But it is possible to supply the model with a user− defined routine for transforming PDE to ODE and treat the latter (Funkquist, 1995; Ekvall, Funkquist, Largerberg, 1994). 2.7.5 Diagnostic Tools In practice, two tasks will take much of the user’s time: i) debugging, i.e., finding errors in the writing of variable relations, when the model is not according to the user’s intentions, and ii) finding out what to do when a model is indeed in accordance with intentions, but still not good enough. MoCaVa offers some tools to facilitate this. Step−wise Design Primarily, each component is compiled stand−alone, and therefore free of compilation errors, before components are linked into a model. However, the difficulties in model debugging usually start after a successful linking. Fortunately, the tree−like structure of the model makes it possible also to test−run one more component at a time. Input are then replaced with their nominal values, and the model is run up to the last not yet debugged component. This means that the user can make debugging easier by modularizing more. Basically, the only effective tool for eliminating run−time errors is to print

70

Practical Grey−box Process Identification

or plot suspiciously−behaving variables and try and track the cause from the submodels that computed them. It is therefore of crucial importance that the user recognizes the variables and the statements that produce them. For that reason no formula manipulation is done, and variable names are retained during execution. Modularization The modularization together with the sequential testing procedure, inherent in the design, also provides information on what to do to improve a bug−free but inadequate model: Mainly, submodels that contribute significantly are worth considering further, while those that do not may be eliminated from consideration. Again, the more modularization, the more information. Nesting The tentative model (= the best so far) and the alternatives (= the hopefully better model structures) need not contain the same components. The statistical risk of rejecting the tentative model (which is the primary tool for determining model complexity) can still be computed, provided the alternatives are nested. That condition is checked by MoCaVa, and the cause of a violation is displayed. The user can then choose to modify the alternative(s) in order to satisfy the nesting condition (and have the benefits of a less cumbersome test and of getting a risk value), or else refrain from nesting, and instead use the prediction−error indicators, or loss values to determine whether an alternative is better. However, even in not nested cases, a comparison has to be ‘fair’. This condition is also checked by MoCaVa, and a violation results in a diagnostic message indicating the cause. The Test Statistics The table of test statistics displays the outcome of the test of a tentative model, and is the main source of information to the user on what to do next. Basically, it yields a three−valued piece of information for each alternative: : The tentative model has not been falsified : The tentative model is false and the alternative is better : The tentative model is false, but the alternative is inadmissible Generally, the results of statistical tests indicate whether a model is false, but not what is wrong. However, the third outcome provides additional information: An alternative is inadmissible, when its fitted parameters are outside admissible ranges, indicating that there is indeed a better model, but not among those tried so far. Since parameters are associated with certain model components, this gives information on what component to amend or replace. The residuals The residuals of a tentative model constitute another source of hints to what may be wrong. For instance, they may contain transients, either initially, or coinciding with large and rapid changes in other variables, or delayed such coincidences, or certain disturbance patterns, like drift or oscillations. Correlation measures are not displayed by default, since they tend to average out such transient errors, unless they occur frequently. In difficult cases it takes some experience to interpret the patterns, and occasionally this does not help either. No doubt, there are cases when it is wiser to suspend the calibration temporarily and instead put the effort into getting better data...

2 The MoCaVa solution

71

2.7.6 What Can Go Wrong? Since the designer of a program for black−box identification knows the model structure, it is conceivable in this case to make a program that is guaranteed always to produce a correct result, provided the assumptions about the model structure do hold. The only cases with guaranteed solutions are those that are linear in the parameters. Among nonlinear structures linearity in the parameters holds, for instance, for the Volterra type (Atherton, 1992), NARX (Nonlinear AutoRegressive with eXternal control) (Billings, 1980), and ‘semi−physical’ structures (Lindskog and Ljung, 1995), all with various shades of ‘blackness’. Not even linear black−box models are always safe in that respect. For instance, ARX models are linear in the parameters, while ARMAX models are not. MoCaVa has fewer restrictions on the model structure, but gives no guarantee always to solve the problem being setup by the user. However, in both the black−box and the grey−box cases the correctness of a result still hinges on the assumptions, which rarely hold exactly. This means that the responsibility for the model being produced still hangs on the model designer. Two things may generally go wrong: i) No model is produced, since the program cannot solve the problem, or ii) a model is produced that passes all tests, but it is still wrong, because the structural assumptions are wrong. The latter case is the serious one − the model is wrong, and one thinks it is right. Call it “pitfall”. MoCaVa has fewer assumptions, and therefore ought to reduce the risk of producing pitfalls. But what can go wrong when using MoCaVa? : The largest model class is too restricted. The risk is shared with all black−box cases, but should be smaller for MoCaVa, since the feasible classes are less restricted. The restrictions are partly inherent in the state−vector class in MoCaVa (see Section 2.1), and partly introduced by the user. A clear distinction is necessary here: The largest class is an assumption, and cannot be tested. The tentative classes (subclasses of the largest) are hypotheses, which are tested. Hence a too restricted largest class is a pitfall (it cannot be diagnosed by MoCaVa), while a too restricted tentative class is not. : The search routine does not converge properly. The construction of the search routine does not allow the search to increase the loss at any step. However, the search may reduce the loss very slowly and even cycle. When this happens there are three typical patterns of search, either i) taking too small steps in about the same direction, or ii) taking too long steps, only to step back about the same length in the opposite direction, or iii) overshooting so much that the loss will increase, again to step back, but then half−way in the same track. Since the negative gradient never points upwards, all the cases of slow convergence are caused by the fact that the loss function is generally not quadratic in the parameters (it may not even be convex), and hence the local value of the Hessian may say little about the curvature of the loss function when far from the minimum, and even less about the distance and direction to the minimum. In such cases the user may have to intervene by changing some of the design parameters of the search routine. Another cause of slow convergence is near singularity of the Hessian, generally caused by freeing too many parameters at a time. Evidently, there is always the possibility that several local minima may cause the search to converge to the wrong minimum. Trying different start values may reveal whether that is the case. The first default start values are the nominal values that are part of the specification of a component. However, when a minimum has been found in the first structure, the minimizing estimate becomes the start value for the next search in the expanded structure. This

72

Practical Grey−box Process Identification

helps to keep the search in the region of one and the same minimum. Experience from test cases has indicated that multiple minima is a practical problem only if the model structure is seriously wrong, or the expansion is done with too many free parameters at a time. However, there is no theoretical results to support the conjecture. The case is not a pitfall, except possibly when a local minimum has been reached and no alternative hypotheses are available to falsify the wrong model. Remark 2.48. Attempts to fit parameters in models with discontinuities in the parameter sensitivities have revealed the following typical pattern: In spite of the discontinuities in the model, the loss function remains a seemingly smooth function of the parameters. The search also quickly reaches the vicinity of the bottom, and often it even converges normally. Occasionally, however, the search has difficulties converging. When close to the optimum, the search may become chaotic taking small and inefficient steps. When the loss function derivatives are magnified, some of them display large numbers of small discontinuities, which accounts for the difficulties in taking short steps. An attempt to explanation of the peculiar behavior is the following: The loss function is a sum of a large number of functions of model residuals, all with continuous parameter sensitivities, except a few where the current state, the input variable and the parameter value happen to combine into a point close to a discontinuity. Since those terms in the sum are few, those with continuous sensitivities will dominate, and the effect will be seen only ‘through a magnifying glass’. The observation also suggests a solution: Augment the Newton−Raphson search with a new stopping rule, taking also loss changes into account. Remark 2.49. There are some observations (Bohlin, unpublished) from trying black−box identification using data collected in closed loop, which indicate that the smallest minimum is not necessarily the right minimum. An explanation would be that if the level of disturbance acting on the process is high, the smallest minimum may actually correspond to the negative inverse of the feedback path (since it contains less noise and is therefore easier to describe with small errors). There is no experience of using MoCaVa for identification in closed loop. However, the more specified the structure of the forward path becomes, the more difficulty should the search routine have in describing the inverse of the feedback path with a model of the same class. That should raise a possible wrong minimum, and conceivably above the right one. : The conditions for numerical differentiation are not satisfied. This is a consequence of allowing nonlinear structures and relying on user−specified scales to compute the argument increments. If scales are wrong by too many powers of ten, then rounding errors may cause erratic results. Numerical differentiation is used for linearizing the model locally as well as for computing the residuals’ parameter sensitivities. Errors in the latter are the more easily detected, since the search will not converge. Differentiation errors in sensitivity matrices mean that the actual model structure will be different from the one that was entered, but they may still constitute valid sensitivity matrices. The test will, in effect, evaluate another model. If the error is large, this should conceivably reject the model (since it will be contradicted by the data), and thus the error will not pass unnoticed. However, it will not be possible to distinguish this case from that of a wrong structural hypothesis. A user is therefore advised to be aware of the risk of numerical errors, and guard against them by confirming that a change in scale does not change the final model noticeably. : The conditions for the applicability of the EKF are not satisfied. It is required that linearization be acceptable around a nominal trajectory computed without feed-

2 The MoCaVa solution

73

back from the data sequence. This is a more severe requirement than generally holds for Extended Kalman Filters, where linearization is done around a state trajectory estimated from past data. The reason for the more restricted filter is that the nominal trajectory will remain stable independent of any outliers in the data. However, the requirement gets IdKit into difficulties in case of drifting disturbances, where even small levels of noise may cause the disturbed trajectory eventually to drift far from the nominal, and possibly out of the linear range. The user should therefore avoid entering drifting disturbances into strong nonlinearities (’Brownian motion’ is the only such disturbance in the library), and instead select a stationary disturbance model and put a bound on its unknown rms value, in order to prevent it from getting out of the linear range. Remark 2.50. A possibility to allow drifting disturbances, and still retain the stability of the reference trajectory has been analyzed by He (1991). However, it has not been implemented in MoCaVa3. : The conditions for the applicability of the stiff ODE solver are not satisfied. If sensitivity matrices would change considerably within a time quantum h, then the quasi−linearization operation the ODE solver is based on cannot be justified. Whether that has serious consequences or not can be investigated, for instance by checking the final model with half the time quantum. The loss value should not change by much more than one. : The conditions for the applicability of the ‘advanced’ options for optimization are not satisfied. The option of SensitivityUpdateControl involves approximations, based on the user’s prior specifications of what would be acceptable approximation errors. There are also a number of performance indicators displayed, to tell the user whether the approximations are reasonable. If the option would fail, that would most likely be because the dynamics of the model change so frequently that predicting transition matrices from one time instant to the next is meaningless. In particular, discontinuities in the model may cause this, but also too strong nonlinearities. However, a prediction failure will show up in the performance indicators (see Section 2.5.3), and the case is not a pitfall per se. However, another assumption may be: The indicators controlling the updating of sensitivity matrices are computed during the first pass in the search, and it is assumed that they will be applicable also throughout the search. This means that if a search carries the model parameters too far from their initial values, then it is conceivable that the indicators will no longer be adequate for the much changed dynamic properties. This is not detectable right out, since the performance indicators will also be wrong. If in doubt, the user may check this by initiating a second search with the same free parameters. This will start from the estimated values. If this converges immediately with only little change in parameter values, then approximations will be acceptable. There is always a possibility to deactivate the option in dubious cases, for instance to run a final search with the exact model overnight. : The balance between the models of object and environment is wrong. When it is difficult to find a physical explanation for the variation of a parameter, it is tempting either to assume a linear regression with any other variables that may possibly affect it, or else model the variation as a disturbance. Both have pitfalls, if used indiscriminantly. As stated in the introduction, it is easy for a predictor based on a stochastic model to predict well over a sampling interval, which yields a small loss, in particular if the sampling is dense or the process responds slowly. It is not unusual that the Brownian model alone, with the trivial predictor y(t k+1|t k) = y(t k),

74

Practical Grey−box Process Identification

predicts better than any deterministic model, which cannot base its prediction on previous output. Hence, as soon as a stochastic disturbance is introduced, the loss normally drops dramatically and the predictor plots look good (which increases the temptation). The variation in the data are responses to known as well as unknown input, described by deterministic and stochastic models respectively. The pitfall in a skew balance between the deterministic and stochastic parts in a model structure is that the search may allocate too much of the variation in the data to disturbances, since it is easier to predict that way, than by means of an underdeveloped deterministic model. Since the purpose of the modelling is normally not to predict the particular data sample, it is recommended that stochastic disturbances be introduced late, and preferably not before all possibilities of explaining a variation have been exhausted. On the other hand, the alternative ‘easy way’ of a regression model may lead into another pitfall: If the regression model has too many free parameters (which is clearly a risk if the number of variables are many), the result may be over−parametrization and spurious ‘dependencies’ discovered. Again the search tries to minimize the loss, and when given sufficiently many free parameters to use for that purpose it may succeed in establishing ‘relations’ that are merely data descriptions. In other words, too ‘forgiving’ deterministic models tend to include phenomena that are actually disturbances. Since stochastic disturbance models are easier to fit to random phenomena they have the salutary effect of reducing spurious regression. In conclusion: Introduce disturbances late, but do it eventually! Remark 2.51. No doubt, it would be desirable to have an objective method of deciding the right balance between deterministic and stochastic parts in a model structure, but, alas, MoCaVa3 does not have one. However, a number of guide−lines are given in the case studies in Part III. To the list of causes of failure may be added that the freedom to specify argument relations and attributes may introduce ordinary programming errors. MoCaVa3 has an option for using the debugging facilities in MATLABX for detecting errors in the user’s components, before subjecting them to fitting and testing.

3

Preparations

3.1 Getting Started 3.1.1 System Requirements The following are the minimum requirements for running MoCaVa, but later and faster configurations are preferable: : Intel Pentium III 500MHz : > 64 Mb RAM : > 100 Mb Hard Disk space : Screen resolution at least 1024*768 : Microsoft WindowsX 95, 98, NT, 2000, or XP : Matworks MATLABX 5.3 or later Remark 3.1. All combinations have not been tested, which might cause difficulties in some cases. Neither WindowsX nor MATLABX are fully backwards compatible. 3.1.2 Downloading Go to internet address www.springer.com/1−84628−402−3. Under “Related links” click on “Download Supplementary Files Here”. Then click on “here” to download MoCaVa−3.2_setup.exe. Alternatively, go to http://mocava.s3.kth.se and click Download on the MoCaVa home page. Then click on MoCaVa−3.2_setup.exe and save the file. 3.1.3 Installation Run MoCaVa−3.2_setup.exe, for instance by double−clicking on the icon. This will start the installation. Click Next twice. The program will open a window to enter the Destination Folder. Type the full path to the MATLABX toolbox directory. Alternatively, click the button marked “...” to open a browser and locate toolbox. Then click Finish. MoCaVa3 will then be installed automatically in a new MoCaVa3 directory under the MATLABX toolbox directory. Some files will also be installed in the toolbox\local directory. 3.1.4 Starting MoCaVa  Start MATLABX and type mocava3 in the command window.  MoCaVa opens a window for accepting some legal terms for the use of MoCaVa.

78

Practical Grey−box Process Identification

 Click I accept the conditions for using MoCaVa.  MoCaVa opens the MoCaVa window for selecting one of the Predat, Calibrate, Validate, or Simulate sessions. 3.1.5 The HTML User’s Manual The contents of Part II are available in more detail in hyper−text format in MoCaVa3\HTML_doc\UserManual. The manual also describes the Validate and Simulate sessions in MoCaVa, which are not treated in this book.

3.2 The ‘Raw’ Data File Data must be in an ASCII file and contain records as follows: : Any headlines must have been removed. : All records must contain the same number of fields separated by blanks or tab stops. : One of the fields may contain physical time, which need not be equally spaced, but must be multiples of a smallest sampling interval. This means that the time variable must be increasing, and never reset like a clock reading at midnight. : Fields with missing data must be marked with NaN or inf. This means that some data columns will contain NaN frequently, if they are sampled more sparsely than others. : If no time variable is icluded, this will be interpreted as sampling with constant interval for the variable with the densest sampling (other must therefore have NaN).

3.3 Making a Data File for MoCaVa  Select Predat and New data file in the MoCaVa window (Figure 3.1). The alternative Modify data file is for changing the specifications, for instance scales, in a previously prepared file.

Figure 3.1. Starting data preparation

 MoCaVa opens the Predat control window (Figure 3.2). It contains some tools for editing data files. Only the Main tab will be used in this tutorial.  Click on Get data file.  MoCaVa opens a browser window (Figure 3.3).

3 Preparations

Figure 3.2. Predat control window

Figure 3.3. Browser window showing defined projects

79

80

Practical Grey−box Process Identification

Figure 3.4. DrumBoiler data directory

It contains directories of all projects that are currently defined, so far only the demo projects. One of them is DrumBoiler, the one to be demonstrated first.  Find the directory holding the response data file(s). After getting the data from an independent source (like a data retrieval or simulation program) it is natural to move the data file into the directory of the project that will use it (for instance, that would package all that is needed in a single directory for easy backup or export). However, since the same data may be used for different projects, as well as several data files used for the same project, the data preparation in MoCaVa is in fact independent of the project that will use it. Hence, the location of the data file may or may not be in the directory of any project. In the present demo case it resides in mocava3\Examples\DrumBoiler (Figure 3.4). The directory contains two ASCII data files containing data generated by the ‘true’ model. However, record #5 has been deleted from Dboil, and two entries in record #2 and #3 have been replaced with NaN, in order to simulate the effect of missing data.  Open Dboil, for instance by double−clicking on Dboil (or by selecting Dboil and clicking Öppna − the Swedish is due to WindowsX).  MoCaVa opens two windows: The Plot Outline (Figure 3.5) showing a graph of the data in the file, and the Data Outline for editing the data in the file.  Indicate that time is in the first column in the data file and select its unit. Enter also names for the variables and their scales, if other than default. Notice that variable names must not contain spaces. After editing, the Data Outline window will look as in Figure 3.6.  Click Apply Now in the Data Outline window, and then Save in the Predat control window.  MoCaVa opens a browser window to store the prepared data (Figure 3.7). Give the file the same name but extension mcv, and place it in an arbitrary directory, in this case the same.  Click Exit predat in the Predat control window. This concludes the data preparation in a case where no outlier removal is necessary. The new file contains the variable names and some data statistics in addition to the data. Remark 3.2. For instructions on how to remove outliers, see the CardBoard case in Section 7.3.  Repeat the preparation for the second data file.

3 Preparations

Figure 3.5. Raw data for DrumBoiler

81

82

Practical Grey−box Process Identification

Figure 3.6. Window for editing DrumBoiler data

Figure 3.7. Window for storing prepared data

4

Calibration

This and the following chapter use two simple examples to introduce the concepts and communication windows needed to run MoCaVa. The first example DrumBoiler demonstrates the calibration of a simulated two−input two−output bilinear model. The second example CascadeControl illustrates the modelling of a nonlinear feedback system involving an ‘algebraic loop’. The drum boiler model has been developed and used on many occasions. The following is quoted from Sørlie (1996a): “The process ... is based on a simplified model of a power plant, originally developed by Eklund (1970); c.f. (Åström and Eklund, 1972, 1975). Later, Ekstam and Smed (1987) augmented a model with a reheater cycle, adding a second state. The result is a set of bilinear state and output equations. Through the inclusion of physically motivated state disturbances and output measurement errors, the example demonstrates the minimal complexity of the three−block functional decomposition devised in IdKit (Graebe, 1990a)”. The purpose of calibration is to find the simplest model that i) is consistent with the user’s prior knowledge and ii) is not falsified by response data.  Start the calibration session by selecting Calibrate in the MoCaVa window (Figure 4.1)

Figure 4.1. Starting Calibrate

4.1 Creating a New Project  MoCaVa opens the Select project window (Figure 4.2) for input. The project directory mocava3\mcvprojects contains four cases for demonstration purposes.  Click on DrumBoiler to select the project.  The name of the selected project appears in the header (Figure 4.3). If the DrumBoiler case had not been created already, it would have been necessary to do the following: Click on New Project. This opens a window for naming the

84

Practical Grey−box Process Identification

Figure 4.2. Window for selecting project

Figure 4.3. Selecting project

project (Figure 4.4). Enter the name DrumBoiler and click OK. This creates a project directory mocava3\mcvprojects\DrumBoiler for storing all information

4 Calibration

85

Figure 4.4. Naming a new project

that is particular to the project, and adds the project name to the list of defined projects in the window. When a project has been selected, it can be deleted, copied, or opened for processing. It is also possible to use the Microsoft Explorer for deleting, copying, or backup.  Click Open to start the project.  MoCaVa will first set up five permanent windows for communication with the user: : The Main window will receive user input and display intermediate results and messages from the user’s guide. : The Plot window will display the results of simulations of the current model. : The Model window will display a block diagram of the current model class. : The Pilot window will display the position of the latest executed subtask in the current session. : The MoCaVa window controls the execution. Any of the other windows may be shut off from under the View tab in the MoCaVa window.

4.2 The User’s Guide and the Pilot Window Basically, MoCaVa consists of a number of independently executable script files (in MoCaVa3\Source\Commands) for the various tasks that have to be handled in a calibration session, but employs a special user’s shell (in MoCaVa3\Source\MoCaVa\calibrate5) to run the tasks according to a procedure of ‘proper calibration’. The shell serves to control that scripts are executed in a logically correct order and input arguments are set properly. However, the sequence is not fixed; there are a number of decision points, where the user may control what will be done next, or has an opportunity to acknowledge or overrule the proposals of the user’s guide. Communication windows have a number of ‘decision’ buttons, the clicking of which will determine the sequel.  MoCaVa displays the User’s guide in the Pilot window (Figure 4.5). It lists the names of the scripts and the conditions under which they are executed. It also highlights the script executed last (except at start−up, when it highlights the first script). Each time a task has been completed, the position changes to the next logical step. Only places where the user can make a decision will normally be highlighted. The numbered lines show the names of the scripts, those marked with > are comments, and the other lines are the conditions. Each script can also be executed independently by simply typing its name in the MATLABX command window. This allows an experienced user to run MoCaVa also in a ‘command mode’, and thus to accept the responsibility that this is done in a logically correct order, and that all input are set properly. However, because it is expected to be difficult to interpret the outcome of executing a script, when some input has not been set or updated properly, even an experienced user is recommended not to use this option in other than simple cases.

86

Practical Grey−box Process Identification

Figure 4.5. The Pilot Window

The Pilot window is also useful when the user wants to suspend a session temporarily and resume afterwards, or regrets a decision and wants to step back.

4.3 Specifying the Data Sample  At first start of the Calibrate session (or after Reset) MoCaVa opens a browser to select the data file used for the calibration (Figure 4.6). The default directory will be mocava3\Examples.  Change the directory to where the prepared data were placed, i.e., mocava3\Examples\DrumBoiler (Figure 4.7). Open the dboil.mcv file. 4.3.1 The Time Range Window  MoCaVa sets up the first user’s entry point in Main window (Figure 4.8). It requires specification of what segment of the data file to be used for calibration (if not all). Default values are the following:

4 Calibration

Figure 4.6. Directory for data used for demo and case studies

Figure 4.7. Selecting data file for calibration

Figure 4.8. Specifying sample

: : : :

Time quantum: The smallest interval between sampling times. Start time: The time of the first record minus one quantum. Stop time: The sampling time of the last record. Time scale: The scale specified in Predat.

87

88

Practical Grey−box Process Identification

 Click OK to accept the default values. Help: Time range window Edit the numbers in order to specify the calibration sample as a segment or all of the data file: : Time quantum is the constant time increment used in the stepwise integration of the ODE defining the model. It should be as large as possible to make computing efficient. It is limited by the (shortest) sampling interval. Since IdKit accepts ‘stiff’ ODE, the time quantum does not have to be shorter than the fastest time constant in the model, i.e., the rate at which the states may change. Instead, it is limited by the rate at which time constants may change (”time constants” are the inverses of the eigenvalues of the state−to−derivative transfer matrix). If the time quantum is smaller than the sampling interval, it must be an integer part of it (1/2,1/3,...). : Start time is the time at which states are to be initialized. This determines the first data record in the sample, as the first one that follows the start time. The default start time is therefore one default time quantum before the time in the first data record. : Stop time determines the end of the sample. : Time scale determines the interval between tick marks in plots. The time unit of all entries is the same as that in the time variable in the data records. Hints

: Whenever the specifications differ from the default values some statistics of the sample will be displayed.

: If you are uncertain of whether you can use the whole sampling interval as time

quantum, make a test by halving it and see if the model responses change noticeably. : You may specify a start time well before that of the first data record. The option is useful when the data were recorded in steady state, and it is difficult to specify prior values for the states. In that case you may use the model for determining a steady state, by running it past the transient phase, before comparing its output with the data.

4.4 Creating a Model Component After the sample specification MoCaVa requires specification of a model class. It consists of a set of connected components (or a single component) corresponding to different parts or phenomena of the physical object to be modelled. Components are ordered according to cause−and−effect relationships. The set is built progressively, as the calibration process proceeds, by appending components of more parts or phenomena, as need be. The DrumBoiler example will have four components at most. Preferably, the first component should describe only well known phenomena in the object (so that it need not be changed later).  MoCaVa opens the Component naming window (Figure 4.9) for the user to give the first component a name of alpha−numeric characters without blanks. (From now on, the screen images will be cropped to show only the relevant parts)  Enter DrumBoiler and click OK. (If you need to do an extra click, you did not press Enter).

4 Calibration

89

Figure 4.9. Naming a new component

Figure 4.10. Selecting a component for editing

4.4.1 Handling the Component Library  MoCaVa opens the Component library window (Figure 4.10).  The DrumBoiler component is empty. Mark it for Change and click OK. Help: Component Library Window It shows the list of defined components. : Select Retain for components to be unchanged. : Select Change to open an existing component for modification or define a new one. : Select Delete to remove a component from the library index. : Select Insert to add a new component to the library index. Its position in the list will be on the line after the Insert. Click OK after selection. Alternatively, click User lib to define or modify a user function. A “user function” is a static or dynamic function common to several components in the project. Hints A component (with the exception of the top component) is always associated with one or more components that receive its Signal output. It must therefore be executed before all receiving components. MoCaVa executes active components from the bottom to the top of the list of components. A new component should therefore be placed below all its target components. The placement of the components in the list thus defines the causality between variables. Unlike in some simulation programs causality is not determined automatically from the mathematical structure of the total system, but instead regarded as prior information, to be entered in this manner. In addition to simplifying the implementation, this also, and more importantly, removes the otherwise necessary fitting and testing of a number of mathematically feasible but physically impossible combinations of components. Since causality usually follows from the construction of the process to be modelled, it would be a waste not to use this prior information.

90

Practical Grey−box Process Identification

Components are connected automatically based on the names of their output; each output variable is connected to all input with the same name. Activating a component causes the otherwise constant input of its target(s) to be replaced with the component output signal(s), when the model is executed. Thus, a component may connect to several targets, and may receive input from several sources. Since the arrangement of components in the list determines the (reversed) order of execution, it is possible to connect signals only to components placed higher in the list. Any connections in the opposite direction (downwards in the list) are established through the state variables, again automatically by their names. This means that, basically, systems involving dynamic feedback loops can be modelled using components inside the loop, but those having algebraic loops cannot. The reason is that states do not depend directly on the input, but will first have to pass an integrator (the ODE solver), before their values affect the next execution of the component sequence. If other component output with a direct dependence on the input were fed back, that would create an algebraic loop, and it would require iteration over the component sequence to resolve such loops. However, MoCaVa provides a way out for such algebraic loops that can be approximated with ‘fast’ state−equations. Hence, it is still admissible to feed back component output with direct dependence on input. Any algebraic loop created in this way will introduce implicit states with time constants fast enough to reach steady state within one time quantum. This creates a ‘stiff’ ODE which is resolved by the integrator in IdKit. Notice again, that an algebraic loop within a component is not allowed. Since component equations are defined by assignment statements and not by equations, it is not possible to write such a component. The top component may execute alone. Other components may execute as long as all their target components are active. It is possible to write the whole model as a single component. However, if the prior knowledge of parts of the object is uncertain, it is convenient to place the uncertainties in separate components. The advantage of this is that the model may be changed easily (by making another component active) in order to try several alternatives for a physical phenomenon or sub−unit with uncertain description. This also takes care of the housekeeping of the large number of alternatives that may play a part in the calibration session. Creating the components may require some thinking and key strokes, but may then, by combination, generate many more model classes, and it is the handling of the latter that is automated as far as possible. The calibration session works by a series of expansions and tests of tentative model classes and structures (see the Pilot window). The ‘root’ model class is the one that is tried first, and should preferably remain unchanged during the calibration session. It contains the top component, and possibly other components. It should therefore contain only relations that can be trusted a priori, like those based on conservation laws. If the ‘root’ model class needs to be expanded in order to describe the sample data adequately, this is done by augmenting more components. 4.4.2 Entering Component Statements  MoCaVa opens the Component function window (Figure 4.11). The window expects state equations and algebraic equations describing the component in the form of a subset of MATLABX M−file statements.  Click OK to close the window.

4 Calibration

91

Figure 4.11. Window for editing state equations

Figure 4.12. Window for editing start conditions

 If the function is dynamic, i.e., there are state variables, MoCaVa opens a second function window for specifying initialization of the state variables (Figure 4.12). The simplest initialization model is to assign constant values to the states. Notice that component functions may use for statements to generate variable array indices. This makes it possible to write models that process arrays.  Click OK. Help: Component Function Window Enter known or hypothesized relations between arbitrary named arguments using a subset of MATLABX M−statements. The following restrictions apply: : Statements may contain elementary algebraic, for, if, else, elseif, and end statements, and the transcendental functions: sin, cos, tan, asin, acos, atan, exp, log, log10, sqrt. For−loop ranges may be either numbers or have symbolic names (but not expressions). : The statements may contain calls to user−defined functions with the same syntax as in M−files, i.e., [out1,out2,...] = MyFunction(in1,in2,...) The brackets [] must be present, even with a single output. : The statements may involve only scalar arguments or explicitly indexed vector elements, for instance inletpressure(i). Arguments must not contain underscores (_). : Comment lines (with % in the first position), blank lines, and continuation symbols (...) ending lines are allowed. Statements do not have to end with semi−colons. : There is a single addition to the MATLABX statements: A time−differentiation operator D to be placed as prefix to a state variable. Hints Notice that x^2 and x^y would be illegal. They must be written as the equivalent expressions x*x and exp(y*log(x)).

92

Practical Grey−box Process Identification

Vectors can be manipulated using for statements. It is also feasible to handle matrices, even if not as convenient as in MATLABX. For instance, a linear state−vector model dx/dt = Ax + Bu may look like this: % Linear state−vector model: for i = 1:n Dx(i) = 0 for j = 1:n ij = i*n + j − n Dx(i) = Dx(i) + A(ij) * x(j) end for j = 1:m ij = i*m + j − m Dx(i) = Dx(i) + B(ij) * u(j) end end

Avoid writing iterative loops in a function definition. The result of fitting a model whose response depends on a variable number of iterations is unpredictable. In order to prevent iterative loops the while statement has been excluded. Do not try and outsmart this restriction, for instance by manipulating the for−loop index or range, or by using an if statement with a condition that depends on some error criterion to terminate the loop. Because of the different syntaxes of the MATLABX elseif and the C else if statements, complex conditional statements involving elseif are somewhat hazardous. Preferably, stick to if and else. MATLABX and C will also interpret expressions involving integers differently. For instance C evaluates the expression 1/2 to an integer, which is 0. The ratio must therefore be written 1./2. to mark that the result should be a real number. 4.4.3 Classifying Arguments  MoCaVa opens a number of windows to allow the user to enter further qualifications and prior information about the object. The first one is the Argument classification window (Figure 4.13). It requests a classification of the arguments defined in the function, according to the rôles they will have in a simulation of the model: : E and P are the dependent variables of interest outside the component. Select Response. : K1, K2, K3, A1, A2, A3 are known constants. Select Constant. : f is fuel flow, i.e., an input variable whose value is determined externally. Select Feed. : u is control valve position, again determined externally. Select Control. : TD, TR, A4, and initstate are constants, whose values are uncertain and possible candidates for estimation. Select Parameter. : distE and distP are unknown input, either constant or varying. Classify them tentatively as Parameter, since it might be enough to have non−varying disturbances in the model.  Click OK.

4 Calibration

93

Figure 4.13. Classifying component arguments

Help: Argument Classification Window Specify the class of each one of the listed arguments in the component. The class determines how the argument is to be interpreted by the calibration and validation programs. There are four classes of component output: : State derivatives: Time derivatives of states. Their classification is determined automatically from context and not changeable from this window. : Signals: Variables that will be input to other, downstream components. They are classified automatically. : Responses: Output that are of interest outside the component, but are not Signals. They may be connected to sensors (through a library function), or fed back to upstream component(s), or just used for display. : Internal: Auxiliary arguments that are used in the statements defining the component functions, but whose values are not of interest outside the component. There are nine classes of component input: : States: Arguments whose values are predicted from the previous call. Their classification is determined automatically and not changeable from this window. : Feedback: Arguments whose values are Responses of downstream components. They are classified automatically. : Parameters: Arguments that are basically independent of time but may change between passes. Some or all may be subject to fitting. Alternatively, they function as

94

Practical Grey−box Process Identification

targets for the output of other components, and can in this way be made to vary with time, when a constant value has turned out to be inadequate. : Control and Feed are known input to the component, whose values are determined by a source model. The latter may be another component, or else a standard routine converting input from a data file. Control and Feed differ in three ways: 1) In their physical interpretations: Control input model known input (with negligible error), typically set points from digital controllers. Feed input model other input from known sources, typically other units or components. The corresponding data (if any) may have measurement errors. 2) In their conversion of input data: This is done by selecting from a menu of standard library functions for interpolation between discrete−time data. The admissible models for Control and Feed differ, in order to adapt to the different properties of the expected data sequences. In particular, Feed may need to filter input data. 3) In the way the graph of connected components is laid out: When the source is another component the Feed terminals are placed on the right side, and the Control terminals on the bottom side of the (target) component. Control and Feed input without a source (data or active component) are treated as Parameters. : Disturbance: Arguments whose values are generated by library models of stochastic processes. : Constants: Arguments that are constant in time and may not be subject to fitting. The difference between Constants and such Parameters that are not fitted, is that Constants will not appear in lists of parameters displayed to the user. The only way to change their values is to modify the component definition. Constants may be used as targets, in the same way as Parameters, Feed, and Control. : Time and Start time: Arguments to be interpreted as physical time. Time arguments appear only in a component whose behavior depends on a clock reading. Time is synchronized to the time variable in the data file. Clicking Cancel takes you back to the window specifying the component equations. This is the typical response when you find a variable in the list that is a misspelling, or which you do not think should be there for some other reason. Hints The argument classification can be used to model the object in a way that suits physical intuition and makes the graph of the system of connected components look familiar to process engineers: : The Feed classification is used mainly to visualize the operation of industrial production processes, consisting of separate units, each one accepting flows of commodities from other units, modifying their properties, and feeding the result to the next unit(s). In this interpretation, a component models a physical unit. In the graph any Feed input enters the component from the right. : The Control classification is useful for such variables that affect the operation of the component. In the graph any Control input enters the component from below. : When a Parameter input to a component is connected to the Signal output of another component, this is visualized by placing the source component inside the target. In this interpretation a component is a sub−model describing an internal physical phenomenon, that may or may not be important for the modelling. Finding this out is done by testing whether a constant parameter value (Dormant sub−model) will do almost as well as the (Active) sub−model in describing the model response.

4 Calibration

95

Figure 4.14. Specifying I/O interfaces

: Constants are typically established physical data, their values obtained from hand-

books, or fixed attributes of the object, like volumes. They may also be used to create ‘stubs’, i.e., points where to enter modifications of the model. Thus, adding a zero constant, or multiplying with a unit constant, creates such stubs. Making a component for a modifying sub−model and connecting it to the stub is a way to refine the model class without having to change any other component. Note: Library functions may use one more class of input and output arguments, namely discrete−timestates. They are transparent to the user, but needed for describing the conversions between discrete and continuous−time variables. 4.4.4 Specifying I/O Interfaces

 MoCaVa opens the I/O interface window (Figure 4.14). It handles the specification of three kinds of interfaces to external variables, including conversion functions, when needed: : Connections to sensors: This causes the inclusion of a library routine defining the transition from continuous variables to sampled data. The user is asked whether or not the variables have sampling sensors attached to them. The option applies to arguments classified as State, Response, Feed, or Disturbance. : Source models: This causes the inclusion of source models generating continuous input from a library routine interpolating between the discrete−time data, in order to define the values of the continuous−time input between the sample points. The user may choose between a number of interpolators, or else indicate that the input will be generated by another component. : Disturbance: This causes the inclusion of library ‘environment’ models. The user must choose between a number of standard models for generating random input with different characteristics. Notice that it is possible to have a sensor attached to a Feed input, thus making it an output of the model. That is in agreement with the actual circumstances when the actual process input has been logged by the computer producing the data file, regardless of whether the source is an external process, or whether the input signal is generated inside the computer and then passed through an actuator before its values are logged.

96

Practical Grey−box Process Identification

Hence, if the actuator is not ideal, it makes sense to have both an interpolator and an sensor attached to the same process input. Using the option of assigning sensors to the Feed input may be useful in cases were there is no reliable information about the source of the input, except that the values have been recorded, probably with measurement errors, and possibly irregularly. In the DrumBoiler case, however, the input is known without measurement errors (it is assumed to have been issued by a control computer). The obvious choice of interface would therefore be the Hold model. In a case where the interpolation routine is not as clear−cut, it is usually better not to choose any of the library functions at this point, but instead let the sources of Feed and Control be modelled by separate components. The point is that this makes it easy to change interpolation rule, without also having to change the root model. In order to illustrate this (even if it would not be needed in the present case), select User model for input f and u. Select Sensor for output E and P.  Click OK to accept the selection. Help: I/O Interface Window This window handles the interfaces with one of three types of variables external to the component: : Filed data. : ’Noise’ sequences from a random number generator. : Signals from other components. The first two require specifications of how to do the conversion between the different types of variables. The third type obviously does not need conversion, and neither does it necessarily need a source component to be connected (if not, it will be treated as Parameter and assigned its nominal value). Conversion specifications (if any) are requested for arguments with the following classifications: : State, Response, Feed, and Disturbance allow inclusion into the component of a sensor model sampling the continuous−time values in the model. There are two options, Sensor and NoSensor; the choice depends on whether or not there is a corresponding variable in the sample file, that one wants to use for prediction and/or fitting. : Feed input allows inclusion of selected routines describing relations between filed discrete−time data and the continuous−time input to the model. There are six options, either for interpolating or filtering data in the sample file, or else indicating that the input is to be a signal from another component. : Control input allows inclusion of selected routines describing relations between filed discrete−time data and the continuous−time input to the model. There are four options, either for interpolating between data in the sample file, or else indicating that the input is to be a signal from another component. : Disturbance input allows inclusion of stochastic models for the environment. There are three alternatives. The choice depends on the general character of the disturbance. Notice that the conversion function is basically a part of the component. However, even if the source of a component input is a data file, it may be better not to include a conversion function. Instead, it is possible to select User model, and then create a separate component to do the conversion. Since it is generally not evident how to interpolate between discrete data, in particular if the latter are also contaminated by measure-

4 Calibration

97

ment errors, it may be necessary to try several interpolators. Placing them in separate components makes it convenient to try alternative input conversions. The following are some comments on the definitions and properties of the standard routines for conversion between variables and data. They implement the algorithms in Section A.9. Output Conversion Functions The Sensor model samples variables with classes State, Response, Feed, or Disturbance with an interval equal to the time quantum, and adds a Gaussian random error. In case the data is sampled with a lower frequency, or some data points are missing, the sensor output will be ignored. Notice that also Disturbance and Feed input may have sensors. Both Feed and Disturbance are naturally regarded as input to the object of the modelling. However, they are also (continuous−time) output of the component, since the latter includes descriptions of input conversion (by library functions). The corresponding input to the component are discrete−time filed data and random numbers. The option of modelling input sensors provides a solution to the well−known problem of ‘input noise’: An estimate of the ‘true’ input is generated by a standard input filter fed with the noisy data, and then a Sensor function attached to the filter output provides a coupling to the same noisy data, which allows estimation of the filter parameters as well as a check of whether the right input filter has been selected. (If you dislike the idea of using the same data twice, you may classify the unknown ‘true’ input as Disturbance instead. This would be logically correct, since the input is in fact unknown. However, it is reasonable to expect that a stochastic disturbance model would not perform better, since it does not use any information in the data, in particular the presence of large transients. It will also make the calibration more time consuming. When in doubt, you can always try both ways). See Section 2.3.5 for further discussion on the subject. Data Input Conversion Functions The Hold model makes a stepwise constant function from the data values, continuous to the right. The FirstOrder model outputs the response to a first−order linear model with unit low−frequency gain and stepwise input. It is a reasonable choice when the response time of a stepwise driven actuator is unknown. The SecOrder model outputs the response to a second−order linear model with unit low−frequency gain and stepwise input. It is a reasonable choice when the actuator may overshoot or its step response has a continuous derivative. The Linear model makes a linear interpolation between the data values. The Delay model is an approximation of a delay function with a (possibly unknown) delay time, which need not be an integer number of the time quantum. The response is exact for ramp input, and a good approximation for processes with long response times. The LPFilter applies a first−order linear digital filter to the data, and then makes a continuous−to−the−right stepwise constant function from the filtered values. It is useful for suppressing input measurement errors. The NLFilter model is designed to eliminate a drawback with the linear filter, namely its tendency to respond slowly to large step changes, when the measurement error level is high and therefore calls for a long time constant of a linear filter. The nonlinear filter uses a nonlinear gain function to reduce the response only to changes below the noise level (instead of the constant ‘smoothing’ of the linear filter). Thus it provides

98

Practical Grey−box Process Identification

a faster response to changes above the noise level, while preserving the noise−filtering effect of the linear filter. Disturbance Functions In order to select a model for disturbances it helps to have at least an idea of the general character of the actual physical disturbance. If nothing is known about its source, and no plot is available, one may have to try several models. Try first the simplest model, the Brownian, and take a look at the estimated disturbance that results from simulating the model. This may reveal if the disturbance has any of the general characteristics assumed by the alternative library models. The Brownian model accumulates Gaussian random numbers, and makes a linear interpolation between the discrete values to create a continuous−time approximation of ‘Brownian motion’. It has one characteristic parameter, the ‘average drift rate’. Its general appearance is random drift with no given direction and no attraction to a ‘zero level’. It is a very robust disturbance, behaving reasonable well for most irregular, low−frequency variation, including infrequent and large random steps. The Lowpass model makes a step−wise constant function from Gaussian random numbers and then applies a first−order linear filter. The result varies randomly around zero, and has little power in frequencies above its bandwidth. It has two characteristic parameters, namely ‘bandwidth’ and ‘rms−value’. It is suitable for modelling low−frequency disturbances with the same general appearance throughout the sample, without a pronounced periodicity. The Bandpass model makes a step−wise constant function from Gaussian random numbers and then applies a second−order linear filter with a pair of complex poles. It has three characteristic parameters, namely ‘rms−value’, ‘frequency’, and ‘bandwidth’. Its general appearance is random variation with a dominating frequency, more or less pronounced. The dominating frequency must be well below the Nyquist frequency. It is suitable for modelling waves, effects of slow and poorly damped control loops, limit cycles, clock−depending environmental effects, and possibly vibrations, if the time quantum can be made small enough. Note: Functions using only discrete−time state variables are less costly than those using continuous−time state variables. Thus the LPFilter and NLFilter take less computing than for instance the Linear interpolation. The reason is that continuous−time states add to the overall order of the model, which affects the computing time approximately by the second power of the order. Note: There is no ‘white−noise’ model in the library. The only way to model high− frequency disturbances into a component is to use the Lowpass model with a bandwidth well above the relevant time constants in the component. The ‘no−white−noise’ restriction is introduced to prevent unexpected consequences of feeding white noise into a non−linear model. 4.4.5 Specifying Argument Attributes  MoCaVa opens the Argument attributes window (Figure 4.15).  This window is one of the main entry points of the user’s prior information (together with the Component function window). If possible, replace the default values with better ones. : The nominal values for the input f and u have been set to approximate the sample averages. Nominal values for the rms values are much larger than the expected measurement error. The reason for this initial guess is that it anticipates that the first

4 Calibration

99

Figure 4.15. Editing argument attributes

model structure is wrong, and that therefore the total model error will be much larger than the measurement error. : The start value initstate has been given an implicit nominal value initstate, since it is a vector, while scaleE and scaleP are implicit because they are common to several arguments. : The simple expressions for scales and nominal values of the rms values derive from the Sensor library function. The unit factors specify that both the scales and the nominal values equal the scales of the measured variables. They may be edited to lower values. : The Min and Max values specify that all physical parameters have positive values, and that A4 is limited to the range (0,1). : The only arguments not created in the Component function window are rms_E and rms_P. They originate in the Sensor library function. After editing, the window for the DrumBoiler component should look as in Figure 4.15.

100

Practical Grey−box Process Identification

Figure 4.16. Specifying implicit attributes

 Click OK to accept the values in the table. Help: Argument Attributes Window This window is one of the main entry points of user prior information (together with the function window). If possible, replace the default values with better ones: : Short description will be appended to the name of the argument in most communication with the user. The text string may include spaces. : Dim is the dimension of the array. Dimensions are either editable or un−editable. Editable vales must agree with the dimensions implicit in the component definition. Un−editable values either correspond to scalars, or else means that the dimensions of the arguments have been set in previously defined components. : Scale is mainly used for setting error levels in numerical approximations. It also determines the default scale in plots. Scales of Parameters have a third use: they are instrumental in setting the likely range of search for parameter estimates (prior probability distribution in the Maximum Aposteriori Probability criterion, Section 2.4.1.2). : Nominal values of parameters determine the start values in a potential search, and the values of known parameters and constants. : Min and Max values set ranges of admissible values (optional). Scales and nominal values may be specified implicitly by entering simple expressions of one of the forms a, b*a, label, label*a, or label(i)*a where a and b are numbers, i is an integer number, and label is the symbolic name of an array of constants, its values to be defined later. Implicit attributes are useful when several variables have the same scale, and are necessary when an argument is an array whose elements have different scales or nominal values. Simple expressions are useful when different arguments have strong and obvious physical relations. 4.4.6 Specifying Implicit Attributes  MoCaVa opens the Implicit attributes window for entering numerical values (Figure 4.16).  The initial state is unknown, try zeroes.  Click OK. 4.4.7 Assigning Data  MoCaVa opens the Data assignment window (Figure 4.17).  Pull down the menu of variables in the data file to find those that correspond to the model variables.

4 Calibration

101

Figure 4.17. Assigning data

The units of logged data often differ from those used in the model of the process proper. Therefore, and in order to eliminate errors caused by confusion of units, it is generally a good idea to use scale converting factors at this point: data = Factor * model output. When a model variable is a vector, then data for all entries in the vector must be stored in consecutive columns. In that case the first of the columns should be selected. The same factor will also be valid for all entries in the vector. In the present case there is no units conversion.  Click OK. This ends the definition of the DrumBoiler component.

4.5 Specifying Model Class  MoCaVa opens the Model class specification window (Figure 4.18).

Figure 4.18. Specifying model class

It shows a list of defined components, so far consisting of a single item. A tentative model class is specified by making a selection of components as either Active or Dormant. Selecting Show and clicking OK will display the component statements.  Click Graph.  MoCaVa draws a block diagram in the Model window of the current tentative model class, so far consisting of a single box (Figure 4.19). The boxes show only the input and output arguments involved, their classification, and, in graphs with more components also their connections to other boxes. Output are listed to the left and input to the right. Help: Model Class Specification Window A tentative model class is defined by the following items: 1) A number of component definition directories (in casedir\Clib). 2) A system definition file (casedir\activity), indicating which components that are currently selected. The latter is set through this window: Mark the components of your choice to become Active, and the other Dormant. The components will connect automatically.

102

Practical Grey−box Process Identification

Figure 4.19. Trivial graph of a single component

Selecting Show for one or more components (and clicking OK) will display the statements defining them in a separate window. This window stays until it is closed manually. The decision buttons indicate a number of logical ways to proceed: : OK will accept the model class as the tentative class and proceed to fitting and falsification. : Simulate is a less bold decision. It causes the predictor defined by the model class with nominal parameter values to be simulated, and the predictions to be compared with the data sample. : Graph will generate and display the graph corresponding to the current selection of active components. It is useful for checking the connections in a model class consisting of several components. : Edit will open the Component library window for defining new components or changing or deleting old ones. : Advanced will open a window for activating a number of tools for enhancing the processing speed in cases of large models, bypassing some of the default user’s check points, changing the time quantum, or debugging the user model. : Suspend will suspend the session temporarily and return control to the MoCaVa window. You must also click Exit in the latter window to return to the MATLABX command window. Restarting Calibrate will open a window where the user may choose between Resume and Reset (see Section 4.19). Hints The graph (in the Model window) shows a block diagram of the current tentative model class. The boxes show only the input and output arguments involved, their classification, and their connections to other boxes. The colours of the argument names indicate the class (on the colour screen), and arrows indicate connections to other boxes or to the data file. The convention for positioning the blocks is that Feed input enter from the right, while Control input enter from below. The graph is laid out to support the modelling of industrial production processes, comprising chains of units modifying the properties of input commodities and feeding the product to the next unit. Boxes within another box connect to parameters of the receiving box and indicates a refinement of that box; the constant parameters have been replaced by the output of the boxes inside. A new graph will be created whenever there is a change in a component or activity status.

4 Calibration

103

Figure 4.20. Editing parameter origin

The graph is constructed automatically from the model class specifications (as opposed to the case in SimulinkX). This means that in more complicated cases a box may overlay some connecting lines between other boxes. One can see this by the fact that the box has no terminal (arrow head) at places where connections disappear under the box and reappears on the other side. Notice that the terminals are either input or output. If you do not want to see a new graph all the time (and wants to save some time in complicated cases), click Advanced and have the display suppressed.

4.6 Simulating A cautious user will try out a new component, before building a complete system from this and other components. That is possible to do, since all input have been (tentatively) classified as either Parameter, Feed, or Control, and given nominal values. The ‘model’ will simulate badly in this case, since without a source component Feed and Control are constant, while the corresponding data are variables. However, the step may reveal any bugs in the newly written component. In more dubious cases than the present there is another reason for simulating as soon as a new component has been created, namely that some of its input may change very little, or their variation may have little effect on the output. In the interest of parsimony it is often worth while to investigate the hypothesis that a constant input will do.  Click Simulate. 4.6.1 Setting the Origin of the Free Parameter Space  MoCaVa opens the Origin window (Figure 4.20). The “origin” is the parameter values used in the predictor simulation that follows. The default values are either the nominal values entered into the Argument attributes window in Figure 4.15 (¸ the ‘true’ values), or else values previously fitted to data. The list is termed “origin”, since any variation in the parameter values (for fitting or other purposes) is done around the values in the list − in the “free parameter space”.  Click OK.

104

Practical Grey−box Process Identification

Figure 4.21. Selecting variables for plotting

Help: Origin Window The values displayed in the table are those of the best of the significantly better alternatives so far to the current tentative model (except at the start of a session, or the activation of a new component, in which cases they are the nominal values set when the component was defined). They are used in simulations, and normally also make a good starting point for the fitting of a new tentative model. You may overrule the recommended values, if you have information that suggests otherwise. Press Export to create and save current values to an ASCII file. Press Import to enter parameter values from a prepared ASCII file, instead of doing the editing manually. In order to allow the Import option the file containing the values to be imported must be any of : An ASCII file with records of the following type: parametername value1 value2 ... : An M−file with records (possible commented): parametername = [value1 value2 ...]; where value# are valid scalar real numbers. Pressing Export creates a file of the second type with address casedir\status\parameters. Notice that only the values may be edited. (Changing a short description in this window will have no effect. It has been placed in a field that allows editing only because this will allow sidewise scrolling of long text strings). 4.6.2 Selecting Variables to be Plotted  MoCaVa starts the predictor simulator, and, after finishing, opens the Plot specification window (Figure 4.21). Check the boxes of the variables to be plotted. Default are variables associated with data and residuals (one−step prediction errors). You may also specify a smaller time range to be displayed.

4 Calibration

105

Figure 4.22. Response of DrumBoiler model with zero input

Figure 4.23. Standard deviations of prediction errors

 Click OK.  MoCaVa displays the result in two windows: The Plot window (Figure 4.22) and the Model class appraisal window (Figure 4.23). 4.6.3 Appraising Model Class  There is no obvious error (except that input are constant and start values are wrong). The model obviously needs the input.  Click Reject. Help: Model Class Appraisal Window Study the plots to appraise the model class with default parameters. Continuous curves are model output and discrete points are data. : Click Accept if you believe the model class will hold a tentative model, provided some parameter values are fitted.

106

Practical Grey−box Process Identification

: Click Reject if something is obviously wrong with the model class. This will take you back to the Model class specification window to set up another model class.

: Click Simulate if you want to see whether other parameter values will help. This will take you back to the Origin window.

: Click Layout if you want to display other variables or limit the time range in order

to obtain better time resolution. This will take you back to the Plot specification window. : Click Rescale to change the scale of a variable for better amplitude resolution. This will allow you to click on the y−axis graduation, in order to open a window for changing the scale attribute of the variable. The new scale will be retained until further manual scaling. The prediction errors are expressed in percentages of the rms−values of the output. Hence a ‘null’ model (all predictions zero) will have 100% prediction error.

4.7 Handling Data Input  MoCaVa opens the Model class specification window again.  Click Edit to indicate that the model does not have enough components.  MoCaVa opens the Component library window again to allow you to expand the library.  Select Insert and click OK in order to add a component handling the control input.  MoCaVa opens the Component naming window.  Give the second component the name Control.  MoCaVa opens the Component library window, now containing two components.  Mark Change for the new, empty component.  MoCaVa opens the Component function window to receive M−statements. The purpose of the component is to describe the connection between the continuous control signal u and the corresponding values in the data file. Since the user−defined functions only allow continuous variables, a library routine must be used to handle the conversion from discrete−time data to continuous−time input. Now, a component must have an output, which means at least one assignment statement. In the current case the output is a signal that will replace the Control input u in the DrumBoiler component, once it has been connected. The minimum component is therefore u = uc, where uc (continuous−time) is the output of a library routine interpolating between the data points. (If the input conversion were included in the DrumBoiler component instead, the auxiliary uc variable would not appear).  Click OK.  MoCaVa opens the Argument classification window.  Select Control and click OK.  MoCaVa opens the I/O interface window to receive the user’s choice of library routine.  Select Hold and click OK. This will cause the library routine modelling the selected interpolation mechanism to be included.  MoCaVa opens the Argument attributes window.  Edit default values, if necessary, and click OK.  MoCaVa opens the Data assignment window. Again there is an option for units conversion: data = Factor * model input, but the DrumBoiler case does not need to use units conversion.

4 Calibration

107

Figure 4.24. Graph of the root model class

 Pull down to find the data that corresponds to uc and click OK. This ends the definition of the Control component.  MoCaVa opens the Model class specification window, containing two components. It would be possible to simulate and plot again, to see how much it helps to have added as source for the Control input. However, to shorten the proceedings somewhat, first provide for the Feed input.  Create a Feed component in the same way.  MoCaVa opens the Model class specification window, containing three components. All components are Active, indicating that they are connected to form the model class.  Click Graph.  MoCaVa adds two new boxes in the Model window (Figure 4.24). In this graph of the three−components system the former parameters u and f have been replaced by input terminals connected to the output of components generating variables u and f. The latter have input connections to the data file.  Click Simulate again, and OK twice.  MoCaVa shows the result in Figure 4.25.  This looks better. There is nothing obvious in the plots that cannot possibly be amended by some fitting of parameters. The obvious first candidates are the start values.  Click Accept to acknowledge the first tentative (‘root’) model class consisting of three connected components.

4.8 Fitting a Tentative Model Structure  MoCaVa opens the Tentative structure window (Figure 4.26). Again, “structure” means “class” with a given selection of free parameters.  Select the parameters to be fitted by checking the boxes. By default, the standard deviations of measurement errors are indicated, since they are notoriously difficult to know in advance. In addition to the ‘true’ measurement errors, they generally have to account for all modelling errors in a fitting.  Free also the two elements in initstate, since it is evident from Figure 4.25 that their zero values are far off. Click OK.

108

Practical Grey−box Process Identification

Figure 4.25. Responses of the ‘root’ model with nominal parameter values

Figure 4.26. Selecting free parameters

 MoCaVa opens the Origin window again (Figure 4.27), this time to specify start values for the search for optimal values of the free parameters.  Click OK to acknowledge the default parameter values. 4.8.1 Search Parameters  MoCaVa opens the Search specification window (Figure 4.28). It allows the user to change the design parameters in the search routine.  Click OK to accept the default values and start the search.

4 Calibration

109

Figure 4.27. Setting start values for the search

Figure 4.28. Setting search parameters

Help: Search Specification Window Both the determination of the best model within the tentative structure, and the determination of alternative model(s) to compare with the tentative, use the same search routine. A difference is that in the first case the search is to go on until convergence, while in the second case one or a few iterations may achieve what is needed to reject the tentative model and point out a better alternative. The default maximum number of iterations is therefore set differently in the two cases, namely to 1, if the test satisfies the “nesting” condition, otherwise to 16. Basically, the search routine is a modified Newton−Raphson procedure, which normally requires few iterations, but may have trouble when the loss function differs much from a quadratic form of linear expressions in the free coordinates. It may therefore need some ‘coaching’ from the user in difficult cases, and the listed design parameters are the means to control the search. Hints The search is time−efficient for the loss function used for the fitting, since it uses a non−negative definite approximation of the Hessian, computed from only first−order derivatives of the model residuals. For parameter values far from the optimum, and large variations in the residuals’ sensitivities to the free coordinates, the estimate of

110

Practical Grey−box Process Identification

the Hessian may however deviate much, causing the steps taken towards the minimum to be inefficient or even counter−productive. For structures such that the residuals are affine (linear) functions of the free coordinates, the search converges in one step, but normally it takes more. The number it takes depends on the search parameters, and the setting takes some skill in difficult cases. The following provides some guidelines: : The Maximum number of iterations: In the beginning of the search (when parameters are far from the optimum) it may be wise to use few iterationss (two or four), in order to check the start−up. This causes the search to be halted, and gives the user a possibility to modify the search parameters and restart (click Reject), or else to continue (click Unfinished) if things seem satisfactory. In difficult cases, one may even maximize to one iteration, in order to have user control over the search all the way. A quick way to change the maximum number of iterations is to use the buttons [*2] or [/2] for doubling or halving the displayed number. : The Step reduction factor: The direction of a step never points in a direction where the loss function increases. However, the length of the step may be wrong in two ways (since it is estimated from an uncertain estimate of the curvature of the loss function): 1) It may be much shorter than optimal, recognizable from the fact that neither the steps nor the convergence indicator values change much from one iteration to the next. The loss function reduces with about the same (small) decrement. 2) It may be substantially longer than optimal, recognizable from the fact that successive iterations will change sign to step back. This is indication of ‘overshoot’. If the iteration is much longer than optimal, the overshoot may even be so large that the loss will increase. Modifying the step reduction factor is a means of rectifying this. : The Step limit: This sets a limit to the step length. The search coordinates are normalized (using the Scale values of the parameters) in such a way that step lengths larger than one should be unlikely. Hence, much longer steps indicate that the search may be going astray, and possibly out of the region of attraction to the optimum. The idea is that in cases of multiple minima, the search should be drawn to the one closest to the start value. It would therefore be reasonable to lower the step limit in difficult cases, and accept the risk of an increased number of iterations. : The Regularization parameters: Ill−conditioned cases (most often caused by freeing too many parameters simultaneously) cause the Hessian to be near singular and the steps to deviate much from the steepest gradient direction. Positive regularization parameters reduce the degree of singularity of the estimated Hessian. The two design parameters r 1 and r 2 cause a constant value Nr 2 to be added to the diagonal elements of the Hessian (where N is the number of data records) and then to be amplified by a factor 1+ r 1. The effect is that the search direction will be drawn towards the steepest gradient direction, with a strength given by the values of the parameters. Well conditioned cases are not effected by small values of the parameters, and that is the reason why the default values are 0.001. Larger values (up to 1, and more) slow down the search, and it is generally better to reconsider the number of free parameters. : The Overshoot limit: The loss value is normalized in such a way that its statistical uncertainty is about one. If the loss value would increase much more, this would be a clear indication of a large overshoot. The overshoot control will then reverse the direction, and take half a step back automatically, and continue to do so, until the limit is satisfied. This is a safety measure for the case that the user has left the

4 Calibration

111

search control to the computer (by specifying a large maximum number of iterations). : The Prior weight: This sets the factor α in the term ½ α — θ — 2 in the loss function (Equation 2.26), and thus reflects the user’s confidence in the origin of the free parameter space. Notice that this also has an effect on the Hessian; a zero weight may have to be compensated by a positive regularization r 2. However, the parameters are not interchangeable; a positive weight changes the optimum, a positive regularization does not. : Generally, manual search control is one of the points where a user will have an opportunity to exercise his/her (hopefully increasing) skill in dealing with difficult non−linear model structures. The auxiliary displays evoked by setting the Logging index constitute the data from which one can appraise the success of the search. Admissible values are 0: No auxiliary printout 1: Printed are Loss, Convergence indicator, Free coordinates 2: Printed are Loss, Convergence indicator, Free coordinates, Loss gradient, Hessian, Free coordinate changes. As a rule of thumb, a smooth search should reduce the convergence indicator with about one unit per iteration, at least after some initial and transient steps. Less smooth searches may still converge, but take longer. : In cases where the routine has difficulties converging, you may also try the step− adaptation routine. You activate it by checking the Adaptation box. 4.8.2 Appraising the Search Result  MoCaVa compiles and executes the C−based fitting routine and displays the result in the Search appraisal window (Figure 4.29).  The record shows that loss decreases rapidly, and the convergence indicator gets negative after four iterations.  Click Plot to get more information to base the next decision on (Figure 4.30).  The model predicts poorly, but the fitting seems to work.  Click Accept in the Search appraisal window. Help: Search Appraisal Window Look at the search log and make an assessment of the search: : Click Accept if the search has converged (convergence indicator < 0) and nothing is obviously wrong with the model, taking into account the restrictions of the model structure (It is the search and not necessarily the model structure that is ‘accepted’). : Click Reject to restart the search, for instance from a new origin or with new values of the search routine parameters. Even if the search has converged you may click Reject if you suspect you have reached a local minimum, or just want to make sure by trying a different start. : Click Unfinished if the search still looks promising, but needs more iterations, and possibly better values of the search routine parameters. : Click Confirm to restart the search from the point where it stopped. This may be useful if you have assigned a prior weight on deviations from the origin, thus forcing the search to compromise between the origin and the Likelihood maximum. Large deviations from the origin will cause a warning of unsuitable parameter scaling.

112

Practical Grey−box Process Identification

Figure 4.29. Search score

Figure 4.30. Responses of the root model class with fitted start values

Confirm can be used to amend that, without actually doing a rescaling. Since the search will be started from an origin closer to the unweighted optimum, the prior loss will reduce, and vanish after a few Confirms (see also Hints).

4 Calibration

113

: Click Plot if you want to see the standard variables (data input, sensor output, and residuals) before deciding.

: Click SelectPlot if you want to see also other variables. : Click Customize to change some default design parameters, in particular the increments used in numerical differentiation with respect to states and parameters.

Hints The absolute loss values are difficult to interpret directly; only the differences matter. Generally, loss differences smaller than one are insignificant (the loss is scaled in that way). A better interpretation is provided in the Test appraisal window showing the outcome of testing the fitted model. The free coordinates are those used in the search. They are dimensionless functions of the values and attributes of the physical parameters (origin, range, and scale). Normally, the sizes of the coordinate values should not be much larger than one. If they are, a warning is displayed. This suggests one of two things: either i) the scale of the parameter corresponding to the largest coordinate is too small, or ii) its origin is too far from the optimum. The second case can be checked by re−running the search starting from the optimum. The Confirm button is for that purpose. Only if that does not help will it be necessary to increase the scale attribute (Click Accept, NewClass, Edit, Change, etc., until you get back to the Argument attributes window to change the scale). If the search log would show a long sequence of positive and unchanging values of Conv (indicating nonzero gradients) followed by unchanging values of Loss, this may be due to rounding errors caused by a too small increment. Try the Customize option and increase DELTA. However, also too large an increment may cause similar problems. The values of the physical parameters are shown together with the estimated standard deviations for those that have been fitted. However, they are reasonable measures of significance of the estimates only if the model class is right. Again, a better assessment of significance is provided by the Test appraisal window.

4.9 Testing a Tentative Model Structure The next step is to try and falsify the tentative model structure by falsifying the best tentative model (just obtained). In preparation for this, one or more alternative (and preferably better) structures have to be conceived.  For this purpose MoCaVa opens the Alternative structures window (Figure 4.31). (The window has also an alternative form, allowing more options, and suiting more complex cases). This is a point where the user must contribute ‘engineering sense’ in order to suggest amendments to the discrepancies seen in the model response.  At least two things are wrong in Figure 4.30: : The power transients are wrong, as seen most clearly from the sequence of power residuals. : There are drifting disturbances in both the output. It is reasonable to assume that fitting some or all of the parameters that affect the responses directly will help. The free parameter spaces in this window are used to set up the finding better values. A “free parameter space” is an array of dimensions of the parameters that the

114

Practical Grey−box Process Identification

Figure 4.31. Specifying alternative model structures

Figure 4.32. The DrumBoiler statements

search routine may use to improve the fit. The dimension of a free scalar parameter is 1, and that of an bounded one is 0. But which parameters to free and how many? The window allows up to eight alternatives, in case it is unclear what to do next. A general strategy would be to free each one of the currently unfitted parameters, thus making as many alternatives (the “Stepwise Forward Inclusion” rule). However, it is often more efficient to use ones prior knowledge of the model structure to decide what to do.  Click Show to display the model statements and check the box for DrumBoiler in the window that opens.  MoCaVa displays the statements in Figure 4.32. You may close the display after using it, or keep it as a reminder of what you have defined.  It seems the easiest to reduce the disturbances first, by fitting the two parameters distE and distP, thus making a single alternative #1.  Click [+] twice to indicate this (Figure 4.33). Then click NewDim to initiate the testing. Help: The Alternative Structures Window In order to create efficient tests to the tentative model structure MoCaVa needs specifications of one or more alternative structures for comparisons. Providing such specifi-

4 Calibration

115

Figure 4.33. A single alternative with two more free parameters

cations is the user’s main tool for entering prior information in addition to the component specifications. You may create the alternative(s) in one of two ways: : By expanding the tentative structure within the current model class (= the set of active components). There is room for maximum eight such alternatives, specified by the free−space indices in the eight columns. As long as the number of free parameters of any of the listed parameters (indicated by the current index values) is smaller than the maximum number (indicated under Max), you may free more parameters by increasing one or more indices (click on +). The indices of specified alternatives turn red. For the sake of parsimony, it is recommended that you increase only few index values (normally one), and the same number for each alternative (column). Click NewDim when all alternatives have been set. : By expanding the current model class. Click NewClass. This will open another window for changing the model class. Click Show, if you want to display selected components before deciding. Click Plot or SelectPlot to appraise the response of the current tentative model before deciding. Click Verify, if plottings look good, and you therefore may consider ending the calibration session. This starts a number of unconditional tests based on computing actual correlations between variables that should not be correlated if the tentative model were true. In addition, the appearance of ‘outliers’ among the residuals is tested. Logically, these tests cannot stop the calibration conclusively, since a hypothesis can never be verified by statistical tests. However, it can be falsified, which yields a one−sided stopping rule: It determines when not to stop. Click Advanced, if you want to suppress some or all user’s checking of the computer’s proposals on parameter values, free space, and search parameters. The window will take long to build in cases with many parameters. MATLABX needs the time to generate the large number of [+] and [−] buttons required for minimizing the number of user’s mouse clickings. As an alternative the user may call for a different ‘primitive’ window, taking somewhat more key strokes and mouse clicking to fill, but much less time to generate. This window will also be more versatile, as well as allow more alternatives (up to 16 vector or scalar parameters). Click on Advanced and check the appropriate box. The setting will not take effect until the next time the Alternative structures window is opened. To get it opened immediately, you may use the ‘dummy’ commands of clicking first NewClass and then OK.

116

Practical Grey−box Process Identification

Help: The Primitive Alternative Structures Window Being ‘primitive’ it allows more combinations of alternatives. You can specify alternative model structures in three ways: : Enter the index value (the number of free entries) of a parameter and press Enter. The corresponding index for the tentative structure is indicated by the number of checked boxes. The column will be completed automatically with the tentative values of other indices. Any thus created column may be edited further, in case one would want to free more parameters in the same alternative. Thus, instead of a single clicking each alternative will take two key strokes and one mouse clicking. : Check the boxes to the right and verify the choice by checking one in the top array of boxes for creating a column of dimension values. : Use the “256) for factors (0.1,0.2,0.5,1). The adaptation will eliminate the need to experiment with the factor, when, as in this case, the default value of 1 will not work. Test routine for tentative model structure #9  Window: Primitive alternative structures  Motivation: Testing again the effect of strip weight on roller gap.  User decision: Free dcw.  Response from LR(*): The loss reduction is 213.

6 Rinsing of the Steel Strip in a Rolling Mill

219

 Interpretation: The strip weight is now significant.  User decision: Select_#1. Accept model structure #10.  Response from MLA(1): The normalized loss is 0.242170 The best model so far is defined in Table 6.3. Table 6.3. Components and parameters defining the deterministic model

Active components Tanks EffectiveVolumes Rollers Roller0 Strip Parameter Short description c_init rms_C1 rms_C2 rms_C3 rms_C4 rms_C5 eta hf he dc dcw hg hif hie

InitialAcidConc_[kg/m3] StDError_C1_[mS/m] StDError_C2_[mS/m] StDError_C3_[mS/m] StDError_C4_[mS/m] StDError_C5_[mS/m] MixingEfficiency ThicknessFilm_[m] ThicknessEdges_[m] FactorCavitation FactorCavitationStripWeight WidthRollerGapJet_[m] ThicknessFilmInputAcid_[m] ThicknessEdgesInputAcid_[m]

Values 10.94 0.356 1232 102 13.4 1.99 0.262 0.620 6.82:10−6 5.87:10−6 0.321:10−6 1.67 0.61 0.165 0.00029 0.254 0.277:10−6 0.000433

0.000062 0.00117

0.000440

8.42:10−6 14.01:10−6 0.53

0.54

0.097

0.044

6.9.2 Avoiding the Pitfall of ‘Data Description’  The number of parameters fitted to the data is now 22, not counting the five rms− values. All have come out statistically significant, although there has been little visual improvement at the end. This suggests that further attempts in the direction might only add to the number of ‘significant’ parameters and still explain nothing about the source of the data. In other words: The session may have come close to the pitfall of ‘data−fitting’, where some of the many free parameters are used by the search routine to adjust the modelling errors to variations in the data that have quite different origins than have been modelled. Figure 6.11 reveals at least two such places: : The model is quite unable to describe the variations of the conductivity in tank #1. Apparently, the flow model of the acid input (Equation 6.25) is not adequate, or its concentration is not constant. The conductivity in tank #2 also has difficulties to agree with data, but that is possibly a consequence of the differences in tank #1. : There are some large and apparently transient phenomena in particularly in tank #5, and in particular around 125 and 225 hours, some of which spills over into tank #4. Each is associated with a stand−stilllasting several hours. Figures 6.12 and 6.13

220

Practical Grey−box Process Identification

Figure 6.11. Responses of the best deterministic model

Figure 6.12. Transient errors at restart after long halt

show the restart of the two occasions, and reveal what happens: The model fails to describe the rapid change of conductivity in the last tank after restart.

6 Rinsing of the Steel Strip in a Rolling Mill

221

Figure 6.13. Transient errors at restart after long halt

 Since there is neither any data of the incoming acid, nor any prior knowledge about its source (the “pickling” process), it remains to accept that the source is indeed unknown, and use stochastic models to describe the variation.  Modelling the restart from temporary halts would require more information on what happens during the halts and immediately after, and possibly also what caused the stopping in the first place (why is the conductivity in tank #3 in Figure 6.13 changing when the process is standing still?). Since the information is not available, one must refrain from explaining the transients as caused by other known variables, and regard them as random. The point of this is to prevent the errors at the halts from propagating into other segments of the sample. Remark 6.10. Obviously, one could choose first to try and get some data or physical knowledge about the pickling process, or even give up on tank #1, and decide that the modelling starts with tank #2. However, that is just a question of where to delimit the object of the modelling. Even if the pickling process were included in the modelling, it would still have some unrecorded and not constant input that has to be described somehow. Remark 6.11. Admittedly, there are still a number of conceivable other shortcomings in the model: The flow dynamics have been assumed fast, and this means for instance that stepwise changes in the input flow to tank #5 would instantaneously affect the level in tank #1, which is obviously not true in the real process. However, simulations have indicated that within the rather long sampling interval of 0.2 h the effect of flow changes have propagated at least to tank #2 (Sohlberg, 1990). Since the level of tank #1 is controlled by a level regulator (and also affects the system dynamics very little), it does not seem worth while a priori to take the effort of modelling the flow dynamics better at this point. It would also cost five more state variables (the levels).

222

Practical Grey−box Process Identification

Remark 6.12. The current deterministic model can easily be falsified, unconditionally of an explicit alternative. A correlation test of the residuals would do it (Section 4.9.1). Simpler still: A look at the residuals sequences immediately reveals that they are not uncorrelated in time. Hence, they cannot be independent measurement errors, as was implicitly hypothesized by trying a deterministic model. However, the same result would probably be obtained from any reasonably complex deterministic model for this case. Hence, in order to stop the process of developing progressively more complex models, one will sooner or later have to resort to some principle that allows for modelling error (in addition to measurement error), in order to decide when it is enough. Stochastic modelling provides such an error concept.

6.10 Modelling Disturbances  The concentration of the hydrochloric acid from the pickling process depends on a number of factors that have not been recorded in the data. It is reasonable to suspect that it is not constant. 6.10.1 Pickling  Click NewClass, select Edit, select Insert, enter Pickling, and select Change.  The following analysis will suggest the form of the model. Hypothesis: The input acid concentration from the pickling bath varies randomly and slowly, and well within the range (0,1000) kg/m3. The boundaries can be modelled by the following formula c 0 = 500 [1 + (v − 0.75)

1 + (v − 0.75) 2]

(6.26)

where v is an unbounded stochastic variable with zero mean and unit standard deviation. A zero value of v yields the nominal value of c 0 = 200. Remark 6.13. The same general formula is automatically used in IdKit to limit parameters in the search. However, it has not been implemented for stochastic variables. There is no guarantee that the estimated values of c 0 will stay within the limits. Under extreme conditions the linearization performed by the EKF in IdKit may violate the boundaries. Entering Function Statements  Enter the following M−statements into the Component function window: % Bounded acid concentration from the pickling bath: beta = v0 − 0.75 cpb = 500*(1 + beta/sqrt(1 + beta*beta)) c0 = cpb

Argument Classification  Make v0 randomly variable by classifying it Disturbance. Classifying cpb as Response makes it possible to plot the estimated acid concentration.  Edit the Argument classification window:

6 Rinsing of the Steel Strip in a Rolling Mill

Argument

Class

Component output beta cpb

Internal Response

Component input v0

Disturbance

223

Source Models  Select the Lowpass model, since this allows estimation of the unknown bandwidth, as well as the rms−value. Unlike in the simpler Brownian model it is possible to limit its variance, which is important to ensure that linearization of the nonlinear function in the model will be possible.  Edit the I/O Interface window: Argument

Source

Connections to sensors cpb NoSensor v0 NoSensor

Unknown input: Environment model v0 Lowpass

Argument Attributes  The disturbance has two characterizing parameters. Use default attributes, but maximize rms_v0 to stay approximately within the linear range. The Nyquist frequency is 0.5/time quantum = 2.5 1/h, and also the maximum bandwidth.  Edit the Argument attributes window. Argument

Short description

Dim Scale

Nominal

Min

Max

Parameters rms_v0 bw_v0

Rms_v0 BandWidth_v0

1 1

1*1 0.5

0 0.5

0 0

0.5 2.5

Disturbance input v0 AcidInputNoise

1

1

Process output cpb ConcPicklingBath_[kg/m3]

1

100

States x_v0

1

1

StateAcidInputNoise

6.10.2 State Noise  Figure 6.11 reveals that there is also unmodelled actual acid flow that adds to the modelled rate of change of the acid concentration in each tank. The simplest hypothesis is that the error flows are random and of high frequency. Call them “spray” to emphasize their unpredictability, and model them as other internal disturbances.

224

Practical Grey−box Process Identification

Internal disturbances can be entered conveniently by connecting to some of the ‘stubs’ in the Tanks model, either to Fstub, cstub, qstub, or Dcstub depending on whether one would expect the unmodelled disturbance to affect liquid flow, concentration, acid flow, or the concentration derivatives. However, the first three hypotheses have now lost their appeal, since this would mean accepting the ‘unphysical’ negative values that have previously been rejected. In addition, the analysis in Section 6.4.1 revealed that only Dcstub will be effective enough to describe the fast responses to restart after a halt. One will simply have to accept that there are phenomena that are too rapid to be explained by a mixing model. Adding high−frequency ‘noise’ to the state derivatives is a conventional way out of the dilemma.  Click NewClass, select Edit, select Insert, enter ConcDisturbance, and select Change. Entering Function Statements  The state disturbance are not necessarily positive, and it is difficult to find any other boundaries. Assume therefore unlimited disturbances.  Enter into the Component function window: % Unbounded state disturbances: for i = 1:5 Dcstub(i) = v(i) end

Argument Classification  Edit the Argument classification window: Argument

Class

Component input v

Disturbance

I/O Interfaces  Select the Lowpass model, since this allows estimation of the unknown bandwidth, as well as the rms−value.  Edit the I/O interface window: Argument

Source

Connections to sensors v NoSensor

Unknown input: Environment model v Lowpass

Argument Attributes  Edit the Argument attributes window.

6 Rinsing of the Steel Strip in a Rolling Mill

225

Argument

Short description

Dim Scale

Nominal

Min

Max

Parameters rms_v bw_v

Rms_v BandWidth_v

5 5

Scalev*1 0.5

0 0.5

0 0

2.5

Disturbance input v ConcNoise_[kg/m3/h]

5

Scalev

States x_v

5

StateConcNoise

Nominal Values and Scaling  The scale of v is related to that of c; divide by the sampling interval: Scalev = Scalec/0.2.  Enter the following values into the Implicit attributes window: Attribute

Values

Scalev

5

0.5

0.05

0.005

0.0005

Remark 6.14. The six new states introduced by the disturbance models make the calibration run considerably much slower. However, activating the options for speeding up the processing will not help in this case. Transfer matrices vary too fast and are too dense for the speed optimization to be effective. An obvious cause is the frequent speed changes.

6.11 Determining the Simplest Environment Model Introducing stochastics into the model means accepting the fact that some phenomena in the process behaviour cannot be modelled by mathematical equations, at least not without unreasonable complexity. Whether this is a serious shortcoming or not depends on how one intends to use the model. It might seem that if one wants to use the model for calculating the process’ responses to various known stimuli, then one needs a deterministic model − stochastic input would obviously be unknown − and one should therefore stick to deterministic modelling. However, that conclusion runs contrary to the conjecture that deterministic model structures, without the ‘padding’ of internal disturbance models, will make fitted parameters more susceptible to disturbances. The conjecture is supported by a study using the same data (Bohlin, 1991b), and also by the DrumBoiler example in Chapter 4. 6.11.1 Variable Input Acid Concentration  In view of the fact that only the product of concentration and volume flow of the input acid affects the steady−state acid balance of the rinsing process, it may be expected a priori that it would be difficult to estimate both the random input acid concentration and the state noise in tank #1. Start therefore by activating only the Pickling component.  Make Pickling Active and ConcDisturbance Dormant.

226

Practical Grey−box Process Identification

Test routine for tentative model structure #10  Window: Primitive alternative structures  Motivation: Testing the effect of variable input concentration.  User decision: Free rms_v0.  Response from ALMP: The loss reduction is 930.  Interpretation: The alternative is better.  User decision: Select_#1. Accept model structure #11.  Response from MLA(10): The normalized loss is 0.146867. Test routine for tentative model structure #11  Window: Primitive alternative structures  Motivation: Testing the effect of optimal input concentration bandwidth.  User decision: Free bw_v0.  Response from ALMP: The loss reduction is 31.2.  Interpretation: The loss reduction is significant. The alternative is better.  User decision: Select_#1. Accept model structure #12.  Response from MLA(4): The normalized loss is 0.146070.  Figure 6.14 shows the simulation result in tank #1. The only obvious prediction errors are at the two long halts. 6.11.2 Unexplained Variation in Acid Concentration  Click NewClass, and make ConcDisturbance Active. Test routine for tentative model structure #12  Window: Primitive alternative structures  Motivation: Testing the effect of concentration state noise.  User decision: Use the SFI rule (click on the rows of all parameters to test for over−fitting.  MoCaVa starts a long procedure of systematically locking each parameter entry to its nominal value (usually zero), fitting the reduced structure, and computing the increase of loss. The result is shown in Table 6.4. The interpretation of the values in the table is that a parameter is either significant (if the loss increase is above a threshold), or else possibly insignificant. Among the latter the one with the smallest loss increase is insignificant. Since the outcome is not conclusive for all parameters, the reduction must be done in several rounds, although with decreasing number of alternatives.

230

Practical Grey−box Process Identification

Figure 6.16. Conductivities and prediction errors

6 Rinsing of the Steel Strip in a Rolling Mill

231

Table 6.4. Loss increases due to reduced parameter freedom

Parameter

Loss increase

he dcw hg hif hie

0.0 0.1 187 12.2 0.1

346

156

65

The first round of the reduction normally involves much calculation, in particular for those alternatives that end up as significant, and they are normally the majority. The reason is that the search for an alternative model within the reduced structure must continue until the best parameters within the alternative structure have been found. (This is in contrast to the testing with expanding alternatives, where it is enough to find a falsifying alternative). If a parameter is significant, the search starts with values that are far from the optimum. However, the next rounds will be fast, due to the following circumstances: : The parameters that turn out significant need not be tested again. : The possibly insignificant must be tested again, but when they turn out possibly insignificant again (which is likely), the computing will not take long. The procedure yields the sequence of results shown in Table 6.5.

Figure 6.17. A segment of the sample showing restart after a long halt

232

Practical Grey−box Process Identification Table 6.5. Loss increases due to reduced parameter freedom

Round

Parameter

Loss increase

#2

dcw hie

0.0 0.0

#3

dcw

0.0

Table 6.6. Components and parameters defining the deterministic model with stochastic disturbances

Active components Tanks EffectiveVolumes Rollers Roller0 Strip Pickling ConcDisturbance Parameter Short description

Values

c_init rms_C1 rms_C2 rms_C3 rms_C4 rms_C5 eta hf he dc dcw hg hif hie

InitialAcidConc_[kg/m3] StDError_C1_[mS/m] StDError_C2_[mS/m] StDError_C3_[mS/m] StDError_C4_[mS/m] StDError_C5_[mS/m] MixingEfficiency ThicknessFilm_[m] ThicknessEdges_[m] FactorCavitation FactorCavitationStripWeight WidthRollerGapJet_[m] ThicknessFilmInputAcid_[m] ThicknessEdgesInputAcid_[m]

7.35 46.2 6.97 1.18 0.204 0.0122 0.491 12.7:10−6 0 0.77 0 0.048 1.38:10−6 0

rms_v0 bw_v0 rms_v bw_v

Rms_v0 BandWidth_v0 Rms_v BandWidth_v

0.498 0.093 0.228 0.367

0.155

0.0227

0.00265

0.000158

3.32:10−6 0.264:10−617.6:10−6 0.55

0.58

0.84

0.144

0.095

0.248

0.0580 0.088

0.00936 0.528

0.00208 2.40

0.000180 2.30

 Accept model structure #16 with zero nominal values for he, dcw, and hie.  Response from MLA(1): The normalized loss is 0.030988. Test routine for tentative model structure #16  Window: Primitive alternative structures

6 Rinsing of the Steel Strip in a Rolling Mill

233

 Motivation: Testing the final model.  User decision: Free Fspray, as, ais simultaneously.  Response from ALMP: The loss reduction is 22.0, but again with inadmissible parameter values. The risk value is 0.0000014.  Interpretation: The loss reduction is significant. The model is falsified, but no alternative is better.  User decision: QuitSearch. The best stochastic model so far is defined in Table 6.6. Remark 6.15. The bandwidths of the state disturbances v(4) and v(5) are close to the Nyquist frequency = 0.5/0.2 = 2.5, which indicates that for all practical purposes they could have been replaced by ‘white’ sequences. Using a ‘white noise’ disturbance model would not cost extra states, and would thus speed up computing. However, MoCaVa does not allow ‘white noise’ disturbances (or a discrete−time approximation of it). The main reason is transparency: White noise into nonlinear structures may yield intuitively unexpected responses (Graebe, 1990b). Figure 6.18 shows a block diagram of the final model class. 6.11.4 Appraising the Roller Conditions The well−established result that the push−back rollers vary in their efficiency to prevent acid from being ejected into the next tank suggests that this information be used to monitor the rollers. The estimation of the status of the rollers has been used to devise a new strategy for maintenance of the rollers (Sohlberg, 1993b). It is therefore interesting to compare the estimates of hf (film thickness) and dc (cavitation factor) when fitted with and without disturbance models. From Tables 6.4 and 6.5: : Without: hf = (6.8, 5.9, 8.4, 14.0) ³m, dc = (1.67, 0.61, 0.53, 0.54) : With: hf = (12.7, 3.3, 0.26, 17.6) ³m, dc = (0.77, 0.55, 0.58, 0.58) The values differ. However, the results indicate that rollers #1 and #4 have worn surfaces (since the they let much more acid through) and are in need of reconditioning. The latter is achieved by grinding the surface to remove a thin layer of the rubber. Using the values of dc to assess the elasticity of the rubber would also be feasible. A low value would indicate that the rubber has hardened or become thin from frequent reconditioning. However, the values are not yet alarmingly low.

12 Conclusions from the Calibration Session The following may be concluded from the calibration session: : The tanks have different dynamic properties. : The rollers have individual surface properties. They are identifiable, and can be used to monitor the roller conditions. : ‘Cavitation’ is significant and the impressions are individual to the rollers. : Much of the acid transferred between tanks is ejected beside the strip through the slot, and not, as first expected, adhering to the strip surfaces. : The mixing in a recipient is not perfect, causing a significant difference between the acid concentrations at the bottom and on the surface. : No effect of ventilation can be verified.

234

Practical Grey−box Process Identification

Figure 6.18. Block diagram of the final model class

: The input acid concentration varies significantly. : There are significant unmodelled phenomena in the models of the rinsing flows between tanks.

: Long halts cause unmodelled transient phenomena after restart. : The model of tank #1 is uncertain. In order to improve it the concentration of input acid must either be measured, or its variation described by a model of the pickling bath.

7

Quality Prediction in a Cardboard Making Process

7.1 Background The case is based on a preliminary study (Bohlin, 1996) with the purpose of investigating whether grey−box identification would eliminate some of the problems with an earlier attempt to model the variations in one of the main quality variables of cardboard, the “bending stiffness”, at the Frövi plant in Sweden. Although a semi−physical regression model predicted well (Gutman and Nilsson, 1996, 1998), the parameter estimates varied much with time. The main study was later carried out by Pettersson (1998), who also designed the on−line predictor running at the plant. All studies were sponsored by the Swedish national NUTEK program for promoting the use of modern methods for industrial control problems. A large amount of experiment data was available from the Gutman−Nilsson study, recorded during normal production of cardboard of a representative series of qualities. The purpose of the model building was two−fold: i) for long−range prediction of the bending stiffness based on preset control variables to be used for preparing grade changes, and ii) for design of model−predictive feedback control from online measurements of cardboard thickness and laboratory measurements of bending stiffness.

7.2 Step 1: A Phenomenological Description This first step in the model making procedure means briefly identifying what physical units and phenomena that mainly contribute to making the cardboard manufacturing process do its task, and the circumstances under which the experiment data were produced. The step serves to delimit the object of the modelling, and to focus the modelling on the a priori most important phenomena. This normally requires frequent consultations with an engineer responsible for the process. Remark 7.1. I recommend a team of two to be responsible in cases of grey−box modelling. An engineer generally skilled in grey−box modelling cannot also be expected always to make a well balanced prior judgement of what details that can and cannot be eliminated a priori. A cardboard plant is a huge collection of machinery, and far too complex for modelling without a drastic reduction of its complexity already from the beginning. Instead of starting with the process and trying to describe how it operates, it is more prudent to start by considering the basic ideas behind its operation, which are usually much simpler. And a process engineer (or possibly a handbook) is a good source of such information. What makes the real process complex is usually

236

Practical Grey−box Process Identification

all the secondary support and control units that make the process operate as intended, or serve to trim its performance to maximum. Only if the secondary units would not do their jobs, will it be necessary to take them into account. The following builds on the report of Gutman and Nilsson (1996) and further consultation with Bengt Nilson at Frövi. The cardboard at the Frövi plant is manufactured by joining four layers of board from four separate systems of headbox and wire, each fed from a separate pulping process, except the two middle layers, which are fed from the same pulp. The four head boxes eject emulsions of wood fibers and chemicals onto the four running wire nets. Most of the water is drained in the process, leaving damp fiber mats on the wires. The joining takes place on the elongated wire of the bottom layer, as depicted in Figure 7.1. In certain qualities a layer of coating is added on the top. The figure describes the process in a detail that is assumed relevant for the modelling of bending stiffness. Processes not included are the many water flows in the system, the consistency control, and the drying.

Refiners r6 r5

r1

f6

Reject

f5

B75

f4

Ctmp

f3

Birch

f2

Pine

f1

Storage tank

Refiner Pump Measurement

Mass flow Information

Laboratory BSI κ6

Mixing tanks Machine chests

Headboxes

Symbols

B70

vw ps

ph

w

vp

Coating

Wires Shoe press

h

wc

Pope Hot nip press

Figure 7.1. Illustrating the sub−processes in the manufacturing of multi−layer cardboard that are assumed to affect the bending stiffnesss index BSI

The pulp in each layer is a blend of six kinds of ‘raw’ pulp: pine, birch, ctmp, B75, reject, and B70. Before the blending the pulp has been treated in refiners, which has effected the properties in a way that may or may not be advantageous to the bending stiffness. Even if one may assume that refining is not done unnecessarily and to an adverse effect, the latter may still be the effect of an attempt to improve other quality variables than the bending stiffness. The joining of the layers certainly affects the bend-

7 Quality Prediction in a Cardboard Making Process

237

ing stiffness, and the subsequent processing in the paper machine, in particular pressing, drying, and coating may or may not change cardboard properties significantly. Speed differences along the machine may do the same. The main control variables in the model are the flows of raw pulp (illustrated by six pumps), and the specific refining energies of some of the pulp qualities, altogether nine possible controls. The flows extracted from the pulping system and fed to the head boxes are not free, but are used to control the basis weight, as illustrated by the information fed back from the basis weight measurements. It is assumed that the control is good enough to render the difference between actual and specified basis weight negligible in the stiffness model. The recording in Figure 7.3 provides some support to that assumption. It is also assumed, although not supported by recordings, that pulp flows and consistencies are regulated well enough.

7.3 Data Preparation Before proceeding further, it is worth while to take a look at the experiment data, since that has bearings on the modelling. Generally, raw data from data acquisition systems not particularly designed for process identification must be preprocessed. In the present case the preparation of suitable data files is done in two steps, first using general functions for data processing in MATLABX and then special functions in MoCaVa. Remark 7.2. A reader who would want to use MoCaVa to repeat the model design procedure described below may skip the somewhat tedious data preparation steps, since the results are available in the directory Examples\CardBoard\. In particular the first manual step depends very much on the particular plant, and has been included for completeness, and also to illuminate that data preparation may require serious consideration. The experiment data used for the calibration and validation has been recorded during normal operation, covering a representative set of product specifications. Sixteen of the variables have been measured on line with a sampling rate of 12 minutes, and two more, BSI and kappa−number of the B70 pulp have been measured in a laboratory more sparsely and with irregular intervals. Raw data were available from two loggings of about one and five months lengths and with about four months in between, viz. during 940829 − 940925 (files out0.txt − out3.txt) and during 950209 − 950703 (files out4.txt − out21.txt). The files out0.txt − out10.txt contain records of 25 variables, and files out11.txt − out21.txt two variables more. The first task is to create two samples to be used for calibration and validation. This is not straightforward however: : There is a four months gap between samples out3.txt and out4.txt : The numbers of recorded variables differ between out10.txt and out11.txt : There are more variables recorded than needed for the identification purpose, and the positions of some variables differ in the files. : There are outliers. These and similar circumstances are certainly not uncommon in practice, and would preferably require a more sophisticated data preparation support than available in the Predat program of MoCaVa. Instead the following will be a somewhat tedious and detailed account of how the raw data were molded into samples suitable for processing by MoCaVa3. First, some MATLABX statements were applied to merge the raw data samples: out0 = load(’..\MoCaVa3\Examples\CardBoard\raw\out0.txt’);

238

Practical Grey−box Process Identification

........................................ out21 = load(’..\MoCaVa3\Examples\CardBoard\raw\out21.txt’); out0010 = cat(1,out1,out2,out3,out4,out5,out6,out7,... out8,out9,out10); out1121 = cat(1,out11,out12,out13,out14,out15,out16,... out17,out18,out19,out20,out21); save ’..\MoCaVa3\Examples\CardBoard\out0010.dat’ out0010 ... −ascii save ’..\MoCaVa3\Examples\CardBoard\out1121.dat’ out1121 ... −ascii

The first statements load the 22 raw data files into the MATLABX work space. The second two statements catenate the resulting matrices into two, out0010 and out1121. The last two save them as ASCII files with a dat extension in the (arbitrary) directory Examples\CardBoard\ for further processing by Predat. The compositions of the two files were determined by the different number of variables in the raw records. This means that the first file out0010 will contain the four months time gap. Use this sample for validation purposes, and the longer and later sample out1121 for calibration. The number of records are 9401 and 10464. The following is a table of the contents in the second file: Table 7.1. Record specifications of raw data file out1121.dat

Pos.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

Name

Physical meaning

On/off−indicator Date Time_[h,min] F197 FFC181 F193 F194 F192 F196 EQ900 EQ903 EQ904 ASPOP ASVIR SP2LT SLT APAL AKYT2 ATJO2

PulpFlowPine_[t/h] PulpFlowBirch_[l/s] PulpFlowCTMP_[t/h] PulpFlowB75_[t/h] PulpFlowReject_[t/h] PulpFlowB70_[t/h] SpecRefEnergyPine_[kWh/t] SpecRefEnergyReject_[kWh/t] SpecRefEnergyB70_[kWh/t] PopeSpeed_[m/min] WireSpeed_[m/min] PressureShoe_[kN/m2] PressureHotNip_[kN/m2] Coating_[g/m2] BasisWeight_[g/m2] Thickness_[micron]

QKAP01 KappaNumberB70

KSTY8

BendingStiffnessIndex_[mN]

7 Quality Prediction in a Cardboard Making Process

239

Variables without specification are not of interest for the case. The specifications for the other data file out0010.dat is the same, except that KSTY8 is now in position #24.  Start MoCaVa by typing mocava3 in the Matlab window, and select Predat, New data file, and Get data file. Use the browser that opens to locate the MoCaVa3\Examples\CardBoard\ directory. The window in Figure 7.2 appears. The directory contains three sets of data files in various stages of preparation: i) a directory raw containing the data files from the original data acquisition ii) the two data files out0010 and out1121 resulting from the manual catenation process just described, and iii) the two data files out0010.mcv and out1121.mcv resulting from running Predat, as described below.

Figure 7.2. Widow for selecting sample to be prepared

 Open the file out1121. This opens the Plot Outline and Data Outline windows (Figures 7.3 and 7.4). Clearly, the data is in need of some editing. The time indications, records #2 and #3 cannot be used in this case. The time variable must be increasing, while the clock readings (#3) are reset at midnight. It will be necessary to use the option for generation of a fictitious time variable instead, based on the record counter. Consult Table 7.1 to change the following in the Data Outline window: : Rename the variables to be used. : Mark the variables not to be used, #1, 2, 3, 4, 21, 23, 24, 25, 27, for removal and click Delete Now. : Select Const. Sampl. interval, from the ‘pull−down’ menu, set the sampling interval to 0.2, and select hours. Click Apply Now. Remark 7.3. The reason for not considering the indicator variable in the first column is that the options in Predat do not allow for the elimination of individual records based on an indicator variable. In the preliminary study (Bohlin, 1996) a temporary C−program was written to do this, in addition to the other data preparation tasks.

240

Practical Grey−box Process Identification

Figure 7.3. Recorded data sample #2

However, most ‘indicator−off’ values are also associated with NaN or inf in the corresponding records, which MoCaVa3 is able to handle. The data shows a number of breaks in the data flow and occasional missing data, as well as a large number of ‘outliers’ both in connection with the breaks and during normal operation. Predat applies a simple rule to eliminate the worst parts from the raw data automatically. This will reduce the need for the user to eliminate spurious data manually.  Click Edit in the MoCaVa window, and then Remove outliers. The MoCaVa − Remove Obvious Outliers window opens. Click Detect Outliers. This will draw 3 σ thresholds in all graphs having values outside the thresholds (Figure 7.5). Click Remove Outliers. The values will be replaced with NaN and the graphs will change accordingly (Figure 7.6). Click Quit. It is generally difficult to know what values are ‘outliers’ and also how much of the outliers to remove, and MoCaVa3 offers no direct solution to the problem. However, the possibilities to model disturbances in both input and output should reduce the

7 Quality Prediction in a Cardboard Making Process

241

Figure 7.4. Window for editing sample attributes

sensitivity to outliers, in particular since the larger outliers have been removed. However again, a glance at the graph still suggests that a few more values should be removed, for physical reasons: The two speed variables ASPOP and ASVIR display a few values that are clearly not in accordance with the normal accuracy in speed measurements. Remark 7.4. The SP2LT and SLT pressure values in Figure 7.6 include quite a num-

242

Practical Grey−box Process Identification

Figure 7.5. Selected records with 3σ limits

ber of zeroes, which may indicate failures in the pressure gauge, and hence outliers. However, they might also indicate that the press itself has been temporarily inactivated, in which case the values are not outliers. In order to decide, one would have to make quite a thorough investigation of the events during the intervals with abnormal operation of the plant. Since this would appear to be overdoing it for a preliminary study, no outliers will be removed from SP2LT and SLT. Remark 7.5. Generally, the variables for which outliers would have the largest effect, if any, are those at the end of the process, namely the speed, pressure, and basis weight settings, which would be expected a priori to affect the stiffness index instantaneously. Also, their measurement accuracies would be expected to be generally higher than the other input variables. The recordings of pulp flows F and specific refining energies EQ are more uncertain, and it is even more difficult to know if an outlier is a measurement error, or if the pulp flow has actually been reduced for a short while.  In order to do a manual elimination of outliers in a variable, first double−click at the corresponding graph. This opens the window in Figure 7.7 for ASPOP. Check

7 Quality Prediction in a Cardboard Making Process

243

Figure 7.6. Selected records purged from obvious outliers

the box Mark Outliers, and draw boxes around the values to be removed. The values turn from red to green. When all selected outliers have been marked in this way, click Remove all. The values will be replaced with NaN and the graphs will change accordingly.  Do the same for ASVIR. One more thing has to be taken care of: Figure 7.5 reveals that there are some negative values in the flow variable masurements FFC181. In order to avoid having to include statements in the model checking for non−positive flow values in the model it is expedient to eliminate them already in the data. It is possible to use Predat again for the purpose. A faster alternative would probably be to use a MATLABX statement for eliminating all negative values from the data matrix. After the manual outlier elimination the data sample appears as in Figures 7.8 and 7.9.  File the sample by clicking Main, and then Save as. Place the prepared sample in MoCaVa3\Examples\CardBoard\out1121.mcv. Finally, click Exit predat.

244

Practical Grey−box Process Identification

Figure 7.7. Marking outliers in ASPOP

 Repeat the procedure for out0010.dat. This brings the level of data contamination down to what is a priori believed to be acceptable for the preliminary study. The remaining, and still considerable amount of ‘errors’ of various kinds will be left to the Calibration and Validation functions in MoCaVa to deal with. Remark 7.6. The need to decide a priory when to stop the data preparation is not entirely satisfactory, but well in accordance with the grey−box concept of supporting ‘objective’ data analysis with prior physical knowledge − some data simply cannot have been caused by the object to be modelled. However, it is the author’s opinion that, ideally, ‘data preparation’ in the form of elimination of some parts of data believed to be erroneous on subjective grounds should be reduced to clear−cut cases. ‘Contamination’ in a data sequence is also data, since there is still some physical process that produced it. It should preferably be modeled as caused by a ‘disturbance’ model. However again, a practical issue is also the trade−off between the time put on preparing ‘good data’ and that used for ‘disturbance modelling’. Since, MoCaVa does not have enough support for modelling as serious contamination as ‘outliers’, the need for separate data preparation remains.

7.4 Step 2: Variables and Causality The purpose of the second step is to define the most important variables and the causation between them. Like the first step this must be based on prior knowledge only. It will also create a skeleton structure on which to hang any prior knowledge about the variables and the relations between them.

7 Quality Prediction in a Cardboard Making Process

245

Figure 7.8. Sample prepared for calibration

The following translates the physical description of the object illustrated by Figure 7.1 into the block−diagram form in Figure 7.10 which is better suited to simulation and identification: f = Input mass flow of pulp constituents [kg/s] r = Specific refining energies of constituents [Wh/kg] κ = ‘Kappa numbers’ of constituents Z = (Q,E,B) = Pulp flow properties in pulp lines Q = Pulp flows [kg/s] B = Bulk of pulp [m3/kg] E = Tensile strengths [N/m2] v = Speeds at wire and pope [m/s] p = Shoe and hot nip pressures [N/m2] c = Coating [kg/m2] H = Thicknesses of layers (including coating) [m]

246

Practical Grey−box Process Identification

Figure 7.9. Sample attributes and statistics

w = Basis weight [kg/m2] BSI = Bending−stiffness index [mN] f,r,κ

Pulp prep.

Z pc

Mixing

Z mx

Pulp feed

Z pu

Paper

machine

w,v

E,H

w,c,v,p

Lab.

BSI

w,c

Figure 7.10. Partitioning of the object, determining the internal and external variables involved in the modelling

The partitioning is based on the following preconceptions:

: Lab.: The bending stiffness BSI should mainly depend on the thicknesses H and

tensile strengths E (= stiffness against pulling) of the layers of the finished cardboard. The relation is static and given by basic mechanics (Gavelin, 1995), and should therefore be invariant and reasonably reliable.

7 Quality Prediction in a Cardboard Making Process

247

: Paper machine: Thickness equals basis weight times bulk, where basis weight is

mainly dependent on the amount of pulp in the different layers. The relation should be reliable, since it can be based on mass balances, where the input flows are known, as well as the output speed. The sum of layer thicknesses is measured. Bulk and tensile strength are material properties, determined primarily by the mixing and refining of the pulp, but transported through the system, and transformed in the paper machine (headboxes, wires, pressing, and drying). The effects of pressing and drying should be instantaneous, but are unknown, except possibly the sign. : Pulp feed: Since fiber strengths and bulk are additive pulp properties, the relations between those properties in the input and output flows Q mx and Q pu can be based mainly on mass balances, and therefore expected to be reliable. The output flow Q pu is controlled to regulate the basis weight w. This is assumed to work without error. The machine chests may or may not introduce dynamics, but with well regulated consistency that should be of first order (with two properties and three chests, that would possibly amount to six state variables). : Mixing: The mixing process should introduce simple and comparatively reliable dynamics, since its volumes and flows are known. The dynamics should be at most first order (possibly adding another six state variables). Transport delays might add to that, if significant. Since fiber strengths and bulk are additive pulp properties, the relations between those properties in the six input ingredients E pc, B pc and the three output mixtures E mx, B mx are based on mass balances. : Pulp preparation: It is generally unknown how a given blend of pulp and refining affect the mechanical properties and bulk of the pulp entering the mixing tanks and machine chests. It is reasonable to expect that a relation would be less reliable, since the raw material and previous processing of the pulp cannot be expected to produce a homogeneous result. The variations should be slow, however, compared to the overall processing time. The primary setting of pulp properties should be static (instantaneous), at least on the time scale of the 12 min sampling interval. Since there are several pulp lines and layers, most variables are arrays. The two middle layers in the cardboard have the same properties, and will be regarded in the sequel as a single layer, so the cardboard has three layers, not counting possible coating. Still, 59 scalar variables have been defined altogether, of which 18 have direct but contaminated relations to experiment data. Hence, most of the variables cannot be measured. But the point of dividing the object into several parts is that it will be possible, on physical grounds, to exclude directly a large number of otherwise mathematically possible relations between the input and output variables. And the number of unknown parameters will still be smaller than in the simplest conceivable ‘black box’ with sixteen input and two output. 7.4.1 Relations to Measured Variables The measured variables are indicated in Figure 7.1. The measurement conditions will need specifications later. Make one more table to support this. The following specifications will be needed: : The names of the recorded variables that correspond to the model variables. : The mean values, as given in the Data outline window in Figure 7.9; they will be needed for scaling. : A factor for converting from the units used in the model to those used in the data file. The latter follows easily, if the data units have been specified. The model will

248

Practical Grey−box Process Identification

use the standardized units [m], [kg], [W], for length, weight, effect, but [h] for time unit. The deviation is an adaptation to the sampling rate, 0.2 h. Table 7.2. Relations between model variables and data

Variable

Data

Mean Conversion

f1 f2 f3 f4 f5 f6 r1 r5 r6

F197 [t/h] FFC181 [l/s] F193 [t/h] F194 [t/h] F192 [t/h] F196 [t/h] EQ900 [kWh/t] EQ903 [kWh/t] EQ904 [kWh/t] QKAP01 AKYT2 [g/m2] ASVIR [m/min] ASPOP [m/min] SP2LT [kN/m2] SLT [kN/m2] APAL [g/m2] ATJO2 [micron] KSTY8 [mN]

3.35 27.8 6.21 5.84 6.27 5.51 205 106 180 63.8 273 318 330 488 54.4 20.2 445 14.1

[kg/h] [m3/h] [kg/h] [kg/h] [kg/h] [kg/h] [Wh/kg] [Wh/kg] [Wh/kg]

À6

w [kg/m2] v w [m/h] v p [m/h] p s [N/m2] p h [N/m2] c [kg/m2] H [m] BSI [mN]

0.001 1000/3600 0.001 0.001 0.001 0.001 0.001/0.001 0.001/0.001 0.001/0.001 1 1000 1/60 1/60 0.001 0.001 1000 1000000 1

7.5 Step 3: Modelling Filling the blocks with relations of various complexities and credibilities, with known or unknown parameters, will create the expanding set of model structures that MoCaVa needs for prior information (in addition to the experiment data). This will exploit more specific knowledge about the phenomena governing the behavior of each block. So far, preparations for this step will have to be done only for the ‘root’ model, i.e., for the simplest conceivable and preferably also reliable relations between the defined variables. Further modelling is postponed until the result of the calibration step indicates that refinement will be necessary. Thus, steps 3 and 4 are taken repeatedly in a ‘loop’.  To start the loop select Calibrate in the MoCaVa window. Click New project and enter its name CardBoard (unless it has already been defined). Select and open the new project. In the next window select the data file from where you put the prepared data, namely MoCaVa3\Examples\CardBoard\out1121.mcv, and click OK in the next window to indicate that the whole file is to be used for the calibration. The modelling procedure starts from the end of the causality chain, the component producing the final output of the model, in this case the “Lab” unit. 7.5.1 The Bending Stiffness  Enter Lab in the Component naming window, and select Change to define it. The next window will receive the assignment statements that specify how the bending stiffness BSI depends on the thicknesses H and strengths E of the layers in the cardboard.

7 Quality Prediction in a Cardboard Making Process

249

Entering Function Statements  In order to find formulas for the dependence assume that the cardboard has the mechanical properties of an ideal I−beam. The following relations are obtained from the theory of bending an elastic four−layer beam: Let H 0 = H c and E 0 = E c be the cb thickness and elasticity of the coating, and H i = H cb i and E i = E i those of the three layers in the uncoated cardboard. Then the following formulas compute the bending stiffness index BSI from E, H, w, c (Pettersson, 1998): Ply coordinates: z 0 = − (H 0 + H 1 + H 2 + H 3) 2 z i = H i−1 + z i−1, (i = 1, 2, 3, 4) Bending stiffness per unit width: A 0 = E 0 (z 1 − z 0) B 0 = E 0 (z 21 − z 20) 2 D 0 = E 0 (z 31 − z 30) 3 for i = 1,2,3, compute A i = A i−1 + E i (z i+1 − z i) B i = B i−1 + E i (z 2i+1 − z 2i ) 2 D i = D i−1 + E i (z 3i+1 − z 3i ) 3 S b = D 3 − B 23 A 3

(7.1) (7.2) (7.3) (7.4) (7.5) (7.6) (7.7) (7.8) (7.9)

The bending stiffness is measured as the force it takes to depress the free end of a sample of cardboard of standard size fixed at the other end. The “bending stiffness index” is further normalized by a factor depending on basis weight: BSI = K si S b [(w + c) 0.1] 3

(7.10)

The known instrument factor is K si = 3 × depression × width (length) 3 of the test sample. Rewriting the formulas into M−statements yields the statements to enter. The credibility of this prior knowledge is high, and the relations are obvious parts of the ‘root’ model. Remark 7.7. From the point of view of identification, it is interesting to note that the relation is cubic in the thickness variables for given strength parameters E. However, the latter parameters may also depend on thickness; in particular pressing may affect both H and E. It is reasonable to conceive that when a piece of cardboard is compressed, the pulling force it will withstand, will not reduce as much as its thickness, if at all. This will conceivably reduce the degree of nonlinearity.  Enter the following M−statements into the Component function window (this has already been done in the demo case): % PLY COORDINATES z0 = − (Hc + Hcb(1) + Hcb(2) + Hcb(3))/2 z(1) = Hc + z0 z(2) = Hcb(1) + z(1) z(3) = Hcb(2) + z(2) z(4) = Hcb(3) + z(3) % BENDING STIFFNESS PER UNIT WIDTH A = Ec * (z(1) − z0)

250

Practical Grey−box Process Identification

B = Ec * (z(1)*z(1) − z0*z0)/2 D = Ec * (z(1)*z(1)*z(1) − z0*z0*z0)/3 for i = 1:3 A = A + Ecb(i) * (z(i+1) − z(i)) B = B + Ecb(i) * (z(i+1)*z(i+1) − z(i)*z(i))/2 D = D + Ecb(i) * (z(i+1)*z(i+1)*z(i+1) − z(i)*z(i)*z(i))/3 end Sb = D − B*B/A % BENDING STIFFNESS INDEX A = (BW+BWc)/0.1 BSI = Ksi * Sb/(A*A*A) % Note: The instrument factor is % Ksi = 3 * depression * width/(length^3) of the test sample

Argument Classification  The entries in the Argument classification window follow immediately: : All dependent variables, except BSI are Internal. : The properties of the cardboard Hcb,Ecb,Hc are Feed variables, to be determined by a not yet defined source component. : Since the coating substance is not changed, its strength Ec is classified as Parameter. : The basis weight of cardboard BW and coating BWc affect BSI in two ways, namely indirectly through the thicknesses Hcb and Hc, and directly through the standardized normalization of the index. They are both variables determining the specifications of the cardboard, and measured with relatively high accuracy. Classify them as Control variables. : Ksi has the standardized value of 12.6 [1000/m]. Classify it as Constant.  Edit the Argument classification window: Argument

Class

Component output z0 z A B D Sb BSI

Internal Internal Internal Internal Internal Internal Response

Component input Hc Hcb Ec Ecb BW BWc Ksi

Feed Feed Parameter Feed Control Control Constant

I/O Interfaces  Specifying the sources of the input and the possible targets of Response arguments is also immediate:

7 Quality Prediction in a Cardboard Making Process

251

: BSI is measured manually and the results are in the sample file. Select Sensor, even

though this means envisaging a ‘sensor’ that delivers its results only sparsely in time. Missing values are indicated by NaN in the file. : Hc, Hcb, Ecb are not measured and are to be determined by another component. : BW, BWc are measured, and it would be possible to select input interpolation models as their sources, and thus to include the latter as part of the Lab component. However, they are also input to other places in the process, and this makes it advantageous to use a common model for the data input. Select therefore User model.  Edit the I/O interface window: Argument

Source

Connections to sensors BSI Sensor Hc NoSensor Hcb NoSensor Ecb NoSensor

Feed input: Source model Hc User model Hcb User model Ecb User model

Control input: Source model BW User model BWc User model

Argument Attributes The Argument attributes window is the second most important entry point for prior information (after the function statements). Considering the entries carefully will save troubles later:  The following are some hints to support the specifications: : Since the variables are many, it is important to associate them with informative Short descriptions, including units. : Dimensions are required for arguments that are arrays: namely z, Hcb, Ecb. They follow immediately from the statements. : Since Hcb and Ecb are arrays, their scales and nominal values must be specified implicitly using labels. (A numeric value would be interpreted by MoCaVa as valid for all elements in the array.) : Even for other reasons will it be advantageous to use implicit specification: In this way, variables sharing scales and/or nominal values will need to be given numerical values only once. For instance, BW and BWc share scales, but not nominal values. However, they appear in other components, and are given implicit nominal values for that reason. Ecb will share both scales and nominal values with other tensile strength variables upstream in the process. : The arguments associated with the output, namely BSI and rms_BSI will not appear elsewhere, and may therefore be given numeric attributes. : Both Ec and rms_BSI are positive parameters, which is indicated under Min. Also the Control and Feed input are positive. However, the boundaries need not be specified, since they would have an effect only if the input would not be connected to other components and instead fitted as parameters.

252

Practical Grey−box Process Identification

 Edit the Argument attributes window: Argument

Short description

Dim Scale

Nominal

Min

Parameters Ec rms_BSI

TensileStrengthCoating [N/m2] StdError_BSI

1 1

ScaleEc 1*1

NomEc 1*1

0 0

Control input BW BWc

BasisWeight [kg/m2] Coating [kg/m2]

1 1

ScaleBW NomBW ScaleBW NomBWc

Feed input Hc Hcb Ecb

ThicknessCoating [m] ThicknessLayers [m] TensileStrengthLayers [N/m2]

1 3 3

ScaleHc ScaleH ScaleE

Process output BSI

BendingStiffnessIndex [mN]

1

Constants Ksi

InstrumentFactor [1000/m]

1

Internal arrays z

PlyCoordinates [m]

4

Max

NomHc NomH NomE

12.6

Nominal Values and Scaling The values of implicit attributes are specified in the next window. Getting the values requires some prior analysis.  Nominal values can be determined directly or indirectly from the data averages in Table 7.2: : Data averages yield (after units conversion) NomBW = 0.27, NomBWc = 0.02. : The thickness of coating is not measured directly. However, it is related to the basic weight by its density. Assuming a density of 1500 kg/m3 yields NomHc = 0.000013. : NomH requires a prior distribution of the measured average of the total thickness into (say) 1/4, 1/2, 1/4 of 0.000445, yielding NomH = (0.000100, 0.000225, 0.000100). : The remaining values NomE and NomEc are more difficult to find. However, a crude input−output balance of the Lab model will yield the answer: With the same tensile strength E for all layers of the cardboard the bending formula will reduce to S b = E (H c + |H cb|) 12, BSI = K si S b [(w + c) 0.1] 3, where |H cb|is the thickness of the board and H c that of the coating. This yields the balance 3 c cb −3 . Inserting the data averE = BSI × K −1 si [(w + c) 0.1] 12 (H + |H |) ages yields NomEcb = 14.1 × 12.6−1 [(0.27 + 0.02) 0.1] 3 12 (0.000445 + 0.000013) −3 = 3.41·10 12 Remark 7.8. The value may seem surprisingly large. However, it is a consequence of using the same metric unit for all lengths. The value illustrates the obvious: that it would require many milli−Newtons indeed to stretch a one−meter cube of cardboard out to double its length (assuming it does not break). The extreme value also emphasizes the importance of scaling. Using the default scale of 1 would obviously not work for the tensile strength variables.

7 Quality Prediction in a Cardboard Making Process

253

Since the variables are positive, the scales are determined easily from the nominal values by rounding to the nearest power of ten.  Enter the following values into the Implicit attributes window: Attribute

Values

ScaleHc NomHc ScaleH NomH ScaleE NomE ScaleBW NomBw NomBWc ScaleEc NomEc

0.0001 0.000013 0.0001 0.00011 1e12 3.41e12 0.1 0.27 0.02 1e12 3.41e12

0.0001 0.000225 1e12 3.41e12

0.0001 0.00011 1e12 3.41e12

Assigning Data  The next window requires the position in the data file and a units conversion factor. Both have been specified in Table 7.1. There is no units conversion; the instrument factor Ksi serves the same purpose.  Edit the Data assignment window: Argument

Data

Conversion

BSI

KSTY8

1

 The ‘model’ so far has no input variables defined. However, there is still a point in simulating it with nominal input: It is a way to check whether the nominal tensile strength has been computed correctly. It may also reveal a ‘bug’ in the assignment statements of the function specifications.  Select Simulate.  The model output BendingStiffness [mN] in the Plot window agrees with the data average.  Select Reject, however, to indicate that the model class so far is not enough for a meaningful calibration. 7.5.2 The Paper Machine  Select Edit (to change the model library), select Insert (to add a new component), enter PaperMachine (to give it a name), and select Change (to define the component). The Component function window opens again to receive M−statements. Entering Function Statements  A first question in the modelling of the cardboard properties is how to define the bulk and strength variables B and E, since the bulk varies considerably as the fiber mass is transformed from pulp of various concentrations into cardboard in various sections of the paper machine. Mainly, the fibers hold different amounts of water, which affects the bulk. It may be even harder to envisage a property of “tensile strength” in the pulp phase, since pulp will obviously not withstand pulling. However, it is still possible to conceive a remaining bulk property, when water has been removed down to the moisture contents of the finished cardboard. Also a strength property of the dry fi-

254

Practical Grey−box Process Identification

ber is conceivable. Thus, the values of B pc, B mx, B pu, E pc, E mx, E pu should be interpreted as equivalent dry−fiber values. Remark 7.9. If the latter would appear hard to accept, it is still possible to argue that the physical interpretation will not have any affect of the final model, since none of the properties are measured directly. Remark 7.10. The ‘filling’ (various chemicals) added to the pulp may of course also change the bulk and strength of the cardboard. Since no data is available on filling, its effect must be ignored so far, possibly to be modelled later as an unknown factor or even disturbance. Assumption: The fiber properties of relevance to bending stiffness do not undergo significant changes between mixing and pressing. This means that possible effects of varying ‘formation’ on the wires can be neglected. After that, some relations follow immediately: The thicknesses are computed from the basis weights w i and densities à i (inverse of bulk), H i = w i à i = w i B i. The basis weights of the layers are computed by distributing the known total basis weight w according to the mass proportions in the layers: x i = Q i (Q 1 + Q 2 + Q 3), w i = x i w, H i = x i w à i, where Q i is the fiber flow in layer #i. These relations hold at all places in the paper machine. However, at least two phenomena can be expected to change the fiber properties, namely pressing in the two press sections and stretching between ‘wire’ and ‘pope’ (see Figure 7.1). There is no obvious reason for suspecting that the speed of the machine would influence the bulk; however the speed difference may well do, since this stretches the cardboard. The effect on bulk is by no means clear, but here too, mass balances provide partial knowledge: We have v w w w = v p w p, H w = B w w w, H p = B p w p, where the subscripts indicate ‘wire’ and ‘pope’ respectively. Now, if the cardboard would have the elasticity of an isotropic rubber band, its bulk would not be affected, and hence H p = B w w p. If it would be more like a bundle of rubber bands, its thickness would not be affected, which yields H p = B w w p v p v w, i.e., its bulk would increase. Unless the cardboard is perfectly isotropic, its bulk should change something in between, for instance by a factor of 1 + θ v (v p − v w) v w, (0 ≤ θ v ≤ 1) . Introduce therefore θ v as an unknown parameter, with zero nominal value, as a means for testing whether the hypothesis of isotrophy is in agreement with data. Remark 7.11. The way θ v appears in the formula makes it possible to regard it as an empirical coefficient measuring the effect of speed differences (drag), in case one would have difficulties accepting the reasoning on ‘anisotrophy’. Little is known about the effect of pressing, except possibly that the bulk should reduce. With the ‘hot nip’ press there is an open question whether a reduction would be due to some sort of ‘plasticity’ of the cardboard, or to the fact that the press is hot. In the latter case may be expected that it would effect mainly the top layer, since heat penetrates slowly. In the opposite case force would be the main cause of reduction, and the pressing would affect all layers. Assuming that the lasting compression of each layer is proportional to its thickness, the compression would be H i =θ i H i p h, where θi is an unknown ‘plasticity’ parameter. (The possibility that plasticity might be related to elasticity has been ignored, since such a relation would be even more speculative.) The effect of the heat is certainly speculative too, but the same relation will be used, mainly for lack of a better alternative. What is known is that heat has some affect on the cardboard, or it wouldn’t be there. Altogether, the assumed model for the thickness reduction due to hot nip pressing will be g i = exp(− θ bhn p h p h). i The ‘shoe’ press is believed to have smaller affect, and there is no heating. Assume

7 Quality Prediction in a Cardboard Making Process

255

therefore reduction by a common factor of the same type. Remark 7.12. Whenever lack of prior knowledge will not allow the use of well founded relations containing parameters with physical meanings, it is important that the empirical relations used instead have an effective form and that its (fictitious) parameters are scaled properly. Usually, it is possible to make fictitious parameters free of scale by introducing relations of the form scaled parameter = scale−free parameter × rated value, where the first factor expresses the variation and the second the constant scale. This has the advantage that it becomes easy to appraise whether a fitted parameter is ‘large’ or ‘small’. The latter event suggests that it may be worth trying a simpler model without the parameter. In the present case, the exponential form expresses the important prior knowledge that variables are positive. By means of the constant p h the parameters are made free of scale. A small value of θ will indicate that either there is no significant effect of pressing, or else the pressure does not vary enough to reveal any effect of pressing. The possibilities suggest that one try first zero values of the fictitious parameters. The following empirical formula for computing the stiffness will also be used: E i = E pu (à i à i) ν. It contains the new parameter ν, whose value (between 1 and 3) ini dicates how much tensile strength is effected by an increase of density, for instance due to pressing.

Prior Credibility The relations are uncertain. In particular, it is not likely that the formulas for computing density and the change of tensile strength will include all affects of the processing through the paper machine. In order to indicate the uncertainty (which is prior knowledge), introduce two ‘stubs’ s b and s e, in the form of constants with unit values. They will serve as “terminals” for other components refining the paper machine model. In summary, the thickness and stiffness models will be:

p h p h) à i = (s b B pu ) −1 [1 + θ v (v p − v w) v w] −1 exp(θ bs p s p s) exp(θ bhn i i (7.11) = x w à (7.12) H cb i i i e ν pu (7.13) E cd i = s E i (à i à i)

 Enter the following statements into the Component function window: % EFFECT OF SHOE AND HOT NIP PRESSING ON BULK for i = 1:3 Bcb(i) = stubB * Bpu(i) * exp(−CBhn(i) * PressHotNip/nomPhn) Bcb(i) = Bcb(i) * exp(−CBs * PressShow/nomPs) end % EFFECT OF VELOCITY DIFFERENCE drag = (SpeedPop + 1)/(SpeedVir + 1) − 1 if drag > 0.1 drag = 0.1 end if drag < 0 drag = 0 end Gain(1) = 1/(1 − Cdrag * drag) Gain(2) = Gain(1)

256

Practical Grey−box Process Identification

Gain(3) = Gain(1) % DENSITY for i = 1:3 Dens(i) = Gain(i)/Bcb(i) end % THICKNESS Hc = BWc * Bc Q = Qpu(1) + Qpu(2) + Qpu(3) H = 0 for i = 1:3 Hcb(i) = BW * Qpu(i)/Q/Dens(i) H = H + Hcb(i) end % EFFECT OF DENSITY ON TENSILE STRENGTH for i = 1:3 Ecb(i) = stubE * Epu(i) * exp(nu*log(Dens(i)/nomDens(i))) end

Remark 7.13. The limitations to the drag variable are introduced to eliminate the effects of possibly remaining outliers in the speed data. Argument Classification  Again, the argument classification is immediate: : All not previously defined dependent variables are Internal, except H. : The properties of the pulp Qpu,Epu,Bpu are set upstream, and therefore Feed input. : SpeedPop, SpeedVir, PressHotNip, PressShoe, BW, BWc govern the running of the paper machine and are therefore Control input. : CBhn, CBs, Cdrag, nu are dimensionless parameters in heuristic formulas. They are all unknown and to be classified as Parameter. : Bc is the bulk of coating. Its value should be constant, and possible to measure separately. However, since that has not been done, it must be classified as Parameter. : nomPHN, nomPs, nomDens are rated values. Classify them as Constant. : Classify stubB and stubE as Constant.  Edit the Argument classification window: Argument

Class

Component output Bcd Internal drag Internal Gain Internal Dens Internal Q Internal H Response

Component input stubB Bpu CBhn PressHotNip nomPhn

Constant Feed Parameter Control Constant

7 Quality Prediction in a Cardboard Making Process CBs PressShoe nomPs SpeedPop SpeedVir Cdrag Bc Qpu stubE Epu nu nomDens

257

Parameter Control Constant Control Control Parameter Parameter Feed Constant Feed Parameter Constant

I/O Interfaces  Specifying the sources of the input and the possible targets of response arguments is also immediate: : Thickness values H have been recorded in the sample file. Select Sensor. : None of Qpu, Bpu, Epu are measured. Select NoSensor. : Qpu, Bpu, Epu are input from other components. Select User model. : BW and BWc have already been assigned to a separate User model in the definition of the Lab component. : SpeedPop, SpeedVir, PressHotNip, PressShoe are also variables with a direct relation to input data. However, like BW and BWc they will also be input to other units in the cardboard process. Select User model.  Edit the I/O interface window: Argument

Source

Connections to sensors H Sensor Bpu NoSensor Qpu NoSensor Epu NoSensor

Feed input: Source model Bpu User model Qpu User model Epu User model

Control input: Source model PressHotNip User model PressShoe User model SpeedPop User model SpeedVir User model

Argument Attributes  Again, the attributes require more consideration: : CBhn, CEhn, Bpu, Qpu, Epu, nomDens, Bcb, Gain, Dens are three−dimensional arrays. : CBhn, CBs, Cdrag are units−free parameters, and have no effect for zero values. Hence, they have unit scales and zero nominal values. : stubB and stubE enter as factors and are therefore positive with unit nominal values. : nu has an admissible value between 1 and 3.

258

Practical Grey−box Process Identification

: Cdrag has zero nominal value. : Bc is positive with nominal value 0.00067 : The values rms_H measuring output errors will initially have to include modelling

errors, in addition to measurement errors. Therefore, it is usually better to start with higher values than the expected measurement accuracy. The conclusion is also supported by the observation that a search for rms−parameters appears to converge more easily from too high than from too low start values (see the example in section 2.6). Hence, set the nominal value and scale of rms_H somewhat lower than the thickness average 0.000445, even though the actual measurement accuracy would be expected to be much smaller. : Nominal values for SpeedPop, SpeedVir, PressHotNip, PressShow are obtained from the data averages in Table 7.2 (after rescaling). : Since nominal values and scales of Bpu, Qpu, Epu are shared with the Lab component, specify them implicitly, using symbolic attributes. : Set the ‘rated values’ nomPhn, nomPs to the nominal values of the corresponding pressures. (It would have been better to use implicit values instead, thus avoiding the need to enter the same figures twice.)  Edit the Argument attributes window: Argument

Short description

Dim Scale

Nominal

Min

Parameters CBhn CBs Cdrag Bc nu rms_H

HopNipPress−BulkCoefficients ShoePress−BulkCoefficient DragCoefficient BulkCoating [m3/kg] DensiyExponent StDError_H

3 1 1 1 1 1

1 1 1 ScaleB 1 0.0001*1

0 0 0 0.00067 1 0.0001*1

0 0 1 0

Control input PressHotNip PressShoe SpeedPop SpeedVir

HotNipPressure [N/m2] ShoePressure [N/m2] PopeSpeed [m/h] WireSpeed [m/h]

1 1 1 1

10000 100000 10000 10000

54400 488000 19800 19080

0 0 0 0

Feed input Bpu Qpu Epu

BulkPulp [m3/kg] PulpFlows [kg/h] StrengthPulpFibers [N/m2]

3 3 3

ScaleB ScaleQ ScaleE

NomB NomQ NomE

0 0 0

Process output H

Thickness [m]

1

0.0001

Constants stubB nomPhn nomPs stubE nomDens

StubFactorBulk NominalHotNipPressure [N/m2] NominalShoePressure [N/m2] StubFactorStrength NominalBoardDensity [kg/m3]

1 1 1 1 3

1 54400 488000 1 NomDens

Max

3

7 Quality Prediction in a Cardboard Making Process Internal arrays Bcb Gain Dens

Bcb Gain Dens

259

3 3 3

Nominal Values and Scaling  The implicit nominal values are again determined by different means: : The bulk may be computed from the basis weight and thickness, B = hw, assuming that all layers have the same bulk. Hence, from Table 7.2, and after rescaling: nomB(i) = 0.000445/0.27 = 0.00165. The densities are the inverses: nomDens(i) = 606. : The nominal values of the input flows must be determined more indirectly, again by means of a mass balance: The total input flow of fibers is Q = w v p b, where b = 7 m is the width of the paper machine. That is distributed according to the proportions of the mass contents of the layers. Logically, the proportions x are part of the specifications of the quality being produced. However, their values are not in the data file, and must therefore be substituted by estimates. The recorded proportions of pulp being fed into the process yields an obvious source from which to calculate the mass distribution in the layers: The averages follow immediately from Table 7.2, with one exception: Since FFC181 is a volume flow, it must first be converted using the known consistency 42 kg/m3 of the pulp. This yields x = {3350+4218,6239+5680+6270,5520}/31268 = {0.24,0.58,0.18}, and hence nomQ = {0.24,0.58,0.18} x 0.273 x 19800 x 7 = {9081,21946,6811}. Notice that the total output flow is about 20% higher than the input flow. The difference consists mainly of ‘filling’. Again the scales are the nominal values rounded to the nearest power of 10.  Enter into the Implicit attributes window: Attribute

Value

ScaleB NomB ScaleQ NomQ NomDens

0.001 0.00165 10000 9081 606

0.001 0.00165 10000 21946 606

0.001 0.00165 10000 6811 606

Assigning Data  The variable in the data file associated with H and the conversion factor are listed in Table 7.2 as ATJO2 and 1000000.  Edit the Data assignment window: Argument

Data

Conversion

H

ATJO2

1e6

This concludes the definition of the PaperMachine component. Checking the component Again, it is worthwhile to check the function statements and the nominal values.

260

Practical Grey−box Process Identification

 Click Simulate and then OK in the next two windows to confirm that the simulation is to be based on the list of nominal values, and that the two measured output are to be plotted and compared with the data.  The Plot window does not indicate that something is obviously wrong with the nominal values. 7.5.3 The pulp feed  Select Edit and Insert, enter PulpFeed, and select Change. Entering Function Statements  The three flows of pulp Q pu into the paper machine are controlled, in order to maintain flows that are consistent with the prescribed basis weights of the three layers of the cardboard. The basis weight controller uses mass balance calculations to inject the right pulp flows into the paper machine: (This assumes that the pumps actuate the controller signals without error and that consistency measurements are accurate.) Q pu = w b v p x i , where x is the given distribution of pulp to the three layers. Again, i the proportions x are part of the specifications of the quality being produced, but the mx mx mx values have not been recorded. Use therefore x i = Q mx i (Q 1 + Q 2 + Q 3 ). pu pu The bulks B and tensile strengths E are properties of the pulp pumped out of the machine chests and into the paper machine. The corresponding properties into the machine chests are B mx and E mx (Figure 7.10). The machine chests may or may not introduce some significant dynamics into the model, depending of their volumes. With mass contents of about 42 x 10 kg and pulp flows of about (9000,22000,7000) kg/h, this will mean time constants around (0.05,0.02,0.06). The longest is about a third of the sampling time 0.2 h. It is therefore likely a priori that the dynamics will have little effect. However, the estimate is still a crude one, and the actual mass contents may differ. Prepare therefore for a later adding of a dynamic machine−chest model. This can be done by writing B pu = B mx + B mc, E pu = E mx + E mc , where B mc, E mc are ‘stubs’ with the purpose of accounting for possibly significant ‘transient’ effects of the machine chests.  Enter the M−statements: % STATIC MASS BALANCE a = BW * width * SpeedPop/(Qmx(1) + Qmx(2) + Qmx(3)) for i = 1:3 Qpu(i) = a * Qmx(i) Bpu(i) = Bmx(i) + Bmc(i) Epu(i) = Emx(i) + Emc(i) end

Argument Classification  Classification is immediate: : a is Internal and of no interest outside the component. : Qmx, Bmx, and Emx are Feed input. : Bmc, Emc, and width are Constant.  Edit the Argument classification window:

7 Quality Prediction in a Cardboard Making Process

Argument

Class

Component output a

Internal

Component input width Qmx Bmx Bmc Emx Emc

Constant Feed Feed Constant Feed Constant

261

Remark 7.14. The BW and SpeedPop input is not in the list of variables to classify, since this has been done in earlier components. I/O Interfaces  The pulp feed is a unit without direct relation to available data. : None of Qmx, Bmx, Emx are measured. Select NoSensor. : Qmx, Bmx, Emx are input from other components. Select User model.  Edit the I/O interface window: Argument

Source

Connections to sensors Qmx NoSensor Bmx NoSensor Emx NoSensor

Feed input: Source model Qmx User model Bmx User model Emx User model

Argument Attributes  Scales and nominal values of the input are the same as for the output and therefore defined implicitly, except that the nominal values of the ‘stubs’ Bmc and Emc are zero.  Edit the Argument attributes window: Argument

Short description

Dim Scale

Nominal

Min

Feed input Qmx Bmx Emx

FeedPulpMixture [m3/kg] BulkPulpMixture [m3/kg] FiberStrengthPulpMixture [N/m2]

3 3 3

NomQ NomB NomE

0 0 0

Constants width Bmc Emc

MachineWidth [m] TransBulkMachineChest [m3/kg] TransStrMachineChest [N/m2]

1 3 3

ScaleQ ScaleB ScaleE

Max

7 0 0

This concludes the definition of the PulpFeed component. The values of the implicit scales and nominal values have already been defined, which illustrates the advantage of using implicits.

262

Practical Grey−box Process Identification

7.5.4 Control Input  The components defined so far use control input from basis weight, speed, and pressure models, yet to be defined. It is obvious from the data records, and not surprising, that basis weight BW (AKYT2) plays a major role for the variations in thickness H (ATJO2), and that coating BWc (APAL) affects the bending stiffness BSI (KSTY8). Hence, the next step is to associate the input variables BWc and BW with the data.  Select Edit and Insert, enter BWInput, and select Change.  Connecting input variables to data is done in a standard way, the only freedom is that of selecting interpolation routine. The purpose of the component statements is to create two continuous−time variables to receive the results of library routines interpolating between the discrete−time data. Entering Function Statements  M−statements: BW = BWin BWc = BWcin

Argument Classification  The variables have the same classification.  Edit the Argument classification window: Argument

Class

Component input BWin BWcin

Control Control

I/O Interfaces  Try first the simplest interpolation, the Hold.  Edit the I/O interface window: Argument

Source

Control input: Source model BWin Hold BWcin Hold

Argument Attributes:  No nominal values are required, since the variables have been connected to data.  Edit the Argument attributes window: Argument

Short description

Dim Scale

Control input BWin BWcin

BasisWeight [kg/m2] Coating [kg/m2]

1 1

ScaleBW ScaleBW

Nominal

Min

Max

7 Quality Prediction in a Cardboard Making Process

263

Assigning Data:  Again, the names of the associated variables in the data file and the conversion factor are listed in Table 7.2.  Edit the Data assignment window: Argument

Data

Conversion

BWin BWcin

KSTY8 APAL

1000 1000

This concludes the definition of the BWInput component.  Any effects of other control input SpeedPop, SpeedVir, PressHotNip, PressShoe, although likely, are less obvious to the eye. In particular, it may be difficult to distinguish between the effects of PressHotNip and BWc, since the corresponding input data SLT and APAL change their levels almost simultaneously and hence are strongly correlated in normal production. This suggests that the building of a ‘root’ model class stop here, since the latter should include only such parts that are obviously needed to describe the variations in the data. The correct way to proceed would therefore be to go to step 4, “Calibration”, find the best model within the ‘root’ model class, and then continue by testing whether the class is sufficient. In principle, any hypothetical relation may be tested, but this requires first expanding the model class, which means looping back to Step 3, “Modelling”. Thus, an expansion will have to be done sooner or later to test at least the most likely shortcomings of the model so far, and it saves time to do some expansion a this stage. The obvious thing to do is to append models of the two remaining control input, the speed and pressure settings, which may or may not have significant effects on the models response. Notice that this will not change the model’s response, since the nominal values of the gain parameters CBhn, CBs, CEhn, Cdrag are zero. Hence, any test result will not be effected by the expansion of the root model.  Select Edit and Insert, enter SpeedInput, and select Change....  Select Edit and Insert, enter PressureInput, and select Change....  Click Simulate.  MoCaVa shows the responses in Figure 7.11 .  The result confirms that the nominal values of nomQ, nomB and nomE computed from steady−state balances are reasonable. The variations in the model output are mainly the effects of varying basis weight and coating. Apparently the basis weight variations explain most of the variations in thickness, but not all. The variations in coating fail to explain those in bending stiffness, although apparently correlated. However, fitting parameters may improve the model. Again the question arises whether it is time to stop modelling and turn to fitting and testing. And again the argument for considering reasonable expansions to the root model is that it will be needed for testing the hypothesis that the root model class is sufficient. With the current model class as the ‘root’ (or ‘null hypothesis’ in the terminology of statistical testing) one or more ‘alternative hypotheses’ must be defined. Remark 7.15. The issue of when stop modelling and go to fitting and testing is one of practical convenience. It does not matter to the test results whether the expanding components are created before or after fitting and testing the current model class, as long as components are appended with parameter values that make them ‘null and void’. On one hand it pays to do it before, as long as one suspects a priori that the cur-

264

Practical Grey−box Process Identification

Figure 7.11. Results of simulating first model

rent model class will not be adequate. On the other hand it would mean unnecessary work to create expansions to a component before even the unexpanded component has been tested significant. Again, the decision depends on prior knowledge, this time on an appraisal of the uncertainty of the hypotheses a component is build on. Thus, the components created so far define what it needed for the model class to make sense and

7 Quality Prediction in a Cardboard Making Process

265

to include effects that are obvious a priori to be significant. The following components are expansions of the ‘root’ model class and are needed to allow the testing of such hypotheses that are most obviously suspected a priori. The alternatives that suggest themselves follow from the construction of the cardboard machine: The idea of having three layers of board is to increase the bending stiffness by having a bulky middle layer and strong surface layers. It is also the idea that changing the mix of pulp ingredients is a way to control the bending stiffness. Since the nominal values in the present model are constant, they cannot describe the latter effect, and a model allowing Bmx and Emx to change with the variation in pulp feed is needed. 7.5.5 The Pulp Mixing  The mixing of pulp for the three layers takes place in three mixing tanks, which have two, three, and one pulp constituents as input, in addition to sufficient water to keep the volumes constant. As with the machine chests, it is unclear a priori whether the dynamics of the mixing tanks will have significant influence on the pulp properties. The volumes of the mixing tanks are five times those of the machine chests, which means that the time constants are about (0.2,0.1,0.3). Since this is in the vicinity of the sampling interval 0.2h, it would be no surprise if the dynamics would turn out not to be negligible. However, in order to find that out, model the mixing in a way similar to that of the machine chests, i.e., as static mixing plus a ‘stub’ for absorbing possibly significant transients from the mixing tanks. Since bulk and tensile strength are both additive properties, the following property−conserving relations hold: Q mx i =

j∈J i

Qj

=

E mx i =

B

mx i

(7.14)

j∈J i

Bj Qj Q

mt i

(7.15)

j∈J i

mt E j Q j Q mx i + Ei

(7.16)

mx i

+B

where i = 1,2,3, J 1 = {1,2}, J 2 = {3,4,5}, J 3 = {6}, and B mt, E mt are the ‘stubs’.  Select Edit, select Insert, type PulpMixing, select Change, and enter the M−statements: % PULP Qmx(1) Qmx(2) Qmx(3)

FLOW IN LAYERS = Q(1) + Q(2) = Q(3) + Q(4) + Q(5) = Q(6)

% BULK Bmx(1) Bmx(2) Bmt(2) Bmx(3)

IN LAYERS = (B(1) * Q(1) + B(2) * Q(2))/Qmx(1) + Bmt(1) = (B(3) * Q(3) + B(4) * Q(4) + B(5) * Q(5))/Qmx(2) + = B(6) + Bmt(3)

% STIFFNESS COEFFICIENTS IN LAYERS Emx(1) = (E(1) * Q(1) + E(2) * Q(2))/Qmx(1) + Emt(1) Emx(2) = (E(3) * Q(3) + E(4) * Q(4) + E(5) * Q(5))/Qmx(2) + Emt(2) Emx(3) = E(6) + Emt(3)

266

Practical Grey−box Process Identification

Argument Classification  Again, the classification is obvious: : Q is Feed input. : B and E are Feed input. : Bmt and Emt are Constant.  Edit the Argument classification window: Argument

Class

Component input Q B Bmt E Emt

Feed Feed Constant Feed Constant

I/O Interfaces  The only direct relation to data is that Q is measured. However, make a separate component for the relation, in order to facilitate a test of alternative data interface models.  Edit the I/O interface window: Argument

Source

Connections to sensors Q NoSensor B NoSensor E NoSensor

Feed input: Source model Q User model B User model E User model

Argument Attributes  There are six input lines and three output lines, which determines the dimension numbers. Scales and nominal values of the input are the same as for the output and therefore defined implicitly, except that the nominal values of the ‘stubs’ Bmt and Emt are zero. All implicit values except NomQin have been defined previously. The latter has six elements with different values. Also B and E are six−dimensional arrays. However, since it is possible to use equal nominal values for all elements, it is feasible to use the same three−dimensional array of nominal values for the six−dimensional arrays. When an attribute has insufficient dimensionality MoCaVa uses its last value as default values for the missing dimensions.  Edit the Argument attributes window: Argument

Short description

Dim Scale

Nominal

Min

Feed input Q B E

FlowPulpConstituents [kg/h] BulkPulpConstituents [m3/kg] StrengthPulpConsituents [N/m2]

6 6 6

NomQin NomB NomE

0 0 0

ScaleQ ScaleB ScaleE

Max

7 Quality Prediction in a Cardboard Making Process Constants Bmt Emt

TransBulkMixingTanks [m3/kg] 3 TransStrengthMixingTanks [N/m2] 3

267

0 0

Nominal Values  The nominal values of Q are obtained from Table 7.2.  Enter the following into the Implicit attributes window: Attribute

Values

NomQin

3350

4218

6230

5680

6270

5520

This concludes the definition of the PulpMixing component. Data will be assigned through the next component. 7.5.6 Pulp Input  The relation of input flow of constituents Q to the corresponding data is modelled in analogy with the other data input. The only deviation is that one of the flows must be converted from volume to mass flow.  Select Edit, select Insert, type PulpInput, select Change, and enter the M−statements Q(1) Q(2) Q(3) Q(4) Q(5) Q(6)

= = = = = =

Qpine C_birch * Fbirch Qctmp QB75 Qreject QB70

Argument Classification  Edit the Argument classification window: Argument

Class

Component input Qpine C_birch Fbirch Qctmp QB75 Qreject QB70

Feed Constant Feed Feed Feed Feed Feed

I/O Interfaces  Specification of the data interface: : The Feed data look noisy and in need of filtering. However, it is still not evident that the effect of the input noise is significant in comparison with other contamination in the data. Try therefore the simplest interpolation first, the Hold. : Since Hold does not have a parameter to fit to the data, there is no point in assigning a sensor. (The contribution to the overall loss of the prediction error of such a sen-

268

Practical Grey−box Process Identification

sor output would depend only on the data, and would not contribute to the calibration process.)  Edit the I/O interface window: Argument

Source

Connections to sensors Qpine NoSensor Fbirch NoSensor Qctmp NoSensor QB75 NoSensor Qreject NoSensor QB70 NoSensor

Feed input: Source model Qpine Hold Fbirch Hold Qctmp Hold QB75 Hold Qreject Hold QB70 Hold

Argument Attributes  Edit the Argument attributes window: Argument

Short description

Dim Scale

Feedl input Qpine Fbirch Qctmp QB75 Qreject QB70

PulpFeedPine [kg/h] PulpFeedBirch [m3/h] PulpFeedCtmp [kg/h] PulpFeedB75 [kg/h] PulpFeedReject [kg/h] PulpFeedB70 [kg/h]

1 1 1 1 1 1

Constants C_birch

ConsistencyBirch [kg/m3]

1

Nominal

Min

Max

1000 100 1000 1000 1000 1000 42

Assigning Data  Again, the names of the associated variables in the data file and the conversion factors are listed in Table 7.2.  Edit the Data assignment window: Argument

Data

Conversion

Qpine Fbirch Qctmp QB75 Qreject QB70

F197 FFC181 F193 F194 F192 F196

0.001 0.2777 0.001 0.001 0.001 0.001

This concludes the definition of the PulpInput component.

7 Quality Prediction in a Cardboard Making Process

269

7.5.7 The Pulp Constituents  The purpose of adding the PulpMixing and PulpInput components is to describe how the six unknown variables Bmx and Emx (bulk and tensile stiffness of the pulp mixture into the PulpFeed component) may depend on the ten input variables, namely the six input flows, and the remaining four input, refining and the “kappa number” (The latter is a standard measure of pulp properties that is generally considered to have some bearing on paper quality). However, it is also possible that there is no significant effect of refining and the kappa number. In this case the varying Feed input may still cause significant variation in Bmx and Emx, even for constant B and E, provided the entries differ. Since this is the whole idea of mixing pulp with different properties, it would be reasonable to hypothesize that having different pulp properties would be a more important improvement of the model than making the properties vary with varying refinement. This would suggest to proceed with calibrating the model class expanded so far. However again, there are two reasons for adding one more component to compute B and E: : The component is needed to hold ‘stubs’ for a later modelling of the effects of refining and kappa. The introduction of the stubs thus enter the prior knowledge that independence of refining and kappa is an uncertain hypothesis and must be tested. : Even if the six bulk and strength parameters in B and E differ, the differences may not be large enough to reveal themselves in the data. In order to allow for the possibility that common values will do for all constituents, a new parametrization will be needed.  Select Edit, select Insert, type PulpConstituents, select Change, and enter the M−statements: % BULK B(1) = B(2) = B(3) = B(4) = B(5) = B(6) =

OF CONSTITUENTS AveBulk * CB(1) * SBR(1) AveBulk * CB(2) AveBulk * CB(3) AveBulk * CB(4) AveBulk * CB(5) * SBR(2) AveBulk * CB(6) * SBR(3) * SBK

% STRENGTH OF CONSTITUENTS E(1) = AveStrength * CE(1) * SER(1) E(2) = AveStrength * CE(2) E(3) = AveStrength * CE(3) E(4) = AveStrength * CE(4) E(5) = AveStrength * CE(5) * SER(2) E(6) = AveStrength * CE(6) * SER(3) * SEK

The Importance of Parametrization The particular parametrization may be interpreted as follows: : AveBulk and AveStrength are parameters carrying units, which are common to all pulp lines. : CB, CE are arrays measuring the influences of various pulp ingredients in the different layers in the cardboard. They are all units−freeand have nominal values one.

270

Practical Grey−box Process Identification

: SBR, SER, SBK, SEK are ‘stubs’, and thus of no effect until they are possibly re-

placed by output from other components describing the effects of refining and the kappa number. : Any of the factors may be used as ‘stubs’, i.e., locking an arbitrary selection to their nominal values makes it possible to test the hypothesis that any one will not be needed. : The two common parameters AveBulk and AveStrength increase the number of unknowns to 14, of which at most 12 are identifiable. However, this is not necessarily a problem, since not all of them will be freed at the same time. The point of the particular parametrization is that this makes it possible to test the hypothesis that equal factors will do. Argument Classification  The stubs SBR, SER, SRK, SEK are Constant. The other arguments are Parameter.  Edit the Argument classification window: Argument

Class

Component input AveBulk CB SBR SBK AveStrength CE SER SEK

Parameter Parameter Constant Constant Parameter Parameter Constant Constant

Argument Attributes  The attributes follow immediately from the parametrization: : The only units−carrying parameters are AveBulk and AveStrength, which may preferably be given the same implicit attributes as the other bulk and tensile strength arguments. : Other parameters have unit scales and nominal values. : All parameter are positive for physical reasons.  Edit the Argument attributes window: Argument

Short description

Dim Scale

Nominal

Min

Parameters AveBulk CB AveStrength CE

AverageBulk [m3/kg] BulkFactors AverageStrength [N/m2] StrengthFactors

1 6 1 6

NomB 1 NomE 1

0 0 0 0

Constants SBR SBK SER SEK

StubBulkRefining StubBulkKappa StubStrengthRefining StubStrengthKappa

3 1 3 1

ScaleB 1 ScaleE 1

1 1 1 1

This concludes the definition of the PulpConstituents component.

Max

7 Quality Prediction in a Cardboard Making Process

271

Figure 7.12. Block diagram of the root model class

 A block diagram of the model class is shown in Figure 7.12, which is generated automatically from the component specifications.  The model class has now been expanded enough to make a meaningful alternative for testing the hypothesis that the tentative (unexpanded) model is good enough. But first, and in order to detect any obvious faults in the added components, do a simulation of the expanded model.  Click Simulate.  The two windows in Figure 7.13 appear, one stating that the number of signals (= the total number of scalar variables connecting the components) is 49 and larger than the default maximum 32. The other provides a possibility to rectify this.  Increase the value of MAX_NR_SIGNALS, for instance four times.  MoCaVa stores the new maximum sizes (in the ASCII file MoCaVa3\mcvprojects\CardBoard\casedir\status\custom_spec ) and prompts you to exit and restart the session to allow new allocation of memory.  Click OK, Exit, and Start, select Calibrate, select and open CardBoard, click Resume and Simulate again.  Since the parameters in the added components have their ‘null’ values, they do not contribute, and the result is the same as in Figure 7.11.

7.6 Step 4: Calibration  The minimum calibration task is to get the residuals unbiased and their variances estimated. This is achieved by fitting the four parameters rms_BSI, rms_H, AveBulk, AveStrength.

272

Practical Grey−box Process Identification

Figure 7.13. Customization window

7 Quality Prediction in a Cardboard Making Process

273

 Select Accept (the model class) and click OK. Check the boxes after the appropriate parameters, and click OK three times to initiate the fitting. Then click Accept (the tentative model with estimated values). This brings the session to the starting point of the calibration loop, where the user must define one or more alternative structures, either by freeing selections of the remaining bounded parameters, or by expanding the model class. As long as there are unknown parameters in the tentative class, they are obvious tools by which to improve the current tentative model by fitting. It is prudent to free only few more parameter, preferably one, in order to reduce the risk of ‘over−fitting’. However, it is generally not obvious which one to fit first. If the user has some means to decide that, or at least to limit the number of candidates, the calibration session will be shorter. Tentative Model Structure #0  For the first round of tests the most obvious misfit is the response of the tentative model to the hot−nip pressure (Figure 7.14). The bulk parameter array CBhn affects the responses to hot−nip pressure directly. However, it is neither clear that all of the three entries do so significantly, nor which one has the largest effect. MoCaVa3 offers two alternative windows for selecting the parameters to free for alternative structures. The default window is the easier to use. However, its options are limited to those of selecting scalars and whole or truncated arrays. That is not enough for the present purpose, since it would presume that among the three layers in the cardboard the top layer is the most affected, and the bottom layer the least. Instead, it will be necessary to test each combination of individual entries in the two arrays as scalars.  Click Advanced and check the box Primitive Alternative Structures Window. Click NewClass and then OK. An alternative structure may be specified in two ways: i) By checking the boxes to the right of the parameter (arrays) that are to be free, and then create the alternative by checking one of the boxes above the fields displaying the alternatives. This allows any conceivable combinations to be set up. ii) By using the ‘expand’ macro () macro that will implement the SBE (Stepwise Backwards Exclusion) rule.  Proceed by clicking < for the parameter array CBhn, thus creating three alternative structures, each one having five free parameters. Figure 7.15 shows the setup. The check marks indicate the free parameters in the current tentative model structure (and fitted to define the current tentative model). Click NewDim and then OK sufficiently many times.  The result of the test is shown in Figure 7.16.  The tentative model is falsified, and at least two alternatives are better with zero risk.  Click Select_#2 (to acknowledge that the alternative with free CBhn(2) is better, and also the best). Then click OK three times to fit the new tentative model. Tentative Model Structure #1  The obvious way to proceed would be freeing each one of the remaining parameter entries in CBhn and possibly also the other parameters in PaperMachine, until either no alternative is better, or else all have been freed and fitted. It is quite straightforward to do this by repeated use of the “