DE102019126804A1 - Fahrzeugsoftwareprüfung - Google Patents

Fahrzeugsoftwareprüfung Download PDF

Info

Publication number
DE102019126804A1
DE102019126804A1 DE102019126804.4A DE102019126804A DE102019126804A1 DE 102019126804 A1 DE102019126804 A1 DE 102019126804A1 DE 102019126804 A DE102019126804 A DE 102019126804A DE 102019126804 A1 DE102019126804 A1 DE 102019126804A1
Authority
DE
Germany
Prior art keywords
identifiers
vehicle
computer
local set
status
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
DE102019126804.4A
Other languages
English (en)
Inventor
Vivekananda KRISHNAMURTHY
Amy Beth Cronin
Scott J. Lauffer
Barnabas J. Nemec
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.)
Ford Global Technologies LLC
Original Assignee
Ford Global Technologies LLC
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 Ford Global Technologies LLC filed Critical Ford Global Technologies LLC
Publication of DE102019126804A1 publication Critical patent/DE102019126804A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05DSYSTEMS FOR CONTROLLING OR REGULATING NON-ELECTRIC VARIABLES
    • G05D1/00Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots
    • G05D1/0055Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots with safety arrangements
    • G05D1/0061Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots with safety arrangements for transition from automatic pilot to manual pilot and vice versa
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/0205Diagnosing or detecting failures; Failure detection models
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/04Monitoring the functioning of the control system
    • B60W50/045Monitoring control system parameters
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W60/00Drive control systems specially adapted for autonomous road vehicles
    • B60W60/001Planning or execution of driving tasks
    • B60W60/0015Planning or execution of driving tasks specially adapted for safety
    • B60W60/0018Planning or execution of driving tasks specially adapted for safety by employing degraded modes, e.g. reducing speed, in response to suboptimal conditions
    • B60W60/00186Planning or execution of driving tasks specially adapted for safety by employing degraded modes, e.g. reducing speed, in response to suboptimal conditions related to the vehicle
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05DSYSTEMS FOR CONTROLLING OR REGULATING NON-ELECTRIC VARIABLES
    • G05D1/00Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots
    • G05D1/0088Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots characterized by the autonomous decision making process, e.g. artificial intelligence, predefined behaviours
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766Error or fault reporting or storing
    • G06F11/0778Dumping, i.e. gathering error/state information after a fault for later diagnosis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3688Test management for test execution, e.g. scheduling of test suites
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00Registering or indicating the working of vehicles
    • G07C5/08Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0808Diagnosing performance data
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/0205Diagnosing or detecting failures; Failure detection models
    • B60W2050/021Means for detecting failure or malfunction
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2556/00Input parameters relating to data
    • B60W2556/45External transmission of data to or from the vehicle
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W60/00Drive control systems specially adapted for autonomous road vehicles
    • B60W60/005Handover processes
    • B60W60/0051Handover processes from occupants to vehicle

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Human Computer Interaction (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Remote Sensing (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Artificial Intelligence (AREA)
  • Evolutionary Computation (AREA)
  • Game Theory and Decision Science (AREA)
  • Medical Informatics (AREA)
  • Business, Economics & Management (AREA)
  • Biomedical Technology (AREA)
  • Hardware Redundancy (AREA)
  • Traffic Control Systems (AREA)

Abstract

Die vorliegende Offenbarung stellt eine Fahrzeugsoftwareprüfung bereit. Ein Computer beinhaltet einen Prozessor und einen Speicher, der Anweisungen speichert, die von dem Prozessor ausführbar sind, um bei Bestimmung, dass ein lokaler Satz Kennungen nicht mit einem aus der Ferne übermittelten Satz Kennungen übereinstimmt, zu verhindern, dass ein Fahrzeug in einen autonomen Modus eintritt, oder das Fahrzeug anzuweisen, einen Zustand mit minimalem Risiko auszuführen.

Description

  • TECHNISCHES GEBIET
  • Diese Offenbarung betrifft allgemein Fahrzeugcomputer und -software.
  • ALLGEMEINER STAND DER TECHNIK
  • Moderne Kraftfahrzeuge, insbesondere Fahrzeuge, die zu autonomem Betrieb fähig sind, beinhalten in der Regel eine Vielzahl von elektronischen Steuereinheiten oder -modulen (electronic control unit - ECU). Die ECUs sind Computer. Rechenaufgaben eines Fahrzeugs können nach Funktion unter den ECUs aufgeteilt werden; ein Hybridantriebsstrangsteuermodul kann einen Hybridantriebsstrang des Fahrzeugs steuern, ein Rückhaltesteuermodul kann Airbags und Vorspanner steuern und so weiter.
  • KURZDARSTELLUNG
  • Das unten beschriebene System verbessert den Betrieb eines Fahrzeugs durch Steuern des Betriebs von Software und Hardware. Wenn Nichtübereinstimmungen auftreten, kann das Fahrzeug durch Ergreifen von Sicherheitsmaßnahmen reagieren, die für den Fahrzeugkontext geeignet sind. Das System kann einem Flottenbetreiber mehr Kontrolle über eine Fahrzeugflotte ermöglichen. Das System kann Fahrzeugeffizienz und -sicherheit verbessern und zeitnahe und korrekte Wartung für das Fahrzeug sicherstellen, indem es Hardware identifiziert und Software auf dem neuesten Stand hält und eine Fehlinstallation erkennt.
  • Ein Computer beinhaltet einen Prozessor und einen Speicher, der Anweisungen speichert, die von dem Prozessor ausführbar sind, um bei Bestimmung, dass ein lokaler Satz Kennungen nicht mit einem aus der Ferne übermittelten Satz Kennungen übereinstimmt, zu verhindern, dass ein Fahrzeug in einen autonomen Modus eintritt, oder das Fahrzeug anzuweisen, einen Zustand mit minimalem Risiko auszuführen.
  • Die Anweisungen können ferner beinhalten, bei Bestimmung, dass der lokale Satz Kennungen nicht mit dem aus der Ferne übermittelten Satz Kennungen übereinstimmt, ein Software-Update von einem entfernten Server zu empfangen. Die Anweisungen können ferner beinhalten, bei Empfang des Software-Updates einen Übereinstimmungsstatus von einem Fehlerhaft-Status auf einen Annehmbar-Status einzustellen und als Reaktion darauf, dass der Übereinstimmungsstatus vom Fehlerhaft-Status schneller als ein Zeitschwellenwert zum Annehmbar-Status wechselt, einen Diagnoseproblemcode einzustellen.
  • Die Kennungen können Konfigurationskennungen beinhalten.
  • Die Anweisungen können ferner beinhalten, regelmäßig die Kennungen von Fahrzeugkomponenten anzufordern und die zurückgesendeten Kennungen im lokalen Satz Kennungen zu speichern.
  • Der lokale Satz Kennungen kann ein aktueller lokaler Satz Kennungen sein, und die Anweisungen können ferner beinhalten, bei Bestimmung, dass der aktuelle lokale Satz Kennungen nicht mit einem vorherigen lokalen Satz Kennungen übereinstimmt, den aktuellen lokalen Satz Kennungen an einen entfernten Server zu übertragen, der den aus der Ferne übermittelten Satz Kennungen übermittelt.
  • Das Ausführen des Zustands mit minimalem Risiko kann Fahren des Fahrzeugs an einen festgelegten Ort beinhalten.
  • Der lokale Satz Kennungen kann in einem Speicher an Bord des Fahrzeugs gespeichert sein.
  • Der aus der Ferne übermittelte Satz Kennungen kann in einem vom Fahrzeug entfernten Speicher gespeichert sein.
  • Die Anweisungen können ferner beinhalten, zu bestimmen, dass der lokale Satz Kennungen nicht mit dem aus der Ferne übermittelten Satz Kennungen übereinstimmt, indem bestimmt wird, dass wenigstens eine Kennung im lokalen Satz Kennungen anders als eine jeweilige Kennung in dem aus der Ferne übermittelten Satz Kennungen ist.
  • Ein Verfahren beinhaltet bei Bestimmung, dass ein lokaler Satz Kennungen nicht mit einem aus der Ferne übermittelten Satz Kennungen übereinstimmt, Verhindern, dass ein Fahrzeug in einen autonomen Modus eintritt, oder Anweisen des Fahrzeugs, einen Zustand mit minimalem Risiko auszuführen.
  • Das Verfahren kann ferner bei Bestimmung, dass der lokale Satz Kennungen nicht mit dem aus der Ferne übermittelten Satz Kennungen übereinstimmt, das Empfangen eines Software-Updates von einem entfernten Server beinhalten. Das Verfahren kann ferner bei Empfang des Software-Updates das Einstellen einen Übereinstimmungsstatus von einem Fehlerhaft-Status auf einen Annehmbar-Status und als Reaktion darauf, dass der Übereinstimmungsstatus vom Fehlerhaft-Status schneller als ein Zeitschwellenwert zum Annehmbar-Status wechselt, Einstellen eines Diagnoseproblemcodes beinhalten.
  • Die Kennungen können Konfigurationskennungen beinhalten.
  • Das Verfahren kann ferner regelmäßiges Anfordern der Kennungen von Fahrzeugkomponenten und Speichern der zurückgesendeten Kennungen im lokalen Satz Kennungen beinhalten.
  • Der lokale Satz Kennungen kann ein aktueller lokaler Satz Kennungen sein, und das Verfahren kann ferner bei Bestimmung, dass der aktuelle lokale Satz Kennungen nicht mit einem vorherigen lokalen Satz Kennungen übereinstimmt, Übertragen des aktuellen lokalen Satzes Kennungen an einen entfernten Server, der den aus der Ferne übermittelten Satz Kennungen übermittelt, beinhalten.
  • Das Ausführen des Zustands mit minimalem Risiko kann Fahren des Fahrzeugs an einen festgelegten Ort beinhalten.
  • Der lokale Satz Kennungen ist in einem Speicher an Bord des Fahrzeugs gespeichert.
  • Der aus der Ferne übermittelte Satz Kennungen kann in einem vom Fahrzeug entfernten Speicher gespeichert sein.
  • Das Verfahren kann ferner das Bestimmen beinhalten, dass der lokale Satz Kennungen nicht mit dem aus der Ferne übermittelten Satz Kennungen übereinstimmt, indem bestimmt wird, dass wenigstens eine Kennung im lokalen Satz Kennungen anders als eine jeweilige Kennung in dem aus der Ferne übermittelten Satz Kennungen ist.
  • Figurenliste
    • 1 ist ein Blockschaubild eines beispielhaften Fahrzeugs.
    • 2 ist ein Prozessablaufdiagramm eines beispielhaften Prozesses zum Verwalten von Hardware und Software für das Fahrzeug aus 1.
    • 3 ist ein Prozessablaufdiagramm eines beispielhaften Prozesses zum Überprüfen des Kommunikationssystems des Fahrzeugs aus 1.
    • 4 ist ein Prozessablaufdiagramm eines beispielhaften Prozesses zum Prüfen der Übereinstimmung von Hardware und Software für das Fahrzeug aus 1.
    • 5 ist ein Prozessablaufdiagramm eines beispielhaften Prozesses zum Reagieren auf nichtübereinstimmende Hardware oder Software für das Fahrzeug aus 1.
    • 6 ist ein Prozessablaufdiagramm eines beispielhaften Prozesses zum Aktualisieren von Software für das Fahrzeug aus 1.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Unter Bezugnahme auf die Figuren beinhaltet ein Computer 30 einen Prozessor und einen Speicher, der Anweisungen speichert, die von dem Prozessor ausführbar sind, um bei Bestimmung, dass ein lokaler Satz Kennungen nicht mit einem aus der Ferne übermittelten Satz Kennungen übereinstimmt, zu verhindern, dass ein Fahrzeug 32 in einen autonomen Modus eintritt, oder das Fahrzeug 32 anzuweisen, einen Zustand mit minimalem Risiko, wie er unten definiert ist, auszuführen.
  • Unter Bezugnahme auf 1 kann das Fahrzeug 32 ein beliebiges Personen- oder Nutzkraftfahrzeug sein, wie etwa ein Auto, ein Lastwagen, ein SUV, ein Crossover-Fahrzeug, ein Van, ein Minivan, ein Taxi, ein Bus usw.
  • Das Fahrzeug 32 kann ein autonomes Fahrzeug sein. Ein Fahrzeugcomputer 34 kann dazu programmiert sein, das Fahrzeug 32 vollständig oder in geringerem Maße unabhängig vom Eingreifen eines menschlichen Fahrers zu betreiben. Der Fahrzeugcomputer 34 kann dazu konfiguriert sein, den Antrieb 36, ein Bremssystem 38, eine Lenkung 40 und/oder andere Fahrzeugsysteme zu betreiben. Der Fahrzeugcomputer 34 kann fähig sein, zwischen unterschiedlichen Modi der Autonomie zu wechseln, z. B. einem oder mehreren autonomen Modi und einem nicht autonomen Modus. Zu Zwecken dieser Offenbarung bedeutet autonomer Betrieb, dass der Fahrzeugcomputer 34 den Antrieb 36, das Bremssystem 38 und die Lenkung 40 ohne Eingabe eines menschlichen Fahrers steuert; halbautonomer Betrieb bedeutet, dass der Computer 34 eins oder zwei von dem Antrieb 36, dem Bremssystem 38 und dem Lenksystem 40 steuert und ein menschlicher Fahrer den Rest steuert; und nichtautonomer Betrieb bedeutet, dass ein menschlicher Fahrer den Antrieb 36, das Bremssystem 38 und der Lenkung 40 steuert. Ein autonomer Modus bedeutet, dass der Fahrzeugcomputer 34 einen autonomen oder halbautonomen Betrieb bereitstellt. Ein nicht autonomer Modus bedeutet, dass der Fahrzeugcomputer 34 einen nicht autonomen Betrieb bereitstellt.
  • Bei dem Computer 30 handelt es sich um einen oder mehrere Computer auf Mikroprozessorbasis. Der Computer 30 beinhaltet einen Speicher, wenigstens einen Prozessor usw. Der Speicher des Computers 30 beinhaltet Medien zum Speichern von Anweisungen, die von dem Prozessor ausführbar sind, sowie zum elektronischen Speichern von Daten und/oder Datenbanken. Der Computer 30 kann derselbe Computer wie der Fahrzeugcomputer 34 sein, oder bei dem Computer 30 kann es sich um einen oder mehrere separate Computer handeln, die mit dem Fahrzeugcomputer 34 über ein Kommunikationsnetz 42 in Verbindung stehen, oder der Computer 30 kann mehrere Computer einschließlich des Fahrzeugcomputers 34 einschließen. Als ein separater Computer kann der Computer 30 eine oder mehrere elektronische Steuereinheiten oder -module (electronic control unit - ECU) 44 wie etwa ein Enhanced Central Gateway (ECG) 46 und/oder ein Schnittstellenmodul für ein automatisiertes Fahrsystem (automated-driving-system interface module - ADSIM) 48 sein oder beinhalten.
  • Der Fahrzeugcomputer 34 ist ein Computer auf Mikroprozessorbasis. Der Fahrzeugcomputer 34 beinhaltet einen Prozessor, einen Speicher usw. Der Speicher des Fahrzeugcomputers 34 beinhaltet Medien zum Speichern von Anweisungen, die von dem Prozessor ausführbar sind, sowie zum elektronischen Speichern von Daten und/oder Datenbanken.
  • Die ECUs 44 sind Computer auf Mikroprozessorbasis. Die ECUs 44 beinhalten jeweils einen Prozessor, Speicher usw. Der Speicher jeder ECU 44 beinhaltet Medien zum Speichern von Anweisungen, die von dem jeweiligen Prozessor ausführbar sind, sowie zum elektronischen Speichern von Daten und/oder Datenbanken. Das ECG 46 plant und führt Kommunikationen zwischen den ECUs 44 aus. Das ADSIM 48 übernimmt nicht fahrerbezogene Aufgaben im Zusammenhang mit dem autonomen Betrieb. Andere ECUs 44 können ein Karosseriesteuermodul 50, eine Antiblockiermodul 52, ein Servolenkungssteuermodul 54, ein Verbrennungsmotorsteuermodul 56, ein Rückhaltesteuermodul 58, ein Steuermodul 60 für einen Hybridantriebsstrang, DC/DC-Wandler 62, Leistungsverteilungskästen 64, ein Batterieelektroniksteuermodul 66 und ein Gangschaltmodul 68 beinhalten.
  • Der Computer 30 kann Signale durch ein Kommunikationsnetz 42 (etwa einen CAN(Controller Area Network)-Bus), Ethernet, Wi-Fi, Local Interconnect Network (LIN), einen bordeigenen Diagnoseanschluss (onboard diagnostics connector - OBD-II) und/oder durch ein beliebiges anderes drahtgebundenes oder drahtloses Kommunikationsnetz senden und empfangen. Der Computer 30 kann über das Kommunikationsnetz 42 kommunikationsfähig an den Fahrzeugcomputer 34, den Antrieb 36, das Bremssystem 38, die Lenkung 40, die ECUs 44, Sensoren 70, einen Sender-Empfänger 72 und andere Komponenten gekoppelt sein.
  • Der Antrieb 36 des Fahrzeugs 32 erzeugt Energie und wandelt die Energie in eine Bewegung des Fahrzeugs 32 um. Bei dem Antrieb 36 kann es sich um ein übliches Fahrzeugantriebssubsystem handeln, beispielsweise einen üblichen Antriebsstrang, der einen Verbrennungsmotor beinhaltet, der an ein Getriebe gekoppelt ist, das Drehbewegung an Räder überträgt; einen elektrischen Antriebsstrang mit Batterien, einem Elektromotor und einem Getriebe, das Drehbewegung an Räder überträgt; einen Hybridantriebsstrang mit Elementen des üblichen Antriebsstrangs und des elektrischen Antriebsstrangs; oder eine beliebige andere Art von Antrieb. Der Antrieb 36 kann eine elektronische Steuereinheit (ECU) oder dergleichen beinhalten, die mit dem Fahrzeugcomputer 34 und/oder einem menschlichen Fahrer in Kommunikationsverbindung steht und Eingaben davon empfängt, z. B. das Steuermodul 60 des Hybridantriebsstrangs. Der menschliche Fahrer kann den Antrieb 36 z. B. über ein Gaspedal und/oder einen Schalthebel steuern.
  • Das Bremssystem 38 ist in der Regel ein übliches Fahrzeugbremssubsystem und wirkt der Bewegung des Fahrzeugs 32 entgegen, um das Fahrzeug 32 dadurch abzubremsen und/oder anzuhalten. Das Bremssystem 38 kann Reibungsbremsen wie etwa Scheibenbremsen, Trommelbremsen, Bandbremsen.; regenerative Bremsen; beliebige andere geeignete Arten von Bremsen; oder eine Kombination beinhalten. Das Bremssystem 38 kann eine elektronische Steuereinheit (ECU) oder dergleichen beinhalten, die mit dem Fahrzeugcomputer 34 und/oder einem menschlichen Fahrer in Kommunikationsverbindung steht und Eingaben davon empfängt, z. B. das Antiblockiermodul 52. Der menschliche Fahrer kann das Bremssystem 38 z. B. über ein Bremspedal steuern.
  • Die Lenkung 40 ist in der Regel ein übliches Fahrzeuglenkungssubsystem und steuert das Lenken der Räder. Die Lenkung 40 kann ein Zahnstangensystem mit elektrischer Servolenkung, ein Steer-by-Wire-System, wie jeweils bekannt, oder ein beliebiges anderes geeignetes System sein. Die Lenkung 40 kann eine elektronische Steuereinheit (ECU) oder dergleichen beinhalten, die mit dem Fahrzeugcomputer 34 und/oder einem menschlichen Fahrer in Kommunikationsverbindung steht und Eingaben davon empfängt, z. B. das Servolenkungssteuermodul 54. Der menschliche Fahrer kann die Lenkung 40 z. B. über ein Lenkrad steuern.
  • Die Sensoren 70 können Daten zum Betrieb des Fahrzeugs 32 bereitstellen, beispielsweise Raddrehzahl, Radausrichtung und Motor- und Getriebedaten (z. B. Temperatur, Kraftstoffverbrauch usw.). Die Sensoren 70 können die Position und/oder Ausrichtung des Fahrzeugs 32 erfassen. Die Sensoren 70 können beispielsweise GPS(global positioning system)-Sensoren; Beschleunigungsmesser wie etwa piezoelektrische oder mikroelektromechanische Systeme (MEMS); Kreisel wie etwa Wendekreisel oder Ringlaserkreisel oder faseroptische Kreisel; Inertialnavigationssysteme (inertial measurements unit - IMU); und Magnetometer beinhalten. Die Sensoren 70 können die Außenwelt erfassen, z. B. Objekte und/oder Eigenschaften der Umgebung des Fahrzeugs 32, wie etwa andere Fahrzeuge, Spurmarkierungen, Verkehrsampeln und/oder -schilder, Fußgänger usw. Die Sensoren 70 können beispielsweise Radarsensoren, Laserabtastungsentfernungsmesser, LIDAR(light detection and ranging)-Vorrichtungen und Bildverarbeitungssensoren wie etwa Kameras beinhalten.
  • Der Sender-Empfänger 72 kann dazu ausgebildet sein, Signale drahtlos durch ein beliebiges geeignetes Kommunikationsprotokoll zu übertragen, wie etwa Bluetooth®, Wi-Fi, IEEE 802.11a/b/g, andere RF(radio frequency - Hochfrequenz)-Kommunikation usw. Der Sender-Empfänger 72 kann eine Vorrichtung sein oder einen separaten Sender und Empfänger beinhalten. Der Sender-Empfänger 72 kann dazu ausgebildet sein, mit einem entfernten Server, also einem Server 74, der von dem Fahrzeug 32 getrennt und beabstandet ist, durch ein Netz 76 zu kommunizieren.
  • Der entfernte Server 74 ist außerhalb des Fahrzeugs 32 angeordnet. Der entfernte Server 74 kann beispielsweise in anderen Fahrzeugen (z. B. C2C-Kommunikation), Infrastrukturkomponenten (z. B. C2I-Kommunikation mittels Dedicated Short-Range Communications (DSRC) oder dergleichen), Notrufbeantwortern, mobilen Vorrichtungen, die dem Eigentümer des Fahrzeugs 32 zugeordnet sind, usw. enthalten sein. Der entfernte Server 74 kann einen Server und einen Datenspeicher beinhalten.
  • Der Sender-Empfänger 72 kann sich durch das Netz 76 mit dem entfernten Server 74 verbinden. Das Netz 76 stellt einen oder mehrere Mechanismen dar, mit denen der Computer 30 mit dem entfernten Server 74 kommunizieren kann. Entsprechend kann es sich bei dem Netz 76 um einen oder mehrere von verschiedenen drahtgebundenen oder drahtlosen Kommunikationsmechanismen handeln, darunter jede gewünschte Kombination aus drahtgebundenen (z. B. Kabel und Faser) und/oder drahtlosen (z. B. Mobilfunk, drahtlos, Satellit, Mikrowelle und Hochfrequenz) Kommunikationsmechanismen und jede beliebige gewünschte Netztopologie (oder Topologien, wenn mehrere Kommunikationsmechanismen benutzt werden). Beispielhafte Kommunikationsnetze beinhalten drahtlose Kommunikationsnetze (z.B. unter Verwendung von Bluetooth, IEEE 802.11 usw.), lokale Netze (local area networks - LAN) und/oder Weitverkehrsnetze (wide area networks - WAN) einschließlich des Internets, die Datenkommunikationsdienste bereitstellen.
  • Einige Komponenten des Fahrzeugs 32 weisen Kennungen auf. In diesem Zusammenhang ist „Kennung“ als eine Kennzeichnung oder Einstellung definiert, die für eine Komponente im Wesentlichen eindeutig ist. Eine Kennung kann eine Hardwarekennung, d. h. eine Kennzeichnung, die eine physische Komponente des Fahrzeugs 32 eindeutig identifiziert; eine Softwarekennung, d. h. eine Kennzeichnung, die ein Softwareelement wie etwa ein Programm, eine Anwendung, ein Betriebssystem usw. eindeutig identifiziert; oder eine Konfigurationskennung sein, d. h. eine Spezifikation von einer oder mehreren Einstellungen, die für eine Komponente gelten, z. B. zur Stabilitätssteuerung, Blockierverhinderung usw. Eine Komponente kann beispielsweise eine Hardwarekennung, mehrere Softwarekennungen und eine oder mehrere Konfigurationskennungen aufweisen. Jede beliebige Komponente, die elektronisch mit dem Computer 30 verbunden ist, z. B. die ECUs 44, die Sensoren 70 usw., kann ihre eigenen Kennungen speichern und diese Kennungen als Reaktion auf eine Abfrage zurücksenden. Der Computer 30, z. B. das ECG 46, speichert Kennungen der Komponenten des Fahrzeugs 32 in Speicher, wobei diese hierin durchweg als ein lokaler Satz Kennungen bezeichnet werden. Der entfernte Server 74 speichert jeweilige Kennungen derselben Komponenten in einem Speicher entfernt vom Fahrzeug 32, die hierin durchweg als ein aus der Ferne übermittelter Satz Kennungen bezeichnet werden. Der aus der Ferne übermittelte Satz Kennungen kann eine „Stammliste“, d. h. eine kuratierte Liste von Kennungen bezüglich der aktuellsten Hardware, Software und/oder Konfigurationen sein.
  • 2 ist ein Prozessablaufdiagramm, das einen beispielhaften Prozess 200 zum Verwalten von Hardware und Software für das Fahrzeug 32 veranschaulicht. Der Speicher des Computers 30 speichert ausführbare Anweisungen zum Ausführen der Schritte des Prozesses 200. Während das Fahrzeug 32 im Laufe der Zeit gewartet und repariert wird und von den ECUs ausgeführte Software im Laufe der Zeit aktualisiert wird, können Fehler im Fahrzeug 32 auftreten, indem die falsche Komponente installiert wird oder eine nichtübereinstimmende Softwareversion installiert wird. Als nicht einschränkende allgemeine Übersicht über den Prozess 200 prüft der Computer 30 die Nachrichtenaustauschfähigkeiten des Fahrzeugs 32 und prüft die Übereinstimmung des lokalen Satzes Kennungen für die Hardware und Software des Fahrzeugs 32 mit dem aus der Ferne übermittelten Satz Kennungen, wie nachstehend ausführlicher beschrieben; bei Übereinstimmung stellt der Computer 30 einen Übereinstimmungsstatus auf „OK“ ein und fährt mit dem Prüfen fort; bei Nichtübereinstimmung führt der Computer 30 Fehlermodusmanagement durch, wenn die Nichtübereinstimmung eine Hardwarekennung oder eine Konfigurationskennung betrifft, und führt ein Software-Update aus (das ebenfalls das Fehlermodusmanagement beinhalten kann), wenn die Nichtübereinstimmung eine Softwarekennung betrifft.
  • Der Prozess 200 beginnt mit dem Ausführen eines Prozesses 300 zum Überprüfen, dass Kommunikationssysteme des Fahrzeugs 32 betriebsfähig sind, wie nachstehend ausführlicher beschrieben. Wenn der Prozess 300 ergibt, dass Fehlermodusmanagement-Maßnahmen ergriffen werden, wie unten beschrieben, wird der Prozess 200 unterbrochen und fährt nicht fort.
  • Nach dem erfolgreichen Abschluss des Prozesses 300 wird der Prozess 200 durch Ausführen eines Prozesses 400 zum Prüfen der Übereinstimmung von Hardware und Software für das Fahrzeug 32 fortgesetzt, wie nachstehend ausführlicher beschrieben. Als Ergebnis des Durchführens des Prozesses 400 hat der Computer 30 eine Antwort vom entfernten Server 74 empfangen, die etwaige Nichtübereinstimmungen zwischen dem lokalen Satz Kennungen und dem aus der Ferne übermittelten Satz Kennungen aufführt.
  • Nach Abschluss des Prozesses 400 fährt der Prozess 200 als Nächstes in einem Entscheidungsblock 205 fort. Im Entscheidungsblock 205 bestimmt der Computer 30, ob der lokale Satz Kennungen nicht mit dem aus der Ferne übermittelten Satz Kennungen übereinstimmt, indem er z. B. die Antwort vom entfernten Server 74 prüft, die Nichtübereinstimmungen aufführt. Zu Zwecken dieser Offenbarung ist „nichtübereinstimmend“ für zwei geordnete Sätze so definiert, dass ein Element eines Satzes sich von dem jeweiligen Element des anderen Satzes unterscheidet. Der lokale Satz Kennungen „stimmt nicht überein“ mit dem aus der Ferne übermittelten Satz Kennungen, wenn wenigstens eine Kennung in dem lokalen Satz Kennungen anders als eine jeweilige Kennung in dem aus der Ferne übermittelten Satz Kennungen ist, z. B. eine der Softwarekennungen für das Karosseriesteuermodul 50 anders als die entsprechend aus der Ferne übermittelte Softwarekennung für das Karosseriesteuermodul 50 ist. Ob Kennungen unterschiedlich sind, kann durch Strangabgleich, z. B. durch den entfernten Server 74, bestimmt werden, wenn er die Antwort mit den Nichtübereinstimmungen zusammenstellt. Wenn der lokale Satz Kennungen nicht mit dem aus der Ferne übermittelten Satz Kennungen übereinstimmt, fährt der Prozess 200 mit einem Entscheidungsblock 215 fort.
  • Wenn der lokale Satz Kennungen mit dem aus der Ferne übermittelten Satz Kennungen übereinstimmt, stellt der Computer 30 als Nächstes in einem Block 210 einen Übereinstimmungsstatus auf einen Annehmbar-Status, z. B. „OK“ ein, d. h. eine Einstellung, die anzeigt, dass keine Probleme mit den Kennungen vorliegen. Der Übereinstimmungsstatus kann für eine beliebige Kennung gelten oder der Übereinstimmungsstatus kann für eine spezifische Art Kennung gelten, z. B. ein Hardwarekennungsübereinstimmungsstatus, ein Softwarewarekennungsübereinstimmungsstatus und ein Konfigurationskennungsübereinstimmungsstatus. Der Übereinstimmungsstatus kann an die verschiedenen ECUs 44 übertragen werden, deren Programmierung den Übereinstimmungsstatus berücksichtigen kann. Nach dem Block 210 kehrt der Prozess 200 zur Durchführung des Prozesses 400 zurück, um die Übereinstimmung der Kennungen regelmäßig zu prüfen.
  • Wenn nach dem Entscheidungsblock 205 der lokale Satz Kennungen nicht mit dem aus der Ferne übermittelten Satz Kennungen übereinstimmt, fährt der Prozess 200 mit dem Entscheidungsblock 215 fort. Im Entscheidungsblock 215 bestimmt der Computer 30, ob die Nichtübereinstimmung zwischen dem lokalen Satz Kennungen und dem aus der Ferne übermittelten Satz Kennungen eine Softwarekennung, eine Hardwarekennung oder eine Konfigurationskennung ist.
  • Wenn die Nichtübereinstimmung eine Hardwarekennung oder eine Konfigurationskennung betrifft, fährt der Prozess 200 fort, indem er einen Prozess 500 für Fehlermodusmanagement ausführt, der unten beschrieben ist. Nach Abschluss des Prozesses 500 endet der Prozess 200.
  • Wenn die Nichtübereinstimmung eine Softwarekennung betrifft, fährt der Prozess 200 fort, indem er einen Prozess 600 zum Aktualisieren der Software des Fahrzeugs 32 ausführt (was das Ausführen des Prozesses 500 für Fehlermodusmanagement beinhalten kann). Nach dem Abschluss des Prozesses 600 kehrt der Prozess 200 zur Durchführung des Prozesses 400 zurück, um die Übereinstimmung der Kennungen regelmäßig zu prüfen.
  • 3 ist ein Prozessablaufdiagramm des Prozesses 300 zum Überprüfen, ob die Kommunikationssysteme des Fahrzeugs 32 betriebsfähig sind. Der Speicher des Computers 30, z. B. des ADSIM 48, speichert ausführbare Anweisungen zum Ausführen der Schritte des Prozesses 300. Als allgemeine Übersicht über den Prozess 300 prüft der Computer 30, ob eine interne Nachricht innerhalb eines Zeitschwellenwerts empfangen wird und ob ein Kontakt zu dem entfernten Server 74 möglich ist; wenn beides fehlschlägt, führt der Computer 30 Fehlermodusmanagement aus.
  • Der Prozess 300 beginnt in einem Block 305, in dem der Computer 30 eine interne Nachricht sendet, d. h. eine Nachricht von einer ECU 44 an eine andere ECU 44 im Fahrzeug 32. Beispielsweise kann das ECG 46 eine Statusnachricht an das ADSIM 48 senden.
  • Als Nächstes bestimmt der Computer 30 in einem Entscheidungsblock 310, ob die interne Nachricht innerhalb eines Zeitschwellenwerts empfangen wurde. Der Zeitschwellenwert kann so gewählt werden, dass er knapp lang genug ist, damit im Wesentlichen alle internen Nachrichten zugestellt werden sollten, solange keine Fehlfunktion vorliegt. Wenn die interne Nachricht nicht innerhalb des Zeitschwellenwerts empfangen wird, fährt der Prozess 300 mit dem Ausführen des Prozesses 500 für Fehlermodusmanagement fort.
  • Wenn die interne Nachricht innerhalb des Zeitschwellenwerts empfangen wird, bestimmt der Computer 30 in Block 315, ob ein Kontakt zu dem entfernten Server 74 möglich ist. Der Computer 30 kann eine voreingestellte Anzahl Nachrichten über den Sender-Empfänger 72 an den entfernten Server 74 übertragen, ohne eine Antwort zu empfangen, bis er daraus schließt, dass kein Kontakt zu dem entfernten Server 74 möglich ist. Die voreingestellte Anzahl Nachrichten kann so gewählt werden, dass wenigstens ein erfolgreicher Austausch stattfindet, wenn ein Signal vom entfernten Server 74 ausreichend stark für zuverlässige Kommunikation ist. Wenn Kontakt zum entfernten Server 74 hergestellt wurde, endet der Prozess 300.
  • Der Prozess 300 fährt mit dem Ausführen des Prozesses 500 fort, wenn nach dem Entscheidungsblock 310 die interne Nachricht nicht innerhalb des Zeitschwellenwerts empfangen wird oder im Entscheidungsblock 315 kein Kontakt mit dem entfernten Server 74 hergestellt wurde. Nach dem Ausführen des Prozesses 500 endet der Prozess 300. Wenn der Prozess 300 als Teil des Prozesses 200 ausgeführt wurde, wird der Prozess 200 unterbrochen und nicht fortgesetzt.
  • 4 ist ein Prozessablaufdiagramm des beispielhaften Prozesses 400 zum Prüfen der Übereinstimmung von Hardware und Software für das Fahrzeug 32. Der Speicher des Computers 30 speichert ausführbare Anweisungen zum Durchführen der Schritte des Prozesses 400. Der Computer 30 kann den Prozess 400 regelmäßig ausführen, z. B. mit einer voreingestellten Häufigkeit oder bei einem Auslöser wie etwa dem Anlassen des Fahrzeugs 32. Als allgemeine Übersicht über den Prozess 400 befragt der Computer 30 Komponenten des Fahrzeugs 32 hinsichtlich ihrer Kennungen, speichert die Kennungen, und sendet den lokalen Satz Kennungen an den entfernten Server 74, wenn der lokale Satz Kennungen nicht mit einem vorherigen lokalen Satz Kennungen übereinstimmt oder wenn eine voreingestellte Zeitspanne abgelaufen ist, und empfängt eine Antwort.
  • Der Prozess 400 beginnt in einem Block 405, in dem der Computer 30 die Kennungen von Komponenten des Fahrzeugs 32 anfordert. Das ECG 46 überträgt Anforderungen durch das Kommunikationsnetz 42 an die Komponenten wie etwa die ECUs 44, die mit ihren Softwarekennungen, Hardwarekennungen und/oder Konfigurationskennungen antworten.
  • In einem Block 410 speichert der Computer 30 als Nächstes die zurückgesendeten Kennungen im lokalen Satz Kennungen. Der lokale Satz Kennungen ist im Speicher des Computers 30, d. h. an Bord des Fahrzeugs 32 gespeichert.
  • Als Nächstes bestimmt der Computer 30 in einem Entscheidungsblock 415, ob der aktuelle lokale Satz Kennungen mit einem vorherigen lokalen Satz Kennungen übereinstimmt. Der vorherige lokale Satz Kennungen wurde während einer früheren Iteration des Prozesses 400 im Block 410 gespeichert. Wenn kein vorheriger lokaler Satz Kennungen im Speicher gespeichert wurde, gilt der aktuelle lokale Satz Kennungen als übereinstimmend. Wenn der aktuelle lokale Satz Kennungen nicht mit dem vorherigen lokalen Satz Kennungen übereinstimmt, fährt der Prozess 400 mit einem Block 425 fort.
  • Wenn der aktuelle lokale Satz Kennungen mit dem vorherigen lokalen Satz Kennungen übereinstimmt, bestimmt der Computer 30 als Nächstes in einem Entscheidungsblock 420, ob eine voreingestellte Zeitspanne abgelaufen ist. Die voreingestellte Zeitspanne kann lang genug gewählt werden, damit die Möglichkeit besteht, dass sich eine der Kennungen geändert hat. Wenn die voreingestellte Zeitspanne nicht abgelaufen ist, wartet der Prozess 400, bis die voreingestellte Zeitspanne abläuft.
  • Wenn der aktuelle lokale Satz Kennungen im Entscheidungsblock 415 nicht mit dem vorherigen lokalen Satz Kennungen übereinstimmt, oder die voreingestellte Zeitspanne im Entscheidungsblock 420 abgelaufen ist, fährt der Prozess 400 mit Block 425 fort. In Block 425 überträgt der Computer 30 den aktuellen lokalen Satz Kennungen über den Sender-Empfänger 72 an den entfernten Server 74.
  • Als Nächstes empfängt der Computer 30 in einem Block 430 eine Antwort vom entfernten Server 74. Die Antwort vom entfernten Server 74 führt etwaige Nichtübereinstimmungen zwischen dem lokalen Satz Kennungen und dem aus der Ferne übermittelten Satz Kennungen auf. Da der aus der Ferne übermittelten Satz Kennungen auf dem entfernten Server 74 eine „Stammliste“ der aktuellsten Kennungen sein kann, zeigt die Antwort, die Nichtübereinstimmungen aufführt, dem Computer 30 auf effektive Weise, welche Hardware, Software und Konfigurationen nicht mehr aktuell sind. Nach Block 430 endet der Prozess 400.
  • 5 ist ein Prozessablaufdiagramm des Prozesses 500 für Fehlermodusmanagement bei z. B. einer nichtübereinstimmenden Hardware, Software oder Konfiguration für das Fahrzeug 32. Der Speicher des Computers 30 speichert ausführbare Anweisungen zum Durchführen der Schritte des Prozesses 500. Der Prozess 500 kann durch ein Kommunikationsproblem im Prozess 300, eine Nichtübereinstimmung in einer Hardwarekennung oder Konfigurationskennung im Prozess 200 oder eine Nichtübereinstimmung in einer Softwarekennung ausgelöst werden, die den autonomen Betrieb des Prozesses 600 beeinflusst. Als allgemeine Übersicht über den Prozess 500 stellt der Computer 30 einen Übereinstimmungsstatus auf „fehlerhaft“ ein, stellt einen Diagnoseproblemcode ein, führt einen Zustand mit minimalem Risiko für das Fahrzeug 32 aus, wenn sich das Fahrzeug in einem autonomen Modus befindet, und verhindert einen Übergang in den autonomen Modus, wenn sich das Fahrzeug 32 nicht in einem autonomen Modus befindet.
  • Der Prozess 500 beginnt in einem Block 505, in dem der Computer 30 einen Übereinstimmungsstatus auf einen Fehlerhaft-Status, z. B. „fehlerhaft“, einstellt, d. h. eine Einstellung, die eine Nichtübereinstimmung in den Kennungen anzeigt. Der Übereinstimmungsstatus kann an die verschiedenen ECUs 44 übertragen werden, deren Programmierung den Übereinstimmungsstatus berücksichtigen kann.
  • Als Nächstes stellt der Computer 30 in einem Block 510 einen Diagnoseproblemcode ein. Der Diagnoseproblemcode kann von einem Techniker gelesen werden, der das Fahrzeug 32 wartet, z. B. mittels bordeigener Diagnostik wie etwa OBD-II. Der Diagnoseproblemcode kann den Grund angeben, weshalb der Prozess 500 aufgerufen wurde, z. B. dass eine interne Nachricht nicht empfangen wurde, fehlender Kontakt mit dem entfernten Server 74, Kennungsnichtübereinstimmung zwischen dem lokalen Satz Kennungen und dem aus der Ferne übermittelten Satz Kennungen usw.
  • In einem Entscheidungsblock 515 bestimmt der Computer 30 als Nächstes, ob sich der Fahrzeugcomputer 34 in einem autonomen Modus befindet, d. h. autonomer oder halbautonomer Betrieb. Wenn das Fahrzeug 32 sich nicht in einem autonomen Modus befindet, fährt der Prozess 500 mit einem Block 525 fort.
  • Wenn das Fahrzeug 32 sich nicht in einem autonomen Modus befindet, weist der Computer 30 als Nächstes in einem Block 520 das Fahrzeug 32 an, einen Zustand mit minimalem Risiko auszuführen, z. B. weist er den Fahrzeugcomputer 34 an, den Zustand mit minimalem Risiko auszuführen, indem der Antrieb 36, das Bremssystem 38 und die Lenkung 40 gesteuert werden.
  • Zu Zwecken dieser Offenbarung weist der Begriff Zustand mit minimalem Risiko die ihm von der National Highway Traffic Safety Administration (NHTSA) und der Society of Automotive Engineers (SAE) zugewiesene Bedeutung auf: „’Minimal risk condition‘ means low-risk operating condition that an automated driving system automatically resorts to either when a system fails or when the human driver fails to respond appropriately to a request to take over the dynamic driving task.“ (,Zustand mit minimalem Risiko‘ bezeichnet einen Betriebszustand mit niedrigem Risiko, auf den ein automatisches Fahrsystem automatisch zurückgreift, wenn ein System ausfällt oder wenn der menschliche Fahrer auf eine Anforderung, die dynamische Fahraufgabe zu übernehmen, nicht angemessen reagiert). (US-Verkehrsministerium & NHTSA, Automated Driving Systems 2.0: A Vision for Safety, unter 26 (Zitat aus SAE International J3016, International Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles (J3016:Sept2016)).) Beispielsweise kann der Zustand mit minimalem Risiko eine Übergabe an den menschlichen Fahrer; autonomes Fahren des Fahrzeugs 32 an einen Straßenrand, d. h. Anhalten des Fahrzeugs 32 außerhalb von Spuren mit aktivem Verkehr; oder Fahren des Fahrzeugs 32 an einen festgelegten Ort, z. B. eine Reparaturwerkstatt, einleiten. Der Fahrzeugcomputer 34 kann den Zustand mit minimalem Risiko unter Verwendung bekannter Algorithmen für autonomen Betrieb ausführen. Nach Block 520 endet der Prozess 500.
  • Wenn sich das Fahrzeug 32 nach dem Entscheidungsblock 515 nicht in einem autonomen Modus befindet, hindert der Computer 30 in einem Block 525 das Fahrzeug 32 daran, in einen autonomen Modus einzutreten. Beispielsweise kann der Computer 30 Befehle von einem Insassen oder vom entfernten Server 74 zum Aufrufen eines autonomen Modus ignorieren. Nach Block 525 endet der Prozess 500.
  • 6 ist ein Prozessablaufdiagramm des Prozesses 600 zum Aktualisieren von Software für das Fahrzeug 32. Der Speicher des Computers 30 speichert ausführbare Anweisungen zum Durchführen der Schritte des Prozesses 600. Als allgemeine Übersicht über den Prozess 600 führt der Computer 30 den Prozess 500 aus, wenn die Software-Nichtübereinstimmung den autonomen Betrieb beeinflusst, aktualisiert die Software, setzt das Fahrzeug 32 für normalen Betrieb zurück und prüft und speichert die Kennungen.
  • Der Prozess 600 beginnt in einem Block 605, in dem der Computer 30 ein Manifest vom entfernten Server 74 empfängt. Das Manifest führt auf, welche Software oder Konfigurationen, falls zutreffend, nicht mehr aktuell oder anderweitig inkompatibel sind.
  • Als Nächstes bestimmt der Computer 30 in einem Entscheidungsblock 610, ob die nichtübereinstimmende Software zum autonomen Betrieb des Fahrzeugs 32 beiträgt. Der Speicher des Computers 30 kann eine Liste oder Tabelle mit Softwareelementen speichern, die während des autonomen Betriebs verwendet werden, und der Computer 30 kann prüfen, ob die im Manifest aufgeführte Software in der gespeicherten Liste oder Tabelle vorhanden ist. Wenn die Software den autonomen Betrieb beeinflusst, führt der Prozess 600 als Nächstes den Prozess 500 für Fehlermodusmanagement aus, und fährt mit einem Block 615 fort, sobald der Prozess 500 abgeschlossen ist.
  • Wenn die Software nach dem Entscheidungsblock 610 den autonomen Betrieb nicht beeinflusst, oder wenn die Software nach dem Prozess 500 den autonomen Betrieb beeinflusst, fährt der Prozess 600 mit Block 615 fort. Im Block 615 empfängt der Computer 30 ein Software-Update vom entfernten Server 74 und aktiviert das Software-Update. Mit anderen Worten installiert der Computer 30 das Software-Update und entfernt Software, die durch das Software-Update ersetzt wird.
  • In einem Block 620 stellt der Computer 30 als Nächstes den Übereinstimmungsstatus auf einen Annehmbar-Status ein, z. B. „OK“, d. h. eine Einstellung, die angibt, dass keine Probleme mit den Kennungen vorliegen. Der Übereinstimmungsstatus kann an die verschiedenen ECUs 44 übertragen werden, deren Programmierung den Übereinstimmungsstatus berücksichtigen kann. Während des Prozesses 500 wäre der Übereinstimmungsstatus auf „fehlerhaft“ eingestellt gewesen.
  • In einem Entscheidungsblock 625 bestimmt der Computer 30 als Nächstes, ob der Übereinstimmungsstatus schneller als ein Zeitschwellenwert vom Fehlerhaft-Status zum Annehmbar-Status gewechselt ist. Der Zeitschwellenwert kann als geringfügig weniger, z. B. 10 Prozent weniger, als die Zeit zum Empfangen und Aktivieren des Software-Updates gewählt werden; somit zeigt das schnellere Wechseln des Übereinstimmungsstatus vom Fehlerhaft-Status zum Annehmbar-Status als der Zeitschwellenwert an, dass eine Störung aufgetreten ist. Eine Störung bedeutet, dass durch einen anderen Mechanismus als die vorgesehene Operation ausführbarer Anweisungen ein falscher Wert gespeichert wurde; beispielsweise kann eine Störung durch einen unbeabsichtigten Bit-Flip, eine Cyberattacke usw. verursacht werden. Wenn der Übereinstimmungsstatus nach längerer Zeit als der Zeitschwellenwert vom Fehlerhaft-Status zum Annehmbar-Status wechselt, fährt der Prozess 600 mit einem Block 635 fort.
  • Wenn der Übereinstimmungsstatus schneller als ein Zeitschwellenwert vom Fehlerhaft-Status zum Annehmbar-Status gewechselt ist, stellt der Computer 30 als Nächstes in einem Block 630 einen Diagnoseproblemcode ein, der eine Störung im Übereinstimmungsstatus anzeigt. Nach Block 630 führt der Prozess 600 als Nächstes den Prozess 500 für Fehlermodusmanagement aus. Nach dem Ausführen des Prozesses 500 endet der Prozess 600.
  • Als Nächstes, oder nach dem Entscheidungsblock 625, wenn der Übereinstimmungsstatus nach einer längeren Zeit als der Zeitschwellenwert vom Fehlerhaft-Status zum Annehmbar-Status gewechselt ist, fährt der Prozess 600 mit Block 635 fort. In Block 63 5 deaktiviert der Computer 30 die Fehlermodusmanagementoperationen, die während des Prozesses 500 implementiert wurden, und erlaubt also dem Fahrzeug 32, den Zustand mit minimalem Risiko zu verlassen, und erlaubt dem Fahrzeug 32, einen autonomen Modus aufzurufen.
  • Als Nächstes fordert der Computer 30 in einem Block 640 die Kennungen von Komponenten des Fahrzeugs 32 an. Das ECG 46 überträgt Anforderungen durch das Kommunikationsnetz 42 an die Komponenten wie etwa die ECUs 44, die mit ihren Softwarekennungen, Hardwarekennungen und/oder Konfigurationskennungen antworten.
  • In einem Block 645 speichert der Computer 30 als Nächstes die zurückgesendeten Kennungen im lokalen Satz Kennungen. Der lokale Satz Kennungen ist im Speicher des Computers 30, d. h. an Bord des Fahrzeugs 32 gespeichert. Nach Block 645 endet der Prozess 600.
  • Im Allgemeinen können die beschriebenen Rechensysteme und/oder -vorrichtungen beliebige von einer Anzahl von Computerbetriebssystemen benutzen, darunter, ohne darauf beschränkt zu sein Versionen und/oder Arten der Ford Sync®-Anwendung, AppLink/Smart Device Link-Middleware, das Microsoft Automotive®-Betriebssystem, das Microsoft Windows®-Betriebssystem, das Unix-Betriebssystem (z. B. das Solaris®-Betriebssystem, vertrieben von der Oracle Corporation aus Redwood Shores, Kalifornien), das AIX UNIX-Betriebssystem, vertrieben von International Business Machines aus Armonk, New York, das Linux-Betriebssystem, die Betriebssysteme Mac OSX und iOS, vertrieben von Apple Inc. aus Cupertino, Kalifornien, das BlackBerry-Betriebssystem, vertrieben von Blackberry, Ltd. aus Waterloo, Kanada, und das Android-Betriebssystem, entwickelt von Google, Inc. und der Open Handset Alliance, oder die QNX® CAR-Plattform für Infotainment, angeboten von QNX Software Systems. Zu Beispielen für Rechenvorrichtungen gehören, ohne Beschränkung, ein Fahrzeugbordcomputer, ein Arbeitsplatzrechner, ein Server, ein Desktop-, Notebook-, Laptop-oder Handheld-Computer oder ein anderes Rechensystem und/oder eine andere Rechenvorrichtung.
  • Rechenvorrichtungen beinhalten allgemein von einem Computer ausführbare Anweisungen, wobei die Anweisungen von einer oder mehreren Rechenvorrichtungen ausführbar sind, wie sie oben aufgeführt wurden. Von einem Computer ausgeführte Anweisungen können aus Computerprogrammen kompiliert oder interpretiert werden, die mithilfe verschiedener Programmiersprachen und/oder -techniken erstellt wurden, darunter, ohne Einschränkung, und entweder allein oder in Kombination, Java™, C, C++, Matlab, Simulink, Stateflow, Visual Basic, Java Script, Perl, HTML usw. Einige dieser Anwendungen können auf einer virtuellen Maschine, wie etwa der Java Virtual Machine, der virtuellen Maschine Dalvik oder dergleichen kompiliert und ausgeführt werden. Allgemein empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen, z. B. von einem Speicher, einem computerlesbaren Medium usw., und führt diese Anweisungen aus, wodurch ein oder mehrere Prozesse durchgeführt werden, darunter ein oder mehrere hier beschriebene Prozesse. Diese Anweisungen und anderen Daten können durch verschiedene computerlesbare Medien gespeichert und übertragen werden. Eine Datei in einer Rechenvorrichtung ist allgemein eine Sammlung von Daten, die auf einem computerlesbaren Medium gespeichert sind, etwa einem Speichermedium, einem Direktzugriffsspeicher usw.
  • Ein computerlesbares Medium (auch als ein prozessorlesbares Medium bezeichnet) beinhaltet jedes beliebige nicht transitorische (z. B. physische) Medium, das an der Bereitstellung von Daten (z. B. Anweisungen) beteiligt ist, die von einem Computer (z. B. von einem Prozessor eines Computers) gelesen werden können. Ein solches Medium kann viele Formen annehmen, zu denen, ohne darauf beschränkt zu sein, nicht flüchtige Medien und flüchtige Medien gehören. Nicht flüchtige Medien können beispielsweise optische Platten, Magnetplatten und anderen dauerhaften Speicher beinhalten. Zu flüchtigen Medien gehören beispielsweise dynamischer Direktzugriffsspeicher (DRAM), der in der Regel einen Hauptspeicher bildet. Diese Anweisungen können von einem oder mehreren Übertragungsmedien übertragen werden, darunter Koaxialkabel, Kupferdraht und Glasfasern, einschließlich der Drähte, die einen Systembus bilden, der an einen Prozessor einer ECU gekoppelt ist. Zu häufigen Formen computerlesbarer Medien gehören beispielsweise eine Diskette, eine flexible Disk, eine Festplatte, Magnetband, ein beliebiges anderes magnetisches Medium, eine CD-ROM, DVD, ein beliebiges anderes optisches Medium, Lochkarten, Papierband, ein beliebiges anderes physisches Medium mit Lochmustern, ein RAM, ein PROM, ein EPROM, ein FLASH-EEPROM, ein beliebiger anderer Speicherchip oder eine Endlosbandkassette oder ein beliebiges anderes Medium, das ein Computer auslesen kann.
  • Datenbanken, Daten-Repositories oder andere hierin beschriebene Datenspeicher können verschiedene Arten von Mechanismen zum Speichern, Zugreifen auf und Abrufen verschiedener Arten von Daten beinhalten, darunter eine hierarchische Datenbank, einen Satz Dateien in einem Dateisystem, eine Anwendungsdatenbank in einem proprietären Format, ein relationales Datenbankmanagementsystem (RDBMS) usw. Jeder solche Datenspeicher ist allgemein in einer Rechenvorrichtung enthalten, die ein Computerbetriebssystem wie etwa eins der oben erwähnten benutzt, und auf ihn wird in einer oder mehreren verschiedenen Weisen über ein Netz zugegriffen. Ein Dateisystem kann von einem Computerbetriebssystem aus zugänglich sein und kann in verschiedenen Formaten gespeicherte Dateien beinhalten. Ein RDBMS benutzt allgemein die Structured Query Language (SQL), zusätzlich zu einer Sprache zum Erstellen, Speichern, Bearbeiten und Ausführen gespeicherter Abläufe, wie etwa die oben erwähnte Sprache PL/SQL.
  • In einigen Beispielen können Systemelemente als computerlesbare Anweisungen (z. B. Software) auf einer oder mehreren Rechenvorrichtungen (z. B. Servern, Personal-Computern usw.) implementiert sein, die auf ihnen zugeordneten computerlesbaren Medien gespeichert sind (z. B. Disks, Speicher usw.). Ein Computerprogrammprodukt kann diese auf computerlesbaren Medien gespeicherten Anweisungen umfassen, um die hierin beschriebenen Funktionen auszuführen.
  • In den Zeichnungen weisen gleiche Bezugszeichen auf gleiche Elemente hin. Außerdem können einige oder alle dieser Elemente geändert werden. Hinsichtlich der hierin beschriebenen Medien, Prozesse, Systeme, Verfahren, Heuristiken usw. versteht es sich, dass zwar die Schritte dieser Prozesse usw. als in einer bestimmten Abfolge stattfindend beschrieben wurden, diese Prozesse jedoch auch ausgeübt werden können, wenn die beschriebenen Schritte in einer anderen als der hier beschriebenen Reihenfolge durchgeführt werden. Es versteht sich ferner, dass bestimmte Schritte gleichzeitig durchgeführt werden können, dass andere Schritte hinzugefügt werden können oder dass bestimmte hierin beschriebene Schritte weggelassen werden können. Mit anderen Worten dienen die vorliegenden Beschreibungen von Prozessen der Veranschaulichung bestimmter Ausführungsformen und sind nicht als die Ansprüche einschränkend auszulegen.
  • Entsprechend versteht es sich, dass die vorstehende Beschreibung veranschaulichend und nicht einschränkend sein soll. Für den Fachmann werden bei der Lektüre der vorstehenden Beschreibung viele andere Ausführungsformen und Anwendungen außer den hierin bereitgestellten Beispielen ersichtlich sein. Der Umfang der Erfindung ist nicht unter Bezugnahme auf die vorstehende Beschreibung zu bestimmen, sondern sollte stattdessen unter Bezugnahme auf die beigefügten Ansprüche zusammen mit dem vollen Umfang der Äquivalente, zu denen sie berechtigt sind, bestimmt werden. Es wird erwartet und ist vorgesehen, dass künftige Entwicklungen auf dem in dieser Schrift erörterten Gebiet stattfinden werden und dass die offenbarten Systeme und Verfahren in diese künftigen Ausführungsformen einbezogen werden. Zusammenfassend versteht es sich, dass Modifikationen und Abwandlungen der Erfindung möglich sind und diese nur durch die nachfolgenden Ansprüche eingeschränkt wird.
  • Alle in den Ansprüchen verwendeten Begriffe sollen ihre einfache und gewöhnliche Bedeutung tragen, wie sie dem Fachmann bekannt ist, solange hierin keine ausdrücklich gegenteilige Angabe vorliegt. Insbesondere die Verwendung von Singularartikeln wie „ein“, „eine“ „der“, „die“, „das“ usw. ist so auszulegen, dass ein oder mehrere der angegebenen Elemente aufgeführt sind, es sei denn, ein Anspruch führt eine ausdrücklich gegenteilige Einschränkung an. „Im Wesentlichen“ im hier verwendeten Sinne besagt, dass eine Abmessung, Zeitspanne, Form oder ein anderes Adjektiv aufgrund physischer Imperfektionen, Unterbrechungen der Stromversorgung, Variationen der Bearbeitung oder anderer Fertigung usw. geringfügig von dem Beschriebenen abweichen kann. Die Adjektive „erste/r“ und „zweite/r“ werden in diesem Dokument stets als Kennungen verwendet und sollen keine Wichtigkeit oder Reihenfolge angeben. Die Verwendung von „in Reaktion auf“ und „bei Bestimmung“ gibt ein Kausalverhältnis und nicht lediglich ein zeitliches Verhältnis an.
  • Die Offenbarung wurde in veranschaulichender Weise beschrieben, und es versteht sich, dass die verwendete Terminologie von beschreibender und nicht einschränkender Art sein soll. Viele Modifikationen und Abwandlungen der vorliegenden Offenbarung sind angesichts der vorstehenden Lehren möglich, und die Offenbarung kann in anderer als der spezifisch beschriebenen Weise ausgeübt werden.
  • Gemäß der vorliegenden Erfindung wird ein Computer bereitgestellt, der einen Prozessor und einen Speicher, der Anweisungen speichert, die von dem Prozessor ausführbar sind, aufweist, um: bei Bestimmung, dass ein lokaler Satz Kennungen nicht mit einem aus der Ferne übermittelten Satz Kennungen übereinstimmt, zu verhindern, dass ein Fahrzeug in einen autonomen Modus eintritt, oder das Fahrzeug anzuweisen, einen Zustand mit minimalem Risiko auszuführen.
  • Gemäß einer Ausführungsform beinhalten die Anweisungen ferner: bei Bestimmung, dass der lokale Satz Kennungen nicht mit dem aus der Ferne übermittelten Satz Kennungen übereinstimmt, ein Software-Update von einem entfernten Server zu empfangen.
  • Gemäß einer Ausführungsform beinhalten die Anweisungen ferner: bei Empfang des Software-Updates einen Übereinstimmungsstatus von einem Fehlerhaft-Status auf einen Annehmbar-Status einzustellen und als Reaktion darauf, dass der Übereinstimmungsstatus vom Fehlerhaft-Status schneller als ein Zeitschwellenwert zum Annehmbar-Status wechselt, einen Diagnoseproblemcode einzustellen.
  • Gemäß einer Ausführungsform beinhalten die Kennungen Konfigurationskennungen.
  • Gemäß einer Ausführungsform beinhalten die Anweisungen ferner: regelmäßig die Kennungen von Fahrzeugkomponenten anzufordern; und die zurückgesendeten Kennungen im lokalen Satz Kennungen zu speichern.
  • Gemäß einer Ausführungsform ist der lokale Satz Kennungen ein aktueller lokaler Satz Kennungen, und die Anweisungen beinhalten ferner, bei Bestimmung, dass der aktuelle lokale Satz Kennungen nicht mit einem vorherigen lokalen Satz Kennungen übereinstimmt, den aktuellen lokalen Satz Kennungen an einen entfernten Server zu übertragen, der den aus der Ferne übermittelten Satz Kennungen übermittelt.
  • Gemäß einer Ausführungsform beinhaltet das Ausführen des Zustands mit minimalem Risiko Fahren des Fahrzeugs an einen festgelegten Ort.
  • Gemäß einer Ausführungsform ist der lokale Satz Kennungen in einem Speicher an Bord des Fahrzeugs gespeichert.
  • Gemäß einer Ausführungsform ist der aus der Ferne übermittelte Satz Kennungen in einem vom Fahrzeug entfernten Speicher gespeichert.
  • Gemäß einer Ausführungsform beinhalten die Anweisungen ferner: das Bestimmen, dass der lokale Satz Kennungen nicht mit dem aus der Ferne übermittelten Satz Kennungen übereinstimmt, durch Bestimmen, dass wenigstens eine Kennung im lokale Satz Kennungen anders als eine jeweilige Kennung in dem aus der Ferne übermittelten Satz Kennungen ist.
  • Gemäß der vorliegenden Erfindung beinhaltet ein Verfahren bei Bestimmung, dass ein lokaler Satz Kennungen nicht mit einem aus der Ferne übermittelten Satz Kennungen übereinstimmt, Verhindern, dass ein Fahrzeug in einen autonomen Modus eintritt, oder Anweisen des Fahrzeugs, einen Zustand mit minimalem Risiko auszuführen.
  • Gemäß einer Ausführungsform, bei Bestimmung, dass der lokale Satz Kennungen nicht mit dem aus der Ferne übermittelten Satz Kennungen übereinstimmt, Empfangen eines Software-Updates von einem entfernten Server.
  • Gemäß einer Ausführungsform, bei Empfang des Software-Updates Einstellen einen Übereinstimmungsstatus von einem Fehlerhaft-Status auf einen Annehmbar-Status und als Reaktion darauf, dass der Übereinstimmungsstatus vom Fehlerhaft-Status schneller als ein Zeitschwellenwert zum Annehmbar-Status wechselt, Einstellen eines Diagnoseproblemcodes.
  • Gemäß einer Ausführungsform beinhalten die Kennungen Konfigurationskennungen.
  • Gemäß einer Ausführungsform regelmäßiges Anfordern der Kennungen von Fahrzeugkomponenten und Speichern der zurückgesendeten Kennungen im lokalen Satz Kennungen.
  • Gemäß einer Ausführungsform ist der lokale Satz Kennungen ein aktueller lokaler Satz Kennungen, wobei das Verfahren ferner umfasst: bei Bestimmung, dass der aktuelle lokale Satz Kennungen nicht mit einem vorherigen lokalen Satz Kennungen übereinstimmt, Übertragen des aktuellen lokalen Satzes Kennungen an einen entfernten Server, der den aus der Ferne übermittelten Satz Kennungen übermittelt.
  • Gemäß einer Ausführungsform beinhaltet das Ausführen des Zustands mit minimalem Risiko Fahren des Fahrzeugs an einen festgelegten Ort.
  • Gemäß einer Ausführungsform ist der lokale Satz Kennungen in einem Speicher an Bord des Fahrzeugs gespeichert.
  • Gemäß einer Ausführungsform ist der aus der Ferne übermittelte Satz Kennungen in einem vom Fahrzeug entfernten Speicher gespeichert.
  • Gemäß einer Ausführungsform Bestimmen, dass der lokale Satz Kennungen nicht mit dem aus der Ferne übermittelten Satz Kennungen übereinstimmt, indem bestimmt wird, dass wenigstens eine Kennung im lokalen Satz Kennungen anders als eine jeweilige Kennung in dem aus der Ferne übermittelten Satz Kennungen ist.

Claims (12)

  1. Verfahren, umfassend: bei Bestimmung, dass ein lokaler Satz Kennungen nicht mit einem aus der Ferne übermittelten Satz Kennungen übereinstimmt, Verhindern, dass ein Fahrzeug in einen autonomen Modus eintritt, oder Anweisen des Fahrzeugs, einen Zustand mit minimalem Risiko auszuführen.
  2. Verfahren nach Anspruch 1, ferner umfassend bei Bestimmung, dass der lokale Satz Kennungen nicht mit dem aus der Ferne übermittelten Satz Kennungen übereinstimmt, Empfangen eines Software-Updates von einem entfernten Server.
  3. Verfahren nach Anspruch 2, ferner umfassend: bei Empfang des Software-Updates Einstellen einen Übereinstimmungsstatus von einem Fehlerhaft-Status auf einen Annehmbar-Status; und als Reaktion darauf, dass der Übereinstimmungsstatus vom Fehlerhaft-Status schneller als ein Zeitschwellenwert zum Annehmbar-Status wechselt, Einstellen eines Diagnoseproblemcodes.
  4. Verfahren nach Anspruch 1, wobei die Kennungen Konfigurationskennungen beinhalten.
  5. Verfahren nach Anspruch 1, ferner umfassend: regelmäßiges Anfordern der Kennungen von Fahrzeugkomponenten; und Speichern der zurückgesendeten Kennungen im lokalen Satz Kennungen.
  6. Verfahren nach Anspruch 1, wobei der lokale Satz Kennungen ein aktueller lokaler Satz Kennungen ist, wobei das Verfahren ferner umfasst: bei Bestimmung, dass der aktuelle lokale Satz Kennungen nicht mit einem vorherigen lokalen Satz Kennungen übereinstimmt, Übertragen des aktuellen lokalen Satzes Kennungen an einen entfernten Server, der den aus der Ferne übermittelten Satz Kennungen übermittelt.
  7. Verfahren nach Anspruch 1, wobei das Ausführen des Zustands mit minimalem Risiko Fahren des Fahrzeugs an einen festgelegten Ort beinhaltet.
  8. Verfahren nach Anspruch 1, wobei der lokale Satz Kennungen in einem Speicher an Bord des Fahrzeugs gespeichert wird.
  9. Verfahren nach Anspruch 1, wobei der aus der Ferne übermittelte Satz Kennungen in einem vom Fahrzeug entfernten Speicher gespeichert ist.
  10. Verfahren nach Anspruch 1, ferner umfassend Bestimmen, dass der lokale Satz Kennungen nicht mit dem aus der Ferne übermittelten Satz Kennungen übereinstimmt, durch Bestimmen, dass wenigstens eine Kennung im lokalen Satz Kennungen anders als eine jeweilige Kennung in dem aus der Ferne übermittelten Satz Kennungen ist.
  11. Computer, umfassend einen Prozessor und einen Speicher, der Anweisungen speichert, die von dem Prozessor ausführbar sind, um das Verfahren nach einem der Ansprüche 1-10 auszuführen.
  12. Fahrzeug, das den Computer nach Anspruch 11 umfasst.
DE102019126804.4A 2018-10-08 2019-10-04 Fahrzeugsoftwareprüfung Pending DE102019126804A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/154.405 2018-10-08
US16/154,405 US10845800B2 (en) 2018-10-08 2018-10-08 Vehicle software check

Publications (1)

Publication Number Publication Date
DE102019126804A1 true DE102019126804A1 (de) 2020-04-09

Family

ID=69886608

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019126804.4A Pending DE102019126804A1 (de) 2018-10-08 2019-10-04 Fahrzeugsoftwareprüfung

Country Status (3)

Country Link
US (1) US10845800B2 (de)
CN (1) CN111008121A (de)
DE (1) DE102019126804A1 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102575640B1 (ko) * 2018-10-15 2023-09-07 현대자동차주식회사 자율 주행 제어 장치, 그를 가지는 차량 및 그 제어 방법
JP7415726B2 (ja) * 2020-03-26 2024-01-17 株式会社オートネットワーク技術研究所 車載情報処理装置、情報処理方法及びサーバプログラム
JP7367626B2 (ja) * 2020-07-08 2023-10-24 トヨタ自動車株式会社 ソフトウェア更新装置、方法、プログラムおよび車両
CN113112641A (zh) * 2021-04-21 2021-07-13 上海星融汽车科技有限公司 车辆ecu刷写方法及车辆诊断仪的下位机
US11941926B2 (en) * 2021-08-04 2024-03-26 Ford Global Technologies, Llc Vehicle variation remediation
US20230315440A1 (en) * 2022-04-05 2023-10-05 Ford Global Technologies, Llc Vehicle software compatibility
DE102022205944A1 (de) * 2022-06-13 2023-12-14 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Betreiben einer Robotervorrichtung

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5513107A (en) 1992-12-17 1996-04-30 Ford Motor Company Methods and apparatus for controlling operating subsystems of a motor vehicle
US6430481B1 (en) 1999-10-28 2002-08-06 General Electric Company Remote verification of software configuration information
US20050262337A1 (en) 2004-05-24 2005-11-24 Siemens Vdo Automotive Corporation Method and device for determining flash software compatibility with hardware
US8392764B2 (en) 2009-11-16 2013-03-05 Cooper Technologies Company Methods and systems for identifying and configuring networked devices
US8751100B2 (en) 2010-08-13 2014-06-10 Deere & Company Method for performing diagnostics or software maintenance for a vehicle
US9639344B2 (en) 2014-12-11 2017-05-02 Ford Global Technologies, Llc Telematics update software compatibility
DE102015209116A1 (de) 2015-05-19 2016-11-24 Robert Bosch Gmbh Verfahren und Aktualisierungsgateway zum Aktualisieren eines eingebetteten Steuergerätes
US20190092341A1 (en) * 2017-09-27 2019-03-28 Waymo Llc Multiple driving modes for autonomous vehicles

Also Published As

Publication number Publication date
US10845800B2 (en) 2020-11-24
US20200110406A1 (en) 2020-04-09
CN111008121A (zh) 2020-04-14

Similar Documents

Publication Publication Date Title
DE102019126804A1 (de) Fahrzeugsoftwareprüfung
DE102015221330A1 (de) Verfahren und Vorrichtung zum robusten Aktualisieren von Firmware eines Fahrzeuges über eine Luftschnittstelle
DE112017002909T5 (de) Fahrzeugvorrichtung
DE112017002919T5 (de) Fahrzeugvorrichtung
DE102018100015A1 (de) Wechselverifizierung vor abschaltung
DE102017113435A1 (de) Fahrzeug-Gateway-Netzwerkschutz
DE102015121091A1 (de) Telematik-Update-Softwarekompatibilität
DE102014217389A1 (de) Autonomes fahren in gebieten für nichtfahrer
WO2010124775A1 (de) Verfahren zur aktualisierung von softwarekomponenten
DE102020100593A1 (de) Fahrzeug-zu-fahrzeug-dateifreigabesystem und -verfahren
DE102014204511A1 (de) System und verfahren zur drahtlosen fahrzeuginhaltsbestimmung
DE102016201279A1 (de) Verfahren und Vorrichtung zum Überwachen einer Aktualisierung eines Fahrzeuges
DE102020104551A1 (de) Sicherung und wiederherstellung einer fahrzeugsteuerungskonfiguration unter verwendung von datenschnappschüssen
DE102017208532A1 (de) Elektronische Fahrzeugsteuereinheit und Fahrzeugdienstverwaltungssystem
DE102020100498A1 (de) Hybridstromnetz für ein fahrzeug
DE102019106448A1 (de) Elektrisches Fahrzeughilfsenergiesystem
DE102019135012A1 (de) Auf richtlinie und token basierender autorisierungsrahmen für konnektivität
DE102021209039A1 (de) Vorrichtung und verfahren zum verwalten einer aktualisierung einer ecu eines fahrzeugs
DE102021106575A1 (de) Fahrzeugreaktion auf eine anomaliebedingung beim autonomen fahren
DE102020100734A1 (de) Fahrzeugdatenmomentaufnahme für flott
DE102020119074A1 (de) Leistungszufuhr im ausgeschalteten zustand des fahrzeugs
DE102020122489A1 (de) Zugriffsautorisierung für verteiltes fahrzeugnetzwerk
DE102019124321A1 (de) Leistungsmanagementausfall in fahrzeugen
DE102020119401A1 (de) Leistungsversorgung während des fahrzeugstarts
WO2017108409A1 (de) Verbessertes verfahren und verbesserte vorrichtung zum konfigurieren und steuern von elektrischen einrichtungen eines fahrzeuges

Legal Events

Date Code Title Description
R082 Change of representative

Representative=s name: BONSMANN - BONSMANN - FRANK PATENTANWAELTE, DE