-
Die Erfindung betrifft ein Verfahren zum Weiterleiten von Daten in einem Kommunikationssystem eines Fahrzeugs nach der Gattung des unabhängigen Anspruchs.
-
Stand der Technik
-
Mit AUTOSAR (AUTomotive Open System ARchitecture) wird eine Entwicklungspartnerschaft aus Automobilherstellern, Steuergeräteherstellern sowie Herstellern von Entwicklungswerkzeugen, Steuergeräte-Basis-Software und Mikrocontrollern bezeichnet, deren Ziel darin besteht, den Austausch von Software auf verschiedenen Steuergeräten zu erleichtern.
-
AUTOSAR stellt eine Reihe von Spezifikationen zur Verfügung, die grundlegende Softwaremodule beschreiben, Anwendungsschnittstellen definieren und eine gemeinsame Entwicklungsmethodik auf der Grundlage eines standardisierten Austauschformats erstellen. Basissoftwaremodule, die durch die AUTOSAR Layered Software Architecture zur Verfügung gestellt werden, können in Fahrzeugen unterschiedlicher Hersteller und Elektronikkomponenten unterschiedlicher Anbieter eingesetzt werden.
-
Aus der
US 8966443 ist ein Verfahren bekannt, um eine AUTOSAR-SoftwareKomponente eines AUTOSAR-Software-Systems zu umgehen.
-
Aufgabe der vorliegenden Erfindung ist es, die Verarbeitungsgeschwindigkeit insbesondere eines AUTOSAR-Software-Systems weiter zu verbessern. Diese Aufgabe wird gelöst durch die Merkmale des unabhängigen Anspruchs.
-
Offenbarung der Erfindung
-
Das Verfahren gemäß den Merkmalen des unabhängigen Anspruchs ermöglicht gerade für Steuergeräte mit integrierter Gateway-Funktionalität eine performante Weiterleitung bzw. Routing bestimmter Daten. Durch die entsprechende Auslagerung der Routing-Funktionalität auf die weitere Domäne kann die erste Domäne, insbesondere die AUTOSAR-Domäne, entlastet werden. Dies führt zu einem besseren Lastausgleich im Gesamtsystem und eine bessere Nutzung von Hardware-Ressourcen insbesondere bei der Nutzung von Multikern-Controllern. Durch die vorgeschlagene hybride Software-Architektur in Form der unterschiedlichen Domänen und Aufgabenverteilung kann zum einen die Software in der AUTOSAR-Domäne unverändert beibehalten werden zur Erfüllung des Hostings von Fahrzeug-Funktionen, während die Software auf der weiteren Domäne gerade hinsichtlich der Leistungsfähigkeit der Weiterleitung der Daten und damit für leistungsrelevante Anwendungsfälle optimiert werden kann. Durch die vorgeschlagene Verteilung der Funktionen in unterschiedliche Domänen und damit unterschiedliche Ausführungsinstanzen können diese je nach Systemanforderungen und Design flexibel über einen oder mehrere CPU-Kerne verteilt werden. Insbesondere im Fahrbetrieb des Fahrzeugs kann aufgrund der vorgeschlagenen Lösung eine geringe Routing-Latenz erzielt werden. Es wird unter anderem dadurch erreicht, dass der Datenaustausch mit der ersten Domäne immer über die weitere Domäne, die sich durch leistungsstarke Weiterleitungsmechanismen auszeichnet, vorgenommen wird. Besonders zweckmäßig verbleiben die performancerelevanten Daten in der weiteren Domäne zur Weiterverarbeitung, während die weiteren Daten die erste Domäne weitergeleitet werden.
-
In einer zweckmäßigen Weiterbildung ist für ein erstes Bussystem eine eigene weitere Domäne und für ein weiteres Bussystem eine weitere eigene Domäne verwendet, wobei ein Datenaustausch zwischen den beiden weiteren Domäne nur auf Ebene einer Dateneinheit, insbesondere eine Protocol Data Unit (PDU), insbesondere eine generische Dateneinheit und/oder in einem Container enthaltene Dateneinheit erfolgt. Gerade diese Routing-Mechanismen werden umfassend auf Anwendungsdaten angewendet, die zwischen Fahrzeugfunktionen auf verschiedenen Steuergeräten ausgetauscht werden, wenn das Fahrzeug im Normalbetrieb fährt.
-
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass zwischen der ersten und der weiteren Domäne Daten auf Ebene von Frames und/oder auf Ebene einer Dateneinheit, insbesondere unter Verwendung eines von beiden Domänen geteilten Speichers, ausgetauscht werden dürfen, während Daten zwischen einer der weiteren Domänen mit einer anderen der weiteren Domänen nur auf Ebene der Dateneinheit, nicht jedoch auf Ebene des Frames ausgetauscht werden. Damit kann auf einen funktions-und protokoll unabhängigen Datenaustauschmechanismus zurückgegriffen werden. Damit kann erreicht werden, dass die im AUTOSAR-Standard definierten Schnittstellen beibehalten werden können, sodass sich die Integration der ersten Domäne im Gesamtsystem vereinfacht wird bzw. wie üblich beibehalten werden kann. Der Datenaustausch innerhalb der weiteren Domänen auf Basis der Dateneinheit kann besonders schnell und performant durchgeführt werden.
-
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass die weitere Domäne zumindest einen Treiber zur Anbindung an die physikalische Schnittstelle des Kommunikationssystems, insbesondere Bussystem, insbesondere zum Datenzugriff bzw. Kontrollmechanismen für ISO/OSI Layer 2, umfasst, und/oder dass die weitere Domäne zumindest einen Protokollspeicher bzw. Protokoll Stack, insbesondere für einen Datenzugriff bzw. Kontrollmechanismen für ISO/OSI Layer 3-5, die für die Handhabung performancerelevanter Daten aus den weiteren Domänen erforderlich sind, umfasst, und/oder dass die weitere Domäne zumindest ein Gateway zur Weiterleitung von zumindest einer Dateneinheit, insbesondere zwischen Protokoll Stacks unterschiedlicher weiterer Domänen, umfasst. Damit wird zum einen die Kommunikation lediglich über die weitere Domäne sichergestellt. Zudem kann eine performante Handhabung der leistungsrelevanten Anwendungsfälle vorgenommen werden wie beispielsweise eine Verarbeitung von Nicht-Transport-Protokollen zum Extrahieren der Dateneinheiten für performantes Routing.
-
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass in der ersten, insbesondere AUTOSAR-Domäne ein virtueller Treiber, insbesondere als Proxies realer Treiber, zum Austausch von Frames zwischen der ersten und der weiteren Domäne mit dem jeweiligen Treiber der weiteren Domäne und/oder zum Austausch mit einem in der ersten Domäne vorgesehenen Interface für Frames vorgesehen ist, und/oder dass in der ersten Domäne zumindest ein Adapter zum Austausch von Daten bzw. Dateneinheiten mit dem Gateway der weiteren Domäne und/oder zum Austausch mit einem in der ersten Domäne vorgesehenen Router für die Dateneinheiten vorgesehen ist. Damit wird sichergestellt, dass der direkte Zugriff auf physikalische Kommunikationsschnittstellen auf die weitere Domäne beschränkt ist. Über die virtuellen Schnittstellen kann jedoch die entsprechende Einbindung der weiteren Domäne insbesondere in der AUTOSAR-Architekturdefinition berücksichtigt werden. Über den Adapter kann auf Ebene der Dateneinheit ein Datenaustausch mit der weiteren Domäne sichergestellt werden.
-
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass aus einer Systembeschreibung der ersten Domäne, insbesondere ein komplettes AUTOSAR-Steuergeräte-Extrakt, ein Konfigurationscode die Weiterleitung der Daten in der weiteren Domäne betreffend und/oder eine reduzierte Systembeschreibung der ersten Domäne, insbesondere ein reduziertes AUTOSAR-Steuergeräten-Extrakt, generiert wird bzw. werden. Damit kann eine bestehende Toolchain angepasst werden, um die jeweiligen Domänen-spezifischen Konfigurationen aus der kompletten Steuergerätekonfiguration abzuleiten. Damit kann eine automatisierte Software-Generierung für die beiden Domänen erfolgen. Es handelt sich hierbei um eine Werkzeugunterstützung zur Verarbeitung von insbesondere AUTOSAR-Standardeingaben (Steuergeräte-Extrakt im ARXML-Format) zur Konfiguration der Software sowohl der AUTOSAR-Domäne wie auch der weiteren Domäne.
-
In einer zweckmäßigen Weiterbildung wird der Konfigurationscode unter Verwendung eines die Weiterleitung der Daten beschreibenden Datenmodells erzeugt. Über das Datenmodell kann eine Speicherung und Visualisierung von Daten für aus dem Steuergeräte-Auszug extrahierte Routing-Einrichtung der weiteren Domäne erfolgen.
-
Weitere zweckmäßige Weiterbildungen ergeben sich aus weiteren abhängigen Ansprüchen und aus der Beschreibung.
-
Kurze Beschreibung der Zeichnung
-
Es zeigen:
- 1 eine klassische E/E-Architektur eines Kraftfahrzeugs,
- 2 eine Domänen-E/E-Architektur eines Kraftfahrzeugs,
- 3 eine zentrale E/E-Architektur eines Kraftfahrzeugs,
- 4 eine abstrakte Darstellung der hybriden Software-Architektur
- 5 eine schematische Darstellung der Datenstruktur,
- 6 die verschiedenen Datenpfade in der hybriden Software-Architektur
- 7 die Datenpfade für ein Routing von PDU und Container innerhalb einer der weiteren Domäneen,
- 8 die Datenpfade für ein Routing von PDU und Container zwischen zwei der weiteren Domäneen betreffend den Empfangs-Anteil,
- 9 die Datenpfade für ein Routing von PDU und Container zwischen zwei der weiteren Domäneen betreffend dem Übertragungs-Anteil,
- 10 die Datenpfade für Empfang und Übertragung von Frames durch die AUTOSAR-Domäne,
- 11 die Datenpfade für Empfang und Übertragung von PDUs durch die AUTOSAR-Domäne,
- 12 die Datenpfade für einen PDU- Empfang durch eine Anwendung und PDU-Routing,
- 13 ein Werkzeug und Workflow für die hybride Software-Architektur sowie
- 14 ein Datenmodell der Routing-Einrichtung.
-
Ausführungsform der Erfindung
-
Die Erfindung ist anhand eines Ausführungsbeispiels schematisch dargestellt und wird nachfolgend unter Bezugnahme auf die Zeichnung ausführlich beschrieben.
-
Im Automobilkontext umfasst die Elektro-und Elektronikarchitektur (E/E) von Fahrzeugen ein Netzwerk von elektronischen Steuergeräten 5, die über Kommunikationskanäle miteinander verbunden sind. Diese E/E-Architekturen sind so konzipiert, dass der Informationsaustausch zwischen den Steuergeräten 5 eingeschränkt ist. Diese Beschränkung der Informationen erfolgt technisch durch eine Gateway-Funktionalität 3, die als reine Software- oder Software-Hardware-Lösung in bestimmten Steuergeräten 2, 4, 6, 7, 8 an Kommunikationsschnittstellen im Fahrzeug integriert ist. Aufgabe des Gateways 3 ist es, Kommunikationskanäle gleicher oder unterschiedlicher Fahrzeug-Bus-Technologien (beispielsweise CAN, LIN, Flexray, Ethernet o.ä.) miteinander zu verbinden und eine kontrollierte Übertragung von Kommunikationsbotschaften zwischen ihnen zu ermöglichen. In den 1-3 sind unterschiedliche E/E-Architekturen gezeigt.
-
Die klassische E/E-Architektur gemäß 1 zeichnet sich durch ein zentrales Gateway 2 mit Gateway-Funktionalität 3 aus, über welches mehrere Kommunikationskanäle, an denen jeweils Steuergeräte 5 angeschlossen sind, miteinander verbunden sind. Untergruppen von Steuergeräten 5 können datentechnisch über ein Sub-Gateway 4 wiederum mit Gateway-Funktionalität 3 miteinander verbunden sein.
-
Bei einer Domänen-bezogenen E/E-Architektur gemäß 2 ist wiederum das zentrale Gateway 2 vorgesehen, welches mehrere Domänen-Steuergeräte 6 mit darin enthaltener Gateway-Funktionalität 3 zum Zwecke des Datenaustauschs miteinander verbindet. Über die Domänen-Steuergeräte 6 können weitere Steuergeräte 5 oder je nach Architektur Sub-Gateways 4 mit daran angeschlossenen Steuergeräten 5 zum Zwecke des Datenaustausches vorgesehen sein.
-
Bei der Zonen-bezogenen E/E-Architektur gemäß 3 sind mehrere Zonensteuergeräte 9 mit Gateway-Funktionalität 3 vorgesehen, die beispielsweise an unterschiedlichen Stellen im Kraftfahrzeug angeordnet werden können. Die Zonensteuergeräte 9 werden über eine Recheneinrichtung 8, insbesondere ein leistungsstarker Fahrzeug-Computer zum Zwecke des Datenaustauschs miteinander verbunden. Die Recheneinrichtung 8 umfasst hierzu ebenfalls eine Gateway-Funktionalität 3. Über die Zonensteuergeräte 9 sind datentechnisch weitere Steuergeräte 5, die räumlich (beispielsweise im Fahrzeug vorne links, vorne rechts, heckseitig etc.) im Bereich dieser Zone angeordnet sind, verbunden. Je nach Anwendungsfall können auch Sub-Gateways 4 zur Anbindung weiterer Steuergeräte 5 vorgesehen sein.
-
Der Hauptanwendungsfall der meisten Steuergeräte 5 ist es, Anwendungssoftware-Komponenten für die Realisierung verschiedener Fahrzeugfunktionen (beispielsweise Bremsen, Motorsteuerung, Energiemanagement etc.) zu hosten. Um dies zu erleichtern wurde in AUTOSAR ein automobiler Standard für Software-Architektur definiert. AUTOSAR definiert Standardschnittstellen zu den Anwendungssoftware-Komponenten in einer Echtzeitumgebung (auch RTE (Real-timeenvironment) abgekürzt) und die entsprechenden infrastrukturellen Mechanismen wie Betriebssystem, Kommunikation, Diagnose, nichtflüchtige Datenspeicherung in der Basissoftware etc. Daher ist es vorteilhaft, den standardisierten Ansatz mit der Standardsoftware AUTOSAR für diesen Anwendungsfall beizubehalten.
-
Für Steuergeräte mit integrierter Gateway-Funktionalität 3 muss jedoch ein leistungsstarkes Datenhandling wie eine performante Weiterleitung von Kommunikationsnachrichten etc. erfüllt werden. Obwohl die erforderliche Routing-Funktionalität durch den AUTOSAR- Standard definiert und unterstützt wird, reicht die Routing-Leistung in der AUTOSAR-Standardsoftware oft nicht aus, um die Leistungsanforderungen, wie sie beispielsweise von Fahrzeugherstellern definiert werden, zu erfüllen. Durch die Standardisierung von Softwarearchitektur, Funktionalität und Schnittstellen durch AUTOSAR und Haftungsfragen bei Änderungen von Standardsoftware ist die Möglichkeit, die Software auf Leistung zu optimieren, eingeschränkt. Darüber hinaus bieten die unterschiedlichen Kommunikationsparadigmen und Routing-Mechanismen der Fahrzeughersteller zusätzliches Optimierungspotenzial über Fahrzeughersteller-spezifische Lösungen, die mit AUTOSAR-Standardsoftware nicht genutzt werden können. Somit ist die AUTOSAR-Standardsoftware nicht optimal für die Implementierung der Gateway-Funktionalität 3.
-
In den nachfolgenden Ausführungsbeispielen wird die Gateway-Funktionalität 3 näher beschrieben, die ein leistungsstarkes Daten-Handling bzw. Daten-Routing für ein AUTOSAR-Umfeld ermöglicht. Für Steuergeräte 5, die sowohl Anwendungsfälle (Hosting von Fahrzeugfunktionen) und Gateway-Funktionalität 3 erfüllen müssen, wird eine leistungsfähige Softwarearchitektur und komplette Softwarelösung vorgeschlagen. Dies wird als hybride Multi-Core (Multi-Kern) Software-Architektur für Automotive-Controller mit integrierter Gateway-Funktionalität 3 bezeichnet.
-
Die hybride Software-Architektur ist in unabhängige Ausführungsinstanzen, nachfolgend als Domänen 16, 18, 20; 40, 42, 44 bezeichnet, aufgeteilt. Diese Domänen 16, 18,20; 40,42, 44 sind voneinander unabhängig ausführbar und zeichnen sich durch unterschiedliche Partitionen, insbesondere Software-Partitionen aus. Die Kommunikation zwischen unterschiedlichen Domänen 16, 18, 20; 40, 42, 44 verläuft entweder über entsprechende Schnittstellen oder beispielsweise über ein bestimmtes Speicherkonzept (Shared-Memory: beispielsweise ein Ringpuffer, auf den die unterschiedlichen Domänen 16, 18,20; 40,42, 44 nach bestimmten Regeln (Schreiben/Lesen; Speicherbereiche etc.) zugreifen dürfen zum Zwecke des Datenaustauschs. In Multi-Core-CPU- Systemen (Mikrocontroller oder Mikroprozessor oder System-on Chip SOC) können diese Domänen je nach Steuergeräte-Systemanforderungen und Design flexibel über einen oder mehrere CPU-Kerne verteilt werden. Ein generischer Datenaustauschmechanismus, als Inter-Domänen-Kommunikation 30, 66 zwischen zumindest der ersten Domäne 40, 42, 44, insbesondere AUTOSAR-Domäne, und der weiteren Domäne 16, 18,20, insbesondere Kommunikationsdomäne, ermöglicht den Datenaustausch zwischen den Domänen 16, 18, 20; 40, 42, 44 und Kernen oder innerhalb der Rechnerkerne.
-
Es wird eine zusätzliche Partitionierung der Software-Architektur in unabhängige Ausführungseinheiten, nachfolgend als sogenannte Domänen 16, 18, 20; 40, 42, 44 bezeichnet, eingeführt. Diese Domänen 16, 18, 20; 40, 42, 44 verfügen über entsprechende Ausführungsfunktionen, die flexibel als zyklische Aufgaben bzw. Tasks oder Interrupts in die Betriebssystemplanung eingebunden werden können, um das erforderliche Steuergeräte-Systemverhalten zu realisieren.
-
Der Teil der AUTOSAR-Architektur wird zumindest einer (ersten) Domäne 40, 42, 44 oder je nach Anwendungsfall auch mehreren (ersten) Domänen 40, 42, 44 zugewiesen, die nachfolgend als erste bzw. AUTOSAR-Domäne 40, 42, 44 bezeichnet wird und die vollständig dem AUTOSAR-Standard entspricht und keine Änderung erfährt. Diese AUTOSAR-Domäne 40, 42, 44 kann als AUTOSAR-Ein- oder Mehr-Kern-Architektur realisiert werden. In den AUTOSAR-Domänen 40, 42, 44 können je nach Anwendungsfall unterschiedliche Anwendungsprogramme 46, beispielhaft dargestellt als Fahrzeugfunktionsprogramme 48.1, 48.2,..., 48.n vorgesehen sein. Weiterhin umfasst die jeweilige AUTOSAR- Domäne 40, 42, 44 eine Basissoftware 52, die beispielsweise einen Router, insbesondere PDU-Router 54 (I-PDU: Interaction layer Protocol Data Unit, eine von AUTOSAR definierte Dateneinheit, nachfolgend auch als PDU (Protocol Data Unit) bzw. Dateneinheit bezeichnet) und/oder Schnittstellen 56 für verwendete Bussysteme (beispielsweise CAN, Flexray, Ethernet etc.) umfassen kann.
-
Unabhängig von der zumindest einen (ersten) AUTOSAR-Domäne 40, 42, 44 ist zumindest eine weitere Domäne 16, 18, 20, vorzugsweise mehrere weitere Domänen 16, 18, 20, vorgesehen. Die weitere Domäne 16, 18, 20 weist eine unabhängige Ausführungsfunktion auf, die das Routing und Handling von Daten betrifft. Besonders bevorzugt wird für jedes Kommunikationsprotokoll (des jeweiligen Kommunikationssystems 11) eine eigene Domäne 16, 18, 20 vorgesehen, beispielsweise eine CAN-Domäne 20, eine Flexray-Domäne 18, eine Ethernet-Domäne 16 etc.. Die weitere Domäne 16, 18, 20 greift auf die jeweilige physikalische Schnittstelle 13 des Kommunikationssystems 11 zu und verarbeitet Nachrichten des jeweiligen Kommunikationssystems 11.
-
Die funktionale Aufteilung zwischen der AUTOSAR-Domäne 40, 42, 44 und der weiteren Domäne 16, 18, 20 insbesondere zum Routen von Daten wird so vorgenommen, dass performancerelevante Anwendungsfälle, die sich durch schnelles Routen bzw. Weiterleiten von Daten auszeichnen, der weiteren Domäne 16, 18, 20 zugeordnet werden. Ein großer Teil der gesamten Datenweiterleitung, die durch das Gateway 3 in Steuergeräten realisiert werden soll, nutzt den sog. PDU- und Container-Routing-Mechanismus. Dieser Routing-Mechanismus wird umfassend auf Anwendungsdaten angewendet, die zwischen Fahrzeugfunktionen auf Steuergeräten 5 ausgetauscht werden, wenn das Fahrzeug fährt (Normalbetrieb). Dieser Anwendungsfall hat eine hohe Anforderung an niedrige Routing-Latenz und wird daher der weiteren bzw. den weiteren Domäne(n) 16, 18, 20 zum Routen bzw. Weiterleiten von Daten zugeordnet. Die Weiterleitung der Daten in der weiteren Domäne 16, 18, 20 erfolgt in Verbindung mit in der Dateneinheit PDU 72 bzw. Container 74, insbesondere durch Informationen im Header 80 und Weiterleitungsinformationen wie beispielsweise in Routing-Tabellen abgelegt. Über den Header 80 bzw. dessen zugehörige Informationen ist eine Identifikation möglich, wie die nachfolgenden Nutzdaten 82 zu interpretieren bzw. weiterzuleiten sind sind.
-
Alle übrigen Anwendungsfälle bzw. Standardfälle wie beispielsweise Diagnoseaufgaben oder Ähnliches, welche sich nicht durch schnelle Datenweiterleitung auszeichnen, werden der AUTOSAR-Domäne 40, 42, 44 zugeordnet. Alle verbleibenden Anwendungsfälle wie lokale Terminierung (Empfang und Übertragung durch gehostete Fahrzeugfunktionen), Transportprotokolle (ISO-TP (International Standards Organization - Transport Protocol), TCP (Transmission Control Protocol), Diagnosekommunikation und Diagnoserouting (UDS (Unified Diagnostic Services), OBD (On-Board Diagnostics), DolP (Diagnostics over Internet Protocol)), Netzwerkmanagement, etc. werden der AUTOSAR-Domäne 40, 42, 44 zugewiesen.
-
Die Domänen 16, 18, 20; 40, 42, 44 in der Hybrid-Software-Architektur können auf einen oder mehrere CPU-Kerne in Multi-Core-CPU-Systemen (Mikrocontroller oder Mikroprozessor oder System-on-Chip (SoC)) abgebildet werden, um die Steuergeräte-Anforderungen und das Design zu erfüllen (z. B. Anzahl der Schnittstellen, Datenverkehr, Latenz- und Durchsatzanforderungen, CPU-Last durch Routing, ...).
-
Die erste bzw. AUTOSAR-Domäne 40, 42, 44 kann als ein- oder mehrkernige Implementierung realisiert werden, wie sie durch den AUTOSAR-Standard definiert ist.
-
Die für Kommunikationsprotokolle spezifischen weiteren Domänen 16, 18, 20 können flexibel auf CPU-Kerne abgebildet werden, um Ein- oder Mehrkernimplementierungen zu realisieren. Jede weitere Domäne 16, 18, 20 kann einem anderen CPU-Kern zugeordnet werden (z. B. CAN-Kern, Ethernet-Kern, ...) oder mehrere oder alle weitere Domänen 16, 18, 20 können einem einzelnen Kern zugeordnet werden (z. B. CAN, Flexray und Ethernet auf einem einzelnen Kern).
-
Der Austausch von Kommunikationsdaten zwischen der AUTOSAR-Domäne 40, 42, 44 und den weiteren Domänen 16, 18, 20 erfolgt über einen generischen Datenaustauschmechanismus, der beispielsweise wie oben beschrieben auf dem Shared-Memory-Konzept basiert und als Inter-Domänen-Kommunikation 30, 66, angesiedelt in den kommunizierenden ersten und weiteren Domänen 16, 18, 20; 40, 42, 44 wie in 4 angedeutet, bezeichnet wird.
-
Inter-Domänen-Kommunikation 30, 66 ist ein funktions- und protokollunabhängiger Datenaustauschmechanismus, der die Übertragung von Datenblöcken von einem Absender auf einen oder mehrere Empfänger ermöglicht.
-
Die Datenblöcke (bspw. Nutzdaten 82 gemäß 5) werden von zusätzlichen Meta-Informationen (bspw. Header 80 gemäß 5) begleitet, nämlich beispielsweise deren Kennung und Länge, die es den Sendern und Empfängern ermöglichen, die ausgetauschten Daten gemeinsam zu interpretieren. Die Zeitplanung des Datenaustauschs kann per Polling oder Interrupt-Schema konfiguriert werden. Die ausgetauschten Daten können zusätzlich durch Sicherheitsmechanismen wie Authentifizierung zur Sicherstellung der Datenintegrität geschützt werden.
-
Werden die Bereiche, zwischen denen Daten ausgetauscht werden, je nach Steuergeräte-Design auf verschiedene Kerne abgebildet, wird derselbe Datenaustauschmechanismus als Inter-Core-Kommunication bezeichnet.
-
Im Rahmen dieser Anwendung sind die Dateneinheiten Frame 70, PDU 72 und Container 74 gemäß 5 relevant. Das Format dieser Dateneinheiten folgt einem TLW-Schema (Typ, Länge, Wert). Der Typ (Identifier, zusätzliche Protokoll-Parameter) und die Länge (der Nutzdaten 82 bzw. payload in Bytes) sind Meta-Informationen, die zusammen als Header 80 bezeichnet werden und den Inhalt des Wertes (Nutzdaten 82 oder Nutzerdaten) angeben.
-
Ein Rahmen bzw. Frame 70 ist die Einheit von Daten, die auf der physikalischen Schnittstelle 13 eines bestimmten Kommunikationsprotokolls übertragen wird und deren exaktes Format durch das Protokoll (CAN, Flexray, Ethernet) definiert wird.
-
Eine PDU 72 entspricht ganz oder teilweise den Nutzdaten 82 des Rahmens bzw. Frames 70, der die Applikationsdaten enthält (aus Signalen mit physikalischer oder funktionaler Relevanz z.B. Fahrzeuggeschwindigkeit, Umgebungstemperatur, Fehlerstatus-Flag, ...). Die PDU 72 hat einen eigenen Header 80 und Payload bzw. Nutzdaten 82.
-
Ein Container 74 für PDU 72 ist ein Kollektor, der verwendet wird, um mehrere enthaltene PDUs 72 zu gruppieren. PDUs 72, die in Frames 70 ohne Container 74 übertragen werden, werden als generische PDUs 72 bezeichnet. Container 74, im Container 74 enthaltene PDUs 72 und generische PDUs 72 haben ihre jeweiligen Header 80 und Payload bzw. Nutzdaten 82. Diese Dateneinheiten haben ggf. eine verschachtelte Struktur, in der Frames 70 aus generischen PDUs 72 bestehen und/oder Container-PDUs 72 und Container-PDUs 72 selbst aus in Containern 74 enthaltenen PDUs 72 bestehen wie beispielhaft in 5 gezeigt.
-
Um den im AUTOSAR-Standard definierten Schnittstellen (APIs: Application Programming Interfaces) zu entsprechen, können Daten zwischen den weiteren Domänen 16, 18, 20 und der AUTOSAR-Domäne 40, 42, 44 auf den Ebenen der Dateneinheit - Frame 70 (vgl. 4 der untere Doppelpfeil zwischen Kommunikationstreiber 24 der weiteren Domaine 16, 18, 20 und den virtuellen Treibern 64 der ersten Domainen 40, 42, 44) und PDU 72 (generisch und im Container 74 enthaltene PDU 72; in 4 angedeutet über den oberen Doppelpfeil zwischen dem PDU-Gateway 28 und dem PDU-Adapter 60, weitergeleitet an den PDU-Router 54 der ersten Domaine 40, 42, 44) ausgetauscht werden.
-
Um den mit der AUTOSAR-Domäne 40, 42, 44 ausgetauschten Dateneinheiten zu entsprechen, dürfen Daten zwischen den weiteren Domänen 16, 18, 20 nur auf der Ebene der Dateneinheit PDU 72 (generisch und/oder im Container 74 enthaltene PDU 72) ausgetauscht werden. Der Datenaustausch zwischen zwei weiteren Domainen 16, 18, 20, die auf unterschiedlichen Kommunikationsprotokollen (CAN, Flexray, Ethernet) basieren, ist auf Frame-Ebene aufgrund des unterschiedlichen Frame-Layouts der jeweiligen Protokolle nicht möglich.
-
Innerhalb der hybriden Softwarearchitektur ist der direkte Zugriff auf physikalische Kommunikationsschnittstellen 13 von CAN-, Flexray- und Ethernet-Protokollen allein auf die jeweilige weitere Domäne 16, 18, 20, die das Routen bzw. Weiterleiten von Daten betreffen, beschränkt. Dieser Ansatz ermöglicht es den weiteren Domänen 16, 18, 20, Nachrichten direkt von den Schnittstellen 13 zu empfangen und innerhalb kurzer Zeit zu trennen. Die Nachrichten werden in der jeweiligen weiteren Domäne 16, 18, 20 zur Weiterverarbeitung aufbewahrt und die restlichen Nachrichten an die AUTOSAR-Domäne 40, 42, 44 weitergeleitet. Die AUTOSAR-Domäne 40, 42, 44 hat somit keinen direkten Zugriff auf die Schnittstellen 13 der jeweiligen Kommunikationssysteme 11, sondern empfängt indirekt für sie relevante Nachrichten über die jeweilige weitere Domäne 16, 18, 20.
-
Die Softwarearchitektur der weiteren Domainen 16, 18, 20, die für die jeweiligen Kommunikationsprotokolle (CAN, Flexray, Ethernet) spezifisch vorgesehen werden, ist ähnlich aufgebaut (siehe 4). Eine Routing-Einrichtung 22 für die jeweilige weitere Domäne 16, 18, 20 besteht jeweils aus einem Kommunikationstreiber 24 zur Anbindung an die jeweilige physikalische Schnittstelle 13 des Kommunikationssystems 11, einen Kommunikationsprotokoll-Stack 26 bzw. Stapelspeicher zur Handhabung der höheren Protokollschichten (bspw. CAN/FR/ETH...) und dem protokoll unabhängigen PDU Gateway 28 zur Weiterleitung von PDUs 72. Für den Datenaustausch mit anderen (weiteren) Domänen 16, 18, 20 bzw. den AUTOSAR-Domänen 40, 42, 44 ist eine Instanz der Inter-Domänen-Kommunikation 30 erforderlich.
-
Die Kommunikationstreiber 24 implementieren den ISO/OSI Layer 2 bezogenen Datenzugriff (Lesen und Schreiben) und Kontrollmechanismen (Mode- und Fehlermanagement), notwendig für die Handhabung der Kommunikationssteuerungen und physikalischen Schnittstellen 13 des jeweiligen Kommunikationsprotokolls (CAN, Flexray FR, Ethernet ETH,...).
-
Der Kommunikationsprotokoll-Stack 26 bzw. Kommunikationsprotokoll-Speicher implementiert nur jene ISO/OSI Layer 3 - 5 Datenzugriffs- und Kontrollmechanismen, die für die Handhabung der routingrelevanten Anwendungsfälle auf den weiteren Domänen 16, 18, 20 notwendig sind. Dieser Bereich umfasst vor allem die Verarbeitung von Nicht-Transport-Protokoll-Nachrichten (Non-ISO-TP, UDP) zum Extrahieren von PDUs 72 für performantes Routing.
-
Das PDU Gateway 28 führt eine performante Weiterleitung von PDUs 72 zwischen verschiedenen Daten-Quellen und -Senken durch, nämlich dem lokalen Kommunikationsprotokoll-Stack 26, dem Kommunikationsprotokoll-Stack 26 auf anderen weiteren Domänen 16, 18, 20 und/oder der AUTOSAR Domäne 40, 42, 44 über die Inter-Domänen-Kommunikation 30. Diese Weiterleitung wird durch konfigurierbare Routing-Anweisungen geregelt, die auch als Routing-Tabelle bezeichnet werden. Die Weiterleitung kann anhand des jeweiligen Headers 80 erfolgen.
-
Um Daten mit anderen weiteren Domänen 16, 18, 20 und der AUTOSAR-Domäne 40,42, 44 auszutauschen, wird in jeder der weiteren Domänen 16, 18, 20 eine Instanz der Inter-Domänen-Kommunikation 30 ausgeführt.
-
AUTOSAR ist eine eigenständige und vollständige Standardarchitektur. Um die proprietäre Routing-Architektur in sie zu integrieren, müssen auf der ersten Domain 40, 42, 44 angesiedelte Softwaremodule 58, 60, 62, 64, die direkt mit beliebigen AUTOSAR-Standardmodulen 52, 54, 56 verbunden sind, eingeführt und in die AUTOSAR-Architekturdefinition des Steuergeräts aufgenommen werden. Der AUTOSAR-Standard bietet die Möglichkeit, komplexe Gerätetreiber 58 (CDD) für eine solche Integrationen zu verwenden.
-
In der AUTOSAR-Standardarchitektur sind Treiber von Kommunikationsschnittstellen (CAN- /Flexray- /Ethernet-Treiber) Teil der Architekturschicht Microcontroller Abstraction Layer (MCAL). Da innerhalb der hybriden Softwarearchitektur der direkte Zugriff auf physikalische Kommunikationsschnittstellen 13 auf die weiteren Domänen 16, 18, 20 beschränkt ist, muss der MCAL auf der AUTOSAR-Domäne 40, 42, 44 über sogenannte virtuelle Kommunikationstreiber bzw. virtuelle Treiber 64 (CDD) für entsprechende Protokolle abgestellt werden. Wie der Name schon sagt, handelt es sich bei den virtuellen Treibern 64 nicht um echte Treiber, sondern um Proxies der realen Treiber und dienen als Standard-AUTOSAR-APIs gegenüber den übergeordneten Schnittstellenmodulen (CAN-/Flexray- /Ethernet-Interface) der sog. Steuergeräte-Abstraktions-Schicht (ECU Abstraction Layer (ECUAL)). Die virtuellen Treiber 64 interagieren und tauschen Frames 50 mit ihren Gegenstücken aus, nämlich mit den realen Kommunikationstreibern 24 auf den jeweiligen weiteren Domänen 16, 18, 20 über die Inter-Domänen Kommunikation 30, 66, die auch auf der AUTOSAR Domäne 40, 42, 44 als Pendant angesiedelt ist.
-
In der AUTOSAR-Standardarchitektur ist ein PDU Router 54 das Softwaremodul, in dem PDUs 72 zwischen verschiedenen Softwaremodulen der unteren und oberen Schicht weitergeleitet werden. Um PDUs 72 zwischen AUTOSAR-Domänen 40, 42, 44 und den weiteren Domänen 16, 18, 20 austauschen zu können, wird der als PDU-Adapter 60 bezeichnete Treiber CDD (AUTOSAR Complex Device Driver) als Lower-Level-Modul des AUTOSAR PDU Routers 54 in die Architektur aufgenommen. Der PDU-Adapter 60 interagiert und tauscht PDUs 72 mit dem PDU-Gateway 28 der jeweiligen weiteren Domäne 16, 18, 20 über die Inter-Domänen-Kommunikation 30, 66 aus. Dies erfolgt durch die erwähnte Shared-Memory-Architektur, also ein gemeinsamer Speicher wie beispielswiese ein Ringspeicher.
-
Eine Instanz der Inter-Domänen-Kommunikation 66 wird in der AUTOSAR-Domäne 40,42, 44 ausgeführt, um den Datenaustausch mit Gegenstücken auf den weiteren Domänen 16, 18, 20 zu ermöglichen. Der Empfang und die Übertragung von Frames 70 und PDUs 72 in der AUTOSAR Domäne 40, 42, 44 wird durch Weiterleitung dieser Dateneinheiten von bzw. zu den virtuellen Kommunikationstreibern 64 (auf Frame-Ebene) bzw. PDU Adapter 60 (auf PDU-Ebene) ermöglicht. Im Gegensatz zu den virtuellen Kommunikationstreibern 64 und dem PDU-Adapter 60 darf die Inter-Domänen-Kommunikation 66 jedoch nicht in die AUTOSAR-Architekturdefinition aufgenommen werden, da sie nicht direkt mit Standard-AUTOSAR-Modulen 52, 54, 56 verbunden ist.
-
Zur Adressierung des Hostings der Fahrzeugfunktionen und Gateway-Anwendungsfälle 5 werden Daten aus beiden Datenquellen, nämlich physische Kommunikationsschnittstellen 13 und Anwendungssoftware-Komponenten, in der hybriden Softwarearchitektur entlang verschiedener Datenpfade weitergeleitet und verarbeitet wie aus 6 ersichtlich.
-
Eine Weiterleitungsentscheidung 90 für empfangene Rahmen bzw. Frames 70 ist jeweils in den weiteren Domänen 16, 18, 20 bzw. zugehörigen Kommunikationstreibern 24 angesiedelt, um Frames 70, die direkt von den jeweiligen Schnittstellen 13 (CAN, Flexray, Ethernet) empfangen werden, weiterzuverarbeiten. Die weitere Domäne 16, 18, 20 weist eine unabhängige Ausführungsfunktion auf, die das Routing von Daten betrifft. Gemäß der konfigurierbaren Weiterleitungsentscheidung 90 unter Auswertung des Headers 80 für Frames 70 innerhalb des Kommunikationstreibers 24 werden die (in Schritt 88) empfangenen Frames 70 an eines der folgenden Ziele weitergeleitet:
- - Nur für AUTOSAR Domänen 40, 42, 44: Frames 70, die nur in der AUTOSAR Domäne 40,42, 44 weiterverarbeitet werden sollen, werden nur über den jeweiligen virtuellen Treiber 64 (CDD) an das AUTOSAR (CAN/Flexray/Ethernet) Schnittstellenmodul 56 weitergeleitet.
- - Nur für die weiteren Domänen 16, 18, 20: Frames 70 mit applikationsrelevanten PDUs 72, die extrahiert und weiterverarbeitet werden sollen, werden im Software-Stack 26 bzw. Kommunikations-Protokoll Stack 26 innerhalb der weiteren Domäne 16, 18, 20 (Kommunikations-Protokoll Stack 26 und PDU Gateway 28) nur nach oben (an die jeweilige weitere Domaine 16, 18, 20) weitergeleitet.
- - Sowohl für AUTOSAR-Domänen 40, 42, 44 wie auch für weitere Domänen 16, 18, 20: Für bestimmte Sonderfälle werden Frames 70 sowohl an AUTOSAR Domänen 40, 42, 44 als auch nach oben im Software-Stack bzw. Kommunikations-Protokoll Stack 26 der weiteren Domänen 16, 18, 20 weitergeleitet.
-
Die Weiterleitungsentscheidung 90 für empfangene Rahmen bzw. Frames 70 lässt sich wie folgt zusammenfassen:
- - Nur für AUTOSAR-Domänen 40, 42, 44
- ◯ Diagnostische Kommunikation
CAN / FR: UDS (Unified Diagnostic Services) auf ISO-TP (International Standards Organization - Transport Protocol)
ETH (Ethernet): UDS auf DolP (Diagnostics over Internet Protocol)
(UDP, TCP (Transmission Control Protocol))
- ◯ Diagnostische Weiterleitung
CAN / FR: Nachrichtenrouting von ISO-TP-Nachrichten
ETH: DolP Routing nicht-diagnostischer TCP-Kanäle
- ◯ nicht-diagnostische TCP Kanäle
relevant für CAN, FR, ETH:
- ◯ Zeitsynchronisierung, Netzwerkmanagement, Messung & Kalibrierung
(XCP)
- - nur für die weiteren Domänen 16, 18, 20
- ◯ Rahmen 70 mit PDUs 72 für PDU- und Container-Routing oder / und Empfang durch eine Anwendung
- - Für AUTOSAR Domänen 40, 42, 44 sowie für die weiteren Domänen 16, 18, 20 relevant
- ◯ Nur für die ETH relevant:
- Adress Resolution Protocol (ARP)
- SOME/IP Service Discovery (SD)
-
Weiterleitungsentscheidung 92 für empfangene PDUs 72
-
Die vom Kommunikationstreiber 24 nach oben im Software-Stack 26 weitergeleiteten Frames 70 werden weiterverarbeitet, um entweder generische PDUs 72 und/oder Container-PDUs 72 zu extrahieren, die die atomaren enthaltenen PDUs 72 enthalten.
-
Generische PDUs 72 oder (in Containern 74) enthaltene PDUs 72 werden gemäß der konfigurierbaren PDU-Weiterleitungsentscheidung 92 innerhalb des PDU-Gateways 28 an eines der folgenden Ziele weitergeleitet:
- - Nur AUTOSAR-Domänen 40, 42, 44: PDUs 72, die nur für den Emfang von Anwendungen 46, 48 relevant sind, die in der AUTOSAR-Domäne 40, 42, 44 gehostet werden, werden nur über den PDU-Adapter 60 an den AUTOSAR PDU-Router 54 weitergeleitet.
- - Nur für die weiteren Domänen 16, 18, 20 relevant: PDUs 72, die nur für PDU- und Container-Routing relevant sind, werden weitergeleitet:
- - wenn die Zielschnittstelle 13 in der gleichen weiteren Domäne 16, 18, 20 liegt, zurück nach unten im Kommunikations-Protokoll Stack 26 der Routing-Einrichtung 22 und Kommunikationstreiber 24 zur Übertragung.
- - wenn sich die Zielschnittstelle 13 in einer anderen weiteren Domäne 16, 18, 20 befindet, an das PDU-Gateway 28 der jeweiligen weiteren Domäne 16, 18, 20 zur Übertragung.
- - Für sowohl AUTOSAR Domänen 40, 42, 44 wie auch weitere Domänen 16, 18, 20:
- -PDUs 72, die sowohl für den Empfang durch Anwendungen 46, 48 als auch für PDU- und Container-Routing relevant sind, werden sowohl an die AUTOSAR Domäne 40, 42, 44 als auch an die Ziel-Domäne der weiteren Domäne 16, 18, 20 weitergeleitet.
-
Kombination der Übertragung von PDUs 72 und Frames 70 von AUTOSAR-Domänen 40, 42, 44 und weiteren Domänen 16, 18, 20:
- Da nur die weiteren Domänen 16, 18, 20 direkten Zugriff auf physikalische Schnittstellen 13 haben, müssen Übertragungsdaten von AUTOSAR-Domänen 40, 42, 44 und weiteren Domänen 16, 18, 20 kombiniert und auf der weiteren Domäne 16, 18, 20 der zugehörigen Zielschnittstelle 13 (CAN / Flexray / Ethernet) übertragen werden.
-
PDUs 72 von Anwendungsprogrammen 46, 48 in der AUTOSAR
- -Domäne 40, 42, 44, von anderen weiteren Domänen 16, 18, 20 und/oder von der lokalen weiteren Domäne 16, 18, 20 werden in dem PDU Gateway 28 der lokalen weiteren Domäne 16, 18, 20 kombiniert, um die Nutzdaten 82 des Ziel-Frames 70 zu konstruieren.
-
Frames 70 aus der Basissoftware 52 in der AUTOSAR-Domäne 40, 42, 44 und der lokalen weiteren Domäne 16, 18, 20 werden vom Kommunikationstreiber 24 auf der lokalen weiteren Domäne 16, 18, 20 an die Zielschnittstelle 13 übertragen.
-
Datenpfade für verschiedene Anwendungsfälle
-
Basierend auf dem jeweiligen Anwendungsfall ist eine bestimmte Teilmenge der Verarbeitung, Weiterleitungsentscheidung und Datenpfaden in der hybriden Softwarearchitektur relevant. Die Datenpfade für verschiedene Anwendungsfälle werden in den folgenden Abschnitten in Verbindung mit den 6-12 erläutert.
-
PDU- und Container-Routing innerhalb einer der weiteren Domänen 16, 18, 20 ist in 7 gezeigt. Für diesen Anwendungsfall werden die auf einer der weiteren Domäne 16, 18, 20 empfangenen PDUs 72 und/oder Container 74 (enthalten in in Schritt 88 empfangenen Frames 70) an die Zielschnittstelle 13 (Übertragung eines entsprechenden Frames 70 gemäß Schritt 106) derselben weiteren Domäne 16, 18, 20 (z. B. CAN zu CAN-Routing) übertragen. Somit geht der Datenpfad (Schritte 91, 92, 93, 110, 120) im Software-Stack 26 innerhalb einer einzigen der weiteren Domänen 16, 18, 20 auf und ab, ohne Datenaustausch mit AUTOSAR-Domänen 40, 42, 44 und anderen weiteren Domänen 16, 18, 20.
-
PDU- und Container-Routing zwischen den weiteren Domänen 40, 42, 44 ist in 8 (Empfangsteil) bzw. 9 (Übertragungsteil) gezeigt. Für diesen Anwendungsfall (Schritte 88, 90, 91, 92, 94 (8); Schritte 108, 110, 120, 104, 106 (9)) werden die auf der Quell-Domäne 16, 18, 20 empfangenen PDUs 72 und/oder Container 74 zunächst auf die Ziel-Domäne 16, 18, 20 übertragen (Empfang der entsprechenden Frames 70 in Schritt 88, Weiterleitungsentscheidung 90 zur Weiterleitung an das PDU Gateway 28 bzw. die dortige Weiterleitungsentscheidung 92 bei Empfang einer PDU 72, Weiterleitung an die entsprechende weitere Ziel-Domäne 16, 18, 20 in Schritt 94, in der weiteren Ziel-Domäne 16, 18, 20 wird in Schritt 108 die PDU 72 von der anderen weiteren Domäne 16, 18, 20 empfangen, in Schritt 110 erfolgt eine kombinierte Übertragung der PDU 72 an den Kommunikationstreiber 24 der Ziel-Domäne 16, 18, 20 (Schritt 120), wobei der Kommunikationstreiber 24 eine Übertragung der PDU 72 im zugehörigen Frame 70 vornimmt (Schritt 104) und anschließend an die zugehörige Schnittstelle 13 überträgt (Schritt 106) auf die Ziel-Schnittstelle 13 der Ziel-Domäne 16, 18, 20.
-
Der Empfang und die Übertragung von Frames 70 und PDUs 72 durch eine AUTOSAR-Domäne 40, 42, 44 ist in 10 gezeigt. Für diesen Anwendungsfall wird der auf einer der weiteren Domäne 16, 18, 20 empfangene (Schritt 88), für die AUTOSAR-Domäne 40, 42, 44 relevante Frame 70 (als solches in der Weiterleitungsentscheidung 90 bspw. über den Header 80 und der Routing-Tabelle ermittelt) von dem Kommunikationstreiber 24 der weiteren Domäne 16, 18, 20 an den virtuellen Treiber 64 der AUTOSAR-Domäne 40, 42, 44 (in Schritt 96) übertragen. Ebenso werden die von der AUTOSAR-Domäne 40, 42, 44 zu übertragenden Frames 70 zunächst in die Ziel-Domäne der weiteren Domäne 16, 18, 20 und dann an die Ziel-Schnittstelle 13 übertragen. Hierzu überträgt die entsprechende virtuelle Schnittstelle 56 in Schritt 100 die jeweiligen Frames 70 an den virtuellen Treiber 64. Der noch in der AUTOSAR Domäne 40, 42, 44 angesiedelte virtuelle Treiber 64 überträgt den jeweiligen Frame 70 in Schritt 102 an den Kommunikationstreiber 24 der zugehörigen Ziel-Domäne 16, 18, 20 und gelangt dann über Schritt 104 an die zugehörige Schnittstelle 13 (vergleiche Schritt 106).
-
Für den Anwendungsfall Empfang und Übertragung von PDUs 72 per AUTOSAR Domänen 40, 42, 44 (11) werden generische PDUs 72 oder enthaltene PDUs 72, die aus Frames 70 extrahiert werden, und entsprechende Container 74, die auf einer der weiteren Domänen 16, 18, 20 empfangen werden, die für AUTOSAR-Domänen 40, 42, 44 relevant sind, in die AUTOSAR-Domäne 40, 42, 44 übertragen. Die in Schritt 88 empfangenen Frames 70 werden in der Weiterleitungsentscheidung 90 auf Relevanz bzw. Routing überprüft und in Schritt 91 an die Weiterleitungsentscheidung 92 der PDUs 72 für die AUTOSAR-Domäne 40, 42, 44 übermittelt. In Schritt 112 erfolgt die Übertragung an die AUTOSAR-Domäne 40, 42, 44 über den PDU Adapter 60 (über Schritt 112) und den PDU Router 54 (Schritt 114). In einer Übertragung der PDU von der AUTOSAR Domäne 40, 42, 44 erfolgt dies in Schritt 116 vom PDU Router 54 an den PDU Adapter 60 und in Schritt 118 an das PDU Gateway 28. In Schritt 110 erfolgt die Übertragung und damit gelangen die zu übertragenden PDUs 72 in Schritt 120 an den Kommunikationstreiber 24, wobei in Schritt 104 eine Umsetzung in den zugehörigen Frame 70 der jeweiligen weiteren Domäne 16, 18, 20 und anschließender Übertragung (Schritt 106) an die jeweilige Schnittstelle 13 erfolgt.
-
Eine Kombination von Anwendungsfällen ist in 12 gezeigt. Zusätzlich zu den drei oben genannten Anwendungsfällen (Weiterleitungsentscheidung für Frames 70, Weiterleitungsentscheidung für PDUs 72, kombinierte Übertragung PDUs 72 und Frames 70 von AUTOSAR Domänen 40, 42, 44 und von weiteren Domänen 16, 18, 20) ist eine Kombination dieser Anwendungsfälle möglich. Ein Beispiel für einen solchen Anwendungsfall ist eine Kombination aus Empfang von PDU 72 durch eine Anwendung 46, 48 und ein PDU-Routing innerhalb der lokalen weiteren Domäne 16, 18, 20. In diesem Fall wird die empfangene PDU 72 über die PDU Weiterleitungsentscheidung 92 an die AUTOSAR-Domäne 40, 42, 44 (über Übertragungspfade 112,140 mit PDU Adapter 60) und über den Übertragungspfad 93, 110, 120, 104 im Software-Stack 26 derselben weiteren Domäne 16, 18, 20 aufgeteilt. Weitere solcher Kombinationen von Anwendungsfällen werden von der hybriden Softwarearchitektur unterstützt.
-
Eine Offboard-Toolchain für die Integration der weiteren Domänen 16, 18, 20 für das Daten-Routing ist in 13 gezeigt. Die Implementierung der hybriden Softwarearchitektur in Embedded Software muss durch die Anpassung der sog. Offboard-Toolchain bzw. Entwicklungsumgebung und des Workflows zur Generierung der Steuergerätekonfiguration und entsprechend eines ECU Flash Containers 146 ergänzt werden. Die hybride Softwarearchitektur teilt den kompletten Umfang der Steuergeräte-Funktionalität im Wesentlichen in AUTOSAR-Domänen-Teile und weitere Domänen-Teile auf. Daher wird die Toolchain angepasst (siehe 13), um die AUTOSAR-Domänen- und die weitere Domänen-spezifischen Konfigurationen aus der kompletten Steuergerätekonfiguration abzuleiten.
-
Durch die in dem Werkzeug 132 zur Erzeugung von Konfigurationsdaten 140, 142 für die weitere Domäne 16, 18, 20 enthaltene Konfigurations-Aufteilung 134 wird die im sog. kompletten AUTOSAR Steuergeräte-Extrakt 130 der Systembeschreibung (*.arxml) definierte AUTOSAR-Steuergerätekonfiguration in eine Daten-Routing-spezifische Konfiguration (wie sie für die weiteren Domänen 16, 18, 20 benötigt wird) aufgeteilt, die in einem zwischengeschalteten Datenmodell 136 (der weiteren Domäne 16, 18, 20) und einer AUTOSAR-spezifischen Konfiguration gespeichert ist, die ein reduziertes AUTOSAR-Steuergeräte-Extrakt 150 ist. Der Inhalt des reduzierten AUTOSAR-Steuergeräte-Extrakts 150 ist also der des vollständigen AUTOSAR Steuergeräte-Extrakts 130, reduziert um den dem Datenmodell 136 der weiteren Domänen 16, 18, 20 zum Daten-Routing zugewiesenen Teil. Der Daten-Routing Konfigurations-Code (*.c, *.h) wird aus dem Daten-Routing Datenmodell 136 generiert.
-
Das Werkzeug 132 zur Erzeugung von Konfigurationsdaten für die weitere Domäne 16, 18, 20 ist am Einstiegspunkt der Softwareentwicklungs-Toolchain und des Workflows integriert. Das komplette AUTOSAR-Steuergeräte-Extrakt 130 beispielsweise des Fahrzeugherstellers wird in das Werkzeug 132 eingegeben, um den Konfigurationscode 140 und den reduzierten AUTOSAR-Steuergeräte-Extrakt 150 abzuleiten. Dieser reduzierte AUTOSAR-Steuergeräte-Extrakt 150, obwohl im Umfang reduziert, ist konsistent und kann daher in jedem AUTOSAR Konfigurations-Tool und Code Generator 152 eingegeben werden, um einen AUTOSAR-Konfigurationscode 154 zu generieren. Sowohl statische Codes 142 (*.c, *.h) der Routing-Einheit 22 (der weiteren Domänen 16, 18,20) wie auch statische AUTOSAR-Codes 156 (*.c, *.h) wie auch die Konfigurationscodes 140 der Routing-Einheit 22 sowie die AUTOSAR-Konfigurationscodes 154 werden einem Compiler bzw. Linker 144 zugeführt, der diese kompiliert und verknüpft, um einen kompletten Steuergeräte-SW Flash Container 146 zu generieren, über den ein Software-Update in das Steuergerät 5 geflasht werden kann.
-
Das Datenmodell 136 der Routing-Einheit der weiteren Domänen 16, 18, 20 ist ein kompaktes steuergeräte-zentriertes Objektmodell, dessen Inhalt aus dem komplexen und redundanten fahrzeugzentrierten AUTOSAR-Datenmodell abgeleitet wird. Die Routing-Einheit-spezifische Konfiguration wird zwischengespeichert im Werkzeug 132 im Format des Datenmodells 136 der Routing-Einheit der weiteren Domänen 16, 18, 20, bevor der Konfigurationscode 140 generiert wird. Dieses Format ermöglicht eine einfachere Visualisierung und Analyse von Datenfluss und Kommunikationsbeziehungen des Gateways 3.
-
Das Datenmodell 136 (siehe 14) stellt den Datenfluss im Gateway 3 in Form eines gerichteten azyklischen Graphen (DAG) dar, der aus Eckpunkten (Knoten) besteht, die mit unidirektionalen Kanten (Pfeilen) verbunden sind. Die Endpunkt-Eckpunkte repräsentieren Quellen 200 und Senken 240 von Daten (Kommunikationscontroller 202 (Empfang z.B. CAN), 242 (Übertragen z.B. CAN); 214 (Empfang z.B. FR (Flexray), 258 (Übertragen z.B. FR), 210 (Empfang z.B. ETH Socket), 246 (Übertragung z.B. ETH Socket), AUTOSAR-Basissoftware 220, AUTOSAR-Softwarekomponente 230). Die Zwischeneckpunkte repräsentieren Verarbeitungsschritte im Gateway (Empfangen (204 (Empfang CAN-Frame), 207 (Empfang CAN Container PDU), 209 (Empfang CAN generische PDU), 212 (Empfang ETH generische / enthaltene PDU), 216 (Empfang FR Frame), 223 (Empfang FR Container, PDU), 226 (Empfang generische PDU)) Entpacken (208 (CAN Entpacken PDU), 224 (FR Entpacken PDU)) insb. von PDU s bei CAN, FR, Weiterleiten, Verpacken (233 (CAN Verpackung PDU), 250 (FR Verpackung PDU)), Senden (223 (CAN enthaltene PDU senden, 248 (FR enthaltene PDU senden), 235 (CAN Conainer PDU senden), 252 (FR Container PDU senden), 253 (FR generische PDU senden), 256 (FR Frame senden), 260 (AUTOSAR CAN Frame senden), 262 (AUTOSAR FR Frame senden), 270 (CAN Frame senden)) und die miteinander verbundenen Kanten repräsentieren Kommunikationsdateneinheiten (Frames 70, PDU 72, generische PDU 72) einschließlich ihrer Wechselbeziehungen (PDU 72 eines Frames 70) und ihrer zeitlichen Reihenfolge der Verarbeitung. Diese Eckpunkte und Kanten haben zusätzlich Eigenschaften, die sie genauer beschreiben.
-
Die vorgeschlagene Hybrid-Multicore-Softwarearchitektur für Automotive-Steuerungen mit integrierter Gateway-Funktionalität bietet eine optimale Lösung für die angesprochene Problemstellung. Es kombiniert die Vorteile der AUTOSAR Standard Software- Architektur mit einer proprietären Routing-Einheit Software-Architektur, um die Anwendungsfälle des Hostings von Fahrzeugfunktionen bzw. Gateway-Funktionalitäten (performante Datenweiterleitung) zu lösen. Neben der Beschreibung der erforderlichen Anpassung an die Embedded Software ist auch die erforderliche Erweiterung und Integration des Werkzeugs 132 beschrieben.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
