Ein Artikel über die fünf Schlüsselelemente für die Implementierung softwaredefinierter Autos

1 Architektur-Upgrade -Oriented Architecture (SOA)-Methodik. Automotive SOA organisiert die zugrunde liegenden Fähigkeiten der Fahrzeugintelligenz. Die Hardwarefähigkeiten und verschiedenen Funktionen des Fahrzeugs werden in Dienste umgewandelt. Diese Dienste werden mit Schnittstellen entworfen, die auf SOA-Standards basieren, und kommunizieren auf der Grundlage von SOA-Standardprotokollen. Auf diese Weise kann jede Servicekomponente aufeinander zugreifen und so die Form der Servicekombination erweitern.

Abbildung 1 Schematische Darstellung der serviceorientierten SOA-Architektur

Die Einführung von SOA hat das traditionelle geschlossene und verfestigte Softwaresystem von Automobilen schrittweise in ein offenes und wiederverwendbares Software-Ökosystem umgewandelt. In der neuen Runde der Software-Architektur-Upgrades, die auf der geschichteten, entkoppelten SOA-Service-orientierten Architektur basieren, werden Geräteabstraktion und atomare Dienste verwendet, um eine vollständige Serviceisierung der Hardware-Funktionen zu realisieren. Zu den spezifischen Objekten gehören Sensoren, Aktoren und traditionelle Buskommunikation rund um den Controller. sowie die eigenen Diagnose- und Speichergeräte des Controllers. Gleichzeitig wird basierend auf der Designidee der „logischen semantischen Konvertierung“ die Schnittstellenstandardisierung abgeschlossen und die Ziele der Schnittstellenwiederverwendbarkeit für verschiedene Plattformen und verschiedene Modelle erreicht.

Abbildung 2 Beispiele für Basisdienste unter SOA-Architektur

Mit Änderungen in der Infrastruktur und den Entwicklungsmethoden werden „softwaredefinierte Autos“ den gesamten Fahrzeugentwicklungsprozess und darauf basierende Softwarearchitekturlösungen untergraben SOA stellt wichtige Service-Abstraktionen für Smart-Car-Systeme bereit. Die strenge Kapselung und Schichtstruktur unterstützt den Einsatz agiler Entwicklungsmethoden und Schnittstellentests und reduziert die Komplexität des Systems, was die Wiederverwendung von Softwarekomponenten bei Fahrzeugaktualisierungen erheblich vereinfacht.

Abbildung 3 Schematische Darstellung der Software-Schichtarchitektur

Architekturstandardisierung:

Die Schichtarchitektur führt die atomare Serviceschicht und die Geräteabstraktionsschicht in die ursprüngliche Fahrzeugarchitektur ein.

Die Geräteabstraktionsschicht ist dafür verantwortlich, die zugrunde liegenden Hardwareunterschiede zu kapseln und Schnittstellen mit den Eigenschaften der Hardwareschicht in Form von Diensten bereitzustellen, damit die atomare Dienstschicht keine Änderungen in der Die von der Systemsoftware bereitgestellten Schnittstellen sind von den Einschränkungen der zugrunde liegenden Hardwareplattform befreit. Die atomare Dienstschicht dient als mittlere Schicht und ist von der Plattform entkoppelt. Sie übernimmt den Aufruf von Anwendungsdiensten auf der oberen Seite die Geräteabstraktion auf der unteren Seite, die Fahrzeugmodellunterschiede und Konfigurationsanpassungen widerspiegelt und die Wiederverwendung von Anwendungen der oberen Schicht über Fahrzeugmodelle hinweg ermöglicht; Der Anwendungs-/Kompositionsschichtdienst ist hauptsächlich für die Realisierung der Benutzernachfragelogik verantwortlich und kombiniert sich ständig ändernde szenariobasierte Anwendungen durch Aufrufen der von der atomaren Serviceschicht bereitgestellten Schnittstelle.

Schnittstellenstandardisierung:

Über alle Modelle und Komponentenlieferanten hinweg maximieren Sie die Wiederverwendung und reduzieren die Komplexität der softwaredefinierten Software- und Hardwareentwicklung für die Automobilindustrie.
Wie kann die Software auf Basis der Architekturstandardisierung autokonzernübergreifend eingesetzt werden? Es ist notwendig, die Schnittstellen zwischen den Schichten zu standardisieren. Verschiedene OEMs, Tier1s und Plattformlieferanten definieren den gleichen Satz von Serviceschnittstellen, sodass Software zwischen verschiedenen OEMs und Tier1s sich gegenseitig aufrufen kann, wodurch die Anzahl der Software erheblich erhöht wird. Die Wiederverwendbarkeit verkürzt das Fahrzeug Entwicklungszyklus.
Im Hinblick auf die Förderung der Schnittstellenstandardisierung hat der chinesische Verband der Automobilhersteller die dritte Ausgabe der „Software-Defined Automotive Atomic Service API Interface and Device Abstraction API Interface Reference Specification“ veröffentlicht, die mehr als 700 APIs enthält Karosseriesteuerung, Wärmemanagement, Es gibt mehrere Funktionsbereiche wie Energiemanagement, Bewegungssteuerung, intelligenter Fahrbereich, Leistungsbereich, Fahrwerksbereich usw. Zu den Mitgliedern, die an der Standardisierungsdefinition von Schnittstellen teilnehmen, gehören mehr als 100 Unternehmen, darunter OEMs, Komponenten und Basis Plattformanbieter und Softwareanbieter.

