Modelling

Modelling your device in IEC 61850 without regretting it in five years

2026-10-29 · 9 min read

The ICD you ship becomes an interface contract with every customer who buys the device. Get it wrong and no amount of protocol correctness saves you, because the master station was configured against a model that no longer matches the device. The good news is that most modelling mistakes are known, cheap to avoid, and visible in the first hour if you look for them.

Start from the data, not from the register map

The tempting shortcut is to take the existing Modbus table and give every row a GGIO instance. It works, it is fast, and it produces a device that no engineer can read: nobody can tell a breaker position from a temperature offset without the mapping document.

Start instead from what each point is: a measurement with a unit, a status with a quality, a controllable device with a behaviour. That decision determines the common data class, and the CDC determines which attributes exist and therefore what a client can do with the point.

Choose the LN class deliberately

Three cases, three different answers:

• There is a standard logical node for it (protection, switchgear, measurement, control). Use it. A customer tool will recognise it, and the semantics come for free.
• There is no standard node but the structure is standard. Then pick a generic node with the right CDC — a status point that is genuinely just a status belongs in a generic node with a status CDC, not in a substitute for something else.
• Nothing fits. Generic nodes exist precisely for this, and using them is correct — using them for everything is the mistake, because a model made entirely of generic nodes tells the reader nothing.

The attributes that people forget

A functional model is not the same as a usable one. These four are what make data trustworthy downstream:

• Quality on every measured and status value, propagated from the source rather than set to good by default.
• Timestamps with a defined time base, carried through every layer that touches the value.
• Units (SIUnit) and scaling (scaleFactor/offset) so a client does not have to guess from the point name.
• Description text (d) that names the physical thing. This is the cheapest documentation your device will ever carry, and it travels with the model.

Instance numbering and naming

Numbering is not cosmetic. Instances must be stable across firmware versions, because a master configured against MMXU1 will not silently move to MMXU2. Decide the rule once — contiguous from 1 within each logical device is the usual convention — write it in the manual, and never let a build script renumber them.

Who owns the ICD

Name an owner. In practice the failures happen when the file is generated by a tool, edited by hand during commissioning, and then regenerated — the hand edits vanish and the site configuration diverges from the repository.

• The ICD is generated, never hand-edited as the primary artefact.
• It lives under version control with a changelog readable by a customer.
• Every delivered file carries an identifier and a revision that map to a firmware version.
• A diff between two revisions is a deliverable you can hand to a customer who asks what changed.

The first-hour check

Before the model leaves your desk, read it as a stranger would and confirm you can answer these without the mapping spreadsheet:

• Which logical device holds the measurements, and why?
• What does each generic instance represent, from its name and description alone?
• Which points are controllable, and by which control model?
• Is every dataset a coherent set that a client would actually subscribe to, or an artefact of how the code groups variables?

Questions that come up

How many logical devices should a device expose?

As few as carry clear meaning. One per physical function or per network-visible service boundary is enough. Splitting by code module produces a structure that mirrors your source tree, which is of no interest to the customer.

Is it acceptable to expose the same value in two places?

Occasionally, for compatibility, but mark it: an alias makes a client subscribe twice and doubles the traffic. If you must duplicate, document which one is authoritative.

Can we change the model after the device is in service?

You can, but every change is a re-engineering event for the customer. Reserve additions for new data (which existing clients can ignore) and treat renames and renumbering as breaking changes that need a migration note.

Keep reading