A SOFTWARE ENVIRONMENT FOR VERIFIABLE MODELING AND SIMULATION. Amanda Grace Rapsang Arjun Saha Kannan M. Moudgalya G. Sivakumar

Transcription

1 A SOFTWARE ENVIRONMENT FOR VERIFIABLE MODELING AND SIMULATION Amanda Grace Rapsang Arjun Saha Kannan M. Moudgalya G. Sivakumar Department of Chemical Engineering Department of Computer Science and Engineering Indian Institute of Technology, Bombay, Mumbai Abstract: We report the progress in development of a software that can simulate and verify applications from various types of engineering domains. In this work, complex circuits are broken down into connected constituent blocks. We model each block by a Block Definition Language (BDL). An application can be modeled by a Model Definition Language in which BDLs are interconnected. Declarative features used give the facility to express properties and constraints. This approach is also Object Oriented. Keywords: Software Environment, Modeling, Simulation, Process Control, Verification 1. INTRODUCTION Simulation is an important activity in the modern industry: it is used in process design, optimization, controller design, controller implementation, what if analysis and debottlenecking studies, to name a few. These are time consuming activities. Finally, these can be done only by highly skilled and trained manpower (Rao 1998). It is clear that we need a simulator to support these activities. The simulator should allow reuse of models, group effort and existing pieces of code, such as, state of the art solvers. Finally, it should allow us to verify that the results given by the simulator are correct. With these in mind, we have been developing a simulator at IIT Bombay, with the following interesting features. The Block Definition Language (BDL) can be both static and dynamic depending on the domain. Each input to a block can have one or more parameter, i.e., an input can be a multivalued input. Each basic block can be combined together to form a super block, which can be used as a basic block. The application builder has the capability to enable user to add components of the design by a click and drag of the mouse as well as adding a number of similar block at once by specifying the parameters needed, such as block type, number of blocks needed, spacing between them, etc. Some of the variables in the dynamic BDL, such as enthalpy of the input stream to the block, will need domain knowledge. This information can be obtained from the domain database. This interaction with the database

2 and also constant updation of the database for unknown components and their properties entered by the user, helps the system work at the domain level. Verification or checking of system correctness of an application system can be done by interfacing the tool with some already existing verification tool. Object oriented approach is used for designing the tool. 2. FLOWSHEET DESIGN OF THE TOOL The flowsheet of the tool design is given in Fig. 1. Each block is modeled by a BDL. The BDL can be both static and dynamic depending on the domain. For example, in the hardware domain, static BDLs are mostly used, whereas in the chemical engineering domain, the BDLs need to be dynamic as equations are structured which depend on some conditions which are known only at run time (e.g., number of components). Dynamic BDLs are written in structured loop forms which are expanded when runtime conditions are known. The BDL generator sends the corresponding block equations at the time of flowsheet generation. The GUI for building blocks enables the user to define basic blocks (both static and dynamic). It can take existing BDLs from the Block Class Library and the user can then modify or combine them. These new BDLs can then be added to the Block Class Library for re-use at a later time. The Application Builder is the front end where the user designs his application. The graphical application is then converted to Model Definition Language (MDL) which is composed of BDLs interconnected together. For building an application, the user can click on a button for a particular block desired or can specify the type and number of blocks needed and how they are to be interconnected together. This parameterized way of drawing blocks to a GUI is a new method which helps simplify the task. The Parser generates from the MDL executable code along with the necessary domain equations. The executable code is generated to perform the function of each block needed during simulation. The equations which compose of Block Equations i.e. equations of each BDL and connectivity equations, when the blocks are interconnected together. In some cases such as the Distillation Column System, where the connectivity equations are structured, MDL Templates are written. Whenever the user wishes to simulate for different number of components, the system would generate the static MDL from the MDL template. The MDL Generator uses these MDL templates and BDLs to give the final MDL. In the Post-Processing, Simulation and Animation phase, the user can provide inputs for simulation such as, timer delay and initial values. As explained in Sec. 2.3, a solvable set of equations are obtained. These equations are sent to a solver for solution and the results are displayed. We will next present examples for the use of BDL and MDL. We will also discuss some of the postprocessing steps. 2.1 BDL In this section we will see how a block is modeled using BDL. The standard types are available: I is type Integer for an input or output and R is real. We can also have types, such as, type V, for voltage and C for current. We can define such domain dependent types. Each function of a block is specified in the FUNCTION. We also have the facility to call domain dependent functions, for example, we can call the VLE function in case of chemical engineering. For a condenser, the BDL is as follows: BEGIN BASIC BEGIN DEFINE NAME Condenser SHAPE R END DEFINE BEGIN PROPERTY n : I i : I M[n]: Dat1 P[n]: R T[n]: R END PROPERTY BEGIN INPUT NAME A TYPE MULTI NAME V[n] TYPE Dat1 END INPUT BEGIN OUTPUT NAME B TYPE MULTI NAME LO[n] TYPE Dat1 NAME D[n] TYPE Dat1 END OUTPUT FUNCTION chemical subroutines BEGIN HV[n] = HV finder() HLO[n] = HLO finder() END

