Forschung zu Software- und Hardware-Entkopplungstechnologien und Trends für autonomes Fahren

„Im Zeitalter softwaredefinierter Autos wird der Status von Software immer höher und die Entwicklung der Smart-Car-Industrie erfordert die Entkopplung von Software und Hardware.“

Ich glaube, jeder kennt Wörter Wie oben beschrieben, hat sich in intelligenten Autos in den letzten Jahren der Entwicklung die Zusammensetzung der Automobillieferkette weltbewegend verändert, und die Entkopplung von Software und Hardware ist zu einem Problem geworden, das sowohl OEMs als auch Zulieferer zu lösen versuchen .

Allerdings sind Standards immer noch schwer zu vereinheitlichen und die Schnittstellen jedes Unternehmens sind immer noch unterschiedlich. Selbst nach so vielen Jahren ist die Entkopplung von Software und Hardware immer noch mit vielen Schwierigkeiten verbunden. 01 Hintergrund der Software- und Hardware-Entkopplung Vor Jahren gab es nur ein Dutzend bis zwanzig Steuergeräte in einem Fahrzeug. Da der Konsum elektronischer Unterhaltung jedoch weiterhin alle Aspekte des Lebens der Menschen durchdringt, sind die funktionalen Anforderungen der Menschen an Autos im Kontext der verteilten Architektur mit jeder neuen Funktion gestiegen erfordert, dass das entsprechende Steuergerät kontinuierlich hinzugefügt wird. Dies gilt insbesondere für selbstfahrende Autos. Infolgedessen ist die Anzahl der Steuergeräte in einem selbstfahrenden Auto auf fast ein bis höchstens zweihundert angewachsen.

Die kontinuierliche Zunahme von Steuergeräten hat dazu geführt, dass die Gesamtlänge und die Gesamtkosten von Kabelbäumen für die Datenübertragung weiter steigen (nach Berechnungen von Zos Automotive Research steigen bei Fortführung der aktuellen verteilten Architektur die Kabelbaumkosten autonomer Fahrzeuge). (wird nicht unter 1.000 US-Dollar liegen) und auch die Schwierigkeit, Lieferanten zu verwalten, hat zugenommen.

Darüber hinaus sind in der verteilten Architektur Funktionen wie ACC und AEB an den Sensor (MCU darin) gebunden und voneinander getrennt (dies entspricht nicht den Grundprinzipien. Wenn Menschen fahren, ist das nicht der Fall ), und die Voraussetzung für autonomes Fahren auf hohem Niveau besteht darin, dass jede Funktion ein Organismus ist und daher über dasselbe SoC implementiert werden muss.

In diesem Zusammenhang ist die Verbesserung der Raumausnutzung und die Maximierung der Steuergeräteleistung auf begrenztem Raum die nächste Entwicklungsrichtung in der Branche. Infolgedessen öffnete die Automotive-EE-Architektur die Tür für die Entwicklung von einer verteilten Architektur zu einer zentralisierten Architektur. Zu diesem Zweck wurden viele Steuergeräte durch Domänencontroller ersetzt und der Hauptsteuerchip wurde aktualisiert vorherige MCU zu SoC.

ECUs nehmen ständig ab, und auch die verbleibenden ECUs im Auto haben sich von einem Teil der Berechnungen zu „Schrauben“ entwickelt, die nur noch die meisten Ausführungsfunktionen übernehmen müssen und über geschwächte Verarbeitungsfähigkeiten verfügen (ECUs immer noch). verfügen über die ursprüngliche Fähigkeit, Berechnungen zu verarbeiten, sind jedoch für die Verarbeitung einiger Berechnungen nicht mehr funktionell erforderlich.

Die Entwicklung der EE-Architektur von verteilt zu domänenzentralisiert und SoC, die MCU ersetzt, hat die Voraussetzungen dafür geschaffen, dass die Automobilindustrie von der Ära „Hardware ist König“ in die Ära „softwaredefinierter Autos“ über Domänen hinweg übergeht.

Der SoC-Chip integriert mehrere Module wie DSP, GPU und NPU. Er verfügt nicht nur über eine Steuereinheit, sondern integriert auch eine große Anzahl von Recheneinheiten. Dies ermöglicht SoC-Chips nicht nur gleichzeitiges Multitasking, sondern auch die Fähigkeit, große Datenmengen zu verarbeiten. Das Ersetzen einiger MCUs durch SoC-Chips ist so, als würde man gewöhnliche Leiter mehrerer Abteilungen eines Unternehmens durch einen superexzellenten CEO ersetzen, der eins bis hundert erreichen kann.

... Formulieren Sie einen 5-8-Jahresplan basierend auf der Software- und Hardware-Integrationslösung des Berichts. Wenn die Software und Hardware in die Produktionslinie gehen, wird es für das Fahrzeug schwierig sein, sich innerhalb von 5 bis 8 Jahren in der Software oder Hardware zu ändern, bis der Fahrzeughersteller die verschiedenen Komponenten eingebaut und das Fahrzeug ausgeliefert hat.

Wenn wir im Zeitalter der softwaredefinierten Autos weiterhin dem Integrationsprozess der ursprünglichen Autofabrik folgen und sofort einen 5-8-Jahresplan für den Autobau festlegen, wird das Problem in den ersten Jahren nicht allzu groß sein des Fahrzeugbaus, aber in der zweiten Hälfte dieses Programmzeitraums wird ein Auto an den Benutzer ausgeliefert, und sowohl die Hardware als auch die Software des Autos sind weit veraltet.

