FUNCTIONS OF PCON NGIPS PCON Workshop Annapolis, MD June 15, 2009

1. FUNCTIONS OF PCONNGIPS PCON WorkshopAnnapolis, MDJune 15, 2009 CAPT Norbert Doerry Technical Director, Surface Ship Design and Systems Engineering Naval Sea Systems Command Norbert.doerry@navy.mil (202) 781-2520 Approved for Public Release

2. PCON in the NGIPS Roadmap “The Power CONtrol module (PCON) consists of the software necessary to coordinate the behavior of the other modules. The PCON Software may reside in other modules, or may reside in an external distributed computer system. The PCON Software interacts with the human operators through a Human-Computer Interface that will typically be part of a ship-wide monitoring and control system.” June 2009 Approved for Public Release CAPT Doerry 2

3. What’s left? • What is the control architecture for PCON? • Hierarchical (supervisory, zonal, local) with graceful degradation toward more distributed, localized autonomy? • Replicated vs Fail-over • Distributed with greater autonomy but reduced coordination? • How should control system redundancy be specified and managed? • What is the PCON fault detection, isolation and recovery strategy? • Redundancy, spatial & functional separation • Maximize reconfigurability of integrated system • How does PCON fit into the HM&E ship infrastructure? • Separate from other engineering and damage control? • Highly integrated with engineering and damage control? • Integrated machinery monitoring and maintenance? • How and where are PCON functional modules allocated among? • Standard shipwide computing “cloud”? • Standard shipwide HMI? • Engineering subsystem? • Machinery modules? June 2009 Approved for Public Release CAPT Doerry 3

4. What’s left? (continued) • How does PCON manage data and interact with other systems? • Replicated, distributed databases? • Publish / subscribe? • Highly integrated versus highly dispersed? • How is the PCON Software integrated into hardware modules? • Should NGIPS Modules reserve space, mounting points, power, data connectivity, and cooling for control hardware to host PCON? • How is the HMI software interface to PCON defined? • How is data connectivity provided? • Interfaces to modules? • Latency & fault tolerance requirements? • Integration with ship wide infrastructure? • Connectivity path between loads and PCON? June 2009 Approved for Public Release CAPT Doerry 4

5. Load Interfaces Simple Load Controlled Load Intelligent Load Power SystemInterface Device Power SystemInterface Device Power SystemInterface Device Power SensorFeedback Bi-Directional Comms withPCON LOAD LOAD LOAD In NGIPS PSID is either PCM-1Aor PCM-2A No Comms Load Sheddingat PSID Sensor Feedback Load Sheddingat PSID Bi-directional Comms Load Sheddingat LOAD 5 Most Legacy Loads VSD in PCM-2A Future Loads / MV Loads

6. Power Control System Interface with Loads • PCON interface with loads facilitates adaptive (QOS and Mission Priority) load shedding • How is the PCON interface with the load provided? • Use ship-wide network with network provided Control System Access Point (CSAP). • Use ship-wide network with NGIPS provided CSAP. • Direct connection to NGIPS Module with NGIPS provided CSAP. • Must Specify all layers of the OSI Model. • Appropriate Standards exist for all but the Application Layer. • LONWORKS (ANSI/EIA 709.1 Control Networking Standard) could be a model for the Application Layer. (others may exist) • Using power cables for the Media Layers can reduce costs by eliminated dedicated signal cables. • ANSI/EIA 709.2-A-2000 Control Network Powerline (PL) Channel Specification • IEEE P1901 Draft Standard for Broadband over Power Line Networks: Medium Access Control and Physical Layer Specifications http://www.3mfuture.com/network_security/arp-guard-arp-spoofing.htm LONWORKS Object Model Echelon 1999 June 2009 Approved for Public Release CAPT Doerry 6

7. CSAP LOAD CSAP LOAD MFPM LOAD MFPM Switch PCM-2A Architecture (IPNC based) Power Architecture Control Architecture Where is this? Input MFPM MFPM LOAD MFPM LOAD Ship Wide PCON ZonalPCON MFPM LOAD Not currently part of IPNC Spec Input MFPM MFPM LOAD MFPM Ship wide HMI LOAD LOAD Switch Local Control LOAD Other SystemControl PSID PSID = Power System Interface Device Not currently part of IPNC Spec CSAP = Control System Access Point MFPM = Multi-Function Programmable Module June 2009 7

8. PCM 2A Basis (IPNC Spec) http://www.powerparagon.com/pdfs/Bulletin%20446%20PNCC%20-08%20Hi%20res.pdf June 2009 Approved for Public Release CAPT Doerry 8

9. Controlled Loads • IPNC included Multi-Functional Programmable Modules (MFPM) • Unclear of the design process for the software to control the loads • May have to communicate with other system supervisory controls • Is this part of PCON? • Or is it part of the load’s parent system, it just happens to reside in an NIGIPS module. • Need control interface in any case. Power SystemInterface Device MFPM Flow Rate LOAD HVAC Fan Sensor Feedback Load Sheddingat PSID VSD in PCM-2A June 2009 Approved for Public Release CAPT Doerry 9

