-
Die Erfindung betrifft ein Verfahren und eine Vorrichtung zum Austauschen fahrzeugoriginärer Informationen.
-
Funktionsgruppen und Steuergeräte heutiger Fahrzeuge sind intern inzwischen weitgehend über Fahrzeugbusse vernetzt. Nun wird damit begonnen, die Vernetzung über die Grenzen des Fahrzeugs hinaus fortzuführen, denn die Kommunikation von Fahrzeugen untereinander (Car2Car-Kommunikation) und mit der Infrastruktur (Car2lnfrastructure-Kommunikation) stellt eine grundlegende Voraussetzung für die Realisierung neuartiger Dienste und Anwendungen dar, die sowohl hohen Kunden- als auch Herstellernutzen haben.
-
Jedes Fahrzeug besitzt eine individuelle Soft- und Hardwareausstattung. Der Funktionsumfang im Fahrzeug hängt von der Art und Anzahl der verbauten Steuergeräte ab. Hinzu kommen - neben CAN - weitere Bussysteme wie LIN, MOST, Byteflight etc. Die Bus- und Steuergeräteprotokolle sind proprietär und gehen nicht über die Grenzen des spezifischen Bussystems hinaus. Das Format der Botschaften ist herstellerspezifisch und enthält wettbewerbsrelevante Informationen. Zudem ist es durch Innovationen im Fahrzeugbau notwendig, diese Busbotschaften ständig an die Bedürfnisse neuer Fahrzeugmodelle anzupassen.
-
Dienste- und Anwendungsentwickler stehen damit vor dem Problem, ihre Software immer wieder an sich verändernde Fahrzeugarchitekturen anpassen zu müssen.
-
Aus der
US 2004/0128673 A1 ist eine gattungsgemäße Vorrichtung zum Austauschen von fahrzeugoriginären Informationen bekannt.
-
Der Erfindung liegt daher das technische Problem zugrunde, ein Verfahren und eine Vorrichtung, durch welche fahrzeugoriginäre Informationen unabhängig von einer Bus- und/oder System-Technologie für lokale und/oder externe Anwendungen zur Verfügung stehen, zu verbessern.
-
Die Lösung des Problems ergibt sich durch die Gegenstände mit den Merkmalen der Patentansprüche 1 und 7. Weitere vorteilhafte Ausgestaltungen der Erfindung ergeben sich aus den Unteransprüchen.
-
Hierzu umfasst die Vorrichtung zum Austausch fahrzeugoriginärer Informationen eine Fahrzeug-Anwendungsprogramm-Schnittstelle (VAPI), die mindestens teilweise logisch zwischen Treibern von Fahrzeugnetzwerken und einem Dienste-Framework mit Anwendungsprogrammen liegt, wobei die Fahrzeug-Anwendungsprogramm-Schnittstelle mit mindestens einer Schnittstelle zu dem Dienste-Framework ausgebildet ist, wobei die Fahrzeug-Anwendungsprogramm-Schnittstelle mit Low-Level-Konnektoren zur Kommunikation mit fahrzeugspezifischen Low-Level-Quellen ausgebildet ist, ein Objekt-Management mit einer Datenbank umfasst, in der fahrzeugoriginäre Informationen objektspezifisch abgelegt sind, wobei die Zuordnung der objektspezifischen Daten zu den zugeordneten Low-Level-Konnektoren durch ein Low-Level-Mapping erfolgt und die Fahrzeug-Anwendungsprogramm-Schnittstelle in einem Profil Definitionen von Datenobjekten und Mappings umfasst, die durch ein Regelwerk umsetzbar sind.
-
Weiter umfasst die Fahrzeug-Anwendungs-Schnittstelle ein Datenobjekt Repository, welches die VAPI Datenobjekte verwaltet und den oberen Schichten zur Verfügung stellt. Das Datenobjekt Repository stellt dabei die eigentliche Datenbank dar, die durch das Regelwerk in Verbindung mit den Profilen geladen wird und durch das Objekt Management gesteuert wird.
-
Hierdurch wird ein universelles Gateway geschaffen, mittels dessen fahrzeugoriginäre Informationen von beliebigen Diensten genutzt werden können, wobei der eigentliche fahrzeugspezifische Aufbau für den Dienste-Anbieter verborgen bleibt. Durch die Definitionen von Datenobjekten und Mappings in einem Profil, das von einem Regelwerk umgesetzt wird, kann das System während des Betriebes jederzeit neu konfiguriert werden, ohne dass hierzu ein Kompilierungsvorgang durchgeführt werden muss.
-
Dabei werden die Datenobjekte beim Start des Systems auf Basis des Profils durch eine Factory erzeugt und in die Objekt Repository gestellt, wobei das Objekt Repository eine Schnittstelle für die Factory zur Verfügung stellt.
-
In einer bevorzugten Ausführungsform ist der Fahrzeug-Anwendungsprogramm-Schnittstelle ein Middleware-Mapping zugeordnet, welche die objektspezifischen Daten der Fahrzeug-Anwendungsprogramm-Schnittstelle in middlewarespezifische Sprachen und/oder Protokolle für Anwendungen und Dienste zur Verfügung stellt. Dabei erfolgt eine Umsetzung der gerätelokalen Basisschnittstelle der Vehicle-API in eine Schnittstelle auf Basis einer anderen Zielsprache (Sprach-Mapping) oder eines Middleware-Protokolls (Middleware-Mapping), was hier zusammengefasst als Middleware-Mapping bezeichnet wird. Dieser in die Schnittstelle integrierte Basisdienst erleichtert die Anbindung verschiedener Anwendungen und Dienste in unterschiedlichen Sprachen (z.B. Java) und Protokolle (z.B. TCP).
-
In einer weiteren bevorzugten Ausführungsform umfasst die Fahrzeug-Anwendungsprogramm-Schnittstelle eine Zugriffssteuerung, die die Definition von Schreib-/Leserechten von Datenobjekten und/oder Authentizität und/oder Verschlüsselung von Zugriffen und/oder Eigensicherheit und/oder Synchronisation festlegt.
-
In einer weiteren bevorzugten Ausführungsform erstellt das Datenobjekt Management für die Anwendungen und Dienste eine Liste der verfügbaren Datenobjekte.
-
In einer weiteren bevorzugten Ausführungsform weist der Wert bzw. das Datum eines Datenobjektes das Format eines Datentyps (VAPIType) auf, wobei der VAPIType definiert, welche Datentypen in einem Datenobjekt enthalten sein können. Die Verwaltung und Struktur von Fahrzeugdaten kann auf diese Art und Weise getrennt werden. Die erlaubten Datentypen definieren die Struktur der Daten, während das Vehicle-API Datenobjekt zur Verwaltung einer Datenstruktur dient.
-
In einer weiteren bevorzugten Ausführungsform sind jedem Datenobjekt ein oder mehrere Low-Level-Mappings zugeordnet, wobei jedes Low-Level-Mapping eine Regel für eine Object to Low Level Conversion- und eine Low-Level to Object Conversion Regel umfasst. Mittels dieser Regel findet ein Datenaustausch zwischen den streambasierten Low-Level Quellen und der VAPI und umgekehrt statt. Dies erfolgt durch Generierung oder Analyse von PDUs, wobei die Zuordnungsvorschriften in den Mapping Definitionen festgelegt werden und durch das Low-Level-Mapping umgesetzt werden.
-
Die Erfindung wird nachfolgend anhand eines bevorzugten Ausführungsbeispiels näher erläutert. Die Fig. zeigen:
- 1 ein Schichtenmodell des Gesamtsystems,
- 2 eine Darstellung der Vehicle-API-Abstraktionsschicht,
- 3 ein Ablaufdiagramm eines Objekt-Managements,
- 4 ein Ablaufdiagramm der Basisanforderungen an ein VAPI Objekt,
- 5 eine Darstellung der funktionalen Anforderungen an abstrakte Datentypen,
- 6 ein Struktogramm des Low-Level-Mappings,
- 7 eine Darstellung des Low-Level-Mappings aus der Sicht eines VAPI Objektes,
- 8 ein Ablaufdiagramm eines Regelwerkes,
- 9 ein Diagramm zur Analyse einer PDU durch das Regelwerk,
- 10 ein Diagramm zur Erzeugung einer PDU durch das Regelwerk,
- 11 ein Modell einer lokalen Schnittstele und
- 12 ein Modell eines Middleware-Mappings.
-
1 zeigt ein Schichtenmodell zum Austausch fahrzeugoriginärer Informationen. Die unterste Schicht stellt die Fahrzeugnetze und fahrzeugspezifischen Geräte dar. Als Fahrzeugnetze können prinzipiell unterschiedlichste Fahrzeugnetze wie CAN, MOST, Flex Ray, LIN, Firewire oder proprietäre Lösungen zur Anwendung kommen, wie beispielsweise RS-232-Schnittstellen zu einzelnen Geräten. Dieser Teil des Schichtenmodells stellt die fahrzeugspezifische Hardware dar. Die spezifischen Eigenschaften und Zugriffsmechanismen dieser Hardware-Schnittstellen werden durch die höheren Schichten der Fahrzeug-Anwendungsprogramm-Schnittstelle (Vehicle API) abstrahiert, was nachfolgend noch näher erläutert wird.
-
Oberhalb dieser Schicht ist ein Low-Level-CAN-Framework angeordnet, wobei CAN hier nur beispielhaft und nicht beschränkend ist. Diese Schicht stellt die systemspezifischen solftwaretechnischen Geräte-Schnittstellen für die Fahrzeugnetze dar. Das Low-Level-CAN-Framework umfasst Low-Level-Datenquellen. Diese Daten sind noch marken- und/oder herstellerabhängig und werden der Vehicle API als Socket-Schnittstelle mit einem definierten Protokoll zur Verfügung gestellt. Die Anbindung der Low-Level-Quellen wird auf Basis von Konnektoren realisiert, wobei die Umsetzung von Low-Level-Daten in Vehicle-API Datenobjekte durch Mapping-Regeln eines konfigurierbaren Regelwerkes erfolgt, was später noch näher erläutert wird. Aus der Sicht der Vehicle-API sind im Low-Level-CAN-Framework also „Datenquellen bzw. -senken“ in Form von Socket-Streams vorhanden.
-
Es besteht weiterhin die Möglichkeit für einen direkten Zugriff auf diese Schicht, unabhängig von der Vehicle-API Abstraktionsschicht. Hierdurch ergibt sich eine vertikale Skalierbarkeit, bei der die darüberliegenden Schichten weggelassen werden können; die Erweiterbarkeit durch Plugins in dieser Schicht ergibt eine horizontale Skalierbarkeit, indem lediglich die benötigten Protokolle auf der entsprechenden Target-Hardware platziert und entsprechende Konnektoren für die Vehicle-API implementiert werden müssen.
-
Dies ist insbesondere von Vorteil, wenn noch marken- oder herstellerspezifische Applikationen parallel vorhanden sind, die in einer nicht dargestellten Schicht angeordnet sind. Der Grund für eine derartige parallele Schicht kann beispielsweise sein, dass diese Applikationen zu komplex sind, um in dem Regelwerk abgebildet zu werden.
-
Die Vehicle-API stellt die eigentliche Abstraktionsschicht dar, in der Fahrzeugsignale und Eigenschaften in einem objektorientierten Datenmodell dargestellt werden.
-
Das Middleware-Mapping ist die Schicht, welche die Vehicle-API Datenobjekte in middlewarespezifischen Sprachen oder Protokollen (z.B. Voyager Message-Format, SOAP, CORBA, UDP-Stream etc.) für Anwendungen und Dienste zur Verfügung stellt, z.B. für das Service-Framework. In dieser Schicht wird die Verteilung der Vehicle-API Datenobjekte durch die Verteilungsmechanismen der entsprechenden Middleware realisiert.
-
Das Middleware-Mapping ist noch Bestandteil des Vehicle-API-Frameworks und stellt spezielle Schnittstellen zu den darüber angeordneten Anwendungen im Dienste-Framework zur Verfügung. Wie aus dem Schichtenmodell erkennbar, existiert dabei aber mindestens eine Schnittstelle, über die die Anwendungen direkt auf die Vehicle-API zugreifen können.
-
In der 2 ist die Vehicle-API-Abstraktionsschicht dargestellt. Wie bereits in 1 dargestellt, liegt die Vehicle-API zwischen den Anwendungen, Diensten und dem Low-Level-CAN-Framework LLCF.
- - Das Low-Level-Mapping enthält ein Regelwerk, das in der Lage ist, Daten aus Quellen bzw. Senken von unteren Schichten auf Datenobjekte des Datenobjekt Repository zu übersetzen (lesen und schreiben). Welche Regeln anzuwenden sind, wird durch Mapping Definitionen des Vehicle-API Profils festgelegt.
- - Das Datenobjekt Repository verwaltet die Vehicle-API Datenobjekte (Objektverwaltung) und stellt diese den oberen Schichten zur Verfügung (Datenobjekt Repräsentation). Die Zugriffssteuerung betrifft die Definition von Schreib-/Leserechten von Datenobjekten und gegebenenfalls Authentizität sowie Verschlüsselung von Zugriffen auf die Vehicle-API. Für die Eigensicherheit der Vehicle-API sollen Regeln definiert werden können, die auf Basis von Abhängigkeiten zwischen Fahrzeugdaten (repräsentiert durch Datenobjekte) Zugriffsbeschränkungen auf Fahrzeugdaten festlegen können. Die Datenobjekt Definition des Vehicle-API Profils legt fest, welche Datenobjekte in der aktuellen Ausprägung vorhanden sind, welche Datentypen sie enthalten und wie die Abhängigkeit bezüglich der Eigensicherheit definiert sind.
-
Im Gegensatz zur 1 sind in 2 die Low-Level-Konnektoren nicht dargestellt. Das Regelwerk aus 1 steckt in der 2 in den Pfeilen zwischen dem Vehicle-API Profil und dem Datenobjekt Repository sowie dem Low-Level-Mapping, während das Middelware-Mapping in dem rechten Teil der Datenobjekt Repräsentation steckt. Dabei sei weiter angemerkt, dass Objekt-Management aus 1 etwas umfassender ist, als das Datenobjekt Repository, was später noch näher erläutert wird. Bevor das Objekt-Management näher erläutert wird, soll an dieser Stelle ein kurzer Einschub betreffend der Sicherheit eingefügt werden.
-
Die „Sicherheit der Vehicle-API“ betrifft drei Aspekte:
- - Authentizität
- - Verschlüsselung
- - Eigensicherheit
-
Durch Authentizität soll gewährleistet werden, dass keine unberechtigten oder von dritten manipulierten Anfragen an die Vehicle-API gestellt werden können. Dies kann z.B. durch folgende Strategien gewährleistet werden.
- - Bevor eine Anwendung eine (Remote-)Anfrage an die Vehicle-API stellen kann, muss eine Authentifizierung durchgeführt werden.
- - Anwendungen und Module werden signiert; die Signatur muss verifizierbar sein.
- - Eventuell wird in bestimmten Fällen jede Anfrage signiert.
- - Eine Certification Authority (CA) könnte auf einem Internet-Portal installiert sein (z.B. als Dienst auf dem Portal-Server).
-
Durch Verschlüsselung soll gewährleistet werden, dass keine Daten auf dem Übertragungsweg von Applikation zu Vehicle-API entschlüsselt und mitgehört werden können. Hier würde sich z.B. anbieten, SSL verschlüsselte Verbindungen zu verwenden.
-
Eine weitere, wichtige Anforderung ist die „Eigensicherheit“ der Vehicle-API. Dies bedeutet, dass Anwendungen keine Befehle an die Steuergeräte des Fahrzeugs senden dürfen, welche die Sicherheit des Fahrzeugs, des Fahrers, der Insassen oder anderer Verkehrsteilnehmer beeinträchtigen. Besondere Fahrzeugsignale wie z.B. Bremse oder Gaspedal sollten wirkungsvoll geschützt sein. Schreibender Zugriff auf originäre Fahrzeugnetze darf nur durch Zugriffsbeschränkungen (z.B. in Form von Zugriffspolicies) möglich sein. Ebenso sollten Abhängigkeiten zwischen Datenobjekten der Vehicle-API definiert werden können, damit gefährliche Situationen beim Remote-Zugriff auf das Fahrzeug ausgeschlossen sind. Beispiel: „Licht aus!“ nur wenn das Fahrzeug abgestellt ist.
-
In der 3 ist schematisch ein Ablaufdiagramm des Objekt-Managements dargestellt. Das Objekt-Management verwaltet die in der Vehicle-API vorhandenen Datenobjekte und stellt mittels seiner Basisfunktionalität (z.B. Objektliste, Objekt reservieren/freigeben etc.) den Zugriff auf die Datenobjekte (DO) zur Verfügung.
-
Die Vehicle-API enthält ein „Object Repository“, das sämtliche in der aktuellen Ausprägung verfügbaren Datenobjekte der Vehicle-API verwaltet. Die aktuelle Ausprägung der Vehicle-API ist abhängig vom vorhandenen Fahrzeug und dessen Steuergeräten. Definiert wird eine Ausprägung durch das Vehicle-API Profil (VAPI-Profil).
-
Die Zugriffe auf Daten und Datenobjekte der zentralen Verwaltungsinstanz der Vehicle-API (VAPI-Object-Manager) sollen einer Zugriffssteuerung unterliegen. Zur Zugriffssteuerung gehören z.B. Merkmale wie Authentizität, Synchronisation und Eigensicherheit.
-
Das Vehicle-API Datenobjekt-Management (kurz: Object-Manager) muss für Anwendungen eine Liste der verfügbaren Datenobjekte zur Verfügung stellen. Diese Liste soll nicht nur an der C++Schnittstelle der Vehicle-API zur Verfügung stehen, sondern ist vorzugsweise auch Bestandteil in jedem Sprach- und Middleware-Mapping.
-
Datenobjekte müssen auf Basis einer eindeutigen Adresse (z.B. URL) gefunden werden können (DO finden).
-
Weitere Anforderungen an das Objekt-Management, die nicht in diesem Use-Case-Diagramm dargestellt sind:
- - Initialisierung: Die Datenobjekte müssen beim Start des Systems auf Basis des Profils erzeugt und in das Object Repository gestellt werden. Die Erzeugung übernimmt eine Factory(-Klasse). Für die Factory muss das Object Repository eine Schnittstelle bereitstellen, um Datenobjekte anlegen zu können. Weiterhin soll es möglich sein, den Datenobjekten die entsprechenden, im Profil definierten, Low-Level-Mappings zuzuweisen.
- - Das Objekt-Management stellt den zentralen Zugriffspunkt auf die Vehicle-API dar und ist eine lokale Basisinformation für die aufsetzende Middleware, die ein netzwerkübergreifendes Naming zur Verfügung stellen muss.
-
In der 4 ist ein Ablaufdiagramm der Basisanforderungen an ein Vehicle-API Datenobjekt (VAPI Object) dargestellt. Die Basisfunktionalität der Datenobjekte wird durch eine abstrakte Basisklasse definiert. Die Instanz eines Datenobjektes enthält ein Attribut, das eine oder mehrere zusammenhängende Fahrzeugeigenschaften darstellt. Die Begriffe in der 4 bedeuten dabei:
- - VAPI-Anwendung: dieser Aktor repräsentiert eine Anwendung, die auf ein Vehicle-API Datenobjekt zugreift.
- - DO-Daten nutzen: Dies ist die „wichtigste“ Eigenschaft eines Datenobjektes. Es ist das enthaltene Datum bzw. der „Wert des Datenobjektes“. Das Datum enthält die eigentlichen Nutzdaten, die in einer Anwendung (VAPI-Anwendung) interessant sind und stellt die Abbildung der Fahrzeugeigenschaft dar, die durch dieses Datenobjekt beschrieben wird. Das Datum kann - je nach Ausprägung des Datenobjektes gelesen (Datum lesen) und geschrieben (Datum schreiben) werden. Zusätzlich gibt es die Möglichkeit, die Anwendung beim Datenobjekt zu registrieren, um ein Update des Datums zu erhalten, wenn ein geänderter Wert vorhanden ist (Push Daten).
Der Wert des Datenobjektes wird immer in Form eines Datentypen (VAPIType) gespeichert. VAPIType definiert, welche Datentypen in einem Datenobjekt enthalten sein können. Dies wird einerseits durch abstrakte, andererseits durch konkrete Datentypen beschrieben. Abstrakte Datentypen geben Kategorien von Basis- bis zusammengesetzter Datentyp vor; unter konkreten Datentypen sind Ausprägungen wie „Nummer, Text, Relative etc.“ zu verstehen. Jedem Basisdatentypen wird ein Mapping (LLCF-Mapping) zu einer Lower-Level-Quelle/-Senke zugeordnet, welches das entsprechende Fahrzeugdatum in das Objektmodell der Vehicle-API umsetzt. Das Mapping wird bestimmt durch das Profil der Vehicle-API (VAPI-Profil).
Wichtig: Ein Datenobjekt beschreibt mit seinem Wert immer eine Eigenschaft des Fahrzeugs oder einer Fahrzeugkomponente, nicht aber die Komponente selbst mit Eigenschaften verschiedenen Typs. Beispiel: In einem Datum werden die Achsstellungen eines Spiegels beschrieben, aber nicht der gesamte Spiegel mit Achsstellungen, Heizung etc.
- - DO Interface Beschreibung: Dieser Use-Case stellt dar, dass ein Datenobjekt Metadaten enthält, die seine Struktur beschreiben. Dazu gehören z.B. URL des Datenobjektes, Kurzbeschreibung, Interface Beschreibung des enthaltenen Datentyps, verwendbare Zugriffsmethoden (read, write, readwrite, push) und unterstützte Konfigurationsparameter (optional). Bestimmt wird die Interface-Beschreibung durch das Profil der Vehicle-API (VAPI-Profil). Die Interface-Beschreibung muss entsprechend über Middleware- und Sprachschnittstellen für Anwendungen verfügbar gemacht werden (eine Art Service-Discovery).
- - DO konfigurieren (optional): Dieser Use-Case beschreibt die Konfigurierbarkeit eines Vehicle-API Datenobjektes. Die Konfigurierbarkeit bezieht sich auf beliebige Eigenschaften, die das Verhalten des Datenobjektes beeinflussen können. Dies können z.B. Latenzzeiten für ein Daten-Update, Timeout-Werte etc. sein.
- - Zugriffsteuerung: Dieser Use-Case beschreibt, dass DO-Datum nutzen und DO konfigurieren Zugriffsbeschränkungen unterliegen. Je nach Anwendungsfall ist es beispielsweise möglich, dass das Datum nur gelesen, nur geschrieben oder gelesen und geschrieben werden kann. Die Zugriffssteuerung betrifft weiterhin beispielsweise die Authentifizierung, die Eigensicherheit und/oder die Synchronisation.
-
Die Klassen von Vehicle-API Objekten und Datentypen sind dabei getrennt, d.h. ein Datenobjekt enthält keine Eigenschaft mehr, welche die Art des enthaltenen Datentyps beschreibt. Stattdessen ist der Datentyp des enthaltenen Datums selbstschreibend. Es gilt: Ein Vehicle-API Datenobjekt enthält ein Datum, welches das Format eines Datentyps hat.
-
Die Verwaltung und Struktur von Fahrzeugdaten kann auf diese Art und Weise getrennt werden. Die erlaubten Datentypen definieren die Struktur der Daten, während das Vehicle-API Datenobjekt zur Verwaltung einer Datenstruktur dient.
-
Es existieren dabei grundsätzlich drei Arten von Objekt Datentypen:
- - Basis Object Datatypes
- - Advanced Object Datatypes
- - Composite Object Datatypes
-
5 zeigt die funktionalen Anforderungen an die abstrakten Datentypen und die Beziehungen, die zwischen ihnen gelten sollen.
-
Ein Vehicle-API Datentyp VAPIType unterstützt grundsätzlich folgende Funktionalitäten:
- - Status lesen - Lesen des Status und des Wertes des Datentyps
- - Status schreiben - Setzen des Status und des Wertes
- - Interface Beschreibung abrufen
-
Alle weiteren abstrakten Datentypen sind Spezialisierungen von VAPIType.
-
Je nach Ausprägung eines konkreten Datentyps können speziell definierte Interface-Methoden vorhanden sein, die eine „sinnvolle“ Manipulation des Datums zulassen (z.B. toggle()-Methode bei Switch, read()/write() bei einem Stream-Datentyp).
-
Ein Basisdatentyp (BasicDatatype) stellt die geringste Granularität der Vehicle-API Datentypen dar. Ein erweiterter Datentyp (AdvancedType) kann nur aus Basisdatentypen bestehen. Ein zusammengesetzter Datentyp (CompositeType) enthält eine Rolle und besteht weiterhin aus einem Array von entweder erweiterten oder Basisdatentypen. Dadurch dass zusammengesetzte Datentypen keine weiteren zusammengesetzten Datentypen und erweiterte Datentypen keine weiteren erweiterten Datentypen enthalten können, wird die Baumtiefe bei der Zusammensetzung von Datentypen eingeschränkt und kann nicht zu groß (> 3) werden.
-
Ein Basisdatentyp (BasicDatatype) besteht ausschließlich aus sprachspezifischen Basisdatentypen (z.B. „int, char[] etc.“ in C++) und kann keine weiteren Vehicle-API Datentypen enthalten. Er ist die kleinste Granularitätsstufe der Vehicle-API Datentypen. Ein Basisdatentyp enthält grundsätzlich den Wert (Value), der das enthaltene Datum darstellt. Zusätzlich können hier noch weitere Eigenschaften, die das Datum beschreiben (z.B. String-Länge etc.), und Methoden zur Modifikation des Datums vorhanden sein (z.B. toggle()-Methode bei Switch, mathematische Operationen bei Number). Die Struktur eines Basisdatentyps ist immer eindeutig definiert, alle Eigenschaften enthalten gültige Werte. Das bedeutet auch, dass Default-Werte für jedes Feld vorgegeben werden können. Eine Semantik für das Datum kann nicht definiert werden.
-
Basisdatentypen sind diejenigen, die mit „Lower-Level-Datenquellen und -Senken“ verbunden werden können. Beispiele für Basisdatentypen sind:
- - Text: Dieser Datentyp repräsentiert eine textuelle Beschreibung. Er enthält ein Zeichenarray oder einen String, die verwendete Sprache, den verwendeten Zeichensatz sowie weitere Flags.
- - Switch: Dieser Datentyp enthält einen boolschen Wert (wahr oder falsch) und kann z.B. einen Schalter mit zwei Zuständen (ein-/aus) repräsentieren.
- - Number: Repräsentiert einen numerischen Wert, z.B. eine Integer- oder Fließkommazahl.
- - Enum: Dieser Datentyp repräsentiert einen Aufzählungstyp. Er enthält die Anzahl der möglichen Zustände und den aktuell gewählten Zustand.
- - <tbd> Unit: Dieser Datentyp repräsentiert eine Maßeinheit.
- - Stream: Dieser Datentyp beschreibt einen Datenstrom, mit dem Daten im Byte- oder Character-format gelesen und geschrieben werden können.
-
Ein erweiterter Datentyp (AdvancedType) besteht immer aus einem oder mehreren Basisdatentypen. Er enthält grundsätzlich eine Rolle und einen aktuellen Wert (current). Die Role beschreibt die Bedeutung (Semantik) des enthaltenen Wertes und ist definiert durch den „Text“ Basisdatentyp. Der aktuelle Wert ist immer ein Basisdatentyp. Weiterhin sind Eigenschaften auf Basis von Basisdatentypen erlaubt, die das enthaltene Datum näher beschreiben (z.B. Wertebereiche, Maßeinheiten etc.). Jeder Eigenschaft kann zugeordnet werden, ob sie zwingend erforderlich oder optional ist. Rolle und aktueller Wert sind immer zwingend, weitere zwingend erforderliche und optionale Eigenschaften können hinzugefügt werden. Die Anzahl und Struktur der erweiterten Datentypen ist festgelegt. Beispiele sind:
- - Activity: Dieser Datentyp beschreibt eine Instanz, die aktiviert und deaktiviert werden kann. Als Basisdatentyp zur Darstellung der Aktivität wird Switch verwendet.
-
Beispiel: Nebelschlussleuchte an/aus.
- - Enumeration: Dieser Datentyp beschreibt eine Instanz, die 2 bis n Zustände hat. Der aktuelle Zustand wird durch den Basistyp Enum beschrieben. Es müssen mindestens zwei Zustände vorhanden sein. Im Gegensatz zur Activity sind die Zustände in Rollen beschrieben.
-
Beispiel: Stellung des Zündschlüssels.
- - Absolute: Dieser Datentyp beschreibt einen absoluten Wert, der einen numerischen Wert und eine Maßeinheit enthält. Es sollen nur metrische Maßeinheiten erlaubt sein. Der Basistyp für den Wert ist Number, die Maßeinheit wird durch Unit beschrieben.
-
Beispiel: Geschwindigkeit in km/h.
- - Relative: Dieser Datentyp beschreibt einen relativen Wert ohne eine festgelegte Einheit. Der Wert liegt zwischen zwei Grenzen. Minimum und Maximum müssen angegeben werden, ebenso die Rollen von Min. und Max.
-
Beispiel: Tankfüllstand in Prozent.
- - Identity: Dieser Datentyp beschreibt ein textuelles Datum mit statischem Charakter. Optional kann ein regulärer Ausdruck angegeben werden, der das Format des Wertes festlegt. Beispiel: Fahrgestellnummer des Fahrzeugs.
- - Specification: Dieser Datentyp beschreibt ein numerisches Datum mit statischem Charakter. Als Basistyp für den Wert wird Number verwendet. Optional kann die Spezifikation eine Maßeinheit enthalten.
-
Beispiel: Leergewicht des Fahrzeuges.
- - <tbd> FormattedStream: Dieser Datentyp beschreibt einen Datenstrom, mit dem Daten eines definierten Formates gelesen und geschrieben werden können.
-
Ein zusammengesetzter Datentyp fasst entweder Basis- oder erweiterte Datentypen gleichen Typs in einem Array zusammen. Er enthält immer eine Rolle und ein Array mit entweder einem oder mehreren Basis- oder erweiterten Datentypen. Zusammengesetzte Datentypen sind diejenigen, die durch das Profil und das Regelwerk der Vehicle-API bei der Initialisierung oder sogar zur Laufzeit definiert werden können.
-
Der zusammengesetzte Datentyp (CompositeType oder kurz Composite) enthält ein Datenfeld (Array oder Set) von Daten und eine Rolle, über die er identifiziert wird. Die enthaltenen Daten sind erweiterte Datentypen. Composites dürfen nicht enthalten sein.
-
Der Zugriff auf ein Datenfeld erfolgt entweder über die Rolle des Datums oder über den Index des Datenfeldes.
-
Ein „konkreter“ zusammengesetzter Datentyp wird auf Basis des Vehicle-API Profils definiert und enthält ein vorgegebenes Set von Daten. Diese Datentypen können also auch nach der Compile-Zeit der Vehicle-API definiert werden. Ein Composite kann hierbei verschiedene Arten von AdvancedTypes enthalten und bildet damit eine Art Record (bzw. struct).
-
Fahrzeugdaten werden in Form der in Datenobjekten enthaltenen Typen dargestellt und aus „Datenquellen“ gelesen oder in „Datensenken gesendet“. Vom Typensystem der Vehicle-API zu den Low-Level-Protokollen und umgekehrt müssen also Abbildungen definiert werden können.
-
Ansatzpunkte für diese Abbildungen sind Datentypen der Klasse VAPIType. Dazu muss zu jedem VAPIType - enthalten in einem Vehicle-API Datenobjekt und identifiziert durch eine Rolle - eine Abbildung von und zu einer entsprechend vorhandenen Datenquelle/-senke definiert werden können. Diese Abbildung - Im Folgenden auch „Mapping“ oder „Low-Level-Mapping“ genannt - soll in gewissem Umfang parametrisierbar und nicht komplett in Programmcode vorhanden sein. Nur so können aufwändige Änderungen der Vehicle-API bei Erweiterungen oder Änderungen der Datenobjekte vermieden werden.
-
Mappings sollen also nicht fest verdrahtet, sondern für Modell- und Protokollvarianten, eventuell auch allgemein für Datenquellen/-senken-Varianten konfigurierbar sein, ohne dass die Vehicle-API neu compliliert werden muss.
-
Der Begriff „Low-Level-Mapping“ beschreibt also die Funktionalität der Vehicle-API, die dafür zuständig ist, Rohdaten (wie z.B. mit dem Low-Level-CAN-Framework ausgetauscht werden müssen) in einen Datentyp der Vehicle-API zu konvertieren und umgekehrt.
-
In 6 ist eine genauere Struktur des Low-Level-Mappings dargestellt. Dabei werden jedem Datenobjekt ein oder mehrere Low-Level-Mappings zugeordnet, abhängig davon, ob ein erweiterter oder ein zusammengesetzter Datentyp enthalten ist. Ziel eines Low-Level-Mapping ist es, die Protokolleinheiten (PDU „Protocol Data Unit“ - Nachrichtenprotokolleinheit des Low-Level-CAN-Framework, z.B. im Format einer „Broadcast-Manager Nachricht“) eines Datenstroms in ein objektorientiertes Datum eines Vehicle-API Datentyps zu konvertieren. Low-Level-Mappings werden mit Hilfe der Regeln in dem Profil der Vehicle-API beschrieben. Das Low-Level-Mapping benötigt dazu folgende Komponenten:
- - Low-Level-Connector: Der Low-Level-Connector verbindet die Low-Level-Quelle/-Senke (Low-Level-Source/Drain) - wie z.B. Broadcast-Manager des LLCF - mit den Mapping Regeln. Für jede Low-Level-Quelle/-Senke ist genau eine Implementierung eines Konnektors notwendig, um diese an die Vehicle-API anzubinden. Für Konnektoren wird eine einheitliche Schnittstelle definiert. Jeder Konnektor muss auf Basis von Mapping-Regeln (z.B. Setup-, Shutdown-, Conversion-Rules) bedienbar sein. Es soll möglich sein, dass der Konnektor zu beliebigen Low-Level Datenquellen/-Senken verbinden kann. Dies kann z.B. der Broadcast-Manager des LLCF sein, aber auch eine per CORBA angebundene Simulation des Fahrzeugdatums o.ä.
- - Setup-Rule: Das Low-Level-Mapping enthält eine Regel, die beschreibt, welche Datenquelle/Senke dem Vehicle-API Datenobjekt zugeordnet wird. Diese Regel beschreibt, welcher Konnektor zu verwenden und wie dieser zu initialisieren ist, damit der Zugriff auf das Fahrzeugnetz möglich ist. Dies beinhaltet z.B. eine Beschreibung des Sockets (Protokoll-Art, Adresse etc.).
- - Shutdown-Rule: Diese Regel beschreibt, wie der verwendete Konnektor deinitialisiert wird.
- - Object to Low-Level Conversion: Diese Regel legt fest, wie das Datum des Vehicle-API Datenobjektes in eine Protokollnachricht für das Low-Level-CAN-Framework umgesetzt wird. Angewendet wird diese Regel bei einem Schreibzugriff auf das Datenobjekt bzw. auf das assoziierte Fahrzeugdatum. Diese PDU wird dem Konnektor übergeben, welcher dafür sorgt, dass die PDU verschickt wird.
- - Low-Level to Object Conversion: Diese Regel legt fest, wie Daten, die aus dem Low-Level-CAN-Framework empfangen werden, in die objektorientierte Repräsentation des Datums im Vehicle-API Datenobjekt umgesetzt werden. Diese Regel wird beim Lesezugriff auf das Datenobjekt bzw. das assoziierte Fahrzeugdatum angewendet. Für den Lesezugriff gibt es zwei Fälle:
- 1. Der Benutzer der Vehicle-API hat aktiv eine Anfrage gestellt und das Datum soll aus dem LLCF gepollt werden. Für diesen Fall wird -je nach Funktionalität der LLCF-Schicht - eine PDU verschickt, die eine Aktualisierungsanfrage über das Fahrzeugnetz schickt. Auf das entsprechende Fahrzeugdatum wird gewartet. In einem anderen Fall könnte es sein, dass das Fahrzeugdatum im LLCF gecatcht wird. Dies hängt von der Implementierung der unteren Schicht ab.
- 2. Es sind „Listener“ im Vehicle-API Datenobjekt registriert und es wird auf Änderungen des Fahrzeugdatums „gehorcht“. Bei Änderungen des Datums wird das LLCF das geänderte Datum senden. Diese PDU wird dann durch die Regel in den Datentypen der Vehicle-API konvertiert.
-
In der 7 sind die Anforderungen an das Low-Level-Mapping aus Sicht des Vehicle API Datenobjektes (FAPI-Object) in einem Diagramm dargestellt, wobei Folgendes gilt:
- - Connector Setup: Dieser Use-Case beschreibt, dass das Low-Level-Mapping den Konnektor zum LLCF (LLCFConnector) initialisiert. Die Initialisierung erfolgt, bevor auf das assoziierte Fahrzeugdatum zugegriffen wird und es wird die o.g. Regel (Setup-Rule) verwendet.
- - Connector Shutdown: Der Use-Case beschreibt, dass das Low-Level-Mapping den Konnektor zum LLCF (LLCFConnector) deinitialisiert, wenn dieser nicht mehr benötigt wird (z.B. beim Herunterfahren des Systems). Nach der Deinitialisierung kann nicht mehr auf das assoziierte Fahrzeugdatum zugegriffen werden und das Vehicle-API Datenobjekt ist „ungültig“. Für die Deinitialisierung wird die o.g. Regel (Shutdown-Rule) verwendet.
- - LLCFConnector: Dieser Use-Case repräsentiert die Verbindung des Mappings zum Fahrzeugdatum (siehe oben). Der Konnektor sollte Spezialfälle und besondere Funktionalitäten enthalten, die ansonsten dazu führen könnten, dass sich die Komplexität des Mapping-Regelwerks zu stark erhöht.
- - LowLevelToObj Konvertierung: Dieser Use-Case beschreibt die Konvertierung eines Fahrzeugdatums in das Objektmodell der Vehicle-API. Für die Konvertierung wird die o.g. Regel (Low-Level to Object Conversion) verwendet. Hierbei muss die PDU, die aus dem LLCF empfangen wird, analysiert werden, es erfolgt eine Stream-To-Object Konvertierung.
- - ObjToLowLevel Konvertierung: Dieser Use-Case beschreibt die Konvertierung des Datums aus dem Objektmodell der Vehicle-API in das PDU-Format des LLCF-Stream („Object-To-Stream Konvertierung“). Für die Konvertierung wird die o.g. Regel (Object to Low-Level Conversion) verwendet. Hierbei muss die PDU für das LLCF erzeugt werden.
-
Zusammenfassend lässt sich sagen, dass einem Vehicle-API Datenobjekt ein oder mehrere Mappings zugeordnet sein können. Das kommt daher, dass in einem VAPIObject mehrere Datenobjekte in einem zusammengesetzten Datentypen (CompositeType) vorhanden sein können.
-
Jeder Mapping-Regel ist jeweils ein Vehicle-API Datentyp (VAPIType) zugeordnet. Die Mapping Klassen teilen sich jeweils in eine Controller-Klasse (LowLevelMapping), die Verbindung zu den Fahrzeugdaten (Aggregation von LowLevelConnector) und Mapping-Regeln (Aggregation von MappingRule) auf. Die Controller-Klasse ist dafür zuständig, die Kommunikation zwischen Datenobjekt (VAPIObject) und Low-Level Konnektor zu bearbeiten und die Regeln zur Konvertierung der Daten anzuwenden. Die Aggregationen und Assoziationen zu Vehicle-API Datenobjekten, Datentypen und Regeln sind jeweils als Referenzen in Member-Variablen der Controller-Klasse enthalten.
-
LowLevelConnector definiert das Interface zu verschiedenen Ausprägungen von Konnektoren. Als mögliche Beispiele sind hier BCastConnector, SocketConnector, PersistenceConnector und CORBAConnector genannt. Die Konnektoren müssen so implementiert sein, dass sie mittels Mapping Regeln gesteuert werden können.
-
Für die Beschreibung der Mapping-Regeln wird vorzugsweise ein XML-Format definiert.
-
Für die Vehicle-API ist ein Regelwerk zu definieren (siehe 1) und zur realisieren, das Folgendes unterstützt:
- - Erzeugung einer Instanz bzw. Ausprägung einer Vehicle-API für das spezielle Fahrzeug und dessen Konfiguration mit einer entsprechenden Menge von Datenobjekten,
- - Konfiguration und Anbindung an das Low-Level-CAN-Framework und Zusammenstellung von Datenkonvertierungsregeln
- - Einlesen von Profilen zur Gesamtkonfiguration der Vehicle-API.
-
In der 8 ist ein solches Ablaufdiagramm für ein Regelwerk dargestellt.
-
Im Allgemeinen wird davon ausgegangen, dass Datenquellen-/senken der Low-Level-Schichten Streams sind, die festgelegte Datenformate und Datenpakete zum Austausch von Daten unterstützen, so wie es z.B. beim Low-Level-CAN-Framework der Fall sein soll. Die Vehicle-API stellt Fahrzeugdaten in einem Objektmodell dar. Ziel ist also, die streambasierten Daten in das Objektmodell zu konvertieren (Lesezugriffe) und umgekehrt (Schreibzugriffe), wobei dies aus der Sicht einer Anwendung beschrieben wird.
-
Das Regelwerk muss die Datentypen kennen, die es zur Erzeugung von Datenobjekten der Vehicle-API nutzen kann. Zusätzlich können auch weitere Datentypen erzeugt werden, indem vorhandene Datentypen in einem zusammengesetzten Datentyp (Composite) kombiniert werden.
-
Damit ein Vehicle-API Datenobjekt mit einer Low-Level-Quelle verbunden werden kann, unterstützt das Regelwerk eine „Mapping-Logik“, die Daten aus dem Stream-Format in ein Vehicle-API Datum umsetzen kann (Stream-2-DO) und umgekehrt (DO-2-Stream).
-
Die Erzeugung von Datenobjekten geschieht in einer Object-Factory. Diese ist dafür zuständig, Datenobjekte und deren Struktur zu erzeugen und dafür zu sorgen, dass die benötigten Mappings auf die Datenquellen/-senken der „Lower-Level-Schichten“ angebunden werden. So müssen folgende Aufgaben von der Object-Factory erledigt werden:
- - Einlesen eines Profils (Profil einlesen)
- - Erzeugung und Zusammenstellung von allen benötigten Datenobjekten im „Object-Repository“ der Vehicle-API: Datentyp, Name, URL, Interface-Beschreibung (Datenobjekte erzeugen)
- - Auswahl und Konfiguration von Mappings für die Paare:
- - Datenobjekt Mapping zu Stream & Protokoll (LLCF-Anbindung)
- - Datenobjekt Mapping zu API (Anbindung herstellerspezifischer Applikation)
-
Ein Mapping soll durch Vehicle-API Profile beschreibbar sein. Ein Profil enthält einen konkreten Anwendungsfall (z.B. „Fahrzeug XY stellt Menge Z an Datenobjekten zur Verfügung“). Es enthält folgende Komponenten:
- - Interface-Profile: Beschreibung von Metadaten und Schnittstellen von Datentypen der Datenobjekte, insbesondere von zusammengesetzten Datentypen.
- - Mapping-Profile - Beschreibung der Art, wie die Datenquellen/-senken bzw. Low-Level-Protokolle in Vehicle-API Datenobjekte umgesetzt werden.
- - Instanzen der Datenobjekte - Welche Datenobjekte stehen zur Verfügung und wie sehen sie für diesen Anwendungsfall aus?
-
Die Beschreibung soll in XML erfasst werden. Dadurch ist ggf. eine Abbildung dieser Beschreibung auf Modelle, Tools, Datenbanken möglich.
-
Nachfolgend wird ein kurzer Überblick gegeben, welche Funktionalitäten von der Vehicle-API zur Realisierung den Mapping- bzw. Konvertierungsregeln unterstützt werden sollten:
- Initialisierung
- 1. Wahl des Konnektor
- 2. Parameter für die Initialisierung des Konnektors (Adresse der Verbindung zu Fahrzeugdaten, z.B. Socket-Adresse, Port, Socket-Parameter)
- 3. Eventuell Kommando-PDU zur Initialisierung für gewünschtes Fahrzeugdatum
- Datum lesen
- 1. Anfrage-PDU zusammenstellen und senden
- 2. Erkennen und Parsen der PDU
- 3. Extrahieren der relevanten Daten
- 4. Berechnung des VAPIType Datums auf Basis der extrahierten Daten
- 5. Rückgabe des Datums
- Push
- 1. Empfang einer PDU aus Low-Level-Quelle
- 2. Erkennen und Parsen der PDU
- 3. Extrahieren der relevanten Daten
- 4. Berechnung des VAPIType Datums auf Basis der extrahierten Daten
- 5. Push des Datums an VAPI-Objekt
- Datum schreiben
- 1. Erzeugung der PDU aus dem VAPIType-Datum
- 2. Senden der PDU an Low-Level Senke
- Deinitialisierung
- 1. Eventuell Kommando-PDU zur Deinitialisierung
- 2. Eventuell Parameter für die Deinitialisierung des Konnektors
-
Nachfolgend soll anhand 9 die Low-Level-Datenobjekt Konvertierung näher erläutert werden.
-
Es wird davon ausgegangen, dass es sich bei den Low-Level-Quellen um Streams handelt, die ein vorgegebenes Protokoll „sprechen“. Die Daten eines Streams lassen sich eindeutig in Protokolleinheiten abgrenzen, die ein definiertes Format enthalten. Jede PDU muss vom Regelwerk analysiert werden. 9 illustriert die notwendigen Schritte.
-
Die Analyse funktioniert folgendermaßen:
- - Die PDU ist ein zusammenhängender Speicher von Bytes.
- - Es existiert eine Beschreibung der in der PDU enthaltenen Datenfelder (Typen, Länge, Byteorder).
- - Die für das Datum des Vehicle-API Objekt relevanten Daten x_1 ... x_n werden aus der PDU extrahiert und einer Berechnungsregel zur Verfügung gestellt.
- - Es ist bekannt, welcher Datentyp aus der PDU entstehen und wie das eigentliche Datum berechnen werden muss.
- - die Berechnungsformel wurde bei Initialisierung der Vehicle-API initialisiert, Platzhalter für die aus der PDU gewonnenen Daten sind vorhanden.
- - Die Platzhalter werden durch die aus der PDU gewonnenen Daten x_1 ... x_n ersetzt, die Berechnung wird ausgeführt und das Ergebnisdatum wird im Vehicle-API Datenobjekt eingesetzt.
-
Hier existieren zwei Regeln, die im XML-Profil beschreibbar sein müssen:
- - PDU-Analyse-Regel: Extraktion der Relevanten Daten x_1 ... x_n
- - Berechnungsregel: Erzeugung des VAPIType Datums durch Ersetzen der Platzhalter.
-
Weiterhin gibt es zwei Möglichkeiten, PDUs aus Low-Level-Schichten zu empfangen:
- - Aktiv durch einen Request: Es wird eine Anfrage in den Stream gesendet und auf eine entsprechende Antwort gewartet.
-
In diesem Fall muss eine Request-PDU zusammengestellt und gesendet werden.
- - Passiv: Am anderen Ende des Streams existiert ein Prozess, der automatisch sendet, wenn neue Daten verfügbar sind (z.B. nach entsprechendem Setup des Broadcast-Manager des LLCF).
-
In der 10 ist die Datenobjekt-Low-Level-Konvertierung näher dargestellt.
-
Auch hier wird davon ausgegangen, dass das Stream-Format eindeutig in PDUs abgrenzbar ist und sich diese eindeutig beschreiben lassen. Hier muss eine PDU nicht analysiert, sondern erzeugt werden. Dazu muss ein vollständiges Template (Muster) der PDU vorhanden sein (definiert durch Profil). 10 illustriert die notwendigen Schritte.
-
Die Erzeugung einer PDU funktioniert dann folgendermaßen:
- - Das Template der Ziel-PDU hat Platzhalter x_1 ... x_n, die mit gültigen Daten ausgefüllt werden müssen.
- - Bei der Initialisierung der Vehicle-API werden die Platzhalter, die konstant bleiben, bereits in das Template eingesetzt.
- - Die Berechnungsformel zur Umrechnung des Vehicle-API Datums in das PDU-Format wurde bereits bei der Initialisierung der Vehicle-API initialisiert. Das Datum wird in den Datentypen der PDU umgerechnet und ebenfalls für den entsprechenden Platzhalter eingesetzt.
-
Hier existieren folgende Regeln, die im XML-Profil beschreibbar sein müssen:
- - Template der PDU
- - Berechnungsregel: Erzeugung des PDU Datentypes aus dem Vehicle-API Datum
-
Zusätzlich müssen Schreibzugriffe synchronisiert werden.
-
Nachfolgend sollen noch einmal die wichtigsten Beschreibungen des Vehicle-API-Profils zusammengefasst werden, mittels derer eine Instanz der Vehicle-API beschreibbar und anpassbar sein soll.
-
Das Profil sollte folgende Beschreibungen enthalten:
- - Interface-Beschreibung:
- Beschreibung der vorhandenen Datenobjekte und deren Schnittstellen sowie Zugriffsmethoden (read, write, readwrite, push).
- - Mapping-Beschreibung:
- Beschreibung der Umsetzung von Low-Level Daten in Datenobjekte.
- - Abhängigkeitsbeschreibung:
- Beschreibung von Abhängigkeiten zwischen Datenobjekten zur Eigensicherheit.
-
Die Beschreibungen sind vorzugsweise in einem XML-Format vorhanden.
-
Die Interface-Beschreibung eines Datenobjektes enthält Folgendes:
- - Beschreibung des Namens (URL) und textuelle Beschreibung des DO
- - Beschreibung der möglichen Zugriffsmethoden: read, write, readwrite, listener
- - Beschreibung des Datentypen: Art, Rollen, Grenzen etc.
- - Beschreibung der Konfiguration: Schlüssel und Wert (optional)
- - Beschreibung möglicher Konfigurationsparameter: Parameter und Beschreibung (optional)
-
Die Interface-Beschreibung der Vehicle-API ist auch die Beschreibung, die „nach außen“ für Anwendungen und Dienste sichtbar sein wird.
-
Durch die Interface-Beschreibung wird ein Profil generiert, das die aktuelle Ausprägung einer Vehicle-API Instanz beschreibt. Hier wird festgelegt, welche Datenobjekte in der Vehicle-API vorhanden sind und sie Schnittstellen aussehen.
-
Die Mapping-Beschreibung der Vehicle-API legt fest, wie aus Protokolldaten
- 1. des Low-Level-CAN-Framework,
- 2. der marken- und herstellerspezifischen Aplikationen
ein Datenobjekt der Vehicle-API erzeugt wird. Folgende Punkte müssen dabei beachtet werden:
- - Adressierung und Handling der Datenquelle:
- Auf welche Datenquelle/-senke wird zugegriffen? Wie funktionieren Vorgänge wie Öffnen, Schließen, Initialisierung, Deinitialisierung? Welche Parameter sind notwendig?
- - Daten lesen:
- Format einer PDU; Welche Identifier müssen beachtet werden? Wie wird in den DO Datentyp umgerechnet? Wie funktioniert eine Abfrage (get) und wie funktioniert passiver Empfang (listen)?
- - Daten schreiben:
- Wie muss die PDU definiert sein, damit sie korrekt gesendet werden kann? Muss zyklisch oder nur einmal gesendet werden etc.
- - Welches Protokoll wird beim Zugriff auf marken- und herstellerspezifische Applikationen verwendet?
-
Als Schnittstelle zu unteren Schichten kommen mehrere Arten in Frage. Zum einen eine auf Protokollen basierende, zum anderen eine auf Funktionsaufrufen basierende Schnittstelle. Im Fall des letzten Typs kann es notwendig sein, die Schnittstelle auf wenige Methoden zusammenzufassen, mit denen Daten und Befehle in definierbaren Datenpaketen - ähnlich wie PDUs bei Streams - übergeben werden. Hinter dieser Schnittstelle steckt ein Dispatcher, der Protokollbefehle in Schnittstellenaufrufe umsetzt.
-
In der 11 ist ein Beispiel für eine lokale Schnittstelle dargestellt. Unter dem Begriff lokale (Applikations-) Schnittstelle sind diejenigen Schnittstellen der Vehicle-API zu verstehen, die nicht direkt über Netzwerkgrenzen verteilt werden. Dabei stellen die verwendeten Begriffe im Einzelnen dar:
- - Lokale VAPI-Anwendung:
- Dieser Akteur des Use-Case Diagramms stellt einen speziellen Fall einer Vehicle-API Anwendung (VAPI-Anwendung) dar. Eine lokale Anwendung wird auf demselben Gerät ausgeführt, welches auch die Vehicle-API enthält.
- - C++-API:
- Diese Schnittstelle ist sozusagen die „native Schnittstelle“ zur Vehicle-API und der „kleinste gemeinsame Nenner“ für Zugriffe. Auf dieser Schnittstelle können lokale Applikationen und
- Sprach- und Middleware-Mapping Module aufsetzen, um Fahrzeugdaten für weitere Sprachen zur Verfügung zu stellen oder über das Netzwerk zu verteilen.
- - Java-API (JNI-Mapping):
- Dieser Use-Case ist ein Beispiel für ein Mapping in die Zielsprache Java. Per „Java-native-Interface“ (JNI) könnte ein lokale Schnittstelle für eine Java-Virtual-Machine geschaffen werden. Es ist jedoch auch möglich, aus einer Sprache wie Java mittels einer Middleware und eines sprachunabhängigen Protokolls (z.B. XML basiert) auf die Vehicle-API zuzugreifen.
- - VAPI-ML (XML-Mapping):
- Dieser Use-Case beschreibt, dass die Vehicle-API (aufbauend auf der C++-Schnittstelle) eine auf XML basierende Schnittstelle zu Fahrzeugdaten zur Verfügung stellt. Hierfür sind zwei Definitionen für XML-Formate notwendig.
- 1. Ein Nachrichtenformat, mit dem Zugriffe auf Fahrzeugdaten formuliert und Daten transportiert werden können.
- 2. Ein Format zur Beschreibung der Metadaten der zentralen Verwaltungsinstanz und der Datenobjekte der Vehicle-API.
Weiterhin ist hierfür ein XML-Parser/-Creator zu integrieren. Die Erzeugung von XML-Nachrichten soll möglichst performant sein, deswegen soll eine C++-Implementierung eines XML-Parser verwendet werden (z.B. Xerses-C++).
-
Die Verteilung der Vehicle-API soll auf Basis von sogenannten „Middleware-Mappings“ erfolgen. Dabei ist erwünscht, dass sowohl die verwendete Konnektivität (z.B. Bluetooth, WLAN, Ethernet, GPRS) sowie die Art der Middleware möglichst beliebig gewählt werden kann. Dabei soll die Vehicle-API nicht nur gerätelokale Schnittstellen bereitstellen und durch Mehrwertdienste verteilen, sondern über eigene Basisdienste zur Verteilung verfügen. Ein solcher Basisdienst wird im Zusammenhang mit der Vehicle-API als „Middleware-Mapping“ bezeichnet. 12 zeigt Beispiele für mögliche Middleware-Mappings und deutet den Zusammenhang mit den lokalen Schnittstellen an. Dabei bedeuten:
- - Netzwerk VAPI-Anwendungen:
- dieser Akteur stellt den speziellen Fall einer Vehicle-API Anwendung (VAPI-Anwendung) dar, die über das Netzwerk auf die Vehicle-API zugreift. Dies können z.B. Dienste des Service-Framework, OSGi-Bundles etc. sein.
- - OSGi-Integration:
- Dieser Use-Case beschreibt ein Mapping der Vehicle-API in ein OSGi-Framework. Die Vehicle-API wird hier mittels einer auf Sockets basierenden Middleware auf ein weiteres Gerät verteilt und im OSGi-Framework als OSGi-Bundle zur Verfügung gestellt.
- - Sockets:
- Dieser Use-Case ist ein Beispiel für einen Socket basierten Ansatz. Es könnte z.B.
- gewünscht sein, dass mit einer Socket-Verbindung auf die Vehicle-API zugegriffen werden kann. In diesem Beispiel werden über die Socket-Schnittstelle Nachrichten im VAPI-ML-Format ausgetauscht.
- - Service-FW (Voyager-Mapping):
- Dieser Use-Case beschreibt ein Mapping auf das Service-Framework, das per iGate an Fahrzeugdaten angebunden werden soll. Nachrichten im Service-Framework werden in einem XML-Format ausgetauscht. Daher ist es auch sinnvoll, ein XML-Format für Vehicle-API Zugriffe und Daten anzubieten. Die Formate sollen aufeinander abgestimmt werden.
- - CORBA:
- Dieser Use-Case beschreibt ein Mapping per CORBA. Es wäre möglich, die Fahrzeugdaten auch per CORBA zur Verfügung zu stellen. Statt eines Java basierten Object Request Brokers (ORB) könnte auch ein C++ basierter ORB verwendet werden.
-
Die Verteilung der Vehicle-API beinhaltet in erster Linie den Aspekt, die in einem physikalischen Gerät vorhandene Vehicle-API für Client-Anwendungen im lokalen oder auch in einem globalen Netzwerk (Internet) zur Verfügung zu stellen.
-
Ein weiterer Aspekt, der optional hinzugefügt werden könnte, ist die „Lokationstransparenz“. Dies würde bedeuten, dass die Vehicle-API und deren Datenobjekte auf verschiedene physikalische Geräte im Fahrzeug verteilt werden. Jedoch könnte sie mit Hilfe eines Middleware-Mapping zu einer Einheit zusammengefasst werden, so dass Client-Anwendungen auf eine logische Vehicle-API zugreifen.
