Handbook of Reliability, Availability, Maintainability and Safety in Engineering Design - Part 52 pdf

4.4 Application Modelling of Availability and Maintainability in Engineering Design 493 Fig. 4.45 Dynamic systems simulation in the blackboard model To take full advantage of v irtual prototyping, it is necessary to develop a mod- elling paradigm that supports modelreuse,that is integratedwith the design environ- ment, and that provides a simple and intuitive user interface that requires a minimum of analysis expertise, as shown in Fig. 4.45. General configuration of process simulation model Many engineered installa- tions have a modular architecture that is b ased on the optimum selection and com- position of systems, assemblies and components from older designs. When the new design is created, these system compositions are selected and then connected to- gether in a configuration. In addition to the dynamics of the systems per se, physical phenomena occur at the interfaces between the system’s components. These interac- tions must also be modelled in an integrated framework that supports the following aspects of interaction modelling: • Model organisation: several models can represent a particular physical phe- nomenon. These models are classified and organised so that the designer is not inundated with choices. An interaction model taxonomy is developed with each (PEM), based on a theoretical formalism to represent and organise the interac- tions. 494 4 Availability and Maintainability in Engineering Design • Model reuse through standardised representation: all interactions between the system composition and its environment occur through the component’s inter- face. Therefore,a libraryof interaction modelscan be indexedby their interfaces. Candidate interaction models can be selected by searching the library f or mode ls with interfaces compatible with the interfaces of the connected components. • Capturing component interaction dynamics: when two components are con- nected via their interfaces, the connection implies that there is an intended phys- ical interaction b etween the two components. This interaction is captured in the behavioural model and the results represented b y graphic display. Modular architectureis the configuration of a compo sition of systems showing what types of modules are components of the system, how many components of each type there are, and how components interact. In object connection modular architecture, the component only has interfaces and does not specify what dependencies it has. Thus, dependencies are created im- plicitly by invoking information from other generic knowledge sources embedded in the blackboard. This has a d isadvantage, in that changes made to the initial configu- ration of the composition of systems modifythe modulararchitecture(e.g. replacing a component causes different connections). In interface connection modular architecture, all dependencies are explicit. In- terfaces define what is required in order to function correctly. Model configuration In many design processes, the target systems are designed using predefined model components.In such processes, these model components are selected, configured and assembled in such a way that the design specifications are met. A model component is a modular design entity with a complete specification describing how it may be connected to other model components in a configuration. For example, a modelled pump assembly has intake and outlet ports to connect it to other model components on each side. The pump’s intake and outlet collectively form the ports or interface to this component. A model component is instantiated in the design by specifying instantiation pa- rameters that describe its specification. Once instantiated, the model component is connected to other instantiated components v ia its ports or interface. Figure 4.46 illustrates several series of model components (in this case, complete PEMs) con- nected together in a general configuration of the simulated process. Composition of systems A configurationis created when two or more model com- ponents are connected to each other via their interfaces. A model component can it- self encapsulate a configuration of numerous model components, thus allowing for a hierarchical structure of systems in a composition of systems. Multiple configura- tions can represent a particular system composition, and are bound to the system’s configuration interface. For example, a process system can be represented as a sin- gle component or as a configuration of several model components. The candidate configurations are all equivalent specifications of the same model components, and the choice of configuration is independent of model behaviour. 4.4 Application Modelling of Availability and Maintainability in Engineering Design 495 Fig. 4.46 General configuration of process simulation model Figure 4.47 illustrates the very many compositions of systems of the process sim- ulation m odel, where each system (PEM), consisting o f model components, is con- nected in a series-parallelconfigurationwith object connection modular architecture at the composition of systems level, and interface connection modular architecture at the m odel components level. Logical flows in process equipment models (PEMs) The overall configuration of a comprehensive process simulatio n model in a compositio n of systems can include a large amount of PEM blocks, each connected to another in many complex flow configurations. There are two types of logical flows between the PEM blocks. The first type of flow represents the items that move through the system. Items can be as- sociated with attributes and priorities. The second type of logical flow changes over time during the simulation run and is represented by values. Examples of values include the number of items in a queue, the result of a random sample, or the level of fluid in a tank. In Extend c  Performance Modelling, each block (model compo- nent) has connectors that are the interface points o f the block. Connections are lines used to specify the logical flow from one block to another. Double lines represent item connections and single lines represent value connections. The concept of value 496 4 Availability and Maintainability in Engineering Design Fig. 4.47 Composition of systems of process simulation model connections in addition to item connections is unique to Extend c  . Other contempo- rary simulation applications require that a function be written whenever a simulation input is based on a value from another point in the model. In the Extend c  Perfor- mance Modelling program, this type of logic is performed without programming of any type. More importantly, the logic of the model is visible to anyone examining the model structure. To simplify the appearance of the model, the connections can be hidden. Optimisation using evolutionaryalgorithms Thefocus is oncharacterising,mod- elling and organising the interactions between model components. The configura- tion also contains analysis models, with rules imposed by a set theoretic formal- ism. The model configuration is based on the context of d esign specification. This framework also incorporates optimisation capabilities. The Extend c  Performance Modelling program includes an ‘evolutionary optim iser’ that employs powerful en- hanced evolutionary algorithms (EA) to determine the best possible model config- uration. Using a drag-and-drop interface, performance metrics and parameters that can be varied are entered into the ‘optimiser’ block. These parameters are used in an equation that defines the objective function. When the model is run, the ‘optimiser’ 4.4 Application Modelling of Availability and Maintainability in Engineering Design 497 Fig. 4.48 PEM library and selection for simulation modelling block generates alternatives and locates the statistically best configuration. Unlike external optimisers, the Extend c  simulation model’s optimisation is well integrated into the program. For example, when the optimisation process is complete, model parameters are automatically set to the optimal configuration. In addition, because the optimiser has been implemented in a block, the source code is available for examination and modification. Model component library The PEM mode ls have been constructed with library- based iconic blocks. These iconic blocks have been developed using a p owerful programming language, namely the Extend c  ModL language. Block dialogs are the mechanism for entering model data and reporting block results. Blocks reside in libraries, and each library represents a grouping of blocks with similar characteris- tics. Blocks are placed on the model worksheet by dragging these from the library window, as illustrated in Fig. 4.48. Logical flow is established between the blocks. Interfaces, components and graphics are created that tailor the model to a specific application. By modifying an existing interface or creating a new one, the simulation modeller develops a model that can be used by someone more familiar with the system than with the simulation 498 4 Availability and Maintainability in Engineering Design tool, where each block then d escribes a calculation or a step in the process. Mod- els can thus be aptly built for the conceptual framework of a collaborative design environment. Model development programming There are several advantages in a dynamic systems simulation development environment applied concurrently in a collabora- tive design environment. Design model builders are able to easily and reliably create new or modified modelling constructs for demanding design modelling situations or new applications. The significance of a p owerful programming language such as ModL further enhances the simulation modelling capability. Traditional simulation languages or scripting environments typically lack full sets of language features such as flexible condition statements ( many are limited to a single condition at a time), user-defined data structures, and user interface development tools. These features are especially suited to the inclusion of dynamic systems simulation as an imbedded knowledgesource in a blackboardsystem.With ModL, only one language and interface needs to be learned and, since ModL is based on the C language, its learning curve is typically short. With less time learning and switching between lan- guages, design model developers are able to develop more sophisticated models in less time. This level of extensibility further prompts designers to develop libraries of custom blocks for specific engineered installations. The ability of the dynamicsystems simulation blackboardmodel to communicate with other knowledge source applications in the blackboard allows the model to ex- change information with the knowledge base and with the exp ert systems within the blackboard, using inter-process communication (IPC) and dynamic data exchange (DDE) capability. Through IPC, the systems simulation model can act as a server application, allowing the blackboard and other knowledge source programs, such as expert system shells, or an artificial neural network (ANN) application, to re- quest that a specific simulation model perform any task that the ModL language allows. The dynamic systems simulation blackboard model can also act as a client ap- plication, requesting data and services from o ther programs. For example, an expert system application can start and r un a specific simulation model, or the simulation model can instruct a spreadsheet to execute a macro and report the results back through the blackboard. Several features of the Extend c  Performan ce Modelling program provide the means for exchange information communication of the dy- namic systems simulation blackboard model, specifically scripting and use of the Extend c  notebook and cloning features. Scripting Scripting is a feature that allows models to be created and/or modified through a suite of ModL functions. With this functionality, designers can create ob- jects that automatically build and modify models. With scripting, designers can de- velop their own model-buildingwizards or self-modifyingmodels. This is especially attractive in a blackboard application. Coupled with the ability to communicate with other knowledge source applications in the blackboard, and with the expert systems within the blackboard using inter-process communication (IPC), scripting provides 4.4 Application Modelling of Availability and Maintainability in Engineering Design 499 Fig. 4.49 Running the simulation model an easy m ethod of allowing applications such as the multi-disciplinary collaborative expert systems to control every aspect of the dynamic systems simulation model, in- cluding building the model, importing or exporting data, and running the simulation with a specific simulation set-up. Running the simulation is initiated by accessing the simulation set-up dialog, which then provides the facility of setting various simulation time properties, as illustrated in Fig. 4.49. Simulation model output Input and output parameters associated with a model can be found in the dialogs of the appropriate blocks or in the output document. While this provides an intuitive association between system metrics and the con- structs used to model these, it can make searching for specific data cumbersome. This is especially true when working with large models containing many layers of hierarchy, typical of engineering design s. An effective way of dealing with this is to use the notebook and cloning feature. With the notebook, a single custom inter- face is created that consolidates critical parameters, results, and model control to a central location. The notebook is a separate window associated with each simula- tion model. Initially, the notebook is a blank worksheet to which text, pictures and clones can be added. Clones are direct links to dialog parameters. Once a clone is 500 4 Availability and Maintainability in Engineering Design Fig. 4.50 Simulation model output results created, any changes to the clone are immediately reflected in the block (or PEM) and v ice versa. Creative use of the notebook can result in an effective modelling interface for a large, complex engin eering design, as illustrated in Fig. 4.50. 4.4.2 Evaluation of Modelling Results The process of dynamic systems simulation evaluation can be divided into three categories: • Model verification, to ensure that the model’s functional behaviour is similar to the real system being modelled; • Model validation, to test the agreement between the results of the behaviour of the model and that of the real system, i. e. determining a correlation between the model’s results and the real system’s output variables; • Problem analysis, which deals with the interpretation of the data generated by the model. In other words, evaluation of dynamic systems simulation is con- cerned with determining the consistency of functionalbehaviour of the model, its 4.4 Application Modelling of Availability and Maintainability in Engineering Design 501 resulting correspondence with the r eal system, and the correct analytic interpre- tation of the model’s resultin g data. Model verification Model verification implies proving that the model is function- ally true according to a set of functional criteria that is applicable for comparison between the model and the real system (i.e. similar types of exogenous, status and endogenous variables). The problem of model verification can thus be reduced to the problem of searching for a set of basic assumptions underlying the functional behaviour of the real system. Such a procedure requires the formulation of a set of postulates or hypotheses describing the behaviour of the real system. This includes the specification of model components and the selection o f variables, as well as the formulation of functional relationships, all of which are inherent in the dynamic systems simulation blackboard model that is used to control the design knowledge sources and integrate the knowledge-based design applications such as the process equipment model (PEM) blocks. The design knowledge base and design knowledge sources form the core of an integrated design support system that enables model verification. The following fig- ures illustrate the design details of these PEM blocks for the various simulation model sectors. In contrast to model verification, the validity of a model depends not on the formulation of a set of postulates or hypotheses d escribing the behaviour of the real system but, rather, on the ability o f the model to predict th e results of model behaviour. Model validation Model validation is the processof developingan acceptable level of confidence that an inference about the results of a simulated process is a valid in- ference for the outputs o f the real system. The problem of model validation can thus be reduced to two characteristic problems: to validate the results of a specific model’s function, and not the mechanism that generated the results, and to compare the input-output transformations generated by the model to those generated by, or specified for, the real system. In the use of dynamic simulation models to represent real systems, different types or classes of error can result, any one of which can lead to erroneous conclusions, such as errors in model design through the exclusion of significant variables, er rors in the modelling approach whereby relevant variables may be represented incorrectly, and errors in programming, input data, or interpre- tation of results. The validity of the model is made p robable, though not certain,by analysis of the assumptions underlying the model, whereby the inductive inferences are analysed through statistical methods. Problem analysis The data g enerated by computer simulation models represent, in effect, the inductive reasoning of the modelling process as the conclusion of a set of inductive inferences, i. e. assumptions of behavioural results or the out- come of operating characteristics about the behaviour of the real system. The rules for analysing the data generated by computer simulation models are predominantly statistical sampling rules based on the theory of probability. Statistical tests used for analysing these assumptions, and also conclusions of the inductive inferences drawn from simulation runs of the model are, in general, hypothesis testing and estimation. 502 4 Availability and Maintainability in Engineering Design Hypothesis testing normally includes the following: • tests on estimates of parameters assuming an underlying probability distribution (i.e. parametric tests); • tests on estimates of parameters that are not dependent on assuming an underly- ing p robability distribution (non-parametric tests); • tests to establish the probability distribution fr om which sam ple data are gener- ated (goodness of fit tests such as Kolmogorov–Smirnov and Chi-square tests); • tests on the relationship among variables (correlation analysis). Estimation includes the calculation of point and interval estimations of parameters, as well as a determination of quantitative equations relating two or more variables (i. e. regression analysis). Statistical methods used for hypothesis testing and esti- mating are, therefore, mainly tests of mean s, analysis of variance and covariance, goodness of fit tests, regression and correlation analysis. The results of dynamic simulation models are often used to determine estimates of the param eters of the response variable or, in this case, the flow volume and/or mass flow consisting of liquid and solids. Because these values are estimates, it is essential to assess their accuracy, which is usually done by placing confidence bands or intervals about the estimates. For example, if the simulation model estimate of the mean flow volume of a particular PEM is a value designated by ¯ E, and the design flow volume is μ , an upper limit UL and lower limit LL could b e established such that the probability of the design flow volume being the mean of these two limits is equal to a specified exact pr obability (using the t-distribution as inference). Dynamic systems simulation case study The case study selected to determine the applicability of dynamic systems simulation modelling in evaluating and verifying process design integrity of complex integrations of systems is a typical alumina refinery process. The data given in Tables 4.14, 4.17 and 4 .20 are extracts from a dynamic systems simulation case study (simulation model sectors 1, 2 and 3), and represent preliminary design data of the real system process p arameters of flow vol- ume, mass flow, solids content and liquid content used in alumina production. The estimates of the maximum, minimum and mean flow volumes of each PEM in the specific sectors are given in the simulation model’s output notebook. Validation of the dynamic systems simulation wouldinclude a comparativeanalysis of the prelim- inary design data of the real system process parameters, as listed in the tables, with the model parameter estimates of each PEM listed in the model’s output notebook. Analysis of the flow volume data generated by the computer simulation model runs would constitute a determination of the confidence intervals about the estimates, such that the probability of correspondence with the design flow volume is equal to a specified exact probability. The case study dynamic systems simulation model evaluation for simulation model sector 1 is given in Figs. 4.51 through to 4.55. Case study model evaluation for simulation model sector 2 is g iven in Figs. 4 .56 through to 4.59, and case study model evaluation for simulation model sector 3 is g iven in Figs. 4.60 through to 4.63. . simulation is con- cerned with determining the consistency of functionalbehaviour of the model, its 4.4 Application Modelling of Availability and Maintainability in Engineering Design 501 resulting correspondence. (IPC), scripting provides 4.4 Application Modelling of Availability and Maintainability in Engineering Design 499 Fig. 4.49 Running the simulation model an easy m ethod of allowing applications. choice of configuration is independent of model behaviour. 4.4 Application Modelling of Availability and Maintainability in Engineering Design 495 Fig. 4.46 General configuration of process simulation