(WS15-01) Geldscheinwechsler

Aus Verteilte Systeme - Wiki
Wechseln zu: Navigation, Suche

Entwicklung und Inbetriebnahme eines voll funktionsfähigen Geldwechselautomaten für einen eingetragenen Verein (vertreten durch Herrn Kai Beckmann).

Teammitglieder

Name Kürzel Email-Adresse Hauptrolle im Projekt Nebenrolle im Projekt
Patrick Schwärzel PS patrick.schwaerzel@student.hs-rm.de Projektverantwortlicher Kundenkontakt
Marcus Michaely MM mail@marcusmichaely.com stellv. Projektverantwortlicher Verwaltung und Kommunikation
Lukas Schnetzer LS Lukas.schnetzer@student.hs-rm.de Entwickler Toolchain
Torsten Kriegbaum TK torsten.kriegbaum@student.hs-rm.de Entwickler Beschaffung und Qualitätssicherung
Alexander Fratzer AF alexander.fratzer@student.hs-rm.de Entwickler Git + GitLab
Norbert Wesp NW norbert.wesp@student.hs-rm.de Entwickler Wiki

Inhaltsverzeichnis

Einleitung

Dieses Wiki dient zur Dokumentation des Fortschrittes im Wahlprojektes "Geldscheinwechsler" und wird fortlaufend aktualisiert.

Allgemeine Projektbeschreibung

Das Projekt "Geldscheinwechsler" läuft unter dem Namen Project MASH, der sich aus "Cash Machine" ableitet. Ziel des Projektes ist die Entwicklung und Inbetriebnahme eines voll funktionsfähigen Geldscheinwechselautomaten. Der geforderte Automat wird im Anschluss an das Projekt in einem eingetragenen Verein aufgestellt und von diesem administriert. Die Hauptaufgaben des Automaten umfassen das Wechseln von Euronoten zu Euromünzen, die Annahme von Spenden und die Möglichkeit zur Fernwartung. Die Kundenanforderungen können hier eingesehen werden. Eine detaillierte Beschreiben der konkreten Anforderungen findet sich unter Requirements. Die Einführungspräsentation befindet sich hier. [AF]

Organisatorisches

Teamtreffen

Regelmäßige Teambesprechungen finden Dienstags im Gebäude C Raum 235 (Doktorandenkolleg) der Hochschule statt.

Uhrzeit Tätigkeit Teilnehmer
08:15 - 09:45 Teambesprechung Team MASH
10:00 - 11:30 Review Team MASH, Projektaufsicht
11:45 - 13:15 Projektarbeit Team Mash

Als mögliche Zusatztermine während der Vorlesungszeit wurden Mittwoch und Freitag beschlossen. Zu Beginn der vorlesungsfreien Zeit wurde beschlossen so oft wie möglich sich im genannten Raum zu treffen, um das Projekt voranzutreiben. [PS]

Die grobe Zeitplanung des Projekts

  • 21.Oktober Präsentation der Projektaufgabe
  • Abschlusspräsentation Ende Januar
  • 07.Februar Ende des Semesters
  • 14.Februar bis März Klausurzeit
  • 18.März um 09:00 Uhr Abgabe des Wikis
  • 22.März Ende des Projekts

[PS]

Die Aufteilung der Phasen:

  • Analyse 25% (75 Std/pro Person)
  • Design 25% (75 Std/pro Person)
  • Implementierung 20% (60 Std/pro Person)
  • Testen 30% (90 Std/pro Person)

Es werden mit 300 Stunden pro Teammitglied geplant. [PS]

Team Kalendar

Kalendar


Allgemeine Informationen

Toolchain

Papyrus

Papyrus ist ein Open-Source Tool, welches auf Eclipse basiert und unter EPL (Eclipse Public License) Lizenz steht. Es kann als Standalone Tool, oder als Eclipse Plugin genutzt werden. Neben UML2 bietet Papyrus auch volle Unterstützung zum Erstellen von systembeschreibenden Diagrammen in SysML. Eine Installationsanleitung findet sich hier und ein User Guide für den Umgang mit SysML hier. [LS]

Modelio

Modelio ist ein Open-Source UML-Werkzeug und steht unter GPLv3 Lizenz. Die Software kann unter diesem Link heruntergeladen und installiert werden und eine Kurzanleitung ist hier zu finden. Da mit Papyrus vermehrt Probleme mit der stabilen Nutzung aufgetreten sind wurde im Team vereinbart zukünftige Diagramme, etc. mit dieser Software zu erstellen. [AF]

Git und GitLab

Git ist ein mächtiges Werkzeug zur verteilten Versionskontrolle von Dateien und steht unter GPLv2 Lizenz. Um mit diesem Werkzeug effizient umgehen zu können sind Kenntnisse über den internen Aufbau von Git unabdingbar. Aus diesem Grund werden hier die essentiellen Mechanismen und Funktionsweisen kurz zusammengefasst. Dies ist keine ausführliche Einführung in git, sondern nur eine kleine Referenz. Eine ausführliche Einführung gibt es hier. GitLab dient als serverseitiges Frontend für Git und offeriert die wichtigsten Funktionen zur effizienten Verwaltung von git-repositories. [AF]

Toolchain

arm-none-eabi für Teensy 3.2

Alle anderen Kompilierungen werden auf dem PI selbst durchgeführt, da dieser schon einen eigenen Compiler besitzt. [NW]

CUnit

Als Testframework wird in diesem Projekt in erster Linie CUnit verwendet. Eine kleine Einleitung mit Beispielprojekt git es hier [AF]


Projektverwaltung

Dieser Abschnitt dient als Übersicht zur allgemeinen Projektstruktur und Organisation.

Struktur

Die Struktur des Projektes orientiert sich an der Vorgehensweise des V-Modells. Das V-Modell ist ein eher statisches Vorgehensmodell zur Entwicklung von komplexen Systemen und Anwendungen. Voraussetzung zur Anwendung des V-Modells ist das Vorhandensein von relativ statischen Anforderungen, da es durch die planungsintensive Vorbereitung der Iterationen und den streng sequentiellen Ablauf wenig agil auf größere, kurzfristige Änderungen in den Anforderungen reagieren kann. Es kann jedoch Iterativ benutzt werden, wenn man eine klare Abgrenzung von einzelnen Anforderungen durchsetzen kann. Eine mögliche Vorgehensweise wäre z.B. zunächst eine vollständige Iteration nur mit funktionalen Anforderungen zu durchlaufen und im Anschluss eine weiter für nicht-funktionale Anforderungen zu starten. Im Falle dieses Projektes wird versucht mit einer einzigen Iteration alle funktionalen und nicht-funktionalen Anforderungen abzudecken. Sollte es unvorhergesehene Hindernisse dabei geben, kann immer noch kurzfristig genug reagiert werden um eine weitere Iteration vorzubereiten, die als Erweiterung der Ursprünglichen dient. In der weiteren Iteration werden dann neue oder weniger wichtige Anforderungen berücksichtigt.

Daraus ergibt sich der Ausgangspunkt für die Projektstruktur wie folgt:

caption

Zunächst wird eine intensive Anforderungsanalyse durchgeführt. Erstes Ziel ist es, das requirement-Paket vollständig zu füllen. Hierbei wird zwischen funktionalen- und nicht-funktionalen Anforderungen unterschieden. Des Weiteren lassen sich die Anforderungen hierarchisch organisieren um eine bessere Übersicht und Untergliederung zu gewinnen um mögliche Abhängigkeiten der einzelnen Anforderungen zu berücksichtigen. Aus den resultierenden Anforderungen werden dann die use-cases erstellt. Die use-cases werden den requirements über eine ID zugeordnet um sie nachvollziehbar zu machen. In dieser Phase werden dann auch Testfälle für das Gesamtsystem vorbereitet.

In der nächsten Phase folgt das Systemdesign. Hierbei werden verschiedene Systemlevels entworfen z.B. Gesamtsystem abstrakt, Gesamtsystem HW, Zuordnung HW-SW, Schnittstellendefinitionen etc.. Resultat der Designphase ist ein Grobdesign und ein Feindesign sowie die Definition von Schnittstellen und Protokollen. Es sollte sich ein modularer Aufbau herauskristallisieren auf dessen Basis die Integrationstests vorbereitet werden können. Des Weiteren werden entsprechende Teil-Projekte im GitLab definiert und Arbeitspakete zur Abdeckung der requirements in Bezug auf konkrete Systemkomponenten abzugebilden. Hierbei wird der GitLab Issue-Tracker verwendet um einzelne commits einzelnen Issues und diese Issues requirements und use-cases zuzuordnen. Grund dafür ist die Projektvorgabe jede einzelnen Codezeile mit einem konkreten requirement rechtfertigen zu können um somit vollständige Transparenz zu gewährleisten.

Im Anschluss erfolgt die Implementierungsphase. Hierbei Arbeiten die Entwickler ihre zugeteilten Arbeitspakete ab und führen Statusupdates im Issue-Tracker durch. Einzelne Arbeitspakete gelten als erfüllt, wenn entsprechende Unit-Tests in angemessenem Vorgehen und Umfang vom verantwortlichen Entwickler durchgeführt wurden und nachgewiesen werden können.

Im Anschluss folgt die rekursive Abarbeitung der Testphasen. Sollten größere Probleme auftreten, die das Systemdesign betreffen werden diese für eine weitere Iteration vorbereitet. [PS, AF]

Organisation

Dateiverwaltung

  • Eine Webseite die über diesen Link erreichbar ist dient der Dokumentenverwaltung. Die Verzeichnisstruktur hat folgende Gliederung:
    • alle Bilder
    • Dokumente zu Software & Tools
    • Dokumente zu technischen Informationen
    • Unsere gehaltenen Präsentationen
    • Protokolle unserer Arbeitszeiten
    • Protokolle unserer Kunden-Gespräche
    • Protokolle unserer Professoren-Gespräche
    • Protokolle unserer Statusberichte
    • Protokolle unserer Team-Treffen
    • Sonstige Dateien
  • Die Dateiverwaltung ist Aufgabe der Qualitätssicherung
  • Dateien sind in dem Format <datum>_<dateiname>_<versionsnr.>_<status> anzulegen.
  • Das Datum hat das Format YYYY-MM-DD.
    • Beispiel: 2015-10-22_Zusammenfassung_v1_final
  • Es werden der Status draft und final verwendet.
    • Draft: Das Dokument wird noch bearbeitet
    • Final: Das Dokument hat die Qualitätssicherung durchlaufen und ist für den externen Gebrauch fertiggestellt.
  • Erstellte Dokumente werden an die Qualitätssicherung per E-Mail oder slack versendet und von diesem überprüft und veröffentlich. [TK]

Team-Kommunikation

Slack

