4.46 General configuration of process simulation modelFigure 4.47 illustrates the very many compositions of systems of the process sim-ulation model, where each system PEM, consisting of
Trang 1Fig 4.45 Dynamic systems simulation in the blackboard model
To take full advantage of virtual prototyping, it is necessary to develop a mod-elling paradigm that supports model reuse, that is integrated with 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 based 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
Trang 2494 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 library of interaction models can be indexed by their interfaces Candidate interaction models can be selected by searching the library for models 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 between the two components This interaction is captured in the behavioural model and the results represented by graphic display
Modular architecture is the configuration of a composition 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 disadvantage, in that changes made to the initial configu-ration of the composition of systems modify the modular architecture (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 via 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 configuration is 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
Trang 3Fig 4.46 General configuration of process simulation model
Figure 4.47 illustrates the very many compositions of systems of the process sim-ulation model, where each system (PEM), consisting of model components, is con-nected in a series-parallel configuration with object connection modular architecture
at the composition of systems level, and interface connection modular architecture
at the model components level
Logical flows in process equipment models (PEMs) The overall configuration of
a comprehensive process simulation model in a composition 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 Extendc Performance Modelling, each block (model
compo-nent) has connectors that are the interface points of 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
Trang 4496 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 Extendc 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 Extendc
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 evolutionary algorithms The focus is on characterising,
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 design specification This
framework also incorporates optimisation capabilities The Extend c Performance
Modelling program includes an ‘evolutionary optimiser’ 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’
Trang 5Fig 4.48 PEM library and selection for simulation modelling
block generates alternatives and locates the statistically best configuration Unlike external optimisers, the Extendc 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 models have been constructed with
library-based iconic blocks These iconic blocks have been developed using a powerful programming language, namely the Extendc 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
Trang 6498 4 Availability and Maintainability in Engineering Design tool, where each block then describes 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 powerful 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 knowledge source in a blackboard system 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 dynamic systems simulation blackboard model to communicate with other knowledge source applications in the blackboard allows the model to ex-change information with the knowledge base and with the expert 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 other programs For example, an expert system application can start and run 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 Extendc Performance Modelling
program provide the means for exchange information communication of the
dy-namic systems simulation blackboard model, specifically scripting and use of the
Extendc 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-building wizards or self-modifying models 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
Trang 7Fig 4.49 Running the simulation model
an easy method 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 designs 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
Trang 8500 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 vice versa
Creative use of the notebook can result in an effective modelling interface for
a large, complex engineering 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 functional behaviour of the model, its
Trang 9resulting correspondence with the real system, and the correct analytic interpre-tation of the model’s resulting 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 of 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 describing the behaviour of
the real system but, rather, on the ability of the model to predict the results of model
behaviour
Model validation Model validation is the process of developing an acceptable level
of confidence that an inference about the results of a simulated process is a valid in-ference for the outputs of 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, errors 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 probable, though not certain, by
analysis of the assumptions underlying the model, whereby the inductive inferences are analysed through statistical methods
Problem analysis The data generated 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.
Trang 10502 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 probability distribution (non-parametric tests);
• tests to establish the probability distribution from which sample 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 means, 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 parameters 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 be established such that the probability
of the design flow volume being the mean of these two limits is equal to a specified exact probability (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 parameters 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 would include a comparative analysis 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 given in Figs 4.56 through
to 4.59, and case study model evaluation for simulation model sector 3 is given in Figs 4.60 through to 4.63