Meilensteine

2. Review & 1. Prototyp: Referenzsystem

Wir hatten unser zweites Review und haben unseren ersten Prototypen teilweise umgesetzt. Dazu wollen wir Euch hier informieren.

Für unseren ersten Prototypen haben wir eine Basiskarte erstellt, welche Teile der Stadt Oldenburg enthält. Diese Basiskarte umfasst die Rettungswache der Johanniter, die Feuerwache der Freiwilligen Feuerwehr, die Feuer- und Rettungswache der Berufsfeuerwehr an der Auguststraße (dort hat sich bis 2012 eine Wache der Berufsfeuerwehr befunden), das Pius-Hospital, das Evangelische Krankenhaus, die Universität Oldenburg sowie das OFFIS.


Mit dem ersten Prototypen sind wir in der Lage eine Alarmfahrt mit dem Referenzsystem aus SUMO automatisiert durchzuführen. Mit der unten aufgeführten GUI kann man einen Notfall zu einem bestimmten Zeitpunkt für ein bestimmtes Notfallszenario in der Simulation auslösen. Unser ELR ist für die Alarmierung soweit die Vorbereitung der Alarmfahrt zum Krankenhaus verantwortlich. Er leitet die Berechnung der Route der Rettungsfahrzeuge an SUMO weiter. Auf Grundlage der Rückgabe von SUMO entscheidet der ELR welche Rettungsfahrzeuge zum Hilfesuchenden geschickt werden und zu welchem Krankenhaus der Patient am Ende gebracht wird. Dabei werden dem ELR die Notwendigen Informationen über die Krankenhäuser, Rettungswachen und Notfallszenarien über eigens entwickelte xml-Formate mitgeteilt. Dadurch kann unser System problemlos auf andere Städte übertragen werden.

Hier noch ein paar Impressionen unserer GUI:

Hier sind noch die Dokumentation und Präsentation zum 2. Review zu finden:


1. Review & Initiales Product Backlog

Wir hatten unser erstes Review und haben unser initiales Product Backlog erstellt. Dazu wollen wir Euch hier informieren.

Einer der wichtigsten Punkte des ersten Reviews sind die Ziele der PG. Das Ziel der PG CHILL3 ist die Entwicklung eines verteilten kooperierenden Systems zur Bevorrechtigung eines Rettungsfahrzeugs an Ampeln während der Alarmfahrt sowie der Bildung einer dynamischen Rettungsgasse. Dabei wird auf ein verteiltes Verkehrsmanagementsystem gesetzt, bei dem zwar ein globaler Knoten (GVMS: Globales Verkehrsmanagementsystem) vorhanden ist, dieser jedoch nicht alle Funktionen des Gesamtsystems übernimmt. Insbesondere lokale Entscheidungen wie das Optimieren der Ampelschaltung bei einer Alarmfahrt sowie das Einbeziehen der involvierten Verkehrsteilnehmer soll auf lokaler Ebene durch ein Lokales Verkehrsmanagementsystem (LVMS) erfolgen. Dadurch wird der zentrale Knoten entlastet, um auch bei Großschadensereignissen, wie sie bspw. in Folge eines Sturms auftreten, ein funktionsfähiges System zu bieten. Des Weiteren wird ein kaskadierendes Verfahren zur Bildung einer dynamischen Rettungsgasse und Sicherstellung einer "Grünen Welle" auf der Route der Rettungsfahrzeuge auf Ebene der Lokalen Verkehrsmanagementsysteme entwickelt.

Wir wollen während der Entwicklung unseres Systems prototypisch vorgehen. Dabei haben wir uns vier Prototypen vorgenommen:

  1. Prototyp Referenzsystem: Hier bauen wir die notwendige Infrastruktur auf, um reproduzierbar eine default Alarmfahrt in SUMO durchführen zu können. In diesem Prototyp findet keine Optimierung der Fahrzeit eines Rettungsfahrzeugs statt. So kann ein Rettungsfahrzeug von Ampeln oder anderen Verkehrsteilnehmern ausgebremst werden.
  2. Prototyp Verkehrsmanagementsystem: In diesem Prototyp werden die technischen Grundlagen des Verkehrsmanagementsystems gelegt. Auf diesem Prototyp kann das eigentliche DyReC-System aufbauen.
  3. Prototyp DyReC I kaskadierendes Verfahren & Ampelsteuerung optimieren: Mit diesem Prototyp wollen wir eine Alarmfahrt durchführen können, ohne dass ein Rettungsfahrzeug eine rote Ampel überfahren muss, da dies Zeit kostet und ein hohes Unfallrisiko birgt.
  4. Prototyp DyReC II dynamische Rettungsgasse: In diesem Prototypen werden die übrigen Verkehrsteilnehmer in das Geschehen einbezogen und bilden eine Rettungsgasse, bevor sich ein Rettungsfahrzeug in direkter Umgebung befindet.

 

Das Product Backlog bildet die Grundlage der weiteren Entwicklung. Dazu haben wir uns eine Pyramide überlegt, mit der wir die initiale Anforderungserhebung durchgeführt haben:

Die Vision bildet dabei die Spitze der Pyramide, gefolgt von den vier Use Cases, welche die Vision eingrenzen. Für jeden Use Case haben wir uns eine Beschreibung überlegt und ein Aktivitätsdiagramm erstellt. Aus den Use Cases leiten sich die Epics als übergeordnete User Stories ab. Daraus ergeben sich die mit Akzeptranzkriterien versehenen User Stories, welche in den einzelnen Sprints als Umsetzungsgrundlage dienen. Die Akzeptanzkriterien beantworten dabei die Frage, wann eine User Story erfüllt ist. Die unterste Ebene bilden die Anforderungen, welche Forderungen über zu erfüllende Eigenschaften an die unterschiedlichen Komponenten stellen.

Hier sind noch die Dokumentation und Präsentation zum 1. Review zu finden:


Vision

Wir haben unseren ersten Meilenstein erreicht! Die Vision unserer PG ist ausgearbeitet und kann hier eingesehen werden.

In der PG CHILL3 wird der Anwendungsfall der Optimierung der Hilfsfrist von Rettungsdiensten betrachtet. Die Hilfsfrist ist dabei die Zeit zwischen dem Einsatzbefehl der Leitstelle bis zum Eintreffen der alarmierten Kräfte. In Niedersachsen soll diese Zeit in 95 % der Fälle kleiner als 15 Minuten sein [BedarfVO-RettD (Nds. GVBl. 1993, 1)]. Um die Hilfsfrist zu Optimieren wird DyReC (DYnamic REscue Chill) prototypisch entwickelt. DyReC ist ein verteiltes System, welches mittels Kommunikation und Kooperation der Verkehrsteilnehmer sowie der Verkehrsinfrastruktur bei der Durchfahrt eines Rettungsfahrzeugs eine dynamische Rettungsgasse bildet um eine möglichst schnelle Durchfahrt des Rettungsfahrzeugs zu gewährleisten. Dazu setzt DyReC auf vorhandene Infrastruktur sowie Car2X-Kommunikation.

Langfristig werden verteilte kooperierende Systeme die Verkehrssteuerung übernehmen. Dies stellt sehr hohe Anforderungen an die Zuverlässigkeit solcher Systeme.

(Stand: 17.12.2020)