Architekturdokumentation Verteilte komponentenbasierte Verkehrssimulation
Diese Dokumentation beschreibt die Softwarearchitektur einer verteilten komponentenbasierten Verkehrssimulation. Die beschriebene Architektur wurde von den Erstellern dieses Dokumentes entworfen und berücksichtigt alle notwendigen Anforderungen für diese Simulation.
Das Ziel dieses Projekts ist das Entwerfen, Implementieren und Dokumentieren einer Verkeherssimulation, die diverse Anforderungen erfüllen soll, die im Dokument ,,Dokumentation Softwaredesign" in Kapitel 2 zu finden sind. Dabei sind Entwicklungsdokumente, wie die Dokumentation der Softwarearchitektur (dieses Dokument), des Softwaredesigns und der Implementierung zu erstellen.
Die folgende Tabelle gibt einen kurzen Überblick über die Qualitätsziele dieses Projekts.
Folgende Mitglieder sind bei diesem Projekt involviert:
Folgende Randbedingungen sind zusätzlich zu den Punkten aus Kapitel 2 (siehe Dokumentation Softwaredesign) einzuhalten:
- Eingebundene Softwaremodule- bzw. komponenten
- Eingebundene Frameworks
Die folgenden Unterkapitel beschreiben das Umfeld dieser Simulation. Hier wird die Frage beantwortet, wie der Benutzer mit der Simulation interagiert und mit welchen Fremdsystemen die Simulation kommuniziert.
Abb.1: Kontextabgrenzung
Benutzer
Der Benutzer startet die Simulation und ist in der Lage diese mit Hilfe der Interaktionsmöglichkeiten zu beeinflussen, wie z.B. die Ampelsteuerung parametrisieren, Pausieren der Simulation, Hindernisse ein-/ausschalten usw.
Nachbarsimulation
Diese ist ein Fremdsystem, das ein Ein-und Ausfahren der Fahrzeuge in einer andere Simulation bzw. in die eigene mit Hilfe eines definierten Protokolls ermöglicht (siehe Abschnitt 3.2 Technischer Kontext). Das konkrete Fremdsystem in diesem Projekt sind die Straßenkarten der anderen Laborgruppen.
Die restlichen Blöcke in Abbildung 1 werden in Kapitel 5 (Bausteinsicht) näher beschrieben. Grundsätzlich kommuniziert die Simulation mit den dargestellten Blöcken.
Abb.2: Technischer Kontext: Darstellung der verwendeten Frameworks und Schnittstellen
MonoGame
MonoGame ist eine Open Source Immplementierung des Microsoft XNA 4 Frameworks mit dessen Hilfe die entwickelten Spiele auf viele Plattformen (Desktop PCs, Tablets,...) übertragen werden können. Das Framework kann sehr einfach in Visual Studio bzwm mit C# genutzt werden. Die GUI in diesem Projekt nutzt dieses Framework, um die erstellte Straßenkarte und die Objekte darstellen zu können.
Amazon Simple Queue Service (AWSSQS)
Amazon Simple Queue Service (SQS) ist ein vollständig verwalteter Nachrichtenwarteschlangen-Service für die Kommunikation zwischen verteilten Softwarekomponenten. SQS ermöglicht eine einfache und wirtschaftliche Entkopplung und Koordination der Komponenten einer Cloud-Anwendung. Dieser Service wurde für die Kommunikation zwischen der Verkehrssimulation und der Nachbarsimulation verwendet. Die genaue Schnittstellenbeschreibung ist im Dokument Vehicle-Handover-Library auf dieser Wiki zu finden.
XML-File
Die XML-File dient zur Kommunikation zwischen der GUI und der Verkehrssimuation. Grundsätzlich befinden sich im File die IDs diverser Straßenstücke, Kreuzungen, Ampeln und Fahrzeuge. Die Erstellung der Straßenkarte sowie die Definition der einzelnen IDs erfolgt mit Hilfe des Tools Tiled, das die ganze Karte in einem .tmx bzw. XML-File sichern lässt. Anschließen können mit MonoGame die IDs im XML-File in Visual Studio verwendet werden, um in der Simulation das Verhalten der Fahrzeuge und Ampeln regeln zu können.
Folgende Abbildung zeigt die Oberfläche von Tiled:
Abb.3: Screenshot der Benutzeroberfläche von Tiled
Zur Lösungsstrategie wurden folgende Details beachtet bzw. entschieden:
- Das Projekt soll aus mehreren Komponenten bestehen, die u.A. eine unabhängige Entwicklung im Team ermöglichen soll
- Die Architektur muss einen hohen Grad an Abstraktion besitzen, damit in weitere Folge Änderungen/Erweiterungen ohne hohen Aufwand realisiert werden können. Dabei wurde die Architektur, wie in Kapitel 5 ersichtlich, in eigene Komponenten zerlegt, die miteinander über Schnittstellen kommunizieren.
- Für die Simulation/GUI wird MonoGame des Microsoft XNA 4.x Frameworks verwendet, um einfache Cross-Plattform Games entwickeln zu können (siehe Kapitel 3.2); dadurch wird auch eine komfortable und einfache Konfiguration der Simulationsparameter aus Punkt 1.2 Qualitätsziele gewährleistet
Dieses Kapitel gibt einen Überblick der Softwarearchitektur und deren Komponenten.
Abb.4: Architektur V.1 der Verkehrssimulation
Die gezeigte Abbildung stellt die drei linierten Bereiche (GUI, Simulation und Ampelsteuerung) als jeweils eigene Prozesse/.exe dar. Den Kern bildet dabei der mittlere Prozess, in dem die beiden Module Fahrzeug und Simulation enthalten sind. Das Modul Fahrzeug enthält alle notwendigen Komponenten und Klassen, die notwendig sind, um alle Funktionalitäten (siehe Abschnitt 5.1.1) bereitzustellen. Es bedient die vom Modul Simulation angebotene Schnittstelle. Das Modul Simulation bietet zwei weitere Schnittstellen für die Verkehrsregelung (Ampelsteuerung) und das GUI Modul an und hat zusätzlich noch eine Verbindung zum Konfigurationsspeicher in Form eines XML Files.
Folgende Abbildung zeigt die erweiterte Architektur (Version 2), die hier detaillierter ausgearbeitet ist. In der Ebene Kontextabgrenzung ist der erweiterte Block der Nachbarsimulation (SQS-Schnittstelle) zu sehen, die ein Ein-und Ausfahren von Fahrzeugen anderer Simulationen (andere Laborgruppen) in die eigene Straßenkarte bzw. in eine andere Straßenkarte ermöglicht. In Ebene 1 ist die eigene Architektur dieses Projekts (siehe Abbildung 4) und in Ebene 2 die weitere Verfeinerung (Packages) der einzelnen Komponenten dargestellt.
Abb.5: Architektur V.2 der Verkehrssimulation
Wie in Ebene 1 in Abbildung 5 ersichtlich, stellen die gezeigten Komponenten, außer der Nachbarsimulation, die ursprüngliche Architektur (Abbildung 4) dieses Projekts dar. Dabei werden vier Module, mit jeweils folgenden Aufgaben, verwendet:
1) GUI
- Stellt einen eigenen Prozess dar
- Anwendung wird grafisch dargestellt
- Pollt die Aktualisierung der darzustellenden Teile von der Simulation
2) Ampelsteuerung
- Stellt einen eigenen Prozess dar
- Es gibt eine Instanz der Verkehrsregelung für die Anwendung, die zentral alle (auf den Kreuzungen verteilten) Lichtanlagen und Verkehrszeichen steuert
- Die Verkehrszeichen sind parametrisierbar
- Regelt die Lichtsteueranlage, sodass alle Ampeln synchron laufen
- Übernimmt zudem die Verteilung der passiven/statischen Verkehrszeichen auf die Kreuzungen
Folgende Module laufen in einem Prozess:
3) Fahrzeug
- Fahrzeuge sind parametrisierbar
- Fahrzeugverhalten: variabel, zufällig, individuell
- Fahrzeuganzahl - Verschiedene Typen: - PKW - LKW
- Gibt Verhalten vor (Agent)
- Pollt Umgebung, andere Fahrzeuge und Verkehrsregelungen/Ampel von der Simulation
4) Simulation
- Sorgt für zusammenhängendes Straßennetz
- Gibt den Simulationstakt vor
- Nimmt die verschiedenen Typen (Kreuzungen/Fahrzeuge) auf
- Regelt die Anzahl der zufahrenden Fahrzeuge
- Verwaltet die Konfigurationsdaten
- Stellt die Schnittstellen den Modulen Ampelsteuerung, Fahrzeug und GUI zur Verfügung
Konfigurationsdatei:
In diesem XML-File sind diverse Parameter und Daten für die GUI, wie die IDs von Kreuzungen und Straßenstücken sowie Maße der Karte, zu finden.
Nachbarsimulation:
Siehe Abschnitt 3.1 Fachlicher Kontext bzw. Dokumentation Vehicle Handover Library für eine detailliertere Beschreibung.
An dieser Stelle sei erwähnt, dass die Implementierungsdetails der oben beschriebenen Module jeweils in den Dokumentationen Software Design und Implementierung zu finden sind.
In Ebene 2 sind, wie erwähnt, die einzelnen Packages der einzelnen Module zu sehen. Die dazugehörigen Klassen der einzelnen Packages sind in der Dokumentation Softwaredesign dargestellt und beschrieben. Die blauen Verbindungspfeile kennzeichnen, wie der Informationsfluss zwischen den einzelnen Packages erfolgt (welche Klasse bekommt Parameter etc. von einer anderen Klasse).
Um einen besseren Überblick über die internen Abläufe zwischen den einzelnen Komponenten aus Ebene 1 zu bekommen, dienen folgende Unterkapitel.
Das folgende Sequenzdiagramm zeigt den prinzipiellen Ablauf zwischen den vier genannten Modulen aus Ebene 1. Die GUI steht im engen Informationsaustausch mit der Simulation, d.h. die GUI fordert von der Simulation die nötigen Parameter bzw. Objekte an, um diese in einem bestimmten Takt auf der Straßenkarte aktualisieren und darstellen zu können. Parameter oder Objekte sind der aktuelle Lichstatus einer Ampelgruppe pro Kreuzung oder die verschiedenen Fahrzeugarten, die auf die Ampelzustände, Kreuzungsart und andere Fahrzeuge achten/dementsprechend reagieren. Anschließend fragt die Simulation die geforderten Details der GUI über die jeweilige Komponente ab, die diese Informationen zur Verfügung stellen. Im letzten Schritt gibt die Simulation die aktualisierten Details nach einer anschließenden Überprüfung der IDs (von Fahrzeugen, Ampelgruppen und Straßen/Kreuzungen) im XML-File an die GUI wieder zurück, die die Objekte auf der Straßenkarte zeichnet.
Abb.6: Ablauf zwischen den Modulen
Siehe Abschnitt 4. Lösungsstrategie oben.