Als Kommunikationstool wird slack verwendet. Slack ist ist ein Webtool ähnlich eines Chatrooms mit der Möglichkeit einzelne Kanäle zu bestimmten und Themen anzulegen. Des weiteren bietet Slack die Funktionalität Gruppen anzulegen, Einzelnachrichten und themenbasierte Nachrichten zu versenden. Es sind sieben Kanäle erstellt worden:

  • file-upload_eertraw: Gruppe für Datei-Uploads, welche die Qualitätssicherung zu sichern und prüfen hat
  • fragen_an_betreuer: Gruppe um zukünftige Fragen an die Betreuer zu diskutieren und zu formulieren
  • fragen_an_kunden: Gruppe um zukünftige Fragen an den Kunden zu diskutieren und zu formulieren
  • general: Gruppe zur Nutzung genereller Information für das gesamte Team
  • news_statusupdates: Gruppe zur Nutzung von Statusupdates einzelner Arbeitsaufträge, zur Verbesserung der Arbeitsverteilung durch Abhängigkeiten
  • wiki: Gruppe um Inhalte des Wikis zu besprechen und zu klären

[MM]

appear.in

Um Teambesprechungen Online durchzuführen nutzen wir appear.in. Appear.in bietet die Möglichkeit kostenlos und ohne Installation spezieller Software zu kommunizieren. Der Service ist Plattformunabhängig und läuft im Webbrowser. Bei diesem Webtool ist es möglich eine URL mit Namen zu registrieren. Wir haben https://appear.in/geldwechsel registriert. Marcus Michaely ist Administrator dieser Seite und kann den virtuellen Besprechungsraum freischalten. [MM]

Wiki Nutzung

  • Die Teammitglieder sind selbst dafür verantwortlich ihre Wiki-Beiträge zu erstellen und aktuell zu halten.
  • Änderungen an Beiträgen sind nur mit Absprache des Beitragseigentümers zu tätigen. Rechtschreibkorrekturen sind erlaubt und gewünscht.
  • Bei einem neuem Beitrag oder wichtigen Änderungen sind die Teammitglieder über das Kommunikationstool slack → news_statusupdates zu informieren [PS, NW]

Projekt Vorgehensmodell

  • Das Projekt verwendet ein modifiziertes V-Modell als Vorgehensmodell.

Aufgabenbeschreibung der Nebenfunktionen

  • Projektleiter:
    • Der Projektleiter ist erster Ansprechpartner für die Teammitglieder, den Kunden und der Projektaufsicht.
    • Verteilung von Arbeitsaufträgen und Aktualisierung der Projektstruktur
  • Verwaltung und Kommunikation
    • Administration von Kommunikationstool slack
    • Hilfestellung zur Nutzung für Teammitglieder
  • Toolchain Beauftragter
    • Versionskontrolle der genutzten Tools
    • Evaluation von Tools
    • Installations- und Bedienungsrecherche der zu verwendeten Tools
  • Beschaffung und Qualitätssicherung
    • Administration der Dateiverwaltung
    • Validierung der Dokumente
    • Materialanfrage, Beschaffung und die dazugehörigen Zwischenschritte
  • Git und GitLab Verantwortlicher
    • Administration des Git-Repositories und GitLab.
    • Hilfestellung zur Nutzung für Teammitglieder
  • Wiki Verantwortlicher
    • Administration des Wiki's
    • Hilfestellung zur Nutzung für Teammitglieder

[PS]

Arbeitszeiterfassung

  • Die Arbeitszeiterfassung wird über GoogleDocs geführt.

Milestones

Das Projekt wurde in die Milestones:

  1. Phase Geldwechsler ohne Spendenfunktion
  2. Phase Geldwechsler mit Spendenfunktion. Die Ausgabe eines Spendenbons mit Anleitung weiterer Ablaufschritte, sowie ein zweiter Ausdruck beinhalte die erforderlichen Informationen zur Spende und kann direkt ausgefüllt werden.
  3. Phase Geldwechsler mit Spendenfunktion und Webinterface
  4. Phase Geldwechsler mit Spendenfunktion und LDAP-Integration

Phase 2 war als Alternativ bzw. Zusatzfunktion in der Kundenanforderung aufgeführt, diese wurde im Kundengespräch vom 23.10.2015 geändert. [PS]


Arbeitspakete

SOLL/IST der geschätzten Zeiten der Arbeitspakete

Soll / IST Zeiten der Arbeitspakete
Arbeitspaket: Money Subsystem (MSP)
Teilkomponente Verantwortlicher
SMART-Hopper Firmware Alexander Fratzer
SSP-Lib Alexander Fratzer
Money Device Controller Alexander Fratzer
Arbeitspaket: Init Monitor Subsystem
Teilkomponente Verantwortlicher
Linux Betriebsystem Patrick Schwärzel
Application_Init Patrick Schwärzel
Application_Management_Handler Patrick Schwärzel
Arbeitspaket: Power Supply Subsystem
Teilkomponente Verantwortlicher
Netzteil Torsten Kriegbaum
Unterbrechungsfreie Stromversorgung (USV) Torsten Kriegbaum
Arbeitspaket: Mode Subsystem
Teilkomponente Verantwortlicher
Administration Server Norbert Wesp
Local-Admin-Frontend Norbert Wesp
Remote-Admin-Frontend Norbert Wesp
Donate Change Handler Lukas Schnetzer
Arbeitspaket: Operator Interface Subsystem
Teilkomponente Verantwortlicher
Administrator Interface Torsten Kriegbaum
User Interface Marcus Michaely
Display Administrator Torsten Kriegbaum
Display / Button User (UMI) Marcus Michaely
Printer Marcus Michaely
Arbeitspaket: Log Subsystem
Teilkomponente Verantwortlicher
RAID 1 Patrick Schwärzel
SyslogD Patrick Schwärzel
mail support Alexander Fratzer

[PS]

Analyse

Pflichtenheft (Final Version)

Pflichtenheft (Final Version - mit Änderungen, Abgenommen durch Kunden) [TK]


Requirements

ID Name Beschreibung Status Abhängigkeit 1 Abhängikeit 2 Abhängigkeit 3 Abhängikeit 4 Funktional
1 Geldscheinwechsel-Funktion Benutzer kann Euronote in Euromunzen wechseln lassen ok 4.1.1
1.1 Geldwechselmodus-Standard Geldscheinwechsel-Funktion ist als Standardmodus ok
1.2 Euromunzausgabe Euromünzen ausgeben (0,50€ / 1€ / 2€) ok 4.2
1.3 Euromünzausgabekorrektheit Der Eingabebetrag in Form von Euronoten ist gleich dem Ausgabebetrag in Euromünzen ok 4.4 4.2
1.3.1 Euromünzausgabedifferenz positiv Ausgabebetrag der Euromünzen nicht höher als Eingabebetrag ok
1.3.2 Euromünzausgabedifferenz negativ Ausgabebetrag der Euromünzen nicht niedriger als Eingabebetrag (Fehlersicherheit), ansonsten eindeutige Fehler-Quittung mit Code, Zeitstempel, Eingabebetrag, Ausgabebetrag und eventuelle Fehlerursache ok 4.1.5 1.5
1.4 Euromünzenbestandsbenachrichtigung Bei Unterschreitung des voreingestellten Schwellwerts oder leerem Euromünzenbestand werden die entsprechenden Personen benachrichtigt ok 4.2
1.4.1 Lokale Euromünzenbestandsbenachrichtigung Keine Geldscheinwechsel-Funktion für den Benutzer verfügbar. Entsprechende Bildschirmausgabe. ok 3.1
1.4.2 Verteilte Euromünzenbestandsbenachrichtigung Bei Unterschreitung des voreingestellten Schwellwerts oder leerem Euromünzenbestand wird ein Administrator/Berechtigter benachrichtigt ok 4.1.6
1.5 Euromünzenbestandsprüfung Geldscheinwechselvorgang kann nicht durchgeführt werden, da der Euromünzenbestand nicht ausreichend ist. Entsprechende Bildschirmausgabe und Rückgabe der Euronote. ok 4.2 4.5.1
1.6 Bon-Berechtigung Normaler Benutzer (Nicht-Spender) bekommt im Regelablauf kein Bon (Fehlersicherheit) ok
2 Spenden-Funktion Benutzer kann Spende an gemeinnützigen Verein tätigen ok 4.5.1
2.1 Spendenmodus-Hinweis Es muss expliziet hingewiesen werden, dass der Benutzer gerade die Spenden-Funktion nutzt ok 4.2 4.5.1
2.2 Spendenausfallsicherheit Die Spende-Funkion muss eine Ausfall-/Fehlersicherheit von 99,99% gewährleisten ok 2.5
2.2.1 Persistenz des Speichervorganges Spendenvorgang darf im Fehlerfall nicht verloren gehen (Fehlersicherheit und Speichersicherheit) ok
2.3 Korrektheit des Spendenbetrags Spendenbetrag auf Bon muss stimmen (Fehlersicherheit) ok 4.4 4.2
2.4 Spendenquittungsinformation Automat druckt einen eindeutigen Bon mit Anleitung der weiteren Spendenschritten aus ok 4.1.5
2.5 Spendenbenachrichtigung Nach einer Spende wird der Kassenwart benachrichtigt ok 4.1.6 4.2
2.6 Spendenunterbrechbarkeit Spendenvorgang kann jederzeit abgebrochen werden ok 4.4 4.2
2.6.1 Ein-Schein-Unterbrechbarkeit Wurde nur eine Euronote in den Automaten eingefügt, so wird diese nach Bestätigung nicht mehr zurückgegeben ok
2.6.2 Mehr-Schein-Unterbrechbarkeit Will der Nutzer mehr als eine Euronote im Spendenmodus einfügen, wird er explizit darauf hingewiesen, dass

eine vollständige Rückerstattung nur durch einen Berechtigten persönlich abgewickelt werden kann

