From GridLAB-D Wiki
Jump to: navigation, search

REQUIREMENT

 *** WORKING DRAFT *** 
Please review, edit and comment as necessary.


Application Concept

The purpose for developing a secondary controller object is to enable the redispatch of setpoints during a simulation to return frequency to its nominal value.

Use Case

The following use cases/research questions are of potential interest. They are each labeled for reference in further discussion.

  • (U0) The secondary controller will first of all simply enable a dynamic simulation to run for longer while maintaining realistic results, i.e. nominal frequency and voltage.
  • (U1) What are potential issues in the interaction of various generators (Grid Forming, Grid Following, Rotating) via a secondary controller.

Requirements

  • (1) The secondary controller should be able to interact with any object that has an active and/or reactive power setpoint ( Diesel, Inverters, loads, etc.) and can participate in both Delta mode and QSTS.
    • As some control models require the adjustment from the secondary controller to be the full schedule and not just a delta, the controller object must be able to see all participating object's schedules.
  • (2) The secondary controller should be able to but not have to control all compatible objects from the previous point.
  • (3) Each participant in secondary control should be assigned a participation factor indicating what part of the power mismatch is mapped to this unit
    • participation factors should be alterable over the course of the simulation.
    • participation factors for active power and reactive power need not be the same.
  • (4) The secondary controller should implement a PID control that will ensure zero frequency error in the steady-state, as well as a voltage profile within tolerance bounds (U0).
  • (5) The time interval at which secondary control signals are sent should be allowed to vary.
    • There should be an ability to "discretize" the output signal, i.e. receiving unit only get an update every x seconds.
    • There should also be an ability to slew the output signal to specific generators (e.g. integral control) in order to avoid excessive setpoint jumps.
  • (6) The capacity available to the secondary controller need not be the same as the full capacity of the object in question.
  • (7) The secondary controller must respect object limits for the quantities it is regulating. If a limit is reached, that object's participation must be redistributed among the remaining units.
  • (8) All gains/parameters in the secondary control should be alterable to allow for higher level EMS/Microgrid Controller, etc. to adjust to varying system conditions.

Performance and Validation Tests

  • (P0) Simulate load coming online without secondary control. Frequency should stabilize but not at nominal.
  • (P1) Repeat P0 but with secondary control. Does frequency return to nominal?
  • (P2) Repeat P0, but instead of secondary control allow one unit to operate in isochronous mode. How is the response different w.r.t P1?
  • (P3) Simulate a long feeder section coming on without secondary control, resulting in voltage voltage violations.
  • (P4) Repeat P3 but with secondary control. Does the voltage stabilize inside the appropriate band.

Open Questions and Future Work

Future expansion could address the following questions via these scenarios:

  • (U2) How might secondary control be "stacked" and interact with each other for interaction in networked microgrids.
    • The secondary controller object would be able to itself participate in secondary control
  • (U3) Can secondary control be "expanded" to consider other objectives:
    • This will require somehow capturing the "interface" through which regions interact, i.e. inter-ties/PCC and the scheduled export/import power via these objects.
    • Classical inclusions in Secondary Control (i.e. AGC):
      • Resource allocation, i.e. "optimal" (however that is defined).
      • Maintain intertie flows (also relevant for networked microgrids).
    • Some additional aspects may include:
      • Reserves considerations
      • Inertia, etc.
    • Participation factors will be function dependent. That means that a generator might for example have a participation factor for frequency control, a different one for VAR control, etc.
  • (U4) How should the secondary controller be altered during contingency events to reallocate factors, potentially adjust gains, etc.
  • (U5) This controller is modeled explicitly as a centralized entity. Future work could consider distributed solutions, although the object structure would likely need to change so much that a new implementation will be necessary.


See Also

Spec:sec_control