Orchestrator/bahn/Analyse-O2C-C2S/sources/c2s/C2S-UjKonstruktion/teams/Abstimmungen-zwischen-Team-Adams-und-Team-Ains.md

Abstimmungen zwischen Team Adams und Team Ains

Version: 107 | Last modified: 2026-06-11T11:29:17.961+02:00 Source: confluence page ID 508364387

---

Diese Seite dient dazu Abstimmungen zwischen Team Adams und Team Ains zu bündeln und festzuhalten, damit wir diesen an einem Ort nachhalten können und nicht unterschiedlich Kanäle und Kommunikationswege nutzen müssen.  trueRedOffen trueBlueIN ARBEIT trueGreenErledigt (PI 38) Abstimmungen zu C2SUJK-190 [TTT] Bekanntgabe BKE an GPE und FPEThema | Einbringende | Detailbeschreibung | Entscheidung | BKE-API für den initialen Datenabzug trueGreenErledigt | Marcel | Die BKE-API wird vsl erst spät in der Iteration 38.5 fertig. Lösungsmöglichkeit wäre eine initiale Befüllung via Kafka | Feedback: Aus unserer Sicht benötigen wir zum aktuellen Stand in PI-38 nicht komplett alle BKE Daten. Uns würden für die Tests in diesem PI die Daten des letzten Kommunikationszeitpunkts genügen. Wie die Schnittstelle zukünftig umgesetzt werden bzw. arbeiten soll, sollten wir nochmal zusammen mit Zülfükar abstimmen. | Langnamen zur Betriebsweise trueGreenErledigt | Sandra via MS Teams | Hallo Team AINS,könnt ihr uns noch die Story von euch schicken in der ihr die Betriebsweise-ID in den BBR-Daten zusätzlich zu dem Langnamen mitschickt. Damit wir das mit unserem Umsetzungsticket verlinken können. Danke!  Weitergabe der ID statt der Langnamen. | Erster Schritt mit Team Ains reden, warum wir Langnamen statt ID in Kafka übergeben? Änderung zeitnah möglich.   Ich habe das Thema ausführlich mit unseren Entwicklern besprochen. Ich stimme mich noch mit Marcel ab, dann können wir Euch morgen Vormittag Lösungsvorschläge geben. Wir werden das c2s.bau.bbm.veroeffentlich-Topic um ein Attribut betriebsweiseKey erweitern. In diesem Feld übertragen wir dann die ID aus der Stammdatentabelle. Zusätzlich erweitern wir auch die BbmVersionAPI um diese ID, damit für die Initialisierung die gleiche Datenstruktur vorliegt. Story dazu UKAINS-1249.  und die UKAINS-1249 wird in der Iteration 38.5 umgesetzt und von mir am höchsten priorisiert. Wichtig dabei ist, dass die Kafka-Schemadefinition bis zum ersten Donnerstag nach dem Iterationswechsel feststeht und dem Team Adams mitgeteilt wird.  | Datenstruktur VE-Kafka-Topics  vs. bbm-basierten API trueGreenErledigt | Sandra | Prüfung ob der letzte Stand der Datenstruktur im VE-Kafka-Topics der Datenstruktur in der bbm-basierten API entspricht. | Die Datenstruktur von beiden Schnittstellen ist einheitlich. Ausnahme: Störungen sind nicht Bestandteil des initialen Abruf via BBMVersion-API. Müssen sie aus meiner Sicht auch nicht sein.   | BBM-basierte API trueGreenERLEDIGT | Franziska am  