ok
2.7 Spendenformular-Web-Interface Web-Interface um Spendenformular auszufüllen und zu drucken prüfung
2.8 Spendenablauf-Web-Interface Web-Interface um Spendenvorgang nachzuschauen prüfung
3 Administration/Konfiguration Administratoren/Berechtigte können administrative Tätigkeiten vornehmen ok 4.5.1
3.1 Administratives HW-Interface Im Admin-Modus kann der registrierte Administrator/Berechtigte Einstellungen über eine Schnitstelle vornehmen ok 4.5.1
3.2 Euronotenleerungsmöglichkeit Administratoren/Berechtigte können Euronoten entnehmen ok 4.2 3.1
3.3 Euromünzennachfüllmöglichkeit Administratoren/Berechtigte können Euromünzen nachfüllen ok 4.2 3.1 4.4
3.3.1 Euromünznachfüllmöglichkeit (manuell) Administratoren/Berechtigte können neue Euromünzen einfüllen und die Anzahl der eingefüllten Euromünzen manuell eingeben ok
3.4 Administrative Einstellungen Administrator/Berechtigte kann allgemeine administrative Tätigkeiten vornehmen ok 3.1 3.5 4.2
3.4.1 Euronotenannahme-Konfiguration Bestimmte Euronoten können gesperrt/abgelehnt werden ok 4.1.2.1
3.4.2 Log-Abrufung Alle Logs können eingesehen werden ok
3.4.3 Modus-Konfiguration Automaten-Modi sollen de-/aktiviert werden können ok
3.4.4 Systemstatus Der Systemstatus kann übersichtlich abgerufen werden ok
3.4.5 Benutzerverwaltung Administration-Accounts können angelegt, gesperrt oder gelöscht werden ok
3.5 Remote-Administration Remote-Zugriff um Einstellungen am Automaten vorzunehmen ok 4.2
3.5.1 Sicherheit-Remotezugriff Remote-Zugriff soll Sicherheitsstandards besitzen, um unbefugten Zugriff zu verhindern ok 4.3
3.5.1.1 LDAP-Integration Benutzerauthentifikation über LDAP-Server zur Konfiguration ok
4 Generelles Allgemeine Anforderungen an das System ok
4.1 Funktionalität Automat muss angemessene Funktionalität bieten ok
4.1.1 Betriebsmodi Geldscheinwechsel-, Spenden-, Administrationsmodus ok 4.2
4.1.2 Euronotenannahme Euronoten können vom Automaten angenommen werden ok
4.1.2.1 Angemessene Scheinannahme Euronotenannahme 5€, 10€, 20€ (alt + neu), 50€ (alt) ok
4.1.3 Euronotenprüfung Euronoten werden überprüft ok 4.2
4.1.4 Mehr-Schein-Funktion Im Spendenmodus ist die mehrfache Annahme mehrerer Euronoten hintereinander möglich ok 4.2
4.1.5 Quittierungsmechanismus Papierquittung/Bon drucken ok 4.2
4.1.6 Benachrichtigungsfunktion Möglichkeit Benachrichtigungen an einen Administrator/Berechtigten über Netzwerk (z.B. per E-Mail) zu senden ok
4.2 Logging Alle Änderungen/Vorgänge werden im System geloggt (Zeitstempel, Benutzer, Aktivität/Ergebnis) ok
4.2.1 Speichersicherheit Alle essentiellen Daten werden persistent und sicher gespeichert ok
4.2.2 Transaktionssicherheit Alle Logvorgänge müssen Transaktionssicher und im Falle

von Systemversagen vollständig (wiederherstellbar) sein

ok 0.5.1
4.3 Sicherheit System muss sicher sein ok
4.3.1 Sichere Euronotenannahme Kein Vortäuschen einer Euronote (Hardware-Sicherheit) ok 4.2
4.3.2 Serieller Geldscheinprüfer Geldscheinprüfer wird über eine serielle, verschlüsselte Verbindung angesteuert ok
4.3.3 Serieller Münzhopper Münzhopper werden über eine serielle, verschlüsselte Verbindung angesteuert ok
4.3.4 Komponentenansteuerung Kein externes Bedienen des Münzhoppers möglich (Hardware-Sicherheit) ok
4.4 Fehlerbehandlung System protokolliert mögliche Fehler und benachrichtigt die Administratoren/Berechtigten. Automatische Funktionseinschränkung anhand der Systemfehleranalyse ok
4.4.1 Quittung im Fehlerfall Im Fehlerfall wird eine Quittung mit entsprechenden Informationen gedruckt ok 4.2 4.1.5
4.4.2 Autonomität Automat soll autonom funktionieren (ohne Netzwerk) ok
4.4.3 Stromausfallsicherung Automat verfügt über eine Stromausfallsicherheit, um das System ordnungsgemäß zu beenden ok 4.2.2
4.4.4 Fehlerbenachrichtigung Bei Fehlern wird der Kassenwart benachrichtigt ok
4.4.4.1 Verteilte Fehlerbenachrichtigung Fehlermeldung wird per Email versendet ok 4.1.6
4.4.5 Datenvalidität Redundante Datenhaltung (z. B. durch RAID) ok 4.2
4.5 Benutzerfreundlichkeit Der Automat besitzt eine benutzerfreundlich Bedienungsoberfläche ok
4.5.1 Benutzerinteraktion Die Kommunikation zwischen dem Automaten und Benutzer findet über ein Display und Bedienelement (Knöpfe oder Klickwheel) statt. ok 4.2
4.6 Leistungsverbrauch im Idle Der Idle-Leistungsverbrauch des Geldscheinwechsel-Automats beträgt 10 Watt (+/- 5 Watt) ok

Diagramme zu Top-Level übergreifende Beziehungen. [PS, AF, MM, TK, LS, NW]


Anwendungsfälle

ID Name Beschreibung Status
UC1 Euronote in Euromünzen wechseln Ausgabe von gleichwertigem Geldwert einer Euronote in Euromünzen draft
UC2 Geld spenden Automat registriert die Spende und gibt einen Bon mit Anleitung der weiteren Spendenschritte aus draft
UC2.1 Spende abschließen (Webserver) Benutzer schließt die Spende über einen Webserver ab draft
UC2.2 Spende abschließen (Kassenwart) Benutzer schließt die Spende über Kassenwart ab draft
UC3-a Administration Administrator/Berechtigter tätigt administrative Aufgabe (abstract) -/-
UC3.1 Administration-Login (lokal) Administrator/Berechtigter meldet sich lokal am System an draft
UC3.1.1 Aktionsauswahl aus Admin-Menü (lokal) Administrator/Berechtigter wählt lokal beliebige Aktion im Menü aus draft
UC3.1.1.1a Euromünzen auffüllen (manuell) Administrator/Berechtigter füllt Euromünzen in den Automaten draft
UC3.1.1.1b Euromünzen ausgeben Administrator/Berechtigter lässt sich alle Euromünzen einer Sorte ausgeben draft
UC3.1.1.2 Euronoten leeren Administrator/Berechtigter leert Geldscheinkontainer draft
UC3.1.1.3 Euronote sperren/entsperren (lokal) Administrator sperrt/entsperrt Euronote für bestimmten Modus draft
UC3.1.1.4 Log durchsuchen (lokal) Administrator durchsucht Systemlog nach Eintrag draft
UC3.1.1.5 Statusabfrage (lokal) Administrator/Berechtigter lässt sich Systemstatus anzeigen draft
UC3.1.1.6 Modus sperren/entsperren (lokal) Administrator kann Modi sperrt/entsperren draft
UC3.1.1.7 System herunterfahren (lokal) Administrator fährt das System ordnungsgemäß herunter draft
UC3.1.1.8 Accountadministration (lokal) System befindet sich im Account-Verwaltungsmodus draft
UC3.1.1.8.1 Neuen Berechtigten-Account anlegen (lokal) Neuen Berechtigen-Account im System anlegen draft
UC3.1.1.8.2 Vorhandenen Berechtigten-Account löschen (lokal) Ausgewählter Berechtigten-Account ist aus dem System gelöscht draft
UC3.1.1.8.3 Kennwort eines Berechtigten-Accounts ändern (lokal) Kennwortänderung des ausgewählten Berechtigten-Accounts draft
UC3.1.1.8.4 Vorhandenen Berechtigten-Account deaktivieren/aktivieren (lokal) Ausgewählter Berechtigten-Account ist in dem System deaktiviert/aktiviert draft
UC3.1.1.9 Administration-Logout (lokal) Angemeldeter Administrator/Berechtigter wird ausgeloggt draft
UC3.1.1.10 Automatischer Logout (lokal) Angemeldeter Administrator/Berechtigter wird ausgeloggt und Administrator/Berechtigter benachrichtig draft
UC3.1.2 Gehäuse wurde geschlossen (lokal) System wechselt vom Administrator-Modus in den Geldscheinwechsel-Modus draft
UC3.2 Administration-Login (verteilt) Administrator/Berechtigter meldet sich remote über das Web-Interface an draft
UC3.2.1 Aktionsauswahl aus Admin-Menü (verteilt) Administrator/Berechtigter wählt remote beliebige Aktion im Web-Interfae aus draft
UC3.2.1.1 Euronote für bestimmten Modus sperren/entsperren(verteilt) Administrator sperrt/entsperrt Euronote für bestimmten Modus draft
UC3.2.1.2 Log durchsuchen (verteilt) Administrator durchsucht Systemlog nach Eintrag draft
UC3.2.1.3 Statusabfrage (verteilt) Administrator/Berechtigter lässt sich über Web-Interface den Systemstatus anzeigen draft
UC3.2.1.4 Modus sperren/entsperren (verteilt) Administrator kann Modi sperrt/entsperren draft
UC3.2.1.5 System herunterfahren (verteilt) Administrator fährt das System ordnungsgemäß herunter draft
UC3.2.1.6 Accountadministration (verteilt) Administrator befindet sich remote im Account-Verwaltungsmodus draft
UC3.2.1.6.1 Neuen Berechtigten-Account anlegen (verteilt) Neuen Berechtigten-Account im System anlegen draft
UC3.2.1.6.2 Vorhandenen Berechtigten-Account löschen (verteilt) Ausgewählter Berechtigten-Account ist aus dem System gelöscht draft
UC3.2.1.6.3 Kennwort eines Berechtigten-Accounts ändern (verteilt) Kennwortänderung des ausgewählten Berechtigten-Accounts draft
UC3.2.1.6.4 Vorhandenen Berechtigten-Account deaktivieren/aktivieren (verteilt) Ausgewählter Berechtigten-Accountist in dem System deaktiviert/aktiviert draft
UC3.2.1.7 Administration-Logout (verteilt) Angemeldeter Administrator/Berechtigter wird ausgeloggt draft
UC4 Euronote prüfen Euronote auf Echtheit und Zulässigkeit prüfen draft
UC5 Euromünzenbestand prüfen Euromünzenbestand wird überprüft und bei erreichen des Schwellwerts ein Administrator/Berechtigter benachrichtigt draft

Diagramme zu den/dem Anwendungsfällen/System, [LS, TK, NW] Zuordnung der UseCases zu den Requirements als Diagramme [LS, AF]

Design

Grobentwurf (Option 1)

caption

