Entwicklung eines Low-Cost Multifunktionsdisplays für das Automatic Identification System (AIS)

Transkript

1 Entwicklung eines Low-Cost Multifunktionsdisplays für das Automatic Identification System (AIS) Einsatz von OpenSeaMap für ein Schiffsnavigationsgerät eingereicht von DI (FH) Christian Poms MASTERARBEIT zur Erlangung des akademischen Grades Master of Arts (MA) an der Ferdinand Porsche FernFH Studienrichtung Wirtschaftsinformatik in Zusammenarbeit mit der Firma FT-TEC Begutachter: Mag. Franz Kopica, BSc., MBA., MSc. Technikum-Wien 2. Begutachter: Mag. Dr. Oliver Jorns Ferdinand Porsche FFH GmbH Langenwang, Juni 23

2 Danksagung Ich bedanke mich bei der Firma FT-TEC, die mir die Entwicklung des Projekts Multifunktionsdisplay anvertraut und damit die Grundlage meiner Masterarbeit geschaffen hat. Die Arbeit erhielt dadurch sowohl theoretische als auch wirtschaftliche Bedeutung. Besonderer Dank geht an Herrn Mag. Franz Kopica, BSc., MBA., MSc., der mich als Betreuer meiner Masterarbeit während des gesamten Erstellungsprozesses sehr aktiv und gewinnbringend unterstützt hat. Ich danke auch dem Studiengangsleiter für Wirtschaftsinformatik der Ferdinand Porsche FernFH, Herrn Mag. Dr. Oliver Jorns, für die Annahme der Zweitbetreuung und seine begleitende Motivationsarbeit. Hochachtung und Dankbarkeit möchte ich mit diesen Zeilen auch meiner Ehefrau Claudia erweisen. Durch ihre Bereitwilligkeit, viele Pflichten des täglichen Lebens aus meiner Verantwortung zu übernehmen, war es mir möglich, diese Arbeit in Angriff zu nehmen und erfolgreich abzuschließen. Sie kam mir stets mit viel Verständis entgegen und war mir eine geduldige Zuhörerin, immer, wenn ich sie gebraucht habe. Ein unermesslicher Dank geht an meine Kollegen des Studiengangs WiMa 9, ganz besonders an meine Freunde DI (FH) Thomas Rankl, MA und DI (FH) Arno Schwendenwein, MA, für ihren Teamgeist und die wertvolle Motivation. Ich möchte Gott danken, dass den Entdeckungen auf dieser Welt keine Grenzen gesetzt sind und er uns Menschen mit den Fähigkeiten ausgestattet hat, diese Entdeckungen zu machen. ii

3 Erklärung Ich versichere, dass ich die vorliegende Arbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Mit der Einstellung dieser Arbeit in die Bibliothek bin ich einverstanden. Wien, im Juni 23 iii

4 Kurzzusammenfassung Im vergangenen Jahrzehnt wurde das Automatic Identification System (AIS) für die See- und Binnenschifffahrt eingeführt und unterstützt seither Hafenverwaltung und Schiffsbesatzung, sichere Navigationsentscheidungen zu treffen und dadurch Unfälle zu vermeiden und negative Auswirkungen auf Mensch und Natur zu reduzieren. Damit einhergehend wurden benutzerfreundliche Anzeigeinstrumente auf den Markt gebracht, die dieses System, in Kombination mit elektronischen Seekarten (ENC), zu einer modernen Navigationshilfe macht, die wesentlich zur Erhöhung der Sicherheit auf See beiträgt. Für die Berufsschifffahrt bereits weitestgehend verpflichtend, ist die Verbreitung von AIS und kompatiblen Anzeigegeräten, meist Multifunktionsdisplays genannt, im Bereich der Freizeitschifffahrt sehr vom Kosten-Nutzen-Faktor abhängig. In dieser Arbeit wird die Entwicklung der Software für ein Multifunktionsdisplay beschrieben. Daraus resultieren soll ein Produkt, das durch den Einsatz von Open-Source-Technologie eine kostengünstige Alternative zu existierenden Geräten darstellt und vor allem für private Bootsbesitzer interessant sein soll. Statt kommerziellen digitalen Seekarten wird das frei erhältliche Open Source Kartenmaterial von OpenSeaMap für die Kartenanzeige verwendet. Hohe Lizenzkosten für Kartenanschaffung und -aktualisierung entfallen damit, was die Attraktivität als Low-Cost-Produkt stärken sollte. iv

5 Abstract During the last decade the Automatic Identification System (AIS) has been introduced to the worldwide maritime traffic and inland water navigation. Now, it supports Vessel Traffic Services (VTS) operations and a ship's crew in making navigational decisions to reduce the chance of accidents as well as related negative effects on humans and nature. User-friendly display devices became available, which use the AIS in electronic nautical charts (ENC) applications, thus making it a powerful navigational aid to increase the safety of life at sea. Although it is required by law to equip most of commercial transport vessels with AIS, it is mostly based on a cost-benefit decision if such a solution is also obtained by owners of private or leisure vessels, even though all types of vessels would benefit from the advantages of AIS. This master thesis describes the software development process for a multifunctional display to serve as a chartplotter in a nautical environment. Its aim is the creation of a product that could become a cost-effective alternative to existing devices, highly powered by open source technology. It is based on the freely available OpenSeaMap chart, instead of the commonly used proprietary ones. By eliminating the necessity of purchasing licences for aquiring and updating digital charts, costs for the client are effectively reduced, thus making the product more affordable and commercially attractive. v

6 Inhaltsverzeichnis KAPITEL. EINLEITUNG... Themenbegründung..... Persönliche Motivation Zielsetzung Nicht-Ziele Aufbau der Arbeit Arbeitsmethode...5 KAPITEL 2 STAND DER TECHNIK UND UMFELD Einleitung Vessel Traffic Services AIS und Komponenten Was ist AIS... AIS Ausrüstungsverpflichtung SOLAS V... AIS System... 2 Kommunikationssystem...4 Schnittstelle zu externen Applikationen...8 Class A versus Class B AIS Transponder...2 OpenStreetMap Einleitung GIS OGC und Simple Features Access Spatial Reference System Was ist OpenStreetMap OSM Datenmodell Nodes Ways Relations Rendern von Slippy Maps Qt Was ist Qt Widgets Signals und Slots Styling Qt Plugin System KAPITEL 3 ENTWICKLUNG DES AIS MULTIFUNKTIONSDISPLAYS Überblick Kundenbefragung Anforderungen an die Hardware...4 vi

7 3.3. Recheneinheit Coprozessor Speicher Schnittstellen Benutzerschnittstelle Hardware Hauptprozessor i.mx Coprozessor Cortex-M Peripherie Anforderungen an die Software Aufgabenstellung Auswahl Programmiersprache Auswahl GUI Framework Technische Randbedingungen Organisatorische Randbedingungen Kontextabgrenzung Fachlicher Kontext Technischer Kontext Features für einen ersten Prototyp im Detail App: Karte App: Target-Liste App: GPX-Log App: Software Update User Interface Design Hardware User Interface Software User Interface Softwarekonzept und -architektur Bausteinsicht der obersten Ebene Funktionsweise der Applikation Custom User Interface Erstellung der UI Template Klasse mit Qt Designer Benutzerdefinierten Style erzeugen Verwaltung der AIS Daten Das Plugin System App: Kartenplotter QMapControl Entwicklung für das Zielsystem Erstellen der Toolchains...82 KAPITEL 4 OPENSTREETMAP FÜR OFFLINE KARTE Einleitung Anforderung Realisierung OSM Render Maschine Komponenten vii

8 PostGIS Datenbank osm2pgsql osmosis Mapnik TileMill Erstellung der Custom-Map Datendatei für Kartenausschnitt erstellen OSM Daten herunterladen Kartenausschnitt definieren Datenextrakt aus Planet Datei erstellen Datenbankimport Styling Rendern der Karte Speicherplatzoptimierung OpenSeaMap... 3 KAPITEL 5 WIRTSCHAFTLICHE BETRACHTUNG Marktumfeld Vergleichsanalyse Fazit... 9 KAPITEL 6 SCHLUSSBEMERKUNGEN/RESÜMEE Überprüfung der Zielerreichung Praxistauglichkeit und Ausblick... KAPITEL 7 ANHANG...I 7. AIS Nachrichten...I 7.2 Konvertierung von ASCII-Code zu 6-Bit Binärdaten...III 7.3 Shell Script zum Indizieren leerer Tiles...IV 7.4 SOLAS Konvention für AIS...VI KAPITEL 8 LITERATURVERZEICHNIS...VII viii

9 Verzeichnis der Abbildungen Abbildung : Vessel Traffic Center mit Operator, Port of London, [2]...9 Abbildung 2: AIS System, [7]...3 Abbildung 3: Blockdiagramm AIS Class A Transponder [eigene Darstellung]...4 Abbildung 4: AIS Protokollpaket (vgl. [8], S. 2) [eigene Darstellung]...5 Abbildung 5: AIS TDMA Übertragungsschema, []...6 Abbildung 6: OpenGIS Simple Features Access Klassenhierarchie, [26]...23 Abbildung 7: Mercator Projektion, [27]...26 Abbildung 8: Beispiel für Node Datentyp [eigene Darstellung]...28 Abbildung 9: Tile Schema für Web-Karten, [29]...3 Abbildung : Qt Module, [3]...32 Abbildung : Blockschaltbild Hardware ([7], S. 44)...43 Abbildung 2: AIS Display Prototyp, Aufbau auf Plexiglasscheibe [eigene Darstellung]...45 Abbildung 3: Fachlicher Kontext [eigene Darstellung]...49 Abbildung 4: Technischer Kontext [eigene Darstellung]...5 Abbildung 5: Skizze Hardware UI Design [eigene Darstellung]...55 Abbildung 6: Bedeutung Funktionstasten [eigene Darstellung]...56 Abbildung 7: Menütastenblock [eigene Darstellung]...57 Abbildung 8: Design Entwurf App-Browser [eigene Darstellung]...58 Abbildung 9: Design Entwurf App Karte [eigene Darstellung]...59 Abbildung 2: Design Entwurf Konfigurationsseite [eigene Darstellung]...6 Abbildung 2: Whitebox Darstellung MFD Software [eigene Darstellung]...6 Abbildung 22: Aktivitätsdiagramm Starten der MFD Applikation [eigene Darstellung]...64 Abbildung 23: Klassendiagramm UI Library [eigene Darstellung]...66 Abbildung 24: SBButton in Qt Designer [eigene Darstellung]...67 Abbildung 25: border-image für #pushbutton:focus [eigene Darstellung]...7 Abbildung 26: SBButton Beispiel für App Karte [eigene Darstellung]...7 Abbildung 27: Speicherblock der SPI DMA Übertragung [eigene Darstellung]...7 Abbildung 28: Klassendiagramm AIS Modul [eigene Darstellung]...72 Abbildung 29: AIS Display Plugin Schema [eigene Darstellung]...74 Abbildung 3: AppMapWidget - View Klasse des Map-Plugins [eigene Darstellung]...78 Abbildung 3: Symbole für AIS Targets (Typ, Kurs) [eigene Darstellung]...8 Abbildung 32: MFD Applikation lauft in Virtual Framebuffer [eigene Darstellung]...82 Abbildung 33: Vergleich Datenbankimport HD/SSD, [53]...87 Abbildung 34: Screenshot Polygon Kaspisches Meer [eigene Darstellung]...96 Abbildung 35: Karte Tag-/Nacht-Modus [eigene Darstellung]... Abbildung 36: Karte Warnemünde, Basislayer und OpenSeaMap Layer [eigene Darstellung]...5 Abbildung 37: Computer process to convert ASCII-code to 6-bit binary field [2]...III Verzeichnis der Tabellen Tabelle : Typische AIS Daten (Auswahl) [eigene Darstellung]... Tabelle 2: Reporting Intervalle (vgl. [8], S. 4) [eigene Darstellung]...7 Tabelle 3: AIS Message 8 Class B Positionsnachricht (vgl. [8], S. 2)...8 Tabelle 4: Aufbau eines NMEA-83 Protokollsatzes [eigene Darstellung]...9 Tabelle 5: ASCII zu 6-bit Konvertierung [eigene Darstellung]...2 Tabelle 6: Werte der AIS Message 8 für Beispiel NMEA Sentence [eigene Darstellung]...2 Tabelle 7: Ergebnisse Umfrage MFD-Features ([7], S. 3)...39 Tabelle 8: Technische Randbedingungen [eigene Darstellung]...47 ix

10 Tabelle 9: Organisatorische Randbedingungen [eigene Darstellung]...48 Tabelle : Features Basissoftware [eigene Darstellung]...52 Tabelle : Features App Karte [eigene Darstellung]...53 Tabelle 2: Größenvergleich Planet Datei und Extrakt [eigene Darstellung]...98 Tabelle 3: Datenbank-Tabellen nach osm2pgsql Import ([6], S. 29)...99 Tabelle 4: TileMill Layer-Definition [eigene Darstellung]... Tabelle 5: Datengröße bei Optimierung [eigene Darstellung]...2 Tabelle 6: Marktumfeld Produktvergleich [eigene Darstellung]...7 Tabelle 7: Vergleichsmatrix [eigene Darstellung]...9 Tabelle 8: AIS Nachrichten (vgl. [8]) [eigene Darstellung]...II Verzeichnis der Listings Listing : XML Beschreibung für OSM Node [eigene Darstellung]...27 Listing 2: XML Beschreibung für OSM Ways [eigene Darstellung]...29 Listing 3: XML Beschreibung für OSM Relations [eigene Darstellung]...29 Listing 4: Hello World Programm für Qt, [3]...33 Listing 5: Qt Signal senden [eigene Darstellung]...34 Listing 6: Definition der Signal Funktion [eigene Darstellung]...34 Listing 7: Definition der Slot Funktion [eigene Darstellung]...34 Listing 8: Beispiel Interface Deklaration in Qt [eigene Darstellung]...36 Listing 9: Beispiel Plugin Deklaration in Qt [eigene Darstellung]...37 Listing : Ausschnitt aus SBButton Klassenimplementierung [eigene Darstellung]...68 Listing : Qt Style Sheet Definition für die Klasse SBButton [eigene Darstellung]...69 Listing 2: Anwendungsbeispiel der Klasse AisDatabase [eigene Darstellung]...72 Listing 3: Definition von AISDatabase::queryTargets() [eigene Darstellung]...73 Listing 4: Plugin Interface Klasse [eigene Darstellung]...75 Listing 5: Host Interface Klasse [eigene Darstellung]...76 Listing 6: Laden der Plugins [eigene Darstellung]...76 Listing 7: Initialisierung des Springboards [eigene Darstellung]...77 Listing 8: Implementierungsklasse AppMap [eigene Darstellung]...77 Listing 9: Anwendung des QMapControl Widgets [eigene Darstellung]...8 Listing 2: Anzeige von Geometrien [eigene Darstellung]...8 Listing 2: Inhalt von qmake.conf [eigene Darstellung]...83 Listing 22: LVM Volums der OSM Render Maschine [eigene Darstellung]...88 Listing 23: Datenbank Konfiguration (postgresql.conf), [55]...89 Listing 24: Aufbau der Map Datei [eigene Darstellung]...92 Listing 25: Aufbau einer CartoCSS Datei [eigene Darstellung]...92 Listing 26: Beispiel eines Map Calls (Overpass API) [eigene Darstellung]...95 Listing 27:.poly Datei für Testregion [eigene Darstellung]...97 Listing 28: gpx2poly.pl Patchdatei [eigene Darstellung]...97 Listing 29: CartoCSS Definition für Layer waterway_label [eigene Darstellung]... Listing 3: OSM Code für Yachthafen Hohe Düne [eigene Darstellung]...3 Listing 3: Overpass Abfrage für Bereich Warnemünde [eigene Darstellung]...4 Listing 32: Shell Script zum Auffinden und Indizieren leerer Tiles [eigene Darstellung]...V x

11 Verzeichnis der Abkürzungen AIS Automatic Identification Services ATN Aids To Navigation CAN Controller Area Network COG Course Over Ground ENC Electronic Navigation Chart GIS Geographic Information System GMDSS Global Marine Distress Safety System GPIO General Purpose Input/Output GPS Global Positioning System IDE Integrated Development Environment IMO International Maritime Organization MA Masterarbeit MFD Multifunktionsdisplay MMSI Maritime Mobile Service Identity OGC Open Geospatial Consortium OSM OpenStreetMap SDIO Secure Digital Input Output SOG Speed Over Ground SRS Spatial Referencing System SOLAS International Convention for the Safety of Life at Sea TDMA Time Division Multiple Access TRB Transportation Research Board VTS Vessel Traffic Services xi

12 Kapitel. Einleitung Kapitel Einleitung. Themenbegründung Im Jahr 989 ereignete sich eine der folgenschwersten maritimen Umweltkatastrophen der Geschichte. Am 24. März dieses Jahres lief die Exxon Valdez, ein über 3 m langer Öltanker, auf Grund und verlor geschätzte 4 Millionen Liter Rohöl, die dabei in das Meer vor Alaska ausgetreten sind (vgl. [], S. 42). Unmittelbare Auswirkungen der Katastrophe waren der Tod von hundert tausenden Meeresbewohnern. Schätzungen eines Teams der University of North Carolina sagen, dass es noch bis 29 dauern kann, bis einige der arktischen Küstenbehausungen wieder vollständig regeneriert sein werden (vgl. [2], Long-Term Population Impacts). Kurz nach diesem Vorfall wurden (weitere) Maßnahmen zur Vermeidung solcher Unfälle ergriffen. Schiffe in Gewässern der Vereinigten Staaten mussten ab diesem Zeitpunkt verpflichtend die Vessel Traffic Services (VTS) der U.S. Coast Guard unterstützen. VTS ist ein marines Verkehrskontrollsystem zur Steigerung der Sicherheit auf See und zur Gewährleistung einer effizienten Navigation für ein gezieltes Verkehrsmanagement (siehe Kapitel 2.2). Vor der Exxon Valdez Katastrophe wurde von den Behörden manueller Sprechfunk verwendet, um Informationen über ein Schiff zu erhalten (Name, geplante Route, ) und diese manuell für Verkehrsmanagement Zwecke auszuwerten und zu verwenden. Erst danach wurde begonnen, digitale Systeme zum Tracking von Schiffen einzusetzen. Während die U.S. Coast Guard für diesen Zweck das bereits vorhandene Digital Selective Calling (DSC) um Funktionen zur Identifizierung und Positionsbestimmung eines Schiffes für Tracking und Management erweiterte, haben andere Länder und deren Behörden eigene Systeme entwickelt (vgl. [3]). Um einer weiteren Separierung der unterschiedlichen organisationsspezifischen und proprietären Systeme entgegenzuwirken, wurde auf Initiative der International Maritime Organization (IMO) begonnen, an einem gemeinsamen Standard für ein automatisches Identifizierungssystem zu arbeiten. Nach mehr als einem Jahrzehnt Entwicklungszeit trat 22 eine Ausrüstungsverpflichtung für das Automatic Identification System (AIS) in Kraft, das ab diesem Zeitpunkt für alle Schiffe galt, die aufgrund ihres Einsatzzwecks und/oder Größe sich an die Richtlinien der weltweit gültigen International Convention for the Safety of Life at Sea (SOLAS) (siehe Kapitel 2.3.2) zu halten hatten (vgl. [4], S. VII). Das Automatic Identification System basiert auf aktiven Transpondern, die autonom auf mehreren Kanälen im Time-Slot-Verfahren identifikations-, navigations- und sicherheitsrelevante Daten sen-