Daher sollten in der Produktdesignphase nachfolgende Iterationsprobleme berücksichtigt werden. Um das Iterationsproblem zu lösen, müssen Software und Hardware getrennt entwickelt werden.

Wenn die Hardwarekonfigurationen verschiedener Automobilhersteller konvergiert sind, ist die Hardware „rollbar“ geworden. Um eine Differenzierung zu erreichen, müssen OEMs in der Lage sein, die sich ständig ändernden Benutzerinformationen sehr schnell zu erfassen Anforderungen zu ermitteln und entsprechende Software-Iterationen durchzuführen. Derzeit haben OEMs zwei Möglichkeiten: Die eine besteht darin, Software und Algorithmen selbst zu entwickeln und alle Probleme selbst zu lösen, einschließlich der Entkopplung von Software und Hardware. Die andere besteht darin, einen geeigneten Lieferanten zu finden, der nach der Entkopplung von Software und Hardware die Iterationsanforderungen bereitstellt.

Wenn Sie den ersten Weg gehen wollen, braucht der OEM eine sehr starke Stärke, aber nicht alle OEMs verfügen über solche Fähigkeiten, daher würde ich den meisten OEMs den zweiten Weg vorziehen. Infolgedessen begann sich der Status von Software-Algorithmus-Unternehmen zu verbessern, und die Beziehung zur Automobillieferkette wandelte sich von ursprünglich klaren Tier1-, Tier2- und Tier3-Beziehungen zu einer Beziehung mit unscharfen Grenzen.

In diesem Zusammenhang haben verschiedene Software- und Hardwarelieferanten auch Anforderungen an die Software- und Hardware-Entkopplung, um eine stärkere Wettbewerbsfähigkeit, eine bessere unabhängige Entwicklung und eine bessere Kooperationsökologie zu erreichen.

Obwohl seit mehreren Jahren der Slogan der Software- und Hardware-Entkopplung gerufen wird, ist der Effekt nicht ideal.

Schwierigkeiten bei der Entkopplung von Sensoren, Chips und Algorithmen

Aufgrund von Der Algorithmus ist stark an den Sensor gebunden. In praktischen Anwendungen bereitet eine solche Bindung den Algorithmusingenieuren große Probleme. Nachdem beispielsweise die bisher in einem Auto verwendete Kamera von einer 2-Megapixel-Kamera auf eine 8-Megapixel-Kamera umgestellt wurde, darf der Algorithmus nicht neu geschrieben werden.

Außerdem ein Tier1-Algorithmus-Ingenieur:

„Auch wenn Sie die Fähigkeit haben, Wahrnehmung umzusetzen.“ Algorithmen und Sensoren Die Entkopplung, wie man den Sensor nach der Entkopplung kalibriert, ist ebenfalls besonders schwierig Ja, sobald der Sensor ausgetauscht wird, werden alle zuvor teuren Datenanmerkungen ungültig und es muss eine neue Sammlungsrunde gestartet werden. Dies ist eine sehr problematische Sache für das Algorithmusunternehmen, aber diese Angelegenheit ist es Derzeit gibt es keine gute Lösung.

Darüber hinaus sind die Sensorkonfiguration, die Einbauposition und der Einbauwinkel bei jedem Fahrzeug unterschiedlich, sodass auch die Algorithmen unterschiedlich sind. Die Erfassungsalgorithmen sind unterschiedlich und die Steueralgorithmen sind unterschiedlich.

Wenn die Entkopplung des Algorithmus und des Sensors nur mühsam ist, dann ist die Entkopplung des Algorithmus und des Chips sehr schwierig.

Als der Autor beispielsweise mit vielen Algorithmenentwicklern über Probleme im Zusammenhang mit der Software- und Hardware-Entkopplung kommunizierte, stellte ich fest, dass einer der gemeinsamen Schwachpunkte, die sie alle haben, folgender ist: Aufgrund der Schwierigkeit der Algorithmus-Transplantation wurde viel zusätzliche Arbeit geleistet.

Das liegt daran, dass die Häufigkeit der Algorithmusmigration unvorhersehbar ist. Der Wettbewerb und die Produktiterationen der Chiphersteller wirken sich oft auf die Marktpräferenzen aus. Man kann nicht sicher sein, ob sich im nächsten Trend neue und bessere Chips verkaufen werden.

Änderungen in den Marktpräferenzen werden dazu führen, dass OEMs Ersatzchips spezifizieren müssen. Zu diesem Zeitpunkt wurde für Algorithmusingenieure Ihr auf diesem Chip basierender Algorithmus möglicherweise gerade verbessert, und es werden neue Anforderungen an die Algorithmustransplantation gestellt.

Der Grund für das obige Phänomen ist die starke Bindungsbeziehung zwischen dem Algorithmus und dem Chip. Unterschiedliche Chips stellen unterschiedliche BSPs bereit, was die Wiederverwendung der zur Entkopplung von Chips und Algorithmen verwendeten Middleware erschwert und für unterschiedliche Chips unterschiedliche kundenspezifische Anpassungen erforderlich ist.

Die Person, die für das intelligente Fahrsystem eines bestimmten OEM verantwortlich ist, erklärte:

"Die Middleware Die Anpassung der ersten Schicht ist ziemlich mühsam. Wenn der Cockpit-Chip beispielsweise den 8155 oder 8295 von Qualcomm verwendet und der autonome Fahrchip den TDA4 verwendet, benötigt die Middleware unterschiedliche BSPs bei der Integration geändert werden. Nehmen Sie kundenspezifische Anpassungen vor Wenn die Hardwarearchitektur unterschiedlich ist (einige Domänencontroller verfügen über 2 oder sogar 3 SoCs), sind auch die Anforderungen an die Middleware unterschiedlich.