10. SurvivabilityAs applied to Distributed Systems • Zonal Survivability • Zonal Survivability is the ability of the distributed system, when experiencing internal faults due to damage or equipment failure confined to adjacent zones, to ensure loads in undamaged zones do not experience an interruption in service or commodity parameters outside of normal parameters • Sometimes only applied to “Vital Loads” • Compartment Survivability • Even though a zone is damaged, some important loads within the damaged zone may survive. For critical non-redundant mission system equipment and loads supporting in-zone damage control efforts, an increase level of survivability beyond zonal survivability is warranted. • For these loads, two sources of power should be provided, such that if the load is expected to survive, at least one of the sources of power should also be expected to survive. SURVIVABILITY DEALS WITH PREVENTING FAULT PROPOGATIONAND WITH RESTORATION OF SERVICE UNDER DAMAGE CONDITIONS June 2009 Approved for Public Release CAPT Doerry 10

11. Quality of Service • Quality of Service is a metric of how reliable a distributed system provides its commodity (electricity) to the standards required by its users (loads). • A failure is any interruption in service, or commodity parameters outside of normal parameters, that results in the load not being capable of performing its function. • Interruptions in service shorter than a specified amount for a given load are NOT a failure for QOS calculations. • For NGIPS, Three time horizons … • Uninteruptible loads • Interruptions of time t1 – on the order of 2 seconds – are NOT tolerable • Short-term interruptible loads • Interruptions of time t1 – on the order of 2 seconds – are tolerable • Corresponding to fault detection and isolation • Long-term interruptible loads • Interruptions of time t2 – on the order of 2-5 minutes – are tolerable • Corresponding to time for bringing additional power generation on line. QUALITY OF SERVICE DEALS WITH ENSURING LOADS RECEIVE A RELIABLE SOURCE OF POWER UNDER NORMAL OPERATING CONDITIONS June 2009 Approved for Public Release CAPT Doerry 11

12. Notional Total Ship ControlsFunctional Decomposition Mission Systems Resource Systems Mobility Electric Plant Combat Systems Network Damage Control Chill Water Commandand Control Fire Main • Mission Systems directly fulfill the Missions of the Ship. • Resource Systems support Mission Systems & other Resource Systems. June 2009 Approved for Public Release CAPT Doerry 12

13. Additional Potential Resource Managers Ship Compartment Information Manager LEAPS? • Provide information on the geometry and status of ship’s compartments. (Sensor Management?) • Configuration Management master database. Ship Properties Information Manager • Provide information on the geometry and status of the entire ship. (Sensor Mgmt?) • Consistent Interface for Ship Properties. Human Machine Interface Manager • Provide the Sailor-System interface for all other Resource and Mission Controllers. Ideally, these would be the only “custom” resource managers in the ship. All other resource managers would be identical across ship classes. June 2009 Approved for Public Release CAPT Doerry 13

14. Functions of PCON • Remote Monitoring and Control of NGIPS modules • Mobility Control • Quality of Power • Quality of Service • Resource Planning and System Configuration • System Stability • Mission Priority Load Shedding • Vulnerability & Recoverability • Fault Response • Maintenance Support • Training June 2009 Approved for Public Release CAPT Doerry 14

15. Remote Monitoring and Control of NGIPS modules • Architectural Choices • Traditional MCS approach • Publish data on module parameters • HMI system creates screen pages using data from module parameter data base • Web Server approach • Each module has a built in Web Server • Screen Pages created within the modules and served to the HMI via a web browser. • RSS type feeds can be used for system level displays • Combination of Traditional and Web Server June 2009 Approved for Public Release CAPT Doerry 15

16. Mobility Control Is Mobility Control part of PCON? • Rolling Reserve Rqmts • Quality of Service • Dynamic Braking • Survivability • Fuel Economy • Power System Stability June 2009 Approved for Public Release CAPT Doerry 16

17. Quality of Power • MVDC bus has a limited diversity of sources and loads. • Ideal voltage range and degree of regulation is not obvious. • TIGHT TOLERANCE MODEL • Voltages regulated within a relatively narrow band to a set nominal voltage. • Simplifies interface design • LOOSE TOLERANCE MODEL • PCON sets nominal voltage over a wide range. • Regulate voltage within a band around the nominal voltage. • Optimize system efficiency. • Increase complexity of sources and loads. • Increase cable size to enable operation at the lower voltage limit. Voltage time Voltage time June 2009 Approved for Public Release CAPT Doerry 17

18. Implementing QOS and Mission Priority Load Shedding • Two different prioritization of loads • Quality of Service • Short term source – load imbalance • Mission Priority • Long term source – load imbalance • Must be able to control small groups or individual loads • Controllable switches / breakers in power-panels / switchgear / PCM • Power Control (PCON) control interface with loads June 2009 Approved for Public Release CAPT Doerry 18

