Inhalt · Prinzip „Alles aus einer Hand.“ Auf diese Weise ist es möglich Applikationen und Geräte Auf diese Weise ist es möglich Applikationen und Geräte in Automotivequalität

Inhalt I

Inhalt

Inhalt ......................................................................................................................... I

Abbildungsverzeichnis ................................................................................................. V

Tabellenverzeichnis .................................................................................................... VII

Abkürzungsverzeichnis ............................................................................................. VIII

1 Einleitung ..................................................................................................... 11

Motivation........................................................................................................ 11

Zielsetzung ...................................................................................................... 11

Kapitelübersicht............................................................................................... 12

2 Agilion GmbH .............................................................................................. 13

Vorstellung Agilion GmbH ............................................................................... 13

Das WIRELESS LOCATION SYSTEM ............................................................ 13

2.2.1 Systemarchitektur.......................................................................................... 14

2.2.2 Mobile TAG’s ................................................................................................. 14

2.2.3 Ankerknoten .................................................................................................. 15

2.2.4 Gateway ........................................................................................................ 15

2.2.5 Lokalisierungsserver ..................................................................................... 16

2.2.6 Visualisierung, Management und Administration ........................................... 16

3 Grundlagen zur Softwareentwicklung ....................................................... 17

ASP.NET......................................................................................................... 17

3.1.1 ASP.NET MVC .............................................................................................. 17

3.1.2 ASP.NET Web API ........................................................................................ 18

jQuery ............................................................................................................. 18

REST .............................................................................................................. 19

4 Anforderungsanalyse.................................................................................. 21

Ausgangssituation und Vorgaben .................................................................... 22

4.1.1 Stakeholder und Interessengruppen .............................................................. 22

4.1.2 System und Systemumgebung ...................................................................... 23

4.1.3 Inbetriebnahme und Wartung des WIRELESS LOCATION SYSTEM ............ 24

4.1.3.1 Inbetriebnahme ............................................................................................. 24

II Inhalt

4.1.3.2 Durch externe Fehlermeldung ausgelöste Wartung....................................... 30

4.1.3.3 Periodische Wartung ohne externe Fehlermeldung ....................................... 31

4.1.4 Einbettung in die Umgebung ......................................................................... 32

4.1.4.1 Integration in das WLS .................................................................................. 32

4.1.4.2 Schnittstellen ................................................................................................ 32

Funktionale Anforderungen ............................................................................. 33

4.2.1 Unterstützte Geschäftsprozesse ................................................................... 34

4.2.2 Funktionale Anforderungen als Product Backlog ........................................... 35

4.2.2.1 User Stories .................................................................................................. 36

4.2.3 Übersicht aller Anwendungsfälle ................................................................... 37

4.2.4 Ausgearbeitete Anwendungsfälle .................................................................. 37

4.2.5 Fachliches Datenmodell ................................................................................ 39

Nicht-Funktionale Anforderungen.................................................................... 41

4.3.1 Anforderungen an die Sicherheit ................................................................... 41

4.3.1.1 Datensicherheit ............................................................................................. 41

4.3.1.2 Authentifizierung ........................................................................................... 41

4.3.1.3 Funktionssicherheit ....................................................................................... 41

4.3.2 Einführung des Systems ............................................................................... 42

4.3.3 Anforderungen an die Dokumentation ........................................................... 42

4.3.4 Anforderungen an Betreuung und Betrieb ..................................................... 42

4.3.4.1 Pflege der Software....................................................................................... 43

4.3.4.2 Qualifikation des Personals ........................................................................... 43

4.3.4.3 Konfigurationsmanagement .......................................................................... 43

Kritischer Erfolgsfaktor .................................................................................... 43

5 Konzeption .................................................................................................. 45

Erstellung des Prüfkatalogs ............................................................................ 45

Prüfalgorithmen .............................................................................................. 47

5.2.1 Überprüfung auf mehrheitliche Einstellung eines Parameters ....................... 47

5.2.2 Überprüfung auf Durchschnitt ....................................................................... 48

5.2.3 Überprüfung auf einen Sollwert (int) .............................................................. 48

5.2.4 Überprüfung auf einen Sollwert (string) ......................................................... 49

Die Konfigurationsdatei ................................................................................... 50

5.3.1 Entwicklung der Konfiguration ....................................................................... 50

5.3.2 Aufbau der Konfigurationsdatei ..................................................................... 50

Systemarchitektur ........................................................................................... 51

5.4.1 IIS-Gehostetes System (Backend und Frontend) .......................................... 51

5.4.2 IIS-Gehostetes System (All in One) ............................................................... 53

5.4.3 Selfhosting .................................................................................................... 54

Softwarearchitektur ......................................................................................... 55

Inhalt III

5.5.1 Zusammenspiel der Softwaretechnologien .................................................... 56

5.5.2 Der Server ..................................................................................................... 56

5.5.3 Der Client ...................................................................................................... 57

5.5.4 Zu übertragende Datenstrukturen .................................................................. 58

5.5.5 Aktivitätsdiagramm ........................................................................................ 58

5.5.6 Dekomposition der SW-Einheit ...................................................................... 60

6 Implementierung ......................................................................................... 63

Sprint 1 Umsetzung der User Story ID 1 und 11 .............................................. 63

Sprint 2 Umsetzung der User Story ID 7 und 13 .............................................. 64

Sprint 3 Umsetzung der User Story ID 9, 10 und 12 ........................................ 66

6.3.1 Datenbankverbindung (ID 12)........................................................................ 66

6.3.2 Kategorisierung von Prüfkriterien (ID 10) ....................................................... 66

6.3.3 Mehrstufige Bewertung von Fehlern (ID 9) .................................................... 66

Sprint 4 Umsetzung der User Story ID 3, 5, 6 und 15 ...................................... 67

6.4.1 Ein- und Ausloggen von Usern mit WLS-Konto ............................................. 67

6.4.2 Unterstützung von Nutzerrollen ..................................................................... 68

Zusatz Reporterstellung und Performancesteigerung ...................................... 69

7 Fazit .............................................................................................................. 71

Erstellung der Software ................................................................................... 71

Weiterentwicklung des WLS ............................................................................ 71

8 Literatur ....................................................................................................... 72

Anlage, Checkliste der Anforderungsanalyse .............................................................. I

Anlage, Inbetriebnahme eines WLS ............................................................................. II

Vorphase ......................................................................................................................... II

Installationsphase .......................................................................................................... III

Ortungskonfiguration ...................................................................................................... IV

Anlage, Prüfkatalog ....................................................................................................... V

Ergebnis Brainstorming ................................................................................................... V

Ausgearbeiteter tabellarischer Katalog ........................................................................... VI

Anlage, Grafisches Design .......................................................................................... XI

CSS Formatvorlage der Buttonelemente ........................................................................ XI

Manipulation der Buttonelemente mittels jQuery am Beipiel Projekt: ............................. XII

IV Inhalt

Manipulation der Statusmitteilung in der Tabellenansicht mittels jQuery: ...................... XII

Anlage, Nutzerauthentifizierung ............................................................................... XIII

Anlage, XSL Formatvorlage ...................................................................................... XIV

Selbstständigkeitserklärung ...................................................................................... 15

Abbildungsverzeichnis V

Abbildungsverzeichnis

Abbildung 1 Systemarchitektur WLS ............................................................................... 14

Abbildung 2 Mobile TAG ................................................................................................. 14

Abbildung 3 Ankerknoten ................................................................................................ 15

Abbildung 4 Gateway ...................................................................................................... 15

Abbildung 5 Das MVC-Muster ......................................................................................... 18

Abbildung 6 Aktivitäten des RE ....................................................................................... 21

Abbildung 7 Prozessüberblick ......................................................................................... 23

Abbildung 8 Inbetriebnahme WLS Ist-Zustand ................................................................ 25

Abbildung 9 Netzwerkkonfiguration eines WLS ............................................................... 27

Abbildung 10 Ablauf der automatischen Zustandsüberwachung...................................... 28

Abbildung 11 Inbetriebnahme WLS Soll-Zustand ............................................................ 29

Abbildung 12 Wartung WLS mit Fehlermeldung Ist-Zustand ........................................... 30

Abbildung 13 Schematische Darstellung der Schnittstellen ............................................. 33

Abbildung 14 Gesamtübersicht Use Cases ..................................................................... 37

Abbildung 15 Das Datenmodell Element ......................................................................... 40

Abbildung 16 Das Datenmodell Failure ........................................................................... 40

Abbildung 17 IIS-Gehostetes System mit Back- und Frontend ........................................ 52

Abbildung 18 IIS-Gehostetes System (All in One) ........................................................... 53

Abbildung 19 Selfhosted Web API ................................................................................... 55

Abbildung 20 Client-Server-Architektur............................................................................ 55

VI Abbildungsverzeichnis

Abbildung 21 Aktivitätsdiagramm Kategorie wählen ........................................................ 59

Abbildung 22 Sequenzdiagramm .................................................................................... 60

Abbildung 23 Klassendiagramm Web API ....................................................................... 61

Abbildung 24 Navigationsmenü ....................................................................................... 63

Abbildung 25 Tabellarische Darstellung der Kategorie Tags ........................................... 64

Abbildung 26 Detailansicht .............................................................................................. 65

Abbildung 27 Formular Login als Teilansicht ................................................................... 67

Abbildung 28 Vorphase einer Inbetriebnahme .................................................................. II

Abbildung 29 Installationsphase eines WLS ..................................................................... III

Abbildung 30 Ortungskonfiguration eines WLS ................................................................ IV

Tabellenverzeichnis VII

Tabellenverzeichnis

Tabelle 1 Auflistung Stakeholder ..................................................................................... 22

Tabelle 2 Product Backlog............................................................................................... 35

VIII Abkürzungsverzeichnis

Abkürzungsverzeichnis

API Application Programming Interface

CAD Computer-Aided Design

CMT Condition Monitoring Tool

CSS Cascading Style Sheets

FEC Forward Error Correction

GUI Graphical User Interface

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

IIS Microsoft Internet Information Service

JSON JavaScript Object Notation

MA Mitarbeiter

OWIN Open Web Interface für .NET

RE Requirements Engineering

REST Representational State Transfer

SOAP Simple Object Access Protocol

SMTP Simple Mail Transfer Protocol

SSL Secure Sockets Layer

TLS Transport Layer Security

URI Uniform Resource Identifier

URL Uniform Resource Locator

Abkürzungsverzeichnis IX

VRML Virtual Reality Modeling Language

WLS WIRELESS LOCATION SYSTEM

XSL Extensible Stylesheet Language

XSL-FO XSL Formatting Objects

XSLT XSL Transformation

XML Extensible Markup Language

Einleitung 11

1 Einleitung

„Wie ist der Zustand meines Ortungssystems?“ Diese Frage stellt den Anstoß zu dieser

Arbeit dar, denn derzeit können diese nur sehr wenig Mitarbeiter bei der Firma Agilion

GmbH beantworten. Die theoretische Konzeption und prototypische Umsetzung eines

Condition Monitoring Tools sind Inhalte dieser Arbeit.

Motivation

Die Motivation zu diesem Projekt entstand während des Praxismoduls im Team der Inbe-

triebnahme bei der Agilion GmbH. Der Prozess der Inbetriebnahme und Wartung des

WIRELESS LOCATION SYSTEM ist derzeitig standardisiert aber mit wenig automatisier-

ten Aufgaben versehen. Da zum Teil sehr komplexe Datenabfragen eingesetzt werden

müssen um beispielsweise den Systemzustand abzubilden, kann sich die Arbeit sehr inef-

fizient gestalten. Ein Werkzeug, welches den Systemzustand überprüft und bei Bedarf

grafisch darstellt, steigert die Effizienz während des gesamten Zyklus.

Zielsetzung

Ziel dieser Arbeit soll es sein, den Prototypen eines Condition Monitoring Tool (CMT) zu

entwerfen und zu entwickeln. Das CMT soll zum einen zeigen, wie das Team der Inbe-

triebnahme bei Routinearbeiten unterstützt werden kann. Und zum anderen stellt es ein

Pilotprojekt zur Weiterentwicklung des WIRELESS LOCATION SYSTEM dar. In diesem

Zusammenhang dient die Entwicklung des Tools als Grundlage zur Evaluierung neuer

Basistechnologien. Die Evaluierung ist jedoch nicht Bestandteil dieser Arbeit.

Um die Software zu erstellen muss zunächst ein Prüfkatalog ausgearbeitet werden, an-

hand dessen Anomalien klassifiziert und entsprechende Maßnahmen eingeleitet werden

können.

12 Einleitung

Kapitelübersicht

Der Aufbau dieses Dokuments reflektiert die Arbeitsweise an dem Projekt. Folglich

schließt sich einem Kapitel für die Vorstellung des Betriebs, in dem die Arbeit erstellt wur-

de, und einem Kapitel mit Grundlagen die Anforderungsanalyse für die Software an. Die

Anforderungsanalyse, unterteilt in Ausgangssituation, funktionalen und nicht-funktionalen

Anforderungen, ist die Voraussetzung für die sich anschließende Konzeptentwicklung, in

der vor allem die Architektur des Softwaresystems behandelt wird. Diesem Kapitel

schließt sich die Dokumentation der Implementierung an, in dem vor allem die technische

Umsetzung der erarbeiteten Grundlagen und Anforderungen beschrieben wird. Den Ab-

schluss dieser Arbeit bildet ein Fazit, welches in Resümee über diese Arbeit und zukünfti-

ge Entwicklungen zieht.

Agilion GmbH 13

2 Agilion GmbH

Im zweiten Kapitel wird die Firma Agilion GmbH und deren WIRELESS LOCATION SYS-

TEM vorgestellt.

Vorstellung Agilion GmbH

