DE102021100155A1 - System und verfahren für dynamisches softwaremanagement - Google Patents

System und verfahren für dynamisches softwaremanagement Download PDF

Info

Publication number
DE102021100155A1
DE102021100155A1 DE102021100155.2A DE102021100155A DE102021100155A1 DE 102021100155 A1 DE102021100155 A1 DE 102021100155A1 DE 102021100155 A DE102021100155 A DE 102021100155A DE 102021100155 A1 DE102021100155 A1 DE 102021100155A1
Authority
DE
Germany
Prior art keywords
processor
task
processors
software
electronic control
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102021100155.2A
Other languages
English (en)
Inventor
Michael R. Story
Keyur R. Patel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Steering Solutions IP Holding Corp
Original Assignee
Steering Solutions IP Holding Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Steering Solutions IP Holding Corp filed Critical Steering Solutions IP Holding Corp
Publication of DE102021100155A1 publication Critical patent/DE102021100155A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • B60R16/0231—Circuits relating to the driving or the functioning of the vehicle
    • B60R16/0232—Circuits relating to the driving or the functioning of the vehicle for measuring vehicle parameters and indicating critical, abnormal or dangerous conditions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3419—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3013—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is an embedded system, i.e. a combination of hardware and software dedicated to perform a certain function in mobile devices, printers, automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3017—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is implementing multitasking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3433—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment for load management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5055—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/805—Real-time

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Quality & Reliability (AREA)
  • Mathematical Physics (AREA)
  • Computer Hardware Design (AREA)
  • Multimedia (AREA)
  • Automation & Control Theory (AREA)
  • Mechanical Engineering (AREA)
  • Stored Programmes (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Ein Verfahren für dynamisches Softwaremanagement umfasst ein Empfangen einer Leerlaufzeit und zumindest eines Aufgabenausführungsmerkmals, das jeweiligen Prozessoren eines anderen Prozessors oder mehrerer anderer Prozessoren entspricht, an einem Quellprozessor. Das Verfahren umfasst ferner ein Identifizieren eines Zielprozessors aus dem einen anderen Prozessor oder den mehreren anderen Prozessoren, welcher in der Lage ist, eine dem Quellprozessor zugehörige Aufgabe auszuführen, basierend auf der Leerlaufzeit und dem zumindest einen Aufgabenausführungsmerkmal des Zielprozessors. Das Verfahren umfasst ferner ein Übermitteln einer Aufgabenaufforderung an den Zielprozessor, welche den Zielprozessor auffordert, die dem Quellprozessor zugehörige Aufgabe auszuführen. Das Verfahren umfasst ferner ein Übermitteln von Anweisungen zur Ausführung der Aufgabe an den Zielprozessor in Reaktion auf ein Empfangen einer Übermittlung von dem Zielprozessor, welche eine Annahme der Aufgabe angibt.

Description

  • TECHNISCHES GEBIET
  • Diese Offenbarung bezieht sich auf Fahrzeugsoftwaremanagement und insbesondere auf Systeme und Verfahren für dynamisches Softwaremanagement.
  • HINTERGRUND
  • Fahrzeuge wie beispielsweise Autos, LKWs, Geländewagen, Crossovers, Minivans oder andere geeignete Fahrzeuge stellen zunehmend komplexe Technologie bereit, welche den Betreibern solcher Fahrzeuge erhöhte Funktionalität und Sicherheitsfunktionen bietet. Beispielsweise umfassen solche Fahrzeuge typischerweise eine fortgeschrittene Spiegelsteuerung, eine komplexe Motorsteuerung, Fahrerassistenzfunktionen (z.B. eine adaptive Geschwindigkeitsregelung und dergleichen), komplexe Sicherheitsfunktionen und dergleichen.
  • Während die Komplexität solcher Technologie weiterhin zunimmt, werden mechanische Fahrzeugsysteme durch komplexe elektronische Steuergeräte (ECU) ersetzt. Solche ECUs sind typischerweise mit Software programmiert, um die gewünschten Funktionen des Fahrzeugs auszuführen. ECUs kommunizieren typischerweise über verschiedene Netzwerke innerhalb solcher Fahrzeuge. Um Funktionen wie diese hierin beschriebenen bereitzustellen, können Fahrzeuge eine erhöhte Anzahl von Steuergeräten umfassen, welche dementsprechend mit zunehmend komplexer Software programmiert werden kann. Eine erhöhte Softwarefunktionalität und -komplexität kann das ECU-Durchsatzmanagement erschweren.
  • ZUSAMMENFASSUNG
  • Die Offenbarung bezieht sich allgemein auf Fahrzeugsoftwaremanagement.
  • Ein Aspekt der offenbarten Ausführungsformen umfasst ein System für dynamisches Softwaremanagement. Das System umfasst einen Quellprozessor und einen Speicher. Der Speicher umfasst Anweisungen, die bei Ausführung durch den Quellprozessor den Quellprozessor dazu veranlassen: von einem anderen Prozessor oder mehreren anderen Prozessoren eine Leerlaufzeit und zumindest ein Aufgabenausführungsmerkmal zu empfangen, das jedem jeweiligen des einen anderen Prozessors oder der mehreren anderen Prozessoren entspricht; basierend auf der Leerlaufzeit und des zumindest einen Aufgabenausführungsmerkmals des Zielprozessors einen Zielprozessor aus dem einen anderen Prozessor oder den mehreren anderen Prozessoren zu identifizieren, welcher in der Lage ist, eine dem Quellprozessor zugeordnete Aufgabe auszuführen; dem Zielprozessor eine Aufgabenaufforderung zu übermitteln, die den Zielprozessor auffordert, die dem Quellprozessor zugeordnete Aufgabe auszuführen; und in Reaktion auf ein Empfangen einer Übermittlung von dem Zielprozessor, welche eine Annahme der Aufgabe anzeigt, dem Zielprozessor Anweisungen zur Ausführung der Aufgabe zu übermitteln.
  • Ein weiterer Aspekt der offenbarten Ausführungsformen umfasst ein Verfahren für dynamisches Softwaremanagement. Das Verfahren umfasst ein Empfangen einer Leerlaufzeit und zumindest eines Aufgabenausführungsmerkmals, das jeweiligen Prozessoren eines anderen Prozessors oder mehrerer anderer Prozessoren entspricht, an einem Quellprozessor. Das Verfahren umfasst ferner eine Identifizierung eines Zielprozessors aus dem einen anderen Prozessor oder den mehreren anderen Prozessoren, der in der Lage ist, eine dem Quellprozessor zugeordnete Aufgabe auszuführen, basierend auf der Leerlaufzeit und des zumindest einen Aufgabenausführungsmerkmals des Zielprozessors. Das Verfahren umfasst ferner ein Übermitteln einer Aufgabenaufforderung an den Zielprozessor, welche den Zielprozessor auffordert, die dem Quellprozessor zugeordnete Aufgabe auszuführen. Das Verfahren umfasst ferner in Reaktion auf ein Empfangen einer Übermittlung von dem Zielprozessor, welche die Annahme der Aufgabe anzeigt, ein Übermitteln von Anweisungen zur Ausführung der Aufgabe an den Zielprozessor.
  • Ein weiterer Aspekt der offenbarten Ausführungsformen umfasst eine Vorrichtung für dynamisches Softwaremanagement. Die Vorrichtung umfasst eine erste elektronische Steuereinheit eines Fahrzeugs. Die erste elektronische Steuereinheit umfasst einen Prozessor und einen Speicher. Der Speicher umfasst Anweisungen, die bei Ausführung durch den Prozessor den Prozessor dazu veranlassen: einer zweiten elektronischen Steuereinheit des Fahrzeugs eine Leerlaufzeit und zumindest ein Aufgabenausführungsmerkmal der zweiten elektronischen Steuereinheit zu empfangen; basierend auf der Leerlaufzeit und des zumindest einen Aufgabenausführungsmerkmals der zweiten elektronischen Steuereinheit zu ermitteln, ob die zweite elektronische Steuereinheit in der Lage ist, der ersten elektronischen Steuereinheit zugeordnete Software auszuführen; in Reaktion auf eine Ermittlung, dass die zweite elektronische Steuereinheit in der Lage ist, die Software auszuführen, der zweiten elektronischen Steuereinheit eine Aufforderung mitzuteilen, die Software auszuführen; und in Reaktion auf ein Empfangen einer Übermittlung von der zweiten elektronischen Steuereinheit, welche eine Annahme der Aufforderung, die Software auszuführen, angibt, die Software auf die zweite elektronischen Steuereinheit zu flashen.
  • Diese und andere Aspekte der vorliegenden Offenbarung werden in der folgenden detaillierten Beschreibung der Ausführungsformen, der beigefügten Ansprüche und der zugehörigen Figuren offenbart.
  • Figurenliste
  • Die Offenbarung wird am besten aus der folgenden detaillierten Beschreibung verstanden, wenn sie in Verbindung mit den beigefügten Zeichnungen gelesen wird. Es wird betont, dass die verschiedenen Merkmale der Zeichnungen nach gängiger Praxis nicht maßstabsgetreu sind. Vielmehr werden die Abmessungen der verschiedenen Merkmale zur Klarheit beliebig vergrößert oder verkleinert.
    • 1 veranschaulicht allgemein ein Fahrzeug nach den Grundsätzen der vorliegenden Offenbarung.
    • 2 veranschaulicht allgemein ein dezentrales dynamisches Softwaredurchsatzmanagementsystem nach den Grundsätzen der vorliegenden Offenbarung.
    • 3 veranschaulicht allgemein eine Kommunikation zwischen elektronischen Steuereinheiten gemäß den Grundsätzen der vorliegenden Offenbarung.
    • 4A und 4B veranschaulichen allgemein Softwarearchitekturen elektronischer Steuereinheiten gemäß den Grundsätzen der vorliegenden Offenbarung.
    • 5 ist ein Ablaufdiagramm, das allgemein ein dezentrales dynamisches Softwaredurchsatzmanagementverfahren gemäß den Grundsätzen der vorliegenden Offenbarung veranschaulicht.
  • DETAILLIERTE BESCHREIBUNG
  • Die folgende Diskussion bezieht sich auf verschiedene Ausführungsformen der Erfindung. Obwohl eine oder mehrere dieser Ausführungsformen bevorzugt sein können, sollten die offenbarten Ausführungsformen nicht so interpretiert werden oder anderweitig verwendet werden, dass sie den Umfang der Offenbarung einschließlich der Ansprüche einschränken. Des Weiteren wird ein Fachmann verstehen, dass die folgende Beschreibung eine breite Anwendung hat und die Diskussion einer Ausführungsform nur beispielhaft für diese Ausführungsform sein soll und nicht bedeuten soll, dass der Umfang der Offenbarung einschließlich der Ansprüche auf diese Ausführungsform beschränkt ist.
  • Wie beschrieben stellen Fahrzeuge wie Autos, LKWs, Geländewagen, Crossovers, Minivans oder andere geeignete Fahrzeuge zunehmend komplexe Technologie bereit, die den Betreibern solcher Fahrzeuge erhöhte Funktionalität und Sicherheitsfunktionen bietet. Beispielsweise hat sich die Automobilsoftwareindustrie schnell von wenigen Funktionen zu fortschrittlicheren Funktionen entwickelt, wie beispielsweise fortgeschrittene autonome Funktionen, fortgeschrittene Fahrerassistenzsysteme (ADAS), fortgeschrittene Spiegelsteuerung, komplexe Motorsteuerung, Fahrerassistenzfunktionen (z.B. adaptive Geschwindigkeitsregelung und dergleichen), komplexe Sicherheitsfunktionen und dergleichen.
  • Während die Komplexität solcher Technologie weiter zunimmt, werden mechanische Fahrzeugsysteme durch komplexe elektronische Steuereinheiten (ECU) ersetzt. Solche ECUs sind typischerweise mit Software programmiert, um die gewünschten Funktionen des Fahrzeugs auszuführen. ECUs kommunizieren typischerweise über verschiedene Netzwerke innerhalb solcher Fahrzeuge. Um Merkmale wie die hierin beschriebenen bereitzustellen, können Fahrzeuge eine erhöhte Anzahl von ECUs umfassen, welche dementsprechend mit zunehmend komplexer Software programmiert werden können.
  • Diese Zunahme der Anzahl und Komplexität solcher Funktionen hat einen Bedarf an mehr Softwarekomplexität wie beispielsweise fortgeschrittene Prognostik, Ausfalloperationen, Ausfalltoleranzen, höhere Sicherheitsniveaus und dergleichen geschaffen. Vermehrte Softwarefunktionalität und -komplexität können eine Herausforderung für ECU- und/oder Softwaredurchsatzmanagement darstellen. Aktuelle Produktionsprojekte für elektronische Servolenksysteme (EPS-Systeme) und/oder Steer-by-Wire-Softwareentwicklung können auf solche Softwaredurchsatzherausforderungen stoßen. Höherer Durchsatz (z.B. zwischen 80% und 92% und höher auftretend) kann zu Datenkorruption und zum Zurücksetzen der ECU führen, was zu einem katastrophalen Ereignis führen kann.
  • Typische Ansätze, solche Durchsatzherausforderungen zu bewältigen, umfassen: ein Ändern eines Takts einer Zentraleinheit (CPU); ein Ändern der Wartezeit für CPU-Anweisungen; ein Optimieren von Funktionen mit Bezug auf die Software; ein Reduzieren von durch die Software bereitgestellter Funktionalität; ein Optimieren der Funktionsausführung (so dass beispielsweise Wartezeit reduziert wird); und ein Diversifizieren des Entwurfsansatzes unter Verwendung eines Zeitgebers, eines direkten Speicherzugriffs (DMA), anderer Peripheriegeräte oder einer Kombination davon, um die Wartezeit zu verkürzen. Solche Ansätze können technisch einfach zu implementieren sein, können jedoch die Leistung solcher Systeme negativ beeinflussen.
  • Dementsprechend können Systeme und Verfahren wie die hierin beschriebenen, die konfiguriert sind, um ein Softwaredurchsatzmanagement zu verbessern, während eine Hardwareleistung aufrechterhalten wird, wünschenswert sein. In einigen Ausführungsformen können die hierin beschriebenen Systeme und Verfahren konfiguriert sein, ein Aufgabenausführungsmanagement unter Verwendung verschiedener ECUs in einem Fahrzeug dynamisch zu verteilen. Wie beschrieben, kann das Fahrzeug eine Vielzahl von ECUs umfassen, die durch ein Kommunikationsnetzwerk verbunden sind. Die ECUs können so programmiert sein, dass sie Aspekte der jeweiligen Komponenten des Fahrzeugs steuern, und entsprechende spezifische Funktionen für die jeweiligen Komponenten umfassen. Einige, aber nicht alle ECUs können mit einem relativ höheren Durchsatz arbeiten. Die hierin beschriebenen Systeme und Verfahren können so konfiguriert sein, dass sie verfügbaren (z.B. nicht verwendeten) Verarbeitungsdurchsatz bestimmter Steuergeräte unter Verwendung des Kommunikationsnetzwerks nutzen. Die hierin beschriebenen Systeme und Verfahren können konfiguriert sein, um dezentrale Anwendungen auf dem Kommunikationsnetzwerk zu erstellen und bereitzustellen, indem ein Teil einer Anwendung auf einer anderen ECU in dem Netzwerk untergebracht wird.
  • In einigen Ausführungsformen können die hierin beschriebenen Systeme und Verfahren konfiguriert sein, um eine Softwaredurchsatzmanagementanwendung (Managementanwendung) auf zumindest einigen der ECUs auszuführen. Die Managementanwendung kann eine Aufgabenbeobachter- und Überwachungsfunktion umfassen, die konfiguriert ist, um Leerlaufaufgaben- (z.B. Leerlaufzeit) und Softwareblockinformationen (z.B. Eigenschaften der Softwareausführungsfähigkeit) für die ECUs aufzuzeichnen (z.B. zu speichern). In einigen Ausführungsformen umfassen die Softwareblöcke ferner einen Vertrauensnachweis (der beispielsweise angibt, dass der entsprechenden ECU vertraut wird, dem Softwareblock zugehörige Software auszuführen) basierend auf vom Betreiber vorab ausgewählten ECU-Nachweisen. In einigen Ausführungsformen können die ECUs einen Nachweis der Softwareblöcke an das Kommunikationsnetzwerk übermitteln und eine Quell-ECU (beispielsweise eine ECU mit auszulagernder Softwareausführung auf andere ECUs, um Leerlaufzeit zu nutzen) kann Aufzeichnungen speichern, die verfügbare Softwareblöcke in dem Kommunikationsnetzwerk angeben.
  • In einigen Ausführungsformen können die hierin beschriebenen Systeme und Verfahren konfiguriert sein, um eine Aufforderung an eine entfernte ECU in Reaktion auf die Quell-ECU zu erzeugen, die Raum- und Ausführungsbandbreite (z.B. Leerlaufprozessorzeit) für einen verfügbaren Softwareblock in der entfernten (z.B. Ziel) ECU identifiziert. Die entfernte ECU kann konfiguriert sein, um die Managementanwendung auszuführen. Die Managementanwendung auf der entfernten ECU kann die Aufforderung empfangen und zustimmen, den Funktionsstatus der Quell-ECU auszuführen. Die entfernte ECU kann ein „Berechtigungserteilungssignal“ (z.B. Akzeptanz) übermitteln, das angibt, dass die entfernte ECU zustimmt, dass die Quell-ECU für eine begrenzte Blockausführung Zugriff auf den Softwareblock haben kann. Die hierin beschriebenen Systeme und Verfahren können konfiguriert sein, um von der Quell-ECU an die entfernte ECU zu übermitteln, dass die Software auf der entfernten ECU in Reaktion darauf ausgeführt wird, dass die Quell-ECU das Berechtigungserteilungssignal erhalten hat.
  • In einigen Ausführungsformen können die hierin beschriebenen Systeme und Verfahren konfiguriert sein, an einem Quellprozessor eine Leerlaufzeit und zumindest ein Aufgabenausführungsmerkmal, das jeweiligen Prozessoren eines anderen Prozessors oder mehrerer anderer Prozessoren entspricht, zu empfangen. Die hierin beschriebenen Systeme und Verfahren können konfiguriert sein, um einen Zielprozessor aus dem einen anderen Prozessor oder den mehreren anderen Prozessoren, der in der Lage ist, eine dem Quellprozessor zugeordnete Aufgabe auszuführen, basierend auf der Leerlaufzeit und des zumindest einen Aufgabenausführungsmerkmals des Zielprozessors zu identifizieren. Die hierin beschriebenen Systeme und Verfahren können konfiguriert sein, um dem Zielprozessor eine Aufgabenaufforderung zu übermitteln, die den Zielprozessor auffordert, die dem Quellprozessor zugeordnete Aufgabe auszuführen. Die hierin beschriebenen Systeme und Verfahren können konfiguriert sein, in Reaktion auf ein Empfangen einer Übermittlung des Zielprozessors, die eine Annahme der Aufgabe angibt, dem Zielprozessor Anweisungen zur Ausführung der Aufgabe zu übermitteln.
  • 1 veranschaulicht allgemein ein Fahrzeug 10 gemäß den Grundsätzen der vorliegenden Offenbarung. Das Fahrzeug 10 kann jedes geeignete Fahrzeug wie beispielsweise ein Auto, einen Lkw, einen Geländewagen, einen Minivan, ein Crossover, jedes andere Personenkraftfahrzeug, jedes geeignete Nutzfahrzeug oder jedes andere geeignete Fahrzeug umfassen. Während das Fahrzeug 10 als ein Personenkraftfahrzeug mit Rädern und für die Benutzung auf Straßen veranschaulicht ist, können die Grundsätze der vorliegenden Offenbarung für andere Fahrzeuge wie beispielsweise Flugzeuge, Boote, Züge, Drohnen oder andere geeignete Fahrzeuge gelten.
  • Das Fahrzeug 10 umfasst eine Fahrzeugkarosserie 12 und eine Motorhaube 14. Ein Fahrgastraum 18 ist zumindest teilweise durch die Fahrzeugkarosserie 12 definiert. Ein anderer Abschnitt der Fahrzeugkarosserie 12 definiert einen Motorraum 20. Die Motorhaube 14 kann beweglich an einem Abschnitt der Fahrzeugkarosserie 12 angebracht sein, sodass die Motorhaube 14 Zugang zu dem Motorraum 20 gewährt, wenn sich die Motorhaube 14 in einer ersten oder offenen Position befindet, und die Motorhaube 14 den Motorraum 20 bedeckt, wenn sich die Motorhaube 14 in einer zweiten oder geschlossenen Position befindet. In einigen Ausführungsformen kann der Motorraum 20 im hinteren Abschnitt des Fahrzeugs 10 angeordnet sein, anders als allgemein veranschaulicht.
  • Der Fahrgastraum 18 kann hinter dem Motorraum 20 angeordnet sein, kann jedoch in Ausführungsformen, in denen der Motorraum 20 im hinteren Abschnitt des Fahrzeugs 10 angeordnet ist, vor dem Motorraum 20 angeordnet sein. Das Fahrzeug 10 kann jedes geeignete Antriebssystem aufweisen, einschließlich einen Verbrennungsmotor, einen oder mehrere Elektromotoren (z. B. bei einem elektrisches Fahrzeug), eine oder mehrere Brennstoffzellen, ein hybrides (z. B. ein Hybridfahrzeug-) Antriebssystem, das eine Kombination eines Verbrennungsmotors, einer oder mehrerer Elektromotoren und/oder jedes anderen geeigneten Antriebssystems umfasst.
  • In einigen Ausführungsformen kann das Fahrzeug 10 einen Benzinkraftstoffmotor wie beispielsweise einen Fremdzündungsmotor aufweisen. In einigen Ausführungsformen kann das Fahrzeug 10 einen Dieselkraftstoffmotor wie beispielsweise einen Selbstzündungsmotor aufweisen. Der Motorraum 20 beherbergt und/oder umschließt zumindest einige Komponenten des Antriebssystems des Fahrzeugs 10. Zusätzlich oder alternativ sind Antriebssteuerungen wie beispielsweise ein Beschleunigungsaktuator (z. B. ein Gaspedal), ein Bremsaktuator (z. B. ein Bremspedal), ein Lenkrad und andere derartige Komponenten in dem Fahrgastraum 18 des Fahrzeugs 10 angeordnet. Die Antriebssteuerungen können durch einen Fahrer des Fahrzeugs 10 betätigt oder gesteuert werden und können direkt mit entsprechenden Komponenten des Antriebssystems wie beispielsweise einer Drosselklappe, einer Bremse, einer Fahrzeugachse, einem Fahrzeuggetriebe und dergleichen verbunden sein. In einigen Ausführungsformen können die Antriebssteuerungen Signale an einen Fahrzeugcomputer (z. B. bei Drive-by-Wire) kommunizieren, welcher im Gegenzug die entsprechende Antriebskomponente des Antriebssystems steuert. Somit kann das Fahrzeug 10 in einigen Ausführungsformen ein autonomes Fahrzeug sein.
  • In einigen Ausführungsformen umfasst das Fahrzeug 10 ein über ein Schwungrad oder eine Schaltkupplung oder eine Fluidkupplung in Kommunikation mit einer Kurbelwelle stehendes Getriebe. In einigen Ausführungsformen umfasst das Getriebe ein manuelles Getriebe. In einigen Ausführungsformen umfasst das Getriebe ein automatisches Getriebe. Das Fahrzeug 10 kann, im Falle eines Verbrennungsmotors oder eines Hybridfahrzeugs, einen oder mehrere Kolben umfassen, welche gemeinsam mit der Kurbelwelle arbeiten, um Kraft zu generieren, die durch das Getriebe an eine oder mehrere Achsen übertragen wird, was Räder 22 dreht. Wenn das Fahrzeug 10 einen oder mehrere Elektromotoren umfasst, stellt eine Fahrzeugbatterie und/oder Brennstoffzelle den Elektromotoren Energie bereit, um die Räder 22 zu drehen.
  • Das Fahrzeug 10 kann automatische Fahrzeugantriebssysteme wie beispielsweise eine Geschwindigkeitsregelung, eine adaptive Geschwindigkeitsregelung, automatische Bremssteuerung, andere automatische Fahrzeugantriebssysteme oder eine Kombination davon umfassen. Das Fahrzeug 10 kann ein autonomes oder semi-autonomes Fahrzeug oder ein anderer geeigneter Fahrzeugtyp sein. Das Fahrzeug 10 kann zusätzliche oder weniger Merkmale als diese allgemein veranschaulichten und/oder hierin offenbarten Merkmale umfassen.
  • In einigen Ausführungsformen kann das Fahrzeug 10 eine Ethernet-Komponente 24, eine Controller-Area-Network-Komponente (CAN) 26, eine Media-Oriented-Systems-Transport-Komponente (MOST) 28, eine FlexRay-Komponente 30 (z. B. Brake-by-Wire-System und dergleichen) und eine Local-Interconnect-Network-Komponente (LIN) 32 umfassen. Das Fahrzeug 10 kann die CAN 26, die MOST 28, die FlexRay-Komponente 30, die LIN 32, andere geeignete Netzwerke oder Kommunikationssysteme oder eine Kombination davon verwenden, um verschiedene Informationen von beispielsweise Sensoren innerhalb oder außerhalb des Fahrzeugs an beispielsweise verschiedene Prozessoren oder Controller innerhalb oder außerhalb des Fahrzeugs zu übermitteln. Das Fahrzeug 10 kann zusätzliche oder weniger Merkmale als diese allgemein veranschaulichten und/oder hierin offenbarten Merkmale umfassen.
  • Das Fahrzeug 10 kann ein dezentrales dynamisches Softwaredurchsatzmanagementsystem 100 umfassen, wie allgemein in 2 veranschaulicht ist. Wie allgemein in 2 veranschaulicht ist, kann das System 100 ein Netzwerk von elektronischen Steuereinheiten (ECU) wie beispielsweise ECU1, ECU2, ECU3, ECU4 und ECU5 umfassen. Obwohl lediglich fünf ECUs veranschaulicht sind, kann das System 100 jede geeignete Anzahl von ECUs (z.B. mehrere zehn oder hundert ECUs) und/oder anderen Komponenten als allgemein veranschaulicht und/oder hierin beschrieben umfassen.
  • Jede ECU kann einen Prozessor und einen Speicher umfassen, der Anweisungen umfasst, die bei Ausführung durch den Prozessor den Prozessor dazu veranlassen, zumindest verschiedene Funktionen einschließlich der hierin beschriebenen auszuführen. Bei einigen Ausführungsformen umfasst jede ECU einen Prozessor und jeder Prozessor kommuniziert mit einem zugeordneten Speicher. Die ECU kann jeden geeigneten Prozessor wie beispielsweise die hierin beschriebenen umfassen. Der Speicher kann eine einzelne Platte oder eine Vielzahl an Platten (z.B. Festplatten) umfassen und umfasst ein Speicherungsmanagementmodul, das eine oder mehrere Partitionen innerhalb des Speichers verwaltet. In einigen Ausführungsformen umfasst der Speicher einen Flashspeicher, einen Halbleiterspeicher (Festkörperspeicher) oder dergleichen. Der Speicher kann ein Random Access Memory (RAM), ein Read-Only Memory (ROM) oder eine Kombination davon umfassen.
  • Das System 100 kann ein Kommunikationsnetzwerk 102 umfassen. Das Netzwerk 102 kann jedes geeignete Netzwerk wie beispielsweise die Ethernet-Komponente 24, die CAN-Komponente 26, die MOST-Komponente 28, die FlexRay-Komponente 30, die LIN-Komponente 32, jede andere geeignete Netzwerk- oder andere Übermittlungskomponente oder eine Kombination davon umfassen. Jede jeweilige ECU des Systems 100 kann mit jeder anderen ECU und/oder einer Teilmenge der anderen ECUs über das Netzwerk 102 kommunizieren. Beispielsweise kann die ECU1 konfiguriert sein, Bremsoperationen für das Fahrzeug 10 auszuführen. Die ECU1 kann Sensordaten von verschiedenen Sensoren des Fahrzeugs 10 empfangen und ermitteln, ob eine Bremse des Fahrzeugs 10 zu betätigen ist. Die ECU2 kann beispielsweise einen Bremsmechanismus des Fahrzeugs 10 steuern. Die ECU1 kann mit der ECU2 kommunizieren, um den Bremsmechanismus basierend auf den von der ECU1 empfangenen Sensordaten durchzuführen.
  • Wie allgemein in 4A und 4B veranschaulicht kann die ECU1 oder jede andere ECU des Systems 100 eine Automobilsystemarchitektur (AutoSAR) umfassen, die Hardware, komplexe Treiber, eine Mikrocontroller-Abstraktionsschicht (MCAL), eine Basisgrundlage, verschiedene Dienste, einen dezentralen ECU-Aufgabenbeobachter und -überwacher, eine Laufzeitumgebung (RTE) und eine Anwendungsschicht mit verschiedenen Anwendungen umfasst. In einigen Ausführungsformen kann die ECU2 oder jede andere geeignete ECU des Systems 100 eine Nicht-AutoSAR-Architektur umfassen, welche Hardware, eine Hardwareabstraktionsschicht, ein Betriebssystem (OS), eine Systemdienstschicht und eine Anwendungsschicht mit verschiedenen Anwendungen einschließlich des dezentralen ECU-Aufgabenbeobachters und -überwachers umfasst. In einigen Ausführungsformen kann die ECU3 oder jede andere geeignete ECU des Systems 100 eine Nicht-AutoSAR-Architektur ohne OS umfassen, welche Hardware, eine Hardwareabstraktionsschicht und den dezentralen ECU-Aufgabenbeobachter und -überwacher umfasst.
  • In einigen Ausführungsformen kann das System 100 den Durchsatz durch Auslagerung verschiedener Software und Aufgaben von einer ECU an eine ECU verbessern, die eine Leerlaufzeit aufweist und in der Lage ist, die Software oder Aufgaben auszuführen. Beispielsweise kann die ECU1 eine Quell-ECU darstellen und Software oder Aufgaben (beispielsweise bezeichnet als Softwareblock) umfassen, die auf andere ECUs ausgelagert werden können, um Leerlaufzeit der anderen ECUs auszunutzen. Der Softwareblock kann Software oder Aufgaben mit begrenzten Eingabe- und Ausgabebereichen, nicht-sicherheitskritische Software oder Aufgaben, relativ kleine Software oder Aufgaben, Software oder Aufgaben, die relativ einfache mathematische oder minimallogische Funktionen verwenden, Software oder Aufgaben, die Grundfunktionen verwenden, Software oder Aufgaben mit einer endlichen Schleife, Software oder Aufgaben, die temporäre (schwankende) Variablen verwenden, andere geeignete Software oder Aufgaben oder eine Kombination davon umfassen.
  • Das System 100 kann konfiguriert sein, um die Anwendung des dezentralen ECU-Aufgabenbeobachters und -überwachers auf zumindest eine Teilmenge der ECUs in dem Netzwerk 102 einzuleiten. Die Anwendung des dezentralen ECU-Aufgabenbeobachters und -überwachers kann eine Softwaredurchsatzmanagementanwendung umfassen und kann hier als die Managementanwendung bezeichnet werden.
  • Wie allgemein in 3 veranschaulicht kann sich eine Instanz der Managementanwendung auf der ECU 1 und der ECU 2 befinden und, obwohl nicht veranschaulicht, kann sich eine Instanz der Managementanwendung auch auf einigen oder allen anderen ECUs auf dem Netzwerk 102 befinden. Die ECU1 kann bei Ausführung der Managementanwendung Informationen von den anderen ECUs empfangen, welche die Managementanwendung auf dem Netzwerk 102 ausführen. Die Information kann für jede ECU, welche die Managementanwendung auf dem Netzwerk 102 ausführt, Leerlaufzeit, Softwareblockinformationen, Vertrauensnachweisinformationen, andere geeignete Informationen oder eine Kombination davon umfassen.
  • Die Leerlaufzeit kann eine Anzahl von verfügbaren Verarbeitungszyklen für eine jeweilige ECU angeben. Die Softwareblockinformation kann eine für eine jeweilige ECU charakteristische Softwareausführungs- oder Aufgabenausführungsfähigkeit angeben. Beispielsweise kann die Softwareblockinformation für eine jeweilige ECU angeben, ob die jeweilige ECU in der Lage ist, den Softwareblock auszuführen, den die ECU1 auslagert. Die Vertrauensnachweisinformation kann angeben, ob der jeweiligen ECU vertraut wird (beispielsweise programmgesteuert oder selektiv durch den Betreiber, Programmierer oder Benutzer des Systems 100 bestimmt), den Softwareblock der ECU1 auszuführen. Die ECU1 kann die von den anderen ECUs empfangene Information im Speicher speichern. Beispielsweise kann die ECU1 eine im Speicher gespeicherte Tabelle aktualisieren. Die Tabelle kann die Leerlaufzeit, Softwareblockinformation, Vertrauensnachweisinformation und/oder andere geeignete Information für jede der ECUs auf dem Netzwerk 102 angeben.
  • Die ECU1 kann so konfiguriert sein, dass sie eine entfernte (z.B. Ziel-) ECU identifiziert, um den Softwareblock der ECU1 auszuführen. Beispielsweise kann die ECU1 eine entfernte ECU, beispielsweise die ECU2, identifizieren, die in der Lage ist, den Softwareblock der im Speicher gespeicherten Tabelle auszuführen. Es sollte verstanden werden, dass jede ECU auf dem Kommunikationsnetzwerk 102 in der Lage sein kann, die entfernte ECU zu sein. Die ECU1 kann ermitteln, ob die ECU2 ausreichend Leerlaufzeit aufweist, um den Softwareblock basierend auf der entsprechenden, in der Tabelle gespeicherten Leerlaufzeit der ECU2 auszuführen. Zusätzlich oder alternativ kann die ECU1 ermitteln, ob der ECU2 vertraut wird, den Softwareblock basierend auf der in der Tabelle gespeicherten Vertrauensnachweisinformation auszuführen.
  • Wenn die ECU1 ermittelt, dass die ECU2 entweder nicht in der Lage ist, den Softwareblock auszuführen, oder nicht ausreichend Leerlaufzeit aufweist, um den Softwareblock auszuführen, kann die ECU1 eine andere ECU als die entfernte oder Ziel-ECU identifizieren. Zusätzlich oder alternativ kann die ECU1, wenn die ECU1 ermittelt, dass der ECU2 nicht vertraut wird, den Softwareblock auszuführen, eine andere ECU als die entfernte oder Ziel-ECU identifizieren. Wenn die ECU1 hingegen ermittelt, dass die ECU2 in der Lage ist, den Softwareblock auszuführen, ausreichend Leerlaufzeit aufweist, um den Softwareblock auszuführen und der ECU2 vertraut wird, den Softwareblock auszuführen, generiert die ECU1 eine Aufforderung (z.B. ein Signal, das die Aufforderung angibt), den Softwareblock auszuführen. Die ECU1 übermittelt die Aufforderung an die ECU2.
  • In Reaktion auf das Empfangen der Aufforderung, den Softwareblock auszuführen, ermittelt die ECU2, ob sie die Aufforderung annimmt. Beispielsweise kann die ECU2 ermitteln, ob die ECU2 weiterhin ausreichend Leerlaufzeit aufweist, um den Softwareblock auszuführen. Wenn die ECU2 bestimmt, die Aufforderung zum Ausführen des Softwareblocks anzunehmen, generiert die ECU2 eine Annahme (z.B. ein Signal, das die Annahme angibt) und kommuniziert die Annahme an die ECU1.
  • In Reaktion auf das Empfangen der Annahme von der ECU2 übermittelt die ECU1 die dem Softwareblock zugehörige Software an die ECU2. In Reaktion auf das Empfangen der Software mit dem Softwareblock von der ECU1 flasht die ECU2 die Software auf die ECU2. Die ECU2 kann dann die dem Softwareblock zugehörige Software ausführen. Die ECU2 kann mit der Ausführung des Softwareblocks verknüpfte Daten an die ECU1 übermitteln. Die Daten können eine Ausgabe der Ausführung der Software oder andere geeignete Daten umfassen.
  • In einigen Ausführungsformen kann das System 100 die hierin beschriebenen Verfahren ausführen. Die hierin beschriebenen Verfahren, wie sie von System 100 ausgeführt werden, sollen jedoch nicht einschränkend sein und jede Art von Software, die auf einem Controller ausgeführt wird, kann die hierin beschriebenen Verfahren ausführen, ohne vom Umfang dieser Offenbarung abzuweichen. Beispielsweise kann ein Controller wie beispielsweise ein Prozessor, der Software innerhalb eines Rechengeräts ausführt, die hierin beschriebenen Verfahren ausführen.
  • 5 ist ein Ablaufdiagramm, das allgemein ein dezentrales dynamisches Softwaredurchsatzmanagementverfahren 400 gemäß den Grundsätzen der vorliegenden Offenbarung veranschaulicht. In 402 empfängt das Verfahren 400 Leerlaufzeiten und Aufgabenausführungsmerkmale. Beispielsweise empfängt die ECU1 (oder beispielsweise andere geeignete ECU) Leerlaufzeitinformation, Softwareblockinformation (z.B. einschließlich Software- und/oder Aufgabenausführungsfähigkeitsmerkmale) und/oder Vertrauensnachweisinformation von den anderen ECUs auf dem Kommunikationsnetzwerk 102. Die ECU1 kann die empfangene Leerlaufzeitinformation, Softwareblockinformation und/oder Vertrauensnachweisinformation in der Tabelle im Speicher speichern.
  • In 404 identifiziert das Verfahren 400 einen Zielprozessor. Beispielsweise kann die ECU1 einen Prozessor wie beispielsweise den zu der ECU2 zugehörigen Prozessor (hier im Weiteren als ECU2 bezeichnet) als den entfernten oder Zielprozessor basierend auf der in der Tabelle gespeicherten Information identifizieren. In 406 übermittelt das Verfahren 400 eine Aufgabenaufforderung an den Zielprozessor. Beispielsweise generiert und übermittelt die ECU1 eine Aufforderung an die ECU2, die zu dem Softwareblock zugehörige Software und/oder Aufgabe auszuführen.
  • In 408 ermittelt das Verfahren 400, ob eine Annahme empfangen wird. Beispielsweise ermittelt die ECU1, ob die ECU2 eine Annahme (z.B. ein Signal, das die Annahme angibt) kommuniziert hat, die zu dem Softwareblock zugehörige Software oder Aufgabe auszuführen (oder beispielsweise durchzuführen). Wenn die ECU1 ermittelt, dass keine Annahme empfangen wurde, fährt das Verfahren 400 mit 404 fort. In einigen Ausführungsformen fährt das Verfahren 400 mit 408 fort und wartet auf eine Annahme. Alternativ endet das Verfahren 400, wenn das Verfahren 400 einen Hinweis empfängt, dass die ECU2 die Aufforderung abgewiesen hat. Wenn die ECU1 ermittelt, dass die Annahme empfangen wird (z.B. hat die ECU2 die Aufforderung angenommen), fährt das Verfahren 400 mit 410 fort.
  • In 410 übermittelt das Verfahren 400 Anweisungen zur Ausführung der Aufgabe an den Zielprozessor. Beispielsweise übermittelt die ECU1 Anweisungen zur Ausführung der zu dem Softwareblock zugehörigen Software oder Aufgabe. In einigen Ausführungsformen können die Anweisungen Software umfassen, die konfiguriert ist, um auf die ECU2 geflasht zu werden. In Reaktion auf das Empfangen der Anweisungen führt die ECU2 die zu dem Softwareblock zugehörige Software oder Aufgabe aus.
  • In 412 empfängt das Verfahren 400 zu der Ausführung der Aufgabe zugehörige Daten von dem Zielprozessor. Beispielsweise empfängt die ECU1 von der ECU2 Daten, die mit der Ausführung der zu dem Softwareblock zugehörigen Software oder Aufgabe verknüpft ist. In Reaktion auf die abgeschlossene Ausführung der zu dem Softwareblock zugehörigen Software oder Aufgabe übermittelt die ECU2 an die ECU1, dass die Ausführung abgeschlossen ist. Die ECU1 gibt die ECU2 frei.
  • In einigen Ausführungsformen umfasst ein System für dynamisches Softwaremanagement einen Quellprozessor und einen Speicher. Der Speicher umfasst Anweisungen, die bei Ausführung durch den Prozessor den Prozessor dazu veranlassen: von einem oder mehreren anderen Prozessoren eine Leerlaufzeit und zumindest ein Aufgabenausführungsmerkmal, das jedem jeweiligen Prozessor des einen anderen Prozessors oder der mehreren anderen Prozessoren entspricht, zu empfangen; einen Zielprozessor aus dem einen anderen Prozessor oder den mehreren anderen Prozessoren basierend auf der Leerlaufzeit und des zumindest einen Aufgabenausführungsmerkmals des Zielprozessors zu identifizieren, der in der Lage ist, eine dem Quellprozessor zugehörige Aufgabe auszuführen; an den Zielprozessor eine Aufgabenaufforderung zu übermitteln, die den Zielprozessor dazu auffordert, die dem Quellprozessor zugehörige Aufgabe auszuführen; und in Reaktion auf ein Empfangen einer Übermittlung von dem Zielprozessor, die eine Annahme der Aufforderung angibt, Anweisungen zur Ausführung der Aufgabe an den Zielprozessor zu übermitteln.
  • In einigen Ausführungsformen gibt das zumindest eine Aufgabenausführungsmerkmal eine Fähigkeit eines jeweiligen Prozessors des einen anderen Prozessors oder der mehreren anderen Prozessoren an, eine bestimmte Aufgabe auszuführen. In einigen Ausführungsformen veranlassen die Anweisungen den Prozessor ferner dazu, die Leerlaufzeit und das zumindest eine Aufgabenausführungsmerkmal für jeden des einen anderen Prozessors oder der mehreren anderen Prozessoren zu speichern. In einigen Ausführungsformen führt der Zielprozessor die Aufgabe gemäß den Anweisungen zur Ausführung der Aufgabe aus. In einigen Ausführungsformen veranlassen die Anweisungen den Prozessor ferner dazu, zur Ausführung der Aufgabe zugehörige Daten von dem Zielprozessor zu empfangen. In einigen Ausführungsformen veranlassen die Anweisungen den Prozessor ferner dazu, einen Vertrauenshinweis von jedem des einen anderen Prozessors oder der mehreren anderen Prozessoren zu empfangen, wobei der Vertrauenshinweis angibt, dass einem jeweiligen Prozessor des einen anderen Prozessors oder der mehreren anderen Prozessoren vertraut wird, eine zugehörige Aufgabe durchzuführen. In einigen Ausführungsformen umfasst die dem Quellprozessor zugehörige Aufgabe eine nicht-sicherheitskritische Aufgabe. In einigen Ausführungsformen sind der Quellprozessor und der eine andere Prozessor oder die mehreren anderen Prozessoren in einem Fahrzeug angeordnet.
  • In einigen Ausführungsformen umfasst ein Verfahren für dynamisches Softwaremanagement ein Empfangen einer Leerlaufzeit und zumindest eines Aufgabenausführungsmerkmals, das jeweiligen Prozessoren des einen anderen Prozessors oder der mehreren anderen Prozessoren entspricht, an einem Quellprozessor. Das Verfahren umfasst ferner ein Identifizieren eines Zielprozessors aus dem einen anderen Prozessor oder den mehreren anderen Prozessoren, welcher in der Lage ist, eine dem Quellprozessor zugehörige Aufgabe auszuführen, basierend auf der Leerlaufzeit und dem zumindest einen Aufgabenausführungsmerkmal des Zielprozessors. Das Verfahren umfasst ferner ein Übermitteln einer Aufgabenaufforderung an den Zielprozessor, welche den Zielprozessor dazu auffordert, die dem Quellprozessor zugehörige Aufgabe auszuführen. Das Verfahren umfasst ferner, in Reaktion auf ein Empfangen einer Übermittlung des Zielprozessors, die eine Annahme der Aufgabe angibt, ein Übermitteln von Anweisungen zur Ausführung der Aufgabe an den Zielprozessor.
  • In einigen Ausführungsformen gibt das zumindest eine Aufgabenausführungsmerkmal eine Fähigkeit eines jeweiligen Prozessors des einen anderen Prozessors oder der mehreren anderen Prozessoren an, eine bestimmte Aufgabe auszuführen. In einigen Ausführungsformen umfasst das Verfahren ferner ein Speichern der Leerlaufzeit und des zumindest einen Aufgabenausführungsmerkmals für jeden des einen anderen Prozessors oder der mehreren anderen Prozessoren. In einigen Ausführungsformen führt der Zielprozessor die Aufgabe gemäß den Anweisungen zur Ausführung der Aufgabe aus. In einigen Ausführungsformen umfasst das Verfahren ferner ein Empfangen von zur Ausführung der Aufgabe zugehörigen Daten von dem Zielprozessor. In einigen Ausführungsformen umfasst das Verfahren ferner ein Empfangen eines Vertrauenshinweises von jedem des einen anderen Prozessors oder der mehreren anderen Prozessoren, wobei der Vertrauenshinweis angibt, dass einem jeweiligen Prozessor des einen anderen Prozessors oder der mehreren anderen Prozessoren vertraut wird, eine entsprechende Aufgabe durchzuführen. In einigen Ausführungsformen umfasst die dem Quellprozessor zugehörige Aufgabe eine nicht-sicherheitskritische Aufgabe. In einigen Ausführungsformen sind der Quellprozessor und der eine andere Prozessor oder die mehreren anderen Prozessoren in einem Fahrzeug angeordnet.
  • In einigen Ausführungsformen umfasst eine dynamische Softwaremanagementvorrichtung eine erste elektronische Steuereinheit eines Fahrzeugs. Die erste elektronische Steuereinheit umfasst einen Prozessor und einen Speicher. Der Speicher umfasst Anweisungen, die bei Ausführung durch den Prozessor den Prozessor dazu veranlassen: einer zweiten elektronischen Steuereinheit des Fahrzeugs eine Leerlaufzeit und zumindest ein Aufgabenausführungsmerkmal der zweiten elektronischen Steuereinheit zu empfangen; basierend auf der Leerlaufzeit und dem zumindest einen Aufgabenausführungsmerkmal der zweiten elektronischen Steuereinheit zu ermitteln, ob die zweite elektronische Steuereinheit in der Lage ist, der ersten elektronischen Steuereinheit zugehörige Software auszuführen; in Reaktion auf eine Ermittlung, dass die zweite elektronische Steuereinheit in der Lage ist, die Software auszuführen, eine Aufforderung zur Ausführung der Software an die zweite elektronische Steuereinheit zu übermitteln; und in Reaktion auf ein Empfangen einer Übermittlung der zweiten elektronischen Steuereinheit, die eine Annahme der Aufforderung zur Ausführung der Software angibt, die Software auf die zweite elektronische Steuereinheit zu flashen.
  • In einigen Ausführungsformen führt die zweite elektronische Steuereinheit die Software aus. In einigen Ausführungsformen veranlassen die Anweisungen den Prozessor ferner dazu, zur Ausführung der Software zugehörige Daten von der zweiten elektronischen Steuereinheit zu empfangen. In einigen Ausführungsformen umfasst die Software nicht-sicherheitskritische Software.
  • Die obige Diskussion soll veranschaulichend für die Grundsätze und verschiedenen Ausführungsformen der vorliegenden Erfindung sein. Zahlreiche Variationen und Modifikationen werden für den Fachmann deutlich, wenn die obige Offenbarung vollständig verstanden wird. Die folgenden Ansprüche sollen so interpretiert werden, dass alle derartigen Variationen und Modifikationen berücksichtigt werden.
  • Das Wort „Beispiel“ wird hier verwendet, um als Beispiel, Fall oder Illustration zu dienen. Jeder Aspekt oder Entwurf, der hier als „Beispiel“ beschrieben wird, ist nicht notwendigerweise als bevorzugt oder vorteilhaft gegenüber anderen Aspekten oder Entwürfen auszulegen. Die Verwendung des Wortes „Beispiel“ soll vielmehr Konzepte konkret darstellen. Wie in dieser Anmeldung verwendet, soll der Begriff „oder“ ein inklusives „oder“ anstatt eines exklusiven „oder“ bedeuten. Das heißt, sofern nicht anders angegeben oder aus dem Kontext ersichtlich, bedeutet „X umfasst A oder B“ eine der natürlichen inklusiven Permutationen. Das heißt, wenn X A umfasst; X B umfasst; oder X sowohl A als auch B umfasst, dann ist „X umfasst A oder B“ unter jedem der vorstehenden Fälle erfüllt. Darüber hinaus sollten die Artikel „ein/eine“, wie sie in dieser Anmeldung verwendet werden, und die beigefügten Ansprüche allgemein so ausgelegt werden, dass sie „ein/eine oder mehrere“ bedeuten, sofern nicht anders angegeben oder aus dem Kontext ersichtlich, dass auf eine Singularform hingedeutet wird. Darüber hinaus soll die Verwendung des Begriffs „eine Implementierung“ (englisch: „an implementation“) oder „eine Implementierung“ (englisch: „one implementation“) nicht die gleiche Ausführungsform oder Implementierung bedeuten, es sei denn, sie wird als solche beschrieben.
  • Implementierungen der hierin beschriebenen Systeme, Algorithmen, Verfahren, Anweisungen usw. können als Hardware, Software oder eine beliebige Kombination davon realisiert werden. Die Hardware kann beispielsweise Computer, Intellectual Property (IP) Kerne, anwendungsspezifische integrierte Schaltkreise (ASICs), programmierbare Logik-Arrays, optische Prozessoren, programmierbare Logik-Controller, Mikrocode, Mikrocontroller, Server, Mikroprozessoren, digitale Signalprozessoren oder jede andere geeignete Schaltung umfassen. In den Ansprüchen sollte der Begriff „Prozessor“ so verstanden werden, dass er eine der vorgenannten Hardware entweder einzeln oder in Kombination umfasst. Die Begriffe „Signal“ und „Daten“ werden synonym verwendet.
  • Wie hierin verwendet, kann der Begriff Modul eine gebündelte funktionale Hardwareeinheit, die zur Verwendung mit anderen Komponenten ausgelegt ist, einen Satz von Anweisungen, die von einer Steuerung ausgeführt werden können (beispielsweise einem Prozessor, der Software oder Firmware ausführt), eine Verarbeitungsschaltung, die konfiguriert ist, eine bestimmte Funktion auszuführen, und eine eigenständige Hardware- oder Softwarekomponente umfassen, die mit einem größeren System verbunden ist. Beispielsweise kann ein Modul eine anwendungsspezifische integrierte Schaltung (ASIC), ein feldprogrammierbares Gate-Array (FPGA), eine Schaltung, eine digitale Logikschaltung, eine analoge Schaltung, eine Kombination von diskreten Schaltungen, Gates und anderen Arten von Hardware oder eine Kombination davon umfassen. In anderen Ausführungsformen kann ein Modul einen Speicher umfassen, der Anweisungen speichert, die von einem Controller ausgeführt werden können, um ein Merkmal des Moduls zu implementieren.
  • Ferner können in einem Aspekt beispielsweise hierin beschriebene Systeme unter Verwendung eines Allzweckcomputers oder eines Allzweckprozessors mit einem Computerprogramm implementiert werden, dass bei Ausführung eines der jeweiligen Verfahren, Algorithmen und/oder hierin beschriebenen Anweisungen ausführt.
  • Zusätzlich oder alternativ kann beispielsweise ein Spezialcomputer/-prozessor verwendet werden, der andere Hardware zum Ausführen eines der hierin beschriebenen Verfahren, Algorithmen oder Anweisungen enthalten kann.
  • Ferner können alle oder ein Teil der Implementierungen der vorliegenden Offenbarung die Form eines Computerprogrammprodukts annehmen, auf das beispielsweise von einem computerverwendbaren oder computerlesbaren Medium aus zugegriffen werden kann. Ein computerverwendbares oder computerlesbares Medium kann ein beliebiges Gerät sein, das beispielsweise das Programm zur Verwendung durch oder in Verbindung mit einem Prozessor greifbar enthalten, speichern, kommunizieren oder transportieren kann. Das Medium kann beispielsweise eine elektronische, magnetische, optische, elektromagnetische oder eine Halbleitereinrichtung sein. Andere geeignete Medien sind ebenfalls verfügbar.
  • Die oben beschriebenen Ausführungsformen, Implementierungen und Aspekte wurden beschrieben, um ein leichtes Verständnis der vorliegenden Erfindung zu ermöglichen und schränken die vorliegende Erfindung nicht ein. Vielmehr soll die Erfindung verschiedene Modifikationen und äquivalente Anordnungen innerhalb des Geltungsbereichs der beigefügten Ansprüche umfassen, wobei der Geltungsbereich die breiteste Auslegung erhalten soll, um alle Modifikationen und äquivalenten Strukturen zu umfassen, die nach dem Gesetz zulässig sind.

Claims (20)

  1. System für dynamisches Softwaremanagement, umfassend: einen Quellprozessor; und einen Speicher, der Anweisungen umfasst, die bei Ausführung durch den Quellprozessor den Quellprozessor dazu veranlassen: von einem anderen Prozessor oder mehreren anderen Prozessoren eine Leerlaufzeit und zumindest ein Aufgabenausführungsmerkmal, welches jedem jeweiligen Prozessor des einen anderen Prozessors oder der mehreren anderen Prozessoren entspricht, zu empfangen; einen Zielprozessor, welcher in der Lage ist, eine dem Quellprozessor zugehörige Aufgabe auszuführen, basierend auf der Leerlaufzeit und des zumindest einen Aufgabenausführungsmerkmals des Zielprozessors aus dem einen anderen Prozessor oder den mehreren anderen Prozessoren zu identifizieren; eine Aufgabenaufforderung an den Zielprozessor zu übermitteln, welche den Zielprozessor dazu auffordert, die dem Quellprozessor zugehörige Aufgabe auszuführen; und in Reaktion auf ein Empfangen einer Übermittlung von dem Zielprozessor, welche eine Annahme der Aufgabe angibt, Anweisungen zur Ausführung der Aufgabe an den Zielprozessor zu übermitteln.
  2. System nach Anspruch 1, wobei das zumindest eine Aufgabenausführungsmerkmal eine Fähigkeit eines jeweiligen Prozessors des einen anderen Prozessors oder der mehreren anderen Prozessoren angibt, eine bestimmte Aufgabe auszuführen.
  3. System nach Anspruch 1, wobei die Anweisungen den Prozessor ferner dazu veranlassen, die Leerlaufzeit und das zumindest eine Aufgabenausführungsmerkmal von jedem des einen anderen Prozessors oder der mehreren anderen Prozessoren zu speichern.
  4. System nach Anspruch 1, wobei der Zielprozessor die Aufgabe gemäß den Anweisungen zur Ausführung der Aufgabe ausführt.
  5. System nach Anspruch 1, wobei die Anweisungen den Prozessor ferner dazu veranlassen, zur Ausführung der Aufgabe zugehörige Daten von dem Zielprozessor zu empfangen.
  6. System nach Anspruch 1, wobei die Anweisungen den Prozessor ferner dazu veranlassen, einen Vertrauenshinweis von jedem des einen anderen Prozessors oder der mehreren anderen Prozessoren zu empfangen.
  7. System nach Anspruch 6, wobei der Vertrauenshinweis angibt, dass einem jeweiligen Prozessor des einen anderen Prozessors oder der mehreren anderen Prozessoren vertraut wird, eine entsprechende Aufgabe durchzuführen.
  8. System nach Anspruch 1, wobei der Quellprozessor und der eine andere Prozessor oder die mehreren anderen Prozessoren in einem Fahrzeug angeordnet sind.
  9. Verfahren für dynamisches Softwaremanagement, umfassend: ein Empfangen einer Leerlaufzeit und zumindest eines Aufgabenausführungsmerkmals, das jeweiligen Prozessoren eines anderen Prozessors oder mehrerer anderer Prozessoren entspricht, an einem Quellprozessor; ein Identifizieren eines Zielprozessors aus dem einen anderen Prozessor oder den mehreren anderen Prozessoren, welcher in der Lage ist, eine dem Quellprozessor zugehörige Aufgabe auszuführen, basierend auf der Leerlaufzeit und dem zumindest einen Aufgabenausführungsmerkmal des Zielprozessors; ein Übermitteln einer Aufgabenaufforderung an den Zielprozessor, welche den Zielprozessor auffordert, die dem Quellprozessor zugehörige Aufgabe auszuführen; und in Reaktion auf ein Empfangen einer Übermittlung von dem Zielprozessor, welche eine Annahme der Aufgabe angibt, ein Übermitteln von Anweisungen zur Ausführung der Aufgabe an den Zielprozessor.
  10. Verfahren nach Anspruch 9, wobei das zumindest eine Aufgabenausführungsmerkmal eine Fähigkeit eines jeweiligen Prozessors des einen anderen Prozessors oder der mehreren anderen Prozessoren angibt, eine bestimmte Aufgabe auszuführen.
  11. Verfahren nach Anspruch 9, ferner umfassend ein Speichern der Leerlaufzeit und des zumindest einen Aufgabenausführungsmerkmals für jeden des einen anderen Prozessors oder der mehreren anderen Prozessoren.
  12. Verfahren nach Anspruch 9, wobei der Zielprozessor die Aufgabe gemäß den Anweisungen zur Ausführung der Aufgabe ausführt.
  13. Verfahren nach Anspruch 9, ferner umfassend ein Empfangen von zur Ausführung der Aufgabe zugehörigen Daten von dem Zielprozessor.
  14. Verfahren nach Anspruch 9, ferner umfassend ein Empfangen eines Vertrauenshinweises von jedem des einen anderen Prozessors oder der mehreren anderen Prozessoren.
  15. Verfahren nach Anspruch 14, wobei der Vertrauenshinweis angibt, dass einem jeweiligen Prozessor des einen anderen Prozessors oder der mehreren anderen Prozessoren vertraut wird, eine entsprechende Aufgabe durchzuführen.
  16. Verfahren nach Anspruch 9, wobei der Quellprozessor und der eine andere Prozessor oder die mehreren anderen Prozessoren in einem Fahrzeug angeordnet sind.
  17. Dynamische Softwaremanagementvorrichtung, umfassend: eine erste elektronische Steuereinheit eines Fahrzeugs, wobei die erste elektronische Steuereinheit einen Prozessor und einen Speicher umfasst, wobei der Speicher Anweisungen umfasst, die bei Ausführung durch den Prozessor den Prozessor dazu veranlassen: einer zweiten elektronischen Steuereinheit des Fahrzeugs eine Leerlaufzeit und zumindest ein Aufgabenausführungsmerkmal der zweiten elektronischen Steuereinheit zu empfangen; basierend auf der Leerlaufzeit und dem zumindest einen Aufgabenausführungsmerkmal der zweiten elektronischen Steuereinheit zu ermitteln, ob die zweite elektronische Steuereinheit in der Lage ist, der ersten elektronischen Steuereinheit zugehörige Software auszuführen; in Reaktion auf eine Ermittlung, dass die zweite elektronische Steuereinheit in der Lage ist, die Software auszuführen, eine Aufforderung an die zweite elektronische Steuereinheit zu übermitteln, die Software auszuführen; und in Reaktion auf ein Empfangen einer Übermittlung von der zweiten elektronischen Steuereinheit, welche die Annahme der Aufforderung zur Ausführung der Software angibt, die Software auf die zweite elektronische Steuereinheit zu flashen.
  18. Dynamische Softwaremanagementvorrichtung nach Anspruch 17, wobei die zweite elektronische Steuereinheit die Software ausführt.
  19. Dynamische Softwaremanagementvorrichtung nach Anspruch 18, wobei die Anweisungen den Prozessor ferner dazu veranlassen, zur Ausführung der Software zugehörige Daten von der zweiten elektronischen Steuereinheit zu empfangen.
  20. Dynamische Softwaremanagementvorrichtung nach Anspruch 17, wobei das zumindest eine Aufgabenausführungsmerkmal eine Fähigkeit eines jeweiligen Prozessors des einen anderen Prozessors oder der mehreren anderen Prozessoren angibt, eine bestimmte Aufgabe auszuführen.
DE102021100155.2A 2020-01-17 2021-01-07 System und verfahren für dynamisches softwaremanagement Pending DE102021100155A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/746,805 2020-01-17
US16/746,805 US11822955B2 (en) 2020-01-17 2020-01-17 System and method for decentralized vehicle software management

Publications (1)

Publication Number Publication Date
DE102021100155A1 true DE102021100155A1 (de) 2021-07-22

Family

ID=76650495

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021100155.2A Pending DE102021100155A1 (de) 2020-01-17 2021-01-07 System und verfahren für dynamisches softwaremanagement

Country Status (3)

Country Link
US (1) US11822955B2 (de)
CN (1) CN113212330B (de)
DE (1) DE102021100155A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113778643A (zh) * 2021-08-13 2021-12-10 中电科芜湖通用航空产业技术研究院有限公司 无人机任务管理计算机软件架构系统和构型切换方法
CN114872645B (zh) * 2022-05-10 2023-03-17 中国第一汽车股份有限公司 一种车载系统应用管理方法、架构、车辆及介质

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004059505A1 (en) * 2002-12-17 2004-07-15 Systemauto System, method and computer program product for sharing information in a distributed framework
KR100535985B1 (ko) * 2004-06-22 2005-12-09 현대모비스 주식회사 조작력 경감 기능을 갖춘 차량의 백업 조향장치
US20070094270A1 (en) * 2005-10-21 2007-04-26 Callminer, Inc. Method and apparatus for the processing of heterogeneous units of work
JP4921054B2 (ja) * 2006-07-07 2012-04-18 株式会社日立製作所 負荷分散制御システム及び負荷分散制御方法
DE102009029642A1 (de) * 2009-09-21 2011-03-24 Robert Bosch Gmbh Verfahren zur Bearbeitung von Informationen und Aktivitäten in einem steuer- und/oder regelungstechnischen System
US8930710B2 (en) * 2011-10-28 2015-01-06 GM Global Technology Operations LLC Using a manifest to record presence of valid software and calibration
US8978160B2 (en) * 2012-09-12 2015-03-10 GM Global Technology Operations LLC Method for selective software rollback
US9298577B2 (en) * 2012-09-19 2016-03-29 Toyota Jidosha Kabushiki Kaisha Predicting bus idle time based on obtained usage data of a bus
US9057624B2 (en) * 2012-12-29 2015-06-16 Cloudcar, Inc. System and method for vehicle navigation with multiple abstraction layers
IN2013MU02180A (de) * 2013-06-27 2015-06-12 Tata Consultancy Services Ltd
WO2015047411A1 (en) * 2013-09-30 2015-04-02 Schneider Electric Usa Inc. Systems and methods of data acquisition
CN106155807A (zh) * 2015-04-15 2016-11-23 阿里巴巴集团控股有限公司 一种实现资源调度的方法与设备
JP6378128B2 (ja) * 2015-04-28 2018-08-22 ルネサスエレクトロニクス株式会社 性能検証装置、システム、方法、およびコンピュータに当該方法を実行させるためのプログラム
US20160365853A1 (en) * 2015-06-09 2016-12-15 Magna Closures Inc. Electromechanical switch via wiring connector
US10185547B2 (en) * 2015-06-26 2019-01-22 Intel Corporation Techniques for distributed operation of secure controllers
US9910700B2 (en) * 2015-08-26 2018-03-06 Netapp, Inc. Migration between CPU cores
CN106648878B (zh) * 2015-10-29 2021-08-20 华为技术有限公司 一种系统及其动态分配mmio资源的方法
CN105857102B (zh) * 2016-04-08 2017-12-15 同济大学 集中式架构控制器及供电冗余的电动智能汽车电气系统
EP3443432A4 (de) * 2016-04-12 2020-04-01 Guardknox Cyber Technologies Ltd. Speziell programmierte computersysteme mit konfigurierten zugehörigen vorrichtungen zur durchführung sicherer sperrungen und verfahren zur verwendung davon
JP2018001901A (ja) * 2016-06-30 2018-01-11 アイシン精機株式会社 走行支援装置
EP3285165A1 (de) * 2016-08-18 2018-02-21 dSPACE digital signal processing and control engineering GmbH Modifizieren und simulieren der betriebssoftware eines technischen systems
CN106427835B (zh) * 2016-11-07 2018-11-02 合肥创宇新能源科技有限公司 一种新能源汽车电子vcu模块的低功耗休眠电路
US20190373051A1 (en) * 2018-06-05 2019-12-05 International Business Machines Corporation Task Scheduling System for Internet of Things (IoT) Devices
US10800278B2 (en) * 2018-06-07 2020-10-13 Ford Global Technologies, Llc Vehicle low-voltage energy system control
KR102699146B1 (ko) * 2018-12-14 2024-08-27 현대자동차주식회사 게이트웨이 프로세서, 그 제어 로직, 프로그램 및 기록매체
US10991175B2 (en) * 2018-12-27 2021-04-27 Beijing Voyager Technology Co., Ltd. Repair management system for autonomous vehicle in a trusted platform
US11285814B2 (en) * 2019-06-19 2022-03-29 Ford Global Technologies, Llc Discharge testing of vehicle batteries

Also Published As

Publication number Publication date
CN113212330B (zh) 2024-08-20
CN113212330A (zh) 2021-08-06
US20210224104A1 (en) 2021-07-22
US11822955B2 (en) 2023-11-21

Similar Documents

Publication Publication Date Title
DE102017100380A1 (de) Diagnostiktest-durchführungssteuersystem und verfahren
DE102021100155A1 (de) System und verfahren für dynamisches softwaremanagement
DE102020122489A1 (de) Zugriffsautorisierung für verteiltes fahrzeugnetzwerk
DE102021111597A1 (de) Autonomes fahrerrückmeldungssystem und -verfahren
DE102022131657A1 (de) Systeme und verfahren zur fahrzeuganalyse
DE102022105476A1 (de) System und Verfahren zum Aufbauen eines fahrzeugintegrierten Kryptografiemanagers
DE102018119114B4 (de) Fahrzeug, System und Verfahren zur Abschwächung von Fehlern in einer Vorrichtung durch Anwendung von Antriebsdrehmoment
DE102021110946A1 (de) Systeme und verfahren zur fahrzeugmodellierung
DE102021129697A1 (de) Maschinenlernverfahren und Maschinenlernsystem
DE102019111623A1 (de) Lenksteuerapparat und lenksteuerverfahren und lenksystem
DE102021125867A1 (de) Automatisierte detektion von fahrzeugdatenmanipulation und mechanischen ausfällen
DE102023103614A1 (de) Generischer aktor mit einer spezifischen lokalen rückfall-funktion
DE102020125714A1 (de) Systeme und verfahren zur verteilten verarbeitung in einem informationsökosystem
DE102020111600A1 (de) Fehlertolerante steuerung von fahrzeugen mit hinteren lenksystemen
DE102022122375B4 (de) Steer-by-wire-software-endanschlag
DE102022124474A1 (de) Integrierte fahrzeugbetriebsfähigkeitsverwaltungssysteme und -verfahren unter verwendung eines verbesserten fehlermodells für einen diagnose-reasoner
DE102021100153A1 (de) Systeme und verfahren zur echtzeitüberwachung von fahrzeugträgheitsparameterwerten unter verwendung von querdynamik
DE102021124839A1 (de) Stufenloser lenkmodus
DE102020124046A1 (de) Dezentral autorisierte fahrzeugvorgänge
DE102020128235B3 (de) Verfahren, system und vorrichtung zum steuern eines elektronischen servolenkungssystems
DE102022122921A1 (de) Systeme und verfahren zur echtzeit-steuerung von permanentmagnet-synchronmaschinen
CN112612599B (en) System and method for distributed processing within an information ecosystem
DE102022202990B4 (de) Verfahren und Vorrichtung zum verteilten maschinellen Lernen für ein fahrzeugbezogenes Maschinenlernproblem
DE102024109568A1 (de) Systeme und verfahren zur auf zahnstangenkraftaufwand basierenden dämpfung für steer-by-wire lenksysteme
DE102021109434B4 (de) Systeme und Verfahren zur redundanten Buskommunikation einer elektronischen Servolenkung

Legal Events

Date Code Title Description
R012 Request for examination validly filed