| Ist die API aus Sicht von Team Ains fertig? Sie ist anscheinend recht langsam (Tim Vahlbrock: Fixes BBM Version API | ART Uj Konstruktion > Team Ains | Microsoft Teams) | Ja, die API ist fertig. Die Performance schauen wir uns noch Mal an. Das die BBM API langsamer sein wird als die VE-API war uns klar, aber der Faktor ist uns zu hoch. ADAMS hat die Anbindung als Update für aktuell gültige Daten umgesetzt und wir werden das zeitnah für die Prod-Umgebung verproben und dann hier zu den Laufzeiten Feedback geben. | Test auf int-sys trueGreenErledigt | Franziska am   | Es soll mit dem Wiremock und mit von euch erstellten Testdaten (BKE zu BBM passend) getestet werden. Wann können wir ungefähr damit rechnen? | Test für init-sys werden aktuell erstellt. Tests werden am durchgeführt und nachfolgend soll die Abnahme des Feature -190 mit dem PM auf int-sys erfolgen. | Änderungen an BKEn trueGreenErledigt | Franziska / Sandra am   | Input aus dem fachlichen Austausch In den Annex VII-Schulungen gibt es folgende Folie, zu der gesagt wird, dass sich die final abgestimmten BKE nicht mehr ändern dürfen:

Hier haben wir die Darstellung des Ablaufes aus Sicht KE-Service, wo BKE durchaus im weiteren Verlauf ersetzt werden:

Heißt "nicht mehr ändern" dann nur, dass sich die BKE an sich nicht mehr ändert, aber sie kann später noch entfallen? | Feedback dazu von Fabian Knöller : BKE ändern sich auch später nochmal: Ausfall Kleiner werden (Ausfall + neue BKE, aber kein Prozessstörer) Größer werden (Ausfall + neue BKE als Prozessstörer (Nr. 14 Legitimierung) Diese Verschneidung muss der KE-Service machen. s. auch Szenarien zu C2SLS-2019 https://arija-confluence.jaas.service.deutschebahn.com/x/Ra0uIQ Prüfen ob die Übertragungsszenarien auch für diesen Fall trägt. 

| Änderung der MakSi-FM BKE-API trueGreenErledigt | Wolfgang am   | Es gibt eine neue Version der API Die neue Version 0.9.5 passt nicht zu der aktuellen Implementierung (0.9.4) im KE-Service. Die Kombau verwendet schon diese Version.  Folgende Änderungen sind bis jetzt identifiziert: kp3Teil heißt jetzt bkeKp3Teil bzw. bbrKp3Teil und bekommt Ausprägung Teil1/2 dazu (breaking change) entstandenAusBKE in KP 4 ist jetzt ein String BkeJson hat jetzt zusätzlich das Attribut referenzBKE (non-breaking, aber der KE-Service parst offenbar strikt und scheitert daran) BkeBbrInfoKP4 entfällt, stattdessen wird BkeBbrInfo verwendet (breaking change) BkeKommunikationsstatusKP4 hat jetzt das Attribut fahrplanjahr (non-breaking) Simon hat jetzt auch nachvollzogen, dass die Umbenennung auf bbrKp3Teil und damit ein Breaking Change auch in den Daten vorliegt (der KE-Service scheitert an einem non-breaking Change). Alle anderen Änderungen betreffen BBRen oder die KP4. Simon: Die Teil12-Problematik betrifft auch die BKEen der 2./3. KP. Bislang ist nur Teil1 oder Teil2 zulässig. Ich hab jetzt einfach mal Teil12 auf Teil1 gemappt. Ich denke, das ist für die Testumgebungen auch erstmal okay. Aber wir müssen das unbedingt mit ASt-Bau besprechen. Ebenso die Änderungen für die 4. KP

|

| Änderung der MakSi-FM BKE-API trueGreenErledigt | Sandra   | Wir haben die Anpassungen auf unserer Seite durchgeführt Mit welchem Releasae können wir die Änderungen ausliefern? | bitte mitnehmen und mit Team besprechen. Ziel ist das Release L35.1 01.04.2026: Wurde gestern, am 31.03.2026 gemergt. Wird mit dem nächsten Relase R36 (RedLane) am 15.04.2026 ausgeliefert. 

Ist es ggf. schon im R35 geliefert worden? → ist in Nachlieferung für R35 enthalten | Publikation x-12 trueGreenErledigt | Sandra     | Auf welcher Umgebung ist das möglich?  | Marcel: Auf der ifp-int-sys

| trueRedOFFEN Daten für die 4. KP | Marcel | Ab 22.4. werden Daten der 4. KP zur Verfügung gestellt (int-sys) Vorerst ist der Abruf der Daten noch deaktiviert, wird erst nach erfolgreichem Test durch Team AINS aktiviert. | 4. KP wird voraussichtlich mit R37 auf Prod zur Verfügung stehen | trueGreenerledigt Schnittstellenänderungen der BKE-API für die 4.KP  | Wolfgang, Marcel | Aktuell ist die das Feld statusBAKO required. Es wurde festgestellt, dass required nicht korrekt ist. Somit kann das Feld zukünftig null liefern. Ist das ein Problem für die AsTBau? | Wurde im PI Planning 41 besprochen und Abhängigkeiten eingeplant.  | trueRedoffen Daten für die 4. KP | Sandra | Aufgabe aus Capaabnahme von Fabian Daten der 4.KP in Prod prüfen | statusBAKO ist nicht mehr required, deswegen wurden die BKE-Daten für 4. KP bisher nicht gespeichert und sind in Prod auch nicht in der AStBau sichtbar. AINS passt das in Iteration1 an. ADAMS hat die Aufgabe zur Anpassung ebenfalls in Iteration1 eingeplant. | (PI 39) Abstimmungen zu C2SUJK-650 [TTT] Baubetroffene Züge Obermenge ermittelnThema | Einbringende | Detailbeschreibung | Entscheidung | Übertragung Verkehrsart trueGreenErledigt | Franziska | In der AStBau sollen die Baubetroffenheiten auch aufgeschlüsselt nach Verkehrsart (SPNV, SPFV, SGV) angezeigt werden. Die Information zur Verkehrsart brauchen wir daher für die PathIds. Kann die Verkehrsart über Kafka mitgeliefert werden? | Termin mit Manfred, Wolfgang, Franziska, Jochen: Verkehrsart wird von Team Ains mitgeliefert | Initialsync trueGreenErledigt | Franziska | Wie kann der Initialsync der Baubetroffenheiten funktionieren?  Option: Analog zu BKE-Initialsync - AStBau ruft Endpunkt auf, der Trigger dafür ist, dass alle aktuell vorhandenen Daten von Ains auf ein neues fullpublication Kafka-Topic geschrieben werden Termin am: ggf. "zu viel" für Kafka? - Ains klärt das im Team/ mit Architekten Option: API, die AStBau die vorhandenen Daten zurückliefert (analog zu VE-API) Option: Funktionalität ist mit einem Feature-Toggle versehen und kann aktiviert werden, wenn beide Services auf einer Umgebung dazu bereit sind. (Analog zum Vorgehen bei BKE) Von Adams bevorzugte Variante: Option 3 | Wir nehmen mit und klären mit dem Team den Einbau des Feature-Toggle (Option 3) und eine Rückmeldung hier geben.  Aus meiner Sicht ist bei Team Ains für die Variante 1 kein Feature-Toggle notwendig. Team Ains geht dreistufig vor.  Abruf der Belegungen aus dem Kapaservice Abruf der Zugtrassen Berechnen der Konflikte und Publizieren der Konflikte via Kafka.  Für den Initialsync kann nach der Bereitschaftsmeldung durch die AStBau  der Schritt 3. eingeleitet werden. Damit beginnt die Berechnung und Publikation der Konflikte somit der Initialsync ohne Mehraufwand für Team Ains durchgeführt werden.  | Konfliktzeiten trueGreenErledigt | Franziska an Manfred und Wolfgang per Chat | Die AStBau soll Baubetroffenheiten an Bauvorgängen aggregiert anzeigen. Da eine bVE wochenweise auf Bauvorgänge aufgeteilt wird, muss auch eine zeitliche Zuordnung der Baubetroffenheiten möglich sein. Der Konfliktservice hat laut Zülfükar auch die Zeiten der Konflikte. | Kann der Konfliktservice die zeitlichen Daten mitschicken? → Ja die Zeiten werden mitgeliefert | Mengengerüst Kafka-Nachrichten zu Baubetroffenheiten trueRedOFFEN | Franziska an Manfred und Wolfgang per Chat | Habt ihr ein ungefähres Mengengerüst, wie viele Kafka-Nachrichten zu Baubetroffenheiten es geben wird? | Bitte mit Niko nochmals reden oder bei RUT-K erfragen und eine Rückmeldung hier geben.  Pro Tag werden in der BKE-Verwaltung ca. 100 - 150 BKEn erwartet : Interessant, aber sagt nichts über die Baubetroffenheiten aus?! Meinst Du damit Konflikte mit BBM? Wenn ja, können wir es momentan noch nicht genau konkret sagen. Nach dem ersten Testläufen bei uns könnten wir das bei uns analysieren. Momentan die grobe Schätzung von 1 - 100 000.  Wann genau, wird es dazu eine genauere Schätzung geben? Klärt   nochmal |

(PI 40) Abstimmungen zu C2SUJK-650 [TTT] Baubetroffene Züge Obermenge ermittelnThema | Einbringende | Detailbeschreibung | Entscheidung | Direkte und indirekte Konflikte einer bVE/Trasse trueGreenFertig | Manfred am   | Zu einem Paar aus einer Trasse und einer bVE kann es Mischformen aus direkter und indirekter Betroffenheit geben:  bVE liegt in Betriebsstelle A,B,C, Trasse verkehrt durch A,B,C  Aber nur in C kommt es zum direkten Konflikt. Wie wollen wir damit umgehen? | Vorschlag:  Wenn direkte Konflikte vorliegen, werden die indirekten Anteile ignoriert. Es zählen dann nur die Konfliktzeiten des direkten Anteils. Die indirekten Konflikte beziehen sich dann also nur auf solche Trassen, die keinen direkten Konflikt besitzen.

Gegenvorschlag: Wenn direkte und indirekte Konflikte vorliegen, werden zwei Nachrichten geschickt: bVE-Trasse mit direkter Betroffenheit bVE-Trasse mit indirekter Betroffenheit Team Ains wird den Gegenvorschlag bVE-Trasse mit direkter Betroffenheit bVE-Trasse mit indirekter Betroffenheit  umsetzen.  | Ablaufsteuerung der Konfliktübermittlung trueGreenfertig | Manfred am | Der Konfliktservice speist sich aus drei unterschiedlichen Quellen: FAPS, und DaViT für die Trassen und KE-Service für bVE. Um ggf. Datenüberholungen z. B. bei direkten und indirekten Belegungen zu minimieren, wäre eine retardierte Konfliktermittlung vorteilhaft. Ist das möglich und welcher Aktualisierungsrythmus wäre hier für AST-Bau günstig |  10 - 15 Minuten für die Aktualisierung sind stand heute akzeptabel.  | Keine Berücksichtigung der Ausregelungsinformationen trueGreenfertig | Manfred am | Ab Fahrplanjahr 2027 sind die Ausregelungsinformationen an der ZugtrassenAPI/Kafka Topic irrelevant.  Wegen der Komplexitätsreduktion im Konfliktservice würden wir dies Auswertung gerne entfallen lassen | Vorschlag:  Keine Auswertung der Ausregelungsinformationen im Fahrplanservice

Kann so gemacht werden. Keine Relevanz für Team die AsTBau, da es für Fahrplan 2027 relevant ist und 2026 nicht betrachtet wird.  | Trassen-Informationen trueBlueIN ARBEIT | Franziska am   | In unserer Schnittstellenabsprache hatten wir festgelegt, dass für die Trasse. jeweils PathId und PathRequestId übergeben werden sollen. In der umgesetzten Schnittstelle steht jetzt allerdings auch der Gesamttrasse-Key mit drin (der eigentlich nur in RUT-K verwendet werden sollte?) und ist das einzige Pflichtfeld... Ist der Gesamttrasse-Key jetzt nur übergangsweise mit drin, solange nicht alle Trassen Path-Ids haben? AStBau soll in Produktion nur Daten für Fplj 2027 anzeigen. Würde es für uns damit reichen, wenn wir nur Daten speichern, die eine Path-Id enthalten? | pathID und pathRequestID sind optionale Felder der ZugtrassenAPI bzw. des Kafka-Topics x.c2s.fpl.zugtrasse.allebearbeitet.v*, pathID ist m. W. n. auch erst ab Fahrplanjahr 2027 verpflichtend. Um im jeden Fall auf der sicheren Seite zu sein, wurde deshalb der gesamttrasseKey mit integriert, dieser ist ein Pflichtfeld in beiden Schnittstellen. (Das Konflikte des Fplj 2026 nicht interessant sind, wurde auch erst später kommuniziert). Zu Punkt 2: So weit ich weiß, soll jede Trasse des Netzfahrplan 2027 (und folgende Fahrpläne) zwingend eine Path-ID besitzen, allerdings nicht von Anfang an. Genauer der Regelfall ist pathID ist vorhanden, es gibt aber Konstellationen in denen die pathID später dazu kommt.

Todo Adams: Wie lange dauert es, bis eine Trasse eine PathId bekommt in RUT-K?  Vermutung: In AStBau werden nur die Konflikte für Trassen mit PathIds benötigt. Ggf. Klärung mit PM Das entspräche auch dem markierten AK:

Feld wird entfernt, wenn wir im PI 42 die neuen Attribute übergeben.   | bVE-Informationen trueGreenfertig | Franziska am   | In der Schnittstellenabsprache haben wir nur bVE-Nummer und BBMN-Id für die Identifizierung von bVE festgelegt. Brauchen wir die BBMN-Versionsnummer noch zusätzlich, oder liefert der Konfliktservice immer Konflikt-Informationen für die aktuellste bVE-Version? | Jede neue Version einer bVE führt zu einer Aktualisierung der Konflikte (es könnte sich ja was geändert haben) und diese Konflikte werden mit der aktuellsten Version der bVE ermittelt und übermittelt. D. h. ja, es bezieht sich immer auf die aktuellste Version der bVE. | Raffinade der  [C2SUJK-888] [TTT] Ermittelte Konflikte sind um Trasseninformationen ergänzt sowie bewertet abhängig von bve-Art - DB InfraGO ITD Lifecycle Management Tool trueBlueIN ARBEIT | Manfred am   | Im genannten Feature sind umfangreiche Attribute der Zugtrassen genannt, die in Abstimmung mit ADAMS integriert werden sollen (vgl. AK1 Attribute sind mit Team Adams abgestimmt, z.B. PathID, Zugnummer, VTs, Start-/Ziel-Betriebsstelle, Regionen und ggf. die betroffenen Betriebsstellen) Wie ist das weitere Vorgehen? | Doppelte Datenhaltung nicht sinnvoll Idee: Daten aus AStBau direkt bei Faps abfragen Adams spricht nochmal mit den Anwendern, ob die "ausführliche" Anzeige sinnvoll ist und spricht dann nochmal mit Zülfükar | Betroffenheitsberechnung Regeltrasse vs. Bautrasse trueGreenfertig | Franziska am   | Im Feature von Ains das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eC2SUJK-650 steht folgendes AK:

D.h. was passiert in folgendem Szenario: Es gibt eine Regeltrasse an einem Verkehrstag, die mehrere Konflikte mit verschiedenen bVE hat, z.B. 1 Konflikt in RB Ost, 1 Konflikt in RB Nord. → Initial werden 2 bVE-Trassen-Konflikt-Messages geschickt: 1 für den Konflikt in Ost, 1 für den Konflikt in Nord Dann wird in Ost eine Bautrasse angelegt, um den Konflikt dort aufzulösen. Welche Update-Messages bekommt die AStBau? Konflikt in Ost ist nicht mehr existent.  D.h. es wird spezifisch für die bVE geschaut, ob hierfür eine Bautrasse angelegt wurde und dadurch der Konflikt nicht mehr existiert. (Würde das dann auch bei Mehrfachbetroffenheiten in der gleichen Region funktionieren, das für einen Verkehrstag ein Konflikt mit der Regeltrasse und ein Konflikt mit der Bautrasse existiert?) Konflikt in Ost ist nicht mehr existent und Konflikt in Nord ist nicht mehr existent. D.h. es würde für den Verkehrstag nur noch auf Konflikte der Bautrasse geschaut und die neu ist Ost angelegte Bautrasse hat in Nord keinen Konflikt. |

| Messestand

| Sandra   | Messestand Vorbereitung Umgebung - ifp-integration Abstimmung zu den Anwendungsfällen Termin am   | Kurze Einleitung zum Konfliktservice Obermenge wird dargestellt Trasse kommt rein Obermenge wird geringer Darstellung an bVE und Bauvorgänge | Datenbereitstellung trueBlueIN ARBEIT | Sandra   | Obermengen Datenbereitstellung auf den Umgebungen Auf welchen integrativen Umgebungen stehen die Daten zur Verfügung? Wann werden die Daten in Produktion zur Verfügung stehen? | Konfliktservice Anbindung auf Produktion abhängig vom Infrastukturdatenservice SIC-OP Migration noch ausstehend Zieldatum für Prod wird demnächst feststehen

|

|

|

|

| PI-41 Abstimmungen zu C2SUJK-786 Attribute aus VERAThema | Einbringende | Detailbeschreibung | Entscheidung | Feature-Refinement trueBlueIN ARBEIT

| Sandra   | Gemeinsame Abstimmung zum Inhalt und Umfang des Features | Zusätzliche Attribute entgegennehmen und speicher   Klärung zu den fachlichen Anforderungen, wo sollen die zusätzlichen Attribute verwendet werden (angezeigt, weitergegeben) Aufwand abschätzen und im Ticket dokumentieren

| Feature-Refinement trueBlueIN ARBEIT | Manfred | Nachtrag zur schriftlichen Anfrage an Adams: Zu [C2SUJK-888] [TTT] Ermittelte Konflikte sind um Trasseninformationen ergänzt sowie bilanziert und b… noch ein paar nachfragen:  (AK 1, zusätzliche Attribute) Konntet ihr mittlerweile klären, welche Zusatzattribute da angefragt werden? Wir werden ja auf jeden Fall für unsere Bilanzierung die zugart brauchen und die pathIDold war angefragt. Noch mehr? Noch in Klärung?  (AK 3, Bewertung von Konflikten): Zunächst eine reine Einstufung nach veART, s. Tabelle im Arbeitsdokument. Seht ihr das auch so? Oder doch eine Vermischung mit der Zugcharakteristik? | Antwort : Zu 1. Wir stehen für die Umsetzung in der AStBau noch im engen Austausch mit Nadine und dem Fachbereich. Es wurde noch nicht entschieden ob und in welchem Umfang wir Trassendaten zu den Konflikten anzeigen sollen. Die Daten zu den Bautrassen liegen bereits in der AStBau vor, dafür benötigen wir also keine Zusatzinformationen von euch. Für eine Unterscheidung wäre es perspektivisch sinnvoll, wenn wir ein Attribut bekommen ob es sich um eine Bautrasse oder eine Regeltrasse handelt. Zu 2. Aus meiner Sicht ist die Unterscheidung nach veART aktuell ausreichend.  | das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eUKAINS-2363 das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eUKAINS-2371 das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eUKAINS-2369 trueRedOFFEN |

| Storys, deren Scope noch finalisiert werden muss |

| Sonstiges:Thema | Einbringende | Detailbeschreibung | Entscheidung | Neues Attribut BBMN-Kennung trueRedOFFEN | Jochen   | In Der AStBau zeigen wir aktuell die "BBMN Kategorie" (Topic bbm.veroeffentlicht "bbmList":"bbmKategorie") an. Dieses soll durch das Attribut "BBMN-Kennung" ergänzt werden. Die Anforderung ist nicht zeitkritisch und wird erst für Fplj 2028 relevant sein.    | Wir sollten uns nochmal zu der Anforderung austauschen eventuell könnte man ein zusätzliche Attribute dirrekt in Scope von C2SUJK-786 mit umsetzen. | BBR-Id  trueGreenfertig | Franziska am   | Können wir das Parsing der BBR-Id entfernen? das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eUKADA-2920 | Leider müssen wir nach einer Email der BVU noch Anpassung am Parsing vornehmen ([UKAINS-1930] Review des Parsen der BBR-ID aus BKE-Verwaltung - DB InfraGO ITD Lifecycle Management Tool). Dies ist in Iteration 39.7 geplant. Erst danach macht es Sinn, dass Adams das Parsing entfernt. Stories sind verknüpft.  Parsing von Team Ains umgesetzt. Aber ich würde von dem Entfernen noch abraten. Wir sprechen am Freitag den 12.03.2026. 27.03.2026: Team Ains prüft nochmals in der Datenbank, ob alte IDs vorkommen. Wenn ja wird nochmals X-12 abgefragt (betrifft nur c2s.bau.bke.fullpublication)). c2s.bau.bke.veroeffentlicht sollte aber jetzt schon korrekt sein. 01.04.2026: Ist im aktuellen Release, der sich momentan auf der SAT befindet. Wird kommenden Mittwoch auf der PROD ausgerollt. Parsing kann von Adams jetzt entfernt werden | bbmIdsForRemoval trueGreenFertig | Franziska am   | Sind die BBM-Ids fahrplanjahrübergreifend eindeutig oder nur im Fahrplanjahr unique? Also insbesondere: Reicht die BBM-Id in bbmIdsForRemoval oder brauchen wir dazu noch das Fahrplanjahr? | Vermutung: BBM-IDs sind eindeutig. Aber wir klären das nochmals mit BBPneo. Ist geklärt, die BBMN-ID sind fahrplanjahrübergreifend eindeutig: 

