Erfahren Sie in einem Artikel mehr über die Softwarearchitektur des intelligenten Domänencontrollers

Intelligentes Fahren erfordert die Zusammenarbeit von Menschen aus vielen verschiedenen Fachrichtungen, und nicht jeder hat einen Software- oder Automobilsoftware-Hintergrund. Um es Menschen mit unterschiedlichem Hintergrund zu ermöglichen, den Inhalt des Artikels einigermaßen zu verstehen, wird in diesem Artikel versucht, ihn in einer sehr populären Sprache zu beschreiben und mit verschiedenen Bildern zu veranschaulichen. Dieser Artikel vermeidet die Verwendung mehrdeutiger Terminologie und alle Begriffe erhalten bei ihrem ersten Erscheinen ihre genaue Definition.

Die Bedeutung der Softwarearchitektur für intelligentes Fahren

Vereinfachtes konzeptionelles Modell des intelligenten Fahrens

Das konzeptionelle Modell des intelligenten Fahrens besteht einfach darin, drei Kernprobleme zu lösen:

1. Wo bin ich?

2. Wohin gehe ich?

3. Wie komme ich dorthin?

Die erste Frage „Wo bin ich?“ Was gelöst werden muss, ist das Problem der „Umgebungswahrnehmung“ und „Positionierung“. Was verstanden werden muss, ist die Position des Autos selbst und die statische Umgebung um die Position herum (Straßen, Verkehrszeichen, Ampeln) usw.) und dynamische Umgebung (Autos, Menschen usw.). Dies hat eine Reihe technischer Lösungen zur Erfassung und Positionierung ausgelöst, darunter verschiedene Sensoren und Algorithmensysteme.

Die zweite Frage „Wohin gehe ich?“ Im Bereich des autonomen Fahrens geht es um „Planungsentscheidungen“. Daraus leiten sich einige Begriffe wie „globale Planung“, „lokale Planung“, „Aufgabenplanung“, „Wegplanung“, „Verhaltensplanung“, „Verhaltensentscheidung“ usw. ab Aufgrund der sprachlichen Mehrdeutigkeit sind einige dieser Begriffe unterschiedliche Arten, dieselbe Bedeutung auszudrücken, wobei einige von ihnen bei unterschiedlichen Gelegenheiten oft ähnliche, aber leicht unterschiedliche Bedeutungen haben.

Abgesehen von der spezifischen Terminologie wird das Problem der „Planungsentscheidung“ im Allgemeinen in drei Teile zerlegt:

1 Planung im globalen Sinne innerhalb eines bestimmten Bereichs (allgemeine Begriffe: globale Planung, Pfadplanung, Aufgabenplanung)

2. Teilen Sie die Ergebnisse des ersten Schritts in mehrere Phasen auf (allgemeine Begriffe: Verhaltensplanung, Verhaltensentscheidung)

3 Führen Sie für jede Phase eine weitere Planung durch Begriffe: lokale Planung, Bewegungsplanung)

Für diese verschiedenen Planungen werden viele Algorithmensysteme zur Lösung von Problemen abgeleitet.

Die dritte Frage „Wie soll ich vorgehen?“ bezieht sich im Allgemeinen auf die „Kontrolle der Ausführung“, also auf die tatsächliche Umsetzung des kleinsten Plans, um den Zweck des Plans zu erreichen. Speziell im Auto spiegelt es sich häufig in verschiedenen Steuerungsalgorithmen wider, und die Steuerungstheorie löst diese Probleme.

Da die Lösungen dieser drei Probleme letztlich allesamt algorithmische Probleme sind, ist der Algorithmus gewissermaßen der Kern des autonomen Fahrens. In gewissem Sinne muss die Softwarearchitektur in der Lage sein, diese Algorithmen zu unterstützen. Ohne ein gutes Tragesystem ist der Algorithmus nutzlos, egal wie gut er ist.

Fraktale rekursive Eigenschaften des grundlegenden konzeptionellen Modells

Der Einfachheit halber stellen wir die drei Probleme des grundlegenden konzeptionellen Modells als E, P und dar. Jeder Satz von E-P-X hat seinen beschreibenden Problemraum.

