IEC 61850 · TECHNICAL PAGE
Evidence, architecture and limits — without rounding the corners.
This page is for the reader who wants to know what was measured, what is not proven, and how the tool is tested. The shorter, less technical introduction is on the product page.
Last updated: 14 November 2026
01 / HOW IT WORKS
How it works.
Four steps, from the configuration file to the report. Each step has a defined input, and its output is what the next step consumes.
- 01
Open the configuration
Reads the network configuration file and shows the devices and their communication — before any physical connection is made.
- 02
Analyse the traffic
Reads recorded network messages and compares them with that same configuration.
- 03
See the difference
Each finding is tied to its evidence: the frame, the field, and the matching place in the configuration.
- 04
Hand over the report
Produces an HTML report from the current analysis: an issue list and a test-case pack, ready to deliver.
The report is not produced until traffic has been analysed; it is built from what was measured.
02 / EVIDENCE
Numbers that were measured, claims that were not.
Every number on this page comes from a recorded measurement. Protocol tests without comparison to an independent implementation only confirm themselves, so GridSight’s tests are pinned to third-party capture bytes.
- 804tests green0 failed · 0 errors · 0 skipped
- 73.6%line coverage across the project92.5% in the MMS module · per-module floors enforced
- 5wire-format defects found and fixedall five surfaced only against third-party capture
- 0interoperability claims without evidenceno live session, no claim written
Measured 29 October 2026 on the interop working branch, with JDK 17 and Gradle 9.3.1. It is not merged into the main branch yet.
What is not proven yet
- No live session has ever run between GridSight and real equipment; no device has accepted a GridSight request.
- The test captures do not state the product or version that produced them, so “works with X” is not written.
- The response direction in those captures is not usable as conformant reference data and has not been asserted separately.
- MMS capture and monitoring are deliberately out of scope.
03 / ARCHITECTURE
The protocol stack is written, not wrapped.
Every layer is a Kotlin module. The reason is plain: for offline operation, control over ASN.1 and no external runtime dependency, you cannot wrap an unknown C library and call the result a product.
iec61850-asn1ASN.1/BER codec and the base data typesiec61850-mmsMMS over ISO: COTP, Session, Presentation, ACSEiec61850-gooseGOOSE publisher and subscriberiec61850-svSampled values (9-2LE)iec61850-sclSCL parser and validationcore · capture · diagnosticsmodel, packet capture and the diagnostic enginesimulator · ui · clivirtual devices, desktop interface and command line
Not every layer is complete, and they are not tested equally. The measured state of each one is recorded in the documentation repository, not on this page.
04 / RELEASE STATE
The release path, gate by gate, with no promised date.
The order is deliberate: the interface does not get more complete until interoperability is proven. No release date has been announced.
Of the eight release gates: one closed, two in progress, five ahead.
- G0
Reconcileclosed
Clean tree, green build, test count recorded.
- G1
Interoperability provenin progress
Third-party capture evidence recorded; a live session and a named peer remain.
- G2
The interface runsin progress
The desktop shell compiles and carries 260 UI tests; a full run against a real configuration is not yet a closed criterion.
- G3
The reportahead
One configuration, one exported report with an issue list and a test-case pack.
- G4
Package and licenceahead
Licence file, tagged version and an installable artefact.
- G5
The demoahead
A ten-minute reproducible story on a synthetic configuration, with no client data.
- G6
First paid useahead
One external user runs it and pays — service or seat.
- G7
Public releaseahead
Release notes, a known-limits page and a support route.
05 / TEST METHOD
Why symmetric tests are not enough.
If GridSight writes a field wrongly and reads it wrongly, the round trip is green and the code is wrong. A real device simply does not answer, and the engineer sees “no response” with no explanation.
So the protocol tests are pinned to bytes written by a different implementation. Five wire-format defects — including a misplaced request identifier and shifted service tags in the name-list family — were found only by that comparison.
There is also a composed conversation test: association, name list, read and release, taken from two captures of the same peer. Every byte is third-party, but the sequence is not one recorded session — and the documentation says so.
The full note: what a GOOSE capture proves, and what it cannot ↗
06 / DOCUMENTATION
Everything, written down and checkable.
The state of each gate, the interoperability evidence, the test method, the glossary and every known limitation — including one defect deliberately left open — are in the public documentation repository.
NEXT STEP
If this is a technical decision, start with one file.
Send one sample configuration; we open it, list the conflicts, and tell you what GridSight has — and does not have — for that job.