Microgrids have been around for as long as the electric generator. Indeed, before we built a highly centralized grid, electricity was generated, distributed, and used in small microgrids.

And interestingly enough, these very first microgrids were DC microgrids.

They were built by Thomas Edison in New York City, prior to Tesla’s introduction of multiphase alternating currents (AC) that changed the electricity generation, distribution, and consumption for good.

Today’s microgrids are very different. They are driven by our society’s quest for sustainable and renewable power generation, the need for a more flexible, versatile, and resilient power system, and the ability to effectively control power flow with power electronics converters.

There are three main types of microgrids:

  1. Customer microgrids (what we all consider as “standard” microgrids)
  2. Utility distribution microgrids
  3. Remote microgrids.

Customer microgrids are true microgrids thatare self-controlled subsystems connected to the grid downstream from a point of common coupling (PCC).

Utility distribution microgrids are distribution subsystems, part of the regulated grid, that are owned and operated by a utility with the goal of helping the utility manage DER portfolios and improve reliability on the network.

Remote microgrids (power systems) are islanded power systems that never operate in grid-tied mode.

Here we focus on the grid-tied microgrids that can operate both in the islanded and grid-tied modes.

Microgrid controls requirements

Microgrids are complex systems since they have to provide all the functions of a large grid, including dynamic control and stabilization, yet with a much simpler control infrastructure, smaller number of generators, and significantly smaller system inertia.

The dynamics of modern microgrids span time constants ranging from microseconds to seconds and all the way to minutes and hours. While the utility grid has a much larger set of resources available for grid control and stabilization, microgrids are expected to achieve the same power quality with a drastically smaller number of energy resources and often with large penetration of intermittent power sources (PV, wind etc.).

And this is why control and stabilization of microgrids are complex.


Microgrids are expected to provide a subset of the 6 key functions:

  • Frequency and voltage regulation
  • Spinning reserve
  • Standalone operation
  • Seamless transition from grid-tied to islanded modes
  • Peak shaving
  • Load shifting

All of these 6 functions are enabled by a microgrid controller.

The microgrid controller architecture

Microgrid controllers are both temporally and spatially distributed, due to the nature of the underlying microgrid that is controlled.

Temporal distribution of a microgrid controller comes from the fact that microgrid controllers control the system dynamics spanning from millisecond-second range (voltage and frequency control) all the way to minutes and hours (load shifting and dispatching) as depicted in the previous graph.

Spatial distribution of a microgrid controller stems from the fact that most microgrid devices (that are by definition distributed) have lower level controllers (fast) on the devices, while higher level controllers (slower) are either: centralized, distributed, or a hybrid between the two.

A central microgrid controller topology has one master controller communicating directly with microgrid devices which are responsible for control and coordination of all the devices. The problem with central control is that there is a single point of failure, but this can be mitigated by duplicating the controller.

A distributed control architecture means that control tasks are performed on multiple controllers and inherently implies robustness to control and communication faults. This approach provides more flexibility and fault tolerance, but comes at a price of more complex control design and hence more complex test and validation.

In practical microgrids centralized controllers are still predominant, however, there are more examples of distributed controls emerging and we are seeing significant research focus on distributed controls.

Primary controllers

Microgrids comprise a spectrum of devices some of which have their own controllers and communication links and some are purely passive. Examples are:

  • Solar PV generators
  • Fuel Cells
  • Gensets
  • Battery Storage
  • Flywheels
  • Wind generators
  • Hydroelectric generators
  • Protection Relays
  • Active Filters
  • Loads

Although individual device controllers are tested by the manufacturer to meet standard grid codes and quality standards, this does not guarantee that the device will necessarily play well with others once integrated into the microgrid.

Especially considering that microgrids usually have much weaker power quality control and can be characterized as weak grids. It is a common problem that multiple solar inverters, connected on a weak microgrid can start interacting, therefore creating fault conditions. These same inverters, if connected to a strong grid, would operate normally.

