Creating a Shipboard Power Simulation Tool Using
Electrical Load Behavior Modeling
by
LT Thomas Deeter, USN
Submitted to the
Department of Mechanical Engineering
System Design and Management Program
in partial fulfillment of the requirements for the degrees of
Naval Engineer
and
Master of Science in Engineering and Management
at the
MASSACHUSETTS INSTITUTE OF TECHNOLOGY
May 2020
c
○ Massachusetts Institute of Technology 2020. All rights reserved.
Author . . . .
Department of Mechanical Engineering
System Design and Management Program
May 8, 2020
Certified by . . . .
Steven B. Leeb
Professor of Electrical Engineering and Mechanical Engineering
Thesis Supervisor
Certified by . . . .
Bryan R. Moser
Academic Director and Sr. Lecturer
System Design and Management
Thesis Supervisor
Certified by . . . .
Daisy Green
Doctoral Candidate
Thesis Supervisor
Accepted by . . . .
Nicolas Hadjiconstantinou
Chairman, Committee on Graduate Students
Accepted by . . . .
Joan Rubin
Executive Director, System Design and Management Program
Creating a Shipboard Power Simulation Tool Using Electrical Load
Behavior Modeling
by
LT Thomas Deeter, USN
Submitted to the Department of Mechanical Engineering System Design and Management Program
on May 8, 2020, in partial fulfillment of the requirements for the degrees of
Naval Engineer and
Master of Science in Engineering and Management
Abstract
Trends in power system simulation that demand computationally-intensive, physics-based models may impede the acquisition of useful results for applications like condition-based maintenance [1], electrical plant load analysis (EPLA) [2], and the scheduling and tasking of finite generation and distribution resources. A tool that can quickly evaluate many scenarios, as opposed to intense, high fidelity modeling of a single operating scenario, may best serve these applications. This thesis presents a behavioral simulator that can quickly emulate the operation of a relatively large collection of electrical loads, providing “what-if” evaluations for more complete exploration of a design or plant operating envelope. Comparisons to field data collected from a microgrid on-board a 270 foot US Coast Guard “Famous” Class medium endurance cutter demonstrate the utility of this tool and approach. The usefulness of this tool is further demonstrated by showing simulated EPLA load factors within 10% of observed load factors over comparable mission sets, both inport and underway. Finally, this thesis will discuss the lessons learned during SPS development and testing, specifically, the need to expand its modeling capability so it can support direct current (DC) electrical distribution systems. The SPS, in its current form can only model alternating (AC) electrical distribution systems.
Thesis Supervisor: Steven B. Leeb
Title: Professor of Electrical Engineering and Mechanical Engineering Thesis Supervisor: Bryan R. Moser
Title: Academic Director and Sr. Lecturer System Design and Management
Thesis Supervisor: Daisy Green Title: Doctoral Candidate
Acknowledgments
Thank you to my wife, Deanna, who has been incredibly supportive throughout my time at MIT. Thank you to my parents for their support. Thank you to my hero, Ron Davis, for all his guidance, love, and support. I wouldn’t have gotten this far with the foundation you provided. Thank you to my classmates and their help with getting through the tougher days at MIT. I would also like to thank CDR Gillespie, CAPT Bebermeyer, Professor Leeb, and Professor Moser for their guidance throughout my research. Thanks as well to Daisy, Steve K., and Brian for assisting me with debugging the program and helping me with my first published work. It was a pleasure working with all of you, and wish you all the best of luck in your future endeavors.
Contents
1 Motivation and Background 13
1.1 Early Design Considerations and Determination of Metrics . . . 14
2 Shipboard Power Simulator 19 2.1 System Architecture . . . 19
2.1.1 Load Database . . . 22
2.1.2 Ship Database . . . 23
2.1.3 Mission Profile Database . . . 25
2.2 Simulation Tool Operation . . . 26
2.2.1 Loading the QT Project . . . 26
2.2.2 Compiling the Code . . . 26
2.2.3 Installation . . . 27
2.2.4 Home Page Functions . . . 27
2.2.5 Loads Page Functions . . . 29
2.2.6 Ship Design Page Functions . . . 35
2.2.7 Simulation Inputs Page Functions . . . 40
2.2.8 Report Page Functions . . . 43
3 Modeling Equipment on the WMEC-270 47 3.1 MPDE Pre-Lube Pump . . . 47
3.2 MPDE Lube Oil Heater . . . 50
3.3 MPDE Jacket Water Heater . . . 52
3.4 SSDG Lube Oil Heater . . . 55
3.5 SSDG Jacket Water Heater . . . 58
3.6 Controllable Pitch Propeller (CPP) Hydraulic Pump . . . 60
3.7 Graywater Pumps . . . 63
3.8 Fuel Oil Purifier . . . 65
3.10 Bilge and Emergency Ballast Pump . . . 70
4 Simulation Testing Results and the Application of Simulated Power Data 73 4.1 Charlie Status . . . 75
4.2 Bravo Status . . . 76
4.3 Alpha-RMD Status . . . 78
4.4 Alpha-Normal Status . . . 80
4.5 Applications of Simulated Power Data . . . 82
4.5.1 EPLA Validation . . . 82
4.5.2 Condition-Based Maintenance Aid . . . 84
5 Conclusion and Further Work 85
A 41-Day Simulated Cruise Mission Profile Data 87
B Sample NILM Upload File 95
C Example Mission Profile Database File 99
List of Figures
1-1 Systems Engineering “V” Process used in Development of the Shipboard Power
Simulator (SPS) Architecture . . . 15
1-2 Partial Schematic of Radial AC Electrical Distribution Onboard USCGC SPENCER (WMEC 905) . . . 16
1-3 Ring Bus AC Electrical Distribution Onboard USN Arleigh Burke Class De-stroyers (reproduced from [3]) . . . 16
2-1 Shipboard Power Simulator (SPS) Architecture . . . 20
2-2 Finite State Machine (FSM) Model of a CPP pump . . . 22
2-3 Power Waveforms for the CPP pump . . . 22
2-4 Shafting System . . . 24
2-5 MinGW Compiler . . . 26
2-6 Executable and Extension Files in Directory Folder . . . 27
2-7 Home Page . . . 28
2-8 Loads Page . . . 30
2-9 Load Entry Form . . . 31
2-10 Load Design Wizard Page with a Two-State Machine Input . . . 33
2-11 User-Generated Power Trace Designer . . . 34
2-12 NILM Data Upload Page . . . 35
2-13 Ship Design Page . . . 37
2-14 Component Loads . . . 38
2-15 Load Interaction Entry . . . 40
2-16 Simulation Inputs Page . . . 42
2-17 Simulation Algorithm Process . . . 44
2-18 Report Page . . . 46
3-1 MPDE Pre-Lube Pump (reproduced from [4]) . . . 48
3-2 MPDE Pre-Lube Pump “Off-On” Power Trace . . . 49
3-4 MPDE Pre-Lube Pump “On-Off” Power Trace . . . 49
3-5 MPDE Lube Oil Heater (reproduced from [4]) . . . 50
3-6 MPDE Lube Oil Heater “Off-On” Power Trace . . . 51
3-7 MPDE Lube Oil Heater “On” Power Trace . . . 51
3-8 MPDE Lube Oil Heater “On-Off” Power Trace . . . 52
3-9 MPDE Jacket Water Heater (reproduced from [4]) . . . 52
3-10 MPDE Jacket Water Heater “Off-On” Power Trace . . . 54
3-11 MPDE Jacket Water Heater “On” Power Trace . . . 54
3-12 MPDE Jacket Water Heater “On-Off” Power Trace . . . 54
3-13 SSDG Lube Oil Heater (reproduced from [4]) . . . 55
3-14 SSDG Lube Oil Heater “Off-On” Power Trace . . . 57
3-15 SSDG Lube Oil Heater “On” Power Trace . . . 57
3-16 SSDG Lube Oil Heater “On-Off” Power Trace . . . 57
3-17 SSDG Jacket Water Heater (reproduced from [4]) . . . 58
3-18 SSDG Jacket Water Heater “Off-On” Power Trace . . . 59
3-19 SSDG Jacket Water Heater “On” Power Trace . . . 60
3-20 SSDG Jacket Water Heater “On-Off” Power Trace . . . 60
3-21 CPP Hydraulic Pump (reproduced from [4]) . . . 61
3-22 CPP Pump “Off-On” Power Trace . . . 62
3-23 CPP Pump “On” Power Trace . . . 62
3-24 CPP Pump “On-Off” Power Trace . . . 62
3-25 Graywater Pump (reproduced from [4]) . . . 63
3-26 Graywater Pump “Off-On” Power Trace . . . 64
3-27 Graywater Pump “On” Power Trace . . . 64
3-28 Graywater Pump “On-Off” Power Trace . . . 64
3-29 Fuel Oil Purifier (reproduced from [4]) . . . 65
3-30 Fuel Oil Purifier Operating Sequence [5] . . . 65
3-31 Fuel Oil Purifier “Off-On” Power Trace . . . 66
3-32 Fuel Oil Purifier “On” Power Trace . . . 67
3-33 Fuel Oil Purifier “On-Off” Power Trace . . . 67
3-34 Inport Auxiliary Saltwater Pump (reproduced from [4]) . . . 68
3-35 Inport Auxiliary Saltwater Pump “Off-On” Power Trace . . . 69
3-36 Inport Auxiliary Saltwater Pump “On” Power Trace . . . 69
3-37 Inport Auxiliary Saltwater Pump “On-Off” Power Trace . . . 69
3-38 Bilge and Emergency Ballast Pump (reproduced from [4]) . . . 70
3-40 Bilge and Emergency Ballast Pump “On” Power Trace . . . 71 3-41 Bilge and Emergency Ballast Pump “On-Off” Power Trace . . . 72 4-1 Observed aggregate power streams from SPENCER and simulated power
streams using the Shipboard Power Simulator. . . 74 4-2 Machinery Configuration in Charlie Status [4] . . . 75 4-3 Charlie status. Observed (left) and simulated (right) power streams and
de-tected load events. . . 76 4-4 Machinery Configuration in Bravo Status [4] . . . 77 4-5 Bravo-2 status. Observed (left) and simulated (right) power streams and
detected load events. . . 77 4-6 Machinery Configuration in Alpha-RMD Status [4] . . . 79 4-7 Alpha-RMD status. Observed (left) and simulated (right) power streams and
detected load events. . . 79 4-8 Machinery Configuration in Alpha-Normal Status [4] . . . 80 4-9 Alpha-Normal status. Observed (left) and simulated (right) power streams
and detected load events. . . 81 4-10 Steady State Calculation as a Load Transitions from “Off” to “On” State
List of Tables
2.1 Function-to-Form Mapping . . . 20
2.2 State Change Variable Detailed Entries . . . 39
2.3 State Change Variable Detailed Entries . . . 40
3.1 MPDE Pre-Lube Pump Modeled Behavior . . . 48
3.2 MPDE Lube Oil Heater Modeled Behavior . . . 50
3.3 MPDE Jacket Water Heater Modeled Behavior . . . 53
3.4 SSDG Lube Oil Heater Modeled Behavior . . . 56
3.5 SSDG Jacket Water Heater Modeled Behavior . . . 59
3.6 CPP Pump Modeled Behavior . . . 61
3.7 Graywater Pump Modeled Behavior . . . 63
3.8 Fuel Oil Purifier Modeled Behavior . . . 66
3.9 Inport Auxiliary Saltwater Pump Modeled Behavior . . . 68
3.10 Bilge and Emergency Ballast Pump Modeled Behavior . . . 70
4.1 Charlie Duty Cycle Results . . . 76
4.2 Bravo Duty Cycle Results . . . 78
4.3 Alpha-RMD Duty Cycle Results . . . 80
4.4 Alpha-Normal Duty Cycle Results . . . 81
4.5 EPLA Load Factor Results . . . 84
A.1 Missions . . . 88
A.2 Missions (cont.) . . . 89
A.3 Missions (cont.) . . . 90
A.4 Missions (cont.) . . . 91
A.5 Temperatures . . . 92
Chapter 1
Motivation and Background
Applying the remarkable gift of vast computational capability in an endless drive for in-creased simulation fidelity with the physical world may offer diminishing returns in many design and analysis efforts. Sometimes, a detailed simulation with differential equations and the very best numerical methods and computation hardware are peerless. For a power sys-tem, high fidelity simulations might be irreplaceable for fault studies, analysis of the effects of variations in nonlinearities, or the subtle impacts of changing environmental conditions, like temperature or humidity, on electromechanical performance. However, particularly for analyses focused on “what-if” studies (which may explore many possible scenarios in a pro-posed design space or operating envelope), current trends in power system simulation that demand computationally-intensive, physics-based models may impede the acquisition of use-ful results [3]. Behavioral modeling of electrical loads [6] may provide sufficient fidelity to enable rapid exploration of a range of scenarios to provide sets of data for applications like condition-based maintenance [1], electrical plant load analysis (EPLA [2]), and the schedul-ing and taskschedul-ing of finite generation and distribution resources. A tool that can quickly evaluate many scenarios, as opposed to intense, high-fidelity modeling of a single operating scenario, may best serve these applications.
This thesis introduces the Shipboard Power Simulator (SPS), a software tool configured as a behavioral simulator that can quickly emulate the operation of a relatively large collection of electrical loads on a microgrid, providing “what-if” evaluations to support more complete exploration of a design space or plant operating envelope. Behavioral emulation of loads in the SPS begins by describing a load as a power consumer represented by a finite state machine (FSM). Temporal transitions in the FSM model can follow a fixed logical sequence in time, or transition between states, randomly, or in concert with the states of other systems or parent systems on the microgrid, or in response to environmental conditions like temperature. Proper modeling of the ship (microgrid) operational dependencies becomes more important
than the precise mathematical description, e.g., differential or difference equations, for a load. Load power and load transients are represented as stored waveform segments, representing power demand in each state, and in the transitions between states. The waveform segments can be acquired from field data if examples of the loads or microgrid system already exist, e.g., using a Noninstrusive Load Monitor (NILM) [1]. Alternatively, a waveform segment can be entered as a “best guess” from “name plate rating,” or based on observations of a similar load, or from a detailed simulation conducted once, thus limiting the computational expense to a small set of expensive simulations with outputs that can be re-used. Results are demonstrated with comparisons to field data collected from the power system on-board a 270-foot US Coast Guard “Famous” Class medium endurance cutter. Comparisons to field data in Chapter 4 demonstrate the utility of the SPS modeling approach for condition-based maintenance and for the computation of EPLA load factors. The utility of the SPS will be measured by comparing the EPLA load factors from real-world missions to the simulated data.
1.1
Early Design Considerations and Determination of
Metrics
The structure of the SPS behavioral modeling rules reflects the top-down design of a micro-grid power system. An engineering “V” [7] diagram illustrates the correspondence between power system design and SPS modeling. The left side of Fig. 1-1 visually illustrates the microgrid power system design, beginning at the top with mission requirements and operat-ing environment, then engineeroperat-ing systems, and, finally, engineeroperat-ing electrical loads. Mission capabilities for the microgrid, or ship in this case, drive the deployment of necessary ship systems. For example, requirements for speed and survivability may drive the number of propulsion shafts installed on a ship. Each shaft requires necessary supporting subsystems or electrical loads to provide lubrication, hydraulic pressure, and so on, each of which places demands on the ship electrical system. Each supporting subsystem includes electrical loads like motors, resistive heaters, and electronic controls. These loads operate at a specified voltage (e.g., 120V, 208V, and 440V AC) and present two or more “states” of operation, including at least an “off” state and an “on” state with specified power consumption levels. Connections may be line-to-line, three phase, and so forth.
High-level global parameters, such as the ship’s mission, the operating environment, or other factors further discussed in Chapter 2, create requirements for specific systems on ships, and also cause these systems to energize or secure at any point in time. US Coast
Figure 1-1: Systems Engineering “V” Process used in Development of the Shipboard Power Simulator (SPS) Architecture
Guard (USCG) and US Navy (USN) ships designate specific operational status, or current “mission,” to indicate operating environment and ship system configuration. In the USCG, for example, “Alpha,” “Bravo,” and “Charlie” mission statuses respectively indicate that the ship is underway, or in-port and ready to get underway if the need arises, or in-port and not expected to get underway for an extended period of time. Each mission calls for certain systems to be energized, and systems will be progressively brought from secured status into standby and, eventually, online, or vice-versa, as the ship transitions between missions. Furthermore, environmental factors can also cause systems to be energized or secured, such as the anti-icing systems energized in cold weather.
The engineering systems serve the different requirements of ship missions. For example, the shafting systems translate energy from the main engines into propulsion thrust. Shafting systems, energized when the main engines are online, include a variety of subsystems with pumps and other electrical devices to support propulsion. Other example ship systems in-clude seawater cooling, electrical generation, HVAC, weapons systems, and communications. Finally each ship system consists of various electrical loads. Because the electrical loads are part of ship systems, their behavioral model can be determined by the operation of the system. Here, it is assumed that the ship microgrid is wired up as an ac radial electrical distribution. This is a common electrical distribution architecture used by the USCG and USN. For example, Fig. 1-2 shows a depiction of the electrical distribution of USCGC SPENCER. In this system, a generator supplies 440 VAC, 60 Hz, ungrounded power directly to the ship’s service switchboard. A variety of sources can energize the main switchboard, including on-board generators or a tie to shore power. Feeders from the main switchboard branch out to load centers and power panels that energize various electrical loads. Fig. 1-2 shows the port and starboard power panels crucial for ship propulsion systems, power
Figure 1-2: Partial Schematic of Radial AC Electrical Distribution Onboard USCGC SPENCER (WMEC 905)
generation systems, and several auxiliary systems.
Figure 1-3: Ring Bus AC Electrical Distribution Onboard USN Arleigh Burke Class De-stroyers (reproduced from [3])
The USN often uses an AC ring bus zonal electrical distribution system (ZEDS). The ZEDS on the Navy’s Arleigh Burke Class Destroyer is shown in Fig. 1-3. This systems is comprised of two conjoining rings that can be configured in multiple ways. One of the ways it can be configured is by connecting the two smaller rings to form a larger outer ring. Another option is to segment the smaller rings into either fore and aft rings, or port and starboard rings. These rings provide power to load centers. The ZEDS utilize a radial distribution methodology from the load centers to subsequent power panels [8]. The USN generates 450 VAC, 60 Hz, power [9]. The secondary voltage system supplies 120 VAC, three-phase, 60 Hz power and is directly supplied from the 450 VAC system through transformer banks.
Early in the SPS development, a metric was determined in order to measure success. EPLA load factor was determined to be the best metric from which we could use to draw a comparison to observed data. The EPLA load factor results will be further discussed in Chapter 4. Due to the nature of these loads and the variation in their use, the observed EPLA values vary within roughly ± 0.1 of each other in the underway condition based upon the missions and environmental conditions in which the ship finds itself. For this reason, a successful simulated EPLA load factor was determined to be any value within ± 0.1 of the observed value. This comparison will be made between simulated data and observed data for two monitored panels onboard the USCGC SPENCER. These panels were chosen as they have the best monitored data available. Chapter 4 will also show a 40-day simulation, but these results will not be compared to real data. Due to the nature of USCG missions and the ability for the ship’s Captain to establish non-standard engineering configurations should the need arise, it is not possible to accurately recreate a long mission set from which to simualte and compare to real data.
Chapter 2
Shipboard Power Simulator
The Shipboard Power Simulator (SPS) was developed to create power demand data using electrical load behavior modeling. This section will discuss the architecture and operation of the SPS.
2.1
System Architecture
The system architecture was the first design decision. The architecture was developed using the guiding heuristics from [10]. The first heuristic, namely “carefully set the boundaries of the architectural space under consideration [10]” set the scope for the SPS. The scope required a simulation for maritime microgrids. Maritime microgrids are different from typ-ical shore microgrids as there are interconnected systems that run in tandem based upon mission requirements. For this reason, it was clear a robust, multilayered architecture would be required. The second heuristic, “the decision model should include only architectural decisions [10]” drove the function-to form mapping. Through function-to-form mapping, it was clear, three databases were needed. An example of the function-to-form mapping used during early SPS development can be seen in Table 2.1.
By having three distinct databases, the user was given more freedom to develop a large set of electrical loads that could be tailored for any specific ship. For example, a user may not know exactly which phases a pump will draw power from a ship, but will know the load requires line-to-line power. The independent load database allows the user to configure a load and all the behaviors of that load, without needing a specific ship. In this case a “master” Load Database can be created for both the US Navy and Coast Guard. From these master databases, specific ships can tailor these pre-developed loads for the unique shipboard configuration. The Ship Database is specific to an individual platform and uses
Table 2.1: Function-to-Form Mapping
Function Form
-Model multi-state loads Load Database
-Store power trace data
-Allow user to generate power trace data for loads with no existing data
-Model electrical distribution system Ship Database
-Configure electrical loads for ship specific operation -Define ship mission speeds and engineering plant configuration
-Input/save/edit mission profiles Mission Profile Database
system. Finally, the third database, the Mission Profile Database contains input data ranging from ship speed to specific missions and can be applied to any ship. This independent database allow for quick simulations across numerous mission, ship speeds, and operating environments in order to see the ship’s electrical response.
Figure 2-1: Shipboard Power Simulator (SPS) Architecture
Fig. 2-1 illustrates an example of a US Navy Load Database. Specific loads can be taken from this Load Database and “installed” in the Ship Database. Fig. 2-1 shows how the Load Database was used to develop a Ship Database for a Cruiser, Destroyer, and an Aircraft
Carrier. Finally, each of these ships can be simulated across different missions, housed within the Mission Profile Database. In this case, you can see there are three different missions including a North Atlantic cruise, Southern Pacific cruise, and a long inport period. The final heuristic from [10] states, “decisions should significantly influence the metrics by which the architecture is evaluated.” The most important metric for proving success of the SPS is its accuracy in determining EPLA load factor and correctly modeling duty cycles during missions. These results will be further discussed in Chapter 4. The need for accurate EPLA load factor metrics led to one load behavior modeling method. Some of the ways to model electrical load behavior discussed in [3] include finite state modeling, single state modeling, and level type modeling. Finite state modeling is best for modeling complex, multi-state loads. An example of this would be a pump that can be off, in a low operating state, and a high operating states. This is a very common load in marine microgrids. Level type modeling is best used for loads that react differently based upon pressure or temperature settings. An example of this type of load, would be a lube oil pump that activates when lube oil header pressure drops below a given set point. Finally, single state modeling is used for simple systems that are always energized such as ventilation fans. The SPS uses finite state modeling to model all load types. This allows the user to create simple and complex loads using only one modeling method. The finite state model can handle both level type and singe state models. For example, the lube oil pump mentioned above could be modeled as a three-state, finite state machine in which transient operations would be triggered, and thus cause a change in state whenever a certain pressure or temperature set point was met. Another benefit to finite state modeling is that the user can pair global triggering events, referred to as state change variables throughout this thesis, to transient power traces that define the transition between states. Ultimately, the finite state modeling method was chosen because it is the most accurate representation of transient and steady state behavior. This modeling method will lead to the most accurate EPLA load factors.
The SPS applies a “bottom-up” approach for defining the hierarchical structure of a behavioral microgrid simulation, as shown on the right side of Fig. 1-1, beginning with in-dividual loads. Finite state machine (FSM) power demand models for each load are stored in the SPS Load Database. Next, information about the radial panel wiring in the ship, system response to global inputs, and the load-to-system relationship is stored in the Ship Database. Finally, the operating profile and missions the ship carries out during the simu-lated time is stored in the Mission Profile Database. With these three databases loaded, the SPS assembles operating power waveforms for any collection of missions of interest.
2.1.1
Load Database
A finite state machine model for each load encapsulates power demand. Each state in the model represents a unique steady-state power level. Each transition between states is associated with a transient change in power demand. For example, Fig. 2-2 shows a finite state model of a Controllable Pitch Propeller (CPP) pump that will play a role later in the “shaft system”.
Figure 2-2: Finite State Machine (FSM) Model of a CPP pump
The real and reactive power waveforms for all three phases for this load, as observed on USCGC SPENCER, are shown in Figure 2-3. The power traces are segmented into three sections, the “Off-On” transient, ‘On” steady-state, and the “On-Off” transient. When first activated, an in-rush current causes a large peak in power demand, creating the “Off-On” transient. Once the CPP pump finishes its transition to the “On” state, the “On”, or steady-state behavior, is repeated or concatenated in the behavioral simulator until the load switches to the “Off” state. In steady state, the pump is observed to consume approximately 2500 W and 1700 VAR per phase for real and reactive power, respectively.
Figure 2-3: Power Waveforms for the CPP pump
is comprised of five critical tables: Loads Table, Power Traces Table, Uploaded Data Table, Operations Table, and the Possible Inputs Table. The “Loads Table” stores basic character-istics for each load, including the load name, the voltage required for operation, how the load is connected electrically (e.g, 3-phase), as well as the FSM model of the load and its parent system, if applicable. The “Power Trace Table” stores the power waveforms for steady-state and transient behavior at a 10 Hz sample rate. The power waveforms can be from field data, e.g. collected with a NILM, or they can be entered as a graphical approximation of an expected power curve, or the data can be provided from other sources including a detailed, one-time simulation of the load. The “Uploaded Data Table” serves as an index that identi-fies data in the the Power Trace Table, e.g., as real or reactive power or harmonic content, and with electrical phase for each waveform. The “Operations Table” is another indexing table that is used to connect the previously designed FSM operation with its specific power trace. The “Possible Inputs Table” holds the data that is shown in the combo boxes in the user interface. This table can be added to if there are inputs that the user requires that are not seen. For example, a user may wish to add a voltage rating. This information would be stored in the “Possible Inputs Table.”
2.1.2
Ship Database
Moving up a conceptual level in the simulator organization, a “system” defines a collection of loads that work together to provide a service to the ship. For example as shown in Fig. 2-4, the starboard shafting system consists of Number (NR) 1 CPP Pump, 1A Lubrication Oil Service Pump (LOSP), and 1B LOSP. All three of these loads would energize in response to any mission that demanded propulsion from the starboard shaft, and therefore required the use of the starboard shafting system.
One or more state change variables define the operational behavior of any particular system like the shafting system. For a ship, state change variables are parameters that ei-ther require or do not require watchstander intervention. That is, sometimes operation is “automatically” triggered depending on other conditions on or around the ship, and other times the operation occurs “manually,” e.g., based on an operator’s demand. Examples of state change variables that might automatically trigger a system to operate include simu-lated or operational variables like crew size, time of day, day of week, ambient temperature, seawater temperature, mission, and ship speed. Changes to these parameters can prompt responses from the systems and associated loads based upon pre-defined rules of operation. Other systems may not operate on a crisp schedule or in tight coordination with ship mis-sion. These “manually” activated systems might, for example, include pumps for black water
Figure 2-4: Shafting System
waste disposal on the ship. These pumps run essentially in the thrall of crew needs, and are essentially random or randomly distributed around other events, e.g., crew mess. In the SPS tool, a stochastic state variable commands the operation of these “manual” loads.
In overview, the Ship Database in the SPS stores the structure of the electrical panel system and load connections on the ship, and also stores the relationship between each load on the power grid and its associated “system”. The individual load behavior, e.g., the FSM describing the load’s power demands, have already been defined and stored in the Load Database. When a user of SPS “connects” a load to the ship power system modeled in a particular ship simulation, the Ship Database stores the electrical interconnection or panel location of the load on the ship, and also stores the specific ship system associated with the load. For example, the NR 1 CPP pump might have been defined previously in the Load Database as being part of a “Shafting System”. The Ship Database stores the data that pairs the NR1 CPP pump with the specific shafting system on the ship, in this case, “starboard shaft”. The Ship Database also stores the associations or state change variables that will trigger the operation of each system. Note that the Load Database defines load behavior specific to each load, and the Ship Database stores load connections and system memberships associated with a particular ship. This distinction permits a single Load Database, e.g., for a broad class of USCG or USN surface ships, to serve as basic data for assembling simulations
of many different ships each with a distinct Ship Database while reusing the same basic loads where appropriate.
More specifically, the Ship Database is comprised of five tables: Ship Electrical Network Table, Component Details Table, Panel Details Table, Load Interactions Table, and Mission Assumptions Table. The “Ship Electrical Network Table” stores the structure of the ship’s electrical distribution system. This table records the breakers, panels, transformers, and interconnections that make up the electrical network. The “Component Details Table” stores specifics on components like panels in the network, including defining characteristics like voltages, connected phases, feeder conduit size, transformer type, transformer grounding, and transformer sequencing for each component. The “Panel Details Table” stores the specific details for a particular instance of a load on the network and a record or tag to its defining example or class in the Loads Database. For example, a load defined in the Panel Details Table as “NR 1 CPP Pump” may be a specific instance of a load class “CPP Pump” found in the Loads Database. The specific instance “NR 1 CPP Pump” is now an example of the class but with a particular connection to specific power system phases and a location on the grid. The “Load Interactions Table” records the system membership for each particular load, e.g., NR1 CPP Pump to the Starboard Shaft. This table stores the specific state variables and associated changes that influence the operations of each load. For example, if a load changes state with the ship’s missions, the Load Interaction Table would have a record of what transient operations a load would experience when a particular mission starts and ends. Finally, the “Mission Assumption Table” records ship operating rules, for example, the speed, generator configuration, and engine configuration for different missions like refueling, cruise, station-keeping, and so forth.
2.1.3
Mission Profile Database
Every ship maintains logs that record the ship’s speed, ambient temperature, seawater tem-perature, crew size, date, present mission, engineering plant line-up, and time. These state change variables affect the behavior of the electrical loads. The final, highest level of data abstraction in the SPS, the Mission Profile Database, records a log of these state change vari-ables that reflect the record of a real or imagined deployment of the ship and its microgrid. Data stored in this database reflects the environment and events the ship will experience during a simulation. Changing entries in the log stored in the Mission Profile Database will create endlessly varied simulations that assemble and emulate the behavior of collections of loads on the ship.
2.2
Simulation Tool Operation
The user interface of the SPS eases the data input effort to quickly produce valuable results for “what-if” scenario analysis. This section demonstrates configuring the SPS to simulate part of the USCGC SPENCER, with the radial electrical distribution system and loads shown in Fig. 1-2. Configuring the SPS proceeds with the same “bottom-up” approach used to describe the SPS database structure.
2.2.1
Loading the QT Project
Ensure all header, source, and .ui code files are in the same directory as the project file. Open the project file through the QT IDE. Once your changes are made in the IDE, build the project and compile it in order to create an independent executable program.
2.2.2
Compiling the Code
The SPS was written in C++ in the QT Integrated Development Environment (IDE). To compile the code into an executable file, Open the MinGW compiler. Locate the .exe build under the directory folder labeled “Release.” Ensure only the .exe file is in his folder. Delete any other files if needed. Copy the directory path and Paste it into the MinGW compiler as seen in Fig. 2-5. Call the deploying executable by typing “windeployqt.exe –quick .” and hit Enter. This will populate the directory folder with all supporting files required to run the compiled executable file independent of the IDE.
2.2.3
Installation
The executable file may be placed in any directory. The supporting application extensions seen in Fig. 2-6 must be copied and placed in the same folder as the executable program file. It is also recommended, but not required, the user store all power trace files in this location.
Figure 2-6: Executable and Extension Files in Directory Folder
2.2.4
Home Page Functions
The executable file opens to a landing page, pictured in Fig. 2-7, that allows the user to start a simulation from scratch or load previously configured databases. The functions below go into further detail on how to manipulate the user interface of the Home Page.
Load an Existing Load Database To load an existing Load Database, Select the but-ton labeled Load an Existing Load Database. You may also accomplish this task by selecting File > Open... > Load Database.
Create a Load Database To create a Load Database, Select the button labeled Create a Load Database. You may also accomplish this task by selecting File > New... > Load Database.
Load an Existing Ship Database To load an existing Ship Database, Select the button labeled Load an Existing Ship Database. You may also accomplish this task by selecting File > Open... > Ship Database.
Create a Ship Database To create a Ship Database, Select the button labeled Create a Ship Database. You may also accomplish this task by selecting File > New... > Ship Database. You will then be prompted to enter the number of generators, shafts, and main engines for the ship you are configuring. The program will also ask you to state whether the shipboard electrical distribution system is a ring bus or radial bus.
Load Simulation Inputs To load a Mission Profile file into the program, Select the button labeled Load Simulation Inputs. You will be directed to the root directory and asked to select the file to open.
Enter New Simulation Inputs To enter new simulation inputs into the program, Select the button labeled Enter New Simulation Inputs. You will be directed to the Simulation Inputs Page.
2.2.5
Loads Page Functions
The Loads Page, pictured in Fig. 2-8, allows the user to add, edit, delete, or preview all loads within the Load Database. The Load Design Wizard Page is used to design or modify the transient and steady state behavior of a load. Fig. 2-10 shows a screenshot of the Load Design Wizard during the configuration of a CPP pump on SPENCER. Because the CPP pump is a two-state load, the user assigns two transient operations, “Off-On” and “On-Off”, to summarize the transitions for the load. In this demonstration, the SPS transient and steady-state waveforms for the CPP are entered using NILM data from field observations.
Entering a Load Enter the class name and number of states in the form picture in Fig. 2-9. The user must also select the state change variables (mission, time of day, day of week, ship speed, ambient temperature, seawater temperature, randomly, or crew size). If the state change variable is “ship speed”, the parent system must be then be supplied. If the state change variable is not “ship speed”, the user is not required, but may enter a parent system or select “None”. Next, the user must select the voltage rating, and how the load is connected to the ship (three phase, line-to-neutral, or line-to-line. Fig. 2-9 shows an example of how a CPP pump would be entered into the load entry form. Select Save when all entries have been made. The newly added load class name will appear in the window at the far left of the Loads Page.
Figure 2-9: Load Entry Form
Add Parent System To add a parent system not found in the Parent System combo box, write the name of the parent system in the text box and select Add Parent System. These new entries are saved in the Load Database and can be used for future load configuration. Add Voltage To add a voltage rating not found in the voltage rating combo box, write the voltage value in the text box and select Add Voltage. These new entries are saved in
Viewing a Load Entry Select a load from the window to the far left of the Loads Page. This will populate the previously added data to the load entry form.
Editing a Load Select the load you wish to edit from the window to the far left of the Loads Page. Make your edits to the load entry form and select Save.
Deleting a Load Select the load you wish to delete from the window to the far left of the Loads Page. Select Delete. The load will be deleted from the database and removed from the window.
Preview Configured Load Once a load is configured, it can be previewed on the Loads Page. The configured operations will appear in the Configured Operations window. Select the desired operation you wish to preview and toggle through the Power Type and Phase combo boxes to find the desired configured operation you wish to preview.
Configuring a Load Pressing the Open Operations Design Wizard button on the Loads Page opens the Load Design Wizard (Fig. 2-10). The Design Wizard aids the user in the completion of the following tasks.
Add Operation Select the state from which the operation starts from the combo box labeled From under Applicable Operations. Select the state from which the operation ends from the combo box labeled To under Applicable Operations. Press Add Operation. This will add an arrow pointing from the starting state to the end state. Until the user adds a power trace to this operation, a block labeled “Not Assigned” will appear on the arrow. Remove Operation Select Remove Operation. This will delete the arrow pointing from the state in the From combo box to the state in the To combo box. This will also delete all entries for this operation from the Operations Table in the Loads Database. Design User-Generated Power Traces Baseline user-generated power traces are in-cluded in the Loads Database during database creation. Cartoon A through Cartoon H provide the user with different shapes to model power traces for “Off-On,” “On-Off”, steady state, and transitions to and from steady states. The user may alter the baseline models by manipulating the peak, steady state, and starting power levels. This is accomplished by clicking on the desired Cartoon Power Trace and entering the desired levels for the Peak Power, Steady Power, and Baseline Power spin boxes respectively. The user may also manipulate the length of time for the power trace by entering the desired length of time into
the Time Length spin box. The Power Trace Preview provides a sketch of the power trace as the user manipulates the above mentioned variables.
Figure 2-11: User-Generated Power Trace Designer
Upload Power Trace Data The Load Database can hold several thousand uploaded traces. Thes traces are stored at a 10Hz sampling rate. The Load Database can hold up to ten minutes of NILM data at this sampling rate. To upload a new power trace from a file, select Upload Power Trace as pictured in Fig. 2-11. Fig. 2-14 will appear. Select Open NILM Date from File and select the desired file. Note: this file must be a .txt file formatted like the example file in Appendix B. The NILM Upload Page, pictured in Figure 2-14, reads in .txt files and breaks them into individual power traces based upon the power type and phase. The user may choose to crop the uploaded trace prior to saving to the database, if desired. To save, click on each row, and hit the Save button.
Preview Power Traces To preview an uploaded power trace, Select the trace you wish to preview from the Uploaded Power Trace Data window and toggle through the Power
Figure 2-12: NILM Data Upload Page
Type and Phase combo boxes to find the desired trace you wish to preview. To preview a user generated trace, Select desired baseline cartoon shape from the Cartoon Power Traces window. This will generate the baseline shape. From here, you may enter any number into either the Time Length, Peak Power, Steady Power, or Baseline Power entry boxes to preview the change to the baseline shape.
Applying a Power Trace to an Operation Once you obtain your desired trace, press Apply NILM Trace to apply a NILM shape or, for a user-generated trace, Select the Power Type and Phase to which the trace should be applied and select Apply Cartoon Trace As:.
2.2.6
Ship Design Page Functions
Next, the Ship Design Page, shown in Fig. 2-13, configures the Ship Database. A user is given a “tree widget” to enter the structure of the radial electrical network from the generator breakers to the power panels. Fig. 2-13 illustrates how the user has designed the electrical network for the USCGC SPENCER, with two monitored panels connected to the Main Switchboard. Specific loads, shown in Fig. 1-2, are entered as connections to
using the Load Class Interaction Designer pictured in the lower left corner of Fig. 2-13. For example, a particular mission type known as “Restricted Maneuvering Doctrine” or RMD places a premium on the ships ability to move nimbly and without restriction. In this case, both NR1 and NR2 CPP pumps are energized to provide the greatest likelihood of retaining propeller pitch control, and these pumps change state when entering or leaving the Alpha RMD mission. When Alpha RMD is entered, both CPP pumps energize, and when Alpha RMD ends, both CPP pumps secure. The user also defines the engineering configurations and speeds at which this ship conducts various missions, using the Mission Assumptions table.
Add Breaker/Panel To add a breaker or panel, Select the breaker under which you wish to place the new one. Right Click and select Add Breaker/Panel. The new panel will be named ”New Breaker/Panel” and can be changed to whatever you wish.
Delete Breaker/Panel To delete a breaker or panel, Right Click on the component you wish to delete and select Delete.
Configure Breaker/Panel To configure a breaker, panel, or transformer, Select the component from the Ship Electrical Network Window. If this component has already been configured, it’s attributes will populate in the Electrical Component Details form. To configure a component for the first time, scroll through the Type combo box to find the definition that matches the component. The choices are breaker, panel, or transformer. If ”transformer” is selected, you must then include definitions for the transformer type, whether it is grounded or un-grounded, and whether it has positive or negative sequencing by using the combo boxes labeled Transformer Type, Wye Spec, and Transformer Sequence respectively. After selecting the component type, you must choose the Line Voltage, Input Connection (three phase, split phase, line-to-line, line-to-neutral), Phases, and Conduit by scrolling through the respective combo boxes. Once all inputs are made in the combo boxes, select Apply.
Add Voltage If the desired line voltage does not exist in the database, the user may enter the value (V) into the text box and select Add Voltage Value.
Add Conduit If the desired conduit size does not exist in the database, the user may enter the size (mm) into the text box and select Add Conduit Size.
Add/Configure/Preview Loads on Panel Select the component to which you wish to add loads/preview. The name of the component will appear next to the ”Selected Compo-nent” label. If loads have been previously added, you will see the load details, to include the load name, length of cable from the panel to the load, cable size, how the load is connected, and to which phases the load draws power. The user may change these inputs by scrolling through the respective combo boxes. Always hit CTRL+S after this change in order to send the data to the Ship Database. To add a new load, Right Click on the desired load under the ”Available Loads” label and select Add Load. A ”quick find” search function is available to assist with finding the desired load.
Figure 2-14: Component Loads
Entering/Editing Load Class Interactions Select the load you wish to configure by double clicking on the Load Class Name in the Component Window. The primary and secondary state change variables will appear. If your load only has a primary state change variable, Right Click in the Load Interaction window and select Add Primary Event. This will populate several entries the user must fill in based upon the primary state. See Table 2.3 for a detailed list of specific entries and/or questions required to be answered in order to define a behavior for each state change variable type. Note: the operation must always be a transient operation and never a steady state operation. Check the box for the specific load the behavior should be applied. Always hit CTRL+S after filling in your data in order to send the data to the Ship Database. Complete an entire cycle for a behavior before attempting to define a new behavior. For example, design the “turn-on” and “turn-off” behaviors for Mission A before moving onto the behaviors in Mission B.
If your load has a primary and secondary state change variable, begin with the primary event first. Right Click in the Load Interaction window and select Add Primary Event.
Table 2.2: State Change Variable Detailed Entries State Change Variable Required Entries
Mission Mission Name (any mission added in Ship Database)
End or Beginning of Mission?
Operation (any operation configured in Load Database)
Time of Day Any Time
Operation
Day of Week Any Day
Operation
Ambient Temperature Low Range Temp (Integer) High Range Temp (Integer) Operation
Seawater Temperature Low Range Temp High Range Temp Operation
Crew Size Low Range Crew Size (Integer)
High Range Crew Size (Integer) Operation
Ship Speed Low Range Speed (Integer)
High Range Speed (Integer) Operation
Randomly Frequency (Very between 1 and 5 minutes, Often-between 30 minutes and 3 hours, Sometimes-Often-between 3 hours and 6 hours, Rarely-between 6 hours and 1 day) Operation
In addition to the required entries outlined in Table 2.3, Select “No” for the secondary dependence for the first primary event of this behavior cycle. Check the box for the specific load the behavior should be applied. Next, Right Click in the Load Interaction window and select Add Primary Event. Fill in this line the same as above, but select a steady state operation, namely the steady state you end in from the primary event you just configured and Select “Yes” for the secondary dependence. Next, Right Click on the row you just created and select Add Secondary Event. A row will appear underneath that must be filled out. Repeat this step once more in order to return to the primary steady state. Finally, Right Click in the Load Interaction window and select Add Primary Event. In addition to the required entries outlined in Table 2.3, Select “No” for the secondary dependence for the last primary event of this behavior cycle. Always hit CTRL+S after filling in your data in order to send the data to the Ship Database. Complete an entire cycle for a behavior before attempting to define a new behavior. An example of a properly configured primary and secondary event sequence can be seen in Fig. 2-15.
Figure 2-15: Load Interaction Entry
Deleting Load Class Interactions Right Click on the row that contains the event you wish to delete and select Delete Event. If you delete an event that has secondary events attached to it, the secondary events will be deleted as well.
Entering/Editing Mission Assumptions Right Click anywhere in the Mission As-sumption window and select Add Mission. The user must scroll through the Plant Con-figuration combo box to define the conCon-figuration for the mission and enter the speed at which the mission is carried out in the Speed line entry.
Table 2.3: State Change Variable Detailed Entries Plant Configuration Energized systems
Full Power Engines-All, Generators-All
Split Plant Engines-One per shaft, Generators-All Trail Shaft Plant Engines-One, Generators-One
Standby Engines-None, but warm system, Generators-None, but
warm system
Secured Engines-None, Generators-None
Deleting Mission Assumptions Right Click on the row that contains the assumptions you wish to delete and select Delete Mission.
2.2.7
Simulation Inputs Page Functions
To load the Mission Profile Database, the user enters mission logs on the Simulation Inputs Page. The user may choose to manually enter the input variables such as mission and ambient temperature, or may upload a Mission Profile CSV data file produced elsewhere,
e.g., in a spreadsheet tool. Fig. 2-16 shows the Simulation Input Page after the user has uploaded the Mission Profile data file for a 41-day cruise of SPENCER.
Adding a Mission Right Click anywhere in the Operational Tasking window and select Add Tasking. The user must scroll through the Mission combo box to enter the mission. Only missions configured in the Mission Assumptions window will appear as choices. The user must also enter the mission start and stop times in the scroll boxes and enter the speed at which the mission is carried out in the Speed line entry.
Deleting a Mission Right Click on the entry you wish to delete from the Operational Tasking window and select Delete Tasking.
Adding a Temperature Input Right Click anywhere in the Operational Environment window and select Add Entry. The user may fill in the ambient and seawater temperatures for any date and time during the simulated cruise.
Deleting a Temperature Input Right Click on the entry you wish to delete from the Operational Environment window and select Delete Entry.
Adding a Crew Size Input Right Click anywhere in the Crew Size window and select Add Crew. The user may fill in the crew size for any date during the simulated cruise. Deleting a Crew Size Input Right Click on the entry you wish to delete from the Crew Size window and select Delete Crew.
Adding Equipment to Start Sequence Right Click on the load you wish to add from the Installed Equipment window and select Add to Start Sequence. The user must scroll through the Operation combo box to enter the starting operation. Only operations configured in the Load Design Wizard will appear as choices. The user must also enter the start time for the chosen operation. If you wish to simulate this start sequence, check the Simulate Start Sequence Only check box.
Deleting Equipment from Start Sequence Right Click on the entry you wish to delete from the Equipment Start Assumptions window and select Remove from Start Sequence.
Load Mission Profile Database File Click on Load Simulation. This will bring up a file dialogue from which you can Select the file name to load into the SPS. The SPS will only load missions from the database that match with the missions from the Mission Assumptions Window.
Save Simulation Inputs to Mission Profile File Click on Save Simulation. This will bring up a file dialogue with which you can Save the simulation inputs seen on the Simulation page to a file.
2.2.8
Report Page Functions
Finally, the Reports Page, pictured in Fig. 2-18, allows the user to choose the load, or loads to be simulated. Any panel or breaker downstream of the selected breaker, or panel, is included in the simulation. For example, if a user selects a generator breaker on a vessel with a ring bus distribution system, the bus tie breakers and subsequent load centers and panels will be included in the simulation. The user may choose which phases and types of power to include in the simulation as well, and may further elect to export the results to a file. Prior to running a simulation the database must be validated. This checks the database for missing data, or possible errors that may produce incomplete or inaccurate simulation data.
Fig. 2-17 illustrates the SPS algorithm to collect data from the Mission Profile Database, identify the operation of relevant ship systems from the Ship Database, and assemble the power waveforms for relevant operating loads from the Load Database to produce simulation waveforms for the emulated cruise. Simulation begins by searching through missions within the Mission Profile Database to create a set of online, standby, and secured main engines and shafts for each mission. These configurations remain constant across all the loads throughout the simulation process. The algorithm also logs the speed for each mission recorded in the Ship Database. Once all the missions have been processed, the SPS algorithm searches through the other inputs in the Mission Profile Data such as seawater temperature or crew size and logs the start and stop time for any changes. These changes define instants when a load may change state. Next, the user selects a collection of loads of interest. The Ship Database is queried to identify grid phases associated with each load. For each phase that supplies power to the load, the SPS queries the Ship Database for the load’s state change variables and searches for changes in these variables in the the Mission Profile Database. For all state changes from the Mission Profile Database, the program uses the start and stop times associated with the change to develop a list of possible state changes for the
Figure 2-17: Simulation Algorithm Process
the Ship Database for the load. If a mission input does cause a power change for the load, the SPS retrieves the name of the operation, such as “Off-On”, from the Ship Database and determines the transient time. The SPS takes the time and operation name, looks up the power waveform in the Load Database, and adds it to the total time series for the phases connected to the load. This process repeats until all requested phases, loads, and power types have been analyzed across the entire mission profile.
Select Loads to Simulate Select the component you wish to simulate from the Select Component to Analyze window. This will populate a list of all loads down stream of the selected component. The user may Select All loads or Select only a portion of the downstream loads. The SPS will only simulate the highlighted loads.
Select Phases and Power Type to Simulate Check the box for the phases and power type you wish to analyze.
Validate Simulation Inputs Prior to running a simulation, you must validate that all data is entered correctly. Click the Validate Inputs button to check for entry errors. This function ensures all mission assumptions, load interactions, simulation constraints, and power traces are entered correctly. The user will receive a warning message if errors are found and will not be able to run a simulation until the errors are cleared.
Run Simulation Click on Run Simulation. Depending on how many loads you are simulating and how long the simulation is, this may take some time, but you can view which load is being simulated in the section labeled ”Current Load Being Analyzed.”
Export Simulation Results After a simulation is complete, the user may choose to up-load the data. If the user desires to concatenate the data to a previously run simulation, select Open next to the section labeled ”Concatenate Data to File.” This will bring up a file dialogue from which the user can select the file for concatenation. The file name will appear in the concatenation text box. If the user does not want to concatenate the data to a file, this step can be skipped and the user can export by selecting Export Results.
Chapter 3
Modeling Equipment on the WMEC-270
Over the past 20 years, the MIT Research Laboratory of Electronics has collected and ana-lyzed data on various military and commercial vessels. Nonintrusive Load Monitor (NILM) systems are installed upstream of two 440V sub-panels in the main engine room of USCGC SPENCER [4, 11]. This NILM data provides insight into the load traces and behavior. This section will expand upon the great work done by my colleague, LT Thomas Kane, in Chapter 2 of his Master’s thesis [4]. This CHAPTER will REPRODUCE the pictures and tables directly from LT Thomas Kane’s thesis AND ALSO COPY TEXT DESCRIPTIONS OF THESE LOADS VERBATIM FROM [4] to illustrate the observed behavior and power traces onboard the USCGC SPENCER and will then explain how the power trace data was used in the SPS to model behavior through the use of finite state modeling. New descriptions in this chapter along with the new graphs of power cconsumption behavior are added here to help explain how the loads are modeled in the Ship Power Simulator. This chapter was co-written with my colleague, LT Steve Kidwell, for joint thesis presentation.3.1
MPDE Pre-Lube Pump
The main propulsion diesel engine (MPDE) pre-lube pump is a motor-driven centrifugal pump that operates upon shutdown of the main diesel engines. The pump energizes once engine speed decreases below 150 RPM and secures when engine speed reaches 150 RPM [4]. Figs. 3-2, 3-3, and 3-4 show the transient and steady state power traces used to model this load as a finite state machine. One state change variable was used in order to create a logic gate to trigger a change in load state. The state change variable for the pre-lube pump is the ship mission. The ship mission decides which MPDE is online, in standby, or secured. The port and starboard pre-lube pumps are both configured in such a way that if the mission
Figure 3-1: MPDE Pre-Lube Pump (reproduced from [4]) Table 3.1: MPDE Pre-Lube Pump Modeled Behavior
Behavior Primary State Operation Secondary State Operation
Change Variable Change Variable
1 Mission-Bravo (starts) Off-On None NA 2 Mission-Bravo (ends) On-Off None NA 3 Mission-Alpha Normal (starts) Off-On None NA 4 Mission-Alpha Normal (ends) On-Off None NA
SPS applies the power trace in Fig. 3-2 when the load’s paired MPDE is placed in standby or secured. The SPS will repeat the power trace in Fig. 3-3 until the load’s paired MPDE is taken out of standby or reenergized. Once the MPDE is taken out of standby or energized, the SPS applies the power trace from Fig. 3-4.
Figure 3-2: MPDE Pre-Lube Pump “Off-On” Power Trace
Figure 3-3: MPDE Pre-Lube Pump “On” Power Trace
3.2
MPDE Lube Oil Heater
The MPDE lube oil heater works in tandem with the pre-lube pump to maintain desired lube oil viscosity and temperature [4]. The heater secures upon engine start, then turns to automatic mode upon the engine securing. In automatic mode, the heater is thermostatically controlled to energize at the low temperature set-point and secure at a high set-point [12].
Figure 3-5: MPDE Lube Oil Heater (reproduced from [4])
Table 3.2: MPDE Lube Oil Heater Modeled Behavior
Behavior Primary State Operation Secondary State Operation
Change Variable Change Variable
1 Mission-Bravo (starts) Off-On None NA 2 Mission-Bravo (ends) On-Off None NA 3 Mission-Alpha Normal (starts) Off-On None NA 3a Mission-Alpha Normal (ongoing) On Randomly On-Off (Some-times) 3b Mission-Alpha Normal (ongoing)
Off Randomly Off-On
(Often)
4 Mission-Alpha
Normal (ends)
On-Off None NA
Figs. 3-6, 3-7, and 3-8 show the transient and steady state power traces used to model this load as a finite state machine. Two state change variables were used in order to only trigger a change in load state if both logic gates were passed. The primary state change variable is the same as the pre-lube pump and will only activate if their associated MPDE is
put in standby or secured. The secondary state change variable, namely “random” is meant to model the automatic mode the heater enters once the engine secures and will energize and secure the heater at random times will its associated MPDE is in standby or secured. The SPS applies the power trace in Fig. 3-6 when the load’s paired MPDE is placed in standby or secured. The SPS will repeat the power trace in Fig. 3-7 until a predetermined amount of time elapses, at which point power trace in Fig. 3-8 is applied. This pattern is repeated until the load’s associated MPDE is energized, at which point the Fig. 3-8 power trace is applied if the load is not already secured.
Figure 3-6: MPDE Lube Oil Heater “Off-On” Power Trace
Figure 3-8: MPDE Lube Oil Heater “On-Off” Power Trace
3.3
MPDE Jacket Water Heater
The MPDE jacket water heater consists of two 4.5 kW, 3-phase immersion heating elements sitting between the cylinders on either side of the engine block. These elements are served from the same breaker and controller, and appear to the NILM as a single 9 kW resistive load. The heaters are thermostatically controlled to energize at a low set point and secure at a high set-point. The jacket water heater operates in tandem with the lube oil heater when the engine is secured [4].
Table 3.3: MPDE Jacket Water Heater Modeled Behavior
Behavior Primary State Operation Secondary State Operation
Change Variable Change Variable
1 Mission-Charlie (starts) Off-On None NA 2 Mission-Charlie (ends) On-Off None NA 3 Mission-Bravo (starts) Off-On None NA 4 Mission-Bravo (ends) On-Off None NA 5 Mission-Alpha Normal (starts) Off-On None NA 5a Mission-Alpha Normal (ongoing) On Randomly On-Off (Often) 5b Mission-Alpha Normal (ongoing)
Off Randomly Off-On
(Often)
6 Mission-Alpha
Normal (ends)
On-Off None NA
Figs. 3-10, 3-11, and 3-12 show the transient and steady state power traces used to model this load as a finite state machine. Similar to the MPDE lube oil heater, two state change variables were used in order to only trigger a change in load state if both logic gates were passed. The primary state change variable is the same as the pre-lube pump and will only activate if their associated MPDE is put in standby or secured. The secondary state change variable, namely “random” is meant to model the automatic mode the heater enters once the engine secures and will energize and secure the heater at random times will its associated MPDE is in standby or secured. The SPS applies the power trace in Fig. 3-10 when the load’s paired MPDE is placed in standby or secured. The SPS will repeat the power trace in Fig. 3-11 until a predetermined amount of time elapses, at which point power trace in Fig. 3-12 is applied. The jacket water heater stays energized for a longer period than the MPDE lube oil heater. This pattern is repeated until the load’s associated MPDE is energized, at which point the Fig. 3-12 power trace is applied if the load is not already secured.
Figure 3-10: MPDE Jacket Water Heater “Off-On” Power Trace
Figure 3-11: MPDE Jacket Water Heater “On” Power Trace
3.4
SSDG Lube Oil Heater
Similar to the MPDE lube oil heater, the SSDG lube oil heater keeps engine lubricating oil temperature within a set range while the engine is secured. Unlike the other loads served from the sub-panels, the lube oil heater is a line-to-line single-phase load of 1.3kW. The heater secures when the SSDG is brought online and the temperature rapidly increases above the upper set point. The lube oil heater operates in relatively short cycles of 10-30 minutes when the engine is secured [4].
Table 3.4: SSDG Lube Oil Heater Modeled Behavior
Behavior Primary State Operation Secondary State Operation
Change Variable Change Variable
1 Mission-Charlie (starts) Off-On None NA 1a Mission-Charlie (ongoing) On Randomly On-Off (Very Often) 1b Mission-Charlie (ongoing)
Off Randomly Off-On
(Very Often) 2 Mission-Charlie (ends) On-Off None NA 3 Mission-Alpha Normal (starts) Off-On None NA 3a Mission-Alpha Normal (ongoing) On Randomly On-Off (Very Often) 3b Mission-Alpha Normal (ongoing)
Off Randomly Off-On
(Some-times)
4 Mission-Alpha
Normal (ends)
On-Off None NA
Figs. 3-14, 3-15, and 3-16 show the transient and steady state power traces used to model this load as a finite state machine. The ship mission drives the generator configuration. The generator configuration determines whether generator loads are energized, de-energized, or cycling. The primary state change variable for the SSDG lube oil heater is the mission and will only activate if the load’s associated generator is put in standby or secured. The secondary state change variable, namely “random” is used to model the 30 minute runs at intermittent intervals. The SPS applies the power trace in Fig. 3-14 when the load’s paired generator is placed in standby or secured. The SPS will repeat the power trace in Fig. 3-15 until a predetermined amount of time elapses, at which point power trace in Fig. 3-16 is applied. This pattern is repeated until the load’s associated generator is energized, at which point the Fig. 3-16 power trace is applied if the load is not already secured.
Figure 3-14: SSDG Lube Oil Heater “Off-On” Power Trace
Figure 3-15: SSDG Lube Oil Heater “On” Power Trace
3.5
SSDG Jacket Water Heater
The SSDG jacket water heater serves the same purpose as the MPDE jacket water heater, maintaining the water temperature in a set range when the generator is secured [4].
Figure 3-17: SSDG Jacket Water Heater (reproduced from [4])
Figs. 3-18, 3-19, and 3-20 show the transient and steady state power traces used to model this load as a finite state machine. Similar to the SSDG lube oil heater, two state change variables were used in order to only trigger a change in load state if both logic gates were passed. The primary state change variable is the same as the SSDG lube oil heater and will only activate if their associated SSDG is put in standby or secured. The secondary state change variable, namely “random” is meant to model the automatic mode the heater enters once the engine secures and will energize and secure the heater at random times will its associated SSDG is in standby or secured. The SPS applies the power trace in Fig. 3-18 when the load’s paired SSDG is placed in standby or secured. The SPS will repeat the power trace in Fig. 3-19 until a predetermined amount of time elapses, at which point power trace in Fig. 3-20 is applied. The jacket water heater stays energized for a longer period than the SSDG lube oil heater. This pattern is repeated until the load’s associated SSDG is energized, at which point the Fig. 3-20 power trace is applied if the load is not already secured.
