QNX CAR platform

Aus Winfwiki

Wechseln zu: Navigation, Suche

Fallstudienarbeit

Hochschule: Hochschule für Oekonomie & Management
Standort: Hamburg
Studiengang: Bachelor Wirtschaftsinformatik
Veranstaltung: Fallstudie / Wissenschaftliches Arbeiten
Betreuer: Prof._Dr._Uwe_Kern
Typ: Fallstudienarbeit
Themengebiet: Connected Cars
Autor(en): Tommy Kneetz, David Lange, Dirk Röschel
Studienzeitmodell: Abendstudium
Semesterbezeichnung:
Studiensemester: 2
Bearbeitungsstatus: begutachtet
Prüfungstermin:
Abgabetermin:

Inhaltsverzeichnis

1 Abbildungsverzeichnis

AbbildungErläuterungQuelle
Abb. 1 Rutschgefahr-Warnung zwischen BMW-FahrzeugenBMW AG (Hrsg.), http://www.bmw.de/de/de/insights/technology/connecteddrive/vehicletovehicle.html
Abb. 2 Überblick IEEE 802.11p Standardeigene Darstellung
Abb. 3 Überblick OSEK Architektureigene Darstellung
Abb. 4 Überblick AUTOSAR Schichtenmodelleigene Darstellung
Abb. 5 ArchitekturübersichtVgl. QNX Connected Automotive Reference, S. 11.
Abb. 6 Neutrino RTOS LayerQNX Software Systems (Hrsg.), http://www.qnx.com/images/products/rtos
Abb. 7 Neutrino Services LayerQNX Software Systems (Hrsg.), http://www.qnx.com/images/automotive/stack/
Abb. 8 Middleware Service - QNX Aviage Multimedia SuiteVgl. QNX Connected Automotive Reference, S. 16.
Abb. 9 Middleware Service LayerVgl. ebd., S. 16.
Abb. 10HMI LayerQNX Software Systems (Hrsg.),http://www.qnx.com/images/automotive/stack/
Abb. 11Third-Party TechnologienVgl. QNX Connected Automotive Reference, S. 11.

2 Abkürzungsverzeichnis

AbkürzungBedeutung
Abb.Abbildung
AMPAsymmetric Multiprocessing
BMPBound Multiprocessing
BNEPBluetooth Network Encapsulation Profile
BSPAutomotive Board Support Packages
bzw.Beziehungsweise
C2CCar-to-Car
C2ICar-to-Infrastructure
ECUElectronic control unit
GPOSGeneral Purpose Operating Systems
HFPHandsFree Phone
IPv6Internet Protokoll Version 6
ITSIntelligent Transportation System
KFZKraftfahrzeug
OSEKOffene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug
QDBQuotes DataBase
RSURoad-Side-Unit
RTOSReal-time operating system
SMBServer Message Block (Kommunikationsprotokoll)
SMPSymmetric Multiprocessing
STAStation (Wireless Client)
TDPTransparent Distributed Processing
VDXVehicle Distributed Executive
WAVEWireless Access in Vehicular Environments
WSMPWAVE Short Message Protocol

3 Einleitung

Heutzutage wird ein Großteil der Funktionen im Fahrzeug durch Software-Lösungen gesteuert oder erst durch solche verfügbar. Die Software im Auto muss dabei hohen Anforderungen wie Zuverlässigkeit, optimale Nutzung von Ressourcen, die auf Platz und Energie beschränkt sind, gerecht werden, dabei aber komplexe Systemarchitekturen zur Realisierung aller gestellten Anforderungen bieten.

Die Verbreitung einer Automotive Software-Lösung wird aufgrund neuer, preislich attraktiver Hardwarekomponenten, schon längst nicht mehr nur in Oberklassewagen, sondern auch in Mittelklasse- und Kleinwagen verwendet. Dies zeigt, das die Architekturen solcher Software-Lösungen für ein immer größer werdendes Spektrum an Anforderungen ausgelegt sein müssen.

In dieser wissenschaftlichen Arbeit werden Anforderungen an eine Automotive Software-Lösung analysiert und näher beschrieben. Bei der Auswahl der Anforderungen konnten aufgrund des festgelegten Umfangs der Arbeit nicht alle Bedingungen berücksichtigt werden. Die weiter unten ausgewählten Anforderungen setzen sich aus wichtigen Punkten zusammen, die jede Software erfüllen muss. Daneben werden Voraussetzungen an grundlegende Hardware-Komponenten, sowie allgemeine in Bezug auf das Bedienkonzept und dem Thema "Connected Car" entsprechenden Anforderungen an die Konnektivität betrachtet. Bei der Recherche solcher Anforderungen stößt man zwangsläufig auf das marktführende Produkt auf diesem Gebiet: Connected Automobile Reference (CAR) der Firma QNX Software Systems.

QNX CAR wird von den führenden Automobilherstellern wie Audi, BMW, Chrysler, Daimler, Fiat, Ford, General Motors usw. eingesetzt und ist bereits in über 10 Millionen Fahrzeuge integriert[1]. Diese dominierenden Referenzen führten dazu, QNX CAR in diese Hausarbeit mitaufzunehmen, um es gründlich zu analysieren.

Am Ende dieser wissenschaftlichen Arbeit werden die zuvor gestellten Anforderungen an eine Automotive Software-Solution mit dieser marktführenden Automotive Software-Solution verglichen. Ziel ist es herauszufinden, warum so viele Automobilhersteller auf QNX CAR setzen und eventuelle Nachteile aufzuzeigen.

4 Grundlagen

4.1 Connected Car

Nachdem sich die Kommunikation im Auto bislang auf BUS-Systeme wie den Controller Area Network Bus (CAN-BUS) beschränkte, welche lediglich innerhalb des Fahrzeugs mit den unterschiedlichen Bauteilen mittels Kabelverbindungen kommunizierte, entwickelt sich die Fahrzeugkommunikationstechnik in die Richtung von neuen Einsatzfeldern. Die Kommunikation soll zwischen Fahrzeugen (Car-to-Car) sowie zwischen Fahrzeug und fest installierten Netzkomponenten an der Fahrbahn (Car-to-Infrastructure) stattfinden. Diese Kommunikationstechniken haben als Hauptziel, die Sicherheit im Straßenverkehr zu erhöhen (Traffic Safety), zusätzlich den Verkehrsfluss zu optimieren (traffic efficiency & management) und den Infotainment Bereich im Auto zu revolutionieren. Folgend eine Auflistung möglicher Anwendungen.

4.1.1 Einsatzfelder

Abb. 1 - Rutschgefahr-Warnung zw. BMW-Fahrzeugen
Abb. 1 - Rutschgefahr-Warnung zw. BMW-Fahrzeugen

Car-to-Car (C2C) auch Vehicle-to-Vehicle (V2V)[2]

Traffic Safety Communication

  • Falschfahrer-Warnung
  • Rettungswagen-Ankündigung
  • Rutschgefahr-Warnung
  • Stauwarnung


Infotainment Communication

  • Telefonieren
  • Spielen
  • Chatten


Car-to-Infrastructure (C2I) auch Vehicle-to-Roadside (V2R)[2]

Traffic Safety Communication

  • Frühzeitiges Erkennen nicht sichtbarer Fahrzeuge
  • Kommunikation mit Ampelanlagen, Verkehrsschildern oder Schranken
  • Kommunikation mit Verkehrszentralen zur Optimierung des Verkehrsflusses


Infotainment Communication

  • Online-Streaming von Medieninhalten
  • Bezahlung in Parkhäusern
  • Herunterladen von Medien


4.1.2 Standards und Normen

Im Rahmen der Einführung oben beschriebener Fahrzeugkommunikationstechniken müssen Standards für die Automobilhersteller geschaffen werden, um die Produktion und Implementierung fahrzeugübergreifender Systeme sowie deren Kompatibilität zu ermöglichen. Dazu gibt es unterschiedliche Ansätze in Europa und den USA. In den USA ist ein Bündnis aus Verkehrsministerium (DOT) und Automobilhersteller vorwiegend für Forschung und Entwicklung von Protokollen und Techniken für den Einsatz auf der Straße zuständig. Im Mai 2002 wurde zudem das Vehicle Safety Communcications Consortium gegründet, welches an dem weiter unten beschriebenen IEEE 802.11p Standard arbeitet. In Europa gibt es zum einen national geförderte Forschungsprojekte, zum anderen das Car-to-Car Communications Consortium (C2C-CC), welches das Ziel hat, einen EU-weit offenen Standard für C2C Kommunikation auf WLAN-Basis zu entwickeln. Dem C2C-CC gehören viele große Automobilhersteller wie beispielsweise Audi, BMW, DaimlerChrysler und weiteren an.


Abb. 2 - Überblick IEEE 802.11p Standard
Abb. 2 - Überblick IEEE 802.11p Standard

IEEE 802.11p
Der IEEE 802.11p Standard, welcher auch als Wireless Access in Vehicular Environments (WAVE) bekannt ist, erweitert den IEEE Std 802.11, um die sichere, schnelle und vollständig kompatible Kommunikation zwischen C2C und C2I sicherzustellen, wie es unter anderem in der US National Intelligent Transportation Systems (ITS) Archiktektur beschrieben wird. Dazu wurden mit WAVE folgende Kommunikationsbedingungen angepasst[3]:

  • kurze Antwortzeiten (50ms – 100ms)
  • Reichweitenerhöhung (1m bis 1000m)
  • Sicherstellung der Funktionsfähigkeit bei hoher Geschwindigkeit (bis 200 km/h)
  • Multipath und Doppler Dienste (durch STA im Fahrzeug)


Durch die Nutzung des Frequenzbereichs von 5.85 bis 5.925 GHz können die gleichen Endgeräte (Sender und Empfänger) des 802.11a/b/g verwendet werden, was den WAVE Standard als kostengünstig und ressourcensparend auszeichnet. Als Protokoll wird zum einen das bekannte IPv6 zur Kommunikation auf Internetbasis eingesetzt, zum anderen wurde das WAVE Short Message Protocol (IEEE 1609.3) entwickelt, das durch kleine Paketgrößen und 1-hop-Nachrichten sehr effizient arbeitet[3].


IEEE 1609.2
Die IEEE 1609 ist eine Arbeitsgruppe, die Protokolle für Anwendungen im Fahrzeugumfeld auf der Basis von IEEE 802.11 standardisiert. Mit IEEE 1609.2 wurde der Standard entwickelt, welcher die sichere Nachrichtenkommunikation mittels Zertifikaten für den oben genannten WAVE Standard auf Basis von AES gewährleistet.


Abb. 3 - Überblick OSEK Architektur
Abb. 3 - Überblick OSEK Architektur

OSEK/VDX Standards
Die OSEK/VDX ist ein Standardisierungsgremium, das im Mai 1993 mit dem Ziel gegründet wurde, einen eigenen Industriestandard zu schaffen, welcher eine offene Architektur für die verteilten Steuereinheiten im Fahrzeug beschreibt. Gründungsmitglieder waren unter anderem verschiedene Kfz-Hersteller wie BMW, Daimler Benz, Opel und Volkswagen, sowie deren Zulieferer Bosch und Siemens. Die Motivation für die Gründung war die Beseitigung von hohen, wiederkehrenden Unkosten in der Entwicklung und im Variantenmanagement für die Software von Steuereinheiten, sowie die Unvereinbarkeit der Steuergeräte verschiedener Hersteller[4].