Wenn wir beispielsweise Problemraum A als „Fahrt von Peking nach Guangzhou“ definieren, dann kann sich die Positionierung von Problem E auf den aktuellen Bezirk in Peking konzentrieren und es besteht keine Notwendigkeit, ihn auf Straßen zu verfeinern. Wir müssen uns auch darum kümmern, ob es Gewitter gibt, und Informationen zur Straßenstruktur über Provinzautobahnen. Zu Frage P:

P-1: Der erste Schritt besteht darin, einen globalen Weg zu entwerfen, welche Autobahn, Nationalstraße oder Provinzstraße genommen werden soll.

P-2: Planen Sie eine Reihe von Verhaltenskomponenten basierend auf dem globaler Pfad, zu welcher Autobahnkreuzung Sie zuerst fahren müssen, wie viele Kilometer Sie fahren müssen, zur Tankstelle gehen, um zu tanken, auf eine andere Straße zu wechseln usw.

P-3: Planen Sie den spezifischen Straßenweg für jeden Abschnitt. Wenn Sie beispielsweise über die dritte Ringstraße oder die vierte Ringstraße zu einer Autobahnkreuzung fahren möchten, in welche Richtung müssen Sie wechseln?

X muss jeden von P geplanten Schritt ausführen.

Wenn wir den Problembereich B als „Sicheres Fahren durch eine Kreuzung“ definieren, sollten wir für Problem E auf die aktuellen Straßeninformationen, Ampelinformationen, Fahrzeugbedingungen auf der Straße, Fußgängerbedingungen usw. achten. Für P-Problem:

P-1: Der erste Schritt besteht darin, einen sicheren Weg durch die Kreuzung zu planen, einschließlich der Spur, auf der die aktuelle Kreuzung erreicht werden soll, und der Spur, auf der die Zielkreuzung gemäß den Verkehrsregeln und Straßeninformationen betreten werden soll.

P-2: Der zweite Schritt besteht darin, eine Reihe von Aktionssequenzen zu planen, die auf den Grundergebnissen des ersten Schritts basieren, z. B. zuerst langsamer werden, die Zielspur wechseln, anhalten und auf die rote Ampel warten und anfahren beschleunigen und die Kreuzung passieren.

P-3: Der dritte Schritt besteht darin, im zweiten Schritt für jede Aktion eine bestimmte Flugbahn zu entwerfen. Die Flugbahn muss Hindernissen wie Fußgängern und Fahrzeugen ausweichen können.

X ist für die Ausführung der Ausgabe von Problem P verantwortlich.

Dieser Problemraum B kommt dem durch übliche Planungsalgorithmen zu lösenden Problem am nächsten. Der erste Schritt von P-1 wird oft als „globale Planung“ oder „Aufgabenplanung“ bezeichnet, P-2 wird oft als „Verhaltensplanung“ oder „Verhaltensentscheidungsfindung“ bezeichnet und P-3 wird als „lokale Planung“ oder „ Verhaltensplanung“. Bewegungsplan“. Wie in der folgenden Abbildung dargestellt, bildet E-P-X ein abstraktes grundlegendes konzeptionelles Modell, und die Problemräume A und B sind seine spezifischen Implementierungen in einem bestimmten Umfang.

Abbildung 1 Zwei EPX-Problemräume

A und B haben ähnliche E-P-X-Strukturen, aber die Spannen der Probleme, die sie lösen, sind zeitlich und räumlich sehr unterschiedlich. Im Bild oben ist die Aufgabe, die A: Tatsächlich ist das E-P-X-Modell, wie in der folgenden Abbildung dargestellt, eine fraktale rekursive Struktur.

Abbildung 2: Fraktale rekursive Struktur von EPX

„Fraktal“ wird auch „selbstähnliches Fraktal“ genannt. Sein weit verbreitetes Verständnis besagt, dass die Teile von Dingen ähnliche Strukturen wie das Ganze haben, was Symmetrie auf verschiedenen Maßstäben darstellt, wie etwa ein Ast eines Baumes und das Ganze Baum Sie haben eine ähnliche Struktur, und außerdem haben auch die Stammadern jedes Blattes eine ähnliche Struktur. Die folgende Abbildung listet einige typische fraktale Strukturen auf.

Abbildung 3 Fraktalbeispiel