02 Technische Schwierigkeiten bei der Entkopplung von Software und Hardware

Middleware ist der Schlüssel zur Realisierung von Software und Hardware Entkopplung Das wichtigste benötigte Werkzeug, daher wird sich das Problem der Software- und Hardware-Entkopplung auf die Middleware konzentrieren.

Aktuelle Middleware muss tatsächlich an Funktionen, Hardwareplattformen und Betriebssysteme angepasst werden. Selbst die am stärksten standardisierte Middleware erfordert eine Anpassung durch Algorithmusunternehmen oder OEMs. Es ist schwer zu sagen, dass es eine Middleware gibt, die alles abdecken kann. Da jede Middleware einige Einschränkungen oder Einschränkungen aufweist, können einige beispielsweise keine Kommunikationsschnittstellen schnell definieren, andere sind für die plattformübergreifende Unterstützung einiger nicht besonders geeignet und einige passen nicht gut zu anderen Chips.

Bei der Datenübertragung selbst treten bei der Middleware Probleme wie Datenabweichung, Datenfehler und der Ausfall einzelner Module auf, die die Datenübertragung beeinträchtigen. Wenn beispielsweise das Datenübertragungsvolumen groß ist und SOME/IP die Datenerfassung durchführt, können viele Kommunikationssignale nicht erfasst werden und es kann leicht zu Paketverlusten kommen.

Darüber hinaus können Datenrückgabefehler leicht eine Reihe von Kettenreaktionen auslösen, die letztendlich die Entscheidungs- und Ausführungsebene beeinträchtigen und nachteilige Folgen haben. Man kann sagen, dass der Datenaustausch theoretisch Vor- und Nachteile hat, die Effizienz verbessern kann, aber wenn die Quelle falsch ist, führt dies zu einer Reihe von Fehlern und es mangelt auch an wirksamen Diagnose- und Korrekturmechanismen.

Darüber hinaus haben auch Zeit und Ort Einfluss auf die Datenübertragung. Bei hohen Geschwindigkeiten stellt Autosar AP beispielsweise höhere Anforderungen an die Datenübertragungsbandbreite. Zu diesem Zeitpunkt wird der Konflikt zwischen dem Bandbreitenübertragungsprotokoll und der Daten-Co-Line-Übertragung besonders offensichtlich sein. An Feiertagen ist die Bandbreitennutzung konzentriert und die Auslastung ist zu hoch, sodass der Datenübertragungsbedarf möglicherweise nicht gedeckt werden kann.

Zusätzlich zu den oben genannten Problemen gibt es bei der aktuellen Middleware auch Probleme wie unzureichende Caching-Mechanismen, funktionale Gruppen, die keine Verschachtelung unterstützen, und eine schlechte Zusammenarbeit der Zustandsmaschinen. Diese Probleme erfordern, dass Algorithmusingenieure an der vorhandenen Middleware arbeiten auf der Software, was die Schwierigkeit der Entkopplung von Software und Hardware erheblich erhöht.

03 Kommerzielle Schwierigkeiten bei der Software- und Hardware-Entkopplung

Zusätzlich zu den oben genannten technischen Schwierigkeiten ist die Software- und Hardware-Entkopplung mit einer Reihe kommerzieller Schwierigkeiten konfrontiert.

Professionelle Middleware-Hersteller

Middleware-Hersteller, vertreten durch Vector, RTI, EB und Yitech, hoffen, eine Reihe standardisierter Middleware zu produzieren, die an die Software und Hardware jedes Unternehmens angepasst werden kann und Hardware-Entkopplung in einem Schritt.

Aber die Realität ist nicht so schön wie gedacht. Einerseits ist es für die Produkte der meisten Middleware-Unternehmen mit Ausnahme einiger führender Middleware-Unternehmen schwierig, das echte Vertrauen der OEMs zu gewinnen. Andererseits sind die meisten Algorithmenunternehmen nicht so bereit, mit Middleware-Herstellern zusammenzuarbeiten , denn sobald die Schnittstellen und Implementierungssysteme von Middleware-Herstellern vereinheitlicht werden, bedeutet dies, dass die Substituierbarkeit ihrer eigenen Produkte verbessert und die Differenzierung verringert wird, was zu einem plötzlichen Anstieg des Wettbewerbsdrucks seitens der Algorithmenunternehmen führen wird beständig.

Wenn darüber hinaus der technologische Entwicklungsweg von Smart Cars noch nicht klar ist, hoffen OEMs, dass sich die Konfiguration ihrer eigenen Autos von Konkurrenzprodukten unterscheidet, um Wettbewerbsbarrieren zu überwinden (Differenzierung auf Anwendungsebene erfordert auch Middleware-Differenzierung als Support) und eine standardisierte Middleware wird diesem Wunsch entgegenwirken. Daher würden OEMs lieber ihre eigene Middleware entwickeln, als standardisierte Middleware zu verwenden, die von Middleware-Unternehmen entwickelt wurde.

Mit der Zeit wird es schwierig, diese Middlewares zu verkaufen, und es wird unhaltbar, nur standardisierte Middlewares herzustellen.