Dazu wurden unter anderem folgende Standards ausgearbeitet:

OSEK-OS (v2.2.3) als wichtigster Standard beschreibt ein Betriebssystem, das als Grundlage für mehrere unabhängige Anwendungsprogramme dient und einen Echtzeitbetrieb ermöglicht. Die Architektur des OSEK / VDX OS unterscheidet drei Ebenen der Verarbeitung: die Interrupt-Ebene, die logische Ebene für Betriebssysteme-Aktivitäten und die Aufgabenmanagement-Ebene. Die Interrupt-Ebene ist höher priorisiert als die Aufgabenmanagement-Ebene. Zusätzlich zur Verwaltung der Prozess-Ebenen gibt es Betriebssystem-Dienste, die für Funktionen wie Task Management, Event Management, Ressourcenmanagement sowie zur Alarm- und Fehlerbehandlung vorgesehen sind[5].

OSEK-COM (v3.0.3) steht für Kommunikation und bildet eine einheitliche Umgebung für die Kommunikation von Automotiven Steuerelementen. Durch die Spezifikation wird die Portabilität von Anwendungssoftware durch einheitliche Kommunikationsschnittstellen erhöht. Dies gilt für die interne Kommunikation von elektronischen Steuergeräten sowie für die externe Kommunikation zwischen unterschiedlichen Steuergeräten[6].

OSEK-NM (v2.5.3) steht für Network Management und beschreibt einen einheitlichen Standard, welcher Fehlfunktionen in der Kommunikation von ECUs unterschiedlicher Hersteller aus einer dedizierten Netzwerk-Management-Komponente verhindert. Dazu muss der Status des Netzwerkes überwacht und ausgewertet werden, was durch eine direkte und indirekte Überwachung erreicht wird[7].


Abb. 4 - Überblick AUTOSAR Schichtenmodell
Abb. 4 - Überblick AUTOSAR Schichtenmodell

AUTomotive Open System Architecture (AUTOSAR)
AUTOSAR ist eine offene und standardisierte Softwarearchitektur, welche gemeinsam mit Automobilherstellern, Zulieferern und Anwendungsentwicklern entworfen wurde.
Unter der Grundidee "Zusammenarbeit bei Standards - Wettbewerb bei der Umsetzung" ebnet AUTOSAR den Weg für innovative elektronische Systeme und berücksichtigt Performancesteigerungen, Sicherheit und Umweltfreundlichkeit. Bei der technischen Umsetzung setzt AUTOSAR grundlegend auf ein Schichtenmodell, um die Anwendungsschicht durch die Zwischen- /Middlewareschicht von der Hardwareschicht zu trennen und somit von Kommunikationsbeziehungen unabhängig zu machen. Dies ermöglicht es, eine Software zu entwerfen, welche auf unterschiedlichsten Hardwarekomponenten lauffähig und somit flexibel ist. In der Abbildung 4 wird zur Veranschaulichung das Schichtenmodell, ohne die einzelnen Komponenten der jeweiligen Schicht, dargestellt.

4.2 QNX

4.2.1 Firma

QNX Software Systems wurde 1980 noch unter dem Namen Quantum Software gegründet und hat das Echtzeitbetriebssystem QUNIX (später QNX) entwickelt. Angefangen als Betriebssystem für den Standard-Arbeitsplatzrechner der Hochschule Ontario verbreitete sich QNX im Markt eingebetter Systeme,[8] auch embedded Systeme genannt, und wurde auf verschiedene Plattformen portiert. Im Jahre 2001, nachdem der Betriebssystem-Kernel von Grund auf neu geschrieben wurde, um Kompatiblität zu SMP[9] und POSIX[10] zu gewährleisten, wurde das Produkt QNX in QNX Neutrino umbenannt und kommerziell angeboten. Das Angebot umfasst auch Entwicklungstools sowie Middleware und Services für die Entwicklung und Implementierung in embedded Systeme. QNX Software Systems ist Vorreiter bei technologischen Innovation. Auf ihrem Weg von der Entwicklung des weltweit ersten mit Sicherheitsmodus ausgestatteten Echtzeitbetriebssystems bis hin zur Verwirklichung der ersten umfassenden Software-Plattform für Embedded-Multicore-Prozessoren, erhielten sie zahlreiche Auszeichnungen für Innovation, Qualität und Industriellen Fortschritt ihrer Produkte. Ende 2007 begann das Unternehmen mit der Veröffentlichung des Quelltexts vom QNX Neutrino Kernel über das eigene Community Portal foundry27.com und ermöglichte so die Nutzung des Betriebssystems für nicht-kommerzielle Zwecke. Nicht zuletzt dadurch hat sich QNX Neutrino seit langem besonders in den drei Bereichen "Steuerung & Automatisierung", "Medizintechnik" und "Automotiv & Telematik" etabliert und ist hier heute mit vielen Kunden vertreten.

4.2.2 Produkt CAR

Mit dem Connected Automobile Reference (CAR) Programm hat das Unternehmen QNX im Februar 2009 ein Programm gestartet, welches die Entwicklung, Implementierung und Aktualisierung von In-Car-Systemen für Automobilhersteller (OEMs), Tier-1 Zulieferern sowie den Endkunden revolutioniert hat. Dazu werden von QNX neben sofort nutzbaren Referenzimplementierungen, welche eine Vielzahl von Hardwarekomponenten unterstützen und somit einen schnellen Aufbau von Software-Lösungen versprechen, auch ein neues Geschäftsmodell zur risikofreieren und kostengünstigen Entwicklung, ein umfangreiches Netzwerk mit über 50 Technologiepartnern und die Onlineplattform foundry27.com angeboten, auf welcher QNX Entwickler bei der Implementierung unterstützen und aktuellen Softwarecode veröffentlichen. Dies kommt vor allem Zulieferern für Automobilkonzerne zugute, welche sonst einen Großteil Entwicklungsarbeit investieren müssen, um Hardwareunterstützungen sowie Software-Lösungen aufzubauen, um dem Kunden ansprechende Beispiele demonstrieren zu können.[11]

QNX bestätigt seine Position als Marktführer im Bereich Automotive Infotainment und Telematik mit der Integration in über 17 Millionen Autos von Automobilherstellern wie Beispielsweise Acura, Audi, BMW, Cadillac, Chrysler, Fiat, Ford, Honda, Land Rover, Volkswagen u.v.a.

5 Anforderungen an eine Automotive Software-Lösung

5.1 Allgemeine Anforderungen

5.1.1 Benutzerfreundliche Bedienbarkeit

Heutzutage steigt die Anzahl von Applikationen, Funktionen und neuen Technologien in Fahrzeugen stetig an, wodurch diese komplexer in der Bedienung und in der Administration werden. Daher hat die Bedienbarkeit der Geräte, und damit die Software-Lösungen, eine besonders hohe Priorität. Eine intuitive Bedienung, sowie die einfache und schnelle Handhabung helfen enorm, die Benutzerfreundlichkeit zu steigern. Technische Lösungen dafür sind zum Beispiel das (Multi-)Touchscreen, die „Multifunktionstasten“ oder die sprachgesteuerte Bedienung.

Schon das Alter der Anwender kann einen großen Unterschied im jeweiligen Empfinden ausmachen. Ford hat beispielsweise sogenannte "Altersanzüge" (Third Age Suits) entwickelt, die in der Konzeption neuer Fahrzeuge eingesetzt werden. Das Tragen dieses Anzuges ermöglichte den Ingenieuren, sich in den Zustand von älteren oder auch jüngeren Menschen zu versetzen, die in ihrer Mobilität eingeschränkt sind[12].


Für die Benutzerfreundlichkeit gibt es die Richtlinie "Interaktion zwischen Mensch und Maschine", die in der Norm ISO 9241 Abschnitt 11 beschrieben ist. Dort werden Anforderungen an die Arbeitsumgebung, an die Hardware und an die Software beschrieben, und die drei Kriterien Effektivität, Effizienz, und Zufriedenheit werden durch diese Norm definiert. Diese Kriterien wiederum können "gemessen" und ausgewertet werden[13].

5.1.1.1 Effektivität

Was ist das Ziel? Wie genau und vollständig kann ein Anwender dieses Ziel mit einem System erreichen? Gemeint ist, dass eine gestellte Aufgabe korrekt und zu 100 Prozent erfüllt werden muss und das System dafür passende Dialogschritte bereitzustellen hat, um dies zu unterstützen.

5.1.1.2 Effizienz

Wie hoch ist der Aufwand, den ein Anwender für eine Aufgabe benötigt? Die Zeit ist hier ausschlaggebend und die Frage, ob eine Aufgabe mithilfe einer neuen Software oder auch Hardware schneller umgesetzt werden kann. Diese Zeit ist messbar und damit auch auszuwerten, um Rückschlüsse auf die benutzerfreundliche Bedienbarkeit zu ziehen.

5.1.1.3 Zufriedenheit

Ist die Nutzung der neuen Hardware/Software angenehm, so kann das ebenfalls gemessen werden. Zum Beispiel können die positiven und negativen Kommentare während der Verwendung gezählt werden. Die Häufigkeit des Produktkaufs und die eventuellen anschließenden Beschwerden geben Aufschluss über die Zufriedenheit der Konsumenten[14].

5.1.2 Implementierbarkeit

Bei der Implementierbarkeit zählen vor allem Standards. Ist es für Hersteller und auch für Endanwender leicht, bekannte und bestehende Hardware- und Softwarestandards zu nutzen, umso mehr Kompatibilität wird es geben. Diese vielfältigen Möglichkeiten erlauben sehr viele verschiedene Kombinationen von Hard- und Software und somit eine große Palette an Lösungen[15].

5.1.3 Konnektivität

Unter Konnektivität wird eine Verbindung zwischen zwei oder mehreren Komponenten verstanden. Diese können kabellos oder kabelgebunden hergestellt werden. Bezogen auf das Auto und auf diese Fallstudie wurden die folgenden drei Beispiele zur genaueren Untersuchung ausgewählt. Dies sind längst nicht alle Möglichkeiten, jedoch musste aufgrund der hohen Komplexität die Auswahl eingeschränkt werden.

5.1.3.1 Internet

Das Internet spielt heutzutage in vielen Situationen und in vielen Bereichen des täglichen Lebens eine große Rolle. Daher auch für eine Automotive Software-Lösung. Das Internet erlaubt Zugriffe auf Updates, Zusatzanwendungen, Zusatzfunktionen und auf Multimediainhalte, die die Automotive Software erweitern und aktualisieren können. Durch das Internet könnten auch im Auto die Social Networks Einzug erhalten. Generell stehen durch das Internet viele Möglichkeiten offen, die auf einer Seite die Sicherheit erhöhen (wie z.B. Verkehrsinfos), auf der anderen Seite die Software durch zusätzliche Applikationen erweitern bzw. aktualisieren können. Im Großen und Ganzen bietet das Internet eine Menge an Informationen, die dazu prädestiniert sind, diese im Auto zur Verfügung zu stellen.

5.1.3.2 Handy

