01 Architektur Dokumentation
Diese Seite beschreibt die Architektur der Straßenverkehrssimulation die im Zuge des Labors "Software Architekturen" an der FH Salzburg entwickelt wird.
Dieses Dokument wurde nach der Architekturdokumentations-Vorlage arc42 aufgebaut: ARC42
Aufgabenstellung ist eine Straßenverkehrssimulation, das basierend auf einer vorher definierten Karte mit definierten Straßenregeln eine Simulation von verschiedenen Verkehrsteilnehmern ermöglicht (PKW, LKW). Diese Simulation wird mithilfe eines GUIs für den Benutzer dargestellt.
Es werden sowohl statische (z.B. Rechtsregel) als auch dynamische (z.B. Ampeln) Verkehrsregeln simuliert.
Die Fahrzeuge werden an zuvor festgelegten Startpunkten in die Simulation gesetzt und fahren anschließend auf zufälligem Weg zu Ihrem Zielpunkt. Die möglichen Zielpunkte (Austrittspunkte aus der Simulation) werden ebenfalls vordefiniert.
Funktionale Anforderungen Übernommen aus der Angabe von DI (FH) DI Roland Graf, MSc:
Die Simulation sollte wie folgt unterstützen:
- Mikroskopische Simulation der Fahrzeuge (PKW und LKW) und Ampelanlagen
- Zusammenhängendes Verkehrs-/Straßennetz
- Geregelte und ungeregelte Kreuzungen
- Verhalten der Verkehrsteilnehmer sollte weitgehend parameterisierbar sein (variabel/zufällig/individuell)
- Verhalten der Lichtsteueranlage parameterisierbar; Regelung über eigenen Prozess
- Anzahl der über Einfahrtstrassen in das System zufahrenden Fahrzeuge regelbar
- Grafische Darstellung und einfache Benutzerschnittstelle; Konfiguration-GUI nicht unbedingt notwendig
Die folgende Anlistung beschreibt die zentralen Qualitätsziele der Straßenverkehrssimulation, die Reihenfolge gibt eine grobe Orientierung bzgl. Priorität der einzelnen Ziele:
- Erweiterbarkeit: Unser Regel und Teilnehmersystem ermöglicht das Erweitern von zusätzlichen Regeln (wie z.B. Bahnübergangsschranken usw.) und das Erweitern von zusätzlichen Teilnehmerverhalten (z.B. Raserverhalten) ohne systemweite Änderungen zu verursachen
- Anpassbarkeit: Teilnehmerverhalten und Regelwerk kann ohne Seiteneffekte angepasst werden
- Robustheit: Einzelne Subprozesse dürfen nicht stoppen, Subprozesse implementieren selbst ein entsprechendes Fail-Safe Verhalten (evtl. Selbstneustart im Falle eines Fehlers), Simulationskomponente implementiert zusätzlich noch eine Watch-Dog-Thread, der periodisch prüft ob noch alle Subprozesse laufen und startet diese nochmals
- Testbarkeit: Die einzelnen Komponenten können unabhängig voneinander getestet werden
- Performance: Da alle Subprozesse als eigener Prozess laufen, werden hier optimal die Ressourcen von Mehrkernprozessoren genutzt
Der folgende Abschnitt enthält die Stakeholder der Straßenverkehrssimulation und beschreibt deren Interesse und Bezug zum Projekt.
Auftraggeber: DI (FH) DI Roland Graf MSc
- Gibt die Basisaufgabenstellung für die Verkehrssimulation
- Unterstützt das Projektteam während der Laboreinheiten
- Interesse an sinnvoll gestalteter Dokumentation (so lang wie nötig, so kurz wie möglich)
Auftraggeber: DI Eduard Hirsch
- Sieht Architekturlösungen nach ein paar Vorlesungen und bringt Änderungswünsche ein
- Versucht die Architektur auf Adaptierbarket zu prüfen (siehe Vertiefung "Adaptive Softwareentwicklung")
Entwicklerteam
- Sind an einer Lösung mit minimalen Implementierungsaufwand interessiert
- Haben Interesse Architektur mit spannenden Technologien umzusetzen
Beim Architekturentwurf waren durch die Aufgabenstellung einige Randbedingungen zu beachten, die sich direkt auf den Entwurf auswirken. Dieser Abschnitt beschreibt diese Randbedingungen und wo nötig, deren Motivation.
In diesem Abschnitt werden die durch die Angabe und Herrn Graf erwähnte Randbedingungen gelistet:
Visual Studio Solution: Die Abgabe soll als Visual Studio Solution erfolgen und soll ohne weiteren Konfigurationsaufwand nach öffnen der Solution mit F5 gestartet werden können.
Implementierung in C#: Aufgrund der Anforderung, dass das Projekt als Visual Studio Solution abgegeben werden muss und aufgrund der bereits existierenden Erfahrung der Projektmitglieder soll die Programmiersprache C# zum Einsatz kommen. Entwickelt wird unter der Frameworkversion 4.5.2.
Multi-Prozess Applikation: In der Angabe wird gefordert, dass mindestens die Ampelsteuerung in einem eigenen Prozess laufen muss. Diese Anforderung erfordert eine Multi-Prozess Architektur.
Team:
Walter Bernhofer, Thomas Eder, David Schöninger, Maximilian Unterrainer, Markus Ziegler
Zeitplan:
Labortermin 3 (20.04.2017): Fertigstellung erster Entwurf Architektur- und Designdokumentation
Labortermin 4 (04.05.2017): Prototypische Demonstration der Simulation
Labortermin 5 (18.05.2017) und 6 (01.06.2017): Erweiterung des Projekts nach den Vorgaben von Koll. Eduard Hirsch
Abgabetermin 17.07.2017: Architektur, Design und Implementierung + Visual Studio Projekt abgeben
Vorgehensmodell:
Agile Softwareentwicklung mit regelmäßigen Telefonkonferenzen bzgl. Abstimmung.
Zur Dokumentation der Architektur kommt arc42 zum Einsatz.
Entwicklungswerkzeuge:
Entwurf mit Stift und Papier bzw. auf dem Whiteboard, wichtige Modelle werden mit dem Enterprise Architect erstellt.
Dokumentation der Architektur, des Designs und der Implementierung erfolgt im Github Repository Wiki.
Entwicklung der Applikation erfolgt mithilfe von Visual Studio 2015 bzw. Visual Studio 2017 (jeweils in der Community Edition).
Konfigurations- und Versionsverwaltung:
Git gehostet in einem privaten Repository auf Github.
Testwerkzeuge und -prozesse:
Visual Studio Unit Tests für die einzelnen definierten Komponenten.
Architekturdokumentation:
Gliederung nach dem deutschen arc42-Template.
Kodierrichtlinien für C#:
Die Coding Conventions aus dem C# Programming Guide sind zu beachten:
- https://msdn.microsoft.com/en-us/library/ff926074.aspx
- http://www.dofactory.com/reference/csharp-coding-standards
Sprache (Deutsch vs. Englisch)
Benennung von Dingen in der Dokumentation und Code in Englisch.
Im fachlichen Kontext werden die fachlichen Konzepte beschrieben, mit denen das System arbeiten soll.
Die Betrachter die Simulation starten das Programm und beobachten die Geschehnisse, die während der Simulation auftreten. Sie können durch Interaktion mit der Benutzeroberfläche Unfälle simulieren und prüfen somit das Verhalten der simulierten Verkehrsteilnehmer während der Simulation.
Die Simulation umfasst die entwickelte Lösung die eine Straßenverkehrslösung nach der österreichischem StVo. darstellt. Dieser Baustein soll im Zuge dieses Projekts entwickelt werden.
Die Verkehrssimulation basiert auf den Verkehrsregeln aus Österreich und enthält somit div. Vorrangsregeln und andere Straßenverkehrsregeln wie z.B. Geschwindigkeitsbeschränkungen, Ampeln etc..
Im technischen Kontext werden die Systeme beschrieben, mit denen die Simulation interagieren muss.
Wie in der Grafik zu sehen ist, kommuniziert die Simulation (In diesem Falle links oben, Group1) über die Amazon AWS Cloud asynchron mit den Simulationen der anderen Gruppen. Die Simulation selbst kann auf einem Rechner betrieben werden, auf dem Visual Studio 2017 installiert ist. Genauere Informationen entnehmen Sie bitte dem Kapitel Verteilungssicht dieses Dokuments.
Der Lösungsansatz lässt sich am besten mit dem folgenden Tafelbild, dass vom Projektteam während der zweiten Besprechung angefertigt wurde, erklären:
Die Simulation baut auf einer Karte auf, die aus Koordinaten besteht. Diese Koordinaten oder Knoten sind durch Linien oder Kanten miteinander verbunden. Diese Kanten bilden ein Wegnetz durch die Simulation. D.h. die Karte ist im Prinzip ein gerichteter Graph. Die Agents (Teilnehmer) können sich auf den Kanten bewegen. Ein Knoten kann mehr als zwei Kanten verbinden, damit werden Kreuzungen bzw. Weggabelungen ermöglicht.
Auf jeden Knoten können mehrere Regeln hinterlegt werden, darunter neben Vorrangsregeln und Geschwindigkeitsregeln auch dynamische Regeln wie z.B. Ampelanlagen.
Knoten speichern neben diesen Regeln auch deren Koordinaten bzw. eindeutige ID, damit die Knoten im Koordinatensystem eindeutig identifizierbar sind. Zusätzlich werden bei jedem Knoten alle angrenzenden Kanten gespeichert.
Startknoten werden durch eine leere Vorgängerliste und Endknoten durch eine leere Nachfolgerliste gekennzeichnet.
Kanten besitzen Knoten als Start- und Endpunkte und dadurch auch Vorgänger- und Nachfolgerkanten. Eine Kante kann auch eine Nachbarkante (z.B. Gegenfahrbahn) besitzen, wodurch ein Fahrstreifenwechsel möglich wird. Diese Nachbarkanten können für Überholmanöver und Ausweichmanöver genutzt werden.
Jeder Agent prüft alle Regeln innerhalb einer definierbaren Reichweite von Kanten (abhängig von Bremsweg, Agentparametern, Sicherheitsabstand zum Vordermann, etc.) und beschleunigt bzw. verzögert entsprechend um unfallfrei am Verkehr teilzunehmen. Nachdem der Agent seine Entscheidung (Beschleunigen, verzögern, gleich bleiben) getroffen hat, aktualisiert er entsprechend seine Position auf der Karte.
Die dynamischen Regeln werden regelmäßig aktualisiert, damit sie ihren Status wechseln können.
- GUI: Grafische Oberfläche (WPF). Zur Visualisierung der Map, Teilnehmer und Konfigurationsmöglichkeiten.
- MAP: Beschreibung der Karte. Aufgebaut als Koordinationsystem bestehend aus aus verschiedenen Kacheln.
- RULES: Set an Regeln, die auf einer Map liegen und die dadurch der Map zu einem Verhalten verhelfen.
- POS/GPS: Globales Positionierungs System, damit sich die Fahrzeuge orten können und wissen wo sie sind und was in ihrer Umgebung passiert.
- TEILNEHMER: Ein Fahrzeug, dass eine Position hat.
- SIM: Simulator & Taktgeber für die Simulation, der in jedem Zeitintervall alle Elemente der Simulation durchgeht und benachrichtigt.
Die Grafik zeigt die Architektur nach Zusammenfassung der bereits beschriebenen Bausteine in vier Teilapplikationen: GUI, Data Access, Rule Engine und Simulation. Durch den Change-Request, dass Fahrzeuge beim Ausfahren aus der Map an andere Simulationen übergeben werden sollen, wurde noch eine Message-Queue Komponente zur Übergabe der Fahrzeuge eingefügt.
Data Access:
Die Data Access Teilapplikation dient als Kommunikationsschnittstelle zwischen allen Applikationen und managed die gespeicherten Simulationsobjekte. Darunter das GPS/Position System, dass alle Fahrzeuge der Karte und deren Position, Geschwindigkeit und andere Parameter speichert. Des Weiteren werden die Map, deren Koordinatensystem, hinterlegte Regeln und die sich ändernden Regeln gespeichert.
Die Komponente DataBridge der Data Access Applikation ermöglicht einen einheitlichen Zugriff auf Data Access Applikation, diese wird von den anderen Applikationen als Bibliothek eingebunden, um nicht selbst die Zugriffe auf die Data Access Applikation implementieren zu müssen.
GUI:
Die GUI kümmert sich um die Darstellung des Status des Speichers der Data Access Applikation und aktualisiert sich laufend, um die Agents (vorher Teilnehmer) und deren Bewegungen auf der Karte zu animieren.
Rule Engine:
Die Rule Engine kümmert sich um das aktualisieren der dynamischen Regeln der Karte und sorgt so für eine Möglichkeit, die Ampelanlagen der Simulation zu steuern (z.B. schaltet die Rule Engine im definierten Rythmus die Ampelanlagen).
Simulation:
Die Simulations-Teilapplikation dient als Startapplikation des Systems und besteht aus den zwei Komponenten Agent und Controller. Der Controller ist zuständig für das Starten aller anderen Applikationen (GUI, Data Access, Rule Engine), sowie dem Überwachen der Prozesse, um Prozesse neu zu starten, sollten diese abstürzen. Die Komponente Agent kümmert sich um das Erstellen von diversen Agents (vorher Teilnehmer) die verschiedenes Fahrverhalten besitzen. Die Agents sind selbst für die Aktualisierung ihrer Geschwindigkeit und ihrer Position in der GPS/Pos der Data Access Applikation zuständig.
Vehicle Handover Library:
Nach dem Change Request zur Mitte des Semesters, wurde die Message-Queue Komponente Vehicle Handover Library eingefügt. Hierzu wurde der Simple Queue Service der Amazon AWS Cloud genutzt. Beim Verlassen der Simulation wird die Fahrzeug-Beschreibung im JSON-Format in die Queue gepusht. Andere Simulationen können sich zur Queue subscriben und diese somit in Echtzeit erhalten und spawnen. Von unserer Gruppe wurde hierzu für alle die "Vehicle-Handover-Library" zur Verfügung gestellt, die sich um das serialisieren und pushen der Fahrzeuge bzw. das asynchrone Erhalten von Fahrzeugen via Events kümmert. (siehe Beschreibung Vehicle-Handover-Library)
- Simulation wird gestartet
- Data Access wird gestartet
- Rule Engine und GUI werden gestartet
- Controller startet Prozessüberwachung und startet Teilapplikation notfalls neu, sollte einer abstürzen
- Data Access
- liest die Konfigurationen in den Speicher, behält diesen dort,
- wartet auf eingehende Anfragen und beantwortet diese
- Rule Engine
- liest alle dynamischen Regeln
- startet für jede Rule einen Thread für die Aktualisierung der jeweiligen Regel im definierten Rythmus
- GUI
- zeichnet Hintergrundbild
- Startet den Thread für die Aktualisierung der Agents und dynamischen Regeln
- Controller
- Startet Thread für Agent Erstellung nach Start der Teilprozesse
- Agent Thread liest Konfiguration für Agent Erstellung (z.B. Gewünschte Verteilung PKW zu LKW, Raser, Frequenz der Agenterstellung etc.)
- Agent erstellt im definierten Rythmus (evtl. auch zufälligen Rythmus) Agents
- Agents berechnen den nächsten Schritt
- Agents aktualisieren ihren Status in der Data Access Applikation
Folgendes Beispielszenario an der Tafel durchbesprochen:
Aufgrund dieses Beispiels wurde die Agent und Rule Logik diskutiert.
Nähert sich z.B. ein Agent über die linke Straße auf der orangenen Spur, hat dieser folgende Regeln zu beachten:
- Maximalgeschwindigkeit v=80
- Knoten 8 + Vorgängerknoten sind auf evtl. Verkehr mit Vorrang zu prüfen
- Knoten 6 + Vorgängerknoten sind auf evtl. Verkehr mit Vorrang zu prüfen
Folgendes Deployment-Diagram zeigt die Verteilungssicht der Anwendung.
Die Simulationen der Gruppen laufen für gewöhnlich auf PCs/Notebooks/Workstations in einer .NET Umgebung. Über die VehicleHandoverLibrary können die einzelnen Simulationen der drei Laborgruppen Fahrzeuge übergeben. Dazu existiert in der Amazon Cloud im Simple Queue Service für jede Gruppe eine FIFO-Queue. Über die SQS-API werden in JSON serialisierte Fahrzeuge, welche eine Simulation verlassen in die jeweilige Queue der Gruppe gepusht. Simulationen anderer Gruppen können Queues anderer Gruppen abonnieren und somit die Fahrzeuge in Echtzeit erhalten.
Bei der Architektur wurde darauf geachtet, Komponenten und Technologien so einzusetzen, dass diese auch für andere Einsatzzwecke einfach adaptierbar sind.
-
Zentralisierter DataAccessLayer / DataBridge: Über diese zentralen Komponenten können sämtliche Datentypen/Klassen, die in JSON serialisierbar sind, zwischen mehreren Applikations-Komponenten synchronisiert werden. Dies ist einfach für weitere Datentypen erweiterbar und könnte auch für andere Systeme/Applikationen verwendet werden.
-
Cloud-MessageQueue für Fahrzeugaustausch: Die VehicleHandoverLibrary verwendet eine Cloud-MessageQueue für den Datenaustausch zwischen den Gruppen. Dadurch können Fahrzeuge in Echtzeit zwischen entfernten Systemen übertragen werden. Es spielt dabei keine Rolle in welcher Programmiersprache die Systeme entwickelt wurden bzw. in welcher Laufzeitumgebung diese laufen, solange gegen die SQS-API entwickelt wird. Somit wäre es beispielsweise auch problemlos möglich, Simulationen die in Java o.Ä. programmiert wurden anzubinden.
Das Projektteam hat sich während einer der Laboreinheiten dazu entschlossen, anstatt der Lösung mit fixer Kantenlänge (je 1 Meter) auf ein flexibleres Graphenmodell zu wechseln. Somit sparen wir uns bei langen geraden den Administrationsaufwand der Anlage und richtigen Positionierung der Punkte auf der Karte.
Des Weiteren erleichtert es die Darstellung und Berechnung der Abstände zwischen den Agenten.
Um eine entkoppelte Kommunikation zwischen den einzelnen Verkehrssimulationen der einzelnen Laborgruppen zu gewährleisten, wurde auf die Messaging-basierte Technologie SQS von Amazon zurückgegriffen. Damit war es mit sehr geringem Implementierungsaufwand möglich, die einzelnen Simulationen miteinander zu verbinden.
Qualitätsbaum
Qualitätsszenarien
- Zuverlässigkeit: Die Zuverlässigkeit der einzelnen Komponenten wird durch Unit-Tests auf ein akzeptables Maß gebracht. Die Kopplung der Bausteine wird über definierte Schnittstellen gering gehalten, Nebeneffekte können so vermieden werden. Eine zentrale Logger-Komponente ermöglicht es, wenn Fehler auftreten diese im Nachhinein zu analysieren und zu beheben.
- Wartbarkeit: Durch die aktuell gehaltene Dokumentation nach arc42 wird gewährleistet, dass ein neues Teammitglied sich in kurzer ZEit in das System einarbeiten kann. Dafür ist zu gewährleisten, dass diese Dokumentation aktuell und der Systemumsetzung entspricht.
- Funktionalität: Einzelne Bausteine können unabhängig getestet werden, insbesondere das Verhalten der Fahrzeuge soll der Realität entsprechen (keine springenden Autos).
- Effizienz: durch die Aufteilung des Systems in einzelne Prozesse/Threads ist gewährleistet, dass aktuelle Mehrkernprozessoren die Software verteilt ausführen und so Performanzprobleme, bei einer annehmbaren Anzahl von Fahrzeugen, vermieden werden.
- Portierbarkeit: die Plattform ist auf das Windows BEtriebssystem festgelegt, auf die einfache Protierbarkeit wird verzichtet.
- Benutzbarkeit: die Benutzung soll einfach sein, und Spaß machen. Die Definition der Landkarte und der Eigenschaften der Fahrzeuge sind in einem ersten Schritt manuell zu erfassen, wenn Zeit bleibt wird ein Editor mitgeliefert.
Aktuelle technische Schulden:
- Thread Handling in der Simulationskomponente überarbeiten, ist noch etwas chaotisch implementiert, jedoch läuft es aktuell auf keine Fehler
- Knoten: Ein Auf der Karte eindeutig identifizierbarer Punkt, auf dem Kanten angehängt werden.
- Kanten: Eine Linie zwischen zwei Knoten, auf der sich Agents befinden
- Agents: Ein Fahrzeug (LKW, PKW, Motorrad, ...) das auf der Karte fährt.
- Static Rules: Statische Regeln wie Vorrang, Stop, ...
- Dynamic Rules: Dynamische Regeln, die ihr Verhalten während der Simulation ändern (Ampel, dynamische Geschwindigkeitsregelung)