13 Kapitel. Einleitung den und empfangen. Im sog. Vessel-to-Vessel Modus werden diese Daten autonom von Schiff zu Schiff gesendet, dieser bietet dadurch Unterstützung zur Kollisionsvermeidung. Durch den Vessel-to-Shore Modus wird effektives Verkehrsmanagement von Seiten der Behörden (Coast Guards) möglich (vgl. [4], S. ). Aktuell fallen etwa mehr als 4. Schiffe in die SOLAS Bestimmungen und führen einen vorgeschriebenen Class A AIS Transponder mit an Bord (vgl. [5]). Seit 27 existiert neben dem Class A Standard für AIS auch ein Class B Standard, der es erlaubt, Geräte mit geringerem Funktionsumfang und daher kostengünstiger herzustellen. Damit wurde eine Low-Cost Option für AIS geschaffen, die nunmehr auch für die Privatschifffahrt bzw. Schiffe außerhalb der SOLAS Verordnung und damit für eine Zielgruppe interessant wurde, die auf einen großen Absatzmarkt für Class B Transponder hoffen lässt. Die kommerzielle Schifffahrt ist im Allgemeinen gut mit Navigationshilfen ausgestattet, so war der Gesetzeszwang primär verantwortlich für eine Kaufentscheidung eines Class A Transponders. Die Auswertung und besonders die Visualisierung der tatsächlich empfangenen Daten (wie z.b. exakte Position, Geschwindigkeit, Maritime Mobile Service Identity (MMSI), Heading, ) war vor allem auf behördlicher Ebene für Verkehrsmanagement Zwecke üblich. Durch die nun einsetzende massive Verbreitung von AIS Systemen wird eine Visualisierung der Daten an Bord weitaus nutzbringender. Visualisierung bedeutet hierbei die Positionierung von allen sendenden und in Empfangsreichweite befindlichen Stationen (Schiffe, Basisstationen, Aids To Navigation (ATN)) auf einer digitalen geografischen Karte (üblicherweise über einen Kartenplotter) direkt an Bord eines systemzugehörigen Schiffes. Dieser und unter allen vorrangige Nutzen ist dabei unmittelbar erkennbar: Kollisionswarnung, respektive Kollisionsvermeidung Es ist davon auszugehen, dass bei einer ständig wachsenden Verbreitung des Systems auch der Absatzmarkt für AIS-fähige Kartenplotter zumindest im selben Ausmaß ansteigt... Persönliche Motivation Vor einigen Jahren war ich an der Entwicklung eines AIS Class A Transponders beteiligt. Das vorliegende Projekt zur Entwicklung eines Low-Cost AIS Multifunktionsdisplays war für mich eine interessante Gelegenheit, bereits vorhandenes Wissen einzusetzen und das Thema Sicherheit in der Schifffahrt noch vertiefender zu erarbeiten. Mit diesem Projekt wird versucht, ein Produkt für einen Markt zu schaffen, der heute noch in der Hand von großen und bekannten Herstellern ist. Meine besondere Motivation an diesem Projekt liegt darin, durch Verwendung einer freien digitalen Weltkarte, im Gegensatz zu kommerziellen Kartenmaterialien, eine preislich attraktive Alternative zu bestehenden Systemen bieten zu können. Für die gesamte Entwicklung stehen nur sehr begrenzte finanzielle Mittel zur Verfügung, das 2

14 Kapitel. Einleitung Entwicklerteam besteht aus nur 3 Personen, einschließlich meine Person. Unter diesen Bedingungen, aber mit einem starken begeisterten Team, ein wettbewerbsfähiges Produkt zu entwickeln, auch darin liegt meine Motivation..2 Zielsetzung Primäres Ziel ist die Entwicklung eines Low-Cost AIS Kartenplotters. Der Kartenplotter soll in einem Marktsegment angeboten werden, in welchem das Gerät als preiswerte Alternative zu teureren namhafter Hersteller für den privaten Schiffs- oder Kleinyacht Besitzer aufgestellt wird. Um dies zu erreichen, soll nach Möglichkeit freies Kartenmaterial fixer Bestandteil des Geräts sein. Hardwaretechnisch muss der AIS Kartenplotter alle gesetzlichen Anforderungen für ein maritimes Gerät erfüllen, mit dem Ziel, an Bord installiert zu werden. Folgende Ziele werden in dieser Arbeit verfolgt: a) Entwicklung einer flexibel erweiterbaren Basissoftware für ein AIS Multifunktionsdisplay (dessen integrativer Bestandteil ein AIS Kartenplotter ist) auf einem eigens dafür entwickelten Embedded Computer System b) Analyse zur Tauglichkeit von geografischen Kartendaten aus dem OpenStreetMap (OSM) Projekt c) Verwertung von OSM Daten zur Kartenvisualisierung am Kartenplotter für den speziellen Anwendungsfall, dass diese Daten offline und Speicherplatz-optimiert am Gerät selbst zur Verfügung stehen d) Ausblick und Analyse zur Verwendung von vektorbasiertem kommerziellen Kartenmaterial von Drittanbietern Folgende Entwicklungsstufen des MFD-Prototypen werden im Umfang dieser Arbeit beschrieben: a) Erstellung einer Plugin-fähigen Basissoftware b) AIS Visualisierung mit Hilfe von Kartenmaterial über online erreichbaren Tile-Server c) Erstellung von lokalen (offline) Kartenressourcen zur Anzeige von Kartenmaterial (geografisch begrenzt) d) Offline Kartenvisualisierung aller notwendigen Meeres- und Flussgebiet und den dazugehörigen Küstenstreifen sowie Ufern aus OSM Daten 3

15 Kapitel. Einleitung Aus den genannten Zielen ergeben sich zwei spezifische Problemstellungen, die der Autor im Weiteren bearbeiten wird: Zum einen, wie die Benutzersoftware für ein AIS Multifunktionsdisplay auf einer speziell dafür neu entwickelten Embedded Linux Hardwareplattform entwickelt wird. Dabei gilt es unter anderem herauszufinden: Welches ist die passende Entwicklungsumgebung für Hardware und Betriebssystem, wie muss die Abarbeitung der programmatischen Aufgaben passieren und wie kann ein modernes und attraktives Benutzerinterface gestaltet werden, mit Hinblick auf die begrenzte Performance? Wie können die vorhandenen Peripheriegeräte für eine benutzerfreundliche Bedienung des Geräts eingesetzt werden? Wird dies erfolgreich gelöst ist der andere Schwerpunkt der Arbeit die Verwendung von OSM Kartenmaterial. Wie kann für dieses Projekt die gesamte maritime Welt als Kartenmaterial am Gerät selbst offline zur Verfügung gestellt werden? Wird aus OSM Daten (diese liegen primär als Daten im XML Format zum Download bereit) der vollständige Planet in allen Zoomstufen als.png Kachelen gerendert, werden mit aktuellem Stand der Datenbank einige TB an Daten generiert (vgl. [6], S. 77). Der verfügbare Speicher ist auf die Größe einer SD-Karte begrenzt, laut Vorgabe auf 64 GB. Konkret gilt zu untersuchen, wie mithilfe bestehender Rendering Software diese Vorgaben zu erreichen sind..2. Nicht-Ziele Die Entwicklung der Hardware ist nicht Teil dieser Arbeit. An dieser Stelle sei auf [7] verwiesen, das detailliert diesen Bereich beschreibt..3 Aufbau der Arbeit Die Arbeit besteht im Wesentlichen aus 5 Teilen. Die Einleitung, das aktuelle Kapitel, ist ein bündiger Einstieg in das Thema und veranschaulicht in kurzen Worten das Projektumfeld. Die Hintergründe und die Motivation des Autors, sowie die kommerzielle Motivation an dieser Arbeit werden erklärt. Die Ziele der Arbeit werden festgestellt, und Nichtziele konkretisiert. Im 2. Kapitel werden die Themengebiete, die für dieses Projekt Relevanz haben, vorgestellt und detailliert beschrieben. Es fasst den Stand der Technik für folgende Themen zusammen: AIS und Systemumfeld, Qt C++ Framework, Kartensysteme und OpenStreetMap. Abk. für Terrabyte ( TB = 24 Gigabyte (GB)) 4

16 Kapitel. Einleitung Das 3. Kapitel beschreibt den Softwareentwicklungsprozess. Es beginnt mit der Planung der Softwarearchitektur, die auch die Abgrenzung zu Fremdsystemen beinhaltet, listet die Anforderungen an das System auf und gibt Einblick in die praktische Durchführung anhand von repräsentativen Softwaremodulen. Wie das freie Kartenmaterial von OpenStreetMap für das Multifunktionsdisplay genutzt wird, steht in Kapitel 4. Es erklärt die notwendigen Schritte, wie Kartenmaterial aus der Geodatenbank von OSM gerendert werden kann. In besonderem widmet es sich der Methoden, wie aus den globalen Daten nur der maritime Teil extrahiert wird und wie die Vorgabe der reduzierten Speicherbelegung realisiert werden konnte. Das 5. Kapitel befasst sich mit der wirtschaftlichen Relevanz dieses Projekts, genauer, des entwickelten Produkts. Aufgrund einer Mitbewerberanalyse wird die mögliche Positionierung am Markt ermittelt und dabei Unterschiede, Stärken und Schwächen identifiziert. Das 6. und letzte Kapitel fasst die Arbeit nochmals zusammen. Die Problemstellungen, die im. Kapitel definiert wurden, werden ein weiteres mal überprüft und bewertet. Der Autor analysiert nach eingehender Behandlung der Thematik auch Gefahren und Risiken des Systems sowie dessen Chancen und wagt einen Ausblick in die Zukunft..4 Arbeitsmethode Ausgehend davon, dass sich FT-TEC für die Markteinführung eines AIS-fähigen Multifunktionsdisplays entschieden hat, wurde im Unternehmen selbst die Produktentwicklung gestartet. Der Autor wurde beauftragt, die komplette softwareseitige Benutzerschnittstelle zu implementieren. Der ISTZustand vor Beginn der Arbeit sind also die bereits weiter oben genannten Vorstellungen bzw. rudimentären Vorgaben eines Unternehmens für ein MFD, eine in Entwicklung befindliche Embedded Hardwareplattform und ein wachsender Markt, dessen Kenntnis von, respektive Bewusstsein für AIS unterstützte Steigerung der Sicherheit auf See größer wird. Als Erfolg zu werten, und damit der geplante SOLL-Zustand, ist in erster Linie, wenn eine konkurrenzfähige Software auf einer fertig entwickelten Embedded Hardware mit freiem Betriebssystem (Linux) implementiert werden kann OpenStreetMap als freie und damit kostengünstige Variante für digitales Kartenmaterial für das MFD nutzbar gemacht werden kann 5

17 Kapitel. Einleitung Die Methoden die zur Erarbeitung dieser Masterarbeit angewandt werden, sind die nachstehend angeführten Punkte: Literaturrecherche zum thematischen Umfeld und zum Stand der Technik Internetrecherche Recherche in Unternehmen und Befragung von Personen, die im selben Umfeld tätig sind Besuch von Fachmessen Einsatz von eigener Erfahrung und Vorstellung Vergleich ähnlicher Produkte Konzepterstellung durch Zusammenführung von persönlichem Wissen, persönlicher Erfahrung und Rechercheergebnissen Verifizierung der Ergebnisse durch definierte Tests 6

18 Kapitel 2. Stand der Technik und Umfeld Kapitel 2 Stand der Technik und Umfeld 2. Einleitung Zu Beginn dieses Kapitels wird das Umfeld beschrieben, für das AIS entworfen wurde und für Schiffe laut SOLAS Kapitel V Regulierung zur verpflichtenden Ausrüstung wurde. Es existieren eine große Menge an Recommendations und Guidelines für die Schifffahrt. Im Folgenden wird das Einsatzgebiet von AIS innerhalb der Vessel Traffic Services beschrieben, womit auch ein Überblick über andere Technologien gegeben wird, die sowohl vor der Einführung von AIS, als auch danach parallel dazu, zur Gewährleistung und Verbesserung der Sicherheit auf See zum Einsatz kommen. Weiters wird der aktuelle Stand der Technik für die projektrelevanten Themen und Technologien erarbeitet. Diese sind die folgenden Punkte: Automatic Identification System (AIS) Digitale Kartensysteme und Geographic Information System (GIS) OpenStreetMap und OpenSeaMap Qt Entwicklungsframework 2.2 Vessel Traffic Services Bereits in der Einleitung dieser Arbeit wurde die Notwendigkeit von Verkehrskontrollsystemen in der Schifffahrt aufgezeigt. Die International Maritime Organisation (IMO) definiert die Notwendigkeit von Vessel Traffic Services (VTS): The purpose of vessel traffic services is to improve the safety and efficiency of navigation, safety of life at sea and the protection of the marine environment and/or the adjacent shore area, worksites and offshore installations from possible adverse effects of maritime traffic. [8] Das grundlegende Ziel von VTS ist demnach durch Unterstützung bei der Navigation von Schiffen, diese sicherer zu machen, und die Bewahrung von Leben und Umwelt durch gezieltes Traffic Management zu gewährleisten. Es wird unterschieden zwischen Port (Hafen-) VTS und Coastal (Küsten-) VTS, grundsätzlich gilt aber, dass VTS Einrichtungen nur in Küstennähe anzutreffen sind. Diese Einrichtungen werden 7

19 Kapitel 2. Stand der Technik und Umfeld von dafür bestimmten behördlichen Autoritäten betrieben (wie z.b. U.S. Coast Guard, oder Port of London Authority). 22 wurde eine EU Direktive (22/59/EC) erlassen, in der geregelt wird, dass bis Ende 27 alle in Frage kommenden Mitgliedstaaten entsprechende Installationen implementieren müssen, um ein VTS gemäß der IMO Resolution A.857(2) [8] zu betreiben (vgl. [9]). Die Vorteile von VTS sind, dass durch Identifizierung und Monitoring von Schiffen, die sich innerhalb der VTS Region bewegen, die Schiffsbewegungen gezielt gesteuert und navigationsrelevante Information und Hilfestellungen angeboten werden können (vgl. [8], S. 4). Folgend genannte Dienste werden von VTS implementiert: Information Service (INS) Das Information Service bietet für Schiffe innerhalb der VTS Region relevante Informationen, die zu definierten Zeiten, aber auch auf Anfrage, ausgesendet werden. Solche Informationen sind z.b. (vgl. [], S.): Aktuelle Verkehrssituation (Position und Absichten anderer Schiffe, Grenzen und Funkfrequenz der VTS Region) Warnungen bezüglich Navigation (wie das Vorhandensein gefährlicher Wracks, oder Hindernisse im Allgemeinen) Meteorologie und meteorologische Warnungen (Windgeschwindigkeit, Wellenhöhe, Sturm, Tsunami) Verfügbarkeit von elektronischen Navigationshilfen (wie z.b. GNSS2, DGPS3 oder AIS) Traffic Organization Service (TOS) Das Traffic Organization Service ist ein Dienst um gefährliche Verkehrssituationen zu vermeiden. Es betrifft das aktive Verkehrsmanagement, das besonders in Situationen bei hoher Verkehrsdichte tragend wird (vgl. [], S. 2). Navigational Assistance Service (NAS) Dieses Service leistet Hilfe für die On-Board Navigation durch aktive Unterstützung des Entscheidungsprozesses, u.a. durch gezielte Instruktionen. Vor allem in schwierigen Situationen, betreffend Navigation oder meteorologische Umstände, ist dieses Service von Bedeutung. Unterstüt2 3 Abk. für Global Navigation Satellite System (z.b. GPS, GLONASS, Galileo) Abk. für Differential GPS 8

20 Kapitel 2. Stand der Technik und Umfeld zung passiert entweder auf Anfrage, oder wenn vom VTS Operator eine Gefahrensituation erkannt worden ist (vgl. [], S. 4). Damit diese Dienste angeboten werden können, muss der VTS Operator ein vollständiges Bild der Verkehrssituation erfassen. Dafür sind zumindest die folgenden Informationen notwendig (vgl. [], S. 25): Daten über die Verkehrssituation, wie Schiffsposition, Bewegungsrichtung und -ziele sowie der eindeutigen Bezeichnung, der Identität der Schiffe Daten über die zu befahrende Region (Fahrrinne), wie z.b. aktuelle meteorologische und hydrologische Verhältnisse und der Status von Aids to Navigation Daten von Schiffen entsprechend den Anforderungen gemäß Reporting Richtlinien Abbildung zeigt das Verwaltungszentrum (Vessel Traffic Center, VTC) des VTS Port of London (vgl. [2]): Abbildung : Vessel Traffic Center mit Operator, Port of London, [2] Das wichtigste Kommunikationsmittel zur Erfassung der Schiffsdaten und für den Betrieb von VTS ist der VHF Sprechfunk. Das IMO Standard Ship Reporting System [3] legt fest, in welcher 9

21 Kapitel 2. Stand der Technik und Umfeld Form diese Daten übermittelt werden. Neben VHF Funk sind Radar und CCTV (Videokameras) elementare Komponenten zur Überwachung einer VTS Region. Das Jahr 22 war der Beginn der Ausrüstungsverpflichtung für AIS, der laut SOLAS Regulierung betroffenen Schiffe (siehe Kapitel 2.3.2). Seit diesem Zeitpunkt hat AIS, in seiner Funktion als digitales automatisches Identifizierungssystem, als Schlüsseltechnologie für VTS eine essentielle Rolle eingenommen. Mittels AIS ist es nun möglich, das Bild der Verkehrslage ständig aktuell zu generieren. Der äußerst aufwendige Prozess, Schiffsidentitäten und deren Positionen manuell zusammenzuführen und dieses Bild aktuell zu halten, ist durch die Einführung von AIS nun automatisiert worden. 2.3 AIS und Komponenten Nachdem bereits die einleitende Beschreibung der Vessel Traffic Services den immensen Vorteil einer automatischen Identifizierung von Schiffen für das Verkehrsmanagement gezeigt hat, wird in diesem Kapitel das Automatic Identification System aus technischer Sicht näher beschrieben Was ist AIS AIS ist ein Kommunikationssystem, das über VHF auf registrierten Kanälen Navigationsdaten austauscht. Es basiert auf einem offenen, unverschlüsselten Protokoll, über das Daten autonom gesendet und empfangen werden, ohne Interaktion von Schiffs- oder Operator Personal. Neben diesem autonomen Modus sind Möglichkeiten vorgesehen, dass kurze, sicherheitsrelevante Nachrichten auch auf menschliche Interaktion hin und applikationsproprietäre Nachrichten gesendet werden können (vgl. [4], S. 5). Die Daten, die autonom generiert und via Broadcast übertragen werden, sind a) dynamische Daten, die über zum Schiff gehörige Sensoren gesammelt werden und b) statische und fahrtbezogene Daten, die über manuelle Eingabe gesetzt werden. Tabelle zeigt einige typische Datensätze dieser beiden Gruppen (vgl. []):

22 Kapitel 2. Stand der Technik und Umfeld Dynamische Daten Static and Voyage related Daten GPS Position Maritime Mobile Service Identity (MMSI) Geschwindigkeit über Grund (SOG4) Call Sign Kurs über Grund (COG5) Ziel der Fahrt (Destination) Heading Schiffsabmessungen Tabelle : Typische AIS Daten (Auswahl) [eigene Darstellung] Diese Daten werden vom Empfänger verarbeitet und können auf einem Display, im Allgemeinen ein Electronic Chart Display and Information System (ECDIS), visualisiert werden. Aktuelle Positionsdaten werden dabei mit der jeweiligen Schiffsidentifikation der empfangenen AIS Stationen geografisch referenziert und auf einer digitalen Karte abgebildet. Durch den Einsatz von AIS soll die Navigation auf See sicherer werden und der Zustand der Umwelt bewahrt werden, indem Unfälle durch gezielte Unterstützung der Navigationsaufgaben vermieden werden. AIS hat folgende funktionale Anforderungen:. Kollisionsvermeidung im Schiff - Schiff Kommunikationsmodus 2. Navigationshilfe im Schiff - Aids to Navigation (AtoN) Modus 3. Tool für verbessertes Trafficmanagement in VTS im Schiff - Basisstation Modus In Notfallsituationen ist AIS eine Technologie unter anderen 6, die einen effizienten Einsatz von Search and Rescue (SAR) erleichtern (vgl. [4], S. 6) AIS Ausrüstungsverpflichtung SOLAS V Die Ausrüstung mit einem an Bord eines Schiffes installierten AIS System ist für Schiffe von bestimmter Art, Einsatzzweck und Größe gesetzlich geregelt. Diese gesetzliche Regelung ist Bestandteil der International Convention for the Safety of Life at Sea (SOLAS). Die SOLAS Konvention wird als das wichtigste international gültige Abkommen über die Sicherheit von Handelsschiffen gesehen. Zum ersten Mal in Kraft gesetzt wurde es 94, nach der Titanic Katastrophe. Die heute gültige Version ist die Konvention von 974, die einer ständigen Aktualisierung unterworfen ist. Aufgabe der SOLAS Konvention ist es, die minimalen Standards für die Konstruktion, die Aus Abk. f. Speed over Ground Abk. f. Course over Ground Hierzu zählen auch Digital Selective Calling (DSC), oder Emergency Position-Indicating Radio Beacons (EPIRBs)