Nach dem, was wir über Jiuzhang Zhijia gelernt haben, mit Ausnahme von Unternehmen wie Huayu Tongruan, die sich auf Module mit hohen technischen Barrieren wie DDS konzentrieren und sich durch langfristige Akkumulation bestimmte Wettbewerbsvorteile erarbeitet haben, sind die meisten Unternehmen, die ursprünglich als positioniert waren „Middleware-Anbieter“ haben in den letzten ein bis zwei Jahren grundsätzlich damit begonnen, sich zu wandeln (in andere Bereiche zu expandieren).

Zulieferer

Algorithmenunternehmen, Tier-1-Unternehmen, die Software und Hardware herstellen, und Chiphersteller haben alle mit der Herstellung von Middleware begonnen, aber in der Praxis macht jeder eine schwer zu erlernende Erfahrung.

Algorithm Company

Wenn für Algorithmenunternehmen die standardisierte Middleware, die sie kaufen, zu allgemein ist, wird es viele Anpassungsprobleme geben, die nicht gelöst werden können, aber wenn das, was sie bekommen, in einer Blackbox geliefert wird. Allgemein- Zweckmäßige Middleware, die nicht zum Algorithmus passt, wird den Algorithmusingenieuren große Schwierigkeiten bereiten. Und wenn Sie maßgeschneiderte Middleware kaufen, muss das Algorithmenunternehmen auch viel Zeit für die Kommunikation mit dem Middleware-Hersteller aufwenden, und die Kosten sind sehr hoch.

Technischer Leiter eines Algorithmenunternehmens:

„Wenn es ein Problem gibt, wird das Unternehmen im Allgemeinen das Problem dem Middleware-Hersteller melden, aber einige Hersteller sind weniger kooperativ und verlangen vom Algorithmenunternehmen die Vorlage tatsächlicher Beweise.“ Beweisen Sie, dass es sich um ein Middleware-Problem handelt, sonst wird es ein Chaos geben, das mehr Arbeitskraft und Zeit verschlingt und den Entwicklungsprozess beeinträchtigt Das Finden empirischer Vergleiche ist mühsam und wird mehr Zeit in Anspruch nehmen. Wenn mehrere Parteien in diesem Prozess zusammenarbeiten, muss der OEM die Leute koordinieren, was den Fortschritt bei der Lösung des Problems weiter verlängert. „

Also entscheiden sich Algorithmenunternehmen einfach dafür, selbst entwickelte Middleware zu entwickeln, die besser zu ihren eigenen Algorithmen passt.

Darüber hinaus ist die Middleware von internationalen Middleware-Herstellern teuer, während die Middleware von inländischen Start-ups hergestellt wird Middleware-Hersteller Die Software ist möglicherweise nicht besser geeignet als die selbst entwickelte Middleware auf Basis des eigenen Algorithmus, was auch einer der Gründe ist, warum Algorithmus-Unternehmen ihre eigene Middleware entwickeln

„Wenn ich sie selbst entwickle, habe ich eine.“ Wäre es besser, die Anforderungen meines Projekts besser zu verstehen, als es von Middleware-Anbietern entwickeln zu lassen? " sagte ein Systemarchitekturingenieur eines Algorithmenunternehmens.

Darüber hinaus gibt es einen weiteren Grund, warum Algorithmenunternehmen selbst entwickelte Middleware entwickeln: Die Algorithmen verschiedener Algorithmenunternehmen weisen kleine Unterschiede auf, und selbst entwickelte Middleware ist es

Ein leitender Direktor eines Algorithmenunternehmens sagte:

„Derzeit ist es schwierig, die Unterschiede der einzelnen Algorithmen widerzuspiegeln. Sie sind alle in C und C++ programmiert Aufgrund der Unterschiede muss die Leistung der Middleware verbessert werden. Dazu müssen wir die Zuverlässigkeit verbessern, was darin besteht, einige Vorteile in der Funktionserfahrung zu verbessern. „

Allerdings stehen Algorithmenunternehmen auch vor vielen Herausforderungen, wenn sie selbst entwickelte Middleware entwickeln. Erstens kann die selbst entwickelte Middleware von OEMs Standards für Lieferanten setzen, aber wenn Algorithmenunternehmen selbst entwickelte Middleware entwickeln, wird dies der Fall sein schwierig. OEMs und andere Zulieferer davon zu überzeugen, sich an ihre eigenen Standards anzupassen

Wie der Softwaredirektor eines L4-Unternehmens sagte:

„Weilai und Xiaopeng stellen beispielsweise ihre eigene Middleware her, weil es das komplette Fahrzeug ist.“ Die Fabrik kann eine Reihe von Standards festlegen, um ihre Lieferanten einzuschränken. Wenn jedoch ein Unternehmen für autonome Fahralgorithmen unterstützende Middleware herstellt, ist es schwierig, andere Lieferanten davon zu überzeugen, den OEM davon zu überzeugen, dass seine Reihe von Dingen angewendet werden kann von OEMs, die nach ihren eigenen Standards integrieren können. „

Wenn ein Algorithmusunternehmen seine eigene Middleware entwickelt, kann es nicht dafür verantwortlich gemacht werden, dass das Algorithmusunternehmen besser gemacht wird

Eine Hauptmaschine Hersteller Der Chefingenieur von Intelligent Network sagte:

„Wir werden mit unseren Lieferanten einen garantierten Servicevertrag unterzeichnen, was bedeutet, dass wir bei einem schweren Qualitätsunfall natürlich der erste Verantwortliche sind, obwohl der Autohersteller die erste verantwortliche Person ist.“ Zum ersten Mal, diese Anbieter zur Rechenschaft zu ziehen. Wenn ein Algorithmusunternehmen Middleware entwickelt, können sie sich der Verantwortung kaum entziehen, wenn es einmal darum geht, und wir werden nicht zulassen, dass sie sich der Verantwortung entziehen. Chiphersteller. Der Zweck der Chiphersteller bei der Herstellung von Middleware besteht darin, Chipleistung anzeigen.

