Crate mako_redispatch

Expand description

mako-redispatch — Redispatch 2.0 process engine for German grid congestion management (§§ 13, 13a, 14 EnWG).

§Three-crate architecture for Redispatch 2.0

Crate	Responsibility
`edi-energy`	IFTSTA status messages (EDIFACT, PIDs 21037/21038)
`redispatch-xml`	XML/XSD format parsing (`ActivationDocument`, `Stammdaten`, …)
`mako-redispatch` ← this crate	Process engine — workflows, routing, deadlines

§Domain background

Redispatch 2.0 entered into force on 1 October 2021 via the Netzausbaubeschleunigungsgesetz (NABEG). It requires all German TSOs (ÜNB) and DSOs (VNB) to coordinate congestion management across transmission and distribution networks using CIM/IEC 62325 XML documents.

Unlike GPKE/WiM/GeLi Gas (EDIFACT RFF+Z13 Prüfidentifikatoren), routing here is document-type-driven via RedispatchRouter.

§Regulatory basis

`BNetzA` decision	Topic
BK6-20-059	`AcknowledgementDocument` (6h), `StatusRequest` (24h)
BK6-20-060	`Stammdaten` (1 Werktag), Activation (5 min)
BK6-20-061	`Kostenblatt` (15th of following month)

§Regulatory deadlines

Obligation	Deadline	Clock
`AcknowledgementDocument`	6 wall-clock hours	UTC
`StatusRequest` response	24 wall-clock hours	UTC
Stammdaten forward (VNB→ÜNB)	1 Werktag	German local time
Activation (ACO) response	5 minutes	UTC
Kostenblatt submission	15th of following month	German local time

Clock semantics differ from GPKE/WiM. Redispatch 2.0 uses UTC wall-clock hours for the acknowledgement and activation deadlines. Only the Stammdaten-forwarding and Kostenblatt obligations follow German local time (CET/CEST) + Werktag rules.

§Deployment role gate

RedispatchModule should only be registered when DeploymentRoles contains at least one of Marktrolle::Nb, Marktrolle::Unb, or Marktrolle::Anb. Lieferant (LF) and MSB deployments are out of scope for Redispatch 2.0.

§IFTSTA PIDs (confirmed from IFTSTA AHB 2.1 + PID 4.0)

PID	Perspective	Process
21037	NB (VNB)	Kommunikationsprozesse Redispatch — Ansicht NB
21038	BTR	Kommunikationsprozesse Redispatch — Ansicht BTR

These PIDs are registered into the PidRouter by RedispatchModule and route to the aktivierung workflow via conversation-ID lookup.

§Module overview

Module	Workflow name	Document type
`stammdaten`	`redispatch-stammdaten`	`Stammdaten`
`aktivierung`	`redispatch-aktivierung`	`ActivationDocument`
`ack_forward` (Verfügbarkeit)	`redispatch-verfuegbarkeit`	`UnavailabilityMarketDocument`
`ack_forward` (Netzengpass)	`redispatch-netzengpass`	`NetworkConstraintDocument`
`ack_forward` (Kaskade)	`redispatch-kaskade`	`Kaskade`
`ack_forward` (Planungsdaten)	`redispatch-planungsdaten`	`PlannedResourceScheduleDocument`
`ack_forward` (Statusanfrage)	`redispatch-statusanfrage`	`StatusRequest_MarketDocument`
`ack_forward` (Kostenblatt)	`redispatch-kostenblatt`	`Kostenblatt`

Re-exports§

pub use router::RedispatchDocumentKind;
pub use router::RedispatchRouter;

Modules§

ack_forward: Generic acknowledge-and-forward workflow for Redispatch 2.0.
aktivierung: Redispatch-Aktivierung workflow for Redispatch 2.0.
router: RedispatchRouter — maps RedispatchDocumentKinds to workflow names.
stammdaten: Stammdatenübermittlung workflow for Redispatch 2.0.

Structs§

RedispatchModule: Engine module for the Redispatch 2.0 process family.