A parallel microgrid can contain several PCS units operating as one power-conversion system. When something goes wrong, an alarm saying “inverter fault” is rarely enough to identify the problem.
Engineers need to know which unit reported it, what the other units were doing, whether communication was healthy, and what changed immediately before the event.
That makes remote diagnostics a core function of the controller, not simply a convenience for operation and maintenance. A well-designed microgrid controller should turn information from multiple inverters into a clear diagnostic picture that can be reviewed without standing beside the equipment.
Parallel operation changes the troubleshooting process. If one inverter stops contributing power, the remaining units may continue operating, making the system appear healthy from a distance even though redundancy has already been reduced.
A useful controller should therefore identify individual PCS units and expose their operating status separately. Operators need to distinguish between a complete system fault, a single-unit fault, a communication interruption, and a unit that has intentionally reduced its output.
Our Hub is designed to coordinate multiple MGC units and supports up to 32 units operating in parallel. That architecture makes unit-level visibility particularly important because the controller is responsible for coordinating a group rather than supervising a single converter.
Diagnostic information should ideally include the unit's online state, active alarms, operating mode, power contribution, and communication condition. Without that separation, technicians may waste time investigating healthy equipment while the actual problem remains isolated inside one PCS.
A diagnostic system becomes much more useful when it provides context around an alarm. Consider a parallel inverter that suddenly reduces output. The immediate question is not merely why the output changed, but whether the reduction came from an internal protection event, a battery-side condition, a grid command, a communication issue, or coordinated system control.
For that reason, remote diagnostics should combine alarms with operating values and event information. Relevant data may include active and reactive power, voltage, frequency, battery status, operating mode, and communication state, depending on the system architecture.
Communication information deserves particular attention. Our Hub uses high-speed CAN communication for coordination and lists a communication speed of up to 1 MHz, with a specified power-output response to grid dispatch of less than 10 ms.
That communication path is part of the control system, so its condition can become a diagnostic clue. A controller that can identify communication loss or abnormal communication behavior helps engineers separate a control-network problem from a PCS hardware problem.
Protocol accessibility also affects troubleshooting. The Hub supports Sunspec, Modbus TCP, and Modbus RTU transmission, providing standardized interfaces through which system information can be exchanged with other equipment.
Looking at one inverter at a time is not enough when the units are expected to operate together. A parallel inverter system has relationships between units that can become as important as the status of any individual converter.
Suppose one PCS is producing substantially less power than its peers. The controller should help the operator determine whether the difference is expected because of dispatch or control settings, or whether the unit is unable to deliver its commanded output.
The same principle applies during changes in system conditions. If several units alter their output simultaneously, engineers need to see the event as a coordinated system response rather than several unrelated alarms.
Our Hub is specifically positioned as a coordinated control platform for MGC units, rather than merely a local display. It combines MGC synergy with high-speed communication and supports system-level control of multiple units.
That distinction is important for remote troubleshooting. The diagnostic interface should allow engineers to move between the overall microgrid state and individual equipment without losing the relationship between them.
A practical interface should therefore answer three questions quickly: What happened to the system? Which unit or subsystem caused it? What were the other units doing at the same moment?
Permanent failures are comparatively easy to investigate. Intermittent faults are harder because the equipment may be operating normally by the time a technician arrives.
Remote diagnostics become valuable when they preserve information from the fault event. Historical operating data, alarm records, communication status, and changes in operating mode can help reconstruct what happened rather than relying on memory or a snapshot taken hours later.
Remote access should also support maintenance without requiring every intervention to happen physically at the site. Our Hub includes a built-in mini web server with Web UI access and supports remote software upgrades.
That capability can shorten the distance between diagnosis and corrective action. It does not mean every fault should be solved remotely; electrical and safety-related interventions still require appropriate site procedures. The advantage is that engineers can often determine what needs attention before dispatching field personnel.
Our broader service model also includes regular remote maintenance intended to provide real-time insight into system operation and support continued system performance.
For distributed microgrids, this can be particularly useful. A remote site may have limited technical personnel, while the equipment itself can be spread across industrial facilities, islands, remote communities, or other locations where every site visit adds time and cost.
We would specify remote diagnostics around the troubleshooting workflow rather than around the number of data points displayed.
First, the controller should provide equipment identification. Operators need to know which PCS, battery interface, or communication path is affected.
Second, it should provide real-time operating context. Power, voltage, frequency, battery information, operating mode, and other relevant measurements help explain the alarm rather than merely announcing it.
Third, it should preserve event and historical information. Intermittent faults require evidence from before, during, and after the abnormal event.
Fourth, the controller should expose communication health. A system cannot be diagnosed reliably if the diagnostic platform cannot distinguish missing data from abnormal equipment behavior.
Fifth, it should support remote access and maintenance functions appropriate to the system. Web-based access and remote software maintenance can reduce unnecessary site visits, provided cybersecurity and operational authorization are properly addressed.
Finally, the controller should preserve the relationship between the parallel units. The objective is not simply to collect more data; it is to make the data useful for understanding coordinated behavior.
At WidenEdge, we designed the Hub around coordinated MGC operation, combining parallel-unit control, high-speed communication, industrial protocols, Web UI access, and software-upgrade capability.
For an EPC or system operator, the most valuable microgrid controller is therefore not necessarily the one with the largest monitoring dashboard. It is the one that can connect an alarm to the affected unit, operating condition, communication state, and system response.
That is ultimately what remote diagnostics should accomplish in a parallel microgrid: reduce the distance between “something changed” and “we know why it changed.”
When multiple PCS units must operate as one system, that diagnostic chain is essential for efficient troubleshooting, maintenance planning, and reliable long-term operation.
Return