Die Agilion GmbH ist ein mittelständiges Unternehmen mit Sitz in Chemnitz. 2004 aus

einem Automobilzulieferer gegründet hat sich das Unternehmen in seiner Kernkompetenz,

der drahtlosen Kommunikation und Echtzeit-Lokalisierung, zu einer marktführenden Grö-

ße entwickelt. Der Leistungsumfang der Agilion GmbH umfasst dabei nicht nur die Pla-

nung und den Aufbau von Infrastrukturen zur drahtlosen Kommunikation, sondern auch

die Auswahl geeigneter Funktechnologien. Dabei verfolgt das Unternehmen das Kanban-

Prinzip „Alles aus einer Hand.“ Auf diese Weise ist es möglich Applikationen und Geräte

in Automotivequalität anzubieten.

Das WIRELESS LOCATION SYSTEM

Das WIRELESS LOCATION SYSTEM (WLS) ist die Basistechnologie der Agilion GmbH

und ein ganzheitliches Lösungskonzept zur Echtzeit-Lokalisierung. Das System umfasst

sowohl die Infrastruktur (Gesamtheit aller Hardwaregeräte) als auch die Software in einer

Server-Client-Architektur. Zentrales Element stellt dabei der Lokalisierungsserver dar. Die

einzelnen Komponenten werden in den nächsten Punkten erläutert. Die folgende System-

beschreibung ist der Homepage der Agilion GmbH entnommen (vgl. Agilion GmbH 2014).

14 Agilion GmbH

2.2.1 Systemarchitektur

Abbildung 1 Systemarchitektur WLS

Das WIRELESS LOCATION SYSTEM kann in einer bestehenden IT-Infrastruktur betrie-

ben und gemanagt werden.

Ein zentrales Ereignismanagement kann, je nach Projektanforderungen, Systemzustände

überwachen und signalisieren sowie eine hohe Verfügbarkeit gewährleisten.

2.2.2 Mobile Tags

Die mobilen Tags werden im Netzwerk lokalisiert. Sie können sowohl von Personen ge-

tragen als auch an Fahrzeugen oder Geräten angebracht werden. Weiterhin ist eine Über-

tragung anwendungsspezifischer Daten von und zu den mobilen Tags möglich.

Abbildung 2 Mobile TAG

Agilion GmbH 15

2.2.3 Ankerknoten

Die Ankerknoten besitzen eine feste Position im Lokalisierungsnetzwerk. Sie fungieren als

Referenzpunkte zur Lokalisierung und ermöglichen die Weiterleitung von Positionsdaten.

Abbildung 3 Ankerknoten

2.2.4 Gateway

Gateways fungieren wie Ankerknoten, besitzen aber zusätzlich eine Schnittstelle zur An-

bindung an eine IT-Infrastruktur. Über diese IT-Infrastruktur werden die Daten zur Lokali-

sierung als auch optional applikationsspezifische Daten zwischen dem drahtlosen Lokali-

sierungsnetzwerk und dem Lokalisierungsserver ausgetauscht.

Abbildung 4 Gateway

16 Agilion GmbH

2.2.5 Lokalisierungsserver

Die Positionsbestimmung der mobilen Tags erfolgt auf einem Lokalisierungsserver. Dieser

bietet optional zusätzliche Schnittstellen, um die Positionsdaten sowie alle weiteren an-

wendungsspezifischen Daten für die Visualisierung, Logistikapplikationen, Einsatzplanung

und weitere Anwendungen verfügbar zu machen. Datenbanken wie SQL-Server, CSV und

TCP/IP werden unterstützt.

2.2.6 Visualisierung, Management und Administration

Die Anzeige der Positionsdaten und applikationsspezifischer Daten der mobilen Tags er-

folgt mit Agilion Visualisierung. Grundlage dafür sind Bilder von Grundrissen, von Grund-

stücksplänen, von 2D/3D-Modellen (CAD, VRML,...) sowie Satellitenbilder. Optional kön-

nen auf Basis der Visualisierung durch den Nutzer auch anwendungsspezifische Informa-

tionen zu den mobilen Tags übertragen werden. Managementtools unterstützen die Ad-

ministration des Systems.

Grundlagen zur Softwareentwicklung 17

3 Grundlagen zur Softwareentwicklung

In diesem Kapitel werden die Softwaretechnologien, die in diesem Projekt verwendet wer-

den vorgestellt. Die Verwendung dieser Technologien ergab sich unter anderem aus den

Vorgaben der Geschäftsleitung als Basistechnologie ASP.NET zu verwenden. Darüber

hinaus mussten Folgeentscheidungen über ergänzende Softwaretechnologien getroffen

werden. Das Gesamtsoftwarepaket soll in diesem Kapitel kurz vorgestellt werden.

Das Zusammenspiel der Softwarekomponenten wird im Abschnitt „Softwarearchitektur“

erläutert.

ASP.NET

ASP.NET ist die am zweithäufigsten verwendete serverseitige Programmiersprache. Sie

basiert auf dem von Microsoft entwickelten .NET-Framework und ist der Nachfolger der

Active Server Pages (ASP).

3.1.1 ASP.NET MVC

Das ASP.NET MVC Framework in der Version 5 ist die neueste Entwicklung aus der

ASP.NET-Familie. Es unterstützt nicht nur die häufig verwendete Model-View-Control

Architektur, darüber hinaus ist es ohne weiteres durch externe Frameworks wie zum Bei-

spiel jQuery erweiterbar. Auf diese Weise ist es dem Entwickler möglich sowohl auf die

serverseitigen Funktionen des ASP.NET zuzugreifen, als auch auf clientseitige Techniken

des JavaScript, um unter anderem die Benutzerfreundlichkeit zu steigern.

MVC steht für Model-View-Control und ist ein Architekturmodell, welches die Trennung

von Programmlogik und Präsentation ermöglicht.

18 Grundlagen zur Softwareentwicklung

Abbildung 5 Das MVC-Muster

(Steyer und Schwichtenberg 2014, S. 16)

Das Prinzip der Umsetzung des MVC-Models im ASP.Net Framework ist die Zuordnung

eines Controllers zu einer View. Jeder Controller erbt Methoden der Klasse „Controller“,

die auf HTTP-Anforderungen an eine ASP.NET MVC-Webseite reagieren.

3.1.2 ASP.NET Web API

„Bei ASP.NET Web API handelt es sich um ein sehr leichtgewichtiges Framework zur

Entwicklung HTTP-basierter Services“ (Steyer und Schwichtenberg 2014, S. 69).

Im Gegensatz zu ASP.NET MVC erben die Controller der Web API von der Klasse Api-

Controller. Diese Klasse stellt die Methoden GET, POST, PUT und DELETE zur Verfü-

gung.

jQuery

„jQuery ist eine JavaScript Bibliothek, die Methoden zur DOM-Navigation und Manipulati-

on, Event-Handling, Animationen und Ajax mittels API einfach verfügbar macht” (jQuery

Foundation - jquery.org 2014).

JQuery wird in dieser Arbeit vor allem zur DOM-Manipulation verwendet.

Grundlagen zur Softwareentwicklung 19

REST

Der Begriff REST steht für Representational State Transfer und hat seinen Ursprung in

der Doktorarbeit von Roy Fielding. Die Idee dahinter ist die Implementierung eines Archi-

tekturstils, der jeder Ressource einen URL zuweist.

Beispiel eines REST-URL:

http://.../controller/methode/parameter

Vier Grundlegende Funktionen werden dabei abgebildet: GET, POST, PUT und DELETE.

GET kommt zum Einsatz, wenn Daten abgerufen werden sollen. Die angeforderten Daten

können XML- oder JSON-serialisiert gesendet werden. Weitere Formate werden grund-

sätzlich unterstützt, bedürfen aber zusätzlicher Konfiguration.

POST wird verwendet, um Ressourcen auf einem Server zu erzeugen, PUT, um Res-

sourcen zu aktualisieren und DELETE zum Löschen von Daten auf einem Server.

Anforderungsanalyse 21

4 Anforderungsanalyse

„Requirements Engineering (RE) ist das disziplinierte und systematische Vorgehen zur

Ermittlung, Dokumentation, Analyse, Prüfung, Abstimmung und Verwaltung von Anforde-

rungen unter kundenorientierten, technischen und wirtschaftlichen Vorgaben“ (Ebert 2012,

S. 35).

Abbildung 6 Aktivitäten des RE

(Ebert 2012, S. 35)

Dieses Kapitel behandelt die Schritte der Anforderungsanalyse zur Erstellung des CMT.

Als Grundlage dient ein Fragebogen, der von verschiedenen Mitarbeitern ausgefüllt wur-

de, die mit dem späteren Produkt arbeiten sollen. Der zugrundeliegende Fragebogen

kann in den Anlagen „Checkliste der Anforderungsanalyse“ nachgelesen werden.


Ausgangssituation und Vorgaben

Der Anlass zur Durchführung dieses Projekts ist die fehlende Automatisierung, die sich im

Prozess der Inbetriebnahme und Wartung des WLS darstellt. Diese werden im Abschnitt

„Inbetriebnahme und Wartung des WIRELESS LOCATION SYSTEM“ detailliert beschrie-

ben.

4.1.1 Stakeholder und Interessengruppen

Die Wartungssoftware soll zunächst als firmeninternes Tool zur Inbetriebnahme, Pflege

und Wartung des WLS eingesetzt werden. Aus diesem Kontext ergeben sich keine fir-

menexternen Kunden, sowie vertragliche Verpflichtung oder gesetzliche Regelungen, die

während des Projektes eingehalten werden müssen. Dennoch können verschiedene Inte-

ressengruppen identifiziert werden, die in folgender Tabelle aufgelistet sind.

Bezeichnung der Interessengruppe Perspektive

Geschäftsleitung Geschäftsleitung

Leiter Inbetriebnahme Auftraggeber, Nutzer

Leiter Softwareentwicklung Entwicklung

Mitarbeiter Inbetriebnahme Nutzer

Projektmanager Nutzer

Integratoren Nutzer

Tabelle 1 Auflistung Stakeholder

Das Interesse der Geschäftsleitung ergibt sich aus dem möglicher Weise späteren Beitrag

des Tools zum wirtschaftlichen Erfolg des WLS. Aus diesem Grund muss die Geschäfts-

leitung bereits an der Entwicklung partizipieren.


Der Leiter der Inbetriebnahme hat zwei Perspektiven auf das Projekt. Zum einen ist er der

Auftraggeber, da seine Abteilung mit der Inbetriebnahme und Wartung des WLS beauf-

tragt ist, zum anderen ist er – in seiner Aufgabe als Projektleiter – auch Nutzer des Pro-

duktes.

Die zukünftige Architektur des WLS soll auf lange Sicht umgestellt werden. Eine Option

dabei ist, eine webbasierte Struktur einzuführen. Aus diesem Grund stellt das Projekt

CMT ein Pilotprojekt dar, woraus sich das Interesse des Leiters der Softwareentwicklung

begründet.

Die Mitarbeiter der Inbetriebnahme und die Projektleiter nehmen die Perspektive der Nut-

zer ein, da sie das Tool in ihrem Tagesgeschäft verwenden werden.

4.1.2 System und Systemumgebung

Die beiden Hauptaufgaben – Inbetriebnahme und Wartung – können verschiedenen Pro-

zessen in der Einführung und Anwendung des WLS zugeordnet werden. Die Software soll

in der Lage sein diese Prozesse abzubilden und funktional zu unterstützen.

Als Kernaufgabe kann die Diagnose beziehungsweise die Überwachung des WLS identi-

fiziert werden. Eine Unterteilung der Funktionalitäten des Condition Monitoring Tools

muss sich an der logischen Einteilung der Prozessschritte der Arbeit mit dem WLS orien-

tieren.

Abbildung 7 Prozessüberblick


Wie in der Grafik erkennbar kann der Arbeitsablauf grob in die drei Prozesse Projektie-

rung, Inbetriebnahme und Pflege eingeteilt werden. Jedem dieser Prozesse sind Arbeits-

schritte mit entsprechend einzustellenden Parametern zugeordnet. Das System muss in

der Lage sein sowohl die Prozesse mit ihren, teilweise überschneidenden Arbeitsschrit-

ten, als auch die unterschiedlichen Parameter zu überwachen und systematisch darzu-

stellen.

Aus diesem Kontext ergibt sich das organisatorische Umfeld der Software zu dem, neben

dem Endnutzer (Nutzer des WLS) und den Mitarbeitern der Inbetriebnahme, auch die

Projektleiter eines WLS Projektes gehören.

Die Software des WLS wird derzeit auf Basis der Betriebssysteme von Microsoft betrie-

ben.

Die Datenhaltung wird mittels einer Oracle oder Microsoft SQL Datenbank realisiert. Das

CMT soll mit diesen Rahmenbedingungen fehlerfrei zusammenarbeiten. Bei der Visuali-

sierung soll es jedoch flexibel und möglichst plattformunabhängig sein.

Als Prototyp soll das CMT Informationen aus der Datenbank des WLS beziehen, diese

verarbeiten und grafisch so darstellen, dass der Zustand schnell vom Nutzer zu erfassen

ist. Eine Schnittstelle zum WLS für den Abruf von Livedaten ist zwar technisch möglich

zurzeit aber noch nicht implementiert. Aus diesem Grund wird diese Option im CMT nicht

berücksichtigt, soll aber möglichst einfach zu einem späteren Zeitpunkt nachgepflegt wer-

den können.

4.1.3 Inbetriebnahme und Wartung des WIRELESS LOCATION SYS-TEM

Die zwei Hauptaufgabengebiete, bei dem das Condition Monitoring Tool unterstützen soll,

sind die Inbetriebnahme und die Wartung des WLS. Im Folgenden werden die einzelnen