Aus technischer Sicht ist es für Chiphersteller weniger schwierig, Middleware herzustellen als für Algorithmenunternehmen. Da Algorithmenunternehmen sich an unterschiedliche Chips anpassen müssen, ist die Arbeitsbelastung weitaus komplizierter als die von Chipherstellern, die Middleware herstellen, und die von Chipherstellern hergestellte Middleware muss sich lediglich an ihre eigenen Chips anpassen können.

Trotzdem wird die von Chipherstellern entwickelte Middleware in der Praxis nur von sehr wenigen Menschen genutzt.

Derzeit ist bekannt, dass zu den Hauptunternehmen, die Middleware herstellen, Middleware-Hersteller, Algorithmenunternehmen, Chiphersteller und OEMs gehören. Der Marktanteil von Middleware ist sehr dünn gespalten und die Konkurrenz ist hart. Wenn Sie zu diesem Zeitpunkt eine vollständige Middleware entwickeln möchten, an wen sollten Sie die entwickelte Middleware verkaufen? Kann man mit Middleware wirklich Gewinne erzielen? All dies ist zu Problemen geworden, die vor der Entwicklung von Middleware berücksichtigt werden müssen.

Ein Experte eines Algorithmenunternehmens sagte:

„Wir verwenden normalerweise keine Middleware von Chipherstellern, da diese aus ökologischen Gründen mehr Middleware herstellen, aber die Leistung ist nicht unbedingt optimal.“ einschließlich KI-Abstraktion, Wiedergabe von Datenaufzeichnungen und Verarbeitung von Punktwolken, alles kann durchgeführt werden, aber in diesem Fall wird es ein Problem geben: Der Algorithmus sollte ursprünglich Dinge tun, aber die Middleware hat sie alle erledigt, und die Leistung ist es nicht Gut. Vollständig garantiert, und es muss die Bedürfnisse mehrerer Algorithmenunternehmen berücksichtigen, und die Flexibilität wird schlechter Der Wettbewerb auf dem Markt ist groß und erfordert auch die Investition großer Arbeitskräfte und materieller Ressourcen in Forschung und Entwicklung. Die meisten leistungsfähigen Chiphersteller haben keine Motivation, zu viel in die Herstellung von Middleware zu investieren, sondern konzentrieren sich lieber darauf, den Chip selbst gut zu machen.

Daher ist die selbst entwickelte Middleware der meisten Chiphersteller sehr leicht und im Grunde handelt es sich um Demo-Middleware, die auf dem Chip ausgeführt werden kann, um Kunden die Leistung des Chips zu demonstrieren. Bei der Entkopplung von Soft- und Hardware wird eine solche Demo-Middleware sicherlich keine nennenswerte Hilfe sein.

Original OEM

Für OEMs bestand schon immer der Bedarf an Middleware-Anpassungen.

Der Verantwortliche für das intelligente Fahrsystem eines bestimmten OEM gab ein Beispiel:

„Zum Beispiel beim Schreiben eines Ampelerkennungsalgorithmus oder eines binokularen Sehalgorithmus, wenn Sie sich vom Herkömmlichen unterscheiden möchten.“ Für Algorithmen oder Algorithmen von Mitbewerbern benötigen Sie eine Reihe angepasster Middleware, die das Abonnieren, Teilen, Aufzeichnen, Wiedergeben, Senden, Speichern und Diagnostizieren von Daten sowie andere Funktionen der Middleware umfasst. Es kann jedoch nicht garantiert werden, dass diese Funktionen unter dem Algorithmus einwandfrei funktionieren Es kann zu Konflikten mit dem vom OEM benötigten System oder Funktionsmechanismus kommen, und zu diesem Zeitpunkt ist ein Middleware-Anbieter erforderlich, der bei der Lösung des Problems hilft Algorithmenunternehmen. Selbstentwickelte Middleware.

Zuallererst bedeutet der Kauf von Closed-Source-Middleware wie RTIs DDS oft, dass die Middleware angepasst wird, was nicht nur höhere Kosten verursacht, sondern auch, dass der Projekt-Docking-Zyklus im Vergleich dazu sehr lang ist So können Sie die Richtung der Anpassung vollständig steuern, Ihre eigenen Daten abrufen und das Produkt uneingeschränkt gestalten. Auf diese Weise können Sie den Produktentwicklungsprozess und die spätere Transformation besser steuern und das Problem lösen, das aufgrund des Ausfalls einer bestimmten Middleware auftreten kann Die Kette verursachte das Problem der verzögerten Massenproduktion.

Zweitens kann selbst entwickelte Middleware auch gewisse technische Barrieren für OEMs bilden. Bei einigen leistungsstarken OEMs liegen einige Anwendungsschichten der oberen Schicht vollständig in ihren eigenen Händen. Sie können ihre eigene Middleware entsprechend den Anforderungen ihrer Anwendungen der oberen Schicht erstellen und einige Funktionen der oberen Schicht besser anpassen .

Tatsächlich, wenn die Middleware-Technologie noch nicht ausgereift ist und zukünftige Trends noch nicht offensichtlich genug sind, besteht der Grund, warum vor- und nachgelagerte Akteure in der Branche Middleware herstellen, darin, die Grenzen ihrer eigenen Fähigkeiten zu testen und die Grenzen zu erkunden der gesamten Branche.