3 Domain Knowledge (Access to domain database) Parser MDL Block Equations Connectivity Equations ExecutableCode (for blocks functions) Application Builder MDL Generator Post-Processor Simulation Simulation/ Animation Interface Static BDLs Dynamic BDLs BDL Generator GUI for building blocks User Solver Fig. 1. Tool Design BEGIN EQUATIONS <Sum; i : 1, total components> Sum(M[n].m[i])*d(HLO[n],t)=Sum(V[n].m[i])*HV[n]- (Sum(LO[n].m[i])+Sum(D[n].m[i]))*HLO[n]; </Sum> <for; i: 1,total components> d(m[n].m[i],t)=v[n].m[i]-(lo[n].m[i]+d[n].m[i]); <Sum; i: 1, total components> (LO[n].m[i])/Sum(LO[n].m[i])= (D[n].m[i])/Sum(D[n].m[i]); (LO[n].m[i])/Sum(LO[n].m[i])= (M[n].m[i])/Sum(M[n].m[i]); </sum> </for> END EQUATIONS The BDLs for the tray and reboiler are also the same as for condenser with a difference in equations. Their equations are given below: Equations for Tray: Sum(M[n].m[i]) * d(hlo[n],t) = Sum(F[n].m[i]) * HF[n] + Sum(L[n].m[i]) * HL[n] + Sum(V[n].m[i])*HV[n] - (Sum(LO[n].m[i]) * HLO[n] + Sum(VO[n].m[i]) * HVO[n]); <for; i: 1,total components> d(m[n].m[i],t)=f[n].m[i]+l[n].m[i]+v[n].m[i]- (LO[n].m[i]+VO[n].m[i]); <Sum; i: 1, total components> (LO[n].m[i])/Sum(LO[n].m[i])= (M[n].m[i])/Sum(M[n].m[i]); (VO[n].m[i])/Sum(VO[n].m[i])= K[n][i]*(M[n].m[i])/Sum(M[n].m[i]); </sum> </for> Equations for Re-Boiler: Sum(M[n].m[i])*d(HLO[n],t) = Sum(L[n].m[i])* HL[n] - (Sum(VO[n].m[i]) + Sum(B[n].m[i])) * HVO[n]; <for; i: 1,total components> Lo[n] M[n] V[n] D[n] Fig. 2. Block Diagram of a Condenser d(m[n].m[i],t)=l[n].m[i]-(vo[n].m[i]+b[n].m[i]); <Sum; i: 1, total components> (VO[n].m[i])/Sum(VO[n].m[i])=(B[n].m[i])/Sum(B[n].m[i]); (VO[n].m[i])/Sum(VO[n].m[i])= K[n][i] * (M[n].m[i])/Sum(M[n].m[i]); </sum> </for> P[n] and T[n] stand for Pressure and Temperature of the block respectively. M[n] stands for the liquid holdup of the block (Vapor holdup is neglected) L[n] stands for the input Liquid Stream into the block. L[n] stands for the input Liquid Stream into the block. Similarly, V[n] stands for the input Vapor Stream into the block and VO[n] stands for the output Vapor Stream of the block. In the tray BDL, F[n] stands for the input Feed to the block. In the condenser BDL, D[n] stands for the output Liquid Stream that flows out of the system. In the reboiler BDL, B[n] stands for the output Vapor Stream that flows out of the system. Class Dat1 is a special class used for the chemical engineering domain and is used as follows: If LO[n] be of type Dat1, then LO[n].m[1] is the flowrate of