Diese 6 Grafiken haben eine Funktion: Jeder Teil jeder Grafik hat die gleiche Struktur wie die gesamte Grafik. Wenn Sie den lokalen Bereich weiter vergrößern, werden Sie feststellen, dass der lokale Bereich die gleiche Struktur aufweist. Wenn wir also über eine Geschäftsverarbeitungslogik verfügen, die auf das Ganze angewendet werden kann, kann diese auch auf Teile angewendet werden. Genau wie bei der Kultivierung mancher Bäume kann man einen Zweig nehmen und ihn pflanzen, und daraus wächst ein neuer Baum heran. Der einem Softwareprogramm zugeordnete Ausdruck ist „Rekursion“. Dies bedeutet nicht die Verwendung rekursiver Funktionen, sondern eine Rekursion auf Architekturebene.

Der akademischere Ausdruck von „Fraktal“ ist „die Verwendung einer Bruchdimensionsperspektive und mathematischer Methoden zur Beschreibung und Untersuchung objektiver Dinge, wobei man über die traditionellen Barrieren eindimensionaler Linien, zweidimensionaler Oberflächen und dreidimensional hinausspringt.“ Festkörper und sogar vierdimensionale Raumzeit kommen der Beschreibung der realen Eigenschaften und des Status komplexer Systeme näher und entsprechen eher der Vielfalt und Komplexität objektiver Dinge. Wenn wir einen geeigneten mathematischen Ausdruck für „physische Realität“ finden und ihn dann in „Programmrealität“ umwandeln, können wir eine präzisere, klarere und genauere Softwarearchitektur und Implementierungsmethode finden.

Softwarearchitektur löst die Abbildung von „physischer Realität“ auf „Programmrealität“

E-P-X ist eine abstrahierte Struktur, die auf der „physischen Realität“ basiert. Und die meisten davon sind verschiedene Arten algorithmischer Arbeit. Die Forschung und Entwicklung der einzelnen Algorithmen selbst kann auf Basis vordefinierter Ein- und Ausgabebedingungen unabhängig durchgeführt werden. Aber wie kombiniert man die Algorithmen, löst sie zum richtigen Zeitpunkt richtig aus und nutzt die Ergebnisse sinnvoll, um schließlich eine Funktion mit praktischem Nutzen zu bilden? Der Kern dieser Brücke von der „physischen Realität“ zur „Programmrealität“ ist die Softwarearchitektur.

Das autonome Fahrsystem reicht von Level 1 bis Level 5. Je höher, desto tiefer ist das oben erwähnte E-P-X-Modell verschachtelt. Softwarearchitektur wird schwieriger. Die meisten einzelnen Level1- und Level2-Funktionen erfordern nur eine Schicht des E-P-X-Modells. Nehmen Sie als Beispiel AEB (automatische Notbremsung):

E-Teil (Wahrnehmung): hauptsächlich statische Erkennung und Klassifizierung vorausliegender Ziele (Autos, Personen), dynamische Verfolgung sowie Erkennung von Abstand und Geschwindigkeit.

P-Teil: Da AEB nur die Längssteuerung durchführt, kann alles durch Geschwindigkeitssteuerung realisiert werden. Planen Sie also einfach die Geschwindigkeit über einen bestimmten Zeitraum ein.

X Teil: Geschwindigkeitsplanung an das Fahrzeugsteuergerät übergeben.

Das bedeutet nicht, dass die AEB-Funktion mit nur einer EPX-Schicht einfach ist. Tatsächlich ist es sehr schwierig, AEB-Funktionen zu implementieren, die in Massen produziert werden können. Der EPX der ersten Ebene muss jedoch nicht auf der Grundlage von Szenarien geplant werden. Er muss sich nur auf die Implementierung von EPX in einem einzelnen Szenario konzentrieren und ist relativ einfach. In Kapitel 2 wird die gemeinsame Softwarearchitektur von L2-Funktionen vorgestellt.

Was ist szenenbasierte Planung?

Selbst in der EPX-Schleife auf der kleinsten Granularitätsebene kann keine EXP-Implementierung alle Probleme auf dieser Ebene lösen.

