Migration

Replacing libiec61850 without rewriting your device

2026-10-29 · 8 min read

Nobody replaces a protocol stack for fun. You replace it because a target platform appeared, a customer demanded evidence you cannot produce, or a licence question arrived from the legal team. The good news is that the expensive part of your product — the device model, the data mapping, the application logic — does not have to move.

Four triggers, and what each one really costs

• Licensing. GPLv3 in shipped firmware raises questions your legal team will eventually ask. Resolving it via a commercial licence from the maintainer is often the cheapest path — do that before planning a migration.
• A target that is not Linux. This is the most expensive trigger, and the one where a stack with existing ports pays for itself immediately.
• Edition 2 depth. If a master station starts using services your stack only partially implements, the migration is not the whole fix — the gap has to be closed somewhere.
• Evidence. A utility asking for a clause-level report cannot be satisfied by a self-run test, no matter how good the stack is.

What actually has to be rewritten

Separate three layers in your codebase before you plan anything. In most products they are already separable, which is why migrations are usually smaller than teams fear.

• The data model. It lives in an ICD/CID file. It does not change — it is your device, expressed in SCL. Keep the file, move the parser.
• The data mapping layer. Your currents, voltages, status points and settings, bound to model nodes. This is where the real work sits, and where a vendor-supplied mapping tool saves the most time.
• The application logic. Protection algorithms and control sequences. If they call protocol functions directly, this layer is the casualty; if they talk to an internal abstraction, it is untouched.

A migration sequence that does not stop the line

Do it in this order. Each step ends with something you can compare against the old build, which is the only way to prove the migration did not change behaviour.

• Freeze the ICD. Export the exact model currently shipping and treat it as the baseline artefact.
• Stand up the new stack in a simulator on Linux first. Get association, dataset reads, reporting and control working before touching hardware.
• Run both stacks against the same conformance test suite and diff the results. Differences are either bugs or genuine capability gaps — you need to know which.
• Port the mapping layer, then the application glue. Compile with the old code paths behind a switch so you can fall back during commissioning.
• Only then integrate on the real target, and run the acceptance captures on both sides of the link.

What to test before you commit

Ask for a trial build and test it against your own device model rather than the vendor demo. Specifically:

• Your largest dataset, not a toy one.
• Buffered and unbuffered reporting under a data storm.
• Control with select-before-operate, including the negative cases.
• File transfer of a realistic disturbance file.
• Two clients at once — a commissioning tool and a real master, behaving like real masters.
• Restart behaviour: what the server does when the client disappears mid-report.

The migration contract

Insist that the SCL handling, the mapping tooling and the conformance test tool come from the same implementation. If they do not, you are accepting a class of defect where the development stack and the test stack disagree, and you will spend acceptance week discovering which one the customer believes.

Questions that come up

Do we lose our model compatibility?

The ICD/CID does not change. What changes is the parser and the internal representation. Keep the file under version control and the migration becomes verifiable rather than hopeful.

Can we run both stacks in one build during transition?

That is the recommended approach for commissioning, provided only one of them binds the MMS port at a time and the failover is explicit rather than accidental.

What if we only need one feature the old stack lacks?

Then do not migrate. Buy the feature, or patch around it. A migration is justified by a platform, a licence or an evidence requirement — not by one missing service.

Keep reading