Doku und erster Vorschlag aus dem Fortna Extrakt dazu

doc/HundM/BricsCAD_TRO_Symbol.md

@@ -0,0 +1,105 @@
+# BricsCAD-Symboldefinition — TRO-Block
+
+## Zweck
+
+Dieses Dokument beschreibt ein BricsCAD-Blocksymbol ("TRO-Symbol"), das im Layoutplan der Förderanlage platziert wird und dessen Attribute per DXF/Skript-Export in ein TRO-Objekt der [JSON-Layout-Konfiguration](Json_Layout-Konzept.md) überführt werden können (Abschnitt "4. TROs").
+
+Das Symbol bildet **nur die Daten ab, die sich pro physischer Instanz unterscheiden und nicht aus Nachbarschaft/Zeichnung oder aus dem Typ ableitbar sind**. Timing-Werte (`trailingTime`, `handlingTime`, `senFree`, `senWait`, `jamTime`, ...) werden bewusst **nicht** am Symbol gepflegt, sondern beim JSON-Export aus einer Default-Tabelle pro `TRO_TYPE` gezogen (siehe [Kapitel "Defaults je Typ"](#defaults-je-typ-timing)). Für Sonderfälle steht ein optionales Override-Attribut zur Verfügung.
+
+Ebenfalls nicht am Symbol gepflegt: **Position/Rotation** (kommt aus der Blockeinfügung) und **Connections/JamAreas** (`entry`/`exit`, kommen aus der grafischen Topologie — welche Verbindungslinie an welchem Anschlusspunkt des Symbols endet).
+
+---
+
+## Attributliste (ATTDEF)
+
+### Gruppe 1 — Kern / Identifikation (Pflicht, bei jedem Typ)
+
+| Tag | Prompt (DE) | Beispielwert | Default | Typ | Bemerkung |
+|---|---|---|---|---|---|
+| `TRO_ID` | TRO-ID | `TRO107` | — | Text | Eindeutig; Basis für `mainTroNo` (`cMainTro107`), `separator.no` (`cSep107.1`), `hmi`-Pfad |
+| `TRO_TYPE` | TRO-Typ | `1Sep1Swi` | — | Liste (Enum) | Steuert `fbType` + Timing-Defaults; siehe [TRO-Typen-Tabelle](TRO_Typen.md) |
+| `CONTROL_UNIT` | Steuerkreis | `OF1` | `OF1` | Liste (Enum) | Sicherheitszone/Schaltschrank |
+| `COMMENT` | Bezeichnung | `Weiche Boom 1` | — | Text | Klartext für Doku, HMI, SCL-Kommentar |
+
+### Gruppe 2 — Hardware-IO (Pflicht, nicht ableitbar)
+
+| Tag | Prompt (DE) | Beispielwert | Default | Typ | Bemerkung |
+|---|---|---|---|---|---|
+| `SENSOR_IN_SEP` | Sensor Separator | `BG3306` | — | Text | Hauptsensor, ergibt `sensorInSep` + `cIn`-Konstante |
+| `SENSOR_JAM2` | Sensor Jam 2 | `BG3305` | *(leer)* | Text, optional | zweiter Stau-/Kontrollsensor |
+| `SENSOR_JAM3` | Sensor Jam 3 | `BG3330` | *(leer)* | Text, optional | nur bei Switch-Typen mit 3. Sensor |
+| `STOPPER_OUTPUT` | Ausgang Stopper | `MB3306` | — | Text | Stopper-/Vereinzelungs-Ausgang |
+| `SWITCH_OUTPUT` | Ausgang Weiche | `MB3304` | *(leer)* | Text | nur bei `1Sep1Swi` / `1Sep2Swi` sichtbar/Pflicht |
+
+### Gruppe 3 — Scanner (optional, blendet sich nur bei Bedarf ein)
+
+| Tag | Prompt (DE) | Beispielwert | Default | Typ | Bemerkung |
+|---|---|---|---|---|---|
+| `SCANNER_ID` | Scanner-ID | `BX1104` | *(leer)* | Text, optional | Cognex-Barcodeleser-Kennung |
+| `HAS_SSCC_SCANNER` | SSCC-Scanner? | `false` | `false` | Bool (Liste `true`/`false`) | schaltet `ssccScanner`- und `wcsTelegram`-Block im Export frei |
+
+### Gruppe 4 — Priorität / Verhalten
+
+| Tag | Prompt (DE) | Beispielwert | Default | Typ | Bemerkung |
+|---|---|---|---|---|---|
+| `PRIORITY_TYPE` | Prioritätsart | `releaseOk` | `releaseOk` | Liste (Enum: `releaseOk`, `Manager`, `Dir2Manager`) | steuert `priority`-Block im JSON |
+| `IS_BORNER` | Einschleusepunkt? | `false` | `false` | Bool | markiert Borner-TROs (Direction-Zuweisung an dieser Stelle) |
+| `N_TO_1_DESTINATIONS` | Anzahl Weichenziele | `3` | *(leer)* | Ganzzahl, optional | nur bei Switch-Typen |
+
+### Gruppe 5 — Override (Ausnahmefälle, i. d. R. leer)
+
+| Tag | Prompt (DE) | Beispielwert | Default | Typ | Bemerkung |
+|---|---|---|---|---|---|
+| `OVERRIDE_TIMING_JSON` | Timing-Override (JSON) | *(leer)* | *(leer)* | Text, optional | Freitext-JSON-Fragment, überschreibt einzelne Default-Timings dieser Instanz (z. B. `{"trailingTime":"T#100ms"}`) |
+| `CUSTOM_CODE_REF` | Sonderlogik-Referenz | *(leer)* | *(leer)* | Text, optional | Verweis auf ein `customCode`-Snippet, das der Export separat einbindet (siehe Json-Konzept Abschnitt 10) |
+
+---
+
+## Sichtbarkeits-/Pflichtregeln beim Attribut-Dialog
+
+| Regel | Bedingung |
+|---|---|
+| `SWITCH_OUTPUT`, `N_TO_1_DESTINATIONS` nur sichtbar/Pflicht | `TRO_TYPE` ∈ {`1Sep1Swi`, `1Sep2Swi`} |
+| `SENSOR_JAM3` nur sichtbar | `TRO_TYPE` ∈ {`1Sep1Swi`, `1Sep2Swi`} |
+| `SCANNER_ID` Pflicht | `TRO_TYPE` = `1Sep_SSCC` oder Scanner-Kommentar in `COMMENT` |
+| `HAS_SSCC_SCANNER` nur `true` möglich | `TRO_TYPE` = `1Sep_SSCC` |
+| `PRIORITY_TYPE` = `Dir2Manager` nur zulässig | `TRO_TYPE` = `1Sep1Swi` |
+
+Diese Regeln werden nicht durch BricsCAD selbst erzwungen (ATTDEF kennt keine bedingte Sichtbarkeit), sondern im Export-Skript (Validierung) und optional per Dynamic-Block-Sichtbarkeitszuständen je `TRO_TYPE`-Variante.
+
+---
+
+## Empfohlener Blockaufbau
+
+- **1 Basis-Blockdefinition** `SYM_TRO` mit allen Attributen aus Gruppe 1–5 (leere Defaults für optionale Gruppen).
+- **Anschlusspunkte** als benannte Punkte/Layer im Block (`PT_ENTRY`, `PT_EXIT`, `PT_EXIT2`, `PT_EXIT3`) — dienen dem Export-Skript zur automatischen Ableitung der `connections[]`-Einträge aus angeschlossenen Linien, ersetzen die früher diskutierten Attribute für `entry`/`exit`.
+- **Grafik** je `TRO_TYPE` unterschiedlich einfärben/formen (z. B. über Dynamic-Block-Sichtbarkeitszustand), damit der Plan auf einen Blick den Typ zeigt — analog zu den `classDef`-Farben im Mermaid-Diagramm in Json_Layout-Konzept.md (`sep`, `swi`, `buf`, `vario`, `sscc`).
+
+---
+
+## Defaults je Typ (Timing)
+
+Die Timing-Defaults werden **nicht** am Symbol gepflegt, sondern zentral im Export-Skript als Lookup-Tabelle `TRO_TYPE → Timing-Defaults` hinterlegt (z. B. aus den in Json_Layout-Konzept.md Abschnitt 4 beobachteten Werten: `1Sep` → `trailingTime=T#600ms, handlingTime=T#200ms`, `1Sep1Swi` → `trailingTime=T#100ms, handlingTime=T#50ms`, `Vario` → `trailingTime=T#800ms, handlingTime=T#300ms`, usw.). Die vollständige, typspezifische Default-Tabelle inkl. aller in dieser Anlage tatsächlich vorkommenden Typen steht in [TRO_Typen.md](TRO_Typen.md).
+
+## Beispiel: Attributsatz für TRO107 (Switch Boom 1)
+
+```
+TRO_ID                 = TRO107
+TRO_TYPE                = 1Sep1Swi
+CONTROL_UNIT             = OF1
+COMMENT                  = Weiche Boom 1 (LS / Clearing)
+SENSOR_IN_SEP            = BG3306
+SENSOR_JAM2              = BG3305
+SENSOR_JAM3              = BG3330
+STOPPER_OUTPUT           = MB3306
+SWITCH_OUTPUT            = MB3304
+SCANNER_ID               = (leer)
+HAS_SSCC_SCANNER         = false
+PRIORITY_TYPE            = Dir2Manager
+IS_BORNER                = false
+N_TO_1_DESTINATIONS      = 3
+OVERRIDE_TIMING_JSON     = (leer)
+CUSTOM_CODE_REF          = (leer)
+```
+
+Der Export-Generator ergänzt daraus automatisch `mainTroNo=cMainTro107`, `separator.no=cSep107.1`, `hmi=DB_Interface_HMI.stTRO.TRO107`, die Timing-Werte aus der Default-Tabelle für `1Sep1Swi`, sowie `jamAreas.entry/exit2/exit3` aus den an `PT_ENTRY`/`PT_EXIT2`/`PT_EXIT3` angeschlossenen Verbindungslinien.

doc/HundM/EA-Listen-Analyse.md

@@ -0,0 +1,141 @@
+# Analyse der Ein-/Ausgabelisten (data/Eingaben)
+
+## Kontext
+
+In `data/Eingaben/` liegen je Steuerung (ILS-1 bis ILS-5, entspricht UH01-UH05) drei Excel-Dateien mit denselben E/A-Punkten in drei Sichten:
+
+| Datei | Inhalt |
+| --- | --- |
+| `..._EA.xlsx` | Rohliste: Adresse (`E000.0`), Kommentar, Zeilenreferenz (Schaltplan) |
+| `..._TIA.xlsx` | Import-Liste fuers TIA Portal: Blatt "PLC Tags" (BMK-Name, `Data Type`, `%E`/`%A`-Logikadresse, Kommentar, HMI-Flags) + Blatt "Constants" (`cIn<Name>`-Indexkonstanten) |
+| `..._WSCAD.xlsx` | Import-Liste fuers WSCAD (E-CAD): Anschluss, Kommentar, **Bezug** (Ortskennzeichen, z.B. `=A01+UC2101-KF1DI1`) |
+
+Alle Signale sind **Bool** (reine Digital-E/A-Listen). Analogwerte (Tilt-/Distanzsensoren), PROFINET-Geraete (Cognex-Scanner BX, RFID) und Antriebsparameter sind **nicht** enthalten — diese werden anderweitig projektiert.
+
+Umfang: ILS-1 (UH01) 443 Tags, ILS-2 (UH02) 1578 Tags, ILS-3 (UH03) 1608 Tags, ILS-4 (UH04) 203 Tags, ILS-5 (UH05) 243 Tags.
+
+## Namenspraefixe (BMK-Schema)
+
+| Praefix | Bedeutung | Beispiel |
+| --- | --- | --- |
+| `BG` | Sensor / Geber (Eingang) | `BG0280`: in Separator LS1 |
+| `SF` | Schalter / Taster / Sicherheitssignal (Eingang) | `SF0025`: Schluesselschalter LS1 |
+| `DI` | Diagnose-/Feedback-Eingang (Sicherung, Schuetz) | `DI0011`: Feedback Hauptschuetze aktiv |
+| `BP` | Druckschalter | `BP0004`: Druckschalter Druckluft OK |
+| `MB` | Ausgang Separator-/Stopper-Ventil | `MB0280`: Separator LS1 |
+| `MA` | Ausgang Motor (Contactor) | `MA0060`: Motor (ILS-KR-M0101) |
+| `QA` | Ausgang Motor / Hauptschuetz | `QA0071`: Motor 1 Ausfahren LS1 |
+| `DQ` | Digitalausgang Sonderfunktion (Fuss, RFID-Handshake) | `DQ0322`: Stuetzfuss aufwaerts LS1 |
+| `FC` | Motorschutz-Feedback | `FC0060`: MSS ausgeloest (ILS-KR-M0101) |
+| `PF` | Leuchtmelder / Signalsaeule | `PF0022`: Signalsaeule gruen "Betriebsbereit" |
+
+## Was daraus automatisch fuers JSON gewinnbar ist
+
+### Vollstaendig generierbar
+
+| JSON-Abschnitt / Zielbaustein | Quelle |
+| --- | --- |
+| `sensors[]` -> `FB_CallSensors`, Dimensionierung `DB_Inputs` | TIA "PLC Tags" (alle BG-Tags: id, hwInput, Kommentar) + "Constants" (`cInBG...` ist exakt der Sensor-Array-Index) |
+| Konstanten-Tabelle (TIA-Konstantenliste) | Constants-Blatt 1:1 |
+| PLC-Variablentabellen (Ordner `PLC-Variablen/Mewa`) | "PLC Tags" — das ist der eigentliche Importzweck der Datei |
+| `outputs`-Felder der TROs/Conveyors/LoadingBooms | MB (Stopper/Separatorventile), MA/QA/DQ (Motoren), FC (Motorschutz), PF (Leuchtmelder) |
+
+### Teilweise generierbar — ueber Kommentar-Parsing
+
+Die Kommentare folgen einem erstaunlich systematischen Muster:
+
+```text
+<Funktionsrolle> [<lfd.Nr.>] (<Einheit>) <Bereich>
+```
+
+Beispiele: `in Separator 1 (ILS-CV M5003) WS1.1`, `AE Abzweig Str.3 (Block 1.1.1)`, `Pin Abfrage (KR-M1101) Block 1.1.1`.
+
+Daraus laesst sich je Foerdertechnik-Einheit (M-Nummer) ein **TRO-/Conveyor-Geruest** ableiten:
+
+- `sensorInSep` aus "in Separator n", Stopper-Output aus "Separator n", `sensorJam*` aus "Stausensor"/"Staumelder Einfahrt"
+- Der **FB-Typ** ist heuristisch bestimmbar:
+  - "AE Abzweig" -> Weiche (`1SepNSwi`)
+  - "Mitnehmerfinger in Position" / "Foerderer voll" / "MT in Position" -> `Vario`
+  - "Pin Abfrage" / "Pruefung MT Pos.x" -> `PinStore`
+  - mehrere "Str.1"..."Str.8" unter einem Block -> mehrzeiliger Puffer/Block
+  - Anzahl der "in Separator n" (1 vs. 2) -> 1Sep vs. 2Sep
+- `conveyors[]`-Grundgeruest: FC/MA-Paare je `KR-M...`/`CV-M...` -> `motorProtectName` + `powerContactor`
+
+Die M-Nummern tauchen unveraendert auch im SCL-Code auf (Beleg: `REGION Carousel KR-M5002` in UH05/FB_Main.scl, `TRO208 : "FB_ILS_MTRO_PinStore_Auto"; // Block 1.1.1` in UH02/FB_Main.scl) — die Zuordnung Liste <-> Code ist also nicht nur Vermutung, sondern nachweisbar identisch.
+
+### Nicht gewinnbar
+
+- Timing-Parameter (`trailingTime`, `handlingTime`, `senFree`/`senWait` etc.)
+- Priority-Manager-Verdrahtung, Release-Ausdruecke
+- `customCode`-Bloecke
+- Scanner-Zuordnung (Cognex BX-Geraete sind PROFINET-Teilnehmer, nicht in den Digital-E/A-Listen)
+- Vor allem die **Topologie**: `connections[]`, `jamAreas[]`, `routing`/`destinations[]`. Die Reihenfolge der M-Nummern liefert nur einen schwachen Hinweis auf Nachbarschaft, keine belastbare Verkettung.
+
+## Hoehere Ebenen in den Listen
+
+Die Listen enthalten eine durchgaengige **Anlagenhierarchie**, die im aktuellen JSON-Konzept noch nicht abgebildet ist:
+
+1. **Signal** — BG/MB/MA/FC/PF/SF/QA/DQ (unterste Ebene)
+2. **Foerdertechnik-Einheit = M-Nummer** — `KR-M5002` (Kreisel), `CV-M5003` (Foerderer), `KR-K1101` (Kreisel-Einfahrt). Entspricht 1:1 einem Conveyor bzw. einer TRO-Instanz.
+3. **Bereichs-/Funktionsgruppen = Gruppen von TROs**:
+   - **Block x.y.z** — PinStore-Bloecke, z.B. UH02: Block 1.1.1 – 1.3.4 (3 Gassen x 4 Ebenen = 12 Bloecke), deckungsgleich mit den Datenbausteinen `DB_Storage1.1.1` ... `DB_Storage1.3.4`; darunter je Block bis zu 8 Gassen ("Str.1"..."Str.8")
+   - **LS 1 / LS 2** — Ladeschleifen in UH01 (Boom-, Fuss-, Rad-Signale)
+   - **WS x.y** — Work Stations in UH04/UH05 (manuelle Arbeitsplaetze)
+   - **UZ0x0y** — Umzaeunungs-/Sicherheitszonen (Reset-/Freigabe-Taster je Zone) -> entspricht den `controlUnits` im JSON-Konzept
+4. **Elektro-Topologie** (nur in den WSCAD-Listen, ueber das Feld "Bezug") — UC-Feldstationen mit Klemmenkarten (`KF1DI1`, `KF1FDQ2` = fehlersichere Karte, 8 oder 16 Kanaele). Die UC-Nummerierung spiegelt die logischen Bereiche: UH02 nutzt z.B. `UC21xx`/`UC22xx`/`UC23xx` fuer die drei PinStore-Bloecke 2.1/2.2/2.3; F-Karten markieren zugleich die Safety-relevanten Signale.
+5. **Steuerung UH0x** — je Dateitripel eine SPS-Konfiguration, entspricht dem `plc`-Abschnitt im JSON.
+
+## Verwendung von Positionen
+
+Zusaetzlich zu den Excel-Listen liegen in `data/Eingaben/` vier JSON-Dateien mit Positions- und Verkabelungsdaten, offenbar Exporte eines WSCAD/CAD-Auswertungstools:
+
+| Datei | Inhalt |
+| --- | --- |
+| `ST500592_10_5-9_ILS_positions.json` | Positionen (x/y in mm) aller Sensoren/Aktoren, Schaltschrankelemente und Verteiler des ILS-Systems (UH01–UH05) |
+| `ST500592_10_5-9_ILS_todraw.json` | Kabelverbindungen (Verteiler ↔ Signal) mit Routing-Polylinie und -laenge, Kabeltrassen (`rack_geometry`), Fehlerprotokolle |
+| `ST500592_Omniflo_positionsdraw.json` / `ST500592_10_5-10_Omniflo_todraw.json` | Gleiches Schema, aber fuer ein weiteres System ("Omniflo", `SPS` 6/7 = UH06/UH07) — **keine** SCL-Konfiguration dazu im Repository, also vermutlich eine benachbarte/zukuenftige Anlage ausserhalb des aktuellen Scopes |
+
+### Struktur
+
+- **`sensors`** / **`schaltschrank_elemente`**: Dict, Schluessel `<BMK>@<SPS>` (z.B. `BG3260@4`), da BMK-Namen ueber die SPSen hinweg wiederverwendet werden. Werte enthalten u.a. `pos` (x,y in mm), `BEZEICHNUNG` (Kommentartext, identisch zur TIA/EA-Liste), `KENNZEICHNUNG` (WSCAD-Ortskennzeichen), `SPS` und **`VERW`**.
+- **`VERW`** ist ein kontrolliertes Vokabular fuer die Funktionsrolle des Signals, z.B. `Sep`, `In sep`, `Jam detector`, `ES branch` (Weichen-Abzweig!), `conveyor full`, `MT in Position`, `Finger in position`, `PIN query`, `Sync P1`–`P4`. Das ist eine **zuverlaessigere Quelle fuer die Rollenklassifikation** als das Parsen der freien Kommentartexte (siehe oben) — z.B. laesst sich eine Weiche (`ES branch`) oder ein Vario-Sync-Punkt (`Sync Px`) direkt am `VERW`-Wert erkennen statt ueber Text-Heuristik.
+- **`mappings`**: Verteiler (`UC0401`, ...) -> Liste der daran angeschlossenen BMK — das ist die **belastbare** (aus der Verkabelung stammende) Zuordnung Signal -> Schaltschrank, nicht nur eine Namenskonvention wie in der WSCAD-Excelliste.
+- **`distributors`**: Verteiler -> eigene Position (x,y).
+- **`kabel`** (nur `_todraw.json`): je Verbindung `id` (`"<Verteiler>-<BMK>@<SPS>"`), Routing-Polylinie (`coords`) und `length` (mm) — die tatsaechliche Kabelstrecke inkl. Verlegung ueber Kabeltrassen/Pritschen.
+- **`rack_geometry`** / **`tunnels`**: Geometrie der Kabeltrassen bzw. Bodentunnel, auf denen die Kabel gefuehrt werden.
+- **`not_found`** / `errors_*` / `warnings`: Validierungsprotokoll des Exporttools (fehlende Verteilerzuordnung, ungueltige Kennzeichnung, doppelte IDs, Attributsluecken) — kein Topologie-Input, aber wertvoll als **Datenqualitaets-Check** fuer einen Generator.
+
+### Lassen sich Topologie-Hinweise ableiten?
+
+Ein Abgleich der bekannten UH01-Kette (siehe [TRO_Graph_UH01-UH05.dot](TRO_Graph_UH01-UH05.dot)) gegen die Sensor-Positionen zeigt ein klares Muster:
+
+| TRO | Sensor | Position (x, y in mm) | Abstand zum vorherigen |
+| --- | --- | --- | --- |
+| TRO100 | BG3242@1 | (341906, 164862) | – |
+| TRO103 | BG3271@1 | (331115, 163051) | ~10,9 m |
+| TRO107 | BG3306@1 | (333164, 152428) | ~10,7 m (nach TRO105) |
+| TRO104 | BG0280@1 | (370801, 187134) | ~46,4 m (Sprung!) |
+| TRO105 | BG3280@1 | (334141, 159162) | ~46,1 m (Sprung zurueck!) |
+| TRO109 | BG0340@1 | (376774, 187155) | liegt nahe bei TRO104 |
+
+Die TROs des Hauptkreislaufs (100, 103, 105, 107, ...) liegen raeumlich dicht beieinander (Abstaende im Bereich 5–15 m), waehrend TRO104/TRO109 (Vorstopper vor den Ladeschleifen LS1/LS2) einen grossen sprunghaften Abstand aufweisen — sie liegen physisch bei den Ladeschleifen, einem raeumlich getrennten Anlagenteil, zu dem die Carrier ausgeschleust und zurueckgefuehrt werden. Das deckt sich exakt mit der bereits aus dem SCL-Code extrahierten Topologie (TRO104 -> LoadingBoom1 -> TRO105).
+
+**Ergebnis:** Positionen liefern **keine eigenstaendige, vollstaendige Topologie** (dafuer fehlt die Information, in welcher Reihenfolge/Richtung Carrier durch nahe beieinanderliegende Elemente laufen — u.a. bei parallelen Foerderstrecken oder Bloecken mit identischen Abstaenden nicht eindeutig). Sie eignen sich aber sehr gut als:
+
+1. **Validierungswerkzeug** fuer die aus dem SCL-Code extrahierte `connections`-Topologie: kurze Abstaende zwischen verbundenen TROs bestaetigen Plausibilitaet, groessere Spruenge markieren bewusste Anlagenteile (Ladeschleifen, Storage-Gassen, AMR-Uebergabe) und lassen sich in der Analyse gezielt kommentieren.
+2. **Raeumliche Clusterbildung**: TROs/Sensoren, die im selben Cluster von Koordinaten liegen, lassen sich automatisch zu den bereits identifizierten Bereichsgruppen (Block, LS, WS, UZ) buendeln oder solche Gruppen erst entdecken, falls die textuelle Kommentar-Zuordnung fehlt oder uneinheitlich ist.
+3. **Massstabsgetreue Lageplan-Darstellung**: der bestehende TRO-Graph ([TRO_Graph_UH01-UH05.svg](TRO_Graph_UH01-UH05.svg)) nutzt eine automatische Graphviz-Anordnung ohne Bezug zur echten Anlage. Mit den `pos`-Koordinaten liesse sich zusaetzlich ein **massstabsgetreuer Lageplan** rendern (SVG/DXF mit echten x/y-Koordinaten je TRO/Sensor), der die abstrakte Topologie mit der realen Hallenlayout ueberlagert.
+4. **Cabinet-/Verteilerzuordnung**: `mappings` + `distributors` liefern die **tatsaechliche** (aus der Verkabelung stammende) Zuordnung Sensor -> Schaltschrank/Verteiler samt dessen Position — praeziser als die Namenskonvention der WSCAD-Bezugsfelder, und direkt nutzbar fuer den `controlUnits`-Abschnitt im JSON.
+5. **Kabel-/Trassendokumentation**: `kabel`, `rack_geometry` und `tunnels` erlauben es, Kabellaengen und -wege je Verbindung automatisch zu dokumentieren (z.B. fuer Stuecklisten/BOM oder Trassenauslastung) — fachlich getrennt von der SPS-Programmlogik, aber ein sinnvoller Zusatznutzen derselben Datenbasis.
+
+## Konsequenz fuer das JSON-Layout-Konzept
+
+Um Ebene 2–4 aus den Excel-Listen automatisch befuellen zu koennen, sollte das JSON-Schema (siehe [Json_Layout-Konzept.md](Json_Layout-Konzept.md)) um folgende Punkte erweitert werden:
+
+1. Ein Feld `unit` bzw. `mNumber` an jedem TRO/Conveyor als expliziter Schluessel zur E/A-Liste (z.B. `"unit": "M5003"`).
+2. Eine neue Gruppierungsebene `areas`/`groups` (Block, LS, WS, UZ, UC-Station), die TROs/Conveyors buendelt und mit dem "Bezug"-Feld der WSCAD-Liste sowie der UZ-Nummerierung der TIA-Liste verknuepft.
+3. Ein optionales Feld `pos: {x, y}` je Sensor/TRO/Conveyor (aus den `..._positions.json`), fuer massstabsgetreue Layout-Darstellung und als Validierungsdatum fuer die Topologie.
+4. Ein Feld `controlUnit`/`cabinet` mit dem Verteiler-BMK (aus `mappings`), zusaetzlich zur bzw. anstelle der bisherigen Ableitung aus der WSCAD-Namenskonvention.
+5. Nutzung des `VERW`-Vokabulars aus den Positions-JSONs als primaere Quelle fuer die Rollenklassifikation der BG/MB-Signale (statt bzw. ergaenzend zur Kommentar-Textheuristik) — reduziert Fehlklassifikationen bei uneindeutigen Kommentaren.
+
+Damit waeren die Ebenen Signal, Foerdertechnik-Einheit, Bereichsgruppe, Steuerung und — als Zusatznutzen — die raeumliche Lage vollstaendig aus den Eingabelisten ableitbar. Manuell zu pflegen blieben dann nur noch die eigentliche Verkettungsrichtung der Topologie (`connections`/`destinations`), Timings und projektspezifische Sonderlogik (`customCode`).

doc/HundM/SCL_Analyse_Standardisierung.md

@@ -0,0 +1,240 @@
+# SCL-Bausteinanalyse: Standardisierungspotenzial
+**Projekt:** HundM_Fortna
+**Datum:** 2026-06-23
+**Analysierte Konfigurationen:** UH01, UH02, UH03, UH04, UH05
+**Gesamt SCL-Dateien:** ~224 Baustein-Deklarationen gefunden
+
+---
+
+## Methodik
+
+- **Eingeschlossen:** Alle `.scl`-Dateien in projektspezifischen Verzeichnissen
+- **Ausgeschlossen (bereits bibliothekarisiert):**
+  - `*/1_BaseSystemLib/**` (UH01, UH04, UH05)
+  - `*/2_ILSLib/**` (UH01, UH04, UH05)
+  - `*/BaseSystemLib/**` (UH02, UH03)
+  - `*/ILSLib/**` (UH02, UH03)
+  - `LGF_DTLtoString_ISO` (Siemens LGF-Standardbibliothek)
+- **Kriterium:** Baustein erscheint identisch (gleicher Name) in mehreren Konfigurationen → Duplikationspflege notwendig
+
+---
+
+## Priorität 1 — In ALLEN 5 Konfigurationen vorhanden
+
+> Diese 22 Bausteine werden in jedem SPS-Projekt kopiert und separat gepflegt.
+> **Empfehlung:** Sofort in eine gemeinsame Projektbibliothek auslagern.
+
+| Baustein | Typ | Kategorie | Pfad |
+|---|---|---|---|
+| `FB_CallSensors` | FB | Sensoren | `050_Sensors/` |
+| `FB_PreMain` | FB | Programmstruktur | `075_PreMain/` |
+| `FB_Main` | FB | Programmstruktur | `100_Main/` |
+| `FC_CARR_GLOB_CORRECTION` | FC | MFR | `200_MFR/` |
+| `FC_Direction` | FC | MFR | `200_MFR/` |
+| `FC_Int2String` | FC (→ String) | Hilfsfunktionen | `400_BasicFunctions/FC/` |
+| `FC_Jam` | FC | Stau | `400_BasicFunctions/FC/` ¹ |
+| `FC_StorageLines` | FC | Puffer | `400_BasicFunctions/FC/` ² |
+| `FC_Call_Jams` | FC | Stau | `700_Jams/` |
+| `FB_CommunicationWCSBL` | FB | Kommunikation | `900_Communications/` ³ |
+| `FB_FortnaTele_Placeholder` | FB | Kommunikation | `900_Communications/` ⁴ |
+| `FB_CommunicationLogger` | FB | Kommunikation | `900_Communications/TCP-Logger/` |
+| `FB_Visu` | FB | Visualisierung | `970_Visu/` |
+| `FB_Visu_Jam` | FB | Visualisierung | `970_Visu/` |
+| `FB_Visu_Jams` | FB | Visualisierung | `970_Visu/` |
+| `FC_CarrierManipulator` | FC | Visualisierung | `970_Visu/` |
+| `FC_BARCODE_SEARCH` | FC | Barcode | `Programmbausteine/` (Root) |
+| `FC_GET_PROFINET_DEVICE_STATES` | FC | PROFINET | `PROFINET/` |
+| `Programming error` | OB | Fehlerbehandlung | `Programmbausteine/` (Root) |
+| `FB-OPC_UA_System-Stat` | FB | SCADA | `SCADA/` |
+| `FB_PerfTest` | FB | Performance | `_PerformanceMeasurement_/` |
+| `FC_S7` | FC | IBN/Test | `_IBN/` |
+
+**Anmerkungen:**
+- ¹ UH03: Datei liegt in `700_Jams/FC_Jam.scl` statt `400_BasicFunctions/FC/`
+- ² UH03: Datei liegt in `800_Storage/FC_StorageLines.scl` statt `400_BasicFunctions/FC/`
+- ³ UH03/UH04/UH05: Unterordner `Fortna-WES-WCS/`
+- ⁴ UH04/UH05: Unterordner `Fortna-WES-WCS/Misc/`
+
+---
+
+## Priorität 2 — In 4 von 5 Konfigurationen vorhanden
+
+| Baustein | Typ | Vorhanden in | Fehlt in | Bemerkung |
+|---|---|---|---|---|
+| `FB_EventLog_StepChange` | FB | UH02, UH03, UH04, UH05 | UH01 | Neu, fehlt noch in UH01 |
+| `FB_PriorityLogic` | FB | UH01, UH03, UH04, UH05 | UH02 | UH02 hat `FB_PriorityManagement` (abweichende Logik) |
+| `FC_Get_LaneStatus` | FC (→ String) | UH01, UH03, UH04, UH05 | UH02 | UH02 verwendet andere Lane-Logik |
+
+---
+
+## Priorität 3 — In 3 Konfigurationen vorhanden
+
+| Baustein | Typ | Vorhanden in | Bemerkung |
+|---|---|---|---|
+| `FB_Visu_JamStorage` | FB | UH01, UH02, UH03 | UH04/UH05 benötigen kein Jam-Puffer-Visu? |
+
+---
+
+## Priorität 4 — In 2 Konfigurationen vorhanden
+
+### 4a) AI/Storage-Gruppe (UH02 + UH03)
+
+Diese Gruppe enthält die Lagerungs- und Umstapelintelligenz. Beide Konfigurationen pflegen identische Kopien.
+
+| Baustein | Typ |
+|---|---|
+| `FB_LineEmptyAnalyze` | FB |
+| `FB_LineLvlAnalyze` | FB |
+| `FB_RearrangeSequencer` | FB |
+| `FB_RearrangeStartCoordination` | FB |
+| `FB_StockRemovalBLKModul` | FB |
+| `FB_StockRemovalSequencerUDT` | FB |
+| `FB_StorageManagement` | FB |
+| `FB_StorageManagementCall` | FB |
+| `FB_UpdateMessage` | FB |
+
+> **Hinweis:** UH02 hat zusätzliche Varianten `_New`, `_New_EY`, `Lvl1` — diese sollten konsolidiert werden (siehe Sonderanalyse unten).
+
+### 4b) CPU-CPU-Exchange (UH02 + UH03)
+
+| Baustein | Typ | Pfad |
+|---|---|---|
+| `FB_I-Device_ReceiveCarrier` | FB | `_CPU-CPU-Exchange/` |
+| `FB_I-Device_SendCarrier` | FB | `_CPU-CPU-Exchange/` |
+
+### 4c) Visu-Erweiterungen (UH02 + UH03)
+
+| Baustein | Typ |
+|---|---|
+| `FB_Visu_AuslagernAI` | FB |
+| `FB_Visu_AuslagernList` | FB |
+| `FB_Visu_ListPinband` | FB |
+
+### 4d) Kommunikation (paarweise)
+
+| Baustein | Typ | Vorhanden in |
+|---|---|---|
+| `FB_CommunicationWES_ASRS` | FB | UH02 + UH03 |
+| `FC_Call_StorageLines` | FC | UH02 + UH03 |
+| `FB_CommunicationWES_DeviceHub` | FB | UH04 + UH05 |
+
+### 4e) Längenmessung (UH01 + UH05)
+
+| Baustein | Typ | Pfad |
+|---|---|---|
+| `FB_Längenmessung` | FB | `Längenmessung/` |
+| `FB_LaengenmessungAI` | FB | `970_Visu/` |
+
+### 4f) String-Konvertierung (UH01 + UH04)
+
+| Baustein | Typ | Rückgabetyp |
+|---|---|---|
+| `FC_usint2String` | FC | String |
+| `FC_Uint2TroString` | FC | String |
+
+> **Zusatzempfehlung:** Zusammen mit `FC_Int2String` (5x vorhanden) prüfen, ob alle drei durch Siemens-Standardfunktionen (`INT_TO_STRING`, `USINT_TO_STRING`) ersetzt werden können. Falls eigene Formatierung nötig: zu einer parametrierbaren FC zusammenfassen.
+
+### 4g) AMR/F2H-Verwandtschaft (UH04 + UH05)
+
+| Baustein | Typ | Vorhanden in |
+|---|---|---|
+| `FB_ScanMonitor` | FB | UH04 + UH05 |
+| `FB_TROHandshakeAMR` | FB | UH04 + UH05 |
+
+### 4h) Test-Bausteine (UH02 + UH03)
+
+| Baustein | Typ | Pfad |
+|---|---|---|
+| `FB_Test_RotierenMT` | FB | `_IBN/` |
+
+---
+
+## Sonderanalyse: Versionschaos — StockRemoval (UH02)
+
+In UH02 existieren 4 Varianten desselben Kernbausteins nebeneinander:
+
+| Baustein | Pfad | Status |
+|---|---|---|
+| `FB_StockRemovalBLKModul` | `200_MFR/_AutomatedIntelligence/` | Original |
+| `FB_StockRemovalBLKModul_New` | `200_MFR/_AutomatedIntelligence/` | Neuversion |
+| `FB_StockRemovalBLKModul_New_EY` | `200_MFR/_AutomatedIntelligence/Embi/` | Sonderabzweig |
+| `Fb_StockRemovalManagementLvl1` | `200_MFR/_AutomatedIntelligence/` | Lvl1-Erweiterung |
+
+**UH03** hat daneben noch:
+- `FB_StockRemovalManagementLvl2`
+- `FB_StockRemovalSequencer`
+- `FB_StorageManagement_Rework`
+- `FB_StorageTaskScheduler`
+
+**Empfehlung:** Auf eine versionierte Hauptvariante reduzieren. Unterschiede als konfigurierbare Parameter lösen. `old/`-Verzeichnisse aufräumen.
+
+---
+
+## Sonderanalyse: "old/"-Verzeichnisse (technische Schulden)
+
+Folgende Bausteine liegen in `old/`-Unterordnern und sollten entfernt werden:
+
+| Baustein | Konfiguration | Pfad |
+|---|---|---|
+| `FB_AMR_Management` | UH04 | `200_MFR/_AutomatedIntelligence/old/` |
+| `FB_F2H_Management` | UH05 | `200_MFR/_AutomatedIntelligence/old/` |
+
+---
+
+## Nicht standardisierbar (anlagenspezifisch)
+
+Diese Bausteine sind inhärent projektspezifisch und sollten **nicht** zusammengelegt werden:
+
+| Baustein | Konfiguration | Begründung |
+|---|---|---|
+| `FB_PriorityManagement` | UH02 | Abweichende Priorisierungslogik vs. `FB_PriorityLogic` |
+| `FB_OffsetCorrection` | UH02 | Anlagenspezifische Korrektur |
+| `FC_ClearJam`, `FC_PutToHj` | UH01 | Spezifische MFR-Logik UH01 |
+| `FB_EmptyCarrBuffer`, `FB_Pin_EmptyBuffer` | UH01 | Pin-Puffer spezifisch UH01 |
+| `FB_SSCCAI` | UH01 | SSCC-Scan spezifisch |
+| `ReadServerDiagnostics` | UH01 | OPC-UA Diagnose |
+| `ReadSessionDiagnostics` | UH01 | OPC-UA Diagnose |
+| `CheckForTimeOut` | UH01 | OPC-UA Session-Timeout |
+| `LCom_Example` (OB) | UH01 | Beispiel/IBN |
+| `TestBaustein`, `FB_TestMain` | UH01 | IBN/Test |
+| `FB_BoomWorkStation` | UH01 | Ladeschleife spezifisch |
+| `FB_ButtonAck` | UH01 | Ladeschleife spezifisch |
+| `FB_DistanceFoot` | UH01 | Ladeschleife spezifisch |
+| `FB_LoadingBoom_INBOUND` | UH01 | Ladeschleife spezifisch |
+| `FB_MotorSimple_INBOUND` | UH01 | Ladeschleife spezifisch |
+| `FB_StopperSimple` / `FB_StopperSpecial` | UH01 | Ladeschleife — könnten aber zusammengefasst werden |
+| `FB_Tilt_TEST` | UH01 | Test |
+| `FB_LV1BlockStorageManagement` | UH02 | Spezifisch UH02 |
+| `FB_Lvl1AdditionalRouting` | UH02 | Spezifisch UH02 |
+| `Fb_StockRemovalManagementLvl1` | UH02 | Spezifisch UH02 |
+| `FB_StockRemovalManagementLvl2` | UH03 | Spezifisch UH03 |
+| `FB_StockRemovalSequencer` | UH03 | Spezifisch UH03 |
+| `FB_StorageManagement_Rework` | UH03 | Rework-Branch |
+| `FB_StorageTaskScheduler` | UH03 | Spezifisch UH03 |
+| `FB_AMR_Management_V2` | UH04 | AMR-Verwaltung UH04 |
+| `FB_CallAMRManagement` | UH04 | AMR-Aufruflogik UH04 |
+| `FB_F2H_Management_Rework` | UH05 | F2H Rework-Branch |
+| `FB_CallF2HManagement` | UH05 | F2H-Aufruflogik UH05 |
+| `FC_GetStationIndex` | UH05 | Stationsindex UH05 |
+| `FB_PhasenTest` | UH02 | Phasenüberwachungs-Test |
+| `FB_Test_RotierenMT` | UH02, UH03 | IBN-Test |
+
+---
+
+## Zusammenfassung: Standardisierungspotenzial
+
+| Priorität | Anzahl Bausteine | Konfigurationsbreite | Aufwand |
+|---|---|---|---|
+| **P1** — Alle 5 UH | 22 | 5x | Hoch, aber höchster Nutzen |
+| **P2** — 4 von 5 UH | 3 | 4x | Mittel |
+| **P3** — 3 von 5 UH | 1 | 3x | Niedrig |
+| **P4** — 2 von 5 UH | 23 | 2x | Nach Gruppen priorisieren |
+| **Gesamt** | **49** | — | — |
+
+### Top-5 Quick Wins
+
+1. **`FC_GET_PROFINET_DEVICE_STATES`** — Reine Diagnose-FC, kein anlagenspezifischer Inhalt. Sofort in BaseSystemLib.
+2. **`FB-OPC_UA_System-Stat`** — OPC-UA-Standard-Handling, identisch in allen 5 UH. Sofort in BaseSystemLib.
+3. **`Programming error` (OB)** — Standard-Fehlerbehandlungs-OB, keine Anlagenlogik.
+4. **`FC_Int2String` / `FC_usint2String` / `FC_Uint2TroString`** — String-Konvertierungen; prüfen ob `INT_TO_STRING` (STEP 7) ausreicht, sonst eine gemeinsame FC.
+5. **`FB_CommunicationLogger`** — TCP-Logger-Logik ohne anlagenspezifische Abhängigkeiten, in allen 5 UH identisch.

doc/HundM/suggestion.md

@@ -0,0 +1,235 @@
+# Vorschlag: Vereinheitlichung der MainTRO-Bausteine (`FB_ILS_MTRO`)
+
+Stand: 2026-07-13
+
+## Ausgangslage
+
+Die Anlage verwendet derzeit **sieben verschiedene MainTRO-Bausteine**, die aus dem
+SPS-Code extrahiert wurden:
+
+| Typ | Separatoren | Weichen | Eingänge | Ausgänge (Richtungen) | Prio-Manager | Scanner | Besonderheit |
+|---|---|---|---|---|---|---|---|
+| `FB_ILS_MTRO_1Sep` | 1 | 0 | 1 | 1 (Exit2) | 1 | 1 | Borner/Dummy-Handling |
+| `FB_ILS_MTRO_1Sep_SSCC` | 1 | 0 | 1 | 1 | 1 | 2 (+SSCC) | Endmess-Sensor |
+| `FB_ILS_MTRO_1Sep1Swi` | 1 | 1 | 1 | 2 (Exit2/3) | 2 (Dir1/2) | 1 | 2. Kreisel |
+| `FB_ILS_MTRO_1Sep2Swi` | 1 | 2 | 1 | 3 (Exit2/3/4) | 1 | 1 | 2. Kreisel |
+| `FB_ILS_MTRO_2Sep1Swi` | 2 | 1 | 2 | 2 | 4 (Dir1-4) | 2 | 2 Eingänge, 2 Kreisel |
+| `FB_ILS_MTRO_Vario` | 1 | 0 (Vario) | 1 | 1 (+Finger-Jam) | 1 | 1 | Kettenförderer, Finger-/Pos-Sensoren, Motorschutz |
+| `FB_ILS_MTRO_PinStore_Auto` | 1 + 21 | n | 1 | n Stationen | 1 | 1 | **Ausreißer** — Lagerblock, Encoder, Lagerlinien |
+
+## Kernerkenntnis
+
+Alle MainTRO-Varianten basieren auf **demselben Grundgerüst**: ein `FB_StateManager`
+mit identischer Schrittkette
+(`WaitForTrolley → Scan → CheckLoad → CheckSep → GetDirection → CheckJam → CheckSwitch → ReleaseSep → Buchen`),
+plus zusammengesetzte Sub-TRO-Bausteine (`FB_ILS_STRO_Sep`, `FB_ILS_STRO_Switch`,
+`FB_ILS_STRO_Vario`, `FB_BarcodeReaderCognex`).
+
+Was sich zwischen den Typen unterscheidet, ist fast ausschließlich die **Anzahl**
+einiger Sub-Module und die entsprechende Zahl an Staubereichen/Richtungen. Das
+Namensschema `<nSep>Sep<nSwi>Swi` bringt es auf den Punkt: Es sind keine 7 Verhaltensweisen,
+sondern **ein Verhalten**, instanziiert mit 1–2 Separatoren, 0–2 Weichen, 1–4 Richtungen.
+
+Der skalare Teil der Schnittstelle ist **überall identisch**: `stInSettings` (Borner,
+Jam-Src/Dest, `bSepType`, Timings), `nInMainTroNo`, `xInSftyOk`, `xInAllRdyToStart`,
+`xInTestMode`, `xInCancel`, `xInAreaStopActive`, `xInRelease`, dazu die Ausgänge
+`xOutCorrection / nOutStateLast / nOutScanResult / xOutNewScan` und die In-Outs
+`stInOutMachineState / stInOutCognexInterface / stInOutHMI`. Lediglich die
+*wiederholten* Elemente werden von Hand vervielfältigt und durchnummeriert
+(`...1`, `...2`, `Dir1..Dir4`, `Exit2..Exit4`).
+
+## Vorschlag: ein einziger Baustein `FB_ILS_MTRO`
+
+Die von Hand nummerierten Member werden durch **Arrays von zusammengesetzten UDTs**
+ersetzt, plus einen **Konfigurations-/Routing-Deskriptor**, der angibt, wie viele
+Elemente jeder Art existieren und wie jede Richtung verdrahtet ist. Der skalare Kern
+bleibt unverändert.
+
+### 1. Vereinheitlichte TRO-Typdefinition (ersetzt die 7 `fbType`-Namen)
+
+```json
+{
+  "$def": "FB_ILS_MTRO",
+  "description": "Single MainTRO block, shaped by config instead of by type name",
+  "config": {
+    "nNoOfSeparators": { "type": "USInt", "range": [1, 2] },
+    "nNoOfSwitches":   { "type": "USInt", "range": [0, 2] },
+    "nNoOfCarousels":  { "type": "USInt", "range": [1, 2] },
+    "nNoOfDirections": { "type": "USInt", "range": [1, 4] },
+    "xScannerPlugged": { "type": "Bool" },
+    "xSsccPlugged":    { "type": "Bool" },
+    "xVarioMode":      { "type": "Bool" }
+  },
+  "arrays": {
+    "arInSeparator":       "Array[1..2] of UDT_MTRO_SeparatorIf",
+    "arInSwitch":          "Array[1..2] of UDT_MTRO_SwitchIf",
+    "arInDirection":       "Array[1..4] of UDT_MTRO_DirectionIf",
+    "arInPriorityManager": "Array[1..4] of UDT_Response",
+    "arInCarouselRun":     "Array[1..2] of Bool",
+    "arInOutJamEntr":      "Array[1..2] of UDT_JamArea",
+    "arInOutJamExit":      "Array[1..4] of UDT_JamArea"
+  },
+  "scalarCore": [
+    "stInSettings", "nInMainTroNo", "xInSftyOk", "xInAllRdyToStart",
+    "xInTestMode", "xInCancel", "xInAreaStopActive", "xInRelease",
+    "stInOutMachineState", "stInOutHMI"
+  ]
+}
+```
+
+### 2. Die zusammengesetzten UDTs, die als Array geführt werden
+
+```json
+{
+  "UDT_MTRO_SeparatorIf": {
+    "stSenInSep": "UDT_Sensor", "stSenSepLeft": "UDT_Sensor",
+    "stSenPart": "UDT_Sensor", "stSenStartScan": "UDT_Sensor",
+    "stSenJamExit": "UDT_Sensor",
+    "Settings": "SettingsSeparator",
+    "bSepType": "Byte", "xIsBorner": "Bool", "nBornerDest": "Int"
+  },
+  "UDT_MTRO_SwitchIf": {
+    "stSenExit3": "UDT_Sensor", "stSenExit4": "UDT_Sensor",
+    "Settings": "SettingsSwitch"
+  },
+  "UDT_MTRO_DirectionIf": {
+    "xPrioRelevant": "Bool",
+    "nSepIndex": "USInt", "nSwitchIndex": "USInt", "nSwitchPos": "USInt"
+  },
+  "UDT_JamArea": {
+    "arCarrier": "Array[*] of stCarrier", "stData": "stJamData"
+  }
+}
+```
+
+### 3. Per-Instanz-Konfiguration, die jeden alten Typ reproduziert (die "Anreicherung")
+
+```json
+{
+  "instances": [
+    {
+      "name": "TRO101", "replaces": "FB_ILS_MTRO_1Sep",
+      "config": { "nNoOfSeparators": 1, "nNoOfSwitches": 0,
+                  "nNoOfCarousels": 1, "nNoOfDirections": 1,
+                  "xScannerPlugged": true, "xSsccPlugged": false, "xVarioMode": false },
+      "direction": [ { "nSepIndex": 1, "nSwitchIndex": 0, "nSwitchPos": 0, "xPrioRelevant": false } ]
+    },
+    {
+      "name": "TRO102", "replaces": "FB_ILS_MTRO_1Sep_SSCC",
+      "config": { "nNoOfSeparators": 1, "nNoOfSwitches": 0,
+                  "nNoOfCarousels": 1, "nNoOfDirections": 1,
+                  "xScannerPlugged": true, "xSsccPlugged": true, "xVarioMode": false }
+    },
+    {
+      "name": "TRO103", "replaces": "FB_ILS_MTRO_1Sep1Swi",
+      "config": { "nNoOfSeparators": 1, "nNoOfSwitches": 1,
+                  "nNoOfCarousels": 2, "nNoOfDirections": 2,
+                  "xScannerPlugged": true, "xSsccPlugged": false, "xVarioMode": false },
+      "direction": [
+        { "nSepIndex": 1, "nSwitchIndex": 1, "nSwitchPos": 3, "xPrioRelevant": true },
+        { "nSepIndex": 1, "nSwitchIndex": 1, "nSwitchPos": 4, "xPrioRelevant": true }
+      ]
+    },
+    {
+      "name": "TRO104", "replaces": "FB_ILS_MTRO_1Sep2Swi",
+      "config": { "nNoOfSeparators": 1, "nNoOfSwitches": 2,
+                  "nNoOfCarousels": 2, "nNoOfDirections": 3,
+                  "xScannerPlugged": true, "xSsccPlugged": false, "xVarioMode": false }
+    },
+    {
+      "name": "TRO105", "replaces": "FB_ILS_MTRO_2Sep1Swi",
+      "config": { "nNoOfSeparators": 2, "nNoOfSwitches": 1,
+                  "nNoOfCarousels": 2, "nNoOfDirections": 4,
+                  "xScannerPlugged": true, "xSsccPlugged": false, "xVarioMode": false }
+    },
+    {
+      "name": "TRO106", "replaces": "FB_ILS_MTRO_Vario",
+      "config": { "nNoOfSeparators": 1, "nNoOfSwitches": 0,
+                  "nNoOfCarousels": 1, "nNoOfDirections": 1,
+                  "xScannerPlugged": true, "xSsccPlugged": false, "xVarioMode": true }
+    }
+  ]
+}
+```
+
+### 4. Einbindung in die bestehende `units[]`-Skeleton-Struktur
+
+Heute schreibt `create_skel.py` einen `fbType`-String pro Einheit. Im Vorschlag wird
+dieses eine Feld zu `fbType: "FB_ILS_MTRO"` plus ein `config`-Objekt, das der Generator
+aus den gezählten Rollen füllt:
+
+```json
+{
+  "unit": "M0101",
+  "fbType": "FB_ILS_MTRO",
+  "config": {
+    "nNoOfSeparators": 1, "nNoOfSwitches": 1,
+    "nNoOfCarousels": 2, "nNoOfDirections": 2,
+    "xScannerPlugged": true, "xSsccPlugged": false, "xVarioMode": false
+  },
+  "io": {
+    "sensorInSep":   ["BG0101"],
+    "switchOutput":  ["MB0102"],
+    "stopperOutput": ["MB0101"],
+    "sensorJam":     ["BG0103"]
+  }
+}
+```
+
+`guess_fbtype()` (liefert heute einen der 7 Namen, siehe `lib/create_skel.py:558-563`)
+würde stattdessen `"FB_ILS_MTRO"` zurückgeben plus einen zählenden Regelsatz:
+
+```json
+{
+  "configRules": {
+    "nNoOfSeparators": "count(roles == 'sensorInSep')",
+    "nNoOfSwitches":   "count(roles == 'switchOutput')",
+    "nNoOfDirections": "count(roles == 'switchOutput') + 1",
+    "xScannerPlugged": "any(role == 'sensorStartScan')",
+    "xVarioMode":      "has(roles, 'sensorFinger') or has(roles, 'sensorCarrInPos')"
+  }
+}
+```
+
+## Abbildung der alten Typen auf den neuen Baustein (Übersicht)
+
+| Alter Typ | Konfiguration, die ihn reproduziert |
+|---|---|
+| `1Sep` | Sep=1, Swi=0, Car=1, Dir=1 |
+| `1Sep_SSCC` | Sep=1, Swi=0, Dir=1, `xSsccPlugged=TRUE` |
+| `1Sep1Swi` | Sep=1, Swi=1, Car=2, Dir=2 |
+| `1Sep2Swi` | Sep=1, Swi=2, Car=2, Dir=3 |
+| `2Sep1Swi` | Sep=2, Swi=1, Car=2, Dir=4 |
+| `Vario` | Sep=1, Swi=0, Dir=1, `xVarioMode=TRUE` |
+
+Sieben Bausteine → **ein Baustein + ein Konfigurationsdatensatz pro Instanz**.
+
+## Was separat bleibt
+
+- **`FB_ILS_MTRO_PinStore_Auto`** ist ein echter Ausreißer — 21 Linien-Separatoren,
+  Encoder-Positionserfassung, Lagerlinien-Daten (`arInOutStorageLines`),
+  Auslager-Stationen. Es ist ein *Lager*-Controller, kein Routing-TRO. Die übrigen
+  sechs werden in `FB_ILS_MTRO` zusammengeführt; PinStore bleibt eigenständig
+  (oder wird zu `FB_ILS_STORE`).
+- **Vario** ist ein Grenzfall: Es tauscht die Weiche gegen einen Kettenförderer mit
+  Finger-/Positionssensoren. Es passt als `xVarioMode` (ein Sub-Modul-Schalter), weil
+  es weiterhin denselben Separator + State-Manager nutzt. Falls die Finger-Schrittkette
+  zu stark abweicht, ist ein dünner Wrapper über den gemeinsamen Kern der Mode-Flag
+  vorzuziehen.
+
+## Abwägung
+
+- **Pro:** ein Baustein zum Testen/Versionieren/Dokumentieren; `create_skel.py` wird
+  deutlich einfacher (kein `FBTYPE_TEMPLATE`-Mapping, ein Aufruf-Template); das in der
+  Standardisierungsanalyse markierte "Versionschaos" entfällt.
+- **Contra:** Arrays mit `nNoOf...`-Guards sind weniger selbsterklärend als ein
+  benannter `1Sep1Swi`; ungenutzte Array-Elemente kosten pro Instanz weiterhin
+  DB-Speicher. Multi-Instanz-Sub-FB-Arrays und `Array[*]`-In-Outs werden auf dem
+  Zielsystem (CPU 1518F) gut unterstützt — es gibt keinen Plattform-Blocker.
+
+## Nächste Schritte (offen)
+
+1. `FB_ILS_MTRO.scl`-Skelett prototypisieren (mit `FOR`-Schleifen-Aufrufen der Sub-TROs
+   und einer datengetriebenen Richtungs-Tabelle).
+2. `create_skel.py` anpassen, sodass es den einzelnen Baustein mit `config`-Block
+   ausgibt statt der sieben Templates.