Prozesse in ihrem derzeitigen Zustand dargestellt und gezeigt, wie das CMT zur Prozess-

verbesserung beitragen kann. Auf den Funktionsumfang und die Funktionsweise wird im

Verlauf dieser Arbeit genauer eingegangen.

4.1.3.1 Inbetriebnahme

Unter Inbetriebnahme wird der einmalige Vorgang des Aufbaus der Infrastruktur und der

Installation sowie Konfiguration der Softwarekomponenten verstanden. Am Ende einer


Inbetriebnahme steht ein voll funktionsfähiges Ortungssystem. Als Überblick über den

derzeitigen Stand dient die folgende Grafik.

Ist-Zustand

Abbildung 8 Inbetriebnahme WLS Ist-Zustand


Wie zu erkennen ist liegt der Hauptbestandteil der Arbeit im Prozess der Inbetriebnahme

in zahlreichen Konfigurationen sowohl bei der Installation, als auch bei den Teilschritten

Netzwerk- und Ortungskonfiguration. Diese Einstellungen werden derzeit schrittweise

manuell geprüft, dabei sind zum Teil komplexe Datenbankabfragen nötig.

Um das grundlegende Problem darzustellen ist in Abbildung 10 der Prozess der Netz-

werkkonfiguration in vereinfachter Form dargestellt. Dennoch ist zu erkennen, dass es

sich um einen komplexen Vorgang handelt. Der rotmarkierte Bereich ist dabei besonders

kritisch zu betrachten. Während dieses Vorgangs werden die Konfigurationsparameter auf

Fehleingaben oder Inkonsistenzen überprüft. Eine maschinelle Unterstützung existiert

zurzeit nicht. Das bedeutet, dass ein fehlerfreier Abschluss und die uneingeschränkte

Funktion des Ortungssystems von der Erfahrung des Mitarbeiters der Inbetriebnahme

abhängig sind. Im gleichen Maße verhält es sich bei der Ortungskonfiguration, welche als

Detailgrafik der „Anlage Inbetriebnahme eines WLS“ zu finden ist.

Ein weiterer, nicht zu vernachlässigender Aspekt, ist die Einarbeitungszeit eines neuen

Mitarbeiters in die Prozesse und Einzelschritte einer Inbetriebnahme. Diese verringert sich

bei zunehmender Automatisierung. So könnte nicht nur die Qualität der Inbetriebnahme,

sondern auch die Effizienz der Einarbeitung gesteigert werden.


Abbildung 9 Netzwerkkonfiguration eines WLS


Soll-Zustand

Mit Hilfe eines Condition Monitoring Tools kann die Systemprüfung strukturiert und auto-

matisiert werden. Auf diese Weise wird sichergestellt, dass alle zu prüfenden Parameter

berücksichtigt werden. Die folgende Prozesskette zeigt im Detail, wie eine solche automa-

tisierte Prüfung ablaufen soll.

Diese Arbeit soll den bestehenden Workflow nicht ändern, sondern die Software muss so

flexibel erstellt werden, dass sie zu jedem Zeitpunkt den Anwender unterstützt ohne die

Prozessschritte signifikant zu verändern.

Abbildung 10 Ablauf der automatischen Zustandsüberwachung

Die Integration des CMT in den Gesamtprozess könnte, wie in der folgenden Grafik dar-

gestellt, umgesetzt werden.


Abbildung 11 Inbetriebnahme WLS Soll-Zustand


4.1.3.2 Durch externe Fehlermeldung ausgelöste Wartung

Das zweite Anwendungsszenario für das Condition Monitoring Tool ist die Wartung des

WLS. Hier liegt das größte Potential zur Optimierung des Prozessablaufs. Begründet ist

dies in dem derzeitigen Ablauf, da viele verschiedene Client- und Datenbank-Tools ver-

wendet werden müssen. Die Einschränkung auf ein einziges Werkzeug ergibt somit eine

Verkürzung des Prozesses und damit der Zeit, die benötigt wird, eine Anomalie im Sys-

tem zu finden. Folgend wird der Wartungsprozess nach Eingang einer Fehlermeldung in

seinem Ist- und Soll-Zustand beschrieben.

Ist-Zustand

Abbildung 12 Wartung WLS mit Fehlermeldung Ist-Zustand


Der Prozess der Fehlersuche unterteilt sich in der Regel in drei Hauptschritte: Fehlerana-

lyse, manuellen Fehlersuche und Fehlerbehebung.

Im ersten Schritt wird zunächst eine mögliche Fehlerursache ermittelt. Da sich unter-

schiedliche Ursachen in ähnlichen „Symptomen“ zeigen ist dieser Schritt stark abhängig

von der Erfahrung des Mitarbeiters. Ist eine mögliche Fehlerursache bestimmt worden

muss diese durch verschiedene Untersuchungen bestätigt werden. Diese manuelle

Fehlerursache ist in groben Zügen standardisiert.

Zunächst wird der benötigte WLS-Client gestartet. Kann mit diesem die Fehlerquelle ge-

funden werden, wird sie mit dem entsprechenden Werkzeug behoben. Falls kein Fehler

gefunden wird muss entweder ein anderer Client genutzt oder die Datenbank mittels eines

Datenbank-Management-Tools manuell untersucht werden. Kann nach diesen Schritten

dennoch kein Fehler gefunden werden muss erneut festgestellt werden, ob die Fehlerur-

sache beim WLS liegt.

Die Dauer und der Erfolg dieses gesamten Prozesses hängen von der Erfahrung des Mit-

arbeiters ab.

Soll-Zustand

Durch das CMT soll eine proaktive Fehlerbehandlung ermöglicht werden wodurch das

Szenario, auf externe Fehlermeldung reagieren zu müssen, eliminiert werden soll.

4.1.3.3 Periodische Wartung ohne externe Fehlermeldung

Ein weiterer wichtiger Anwendungsfall für das CMT ist die periodische Wartung des WLS.

Ist-Zustand

Derzeit existiert keine standardisierte Vorgehensweise für die Wartung des Systems. Das

bedeutet, dass auf die Schritte der manuellen Fehlersuche zurückgegriffen werden muss.

Teilweise werden SQL-Queries verwendet, welche jedoch auf bestimmte Projekte – bei

dem das WLS zum Einsatz kommt – abgestimmt und somit nicht universell einsetzbar

sind. Eine effiziente Systemwartung ist aus diesem Grund nur bedingt möglich.

Soll-Zustand

Mit der Einführung des CMT soll den Mitarbeitern nicht nur ein Werkzeug geliefert, son-

dern auch ein Standard definiert werden mit dem das WLS zu warten ist. Dabei kann der


schematische Ablauf aus Abbildung 10 angewendet werden. Zudem zeigt dies, wie flexi-

bel ein solches Tool eingesetzt werden kann.

Eine spezifische und detaillierte Prozessmodellierung würde den Rahmen dieser Arbeit

überschreiten und ist somit kein Bestandteil.

4.1.4 Einbettung in die Umgebung

In diesem Teil werden die verschiedenen Schnittstellen des Produktes zu seiner Umge-

bung identifiziert und grob beschrieben.

4.1.4.1 Integration in das WLS

Das WLS ist ein bewährtes und voll ausgereiftes Softwaresystem, es basiert auf einer

Server-Client-Architektur.

Das CMT soll seine Funktionalität nicht als neuer Client oder seine Funktionen innerhalb

eines existierenden Clients anbieten, sondern als selbstständige Softwarelösung entwi-

ckelt werden. Wie bereits erwähnt gibt es die Vision, das WLS auf eine neue webbasierte

Basistechnologie zu portieren beziehungsweise umzustellen. In dieser neuen Umgebung

soll das CMT in jeder Instanz voll integriert sein.

Das WLS, beziehungsweise dessen Datenbank, wird über eine Schnittstelle an das CMT

angebunden, um die Kommunikation zwischen WLS und CMT zu gewährleisten. Auf die-

se Weise wird das Condition Monitoring Tool logischer Bestandteil des WLS.

Ein Dokumentationstool, welches während des Praktikums von Sebastian Naumann für

die Agilion GmbH entstand und in dem entsprechenden Praktikumsbericht beschrieben

wurde, soll in die Lösung integriert werden. (Naumann 2014)

4.1.4.2 Schnittstellen

Zwei Schnittstellen ergeben sich aus der Umgebung für das CMT, die im Nachfolgenden

beschrieben werden.

Mensch-Maschine-Schnittstelle

Die zukünftigen Nutzer der Software sind erfahrene PC-Anwender und geübt mit der Ver-

wendung verschiedenster Software. Da es sich bei dem WIRELESS LOCATION SYSTEM

jedoch um ein sehr umfangreiches Softwarepaket aus verschiedenen Clients und Tools


mit unterschiedlichsten Funktionen handelt, soll eine Lösung gefunden werden, um dieses

Paket nicht noch mehr zu überladen. Aus diesem Grund soll das CMT als Webanwen-

dung realisiert werden. Das daraus resultierende Webinterface soll die Schnittstelle zwi-

schen Nutzer und Software darstellen. So kann eine einfache, übersichtliche und vor al-

lem leicht erlernbare Nutzung garantiert werden.

CMT-WLS-Schnittstelle

Diese Schnittstelle stellt sicher, dass die Informationen, die vom Nutzer gewünscht wer-

den, aus dem WLS abgerufen werden können. Als Datenquelle dient der Datenbankser-

ver, welcher mit dem WLS verbunden ist. Die Software soll nur über einen lesenden Zu-

griff auf die Datenbank verfügen.

Abbildung 13 Schematische Darstellung der Schnittstellen

Funktionale Anforderungen

Folgende funktionale Anforderungen wurden sowohl durch verschiedene Workshops er-

arbeitet, als auch teilweise von der Geschäftsleitung vorgegeben.


4.2.1 Unterstützte Geschäftsprozesse

Die von der Software unterstützten Geschäftsprozesse ergeben sich aus den Teilprozes-

sen eines WLS-Projektes. Konkret bedeutet das die Unterstützung der Einführung des

WIRELESS LOCATION SYSTEMS bei einem Kunden und, im Anschluss eines erfolgrei-

chen Projektes, die Wartung beziehungsweise die Instandhaltung des WLS.

Der Aufbau und Ablauf eines Projektes bei der Agilion GmbH wird in der Bachelorarbeit

„Betriebswirtschaftliche, software- und informationstechnische Konzeption einer Schnitt-

stelle für den Datenaustausch zwischen SAP Business One und aXc-Project“ von Herrn

Leonid Drost detailliert beschrieben (Drost 2014).


4.2.2 Funktionale Anforderungen als Product Backlog

Aus den Umfragebögen und den Ergebnissen verschiedener Workshops wurde ein Pro-

duct Backlog zusammengestellt, welches die Anforderungen an die Software beinhaltet.

Dieses Backlog wurde zu Gunsten der Zusammenarbeit mit anderen Beteiligten und der

einfachen Verarbeitbarkeit in Microsoft Excel erstellt. Dies hat den Vorteil, dass die Ein-

träge leicht editierbar und sortierbar sind. Die rotmarkierten User Stories sind Sicherheits-

anforderungen und somit ihrem Charakter nach nicht funktionale Anforderungen. Aus die-

sem Grund werden sie in einem späteren Teilabschnitt genauer beschrieben.

Die Priorisierung orientiert sich an einer Skala von Eins bis Fünf, wobei Eins die Niedrigs-

te und Fünf die höchste Priorität repräsentiert.

Story ID

Priorität User Story

Must Have

1 5 Als Nutzer möchte ich mittels Menü auf jede Seite navigieren können.

2 4 Als Server möchte ich Daten verschlüsselt übertragen

3 3 Als Nutzer möchte ich mich mit meinem gültigen WLS Konto authentifi-zieren

4 4 Als Server möchte ich mich gegenüber dem Client authentifizieren

5 5 Als Nutzer möchte ich mich einloggen können.

6 2 Als Nutzer möchte ich mich ausloggen können.

7 3 Als Nutzer möchte, dass Prüfkriterien tabellarisch angezeigt werden

8 2 Als Nutzer möchte ich Tabellen filtern und sortieren können

9 5 Als Softwaresystem möchte ich Fehler mehrstufig bewerten können

10 4 Als Softwaresystem möchte ich Prüfkriterien kategorisieren

11 5 Als Nutzer möchte ich Fehler eindeutig in Schwere dargestellt haben

12 5 Als Softwaresystem möchte ich lesend auf die Datenbank des WLS zugreifen

13 3 Als Nutzer möchte ich zu jedem Fehler eine Detailansicht

14 4 Als Nutzer möchte ich das Tool flexibel anpassen können

15 2 Für spätere Versionen soll das Tool Nutzer mit verschiedenen Rollen unterstützen

Should Have

16 1 Als Nutzer möchte ich einen Report erstellen können

17 1 Als Softwaresystem möchte ich bei kritischen Fehlern soll eine E-Mail versenden

Tabelle 2 Product Backlog


4.2.2.1 User Stories

Exemplarisch sind in diesem Abschnitt zwei User Stories aufgeführt.

User Story Titel: Als Nutzer möchte ich mittels Menü auf jede Seite navigie-

ren können.

User Story ID: 1

Szenario: Als Nutzer möchte ich über ein Navigationsmenü verfügen, um

übersichtlich und einfach zwischen verschiedenen Ansichten zu

wechseln.

Akzeptanzkriterium1: Vorausgesetzt der Nutzer ist eingeloggt,

Wenn der Nutzer auf einen Navigationsbutton klickt,

Dann soll die entsprechende View geöffnet werden, das Navigati-

onsmenü soll weiterhin verfügbar sein.

Akzeptanzkriterium2: Vorausgesetzt der Nutzer ist nicht eingeloggt,