4 the 1st component of the output Liquid Stream. Similarly LO[n].m[2] is the flowrate of the 2nd component and so on till total components which is the total number of components of the system. For the Condenser Block Equations: All the Equations inside the for loop is expanded at runtime when the number of components total components are known. The 1st Equation is an Enthalpy Balance. HLO[n] stands for the enthalpy of the output Liquid Stream and is calculated by an external subroutine called HLO finder.java. An example of how the Enthalpy for a particular block can be calculated is: H[n][i] = R[A[i](T [n] T ref ) + B[i] 2 (T [n]2 T 2 ref ) + C[i] 3 (T [n]3 T 3 ref )] where A[i], B[i], C[i] are the Enthalpy constants for component i. T ref is the reference temperature specified by domain conditions. Combining all such component enthalpies for any stage we get: H[n] = components i=1 H[n][i] HV[n] and HVO[n] are calculated similarly but are for vapor components (here we add the latent heat of vaporization to H[n]). HL[n] and HLO[n] are calculated for the liquid components. The Sum notation means that an internal loop is formed to calculate recursively the sum of what is present inside the Sum parentheses. E.g. Sum(M[n].m[i]) is equivalent to, for a 2 component system, (M[n].m[1] + M[n].m[2]). The notation d(hlo[n],t) denotes the derivative of the Enthalpy of the Output Liquid Stream with respect to time. Similarly, all the other stream enthalpies are calculated. The 2nd Equation is a component mass balance equation, where the notation The 3rd Equations basically states that since both LO[n] and D[n] have the same composition, their individual component mole fractions can be equated. The 4th Equation does the same for M[n] and LO[n]. For the Tray Block Equations: The 1st Equation is again an Enthalpy Balance, which here also incorporates the Feed Enthalpy since there is Feed to the Tray. The 2nd and 3rd Equation are similar to the ones in the Condenser BDL. The 4th Equation is the VLE equation which relates the mole fraction of each component in the output vapor phase to the mole fraction of the same component in the output liquid phase. The proportionality constant is K[n][i] which is again calculated through an external subroutine called K finder.java. An example of how these K values can be calculated is as follows: K[n][i] = Pc[i] P [n] 14.7 exp[a a 1[i] 2[i] 1.8T [n] 460+a ] 3[i] where, P c [i], a 1 [i], a 2 [i], a 3 [i] are constants for component i. 2.2 MDL When a number of these BDLs modeling different or same type of blocks, are interconnected we get an MDL,i.e., an MDL is a a number of BDLs, connection between them and the equations. An MDL is similar to a BDL in properties, input and output specification. Apart from these, it has the connection specification and also the component blocks. Example for a 3 block, 2 component system is given below: BEGIN MDL /*properties specification*/ /*input specification*/ /*output specification*/ BLOCK reboiler NAME first reboiler END BLOCK BLOCK tray NAME first tray END BLOCK BLOCK condenser NAME first condenser END BLOCK END MDL BEGIN CONNECTION CONNECT connect one FROM V[2] TO VO[1] TYPE FF END CONNECT /*other connections*/ END CONNECTION This lists the connectivity equations of the connected blocks. E.g since the vapor output of block 1 (re-boiler) is equal to the input vapor of block 2 (tray), a sample equation is, V[2] = VO[1]. The final set of equations is shown below: (M[1].m[1] + M[1].m[2]) * d(hlo[1],t)=(l[1].m[1] + L[1].m[2]) * HL[1] - (VO[1].m[1] + VO[1].m[2]) + (B[1].m[1] + B[1].m[2]) * HVO[1]; d(m[1].m[1],t) = L[1].m[1] - (VO[1].m[1] + B[1].m[1]); d(m[1].m[2],t) = L[1].m[2] - (VO[1].m[2] + B[1].m[2]); (VO[1].m[1])/(VO[1].m[1] + VO[1].m[2]) = (B[1].m[1])/(B[1].m[1] + B[1].m[2]); (VO[1].m[2])/(VO[1].m[1] + VO[1].m[2]) = (B[1].m[2])/(B[1].m[1] + B[1].m[2]); (VO[1].m[1])/(VO[1].m[1] + VO[2].m[2]) = K[1][1] * (M[1].m[1])/(M[1].m[1] + M[1].m[2]);