Hauptfokus des Designs liegt auf dem hohen Maß an Sicherheit, das vom Kunden gefordert wird. Das System wird voraussichtlich in einem Umfeld betrieben, in dem Untersuchungen der Sicherheitsaspekte z.B. durch Penetrationstests nicht ausgeschlossen sind. Ein weiterer Aspekt für den vorgestellten Systementwurf basiert auf der Annahme, dass die zur Verfügung gestellte Hardware in erster Linie aus Raspberry Pi's Model B+ besteht. Die Erfahrungen der Projektteilnehmer stimmt darin überein, dass es sich bei den B+ Pi's um solide zuverlässige Hardware handelt. Ein weiterer Vorteil in der Verwendung des B+ ist eine offene und hilfsbereite Entwickler-Community und ein einfach zu portierendes, vom Hersteller unterstütztes BSP bestehend aus einem Linux. Ein großer Nachteil ist jedoch der verhältnismäßig schwache Singlecore Prozessor (ARM11). Um die geforderten Sicherheitskriterien zu erfüllen weißt das System deswegen einen verteilten Charakter auf. Das Gesamtsystem besteht aus mindestens zwei Raspberry PI B+ (im Folgenden als Pi A und Pi B beszeichnet)und einem Arduino Uno zur Ansteuerung der Interaktionskomponenten (Display, Numpad, etc.). PI A fungiert als Master. Auf diesem befindet sich die Hauptlogik des Systems, welches die verschiedenen Nutzermodi offeriert und durch ein RAID1 einen persistenten Systemlog führt. Schnittstellen nach außen (z.B. Remote Administration Interface) werden auf einen eigenen Pi verlagert. Die Kommunikation der Komponenten wird mit RPC-Mechanismen über eine Ethernet-Schnittstelle durchgeführt. Ein weiteres Sicherheitsrisiko liegt in der Anforderung, dass Spender ihre Spenden über ein Webinterface bestätigen können. Dieses Webinterface bietet somit eine große Angriffsfläche. Zusammen mit der Schwachen Singlecore CPU des B+, wäre es einfach das Gesamtsystem mit einem DoS-Angriff handlungsunfähig zu machen. Die einfachste Möglichkeit diese Fläche zu minimieren ist die Verlagerung der Webschnittstelle in das Vereinssystem selbst, was jedoch in der Analyse ausgeschlossen wurde. Somit wird ein weiterer PI (C) benötigt auf dem die Schnittstelle offeriert wird. Im Gegensatz zum Administrationsinterface (PI B) ist das Webinterface nicht räumlich an den Automaten gebunden was das Vorhandensein von drei PI's im System rechtfertigt. Eine weitere Platine (Teensy 3.2) wird als Protokoll-Converter für die Münzhopper eingesetzt. Die zur Verfügung gestellten Münzhopper können nur Parallel angesteuert werden, was in Konflikt mit diversen Anforderungen des Kunden steht (Wunsch auf SMART Hopper Integration und Verschlüsselte Serielle Kommunikation mit Hopper). Ein weiterer Aspekt für den Einsatz der Teensy 3.2 Platine liegt in der zeitlichen Beschränkungen des parallen Protokolls der Hopper. Zur Umsetzung müssen Flanken im Bereich von 5ms abgefangen und verarbeitet werden, was auf dem B+ nur mit der Entwicklung eines Kerneltreibers oder einem RealTime OS gewährleistet werden kann. Auf dem Teensy wird somit ein FreeRTOS portiert. Die Kommunikation Richtung Master wird durch das SSP Protokoll der Firma Innovative Technology Ltd umgesetzt.
Vorteile:

  • bietet durch seinen verteilten Charakter ein hohes Maß an Sicherheit und verbesserte Nutzung von benötigter Rechenleistung.
  • Durch eine konsequente Modularisierung ist es möglich einen 24/7 Betrieb anzubieten, da Hardwarekomponenten extern vorbereitet Bespielt und in vernachlässigbar kleinen Wartungsfenstern ohne großes Fachwissen ausgetauscht werden können.


Nachteile:

  • hohe Implementierungsaufwand durch Realisierung von RPC Mechanismen und Sicherheitsprotokollen über die interne Ethernet-Schnitstelle
  • hoher Stromverbrauch und eine hohe Komplexität

Fazit: Aus diesem Grund wird sich gegen das vorgestellte Design entschieden und ein anderer Ansatz verflogt.

Angelehnt an das Design und die Arbeitspakete lässt sich das System folgendermaßen modularisieren:

Das oben vorgestellte Design deckt alle Anforderungen zufriedenstellend ab. Diagramme für eine Zuordnung der Systemkomponenten zu den Requierments befinden sich hier. [AF]


Grobentwurf (Option 2)

Grobentwurf modularer Aufbau Grobenentwurf Verantwortlichkeiten


Option 2 bietet eine abstraktere Sicht auf das Gesamtsystem als Option 1. Mittelpunkt dieses Designs ist eine schwächere Orientierung an vorhanden Hardwarekomponenten und Sicherheitskriterien und ein stärkerer Fokus auf geringeren Stromverbrauch und überschaubarem Entwicklungsaufwand. Schlüsselrolle bildet das Steuermodul, welche durch ein Raspberry Pi2 realisiert wird. Der Rasperry Pi2 verfügt über eine ARM Cortex-A7 Quadcore-CPU mit stärkerer Singlecore Leistung als der ARM11 des Pi B+. Hierdurch fällt die Notwendigkeit weg, das System über diverse Hardwarekomponenten zu verteilen um Ausfallsicherheit durch z.B. DoS-Attacken zu realisieren, da im Worst-Case nur ein Core überlastet, was die Verfügbarkeit der Grundfunktionalität jedoch nicht zwingend beeinträchtigt. Des Weiteren ist auf dem PI 2 genug Rechenleistung vorhanden um jeden geforderten Service problemlos anbieten zu können. Der Einsatz einer zusätzlichen Platine als Protokollwandler ist dennoch erforderlich und wird in diesem Design übernommen. Dieser Ansatz bietet den Projektteilnehmern mehr Freiheit bei der Umsetzung ihrer Arbeitspakete. [PS]

Beschreibung der aufgeführten Komponenten:

Hardware-Layer (HW):

  • Printer:
    Verwendung zur Spenden-, Fehler- und Admin-Belegbehandlung. In beiden Fällen wird ein Ausdruck ausgegeben.
    Der User Interface Prozess ist für die Ansteuerung verantwortlich.
  • User Machine Interface (UMI-> Display, Knöpfe, Sensor):
    Display und Funktionsknöpfe zur Kommunikation zwischen Benutzer und Geldscheinwechsel-Automat. Die Funktionsknöpfe bieten Bestätigungs-, Abbruchs- und Spendenfunktionalität. Der User Interface Prozess ist für die Ansteuerung verantwortlich. Zusätzlich registriert das UMI, ob der Geldscheinwechsel-Automat geöffnet wurde und sendet eine Meldung an den Mode Process.
  • Admin Display:
    Das Administrator Display ist direkt mit dem Raspberry Pi2 verbunden und nur im geöffneten Zustand des Geldscheinwechsel-Automaten bedienbar. Die Administrationsoberfläche wird über das Touchdisplay bedient. Die Funktionalität ist verbunden mit dem local-Admin-Frontend (siehe Lokal-Admin-Frontend) und der Administrator Interface Prozess ist für die Ansteuerung verantwortlich.
  • Raspberry Pi2 (PI2):
    Der Rasperry Pi2 verfügt über eine ARM Cortex-A7 Quadcore-CPU und 1GB Arbeitsspeicher.
  • Speichermedium F0 und F1:
    Zwei USB Speichersticks werden als Speichermedium verwendet.
  • Netzteil (PS):
    Das Netzteil hat die verschiedenen Spannungsvoraussetzungen zu erfüllen.
  • Unterbrechungsfreie Stromversorgung (USV):
    Die USV ist Bestandteil der Kannkriterien und dient dem ordnungsgemäßen Herunterfahren des System bei Stromausfall. Sollte sich der Automat aktiv in einem Geldscheinwechsel- oder Spendenvorgang befinden so kann dieser zwar nicht ordnungsgemäß durchgeführt werden, jedoch können mit Sicherheit die entsprechenden Log-Einträge getätigt werden um die durchgeführten Schritte nachvollziehen zu können.
  • Note Acceptor:
    Nimmt voreingestellte Euronoten an, prüft diese auf Echtheit und gibt entsprechende Information an den Money-Device-Controller weiter.
  • Smart Converter Board:
    Das Smart Converter Board ist für die parallele Ansteuerung der Geldhopper zuständigen.

Operation System Layer (OS):

  • Linux:
    Das offiziell von RaspberryPi unterstützte Linux, auf Debian basierende, Betriebssystem Raspbian (Wheezy) wird verwendet.
  • RAID:
    Ein zusätzlicher Datenspeicher wird in Form von zwei USB-Sticks im Raid-Level 1 angeschlossen. Der Geldscheinwechsler speichert Daten, die den Geldscheinwechsel-, Spendenvorgang und die Störungsmeldung protokoliert. Diese Daten besitzen nicht nur für den Eigentümer eine besondere Wichtigkeit, sondern sind auch ein Nachweis der getätigten Geldscheinwechseltransaktion gegenüber dem Benutzer.
    Aus diesem Grund wurde eine Spiegelung des Datenspeichers verwendet. Das Risiko von Datenverlust durch Laufwerksausfälle ist somit abgesichert und auf ein tragbares Limit minimiert.
    Die Logdaten der oben erwähnten Aktion sind auf diesem Speichermedium persistent gespeichert. Die Geldscheinwechsel Applikation und Hilfsprogramme befinden sich auf der internen SD-Speicherkarte und werden als Wiederherstellungs-Image dem Gerät beigefügt.
  • FreeRTOS:
    Das RealTimeOperatingSystem ist auf dem Smart Converter Board portiert und offeriert ein Task- und Memorymanagement Modell.
  • Hopper Driver:
    Der Hopper Driver implementiert das Protokoll zur Ansteuerung der parallelen Münz-Hopper.

Support Layer (SUP):

  • SyslogD:
    Syslog ist ein Standard zur Übermittlung von Log-Meldungen. Geldscheinwechsel-, Spendenvorgänge, administrative Änderungen und Fehlermeldungen werden in die entsprechenden Log-Files geschrieben.
  • SmtpD:
    Der Smtp Daemon offeriert die Möglichkeit Administratoren/Berechtigte via E-Mail über Gerätestatus und Fehler zu informieren.