Viele Ingenieure für autonomes Fahren von OEMs glauben jedoch, dass „im Vergleich zu Algorithmenunternehmen die selbst entwickelte Middleware der OEMs kaum Vorteile hat.“

Erstens verfügen die meisten OEMs nicht über große Algorithmenkapazitäten. Die Kosten für die Einrichtung eines Teams speziell für die Herstellung von Middleware sind enorm, aber das Ergebnis ist möglicherweise nicht so gut wie das eines Anbieters, der sich darauf spezialisiert hat . Es ist, als ob der Schmerz, der durch die eigenen schwachen Projekte verursacht wird, schmerzhafter sein wird als die neuen Herausforderungen der eigenen starken Projekte.

Zweitens ist es für die vom OEM selbst entwickelte Middleware schwierig, genügend Beispiel-Feedback zu erhalten, was der Produktiteration nicht förderlich ist. Die Algorithmen und Middleware der Zulieferer werden von allen immer häufiger genutzt, und mit zunehmender Kundenbasis wird die Kundenrückmeldungsrate zu Fehlern höher sein, was jedoch dem iterativen Produktfortschritt zuträglicher ist, wenn die OEMs ihre eigenen Produkte entwickeln und nur diese liefern Produkte für sich selbst, es wird einfach sein. Da nicht genügend Beispieldaten vorhanden sind, ist die Iteration langsamer.

Wenn der OEM außerdem seine eigene Middleware entwickeln möchte, wird er zwangsläufig technische Talente von anderen Unternehmen abwerben. Talente, die in einer Abteilung eines großen Unternehmens arbeiten, haben jedoch möglicherweise kein so starkes Sendungsbewusstsein. Schließlich wird es immer das Gefühl geben, dass „der Himmel einstürzt und es immer noch Menschen gibt, die ihn halten.“ Das Ergebnis ist, dass es als ideal gilt, wenn die Fähigkeiten der rekrutierten Talente zu 80 % ausgenutzt werden können. Aber wenn das gleiche technische Talent alleine an die Arbeit geht und die Forschung mit persönlichen Interessen verbunden ist, wird er definitiv mehr Druck und Motivation haben, es gut zu machen. In einem solchen Umfeld kann er oft mehr Talente zeigen.

Schließlich erfordert selbst entwickelte Middleware für den Aufbau eines Forschungsteams viel Talent. Sobald sich herausstellt, dass dieser Weg nicht weitergehen kann, besteht die Gefahr, dass eine so große Anzahl von Mitarbeitern entlassen wird. Die Entlassungen einer großen Zahl von Mitarbeitern werden bei den derzeitigen Mitarbeitern das Gefühl verstärken, dass „das Unternehmen instabil ist“.

Aus dieser Sicht ist die „selbst entwickelte Middleware“ der OEMs vielleicht eher nur ein Marketing-Slogan, aber das bedeutet nicht, dass die selbst entwickelte Middleware aller OEMs nicht erfolgreich sein kann, wenn sie stark genug ist. Sie können OEMs, die erfolgreich selbst entwickelte Algorithmen entwickelt haben, eine hohe Erfolgswahrscheinlichkeit bei selbst entwickelter Middleware haben. Aber relativ gesehen müssen OEMs, die nicht in der Lage sind, die meisten Algorithmen selbst zu entwickeln, die Anforderungen für die Entkopplung von Software und Hardware immer noch von den Zulieferern erfüllen.

04 Middleware weicht „von ihrer ursprünglichen Absicht ab“

Die Geburtsstunde der Middleware bestand ursprünglich darin, das Problem zu lösen, dass Software und Hardware nicht getrennt entwickelt werden können. Daher hofften die Menschen zunächst, dass Middleware eine blockierende Wirkung haben könnte Software kann den Prozess rationalisieren und an die gesamte Software und Hardware angepasst werden, sodass Software-Anwendungsingenieure auf höherer Ebene gute Ergebnisse in Algorithmen erzielen können, ohne sich mit Hardware-Anpassungsproblemen befassen zu müssen.

Die Realität steht jedoch im Widerspruch zum ursprünglichen Wunsch.

Einerseits weist Middleware eine hohe Individualisierungsintensität auf.

Ein Softwarearchitekt eines Algorithmenunternehmens stellte vor:

„Jedes Automodell oder jede Chipplattform verfügt über eine unterschiedliche Anpassungsfähigkeit an die Middleware. Die bereitgestellte zugrunde liegende Software passt sich an die Middleware an. Die Fähigkeiten sind ebenfalls unterschiedlich. Wenn einige Fahrzeuge verwenden.“ Das QNX-Betriebssystem und einige verwenden das Linux-Betriebssystem. Diese beiden Betriebssysteme verfügen über einige angepasste Inhalte für die Middleware. Basierend auf einer bestimmten Plattform müssen beispielsweise einige spezielle Kommunikationsmethoden aktiviert werden. Einige müssen Daten nicht über eine gemeinsame Verbindung wie herkömmliches Ethernet übertragen. Die Verwendung spezieller Verbindungen wie PCIe oder Speicher erfordert jedoch eine Anpassung der Middleware kann die Kommunikationsanforderungen verschiedener Links unterstützen.

„Einige Hersteller oder OEMs von autonomer Fahrsoftware verfügen über eigene Protokollierungsmethoden, andere möglicherweise nicht. Für die Bereitstellung einer Protokollierungsfunktion ist Middleware erforderlich. Abhängig von den Fähigkeiten verschiedener Benutzer führt die Middleware daher entsprechende Anpassungen durch.“