5 (VO[1].m[2])/(VO[1].m[1] + VO[2].m[2]) = K[1][2] * (M[1].m[2])/(M[1].m[1] + M[1].m[2]); (M[2].m[1] + M[2].m[2]) * d(hlo[2],t) = (F[2].m[1] + F[2].m[2]) * HF[2] + (L[1].m[1] + L[1].m[2]) * HL[2] + (V[1].m[1] + V[1].m[2]) * HV[n] - ((LO[1].m[1] + LO[1].m[2]) * HLO[2] + (VO[1].m[1] + VO[1].m[2]) * HVO[2]); d(m[2].m[1],t) = F[2].m[1] + L[2].m[1] + V[2].m[1] - (LO[2].m[1] + VO[2].m[1]); d(m[2].m[2],t) = F[2].m[2] + L[2].m[2] + V[2].m[2] - (LO[2].m[2] + VO[2].m[2]); (LO[2].m[1])/(LO[2].m[1] + LO[2].m[2]) = (M[2].m[1])/(M[2].m[1] + M[2].m[2]); (LO[2].m[2])/(LO[2].m[1] + LO[2].m[2]) = (M[2].m[2])/(M[2].m[1] + M[2].m[2]); (VO[2].m[1])/(VO[2].m[1] + VO[2].m[2]) = K[2][1] * (M[2].m[1])/(M[2].m[1] + M[2].m[2]); (VO[2].m[2])/(VO[2].m[1] + VO[2].m[2]) = K[2][2] * (M[2].m[2])/(M[2].m[1] + M[2].m[2]); (M[3].m[1] + M[3].m[2]) * d(hlo[3],t) = (V[3].m[1] + V[3].m[2]) * HV[3] - (LO[3].m[1] + LO[3].m[2] + D[3].m[1] + D[3].m[2]) * HLO[3]; d(m[3].m[1],t) = V[3].m[1] - (LO[3].m[1] + D[3].m[1]); d(m[3].m[2],t) = V[3].m[2] - (LO[3].m[2] + D[3].m[2]); (LO[3].m[1])/(LO[3].m[1] + LO[3].m[2]) = (D[3].m[1])/(D[3].m[1] + D[3].m[2]); (LO[3].m[2])/(LO[3].m[1] + LO[3].m[2]) = (D[3].m[2])/(D[3].m[1] + D[3].m[2]); (LO[3].m[1])/(LO[3].m[1] + LO[3].m[2]) = (M[3].m[1])/(M[3].m[1] + M[3].m[2]); (LO[3].m[2])/(LO[3].m[1] + LO[3].m[2]) = (M[3].m[2])/(M[3].m[1] + M[3].m[2]); V[2]=VO[1]; V[3]=VO[2]; L[1]=LO[2]; L[2]=LO[3]; 2.3 Post-Processing Steps After the equations are created, values have to be assigned to some variables so that the equations become solvable. The following guidelines are to be used while taking user input: (1) There should be at least one unknown in each equation. (2) Every variable should come in at least one equation. (3) Finally, number of variables should be equal to the number of equations. In the next section, verification part will be dealt with. 3. VERIFYING CORRECTNESS The correct behavior of a system depends on results of computation and on the time on which reactions are performed. In order to verify the correctness of an application, verification tools are needed. While simulation allows the user to exercise their design before implementation, verification ensures that a system correctly implements a specific function (Clarke and Wing 1996). This helps avoid any illogical results and runtime errors that the final simulation might generate. In addition to facilities like design, graphical simulation and code generation, the tool also provide a hook in which verification can be done. For the purpose of verification, a model of the application will be generated. Along with the model, properties of the system to be verified will also be generated. This model along with the properties are then given to a verification tool. The figure below shows the design of the tool with verification facility incorporated into it. The parser in addition to generation of code and equations needed for simulation also generate a model and properties of the application for verification. Currently we are trying to generate a model for HOL(theorem proving program) but we have provide facility in which models in promella for SPIN, spl for STeP, etc can also be generated at a later stage. We will illustrate this by a hardware verification (Kern and Greenstreet 1999) example. Consider the fragment of an adder circuit given below. We wish to verify that o = (i1 + i2 + cin MOD 2) There are three steps involve in doing this: cin i1 i2 Fig. 4. Fragment of an adder circuit (1) write a specification of the circuit in logic (2) formulate the correctness of the circuit (3) prove the correctness of the circuit 3.1 Specify the circuit p Specification of an XOR gate: Xor(i1, i2, o) = (o = (i1 = i2)) Specification of the adder circuit: Add(cin, i1, i2, o) = p.xor(cin, i1, p) Xor(p, i2, o) ML source text: val Xor = Define Xor(i1, i2, o) = (o = (i1 : bool = i2)) ; valadd = Define Add(cin, i1, i2, o) = p. Xor(cin, i1, p) Xor(i2, p, o) ; o