• 1.2 Kommunikationsarchitektur: Technologieanwendung basierend auf Fahrzeug-Ethernet

  Mit der kontinuierlichen Zunahme der Fahrzeugfunktionen, Insbesondere mit der kontinuierlichen Weiterentwicklung des autonomen Fahrens und der intelligenten Cockpits sind die zu übertragenden Signale ständig gestiegen und werden von den Nutzern an die OTA-Upgrade-Erfahrung gestellt Die Wachstumsrate von Funktionen kann mithilfe der auf Ethernet-Diensten basierenden Kommunikationsmethode die flexible Neuorganisation von Funktionen realisieren und so das Problem in der herkömmlichen signalorientierten Kommunikationsarchitektur effektiv lösen, das aufgrund der Zunahme oder Abnahme entsteht. Durch die Änderung einzelner Signale ändern sich alle mit der Funktion verbundenen Systeme.

  Fahrzeug-Ethernet und die von ihm unterstützte Protokollarchitektur der oberen Schicht sind in der folgenden Abbildung dargestellt. Fahrzeug-Ethernet unterstützt hauptsächlich OSI-Schicht-1- und Schicht-2-Technologien , TCP/IP, DoIP, SOME/IP, DDS und andere Protokolle oder Anwendungsformulare.

  

  Abbildung 4 Fahrzeug-Ethernet und seine unterstützte Protokollarchitektur der oberen Schicht#🎜 🎜 #

  Der vollständige Name von SOME/IP lautet: Scalable Service-Oriented Middleware over IP, eine skalierbare serviceorientierte Middleware auf IP-Basis, die 2013 in die AUTOSAR 4.1-Spezifikation integriert wurde .

  

  Abbildung 5 Unterstützung serviceorientierter SOME/IP-Middleware #🎜🎜 #

  Änderungen nach dem Upgrade der Kommunikationsarchitektur:
  Flexiblerer Kommunikationsmechanismus: CAN-Bus Für Rundfunk Bei der Kommunikation funktioniert der Multi-Master-Modus so, dass die von jedem Knoten gesendeten Informationen alle Kommunikationsmedien belegen können, der empfangende Knoten jedoch wählen kann, ob er die Informationen empfangen möchte. Ethernet kommuniziert auf zwei Arten: eins-zu-eins oder eins-zu-viele. Bei der eins-zu-eins-Methode deckt die Nachricht des sendenden Knotens die Adresse von sich selbst und einem empfangenden Knoten ab. Die Nachricht des sendenden Knotens umfasst die Adressen von sich selbst und einem empfangenden Knoten. Die Adressen von sich selbst und mehreren empfangenden Knoten. Beides hat keinen Einfluss auf die Kommunikation anderer Knoten.
  Höhere Bandbreite, geringere Latenz: Die Gesamtmenge der Datenübertragung im Auto und die Anforderungen an die Übertragungsgeschwindigkeit steigen immer weiter, ebenso wie die Nachfrage nach Standardprotokollen überall Branchen Angetrieben durch ist es unumgänglich geworden, mehr Anwendungsszenarien zu unterstützen und traditionelle Kommunikationsnetzwerke im Fahrzeug wie CAN/LIN durch schnelleres Ethernet zu ersetzen.
  Mehr Anwendungsszenarien, einfache Vernetzung und einfache Erweiterung: In-Vehicle-Ethernet und Off-Vehicle-Netzwerk basieren bei der Kommunikation mit dem Off-Vehicle-Netzwerk auf dem gleichen Protokoll , der Schnittstellenübergang ist reibungsloser. Herkömmliche Kommunikationsnetzwerke im Fahrzeug basieren auf einzigartigen Netzwerkprotokollen und weisen eine schlechte Schnittstellenstandardisierung auf. Bei der Interaktion mit Netzwerken außerhalb des Fahrzeugs müssen Protokolle verschiedener Systeme konvertiert werden. Aufgrund des Vernetzungstrends sind die Kosten für die Protokollumwandlung von Automotive-Ethernet sogar noch geringer.
  Schnellere OTA-Upgrade-Geschwindigkeit, benutzerfreundlichere Erfahrung: Bei Verwendung von Ethernet für das OTA-Upgrade ist die Kommunikationsgeschwindigkeit mehr als zehnmal höher als bei einem herkömmlichen CAN-Upgrade Reduziert die Wartezeit des Benutzers erheblich. Durch den Einsatz der dienstbasierten Kommunikation SOME/IP kann eine flexible Neuorganisation von Funktionen realisiert und das Problem der Zunahme oder Abnahme/Änderung einzelner Funktionen in der traditionellen Architektur mit funktionalen Anforderungen als Kern effektiv gelöst werden, was zu der Notwendigkeit führt, Funktionen zu ändern. verwandte Systeme und reduzieren die Notwendigkeit von System-OTA-Upgrades.

  1.3 Hardware-Architektur: regionaler Zugriff + Zentralisierung der Rechenleistung#🎜 🎜# Die elektronische und elektrische Architektur des Fahrzeugs ist der Grundstein für die Realisierung softwaredefinierter Autos. Die meisten derzeit auf dem Markt verkauften herkömmlichen Autos verfügen über eine verteilte elektronische und elektrische Architektur, wie in der folgenden Abbildung dargestellt.

  

  Abbildung 6 Schematische Darstellung der traditionellen verteilten elektronischen und elektrischen Architektur

  #🎜🎜 ## 🎜🎜#In der verteilten elektronischen und elektrischen Architektur werden Fahrzeugfunktionen zunächst in verschiedene Module unterteilt, wie z. B. Leistungssteuerung, Fahrwerkssteuerung, aktive Sicherheit, passive Sicherheit, intelligentes Fahren, Infotainment und Karosserie , usw. . Anschließend werden die Funktionen jedes Moduls weiter unterteilt. Beispielsweise werden die Karosseriefunktionen weiter in Funktionen wie Lichtsteuerung, Türsteuerung und Sitzsteuerung unterteilt. Verschiedene elektronische Steuerfunktionen werden mithilfe unabhängiger elektronischer Steuergeräte (ECUs) implementiert, und verschiedene ECUs kommunizieren über CAN/CAN FD.

  Da jedes Steuergerät von einem anderen Lieferanten entwickelt wird und über unterschiedliche eingebettete Software und zugrunde liegenden Code verfügt, verursacht die verteilte elektronische und elektrische Architektur viel Redundanz und Stücklistenkosten auf Fahrzeugebene. Da die fahrzeuginterne Software auf verschiedene Steuergeräte verteilt ist und die Steuergeräte von jedem Zulieferer unabhängig fertiggestellt werden, sind ihre Software und Hardware außerdem eng miteinander verbunden, und der OEM hat nicht die Befugnis, die Software auf dem Steuergerät zu warten und zu aktualisieren .

  Die schnelle Erfüllung der Benutzerbedürfnisse ist für OEMs der Schlüssel zur Eroberung von Marktanteilen, und die verteilte elektronische und elektrische Architektur schränkt die Geschwindigkeit, mit der OEMs auf die Marktnachfrage reagieren können, erheblich ein. Angenommen, der Benutzer schlägt vor, nach Abschluss des Entwurfs eines bestimmten Automodells eine Fahrerpositionsspeicherfunktion hinzuzufügen, d Sie können sie als Memory-Positionen festlegen, um spätere schnelle Anpassungen zu ermöglichen. Softwareänderungen müssen an mehreren Komponenten wie Türsteuerungen, Sitzsteuerungen, Lenkradsteuerungen und Gateways vorgenommen werden. Erst nachdem jeder Komponentenlieferant die Änderungen abgeschlossen hat und der OEM die Integrationstests und Fahrzeugtests abgeschlossen hat, können neue Funktionen geändert werden auf den Markt gebracht werden, was zu Problemen wie langen Entwicklungs- und Änderungszyklen und hohen Kosten führen wird.

  Zu diesem Zweck haben verschiedene Automobilhersteller bereits damit begonnen, neue elektronische und elektrische Architekturlösungen zu reservieren, um die schnelle Implementierung softwaredefinierter Autos zu fördern. Die besonderen Merkmale der neuen elektronischen und elektrischen Architektur sind die Zentralisierung der Funktionen (Software) und die Standardisierung der Hardware. Die einheitliche Verwaltung von Steuerungsfunktionen über eine zentrale Computerplattform/Domänencontroller reduziert Hardware-Redundanz und Stücklistenkosten und verringert so die Abhängigkeit des OEM von zahlreichen Lieferanten. Neue elektronische und elektrische Architekturen werden je nach Grad der Funktionskonzentration hauptsächlich in drei Typen unterteilt.

  Der erste Typ: Domänenzentralisierte Elektronik- und Elektroarchitektur

  In der Domänenzentralisierten Elektronik- und Elektroarchitektur sind die elektronischen und elektrischen Steuerfunktionen des Fahrzeugs in N Funktionsdomänen unterteilt, für die jeweils eine Domäne entworfen wird Funktionsdomäne Die anderen Controller sind domäneninterne Controller, und die Controller in jeder Domäne sind im Allgemeinen intelligente Sensoren, Aktoren und herkömmliche Controller.

  Das schematische Diagramm der domänenzentrierten elektronischen und elektrischen Architektur ist in der folgenden Abbildung dargestellt. Im Beispiel sind die elektronischen und elektrischen Steuerfunktionen des Fahrzeugs in fünf Funktionsbereiche unterteilt: Leistungsbereich, Fahrwerkssicherheitsbereich, intelligentes Fahren Domäne, Infotainment-Domäne und Körperkomfort-Domäne.

  

  Abbildung 7 Schematische Darstellung der domänenzentralisierten elektronischen und elektrischen Architektur

  Zweiter Typ: domänenübergreifende zentralisierte elektronische und elektrische Architektur

  In der domänenzentralisierten elektronischen und elektrischen Architektur Domäne Steuerung Der Controller ist nur für die zentrale Steuerung von Funktionen in einer Domäne verantwortlich. In der domänenübergreifenden zentralisierten elektronischen und elektrischen Architektur sind einige Domänencontroller für die zentrale Steuerung von Funktionen in zwei oder mehr Domänen verantwortlich, wodurch die funktionale Integration weiter verbessert wird das System. Die gebräuchlichere domänenübergreifende zentralisierte elektronische und elektrische Architektur ist die Drei-Domänen-Architektur. Das schematische Diagramm der domänenübergreifenden zentralisierten elektronischen und elektrischen Architektur ist in der folgenden Abbildung dargestellt.

  

  Abbildung 8 Schematische Darstellung der domänenübergreifenden zentralisierten elektronischen und elektrischen Architektur

  Die Drei-Domänen-Architektur ist die Fahrzeugsteuerungsdomäne, die Domäne des intelligenten Fahrens und die Domäne des intelligenten Cockpits. Sie kombiniert das Original Der Leistungsbereich, der Fahrwerkssicherheitsbereich und der Karosseriekomfortbereich sind in den Fahrzeugsteuerungsbereich integriert, und der intelligente Fahrbereich und der intelligente Cockpitbereich konzentrieren sich auf die Realisierung von Fahrzeugintelligenz und Konnektivität.

  Die Drei-Domänen-Architektur verfügt über 3 Domänencontroller:

  Der Fahrzeugdomänencontroller ist für die Fahrzeugsteuerung verantwortlich und stellt hohe Echtzeit- und Sicherheitsanforderungen.

  Der intelligente Fahrdomänencontroller ist für die autonome Steuerung verantwortlich fahrbezogene Wahrnehmungen, Planung und entscheidungsbezogene Funktionsimplementierung;

  Der intelligente Cockpit-Domänencontroller ist für die HMI-Interaktion und die Cockpit-bezogene Funktionsimplementierung verantwortlich.

  Der dritte Typ: regionaler Zugang + zentralisierte elektronische und elektrische Architektur

  Die zentralisierte elektronische und elektrische Architektur verteilt die elektronischen und elektrischen Systeme im Fahrzeug nicht mehr funktionsgerecht, sondern konzentriert die Steuerlogik aller Funktionsbereiche des Fahrzeugs auf der zentralen Rechenplattform und verbessert so die Systemfunktionsintegration weiter. Die Steuerungs-/Rechenfunktionen von Steuergeräten in den ursprünglichen verteilten und domänenzentrierten Architekturen werden von der zentralen Rechenplattform übernommen und in einfachere Sensoren oder Aktoren umgewandelt.

  Um die Länge des Kabelbaums zu reduzieren, die Kommunikation zu vereinfachen, Zugang und Stromversorgung in der Nähe zu ermöglichen, können im Rahmen der zentralisierten Architektur Bereiche nach physischen Standorten unterteilt und regionale Controller innerhalb des Bereichs eingesetzt werden, um einen zu bilden Zentrale Rechenplattform und mehrere regionale Controller-Architektur. Das schematische Diagramm der zentralisierten elektronischen und elektrischen Architektur ist in der folgenden Abbildung dargestellt.

  

  Abbildung 9 Schematische Darstellung einer zentralisierten elektronischen und elektrischen Architektur

  Bei der Aktualisierung der Hardwarearchitektur müssen auch die Integration domänenübergreifender Funktionen, die Schichtung von Softwarefunktionen unter der SOA-Architektur und der Postservice berücksichtigt werden Steuerung in Echtzeit, funktionales Sicherheitsdesign, komplexes Hardware-Design und -Integration und mehr.

  2 Sicherheits-Upgrade: Aufbau eines mehrschichtigen Fahrzeug-Tiefenverteidigungssystems

  2.1 Funktionale Sicherheit

  Mit der kontinuierlichen Verbesserung der elektronischen und elektrischen Architekturtechnologie werden immer mehr Systeme und Komponenten entwickelt des Fahrzeugs einbezogen werden. Sie haben Auswirkungen auf die funktionale Sicherheit. Aus diesem Grund hat sich die funktionale Sicherheit auch von der Entwicklung einiger Schlüsselsysteme auf die umfassende Entwicklung aller Systeme im gesamten Fahrzeug ausgeweitet.

  Gleichzeitig stellt das Aufkommen neuer Architekturtechnologien wie Domänencontroller und zentrale Computerplattformen neue technische Herausforderungen für die funktionale Sicherheit dar. Die funktionale Sicherheit muss Entwicklungs- und Bewertungsmethoden für diese komplexen Systeme und Software etablieren.

  Funktionale Sicherheitstechnologie beeinflusst auch die Entwicklung der elektronischen und elektrischen Architekturtechnologie, indem sie sich von der traditionellen ausfallsicheren (Fail-Safe) zur ausfallsicheren (Fail-Operational) Technologie entwickelt, und es wird mehr Redundanz in das Design von elektronischen und elektrischen Architekturen eingeführt elektrische Architektur (z. B. Kommunikationsredundanz, redundante Controller usw.) und Sicherheitsmaßnahmen.

  Zukünftig wird die Bildung eines intelligenten Fahrzeugökosystems die funktionale Sicherheitstechnologie fördern, die über Fahrräder hinausgeht und sich auf die gesamte Verbindung ausdehnt, um die Gesamtsicherheit des gesamten intelligenten Ökosystems zu erreichen.

  2.2 Voraussichtliche funktionale Sicherheit

  Voraussichtliche funktionale Sicherheit in Bezug auf elektronische und elektrische Architektur bezieht sich auf die Vermeidung von Personengefahren, die durch unzureichende Funktionen oder vernünftigerweise vorhersehbare Fehlbedienungen durch Menschen verursacht werden. Funktionale Sicherheitstechnik wird voraussichtlich Teil der Automobiltechnik sein und der entsprechende Standard ist ISO 21448. Analysieren Sie auf der Grundlage der autonomen Fahrfunktion und ihres Betriebsdesignbereichs das Systemkonfigurationsschema, das die erwarteten Anforderungen an die funktionale Sicherheit erfüllt, und bestimmen oder wählen Sie das geeignete elektronische und elektrische Architekturschema basierend auf dem Systemkonfigurationsschema aus. Wichtige technische Punkte der erwarteten funktionalen Sicherheit:

  (1) Technologie zur Formulierung von Sicherheitskriterien für autonomes Fahren: Entwicklung objektiver quantitativer Kriterien für die Sicherheitsleistung des autonomen Fahrens in bekannten und unbekannten Szenarien, um das Sicherheitsniveau des autonomen Fahrens wissenschaftlich zu bestimmen;

  (2) Sicherheitsanalysetechnologie: Durch Sicherheitsanalysemethoden wie STPA die unzureichenden Leistungseinschränkungen und Gefahren auslösenden Bedingungen von sicherheitsrelevanten Funktionen des autonomen Fahrens identifizieren, gezielte Maßnahmen formulieren und Funktionsaktualisierungen durchführen
  (3 ) Multi-Säulen-Ansatz Testtechnologie: Erwartetes Testsystem für die funktionale Sicherheit des autonomen Fahrens, bestehend aus Simulationstests, festgelegten Szenariotests und realen Straßentests
  (4) Sicherheitsdemonstrationstechnologie: Basierend auf den Ergebnissen der Sicherheitsentwicklung, -analyse und -tests; usw., entwickeln Sie die erwartete funktionale Sicherheitsdateistrategie, bewerten Sie durch GSN und andere Demonstrationsmethoden die Sicherheitsrisiken des autonomen Fahrens und vervollständigen Sie die erwartete funktionale Sicherheitsfreigabe
  (5) Sicherheitsüberwachungstechnologie: Überwachen Sie die Sicherheitsleistung während des Betrieb des autonomen Fahrens und Identifizierung von Sicherheitsrisiken durch Bord- und Fernmittel sowie Durchführung notwendiger Risikokontrollmaßnahmen, um den sicheren Betrieb des autonomen Fahrens zu gewährleisten.

  2.3 Netzwerksicherheit

  Intelligente Autoterminals, Kommunikationspipelines, Cloud-Plattformen und mobile Anwendungen sind alle einer Reihe von Bedrohungen für die Informationssicherheit ausgesetzt. Ausgehend von der Dimension des Automotive-Netzwerkraums werden durch vielfältige technische Kooperationen, verschiedene Mittel, die sich gegenseitig ergänzen, und die mehrstufige Bereitstellung von Sicherheitsverteidigungslinien von außen nach innen die Anforderungen an Tiefe, Ausgewogenheit und Integrität des Schutzes der Fahrzeuginformationssicherheit erfüllt erfüllt werden kann. Aus Sicht der Netzwerksicherheit, Intranetsicherheit und Steuergerätesicherheit ist es notwendig, entsprechende Schutzmaßnahmen auf Basis der elektronischen und elektrischen Fahrzeugarchitektur der neuen Generation zu implementieren und einzusetzen. Abbildung 10: Umfassender Netzwerksicherheitsschutz für intelligente Autos , Täuschung, Trojaner und andere Netzwerkangriffe. Es ist erforderlich, über die aktive Sicherheitsschutzfunktion des Auto-Cloud-Verbindungsmechanismus zu verfügen, und die Schutzstrategie kann in Echtzeit über das Cloud-System konfiguriert werden, das hauptsächlich Zugangsauthentifizierungsmechanismen, Kommunikationsschutzmechanismen, Ethernet-Firewall-Mechanismen und Einbruchserkennung umfasst und Präventionsmechanismus (IDPS).

  

  Netzwerksicherheit im Fahrzeug

  Die Netzwerksicherheit im Fahrzeug widersteht hauptsächlich Angriffen auf Fahrzeug-CAN/CAN-FD und Fahrzeug-Ethernet, einschließlich Angriffen wie Nachrichtenüberwachung, Fehlerinjektion und Nachrichtenwiedergabe. Zu den Schutzstrategien gehören: Bus-Intrusion-Detection-Mechanismus, Intranet-Firewall-Mechanismus, funktionaler Domänenisolationsmechanismus, Bus-Kommunikationsschutzmechanismus und diagnostischer Sicherheitsschutzmechanismus.

  Schlüssel-ECU-Sicherheit

  Um sicherzustellen, dass das Fahrzeugsystem oder Schlüsseldaten nicht zerstört werden, muss die Schlüssel-ECU-Ebene des Fahrzeugs über Sicherheitsfunktionen für einen sicheren Start, eine sichere Speicherung von Schlüsseldaten usw. verfügen Sicherer Systembetrieb und kann für Anwendungen verwendet werden, die ausgeführt werden, um Berechtigungsverwaltungsfunktionen bereitzustellen.

  Dienstsicherheit

  Das SOA-Sicherheitsframework muss fünf Grundprinzipien folgen: Vertraulichkeit, Integrität, Authentizität, Autorisierung und Verfügbarkeit, durch Informationsverschlüsselung, digitale Signaturen, Passwortauthentifizierung und Entwurf von Zugriffskontrolllisten. Verschiedene Lösungen und Produkte wie ACL- und DOS-Angriffsüberwachung sorgen für Netzwerksicherheit und stellen gleichzeitig sicher, dass diese Netzwerkinformationen erkannt, abgerufen, kommuniziert und überwacht werden können.

  Abbildung 11 Sicherheitsprinzipien für Fahrzeug-SOA-Dienstnetzwerke

  Stellen Sie bei der Diensterkennung den Isolationsmechanismus für Informationssicherheitsgruppen so ein, dass Dienst-Broadcast-Nachrichten nur an Dienstbenutzer gesendet werden, die sie benötigen.

  In Bezug auf den Dienstzugriff richten Sie Mechanismen zur Informationssicherheitszugriffskontrolle für Dienstanbieter ein, authentifizieren und autorisieren von Dienstbenutzern initiierte Dienstanfragen.

  Bestimmen Sie in Bezug auf die Dienstkommunikation SOA basierend auf den tatsächlichen Geschäftsanwendungsszenarien von SOA-Diensten Der Informationssicherheitsübertragungsmechanismus, den Nachrichten verwenden sollten.

  Richten Sie im Hinblick auf die Dienstüberwachung einen Dienstsicherheitsüberwachungsmechanismus ein, um abnormale Ereignisse im Zusammenhang mit SOA-Diensten zu erkennen, und einen Sicherheitsreaktionsverarbeitungsmechanismus.

  3 Prozessänderung: Agile Entwicklung, iterative Veröffentlichung
  Die Funktionen des Autos ändern sich mit jedem Tag und die Menge an Softwarecode nimmt von Tag zu Tag zu. Die Wasserfallentwicklung unter dem traditionellen V-Modell Um Kunden schnell beliefern zu können, ist die Umstellung des Softwareentwicklungsprozesses von entscheidender Bedeutung. Derzeit setzen immer mehr Automobilzulieferer auf agile Entwicklung. Basierend auf der Systemarchitektur zur Erzielung einer Software- und Hardware-Entkopplung und einer hierarchischen Architektur aus Systemsoftware, Middleware und Anwendungssoftware kann eine schnelle Iteration und Freigabe von Softwarefunktionen erreicht werden, sodass OEMs den Markt schnell erobern können.

  • Der Kern des agilen Entwicklungsprozesses besteht darin, das Bewusstsein für Zusammenarbeit, Verantwortung, Qualität, Lernen und Innovation des F&E-Personals zu kultivieren und dadurch die F&E-Fähigkeiten des gesamten Software-F&E-Teams zu verbessern effiziente Entwicklung hochwertiger Software. Die Feature-Entwicklung verwendet ein iteratives Entwicklungsmodell mit einem monatlichen Entwicklungszyklus, der weiter unterteilt ist in detailliertes Design und Überprüfung, Feature-Entwicklung und Code-Lesen, Überprüfung und Bewertung der Codequalität, Testfall-Design und -Schreiben, gemeinsames Debuggen von Feature-Funktionen, Überprüfung der Feature-Integration, usw. Unterprozess. Jeder Unterprozess verfügt über spezifische Ergebnisse (Designdokumente, Quellcode, Überprüfungsberichte, Testfälle, Testberichte usw.) und ein quantitatives Bewertungssystem (Vollständigkeit der Designdokumentkapitel, inkrementeller Code-Messbericht, Überprüfungsmeinungsdichte, Testfallabdeckung). , Fehlerdichte usw.), stellen Sie sicher, dass jeder Teilprozess in Übereinstimmung mit den Qualitätsanforderungen der Softwareentwicklung durchgeführt wird, und archivieren Sie alle Dokumente, um die Rückverfolgbarkeit der Softwarequalität zu unterstützen.

    Die Versionsveröffentlichung verwendet ein schnelles Iterationsmodell von Softwareversionen mit einem wöchentlichen Veröffentlichungszyklus. Jede Woche werden Versionen aus stabilen Zweigen veröffentlicht, um die Grundfunktionen und neuen Features vollständig zu überprüfen die Software, führen Sie Regressionstests für die gelösten Probleme durch und geben Sie die Version frei, nachdem alle Probleme behoben sind. Der Geschäftswert der agilen Entwicklung:

    • Benutzererfahrungen können monatlich veröffentlicht werden.
    • Fehler und Patches werden wöchentlich schnell veröffentlicht.
    • Die Softwareversion wird stündlich iteriert, wobei Komponenten und das Fahrzeug synchron integriert und automatisch verifiziert werden (7*24h unbeaufsichtigt).

    4 Tool-Chain-Upgrade: Entwicklung von Fahrzeugservices auf Basis von SOA

    SOA Der General Die Idee besteht darin, ein Dienstmodell zu entwerfen, verschiedene Basisdienste zu extrahieren, geeignete API-Schnittstellen durch hierarchische Entkopplung zu definieren und die Anwendung zum Aufrufen von Dienst-API-Schnittstellen zu verwenden, um Geschäftslogik zu implementieren. Die Definition der API-Schnittstelle ist unabhängig von der Hardwareplattform, dem Betriebssystem und der Programmiersprache, die den Dienst implementiert, und stellt sicher, dass in verschiedenen Systemen erstellte Dienste auf einheitliche und universelle Weise interagieren können.

    Für die Automobilindustrie ist SOA eine neu eingeführte Technologie, die ein effektives Set an Prozessen, Methoden und Werkzeugketten erfordert. Die drei ergänzen sich derzeit Es gibt noch keine sehr ausgereifte Methodik und Toolkette, und die meisten OEMs und Tier1/Tier2 befinden sich in der Erkundungsphase. Die folgende Abbildung zeigt eine servicebasierte Funktionsentwicklungsprozessmethode.

    

    Abbildung 12 Servicebasierte Funktionsentwicklungsprozessmethode # 🎜🎜#

    Führen Sie zunächst eine Bedarfsanalyse für die Funktion durch, geben Sie die Szenariodefinition und das Feature-Design sowie die entsprechende physische Topologie und Modulfunktionsdefinition aus. Fahren Sie dann mit dem Systemdesign einschließlich der Servicearchitektur fort Design, Servicedesign und Kommunikationsdesign muss die Servicedefinition auf der API-Schnittstellen-Referenzspezifikation basieren, die von der Software-Defined Automotive Working Group der China Association of Automobile Manufacturers veröffentlicht wurde.

    5 Verbesserung der industriellen Arbeitsteilung: vernünftige Arbeitsteilung, offene Zusammenarbeit

    Angesichts der Zukunft von intelligenten Autos, mit Während die ursprüngliche industrielle Wertschöpfungskette zu brechen beginnt, transformieren sich traditionelle Automobilunternehmen nacheinander, neue Kräfte entstehen, der technologische Fortschritt verändert sich mit jedem Tag und grenzüberschreitende Akteure dringen in die Branche ein Elemente und Formen des industriellen Wettbewerbs verändern sich stillschweigend, was einerseits die Bildung eines neuen Industriemusters vorantreibt, andererseits aber auch die Entstehung einer neuen industriellen Ökologie hervorbringt. Die Smart-Car-Industrie entwickelt sich in eine vielfältigere und komplexere Richtung, mit vielen neuen Technologiefeldern, die noch nie zuvor involviert waren. Nur eine offene Zusammenarbeit kann Win-Win-Ergebnisse erzielen und komplementäre Vorteile können Synergien schaffen.

    5.1 Gesamtempfehlungen

    Wie bereits erwähnt, die Automobilindustrie Mit der Weiterentwicklung hin zu Elektrifizierung und Intelligenz treiben Technologie und Benutzererfahrung das rasante Wachstum der Automobilindustrie voran. Mit der schrittweisen Weiterentwicklung intelligenter Autos nimmt auch die Komplexität der Fahrzeugsoftware und -hardware weiter zu. Die Umstellung auf softwaredefinierte Autos ist jedoch noch in den Kinderschuhen. Die groß angelegte Einführung von Software stellt die Automobilindustrie vor große Herausforderungen – von Design und Entwicklung bis hin zu Integration, Tests, Freigabe und Wartung. Nur wenn wir die Komplexität der Software- und Hardwarekombination richtig bewältigen, können wir weiterhin die Erlebnisbedürfnisse der Verbraucher erfüllen und die Wettbewerbsfähigkeit auf dem Markt stärken.

    Die geschichtete Entkopplung ist ein wichtiges Mittel zur Verbesserung der Wiederverwendbarkeit von Software und zur Reduzierung der Komplexität der Software- und Hardware-Entwicklung. Sie ist auch der einzige Weg zu softwaredefinierten Autos. Durch die geschichtete Entkopplung können Software und Hardware getrennt und Anwendungen von der Basisplattform getrennt werden. Allerdings ist die Umsetzung zu einer zentralen Herausforderung geworden und wird sich direkt auf die strategischen Ziele und den Wert softwaredefinierter Autos auswirken. Aus technischer Sicht sind die wichtigsten Herausforderungen die Frage, wie man die Architektur schichtet und wie man Dienste aufteilt, um die Wiederverwendung zu maximieren, Entwicklung, Wartung und langfristige Weiterentwicklung zu vereinfachen. Nur eine vernünftige, stabile und einheitliche Serviceabteilung kann sicherstellen, dass der Wert softwaredefinierter Autos maximiert wird. Aus Sicht der Industriekette ist die Art und Weise, wie alle Parteien sich positionieren, die Arbeit aufteilen und zusammenarbeiten, um die größtmöglichen Interessen aller Parteien zu gewährleisten, die Grundlage für die schnelle Implementierung softwaredefinierter Prozesse Autos.

    Gesamtempfehlung:

    Stärkung der Automobilindustrie unter den Gesichtspunkten der Einheitlichkeit technischer Spezifikationen und sinnvoller Aufteilung der Arbeitskräfte in der Branche Vor- und nachgelagerte Unternehmen in der Kette kooperieren und arbeiten zusammen, um gemeinsam die Standardisierung von Software- und Hardwareschnittstellen für intelligente Autos voranzutreiben, atomare Dienst- und Geräteabstraktionsschichten aufzubauen und eine hierarchische Entkopplung von Anwendungen, Basisplattformen und Hardware zu realisieren Service-Architektur und Schnittstellenstandardisierung und -vereinheitlichung, um modellübergreifendes Erreichen zu erreichen, die Wiederverwendung über Teilelieferanten hinweg zu maximieren, Anpassungen zu reduzieren, Innovationen zu beschleunigen und die kollaborative Effizienz der Smart-Car-Branche zu verbessern. Gleichzeitig wird in Kombination mit den Anforderungen und Vorteilen aller Parteien in der Industriekette auf der Grundlage der hierarchischen Struktur eine angemessene Arbeitsteilung gebildet, um eine vollständige Zusammenarbeit zu erreichen.

    Spezifische Vorschläge:

    • Realisieren Sie in der Geräteabstraktionsschicht die Lösung von Geräten und Ports Kopplung, Abschirmung von Hardware-Funktionsunterschieden und Herstellerunterschieden, und diese Schicht wird von der Industrie gemeinsam definiert und schirmt die Unterschiede zwischen Geräten und Treibern ab; Die atomare Dienstschicht, der Dienst und die Plattform sind entkoppelt, um die Wiederverwendbarkeit der Software zu verbessern. Diese Schicht wird von der Industrie gemeinsam definiert und standardisiert Schicht, Anwendungen und Dienste werden entkoppelt, Anwendungen werden fahrzeugmodellübergreifend wiederverwendet und die Erfahrung wird fokussiert. Es wird empfohlen, dass diese Schicht von OEMs geleitet wird.
    • Abbildung 13 Gesamtempfehlungen für die softwaredefinierte Zusammenarbeit in der Automobilindustrie #🎜🎜 ## 🎜🎜#
    • Gleichzeitig bedeutet API-Standardisierung nicht eine Homogenisierung des Branchenwettbewerbs, Offenheit bei Standards und Wettbewerb bei Produkten. OEMs und Teilelieferanten können hierarchisch die Kernwettbewerbsfähigkeit in Schlüsseltechnologien aufbauen, gemeinsam Managementfähigkeiten aufbauen, um Effizienz und Skalierbarkeit zu verbessern, und Schutzmechanismen in Geschäftsmodellen einbauen, um Exklusiv-/First-Mover-Vorteile zu gewährleisten und so letztlich den Benutzern einzigartige, entwicklungsfähige und einzigartige Produkte anzubieten Produkte mit höherer Wertschöpfung.

    Gleichzeitig sind Hardware, Software, Plattformen usw. verschiedener Hersteller interoperabel, d. h. unterschiedliche Modelle und unterschiedliche Komponenten können zur Vervollständigung dieselbe Sprache verwenden domänenübergreifende Anrufe und Austausche. Und die Möglichkeit, Informationen auszutauschen, kommt jedem Unternehmen in der Industriekette zugute.

    Für OEMs:

    Einfacher zu verwalten: hin zu einem objektorientierten Softwareverwaltungsmodell Durch die Transformation erleichtert die Software Onetrack die Verwaltung komplexerer Fahrzeugsoftwaresysteme und -lieferanten und kann sich auf Integrationsfähigkeiten konzentrieren, um die Wettbewerbsfähigkeit zu steigern. Die Softwareentwicklung kann mit Service-APIs vorintegriert werden, um die Einführung von Modellen zu beschleunigen.

    Für Teilelieferanten:

    Anpassungen reduzieren: Komplexe Arbeit reduzieren das keinen Mehrwert schafft, reduziert die Entwicklungs- und Wartungskosten für verschiedene Modelle;

    • Innovation beschleunigen: Talente freisetzen, um sich auf Innovation zu konzentrieren und differenzierte Technologien und Produkte zu entwickeln.
    • Für Softwareentwicklungsunternehmen/-entwickler:

    Einfacher zu bekommen begonnen: Leicht zu verstehen, Entwicklungsressourcen zu integrieren und sich schnell zu entwickeln; den Post-Market-Wert und bringen mehr Chancen. Mehr Raum für die Verwirklichung.

    5.2 OEM

    • OEMs wenden sich direkt an Endverbraucher, stellen Automobilprodukte bereit, die den Anforderungen der Benutzer entsprechen, integrieren Software und Hardware, Anwendungsfunktionen und ökologische Dienstleistungen, um die Lieferung kompletter Fahrzeugfertigungen bis hin zu langfristigen Reisedienstleistungen zu vervollständigen.

      Automobilhersteller sind nicht nur Hersteller von Autos, sondern bieten Verbrauchern auch mobile reisebezogene Dienstleistungen an und erfüllen die unterschiedlichen Autobedürfnisse der Benutzer durch Softwareentwicklung, Konfiguration und iterative Upgrades. Benutzer können über die Software verschiedene Funktionen von Automobilprodukten einstellen und sogar Reiseszenen bearbeiten oder bestimmte Szenenfunktionen entsprechend ihren persönlichen Vorlieben herunterladen. Zu diesem Zweck müssen OEMs den Aufbau und die Entwicklung der folgenden Plattformen abschließen:

      1) Hardware-Plattform-Integration

      Die Hardware-Plattform ist die Basis für softwaredefinierte Autos. In dieser Phase ist die Elektronik und elektrische Architektur, die von jedem OEM geplant wird. Es gibt drei Haupttypen: zentralisierte Funktionsdomäne, domänenübergreifende Integration und zentrale Computerdomäne + regionaler Zugriff. Um den Anforderungen intelligenter Autos und softwaredefinierter Autos gerecht zu werden, werden in Zukunft ein zentraler Rechenbereich und ein regionaler Zugang die gängige elektronische und elektrische Architektur sein. OEMs müssen die Funktionen jeder Domäne und die Schnittstellen für regionale Zugangshardware entsprechend ihren eigenen Bedingungen sinnvoll zuweisen.

      2) Software-Integration

      Fahrzeughersteller müssen über Software-Integrationsfunktionen verfügen, ein „Software-Center“ oder „User Experience Center“ aufbauen und eine entsprechende Organisationsstruktur einrichten, um die Fähigkeiten zur Entwicklung von Fahrzeugsoftware zu verbessern.

      Die erste Stufe: Konzentrieren Sie sich auf Software der Fahrzeugsteuerungsanwendungsebene und Software, die stark mit der Benutzererfahrung zusammenhängt, um Markenmerkmale zu formen und die Benutzerbindung zu verbessern. Erstellen Sie eine Softwareentwicklungsumgebung und verfolgen Sie den Softwareentwicklungsprozess, z. B. den Import von AUTOSAR-Spezifikationen usw., um eine Entkopplung der Software auf der Anwendungsebene und der Lieferantenhardware auf der Entwicklungsebene zu erreichen. Nachdem die Software auf der Anwendungsebene gekapselt wurde, wird sie an die übergeben Für die Integration und Konfiguration können mehrere Hardware-Anbieter angegeben werden, ohne dass die Anwendungsschicht geöffnet werden muss. Gleichzeitig können wir mit ökologischen Dienstleistern zusammenarbeiten, um Software von Drittanbietern in die Anwendungsschicht einzubetten. Nachdem die Anwendungsschicht unabhängig gesteuert wurde, kann sie schnell übertragen werden, die Entwicklungseffizienz verbessern und eine Grundlage für die kontinuierliche Iteration von Funktionen und häufige Aktualisierungen für Benutzer bieten. OTA ist der Kernkanal und die erste Phase der Implementierung ist der erste Schritt hin zu softwaredefinierten Autos.

      Die zweite Stufe: Durch den Kauf von Konfigurationstools schrittweise die Integration der Anwendungsschicht und der unteren Ebene realisieren. Der Hardwarelieferant stellt eine „White Box“ für die Integration und das Flashen beim OEM bereit. Verwirklichen Sie die echte Entkopplung von Software und Hardware, erweitern Sie den Umfang der Hardwarebeschaffung und senken Sie die Beschaffungskosten. Die zugrunde liegenden Konfigurationsfunktionen erfordern jedoch hohe Investitionen von OEMs, und OEMs werden aufgrund ihrer eigenen Fähigkeiten überlegen, ob sie in das Spiel einsteigen.

      Die dritte Stufe: Beginnen Sie schrittweise mit der unabhängigen Entwicklung der Hardware und der zugrunde liegenden Schichten. Reduzieren Sie die Fahrzeugkosten durch Hardware, wählen Sie Kernchips unabhängig aus, durchbrechen Sie die Einschränkungen von Hardwareplattformen und führen Sie eine modulare Softwaretransplantation basierend auf der Fahrzeugkonfiguration und den Funktionsanforderungen basierend auf Kosten und Kundenerfahrung durch.

      3) Aufbau einer offenen Plattform

      Die traditionelle Automobilentwicklung basiert vollständig auf der Philosophie der Ingenieure der Automobilfabrik und ist ein Entwicklungsmodell, das Kunden über Kunden stellt. Basierend auf dem neuen Modell der Win-Win-Situation, Symbiose und Co-Kreation kann die offene Plattform die Beziehung zwischen Lieferanten, Fahrzeugen und Nutzern unter der neuen Situation lösen.

      Die offene Plattform kann Fahrzeugentwicklungsingenieuren, Dritten und Benutzern umfassende Fahrzeugfähigkeiten bieten. Diese Fähigkeiten umfassen einige zugrunde liegende Hardwarefähigkeiten, Softwarefähigkeiten, Daten und Informationen. Basierend auf diesen Fähigkeiten können vielfältige Lösungen gefunden werden Software bietet Benutzern maßgeschneiderte, personalisierte und abonnementbasierte Dienste, die einen Mehrwert für Benutzer und OEMs schaffen und auch eigene Vorteile bringen. Ermöglichen Sie Benutzern, sich an der Entwicklung von Fahrzeugsoftware zu beteiligen und tatsächlich softwaredefinierte Autos zu realisieren.

      Durch die offene Plattform können Hunderttausende Hardwaremodule im Auto genutzt werden, die stärkere Wahrnehmungsfähigkeiten, mehr Anwendungsszenarien, eine größere Abdeckung und längere Lebenszyklen als Mobiltelefone bieten können, so das Automotive-Ökosystem breiter als das Mobiltelefon-Ökosystem, offener als Mobiltelefone und näher am Benutzer.

      5.3 Teilelieferant

      Für traditionelle Teilelieferanten haben OEMs im Zuge des Entwicklungstrends softwaredefinierter Autos ein zunehmendes Mitspracherecht bei der Entwicklung von Systemfunktionen. Mit Hilfe der Software- und Hardware-Entkopplung und der Implementierung der SOA-Architektur werden OEMs auch nach und nach für die Entwicklung verantwortlich sein der Anwendungsfunktionen einiger Zulieferer muss sich Tier 1, das traditionell auf Hardware basiert, dringend transformieren und einen neuen Ausweg finden.

      Derzeit ist die Schaffung vollständiger Software- und Hardware-Stack-Funktionen der Schlüssel zur Eroberung der nächsten großen Marktanteile. Viele Tier1-Unternehmen mit sehr umfassenden Fähigkeiten bauen „Hardware + zugrunde liegende Software + Middleware + Anwendungssoftware-Algorithmen + System“. Integration“ „Mit technischen Full-Stack-Funktionen können Kunden sowohl Hardware und Software als auch integrierte Software- und Hardwarelösungen erhalten. Allerdings erfordert ein solches Layout, dass Tier1 viel Arbeitskraft und Kapital investiert, was sich nicht alle Tier1 leisten können.

      In diesem Zusammenhang sollten Teilelieferanten Hardware-Ports weiter öffnen und die Fähigkeiten der Hardware abstrahieren. Um die Kosten für die Anpassung für verschiedene OEMs zu senken und die Liefereffizienz zu verbessern, müssen die Schnittstellen nach einheitlichen Standards geöffnet werden. um die Matching-Komplexität zu reduzieren, die Software- und Hardware-Kopplung zu reduzieren und die Flexibilität und Wiederverwendung zu verbessern. Wir arbeiten auch proaktiv mit OEMs, Softwarelieferanten und anderen Parteien zusammen, um gemeinsam ein Teileökosystem aufzubauen, um vielfältigere und reichhaltigere Gewinnszenarien zu schaffen. Unter der Prämisse von Standardschnittstellen werden Leistungsunterschiede den Teilelieferanten gleichzeitig Konkurrenz machen. Es wird auch Zulieferer zu Innovationen und Fortschritten ermutigen. Teilelieferanten sollten sich auf die internen Kernalgorithmen konzentrieren und durch Optimierung und Aktualisierung interner Algorithmen und Codes Differenzierung und kontinuierliche Weiterentwicklung von Leistung und Erfahrung erreichen. Und durch die Zusammenarbeit mit IT-Unternehmen in den Bereichen Automobilhersteller, künstliche Intelligenz, Software und anderen Bereichen können wir die neuesten Bedürfnisse und Entwicklungsrichtungen verstehen, unsere eigene F&E-Richtung und -Fähigkeiten anpassen, uns auf Hardware stützen und das gesammelte Branchenwissen nutzen -Wie Vorteile beim Aufbau von Anwendungsfunktionssoftwarefunktionen entstehen, die Rückmeldungen geben und differenzierte Hardwareverkäufe vorantreiben, ist die Wahl vieler Teilelieferanten.

      5.4 Basisplattformanbieter

      Angesichts der Ära softwaredefinierter Autos besteht das Ziel der Basisplattformhersteller darin, ihre eigene IKT-Technologieakkumulation und Vorteile zu nutzen, um OEMs bei der Entwicklung differenzierter Lösungen zu unterstützen, die für ihre eigene Planung geeignet sind des gesamten Fahrzeugs Die elektronische und elektrische Architektur der nächsten Generation reduziert die Komplexität der Forschung und Entwicklung von Smart Cars, verbessert die Effizienz und beschleunigt die Entwicklung von Smart Cars.

      Aber das aktuelle Lieferkettenmodell von OEMs zu First-Tier-Lieferanten, Second-Tier-Lieferanten und Third-Tier-Lieferanten wird immer unschärfer, und Automobilunternehmen hoffen zunehmend, mehr Inhalte zu dominieren. Dies zwingt Anbieter grundlegender Plattformen Mit einer offeneren Haltung Grenzen überschreiten, sich auf die eigenen vorteilhaften Produkte konzentrieren, offene API-Schnittstellen für obere und untere Hardware und Anwendungssoftware bereitstellen und eine sichere und vertrauenswürdige Betriebsumgebung sowie eine benutzerfreundliche Serviceentwicklung und -überprüfung für funktionale Software bereitstellen . Werkzeugkette.

      Es wird empfohlen, dass Basisplattformanbieter OEMs eine Architektur für die nachhaltige Weiterentwicklung intelligenter Autos bereitstellen. Das Designkonzept sollte auf den Menschen ausgerichtet sein und weiterhin Innovationen rund um das Benutzererlebnis und den Geschäftserfolg des OEMs ermöglichen. 5.5 Softwareanbieter/Softwareentwickler Nehmen Sie die Funktionen des interaktiven Cockpit-HMI-Systems zurück, z. B. UI/UX-Designtools, Spracherkennungsmodule, Soundeffektmodule und Gesichtserkennungsmodule, und erwerben Sie Softwarelizenzen direkt von Softwarelieferanten, umgehen Sie so die traditionelle Ebene 1 und erreichen Sie Autonomie . Entwicklung.

      Mit der Weiterentwicklung der Software-Defined-Car-Revolution werden Automobil-Hardwaresysteme nach und nach standardisiert, und Software ist der am schnellsten iterative, am einfachsten zu personalisierende und differenzierende Teil des Autos. Gleichzeitig wird Software auch die Hardware steuern Innovation. 2. Die einen ergänzen sich. Für Softwarelieferanten gilt: Je mehr Software-IP-Produktportfolios sie anbieten können, desto wahrscheinlicher ist es, dass sie einen höheren Fahrzeugwert erzielen.

      Gleichzeitig versuchen Softwareanbieter auch, in die von der traditionellen Tier1 kontrollierten Hardware-Design- und Fertigungsverbindungen wie Domänencontroller, T-BOX usw. einzusteigen, um vielfältige Lösungen anzubieten. Für die Entwicklung von Smart-Car-APP-Anwendungen wird die Entwicklung von Anwendungssoftware basierend auf der Atomic Service Standard API sehr bequem und einfach zu verwenden sein. Bei Anwendungen ist es nicht erforderlich, der zugrunde liegenden Implementierung zu viel Aufmerksamkeit zu schenken und die Abhängigkeiten verschiedener Ebenen und Module zu reduzieren, ähnlich wie beim Android-basierten Entwicklungsmodell. Für unterschiedliche Personengruppen, unterschiedliche Autos und unterschiedliche Lebensszenarien werden unterschiedliche Anwendungsentwickler Anwendungen mit unterschiedlichen Funktionen, unterschiedlichen Grafiken und unterschiedlichen Erfahrungen erstellen.

      Da die Schwelle für die Anwendungsentwicklung niedriger wird, können sich mehr Softwarelieferanten/-entwickler an der Entwicklung von Automobilanwendungs-APPs beteiligen, und in der Folge wird der Wettbewerb in der Softwareentwicklung größer. Softwareanbieter sollten anhand einiger Umfragedaten die Präferenzen verschiedener Personengruppen analysieren und differenzierte, publikumsgerechte Anwendungen für verschiedene Automodelle entwickeln. Benutzer können einige Funktionen und Feature-Anwendungen entsprechend ihren tatsächlichen Bedingungen selektiv installieren. Durch verschiedene Anwendungen und Dienste können sie einige Eigenschaften ihrer eigenen Fahrzeuge definieren, um funktionale Upgrades oder personalisierte Anpassungen durch Software zu erreichen.

      Im Wettbewerbsprozess wird nicht nur sehr beliebte Anwendungssoftware auftauchen, sondern auch die Initiative und Genauigkeit der Anbieter von Anwendungssoftware zur Verbesserung von Dienstleistungen und Produkten erhöht Innovationsfähigkeiten, wodurch das Smart-Car-Anwendungsökosystem floriert.

      5.6 Branchenverbände

      Die Regierung sollte bei Vorschriften Richtlinien, Standards und andere Aspekte sollen der gesamten Automobilindustrie dabei helfen, ein angemessenes und effizientes Managementsystem einzurichten, den ordnungsgemäßen und reibungslosen Betrieb der gesamten Branche zu überwachen, weiterhin größer und stärker zu werden und einen fairen Wettbewerb in der gesamten Branche sicherzustellen.

      Richtlinien ermutigen Unternehmen, neue Technologien zu entwickeln. Beispielsweise können Unternehmen, die einen Beitrag zur Automobilindustrie geleistet oder bei bestimmten Technologien Durchbrüche erzielt haben, dafür belohnt werden, Innovationen zu teilen und zu demonstrieren . Erfolge erzielen, eine tiefe Integration von Wissenschafts- und Technologiepolitik und Wissenschafts- und Technologieinnovation erreichen, Richtlinien kontinuierlich verbessern, Feedback-Systeme verbessern, die treibende Kraft der Politik bei der Entwicklung neuer Technologien voll ausschöpfen, ein gutes Ökosystem für Automobilsoftware schaffen und nutzen Intelligente vernetzte Autos, um den intelligenten Transport sowie den Bau und die Entwicklung intelligenter Städte voranzutreiben.

      Etablieren Sie gemeinsame Schnittstellen und andere Spezifikationen, um gemeinsame Probleme auf der Grundlage von Standards zu lösen, die Verbindung und Interoperabilität von Software- und Hardwareprodukten für die Automobilindustrie zu realisieren und zu vermeiden, dass Unternehmen miteinander kämpfen Es wird empfohlen, dass Unternehmen ihre eigenen Produkte unter einer einheitlichen Schnittstelle innovieren und entwickeln, Doppelarbeit und fragmentierte Investitionen vermeiden, die Forschungs- und Entwicklungseffizienz verbessern und die Entwicklung intelligenter vernetzter Autos in meinem Land fördern.

Das obige ist der detaillierte Inhalt vonEin Artikel über die fünf Schlüsselelemente für die Implementierung softwaredefinierter Autos. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!