Anpassung bedeutet, ob es darum geht, dem Middleware-Hersteller Leute zuzuweisen, die andere Anforderungen als die Standardisierung erfüllen, oder ob das Algorithmenunternehmen/die Host-Fabrik dedizierte Docking-Algorithmus-Ingenieure entsenden soll, um die Middleware durchzuführen. Die personalisierte Anpassung und Anpassung erfordert zusätzliche Arbeitskräfte und Material Ressourcen.

Die angepasste Middleware schafft neue Schwierigkeiten bei der Datenanalyse durch den Algorithmus.

Ein Ingenieur eines OEM sagte unverblümt:

„Wenn V2X in Massenfahrzeugen installiert werden soll, die Middleware bei verschiedenen Modellmarken jedoch unterschiedlich ist, dann wird auch die QoS (Servicestrategie) unterschiedlich sein.“ . Es gibt Probleme bei der Datenanalyse, daher kann die Kommunikation zwischen Fahrzeugen schwierig sein. „

Andererseits beginnen immer mehr Akteure, den AUTOSAR-Standard zu umgehen und es selbst zu tun.“ sagte ein Systemexperte eines OEM. In einer Zeit, in der jedes Unternehmen seine eigene Middleware entwickelt, passt sich die meiste Middleware nur an ihre eigenen Algorithmen, Schnittstellen usw. an, und das Phänomen der Inkonsistenz wird immer schlimmer.

Ob es sich um einen OEM oder ein Algorithmenunternehmen handelt: Anstatt zu prüfen, ob die Middleware einfach zu verwenden ist und ob Software und Hardware entkoppelt sind, wird bei der Projektzusammenarbeit wirklich darüber nachgedacht, ob sie die tatsächlich aufgetretenen Probleme lösen kann. Wenn die gekaufte Middleware das Problem nicht löst und nicht den gewünschten Effekt erzielt, müssen beide Parteien verschiedene Inhalte basierend auf der ursprünglichen Middleware ändern und hinzufügen, was zu einer Situation kontinuierlicher „Kopplung“ führt. Die Anpassung der Middleware ist zu einem unvermeidlichen Phänomen geworden.

Wenn ich also auf die ursprüngliche Absicht der Middleware zurückblicke, Prozesse zu vereinfachen und die Arbeitsbelastung zu reduzieren, muss ich seufzen.

05 Wie können wir eine Entkopplung von Software und Hardware erreichen?

Wenn Sie also eine Software- und Hardware-Entkopplung erreichen möchten, von welchen Gesichtspunkten aus können Sie beginnen?

Einerseits kann die Hardware-Virtualisierung zunächst auf Betriebssystemebene erfolgen und Schnittstellen, Kommunikationsprotokolle usw. können standardisiert werden, sodass Anwendungen der oberen Schicht nicht unterschiedliche Probleme des zugrunde liegenden Systems berücksichtigen müssen , aber dafür ist eine intensive Zusammenarbeit zwischen Chipherstellern und Betriebssystemherstellern erforderlich, oder Chiphersteller entwickeln ihr eigenes Betriebssystem, sodass es immer noch große Schwierigkeiten gibt.

Obwohl die zukünftige Form der Middleware noch unklar ist, ist eines sicher: Die Entkopplung von Software und Hardware muss noch in Form von Middleware gelöst werden, aber Middleware kann auf verschiedene Arten unterschieden werden:

1. Middleware-Anbieter entwickeln Tool-Middleware, die Autosar basierend auf Autosar selbst vereinfacht. Da Autosar selbst sehr komplex ist, ist es für Ingenieure nicht leicht zu erlernen. Wenn eine vereinfachte Version des Entwicklungstools bereitgestellt werden kann, wäre es eine gute Idee, dieses Tool vor- und nachgelagerten Herstellern zur Verfügung zu stellen, die selbst entwickeln müssen Middleware und optimieren ihren eigenen, selbst entwickelten Middleware-Prozess.

2. Middleware-Fabriken, Hauptmotorenhersteller und Zulieferer bilden eine Middleware-Allianz, wobei die Chipfabrik oder Hauptmotorenfabrik die Führung übernimmt, um die Regeln zu vereinheitlichen. Bei der Austestung der Marktgrenzen wird ein sehr leistungsfähiger OEM oder eine Chipfabrik die Führung übernehmen und eine Industrieallianz bilden, um Standards, Betriebssysteme, Schnittstellen usw. zu vereinheitlichen, um Industriestandards zu bilden.

3. Vollständig Open Source, mit einem proprietären Betriebssystem, das vom Chiphersteller entwickelt wurde, sodass vor- und nachgelagerte Unternehmen auf dieser Basis entwickeln können. Chiphersteller erstellen Open-Source-Toolkits wie CUDA von NVIDIA, die nicht nur ihr eigenes Betriebssystem und ihre eigene Middleware entwickeln, sondern auch vollständig Open Source sind und Upstream- und Downstream-Kunden dabei helfen, Tools für eine bessere Anpassungsentwicklung gemeinsam zu nutzen und ein gutes Ökosystem aufzubauen.