Ebenfalls schon ein Standard, das Handy. Ganz wichtig also die Möglichkeit, das Handy mit dem „Auto“ zu verbinden. Bekannte Standards sind Bluetooth oder kabelgebundene Lösungen. Die Verbindung erlaubt neue Funktionen bzw. Möglichkeiten, mithilfe der Automotive Software auf die Inhalte des Handys zuzugreifen. Im Vordergrund stehen hierbei die Kontakte und die Möglichkeit der Annahme und Abweisung von Anrufen, ohne das Handy zu verwenden. Darüber hinaus gibt es weitere interessante Funktionen wie die Freisprecheinrichtung, die ein Muss darstellt.

5.1.3.3 Netzwerke

Wie mit vielen anderen Geräten soll auch im Automobil der Netzwerkzugriff Einzug erhalten. Hier kann man zwischen Heim- und Firmennetzwerken unterscheiden. In beiden Netzwerken gibt es Informationen / Daten, die es zu übertragen gilt. Ebenfalls sehr interessant ist der Zugriff vom Automobil auf Geräte in den Netzwerken und umgekehrt. Zum Beispiel können vom privaten Rechner aus die MP3-Dateien mit dem Automobil ausgetauscht oder einfach eine Zustandsüberwachung des Fahrzeuges durchgeführt werden.

Media Oriented Systems Transport (MOST) ist der aktuelle Standard für Multimedia- und Infotainmentnetzwerke in Fahrzeugen. Alle sieben Schichten des OSI/ISO Schichtenmodells werden durch MOST abgedeckt und durch einheitliche Schnittstellen wird die Implementierung des MOST Protokolls in Multimediageräten vereinfacht. Einfach ausgedrückt stellt MOST eine einheitliche, objektorientierte Schnittstelle dar, um die Gerätefunktionalitäten verwenden zu können. Ein MOST Netzwerk, welches meist ein Ring darstellt, kann bis zu 64 Geräte umfassen[16].

Zusätzlich bzw. ergänzend zur MOST Technologie wurde ein Konzept zur Verwendung von Ethernet/IP erarbeitet. Ethernet hat sich bereits in der Industriellen IT als sicheres und zuverlässiges Netzwerk bewährt. Die offenen Standards und die vielen möglichen Protokolle ermöglichen die einfache Integration von mobilen Geräten in das Auto. Ethernet wird bereits in ersten Fahrzeugen getestet und es scheint, dass Ethernet für die Industrie immer relevanter wird. Vorstellbar ist auch der Einsatz bei sicherheitskritischen Funktionen. Zum Beispiel zur Aktualisierung von Sensordaten bei Fahrerassistentsystemen [17].

5.1.3.4 Navigation

Im Bereich der Navigation sind ebenfalls Standards etabliert, die drahtlos Informationen mit dem "Auto" bzw. mit dem Navigationssystem im Auto austauschen. Dazu zählt GPS und TMC.

GPS

Das vom amerkianischen Verteidigungsministerium entwickelte System besteht aus 30 Satelliten, die die Erde in einer nominellen Höhe von 20200 km umkreisen. Die GPS-Satelliten senden Signale aus, die eine genaue Ortsbestimmung von GPS-Empfängern ermöglichen. Die Ermittlung der Position ist für Empfänger möglich, wenn sie feststehend sind, sich auf der Erdoberfläche, in der Erdatmosphäre oder in den niederen Umlaufbahnen bewegen. Vor allem in der Luft-, Land- und in der Seefahrt wird GPS erfolgreich eingesetzt, um die Positionen zu bestimmen. Das GPS-Signal wird jedem kostenlos zur Verfügung gestellt. Eigentlich heißt das System Navigation System for Timing and Ranging (NAVSTAR), jedoch wurde es unter dem Namen Global Positioning System (GPS) bekannt[18].

TMC

TMC steht für Traffic Message Channel und ist ein digitaler Radio-Datendienst, der in RDS ausgestrahlt wird. Geeignete Empfangsgeräte können dann über diesen Dienst Verkehrsstörungen (z.B. Staumeldungen) empfangen. Durch das ständige Senden des Signals erhalten die Nutzer die Informationen öfter und sind damit aktueller informiert als durch das Radio. Durch einen TMC-Empfänger oder ein TMC-Modul kann die Navigationssoftware die Verkehrsmeldungen empfangen und auswerten. Die meisten Navigationssysteme, zumindest die neuesten Modelle, berechnen automatisch eine Umleitung und warnen den Fahrer[19].

5.2 Software-Anforderungen

5.2.1 Betriebssystem

Im Automobil treffen zwei Bereiche aufeinander, die die Anforderungen an ein Betriebssystem stellen. Auf der einen Seite gibt es das Infotainment (Audio, Video, Telefonie, Internet, Navigation), das Anforderungen vorgibt. Dafür werden recht leistungsfähige Rechnersysteme benötigt (32-Bit Technologie). QNX, VxWorks, WindowsCE und Linux sind hier oft vorzufinden. Der zweite Bereich ist der "klassische" Steuerungsbereich, der die Mechatronik des Automobils steuert und überwacht. Dieser Bereich hat als wichtigste Anforderung den "Echtzeitbetrieb". Die exakte Anforderung ist wiederum vom Steuergerät bzw. von der zu überwachenden Komponente (z.B. Einspritzanlage, ABS, die Airbags oder die Fensterheber) abhängig. Echtzeitbetriebssysteme (RTOS) müssen auch im ungünstigsten Fall die Dienste für die Anwendungsprogramme verrichten können.[20]

Warum sich bei einem embedded System ein Real-time Operating Systems (RTOSs) und kein General Purpose Operating Systems (GPOSs) anbietet, zeigt ein Blick auf die geforderten Anforderungen an ein embedded System in Bezug auf die Betriebssystemtypen. Wenn mehrere Prozesse gleichzeitig gestartet werden, kann es in einem Auto von großer Relevanz sein, welcher Prozess wann ausgeführt wird. Hier bietet ein RTOS für Entwickler die Möglichkeit zur Festlegung von Reihenfolgen. GPOS arbeitet "fair" und kann dadurch keine Priorisierung der Prozesse gewährleisten, da hier die Prozesse standardmäßig nach der Reihenfolge der ausgeführten Prozesse ausgeführt werden. Die Eigenschaft der "Priorisierung" kann besonders in den Einsatzgebieten von embedded Systemen, z.B. Auto im Straßenverkehr oder in Flugzeugen, überlebenswichtig sein.[21]

Weitere Funktionen eines RTOS gegenüber einem GPOS sind:

  • Vorhersagbarkeit: Die Zeit für die Ausführung eines Prozesses muss begrenzt sein
  • Skalierbarkeit: Skalierbarkeit ist die Zerlegung des Betriebssystems in kleine Teile, welche einzeln angesprochen werden können, um die Ressourcenverteilung schneller und besser zu koordinieren
  • Robustheit: Ein RTOS besitzt gegenüber einem GPOS Methoden, wodurch das Risiko eines Absturzes minimiert bzw. verkürzt wird

5.2.2 Sicherheit

Vor dem Hintergrund, dass immer mehr Software in Autos integriert wird, wird es für Automobilhersteller und Zulieferer immer wichtiger, auch die Bestandteile eines Steuergeräts vor unbefugtem Zugriff zu schützen. Außerdem müssen Schutzmechanismen erstellt werden, die in betriebliche Abläufe integriert werden, um das Risiko eines Fehlverhaltens von Automobilkomponenten und damit das Sicherheitsrisiko für Fahrer und Fahrzeug durch Software-Schutzmechanismen zu minimieren.

Durch die Kommunikation von Fahrzeugen über das GSM, UMTS-Netz oder Wireless Lan steigt die Gefahr eines fremden Zugriffs auf das System. Hierdurch ist es möglich, Zugangsdaten von Fahrzeugen einzusehen oder sogar den Zugriff auf Steuergeräte des Autos zu bekommen. Die beste Methode, um sich davor zu schützen, ist die Kryptographie der Systemdaten und die Verschlüsselung des Systemzugangs. Eine Möglichkeit hierfür ist die Hinterlegung von verschlüsselten Zugangsdaten im Autoschlüssel oder ein passwortgeschützter Zugriff, welcher den Benutzer dazu berechtigt, auf das System zuzugreifen.[22]

Ein weiteres Problem beim Einsatz von Sicherheitssoftware in Fahrzeugen ist die beschränkte Aktualisierung von nachträglichen Schutzmechanismen. Aus diesem Grund muss das System bereits in der Entwicklung so gut wie möglich abgesichert und anschließend durch Sicherheitsupdates aktuell gehalten werden. [22]

Dennoch gibt es immer noch die Problematik, dass das System interne Probleme hat und die benötigten sicherheitsrelevanten Systeme nicht zur richtigen Zeit zur Verfügung stehen. Um dieses Problem so gut wie möglich zu beseitigen, ist der Einsatz eines Echtzeitbetriebssystems notwendig. Hierdurch wird gewährleistet, dass die benötigten sicherheitsrelevanten Systeme in kürzester Zeit angesprochen werden.

5.2.3 Erweiterbarkeit

Erweiterbarkeit in einer Automotive Solution muss unterteilt werden in eine Erweiterung der Bedienoberfläche von Autoherstellern und der Implementierung von neuen Funktionen.

Das Verändern der Bedienoberfläche von Software ist ein beliebtes Mittel von Herstellern, um sich trotz gleicher Softwarebasis von der Konkurrenz abzuheben. Das Alleinstellungsmerkmal wird vor allem durch die Steigerung der Bedienung und Übersichtlichkeit erzielt. So ist es bereits seit Jahren in der Mobilfunkbranche für einige Hersteller Standard, ihre eigene Oberfläche auf die gegebenen Betriebssysteme zu integrieren. Ein Beispiel hierfür ist der Hersteller HTC, welcher seine "Sense" Oberfläche sowohl auf Windows Mobile Geräten, sowie auf Android Smartphones integriert hat. Um diese Oberflächen-Erweiterung zu ermöglichen, sollte die HMI Schnittstelle einer Automotive Solution veränder- und erweiterbar sein.

Der zweite Grund zur Erweiterung von bestehenden Automotive Solutions liegt darin, auch in bestehende Geräte weitere Funktionen integrieren zu können. Ein Auto hat im Durchschnitt eine Lebensdauer von 12 Jahren[23] , so dass neue Technologien und Anwendungen schnell veraltet sind. So geht man davon aus, dass gerade mal 30% der Autos nach 5 Jahren auf dem aktuellen Stand der Technik sind. Ein Beispiel für eine neue Technologie ist die Einführung von neuen Übertragungsstandards wie z.B. LTE. Um solche Technologien im Nachhinein in die Automotive Solution zu integrieren, muss hierfür von den Software-Architekten eine Möglichkeit zur nachträglichen Anbindung an die Software gewährleistet werden. Solch eine Architektur wird als offene Systemarchitektur bezeichnet [24]

