Embed Size (px)
Citation preview
Masterthesis
Erfassung und Interpretierung von ISOBUS-Daten aus isobusfähigen Landmaschinen und
Bereitstellung der aufbereiteten Daten als Android-Service für die Android-App „farmpilot“ auf einem
Android-Tablet.
Fachbereich Elektrotechnik und Informatik Masterstudiengang Informationstechnik
Name: Alexander Kuhn Matrikelnummer: 578748 Erstellt bei: arvato Systems GmbH in Gütersloh
Erstprüfer: Prof. Dr. rer. nat. Nikolaus Wulff, FH Münster Zweitprüfer: Dipl.- Ing. Christoph Apke, arvato Systems GmbH
II
Danksagung
Mein besonderer Dank gilt meiner Familie und meiner Freundin, auf die ich mich zu
jeder Zeit verlassen kann und die hierdurch wesentlich zum Erfolg dieser Arbeit
beigetragen haben.
Des Weiteren bedanke ich mich bei Herrn Prof. Dr. rer. nat. Nikolaus Wulff für seine
Unterstützung und die Betreuung meiner Arbeit.
Nicht zuletzt geht mein Dank an meinen Kollegen und arvato Systems internen
Betreuer Herrn Dipl.-Ing. Christoph Apke für seine hilfreichen konstruktiven
Kommentare und die angenehme Zusammenarbeit.
Darüber hinaus bedanke ich mich bei allen anderen, hier nicht im Einzelnen
genannten Personen, die mich bei der Anfertigung dieser Arbeit in unterschiedlicher
Weise unterstützt haben.
III
Eidesstattliche Erklärung
Hiermit versichere ich, dass ich die vorliegende Arbeit selbstständig angefertigt und
dabei nur die angegebenen oder bei Zitaten kenntlich gemachten Quellen und Hilfs-
mittel verwendet habe.
Ennigerloh, den ________________ _____________________________
Alexander Kuhn
IV
Kurzbeschreibung
In der nationalen und internationalen Landwirtschaftsindustrie werden vermehrt IT-
Lösungen in Landmaschinen (Mähdrescher, Rodemaschinen oder Traktoren)
eingesetzt, die als Organisations- oder Steuerungseinheiten dienen. Dabei kommt für
die Kommunikation zwischen den einzelnen Komponenten innerhalb einer
Landmaschine ein von der “International Organization for Standardization” ent-
wickeltes Transportprotokoll mit der Norm ISO 11783 zum Einsatz, das die
Steuerung und den Informationsaustausch auf einem Bussystem regelt.
Die auf dem Bussystem übertragenen Maschinendaten (ISOBUS-Daten) sind
heutzutage nicht nur für die Landmaschine und den Fahrer relevant. Sie werden
auch vermehrt von Disponenten für deren Einsatzplanung und Auswertung gefordert.
Im Rahmen dieser Masterarbeit wird eine Analyse der Gesamtsituation bezüglich der
ISOBUS-Datenverarbeitung auf Landmaschinen durchgeführt und eine Android-
Applikation konzipiert und implementiert, die als eigenständiges, natives Android-
Service im Hintergrund agiert und ISOBUS-Daten auswertet. Die ISOBUS-Daten
werden der externen Anwendung „farmpilot-App“ zur Verfügung gestellt.
V
Inhaltsverzeichnis
1 Einleitung ............................................................................................................. 1
1.1 Unternehmensprofil ....................................................................................... 1
1.2 arvato Systems .............................................................................................. 2
1.3 Abteilung NMA-D und das Produkt „farmpilot“ ............................................... 3
1.4 Hintergrund, Motivation und Zielsetzung ....................................................... 3
1.5 Gliederung der Arbeit .................................................................................... 4
2 Grundlagen .......................................................................................................... 5
2.1 „farmpilot“ - System ....................................................................................... 5
2.1.1 „farmpilot-Portal“ ..................................................................................... 7
2.1.2 „farmpilot-App“ ........................................................................................ 9
2.2 ISOBUS und CAN-Bus ................................................................................ 11
2.2.1 CAN-Bus ............................................................................................... 11
2.2.2 ISOBUS ................................................................................................ 15
3 Evaluation / Analyse .......................................................................................... 19
3.1 Derzeitiger IST-Zustand .............................................................................. 19
3.2 Möglichkeiten und Alternativen .................................................................... 20
3.2.1 Übertragungstechniken ......................................................................... 20
3.2.2 Hardware und Software ........................................................................ 22
4 Konzeption ........................................................................................................ 25
4.1 Anforderungen ............................................................................................. 25
4.1.1 Konzeptionelle Anforderungen .............................................................. 25
4.1.2 Technische Anforderungen ................................................................... 27
4.2 Analyse der Technik & Entscheidungsfindung ............................................ 29
4.2.1 Analyse: mobile Geräte ......................................................................... 29
4.2.2 Analyse: Funkübertragungstechnik und CANBUS-Komponente ........... 30
4.3 Analyse der ISOBUS-Nachrichten ............................................................... 32
VI
4.4 Entwurf ........................................................................................................ 37
4.4.1 Technischer Aufbau .............................................................................. 37
4.4.2 Datenkommunikation Bluetooth ............................................................ 38
4.4.3 Berechnung der ISOBUS-Identifier Komponenten ................................ 38
4.4.4 Datenspeicherung und Bereitstellung ................................................... 39
4.4.5 Adressermittlung ................................................................................... 40
4.4.6 Zusammenfassung & Ausschlusskriterium ........................................... 41
5 Implementierung ................................................................................................ 42
5.1 Organisatorisches ........................................................................................ 42
5.1.1 Vorgehensmodell .................................................................................. 42
5.1.2 Eingesetzte Technologie und Werkzeuge ............................................. 42
5.2 Allgemeine in Android verwendete Techniken ............................................. 43
5.2.1 Architektur ............................................................................................. 43
5.2.2 Manifest-Datei, Activity & Lebenszyklus ............................................... 45
5.2.3 Service .................................................................................................. 47
5.2.4 SQLite ................................................................................................... 48
5.2.5 ContentProvider & ContentResolver ..................................................... 50
5.3 Implementierung der ISOBUS-Reader App ................................................. 52
5.3.1 Grafische Benutzeroberflächen und Ablauf der Anwendung ................ 52
5.3.2 ISOBUS-Daten-Empfang und Berechnung ........................................... 58
5.3.3 ISOBUS-Daten-Verwaltung mit SQLite ................................................. 65
5.3.4 ISOBUS-Daten-Bereitstellung für externe Anwendungen ..................... 75
5.3.5 ISOBUS-Adressermittlung und Verwaltung .......................................... 78
6 Test ................................................................................................................... 83
6.1 Verifikation der Anwendung ......................................................................... 84
6.2 Validierung der Anwendung ........................................................................ 86
7 Fazit und Ausblick ............................................................................................. 87
8 Abbildungsverzeichnis ....................................................................................... 89
VII
9 Listingverzeichnis .............................................................................................. 91
10 Tabellenverzeichnis ........................................................................................ 93
11 Literaturverzeichnis ......................................................................................... 94
1
1 Einleitung
In diesem Abschnitt der Masterarbeit erfolgt ein kurzer Einblick in das Unternehmen
arvato Systems und in die Abteilung NMA-D, sowie das Produkt „farmpilot“.
Anschließend wird der Hintergrund und die Motivation sowie die Zielsetzung der
Arbeit beschrieben und eine kurze Erläuterung zur Gliederung gegeben.
1.1 Unternehmensprofil
Der Name „arvato“ ist ein Kunstname bzw. ein Akronym. Dabei steht „ar“ für das
lateinische Wort ars, die Kunst, „va“ für Variation, „t“ für Technik und „o“ für
Organisation. Gegründet wurde das Unternehmen „arvato AG“ im Juli 1999 und hat
seinen Hauptsitz in Gütersloh. [1]
Abb. 1.1 – Bertelsmann Struktur
„arvato“ ist ein Tochterunternehmen des internationalen Medienkonzerns
„Bertelsmann SE & Co. KGaA“ (ehemals „Bertelsmann AG“), zu der noch weitere
Haupt-Geschäftsbereiche wie „RTL Group“, die weltgrößte englischsprachige
Verlagsgruppe „Random House“ und Europas größtes Druck- und Verlagshaus
„Gruner + Jahr AG & Co. KG“ gehören. „arvato Systems“ ist ein Teilbereich von
„arvato“. [1] [2] [3] [4] [5]
Hierzu werden kurz einige Daten und Fakten zum Überblick genannt:
Bertelsmann erwirtschaftete einen Umsatz von ca. 15,3 Mrd € (2011), hat über
100.000 Mitarbeiter in mehr als 50 Ländern und hat mehr als 1.000 Einzelfirmen.
„arvato“ selbst machte einen Umsatz von 5,4 Mrd. € mit insgesamt über 68.000
Mitarbeitern in 36 Ländern, davon über 20.000 Mitarbeiter in Deutschland. Zu den
„arvato“-Leistungsbereichen zählen „Creation“ (Konzeption, Kampagnen-
management und Marketing), „CRM“, „Customer Service“, „E-Commerce“,
1.2 arvato Systems
2
„Finance“, „Print“, „Replication“ (CD- und DVD-Lösungen), „Supply Chain
Management“ und der für die Masterarbeit relevante Bereich „IT“ mit der
Unternehmenseinheit „arvato Systems“.
Abb. 1.2 – arvato-Leistungsbereiche
1.2 arvato Systems
Mit über 30 Jahren Erfahrung in der IT-Dienstleistung sowohl in Europa als auch in
Nordamerika und Asien machte „arvato Systems“ im Jahre 2011 mit mehr als 2.000
Mitarbeitern einen Umsatz von 265 Mio. €. Sowohl die Realisierung von Standard-
Software als auch branchenspezifische und individuell entwickelte IT-Systeme
gehören zu den Aufgaben des Unternehmens. Mit der Planung, Entwicklung und
Implementierung und der Inbetriebnahme und Betreuung der IT-Lösungen sollen
Geschäftsprozesse besser miteinander vernetzt und optimale Abläufe garantiert
werden. Die Branchen Handel, Logistik & Transport, Manufacturing, Medien sowie
Versorgung und Verwaltung sind das Augenmerk von arvato Systems. [6]
Des Weiteren stellt arvato Systems mit seiner 30-jährigen Erfahrung und dem vor Ort
in Gütersloh (Deutschland) befindlichen Großrechenzentrum und seinen Rechenzen-
trumsdienstleistungen (Infrastructure Services) eine langfristig stabile Nachhaltigkeit
und Internationalität aber auch einen nahezu perfekten Datenschutz und
Datensicherheit dar. Gerade in der heutigen Zeit haben diese Aspekte einen hohen
1.3 Abteilung NMA-D und das Produkt „farmpilot“
3
Stellenwert und die Kunden gewinnen ein noch stärkeres Vertrauen in arvato
Systems dadurch, dass die Daten in Europa/Deutschland gespeichert werden.
1.3 Abteilung NMA-D und das Produkt „farmpilot“
In der Abteilung NMA-D der arvato Systems GmbH ist das Produkt „farmpilot“
vorzufinden. Dieses Produkt wurde im Herbst 2009 nicht von einem externen
Unternehmen in Auftrag gegeben, sondern durch eigene Kreation und Ideenfindung
aufgestellt, welches sich in der Landwirtschaftsindustrie ansiedelt.
Hierbei wurde vorab mit Hilfe von Umfragen festgestellt, dass es einen großen
Bedarf an IT-Lösungen und IT-Dienstleistungen (sowohl im Hardware- als auch im
Softwarebereich) in der Landwirtschaftsindustrie gibt. Diesem wird beabsichtigt mit
„farmpilot“ entgegenzutreten und sich hierbei als Vorreiter mit großem IT-Potential
und einer möglichen Marktführerrolle zu platzieren.
„farmpilot“ dient als Organisationsportal sowohl der nationalen als auch der
internationalen Landwirtschaftsindustrie (Maschinenringe, Lohnunternehmer und
Landwirte), um entsprechende Arbeitsvorgänge sowohl vom Büro als auch direkt von
den Feldern aus effizienter zu verwalten. Auf das Produkt „farmpilot“ wird in Kapitel
2.1 „farmpilot“ - System genauer eingegangen.
1.4 Hintergrund, Motivation und Zielsetzung
Das Verwaltungstool „farmpilot“ besitzt bereits einen großen Umfang zur
Organisation von landwirtschaftlichen Aufgabenfeldern. Die Anwender (Landwirte,
Lohnunternehmer) stellen aber auch zusätzlich die Anforderung, Daten und Werte,
die bei einer landwirtschaftlichen Maschine auftreten ebenfalls mit in das
Verwaltungstool aufnehmen zu können. Diese Daten könnten dabei z.B. die
Geschwindigkeit des Traktors, die GPS-Position, den Bodenabstand des Mähgeräts
zum Boden und die Ausbringungsmenge der Gülle angeben oder eine Information
darüber sein, ob ein bestimmtes Ventil geöffnet oder geschlossen ist.
1.5 Gliederung der Arbeit
4
Um die zusätzlichen Daten aufnehmen zu können, wird eine Lösung als Teilprojekt
des Produkts „farmpilot“ konzipiert und entwickelt. Die Lösung liegt dabei in der
Erfassung und Auswertung von ISOBUS-Daten nach der Norm ISO 11783.
Die Realisierung erfolgt in Form einer Masterarbeit. Dazu wird eine Android
Anwendung entwickelt, die mit Hilfe zusätzlicher Hardware das Auslesen von
ISOBUS-Daten ermöglicht. Die Anwendung soll dabei weitestgehend im Hintergrund
agieren und die ISOBUS-Daten der „farmpilot-App“ für die Weiterverwendung
bereitstellen. Mit den ermittelten Daten hat die „farmpilot-App“ dann die Möglichkeit,
die Daten sowohl dem Landmaschinenfahrer direkt auf seinem Tablet anzuzeigen als
auch dem Disponenten zur Verfügung zu stellen, damit dieser auf dem „farmpilot-
Portal“ (Desktop) vom Verwaltungsgebäude aus die Übersicht behalten kann.
Die Erfassung von ISOBUS-Daten ist Kernpunkt dieser Masterarbeit.
1.5 Gliederung der Arbeit
Auf den folgenden Seiten werden zunächst die Grundlagen und Techniken erläutert,
die für die Realisierung des Projekts benötigt werden. Im Anschluss erfolgt eine
Analyse des derzeitigen Zustands und die Möglichkeiten und Alternativen zur
Erfassung der Daten werden aufgezeigt. Des Weiteren werden die Alternativen
bewertet und die gewählte Vorgehensweise und das Konzept vorgestellt. Zum
Schluss wird die Implementierung des aufgestellten Konzepts erläutert und auf die
bei der Realisierung angewendeten Testverfahren eingegangen.
5
2 Grundlagen
Um eine Software zur Erfassung und Auswertung von ISOBUS-Daten für das
Produkt „farmpilot“ konzeptionieren und realisieren zu können, werden verschiedene
Technologien sowohl bei der Hardware als auch bei der Software verwendet. Diese
grundlegenden Techniken werden in diesem Abschnitt der Arbeit kurz erläutert.
2.1 „farmpilot“ - System
„farmpilot“ ist das Organisationsportal für Maschinenringe, Lohnunternehmer und
Landwirte. Es ist das Produkt, zu dem diese Masterarbeit als Teilprojekt realisiert
wird, so dass eine Notwendigkeit besteht, das Produkt kurz vorzustellen.
„farmpilot“ stellt ein Verwaltungs- und Planungstool dar, welches für die nationale
aber auch für die internationale Landwirtschaftsindustrie entwickelt wurde. Das
Einsatzgebiet ist groß und vielfältig, da es sowohl für den landwirtschaftlichen
Fuhrpark, die Logistik und Disposition aber auch für die Pflanz-, Pflege- und
Erntevorgänge eingesetzt werden kann. Es dient der Pflege von Stammdaten,
Dokumentationsdaten und organisiert die Betriebsabläufe wie z.B. die
Einsatzplanung von Maschinen und Mitarbeitern. Des Weiteren steht dem
landwirtschaftlichen Auftraggeber (z.B. einem Maschinenring) eine gewisse Kontrolle
und Auswertung zur Verfügung.
Die Stärken von arvato Systems und dem Produkt „farmpilot“ sind zum einen die
Neutralität, da keine Bindung an einzelne Hersteller von landwirtschaftlichen Geräten
notwendig ist und zum anderen, dass trotzdem Kooperationen und Vernetzungen
bestehen, wie z.B. die Kooperation zum BMR (Bundesverband der Maschinenringe
e.V.) und dem CCI (Competence Center ISOBUS e.V.).
Die Abbildung „Abb. 2.1“ soll den Ablauf besser verdeutlichen. Dabei ist anzumerken,
dass „farmpilot“ aus zwei Bereichen besteht. Auf der linken Seite befindet sich das
„farmpilot-Portal“ welches von einem Desktop-PC bedient werden kann. Auf der
rechten Seite ist die „farmpilot-App“, die sich auf einem Terminal oder einem Tablet
befindet. Kapitel 2.1.1 „farmpilot-Portal“ und Kapitel 2.1.2 „farmpilot-App“ gehen
genauer auf die Komponenten ein.
2.1 „farmpilot“ - System
6
Abb. 2.1 – „farmpilot“ Gesamtübersicht
Sowohl das „farmpilot-Portal“ als auch die „farmpilot-App“ für Android-Tablets werden
auf der technischen Basis der Adobe Flash-Plattform entwickelt. Als Entwicklungs-
framework wird Apache Flex (ehemals Adobe Flex) und als plattformunabhängige
Laufzeitumgebung die „Adobe Integrated Runtime“ (häufig auch „Adobe Air“ oder
„AIR“ genannt) verwendet. Ab der AIR Version 2.5 (Oktober 2010) unterstützt es
Smartphones und Tablets, die auf „Blackberry Tablet OS“, „Android“ oder „iOS“
basieren. Zur Kommunikation, Datenverarbeitung und Datenhaltung dient das
zertifizierte Rechenzentrum von arvato Systems. Die Übertragung der Daten von der
mobilen „farmpilot-App“ auf dem Tablet erfolgt über das Mobilfunknetz.
2.1 „farmpilot“ - System
7
1 „Schlag“ ist der Fachbegriff für eine landwirtschaftlich genutzte Ackerfläche.
2.1.1 „farmpilot-Portal“
„farmpilot-Portal“ ist das Verwaltungssystem, welches sich auf dem Desktop PC
befindet. Eingegliedert wird „farmpilot-Portal“ derzeit in drei Module:
Abb. 2.2 – „farmpilot-Portal“ Module
Disposition
Im Dispositionsmodul besteht zum einen die Möglichkeit seine kundenbezogenen
Stammdaten wie Anschrift, Telefonnummer und Schlagdaten1 zu hinterlegen und
zum anderen können Mitarbeiter und Ressourcen (landwirtschaftliche Maschinen und
Geräte) gepflegt werden. Im Anschluss können mit Hilfe dieser Daten Einsätze und
Arbeitszeiten sowohl für die Mitarbeiter als auch für die Maschinen festgelegt,
koordiniert und kontrolliert werden. Dabei sind die Abläufe des Betriebs fest im Blick,
so dass die bestehenden Ressourcen optimal genutzt und deren Einsatz optimiert
werden kann. Zu dem Dispositionsmodul zählen die Bereiche Auftragserfassung,
Kampagnenplanung und Kunden-/Mitarbeiterverwaltung.
Abb. 2.3 – Tagesgenaue Disposition
2.1 „farmpilot“ - System
8
Abb. 2.4 – Detaildisposition (Einsatzplanung)
Flottenmanagement
Mit dem Flottenmanagement werden die Betriebsdaten zentral im „farmpilot-Portal“
erfasst, strukturiert und übersichtlich abgebildet. Somit besteht ein Überblick über alle
eigenen Prozesse und es können gegebenenfalls weitere Schritte eingeleitet werden.
Die Visualisierung im Portal selbst erfolgt weitgehend über graphische Darstellungen
anhand leicht verständlicher Diagramme. Die geographischen Informationen werden
dabei über eine integrierte Google®-Kartendarstellung angezeigt.
Das Modul erlaubt es dem Anwender mit Hilfe der Bereiche Maschinenübersicht,
Auftragsübersicht, Fahrzeuggruppen und Dokumentation eigene Maschinen zu
lokalisieren, ganze Fahrzeuggruppen zu managen und papierlos Aufträge zu
verwalten.
Die Abbildung „Abb. 2.5“ stellt eine Übersicht der Maschinen dar, die innerhalb des
Flottenmanagements derzeit im Einsatz und somit online verfügbar sind.
2.1 „farmpilot“ - System
9
Abb. 2.5 – Maschinenübersicht im Flottenmanagement
Diagnose
Die Diagnosefunktion ermöglicht eine erste Problemanalyse beim Kundendienst des
Herstellers unmittelbar nach Auftreten des Fehlers. Es wird davon profitiert, dass
vermeidbare Kundendienstfahrten eingespart und Fehler schneller behoben werden
können. Für einfache Bedienerfragen können Screenshots des Terminals oder
Konfigurationsdateien der Maschinen an „farmpilot“ gesendet werden. Eine
Ferndiagnose mit „farmpilot“ spart Zeit und Ressourcen. Die Anfahrts- und
Reisekosten können somit verringert werden.
2.1.2 „farmpilot-App“
Die „farmpilot-App“ ist das mobile Gegenstück vom „farmpilot-Portal“. Diese wird auf
einem Android-Tablet auf der Seite des Fahrers innerhalb einer landwirtschaftlichen
Maschine angewendet. Die App wird eingesetzt, um entsprechende Aufträge von
einem Disponenten zu empfangen (Push-Funktion). Der Fahrer erhält dabei ein
Auftragsset. Er kann zur gleichen Zeit nur ein einziges Auftragsset auf dem Tablet
verwalten. Zu einem Auftragsset gehören mehrere Aufträge und der Fahrer kann sich
zu jedem Auftrag die Auftragsdetails wie z.B. die Arbeitstätigkeit, die Position des zu
bearbeitenden Schlags und die Kundendaten (Schlagbesitzer, Telefonnummer,…)
anzeigen lassen. Befindet sich der Fahrer an dem entsprechenden Schlag, so kann
er die Bearbeitung des Schlags/Auftrags starten und später wieder stoppen.
Zusätzlich hat der Fahrer die Möglichkeit, detaillierte Angaben zur Arbeitszeit,
Rüstzeit, Pausen oder Überfahrt im Bereich Zeiterfassung zu machen.
2.1 „farmpilot“ - System
10
Abb. 2.6 – „farmpilot-App“ Hauptmenü
Abb. 2.7 – „farmpilot-App“ Auftragsbearbeitung
Sobald ein Auftrag abgeschlossen ist, sendet die App automatisch einen Bericht an
den Disponenten, so dass dieser sehen kann, dass ein Teil der Aufträge vom
Auftragsset abgearbeitet wurden. Ein Auftragsset kann pausiert und auch über
mehrere Tage bearbeitet werden. Ist das Auftragsset abgeschlossen, so wird es vom
Fahrer quittiert und an den Disponenten zurück gesendet.
Wie man hierbei bereits erkennen kann, ist das Produkt „farmpilot“ schon sehr um-
fangreich. Jedoch besteht der Wunsch zur Erfassung weiterer wichtiger Informa-
tionen wie den ISOBUS-Daten aus den landwirtschaftlichen Maschinen.
2.2 ISOBUS und CAN-Bus
11
2.2 ISOBUS und CAN-Bus
Für die Realisierung des Teilprojekts zur Erfassung von ISOBUS-Daten werden in
diesem Abschnitt die technischen Grundlagen aufgezeigt. In Kapitel 2.2.1 wird das
serielle Bussystem CAN-Bus (oder auch „CANBUS“ geschrieben) und in Kapitel
2.2.2 die in der Landwirtschaft eingesetzte Norm ISO 11783 (auch unter seinem
Markennamen „ISOBUS“ bekannt) erläutert. ISOBUS baut auf das Bussystem CAN-
Bus auf.
2.2.1 CAN-Bus
Der CAN-Bus (CAN = Controller Area Network) ist ein serielles Bussystem, welches
den Feldbussen angehört. Entwickelt wurde der Bus 1983 von Bosch mit dem Ziel
mehrere Steuergeräte, die in Automobilen eingesetzt werden, zu vernetzten und die
Menge an benötigten Kabeln zu verringern. Der CAN-Bus ist international
standardisiert und in der Norm ISO 11898 festgehalten. Im ISO/OSI-Referenzmodell
wird das Bussystem auf Layer 1 (physikalische Schicht) und Layer 2 (Datensicher-
ungsschicht) referenziert.
Als Übertragungsmedium dienen entweder Kupferleitungen oder Glasfaser, wobei
Kupferleitungen die gängige Variante darstellen. Innerhalb des Bussystems agieren
mehrere Steuergeräte (=Busteilnehmer) in gleichberechtigter Form, so dass hierbei
das „Multi-Master-Prinzip“ gilt. Dabei arbeitet CAN-Bus nach dem CSMA/CR-
Verfahren (CMSA/CR = Carrier Sense Multiple Access / Collision Resolution), bei der
Zugriffs- und Kommunikationskollisionen mittels Arbitrierung aufgelöst werden. [7]
Unter Arbitrierung ist zu verstehen, dass eine entsprechende Funktionseinheit als
Entscheider/Richter agiert und eine gerechte Zuteilung von Ressourcen durchführt.
Diese Funktionseinheit kann in Form einer elektrischen, digitalen Schaltung oder als
Softwareroutine realisiert werden. Beim CAN-Bus erfolgt eine bitweise Arbitrierung,
bei der die am Bussystem teilnehmenden Sender während des Sendens der eigenen
Nachricht (bestehend aus Identifier und Datenfeld) gleichzeitig auf dem Bus lauschen
und einen bitweisen Vergleich des Identifiers durchführen. Senden zwei Teilnehmer
gleichzeitig, so überschreibt das erste dominante Bit eines der beiden das ent-
sprechend rezessive des anderen, was dieser erkennt und seinen Übertragungs-
versuch beendet.
2.2 ISOBUS und CAN-Bus
12
Mit Hilfe dieses Verfahrens kann eine Wichtigkeit bzw. Hierarchie der Nachrichten
zugewiesen werden. Beim CAN-Bus steht eine Nachricht mit einem niedrigen Ident-
ifier für eine hohe Priorität und eine Nachricht mit einem hohen Identifier für eine
niedrige Priorität. Zur Datensicherung wird eine zyklische Redundanzprüfung (CRC =
Cyclic Redundancy Check) durchgeführt und zur Synchronisierung der Busteilneh-
mer das „bit stuffing“-Verfahren angewendet. Unter „bit stuffing“ (zu Deutsch „Bit-
stopfen“) ist das Einfügen eines inversen Bits bei einer entsprechend gleich-
bleibenden Folge von Bits zu verstehen. Beim CAN-Bus wird bei einer Folge von
mehr als fünf gleichen Bits ein inverses Bit dazwischen eingefügt, z.B. eine Bitfolge
„000000010100“ der Länge 12 wird zu einer Bitfolge „0000010010100“ der Länge 13.
Bei der Verwendung von Kupferleitungen als Übertragungsmedium erfolgt eine Ver-
arbeitung der Daten mittels Differenzsignalen. Diese werden mit zwei oder drei
Leitungen ausgeführt: CAN_HIGH, CAN_LOW und optional CAN_GND (Masse).
CAN_LOW enthält den komplementären Pegel von CAN_HIGH gegenüber einer
Ruhespannung von etwa 2V. Die Differenzspannung bei einem dominanten Bit
beträgt etwa 3V. Dadurch können Gleichtaktstörungen unterdrückt werden, da die
Differenz gleich bleibt. Die Abbildung „Abb. 2.8“ zeigt das Verhalten der
Differenzsignale. [7]
Abb. 2.8 – Spannungspegel im CAN-Bus; Darstellung der Rezessivität und Dominanz
Als Topologie wird in den meisten Fällen die Variante eines linienförmigen
Bussystems verwendet, obwohl auch ein sternförmiger Bus möglich ist. Der
sternförmige Bus zieht aber gegenüber dem linienförmigen Bussystem einige
Nachteile nach sich. Ein Abschlusswiderstand von 120 Ohm ist an beiden
Leitungsenden notwendig.
2.2 ISOBUS und CAN-Bus
13
Abb. 2.9 – Linearer CAN-Bus
Der CAN-Bus wird zwischen einem Highspeed-Bus (max. 1Mbit/s) und einem Low-
speed-Bus (max. 125kbit/s) unterschieden. Die maximale (theoretische) Leitungs-
länge beträgt ca. 40m bei 1 Mbit/s, 100m bei 500 kbit/s und 500m bei 125 kbit/s. Die
maximale Teilnehmeranzahl auf physikalischer Ebene hängt von den verwendeten
Bustreiberbausteinen (Transceiver, physikalische Anschaltung an den Bus) ab. Mit
gängigen Bausteinen sind 32, 64 oder bis zu 110 (mit Einschränkungen bis zu 128)
Teilnehmer pro Leitung möglich. Erweiterungsmöglichkeit über Repeater oder Bridge
sind jedoch ebenfalls gegeben. [7]
Eine CAN-Bus-Nachricht (auch Telegramm genannt) besteht aus einem Identifier
und dem Datenfeld, in der die relevanten Informationen enthalten sind. Die
Spezifikation definiert zwei verschiedene Identifier-Formate:
11-Bit-Identifier, auch „Base Frame Format“ genannt (CAN 2.0A)
29-Bit-Identifier, auch „Extended Frame Format“ genannt (CAN 2.0B)
Damit die Arbitrierung auch einwandfrei funktioniert, darf es zu einem Identifier immer
nur maximal einen Sender geben. Ein Busteilnehmer kann sowohl Empfänger als
auch Sender von Nachrichten mit beliebig vielen Identifiern sein.
Die CAN-Bus Norm fordert, dass das „Base Frame Format“ stets akzeptiert werden
muss. Das „Extended Frame Format“ kann akzeptiert, muss aber zumindest toleriert
werden.
Das Datenfeld einer CAN-Bus-Nachricht hat stets eine maximale Bit-Länge von 64-
Bit bzw. 8-Byte. Die Länge wird im Identifier im Bereich „Data Length Code“ fest-
gehalten. Somit kann die Länge der gesamten Nachricht variabel sein.
2.2 ISOBUS und CAN-Bus
14
Ein CAN-Bus-Telegramm besitzt einen genormten Telegrammrahmen, der als
„Frame“ bezeichnet wird. Hierbei gibt es vier verschiedene Arten von Frames: [7]
Daten-Frame, dient dem Transport von bis zu 8 Byte an Daten
Remote-Frame, dient der Anforderung eines Daten-Frames von einem
anderen Teilnehmer
Error-Frame, signalisiert allen Teilnehmern eine erkannte Fehlerbedingung in
der Übertragung
Overload-Frame, dient als Zwangspause zwischen Daten- und Remote-
Frames
Die Abbildungen „Abb. 2.10“ und „Abb. 2.11“ zeigen den Aufbau eines Daten-Frames
sowohl im „Base Frame Format“ als auch im „Extended Frame Format“.
Abb. 2.10 – Datentelegramm im „Base Frame Format“
Abb. 2.11 – Datentelegramm im „Extended Frame Format“
2.2 ISOBUS und CAN-Bus
15
Der Acknowledge-Slot wird verwendet, um den Empfang eines korrekten CAN-
Frames zu quittieren.
Aufgrund der geringen Kosten, der Echtzeitfähigkeit und der hohen Daten- und
Störsicherheit wird CAN-Bus nicht nur in der Automobilindustrie sondern auch in der
Automatisierungstechnik, den Aufzugsanlagen, der Flugzeug- und Raumfahrttechnik,
in Landmaschinen und in vielen weiteren Bereichen eingesetzt. [8]
2.2.2 ISOBUS
Die Akteure der landwirtschaftlichen Industrie (Landwirt und Disponent) hatten das
Bedürfnis, ihre Landmaschinen mit einer Technik auszustatten, die es Ihnen
ermöglicht, unterschiedliche Traktoren und Fahrerkabinen mit unterschiedlichen
Arbeitsgeräten verschiedener Hersteller zu verwenden und zu steuern, so dass
trotzdem noch eine reibungslose Kommunikation untereinander gewährleistet ist.
Damit soll auch die unnötige Anschaffung zusätzlicher, herstellerspezifischer Geräte
und Bedienelemente vermieden werden und somit Kosten eingespart werden
können.
Dazu wurde die Norm „ISO 11783“ mit dem Titel „Tractors and machinery for
agriculture and forestry — Serial control and communications data network —„
spezifiziert. Es wird oft der Markenname „ISOBUS“ für die Applikation verwendet.
Dabei stellt eine ISOBUS-Anwendung meist nur eine begrenzte Menge der in der
Norm definierten Möglichkeiten dar. Eine ISOBUS-Anwendung wird dabei an dem
OSI-Referenzmodell auf der Schicht 7 „Anwendungsschicht“ angesiedelt. Für die
erfolgreiche Kommunikation werden des Weiteren auch die Schichten 1
„Bitübertragungsschicht“ und 2 „Sicherungsschicht“ benötigt, die jedoch durch
Verwendung des „CAN-Bus“-Bussystems größten Teils abgedeckt werden. [9]
Die Norm definiert neben den physikalischen Eigenschaften des Netzwerkes wie
Stecker und Leitungen auch die Art der Teilnehmer sowie Datenformate und
Schnittstellen.
Netzwerkprotokoll SAE J1939
Als Grundlage für die Norm ISO 11783 werden wesentliche Teile des „SAE J1939“-
Netwerkprotokolls verwendet. SAE J1939 wird von der internationalen „Society of
2.2 ISOBUS und CAN-Bus
16
Automotive Engineers“ (SAE) definiert, welches wiederum auf der „Bitübertragungs-
schicht“ (Schicht 1) mit CAN-Highspeed nach ISO 11898 (CAN-Bus) arbeitet.
Da SAE J1939 auf CAN-Bus aufbaut, ist es ebenfalls ein Multimaster-System mit
dezentralisiertem Netzwerk-Management. Dabei werden die Informationen mittels
Parameter (Signale) beschrieben und in Parametergruppen (PGs) auf insgesamt 4
Speicherseiten (Data Page) zusammengefasst. Durch eine „Parameter Group
Number“ (PGN) wird eine entsprechende Parametergruppe eindeutig identifiziert.
[10]
In der Abbildung „Abb. 2.12“ wird dargestellt, wie das Protokoll AES J1939 den aus
CAN-Bus bekannten Identifier verwendet und in diesem eine entsprechende Para-
meter- und Speicherseiten-Logik unterbringt.
Abb. 2.12 – Detailierte Aufsplittung vom CAN-Identifier
Die Datenübertragung erfolgt in den meisten Fällen zyklisch. Somit können die
Empfänger Daten empfangen, ohne diese explizit anfordern zu müssen (Broadcast-
Verfahren). Es ist jedoch auch möglich, Daten explizit anzufordern und darauf eine
entsprechende Antwort zu erhalten. Eine Peer-to-Peer Kommunikation zwischen
zwei Steuergeräten ist ebenfalls möglich. Die Entscheidung, ob eine Broadcast- oder
ein Peer-to-Peer-Kommunikation angestrebt ist, wird in der Parametergruppe
definiert. In der Abbildung Abb. 2.12 wird es im unteren Bereich mit „PDU1 Format
(peer to peer)“ und PDU2 Format (broadcast)“ verdeutlicht.
Damit die Adressen der Teilnehmer nur einmal im Bussystem vorkommen und eine
störungsfreie Kommunikation gewährleistet ist, muss jedes Steuergerät eine
Mindestfunktionalität des dezentralen Netzwerk-Managements implementieren:
Auflösung von Adresskonflikten
2.2 ISOBUS und CAN-Bus
17
Laufende Prüfung, ob Steuergeräteadressen in einem Netzwerk doppelt
vergeben sind
Änderung der Steuergeräteadressen zur Laufzeit
ISOBUS
Die Norm ISO 11783 besteht aus insgesamt 13 Teilbereichen, in der die gesamten
physikalischen Eigenschaften als auch die Kommunikation der Teilnehmer und
Schnittstellen geregelt sind.
Die Anforderungen an ISOBUS sind vielfältig, jedoch stechen zwei entscheidende
Aspekte in der Landwirtschaftsindustrie derzeit stark hervor: „Precision Farming“ und
„gläserne Produktion“.
Das Ziel von „Precision Farming“ ist es eine präzisere, umweltfreundlichere und
kostengünstigere Landwirtschaftstätigkeit zu gewährleisten. Ein oft genanntes
Beispiel ist das Austragen von Dünge- und Unkrautbekämpfungsmittel auf den
Schlägen. Mit Hilfe der neuen Technik besteht die Möglichkeit, sparsam mit den
Mitteln umzugehen und präzise an den zu bearbeitenden Stellen eines Feldes
entsprechend mehr oder weniger an Mittel auszubringen.
Des Weiteren wird von den Ländern bzw. von den Behörden eine lückenlose
Dokumentation der landwirtschaftlichen Vorgänge gefordert, so dass stets ein
Einblick in die Arbeit und die Herstellungsabläufe gegeben ist. Dieser Aufwand
musste früher mühsam in Papierform festgehalten werden und der Verwaltungs-
aufwand war enorm. Mit Hilfe der ISOBUS-Technik auf Landmaschinen und der
grundsätzlichen vermehrten IT in der Landwirtschaftsindustrie wird der bürokratische
Verwaltungsaufwand durch die Technik stark entlastet und sogar noch präziser /
gläserner dokumentiert, da vermehrt genauere Informationen aufgenommen werden
können. Des Weiteren werden die Daten auf einem Farm-Managementsystem wie
z.B. dem „farmpilot-Portal“ gespeichert. Auf die Daten kann ein Disponent jederzeit
zugreifen und diese den Behörden in elektronischer oder Papierform zur Verfügung
stellen.
Als ISOBUS-Hardware werden dabei folgende Komponenten definiert: [9]
ISOBUS-Stecker
Es wurde ein einheitlicher Stecker für den Anschluss von Anbaugeräten
eingeführt, der sowohl Leitungen für die Datenübertragung (CAN_HIGH,
2.2 ISOBUS und CAN-Bus
18
CAN_LOW) als auch Leitungen zur Stromversorgung von elektrischen
Komponenten liefert.
Virtual Terminal
Ein Anzeige- und Bedienelement, welches einen Bildschirm mit einer
Auflösung von mindestens 200 x 200 Pixeln und 6 Druckknöpfen besitzen
muss.
Traktor-ECU
Das Traktorsteuergerät wird auf einem Traktor bzw. Trägerfahrzeug
angebracht und dient als „Jobrechner“ für die Verarbeitung von Informationen
und Signalen innerhalb des Fahrzeugs. In der einfachsten Variante „Lowcost-
Lösung“ stellt es Fahrgeschwindigkeit, Zapfwellendrehzahl und Dreipunkt-
positionen als Informationen zur Verfügung. Bei den höheren Varianten
werden Ventilstellungen, Hydraulikdrücke und viele weitere Informationen
bereitgestellt.
Implement-ECU
Implement-ECU ist der Jobrechner, der sich auf den Anbaugeräten befindet.
Er übernimmt sowohl die Steuerung der Maschine als auch die Anzeige von
Daten und die Umsetzung von Bedienereingaben.
Taskcontroller
Der Taskcontroller (TC) stellt die Schnittstelle zwischen dem „Farm
Management System“ und der Gerätesteuerung dar. Im einfachsten Fall
dokumentiert er die ausgeführte Arbeit. Der Fahrer kann jedoch dem
Taskcontroller auch Aufträge erteilen, die dieser eigenständig abarbeiten
kann. Ein Beispiel ist das oben genannte „Precision Farming“. Hierbei
übernimmt der Taskcontroller die präzise Ausbringung des Dünge- oder
Unkrautbeseitigungsmittels.
Fileserver
Der Fileserver stellt die Speichereinheit für alle an das ISOBUS-System
angeschlossen Geräte dar. Hierbei werden sowohl Informations- als auch
Konfigurationsdaten gespeichert.
Im Kapitel 4.3 „Analyse der ISOBUS-Nachrichten“ werden die ISOBUS-Telegramme
genauer erläutert.
19
3 Evaluation / Analyse
Im folgenden Abschnitt erfolgt eine Analyse des derzeitigen IST-Zustands bezüglich
der Landwirtschaftsindustrie und des Produkts „farmpilot“. Des Weiteren werden
Möglichkeiten und Alternativen bezüglich der Übertragungstechniken und der Hard-
und Software aufgezeigt, die zur Erfassung und Verwaltung von ISOBUS-Daten
möglich und nötig sind.
3.1 Derzeitiger IST-Zustand
IST-Zustand: „farmpilot“
In den Grundlagen wird verdeutlicht, dass das Produkt „farmpilot“ bereits mehrere
Lösungen für die Landwirtschaftsindustrie bereitstellt. Mit „farmpilot“ bzw. der mobilen
„farmpilot-App“ auf Tablets ist es derzeit jedoch nicht möglich, landwirtschaftliche
ISOBUS-Daten von den Landmaschinen zu erfassen und zu verwalten. Dieser
Mangel soll mit der Masterarbeit beseitigt werden.
IST-Zustand: Landwirtschaftsindustrie & Tablets
In der Landwirtschaft haben sich die Norm ISO 11783 und die ISOBUS-
Anwendungen etabliert. Diese werden auf den Landmaschinen vermehrt eingesetzt
und die Daten werden sowohl auf dem Bildschirm (Terminal) angezeigt als auch
aufgezeichnet (USB-Stick oder Speicherkarten) und auch per Mobilfunk an die
Zentrale gesendet.
All diese Terminals (unabhängig davon ob es „CCI-Terminals“, „Müller Elektronik-
Terminals“ oder „Class Terminals“ sind) haben jedoch einen bestimmten
gemeinsamen negativen Aspekt: Die Bildschirme sind alle im Traktor bzw. in der
Landmaschine fest integriert. Hierbei liegt der Vorteil in einem mobilen Endgerät.
Diese mobilen Geräte sind leicht und können mit einer KFZ-Halterung innerhalb einer
Fahrerkabine mühelos angebracht werden. Somit ist die Überlegung bzw. das Ziel,
dem Fahrer nur ein einziges Tablet zur Verfügung zu stellen, welches er für
unterschiedliche Aufträge und Arbeitsvorgänge in unterschiedlichen Traktoren bzw.
Fahrerkabinen einsetzen kann.
3.2 Möglichkeiten und Alternativen
20
Derzeit gibt es nur eine Entwicklung von der Firma Claas mit dem Namen „Class UT
App“, die ebenfalls die Strategie ansetzt, ISOBUS-Daten auf einem Tablet zu
empfangen und zu verwalten. Das Produkt befindet sich derzeit jedoch noch in der
Entwicklungsphase und steht nur für Apple-Tablets zur Verfügung.
3.2 Möglichkeiten und Alternativen
Es gibt verschiedene Systeme, mit denen die Datenerfassung von CANBUS/
ISOUBS-Daten möglich ist, sowohl in der Übertragungstechnik als auch im
Hardware- und Software/Betriebssystem-Bereich. In diesem Teilabschnitt sollen die
möglichen Varianten aufgezeigt und verglichen bzw. bewertet werden.
3.2.1 Übertragungstechniken
Als Übertragungstechniken sind prinzipiell zwei Varianten möglich. Zum einen die
kabelgebundene Übertragungstechnik und zum anderen die Übertragung auf Basis
von Funktechnik. In diesem Abschnitt werden nur die Möglichkeiten der Funktechnik
aufgezeigt, denn eine der Grundvoraussetzungen des Projekts ist die Verwendung
der kabellosen Datenkommunikation.
Infrarot:
Mit Hilfe einer Infrarot-Schnittstelle ist es möglich, Daten zwischen zwei Geräten zu
übertragen. Die „Infrared Data Association“ (IrDA) hat hierzu eine Standardisierung
von Infrarot-Transceivern und Protokollspezifikationen etabliert. Dabei ist nach
heutigem Standard nicht nur die „Serial Infrared“-Spezifikation mit einer geringen
Übertragungsgeschwindigkeit gegeben, sondern auch die „Ultra Fast Infrared“-
Spezifikation mit 96 Mbit/s oder Giga-IR mit 1Gbit/s. Die Infrarot-Übertragungsart hat
jedoch einige gravierende Nachteile: Zum einen sind die heutigen Geräte
(Smartphones & Tablets) selten mit einer Infrarot-Schnittstelle ausgestattet und zum
anderen besteht eine geringe Datenübertragungsreichweite von nur einigen Metern.
Des Weiteren ist ein ständiger Sichtkontakt zwischen den zwei Geräten von Nöten.
[12]
3.2 Möglichkeiten und Alternativen
21
WLAN:
Das WLAN als Funkübertragungstechnik zählt gegenüber der Infrarot-
Übertragungstechnik zu der bevorzugteren Variante. WLAN kann in zwei
verschiedenen Modi geführt werden: 1. Infrastruktur-Modus, bei dem ein „Wireless
Access Point“ als zentrale Stelle agiert und eine Koordination und Kommunikation für
mehrere Geräte (WLAN-Clients) bereitstellt. 2. „Ad-hoc-Modus“. In diesem Modus
gibt es keine koordinierende Master-Einheit, sondern die Funkübertragungs-
koordination erfolgt auf den jeweiligen Geräten selbst. Solch ein Funknetzwerk wird
mit einer sehr geringen Anzahl an Teilnehmern betrieben. Oft wird ein Ad-hoc-
Netzwerk zur Kommunikation von nur zwei Geräten verwendet. [13]
Bluetooth:
Mittels der Funkübertragungstechnik Bluetooth steht ebenfalls eine Kommunikations-
schnittstelle sowohl für Kleingeräte wie Mobiltelefone, Tablets oder PDAs als auch für
Computer und Peripheriegeräte zur Verfügung. Diese Technik erlaubt verbindungs-
lose sowie verbindungsbehaftete Übertragungen von Punkt zu Punkt mit einer der-
zeitigen maximalen Reichweite von ca. 100m. Bluetooth bietet im Schnitt eine Daten-
übertragungsrate von 1 bis 2Mbit/s, abhängig vom gewählten Modus. Ein großer
Vorteil gegenüber WLAN ist die geringe Leistungsaufnahme bei Bluetooth. [14]
Die Tabelle 3.1 stellt eine Übersicht dar.
Klasse Max. Leistung Max. Leistung Reichweite
allgemein
Reichweite
im Freien
Klasse 1 100 mW 20 dBm ca. 100 m ca. 100 m
Klasse 2 2,5 mW 4 dBm ca. 10 m ca. 50 m
Klasse 3 1 mW 0 dBm ca. 1 m ca. 10 m
Tabelle 3.1 – Bluetooth Klassen mit entsprechender Leistung und Reichweite
3.2 Möglichkeiten und Alternativen
22
3.2.2 Hardware und Software
Tablet & Smartphone-Hardware:
Zurzeit gibt es eine Vielzahl an verfügbaren mobilen Geräten und die Menge nimmt
stetig zu, wohingegen der Computerabsatzmarkt teilweise sinkt bzw. stagniert. Die
vier bekanntesten Betriebssysteme die sowohl für Smartphones als auch für Tablets
zur Verfügung stehen sind: Android von Google, iOS von Apple, BlackBerry10 von
BlackBerry (ehemals „Research in Motion“) und Windows Phone von Microsoft.
Diese Betriebssysteme unterstützen in der Funkübertragungstechnik sowohl WLAN
als auch Bluetooth. Des Weiteren bieten die Geräte die Mobilfunktechnik (GPRS,
UMTS und teilweise auch schon LTE) für Telefonie und Internet / Datenübertragung.
Die Bedienung erfolgt über einen berührungsempfindlichen Bildschirm (Touch
Screens).
Zu unterscheiden sind die mobilen Geräte bezüglich ihrer Betriebssysteme sowohl in
der Anwendung, als auch in der Entwicklung von Anwendungen (Apps) für diese
Geräte. Nicht nur der Aspekt der Entwicklung sondern auch die größtmögliche
Verbreitung der Anwendung steht für das Entwicklerteam im Vordergrund. Dabei ist
das Android-Betriebssystem mit mehr als 74% Marktanteil derzeitiger Marktführer bei
Smartphones und 67% Marktanteil bei Tablets. [15] [16]
Abb. 3.1 – Betriebssystem-Marktanteile bei Smartphones
Abb. 3.2 – Betriebssystem-Marktanteile bei Tablets
3.2 Möglichkeiten und Alternativen
23
CANBUS/ISOBUS-Hardware:
Schaut man sich auf dem Markt um, so gibt es nicht viele aber doch einige
Komponenten, die CANBUS-Daten entgegennehmen und weiterreichen können. Es
gibt sie in den Varianten CANBUSBluetooth, CANBUSWLAN, CANBUSLAN,
CANBUSUSB und CANBUSRS232. Hierbei gibt es auch verschiedene
Ausführungen, wie z.B. kleine Komponenten für den Bastlerbereich mit geringen
Kosten oder ausgereifte „Embedded-Boxen“, die in der Industrie und vor allem im
Außenbereich eingesetzt werden und preislich ein hohes Niveau aufzeigen. In
diesem Bereich spielt auch die Schutzart der elektronischen Geräte eine wichtige
Rolle, die einen Schutz des Gerätes gegen Fremdkörper (körnige Fremdkörper,
Staub und Wasser) aber auch den Schutz gegen Berührung durch den Menschen
(Finger, Werkzeug oder Draht) gewährleisten soll.
Eine geringe Auswahl an möglicher, zur Verfügung stehender Hardware soll kurz
aufgezeigt werden.
WLAN-Boxen:
CAN-Bus Ethernet / WLAN Gateway
CAN2Web Advanced [17]
Avisaro WLAN Device
CAN mit D-Sub [18]
CANlink WLAN [19]
3.2 Möglichkeiten und Alternativen
24
Bluetooth-Boxen:
C2BT2 - CAN Bluetooth
Adapter mit 9-pol. D-Sub [20]
BlueDash ECU [21]
(Derzeit in Entwicklungsphase von
der „University of Modena and Reggio
Emilia“ in Italien)
CANlink Bluetooth [22]
Alternative Variante zum eigenen Entwickeln eines CANBUS-Transceivers:
Der Einplatinencomputer “Raspberry Pi” mit ARM-Architektur und Linux als
Betriebssystem. Als Erweiterungsaufsteckmodul zur Erfassung von CANBUS-Daten
kommt ein PICAN-Modul zum Einsatz. Für die Funkübertragung kann ein WLAN-
oder ein Bluetooth-Dongle verwendet werden.
25
4 Konzeption
In Kapitel 3 wird eine Analyse des Produkts „farmpilot“ und die grundsätzlich
gegebenen Möglichkeiten und Alternativen bezüglich der CANBUS-Hardware und
der mobilen Geräte zur CANBUS-/ISOBUS-Datenerfassung durchgeführt. Der
Abschnitt Konzeption beschäftigt sich mit der konkreten Frage der Machbarkeit (das
Ob) und der Realisierung (das Wie) bezüglich der ISOBUS-Datenerfassung und
Datenverwaltung als Teilprojekt des Produkts „farmpilot“. Es erfolgt eine Analyse
sowohl der konzeptionellen als auch der technischen Anforderungen und eine
detaillierte Analyse der ISOBUS-Telegramme, welche das Fundament dieser
Masterarbeit bilden.
4.1 Anforderungen
Das Projekt weist konzeptionelle und technische Anforderungen auf, die in diesem
Abschnitt aufgezeigt werden. Grundsätzlich wird das Projekt bzw. die Anwendung als
Prototyp realisiert, welches als Grundlage für weitere Projekte herangezogen werden
soll.
4.1.1 Konzeptionelle Anforderungen
Folgende Anforderungen werden dabei festgelegt:
Erfassung der ISOBUS-Daten im „only read“- Modus
Selektives Erfassen der gefilterten Daten
Zugriff auf die Datenbank für externe Apps ermöglichen
Anmeldung und aktive Beteiligung am Bussystem
Anwendung soll als Hintergrundprozess agieren
Erfassung der ISOBUS-Daten im „only read“- Modus
Eines der wichtigsten Anforderungen ist das grundsätzliche Erfassen der ISOBUS-
Daten. Dabei soll die Möglichkeit gegeben werden, im „only read“ – Modus auf dem
ISOBUS-Netzwerk zu lauschen und die Telegramme entgegen zu nehmen.
4.1 Anforderungen
26
Selektives Erfassen der gefilterten Daten
Beim Empfang der Daten erhält der Anwender (Fahrer) die Möglichkeit, eine Auswahl
treffen zu können, welche ISOBUS-Daten für ihn relevant sind und welche er
diesbezüglich Speichern möchte. Es wird somit ein Filter-System integriert, mit dem
der Fahrer die Verwaltung der Telegrammart ( auch „Parameter Group Number“
genannt) pflegen kann. Eine genaue Erläuterung zu den Telegrammen erfolgt im
Kapitel 4.3 „Analyse der ISOBUS-Nachrichten“.
Zugriff auf die Datenbank für externe Apps ermöglichen
Die empfangen Daten werden in einer Datenbank in der Form abgespeichert, so
dass eine externe App einen lesenden und löschenden Zugriff auf die Datenbank
erhält. Hierbei ist zu beachten, dass der Zugriff auf die Datenbank sowohl von einer
nativen App als auch von einer App, die auf „Apache Flex“-Basis beruht, möglich ist.
Anmeldung und aktive Beteiligung am Bussystem
Als weitere Anforderung gilt die Anmeldung und aktive Beteiligung am Bussystem.
Hierbei soll das mobile Gerät nicht nur im „read only“-Modus lauschen, sondern sich
auch an das Bussystem anmelden und eine eigene eindeutige Adresse erhalten, so
dass das mobile Gerät auch von anderen Busteilnehmern gesehen wird.
Anwendung soll als Hintergrundprozess agieren
Eine weitere Vorgabe ist die Entwicklung der Anwendung solcherart, dass dem
Anwender für das Starten und Konfigurieren der Anwendung ein grafische
Benutzeroberfläche zur Verfügung steht. Anschließend wird in laufenden landwirt-
schaftlichen Betriebsvorgängen die Anwendung als „Background Process“ im
Hintergrund durchgeführt und die ISOBUS-Daten werden den externen
Anwendungen bereitgestellt.
4.1 Anforderungen
27
4.1.2 Technische Anforderungen
Folgende Anforderungen werden dabei festgelegt:
Funkbasierte Kommunikation zwischen Transceiver und mobilem Gerät
CANBUS-Embedded-Komponente zur bidirektionalen Kommunikation
Flexible Verwendung des mobilen Geräts in unterschiedlichen Traktoren
Einhaltung der Schutzart bei der CANBUS-Komponente
Funkbasierte Kommunikation zwischen CANBUS-Komponente und mobilem
Gerät
Eine der wichtigsten Vorgaben beim Erfassen der CANBUS-/ISOBUS-Daten ist die
kabellose Kommunikation zwischen der CANBUS-Komponente und dem mobilen
Gerät. Triftige Gründe dafür sind die Vermeidung von unnötigen Kabelverlegungen,
und möglichen Kabelbrüchen sowie das plötzliche Loslösen der Kabel an den
Komponenten. Des Weiteren ist an den mobilen Geräten meistens nur eine USB-
Stecker-Verbindung für die Datenübertragung gegeben. Oft wird die USB-Buchse für
die Stromversorgung benötigt und steht somit nahezu gar nicht für Daten-
übertragungen innerhalb des Traktors zur Verfügung. Des Weiteren gibt es derzeit
keinen Standard bzw. keine Norm für eine funkbasierte ISOBUS-Kommunikation mit
mobilen Geräten.
CANBUS-Embedded-Komponente zur bidirektionalen Kommunikation
Die CANBUS-Komponente soll ein kompaktes, eingebettetes System aufweisen.
Dabei soll die Kommunikation mit dem CANBUS-Bussystem kabelgebunden und auf
der anderen Seite die Kommunikation mit dem mobilen Gerät funkbasiert erfolgen.
Des Weiteren soll auf beiden Kommunikationskanälen eine bidirektionale
Datenübertragung stattfinden, d.h. das eingebettete System kann in beide Rich-
tungen sowohl Daten senden als auch empfangen.
4.1 Anforderungen
28
Flexible Verwendung des mobilen Geräts in unterschiedlichen Traktoren
Das Anzeige- und Bediengerät wird innerhalb einer Fahrerkabine so angewendet
bzw. angebracht, dass während der Fahr- und Arbeitsvorgänge das Gerät in der
Fahrerkabine fest verankert ist und sich einwandfrei bedienen lässt. Der Fahrer soll
jedoch die Möglichkeit haben, ein einziges mobiles Gerät auch auf anderen
Traktoren für seine Arbeitsvorgänge verwenden zu können. Dies setzt voraus, dass
auf jedem Traktor, bei dem das mobile Gerät eingesetzt werden soll, stets eine
eigene CANBUS-Komponente auf dem Traktor fest installiert werden muss.
Einhaltung der Schutzart bei der CANBUS-Komponente
Weil die CANBUS-Komponente stets in der Fahrerkabine mitgeführt wird, soll das
Gerät mindestens eine Schutzart von der Kategorie IP65 aufweisen.
Dies bedeutet, dass das Gerät staubdicht gegenüber Fremdkörpern sein muss und
einen vollständigen Schutz der innenliegenden elektronischen Komponenten vor
menschlichen Berührungen und gegen Strahlwasser aus jedem beliebigen Winkel
aufweisen muss.
4.2 Analyse der Technik & Entscheidungsfindung
29
4.2 Analyse der Technik & Entscheidungsfindung
In diesem Abschnitt erfolgt die Analyse der Technik bezüglich Ihrer Vor- und
Nachteile sowie ihrem Einsatzzweck und die anschließende Entscheidungsfindung
zu den Komponenten.
4.2.1 Analyse: mobile Geräte
Bei der Auswahl von mobilen Geräten kommt es zum einen auf die Art (Smartphone
oder Tablet) und die Größe (Maße des Gehäuses und der Bildschirmgröße) des
Geräts und zum anderen auf das einzusetzende Betriebssystem und die
Entwicklungssprache an.
Art & Maße des mobilen Geräts
Als mobile Geräte stehen sowohl Smartphones als auch Tablets von mehreren
Herstellern in verschiedenen Größen, Funktionen und Betriebssystem zur Auswahl.
Nahezu alle Geräte weisen die Mindestanforderungen WLAN, Bluetooth und den
Mobilfunkstandard der dritten Generation UMTS auf. Die Smartphone-Variante bietet
mit den kompakteren Größen eine bessere Mobilität gegenüber Tablets. Die
Bildschirmgrößen der Smartphones sind jedoch oft zu klein, so dass eine optimale
Lesbarkeit und Bedienung durch den Fahrer innerhalb der Fahrerkabine nicht
gegeben ist. Hierbei stellen die Tablets den entscheidenden Vorteil. Diese bieten die
gleichen Funktionen aber mit größeren Bildschirmdiagonalen von 7 Zoll (17,78 cm)
bis 10,1 Zoll (25,65 cm).
Betriebssystem & Entwicklungssprachen
Die vier am weitesten verbreiteten Betriebssysteme auf dem Smartphone- und
Tablet-Markt sind Android, iOS, Windows Phone und BlackBerry. Bezogen auf den
Marktanteil bei den Tablets stechen Android mit 67,0% und iOS mit 28,3% hervor.
Für das Entwicklerteam sind aber auch die Programmiersprache und die
möglicherweise anfallenden einmaligen oder kontinuierlichen Gebühren für das
Entwickeln und Bereitstellen der Anwendung auf den Verkaufsplattformen relevant.
4.2 Analyse der Technik & Entscheidungsfindung
30
Das grundsätzliche Entwickeln von Apps ist bei allen Betriebssystemen kostenlos.
Wird eine Anwendung auf der entsprechenden Verkaufsplattform zur Verfügung
gestellt, so sind die Kosten für eine Android-App mit Ausnahme von BlackBerry-Apps
am günstigsten. Google verlangt für die Anmeldung eines Android-Entwicklers bzw.
eines Android-Entwicklerteams am „Google Play Store“ einmalig 25 US-Dollar (ca. 19
Euro) [23], wohingegen Apple eine jährliche Gebühr von 79 Euro für das
Bereitstellen von iOS-Apps im „App Store“ verlangt [24]. Microsofts „Windows Phone
Store“ besitzt eine einmalige Entwicklergebühr von 99 US-Dollar (ca. 73 Euro) [25]
und beim „BlackBerry World“ ist das Bereitstellen einer App derzeit kostenlos [26].
Als Programmiersprache wird Java in Android, ObjectivC in iOS, C# in Windows
Phone und Java ME (Micro Edition) in Blackberry eingesetzt. Java ME ist eine
minimierte Variante von Java, die in etwa Java SE 1.3 entspricht.
Entscheidungsfindung:
Die vielen Vorteile von Android (Marktstellung, Entwicklergebühr, Programmier-
sprache Java, große Anzahl an Tablet-Geräten unterschiedlicher Hersteller, die meist
günstiger sind als die iPads von Apple) führten dazu, dass das Entwicklerteam sich
bereits beim Produkt „farmpilot“ für Android-Tablets entschieden hatte. Diese
Entscheidung wurde somit indirekt auch für dieses Teilprojekt als Anforderung
festgelegt.
4.2.2 Analyse: Funkübertragungstechnik und CANBUS-
Komponente
Bei der Entscheidungsfindung bezüglich des Kaufs einer CANBUS-Komponente
müssen folgende Anforderungen berücksichtig werden: eingebettetes System,
funkbasierte Datenübertragung mit einem Tablet, Einhaltung der Schutzart und
bidirektionale Kommunikation. Hierbei haben sich die Geräte „CANlink Bluetooth“ als
auch „CANlink WLAN“ durchgesetzt, weil diese beiden Geräte alle angegeben
Anforderungen erfüllen.
Da sowohl die CANBUS-Komponente als auch das Tablet sich in der Fahrerkabine
einer Landmaschine befinden werden, ist die Funkübertragungsstrecke auf nur
einige Meter begrenzt. Somit kommt sowohl die WLAN-Variante mit einer großen
Reichweite als auch die Bluetooth-Variante mit einer geringeren Funkübertragungs-
4.2 Analyse der Technik & Entscheidungsfindung
31
strecke als Einsatzmöglichkeit in Frage. Hinsichtlich der Datenübertragungs-
geschwindigkeit sind ebenfalls beide Varianten geeignet, weil die Datenrate auf dem
ISOBUS-System 250kbit/s beträgt. Bluetooth 2.0 erreicht 2Mbit/s und WLAN 802.11g
bis zu 54Mbit/s.
Die „CANlink WLAN“-Komponente weist einige Nachteile auf. Dieses Gerät bietet
zwei verschiedene Betriebsarten an: „Access-Point-Modus“ und „Add-hoc-Modus“.
Beim Access-Point-Modus ist eine zusätzliche Komponente in der Fahrerkabine
nötig, die als Vermittlerstelle (Access-Point) für die CANBUS-Komponente und das
Tablet agieren muss. Der Add-hoc-Modus bietet eine Möglichkeit der Direkt-
kommunikation zwischen zwei Geräten, jedoch wird der Modus derzeit nicht vom
Android-Betriebssystem unterstützt. Ein weiterer, nicht unwichtiger Nachteil bezüglich
der WLAN-Variante besteht darin, dass der Traktor-Fahrer das Tablet-Gerät in
gewissen Situationen an andere WLAN-Stationen einbinden muss, um entsprech-
ende Daten an andere Landmaschinen oder an Industrieanlagen zu übertragen.
Hierbei müsste die CANBUS-Datenerfassung vom Fahrer stets unterbrochen
werden. Durch die Verwendung der „CANlink Bluetooth“-Komponente muss die
CANBUS-Datenerfassung nicht unterbrochen werden, weil die Bluetooth-Kommuni-
kationsschnittstelle nur für diese Anwendung zur Verfügung steht. Bluetooth stellt
somit einen eigenständigen für die Anwendung abgekoppelten Übertragungskanal
dar und die WLAN-Kommunikationsschnittstelle ist weiterhin frei verfügbar.
Die Kostenfrage ist ebenfalls ein Vorteil für „CANlink Bluetooth“. Mit einem Starterkit-
Preis von ca. 400€, ist es gegenüber „CANlink WLAN“ (Starterkit-Preis ca. 600€)
kostengünstiger und die Leistungsaufnahme bei der Bluetooth-Übertragungstechnik
ist geringer.
Entscheidungsfindung:
Aufgrund der Gegebenheit, dass sowohl WLAN als auch Bluetooth für den
Einsatzzweck der ISOBUS-Datenerfassung geeignet sind und die Bluetooth-Variante
einige Vorteile gegenüber der WLAN-Variante aufzeigt, fällt die Entscheidung zur
Verwendung einer CANBUS-Komponente auf das Produkt „CANlink WLAN“ von der
Firma RM Michaelides Software & Elektronik GmbH.
4.3 Analyse der ISOBUS-Nachrichten
32
4.3 Analyse der ISOBUS-Nachrichten
Um Information und Daten innerhalb des Projekts empfangen, interpretieren und
auch versenden zu können, muss der grundlänge Aufbau einer ISOBUS-Nachricht
verstanden werden. In diesem Abschnitt erfolgt eine Analyse der ISOBUS-
Telegramme.
Die Abbildung „Abb. 4.1“ verdeutlich grafisch den Nachrichtenaufbau des Netzwerk-
protokolls.
Abb. 4.1 - Detailierte Aufsplittung vom CAN-Identifier
Eine vollständige Nachricht bestehend aus den Verwaltungsinformationen (Identifier)
und den Daten (Data) wird „protocol data unit“ (PDU) genannt. Diese besteht aus
einem 29bit Identifier und dem anschließenden Datenbereich mit maximal 64bit.
Im Identifier werden die Informationen darüber festgehalten, um welche
Nachrichtenart es sich handelt, welche Informationen im Datenfeld übermittelt
werden, wer der Versender der Nachricht ist, wer die Nachricht erhalten soll und
welche Priorität die gesendete Nachricht aufweist. Im Data-Feld stehen dann die
relevanten Informationen wie z.B. die Geschwindigkeit des Traktors.
Die Nachricht (PDU) besteht aus sieben vorgegebenen Feldern:
- Priorität - Extended Data Page (EDP) - Data Page (DP)
- PDU Format (PF) - PDU Specific (PS) - Source Address (SA)
- Data
4.3 Analyse der ISOBUS-Nachrichten
33
Priorität EDP DP PF PS SA Data
Byte Nr.: 1 2 3 4 5
Anzahl
verwendeter
Bits:
3 1 1 8 8 8 64
Tabelle 4.1 – Byte-Belegung der entsprechenden Felder
Priorität:
Das erste Byte des Identifiers beinhaltet die Informationen über die Priorität. Es
werden nur die ersten drei Bits benötigt und die restlichen Bits von 4 bis 8 werden
verworfen. Die Prioritäten-Bits werden verwendet, um eine optimale Nachrichten-
latenz bei der Übertragung zu gewährleisten. Die höchste Priorität hat den Wert 0
(0002) und den niedrigsten Wert 7 (1112). Für Kontrollnachrichten ist der Default-Wert
3 (0112) und für alle restlichen Nachrichten der Default-Wert 6 (1102) definiert.
Extended Data Page (EDP):
Das EDP-Bit wird in Verbindung mit dem DP-Bit (Data Page) zur Festlegung der
Struktur des CAN Identifier innerhalb des CAN Data Frame verwendet. In allen
Nachrichten der Norm ISO 11783 ist die Null standardmäßig festgelegt. Für
zukünftige, mögliche Änderungen ist der Wert Eins zusätzlich von der Norm ISO
11783 reserviert. Die Tabelle 4.2 zeigt eine Beschreibung der Verwendung von EDP
und DP. Der EDP-Wert wird im zweiten Bit des zweiten Bytes festgehalten.
EDP
Bit 25
DP
Bit 24
Beschreibung / Verwendung
0 0 ISO 11783 PGN-Seite 0
0 1 ISO 11783 PGN-Seite 1
1 0 Reserviert für ISO 11783
1 1 ISO 15765-3
Tabelle 4.2 – Verwendung der EDP- /DP-Werte
4.3 Analyse der ISOBUS-Nachrichten
34
Data Page (DP):
In der Data Page wird die Seitenzahl festgelegt. Die Seitenzahl definiert das im
Identifier ausgewählte PDU Format. Der DP-Wert ist im ersten Bit von Byte 2
eingetragen. Die Abbildungen „Abb. 4.2“ und „Abb. 4.3“ sollen das Zusammenspiel
von EDP und DP verdeutlichen. „Abb. 4.2“ stellt dabei das PDU1 und „Abb. 4.3“ das
PDU2 Format dar.
Abb. 4.2 – Beschreibung des PDU1 Formats
PDU Format (PF) und PDU Specific (PS):
Das PDU Format verwendet insgesamt die vollen 8 Bit des dritten Bytes. Mit den 8
Bit ist ein Wertebereich von 0 bis 255 gegeben. In der Norm ISO 11783 wird der PF-
Wertebereich in zwei Bereiche von 0 bis 239 und von 240 bis 255 eingeteilt. Der
erste Teilbereich signalisiert, dass es sich um das PDU1 Format handelt und somit
das 4. Byte im Identifier, also das „PDU Specific“-Byte, für eine bestimmte
Zieladresse (Destination Address – DA) reserviert / verwendet wird. Dieses wird auch
als „PS(DA)“ in Abbildung „Abb. 4.2“ angezeigt.
Befindet sich der Wert des PF-Bytes jedoch im zweiten Teilbereich (zwischen 240
und 255), so handelt es sich hierbei um ein PDU2 Format. In diesem Fall beinhaltet
das „PDU Specific“-Byte keine Zieladresse, sondern wird als „erweiterter
Informationsbereich“ (Group Extension – GE) verwendet, welcher weitere Auf-
schlüsse über die Nachricht geben soll. Beim PDU2 Format handelt es sich um eine
Broadcast-Nachricht, die global an alle Teilnehmer gerichtet ist. Somit wird keine
4.3 Analyse der ISOBUS-Nachrichten
35
Zieladresse benötigt. Die Abbildung „Abb. 4.3“ zeigt das „PDU2 Format“ auf, in der
„Group Extension“ als „PS(GE)“ dargestellt wird.
PDU Format PF PS
PDU 1 0 bis 239 Destination Address (DA)
PDU 2 240 bis 255 Group Extension (GE)
Tabelle 4.3 – Bedeutung der PDU Formate
Für das PDU1 Format sind insgesamt 2 x 240 = 480 verschiedene Zahlenkom-
binationen bzw. Nachrichtenvarianten möglich. Das PDU2 Format definiert 2 x 16 x
256 = 8192 Varianten von Nachrichten.
Abb. 4.3 - Beschreibung des PDU2 Formats
Zur vereinfachten Definition und Unterscheidung der Nachrichten und zur besseren
Handhabung der Nachrichten wird die „Parameter Group Number“ (PGN) definiert.
Für das PDU1 Format bildet sich die PGN aus den Bytes/Feldern von EDP, DP und
PF. Für das PDU2 Format bildet sich die PGN aus den Feldern EDP, DP, PF und
PS.
Die gesamte Anzahl an möglichen PGNs entspricht somit 8672 (480 PGNs für PDU1
und 8192 PGNs für PDU2).
4.3 Analyse der ISOBUS-Nachrichten
36
Source Address (SA):
Im sechsten Byte des Identifiers befindet sich in jeder Nachricht die Source Address.
Dies ist die eindeutige Adresse des Senders. Insgesamt sind 255 SA’s möglich.
Mit den gegebenen Informationen über den Aufbau der ISOBUS-Nachricht kann das
Empfangen und Interpretieren präzise durchgeführt werden.
4.4 Entwurf
37
4.4 Entwurf
Anhand der definierten Anforderungen und der durchgeführten Analyse wird ein
Entwurf des Projekts zur Erfassung und Interpretierung von ISOBUS-Daten
konzeptioniert. Der Entwurf beschäftigt sich hauptsächlich mit der Entscheidung, wie
die Anforderungen optimal umgesetzt werden können. Das Projekt stellt dabei ein
Teilprojekt des Produkts „farmpilot“ dar, welches die Daten dem Produkt „farmpilot“
zur Verfügung stellt.
Die Basis zur Entwicklung der Anwendung erfolgt auf dem Betriebssystem Android
und einem Android-Tablet der Marke „Samsung Galaxy Tab 10.1“, welcher innerhalb
des „farmpilot“-Produkts als Referenzgerät für die Entwicklung verwendet wird und
auch den Landwirten für „farmpilot“-Testphasen vom Unternehmen für drei Monate
bereitgestellt wird. Auf die Android Entwicklung wird im Kapitel 5.1.2 „Eingesetzte
Technologien“ genauer eingegangen.
4.4.1 Technischer Aufbau
Der technische Aufbau der Hardwarekomponenten besteht aus dem CANBUS-
Bussystem, an dem mehrere CANBUS-Teilnehmer angeschlossen sein können. Als
wichtige Teilnehmer zählen der Jobrechner, der für das Kommunikations-
management innerhalb des Bussystems zuständig ist und der „Virtual Terminal“,
welcher als Bildschirm und Bedienfeld für den Fahrer agiert. An das CANBUS-
Bussystem erfolgt ein kabelgebundener Anschluss des „CANlink Bluetooth“-Geräts.
Die Kommunikation zwischen CANlink und dem Android-Tablet wird mittels der
funkbasierten Variante per Bluetooth realisiert. In der Abbildung „Abb. 4.4“ wird der
technische Aufbau grafisch dargestellt.
CANBUS -
Bussystem
Virtual Terminal
(Bildschirm)
Jobrechner
CANBUS-
Teilnehmer
1
WeitereCANBUS-Teilnehmer
CANBUS-
Teilnehmer
2
CANBUS-
Teilnehmer
n
kabelgebunden
kabelgebunden
kabelgebunden
CANlink
Bluetooth
kabelgebunden
(hier RS232)
...
Android-
TabletBluetooth
Abb. 4.4 – Systemkomponenten und Kommunikation
4.4 Entwurf
38
4.4.2 Datenkommunikation Bluetooth
Mit dem Produkt „CANlink Bluetooth“ (kurz: CANlink) vom Unternehmen „RM Micha-
elides Software & Elektronik GmbH“ steht zusätzlich eine rudimentäre Beispiel-
Android-Anwendung zur Verfügung. Diese baut auf das von Google freie, bereit-
gestellte Beispiel „BluetoothChat-Example“ auf und gewährleistet einen Verbindungs-
aufbau mit CANlink. Des Weiteren bietet die Anwendung den Kommunikationsaufbau
mit dem CANBUS-Bussystem und dem entgegennehmen von CANBUS-Nachrichten.
Dieses Projekt verwendet die zur Verfügung gestellte Anwendung als Grundbaustein
und realisiert die Kommunikation und Datenerfassung von ISOBUS-Daten als
Erweiterung und nötiger Anpassung der Anwendung.
Android App: RM_BluetoothDemo
Package: rm.bluetooth.demo
RM_BluetoothDemo.java
BluetoothCommunicationService.java
DeviceListActivity.java
Package: rm.lib.bytemode
BmcCanMessage.java
BmCmd.java
BmcOnlineObject.java
BmcReset.java
ByteCommand.java
ByteCommandCallbacks.java
SendSerial.java
4.4.3 Berechnung der ISOBUS-Identifier Komponenten
Um aus dem Empfang von CANBUS-Nachrichten entsprechende ISOBUS-
Information zu erhalten, werden die CANBUS-Nachrichten einzeln entgegengenom-
men und ausgewertet. Diese Berechnung agiert dabei als ein eigenständiger Thread
innerhalb der Anwendung im Hintergrund, ohne dabei sowohl die Bluetooth-
Kommunikation und den damit einhergehenden Datenempfang als auch die GUI-
Ausgabe im Ablauf zu blockieren. Realisiert wird dieser Vorgang mit Hilfe des
Android-Services Konzepts. Im Kapitel 5.2.3 wird die Service-Komponente genauer
erklärt.
4.4 Entwurf
39
Bei der Berechnung der ISOBUS-Informationen werden die Identifier-Komponenten
„Priorität“, „Extended Data Page“, „Data Page“, „PDU Format“, „PDU Specific“ und
die „Source Address“ ermittelt. Der genaue Vorgang der Berechnung wird im Kapitel
5.3.2 detailliert erläutert.
4.4.4 Datenspeicherung und Bereitstellung
Nach der Berechnung der ISOBUS-Daten werden diese entsprechend verwaltet bzw.
gespeichert. Zur Datenverwaltung wird das relationale Datenbankmana-
gementsystem (DBMS) „SQLite“ verwendet, welches von Android nativ bereitgestellt
wird. SQLite ist speziell für den Einsatz in eingebetteten Systemen entworfen
worden. Die gesamte Datenbank befindet sich dabei in einer einzigen Datei, die auf
dem Android-Gerät gespeichert wird. SQLite ist ein kompaktes, optimiertes,
serverloses („standalone“) Datenbanksystem, welches keine Installation und zentrale
Konfiguration erfordert. Trotzdem unterstützt SQLite einen Großteil der im SQL-92-
Standard festgelegten SQL-Sprachbefehle. Das DBMS erlaubt die zeitgleiche
Nutzung einer Datenbank durch mehrere Anwendungen. Es wird jedoch kein
komplexes Benutzer-Rechte-Management unterstützt. Eine Anwendung hat
entweder Zugriff auf die komplette Datenbank oder gar keinen Zugriff.
In der App soll der Benutzer die Möglichkeit haben entscheiden zu können, ob er alle
ISOBUS-Nachrichten erfassen möchte oder ob er einen „Parameter Group Number“-
Filter verwenden möchte, um nur bestimmte Nachrichten zu verwalten. Entsprechend
diejenigen Nachrichten dessen PGN-Wert im Filter enthalten ist.
Eine weitere Voraussetzung ist der Zugriff auf die ISOBUS-Daten bzw. auf die
SQLite-Datenbank von außen, d.h. sowohl von nativen, externen Android-Apps als
auch der mögliche Zugriff durch eine Anwendung, die mit Apache Flex entwickelt
wird. Weil eine SQLite-Datenbank in den Grundeinstellungen nur einen Zugriff auf
diejenige Anwendung gewährt, in der die Datenbank erzeugt wird, muss diese
Einstellung umkonfiguriert werden, so dass eine Berechtigung und physikalische
Sichtbarkeit im Speicher auch externen Anwendungen zur Verfügung steht.
4.4 Entwurf
40
Für die grundsätzliche Datenerfassung der ISOBUS-Daten sind zwei
Datenbanktabellen notwendig: „IsobusDataTable“ und „PgnDataTable“.
IsobusDataTable
Spaltenname Typ
_id INTEGER
canid TEXT_TYPE
candata TEXT_TYPE
pgn TEXT_TYPE
infotext TEXT_TYPE
timestamp TEXT_TYPE
PgnDataTable
Spaltenname Typ
_id INTEGER
pgn TEXT_TYPE
infotext TEXT_TYPE
4.4.5 Adressermittlung
Damit das Android-Tablet nicht nur als stiller Lauscher am Netzwerk agieren kann,
sondern auch als Teilnehmer am ISOBUS-Netzwerk für andere Teilnehmer bekannt
ist, ist eine weitere Funktion nötig. Dieser Vorgang wird nach der Norm ISO11783
„Address Claiming“ genannt.
Der Bereich „Source Address“ wird im Identifier der ISOBUS-Nachricht definiert.
Insgesamt sind 254 Teilnehmer an einem ISOBUS-Netzwerk möglich. Jeder dieser
Teilnehmer muss dabei eine eindeutige, an das Gerät vergebene Adresse (Source
Address) verwenden.
Die Funktion soll eine Adressermittlung für das Tablet durchführen. Es wird dazu
nach der Norm zunächst eine Anfrage / Broadcast („Request for Address Claimed“)
an alle Teilnehmer im Bussystem gesendet und diese melden sich mit einer Antwort-
Nachricht („Address Claimed“) am Bussystem. In der Rückmeldung sind die „Source
Adressen“ der anderen Teilnehmer enthalten. Das Tablet führt intern eine Adress-
verwaltungsliste, in der die Teilnehmer, die im Netzwerk vorhanden sind,
festgehalten werden und somit für das Tablet bekannt sind. Das Tablet prüft die
4.4 Entwurf
41
Adressverwaltungsliste und ermittelt im Anschluss eine freie ISOBUS-Adresse, die
es dem Netzwerk bekannt gibt.
Des Weiteren wird eine Funktion implementiert, so dass das Tablet eine Anmeldung
eines weiteren, neuen ISOBUS-Teilnehmers an das ISOBUS-Netzwerk erkennen
kann. Meldet sich dieser Teilnehmer mit der gleichen Absenderadresse, welches
auch das Tablet besitzt, so ermittelt das Tablet automatisch eine neue, freie „Source
Address“.
Somit werden die Anforderungen an die Mindestfunktionalität des Netzwerk-
managements erfüllt. Die Anforderungen werden zur Erinnerung ein weiteres Mal
aufgelistet.
Auflösung von Adresskonflikten
Laufende Prüfung, ob Steuergeräteadressen in einem Netzwerk doppelt
vergeben sind
Änderung der Steuergeräteadressen zur Laufzeit
4.4.6 Zusammenfassung & Ausschlusskriterium
Die in Kapitel 4.4 „Entwurf“ erläuterten Funktionen decken die geforderten
Anforderungen vollständig ab. In Kapitel 5 „Implementierung“ erfolgt eine detaillierte
Erläuterung der Funktionen. Diese werden mit den dazugehörigen, relevanten Code-
Abschnitten dokumentiert.
Es soll an dieser Stelle darauf hingewiesen werden, dass das Versenden von
CANBUS- / ISOBUS-Nachrichten an das Bussystem durch den Anwender / Fahrer
als Funktion in dieser Anwendung nicht zur Verfügung gestellt wird. Somit gibt es
auch keine Schnittstelle, mit der eine externe App ISOBUS-Daten an diese
Anwendung senden kann.
Die Begründung liegt darin, dass mit dem Senden von Nachrichten auch ein Eingriff
sowohl in die Arbeitsvorgänge als auch die Steuerung von Traktoren bzw.
Fahrkabinen möglich ist. Das Senden von Nachrichten kann somit eine potentielle
Gefahr darstellen und müsste somit von einem Technischen Überwachungsverein
(TÜV) abgenommen werden.
42
5 Implementierung
Neben der Analyse des bestehenden Prozesses und der Erstellung eines Konzeptes
zur Umsetzung des Projekts „ISOBUS-Datenerfassung“ ist auch die Realisierung
Aufgabe der Masterarbeit. In diesem Abschnitt werden die benötigten Funktionali-
täten und Masken erläutert.
5.1 Organisatorisches
5.1.1 Vorgehensmodell
Beim Unternehmen arvato Systems in der Abteilung NMA-D ist kein spezielles
Vorgehensmodell zur Durchführung von Softwareprojekten vorgeschrieben, sodass
die einzelnen Projektteams selbst entscheiden können, wie sie vorgehen möchten. In
diesem Projekt wird ein iterativ inkrementelles Vorgehensmodell eingesetzt, da es
ideal für die Realisierung dieses Projekts angewendet werden kann.
5.1.2 Eingesetzte Technologie und Werkzeuge
In Kapitel 4.2 „Analyse der Technik & Entscheidungsfindung“ wird erläutert, dass die
Entscheidung bezüglich der Hardware zugunsten eines Android-Tablets als mobiles
Gerät gefallen ist. Das Produkt „farmpilot“ entwickelt seine Anwendung „farmpilot-
App“ ebenfalls auf Basis von Android. Es wird jedoch sowohl für die Desktop-
Variante „farmpilot-Portal“ als auch für die mobile Variante „farmpilot-App“ die
plattformunabhängige Laufzeitumgebung „Adobe Integrated Runtime“ (Adobe AIR)
mit dem Entwicklungsframework Apache Flex und der Programmiersprache
Actionscript eingesetzt. Adobe AIR stellt seine Laufzeitumgebung dem Betriebs-
system Android, BlackBerry und iOS zur Verfügung.
Die Entwicklung dieses Projekt erfolgt nicht auf der Laufzeitumgebung Adobe AIR,
sondern setzt nativ auf Android auf. Als Entwicklungsumgebung wird Eclipse mit dem
Plugin „Android Development Tools“ (ADT) von Google eingesetzt. Die Entwicklung
erfolgt mit der Programmiersprache Java und dem Android SDK, welches
Bibliotheken und APIs von Google und weiteren bekannten Herstellern bereitstellt.
Mit Hilfe dem USB-Treiber und dem „Android Virtual Device“ (AVD), welche im SDK
5.2 Allgemeine in Android verwendete Techniken
43
Paket enthalten sind, kann direkt auf einem Android-Gerät oder durch die
Verwendung des AVD-Emulators eine Anwendung ausgeführt und getestet werden.
Des Weiteren enthält das ADT-Plugin eine Debuger-Funktion, mit der ein an den
Entwicklungs-PC angeschlossenes Gerät in direkter Kommunikation gedebuggt
werden kann.
5.2 Allgemeine in Android verwendete Techniken
Um den Implementierungsvorgang bezüglich der Android-App-Entwicklung zu
verdeutlichen, werden in diesem Abschnitt die relevanten Android-Techniken kurz
erläutert.
5.2.1 Architektur
Abb. 5.1 – Android Systemarchitektur
Die Systemarchitektur von Android ist in Form eines Schichten-Systems konzipiert.
Die einzelnen Schichten mit Ihren Aufgaben werden nachfolgend erläutert:
5.2 Allgemeine in Android verwendete Techniken
44
Linux Kernel
Die Basis von Android bildet ein Linux-Kernel. Der Linux-Kernel bildet in der Android-
Architektur die Hardwareabstraktionsschicht und enthält die benötigten Gerätetreiber.
Er ist zuständig für die Prozess- und Speicherverwaltung, stellt Schnittstellen für
Multimediakomponenten und die Netzwerkkommunikation bereit und ist zuständig für
die Energieverwaltung und das Sicherheitskonzept.
Libraries
Die Libraries-Schicht stellt eine große Menge an Standardbibliotheken zur Verfügung
und dient als Schnittstelle zwischen den Android-Anwendungen und dem Linux-
Kernel. Die Bibliotheken werden nativ in C oder C++ entwickelt. Diese stellen alle
erforderlichen Funktionalitäten wie z.B. Datenbank, Multimedia-Verwaltung,
Webzugriff, 2D- und 3D-Grafikbibliotheken etc., den Android-Anwendungen bereit.
Android Runtime
In der „Android Runtime“-Schicht stellt die „Dalvik Virtual Machine“ den Kern der
Laufzeitumgebung dar. Diese ist zuständig für die Interpretierung und Ausführung
der Android-Anwendungen. Android Apps werden in der Programmiersprache Java
entwickelt. Die „Core Libraries“ stellen die nötigen Android-Java-Klassenbibliotheken
dar. Anders als die Java-Virtual-Machine, die auf einem Kellerautomaten basiert,
stellt die Dalvik Virtual Machine eine Registermaschine dar.
Application Framework
Der Anwendungsrahmen stellt einer Anwendung entsprechende Systemklassen zur
Verfügung. Die Systemklassen sind komplett in Java geschrieben und gewähren
einen Zugriff auf Hardwarekomponenten aus der Anwendung heraus. Für die
Entwicklung einer Anwendung stehen dem Entwickler die Systemklassen bereit.
Applications
In der Anwendungsschicht befinden sich sowohl die Grundfunktionalitäten, die
sogenannten Android eigenen Anwendungen wie z.B. Telefonie, Browser,
Adressbuch oder Kalender als auch Drittanbieter-Anwendungen, die sich der
Benutzer nachträglich selber aus dem „Google Play Store“ oder einer anderen
alternativen Plattform herunterladen und installieren kann. In dieser Schicht befinden
sich auch die eigenen, selbstentwickelten Anwendungen.
5.2 Allgemeine in Android verwendete Techniken
45
5.2.2 Manifest-Datei, Activity & Lebenszyklus
Manifest-Datei
Android ist eine moderne Plattform für komponentenbasierte Anwendungen. Um den
Grundgedanken der Wiederverwendbarkeit von bestehenden Programmen und Pro-
grammteilen optimal zu nutzen und sparsamen Umgang mit verfügbaren Ressourcen
zu gewährleisten, stellt Android eine moderne Plattform für komponentenbasierte
Anwendungen zur Verfügung. Zu den Komponenten zählen „Activity“, „Service“,
„Content Provider“ und noch einige mehr.
Eine Android-Anwendung besteht aus mehreren Komponenten. Die einzelnen
Komponenten werden in einer „Manifest-Datei“ global festgehalten. Die Manifest-
Datei wird automatisch generiert und beinhaltet wichtige Informationen darüber, wie
die Anwendung aufgebaut und ausgeführt wird. Neben dem Eintrag der
Komponenten enthält die Datei den „package“-Namen, mit der eine Anwendung
eindeutig identifiziert wird. Auch der Hinweis auf die zuerst startende Oberfläche
(Main-Activity) und Berechtigungseinträge wie den Zugriff auf entsprechende
Hardwarekomponenten oder die Nutzerfreigabe für andere, externe Anwendungen
werden im Manifest geregelt. Das Listing 5.1 zeigt ein Beispiel solch einer Manifest-
Datei.
Listing 5.1 – Android Manifest-Datei
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.htchalloworld"
android:versionCode="1"
android:versionName="1.0" >
<uses-sdk
android:minSdkVersion="10"
android:targetSdkVersion="10" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<application
android:allowBackup="true"
android:icon="@drawable/ic_launcher"
android:label="@string/app_name"
android:theme="@style/AppTheme" >
<activity
android:name="com.example.htchalloworld.MainActivity"
android:label="@string/app_name" >
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>
5.2 Allgemeine in Android verwendete Techniken
46
Activity
Die meisten Android-Anwendungen besitzen grafische Benutzeroberflächen, die eine
Interaktion mit dem Benutzer gewähren. Activities dienen in Android zur Darstellung
und Verwaltung solcher Benutzeroberflächen. Activities sind in Android-
Anwendungen kein Muss (Beispiel Android-Services). Ist jedoch eine Interaktion mit
dem Benutzer erforderlich, so ist mindestens eine Activity in der Anwendung
notwendig. Eine Activity bestimmt die Sichtbarkeit der Oberflächenelemete
(Textfelder, Buttons, etc), behandelt Anwendereingaben und liest Eingabefelder aus
und reagiert auf die Auswahl in einem Menü. Eine Activity stellt die Kontrolleinheit
dar, die die entsprechenden Layout-Komponenten und Views verwaltet. Eine Layout-
Komponente ist zuständig für die relative oder absolute Anordnung der View-
Elemente (Oberflächenelemente).
Listing 5.2 – Codebeispiel einer Activity
Activity - Lebenszyklus
Listing 5.3 – Lebenszyklus einer Activity
package com.example.htchalloworld;
import android.os.Bundle;
import android.app.Activity;
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
}
}
5.2 Allgemeine in Android verwendete Techniken
47
Durch den oben dargestellten Ablauf wird ein optimiertes und performantes
Erzeugen von Activities innerhalb einer Anwendung realisiert. Diese Variante
gewährt einen sparsamen Umgang mit den gegeben Ressourcen, da eine erzeugte
Activity solange wie möglich und solange wie nötig im Speicher gehalten wird und
somit die ressourcenlastige, ständige Erzeugung von Activities größtmöglich
vermieden wird.
5.2.3 Service
Services sind für länger andauernde Tätigkeiten gedacht. Ein Service läuft im
Hintergrund und führt die dem Service zugewiesenen Aufgaben durch. Ein Service
besitzt keine Benutzeroberfläche.
Unter Android gibt es zwei Formen von Services: „Started“- und „Bound“-Service.
Bei einem Started-Service wird der Service von der aufrufenden Anwendung mit dem
Befehl startService() gestartet und läuft im Hintergrund unendlich lange weiter.
Hierbei ist es wichtig, dass eine Anwendung, die beendet werden soll, vorher auch
noch den Service beendet. Der Entwickler ist für die korrekte Beendigung des
Services zuständig. Für gewöhnlich erledigt ein Started-Service eine einzelne
Operation / Aufgabe und liefert keinen Rückgabewert oder Rückantwort zurück. Ein
Service hat die Möglichkeit, sich selbst zu beenden, z.B. wenn er seine Aufgabe
erledigt hat. Ein Beispiel für einen Started-Service wäre ein Download einer Datei.
Nach dem der Download abgeschlossen ist, beendet sich der Service.
Bei einem Bound-Service wird der Service gestartet bzw. „gebunden“, wenn eine
aufrufende Anwendungskomponente bindService() ruft. Der „Client“, der den Service
aufruft, kann dabei ein Teil der Anwendung sein, zu der auch der Service gehört,
aber auch fremde Prozesse dürfen die Funktionen des Service ansprechen. Ein
gebundener Service wird ausgeführt, solange mindestens ein Client mit ihm
verbunden ist. Somit können mehrere Komponenten zur gleichen Zeit an dem
Service gebunden werden. Ist keine einzige Komponente gebunden, so wird der
Service zerstört. Ein Bound-Service bietet eine Client-Server-Schnittstelle, welches
den Anwendungskomponenten eine Interaktion mit dem Service gewährt. Dazu
gehören Anfragen zu senden und Ergebnisse / Rückantworten zurückerhalten.
5.2 Allgemeine in Android verwendete Techniken
48
Ein Service muss in der Manifest-Datei hinterlegt werden.
Listing 5.4 – Service-Deklaration in der Manifest-Datei
In diesem Projekt wird die Bound-Service-Variante mit Hilfe eines Callback-
Mechanismus für die Kommunikation zwischen Client und Service verwendet. Die
Abbildung „Abb. 5.2“ stellt den Vorgang grafisch dar.
ServiceActivity
Runnable
Handler
MessageBinderService-
Connection
Callback
Übergabe per Binder
Abb. 5.2 – Kommunikation zwischen Activity und Service
5.2.4 SQLite
Für die Speicherung und Verwaltung von wiederholenden und strukturierten Daten
eignet sich idealerweise eine Datenbank. Android stellt dem Entwickler bzw. den
Anwendungen ein Datenbankmanagementsystem SQLite zur Verfügung.
Eine Anwendung mit einer Datenbank verwendet eine Java-Klasse als
Datenbankmanager. Android stellt eine abstrakte Klasse SQLiteOpenHelper bereit.
Die Datenbankmanager-Klasse erbt von der abstrakten Klasse und weiß als
Unterklasse, wie sie die Datenbank erzeugt und wie das Datenbankschema aussieht.
<application
android:allowBackup="true"
android:icon="@drawable/ic_launcher"
android:label="@string/app_name"
android:theme="@style/AppTheme" >
...
<service android:name=".ExampleService" />
...
</application>
5.2 Allgemeine in Android verwendete Techniken
49
Der Datenbankmanager beinhaltet mindestens den Namen der Datenbank, die
Datenbankversion und die zwei abstrakten Methoden onCreate() und onUpdate().
Für den Zugriff auf SQLite Datenbanken stehen folgende sechs Operationen bereit:
query, rawQuery, insert, update, delete, execSQL.
Um auf die Ergebnisse von Datenbankanfragen zugreifen zu können, bietet die
Android-API das Konstrukt Cursor. Dabei handelt es sich um einen Zeiger auf einen
Datensatz der Ergebnismenge. Hiermit ist es möglich, innerhalb der Ergebnismenge
vor und zurück zu navigieren, die von einem SELECT-Befehl angefragten
Ergebnisdatensätze auszulesen und die Anzahl der Ergebnisdatensätze zu ermitteln.
Des Weiteren ist der Zugriff auf große Ergebnismengen so optimiert, dass die
SQLiteCursor-Implementierung große Ergebnismengen in Teilmengen, sogenannten
Datenfenstern, Schritt für Schritt einliest. Solch eine Vorgehensweise wird auch
„windowing“ genannt.
public class TestDatenbank extends SQLiteOpenHelper {
public static final int DATABASE_VERSION = 1;
public static final String DATABASE_NAME = "test.db";
private static final String TEXT_TYPE = " TEXT";
private static final String COMMA_SEP = ", ";
public TestDatenbank (Context context) {
super(context, DATABASE_NAME, null, DATABASE_VERSION);
}
@Override
public void onCreate(SQLiteDatabase db) {
db.execSQL("CREATE TABLE ...");
}
@Override
public void onUpgrade(SQLiteDatabase db, int oldVersion,
int newVersion) {
db.execSQL(("DROP TABLE ...");
onCreate(db);
}
}
5.2 Allgemeine in Android verwendete Techniken
50
5.2.5 ContentProvider & ContentResolver
Um einen Zugriff auf Datenbankinhalte und Dateien außerhalb einer Anwendung
auch externen Anwendungen zu gewähren, stellt Android dem Entwickler das
Konzept des ContentProvider und ContentResolver zur Verfügung. Eine Anwendung,
die Dateien oder Datenbankinhalte verwaltet und diese anderen Anwendungen
bereitstellt, nennt man Provider und benötigt die Implementierung der
ContentProvider-Klasse. Die anderen, externen Anwendungen stellen die
Konsumenten dar, die einen Zugriff auf den Inhalt der Daten (Datenbankinhalte oder
Dateien) erhalten möchten und somit ein ContentReselver-Objekt instanziieren/
verwenden müssen.
Zur eindeutigen Identifikation eines ContentProviders werden entsprechende
Stammdaten in der ContentProvider-Klasse eingetragen. Dazu zählen die
„Authority“ des Providers und die URI als Einstiegspunkt der verwalteten Inhalte.
Des Weiteren erfolgt ein Eintrag des ContentProvider und dessen zugehörigen
Zugriffsberechtigungen in der Manifest-Datei.
Listing 5.5 - Beispielcode einer ContentProvider-Implementierung
public class TestContentProvider extends ContentProvider {
public static final String AUTHORITY = "com.example.providers.
testcontentprovider ";
public static final Uri CONTENT_URI = Uri.parse("content://" +
AUTHORITY + "/" + DBColumns.TABLE_NAME);
...
...
@Override
public Cursor query(Uri uri, String[] projection, String selection,
String[] selectionArgs, String sortOrder) {
...
return dbController.queryPasser(getContext(), uri,
DBColumns.TABLE_NAME, inWhere, projection, selection,
selectionArgs, null, null, sortOrder);
}
...
@Override
public int delete(Uri uri, String selection, String[] selectionArgs) {
if(selection == null && selectionArgs == null){
return dbController.deleteAllDataInDatabase();
} else {
String idString = selectionArgs[0];
int id = Integer.valueOf(idString);
return dbController.deleteSelectedDataInDatabase(id);
}
}
}
5.2 Allgemeine in Android verwendete Techniken
51
Listing 5.6 – ContentProvider Eintrag in der AndroidManifest.xml
Für den Datenbankzugriff bietet die Klasse ContentProvider folgende Operationen:
insert(), delete(), update() und query(). Jeder Methode wird mindestens der URI-
Parameter übergeben. Der ContentResolver stellt als Gegenstück die gleichen
Methoden für die externe Anwendung zur Verfügung.
Auch beim Konsumenten erfolgt ein Eintrag der Berechtigungen in der Manifest-
Datei.
Listing 5.7 – Eintrag der Berechtigungen in der Manifestdatei einer externen Anwendung
Ein ContentResolver-Objekt wird innerhalb einer von Context abgeleiteten Klasse
(Activities, Services, etc.) instanziiert und für das Auslesen und Schreiben von Daten
verwendet. Das Listing 5.8 zeigt ein Activity-Beispiel einer externen Anwendung, mit
der die Datenbankinhalte von der Provider-Anwendung gelöscht werden können.
Listing 5.8 – Verwendung des ContentResolver in einer externen Anwendung
...
<provider
android:name=".providers.TestContentProvider"
android:authorities="com.example.providers.testcontentprovider"
android:readPermission="com.example.READ_DATABASE"
android:writePermission="com.example.WRITE_DATABASE" />
...
...
<uses-permission android:name=" com.example.READ_DATABASE " />
<uses-permission android:name=" com.example.WRITE_DATABASE " />
...
public class DeleteDataActivity extends Activity {
public static final String AUTHORITY = "com.example.providers.
testcontentprovider";
public static final String TABLE_NAME = "testTable";
private ContentResolver cr;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_delete_data);
cr = getContentResolver();
}
public void onClickButtonDeleteAllEntries(View view) {
Uri uri = Uri.parse("content://" + AUTHORITY + "/" +
TABLE_NAME);
cr.delete(uri, null, null);
}
}
5.3 Implementierung der ISOBUS-Reader App
52
5.3 Implementierung der ISOBUS-Reader App
In diesem Abschnitt der Masterarbeit werden die relevanten Applikationen und
Masken der ISOBUS-Reader App detailliert erläutert und mit entsprechenden kurzen
Quellcode-Ausschnitten dokumentiert.
Die Implementierung der Anwendung besteht aus vier wesentlichen Teilbereichen:
ISOBUS-Daten Empfang und Berechnung
ISOBUS-Daten Verwaltung mit SQLite
ISOBUS-Daten Bereitstellung für externe Anwendungen
ISOBUS-Adressermittlung und Verwaltung
5.3.1 Grafische Benutzeroberflächen und Ablauf der
Anwendung
Der Startbildschirm ist die erste Activity, die der Benutzer beim Starten der
Anwendung angezeigt bekommt. In dieser wird der Verbindungsaufbau zum CANlink
Bluetooth – Gerät ausgeführt. Dazu klickt der Benutzer auf das Optionsmenü,
welches anschließend in der unteren Ebene als Leiste angezeigt wird. Hierbei sind
drei Einträge zu sehen: „Connect to CANlink Bluetooth“, „Disconnect“ und „Starte
Addressclaiming“. Der Benutzer wählt den Eintrag für den Verbindungsaufbau,
selektiert das CANlink Bluetooth-Geräte aus der erscheinenden Bluetooth-
Geräteliste und bestätigt die Verbindung mit einem vier-stelligen Passwort.
Ist die Verbindung erfolgreich, so wird dies dem Benutzer mit dem Eintrag
„Verbindungsstatus BT Box: verbunden“ bekanntgegeben und in der rechten oberen
Ecke wird der Name des Bluetooth-Geräts, mit dem das Tablet verbunden ist,
angezeigt.
Des Weiteren werden auf der Startseite in der oberen Hälfte Statusinformationen und
die Buttons „Starte Empfang“, „Stoppe Empfang“ „Alle Daten speichern“, „Zeige
Daten“ und „Testmessage senden“ dargestellt. Nach dem eine Verbindung aufgebaut
ist, kann der Benutzer entscheiden, wann er mit der Speicherung der ISOBUS-
Nachrichten starten und stoppen möchte. Möchte der Anwender nicht nur die PGN-
gefilterten Daten, sondern alle eingehenden Nachrichten abspeichern, so klickt er auf
den Button „Alle Daten speichern“.
5.3 Implementierung der ISOBUS-Reader App
53
Die Abbildung „Abb. 5.3“ und die Abbildung „Abb. 5.4“ stellen die Screenshots des
Startbildschirm dar.
Abb. 5.3 – Startbildschirm der ISOBUS Reader Anwendung
Abb. 5.4 – Die Anwendung ist mit dem Bussystem verbunden
Sobald der Anwender den Button „Starte Empfang“ ausführt, werden die Nachrichten
in der unteren Hälfte (unter den Buttons) in einer ListView ausgegeben. Dabei
werden die Daten „fließend“ angezeigt, d.h. die aktuellste Nachricht wird als letzte in
der Liste ganz unten aufgeführt und die Liste scrollt bzw. verschiebt sich automatisch
nach unten. Möchte sich der Benutzer einen Eintrag im Detail anschauen, so kann er
das automatische Scrollen beenden, in dem er die fließende Ausgabe mit einer
Berührung auf die ListView anhält.
5.3 Implementierung der ISOBUS-Reader App
54
Abb. 5.5 – Empfange Nachrichten werden in einer ListView ausgegeben
Ein längeres Drücken auf einen Eintrag öffnet ein Kontextmenü mit der Auswahl
„Details anzeigen“. Wählt der Anwender diesen Eintrag aus, so wird diesem eine
neue Activtiy angezeigt. Auf dieser neuen Anzeige werden die aus der ISOBUS-
Nachricht berechneten Daten (PF, PGU, PGN, DA, GE, SA, EDP, DP) detailliert
aufgezeigt.
Abb. 5.6 – Aufruf des Kontextmenüs zu einem Eintrag
Abb. 5.7 – Detaillierte Ansicht der berechneten Daten zu einer Nachricht
5.3 Implementierung der ISOBUS-Reader App
55
Möchte der Anwender alle Nachrichten speichern, so wählt dieser den Button „Alle
Daten speichern“ aus. Der Button wechselt seine Beschriftung auf „Gefilterte Daten
speichern“ und bietet nun wieder an, nur gefilterte Daten zu speichern.
Abb. 5.8 – Dynamische Darstellung des Buttons „Gefilterte/Alle Daten speichern“
Möchte der Anwender sich einen Überblick über die in der Datenbank gespeicherten
Daten anzeigen lassen, so wählt er auf dem Startbildschirm den Button „Zeige
Daten“ aus. Anschließend wird dem Benutzer eine Übersichtsseite mit den Buttons
„Daten anzeigen“, „Daten löschen“ und „Verwaltung Datenerfassung“ angezeigt. Zum
Anzeigen der Daten wählt der Benutzer „Daten anzeigen“.
Abb. 5.9 – GUI für die Dateneinsicht und Datenverwaltung
Die aufgezeichneten Daten werden in einer ListView in Tabellenform, entsprechend
der eingehenden Reihenfolge sortiert, ausgegeben.
Abb. 5.10 – Ausgabe der erfassten und berechneten Isobusdaten in einer Tabelle
5.3 Implementierung der ISOBUS-Reader App
56
Zum Löschen von Datensätzen wählt der Benutzer den Button „Daten löschen“. Es
wird eine weitere Activity angezeigt, in der der Benutzer die Möglichkeit hat alle
Datensätze oder nur einen bestimmten Datensatz zu löschen.
Abb. 5.11 – Eine Maske zum Löschen von Datensätzen
Um nur gefilterte ISOBUS-Nachriten zu erfassen, muss ein entsprechender Filter
bzw. eine Filtermaske gepflegt werden. Diese Verwaltung wird mit dem Button
„Verwaltung Datenerfassung“ aufgerufen. Die Verwaltungsanzeige bietet die Buttons
„PGN eintragen“, „PGNs anzeigen“ und „PGNs löschen“ zur Auswahl an.
GUI für die Verwaltung von PGN-Filtereinträgen
In der Maske „PGN eintragen“ kann eine neue Parameter Group Number als
Filterkriterium eingetragen werden. Zusätzlich kann noch ein Infotext eingegeben
werden.
Abb. 5.12 – Eine Maske zur Erfassung eines PGN-Filterkriteriums
Beim Aufruf des Buttons „PGNs anzeigen“ werden die verwalteten PGNs ebenfalls in
einer ListView in Tabellenform ausgegeben.
Abb. 5.13 – Anzeige der eintragenen PGN-Filterkriterien
5.3 Implementierung der ISOBUS-Reader App
57
Das Löschen eines oder auch aller PGN-Einträge ist ebenfalls möglich und die
dazugehörige Maske wird mit dem Button „PGNs löschen“ aufgerufen.
Abb. 5.14 – Eine Maske zum Löschen von PGN-Filtereinträgen
5.3 Implementierung der ISOBUS-Reader App
58
5.3.2 ISOBUS-Daten-Empfang und Berechnung
Die Hauptbenutzeroberfläche bzw. die Startseite der ISOBUS-Reader Anwendung
stellt die Activity „ISOBUS_Reader_Main.java“ dar, die auf der von „RM Michaelides
Software & Elektronik GmbH“ Test-Anwendung „RM Bluetooth Demo“ basiert. „RM
Bluetooth Demo“ basiert ebenfalls auf der von Google bereitgestellten Beispiel-
Anwendung „BluetoothChat“.
Die „ISOBUS_Reader_Main“-Klasse kommuniziert mit der „BluetoothCommuncation-
Service"-Klasse, welches mittels eines Callback-Mechanismus realisiert wird. In
Android können Threads eine Nachrichten-Warteschlange „Message Queue“
besitzen, in der Nachrichten in Form von Message- oder Runnable-Objekten enthalten
sein können. Ein Thread kann somit Ereignisse aus vielen Quellen annehmen und
ein Ereignis nach dem anderen abarbeiten. Mittels eines „Handlers“ hat man die
Möglichkeit, Message- oder Runnable-Objekte in die Message Queue eines Threads
zu stellen. Eine Handler wird in derjenigen Komponente definiert, in der eine
Rückmeldung aus der Hintergrundoperation später verarbeitet werden soll. In diesem
Projekt wird der Handler in der Activity „ISOBUS_Reader_Main.java“ implementiert
und der „BluetoothCommunicationService“-Klasse über dessen Konstruktor bekannt
gegeben.
Das Listing 5.9 zeigt einen Ausschnitt aus der „BluetoothCommunicationService“-
Klasse, in der der eingehende Byte-Stream entgegengenommen und an den Handler
weitergereicht wird.
5.3 Implementierung der ISOBUS-Reader App
59
Listing 5.9 – Übergabe einer Nachricht an den Handler
Listing 5.10 zeigt den Handler, der als innere Klasse innerhalb von
„ISOBUS_Reader_Main.java“ implementiert wird und die Rückmeldungen
(messages) in einem Switch-Case-Konstrukt verarbeitet. Dabei wird das Message-
Objekt aus der Nachrichtenschlange entgegengenommen und an die Bluetooth-
messageCommand-Klasse (BmCmd) zur weiteren Verarbeitung übergeben.
Listing 5.10 – Handler verarbeitet die Nachrichten aus der Message Queue
Nach der Verarbeitung der Nachricht in der BmCmd-Klasse wird die Nachricht ein
weiteres Mal dem Handler bereitgestellt. Ab diesem Zeitpunkt erfolgt das Berechnen
der ISOBUS-Daten aus der CANBUS-Nachricht.
...
@Override
public void run() {
byte[] buffer = new byte[1024];
int bytes;
// Keep listening to the InputStream while connected
while (mmStayConnected) {
try {
if (mmInStream != null) {
// Read from the InputStream
bytes = mmInStream.read(buffer);
// Send the obtained bytes to the UI Activity
mHandler.obtainMessage(ISOBUS_Reader_Main.MESSAGE_READ, bytes, -1,
buffer).sendToTarget();
} else {
Log.e(TAG, "InputStream ist NULL. Somit kann darauf nicht gelesen
werden.");
}
} catch (IOException e) {
...
}
}
...
}
private final Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
...
case MESSAGE_READ:
// Parameter 0 ist das Objekt bzw. das Byte-Array und Parameter
// 1 ist die Länge/Anzahl des Byte-Array
mBmCmd.s8RxData((byte[]) msg.obj, msg.arg1);
break;
...
}
}
};
5.3 Implementierung der ISOBUS-Reader App
60
1 Bei der Implementierung des Callback-Mechanismus wurde das Implementierungs-Beispiel aus dem Buch „Android
2“ von Arno Becker und Marcus Pant aus dem Kapitel 8.5 Callback-Mechanismen als Grundlage verwendet.
Eine CANBUS-Nachricht wird in folgender Form bereitgestellt:
RDX; 18FD0226; FF 00 03 FF FF FE 54 00
Der erste Abschnitt gibt Information darüber, um was für eine Nachricht es sich
handelt. Der zweite Abschnitt stellt den CAN-Identifier und der dritte das CAN-Data
dar. Die Information „RDX“ bestimmt mit dem ersten Buchstaben die Feedback-
message-Art. R steht für Received. Der zweite Buchstabe beinhaltet die Information
des Frames. In diesem Fall handelt es sich um ein DataFrame. Der dritte Buchstabe
steht für die Art des Identifier. Weil es sich hierbei um ISOBUS-Nachrichten handelt,
ist es stets ein erweiterter 29-Bit-Identifier. Somit steht das X für Extended.
Die Berechnung der ISOBUS-Daten aus den CANBUS-Nachrichten erfolgt in der
„CalculateISOBUSDataService“-Klasse, welche als Bound-Service implementiert
wird. Der Nachrichtenaustausch erfolgt ebenfalls nach einem Callback-Mecha-
nismus, bei dem ein Handler und ein Runnable-Objekt seitens der Activity und ein
Binder-Objekt seitens des Service implementiert1 werden. Die Abbildung „Abb. 5.15“
soll die Implementierung grafisch verdeutlichen.
ServiceActivity
Runnable
Handler
MessageBinderService-
Connection
Callback
Übergabe per Binder
Abb. 5.15 – Implementierung eines Service mit Callback
5.3 Implementierung der ISOBUS-Reader App
61
Die „CalculateISOBUSDataService“-Klasse beinhaltet einen Binder, der die Methode
calcValueForFlowData() zur Berechnung der Daten bereitstellt. Das Listing 5.11 zeigt
den Aufruf der Methode und die Übergabe des message-Objects innerhalb der
Activity „ISOBUS_Reader_Main.java“.
Listing 5.11 – Callback-Mechanismus: Aufruf der „calcValueForFlowData()“-Methode
mittels des Binders
In der calcValueForFlowData() wird die Dateninformation an eine weitere Methode
„_berechneErgebnis()“ übergeben, die als eigenständiger Thread die Berechnung
durchführt. Anschließend wird dem Runnable-Objekt das Ergebnis der Berechnung
hinzugefügt. Das Runnable-Objekt wird dann mit Hilfe der post-Methode des
Handlers in die Message Queue des Threads gestellt, die der Handler verwaltet.
mRunnable2 selbst ist Teil der Activity und nicht des Service und darf daher auf die
Oberflächen-Komponenten der Activity zugreifen.
private final Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
...
case MESSAGE_DISPLAY:
if (printDataOnGui == true) {
if (mBinder != null) {
mBinder.calcValueForFlowData((String) msg.obj);
} else {
Toast.makeText(getApplicationContext(), "Failure: mBinder not
bound.", Toast.LENGTH_LONG).show();
}
}
break;
...
}
}
};
public class CalculateISOBUSDataService extends Service {
private String canMessageString = null;
private ISOBUS_Reader_Main.MeinRunnable mRunnable2;
private final IBinder mBinder = new MeinBinder();
...
public class MeinBinder extends Binder {
public void setActivityCallbackHandler(final Handler callback) {
mCallbackHandler = callback;
}
public void setRunnable2(final ISOBUS_Reader_Main.MeinRunnable runnable) {
mRunnable2 = runnable;
}
...
public void calcValueForFlowData(String canMessageStringTmp) {
canMessageString = canMessageStringTmp;
(weiterer Code auf der nächsten Seite)
5.3 Implementierung der ISOBUS-Reader App
62
Listing 5.12 – CalculateISOBUSDataSerice: Android-Service zur Berechnung der ISOBUS-
Daten
In der Methode „_berechneErgebnis()“ wird geprüft, ob die „message“ ungleich NULL
ist und anschließend an die „decodeData()“-Methode weitergereicht.
Listing 5.13 – Aufruf der decodeData()-Methode
Nachdem eine Nachricht an die Methode „decodeData()“ übergeben wird, wird diese
Nachricht zunächst einmal mit Hilfe von regulären Ausdrücken überprüft und
anschließend in die Teilstrings für CAN-Identifier und CAN-Data gesplittet. Getrennt
werden die Informationen noch einmal mit regulären Ausdrücken geprüft, ob diese in
Hexadezimaler Form und in der entsprechenden Zeichenlänge für Identifier (8
Zeichen) und Data (16 Zeichen) vorliegen und dann in die Long-Datentypen
überführt. Diese Vorgänge sind sehr trivial, so dass aus Platzgründen kein Code
dazu gezeigt werden soll. Jedoch wird der Code der Berechnung aufgezeigt.
Die Berechnung des Identifiers erfolgt in der Methode calcIsobusId() und die Data-
Informationen in der Methode calcIsobusData().
new Thread() {
public void run() {
if (canMessageString != null) {
_berechneErgebnis(canMessageString);
if (mRunnable2 != null) {
mCallbackHandler.post(mRunnable2);
}
}
}
}.start();
}
}
...
}
private void _berechneErgebnis(String message) {
if (message != null) {
tmpBoolean = decodeData(message);
if (!tmpBoolean) {
Log.e(TAG, "Fehler in der Berechnung. Berechnung wurde für den
fehlerhaften Datensatz abgebrochen.");
}
}
}
5.3 Implementierung der ISOBUS-Reader App
63
Listing 5.14 - decodeData()-Methode in der Identifier und Data berechnet werden
In calcIsobusId() werden die Werte des Identifiers berechnet. Zu den Werten zählen:
Priorität, Extended Data Page (EDP), Data Page (DP), PDU Format (PF), PDU
Specific (PS) und Source Address (SA). Dabei erfolgt die Berechnung sowohl mit
arithmetischen als auch mit bitweisen Operatoren. Das Listing 5.15 zeigt den Code
zur Berechnung der Daten.
Die berechneten Informationen werden in das detailedData-Objekt von der Klasse
„DetailedIsobusDataStructure“, eingetragen.
private boolean decodeData(String messageUntouched) {
...
tmpBoolean = calcIsobusId();
if (tmpBoolean == false) {
Log.e(TAG, "Fehler in der ID-Berchnung.");
return false;
}
tmpBoolean = calcISOBUSData();
if (tmpBoolean == false) {
Log.e(TAG, "Fehler in der Data-Berchnung.");
return false;
}
...
fillStringVariables();
return true;
}
public boolean calcIsobusId() {
// PDU-Format ermitteln
detailedData.pf = (detailedData.canID / 0x10000) & 0x00FF;
if (detailedData.pf <= 239) {
detailedData.pdu = 1;
} else {
detailedData.pdu = 2;
}
// Ermitteln von source address und destination address/group extension
detailedData.sa = detailedData.canID & 0xff;
if (detailedData.pdu == 1) {
detailedData.da = (detailedData.canID & 0xff00) / 0x100;
detailedData.ge = 0;
} else {
detailedData.da = 0;
detailedData.ge = (detailedData.canID & 0xff00) / 0x100;
}
// Ermitteln der PGN
if (detailedData.pdu == 1) {
detailedData.pgn = (detailedData.canID / 0x100) & 0x3ff00;
} else if (detailedData.pdu == 2) {
detailedData.pgn = (detailedData.canID / 0x100) & 0x3ffff;
}
(weiterer Code auf der nächsten Seite)
5.3 Implementierung der ISOBUS-Reader App
64
Listing 5.15 – In calcIsobusId() werden die Werte Priorität, EDP, DP, PF, PS und SA aus
dem Identifer berechnet
Das detailedData-Objekt steht mit Hilfe des Handlers anschließend wieder der
Activity „ISOBUS_Reader_Main.java“ zur Verfügung, welches für die Speicherung in
die SQLite Datenbank verwendet wird.
Zusätzlich zur Abspeicherung wird eine Activity zur detaillierten Anzeige der
berechneten Daten implementiert. Hierbei kann ein einzelner Datensatz mit Hilfe
eines Kontextmenüs die Detailansicht aufrufen.
Abb. 5.16 – Detailansicht einer berechneten ISOBUS-Nachricht
...
// Berechnung von edp und dp
tmpLong = ((detailedData.canID / 0x1000000) & 0x03);
tmpInt = (int) tmpLong;
switch (tmpInt) {
case 0:
detailedData.edp = 0; detailedData.dp = 0;
break;
case 1:
detailedData.edp = 0; detailedData.dp = 1;
break;
case 2:
detailedData.edp = 1; detailedData.dp = 0;
break;
case 3:
detailedData.edp = 1; detailedData.dp = 1;
break;
default:
Log.e(TAG, "Fehler beim Bestimmen der EDP und DP.");
return false;
}
// Berechnung der Priorität
tmpLong = ((detailedData.canID / 0x1000000) & 0x1c);
detailedData.priority = (int) (tmpLong >> 2);
return true;
}
5.3 Implementierung der ISOBUS-Reader App
65
5.3.3 ISOBUS-Daten-Verwaltung mit SQLite
Nachdem eine ISOBUS-Nachricht berechnet ist, wird im nächsten Vorgang die
Sicherung der Daten durchgeführt. Die Datenverwaltung erfolgt dabei parallel zum
Datenempfang und der Datenberechnung.
Der Anwender hat die Möglichkeit, alle empfangenen ISOBUS-Nachrichten in der
Datenbank zu speichern oder nur die ISOBUS-Nachrichten, deren „Parameter Group
Number“ (PGN) im PGN-Nachrichtenfilter enthalten ist. Der PGN-Nachrichtenfilter
stellt aus technischer Sicht eine weitere Datenbanktabelle dar.
In der Activity „ISOBUS_Reader_Main.java“ erfolgt die Implementierung der
Runnable-Klasse als innere Klasse. Diese instanziiert das detailedData-Objekt der
„DetailedIsobusDataStructure“-Klasse und hat Zugriff auf die berechneten Daten.
Listing 5.16 – Aufruf der Speichervorgänge in der „ISOBUS_Reader_Main“-Klasse
public class MeinRunnable implements java.lang.Runnable {
public DetailedIsobusDataStructure detailedData;
List<String> pgnList;
public MeinRunnable() {
pgnList = isoDbController.readPgnDataForFiltering();
}
public void run() {
if (filterActiv) {
saveSelectedDataToDatabase();
} else {
saveAllDataToDatabase();
}
}
private void saveAllDataToDatabase() {
if (detailedData != null) {
isoDbController.insertDataInDatabase(detailedData);
} else {
Log.d(TAG, "Fehler in saveDataToDatabase(). detailedData ist null.");
}
}
private void saveSelectedDataToDatabase() {
if (detailedData != null) {
if (pgnList.contains(String.valueOf(detailedData.pgn))) {
isoDbController.insertDataInDatabase(detailedData);
}
}
}
};
5.3 Implementierung der ISOBUS-Reader App
66
Sowohl in der saveSelectedDataToDatabase()- als auch in der saveAllDataTo
Database()-Methode wird zum Speichern der Nachricht die Methode insertDataIn
Database(detailedData) ausgeführt. Sollen nur die in der PGN-Liste eingetragen
Nachrichten mit entsprechender PGN gespeichert werden, so wird zuvor die gerade
empfangene und berechnete PNG Nummer mit der PGN-Liste verglichen und ein
Speichern der Nachricht wird gewährt oder die Nachricht verworfen.
Die Speicherung und Verwaltung der ISOBUS-Nachrichten wird im package
„farmpilot.datenerfassung“ implementiert. Das Package beinhaltet folgende Klassen:
„IsobusData.java“, „IsobusDbContract.java“, „IsobusDbHelper.java“ und „IsobusDb
Controller.java“.
Die Klasse „IsobusDbContract“ beinhaltet das Datenbank-Schema (Tabellenname
und Spaltennamen) für die zwei entscheidenden Tabellen: „IsobusDataTable“ und
„PgnDataTable“. Diese werden als innere Contract-Klassen implementiert.
Listing 5.17 – Implementierung des Datenbankschemas in der IsobusDbContract-Klasse
public class IsobusDbContract {
// To prevent someone from accidentally instantiating the contract class,
// give it an empty constructor.
public IsobusDbContract() {
}
/*
* Inner class that defines the table contents.
* http://developer.android.com/training/basics/data-storage/databases.html
*/
public static abstract class DBColumns implements BaseColumns {
public static final String TABLE_NAME = "IsobusDataTable";
public static final String COLUMN_NAME_CAN_ID = "canid";
public static final String COLUMN_NAME_CAN_DATA = "candata";
public static final String COLUMN_NAME_PGN = "pgn";
public static final String COLUMN_NAME_INFOTEXT = "infotext";
public static final String COLUMN_NAME_TIMESTAMP = "timestamp";
// Bytes gelesen von links nach rechts: Byte1 ... Byte8
public static final String COLUMN_NAME_BYTE1 = "byte1";
public static final String COLUMN_NAME_BYTE2 = "byte2";
public static final String COLUMN_NAME_BYTE3 = "byte3";
public static final String COLUMN_NAME_BYTE4 = "byte4";
public static final String COLUMN_NAME_BYTE5 = "byte5";
public static final String COLUMN_NAME_BYTE6 = "byte6";
public static final String COLUMN_NAME_BYTE7 = "byte7";
public static final String COLUMN_NAME_BYTE8 = "byte8";
}
public static abstract class DbPgnColumns implements BaseColumns {
public static final String TABLE_NAME = "PgnDataTable";
public static final String COLUMN_NAME_PGN = "pgn";
public static final String COLUMN_NAME_INFOTEXT = "infotext";
}
}
5.3 Implementierung der ISOBUS-Reader App
67
Die Klasse „IsobusDbHelper.java“ erbt von der abstrakten Klasse SQliteOpenHelper
und ist zuständig für das Erstellen der eigentlichen Datenbank, den
Datenbanktabellen und den entsprechenden Attributen für die jeweilige Tabelle. In
der Klasse wird der Datenbankname als auch die Datenbankversionsnummer
festgehalten. Das Erzeugen der Datenbank erfolgt in der onCreate()- und das
Updaten (löschen und anschließend neu erzeugen) in der onUpgrade()-Methode.
Die SQLite-Anweisungen werden als vorbereitete Anweisungen (prepared
Statements) realisiert, um SQL-Injection-Angriffe zu verhindern.
public class IsobusDbHelper extends SQLiteOpenHelper {
public static final int DATABASE_VERSION = 1;
public static final String DATABASE_NAME = "CANBUS_Datenbank.db";
private static final String TEXT_TYPE = " TEXT";
private static final String COMMA_SEP = ", ";
/***********************************************************************
* candata-Table Bereich
***********************************************************************/
private static final String SQL_CREATE_ENTRIES =
"CREATE TABLE IF NOT EXISTS " + DBColumns.TABLE_NAME + " (" +
DBColumns._ID + " INTEGER PRIMARY KEY AUTOINCREMENT, " +
DBColumns.COLUMN_NAME_CAN_ID + TEXT_TYPE + COMMA_SEP +
DBColumns.COLUMN_NAME_CAN_DATA + TEXT_TYPE + COMMA_SEP +
DBColumns.COLUMN_NAME_PGN + TEXT_TYPE + COMMA_SEP +
DBColumns.COLUMN_NAME_INFOTEXT + TEXT_TYPE + COMMA_SEP +
DBColumns.COLUMN_NAME_TIMESTAMP + TEXT_TYPE + COMMA_SEP +
DBColumns.COLUMN_NAME_BYTE1 + TEXT_TYPE + COMMA_SEP +
DBColumns.COLUMN_NAME_BYTE2 + TEXT_TYPE + COMMA_SEP +
DBColumns.COLUMN_NAME_BYTE3 + TEXT_TYPE + COMMA_SEP +
DBColumns.COLUMN_NAME_BYTE4 + TEXT_TYPE + COMMA_SEP +
DBColumns.COLUMN_NAME_BYTE5 + TEXT_TYPE + COMMA_SEP +
DBColumns.COLUMN_NAME_BYTE6 + TEXT_TYPE + COMMA_SEP +
DBColumns.COLUMN_NAME_BYTE7 + TEXT_TYPE + COMMA_SEP +
DBColumns.COLUMN_NAME_BYTE8 + TEXT_TYPE + " );";
private static final String SQL_DELETE_ENTRIES = "DROP TABLE IF EXISTS " +
DBColumns.TABLE_NAME;
public static final String[] ALL_COLUMNS = new String[] {
DBColumns._ID, DBColumns.COLUMN_NAME_CAN_ID, DBColumns.COLUMN_NAME_CAN_DATA,
DBColumns.COLUMN_NAME_PGN, DBColumns.COLUMN_NAME_INFOTEXT,
DBColumns.COLUMN_NAME_TIMESTAMP
};
public static final String[] ALL_COLUMNS_WITH_BYTES = new String[] {
DBColumns._ID, DBColumns.COLUMN_NAME_CAN_ID, DBColumns.COLUMN_NAME_CAN_DATA,
DBColumns.COLUMN_NAME_PGN, DBColumns.COLUMN_NAME_INFOTEXT, DBColumns.
COLUMN_NAME_TIMESTAMP, DBColumns.COLUMN_NAME_BYTE1, DBColumns.
COLUMN_NAME_BYTE2, DBColumns.COLUMN_NAME_BYTE3, DBColumns.COLUMN_NAME_BYTE4,
DBColumns.COLUMN_NAME_BYTE5, DBColumns.COLUMN_NAME_BYTE6, DBColumns.
COLUMN_NAME_BYTE7, DBColumns.COLUMN_NAME_BYTE8
};
(weiterer Code auf der nächsten Seite)
5.3 Implementierung der ISOBUS-Reader App
68
Listing 5.18 – Implementierung der IsobusDbHelper-Klasse die für die Erzeugung der
Datenbank zuständig ist
Für das Speichern und Löschen von Datenbankinhalten ist die Klasse „IsobusDb-
Controller“ verantwortlich. Diese verwaltet sowohl die insert- und delete-Anweisungen
als auch die Ausgabe der Daten mit Hilfe des SQliteCursor Konzepts. Weil die
Klasse „IsobusDBController“ von der Codemenge umfangreich ist, sollen die
nachfolgenden Listings nur die relevanten Funktionen aufzeigen. Die relevanten
Funktionen werden hier zunächst einmal aufgezählt. Die meisten Methodennamen
sind selbstsprechend:
openDbWithReadPermission(), openDbWithWriteAndReadPermission(), closeDB(),
insertDataInDatabase(), insertPgnDataInDatabase(), deleteAllDataInDatabase(),
deleteSelectedDataInDatabase(), readDataFromDatabase(), readPgnFilterFromData-
base().
Das Listing 5.19 zeigt den grundsätzlichen Aufbau der „IsobusDBController“-Klasse
und die Methoden für den Verbindungsaufbau und –abbau zur Datenbank. Der Ver-
bindungsaufbau kann sowohl in „Nur-Lese-Form“ oder in „Lese-Schreib-Form“ erfol-
gen. „IsobusDbController“ implementiert die „SQliteDatabase“-Klasse für die grund-
/***********************************************************************
* pgn-table Bereich
***********************************************************************/
private static final String SQL_CREATE_PGN_ENTRIES =
"CREATE TABLE " + DbPgnColumns.TABLE_NAME + " (" +
DbPgnColumns._ID + " INTEGER PRIMARY KEY AUTOINCREMENT, " +
DbPgnColumns.COLUMN_NAME_PGN + TEXT_TYPE + COMMA_SEP +
DbPgnColumns.COLUMN_NAME_INFOTEXT + TEXT_TYPE + " );";
private static final String SQL_DELETE_PGN_ENTRIES = "DROP TABLE IF EXISTS " +
DbPgnColumns.TABLE_NAME;
public static final String[] ALL_PGN_COLUMNS = new String[] {
DbPgnColumns._ID, DbPgnColumns.COLUMN_NAME_PGN, DbPgnColumns.
COLUMN_NAME_INFOTEXT};
public IsobusDbHelper(Context context) {
super(context, DATABASE_NAME, null, DATABASE_VERSION);
}
@Override
public void onCreate(SQLiteDatabase db) {
db.execSQL(SQL_CREATE_ENTRIES);
db.execSQL(SQL_CREATE_PGN_ENTRIES);
}
@Override
public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
db.execSQL(SQL_DELETE_ENTRIES);
db.execSQL(SQL_DELETE_PGN_ENTRIES);
onCreate(db);
}
}
5.3 Implementierung der ISOBUS-Reader App
69
sätzliche Datenbank und das Datenbankschema mit der Klasse „IsobusDbHelper“.
Listing 5.19 – Grundsätzlicher Aufbau der „IsobusDbController“-Klasse und der
Verbindungsaufbau und –abbau zur Datenbank
public class IsobusDbController {
private static final String TAG = IsobusDbController.class.getSimpleName();
private IsobusDbHelper mDbHelper;
private SQLiteDatabase db;
private String canId, canIdStringHex, canData, pgn, infotext, timestamp;
private String byte1String, byte2String, byte3String, byte4String,
byte5String, byte6String, byte7String, byte8String;
...
private IsobusData pData;
public IsobusDbController(Context context) {
mDbHelper = new IsobusDbHelper(context);
}
...
/***********************************************************
* Öffnet eine Datenbankverbindung mit Lese-Rechten.
**********************************************************/
public void openDbWithReadPermission() throws SQLException {
if (db == null) {
db = mDbHelper.getReadableDatabase();
Log.d(TAG, db was null.");
} else {
if (db.isOpen() == false) {
db = mDbHelper.getReadableDatabase();
Log.d(TAG, db is not null but was closed. db is open now.");
} else {
Log.d(TAG, db is still open.");
}
}
}
/*****************************************************************
* Öffnet eine Datenbankverbindung mit Schreib- und Leserechten.
******************************************************************/
public void openDbWithWriteAndReadPermission() throws SQLException {
if (db == null) {
db = mDbHelper. getWritableDatabase ();
Log.d(TAG, db was null.");
} else {
if (db.isOpen() == false) {
db = mDbHelper. getWritableDatabase ();
Log.d(TAG, db is not null but was closed. db is open now.");
} else {
Log.d(TAG, db is still open.");
}
}
}
/******************************************************************
* Schliesst eine offene Datenbank
*****************************************************************/
public void closeDB() {
if (mDbHelper != null) {
mDbHelper.close();
Log.d(TAG, "closeDB() was called. Datenbank wird geschlossen.");
}
}
}
5.3 Implementierung der ISOBUS-Reader App
70
Zur Speicherung der ISOBUS-Daten in die Datenbank werden die entsprechenden
Daten aus dem detailedData-Objekt ausgelesen und in das values-Objekt von der
Klasse „ContentValues“ eingefügt. Anschließend wird der komplette Datensatz mit
Hilfe der insert()-Operation in die Datenbank eingetragen.
Listing 5.20 – Speichern der ISOBUS-Daten in die Datenbank mit Hilfe des insert-Befehls
Die insertPgnDataInDatabase()-Methode ist für das Speichern der PGN-Filter-Daten
zuständig und ist von der Funktionalität ähnlich aufgebaut wie die insertDataInData
base()-Methode. Es wird zuvor noch in checkPgnIfAlredyInDb() geprüft, ob der zu
speichernde PGN-Filter-Datensatz bereits in der Datenbank enthalten ist. Die
Vorgänge werden in Listing 5.21 aufgezeigt.
public long insertDataInDatabase(DetailedIsobusDataStructure detailedData) {
canId = String.valueOf(detailedData.canID);
canIdStringHex = detailedData.idHexString;
canData = detailedData.dataHexString;
pgn = String.valueOf(detailedData.pgn);
byte1String = detailedData.byte1;
byte2String = detailedData.byte2;
byte3String = detailedData.byte3;
byte4String = detailedData.byte4;
byte5String = detailedData.byte5;
byte6String = detailedData.byte6;
byte7String = detailedData.byte7;
byte8String = detailedData.byte8;
return insertDataInDatabase();
}
/************************************************
* Daten in Datenbank einfügen
************************************************/
private long insertDataInDatabase() {
openDbWithWriteAndReadPermission();
timestamp = sdf.format(new Date());
// Create a new map of values, where column names are the keys
ContentValues values = new ContentValues();
values.put(DBColumns.COLUMN_NAME_CAN_ID, canIdStringHex);
values.put(DBColumns.COLUMN_NAME_CAN_DATA, canData);
values.put(DBColumns.COLUMN_NAME_PGN, pgn);
values.put(DBColumns.COLUMN_NAME_INFOTEXT, infotext);
values.put(DBColumns.COLUMN_NAME_TIMESTAMP, timestamp);
values.put(DBColumns.COLUMN_NAME_BYTE1, byte1String);
values.put(DBColumns.COLUMN_NAME_BYTE2, byte2String);
values.put(DBColumns.COLUMN_NAME_BYTE3, byte3String);
values.put(DBColumns.COLUMN_NAME_BYTE4, byte4String);
values.put(DBColumns.COLUMN_NAME_BYTE5, byte5String);
values.put(DBColumns.COLUMN_NAME_BYTE6, byte6String);
values.put(DBColumns.COLUMN_NAME_BYTE7, byte7String);
values.put(DBColumns.COLUMN_NAME_BYTE8, byte8String);
newRowId = db.insert(DBColumns.TABLE_NAME, null, values);
return newRowId;
}
5.3 Implementierung der ISOBUS-Reader App
71
Listing 5.21 – Speichern der PGN-Filter-Daten in die Datenbank
Um die in der Datenbank gespeicherten Daten wieder löschen zu können, stehen
zwei Methoden (deleteAllDataInDatabase() und deleteSelectedDataInDatabase()) in der
„IsobusDbController“-Klasse zur Verfügung. Die beiden Methoden unterscheiden
sich darin, dass die erste Methode alle ISOBUS-Datensätze in der Tabelle löscht, die
zweite Methode hingegen nur einen einzelnen Datensatz mit entsprechender SQL-ID
(_id) aus der Tabelle löscht. Das nachfolgende Listing 5.22 beschreibt diese
Vorgänge.
public long insertPgnDataInDatabase(int pgnTmp, String infotextTmp) {
openDbWithWriteAndReadPermission();
if (checkPgnIfAlredyInDb(pgnTmp)) {
Log.d(TAG, "PGN ist bereits in PGN-Tabelle enthalten und wird somit nicht
nochmal abgespeichert.");
closeDB();
return -2;
} else {
ContentValues values = new ContentValues();
values.put(DbPgnColumns.COLUMN_NAME_PGN, pgnTmp);
values.put(DbPgnColumns.COLUMN_NAME_INFOTEXT, infotextTmp);
newRowId = db.insert(DbPgnColumns.TABLE_NAME, null, values);
closeDB();
return newRowId;
}
}
private boolean checkPgnIfAlredyInDb(int pgnTmp) throws SQLException {
int count = -1;
String pgnTmpString = String.valueOf(pgnTmp);
String[] pgnTmpStringArray = { pgnTmpString };
Cursor c = null;
try {
String query = "SELECT COUNT(*) FROM " + DbPgnColumns.TABLE_NAME +
" WHERE " + DbPgnColumns.COLUMN_NAME_PGN + " = ?";
c = db.rawQuery(query, pgnTmpStringArray);
if (c.moveToFirst()) {
count = c.getInt(0);
}
if (count > 0) {
return true;
}
} finally {
if (c != null) {
c.close();
}
}
return false;
}
5.3 Implementierung der ISOBUS-Reader App
72
Listing 5.22 – Löschen aller oder einzelner ISOBUS-Datensätze aus der Datenbank
Die Methoden deleteAllPgnDataInDatabase() und deleteSelectedPgnDataInDatabase()
sind von der Funktionalität identisch zu ihren namensähnlichen Methoden
deleteAllDataInDatabase() und deleteSelectedDataInDatabase(), hierbei werden nicht
die ISOBUS-Daten, sondern die PGN-Filter-Daten in der Datenbank gelöscht. Weil
die jeweiligen Codefragmente sich stark ähneln, soll der Code der Methoden
deleteAllPgnDataInDatabase() und deleteSelectedPgnDataInDatabase() nicht weiter
aufgeführt werden.
Das nachfolgende Listing 5.23 beschreibt in der readDataFromDatabase()-Methode
das Auslesen der ISOBUS-Daten aus der Datenbank mit Hilfe des Cursor-
Konstrukts. Es wird dabei zuvor eine db.query()-Operation mit den entsprechenden
Selektionsparametern ausgeführt und an das Cursor-Objekt übergeben.
Anschließend wird innerhalb des Cursor-Objekts mit einer while-Schleife zeilenweise
ein Datensatz ausgelesen und in die ArrayList canDataList gespeichert.
public int deleteAllDataInDatabase() {
try {
Log.d(TAG,"deleteAllDataInDatabase() call: --->");
openDbWithWriteAndReadPermission();
valueOfDeletedEntries = db.delete(DBColumns.TABLE_NAME, null, null);
} catch (SQLiteException e) {
Log.e(TAG, "deleteSelectedDataInDatabase()", e);
return -1;
} finally {
closeDB();
}
return valueOfDeletedEntries;
}
/************************************************
* ausgewählten Datensatz aus Datenbank löschen
************************************************/
public int deleteSelectedDataInDatabase(int id) {
try {
openDbWithWriteAndReadPermission();
String selection = DBColumns._ID + " LIKE ?";
// Specify arguments in placeholder order.
String[] selectionArgs = { String.valueOf(id) };
valueOfDeletedEntries = db.delete(DBColumns.TABLE_NAME, selection,
selectionArgs);
} catch (SQLiteException e) {
Log.e(TAG, "deleteSelectedDataInDatabase()", e);
return -1;
} finally {
closeDB();
}
return valueOfDeletedEntries;
}
5.3 Implementierung der ISOBUS-Reader App
73
Listing 5.23 – Auslesen von ISOBUS-Daten aus der Datenbank
Die Methode readPgnFilterFromDatabase() ist von der Funktionalität identisch zur
readDataFromDatabase()-Methode, hierbei werden nicht die ISOBUS-Daten, sondern
die PGN-Filter-Daten gelesen. Weil beide Codefragmente sich stark ähneln, soll der
Code der readPgnFilterFromDatabase()-Methode nicht weiter aufgeführt werden.
In der Methode readDataFromDatabase() erfolgt in der while-Schleife ein Aufruf einer
weiteren Methode cursorToIsobusData(), welches dem Cursor übergeben wird.
Innerhalb dieser Methode werden die einzelnen Attribute pro Datensatz durch die
Angabe des Spaltennamens aus dem Dateninhalt des Cursors ausgelesen und
entsprechend in das IsobusData-Objekt pData eingetragen. Die Methode
cursorToIsobusData() wird im nachfolgenden Listing 5.24 aufgezeigt.
/************************************************
* Daten aus Datenbank auslesen
************************************************/
public List<IsobusData> readDataFromDatabase() {
List<IsobusData> canDataList = new ArrayList<IsobusData>();
openDbWithReadPermission();
String[] projection = IsobusDbHelper.ALL_COLUMNS;
String selection = null;
String[] selectionArgs = null;
String sortOrder = null;
Cursor cursor = db.query(DBColumns.TABLE_NAME, // Anfragende Tabelle
projection, // Spalten für Rückgabe
selection, // Spalten für die WHERE Bedingung
selectionArgs, // Werte für die WHERE Bedingung
null, // Gruppierung (nicht benötigt)
null, // Filter für Gruppierung
sortOrder // Sortierverhalten
);
cursor.moveToFirst();
while (!cursor.isAfterLast()) {
IsobusData data1 = cursorToIsobusData(cursor);
canDataList.add(data1);
cursor.moveToNext();
}
cursor.close();
closeDB();
return canDataList;
}
5.3 Implementierung der ISOBUS-Reader App
74
Listing 5.24 – Auslesen der Einzelnen Spaltenwerte aus dem Cursor-Datensatz
Die Methode cursorToIsobusDataPgn() ist von der Funktionalität identisch zur
cursorToIsobusData() Methode, hierbei werden nicht die ISOBUS-Daten, sondern die
PGN-Filter-Daten aus dem Cursor gelesen. Weil beide Codefragmente sich stark
ähneln, soll der Code der cursorToIsobusDataPgn() Methode nicht weiter aufgeführt
werden.
/************************************************************************
* Es werden die vom Cursor ausgelesenen Daten in das Objekt IsobusData
* "gepeichert" und zurück gegeben.
************************************************************************/
private IsobusData cursorToIsobusData(Cursor cursor) {
pData = new IsobusData();
pData.idSql = cursor.getInt(cursor.getColumnIndex(DBColumns._ID));
pData.canIdStringHexSql = cursor.getString(cursor.getColumnIndex(
DBColumns.COLUMN_NAME_CAN_ID));
pData.canDataStringSql = cursor.getString(cursor.getColumnIndex(
DBColumns.COLUMN_NAME_CAN_DATA));
pData.pgnSql = cursor.getInt(cursor.getColumnIndex(
DBColumns.COLUMN_NAME_PGN));
pData.infoTextSql = cursor.getString(cursor.getColumnIndex(
DBColumns.COLUMN_NAME_INFOTEXT));
pData.timestampStringSql = cursor.getString(cursor.getColumnIndex(
DBColumns.COLUMN_NAME_TIMESTAMP));
return pData;
}
5.3 Implementierung der ISOBUS-Reader App
75
5.3.4 ISOBUS-Daten-Bereitstellung für externe
Anwendungen
In Kapitel 5.2.5 „ContentProvider & ContentResolver“ wird das Prinzip der
Bereitstellung von Datenbankinhalten für externe Anwendungen anhand eines
Beispiels kurz erläutert. In diesem Abschnitt wird die Implementierung des
„ContentProviders“ in der Klasse „IsobusdataContentProvider“ für die Bereitstellung
der ISOBUS-Daten aufgezeigt. Für den ContentProvider wird ein dbController-Objekt
der bereits bekannten Klasse IsobusDbController bereitgestellt.
Sowohl die query- als auch die delete-Methode erhalten die relevanten Anfrage- bzw.
Löschanweisungs-Paramater von einer externen Anwendung und übergeben diese
an die entsprechende Methode des dbController-Objekts. Im Falle einer Anfrage
(query) liefert der ContentProvider die ISOBUS-Datensätze als Cursor-Objekt an die
externe Anwendung zurück. Bei der delete-Operation wird ein Integer-Wert für die
Anzahl der gelöschten Datensätze als Rückgabewert übergeben. Für das Löschen
der Datensätze stehen auch hier die zwei Methoden deleteAllDataInDatabase() und
deleteSelectedDataInDatabase() zur Verfügung, mit denen das Löschen aller
Datensätze oder eines einzelnen Datensatzes ermöglicht wird.
public class IsobusdataContentProvider extends ContentProvider {
public static final String AUTHORITY = "farmpilot.services.
CandataContentProvider";
public static final Uri CONTENT_URI = Uri.parse("content://" + AUTHORITY +
"/" + DBColumns.TABLE_NAME);
private IsobusDbController dbController;
@Override
public boolean onCreate() {
dbController = new IsobusDbController(getContext());
return true;
}
/***********************************************************************
* Es wird der Query verarbeitet, der von ausserhalb als Anfrage eingeht.
***********************************************************************/
@Override
public Cursor query(Uri uri, String[] projection, String selection,
String[] selectionArgs, String sortOrder) {
return dbController.queryPasser(getContext(), uri, DBColumns.TABLE_NAME,
null, projection, selection, selectionArgs, null, null, sortOrder);
}
(weiterer Code auf der nächsten Seite)
5.3 Implementierung der ISOBUS-Reader App
76
Listing 5.25 – IsobusdataContentProvider zur Bereitstellung der Datenbank für externe
Anwendungen
Zu beachten ist auch, dass der Eintrag des ContentProviders in der Android-
Manifest.xml durchgeführt wird.
Listing 5.26 - ContentProvider Eintrag in der AndroidManifest.xml
Für die Anfrage von ISOBUS-Daten wird in der queryPasser()-Methode eine von
Android bereitgestellte Hilfsklasse „SQLiteQueryBuilder“ verwendet. Mit dieser
Hilfsklasse kann eine Datenbankanfrage Schritt für Schritt „zusammengebaut“ und
anschließend der Anfrage-Befehl sqlBuilder.querry() ausgeführt werden.
Listing 5.27 – Datenanfrage mit Hilfe des SQLiteQueryBuilder Konzepts
...
/***********************************************************************
* Es wird die delete-Anweisung verarbeitet, die von ausserhalb eingeht.
***********************************************************************/
@Override
public int delete(Uri uri, String selection, String[] selectionArgs) {
if (selection == null && selectionArgs == null) {
return dbController.deleteAllDataInDatabase();
} else {
String idString = selectionArgs[0];
int id = Integer.valueOf(idString);
return dbController.deleteSelectedDataInDatabase(id);
}
}
}
...
<provider
android:name="farmpilot.services.IsobusdataContentProvider"
android:authorities=" farmpilot.services.IsobusdataContentProvider"
android:readPermission=" farmpilot.services.READ_DATABASE "
android:writePermission=" farmpilot.services.WRITE_DATABASE " /> ...
public Cursor queryPasser(Context context, Uri uri, String inTables,
CharSequence inWhere, String[] projectionIn, String selection,
String[] selectionArgs, String groupBy, String having, String sortOrder) {
openDbWithWriteAndReadPermission();
SQLiteQueryBuilder sqlBuilder = new SQLiteQueryBuilder();
sqlBuilder.setTables(inTables);
if (inWhere != null) {
sqlBuilder.appendWhere(inWhere);
}
if (db != null) {
Cursor c = sqlBuilder.query(db, projectionIn, selection, selectionArgs,
groupBy, having, sortOrder);
c.setNotificationUri(context.getContentResolver(), uri);
return c;
} else {
Log.d(TAG, "db == null.");
}
return null;
}
5.3 Implementierung der ISOBUS-Reader App
77
Eine Verwendung des ContentResolvers in einer externen Anwendung wird
beispielhaft bereits in Kapitel 5.2.5 „ContentProvider & ContentResolver“ aufgezeigt,
so dass eine weitere Erläuterung des Codefragments an dieser Stelle nicht mehr
notwendig ist.
5.3 Implementierung der ISOBUS-Reader App
78
5.3.5 ISOBUS-Adressermittlung und Verwaltung
In Kapitel 4.4.5 „Adressermittlung“ wird die Notwendigkeit der Ermittlung und Ver-
waltung einer für das Android-Tablet eindeutig festgelegten ISOBUS-Adresse
(Source Address) aufgezeigt und erläutert. In diesem Abschnitt erfolgt die
Erläuterung der Implementierung anhand der entsprechenden Codefragmente, die in
den nachfolgenden Listings aufgezeigt werden.
Der Aufruf zum Starten des AddressClaiming-Prozesses wird in der Hauptbenutzer-
oberfläche innerhalb des Optionsmenüs ausgewählt. Dies führt dazu, dass die
claimingAddressProcess()-Methode in der „ISOBUS_Reader_Main“-Klasse ausgeführt
wird. Es wird geprüft, ob eine Bluetooth-Verbindung besteht, um den Adress-
Claiming-Prozess überhaupt ausführen zu können.
Wie bereits erwähnt, wird in der Implementierung eine Adressverwaltungsliste (auch
Adressbuch genannt) benötigt, um einen Überblick der am ISOBUS teilnehmenden
Geräte zu erfahren und eine eigene Source Address zu ermitteln. Zur Ermittlung der
Teilnehmeradresse wird nach ISO 11783-5 die Broadcast-Nachricht „Request for
Address Claimend“ an das Bussystem versendet und die Teilnehmer melden sich mit
einer „Address Claim“-Nachricht mit ihrer entsprechenden Source Address zurück.
Das Versenden der Broadcast-Nachricht erfolgt in sendeBroadcast()-Methode der
Addressclaiming-Klasse. Laut der ISO-Norm hat die Broadcast-Nachricht folgenden
Aufbau: 0x18EAFFFE (Identifier) und 0x00EE00 (Data).
Der Methodenaufruf findet in der claimingAddressProcess()-Methode statt. Es wird
dem Android-Tablet zunächst eine voreingestellte Source Address (Wert 0xF7)
zugewiesen. Dieser Wert ist jedoch nur ein Default-Wert und kann sich während der
Kommunikation ändern, wenn festgestellt wird, dass diese Source Adress bereits
statisch an ein anderes Gerät vergeben ist. Nach dem die Broadcast-Nachricht
generiert wird, wird diese an das mBmCmd-Objekt der BluetoothmessageCommand-
Klasse (BmCmd) zum Versenden weitergereicht.
Das Listing 5.28 zeigt den Aufruf und Ablauf der claimingAddressProcess()-Methode.
5.3 Implementierung der ISOBUS-Reader App
79
Listing 5.28 – Aufruf des Address Claiming Vorgangs
In der Addressclaiming-Klasse werden folge Methoden aufgezeigt:
sendeBroadcast(), startAddressClaiming(), teilnehmerArry(), eigeneTeilnehmeradres
seErmitteln()
In der sendeBroadCast()-Methode erfolgt die Generierung der Broadcast-Nachricht
und die startAddressClaiming()-Methode wird im laufenden ISOBUS-System zur
Überprüfung und Bekanntgabe der eigenen Source Adresse auf dem Bussystem
benötigt.
In der teilnehmerArray()-Methode erfolgt das Kontrollieren eines übergebenen
Nachrichten-Identifier auf dessen Source Adresse. Es wird dabei geprüft, ob die
Source Adresse in der Adressverwaltungsliste bereits enthalten ist. Ist dies nicht der
Fall, so wird in der „ByteCommandCallbacksImpl.java“-Klasse ein Eintrag der
Adresse in das Adressbuch durchgeführt. (Das später folgende Listing 5.32 zeigt das
Codefragment auf).
Die Methode eigeneTeilnehmeradresseErmitteln() ist für die Ermittlung der eigenen
Source Address zuständig. Vorzugsweise soll die Adresse F7 dem Tablet
zugewiesen werden. Ist diese Adresse bereits, belegt so erhält das Tablet eine
nächst freie Adresse. Bei der Suche einer freien Adresse wird mit der Source
Address 1 begonnen. Es wird mit dem Adressbuch verglichen bzw. geprüft, ob diese
ebenfalls bereits vergeben ist. Ist dies der Fall, so wird die Adresse stets um eine 1
inkrementiert und wieder verglichen. Dieser Vorgang wird solange durchgeführt, bis
eine freie Adresse ermittelt wird.
private boolean claimingAddressProcess() {
if (mitBtBoxVerbunden == true) {
mBmCmd.SendBmFrame(addc.sendeBroadcast());
addc.eigeneISOBUSadresse = (byte) 0xF7;
addclGestartet = true;
bCmdCbImpl.addclGestartet = addclGestartet;
return true;
} else {
Toast.makeText(this, "Keine BT Box Verbindung! Bitte Connect to CANlink
Bluetooth durchführen.", Toast.LENGTH_LONG).show();
}
addclGestartet = false;
bCmdCbImpl.addclGestartet = addclGestartet;
return false;
}
5.3 Implementierung der ISOBUS-Reader App
80
Listing 5.29 – Adressclaiming – Klasse für die Prüfung des Adressbuchs und zur
Ermittlung der eigenen ISOBUS-Adresse
Im vorherigen Listing 5.29 wird die generateBroadcastmessage()-Methode der Klasse
„BmcCanMessage“ in der Methode sendeBroadcast() aufgeführt. Dieses Code-
fragment wird im nachfolgenden Listing 5.30 detailliert aufgezeigt.
public class Addressclaiming {
public int[] teilnehmerInt = new int[254];
public int summeMaxTeilnehmer = 254;
public int eigeneISOBUSadresse = 0;
private int z = 1; // Zähler
public BmcCanMessage sendeBroadcast() {
BmcCanMessage brme = new BmcCanMessage();
brme.extendedIdentifier = true;
brme.generateBroadcastmessage();
return brme;
}
public BmcCanMessage startAddressClaiming(int[] teilnehmerarray, int
anzahlteilnehmer, boolean F7vergeben) {
BmcCanMessage addcl = new BmcCanMessage();
addcl.extendedIdentifier = true;
addcl.identifier = eigeneTeilnehmeradresseErmitteln(teilnehmerarray,
anzahlteilnehmer, F7vergeben);
addcl.addressClaimingMessage(eigeneTeilnehmeradresseErmitteln(
teilnehmerarray, anzahlteilnehmer, F7vergeben), F7vergeben);
return addcl;
}
public boolean teilnehmerArry(int identifier, int[] teilnehmerarray,
int anzahlteilnehmer) {
int i = 0;
while (identifier != teilnehmerarray[i] && i <= anzahlteilnehmer){
i++;
}
if (identifier == teilnehmerarray[i] || identifier == 0xFE){
return false;
} else {
return true;
}
}
private byte eigeneTeilnehmeradresseErmitteln(int[] teilnehmerarray,
int anzahlteilnehmer, boolean F7vergeben) {
if (F7vergeben == true) {
int i = 1;
while (z <= anzahlteilnehmer) {
while (i <= anzahlteilnehmer && teilnehmerarray[i] != z) {
if (i == anzahlteilnehmer) {
return (byte) z;
}
i++;
}
i = 1;
z++;
}
} else if (F7vergeben == false) {
return (byte) (0xF7);
}
return (byte) (0xFF);
}
}
5.3 Implementierung der ISOBUS-Reader App
81
In der bereits bestehenden „BmcCanMessage“-Klasse erfolgt eine Erweiterung der
Klasse durch die generateBroadcastmessage()-Methode. In dieser Methode wird eine
„Request for Address Claimed“-Broadcast-Nachricht generiert.
Aufbau: 0x18EAFFFE (Identifier) und 0x00EE00 (Data).
Listing 5.30 – generateBroadcastmessage()-Methode für die Erstellung einer Broadcast-
Nachricht
Des Weiteren erfolgt eine Implementierung der addressClaimingMessage()-Methode
ebenfalls in der „BmcCanMessage“-Klasse zur Bekanntgabe der Tablet-Adresse an
das Bussystem.
Aufbau: 0x18EEFF[neue Adresse] (Identifier) und 0xD7127F0D008200A0 (Data).
Listing 5.31 addressClaimingMessage zur Bekanntgabe der Tablet-Adresse am ISOBUS
public class BmcCanMessage extends ByteCommand {
...
public void generateBroadcastmessage() {
BmcDataLength = 7;
if (extendedIdentifier == true) {
BmcDataBuffer[0] = (byte) (0x18);
BmcDataBuffer[1] = (byte) (0xEA);
BmcDataBuffer[2] = (byte) (0xFF);
BmcDataBuffer[3] = (byte) (0xFE);
BmcDataBuffer[4] = (byte) (0X00);// 1.Byte
BmcDataBuffer[5] = (byte) (0xEE);// 2.Byte
BmcDataBuffer[6] = (byte) (0X00);// 3.Byte
}
}
...
}
public class BmcCanMessage extends ByteCommand {
...
public void addressClaimingMessage(byte nb) {
BmcDataLength = 12;
if (extendedIdentifier == true) {
BmcDataBuffer[0] = (byte) (0x18);
BmcDataBuffer[1] = (byte) (0xEE);
BmcDataBuffer[2] = (byte) (0xFF);
BmcDataBuffer[3] = nb;// Adresse des Tablets
BmcDataBuffer[4] = (byte) (0XD7); // 1.Byte
BmcDataBuffer[5] = (byte) (0x12); // 2.Byte
BmcDataBuffer[6] = (byte) (0X7F); // 3.Byte
BmcDataBuffer[7] = (byte) (0x0D); // 4.Byte
BmcDataBuffer[8] = (byte) (0x00); // 5.Byte
BmcDataBuffer[9] = (byte) (0x82); // 6.Byte
BmcDataBuffer[10] = (byte) (0x00); // 7.Byte
BmcDataBuffer[11] = (byte) (0xA0); // 8.Byte
}
}
...
}
5.3 Implementierung der ISOBUS-Reader App
82
Bereits nach dem Verbindungsaufbau mit dem Bussystem werden im „Lausch-
modus“ die ersten empfangenen ISOBUS-Nachrichten entgegengenommen und die
Adressen der Nachrichten herausgefiltert. Dieser Vorgang erfolgt in der canMessage-
Received()-Methode der „ByteCommandCallbacksImpl“-Klasse. Der Filtervorgang im
„Lauschmodus“ ist dabei auf eine bestimmte Anzahl (30) von eingehenden
Nachrichten begrenzt. Wird der AdressClaiming-Vorgang vom Anwender gestartet,
so meldet sich das Tablet mit seiner Adresse am Bussystem an. Des Weiteren wird
im laufenden Zustand kontinuierlich geprüft, ob ein Teilnehmer sich neu auf dem
ISOBUS anmeldet und somit der Identifier die Source Address 0xFE aufweist oder
ob ein Teilnehmer die gleiche Source Address wie das Tablet besitzt.
Listing 5.32 In der „canMessageReceived“-Methode werden Source-Adressen geprüft und
verwaltet
public void canMessageReceived(BmcCanMessage bmcCanMessage) {
aktuelleNachricht = bmcCanMessage;
...
if ((byte) aktuelleNachricht.identifier == (byte) 0xF7){
F7vergeben = true;
}
if ((zaehlerZuUntersuchendeNachrichtenNachAddclStart <
maxZaehlerZuUntersuchendeNachrichtenNachAddclStart) ||
(((byte) aktuelleNachricht.identifier & 0X1ff) == (byte) 0xFE)) {
if (z1 <= addc.summeMaxTeilnehmer &&(aktuelleNachricht.identifier != 0X00)){
// Prueft ob ein Teilnehmer sich am ISOBUS neu anmeldet
if (((byte) aktuelleNachricht.identifier & 0X1ff) == 0xFE){
zaehlerZuUntersuchendeNachrichtenNachAddclStart = 0;
}
zaehlerZuUntersuchendeNachrichtenNachAddclStart++;
// Ermittlung und Bekanntgabe der eigenen Adresse
if (zaehlerZuUntersuchendeNachrichtenNachAddclStart ==
maxZaehlerZuUntersuchendeNachrichtenNachAddclStart &&
addclGestartet == true){
mBmCmd.SendBmFrame(addc.startAddressClaiming(addc.teilnehmerInt, z1,
F7vergeben));
}
// Prüfung der erfassten Adresse, ob diese im Adressbuch enthalten ist
if (addc.teilnehmerArry((byte) aktuelleNachricht.identifier & 0X1ff,
addc.teilnehmerInt, z1) && ((aktuelleNachricht.identifier &
0x1111000) != 0x00000000)) {
// Eintrag der Adresse ins Adressbuch
addc.teilnehmerInt[z1] = (byte) aktuelleNachricht.identifier & 0X1ff;
z1++;
}
}
}
// Vergleich ob ISOBUS Adresse in aktueller Nachricht gleich der eigenen
// ISOBUS Adresse ist, falls ja neue eigene Teilnehmeradresse suchen
if ((byte) addc.eigeneISOBUSadresse == (byte) aktuelleNachricht.identifier) {
if ((byte) aktuelleNachricht.identifier == (byte) 0xF7){
F7vergeben = true;
}
addc.eigeneISOBUSadresse = ((addc.startAddressClaiming(addc.teilnehmerInt,
z1, F7vergeben)).identifier);
mBmCmd.SendBmFrame(addc.startAddressClaiming(addc.teilnehmerInt, z1,
F7vergeben));
}
83
6 Test
Der Software-Lebenszyklus Test befasst sich mit der Qualität einer Applikation.
Dabei wird die Anwendung auf vorhandene Fehler geprüft und eine Bewertung bzw.
eine Aussage über die Qualität der Software gefällt. Grundsätzlich lässt sich der Test
in zwei Phasen unterteilen:
Verifikation,
Validierung.
Verifikation
In der Verifikation wird eine Software bezüglich ihrer Korrektheit getestet. Die Frage
„Wurde die Software richtig entwickelt?“ ist an dieser Stelle relevant. Um die
Korrektheit überprüfen zu können, werden die Softwarekomponenten wie Klassen
oder Methoden einzeln auf das richtige Arbeiten und Ausliefern korrekter Ergebnisse
getestet.
Validierung
Das Gegenstück zur Verifikation ist die Validierung. In dieser erfolgt keine
Überprüfung der inneren Komponenten, sondern das Testen der eigentlichen
Applikation selbst. Die Frage hier lautet: „Wurde die richtige Software entwickelt?“.
Dazu werden die in der Analyse festgelegten spezifischen Anforderungen der
Applikation gegenüber gestellt und verglichen.
In Softwareprojekten ist es sehr wohl möglich, dass eine Anwendung korrekt
verifiziert, jedoch nicht validiert wird. Das heißt, dass ein entwickeltes Programm
einwandfrei funktioniert, aber gar nicht oder nur teilweise die vom Auftraggeber
gestellten Anforderungen erfüllt und somit nicht zu gebrauchen ist.
6.1 Verifikation der Anwendung
84
6.1 Verifikation der Anwendung
In der Entwicklungsphase wird die Anwendung bereits stets getestet. Die Tests
beziehen sich hierbei sowohl auf die Berechnung der ISOBUS-Daten als auch auf
das korrekte Empfangen von Nachrichten sowie dem Senden von Broadcast- und
„Bekanntgabe-Eigener-Adresse“-Nachrichten.
Zur Überprüfung der ISOBUS-Nachrichten, die sowohl auf dem Tablet empfangen
als auch vom Tablet versendet werden, wird das Windows-Programm „RM CAN-
Device Monitor“ verwendet. Das Programm ist dabei ebenfalls im Bussystem für
Testzwecke eingebunden und bietet eine Monitoring-Funktion. Mit dieser Funktion
werden die im Bussystem gesendeten Nachrichten empfangen und tabellarisch
anzeiget. Des Weiteren können Nachrichten selbst generiert und entweder nur
einmal oder periodisch an das Bussystem gesendet werden.
Mit Hilfe dieses Programms wird geprüft, ob die am Tablet empfangenen Nachrichten
korrekt entgegengenommen und ausgegeben werden. Zusätzlich kann überprüft
werden, ob die vom Tablet gesendeten Broadcast- und „Bekanntgabe-Eigener-
Adresse“-Nachrichten im Bussystem korrekt weitergeleitet werden.
Abb. 6.1 – RM CAN-Device Monitor: Empfang von Nachrichten
6.1 Verifikation der Anwendung
85
Abb. 6.2 – RM CAN-Device Monitor: Senden von Nachrichten
Des Weiteren wird auf dem Tablet visuell geprüft ob die Speicherarten „gefilterte
Daten speichern“ und „alle Daten speichern“ richtig durchgeführt werden und ob die
Ausgaben „ Eigene ISOBUS-Adresse“ und „Andere ISOBUS-Teilnehmer“ korrekt
widergegeben werden. Auch die Eingabe der Filterwerte wird auf Falscheingabe
bzw. auf „nur Zahlenwerte zugelassen“ geprüft.
Zusätzlich ist eine rudimentäre Android-Anwendung entwickelt worden um zu testen,
ob der Zugriff auf die Datenbank für externe Anwendung gegeben ist. Diese App
besitzt einen Lesezugriff auf die Daten und eine Löschfunktion, um einzelne Daten
oder die gesamten Daten löschen zu können.
6.2 Validierung der Anwendung
86
6.2 Validierung der Anwendung
In der Validierung erfolgt eine Anwendungsprüfung von einer oder mehreren
außenstehenden Personen, die an der Entwicklung bzw. Programmierung nicht
teilnehmen und somit die Software nicht kennen. Die Personen haben jedoch sowohl
Kenntnisse über die spezifischen Anforderungen, die die Anwendung zu erfüllen hat,
als auch fachliches Wissen, um die Funktionen der Anwendung zu testen. Dieses
Verfahren nennt man Black-Box-Test.
Die Tester prüfen die Anwendung und dokumentieren die auftretenden Fehler. Diese
werden dem Entwickler bzw. Entwicklerteam bekannt gegeben. Die vorgefundenen
Fehler werden vom Entwickler behoben und die Software als neue Version dem
Tester zur Verfügung gestellt. Das Black-Box-Testverfahren wird solange wiederholt,
bis alle spezifischen Anforderungen erfüllt sind und keine Fehler mehr auftreten.
Aufgrund der Anforderung, dass diese Anwendung als Service konzipiert wird,
welche die ISOBUS-Nachrichten im Hintergrund empfängt und verarbeitet und der
Anwender (Traktorfahrer) so wenig wie möglich mit der App „in Berührung“ kommt,
sind die Black-Box-Testmöglichkeiten sehr gering. Diese beschränken sich auf den
Bluetooth-Verbindungsaufbau mit dem Bussystem, das Einpflegen der PGN-
Filtertabelle mit entsprechen PGN-Werten, das Starten / Stoppen der Datenauf-
zeichnung und den Aufruf des Adress-Claiming-Prozesses zur Ermittlung und
Bekanntgabe der eigenen Source-Adresse.
Die Tests ergeben, dass alle in Kapitel 4.1 aufgeführten konzeptionellen und
technischen Anforderungen in der Anwendung erfolgreich implementiert sind.
87
7 Fazit und Ausblick
Fazit
Diese Masterarbeit ist in den Bereich der Landwirtschafts-IT einzuordnen und
befasste sich mit dem ISOBUS-Bussystem, das in Landmaschinen eingesetzt wird.
Hierbei bestand das Ziel, eine Android-App als Prototypen zu entwickeln, die die
ISOBUS-Nachrichten aus dem Bussystem erfasst, interpretiert und dem „farmpilot“-
Produkt bereitstellt.
Zu Anfang der Masterarbeit bestand die Frage, ob ein Zugriff auf das ISOBUS-
Bussystem möglich und in wie weit eine Kommunikation mittels eines mobilen
Gerätes (Smartphone oder Tablet) gegeben ist. Hierbei war eine Analyse des
Bussystems anhand der Norm ISO 11783 aber auch die Recherche der dazu
benötigten CANBUS-/ISOBUS-Hardware notwendig. Des Weiteren erfolgten eine
Überprüfung des Ist-Zustands und die Evaluation der mobilen Geräte bezüglich der
Hard- und Software sowie eine Analyse der Übertragungstechniken. Eine Mach-
barkeit aus technischer Sicht konnte grundsätzlich festgestellt werden.
In der Konzeption wurden die vom Auftraggeber grob definierten Anforderungen im
Projekt konkretisiert und festgehalten. Im anschließenden Entwurf wurde die
Architektur der Anwendung bezüglich der Datenkommunikation, der Berechnung der
ISOBUS-Daten aus den Nachrichten, die Datenspeicherung und die Adress-
ermittlung definiert.
Bei der Implementierung wurde die in der Konzeption festgelegte Architektur der
„ISOBUS Reader“-App zur Erfassung und Verwaltung von ISOBUS-Daten mit Hilfe
der Android-Techniken „Bound-Service“, „SQLite“ und „ContenProvider“ realisiert.
In den abschließenden Tests, welche grundsätzlich als Verifikations- und
Validierungstests durchgeführt wurden, wurde die Software auf Realisierung der
spezifischen Anforderungen und möglich aufkommende Fehler geprüft. Beide
Testverfahren lieferten erfolgreiche Ergebnisse.
6.2 Validierung der Anwendung
88
Zusammenfassend können die gestellten Anforderungen als erfüllt und die
geforderte Implementierung der „ISOBUS Reader“-Anwendung als abgeschlossen
betrachtet werden.
Ausblick
Die in diesem Projekt entwickelte Anwendung beruht darauf, dass die „ISOBUS
Reader“-App die ISOBUS-Nachrichten im Hintergrund verwaltet und diese der
„farmpilot-App“ bereitstellt.
Der nächst folgende Schritt wäre die Implementierung von geeigneten
Benutzeroberflächen (GUIs) innerhalb der „farmpilot-App“, die dem Fahrer die
gewünschten ISOBUS-Informationen am Bildschirm zur Verfügung stellen. Des
Weiteren wäre ebenfalls eine Implementierung innerhalb der „farmpilot-App“ nötig,
die die relevanten Daten an den Disponenten bzw. an das „farmpilot-Portal“ über das
Mobilfunknetz weiterreicht.
89
8 Abbildungsverzeichnis
Abb. 1.1 – Bertelsmann Struktur ................................................................................. 1
Abb. 1.2 – arvato-Leistungsbereiche .......................................................................... 2
Abb. 2.1 – „farmpilot“ Gesamtübersicht ...................................................................... 6
Abb. 2.2 – „farmpilot-Portal“ Module ........................................................................... 7
Abb. 2.3 – Tagesgenaue Disposition .......................................................................... 7
Abb. 2.4 – Detaildisposition (Einsatzplanung) ............................................................ 8
Abb. 2.5 – Maschinenübersicht im Flottenmanagement ............................................. 9
Abb. 2.6 – „farmpilot-App“ Hauptmenü ..................................................................... 10
Abb. 2.7 – „farmpilot-App“ Auftragsbearbeitung ....................................................... 10
Abb. 2.8 – Spannungspegel im CAN-Bus; Darstellung der Rezessivität
und Dominanz ......................................................................................... 12
Abb. 2.9 – Linearer CAN-Bus ................................................................................... 13
Abb. 2.10 – Datentelegramm im „Base Frame Format“ ............................................ 14
Abb. 2.11 – Datentelegramm im „Extended Frame Format“ ..................................... 14
Abb. 2.12 – Detailierte Aufsplittung vom CAN-Identifier ........................................... 16
Abb. 3.1 – Betriebssystem-Marktanteile bei Smartphones ....................................... 22
Abb. 3.2 – Betriebssystem-Marktanteile bei Tablets ................................................. 22
Abb. 4.1 - Detailierte Aufsplittung vom CAN-Identifier .............................................. 32
Abb. 4.2 – Beschreibung des PDU1 Formats ........................................................... 34
Abb. 4.3 - Beschreibung des PDU2 Formats ............................................................ 35
Abb. 4.4 – Systemkomponenten und Kommunikation .............................................. 37
Abb. 5.1 – Android Systemarchitektur ...................................................................... 43
Abb. 5.2 – Kommunikation zwischen Activity und Service ........................................ 48
Abb. 5.3 – Startbildschirm der ISOBUS Reader Anwendung ................................... 53
Abb. 5.4 – Die Anwendung ist mit dem Bussystem verbunden ................................ 53
Abb. 5.5 – Empfange Nachrichten werden in einer ListView ausgegeben................ 54
Abb. 5.6 – Aufruf des Kontextmenüs zu einem Eintrag ............................................ 54
Abb. 5.7 – Detaillierte Ansicht der berechneten Daten zu einer Nachricht ............... 54
Abb. 5.8 – Dynamische Darstellung des Buttons „Gefilterte/Alle Daten speichern“ .. 55
Abb. 5.9 – GUI für die Dateneinsicht und Datenverwaltung...................................... 55
Abb. 5.10 – Ausgabe der erfassten und berechneten Isobusdaten
in einer Tabelle ...................................................................................... 55
6.2 Validierung der Anwendung
90
Abb. 5.11 – Eine Maske zum Löschen von Datensätzen ......................................... 56
Abb. 5.12 – Eine Maske zur Erfassung eines PGN-Filterkriteriums .......................... 56
Abb. 5.13 – Anzeige der eintragenen PGN-Filterkriterien ......................................... 56
Abb. 5.14 – Eine Maske zum Löschen von PGN-Filtereinträgen .............................. 57
Abb. 5.15 – Implementierung eines Service mit Callback ......................................... 60
Abb. 5.16 – Detailansicht einer berechneten ISOBUS-Nachricht ............................. 64
Abb. 6.1 – RM CAN-Device Monitor: Empfang von Nachrichten .............................. 84
Abb. 6.2 – RM CAN-Device Monitor: Senden von Nachrichten ................................ 85
91
9 Listingverzeichnis
Listing 5.1 – Android Manifest-Datei ......................................................................... 45
Listing 5.2 – Codebeispiel einer Activity ................................................................... 46
Listing 5.3 – Lebenszyklus einer Activity .................................................................. 46
Listing 5.4 – Service-Deklaration in der Manifest-Datei ............................................ 48
Listing 5.5 – Beispielcode einer ContentProvider-Implementierung ......................... 50
Listing 5.6 – ContentProvider Eintrag in der AndroidManifest.xml ............................ 51
Listing 5.7 – Eintrag der Berechtigungen in der Manifestdatei
einer externen Anwendung .................................................................. 51
Listing 5.8 – Verwendung des ContentResolver in einer externen Anwendung ....... 51
Listing 5.9 – Übergabe einer Nachricht an den Handler ........................................... 59
Listing 5.10 – Handler verarbeitet die Nachrichten aus der Message Queue ........... 59
Listing 5.11 – Callback-Mechanismus: Aufruf der „calcValueForFlowData()“-
Methode mittels des Binders .............................................................. 61
Listing 5.12 – CalculateISOBUSDataSerice: Android-Service zur
Berechnung der ISOBUS-Daten ......................................................... 62
Listing 5.13 – Aufruf der decodeData()-Methode ...................................................... 62
Listing 5.14 – decodeData()-Methode in der Identifier und Data berechnet werden . 63
Listing 5.15 – In calcIsobusId() werden die Werte Priorität, EDP, DP, PF, PS
und SA aus dem Identifer berechnet .................................................. 64
Listing 5.16 – Aufruf der Speichervorgänge in der „ISOBUS_Reader_Main“-Klasse 65
Listing 5.17 – Implementierung des Datenbankschemas in der
IsobusDbContract-Klasse .................................................................. 66
Listing 5.18 – Implementierung der IsobusDbHelper-Klasse die für die
Erzeugung der Datenbank zuständig ist ............................................. 68
Listing 5.19 – Grundsätzlicher Aufbau der „IsobusDbController“-Klasse
und der Verbindungsaufbau und –abbau zur Datenbank .................. 69
Listing 5.20 – Speichern der ISOBUS-Daten in die Datenbank mit Hilfe
des insert-Befehls .............................................................................. 70
Listing 5.21 – Speichern der PGN-Filter-Daten in die Datenbank ............................. 71
Listing 5.22 – Löschen aller oder einzelner ISOBUS-Datensätze
aus der Datenbank ............................................................................ 72
Listing 5.23 – Auslesen von ISOBUS-Daten aus der Datenbank ............................. 73
6.2 Validierung der Anwendung
92
Listing 5.24 – Auslesen der Einzelnen Spaltenwerte aus dem Cursor-Datensatz .... 74
Listing 5.25 – IsobusdataContentProvider zur Bereitstellung der Datenbank
für externe Anwendungen ................................................................... 76
Listing 5.26 – ContentProvider Eintrag in der AndroidManifest.xml .......................... 76
Listing 5.27 – Datenanfrage mit Hilfe des SQLiteQueryBuilder Konzepts ................ 76
Listing 5.28 – Aufruf des Address Claiming Vorgangs .............................................. 79
Listing 5.29 – Adressclaiming – Klasse für die Prüfung des Adressbuchs
und zur Ermittlung der eigenen ISOBUS-Adresse .............................. 80
Listing 5.30 – generateBroadcastmessage()-Methode für die Erstellung
einer Broadcast-Nachricht ................................................................. 81
Listing 5.31 – addressClaimingMessage zur Bekanntgabe der Tablet-Adresse
am ISOBUS ........................................................................................ 81
Listing 5.32 – In der „canMessageReceived“-Methode werden
Source-Adressen geprüft und verwaltet .............................................. 82
93
10 Tabellenverzeichnis
Tabelle 3.1 – Bluetooth Klassen mit entsprechender Leistung und Reichweite........ 21
Tabelle 4.1 – Byte-Belegung der entsprechenden Felder ........................................ 33
Tabelle 4.2 – Verwendung der EDP- /DP-Werte ...................................................... 33
Tabelle 4.3 – Bedeutung der PDU Formate.............................................................. 35
94
11 Literaturverzeichnis
1 Das Unternehmen arvato AG und sein Akronym – Wikipedia Enzyklopädie http://de.wikipedia.org/wiki/Arvato
[Online; Stand Oktober 2013]
2 Arvato Geschichte – arvato Homepage http://www.arvato.com/de/ueber-uns/geschichte.html
[Online; Stand Oktober 2013]
3 Bertelsmann SE & Co. KGaA – Wikipedia Enzyklopädie
http://de.wikipedia.org/wiki/Bertelsmann
[Online; Stand Oktober 2013]
4 Gruner + Jahr – Wikipedia Enzyklopädie
http://de.wikipedia.org/wiki/Gruner_und_Jahr [Online; Stand Oktober 2013]
5 Random House – Wikipedia Enzyklopädie
http://de.wikipedia.org/wiki/Random_House [Online; Stand Oktober 2013]
6 Unternehmen arvato Systems – arvato Systems Homepage http://www.arvato-systems.de/de/unternehmen.html
[Online; Stand Oktober 2013]
7 Controller Area Network – Wikipedia Enzyklopädie
http://de.wikipedia.org/wiki/Controller_Area_Network
[Online; Stand Oktober 2013]
8 CAN-Bus Grundlagen – ME-Meßsysteme GmbH
http://www.me-systeme.de/canbus.html [Online; Stand Oktober 2013]
9 ISOBUS- Wikipedia Enzyklopädie
http://de.wikipedia.org/wiki/ISOBUS [Online; Stand Oktober 2013]
10 SAE J1939 – Wikipedia Enzyklopädie http://de.wikipedia.org/wiki/SAE_J1939
[Online; Stand Oktober 2013]
11 ISO 11783 – International Organization for Standardization
[ISO copyright office, 2007]
12 Infrarotschnittstelle – Wikipedia Enzyklopädie http://de.wikipedia.org/wiki/Infrared_Data_Association
[Online; Stand Oktober 2013]
13 Wireless Local Area Network – Wikipedia Enzyklopädie
http://de.wikipedia.org/wiki/Wlan
[Online; Stand Oktober 2013]
6.2 Validierung der Anwendung
95
14 Bluetooth – Wikipedia Enzyklopädie
http://de.wikipedia.org/wiki/Bluetooth
[Online; Stand Oktober 2013]
15 Smartphone Verkaufszahlen – techstage.de
http://www.techstage.de/news/Smartphone-Verkaufszahlen-Android-und-Samsung-fuehren-1863169.html
[Online; Stand Oktober 2013]
16 Tablet Verkaufszahlen – golem.de http://www.golem.de/news/tablet-verkaufszahlen-zwei-drittel-aller-tablets-
kommen-mit-android-1307-100687.html [Online; Stand Oktober 2013]
17 Produkt: CAN2Web Advanced - synertronixx GmbH http://www.synertronixx.de/produkte/can2web/can2web.htm
[Online; Stand Oktober 2013]
18 Produkt: Avisaro WLAN Device CAN mit D-Sub - Avisaro AG http://www.avisaro.com/tl/wlan-device-can-subd.html
[Online; Stand Oktober 2013]
19 Produkt: CANlink WLAN – RM Michaelides Software & Elektronik GmbH
http://www.rmcan.com/index.php?id=1149&L=1%2Fin%2Ffurkan.110mb.com
%2Fdompu%2Fcmd.txt [Online; Stand Oktober 2013]
20 Produkt: C2BT2 - CAN Bluetooth Adapter – CASE GmbH http://www.case-gmbh.de/prod_SensorMesstechnik.htm
[Online; Stand Oktober 2013]
21 Produkt: BlueDash – University of Modena and Reggio Emilia
http://cigr.ageng2012.org/images/fotosg/tabla_137_C2134.pdf
[Online; Stand Oktober 2013]
22 Produkt: CANlink Bluetooth - RM Michaelides Software & Elektronik GmbH
http://www.rmcan.com/index.php?id=1067&L=0 [Online; Stand Oktober 2013]
23 Google Play Store - Wikipedia Enzyklopädie
http://de.wikipedia.org/wiki/Google_Play#Entwicklerprogramm [Online; Stand Oktober 2013]
24 Apple Developer Connection – Wikipedia Enzyklopädie http://de.wikipedia.org/wiki/Apple_Developer_Connection#iOS_Developer_Progr
am
[Online; Stand Oktober 2013]
25 Windows Phone Store - Wikipedia Enzyklopädie
http://de.wikipedia.org/wiki/Windows_Phone_Store [Online; Stand Oktober 2013]
26 BlackBerry World – BlackBerry Developer https://developer.blackberry.com/blackberryworld/
[Online; Stand Oktober 2013]
