下载文档原格式
MIKE 21/3 FLOW MODEL FM沙模块用户使用手册目录（Contents）目录（Contents） (1)1 关于本文档（About this guide） (3)1.1 编写本文档的目的(Purpose) (3)1.2 用户所需的知识背景(Assumed User Background) (3)1.3 MIKE Zero 模型编辑器程序界面结构(General Editor Layout) (3)1.3.1 导航栏(Navigation tree) (3)1.3.2 编辑窗体(Editor window) (3)1.3.3 有效性显示窗体(Validation window) (4)1.4 在线帮助系统(Online Help) (4)2 引言(Introduction) (5)2.1 概述(General specification) (5)2.1.1 适用范围(Application areas) (5)3 说明(Getting started) (6)4 示例(Examples) (7)4.1 概述(General) (7)4.2 U 型河道示例(U-shaped flume) (7)4.3 环流示例(Sand transport in circulation current) (7)5 沙模块（Sand Transport Model） (7)5.1 模型定义（Model Definition） (7)5.1.1 概述（General description） (8)5.1.2 床面活动层厚度（Layer thickness） (8)5.1.3 驱动力参数（Forcing parameters） (8)5.1.4 单一水流工况（Pure flow） (8)5.1.5 波流共同作用工况(Combined current and waves) (9)5.2 时间参数（Time Parameters） (10)5.3 求解格式（Solution technique） (10)5.3.1 备注与提示（Remarks and hints） (11)5.4 泥沙特性（Sediment properties） (11)5.4.1 泥沙特性（Sediment properties） (11)5.4.2 推荐取值（Recommended values） (12)5.5 床面阻力（Bed resistance） (12)5.5.1 概述（General description） (12)5.5.2 参数取值（Data） (13)5.5.3 推荐取值（Recommended value） (13)5.6 驱动力参数（Forcings） (13)5.6.1 波浪（Waves） (14)5.6.2 水流（Flow） (15)5.7 扩散（Dispersion） (16)5.7.1 平流扩散(Horizontal dispersion) (16)5.7.2 对流扩散（Vertical dispersion） (17)5.7.3 推荐设置（Recommended values） (17)5.8 源汇项（Sources） (17)5.8.1 源汇项设定（Source specification） (18)5.8.2 备注与提示（Remarks and hints） (18)5.9 初始条件（Initial Conditions） (18)5.9.1 泥沙粒径组分浓度（Fraction Concentration） (19)5.9.2 床面活动层厚度（Layer thickness） (19)5.10 边界条件（Boundary Conditions） (20)5.10.1 边界设置（Boundary Specification） (20)5.11 地貌演化模块（Morphology modoule） (21)5.12 输出（Outputs） (21)5.12.1 图形化查看（Geographic view） (21)5.12.2 输出类型（Output type） (22)5.12.3 输出项（Output items） (26)6 地貌演化模块（Morphology module） (29)6.1 概述（General description） (29)6.2 模型定义（Model definition） (29)6.3 时间参数（Time Parameter） (30)6.4 河岸侵蚀（Bank Erosion） (30)6.5 边界条件（Boundary conditions） (30)6.5.1 边界说明（Boundary specification） (30)1 关于本文档（About this guide）1.1 编写本文档的目的(Purpose)编写本文档的主要目的在于指导用户使用MIKE 3 Flow Model FM 模型中的沙模块（非粘性泥沙输移的计算）。
Advanced Process Control in the Plant Engineering and Construction PhaseVassilis Sakizlis∗, Andy Coward♠, Kumar Vakamudi♣, Ivan Mermans♠.1. IntroductionThe profit in process industries is a function of effective plant operation. This energy and economic based incentive leads to the development of advanced operation and control strategies (See Qin and Badgwell, 2003; Christofides et al., 2008).The success of advanced control in the oil and gas industry, in particular, over the last 30 years is widely acknowledged. Successful applications have been reported in olefin plants (Shindo et al., 2004), refineries (Moro and Odloak, 1995; Haseloff et al., 2007) and gas plants (Hotblack, 2004; Honeywell 2005). Payback times of a few months have been achieved, in addition to improved economics by 5-10%. The success of these projects is attributed to increased profit margin and reduction in the energy consumption. Currently, the main research and development trends in that field focus on centralized co-ordinated control for plant – wide solutions (Cheng et al.,2007), non-linear models (Kumar and Daoutidis, 2002) and multivariable optimizing solutions that can be incorporated in a PLC or DCS hardware (Dua et al., 2008).Predominately, however, advanced control is developed, installed and commissioned after the plant start-up. Dynamic simulation may be used to expedite the step testing and plant model development, however, the set-up of the system is still held until at least after the plant commissioning. This conventional strategy (Figure 1) inadvertently introduces a delay in the advanced control implementation and consequently postpones the capitalization of the relevant benefits.∗ Bechtel Ltd. 245 Hammersmith Road, W6 8DP, London, UK.♠ Honeywell Process Solutions, Lovelace Road, Bracknell, Berkshire, RG12 8WD.♣ Bechtel Ltd, 3000 Post Oak Boulevard, 77056, Houston, Texas, USA.Figure 1. Conventional Approach to Multivariable ControlIn the novel work presented here we have minimized this delay by providing advanced process control at the early stages of the process design and engineering. The work concerns the design, testing and installation of advanced control (also termed as multivariable control – MVC) as part of the engineering and construction of an approximately 1300 MMSCFD gas plant in the Middle East.The MVC scope of work as part of the EPC (Engineering Procurement and Construction) phase included:Multivariable Predictive Control hardware and software supply, installation and integration.Development of a dynamic simulation model for testing the MVC performance.Supply and configuration of the DCS-OPC interface communication.This interface comprises software, hardware and the necessary graphicsand logics.The contractor (Eastern Bechtel) managed, supervised and provided information to the vendor (Honeywell) who developed and delivered the MVC.The next section explains the prime terms used in this article. The following paragraphdescribes briefly the process while focusing on the NGL recovery system. Thefollowing sections describe the steps that were followed starting from the dynamic model development for the NGL recovery system and finishing with the MVC training for operators and engineers.2. Definitions−Dynamic simulation model: Non-linear model of the process plant based on first principles and built on a commercial software, e.g.HYSYS, UniSim, gPROMS.−Linear dynamic model. Model derived from plant excitation data. The form of this model can be finite time impulse responses, transferfunctions, state space or AutoRegressive eXogeneous model (ARX).This model is in general used to derive a multivariable control solutionfor the plant.−Multivariable Control (MVC) refers to control algorithms that simultaneously compute the optimal value of a set of manipulatedvariables based on a selected set of current plant measurements. Thecomputation is the on-line solution of an optimization problemconsisting of :an economic or tracking objective functionthe linear dynamic model of the system andperformance and operational constraintsFor more information on MVC that is also called APC (AdvancedProcess Control) or MPC (Model Predictive Control) refer to Quin andBadgwell (2003). The Honeywell proprietary MVC controller is theProfit Controller algorithm and software.3. Process DescriptionThis gas plant facility includes process units for gas and condensate separation, condensate stabilization, gas treating, gas dehydration, NGL recovery and residue gas injection. The simplified plant flowsheet is shown in Figure 2. The main products from the plant are outlined on Table 1.Table 1. Products of the gas plant.No Product Plant Unit1 Condensates C5+ Condensate Stabilizer bottomsand Liquid Separation bottoms2 Natural Gas Liquids(NGL), mostly C3, C2 NGL recovery unit and Liquid Separation bottoms3 Sweet natural gas C1,C2NGL recovery overheadFigure 2. Gas Plant flowsheet.The scope of MVC concerned the three main separation units that are directly linked with the plant production, i.e. the condensate stabilizer and the feed liquid separation unit that remove the heavy components from the gas stream;; and the NGL recovery system that includes a demethanizer distillation column.The unit which attributes most to the plant production and the one which benefits the most from applying the Multivariable Control (MVC) optimization is the NGL recovery system. Figure 3 is a simplified process flow diagram of the NGL recovery system that omits the details that are not relevant to MVC. The NGL Recovery Unit utilizes UOP/Ortloff’s licensed Supplemental Rectification Process (SRP) (US patent number 7,191,617) technology to efficiently recover the ethane from the dehydrated gas while maintaining 99+% recovery of the propane and heavier components for the wide range of ethane recoveries. The resulting residue gas is routed to the residue gas manifold for reinjection after being re-compressed by two compressors in series that control the pressure in the unit.The NGL recovery process includes a multi-stage propane refrigeration circuit toprovide the additional cooling duty required to meet the product specifications.Figure 3. NGL recovery flowsheet and representation of MVC manipulated variables.4. MVC Objectives and Control SchemeHere, we describe the formulation of the control structure for the NGL unit. The same approach was used in the rest of the relevant units.The prime MVC objectives were to•Minimise the C3+ composition in the overhead product and maximize C3recovery in the bottoms product.•Minimise the C2+ concentration in the i.e. in the NGL stream during C2recovery and the reverse during C2 rejection.•Maximise plant production rate.•Minimise plant energy usage.At the same time operational constraints should not be exceeded. For example, the C1/C2 ratio in the bottoms product should be maintained below a designated set-point, while the pressure in the overhead gas stream should not deviate from its given value. To satisfy the aforementioned constraints and objectives the contractor (Bechtel) compiled the set of manipulated and control variables that constitute the MVCstructure. The main selection criteria were:−The manipulated variables (MVs) should have a large impact on the process objectives and constraints. Additionally, the effect of the MVson the process objectives should ideally be immediate without largedelays. For example, reducing the temperature of the feed to thedemethanizer at constant pressure, leads to a reduction in the columntemperature, hence increasing the liquid ethane recovery.−The control variables had to be directly linked to the objectives and constraints of the process. For example the pressure at the columnoverhead is a constraint and therefore, was included in the structure.−The number MVs and CVs should be kept at a relatively low level to avoid complexities during tuning and commissioning and to preventnegative effects on the NGL or other parts of the plant. For example thepressure at the NGL inlet was not used in the structure as it may affectadversely the downstream units.The awareness here of the contractor on the plant operation and design was paramount to the determination of the control structure.5. Configuration and Testing of MVC ControllerBecause the “real” process for this project did not exist at the time of the MVC project, the testing of the developed MVC applications could be handled in one of two ways;•Testing against a “perfect” inverted linear dynamic model with the Profit Design Studio,•Testing of the Profit Controller against the control loops and the process model within a dynamic simulation model.To demonstrate how the Profit Controller would act with unmeasured and process disturbances, the latter option was chosen.5.1. Dynamic ModelA dynamic model of the plant was under construction by the contractor (Bechtel) to conduct design studies and to serve as a platform for the operator training plant simulator (OTS). The development of the model was a joint effort by the Bechtel Advanced Simulation Group and the Bechtel Process discipline of the gas plant project. This model is a detailed representation of the plant steady state and dynamic behaviour. For instance, it accounted for hydraulics, compressor performance curves and the modelling of the dominant stream components. The NGL portion was extracted from the plant model and after a set of modifications it was handed over to the vendor (Honeywell). The main modifications were:1.The boundaries of the unit were modelled as points of constant pressure. Theseare the feed to the unit, the residue gas to the re-injection compressors and theNGL product.2.The two ratio controllers were configured. These were the ratio of the side streamover the feed flow and the ratio of the by-pass to the turbo-expander over the feed flow.3.The settings of level controllers and the column bottoms temperature controllerwere revisited.The original model and the majority of the modifications were developed in HYSYS 2004 by Bechtel. Honeywell read, simulated and edited the model as necessary using UniSim. The compatibility between the two pieces of software obviated rebuilding the entire or parts of the model.5.2. Step Testing for MVC - Profit ControllerAny linear multivariable controller requires dynamic response models of the process it is controlling. These responses are normally obtained by perturbing manipulated variables, i.e. introducing step changes in the setpoint of the control loop (hence step testing.) This activity requires that the process move close to limits and quality constraints and also requires that all other process disturbances are minimised. This limits the operator in his normal role and introduces the risk of going off specification or facing an abnormal situation.By developing a matrix of dynamic responses from the UniSim dynamic simulation, the response models are obtained in a risk-free environment. The time to develop the models is also reduced.The step testing activities alone on a demethaniser would normally take at least a week, even using efficiency tools such as Profit Stepper (closed loop step testing with online model identification) because of the time to the fractionation column takes to reach a steady state after a process move. Utilising UniSim meant that a sequence of step tests could be configured once and then left to run, with the UniSim simulation set to run as fast as possible. This meant that the dynamic model starting from a steady state could be saved and run as required, depending upon the results obtained. Because the process is a simulation, variables that cannot normally be fixed (such as ambient temperature) could also be held constant to improve the overall model quality.If base control loops needed retuning, they could be adjusted and then the step testing sequence run again overnight to provide data for analysis in the morning. On the live process, this activity would require re-testing the process, with delays for the project, additional cost and potentially additional risk for the customer.Results obtained from the UniSim model were extremely encouraging and compared favourably in terms of gains and dynamics to models obtained from a similar unit in another Honeywell project, which had been step-tested using conventional methods. This demethaniser, located in the Middle East, used the same licensor design and provided a good reference for model gains and dynamics. Examples of the responses obtained from UniSim are shown below.Figure 4. Response of C2/C2 ratio to Demethaniser Feed temperature.Figure 4 indicates that if the feed temperature to the demethaniser is increased (gets less cold) then the ratio of methane to ethane in the demethaniser bottoms would increase. This agrees with expectations – less “cold” entering the system with constant reboil would recover less ethane. Similarly, increasing the reboil would decrease the ratio because more methane would be driven up the column. As can be seen, the responses are very clean, with no disturbances and very self-similar models for different settling times. The main benefits from the testing activities via a dynamic simulation model are:a.The linear model derived from the UniSim dynamic simulation can potentially beused for commissioning of the real plant MVC.b.The generation of the dynamic model and subsequently the realistic linear modelenabled the testing of the MVC graphics, databases.c.The models provided insight into the correlations between the manipulated andcontrolled variables that can be essential during commissioning and tuning of the real plant MVC.5.3. Profit Controller Configuration and performance evaluationOnce the linear dynamic model was derived the configuration of the MVC controller was completed in the Profit Design Studio where the objective function weights and constraints are set. This activity allowed the installation of the MVC controller on the real MVC hardware and the generation of the MVC graphics, the MVC database and the MVC-DCS interface.The MVC controller was integrated with the UniSim dynamic model to evaluate the controller performance. UniSim contains an option where MVC can be added to the process - Profit Controller (Figure 5) is one of those options and can be added and then connected to relevant points across the process. In this case, the Profit Controller application was configured to link to the setpoint of all the base control loopsFigure 5. Profit Controller Integrated in UniSim.Controlled variables are also connected to the Profit Controller from different points in the process. Where specific instruments were going to be connected to the Profit Controller, the stream properties (temperature, pressure or flow) at the location closest to where the instrument would be situation were used, converted to the appropriate units to be used at site. Where a property or composition was used, the particular component or stream composition was used as the source value.Utilising the UniSim dynamic model meant that where qualities or compositions were required, preliminary inferential models could also be identified. For example, the online application would require the methane and ethane concentrations in the demethaniser bottoms stream to be inferred by online calculations. Using information from the dynamic simulation, preliminary inferential models were developed and then tested over the expected operational range. The actual inferential models will be validated against the laboratory results once the process is commissioned. Subsequently, the inferential model will be adjusted accordingly if necessary.5.4. MVC Simulated Cost BenefitsDuring the ethane recovery mode, the objective of the MVC application on the demethaniser column was to maximize the recovery of ethane and heavier components from the methane stream and therefore the methodology used was to compare the ethane recovery data both before and after MVC implementation.The UniSim simulations were started and allowed to stabilise; the data for key parameters collected then forming the base case for the pre-MVC scenario. The Profit Controller wasthen switched ON and data collected with Profit Controller controlling the process – thisdata then formed the post MVC case. The comparison of these two cases data provided the expected benefits of MVC on demethaniser column.During a conventional project, this methodology would be very conservative, since improvements in base level control loop design and tuning would also contribute to the overall project benefits. However, in this case, the approach served to highlight the benefits.Following (Figure 6) are trends developed from UniSim Design showing the process data as the MVC was commissioned on the virtual dynamic model based plant.Figure 6. Trends of the C1/C2 ratio and C2 recovery with and without MVCFrom the data extracted from UniSim, the benefits of Profit Controller on the demethaniser are expected to be approximately 1.37% increase in the ethane recovery. This could translate to $5-6m per year savings based on the current NGL and natural gas price.Additional benefits are anticipated if the Profit Controller is allowed to change the NGL unit upstream pressure that consequently controls the feed flow to the unit. However, this variable is currently excluded as it may cause instabilities in upstream units. During the actual commissioning activities the decision to utilise this variable will be re-examined to potentially increase the MVC benefits.6. DCS – MVC InterfaceThe plant DCS was the CS3000 system supplied, configured and implemented by Yokogawa East Asia.The MVC implementation was designed as follows:o The MVC execution software was installed on the MVC server.o The MVC user interface was installed on the MVC workstation to allow monitoring and tuning capabilities.o The MVC server is connected to the DCS via OPC.Redundant links between the MVC server and the DCS OPC servers were employed to enhance the systems reliability. Figure 4 illustrates the architecture.The expected operation is:−MVC server will receive a set of measurements through the plant DCS.−MVC will perform calculations to compute the optimal control actions.−The computed control action will be fed back to DCS controllers in the form of regulatory controller set-points.−The MVC workstation user interface permits the MVC engineer to change the underlying MVC model or even add – remove controllers on the plant units.The DCS had to be configured accordingly to enable the appropriate communication between the two systems. The DCS modifications and the reasons behind them are listed here:6.1. DCS GraphicsAlthough the full operation of the MVC can be performed from the MVC Viewer Workstation, the DCS Human Machine Interfaces (HMIs) should still allow the operator to adjust on-line a selected set of the MVC settings. For example the operator should be allowed to enable and disable the MVC control or manipulated variables. Hence, the DCS vendor developed graphics as per the contractor (Bechtel) and Honeywell instructions. The graphics were integrated with the Yokogawa DCS with appropriate links to the process graphics, while they bear resemblance to the MVC Viewer graphics(Figure 8). This is a feature that can only be materialized at the early construction phase, where there is sufficient time to review the graphics and ensure consistency and compliance with the project philosophy.6.2. DCS logicThe controllers that were admitting MVC set-points had to be configured accordingly to allow an automated switching from the MVC to the DCS mode of operation. Additionally a portion of logic was implemented to fall – back the relevant DCS controllers to a safe mode of operation for the following cases:−Lack of communication between MVC and DCS−Emergency shut down in the plant−Manual selection to switch MVC off.6.3. DCS watchdogThe watchdog timer monitors the health of the Profit Controller applications and the health of the DCS-MVC communication. When either the MVC – DCS communication fails or one of the Profit Controller applications degrades, the watchdog alerts the operator and ensures a safe and seamless fallback from the MVC to the DCS operating mode. Traditionally, the watchdog logic resides in the DCS and one watchdog is implemented per Profit Controller application. Here, there was a limitation on the DCS loading that restricted the installation of the watchdog on the DCS. Thus, a new approach was developed that transferred a portion of the MVC logic to the MVC server.MVC Server sideThe MVC Server part of the watchdog is implemented as a Profit Toolkit application. This application receives a watchdog reset signal from each Profit Controller application it is monitoring. If it does not receive a reset signal in a configurable period of time from one of the Profit Controller applications, then the pertinent Profit Controller application has been degraded or corrupted. Hence, it sends the corresponding shed signal to the DCS. The reset signal is a value that is incremented every time the Profit Controller engine executes. This value is always incremented, even if the controller is not on-line.DCS Server sideThe DCS part of the application performs 2 tasks :• It monitors the health of the communications link between the MVC server and the DCS. To do so, it receives a watchdog reset signal from the MVC server side of the application. If it has not received the reset signal for a configurable period of time, it switches all the DCS base level controllers that are used by all the Profit Controllerapplications, back to their fallback DCS mode. The reset signal is a value that is incremented every time the Profit Toolkit watchdog application executes.• It monitors the health of the Profit Controller individual applications. When it receives a shed signal from the MVC server side for one application, it switches the DCS base level controllers that are used by that Profit Controller application, back to their fallback mode. This configuration (Figure 9) maintains the DCS watchdog logic to a minimum and hence gives priority to the critical tasks of the DCS. This is desirable from an operational and maintenance point of view. Note that this implementation reduces the DCS watchdog loading by ≈80%.Figure 7. MVC hardware architecture and connections with DCS.DCS user interface for MVCMVC Viewer interfaceFigure 8. MVC graphics on MVC workstationFigure 9 DCS and MVC watchdog implementation.7. MVC Testing - DCS integrationWhen any Advanced Process Control application is implemented onto a Distributed Control System (DCS), the entire system must always be fully tested to ensure that communication paths are correctly configured and that DCS displays are correctly configured. Limits and values that are entered into schematics by the operator reside in the DCS and these values are then read up to the Supervisory Computer. Each schematic entry point is checked to ensure that the value is being stored in the correct location and then read correctly into the correct location within the MVC application.Fallback strategies need testing where situations such as network disruptions, power failures or system failures are simulated. In each case, on a live system, there is a risk ofinterruption to the process because mode changes and alarms are being triggered on the system controlling the process.Utilising the dynamic model to develop the Profit Controller application allowed the testing of the integration to be performed in complete safety in the factory. All schemes, fallback logic, control loop mode shedding and schematics were fully tested using the developed Profit Controller and the system architecture that would be in place on site. All Ethernet switches, cables, computers and implementation specifics were tested to ensure that they performed as expected. This significantly reduces the risk on site, but more importantly will reduce delays to the project once the process equipment is commissioned.8. MVC TrainingTraining of operators is a fundamental part of any MVC project, since without the operator’s understanding and acceptance of the technology, it will not be used. The best MVC application, if not accepted by the operator, will never remain turned on.Utilising MVC technology is normally a change from the operator workflow. Because the brownfield sites have been in operation for some time, operators have been trained on how to run the unit and have developed their own way of “driving” the process. Between different shifts, significantly different process performance can be observed when historical data is reviewed. Trying to change this behaviour is time consuming and sometimes problematic.Training the operators in the MVC technology, and how to use it, from the outset means that the MVC operation becomes an integral part of their workflow. Standardising the operational methodology from commissioning onwards also means that the operators achieve the best possible performance, all the time.Because the Profit Controller applications were configured at an early stage, all the operators were trained on what the technology would look like, what the objectives would be, what the schematics would look like and how they would control the process using MVC technology. Their work flow was then defined including using Profit Controller.9. ConclusionsAdvanced control has realised substantial economical benefits to operating companies. However, its conventional implementation postpones its installation and testing until after plant commissioning. In this work (outlined in Figure 10), the MVC project has started long before the process construction is completed. Hence, the long lead time items have been completed before the process commissioning starts:1.The design and requirements of NGL unit MVC applications are well understoodand so can be accomplished with a high degree of accuracy at an early stage. In that respect, the engineering firm that designs and builds the plant uses its experience with plant design and operation to ascertain the MVC control structure.2.Control loop interactions and strategies are tested and proven ahead of time,reducing the process commissioning time.3.Risky and time consuming activities such as the process step testing of the plantproduction units (NGL unit, etc.), DCS interfacing and DCS testing are all performed in a zero risk factory environment and fully tested before the system is taken to site.4.Operators are trained and expect the MVC applications as a part of theirfundamental workflow, rather than having to adapt to using the technology at a later stage.The MVC design, installation, testing and commissioning at site would normally last six (6) to nine (9) months. This new approach of transferring a portion of these activities to the engineering phase reduces the site engagement too step testing and commissioning of the stabilizer and liquid separation unitso validation of the process response model for the NGL unito tuning and monitoring of the MVC controller performance.Hence the duration of these activities can potentially be reduced to around one (1) month. This approach significantly accelerates the benefit delivery and enables an earlier improvement in process operation. It thereby, leads to an early payback of the MVC project investment.Figure 10. Advanced Control prior commissioning. Note in Red the MVC elements in the Engineering Phase.。