Ein Punkt, welcher die Erweiterbarkeit von Automotive Plattformen in der aktuellen Zeit noch wichtiger macht, ist die Anbindung neuer Anwendungen und Applikationen. Ist die Plattform offen für die Integration neuer Applikationen, welche womöglich nicht vom Hersteller kommen? So gibt es seit einiger Zeit in der Mobilfunkindustrie immer häufiger die Änderung der alten geschlossenen Systeme auf offene Systeme. So hat das Unternehmen Apple durch die Einführung des Apple App Store als erstes erfolgreich die Erweiterbarkeit seines Smartphones für freie Programmierer eröffnet. Durch diese Änderung der Politik gegenüber Anwendungen wurde ein komplett neuer Markt eröffnet. Diese Möglichkeit zur Integration neuer Applikationen sollte auch eine Automotive Solution besitzen, um so die täglich wachsende Anzahl an Anwendungen zu ermöglichen.

5.2.4 Update-Fähigkeit

Die Wichtigkeit von Software-Aktualität in Fahrzeugen wurde bereits unter Punkt 5.2.3 beschrieben. Neben der Integration von neuen Funktionen und Anwendungen muss auch die Aktualisierung des Systems und verwendeter Applikationen ermöglicht werden.

Der wichtigste Grund für die Aktualisierung des Betriebssystems ist die Sicherheit. Durch die immer weiter verbreiteten Viren, Würmer und anderen Computer-Schädlinge, ist die Erneuerung von Virendefinitionen und anderen Abwehrmechanismen nötig. Nur durch die ständige Aktualisierung solcher Definitionen ist eine erfolgreiche Abwehr möglich, da die Angreifer ständig neue Möglichkeiten entdecken, um ihre Attacken durchzuführen. Aus diesem Grund muss das Betriebssystem durch sogenannte Sicherheits-Updates von bestehenden Sicherheitslücken befreit werden.

Die Schwierigkeit für Updates in Automotive Plattformen ist der Weg zur Aktualisierung. Beispielsweise werden solche Updates bei den standardmäßigen Serviceintervallen in Autowerkstätten durchgeführt. Diese Autoinspektionen sind in der Regel alle zwei Jahre durchzuführen, was viel zu selten ist, um das System auf dem neuesten Stand zu halten. Aus diesem Grund muss das System und die Software einer Automotive Solution via Internetverbindung auf den neuesten Stand gebracht werden, um die Sicherheit sowie den aktuellsten Stand des Systems und der Anwendungen gewährleisten zu können.

5.3 Hardware-Anforderungen

5.3.1 Prozessoren

Gerade Prozessoren im Automobilbereich müssen bestimmte Anforderungen erfüllen. So sind Eigenschaften wie Preis, Leistungsaufnahme, eine hohe Resistenz gegenüber Wärme und Kälte sowie die Größe der Komponenten bei jedem im Automobil eingesetzten Prozessor zu berücksichtigen. Andere Eigenschaften wie Leistung, Befehlssatz, Architektur, Komplexität in Form von 8/16/32-Bit und Anzahl der Kerne sind von dem Einsatzgebiet abhängig.

Ein Einsatzgebiet sind Steuergeräte, welche z.B. für Motorsteuerung, Fahrzeugbeleuchtung, Fensterheber, Kombi-Instrumente und Airbags, aber auch für Fahrzeugsicherheitsmodule wie ABS oder ESP zuständig sind. Hier werden aufgrund ihrer Vorzüge meist Mikroprozessoren beziehungsweise Mikrocontroller eingesetzt, welche neben dem Prozessor schnelle, energieeffiziente Flash-Speicherchips besitzen und zusammen platzeffizient auf Halbleiterchips untergebracht werden.

Prozessoren im Einsatzgebiet von Automobile-Infotainment benötigen hingegen eine wesentlich höhere Performance und Kompatibilität, um Soft- und Hardware aus dem Heim-/Desktopbereich zu unterstützen und somit schnell und ohne kostenintensiven Entwicklungsaufwand viele Technologien und Anwendungssoftware zu unterstützen.

Eine Automotive Software-Lösung muss somit sehr flexibel und umfangreich in der Unterstützung der verschiedenen Prozessoren mit ihren spezifischen Eigenschaften sein.

5.3.2 Schnittstellen

Ein Infotainment-System für das Auto muss standardisierte Schnittstellen aus dem Automobilbereich wie CAN und MOST unterstützen und zusätzlich gängige Schnittstellen für Endgeräte der Verbraucher anbieten, um den Anforderungen gerecht zu werden.

Anbei folgt die Beschreibung ausgewählter Schnittstellen, welche aufgrund der starken Verbreitung und der Erweiterung des Funktionsumfangs im Automobil aufgenommen wurden.

Controller Area Network, kurz CAN, ist ein von Bosch entwickeltes Bussystem und wurde als ISO 11898 international standardisiert. Es verbindet die einzelnen Steuergeräte des Fahrzeugs untereinander und wird heutzutage in nahezu jedem Auto eingesetzt. Durch die Anbindung des CAN-Bus an ein Infotainment-System können fahrzeugspezifische Einstellungen wie Klimaeinstellungen, Standheizung, Sitzeinstellungen u.v.a. in einer benutzerfreundlichen Oberfläche vom Fahrzeughalter geändert, sowie der Status des Fahrzeugs (Reifendruckkontrollanzeige, Ölstand etc.) jederzeit abgerufen werden.

Media Oriented Systems Transport, abgekürzt als MOST, ist ein spezielles Infotainment-Kommunnikationssystem, welches vorhandene Multimedageräte im Fahrzeug wie z.B. den Verstärker, den CD-Wechsler oder das Radio verbindet. Als Besonderheit ist neben der Übertragung von Audio- und Videodaten das sogenannte Application Framework zu nennen. Es steuert die Logik zwischen der am MOST-Bus angeschlossenen Geräte, so dass z.B. die Radioübertragung ausgeschaltet wird, wenn ein Anruf eingeht.[25] Durch die Anbindung der Multimediageräte ist die Unterstützung des MOST-Bus eine wichtige Anforderung einer Automotive Software-Lösung.

Universal Serial Bus ist der als USB weit verbreitete Standard für PC-Peripherie-Geräte wie Drucker, Festplatten, Maus und Tastatur u.v.a., welche vornehmlich im Consumer Bereich zum Einsatz kommen. Die USB-Spezifikation sieht einen Host-Controller vor, welcher die Aufgabe hat, die Koordination oben genannter Geräte zu übernehmen. Für den Automotiv Bereich werden spezielle Controller benötigt, die Spezifikationen wie AEC Q100 unterstützen, um den Betrieb bei Temperaturen zwischen -40 und +150°C zu gewährleisten.[26]

Weiter beschreibt die Spezifikation den Aufbau eines USB-Kabels mit vier Adern. Diese unterteilen sich in zwei für die Übertragung von Datensignalen und zwei zur Stromversorgung (5V, 2.5W). Sie versorgen damit, Geräte welche keine eigene Energiequelle haben, mit Strom. Diesen Vorteil nutzen Geräte wie USB-Speichersticks aus, auf welchem sich im handlichen Format mehrer Gigabyte Daten transportieren lassen. Anwendungsbeispiele von USB-Port im Auto: Dateischnittstelle zur Übertragung von Audio- und Videodateien ans Entertainmentsystem, als Diagnoseschnittstelle des Fahrzeugs oder einfaches aufladen des Mobiltelefons. [27]

6 QNX CAR Plattform als Automotive Software-Lösung

QNX Connected Automotive Referenz (CAR) ist eine Software, welche Funktionen bietet, die an eine heutige Automotive Solution gestellt werden. CAR bietet laut QNX eine Reihe von Referenzimplementierungen, Werkzeugen sowie Dienstleistungen, um eine individuelle Kundenlösung in Automobile zu integrieren. [28] Durch die Referenzimplementierung entfällt die Erstintegration, d.h. die Abstimmung der Software auf den Prozessor.

Zudem baut QNX auf die Zusammenarbeit mit 90 Technologie-Partnern, welche ergänzende Hard- und Software für CAR bereitstellen. [29]

Die Funktionen von CAR erstrecken sich z.B. von Navigation, Spracherkennung über die Verbindungsmöglichkeit mit portablen Geräten, Bluetooth, Musikmanagement, bis hin zum Internetradio sowie anderen Funktionen, welche im Automotive Bereich gefragt sind. [29]

Der Kern von QNX CAR ist das Betriebssystem QNX Neutrino OS, welches speziell für embedded Systeme erstellt wurde. Im folgenden werden die Software-Architektur und die einzelnen Technologien, welche CAR bietet, beschrieben.

6.1 Architektur

Abb. 5 - Architekturübersicht
Abb. 5 - Architekturübersicht

Eine Software-Architektur stellt das Grundgerüst, die sogenannten Fundamente und Säulen, einer Software dar. Im Buch "Software-Architektur: Grundlagen - Konzepte - Praxis" wird über den Charakter der Architektur geschrieben, dass diese die "Komplexität überschaubar und handhabbar macht". [30] Software-Architektur beinhaltet häufig auch Schnittstellen-Architektur, um das Zusammenspiel mit anderen Software- oder Hardware-Komponenten zu beschreiben.

[30]

Die QNX CAR Software-Architektur ist modular in verschiedene Layer unterteilt, welche aufgrund der Anforderungen an eine Automotive Software-Lösung erstellt wurde. Die Allgemeine Software-Architektur wird für das Infotainment und für die Instrumentenkomponenten verwendet und enthält alles vom Hardwaresupport (BSPs) bis zur Benutzerschnittstelle(HMI), siehe Abb. "6.1 - 1 Architektur".

Die QNX-Software-Architektur wird im folgenden, vom untersten bis zum obersten Layer, beschrieben.

6.1.1 BSPs

Automotive Board Support Packages (BSPs) erlauben die Entwicklung von Software-Anwendungen unabhängig von der Hardware, so dass diese auch für neue Projekte wiedereinsetzbar sind.

QNX bietet die Möglichkeit zur Anbindung von Board Support Packages anspruchsvoller Fahrzeug-Software. Der BSP Layer ist ausgerüstet mit einem Bootloader, wodurch die benötigten Gerätetreiber für das Betriebssystem bereitgestellt werden. Dieser impliziert einen geringen Aufwand für die Kommunikation zwischen dem BSP und der bereitgestellten Hardware.

QNX bietet unter anderem BSPs zur Initialisierung für den Prozessor, Bus oder den RAM. Die QNX BSPs unterstützen folgende Prozessor-Architekturen: x86, SH-4, PowerPC, MIPS, ARM.

6.1.2 Neutrino RTOS

QNX Neutrino RTOS ist ein Echtzeitbetriebssystem.

Abb. 6 - Neutrino RTOS Layer
Abb. 6 - Neutrino RTOS Layer

Das Echtzeitbetriebssystem QNX Neutrino RTOS bietet Ausfallsicherheit sowie Skalierbarkeit. Die Ausfallsicherheit wird durch die Unabhängigkeit der Anwendungen vom Treiber und vom Kernel gewährleistet, wobei die Skalierbarkeit das Verhalten der notwendigen Ressourcen für die einzelnen Anwendungen und Treiber regelt.

Neutrino RTOS ist ein Betriebssystem, welches abwärtskompatibel ist. „Das Neutrino RTOS basiert auf einer Mikrokernel Architektur, welche modular (bausteinartig) aufgebaut ist, um dem Kunden ein optimiertes und zuverlässiges System zu bieten.“[31]