| KE-Service-Anbindung an RUT-K trueGreenFertig | Franziska am   | In welchen Umgebungen ist der KE-Service an RUT-K angeschlossen? Konkreter: Auf welchen Umgebungen können wir damit rechnen, dass Daten, die die AStBau über den KE-Service bekommt auch in RUT-K vorhanden sind? Also wo sollten RUT-K und AStBau die gleiche Datengrundlage an bVE haben? | Kannst Du bitte die Frage konkretisieren? Worauf bezieht sich Deine Frage? Grundsätzlich ist der KE-Service in fast allen Umgebungen, außer ifp-abn-next, ifp-lup, vorhanden. Bitte prüfen ob Aktualisierung auf der Integration seitens DaViT stattgefunden.  Momentan sind die Daten für BKEn nur auf der Ifp.int-sys zur ITU-TTTneo (IEU TTTneo) synchron. Auf der DaViT-ASS sind die Daten auch synchron, aber keine BKEn im KE-Service Verfügbar.  | "Abnahmetest" der Capability auf der int.sys trueGreenFertig | Marcel am  05.03.2026 | Test von dem Fabian Knöller  gewünscht auf der Ifp.int.sys mit 3 BKE je 2 und 3. KP. Vorbereitung laufen. Komme auf Euch zu. | Testvorbereitung laufen. Termin heute am 26.03.26 16:00 Uhr.  Finaler Abnahmetermin am 02.04.2026 14:00 Uhr - 14:30 Uhr geplant. Möchte jemand von Euch teilnehmen?   zum Termin am 02.04 einladen | Anpassung bbm-API   trueGreenFertig | Sandra | Wir haben die Anpassungen auf unserer Seite durchgeführt Mit welchem Releasae können wir die Änderungen ausliefefern? Von unserer Seite bevorzugt mit L35.1 am 01.04. auf ituTTTneo |   bitte mitnehmen und mit Team besprechen. Ziel ist das Release L35.1 27.03.2026: Noch in Klärung

|