Zum Beispiel: Für einen einfachen Anwendungsfall beim Geradeausfahren können wir die End-X-Einheit als Fahrzeugsteuerungsalgorithmus implementieren, der alle Szenarien auf ebenen Straßen sowie bergauf und bergab bewältigen kann. Sie können auch eine Planungseinheit (S) verwenden, um flache Straßen, Steigungen und Gefälle als unterschiedliche Szenarien basierend auf den Informationen der E-Einheit zu identifizieren und zu verschiedenen EXP-Zyklen der nächsten Ebene zu wechseln. Jede EXP-Schleife der nächsten Ebene implementiert eine einzelne Szene. Selbst wenn ein X-Einheiten-Steuerungsalgorithmus zur Lösung aller Ebenen-, Bergauf- und Bergab-Szenarien verwendet wird, unterscheidet der Algorithmus diese Szenarien intern. Tatsächlich handelt es sich immer noch um eine kleinkörnige EXP-Schleife.

Abbildung 4 EPX-Planung

Wie in Abbildung 4 gezeigt, kann die Szenenplanung (S) auf jeder Ebene erfolgen, was bedeutet, dass die Definition von „Szenario“ ebenfalls eine granulare Aufteilung ist. Daher sollte das EPX-Modell das EPX-S-Modell sein. Es gibt einfach keinen offensichtlichen S-Abschnitt unterhalb von L2.

Wie die Softwarearchitektur mit L1 bis L3+ kompatibel ist

Die automatische Parkassistenzfunktion erfordert ab sofort eine Szenenplanung, z. B. vertikales Parken, vertikales Parken, horizontales Parken, horizontales Parken, diagonales Parken usw. Sie sind alle unterschiedlich Szenarien, und ihre P- und X-Teile müssen separat implementiert werden. Die Szenenplanung kann jedoch manuell über die HMI-Schnittstelle ausgewählt werden, bei der es sich um eine „Human-in-the-Loop“-S-Einheit handelt.

Stufe 3 Unter den oben genannten Funktionen ist bei längerem Fahren kein manueller Eingriff erforderlich. Es wird unweigerlich eine automatische Planung mehrerer verschiedener EXP-Stufen erfordern. Auf diese Weise unterscheidet sich die Softwarearchitektur stark von den Funktionen unterhalb von L2. Dies ist einer der Gründe, warum viele Unternehmen L2 und L3+ in zwei verschiedene Teams aufteilen.

Solange die Softwarearchitektur bewusst auf der Grundlage des mehrstufigen EXP-S-Modells entworfen wird, verfügt jede EXP-S-Einheit über ihre eigene geeignete Ausführungsform. Tatsächlich kann eine Reihe von Softwarearchitekturen realisiert werden Unterstützung von L1 bis L3+ Das obige automatische Fahren ist grundlegend. Es ist nur so, dass die S-Einheit für Funktionen unterhalb von L2 schwächer ist, ihr architektonischer Status bleibt jedoch bestehen.

Softwarearchitektur von L2- und niedrigeren Einzelfunktionscontrollern

Werfen wir zunächst einen Blick auf die allgemeine Softwarearchitektur der L2-Funktion.

AEB/ACC/LKA-Lösung mit Smart Sensor

Die drei Funktionen AEB/ACC/LKA sind die klassischste Fahrassistenz der L2-Funktion. Der Wahrnehmungsteil der allgemeinen Systemlösung verwendet hauptsächlich eine Vorwärtskamera, um Zielinformationen (Fahrzeuge, Fußgänger) auszugeben und diese mit den vom Vorwärts-Millimeterwellenradar bereitgestellten Zieldaten zu fusionieren, um genauere Geschwindigkeit und Entfernung zu erhalten. Visuelle Wahrnehmung und Radarwahrnehmung nutzen meist Smart-Sensor-Lösungen, sodass Tier 1 Produkte von ausgereiften Tier 2-Anbietern auswählen kann. Die Hauptentwicklungsarbeit von Tier 1 liegt in der Implementierung der Wahrnehmungsfusion und des Funktionszustandsautomaten- und Fahrzeugsteuerungsalgorithmus.

Häufig verwendete Hardwarearchitektur

Option 1: Die visuellen Wahrnehmungsergebnisse werden an den Radarwahrnehmungscontroller übertragen, und die Wahrnehmungsfusion und -integration erfolgt abgeschlossen in der funktionalen Zustandsmaschine des Radarwahrnehmungscontrollers L2

Abbildung 5 Schema 1 Topologie#🎜🎜 ## 🎜🎜#