23 Kapitel 2. Stand der Technik und Umfeld rüstung und den Betrieb von Schiffen, in Bezug auf deren Sicherheit, festzulegen (vgl. [5], S. 288). In Kapitel V, Regulation 9 der SOLAS Konvention wird geregelt, welche Schiffe verpflichtend mit AIS Systemen ausgerüstet werden müssen. Diese Regelung trat mit. Juli 22 in Kraft und umfasst alle Schiffe, die folgende Kriterien erfüllen: Schiffe ab 3 Bruttoregistertonnen (auch Gross-Tonnage (GT)), die in internationalen Gewässern verkehren Handelsschiffe ab 5 GT, die nicht in internationalen Gewässern verkehren Alle Personentransportschiffe Die SOLAS Konvention gibt auch die Termine vor, bis wann die Nachrüstung auf bereits existierenden Schiffen durchgeführt werden musste (siehe Kapitel V, Regulation Originalwortlaut im Anhang, Kapitel 7.4). Von lokalen Behörden (Authorities) kann die Verpflichtung zur Ausrüstung auch auf andere Schiffe, die nicht in die SOLAS Konvention fallen (z.b. Schiffe unter 3 GT), erweitert werden (vgl. [6], S. 372, 373) AIS System Als AIS System wird die Gesamtheit aller Komponenten und Dienste bezeichnet, die Teil des AIS Kommunikationsnetzwerks sind. Abbildung 2 zeigt einen Überblick dieses Systems. Der linke Teil der Grafik zeigt das Shore Netzwerk, also die Küsten-Infrastruktur, die, wie im Fall von VTS, von lokalen Behörden betrieben wird. Der rechte Teil der Grafik zeigt den Einsatz der AIS Stationen. AIS Stationen sind mit Sende- und Empfangseinheit ausgestattete Geräte. 2

24 Kapitel 2. Stand der Technik und Umfeld Abbildung 2: AIS System, [7] Die Recommendation ITU-R M.37- definiert die technischen Merkmale sowie Kommunikationsprotokoll und Netzwerkzugang im maritimen VHF Band. Es wird unterschieden zwischen mobilen und fixen Stationen (vgl. [7], S. 28): Mobil: Class A und Class B Schiffstransponder (siehe Kapitel 2.3.6) Aids To Navigation7 (AtoN) Transponder Search and Rescue (SAR) Lufteinsatzkräfte Fix: 7 AIS Base Station AtoN sind fix installierte Navigationshilfen, meist (beleuchtete) Boyen oder Leuchttürme 3

25 Kapitel 2. Stand der Technik und Umfeld AIS Simplex/Duplex Repeater Über eine standardisierte Schnittstelle können die auf Schiffen installierten Transponder an ein kompatibles Display angeschlossen werden. Diese, im allgemeinen Sinn, als AIS Display bezeichnete Anwendung ist z.b. ein Radar oder ECDIS. Das Entwicklungsziel des Projekts dieser Arbeit beschränkt sich auf AIS Displays für Class B Stationen. Im folgenden Abschnitt wird das Kommunikationsschema im AIS System und der Aufbau eines AIS Transponders beschrieben Kommunikationssystem AIS Geräte sind vergleichbar mit Mobiltelefonen, in der Hinsicht, dass AIS Geräte wie auch Mobiltelefone Nachrichten entweder von einem Gerät zu einem anderen, oder zu einer Gruppe senden können. Der Unterschied ist, dass AIS Geräte speziell definierte Nachrichten, nach einem Reporting-Mechanismus, regelmäßig und autonom versenden. Ein Transponder besitzt Schnittstellen zu an Bord befindlichen Sensoren, wie z.b. Gyro Sensor, Heading Sensor, GPS, oder Rate-of-Turn Sensor. Über diese Schnittstellen werden spezifische Daten gesammelt, verarbeitet, und über ein definiertes Nachrichtenschema über den sog. VHF Data Link (VDL) an, im Allgemeinen alle, Stationen gesendet, die sich in Empfangsreichweite befinden. Weiters muss ein Transponder eine Schnittstelle zu einem externen Display haben. Abbildung 3 zeigt den (vereinfachten) funktionalen Aufbau eines Class A AIS Transponders: Abbildung 3: Blockdiagramm AIS Class A Transponder [eigene Darstellung] 4

26 Kapitel 2. Stand der Technik und Umfeld Zur Datenübertragung über VHF werden Datenpakete mit 96 Bits pro Sekunde GMSK 8 moduliert abwechselnd über 2 Kanäle gesendet. Die Standardfrequenzen sind 6,975Mhz (AIS) und 62,25Mhz (AIS2), diese können aber von lokalen Behörden über spezielle Kanal-Management Nachrichten geändert werden. Ähnlich wie die meisten Mobiltelefone nutzt das AIS System ein Time-Division Multiple Access (TDMA) Kommunikationsprotokoll. Das bedeutet, dass die benutzte Frequenz in definierte Zeitschlitze (Slots) aufgeteilt wird. Es gibt 225 Slots pro Minute (ein Frame), je Slot ist ein Zeitfenster von 26,6 ms vorgesehen, innerhalb welchem Protokollpakete gesendet werden können. Die Größe der Datenpakete je Slot beträgt bei der Baudrate von 96 Bits/s 256 Bits (vgl. [8]). Abbildung 4 zeigt den Aufbau eines AIS Protokollpakets. Die Protokoll Struktur basiert auf der in [9] definierten High-level data link control (HDLC) Datenpaket Struktur. Abbildung 4: AIS Protokollpaket (vgl. [8], S. 2) [eigene Darstellung] Die meisten AIS Nutzdaten (AIS Nachrichten/Messages) sind nicht länger als 68 Bits, können also innerhalb eines Slots übertragen werden. Es gibt aber auch sog. Multi-Slot-Nachrichten, die für die Übertragung mehrere Slots benötigen. Es werden 4 Zugangsmethoden zum VHF Datenlink im Zeitschlitzverfahren unterschieden (vgl. [4], S. 8):. SOTDMA Self-Organised TDMA ist die Standard Zugangs-Methode für mobile Stationen. Anhand der anzuwendenden Reporting-Rate werden Übertragungen zeitlich geplant und zukünftige Slots reserviert. Durch vormaliges Lauschen am Frequenzkanal, können für die Übertragung freie Slots ermittelt werden. 2. RATDMA Random Access TDMA wird für spontane Übertragungen verwendet. 3. FATDMA Fixed Access TDMA wird von Stationen verwendet, die für die Übertragung Slots verwen- 8 Abk. f. Gaussian minimum shift keying 5

27 Kapitel 2. Stand der Technik und Umfeld den, die speziell für diese Nutzung fix reserviert sind. Nachrichten von Basisstationen können über FATDMA gesendet werden. 4. CSTDMA Carrier Sense TDMA wird von Stationen angewandt, die nur auf freien Slots senden, und keine Slots für Übertragungen reservieren dürfen, wie z.b. Class B Geräte. Abbildung 5 visualisiert den Vorgang des SOTDMA Zugangsschemas: Abbildung 5: AIS TDMA Übertragungsschema, [] Bei jedem Sendevorgang von Positionsnachrichten (diese werden in regelmäßigen Intervallen gesendet, u.a. abhängig von Geschwindigkeit und Kursänderung, siehe Tabelle 2) wird automatisch ein zukünftiger Slot für die nächste zu sendende Positionsnachricht reserviert. Nachstehende Tabelle listet die für die vorherrschende Situation anzuwendenden Intervalle für die Übermittlung der dynamischen Positionsnachrichten auf. Sofern nicht anders angegeben, beziehen sich die Einträge auf mobile Class A AIS Stationen im autonomen Betriebsmodus: 6

28 Kapitel 2. Stand der Technik und Umfeld Zustand Reporting Intervall Schiff vor Anker, oder vertaut, oder Geschw. < 3 Knoten 3 Minuten Schiff vor Anker, oder vertaut, oder Geschw. > 3 Knoten Sekunden Schiff Geschw. -4 Knoten Sekunden Schiff Geschw. -4 Knoten und Kursänderung 3 /3 Sekunden Schiff Geschw Knoten 6 Sekunden Schiff Geschw Knoten und Kursänderung 2 Sekunden Schiff > 23 Knoten 2 Sekunden Schiff > 23 Knoten und Kursänderung 2 Sekunden Class B 9 Geschw. < 2 Knoten 3 Minuten Class B Geschw. > 2 Knoten 3 Sekunden SAR Lufteinsatzkräfte Sekunden AtoN 3 Minuten Basis-Station Sekunden Tabelle 2: Reporting Intervalle (vgl. [8], S. 4) [eigene Darstellung] Die Intervalle können von diesen Vorgaben abweichen, wenn einer mobilen Station per Assignment (z.b. durch eine Basisstation) eine höhere Update-Rate zugewiesen wird. Neben den Intervallen zum autonomen Senden der dynamischen Positionsdaten, sind die Sendeintervalle für andere schiffs- bzw. fahrtbezogene Daten wie folgt geregelt (vgl. [8], S. 3): Statische Informationen (Static Information): alle 6 Minuten, oder bei Request Fahrtbezogene Informationen (Voyage related): alle 6 Minuten, oder bei Request Sicherheitsrelevante Informationen (Safety related): bei Bedarf Der Datenaustausch erfolgt in organisatorisch zusammengefassten Datensätzen, den sog. AIS Nachrichten. Mit aktuellem Stand sind deren insgesamt 27 unterschiedliche definiert. Eine tabellarische Übersicht aller AIS Nachrichten wurde dem Anhang beigefügt (siehe Kapitel 7.). Jede dieser Nachrichten beinhaltet unter anderen Daten, die Nachrichten Kennung (-27) und eine eindeutige Benutzer Identifikation (MMSI). Exemplarisch wird in nachfolgender Tabelle der Aufbau eines Class B Positionsreports (Message 8) dargestellt: 9 Hier gemeint: Class B Stationen im Carrier-Sense TDMA Funktionsmodus 7

29 Kapitel 2. Stand der Technik und Umfeld Parameter Bits Beschreibung Message ID 6 Nachrichten Identifier (=8) Repeat Indicator 2 Reserviert für Repeater, zum Anzeigen, ob Nachricht bereits weitergeleitet wurde User ID 3 MMSI Nummer Spare 8 Nicht verwendet SOG Speed over ground, Geschwindigkeit über Grund Position Accuracy Indikator für Positionsgenauigkeit Longitude 28 Longitude, Längengrad Latitude 27 Latitude, Breitengrad COG 2 Course over ground, Kurs über Grund True heading 9 True heading Time stamp 6 UTC Sekunde bei Senden der Nachricht Spare 2 Nicht verwendet Class B unit flag CSTDMA/SOTDMA Modus (= für CSTDMA) Class B display flag Integriertes Display? Class B DSC flag DSC integriert? Class B band flag VHF spezifisch Class B Message 22 flag Kanal Management möglich? VHF spezifisch Mode flag Autonomer/Assigned Modus RAIM flag Flag zur Positionsbestimmung Communication state 2 VHF spezifisch Summe Bits 68 Nachricht benötigt einen Slot zum Senden Tabelle 3: AIS Message 8 Class B Positionsnachricht (vgl. [8], S. 2) Schnittstelle zu externen Applikationen Die am VDL empfangenen sowie gesendeten Nachrichten werden über eine IEC662-2 (auch bekannt als NMEA-83) Schnittstelle an externe Applikationen, wie ein externes Display, weitergereicht (siehe Abbildung 3). 8