19. Power Management – Quality of Service • Provide Power Continuity to the degree needed by the loads • Un-interruptible • Short term interruptible • Long term interruptible • ROLLING RESERVE MODEL • Respond to a shortage in power generation capacity by shedding long-term interrupt loads. • Keep sufficient power generation capacity online to power uninterruptible and short-term interruptible loads on loss of the largest online generator. • Restore Long term interrupt loads are when sufficient power generation capacity is restored. • ENERGY STORAGE MODEL • Use energy storage to power uninterruptible and short-term interruptible loads until sufficient power generation is restored to power all loads. June 2009 Approved for Public Release CAPT Doerry 19

20. Resource Planning andSystem Configuration • Provide sufficient power to all loads while providing sufficient rolling reserve • LOAD DEPENDENT POWER MANAGEMENT MODEL • Base rolling reserve on the total amount of load and the current operating condition • RESOURCE MANAGEMENT MODEL • Calculate Rolling Reserve based on negotiations between Resource Managers Radan 2004 June 2009 Approved for Public Release CAPT Doerry 20

21. System Stability • Stability of DC Power Systems complicated by negative incremental resistance of constant power loads. • LINEAR STABILITY METHODS • Generally based on Gain and Phase margins. • Measure of Small Signal Stability only. • Need to address all operating conditions to assess stability. • NONLINEAR STABILITY METHODS • Accurately model the time-varying, non-linear power system including initial conditions, system parameters and inputs. • Determine equilibrium points. • Determine perturbations about each equilibrium. • For each perturbation about each equilibrium, determine the dynamic response of the system and whether it is acceptable G(s) = SL (Flower and Hodge 2005) June 2009 Approved for Public Release CAPT Doerry 21

22. Vulnerability and Recoverability • Zonal Survivability is assumed. Issues become • Which power system components are safe to energize? • Which loads are safe to energize? • What is the priority ranking of loads to re-energize? • OPERATOR-BASED RESPONSE MODEL • System reports the condition of power system equipment and loads. • Operator makes decisions. • AGENT BASED RESPONSE MODEL • Resource Managers (computer agents) determine health of equipment and make decisions. June 2009 Approved for Public Release CAPT Doerry 22

23. Fault Response • Fault Response Actions • Identifies that a fault has occurred • Reconfigures the power system • Protects equipment and cables • CIRCUIT BREAKER MODEL • Fault currents coordinate the tripping of breakers. • Affordability Concerns • DC Breakers • Power electronics sized to provide sufficient fault current • POWER ELECTRONICS MODEL • Sensors and controls detect and localize faults. • Use QOS to enable taking bus down to isolate fault with zero-current switches. • Provide un-interruptible loads with alternate power source. • Requires an architecture and a design methodology. (Phillips 2006) June 2009 Approved for Public Release CAPT Doerry 23

24. Maintenance Support • Integrate equipment tag-out procedures into Power Control System (PCON), Power Distribution, PCM-1A and PCM-2A. • Provide hot-swappable input and output modules in PCM-2A to minimize the number of loads impacted by maintenance action on the PCM-2A. (and possibly PCM-1A too) • Minimize scheduled maintenance on NGIPS modules – especially those that are non-redundant in the power system. • Integrate Condition Based Maintenance into • Power Control System (PCON) • Control interface for NGIPS modules • Power Control System – Load control interface. June 2009 Approved for Public Release CAPT Doerry 24

25. Training • Architectural Choices • School House / Manuals • Onboard Dedicated Training Software • May use HMI common to Operational System • Distributed Web Based Software • Each Module serves up a training simulation of itself • Combination of the above June 2009 Approved for Public Release CAPT Doerry 25

26. Summary • Need to understand the overall ship MCS Control Strategy and Architecture. • Need to decide what is in and what is out of PCON. • Need to ensure someone else is taking care of the stuff that is outside of PCON. • Need to develop a plan for maturing PCON approach, developing software, developing the integration approach, developing specs and standards, and developing the software support plan. Approved for Public Release CAPT Doerry

27. backup June 2009 Approved for Public Release CAPT Doerry 27

28. Traditional Approach Establish Requirements Create a Design Optimize on Acquissition Cost Make Sister Ships Identical Implement in Software & Hardware Modernize to degree affordable End Product Brittle to Changing Requirements June 2009 Approved for Public Release CAPT Doerry 28

29. Proposed Approach Functional Decomposition Develop Architecture Develop Modules Establish Requirements Aggregate Modules Modernize by Replacing Modules Design for a Changing World June 2009 29

30. Robust Design • Minimize Propagation of change across multiple subsystems due to changes in requirements. • Don’t re-engineer the entire system to upgrade one piece of equipment. • Minimize Propagation of change across multiple organizational boundaries. • Does not mean a monolithic controls contractor. • Support Organizations should reflect the functional Decomposition. Reduce Sensitivity to Changing Requirements June 2009 30 Approved for Public Release CAPT Doerry