Plattform-Positionierung
ÖPNV-Störungsmanagement auf UDM
Diese Übersicht zeigt, warum UDM gegenüber etablierten BME-Produkten wie NettroBME, INIT RESPONSEassist oder ebblo LIO-IDS strukturell überlegen ist. Sie macht sichtbar, welche Bausteine für ein konkurrenzfähiges Leitstellen-System bereits in der Plattform liegen.
Konfigurierbar statt Custom-Software
VDV-konform
KI integriert
Live-Karte und GIS-Lagebild
Multi-Mandant
Markt und Ausgangslage
Der Markt ist breiter besetzt als gemeinhin angenommen. Sieben relevante Anbieter teilen sich das Feld, von BME-Spezialisten über ITCS-zentrierte Leitsysteme bis zu Auskunfts- und Bahn-Stacks. Alle sind Branchen-Standardprodukte mit festem Datenmodell und Release-Bindung an den Hersteller.
BME-Spezialisten
Nettropolis AG
Bruchsal · ab 1998
Nettro·BME, Nettro·ZEM, Nettro·CMS
Marktführer für BME im deutschsprachigen Raum mit mehr als 30 Verkehrsunternehmen. Klassische Leitstellensoftware, etwa ab 2004 entwickelt, mit kategoriegetriebenen Workflows. Der heutige UDM-Autor hat NettroBME seinerzeit mitentwickelt.
IVU Traffic Technologies
Berlin
IVU.incident, IVU.fleet, IVU.suite
Webbasiert, mit vorkonfigurierten Aufgabenlisten und automatischer Übernahme aus der Leitstelle. Direkte Integration mit IVU.realtime für die Fahrgastinfo. Direkter NettroBME-Konkurrent, technologisch deutlich moderner.
ITCS-zentriert, Bahn/MaaS und Auskunft
INIT SE
Karlsruhe
MOBILE-ITCS nextGen, RESPONSEassist, MOBILEforms
ITCS-zentriert. Seit 2024/25 mit automatischer Fahrgastinfo aus disponierten Maßnahmen, Referenz DB Regio Bus Baden-Württemberg. Form-basierte Bearbeitung mit Handlungsempfehlungen.
ebblo
ehem. Trapeze DE
LIO-IDS mit Störungs-Manager und Ablauf-Manager
Schlägt korrekte Handlungsschritte vor. Der Vorgang bleibt offen, bis alle vordefinierten Aktionen abgeschlossen sind.
PSI Transcom
Berlin
PSItraffic und profahr (ITCS)
Rechnergestützte Betriebsleitsysteme für ÖPNV und SPNV. Mehrmandanten-Leitstelle, Anschlussverkehre, Lademanagement. Referenzen unter anderem bei Veolia/MoveOn und der Verkehrsgemeinschaft Nordvorpommern.
Siemens Mobility / Hacon
München · Hannover
Disruption Management, HAFAS.info, eos.uptrade, Padam, Sqills
Hacon gehört seit 2017 zu Siemens. Eher SPNV- und Fernverkehr-fokussiert, MaaS-Stack mit Disruption-Management-Modul für Bus-/Bahn-Mischbetriebe.
Mentz GmbH
München
DIVA, EFA, EMS und ICS (Incident Capturing System)
Marktführer multimodale Fahrgastauskunft, etwa DEFAS Bayern und NVBW. EMS und ICS reichen Störungsdaten an EFA und den TPEG-Ausgang weiter. Referenz: Stockholm.
Sekundär, nicht BME-Kern
HanseCom aus der INIT-Gruppe (Ticketing), Funkwerk (BOS-Funk und Sicherheit), ZEDAS (Asset und Instandhaltung) sowie SWARCO, COS, Clever Devices (Verkehrsmanagement). Diese Anbieter berühren BME nur tangential.
Gemeinsamer Nenner aller sieben Anbieter. Es handelt sich um Branchen-Standardprodukte mit festem Datenmodell und Release-Bindung an den Hersteller. Keiner ist eine konfigurierbare Plattform für mehrere Apps wie BME, Asset, Schulung, Krise und Ticketing auf einem gemeinsamen Stammdaten-System. Genau hier hat UDM eine strukturelle, nicht nachholbare Position.
Normativer Rahmen. Die VDV-Schrift 722 „Strukturiertes Störungsmanagement" definiert seit 2016 den Prozess von Ereignis über Kategorie und Maßnahme bis zur Fahrgastinfo. Die VDV-Mitteilung 7048 konkretisiert die Praxis. Anschlussstandards sind VDV 452/453/454 und SIRI-SX.
Die etablierten Produkte folgen dieser Logik literal. Der Disponent wählt zuerst die Kategorie, dann führt das System durch eine vordefinierte Checkliste. Diese Lehrmeinung ist heute klar überholbar, mit oder ohne KI.
Produkt für ein Problem oder Plattform für viele Probleme
Der entscheidende Unterschied liegt nicht in der Funktionsliste, sondern in der Bauart.
Die drei strukturellen Unterschiede
Wettbewerber verkaufen ein Produkt für ein Problem. UDM verkauft eine Plattform für viele Probleme, in der BME die erste App ist.
Bauart
Generische, konfigurationsgetriebene Plattform. Entitäten, Datenquellen, Views, Dialoge, Aktionen und Berechtigungen sind Konfiguration. BME ist eine App unter vielen.
Datenhoheit
System- und App-Trennung mit Multi-Provider. Die Stammdaten (Linien, Fahrzeuge, Personal, Haltestellen) leben im Subsystem. Mehrere Apps wie BME, Asset, Schulung und Krise teilen sie sich. Datenquellen sprechen SQL Server, MariaDB und weitere Provider.
Erweiterungsmodell
Anpassung in Minuten statt Releases. Der Hauptadmin des VU baut Felder, Listen und Workflows selbst im AdminClient. Mit QuickConfig auch live im UserClient. Plattform-Releases statt Anpassungs-Releases.
BME-Anforderungen auf UDM-Bausteine abgebildet
Etwa 85 Prozent der Funktionsliste eines BME-Wettbewerbers sind in UDM bereits horizontal abgebildet. Nicht für BME gebaut, sondern weil jede UDM-App diese Bausteine erbt.
| BME-Anforderung |
UDM-Baustein |
Reifegrad |
| Kategorisierte Meldungserfassung mit Pflichtfeldern je Typ | Entitäten, Datenquellen, ColumnConfig-Vererbung (Entity, DS, VE), Dialog-Designer, Element-Settings mit Guid-Referenzen | Impl. |
| Dynamische Checklisten und strukturierte Bearbeitung | Dialog-Designer, UdmActions, DynamicCode, Form-Element-Manager und Subdialoge mit Live-Change-Notification | Impl. |
| Maßnahmenkatalog und Workflow | UdmActions mit reaktivem Binding, CanExecuteAction, SetCondition und Berechtigungen | Impl. |
| Berechtigungen je Bereich, Rolle, Halt oder Linie | Permission-Filter-Resolution mit Boolean-Tristate sowie CompanyRole- und CompanyDivision-User-Filter | Impl. |
| Gerichtsfeste Dokumentation | Versionierung, Auto-History und Plattform-Audit | Teilimpl. |
| Leitstellen-Dashboards | DynamicMatrix-VE (V1, serverseitige Pipeline), Gauge/KPI V2 (6 Modi), Charts | Impl. |
| Echtzeit und Multi-User in der Leitstelle | Live-Change-Notification, Filter-Refresh und Karten-Refresh | Impl. |
| Eskalations- und Nachrichtenketten | UdmActions, Background-Services und SendMessage-Executor | Konzept |
| ITCS- und VDV-Schnittstellen | VDV 452 Import (Phase 1 da), VDV 453/454/SIRI auf gleicher Pipeline | Teilimpl. |
| KI-Unterstützung für Klassifikation, Texterzeugung und Vorschlag | KI-Assistent, Subdialog-Tool, KI-Datenimport und Eval-Framework mit 25 Tests, Multi-Turn und Prompt-Caching | Impl. |
| Fahrgastinfo-Templates aus Maßnahme | Element-Mapping mit FieldMappings und Wertquellen, Versionierung und UdmAction-Output | Impl. |
| Multi-Mandanten für Verbund oder Subunternehmer | CompanyDivision-Baum (siehe Kunden-Portal-Showcase) | Impl. |
| DSGVO und Retention | Konzept mit PII-Flag, Löschjob, Protokoll und Retention | Konzept |
| Karten-View mit Live-Vehicle-Tracking | WFS-Layer-Integration, Linienverläufe (transit_shapes_with_routes) und AI Entity-Tools. Produktiv für die VBK Karlsruhe ausgeliefert. | Impl. |
Architektur-Schichten: App „BME" auf UDM
Plattformkerne sind nicht App-eigene Module. Asset-, Schulungs-, Krisen- und Ticketing-Apps nutzen sie mit. NettroBME muss diese Schichten pro Modul nachbauen.
UserClient (Leitstelle)
Live-Dashboard
Meldungsformular
Karte mit Live-Fahrzeugen
Maßnahmen-Tab
DFI-Vorschau
Eskalations-View
App: BME
Dialoge für Meldung, Maßnahme, Eskalation und Vorlage. Views als Liste, Karte, Matrix, Gauges und Timeline. Aktionen als Maßnahmenkatalog mit Bedingungen und Berechtigungen. Filter für Bereich, Linie und Schicht im Tristate-Modus.
System: ÖPNV-Stammdaten
Entitäten: Linie, Halt, Fahrzeug, Personal, Bereich, Meldungstyp, Maßnahmentyp, Empfängergruppe, Vorfall und Bearbeitungsschritt.
Datenquellen: ITCS-Live über VDV 453/454/SIRI, Asset-Datenbank, Personalplan, DFI-Kanäle und WFS.
ColumnConfig-Vererbung über alle Views.
Plattformkerne (transversal, alle Apps)
Berechtigungen
Versionierung
KI-Assistent
Audit
Background-Services
Live-Change-Notification
DSGVO
„Klüger und moderner": was UDM heute schon erfüllt
Aus dem IT-Incident-Management (Rootly, incident.io, PagerDuty, Cutover) sowie aus aktueller Forschung kommen vier Trends, die im ÖPNV-Markt noch nicht angekommen sind. UDM trägt sie architektonisch bereits.
Signal-getrieben statt Kategorie-getrieben
Beim Wettbewerb wählt der Disponent zuerst die Kategorie, dann die Checkliste. Bei UDM ist die Datenquelle eine generische Event-Quelle. ITCS-, Sensor- und Funk-Anbindungen passen auf dasselbe Schema. Der Workflow ist eine Action-Komposition, kein starrer Kategoriebaum. Die Kategorie wird zum Attribut, nicht zur Voraussetzung.
Dynamische Checklisten als Komposition
Beim Wettbewerb gibt es eine feste Checkliste pro Kategorie. Bei UDM setzen sich Checklisten aus Aktions-Bausteinen zusammen: Fahrer informieren, Anschluss prüfen, DFI-Text senden, an BOS melden. Jeder Baustein trägt eigene Bedingungen. Der Kontext aus Linie, Tageszeit und Bereich bestimmt die Zusammenstellung.
Nachrichtenketten als eigene Domäne
Beim Wettbewerb sind Verteiler statisch pro Kategorie. Bei UDM werden Empfänger und Kanäle über Rollen, Bereitschaftspläne und SLA-Regeln aufgelöst. Eskalations- und Quittungs-Logik folgen dem PagerDuty-Modell. Die Bausteine sind vorhanden, der SendMessage-Executor ist noch ein Stub.
KI als Co-Pilot, nicht als Klassifikator
Beim Wettbewerb stehen KI-Funktionen meist nur auf der Roadmap. Bei UDM sind KI-Assistent, Subdialog-Tool und KI-Datenimport bereits Plattform. Aus einer Freitextmeldung schlägt das System Maßnahmen, Severity und Fahrgasttext vor. Das Eval-Framework misst die Qualität kontinuierlich.
Maßnahme schreibt Fahrgastinfo
INIT macht es bereits seit 2024/25. UDM trägt es ebenfalls. Jede Maßnahme führt Templates für DFI, Web, App und Social über das Element-Mapping mit Wertquellen. Der Disponent disponiert, die Fahrgastinfo wird daraus deduziert und freigegeben.
Event-Sourcing und gerichtsfeste Dokumentation
Beim Wettbewerb gibt es einen Workflow-Status pro Ticket und ein Audit-Log nebenher. Bei UDM sind Versionierung und Auto-History Plattform. Der Vollausbau zu Event-Sourcing ist ein Plattform-Refinement, kein BME-Feature.
GIS-Ereignis-Lagebild für ÖPNV mit Live-Fahrzeug-Tracking
Eine zweite App auf demselben System-Stamm. Live-Fahrzeugpositionen, Aufzüge an U- und Stadtbahn-Stationen, defekte DFI-Anzeiger, gestörte LSA-Bevorrechtigung, Wetter und Baustellen liegen alle auf einer Karte. Genau die Aufgabe, für die heute drei separate Tools im Browser-Tab offen sind.
Live-Fahrzeug-Tracking ist bereits produktiv ausgeliefert. Für die VBK Karlsruhe haben wir WFS-Layer-Integration, Linienverläufe (transit_shapes_with_routes) und AI Entity-Tools gebaut. Die Karte ist ein Plattformbaustein und kein BME-Spezialmodul, jede UDM-App kann sie nutzen. Das ist die Basis-Schicht des Lagebilds; die Ereignis-Quellen werden als weitere Layer darübergelegt.
Datenquellen für Ereignis-Layer nach Beschaffbarkeit
Offen verfügbar
Demo-tauglich, ohne Kundenvertrag:
- VBB/BVG Aufzugs-Feed für Berliner U- und S-Bahn-Aufzüge mit Geo-Daten über RSS und REST
- MVG für Münchner U-Bahn-Aufzüge und Rolltreppen
- brokenlifts.org als aggregierte Historie von Sozialhelden e.V.
- DELFI und opendata-oepnv.de für GTFS-RT Service-Alerts bundesweit
- Mobilithek mit SIRI-SX für Verbund-Disruptions
- DWD Open Data für Wetterwarnungen im CAP-Format
Pro Kunde freischalten
VU-intern oder kommunal verhandelbar:
- VDV 453/454 für Soll- und Ist-Daten sowie Live-Fahrzeug-Positionen aus dem hauseigenen ITCS
- VDV 736 und SIRI-SX intern für ITCS-Störungen
- OCIT-C der kommunalen LSA für die LSA-Bevorrechtigung
- DFI-Anzeiger-Status über Lumino, Brandmaier, Annax, Aesys oder TeleMATRIK
- VU-eigene Aufzugs-Wartungsverträge für OEM-Freischaltung
- Fahrzeug-Status für Bordrechner, Klima oder Tür über das ITCS
OEM-vertragspflichtig
Nur über den Wartungsvertrag des Aufzug-Eigentümers:
- Schindler Ahead
- KONE 24/7 Connected
- Otis ONE
- TK Elevator MAX
Im ÖPNV ist der Eigentümer typischerweise das VU oder die Stadt. Die Daten sind also in greifbarer Nähe, müssen aber per Auftrag freigeschaltet werden.
ÖPNV-spezifisches Killer-Argument: LSA-Bevorrechtigung. Eine defekte Vorrang-Schaltung kostet Tram und Bus pro Knoten 30 bis 90 Sekunden. Die Quelle ist OCIT-C der städtischen Verkehrsleitzentrale zusammen mit den R09-Telegrammen aus dem ITCS. Wettbewerber wie Nettro-ZEM, IVU.incident oder ebblo LIO-IDS zeigen Ereignisse, aber keiner bringt die LSA-Bevorrechtigungs-Performance dediziert auf den Schirm. UDM kann das über die generische Ereignis-Pipeline, die Asset-Verknüpfung (LSA als Asset) und die DynamicMatrix-Auswertung abbilden. Die Live-Fahrzeuge sind direkt daneben sichtbar.
Connector-Architektur
GIS-View „Lagebild" mit Layer-Toggle pro Quelle
Live-Fahrzeuge (VBK-Stack)
Linienverläufe
Aufzug
LSA-Vorrang
DFI
Wetter
Baustellen
manuelle Meldung
App „Ereignis-Lagebild ÖPNV"
Ereignis-Datenmodell mit Quelle, Severity, Geo, Zeit und Asset-Referenz. Maßnahmen-Workflow mit den Bausteinen der App „BME". Filter für Bereich, Linie und Schweregrad. Auswertung über die DynamicMatrix.
Connector-Schicht über UDM-Background-Services
VDV 453/454 Live-Fzg (VBK)
VBB/BVG
DELFI-RT
DWD
VDV 453/454 weitere VU
OCIT-C
DFI-Hersteller
OEM-Lift
manuelle Erfassung im UserClient
Demo in zwei Stufen
Wiederverwendung statt Neubau. Diese App teilt sich mit der BME-App das Stammdaten-Subsystem (Halt, Linie, Fahrzeug, Bereich), die Berechtigungs-Logik, den KI-Assistenten und die Live-Karte aus dem VBK-Stack. Was hinzukommt, ist die Connector-Schicht. Davon sind die ersten drei Adapter für VBB/BVG, DELFI-RT und DWD reine Programmierarbeit gegen offene REST-Endpoints.
Was UDM ehrlich noch fehlt
Transparenz statt Marketing. Diese Bausteine sind in Wettbewerbern vorhanden, in UDM noch nicht oder nur teilweise. Alle sind absteckbare Plattform-Erweiterungen, keine architektonischen Hindernisse.
| Lücke |
Bewertung |
Nächster Schritt |
| VDV 453/454-Live-Adapter | Konsument konzeptionell vorhanden, kein Live-Connector | Plattform-Feature als Folge aus vdv-452-import |
| SIRI-SX Out | Für die Fahrgastinfo-Verteilung nach außen | Schnittstellen-Aufgabe, gut absteckbar |
| Notification-Engine als first-class Plattform-Feature | Heute Action- und Background-Service-Pattern, kein dedizierter Dispatcher mit Quittung, Eskalation und Retry-Policy | Plattform-Feature mit gleichem Bedarf in incident-ticketing |
| BOS-Funk und SCADA-Adapter | Pro VU eine Integrationsaufgabe | Connector pro Kunde |
| Predictive-Maintenance-ML-Modelle | Das Datenmodell trägt es, die ML-Pipeline ist nicht Teil der Plattform | Optional, kein BME-Kernbedarf |
| Live-Karte als generischer Plattformbaustein | Der VBK-Stack ist produktiv, eine Generalisierung ist sinnvoll | Eigener Showcase „Karte als Plattformbaustein" |
Vertriebs-Botschaft
Ein VU, das heute auf NettroBME, IVU.incident, INIT RESPONSEassist, ebblo LIO-IDS, PSItraffic, Siemens Disruption Management oder Mentz EMS sitzt, kauft ein Produkt für ein Problem. Auf UDM kauft es eine Plattform für viele Probleme, in der die erste App BME ist. Die zweite App ist die Schulungsverwaltung, die dritte das Asset-Management, die vierte das Krisenmanagement. Jede teilt sich Stammdaten, Berechtigungen, Versionierung, Audit, KI-Assistent und Echtzeit-Stack.
01
Time-to-Customizing
Ein neuer Meldungstyp, eine neue Maßnahme oder eine neue Eskalationskette ist beim VU-Hauptadmin in Minuten konfigurierbar. Bei Wettbewerbern bedeutet das ein Hersteller-Ticket, ein Customizing-Projekt und einen Release-Zyklus.
02
Datenhoheit
Die Stammdaten gehören dem VU, nicht dem Hersteller. Die Migration zwischen Datenbank-Providern ist ein Konfigurations-Projekt, kein Migrations-Projekt. Möglich on-prem, in der Cloud oder hybrid.
03
KI ist bereits drin
Kein „KI-Add-on V2", sondern integrierter Bestandteil der Plattform inklusive Eval-Framework. Subdialog-Tool und KI-Datenimport sind ausgeliefert.
Glaubwürdigkeits-Brücke. Der Autor von NettroBME baut heute UDM. Die Plattformschicht, die in NettroBME architekturbedingt fehlt, ist in UDM von Anfang an die Basis. Das ist ein Vertriebsargument, das kein Wettbewerber kopieren kann.
Empfohlenes Showcase-Setup für die Demo
Vier Schritte, die einen Wettbewerber-Vergleich in der Demo entscheiden. Mit echten Daten aus dem VBK-Stack.
1
System „ÖPNV-Stammdaten" aufsetzen
Ein Mini-Datenmodell aus dem VBK-Showcase mit 5 Linien, 30 Haltestellen, 10 Fahrzeugen und 20 Personalrollen. Eine Read-only-Schnittstelle reicht für die Demo.
2
App „BME" konfigurieren
Drei Dialoge für Meldung, Maßnahme und Eskalation. Zwei Listen mit offenen Störungen und Tagesreport. Eine Matrix mit Störungen je Linie und Tag. Eine Karte mit Live-Positionen und überlagerten offenen Störungen.
3
End-to-End-Workflow vorführen
Ein ITCS-Event wird simuliert, der Live-Eintrag erscheint. Der KI-Assistent schlägt eine Maßnahme vor, der Disponent bestätigt. Daraus wird ein DFI-Text generiert und an die Kanäle verteilt, die Quittung kommt zurück. Dauer: unter zwei Minuten.
4
Killer-Argument: Live-Anpassung während der Demo
Im AdminClient wird ein neues Pflichtfeld am Meldungstyp angelegt. Es ist sofort in der Leitstellen-App sichtbar. Bei Wettbewerbern unmöglich ohne Release. Genau das ist der Moment, der die Verkaufsentscheidung kippt.
Hinweis. Dieses Dokument ist ein Positionierungs-Showcase, keine Produktbeschreibung eines fertigen BME-Moduls. Die genannten UDM-Bausteine sind entweder produktiv (Reifegrad „Impl.") oder konzeptionell ausgearbeitet (siehe Mapping-Tabelle). Eine konkrete BME-Umsetzung entsteht über das Showcase-Setup nach Abschnitt 10.
Verwandte Dokumente. oepnv-analyse (Markt und Branche), incident-ticketing (Ticket-Datenmodell als Blaupause), customer-portal-ticketing (Multi-Mandanten-Modell) und dienstplan-showcase-vbk (bestehender VBK-Showcase).