sps_skel/doc/E-Planung_Bruecke.md

Brücke Layout ↔ E-Planung über *_positionsdraw.json

Stand 2026-10-10. Erst Machbarkeitsprüfung, inzwischen umgesetzt als lib/e_planning.py (Regeln cfg/e_planning.ini, Aufruf bin/e_planning.bat, scl_skeleton --eplan); Bedienung in doc/Python_Scripts.md §5c, Stand der Umsetzung unten.

Problem

Das Kapitel "Daten" in doc/Klassenhierarchie.md zeigt: das Hardwarelayout (CSV) liefert die Struktur (welche TROs, welche Separatoren/Weichen, wer mit wem), die E-Planung die Namen und Adressen (BG…, MB…, MA…, FC…). Die EA-Liste allein kennt aber keine Topologie. Es fehlt die Zuordnung Layout-Bauteil (CSV-TeileId) → Betriebsmittelkennzeichen (BMK).

Idee

Die E-Planung wird als Layer über der Hardwareplanung gezeichnet: Sensor- und Aktorsymbole liegen in der Zeichnung neben dem Bauteil, zu dem sie gehören. Das Kabellängen-Tool (C:\10-Develop\gitrepos\kabellaengen, lib/getpositions.py) schreibt diese Symbole mit Position und Attributen nach <zeichnung>_positionsdraw.json. Damit ist die Brücke eine räumliche Zuordnung: E-Symbol → nächstes Layout-Bauteil passender Art.

Datenquelle *_positionsdraw.json

Schlüssel	Inhalt	Nutzen für sps_skel
sensors	je BMK (BG0642@UNKNOWN): pos [x, y], VERW (Verwendung), BEZEICHNUNG (Klartext), BESCHR, ARTINR, KENNZEICHNUNG (=A1+UH01-KF107)	Hauptquelle: Sensoren/Ventile/Motoren im Feld
schaltschrank_elemente	Elemente im Schrank (Motorschutz FC…, Taster, Leuchten, QA…) mit VERW, BEZEICHNUNG, KENNZEICHNUNG, ohne Feldposition	Motorschutz ↔ Motor, Bedienelemente
mappings	Steuerung → Liste ihrer BMK (UH01: [...])	Steuerungsaufteilung, Nummernkreis
racks, distributors, tunnels	Kabeltrassen, Verteiler	für sps_skel ohne Belang
double_ids, warnings	doppelte BMK, fehlende Attribute	Qualitätsprüfung der E-Daten

Die Erdungs-Beispiele (PR500501_…_Erdung_…, ST500652_…) enthalten nur Potentialausgleich (POT…) und taugen nicht für die Brücke. Brauchbar sind Dateien mit BG/MB/MA: Mubea_positionsdraw.json (157 Feld-BMK), ST500592_ILS_positionsdraw.json (~3100), ST500592_10_5-10_Omniflo_… (~900), ST-Fortna_positions_.json (mit 38 Scannern BX).

Test an Mubea

Eingaben: data/mubea.csv (Layout, 38 Separatoren) und kabellaengen/work/Mubea_positionsdraw.json (E-Planung). Die Zahlen in diesem Abschnitt stammen aus der ersten Untersuchung (Umkreis 700 mm, ohne Regeln); das Ergebnis der Umsetzung steht unten.

1. Lagebezug

Die Ermittlung aus lib/dxf_registration.py (derive_transform) funktioniert unverändert, wenn man die E-Symbole mit VERW SEP/IN SEP als Rolle "Separator" einsetzt:

mubea.csv <- Mubea_positionsdraw.json:  dx +50613.6 mm, dy +8555.8 mm, Drehung 0
                                        26/38 Separatoren im Toleranzband