Wenn der Nutzer auf einen Navigationsbutton klickt,

Dann soll keine View geöffnet werden.

User Story Titel: Als Nutzer möchte ich mich ausloggen können.

User Story ID: 6

Szenario: Als Nutzer möchte ich mich mittels Klick auf einen Button ausloggen

können.

Akzeptanzkriterium: Vorausgesetzt der Nutzer ist eingeloggt,

Wenn der Nutzer auf einen „Ausloggen“-Button klickt,

Dann soll die Session des Nutzers beendet werden,

Und die Login-View soll sich öffnen

Und der Nutzer soll keine Navigationsmöglichkeit mehr haben.


4.2.3 Übersicht aller Anwendungsfälle

Abbildung 14 Gesamtübersicht Use Cases

4.2.4 Ausgearbeitete Anwendungsfälle

Für die Beschreibung der Use Cases wird eine Schablone verwendet, welche sich an den

Empfehlungen von Alistair Cockburn orientieren (Cockburn 2008).

Name

Anwendungsfälle haben einen eindeutigen Namen und können über diesen

identifiziert werden.

Akteur

Akteure sind beteiligte Personen oder Systeme, die nicht Bestandteil des

beschriebenen Systems sind. Beispielsweise können das Nutzer, Administratoren

oder externe Software sein.

Trigger

Der Trigger ist das auslösende Ereignis.


Kurzbeschreibung

Die Kurzbeschreibung umreißt den Ablauf und den Inhalt des Anwendungsfalls in

maximal drei Sätzen.

Vorbedingung

Bedingungen, welche erfüllt sein müssen, damit der Anwendungsfall ausgelöst

werden kann.

Essenzielle Schritte

Iterative Beschreibung und Nummerierung der Einzelschritte des Prozesses inner-

halb des Use Cases.

Ausnahmefälle

Die Ausnahmefälle stehen für die nicht beeinflussbaren aber möglichen Einfluss-

faktoren, die ein Scheitern des Use Cases hervorrufen können.

Nachbedingung

Welchen Zustand oder Bedingungen das System nach dem erfolgreichen

Ablauf des Use Cases haben soll wird in diesem Abschnitt beschrieben.

Zeitverhalten

Falls der Anwendungsfall innerhalb eines gewissen zeitlichen Rahmens ablaufen

soll, so wird dieser hier festgelegt.

Alternativen

Falls neben dem Standardablauf noch alternative Abläufe existieren, dann werden

diese unter diesem Punkt eindeutig nummeriert und beschrieben. Die Alternativen

müssen nicht denselben Endzustand erreichen wie der Standardablauf.

Exemplarisch soll in diesem Abschnitt der Anwendungsfall „Kategorie Tags überprüfen“

beschrieben werden.

Name Kategorie Tags überprüfen

Akteur Nutzer

Trigger Nutzer betätigt Button „Tags“

Kurzbeschreibung Der Nutzer kann den Zustand der Kategorie Tags über einen

Menübutton auswählen. Dadurch wird eine Ansicht geöffnet

und die der Kategorie zugehörigen Daten grafisch dargestellt.

Vorbedingung Der Nutzer ist eingeloggt.


Essenzielle Schritte 1. Nutzer betätigt den Navigationsbutton „Tags“

2. System liest den Abschnitt Tags der Konfigurationsda-

tei ein

3. System baut Datenbankverbindung auf

4. System wertet die Daten gemäß der Konfigurationsda-

tei aus

5. System sendet Daten serialisiert an den Client

6. Client stellt Daten in einer View grafisch dar

Ausnahmefälle Webserver ist nicht erreichbar

Nachbedingung Die ausgewerteten Daten liegen im Cache des Systems

Zeitverhalten Der Aufbau der View sollte 50 ms nicht überschreiten

Alternativen 2.a) Liegen die Daten bereits im Cache, entfallen die Punkte

zwei bis vier

4.2.5 Fachliches Datenmodell

Das Condition Monitoring Tool soll seine Daten nicht in einer eigenen Datenbank verwal-

ten, sondern bei Bedarf, Daten aus der Datenbank des WLS abrufen. Dennoch muss die

Software über einen Mechanismus verfügen Daten, die bereits verarbeitet wurden, ver-

walten zu können.

Die Herausforderung bei der Modellierung eines geeigneten Modells liegt in der Dynamik

der zu verwaltenden Daten. Beispielsweise können bei der Analyse des WLS Daten aus

verschiedenen Tabellen der Datenbank zugrunde liegen. Die Daten aus verschiedenen

Tabellen unterscheiden sich sowohl in Inhalt als auch in ihren Datentypen. Folglich muss

ein Modell entwickelt werden, welches alle Möglichkeiten abdeckt.

Da es sich bei dieser Arbeit um ein Ein-Mann-Projekt handelt wurde bei der Erstellung

des Datenmodells das KISS-Prinzip aus dem Marketing angewendet. KISS ist ein Akro-

nym und steht für „Keep it small and simple.“

Zwei Entitäten sollen das fachliche Datenmodell repräsentieren. Zum einen handelt es

sich dabei um die Daten, welche aus der Datenbank abgegriffen werden. Diese werden

zu folgenden Modell abstrahiert:


Abbildung 15 Das Datenmodell Element

Diese Klasse wird immer dann verwendet, wenn es gilt Ergebnisse aus Datenbankabfra-

gen auf das CMT zu mappen. Sie verfügt nur über zwei Attribute (key und value, beides

vom Typ String). Das Attribut key wird verwendet, um das Element eindeutig zu identifizie-

ren. Value ist der eigentliche Inhalt der Klasse. Die Entscheidung für beide Attribute den

Datentyp String zu wählen hat den Grund, dass alle Ergebnisse aus einer Datenbankab-

frage als String vorliegen. Eine Konvertierung in andere Datentypen wäre einfach möglich,

würde aber die Anzahl der Containerklassen erhöhen.

Das zweite Datenmodell stellt sich folgendermaßen dar:

Abbildung 16 Das Datenmodell Failure

Dieses Modell verfügt über vier Attribute vom Typ String und wird für die Verwaltung der

Ergebnisse der Prüfungen des WLS in Anspruch genommen. Das Attribut „key“ wird für

die Bezeichnung des Tests angewendet. „Amount“ soll dazu verwendet werden die An-

zahl der Fehler eines Tests speichern zu können. Auch vom Nutzer definierte Meldungen

müssen verwaltet werden, dies geschieht unter der Verwendung des Attributs „message.“

Das Attribut „status“ gibt Auskunft über den Schweregrad der Meldung.

Unmittelbare Beziehungen zwischen diesen beiden Modellen soll es nicht geben.


Nicht-Funktionale Anforderungen

In den folgenden Kategorien werden die Nicht-Funktionalen Anforderungen beschrieben.

4.3.1 Anforderungen an die Sicherheit

Ein wichtiger Aspekt bei der Erstellung der Software soll die Sicherheit sein. Dies umfasst

einerseits die Sicherheit der Daten, andererseits die Authentizität sowohl des Servers, als

auch des Nutzers. Aus diesem Grund sind folgende drei Punkte umzusetzen:

4.3.1.1 Datensicherheit

Die Kommunikation des Webinterfaces (Benutzerschnittstelle) mit dem funktionalen Kern

des CMT soll nicht über HTTP stattfinden, sondern über dessen sichere Variante, das

HTTPS. Die Verschlüsselung soll mit TLS (besser bekannt unter der Vorgängerbezeich-

nung SSL) realisiert werden. Dies soll in dieser Arbeit durch den IIS realisiert werden.

4.3.1.2 Authentifizierung

Nutzerauthentifizierung

Um den Zugriff von unbefugten Nutzern auf sensible Daten zu verhindern muss das CMT

über einen Mechanismus der Nutzerauthentifizierung verfügen. Dabei soll auf die Nutzer-

konten des WLS zurückgegriffen werden. Das Anlegen und Verwalten von Nutzern sind

keine Anforderungen an die Software, sondern werden weiterhin vom WLS gewährleistet.

Serverauthentifizierung

Serverseitig soll die Authentifizierung mittels Zertifikat realisiert werden, um sicherzuge-

hen, dass sich der Webclient auch mit dem richtigen Webserver verbindet.

4.3.1.3 Funktionssicherheit

SQL-Injections

Als SQL-Injections werden Angriffe auf eine Datenbank bezeichnet, bei denen der Angrei-

fer die Befehle eines Programms ändert oder erweitert, um so Datenbank-Kommandos

mit den Privilegien des Programms auszuführen. Die Schäden sind umso höher, je mehr

Privilegien das Programm besitzt. Bei Webanwendung ist der kritische Angriffspunkt die

Manipulation parametrisierter Datenbankabfragen über den URI. Um dies in der zu erstel-


lenden Software zu verhindern sollen keine parametrisierten Datenbankabfragen verwen-

det werden, so dass eine Manipulation der Query von unbefugten unmöglich ist.

Cross-Site Scripting

„Bei einem seitenübergreifenden Skriptangriff (Cross-Site-Scripting, abgekürzt XSS) ge-

lingt es dem Angreifer, eigenen Clientskriptcode im Kontext einer fremden Webanwen-

dung auszuführen. Dadurch kann der Angreifer z. B. Daten von Cookies »kapern«. Die

Gefahr besteht immer, wenn eine Webseite Benutzereingaben wieder ausgibt, ohne sie

auf enthaltenen Skriptcode zu prüfen. […]

In ASP.NET ist der seitenübergreifende Skriptangriff durch eine in ASP.NET Page

Framework integrierte Sicherheitsfunktion bereits entschärft. Page Framework bemerkt,

wenn ein Skript an eine Seite übergeben wird und verweigert dann die Abarbeitung des

Skripts“ (Schwichtenberg, 2014).

Um eine größere Sicherheit zu gewährleisten soll das Tool nicht als volle Webanwendung

dienen, das heißt, die Funktionen werden nicht im Internet, sondern nur im Intranet des

jeweiligen Kunden zur Verfügung gestellt.

4.3.2 Einführung des Systems

Das System soll zunächst firmenintern genutzt werden. Dazu soll es von verschiedenen

Mitarbeitern auf seine Nutzbarkeit geprüft werden. Im selben Zeitraum sollen die Funktio-

nen der Software komplettiert und erweitert werden. Ist die vollständige Produktreife er-

reicht muss ein Abnahmeprozess modelliert werden. Nach erfolgreicher firmeninterner

Abnahme der Software soll sie schrittweise in Produktivsysteme integriert werden. Ein

entsprechender Arbeitsablauf muss zu diesem Zeitpunkt ausgearbeitet werden.

4.3.3 Anforderungen an die Dokumentation

Für das Softwaresystem ist ein Benutzerhandbuch zu erstellen, welches jedoch nicht Be-

standteil der hier vorliegenden Arbeit ist.

4.3.4 Anforderungen an Betreuung und Betrieb

Die folgenden drei Punkte beschreiben die Anforderungen, die während des Betriebs und

der Betreuung der Software zu erfüllen sind.


4.3.4.1 Pflege der Software

Da die Datenbank des WLS regelmäßigen Anpassungen unterliegt und sich dabei auch

die Struktur verändern kann, muss sichergestellt werden, dass das CMT, welches auf

diese Ressourcen zugreift, im selben Maße angepasst wird. Darüber hinaus gibt es keine

weiteren Anforderungen an die Pflege.

Verantwortliche für die Pflege ist der Entwickler oder ein dafür berufener Programmierer.

4.3.4.2 Qualifikation des Personals

Nutzer, die Änderungen an der Software vornehmen müssen, welche keine Arbeit am

Quellcode bedürfen, brauchen Grundkenntnisse in der Textverarbeitung, speziell im For-

mat XML. Des Weiteren muss das Bedienpersonal befähigt sein, SQL-Queries eigenstän-

dig zu entwickeln und an das für das CMT erforderliche Format (siehe 5.3.2) anzupassen.

Um Änderungen am Quellcode vornehmen zu können sind Kenntnisse im Bereich Web-

technologie, speziell ASP.Net Web API und jQuery, nötig.

4.3.4.3 Konfigurationsmanagement

Als Erweiterung für die Software kann ein Konfigurationsmanagement integriert werden,

welches die als XML vorliegende Konfigurationsdatei ausliest und dem Nutzer als Formu-

lar in einer View visualisiert. Dies hat den Vorteil, dass die Eingaben auf Fehler überprüft

werden können ohne bereits Änderungen an der Konfigurationsdatei vorgenommen zu

haben. Eine Umsetzung dieser Funktionalität findet jedoch nicht im Rahmen dieser Arbeit

statt.

Kritischer Erfolgsfaktor

In diesem Projekt soll zunächst ein kritischer Erfolgsfaktor identifiziert werden und zwar

die Vereinfachung der Prozesse der Inbetriebnahme und der Wartung des WLS. Ziel ist

es nicht diese Prozesse optimal zu modellieren, sondern den Mitarbeitern und Nutzern ein

Werkzeug zur Verfügung zu stellen, welches eine bisher existierende Lücke füllt.

Die Prozessoptimierung liegt im Verantwortungsbereich der Projektleiter.

Dennoch müssen in diesem Punkt Einschränkungen gemacht werden, da es der zeitliche

Rahmen nicht zulässt ein Produkt mit vollständigem Funktionsumfang bereitzustellen. Der

Prototyp soll jedoch den zukünftigen Workflow vollständig unterstützen.

Konzeption 45

5 Konzeption

Um die Grundlagen für die Implementierungsphase zu schaffen, musste zunächst ein

Konzept für die Software geschaffen werden, die den Vorgaben aus Punkt 4 entsprechen

und sich auf eine theoretische Vorarbeit stützt.

Erstellung des Prüfkatalogs

