Entwicklung eines Datenmanagementsystems für den ... · Für stationäre Maschinen und Anlagen...

152
Abschlussbericht zum Verbundforschungsprojekt Entwicklung eines Datenmanagementsystems für den Teleservice bei mobilen Arbeitsmaschinen (DAMIT) Das diesem Bericht zugrunde liegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen 0330711 gefördert. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt bei den Autoren. Laufzeit: 01.05.2006 – 30.04.2009 Autoren: Brandt, V.; Dirks, M.; Ganseforth, A.; Göres, T.; Grothaus, H.-P.; Harms, H.-H.; Möller, A.; Rustemeyer, T.; Wäsch, D.

Transcript of Entwicklung eines Datenmanagementsystems für den ... · Für stationäre Maschinen und Anlagen...

Abschlussbericht zum Verbundforschungsprojekt

Entwicklung eines Datenmanagementsystems für den Teleservice bei mobilen Arbeitsmaschinen

(DAMIT)

Das diesem Bericht zugrunde liegende Vorhaben wurde mit Mitteln des Bundesministeriums

für Bildung und Forschung unter dem Förderkennzeichen 0330711 gefördert. Die

Verantwortung für den Inhalt dieser Veröffentlichung liegt bei den Autoren.

Laufzeit: 01.05.2006 – 30.04.2009

Autoren:

Brandt, V.; Dirks, M.; Ganseforth, A.; Göres, T.; Grothaus, H.-P.; Harms, H.-H.; Möller, A.;

Rustemeyer, T.; Wäsch, D.

Inhaltsverzeichnis II

Inhaltsverzeichnis

I Kurzdarstellung des Forschungsvorhabens ....................................................1

I.1 Einleitung.................................................................................................................... 1 I.2 Aufgabenstellung und Zielsetzung ............................................................................. 1 I.3 Planung und Ablauf des Vorhabens ........................................................................... 2 I.4 Stand der Wissenschaft und Technik zu Projektbeginn ............................................. 2 I.5 Zusammenarbeit mit anderen Stellen......................................................................... 8

II Eingehende Darstellung des Forschungsvorhabens.......................................9

II.1 Zustandsüberwachung exemplarischer Baugruppen ................................................. 9 II.1.1 Voraussetzungen für ein Condition Monitoring ................................................... 9

II.1.1.1 Instandhaltungsstrategien ............................................................................. 9 II.1.1.1.1 Messbarkeit des Verschleißzustandes................................................. 10 II.1.1.1.2 Interpretierbarkeit der Zustandsgröße.................................................. 11 II.1.1.1.3 Prognostizierbarkeit des Verschleißverhaltens .................................... 11

II.1.1.2 Beispielbaugruppe Walzengang ................................................................. 11 II.1.1.3 Beispielbaugruppe Hydrauliköl.................................................................... 13

II.1.2 Vorhersagbarkeit von Wartung und Instandhaltung.......................................... 16 II.1.2.1 Kettenlängung Schrägförderer .................................................................... 16

II.1.2.1.1 Einleitung ............................................................................................. 16 II.1.2.1.2 Erkenntnisse anhand Prüfstandsuntersuchungen ............................... 18 II.1.2.1.3 Abgleich mit Daten aus dem Ernteeinsatz ........................................... 19

II.1.2.2 Luftfilterverschmutzung Dieselmotor........................................................... 21 II.1.2.2.1 Einleitung ............................................................................................. 21 II.1.2.2.2 Untersuchungen am Prüfstand ............................................................ 22 II.1.2.2.3 Auswertung der Erntedaten ................................................................. 24

II.1.2.3 Zusammenfassung...................................................................................... 25 II.2 Datenmanagement ................................................................................................... 27

II.2.1 Kompressionsmethoden für verschiedene Datenarten..................................... 27 II.2.1.1 Dateneigenschaften und Anforderungen an die Kompressionsmethoden.. 27 II.2.1.2 Theoretische Betrachtungen und Voruntersuchungen................................ 32

II.2.1.2.1 Theoretische Betrachtungen................................................................ 32 II.2.1.2.2 Voruntersuchungen.............................................................................. 34

II.2.1.3 Entwicklung der Methoden.......................................................................... 43

Inhaltsverzeichnis III

II.2.1.3.1 Entwicklungsumgebung und Vorgehen................................................ 43 II.2.1.3.2 Kompressionsmethode für Messwert-Zeitreihen.................................. 44 II.2.1.3.3 Kompressionsmethode für Positionsdaten........................................... 50

II.2.1.4 Experimentelle Erprobungen....................................................................... 70 II.2.1.4.1 Versuchstraktor und Entwicklungsumgebung ...................................... 70 II.2.1.4.2 Feldversuche........................................................................................ 73 II.2.1.4.3 Erprobung der Kompressionsmethoden .............................................. 74

II.2.1.5 Hinweise für die Praxis................................................................................ 89 II.2.1.5.1 Hinweise zur Implementierung............................................................. 90 II.2.1.5.2 Hinweise zur Parametrierung............................................................... 91 II.2.1.5.3 Hinweise zu Einsatzmöglichkeiten und -grenzen................................. 94

II.2.2 Software-Architektur und Datenfluss ................................................................ 96 II.2.2.1 On-Board-Unit ............................................................................................. 96

II.2.2.1.1 Eingesetzte Hardware.......................................................................... 96 II.2.2.1.2 Programmiersprachen.......................................................................... 97

II.2.2.2 Software-Architektur.................................................................................... 97 II.2.2.2.1 Einleitung ............................................................................................. 97 II.2.2.2.2 Schichtentrennung ............................................................................... 98 II.2.2.2.3 Schichtenarchitektur............................................................................. 98

II.2.2.3 Beschreibung der Dienste........................................................................... 99 II.2.2.3.1 GSM-Treiber ........................................................................................ 99 II.2.2.3.2 WLAN-Treiber ...................................................................................... 99 II.2.2.3.3 GPS/Galileo ......................................................................................... 99 II.2.2.3.4 CAN-Bus Interface ............................................................................. 100 II.2.2.3.5 Positioning.......................................................................................... 100 II.2.2.3.6 Kommunikation .................................................................................. 100 II.2.2.3.7 Sensoren/Aktoren .............................................................................. 100 II.2.2.3.8 Datenablage....................................................................................... 100 II.2.2.3.9 Datenlogger........................................................................................ 100 II.2.2.3.10 Datenverdichter ................................................................................. 101 II.2.2.3.11 Kommunikationsmanager.................................................................. 101

II.2.2.4 Simulationsumgebung............................................................................... 101 II.2.2.5 Datenverarbeitung auf der OBU................................................................ 102

II.2.2.5.1 Sensordienste .................................................................................... 102 II.2.2.5.2 Sensortransformer ............................................................................. 103 II.2.2.5.3 Datenverdichter und Datenablage ..................................................... 104

Inhaltsverzeichnis IV

II.2.2.5.4 Alarm-Manager .................................................................................. 105 II.2.2.6 Konfiguration der OBU.............................................................................. 107 II.2.2.7 Kommunikation mit dem Backend............................................................. 108

II.2.2.7.1 Schnittstelle zwischen OBU und Backend ......................................... 108 II.2.2.7.2 Intervalle............................................................................................. 109 II.2.2.7.3 Versende-Strategien .......................................................................... 110 II.2.2.7.4 Automatische Berechnung optimaler Strategien................................ 111

II.2.2.8 XML-Dateistruktur zur internen Datenübertragung ................................... 113 II.2.2.8.1 ISO-XML ............................................................................................ 113 II.2.2.8.2 Beschreibung der Formate zur Datenübertragung............................. 115

II.2.2.9 Back-End................................................................................................... 116 II.3 Vernetzte Prozesse ................................................................................................ 119

II.3.1 Technologien und Schnittstellen im Logistikprozess ...................................... 119 II.3.1.1 Prozessmodell Logistikkette Rübe ............................................................ 119

II.3.1.1.1 Teilprozess Kampagnenplanung........................................................ 120 II.3.1.1.2 Teilprozess Roden ............................................................................. 121 II.3.1.1.3 Teilprozess Abfuhr ............................................................................. 122

II.3.1.2 Datenformate ............................................................................................ 122 II.3.1.3 Umsetzung................................................................................................ 123

II.3.2 Vorbeugende Instandhaltungsprozesse durch Teleservice ............................ 124 II.3.2.1 Einordnung des Themas „Vorbeugende Instandhaltungsprozesse durch

Teleservice“............................................................................................... 124 II.3.2.2 Was bedeutet „Instandhaltung“? ............................................................... 124 II.3.2.3 Was bedeutet „Vorbeugende Instandhaltung“? ........................................ 124 II.3.2.4 Was wird für die „Vorbeugende Instandhaltung“ benötigt? ....................... 125 II.3.2.5 Rolle der verschiedenen Forschungs-Cluster des Projektes für die

„Vorbeugende Instandhaltung“.................................................................. 125 II.3.2.5.1 „Zustandsüberwachung exemplarischer Baugruppen“ ...................... 125 II.3.2.5.2 „Datenmanagement“ .......................................................................... 125 II.3.2.5.3 „Teleservice“ ...................................................................................... 125 II.3.2.5.4 Was sind „Vorbeugende Instandhaltungsprozesse durch Teleservice“?

........................................................................................................... 126 II.4 Systembasierte Dienstleistungen ........................................................................... 129

II.4.1 Dienstleistungsangebote für mobile Arbeitsmaschinen .................................. 129 II.4.1.1 Dienstleistungsfelder und ihre aktuellen Trends ....................................... 130

Inhaltsverzeichnis V

II.4.1.1.1 Besondere Rahmenbedingungen für Instandhaltungsleistungen in der

Agrartechnik ...................................................................................... 131 II.4.1.1.2 Kundenanforderungen ....................................................................... 131

II.4.1.2 Instandhaltung als Teil der Lifecycle Kosten............................................. 132 II.4.1.2.1 Instandhaltungsbegriffe (DIN) ............................................................ 132 II.4.1.2.2 Instandhaltungsstrategien .................................................................. 132

II.4.1.3 Dienstleistungsprozess ............................................................................. 134 II.4.1.3.1 Nutzung verteilter Informationen für den Produktentstehungsprozess

........................................................................................................... 135 II.4.1.4 Dienstleistungsangebote........................................................................... 136

II.4.1.4.1 Planbare Instandhaltung als Kern wirtschaftlicher Serviceangebote . 136 II.4.1.4.2 Wirtschaftliche Serviceangebote........................................................ 137

III Zusammenfassung..........................................................................................138

IV Literaturverzeichnis ........................................................................................139

V Veröffentlichungen und Vorträge...................................................................145

V.1 Veröffentlichungen.................................................................................................. 145 V.2 Vorträge.................................................................................................................. 146

I Kurzdarstellung des Forschungsvorhabens 1

I Kurzdarstellung des Forschungsvorhabens

I.1 Einleitung

Zwei Trends haben die Entwicklungen im Segment der mobilen Arbeitsmaschinen in den

letzten Jahren nachhaltig gekennzeichnet. Neben der stetig zunehmenden Leistung und

Schlagkraft der Maschinen ist vor allem der vermehrte Einsatz von Elektronik charak-

teristisch. Insbesondere in der Landtechnik hat der Anteil elektronischer Komponenten

rapide zugenommen. Ursache hierfür waren ein gestiegener Kostendruck und der zuneh-

mende nationale und internationale Wettbewerb, dem sowohl Hersteller als auch Instand-

halter und Betreiber der Maschinen ausgesetzt sind. Neben der Reduzierung der Betriebs-

kosten zielen die Entwicklungen auf eine Erhöhung der Verfügbarkeit der Maschinen, die

häufig Schlüsselfunktionen in den Arbeitsprozessen einnehmen.

Zusätzlich zum verstärkten Elektronikeinsatz auf den Einzelmaschinen ermöglichen Tele-

matik- bzw. Teleservice-Systeme die kommunikationstechnische Verknüpfung der Maschine

mit einem zentralen Daten-Server. Eine wichtige Teilfunktion dieser Systeme stellt die Früh-

erkennung und Ferndiagnose von Maschinenzuständen dar, um Serviceprozesse optimieren

und so den Maschinennutzen für den Betreiber maximieren zu können. Auch der Zugriff auf

Maschinendaten über das Internet kann den Maschinenbetreiber unterstützen, die Einsatz-

planung seiner Maschinen zu verbessern und Prozessabläufe zu optimieren. Einem intelli-

genten Datenmanagement kommt innerhalb eines solchen Teleservice-Systems eine hohe

Bedeutung zu.

I.2 Aufgabenstellung und Zielsetzung

Das Ziel dieses Projektes bestand darin, ein Datenmanagementsystem zu entwickeln, das

es ermöglicht, den Kundennutzen beim Einsatz von Teleservice-Systemen bei mobilen

Arbeitsmaschinen zu fördern. Durch das Datenmanagement sollte eine bedarfsgerechte und

effiziente Übertragung von Maschinendaten ermöglicht werden. So sollen sich u. A. neue,

zustandsorientierte Instandhaltungsstrategien realisieren lassen, was an exemplarisch

ausgewählten Maschinenbaugruppen nachzuweisen war. Voll ausgenutzte Verschleiß-

potenziale und zustandsorientierte Instandhaltungsstrategien fördern auf der einen Seite

eine nachhaltige Produktion von qualitativ hochwertigen Lebensmitteln. Auf der anderen

Seite stellen sie eine wichtige Grundlage für attraktive Dienstleistungsangebote der Her-

steller und Instandhalter an die Maschinenbetreiber dar. Bei den internetgestützt ablaufen-

I Kurzdarstellung des Forschungsvorhabens 2

den Serviceprozessen, die im Rahmen von DAMIT entwickelt wurden, lag ein besonderer

Fokus darauf, alle Prozessbeteiligten - vom Betreiber über den Instandhalter bis zum Her-

steller - einbinden zu können. Dies trägt u. A. zur Sicherung der Arbeitsplätze in zahlreichen

kleinen Unternehmen in ländlichen Räumen bei. Auch bei der Unterstützung von komplexen

Logistikprozessen sollte das entwickelte Datenmanagementsystem nutzbringend eingesetzt

werden können, um die Wertschöpfung aller Prozessbeteiligten zu sichern.

I.3 Planung und Ablauf des Vorhabens

Zu Beginn des Projektes wurden verschiedene Maschinenbaugruppen exemplarisch

ausgewählt, für die dann systematisch zustandsabhängige Instandhaltungsstrategien ent-

wickelt wurden. Als Basis für die Entwicklung der modularen Softwarearchitektur des

Datenmanagementsystems und der zugehörigen flexiblen Kommunikationsstruktur wurden

zu Projektbeginn zwei unterschiedliche Hardwareplattformen ausgewählt, um die geforderte

Portierbarkeit der Software zu berücksichtigen. Die einzelnen Elemente des Daten-

managementsystems wurden während der Projektlaufzeit in Kooperation bzw. in enger

Abstimmung der beteiligten Projektpartner entwickelt, zum Ende des Projektes zu lauf-

fähigen Beispielanwendungen zusammengeführt und im Rahmen des Abschlussworkshops

den interessierten Besuchern demonstriert.

I.4 Stand der Wissenschaft und Technik zu Projektbeginn

In den vergangenen Jahren war die Landtechnikbranche gekennzeichnet durch einen Trend

zu leistungsfähigeren Maschinen mit erhöhten Durchsatzleistungen und hochspezialisierten

technischen Ausstattungen. Insbesondere bei Maschinen, die im Saisoneinsatz nur eine

begrenzte Zeit im Jahr betrieben werden wie Mähdrescher, Feldhäcksler, Kartoffel- oder

Rübenroder, erwarten die Kunden entsprechend hohe Maschinenlaufzeiten und Verfüg-

barkeiten sowie eine schnelle Behebung von Störfällen. Dieses erforderte eine hohe

Kompetenz in der Betreuung der Maschinen und eine schnelle Reaktionsfähigkeit des

Kundenservice, um den Service lokal verfügbar zu machen. Insbesondere Systeme und

Konzepte für Teleservice-Lösungen können diese Dienstleistungs- und Servicestrukturen

unterstützen. Die Vorteile dieser Systeme sind vielfältig:

• Fernwartung und -diagnose

• Ferninbetriebnahme und -manipulation

• Prozess- und Maschinenmodellierung

• Aufbau kundenorientierter Dienstleistungen

I Kurzdarstellung des Forschungsvorhabens 3

• Schadensfrüherkennung

• Verschleißüberwachung

• Logbuchfunktion/Crash-Recording

• Online Software Updates

Für stationäre Maschinen und Anlagen existieren bereits seit mehreren Jahren Anwen-

dungen für Teleservice-Systeme. Darauf aufbauend wurden verschiedene Projekte und

Untersuchungen durchgeführt, welche die Umsetzung der Systeme für mobile Arbeits-

maschinen zum Ziel hatten. [Lei03], [Tes00], [Mum02], [Har97], [Ven03], [Bec99], [Die97],

[Dre96], [Kau97], [Kra00], [Mat00], [Rei99], [Sch01], [Wes98]

Eines dieser Projekte war TesMa (Teleservice für mobile Maschinen und Anlagen). [Tes00]

Der Schwerpunkt lag bei diesem Projekt vor allem im Bereich der Baumaschinen. Die

Ergebnisse dieses Projektes bildeten eine Basis für Anwendungen bei Landmaschinen, es

ist jedoch nicht ohne weiteres möglich, die Ergebnisse von den Bau- zu den Landmaschinen

zu transferieren. Gründe hierfür sind unterschiedliche Elektronikkonzepte und die Tatsache,

dass Baumaschinen den Vorteil haben, dass Sie meistens quasi-stationär arbeiten, also

einen festgelegten und überschaubaren Baustellenbereich nicht verlassen. Dieses stellt eine

erhebliche Erleichterung für den Aufbau einer Kommunikation dar. Ein anderes Verbund-

projekt, an dem Hersteller mobiler Arbeitsmaschinen (Baumaschinen) beteiligt waren, war

das Projekt „mumasy“ (Multimediales Maschineninformationssystem). [Mum02] Dieses

Projekt hatte zum Ziel, ein branchenübergreifendes und konsistentes Modell für den

Datenaustausch zu entwickeln. Auch hier kam es zu dem Effekt, dass eine Anwendung, die

im stationären Anlagenbau einwandfrei funktioniert, für den echten mobilen Einsatz, vor

allem im ländlichen Bereich, nur bedingt geeignet ist.

In weiteren Projekten unter Leitung des Instituts für Landmaschinen und Fluidtechnik (ILF)

wurden die Grundlagen für Teleservice-Lösungen für Landmaschinen entwickelt. In einem

vom BMBF geförderten Verbundprojekt wurde ein „Leitfaden für eine gesamtheitliche

Teleservice(TS)-Lösung in der Landmaschinenbranche“ erstellt. [Lei03] Dieser Leitfaden gibt

Hinweise und Anregungen für die Einführung von Teleservice-Systemen und soll bestehende

Unsicherheiten und Informationsdefizite abbauen. Folgende Punkte werden in diesem

Leitfaden erläutert:

• Aufbau eines TS-Systems und Einbindung der neu geschaffenen Prozesse in die bestehenden Aufbau- und Ablauforganisationen der Unternehmen. Entwicklung der Datenmodelle, Customizing der Module und Integration der TS-Datenbanken und Strukturen in existierende ERP Systeme der Unternehmen. [Löh03a]

I Kurzdarstellung des Forschungsvorhabens 4

• Anwendungsbeispiel zur statistischen Auswertung der Informationen im After-Sales-Service. Welche Quellen müssen neben den Maschinendaten noch genutzt werden und welche Adressaten können und sollen mit den gewonnenen Informationen versorgt werden? Wie können die Informationen maschinenspezifisch und maschinenübergreifend ausgewertet und zur Verfügung gestellt werden? [Ahr03]

• Anwendungsbeispiel zur SMS-Datenerfassung. Wie kann eine Datenkommunikation zwischen einer mobilen landwirtschaftlichen Maschine und einer Service-Leitstelle unter Ausnutzung des Short Message Service (SMS) aufgebaut werden? Welche Elemente und welche Software werden benötigt und wie hoch ist die Informationsdichte? Darüber hinaus wurde untersucht, wie viel Informationen in einer SMS (160 ASCII-Zeichen) unter Ausnutzung einer optimalen Codierung übermittelt werden können. [Sch03]

• Anwendungsbeispiel zur Onlinediagnose einer mobilen Arbeitsmaschine. Am Beispiel eines selbstfahrenden Kartoffelroders wurde gezeigt, wie eine Diagnose an der Maschine über eine GSM-Verbindung durchgeführt werden kann. Mit dem entwickelten System kann eine Verbindung zur Maschine aufgebaut werden und der Servicetechniker kann von einem beliebigen Ort aus mit dem Bediener der Maschine zusammen eine Diagnose durchführen. [Möl03]

• Fehlerlokalisierung und Schadensdiagnostik an einer mobilen Arbeitsmaschine. Es wurden verschiedene Möglichkeiten der Fehlerlokalisierung an der Maschine und der Visualisierung des Zustands entwickelt. Dazu wurden klassische Verfahren genau so wie Expertensysteme verwendet. Es wurde gezeigt, dass durch geeignete Lern- und Analysemethoden eine automatisierte Zustandsbestimmung der Maschinen möglich ist. Ein entwickeltes Java-Applet ermöglicht die Visualisierung der Maschinendaten und -zustände an beliebigen Orten. [Kra03]

• Es wurden Möglichkeiten aufgezeigt, wie die Instandhaltung landtechnischer Arbeitsmittel verbessert werden kann. Welche Formen der Abnutzung und des Verschleißes liegen vor und mit welchen Maßnahmen sollten diesen in der Instandhaltung begegnet werden? [Löh03b]

• Die rechtlichen Aspekte des Teleservice. Welche gesetzlichen Auflagen existieren bei fernerbrachten Dienstleistungen? Welche juristischen Bedingungen sind zu erfüllen, um die Maschinendaten zu versenden und auszuwerten? Wer „besitzt“ die Daten und wer darf die Informationen nutzen? [Pla03]

• Gestaltungsempfehlungen für Teleservice-Systeme in der Landmaschinenbranche. Aus den untersuchten Bereichen und den Erfahrungen des Projektes wurden Empfehlungen zur Gestaltung bei Planung und Entwicklung hinsichtlich der Punkte Strategie, Organisation, Personal und Technik gegeben. [Div03]

I Kurzdarstellung des Forschungsvorhabens 5

Die Wirtschaftlichkeit von Teleservice-Systemen für mobile Arbeitsmaschinen war Gegen-

stand mehrerer Untersuchungen. Eine konkrete monetäre Bezifferung der Vorteile ist

praktisch nicht möglich, da die Entwicklung und die Einsatzfelder jeder Maschine individuell

sind. Somit ist es nicht möglich, verlässliche Beispielrechnungen zu erstellen. Generell ist

jedoch zu erwarten, dass sich durch ein Teleservice-System sowohl beim Landwirt als auch

beim Maschinenhersteller Einsparungen einstellen werden. [Har03], [Kra00] Trotz der über-

durchschnittlichen Vorteilhaftigkeit der Innovation im Gegensatz zu anderen kaufmännischen

und technischen Innovationen sind bisher relativ wenig Systeme implementiert worden.

Diese Zurückhaltung ist im stationären Maschinen- und Anlagenbau analog zu finden.

Borgmeier [Bor02] hat dieses Phänomen in einer empirischen Analyse nachgewiesen und

darauf aufbauend ein Diffusionsparadoxon entwickelt. Darüber hinaus werden Strategien

und Empfehlungen entwickelt wie diese Lücke geschlossen werden kann. Dazu gehören

u. a. Kompatibilitätsstrategien, die Entwicklung von Schnittstellen, die Förderung der Ver-

netzung, stabile Kommunikation und die Entwicklung verfeinerter Diagnoseverfahren.

Für die Instandhaltung gibt es grundsätzlich mehrere Strategien, die in der im Jahre 2003

überarbeitet erschienenen DIN 31051 aufgeführt sind. Generell gibt es die Möglichkeit,

reaktiv, zeitabhängig, zustandsorientiert oder lebensdauerorientiert zu verfahren. Die

Instandhaltung landtechnischer Arbeitsmittel war Gegenstand mehrerer Untersuchungen mit

unterschiedlichen Zielrichtungen. Beispielhaft seien hier [Bru00], [Löh03b], [Eic00a], [Eic00b]

genannt. Für die Zuordnung von Instandhaltungsstrategien zu den spezifischen Baugruppen

und Komponenten existieren jedoch noch keine Erfahrungen und Untersuchungen.

Die technische Realisierung der Datenreduktion auf der Maschine kann durch adaptive

Messungen, Expertensysteme oder statistische Diagnosemethoden erfolgen. Adaptive

Messungen (alternative Bezeichnung sind Transitional Recording oder ereignisorientierte

Messdatenerfassung) legen ein Toleranzband fest, welches zur Auslösung einer Messung

verlassen werden muss, um die Speicherung eines Datums zu verursachen. Alle Daten

innerhalb dieses Bandes werden im Falle einer späteren Analyse interpoliert. [Keh01],

[Hil98], [Wie96], [Sch95], [Sch92], [Met92], [Mic83] Die für die Anwendung an den

Baugruppen mobiler Arbeitsmaschinen individuell zulässigen Grenzen sollen im Projekt

ermittelt werden.

Expertensysteme bieten die Möglichkeit, Datensätze automatisiert in definierte Klassen

einzuordnen. Insbesondere Künstliche Neuronale Netze, Fuzzy-Logic sowie deren

Kombination in Neuro-Fuzzy-Systemen haben sich als zuverlässige Instrumente erwiesen,

die auch bei Ausreißern oder außergewöhnlichen Betriebszuständen ein robustes Verhalten

I Kurzdarstellung des Forschungsvorhabens 6

zeigen. Voraussetzung ist die vorherige Lernphase dieser Verfahren, die mit Trainingsdaten

durchgeführt werden muss. [Abe01], [Wit01], [Ali00], [Wit00], [Bot98], [Zak98], [Bro97],

[Sch97], [Nau96], [Pup96], [Bot95], [Pea95], [Pup91], [Jac87] Statistische Methoden wie das

auf dem Bayes-Theorem basierende Verfahren nach Dempster-Shafer können eine

Zuordnung/Diagnose von Datensätzen aufgrund von Wahrscheinlichkeiten durchführen. Die

Methode nach Dempster-Shafer bietet dabei den Vorteil, dass für jede Zuordnung/Diagnose

ein Sicherheitsintervall mit bestimmt wird. Dieses Intervall wird bei steigenden Datenmengen

und fundierteren Wahrscheinlichkeiten kleiner bzw. bei kleinen Datenmengen größer. Die

Güte einer Vorverarbeitung/Reduktion der Daten wird also mit angegeben wobei sich diese

Güte mit steigender Erfahrung verbessert. [Hal01], [Mah01], [Hal00], [Kla99], [Sto99],

[Var97], [Hal92], [Wal90] Auf Basis der Ergebnisse und Erfahrungen dieser Methoden

können die Abläufe der Instandhaltung ermittelt werden. Hier findet eine Kombination mit den

klassischen Verfahren der Instandhaltung statt. [Gri99], [Löh03b]

Bisher verfügbare Telematiklösungen beschränken sich häufig auf lediglich ein Kommunika-

tionsmedium, bei den Landmaschinen meist SMS-Versand oder GSM. Dem gegenüber steht

der Trend, in mobilen Geräten immer mehr drahtlose Schnittstellen mit unterschiedlicher

Bandbreite und Abdeckung zu integrieren. Die Nutzung aller verfügbaren Schnittstellen für

eine Telematiklösung stellt ungleich höhere Anforderungen an das Daten-, Verbindungs- und

Kommunikationsmanagement. [Krü00], [KTB00], [Ets00], [Aue93] Abhängig von der Wichtig-

keit der Daten muss die Maschine das passende Kommunikationsmedium auswählen. Ist

das Medium gerade nicht verfügbar, müssen die Daten zwischengespeichert und zum

nächstmöglichen Zeitpunkt übertragen werden. Ist die Bandbreite des Mediums zu gering,

kann eine gezielte Reduktion der Daten eine Übertragung über dieses Medium trotzdem

möglich machen. Tabelle I.1 gibt eine Übersicht über verfügbare drahtlose terrestrische

Kommunikationsschnittstellen.

Tabelle I.1: Vergleich verschiedener Kommunikationsschnittstellen

Medium Bandbreite Abdeckung Qualität Kosten

SMS < 1 kBit/s Sehr hoch Niedrig Hoch

Betriebsfunk/GSM 9,6 kBit/s Hoch Hoch Hoch

GPRS 56,8 kBit/s Mittel Hoch Hoch

Bluetooth 768 kBit/s 10 m Hoch Gering

WLAN 54 MBit/s Max. 300 m Hoch Gering

I Kurzdarstellung des Forschungsvorhabens 7

Durch die Nutzung der Positions- und Bewegungsinformationen (GPS) kann die

Zuverlässigkeit des Verbindungsmanagements erhöht werden. Verbindungen können

kontrolliert beendet werden, bevor sich die Maschine aus dem abgedeckten Gebiet bewegt,

ebenso wie die Maschine beispielsweise eine WLAN-Verbindung an bestimmten Orten

aufbauen kann und gesammelte Daten unter Ausnutzung der hohen Bandbreite und

geringen Kommunikationskosten automatisch übertragen kann. Voraussetzung dafür ist das

Vorhandensein der Abdeckungsdaten, die aber bei Betrieb der Maschine in festen Gebieten

auch durch die Maschine selbst ermittelt und dokumentiert werden können. Es gibt

zahlreiche Geräte, welche verschiedene Kommunikationsmedien unterstützen (z. B.

moderne Mobiltelefone), jedoch existieren keine Lösungen, die eine automatische Auswahl

treffen und das Verbindungsmanagement übernehmen.

AgroXML ist ein Datenstandard, der vom KTBL (Kuratorium für Technik und Bauwesen in

der Landwirtschaft) zusammen mit der Fachhochschule Bingen zum Datenaustausch

speziell im Agrarsektor entwickelt wird. Es soll dabei eine Datenkommunikation entlang der

Produktions- und Lieferkette gewährleistet werden, bei welcher die Daten derart

bereitgestellt werden können, dass sie jederzeit ohne zusätzliche Aufbereitung zur

Verfügung stehen und nach einmaliger Erfassung jederzeit von verschiedenen Programmen

nutzbar sind. Ein entscheidendes Merkmal ist dabei eine Plattformunabhängigkeit, die es

erlaubt, zwischen Geräten verschiedener Hersteller zu kommunizieren, wenn sie über eine

entsprechende Schnittstelle verfügen. Unterschiedlichste Software soll auf die Daten

zugreifen können, ohne dass der Nutzer sich um die Formatierung kümmern muss. Damit

bleibt es dem Landwirt erspart, die gleichen Daten in verschiedene Formulare in

unterschiedlichen Formaten einzugeben. Eine Verringerung der Datenredundanz führt somit

zu einer Zeit- und Kostenersparnis in der Verwaltung obwohl die Dokumentationspflichten

stetig zunehmen. Die Sprache AgroXML ist frei verfügbar und damit ohne Zusatzkosten für

Lizenzen implementierbar. Zur Verarbeitung dokumentationspflichtiger Lebensmittel ist eine

entsprechende Informations- und Kommunikationsstruktur notwendig, die durch den Einsatz

von AgroXML bereitgestellt werden kann. Dabei gewährleistet der Zugriff auf alle relevanten

Informationsstellen und Datenbanken die Möglichkeit einer einfachen benutzerangepassten

Dokumentation.

I Kurzdarstellung des Forschungsvorhabens 8

I.5 Zusammenarbeit mit anderen Stellen

Das dieses Verbundprojekt bearbeitende Team setzte sich aus einer Forschungseinrichtung,

einem mittelständischen Unternehmen aus dem Bereich der Informationstechnik sowie zwei

Unternehmen der Landtechnik zusammen, die ebenfalls mittelständisch organisiert sind.

Als Forschungseinrichtung war das Institut für Landmaschinen und Fluidtechnik (ILF) der

Technischen Universität Braunschweig im Wesentlichen für die Entwicklung von

Datenkompressionsmethoden sowie für die Koordination des Verbundprojektes verant-

wortlich. Zudem unterstützte das ILF die Landtechnikunternehmen Claas und Grimme bei

der Entwicklung und Umsetzung von Instandhaltungsstrategien. Claas war darüber hinaus

zuständig für die Modellierung von Serviceprozessen und Grimme für die Modellierung des

Logistikprozesses bei der Zuckerrübenernte. Die Firma eck*cellent IT (zu Projektbeginn

noch Lineas Project Services) war im Rahmen des Projektes verantwortlich für den Aufbau

einer modularen Softwarearchitektur und einer flexiblen Kommunikationsstruktur.

II.1 Zustandsüberwachung exemplarischer Baugruppen 9

II Eingehende Darstellung des Forschungsvorhabens

In den nachfolgenden Abschnitten werden verschiedene Elemente beschrieben, die

Bestandteil des entwickelten Datenmanagements sind oder eine wichtige Voraussetzung

dafür darstellen.

II.1 Zustandsüberwachung exemplarischer Baugruppen

Der folgende Abschnitt dokumentiert den Einsatz von Condition Monitoring Systemen an

selbstfahrenden Erntemaschinen. Am Beispiel ausgewählter Baugruppen wurden Konzepte

entwickelt, die Anwendung an Prüfständen und Feldversuchen erprobt und wichtige

Erkenntnisse für die zukünftige Gestaltung von Condition Monitoring Systemen abgeleitet.

II.1.1 Voraussetzungen für ein Condition Monitoring

II.1.1.1 Instandhaltungsstrategien

Die Instandhaltungsstrategie bestimmt den Zeitpunkt, an dem eine Baugruppe aufgrund von

Verschleiß ausgetauscht wird. Dazu existieren in der Praxis verschiedene Strategien.

Die reaktive Instandhaltung basiert auf dem Austausch einer Baugruppe bei Ausfall. Dadurch

wird die Baugruppen-Standzeit vollständig ausgenutzt, es werden somit keine Ressourcen

verschwendet. Da der Ausfall der Baugruppe im Regelfall nicht vorhersehbar ist, führen der

spontane Ausfall und die nachfolgende Instandhaltung zu einem Stillstand der Maschine,

was sich in einer geringen Maschinenverfügbarkeit widerspiegelt.

Die präventive Instandhaltung verfolgt den Ansatz, eine Baugruppe in festen Intervallen zu

wechseln. Dieses Intervall wird so gewählt, dass unter regulären Bedingungen kein

Verschleiß-Ausfall der Baugruppe zwischen den Wechselintervallen auftritt. Das hat zur

Folge, dass bei geringerer Belastung in einem Wechselintervall eine Baugruppe mit –zum

Teil erheblicher- Reststandzeit ausgewechselt wird. Diese Verschwendung von Ressourcen

führt zu erhöhten Instandhaltungskosten. Im Umkehrschluss steigt die Maschinenver-

fügbarkeit, weil zwischen den Wechselintervallen kein Instandhaltungsaufwand entsteht.

Gerade im Bereich selbstfahrender mobiler Arbeitsmaschinen wird heutzutage eine hohe

Maschinenverfügbarkeit gefordert, um die Erntefenster zu verkürzen. Dies führt zur

verstärkten Anwendung der präventiven Instandhaltungsstrategie, die zur Erhöhung der

Instandhaltungskosten führt.

II.1 Zustandsüberwachung exemplarischer Baugruppen 10

Bild II.1: Zusammenhang von Instandhaltungskosten zu Maschinenverfügbarkeit

Die Maschinenverfügbarkeit steigt in einem weiten Bereich nahezu linear mit den

eingesetzten Instandhaltungskosten (siehe Bild II.1). Ein Ansatz, diesen linearen

Zusammenhang von Maschinenverfügbarkeit zu Instandhaltungskosten zu verlassen führt

über die zustandsbasierte Instandhaltung. Sie basiert auf der kontinuierlichen Ermittlung des

aktuellen Verschleißzustandes und Baugruppen-Tausch bei Bedarf. Somit werden Bau-

gruppen-Reststandzeiten optimal ausgenutzt. Um gleichzeitig eine hohe Maschinenver-

fügbarkeit zu gewährleisten, muss die Instandhaltung planbar sein, um sie in Maschinen-

stillstandszeiten durchführen zu können. Dazu ist es notwendig, aus dem erfassten,

aktuellen Verschleißzustand einer Baugruppe sowie dem bekannten Verschleißverhalten

eine Prognose der Reststandzeit zu ermitteln. Diese Zustandsüberwachung bezeichnet man

als Condition Monitoring.

II.1.1.1.1 Messbarkeit des Verschleißzustandes

Eine wesentliche Voraussetzung für Condition Monitoring liegt in der kontinuierlichen

Erfassung des aktuellen Verschleißzustandes. Häufig lässt sich der Verschleiß einer

Baugruppe jedoch nicht direkt messen und muss indirekt mit Hilfe einer Zustandsgröße

ermittelt werden. Bei deren Auswahl wird häufig auf Größen zurückgegriffen, die bereits

sensorisch erfasst werden. Zusätzliche Sensoren erhöhen die Kosten des Condition

Monitoring Systems und reduzieren das dadurch gewonnene Einsparungspotenzial.

Instandhaltungs- kosten

Maschinen- verfügbarkeit

Präventive Instandhaltung

Zustandsbasierte Instandhaltung

Reaktive Instandhaltung

II.1 Zustandsüberwachung exemplarischer Baugruppen 11

II.1.1.1.2 Interpretierbarkeit der Zustandsgröße

Die zweite Voraussetzung für Condition Monitoring liegt in der Interpretierbarkeit der

Zustandsgröße. Im Allgemeinen ist die gemessene Zustandsgröße nicht linear mit dem

Verschleißzustand verknüpft. Heutzutage wird der Verschleißzustand häufig rein visuell von

Experten bestimmt. Die objektive Erfassung des aktuellen Verschleißzustandes aus diesem

Expertenwissen ist damit problematisch.

II.1.1.1.3 Prognostizierbarkeit des Verschleißverhaltens

Zusätzlich zur objektiven Quantifizierung des aktuellen Verschleißzustandes muss man vom

aktuellen Verschleißzustand den Zeitpunkt des Baugruppenausfalls hochrechnen. Dazu

benötigt man Wissen über den Verschleißverlauf über der Zeit. Dieser Zusammenhang ist

jedoch häufig stark abhängig von äußeren Einflussgrößen. Die sichere Ermittlung des Ver-

schleißverhaltens ist wegen der Vielzahl der – oft nicht offensichtlichen – Randbedingungen

sowie der üblicherweise langen Baugruppenstandzeiten somit schwierig.

II.1.1.2 Beispielbaugruppe Walzengang

Als erste Beispielbaugruppe wurde der Walzengang eines Rübenroders gewählt. Dieser Teil

der Reinigungseinrichtung besteht aus Reinigungswalzen, welche die Rüben von

anhängender Erde, Steinen und Kluten befreien (siehe Bild II.2). Nachdem die Rodeschare

die Rüben ausgegraben haben, werden sie auf ein Siebband übergeben, welches die Rüben

zur Reinigungseinrichtung fördert. Starker Verschleiß an den Reinigungswalzen führt zu

schlechter Abreinigung des Erntegutes, was sich in einer verringerten Erntegutqualität

widerspiegelt.

Zur effektiveren Abreinigung arbeiten einige der hydraulisch angetriebenen Reinigungs-

walzen gegenläufig: zwei benachbarte Walzen „ziehen“ Verunreinigungen aus dem

Erntegutstrom. Gerät jedoch ein Stein in den Spalt zwischen den gegenläufigen

Reinigungswalzen, besteht die Gefahr, dass sich dieser verklemmt. Der eingeklemmte Stein

erzeugt Riefen auf den Reinigungswalzen und beschädigt die aufgebrachten

Reinigungslippen. Durch den Steinklemmer steigt der Druck in der Zuleitung des

antreibenden Hydraulikmotors. Dieser wird mit Hilfe eines Drucksensors überwacht. Bei

sprunghaftem Anstieg wird die Drehrichtung der Walzen reversiert, um den eingeklemmten

Stein auszuwerfen.

II.1 Zustandsüberwachung exemplarischer Baugruppen 12

Bild II.2: Walzengang mit Reinigungswalzen am Rübenroder

Die bisherige Instandhaltungsstrategie für die Reinigungswalzen ist bereits zustandsbasiert.

Vor Beginn jeder Erntekampagne wird der Walzengang von Servicemonteuren mit

Expertenwissen begutachtet und bewertet, ob die Walzen eine weitere Rodekampagne

überstehen oder ob die Reinigungsleistung durch die Beschädigung der Reinigungslippen zu

sehr verringert ist. Ziel ist es, die Begutachtung einzusparen und ein automatisiertes

Condition Monitoring System zu entwickeln.

Um ein kostenneutrales Condition Monitoring für den Walzengang zu realisieren, wird die

Zahl der Steinklemmer als Zustandsgröße für den Verschleißzustand gewählt.

In der ersten Kampagne zeigte die Versuchsmaschine wenig Steinklemmer, weil sie

aufgrund der guten Witterung wenig belastet war und zusätzlich in steinarmen Böden

eingesetzt wurde. Signifikanter Verschleiß am Walzengang war kaum feststellbar. In der

zweiten und dritten Kampagne war - trotz des Einsatzes der Maschine auf steinigen Böden -

der Verschleiß der Walzen auch in dieser Maschine so gering, dass kein Ausfall der

Baugruppe bis zum Projektende zu erwarten war. Zudem zeigte sich die objektive

Quantifizierung des aktuellen Verschleißzustandes trotz des Expertenwissens als schwierig.

Bei der Begutachtung des Walzenganges im Vorfeld einer Kampagne wird bisher lediglich

bewertet, ob die Rest-Standzeit der Walzen für den Einsatz in einer weiteren Erntekampagne

ausreicht. Eine Quantifizierung des Verschleißzustandes findet nicht statt.

Die Interpretierbarkeit der Zustandsgröße (die Anzahl der Steinklemmer) erschwert sich

dadurch, dass zwei Kategorien von Steinklemmern existieren. Bei einem einfachen

II.1 Zustandsüberwachung exemplarischer Baugruppen 13

Steinklemmer löst sich der Stein beim einmaligen Reversieren der Walzen. Sitzt ein Stein

nach dreimaligem Reversieren noch immer im Spalt zwischen den Reinigungswalzen, spricht

man von einem schweren Steinklemmer. Dem Fahrer wird durch eine Warnmeldung

angezeigt, dass der Stein manuell entfernt werden muss. Ein schwerer Steinklemmer

erzeugt erheblich mehr Verschleiß als drei einfache Steinklemmer, die die gleiche Zahl an

Reversiervorgängen hervorrufen. Die Ermittlung des Verschleißverlaufes über der Zeit

erschwert sich darum, da das Verhältnis von einfachen zu schweren Steinklemmern stark

schwankt.

II.1.1.3 Beispielbaugruppe Hydrauliköl

Die zweite Beispielbaugruppe für die zustandsbasierte Instandhaltung ist das Hydrauliköl. Es

ist am selbstfahrenden Rübenroder von zentraler Bedeutung, weil es zur Energieübertragung

sowohl für den hydrostatischen Fahrantrieb als auch für die Rodetechnik dient. 1/3 der

insgesamt 450 Liter Hydrauliköl befindet sich ständig im Hydrauliksystem der Maschine,

während die restlichen 300 Liter als Tankinhalt vorgehalten werden. Das komplexe

Hydrauliksystem besteht aus 17 Pumpen, ca. 40 Motoren und etwa 50 Zylindern.

Bislang wird beim Hydrauliköl die präventive Instandhaltungsstrategie angewandt. Das

Hydrauliköl wird jährlich bzw. nach 1000 Betriebsstunden gewechselt. Der Grund für das

kurze Wechselintervall ist nicht der Verschleiß des Hydrauliköls selbst, sondern die Bildung

von Kondenswasser an den Wänden des Tanks in der langen Standzeit zwischen den

Kampagnen. Eine Voraussetzung für die Ausnutzung der gesamten Ölstandzeit war der

Einbau eines Feinstfilters, der in der Lage ist, mit einem Filterelement bis zu 500 ml Wasser

aus dem Öl herauszufiltern.

Beim Verschleiß von Hydrauliköl werden die Moleküle aufgespalten und es entsteht Säure.

Bei der Neutralisation der entstandenen Säuremoleküle werden Additive abgebaut. Sind die

Additive vollständig abgebaut, steigt der Säureanteil im Öl an. Die Total Asset Number TAN

quantifiziert den Säuregehalt im Öl. Mit dem Säuregehalt steigt auch die Leitfähigkeit des

Fluids. Zusätzlich ändert sich die Kernviskosität. Als Kernviskosität bezeichnet man die

temperaturkompensierte Viskosität des Fluids.

Zur Erfassung des Hydrauliköl-Verschleißes eignet sich keiner der bisher verbauten

Sensoren. Darum wurde die Maschine mit einem zusätzlichen Ölzustandssensor

ausgestattet, der bislang in stationären Anlagen verwendet wird. Er nimmt neben der

relativen Feuchte die Öltemperatur, die relative Dielektrizitätskonstante (entspricht der

Leitfähigkeit) und die relative Kern-Viskosität auf. Die relativen Ausgangsgrößen des

II.1 Zustandsüberwachung exemplarischer Baugruppen 14

Sensors basieren auf Referenzwerten, die innerhalb der ersten 100 Betriebsstunden

aufgenommen werden. Innerhalb der ersten und zweiten Versuchskampagne wurden

zusätzlich zur Ölverschleiß-Bestimmung mit dem Ölzustandssensor Laboruntersuchungen

zur Ermittlung des Hydrauliköl-Verschleißes durchgeführt. Sowohl an der wenig belasteten

Maschine der ersten Versuchskampagne als auch in der stärker belasteten Maschine des

zweiten Versuchszeitraums zeigten die Laboruntersuchungen keinen nennenswerten

Verschleiß.

Die Kern-Viskosität wird in stationären Anlagen als hauptsächliches Verschleißkriterium

verwendet. Zu Beginn der zweiten Versuchskampagne zeigte sich jedoch, dass durch die

lange Standzeit zwischen den Kampagnen und den hohen Additivgehalt das zur

Viskositätsmessung verwendete Sensorelement verklebt und die Messwerte damit verfälscht

werden. Die Dielektrizitätskonstante ist messtechnisch gut erfassbar. Zudem kann bei

Ausschluss der relativen Kernviskosität aus dem Messverfahren die Referenzzeit von

100 Betriebsstunden auf 5 bis 10 Stunden verringert werden, weil die aufwändige Ermittlung

des Viskositäts-Temperatur-Zusammenhangs entfällt.

Die Dielektrizitätskonstante verhält sich weitestgehend proportional zur TAN. Der

Schwellwert, an dem das Hydrauliköl vollständig verschlissen ist, wird von keinem

Ölhersteller exakt beziffert. Der Hersteller des Ölzustandssensors gibt als Faustwert eine

Veränderung der Dielektrizitätskonstante von 20 % an. Mit diesem Grenzwert ist eine

Quantifizierung des aktuellen Hydraulikölverschleißes realisierbar.

Bild II.3 zeigt den theoretischen Verschleißverlauf des Hydrauliköls. Im flachen, geraden Teil

der Verschleißkurve genügt der Additivanteil im Fluid noch aus, um die frei werdenden

Säuremoleküle zu neutralisieren. Der Säuregehalt, ausgedrückt über die TAN, bleibt nahezu

konstant. Sobald die Additive jedoch abgebaut sind, steigt die TAN exponentiell an.

Für die Prognostizierbarkeit einer Reststandzeit des Hydrauliköls muss man den funktionalen

Zusammenhang des Verschleißverhaltens über der Zeit kennen. Bild II.4 zeigt den Verlauf

der Dielektrizitätskonstante über der Zeit an zwei Versuchsmaschinen aus der dritten

Versuchskampagne. Die abgebildete Maschinenlaufzeit bei Maschine A beträgt 1050 Be-

triebsstunden, die Maschine B leistete im dargestellten Zeitraum 750 Betriebsstunden.

II.1 Zustandsüberwachung exemplarischer Baugruppen 15

Bild II.3: theoretisches Verschleißverhalten von Hydrauliköl

Das Bild II.4 zeigt, dass bei Maschine B bei etwa 720 Betriebsstunden der stark

exponentielle Teil der Kurven beginnt. Maschine A zeigt auch 300 Betriebsstunden später

noch keinen wesentlichen Ölverschleiß. Der Verlauf ist somit stark abhängig von weiteren

Umgebungsbedingungen. Für eine sichere Vorhersagbarkeit der Reststandzeit ist ein breiter

aufgestellter Test notwendig, in dem der Einfluss der Umgebungsbedingungen analysiert

werden muss. Die Quantifizierbarkeit des Hydraulikölverschleißes ist mit den Ergebnissen

des Projektes jedoch bereits jetzt realisierbar.

Maschine A

-30

-20

-10

0

10

20

30

40

Zeit

rela

tive

Wer

te [%

]

rel. Dielektrizität

Maschine B

-30

-20

-10

0

10

20

30

40

Zeit

rela

tive

Wer

te [%

]

rel. Dielektrizität

Bild II.4: Verlauf der Dielektrizitätskonstante für zwei verschiedene Versuchsmaschinen

TAN

twarn t

II.1 Zustandsüberwachung exemplarischer Baugruppen 16

II.1.2 Vorhersagbarkeit von Wartung und Instandhaltung

Wartung und Instandhaltung an selbstfahrenden Erntemaschinen wird für viele Bauteile und

Baugruppen bisher präventiv und/oder reaktiv betrieben. Das heißt entweder werden

Bauteile vor dem Ernteeinsatz aufgrund eingehender Prüfung als defekt erkannt und

ausgewechselt oder während des Einsatzes fallen Bauteile aus. Diese müssen dann

kurzfristig ersetzt werden. Wartungsarbeiten während der Hauptbetriebszeit stören den

Einsatz gleichermaßen.

Eine pauschale Wartungs- und Instandhaltungsstrategie aufgrund einfacher Bezugsgrößen,

wie z. B. geleisteter Arbeitsstunden, ist nicht immer optimal. Dies liegt auch daran, dass

verschiedene und teilweise unbekannte Einflussfaktoren mit bedeutenden Auswirkungen auf

die Nutzungsdauer der Verschleißbauteile und die Standzeit wartungsintensiver Bauteile

nicht erfasst werden. Die Zusammenhänge zwischen den Einflussgrößen und der

Nutzungsdauer bzw. der Standzeit sind teilweise qualitativ bekannt. Ein direkter quantitativer

Bezug fehlt allerdings. Unter wirtschaftlichen Gesichtspunkten erscheint es an dieser Stelle

sinnvoller, Kriterien zu ermitteln, aufgrund derer sich der Zustand der zu überwachenden

Bauteile beschreiben lässt.

Anhand zweier exemplarischer Baugruppen des Mähdreschers werden zwei verschiedene

Ansätze vorgestellt, welche aufzeigen, wie die Vorhersage von Wartung und Instandhaltung

an selbstfahrenden Erntemaschinen funktionieren kann.

II.1.2.1 Kettenlängung Schrägförderer

II.1.2.1.1 Einleitung

Die Kettenlängung im Schrägförderer des Mähdreschers ist für die Maschinenwartung und

Instandhaltung ein wichtiger und entscheidender Faktor. Bild II.5 zeigt die Einzugsketten des

Schrägförderers im eingebauten Zustand.

Die Nutzung der Ketten über die Verschleißgrenze hinweg hat einen Ausfall der Kette zur

Folge und kann große Schäden und hohe Kosten in den nachfolgenden Baugruppen wie

Dreschwerk, Rotor oder Schüttler und Strohhäcksler verursachen. Die Ausfallzeit der

Maschine ist dann entsprechend hoch. Andererseits erschwert die Anordnung von drei bis

vier parallel laufenden Ketten die Ermittlung der Verschleißlängung. Der Kontakt der Kette zu

verschiedensten Materialien wie z. B. Sand, Pflanzenteile, ölhaltige Körner, Wasser bei

II.1 Zustandsüberwachung exemplarischer Baugruppen 17

verschiedenen zu fördernden Korn-Strohgemischmengen hat weiterhin erheblichen Einfluss

auf den zeitlichen Verlauf der Längung. Dies stellt an die Ermittlung und Analyse eines

Verschleißwertes hinsichtlich Vorhersagbarkeit hohe Anforderungen.

Bild II.5: Einzugsketten am Schrägförderer

Aufgrund des mechanisch eindeutigen Verhaltens (die Kette kann immer nur länger werden)

wird der Ansatz verfolgt, den zeitlichen Verlauf der Messgröße mittels einer mathematischen

Funktion abzubilden und auf entsprechende Restlaufzeiten hin zu interpretieren. In Bild II.6

sind die qualitativen Verläufe zweier Funktionen dargestellt, die für die Beschreibung der

Kettenlängung als Ansätze dienten.

Bild II.6: Darstellung der Kettenlängung als Polynom

II.1 Zustandsüberwachung exemplarischer Baugruppen 18

II.1.2.1.2 Erkenntnisse anhand Prüfstandsuntersuchungen

Zur Validierung des Messverfahrens wurde die Kettenlängung zunächst an einem Prüfstand

ermittelt. In Bild II.7 ist die Versuchseinrichtung mit aufgebautem Schrägförderer zu sehen.

Bild II.7: Prüfstand zur Untersuchung der Schrägfördererketten

Zur eindeutigen Analyse der Daten wurden die Haupteinflussgrößen Drehzahl und Zugkraft

im Lasttrum der Ketten fest definiert und konstant gehalten. Alle weiteren o. g. Einflüsse

wurden in die Untersuchung nicht mit einbezogen.

Bild II.8 zeigt die ermittelte Kettenlängung eines Prüflaufes in Abhängigkeit der Prüfzeit. Es

kann festgestellt werden, dass sich die Daten mittels Regressionsanalyse eindeutig mathe-

matisch beschreiben lassen.

Bild II.8: Kettenlängung am Prüfstand

II.1 Zustandsüberwachung exemplarischer Baugruppen 19

Die für den Prüfstandslauf ermittelte Funktion mit einem Bestimmtheitsmaß von größer 0,998

zeigt eine hohe Übereinstimmung zum tatsächlichen Verlauf. Gleichzeitig ist dadurch eine

Prognose hinsichtlich des weiteren Verlaufes bei höheren Laufzeiten möglich. Zu

verschiedenen Laufzeiten werden zur Funktion a+bx+cx²+dx³ mittels Regressionsanalyse die

Parameter a, b, c, d ermittelt. Anschließend wird der Verlauf der Längung zu höheren

Laufzeiten berechnet. In Bild II.9 ist die Abweichung der berechneten Kettenlängung relativ

zu den tatsächlich ermittelten Werten dargestellt.

Bild II.9: Ermittelte Abweichungen

Es zeigt sich, dass für eine zuverlässige Prognose eine entsprechende Datenbasis

erforderlich ist. Diese liegt für diesen Prüflauf bei > 140 h Prüfdauer. Es wird auch deutlich,

dass die Analyse der Daten kontinuierlich fortgesetzt werden muss. D. h. die voraus-

sichtliche, verbleibende Laufzeit muss ständig mit den hinzugekommenen Messdaten

aktualisiert werden.

II.1.2.1.3 Abgleich mit Daten aus dem Ernteeinsatz

Um die Qualität der Daten unter realen Einsatzbedingungen (siehe Bild II.10) kennen zu

lernen, wird die Kettenlängung im Feldeinsatz zu verschiedenen Laufzeiten ermittelt. Zur

Ermittlung der Längung wird die gleiche Methode verwendet, wie bei den Prüfstands-

II.1 Zustandsüberwachung exemplarischer Baugruppen 20

versuchen. Die Auswertung der Daten zeigt einen ähnlichen Verlauf wie die Daten vom

Prüfstandslauf.

Bild II.10: Maisernte mit einem Mähdrescher vom Typ Lexion

Wechselnde Getreidearten, Standorte und Witterungsbedingungen scheinen weniger

Einfluss auf den Verlauf zu haben als zunächst angenommen. Auch hier finden sich hohe

Bestimmtheitsmaße von 0,999 zur ermittelten Funktion (Bild II.11).

Bild II.11: Kettenlängung im Feldeinsatz

Aufgrund dieser Ergebnisse lassen sich nun Meldungen definieren, mit denen eine

vorausschauende Wartung und Instandhaltung praktiziert werden kann:

1. bei jedem Motorstart wird ein Wert abgespeichert und die aktuelle Verschleißlängung

wird errechnet

2. ab 100 Arbeitsstunden werden mittels Regressionsanalyse vorrausichtliche Lauf-

zeiten für eine Kettenlängung von 1,5 %, 2,0 %, 2,5 % und 3 % berechnet

II.1 Zustandsüberwachung exemplarischer Baugruppen 21

Folgende Meldungen lassen sich bei entsprechender Längung generieren:

a) 1,5 %: Anzeige des aktuellen Wertes & Ketten müssen in xx h gekürzt werden

b) 2,0 %: Kette muss gekürzt werden

c) 2,5 %: voraussichtliche Restlaufzeit beträgt xx h (tägliche Aktualisierung erforderlich)

d) 3,0 %: Kette muss ausgetauscht werden

Somit stehen also dem Bediener und der betreuenden Werkstatt Informationen zur

Verfügung, mit denen notwendige Wartung und Ersatz des Bauteiles vorab mitgeteilt

werden. Erforderliche Arbeiten können koordiniert werden, so dass eine möglichst hohe

Maschinenverfügbarkeit erreicht wird. Schäden durch unzulässige Nutzung mit zu hohem

Verschleiß können so vermieden werden.

II.1.2.2 Luftfilterverschmutzung Dieselmotor

II.1.2.2.1 Einleitung

Der Luftfilter zur Säuberung der Verbrennungsluft für den Dieselmotor ist ein weiteres

Bauteil, welches eine zentrale Bedeutung für eine hohe Maschinenverfügbarkeit hat.

Gleichzeitig werden hier sehr hohe Anforderungen an Funktion und Standzeit gestellt. Staub

in der Umgebungsluft der Maschine ist verfahrenstechnisch bedingt fast immer vorhanden

und gleichzeitig die begrenzende Haupteinflussgröße für die Standzeit des Filterelements.

Unter Einsatzbedingungen wie in Bild II.12 zu sehen, wird der Luftfilter u. U. extrem

beansprucht. Hier kann es sein, dass Wartungsintervalle deutlich kürzer sind als unter

weniger staubigen Verhältnissen. Eine Wartung an dieser Stelle während des Einsatzes hat

ebenfalls Ausfallzeiten zur Folge, welche bei entsprechender vorsorglicher Wartung

vermieden werden können.

Ein Indikator für den Verschmutzungszustand ist der Unterdruck im Ansaugrohr zwischen

Dieselmotor und Filterelement. Diese Messgröße wird bei näherer Betrachtung aber noch

von weiteren Einflüssen, wie z. B. der Motordrehzahl und Motorauslastung wesentlich

beeinflusst. Vibrationen können am Filterelement einen Säuberungseffekt hervorrufen. Für

die zu interpretierende Messgröße „Unterdruck“ heißt das, dass sich das Messsignal nicht

immer direkt und eindeutig in Zusammenhang zur Verschmutzung bringen lässt. Sowohl

größere als auch kleinere Werte können gemessen werden, ohne dass sich der

Verschmutzungszustand des Filters geändert hat.

II.1 Zustandsüberwachung exemplarischer Baugruppen 22

Bild II.12: Getreideernte unter sehr staubigen Bedingungen

Unter diesen Voraussetzungen ist die Analyse des zeitlichen Verlaufes des Druckes nur mit

hohem Aufwand möglich. Die Auswertung der Messgröße mittels einer Klassierung und

Analyse der Anteile mit definierten Grenzwerten (siehe Bild II.13) bietet sich hier als

Alternative an.

Bild II.13: Bsp. Klassierung als Häufigkeit

Eine bereits bekannte und einfache Variante dieser Auswertung ist die heute angewendete

Grenzwertüberwachung in Form eines Druckschalters. Anhand eines Beispieles soll also

gezeigt werden, wie eine Auswertung klassierter Daten erfolgen kann und welche Aussagen

sich für eine Prognose von Wartung und Instandhaltung ableiten lassen.

II.1.2.2.2 Untersuchungen am Prüfstand

Der direkte Zeitbezug der klassierten Daten ist bei einer Häufigkeits- oder Verweildauer-

klassierung nicht mehr herzustellen. Zur anschließenden Interpretation ist es daher wichtig,

die Qualität der Messdaten sicherzustellen.

II.1 Zustandsüberwachung exemplarischer Baugruppen 23

Hauptaufgabe für die Untersuchungen am Prüfstand ist daher die Absicherung der

Genauigkeit und des Verhaltens bei unterschiedlichen Drücken. Dazu wurde der später im

Feld eingesetzte Sensor auf dem in Bild II.14 dargestellten Prüfstand in verschiedenen

Ansaugbedingungen getestet und mit einem Referenzsensor abgeglichen.

Bild II.14: Prüfstand Drucksensor

Der absolute Verlauf bei veränderten Luftansaugbedingungen zeigt ein Signal mit geringer

Streubreite. Der in Bild II.15 dargestellte Vergleich mit dem Referenzsensor zeigt ein

schmales Band. Eine Hysterese im Bereich der geforderten Genauigkeit ist nicht festgestellt

worden.

Bild II.15: Signalverlauf Drucksensor

II.1 Zustandsüberwachung exemplarischer Baugruppen 24

II.1.2.2.3 Auswertung der Erntedaten

Während der Getreide- und Maisernte 2008 wurde an einem Mähdrescher vom Typ

Lexion 600 der Unterdruck im Luftansaugrohr gemessen und als Verweildauerklassierung

abgelegt (Bild II.16). Nach Definition von Grenzwerten ist eine standardisierte Auswertung

der Daten möglich, gleichzeitig lassen sich die Daten so übersichtlich zusammenstellen.

Bild II.16: Klassierung und Auswertung

Regelmäßiges Auslesen und Zurücksetzen des Speichers während der Ernte ermöglichen

es, den Bezug zu Wartungs- und Instandhaltungsarbeiten herzustellen. Bild II.17 zeigt die zu

den Grenzwerten belegten Klassen in Abhängigkeit vom Datum. Als durchgängige

Markierung sind die Wartungs- und Instandhaltungsarbeiten eingetragen.

Folgende Meldungen lassen sich durch Analyse der Daten unter Berücksichtigung der

Einsatzbedingungen sowie der Wartungs- und Instandsetzungsarbeiten für eine

vorausschauende Filterwartung ableiten:

1. Wartungsempfehlung, wenn 1 % der Daten über 50 mbar liegen

2. Alarmmeldung, wenn 1 % der Daten über 55 mbar liegen

3. Filterwechsel, wenn bereits 10x gesäubert wurde und 1 % der Daten über 50 mbar

liegen

Die kontinuierliche Bewertung der Gesamtheit der Messdaten bietet also die Möglichkeit, den

Zustand des Filterelementes ständig zu aktualisieren und zu bewerten. Meldungen zur

erforderlichen Wartung können somit generiert werden und Wartung und Instandhaltung

lassen sich dementsprechend in den Tages- oder Wochenablauf einplanen.

II.1 Zustandsüberwachung exemplarischer Baugruppen 25

Bild II.17: Abgleich Auswertung Klassierung und Erntemeldungen

Das Filterelement ist in seiner Lebensdauer begrenzt. Durch Säuberung wird es nie den

Neuzustand erreichen und setzt sich somit immer weiter zu. Die aufgezeigte Methode der

Datenauswertung bietet hierfür einen weiteren Vorteil. Der Säuberungseffekt spiegelt sich

direkt in den Messdaten wieder. Durch Vergleich der Daten vor und nach der Wartung kann

abgeleitet werden, ob die Säuberung noch erfolgreich ist oder ob der Filter ersetzt werden

muss.

II.1.2.3 Zusammenfassung

Die Zustandsüberwachung von Bauteilen hinsichtlich Wartung und Instandhaltung wird für

viele Bauteile und Baugruppen der selbstfahrenden Erntemaschinen momentan noch von

dem Bediener und/oder der betreuenden Werkstatt übernommen. Dieses geschieht häufig in

statisch festen Zeitabständen (z. B. jeden Morgen, reaktiv bei Durchsicht aufgrund von fest

definierten Intervallen - z. B. Abschmierzyklen, Getriebeölwechsel) oder bei Schäden.

In diesem Teil des Projektes wurden Lösungsansätze aufgezeigt, mit Hilfe derer durch

Einsatz einfacher Sensorik und intelligenter Auswertung von Daten, der Zustand

verschiedener Bauteile kontinuierlich während des Maschineneinsatzes überwacht werden

kann. Anhand zweier Baugruppen des Mähdreschers und zweier verschiedener

Auswertungsmethoden wurde aufgezeigt, auf welche Weise eine Vorhersage zu Wartung

und Instandhaltung an selbstfahrenden Erntemaschinen funktionieren kann. Besonders zu

II.1 Zustandsüberwachung exemplarischer Baugruppen 26

beachten ist hierbei, dass sich für die unterschiedlichen Einsatzbedingungen und

Anwendungen kein generelles Verfahren für alle zu überwachenden Bauteile empfiehlt. Im

Einzelfall ist zu entscheiden, wie weitere Bauteile hinsichtlich Wartung und Instandhaltung

überwacht werden können.

Vorhersagbarkeit von Wartung und Instandhaltung ermöglicht dem Maschinenbediener und

der betreuenden Werkstatt durch Steigerung der Maschinenverfügbarkeit und effiziente

Einsatzplanung eine gesteigerte wirtschaftliche Nutzung der Maschine. Die technischen

Vorraussetzungen sind innerhalb dieses Projektteiles in ihrer Verfügbarkeit aufgezeigt

worden.

II.2 Datenmanagement 27

II.2 Datenmanagement

Das Datenmanagementsystem setzt sich aus unterschiedlichen Elementen zusammen, die

auf einer maschinenseitigen On-Board-Unit sowie im Back-End zum Einsatz kommen. Einige

dieser Elemente, die im Rahmen des Projektes erarbeitet wurden, sollen im Folgenden

vorgestellt werden.

II.2.1 Kompressionsmethoden für verschiedene Datenarten

Im Rahmen dieses Abschnitts soll die Entwicklung der Datenkompressionsmethoden

beschrieben werden. Dazu werden zunächst relevante Datenarten identifiziert und Anfor-

derungen gesammelt. Danach folgt die ausführliche Beschreibung des Entwicklungs-

prozesses. Abschließend werden einige beispielhafte Kompressionsergebnisse vorgestellt.

II.2.1.1 Dateneigenschaften und Anforderungen an die Kompressionsmethoden

Die zu entwickelnden Datenkompressionsmethoden sollen dazu dienen, verschiedenste

Datenarten, die auf der mobilen Arbeitsmaschine vorliegen bzw. dort erhoben, gemessen

oder errechnet werden, zu komprimieren, um so eine effiziente drahtlose Kommunikation

und ggf. eine Zwischenspeicherung zu ermöglichen.

Bei mobilen Arbeitsmaschinen müssen zur Prozessüberwachung oder zur Steuerung und

Regelung von Maschinenfunktionen häufig zeitliche Abfolgen verschiedenster Messwerte

ermittelt und übertragen werden. Druck-, Drehzahl- oder Temperaturmesswerte sind typische

Vertreter dieser Datenart. Für solche gemessenen, analogen Werte soll vorausgesetzt

werden, dass diese als abgetastetes und quantifiziertes Signal über einen maschinen-

internen Datenbus (wie z. B. einen CAN-Bus) bereitgestellt werden. Diese Bereitstellung

kann dabei, entsprechend der verschiedenen Nachrichtentypen des CAN-Protokolls,

entweder zyklisch oder in unregelmäßigen Abständen eventgesteuert erfolgen. Jedem

Messzeitpunkt ist eindeutig ein Wert der Messgröße zugeordnet. Die Abtastrate der zyklisch

einlaufenden Daten kann jedoch nicht als bekannt und konstant vorausgesetzt werden, da

diese sich beispielsweise in Abhängigkeit von der Bus-Auslastung verändern kann.

Eine weitere wichtige Datenart stellen die Positionsinformationen dar. Mit Hilfe moderner

satellitengestützter Ortungssysteme lässt sich die Position einer mobilen Maschine weltweit

mit hoher Genauigkeit bestimmen. Diese Systeme basieren bisweilen zumeist auf dem

II.2 Datenmanagement 28

amerikanischen GPS-System. Bei höheren Genauigkeitsanforderungen kommen zusätzlich

Korrektursignale zum Einsatz, die entweder satellitengestützt (DGPS) oder terrestrisch

(RTK) bereitgestellt werden. Aus der zeitlichen Abfolge dieser Positionsinformationen lässt

sich auch der zurückgelegte Weg ermitteln. Insbesondere im Bereich der Landmaschinen,

sind diese sog. Geodaten von sehr großem Interesse. Damit lassen sich in einem ersten

Schritt ortsdifferenzierte bzw. teilflächenspezifische Informationen sammeln, die in einem

zweiten Schritt genutzt werden können, die Landbewirtschaftung teilflächenspezifisch

durchzuführen. Dabei handelt es sich um das sog. Precision Farming, welches sowohl aus

ökologischen als auch aus ökonomischen Gründen zunehmend an Bedeutung gewinnt. Die

Positionsinformationen, die vom Ortungssystem i. d. R. zyklisch ausgegeben werden,

bestehen zu jedem Messzeitpunkt aus einem Wertepaar, welches die Längen- und

Breitengradinformationen enthält. Dabei sind die südlichen Breitengrade und die westlichen

Längengrade mit einem negativen Vorzeichen versehen, um auch die jeweilige Hemisphäre

der Position eindeutig anzugeben.

Einstellparameter, Statusinformationen oder Stellsignale sind weitere Daten, die auf dem

Datenbus einer mobilen Maschine häufiger vorkommen. Für eine Kompression ist diese

Datenart jedoch eher unbedeutend, da es i. d. R. nur bei einer Veränderung des Wertes oder

zur Initialisierung nach einem Maschinenneustart zu einer Übertragung kommt und die

daraus resultierende Datenmenge keinen nennenswerten Umfang hat.

Im weiteren Verlauf sollen daher vorrangig die ersten beiden Datenarten, also die Messwert-

Zeitreihen und die Positionsdaten, betrachtet werden, da die Verwendung von Daten-

kompressionsmethoden hier ein hohes Einsparpotenzial verspricht und der Bedarf für eine

Kompression bei diesen Datenarten am größten ist. Insbesondere wenn eine hohe

Genauigkeit gefordert ist, müssen diese Daten hochfrequent übertragen werden, was ohne

Kompression zwangsläufig zu sehr großen Datenmengen führt.

Damit die Entwicklung der Kompressionsmethoden zielgerichtet erfolgen kann, müssen

zunächst alle relevanten Anforderungen zusammengetragen werden. Dies geschieht im

Folgenden anhand verschiedener Kriterien.

Mobiler Einsatz

Die zu entwickelnden Kompressionsmethoden müssen für den Einsatz auf mobilen

Arbeitsmaschinen geeignet sein. Das bedeutet, dass die Kompressionsalgorithmen auf

mobiltauglichen Rechnern lauffähig implementierbar sein müssen. Dabei ist zu beachten,

dass diese Rechner, im Vergleich zu Desktop-Rechnern, bisweilen noch nur über geringe

II.2 Datenmanagement 29

Speicher- und Prozessorressourcen verfügen. Zudem sind sie vergleichsweise teuer,

weswegen eine Erhöhung der knappen Ressourcen durch die Verwendung mehrerer solcher

Rechner aus Kostengründen i. d. R. nicht darstellbar ist. Auch der nur sehr eingeschränkt

verfügbare Bauraum auf der Maschine spricht gegen den Einsatz mehrerer solcher Rechner.

Bei mobilen Arbeitsmaschinen wird die Primärenergie i. d. R. in Form von Kraftstoffen in

Tanks mitgeführt. Da diese Tanks nur über eine begrenzte Kapazität verfügen und so die

Einsatzdauer der Maschine limitieren, ist einer effizienten Energienutzung, auch bei der

Datenverarbeitung, ein hoher Stellenwert einzuräumen.

Online-Fähigkeit

Eine weitere Anforderung, die unmittelbar aus dem mobilen Einsatz resultiert ist die Online-

Fähigkeit der Kompressionsalgorithmen. Dies bedeutet, dass die einlaufenden Daten

unmittelbar verarbeitet werden können, ohne dass eine Kenntnis über zukünftige Werte

vorliegen muss. Bild II.18 macht den Begriff der Online-Fähigkeit an Hand von drei kleinen

Beispielen deutlich. Es zeigt eine zeitliche Abfolge von Daten, bestehend aus einzelnen

Messwerten, vom Zeitpunkt t0 bis zum Zeitpunkt tl. Jeder der Kästen repräsentiert dabei

einen Messwert. Die senkrechten Pfeile kennzeichnen den Zeitpunkt an dem die Kom-

pression durchgeführt werden soll und die Messwerte, die dabei vom Algorithmus verarbeitet

werden, sind grau hinterlegt. Im Fall a) müssen alle Werte zunächst zwischengespeichert

werden, bevor der Kompressionsalgorithmus zum Zeitpunkt t = tl die gesamten Daten im

Nachhinein verarbeitet. Dieser Algorithmus ist nicht online-fähig. Im Fall b) werden mehrere

zurückliegende Werte zum aktuellen Zeitpunkt t = ta verarbeitet. Hierbei handelt es sich um

einen bedingt online-fähigen Algorithmus. Im dritten Fall c) schließlich verarbeitet der online-

fähige Algorithmus jeden einzelnen Wert unmittelbar zum aktuellen Zeitpunkt.

Bild II.18: Veranschaulichung des Begriffs der Online-Fähigkeit nach [Ger07]

II.2 Datenmanagement 30

Die Online-Fähigkeit ist nicht nur wegen der begrenzten Speicherressourcen auf dem

mobilen Rechner erstrebenswert sondern insbesondere auch wegen der schwer vorher-

sehbaren Abschaltvorgänge der Maschine. Wenn der Bediener die Maschine abschaltet,

muss sichergestellt sein, dass kurze Zeit später auch die Spannungsversorgung des mobilen

Rechners unterbrochen wird. Nur so kann gewährleistet werden, dass die in der Batterie

gespeicherte Energie nicht verloren geht und für einen, ggf. mehrere Monate späteren

Neustart der Maschine im notwendigen Umfang zur Verfügung steht. Durch einen online-

fähigen Kompressionsalgorithmus kann verhindert werden, dass beim spontanen Abschalten

der mobilen Arbeitsmaschine Daten verloren gehen. Außerdem steht dadurch das

Kompressionsergebnis für eine Kommunikation oder eine Archivierung zeitnah nach dem

Einlaufen der Daten zur Verfügung.

Verlustgrad und Parametrierbarkeit

Die zu entwickelnden Kompressionsmethoden sollen verlustbehaftet arbeiten, der

Verlustgrad soll sich jedoch dem jeweiligen Bedarf und Einsatzfall entsprechend begrenzen

lassen. Wie viel Information bei der Kompression eliminiert wird, die später nicht wieder

rekonstruiert werden kann, soll bei der Kompression mit Hilfe von anschaulichen Parametern

vorgegeben werden können. Eine weitere sehr wichtige Anforderung ist, dass der

Kompressionsgewinn in einem günstigen Verhältnis zum Informationsverlust stehen soll.

Demnach sollte ein hoher Kompressionsgewinn möglichst nur einen vergleichsweise

geringen Informationsverlust bewirken. Die zu entwickelnden Methoden sollen eine zeitliche

Zuordnung der Daten nach der Kompression weiterhin ermöglichen.

Übertragbarkeit

Die zu entwickelnden Kompressionsmethoden sollen sich nach Möglichkeit zur

Komprimierung verschiedener Datenquellen nutzen lassen. Diese Übertragbarkeit soll

sicherstellen, dass nicht für jede Datenquelle eine individuelle Kompressionsmethode

entwickelt werden muss. Außerdem müssen so auf dem mobilen Fahrzeugrechner nur

wenige Kompressionsmethoden in Form von Softwarediensten implementiert werden. Diese

Softwaredienste können dann bei Bedarf, also wenn Daten aus mehreren verschiedenen

Datenquellen gleichzeitig komprimiert werden sollen, einfach mehrfach gestartet und

individuell parametriert an die verschiedenen Datenquellen angepasst werden.

Dekomprimierbarkeit

Nach Möglichkeit soll die Dekompression, also die Rückgewinnung der Information aus dem

Kompressionsergebnis, ohne großen Aufwand und ohne die Kenntnis vieler zusätzlicher

II.2 Datenmanagement 31

Informationen (Metadaten) möglich sein. Dies ist unbedingt anzustreben, da mobile

Arbeitsmaschinen nicht in einem einheitlichen, abgegrenzten Organisationsumfeld zum

Einsatz kommen. Im Gegenteil; auf Grund der großen Vielfältigkeit dieser Maschinen werden

sie in sehr unterschiedlichen Branchen und Betrieben eingesetzt. Deswegen ist auch von

sehr heterogenen Strukturen bei den Nutzern der Daten auszugehen. Vom Landwirt über

den Baubetriebsleiter bis hin zum Servicemitarbeiter in der Reparaturwerkstatt sollen alle

potenziellen Datennutzer einen möglichst einfachen Zugriff auf die komprimierten Daten

erhalten können. Dies ist am einfachsten sicherzustellen, wenn zur Decodierung keine oder

nur sehr wenige Metadaten bekannt sein müssen bzw. wenn das Kompressionsergebnis

auch ohne Decodierung lesbar und aussagekräftig ist. Für den Fall, dass keine

umfangreichen Metadaten beim Datennutzer bekannt sein müssen, ist es auch nicht

notwendig, diese zusätzlich zu den eigentlichen Daten zu übertragen. Aufgrund der

beschriebenen, sehr heterogenen Strukturen bei der Datennutzung kann nämlich nicht

davon ausgegangen werden, dass die Metadaten bei allen Datennutzern als bekannt

vorausgesetzt werden können.

Kontextsensitivität

Eine letzte und dennoch sehr wichtige Anforderung ist die Kontextsensitivität der

Kompressionsalgorithmen. Kontextinformationen sind Informationen, die sich nicht aus der

zu komprimierenden Datenmenge selbst, sondern aus der Kombination mit externen

Informationsquellen gewinnen lassen. Beispielsweise liefert eine Positionsinformation selbst

keine Aussage darüber, ob sich die Position innerhalb eines Feldes oder auf einer Straße

bzw. einem Weg befindet. Werden jedoch die Positionsinformation mit den Daten einer

digitalen Karte kombiniert, so lässt sich aus dem Kontext heraus eine solche Aussage

treffen.

Der Begriff der Kontextsensitivität beschreibt die Beeinflussbarkeit der Kompressions-

methode während ihrer Laufzeit durch Kontextinformationen. Damit wäre für das Beispiel der

Positionsinformationen denkbar, auf dem Feld aus Gründen der Genauigkeit einen niedrigen

Verlustgrad und auf der Straßen zu Gunsten der Kompressionsrate einen hohen Verlustgrad

zu wählen. Eine Anpassung des Verlustgrads einer Kompressionsmethode soll also in

Abhängigkeit von Kontextinformationen möglich sein, jedoch nicht innerhalb des

Kompressionsalgorithmus selbst, sondern nach Möglichkeit von extern durch Anpassung der

Kompressionsparameter realisiert werden können. Nur so kann die zuvor geforderte

Übertragbarkeit der Algorithmen sichergestellt werden.

II.2 Datenmanagement 32

Die Verarbeitung der Kontextinformationen muss in diesem Falle von einem speziellen

externen Softwaredienst erfolgen, der nur die Parametrierung des Kompressionsalgorithmus

in Abhängigkeit des Kontextes anpasst, nicht aber den Algorithmus selbst. Nachfolgend sind

in Tabelle II.1 alle, im vorigen Abschnitt bereits erläuterten Anforderungen in Form einer

Anforderungsliste nochmals übersichtlich zusammengestellt.

Tabelle II.1: Qualitativer Vergleich der Ergebnisse aus den Voruntersuchungen

Nr. Anforderungsmerkmal Ausprägung Anforderungsart

1 Mobiler Einsatz ermöglichen F

2 Online-Fähigleit sicherstellen F

3.1 Verlustgrad beeinflussbar gestalten und möglichst günstiges Verhältnis von

Kompressionsgewinn zu Informationsgewinn anstreben

F

3.2 Parametrierbarkeit anschauliche Parameter W

4 Übertragbarkeit sicherstellen F

5 Dekomprimierbarkeit möglichst einfach und ohne die Kenntnis von Metadaten

ermöglichen

W

6 Kontextsensitivität durch externe Maßnahmen ermöglichen

F

Neben den Anforderungsmerkmalen ist jeweils die geforderte Ausprägung aufgeführt. In der

letzten Spalte sind die Anforderungen kategorisiert. Dabei wird zwischen Festanforder-

ungen (F) und Wunschanforderungen (W) unterschieden.

II.2.1.2 Theoretische Betrachtungen und Voruntersuchungen

Auf einige theoretische Grundlagen der Datenkompression soll an dieser Stelle, mit Blick auf

die Zielsetzung der vorliegenden Arbeit, kurz eingegangen werden bevor anschließend die

Darstellung der im Rahmen des Projektes durchgeführten Vorversuche zur Daten-

kompression erfolgt.

II.2.1.2.1 Theoretische Betrachtungen

Bei der Kompression von Daten kann grundsätzlich zwischen verlustfreien und verlust-

behafteten Methoden unterschieden werden. Bei der verlustfreien Kompression werden

lediglich Redundanzen aus einer gegebenen Datenmenge entfernt, wohingegen bei den

verlustbehafteten Methoden auch Irrelevanzen aus der gegebenen Datenmenge eliminiert

werden.

II.2 Datenmanagement 33

Redundanzreduktion

Die Informationstheorie beschäftigt sich im Wesentlichen mit der mathematischen Ermittlung

und Elimination von Redundanzen, die in einer gegebenen Datenmenge enthalten sind, um

so die erforderliche Mindest-Kanalkapazität für eine fehlerfreie Übertragung zu bestimmen.

Dazu ist die Häufigkeitsverteilung der in der Datenmenge enthaltenen Zeichen von

entscheidender Bedeutung. Methoden zur Redundanzreduktion sind meist vielseitig

verwendbar und damit auf teilweise sehr unterschiedliche Datentypen anwendbar. Diese

Tatsache ist darauf zurückzuführen, dass bei dieser Art der Kompression die zu

komprimierenden Daten nur auf ihrer Syntaxebene betrachtet und verarbeitet werden.

Semantische und pragmatische Aspekte der Daten bleiben unberücksichtigt. D. h. bei der

Kompression hat weder einen Einfluss, wofür die zu übertragenen Zeichen stehen (also

welche Bedeutung sie haben) noch, ob diese Zeichen für einen Empfänger interessant sind

oder nicht. Der Vorteil der verlustfreien Kompressionsmethoden ist, dass sich alle in der

ursprünglichen Datenmenge enthaltenen Informationen aus dem Kompressionsergebnis

fehlerfrei rekonstruieren lassen. Ein sehr großer Nachteil sind jedoch die nur vergleichsweise

niedrigen Kompressionsraten, die mit den verlustfreien Kompressionsmethoden erzielt

werden können.

Eine wesentliche Anforderung an die zu entwickelnden Kompressionsmethoden ist deren

Online-Fähigkeit. Die Häufigkeitsverteilung der zu übertragenen Zeichen bzw. Werte ist aber,

wenn überhaupt, erst im Nachhinein bekannt und steht deshalb während der Online-

Verarbeitung der einzelnen Messwerte noch nicht zur Verfügung. Außerdem handelt es sich

bei den zu komprimierenden Daten oft um digitalisierte Analogsignale. Bei hoher Auflösung

kann das Signal daher sehr viele verschiedene Werte annehmen (im Gegensatz z. B. zu

Textdaten mit einem sehr begrenzten Zeichensatz).

Für die im Rahmen dieser Arbeit verfolgten Ziele scheinen die verlustfreien

Kompressionsmethoden mit dem Ansatz der Redundanzreduktion also weniger gut geeignet

zu sein. Aus diesem Grund wird festgelegt, dass die zu entwickelnden Methoden nicht

verlustfrei sondern verlustbehaftet arbeiten sollen.

Irrelevanzreduktion

Bei den verlustbehafteten Kompressionsmethoden, die den Ansatz der Irrelevanzreduktion

verwenden, sind die erzielbaren Kompressionsraten nicht begrenzt, allerdings ist die stärkere

Kompression dabei nur auf Kosten des Informationsgehaltes möglich. Bei der Entwicklung

und Bewertung von verlustbehafteten Kompressionsmethoden muss deswegen neben der

II.2 Datenmanagement 34

Kompressionsrate (bzw. dem Kompressionsgewinn) immer auch der Informationsverlust, der

durch die verlustbehaftete Kompression hervorgerufen wurde, mit berücksichtigt werden. Die

zu entwickelnden Methoden sollen, wie bereits in Abschnitt II.2.1.1 festgelegt wurde, auf

fahrzeugseitigen Rechnern lauffähig implementiert werden können. Damit die Kompression

rechnergestützt erfolgen kann, müssen zunächst geeignete Relevanzkriterien definiert

werden. Mit Hilfe dieser Relevanzkriterien kann der Kompressionsalgorithmus irrelevante

Informationen von relevanten Informationen unterscheiden. So kann erreicht werden, dass

bei der Kompression keine relevanten sondern nur irrelevante Informationen verloren gehen.

II.2.1.2.2 Voruntersuchungen

Voruntersuchungen, die an Hand von Testdatensätzen durchgeführt wurden, sollen dazu

dienen, vorbereitend für den eigentlichen Entwicklungsprozess, eine tendenzielle

Einschätzung der Wirksamkeit verschiedener Maßnahmen zur Datenkompression zu

ermöglichen. Auf den Ablauf und die Erkenntnisse dieser Voruntersuchungen soll an dieser

Stelle etwas näher eingegangen werden.

Die Voruntersuchungen zur Entwicklung verschiedener Datenkompressionsmethoden

wurden an Hand von Testdatensätzen durchgeführt die freundlicherweise von der Firma

Claas bereitgestellt wurden. Bei den Datensätzen handelt es sich um die Verläufe der

Drehzahl des Verbrennungsmotors eines Mähdreschers. Diese wurden unter realen

Erntebedingungen mit einer Frequenz von 1/15 Hz aufgezeichnet. Die Datensätze beinhalten

die aufgezeichneten Motordrehzahlwerte über mehrere aufeinander folgende Tage, von

denen einer als repräsentativ für die ersten Voruntersuchungen ausgewählt wurde. Bild II.19

zeigt den Verlauf der Motordrehzahl über diesen ausgewählten Tag hinweg. Es ist

erkennbar, dass die Maschine an diesem Tag zwischen 10:40 Uhr und 21:20 Uhr, mit

Ausnahme von zwei längeren und einigen sehr kurzen Unterbrechungen, kontinuierlich in

Betrieb war. Weiterhin sind in diesem Messschrieb die typischen Einsatzbedingungen eines

Mähdreschermotors zu erkennen: Den überwiegenden Teil der Zeit bewegen sich die

Drehzahlwerte in einem Bereich zwischen 1900 und 2100 1/min. Nur wenige Male wurde die

Drehzahl in einen Bereich von etwa 1200 1/min abgesenkt. Diese Datensätze haben

einerseits wegen der sehr geringen zeitlichen Auflösung und außerdem durch den sehr

speziellen Drehzahlverlauf, der sich aus dem Einsatzfall „Mähdrescher" ergibt, keinen

allgemein gültigen oder gar repräsentativen Charakter für die verschiedensten zu

komprimierende Daten in Telematikanwendungen bei mobilen Arbeitsmaschinen. Dennoch

lassen sich daran einige grundlegende Kompressionsprinzipien erproben und bewerten, um

für den weiteren Verlauf des Entwicklungsprozesses wichtige Hinweise zu erlangen.

II.2 Datenmanagement 35

Bild II.19: Motordrehzahlwerte eines Mähdreschers, die als Testdaten zur Verfügung

standen

Folgende drei grundlegende Maßnahmen zur Datenkompression wurden im Rahmen der

Voruntersuchungen auf die Testdatensätze angewendet. Dabei wurden verschiedene

Parameter variiert.

1. Reduzierung der Abtastrate: Durch Verringerung der Abtastrate um einen definierbaren

Faktor kann die Datenmenge sehr einfach reduziert werden. Es werden verschiedene

Faktoren untersucht. Beim Faktor fünf ist beispielsweise nur noch jeder fünfte

Messwert relevant.

2. Mittelung über feste Blocklängen: Dabei werden mehrere aufeinander folgende

Messwerte zu einem Block zusammengefasst. Für jeden dieser Blöcke ist, statt aller

ursprünglichen Messwerte, nur noch der arithmetische Mittelwert dieser Messwerte

relevant. Nur noch dieser Mittelwert wird abgespeichert. Die Blocklänge wird als

Parameter variiert. Sind alle Messwerte eines Blockes bekannt, so wird der errechnete

Mittelwert zusammen mit dem Startzeitpunkt des Blockes abgespeichert.

3. Mittelung über variable Blocklängen: Im Gegensatz zur vorherigen Maßnahme, wird

hierbei die Länge der Blöcke, über die eine Mittelung der Messwerte stattfindet,

dynamisch eingestellt. Erst wenn gewisse Kriterien eintreten, wird ein Block

abgeschlossen und die Mittelwertbildung startet mit dem aktuellen Messwert erneut.

Auch hierbei wird der Mittelwert aller Messwerte des abgeschlossenen Blockes

zusammen mit dessen Startzeitpunkt abgespeichert. Als Abbruchkriterien werden die

II.2 Datenmanagement 36

Differenz zwischen dem aktuellen Messwert und dem letzten errechneten

Mittelwert (P1) sowie die Differenz des aktuellen Messwertes zum ersten Messwert des

aktuellen Blockes (P2) überwacht. Diese beiden Parameter werden für die Vorversuche

variiert.

Um diese Maßnahmen vergleichen und subjektiv bewerten zu können, sind diese jeweils auf

den in Bild II.19 dargestellten Signalverlauf angewendet worden, also auf alle Daten, die

während des ausgewählten Tages gemessen wurden. Dabei ist zu berücksichtigen, dass in

den Zeiträumen, wo die Motordrehzahl gleich null ist, keine Messwerte aufgezeichnet

wurden. Deswegen bleiben diese Zeiträume auch bei der Berechnung der Kompressions

raten und Einsparungen unberücksichtigt.

In Tabelle II.2 sind die, durch die ersten beiden Maßnahmen, erzielten Kompressionsraten

und Einsparungen für die variierten Parameter aufgelistet. Für beide Maßnahmen, also die

Reduktion der zeitlichen Abtastrate und die Mittelung der Messwerte über feste Blocklängen,

ergeben sich jeweils genau gleiche Resultate für die Kompressionsrate bzw. die Einsparung.

Diese Resultate sind zudem unabhängig vom Verlauf der zu komprimierenden Daten und

damit prinzipiell bereits im Voraus berechenbar.

Tabelle II.2: Kompressionsergebnisse der ersten beiden Maßnahmen

Faktor, um den die Abtastrate reduziert wurde bzw. Länge der festen Blöcke

CR -

Einsparung [%]

Bild-Nr.

2 2 50

3 3 66,6 II.20 und II.21

5 5 80

10 10 90 II.22 und II.23

20 20 95

50 50 98 II.24 und II.25

100 100 99

200 200 99,5

Im Folgenden sind in den Bildern II.20 bis II.25 einige exemplarisch ausgewählte Ergebnisse

aus den Voruntersuchungen vergleichend dargestellt, die mit drei verschiedenen Parametern

jeweils mit der ersten und der zweiten Kompressionsmaßnahme erzielt wurden. Dabei sind

die Ergebnisse immer für den in Bild II.19 markierten Ausschnitt vergrößert dargestellt, um

im direkten visuellen Vergleich mit dem Verlauf des Originalsignals einen subjektiven

Eindruck vom jeweiligen Kompressionsergebnis zu erlangen. Die Kompressionsraten und

Einsparungen beziehen sich aber, wie bereits erwähnt, immer auf die Daten des gesamten

Tages.

II.2 Datenmanagement 37

Bild II.20: Auflösung red. um Faktor 3, Bild II.21: Feste Blocklänge 3, CR = 3, Einsp.: 66,6 % CR = 3, Einsp.: 66,6 %

Bild II.22: Auflösung red. um Faktor 10, Bild II.23: Feste Blocklänge 10, CR = 10, Einsp.: 90 % CR = 10, Einsp.: 90 %

II.2 Datenmanagement 38

Bild II.24: Auflösung red. um Faktor 50, Bild II.25: Feste Blocklänge 50 CR = 50, Einsp.: 98 % CR = 50, Einsp.: 98 %

Bei der genaueren Betrachtung der Ergebnisse fällt auf, dass mit beiden Maßnahmen bei

entsprechend groß gewähltem Kompressionsparameter zwar recht gute Kompressions-

ergebnisse erzielt werden können, das Kompressionsergebnis dann jedoch nur noch eine

sehr ungenaue Repräsentation des ursprünglichen Signalverlaufs darstellt. Dabei zeigen

beide Maßnahmen unterschiedliche Besonderheiten.

Bei der ersten Maßnahme fällt auf, dass sie die zum Zeitpunkt der Abtastung aktuell

vorliegenden Werte fehlerfrei wiedergibt. Dieser Vorteil kommt jedoch nur dann wirklich zum

tragen, wenn sich der Signalverlauf bis zum nächsten Abtastzeitpunkt nicht wesentlich

verändert. Liegt hingegen genau zu einem Abtastzeitpunkt kurzzeitig ein eher extremer Wert

vor, so vermittelt das Kompressionsergebnis den Anschein, dass dieser extreme Wert für die

Dauer bis zum nächsten Abtastschritt vorgelegen hat. Doch auch der umgekehrte Fall, wenn

nämlich kurzzeitig auftretende Abweichungen verloren gehen, weil gerade in dieser Zeit

keine Abtastung stattgefunden hat, ist negativ zu bewerten, insbesondere wenn kurzzeitige

extreme Ereignisse im Signalverlauf eine wichtige Information darstellen. Bereits bei einer

Verringerung der Abtastrate um den Faktor 3 (Bild II.20) geht das kurzzeitige Absinken der

Drehzahl bei ca. 2200 Sekunden nicht mehr aus dem Kompressionsergebnis hervor. Beim

II.2 Datenmanagement 39

Faktor 50 (Bild II.24) geht durch die Kompression sogar auch die davor liegende, längere

Phase mit niedrigerer Drehzahl verloren.

Die zweite Maßnahme zeigt ihre Vorteile, wenn der Signalverlauf über der eingestellten

Blocklänge hinweg nur leichten Schwankungen unterworfen ist. Als Kompressionsergebnis

wird für die Dauer dieses Blocks der Mittelwert abgespeichert, der dann eine gute

Repräsentation des ursprünglichen Signalverlaufs darstellt. Doch, wie schon bei der ersten

Maßnahme, werden auch bei dieser Kompressionsmethode die Schwächen insbesondere

bei großen Sprüngen im Signalverlauf offensichtlich. Die Mittelwertbildung berücksichtigt

zwar diese Änderungen im Signalverlauf, die Kompressionsergebnisse zeigen jedoch auch

hierbei, insbesondere bei den größeren Blocklängen (Bild II.23 und Bild II.25), keine

grundsätzliche Übereinstimmung mit dem Ausgangssignal mehr. Durch die Mittelwertbildung

treten im Kompressionsergebnis in Bereichen, wo das Originalsignal zwischen dem hohen

und dem niedrigen Drehzahlbereich wechselt, zeitweise Signalamplituden auf, die im

Originalsignal zu keiner Zeit tatsächlich vorgelegen haben.

In Tabelle II.3 sind die Kompressionsraten und Einsparungen zusammengestellt, die im

Rahmen der Voruntersuchungen mit der dritten Maßnahme erzielt wurden. Da diese als

einzige der untersuchten Maßnahmen eventgesteuert arbeitet, sind die Kompressions-

ergebnisse individuell vom Verlauf der zu komprimierenden Daten und von den für die

beiden Abbruchkriterien eingestellten Schwellwerten abhängig. Sobald ein neu hinzu

kommender Messwert dafür sorgt, dass mindestens eines der beiden Abbruchkriterien

vorliegt, so wird der zuletzt berechnete Mittelwert abgespeichert und die Mittelwertbildung

beginnt mit dem aktuellen Messwert von neuem. Mit der Überwachung der Abbruchkriterien

wird verhindert, dass relevante Merkmale des Originalsignals bei der Kompression verloren

gehen. Die Abbruchkriterien können also auch als Relevanzkriterien bezeichnet werden. In

den Bildern II.26 bis II.28 sind ausgewählte Kompressionsergebnisse dargestellt, die mit der

dritten Kompressionsmaßnahme erzielt wurden. Um eine subjektive Vergleichbarkeit der

Ergebnisse zu erleichtern, wurden die Abbruchkriterien bei den drei dargestellten Beispielen

so gewählt, dass ähnliche Kompressionsraten erreicht wurden, wie bei den zuvor gezeigten

Ergebnissen der ersten beiden Maßnahmen.

II.2 Datenmanagement 40

Tabelle II.3: Kompressionsergebnisse der dritten Maßnahme

Verwendete Abbruchkriterien

P1 P2

CR -

Einsparung [%]

Bild-Nr.

2 2 1,4 28,1

3 3 1,7 40,9

5 5 2,5 59,5

6 6 3,0 66,4 II.26

8 10 4,6 78,3

10 10 5,2 80,8

18 19 10,0 90,0 II.27

50 50 45,2 97,8

60 70 50,0 98,0 II.28

100 100 78,4 98,7

200 200 98,0 99,0

Es fällt auf, dass die großen Sprünge, die im ursprünglichen Signalverlauf vorhanden sind, in

allen drei Diagrammen auch im Kompressionsergebnis korrekt wiedergegeben werden. Dies

war bei den beiden ersten Maßnahmen bereits bei kleinen Kompressionsraten nicht mehr

der Fall. Ein grundlegender Unterschied zwischen den dargestellten drei Diagrammen

besteht lediglich in den Bereichen kleiner Signalamplituden. Hier nimmt mit zunehmender

Kompressionsrate auch die Genauigkeit dahingehend ab, dass kleinere

Signalschwankungen aus dem Kompressionsergebnis nicht mehr hervor gehen. In diesen

Bereichen wird das Signal durch den ermittelten Mittelwert jedoch in akzeptabler Weise

repräsentiert.

II.2 Datenmanagement 41

Bild II.26: Var. Blocklänge, Bild II.27: Var. Blocklänge, Parametersatz 1, Parametersatz 2, CR = 3, Einsp.: 66,4 % CR = 10, Einsp.: 90 %

Bild II.28: Var. Blocklänge Parametersatz 3, CR = 50, Einsp.: 98 %

II.2 Datenmanagement 42

Vergleichende Bewertung und Zusammenfassung der Voruntersuchungen

Um die Ergebnisse der Voruntersuchungen abschließend qualitativ vergleichen zu können,

sollen die neun zuvor dargestellten Kompressionsergebnisse der drei untersuchten Maß-

nahmen (Bilder II.20 bis II.28) in ein Schaubild eingetragen werden, in dem der relative Spei-

cherplatzbedarf und der relative Informationsgehalt (bezogen auf die Originaldaten) der

verschiedenen Kompressionsergebnisse eingetragen werden. Dazu kann der relative Spei-

cherplatzbedarf aus der Kompressionsrate bzw. aus der Einsparung sehr einfach errechnet

werden. Lediglich der relative Informationsgehalt muss subjektiv durch visuellen Vergleich

der Kompressionsergebnisse mit dem Verlauf der Originaldaten ermittelt werden. In Bild II.29

sind die Ergebnisse der untersuchten Maßnahmen eingetragen. Da die relativen Infor-

mationsgehalte der ersten beiden Maßnahmen bei der subjektiven Bewertung als sehr

ähnlich eingestuft wurden, sind diese für die Darstellung zusammengefasst dargestellt.

Spei

cher

plat

zbed

arf

Trend bei Maßnahme 1 und 2

Trend b

ei Maß

nahm

e 3

Bild II.29: Qualitativer Vergleich der Ergebnisse aus den Voruntersuchungen

Das Bild veranschaulicht, dass sich die Ergebnisse der dritten Maßnahme deutlich positiv

von den Ergebnissen der ersten beiden Maßnahmen abheben. Bei gleichem relativem

Speicherplatzbedarf liegen die Informationsgehalte der Kompressionsergebnisse hier weit

über denen der ersten beiden Maßnahmen. Neben den konkreten Einzelergebnissen sind

auch Trendverläufe angegeben, wie sich die Kompressionsergebnisse bei Variation der

Kompressionsparameter verändern würden. Die dargestellte Trendlinie für die dritte

Maßnahme liegt insgesamt in einem wesentlich günstigeren Bereich (hoher Informations-

gehalt bei niedrigem Speicherplatzbedarf) des Diagramms als die der anderen beiden.

II.2 Datenmanagement 43

Die Voruntersuchungen haben gezeigt, dass sich von den drei untersuchten Maßnahmen die

dritte als am besten geeignet heraus gestellt hat. Dabei ist einschränkend anzumerken, dass

diese Aussage bislang nur auf Basis der Anwendung auf die Testdaten beruht. Diese

verfügen ihrerseits, wie bereits weiter oben dargestellt, über sehr spezielle Eigenschaften,

die nicht unbedingt als repräsentativ für viele verschiedene Datenarten betrachtet werden

dürfen. Dennoch kann festgehalten werden, dass die individuelle Beeinflussung der

Kompression durch den Verlauf des zu komprimierenden Signals durchaus einen vielver-

sprechenden Ansatz darstellt. Gegenüber den ersten beiden untersuchten Maßnahmen

ließen sich, bei vergleichbaren Kompressionsraten, wesentlich höhere Informationsgehalte

im Kompressionsergebnis erhalten. Aus diesem Grund wird an dieser Stelle das Prinzip der

dritten Maßnahme als Grundlage für die weiteren Entwicklungen ausgewählt.

II.2.1.3 Entwicklung der Methoden

Im Abschnitt II.2.1.1 wurden die grundlegenden Eigenschaften der zu komprimierenden

Daten dargestellt. Außerdem wurden dort verschiedene Anforderungen zusammengetragen,

die die zu entwickelnden Kompressionsmethoden im Idealfall erfüllen sollen. Im Rahmen von

Voruntersuchungen wurden verschiedene Maßnahmen zur Datenkompression auf ihre

prinzipielle Eignung untersucht. Die Ergebnisse dieser Voruntersuchungen wurden im

vorangegangenen Abschnitt II.2.1.2 dargestellt und diskutiert. Außerdem erfolgte eine

qualitative, vergleichende Bewertung. Auf dieser Basis wird nun im Rahmen dieses

Abschnitts die Entwicklung der Kompressionsmethoden für die vorgestellten Datenarten

beschrieben.

II.2.1.3.1 Entwicklungsumgebung und Vorgehen

Für die Entwicklungen und Untersuchungen wurde das Programmpaket Matlab von der

Firma The MathWorks® als Entwicklungsumgebung genutzt. Bei Matlab handelt es sich um

ein umfangreiches Softwarepaket für numerische Mathematik. Seine besondere Stärke liegt

in der Vektor- und Matrizenrechnung. Neben einem Basismodul, welches die obligatorischen

Ein- und Ausgabefunktionen, vielfältige zwei- und dreidimensionale Visualisierungsmöglich-

keiten, zahlreiche mathematische Funktionen sowie die Möglichkeit zur Programmierung und

Programmablaufsteuerung mitbringt, sind verschiedene Erweiterungspakete, sog. Tool-

boxen, verfügbar. Damit stellt Matlab für viele Anwendungsfälle ein geeignetes Werkzeug für

die simulative Lösung auftretender Problemstellungen dar [ABRW03]. Für die hier vorge-

stellten Untersuchungen wurde Matlab in der Programmversion R2006a (V7.2.0.232)

verwendet, die unter anderem die beiden Toolboxen Simulink und Stateflow, jeweils in der

II.2 Datenmanagement 44

Version V6.4, beinhaltet. Die im vorangegangenen Abschnitt untersuchten Maßnahmen zur

Datenkompression wurden für die Voruntersuchungen in Form von Blockschaltbildern in

Simulink prototypisch implementiert. Diese Variante bietet den Vorteil, dass die Messwerte

über ein zeitdiskretes, abgetastetes Simulationsmodell, entsprechend ihrer Messzeit,

schrittweise aus einem Speicher eingelesen und nacheinander verarbeitet werden. Damit

wurde bereits bei den Voruntersuchungen sichergestellt, dass die verwendeten Algorithmen

online-fähig sind, also nur den zurückliegenden, nicht aber den zukünftigen Signalverlauf als

bekannt voraussetzen. Ein weiterer Vorteil dieser Vorgehensweise ist die gute Portierbarkeit

der entwickelten Algorithmen auf eine Echtzeit-Hardware (RCP), was für die experimentellen

Erprobungen der Datenkompressionsmethoden von sehr großer Bedeutung ist. Für den nun

folgenden Entwicklungsprozess soll dieser Ansatz deshalb weiter verfolgt werden.

II.2.1.3.2 Kompressionsmethode für Messwert-Zeitreihen

Zur ersten Datenart, für die eine Komprimierung ermöglicht werden soll, zählen die sog.

Messwert-Zeitreihen. Auch bei den Testdaten, auf deren Basis die Voruntersuchungen

durchgeführt wurden, handelte es sich um eine solche Messwert-Zeitreihe. Aus diesem

Grund liefern die Voruntersuchungen schon sehr konkrete Ansätze zur Entwicklung einer

geeigneten Kompressionsmethode für diese Datenart.

Bei den Voruntersuchungen konnte, im Vergleich zu den anderen beiden untersuchten

Maßnahmen, mit der dritten Maßnahme zur Datenkompression (Mittelung über variable

Blocklängen) das beste Ergebnis erzielt werden. Diese Maßnahme zeichnet sich gegenüber

den anderen beiden dadurch aus, dass sie individuell auf den Verlauf der zu

komprimierenden Messwert-Zeitreihe reagieren kann, d. h. sie arbeitet signaladaptiv. Der zu

komprimierende Signalverlauf wird dabei laufend auf relevante Kriterien überprüft. Dieses

Prinzip der Irrelevanzreduktion soll im Rahmen des Entwicklungsprozesses auf Grund der

positiven Erfahrungen aus den Voruntersuchungen weiter verfolgt und verbessert werden.

Die Wahl geeigneter Relevanzkriterien übt einerseits einen entscheidenden Einfluss auf das

Kompressionsergebnis aus und außerdem hängt davon ab, ob alle Anforderungen, die zuvor

dargestellt wurden, auch erfüllt werden. Nachfolgend soll daher zunächst eine genauere

Analyse der Relevanzkriterien stattfinden, die bei den Voruntersuchungen mit der dritten

Maßnahme verwendet wurden. Ausgehend von dieser Betrachtung sollen weitere mögliche

Relevanzkriterien auf ihre Eignung hin untersucht werden, bevor abschließend eine Auswahl

geeigneter Relevanzkriterien für die algorithmische Umsetzung erfolgt.

II.2 Datenmanagement 45

Relevanzkriterien

Bei den Voruntersuchungen mit der dritten Maßnahme wurden als Relevanzkriterien zwei

verschiedene Werte beobachtet: Zum einen die Abweichung des aktuellen Messwertes vom

letzten Mittelwert (P1) und zusätzlich die Abweichung des aktuellen Messwertes vom ersten

Messwert des aktuellen Blockes (P2) Bild II.30 veranschaulicht diese beiden Kriterien an

einem exemplarischen Signalverlauf. Die Zeit ts ist der Startzeitpunkt des aktuellen Blockes,

für den eine Mittelung der Messwerte erfolgt. Die aktuelle Zeit ist mit ta bezeichnet, zum

Zeitpunkt tl wurde der letzte Messwert (wl) berücksichtigt und zum Zeitpunkt tn ist ein neuer

Messwert (wn) hinzugekommen. Die Überprüfung der beiden Kriterien P1 und P2 entscheidet

darüber, ob der neue Wert wn mit in die Mittelung einbezogen wird oder ob es zu einem

Abbruch kommt, der vorherige Mittelwert zum Zeitpunkt ts abgespeichert und die

Mittelwertbildung zum Zeitpunkt tn mit dem Wert wn von neuem begonnen wird.

Mes

swer

t w P1

P 2

Bild II.30: Relevanzkriterien bei den Voruntersuchungen mit der dritten Maßnahme

Der Wahl der beiden Kriterien für die Voruntersuchungen lagen zum einen die einfache

Implementierbarkeit des zugehörigen Kompressionsalgorithmus sowie die folgenden beiden

Überlegungen zu Grunde: Das Kriterium P1 dient dazu, dass große Sprünge im Signalverlauf

zu einem Abbruch führen und durch die Überwachung von P2 soll sichergestellt werden,

dass es auch im Falle eines langsam driftenden Signals auf jeden Fall beim Überschreiten

des angegebenen Wertes zu einem Abbruch kommt. Bei den Testdaten konnten zwar im

Rahmen der Voruntersuchungen bereits gute Kompressionsergebnisse mit diesen beiden

Kriterien erzielt werden, es werden jedoch nicht alle, in Tabelle II.1 genannten,

II.2 Datenmanagement 46

Anforderungen optimal erfüllt. Insbesondere die geforderte Anschaulichkeit der beiden

Parameter ist noch verbesserungswürdig. Es kann nicht unmittelbar aus den eingestellten

Parametern abgelesen werden, welche Informationen bei der Kompression als irrelevant

eingestuft wurden.

Auch wird der neu errechnete Mittelwert bei der Relevanzprüfung bislang noch überhaupt

nicht berücksichtigt. Da dieser Wert jedoch im Kompressionsergebnis die Repräsentation der

Originaldaten darstellt, sollte dieser zukünftig bei der Relevanzprüfung mit einbezogen

werden. Auch die Abweichung des aktuellen Wertes vom Startwert (P2) erscheint nicht

unbedingt sinnvoll. Dadurch wird der Startwert gegenüber den anderen Werten, über die die

Mittelwertbildung stattfindet, stärker berücksichtigt. Auch dieser Aspekt soll zukünftig

vermieden werden, damit der Startwert nur so stark Einfluss auf die Kompression nehmen

kann, wie alle übrigen Messwerte des aktuellen Blockes auch.

Um den aufgezeigten Aspekten Rechnung zu tragen, wird ein neuer Ansatz zur

Relevanzprüfung für die Kompression von Messwert-Zeitreihen entwickelt. Dieser Ansatz

stützt sich im Wesentlichen auf die folgenden drei Punkte:

• Der aktuelle Mittelwert mn (unter Berücksichtigung des neuen, zu prüfenden

Messwertes wn) soll bei der Relevanzprüfung berücksichtigt werden.

• Bezogen auf diesen Mittelwert soll eine maximal zulässige Abweichung dzul des

ursprünglichen Signalverlaufs definierbar sein.

• Sobald diese zulässige Abweichung dzul vom Verlauf des Originalsignals an

wenigstens einer Stelle überschritten wird, soll die Mittelwertbildung nach dem letzten

gültigen Wert wl abgebrochen werden und mit dem neuen Wert wn zum Zeitpunkt tn

von neuem beginnen.

In Bild II.31 soll dieser neue Ansatz zur Relevanzprüfung veranschaulicht werden.

Bild II.31 a) zeigt den vorherigen Mittelwert ml und die zulässige Abweichung dzul. Solange

sich der Verlauf des Originalsignals innerhalb dieses Toleranzbandes befindet, liegen keine

relevanten Informationen vor. Die Mittelwertbildung als Maßnahme zur Datenkompression ist

also zulässig, weil dabei nur irrelevante Informationen eliminiert werden. In Bild II.31 b) ist

nun auch der neue Mittelwert mn eingezeichnet, der nach Hinzukommen des neuen

Wertes wn berechnet wurde. Auch die maximal zulässige Abweichung ist in Bezug auf mn

dargestellt. Die dann durchgeführte Überprüfung zeigt, dass durch Hinzukommen des neuen

Wertes wn, der Verlauf des Originalsignals nicht mehr vollständig innerhalb des

Toleranzbandes liegt.

II.2 Datenmanagement 47

Bild II.31: Neues Relevanzkriterium für die Kompression der Messwert-Zeitreihe

II.2 Datenmanagement 48

Im dargestellten Beispiel liegt der Wert wl um den Betrag dmax vom neuen Mittelwert mn

entfernt. Da |dmax| größer als der zulässige Abstand dzul ist, liegt nun eine relevante

Information vor und deswegen kommt es zu einem Abbruch der Mittelwertbildung. Wie in

Bild II.31 c) gezeigt, wird beim Eintreten dieser Abbruchbedingung der vorherige

Mittelwert ml abgespeichert (zusammen mit dem Startzeitpunkt ts der bisherigen

Mittelwertbildung) und die Mittelwertbildung beginnt zum Zeitpunkt tn mit dem Wert wn von

neuem.

Algorithmische Umsetzung

Um der Anforderung nach einer Implementierbarkeit der Datenkompressionsmethode auf

einem mobiltauglichen Rechner nachzukommen, werden im Folgenden die wichtigsten

Schritte der algorithmischen Umsetzung der vorgestellten Datenkompressionsmethode

erläutert. Anschließend wird auf die prototypische, programmtechnische Umsetzung der

Methode in Form eines Stateflow-Charts eingegangen.

Die algorithmische Umsetzung der Kompressionsmethode gestaltet sich vergleichsweise

einfach: Um die Mittelwertbildung zu ermöglichen, muss nur die Summe aller Werte des

aktuellen Blockes sowie deren Anzahl bekannt sein. Das arithmetische Mittel kann dann

einfach durch Division gebildet werden. Für die Relevanzprüfung, also ob alle Punkte des

Originalsignals innerhalb der eingestellten Toleranz liegen, müssen zudem lediglich noch der

größte und der kleinste Wert des aktuellen Blocks bekannt sein. Jeder neu hinzukommende

und zu prüfende Wert wird zunächst mit den beiden bekannten Extrema des aktuellen Blocks

verglichen. Stellt der neue Wert ein neues Extremum dar, so wird eines der bisherigen

ersetzt. Danach erfolgt die Berechnung der größten Abweichung des Originalsignals

bezogen auf den neuen Mittelwert und es schließt sich ein Vergleich mit der maximal

zulässigen Abweichung an. Von diesem Vergleich hängt ab, ob durch die Hinzunahme des

neuen Wertes relevante Informationen verloren gehen würden und die Mittelwertbildung

deswegen abgebrochen wird, oder ob die Mittelwertbildung fortgesetzt werden kann, weil

keine Relevanz vorliegt.

Besonders hervorzuheben ist die Tatsache, dass, egal über welchen Zeitraum hinweg eine

Mittelung der Werte stattfindet, immer nur eine begrenzte und im Vorfeld bekannte Anzahl

von Variablen zwischengespeichert werden muss. Es ist also nicht notwendig, alle Werte des

aktuellen Blockes zwischenzuspeichern.

Bei der prototypischen, programmtechnischen Umsetzung in Form eines Stateflow-Charts,

welches in Bild II.32 dargestellt ist, wurden die o. g. Schritte konsequent umgesetzt.

II.2 Datenmanagement 49

START

(Zurück-)Setzen der Variablen

END---------START

state/

Nächste Nachricht lesen

Wert nicht einlesen solange keine neue Nachricht und somit auch kein neuer Wert vorliegt

Aktuellen Mittelwert bilden

Extremwerte aktualisieren

Überprüfen auf Abbruchbedingung

Abweichung berechnen

ODERSpeichern des aktuellen Mittel-wertes als letzten Mittelwert

ENTWEDERAusgabe des letzten Mittelwertes mit der Zeit des letzten Abbruchs

Unterfunktion zur Berechnung der Abweichung:

dev=get_deviation(Mean, Min, Max)

Allererste Nachricht lesen, ersten Wert und erste Zeit einlesen

{last_message = rx_time;new_value = value;new_time = time;reduced_mean = 0.0;reduced_time = 0.0;}

{item_number = 1;sum = new_value;mean = new_value;last_time = new_time;last_mean = new_value;min = new_value;max = new_value;}

{new_message = rx_time;new_value = value;new_time = time;}

{last_message = new_message;item_number ++;sum += new_value;mean = sum / item_number;}

[new_value < min]{min = new_value;}

[new_value > max]{max = new_value;}

[(deviation > maxDeviation)]

{deviation = get_deviation(mean, min, max);}

{last_mean = mean;}{reduced_mean = last_mean;reduced_time = last_time;}

[new_message == last_message]

123

1 2

1

2

eM

Bild II.32: Prototypische Implementierung des Kompressionsalgorithmus für Messwert- Zeitreihen in Form eines Stateflow-Charts

Dieses Stateflow-Chart ist Teil eines Simulink-Modells, welches durch Einstellen einer festen

Zykluszeit mit einer festen Sample-Rate arbeitet. Über definierte Eingangsvariablen werden

die zu komprimierenden Messwerte aus der Simulink-Umgebung an das Chart übergeben.

Zu jedem Sample-Zeitpunkt werden der jeweils aktuellste Messwert (value) sowie der

zugehörige Empfangszeitpunkt des Wertes (rx_time) an das Chart übergeben und dort

verarbeitet. Außerdem wird die Systemzeit (time) und der Kompressionsparameter dzul

(maxDeviation) übermittelt. In Klammern sind die Variablenbezeichungen in der Form

angegeben, wie sie im Chart verwendet wurden. Das Kompressionsergebnis, bestehend aus

Wert und Zeit, wird nach der internen Berechnung zu jedem Sample-Schritt über die

Variablen reduced_time und reduced_mean wieder an das Simulink-Modell ausgegeben.

Dabei handelt es sich immer um die Werte des letzten, bereits abgeschlossenen Blockes.

II.2 Datenmanagement 50

Über den zuvor beschriebenen algorithmischen Kern der Kompressionsmethode hinaus sind

in dem Chart noch einige zusätzliche Dinge zu erkennen. Zum Start des Programms werden

zunächst einige Variablen erstmalig mit Werten belegt. Dies geschieht, beginnend in der

oberen linken Ecke des Charts, durch abarbeiten der Befehle, die in geschwungenen

Klammern an den Transitionspfeilen stehen. Während des ersten Sample-Schritts läuft das

Programm bis zum sog. state (Zustand) und verharrt dort bis zum nächsten Sample-Schritt.

Bei jedem nun folgenden Sample-Schritt durchläuft das Programm, ausgehend vom state,

eine Programmschleife, die aus verschiedenen Transitionen zusammengesetzt ist.

Entsprechend der gerade vorliegenden Bedingungen, die in eckigen Klammern an den

Transitionen angegeben sind, werden diese durchlaufen. Dabei werden ggf. die in

geschwungenen Klammern angegebenen Befehle ausgeführt.

Als erstes wird im Rahmen dieser Programmschleife geprüft, ob es sich um einen neuen

Messwert handelt, der verarbeitet werden muss. Dies wird anhand des Empfangszeitpunktes

(rx_time) festgestellt. Dieser Schritt ist der festen Sample-Rate des Simulink-Modells

geschuldet. Ist die Sample-Rate des Modells höher als die Aktualisierungsrate des

Messwertes (der z. B. von einem CAN-Bus gelesen wird) so kann es vorkommen, dass ein

zuvor bereits verarbeiteter Messwert ein weiteres Mal eingelesen wird. Für den Fall, dass es

sich um einen solchen alten Wert handelt, wird dieser sofort verworfen und die

Programmschleife abgebrochen. Handelt es sich jedoch um einen neuen Wert, so folgen

zunächst die Neuberechnung des Mittelwertes und die Aktualisierung der Extrema. Danach

wird die größte Abweichung ermittelt. Dies geschieht mit Hilfe einer sog. Embedded-Matlab-

Funktion. Dieser Funktion werden der aktuelle Mittelwert (mean) sowie der kleinste (min) und

der größte Messwert (max) des aktuellen Blockes übergeben. Abschließend erfolgt die

Relevanzprüfung, die im positiven Fall zu einem Abbruch der Mittelwertbildung, zu einer

Ausgabe des vorherigen Mittelwertes und zum Zurücksetzen der Variablen führt. Für den

Fall, dass keine Relevanz vorliegt, wird der neue Mittelwert übernommen und ohne weitere

Aktionen an den Anfang der Programmschleife gesprungen.

II.2.1.3.3 Kompressionsmethode für Positionsdaten

In Abschnitt II.2.1.1 wurden neben den Messwert-Zeitreihen auch die Positionsdaten

ausgewählt. Im Rahmen dieses Abschnitts soll nun die Entwicklung einer Methode zur

Datenkompression für diese spezielle Datenart beschrieben werden. Die Positionsdaten

beinhalten die Information über den Aufenthaltsort einer Maschine zu einem bestimmten

Zeitpunkt. Erhoben werden diese Daten fast ausschließlich mit Hilfe satellitengestützter

II.2 Datenmanagement 51

Ortungssysteme. Als geodätisches Referenzsystem wird dabei im Normalfall WGS84

[WGS00] verwendet, da dieses System einheitlich für die ganze Erde gültig ist.

Die Entwicklungen zur Kompression der Messwert-Zeitreihen lassen sich nicht unmittelbar

auf die Positionsdaten übertragen. Dies liegt vor allen Dingen daran, dass die

Positionsinformation selbst in Form von zwei verschiedenen Werten – dem Längen- und dem

Breitengrad – vorliegt. Diese Wertepaare stehen i. d. R. nicht kontinuierlich zur Verfügung,

sondern werden von den Ortungssystemen zeitdiskret ausgeben. In der zeitlichen Folge

mehrerer solcher Wertepaare stecken außerdem weitere Informationen (wie z. B.

zurückgelegte Strecke, durchschnittliche Geschwindigkeit usw.), die ggf. auch einen Einfluss

auf die Relevanz der Positionsdaten nehmen können. Eine weitere Schwierigkeit besteht

darin, dass die beiden Werte jeweils als Winkelmaß angegeben sind. Dies hat zwar den

Vorteil, dass jede Position auf der Erdoberfläche mit nur zwei Koordinaten eindeutig

beschrieben werden kann. Jedoch haben diese Winkelmaße den Nachteil, dass sie sehr

abstrakt und damit sehr viel schwerer einschätzbar sind als z. B. Streckenangaben bzw.

Abstände in Metern.

Um möglichst anschauliche Relevanzkriterien definieren zu können, muss daher zunächst

eine Transformation der zu komprimierenden Positionsinformationen in ein lokales

kartesisches Koordinatensystem mit der Einheit Meter durchgeführt werden (Bild II.33). Dazu

wird eine Position als Ursprungspunkt des lokalen Koordinatensystems definiert, von dem

aus die X-Achse in Ost-Richtung und die Y-Achse in Nord-Richtung zeigt.

Alle anderen Positionen werden in Bezug zu diesem Punkt gesetzt, indem deren Abstände

zum Ursprung in X- und Y-Richtung berechnet werden. So lassen sich alle zu

komprimierenden Positionsdaten anschaulich in einem kartesischen Koordinatensystem

darstellen und mit der Einheit Meter bemaßen. Diese Transformation stellt einen

vorbereitenden Schritt für die anschließende Relevanzprüfung dar.

Da bei dieser Transformation die Oberfläche der Erdkugel als Ebene angenähert wird,

entstehen zwangsläufig Fehler, die mit zunehmendem Abstand vom Ursprung des lokalen

Koordinatensystems größer werden. Diese sind jedoch aus verschiedenen Gründen, die

später noch genauer betrachtet werden, zu vernachlässigen.

II.2 Datenmanagement 52

Bild II.33: Einführung eines lokalen kartesischen Koordinatensystems zur anschaulichen Darstellung und Bemaßung der Positionsinformationen

Bild II.34 veranschaulicht einige Aspekte, die bei der Bestimmung des Abstandes zwischen

zwei benachbarten Positionen und somit auch bei der Transformation der

Positionsinformationen in das lokale kartesische Koordinatensystem zu berücksichtigen sind.

Durch die Definition von Längen- und Breitengradbemaßung der Erde ergibt sich die

Tatsache, dass alle benachbarten Breitengrade an der Erdoberfläche den gleichen Abstand

zueinander haben. Daher lässt sich der Abstand Δy zwischen zwei benachbarten Positionen,

die auf dem selben Längengrad liegen, aus der Breitengraddifferenz Δφ und dem

Erdradius rE, der etwa 6378137 Meter beträgt [WGS00], an Hand der nachfolgenden

Gleichung näherungsweise ermitteln:

ΔϕΔ = ⋅ π ⋅ ⋅

°E2 r360

y (II.1)

Der Breitengrad, der durch den Ursprung des lokalen Koordinatensystems läuft, soll mit φU

und der Längengrad mit λU bezeichnet werden. Ist φP der Breitengrad der zu

transformierenden Position P und wird Δφ durch (φP – φU) ersetzt, so ist Δy gleich der Y-

Koordinate yP dieser Position im lokalen Koordinatensystem.

−⋅ϕ

= ⋅ π ⋅°ϕP U

P Ey 2360

r (II.2)

II.2 Datenmanagement 53

Äquator

Nordpol

Südpol

Breitengrad φ

Äquator

Nordpol

λ

Äquator

Nordpol

Südpol

Breitengrad φ

λ

φ

Längengrad λ

Längengrad λ

Erdr

adiu

s r E

rE · cos φ

ΔλΔx1

Δx2

rE · cos φ

rE

Bild II.34: Abhängigkeit des Längengradabstandes vom Breitengrad

Die Berechnung der X-Koordinate gestaltet sich etwas komplizierter, denn benachbarte

Längengrade weisen keinen konstanten Abstand zueinander auf. Mit zunehmender

Entfernung vom Äquator nimmt deren Abstand zueinander immer weiter ab, bis schließlich

an den Polen alle Längengrade in einem Punkt zusammenlaufen. Eine Längengraddifferenz

führt auf der Erdoberfläche zu einem Abstand in Ost-West-Richtung, der zusätzlich vom

Breitengrad φ abhängt, auf dem die beiden Positionen liegen. Bei der Umrechnung einer

Längengraddifferenz Δλ in einen Abstand Δx muss daher der Kosinus des Breitengrades φ

zur Korrektur aufmultipliziert werden. Dieser Zusammenhang wird in Bild II.34 deutlich.

Vereinfachend wird festgelegt, dass bei der Transformation der Positionsdaten für alle Werte

der Kosinus des Breitengrades φU berücksichtigt wird, der durch den Ursprung des lokalen

Koordinatensystems verläuft. Dadurch wird die Rücktransformation der kartesischen

II.2 Datenmanagement 54

Koordinaten nach der Kompression wesentlich vereinfacht, weil der Korrekturfaktor cos(φU)

dann für alle Positionsdaten den gleichen Wert hat.

ΔλΔ = ⋅ π ⋅ ϕ

°⋅ ⋅E Ux 2 r cos360

(II.3)

Ist λP der Längengrad der zu transformierenden Position P so kann Δλ durch (λP – λU) ersetzt

werden und damit entspricht Δx der X-Koordinate xP der Position P.

λ − λ= ⋅ π ⋅ ϕ⋅ ⋅

°P U

P E Ux 2 r cos360

(II.4)

Damit sind alle notwendigen Rechenvorschriften für die Transformation der Positionsdaten in

ein kartesisches Koordinatensystem bekannt. Für die Rücktransformation sind die beiden

Gleichungen II.2 und II.4 lediglich nach dem gesuchten Längen- bzw. Breitengrad des

jeweiligen Punktes umzustellen. Die Fehler, die bei der Transformation entstanden sind,

wirken sich nur auf die Darstellung der Positionsdaten im kartesischen Koordinatensystem

aus und sind in mitteleuropäischen Breiten selbst für Ausdehnungen des Koordinaten-

systems über zweihundert Kilometer vernachlässigbar (< 2,5 %). Bei der Rücktransformation

werden diese Fehler wieder kompensiert, so dass sich die Transformation nicht negativ auf

die Genauigkeit der komprimierten Positionsinformationen auswirkt.

Auch für diese Datenart soll bei der Entwicklung der Kompressionsmethode der Ansatz der

Irrelevanzreduktion gewählt werden. Nachfolgend müssen dafür zunächst geeignete

Relevanzkriterien entwickelt werden, bevor anschließend die algorithmische Umsetzung

beschrieben wird.

Relevanzkriterien

Um einen geeigneten Ansatz zur rechnergestützten Relevanzprüfung entwickeln zu können,

werden auch für die Positionsdatenkompression zunächst einige grundsätzliche Punkte

definiert:

• Der Kompressionsgewinn soll erzielt werden, indem irrelevante Positionsdaten nicht

abgespeichert werden.

• Das Kompressionsergebnis besteht ausschließlich aus den verbleibenden, als

relevant eingestuften Positionen, die bereits im Originalsignal enthalten waren.

• Über die einstellbaren Kompressionsparameter soll unter anderem die Unsicherheit

bzw. Ungenauigkeit begrenzt werden können, mit der die bei der Kompression

II.2 Datenmanagement 55

entfallenen Positionen nachträglich aus dem Kompressionsergebnis wieder

rekonstruiert werden können.

Über die Relevanz einer einzelnen Position kann im Normalfall nicht entschieden werden.

Erst die zeitliche Folge mehrerer Positionen, also der Wegverlauf, gibt Aufschluss über die

Relevanz der einzelnen Wegpunkte. Auf Grund der geforderten Online-Fähigkeit der

Algorithmen, muss schon bei der Wahl der Relevanzkriterien berücksichtigt werden, dass

eine Relevanzprüfung für jeden neu hinzu kommenden Wegpunkt zeitnah möglich sein

muss. Nur so kann sichergestellt werden, dass nur eine ganz beschränkte Anzahl von

Wegpunkten zwischengespeichert werden muss.

Nachfolgend sind in den Bildern II.35 bis II.38 einige typische Wegverläufe dargestellt, an

denen jeweils ein Kriterium deutlich wird, dass bei der Relevanzprüfung unbedingt

Berücksichtigung finden soll: Bei den Darstellungen dieser Wegverläufe wurde

vorausgesetzt, dass die einzelnen Wegpunkte (P1 bis Pn) mit einem konstanten zeitlichen

Abstand zueinander aufgezeichnet worden sind. Nur so lässt sich aus der Folge der

einzelnen Wegpunkte auch eine Aussage über die dazwischen liegende durchschnittliche

Geschwindigkeit ableiten. Dies ist notwendig, weil die Geschwindigkeit für die

Relevanzprüfung ein entscheidendes Kriterium darstellen kann.

Y-A

chse

Bild II.35: Kurswinkeländerung als Relevanzkriterium für die Positionsdatenkompression

Bild II.35 zeigt einen Weg, der, beginnend im Punkt P1, bis zum Punkt P5 weitgehend

geradlinig (mit einem nahezu konstanten Kurswinkel ω) verläuft. Im Punkt P5 jedoch stellt

sich eine deutliche Kurswinkeländerung Δω ein. Anschließend verläuft der Weg wieder

nahezu geradlinig bis zum Punkt P8. Eine deutliche Kurswinkeländerung stellt ein relevantes

Merkmal im Wegverlauf dar und soll daher bei der Kompression der Positionsdaten

berücksichtigt werden.

II.2 Datenmanagement 56

Ein weiterer exemplarischer Verlauf ist in Bild II.36 dargestellt. Vom Startpunkt P1 aus

verläuft der Weg weitgehend geradlinig auf den Endpunkt P6 zu. Einzig der Punkt P4 weist

eine auffallend große Querabweichung dq zur Hauptrichtung des übrigen Wegverlaufs auf.

Auch diese Querabweichung dq soll bei der Relevanzprüfung berücksichtigt werden. Dass im

Punkt P4 zusätzlich eine große Kurswinkeländerung vorliegt, soll an dieser Stelle nicht näher

betrachtet werden. Es macht jedoch deutlich, dass verschiedene Relevanzkriterien sich

durchaus überlagern oder sogar gegenseitig bedingen können.

X-Achse

P1

aufgezeichnete Wegpunkte Pi

P6P5

P4

P3P2

Querabw

eichung

dq

Bild II.36: Querabweichung als Relevanzkriterium für die Positionsdatenkompression

Ein drittes Relevanzkriterium ist in Bild II.37 dargestellt. Anders als bei den letzten beiden

Beispielen liegen hier alle Punkte ziemlich genau auf einer Linie. Das Relevanzkriterium ist

hierbei am Abstand der aufeinander folgenden Wegpunkte zu erkennen. Die

durchschnittliche Geschwindigkeit v zwischen zwei Punkten lässt sich näherungsweise aus

der Strecke Δs und der dafür benötigten Zeitdifferenz Δt mit Hilfe der Gleichung v = Δs / Δt

ermitteln. Da alle Wegpunkte im gleichen zeitlichen Abstand aufgezeichnet wurden, ist die

Geschwindigkeit proportional zum jeweiligen Punktabstand. Zwischen den Punkten P1

und P4 liegt demnach eine nahezu konstante und vergleichsweise hohe Geschwindigkeit vor.

Im Punkt P4 reduziert sich die Geschwindigkeit auf weniger als ein Drittel der bisherigen, was

an den wesentlich kleineren Abständen zwischen den Punkten P4 bis P7 zu erkennen ist.

Würde solch ein Geschwindigkeitsunterschied bei der Kompression nicht berücksichtigt, so

würde dies bei der späteren Rekonstruktion der eliminierten Wegpunkte einen Fehler in

Längsrichtung zur Folge haben. Um diesen Fehler einschränken zu können, sollen auch die

aus der Geschwindigkeitsdifferenz resultierende Längsabweichung dl als Relevanzkriterium

betrachtet werden.

II.2 Datenmanagement 57

Y-A

chse

Bild II.37: Aus der Geschwindigkeitsdifferenz resultierende Längsabweichung als Relevanzkriterium für die Positionsdatenkompression

Nachdem zuvor drei verschiedene Relevanzkriterien vorgestellt wurden, kommt nun ein

Irrelevanzkriterium hinzu, welches in Bild II.38 veranschaulicht ist. Unter gewissen

Bedingungen kann es dazu kommen, dass die Relevanzkriterien erfüllt sind, obwohl die

Informationen überhaupt nicht relevant sind. Um zu verhindern, dass dadurch irrelevante

Wegpunkte zu Lasten des Kompressionsergebnisses abgespeichert werden, ist die

Definition eines Irrelevanzkriteriums notwendig.

Y-A

chse

Δsm

ind

Bild II.38: Mindestabstand als Irrelevanzkriterium für die Positionsdatenkompression

Ein solcher Fall liegt vor, wenn aufeinander folgende Wegpunkte einen gewissen

Mindestabstand zueinander nicht überschreiten. Befindet sich die mobile Arbeitsmaschine im

Stillstand, liefert das Ortungssystem weiterhin in festen Zeitabständen die momentane

Position. Da dabei von kleineren Ungenauigkeiten ausgegangen werden muss, haben die

ermittelten Positionen fast nie genau den gleichen Wert, sondern es bildet sich eine Art

Punktewolke aus. Die ermittelten Positionen liegen dabei zwar in einem räumlich sehr eng

II.2 Datenmanagement 58

gefassten Bereich, aber das Relevanzkriterium der Kurswinkeländerung wird fast immer

erfüllt. In Bild II.38 ist dies sehr schön erkennbar. Bis zum Punkt P3 bewegt sich die

Maschine mit einer bestimmten Geschwindigkeit. Dann stoppt die Maschine; das

Ortungssystem zeichnet die Punkte P4 bis P8 jedoch weiterhin auf. Zwischen den Punkten P8

und P10 bewegt die Maschine sich wieder mit ihrer ursprünglichen Geschwindigkeit weiter.

Bei realen Messwerten wären sicherlich Verzögerungs- und Beschleunigungsphasen

ersichtlich, die in der idealisierten Darstellung jedoch bewusst vernachlässigt worden sind.

Es ist erkennbar, dass alle Punkte, die während der Stillstandszeit aufgezeichnet wurden,

einen Mindestabstand Δsmind zum Punkt P3 nicht überschreiten, die Kurswinkeländerung Δω

jedoch immer größer als 30 Grad ist. Um nicht alle diese irrelevanten Punkte abspeichern zu

müssen, kann ein Mindestabstand Δsmind definiert werden. Liegt ein neuer Punkt zu nah am

zuletzt gültigen, so wird der neue Punkt verworfen. Liegt ein neuer Punkt weiter als Δsmind

vom letzten gültigen Wegpunkt entfernt, erfolgt eine Prüfung an Hand der Relevanzkriterien.

Demnach wären die Punkte P4 bis P8 aus Bild II.38 als irrelevant einzustufen, erst der

Punkt P9 liegt wieder weiter als Δsmind von P3 entfernt.

Für den Fall, dass sich die Maschine nicht im Stillstand befindet, sondern noch mit sehr

geringer Geschwindigkeit fortbewegt, könnte das beschriebene Irrelevanzkriterium u. U.

auch wirksam werden. Auf das Kompressionsergebnis würde sich dies dann ähnlich wie eine

Herabsetzung der Abtastrate des Ortungssystems auswirken. Für sehr niedrige

Geschwindigkeiten ist dies durchaus akzeptabel und stellt somit kein Problem dar. Ein

Abdriften der Punktewolke wird dadurch verhindert, dass der Mindestabstand Δsmind nicht

zum letzten Punkt sondern zum letzten gültigen Punkt als Irrelevanzkriterium angesetzt wird.

Für die algorithmische Umsetzung, die im folgenden Abschnitt beschrieben ist, wird die

Reihenfolge, in der die vier vorgestellten Kriterien abgeprüft werden, einen entscheidenden

Einfluss auf das Kompressionsergebnis haben.

Algorithmische Umsetzung

Da die vier vorgestellten Kriterien nicht völlig losgelöst voneinander betrachtet werden

können, muss für die algorithmische Umsetzung der Relevanzprüfung eine geeignete

Reihenfolge der einzelnen Kriterien definiert werden. Dazu werden zunächst verschiedene

Aspekte und Bedingungen formuliert, die bereits aus dem vorangegangenen Abschnitt

bekannt sind.

II.2 Datenmanagement 59

• Die Überprüfung des Kriteriums „Punktabstand“ muss möglichst früh erfolgen, damit

irrelevante Punkte als solche erkannt werden, bevor die anderen Kriterien diese als

relevant deklarieren.

• Das Kriterium „Kurswinkeländerung“ darf erst nach dem Kriterium „Punktabstand“

abgefragt werden, da, insbesondere bei sehr kleinen Punktabständen (etwa im

Stillstand), der Kurswinkel sich fast immer sehr stark ändert. Die Kurswinkeländerung

ist aber bei sehr kleinen Punktabständen vernachlässigbar.

• Kriterien, die aufwendige Rechenschritte erfordern, sollten möglichst spät überprüft

werden. Für den Fall, dass andere Kriterien vorher zutreffen, werden so die

rechenintensiven Programmteile in der Programmschleife übersprungen. Das führt zu

einer Schonung von Rechnerressourcen.

• Das Kriterium „Längsabweichung“ muss vor dem Kriterium „Punktabstand“ überprüft

werden, da sonst ggf. (etwa beim Stillstand der Maschine) die Geschwindigkeit nicht

berechnet und somit das Kriterium Längsabweichung nicht vollständig geprüft werden

kann. Da dieses Kriterium jedoch zum Beginn und zum Ende einer Stillstandsphase

aufgrund der Geschwindigkeitsänderung fast immer relevant ist, muss dieses

unbedingt vor dem Kriterium „Punktabstand“ überprüft werden.

Aus diesen Punkten ergibt sich, dass die Längsabweichung als erstes geprüft werden muss.

Danach wird der Punktabstand untersucht. Von den verbleibenden beiden Kriterien wird

zunächst die Kurswinkeländerung geprüft, da diese mit weniger Rechenaufwand verbunden

ist als die abschließende Überprüfung der Querabweichung. In Tabelle II.4 sind die vier

Kriterien noch einmal in der erarbeiteten Reihenfolge zusammengefasst.

Die algorithmische Umsetzung dieser vier Kriterien soll im Folgenden beschrieben werden,

bevor anschließend die programmtechnische Umsetzung in Form eines Stateflow-Charts

erläutert wird.

Tabelle II.4: Relevanz- und Irrelevanzkriterien für die Positionsdatenkompression

Nr. Kriterium Art Merkmal

1 Längsabweichung Relevanz dl

2 Punktabstand Irrelevanz Δsmind

3 Kurswinkeländerung Relevanz Δω

4 Querabweichung Relevanz dq

II.2 Datenmanagement 60

Kriterium „Längsabweichung“

Bild II.39 zeigt einen beispielhaften Wegverlauf, bei dem das Kriterium der maximalen

Abweichung in Längsrichtung dl,max zutrifft. Bei der Überprüfung der Kriterien gilt für die

einzelnen Wegpunkte eine einheitliche Nomenklatur, die auch in Bild II.39 angewendet

wurde: Am letzten, als relevant abgespeicherten Punkt startet die Überprüfung. Dieser

Startpunkt ist mit Ps bezeichnet. Von Ps aus werden die folgenden Wegpunkte auf ihre

Relevanz überprüft. Liegt keine Relevanz vor, so wird die Überprüfung nach Hinzunahme

eines weiteren Punktes erneut durchgeführt. Der neueste Punkt wird dabei mit Pn und der

zuvor als letztes überprüfte Punkt mit Pl bezeichnet. Die einzelnen Momentangeschwin-

digkeiten der verschiedenen Wegschritte weisen in Bild II.39 einen großen Unterschied

zueinander auf.

Y-A

chse

Bild II.39: Relevanzkriterium Längsabweichung

Um die Berechnung der maximal möglichen Abweichung in Längsrichtung dl,max zu

ermöglichen, ohne alle zurückliegenden Wegpunkte zwischenspeichern zu müssen, wird

folgender Ansatz verwendet: Die, seit dem letzten abgespeicherten Wegpunkt Ps

aufgetretenen Extrema der Momentangeschwindigkeit, vmin und vmax, werden zwischen-

gespeichert. Bei jedem neu hinzu kommenden Punkt wird geprüft, ob die Momentan-

geschwindigkeit vl,n zwischen den beiden aktuellsten Punkten Pl und Pn ein neues Extremum

darstellt. Falls ja, wird das bisherige ersetzt. Außerdem kann die zwischen dem letzten

abgespeicherten Wegpunkt Ps und dem aktuell zu prüfenden Punkt Pn vorliegende

Durchschnittsgeschwindigkeit vm aus dem Abstand Δsges und der Zeitdifferenz (tn – ts) mit

guter Näherung bestimmt werden. Die drei Geschwindigkeiten vmin, vmax und vm charakteri-

sieren die Steigungen der drei Geraden im s-t-Diagramm, welches in Bild II.40 dargestellt ist

und die Herleitung von dl,max veranschaulicht. Die mögliche Abweichung in Längsrichtung

II.2 Datenmanagement 61

dl,max, die sich bei der späteren Rekonstruktion der irrelevanten Punkte maximal ergeben

kann, ist im Diagramm zwischen dem Schnittpunkt der beiden Geraden vmax und vmin und der

darüber liegenden Geraden vm am Zeitpunkt tdl,max abzulesen.

sn

ssts tn

Zeit t

Weg

s

d l,m

ax

vmin

vm v max

tdl,max

smin

smax

Startpunkt Ps

Neuer Punkt Pn

Bild II.40: s-t-Diagramm zur Veranschaulichung des maximal möglichen Fehlers in Längsrichtung dl,max

Zur Bestimmung von dl,max werden zunächst die Geradengleichungen für die beiden Extrema

der Momentangeschwindigkeit, vmin und vmax, aufgestellt:

( )= − +l,maxmin min d s ss v t t s (II.5)

( )= − +l,maxmin max d n ns v t t s (II.6)

Das Gleichsetzen der beiden Geradengleichungen liefert:

( ) ( )− + = − +l,max l,maxmin d s s max d n nv t t s v t t s (II.7)

Ausmultiplizieren und nach tdl,max auflösen:

− + = − +l,max l,maxmin d min s s max d max n nv t v t s v t v t s (II.8)

− = − + −l,max l,maxmin d max d min s max n n sv t v t v t v t s s (II.9)

II.2 Datenmanagement 62

− + −=

−l,max

min s max n n sd

min max

v t v t s stv v

(II.10)

Der Term (sn – ss) kann durch Δsges ersetzt werden.

− + Δ=

−l,max

min s max n gesd

min max

v t v t st

v v (II.11)

Damit ist tdl,max nun aus den gegebenen Größen berechenbar. Gleichung II.5 liefert einen

Ausdruck für smin und außerdem gilt für smax:

( )= − +l,maxmax m d s ss v t t s (II.12)

Für die gesuchte Größe dl,max gilt:

= −l,max max mind s s (II.13)

Das Einsetzen der Ausdrücke aus den Gleichungen II.5 und II.12 in Gleichung II.13 liefert

schließlich folgenden Ausdruck für dl,max:

( )( )= − −l,maxl,max m min d sd v v t t (II.14)

Dieser Wert für dl,max wird in der Programmschleife mit dem zulässigen

Längsabweichung dl,zul vergleichen, der als Kompressionsparameter vorgegeben ist. Ist dl,max

größer als dl,zul so liegt eine Abbruchbedingung vor: Punkt Pl wird abgespeichert und als

neuer Startwert Ps gesetzt. Liegt keine Abbruchbedingung vor, so folgt die Überprüfung des

Irrelevanzkriteriums Punktabstand.

Kriterium „Punktabstand“

Die Überprüfung des Irrelevanzkriteriums gestaltet sich vergleichsweise einfach: Bereits aus

der vorangegangenen Relevanzprüfung ist der Abstand Δsges zwischen dem Startpunkt Ps

und dem neuen Punkt Pn bekannt. Ist dieser Abstand Δsges kleiner als der notwendige

Mindestabstand Δsmind, so wird der neue Punkt als irrelevant eingestuft. Tritt dieser Fall ein,

wird einfach mit dem Einlesen des nächsten Punktes fortgefahren, ohne die übrigen

Relevanzprüfungen zu durchlaufen.

Wird der Punkt nicht als irrelevant eingestuft, d. h. wenn Δsges größer oder gleich Δsmind ist,

wird die Relevanzprüfung mit der Untersuchung der Kurswinkeländerung fortgesetzt.

II.2 Datenmanagement 63

Kriterium „Kurswinkeländerung“

Bild II.41 veranschaulicht an einem exemplarischen Wegverlauf, wie die Überwachung des

Kriteriums der maximalen Kurswinkeländerung Δω im Programm abläuft.

ωl,n

X-Achse

Ps

Pn

Pl Δω

Startpunkt Ps

Neuer Punkt Pn

Letzter Punkt Pl

Übrige Punkte Pi

ωs,l

Bild II.41: Relevanzkriterium Kurswinkeländerung

Die Kurswinkeländerung Δω beschreibt den Winkel, um den sich im Punkt Pl die Richtung

ändert, wenn der Weg vom Startpunkt Ps aus zunächst zum letzten Punkt Pl und von dort

aus zum neuen Punkt Pn verläuft. Dazu müssen zunächst für die Strecken PsPl und PlPn die

zugehörigen Kurswinkel ωs,l und ωl,n ermittelt werden. Alle Kurswinkel werden, ausgehend

von der Nordrichtung (Richtung der Y-Achse), im Uhrzeigersinn angegeben und können

Werte zwischen 0 und 360 Grad annehmen. Anhand von Bild II.42 soll die

programmtechnische Umsetzung der Kurswinkelberechnung erläutert werden.

ωA,B

X-Achse

Y-Achse

A

ByB

xB

AB

ω

Quadrant I

Quadrant IVQuadrant III

Quadrant II

Bild II.42: Prinzipielles Vorgehen zur Ermittlung des Kurswinkels

Zur Ermittlung des Kurswinkels der Geraden, die durch die beiden Punkte A und B verläuft,

müssen die Koordinaten xA und yA des Startpunkts A sowie xB und yB des Zielpunkts B

bekannt sein. Im Bild II.42 liegt der Punkt A genau im Ursprung des Koordinatensystems,

II.2 Datenmanagement 64

daher gilt hier der Sonderfall xA = yA = 0. Liegt der Punkt B, bezogen auf A, im ersten oder

vierten Quadranten, lässt sich ωA,B sehr einfach aus der Differenz in Y-Richtung Δy und der

Länge der Strecke AB mit Hilfe der Kosinusfunktion bestimmen. Mit Δx = xB - xA, Δy = yB - yA

und AB = √(Δx² + Δy²) gilt dann:

−ω =

− + −B A

A,B 2 2B A B A

y yarccos(x x ) (y y )

(II.15)

Für den zweiten und dritten Quadranten muss der mit Gleichung II.15 ermittelte Winkel von

360 Grad subtrahiert werden, um die vereinbarte Konvention zu erfüllen. In diesem Fall gilt:

−ω = ° −

− + −B A

A,B 2 2B A B A

y y360 arccos(x x ) (y y )

(II.16)

Es ist zu beachten, dass der Abstand zwischen den Punkten A und B niemals gleich null sein

darf, da dies zu einer Division durch null führen würde. Dies lässt sich durch die vorher

durchgeführte Überprüfung des Irrelevanzkriteriums Punktabstand jedoch sehr einfach

sicherstellen. Für die Fallunterscheidung, in welchem Quadranten der Kurswinkel liegt, bietet

sich die Betrachtung des Vorzeichens der Differenz in X-Richtung Δx = xB - xA an. Für den

Fall dass Δx positive Werte annimmt, ist zur Kurswinkelberechnung die Gleichung II.15 zu

verwenden, in allen anderen Fällen hingegen Gleichung II.16.

Nachdem damit die Bestimmung der beiden Kurswinkel ωs,l und ωl,n möglich ist, soll nun auf

die programmtechnische Umsetzung zur Bestimmung der Kurswinkeländerung Δω

eingegangen werden. Dazu wird zunächst die Differenz der beiden Kurswinkel berechnet.

β = ω − ωl,n s,l (II.17)

Dabei kann β Werte zwischen -360 und +360 Grad annehmen. Für Δω sind jedoch nur

Werte aus dem Intervall [-180,180] sinnvoll. Deswegen ist auch hier wieder eine

Fallunterscheidung nötig. Für Werte von β kleiner -180 Grad gilt:

Δω = β + °360 (II.18)

Für den Fall, dass β größer als 180 Grad ist, gilt:

Δω = β − °360 (II.19)

II.2 Datenmanagement 65

In allen anderen Fällen gilt:

Δω = β (II.20)

Da das Vorzeichen der Kurswinkeländerung nicht interessiert, wird zur Relevanzprüfung der

Betrag der Kurswinkeländerung gebildet und mit dem Kompressionsparameter Δωzul

verglichen. Ist |Δω| größer als Δωzul, liegt eine relevante Information vor und die

Relevanzprüfung wird abgebrochen. Trifft diese Bedingung nicht zu, wird die

Relevanzprüfung mit der Untersuchung des letzten Kriteriums (Querabweichung) fortgesetzt.

Kriterium „Querabweichung“

Wenn alle bisherigen Überprüfungen durch Hinzukommen des neuen Punktes Pn keine

relevanten Informationen identifiziert haben, so folgt als letztes die Überprüfung der

Querabweichung. Die prinzipielle Vorgehensweise hierzu ist in Bild II.43 veranschaulicht.

Y-A

chse

letzte Hauptric

htung

dq,tats2

dq,tats1

Bild II.43: Relevanzkriterium Querabweichung

Bei der Überprüfung des Kriteriums wird untersucht, ob durch Hinzunahme des neuen

Punktes Pn zu den zurückliegenden Punkten eine maximal zulässige Querabweichung dq,zul

überschritten wird. In Bild II.43 sind für die beiden Punkte Pmin und Pl die tatsächliche Quer-

abweichung dq,tats1 und dq,tats2 eingezeichnet. Diese Querabweichungen stehen senkrecht zur

Strecke PsPn, die, nach Hinzunahme von Pn, die neue Hauptrichtung darstellt. Diese

Abstände sollen, wenn sie von der Hauptrichtung aus betrachtet links liegen, ein negatives

Vorzeichen erhalten; liegen sie rechts davon soll ihr Wert positiv sein.

Wären die Koordinaten aller Punkte bekannt, so könnten auch alle, auf die Hauptrichtung

bezogenen, tatsächlichen Punktabstände berechnet und mit dem Kompressionspara-

II.2 Datenmanagement 66

meter dq,zul verglichen werden. Diese Vorgehensweise hätte jedoch einige entscheidende

Nachteile: Es müssten dazu alle Wegpunkte zwischengespeichert werden, die seit dem

letzten Abbruchkriterium auf Grund von Irrelevanz verworfen wurden. Dadurch würde sich

mit jedem zusätzlichen Punkt die Rechenzeit für die Prüfung des Kriteriums erhöhen. Weil

unter bestimmten Umständen jedoch sehr viele Punkte nacheinander verworfen werden

können (was auch die Voraussetzung für eine hohe Kompressionsrate darstellt), muss nach

einem anderen Weg gesucht werden, um den Anforderungen aus Abschnitt II.2.1.1 gerecht

zu werden. Darum soll für die Überprüfung des Kriteriums ein anderer Ansatz verwendet

werden, der im Folgenden erläutert wird.

Um die Anforderungen aus Abschnitt II.2.1.1 zu erfüllen, kann nur eine begrenzte Anzahl

zusätzlicher Punkte zwischengespeichert werden, egal wie viele Punkte seit dem letzten

Abbruchkriterium bereits zurückliegen. Da die Punkte mit jeder neuen Hauptrichtung aber

auch neue Abstände zu dieser einnehmen, ist die Auswahl geeigneter relevanter Punkte

entscheidend für die Überprüfung des Kriteriums. Neben den ohnehin gespeicherten

Punkten Ps, Pl und Pn sollen dazu zwei weitere Punkte, Pmin und Pmax, zwischengespeichert

werden, die in Bild II.43 eingezeichnet sind. Dabei handelt es sich um die Punkte, die, in

Bezug auf die letzte Hauptrichtung PsPl, am weitesten links (Pmin) und am weitesten rechts

(Pmax) liegen. Dabei zählt nicht der tatsächliche Abstand, sondern die Winkeldifferenz

zwischen der Richtung PsPmin bzw. PsPmax und der letzten Hauptrichtung PsPl.

Kommt eine neuer Punkt hinzu, liegt eine neue Hauptrichtung PsPn vor. In Bezug auf diese

neue Hauptrichtung werden dann die Abweichungen der bisherigen Extrempunkte Pmin und

Pmax ermittelt und mit dem Kompressionsparameter dq,zul verglichen. Dabei ist eine

Besonderheit zu beachten, die an dem exemplarischen Wegverlauf im Bild II.43 deutlich

erkennbar ist: Weil die Strecke PsPmin eine größere, negative Winkeldifferenz in Bezug auf

die neue Hauptrichtung aufweist als die Strecke PsPl (letzte Hauptrichtung), stellt Pmin

vereinbarungsgemäß den Extrempunkt dar, der links von der neuen Hauptrichtung liegt.

Dennoch ist erkennbar, dass die tatsächliche Querabweichung dq,tats2 des Punktes Pl größer

ist als die tatsächliche Abweichung dq,tats1 des Punktes Pmin. Für die Relevanzprüfung dürfen

daher nicht die tatsächlichen Querabweichungen dq,tats, sondern die möglichen

Querabweichungen dq,min und dq,max links und rechts der Hauptrichtung betrachtet werden.

Diese möglichen Abweichungen sind in Bild II.44 eingezeichnet.

II.2 Datenmanagement 67

Y-A

chse

letzte Hauptric

htung

dq,tats2

dq,tats1

Bild II.44: Ermittlung der möglichen Querabweichungen dq,min und dq,max

Zur Ermittlung von dq,min und dq,max wird zunächst der Differenzwinkel αmin (bzw. αmax) in

Bezug zur Hauptrichtung und die Länge der Strecke PsPn bestimmt. Die möglichen

Abweichungen können dann mit Hilfe der nachfolgenden Gleichungen berechnet werden:

= ⋅ αq,min s n mind P P sin (II.21)

= ⋅ αq,max s n maxd P P sin (II.22)

Dadurch, dass die Winkelangaben in Bezug auf die Hauptrichtung rechtsläufig positiv und

nach links hin negativ sind, werden, auf Grund der Sinusfunktion, auch die errechneten

Abweichungen, entsprechend der zu Beginn getroffenen Konvention, vorzeichenrichtig

ermittelt. Das ermöglicht die Unterscheidung zwischen dem linken Extrempunkt Pmin und dem

rechten Extrempunkt Pmax. Es zeigt sich in Bild II.44, dass die ermittelte mögliche

Abweichung dq,min betragsmäßig größer als die größte tatsächliche Abweichung dq,tats2 ist.

Das Kriterium wird daher zwar eher früher als später auslösen, ein größerer tatsächlicher

Punktabstand kann jedoch damit praktisch ausgeschlossen werden. Die möglichen

Abweichungen dq,min und dq,max stellen also geeignete Größen zur Überwachung des

Relevanzkriteriums Querabweichung dar. In der Programmschleife erfolgt nach der

Berechnung von dq,min und dq,max ein Vergleich mit der maximal zulässigen Querabweichung

dq,zul, die als Kompressionsparameter vorgegeben wird. Ist mindestens einer dieser Werte

betragsmäßig größer als dq,zul, fällt die Relevanzprüfung positiv aus. Dann wird der letzte

Punkt Pl abgespeichert und als neuer Startpunkt gesetzt. Außerdem wird Pn als neuer

rechter und linker Extrempunkt gesetzt und die Relevanzprüfung beginnt nach dem Einlesen

eines neuen Punktes von vorne. Fällt die Relevanzprüfung hingegen negativ aus, wird diese

II.2 Datenmanagement 68

ohne Zurücksetzen mit einem neuen Punkt fortgesetzt. In diesem Fall wird jedoch zunächst

noch geprüft, ob die bisherigen Extrempunkte Pmin und Pmax immer noch gültig sind oder ob

einer von ihnen durch den Punkt Pn ersetzt werden muss. Dies erfolgt ganz einfach durch

Untersuchung der Vorzeichen der zuvor berechneten Werte dq,min und dq,max: Falls der Wert

für dq,max kleiner als null ist, wird der bisherige Maximalpunkt Pmax durch Pn ersetzt. Wenn

dq,min größer als null ist dann wird Pmin durch Pn ausgetauscht. Trifft keines dieser beiden

Kriterien zu, dann stellt Pn kein neues Extremum dar und die bisherigen Extrempunkte gelten

weiterhin. Für das in Bild II.44 dargestellte Beispiel ist der Wert für dq,max kleiner als null (da

er links von der Hauptrichtung liegt) und deswegen würde hier der Punkt Pn als neuer

Maximalpunkt Pmax gesetzt werden.

Programmtechnische Umsetzung

Wie bereits der Algorithmus zur Messwert-Zeitreihenkompression (Abschnitt II.2.1.3.2),

wurde auch die Positionsdatenkompression in Form eines Simulink-Modells prototypisch

implementiert, welches mit einer festen Sample-Rate arbeitet. Die Programmschleife selbst

wurde dabei wieder als Stateflow-Chart umgesetzt, welches in Bild II.45 dargestellt ist. Viele

der zuvor dargestellten Rechenoperationen wurden dabei als Funktionen (sog. Embedded-

Matlab-Funktionen) ausgelagert. Diese finden sich im unteren Bereich des Charts in den

rechteckigen Kästen. Dem Chart werden zu Beginn eines jeden Sample-Schritts über

definierte Eingangsvariablen die zu komprimierenden Messwerte aus der Simulink-

Umgebung übergeben. Dazu gehören die jeweils aktuellsten Messwerte vom Ortungssystem

– Längen- (longitude) und Breitengrad (latitude) – sowie die Systemzeit (time) und die

zugehörige Empfangszeit (rx_time}) dieser Daten vom CAN-Bus. Als Kompressions-

parameter für die Relevanzprüfung werden die zulässige Längsabweichung dl,zul

(maxDeviation_long), der Mindestabstand Δsmind (minDistance), die zulässige Querab-

weichung dq,zul (maxDeviation_lat) sowie die zulässige Kurswinkeländerung Δωzul

(maxDirectionDiff) bereitgestellt. Das Kompressionsergebnis wird über die Variablen

reduced_longitude, reduced_latitude und reduced_t an das Simulink-Modell ausgegeben.

Zusätzlich erfolgt, zur leichteren Kontrolle und Visualisierung der Kompressionsergebnisse,

eine Ausgabe der Originaldaten (new_x und new_y) und des Kompressionsergebnisses

(reduced_x und reduced_y) in kartesischen Koordinaten. Beim Kompressionsergebnis wird,

auf Grund der festen Sample-Rate, immer der jeweils letzte relevante Punkt ausgegeben.

II.2 Datenmanagement 69

123

1

1 2

2

1

2

1

2

1

2

1

2

12

1

2

1

2

END---------START

state/

START Allererste Nachricht lesen

Allerersten Punkt einlesen und als ersten Startpunkt schreiben

Neuen Punkt einlesen

Letzten Punkt als neuen Startpunkt schreiben

Bedingungen für das Schreiben von Punkten

Ersten Punkt nach dem Startpunkt „merken“

Letzten Punkt „vergessen“ und aktuellen Punkt „merken“

Verlassen der Prüfschleife wenn aktueller Punkt zu nah am Startpunkt

Ende der Prüfschleife, kein Relevanzkriterium erfüllt Unterfunktionen:

Längsabweichung durch Änderung der Geschwin-digkeit berechnen

Richtungsänderung berechnen

Querabweichung berechnen

Extremwerte für Querabweichung gegebenenfalls aktualisieren

1.max.Längsabweichung

2.max.Richtungsänderung

3.max.Querabweichung

x_=get_x_meter(delta_longitude_, first_latitude_)

y_=get_y_meter(delta_latitude_)

red_lat=get_latitude(red_y, f_lat)

red_long=get_longitude(red_x, f_long, f_lat)

speed_=get_speed(a_X, a_Y, a_T, b_X, b_Y, b_T)

omega=get_heading(from_X, from_Y, to_X, to_Y)

dirDiff=get_directionDiff(A_x, A_y, B_x, B_y, C_x, C_y)

abs_distance=get_distance(from_x, from_y, to_x, to_y)

distanceToLine=get_distanceToLine(a_x, a_y, b_x, b_y, c_x, c_y)abs_result=get_abs(value1)

eM

eM

eM

eM

eM

eM

eM

eM

eM

eM

Nächste Nachricht lesen

Punkt nicht einlesen solange keine neue Nachricht vom GPS-Empfänger und somit auch kein neuer Punkt vorliegt

{lateral_deviation=deviationMax;}

[lateral_deviation > maxDeviation_lat]

[abs_directionDiff > maxDirectionDiff]

[longitudinal_deviation > maxDeviation_long]

[speed > speedMax]{speedMax = speed;}

[speed < speedMin]{speedMin = speed;}

{last_x = new_x;last_y = new_y;last_t = new_t;

item_number ++;}

[distance < minDistance]

[deviationMin > deviationMax]{lateral_deviation = deviationMin;}

[max_distanceToLine < 0]{max_x = new_x; max_y = new_y;}

[min_distanceToLine > 0]{min_x = new_x; min_y = new_y;}

{new_message = rx_time;}

[new_message == last_message]

{last_message = new_message;numOriginal ++;delta_latitude = latitude - first_latitude;delta_longitude = longitude - first_longitude;new_x = get_x_meter(delta_longitude, first_latitude);new_y = get_y_meter(delta_latitude);new_t = time;distance = get_distance(start_x, start_y, new_x, new_y);}

[item_number == 1]{last_x = new_x; last_y = new_y; last_t = new_t;min_x = new_x; max_x = new_x;min_y = new_y; max_y = new_y;speed = get_speed(start_x, start_y, start_t, last_x, last_y, last_t);speedMin = speed; speedMax = speed;item_number = 2;}

{speed = get_speed(last_x, last_y, last_t, new_x, new_y, new_t);speedMean = distance/(new_t - start_t);}

{t_maxDiff = (speedMin * start_t - speedMax * new_t + distance) / (speedMin - speedMax);longitudinal_deviation = (speedMean - speedMin) * (t_maxDiff - start_t);}

{directionDiff = get_directionDiff(start_x, start_y, last_x, last_y, new_x, new_y);abs_directionDiff = get_abs(directionDiff);}

{min_distanceToLine = get_distanceToLine(start_x, start_y, min_x, min_y, new_x, new_y);max_distanceToLine = get_distanceToLine(start_x, start_y, max_x, max_y, new_x, new_y);deviationMin = get_abs(min_distanceToLine);deviationMax = max_distanceToLine;}

{reduced_x = last_x;reduced_y = last_y;reduced_latitude = get_latitude(reduced_y, first_latitude);reduced_longitude = get_longitude(reduced_x, first_longitude, first_latitude);reduced_t = last_t;numReduced ++;start_x = last_x;start_y = last_y;start_t = last_t;item_number = 1;short_distance = 0;}

{last_message = rx_time;numOriginal = 1;first_latitude = latitude;first_longitude = longitude;new_x = 0;new_y = 0;new_t = time;reduced_x = new_x;reduced_y = new_y;reduced_latitude = latitude;reduced_longitude = longitude;reduced_t = new_t;numReduced = 1;start_x = reduced_x;start_y = reduced_y;start_t = reduced_t;item_number = 1;}

Bild II.45: Prototypische Implementierung des Algorithmus zur Positionsdaten- kompression in Form eines Stateflow-Charts

II.2 Datenmanagement 70

Zum Start des Programms werden zunächst wieder einige Variablen erstmalig mit Werten

belegt. Während des ersten Sample-Schritts läuft das Programm bis zum state. Bei jedem

nun folgenden Sample-Schritt durchläuft das Programm, ausgehend vom state, die

Programmschleife, die aus verschiedenen Transitionen zusammengesetzt ist und alle zuvor

beschriebenen Schritte der Relevanzprüfung abbildet. Zur Wahrung der Übersichtlichkeit und

zur mehrfachen Nutzbarkeit einmal implementierter Rechenschritte, wird dabei mehrmals auf

die ausgelagerten Funktionen zurückgegriffen.

Zunächst erfolgt anhand der rx_time eine Prüfung, ob es sich überhaupt um einen neue

Position handelt, die verarbeitet werden muss. Falls es sich um einen bereits verarbeitete

Position handelt, wird diese sofort verworfen und die Programmschleife abgebrochen.

Handelt es sich jedoch um einen neuen Wert, erfolgt noch die Umrechnung der Längen- und

Breitengradinformationen der jeweiligen Position in einen Punkt im lokalen kartesischen

Koordinatensystem. Daran schließen sich die vier Relevanzprüfungen in der zuvor

beschriebenen Reihenfolge an. Die Relevanzprüfungen ziehen sich entlang der Transitionen,

die senkrecht aus dem state heraus nach unten verlaufen. Die Transitionen, die von diesem

Pfad aus nach links verlaufen, haben als Bedingung das Vorliegen einer relevanten

Information. Die Transitionen auf dem Weg zurück in den state bewirken die

Rücktransformation und Ausgabe des Punktes Pn als Kompressionsergebnis sowie das

erforderliche Neusetzen verschiedener Variablen. So wird die Relevanzprüfung des

nächsten Punktes vorbereitet. Falls keine Relevanz vorliegt, wird die Programmschleife nach

rechts hin verlassen. Auf dem Weg zum state werden auch hierbei einzelne Variablen neu

gesetzt, sofern dies erforderlich ist.

II.2.1.4 Experimentelle Erprobungen

In diesem Abschnitt wird dargestellt, wie die verschiedenen Kompressionsmethoden im

Rahmen von experimentellen Erprobungen getestet wurden. Außerdem werden

verschiedene exemplarische Kompressionsergebnisse vorgestellt und subjektiv beurteilt.

II.2.1.4.1 Versuchstraktor und Entwicklungsumgebung

Die experimentellen Erprobungen wurden mit einem Traktor vom Typ Fendt 818 Vario

durchgeführt. Dieser Traktor verfügt über einen Dieselmotor mit einer Nennleistung von

132 kW, ein hydrostatisch-mechanisch-leistungsverzweigtes Stufenlos-Getriebe und ein

elektronisches Motor-Getriebe-Management (TMS). Außerdem ist der Traktor mit einem

Frontlader und mit einem elektronischen Lenk- und Rückfahrsystem der Firma Neumaier

II.2 Datenmanagement 71

ausgestattet. Bild II.46 zeigt die Maschine während der Feldversuche unter realen

Einsatzbedingungen bei der Bodenbearbeitung und beim Mähen.

Bild II.46: Versuchstraktor bei den Praxiseinsätzen zur Erprobung der Daten- kompressionsmethoden

Zur prototypischen Implementierung der Datenkompressionsalgorithmen wurde der Traktor

mit einer umfangreichen Entwicklungsumgebung ausgestattet, die im Folgenden kurz

vorgestellt werden soll. Das Hauptelement der Entwicklungsumgebung stellt eine sog. Rapid-

Control-Prototyping-Hardware der Firma dSPACE vom Typ MicroAutoBox 1401/1504 dar,

die vorne rechts in der Kabine des Traktors montiert ist. Ein Laptop, der im vorderen rechten

Bereich der Kabine in Reichweite des Fahrers mobiltauglich befestigt ist, dient als Host-PC

zur Programmierung, Steuerung und Überwachung der MicroAutoBox sowie zur

Aufzeichnung der Messdaten.

In Bild II.47 sind die einzelnen Elemente der Entwicklungsumgebung sowie deren

Montagepositionen am Versuchstraktor erkennbar. Zur Erhebung verschiedener Messwerte

kann die MicroAutoBox von drei CAN-Bussen des Traktors beliebige CAN-Botschaften

lesen. Neben einem Zugang zum sog. ISO-Bus (standardisiert nach ISO 11783), der über

die Gerätesteckdose am Traktorheck angeschlossen ist, besteht über zwei Steckdosen in

der rechten B-Säule der Kabine Zugriffsmöglichkeit auf die beiden traktorinternen Busse G-

Bus (Getriebe- und Motorinformationen) und K-Bus (u. a. Bedien- und Stellsignale). Als

Positionssensor kommt ein GPS-Ortungssystem vom Typ Trimble AgGPS 332 mit externer

Antenne zum Einsatz. Zur Steigerung der Positioniergenauigkeit wurde bei allen

durchgeführten Versuchen der kostenfreie Korrekturdatendienst EGNOS genutzt. Während

der Feldversuche bei der Bodenbearbeitung aktualisierte das System die Positionsdaten mit

einer Frequenz von 1 Hz. Für die Versuche im Mähbetrieb konnte die Aktualisierungsrate

durch eine geänderte Parametrierung auf einen Wert von 5 Hz gesteigert werden. Auch das

Ortungssystem übergibt seine Messwerte per CAN-Bus an die MicroAutoBox.

II.2 Datenmanagement 72

Bild II.47: Komponenten der Entwicklungsumgebung des Versuchstraktors

Zur übersichtlichen Verdrahtung der vier CAN-Kanäle mit der MicroAutoBox wurde eine

spezielle Anschlussbox mit mehreren D-Sub-Anschlussbuchsen aufgebaut. Hierüber besteht

auch die Möglichkeit, bis zu 24 analoge Messkanäle einzuspeisen. Die wetterfeste externe

Messtechnikbox, die vorne rechts außerhalb der Kabine montiert ist, dient zum Aufbau der

nötigen Messverstärker und der Spannungsversorgung. Im Rahmen der hier vorgestellten

Untersuchungen werden jedoch keine analogen Sensoren verwendet, da alle relevanten

Signale auf den CAN-Bussen verfügbar sind.

Zur Implementierung der Kompressionsalgorithmen auf der MicroAutoBox ist auf dem

Host-PC das Matlab-Softwarepaket in der Version R2006a (V7.2.0.232) installiert. Durch

automatische Code-Generierung wird aus den Kompressionsalgorithmen, die in Form von

Simulink-Modellen vorliegen, ein lauffähiger Programmcode für den digitalen Signal-

II.2 Datenmanagement 73

prozessor (DSP) der MicroAutoBox erzeugt und darauf übertragen. Der Programmablauf des

so erzeugten Codes kann über die Softwareanwendung ControlDesk, die von der Fa.

dSPACE bereitgestellt wird, vom Host-PC aus überwacht und beeinflusst werden. Außerdem

erfolgt darüber die Steuerung der Messwertaufzeichnung.

II.2.1.4.2 Feldversuche

Wie bereits in Bild II.46 dargestellt, wurden im Rahmen der hier vorgestellten Unter-

suchungen verschiedene Feldversuche durchgeführt. Ende August 2007 wurde der

Versuchstraktor einen Tag lang zur Bodenbearbeitung mit einem Grubber eingesetzt, der

über eine Arbeitsbreite von drei Metern verfügte. In weiteren Versuchen, die Ende Mai 2008

an zwei verschiedenen Tagen stattfanden, wurde der Traktor zusammen mit einem

Scheibenmähwerk (Arbeitsbreite 2,8 m) jeweils einige Stunden zur Grasmahd im ersten

Schnitt eingesetzt. Die im Zusammenhang mit den Feldversuchen notwendigen Straßen-

fahrten repräsentieren einen weiteren relevanten Einsatzbereich des Traktors und wurden

deshalb in die Untersuchungen eingeschlossen.

Während der ersten Feldversuche bei der Bodenbearbeitung wurde das Simulink-Modell mit

einer festen Zykluszeit von 0,1 s betrieben, was einer Frequenz von 10 Hz entspricht. Für die

Versuche im Mähbetrieb wurde die Zykluszeit auf 0,01 s reduziert und die Frequenz dadurch

auf 100 Hz gesteigert. Weil die aufgezeichneten und verarbeiteten CAN-Nachrichten über

Aktualisierungsraten von höchstens 50 Hz verfügen ist so sichergestellt, dass alle neuen

CAN-Nachrichten auch tatsächlich verarbeitet werden können und nicht zwischen den

Abtastschritten verloren gehen.

Mit den durchgeführten Feldversuchen wurden im Wesentlichen zwei Ziele verfolgt:

• Erprobung der Funktionsweise und Nachweis der Online-Fähigkeit der entwickelten

Kompressionsalgorithmen

• Erhebung verschiedener, unkomprimierter Messdaten (Originaldaten) unter

repräsentativen Einsatzbedingungen zur Weiterentwicklung und Optimierung der

Kompressionsalgorithmen im Rahmen von Simulation

Die aufgezeichneten Daten können nachträglich mehrfach in einem Offline-

Simulationsmodell unter Verwendung verschiedener Kompressionsparameter verarbeitet

werden. Bild II.48 veranschaulicht diesen Vorgang in Form eines Blockschaltbildes. Dadurch,

dass sowohl bei der Online- als auch bei der Offline-Erprobung der gleiche, in Simulink bzw.

II.2 Datenmanagement 74

Stateflow implementierte Kompressionsalgorithmus, verwendet wird, sind die erzielten

Kompressionsergebnisse direkt vergleichbar und eine subjektive Beurteilung wird möglich.

Bild II.48: Möglichkeit zur Komprimierung der Daten im Online- oder Offline-Betrieb

II.2.1.4.3 Erprobung der Kompressionsmethoden

Im Rahmen dieses Abschnittes werden einige exemplarische Ergebnisse dargestellt, die bei

der Anwendung der entwickelten Kompressionsmethoden auf verschiedene Daten erzielt

werden konnten. Neben der Variation der Datenart soll auch der Einfluss des gewählten

Kompressionsparameters an einigen Beispielen dargestellt werden.

Zunächst wird die Methode zur Kompression von Messwert-Zeitreihen auf mehrere

Datenarten angewendet. Dazu werden verschiedene Messgrößen ausgewählt, die

insbesondere mit Blick auf die Dynamik, sehr verschiedene Eigenschaften mitbringen. Durch

diese Vorgehensweise soll eine universelle Nutzbarkeit dieser Kompressionsmethode

demonstriert werden. Anschließend werden ausgewählte Ergebnisse der

Positionsdatenkompression vorgestellt. Hierbei wird zwischen dem Feldeinsatz und der

Straßenfahrt unterschieden.

Messwert-Zeitreihen

Für die Erprobung der Kompressionsmethode für Messwert-Zeitreihen wurden vier

verschiedene Messgrößen ausgewählt. Dabei handelt es sich um die Motortemperatur

(in °C), die Fahrgeschwindigkeit (in m/s), die Motordrehzahl (in 1/min) und die

Motorauslastung (in %). Diese Daten wurden bewusst gewählt, da sie verschiedene

Eigenschaften aufweisen, die für die Funktion und Arbeitsweise der Kompressionsmethode

relevant sein können. Nachfolgend soll auf die Messgrößen und die

Kompressionsergebnisse einzeln eingegangen werden. Bei den Untersuchungen wurde für

II.2 Datenmanagement 75

alle Messgrößen der in Abschnitt II.2.1.3.2 vorgestellte Kompressionsalgorithmus verwendet.

Der Kompressionsparameter dzul (maxDeviation) wurde dabei individuell variiert.

Motortemperatur

Bild II.49 zeigt den Verlauf der Motortemperatur während des gesamten Feldversuchstages

bei der Bodenbearbeitung, einschließlich der An- und Abfahrt von jeweils ca. 14 Kilometern.

Die Motortemperatur wurde vom traktorinternen G-Bus des Traktors gelesen und aufgezeich-

net. Die entsprechende CAN-Nachricht verfügt über eine Aktualisierungsrate von einem

Hertz und die Auflösung der Temperaturmesswerte beträgt ein Grad.

Bild II.49: Datenbasis Motortemperatur

Der Verlauf der Motortemperatur weist, auf Grund der physikalischen Eigenschaften des

Motorkühlsystems, nur eine sehr geringe Dynamik auf. Um den Einfluss des

Kompressionsparameters auf das Kompressionsergebnis besser beurteilen zu können, ist in

Bild II.49 ein Teilbereich des Signalverlaufs markiert. In Bild II.50 ist das Kompressions-

ergebnis für eine zulässige Abweichung dzul = 1 °C für diesen markierten Ausschnitt

dargestellt. Die angegebene Kompressionsrate und Einsparung bezieht sich jedoch auf den

gesamten Signalverlauf.

In Tabelle II.5 sind alle Kompressionsergebnisse aufgelistet, die im Rahmen der

Erprobungen mit verschiedenen Werten für dzul erzielt wurden. Die durchweg hohen

Kompressionsraten sind auf die sehr geringe Dynamik des Messwertes zurückzuführen. Weil

sich die Temperatur nur vergleichsweise langsam ändert, haben aufeinander folgende

Messwerte sehr häufig den gleichen Wert. Diese Redundanzen werden vom

Kompressionsalgorithmus bei dzul = 0 sehr erfolgreich eliminiert und führen bereits zu

Einsparungen von über 96 %. Für Werte von dzul > 0 werden zusätzlich Irrelevanzen aus der

II.2 Datenmanagement 76

ursprünglichen Datenmenge eliminiert, wodurch das Kompressionsergebnis noch weiter

gesteigert werden kann. Dabei ist allerdings zu beachten, dass eine weitere Steigerung des

Kompressionsgewinns nur noch zu Lasten des Informationsgehaltes möglich ist.

Bei den Untersuchungen konnten mit Werten für dzul zwischen 0,5 und 2 Grad, subjektiv

betrachtet, sehr günstige Verhältnisse zwischen Kompressionsgewinn und Informations-

verlust erzielt werden.

Bild II.50: Motortemperatur: dzul = 1 °C; CR= 104; Einsp.: 99,04 %

Tabelle II.5: Kompressionsergebnisse für die Motortemperaturdaten

dzul [°C]

CR -

Einsparung [%]

Bild-Nr.

0 28,3 96,46

0,5 30,6 96,73

1 104 99,04 II.50 1,5 167 99,40

2 248 99,60

3 528 99,81

4 975 99,90

5 1192 99,92

Fahrgeschwindigkeit

Die Fahrgeschwindigkeitsdaten, die in Bild II.51 dargestellt sind, stellen die zweite Datenart

dar, an der der Kompressionsalgorithmus erprobt wurde. Die Daten wurden vom ISO-Bus

des Traktors während eines etwa zwei Stunden dauernden Feldeinsatzes beim Grasmähen

II.2 Datenmanagement 77

aufgezeichnet und es handelte sich dabei um die im Getriebe ermittelte, theoretische

Fahrgeschwindigkeit (ohne Schlupf). Die erste halbe Stunde der Aufzeichnung entfiel dabei

auf die ca. zehn Kilometer lange Anfahrt. Die Rückfahrt wurde nur zu einem kleinen Teil

aufgezeichnet.

Bild II.51: Datenbasis Fahrgeschwindigkeit

Eine Besonderheit der Geschwindigkeitsdaten ist, dass diese, insbesondere im Feldeinsatz,

sehr oft zwischen positiven und negativen Werten wechseln können. Im Vergleich zur

Motortemperatur weisen die Fahrgeschwindigkeitsdaten eine wesentlich höhere Dynamik

auf. Auf Grund der dynamischen Vorgänge beim Bremsen und Beschleunigen des Traktors

sind deren Änderungsraten jedoch begrenzt.

Die Fahrgeschwindigkeitsinformation ist mit einer Aktualisierungsrate von zehn Hertz und

einer Auflösung von 0,001 m/s auf dem ISO-Bus verfügbar. Da die Geschwindigkeit und die

Fahrtrichtung getrennt in der Nachricht enthalten sind, erfolgt zunächst eine Umrechnung in

einen vorzeichenbehafteten Wert, dessen Verlauf in Bild II.51 dargestellt ist. Auch hier ist

wieder ein repräsentativer Ausschnitt markiert, für den nachfolgend in Bild II.52 ein

beispielhaftes Kompressionsergebnis dargestellt ist. Die Tabelle II.6 enthält alle

Kompressionsergebnisse, die für diese Datenart ermittelt wurden.

II.2 Datenmanagement 78

Bild II.52: Fahrgeschwindigkeit: dzul = 0,2 m/s; CR= 20,0; Einsp.: 95,01 %

Tabelle II.6: Kompressionsergebnisse für die Fahrgeschwindigkeitsdaten

dzul [m/s]

CR -

Einsparung [%]

Bild-Nr.

0 1,61 38,03

0,2 20,0 95,01 II.52 0,3 29,4 96,60

0,4 38,7 97,42

0,5 47,9 97,91

1 98,9 98,99

2 242 99,59

Auch hier werden mit dzul = 0 zunächst nur die redundanten Informationen eliminiert, was

bereits zu einer Einsparung von knapp 40 % führt. Durch schrittweise Erhöhung von dzul

ergeben sich zunehmend größer werdende Einsparungen. Im Rahmen der Untersuchungen

führten Werte zwischen 0,2 und 0,5 m/s für dzul zu einem sehr günstigen Verhältnis zwischen

Kompressionsgewinn und Informationsverlust.

II.2 Datenmanagement 79

Motordrehzahl

Vom selben Feldeinsatz wie die zuvor betrachtete Fahrgeschwindigkeit stammen auch die

Motordrehzahldaten, die in Bild II.53 dargestellt sind. Auch diese Motordrehzahldaten

wurden vom ISO-Bus des Versuchstraktors gelesen. Die entsprechenden CAN-Botschaften

auf diesem Bus werden mit einer festen Rate von 50 Hertz fortlaufend aktualisiert und die

Motordrehzahlwerte sind mit 0,125 1/min aufgelöst.

Bild II.53: Datenbasis Motordrehzahl

Da die Motordrehzahl sich sehr viel dynamischer verändern kann als die bislang

betrachteten Messgrößen, ist in Bild II.53 nur ein sehr schmaler Bereich markiert, für den

nachfolgend in Bild II.54 ein exemplarisches Kompressionsergebnis vergrößert dargestellt

ist. Weitere Kompressionsergebnisse sind der Tabelle II.7 zu entnehmen. Auch hier wird für

dzul = 0 deutlich, dass allein durch die Eliminierung der redundanten Informationen bereits ein

großer Teil der Datenmenge eingespart werden kann. Für den betrachteten Signalverlauf

stellen Kompressionsparameter dzul aus dem Wertebereich von 10 bis 20 1/min einen guten

Kompromiss zwischen Informationsverlust und Kompressionsgewinn dar.

II.2 Datenmanagement 80

Bild II.54: Motordrehzahl: dzul = 20 1/min; CR= 25,4; Einsp.: 96,07 %

Tabelle II.7: Kompressionsergebnisse für die Motordrehzahldaten

dzul [1/min]

CR -

Einsparung [%]

Bild-Nr.

0 5,60 82,15

2 7,44 86,56

5 7,44 86,56

10 13,3 92,47

15 16,9 94,08

20 25,4 96,07 II.54 50 161 99,38

100 613 99,84

II.2 Datenmanagement 81

Motorauslastung

Als letztes wurde die Methode zur Kompression von Messwert-Zeitreihen auf

Motorauslastungsdaten angewendet, die – genau wie auch die beiden vorangegangenen

Messgrößen – während des Feldversuchstages im Mähbetrieb aufgenommen wurden.

Bild II.55 zeigt den Verlauf über die Dauer von fast zwei Stunden.

Bild II.55: Datenbasis Motorauslastung

Die Motorauslastung kann mit einer Auflösung von einem Prozentpunkt vom sog. G-Bus des

Versuchstraktors gelesen werden, auf dem die zugehörige CAN-Nachricht mit einer

Frequenz von 20 Hertz fortlaufend aktualisiert wird. Der Wert beschreibt, zu wie viel Prozent

das bei aktueller Drehzahl mögliche Drehmoment des Motors (Drehmomentdachkurve)

durch das tatsächliche Motordrehmoment ausgeschöpft ist.

Bei der Motorauslastung handelt es sich, verglichen mit den anderen betrachteten Daten, um

die Messgröße mit der höchsten Dynamik. Einsatzbedingt oder auch ausgelöst durch

bestimmte Eingriffe des Maschinenbedieners kann der Wert der Motorauslastung sich quasi

sprunghaft zwischen 0 und 100 Prozent verändern. Diese Tatsache wird beispielsweise in

Bild II.55 in der ersten halben Stunde während der Straßenfahrt deutlich. Die

Motorauslastung schöpft den Wertebereich hier voll aus. Aber auch während des

Mähbetriebs (weiter rechts in Bild II.55 zwischen t = 0,6 und 1,8 h) schwankt das Signal in

einem wesentlich weiteren Bereich als z. B. die Motordrehzahl (vergl. Bild II.53).

Um die Kompressionsergebnisse visuell, subjektiv beurteilen zu können, ist auch hier nur ein

sehr kurzer Zeitbereich in Bild II.55 markiert und in Bild II.56 vergrößert dargestellt. Die

II.2 Datenmanagement 82

Ergebnisse weiterer Untersuchungen mit variiertem Kompressionsparameter dzul sind in

Tabelle II.8 aufgelistet.

Durch den hochdynamischen Signalverlauf, beinhaltet der untersuchte Datensatz weniger

als 35 % redundante Messwerte. Bei Werten für dzul von ein bis drei Prozentpunkten werden

bei akzeptablem Informationsverlust nur vergleichsweise kleine Einsparungen zwischen 70

und 90 Prozent erzielt. Wird der Kompressionsparameter vergrößert, so lassen sich zwar

höhere Kompressionsgewinne erzielen, das Kompressionsergebnis insgesamt ist jedoch

dann aufgrund des stark wachsenden Informationsverlustes nicht mehr optimal.

Bild II.56: Motorauslastung: dzul = 3 %; CR= 8,49; Einsp.: 88,22 %

II.2 Datenmanagement 83

Tabelle II.8: Kompressionsergebnisse für die Motorauslastungsdaten

dzul [%]

CR -

Einsparung [%]

Bild-Nr.

0 1,54 34,87

1 3,53 71,68

2 5,90 83,05

3 8,49 88,22 II.56 4 11,5 91,28

5 14,6 93,15

10 34,7 97,12

20 114 99,12

Positionsdaten

Die Erprobung der in Abschnitt II.2.1.3.3 entwickelten Methode zur Kompression von

Positionsdaten soll im Rahmen dieses Abschnitts an Hand von zwei Einsatzfällen durch-

geführt werden. Dabei wird zwischen dem Feldeinsatz und der Straßenfahrt des Traktors

unterschieden. Da diese beiden Fälle verschiedene Eigenschaften und Anforderungen mit

sich bringen, die für die Arbeitsweise der Kompressionsmethode und das Kompressions-

ergebnis relevant sein können, sollen beide getrennt untersucht werden.

Bei den Untersuchungen werden nur die vier Kompressionsparameter individuell variiert, um

deren Einfluss auf das Kompressionsergebnis zu veranschaulichen. Der verwendete

Kompressionsalgorithmus ist jedoch bei allen Erprobungen identisch.

Feldeinsatz

Da sich die Positionsverläufe des Traktors zwischen dem Feldeinsatz bei der Boden-

bearbeitung und beim Mähen ohnehin nur unwesentlich unterscheiden, beschränken sich

alle hier dargestellten Ergebnisse auf die Feldversuche im Mähbetrieb. Im Mähbetrieb

wurden die Positionsinformationen des Ortungssystems zudem mit einer Frequenz von fünf

Hertz und damit fünf Mal so häufig wie während der Bodenbearbeitung aktualisiert. Aus

diesem Grund enthalten diese Positionsdaten mehr Informationen und spiegeln somit den

tatsächlichen Fahrspurverlauf auch genauer wider.

Bild II.57 zeigt den Positionsverlauf des Traktors während eines Mäheinsatzes auf einem

Schlag von etwa einem Hektar Größe ca. sechs Kilometer westlich von Braunschweig. Im

Bild sind auf dem Schlag zwei Hindernisse, ein Baum und ein Baumstumpf, erkennbar, die

II.2 Datenmanagement 84

beim Mähen umfahren werden mussten. Da der Schlag bereits vor Beginn der

Messwertaufzeichnungen rundherum auf einer Breite von ca. acht Metern freigemäht worden

war, beschränken sich die Messwerte auf den verbleibenden, mittleren Teil. Der dargestellte

Positionsverlauf wurde über einen Zeitraum von 68 Minuten aufgezeichnet und setzt sich aus

der zeitlichen Abfolge von mehr als 20.000 diskreten Positionsinformationen zusammen.

Bild II.57: Positionsdatenverlauf während eines Mäheinsatzes

Nachfolgend sollen, anhand des in Bild II.57 gezeigten Positionsverlaufs, die Wirkungsweise

der Kompressionsmethode und der Einfluss der vier Kompressionsparameter untersucht

werden. Um die Arbeitsweise der Kompressionsmethode nachvollziehbar zu gestalten und

eine Beurteilung des Kompressionsergebnisses zu erleichtern, wurde eine Möglichkeit

geschaffen, die im Kompressionsergebnis kenntlich macht, welches der drei Relevanz-

kriterien (Längsabweichung, Kurswinkeländerung oder Querabweichung) zum Abspeichern

einer Position geführt hat.

In Tabelle II.9 sind alle Parametersätze aufgelistet, die im Rahmen der Erprobungen bei

Anwendung der Kompressionsmethode auf die Beispieldaten untersucht wurden. Enthalten

sind außerdem die dabei erzielten Kompressionsergebnisse; die letzte Spalte gibt die

Bildnummer an, in der das Kompressionsergebnis für die jeweilige Parameterkombination

dargestellt ist. Die Visualisierung des Kompressionsergebnisses in Bild II.58 beschränkt sich

auf den in Bild II.57 markierten Bereich am nördlichen Vorgewende des Schlages. Dieser

Bereich wurde für die visuelle Beurteilung des Ergebnisses als repräsentativ ausgewählt, da

II.2 Datenmanagement 85

er neben längeren geraden Positionsverläufen auch Kurven verschiedener Radien sowie

Wendemanöver des Traktors beinhaltet.

Bei den Erprobungen wurde ein Parametersatz ausgewählt, der ein sehr günstiges

Verhältnis von Kompressionsgewinn zu Informationsverlust aufweist. Für die vergleichende

Beurteilung der Parametereinflüsse im Rahmen der durchgeführten Untersuchungen diente

dieser Parametersatz daher als Referenz. Das Kompressionsergebnis, welches mit dieser

Referenzparametrierung erzielt wurde, ist in Bild II.58 dargestellt. Der Mindestpunkt-

abstand Δsmind (Irrelevanzkriterium) beträgt dabei 0,3 m. Die bei der Rekonstruktion der

eliminierten Punkte maximal zulässige Abweichung beträgt in Längsrichtung (dl,zul) und in

Querrichtung (dq,zul) jeweils 0,5 m. Kurswinkeländerungen Δωzul kleiner als 30 Grad werden

vom Kompressionsalgorithmus als irrelevant eingestuft.

Bild II.58: Referenzparametrierung für die Positionsdatenkompression im Feldeinsatz, CR = 26,9; Einsp.: 96,29 %

Für die Referenzparametrierung fällt auf, dass jedes der drei Relevanzkriterien bei der

Kompression - zumindest einige Male - zugetroffen hat. Bei den Wendevorgängen mit Fahrt-

richtungswechsel kam es häufig zu relevanten Kurswinkeländerungen; beim Verzögern des

Traktors bei Erreichen des Vorgewendes war meist das Kriterium Längsabweichung relevant

und während der Fahrten am Vorgewende mit konstantem Kurvenradius sorgte i. d. R. das

II.2 Datenmanagement 86

Kriterium Querabweichung für das Abspeichern der verbleibenden Wegpunkte. Während der

Geraden haben die Kriterien Längs- und Querabweichung etwa gleich häufig, insgesamt

jedoch nur wenige Male ausgelöst. Weiter ist erkennbar, dass die tatsächliche Querab-

weichung des Kompressionsergebnisses vom ursprünglichen Positionsverlauf überall

wesentlich geringer als die zulässigen 0,5 Meter ist. Diese Tatsache ist auf die Wirkungs-

weise des Kompressionsalgorithmus zurückzuführen und in Abschnitt II.2.1.3.3 ausführlich

erläutert worden.

Der in Bezug auf den vorherigen Parametersatz bzw. auf die Referenzparametrierung

variierte Parameter des jeweiligen Versuchsdurchlaufs ist in Tabelle II.9 fett hervorgehoben,

um die Übersichtlichkeit zu verbessern.

Tabelle II.9: Kompressionsergebnisse für die Positionsdaten aus dem Feldeinsatz

Δsmind [m]

dl,zul [m]

Δωzul [°]

dq,zul [m]

CR -

Einsparung [%]

Bild-Nr.

0,3 0,5 30 0,5 26,9 96,29 II.58 0,3 0,5 30 0,2 18,1 94,47

0,3 0,5 30 0,1 10,7 90,69

0,3 0,1 30 0,1 8,77 88,59

0,1 0,1 30 0,1 8,56 88,32

0,3 1 30 0,5 31,4 96,82

0,3 1 30 1 39,2 97,45

0,3 2 30 1 45,7 97,81

0,3 100 30 1 49,8 97,99

1 100 30 1 54,3 98,16

0,3 0,5 5 0,5 7,58 86,80

0,3 0,5 10 0,5 19,0 94,74

0,3 0,5 20 0,5 26,3 96,20

0,3 0,5 50 0,5 27,1 96,31

0,3 0,5 90 0,5 27,5 96,36

Straßenfahrt

In diesem Abschnitt soll die entwickelte Methode zur Geodatenkompression abschließend

noch an Positionsdaten erprobt werden, die während der Straßenfahrt des Traktors auf dem

Weg von einem der Mäheinsätze zurück zum Institut aufgezeichnet wurden. In Bild II.59 ist

der Positionsverlauf in eine Kartendarstellung projiziert dargestellt, auf dessen Grundlage die

nachfolgenden Untersuchungen durchgeführt wurden.

II.2 Datenmanagement 87

Bild II.59: Positionsdatenverlauf während der Straßenfahrt

In dieser Darstellung fällt auf, dass der Positionsdatenverlauf an einigen Stellen Lücken

aufweist, an denen keine aktuellen Positionsdaten aufgezeichnet worden sind. In diesen

Bereichen hat der GPS-Empfänger wegen Signalabschattungen zeitweise keine gültige

Positionsinformation ermitteln können. Auf dem befahrenen Streckenteilstück der Bundes-

straße 1 zwischen der Einfahrt Lamme und Lehndorf sind diese temporären Abschattungen

auf den Allee-Baumbestand und im Stadtbereich Braunschweig auf die Brückenunter-

querung im Bereich der Bundesautobahn 391 und die meist beidseitige mehrgeschossige

Randbebauung zurückzuführen.

Da auch solche unvollkommenen Originaldaten vom Kompressionsalgorithmus ordnungs-

gemäß verarbeitet werden müssen, ist der vorliegende Positionsverlauf für die Erprobung

der Kompressionsmethode sehr gut geeignet. Es muss jedoch bedacht werden, dass Unge-

nauigkeiten oder gar Lücken in den Originaldaten durch den Kompressionsalgorithmus nicht

kompensiert werden können. Auch die Unsicherheiten, die sich durch Wahl geeigneter Kom-

pressionsparameter begrenzen lassen, gelten lediglich für die Rekonstruktion des ge-

messenen Positionsverlaufs (einschließlich eventueller Messfehler) aus dem Kompressions-

ergebnis, nicht jedoch für die Rekonstruktion des tatsächlich zurückgelegten Positions-

verlaufs.

Bild II.60 zeigt das Kompressionsergebnis für den in Bild II.59 markierten Teilabschnitt der

Straßenfahrt bei Verwendung der Referenzparametrierung aus dem zuvor dargestellten

II.2 Datenmanagement 88

Feldeinsatz. Dabei wird eine sehr gute Übereinstimmung des Kompressionsergebnisses mit

dem Original-Positionsverlauf deutlich. Es fällt aber gleichzeitig auf, dass das

Kompressionsergebnis, trotz gleicher Parametrierung, mit einer Einsparung von unter

89 Prozent bei der Straßenfahrt wesentlich schlechter ausfällt als bei der Kompression des

Positionsdatenverlaufs im Feldbetrieb (96,29 %, vergl. Bild II.58). Dies ist darauf

zurückzuführen, dass bei den durchweg höheren Geschwindigkeiten während der

Straßenfahrt auch die zulässigen Grenzwerte häufiger überschritten werden und deswegen

folgerichtig auch mehr Punkte als relevant eingestuft werden.

Bild II.60: Referenzparametrierung aus dem Feldeinsatz angewendet zur Positionsdatenkompression der Straßenfahrt, CR = 8,83; Einsp.: 88,67 %

In Tabelle II.10 sind alle Kompressionsergebnisse aufgelistet, die mit verschiedenen

Parametersätzen im Rahmen der Untersuchungen erzielt wurden.

Tabelle II.10: Kompressionsergebnisse für die Positionsdaten der Straßenfahrt

Δsmind [m]

dl,zul [m]

Δωzul [°]

dq,zul [m]

CR -

Einsparung [%]

Bild-Nr.

0,3 0,5 30 0,5 8,83 88,67 II.60 2 2 50 2 19,2 94,80 II.61 2 5 50 5 31,7 96,85

2 20 50 20 60,9 98,36

2 100 50 100 129 99,23

2 100 30 100 92,4 98,92

5 1000 30 2 26,9 96,29

5 1000 30 5 44,6 97,76

5 1000 30 20 80,8 98,76

5 1000 30 100 110 99,09

5 1000 15 100 64,7 98,45

5 1000 90 100 192 99,48

II.2 Datenmanagement 89

Da bei der Straßenfahrt davon ausgegangen werden kann, dass die Genauig-

keitsanforderungen an das Kompressionsergebnis geringer sind als beim Feldeinsatz, wird

zunächst untersucht, welche Auswirkung die Vergrößerung der Kompressionsparameter dq,zul

und dl,zul auf das Kompressionsergebnis hat. Zudem wird auch der Mindestpunktabstand

Δsmind auf einen Wert von zwei Metern und die zulässige Kurswinkeländerung Δωzul auf einen

Wert von 50 Grad erhöht.

Das dabei mit Werten für dl,zul und dq,zul von jeweils zwei Metern erzielte Kompressions-

ergebnis, welches in Bild II.61 dargestellt ist, zeigt trotz einer Verdopplung der Kom-

pressionsrate noch eine sehr gute Übereinstimmung mit dem Originalverlauf und dient daher

für die Positionsdatenkompression der Straßenfahrt als neue Referenzparametrierung.

Bild II.61: Neue Referenzparametrierung für die Positionsdatenkompression im Straßeneinsatz, CR = 19,2; Einsp.: 94,8 %

Im Rahmen dieses Abschnittes konnte an Hand praktischer Erprobungen an verschiedenen

Beispielen die prinzipielle Funktionsweise der entwickelten Methoden deutlich gemacht

werden. Außerdem wurde veranschaulicht, wie sich die Qualität der Kompressionsergeb-

nisse durch gezielte Variation des bzw. der Kompressionsparameter nachvollziehbar

beeinflussen lässt.

II.2.1.5 Hinweise für die Praxis

Im Rahmen der vorangegangenen Abschnitte wurde die Entwicklung verschiedener

Datenkompressionsmethoden zur Verwendung in Telematiksystemen bei mobilen

Arbeitsmaschinen dargelegt. Vom Zusammenstellen der Anforderungen über die

durchgeführten Vorversuche und den eigentlichen Entwicklungsprozess bis hin zur

praktischen Erprobung wurden dabei alle Schritte umfassend beschrieben.

II.2 Datenmanagement 90

In diesem Abschnitt sollen nun noch einige Hinweise zusammengestellt werden, die bei der

praktischen Umsetzung der entwickelten Datenkompressionsmethoden in einem Telematik-

system besonders zu beachten sind. Diese lassen sich drei verschiedenen Kategorien

zuordnen. Neben Hinweisen, die die Implementierung der Kompressionsalgorithmen auf

einer mobiltauglichen Rechnerplattform betreffen, werden wichtige Aspekte aufgeführt, die

für die Parametrierung der Algorithmen von Bedeutung sind. Im dritten Punkt werden

schließlich noch Hinweise zu den Einsatzmöglichkeiten und den Einsatzgrenzen der

entwickelten Kompressionsmethoden gegeben.

II.2.1.5.1 Hinweise zur Implementierung

Für eine produkttaugliche Implementierung der Kompressionsalgorithmen müssen einige

Punkte beachtet werden, die bei der vorgestellten prototypischen Implementierung

vernachlässigbar waren.

Serienimplementierung

Für die produkttaugliche Serienimplementierung ist zunächst eine geeignete Rechner-

hardware auszuwählen, die einerseits die notwendigen Schnittstellen (u. a. CAN) sowie

darüber hinaus die nötigen Speicherressourcen mitbringt und über eine ausreichende

Rechenleistung verfügt. Entsprechend des nutzbaren Betriebssystems bzw. der nutzbaren

Laufzeitumgebung für die ausgewählte Rechnerhardware, ist eine geeignete Programmier-

sprache auszuwählen, in der die Kompressionsalgorithmen implementiert werden können.

Aus heutiger Sicht scheinen sog. dienstebasierte Software-Architekturen besonders gut

geeignet für die Implementierung der Datenkompressionsalgorithmen [GGRM07]. In einer

solchen Architektur können die beiden entwickelten Kompressionsalgorithmen als sog.

Anwendungsdienste eingebunden werden, die dann während der Laufzeit bedarfsgesteuert

(zur Kompression verschiedener Messgrößen ggf. auch mehrfach mit unterschiedlichen

Parametersätzen) gestartet werden können.

Abschaltvorgänge

Ein weiterer Punkt, der unbedingt beachtet werden muss ist, dass die Rechnerhardware, die

auf der mobilen Arbeitsmaschine zum Einsatz kommt und auf der die Kompressions-

algorithmen laufen, nicht permanent mit Betriebsspannung versorgt werden kann. In der

Regel wird beim Abstellen des Verbrennungsmotors der mobilen Arbeitsmaschine nach einer

kurzen Verzögerungsphase die Spannungsversorgung der auf der Maschine installierten

Systeme unterbrochen. Da zwischen dem Abstellen der Maschine und einer anschließenden

II.2 Datenmanagement 91

Wiederinbetriebnahme unter Umständen mehrere Monate liegen können, muss diesen

Abschaltvorgängen auch bei der Implementierung der Kompressionsalgorithmen besondere

Beachtung geschenkt werden, damit keine Daten verloren gehen.

Beide entwickelten Algorithmen schließen den zurückliegenden Signalverlauf immer erst

dann ab, wenn eine relevante Information detektiert wird. Um keine Daten zu verlieren, muss

beim Abschalten der Maschine ein Relevanzkriterium bewusst ausgelöst werden, um den

aktuellen Datensatz abzuschließen und abzuspeichern. Dieses Vorgehen bietet sich auch

an, wenn alle zurückliegenden Daten zu einem bestimmten Zeitpunkt von der Maschine aus

übertragen werden sollen.

II.2.1.5.2 Hinweise zur Parametrierung

Im Rahmen der experimentellen Erprobungen wurden verschiedene Erfahrungen hinsichtlich

der Parametrierung der beiden Kompressionsalgorithmen gemacht, die an dieser Stelle noch

einmal kurz zusammengefasst werden sollen.

Messwert-Zeitreihen

Für die Wahl des richtigen Wertes für den Kompressionsparameter dzul ist zunächst immer

entscheidend, wozu die Daten anschließend – also nach der Kompression – verwendet

werden sollen und wie viel Informationsverlust dabei akzeptiert werden kann. Außerdem

hängt der zu wählende, absolute Wert für dzul natürlich auch sehr stark von der Einheit und

dem Wertebereich der zu komprimierenden Größe ab. Deswegen lassen sich hierzu an

dieser Stelle keine pauschalen, absoluten Zahlenwerte als Empfehlung formulieren.

Es kann jedoch festgehalten werden, dass sich bei allen vier untersuchten Messgrößen gute

bis sehr gute Übereinstimmungen des Kompressionsergebnisses mit dem Originalsignal

ergeben haben, solange für dzul Werte eingesetzt wurden, die nicht mehr als zwei Prozent

des zu erwartenden maximalen Wertes der Messgröße betrugen. Eine relative

Parametervorgabe, bezogen auf den maximal zu erwartenden Betrag der Messgröße, kann

demnach für die hier untersuchten Messgrößen prinzipiell als Richtwert empfohlen werden.

Für andere Signale ist diese Empfehlung jedoch im Einzelfall zu überprüfen.

Eine weitere Möglichkeit zur Parametervorgabe bestünde darin, diesen relativ, in Bezug auf

den jeweils aktuellen Mittelwert, anzugeben. Damit wäre die Parametervorgabe völlig

unabhängig vom zu erwartenden Wertebereich der zu komprimierenden Messgröße möglich.

Dies hätte jedoch zur Folge, dass im Bereich nahe Null bereits viel geringere absolute

Abweichungen als relevant eingestuft würden als wenn das Signal deutlich von Null

II.2 Datenmanagement 92

verschieden ist. Aus diesem Grund wurden im Rahmen der hier vorgestellten

Untersuchungen nur Erprobungen mit absoluter Parametervorgabe durchgeführt.

Bei den experimentellen Erprobungen konnte außerdem festgestellt werden, dass sich diese

Kompressionsmethode unter gewissen Bedingungen auch zur verlustfreien Kompression

eignet. Dazu muss für den Kompressionsparameter dzul der Wert Null gewählt werden. Für

den Fall, dass das Originalsignal mehrere aufeinander folgende, gleiche Werte enthält,

können diese im Kompressionsergebnis eingespart werden, ohne dabei Informationen zu

verlieren. Die damit erzielbaren Einsparungen sind umso größer, je geringer die zu

komprimierenden Werte aufgelöst sind, je weniger dynamisch sich das Originalsignal ändert

und je höher die Abtastrate beim Einlesen der Daten ist.

Positionsdaten

Auch die zu wählenden Parameter für die Positionsdatenkompression hängen zunächst

maßgeblich von den Genauigkeitsanforderungen ab, die an das Kompressionsergebnis

gestellt werden. Da die Methode zur Kompression von Positionsdaten ausschließlich für eine

Datenart eingesetzt wird, fällt es hier etwas leichter, einige allgemein gültige Hinweise zur

Parameterwahl zu formulieren. Da sich die Parameter in Ihrer Wirkungsweise teilweise

gegenseitig beeinflussen, dürfen die vier Parameter nicht völlig losgelöst voneinander

betrachtet werden. Wird beispielsweise nur der Parameter dl,zul verändert, so führt dies nicht

nur dazu, dass weniger Werte auf Grund des Kriteriums Längsabweichung abgespeichert

werden, sondern in der Regel nimmt dadurch auch die Summe der Punkte zu, die auf Grund

zu großer Querabweichung als relevant gelten.

Um keine relevanten Positionsinformationen zu verlieren, sollte der Parameter Δsmind i. d. R.

immer kleiner sein, als der kleinste der beiden Parameter dl,zul und dq,zul.

Für das Kriterium Kurswinkeländerung wurden im Rahmen der durchgeführten Untersuch-

ungen durchweg gute Ergebnisse erzielt, wenn für den Parameter Δωzul Werte größer als

20 Grad gewählt wurden. Um Reversiervorgänge sicher erfassen und den Wendepunkt als

relevant einstufen zu können, sollte der Wert für Δωzul jedoch nicht größer als 90 Grad sein.

Falls an das Kriterium Längsabweichung im Kompressionsergebnis keinerlei Anforderungen

gestellt werden, so kann für dl,zul einfach ein sehr großer Wert (z. B. 1000 m) eingesetzt

werden. Durch diese Maßnahme lässt sich das Kriterium zu Gunsten einer höheren

Kompressionsrate sehr einfach außer Kraft setzen.

II.2 Datenmanagement 93

Für den Fall, dass bei der Rekonstruktion der zurückgelegten Strecke sowohl die

Genauigkeit der Längs- als auch der Querabweichung von Bedeutung ist, so sollten die

Werte für dl,zul und dq,zul sich nicht zu sehr unterscheiden. Bei der Definition dieser

Kompressionsparameter wurde sehr auf ein hohes Maß an Anschaulichkeit geachtet. Beide

Werte geben an, wie weit eine aus dem Kompressionsergebnis für einen bestimmten

Zeitpunkt rekonstruierte Position maximal von der tatsächlich zu diesem Zeitraum ermittelten

Originalposition abweichen kann. In Abschnitt II.2.1.3.3 wurde bei der Beschreibung der

zugehörigen Kompressionsalgorithmen bereits erläutert, dass es meist schon vor Erreichen

einer tatsächlichen Abweichung in Höhe dieser Grenzwerte zum Auslösen der Kriterien

kommt. Deswegen sind die tatsächlichen Abweichungen der Punkte in Längs- und

Querrichtung in der Praxis meist nur etwa halb so groß wie die eingestellten Grenzwerte.

Eine Garantie für diese Unterschreitung der Grenzwerte gibt es zwar nicht, jedoch kann der

Umstand bei der Festlegung der Parameter durchaus berücksichtigt werden.

Wie bereits in Abschnitt II.2.1.4.3 angedeutet, soll an dieser Stelle nochmals darauf

hingewiesen werden, dass Ungenauigkeiten, die schon in den Originaldaten vorhanden sind,

durch den Kompressionsalgorithmus nicht kompensiert werden können. Auch die

Unsicherheiten, die sich durch die Wahl geeigneter Kompressionsparameter begrenzen

lassen, gelten lediglich für die Rekonstruktion des gemessenen Positionsverlaufs

(einschließlich eventueller Messfehler) aus dem Kompressionsergebnis, nicht jedoch für die

Rekonstruktion des tatsächlich zurückgelegten Positionsverlaufs.

Allgemeiner Hinweis zur Parametrierung

Bei der Entwicklung der Kompressionsmethoden wurde entsprechend der Anforderungen

aus Abschnitt II.2.1.1 darauf geachtet, dass die Parameter den Kompressionsalgorithmen

extern bereitgestellt werden können. In Kombination mit dienstebasierten Software-

Architekturen lassen sich die Kompressionsalgorithmen so kontextsensitiv, also in

Abhängigkeit weiterer Umstände, parametrieren. Die Parametrierung muss also nicht

einmalig mit festen Parametern erfolgen, sondern kann den Erfordernissen sehr flexibel

angepasst werden. In diesem Fall muss ein separater Softwaredienst die Aufgabe

übernehmen, auf Basis der Kontextinformationen die passenden Kompressionsparameter

auszuwählen und diese den Kompressionsdiensten bereitzustellen.

II.2 Datenmanagement 94

II.2.1.5.3 Hinweise zu Einsatzmöglichkeiten und -grenzen

Abschließend soll noch kurz auf einige Fälle eingegangen werden, bei denen ein Einsatz der

entwickelten Kompressionsmethoden möglich und sinnvoll erscheint. Zudem werden auch

die Einsatzgrenzen der entwickelten Methoden zur Datenkompression aufgezeigt.

Einsatzmöglichkeiten

Zu den klassischen Anwendungsfällen von Telematiksystemen bei mobilen Arbeitsmaschi-

nen zählen die Dokumentation, die Datenerhebung zur Entscheidungsunterstützung (z. B.

Flottenmanagement) sowie die Prozess- und Zustandsüberwachung. Die entwickelten

Datenkompressionsmethoden sind für einen Einsatz im Rahmen all dieser Anwendungsfälle

prädestiniert, da sie es ermöglichen, in einer bestimmten Datenmenge wesentlich mehr

relevante Informationen zu übertragen als wenn die Übertragung ohne vorherige

Kompression erfolgen würde.

Die entwickelten Methoden eignen sich aber nicht ausschließlich für die Kompression der

Daten vor einer drahtlosen Übertragung. Sie können ebenso für eine nachträgliche Kompres-

sion der Daten vor der Archivierung (z. B. auf einem stationären Datenserver) dienen. Dabei

steht nicht primär die Einsparung von Speicherplatz, der sich bei stationären Systemen

relativ kostengünstig und nahezu unbegrenzt erweitern lässt, im Vordergrund, sondern der

Fokus liegt dabei auf den vereinfachten Zugriffs- und Darstellungsmöglichkeiten, die die klei-

neren Datenmengen gegenüber den unkomprimierten Daten bieten. Da die komprimierten

Daten ihren zeitlichen Bezug behalten und auch die komprimierten Messgrößen weiterhin in

ihrer ursprünglichen Skalierung vorliegen, ist keine Dekomprimierung erforderlich. Das

begünstigt den Zugriff auf die komprimiert vorliegenden Informationen sehr.

Auf Grund der beschriebenen Eigenschaften und der universellen Verwendbarkeit können

die entwickelten Methoden, über den Bereich der mobilen Arbeitsmaschinen hinaus,

prinzipiell auch für Anwendungen auf anderen Gebieten interessant sein.

Einsatzgrenzen

Bedingt durch die Arbeitsweise der Kompressionsmethoden ergeben sich jedoch auch

Einsatzgrenzen. Zwar sind beide Methoden prinzipiell online-fähig, d. h. Daten können

unmittelbar so vom jeweiligen Algorithmus verarbeitet werden, wie sie vom CAN-Bus

einlaufen. Das Kompressionsergebnis steht als Ausgangssignal jedoch erst mit einem mehr

oder weniger langen zeitlichen Verzug zur Verfügung, dessen Dauer vom Messgrößen-

verlauf und den gewählten Kompressionsparametern abhängt. Erst wenn ein Messwert oder

II.2 Datenmanagement 95

eine Position als relevant eingestuft wird, ist der davor liegende Signalverlauf seit dem

vorherigen relevanten Ereignis im Kompressionsergebnis bekannt. Für die Dauer seit dem

letzten relevanten Ereignis im Originalsignal bis zum aktuell betrachteten Zeitpunkt enthält

das Kompressionsergebnis noch keine Informationen. Diese variablen Verzugszeiten sind

der Grund dafür, dass die entwickelten Methoden sich nicht für den Einsatz in

Zusammenhang mit laufzeitkritischen Anwendungen wie beispielsweise Regelungen eignen.

Unerwünschtes Systemverhalten oder Fehlfunktionen könnten hier die Folge sein,

weswegen für diesen Einsatzfall von einer Verwendung der Kompressionsverfahren

unbedingt abzusehen ist.

II.2 Datenmanagement 96

II.2.2 Software-Architektur und Datenfluss

Ein wichtiges Ziel während des Projektes war es, eine offene, flexible und portable Software-

Architektur für die On-Board-Unit zu entwickeln. Im Rahmen des Projektes sollten zwei

unterschiedliche Systeme mit unterschiedlicher Ausstattung eingesetzt werden und der

Portierungsaufwand für die Software so gering wie möglich gehalten werden.

Gerade auch die Bestandteile des Systems für die Steuerung der Kommunikation sollten

möglichst ohne Anpassungen übernommen werden können

II.2.2.1 On-Board-Unit

Die On-Board-Unit übernimmt verschiedene Aufgaben, die hier kurz aufgeführt werden

sollen:

• Sammlung der Sensordaten und Aktorstellungen über den CAN-Bus der

Erntemaschine. Wobei mehrere CAN-Busse auf der Maschine vorhanden sein

können, die alle gleichzeitig überwacht werden müssen.

• Bestimmung der Position über den integrierten GPS-Empfänger

• Steuerung der Kommunikation über die zur Verfügung stehenden

Kommunikationswege

• Kompression der Daten

II.2.2.1.1 Eingesetzte Hardware

In dem Projekt wurden zwei unterschiedliche On-Board-Units aus dem Automotive-Bereich

eingesetzt:

• CarMediaLab The Flea

• T-Systems/gedas gComet

Die eingesetzte Hardware unterscheidet sich in den verfügbaren Ressourcen deutlich.

Während der Flea ein 32-bit Microcontroller-basiertes System ist (Infineon TriCore), nutzt der

gComet einen x86-kompatiblen Prozessor (AMD Geode). Auch die Speicherausstattung

unterscheidet sich. Beiden Plattformen gemeinsam ist die Nutzung von Linux als

Betriebssystem. Durch die unterschiedlichen Prozessor-Architekturen ergeben sich aber

II.2 Datenmanagement 97

trotz des gleichen Betriebssystems deutliche Unterschiede. Auch die Anbindungen der

zusätzlichen Hardware auf Treiber-Ebene (GPS, CAN, GPRS) ist zwischen den beiden

Systemen nicht kompatibel.

II.2.2.1.2 Programmiersprachen

Auf beiden Plattformen ist eine Java-Laufzeitumgebung (JRE) verfügbar. Während die x86-

Plattform offiziell von Sun unterstützt wird, ist auf dem Flea nur eine Kaffe VM verfügbar, die

zudem nur Java 1.3 unterstützt.

Für die Entwicklung der Treiber zum direkten Zugriff auf die Hardware wurde C in

Verbindung mit dem Java Native Interface eingesetzt. So kann direkt aus Java heraus auf

die Schnittstellen zugegriffen werden, wenn die entsprechenden Funktionen in C umgesetzt

wurden.

II.2.2.2 Software-Architektur

II.2.2.2.1 Einleitung

Aus Gründen der Portabilität wurde Java als Programmiersprache gewählt, da diese

aufgrund der Java Virtual Machine (JVM) Plattform-unabhängig ist. Die Plattform-

abhhängigen Teile wie Treiber wurden über JNI eingebunden.

Außerdem ist Java eine objekt-orientierte Programmiersprache, die für viele Plattformen

verfügbar ist. Aufgrund der virtuellen Maschine ist außerdem das Nachladen von

Programmteilen zur Laufzeit möglich, die auf mehreren Plattformen gleichzeitig Laufen.

Dieses wäre beispielsweise in C++ nicht möglich gewesen. Über dynamisch gelinkte

Bibliotheken lassen sich zwar Module dynamisch Nachladen und auch zur Laufzeit

austauschen, aber diese Bibliotheken müssen in kompilierter Form für jede Plattform einzeln

bereitgestellt werden.

Für das dynamische Nachladen und Austauschen von Programmteilen gibt es in Java

bereits ein standardisiertes Framework – OSGi. OSGi steht für Open Services Gateway

initiative. Dabei handelt es sich um hardware-unabhängige, dynamische Software-Plattform,

die es erleichtert, Anwendungen und ihre Dienste per Komponentenmodell zu modularisieren

und zu verwalten.

II.2 Datenmanagement 98

II.2.2.2.2 Schichtentrennung

Neben OSGi als Komponentenmodell für die einzelnen Anwendungsmodule wurde

zusätzlich ein Schichtenmodell für die OBU spezifiziert. Dabei werden drei Schichten

unterschieden.

Die erste Schichte – der Hardware Abstraction Layer (HAL) – stellt die nicht portablen

Bestandteile der Anwendung dar. Diese müssen für jede Plattform angepasst und

bereitgestellt werden. Diese Schicht wurde so klein und schlank wie möglich gehalten, um

den Portierungsaufwand zu minimieren.

Die zweite Schicht – die Basisdienste – stellen grundlegende Funktionalitäten bereit. Dabei

handelt es sich bereits um anwendungsrelevante Funktionen, wie das Ermitteln der aktuellen

Position, das Lesen von Sensor- und Aktor-Informationen, die Ablage von Daten und das

Übertragen von Daten. Diese stellen eine anwendungsorientierte Schnittstelle für den Zugriff

auf die Hardware-Ressourcen bereit. Die Basisdienste dürfen keine Abhängigkeiten zur

Hardware haben, sondern nur die fest definierten Schnittstellen des HAL nutzen. Dadurch

sind die Basisdienste zwischen verschiedenen Plattformen portabel.

Die dritte und letzte Schicht – die Anwendungsdienste – setzen schließlich die

Anwendungsfälle für den Einsatz der OBU um. Dabei handelt es sich unter anderem um die

Kommunikationssteuerung, Fahrspurverfolgung, Datenlogging und Datenkompression. Die

Anwendungsdienste sollten nur auf die Basisdienste oder andere Anwendungsdienste

zurückgreifen. Ein direkter Zugriff auf den HAL ist zwar möglich, sollte aber vermieden

werden. Wenn hier Funktionen fehlen, so sollten sie bei den Basisdiensten ergänzt oder ein

neuer Basisdienst geschaffen werden.

II.2.2.2.3 Schichtenarchitektur

Das nachfolgende Bild II.62 stellt das im vorigen Abschnitt beschriebene Schichtenmodell

mit den einzelnen Diensten dar. Nicht alle dargestellten Dienste wurden im Rahmen des

Projektes auch umgesetzt. Lediglich die für die Ziele des Projektes wichtigen wurden auch

tatsächlich umgesetzt. Die weiteren Dienste wurden zur Einordnung der Funktionen in die

Architektur exemplarisch mit aufgeführt, da sie für Telematik- und Teleserviceanwendungen

allgemein von Bedeutung sind.

II.2 Datenmanagement 99

Bild II.62: Schichtenarchitektur der On-Board-Unit

II.2.2.3 Beschreibung der Dienste

Im Folgenden werden die umgesetzten Dienste beschrieben.

II.2.2.3.1 GSM-Treiber

Der GSM-Treiber ist für die Kommunikation über das GSM-Mobilfunknetz zuständig. Über

ihn kann eine Internet-Verbindung aufgebaut werden, können eingehende Telefonanrufe

erkannt werden und können SMS verschickt und empfangen werden.

II.2.2.3.2 WLAN-Treiber

Der WLAN-Treiber ist für das Überwachen und Steuern der WLAN-Kommunikation

zuständig. Über ihn werden bekannte WLAN-Netze bei Verfügbarkeit erkannt und

Verbindungen auf- und abgebaut.

II.2.2.3.3 GPS/Galileo

Die Aufgabe des GPS-Treibers ist es, aktuelle Positionsinformationen zu liefern. Zusätzlich

werden Status-Informationen geliefert, wie die Anzahl der empfangenen Satelliten,

Geschwindigkeit und Genauigkeit.

II.2 Datenmanagement 100

II.2.2.3.4 CAN-Bus Interface

Das CAN-Bus-Interface liest Informationen von einem oder mehreren CAN-Bussen der

Maschine. Über den CAN-Bus sind üblicherweise die Sensorinformationen verfügbar.

II.2.2.3.5 Positioning

Der Positioning-Dienst stellt interpretierte Ortsinformationen bereit. Dabei ist die Darstellung

der Ortsinformation unabhängig vom Satellitensystem. Dadurch können sowohl transparent

die Satellitensysteme zwischen GPS, Galileo und GLONASS gewechselt werden, aber auch

mehrere parallel betrieben werden, um die Genauigkeit und Verfügbarkeit zu steigern.

II.2.2.3.6 Kommunikation

Der Kommunikationsdienst ist für das Übertragen von Informationen zuständig. Er bündelt

die Kommunikation über SMS, GSM, GPRS, WLAN und Bluetooth zu einem einheitlichen

Dienst.

II.2.2.3.7 Sensoren/Aktoren

Der Sensor- und Aktordienst liefert Sensor- und Aktorinformationen der Maschine, die vom

CAN-Bus gelesen werden. Dieser Dienst ist außerdem für eine einheitliche Darstellung der

Informationen zuständig. So abstrahiert er von den rein technischen Darstellungsformen in

Bits und Bytes der CAN-Botschaften und liefert semantisch aufbereitete Informationen, wie

beispielsweise eine Motordrehzahl in U/min.

II.2.2.3.8 Datenablage

Der Datenablage-Dienst dient der Speicherung von Daten auf dem System. Dabei

abstrahiert er von der tatsächlichen Speicherung und legt die Daten unabhängig vom

tatsächlichen Speichermedium ab (RAM, Festplatte, Flash-Speicher).

II.2.2.3.9 Datenlogger

Der Datenlogger ist der einfachste Anwendungsdienst. Seine Aufgabe ist es, eine vorher

festgelegte Zahl von Sensor-Informationen zusammen mit der Position in regelmäßigen

Abständen zu protokollieren und in regelmäßigen Abständen auch zu übertragen.

II.2 Datenmanagement 101

II.2.2.3.10 Datenverdichter

Der Datenverdichter ist eine erweiterte und verbesserte Form des Datenloggers. Neben dem

reinen Protokollieren der Informationen kann er sie zusätzlich verdichten, so dass sie

weniger Speicherplatz auf dem System benötigen und weniger Bandbreite bei der

Übertragung. Die in diesem Dienst umgesetzten Verfahren sind ein wichtiger Bestandteil des

Projektes.

II.2.2.3.11 Kommunikationsmanager

Der Kommunikationsmanager entscheidet, wann und wie Daten übertragen werden. Dazu

überwacht er die verfügbaren Kommunikationswege, die zu übertragenden Datenmengen

und die für die Kommunikation vorgegebenen Parameter, die über die Wichtigkeit der

einzelnen Informationen entscheiden.

Im Kommunikationsmanager wurde die variable Kommunikationsstruktur erfolgreich

umgesetzt, die eines der primären Ziele des Projektes waren.

II.2.2.4 Simulationsumgebung

Durch die modulare Architektur und die Nutzung von Java und OSGi mit fest definierten

Schnittstellen lässt sich für die Entwicklung und den Test von Modulen/Diensten leicht eine

Simulationsumgebung schaffen, was im Rahmen des Projektes auch gemacht wurde.

Einzelne Dienste können simuliert werden, so kann beispielsweise der Positionierungsdienst

Daten einer vorher aufgezeichneten Fahrt liefern, ebenso wie auch der Sensor- und

Aktorwert. So lassen sich darauf basierende Module wie der Datenverdichter während der

Entwicklung gezielt testen, ohne dass zeitraubende Feldversuche unternommen werden

müssen.

Durch die fest definierten Schnittstellen im Rahmen der OSGi-Architektur ist sichergestellt,

dass die so getesteten Dienste auch in der Zielumgebung ohne Anpassungen funktionieren.

Im Rahmen des Projektes wurden Simulationsdienste für die Positionierung und Sensor-

/Aktorwerte entwickelt und für den Test der Datenverdichtung genutzt.

II.2 Datenmanagement 102

II.2.2.5 Datenverarbeitung auf der OBU

Sensordienste sorgen auf der OBU dafür, dass Daten vom CAN-Bus ins System gelangen

und weiterverarbeitet werden. Diese Weiterverarbeitung geschieht durch Sensortransformer,

Datenverdichter und AlarmManager.

II.2.2.5.1 Sensordienste

Sensordienste sind, wie bereits angedeutet, tatsächlich keine Sensoren im eigentlichen

Sinne. Vielmehr dienen Sensordienste dazu, Sensordaten aus dem CAN-Bus-System der

Landmaschine aufzunehmen und an weiterverarbeitende Dienste weiterzuleiten.

Sensoren gehören zu den Basisdiensten und greifen auf das CAN-Bus-Interface im

Hardware Abstraction Layer zu, um an die benötigten Daten zu gelangen.

Das CAN-Bus-Interface besteht aus einer Programmbibliothek, die in der

Programmiersprache C geschrieben ist und die Rohdaten vom CAN-Bus aufnimmt. Mit Hilfe

eines Java Native Interfaces (JNI) gelangen sie zum OSGi-Bundle CanBridge. Dieses

Bundle stellt lediglich die OSGi-seitige Schnittstelle zu den nativen Bibliotheken dar. Die

erste Weiterverarbeitung geschieht dann im CanService: Hier werden Methoden zum Lesen

und Schreiben von CAN-Daten mit bestimmten IDs angeboten.

Erst im Sensor-Basisdienst, dem Bundle SensorActor, werden aus den CAN-Daten Integer-

oder Double-Zahlenwerte extrahiert. Dazu wird für jede ID, die ausgelesen werden soll, ein

Thread gestartet. Jeder dieser Sensordienste hat folgende Einstellungsmöglichkeiten:

• CAN-Bus: Die Nummer des CAN-Busses, von dem die Daten ausgelesen werden

sollen

• Message ID: Die Message-ID, auf die der Sensordienst lauschen soll. Hier sind

sowohl normale als auch extended Message-IDs möglich. Message-IDs, bei denen

die Inhalte von bestimmten Bits in der Nachricht abhängen, werden derzeit nicht

unterstützt.

• Update Interval: Das Intervall, mit denen die Daten ausgelesen werden. Die Angabe

erfolgt in Millisekunden.

• Start Bit: Die Bitnummer, bei der die auszulesende Zahl beginnt. Das erste Bit hat

hierbei die Nummer 0.

II.2 Datenmanagement 103

• Data Length: Die Länge der Zahl in Bit. Besteht die Zahl aus mehr als einem Byte, so

werden die Zahlen low-byte-first verarbeitet.

• Factor, Offset: Die Rohdaten können mit einem Faktor a und einem Offset b affin

verzerrt werden. Ist x die vom CAN-Bus gelesene Zahl, so wird bax +⋅ )( als

gelesener Wert bereit gehalten.

• Unit: Die Einheit, in der der Wert gemessen wird.

Ein Sensordienst implementiert sowohl das DataProvider-Interface als auch das

DataListenerRegistry-Interface. Darüber können andere Dienste entweder die gelesenen

Daten selbsttätig beim Sensordienst abholen, oder sie können sich als Listener registrieren

und so bei neuen Werten automatisch benachrichtigt werden.

II.2.2.5.2 Sensortransformer

Die Sensortransformer-Dienste gehören, wie die Sensoren, zu den Basisdiensten. Sie

dienen dazu, aus dem Werteverlauf eines Sensors einen neuen Wert zu berechnen.

Typischerweise werden Sensortransformer dazu benutzt, um Werte für Alarm-Manager

bereit zu halten. Dazu kann beispielsweise der aktuelle Gradient berechnet, Fraktile

bestimmt oder Korrelationsfunktionen durch die bisherigen Messwerte gelegt werden.

Sensortransformer melden sich bei einem Sensor als Listener an und halten, wie Sensoren

auch, die Werte sowohl über das DataProvider-Inerface, wie auch das DataListenerRegistry-

Interface bereit. So können sie von anderen Diensten genau wie Sensoren angesprochen

werden. Insbesondere können Daten der Sensortransformer damit auch über

Datenverdichter komprimiert werden und als Messwerte zum Backend gesendet werden.

Im Rahmen der Projektlaufzeit wurden beispielhaft zwei Sensortransformer vorgesehen:

• FraktilTransformer. Diese dienen dazu, einen Sensorwert über eine einstellbare

Anzahl von Werten zu beobachten und zu ermitteln, wo der kleinste Messwert der

oberen x Prozent der Werte liegt. Dies kann dazu benutzt werden, um aus dem

Differenzdruck am Luftfilter den Verschmutzungsgrad abzuleiten. Dieser Transformer

ist implementiert worden.

• RegressionTransformer. Dieser Transformer ist in der Lage, eine Regression n-ten

Grades durch die letzten Messwerte zu legen und aus deren Verlauf zu ermitteln,

wann die Messwerte voraussichtlich einen bestimmten Grenzwert überschreiten

II.2 Datenmanagement 104

werden. Dies kann mit einer kubischen Regression beispielsweise dazu benutzt

werden, die Kettenlängung vom Schrägförderer vorherzusagen.

II.2.2.5.3 Datenverdichter und Datenablage

Datenverdichter werden im OSGi-Bundle DataCompressor implementiert. Diese Dienste

gehören zu den Anwendungsdiensten. Jeder Datenverdichter ist dafür zuständig, einen

Sensorwert zu komprimieren und die Daten mit Hilfe des Basisdienstes Datenablage zu

speichern.

Ein Null-Verdichter kann dabei zum Loggen der Daten benutzt werden, so dass über die

Datenverdichter auch der Logging-Dienst realisiert werden kann.

Die Datenablage ist im OSGi-Bundle Persistence realisiert. Über das Interface Persistence

können neue Ablageplätze (Storages) angelegt, gesucht oder gelöscht werden. Beim

Anlegen kann über einen zusätzlichen Parameter die Art der Komprimierung eingestellt

werden: Keine Komprimierung, GZIP oder 7Z.

Um Daten in einem Storage abzulegen oder sie auszulesen, muss man sich einen

StorageHandle geben lassen. Darüber sind Funktionen zum Laden und Speichern von

Strings und Byte-Arrays realisiert. Darüberhinaus kann man sich einen DataOutput geben

lassen, um die primitiven Java-Datentypen als Binärdatei zu speichern.

Der Basisdienst Datenablage greift dabei nicht auf einen Dienst aus dem Hardware-

Abstraction-Layer zurück, da das Öffnen und Schließen von Dateien und die Verknüpfung

von Dateien mit Streams bereits von der Java-Virtual-Machine gekapselt wird.

Jeder Datenverdichter fordert bei der Datenablage einen eigenen Ablageplatz an und legt die

Daten in einem eigenen XML-Format (siehe Abschnitt II.2.2.8, XML-Dateistruktur) ab. Damit

die Daten das Backend erreichen können, implementieren sie das Interface

SendingDataProvider. Über dieses Interface können Datenkomprimierer aufgefordert

werden, die alte Datenablage abzuschließen und eine neue zu beginnen. Zudem kann über

dieses Interface der Kommunikations-Manager die Dateien, die zum Versand bereit stehen,

abfragen.

Bild II.63 zeigt eine Übersicht der beteiligten Module: Ein Datum liegt am CAN-Bus vor und

wird über den Sensordienst und das CAN-Bus-Interface vom Datenverdichter geholt. Hier

werden die Daten wie beschrieben komprimiert und an die Datenablage weitergereicht. Der

Kommunikationsmanager prüft, wie in Abschnitt II.2.2.7.2, Kommunikation mit dem Backend-

II.2 Datenmanagement 105

Intervalle beschrieben, regelmäßig die Größe der gespeicherten Dateien. Bei Bedarf wird

dann über den Kommunikationsdienst und den GSM-Treiber (oder einen anderen

Treiberdienst aus dem HAL) eine Internetverbindung zum Backend-Server aufgebaut und die

Daten versandt.

Bild II.63: Datenfluss und Beteiligte Module bei der Sammlung von Daten

II.2.2.5.4 Alarm-Manager

Alarm-Manager haben Ähnlichkeiten zu Datenverdichtern. Der wesentliche Unterschied ist,

dass sie die Daten nur beobachten und im richtigen Augenblick Alarm schlagen, statt Daten

zu sammeln und abzuspeichern.

Alarm-Manager melden sich als Listener bei einem Sensortransformer (oder auch direkt an

einem Sensor) an und bekommen von diesem dann die aktuellen Werte geliefert. Dieser

Sensorwert wird mit zwei (verschiedenen) Schwellwerten s1 und s2 verglichen.

Nun gibt es zwei Möglichkeiten für das Verhältnis zwischen s1 und s2:

1. s1<s2 oder

2. s1>s2.

II.2 Datenmanagement 106

In beiden Fällen wird ein gelber Alarm ausgelöst, wenn der neue Wert zwischen den beiden

Schwellen liegt. Ist der Wert echt größer als s2 (Fall 1) bzw. echt kleiner als s2 (Fall 2), so

wird ein roter Alarm ausgelöst. Ansonsten wird kein Alarm ausgelöst. Deswegen heißt s1 das

grüne Limit, s2 heißt das gelbe Limit.

Im Falle eines Alarms soll natürlich der Fahrer benachrichtig werden. Da im Rahmen des

DAMIT-Projektes kein Terminal- oder Displaydienst realisiert wurde, wird der Fahrer auch

nicht benachrichtig. Parallel dazu wird der Messwert zusammen mit einer Alarm-ID an das

Backend verschickt. Dieses stößt dann gegebenenfalls Teilautomatisierte

Geschäftsprozesse an – beispielsweise zur Wartung und Instandhaltung der Landmaschine.

Eine Übersicht zu diesem Vorgang bietet Bild II.64. Ein Datum liegt am CAN-Bus an, wird

durch den Sensordienst gelesen und (meist) an einen Werteanalyse-Dienst weitergereicht.

Dort wird aus dem bisherigen Datenfluss eine Kennzahl berechnet und an den Alarm-

Manager kommuniziert. Der Alarm-Manager entscheidet, ob und welcher Alarm ausgelöst

wird. Ein eventueller Alarm wird dann an den Kommunikationsmanager gemeldet, der dann

über den Kommunikationsdienst und einen geeigneten Treiber die Verbindung zum Internet

herstellt. Dann wird der Alarm ans Backend versandt.

Bild II.64: Datenfluss und Beteiligte Module für das Alarm-Management

II.2 Datenmanagement 107

II.2.2.6 Konfiguration der OBU

Die OBU kann über das Backend konfiguriert werden. Da auf Seiten des Backends nicht

sichergestellt werden kann, dass die OBU eingeschaltet oder empfangsbereit ist, wird die

Kommunikation von Seiten des mobilen Gerätes aus etabliert. Über einen HTTP-GET

übermittelt die OBU ihre Identifikation und bekommt dafür die für sie gültige Konfiguration

geliefert.

Eine Konfiguration besteht aus einer Datei im Properties-Format, d.h. in jeder Zeile steht ein

Key-Value-Paar, getrennt durch ein Gleichheitszeichen.

Bild II.65: Ausschnitt einer Properties-Datei

Die Keys beginnen alle mit einem Schlüsselwort für den Namensraum. Darüber wird die

Zuordnung der Properties zu den einzelnen Programmteilen realisiert. Der Namensraum wird

durch einen Punkt von dem restlichen Key abgetrennt. In Bild II.65 sind die Namensräume

Sensors_CAN und Sensors_Transformer zu erkennen. Sensors_CAN ist der Namensraum

für den Sensordienst, Sensors_Transformer der für die Werteanalyse. Zeilen, die mit einer

Raute (#) eingeleitet werden, sind Kommentarzeilen und dienen lediglich der besseren

Lesbarkeit für den Menschen.

II.2 Datenmanagement 108

Auf der OBU selbst melden sich alle Programmteile, die konfigurierbar sind, über die

Methode void appendConfigurable(Configurable) des Interfaces ConfManager beim

Konfigurations-Manager an. Wenn der Konfigurationsmanager dann mit einer neuen

Konfiguration versorgt wird, spaltet er diese zunächst in die verschiedenen Namensräume

auf und verteilt dann an alle konfigurierbaren Programmteile nur die Key-Value-Paare, die

dem Namensraum genügen.

Für eine initiale Konfiguration stehen auf der OBU üblicherweise zwei Konfigurationsdateien

zur Verfügung, die beide geladen werden:

1. Die Basis-Konfiguration, die insbesondere eine erste Konfiguration des

Kommunikations-Managers bereit stellen muss. Hierüber wird sichergestellt, dass die

mobile Einheit eine Verbindung zum Backend aufbaut, um sich von dort die gerade

gültige Konfiguration zu holen.

2. Die zuletzt vom Server geladene Konfiguration. Dies dient dazu, dass auch dann

Daten aufgezeichnet und Alarme verarbeitet werden, wenn vielleicht gerade keine

Verbindung hergestellt werden kann.

Der genaue Ablauf der Kommunikation wird im Abschnitt II.2.2.7, Kommunikation mit dem

Backend, beschrieben.

II.2.2.7 Kommunikation mit dem Backend

Da die OBU nicht ständig mit dem Internet verbunden ist, kann von außen nicht so leicht

eine Verbindung aufgebaut werden. Die Initiative hierzu geht immer von der OBU aus; sie

wählt sich auf einem geeigneten Weg ins Internet ein und sucht dann die Verbindung zum

Backend.

II.2.2.7.1 Schnittstelle zwischen OBU und Backend

Die Kommunikationsschnittstelle zum Backend erfolgt ausschließlich über das HTTP-

Protokoll. Wie bereits erwähnt, geht dabei die Initiative immer vom mobilen Gerät aus. Dazu

stehen für alle Kommandos, die vom mobilen Gerät an das Backend gerichtet werden,

Webseiten mit Formularen zur Verfügung, die über HTTP-GET bzw. HTTP-POST ausgefüllt

werden können.

Derzeit sind folgende Schnittstellen realisiert:

II.2 Datenmanagement 109

• Kommandos herunterladen. Hiermit kann der Server die OBU veranlassen, eine neue

Konfiguration zu laden oder Software-Pakete zu updaten.

• Konfiguration herunterladen. Auf diese Weise wird eine neue Konfiguration auf die

OBU geladen, wie in Abschnitt II.2.2.6, Konfiguration der OBU, beschrieben.

• Daten hochladen. Hier werden die gesammelten Daten zum Backend übertragen. Es

kann immer nur eine Datei übertragen werden; wenn mehrere Dateien übertragen

werden müssen, muss diese Seite mehrfach aufgerufen werden. Damit das Backend

die einzelnen Dateien auch versteht, muss als erstes ein Inhaltsverzeichnis über die

kommenden Dateien verschickt werden. Die Struktur der Dateien wird in Abschnitt

II.2.2.8, XML-Dateistruktur, beschrieben.

• Datei herunterladen. Hier können Binärdateien heruntergeladen werden. Dies dient

dazu, Software-Updates aufspielen zu können. Dazu wurde das OSGi-Paket

BundleManager implementiert, das in der Lage ist, während der Laufzeit Pakete

durch neue Dateien zu ersetzen.

• Alarm melden. Hierüber können Alarm-Manager ihren aktuellen Messwert an das

Backend übertragen. Die Entscheidung, was mit dem übertragenen Wert passieren

soll, wird im Backend gefällt.

Die einzige Möglichkeit, der OBU eine Mitteilung zu schicken, ist eine SMS, die über die

GSM-Anbindung der Digibox empfangen wird. Daraufhin stellt die mobile Einheit eine

Internet-Verbindung zum Backend her, um von dort die aktuellen Kommandos

herunterzuladen. Auf diese Weise wird auch verhindert, dass eine versehentliche SMS zu

einem größeren Schaden führt, weil die tatsächlichen Kommandos nicht über die SMS,

sondern über die Backend-Schnittstelle übertragen werden.

II.2.2.7.2 Intervalle

In der Konfiguration des Kommunikationsmanagers sind drei Intervalle wichtig:

1. Fehler-Intervall für das Empfangen einer Server-Konfiguration. Die OBU versucht,

möglichst schnell die Konfiguration zu empfangen. Gelingt dies nicht, wartet sie eine

Zeit lang, um dann einen neuen Versuch zu machen. Diese Schleife wird

unterbrochen, wenn das Herunterladen der Konfiguration gelungen ist und erst

wieder aufgenommen, wenn die OBU durch Kommandos dazu aufgefordert wird.

II.2 Datenmanagement 110

2. Intervall für das Empfangen von SMS. Die OBU schaut in regelmäßigen Abständen,

ob eine SMS empfangen wurde. Aufgrund von technischen Einschränkungen ist es

auf der Digibox derzeit nicht möglich, den SMS-Speicher zu prüfen, während eine

Internet-Verbindung über GPRS steht. Daher wird der SMS-Speicher nur geprüft,

wenn keine Verbindung zum Internet hergestellt ist.

3. Intervall für das Prüfen der Datenmenge für den besten derzeit verfügbaren

Kommunikationsweg. Hier wird in regelmäßigen Abständen geprüft, worüber die

derzeit beste Internet-Verbindung hergestellt werden könnte. Zu jeder Verbindungsart

gibt es eine Datenschwelle, ab der die Daten zum Backend versendet werden

müssen. Ist diese Datenschwelle überschritten, wird allen Datenverdichtern mitgeteilt,

dass sie neue Dateien beginnen sollen. Dann wird die Verbindung zum Internet

hergestellt und die Dateien werden versendet.

II.2.2.7.3 Versende-Strategien

Je nachdem, welche Hardware zur Verfügung steht, können unterschiedliche Wege benutzt

werden, um die OBU mit dem Internet zu verbinden. Auf der Digibox sind das das W-LAN

und GPRS, aber auch Bluetooth oder UMTS sind grundsätzlich denkbar.

Tabelle II.11: Einige mögliche Kommunikationsnetze mit Übertragungsgeschwindigkeit,

anfallende Kosten und Netzabdeckung

Netz Geschwindigkeit Kosten Abdeckung/Reichweite

WLAN Sehr schnell Niedrig Geringe Reichweite

Bluetooth Schnell Niedrig Sehr geringe Reichweite

UMTS Schnell Mittel Geringe Abdeckung

EDGE Mittel Hoch Mittlere Abdeckung

GPRS Langsam Hoch Große Abdeckung

SMS Sehr langsam Sehr hoch Sehr große Abdeckung

Wie Tabelle II.11 zeigt, können die unterschiedlichen Verbindungswege leicht in eine

Qualitäts/Kosten-Reihenfolge gebracht werden, da eine hohe Geschwindigkeit auch mit

geringen Kosten einhergeht. Leider läuft dem die Verfügbarkeit entgegen, d.h. die schnellen,

günstigen Verbindungen sind nur schlecht verfügbar.

II.2 Datenmanagement 111

Um einen Überlauf zu verhindern und unnötige Verbindungskosten zu vermeiden, wird

jedem möglichen Übertragungsweg n ein Datenschwellwert s(n) zugeordnet. Diese

Zuordnung heißt Versende-Strategie. Langsamen, teuren Verbindungen wird im Normalfall

ein höherer Schwellwert zugeordnet werden. Damit soll vermieden werden, Daten über eine

ungünstige Verbindung zu verschicken. Im Notfall jedoch muss auch eine langsame

Verbindung benutzt werden, um Datenverluste zu vermeiden.

Eine solche Versende-Strategie kann natürlich von Hand erstellt werden. Alternativ kann

man auch über einen Algorithmus aus der stochastischen dynamischen Optimierung eine

optimale Strategie automatisch bestimmen lassen.

II.2.2.7.4 Automatische Berechnung optimaler Strategien

Da die Fahrtwege, Datenmengen und die Übertragungswege nicht von vorne herein bekannt

sind, handelt es sich hierbei um eine stochastische Fragestellung. Als Kosten fallen dabei die

tatsächlichen Übertragungskosten an plus die Kosten, die durch Datenverluste entstehen. Je

nachdem wie wichtig die Daten sind, können Datenverluste hingenommen werden; daher

müssen sie als Kosten mit eingehen.

Eine Versende-Strategie heißt dann optimal, wenn die erwarteten Kosten minimal sind. Das

bedeutet, dass man eventuell im Nachhinein für eine konkrete Fahrt eine bessere Strategie

finden kann. Da die konkreten Daten aber erst im Nachhinein vorliegen, ist die optimale

Versende-Strategie die Beste, für die man sich entscheiden kann.

Zur Bestimmung der optimalen Strategie liegt folgendes mathematische Modell aus der

stochastischen dynamische Optimierung (siehe z. B. [KW03]) zugrunde:

Der Zustandsraum Z besteht aus allen möglichen Zuständen z mit

z = (n,d)

Dabei ist n das Beste der möglichen Netze (also W-LAN, Bluetooth, GPRS usw.) und d die

Größe der Daten in Byte. Wichtig ist, dass die Menge der Netze geordnet ist, d.h. wenn zwei

Netze verfügbar sind, kann man eindeutig das bessere Netz auswählen. So bedeutet also

beispielsweise z=(W-LAN,8192), dass das beste verfügbare Netz W-LAN ist und dass 8 kiB

Daten versendet werden müssen.

Die Menge der Aktionen hat zwei Elemente: versenden und lagern. Versenden bedeutet,

dass alle momentan vorhandenen Daten zum Backend-Server versendet werden und diese

von der OBU gelöscht werden. Lagern heißt, dass kein Versandt stattfindet. Wie bereits

II.2 Datenmanagement 112

oben angedeutet, entscheidet sich die OBU in festen Zeitintervallen für eine dieser beiden

Aktionen.

Je nach gewählter Aktion fallen Kosten c(z,a), abhängig vom Zustand z=(n,d) und der

gewählten Aktion a, an. Vorausgesetzt ist hier:

a) Die Lagerkosten sind unabhängig vom gewählten Netz, d.h.

c(lagern,n1,d) = c(lagern,n2,d)

b) Die Kosten müssen in d monoton wachsen

c) Es muss für jedes Netz n eine Größe dn geben, so dass für alle d>dn:

c(lagern,n,d) > c(versenden,n,d)

Die Kosten müssen nicht genau den realen Kosten entsprechen. Insbesondere sind die

Lagerkosten rein virtuelle Kosten, die einen möglichen Datenverlust und die Verzögerung,

mit der die Daten am Backend zur Verfügung stehen, repräsentieren.

Der Übergang von einem Zustand z1=(n,d1) zu einem Nachfolgezustand z2=(m,d2) ist

natürlich von der gewählten Aktion abhängig, da die Datenmenge zunächst entweder gleich

bleibt (bei der Aktion lagern) oder auf 0 fällt (bei der Aktion versenden). Trotzdem lässt sich

der Übergang nur durch eine Wahrscheinlichkeit beschreiben, da die im nächsten

Zeitintervall verfügbaren Netze und die hinzugekommenen Daten nicht vorhersehbar sind.

Zur Vereinfachung wird angenommen, dass eine konstante Datenmenge δd pro Zeitintervall

hinzukommt; die Menge hat sich in Experimenten als nicht sehr veränderlich herausgestellt.

Für die Netze allerdings benötigt man sogenannte Übergangswahrscheinlichkeiten: Die

Wahrscheinlichkeit pnm beschreibt die Wahrscheinlichkeit, dass man in einem Zustand als

bestes Netz n sieht und im Nachfolgezustand Netz m.

Damit ergeben sich, ausgehend von z1 für z2=(m,d2) und eine Aktion a, folgende

Wahrscheinlichkeiten:

P(d2=δd) = pnm, falls a=versenden

P(d2=d1+ δd) = pnm und falls a=lagern

Um eine optimale Strategie zu ermitteln, müssten jetzt die erwarteten Kosten, die sich aus

einer Entscheidung ergeben, aufaddiert werden. Dadurch ergeben sich aber automatisch

II.2 Datenmanagement 113

unendliche Kosten, weswegen auf die diskontierte Kostensumme zurückgegriffen wird. Die

Kosten die im k-ten Schritt entstehen, werden also mit βk multipliziert, mit 0<β<1.

Aufgrund der Struktur des Problems kann der Wert der diskontierten Folgekosten durch eine

ereignisgesteuerte Simulation (siehe z. B. [Kol08]) geschätzt werden, wobei die Anzahl der

Schritte der Simulation groß genug sein muss, damit jedes Netz hinreichend oft besucht

werden muss.

Um jetzt die optimale Strategie zu bestimmen, wird folgender Algorithmus verwendet:

1. Beginne mit einer zufälligen Strategie s.

2. Berechne für einen Zustand z die Ein-Schritt-Kosten der Aktionen versenden und

lagern.

3. Berechne die diskontierten Folgekosten für die Aktionen unter der Strategie s und

vergleiche die Gesamtkosten der Aktionen. Ist die billigere Aktion so, wie Strategie s

vorgibt, ist alles in Ordnung. Ist die billigere Aktion aber gerade anders, als Strategie

s vorgibt, so muss die Strategie s so geändert werden, dass die Wahl für Zustand

z=(n,d) korrigiert wird (indem s(n)=d oder s(n)=d-1 gesetzt wird, je nachdem, was

billiger ist).

4. Auf diese Art und Weise werden so lange Zustände ausgewertet, bis sich s nicht

mehr verändert. Dann weiß man aber, dass s optimal sein muss.

II.2.2.8 XML-Dateistruktur zur internen Datenübertragung

Zur Übertragung der Daten zwischen mobilem Arbeitsgerät und Backend-Server werden

Dateien im XML-Format übertragen. XML hat zwar gegenüber Binär-Formaten den Nachteil,

dass es einen relativ großen Overhead an Strukturinformationen hat. Durch einfache ZIP-

Komprimierung wird dieser Nachteil aber im Wesentlichen kompensiert, so dass die Vorteile,

z.B. robuste Parser, automatische Überprüfung der Korrektheit, mit nur geringen Nachteilen

einhergehen.

II.2.2.8.1 ISO-XML

Zum Datenaustausch zwischen mobilem Arbeitsgerät und Backend-Server wurde zunächst

das ISO-XML ins Auge gefasst [ISO09].Dabei handelt es sich um eine XML-Sprache, die

entwickelt wurde, um den Datenaustausch zwischen Programmen verschiedener Hersteller

zu vereinfachen.

II.2 Datenmanagement 114

Um Daten zu versenden, werden in ISO-XML die Daten nicht direkt im XML abgelegt,

sondern in einer Extra-Datei im Binär-Format übertragen. Die Daten werden dabei immer in

einer Tabelle mit fester Spaltenzahl und festen Zeitabständen abgelegt. Die Bedeutung der

Spalten und ein Hinweis auf den Dateinamen werden wiederum im XML-Format

beschrieben, so dass einem allgemeinen Verständnis nichts im Wege steht.

Tabelle II.12: Aufbau der Daten-Binär-Datei im ISO-XML

Zeitstempel 1 Datum 1.1 Datum 2.1 …

Zeitstempel 2 Datum 1.2 Datum 2.2 …

… … …

Leider ist das Format nicht dazu geeignet, komprimierte Daten zu versenden, denn das

Wesen unserer Datenverdichtung ist es ja gerade, Daten von möglichst vielen Zeiten

wegzulassen. Hier ist es aber so, dass die obige Tabelle keine Lücken aufweisen darf, d.h.

es müssen alle Daten zumindest als Nullwerte existieren. Daher ist es – gerade bei guter

Kompression – besser, die Datenreihen einzeln jeweils mit ihren Zeiten abzuspeichern,

obwohl man so für jeden Messwert einen Zeitstempel speichern muss und nicht nur pro Zeile

einen.

Ein weiteres Problem mit dem Tabellenformat ist die Tatsache, dass alle Daten in nur einer

Datei liegen. Das bedeutet, dass entweder alle Datenkomprimierer in der richtigen

Reihenfolge gemeinsam schreibend auf eine Datei zugreifen müssen, um die Zeilen korrekt

zu füllen, dass jeder Messwert in einer eigenen Zeile stehen muss oder dass die Daten

zunächst nur zwischengespeichert werden, um sie dann zum Versand in das ISO-XML-

Format umzukopieren. Das erhöht den Platzbedarf auf der On-Board-Unit auf das Doppelte

und führt zu erheblichem CPU- und Zugriffsaufwand.

Um jedoch den Datenaustausch mit anderen Programmen zu ermöglichen, können in der

Konfiguration im Backend bereits ISO-XML-spezifische Daten wie z.B. das DDI eingetragen

werden. So wird ein ISO-XML-Export aus dem Backend leicht und verlustfrei ermöglicht;

beispielsweise kann ein Programm zur teilautomatisierten Ausführung von Geschäftspro-

zessen Daten im ISO-XML-Format entgegennehmen und an Werkstattsysteme weiterleiten,

die mit ISO XML arbeiten.

II.2 Datenmanagement 115

II.2.2.8.2 Beschreibung der Formate zur Datenübertragung

Für jede einzelne Messreihe wird eine eigene XML-Datei angelegt, die je nach Kompres-

sionsverfahren unterschiedlich formatiert ist. Die Dateinamen setzen sich aus dem

Zeitstempel der Erstellung, dem Namen des Sensors und einer Zufallszahl zusammen. Dies

verhindert, dass Dateien von unterschiedlichen mobilen Geräten gleiche Dateinamen

besitzen, was zu Verwechselungen auf dem Server führen kann.

Die einzelnen Dateien für die Datenreihen sind sehr ähnlich aufgebaut. Durch das Root-

Element wird beschrieben, um welche Kompressionsart es sich handelt. Neben den üblichen

Angaben zum verwendeten XML-Schema wird in einem Attribut die Start-Zeit der Messung

festgehalten.

Im Rahmen des Projektes wurden folgende drei Formate realisiert:

1. CompressedDataGPS. Solche Daten dienen dazu, GPS-Positionen zu bescheiben.

Zum Kompressions-Algorithmus siehe Abschnitt II.2.1.3.3. Innerhalb dieses Elemen-

tes können nur Elemente vom Typ GPSItem benutzt werden. Als Attribute werden ein

Zeitstempel, die geographische Länge und die geographische Breite (in Grad)

angegeben.

2. CompressedDataMeans. In diesen Dateien werden komprimierte Zeitschriebe

gespeichert. Der Kompressionsalgorithmus wird in Abschnitt II.2.1.3.2 beschrieben.

Die Daten selbst werden in Elementen vom Typ MeansItem beschrieben: Als

Attribute wird ein Zeitstempel und der (mittlere) Sensorwert gespeichert.

3. CompressedDataCategorization. Diese XML-Dateien werden benutzt, um Tabellen

von klassierten Daten zu speichern. Die Daten werden in Elementen vom Type

CategorizationItem gehalten; dieses hat als Attribut einen Zeitstempel. Darin werden

in Category-Elementen im Attribut Frequency die absoluten Häufigkeiten der einzel-

nen Kategorien gespeichert. In Elementen vom Typ SuccessiveCategory wird gespei-

chert, wie viele Wechsel es von einer Kategorie in eine andere gegeben hat. Als Kon-

vention wird vereinbart, dass alle Werte, die nicht in der Datei aufgefürt sind, als 0

gelten.

Zum Versand der Dateien wird zunächst eine Inhaltsverzeichnis-Datei erstellt, an der der

Backend-Server erkennen kann, mit welchen Dateien er zu rechnen hat und was ihr Inhalt

ist. Das Root-Element DamitData enthält Attribute zur OBU-ID und zur Mess-ID, damit die

Messdaten eindeutig einem Gespann und einer Messung zugeordnet werden können.

II.2 Datenmanagement 116

Außerdem enthält die Datei einen Zeitstempel der internen Zeit (nach der alle Zeitstempel

genommen werden) und der GPS-Zeit, damit im Backend Fehler der internen Zeit

ausgeglichen werden können. Danach folgen SeriesOfMeasurement-Elemente, die die

Zuordnung Messreihe–Dateiname ermöglichen. Diese Datei wird als erstes zum Backend

übertragen; so können die nachfolgenden Dateien korrekt zugeordnet werden, auch wenn

sie durch einen eventuellen Verbindungsabbruch eventuell erst sehr viel später versendet

werden können.

II.2.2.9 Back-End

Das entwickelte Back-End ist für die Speicherung, Visualisierung und Konfiguration der

OBUs zuständig. Dabei handelt es sich um eine Web-Anwendung, die über einen Web-

Browser aufgerufen und bedient werden kann. Zur Datenablage werden alle Daten in einer

relationalen Datenbank gespeichert.

Die Architektur des Back-Ends orientiert sich an den klassischen, modernen Web-

Architekturen im Java-Enterprise-Bereich und ist in Bild II.66 dargestellt. Zum Zugriff auf die

Datenbank wird eine Persistenzschicht genutzt, in diesem Fall Hibernate, während die

Oberfläche selbst auf dem ZK-Framework basiert, was die Erstellung von hoch-interaktiven

Web-Anwendungen ermöglicht, die in der Benutzbarkeit kaum von klassischen Desktop-

Anwendungen zu unterscheiden sind.

Bild II.66: Architektur Back-End

II.2 Datenmanagement 117

Die wichtigsten Aufgaben des Back-Ends liegen in der Konfiguration, der Datenspeicherung

und der Visualisierung. Neben den Maschinen ist auch die Verwaltung von Gespannen, also

der Zusammenschluss von mehreren Geräten, im Back-End abbildbar.

Der nachfolgende Screenshot in Bild II.67 gibt einen groben Überblick über den Aufbau und

die Funktionsweise des Back-Ends.

Bild II.67: Screenshot der Bedienoberfläche des Back-Ends

Auf der linken Seite findet sich die Hauptnavigation, in der die einzelnen Bereiche aufgelistet

sind und ausgewählt werden können. Im Hauptbereich rechts werden dann die Informationen

angezeigt. In diesem Fall eine Übersicht über die vorhandenen Gespanne im System, das

für die Abschlusspräsentation nur den ILF Versuchstraktor umfasst.

Die gesammelten Daten werden dann zu den einzelnen Maschinen und Zeitpunkten

abgespeichert und können unter den Messaufträgen eingesehen werden. Die nachfolgenden

Screenshots zeigen exemplarisch die Darstellung der Motordrehzahl (Bild II.68) und die

Aufzeichnung der GPS-Fahrspur während der Abschlusspräsentation (Bild II.69).

II.2 Datenmanagement 118

Bild II.68: Visualisierung eines Messwert-Zeitverlaufs im Back-End

Bild II.69: Visualisierung eines Positionsdatenverlaufs im Back-End

II.3 Vernetzte Prozesse 119

II.3 Vernetzte Prozesse

Neben den mehr technischen Aspekten des Projektes bei der „Zustandsüberwachung

exemplarischer Baugruppen“ und beim „Datenmanagement“ wird unter dem Topic „Vernetzte

Prozesse“ die Verknüpfung der Technik mit den darüber liegenden Geschäftsprozessen

verdeutlicht. Beispielhaft sind Prozessmodelle für die Logistikkette Rübe und für den Service-

Ablauf einer Landtechnikwerkstatt dargestellt.

II.3.1 Technologien und Schnittstellen im Logistikprozess

Ein effizienter Informationsaustausch innerhalb der Logistikkette Rübe ist die Basis für den

wirtschaftlichen Anbau und die ökonomische Verwertung der Zuckerrübe. Derzeitige

Probleme im Logistikprozess entstehen durch

• Inkompatible „Insellösungen“ bei der Datenerfassung

• Schlechte Bedienbarkeit der Systeme durch geringe Integration in die Maschinen

• Regionale Spezialitäten in Abhängigkeit der beteiligten Partner

• Geringe Aktualität des Datenbestandes

Im Projekt wird ein Prozessmodell einer beispielhaften Logistikkette Rübe erarbeitet. Die

reale Ausprägung kann aufgrund der bereits genannten regionalen Spezialitäten leicht von

diesem Modell abweichen. Auf diesem Modell basierend wird eine in die Maschine integrierte

Datenerfassung am Rübenroder implementiert und mit einer standardisierten Schnittstelle

versehen, die den Anforderungen der Logistikkette genügt.

II.3.1.1 Prozessmodell Logistikkette Rübe

Bild II.70 zeigt die Beteiligten der Logistikkette Rübe. Die komplexe Logistikkette Rübe wird

weitgehend zentral von der Zuckerfabrik gesteuert (links unten). Weitere Prozessbeteiligte

sind der Anbauer (oben links), der Rodedienstleister (oben rechts) sowie die Abfuhrgemein-

schaft (unten rechts).

II.3 Vernetzte Prozesse 120

Bild II.70: Beteiligte im Logistikprozess Rübe

Der Gesamtprozess der Rübenlogistik wird in die Teile Kampagnenplanung, Roden und

Abfuhr unterteilt. Die Kampagnenplanung beginnt im Frühjahr vor der Aussaat der Rübe. Im

Herbst schließt sich der Teilprozess Roden an, dem die Abfuhr der Rüben folgt. Die

folgenden Sequenzdiagramme (Bild II.71 bis II.73) zeigen, welche Informationen zwischen

den Prozessbeteiligten zu welchem Zeitpunkt ausgetauscht werden.

II.3.1.1.1 Teilprozess Kampagnenplanung

Roder ZuckerfabrikAnbauer

Festlegung Liefermenge

Abfuhr

Festlegung der Anbaufläche

Kampagnenplanung, Abfuhrplan Kampagnenplanung, Abfuhrplan

Kampagnenplanung

Festlegung der Mietenposition

Festlegung der Schläge

Festlegung der Schläge

Bild II.71: Informationsfluss im Teilprozess Kampagnenplanung

II.3 Vernetzte Prozesse 121

Die Kampagnenplanung beginnt im Frühjahr mit der Festlegung der Gesamtliefermenge in

der folgenden Kampagne durch die Zuckerfabrik. Den Anbauern wird basierend auf ihrer

Lieferquote die geforderte Liefermenge mitgeteilt. Hat jeder Anbauer die Anbaufläche an die

Zuckerfabrik bekannt gegeben, erfolgt bereits eine erste grobe Kampagnen- und

Abfuhrplanung durch die Zuckerfabrik, die den ungefähren Rodetermin festlegt und damit

Einfluss auf den Aussaat-Termin hat. Daraufhin legt der Anbauer die Schläge fest, auf denen

im aktuellen Wirtschaftsjahr Rüben angebaut werden. Diese Daten fließen wiederum in eine

detailliertere Kampagnenplanung durch die Zuckerfabrik ein. Als letzter Schritt in der

Kampagnenplanung wird - häufig sogar vor Ort - die Mietenposition auf dem Schlag anhand

der geografischen Gegebenheiten (Straßen, Zufahrten, Untergrundgegebenheit) festgelegt.

II.3.1.1.2 Teilprozess Roden

Bild II.72: Informationsfluss im Teilprozess Roden

Während des Teilprozesses Roden findet die eigentliche Ernte der Zuckerrübe statt. Vom

Anbauer wird dazu der Termin, die Fläche mit der Mietenposition und der Ort an den

ausführenden Rodedienstleister, meistens ein Lohnunternehmer oder eine

Maschinengemeinschaft, übermittelt. Dieser bestätigt den Auftrag und meldet nach

Ausführung des Rodeauftrags manuell oder durch das integrierte Datenerfassungsprogramm

des Roders die Erntemenge, die Position der Miete und Informationen über die Qualität des

Erntegutes an das Datenmanagementsystem der Zuckerfabrik und den Anbauer.

II.3 Vernetzte Prozesse 122

II.3.1.1.3 Teilprozess Abfuhr

Roder ZuckerfabrikAnbauer

Liefernachricht: Liefermenge, Verschmutzung, Zuckergehalt, Qualität

Abfuhr der Rüben

Abfuhr

Liefertermin, Lademenge, Mietenposition

Bild II.73: Informationsfluss im Teilprozess Abfuhr

Vor der Abfuhr wird von der Zuckerfabrik der Liefertermin, die Lademenge und die Mieten-

position an die Lademaus übermittelt. Diese verlädt das Erntegut. Mit den Daten sowie den

bei der Anlieferung ermittelten Werten generiert die Zuckerfabrik eine Liefernachricht, die

dem Anbauer zugestellt beziehungsweise über das Datenmanagementsystem zugänglich

gemacht wird.

II.3.1.2 Datenformate

Das bestehende Prozessmodell der Logistikkette wurde verwendet, um darauf basierend

eine maschinenintegrierte Datenerfassung auf dem Rübenroder zu entwickeln. Aus dem

Prozessmodell der Logistikkette ergibt sich dabei, welche Daten während des Rode-

prozesses erhoben und exportiert werden müssen und welche Daten im Vorfeld des

Rodeauftrags zur Verfügung stehen und importiert werden müssen. Nahezu alle großen

westeuropäischen Zuckerkonzerne betreiben mittlerweile Datenmanagementsysteme, an die

weitere Prozessbeteiligte angeschlossen sind. Jedes dieser Datenmanagementsysteme

besitzt proprietäre Daten-Schnittstellen zum Im- und Export der Daten an die Prozess-

beteiligten. Derzeit ist meistens spezielle zusätzliche Hardware für die Datenerfassung

notwendig. Auch die Daten, die bereits im Elektroniksystem der Maschine erfasst sind

(beispielsweise Flächen oder Erträge), müssen manuell in das System übernommen werden.

Für eine Integration der Datenerfassung in die Maschine und die Online-Anbindung der

Maschine an die Datenmanagementsysteme ist eine Standardisierung der Im- und Export-

Schnittstelle unabdingbar, da das Vorhalten sämtlicher proprietärer Schnittstellen nicht reali-

II.3 Vernetzte Prozesse 123

sierbar ist. Der internationale Standard ISOBUS [ISO09] definiert in der Norm Teil 10 der

ISO 11783 ein XML-basiertes Datenformat für den Austausch von Auftrags- und Prozess-

daten zwischen einer Maschine und einem Hof-PC. Im Projektverlauf wurde gezeigt, dass

die ISOBUS-XML Schnittstelle geeignet ist, alle notwendigen Daten, die an der Schnittstelle

zwischen Datenmanagementsystem der Logistikkette Rübe und dem Rübenroder anfallen,

aufzunehmen.

II.3.1.3 Umsetzung

Basierend auf den gesammelten Anforderungen wurde im Verlauf des Projektes eine

Anwendung zur Datenerfassung entwickelt, die auf dem maschinenintegrierten Terminal

parallel zur Maschinenbedienung abläuft (siehe Bild II.74).

Bild II.74: Hauptbildschirm des maschinenintegrierten Datenerfassungsprogramms

Sämtliche, ohnehin auf der Maschine verfügbaren Daten wie z. B. die GPS-Position können

damit automatisch sehr komfortabel in das System einfließen. Das System verfügt über eine

ISOBUS XML Schnittstelle, über die im Vorfeld der Kampagne per USB-Stick die Stamm-

daten bestehend aus Betrieben, Schlägen und Fahrern sowie die vorgeplanten Rodeaufträge

an der Maschine importiert werden. Nach Abarbeitung der Aufträge erfolgt der Export

ebenfalls per ISOBUS XML auf dem USB-Stick, um die Daten für Dokumentations- und

Fakturierungszwecke am Hof-PC wieder einzulesen. Zusätzlich wurde eine Online-Über-

tragung des standardisierten Austauschformates zu einer beispielhaften Implementation

eines Onlineportals realisiert. Sobald in den bestehenden Datenmanagementsystemen damit

eine standardisierte ISOBUS-XML Schnittstelle zur Verfügung steht, können die erfassten

Daten des Rübenroders in Echtzeit drahtlos übertragen werden.

II.3 Vernetzte Prozesse 124

II.3.2 Vorbeugende Instandhaltungsprozesse durch Teleservice

Die Erhöhung der Betriebsbereitschaft bzw. die Erhaltung der Verfügbarkeit von mobilen

Arbeitsmaschinen u. a. im landwirtschaftlichen Umfeld nimmt einen immer größeren Raum

und damit eine zunehmende Gewichtigkeit ein. Vorbeugende Instandhaltungsprozesse sind

ein Baustein zur Erhaltung der Maschinenverfügbarkeit. Eine unmittelbare Reaktion auf

Veränderungen von Betriebsparametern muss gewährleistet werden. Dazu sind geeignete

Schlüssel-Indikatoren zu überwachen. Das wiederum bedingt eine geeignete Sensorik. Die

sensierten Schlüssel-Indikatoren müssen dann geeignete Methoden zur Behandlung von

Triggerereignissen durchlaufen. Um die zeitnahe bzw. unmittelbare Veranlassung von

Maßnahmen nach Eintreffen von auslösenden Triggerereignissen sicherzustellen, kommen

die Techniken des „Teleservice“ zum Einsatz.

II.3.2.1 Einordnung des Themas „Vorbeugende Instandhaltungsprozesse durch Teleservice“

Vorbeugende Instandhaltung erfordert die Planung von Maßnahmen zur Bewahrung und

Wiederherstellung des Sollzustandes sowie die Feststellung und Beurteilung des

Istzustandes von technischen Mitteln eines Systems, hier der mobilen Arbeitsmaschine.

Techniken des Teleservice ermöglichen die Feststellung und Beurteilung des Istzustandes

einer mobilen Arbeitsmaschine mit minimalem Zeitverzug, also quasi Online.

II.3.2.2 Was bedeutet „Instandhaltung“?

Gemäß Definition nach DIN 31051 (Instandhaltung – Begriffe und Maßnahmen) bedeutet

Instandhaltung der Einsatz von „Maßnahmen zur Bewahrung und Wiederherstellung des

Sollzustandes sowie zur Feststellung und Beurteilung des Istzustandes von technischen

Mitteln eines Systems“.

II.3.2.3 Was bedeutet „Vorbeugende Instandhaltung“?

Durch die Planung von Maßnahmen, die der Bewahrung des Sollzustandes sowie zur

Feststellung und Beurteilung des Istzustandes von Mitteln eines Systems dienen, erweitert

sich Instandhaltung zu der vorbeugenden Instandhaltung.

II.3 Vernetzte Prozesse 125

II.3.2.4 Was wird für die „Vorbeugende Instandhaltung“ benötigt?

Eine vorbeugende Instandhaltung erfordert die Identifikation von Schlüssel-Indikatoren, die

eine verlässliche Basis für die Auslösung der notwendigen Maßnahmen einer vorbeugenden

Instandhaltung zur Verfügung stellen. Um diese Schlüssel-Indikatoren praktisch - also

technisch - auszugestalten ist eine geeignete Sensorik vorzusehen. Die Sensorik in

Kombination mit den Algorithmen zur Extrahierung der Schlüssel-Indikatoren liefert dann

Methoden, um die geforderten Triggerereignisse zu behandeln. Die Triggerereignisse

werden zum Auslösen von Prozessketten verwendet.

II.3.2.5 Rolle der verschiedenen Forschungs-Cluster des Projektes für die „Vorbeugende Instandhaltung“

Wie bereits angeklungen, werden die Ergebnisse der Forschungs-Cluster „Zustands-

überwachung exemplarischer Baugruppen“ und „Datenmanagement“ mit den in Vorprojekten

gewonnenen Erkenntnissen des „Teleservice“ in einer geeigneten Art und Weise kombiniert,

um eine vorbeugende Instandhaltung zu realisieren.

II.3.2.5.1 „Zustandsüberwachung exemplarischer Baugruppen“

Die mittels einer systematischen Versuchmethodik erhobenen Daten und die daraus

gewonnenen mathematischen Modelle liefern die notwendigen und geeigneten Schlüssel-

Indikatoren.

II.3.2.5.2 „Datenmanagement“

Der Forschungs-Cluster „Datenmanagement“ setzt die mathematischen Modelle in Algorith-

men um, die informationstechnisch abgebildet werden. Die implementierten Algorithmen sind

auf der On-Board-Unit (OBU) der mobilen Arbeitsmaschine oder auf einem zentralen Infor-

mationssystem ablauffähig. Das Datenmanagement bereitet Sensordaten auf und liefert

vorverarbeitete Daten für den dargestellten Prozessablauf der vorbeugenden Instandhaltung.

II.3.2.5.3 „Teleservice“

Teleservice wird in diesem Zusammenhang als Vehikel für den Transport von Daten

zwischen einer mobilen Arbeitsmaschine und einem zentralen Informationssystem genutzt.

Teleservice ist gemäß Definition „… der Datenaustausch mit entfernt stehenden technischen

II.3 Vernetzte Prozesse 126

Anlagen (z. B: mobilen Arbeitsmaschinen) zum Zweck der Fehlererkennung, Diagnose,

Wartung, Datenanalyse oder Optimierung“.

II.3.2.5.4 Was sind „Vorbeugende Instandhaltungsprozesse durch

Teleservice“?

Vorbeugende Instandhaltungsprozesse durch Teleservice ist nun die konsequente „Um-

setzung der Planung von Maßnahmen zur Bewahrung des Sollzustandes, sowie die Fest-

stellung und Beurteilung des Istzustandes einer mobilen Arbeitsmaschine“ unter Zuhilfe-

nahme der Techniken des Teleservice.

Die Bewahrung des Sollzustandes, und damit die Aufrechterhaltung der Betriebsfähigkeit der

mobilen Arbeitsmaschine, wird exemplarisch durch die Überwachung eines Motorluftfilters

gezeigt. Es wird die Druckdifferenz zwischen Ein- und Ausgang des Luftfilters gemessen.

Nach Über- bzw. Unterschreitung vordefinierter Differenzdrücke wird ein Trigger ausgelöst.

Dieser Trigger löst den relevanten Instandhaltungsprozess aus.

Der Ablauf des Instandhaltungsprozesses ist schematisch in Bild II.75 und Bild II.76 skizziert.

II.3 Vernetzte Prozesse 127

Bild II.75: Condition Monitoring am Beispiel der Luftfilterüberwachung

Teil 1: Prozessschritte 1 bis 5

II.3 Vernetzte Prozesse 128

Bild II.76: Condition Monitoring am Beispiel der Luftfilterüberwachung

Teil 2: Prozessschritte 6 bis 11

II.4 Systembasierte Dienstleistungen 129

II.4 Systembasierte Dienstleistungen

Neben dem Verkauf landtechnischer Produkte hat der Service bei CLAAS eine hohe

Bedeutung. Eine hohe Betriebsbereitschaft und Verfügbarkeit der CLAAS Maschinen, die

Erbringung wertschöpfender Dienstleistungen und der Erhalt der Kundenzufriedenheit

motivieren zum Ausbau des Dienstleistungsgeschäftes. Ziel des Unternehmens ist es, für die

komplette Bandbreite der Produkte Dienstleistungen anzubieten. Diese Dienstleistungen

über den Lebenszyklus der Maschinen richten sich auf individuelle Bedingungen der

Kunden. Durch Verknüpfung technischer Produkte mit „intelligenten“ Dienstleistungen

werden integrierte/hybride Leistungsangebote geschaffen. Diese Leistungssysteme stützen

sich auf moderne Informations- und Kommunikationstechnologien.

II.4.1 Dienstleistungsangebote für mobile Arbeitsmaschinen

Bild II.77: Entwicklung der Dienstleistungsangebote für mobile Arbeitsmaschinen

Der Wandel vom Produktanbieter zum Anbieter von Leistungssystemen aus Produkten und

Dienstleistungen (Bild II.77) erfordert eine entsprechende Dienstleistungsstrategie, eine

angepasste Gestaltung des Dienstleistungsportfolios. Claas hat die drei Dienstleistungsfelder

Agrartechnik und Produktionsmittel, (Agrar-) Produktion und Unternehmensmanagement

definiert (Bild II.78). Daneben existieren noch Claas-interne und vertriebspartnergerichtete

Dienste.

II.4 Systembasierte Dienstleistungen 130

CLAAS interneDienste

Vertriebspartner - gerichtete Dienste

Unternehmens- management• Marktorientierung/

Differenzierung• Betriebswirtschaftl.

gemanagte Gro ß betriebe, neue Kooperationsformen

• Vernetzung mit Kompetenzpartnern ( - zentren)

(Agrar) Produktion• Arbeitserledigung als

Komplettangebot• Dokumentation von

Prozessdaten• Prozess- /Stückkosten-

optimierung

Agrartechnik undProduktionsmittel• Nutzung statt

Investment• H ö chste Effizienz• Hohe Sicherheit/

Verfü gbarkeit

Maschinen

Bild II.78: Dienstleistungsfelder und ihre aktuellen Trends

II.4.1.1 Dienstleistungsfelder und ihre aktuellen Trends

Die drei Dienstleistungsfelder (Bild II.78) werden im Folgenden näher beschrieben:

Im Dienstleistungsfeld Agrartechnik und Produktionsmittel rückt die langfristige Nutzung

der Maschine gegenüber dem Anfangsinvestment in den Vordergrund. Wichtig ist hier die

Sicherstellung der Maschinenbetriebsbereitschaft und -verfügbarkeit.

Das Dienstleistungsfeld (Agrar-)Produktion geht darüber hinaus und fokussiert die

Arbeitserledigung. Das heißt die Maschine ist betriebsbereit sowie verfügbar und soll nun

effizient eingesetzt werden. Dazu gehören sowohl die Dokumentation von Prozessdaten als

auch die Prozess- bzw. Stückkostenoptimierung als Dienstleistung für den Kunden.

Das umfassendste Dienstleistungsfeld ist das Unternehmensmanagement. Hier werden

Fragen des gesamten Unternehmensmanagements im Agrarbereich betrachtet. Angeboten

werden beispielsweise Optimierung im Prozessmanagement, Managementsysteme für

Lohnunternehmer und überbetriebliche Maschinenverwendung oder Fuhrparkmanagement.

II.4 Systembasierte Dienstleistungen 131

II.4.1.1.1 Besondere Rahmenbedingungen für Instandhaltungsleistungen in der Agrartechnik

Die Landtechnikbranche ist im Vergleich zur Kfz- und Nutzfahrzeugbranche durch geringe

Stückzahlen bei gleichzeitig hoher Variantenvielfalt gekennzeichnet. Das führt dazu, dass

bekannte und ausgereifte Methoden der Instandhaltung, wie sie insbesondere im

Automobilbereich verbreitet sind, für die Landtechnik nur sehr eingeschränkt angewandt

werden können. Je nach Nutzung der Maschinen – insbesondere unter den regional stark

variierenden Umweltbedingungen – gibt es große Abweichungen in den Wartungs- und

Instandhaltungsaufwendungen. Außerdem erschwert die unterschiedliche Ausstattung der

Werkstätten (teilweise ländliche, handwerkliche Prägung, wenig IT-Unterstützung, teilweise

unvollständige Arbeitsplanung) die Vorplanung.

II.4.1.1.2 Kundenanforderungen

Die Anforderungen des Maschinenbetreibers (Landwirt, Lohnunternehmer) gegenüber dem

Dienstleistungsanbieter sind:

a) niedrige Kosten der Betriebsbereitschaft

b) geringe Ausfallzeiten der Maschinen

c) hohe Zuverlässigkeit und Verfügbarkeit.

Zudem soll der Maschinenbetreiber unterstützt werden, die Maschinen effizient zu betreiben.

Aus einer von CLAAS durchgeführten Umfrage geht hervor (Bild II.79), dass die Forderung

der Kunden höherer Maschinenverfügbarkeit stetig zunimmt. Dies ist die Folge der

fortschreitenden Weiterentwicklung zu immer leistungsfähigeren Maschinen. Folglich werden

für die gleiche Arbeitsleistung immer weniger Maschinen benötigt. Somit steigt das Risiko bei

einem Maschinenausfall, einen Verfügbarkeitsengpass nicht ausgleichen zu können. Durch

stetige Verbesserung der Maschinenqualität durch kontinuierliche Verbesserungsmaß-

nahmen der Hersteller sinken die Instandhaltungskosten im Verhältnis zum ursprünglichen

Maschineninvest.

II.4 Systembasierte Dienstleistungen 132

95 %

98 %

10 %

6 %

Ø GeforderteMaschinen-verfügbarkeit

Ø Instandhaltungs-aufwand p.a. vom Neumaschinenwert

10 J

ahre

sfris

t

Bild II.79: Anforderung an die Maschinenverfügbarkeit

II.4.1.2 Instandhaltung als Teil der Lifecycle Kosten

II.4.1.2.1 Instandhaltungsbegriffe (DIN)

Bei der Abgrenzung der Leistungsinhalte in der Instandhaltung wurde auf die Definition der

Begriffe besonderer Wert gelegt. Je nach Begriffsdefinition können unterschiedliche Inhalte

gemeint sein. In Fragen der Instandhaltung liegen diesem Projekt die Definitionen der

DIN 3105 zugrunde (Bild II.80).

Kombination aller technischen und administrativen Maßnahmen sowie Maßnahmen des Managements während des Lebenszyklus einer Betrachtungseinheit zur Erhaltung des funktionsfähigen Zustandes oder die Rückführung in diesen, so dass die geforderte Funktion erfüllt werden kann.

Maßnahmen zur Feststellung und Beurteilung des Ist-Zustandes

Maßnahmen zur Verzögerung des Abbaus des vorhandenen Abnutzungsvorrats

Maßnahmen zur Rückführung in den funktionsfähigen Zustand

Maßnahmen zur Steigerung Funktionssicherheit

Inspektion Wartung Instandsetzung Verbesserung

Instandhaltung (DIN 3105)

Bild II.80: Begriffsdefinitionen nach DIN 3105

II.4.1.2.2 Instandhaltungsstrategien

Die Nutzung von Maschinen und Anlagen führt zu einem vorhersehbaren, unvermeidlichen

Abbau der hierfür konstruktiv vorgegebenen Abnutzungsvorräte. Diesen Vorgang beschreibt

eine idealisierte Abbaukurve. Je nach gewählter Instandhaltungsstrategie (Bild II.81) erfolgt

II.4 Systembasierte Dienstleistungen 133

die Instandsetzung zu unterschiedlichen Zeitpunkten im Verlauf der Abbaukurve einer

Maschine oder Anlage.

Ausfall

Sollzustand(nach Instandsetzung)

Schadensgrenze

Zeit Δ t

AusfallbedingteInstandhaltung (Feuerwehr)

Sollzustand(nach Instandsetzung)

Schadensgrenze

Zeit

Δ t

Sollzustand(nach Instand-setzung)

Schadens-grenze

Zeit Δ tΔ t

InspektionRest-Nutzungs-

vorrat

Soll-Ist-Differenz

VorbeugendeInstandhaltung (periodisch wiederkehrend)

Zustands-abhängigeInstandhaltung Zeit Dauerfest!

Bild II.81: Instandhaltungsstrategien

Traditionell wird die ausfallbedingte Instandhaltung verfolgt. Hier ist es wichtig, dass bei

Eintreten eines Schadensereignisses, eine rasche Instandhaltung sichergestellt wird. Eine

andere Strategie kommt insbesondere bei kritischen Bauteilen und Baugruppen zur

Anwendung. Diese Teile werden dauerfest konstruiert, um einen Schadensfall während des

Maschinenlebenszyklus mit hoher Wahrscheinlichkeit auszuschließen. Diese Strategie ist bei

Betrachtung der Maschinenlebenszykluskosten selten wirtschaftlich. Alternativ findet man die

vorbeugende Instandhaltung. Diese kommt häufig auch im Zusammenhang mit der

Inspektion und Wartung zum Tragen. Im Rahmen von definierten Zeitintervallen werden

ausgewählte Teile untersucht (Feststellung eines definierten Abnutzungsgrades) und

Verbrauchsmaterialien (Öle, Filter) ausgetauscht. Als vierte und auch im Projekt an

ausgewählten Baugruppen (Einzugskette, Luftfilter) sowie am Hydrauliköl untersuchte

Strategie kommt die zustandsabhängige Instandhaltung (Condition Monitoring), insbe-

sondere bei kritischen Bauteilen und Komponenten (hohe Folgekosten bei Ausfall), zum

Tragen. Wichtig ist eine eingehende Beurteilung aller Bauteile, Baugruppen und Kompo-

nenten zur Auswahl geeigneter Instandhaltungsstrategien.

II.4 Systembasierte Dienstleistungen 134

II.4.1.3 Dienstleistungsprozess

Instandhaltungsdienstleistungen folgen einem stetig wiederkehrenden Prozess, der mit dem

Identifizieren der Notwendigkeit beginnt und mit der Administration bzw. der Abrechnung der

Leistung endet. Verschiedene Instandhaltungsdienstleistungen wurden im Rahmen des

Projektes detailliert untersucht. Dazu wurden die Teilschritte der Dienstleistungserbringung

bezüglich des entsprechenden Arbeitsaufwandes analysiert. Das Ergebnis dieser Analyse ist

in Bild II.82 dargestellt.

Identifizierender Notwen- digkeit

PlanungOrganisation der Ressourcen

Durch-führung

Dokumen- tation

Administra-tion/ Ab-rechnung

Identifizierender Notwen- digkeit

PlanungOrganisation der Ressourcen

Durch-führung

Dokumen- tation

Administra-tion/ Ab-rechnung

Arbe

itsau

fwan

d

Zeitverlauf

Durchführung

Planung Administration

handwerklich/traditionellvorgeplant/standardisiert

Bild II.82: Traditionelle versus vorgeplante Instandhaltung

Dabei ist zu erkennen, dass die handwerklich/traditionellen Methoden der Instandhaltung

zwar einen geringen Planungsaufwand haben, in der Durchführung und insbesondere in der

Administration jedoch hohe Aufwendungen verursachen.

Insbesondere die Administrationsaufwendungen, aber auch die Aufwendungen für die

Durchführung der Instandhaltung lassen sich durch einen geringfügig höheren Planungs-

aufwand mit einem vorgeplanten und standardisierten Vorgehen erheblich reduzieren.

II.4 Systembasierte Dienstleistungen 135

II.4.1.3.1 Nutzung verteilter Informationen für den Produktentstehungsprozess

Produktentstehungsprozess

KundenFeedback

SchadenStatistik

MaschinenCAN-BusVersuch ET-

Umsätze

Telematik

Serviceverträge

Informationsquellen

Bild II.83: Verteilte Informationen verbessern den Produktentstehungsprozess

Ein Landtechnikhersteller, der wirtschaftliche Instandhaltungsangebote über den kompletten

Maschinenlebenszyklus anbieten will, muss möglichst umfassende Informationen zu Maschi-

neneinsatz und -nutzung zusammentragen. Dafür stehen ihm verschiedene Informations-

quellen zur Verfügung (Bild II.83). Traditionell werden in den Versuchsabteilungen der Her-

steller vielfältige Untersuchungen zu Funktion und Festigkeit angestellt. Darüber hinaus

bietet die Sensorausstattung der Maschinen die Möglichkeit, Maschinendaten zu generieren

und anschließend auszuwerten. Zu den im Markt befindlichen Maschinen erhält der

Hersteller über Kundendienstmitarbeiter und Schulungszentren ein umfangreiches Feed-

back, das informationstechnisch erfasst und strukturiert aufbereitet wird. Zusätzlich können

aus Ersatzteilumsätzen und Schadensstatistiken Instandhaltungsinformationen abgeleitet

werden. Sind Versuchsmaschinen in eine Telematikinfrastruktur eingebunden, so erlaubt

dies ein Monitoring von Sensorwerten zur Maschinennutzung und zum Auftreten von

Alarmen und Störungen. Eingebunden in Serviceverträge wird der komplette Instandhal-

tungsprozess professionell begleitet und zu Abrechnungs- und Dokumentationszwecken

einzelmaschinenbezogen informationstechnisch festgehalten. Die Bündelung und intelligente

Auswertung dieser Informationen geht in die frühen Phasen der Produktentstehung neuer

Maschinen ein. Dies verbessert die Qualität der Maschinen und der Instandhaltungsprozesse

über den gesamten Lebenszyklus.

II.4 Systembasierte Dienstleistungen 136

II.4.1.4 Dienstleistungsangebote

II.4.1.4.1 Planbare Instandhaltung als Kern

wirtschaftlicher Serviceangebote

FuE Methoden

PI (Planbare Instandhaltung)

Vernetzte Systembasis

Product-Lifecycle ManagementWer

ksta

ttman

agem

ent

DL-Entwicklung(Service Engineering)

und -Erbringung FuE M

anagement

Dienstleistungsstandards

Dienstleistungsmarkteting/-vertrieb

Dienstleistungskompetenz (HR)

Dienstleistungscontrolling

Service-Engineering Methoden

Bild II.84: Planbare Instandhaltung als Teil der Dienstleistungsorganisation

Die zuvor beschriebenen Werkzeuge zur Schaffung einer planbaren Instandhaltung sind Teil

der gesamten Dienstleistungsorganisation (Bild II.84). Wichtig sind FuE Methoden, um die

planbare Instandhaltung in den Produktentstehungsprozess zu integrieren. Weiterhin sind

durchgängige und vernetzte Systeme über alle Leistungsebenen erforderlich. Eingebettet ist

dieser Methoden- und Systemkern in das Product-Lifecycle-Management, das Werkstatt-

management der verteilten Händlerwerkstätten und das FuE Management des Unter-

nehmens. Ein steuernder Bestandteil im Gesamtprozess ist die systematische Dienst-

leistungsentwicklung und -erbringung basierend auf den Methoden des „Service

Engineering“.

II.4 Systembasierte Dienstleistungen 137

II.4.1.4.2 Wirtschaftliche Serviceangebote

Bild II.85: Standardisierte Bereitschaftsangebote

Die definitorische Klarheit aus der Instandhaltungsnorm (Bild II.80) sowie eindeutig beschrie-

bene, in der Leistungstiefe klar abgegrenzte, modellierte Instandhaltungsprozesse erlauben

die Beschreibung und Implementierung standardisierter Betriebsbereitschaftsangebote

(Bild II.85). Voraussetzung ist eine durchgängig vernetzte Systembasis von den Maschinen

über Händlersysteme bis hin zum Maschinenhersteller. Wirtschaftlich erfolgreich sind

Dienstleistungsangebote zur Maschinenbetriebsbereitschaft und -verfügbarkeit insbesondere

dann, wenn die beschriebenen Prozesse der systematischen Dienstleistungsentwicklung

zum Tragen kommen.

III Zusammenfassung 138

III Zusammenfassung

Zu den wichtigsten Entwicklungen im Segment der mobilen Arbeitsmaschinen der

vergangenen Jahre zählen die Teleservice-Systeme. Eine wichtige Teilfunktion dieser

Systeme stellt die Früherkennung und Ferndiagnose von Maschinenzuständen dar, um

Serviceprozesse optimieren und so den Maschinennutzen für den Betreiber maximieren zu

können. Auch der Zugriff auf Maschinendaten über das Internet kann den

Maschinenbetreiber unterstützen, die Einsatzplanung seiner Maschinen zu verbessern und

Prozessabläufe zu optimieren. Einem intelligenten Datenmanagement kommt innerhalb

eines Teleservice-Systems eine hohe Bedeutung zu.

Im Rahmen des Verbundprojektes ist es als Gesamtergebnis gelungen, ein umfassendes

Datenmanagementsystem für den Teleservice bei mobilen Arbeitsmaschinen zu entwickeln

sowie komplexe Logistik- und Instandhaltungsprozesse zu modellieren, um diese durch das

Datenmanagementsystem zu unterstützen.

In einem Teilprojekt wurde dazu eine modulare, dienstebasierte Softwarearchitektur

geschaffen. Parallel dazu wurde eine flexible Kommunikationsstruktur entwickelt, die eine

situationsabhängige Auswahl eines geeigneten Übertragungsmediums für die

Datenübertragung von der Maschine zum Backend-Server sowie die dortige Archivierung

ermöglicht. Zur Reduzierung der zu übertragenden Datenmengen wurden in einem weiteren

Teilprojekt leistungsfähige Kompressionsalgorithmen entwickelt und in praktischen

Versuchen erfolgreich erprobt. Es erfolgte weiterhin die Entwicklung und Erprobung von

Methoden zur automatisierten Zustandsüberwachung exemplarischer Baugruppen mit dem

Ziel einer Reststandzeitprognose, die dann als Grundlage zur Ableitung zustandsbasierter

Instandhaltungsstrategien für diese Baugruppen genutzt wurden. Die Entwicklung von

Prozessmodellen für die Logistikkette Rübe und einen Instandhaltungsprozess fand im

Rahmen eines weiteren Teilprojektes statt.

In verschiedenen praktischen Umsetzungen des Systems, sowohl auf einem stationären

Versuchstand als auch auf mehreren verschiedenen mobilen Arbeitsmaschinen, konnte die

Funktionsfähigkeit des Systems nachgewiesen werden.

IV Literaturverzeichnis 139

IV Literaturverzeichnis

[Abe01] Abe, S. Pattern Classification – Neuro-Fuzzy Methods and Their Comparison. Springer, London et al., 2001, ISBN 1-85233-352-9

[ABRW03] Angermann, A.; Beuschel, M.; Rau, M.; Wolfarth, U.

Matlab – Simulink – Stateflow. 2. Auflage. Oldenbourg Verlag München Wien, 2003

[Ahr03] Ahrends, O. Anwendungsbeispiel 1: Das Serviceformular – Ganzheitliche Umsetzung im Unternehmen. In [Lei03]

[Ali00] Aliev, R.; Bonfig, K. W.; Aliew, F.

Soft Computing. Verlag Technik, Berlin, 2000, ISBN 3-341-01238-9

[Aue93] Auernhammer, H.; Frisch, J.

Landwirtschaftliches Bus-System LBS. LAV, Frankfurt/Main, 1993

[Bec99] Becker, E. Teleservice in der Antriebstechnik auf Basis von Schwingungen. VDI-Berichte, Nr. 1416, VDI-Verlag, Düsseldorf, 1998, S. 90-93

[Bor02] Borgmeier, A. Teleservice im Maschinen- und Anlagenbau. Dissertation, TU Darmstadt, Deutscher Universitäts-Verlag, Wiesbaden, 2002, ISBN 3-8244-0658-6

[Bot95] Bothe, H.-H. Fuzzy Logic. 2. Aufl. Springer, Berlin, Heidelberg et. al., 1995, ISBN 3-540-56967-7

[Bot98] Bothe, H.-H. Neuro-Fuzzy-Methoden. Springer, Berlin, Heidelberg et. al., 1998, ISBN 3-540-57966-4

[Bro97] Brooks, R. R.; Iyengar, S. S.

Multi-Sensor Fusion: Fundamentals and Applications with Software. Prentice Hall PTR, Upper Saddle River – New Jersey, 1997, ISBN 0-13-901653-8,

[Bru00] Bruhn, I. Erhebung zu den Reparaturkosten von Maschinen auf Großbetrieben, dargestellt für Traktoren und Mähdrescher. Dissertation, Forschungsbericht Agrartechnik des VDI/MEG 357, Kiel, 2000, ISSN 0931-6264

[Die97] Diekhans, N.; Kausch, C.; Meyer, H. J.

Teleservicesysteme – Einsatzpotential bei Landmaschinen, Landtechnik, Ausgabe 02/1998, S. 104-105

[Div03] -, -. Autorenkollektiv des Leitfadens: Empfehlungen zur Gestaltung von Teleservice-Systemen in der Landmaschinenbranche. In [Lei03]

IV Literaturverzeichnis 140

[Dre96] Drews, P.; van de Venn, H. W.

Teleservice. BMT – Baumaschine + Technik, H. 11/12, 1996, S. 16-18

[Eic00a] Eichler, C. Instandhaltungstechnik, 5. Auflage, Verlag Technik GmbH, Berlin, 2000, ISBN 3444100667-2

[Eic00b] Eichler, C. Zu Entwicklungstendenz der Instandhaltung landtechnischer Arbeitsmittel. Agartechnik, 40 (1990), H. 9, S. 416-418

[Ets00] Etschberger, K. Controller Area-Network. 2. Aufl., Carl Hanser Verlag, München, Wien, 2000, ISBN 3-446-19431-2

[Ger07] Gericke, C. Entwicklung von Datenreduktionsverfahren mit dem Ziel der Fehlerfrüherkennung zur Verwendung in Teleservice Systemen, Technische Universität Braunschweig, Institut für Landmaschinen und Fluidtechnik, Studienarbeit, 2007

[GGRM07] Göres, T.; Grothaus, H.-P.; Rustemeyer, T.; Möller, A.

Development of a Data Management System for Teleservice Applications on Mobile Working Machines – DAMIT. In: Proceedings “Engineering Solutions for Energy and Food Production" of the 65th International Conference on Agricultural Engineering (Landtechnik AgEng), 2007, S. 265 - 270

[Gri99] Grimmelius, H. T.; Meiler, P. P.; Maas, H.L.M.M.; Bonnier, B.; Grevink, J. S.; van Kuilenburg, R. F.

Three State-of-the-Art Methods for Condition Monitoring. IEEE Transactions on Industrial Electronics, 46 (1999), No. 2, pp. 407-416

[Hal00] Hall, D. L. Lectures in Multisensor Data Fusion and Target Tracking. Tech Reach Inc. Artech House, Boston, CD-ROM, 2000, ISBN 1-580-53140-7

[Hal01] Hall, D. L.; Llinas, J.

Handbook of Multisensor Data Fusion. CRC Press. Boca Raton, London, New York, 2001, ISBN 0-8493-2379-7

[Hal92] Hall, D. L. Mathematical Techniques in Multisensor Data Fusion. Artech House, Boston, London, 1992, ISBN 0-89006-558-6

[Har03] Harms, H.-H.; Krallmann, J.

Teleservice von morgen – Entwicklungen und Trends, Tagung Landtechnik für Profis, VDI/MEG am 29.01.2003, Magdeburg, Tagungsband S.97-111

[Har97] Harnischfeger, M.; Hudetz, W.

Leitfaden: Teleservice einführen und nutzen. Maschinenbau-Verlag, Frankfurt/Main, 1997

IV Literaturverzeichnis 141

[Hil98] Hillenbrand, F. Transitional Recording für analoge Daten. etz Elektrotechnik und Automation, 119 (1998), H. 12, S. 42-43

[ISO09] -, -. ISO 11783, Tractors and machinery for agriculture and forestry - Serial control and communications data network

[Jac87] Jackson, P. Expertensysteme – eine Einführung. Addison Wesley, Bonn, 1987, ISBN 3-925118-4

[Kau97] Kausch, C. Einsatzpotential von Teleservice bei Landmaschinen. Unveröffentlichte Diplomarbeit am Institut für Landmaschinen und Fluidtechnik der TU Braunschweig, 1997

[Keh01] Kehrer, R. Konzentriert Messen. Computer und Automation. 2001, H. 11, S. 74-78

[Kla99] Klaus, F. Einführung in Techniken und Methoden der Multisensor-Datenfusion. Habilitation, Universität Siegen, 1999, Elektronische Ressource, urn:nbn:de:hbz:467-575

[Kol08] Kolonko, M. Stochastische Simulation, Vieweg+Teubner, 1. Auflage (2008), ISBN 978-3835102170

[Kra00] Krallmann, J. Analyse des Einspar- und Nutzenpotentials eines Teleservicesystems in der Landwirtschaft unter technischen und wirtschaftlichen Gesichtspunkten. Unveröffentlichte Diplomarbeit am Institut für Landmaschinen und Fluidtechnik der TU Braunschweig, 2000

[Kra03] Krallmann, J.; Fölster, N.

Fehlerlokalisierung und Schadensdiagnostik. In [Lei03]

[Krü00] Krüger, G.; Reschke, D.

Lehr- und Übungsbuch Telematik. Fachbuchverlag Leipzig, München, Wien, 2000, ISBN3-446-21053-9

[KTB00] -, -. Kuratorium für Technik und Bauwesen in der Landwirtschaft (KTBL): Elektronikeinsatz in der Landwirtschaft. KTBL-Schrift 390, 2000, ISBN 3-7843-2114-3

[KW03] Kall, P.; Wallace, S. W.

Stochastic Programming, Second Edition (2003), http://home.himolde.no/~wallace/manujw.pdf siehe auch: Stochastic Programming, Jogn Wiley & Sons, Chichester (1994)

IV Literaturverzeichnis 142

[Lei03] -, -. Leitfaden für eine gesamtheitliche Teleservice-Lösung in der Landmaschinenbranche. Abschlussbericht des Projektes „eine gesamtheitliche Teleservice-Lösung für die Landmaschinenbranche, CD-ROM, Braunschweig, 2003, ISBN 3-00-011832-2

[Löh03a] Löhner, L. Leitfaden für die Einführung von Teleservice. In [Lei03]

[Löh03b] Löhner, L. Verbesserte Instandhaltung landtechnischer Arbeitsmaschinen. In [Lei03]

[Luo95] Luo, R. C.; Kay, M. G.

Multisensor Intergration and Fusion for Intelligent Machines and Systems. Balex Publishin Corporation, Norwood, 1995, ISBN 0-89391-863-6

[Mah01] Mahler, R. Random Set Theory for Target Tracking and Identification. In [Hal01], pp. 14/1-14/33, 2001

[Mat00] Mattfeld, R. Systematische Grundlagenermittlung für ein Teleservice-System zur Betreuung eines selbstfahrenden Kartoffelroders während der Erntekampagne. Unveröffentlichte Diplomarbeit am Institut für Landmaschinen und Fluidtechnik der TU Braunschweig, 2000

[Met92] Metzger, K. Exakte Erfassung veränderlicher Meßgrößen – Transitional Recording für analoge Meßsignale. Markt und Technik, 1992, H. 37, S. 74-78

[Mic83] Michaelis, B. Einführung zusammengesetzter Messgrößen – ein Konzept zur Datenreduktion. Messen, Steuern, Regeln, 26 (1983), H. 6, S. 302-304

[Möl03] Möller, A. Anwendungsbeispiel 3: Onlinediagnose am Kartoffelvollernter. In [Lei03]

[Mum02] -, -. Mumasy (Multimediales Maschineninformationssystem). Abschlusspräsentation, 23.04.2002, VDMA, Frankfurt/Main

[Nau96] Nauck, D.; Klawonn, F.; Kruse, R.

Neuronale Netze und Fuzzy-Systeme – Grundlagen des Konnektionismus, neuronaler Fuzzy-Systeme und der Kopplung mit wissensbasierten Methoden, 2. Aufl. Vieweg, Braunschweig, Wiesbaden, 1996, ISBN 3-528-15265-6

[Pea95] Pearson, J. C.; Gelfand, J. J.; Sullivan, W. E.; Peterson, R. M.; Spence, C. D.

Neural Network Approach to Sensory Fusion. In [Luo95], pp. 111-120

[Pla03] Platon, G. Rechtliche Aspekte des Teleservice. In [Lei03]

IV Literaturverzeichnis 143

[Pup91] Puppe, F. Einführung in Expertensysteme. 2.Aufl. Springer, Berlin, Heidelberg et. al., 1991, ISBN 3-540-54023-7

[Pup96] Puppe, F.; Gappa, U.; Poeck, K., Bamberger, S.

Wissensbasierte Diagnose- und Informationssysteme. Springer-Verlag, Berlin, 1996, ISBN 3-540-61369-2

[Rei99] Reininghaus, F. Systematische Grundlagenermittlung für ein Teleservice-System zur Betreuung eines selbstfahrenden Bunkerköpfroders während der Zuckerrübenernte. Unveröffentlichte Diplomarbeit am Institut für Landmaschinen und Fluidtechnik der TU Braunschweig, 1999

[Sch01] Schlichting, M. Erarbeitung eines Konzepts zur Implementierung eines Teleservicemoduls in eine Großballenpresse. Unveröffentlichte Diplomarbeit am Institut für Landmaschinen und Fluidtechnik der TU Braunschweig, 2001

[Sch03] Schlichting, M. Anwendungsbeispiel 2: SMS-Datenerfassung. In [Lei03]

[Sch92] Scholz, P.; Metzger, K.

Transitional Recording. Ein neues Verfahren zur Online-Datenreduktion bei der PC-gestützten, vielkanaligen Langzeitdatenaufnahme. Konferenz-Einzelbericht, MessComp ´92, Tagungsband, S. 95-98, ISBN 3-924651-33-7

[Sch95] Scholz, P. Methoden der ereignisgesteuerten Datenaufnahme. Konferenz-Einzelbericht, MessComp ´95, Tagungsband, S. 283-286, ISBN 3-924651-48-5

[Sch97] Scherer, A. Neuronale Netze: Grundlagen und Anwendungen. Vieweg, Braunschweig, Wiesbaden, 1997, ISBN 3-528-05465-4

[Sto99] Stone, L. D.; Barlow, C. A.; Corwin, Th., L.

Bayesian Multiple Target Tracking. Artech House, Bosten, London, 1999, ISBN 1-58053-024-9

[Tes00] -, -. Teleservice für mobile Maschinen und Anlagen – Abschlussbericht. VDMA-Verlag, Frankfurt/Main, 2000, ISBN 3-8163-0395-1

[Var97] Varshney, P. K. Distributed Detection and Data Fusion. Springer, Berlin et al., 1997, ISBN 0-387-94712-4

[Ven03] van de Venn, H. W.

Internetbasierter Teleservice für mobile Maschinen und Anlagen. Dissertation, RWTH Aachen, Berichte aus der Automatisierungstechnik, Shaker, Aachen, 2003, ISBN 3-8322-2123-9

IV Literaturverzeichnis 144

[Wal90] Waltz, E.; Llinas, J.

Multisensor Data Fusion. Artech House, Boston/London, 1990, ISBN 0-89006-277-3

[Wes98] Westkämper, E.; Wieland, J.

Neue Chancen durch Teleservice. Werkstatt und Betrieb, H. 6, 1998, S. 598-601

[WGS00] -, -. Department of Defense World Geodetic System 1984: Its Denition and Relationships with Local Geodetic Systems. 2000

[Wie96] Wiesbauer, A. Langzeit-Meßsignalaufzeichnung mit Datenkompression. Technischen Messen, 63 (1996), H. 1, S. 30-33

[Wit00] Wittmann, Th.; Hunscher, M.; Kischka, P.; Ruhland, J.

Data Mining. Peter Lang Verlag, Frankfurt/Main et. al., 2000, ISBN 3-631-36680-9

[Wit01] Witten, I. H.; Frank, E.

Data Mining. Carl Hanser Verlag, München, Wien, 2001, ISBN 3-446-21533-6

[Zak98] Zakharian, S.; Ladewig-Riebler, P.; Thoer, S.

Neuronale Netze für Ingenieure. Vieweg, Braunschweig, Wiesbaden, 1998, ISBN 3-528-05578-2

Veröffentlichungen und Vorträge 145

V Veröffentlichungen und Vorträge

Folgende Veröffentlichungen und Vorträge sind im Lauf des Verbundprojektes von den

Projektpartnern, teilweise in Kooperation, getätigt worden.

V.1 Veröffentlichungen

Göres, T.; Harms, H.-H.

Datenmanagementsystem für den Teleservice bei mobilen Arbeitsmaschinen, Landtechnik 62 (2007), Heft 5, S. 328-329, ISSN 0023-8082

Göres, T.; Harms, H.-H.

Data Management System for Teleservice in Mobile Machines, Beitrag Nr. 328 in der Online-Ausgabe der Zeitschrift Landtechnik, www.landtechnik-net.com,

Göres, T.; Grothaus, H.-P.; Rustemeyer, T.; Möller, A.

Development of a Data Management System for Teleservice Applications on Mobile Working Machines – DAMIT, 65th International Conference on Agricultural Engineering (Landtechnik AgEng) 09.-10.11.2007, Hannover Tagungsband “Engineering Solutions for Energy and Food Production” S. 265-270, ISBN: 978-3-18-092001-6

Göres, T. Daten für den Teleservice managen, Eilbote, Heft 18, 2008, Seite 9

Göres, T. Datenmanagement in der Landtechnik - Verschleiß messen und dem Fahrer melden, Lohnunternehmen 63 (2008), Heft 6, Seite 44-46

Göres, T.; Harms, H.-H.; Lang, T.

Methoden zur Datenkompression für Telematikanwendungen bei Landmaschinen, 66th International Conference Agricultural Engineering (LAND.TECHNIK 2008) 25.-26.09.2008, Stuttgart-Hohenheim Tagungsband “Landtechnik regional und international” S. 397-403, ISBN: 978-3-18-092045-0

Göres, T.; Harms, H.-H.; Lang, T.; Oetker, J. T.

Modellgestützte Zustandsdiagnose eines Luftfilters, Landtechnik 63 (2008), Heft 6, S. 346-347, ISSN 0023-8082

Göres, T.; Harms, H.-H.; Lang, T.; Oetker, J. T.

Model-based condition diagnosis of an air filter, Beitrag Nr. 346 in der Online-Ausgabe der Zeitschrift Landtechnik, www.landtechnik-net.com,

Göres, T. Datenmanagement für den Teleservice – Maschinenzustände automatisch überwachen, Neue Landwirtschaft 19 (2008), Heft 12, S. 62, ISSN 0863-2847

Veröffentlichungen und Vorträge 146

Göres, T.; Lang, T.; Harms, H.-H.

Datenkompressionsmethoden für Telematikanwendungen bei mobilen Maschinen, Landtechnik 64 (2009), Heft 1, S. 40 - 42, ISSN 0023-8082

Göres, T.; Lang, T.; Harms, H.-H.

Methods for data compression in telematics applications on mobile machines, S. 40-42 in der Online-Ausgabe 1/2009 der Zeitschrift Landtechnik, www.landtechnik-online.eu

V.2 Vorträge

Harms, H.-H.; Göres, T.

Entwicklung eines Datenmanagementsystems für den Teleservice bei mobilen Arbeitsmaschinen, Vortrag anlässlich der Veranstaltung „Industrielle Anwendungen als Herausforderung für Hochleistungs-Bioschmierstoffe“ der AG Bioöl des TAT am 16.10.2007 in Duisburg

Göres, T.; Grothaus, H.-P.; Rustemeyer, T.; Möller, A.

Development of a Data Management System for Teleservice Applications on Mobile Working Machines – DAMIT, 65th International Conference on Agricultural Engineering (Landtechnik AgEng) 09.-10.11.2007, Hannover

Göres, T.; Datenmanagement für den Teleservice - Aktueller Stand des Forschungsprojektes DAMIT, Vortrag vor dem Arbeitskreis Teleservice des VDMA am 27.02.2008 in Damme

Göres, T. Methoden zur Datenkompression bei Telematikanwendungen, Vortrag beim Kolloquium „Datenmanagement für den Teleservice bei Mobilen Arbeitsmaschinen“ am 04.04.2008 in Braunschweig

Bergmann-Eggers, S.; Wäsch, D.

Architektur und Kommunikation in Telematikanwendungen, Vortrag beim Kolloquium „Datenmanagement für den Teleservice bei Mobilen Arbeitsmaschinen“ am 04.04.2008 in Braunschweig

Ganseforth, A.; Möller, A.

OPTIPLAN – Datenmanagement in der Zuckerrüben-Logistikkette, Vortrag beim Kolloquium „Datenmanagement für den Teleservice bei Mobilen Arbeitsmaschinen“ am 04.04.2008 in Braunschweig

Grothaus, H.-P.. Planbare Instandhaltung über die Maschinenlebensdauer als Basis für innovatives Werkstattmanagement, Vortrag beim Kolloquium „Datenmanagement für den Teleservice bei Mobilen Arbeitsmaschinen“ am 04.04.2008 in Braunschweig

Göres, T.; Harms, H.-H.; Lang, T.

Methoden zur Datenkompression für Telematikanwendungen bei Landmaschinen, 66th International Conference Agricultural Engineering (LAND.TECHNIK 2008) 25.-26.09.2008, Stuttgart-Hohenheim

Veröffentlichungen und Vorträge 147

Ganseforth, A. Voraussetzungen für ein Condition Monitoring, Vortrag beim Abschlussworkshop im Verbundforschungsprojekt DAMIT „Datenmanagement für den Teleservice bei mobilen Arbeitsmaschinen“ am 27.03.2009 in Braunschweig

Dirks, M. Vorhersagbarkeit von Wartung und Instandhaltung, Vortrag beim Abschlussworkshop im Verbundforschungsprojekt DAMIT „Datenmanagement für den Teleservice bei mobilen Arbeitsmaschinen“ am 27.03.2009 in Braunschweig

Göres, T. Kompressionsmethoden für verschiedene Datenarten, Vortrag beim Abschlussworkshop im Verbundforschungsprojekt DAMIT „Datenmanagement für den Teleservice bei mobilen Arbeitsmaschinen“ am 27.03.2009 in Braunschweig

Wäsch, D. Software-Architektur und Datenfluss, Vortrag beim Abschlussworkshop im Verbundforschungsprojekt DAMIT „Datenmanagement für den Teleservice bei mobilen Arbeitsmaschinen“ am 27.03.2009 in Braunschweig

Möller, A. Technologien und Schnittstellen im Logistikprozess, Vortrag beim Abschlussworkshop im Verbundforschungsprojekt DAMIT „Datenmanagement für den Teleservice bei mobilen Arbeitsmaschinen“ am 27.03.2009 in Braunschweig

Brandt, V. Vorbeugende Instandhaltungsprozesse durch Teleservice, Vortrag beim Abschlussworkshop im Verbundforschungsprojekt DAMIT „Datenmanagement für den Teleservice bei mobilen Arbeitsmaschinen“ am 27.03.2009 in Braunschweig

Grothaus, H.-P.. Dienstleistungsangebote für mobile Arbeitsmaschinen, Vortrag beim Abschlussworkshop im Verbundforschungsprojekt DAMIT „Datenmanagement für den Teleservice bei mobilen Arbeitsmaschinen“ am 27.03.2009 in Braunschweig