QNX gibt an, dass mit dieser Architektur Anwendungen, Gerätetreiber und File Systeme unabhängig vom Kernel als speichergeschützte Prozesse arbeiten können. Dadurch bleiben alle anderen Prozesse beim Abbruch eines Prozesses bestehen, während der abgebrochene Prozess automatisch neu gestartet wird. [31] Der Kernel überwacht alle laufenden Systemaktivitäten, um Fehler in Prozessen zu lokalisieren.

„Neutrino RTOS bietet eine saubere Strategie für die Migration von Single-Core auf Multi-Core-Prozesse. Die einzigartige Multi-Prozess-Technologie entscheidet, wo welcher Prozess ausgeführt wird, und nimmt das Risiko für die Migration von den Entwicklern.“ [31]

Das Mikrokernel-Design erlaubt den Entwicklern, die Reihenfolge der startenden Prozesse festzulegen, um so die Anwendung schnellstmöglich („Fast boot“) zu starten. Laut QNX lassen sich so Anwendungen (z.B. Audio) zeitgleich mit dem Betriebssystem starten. Dieses wird als „Instant device activation“ beschrieben.

Die hohe Zuverlässigkeit verdankt das Neutrino RTOS dem Mikrokernel und kann dadurch in kritischen Bereichen wie in Atomkraftwerken, in Krankenhäusern und auch in Raumstationen eingesetzt werden.

6.1.3 Neutrino Services

Die Neutrino Services stützen sich auf das bewährte Neutrino RTOS.

Abb. 7 - Neutrino Services Layer
Abb. 7 - Neutrino Services Layer

File System

Das File System unterstützt eine große Anzahl von aktuellen Formaten. Es werden Festplatten und USB-Sticks mit den Dateisystemen FAT, Ext2, NTFS und HFS unterstützt. Außerdem unterstützt das File System die Nutzung von SMB.


Grafik

Die QNX Core Grafik bietet 2D und 3D Lösungen und unterstützt dabei die Grafik-Programmierschnittstelle OpenGL, welche eine Darstellung von 3D Anwendungen in Echtzeit erlaubt [32]. Von QNX wird die QDB Datenbank genutzt, da diese unter anderem einen Netzwerkzugriff bietet und für embedded Systeme geeignet ist. Mit der QNX Graphic Technologie sind benutzerdefinierte Benutzerschnittstellen erstellbar. [33]


Geräteanschluss

Um Geräte mit der Automotive Lösung zu verbinden, stellt QNX folgende Verbindungsmöglichkeiten zur Verfügung. Es werden die Funkübertragungstechnologien Wireless-Lan (W-Lan) sowie Bluetooth übertragen. Bluetooth dient hauptsächlich der Verbindung mit Mobilfunkgeräten, während W-Lan in den meisten Fällen für Laptops oder Tablet-PC´s genutzt wird.

Dem gegenüber stehen die kabelgebundenen seriellen Bus-Systeme CAN und MOST. CAN ist ein asynchrones serielles BUS-System, welches für die Automobilbranche entwickelt wurde, um die Vernetzung von Steuergeräten in Fahrzeugen zu vereinfachen und die Kabellängen im Automobil zu verringern. MOST ist ein BUS-System, welches zur Übertragung von Medien (z.B. Audio- oder Videomaterial) entwickelt wurde.[34]


Eingabe

Die QNX CAR Architektur unterstützt unterschiedliche Eingabemöglichkeiten von Geräten. So werden Touchscreens, Multifunktionstasten oder Hardwaregeräte, wie eine Maus oder ein Joystick, unterstützt.


Network

Die QNX Architektur bietet die Möglichkeit zur Nutzung der Internet-Protokolle IPv4 und IPv6, sowie W-Lan Standards Wi-Fi 802.11.


Sicherheit

Um die grundlegende Sicherheit des QNX Neutrino Systems zu gewährleisten, wird eine Microkernel-Architektur eingesetzt, welche eine hohe Systemverfügbarkeit sichert.

Um die Sicherheit des QNX Systems zusätzlich zu verstärken, gibt es unter den Middleware Services Dienste in Form des System Health Monitor und Adaptive Partioning unter dem Titel "High availability".

Das System Health Monitor bietet eine "Heartbeat-Funktion", welche alle Prozesse überwacht und sicherstellt, dass diese wie gewünscht ausgeführt werden. Zudem startet der Health Monitor automatisch bei einem erkannten Abbruch eine System-Wiederherstellungssequenz aus, welche zuvor von den Architekten bestimmt werden können. Dadurch lassen sich Anwendungen, Treiber oder das gesamte System innerhalb weniger Millisekunden neu starten.

Das Adaptive Partioning erlaubt dem Systemdesigner, Subsysteme so zu unterteilen, dass Anwendungen trotz eines Abbruchs einzelner Subsysteme gestartet werden können. [33]

QNX bietet hierdurch eine 99,999\% Ausfallsicherheit seiner Anwendungen.[35]

6.1.4 Middleware Services

Abb. 8 - Middleware Service - QNX Aviage Multimedia Suite
Abb. 8 - Middleware Service - QNX Aviage Multimedia Suite
Abb. 9 - Middleware Service Layer
Abb. 9 - Middleware Service Layer

Der Middleware Service Layer bietet viele Anwendungen für eine Automotive Software, die es Entwicklern erlaubt, die Applikationen von dem HMI-Layer zu trennen. Der Middleware Service Layer unterteilt sich in folgende Funktionen.


Multimedia

Multimedia ist eine Grundkomponente für jede Automotive Software-Lösung. Um dieser Anforderung gerecht zu werden, bietet QNX die Multimedia Engine „QNX Aviage Multimedia Suite“ an.

Die Aviage Multimedia Suite ermöglicht, angefangen vom Abspielen, über das Suchen, bis hin zur gleichzeitigen Nutzung mehrerer Benutzer, bezüglich Multimedia-Daten individuelle Steuerungselemente und Lösungen. Darüber hinaus stellt die API die Schnittstelle zum HMI Layer sicher.

Zur Befüllung der Multimedia Engine mit Daten gibt es folgende Möglichkeiten:

Anbindung per "Media Sync and Database" durch Übertragung von Medien aus einer Synchronisation von externen Daten oder Daten einer internen Datenbank. Bei der Datenbank handelt es sich um eine QDB Datenbank. „QDB basiert auf einer SQLite Datenbank mit einer Optimierung hinsichtlich einer Automotive Software“ [36].

Durch Nutzung der QNX-eigenen Netzwerk-Technologie „transparent distributed processing (TDP)“ können Geräte über ein Netzwerk gemeinsam genutzt werden. Die Anwendungen / Prozesse müssen hierbei durch verschiedene Prozessoren ausgeführt werden. Die „QNX Aviage Multimedia Suite“ bietet die Möglichkeit für den Anschluss und zur Steuerung externer Geräte, z.B. IPod oder andere Multimedia Geräte mit USB-Anschluss oder Bluetooth ("Portable Device Connectivity").


Im folgenden werden einzelne Funktionen des Middleware Service Layer beschrieben.


Freisprechfunktionen

Freisprechfunktionen sind in vielen Automobilanwendungen unentbehrlich geworden. Die wichtigste Aufgabe ist somit, das Handy mit dem Radiosystem zu verbinden. Dafür bietet QNX CAR Funktionen zur Rauschunterdrückung. Bluetooth dient als Kommunikationsschnittstelle zwischen dem mobilen Gerät und der Anwendungsebene, um Zugriff auf die Daten, die „Stimmen“ über das Mikrofon und die Multimediainhalte zu erhalten.

„Um die Entwicklung und Integration von Freisprechanlagen zu erleichtern, wurde iAnywhere (Sybase) Blue SDK v3.0 in QNX CAR implementiert. Dieses bietet die Funktionen zur Geräteverbindung (SDP), Freisprechen (HFP), der Vernetzung (BNEP) und dem Audio-Streaming (AVRCP/A2DP).“ [37].

Alle Telefonkomponenten sind so entwickelt, dass sie modifiziert werden können, ohne dass dies Einfluss auf die anderen Komponenten hat.


Navigation

„QNX Navigation Software nutzt Standards wie OpenGL ES und OpenVG zur Nutzung hardwarebeschleunigter Grafiken. QNX arbeitet mit den Marktführern auf diesem Gebiet (z.B. Navigon) zusammen, wobei die meisten bereits QNX Neutrino RTOS nutzen“ [38].


Software Update

Um das System, sowie Andwendungen in QNX CAR, immer auf den neuesten Stand zu bringen, besitzt es die Funktion zum Software-Update. Hierfür stehen die Anwendungen immer in Verbindung mit der „Cloud“, um Aktualisierungen zeitnah zu erhalten („Over-the-Air-Updates“). Außerdem ist es möglich, Software-Updates über eine USB-Schnittstelle einzuspielen. QNX arbeitet mit RedBend Software, die sich in der Industrie bereits bewährt hat. Die RedBend Technologie ermöglicht das Flashen und garantiert ein erfolgreiches Update bei Stromproblemen.


Browser

Der QNX CAR Browser ist eine Eigenentwicklung auf Basis des Open-Source Projekts WebKit [39]. Beim Browser, welcher in CAR zum Einsatz kommt, handelt es sich um einen modularen, Multiplattform- und Embedded-fähigen Webbrowser. Der Webbrowser bietet die meisten grundlegenden Funktionen eines Browsers, wie die Fähigkeit Links zu folgen, die Fähigkeit zum Download und der Darstellung von Inhalten. Ein Vorteil des WebKit Projekts ist die einfache Anpassbarkeit der Browser Engine auf die individuellen Kundenwünsche. [40] Ein Nachteil des Open-Source Browsers ist die Erweiterbarkeit um neue Funktionen, was im Gegensatz zu den marktführenden Browsern (Microsoft IE, Mozilla Firefox) länger dauert.


Speech

„Die Spracherkennung, sowie Text-to-speech Software, sind Produkte von QNX Partnern wie IBM, Nuance, Temic und VoiceBox.

6.1.5 HMI

Abb. 10 - HMI Layer
Abb. 10 - HMI Layer

„Die Schnittstelle zwischen Mensch und Maschine (HMI) ist die Benutzerschnittstelle.“ [41]

Als Benutzerschnittstelle dient der HMI Layer nicht nur der Benutzereingabe, sondern auch der Grafikausgabe der angebotenen Applikationen. Hierzu gehören 3D-Grafiken von Navigationssystemen, der Webbrowser, sowie alle anderen darstellbaren Medien.

Der QNX HMI Layer ist strikt von den Kernfunktionen der Middleware Service und des Neutrino RTOS getrennt. Dies bietet die Möglichkeit, Anwendungen (Middleware) unabhängig von der Benutzeroberfläche(HMI), oder die Benutzeroberfläche unabhängig von den Anwendungen implementieren oder ändern zu können.

Der Layer basiert auf der QNX Eigenentwicklung "QNX Aviage HMI Suite". "Die Suite verfügt über einen Stand-alone-Player zur Wiedergabe von Adobe Flash Lite 3 Anwendungen, einschließlich Audio, Flash-Video-und Netzwerk-Kommunikation. Es bietet erhöhte Performance durch Hardware-Beschleunigung[...]."[42]

