Grid Operators & DSOs

From form-based registration
to structured import.

DSOs process hundreds of grid connection requests per year — each in a different format, all requiring manual re-keying. DERpass delivers the grid connection chapter, metering concept, and national registration fields as structured, importable data.

What DSOs deal with today.

01

Connection requests in dozens of formats

Some installers use the DSO's online portal. Others submit PDF forms. Others email spreadsheets. Each format requires a different intake process, and none are machine-readable end to end.

02

Staff re-type nameplate data into internal systems

Inverter model, AC capacity, protection relay type, grid connection point ID — all re-typed by hand into GIS, SCADA, and registration systems. Every keystroke is a potential error.

03

Transcription errors cause weeks of delay

A wrong EAN code or a missing MaStR number triggers a rejection, a resubmission cycle, and weeks of additional back-and-forth before the system can be connected. The installer blames the DSO; the DSO blames the installer.

04

Protection settings arrive unstructured

Protection relay configuration, voltage and frequency thresholds, and anti-islanding settings arrive in PDF datasheets or handwritten notes — none of which can be validated or imported without manual interpretation.

What grid operators need from a data standard.

R1

Structured import of grid connection data

Nameplate capacity, grid connection point ID, voltage level, and protection relay settings should arrive as structured fields that map directly to DSO system imports — not extracted from PDFs.

R2

Machine-readable metering concept

The metering scheme type, meter list, OBIS codes, and feed-in direction should be explicitly structured — not described in prose — so they can be validated against DSO metering rules without human interpretation.

R3

National registration fields in a consistent format

MaStR number, BNetzA registration date, EAN code, and E17 metering ID should appear in the same place, in the same format, in every connection request — regardless of which installer prepared it.

R4

Verifiable data provenance

DSOs need confidence that the data submitted matches what is actually installed. Optional signatures on events let a DSO verify that the installer who signed the file is the same one who commissioned the system.

How DERpass addresses these needs.

Grid connection chapter is importable, not re-typed

The grid_connection chapter includes GCP ID, voltage level, AC capacity, protection relay model and settings, DSO contact, and feed-in direction — all as typed, structured JSON fields that map directly to DSO import templates.

Metering concept is fully structured

The metering chapter carries scheme type (net-metering, gross-metering, behind-the-meter), a typed meter list with OBIS codes, and bidirectional feed-in flags — all machine-readable and validatable against DSO metering rules.

National profiles map to registration fields

The DE national profile carries MaStR number, BNetzA registration date, and VDE norm references in fixed, named fields. The NL profile carries EAN code and E17 metering ID. Both map directly to national registry import fields — no transcription step.

Optional JWS signatures for data integrity

Events and file revisions can carry JWS signatures from the installer or commissioning engineer. A DSO can verify the signature to confirm that the submitted data has not been altered since it was signed — without relying on a central authority.

Who this applies to.

Bayernwerk NetzDSO · Bavaria, DE
WestnetzDSO · NRW, DE
E.ON NetzDSO · DE
Netze BWDSO · Baden-Württemberg, DE
StedinDSO · NL
AllianderDSO · NL

See it in a file. The 250 kWp industrial example includes a complete MV grid connection chapter — 20 kV transformer station, VDE-AR-N 4110 protection relay settings, and MaStR registration data — exactly as a DSO would need to import it.