Als Basis für die Ausarbeitung dient das Ergebnis eines Brainstormings, welches mit den

Stakeholdern des Projektes durchgeführt wurde. Die darin enthaltenen Stichpunkte sind

aufgearbeitet und in die, von der Geschäftsführung vorgegebenen, Kategorien eingeteilt

worden. Die Kategorien richten sich nach dem geplanten Workflow und unterteilen sich

wie folgt:

Projekt

Standort

Infrastruktur

Tags

Ortung

Wartung

Als erster Schritt wurden die einzelnen Punkte des Brainstormings den verschiedenen

Kategorien zugeordnet. Anschließend musste festgestellt werden, wie der Zugriff auf die

Rohdaten für eine Prüfung gewährleistet werden soll. Drei grundlegende Methoden ste-

hen theoretisch zur Verfügung:

1. Livedaten aus dem WLS

2. Datenbankabfrage

3. Daten aus dem Statistiktool

Jedem Prüfkriterium wurde eine Rohdatenquelle zugeordnet.

Der nächste logische Schritt war die Fehlerdefinition, das heißt, für jedes Prüfkriterium

musste eindeutig definiert werden wann und in welcher Abstufung ein Fehler zu generie-

ren ist.

46 Konzeption

Resultat war ein tabellarisch aufgebauter Katalog, der in vier Spalten unterteilt ist. Spalte

Eins dient als Bezeichnung für die Prüfung, in der Regel dient dazu der zu untersuchende

Parameter. Die zweite Spalte gibt an, wie der Parameter zu untersuchen ist beziehungs-

weise die Quelle der Rohdaten. Spalte Drei definiert, wann ein Fehler zu generieren ist.

Die letzte Spalte gibt vor, welche Unterteilung bei den Fehlern vorzunehmen ist. Dabei gilt

folgendes Muster:

Zweistufig:

Stufe eins Kein Fehler

Stufe zwei Fehler

Dreistufig:

Stufe eins Kein Fehler

Stufe zwei Warnung

Stufe drei Fehler

Konzeption 47

Prüfalgorithmen

Im Anschluss an die Erstellung des Prüfkatalogs wurden Algorithmen entwickelt mit denen

die Rohdaten ausgewertet werden sollen. Dazu mussten die Prüfungen auf ihren wesent-

lichen Kern reduziert werden Das Ergebnis waren vier einfache Algorithmen, welche aus-

reichen, um den gesamten Komplex des Prüfkatalogs abzudecken. Diese wurden wäh-

rend der Implementierungsphase im Quellcode umgesetzt. Aus Gründen der Übersicht

werden die Quellcodes in den nächsten vier Unterabschnitten mit dargestellt.

5.2.1 Überprüfung auf mehrheitliche Einstellung eines Parameters

Dieses Prüfverfahren wird beispielsweise bei der Überprüfung des Parameters „FEC“ an-

gewendet. Dazu wird zunächst festgestellt wie die Mehrheit der Geräte konfiguriert sind

(FEC an oder aus). Weicht ein Gerät von der Konfiguration der Mehrheit ab wird dies als

fehlerhaft konfiguriert registriert.

public List<ElementContainer> failureMajorityAnalysis(List<ElementContainer> list)

{

if (list.Select(elem => elem.value).GroupBy(elem2 => elem2).Count() > 1)

{

int i = list.Select(elem => elem.value).GroupBy(elem2 => elem2).Count();

var hilf = list.Select(elem2 => elem2.value).GroupBy(elem2 => elem2).ToArray();

int count = 0;

int countFailure = 0;

var value = "value";

for (int j = 0; j < i; j++)

{

if (count < list.Count(elem => elem.value.Equals(hilf[j].Key)))

{

count = list.Count(elem => elem.value.Equals(hilf[j].Key));

value = hilf[j].Key;

}

}

countFailure = list.Count(elem => !elem.value.Equals(value));

return list.Where(elem => !elem.value.Equals(value)).ToList<ElementContainer>();

}

return null;

}

Der Input der Methode ist eine Liste von Objekten der Klasse Element. Diese Liste wird

dahingehend gruppiert und überprüft, welche Konfiguration am häufigsten vorkommt. Die

Rückgabe dieser Methode entspricht einer Liste, die alle Elemente enthält, die nicht den

Vorgaben entspricht.

48 Konzeption

5.2.2 Überprüfung auf Durchschnitt

Bei dieser Überprüfung wird der Durchschnitt eines Parameters der zu prüfenden Geräte

ermittelt. Falls ein Gerät um eine festgelegte Toleranz (siehe Konfigurationsdatei „In-

nerTolerance“) von Durchschnittswert abweicht, wird dies als fehlerhaft konfiguriert regis-

triert.

public List<ElementContainer> failureAverageAnalysis(List<ElementContainer> list, int tolerance)

{

List<ElementContainer> failureList = new List<ElementContainer>();

var average = list.Average(elem => Convert.ToInt16(elem.value));

foreach (ElementContainer elem in list)

{

if ((Math.Max(Convert.ToInt16(elem.value), average) -

Math.Min(Convert.ToInt16(elem.value), average)) > tolerance)

{

failureList.Add(elem);

}

}

return failureList;

}

Diese Methode fordert zwei Parameter. Zum einen die Liste der zu prüfenden Elemente

und zum anderen eine Toleranz.

Zunächst wird ein Durchschnitt der Prüfwerte der Elemente gebildet. Im Anschluss wird

jedes einzelne Element mit dem gebildeten Durchschnitt verglichen. Alle Elemente, die

diesen um die angegebene Toleranz entweder über- oder unterschreiten, werden in einer

neuen Liste zusammengefasst und zurückgegeben.

5.2.3 Überprüfung auf einen Sollwert (int)

Bei dieser Methode wird der zu prüfende Parameter mit einem Sollwert verglichen. Weicht

der Parameter um eine festzulegende Toleranz ab, wird das Gerät als fehlerhaft konfigu-

riert registriert.

Konzeption 49

public List<ElementContainer> failureToleranceAnalysis(List<ElementContainer> list, int setpoint,

int tolerance)

{



{

if ((Math.Max(Convert.ToDouble(elem.value), setpoint) -

Math.Min(Convert.ToDouble(elem.value), setpoint)) > tolerance)

{


}

}

return failureList;

}

Diese Methode fordert drei Parameter. Parameter Eins ist die Liste der zu prüfenden Ele-

mente, Parameter Zwei der Sollwert und der letzte Parameter ist eine Toleranz.

Abgesehen davon, dass nicht auf den Durchschnitt sondern auf einen Sollwert geprüft

wird, funktioniert diese Methode prinzipiell wie die in Punkt 5.2.2 beschriebene.

5.2.4 Überprüfung auf einen Sollwert (String)

Bei diesem Algorithmus wird ein Parameter auf einen Sollwert überprüft, welcher als Da-

tenformat String vorliegt. Aus diesem Grund wird auch nicht mit Toleranzen gearbeitet.

Weicht eine Konfiguration ab, wird das Gerät als fehlerhaft konfiguriert registriert.

public List<ElementContainer> failureNotEqualAnalysis(List<ElementContainer> list, string setpoint)

{



{

if (!elem.value.Equals(setpoint))

{


}

}

return failureList;

}

Auch in dieser Methode werden die Elemente auf einen Sollwert geprüft, allerdings han-

delt es sich in diesem Fall um einen Parameter von Typ String.

50 Konzeption

Die Konfigurationsdatei

Ziel dieser Arbeit soll es, wie bereits erwähnt, sein, eine Software zu erstellen, die vom

Nutzer ohne große Aufwände um weitere Funktionen beziehungsweise Prüfmerkmale

erweitert werden kann. Der Lösungsansatz, welcher für das Projekt gewählt wurde, ist die

Software mit einer Konfigurationsdatei auszustatten, die unabhängig vom Quellcode be-

arbeitet werden kann und vom Programm dynamisch eingelesen wird.

5.3.1 Entwicklung der Konfiguration

Die zu entwickelnde Konfigurationsdatei muss einer genormten Struktur unterliegen, wel-

che zudem vom .Net Framework unterstützt wird. Als Basis dafür dient das XML Format.

Eine weitere Bedingung, die erfüllt werden muss, ist die Unterteilung in die verschiedenen

Kategorien des Prüfkatalogs. Der Inhalt der Konfigurationsdatei ergibt sich aus den Para-

metern der Prüfmethoden und der SQL-Query, welche die Rohdaten für die Prüfungen

liefert.

5.3.2 Aufbau der Konfigurationsdatei

Die Konfigurationsdatei wird im XML Format erstellt; das Wurzel-Element ist „configurati-

on.“ Die Bezeichnung der Kind-Elemente legt fest, zu welcher Kategorie das entspre-

chende Element gehört. Jedes Kind-Element kann beliebig oft wiederholt werden, so ist

es möglich jeder Kategorie mehrere Prüfkriterien zuzuordnen. Das bedeutet, ein Kind-

Element ist ein Prüfkriterium. Darüber hinaus verfügt jedes über folgende Attribute:

Description Wird zur Anzeige in der späteren View als Bezeichner verwendet

Type Legt fest, welche Prüfmethode angewendet werden soll

Query Datenbankabfrage, welche die zu prüfenden Elemente (Rohdaten)

liefert

Folgendes Format ist dabei anzuwenden:

SELECT [DISTINCT] Beschreibung, Prüfwert FROM Quelle [WHERE Where-Klausel]

Setpoint Sollwert

InnerTolerance Wird zur Bestimmung der fehlerhaften Konfiguration eines Gerätes

verwendet

OuterTolerance1 Schwellenwert für die Kategorisierung als Warnung

Konzeption 51

OuterTolerance2 Schwellenwert für die Kategorisierung als Fehler

Rohfassung einer Konfigurationsdatei:

<?xml version="1.0" encoding="utf-8" ?> <configuration> <project description=”” type=”” query=”” setpoint="" innerTolerance="" outerTolerance1="" outer Tolerance2="" message="”></project> <location description=”” type=”” query=”” setpoint="" innerTolerance="" outerTolerance1="" out-erTolerance2="" message="”></location> <tags description=”” type=”” query=”” setpoint="" innerTolerance="" outerTolerance1="" outerToler-ance2="" message="”></Tags> <infrastructure description=”” type=”” query=”” setpoint="" innerTolerance="" outerTolerance1="" outerTolerance2="" message="”></infrastructure> <localization description=”” type=”” query=”” setpoint="" innerTolerance="" outerTolerance1="" outerTolerance2="" message="”></localization> <maintenance description=”” type=”” query=”” setpoint="" innerTolerance="" outerTolerance1="" outerTolerance2="" message="”></maintenance> <configuration>

Systemarchitektur

Ausgehend von den funktionalen und nicht-funktionalen Anforderungen an das System

gibt es verschiedene Architekturalternativen.

Für die Entwicklung des Prototyps wurde zunächst die Variante „IIS-Gehostetes System

(Backend und Frontend)“ gewählt.

5.4.1 IIS-Gehostetes System (Backend und Frontend)

Diese Variante spezifiziert die Architekturskizze der Anforderungsanalyse und integriert

das Dokumentationstool als Frontend. Das Frontend hat dabei hybride Eigenschaften. Es

tritt gegenüber der Web API als Client und dem Browser gegenüber als Server auf. Die

Abbildung 17 zeigt den Aufbau des Gesamtsystems.

52 Konzeption

Abbildung 17 IIS-Gehostetes System mit Back- und Frontend

Vorteile dieser Architektur:

Bequeme Hostkonfiguration über GUI des IIS-Manager

- Einrichtung SSL

- Zertifikatauthentifizierung des Servers

- Verwaltung von Zertifikaten

Zugriff auf IIS Features (z.B.: Logging)

Weniger Konfigurationsaufwand der Software

Nachteile:

Zusätzliche Software (IIS-Server), die beim Kunden installiert werden muss

Zusätzliche Software (IIS-Server), die gewartet werden muss

Keine Kontrolle über Start der Services

Konzeption 53

5.4.2 IIS-Gehostetes System (All in One)

In einem späteren Entwicklungsschritt sollen die WEB API und das Dokumentationstool

zu einer logischen Einheit zusammengefasst werden. Dadurch entfällt der

Konfigurationsaufwand für zwei Softwaresysteme. Des weiteren ist eine Verringerung der

Datenauslastung im Netzwerk zu erwarten, da das Dokumentationstool als

Zwischensystem wegfällt.

Die Architektur stellt sich wie folgt dar.

Abbildung 18 IIS-Gehostetes System (All in One)

Für diese Architektur gelten prinzipiell die Vor- und Nachteile der Vorangegangenen. Dar-

über hinaus entfällt die Wartung für zwei Softwaresysteme, woraus sich ein zusätzlicher

Vorteil ergibt.

54 Konzeption

5.4.3 Selfhosting

Diese Alternative verzichtet auf den Einsatz eines Webservers. Hierfür wird die Fähigkeit

des Selfhostings des ASP.Net Web API genutzt.

Um dies zu gewährleisten soll eine Middleware, das Open Web Interface für .NET (O-

WIN), verwendet werden. Mit dessen Hilfe wird die Web-Anwendung vom Web-Server

entkoppelt. Diese Funktion kann mit der derzeitigen Technologie des ASP.Net-

Frameworks nur für die Web API umgesetzt werden. Um den vollständigen Funktionsum-

fang der Software im Selfhosting zu betreiben, muss entweder auf ein weiteres externes

Framework namens NancyFx zurückgegriffen oder die – noch in der Alpha-Testphase

befindliche – nächste Generation des ASP.Net Frameworks (ASP.Net vNext) genutzt

werden. Die nächste Generation des Frameworks vereint die Funktionen ASP.NET MVC,

Web API und Web Pages. Darüber hinaus ist der Entwickler frei in seiner Auswahl an