Application Layer (APP):

  • Application Init Prozess:
    Nachdem das Linux sein Startvorgang beendet hat, wird der Application Init Prozess gestartet. Der Application Init Prozess erzeugt anschliessend die Prozesse:
    1. Application Monitor/Err Handler
    2. User Interface
    3. Money-Device-Controller
    4. Administrator Interface
    5. Administrator Server
    6. Mode Process
  • Application Monitor/Err Handler Prozess:
    Der Application Monitor/Err Handler Prozess überwacht den Application Init Prozess und dessen Kinderprozesse. Die Überwachung findet über Shared Memory Objekte und einer Transaktionsdatei (Lock-Files) statt. Die Prozesse schreiben ihren Status periodisch in die Shared Memory Objekt. Die Mode Unit hat ein zusätzliches Lock-File um die einzelnen Transaktionsschritte eines Spenden- oder Wechselvorganges festzuhalten.
    Im Fehlerfall ist die Lockdatei > 0 Byte und entsprechende Informationen werden durch den Application Monitor/Err Handler zusammengefasst und über den smtpd an die verantwortliche Person versendet. Ein Fehler wird erst nach interner Fehlerbehandlung der verantwortlichen Prozesse an den Application Monitor/Err Handler weitergereicht und eine entsprechende Fehlerbehandlung eingeleitet.
    Auslöser können sein:
    • Fehler durch Note Acceptor führt zu Gesamtausfall
    • Fehler durch SmartHopper führt zur Sperrung des Wechselmodus. Geldwechselautomat kann weiter im Spendenmodus betrieben werden.
    • Fehler durch Drucker führt zu Gesamtausfall. Es besteht keine Möglichkeit des Drucks einer Fehlerquittung oder Spendenbons.
    • Fehler durch User Machine Interface führt zu Gesamtausfall, da keine Möglichkeit der Kommunikation mit Anwender besteht.

    Im Fehlerfall wird die Transaktionsdatei überprüft, relevante Information für die Fehlermeldung zusammengefasst und an die verantwortliche Person über den smtpd versendet.

  • Money-Device-Controller:
    Aufgabe des Money-Device-Controller ist die Ansteuerung der Geldperipherie. Er informiert den MP (Mode Process) über Ereignisse am Note Acceptor und nimmt vom MP Befehle zur Ausgabe von Euromünzen an. Hierbei verwendet er das SSP-Protokoll (ITL). Außerdem versucht er ein höchstmaß an Fehlerabstraktion an den angesteuerten Geräten in Systemrichtung durchzusetzen.
  • Converter:
    Der Converter ist die Software-Komponente des Smart Converter Boards. Er ist verantwortlich für die Umsetzung der SSP-Kommandos und der offeriertung der SMART-Hopper Funktionalität.
  • Mode Process:
    Der Mode Process ist die zentrale Einheit des Automaten und sorgt für die Kommunikation der Subsysteme untereinander. Der Prozess implementiert die Hauptlogik der Geldscheinwechsel- und Spendenvorgänge und nutzt dabei die Schnittstellen der anderen Subsysteme. Die Hauptaufgaben des Prozesses liegen darin, für einen geregelten Ablauf des Geldscheinwechsel- bzw. Spendenvorgangs zu sorgen und zwischen den verschieden Automatenmodi zu wechseln. Die Kommunikation zu den anderen Subsystemen wird mit FIFOs realisiert. Beim Start des Systems wird ein Thread für „Geldscheinwechseln“ und „Spenden“ (modeUnit-Thread) und ein Thread für den „Heartbeat“ gestartet. Der modeUnit-Thread schläft an der FIFO bis zum Erhalt einer Nachricht und regelt entsprechend den weiteren Ablauf des Systems.
  • Administration Server Prozess:
    Der Administration Server Prozess ist die Kommunikationsschnittstelle zwischen den administrativen Frontends und dem System. Der Prozess implementiert die Logik aller administrativen Tätigkeiten, welche lokal sowie remote am System durchgeführt werden können. Für die Kommunikation zu den Frontends stellt dieser Prozess FIFOs bereit. Eingehende Nachrichten werden hier identifiziert, entpackt, ausgeführt und ggf. an den Mode Process weitergeleitet.
  • User Interface Prozess:
    Der User Interface Prozess ist die Kommunikationsebene zwischen dem User Machine Interface und den Knöpfen. Somit dient er der Kommunikation mit dem Benutzer. Zusätzlich meldet der User Interface Prozess dem Mode Process, wenn die Tür des Automaten geöffnet würde.
  • Administrator Interface Prozess:
    Der Administrator Interface Prozess ist die Kommunikationsebene zwischen dem Administrator Server Prozess und dem Local-Admin-Frontend. Der Prozess steuert das Admin Display an und erzeugt eine GUI um die administrativen Tätigkeiten durchzuführen.
  • Local-Admin-Frontend:
    Das Local-Admin-Frontend stellt eine Benutzeroberfläche für die lokale Administration des Systems bereit. Das lokale Frontend bekommt die Eingaben des Administrators/Berechtigten über den Administrator Interface Prozess und übermittelt diese mittels FIFOs in einem bestimmten Aufbau an den Administration Server Prozess.
  • Remote-Admin-Frontend:
    Das Remote-Admin-Frontend stellt eine Benutzeroberfläche für die verteilte Administration des Systems bereit. Die Eingaben des Administrators/Berechtigten werden hier in entsprechende Nachrichten gepackt und versendet. Da die Kommunikation über dieses Frontend zum System über das Netzwerk läuft wird diese aus Sicherheitsgründen für den Weg der Übertragung zum Webserver des Systems verschlüsselt und ab dort wieder unverschlüsselt zum Administration Server Prozess weitergeleitet.
  • Donate Validator:
    Der Donate Validator Prozess erhält relevante Daten vom Geldwechselautomaten um einen Spendenvorgang über einen Webserver abzuschliessen. Der Spender füllt die entsprechenden Informationen im Webformular aus und durch Bestätigung werden diese Information in ein Latex-Template eingefügt und kompiliert. Das entstandene PDF-Dokument wird als E-Mail an den Kassenwart gesendet.

[PS, LS, AF, MM, TK, NW]


Modularer Aufbau

caption

Modular lässt sich das System in die Hauptkomponenten unterteilen:

  • log_subsystem: Verantwortlich für die Erstellung, Verfügbarkeit und Konsistenz des Logs, somit umfasst dieses Subsystem auch das RAID.
  • donate_validator: Spenden Validierungs-Server um einem Berechtigten alle nötigen Informationen zur Nachvollziehbarkeit von getätigten Spenden zukommen zu lassen.
  • operator_interface_subsystem: Verantwortlich für die Lokale Darstellung von notwendigen Informationen auf den Displays (User und Administrator).
  • mode_subsystem: Hauptlogik für die Abwicklung von den drei Hauptmodi: Wechsel, Spende und Administration.
  • money_subsystem: Verantwortlich für die Interaktion mit der Geld-Peripherie insbesondere Hopper und Geldscheinvalidierer.
  • init_monitor_subsystem: Verantwortlich für Erstellung und Monitoring aller wichtigen Systemprozesse.
  • power_supply_subsystem: Stromversorgung der verschiedenen Hardwarekomponenten.

Die weitere Strukturierung der Module wird im entsprechenden Feindesign genauer spezifiziert. [AF]

Hardware Layout

caption

Das MCB (Main Controller Board - Rapberry PI 2) verfügt standardmäßig über vier USB Ports. Benötigt werden mindestens sieben, daher wird ein Hub(4x) eingeplant, der jedoch ohne externe Stromquelle auskommen sollte. Je nach Qualität des ausgewählten HUBs bleibt zu entscheiden ob das RAID1, bestehend aus zwei Flash-Speichern, an den HUB oder direkt an den PI2 selbst angeschlossen werden sollte. Dieses Layout ist vorläufig und wird im Feindesign unter Power-Supply weiter ausgeführt und ggf. angepasst. [NW]

gestellte Hardware

Raspberry Pi 2

Zustand: Neu
Funktion: MasterController
Der Raspberry Pi 2 wird als Hauptsteuereinheit im Geldwechselautomaten verwendet. Das offizielle von RaspberryPi unterstützte Linux, auf Debian basierende, Betriebssystem Raspbian Jessie wird verwendet.
Ein zusätzlicher Datenspeicher wird in Form von zwei USB-Sticks im Raid-Level 1 angeschlossen. Der Geldwechsler speichert Daten, die den Geldwechsel-, Spendenvorgang und die Störungsmeldung protokoliert. Diese Daten besitzen nicht nur für den Eigentümer eine besondere Wichtigkeit, sondern sind auch ein Nachweis der getätigten Geldwechseltransaktion gegenüber den Nutzer.

Aus diesem Grund wurde eine Spiegelung des Datenspeichers verwendet. Das Risiko von Datenverlust durch Laufwerksausfälle ist somit abgesichert und auf ein tragbares Limit minimiert.

Die Logdaten der oben erwähnten Aktion sind auf diesem Speichermedium persistent auf einem RAID-Level 1 gespeichert. Die Geldwechsel Applikation und Hilfsprogramme befinden sich auf der internen SD-Speicherkarte und werden als Wiederherstellungs-Image dem Gerät beigefügt.

Es wird das Software-Raid mdadm verwendet. Mdadm ist ein Freie Software, lizenziert under den Bedienungen von GNU General Public License Version 2 oder später, Linux Dienstprogramm um Software-Raid Speichermedium zu managen und zu überwachen.

Scheinakzeptor

Funktion: Annehmen, Prüfen und sicheres Aufbewaren der aktzeptierten Geldscheine. Kommunkikation mit der Steuerung des Systems.
Hersteller: http://innovative-technology.com/de/
Modell: NV9
Zustand: Gebraucht und auf volle Funktionsfähigkeit von Herr Kai Beckmann getestet.
Wie wurde das Gerät in das Projekt eingebracht: Die Hardware wurde zu Begin des Projektes von Herrn Beckmann zu verfügung gestellt.
Datenblatt: selbst recherchiert: http://www.cs.hs-rm.de/~tkrie001/wahlprojekt/.draft/Dokumente_Technische-Infos/Geldscheinpruefer/Geldscheinpruefer_NV9.pdf

Münzhopper

Funktion: Quantifizierte Ausgabe von Münzen aus einem Sammelbehälter. Fehlermeldung bei Fehlfunktion. Kommunikation mit der Steuereinheit des Systems.
Hersteller:http://www.azkoyenpaymenttechnologies.com/hoppers
Modell:: Hopper-U
Zustand: Gebraucht und auf volle Funktionsfähigkeit von Herr Kai Beckmann getestet.
Wie wurde das Gerät in das Projekt eingebracht: Die Hardware wurde zu Begin des Projektes von Herrn Beckmann zu Verfügung gestellt.
Testbericht: 1. Testbericht 06-11-2015
Datenblatt: selbt recherchiert: http://www.cs.hs-rm.de/~tkrie001/wahlprojekt/.draft/Dokumente_Technische-Infos/Muenzhopper/MuenzHopper_u.pdf

Thermodrucker

Hierbei handelt es sich um eine Thermodrucker der Fima Adafruit
Funktion: Bedrucken von Thermopapierrollen mit Kommunikation über serielle Schnittstelle
Hersteller: adafruit
Zustand: neu
Wie wurde das Gerät in das Projekt eingebracht: Herr Beckman hat dieses Gerät zur Verfuegung gestellt
Datenblatt: http://www.adafruit.com/datasheets/cashino%20thermal%20printer%20a2.pdf
Inbetriebnahme
Der an den seriellen Port des Druckers wurde ein USB-/TTL-Adapter angeschlossen. Als Spannungsversorgung dient ein Netzteil mit 5Volt und 2A. Der Drucker zieht beim Drucken temporär bis zu 2 Ampere (Ausgemessen mit Voltmeter) Durch den USB/TTL-Adapter erscheint der Drucker als virtueller COM-Port im Linuxsystem unter /dev/ttyUSB0 Angesprochen wurde der Drucker für die Tests mit der vom Hersteller Adafruit zur verfügung gestellen Pythonbibliothek. Die Bibliothek findet sich unter [1] Zum Testen wurde folgender Demoausdruck erstellt:
Spendenbon draftV1.JPG Anschluesse printer.jpg