Option 2: Ein unabhängiger L2-Controller verbindet die Vision- und Radar-Smart-Sensoren, und der L2-Controller vervollständigt die Wahrnehmungsfusion und die L2-Funktionszustandsmaschine

#🎜 🎜#

Abbildung 6 Schema 2 Topologie

#🎜 🎜 #Beide Schemata werden häufig verwendet. Option 1 verwendet einen leistungsstärkeren Radarcontroller und weist einige Recheneinheiten für die Implementierung des Fusionsalgorithmus und der funktionalen Zustandsmaschine zu. Viele Chiphersteller berücksichtigen diesen Teil der Rechenleistung bei der Entwicklung von Radarverarbeitungschips. Die S32R-Serie von NXP ist beispielsweise speziell für Radar-Steuergeräte konzipiert. Ihre mehreren Kerne reichen aus, um die Radarsignalverarbeitung und die L2-Funktionsimplementierung gleichzeitig durchzuführen. Schließlich wird der rechenintensivste visuelle Algorithmus auf einem anderen Gerät ausgeführt.

Option 2 trennt L2, um den L2-Funktionscontroller zu implementieren, und kommuniziert mit den beiden Smart Sensoren über private Can, um Sensordaten zu erhalten. Generell kann bei dieser Lösung in Zukunft das Hinzufügen weiterer L2-Funktionen in Betracht gezogen werden, und bei Bedarf können Sie weitere Smart Sensoren anschließen.

Typische Softwarearchitektur

Für die Systemarchitektur mit Smart Sensor gelten die nach vorne gerichtete Smart-Kamera und das nach vorne gerichtete Millimeterwellenradar die Semantik von Zielobjekten in ihren jeweiligen beobachteten Umgebungen herauszufinden. Diese beiden Datenteile werden über den Can-Bus oder den internen IPC-Mechanismus (Inter-Process Communication of Computer OS) direkt an das Modul übertragen, das für die Wahrnehmungsfusion und die Implementierung der L2-Funktion verantwortlich ist.

Ob es sich um Hardwarelösung eins oder Lösung zwei handelt, die in der Branche am häufigsten verwendete Softwarearchitektur wird auf Basis von Classic AutoSar entwickelt. Classic AutoSar bietet allgemeine Funktionen für Fahrzeug-Steuergeräte und stellt eine Ausführungsumgebung sowie Dateneingabe- und -ausgabekanäle für Referenzsoftware bereit. Das Wahrnehmungsfusionsmodul und andere ACC/AEB/LKA-Funktionen können als eine oder mehrere AutoSar-SWCs (Softwarekomponenten) implementiert werden. Jeder Entwickler hat seine eigene vernünftige Logik, ob und wie diese SWC-Komponenten aufgeteilt werden sollen. Die grundlegende Architektur ist jedoch weitgehend dieselbe.

Natürlich können Sie Classic AutoSar nicht verwenden und ein anderes geeignetes RTOS als zugrunde liegendes System verwenden. Möglicherweise wird es für Fahrzeugsteuergeräte, die eine allgemeine Funktionsentwicklung erfordern, schwieriger erfüllen einige funktionale Sicherheitsstandards, aber die Architektur der Anwendungsfunktionsentwicklung unterscheidet sich nicht wesentlich von der Lösung mit Classic AutoSar.

Abbildung 7 Typische Softwarearchitektur von ACC/AEB/LKA #

#🎜 🎜#

MBD-Entwicklungsmethode

Die in der Branche häufig verwendete MBD-Methode (Modellbasierte Entwicklung) Zur Umsetzung der Wahrnehmung Fusionsalgorithmus, Planungs- und Steuerungsausführungsalgorithmus und ACC/AEB/LKA-Funktionszustandsmaschine. Verwenden Sie dann Tools, um C-Code zu generieren und ihn manuell in die Zielplattform zu integrieren. Einer der Vorteile der MDB-Entwicklungsmethode besteht darin, dass Sie zunächst Modellwerkzeuge und -geräte wie CanOE verwenden können, um direkt am Fahrzeug zu entwickeln und zu debuggen, oder eine Verbindung zur Simulationsplattform für Entwicklung und Debugging herstellen können. Auf diese Weise kann das Entwicklungsteam in zwei Teile geteilt werden: Ein Teil verwendet Modelltools, um Anwendungsfunktionen zu entwickeln, und der andere Teil entwickelt eine Reihe mühsamer Arbeiten, die für alle Fahrzeug-Steuergeräte erforderlich sind, und integriert sie dann.