Hosting Szenarien, denn es wird sowohl IIS, Selfhost und plattformübergreifendes (MAC

OS oder Linux) Hosting unterstützt. Diese Technologie steht offiziell noch nicht zur Verfü-

gung, kann aber im Rahmen der Erprobung des Visual Studio CTP bereits getestet wer-

den.

Die Grundlegende Struktur wird beibehalten, wie in Abbildung 19 zu erkennen ist.

Vorteile dieser Architektur:

Volle Kontrolle über das Tool

Keine zusätzliche Installation eines IIS auf Kundenserver nötig

Nachteile:

Erhöhung des Konfigurationsaufwandes für das CMT, denn alle Funktionen, die

normalerweise vom IIS geliefert werden, müssen in der Anwendung implementiert

werden

Konzeption 55

Abbildung 19 Selfhosted Web API

Softwarearchitektur

Die Grundlegende Architektur soll den Charakter eines verteilten Systems haben, konkret

soll eine Client-Server-Architektur umgesetzt werden. In dieser Architektur hat der Client

die Möglichkeit Aufgaben vom Server erledigen zu lassen. Der Server hat die Funktion

Anfragen von Clients entgegenzunehmen, auszuführen und das Ergebnis an den Client

zurückzusenden.

Abbildung 20 Client-Server-Architektur

56 Konzeption

Das zu entwickelnde Softwaresystem (CMT) soll den Server repräsentieren, als Client

dient zukünftig ein beliebiger Browser.

5.5.1 Zusammenspiel der Softwaretechnologien

Die Basistechnologie für das CMT soll ASP.NET sein. Dieses wird durch das JavaScript

Framework jQuery ergänzt, um DOM-Manipulationen zu ermöglichen. JQuery wurde auf

Grund seiner einfachen Handhabung und guten Dokumentation gewählt. Darüber hinaus

wird jQuery durch das ASP.NET Framework voll unterstützt und lässt sich somit ohne

weiteres in die Softwareumgebung integrieren.

Die Kommunikation soll mittels REST über HTTP realisiert werden. Vergleichbare Proto-

kolle oder Services, wie SOAP oder WCF, wurden aufgrund ihrer Komplexität nicht aus-

gewählt. Der Funktionsumfang von REST erfüllt die Anforderungen an das System in vol-

lem Maße und ist zudem in der ASP.NET Web API bereits integriert.

Zur Serialisierung von Objekten wurde JSON gewählt, dies lässt sich auf die Entschei-

dung zur Verwendung von jQuery zurückführen.

Das Zusammenspiel lässt sich an folgendem Beispiel kurz erläutern.

Nachdem der Nutzer sich erfolgreich authentifiziert hat wird die Anwendung gestartet.

Durch das Anwählen des Navigationselementes Wartung wird folgender URL aufgerufen:

https://servername/api/maintenance. Der MaintenanceController (ASP.NET Web API)

reagiert auf diesen Aufruf und startet die dafür vorgesehenen Funktionen. Die Ergebnisse

der Prüfungen ergeben eine Liste, welche ins JSON-Format serialisiert und mittels ver-

schlüsseltem HTTP an den Client gesendet werden. Der String hat folgendes beispielhaf-

tes Format:

[{"key":"Tabellengröße","amount":"0","message":"Tabellengrößen überprüfen","status":"ok"}].

Dieser String wird von JavaScript Framework jQuery deserialisiert und die Fehlerliste auf

die Ansichtstabelle gemappt. Gleichzeitig wird auch das Steuerelement gemäß dem Sta-

tus der Fehler angepasst (siehe Anlage grafisches Design).

5.5.2 Der Server

Die Architektur des Servers soll gemäß dem MVC-Muster umgesetzt werden. Grundle-

gendes Element in dieser Struktur ist der Controller. Um die Wartbarkeit der Software zu

verbessern, gibt es für jede Prüfkategorie (Projekt, Standort, Infrastruktur, Tags, Ortung

und Wartung) einen separaten Controller. Die Controller sollen so eingeschränkt werden,

Konzeption 57

dass nur Daten abgerufen werden können. Das bedeutet sie reagieren nur auf GET-

Anfragen seitens des Clients. Für die Verarbeitung von Daten werden vom Controller

ausgelagerte Klassen verwendet.

Jedem Controller ist eine separate View zugewiesen, die je nach Nutzerinteraktion ange-

steuert und visualisiert wird.

Die Modelkomponenten sollen gemäß den Vorgaben des fachlichen Datenmodells umge-

setzt werden.

5.5.3 Der Client

In diesem Projekt dient ein beliebiger Internetbrowser als Client. Die Arbeitsweise des

Clients wird über die Views, konkret über die JavaScript-Funktionen, gesteuert.

Grundsätzlich ist die Webtechnologie in der Lage beliebige Clients mit Daten zu versor-

gen, solange sie über eine HTTP-Client-Funktion verfügen.

Beispiel C# Anwendung:

HttpClient client = new HttpClient();

var url = "http://127.0.0.1:81/api/test";

var response = await client.GetAsync(url);

var content = await response.Content.ReadAsStringAsync();

Beispiel Java Anwendung:

HttpClient client = new DefaultHttpClient();

HttpGet request = new HttpGet("http://127.0.0.1:81/api/test");

HttpResponse response = client.execute(request);

BufferedReader rd = new BufferedReader(new InputStreamReader(response.getEntity()

.getContent()));

58 Konzeption

5.5.4 Zu übertragende Datenstrukturen

Alle Daten, die übertragen werden, sind im JSON-Format zu serialisieren. Die Serialisie-

rung wird vom jeweiligen Controller automatisch durchgeführt und basiert auf den mit den

Datenmodellen vereinbarten Dataverträgen.

Datenverträge sind eine abstrakte Beschreibung der auszutauschenden Daten und defi-

nieren für jeden Parameter oder Rückgabewert, welche Daten serialisiert werden müssen.

Datenvertrag am Beispiel Element:

[DataContract]

public class ElementContainer

{

[DataMember]

public string key { get; set; }

[DataMember]

public string value { get; set; }

public ElementContainer(string k, string v)

{

key = k;

value = v;

}

}

5.5.5 Aktivitätsdiagramm

In dem folgenden Aktivitätsdiagramm ist der prinzipielle Ablauf einer Nutzerinteraktion zu

erkennen. Mit dem Start des Browsers und dem Aufrufen der URL zum Webservice soll

die Login View geöffnet werden, in der sich der Nutzer authentifizieren muss. Ist dies er-

folgreich geschehen soll vom System die Startseite geöffnet werden. Auf der Startseite

soll der Nutzer die Möglichkeit haben zwischen den verschiedenen Kategorien wählen zu

können. Wurde eine Wahl getroffen, werden vom System die entsprechenden Prüfkrite-

rien abgearbeitet und das Ergebnis in einer View dargestellt.

Konzeption 59

Abbildung 21 Aktivitätsdiagramm Kategorie wählen

Die eigentliche Komplexität verbirgt sich im Punkt „Prüfkriterien abarbeiten.“ Um sicherzu-

stellen, dass das System die richtigen Kriterien abarbeitet muss die Konfiguration eingele-

sen und die entsprechenden Parameter übernommen werden. Anschließend müssen die

Daten aus der Datenbank abgerufen und entsprechend der Parameter ausgewertet wer-

den. Aus den ausgewerteten Daten wird eine Fehlerliste erstellt, welche in der View dar-

gestellt wird. Der hier beschriebene Prozess ist in folgender Abbildung als Sequenzdia-

gramm grafisch dargestellt.

60 Konzeption

Abbildung 22 Sequenzdiagramm

Die GET-Methode eines Frontend Controller ruft die entsprechende Methode in dem auf-

gerufenen Controller des Backends auf. Dieser erzeugt eine Instanz der Klasse CheckLo-

gic und startet die Methode SimpleDatabaseCheck, welche für die datenbankspezifischen

Prüfkriterien verantwortlich ist. Um die zu prüfenden Parameter auszulesen, wird eine

Instanz der Klasse ConfigReader angelegt und deren Methode ReadConfig ausgeführt.

Die Klasse ConfigReader ist in der Lage, die Konfigurationsdatei auszulesen und eine

Liste mit Parametern zurückzuliefern, welche dem entsprechenden Controller zugeordnet

werden kann. Beispielsweise liefert der ConfigReader – für eine vom InfrastrukturControl-

ler aufgerufene Prozedur – nur Prüfparameter zurück, welche für die Infrastrukturgeräte

bestimmt sind. Ein wichtiger Parameter, der übergeben wird, ist die SQL-Query mit deren

Hilfe die Datenelemente, die geprüft werden sollen, abgerufen werden. Diese werden in-

nerhalb einer Liste verwaltet. Als nächster Schritt wird ein Objekt der Klasse Analyst er-

zeugt. Die Klasse Analyst verfügt über die Prüfmethoden und ist damit in der Lage, die

Datenelemente zu überprüfen. Von der Klasse Analyst wird letztlich für jedes Prüfkriterium

ein Objekt der Klasse FailureElement zurückgegeben, welches in einer Fehlerliste verwal-

tet wird. Sind alle Prüfkriterien der Konfiguration abgearbeitet wird die Liste der Fehler an

den Controller des Backends geliefert, serialisiert und als JSON-String dem Controller des

Frontends übergeben.

5.5.6 Dekomposition der SW-Einheit

Die statische Struktur des Softwaresystems ist wie im folgenden Klassendiagramm auf-

gebaut. Das Diagramm ist auf ein Minimum reduziert und veranschaulicht die Elemente

der Web API, welche für die logische Funktionalität der Monitoring-Software nötig sind.

Konzeption 61

Alle Klassen, welche von der Entwicklungsumgebung automatisch erstellt wurden und

zum Teil auch editiert werden mussten, sind aus Gründen der Übersichtlichkeit entfernt

worden. Das Gesamtsystem ergibt sich aus dem Dokumentationstool (stellt die View-

Klassen bereit) und der hier dargestellten Web API. Die rote Markierung symbolisiert die

Controllerklassen, Hilfsklassen werden durch die gelbe Farbe klassifiziert und die Modelle

durch Grün. Die View-Klassen, welche im Dokumentationstool neu angelegt werden

mussten, werden durch den Renderer (Razor), welcher von ASP.NET bereitgestellt wird,

in reinen HTML-Code übersetzt.

Abbildung 23 Klassendiagramm Web API

Implementierung 63

6 Implementierung

Das Product Backlog wurde für die Implementierungsphase in verschiedene Sprints ein-

geteilt; folgende Arbeitsschritte haben sich ergeben.

Sprint 1 Umsetzung der User Story ID 1 und 11

Abbildung 24 Navigationsmenü

Wie in Abbildung 25 dargestellt, wurden Steuerelemente in die View integriert, die mittels

CSS und jQuery individuell angepasst werden können. Die entsprechenden Codezeilen

sind in der Anlage „Grafisches Design“ zu finden.

Die Steuerelemente werden grün markiert, wenn in der entsprechenden Kategorie kein

Fehler festgestellt wurde. Falls nur Warnungen aber kein Fehler registriert wurde, wird der

Button gelb dargestellt und die Anzahl der Warnungen der Kategorie im Button angezeigt.

Wurde mindestens ein Fehler festgestellt, muss der Button rot markiert und die entspre-

chende Anzahl der Fehler und Warnungen angezeigt werden.

64 Implementierung

Sprint 2 Umsetzung der User Story ID 7 und 13

Abbildung 25 Tabellarische Darstellung der Kategorie Tags

Die einzelnen Prüfkriterien werden, wie in Abbildung 25 dargestellt, tabellarische aufgelis-

tet. Realisiert wird dies mit dem JavaScript Framework jqGrid. Dieses benötigt als Input

einen String im JSON-Format. Die Objekte werden automatisch deserialisiert und ent-

sprechend auf die Tabelle gemappt.

$('#failureList').jqGrid({

url: '/TagCMT/Json',

datatype: "json",

mtype: "GET",

contentType: "application/json",

grouping: true,

hoverrows: true,

colModel: [

{ name: 'key', index: 'key', width: 150, align: 'left'},

{ name: 'amount', index: 'amount', width: 50, align: 'left'},

{ name: 'message', index: 'message', width: 600, align: 'left',},

{ name: 'status', index: 'status', width: 50, fixed: true, formatter: booleanFormatter}

],

[…]

ondblClickRow: function (id) { […] }

});

Die wichtigsten Parameter sind:

url Methode des Controllers, der die Daten liefert „/Controller/Methode“

contentType Datentyp, welcher vom Controller geliefert wird

colModel: Spaltenaufbau der Tabelle

ondblClickRow Löst ein durch Doppelklick auf eine Spalte ausgelöstes Ereignis aus

Implementierung 65

Das automatische Mappen der Daten auf die Tabelle funktioniert nur, wenn die Spalten

den Schlüsseln aus dem JSON-String entsprechen. Dies wird auch durch den bereits er-

wähnten Datenvertrag zur Serialisierung gewährleistet. Beispielsweise wird die erste Zeile

der Abbildung 25 wie folgt serialisiert:

[{"key":"FEC","amount":"0","message":"Ohne Dummy, und alle Toleranzen auf 0","status":"ok"}]

Wie zu erkennen ist entsprechen die rotmarkierten Schlüssel den Spaltenbezeichnungen

in der Tabelle.

Die Detailansicht wird mittels Doppelklick auf eine Zeile der Tabelle geöffnet. Dabei wer-

den alle Elemente, die diesen Fehler verursacht haben in einem Popup dargestellt.

Abbildung 26 Detailansicht

Für diese Grafik wurde auf die Spalte „Rangen im Slow aktiv“ doppelt geklickt. Der Con-