2.8" TFT-Display mit Touch (Admin-Interface)

Zustand: Neu

Funktion: Das Display dient der lokalen Administration des Geldscheinwechsel-Automaten.

Spezifikation:

  • TFT-Display: 2.83", 240x320 (Transmissiv)
  • Sichtfeld: 43.2 x 57.6mm
  • Touch Controller: TI ADS7846/TSC2046
  • Hintergrundbeleuchtung dimmbar (PWM)
  • Schnittstelle: SPI (Touch Controller + Display)
  • 3 Taster
  • GPIOs über 40-Pin FFC/ZIF-Steckverbinder erreichbar
  • Power: 5V
  • Raspberry Pi HAT Pinout (40 Pins)
  • Hergestellt in Deutschland

GitHub: https://github.com/watterott/RPi-Display

Online-Store: http://www.watterott.com/de/RPi-Display-B-Plus [MM]

zusätzliche Hardware

  • zwei Flash-Speicher
  • Teensy 3.2
  • Level Shifter
  • zwei Buttons
  • Pi USV
  • Netzteil

[NW]

Testaufbau

User Interface Front.JPG

Alle Informationen zum User Interface finden sich hier


Software in Test: https://github.com/fdebrabander/Arduino-LiquidCrystal-I2C-library/tree/master/examples

https://github.com/fdebrabander/Arduino-LiquidCrystal-I2C-library [MM]

Übersicht Hauptprozesse

caption

Die oben vorgestellten Prozesse agieren überwiegend autonom. Für die IPC der Prozesse untereinander werden deswegen FIFOs verwendet. Für jede Kommunikation zwischen zwei Prozessen gibt es immer zwei FIFOs, eine zum Senden und eine zum Empfangen von Nachrichten (A->B und A<-B). Die Nachrichten sind überwiegend Kommandos und Rückgabewerte in der Größenordnung weniger Bytes. Deswegen bringt eine Kommunikation mittels Shared Memory und POSIX Semaphoren mehr Nachteile durch erhöhten Synchronisierungsaufwand als Vorteile durch schnelleren Datenaustausch. Jeder Prozess, der vom Application Init Process gestartet wird, startet zuerst einen heartbeat-Thread. Jeder dieser Threads ist einzig für die Rückmeldung an den Application Monitor Handler Process mittels prozesszugeordnetem Shared Memory Segment (*_shm) zuständig. Das Admin-Web-Frontend ist zwar kein eigener Prozess, welcher durch den Application Init Process gestartet wird, aber aufgrund der Kommunikation mit dem Administration Server Process über FIFOs wird es hier mit ausgeführt. Verwendete Protokolle werden im entsprechenden Feindesign näher spezifiziert. [AF, NW]

Feinentwurf

Mode_Subsystem

Die Mode Unit ist die zentrale Kommunikationsschnittstelle des Automaten und steuert den Ablauf aller Wechsel-, und Spendenvorgänge, sowie den Wechsel zwischen den verschiedenen Modi. Die Hauptaufgabe des Prozesses ist es für eine ordnungsgemäße Kommunikation zwischen den Subsystemen zu sorgen und dabei jeden Schritt im System sicher zu loggen. Feinentwurf Mode_Subsystem [LS, NW]


Init Monitor_Subsystem

Das Init Monitor Subsystem ist für den Start der Geldwechselautomat-Prozesse und deren Überwachung zuständig. Durch periodische Abfragen (Heartbeat) an die beteiligten Prozesse wird die Funktionsfähigkeit bestätigt und gewährleistet somit einen sicheren Betriebszustand. Feinentwurf Init Monitor_Subsystem [PS]


Money_Subsystem

Die Aufgaben des Money-Subsystems umfassen die Ansteuerung der Geldperipherie und die Umsetzung der seriellen, verschlüsselten Kommunikation zu den Münzausgabegeräten. Dazu wird ein Linux-Prozess in das Hauptsystem integriert, um das Protokoll der Geldannahme- und Ausgabegeräte in Richtung der Hauptprozesse zu abstrahieren. Des Weiteren muss ein kleines System entwickelt werden, dass das Protokoll, zur Ansteuerung der vom Kunden gelieferten Münzausgabegeräte, auf ein gefordertes Protokoll umwandelt. Dieser Schritt kann als Entwicklung einer eigenen, minimalistischen, SMART-Hopper Komponente verstanden werden. Feinentwurf Money_Subsystem [AF]


Operator_Interface_Subsystem

Die Aufgabe des Operator-Interface-Subsystems ist die Kommunikation zwischen dem Benutzer und dem Gelscheinwechsel-Automaten und ist ebenfalls für die Kommunikation zwischen Administrator/Berechtigten und dem System.

Diese Aufgabe wurde in zwei Aufgabenbereiche unterteilt:

1) Zum Einen in das User-Interface (UMI) mit den dazugehörigen Ein-/Ausgabe-Geräte wie z.B. Knöpfe und Display. Feinentwurf User-Interface [MM]

2) Und in das Admin-Interface oder auch Admin-Frontend, mit dem der Administrator über ein kleines Touch-Display das System administrieren kann. Feinentwurf Admin-Interface [TK]


Log_Subsystem

Das Log-Subsystem beinhaltet ein Speicherkonzept um Daten redundant zu speichern, sowie die Ereignis- und Fehlerprotokollierung. Der Geldbestand, die Konfigurationseinstellungen und die Spendenabwicklung besitzen eine hohe Anforderung an Datensicherheit und Ereignisprotokollierung. Aus diesem Grund wurde ein RAID-Level 1 zur Verbesserung der Datensicherheit und der rsyslogd Daemon als Ereignis- und Fehlerprotokollierung implementiert. Ein weiterer Teil des Log-Subsystems ist die E-Mail [[2]]Benachrichtigung im besonderen Ereignisfall.


2015-12-07 log ubsystem overview1.0.png

Das Log Subsystem setzt sich aus dem Syslog und dem RAID 1 Speichermedien-Verbund zusammen. [PS]


Power_Supply_Subsystem

Die Aufgabe des Power-Supply-Subsystems ist die einzelnen Komponenten mit Strom zu versorgen. Am Ende der Fertigstellung soll der Automat nur noch über einen Stromstecker angeschlossen werden und das Power-Supply-Subsystem soll die verschiedene Versorgungsspannungen liefern. Feinentwurf Power_Supply_Subsystem [TK]


Aufgabe dieses Subsystems ist die Bereitstellung eines Spendenformulars über eine Web-Schnittstelle. Dieses Modul konnte nicht entwickelt werden, da keine zeitlichen Ressourcen mehr vorhanden waren. [AF]

Gehäusedesign

Bezüglich eines Gehäuses für den Geldscheinwechsel-Automaten haben wir Jeffert Paulat beauftragt. Er hat für uns ein höchst professionelles, maßstabgetreues und sicheres Gehäuse konstruiert, welches unter diesem Link ausführlich beschrieben wird.

Hier schon einmal eine Sicht auf das Gehäuse mit leicht durchsichtigem Material (für eine bessere Übersicht): [NW]

Mash Automat iso.jpg


Integration

Hier wird für jedes Subsystem die Integration beschrieben. Dazu zählen unter Anderem die benötigten Librarys und Verzeichnisse der Konfigurationsdateien und deren benötigten Anpassungen.


Test und Evaluation

Wechselmodus-Testfälle

Test-ID Beschreibung Ergebnis Anmerkung
TW1 Wird die entsprechende Anzahl von Euromünzen für eine Euronote ausgegeben? +++
TW2 Wird eine Fehlerquittung gedruckt und eine entsprechende Fehlermeldung angezeigt, wenn zu wenig Euromünzen ausgegeben wurden? +++
TW3 Wird die entsprechende Benachrichtigung an den Administrator/Berechtigten gesendet, wenn zu wenig Euromünzen ausgegeben wurden? +++
TW4 Werden alle Schritte des erfolgreichen Gelscheinwechselvorgangs geloggt? ++ Alle Einträge vorhanden, könnten aber besser gestaltet werden
TW5 Werden alle Schritte des nicht-erfolgreichen Gelscheinwechselvorgangs geloggt? ++ Alle Einträge vorhanden, könnten aber besser gestaltet werden
TW6 Erkennt das System, ob für jede mögliche Euronote ausreichend Euromünzen vorhanden sind? +++
TW7 Erkennt das System, ob für jede mögliche Euronote zu wenig Euromünzen vorhanden sind? +++
TW8 Erkennt das System welche Euronote eingeführt wurde? +++
TW9 Kann das System echt und unechte Euronoten unterscheiden? +++
TW10 Wird die Euronote wieder ausgegeben, wenn sie als "nicht echt" erkannt wurde? +++
TW11 Erkennt das System, ob die eingeführte Euronote "gesperrt" / "nicht gesperrt" ist? +++
TW12 Wird nach einem Geldscheinwechselvorgang der Euromünzenbestand geprüft? +++
TW13 Wird bei Unterschreitung des Schwellenwerts des Euromünzenbestands der Administrator/Berechtigte informiert? +++
TW14 Wechselt das System standardmäßig immer wieder in den Geldscheinwechsel-Modus? - Es ist kein Time-Out implementiert
TW15 Wird bei unvollständigem Druckvorgang, durch Papiermangel, eine entsprechende Fehlermeldung angezeigt? +++
TW16 Wird ein Administrator/Berechtigter (inkl. aller erforderlichen Informationen) benachrichtigt, wenn das System in einen Fehlerzustand kommt? + Benachrichtigung müsste mehr Informationen beinhalten
TW17 Kann der Benutzer Geld wechseln, wenn der Geldscheinwechsel-Modus deaktiviert ist? +++
TW18 Ist die Transaktionssicherheit bei Stromausfall im Geldscheinwechselbetrieb (ohne USV-Unterstützung) sichergestellt? + Je fertig ausgegebene und gespeicherte Euromünzen-Art ja, Rest nein
TW19 Ist die Transaktionssicherheit bei Stromausfall im Geldscheinwechselbetrieb (mit USV-Unterstützung) sichergestellt? + Je fertig ausgegebene Euromünzen-Art ja, aber nicht der komplette Vorgang, da nur der PI durch die USV mit Strom versorgt wird
TW20 Funktioniert der Geldscheinwechsel-Modus noch mit einer unterbrochenen Netzwerkverbindung? +++
TW21 Kann der Benutzer eine Euronote in Euromünzen wechseln lassen?? +++
TW22 Werden Euromünzen ausgegeben? +++
TW23 Wird der Benutzer informiert, wenn der Geldscheinwechsel-Modus nicht verfügbar ist? +++

