Testen hoch 10 - Für den Bahnverkehr der Zukunft
Denunciar
Compartilhar
•0 gostou•72 visualizações
Testen hoch 10 - Für den Bahnverkehr der Zukunft
•0 gostou•72 visualizações
Denunciar
Compartilhar
Baixar para ler offline
Testen von Software, die komplexe Situation real-time lösen muss, die auf unscharfen Regeln basiert und die Erfahrung, Intuition und Bauchgefühl ersetzen soll – ist das überhaupt möglich? Nach unseren Erfahrungen: "Nicht vollständig". Aber am Swiss Testing Day zeigten Roman Caspar und ich, wie wir versuchen, beim Testing das Optimale herauszuholen – für den Bahnverkehr der Zukunft
Recomendados
Mais conteúdo relacionado
Similar a Testen hoch 10 - Für den Bahnverkehr der Zukunft
Similar a Testen hoch 10 - Für den Bahnverkehr der Zukunft(20)
Mais de Christoph Wolf
Mais de Christoph Wolf(7)
Testen hoch 10 - Für den Bahnverkehr der Zukunft
- 1. 1 Roman Caspar, SBB Christoph Wolf, SwissQ Consulting AG Swiss Testing Day 2021 Testen hoch 10 - Für den Bahnverkehr der Zukunft
- 2. SBB – Testen hoch 10 – Für den Bahnverkehr der Zukunft – Swiss Testing Day 2021 2 Bahnverkehr der Zukunft Rail Control System (RCS) Real-Time Optimization (RTO) Testen hoch 10 bei RTO Erfolgsfaktoren 1. Automatisierte Unit-Tests 2. Manuelle Feature-Test 3. Release-Stabi 4. Systemtest 5. Abnahmetest 6. Testframework 7. Labortest 8. Live-Test 9. Pilot 10. Reproduktion von Situationen Agenda
- 4. SBB – Testen hoch 10 – Für den Bahnverkehr der Zukunft – Swiss Testing Day 2021 4 Erhöhung Stabilität und Robustheit des Fahrplans Effizienzsteigerungen im Kapazitätsmanagement und im Bahnbetrieb insbesondere durch Automatisierung Steigerung Zufriedenheit der Bahnkunden SBB Infrastruktur: Schwerpunkte für die Zukunft (Auswahl)
- 7. Fahrplan Leitsystem Stellwerk Weichen, Signale, Sicherungsanlagen RCS Fahrplan Betriebslage Prognose Konflikterkennung Disposition GUI Disposition 2 vor 1 Disposition 1 vor 2 Fahrweg-Disposition Zug 2 Nach Fahrplan Zug 1 Zug 2 Konflikt Zug 1 Zug 2 ? ? Rail Control System SBB – Testen hoch 10 – Für den Bahnverkehr der Zukunft – Swiss Testing Day 2021
- 8. SBB – Testen hoch 10 – Für den Bahnverkehr der Zukunft – Swiss Testing Day 2021 8 Disposition ist eine schwere Aufgabe …
- 10. Leitsystem RCS Disponent Disposition Fahrdienstleiter Bisher GUI GUI SBB – Testen hoch 10 – Für den Bahnverkehr der Zukunft – Swiss Testing Day 2021 10 ! Leitsystem Fahrdienstleiter DispoOp GUI RCS Disponent In Zukunft RTO Disposition GUI ! Zugsteuerung mit RTO
- 11. Fahrweg-Alternativen Dispositionen SBB – Testen hoch 10 – Für den Bahnverkehr der Zukunft – Swiss Testing Day 2021 11 Prognose Optimierung RTO-Module
- 12. SBB – Testen hoch 10 – Für den Bahnverkehr der Zukunft – Swiss Testing Day 2021 12 Komplexität bei Fahrwegen und Reihenfolgen
- 13. Erfahrung & Bauchgefühl Regeln Reproduzierbarkeit Testdaten Testumgebung Komplexität Robustheit SBB – Testen hoch 10 – Für den Bahnverkehr der Zukunft – Swiss Testing Day 2021 13 RTO: Herausforderungen
- 14. Testen hoch 10 bei RTO
- 15. SBB – Testen hoch 10 – Für den Bahnverkehr der Zukunft – Swiss Testing Day 2021 15 Test bzw. Testtool Verantwortlicher «Standard» Automatisierte Unit-Tests Entwickler Manuelle Feature-Tests Tester Release-Stabi Release-Management Systemtest Tester Abnahmetest Anwendervertreter «Speziell» Testframework Tester Labortest Anwendervertreter Live-Test Anwendervertreter/Anwender Pilotbetrieb Anwendervertreter/Anwender Reproduzieren von Situationen Entwickler, BA Tests in RTO
- 16. SBB – Testen hoch 10 – Für den Bahnverkehr der Zukunft – Swiss Testing Day 2021 16 Modell- definition Modell- Bahnnetz Optimierungs- gebiet Zugfahrt Erwartetes Ergebnis RCS/RTO Test- framework Infrastruktur aufbauen Gebiet definieren Zugfahrt einplanen Ergebnis überprüfen Test- durchführung Testframework
- 17. Testframework SBB – Testen hoch 10 – Für den Bahnverkehr der Zukunft – Swiss Testing Day 2021 17 Zugfahrten Erwartetes Ergebnis Modell- Bahnnetz Optimierungs- gebiet
- 18. SBB – Testen hoch 10 – Für den Bahnverkehr der Zukunft – Swiss Testing Day 2021 18 Anwendervertreter testen Situationen mit einem RTO-Entwicklungssystem. Geeignet für … testen von neuen Features und interessanten Konstellationen. ausprobieren einer neuen Zielfunktion bzw. Konfiguration. Aber ... Dispositionen können durch das Produktionssystem überschrieben werden. die Realität (Betriebslage) gewinnt immer. Daher nicht geeignet für … testen von Spätfolgen der RTO-Dispositionen. Labortests
- 19. SBB – Testen hoch 10 – Für den Bahnverkehr der Zukunft – Swiss Testing Day 2021 19 Beobachtung von RTO-Dispositionen im realen Bahnverkehr durch … Verbindung eines RTO-Integrationssystems mit dem produktiven Leitsystem .. mit enger Begleitung von … Anwendervertretern Disponenten & Fahrdienstleitern Ausserdem: Simulation mit … hinzugefügten Zügen manuellen Störungen provozierten Verspätungen Live-Tests (in Betriebszentralen)
- 20. SBB – Testen hoch 10 – Für den Bahnverkehr der Zukunft – Swiss Testing Day 2021 20 RTO ist in einem Gebiet aktiv. Disponenten und Fahrdienstleiter beobachten und greifen, falls nötig, ein. Befunde werden sofort dokumentiert. Befunddiskussion jede Woche. Reproduzieren der Befunde. Pilotbetrieb (Produktion)
- 21. SBB – Testen hoch 10 – Für den Bahnverkehr der Zukunft – Swiss Testing Day 2021 21 Sicherung der Ausgangssituation eines jeden Optimierungslaufs. Über 10’000 abgespeicherte Situationen pro Tag Detaillierte Analyse der Optimierung Beantwortet: Wieso? Wie besser? Reproduzieren von Situationen
- 22. Erfolgsfaktoren
- 23. SBB – Testen hoch 10 – Für den Bahnverkehr der Zukunft – Swiss Testing Day 2021 23 Enge Zusammenarbeit mit Anwendervetretern, die viel Erfahrung haben Enge Begleitung der Anwender in den Betriebszentralen Schnelles Feedback ( > > > > … > ) Detaillierte Erkenntnisse aus dem produktiven Betrieb ( ) «Beweise» für korrekte Arbeitsweise von RTO ( ) Ursachen für «schlechte» Dispositionen ( ) Testen einer geänderten Konfiguration mit Testdaten aus konkreten Situationen ( ) Reduktion der Komplexität ( ) Simulationen mit einfachen Testdaten ( ) Erfolgsfaktoren
- 24. 24 Danke, merci & grazie. Roman Caspar Product Owner SBB Christoph Wolf Business Analyst SwissQ
Notas do Editor
- Begrüssung: Roman Caspar, Product Owner RTO bei der SBB. Christoph Wolf von SwissQ, Business Analyst in einem RTO-Team bei der SBB.
- Wir werden euch zuerst kurz einige Ziele bezüglich des Bahnverkehrs der Zukunft vorstellen. Dann erklären wir, soweit es für das weitere Verständnis des Vortrags nötig ist, was das Rail Control System macht, wie die Real-Time Optimization des Bahnverkehrs funktioniert und welche Herausforderungen wir haben. Wir zeigen dann, wie wir im beim Testen der Real-Time Optimization vorgehen. Von den 10 Punkten, die hier aufgeführt sind, gehen wir aber nicht auf alle, sondern nur auf die interessanten näher ein. Zum Abschluss diskutieren wir dann noch die Erfolgsfaktoren bezüglich Testen von RTO. [Timing: Intro + Agenda: 3 Minuten RCS/RTO: 8 Minuten Testing: 11 Minuten Erfolgsfaktoren + Abschluss: 2 Minuten]
- Starten wir mit den Zielen des Bahnverkehrs der Zukunft.
- Hier sind einige Schwerpunkte für den Bereich Infrastruktur der SBB. Unser System RTO trägt vorwiegend zur Effizienzsteigerung im Kapazitätsmanagement und im Betrieb bei. Natürlich erhoffen wir uns dadurch eine höhere Fahrplanstabilität und damit auch eine Steigerung der Kundenzufriedenheit.
- Kommen wir nun zum Rail Control System RCS, einem der zentralen Systeme für den Bahnbetrieb.
- Hier ist das Gebiet um Olten, unser erstes Optimierungsgebiet. In dem Fenster auf der linken Seite sieht man, wo sich ein Zug gerade befindet, das ist die Betriebslage . Weiterhin kann man sich dort anzeigen lassen, wo sich ein Zug, hier der InterRegio 25 Bern-Zürich wahrscheinlich demnächst befinden wird. Dies sieht man auch auf der rechten Seite für alle Züge in einem Gebiet. Basis für diese Ansicht ist der Fahrplan. Wenn sich aber z.B. ein Zug verspätet oder es auf dem Bahnnetz Probleme gibt, werden die Züge neu berechnet. Das macht die Prognose.
- Basierend auf dem Fahrplan, den RCS einen Tag im Voraus bekommt, und der Betriebslage, erstellt RCS alle 2 Sekunden eine Prognose für fast die ganze Schweiz, wo sich Züge in den nächsten Stunden befinden werden. Angenommen 2 Züge sollen in 2 Minuten Abstand das gleiche Gleis benutze, dann ist das kein Problem: Der erste Zug fährt über das Gleis. 2 Minuten später ist das Gleis frei und der zweite Zug kann fahren. Falls jetzt der erste Zug zwei Minuten Verspätung hat, erkennt RCS einen Konflikt und zeigt ihn an (Ausrufezeichen auf dem Bild). Dieser Konflikt kann nun von einem Disponenten auf mehrere Arten gelöst werden, durch sogenannte Dispositionen: Man kann eine Reihenfolge-Disposition machen: Zug 1 wartet und Zug 2 fährt , dadurch bleibt Zug 2 pünktlich, die Verspätung von Zug 1 wird grösser. Oder Zug 2 wartet und Zug 1 fährt, dadurch haben beide Züge etwas Verspätung. Eine andere Möglichkeit ist eine Fahrweg-Dispositionen: Ein Zug wird auf ein anderes, paralleles Gleis geleitet, macht also eine Fahrwegänderung. Dadurch vergrössert sich die Verspätung nicht. Beim parallelen Gleis könnte es aber dann wieder zu einem Konflikt mit einem weiteren Zug kommen, was beachtet werden muss. Die Disposition muss nun noch über das Leitsystem an das Stellwerk weitergegeben werden.
- Kennt ihr das, wenn Euer Zug plötzlich auf freier Strecke warten muss, für euch ist nicht ersichtlichen, weshalb? Oder wenn Euer Zug minutenlang ziemlich langsam unterwegs ist, eventuell hinter einem Güterzug. Bei all diesen Fällen, habt ihr vermutlich eine Entscheidung der Disposition miterlebt. Bei «Planverkehr» muss keine Disposition durchgeführt werden. Dann läuft alles wie schon lange im Voraus geplant ab. Dies ist der ideal Fall. Bei Verspätungen oder grösseren Störungen ist ein Eingreifen der Disponenten unumgänglich. Bei allen Entscheidungen muss der Disponent das Funktionieren des Gesamtsystem im Blick haben – und alle Entscheidungen danach ausrichten, damit der Zugverkehr möglichst schnell wieder planmässig verkehrt. Denn jede Entscheidung hat oft weiter Konflikte zur Folge.
- Und bei diesen Dispositionen soll RTO unterstützen. Hier sieht man einen Fahrdienstleiter bei seiner Arbeit in der Betriebszentrale Olten. Rechts sind 4 Bildschirme für das Rail Control System, links 6 Bildschirme für das Leitsystem. Der Fahrdienstleiter überträgt die Dispositionen, die ein Disponent in RCS gemacht hat, in das Leitsystem. Dieses steuert dann über das Stellwerk Signale und Weichen, damit die Disposition umgesetzt wird.
- Damit sind wir bei der bisherigen Arbeitsweise: Ein Disponent bearbeitet die von RCS angezeigten Konflikte und macht Dispositionen. Diese werden vom Fahrdienstleiter manuell ins Leitsystem übertragen. Mit RTO unterstützen wir den Disponenten und Fahrdienstleiter in bestimmten Gebieten. RTO löst die Konflikte auf und disponiert die Lösung automatisch über ein weiteres neues System, DispoOp, im Leitsystem. Der Disponent und Fahrdienstleiter überwachen die Dispositionen von RTO und greifen, falls notwendig, ein.
- Wie macht das RTO? RTO besteht hauptsächlich aus 2 Modulen: Eines berechnet für alle Züge, die in den nächsten 30 Minuten im Optimierungsgebiet fahren, alternative Fahrwege auf Vorrat. Diese können dann bei der eigentlichen Optimierung für Fahrwegänderungen verwendet werden. Die alternativen Fahrwege werden nach gewissen Regeln bewertet und somit priorisiert. Da wir z.B. Linksverkehr auf dem Bahnnetz haben, wird ein Fahrweg, der weit nach rechts geht, schlechter bewertet. Die eigentliche Optimierung basiert auf der Prognose und der darauf aufbauenden Konflikterkennung. Die Optimierung erzeugt sich bei Konflikten einen Suchbaum, bei dem sie an jedem Knoten eine Fahrwegänderung oder eine Reihenfolgedisposition machen könnte. Dann berechnet die Optimierung innerhalb von 5 Sekunden aus den vielen Tausend Möglichkeiten diejenige, die eine Zielfunktion optimiert. In die konfigurierbare Zielfunktion fliessen mehrere Kriterien ein, z.B. der Gesamtverspätung aller Züge im Gebiet. Darauf erzeugt RTO die Dispositionen, die nötig sind, um die optimale Lösung umzusetzen. Diese werden dann wieder von der Prognose verarbeitet. Falls eine Fahrwegänderung disponiert wurde, d.h. ein Zug auf ein anderes Gleis fährt, werden neue Fahrwegalternativen für diesen Zug berechnet.
- Eine grosse Herausforderung ist die Komplexität. Oben sieht man z.B. die Gleise für die Einfahrt in den Bahnhof Zürich, der ganz rechts zu sehen ist. Die Bilder unten geben einen Eindruck, wie viel Züge sich im System befinden. Jeder dieser Züge hat einige Fahrwegalternativen und bei je zwei Zügen gibt es zwei Möglichkeiten zur Reihenfolgedisposition. Dies führt zu mehreren Tausend Optimierungsvarianten pro 5-sekündigem Rechenlauf.
- Neben der Komplexität ist die Definition der Zielfunktion, die RTO sagt, was die optimale Lösung ist, eine weitere Herausforderung. Es ist sehr schwierig, das Bauchgefühl von Disponenten, das auf ihrer langjährigen Erfahrung beruht, in Regeln zu übertragen. Es kommt auch öfters zu Diskussionen über die Robustheit der Entscheidung von RTO: Was könnte demnächst passieren? Eine Fahrwegänderung könnte zurzeit gut aussehen. Falls es aber zu einer weiteren Zugverspätung kommt, könnte diese Fahrwegänderung grosse Verspätungen nach sich ziehen. Damit kommen wir zu der Testumgebung: Wie gut die Dispositionen von RTO sind, sieht man oft erst im laufenden Betrieb auf dem realen Bahnnetz. Und dafür gibt es keine Testumgebung. Weiterhin ist jede Situation auf dem Bahnnetz anders. Was in einer Situation funktioniert hat, kann in einer leicht veränderten anderen Situation zu einer schlechten Lösung führen. Daher ist es schwierig, ausreichend künstliche Testdaten zur Verfügung zu stellen. Für die Diskussionen, ob ein Entscheidung in einer Situation von RTO gut war oder nicht und wie wir die Regeln verbessern können, ist es auch wichtig, diese Situation reproduzieren zu können um genau zu sehen, was RTO warum entschieden hat und um eine neue Zielfunktion zu überprüfen.
- Wie gehen wir diese Herausforderungen an? Im Bereich Testing zeigen wir euch nun unsere Lösungsansätze.
- Auf die oberen 5 Tests werde ich nur kurz eingehen, da sie nichts besonderes sind. Wir nutzen Jenkings als Build-Tool, damit werden automatisierte Tests, die in Java geschrieben sind, ausgeführt. Continuous Integration: Bei Commit in Git > macht Jenkins Build > Java-Tests Für manuellen Tests, die von unseren Testern in den Teams gemacht werden, nutzen wir Xray for Jira als Testmanagement-Tool. Die Release-Stabi ist die erste Phase eines Release-Tests. Das Testsystem läuft parallel zum Produktionssystem und bekommt die gleichen Daten wie z.B. Fahrplan oder Betriebslage. Selbst die Dispositionen, die auf dem Produktionssystem gemacht werden, werden übertragen. Ziel ist es festzustellen, ob ein neues Release rund läuft. Dann kommen im Release-Test noch der Systemtest und der Abnahmetest. Kommen wir nun zu den Tests und Testtools, die speziell für RTO sind: Wir haben ein Testframework entwickelt, das von unseren Testern genutzt wird. Dann führen Labortests, Live-Tests und den Pilotbetrieb durch, bei denen Anwender mit RTO arbeiten. Zusätzlich haben wir noch die Möglichkeit, interessante Situationen aus dem Betrieb zu reproduzieren. Diese Sachen werde ich nun näher erläutern.
- Das Schweizer Bahnnetz ist gross und es ist teuer, dort Züge für Tests fahren zu lassen. Weiterhin ändert sich durch Baumassnahmen das Bahnnetz laufend, wodurch Tests dann eventuell unbrauchbar werden könnten. Daher haben wir für einige Tests, z.B. für Fahrwegalternativen, ein abgespecktes Bahnnetz definiert und simulieren darauf Zugfahrten für Testzwecke. RCS hat ein eigenes internes Modell für das Bahnnetz mit all seinen Komponenten und für Zugfahrten. Daher brauchen wir ein Testframework, um unser Modell in eine Form zu übersetzen, die RCS und RTO verstehen. Ablauf der Tests mit dem Testframework: Bahnnetz übersetzen, d.h. die RCS-Instanz arbeitet auf dem Modell-Bahnnetz Gebietsdefinition übersetzten Zugfahrten übersetzten Test durchführen Ergebnis mit dem erwarteten Ergebnis vergleichen Tests mit dem Testframework werden nicht bei jedem Commit durchgeführt, sondern jede Nacht bei einem Extra-Build
- Das Modell-Bahnnetz definieren wir grafisch. Es wird dann in GraphML abgespeichert, ein XML-Format zur Repräsentation von Graphen. Diese wird dann vom Testframework in ein Bahnnetz, das RCS versteht, transformiert. Hier sieht man z.B. die Definition eines Einfahrts-Signals in den Bahnhof «Oberon». Darunter ist die Definition des Optimierungsgebiets mit Signalen. Dann kommt die Zugfahrt, die durch einen Pfad in dem Graphen beschrieben. Dieser Zug fährt z.B. über Gleis 4 des Bahnhofs Oberon. Rechts unten sieht man eine Fahrwegalternative, die für eine Zugfahrt berechnet werden sollte. Falls sie nicht in den berechneten Fahrwegalternativen vorhanden ist, schlägt der Test fehl. Mit etwas Übung ist es mit dem Testframework möglich, recht schnell Testfälle für spezielle Situation zu erstellen. Nach diesem recht technischen Test kommen wir nun zu den Tests, die von Anwendern durchgeführt werden …
- Es geht los mit Labortests. Testen von neuen Features und interessanten Konstellationen. Ausprobieren einer neuen Zielfunktion bzw. Konfiguration. Dispositionen können durch das Produktionssystem überschrieben werden. Die Realität (Betriebslage) gewinnt immer. Wenn RTO sich hier für eine Fahrwegänderung entschieden hat, der Zug aber dann doch auf dem ursprünglichen Fahrweg fährt, überschreibt das die Disposition vor RTO. Daher nicht geeignet für Testen von Spätfolgen der RTO-Dispositionen.
- Um diese Nachteile zu umgehen, führen wir regelmässig Live-Tests in den Optimierungsgebieten durch. Wir haben vorletztes und letztes Jahr Live-Test im Raum Olten durchgeführt. Seit letztem Herbst laufen sie im Tessin zwischen Bellinzona und dem neuen Ceneri Basistunnel. Hier rechts ein Beispiel: Ein Zug wurde manuelle eingefügt. Dieser muss mit einem anderen Zug kreuzen. RTO hat daraufhin eine Fahrwegänderung in Giubiasco von Gleis 2 nach Gleis 4 gemacht.
- Seit 10 Monaten haben wir nun Pilotbetrieb im Raum Olten. Im Tessin fingen wir im Juni an. RTO ist in Produktion. Es ist in einem Gebiet eingeschaltet und optimiert dort den Bahnverkehr. Disponenten und Fahrdienstleiter beobachten und greifen, falls nötig, ein. Sie dokumentieren Sachen, die ihnen auffallen, sofort. Dazu gehören z.B. eine Beschreibung der Situation mit den beteiligten Zugfahrten, die Dispositionen oder die Situation im Bahnhof. Die Befunde diskutieren wir jede Woche. Bei Bedarf können wir die Befunde reproduzieren …
- Die Optimierung kann nämlich bei Bedarf bei jedem Optimierungslauf die Ausgangssituation vor der Optimierung in einer Datei abspeichern. Das passiert dann jede 5 Sekunden, man bekommt also eine Menge Daten. Dies ist im Pilotbetrieb aktiv. Bei der Entscheidung, welche Dispositionen optimal sind, kommt es oft auf Sekunden an, die ein Zug früher oder später an einem Konfliktort ist. Mit diesem Hilfsmittel können wir exakt die Ausgangssituation reproduzieren. Bei Befunden aus dem Pilotbetrieb kann so nachvollzogen werden, warum RTO diese Lösung gewählt hat. Die Ausgabe erfolgt in Form von detaillierten Daten sowie eine grafische Darstellung eines jeden Optimierungsschritts. Falls die gewählte Lösung nicht gut ist, kann man z.B. die Zielfunktion umkonfigurieren, und diese Situation mit der geänderten Zielfunktion testen. So kann die Optimierung laufend verbessert werden.
- Damit möchte wir die Vorstellung der speziellen Tests für RTO abschliessen und auf die Erfolgsfaktoren zu sprechen kommen.
- Die enge Zusammenarbeit mit den Anwendervertretern ist unheimlich wichtig. Wir können sehr von ihrem Wissen und ihrer Erfahrung profitieren. Die Anwendervertreter begleiten die Disponenten und Fahrdienstleiter in den Betriebszentralen während der Live-Tests und dem Pilotbetrieb sehr eng. Dies ist unter Anderem nötig, um die Unsicherheit bei der Arbeit mit einem neuen, automatisieren System zu reduzieren. Schnelles Feedback: Labortest: Änderungen und Anpassung sofort testbar, aber Erkenntnisse noch unsicher Live-Test: Anfangs alle zwei Wochen, jetzt einmal im Monat. Sehr gute Erkenntnisse, aber zu anderen Zeiten und Betriebslagen könnten sich andere Probleme ergeben. Pilot: Feuerprobe für RTO. Hier bekommen wir sehr viel Feedback, was RTO gut macht und wo noch Verbesserungspotential liegt. Wir können dann mithilfe des Reproduzierens entweder die korrekte Arbeitsweise von RTO zeigen oder die Ursachen für schlechte Dispositionen suchen. Reproduzieren von Situation hilft auch, die geänderte Konfiguration der Zielfunktion auszuprobieren. Mit dem Testframework können wir die Komplexität für die Testdurchführung senken, indem wir einige Tests mit einfachen Testdaten ausführen können.
- Damit sind wir am Ende mit unserem Ausflug in den Bahnverkehr der Zukunft und stehen noch für Fragen zur Verfügung …