6 Parser User Implementation Properties... OO Simulation environment System Properties Specification Verification Tool Promella Spin SPL STeP... HOL PVS... Domain Verification Model Checking Theorem Proving Fig. 3. Verification facility incorporated into the tool Proof or Counter Example 3.2 Formulate Correctness Abstraction function from bool to num: Bv(b) = if b then 1 else 0 Logical formulation of correctness: cin i1 i2 o. Add(cin, i1, i2, o) Bv o = (Bv i1 + Bv i2 + Bv cin) MOD 2 ML source text: val Bv = Define Bv b = if b then 1 else 0 ; g cin i1 i2 o. Add(cin, i1, i2, o) (Bv o = (Bv i1 + Bv i2 + Bv cin) MOD 2) ; The g function establishes a formula as a goal that we wish to prove The next step is to develop the proof interactively. For this the user has to know HOL. The above example is verification for a hardware circuit. We have to come up with techniques for verifying engineering processes. For example, each conservation equation (e.g. mass balance) has to be checked and validated for the entire flowsheet. This involves collection of the conservation equation in question from all the building blocks of the flowsheet. 4. CONCLUSION In this paper, we have described the design of our tool - flowsheet design, BDL/MDL and verification part. The simulation part have been implemented and the work on verification part of the tool is still being carried on. The tool will generate a model of an application for a particular verification tool, but the user has to know how to use the verification tool. At present, the work for each domain is carried out independently, and integration of all these parts, which will be our next step of work, will give us the complete tool. That the tool is able to simulate applications from different domains is accredited to the parser, which has the capability of interfacing the system with solvers, domain databases and verification tools and the structure of the BDL and MDL, which is able to represent blocks from different domain using the same structure. REFERENCES Clarke, E. and J. Wing (1996). Formal methods: State of the art and future directions. Technical Report CMU-CS CMU Computer Science. Kern, C. and M. Greenstreet (1999). Formal verification in hardware design: A survey. ACM Transactions on Design Automation of E. Systems 4, Rao, S. Hanumantha (1998). A Software Architecture for Modelling and Simulation ofcontinuous Engineering Systems. PhD thesis. IIT Bombay.