[NW]

Spendenmodus-Testfälle

Test-ID Beschreibung Ergebnis Anmerkung
TS1 Zeigt das System an, dass man sich im Spenden-Modus befindet? +++
TS2 Wird bei einer erfolgreich durchgeführten Spende der Kassenwart benachrichtigt? +++
TS3 Können im Spenden-Modus mehrere Euronoten für eine Spende zusammengefasst werden? +++
TS4 Wird bei einer Mehr-Schein-Spende die Summer aller eingefügten Euronoten angezeigt? +++
TS5 Weist das System bei einer Mehr-Schein-Spende daraufhin, dass immer nur die zuletzt eingefügte Euronote beim Abbrechen des Vorgangs wieder ausgegeben wird? ++ Die Meldung befindet sich außen auf dem Automaten. Jeder Schein muss einzeln bestätigt werden.
TS6 Wird bei einer Mehr-Schein-Spende beim Abbrechen, die zuletzt eingefügt Euronote wieder ausgegeben? +++
TS7 Wird bei einer Mehr-Schein-Spende beim Abbrechen ein Bon ausgegeben mit allen erforderlichen Informationen, damit der benutzer sein restliches Geld zurückbekommt? +++
TS8 Wird bei einer abgebrochenen Mehr-Schein-Spende der Kassenwart benachrichtigt? +++
TS9 Wird eine entsprechende Fehlermeldung angezeigt, wenn der Drucker "nicht genug" / "kein" Papier mehr hat? +++
TS10 Wird ein Administrator/berechtigter benachrichtigt, wenn das System in einen Fehlerzustand kommt? + Webserver wurde nicht implementiert. Es werden aber Fehlermeldung verschickt.
TS11 Wird eine entsprechende fehlermeldung angezeigt, wenn bei einer durchgeführten Spende keine verbindung zum Netzwerk besteht, um die Informationen an der Webser zu schicken? - Webserver wurde nicht implementiert.
TS12 Erkennt das System welche Euronote eingefügt wurde? +++
TS13 Kann das System echte und unechte Euronoten unterscheiden? +++
TS14 Wird die Euronote wieder ausgegeben wenn sie als nicht "echt" erkannt wurde? +++
TS15 Erkennt das System, ob die eingefügte Euronote "gesperrt" / "nicht gesperrt" ist? +++
TS16 Kann der Benutzer Geld spenden, wenn der Spendenmodus deaktiviert ist? +++
TS17 Kann man sich am Spendenwebserver mit einer nicht existierenden ID anmelden? - Webserver wurde nicht implementiert
TS18 Kann man sich am Spendenwebserver mit einer existierenden ID anmelden? - Webserver wurde nicht implementiert
TS19 Kann man sich am Spendenwebserver mit einer existierenden ID anmelden, wenn die Spende schon durchgeführt wurde? - Webserver wurde nicht implementiert
TS20 Kann ein Benutzer eine Spende abschließen, ohne alle erforderlichen Informationen einzugeben? - Webserver wurde nicht implementiert
TS21 Wird vom Webserver bei erfolgreicher Angabe aller erforderlichen Informationen ein Latex-Template an den Kassenwart gesendet? - Webserver wurde nicht implementiert
TS22 Wird der Benutzer nach einer gewissen Zeit vom Webserver abgemeldet? - Webserver wurde nicht implementiert
TS23 Wird die ID im Webserver bei erfolgreichem Abschließen der Spende gelöscht? - Webserver wurde nicht implementiert
TS24 Wird eine Benachrichtigung an den Administrator gesendet, wenn eine ID nicht gelöscht werden kann? - Webserver wurde nicht implementiert
TS25 Werden alle Schritte des erfolgreichen Spenden-Vorgangs geloggt? ++ Alle Einträge vorhanden, könnten aber besser gestaltet werden
TS26 Werden alle Schritte des nicht erfolgreichen Spenden-Vorgangs geloggt? ++ Alle Einträge vorhanden, könnten aber besser gestaltet werden
TS27 Ist sichergestellt das kein Schritt verloren geht, wenn während des Spenden-Vorgangs der Strom ausfällt? (mit USV) +++
TS28 Ist sichergestellt das kein Schritt verloren geht, wenn während des Spenden-Vorgangs der Strom ausfällt? (mit USV) - Keine Spendenquittung da die USV den Drucker nicht mit Strom versorgt
TS29 Wird dem Benutzer beim Tätigen der Spende am System angezeigt, dass durch eine nicht vorhandene Netzwerkverbindung das Anfordern der Spendenquittung über den Webserver nicht möglich ist? - Webserver wurde nicht implementiert
TS30 Werden die eingegebenen Informationen auf dem Webserver gespeichert, wenn während der Eingabe die Netzwerkverbindung unterbrochen wird? - Webserver wurde nicht implementiert
TS31 Kann eine Spendenquittung über den Webserver angefordert werden, wenn die Netzwerkverbindung unterbrochen ist? - Webserver wurde nicht implementiert
TS32 Kann eine Spendenquittung über den Webserver angefordert werden, wenn die Netzwerkverbindung unterbrochen ist? - Webserver wurde nicht implementiert
TS33 Kann der Benutzer eine Spende tätigen? +++
TS34 Stimmt der Spenden-Betrag auf dem ausgedruckten Bon nach einem erfolgreichen Spenden-Vorgang? +++
TS35 Wird nach einem Spendenvorgang ein eindeutiger Bon mit Anleitung der weiteren Schritte gedruckt? +++
TS36 kann der Spenden-Vorgangjederzeit abgebrochen werden? +++
TS37 Kann nach Bestätigung einer Euronote die Euronote wieder ausgegeben werden? +++
TS38 Kann der Status einer Spenden über ein Webinterface angeschaut werden? - Webserver wurde nicht implementiert

[LS]


lokale Administration-Testfälle

Test-ID Beschreibung Ergebnis Anmerkung
TAL1 Anmelde Möglichkeit am lokalen System verfügbar? - nicht implementiert
TAL2 Anmeldung mit deaktiviertem Account möglich? - Anmeldung nicht implementiert
TAL3 Wird Administrator-Modus lokal ausgewählt? +++
TAL4 Wird Administrator-Menü nach erfolgreicher Anmeldung angezeigt? +++
TAL5 Wird Account nach 3x fehlgeschlagenem Anmeldeversuch gesperrt? - nicht implementiert
TAL6 Kann über eine Korrekturmöglichkeit eine Eingabe wiederholt werden? - nicht implementiert
TAL7 Admin kann lokal alle administrativen Tätigkeiten durchführen? + Keine Account-Verwaltung, kein Shutdown und Reboot
TAL8 Wird ein eingeloggter Account nach Zeitüberschreitung ohne Tätigkeit abgemeldet? - nicht implementiert
TAL9 Wird Admin benachrichtigt wenn eingeloggter Account Zeitmarke ohne Tätigkeit überschreitet. - nicht implementiert
TAL10 Kann Admin/Berechtigter lokal Münzen hinzufügen +++
TAL11 Kann Admin/Berechtigter Münzen einer bestimmten Sorte ausgeben? +++
TAL12 Kann Admin/Berechtigter alle Noten aus dem System entfernen? +++
TAL13 Kann Admin/Berechtigter bestimmte Noten lokal sperren? +++
TAL14 Kann Admin/Berechtigter bestimmte Noten lokal entsperren? +++
TAL15 Kann Admin/Berechtigter Log-Einträge lokal einsehen? +++
TAL16 Kann Admin/Berechtigter lokal Systemstatus einsehen? +++
TAL17 Kann Admin/Berechtigter lokal Systemstatus bestimme Modi sperren? +++
TAL18 Kann Admin/Berechtigter lokal Systemstatus bestimme Modi entsperren? +++
TAL19 Kann Admin/Berechtigter lokal das System herunterfahren? - Implementierung noch nicht ausgereift / fehlerhaft
TAL20 Kann Admin/Berechtigter lokal Account-Administration durchführen? - nicht implementiert
TAL21 Kann Admin/Berechtigter lokal einen schon vorhandenen Account anlegen? - nicht implementiert
TAL22 Kann Admin/Berechtigter lokal einen nicht vorhandenen Account löschen? - nicht implementiert
TAL23 Kann Admin/Berechtigter lokal einen nicht vorhandenen Account deaktivieren? - nicht implementiert
TAL24 Kann Admin/Berechtigter lokal ein Kennwort eines vorhandenen Account zurücksetzen? - nicht implementiert
TAL25 Kann Admin/Berechtigter lokal ein Kennwort zu einem "nicht erlaubten" Kennwort ändern? - nicht implementiert
TAL26 Kann ein Berechtigter (nicht Admin) administrative Tätigkeiten, für die er nicht die entsprechenden Rechte hat, durchführen? (Account-Verwaltung, etc) - nicht implementiert
TAL27 Ist sichergestellt, dass kein Schritt verloren geht, wenn während der Administration der Strom ausfällt? (ohne USV) + Konfigurationen ja, bei Münzausgabe nein
TAL28 Ist sichergestellt, dass kein Schritt verloren geht, wenn während der Administration der Strom ausfällt? (mit USV) + Konfigurationen ja, bei Münzausgabe nein
TAL29 Ist sichergestellt, dass sich immer nur ein Administrator/Berechtigter am System anmelden kann (lokal und verteilt mit inbegriffen)? - Wurde im Laufe des Projekts als unnötig angesehen und ignoriert
TAL30 Kann der Administrations-Modus betreten werden, wenn das Gehäuse nicht geöffnet ist? +++
TAL31 Wird der Administrations-Modus betreten (Login) wenn das Gehäuse geöffnet wird? + Admin-Modus ja, Login nein (da nicht implementiert)
TAL32 Wechselt das System aus dem Administrations-Modus in den Geldscheinwechsel-Modus, sobald das Gehäuse geschlossen wird?? +++
TAL33 Werden beim Schließen des Gehäuses nicht gespeicherte Einstellungen verworfen? - nicht gespeicherte Einstellungen bleiben erhalten
TAL34 Wird der angemeldete Administrator/Berechtigte beim Schließen des Gehäuses automatisch abgemeldet? - Login nicht implementiert, daher kein Logout
TAL35 Kann die lokale Administration trotz fehlender Netzwerkverbindung durchgeführt werden? +++

[NW]

remote Administration-Testfälle

