Fernwartung Und Fern Diagnose
-
Upload
darthblair -
Category
Documents
-
view
47 -
download
0
Transcript of Fernwartung Und Fern Diagnose
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 1/47
BACHELORARBEIT
Aufgabenstellung:
Prof. Dr. Gabrijela Dreo Rodosek
Betreuung:
Dipl.-Inf. Frank Eyermann
Universität der Bundeswehr München
Fakultät für Informatik
Neubiberg
30.12.2010
Fernwartung und Ferndiagnose eines modernen
Kaffeevollautomaten Bachelorarbeit von
Bassüner, Marcel 1080580
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 2/47
Eigenständigkeitserklärung
Hiermit versichere ich, dass ich die vorliegende Arbeit selbstständig angefertigt habe.Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken und Zitate sind
als solche kenntlich gemacht. Es wurden keine anderen als die in der Arbeit angegebe-
nen Quellen und Hilfsmittel benutzt. Die Arbeit wurde weder einer anderen Prüfungs-
behörde vorgelegt noch veröffentlicht.
Neubiberg, den 30.12.10
Datum, Unterschrift
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 3/47
Inhaltsverzeichnis ii
Inhaltsverzeichnis
Inhaltsverzeichnis ................................................................................................ ii Abbildungsverzeichnis ....................................................................................... iv Abkürzungsverzeichnis ....................................................................................... v 1 Einleitung ......................................................................................................... 1
1.1 Motivation ..................................................................................................................... 2 1.2 Problemstellung ............................................................................................................ 3 1.3 Zielsetzung .................................................................................................................... 4
2 Anforderungsanalyse ...................................................................................... 5 2.1 Nutzungsszenarien ....................................................................................................... 5 2.2 Anforderungen an das System .................................................................................... 7
3 Grundlagen ...................................................................................................... 9 3.1 Authentifizierung ......................................................................................................... 9
3.1.1 Aufweisen von Wissen ........................................................................................ 9 3.1.2 Benutzung eines Besitzes .................................................................................. 10 3.1.3 Biometrische Merkmale .................................................................................... 11
3.2 Digitale Zertifikate ..................................................................................................... 11 3.2.1 Digitale Zertifikate und Certificate Authorities ................................................ 12 3.2.2 Digitale Zertifikate in Java ................................................................................ 13
3.3 SNMP ........................................................................................................................... 14 3.3.1 SNMP in Java .................................................................................................... 15
4 Design ............................................................................................................. 16 4.1 Statusinformationen und Einstellungen ................................................................... 16
4.1.1 Separat an jedem Automaten ............................................................................ 16 4.1.2 Zentralisierung .................................................................................................. 16 4.1.3 Fazit................................................................................................................... 17
4.2 Internet Übertragung ................................................................................................. 18 4.2.1 Entwurf eines eigenen Protokolls ..................................................................... 18 4.2.2 SNMP ................................................................................................................ 18 4.2.3 Fazit................................................................................................................... 18
4.3 Autorisierung von Technikern .................................................................................. 19 4.3.1 Passwort ............................................................................................................ 19 4.3.2 Token ................................................................................................................. 19
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 4/47
Inhaltsverzeichnis iii
4.3.3 Fingerabdruck ................................................................................................... 20 4.3.4 Fazit................................................................................................................... 20
4.4 Dokumentation ........................................................................................................... 21 4.5 Verarbeitung von Störungen oder Fehlern .............................................................. 22
5 Implementierung ........................................................................................... 23 5.1 Kaffeeautomat ............................................................................................................ 24
5.1.1 CMaschineAgent und AgentFactory ................................................................. 24 5.1.2 AutoCheck ........................................................................................................ 26
5.2 Wartungs- und Diagnoseeinheit ................................................................................ 26 5.2.1 ClientServerAgent............................................................................................. 26 5.2.2 LocalMaintenance ............................................................................................. 27 5.2.3 ServerTrapReceiver und TrapReceiver ............................................................. 29 5.2.4 AutoMaintenance .............................................................................................. 30
5.3 Leasingfirma ............................................................................................................... 30 5.3.1 LessorTrapReceiver .......................................................................................... 31 5.3.2 TechnicianManagement .................................................................................... 32
6 Fazit ................................................................................................................ 34 Literaturverzeichnis ........................................................................................... vi Anhang ................................................................................................................ ix
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 5/47
Abbildungsverzeichnis iv
Abbildungsverzeichnis
Abbildung 1: Impressa X9 der Firma Jura [5] ............................................................................ 2 Abbildung 2: Use-Case-Diagramm ............................................................................................ 7
Abbildung 3: Smart-Card [10] .................................................................................................. 10 Abbildung 4: Direktes Vertrauensmodell [11] .......................................................................... 12 Abbildung 5: Aufbau Zertifikat [8] .......................................................................................... 13 Abbildung 6: Schema SNMP Kommunikation ........................................................................ 15 Abbildung 7: Schema Zentralisierter Einstellungen ................................................................. 17 Abbildung 8: Schema RFID-System [19] ................................................................................ 20 Abbildung 9: Fingerprintsensor [20] ........................................................................................ 20 Abbildung 10: Schema Authentifizierung Techniker ............................................................... 21 Abbildung 11: Schema Fehlerverarbeitung .............................................................................. 22 Abbildung 12: Unterteilung Implementierung ......................................................................... 23 Abbildung 13: Pakete der Implementierung ............................................................................. 23 Abbildung 14: Frontend ........................................................................................................... 24 Abbildung 15: CMaschineAgent und AgentFactory ................................................................ 25 Abbildung 16: ClientServer ...................................................................................................... 26 Abbildung 17: Pico-c der Firma Super Talent [22] .................................................................. 28 Abbildung 18: LocalMaintenance Konstruktor ........................................................................ 28 Abbildung 19: LocalMaintenanceForm.................................................................................... 29 Abbildung 20: Lessor ............................................................................................................... 30 Abbildung 21: „TrapManagement“ Ansicht ............................................................................. 31 Abbildung 22: „ClientVerbindung“-Ansicht ............................................................................ 32 Abbildung 23: „Neuer Techniker“-Ansicht .............................................................................. 33 Abbildung 24: Ausschnitt der MIB-Struktur ............................................................................. xi
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 6/47
Abkürzungsverzeichnis v
Abkürzungsverzeichnis
ID ..................................... Identifikator
LAN ................................. Local Area Network
PIN ................................... Persönliche Identifikationsnummer
TAN ................................. Transaction Authentification Numbers
RFID ................................ Radio-Frequency Identification
RJ-45 ................................ genormte Steckverbindung für Telekommunikationsverkabelung
UniBwM .......................... Universität der Bundeswehr München
CA .................................... Cetificate Authority
ITU .................................. Internationalen Fernmeldeunion
IETF ................................. Internet Engineering Task Force
MIB .................................. Management Information Base
OID .................................. Object Identifier
IP ...................................... Internet ProtocolTCP .................................. Transmission Control Protocol
DES .................................. Data Encryption Standard
AES .................................. Advanced Encryption Standard
TLS .................................. Transport Layer Security
CRL ................................. Certificate Revocation List
SNMP .............................. Simple Network Management Protocol
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 7/47
Kapitel 1: Einleitung 1
1 Einleitung
Der verlockende Duft von frisch aufgebrühtem Kaffee lässt für viele Deutsche die „kleine
Pause“ zum Erlebnis werden. Zum täglichen Ritual gehört er unbestritten dazu. So trinkt
durchschnittlich jeder Deutsche jährlich mehr Kaffee als Wasser. Eine Studie besagt, dass der
Pro-Kopf-Umsatz von Kaffee im Jahr 2007 bei 146 Litern lag. Der Umsatz von Mineral- bzw.
Heilwasser hingegen lag nur bei 130 Liter. [1] Eine Tasse des aromatischen Heißgetränkes
bedeutet für jeden, der ihn mag Genuss und Entspannung. Durch Ausschüttung von Dopamin
und Adrenalin fördert er die Aufmerksamkeit, Vitalität und Konzentration. [2] In der Gemein-
schaft genossen sorgt er in Büros, kleinen Firmen, Handwerksbetrieben und in den Arbeits-
räumen eines Beamten für Geselligkeit. Die Möglichkeiten der Zubereitung sind durchaus un-
terschiedlich. In den Pausenräumen werden zumeist handelsübliche Kaffeeautomaten oder
Kaffeemaschinen genutzt. Dort treffen sich Kollegen um sich gegenseitig auf den neusten
Stand zu bringen. Einzelne ziehen sich mit Snack und Tageszeitung in eine ruhige Ecke zu-
rück. Die Batterien werden wieder aufgeladen. Nach der Pause geht es frisch ans Werk. Der
Alltag sieht dagegen oft anders aus. Der durchschnittliche Kaffeetrinker wird allzu oft vor di-
verse Probleme gestellt. Manchmal fehlen Filtertüten, der Kaffee ist abgestanden oder die
Kaffeekanne ist leer. Der Mangel an Kleingeld für den Automaten oder für die Gemein-
schaftskaffeekasse betrübt die Betroffenen sehr. Der Ernst der Lage steigt weiter dramatisch
an, wenn der geliebte Kaffeespender nun plötzlich defekt sein sollte. Wer kümmert sich nun
darum? Wo liegen entsprechende Zuständigkeiten für Reparatur und Wartung? Diese Arbeit
zeigt mit der Erstellung eines umfangreichen Wartungs- und Diagnosesystems für alle aufge-
stellten Kaffeevollautomaten innerhalb einer Firma einen Lösungsweg für diese Probleme auf.
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 8/47
Kapitel 1: Einleitung 2
1.1 Motivation
Der Kaffeevollautomat „Impressa X9“ der Firma Jura stellt eine hohe Funktionalität und Be-dienerfreundlichkeit bereit. Zusätzlich ist er mit einer Tageskapazität von bis zu 100 Tassen
[3] für eine kommerzielle Nutzung und somit für den Einsatz in mittleren bis großen Firmen
bestens geeignet. [4]
Abbildung 1: Impressa X9 der Firma Jura [5]
Um den Funktionsumfang weiter zu erhöhen und somit das Einsatzgebiet zu erweitern wurde
bereits in der Bachelorarbeit von Stefan Mazur und Marlene Knösel eine Trennung von Ma-
schinensteuerung und Benutzeroberfläche umgesetzt. Dies ist notwendig um wichtige Kern-
funktionen der Maschine, unabhängig von Modifikationen wie zum Beispiel Abrechnungssys-
temen und verschiedenen grafischen Oberflächen, sicherzustellen. [6] Im Verlauf wurde der
Kaffeeautomat unter anderem um eine Registered Jack 45 (RJ-45) Schnittstelle erweitert und
somit der Weg für eine Einbindung und Kommunikation in einem Local Area Network (LAN)
bereitet. Auf Grundlage dieses Konstrukts ist es nun möglich, das Gerät für weitere Anwen-
dungsbereiche zu öffnen und die Kundenfreundlichkeit noch weiter zu steigern.
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 9/47
Kapitel 1: Einleitung 3
1.2 Problemstellung
Als Ausgangslage ist das System nun für jegliche Erweiterungen bereit. Um diese Arbeit ab-zugrenzen werden im Folgenden die Problematiken, zu denen diese Arbeit einen Lösungsweg
aufzeigen soll, vorgestellt.
1. Fernwartung und Diagnose
Im aktuellen Zustand des Systems können Einstellungen nur lokal an einem Gerät
vorgenommen werden. So muss bei Inbetriebnahme des Systems jedes System einzeln
konfiguriert werden. Auch bei einer späteren Änderung, wie zum Beispiel der Uhrzeit
ist es von Nöten das ein Techniker zu jedem Kaffeeautomaten geht und diese Einstel-
lung vornimmt. Dafür wird Zeit oder Personal benötig. Beides kostet den Kunden im
Endeffekt mehr Geld, wodurch das Interesse an dem Angebot der Leasingfirma
schwinden würde. Somit muss eine Lösung zum Abrufen und Ändern von Einstellung
aus der Ferne, über das Internet, gefunden werden. Damit kann die Leasingfirma der
Kaffeeautomaten bei gegebenem Anlass auch ohne großen Aufwand Anpassungen
vornehmen.
2. Zugriffskontrolle am AutomatenNatürlich müssen Einstellungen auch weiterhin direkt am Gerät vorgenommen werden
können. Jedoch sollte nicht einfach jeder Benutzer wichtige Einstellungen ändern
können. Es muss unterbunden werden, dass Einstellungen vorgenommen werden die
einen Automaten beschädigen oder unerlaubt Leistungen erschlichen werden. Es ist
somit einfach zu erkennen dass eine Sicherung notwendig ist, welche den Zugriff auf
Einstellungen des Kaffeeautomaten regelt, so dass nur autorisiertes Personal zu Ände-
rungen in der Lage ist.3. Automatisierung von einfachen Aufgaben
In einer Firma die 20 Kaffeeautomaten der Leasingfirma nutzt, steht eine Uhrzeitände-
rung an. Es muss an jedem Automaten die Uhrzeit geändert werden. Dazu ist es ent-
weder notwendig einen Techniker zu beauftragen, der dies an jedem Gerät durchführt
oder die Aktion wird über die Fernwartung umgesetzt. Doch Beides stellt einen unver-
hältnismäßigen Aufwand dar. Es muss eine Möglichkeit geschaffen werden, um einfa-
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 10/47
Kapitel 1: Einleitung 4
che Änderungen zu automatisieren. Dies entlastet die Leasingfirma, da sie im Rahmen
desselben Servicepaketes mehr Leistung bieten kann.
1.3
Zielsetzung
Die Erweiterung des Systems kann sehr flexibel umgesetzt werden und es bestehen viele
Möglichkeiten Modifikationen durchzuführen, um es an eine bestimmte Anforderung anzu-
passen. Nachfolgend werden im speziellen jene aufgezählt, welche in dieser Arbeit bearbeitet
werden sollen.
1. Es soll eine System zur Wartung und Diagnose der Kaffeevollautomaten einer Firma
realisiert werden.
2. Die Service-Firma wird selbständig bei auftretenden Fehlern informiert und ist in der
Lage remote auf die Einstellungen und Statusmeldungen der Kaffeeautomaten zuzu-
greifen.
3. Ein Techniker kann vor Ort Diagnose und Wartung vornehmen.
4. Der für die Erbringung der Serviceleistung notwendige Arbeitsaufwand soll durch Au-
tomatisierung minimiert werden.
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 11/47
Kapitel 2: Anforderungsanalyse 5
2 Anforderungsanalyse
Um eine detaillierte Anforderungsanalyse aufstellen zu können, werden im kommenden Ab-
schnitt verschieden Szenarien zur Nutzung des Systems dargestellt. Darauf basierend werden
Bedingungen und Anforderungen hergeleitet und formuliert.
2.1 Nutzungsszenarien
Szenario 1:
In einer mittelständischen bis großen Firma sind an verschiedenen Orten Kaffeemaschinen
aufgestellt, um das tägliche Bedürfnis der Mitarbeiter an Koffein zu decken. Jedoch sind in
letzter Zeit vermehrt Defekte bei diesen Kaffeemaschinen aufgetreten. Statt die defekten Ge-
räte zu ersetzen hat sich der Geschäftsführer entschlossen, das Angebot einer Leasing-Firma
zu nutzen. Diese stellt Kaffeeautomaten bereit, welche in der Firma an verschiedenen Punkten
aufgestellt werden können. Zusätzlich zu den Geräten übernimmt die Leasing-Firma jegliche
Serviceleistungen. Um die Kosten zu minimieren, werden die Kaffeeautomaten mit einer In-
ternetverbindung versehen, worüber Statusinformationen und Einstellungen direkt von der
Leasingfirma abgerufen bzw. gesetzt werden können. Des Weiteren wird die Leasing-Firma
bei auftretenden Fehlern oder Defekten direkt über diese Verbindung informiert, um entspre-
chende Maßnahmen einleiten zu können.
Szenario 2:
Bei diesem Szenario handelt es sich um die zuvor beschriebene Firma, welche das Angebot
der Leasing-Firma wahrgenommen hat und nun schon seit einigen Monaten von den Vorzügen
profitiert. Die Leasing-Firma hat eine Mitteilung über einen Fehler an einem der Kaffeeauto-
maten erhalten, bei der Bearbeitung der Meldung wird klar, dass es sich um einen schwerwie-
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 12/47
Kapitel 2: Anforderungsanalyse 6
genden Defekt handelt. Ein Techniker wird mit der Behebung des Problems beauftragt. Da
sich der Grund für das Problem dem Techniker nicht sofort erschließt, entscheidet er sich die
Logdateien des Automaten auf Herkunft zu untersuchen. Nachdem er die Ursache gefunden
hat und das defekte Teil ersetzt wurde, meldet sich der Techniker an dem Kaffeeautomaten an.
Nun kann er entsprechend notwendige Korrekturen der Einstellungen vornehmen. Um Rück-
fragen zu ermöglichen, wird der Zugriff auf die Einstellungen mit den Daten des Technikers
in den Logdateien vermerkt.
Szenario 3:
Um die Serviceleistung bei sinkendem Personalbedarf und sinkenden Kosten zu erhöhen, sol-len verschiedene Vorgänge automatisiert werden. Zur Umsetzung wurde in der oben bereits
beschriebenen Firma ein System installiert, welches selbständig Diagnose- und Wartungsar-
beiten der in der Firma aufgestellten Kaffeeautomaten durchführt. Das System wurde bei der
Aufstellung so konfiguriert, dass Einstellungen für die Kaffeeautomaten zentral vorgenom-
men werden können und von der Diagnoseeinheit in regelmäßigen Abständen überprüft wer-
den. Bei Abweichungen werden entsprechend notwendige Maßnahmen selbständig vom Sys-
tem ergriffen. Treten schwerwiegende Fehler auf, welche die Wartungs- und Diagnoseeinheitnicht eigenständig beheben kann, wird die Leasing-Firma informiert. Mit Einführung des neu-
en Systems wurde dem nun notwendigen Techniker die Arbeit erleichtert. Er kann sich durch
die zentralisierte Diagnose nun schnellstmöglich einen Überblick über das Gesamtsystem ver-
schaffen und Einstellungen für alle Automaten gleichzeitig ändern.
Aus den beschriebenen Nutzungsszenarien wurde ein Use-Case-Diagramm (Abbildung 2)
zusammengestellt. Dabei geht hervor, dass der größte Teil der Funktionalität des Systems bei
der Wartungs- und Diagnoseeinheit liegt. Ein Techniker bzw. die Leasing-Firma muss aus-
schließlich mit dieser kommunizieren, um Einstellungen oder Statusinformationen abzurufen.
Das System leitet getätigte Änderungen selbständig an die Kaffeeautomaten weiter.
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 13/47
Kapitel 2: Anforderungsanalyse 7
Abbildung 2: Use-Case- Diagramm
2.2 Anforderungen an das System
Durch eine Analyse der Nutzungsszenarien lassen sich an das System gestellte Kernanforde-
rungen herleiten, welche das zu entwickelnde System erfüllen muss.
1. Es muss eine Wartungs- und Diagnoseeinheit erstellt werden, welche mit den ihr zu-
geordneten Kaffeeautomaten kommunizieren kann.
2. Die Einheit muss Statusinformationen und Einstellungen bereitstellen.
a. Diese sollen über das Internet zur Leasing-Firma übertragen werden und dort
geändert werden können.
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 14/47
Kapitel 2: Anforderungsanalyse 8
b. Einstellungen sollen vor Ort von einem Techniker abgerufen und geändert
werden können.
c. Änderungen werden automatisiert an die angeschlossenen Kaffeeautomaten
übertragen.
3. Der Zugriff auf bereitgestellte Daten muss gesichert werden.
a. Bei der Übertragung über das Internet muss ein Protokoll gewählt werden,
welches eine Verschlüsselung zur Verfügung stellt.
b. Vor Ort muss sichergestellt werden, dass Einstellungen nur von einem ausge-
wiesenen Techniker der Leasing-Firma geändert werden dürfen.
4. Zu Diagnosezwecken sollen die Abläufe innerhalb der Wartungs- und Diagnoseeinheit
dokumentiert und in Logdateien gespeichert werden.
5. Auftretende Fehler müssen gemäß den Möglichkeiten des Systems verarbeitet werden.
a. Fehler einzelner Kaffeeautomaten werden über eine Netzwerkverbindung zum
Server gesandt.
b. Wenn möglich werden Fehler durch die Wartungseinheit behoben. Bei
schwerwiegenden Fehlern oder Defekten wird die Fehlermeldung an die Lea-
sing-Firma weitergeleitet.
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 15/47
Kapitel 3: Grundlagen 9
3 Grundlagen
In diesem Kapitel werden Grundlagen der Arbeit besprochen und verwendete Frameworks,
Mechanismen und Protokolle erklärt.
3.1 Authentifizierung
Um die Zugriffkontrolle eines Systems zu bewältigen, ist eine Authentifizierung notwendig.
Das bedeutet die sichere Feststellung der Identität einer Person. Diese Information kann auf
verschiedene Weisen sichergestellt werden. Dabei kann es sich um das Aufweisen von Wis-
sen, die Benutzung eines Besitzes oder den Nachweis eines biometrischen Merkmales han-
deln. In den nächsten Abschnitten werden nun diese Möglichkeiten näher beleuchtet und dar-
gestellt [7].
3.1.1 Aufweisen von Wissen
Dieser Faktor zur Authentifizierung wird meist in Computersystemen verwendet. Der Nach-
weis von Wissen in Form von Passwörtern, Personal Identification Numbers (PINs) oder
Transaction Authentification Numbers (TANs) ist in jeglichen Bereichen zu finden. Dabei ist
auch die Kombination von verschiedenem Wissen möglich wie zum Beispiel die Abfrage ei-
nes Passwortes in Verbindung mit dem Geburtsdatum. Für diese Art des Nachweises wird an
dem betroffenen System keinerlei spezielle oder zusätzliche Hardware benötigt. Die Wissens-
übertragung kann einfach durch ein Eingabegerät wie eine Tastatur oder ein Nummernfeld ge-
schehen. Denkbar ist auch eine Eingabe per Bildschirmtastatur. [8] Nachteil bei der Verwen-
dung von Wissen zur Authentifizierung ist die Möglichkeit zur Vervielfältigung ohne Kennt-
nisnahme des eigentlichen Eigentümers, mit geringem oder keinem zusätzlichen Aufwand.
Ein Passwort kann zum Beispiel bei der Eingabe von einem Dritten gesehen oder vom Besit-
zer selbst verraten werden. [9]
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 16/47
Kapitel 3: Grundlagen 10
3.1.2 Benutzung eines Besitzes
Der Besitz eines bestimmten Gegenstandes ist im Alltag eine weit verbreite Methode zur Zu-
gangsbeschränkung. Ein Büroschlüssel ist eines der einfachsten Beispiele um nicht autorisier-
te Personen vom Zugang zu einem gesonderten Bereich auszuschließen. Aber auch Schlüssel-karten wie Smart-Cards oder Chipkarten zählen zu diesem Bereich. Objekte zur Authentifizie-
rung werden auch Token genannt. Bei der Benutzung von Token sollte darauf geachtet wer-
den, dass die Erstellung einer Kopie nur schwer oder gar nicht möglich ist. Das wird realisiert
indem gezielt Fehler auf dem Datenträger erzeugt werden, welche nicht mit gängigen Mitteln
zu reproduzieren sind. Sodass bei der Ausführung eines Programmes oder zu Beginn eines
Prozesses auf das Vorhandensein dieses Fehlers getestet werden kann. Eine weitere Möglich-
keit ist den direkten Zugriff auf den Speicher zu unterbinden, damit kein Kopieren des Inhaltsdurchführbar ist. In Smart-Cards wird das realisiert, indem eine Interaktion mit dem internen
Permanentspeicher nur über den verbauten Prozessor passiert. Der Speicher ist ausbausicher
in der Karte untergebracht. [8]
Abbildung 3: Smart -Card [10]
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 17/47
Kapitel 3: Grundlagen 11
3.1.3 Biometrische Merkmale
Bei der Feststellung der Identität einer Person zur Authentifizierung ist Biometrie eine der si-
chersten Methoden. Dabei wird ein einzigartiges persönliches Merkmal einer Person gescannt
und mit gespeicherten Werten verglichen. Diese Scans müssen exakt und wiederholbar sein,um für eine Zugriffskontrolle in Frage zu kommen. Zu denen am häufigsten verwendeten
Merkmalen zählen der Fingerabdruck, die Retina bzw. die Iris, die Stimme oder spezielle Ge-
sichtsmerkmale. [7] Ein DNA Scan zu Identifikationszwecken ist in den meisten Fällen nicht
praktikabel, da die Authentifizierung innerhalb von wenigen Sekunden ablaufen sollte und
nicht wie in diesen Fall eine Woche auf das Ergebnis der Analyse gewartet werden kann.
Nachteil dieses Faktors zur Authentifizierung im Vergleich zu den anderen beiden Varianten
sind die erheblich höheren Kosten für die Anschaffung von Scannern. [8] Sowohl Vor- undNachteil dieser Methode ist, dass keine Möglichkeit zu Weitergabe der Schlüsselmerkmale
besteht. Wodurch einerseits die Zugangsberechtigung nicht weitergereicht werden kann, ande-
rerseits ein Verlieren oder Vergessen ausgeschlossen ist. Der Datensatz jeder berechtigten Per-
son muss in einem zugriffsgeschützten Gerät gespeichert oder von diesem auf einem zentralen
Speicher erreichbar sein, wodurch es nicht möglich ist eine dem System unbekannte Person
zu berechtigen.
3.2 Digitale Zertifikate
Im digitalen Datenverkehr wird heutzutage fast ausschließlich asynchrone Verschlüsselung
zur Übertragung von sensiblen Daten verwendet. Diese Methode bietet eine Lösung für die
größten Probleme der synchronen Verschlüsselung. [11] Bei synchroner Kryptierung muss der
Schlüssel erst an beide Seiten auf einem bereits gesicherten Weg übertragen werden. Dieasynchrone Verschlüsselung erlaubt es den Public Key zu veröffentlichen. Mit diesem Schlüs-
sel können nun Nachrichten chiffriert werden, welche nur der Empfänger mit dem passenden
privaten Schlüssel decodieren kann. Durch die Verbreitung des Public Key entsteht ein ande-
res Problem. Es kann nicht sichergestellt werden, dass der Herausgeber wirklich die Person
oder Institution ist für die sie gehalten wird. Dieser Problematik wirken Digitale Zertifikate
entgegen.
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 18/47
Kapitel 3: Grundlagen 12
3.2.1 Digitale Zertifikate und Certificate Authorities
Ein digitales Zertifikat dient der Bindung eines öffentlichen Schlüssels an eine bestimmte
Identität. Eine Institution versichert dabei, dass der Public Key einer Person, dem Zertifikats-
besitzer, zuzuordnen ist. Diese Institution heißt Cetificate Authority (CA). Als Voraussetzungmuss der Zertifikatsprüfer Vertrauen in die CA und deren öffentlichen Schlüssel besitzen.
Abbildung 4: Direktes Vertrauensmodell [11]
Zur Verwendung bei Public Key Zertifikaten hat sich der Standard X.509 der Internationalen
Fernmeldeunion (ITU) durchgesetzt. In der neusten Version X.509 v3 [12] speichert das Zerti-
fikat Informationen wie [7]:
• Seriennummer
• Versionsnummer
• Einzelheiten zur Identität des Besitzers
• Details zum verwendeten Verschlüsselungsalgorithmus
• Gültigkeitsdauer
• Und die digitale Signatur der CA
Die Zertifizierungsinstitution signiert alle zum Zertifikat gehörenden Daten und setzt dieseverschlüsselte Prüfsumme unter das Zertifikat. Dadurch werden die Daten nicht vor einer Än-
derung geschützt, jedoch würde eine solche sofort bei Überprüfung der Signatur auffallen.
Somit ist die Integrität der angegebenen Daten durch die CA versichert. [8]
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 19/47
Kapitel 3: Grundlagen 13
Abbildung 5: Aufbau Zertifikat [8]
3.2.2 Digitale Zertifikate in Java
In Bezug auf die Verwendung von Zertifikaten stellt die Security-API der Java SE nur Mög-
lichkeiten der Verwaltung von Schlüsseln und das Prüfen von Zertifikaten bereit. [13] Um
selbstsignierte Zertifikate zu erstellen, muss man auf die Klassen aus dem „sun.security.*“
Paket zurückgreifen. Hier werden mit der Klasse „CertAndKeyGen“ Funktionen bereitgestellt
mit welchen sich X.509 v1 und v3 Zertifikate erstellen lassen. Da sich in den mit dieser Me-
thode erstellten Zertifikaten kein spezifischer Public Key einbetten lässt und die Erweite-
rungsfunktionalität der X.509 v3 nicht implementiert ist, dienen sie nur der Identifikation ei-
ner CA und nicht der näheren Beschreibung eines öffentlichen Schlüssels. [14] Um die kom-
plette Spannbreite der Funktionalität von Zertifikaten auszuschöpfen, ist die Verwendung ei-
nes Drittanbieter -Pakets vonnöten. Dazu wird im Folgenden die „Bouncy Castle Crypto“ API
vorgestellt.
Bouncy Castle Crypto API
Die „Legion of the Bouncy Castle” ist ein Zusammenschluss, welcher seit mehr als 10 Jahren
existiert. Sie haben sich zum Ziel gesetzt, Verschlüsselung für Jedermann zur Verfügung zu
stellen. Dazu haben sich im Laufe der Zeit Sicherheits-APIs für die Sprachen C# und Java
entwickelt. Dabei hält die Java Version folgende Funktionalität bereit: [15]
• eine leichtgewichtige Kryptografie API
• einen Provider für die Java Kryptografie Erweiterung und Architektur
• eine Bibliothek für das Schreiben und Einlesen von ASN.1 enkodierten Objekten
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 20/47
Kapitel 3: Grundlagen 14
• eine leichtgewichtige Benutzerseiten TLS API
• Generatoren für v1 und v3 X.509 Zertifikate, v2 CRLs und PKCS12 Dateien
• Generatoren für v2 X.509 Attribut Zertifikate
• Generatoren / Prozessoren für S/MIME, CMS, OCSP, TSP und OpenPGP
Für dieses Projekt sind nur die X.509 Zertifikate von Bedeutung.
3.3 SNMP
SNMP steht kurz für „Simple Network Management Protocol“. Das Protokoll wurde 1988
von der Internet Engineering Task Force (IETF) veröffentlicht. Es dient der zentralen Steue-
rung und Überwachung von Netzwerkkomponenten. Dabei beschreibt es den Aufbau der Da-
tenpakete zum Anfordern und Erhalten von Management-Informationen. Bei der Verwendung
des Protokolls wird zwischen Agenten und Managern unterschieden. Agenten sind Software-
systeme, welche auf SNMP-Anfragen reagieren und somit Status- und Statistikinformationen
bereitstellen. Diese Informationen werden in der „Management Information Base“ (MIB) in
Form von „Managed Objects“ bereitgestellt. Um die Informationen gezielt abzurufen werden
„Object Identifier“ (OID) eingesetzt. Ein OID ist eine Zeichenkette aus Nummern, jede dieser
Nummern steht für ein bestimmtes Level innerhalb eines hierarchischen Baumes. So erreicht
man mit dem Ast „1.3.6.1.2.1“ die SNMP MIB-2 zum Internetprotokoll (IP) und „Transmissi-
on Control Protocol“ (TCP). Dieses MIB-Modul sollte von jeder Netzwerkkomponente um-
gesetzt werden, wodurch gleiche Informationen durch dieselbe OID zu erreichen sind. Für
diese Arbeit wird ein bereits für die Universität der Bundeswehr München (UniBwM) im glo-
balen Verzeichnis registrierter Zweig verwendet. Seine Bezeichnung ist „1.3.6.1.4.1.24094“,
sie steht für „iso.org.dod.internet.private.enterprises.UniBwM“. Manager sind Anwendungen
welche SNMP Agenten verwalten. Dies geschieht durch die Ausstellung von Anfragen, Verar-
beiten von Antworten und das Lauschen nach Agenten TRAPs. Eine TRAP ist eine von einem
Agenten gesendete Fehlermeldung, welche nur in akuten Notfällen verwendet wird. Die neus-
te Version v3 des Protokolls bietet im Gegensatz zu den Vorgängern ein Sicherheits- und Ad-
ministrationsframework. Dazu zählt unter anderem eine verschlüsselte Übertragung mit Trip-
le-Data Encryption Standard (DES) oder Advanced Encryption Standard (AES). [16]
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 21/47
Kapitel 3: Grundlagen 15
Abbildung 6: Schema SNMP Kommunikation
3.3.1 SNMP in Java
Java stellt wiederum keine native Lösung für die Verwendung von SNMP bereit. Um SNMP
dennoch zu nutzen, kann das Paket „SNMP4J“ verwendet werden. Frank Fock und Jochen
Katz arbeiten seit nun fast sieben Jahren an diesem Projekt. SNMP4J unterstützt die Kom-
mandoerzeugung für SNMP Manager und das Reagieren auf Kommandos für Agenten. Es ist
ein rein objektorientiertes Paket, welches sich an SNMP++ anlehnt. Das Paket bietet folgende
Features: [17]
• SNMPv3 mit MD5 oder SHA Authentifikation
• DES und AES 128bit, AES 192bit oder AES 256bit Verschlüsselung
• Veränderbare Nachrichten Verarbeitung für MPv1,MPv2c und MPv3
• Veränderbare Transportprotokolle. UDP und TCP sind bereits enthalten
• Synchrone und Asynchrone Anfragen
• Multi-Thread Unterstützung
• Dokumentation (Logging) mit Log4J
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 22/47
Kapitel 4: Design 16
4 Design
Im folgenden Kapitel wird ein Konzept entworfen welches die Bedingung der Anforderungs-
analyse erfüllt. Dabei werden verschieden Herangehensweisen betrachtet und anschließen die
zur Erreichung des Ziels beste Methode ausgewählt.
4.1 Statusinformationen und Einstellungen
Wie in den Anforderungen an das System festgelegt wurde, sollen Statusinformationen und
Einstellungen bereitgestellt werden. Bei der Umsetzung gibt es verschiedene Möglichkeiten
um dies zu realisieren.
4.1.1 Separat an jedem Automaten
Eine erste Variante wäre eine Verwirklichung bei der die Einstellungen an jedem Kaffeeauto-
maten getätigt werden. Jedes System kann einzeln konfiguriert und genau auf seinen Standort
innerhalb einer Firma angepasst werden. Zum Beispiel kann ein Automat in der Kantine für
ein anderes Abrechnungssystem eingestellt werden als ein Automat im Bürodistrikt. Die Lea-
singfirma hat die Möglichkeit auf jedes Gerät über das Internet separat zuzugreifen und Sta-
tusinformationen abzurufen oder Einstellungen zu setzen.
4.1.2 Zentralisierung
Einstellungen werden zentral an einem serverartigen System gesetzt, welches die Konfigura-
tion automatisch an alle angeschlossenen Kaffeeautomaten überträgt. Der Aufwand für die
Änderung wird minimiert, da sie nur am Server vorgenommen werden müssen. Anfragen oder
Befehle der Leasingfirma werden über das Internet zu dieser Verwaltungseinheit gesandt und
diese kümmert sich selbständig um die Umsetzung beziehungsweise Durchsetzung. Voraus-
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 23/47
Kapitel 4: Design 17
setzung dabei ist ein gleicher technischer Aufbau der Automaten, damit alle Systeme auf die
Einstellungen gleich regieren können.
4.1.3 Fazit
Die aufgezeigten Alternativen halten jeweils Vor - und Nachteile bereit. So ist der Aufwand für
die Einstellung an jedem Gerät einzeln erheblich größer. Zusätzlich stellt der Anschluss jedes
Automaten an das Internet zur Kommunikation mit der Leasingfirma eine enorme Sicherheits-
lücke dar, da entsprechend viele Ports oder IP-Adressen freigegeben werden müssen. Dieses
Problem besteht bei einer zentralisierten Verwaltung der Einstellungen nicht. Hier ist es nur
von Nöten der Servereinheit einen Zugang zum Internet zu ermöglichen. Jedoch ist die Mög-
lichkeit zur Konfiguration des Systems auch äquivalent niedriger. Für die Umsetzung in die-
sem Projekt wird daher eine abgewandelte Version der zentralisierten Verwaltung gewählt. Es
wird ein Serversystem bereitgestellt, welches eine Anbindung zum Internet bekommt, um mit
der Leasingfirma kommunizieren zu können. Damit das Problem der eingeschränkten techni-
schen Modifikation behoben wird, bekommt die Verwaltungseinheit Einstellungssätze für ver-
schiedene Bauweisen der Kaffeeautomaten. Der Server kann nun bei dem Kaffeeautomaten
abfragen um welche Konfiguration es sich handelt und die dafür vorgesehenen Einstellungen
übertragen. Bei dieser aufgezeigten Realisierung sind Sicherheitslücken und Aufwand mini-
miert trotz einer insgesamt hohen Flexibilität der Systemkonfiguration.
Abbildung 7: Schema Zentralisierter Einstellungen
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 24/47
Kapitel 4: Design 18
4.2 Internet Übertragung
Damit eine Fernwartung und Diagnose der Kaffeeautomaten möglich ist, muss eine Kommu-nikation mit der Leasingfirma über das Internet realisiert werden. Vorrangig werden Einstel-
lungen von der Leasingfirma gesendet oder Statusinformationen des Serversystems abgeru-
fen. Diese Übertragungen müssen jedoch gesichert werden da Unbefugte sonst die Möglich-
keit hätten, Einstellungen des Systems zu ändern und es somit schädigen oder vertrauliche
Nutzerdaten entwenden könnten.
4.2.1 Entwurf eines eigenen Protokolls
Für den Zweck der Übertragung besteht die Möglichkeit ein eigenes Transportprotokoll zu
entwerfen. Das Protokoll würde, auf Basis der „Transport Layer Security“ (TLS) zur sicheren
Übertragung, umgesetzt werden. Bei der Erstellung müssen Funktionen wie das Setzen, sowie
Abrufen von Einstellungen, Übertragen von Statusinformationen und die Möglichkeit zu Feh-
lermeldungen realisiert werden.
4.2.2 SNMP
Das Simple Network Management Protocol wurde bereit im Grundlagen Kapitel beschrieben
und verfügt durch die „Managed Objects“ über eine Möglichkeit Informationen und Einstel-
lungen bereit zu stellen, welche wiederum gezielt durch SNMP-Pakete geändert oder abgeru-
fen werden können. In der neusten Version v3 stellt es, wie bereits erwähnt, eine Verschlüss-
lung mit Tripple-DES oder AES bereit. [16]
4.2.3 Fazit
Die Entscheidung für die Wahl einer passenden Übertragungsmethode für das System, fällt
leicht. Unbestritten stellt der Entwurf eines eigenen Protokolls einen immensen Aufwand dar,
welcher natürlich durch ein perfekt auf das System zugeschnittenes Ergebnis belohnt wird. Im
Falle dieses Projektes ist dieser Aufwand jedoch keinesfalls gerechtfertigt, da SNMP alle
Notwendigen Anforderungen mehr als ausreichend erfüllt. Zusätzlich bietet es durch „Mana-
ged Objects“ und MIB bereits eine strukturierte Möglichkeit zur Verwaltung und Änderung
von Einstellungen und Informationen.
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 25/47
Kapitel 4: Design 19
4.3 Autorisierung von Technikern
Der Zugriff auf sensible Informationen und Einstellungen des Systems muss vor unbefugtenVeränderungen geschützt werden. Somit ist eine sichere Authentifizierung eines Technikers
von Nöten. Die Faktoren der Authentifizierung wurden bereits im Grundlagen Kapitel erklärt.
Es werden nun Beispiele für die Umsetzung dieser Faktoren gewählt, die für das Projekt in
Frage kommen. Anschließend wird eine Entscheidung zugunsten der praktikabelsten Lösung
getroffen.
4.3.1 Passwort
Passwörter sollten wohl das bekannteste Beispiel für eine Authentifizierung über den Nach-
weis von Wissen sein. Bei der Verwendung von Passwörtern zur Autorisierung eines Techni-
kers gibt es verschiedene Möglichkeiten der Umsetzung. Gemeinsam haben alle Methoden
den Vorteil von Passwörtern. Sie sind einfach bei Mensch und Maschine zu realisieren und es
wird keine zusätzliche Hardware benötigt. [9] Eine Variante wäre die Einführung eines „Ad-
ministratorpasswortes“. Diese kennen alle Techniker und haben somit die Möglichkeit sich
Zugang zu dem Wartungs- und Diagnosesystem zu verschaffen. Jedoch ist die Gefährdung desSystems bei der Benutzung dieser Alternative zu hoch. Ein Unbefugter, der das Passwort er-
späht, hat sofort Zugriff auf alle Bereiche und es kann nicht nachvollzogen werden wer den
Schaden verursacht hat. Die Umsetzung eines Nutzersystems für Techniker scheint somit
sinnvoller, da bei offensichtlich unbefugter Benutzung das Nutzerkonto sofort gesperrt wer-
den kann, bis die Ursache behoben und das Problem geklärt wurde.
4.3.2 Token
Für eine Authentifizierung über einen Token ist der Besitz des Token zwingend notwendig.
Zum Einsatz in diesem Projekt wird für jeden Techniker ein Token erstellt, welcher wichtige
Informationen zur eindeutigen Identifizierung des Technikers bereithält. Dabei muss bei der
technischen Realisierung darauf geachtet werden, dass der Speicher nicht direkt auslesbar ist
um ein Vervielfältigen zu verhindern. [8] Um eine zusätzliche Integrität der Daten zu gewähr-
leisten, werden die Daten des Technikers in ein digitales Zertifikat eingebettet. Bei Verlust
kann das entsprechende Zertifikat per „Certificate Revocation List“ (CRL) über die Serien-
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 26/47
Kapitel 4: Design 20
nummer zurückgerufen werden. [18] Für die technische Realisierung ist eine Radio Fre-
quency Identification (RFID) denkbar. Radiofrequenz Identifikation ist ein System der berüh-
rungslosen Datenübertragung. Hierbei werden Informationen von einem mobilen Transponder
zu einem Lesegerät versandt, oder umgekehrt. [19]
Abbildung 8: Schema RFID-System [19]
4.3.3 Fingerabdruck
Zur Identifizierung der Techniker kann an den Wartungs- und Diagnoseeinheiten ein Finger-
printsensor angebracht werden. Dazu werden die entsprechenden Templates bei Einstellung
eines Technikers aufgenommen und an die von Ihm zu wartenden Systeme übertragen. Ein
Vorteil dieser Methode ist, dass ein Fingerabdruck vom Techniker weder vergessen noch ver-
loren werden kann und er somit keinesfalls durch solche Nichtigkeiten von seiner Arbeit ab-
gehalten wird.
Abbildung 9: Fingerprintsensor [20]
4.3.4 Fazit
Alle drei aufgezeigten Varianten bieten ausgeglichene Vor - und Nachteile und kommen somit
für den Einsatz infrage. Bei genauerer Betrachtung fällt jedoch auf, dass der finanzielle Auf-
wand der Biometrieerkennung erheblich höher ist, als bei den beiden anderen Alternativen.
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 27/47
Kapitel 4: Design 21
Somit wird diese Methode zurückgestellt. Um einem Sicherheitsverlust durch Verlieren eines
Token oder Erspähen eines Passwortes entgegen zu wirken, werden die beiden Methoden
kombiniert. Ein bekanntes Passwort oder ein gefundener Token reicht somit für eine Authenti-
fizierung nicht aus. Um Zugriff zum System zu erlangen muss man über Beides verfügen. Es
wird somit an der Wartungs- und Diagnoseeinheit ein RFID Empfänger installiert. Sobald ein
Techniker in das Nahfeld [19] kommt wird er vom System erkannt und zur vollständigen Au-
thentifizierung nach seinem Passwort gefragt. Bei der Eingabe des Passwortes wird von der
Challenge-Response Methode Gebrauch gemacht. Dabei wird nicht das Passwort selbst über-
tragen sondern nur ein Beweis dafür, dass das Passwort bekannt ist. [8]
Abbildung 10: Schema Authentifizierung Techniker
4.4 Dokumentation
Zugriffe oder Änderungen am System sollen zu Diagnosezwecken gespeichert werden. Dazu
werden auf der Wartungs- und Diagnoseeinheit rotierende Logdateien angelegt. Diese können
vor Ort von Technikern oder remote von der Leasingfirma eingesehen werden.
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 28/47
Kapitel 4: Design 22
4.5 Verarbeitung von Störungen oder Fehlern
Auftretende Fehler oder Störungen werden dokumentiert. Hat ein Kaffeeautomat eine Stö-rung, sendet dieser einen Fehlerbericht an die Wartungs- und Diagnoseeinheit. Nun werden
alle wichtigen Informationen dazu automatisch geloggt und eine mögliche Lösungsstrategie
eingeleitet. Sollte dieser Versuch fehlschlagen und der Fehler weiterhin bestehen, wird die
Fehlermeldung von dem Server an die Leasingfirma weitergeleitet. Diese verarbeitet einge-
hende Fehler in einer Art Ticketsystem. Ein registrierter Fehler wird in eine Datenbank aufge-
nommen und in der Supportsoftware als ausstehend angezeigt. Sobald ein Techniker begon-
nen hat diese Störung zu bearbeiten, verschwindet der Fehler aus der Anzeige der ausstehen-
den Meldungen und andere Techniker haben nur noch begrenzten Zugriff darauf. Der bearbei-
tende Techniker kann nun Maßnahmen zur Behebung des Fehlers einleiten oder gegebenen-
falls einen Techniker zum Vor -Ort-Service schicken.
Abbildung 11: Schema Fehlerverarbeitung
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 29/47
Kapitel 5: Implementierung 23
5 Implementierung
Das folgende Kapitel beschreibt einen Prototyp des Gesamtsystems zu Wartung und Diagno-
se. Dabei werden Konzepte verwendet die im vorherigen Abschnitt dieses Dokumentes her-
ausgearbeitet wurden. Bei der Umsetzung traten neue Probleme auf, die in der Konzeption
nicht bedacht werden konnten. Auf diese wird gezielt eingegangen. Die Implementierung des
Systems teilt sich in verschiedene Abschnitte:
Abbildung 12: Unterteilung Implementierung
Wie anhand des Design-Kapitels ersichtlich ist, wird ein Großteil der Funktionalität bei der
Wartungs- und Diagnoseeinheit liegen, welche in der Implementierung „ClientServer“ ge-
nannt wurde. Für die Umsetzung wurden zwei Pakete erstellt:
Abbildung 13: Pakete der Implementierung
Auf den Inhalt der Pakete wird in den folgenden Abschnitten genauer eingegangen.
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 30/47
Kapitel 5: Implementierung 24
5.1 Kaffeeautomat
Wie bereits in der Einleitung erwähnt, wurden durch die Teilung in Front- und Backend dieKernfunktionen des Kaffeeautomaten von den Zusatzfunktionen getrennt. Dadurch ist für die
Implementierung von Wartungs- und Diagnosemechanismen nur das Frontend relevant. Das
Frontend stellt in Bezug auf Einstellungen und Statusinformationen einen SNMP Agenten dar.
Es erhält Befehle oder Anforderungen vom ClientServer, auf welche es reagieren muss. Zu-
sätzlich sollte es ermöglicht werden, Traps zu senden. Da derzeit keine Fehlermeldungen des
Kaffeeautomaten bekannt sind, welche den Einsatz eines Technikers erfordern, wurde die
Funktion nicht implementiert.
Abbildung 14: Frontend
5.1.1 CMaschineAgent und AgentFactory
Das Frontend instanziiert mit der Klasse „CMaschineAgent“ einen SNMP Agenten. Diese
Klasse erbt direkt von AgentFactory, ein Grundbaustein für die benötigten SNMP Agenten in
diesem Projekt. Die AgentFactory erweitert die Klasse „org.snmp4j.agent.BaseAgent“. Dabei
werden mit der Funktion „addViews(vacm)“ im Projekt standardisierte Zugriffsfreigaben ge-
setzt. Die Funktionen „moreViews(vacm)“, „addCommunities(communityMIB)“ und
„buildMO()“ sind in der Klasse AgentFactory standartmäßig leer. Sie können später von er-
benden Klassen überschrieben werden, um den Agenten weiter anzupassen. Unter
„setUp(name)“ müssen geforderte SNMP Variablen der SNMP MIB-2 registriert werden.
Exemplarisch hierfür wurde unter der OID „1.3.6.1.2.1.1.1.0“ die Systembeschreibung mit
dem Inhalt des Strings „name“ gesetzt. Um einen Agenten zu erzeugen wird die Funktion „ge-
tInstance(name)“ verwendet. Diese liefert eine fertig konfigurierte Instanz eines SNMP Agen-
ten.
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 31/47
Kapitel 5: Implementierung 25
Abbildung 15: CMaschineAgent und AgentFactory
Die Klasse CMaschineAgent überschreibt einige der AgentFactory Prozeduren. In „more-
Views()“ und „addCommunities()“ wird der Agent für das SNMPv2c Security Modell vorbe-
reitet. Dies ist notwendig, da die vom ClientServer verwendete „Broadcast Detection“ keine
Authentifizierung per Nutzername und Passwort unterstützt. GetInstance() wurde überschrie- ben um einen Logger für den Agenten zu initialisieren. Zum Loggen findet das Paket „log4j“
innerhalb des Paketes Anwendung. Mittels Konfigurator können die Formatierung und das
Ziel der Ausgabe bestimmt werden. In diesem Fall wird eine rotierende Logdatei mit dem
Namen, der bei der Instanziierung angegeben wurde, im Ordner „logs“ erstellt. Die Methode
„buildMO()“ registriert die Managed Objects des Agenten. Hier wurden alle Variablen umge-
setzt, die ein Kaffeeautomat bereitstellt. Dazu gehören unter anderem:
1.3.6.1.4.1.24094.1.2.1 : Aktueller Status
1.3.6.1.4.1.24094.1.2.2 : Fehlercode (falls eine Störung vorliegt)
1.3.6.1.4.1.24094.1.2.3 : Zähler der Maschine, als Tabelle
1.3.6.1.4.1.24094.1.2.4 : Zeit zum Einschalten des Automaten
1.3.6.1.4.1.24094.1.2.5 : Zeit zum Ausschalten
1.3.6.1.4.1.24094.1.2.6 : Einzuschaltende Tage , als Tabelle
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 32/47
Kapitel 5: Implementierung 26
Für die Erstellung von Tabellen wurde die Klasse MOTableBuilder genutzt und für Skalare
MOScalarFactory erweitert. [21]
5.1.2 AutoCheck
AutoCheck ist ein Thread, der die Verbindung zwischen den Managed Object des Agenten
und den Einstellungen des Backend herstellen soll. Bei der Bearbeitung des Projekts wurde
keine Möglichkeit gefunden, direkt auf den Empfang eines SNMP SET Befehls zu reagieren.
Somit kann keine sofortige Übertragung der Einstellungen zum Backend stattfinden. Auto-
Check prüft in regelmäßigen Zeitintervallen ob Änderungen vorgenommen wurden. Wenn
dies der Fall ist, wird die Übertragung zum Backend gestartet.
5.2 Wartungs- und Diagnoseeinheit
Die Wartungs- und Diagnoseeinheit stellt den größten Teil der Funktionalität bereit. In der
Implementierung wird sie durch den ClientServer repräsentiert. Nach dem Start des Servers
wird die IP-Adresse der Leasingfirma abgefragt. Nachdem diese eingegeben wurde, wird die
Initialisierung fortgesetzt. Geloggt werden die Abläufe innerhalb des ClientServers wiederummit dem log4j Paket und rotierenden Logdateien.
Abbildung 16: ClientServer
5.2.1 ClientServerAgent
Wie auch schon bei der Klasse CMaschineAgent erbt der ClientServerAgent von AgentFacto-
ry und überschreibt Methoden. Hiervon sind nur die „getInstance(name)“, welche wiederum
einen Logger initialisiert, und die „buildMO()“, betroffen. Hier werden diesmal die Variablen
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 33/47
Kapitel 5: Implementierung 27
des Servers registriert. Unter den verwalteten Objekten befinden sich Informationen wie Sta-
tus („1.3.6.1.4.1.24094.1.1.2“) und Fehlercode („1.3.6.1.4.1.24094.1.1.3“), darüber hinaus
auch die Einstellungen zu den verschiedenen Konfigurationen der Kaffeeautomaten, wie im
Konzept beschrieben. Zu Demonstrationszwecken wurde in diesem Prototyp jedoch nur eine
Konfiguration implementiert. Diese ist unter der OID „1.3.6.1.4.1.24094.1.1.1“ zu finden und
beinhaltet beispielsweise folgende Einstellungen:
1.3.6.1.4.1.24094.1.1.1.1 : Zeit zum Einschalten der Automaten
1.3.6.1.4.1.24094.1.1.1.2 : Zeit zum Ausschalten
1.3.6.1.4.1.24094.1.1.1.3 : Einzuschaltende Tage , als Tabelle
1.3.6.1.4.1.24094.1.1.1.4 : Zeit nach der die Automaten in den Standby wechseln
Die Leasingfirma kann über SNMP Befehle auf die Informationen und Einstellungen dieses
Agenten zugreifen. Für die Übertragung werden eine MD5-Authentifizierung, DES-
Verschlüsselung und ein Standardbenutzername sowie ein Standardpasswort verwendet. Die
Nutzerdaten können für das Endprodukt entsprechend angepasst werden. Es ist auch möglich
verschiedene Nutzer mit unterschiedlichen Zugriffsrechten anzulegen.
5.2.2 LocalMaintenance
Die Klasse LocalMaintenance ist ein Thread, welcher die Authentifizierung von Technikern
übernimmt. Aus finanziellen Gründen wurde das RFID System, welches in der Designphase
beschrieben wurde, durch ein USB-Dongle ersetzt. Dabei handelt es sich wiederum aus Kos-
tengründen, um einen einfachen USB-Stick mit sehr kleinen Ausmaßen. Im Endprodukt sollte
dieser jedoch mindestens durch einen nicht kopierbaren Token ersetzt werden. Für den Ein-
satz in diesem Prototyp reicht der „Pico-c“ der Firma „Super Talent“ aus. Er zeichnet sich
durch seine kleine Bauweise aus. Durch die an ihm befestigte Kette kann er ohne Probleme
durch einen Techniker mitgeführt werden.
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 34/47
Kapitel 5: Implementierung 28
Abbildung 17: Pico-c der Firma Super Talent [22]
Sobald der USB-Stick an den Server angeschlossen wird, erkennt ihn das System. Da Java ein
begrenztes Spektrum an Hardware Unterstützung beinhaltet, muss die Erkennung für jedes
Betriebssystem des Servers extra implementiert werden. Für die, mit dem Prototyp entwickel-
te Windowsversion („WinCertHandle“), muss der USB-Stick als „USBDONGLE“ benanntsein. Jegliche Aktivitäten, die mit diesem USB-Dongle oder der Authentifizierung zu tun ha-
ben, sind in der abstrakten Klasse CertHandle zusammen gefasst. Um ein anders Betriebssys-
tem zu unterstützen, muss eine neue Klasse geschrieben werden, die von CertHandle erbt und
die Funktionen „getPath()“ und „isConnected()“ entsprechend überschreibt. Anschließend
muss der Aufruf des Konstruktors von LocalMaintenance mit der neuen Klasse angepasst
werden.
Abbildung 18: LocalMaintenance Konstruktor
Der Anschluss des USB-Dongles wird geloggt und danach die Authentifizierung initialisiert.
Hierzu wird der Techniker zunächst nach seinem Passwort gefragt. Das Passwort entschlüsselt
einen PrivateKey, der auf dem Stick in der Datei „technician.prk“ gespeichert ist. Anschlie-
ßend wird mit der Challenge-Response Methode überprüft, ob dieser PrivatKey zu dem imZertifikat enthaltenen PublicKey gehört. Das Zertifikat des Technikers befindet sich in der
Datei „technician.cert“. Der Techniker hat drei Versuche um das Passwort richtig einzugeben,
jeder Fehlversuch wird ebenfalls geloggt. Nach dem dritten Fehlversuch wird automatisch ei-
ne Meldung mit den Daten des Technikers an die Leasingfirma gesandt und das System für
zehn Minuten gesperrt. Dies gibt der Leasingfirma genug Zeit, um auf einen eventuellen un-
befugten Zugriffsversuch entsprechend zu reagieren. Wenn die Verifizierung jedoch erfolg-
reich war, öffnet sich dem Techniker das „LocalMaintenanceForm“ (Abbildung 19). Hier
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 35/47
Kapitel 5: Implementierung 29
werden grundsätzliche Informationen angezeigt und die Einstellungen der Kaffeeautomaten
können geändert werden.
Abbildung 19: LocalMaintenanceForm
Nach Schließen des Formulars wird dokumentiert, welcher Techniker Änderungen vorge-
nommen hat und das System wiederum eineinhalb Minuten gesperrt. Somit hat der Server
Zeit, die Einstellungen an die angeschlossenen Kaffeeautomaten zu übertragen. Für die zu
übertragenden Einstellungen wurden exemplarisch die Ein- und Ausschaltzeit sowie die ein-
zuschaltenden Tage implementiert.
5.2.3 ServerTrapReceiver und TrapReceiver
TrapReceiver ist eine abstrakte Klasse zum Empfangen von Traps. Sie basiert auf der Bei-
spielimplementierung MultiThreadedTrapReceiver des SNMP4J Projekts und implementiert
das Interface „org.snmp4j.CommandResponder“. Die Klasse ServerTrapReceiver erbt von
TrapReceiver und überschreibt die Funktion „processPdu(event)“. Mit dieser Methode wird
die Reaktion auf eingehende Traps festgelegt. Da ein Kaffeeautomat nur einen Trap sendet,
wenn ein äußerst schwerwiegender Fehler vorliegt, werden die ankommenden Traps von der
Klasse ServerTrapReceiver direkt an die Leasingfirma weitergeleitet. Hier kann im Endpro-
dukt jedoch eine differenziertere Verarbeitung der Traps umgesetzt werden.
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 36/47
Kapitel 5: Implementierung 30
5.2.4 AutoMaintenance
Die AutoMaintenance stellt das spätere Kernstück der Wartungs- und Diagnoseeinheit dar.
Die Aufgabe der Klasse liegt darin, Fehlercodes oder Störungen der Kaffeeautomaten zu er-
kennen und entsprechende Gegenmaßnahmen einzuleiten. Aufgrund von mangelnden Kennt-nissen über die Störungsmeldungen der Kaffeeautomaten, sind in diesem Prototyp keine
Fehlercodes implementiert wurden. Somit nimmt die AutoMaintenance einen abgespeckten
Aufgabenbereich wahr. In regelmäßigen Zeitintervallen wird die Netzwerkadresse des Servers
ermittelt und anschließend eine SNMP Anfrage über die Broadcastadresse versandt. Der Ser-
ver registriert alle eingehenden Antworten und filtert über den Inhalt, nicht zur Leasingfirma
gehörende Geräte, heraus. Bei den Verbleibenden handelt es sich um die gesuchten Kaffeeau-
tomaten. Die IP-Adressen der Automaten werden in eine Liste aufgenommen, aus welcher die Anzahl der angeschlossenen Clients ermittelt wird. Danach wird der Status eines jeden
Gerätes geprüft. Wenn ein Fehlerstatus entdeckt wird, dokumentiert diesen das System sofort.
In jedem fünften Intervall werden die zentralen Einstellungen an alle Adressen in der Liste
übermittelt. Somit können auch neue, nicht konfigurierte Kaffeeautomaten sofort in das Sys-
tem integriert werden.
5.3 Leasingfirma
Im Endprodukt wird dieser Teil der Implementierung den wahrscheinlich größten Umfang be-
sitzen. Wie bereits im Design beschrieben, sollte an dieser Stelle eine ausführliche Techniker-
verwaltung mit CRL und ein weitreichendes Ticketsystem für eingehende Traps zu finden
sein. Da das Hauptaugenmerkt dieser Arbeit nicht auf diesen Verwaltungsmechanismen liegt,
wurden nur die Kernfunktionen der Leasingfirma umgesetzt. In der Implementierung wird dieLeasingfirma durch die Klasse „Lessor“ repräsentiert.
Abbildung 20: Lessor
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 37/47
Kapitel 5: Implementierung 31
5.3.1 LessorTrapReceiver
Wie auch der „ServerTrapReceiver“, erweitert der LessorTrapReceiver die Klasse TrapRecei-
ver und überschreibt die Funktion „processPdu(event)“. Der Empfang eines Traps wird do-
kumentiert, und anschließend in ein stark vereinfachtes „Ticketsystem“ übernommen. Wennder Nutzer nicht das „TrapManagement“ geöffnet hat, wird er mit einer Meldung über den
Eingang informiert.
Abbildung 21: „TrapManagement“ Ansicht
Da eingegangene Traps sofort in einer Ini-Datei gespeichert werden, kann auch nach Schlie-
ßen und erneutem Öffnen des Programms auf alte Traps zugegriffen werden. Über den Button
„Löschen“ kann die Ausgewählte Meldung permanent gelöscht werden. Bei einem Klick auf
den Button „Zum Client verbinden“ wird die Ansicht „ClientVerbindung“(Abbildung 22) ge-laden. Die Ziel IP-Adresse wird automatisch übernommen. In dieser Ansicht können SNMP
Befehle gesendet und Antworten empfangen werden. Mit der Auswahl der Methode GET oder
SET wird die Ansicht entsprechend angepasst. Wenn eine Anfrage durch Hinzufügen von OID
mit einer eventuellen Zuweisung Erstellt wurde, kann die Anfrage übertragen werden. Ant-
worten, die das System daraufhin erhält, werden simultan in die OID Liste (Abbildung 22,
rechts) übernommen und können direkt für weiter Anfragen verwendet werden.
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 38/47
Kapitel 5: Implementierung 32
Abbildung 22: „ClientVerbindung“- Ansicht
5.3.2 TechnicianManagement
Diese Klasse übernimmt die Aufgabe einer CA. TechnicianManagement ist eine abstrakte
Klasse, welche auf die Funktionen eines CertHandle zurückgreift und somit auf das verwen-
dete Betriebssystem beim Aufruf des Konstruktors angepasst werden muss. Bei einer Umset-
zung muss die Methode „saveTech(tech)“ überschrieben werden. Diese dient der Speicherung
und Verwaltung erstellter Techniker. Der Prototyp verwendet die Implementierung „NoSa-
veTMan“, welche keine Speicherung oder Verwaltung von Technikern vorsieht. Das Pro-
gramm stellt zum TechnicianManagement drei Ansichten bereit, welche die entsprechenden
Funktionen verfügbar machen. Bei der Erstinbetriebnahme muss ein neues Firmenzertifikat
erstellt werden. Wenn keine Key-Dateien gefunden werden können, weist das System auf eine
Neuerstellung hin. Dazu gibt man in der „Neues Firmenzertifikat“ Ansicht das Land und den
Namen der Firma ein. Bei Klick auf den Button, werden nun vom TechnicianManagement ein
zufälliger PublicKey, der dazu passende PrivateKey erstellt und die Firmendaten in der Datei
„TManagementSettings.ini“ gespeichert. Die Datei „ca.puk“ muss nun auf alle Kaffeeautoma-
ten der Leasingfirma übertragen werden. Dies geschieht am besten direkt bei der Fertigung.
Nun können mit der „Neuer Techniker“-Ansicht, neue Techniker -Zertifikate erstellt werden.
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 39/47
Kapitel 5: Implementierung 33
Abbildung 23: „Neuer Techniker“- Ansicht
Hier werden Name, Passwort und gegebenenfalls eine Unterorganisation des Technikers ein-
gegeben. Mit Klick auf den Button „Techniker erstellen“ wird, falls ein USB-Dongle ange-
schlossen ist, ein Technikerzertifikat erstellt und anschließend mit dem verschlüsselten Pri-
vateKey auf den USB-Stick übertragen. Das erstellte Zertifikat besitzt eine festgelegt Gültig-
keitsdauer von einem Jahr. Der Vorgang wird abgebrochen und der Nutzer darauf hingewie-
sen, falls kein USB-Dongle erkannt wurde. In der Ansicht „Techniker bearbeiten“ kann ein
bereits erstellter Techniker bearbeitet werden oder die Gültigkeit seines Zertifikates erneut auf
ein Jahr gesetzt werden. Wenn ein USB-Dongle angeschlossen ist, werden die darauf befindli-
chen Daten des Technikers automatisch in die Anzeige geladen. Dies kann jedoch aufgrund
der Komplexität asynchroner Verschlüsselung einen Moment dauern. Wenn der Nutzer einen
Techniker bearbeiten möchte, obwohl kein USB-Dongle angeschlossen ist, wird er ebenfalls
darauf hingewiesen.
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 40/47
Kapitel 6: Fazit 34
6 Fazit
Durch die Entwicklung eines Systems zur Wartung und Diagnose konnte das Einsatzgebiet
der Impressa X9 erheblich erweitert werden. Als Gesamtkonstrukt ist nun auch der Weg für
die Verwendung in großen Firmen mit vielen Kunden geebnet. Die Schaffung einer Wartungs-
und Diagnoseeinheit bildet die Grundlage für zukünftige Erweiterungen des Systems, da nun
Module wie eine Nutzerverwaltung bequem eingerichtet werden können. Darüber hinaus
können sie durch die Option der Fernwartung, verwaltet werden. Aufgrund der hohen Kom-
plexität der verwendeten Technologien, konnten nicht alle Konzepte der Designphase eins zu
eins umgesetzt werden. Jedoch stellen die vorgenommenen Anpassungen nur eine geringfügi-
ge Einschränkung der Funktionalität dar. Der innerhalb dieser Arbeit entworfene Prototyp, ist
keinesfalls vollständig und dient nur dem „Proof of Concept“. Trotz kleiner Einschränkungen
durch den gegebenen finanziellen, beziehungsweise zeitlichen Rahmen, konnten die Ziele die
zu Beginn der Arbeit erstellt wurden, zufriedenstellend erreicht werden.
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 41/47
Literaturverzeichnis vi
Literaturverzeichnis
[1] Euro-Informationen, Berlin : EU-Info.Deutschland - Deutsche trinken mehr Kaffee als
Wasser. http://www.eu-info.de/deutsche-europapolitik/Umfragen-Statistiken-
Deutschland/kaffee/, Stand: Dezember 2010
[2] Dürr, Dr. Ingolf : Deutsches Grünes Kreuz e. V. - Kaffee: Wirkung auf die Gesundheit.
http://www.dgk.de/fileadmin/user_upload/Fachleute_pdf/kaffee-publikums-
brosch_st.pdf, Stand: Dezember 2010
[3] JURA Elektroapparate AG: Technische Daten IMPRESSA X9 Win.
http://www.jura.com/de/home_x/products_commercial_use2/technical_data_jura_impre
ssa_x9win_eu-int.pdf, Stand: November 2010
[4] JURA Elektroapparate AG: Das Buch zur IMPRESSA X9 Win.
http://www.jura.com/de/home_x/service_support/manual_home/manual-
machines/download_manual_jura_impressa_x9win_deutsch.pdf, Stand: November
2010
[5] JURA Gastro Vertriebs-GmbH : JURA Gastro Vertriebs-GmbH Grainau.
http://www.juraworldgastro.de/IMPRESSA-X9-Win-p19.html, Stand: Dezember 2010
[6] Knösel, Marlene und Stefan Mazur, Bachelorarbeit "Design und Implementierung eines
Multimedia- und Kommunikationsrechners für moderne Kaffeemaschinen", 2010.
[7] Tsolkas, Alexander und Klaus Schmidt, "Zugriffskontrolle über Authentifizierung" in
Rollen und Berechtigungskonzepte. Wiesbaden, Deutschland: Vieweg+Teubner Verlag /
Springer Fachmedien Wiesbaden GmbH, 2010, Kap. 7, S. 127-157.
[8] Kappes, Martin , "Authentifikation" in Netzwerk- und Datensicherheit . Wiesbaden,
Deutschland: B.G. Teubner Verlag / GWV Fachverlage GmbH, 2007, Kap. 3, S. 39-68.
[9] Maus, Thomas , "Das Passwort ist tot — lang lebe das Passwort!" Datenschutz und
Datensicherheit - DuD, Vol. 32, Nr. 8, S. 537-542, 2008.
[10] IGEL Technology: Smart Card thin Client: Flexible thin clients with smart card readers.
http://smartcardthinclient.com/, Stand: Dezember 2010
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 42/47
Literaturverzeichnis vii
[11] Bless, Roland and Mink, Stefan and Conrad, Michael and Kutzner, Kendy and Blaß,
Erik-Oliver and Hof, Hans-Joachim and Schöller, Marcus , "Digitale Zertifikate, PKI
und PMI" in Sichere Netzwerkkommunikation.: Springer Berlin Heidelberg, 2005, S.
349-395.
[12] Cooper, D. : Internet X.509 Public Key Infrastructure Certificate.
http://tools.ietf.org/html/rfc5280, Stand: Mai 2008
[13] Ullenboom, Christian : Java ist auch eine Insel (8. Auflage). http://www.iks.hs-
merseburg.de/~uschroet/Literatur/Java_Lit/JAVA_Insel/javainsel_26_001.htm#mjc78fb
10cd3a6d5dc3e8d94d0d6162423, Stand: Dezember 2010
[14] Mansfeld, Adam : coffeehaus.de / Notizen / X509 Zertifikate mit Java erstellen.
http://coffeehaus.de/Notizen/X509ZertifikateMitJavaErstellen, Stand: Dezember 2010
[15] Bouncy Castle, Legion of the : bouncycastle.org. http://www.bouncycastle.org/, Stand:
Dezember 2010
[16] SNMP Research International, Inc. : Simple Network Management Protocol FAQ.
http://www.snmp.com/FAQs/, Stand: Dezember 2010
[17] Fock, Frank : SNMP4J - Free Open Source SNMP API for Java.
http://www.snmp4j.org/index.html, Stand: Dezember 2010
[18] Wölfl, Thomas , "Rückruf von Zertifikaten" in Formale Modellierung von
Authentifizierung und Authorisierung infrastrukturen, DUV, Ed., 2006, Kap. 4, S. 43-
56.
[19] Brooks Automation (Germany) GmbH - RFID Division: RFID - Erklärung der
Funktionsweise. http://www.brooks-rfid.com/de/rfid-grundlagen/rfid-technik.html,
Stand: Dezember 2010
[20] SecureNet Solutions. http://www.securenetsol.com/catalog/images/image009.jpg,
Stand: Dezember 2010
[21] Rask, Johan : Introducing to snmp4j - Jayway Team Blog.
http://blog.jayway.com/2010/05/21/introduction-to-snmp4j/, Stand: Dezember 2010
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 43/47
Literaturverzeichnis viii
[22] Amazon.com, Inc. oder Tochtergesellschaften : Super Talent STU4GPCN Pico-C 4GB
Speicherstick USB 2.0. http://www.amazon.de/Talent-STU4GPCN-Pico-C-
Speicherstick-nickel/dp/B001MF9TC2/ref=sr_1_7?ie=UTF8&qid=1293572533&sr=8-
7, Stand: Dezember 2010
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 44/47
Anhang ix
Anhang
Ausschnitt der im Projekt verwendeten MIB
CoffeeMLessorMIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Integer32 FROM SNMPv2-SMI
;
UniBwM MODULE-IDENTITY
LAST-UPDATED "200201300000Z"
ORGANIZATION "Universitaet der Bundeswehr Muenchen"
CONTACT-INFO
"postal:Kai Freytag
email:kai.freytag&unibw.de"
DESCRIPTION
"MIB structure used by UniBwM"
REVISION "200201300000Z"
DESCRIPTION
"Kaffeeautomat"
::= { enterprises 24094}
-- Net-SNMP enterprise-specific management objects
--
CoffeeMLessor OBJECT IDENTIFIER ::= {UniBwM 1}
ClientServer OBJECT IDENTIFIER ::= {CoffeeMLessor 1}
CMaschine OBJECT IDENTIFIER ::= {CoffeeMLessor 2}
UserManagement OBJECT IDENTIFIER ::= {CoffeeMLessor 3}
cMaschine OBJECT IDENTIFIER ::= {ClientServer 1}
Status OBJECT-TYPE
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 45/47
Anhang x
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Status of the Server. 1 -> OK ; 0 -> see ErrorCode"
::= {ClientServer 2 }
ErrorCode OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If State is 0 here can be found the ErrorCode"
::= {ClientServer 3 }
NOClients OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of connected Clients"
::= { ClientServer 4 }
trapOn OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"If it is 1 the Server will send TrapMessages"
::= { ClientServer 5 }
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 46/47
Anhang xi
Struktur-Ausschnitt der im Projekt verwendeten MIB
Abbildung 24: Ausschnitt der MIB-Struktur
5/17/2018 Fernwartung Und Fern Diagnose - slidepdf.com
http://slidepdf.com/reader/full/fernwartung-und-fern-diagnose 47/47
Anhang xii
CD-Rom
Inhalt:
- Source-Code, inklusive des Originalcodes, im Verzeichnis src/
- JavaDoc im Verzeichnis doc/ - Digitale Kopie dieser Bachelorarbeit