Der HMI Layer teilt sich in Applikationen und die Grafik-Oberfläche.


HMI Applikationen

Die HMI Applikationen bieten die Möglichkeit zur Nutzung vom Browser, Navigationsdiensten, dem Telefon, sowie weiteren Multimedia und Web 2.0 Anwendungen.

Neben dem QNX Browser (siehe 6.1.4 Middleware Services) ist der "Composition Manager" ein Bestandteil der "QNX Aviage HMI Suite". QNX ermöglicht durch seinen "Composition Manager" die Überlagerung von Bildern, von beispielsweise Adobe Flash Player, Webbrowser oder 3D-Grafiken, auf demselben physischen Display.


HMI Graphics

Die HMI Graphics' basieren auf Adobe Flash, welches "das Grafik-Design mit dem anschließenden Developer Zyklus, vereinigt". [43] Die HMI Graphics stellt den Appkikations Framework zur Verfügung, welcher zur Erweiterung der Fähigkeiten von Adobe Flash dient. Der Applikations Framework stellt Dienste bereit, in denen die HMI Applikationen gestartet und gesteuert werden und die Schnittstelle zwischen dem Middleware Service und dem Neutrino RTOS Layer verwaltet wird. Der HMI Layer bedient sich hierbei auf Softwaredienste der unteren Layer, um die Eingaben über Tasten oder Sprache zu steuern.[44]

6.1.6 Third-Party Technologien

Durch die modular aufgebaute Architektur bietet die QNX CAR Software Drittanbietern eine einfache Lösung zur Implementierung ihrer Software (Third-Party Technologie). Durch den HMI-Layer ist es Drittanbietern zusätzlich möglich, eine eigene Benutzeroberfläche auf ihr QNX System zu legen, um sich damit von Konkurrenten abzuheben.

6.2 Hardware-Unterstützung

6.2.1 Prozessoren

Die QNX CAR Software unterstützt verschiedene Prozessorarchitekturen. So werden ARM-, PowerPC-, SH- und Atom-Prozessoren unterstützt. Anbieter dieser Architekturen sind Texas Instruments, Nvidia, Fujitsu, Intel und Renesas[45].

Das QNX Neutrino RTOS unterstützt symmetrische (SMP), gebündelte (BMP) und asymmetrische (AMP) Multiprocessing-Modelle. Die Nutzung von Single-Core Prozessoren führt aufgrund der vielen unterschiedlichen gleichen Funktionsanforderungen (z.B. Multimediaanwendungen und Navigation) zu großen Problemen. Der Single-Core Prozessor würde gegenüber einem Multi-Core Prozessor viel mehr Hitze verursachen, als auch einen höheren Energieverbrauch haben und damit die gesetzten Grenzwerte an Prozessoren überschreiten. Multicore-Prozessoren hingegen bieten eine höhere Rechenleistung durch Parallelität und führen zu niedrigeren Taktraten als Single-Core Prozessoren[45].

SMP
Aus einer Ausarbeitung der Uni Erlangen geht folgendes zu symmetrischen Multiprozessoren (SMP) hervor. In einem SMP Multiprozessorsystem arbeiten mehrere identische und gleichwertige (kein Master, Slave) Prozessoren zusammen, wobei alle über einen gemeinsamen Speicher miteinander kommunizieren. Ein Vorteil gegenüber asymmetrischen Multiprozessoren (AMP) ist die Übernahme aller Aufgaben (sogenannten Threads) durch alle Prozessoren[46].

Bei SMP besteht nur eine Version des Neutrino OS, auf die alle Prozessoren zugreifen. Durch die Nutzung nur einer Kopie des Neutrino OS kann SMP dynamisch Ressourcen für spezifische Anwendungen zuweisen, anstatt die Zuweisung für einen einzelnen Prozessoren zu übernehmen. Neutrino lässt die laufenden Threads innerhalb einer Applikation gleichzeitig auf jeder CPU ausführen, wodurch die gesamte Rechenleistung des Chips für Anwendungen zu jeder Zeit verfügbar sind[47].


AMP
Bei asymmetrischen Multiprozessoren (AMP) dient ein Prozessor zur Steuerung und Kontrolle der anderen Prozessoren. Dieser Prozessor verteilt die anstehenden Threads an die Prozessoren, um so die Belastung auf alle Prozessoren zu verteilen[48].

Beim Neutrino OS laufen die Anwendungen jeweils auf einem Prozessor, wobei diese gleichzeitig mit Anwendungen und System-Diensten anderer Prozessoren kommunizieren können. Durch die Ausführung einer Anwendung auf einem Prozessor kann es zum Leerlauf anderer Prozessoren kommen. Die Zuweisung der Ressourcen auf die Prozessoren geschieht bereits während des Bootvorgangs. [48]


BMP
Gebündelte Multiprozessoren (BMP) bieten die Planungskontrolle von AMP´s, während das Hardware Management auf SMP´s basiert. Gebündelte Multiprozessoren funktionieren wie SMP´s, das heißt, dass alle Prozessoren alle Threads bearbeiten können, wobei bei BMP´s entschieden werden kann, welcher Thread von welchem Prozessor ausgeführt wird[49].

Wie bei symmetrischen Multiprozessoren wird bei gebündelten Multiprozessoren nur eine Version des Neutrino OS ausgeführt, welche einen Gesamtüberblick über die System-Ressourcen hat. Dadurch können die Threads dynamisch zugewiesen und gemeinsam ausgeführt werden. Gegenüber SMP´s kann bei einem BMP eine Ressource nur für eine bestimmte CPU reserviert werden.[49]
Funktion SMP BMP AMP
Gemeinsame Nutzung von Ressourcen Ja Ja ---
Skalierbarkeit über Mehrfach CPU´s Ja Ja begrenzt
Abwärtskompatibilität in den meisten Fällen Ja Ja
gemischte Betriebssystem-Umgebung (e.g. Neutrino and Linux) --- --- Ja
dedizierte Prozessorfunktionen --- Ja Ja
Intercore-Kommunikation schnell schnell langsam
Synchronisation zwischen den CPU´s Ja Ja ---
Strukturausgleich Ja Ja ---
Systemweite Fehlerbehebung und Optimierung Ja Ja ---
QNX hat tabellelarisch die wichtigsten Funktionen von Multiprozessoren mit den 3 Multiprozessortypen verglichen[48]

6.2.2 Datenübertragung

Für die Datenübertragung in QNX CAR wird die QNX Eigenentwicklung TDP („transparent distributed processing“) genutzt. QNX TDP ist auch unter der Bezeichnung „QNet Networking“ bekannt.

Mit TDP ist es jedem Gerät möglich, auf die Ressourcen anderer Geräte innerhalb des Netzwerkes zuzugreifen (z.B. Datenbanken). Hierdurch ist weniger Hardware notwendig, da die Geräte ihre Hardware-Ressourcen teilen. Zum Beispiel kann der Speicher (z.B. Flash) eines Gerätes durch ein anderes verwendet werden und benötigt keinen eigenen Speicher.

QNX TDP ermöglicht außerdem den Zugriff einer Anwendung auf einen entfernten Dienst. Die Anwendung muss hierzu nicht einmal den Ort des anzusprechenden Knotens wissen. Hierzu muss die Anwendung nur eine Nachricht an TDP senden, welche die Nachricht an den korrekten Knoten weiterleitet. Dadurch müssen die Entwickler nicht die einzelnen Knoten separat ansprechen.

Um die Skalierbarkeit und die Rechenleistung von QNX CAR zu erhöhen, kann QNX TDP mit symmetrischen oder gebundenen Multi-Prozessoren kombiniert werden. Ein weiterer Vorteil von QNX TDP ist die Ausfallsicherheit. Fällt eine Netzwerkverbindung aus, so können die Daten auf einer anderen Verbindung gesendet und empfangen werden. Außerdem ist die Verteilung der Daten auf mehrere Netzwerkressourcen möglich [1].

6.2.3 Speichermedien

Der Einsatz von Speichermedien, wie USB-Stick oder MP3-Player, sowie Festplatten hat aufgrund der immer weiter fallenden Preise zugenommen. So ist der Anschluss solcher Medien immer mehr gefragt, während Abspielmedien wie CDs aufgrund der geringen Speichergröße immer weiter abnehmen. Dadurch ist die Nutzung von MP3-Playern über einen Kassetten-Adapter seit Jahren ein beliebter Weg, um seine Musik über das Autoradio abzuspielen. Doch ein Kassettendeck findet man in aktuellen Automodellen nicht mehr. Zudem ist die Nutzung sowie die Qualität solch eines Adapters meist schlechter als eine direkte Integration der Medien.

QNX bietet in seiner Automotive Plattform CAR die Möglichkeit zur Anbindung von USB-Sticks, MP3-Playern, welche über USB als Speichermedium erkannt werden, sowie den Anschluss externer Festplatten über USB. Unterstützt werden die Filesysteme ext2, DOS / FAT12, FAT16, FAT32, ISO9660 und Joliet.

6.3 Erweiterbarkeit

6.3.1 Bausteinprinzip

Wie bereits in Kapitel 6.1 beschrieben ist die Software-Architektur von QNX CAR modular, d.h. nach dem Bausteinprinzip(Modular) aufgebaut. Dadurch ist es möglich, auf den einzelnen Layern Module (Bausteine) hinzuzufügen oder zu entfernen. Auf diese Weise lässt sich QNX CAR für jeden Kunden individuell anpassen. Zur Implementierung der Module ist es nicht notwendig, eine Tier One Integration (direkte Hardwareschnittstelle) durchzuführen, da QNX CAR hierfür die Schnittstellen schon bereitstellt.

Das Bausteinprinzip bietet außerdem eine Möglichkeit, die einzelnen Module zu updaten. So lässt sich das Navigations-Modul (Middleware Service) unabhängig von den anderen Modulen und des OS auf den neusten Stand bringen.

6.3.2 Third-Party Technologie

Aufgrund der Modularität ist es QNX möglich, seinen Kunden ein weites Spektrum an Eigenprodukten sowie Third-Party Technologie seiner Partner anzubieten.

QNX bietet in einem Repository (QNX Momentics Repository) ein Paket an Third-Party-Software zum Download an. "Es enthält Demos, kommerzielle / nicht-kommerzielle, Quellcode und Bibliotheken, welche auf dem Neutrino OS ausgeführt werden können"[50]. Diese Produkte werden auch in regelmäßigen Abständen geupdated.

Abb. 11 - Third Party Technologien
Abb. 11 - Third Party Technologien

QNX gibt aktuell folgende Partnerschaften[51] bekannt:

  • Adobe (Flash Lite 3 HMI)
  • Apple (iPod/iPhone connectivity)
  • Gracenote (media management)
  • Pandora Internet Radio
  • iAnywhere (Bluetooth)
  • Microsoft (portable media connectivity)
  • Silicon Turnkey Express

6.3.3 Lizenzen