Das entspricht dem schon gespeicherten Bezug mubea.csv|500573_60_1.dxf (dx +50833.7, dy +8414.5) bis auf ~250 mm: die E-Zeichnung liegt im selben Koordinatensystem wie die Layoutzeichnung. Zum Prüfen genügt also der bestehende Mechanismus; als Schlüssel in cfg/dxf_registration.json kann <csv>|<positionsdraw.json> dienen.

2. Was sich zuordnen lässt

E-Symbol (VERW)	Layout-Partner	Abstand	Ergebnis
IN SEP (BG, Sensor im Separator)	Separator	0–1 mm im Pin-Speicher (20/20), sonst 200–500 mm	Anker: das Symbol sitzt auf dem Separator
SEP (MB, Stopperventil)	Separator	konstant ~270 mm daneben	eindeutig über Nummernregel (unten), nicht über Abstand
AE ABZWEIG (MB, Ausschleusventil)	Ausschleuselement	konstant 1414 mm (20/20, Versatz (−1405, −159))	eindeutig, wenn der Versatz je Symbolart bekannt ist
STAU_REF-LT (BG, Stausensor)	Ausschleuselement	konstant 1391 mm (20/20)	wie oben
ABZWEIG-K104 (MB, Weiche)	Weiche	783 mm	eindeutig (nur eine Weiche)
BANDBRUCH, KETTENBRUCH, ÜBERGABE/ÜBERNAHME, SYNC P1..4, ZAPPLER	Kreisel/Strecke/Station	uneinheitlich, teils > 50 m (Symbol an Konvejoren außerhalb des CSV-Ausschnitts)	nicht über Abstand, nur über BEZEICHNUNG

Nebeneinander liegende Separatoren (Pin-Speicher, Raster 800 mm) machen den Abstand allein mehrdeutig: das MB von Strecke n liegt 270 mm von Separator n und 530 mm von Separator n+1. Eindeutig wird es erst mit der Nummernregel.

3. Nummernregel der E-Planung

Ventil = Sensor + 1, gleiche Funktionsgruppe:

Paar	Treffer (von 58 MB)
MB(n) SEP ↔ BG(n−1) IN SEP (z. B. BG0642 / MB0643)	31
MB(n) AE ABZWEIG ↔ BG(n−1) STAU_REF-LT (z. B. BG0542 / MB0543)	21
sonstige Paare (VEREINZ(CP), STOPPER (CP), AE ABZW.)	3
ohne BG-Partner	3

Damit reicht es, den Sensor räumlich zuzuordnen (der IN SEP liegt auf dem Separator); das Ventil folgt aus der Nummer. Die SCL-Referenzen zeigen dasselbe Muster (stSenInSep := …["cInBG3242"], xOutStopper1 => "MB3242") — dort sogar mit gleicher Nummer; die Regel ist also projektabhängig und gehört in eine Konfiguration, nicht in den Code.

Gleiches gilt für Motor ↔ Motorschutz: MA0200 "PIN CONVEYOR#100" ↔ FC0200 "MOTORSCHUTZ CONVEYER #100" (gleiche Nummer, schaltschrank_elemente), wie in der SCL xOutVarioMotor => "MA0145", xInMotorProtection := "FC0145".

4. Was nicht passt

12 von 38 Layout-Separatoren (vor allem an den Kreiseln K0102/K0104/K0105) haben im Umkreis von 700 mm kein IN SEP/SEP; umgekehrt liegen mehrere IN SEP des Kreisels K0102 neben Aus-/Einschleuselementen statt neben einem Separator. Vermutlich ist die CSV (aus 500573_60_1.dxf) ein anderer Planungsstand als die E-Zeichnung Mubea.dxf des Kabellängen-Tools, oder Kreisel-Separatoren sind im CSV anders modelliert. Das muss mit zueinander passenden Ständen geprüft werden, bevor man eine Quote angibt.

Mubea_positionsdraw.json enthält keine Scanner (BX). Für Scanner-Zuordnung ist ein anderes Projekt nötig (ST-Fortna_positions_.json, ILS-Baugruppe).