In many commercial projects, microgrids are built by upgrading an existing distribution (sub)system with a microgrid controller, protective relays, and renewable generation in tandem with energy storage. These microgrids provide a challenge to reliably control and tuning due to lack of component interoperability.

Today, most of the interoperability issues are (solved) avoided by deploying homogeneous microgrids designed, built, and commissioned by a single vendor.

As we move towards the more heterogeneous microgrids, where equipment and controllers are sourced from different manufacturers, interoperability issues will need to be addressed with standardized testing processes, new testing equipment, new standards and new ways of test automation. Indeed, all of the new devices included in the design need to be compatible with legacy microgrid components.

How to test and validate microgrid controller

Whether you are developing a microgrid controller, a smart inverter or any distributed energy resource, or a complete system, microgrid controller—that includes software, firmware, and communications—needs to be extensively tested and validated.

This requires testing each microgrid component separately (PV inverter, battery inverter etc.), varying groups of assets/subsystems (i.e. diesel genset with critical load groups), and finally the entire system. Yes, this is an exhaustive amount of testing that requires a lot of time and money, so we need to test in the most efficient ways possible.

Today, the most widely adopted approach is to either directly jump into system building and test while building and commissioning, or to test using a microgrid test lab.

Power labs are really impressive pieces of engineering, but testing microgrid controller firmware and software with high-power and high-voltage microgrid test bed is not only expensive but also highly inflexible way of testing with limited test coverage.

Hardware in the loop (HIL) simulation (sometimes referred to as the Controller Hardware in the Loop (C-HIL)) is a testing practice that is new to the power industry. The testing technique has been around for decades in automotive and aerospace industries and has been critical to the testing of their controllers.

For the case of power electronics and microgrids, this involves simulating the power stage with ultra-high fidelity and using the real controller in the loop with the real-time simulation. In other words, a HIL microgrid test bed has an identical control system to your real microgrid, only the power hardware is emulated with ultra-high fidelity.

Hardware in the Loop microgrid testing allows for:

  • Unsupervised controller testing, 24/7;
  • Automated testing;
  • Repeatable test conditions;
  • In-house replication of the accredited lab test conditions;
  • Automated test reporting;
  • Unified test procedures thanks to hardware abstraction
  • Continuous integration (CI) test practices,
  • Orders of magnitude lower cost per test point.

Although there are no existing standards covering microgrid controller testing, testing a controller from the start of development using hardware in the loop simulation tools cannot be stressed enough. After your controls have been vigorously tested, power tests are just as essential for hardware testing and final systems testing.


Microgrid Controller Standards

Although there are no existing standards in the United States covering microgrid control, interoperability, and microgrid control testing there are two IEEE working groups developing: IEEE2030.7 and IEEE2030.8 specifically for microgrids controllers.

P2030.7 is intended to be the “Standard for the Specification of Microgrid Controllers.” As given by the IEEE:

“The reason for establishing a standard for the Microgrid Energy Management System (MEMS) is to enable interoperability of the different controllers and components needed to operate the MEMS through cohesive and platform-independent interfaces. This approach will allow for flexibility and customization of components and control algorithms to be deployed without sacrificing “plug-and-play” or limiting potential functionality…“

P2030.8 is intended to the “Standard for the Testing of Microgrid Controllers.” As given by the IEEE:

“The reason for establishing a standard for testing microgrid controllers, in the context of enabling interoperability of the different controllers and components needed to operate the controller through cohesive and platform-independent interfaces, is to establish standardized testing procedures.“

Before microgrid controllers and testing are covered by standards (such as e.g. solar inverters with UL1741 or BDEW TR3) we as a community will have to develop and apply “de-facto” standards and test procedures. Once the basic test requirements are standardized we will continue to expand test cases and processes

Hardware in the loop will be the central tool that will enable us to deliver advanced microgrids with sophisticated functionality. In addition, HIL will enable us to experiment, learn, and quickly evolve designs while deploying real and reliable designs.