troller hat die Elemente von der Web API abgerufen, welche den Fehler verursacht haben

und tabellarisch nach Bezeichnung und den falsch konfiguriertem Wert (Spalte Zwei) an-

gezeigt.

66 Implementierung

Sprint 3 Umsetzung der User Story ID 9, 10 und 12

6.3.1 Datenbankverbindung (ID 12)

Die Datenbankverbindung wird je nach Kundendatenbankbank entweder mit einem MS

SQL Datenbanktreiber oder mit dem Pendant von Oracle gewährleistet. Der entsprechen-

de Connectionstring wird in der WebConfig von ASP.Net hinterlegt und kann jederzeit

beliebig editiert werden ohne den Quellcode zu verändern. Der „Read-Only“ Zugriff wird

mit Hilfe von Nutzerrechten in der Datenbank durchgesetzt.

Die Datenbankabfragen werden in der Konfigurationsdatei hinterlegt.

Beispiel Oracle-Verbindung:

OracleConnection con = new OracleConnec-

tion(ConfigurationManager.ConnectionStrings["instant"].ConnectionString);

WebConfig:

<configuration>

<connectionStrings>

<add name="instant" connectionString="SERVER =(DESCRIPTION =(ADDRESS = (PROTOCOL =

TCP)(HOST = xxx.xxx.xxx.xxx)(PORT = 16000))(CONNECT_DATA =(SID = xxxxx))); UID=UserID;

PWD=Passwort" providerName="System.Data.OracleClient" />

</connectionStrings>

6.3.2 Kategorisierung von Prüfkriterien (ID 10)

Die Kategorisierung wird mit Hilfe des von der Geschäftsleitung vorgegebenen Workflows

– der Unterteilung in die Kategorien Projekt, Standort, Infrastruktur, Tags, Ortung und

Wartung – und der in dieser Weise strukturierten Konfigurationsdatei umgesetzt. So kann

gewährleistet werden, dass bei der Ausführung eines Steuerelementes in der GUI die

richtigen Prüfparameter ausgeführt werden.

6.3.3 Mehrstufige Bewertung von Fehlern (ID 9)

Durch die bereits beschriebenen Prüfalgorithmen werden lediglich Listen mit fehlerhaft

konfigurierten Geräten zurückgegeben. Ein Fehler, welcher in einer View dargestellt wer-

den kann, wurde daher noch nicht generiert. Dazu werden zwei Toleranzen (Siehe Konfi-

gurationsdatei „OuterTolerance1“ und „OuterTolerance2“) verwendet, um festzulegen, in

welcher Abstufung der Fehler zu generieren ist. Überschreitet die Anzahl der fehlerhaft

Implementierung 67

konfigurierten Geräte keine Toleranz wird kein Fehler generiert („ok“). Wird die erste Tole-

ranzstufe überschritten, Toleranz zwei jedoch nicht, wird eine Warnung („warning“) gene-

riert. Wird die Toleranzstufe zwei überschritten wird ein Fehler („error“) generiert. Die Wer-

te der Toleranzen können in der Konfigurationsdatei definiert werden.

public FailureContainer constructFailureList(List<ElementContainer> list, string cacheKey, string

message, int outerTol1, int outerTol2)