Was die Brücke für das Kapitel "Daten" liefert

SCL-Datum	aus positionsdraw.json	Regel
stInSeparator<n>.stSenInSep	BG mit VERW IN SEP	räumlich am Separator (Anker)
xOutStopper<n>	MB mit VERW SEP	Nummernregel ab dem BG
stInSenJam<n>, Settings.xPluggedJam	BG STAU_REF-LT	räumlich, Versatz je Symbolart; vorhanden ⇒ xPluggedJam := TRUE
xOutSw<n>ExTo3/4	MB AE ABZWEIG / Weichen-MB	Nummernregel ab dem Stausensor bzw. räumlich an Weiche/Ausschleuselement
Settings.xPluggedPart, stSenPart	BG BT BELADEN	räumlich; vorhanden ⇒ TRUE
xInMotorProtection, xOutVarioMotor	MA im Feld + FC in schaltschrank_elemente	gleiche Nummer
xInCarouselRun (welcher Antrieb)	FC/MA-BEZEICHNUNG "KREISEL-K0102", "CONVEYOR #100"	Textabgleich mit dem Host-Kreisel des TRO
Steuerung, TRO-Nummernkreis, stInOutMachineState	KENNZEICHNUNG =A1+UH01-KF107, mappings	UH01 = Steuerung, KF107 = E/A-Station
Plausibilisierung	BEZEICHNUNG "SEPARATOR STR. 14", "KR-K0102 VOR BT-BELADUNG"	Strecken-/Kreiselnummer gegen Layout prüfen

Nicht aus dieser Quelle: Not-Halt-Kreis (xInSftyOk), Taster für Automatik/Quittieren (stehen nur als Schrankelemente ohne Bezug zum TRO), Scanner-Hardwarekennungen, Weichenbauart (xNewSwitch).

Umsetzung (Stand 2026-10-10)

1. lib/e_planning.py: liest *_positionsdraw.json in EDevice (BMK, VERW, Bezeichnung, Kennzeichnung → Steuerung/E/A-Station, Position).
2. Lagebezug über dxf_registration.derive_transform mit den IN SEP-Sensoren als Rolle "Separator"; abgelegt in cfg/dxf_registration.json unter <csv>|<positionsdraw.json>.
3. Regeln in cfg/e_planning.ini (projektabhängig): je Rolle Layout-Art, VERW, Höchstabstand, Sollabstand (für die konstanten Versätze von Stausensor und Ausschleusventil — sonst gewinnt bei 0080/0084 ein näherer, fremder Stausensor des Kreisels K0102) und die Nummernregel (MB = BG + 1).
4. Ausgabe <csv>_eplan.json (EplanDocument) und Bericht <csv>_eplan.md. scl_skeleton --eplan setzt Separator-Sensor und Stopperventil ein (SclName.todo = False); alles andere bleibt TODO(E-Planung).

Ergebnis Mubea mit den ausgelieferten Regeln: Separator-Sensor 21/38, Stopper 22/38, Stausensor 20/23, Ausschleusventil 20/23, Weichenventil 1/1. Den Separator-Sensor nimmt die Regel nur bis 300 mm; die Kreisel-Fälle mit 470–540 mm (z. B. BG0532 an 0044) bleiben bewusst offen.

Offen:

• Stausensoren und Ausschleus-/Weichenventile stehen in JSON und Bericht, kommen aber noch nicht in die SCL: die TRO-JSON sagt nicht, welches Ausschleuselement bzw. welche Weiche zu welchem TRO-Ausgang gehört.
• Die Lagerlinien eines PinStore-TRO (arInSep[n]) sind zugeordnet, der Generator erzeugt die Linienparameter aber noch nicht.
• Scanner (BX) fehlen in den Mubea-Daten; Regel und Test mit ST-Fortna_positions_.json stehen aus.
• Ein Abgleich mit passenden Ständen von CSV und E-Zeichnung für die Kreisel.