QNX hat sein Lizenzsystem in vier verschiedene Arten unterteilt:

  • Kommerzielle Software-Lizenz: Diese Lizenz ist für Kunden, welche QNX Produkte kommerziell weitervertreiben.
  • Partner Software-Lizenz: Diese Lizenz ist für Unternehmen, welche QNX Produkte im Auftrag anderer Kunden weiterentwickeln. Diese Lizenz ist teilweise für das bearbeitende Unternehmen kostenlos.
  • nicht gewerbliche Endnutzer-Lizenz: Diese Lizenz ist für nicht-kommerzielle Kunden (z.B. Studenten). Diese Lizenz ist kostenlos.
  • Open-Source-Lizenz: QNX besitzt einige Produkte, welche als Open-Source und damit frei zugänglich und kostenlos für Endverbraucher sind[52].

7 Bewertung der QNX CAR-Plattform

In diesem Abschnitt werden die Anforderungen an eine Automotive Software-Lösung mit QNX CAR Plattform gegenübergestellt und bewertet. Die Anforderungen basieren auf eigenen Recherchen sowie Standards und Normen von Automotive Software-Lösungen. Eine praktische Nutzung von QNX CAR ist hierbei nicht Teil der Bewertung, da die benötigte Hardware nicht vorhanden ist.

Die Anforderungen unterteilen sich hierbei in die Bereiche "allgemeine Anforderungen", "Softwareanforderungen" und "Hardwareanforderungen".


7.1 Soll-Ist-Vergleich

7.1.1 Allgemeine Anforderungen

Benutzerfreundliche Bedienbarkeit
In den Anforderungen wurde der hohe Stellenwert von Bedienkonzepten im Auto aufgezeigt, welche laut ISO Norm die Kriterien Effektivität, Effizienz und Zufriedenheit erfüllen müssen. QNX CAR bietet keine komplette Lösung vorbestimmter Bedienungen für Automobile an, gibt aber den Automobilherstellern durch Unterstützung von beispielsweise Touchscreens, Multifunktionstasten und Sprachsteuerung die Freiheit, eine benutzerfreundliche Bedienung für den Endverbraucher zu erstellen. Es werden alle regulären Möglichkeiten zur Steuerung der Plattform zur Verfügung gestellt, die Anforderung an benutzerfreundliche Bedienbarkeit kann aber von der Software nur angeboten und nicht umgesetzt werden.

Implementierbarkeit
Die Implementierbarkeit von Automotiv-Softwarelösungen in Automobile ist für Automobilhersteller und Softwareanbieter gleichermaßen wichtig. Automobilhersteller müssen bei der Auswahl der Hardware unabhängig von der Software sein und diese ohne aufwendige zusätzliche Softwareentwicklung ins Automobil integrieren können.
Durch die Automotive Board Support Packages (BSP) stellt QNX CAR die Gerätetreiber für zur Implementierung standardisierter Komponenten bereit, und durch die aktive Weiterentwicklung wird aktuelle Hardware schnell unterstützt.

Konnektivität
Für die Verbindung mit dem Internet, dem Handy und Netzwerken schafft QNX die Grundlage durch die Nutzung der Neutrino Services. Zu den Services gehören die beiden Bereiche "Device connectivity" und "Networking", welche die Protokolle und Grundlagen zur Verbindung mit den vorher genannten Geräten und Services bietet.

7.1.2 Software-Anforderungen

Betriebssystem
Durch die unter Punkt 5.2.1 herausgearbeiteten Anforderungen an ein Betriebssystem im Auto hat sich herausgestellt, dass diese am besten durch ein Echtzeitbetriebssystem erfüllt werden. Mit dem Echtzeitbetriebssystem Neutrino RTOS stellt QNX eine gute Grundlage dar, diese Anforderungen zu erfüllen, und nutzt dadurch die Vorteile eines RTOS gegenüber eines GPOS.

Sicherheit
Die Sicherheitsanforderungen werden grundlegend durch die Eigenschaften eines Echtzeitbetriebssystems erfüllt. So wird die Ausfallsicherheit und die hohe Verfügbarkeit von 99.999% der Anwendungen durch den System Health Monitor sichergestellt. Hierdurch sind Systeme auch im Notfall immer betriebsbereit. Weitere Sicherheitsfunktionen in Bezug auf Netzwerke sind im QNX Neutrino RTOS auf dem Service Layer in Form eines eigenen Security-Moduls untergebracht. Einen weiteren Vorteil bietet die Skalierbarkeit des Betriebssystems. Dadurch können in kritischen Situationen die benötigten Ressourcen auf die sicherheitsrelevanten Anwendungen gebündelt werden.

Erweiterbarkeit
Den ersten Punkt der Anforderungen in Bezug auf die Erweiterbarkeit, die Anpassung der Oberfläche, erfüllt die QNX CAR Plattform. Durch den separat anpassbaren HMI-Layer in der Software-Architektur können die Hersteller ihre Bedienoberfläche individuell auf ihre Anforderungen zuschneiden. Zur Erweiterung der Funktionen der QNX CAR Plattform wird ein Softwareentwicklungspaket (QNX Momentics Development Suite) angeboten, mit welchem sich das System durch Technologien von QNX Partnern ergänzen lässt.

Updatefähigkeit
QNX bietet mit dem integrierten Update Manager im Middleware Layer eine einfache Möglichkeit, dynamische Upgrades für das Betriebssystem durchzuführen und neue Anwendungsfeatures hinzuzufügen. Durch die stetige Weiterentwicklung des Betriebssystemkernels. Der QNX Update Manager aktualisiert das CAR System über eine kabelgebundene und kabellose Verbindung. Eine Aktualisierung bei einer Serviceinspektion durch einen Automechaniker ist in QNX nicht vorgesehen.

7.1.3 Hardware-Anforderungen

Prozessoren
Wie aus den Anforderungen ersichtlich wurde, wird von einer Automotive Software-Lösung eine vielseitige Unterstützung verschiedener Prozessorarchitekturen gefordert, um herstellerunabhängig zu sein und eine möglichst hohe Verbreitung der Software zu ermöglichen. QNX unterstützt die Architekturen führender Hersteller im Prozessormarkt wie ARM, PowerPC, SH und Atom Prozessoren, und erfüllt somit die Anforderung.

Schnittstellen
QNX CAR unterstützt die in den Anforderungen beschriebenen Schnittstellen. Somit existiert eine Basis, um alle fahrzeugspezifischen Komponenten wie Fensterheber, Klimaanlage u.v.a. anzusprechen und zu steuern. Zusätzlich können durch weitere Schnittstellen wie Bluetooth oder USB auch externe Geräte mit der Software Plattform verbunden werden.

7.2 Vor- und Nachteile

In der folgenden Tabelle werden die wichtigsten Vor- und Nachteile gegenübergestellt. Diese wurden nach Ausarbeitung dieser Fallstudie und durch Recherchen im Internet zusammengetragen. Eine praktische Prüfung konnte nicht durchgeführt werden.


Vorteile Nachteile
Einer der größten Vorteile ist die HMI Oberfläche. Diese Komponente ermöglicht es, viele Applikationen für die Plattform zu entwickeln. Der Zugriff auf HW Komponenten ist durch QNX getrennt und wird den Applikationen als Dienst zur Verfügung gestellt. Individuelle und viele Lösungen sind dadurch möglich. Ein Nachteil gegenüber anderen Embedded Systemen ist, dass kein Open Source Code zur Verfügung steht, dadurch Flexibilität verloren geht und für die Entwicklung auch Lizenzen notwendig sind.
QNX bietet die Momentics Development Suite an, um eine angepasste, einfache Entwicklungsumgebung ihres Echtzeitbetriebssystems zur Verfügung zu stellen, damit der Einstieg für schnelle Anpassungen besteht und somit das QNX Neutrino System in die unterschiedlichen Automobile eingebunden werden kann. Third-Party Technologien und Applikationen, die in das System eingebunden werden oder werden können, machen das System anfällig, was nachteilig zu bewerten ist.
Ein ganz großer Vorteil ist natürlich die lange Erfahrung der QNX mit diesen Systemen. Als sogenannter "Leader" auf dem Markt wird das nochmals gestärkt. Der Nachteil des Lizenzmodells ist, dass die Software zwar kostenlos heruntergeladen und verändert werden kann, diese Änderung aber ohne eine offizielle kostenpflichtige Lizenz nicht veröffentlicht werden darf.
Das Lizenzmodell hat einen Vor- und einen Nachteil. Der Vorteil ist, dass QNX deren Produkte bereitstellt und beispielsweise Automobilhersteller diese zum Test nutzen können und nur im Falle, dass ein Projekt zustande kommt, auch erst dann Kosten anfallen


8 Schlussbetrachtung

Die Anforderungen an ein Auto haben sich im Laufe der Zeit gewandelt. War früher noch der Bedarf nach einer Klimaanlage, elektrischen Fensterhebern oder einem Schiebedach, groß, so ist heute die Nachfrage nach einer Möglichkeit Navigation, Multimedia-Geräte anzuschließen oder sogar einer Internetverbindung innerhalb des Autos immer größer. Um all diese neuen Anforderungen platzsparend und effektiv in ein Auto zu integrieren, wurden im Laufe der letzten Jahre, Automotive Software-Lösungen aufgebaut und bis heute weiterentwickelt.
Doch solch eine Automotive Software-Lösung bietet nicht nur Komfort, sondern ist auch ein wichtiger Bestandteil für die Sicherheit eines Autos geworden. Das Ziel einer solchen Lösung ist es, viele Funktionen eines Autos mit einer Automotive Plattform steuern zu können um den Komfort des Autofahrens zu steigern und eine Autofahrt für alle Fahrgäste so angenehm wie möglich zu machen. Der führende Hersteller von Automotive Software-Lösungen QNX hat dieses bereits vor einigen Jahren erkannt und mit der Entwicklung seiner Automotive Software-Lösung CAR begonnen.

Diese wissenschaftliche Arbeit zeigt, dass mit der QNX CAR Plattform (die mittlerweile am weit verbreitetenste Software Lösung)eine Lösung existiert, die Automobilhersteller bei der zunehmend steigenden Anzahl von Elektronischen Bauteilen und die dadurch komplexeren Anforderungen in der Bedienungbarkeit, Hard- und Software ins Auto zu integrieren, entlasten soll.

Schon bei der ersten Analyse des Produktes wurde klar, dass es sich um eine sehr fortschrittliche und aktuelle Automotive Software-Lösung handelt. Dieser erste Eindruck wurde durch die immer tiefgründigere Recherche zu QNX CAR weiter bestätigt. CAR unterstützt alle herausgearbeiteten Ansprüche zu Bedienkonzepten, Medienunterstützung, Internetkonnektivität und erfüllt dabei alle Sicherheitsrelevanten Anforderungen. Nachteile wurden hauptsächlich im Lizensmodell, sowie in der Gefahrenquelle von Third-Party Technologie entdeckt. Das Betriebssystem Neutrino RTOS, welches den Hauptbestandteil der CAR Plattform bildet, bietet aufgrund des Einsatzes in sicherheitskritischen Bereichen wie medizinischen Geräten, Atomkraftwerken und Automobilen eine ausgereifte, stabile und sehr hohe Zuverlässigkeit. Dies bestätigt die Analyse, Nachteile im Neutrino RTOS konnten nicht ausfindig gemacht werden.