30 Kapitel 2. Stand der Technik und Umfeld NMEA-83 definiert ein serielles asynchrones Interface mit einer Baudrate von 384 Bits/s, 8 Datenbits und Stoppbit. Alle übermittelten Daten sind als ASCII Zeichen zu interpretieren. Die Protokollpakete, die sog. Sentences, sind maximal 82 Zeichen lang, wobei 79 Nutzzeichen innerhalb dem Startzeichen $ (oder! ) und den Endezeichen <CR><LF> eingebettet sind. Ein Datensatz besteht aus einem oder mehreren Datenfeldern, die mittels Komma getrennt sind (vgl. [2], S. 9). Ein gültiger NMEA-83 Sentence beinhaltet folgende Elemente: ASCII Beschreibung $ oder! Startzeichen <address field> Talker ID und Sentence Formatter, <data field> Ein oder mehrere Datenfelder, <data field>... * <checksum field> Checksumme <CR><LF> Endezeichenkette Tabelle 4: Aufbau eines NMEA-83 Protokollsatzes [eigene Darstellung] AIS Nachrichten, die über den VDL empfangen wurden, werden als VDM Sentence (VHF Data-link Message) an die externe Schnittstelle (IEC662-2/NMEA-83) gesandt. VDM ist der Formatter, welcher festlegt, wie die nachfolgenden Datenfelder zu interpretieren sind. Startzeichen für die Zeichenkette ist das Rufzeichen!, das (im Unterschied zu dem $ Zeichen) angibt, dass sich gekapselte ASCII-kodierte Binärdaten in dem Sentence befinden. Beispielsweise sieht der gültige Protokollsatz für einen VDM Sentence folgendermaßen aus:!aivdm,,,,a,b6cdcmt3`tba35f@v9fahi7kp6,*58<cr><lf> Mit Bezug auf Tabelle 4 ist dieser Beispielsatz wie folgt aufgebaut:!...startzeichen AI...Talker ID (AI => AIS Station) VDM...Sentence Formatter (VHF Data-link Message)...Datenfeld: Total number of sentences to transfer message...datenfeld: Sentence number A...Datenfeld: AIS Kanal B6CdC[...]...Datenfeld: Enkapsulierte Binärdaten (AIS VDL Nachricht) 9

31 Kapitel 2. Stand der Technik und Umfeld...Datenfeld: Number of fill bits *58...Checksumme <CR><LF>...Endezeichen Im Binärdatenteil ist im angeführten Beispielsatz eine über den Kanal A empfangene AIS Nachricht 8 (Class B Positionsreport, Aufbau siehe Tabelle 3) enthalten. [2] definiert den Mechanismus, wie der Binärdatenteil eines VDM Sentences zu dekodieren ist. Jedes ASCII-Zeichen repräsentiert ein 6-bit Binärfeld. Das entsprechende Binärfeld kann nach einem mathematischen Schema aus dem ASCII Zeichen berechnet werden (siehe Anhang, Kapitel 7.2). Als ersten Schritt werden die ASCII Symbole in den entsprechenden 6-bit Binärcode konvertiert. Der resultierende Binär-Stream muss dann anhand der in [8] definierten AIS Message Struktur interpretiert werden. Tabelle 5 zeigt den dekodierten Binär-Stream für den Beispielsatz. B6CdCmt3`tba35f@V9faHi7kP6 ASCII 6-bit Binärdaten B 6 C d C m t 3 ` t b a Tabelle 5: ASCII zu 6-bit Konvertierung [eigene Darstellung] Exemplarisch werden die ersten 5 Datenfelder der in Tabelle 5 dekodierten AIS Message 8 berechnet. Die Interpretation der Daten ergibt sich aus der Definition in Tabelle 3 (Message 8). 2

32 Kapitel 2. Stand der Technik und Umfeld Bitposition Bits Binärwert Parameter Message ID (Wert: 8) Repeat Indicator (Wert: ) MMSI (Wert: 42332) Spare (Wert: default) Speed Over Ground (Wert: 4 =>.4 Knoten)... Tabelle 6: Werte der AIS Message 8 für Beispiel NMEA Sentence [eigene Darstellung] Class A versus Class B AIS Transponder Schiffe, die der SOLAS Verordnung unterliegen, müssen mit Class A AIS Transponder ausgerüstet werden. Transponder nach dem Class B Standard haben geringere technische Anforderungen und können somit kostengünstiger produziert und verkauft werden. Zielgruppe für diese Geräte ist die Freizeit- und Sportschifffahrt. Die nachfolgende Tabelle stellt die Unterschiede in den technischen Anforderungen der beiden Spezifikationen gegenüber (vgl. [8]): Eigenschaft Class A Class B Erklärung Sendeleistung 2.5 W 2W Class B Transponder haben durch geringere Sendeleistung auch eine niedrigere Reichweite. Kommunikationsschema SOTDMA CSTDMA Class A Systeme reservieren Übertragungskanäle, während Class B Geräte nur auf freien Kanälen senden dürfen, solange die priorisierte Kommunikation nicht gestört wird. Externe Inputs GPS, Heading, ROT Keine Class B Transponder haben keine Schnittstellen zu externen Geräten. Sie verfügen über einen eingebauten GPS Empfänger. Positionsupdaterate min. 2 s min. 3 s Die minimalste Updaterate für Positionsnachrichten beträgt bei Class B Geräten nie weniger als 3 Sekunden (siehe Tabelle 2). 2

33 Kapitel 2. Stand der Technik und Umfeld 2.4 OpenStreetMap 2.4. Einleitung OpenStreetMap ist eine freie geografische Datenbank. Das Projekt hat zum Ziel, möglichst alle geografischen Features der Welt in einer einzigen Datenbank zusammenzufassen. Im Unterschied zu einer Menge anderer existierender Anbieter und deren Services, die frei zugängliche Karten anbieten, dürfen die Daten von OpenStreetMap kopiert, geändert und weiterverteilt werden ohne Einschränkungen. Die Daten dürfen selbst Offline verwendet und nach Bedarf so modifiziert werden, um daraus Karten(layouts) entsprechend den eigenen Wünschen zu generieren. Die nachfolgenden Abschnitte dieses Kapitels geben eine Einführung für die Arbeit mit geografischen Informationen, bevor das Projekt OpenStreetMap einer genaueren Betrachtung unterzogen wird GIS Geographic Information System (GIS) nennt sich die Disziplin, geografische Daten zu sammeln, zu speichern, zu analysieren und in verschiedensten Arten zu präsentieren. Die Verarbeitung dieser Daten passiert digital mit dem Computer. GIS unterstützt den Prozess der Kartographie und wurde damit hauptsächlich auf behördlicher Ebene eingesetzt. Es gibt eine große Anzahl an existierenden GIS Produkten, sowohl Open Source als auch kommerziell. Das Environmental Systems Research Institute (ESRI) [22] etwa ist mit dem Produkt ArcGIS und einem gewaltigen Pool an geografischen und demografischen Daten einer der großen kommerziellen Anbieter von GIS Software. Darüberhinaus wurde das bekannte Shapefile Format, zum Speichern von geografischen Vektordaten, von ESRI eingeführt (vgl. [23]). Neben Comma-separated ASCII sind Shapefile Daten die am weitest verbreitetsten Formate zum Austausch von geografischen Daten und für den Import in GIS Datenbanken (vgl. [24], S. 2). OpenStreetMap im Gegensatz verwendet eigene Datenformate und eigene Software zum Erstellen und Austausch von Geodaten. Die OpenStreetMap Datenbank wird von Freiwilligen Mappern erstellt und erweitert, daher sollen Software und Formate intuitiv und einfach zu benutzen sein. Das System und im Speziellen die Ontologie, die Einteilung und Kategorisierung der Features, ist weitestgehend offen und nicht fixen Regulativen unterworfen. Auch wenn OSM eigene Formate verwendet, existieren Programme und Utilites, um OSM Daten in die für GIS üblichen Formate, wie Shapefiles, zu konvertieren oder in z.b. PostGIS zu importieren (vgl. [6], S. 7). Als Bindeglied für unterschiedliche Systeme in der GIS-Welt wurden vom Open Geospatial Consortium (OGC) offene Standards für den Datenaustausch, sowie für Dienste und die Verarbeitung von GIS Daten, definiert. 22

34 Kapitel 2. Stand der Technik und Umfeld OGC und Simple Features Access Das Open Geospatial Consortium (OGC) [25] ist ein internationales Konsortium aus über 4 Organisationen, Behörden und universitären Einrichtungen. Neben Organisationen wie der Internet Engineering Task Force (IETF) oder dem World Wide Web Consortium (W3C) ist es Ziel des OGC freie, öffentlich zugängliche Interface Standards zu entwerfen und zu publizieren. Interoperabilität zwischen unterschiedlichen Systemen, Plattformen und Herstellern kann nur über freie Standards gewährleistet werden. OGC forciert Interoperabilität mit Standards, die den Zugriff, die Bearbeitung und den Austausch von raumbezogenen Daten im Web regeln (vgl. [25]). Der OpenGIS Simple Features Access (SFA) Standard definiert eine einheitliche Architektur für häufig verwendete Objekte zur Beschreibung von 2 dimensionalen Geometrien. In der GIS-Welt werden reale Objekte wie Points of Interest (POIs), Straßen, Stadtbezirke, oder Gebäude durch Punkte, Linien, Polygone oder Gruppierungen dieser elementaren Datentypen dargestellt. Eine Basisklasse Geometry hat abgeleitete Klassen für Point, Curve, Surface und GeometryCollection (vgl. [26]). Abbildung 6 zeigt die Architektur der Simple Feature Geometry. Abbildung 6: OpenGIS Simple Features Access Klassenhierarchie, [26] 23

35 Kapitel 2. Stand der Technik und Umfeld Geometry ist die abstrakte Basisklasse für die Referenzarchitektur. Sie legt grundlegende Methoden der davon abgeleiteten instanziierbaren Klassen fest, wie z.b. Methoden zum Auffinden von Beziehungen zwischen Geometrien (wie Überschneidungen, oder die Distanz zwischen Objekten) oder zum Lesen von Eigenschaften des instanziierten Objekts (wie Spatial Reference System, oder Objektdimension). SFA Objekte können (z.b. Punkt), (z.b. Linie) oder 2 dimensionale (z.b. Polygon) Geometrien sein. Während ein Point, der eine Position im Koordinatenbezugssystem repräsentiert, eine instanziierbare Klasse ist, sind Curve und Surface abstrakte Klassen, die offene Linienformen, respektive geschlossene geografische Bereiche definieren. In der Abbildung der Klassenhierarchie wird ersichtlich, dass alle - und 2-dimensionalen Geometrieobjekte durch 2 oder mehrere Points aufgebaut sind. GeometryCollection Klassen sind Klassen zur Gruppierung von einzelnen geometrischen Elementartypen. So ist z.b. die Klasse MultiPoint eine Collection, also eine Gruppierung, für 2 oder mehrere Point Objekte (vgl. [26], S. 3-2). Jedes Objekt ist einem Kartenbezugssytem, einem sog. Spatial Reference System zugewiesen. Das nächste Kapitel gibt einen Einblick in Koordinatensysteme und Projektionen Spatial Reference System Kartographie ist die Wissenschaft, die Erde auf flachen Karten darzustellen. Da es hierfür eine Vielzahl an unterschiedlichen Berechnungsmethoden gibt, können Positionsdaten nur in Verbindung mit einem Spatial Reference System (SRS) sinnvoll miteinander in Verbindung gebracht werden. Das SRS gibt Auskunft über das verwendete Koordinaten-Referenz-System und die angewandte Projektion. Die Erde sieht, aus dem Weltraum betrachtet, einer Kugel ähnlich, in Wirklichkeit ist sie aber ein Geoid, der keine homogene Oberfläche aufweist (vlg. [24], S. 54). Damit über diesen Geoid ein Koordinatensystem gespannt werden kann, muss dessen Oberfläche definiert werden. Um geometrische Brechnungen zu beschleunigen, wird aus dem komplexen Geoid ein vereinfachtes Modell generiert der Referenz-Ellipsoid. Der heutzutage Quasi-Standard eines weltumspannenden Koordinatensystems, das sehr hohe regionale Genauigkeit aufweist, ist das World Geodetic System (WGS) 84, basierend auf dem WGS 84 Ellipsoid. Durch seine globale Einsatzfähigkeit wird es universell in der Navigation verwendet. Das Global Positioning System (GPS) basiert auf WGS 84. Das WGS 84 Datum wird in Longitude/Latitude Notation angegeben. Die Erde besteht dabei WGS 84 setzt sich neben dem Referenz-Ellipsoid auch aus einer Geoid Komponente zusammen. Über ein Gravitationsmodel kann somit der nominale Meeresspiegel bestimmt werden (vgl. [24], S. 57) 24

36 Kapitel 2. Stand der Technik und Umfeld aus 36 Längengraden und 8 Breitengraden. Die Längengrade, die sog. Meridiane, verlaufen senkrecht zum Äquator, jeweils von -8 - West und - 8 Ost. Die Breitengrade verlaufen parallel zum Äquator, von -9 - Süd bis - 9 Nord. Mit Datum und Koordinatenreferenzsystem kann jeder Punkt auf der Weltkugel ausreichend identifiziert werden. Die European Petroleum Survey Group (EPSG) hat ein Nummerierungssystem für Spatial References eingeführt. In diesem Nummerierungsstandard hat WGS 84 die Nummer 4326, weshalb EPSG:4326 gleich bedeutend mit WGS 84 ist. Dies ist das Standardreferenzsystem von OpenStreetMap (vgl. [24], S ). Der andere Teil, der ein SRS vollständig definiert, ist die verwendete Projektion. Eine 2D Projektion, oder auch Kartennetzentwurf, ist notwendig a) um den Geoid Erde auf eine flache Karte zu transformieren und b) weil eine planare (euklidische) Geometrie mathematische und visuelle Vereinfachung mit sich bringt. Mathematisch gesehen ist es offensichtilch einfacher, die Fläche einer Geometrie in der Ebene des kartesischen Koordinatensystems zu berechnen, als dessen Fläche auf der Oberfläche eines Ellipsoids. Es existieren eine Reihe von Projektionsarten, auf die hier nicht näher eingegangen werden soll. Wichtig ist, dass es keine ideale Projektionsmethode gibt, vielmehr kann jede Methode nur eine der folgenden Eigenschaften, die sich gegenseitig ausschließen, gut erreichen: Längentreue Darstellung Winkeltreue Darstellung Flächentreue Darstellung Der für die Web-Karte von OpenStreetMap angewandte Kartennetzentwurf ist die sog. Google Mercator Projektion, EPSG:3875 (od. früher 993). Hierbei handelt es sich um eine winkeltreue Zylinderprojektion, die sich gut für Webkarten und zur Navigation eignet, da für den ganzen Planeten das selbe SRS verwendet werden kann. Die Meridiane besitzen immer den gleichen Abstand, während die Breitengrade mit Annäherung an die Pole einen größer werdenden Abstand haben. Die Darstellung in Äquator-Nähe ist sehr genau, nimmt zu den Polen hin an Flächenverzerrung zu, was z.b. Grönland unrealistisch groß erscheinen lässt. Durch die Verzerrung werden diese Karten nur zwischen -85, Süd und 85, Nord Breite angezeigt (vgl. [24], S.53-65). [27] 25

37 Kapitel 2. Stand der Technik und Umfeld Abbildung 7: Mercator Projektion, [27] Was ist OpenStreetMap OpenStreetMap ist ein Projekt zur Erstellung einer globalen Geodatenbank. Die Datenbank wird von freiwilligen Mappern erweitert, die geografische Information mittels GPS Receivern aufzeichnen. Die GPS Aufzeichnungen werden dann in Form von Punkten und Linien, erweitert um Kategorien und Eigenschaften, den sog. Tags, der Datenbank zugeführt um daraus Kartenmaterial (Länder, Straßen, POIs) zu generieren. Dieser Vorgang nennt sich Crowdsourcing. Die Datenbank wächst auch durch die Verarbeitung von bereits existierendem Kartenmaterial, das keinen Copyright-Schutz hat (z.b. Daten der öffentlichen Hand, Spenden/Freigabe von Unternehmen, die im Besitz von Kartendaten sind). Die Gründer von OSM bezeichnen das Projekt selbst als WikiLandkarte. Mapper (jeder, der sich als aktiver Benutzer registriert) kann beliebige Features der Datenbank hinzufügen oder ändern, wobei für jedes Feature eine Versionsgeschichte gespeichert wird, um vorhergehende Zustände wieder zurückzuholen. Durch den Einsatz von eigener Software wird das Ziel erreicht, höchste Flexibilität in Bezug auf was und wie gemappt wird zu haben. Daten und Dienste von OSM sind free as in beer, not free as in speech [24], was bedeutet, dass alle Information von jedem frei genutzt, verändert und weitervertrieben werden darf (vgl. [24], S. 8,9). 26

38 Kapitel 2. Stand der Technik und Umfeld OSM Datenmodell Das OSM zugrundeliegende Datenmodell basiert auf überraschend wenigen Design Goals und wurde ohne größeren Projektplan über die Zeit in kleinen Schritten entwickelt. Indes sind folgende, für das Projekt fundamentale Prinzipien zu nennen: Datenmodell und API sind so einfach wie nur möglich Diese wurden mit Hinblick darauf entworfen, Daten so simpel wie möglich zu erstellen und zu editieren, weniger für die Verwendung innerhalb von Applikationen (was in der Regel eine Transformation der Daten vor Gebrauch nötig macht). Editieren der Daten, ähnlich wie in Wiki Software Viele Benutzer können gleichzeitig editieren, und jeder Änderungsschritt wird versioniert. Topologie Information, wie einzelne Features miteinander verknüpft sind, wird auch gespeichert. Wenig Regulativen, höchste Editierfreiheit OSM nimmt es damit sehr genau, es hat kaum Vorgaben, Benutzer brauchen keine Ontologie zu lernen. Es gibt 3 Datentypen in OSM. Diese sind: Nodes, Ways und Relations. Mittels Tagging (das Hinzufügen von beliebig vielen Key-Value Paaren) werden daraus geografische Features, hinreichend beschrieben und kategorisiert durch Tags. Standardformat für OSM Daten ist XML Nodes Nodes sind Punkte, versehen mit eindeutig identifizierenden Positionsdaten in Weltkoordinaten. Die XML Beschreibung für einen Node sieht z.b. wie folgt aus: <?xml version="." encoding="utf-8"?> <osm version=".6" generator="overpass API"> <meta osm_base="23-4-3t4:2:4z"/> <node id=" " lat=" " lon="5.6282"> <tag k="amenity" v="place_of_worship"/> <tag k="created_by" v="potlatch.f"/> <tag k="denomination" v="catholic"/> <tag k="religion" v="christian"/> </node> </osm> Listing : XML Beschreibung für OSM Node [eigene Darstellung] 27

39 Kapitel 2. Stand der Technik und Umfeld Der zuvor beschriebene Node ist eine Kirche in 8665 Langenwang, Österreich: Abbildung 8: Beispiel für Node Datentyp [eigene Darstellung] Das node Element hat die Attribute id, die den Node eindeutig von anderen Nodes (nicht jedoch von Ways und Relations) unterscheidet, lat und lon, für die Positionsinformation. Die einzigen Child-Elemente sind Elemente vom Typ tag, die Key-Value Paare zur Beschreibung des Nodes Ways Ways sind nichts anderes als eine Liste von Nodes, die einen Linienzug beschreiben. Ways sind z.b. Straßen oder Wege. Wenn der Linienzug geschlossen ist (erster und letzter Punkt (Node) sind ident) beschreibt der Way eine Fläche, wie z.b. einen Park, oder einen Stadtbezirk. In XML wird ein Way wie folgt beschrieben (siehe Kirchengasse in obigem Beispiel): <osm version=".6"> <way id=" " visible="true" timestamp="22-8-8t7:3:46z" version="9" changeset="277577" user="eriosw" uid="45347"> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <tag k="highway" v="residential"/> <tag k="is_in" v="langenwang,bruck-mürzzuschlag,steiermark,österreich,europe"/> 28

40 Kapitel 2. Stand der Technik und Umfeld <tag k="name" v="kirchengasse"/> <tag k="source" v="plan.at 29"/> </way> </osm> Listing 2: XML Beschreibung für OSM Ways [eigene Darstellung] Die Child-Elemente eines way Elements sind Referenzen auf node Elemente, die den Verlauf des Weges beschreiben, und Tags für die Metainformationen. Teilen zwei Ways ein oder mehrere idente Nodes, bedeutet das, dass sie physikalisch miteinander verbunden sind, was vor allem für Routing Programme wichtig ist Relations Relations sind Listen von den bereits genannten Objekten, inklusive Relations. Sie dienen zum Beschreiben komplexerer Features, die nicht durch einzelne Nodes oder Ways repräsentiert werden können. Folgender XML Code beschreibt als Relation die administrativen Grenzen des Gemeindegebiets Langenwang: <osm version=".6" generator="openstreetmap server"> <relation id="5983" visible="true" timestamp="23--t2:34:37z" version="7" changeset="44867" user="a_uller" uid="965"> <member type="way" ref=" " role="outer"/> <member type="way" ref="283695" role="outer"/> <member type="way" ref="75324" role="outer"/> <member type="way" ref="753243" role="outer"/> <member type="way" ref="492962" role="outer"/> <member type="way" ref="283695" role="outer"/> <member type="way" ref=" " role="outer"/> <member type="way" ref=" " role="outer"/> <member type="way" ref=" " role="outer"/> <member type="way" ref=" " role="outer"/> <member type="way" ref=" " role="outer"/> <tag k="admin_level" v="8"/> <tag k="boundary" v="administrative"/> <tag k="name" v="gemeinde Langenwang"/> <tag k="postal_code" v="8665"/> <tag k="ref:at:gkz" v="626"/> <tag k="type" v="multipolygon"/> <tag k="wikipedia:de" v="langenwang"/> </relation> </osm> Listing 3: XML Beschreibung für OSM Relations [eigene Darstellung] 29

41 Kapitel 2. Stand der Technik und Umfeld Rendern von Slippy Maps Um aus den geografischen Daten des OpenStreetMap Projekts digitale Landkarten zu erstellen, müssen diese Rohdaten von der OpenStreetMap Datenbank kopiert werden. Es existieren im Wesentlichen 3 Methoden zum Download der Datenbank, oder eines Datenbankauszugs: Planet Datei OpenStreetMap API Extended API Als Planet Datei wird ein wöchentlich aktualisierter Datenbank-Snapshot bezeichnet, der über Downloadseiten heruntergeladen werden kann. OpenStreetMap API und Extended API (XAPI) sind Web APIs, die zum Teil direkten Zugriff auf die OSM Datenbank erlauben, um nur diejenigen Daten abzufragen, welche bestimmten Suchkriterien (Region, Features, Typ, etc.) entsprechen (vgl. [28], S. 73-9). In Kapitel werden die Methoden anhand eines speziellen Anwendungsfalles genauer beschrieben. Zur Anzeige von digitalen Weltkarten im Web werden von zahlreichen Anbietern sog. Slippy Maps verwendet. Slippy Maps ermöglichen dem Anwender eine Weltkarte über das Web zu betrachten, zu zoomen und den angezeigten Bereich zu verschieben. Google, Bing, und auch OpenStreetMap verwenden Slippy Maps. Die Welt wird dabei für jeden verfügbaren Zoomlevel in Kacheln (engl. Tiles) aufgeteilt. Die Tiles werden auf dem Server von OSM aus den Vektordaten der Datenbank vorberechnet, zwischengespeichert und bei Abruf über die Web-Karten Applikation als Bitmap Datei an den Client geliefert. Somit fällt am Client ein rechenintensives Rendering des angezeigten Kartenausschnitts weg, angezeigt wird keine Vektorkarte, sondern eine bereits am Server gerenderte Rasterkarte. Für die Darstellung wird die Mercator Projektion angewandt. Es wird nur der Bereich zwischen -85 Süd und 85 Nord Breite verwendet (siehe Kapitel 2.4.4), was zu einer exakt quadratischen Weltkarte führt. Die Kacheln sind genau 256x256 Pixel groß. In der niedrigsten Zoomstufe wird die gesamte Welt in einer Kachel angezeigt. Mit jeder weiteren Zoomstufe vervielfacht sich die Anzahl der Kacheln - ein immer kleinerer Ausschnitt der Welt findet auf einer Kachel Platz (vgl. [6], 75, 76). Abbildung 9 veranschaulicht dieses Prinzip: [29] 3

42 Kapitel 2. Stand der Technik und Umfeld Abbildung 9: Tile Schema für Web-Karten, [29] Die Anzahl der erforderlichen Kacheln je Zoomstufe ergibt sich demnach gemäß folgender Formel: c = Anzahl Tiles, n = Zoomstufe c=2 n x 2n Als Rendern wird in diesem Zusammenhang der Prozess bezeichnet, aus den vorhanden Rohvektordaten Bitmap Rasterkarten zu generieren, deren Aussehen durch Styles vorgegeben wird. Es existieren eine Reihe von Rendering Applikationen, die aus OpenStreetMap (und vielen anderen in der GIS Welt üblichen) Daten digitale Rasterkarten generieren können. Das vom OSM Projekt favorisierte Renderprogramm ist Mapnik [3]. Mapnik ist ein in C++ geschriebenes Programm, und unterstützt das Lesen von ESRI Shapefiles, PostGIS, TIFF rasters,.osm Dateien und einigen anderen. Über die sog. Map Datei werden Styles definiert, die das Aussehen der zu rendernden Vektordaten bestimmen. Mapnik und der Vorgang des Renderns wird in den Kapiteln und anhand eines konkreten Anwendungsfalles genauer beschrieben. Standard OSM XML Dateien enden auf.osm. 3

43 Kapitel 2. Stand der Technik und Umfeld 2.5 Qt 2.5. Was ist Qt Qt ist ein plattformübergreifendes C++ Framework für die Entwicklung von Graphical User Interface (GUI) Applikationen. Qt wurde ursprünglich als reines UI Framework entwickelt, mittlerweile wurde daraus eine umfangreiche Bibliothek, die neben UI Funktionen auch Klassen für Aufgaben wie Datenbankzugriff, XML Parsing, WebKit, Multimediaverarbeitung, Networking, OpenGL, Scripting u.a. bereitstellt (vgl. [3], S. 3). Qt verfolgt den Ansatz write once, compile anywhere [32], und meint, dass Source Code nur einmal geschrieben werden muss, aber für viele Plattformen kompiliert werden kann (vgl.[32], S. xv). Zu den unterstützten Plattformen zählen Windows XP 32 bis Windows 8/64bit, Linux, Mac OS X (bis.8), Solaris und viele Versionen von Unix mit X Unterstützung (vgl. [33], Supported Platforms ). Qt wurde ursprünglich von Haavard Nord und Erik Chambe-Eng entwickelt, die 994 gemeinsam das Unternehmen Trolltech gegründet haben (vgl. [32], S. xix). Später (28) wurde die Qt Entwicklung von Nokia übernommen, das diese aber mit 22 vollständig an das norwegische Unternehmen Digia verkauft hat, das aktuell die Rechte an Qt besitzt (vgl. [33]). Mit der Variante Qt/Embedded steht das Framework auch für Embedded Plattformen zur Verfügung. Neben Windows Embedded 7 wird auch Linux on ARM unterstützt, was ein auschlaggebendes Argument für den Einsatz für das vorliegende Projekt war. Seit Version 4 der Qt Framework Bibliothek setzt sich diese aus mehreren Modulen zusammen. Qt 4. bestand bereits aus etwa 5 Klassen und mehr als 9 Funktionen. Die Aufteilung in Module gibt Programmierern die Möglichkeit, nur gegen diejenigen Module zu kompilieren, welche auch tatsächlich benötigt werden (vgl. [32], S. xx). Abbildung : Qt Module, [3] 32

44 Kapitel 2. Stand der Technik und Umfeld Widgets Als Widget wird in Qt ein GUI Element bezeichnet. QWidget ist die Basisklasse, von der die GUI Objektklassen abgeleitet sind. Ein Widget ist z.b. ein Button (QButton), ein Label (QLabel) oder ein Dialogfeld (QDialog). Es ist aber auch möglich, eigene Widgets zu implementieren. Diese können von Grund auf neu entwickelt werden, oder auch einfach durch Komposition vorhandener Widgets erstellt werden. Ein Hello World Programm, das ein Fenster mit dem Text Hello World anzeigt, sieht für Qt folgendermaßen aus: #include <Qapplication> #include <Qlabel> int main(int argc, char **argv) { Qapplication app(argc, argv); Qlabel l( Hello World! ); l.show(); return app.exec(); } Listing 4: Hello World Programm für Qt, [3] Signals und Slots Bereits 992 wurde von Chambe-Eng die Idee von Signals und Slots entwickelt, ein GUI Paradigma für Events und State Changes (vgl. [32], S. xix). Später wurde dieser Mechanismus von vielen anderen Frameworks übernommen. Mittels dem Signal und Slot Mechanismus können Objekte miteinander kommunizieren, ohne dass ein Objekt Kenntnis vom anderen haben muss. In GUI Applikationen lösen Ereignisse (engl. Events), das sind z.b. Benutzeraktionen wie das Klicken eines Buttons, Signals aus (emit signal()). Ein anderes Objekt kann sich mit diesem Signal verbinden und Event Benachrichtigungen empfangen. Dabei wird über den Aufruf von connect() eine Empfangsfunktion, ein sog. Slot, für das Signal bestimmt. Das Signals und Slots Prinzip hat gegenüber einer anderen verbreiteten Methode, nämlich Callback Funktionen für die Event-Synchronisation zu verwenden, den Vorteil, dass Signals und Slots typsicher sind, und Objekte keine Referenzen auf andere halten müssen. Callbacks sind direkte Aufrufe, während Signals und Slots ein generischer Mechanismus ist, der zwar Objekte unterschiedlicher Art verbindet, allerdings diese Verbindung automatisch aufgehoben wird, sobald eines der Objekte gelöscht wird. Programmabstürze werden dadurch vermieden. 33

45 Kapitel 2. Stand der Technik und Umfeld Beispielsweise sendet ein Objekt der Klasse ClassA das Signal clicked(): void ClassA::signalEmittingMethod() { [ ] emit clicked(); } Listing 5: Qt Signal senden [eigene Darstellung] Das Signal wird in der Klassendefinition mittels dem signals Schlüsselwort als solches definiert: class ClassA : public QObject { [ ] signals: void clicked(); } Listing 6: Definition der Signal Funktion [eigene Darstellung] Ein Objekt der Klasse ClassB verbindet sich mit dem clicked() Signal über die connect() Funktion: connect(senderclassa, SIGNAL(clicked), rcvclassb, SLOT(actionClick)); Die Methode actionclick() ist der (Empfangs-)Slot, der bei Auslösen des Signals clicked() damit automatisch aufgerufen wird. Die Definition des Slots geschieht mit dem slot Schlüsselwort: class ClassB : public QObject { [ ] public slots: void actionclick(); Listing 7: Definition der Slot Funktion [eigene Darstellung] Slots können identisch zu herkömmlichen C++ Memberfunktionen virtuell sein, überladen werden, public, protected oder private sein. Mit der Ausnahme, dass nur slots mit Signals verbunden werden können. Dabei ist es auch möglich, ein Signal mit vielen Slots, viele Signals zu genau einem Slot, oder sogar ein Signal mit einem anderen Signal zu verbinden (vgl. [32], S. 2, 2) Styling Standardmäßig werden Widgets von Qt so gerendert, dass sie für ein natives 2 Look and Feel für die Plattform, auf der die Applikation läuft, sorgen. Dafür gibt es von QStyle abgeleitete UI Render2 native bedeutet in diesem Sinne: UI Elemente, deren Aussehen aus einer vorhandenen (z.b. zum Betriebssystem gehörigen) Bibliothek generiert wird 34

46 Kapitel 2. Stand der Technik und Umfeld klassen wie z.b. QWindowsStyle, QWindowsVistaStyle, oder QMacStyle. Qt entscheidet automatisch, mit welchem Style Widgets für die aktuelle Plattform gerendert werden. Dieser Standard- oder native Style kann mittels einer der im Folgenden angeführten Methoden verändert, oder sogar völlig neu implementiert werden (vgl. [32], S. 439): Erstellen von vererbten Widgetklassen und Überschreiben der Paint und Mouse Event Handler Funktionen. Zwar hat man damit volle Kontrolle darüber, wie das Widget gezeichnet wird, allerdings erfordert das auch viel Programmieraufwand. In bestehendem Source Code müssen die Klassennamen der Widgets nachträglich geändert werden. Es können auf QStyle (oder davon abgeleiteten, wie QMacStyle) basierte Vererbungsklassen implementiert werden. Qt verwendet intern diese Methode zum Rendern der Plattformnativen Styles. Mit Qt 4.2 wurden Qt Style Sheets (QSS) eingeführt. Mittels Textdateien, die zur Laufzeit von der Engine gelesen und interpretiert werden, kann das Aussehen und Verhalten von Widgets manipuliert werden. Qt Style Sheets orientieren sich an HTML Cascading Style Sheets (CSS), sind allerdings speziell auf Widgets abgestimmt. Für diese Arbeit wurde die Methode der Qt Style Sheets angewendet. Um etwa die Hintergrundfarbe des Textbox Widgets (Klasse: QLineEdit) zu ändern, wird folgender QSS Code geschrieben (vgl. [32], S. 439): 2 3 QLineEdit { background-color: yellow; } Ähnlich wie im CSS Format werden Eigenschaften von Widgets mittels Selector (im Beispiel: QLineEdit), Attributen (background-color) und deren Werte (yellow) gesetzt. Wird der QSS Code in eine separate Datei namens customstyle.qss geschrieben, kann er über die Command-Line Option -stylesheet customstyle.qss für die gesamte Applikation gesetzt werden. Alternativ kann dies auch über die Funktion QApplication::setStyleSheet() zur Laufzeit passieren. Weiters ist es möglich, Stylesheets speziell für ein Widget und dessen untergeordnete Kindobjekte zu setzen, etwa für ein Dialogfeld (vgl. [32], S. 44, 44): dialog->setstylesheet( QLineEdit { background-color: yellow; } ); In Kapitel wird die Verwendung von Qt Style Sheets anhand eines Praxisbeispiels vertiefender diskutiert. 35

47 Kapitel 2. Stand der Technik und Umfeld Qt Plugin System Plugins sind Softwaremodule, die die Funktion von bestehenden Applikationen erweitern. Diese Softwaremodule sind dynamische Bibliotheken, separate Dateien, die entweder beim Kompilieren fest mit der entsprechenden Applikation verlinkt, oder zur Laufzeit dynamisch geladen werden. Mit QLibrary bietet Qt eine plattformunabhängige Methode, um dynamische Bibliotheken (abhängig vom Zielsystem auch Shared Libraries oder Dynamic Link Libraries (DLLs) genannt) zur Laufzeit zu laden. Dabei sucht QLibrary bei Angabe des Dateinamens myplugin nach myplugin.dll in Windows, myplugin.so in Linux und myplugin.dylib in Mac OS X (vgl. [32], S. 49). Ein Plugin implementiert zumindest ein Interface. In C++ ist ein Interface eine abstrakte Klasse, d.h. eine Klasse, die nur aus virtuellen Methoden-Deklarationen (ohne Implementation) besteht. Applikation und Plugin kommunizieren über diese, beiden Seiten, bekannten Interfaces. QLibrary benötigt, dass ein Interface, das für Plugins verwendet wird, über das Makro Q_DECLARE_INTERFACE() registriert wird. Eine Interface Deklaration sieht beispielsweise wie folgt aus: class MyInterface { virtual ~MyInterface() {} virtual QStringList mycapabilities() = ; virtual int mypluginmethod(int param) = ; }; Q_DECLARE_INTERFACE(MyInterface, com.example.myapp.myinterface/. ) Listing 8: Beispiel Interface Deklaration in Qt [eigene Darstellung] Mittels dem Q_DECLARE_INTERFACE() Makro wird dem Interface ein eindeutiger Identifier zugewiesen. Dieser besteht normalerweise aus einer umgekehrten Domain, dem Applikationsnamen, dem Namen des Interfaces und, per Schrägstrich getrennt, einer Versionsnummer. Dies soll QLibrary helfen, externe Plugins absturzsicher zu laden. Ein Plugin mit der zugehörigen Klasse MyPluginClass, das obenstehendes Interface implementiert, muss das Makro Q_INTERFACES() innerhalb der Klassendefinition in der Header Datei angeben, damit die Applikation später einen dynamischen Cast mittels qobject_cast<t>() durchführen kann: class MyPluginClass : public QObject, public MyInterface { Q_OBJECT Q_INTERFACES(MyInterface) 36

48 Kapitel 2. Stand der Technik und Umfeld [ ] 5 6 }; Listing 9: Beispiel Plugin Deklaration in Qt [eigene Darstellung] Bei der Implementierung der Plugin Klasse MyPluginClass ist schließlich darauf zu achten, das Makro Q_EXPORT_PLUGIN2() wie folgt an das Ende der.cpp Datei zu schreiben, Q_EXPORT_PLUGIN2(myplugin, MyPluginClass) wobei der erste Parameter der Name der Library, ohne Dateiendung oder Versionsnummer, und der zweite Parameter der Name der Plugin Klasse ist (vgl. [32], S ). In Kapitel 3. wird dieses Prinzip anhand einer tatsächlichen Implementierung weiter vertieft und auch gezeigt, wie die Applikation letztendlich eine externe dynamische Bibliothek zur Laufzeit lädt. 37

49 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Kapitel 3 Entwicklung des AIS Multifunktionsdisplays 3. Überblick In diesem Kapitel werden die praktischen Ergebnisse der Entwicklungsarbeit präsentiert. Es werden alle wichtigen Systemkomponenten einschließlich der Hardware zumindest überblicksmäßig vorgestellt. Ausführlich beschrieben wird die Planung und Entwicklung der Software für das MFD. 3.2 Kundenbefragung Bei der Entwicklung des FT-TEC MFD handelt es sich, wie bereits erwähnt, nicht um ein gänzlich neuartiges Produkt. Vielmehr steht die Entwicklung in Konkurrenz zu bestehenden Systemen von bekannten Herstellern (z.b. NSS7 von Simrad [34]). Um eine Vorstellung zu bekommen, was sich potenzielle Kunden von einer Neuentwicklung eines Low-Cost Multifunktionsdisplays erwarten, wurde von FT-TEC auf der Austrian Boat Show 22 in Tulln und der Miami Boat Show 22 eine Umfrage zu diesem Thema durchgeführt. Bei der Umfrage wurden den Befragten 3 Aussagen vorgelegt, die jeweils mit sehr wichtig, wichtig, bedingt wichtig, weniger wichtig und unwichtig zu bewerten waren (vgl. [35]). Weiters wurde den Befragten die Möglichkeit geboten, eigene Vorschläge zu formulieren. In [7], auf den Seiten 3-32, wurden die Ergebnisse ausgewertet. Die nachfolgende Tabelle ist dieser Auswertung entnommen: Wichtigkeit Gesamt Integrierter AIS Transponder Geringer Stromverbrauch Kostenloses Kartenmaterial Kleine Abmessungen Großes Display Hohe Displayauflösung Bedienung mittels Touchscreen Animationen in der Software

50 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Wichtigkeit Gesamt WLAN Ehternet CAN RS RS USB 6 Bluetooth ZigBee Tabelle 7: Ergebnisse Umfrage MFD-Features ([7], S. 3) Zusammenfassend wird festgehalten, dass folgende Features, zusätzlich zu den Minimalanforderungen eines AIS-fähigen MFD (wie z.b. RS232) für die befragten Personen besondere Wichtigkeit haben (diese wurden zum Teil als Vorschläge von den Befragten frei formuliert): Unterstützung von WLAN zur Nutzung des Internets, um lokale Informationen im Hafenbereich oder s abzurufen Eine hohe Displayauflösung, um möglichst viele Details zu erkennen Anzeige von freiem Kartenmaterial ist erwünscht, ebenso die Kompatibilität zu kommerziellen sog. Electronic Nautical Charts (ENCs) von Herstellern wie Navionics oder Jeppesen Einfache Aktualisierung des Kartenmaterials und der Firmware über Internet USB als Schnittstelle zum eigenen Computer Der Kartenplotter soll über einen Touchscreen verfügen und auch mit Handschuhen einfach und intuitiv bedienbar sein Das Gerät muss zu handelsüblichen Class B Transpondern kompatibel sein. Da an Bord vieler Schiffe bereits ein AIS Empfänger installiert ist, soll es keinen AIS Empfänger integriert haben Das Gerät soll auch noch bedienbar sein, wenn es direkter Sonneneinstrahlung ausgesetzt ist 39

51 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Die Ergebnisse dieser Befragung wurden in die weitere Anforderungsanalyse miteinbezogen (vgl. [7], S. 3, 32). 3.3 Anforderungen an die Hardware An dieser Stelle werden nur diejenigen Anforderungen angeführt, welche für die Entwicklung der Software relevant sind. Für eine umfassende Analyse siehe [7], S Recheneinheit Bei der Definition der CPU Leistung wurde auf Erfahrungs- und aktuelle Marktwerte zurückgegriffen. Das System wird Linux als Betriebssystem erhalten, neben der Darstellung von digitalen Karten sollen auch grafisch aufwändigere Anwendungen auf dem System ausführbar sein. Diese Anwendungen sind großteils noch nicht spezifiziert, die CPU Leistung soll aber nicht unterdimensioniert werden, sondern eher noch Reserven bieten. GHz Taktfrequenz gilt als Minimum. Um eine gute Gesamtperformance zu erreichen, soll die Recheneinheit über eine schnelle DRAM3 Schnittstelle verfügen. Für gute Grafikperformance soll eine CPU mit integrierter GPU 4 und Grafikbeschleuniger gewählt werden. Damit Linux als Betriebssystem einsetzbar ist, muss die CPU eine MMU5 besitzen. Zur Unterstützung von akzeptablen externen Speichergrößen von mehreren GB wird eine 32 Bit Architektur gewählt (vgl. [7], S. 32) Coprozessor Bei angeschlossenem AIS Transponder kann es vorkommen, dass es zu einer hohen Rechenlast aufgrund von Protokollverarbeitungs- und Dekodierverfahren kommt. Daher wird die Hardware mit einem geeigneten Coprozessor ausgestattet, der diese Aufgaben übernimmt. Als Coprozessor wird ein 32 Bit Mikrocontroller ausgewählt (vgl. [7], S. 32) Speicher Die Größe des Hauptspeichers wird auf 52 MB Minimum festgelegt (min. DDR2, besser DDR3 SDRAM) Abk. f. Dynamic Random-Access Memory Abk. f. Graphics Processing Unit Abk. f. Memory Management Unit 4

52 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Der Speicher des Geräts soll mittels SD-Karte erweiterbar sein, daher muss ein SD-Kartenslot vorgesehen werden. Dieser erweiterte Speicher ist für Kartenmaterial und sonstige Datenspeicherung vorgesehen. Kernel und Dateisystem sollen auf einem kompakten NAND 6-Flashspeicher untergebracht werden, der mindestens 28 MB groß sein soll (vgl. [7], S. 33) Schnittstellen Das MFD soll folgende Schnittstellen aufweisen: Min. x USB, für den Anschluss von externer Peripherie, Speichererweiterung oder eines PCs WLAN, primär für Internetzugang Ethernet, als weitere Option für den Internetzugang CAN7, zur Kommunikation mit Geräten über NMEA 2 RS232 zum Anschluss eines AIS Transponders UART, serielle Schnittstelle für den Wartungszugang zur Linux Shell RS422 zum Anschluss von Bord-Peripherie wie Radar oder Echolot VGA für externen Monitor SD-Kartenslot für externe Speichererweiterung 2 optische Relaisausgänge zum Schalten von externer Hardware 2 optische Eingänge für externe Schalter (vgl. [7], S. 33) Benutzerschnittstelle In einer Studie des Transportation Research Board (TRB) wurden generelle Anforderungen an AIS-Displays definiert (vgl. [4]). Unter technischen Anforderungen an AIS-Displays versteht man die Anforderungen an: Hardware, Software, Datenbanken/-strukturen, Netzwerke, Speicher und Verarbeitung. Obwohl es schon viele AIS-fähige Displays am Markt gibt, konnte das TRB keine 6 7 NAND Flash ist neben NOR Flash eine Art von Flash Speicher (benannt nach der Speicherzellen Anordnung) (vgl. [36], S. 53) Abk. f. Controller Area Network 4

53 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays normativen Vorgaben für deren technischen Anforderungen finden, weder aktuell gültige, noch für zukünftig zu produzierende Displays (vgl. [4], S. 93). Ausgehend vom aktuellen Stand der Technik, der technischen Umsetzung der Konkurrenzprodukte und nicht zuletzt von den in Kenntnis gebrachten Kundenwünschen, werden bereits dennoch gewisse Vorgaben gesetzt. Nach aktuellem Kenntnisstand enthält das Portfolio jedes Konkurrenzanbieters zumindest eine Produktvariante mit Touchscreen (vgl. NSS7 von Simrad [34], e7 von Raymarine [37], GPSMAP von Garmin [38]). Eine Kartenanwendung, auf der virtuelle Elemente (Marker, Waypoints, etc.) exakt positioniert werden sollen, kann dieser Anforderung voraussichtlich mit einem Touchscreen allein nicht gerecht werden, vor allem auch unter der Annahme, dass für das Produkt kein teurer High-End Touchscreen zum Einsatz kommen wird. Des Weiteren wird festgelegt, dass das MFD allein mit der Hand (ohne sog. Pen für einen Touchscreen) bedienbar sein soll. Erfahrungswerte zeigen auch, dass bei starkem Seegang Hardware-Bedienelemente einfacher zu handhaben sind, als sog. virtuelle Buttons über einen Touchscreen. Als Anforderungen an benutzerfreundliche und konkurrenzfähige Bedienelemente werden für das MFD der FT-TEC GmbH die folgenden definiert (vgl. [7], S. 34): ein TFT Display mit einer minimalen Auflösung von 24 x 768 Pixel (XGA8) ein resistiver9 Touchscreen, um oben genannte Anforderungen zu erfüllen eine ausreichende Anzahl an sog. Hardware Buttons (max. 2 Stück), die zusätzlich zum Touchscreen als leicht zu bedienendes Benutzerinterface vorhanden sind und je nach Applikation gleichbleibende oder dynamische Funktion erhalten ein Joystick oder Drehencoder, z.b. zum exakten Steuern oder Navigieren innerhalb der Kartenanwendung (zur Differenzierung: ein Joystick ist ein Bedienelement mit mind. 4 Freiheitsgraden, was einer Navigation nach oben, unten, links und rechts entspricht, während mittels Drehencoder lediglich eine Drehung nach links oder rechts möglich ist) 3.4 Hardware Unter Berücksichtigung der voran angeführten Anforderungen wurde ein erster Prototyp der AIS MFD Hardware entwickelt. Abbildung zeigt das Blockschaltbild des entwickelten Prototypen. Folgend werden die verwendeten Komponenten kurz vorgestellt. 8 9 Abk. f. Extended Graphics Array Resistive Touchscreens reagieren auf Druck (von Finger oder Gegenstand) und sind dadurch auch mit Handschuhen bedienbar (im Gegensatz zu kapazitiven Touchscreens, die von einem leitenden Gegenstand (z.b. nackter Finger) berührt werden müssen) (vgl. [39], S. 24 u. 24) 42

54 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Abbildung : Blockschaltbild Hardware ([7], S. 44) 43

55 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays 3.4. Hauptprozessor i.mx535 Als Hauptprozessor wird der i.mx535 ARM Cortex-A8 mit,2 GHz von Freescale eingesetzt. Dieser wird nicht direkt, sondern als CPU Modul auf der Trägerplatine integriert (siehe dazu Abbildung 2. Ausgewählt wurde das TX53-33 CPU Modul von Ka-Ro Electronics GmbH (vgl. [7], S. 44, 45). Folgende Schnittstellen werden vom TX53 CPU Modul unterstützt: ) / Mbps Ehternet, 2) 2x USB 2., 3) 5x UART (verwendet für Bluetooth, externe RS422 Schnittstelle, RS232 für den seriellen Zugang zur Linux Shell und als Kommunikationsschnittstelle zum Coprozessor), 4) GPIOs (eingesetzt für 2x opt. Eingänge und 2x opt. Ausgänge, Anschluss Drehencoder und Folientastatur), 5) 2x SDIO (verwendet für WLAN Modul und SD Card Reader), 6) LVDS Schnittstelle zum Anschluss eines LCD Monitors, 7) eine VGA Schnittstelle, 8) und eine SATA Schnittstelle. Weitere Bestandteile des Boards sind ein 28 MB NAND Flash, 52 MB DDR3 SDRAM und eine Real Time Clock (vgl. [4]) Coprozessor Cortex-M4 Ein ARM Cortex-M4 von STMicroelectronics ist der Coprozessor der AIS MFD Hardware (vgl. [7], S. 45; [4]). Er ist primär für die Kommunikation zu externen Geräten verantwortlich. Verwendet werden die zur Verfügung stehenden UART Interfaces für ) den Anschluss eines AIS Transponders, und 2) der Kommunikation mit dem Hauptprozessor. Über die SPI Schnittstelle geschieht der DMA2 Datentransfer zum Hauptprozessor. Die CAN Schnittstelle ist für zukünftige Erweiterungen zur Unterstützung diverser anderer externen Geräte vorgesehen Peripherie Ein transflektives2 TFT-LCD Display erfüllt die Anforderung, auch bei Sonneneinstrahlung lesbar zu sein und die geforderte Auflösung darzustellen. Eine genaue Festlegung für einen Typ oder Hersteller für das Endprodukt wird zu diesem Zeitpunkt noch nicht gemacht. Für erste Prototypversionen wird ein PQ WX '' WXGA TFT von Pixel QI eingesetzt. Als Touchscreencontroller kommt der SX865 von Semtech zum Einsatz (vgl. [7], S. 43). Spezifische Modelle für Drehencoder und Folientastatur wurden noch nicht ausgewählt. 2 2 Abk. f. Direct Memory Access; mittels DMA Transfer können große Datenblöcke über die SPI Schnittstelle zwischen den beiden Controllern übertragen werden, ohne CPU Ressourcen zu benötigen im Gegensatz dazu: transmissives Display (vgl. [7], S. 24) 44

56 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Abbildung 2: AIS Display Prototyp, Aufbau auf Plexiglasscheibe [eigene Darstellung] 3.5 Anforderungen an die Software Die Anforderungsanalyse und im Weiteren die Planung der Software-Architektur folgen in wesentlichen Zügen dem von arc42 entwickelten Prozess zur Entwicklung und Konstruktion von effektiven Software-Architekturen (vgl. [42]) Aufgabenstellung Im Folgenden wird noch einmal die eigentliche Aufgabenstellung für die geplante Softwareentwicklung zusammengefasst: Für die Neuentwicklung eines AIS-fähigen Chartplotters soll die dafür erforderliche Benutzerapplikation erstellt werden. Das Hauptfeature der Software ist die Darstellung einer digitalen geografischen Karte, die jeweils zur aktuellen Position des eigenen Schiffes den jeweils relevanten Kartenausschnitt präsentiert. Auf der Karte selbst wird die Position des eigenen Schiffes anhand eines Symbols angezeigt. Werden Positionsmeldungen von anderen Schiffen über einen angeschlosse- 45

57 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays nen AIS Transponder empfangen, werden auch diese Schiffe als Symbole auf der digitalen Karte (auf der jeweiligen übermittelten geografischen Position) angezeigt. Ein weiteres wesentliches Feature ist die Möglichkeit der Funktionserweiterung über ApplikationsPlugins, die sog. Apps. Es existiert eine Basissoftware, die neben der Grundfunktionalität Bibliotheken für das applikationsspezifische User Interface (UI), eine interne Datenbank, Zugriff auf Konfigurationseinstellungen und etwaige Applikations-Treiber bereitstellt. Die tatsächlichen Anwendungen sind in den App-Plugins gekapselt und können dynamisch aktiviert und deaktivert werden. Einzelne Apps können über unterschiedliche Wege am Gerät installiert und ebenso aktualisiert werden. Die Software wird über teilweise nicht standardisierte Benutzereingabegeräte gesteuert. Die Software muss kompatibel zu folgenden Peripheriegeräten sein: Touchscreen, Folientastatur und Drehencoder Auswahl Programmiersprache Als Programmiersprache wird C++ gewählt. C++ Code kompiliert zu performanten Binaries. Es ist mit wenig Aufwand möglich, Programme auf schnellen Entwicklungsrechnern für die Zielhardware zu cross-kompilieren (siehe Kapitel 3.2) Auswahl GUI Framework Als GUI Framework wird Qt eingesetzt. Mit Qt/Embedded existiert eine Variante dieser umfangreichen Bibliothek, die für die Hardware und Software Plattform des Zielsystems (ARM Mikrocontroller und Linux) in Frage kommt. Viele weitere positive Eigenschaften wurden bereits in Kapitel 2.5 ausführlich beschrieben Technische Randbedingungen Das Entwicklungsprojekt unterliegt einer Reihe von technischen Randbedingungen. Die folgende Tabelle dokumentiert diese Randbedingungen und erklärt die ihnen zugrundeliegende Motivation. Randbedingung Erläuterung Spezifische Hardware Die Software muss auf dem speziell dafür entwickelten Gerät betrieben werden können. Da die Hardware und die Software gleichzeitig entwickelt werden, muss die Software auf den jeweils aktuellsten Hardware-Prototypen getestet werden. Unter diesen Punkt fallen auch die teils nicht standardisierten Eingabegeräte. 46

58 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Randbedingung Erläuterung Betrieb auf Linux Betriebssystem Als Betriebssystem kommt ein spezielles Linux für Embedded Systemumgebungen zur Anwendung. Dieses wird voraussichtlich das Linux von µcross [43] sein. Ein Kernel mit der Versionsnummer oder aktueller wird eingesetzt. Implementierung in C++ Die komplette Benutzersoftware wird in C++ programmiert. Der Source Code muss mit einem C++ fähigen Compiler für das Zielsystem übersetzt werden können. Verwendung von Qt als UI Frame- Qt bietet, vor allem auch für den Embedded Bereich, ein leiswork tungsstarkes UI Framework. Die Software soll Qt weitgehend einsetzen. Die minimale Version von Qt, die unterstützt werden muss, ist Die Unterstützung weiterer Frameworks wird nicht vorgesehen. Einsatz von Open Source Modulen Die Hinzunahme von frei verfügbaren Open Source Modulen in das Entwicklungsprojekt ist per Firmen- und Projektrichtlinie gestattet. Ausrichtung grafischer Menüs an Die grafischen Buttons der Hauptmenüleiste zur Steuerung Hardware-Folientastatur von Apps, müssen am Display so platziert sein, dass sie zum einen über den Touchscreen zu bedienen sind, und zum anderen durch deren Bildschirmposition einigen Hardware Buttons der Folientastatur logisch zugeordnet sind (damit redundant über Touchscreen als auch über Folientastatur dieselben Aktionen ausgeführt werden können). Tabelle 8: Technische Randbedingungen [eigene Darstellung] Organisatorische Randbedingungen Organisatorische Randbedingungen werden nur jene angeführt, die struktureller und ressourcenbezogener Art sind. Auf typische organisationsbezogene Bedingungen, die normalerweise Teil einer Architektur-Planung sind, wird in diesem Rahmen nicht näher eingegangen. Randbedingung Erläuterung Zeitplan Beginn der Entwicklung ist Juli 22, ein erster vorzeigbarer Prototyp der Software ist mit September 22 geplant. Ein weiterer Prototyp wird mit Dezember 22 fertiggestellt. Dieser stellt auch gleichzeitig den Beginn der Produktionsüberleitung dar. Funktionsumfang Der tatsächliche Funktionsumfang, der in der ersten Entwicklungsphase, die diese Arbeit beschreibt, erstellt wird, ist ausführlich in Kapitel dokumentiert. 47

59 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Randbedingung Erläuterung Entwicklungswerkzeuge Das erste User Interface Design wird mit Papier und Bleistift skizziert. Das endgültige Design wird in einem Vektorgrafikprogramm (z.b. Inkscape) entworfen. Als integrierte Entwicklungsumgebung, oder geläufiger als Integrated Development Environment (IDE) bezeichnet, wird zur Erstellung der Software Qt Creator verwendet. Die Software muss allerdings auch ohne IDE für das Zielsystem kompilierbar sein. Versionsverwaltung Als Versionsverwaltungssystem kommt git zum Einsatz. Das Repository wird redundant zur lokalen Kopie auch auf einem gehosteten, über das Internet erreichbaren Server gespeichert. Das Repository am Server wird weiters auf ein entferntes Backup System regelmäßig dupliziert. Testwerkzeuge Es werden keine Testwerkzeuge explizit festgelegt. Abnahmeprozess Bei Projektstart wird ein Testkatalog vorgelegt. Dieser beinhaltet ausformulierte Testfälle für alle festgelegten Funktionsanforderungen. Dokumentation Dokumentation ist diese Arbeit. Im Quellcode wird reichlich und aussagekräftig mittels Inline-Kommentaren dokumentiert. Die Syntax dafür wird so gewählt, dass mittels dem Programm Doxygen22 eine Dokumentation im html Format generiert werden kann. Tabelle 9: Organisatorische Randbedingungen [eigene Darstellung] Kontextabgrenzung Vorrangig wichtig für ein Softwarekonzept ist dessen Abgrenzung zur Umwelt. Dazu werden in den nächsten Abschnitten Fremd- bzw. Nachbarsysteme identifiziert und Schnittstellen benannt. Es wird unterschieden zwischen einer fachlichen und einer technischen Sicht Fachlicher Kontext Abbildung 3 stellt den fachlichen Kontext der Anwendung dar. Folgend werden die dargestellten Nachbarsysteme kurz erklärt. 22 Werkzeug zur Generierung von C++ Quellcode Dokumentation (vgl. [44]) 48

60 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Abbildung 3: Fachlicher Kontext [eigene Darstellung] Anwender Das AIS MFD wird von menschlichen Benutzern verwendet. Diese sind typischerweise der Skipper oder auch andere Mitglieder der Schiffsbesatzung. Der Anwender steuert die Software, indem er konfiguriert, wie die Daten momentan zur Anzeige gebracht werden sollen. Es ist nicht vorgesehen, dass der Anwender (im eigentlichen Sinne die AIS MFD Software) Fremdsysteme steuern kann. On-Board Infrastruktur (Fremdsystem) Über die Stereotyp-Bezeichnung OnBoard Infrastructure werden jene Fremdsysteme gruppiert, die Geräte der Schiffsinfrastruktur darstellen und über ein physikalisches Interface mit dem AIS MFD verbunden werden. Die Grafik zeigt neben dem AIS Transponder noch weitere Geräte an. Für die erste Implementierungsphase ist allerdings nur die Integration eines AIS Transponders geplant. 49

61 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Digitales Kartenmaterial (Fremdsystem) Die digitale Karte, die der AIS Chartplotter anzeigt, wird von Drittanbietern bereitgestellt. Die Anwender Software integriert einen Viewer (die primäre Anwendung), die das Kartenmaterial anderer Hersteller zur Anzeige bringt Technischer Kontext Die technische Sicht auf die Kontextabgrenzung veranschaulicht die tatsächlichen Kanäle, über die die AIS MFD Software mit den Fremdsystemen, respektive der Umwelt, kommuniziert. Abbildung 4: Technischer Kontext [eigene Darstellung] Peripherie Für Folientastatur und Drehencoder werden eigens für dieses Projekt/diese Hardware Linux Kerneltreiber implementiert (nicht Teil dieser Arbeit). Sie registrieren diese speziellen Peripheriegeräte, genauso wie den Touchscreen eines Drittanbieters, im System als standardkonforme Linux Input Devices. 5

62 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Coprozessor Jede Kommunikation über die physikalischen Schnittstellen zu angeschlossenen externen OnBoard Geräten (z.b. AIS Transponder, Sonar, Radar) erfolgt über spezielle Treibersoftware, die am Coprozessor (STM32) ausgeführt wird (nicht Teil dieser Arbeit). Die Coprozessor Treiber wandeln die Low-Level Protokolldaten in binäre Datenströme um, die über die SPI Schnittstelle und einem STM32 Link Treiber am Hauptsystem mittels DMA der AIS MFD Anwender Software bereitgestellt werden. Digitale Karte Wie bereits zuvor erwähnt, wird der Viewer der AIS MFD Software nach Abschluss der ersten Entwicklungsphase digitale Karten in Form von Tiles verarbeiten. Diese Tiles sind als Kartenmaterial entweder lokal in Form von Dateien innerhalb einer standardisierten Verzeichnisstruktur verfügbar, oder werden bei Bedarf von einem entfernten Tile Server angefordert Features für einen ersten Prototyp im Detail Zur Abgrenzung der ersten Entwicklungsphase für einen lauffähigen Prototyp werden die dafür notwendigen Funktionen bzw. Features definiert. Tabellen und listen diese auf. Sie sind zum Teil eine abschließende Zusammenfassung der erarbeiteten Anforderungen. Bezeichnung Erklärung User Interface Das User Interface der Software soll ansprechend und modern erscheinen. Es soll später auch von Personen ohne Programmierkenntnisse optisch anzupassen sein. Localization Neben Englisch soll die Software auch in anderen Sprachen nutzbar sein. Die aktuelle Sprache kann über die Applikationskonfiguration vom Benutzer gewechselt werden. Bedienung Die Software muss mittels eines Touchscreens, der Folientastatur und einem Drehencoder steuerbar sein. Dabei muss die Software auch bei Vorhandensein nur des Touchscreens oder nur der Folientastatur bedienbar bleiben. Plugin Schnittstelle Die eigentlichen Features sollen als Plugins dynamisch in eine dadurch erweiterbare Basissoftware eingebunden werden. Apps-Browser Jedes aktive Plugin wird in einem sog. Apps-Browser angezeigt. Der Apps-Browser ist das Hauptmenü der AIS MFD Software. 5

63 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Bezeichnung Erklärung Einheitliches Konfigurationsmana- Die Basissoftware stellt auch für App-Plugins ein vereinheitgement lichtes Konfigurationsinterface zur Verfügung. Hauptkonfiguration Alle applikationsweiten Einstellungen. Tag-/Nacht-Modus Die Software soll bei hoher Umgebungslichtintensität ein Erscheinungsbild für den Tag und bei wenig Licht ein angenehm zu betrachtendes Display für die Nacht haben. Kollisionswarnung Die Software muss bei erkannter Gefahr einer Kollision mit einem anderen AIS Target (Schiffe/AToNs, die über AIS dynamische und statische Daten senden) über das Display (und evtl. eine I/O Schnittstelle) eine gut erkennbare Warnung ausgeben. Tabelle : Features Basissoftware [eigene Darstellung] App: Karte Dieses Plugin stellt das Hauptfeature der AIS MFD Software dar. Es ist die eigentliche Chartplotter Anwendung. Bezeichnung Erklärung Anzeige OSM Kartenmaterial Primäres Ziel ist die Unterstützung von OSM Kartenmaterial, das entweder über den OSM Tile Server oder von einer lokalen Ressource bezogen wird. Weitere Kartendienste können unterstützt werden. Funktion: Zoomen Die Kartenanzeige muss mehrere Zoomlevels unterstützen. Dies soll einerseits über Funktionstasten möglich sein, aber gegebenenfalls auch über den Drehencoder. Funktion: Scrollen Die Karte soll über den Touchscreen mittels Slidebewegung scrollbar sein. Anzeige von AIS Targets Empfangene AIS Targets müssen als spezielle Symbole (je nach Schiffstyp) auf der Karte angezeigt werden. Eigenschaften wie Geschwindigkeit, Kurs über Grund usw. sollen das Anzeigebild beeinflussen. Automatische Zentrierung Es soll möglich sein, die automatische Zentrierung auf die Position des eigenen Schiffes zu aktivieren/deaktivieren. Maßstabsanzeige Die Karte soll den jeweils gültigen Maßstab indizieren. Tracking Bei aktiviertem Tracking wird der zurückgelegte Kurs als Track angezeigt. 52

64 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Bezeichnung Erklärung Gefährliche Targets Signalisierung der Targets, die sich auf Kollisionskurs befinden. Filterung Targets Über einen konfigurierbaren Filter sollen alle außer gefährliche (siehe oberer Punkt) Targets ausgeblendet werden können. Tabelle : Features App Karte [eigene Darstellung] App: Target-Liste Die App Target-Liste ist eine Sicht auf die interne AIS Target Datenbank. Sie listet alle empfangenen AIS Targets in definierbarer Reihung auf. Die Sortierung soll zumindest nach folgenden Kriterien möglich sein: Entfernung zum eigenen Schiff Schiffstyp MMSI Geschwindigkeit Wird ein Target ausgewählt, werden alle verfügbaren statischen sowie dynamischen Informationen in einem Detailfenster visualisiert App: GPX-Log Das Plugin erweitert die Software um eine Logging Funktionalität. Alle eigenen Positionsdaten werden als XML Datei im GPX Format geloggt. Es soll möglich sein, mehrere Tracks unter verschiedenen Namen zu speichern. Die gespeicherten GPX Logdateien können entweder vom Gerät kopiert werden, oder direkt auf der Karte angezeigt werden App: Software Update Über diese App kann die installierte Software aktualisiert werden, oder neue Apps installiert werden. 3.6 User Interface Design Donald A. Norman fasst in [45] zusammen, dass das Aussehen, oder allgemeiner die Erscheinung eines Geräts, die wesentlichen Anhaltspunkte liefern muss, damit eine ordnungsgemäße Bedie- 53

65 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays nung desselben möglich ist. Mit anderen Worten heißt das, die Information über die Handhabung eines Geräts ist nicht nur beim Benutzer selbst, sondern steckt auch in dem Gerät, indem es sich der Erfahrung und der Intuition des Benutzers gemäß präsentiert. Der erfolgreiche Entwurf des User Interface für das MFD ist als kritischer Erfolgsfaktor für das gesamte Projekt zu sehen. Das UI ist direkt dafür verantwortlich, ob künftige Kunden, die Benutzer, rasch lernen und verstehen, das Gerät zu verwenden, oder sich auf lange Sicht für ein anderes Gerät entscheiden werden. Noch bevor es allerdings dazu kommt, spielt es eine wesentliche Rolle bei der Kaufentscheidung für das Gerät. Daher wurde der User Interface Entwicklung besondere Wichtigkeit zugeordnet. Da es sich bei dem Projekt um eine komplette Neuentwicklung eines Multifunktionsdisplays handelt, und sich auch alle Hardwarebedienelemente direkt am Gerät befinden, umfasst der Prozess des UI Layouts sowohl das softwareseitige Erscheinungsbild, als auch Elemente der Hardware. Folgend werden nun die einzelnen Schritte der UI Entwicklung beschrieben Hardware User Interface Aus den in Kapitel 3.3 erfassten Anforderungen summieren nun die nachfolgend angeführten Punkte die zur Verfügung stehenden Ressourcen für das Hardware UI Layout: ) Touchscreen Der Touchscreen erstreckt sich über die gesamte Displayoberfläche. 2) Folientastatur für bis zu 2 einzelne Tasten 3) Drehencoder Der erste Prototyp wird mit einem Drehencoder bestückt werden. Moderne Hardware Layouts, wie z.b. von Smartphones23, weisen vermehrt, neben einem verhältnismäßig großen Touchscreen, selten mehr als 3 oder 4 fix platzierte Tasten am Gehäuse außerhalb des Displays auf. Für das AIS MFD allerdings ist es sinnvoller, eine größere Anzahl an fix platzierten Hardware Tasten vorzusehen, nämlich aus folgenden Gründen: Die Bedienung des Geräts soll zu einem großen Teil auch ohne Touchscreen möglich sein Das Gerät soll auch unter extremen Bedingungen bedienbar bleiben. Sturm, starker Seegang, Handschuhe, Nässe dies sind einige Faktoren, die die Bedienung eines Touchscreens erheblich erschweren, währenddessen tatsächliche Hardware Tasten aber weiterhin fassbar bleiben. 23 z.b. Sony Xperia Go (vgl. [46]) 54

66 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Reduzierung der für Interaktionen notwendigen Klicks Eine größere Anzahl zur Verfügung stehender omnipräsenter Tasten erhöht die Wahrscheinlichkeit, gewisse Aufgaben mittels einer geringeren Anzahl an Benutzeraktionen durchzuführen. Folgendes Beispiel soll dies erläutern: Ist für die Navigation zum Home Screen ein Untermenü aufzurufen, muss erst eine Menü-Taste und danach eine weitere gedrückt werden. Existiert eine omnipräsente Taste Home Screen ist lediglich ein Einzelvorgang (einmaliges Drücken der Taste) notwendig. Diese Tasten, würden sie als Buttons als Teil der Software implementiert werden, müssten groß genug gestaltet sein, damit sie auf einem Schiff sicher mit dem Finger getroffen werden und würden dadurch wertvollen Anzeigeplatz am Display vereinnahmen. Abbildung 5: Skizze Hardware UI Design [eigene Darstellung] Basierend auf den oben genannten Voraussetzungen und Überlegungen wurde der erste Entwurf des Hardware UI auf Papier skizziert (Abbildung 5). 55

67 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Block: Funktionstasten und Drehencoder Im Bereich rechts neben dem Display werden die Funktionstasten gruppiert. Dies sind Tasten, die über die Programmlaufzeit hinweg gleiche oder vergleichbare Bedeutung besitzen. Durch ihre spezifische Anordnung, sichtbare Bezeichnung durch Icons und teils unterschiedliche Größe wird der Wiedererkennungsfaktor und deren intuitive Anwendung verbessert. Abbildung 6: Bedeutung Funktionstasten [eigene Darstellung] Block: Menütasten Direkt unter dem Display wird eine Reihe von Menütasten platziert. Diese werden mit keinem speziellen Aufdruck gekennzeichnet, sondern erhalten ihre Bedeutung über den jeweils aktuellen Programmkontext. Das heißt, dass die Bedeutung der Tasten je nach Programmzustand während der Laufzeit wechselt. Konkret wird an der Displayunterseite bei Bedarf ein Softwaremenü angezeigt, über die Menütasten kann es, redundant zu der Bedienung über Touchscreen, gesteuert werden. 56

68 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Abbildung 7: Menütastenblock [eigene Darstellung] Software User Interface Nachdem das grundlegende Hardware Erscheinungsbild skizziert wurde, wurde darauf aufbauend die Entwicklung des Software UI begonnen. Für die Realisierung wurde Inkscape verwendet. Inkscape ist ein Open Source Vektorgrafikeditor, der Dateien im standardisierten Scalable Vector Graphics (SVG) Dateiformat lesen und schreiben kann (vgl. [47]). Die Umsetzung in einem Vektorgrafikprogramm, im Gegensatz zu z.b. bitmaporientierten Grafikprogrammen, hat den Vorteil, dass die erstellten Dateien keine fixe Bildauflösung besitzen, sondern flexibel an jegliche reale Bildgröße, ohne Qualitätsverlust und zu jedem Zeitpunkt, angepasst werden können. Das ist für dieses Projekt auch deshalb wichtig, da sich die Displaygröße (Abmessung und Auflösung) während des Entwicklungszyklus ändern kann. Ein weiterer Vorteil entsteht bei der Überleitung des Designs als statische Grafik in Programmcode. Unabhängig davon, wie das Programm später die Grafiken zu Buttons, Hintergründe, Icons, Schriften, etc. zusammenstellt, kann aus einer Vektordatei, die alle Designelemente beinhaltet, jedes beliebige Detail für diesen Zweck extrahiert werden. Für das Design werden alle User Interface Elemente selbst entworfen, es werden keine nativen Elemente verwendet. In 3.5 wurde bereits die Software für das AIS MFD als Programm illustriert, dessen Funktionalität durch Plugins, den Apps, erweitert wird. UI Designs, die einem bereits oftmals angetroffenen und daher vertrautem Muster entsprechen, sind intuitiver und werden vom Benutzer schneller akzeptiert, so wird z.b. in [48], S. 3-8, das Springboard Pattern beschrieben. Es kommt in einer Vielzahl moderner Softwareanwendungen zum Einsatz. Das Springboard, oder auch Launchpad genannt, ist eine Einstiegsseite für eine große Anzahl von Menüoptionen, z.b. den Apps, es dient zum Starten bzw. Aktivieren diverser Features einer Applikation. Beispiele dafür sind der ios Home Screen oder der Android Home Screen. Der erste Designentwurf für das Software UI ist das Springboard des MFD, im Weiteren auch AppBrowser genannt. Anders als auf Smartphones wurden die Menüsymbole sehr groß entworfen, da 57

69 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays eine Auswahl über den Touchscreen dadurch einfacher wird, und für die erste Produktserie keine große Anzahl an unterschiedlichen Apps zu erwarten ist. Der App-Browser erscheint attraktiver, wenn der Platz ausgefüllt ist. Der Eindruck von fehlenden Features soll dadurch vermieden werden. Abbildung 8 zeigt die Umsetzung des App-Browser Designs in Inkscape. Um die visuelle Vorstellung zu verbessern, wurde zusätzlich auch das Hardware UI, inklusive Gehäuse, aus der Vorlage der Papierskizze in Inkscape nachgezeichnet. Abbildung 8: Design Entwurf App-Browser [eigene Darstellung] In der Mitte der Anzeige befinden sich die großen Menübuttons. Sie sollen per Touchscreen und Drehencoder nach links oder rechts verschiebbar sein, um weitere Buttons in die Anzeigefläche zu positionieren. Hier wurde in Kombination mit dem Springboard das Image Carousel Pattern (vgl. [48], S. 34) implementiert. Der App-Browser des MFD ist bewusst sehr einfach aufgebaut, um dem Benutzer den Einstieg in die Programm-Features sehr direkt und unkompliziert anzubieten. Exemplarisch werden an dieser Stelle noch zwei weitere Design Entwürfe präsentiert. Zum einen die App Map (deutsch: Karte), welche die Hauptanwendung des MFD darstellt (siehe Abbildung 9). Oberhalb der Kartenansicht befindet sich die Statusanzeige. Auf ihr werden die wichtigsten navigationsrelevanten Daten angezeigt (wie Kurs über Grund, Geschwindigkeit oder Position), Warnungen und diverse Statusmeldungen. 58

70 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Unterhalb der Kartenanzeige befindet sich die Menüleiste. Die einzelnen Menübuttons weisen den Tasten im Menütastenblock (Hardware-Tasten an der Unterseite) ihre kontextabhängige Bedeutung zu. Das Drücken einer Hardware-Taste löst die gleiche Aktion aus, wie das Drücken des entsprechenden Menübuttons über den Touchscreen. Abbildung 9: Design Entwurf App Karte [eigene Darstellung] Abbildung 2 zeigt den Aufbau einer Konfigurationsseite. Auch hier werden alle angezeigten Elemente für die Verwendung über den Touchscreen, sowie redundant auch über die Hardware-Tasten und Drehencoder optimiert. Der aktive Eintrag (jener, der Input über die Bedienelemente akzeptiert) ist jeweils mit weißem Hintergrund hervorgehoben. Mittels Drehencoder wird der Fokus auf den nächsten oder vorherigen Eintrag gesetzt. 59

71 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Abbildung 2: Design Entwurf Konfigurationsseite [eigene Darstellung] 3.7 Softwarekonzept und -architektur Die Architektur der Software wurde in erster Linie nach ihren funktionalen Merkmalen und dem Architekturziel, die Basis der Software klein zu halten und Funktionalität über Plugins zu erweitern, strukturiert. Die Vorteile dieser Methode sind: Klare Kapselung von Features Flexibles und simples Aktivieren und Deaktivieren von Programmfunktionalität Software Erweiterung geschieht über definierte Schnittstellen, was eine Delegierung dieser Aufgabe vereinfacht Plugins können bei Gleichbleiben des Interfaces durch ähnliche der selben Art ausgetauscht werden (z.b. Austausch des einfachen Kartenplotter Plugins durch ein komplexeres) Als Nachteil der gewählten Architektur zählt folgender Punkt: 24 Da die Plugins nicht ein reines Strategy Pattern 24 implementieren, sondern Abhängigkei- Das Strategy Pattern definiert eine Familie von Algorithmen. Jeder einzelne ist so gekapselt, dass sie untereinander austauschbar sind (vgl. [49], S. 35). 6

72 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays ten untereinander ausbilden können, kann die Komplexität, nämlich die Abhängigkeit zwischen einzelnen Plugins, steigen. Dadurch ergibt sich weiters, dass zur Laufzeit auf Vorhandensein von entsprechenden Plugins geprüft werden muss Bausteinsicht der obersten Ebene Abbildung 2 zeigt die vereinfachte Struktur der Basissoftware anhand einer Bausteinsicht. Dies ist die oberste Architekturebene, sie stellt die vorhandenen Module und deren Abhängigkeiten dar. Für den Zweck der Übersichtlichkeit wurden die Abhängigkeiten des Moduls Logger nicht eingezeichnet, da diese zudem für jedes Modul optional sind. Stellvertretend für eine Vielzahl von Plugin Modulen wurde das Plugin(x) in die Abbildung eingezeichnet. Anschließend an die Grafik werden die Module und deren Aufgaben bzw. Verantwortlichkeiten diskutiert. Abbildung 2: Whitebox Darstellung MFD Software [eigene Darstellung] 6

73 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays User Interface Library Zweck/Verantwortlichkeit: Die User Interface Library ist eine Sammlung von Graphical User Interface (GUI) Elementen, die sowohl einfache Controls als auch komplexere Menüs, Widgets und Special Purpose Windows, wie z.b. einen konfigurierbaren Settings-Dialog, beinhaltet. Schnittstellen: Die User Interface Library weist selbst keine Abhängigkeiten zu anderen Softwaremodulen auf. Umgekehrt sollten alle Module, die ein GUI implementieren, die Methoden/Funktionen der UI Library nutzen. Configuration Zweck/Verantwortlichkeit: Sämtliche Konfigurationswerte der Basisapplikation sowie aller geladenen Plugins, werden innerhalb einer Datei verwaltet. Dieses Modul erlaubt das Lesen und Schreiben von Konfigurationswerten. Schnittstellen: Bietet Methoden/Funktionen zur Manipulation von Konfigurationswerten. Core Zweck/Verantwortlichkeit: In diesem Modul geschieht die zentralisierte Verwaltung, die grundlegende Ablaufsteuerung und Delegierung der Verantwortlichkeiten. Der App-Browser ist das grafische Frontend zum Core Modul. Schnittstellen: Das Modul verwendet Schnittstellen zu den Modulen Configuration, UI Library, AISTargetDatabase und CorePluginInterface. CorePluginInterface Zweck/Verantwortlichkeit: Das CorePluginInterface ist das Kommunikationsinterface zwischen allen zur Laufzeit geladenen Plugins und der Core-Applikation. Schnittstellen: Plugins nutzen Methoden dieses Interfaces als Kommunikationskanal zur Hauptapplikation. PluginLoader Zweck/Verantwortlichkeit: Lädt zur Laufzeit alle innerhalb eines Verzeichnisses verfügbaren externen Pluginbibliotheken. 62

74 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Schnittstellen: Wird vom Modul CorePluginInterface während der Initialisierungsphase der Applikation genutzt. Plugin Zweck/Verantwortlichkeit: Erweitert als externe Library die Feature-Palette der AIS MFD Anwendung. Schnittstellen: Zugriff auf Daten und Funktionen der Core-Applikation über CorePluginInterface. AISTargetDatabase Zweck/Verantwortlichkeit: Legt ein Verzeichnis statischer und (historischer) dynamischer Daten aller über AIS empfangenen Schiffe an. Schnittstellen: Das Core Modul sowie Plugins nutzen Funktionen der AISTargetDatabase für die Abfrage von Schiffsdaten. AISReader Zweck/Verantwortlichkeit: Über die SPI Schnittstelle werden dekodierte AIS Nachrichten vom Coprozessor gelesen und zum Einfügen in die AISTargetDatabase vorbereitet. Schnittstellen: Binäre Daten über SPI Datalink. Die AISTargetDatabase nutzt das Modul als Datenquelle. Logger Zweck/Verantwortlichkeit: Das Logger Modul ist für die Logging-Funktionalität zur Laufzeit verantwortlich. Alle Komponenten des Systems sollen dessen exportierten Methoden für Tracing und Debugging Nachrichten verwenden. Schnittstellen: Funktionen und Makros um auf unterschiedlichen Logging-Levels25 Debug Nachrichten zu generieren. 25 Typische Logging-Levels sind: Trace, Debug, Info, Warning, Error, Fatal 63

75 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Funktionsweise der Applikation In Abbildung 22 ist der Prozess der MFD Applikation bei Systemstart dargestellt. Im Aktivitätsdiagramm wird u.a. sichtbar, dass die Basisanwendung primär eine Plattform für Erweiterungs-Plugins ist. Abbildung 22: Aktivitätsdiagramm Starten der MFD Applikation [eigene Darstellung] 3.8 Custom User Interface Die User Interface Library fasst als eigenständiges Modul Komponenten zusammen, die für ein individuelles Erscheinungsbild der AIS MFD Anwendung sorgen und stellt sie den Komponenten mit Benutzerschnittstelle zur Verfügung. In Kapitel wurde ein Feature des Qt Frameworks beschrieben, das es ermöglicht, mittels Qt Style Sheets das Aussehen der built-in Widgets individuell anzupassen. Dieses Feature erlaubt es 64

76 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays der UI Library, vorgefertigte UI Templates zu exportieren, deren finales Erscheinungsbild am Display im Weiteren mit Qt Style Sheets individualisiert wird. Das Klassendiagramm in Abbildung 23 gibt einen Überblick über die Zusammensetzung der User Interface Library. Folgende Widgets wurden implementiert: Die Klasse Springboard: Für den App-Browser der Hauptapplikation wird eine Instanz des Springboard Widgets erzeugt. Die einzelnen SBButton Objekte werden über einen SBContainer verwaltet (der u.a. das animierte Scrollen steuert). Die Klasse Menu: Diese Klasse implementiert das Widget für das Hauptmenü am unteren Fensterrand (für Apps oder Konfigurationsdialog). Das Hauptmenü kann normale Buttons (MDefaultButton) oder Checkbox-Buttons (MCheckButton) enthalten. Die Klasse SettingsDialog: Erstellt einen Konfigurationsdialog, der aus einer oder mehreren Seiten (SettingsPage) aufgebaut ist und eine Reihe von Widgets zur Eingabe und Anzeige von Konfigurationswerten zur Verfügung stellt. Die Klasse OSKDialog erstellt ein Fenster, das aus einer Eingabe-Textbox und einem OnScreen-Keyboard besteht. Dies wird für die Texteingabe über den Touchscreen benötigt. Die Klassen MsgBox, Header und Footer sind simple Widgets, die für einen einheitlichen Aufbau von App-Windows verwendet werden sollen. Für Standard-Bedienelemente (wie z.b. Buttons, Checkboxen usw.) stellt die UI Library spezielle Style Sheets zur Individualisierung von built-in Qt Widgets bereit. 65

77 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Abbildung 23: Klassendiagramm UI Library [eigene Darstellung] Die Methodik zur Erstellung eines Custom User Interfaces wird anhand der Klasse SBButton exemplarisch erklärt. 66

78 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays 3.8. Erstellung der UI Template Klasse mit Qt Designer Im Programm Qt Designer wird das Widget SBButton modelliert. Das Widget selbst ist ein aus Standard Widgets des Qt Frameworks zusammengesetztes Objekt. Das Basisobjekt bildet ein QButton, optisch darüber werden zwei simple QWidget Objekte gelegt. Abbildung 24: SBButton in Qt Designer [eigene Darstellung] Die erstellte Klasse stellt die Vorlage, oder das Template, eines Buttons für den App-Browser dar. Das oberste QWidget soll das jeweilige Icon des Buttons anzeigen. Alle weiteren optischen Modifikationen werden bereits über Qt Style Sheets definiert. Das zweite, darunterliegende QWidget Objekt ist verantwortlich für die Anzeige eines passenden Hintergrunds und die Umrandung des Icons. Auch dem QButton Objekt wird ein benutzerdefinierter Style zugeordnet. Die tatsächliche Größe der instanziierten SBButton Objekte soll sich dynamisch der aktuellen Displayauflösung, oder allgemeiner formuliert, der Anforderung des jeweiligen assoziierten Parent-Objekts, anpassen. Hierfür wird ein QBoxLayout verwendet und entsprechend auf das resize Event des Widgets reagiert26. Folgender Quellcodeabschnitt zeigt die Erstellung des QVBoxLayouts im Konstruktor der SBButton Klasse, und die dynamische Größenanpassung in der resizeevent Methode: 26 Auf den Einsatz verschachtelter QBoxLayouts wurde bewusst verzichtet, da diese in diesem Fall eine höhere Komplexität generiert hätten, als die Funktion resizeevent() zu implementieren. 67

79 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays SBButton::SBButton(QWidget *parent): Qwidget(parent) { QVBoxLayout *verticallayout = new QVBoxLayout(this); verticallayout->setmargin(); verticallayout->addwidget(pushbutton); this->setlayout(verticallayout); // Redirect focus to QButton object, to grab user input setfocusproxy(pushbutton); // Resignal QButton clicked() signal to receiver connect(pushbutton, SIGNAL(clicked()), this, SIGNAL(clicked())); } SBButton::resizeEvent(QResizeEvent *) { int spaceside = buttonicon->width()/5; int spacetop = buttonicon->width()/6; int bkgwidth = width() - 2 * spaceside; int bkgheight = buttonicon->height() + 2 * spacetop; // Set new position of iconbackground iconbackground->setgeometry(spaceside, spacetop, bkgwidth,bkgheight); } Listing : Ausschnitt aus SBButton Klassenimplementierung [eigene Darstellung] Benutzerdefinierten Style erzeugen Um dem Template einen benutzerdefinierten Style zuzuweisen, müssen zumindest die Style Sheet Eigenschaften definiert werden, und, wenn nötig, die dafür erforderlichen Grafiken (z.b. für den Hintergrund) angefertigt werden. Die Style Sheet Eigenschaften der Klasse SBButton für den AppBrowser der AIS MFD Anwendung sind wie folgt definiert: #SBButton { min-height: 38px; max-height: 45px; min-width: 25px; max-width: 32px; } #SBButton #pushbutton { background-image: url(:/images/sbbutton-bkg.png); background-repeat: repeat-x; 68

80 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays font: 5 42pt "FreeSans"; font-weight: bold; padding-top: 2px; border: 2px solid #858585; } #SBButton #pushbutton:focus, #SBButton #pushbutton:hover, #SBButton #pushbutton:pressed { border-width: 7px 7px 7px 7px; border-image: url(:/images/sbbutton-border-active.png) 7 repeat; } #SBButton #pushbutton:pressed { color: rgb(7, 7, 7); } #SBButton #widget_icon_bkg { background-image: url(:/images/sbbutton-iconlayer-bkg.png); background-repeat: repeat-x; border: 2px solid #858585; } Listing : Qt Style Sheet Definition für die Klasse SBButton [eigene Darstellung] Für die Widget Klasse SBButton werden die CSS Eigenschaften für minimale und maximale Abmessungen gesetzt. Der Button Klasse pushbutton wird Hintergrund (sbbutton-bkg.png generiert einen transparenten Hintergrund), Schriftart und -größe, sowie ein Rand definiert. Für die speziellen States focus, hover und pressed der Klasse pushbutton (d.h. wenn der Button aktiv bzw. selektiert wird) soll die Umrandung aus einer Grafik generiert werden. Wird die Umrandung über die border-image Eigenschaft gesetzt, wird die dafür zu verwendende Grafik in einen 3x3 Raster unterteilt. Die 4 äußeren Ecken (I, III, VII, IX) werden unverändert für die Ecken der Umrandung übernommen, während die anderen Zellen nach Bedarf gestreckt, oder, wie oben definiert (repeat) repetitiv aneinandergereiht werden, um die Bereiche zwischen den Ecken zu füllen. Ist der Bereich der Zelle V gefüllt, also nicht transparent, würde damit zusätzlich auch der Hintergrund (alles innerhalb der Umrandung) gezeichnet werden. Im obigen Beispiel wird die border-image Grafik in jeweils 7x7 Pixel große Zellen unterteilt. Abbildung 25 veranschaulicht den Vorgang: a) ist die (vergrößerte) border-image Grafik, b) ist der Raster, nach dem die Grafik zerteilt wird, und in c) sind Grafik und Raster übereinandergelegt. 69

81 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Abbildung 25: border-image für #pushbutton:focus [eigene Darstellung] Bei Anwendung dieser CSS Eigenschaften auf eine Instanz der Klasse SBButton wird letztendlich der bereits wie in Kapitel modellierte Button generiert. 2 SBButton btn; btn.setstylesheet(style); Der Button selbst hat einen transparenten Hintergrund, lässt deshalb das (dahinterliegende) Parent-Window durchscheinen. Abbildung 26 zeigt das Aussehen eines generierten Button für die App Map, links im default Zustand und rechts im selektierten Zustand, mit angewandter border-image Eigenschaft. Abbildung 26: SBButton Beispiel für App Karte [eigene Darstellung] 7

82 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays 3.9 Verwaltung der AIS Daten AIS Daten werden über einen an eine externe RS232/RS422 Schnittstelle des MFD angeschlossenen AIS Transponder empfangen. Der Transponder sendet gekapselte Binärdaten im NMEA 83 Format (siehe Kapitel 2.3.5). Die NMEA Daten werden vom Coprozessor gelesen, dekodiert und über die SPI Schnittstelle mittels Direct Memory Access (DMA) in regelmäßigen Intervallen an den Hauptprozessor gesendet. Es wird immer ein Speicherblock fixer Größe transferiert. Dieser Speicherblock teilt sich in 2 Bereiche auf, nämlich a) Positionsreports und b) andere Nachrichten. Abbildung 27 zeigt die beiden Speicherbereiche A und B, die Positionsreports werden in M.x übermittelt, Nachrichten anderer Art in M2.x. Unbelegter Speicher (abhängig von der Anzahl empfangener AIS Nachrichten im jeweiligen Übertragungszyklus) wird als ungültig markiert. Abbildung 27: Speicherblock der SPI DMA Übertragung [eigene Darstellung] Die AIS Rohdaten werden von der Klasse AisReader im Intervall von Sekunde vom SPI Kernel Driver gelesen. Laut AIS Spezifikation können bei Vollauslastung beider AIS Kanäle maximal 75 Nachrichten pro Sekunde empfangen werden 27. Die Klasse AISInserter extrahiert die AIS Rohdaten aus dem gelesenen Speicherblock und schreibt diese in die AisDatabase. Bei Applikationsstart wird ein Singleton Objekt der Klasse AisDatabase instanziiert. Dies steht danach allen Applikationsmodulen und dynamisch geladenen Plugins zur Verfügung. Die Abfrage der AIS Daten erfolgt ähnlich wie bei einem Datenbankprovider. 27 Ergibt sich aus: 225 Slots/Minute => 37.5 Slots/Sekunde/Kanal 7

83 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Abbildung 28: Klassendiagramm AIS Modul [eigene Darstellung] Der folgende Codeausschnitt zeigt, wie eine typische Abfrage von AIS Daten erfolgt: AisDatabase::AisResult res; AisDatabase *aisdb = AisDatabase::instance(); // Query against ShipType AisTarget::ShipTypeOwnShip res = aisdb->querytargets(aistarget::shiptypeownship); if (res) { if (aisdb->fetchresult(res)) { AisTarget t; aisdb->getresultdata(t, res); if (t.mmsi()!= mownshipmmsi) { mownshipmmsi = t.mmsi(); } } } aisdb->freeresult(res); Listing 2: Anwendungsbeispiel der Klasse AisDatabase [eigene Darstellung] 72

84 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Mit AisDatabase::queryTargets() wird eine der überladenen Query Funktionen für Schiffsdaten aufgerufen. Die Definition von AisDatabase::queryTargets() sieht folgendermaßen aus: /** querytargets search list of mmsi to search AisResult (use for consecutive calls to getresultdata) * * Start a database query for targets */ AisResult querytargets(const QList<unsigned int>& search = QList<unsigned int>()); AisResult querytargets(const QList<quint8>& listtypeofship); AisResult querytargets(quint8 typeofship); AisResult querytargets(unsigned int mmsi); AisResult querytargets(const QList<unsigned int>& search, const QList<quint8>& listtypeofship); AisResult querytargets(const QList<unsigned int>& search, quint8 typeofship); Listing 3: Definition von AISDatabase::queryTargets() [eigene Darstellung] Schiffsdaten können nach MMSI und/oder nach Schiffstype gesucht werden. Dabei wird entweder ein bestimmter einzelner Wert, oder eine Liste von Suchwerten angegeben. AisDatabase::fetchResult() setzt das Resultat auf das jeweils nächste gültige Abfrageergebnis. AisDatabase::getResultData() schließlich liefert die aktuelle Ergebnisreihe zurück. Die AisDatabase sieht die Möglichkeit vor, für beliebige Targets eine Historie der empfangenen Positionsdaten zu speichern. Ist ein Target außer Empfangsreichweite, d.h. ist länger als eine definierte Zeitdauer keine Positionsmeldung mehr empfangen worden, verlieren die historischen Daten an Gültigkeit und werden aus der Datenbank entfernt. Dafür sorgt die Klasse GarbageCollector, die in regelmäßigen Zyklen die Datenbank aufräumt. Bevor ein Target-Datensatz tatsächlich aus der Datenbank gelöscht wird, wird das Signal datasetsmarkedfordeletion ausgelöst, um Modulen die Möglichkeit zu geben, darauf zu reagieren und dies am User Interface zu signalisieren. 3. Das Plugin System Die AIS Display Software hat die Architektur einer Plattform, die über dynamisch geladene Plugins ihre Funktionalität erweitert. Als Provider, oder Host, für Plugins stellt sie Basisfunktionalität zur Verfügung, wie z.b. die AISDatabase, das Konfigurationsmodul oder die User Interface Library. 73

85 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Zur Realisierung dieser Plugin Architektur werden vorrangig 2 Interfaces 28 definiert. Eines (IPlugin), das jedes Plugin implementieren muss, um dynamisch geladen zu werden. Als zweites Interface wird ein Host Interface (IHost) definiert. Das Host Interface wird von der AIS Display Software selbst implementiert, damit Plugins die Möglichkeit haben, eine Plugin zu Host Kommunikation durchzuführen. Abbildung 29 zeigt den prinzipiellen Aufbau des Plugin Systems: Abbildung 29: AIS Display Plugin Schema [eigene Darstellung] Ein Plugin besteht im Wesentlichen aus der Plugin Base Class, die Klasse, die das Plugin Interface implementiert, und, sofern das Plugin ein eigenes User Interface bereitstellt, aus der Kombination aus Model-View-Controller (MVC) Klassen (aus Zwecken der Übersichtlichkeit wurden in der Grafik nur die View (Vx) und Controller (Cx) Klassen abgebildet). Das MVC ist ein zusammengesetztes Software Design Pattern, das durch die Implementierung mehrerer Klassen die Anzeige- von der Business-Logik separiert (vgl. [49], S ). Das Plugin Interface definiert eine Reihe von Methoden zur Registrierung, Identifizierung, Initialisierung und Steuerung von Plugins. Die Definition dieser Klasse ist wie folgt: class IPlugin { public: virtual ~IPlugin() {} // A short name virtual QString // The Resource virtual QString 28 for the plugin getname() const = ; ID of the App Icon geticon() const = ; C++ besitzt kein Interface Sprachelement, daher ist hier mit Interface immer eine abstrakte Klasse (eine Klasse, die nur virtuelle Methoden besitzt) gemeint. 74

86 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays // A description (consists of about 3-8 words) virtual QString getdescription() const = ; // Activates the plugin (without UI) virtual void activate(bool isactive = true) = ; // The plugin should show the UI virtual void show(bool isvisible = true) = ; // Sets virtual // Sets virtual the parent window for the main widget void setparent(qwidget *parent) = ; the host interface to communicate back to the main app void sethost(hostinterface *host) = ; // Returns registered actions virtual QMap<QString, QString> pluginactions(qstring &key) = ; [ ] }; Q_DECLARE_INTERFACE(IPlugin, "com.ft-tec.aisd.iplugin/.") Listing 4: Plugin Interface Klasse [eigene Darstellung] Das Makro Q_DECLARE_INTERFACE() assoziiert einen eindeutigen Bezeichner mit diesem Interface. Dies ist eine Konvention des Qt Frameworks zur Identifizierung von zur Laufzeit geladenen externen Libraries, den Plugins (siehe Kapitel 2.5.4). Zur Herstellung eines bidirektionalen Kommunikationskanals wird das Host Interface definiert, das von der AIS Display Software implementiert wird. Über die Methode IPlugin::setHost() wird dem Plugin bei Initialisierung eine Referenz zur Host Applikation übergeben. Das Host Interface ist folgendermaßen definiert: class IHost { public: // Access to application wide configuration virtual QSettings appsettings() = ; // Access to common resources virtual const QPixmap &symbolshiptype(aistarget::shiptypes type) = ; // Access to common resources virtual const QString strshiptype(aistarget::shiptypes type) = ; [ ] // Special runtime configuration value 75

87 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays virtual unsigned int ownshipmmsi() = ; // Populate executed plugin action among other plugins virtual void populateaction(const QString &key, const QString &action, const QString &param) = ; [ ] }; Q_DECLARE_INTERFACE(IHost, "com.ft-tec.aisd.hostinterface/.") Listing 5: Host Interface Klasse [eigene Darstellung] Die AIS Display Software lädt bei Applikationsstart alle externen Plugins, die sich im Verzeichnis [AppDir]/plugins befinden: QDir dir(qapplication::applicationdirpath()); dir.cd(qstring("plugins")); foreach (QString filename, dir.entrylist(qdir::files)) { QPluginLoader loader(dir.absolutefilepath(filename)); if ((plugin = qobject_cast<appinterface *>(loader.instance()))) { plugin->setparent(this); plugin->sethost(this->mihost); mplugins.insert(plugin->getname(), loader.instance()); } } Listing 6: Laden der Plugins [eigene Darstellung] Schließlich werden nun für jedes geladene Plugin Einträge im Hauptmenü, dem App-Browser, zur Auswahl für den Benutzer hinzugefügt. Dafür wird die einzige Instanz der Springboard Klasse, die Teil der UI Library ist (siehe Kapitel 3.8), angelegt und mit Bezeichnung und Icon der Plugins initialisiert: UI::SpringBoard *appbrowser = new UI::Springboard(mMainWidget); // Loop through all plugins and add them to the browser QListIterator<QString> i(mplugins); IPlugin *plugin; while (i.hasnext()) { plugin = qobject_cast<iplugin *>(mplugins.value(i.next())); appbrowser->additem(plugin->getname(), plugin->getdescription(), 76

88 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays plugin->geticon()); } Listing 7: Initialisierung des Springboards [eigene Darstellung] 3. App: Kartenplotter Die Kartenplotter Anwendung der AIS Display Software wird als Plugin realisiert. Dafür wird das Interface IPlugin implementiert. Der folgende Block zeigt einen Code-Ausschnitt der Definition der Implementierungsklasse AppMap: class AppMap : public QObject, public IPlugin { Q_OBJECT Q_INTERFACES(IPlugin) public: AppMap(QObject *parent = ); private: // The View AppMapWidget *mainwidget; // The Controller AppMapController *mcontroller; // Mainly the Model IHost *mhost; public: // Implements the IPlugin interface QString getname() const { return tr("map"); } // Implements the IPlugin interface QString getdescription() const { return tr("navigational Map"); } [ ] } Listing 8: Implementierungsklasse AppMap [eigene Darstellung] Auch der Implementierungsklasse wird ein Qt Makro hinzugefügt. Q_INTERFACES() ist Teil des Qt-Plugin Mechanismus, es publiziert die Interfaces, die von dieser Klasse implementiert werden, hier: IPlugin. AppMapWidget ist die View Klasse der Kartenanwendung. Sie verwaltet User Interface spezifische Elemente des Kartenplotters und bringt sie zur Anzeige. Das UI besteht im Wesentlichen aus drei 77

89 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays wichtigen Elementen: der Statusleiste (Klasse: MapStatus), der Menüleiste (Klasse: Menu) und dem Widget, das die Karte und alle darauf dargestellten Objekte anzeigt (Klasse: QMapControl). Abbildung 3: AppMapWidget - View Klasse des Map-Plugins [eigene Darstellung] Das MapStatus Widget wurde speziell für dieses Plugin entwickelt, und zeigt diverse Navigationsinformationen im obersten Displaybereich an. Das Menu Widget hingegen ist ein Widget der UILibrary (siehe Kapitel 3.8) und wird auch von anderen Plugins eingesetzt. QMapControl ist das Widget, das die grundlegende Funktion des Kartenzeichnens erfüllt. Positionsbezogene Daten, wie die Positionen der über AIS empfangenen Schiffsdaten, werden ebenso darin abgebildet. Es wird im Folgenden genauer betrachtet. 3.. QMapControl QMapControl [5] ist ein von Kai Winter programmiertes Open Source Widget für das Qt Framework. Es wurde als Komponente für mobile Anwendungen entwickelt, die Kartenmaterial und positionsbezogene Daten darstellen. Folgende Eigenschaften, die das QMapControl Widget aufweist, waren erforderlich, um es für die Kartenanwendung als Viewer auszuwählen (vgl. [5], S. 3-32): 78

90 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Darstellung von Kartenmaterial Als Quelle für Kartenmaterial können Tile Server und Web Map Service (WMS) 29 Server dienen. Für die AIS Display Anwendung ist lediglich die Tile-Server-Komponente relevant. Platzierung von selektierbaren Objekten auf der Karte Es können Bilddateien oder geometrische Objekte auf der Karte platziert werden. Die QMapControl Bibliothek orientiert sich bei der Definition von geometrischen Objekten an der SFA Spezifikation von OGC (siehe Kapitel 2.4.3). Darstellung von mehreren Layern Durch die Unterstützung der Anzeige mehrerer Ebenen und von Transparenz, können Karten unterschiedlicher Quellen übereinander gelegt werden. Layer können ein- und ausgeblendet werden. Performance Das Widget ist für den Einsatz auf mobilen Plattformen mit begrenzter Speicher- und Rechenkapazität entwickelt. Plattform Linux Das Widget basiert auf dem Qt Framework, und ist somit theoretisch auf allen von Qt unterstützten Plattformen einsetzbar. Aus Benutzersicht funktioniert das Widget ähnlich wie herkömmliche Web-Karten, wie z.b. die Slippy Map von OpenStreetMap. Tiles für den jeweiligen Kartenausschnitt werden von der externen Quelle angefordert und im Viewer angezeigt, sobald sie heruntergeladen wurden. Auch während des Ladevorgangs kann der Kartenausschnitt durch Benutzeraktion verschoben, ein- oder ausgezoomt werden. Die Bibliothek wurde um einige Funktionen erweitert, wie z.b. Karten auch von lokaler Quelle zu lesen, anstatt lediglich von Quellen, die über das Internet erreichbar sind. Im Folgenden wird anhand des Einsatzes in der View Klasse AppMapWidget erklärt, wie das QMapControl Widget verwendet wird: // Create the MapControl Widget mmapctrl = new MapControl(QSize(width,height)); mmapadapter = new TileMapAdapter("file", "/path/to/tiles/%/%2/%3.png", 256,, 6); mmaplayer = new MapLayer("OpenStreetMap", mmapadapter); 29 WMS basiert auf einem OGC Standard. Über WMS Server wird Kartenmaterial über HTTP angefordert. 79

91 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays mmaplayer->setvisible(true); mmapctrl->addlayer(mmaplayer); Listing 9: Anwendung des QMapControl Widgets [eigene Darstellung] Nachdem das Viewer Widget als MapControl Objekt angelegt wurde, wird diesem zumindest eine Anzeigeebene über die Methode MapControl::addLayer() hinzugefügt. Ein Layer muss erstellt werden, um darin Kartenmaterial (oder geometrische Objekte) zur Anzeige zu bringen (vgl. [5], S. 49). Für das MapControl Objekt können beliebig viele Layer erzeugt werden. Was der Layer anzeigt, wird über den MapAdapter definiert, der ihm zugeordnet wird. Ein MapAdapter legt fest, von welcher Quelle Kartenmaterial zu laden ist, was von dieser Quelle geladen werden kann (d.h., ist die Quelle ein Tile Server oder ein WMS Server), welche Maße die Kartenkacheln haben und für welche Zoomstufen die Kartenausschnitte angezeigt werden sollen. Der MapAdapter führt Koordinatentransformationen durch und erstellt die Server Requests. Im zuvor angeführten Beispiel wird mit file angegeben, dass sich die Tile Dateien auf einer lokalen Ressource befinden. Der nächste Code-Ausschnitt zeigt, wie Geometrien (in diesem Fall das Image-Symbol eines AISTargets) über die Karte gelegt werden: // Create Geometry Layer mitemslayer = new GeometryLayer("Ships", mmapadapter); mmapctrl->addlayer(mitemslayer); void showtarget(const AisTarget &target, const AisDynamicData &dyndata) { // Add the ship as a point geometry to the layer Point* ship = new Point(dynData.position().x(), dyndata.position().y(), new QPixmap(*getSymbolPixmap(target.typeOfShip(), dyndata.cog())), QString("%").arg(target.mmsi())); mitemslayer->addgeometry(ship); } Listing 2: Anzeige von Geometrien [eigene Darstellung] Zuerst wird ein neuer GeometryLayer im MapControl Objekt angelegt. GeometryLayer sind Ebenen zur Anzeige von Geometrien. In diesem Fall wird dem Layer eine Point Geometrie hinzugefügt. Dem Point Konstruktor wird ein QPixmap Objekt übergeben, das, abhängig vom Schiffstyp und Kurs über Grund des Schiffs, das AIS Target an der definierten Position als Symbol anzeigt. 8

92 Kapitel 3. Entwicklung des AIS Multifunktionsdisplays Abbildung 3: Symbole für AIS Targets (Typ, Kurs) [eigene Darstellung] 3.2 Entwicklung für das Zielsystem Bei der Zielhardware (wie in Kapitel 3.4 vorgestellt), handelt es sich um eine Embedded Mikrocontroller Plattform. Der i.mx535 ist ein ARM Cortex-A8 Prozessor. Mit Qt/Embedded Linux (oder auch Qtopia Core genannt) stellt Qt eine eigene Version des Frameworks für den Embedded Bereich zur Verfügung. Qt/Embedded Linux hat dieselbe API wie die Desktop Versionen Qt/Windows, Qt/X und Qt/Mac, außerdem erweitert mit speziellen Klassen für die Entwicklung auf Embedded Systemen. Qt/Embedded Linux nutzt, anstatt eines X-Window Systems, sein eigenes Window System QWS. Dieses schreibt direkt in den Linux Framebuffer. Der Linux Framebuffer ist der Speicherbereich, der für die Displayanzeige reserviert und auf modernen Linux Systemen standardmäßig aktiviert ist. Dadurch fällt der Speicher und Performance Overhead, beides limitierte Faktoren auf Embedded Systemen, eines X-Servers weg. Die Applikation wird auf einem Host Rechner cross-kompiliert und dann auf das Zielsystem kopiert. Dafür muss am Host System, neben der Qt/X Standard Toolchain auch eine Toolchain für das Zielsystem eingerichtet werden. Für die einfache Entwicklung, Test und Debuggen der Applikation kann diese am Host System simuliert werden. Dafür existiert das X Programm Virtual Framebuffer von Qt, das den Linux Framebuffer der Zielhardware simuliert. Die Software muss dafür, bei gleichbleibender Codebasis, mit der sog. Qt/QVFB Toolchain kompiliert werden (vgl. [32], S ). 8