Konzept: Staubereiche nach Separator, SCL-Namen nach UH01-UH05

- Kennung der Staubereiche in der JSON nach ihrem Separator (J<Sep>,
  wie im Mubea-Layout J1024 fuer Sep1024)
- SCL-Name festgelegt auf den Standard UH01-UH05:
  "DB_JamArea<NNNN>".stJam<NNNN>_<k> (Foerderernummer, Reihenfolge
  entlang des Materialflusses)
- Separator- und Foerderernummern wie TRO-IDs in der ID-Datei

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

doc/Konzept_Layout_Hardware_SCL.md

@@ -277,18 +277,35 @@ Zusammenführungen nicht eindeutig.
 
 **Vorschlag:**
 
-- **Kennung in der JSON nach dem Nachfolger:** `JA_<TRO-ID>`, z. B. `JA_TRO112`;
-  ein zweiter Eingang (PinStore) `JA_TRO208_2`. Eindeutig, solange die TRO-IDs
-  eindeutig sind, und mit ihnen stabil.
-- **Name im SCL nach dem bisherigen Schema** `"DB_JamArea<NNNN>".stJam<NNNN>_<k>`:
-  `<k>` lässt sich aus dem Layout ableiten (Reihenfolge auf dem Förderer in
-  Flussrichtung), `<NNNN>` ist die Förderernummer. Die vergeben wie die TRO-IDs
-  die SPS-Programmierer bzw. sie kommt aus der Hardwareplanung (`KR-K0102`); sie
-  steht in derselben ID-Datei (`[mubea.foerderer]`, `K0102 = <Lage>`). Ohne
-  Förderernummer bleibt der Name `TODO(E-Planung)` wie heute.
-- **Alternative,** falls das alte Schema nicht nötig ist: SCL-Name direkt aus der
-  Kennung (`"DB_JamArea".JA_TRO112`); braucht keine Förderernummern, weicht aber
-  von den bestehenden Projekten und deren `FC_Call_Jams` ab. Entscheidung offen.
+**Ergänzung (2026-10-11):** In einem Mubea-Layout heißen die Staubereiche nach
+**ihrem Separator**: der Staubereich vor `Sep1024` heißt `J1024`. Das passt zum
+Befund oben: der Staubereich ist die Warteschlange vor dem Stopper, also der
+Eingang genau eines TRO bzw. genau eines Separators. Das Layout liegt nicht im
+Repo; Quelle der Separatornummer (Zeichnungsbeschriftung, E-Planung, Vergabe durch
+die SPS-Programmierer) noch klären.
+
+- **Kennung nach dem Separator:** `J<Separatornummer>`, z. B. `J1024`. Das ist
+  feiner als eine Kennung je TRO und deckt TROs mit mehreren Separatoren
+  (`2Sep1Swi` mit `JamEntr1`/`JamEntr2`) ohne Sonderregel ab. Zusammenführungen
+  sind kein Problem, weil der Name nur am Nachfolger hängt.
+- **Separatornummern wie TRO-IDs behandeln:** in derselben ID-Datei, über die Lage
+  des Separators wiedergefunden, von den SPS-Programmierern vergeben bzw.
+  übernommen; `--renumber` vergibt sie in der frühen Phase neu.
+- **Name im SCL — festgelegt: Standard sind die SCL-Dateien UH01–UH05,** also
+  `"DB_JamArea<NNNN>".stJam<NNNN>_<k>`. `J<Separatornummer>` ist nur die Kennung
+  in der JSON (und die Beschriftung im Layout), nicht der SCL-Name. Für den
+  SCL-Namen braucht es je Staubereich:
+  - `<NNNN>`: die **Förderernummer** des Förderers, auf dem der Staubereich liegt
+    (Kreisel K0102 → `0102`); vergeben von den SPS-Programmierern bzw. aus der
+    Hardwareplanung (`KR-K0102`), gepflegt in der ID-Datei wie TRO-IDs und
+    Separatornummern;
+  - `<k>`: laufende Nummer **entlang des Materialflusses** auf diesem Förderer,
+    aus dem Layout abgeleitet (Kreisel in Umlaufrichtung, beginnend an einer
+    festzulegenden Stelle, z. B. nach der Einschleusung).
+
+  Ohne Förderernummer bleibt der Name `TODO(E-Planung)` wie heute.
+- Ausnahmen bleiben Sonderfälle mit eigenem Namen: Lagerlinien, Übergabe an eine
+  andere Steuerung, Leerträgerpuffer.
 
 ### Korrekturen in BricsCAD
 
@@ -315,8 +332,9 @@ erzeugen, `doc/Python_Scripts.md` ergänzen.
 
 ## Offene Entscheidungen
 
-- **SCL-Name der Staubereiche:** bisheriges Schema mit Förderernummer (Empfehlung)
-  oder neues Schema direkt aus `JA_<TRO-ID>`.
+- **Staubereiche:** woher die Separatornummer (`Sep1024` → `J1024`) stammt; wo auf
+  einem Kreisel die Zählung `<k>` beginnt (Referenz K0102 prüfen). Das SCL-Schema
+  ist festgelegt (UH01–UH05).
 - **Toleranz** beim Wiederfinden der TROs über die Lage; Verhalten, wenn ein
   Separator weiter verschoben wurde (Vorschlag: als "neu" + "weggefallen" melden,
   der Programmierer übernimmt die ID von Hand).