Als Fazit dieser wissenschaftlichen Hausarbeit kann gesagt werden, dass QNX CAR aufgrund der erfüllten Anforderungen, zu Recht der Marktführer auf dem Gebiet der Automotive Software-Lösungen ist. Bereits über 200 Fahrzeugmodelle verwenden die QNX CAR Plattform als Grundlage für ihre Infotainment- und Telematiklösungen. Ein Konkurrenzprodukt hat es nicht leicht gegen diese ausgereifte und weit verbreitete Automotive Software-Lösung Marktanteile gut zu machen.

Der Trend mehr und mehr elektronische Geräte aus dem Consumer Bereich ins Automobil zu integrieren, stellt immer neue Anforderungen an die Technik und Softwareentwicklung und somit wird es auch in den nächsten Jahren interessante Weiterentwicklungen in diesem Bereich geben. Das Automobil wird damit in das heute schon vorhande Netzwerk von mobilen Geräten, dem Internet mit seinen Web 2.0 Anwendungen und dem Cloud Computing integriert.

9 Fußnoten

  1. ↑ 1,0 1,1 Vgl. QNX News Releases
  2. ↑ 2,0 2,1 Vgl. C2C – Technologische Herausforderungen
  3. ↑ 3,0 3,1 W.Fischer:Homepage der IEEE Organisation, Development of DSRC/WAVE Standards, S.2ff
  4. ↑ Vgl. OSEK/VDX: Binding Specification, S. 3.
  5. ↑ Vgl. ebd., S. 6.
  6. ↑ Vgl. OSEK/VDX: OSEK Communication Specification 3.0.3, S. 8ff.
  7. ↑ Vgl. OSEK/VDX: Network Management Concept and Application Programming Interface, S. 3.
  8. ↑ Dies bezeichnet Computer welche für eine bestimmte Aufgabe, meist zur Steuerung, Regelung oder Überwachung in einer Maschine eingesetzt werden.
  9. ↑ Symmetrisches Multiprozessorsystem (SMP) ist eine Multiprozessor-Architektur.
  10. ↑ Portable Operating System Interface (POSIX) ist eine von der IEEE und Open Group entwickelte und standardisierte Schnittstelle zwischen Applikation und Betriebssystem.
  11. ↑ Vgl. QNX CAR Business model overview
  12. ↑ Vgl. Artikel Autosieger.de
  13. ↑ Vgl. iso.org
  14. ↑ Vgl. iso.org
  15. ↑ Vgl. Artikel Hr. Jendryschik
  16. ↑ Vgl. MOST Homepage
  17. ↑ Vgl. Ethernet im Auto
  18. ↑ Vgl. GPS Kowoma
  19. ↑ Vgl. Bluetooth-GPS.de
  20. ↑ Vgl. Automotive Betriebssysteme
  21. ↑ Vgl. QNX - When do you need an RTOS
  22. ↑ 22,0 22,1 Vgl. Eingebettete Sicherheit und Kryptographie im Automobil
  23. ↑ Vgl. Lebensdauer eines Autos
  24. ↑ Vgl. Anforderungen und Chancen automobilgerechter Software-Entwicklung
  25. ↑ Vgl. Most, S.35
  26. ↑ Vgl. USB Jetzt Auch Im Auto, S.2
  27. ↑ Vgl. Grundlagen der Rechnerkommunikation, S. 212f.
  28. ↑ Vgl. QNX Connected Automotive Reference, S. 4
  29. ↑ 29,0 29,1 Vgl. QNX Connected Automotive Reference, S. 5
  30. ↑ 30,0 30,1 vgl. Software-Architektur: Grundlagen, S.1
  31. ↑ 31,0 31,1 31,2 Vgl. QNX Neutrino RTOS
  32. ↑ Vgl. OpenGL
  33. ↑ 33,0 33,1 Vgl. QNX Connected Automotive Reference, S. 23
  34. ↑ Vgl. CAN, MOST & FlexRay
  35. ↑ Vgl. Harte Echtzeit mit Posix Microkernel
  36. ↑ Vgl. QNX Connected Automotive Reference, S. 17
  37. ↑ Vgl. QNX Connected Automotive Reference, S. 18
  38. ↑ Vgl. QNX Connected Automotive Reference, S. 19
  39. ↑ Vgl. Webkit Browser
  40. ↑ Vgl. Overview of the Web Browser Engine
  41. ↑ Vgl. Mensch-Maschine-Schnittstelle
  42. ↑ Vgl. QNX Aviage HMI Suite
  43. ↑ Vgl. QNX Connected Automotive Reference, S. 13
  44. ↑ Vgl. QNX Connected Automotive Reference, S. 14
  45. ↑ 45,0 45,1 Vgl. Multicore Processing
  46. ↑ Vgl. Mehrprozessorarchitekturen(SMP, Cluster, UMA/NUMA)
  47. ↑ Vgl. Symmetric multiprocessing (SMP)
  48. ↑ 48,0 48,1 48,2 Vgl. Asymmetric multiprocessing (AMP)
  49. ↑ 49,0 49,1 Vgl. Bound multiprocessing (BMP)
  50. ↑ Vgl. QNX Technical Articles
  51. ↑ Vgl. QNX Partner integrations
  52. ↑ Vgl. QNX Licensing

10 Literaturverzeichnis

NameQuelle
Anforderungen und Chancen automobilgerechter Software-Entwicklung BMW Car IT GmbH: Dr. Ulrich Weinmann (Hrsg.), http://ls12-www.cs.tu-dortmund.de/teaching/courses/ss05/proseminars/automotive/download/literature/05.pdf (15.05.2010)
Artikel Autosieger.dehttp://www.autosieger.de/article17963.html (06.06.2010)
Artikel Hr. Jendryschikhttp://jendryschik.de/wsdev/trans/designguide/implementierbarkeit (06.06.2010)
Asymmetric multiprocessing (AMP) QNX Software Systems (Hrsg.), http://www.qnx.com/developers/docs/6.3.2/neutrino/sys_arch/smp.html#AMP (25.05.2010)
Automotive BetriebssystemeFriedrich-Alexander-Universität Erlangen-Nürnberg: Wolfgang Schröder-Preikschat (Hrsg.), http://www4.informatik.uni-erlangen.de/~wosch/Publications/2004/pearl04.pdf (15.05.2010)
Bluetooth-GPS.dehttp://www.bluetooth-gps.de/Was-ist-TMC-:_:15.html (09.06.2010)
Bound multiprocessing (BMP) QNX Software Systems (Hrsg.), http://www.qnx.com/developers/docs/6.3.2/neutrino/sys_arch/smp.html#BMP (25.05.2010)
Bussysteme in der Fahrzeugtechnik Werner Zimmermann,Ralf Schmidgall: Bussysteme in der Fahrzeugtechnik: Protokolle und Standards (ISBN-13: 978-3834801661)
C2C – Technologische HerausforderungenVolkswagen AG: Andreas Lübke (Hrsg.), http://www.network-on-wheels.de/downloads/VDE2004_Luebke_Paper.pdf (15.05.2010)
CAN, MOST & FlexRay http://cis.cs.tu-berlin.de/Lehre/SS-06/Sonstiges/technInfo/20060621_vortrag_8.pdf (16.05.2010)
Eingebettete Sicherheit und Kryptographie im Automobil http://www.crypto.rub.de/imperia/md/content/texte/car_security_v8.pdf (10.06.2010)
Ethernet im Autohttp://www.innovations-report.de/html/berichte/automotive/ethernet_macht_infotainment_auto_flexibel_152667.html (06.06.2010)
GPS Kowomahttp://www.kowoma.de/gps/Geschichte.htm (09.06.2010)
Grundlagen der RechnerkommunikationGrundlagen der Rechnerkommunikation: Technische Realisierung von Bussystemen und Rechnernetzen. Für alle IT-Studiengänge: Informatik, Elektrotechnik und Informationstechnik von Bernd Schürmann von Vieweg+Teubner (Broschiert - 29. November 2004)
Harte Echtzeit mit Posix Microkernel http://www.sps-magazin.de/?inc=artikel/article_show&nr=20579 (20.05.2010)
iso.orgISO (Hrsg.), http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=38896 (06.06.2010)
Lebensdauer eines Autos http://www.handelsblatt.com/technologie/news/lebensdauer-eines-autos-steigt-kaum-noch;1386255 (05.06.2010)
Mehrprozessorarchitekturen(SMP, Cluster, UMA/NUMA) http://www4.informatik.uni-erlangen.de/Lehre/SS04/PS_KVBK/talks/Ausarbeitung-Mehrprozessorarchitekturen-2.pdf (25.05.2010)
Most Das Multimedia-bussystem für den Einsatz im Automobil Von Andreas Grzemba
MOST Homepagehttp://www.mostcooperation.com/home/index.html (06.06.2010)
Multicore Processing QNX Software Systems (Hrsg.), http://www.qnx.com/developers/docs/6.3.2/neutrino/sys_arch/smp.html#Introduction (25.05.2010)
OpenGl http://www.opengl.org/documentation/current_version/ (16.05.2010)
Overview of the Web Browser Engine QNX Software Systems (Hrsg.), http://www.qnx.com/developers/docs/6.4.1/webkit/dev_guide/overview.html (20.05.2010)
QNX - When do you need an RTOS QNX Software Systems (Hrsg.), http://www.qnx.com/download/download/8090/qnx_when_do_you_need_an_rtos.pdf (15.05.2010)
QNX Aviage HMI SuiteQNX Software Systems (Hrsg.), http://www.qnx.com/products/intl/middleware/graphics/hmi.html (21.05.2010)
QNX CAR Business model overview QNX Software Systems (Hrsg.), http://www.qnx.com/products/qnxcar/business_overview.html (16.05.2010)
QNX Connected Automotive Referencehttp://www.qnx.com/download/download/19092/qnx_connected_automotive_reference.pdf (17.05.2010)
QNX LicensingQNX Software Systems (Hrsg.), http://www.qnx.com/legal/licensing/ (07.05.2010)
QNX Neutrino RTOS QNX Software Systems (Hrsg.), http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html (16.05.2010)
QNX News Releases QNX Software Systems (Hrsg.), http://www.qnx.com/news/pr_2756_1.html (06.05.2010)
QNX Partner integrations QNX Software Systems (Hrsg.), http://www.qnx.com/products/qnxcar/partners.html (07.05.2010)
QNX Technical Articles QNX Software Systems (Hrsg.), http://www.qnx.com/developers/articles/rel_1031_1.html (06.05.2010)
Software-Architektur: Grundlagen Software-Architektur: Grundlagen - Konzepte - Praxis Von Oliver Vogel,Ingo Arnold,Arif Chughtai,Edmund Ihler,Timo Kehrer,Uwe Mehlig,Uwe Zdun - 2.Auflage
Symmetric multiprocessing (SMP) QNX Software Systems (Hrsg.), http://www.qnx.com/developers/docs/6.3.2/neutrino/sys_arch/smp.html#SMP (25.05.2010)
USB Jetzt Auch Im Auto Cypress Semiconductor Corp. (Hrsg.), Brian Ellis, http://www.cypress.com/?docID=14498 (08.06.2010)
Webkit Browser http://webkit.org/projects/ (20.05.2010)
Von „http://winfwiki.wi-fom.de/index.php/QNX_CAR_platform“
Persönliche Werkzeuge