4. Als Dienstleistung bieten wir Lieferanten maßgeschneiderte Middleware-Services und Wartungsarbeiten an. Aufgrund der niedrigen Marktobergrenze und der Schwierigkeit, Middleware zu vereinheitlichen, wird Middleware möglicherweise nicht zu einem unabhängigen Produkt, sondern zu einem maßgeschneiderten Dienst. Da Middleware-Hersteller über bessere Erfahrungen in der Middleware-Forschung verfügen, sind sie besser in der Lage, solche maßgeschneiderten Dienste anzubieten.

In der Vergangenheit erlebten verschiedene Mobiltelefonmarken ihre volle Blütezeit. Von 2005 bis 2010, als „Brick Phones“ und Smartphones Seite an Seite flogen, waren auf dem Markt bis zu 200 Mobiltelefonschnittstellen im Umlauf Markt. Verschiedene Marken von Mobiltelefonen haben unterschiedliche Ladeschnittstellen, unterschiedliche Kopfhörerschnittstellen, verschiedene große und kleine Schnittstellen mit derselben Form und unterschiedlichen Größen, und sogar Mobiltelefone derselben Marke haben unterschiedliche Ladeschnittstellen.

Ein Digitalexperte musste damals oft 5 oder 6 Arten von Ladegeräten und 5 oder 6 verschiedene Kabel mitbringen, wenn er auf Geschäftsreise ging. Auch wenn wir später ein Universalladegerät haben, können wir zum Aufladen nur den Akku des Tablet-Telefons herausnehmen. Das Problem, dass der Ladeanschluss des Smartphones und die Kopfhöreranschlüsse unterschiedlicher Größe nicht vereinheitlicht werden können, lässt sich immer noch nicht lösen.

Solch eine chaotische und ungeordnete Zeit ist auch die Zeit, in der die Entwicklung der Mobiltelefontechnologie nach dem Aufstieg der Mobiltelefone am brillantesten und dynamischsten ist, genau wie die aktuelle Entwicklung intelligenter Autos. Heute sehen wir, dass Hunderte von Mobiltelefonherstellern im Rahmen ihrer eigenen Forschung nach und nach unter der endgültigen Entscheidung des Marktes vereinheitlicht wurden und schließlich Standards gebildet haben.

Die Smart-Car-Branche ist stark vom elektronischen Verbrauchermarkt betroffen, insbesondere vom Mobiltelefonmarkt. In den letzten zwei Jahren wirkten alle in der Branche sehr ungestüm und alle waren bestrebt, schnell zu sein Im Endzustand hoffe ich, in kurzer Zeit einen Meister auswählen zu können. Tatsächlich ist die Automobilindustrie jedoch eine langsam wachsende Branche. Von der Produktion von Fahrzeugen über die Massenproduktion bis hin zum Verbrauchermarkt können wir uns nur kontinuierlich optimieren und Standards bilden. Und vielleicht kann Middleware erst jetzt wirklich zu einem Standard vereinheitlicht werden.

Wenn die Technologie in Zukunft ausgereift ist, könnte Middleware als Basissoftware verwendet werden, die auf dem ASIC-Chip verfestigt ist, und es ist nicht bekannt, ob sie nicht mehr in der Software enthalten sein wird Form der Middleware allein.

06 Ein paar abschließende Worte

Allerdings gibt es derzeit viele Schwierigkeiten Wer ist in diesem Fall für Middleware geeignet?

Im Allgemeinen ist der Chiphersteller die am besten geeignete Middleware, wenn wir Standard-Middleware verwenden möchten, um das Ziel der Entkopplung von Software und Hardware vollständig zu erreichen.

Zwei Gründe: Erstens basiert die Anpassung des Algorithmus letztlich auf der Chip-Plattform, und der Chip ist der Grundstein. Zweitens gibt es weniger Chip-Unternehmen als Algorithmen-Unternehmen, und es ist vergleichsweise weniger schwierig, sie zu vereinen.

Aber basierend auf der Prämisse, dass jeder eine Anpassung erwartet, sind Algorithmusunternehmen derzeit am besten geeignet, maßgeschneiderte Middleware herzustellen.

„Chipunternehmen legen mehr Wert auf die Anwendung des Chips selbst, z. B. ob ein Überprüfungsmechanismus hinzugefügt werden soll, wie BSP geplant und beschleunigt werden soll usw. Chipunternehmen.“ Das können alle erreichen, aber Chip-Unternehmen können keine besseren Optimierungsvorschläge für Anwendungssoftware und Middleware machen. Der Kunde kann nur seine ausgereifte Lösung verwenden, aber diese Lösung kann möglicherweise nicht alle Anforderungen der Software erfüllen # Es ist ersichtlich, dass Algorithmenunternehmen diejenigen sind, die in der Geschäftspraxis die meisten Anpassungsanfragen erhalten und am häufigsten aufgefordert werden, eine Middleware-Anpassung vorzunehmen. Am bequemsten ist es, direkt angepasste Middleware zu erstellen, die sich an ihre eigenen Algorithmen anpasst.

Der Chefingenieur einer bestimmten Hauptmotorenfabrik hat auch die gleiche Ansicht:

"Soweit Was die Funktionen der oberen Ebene betrifft, ist der Dienst relativ fokussiert und der Anbieter von autonomen Fahrlösungen verfügt über ein tiefes Verständnis für funktionale Anwendungen. Durch die Abstraktion der Middleware von der Anwendungsschicht kann er besser mit den zugrunde liegenden Mainstream-Chip-Hardwarelösungsanbietern mithalten. Die Gesamtlösung ist sinnvoller.“ #🎜 🎜#

Das obige ist der detaillierte Inhalt vonForschung zu Software- und Hardware-Entkopplungstechnologien und Trends für autonomes Fahren. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!