Test-ID Beschreibung Ergebnis Anmerkung
TAR1 Kann sich ein Administrator/Berechtigter remote am System anmelden um administrative Tätigkeiten durchzuführen? +++
TAR2 Kann sich ein Administrator/Berechtigter mit deaktiviertem Account remote am System anmelden? ++ Noch nicht umgesetzt, aber es wird eine extra zugeschnittene Regel für LDAP eingerichtet
TAR3 Kann der Administrator-modus remote augewählt werden? +++
TAR4 Wird das Admin-Menü angezeigt, wenn sich ein Administrator/Berechtigter remote angemeldet hat? +++
TAR5 Wird der Administrator-/Berechtigten-Account bei dreimaliger falscher Eingabe des Kennworts deaktiviert? - Aus Zeitmangel wurde sich hierauf nicht konzentriert, sollte aber konfigurierbar sein
TAR6 Kann ein Administrator/Berechtigter im Admin-Menü alle verteilten, administrativen Tätigkeiten durchführen? +++
TAR7 Wird ein remote angemeldeter Administrator/Berechtigter nach einer gewissen Zeit automatisch abgemeldet? - Aus Zeitmangel wurde sich hierauf nicht konzentriert, ist aber noch geplant
TAR8 Kann ein Administrator/Berechtigter bestimmte Euronoten remote sperren? +++
TAR9 Kann ein Administrator/Berechtigter bestimmte Euronoten remote entsperren? +++
TAR10 Kann ein Administrator/Berechtigter Log-Einträge remote vom System einsehen? +++
TAR11 Kann ein Administrator/Berechtigter sich remote den Systemstatus anzeigen lassen? +++
TAR12 Kann ein Administrator/Berechtigter remote bestimmte Modi sperren? +++
TAR13 Kann ein Administrator/Berechtigter remote bestimmte Modi entsperren? +++
TAR14 Kann ein Administrator/Berechtigter remote das System herunterfahren? - Implementierung noch nicht ausgereift / fehlerhaft
TAR15 Kann ein Administrator/Berechtigter remote Account-Administration durchführen? +++
TAR16 Kann ein Administrator/Berechtigter remote einen schon vorhandenen Account anlegen? +++
TAR17 Kann ein Administrator/Berechtigter remote einen nicht vorhandenen Account löschen? +++
TAR18 Kann ein Administrator/Berechtigter remote einen nicht vorhandenen Account deaktivieren? +++
TAR19 Kann ein Administrator/Berechtigter remote ein Kennwort eines nicht vorhandenen Account zurücksetzen? +++
TAR20 Kann ein Administrator/Berechtigter remote ein Kennwort zu einem "nicht erlaubten" Kennwort ändern? +++
TAR21 Kann ein Berechtigter (nicht Administrator) administrative Tätigkeiten, für die er nicht die entsprechenden Rechte hat, durchführen? (Account-Verwaltung) +++
TAR22 Ist sichergestellt, dass kein Schritt verloren geht, wenn während der Administration der Strom ausfällt? (ohne UV) +++
TAR23 Ist sichergestellt, dass kein Schritt verloren geht, wenn während der Administration der Strom ausfällt? (mit UV) +++
TAR24 Ist sichergestellt, dass sich immer nur ein Administrator/Berechtigter am System anmelden kann (lokal und verteilt gleichzeitig mit inbegriffen)? - Wurde im Verlauf als nicht nötig angesehen und von daher ignoriert
TAR25 Werden noch nicht gespeicherte Einstellungen, welche remote durchgeführt wurden, beim unterbrechen der Netzwerkverbindung verworfen und der Administrator/Berechtigter automatisch abgemeldet? ++ Einstellungen werden verworfen, Administrator/Berechtigter aber nicht abgemeldet
TAR26 Kann das System remote administriert werden, obwohl keine Netzwerkverbindung zum System besteht? +++
TAR27 Besitzt der Remote-Zugriff Sicherheitsstandards um unbefugten Zugriff zu verhindern? +++

[NW]

generelle Testfälle

Test-ID Beschreibung Ergebnis Anmerkung
TG1 Beträgt der Idle-Leistungsverbrauch des Geldscheinwechsel-Automats bei 10 Watt (+- 5 Watt)? +++
TG2 Bietet das System angemessene Funktionalitäten? + Einige Requirements wurden nicht erfüllt
TG3 Sind die entsprechenden Modi vorhanden? +++
TG4 Ist das Vortäuschen einer Euronote möglich? +++
TG5 Wird der Geldscheinprüfer über eine serielle, verschlüsselte Verbindung angesteuert? +++
TG6 Werden die Münzhopper über eine serielle, verschlüsselte Verbindung angesteuert? +++
TG7 Können die Münzhopper extern bedient werden? ++ Es exisiert zur Zeit kein sicheres "Case" um die Hopper darin vor externem Zugriff besonders zu schützen
TG8 Verfügt das System über eine USV, um bei einem Stromausfall ordnungsgemäß herunterzufahren? + Die USV ist zu klein / nicht stark genug um das komplette System zu versorgen um es komplett ordnungsgemäß herunterzufahren
TG9 Besitzt das System eine redundante Datenhaltung? - Erklärung dazu im Feindesign von Patrick
TG10 Besitzt das System eine benutzerfreundliche Bedienungsoberfläche? +++
TG11 Findet die Kommunikation zwischen dem System und dem Benutzer über ein Display und Bedienelemente (Knöpfe) statt? +++
TG12 Läuft die Benutzerauthentifizierung zur Konfiguration des Systems über einen LDAP-Server? +++

[NW, LS]


Abschließendes und weitere Aussichten

Das Projekt ist zum größten Teil erfolgreich verlaufen und brachte ein Resultat, was von den Teammitgliedern in den Anfangszeiten nicht erwartet wurde. Es wurden viele, aber nicht alle Anforderungen umgesetzt. Grund dafür war die Unerfahrenheit der einzelnen Teammitglieder im einschätzen von Arbeitszeiten. Die angedachten Zeiten für die einzelnen Projektmodule wurden weit überschritten. Dies stellt jedoch keine Überraschung dar, da die Anforderungen an das Endprodukt sehr üppig ausgefallen sind, es jedoch nicht möglich war sich von einzelnen Anforderungen abzugrenzen. Die nicht umgesetzten Anforderungen umfassen zum größten Teil Transaktionssicherheit in Bezug auf Logging und das Raid-System, da es in diesen Arbeitspaketen zu unerwarteten Schwierigkeiten mit der ausgewählten Linux Distribution kam, der Projektfortschritt jedoch keinen Plattformwechsel mehr ermöglichte. Eine weitere nicht umgesetzte Anforderung betrifft die lokale Administration. Es ist zu Zeit nicht möglich sich an dem Gerät lokal zu authentifizieren. Jeder Administrator/Berechtigter der einen Schlüssel für das Gehäuse besitzt, ist in der Lage Maßnahmen der lokalen Administration durchzuführen ohne eindeutig identifiziert zu werden. Des Weiteren fehlt noch eine gute Fehlerbehandlung im Großen. Wenn einzelne Prozesse auf dem System ihre Aufgabe nicht ordnungsgemäß erfüllen, kann es zu inkonsistenten Systemzuständen kommen, die einen Neustart des Systems erfordern, was jedoch die Ausnahme und nicht die Regel darstellt. Dies ist dadurch geschuldet, dass zum Projektende hin, keine zeitlichen Ressourcen mehr für einen ausgewogenen Systemtest zur Verfügung standen, da die Integration der verschiedenen Subsysteme sehr viel schwieriger und langwieriger als eingeplant verlief. Verantwortlich für diese große zeitliche Verzögerung ist auf die komplexe Softwarearchitektur und die erschwerten Testbedingungen zurück zu führen. Da vom Kunden nur einzelne Hardwarekomponenten geliefert wurden, verfügte nicht jedes Teammitglied über einen Testaufbau weswegen das Verhalten einzelner Prozesse virtualisiert werden musste, was die Fehlerfortpflanzung erheblich förderte. Milestone drei wurde ebenfalls nicht erreicht, da zur Umsetzung keine zeitlichen Ressourcen mehr vorhanden waren. Dieser Milestone umfasste jedoch eine Anforderung von der sich das Team von Beginn an distanzieren wollte. Trotz all der negativen Aspekte, kann das Projekt jedoch zum größten Teil als erfolgreich angesehen werden. Es wurde ein Geldwechselautomat entwickelt, der seine Grundaufgaben erfüllt. Er verfügt über ausreichend Schnittstellen zur Administration und Wartung. Ein Spendenvorgang ist ebenfalls ausfallsicher möglich und die Wahrscheinlichkeit für auftretende Fehler ist gering. Dies ist natürlich etwas spekulativ, da ein Beta-Test mit dem System, aufgrund eines fehlenden Gehäuses nicht möglich war. Eines der Teammitglieder übernimmt jedoch die Wartung und Weiterentwicklung im Haus des Kunden weswegen die Ausmerzung dieser Fehler auch nur eine Frage der Zeit ist. Die Erfüllung der restlichen Anforderungen wäre die nächste Maßnahme, die zu ergreifen wäre. Des Weiteren müsste das System etwas mehr an Robustheit gewinnen. Dies könnte dadurch erreicht werden, dass die IPC auf ein Minimum beschränkt wird. Dazu könnten z.B. diverse Prozesse zusammengefügt werden, wie z.B. Money-Subsystem und User-Interface als ein Prozess zur Ansteuerung von Hardware-Devices. Eine größere USV und ausgewogenere Fehlerbehandlung wäre ebenfalls ein weiterer Schritt. Um die Spendeneinnahmen des Vereins zu erhöhen, wäre eine Funktion hilfreich, die es ermöglicht einen Teilbetrag eines eingeführten Scheines zu wechseln und einen Teilbetrag zu spenden. [AF]


Quellen

https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-a-basic-ldap-server-on-an-ubuntu-12-04-vps
https://help.ubuntu.com/community/OpenLDAPServer
http://www.plone-entwicklerhandbuch.de/authentifizierung/ldap
https://www.ldap-account-manager.org/lamcms/
https://www.pjrc.com/teensy/teensy31.html#specs
http://rishifranklin.blogspot.de/2014/03/freertos-on-teensy-31.html
https://www.adafruit.com/products/757
https://www.adafruit.com/datasheets/cashino%20thermal%20printer%20a2.pdf
http://innovative-technology.com/images/pdocuments/manuals/SSP_Manual.pdf
http://innovative-technology.com/de/products/products-main/378-nv9-usb-2
http://www.azkoyenpaymenttechnologies.com/hoppers
https://curl.haxx.se/libcurl/
http://piusv.de/support/piusvdoku.pdf
http://www.watterott.com/de/RPi-Display-B-Plus
http://www.sainsmart.com/sainsmart-iic-i2c-twi-serial-2004-20x4-lcd-module-shield-for-arduino-uno-mega-r3.html
https://www.sparkfun.com/products/79140
[NW]


Aktuelle Dokumente

[TK]


Hoch zu Top