Höher integrierte Produktlösungen

Im Allgemeinen verwenden vollautomatische Parkprodukte eine stärker integrierte Lösung in einem Steuergerät. Der visuelle Algorithmus (statisches Hindernis). Erkennung, dynamische Hinderniserkennung, Fußgängererkennung, Parkplatzlinienerkennung), Ultraschallradaralgorithmus (Abstandserkennung, Hinderniserkennung), Trajektorienplanung und Steuerungsausführung des Parkvorgangs sind alle in einem Controller untergebracht. Höhere Integrationsstufen unterstützen auch die 360-Grad-Surround-View-Funktion im automatischen Parkcontroller, was auch Unterstützung für die Kamera-Surround-Bildkorrektur und das Zusammenfügen von 2D/3D-Grafiken, die Videoausgabe, die HMI-Generierung und andere Funktionen erfordert.
Die schematische Hardware-Topologie ist wie folgt.

Hardware-Topologiediagramm

#🎜 🎜 #Abbildung 8 Hardware-Topologieschema des Parksystems

Jedes Modul in der Abbildung verfügt über unterschiedliche Verteilungsmodi in unterschiedlichen Hardware-Auswahlschemata. Im Allgemeinen verwenden MCUs, die für die Echtzeitverarbeitung verwendet werden, einen separaten Chip. Verschiedene Chiphersteller haben ihre eigenen KI-Einheitslösungen. Einige verwenden Hochleistungs-DSP, andere verwenden proprietäre Matrix-Recheneinheiten, andere verwenden FPGA und so weiter.

Typische Softwarearchitektur

Das Bild unten ist eine typische Softwarearchitektur des automatischen Parksystems (nur eine vereinfachte Darstellung, tatsächliche Massenproduktion). System wird komplizierter sein):

Im Vergleich zu 2.1.1 besteht die bedeutendste Änderung hier darin, die beiden Systeme „Echtzeitdomäne“ und „Leistung“ zu unterscheiden Domäne". Im Allgemeinen bezeichnen wir die Software- und Hardwaresysteme auf MCUs oder anderen Echtzeitkernen (Cortex-R, Cortex-M oder andere gleichwertige Serien) als „Echtzeitdomäne“. Der große Kern im SOC (Cortex-A oder gleichwertige Serie) und das darauf laufende Linux/QNX werden zusammenfassend als Leistungsdomäne bezeichnet, die im Allgemeinen auch Software- und Hardwaresysteme umfasst, die die Beschleunigung visueller Algorithmen unterstützen.

Obwohl das vollautomatische Parksystem im Hinblick auf den technischen Aufwand für die Massenproduktion viel kleiner ist als aktive Sicherheitsfunktionen der Stufe 2 wie ACC/AEB/LKA. Aber was die Softwarearchitektur angeht, ist das Parksystem viel komplizierter. Dies spiegelt sich hauptsächlich in den folgenden Aspekten wider:

Abbildung 9 Softwarearchitektur des Parksystems#🎜🎜 #

Die Aufteilung in Echtzeitdomäne und Leistungsdomäne bringt systematische Komplexität mit sich, die für unterschiedliche Berechnungen basierend auf Echtzeitanforderungen und Rechenressourcenanforderungen ausgewählt werden muss . Plattform

