top of page

Firmware updates are now compliance events

Updated: 4 days ago


Here's a scenario every asset manager will recognise. The OEM pushes an inverter firmware update — improved fault ride-through logic, better harmonic performance, routine stuff. It's applied across the site during a maintenance window. Operationally, nothing skips a beat.

Under the Template for Compliance Programs, that update is a compliance event. In fact it's the Template's own worked example — Chapter 3 uses an inverter control system update to illustrate exactly this category of change.

New Principle 5 requires that where plant performance may be affected by hardware modifications, equipment replacements, software updates, firmware changes or any similar plant change, the Registered Participant must promptly assess whether the change could affect compliance with existing performance standards — or require updates to the models and data previously provided to AEMO and the NSP.

The Template backs this with a formal definition. A plant change is any replacement, refurbishment or system change the participant considers may affect the plant's capability to meet a performance standard — explicitly including changes to software or firmware associated with digital control and protection systems.

Why the emphasis? Because in an inverter-based power system, behaviour lives in code. A settings change can alter a plant's disturbance response as materially as swapping a transformer. The Panel is aligning the compliance framework with the engineering reality.

Practically, a plant change ripples through your compliance program in four ways.

Reassessment triggers. Look across the clause tables and you'll find "after plant change" attached to suggested assessment frequencies almost everywhere — reactive capability, voltage control step tests, protection injection testing, control system setting checks. Your program needs a mechanism that catches a change and triggers the right reassessments.

The clause 5.3.9 pathway. Some alterations sit on the deemed list at clause 5.3.9(d) and require a submission; others will if they affect performance against the schedule 5.2 technical requirements or, in AEMO's reasonable opinion, system strength, power system security or network capability. The Panel actively encourages using AEMO's generating system change form to open a scoping process with the NSP and AEMO early — and says explicitly that doing so is consistent with Principle 5. That's a genuinely useful, low-friction step with the Panel's endorsement attached.

Settings approvals. Where a change affects control or protection system settings tied to a performance standard, approval from the relevant NSP and AEMO may be required before you proceed.

The five-business-day clock. This is the one most easily missed. Where a plant change means the models or data previously supplied to AEMO are no longer accurate, updated information must reach AEMO within five business days under NER clause 5.3.8(f), and the NSP promptly. Combined with Principle 5, that connects OEM patch cycles directly to a regulatory clock. For a portfolio running fleet-wide inverter updates, that's a workflow question as much as an engineering one.

The uncomfortable question for many GCPs: does your program actually know when a plant change happens? In our experience the gap is rarely wilful — it's that the maintenance workflow and the compliance workflow live in different systems, and firmware versions don't announce themselves. A compliance program that satisfies Principle 5 needs a register of changes, an assessment step, and a record of the reasoning — plus monitoring capable of confirming the plant still behaves as modelled after the change lands.

That last point is where continuous monitoring quietly earns its keep: the fastest way to validate post-change behaviour is to watch the plant respond to real system events.

How does your organisation track plant changes today? We'd genuinely like to hear — it's one of the most varied practices we see across the NEM.

Q: Do software or firmware updates count as plant changes?

A: Yes. The Template's definition of a plant change explicitly includes changes to software or firmware associated with digital control and protection systems, where the participant considers the change may affect capability to meet a performance standard. Continuous monitoring allows the impacts of these updates to be monitored. The Template uses an inverter control system update as its worked example.

A: Some alterations are on the deemed list at clause 5.3.9(d); others require a submission if they affect performance against the schedule 5.2 technical requirements or, in AEMO's reasonable opinion, system strength, power system security or network capability. The Panel encourages using AEMO's generating system change form to scope this early.

A: Where you become aware that models, data or information previously supplied are incomplete, inaccurate or out of date, updated information must reach AEMO within five business days under NER clause 5.3.8(f), and the NSP promptly.

A: Where a change affects control or protection system settings necessary to comply with an existing performance standard, approval from the relevant NSP and AEMO may be required.


bottom of page