Für die nächste Generation zentralisierter elektronischer und elektrischer Architektur ist die Verwendung einer zentralen + zonalen zentralen Recheneinheit und eines regionalen Controller-Layouts für verschiedene OEMs oder Tier-1-Player zu einer unverzichtbaren Option geworden. Es gibt drei Möglichkeiten: Separates SOC, Hardware-Isolation, Software-Virtualisierung. Die zentralisierte zentrale Recheneinheit wird die Kerngeschäftsfunktionen der drei Hauptbereiche autonomes Fahren, intelligentes Cockpit und Fahrzeugsteuerung integrieren. Der standardisierte regionale Controller hat drei Hauptaufgaben: Stromverteilung, Datendienste und regionales Gateway. Daher wird die zentrale Recheneinheit einen Hochdurchsatz-Ethernet-Switch integrieren.
Da der Integrationsgrad des gesamten Fahrzeugs immer höher wird, werden immer mehr Steuergerätefunktionen langsam in die regionale Steuerung übernommen. Der plattformbasierte Regionalcontroller verwendet dasselbe Hardwaredesign und dieselbe E/A-Schnittstelle, wodurch die Skalierbarkeitsanforderungen verschiedener Modelle besser erfüllt werden können. Daher übernimmt die regionale Steuerung auch die wichtige Funktion der Abstraktion der Fahrzeughardware. Die beiden werden Hochgeschwindigkeits-Ethernet anstelle der ursprünglichen Can-Kommunikation verwenden, um sich miteinander zu verbinden. Zusammenfassend lässt sich sagen, dass die skalierbare elektronische Architektur die Hardwareunterschiede zwischen den Modellen abschirmen soll. Unabhängig davon, wie viele regionale Controller im Kommunikationsnetzwerk verwendet werden, folgen ihre gegenseitigen Kommunikationsmodi denselben Regeln. Gleichzeitig übernimmt der Regionalcontroller auch die Verantwortung für die Abstraktion der Steuergerätefunktionen innerhalb seines lokalen Netzwerks.
Die oben genannte zentralisierte Architektur mit der zentralen Computerplattform als Kern hat eine einheitliche Sensor- und Peripherieschnittstelle eingerichtet, die Chip-Upgrades unterstützen kann. Ihr ultimatives Ziel besteht darin, Hardware-Upgrades während des Fahrzeuglebenszyklus zu erreichen und dadurch die Lebensdauer zu verlängern intelligenter Lebenszyklus von Automobilen. Jeder regionale Controller verfügt über eine eigene Betriebssystem-Middleware (SOA Core Middleware), die ein verteiltes Computer- und Kommunikations-Framework bereitstellen, die Unterschiede in den Kerneln verschiedener Betriebssysteme abschirmen und ein einheitliches Service-Entwicklungs-Framework für die obere Seite bereitstellen kann. Zu den beteiligten Funktionen gehören Dienstverwaltung, Netzwerkverwaltung, Kommunikationsverwaltung, Upgrades, Diagnose, Protokolle, Status usw.
Dieser Artikel konzentriert sich auf die Richtung der Software- und Hardware-Entkopplung und erklärt, wie Software und Hardware für SOA bereitgestellt werden.
Die folgende Abbildung zeigt das typische Designprinzip der SOA-Softwarearchitektur. Diese serviceorientierte Entwicklungsarchitektur ist eigentlich eine SOA-Architekturmodelllösung für die serviceorientierte Entwicklung, die es Produktmanagern ermöglicht, sich auf das Servicedesign zu konzentrieren, während die Systemsoftware tief in den Produktentwicklungsprozess eindringt. Dies ist auch eine Lösung für die Automobilsoftwarekrise. Ein großer Durchbruch. Die gesamte SOA-Architektur kann als ein von Software und Hardware entkoppeltes System zusammengefasst werden, das aus einer logischen Architektur und einer Service-Abstraktion und -Anpassung besteht, die durch eine Service-Architektur vervollständigt werden und letztendlich ein standardisiertes Service-System etablieren.
Der gesamte Entwurfsprozess für eine logische Architektur kann wie folgt zusammengefasst werden:
Elektronische und elektrische Architektur: Der Entwurf einer skalierbaren Architektur (auch Computer- und Kommunikationsarchitektur genannt) muss die Anforderungen von mehrschichtigem Design, mehrschichtigem Testen usw. erfüllen geschichtete Überprüfung, um die Kettenreaktion von Softwareänderungen während der Entwicklungsphase und den konzentrierten Ausbruch von Problemen während des Integrationstests zu vermeiden, sodass Probleme schneller entdeckt und Softwareversionen schneller geändert werden können.
Hardware-Computing-Plattform: Die skalierbare Hardwareplattform umfasst SOA Basic Service Management und SOA Hardware I/O Control Management, ist mit mehreren Sensoren und externen Geräten des autonomen Fahrsystems kompatibel und unterstützt multi-heterogene Chips und Hardware-Upgrades.
Betriebssystemkernel/Service-Middleware: Als Kern der Dateiplanung und -steuerung kann das Betriebssystem die besten Steuerungsfunktionen bei der Unterstützung der Software- und Hardware-Entkopplung und der Softwarebereitstellung auf Hardware erreichen.
Kommunikationsarchitektur: Die Skalierbarkeit der Kommunikationsarchitektur kann eine schnelle Anpassung bei der Entwicklung plattformbasierter Modelle ermöglichen. Die Kommunikationserweiterung der nächsten Stufe der Modellentwicklung kann reduziert werden Um von der aktuellen Produktgeneration zu lernen, ist keine große zusätzliche Entwicklungsarbeit erforderlich, was den Druck der späteren Produktlinienwartung erheblich verringern kann.
Um den Echtzeitanforderungen der Fahrzeugsteuerung gerecht zu werden, wird das Kernnetzwerk zuverlässige Kommunikationstechnologien wie TSN übernehmen. Im LAN unter dem regionalen Controller bleiben traditionelle Kommunikationsmethoden wie CAN und Lin bestehen. Die Kommunikation innerhalb eines lokalen Netzwerks kann in Form herkömmlicher Signale erfolgen. Im zentralen Ethernet-Backbone-Netzwerk werden Daten in Form von Diensten interagiert, was Kommunikations-Middleware wie DDS erfordert.
Serviceschicht/Anwendungsschicht: Die standardisierte Serviceschicht und die orchestrierbare Anwendungsschicht umfassen mehrere wichtige Teile des SOA-Systemfunktionsmanagements, des Unit-Domain-Funktionsmanagements, des Fahrzeugfunktionskontrollmanagements und des Cloud-Service-Managements.
Vor einer detaillierten Analyse der Kerntechnologie der Softwarearchitekturbereitstellung mit zentraler Domänensteuerung als Kern müssen mehrere verwandte wichtige Konzepte im Detail erläutert werden. Das Sensor-/Aktor-Designmuster in Autosar beschreibt, wie das Steuergerät die Sensoren/Aktoren im Regelkreis im Kontext der Gesamtarchitektur handhabt.
BEG-Geräteabstraktion befindet sich auf RTE (einer Testlaufumgebung). Es handelt sich um eine Reihe von Softwarekomponenten, die von Sensoren und Aktoren abstrahiert werden, die mit einem bestimmten Steuergerät verbunden sind und auf RTE basieren einzige Komponente, die auf die abstrakte ECU-Schnittstelle zugreifen darf. Die Geräteabstraktion extrahiert die Rohsignale von Sensoren und Aktoren, wie Pixel, Punktwolken, Spannungen, PWM-Signale, digitale Signale/Nachrichten, Frequenzen, und stellt physikalische Schnittstellen (wie Pixel, Punktwolken, Druck, Masse, Temperatur usw.) bereit. ). Tatsächlich vervollständigt die Geräteabstraktion die Konvertierung physikalischer Werte wie Spannungswerte, digitale Signale, Punktwolken usw.
Geräteabstraktion spiegelt die Austauschbarkeit von Software auf Anwendungsebene zwischen verschiedenen Hardwarevarianten durch Plattformsoftware und zugrunde liegende Treibersoftware wider.
Tabelle 1 Abstrakte Beziehung zwischen Plattformsoftware und Gerät (Sensor)
Abstrakte Schichtung |
Funktion |
Arbeitsprinzip | Arbeitsdetails |
||||||||||||
| Plattform-Software |
Eingabe des ursprünglichen Erfassungswerts, Ausgangsspannungswerts Entkopplung von Software und Hardware-Verbindung |
Stellen Sie physikalische Eigenschaften der Originalschnittstelle bereit |
mechanische Eigenschaften, elektrische Eigenschaften, funktionale Eigenschaften und verfahrenstechnische Eigenschaften. |
||||||||||||
Treiber für elektrische Geräte |
Eingangsspannungswert, gefilterter Ausgangsspannungswert Stellen Sie die Verfügbarkeit von Sensormesswerten sicher |
Führen Sie die Treibersoftware für elektrische Geräte zur elektrischen Diagnose (z. B. Erkennung) aus Masse, Batterie) Kurzschluss, offener Stromkreis usw.) |
Entrauschungsfilter Spannungskompensation, wenn der Sensor extern mit Strom versorgt wird |
||||||||||||
Sensorgerätetreiber |
Eingangsspannungswert, Ausgabesensorwert wie Pixel, Punktwolke, Temperaturwert Verschiedene Sensordifferenzelemente entkoppeln |
Sensorgerätetreiber ausführen; Sensor steuern physikalisches Verhalten von ·Filterfunktion (einschließlich Downsampling) |
Virtueller Gerätetreiber Geben Sie den Bedeutungswert des Sensors ein und geben Sie den ergänzten Gesamtwert aus, z. B. den Helligkeitswert.Ende der entkoppelten Sensorsignalkompensation 🔜 Kompensation | ||||||||||||
| ·Funktionstest-Diagnoseschnittstelle |
Tabelle 2: Abstrakte Beziehung zwischen Plattformsoftware und Gerät (Ausführer)
Zusammenfassend lässt sich das abstrakte Konzept und Design des BEG-Geräts wie folgt zusammenfassen: Die Anwendungssoftware ist unabhängig von den spezifischen Sensoren und Aktoren, die an ein bestimmtes Steuergerät angeschlossen sind. Code kann zwischen verschiedenen Sensoren und Aktoren wiederverwendet werden. Unterschiedliches Code-Sharing-Kooperationsmodell (Software-Sharing), wodurch unterschiedliche Geschäftsmodelle unterstützt werden. Funktionen auf verschiedenen Steuergeräten bereitstellen oder neu verteilen. Dieses Entwurfsmuster wird auch als Geräteabstraktion bezeichnet Die Funktions- und Serviceschnittstellen sind nach unten mit der Plattformsoftware verbunden. Ziel ist es, die Schnittstellen so weit wie möglich freizulegen, die Entkopplung von Software und Hardware zu realisieren und Softwareänderungen durch S&A-Änderungen zu vermeiden. 03 Beispiel für Geräteabstraktion in SOAHier geben wir ein Beispiel, um zu veranschaulichen, wie Geräteabstraktion in SOA-Architektur implementiert wird. Diese Methode muss nur die Sensorkategorie (z. B. Radar, Kamera usw.) kennen, um die Rohdaten der Eingabe zu definieren. Für die oberste Anwendungsschicht ist es nicht erforderlich, die spezifische Verbindungsmethode zu kennen Sensordaten müssen angewendet werden. Nehmen Sie als Beispiel die Geräteabstraktion des Sensors, die wie folgt ausgedrückt werden kann:
Zweitens entnimmt die MCU/SOC den entsprechenden Punktwolkenwert gemäß einem bestimmten Zeitraum aus der entsprechenden physischen Adresse, gibt ihn über das E/A-Gerät an das E/A-Hardware-Abstraktionsmodul weiter und erkennt den gemessenen Datenmesspunkt Über den I/O-Hardware-Abstraktpunkt wird das Elektrogerät der ersten Ebene mit dem Router verbunden, und der Sensor berechnet den Spannungswert basierend auf den Routing-Informationen und den interpretierten Rohdaten und führt eine Filterverarbeitung durch. Für diesen Vorgang ist kein Verständnis der Bedeutung erforderlich der gemessenen Daten. Anschließend wird der Spannungswert im Hardware-Abstraktionsmodul gemäß dem 8-Bit-Treiber Schritt für Schritt verarbeitet und vom Sensor-Elektronikgerätetreiber aufgerufen, um den grundlegenden Originalwert zu generieren. Dieser Wert steuert das virtuelle Gerät DRI durch den Sensor des virtuellen Geräts für Fußgänger, Verkehrsschilder usw. Schließlich liest die Anwendungssoftware in AP Autosar die Zieldaten des Sensors in Echtzeit über die Echtzeit-Betriebsumgebung RTE, die für die anschließende Planungssteuerung und Entscheidungssteuerung der Anwendungssoftware verwendet wird. Wie aus dem obigen Beispiel hervorgeht, hat die Geräteabstraktion die folgenden Vorteile: Änderungen in Sensor und Aktuator führen nicht zu damit verbundenen Änderungen in der Plattformsoftware und der Anwendungssoftware. Zusammenfassend gibt es ungefähr die folgenden Arten von Software- und Hardware-Entkopplung durch Transformationen.
Sensoren und Aktormodule desselben Typs können einige der gleichen Verarbeitungsmodule gemeinsam nutzen. Für den Verarbeitungsmodus der Seitenkamera kann beispielsweise der Verarbeitungsalgorithmus einer der Seitenkameras direkt angewendet werden Die anderen drei müssen lediglich die Kameraparameter der drei Kameras neu kalibrieren. Wenn einige Kameras auf Kameras mit höherer Auflösung aktualisiert werden müssen, müssen keine größeren Änderungen an der zugrunde liegenden Treibersoftware und Plattformsoftware vorgenommen werden, zumindest nicht an der I/. O-Schnittstelle. Es besteht keine Notwendigkeit, das Formular oder den Dateneingabemodus zu ändern, aber das Algorithmusmodul für die Bildverarbeitung muss neu abgestimmt werden. Beispielsweise ist der ursprüngliche Verarbeitungsalgorithmus mit niedriger Auflösung möglicherweise nicht in der Lage, die Echtzeitanforderungen zu erfüllen Anforderungen an das hochauflösende Verarbeitungsmodul In diesem Fall ist es notwendig, die Optimierungsmethode des neuronalen Netzwerkbeschleunigungsmodells zu untersuchen, das gesamte Algorithmusarchitekturmodell bleibt jedoch unverändert. 04 Zusammenfassung Derzeit ist die von vielen OEMs befürwortete Entwicklungsmethode die plattformbasierte Produktentwicklung, und die Plattformisierung betont die Kernidee der Entkopplung von Software und Hardware. Die Einführung des SOA-Architekturmodells erleichtert die Bildung von Produktlinien und Plattformen In der Arbeitsteilung ist die Produktlinie für bestimmte Fahrzeugmodellprojekte verantwortlich und die Plattformlinie für den Aufbau eines Technikzentrums. Bei der Entwicklung neuer Plattformen sind die technischen Verbindungen oft sehr lang und komplex. Das mehrschichtige Architekturdesign und die Software- und Hardware-Entkopplungsmethode können das mehrschichtige Testen und Verifizieren erleichtern, den Druck von Integrationstests verringern und Probleme umfassender erkennen Erhöhen Sie die Geschwindigkeit der Versionsfreigabe. |
Das obige ist der detaillierte Inhalt vonSoftware-Architekturdesign und Software- und Hardware-Entkopplungsmethodik in SOA. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
Zuerst sammelt MCAL in der darunter liegenden physikalischen Schicht Daten durch Zugriff auf den uC-Port und stellt Rohdaten bereit, die mit Sicherheit erkannt werden Zeitraum (z. B. 10 ms), es besteht keine Notwendigkeit, die Verbindungsmethode von Elektrogeräten und die entsprechende Datenbedeutung zu verstehen. Beispielsweise werden die ursprünglichen Bildpixeldaten vom zugrunde liegenden Lidar-Sensor erfasst und in den Mikrocontroller MCU/SOC eingegeben. 
Für den Austausch verschiedener Arten von Sensorsensoren ist die Auswahl des Steuergeräts nicht mehr auf das vom Steuergerät unterstützte Signalanalysemodusmodell beschränkt. Um beispielsweise NTC- und PTC-Modelle zu ersetzen, müssen Sie nur das Softwaremodul im Gerätetreiber ändern. 