Nachdem das Betriebssystem im Leistungsbereich Linux übernommen hat, ist die Ausführungsumgebung auf Betriebssystemebene viel komplizierter als bei RTOS
• #🎜 🎜# Zur Unterstützung der Anwendungsentwicklung ist eine Reihe von Frameworks oder Middleware erforderlich. 🎜🎜## 🎜🎜#Verarbeitungspfad des Videostreams erhöht
• Datenpfadanforderungen zwischen der Echtzeitdomäne und der Leistungsdomäne erhöht
• #🎜🎜 #Es gibt Datenkommunikationsanforderungen zwischen verschiedenen Softwaremodulen im Leistungsbereich
• Nach der Implementierung der spezifischen Chipplattformlösung wird die Architekturdesign muss mit den verschiedenen Aspekten des Chip-SDK für die Integration und das Gesamtdesign in Zusammenhang stehen
• Darüber hinaus können wir durch diese Softwarearchitektur sehen einige Probleme, die durch die Einführung von Linux (oder QNX/vxworks) verursacht wurden. Diese Systeme selbst sind Computer-Betriebssysteme, die nichts mit bestimmten Branchen zu tun haben. Bei der Verwendung in elektronischen Steuerungen für Kraftfahrzeuge gibt es eine Reihe allgemeiner Funktionen, die nichts mit spezifischen Produktfunktionen zu tun haben, sondern als Automobil-Steuergeräte implementiert werden müssen. Wie Diagnose, Uhrensynchronisation, Upgrades usw. Dieser Teil macht einen sehr großen Arbeitsaufwand in der gesamten Controller-Entwicklung aus, der in vielen Fällen 40 % übersteigt, und steht in engem Zusammenhang mit der Zuverlässigkeit des Controllers.
• Im Bereich der Netzwerkkommunikationsausrüstung werden diese häufig als Managementebenen bezeichnet. Viele davon sind auch grundlegende Funktionen, die AutoSar AP bietet. Unabhängig davon, ob es sich um CP AutoSar oder AP AutoSar handelt, handelt es sich bei den meisten anderen, mit Ausnahme des für die Kommunikation verantwortlichen Moduls, um Funktionen der Verwaltungsebene.

