Siemens Develops a Dynamic Turbine Simulator for Steam Turbine Controller Examination

Author(s):
Eckart Brackenhammer - Siemens
Eberhard Schmidt - Siemens

Industry:
Energy/Power

Products:
Simulation Interface Toolkit, Real-Time Module, PXI-8176, LabVIEW, PXI-6733, PXI-6052E, PXI-6527, PXI-1042

The Challenge:
Creating a real-time simulator for steam turbine controller factory acceptance tests (FAT).

The Solution:
Using NI LabVIEW, LabVIEW Real-Time, the LabVIEW Simulation Interface Toolkit and PXI-1042, PXI-6527, PXI-6733, PXI-6052E, and PXI-8716RT modules to create a real-time simulator.

Performing Quality Assurance Tests

Before delivering an automatic steam turbine controller to our customer, we test the turbine regulator hardware and software. The FAT is a product quality assurance program component. We test the automatic controller under different operating conditions to detect disturbances in the system. Often, customer representatives bring their own test points into the inspection report. We deliver the turbine controller only after a successful test conclusion.

For FAT execution, we must close the turbine controller automatic control loops using a simulated, controlled system. We developed a real-time turbine simulator, which is attached to the turbine controller I/O signals. The simulator computes the appropriate process variables from the turbine controller, adjusting signals as feedback. For the computation, we provided a dynamic processing model, consisting of a steam generator and turbine, rerouting stations, condenser, generator, and electrical net. With this model, we can test the different operation modes, including the turbine starting within a specified revolution rate, the turbine operating under load or pressure control, load decreases under idle operation, load removal and turbine shutdown. In addition to the actual functional test, the turbine simulator can aid in parameter tuning and optimization in the field prior to operation. We deliver a simple turbine controller model so the customer can operate the turbine simulator when a test turbine is unavailable.

To test different steam turbine controller types, the simulator offers 16 analog I/O and 24 digital I/O. In addition, the simulator also features:

• 2 ms cycle time
• Deterministic real-time performance
• Portability and field connectivity
• Module programmability

We divided the turbine simulator development into three phases.

Selecting the Simulator System (Phase 1)

We evaluated various real-time systems for hardware and software development capabilities. Our requirements included performance, simple programmability, visualization surface, input and output hardware interfaces (driver functions), and mobile serviceability. Also, we needed to port turbine models written using The MathWorks, Inc. MATLAB® and The MathWorks, Inc. Simulink® software simulator from our turbine work. We decided to use a system with the following components:

• NI PXI-1042 with NI PXI-8176 real-time controller
• NI PXI-6527 (digital card with 24 digital inputs and 24 digital outputs)
• NI PXI-6733 (two 8-channel analog output cards with 16-bit resolution)
• NI PXI-6052E (two multifunction cards with 8 analog inputs)
• NI LabVIEW
• LabVIEW Real-Time Module
• LabVIEW Simulation Interface Toolkit

Structuring the Signal Conditioning Rack (Phase 2)

Due to different analog signal levels exchanged between the steam turbine automatic controllers and simulator, we first must convert them. The steam turbine automatic controller supplies +/- 20 mA signals at the output and needs 4 to 20 mA signals at the input. Also, for the speed measurement, we need three frequency signals within the range of 0 to 3.6 kHz. The PXI modules work with a signal level of +/- 10 V. For signal conditioning, we developed a 19 in. rack from ATR Industrial Electronics to quickly and easily attach to the prefabricated PXI cables.

Executing the Environment Development to Manage the Hardware Channels (Phase 3)

We use the clocks on the PXI hardware modules to guarantee the simulator real-time performance. A multifunction data acquisition module (PXI-6052E) provides a continuous clock pulse via the backplane bus (RTSI) to trigger the other modules simultaneously. We run the computing simulation model loop with the same clock pulse. We specify the clock pulse in the program (e.g., 500 ticks/s = 2 ms) and can adapt it if the real-time test recognizes errors.

The loop execution always consists of two partial stages. In the first partial stage, the system reads the input signals and passes the computation results from the preceding loop to the outputs. In the second partial stage, the system computes the model with the previously read values and pushes the calculated values into the shift register for use in the next loop cycle.

Using LabVIEW, we set the control simulation and I/O loop to time-critical priority. As a result, no other loops can interrupt or block it when it is operating. This ensures real-time deterministic simulation loop behavior.

The simulator consists of two separate programs and computer systems. The first system is the PXI real-time system with the NI PXI-8176 controller running a real-time OS that calculates the model. The second system is a laptop (host) with Windows 2000 and LabVIEW, which contains the user interface and the model parameter computation. We connect the host and real-time system via standard TCP/IP. We downloaded the simulation routine onto the real-time system from the host laptop. Then, the host runs a Windows-based user interface.

Because the simulator test must exchange data between the host and the real-time system time-critical program without handicaps, the system transfers the data via real-time FIFOs. Using the real-time FIFOs, the system exchanges signals between the model, the user interface, and the hardware interface. The host system supplies the model with parameters, which the host calculates from geometry and turbine thermodynamic sectional view data.

The operator can set different operating conditions, and the user interface displays them as well as important process variables, e.g., turbine revolution number, pressure before turbine, and turbine control valve openings. Additionally, the system can call diagrams, which represent these process variables as well as the turbine controller output variables over the time axis on the control surface. To maintain clarity of the model structure and host function and easily adapt to different turbine types, we pursued a strictly modular structure. This is particularly important so that users without advanced LabVIEW knowledge can make simple changes and adjustments.

We built the process model in a strictly hierarchical manner. To supply the different model modules with parameters and provide the necessary data exchange between the hardware and user interface, we used data fields (arrays) that are converted into clusters. We use clusters because we can use them to name both the individual elements (data) and the structure. Clusters are hierarchical; the nesting depth corresponds to that of the module with which the cluster is connected. The clusters are present throughout the entire model as a data pipe. The submodules extract the data using the unbundle by name function in the different hierarchy levels. Unfortunately, the system must transform data from and/or into arrays because only arrays can be transferred over the real-time FIFOs. So that the simulator can adapt to the different turbine types, we must only modify or exchange the turbine module for another, i.e., a module for a two-pressure-stage turbine.

Fulfilling Performance Requirements

Our first simulator tests fulfilled performance requirements (the entire processing concept is counted in 2 ms) and handling (change projection and operation) requirements. Although the most difficult element was developing the execution environment, which must be completely provided by the LabVIEW user, we successfully completed these project phases using NI products.

Because of the high demand for this dynamic turbine simulator system, we decided to develop an additional simulator system for different turbine controller testing at the same time. For the new system, we again used a PXI system with real-time controllers (PXI-1042 and PXI-8176). To increase possible control loop rates, we changed the I/O hardware of the first system to three FPGA I/O cards (PXI-7831R) because these cards make signal input and output parallel processing more efficient. Additionally, the driver for the FPGA cards produces less CPU load than the driver for traditional DAQ or the NI-DAQmx cards. As a result, we use higher-computational models.

We also changed the model representation from standard LabVIEW to the new LabVIEW simulation module. With this toolset, which was developed especially for simulation, we simplified the simulation model realization, particularly when we used some model parts that were realized before with MATLAB and Simulink. We can translate these parts directly to LabVIEW using the Simulink Translator.

MATLAB and Simulink are registered trademarks of The MathWorks, Inc.

Author Information:
Eckart Brackenhammer
Siemens
Germany
Tel: +39-06-22541217
eckart.brackenhammer@siemens.com

Browse All Case Studies »