{

if (list.Count > outerTol2) return new FailureContainer(cacheKey,

list.Count.ToString(), message, "error");

else if (list.Count <= outerTol1) return new FailureContainer(cacheKey,

list.Count.ToString(), message, "ok");

else return new FailureContainer(cacheKey, list.Count.ToString(), message, "warn-

ing");

}

Sprint 4 Umsetzung der User Story ID 3, 5, 6 und 15

6.4.1 Ein- und Ausloggen von Usern mit WLS-Konto

Für die Umsetzung dieses Tool wird die von ASP.Net zur Verfügung gestellte Formular-

Login-View genutzt.

Abbildung 27 Formular Login als Teilansicht

ASP.Net ist optimiert für verschiedene Authentifizierungsszenarien, wie zum Beispiel mit-

tels Windows-Konto oder für die Authentifizierung mittels eines Google- oder Facebook-

Kontos. Für das CMT ist eine Custom-Authentifizierung entwickelt wurden. Diese nutzt die

Anmeldedaten der in der WLS-Datenbank hinterlegten Nutzerkonten. Folgende Funkti-

onsweise wurde dabei implementiert:

1. Nutzer gibt Benutzername und Kennwort ein.

68 Implementierung

2. Programm verschlüsselt das Kennwort (da in der Datenbank nur verschlüsselte

Passwörter vorliegen und diese nicht entschlüsselt werden sollen)

3. Programm baut Datenbankverbindung auf und ruft Nutzerdaten (Benutzername

und verschlüsseltes Passwort) aus der WLS-Datenbank ab

4. Vergleichen der Benutzernamen und verschlüsselte Kennwörter

5. Bei gültiger Kombination: Authentisierung des Nutzers, bei falscher Kombination:

keine Authentisierung (Meldung „Der angegebene Benutzername oder das ange-

gebene Kennwort ist ungültig.“ wird angezeigt)

Der Quellcode zu der hier beschriebenen Funktionsweise ist in der Anlage Nutzerauthen-

tifizierung aufgeführt. Das Verfahren zum Verschlüsseln der Passwörter kann aus Daten-

schutzrechtlichen Gründen nicht beschrieben werden.

6.4.2 Unterstützung von Nutzerrollen

Auch für diese Funktion gibt es im ASP.Net Framework bereits vorgefertigte Methoden,

welche allerdings nicht in das hier vorliegende Konzept passen. Aus diesem Grund wird

ein „Custom Role Provider“ Implementiert, der die Möglichkeit bietet, jedem Benutzer eine

Rolle zuzuweisen.

Dies wird derzeit noch primitiv mit manueller Zuweisung mittels Arrays gewährleistet. In

Zukunft werden die im WLS hinterlegten Rollen unterstützt.

public override string[] GetRolesForUser(string username) {

switch (username) {

case "sna": {

return new[] { "Manager", "Administrator" }; } default: return new string[] { "Administrator" };

} }

Die Methoden der Controller können im Anschluss an verschiedene Nutzerrollen gebun-

den werden.

[Authorize(Roles="Administrator")]

public ActionResult Index()

{

return View();

}

Implementierung 69

Zusatz Reporterstellung und Performancesteigerung

Als Wunschkriterium wurde die Möglichkeit zur Erstellung eines Reports angegeben. Die-

ses Kriterium ist nicht voll umgesetzt, jedoch ein Lösungsansatz dazu entwickelt worden.

In diesem Zusammenhang werden die Möglichkeiten von XML und den damit verbunde-

nen Technologien XSLT und XSL-FO genutzt Zur Generierung des Reports im PDF-

Format wird eine externe Engine (FO.NET) verwendet.

Das Folgende Listing zeigt die Umwandlung eines JSON-String in das XML Format (re-

port.xml), die Formatierung gemäß einer Vorlage (report.xsl) und die Übersetzung ins

PDF-Format. Die Formatvorlage ist in Anlage „XSL Formatvorlage“ aufgeführt.

//Umwandlung JSON in XML

byte[] bytes = Encoding.UTF8.GetBytes(jsonString);

using (var stream = new MemoryStream(bytes))

{

var quotas = new XmlDictionaryReaderQuotas();

var jsonReader = JsonReaderWriterFactory.CreateJsonReader(stream, quotas);

XDocument xml = XDocument.Load(jsonReader);

xml.Save("C:/…/report.xml");

}

//Transformation mit xslt

XslCompiledTransform xslt = new XslCompiledTransform();

xslt.Load("C:/…/report.xsl");

xslt.Transform("C:/…/report.xml", "C:/…/report.fo");

//Übersetzung nach PDF

FonetDriver driver = FonetDriver.Make();

driver.Render("C:/…/report.fo", "C:/…/report.pdf");

Zur Steigerung der Performance wurde auf Seiten der Web API Caching eingesetzt. Er-

gebnisse, die auf Grund einer Nutzerinteraktionen generiert wurden, werden mittels Time-

Caching im Arbeitsspeicher gehalten und bei einer erneuten Nutzerinteraktion (innerhalb

eines einstellbaren Zeitfensters) ohne Neuberechnung zum Client gesendet. Zur Erweite-

rung dieses Mechanismus können Caching-Monitore eingesetzt werden, welche eine Än-

derung der Rahmenbedingungen registrieren und auch innerhalb des Zeitfensters eine

Neuberechnung veranlassen können.

Fazit 71

7 Fazit

Das Fazit dieser Arbeit muss sich in zwei verschiedene Perspektiven unterteilen. Zum

einen in Hinblick auf die Erstellung der Software und die Einhaltung der Anforderungen,

welche an die Software gestellt wurden. Zum anderen bezüglich der Verwendung der

Technologie für die weitere Entwicklung des WIRELESS LOCATION SYSTEM.

Erstellung der Software

In diesem Projekt wurde ein Prototyp entwickelt der das Konzept einer Diagnosesoftware

in vollem Maße realisiert. Das CMT ist in der Lage den Zustand des WLS zu analysieren,

Anomalien zu identifizieren und dem Nutzer grafisch darzustellen. Einschränkungen

mussten im Funktionsumfang bezüglich der Prüfmechanismen gemacht werden, da zum

Zeitpunkt der Erstellung dieser Arbeit keine Schnittstelle zum WLS existierte, welche es

ermöglicht Livedaten abzurufen. Aus diesem Grund ist die Analyse derzeit lediglich auf

Daten aus der Datenbank gestützt. Die Software wurde so flexibel gestaltet, dass, ohne

das Gesamtkonzept zu ändern, Anpassungen oder das Einpflegen neuer Funktionen

durchgeführt werden können. Darüber hinaus erfüllt die Software alle von den Stakehol-

dern gestellten Anforderungen. In den weiteren Entwicklungsprozessen werden die Neue-

rungen des ASP.NET vNext in das System integriert, um so einen plattform- und vor allem

Webserver-unabhängigen Standard zu erfüllen. Dies ist Voraussetzung für den Einsatz in

„Livesystemen.“

Weiterentwicklung des WLS

Im Rahmen dieser Arbeit konnten die grundlegenden Möglichkeiten des ASP.NET

Framework aufgezeigt werden. Mit diesem Framework ist der Entwickler in der Lage fort-

geschrittene Webanwendungen zu erstellen. Darüber hinaus unterstützt das ASP.NET

eine Vielzahl von externen Frameworks, zum Beispiel jQuery, mit denen der Funktions-

umfang um ein Vielfaches erweitert werden kann. Der gravierendste Schwachpunkt – die

Plattformabhängigkeit – wird mit dem Release der nächsten Version eliminiert.

Eine generelle Entscheidung für oder gegen die Verwendung von ASP.NET als Basis-

technologie kann, im Rahmen dieser Arbeit, jedoch nicht getroffen werden.

72 Fazit

8 Literatur

Agilion GmbH (2014). http://www.agilion.de/de/produkte/m-wireless-location-

system/systemarchitektur. Abruf am 2014-07-24.

Cockburn A (2008) Use cases effektiv erstellen. mitp, Heidelberg.

Drost L (2014) „Betriebswirtschaftliche, software- und informationstechnische Konzeption

einer Schnittstelle für den Datenaustausch zwischen SAP Business One und aXc-Project.

Bachelorarbeit, MNI, Mittweida.

Ebert C (2012) Systematisches Requirements Engineering. Anforderungen ermitteln, spe-

zifizieren, analysieren und verwalten. dpunkt.verlag.

jQuery Foundation - jquery.org (2014) jquery.com. jquery.com. Abruf am 2014-07-11.

Naumann S (2014) Praktikumsbericht von Sebastian Naumann bei der Agilion GmbH.

Praktikumsbericht, MNI, Mittweida.

Schwichtenberg H Cross-Site Scripting. http://www.it-

visions.de/glossar/alle/3234/CrossSite_Scripting.aspx. Abruf am 2014-10-10.

Steyer M, Schwichtenberg H (2014) Moderne Webanwendungen mit ASP.NET MVC und

JavaScript. ASP.NET MVC im Zusammenspiel mit Web APIs und JavaScript-

Frameworks. O'Reilly, Beijing, Köln [u.a.].

Anlage, Checkliste der Anforderungsanalyse I

Anlage, Checkliste der Anforderungsanalyse

1. Wer ist der Kunde? Wer ist nicht Kunde?

2. Welche Herausforderungen muss der Kunde in Zukunft bestehen?

3. Welches Problem soll das System lösen?

4. Welchen Nutzen soll der Kunde aus der Lösung ziehen?

5. Welche Anforderungen haben verschiedene Kunden an dieses Produkt? Brauchen sie spezielle Dienstleistungen?

6. Welche Risiken werden mit der geplanten Lösung auftreten?

7. Sind ausreichend Ressourcen vorhanden um das Produkt pünktlich und mit der richtigen Qualität zu liefern?

8. Was exakt muss das Projekt liefern?

9. Welche Szenarien sind relevant?

10. Welche Kriterien/Anforderungen muss das Produkt erfüllen und wie sind deren Relevanz?

11. Welche Funktionen und Eigenschaften sind an diesem Produkt am wichtigsten?

12. Kommen die Anforderungen von der richtigen Seite? Wurde eine Partei übersehen?

13. Welche Qualitätsanforderungen werden an das Produkt gestellt? Welche davon ist die wichtigste?

14. Was wäre wenn diese nicht realisiert werden kann?

15. Welche Interessengruppen spielen für den Erfolg des Projektes eine Rolle?

16. Wie sieht das Umfeld eines solchen Systems aus? Welche Einflüsse bestimmen die zu entwickelnde Lösung im Tagesgeschäft?

17. Sind die späteren Nutzer bekannt?

18. Wie werden die Benutzer mit dem System kommunizieren?

19. Sind die Anforderungen technisch machbar?

20. Welches Problem könnte dieses System verursachen? (z.B. Installation, Betrieb, Wartung)

21. Welche zusätzlichen Anforderungen und Randbedingungen können später einmal auftre-ten?

22. Sind Sie der richtige Ansprechpartner?

23. Welche anderen Personen sollte ich noch befragen?

24. Haben Sie den Eindruck, ich habe vergessen, Sie etwas zu fragen? (Ebert 2012)

A-II Anlage, Inbetriebnahme eines WLS

Anlage, Inbetriebnahme eines WLS

Vorphase

Abbildung 28 Vorphase einer Inbetriebnahme

Anlage, Inbetriebnahme eines WLS III

Installationsphase

Abbildung 29 Installationsphase eines WLS

A-IV Anlage, Inbetriebnahme eines WLS

Ortungskonfiguration

Abbildung 30 Ortungskonfiguration eines WLS

Anlage, Prüfkatalog V

Anlage, Prüfkatalog

Ergebnis Brainstorming

FEC

Sendeleistung

Kalibrierwert Gruppenbasiert

SW Version

inkonsistente Konfiguration

Luftdruck Gerätegruppen

Tags, die im Slow rangen

degenerieren des Systems

Client-, Serverversionen "veraltet"

Parameterstreuung (x,y, z 0)

Qualitätsbeurteilung, Systemweit und Tagebene

Ranging Fehler

Geräteauslastung

Lifesigntimeout

"Leichenidentifikation"

Serverneustarts

Datenexportverbindung, Datenbank (Aufbau und Abbau)

Datenbankgröße, Tabellengröße (Statistik / Logging)

Prozessorauslastung (WLS) (Statistik / Logging)

Plausibilität I/O

Antennenpos. und physisches Modell

Unterspannung

Statistik Routen

Überlappungserkennung

Fahrzeugduplikate

Geräte mit schlechter Metrik (unterdurchschnittlich)

Durchschnittliche Ranging Partner (Tags)

Konsistenzprüfung Ortungsbereiche (nicht zugeordnete Ortungsbereiche, Geräte ohne OB)

Geräte mit deaktivierter Ortung

Geräte bei denen Parameter auf Default stehen

Anzahl der noch zu flashenden Geräte

Geräte ohne .awt Files

Datenbankperformance

anormale Fahrbewegungen

Antennenposition

Gateway, die kein Netzwerklink haben

A-VI Anlage, Prüfkatalog

Ausgearbeiteter tabellarischer Katalog

Projekt

Funktion Fehler Fehlerstufen

Eingaben vollständig? Wurden alle Projekteinstellungen vorgenommen? Fehler wenn unvollständig Zweistufig

Lizenzen gültig? Fehler wenn ungültig Zweistufig

Client-, Serverversionen Untersuchung der Versionen bei bestimmter Version kein Fehler Dreistufig

(bereits in Dokumentationstool vorhanden) ab Version x Warnung

ab Version xx Fehler

Standorte bisher keine Prüfungen

Anlage, Prüfkatalog VII

TAGs


FEC Untersuchung des Parameters bei Gleichheit kein Fehler Zweistufig

bei Unterschied Fehler

Datenbankabfrage

Sendeleistung Untersuchung des Parameters Kein Fehler innerhalb einer Toleranz Dreistufig

Warnung bei Überschreitung um einen gewissen Faktor

Datenbankabfrage Fehler bei Überschreitung um einen höheren Faktor

Tags, die im Slow rangen Untersuchung des Parameters 0 Geräte kein Fehler Dreistufig

x Geräte Warnung

Datenbankabfrage xx Geräte Fehler

Fahrzeugduplikate 0 Kein Fehler Zweistufig

< 0 Fehler

Firmware-Version Untersuchung des Parameters

Datenbankabfrage

Unterspannung Geräte Untersuchung des Parameters Kein Fehler innerhalb einer Toleranz

Warnung bei Überschreitung um eine gewisse Anzahl

Datenbankabfrage Fehler bei Überschreitung bei höheren Anzahl

Ranging Fehler Abfrage Statistik Kein Fehler innerhalb einer Toleranz Dreistufig


Nutzung Statistiktool Fehler bei Überschreitung um einen höheren Faktor

Lifesigntimeout Abfrage Statistik Kein Fehler innerhalb einer Toleranz Dreistufig



Geräte ohne Ortungsbereich Geräte ohne Ortungsbereich 0 Kein Fehler Zweistufig

A-VIII Anlage, Prüfkatalog

< 0 Fehler

Unerledigte Firmware-Updates Liste der noch zu flashenden Geräte ist nicht leer 0 Kein Fehler Zweistufig

< 0 Fehler

Geräte ohne .awt Files können nicht parametrisiert werden 0 Kein Fehler Zweistufig

< 0 Fehler

Infrastruktur


Sendeleistung Untersuchung des Parameters Kein Fehler innerhalb einer Toleranz Dreistufig



Geräte mit deaktivierter Ortung Untersuchung des Parameters

Datenbankabfrage

Kalibrierwert Untersuchung des Parameters bei Gleichheit kein Fehler Dreistufig



Firmware-Version Untersuchung des Parameters

Datenbankabfrage

Unterspannung Geräte Untersuchung des Parameters Kein Fehler innerhalb einer Toleranz



Geräteauslastung Schnittstelle zu WLS nötig Kein Fehler innerhalb einer Toleranz Dreistufig


Fehler bei Überschreitung um einen höheren Faktor

Anlage, Prüfkatalog IX

Lifesigntimeout Abfrage Statistik Kein Fehler innerhalb einer Toleranz Dreistufig



Geräte mit schlechter Metrik Untersuchung des Parameters Kein Fehler innerhalb einer Toleranz Dreistufig



Inkonsistente Parameter Sind Parameter noch auf Default-Einstellung, die im Livesystem anders gesetzt sein sollten? z.B. x, y oder z

Unerledigte Firmware-Updates Liste der noch zu flashenden Geräte ist nicht leer 0 Kein Fehler Zweistufig

< 0 Fehler

Geräte ohne .awt Files Weitere Spezifikation nötig 0 Kein Fehler Zweistufig

< 0 Fehler

Gateways ohne Netzwerk-Link Schnittstelle zu WLS nötig

Ortung


Überlappungserkennung Untersuchung des Parameters Kein Fehler innerhalb einer Toleranz Dreistufig



Nicht zugeordnete Ortungsbereiche nicht zugeordnete Ortungsbereiche 0 Kein Fehler Zweistufig

< 0 Warnung

Ortungsqualität Schnittstelle zu WLS nötig

Unnormale Fahrbewegung Schnittstelle zu WLS nötig

Geschwindigkeitsüberschreitungen Schnittstelle zu WLS nötig

A-X Anlage, Prüfkatalog

Wartung


Datenbankgröße/Tabellengröße Untersuchung des Parameters Kein Fehler innerhalb einer Toleranz Dreistufig



Prozessorauslastung Prüfung aus Quellcode Kein Fehler innerhalb einer Toleranz Dreistufig


Fehler bei Überschreitung um einen höheren Faktor

Datenexportverbindung Abfrage Statistik Kein Fehler innerhalb einer Toleranz Dreistufig



Serverneustarts Abfrage Statistik Kein Fehler innerhalb einer Toleranz Dreistufig



Updates Prüfung auf neue WLS-Version Warnung bei veralteter Version Zweistufig

Datenbankverbindung Abfrage Statistik Kein Fehler innerhalb einer Toleranz Dreistufig



Meldungsmanagement Auflistung versandter Meldungen Abhängig von Art/Anzahl der Meldungen Dreistufig

Datenbank-Performance Genauere Spezifikation nötig Definition von Messungen und Logging im WLS nötig

Anlage, Grafisches Design XI

Anlage, Grafisches Design

CSS Formatvorlage der Buttonelemente

.buttonRed {

background-color: #ff0000; } .buttonRed:hover {

background-color: #ff0000; border-style:ridge;

} .buttonYellow {

background-color: #fedb1d; } .buttonYellow:hover {

background-color: #fedb1d; border-style:ridge;

} .buttonGreen {

background-color: #0ab721; } .buttonGreen:hover {

background-color: #0ab721; border-style:ridge;

} .buttonGreen, .buttonYellow, .buttonRed {

height: 50px; width: 170px; border-style: outset; border-color:ActiveBorder; display: block; border-radius: 10px 10px; text-align: center; font-size:large; font-weight:800; text-decoration: none; margin: 10px 10px 20px; vertical-align: central;

}

A-XII Anlage, Grafisches Design

Manipulation der Buttonelemente mittels jQuery am Beispiel Projekt:

$.getJSON('/ProjectCMT/getJson', function (data) {

var Error = 0; var Warning = 0; $.each(data, function (key, value) {

$.each(value, function (key, value) { if (key === "status" && value === "error") Error++; if (key === "status" && value === "warning") Warning++; });

}); if (Error > 0) {

$('#Projekt').attr({ class: "buttonRed" }); if (Warning === 1) $('#Projekt_Warnung').text(Warning + " Warnung"); else $('#Projekt_Warnung').text(Warning + " Warnung"); $('#Projekt_Fehler').text(Error + " Fehler");

} else {

if (Warning > 0) { if (Warning === 1) { $('#Projekt_Warnung').text(Warning + " Warnung"); $('#Projekt').attr({ class: "buttonYellow" });

} else {

$('#Projekt_Warnung').text(Warning + " Warnungen"); $('#Projekt').attr({ class: "buttonYellow" }); }

} }

});

Manipulation der Statusmitteilung in der Tabellenansicht mit-tels jQuery:

function booleanFormatter(cellvalue, options, rowObject) {

if (cellvalue == "ok") { return "<img src='../../Images/icons/ok.jpg' width=\"30\" height=\"30\" />"; } else if (cellvalue == "warning") { return "<img src='../../Images/icons/warning.jpg' width=\"30\" height=\"30\" />"; } else { return "<img src='../../Images/icons/error.jpg' width=\"30\" height=\"30\" />"; } }

Anlage, Nutzer-Authentifizierung XIII

Anlage, Nutzer-Authentifizierung

public class CustomMembershipProvider : MembershipProvider {

static int MAX_LOGIN_TEXT_LENGTH = 20; static readonly List<User> Users = new List<User>(getUsers());

public class User {

public string Username { get; set; } public string Password { get; set; }

public User(string name, string pw) {

Username = name; Password = pw;

} }

public static List<User> getUsers() {

List<User> list = new List<User>(); OracleConnection con = new OracleConnec-

tion(ConfigurationManager.ConnectionStrings["instant"].ConnectionString); OracleCommand com; OracleDataReader dr; try {

con.Open(); com = con.CreateCommand(); com.CommandText = "SELECT login, pwd FROM users"; dr = com.ExecuteReader(); while (dr.Read()) {

list.Add(new User(dr[0].ToString(), dr[1].ToString())); }

} catch (Exception){}

return list; }

/** Hashen der Passworteingabe*/ public static byte[] vScramblePwD(String pwd) {

String ges = pwd + "jkhJHjh8f18(!"; byte[] ok = new byte[MAX_LOGIN_TEXT_LENGTH]; for (int i = 0; i < MAX_LOGIN_TEXT_LENGTH; i++) {

ok[i] = (byte)ges.ToCharArray()[i]; } vScramble(ok, MAX_LOGIN_TEXT_LENGTH); return ok;

}

/** Hilfsfunktion zum Passworthashen */ private static void vScramble(byte[] _pbData, int _wLength) { […]/** Aus Datenschutzgründen nicht aufgeführt */ } /** Validierung des Nutzers */ public override bool ValidateUser(string username, string password) {

var pw = System.Text.Encoding.Default.GetString(vScramblePwD(password)); return Users.Exists(m => m.Username == username && m.Passwort == pw);

}

A-XIV Anlage, XSL Formatvorlage

Anlage, XSL Formatvorlage

<?xml version="1.0" encoding="iso-8859-1"?> <xsl:stylesheet version="1.0" xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">  <xsl:template match="/"> <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"> <fo:layout-master-set> <fo:simple-page-master master-name="main" page-height="29.7cm" page-width="21cm" font-family="sans-serif" margin-top="0.5cm" margin-bottom="1cm" margin-left="2cm" margin-right="2cm"> <fo:region-body margin-top="4.0cm" margin-bottom="1cm" /> <fo:region-before extent="1.5cm" /> </fo:simple-page-master> </fo:layout-master-set> <fo:page-sequence master-reference="main"> <fo:flow flow-name="xsl-region-body" > <xsl:apply-templates /> </fo:flow> </fo:page-sequence> </fo:root> </xsl:template> <xsl:template match="root/item"> <fo:block> <xsl:value-of select="key" /><xsl:text> </xsl:text> <xsl:value-of select="amount" /><xsl:text> </xsl:text> <xsl:value-of select="message" /><xsl:text> </xsl:text> <xsl:value-of select="status" /><xsl:text> </xsl:text> </fo:block> </xsl:template> <xsl:template name="table"><xsl:text>Tabelle</xsl:text></xsl:template>

</xsl:stylesheet>

Selbstständigkeitserklärung

Selbstständigkeitserklärung

Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig und nur unter Verwen-

dung der angegebenen Literatur und Hilfsmittel angefertigt habe.

Stellen, die wörtlich oder sinngemäß aus Quellen entnommen wurden, sind als solche

kenntlich gemacht.

Diese Arbeit wurde in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde

vorgelegt.

Chemnitz, den 24.10.2014

Sebastian Naumann

Documents

Inhalt · Prinzip „Alles aus einer Hand.“ Auf diese Weise ist es möglich Applikationen und Geräte Auf diese Weise ist es möglich Applikationen und Geräte in Automotivequalität