• Zusammenarbeit mehrerer Einzelfunktions-Steuergeräte

  Wie man zusammenarbeitet, wenn in einem Fahrzeug mehrere L2-Funktionen vorhanden sind. Die folgende Abbildung ist ein Beispiel einer vereinfachten Multi-Controller-Topologie.

  

  Abbildung 10 Topologieschema mehrerer L2-Funktionscontroller plus Domänencontroller#🎜🎜 ##🎜 🎜#

  Diese Topologie integriert 6 Controller, bereitgestellt durch „vollautomatisches Parksystem“, „vorwärts gerichtete Smart-Kamera“ und „vorwärts gerichtetes Millimeterwellenradar“. Die Funktionalität ist wie zuvor beschrieben. Bei den Radargeräten für die linke und rechte Ecke handelt es sich um zwei gespiegelte Geräte, die jeweils unabhängig voneinander arbeiten und Funktionen wie „Alarm bei Annäherung an das hintere Fahrzeug“ und „Alarm beim Öffnen der Tür“ realisieren können. Das „Fahrerüberwachungssystem“ erkennt den Status des Fahrers und kann eine Warnung ausgeben, wenn es feststellt, dass der Fahrer während der Fahrt völlig müde ist, und benachrichtigt andere Systeme, um zu versuchen, langsamer zu fahren und anzuhalten.
  Die wichtigsten Punkte in dieser Topologie sind wie folgt: Einführung eines Domänencontrollers zum Verbinden mehrerer unabhängiger Fahrassistenzfunktionscontroller und Verbinden des Domänencontrollers mit dem Backbone-Netzwerk Can Bus, um eine unzureichende Busbandbreite zu vermeiden.
  Aus Sicht der Softwarearchitektur arbeitet jeder Fahrassistenzcontroller unabhängig und entscheidet unabhängig, seine eigenen Funktionen zu starten und zu stoppen. Relevante Steuersignale werden an den Domänencontroller gesendet, der sie an die Energiedomäne weiterleitet. Der Fahrerassistenz-Domänencontroller ist für die Steuerung der Steuerausgänge der einzelnen Controller verantwortlich. Aus Sicht der Rolle, die Domänencontroller dabei spielen können, gibt es verschiedene mögliche Ausführungen von leicht bis schwer. Beim schlanken Domänencontroller-Design übernimmt der Domänencontroller nur die einfache Datenweiterleitung, indem er die Daten im Backbone-Netzwerk filtert und an den Controller in der Domäne sendet. Senden Sie Steuersignale von Controllern in der Domäne an das Backbone-Netzwerk. Diese Methode erfordert keine hohe Rechenleistung des Domänencontrollers.
  Wenn der Domänencontroller mehr Arbeit übernimmt, kann er die Berechnungsarbeit des Echtzeit-Domänenteils anderer Controller übernehmen. Beispielsweise werden die Planungskontrollberechnungen von ACC/AEB/LKA alle auf dem Domänencontroller durchgeführt. Dies erfordert, dass andere Controller Erfassungsdaten an den Domänencontroller senden, die vom Domänencontroller einheitlich verarbeitet werden. Dies erfordert eine höhere Rechenleistung. Gleichzeitig sind auch die Bandbreitenanforderungen für domäneninterne Netzwerke gestiegen.
  Da der Domänencontroller alle Sensordaten abrufen kann, kann er auch einige zusätzliche Funktionen entwickeln, z. B. die Abhängigkeit von den Sensoren im Bild Es ist möglich, dass der Domänencontroller Spurwechselassistenz- oder Notfall-Hindernisvermeidungsfunktionen implementiert.
  Da sich die Funktionen allmählich auf Domänencontroller konzentrieren, werden die nicht bewussten Teile anderer Controller, die den Erfassungsteil tragen, allmählich geschwächt.
  EPX-SA-Konzeptmodell

  Schiedsgerichtsmechanismus#🎜🎜 #Wie bereits erwähnt, kann die Realisierung von ACC/AEB/LKA-Funktionen, die Realisierung des vollautomatischen Parkens und andere Funktionen unterhalb eines einzelnen L2 alle als eine oder zwei Schichten verstanden werden von Fraktalen Rekursives EPX-S-Modell.

  Tatsächlich können diese drei Funktionen von ACC/AEB/LKA in tatsächlichen Massenproduktionsprodukten gleichzeitig aktiviert werden. Jede davon ist ein separater EPX-S-Zyklus . . Dadurch können mehrere EPX-S-Schleifen gleichzeitig und parallel betrieben werden. Wenn gleichzeitig eine X-Ausgabe generiert wird, muss sie durch einen Schlichtungsmechanismus (Schiedsverfahren) entschieden werden.

  Wenn mehrere Controller gleichzeitig ausgeführt werden, entscheidet der Domänencontroller auf einer höheren Ebene.

  Das EPX-S-Modell sollte also zum EPX-SA-Modell erweitert werden. Wie in der folgenden Abbildung dargestellt, handelt es sich bei Szenario 1 und Szenario 2 um zwei parallel laufende EPX-S-Schleifen, und das von ihnen generierte X wird nach der Arbitrierung ausgegeben.

  

  Abbildung 11 EPX-SA-Konzeptmodell #

  #🎜 🎜#Vorschlag des Konzepts des Umweltmodells

  Jeder Controller, der eine einzelne L2-Funktion implementiert, verfügt über bestimmte Aspekte der Wahrnehmungsfähigkeiten. Sie alle beschreiben einen bestimmten Aspekt der Eigenschaften der inneren und äußeren Umgebung des Fahrzeugs, der in räumliche Winkel und Entfernungen oder in physikalische Eigenschaften wie sichtbares Licht, Ultraschallwellen, Millimeterwellen und Laser unterteilt werden kann. Wenn ein ideales, völlig genaues 3D-Modellsystem für die gesamte Umgebung erstellt wird, entspricht jeder Sensor einem Filter für das Modell. Wie ein „Blinder, der einen Elefanten berührt“ drückt jeder Sensor einen bestimmten Aspekt der Eigenschaften des idealen Modells aus.

  Der Wahrnehmungsteil des intelligenten Fahrens besteht eigentlich darin, möglichst viele Sensoren und Algorithmen zu nutzen, um eine Annäherung an das ideale Modell zu erreichen. Je mehr Sensoren verfügbar sind, desto genauer ist der Algorithmus und desto weniger weicht er vom Idealmodell ab.

  Im Domänencontroller von L2 können bei Bedarf die Sensordaten aller untergeordneten Controller abgerufen werden. Auf dieser Ebene kann dann ein realistisches Modell des idealen Umgebungsmodells zusammengestellt werden Es unterscheidet sich vom Idealmodell, aber es ist bereits ein Umweltmodell im ganzheitlichen Sinne.

  Die vom Umgebungsmodell bereitgestellten Informationen werden nicht nur in den Planungsmodulen (P) auf allen Ebenen verwendet, sondern auch in den Phasen Planung (S) und Schlichtung (A).

Das obige ist der detaillierte Inhalt vonErfahren Sie in einem Artikel mehr über die Softwarearchitektur des intelligenten Domänencontrollers. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!