DE102018124934A1

DE102018124934A1 - Hybridelektrofahrzeug mit automatisiertem Softwareaktualisierungssystem

Info

Publication number: DE102018124934A1
Application number: DE102018124934.9A
Authority: DE
Inventors: Brian David Tillman; Medville Jay Throop; Ylldes Zeneli; Karl Nathan Clark
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2017-10-11
Filing date: 2018-10-09
Publication date: 2019-04-11
Also published as: US20190108010A1; CN109656586A; US10564954B2

Abstract

Ein Fahrzeug beinhaltet (eine) bordeigene Steuerung(en), die an einen drahtlosen Sendeempfänger gekoppelt und konfiguriert ist (sind), um sich mit einem Remote-Server zu verbinden und auf eine Remote-Softwareaktualisierungsnachricht für ein Fahrzeug von dem (den) Remote-Server(n) zu reagieren. Als Reaktion darauf lädt (laden) der (die) Steuerung(en) eine Softwareaktualisierung von dem (den) Remote-Server(n) auf das Fahrzeug herunter. Die Steuerung(en) ist (sind) ferner konfiguriert, um einen Fahrzeugruhezustand zu erfassen, um zu bestimmen, ob das Fahrzeug unbeaufsichtigt ist, sodass die Softwareaktualisierung fortgesetzt werden kann. Wenn der Ruhezustand erfasst wird, konfiguriert (konfigurieren) die Steuerung(en) das Fahrzeug als Reaktion auf die Remote-Softwareaktualisierungsnachricht in einen abgesicherten Modus, der Zustände aufweist, die Schlüsselschalter eingeschaltet, Getriebe in Parken und Motor aus einschließen. Wenn die Konfigurationen in den abgesicherten Modus erfolgreich sind, aktualisiert (aktualisieren) und/oder flasht (flashen) die Steuerung(en) die heruntergeladenen Aktualisierungen auf fahrzeuginterne, bordeigene Computerverarbeitungssysteme und (eine) Steuerung(en), die unter anderem beispielsweise eine Motorsteuereinheit (engine control unit - ECU) einschließen kann (können).

Description

TECHNISCHES GEBIET
Die Offenbarung betrifft Elektro- oder Hybridelektrofahrzeuge, die mit einer automatisierten Remote-Pre-Flash-Sicherheitskonfiguration konfiguriert sind, und unbeaufsichtigte fahrzeuginterne Softwareaktuali sierungstechnologie.
ALLGEMEINER STAND DER TECHNIK
Fahrzeughersteller haben verschiedene Arten von fahrzeuginternen und/oder bordeigenen Computerverarbeitungssystemen entwickelt, die gelegentlich Softwareaktualisierungen erforderlich machen. In der Vergangenheit haben solche Softwareaktualisierungen einen manuellen Betrieb der fahrzeuginternen Computerverarbeitungssysteme durch einen Techniker erforderlich gemacht, um das Fahrzeug in einen abgesicherten Modus zu konfigurieren und um die Softwareaktualisierungen manuell auszuführen und manuell zu bestätigen, dass diese erfolgreich waren. Wenn für eine große Anzahl an Fahrzeugen in einer Flotte Softwareaktualisierungen erforderlich sind, kann der Prozess zeitraubend und kostspielig werden, was durch Fehler bei den manuellen Aktualisierungsvorgängen noch verschlimmert werden kann. Mit Fortschritten bei solchen Fahrzeugcomputerverarbeitungssystemen, die in neueren Elektro- und Hybridelektrofahrzeugen genutzt werden, die teilweise von häufigeren Softwareaktualisierungen profitieren können, ist der Bedarf an automatisierteren Softwareaktualisierungsfunktionen noch deutlicher geworden.
KURZDARSTELLUNG
Viele Arten von Privat-, Nutz- und Industriefahrzeugen, einschließlich Verbrennungsmotor- und Hybrid-, Plug-In-Hybrid- und Batterie-Elektrofahrzeugen, hierin gemeinsam als „Fahrzeuge“ bezeichnet, beinhalten verschiedene Arten von fahrzeuginternen Rechensystemen, Steuerungen, Schnittstellen, Netzwerken, Kommunikationsfunktionen und Anwendungen, die einen Fahrzeugbetrieb sowie eine bordeigene und fahrzeuginterne Steuerung von neuen und verbesserten Antriebs- und Elektroantriebssystemen, Fahrzeug-zu-Fahrzeug- und Fahrzeug-zu-Infrastruktur-Kommunikation sowie verwandte Kommunikationsfunktionen und die Steuerung und den Austausch von Daten ermöglichen, einschließlich fernausgelösten fahrzeuginternen Softwareaktualisierungen an diesen fahrzeuginternen Systemen.
Die Offenbarung bezieht sich auf Elektro- oder Hybridelektrofahrzeuge, die mit automatisierten und unbeaufsichtigten fahrzeuginternen Funktionen zur Fernsoftwareaktualisierung von Verarbeitungssystemen konfiguriert sind, die durch den einschlägigen Fachmann auch als Software-Flash-/-Aktualisierungsfunktionen bezeichnet werden. Die neuen automatisierten, fernausgelösten und -gesteuerten sowie unbeaufsichtigten Aktualisierungsfunktionen nutzen ferner neue Technologie zur verbesserten sicheren fahrzeuginternen Pre-Flash-Konfiguration des Fahrzeugs vor dem Aktualisieren. Früher war für Fahrzeuge, die Softwareaktualisierungen benötigten, ein fahrzeuginterner Techniker oder Bediener erforderlich, um den Flash-Vorgang durch manuelles Neukonfigurieren des Fahrzeug neben anderen Anforderungen als im Parkzustand mit ausgeschaltetem Motor und eingeschaltetem Zündschlüsselschalter zu konfigurieren.
Die neue Technologie der Offenbarung ermöglicht drahtloses und unbeaufsichtigtes Fernfahrzeugsoftwarescannen zum Erfassen von Fahrzeugen, die Softwareaktualisierungen benötigen. Das neue System ermöglicht außerdem Planen von automatisierten Aktualisierungen von Flottenfahrzeugen während vorbestimmten Zeiträumen, wie etwa Nichtgeschäftszeiten und, wenn solche Fahrzeuge unbeaufsichtigt sind und sich nicht in Betrieb befinden. Ferner ermöglicht die Innovation eine automatisierte Fahrzeugkonfiguration in den abgesicherten Modus unter Verwendung von zum Beispiel dem SYNC-System von Ford, das gemäß der Offenbarung konfiguriert ist, um das Fahrzeug elektronisch und aus der Ferne neuzukonfigurieren, um sich im Parkzustand zu befinden sowie den Motor aufgeschaltet zu haben und um den Zündschlüsselschalter zu aktivieren, sodass sich dieser im An-Zustand befindet. In weiteren Modifikationen ermöglicht das neue System außerdem eine Erfassung eines ausreichenden Ladezustands (state of charge - SoC) für Elektro- und Hybridelektrofahrzeuge und kann dieses den Verbrennungsmotor starten, um das Fahrzeug gegebenenfalls zu laden, und kann dann die Softwareaktualisierung einleiten, sobald ein ausreichender SoC erreicht wurde.
Die Offenbarung bezieht sich auf ein Fahrzeug, das zumindest eine und/oder eine oder mehrere bordeigene Steuerung(en) beinhaltet, die an einen drahtlosen Sendeempfänger gekoppelt und konfiguriert ist (sind), um sich miteinem Remote-Server oder -Servern zu verbinden und auf eine Remote-Softwareaktualisierungsnachricht für das Fahrzeug von dem (den) Remote-Server(n) zu reagieren. Als Reaktion darauf, dass die Nachricht verfügbare Softwareaktualisierungen angibt, lädt (laden) der (die) Steuerung(en) eine Softwareaktualisierung von dem (den) Remote-Server(n) auf das Fahrzeug herunter. Vor dem Aktualisieren der fahrzeuginternen Software ist (sind) die Steuerung(en) ferner konfiguriert, um einen Fahrzeugruhezustand zu erfassen, um sicherzustellen, dass das Fahrzeug unbeaufsichtigt und nicht in Gebrauch ist, sodass die Softwareaktualisierung ohne Unterbrechung fortgesetzt werden kann. In üblichen Konfigurationen beinhaltet ein solcher Ruhezustand, dass das Fahrzeug 100 ausgeschaltet und geparkt ist, und wobei sich dessen verschiedene Komponenten, Systeme und Vorrichtungen in einem nicht mit Strom versorgten, Nicht-Betriebszustand und/oder nicht verwendeten Zustand befinden. Wenn der Ruhezustand erfasst wird, konfiguriert (konfigurieren) die Steuerung(en) das Fahrzeug als Reaktion auf die Remote-Softwareaktualisierungsnachricht in einen abgesicherten Modus, um automatisch und elektronisch Fahrzeugzustände zu ermöglichen, die Schlüsselschalter eingeschaltet, Getriebe in Parken und Motor aus einschließen.
Wenn diese Konfigurationen in den abgesicherten Modus erfolgreich sind, aktualisiert (aktualisieren) und/oder flasht (flashen) die Steuerung(en) die heruntergeladenen Aktualisierungen auf fahrzeuginterne, bordeigene Computerverarbeitungssysteme, wie etwa die Steuerung(en) und andere Verarbeitungssysteme, und die unter anderem beispielsweise eine Motorsteuereinheit (engine control unit - ECU) einschließen kann (können). Sobald dies abgeschlossen ist, wird die geflashte Software gegenüber der heruntergeladenen Softwareaktualisierung verifiziert, um Fehler zu erfassen. Wenn Fehler erfasst werden, kann ein erneutes Herunterladen und/oder Flashen versucht werden, bevor die Zielsteuerung(en) und -verarbeitungs- und -rechensysteme auf einen ursprünglichen Zustand zurückgesetzt wird (werden) und ein Fehlerzustand generiert und kommuniziert wird. Wenn keine Fehler in der geflashten Software erfasst werden, wird der Aktualisierungs- und/oder Flash-Vorgang beendet und beendet (beenden) die Steuerung(en) den abgesicherten Modus und gibt (geben) den Befehl für einen Zustand mit ausgeschaltetem Schlüsselschalter.
In Variationen ist (sind) die bordeigene(n) Steuerung(en) außerdem an eine Netzwerkkommunikationsvorrichtung gekoppelt, welche den Sendeempfänger beinhaltet, und ist (sind) diese ferner konfiguriert, um sich in regelmäßigen Abständen mit dem (den) Remote-Server(n) zu verbinden und eine Softwareversionsanforderung von dem (den) Remote-Server(n) zu empfangen. Als Reaktion darauf ist (sind) die bordeigene(n) Steuerung(en) konfiguriert, um eine Antwort an den Server zu generieren, die eine Softwareversionsliste für fahrzeuginterne Software beinhaltet.
Die bordeigene(en) Steuerung(en) ist (sind) ferner angepasst, um die Remote-Softwareaktualisierungsnachricht von dem (den) Remote-Server(n) zu empfangen, die zumindest eines von und/oder eines oder mehrere von Authentifizierungsdaten zur Softwareaktualisierung und/oder einer aktualisierten Softwareversionsliste beinhaltet. Die Steuerung(en) verifiziert (verifizieren) die heruntergeladene Softwareaktualisierung gemäß den Authentifizierungsdaten und/oder der aktualisierten Softwareversionsliste. Wenn die Verifikation fehlschlägt, ist (sind) die Steuerung(en) konfiguriert, um ein erneutes Herunterladen der Softwareaktualisierung zu versuchen und als Reaktion auf eine erfolgreiche Verifizierung das Fahrzeug in den abgesicherten Modus zu konfigurieren, um die Aktualisierung zu ermöglichen.
In einer weiteren Anordnung der Offenbarung ist (sind) die bordeigene(n) Steuerung(en) außerdem konfiguriert, um auf Erfassen zu reagieren, dass ein aktueller Zeitpunkt in einem vorbestimmten Aktualisierungsplan liegt, wodurch Zeiträume vorgeschrieben werden, während denen das Fahrzeug zum Aktualisieren und/oder Flashen der heruntergeladenen Software zur Verfügung steht. Als Reaktion auf Erfassen der Verfügbarkeit für Softwareaktualisierungen kann (können) die Steuerung(en) das Fahrzeug in den abgesicherten Modus konfigurieren, um die Aktualisierung einzuleiten. Andernfalls ist (sind) die Steuerung(en) als Reaktion auf Erfassen einer Nichtverfügbarkeit angepasst, um eine Nachricht „Aktualisierung ausstehend“ zu generieren, die an eines oder mehrere von dem (den) Remote-Server(n), einem fahrzeuginternen Benachrichtigungssystem und einer Benutzerschnittstelle und/oder einem anderen Ziel kommuniziert werden kann. In weiteren Variationen ist (sind) die bordeigene(n) Steuerung(en) außerdem konfiguriert, um den aktuellen Zeitpunkt zu überwachen, bis ein Zeitpunkt in dem vorbestimmten Aktualisierungsplan erfasst wird.
In zusätzlichen Konfigurationen der Offenbarung ist (sind) die bordeigene(n) Steuerung(en) außerdem an eine Batterie gekoppelt und ferner konfiguriert, um einen Ladezustand (state of charge - SoC) der Batterie zu erfassen, der eine Flash-Ladungsgrenze überschreitet. Wenn ein ausreichender SoC vorhanden ist, um die bordeigene(n) Steuerung(en) zu aktivieren, um die Softwareaktualisierung abzuschließen, ist (sind) die Steuerung(en) angepasst, um das Fahrzeug in den abgesicherten Modus zu steuern. Andernfalls konfiguriert (konfigurieren) die bordeigene(n) Steuerung(en) das Fahrzeug bei Erfassen einer Wiederaufladeberechtigung in den abgesicherten Modus, jedoch mit einem Zustand mit eingeschaltetem Motor, sodass die Batterie wiederaufgeladen wird, bis der SoC die Flash-Ladungsgrenze überschreitet.
Die bordeigene(n) Steuerung(en) ist (sind) in anderen Anordnungen außerdem konfiguriert, um als Reaktion auf die Verifikation der Softwareaktualisierung den abgesicherten Modus und den Zustand mit ausgeschaltetem Schlüsselschalter zu beenden und um einen Aktualisierungsstatus an einen oder mehreren von dem (den) Remote-Server(n) und eine Schnittstelle des Fahrzeugs zu kommunizieren. Die Offenbarung bezieht sich außerdem auf Anpassungen der bordeigene(n) Steuerung(en), um eine Funktion der Aktualisierung bei Bedarf zu ermöglichen, wobei die Steuerung(en) ferner an eine Fahrzeugschnittstelle gekoppelt ist (sind), wie etwa unter anderem an eine graphische Benutzerschnittstelle, und außerdem konfiguriert ist (sind), um eine Aktualisierungsanfrage als Reaktion auf eine Eingabe von der graphischen Benutzerschnittstelle zu generieren und an den Remote-Server zu kommunizieren und um als Reaktion auf die Anfrage die Remote-Softwareaktualisierungsnachricht für das Fahrzeug zu empfangen. In noch weiteren Modifikationen ist (sind) die bordeigene(n) Steuerung(en) angepasst, um auf ein Fahrzeug- und/oder Benutzerinteraktionssignal zu reagieren, was einschließen kann, dass ein Benutzer versucht, das Fahrzeug während des abgesicherten Zustands und/oder Aktualisierungsvorgangs zu starten oder anderweitig zu nutzen, und um zumindest eine von einer Nachricht über den abgesicherten Modus an die graphische Benutzerschnittstelle und/oder eine audiovisuelle Warnung zu generieren, um den konfigurierten abgesicherten Modus anzukündigen, und um den Aktualisierungsvorgang fortzusetzen.
Diese Kurzdarstellung der Umsetzungen und Konfigurationen der Fahrzeuge und beschriebenen Komponenten und Systeme stellt eine Auswahl von beispielhaften Umsetzungen, Konfigurationen und Anordnungen in einer vereinfachten und weniger technisch detaillierten Anordnung vor, und solche sind ferner nachstehend in der detaillierten Beschreibung in Verbindung mit den beigefügten Veranschaulichungen und Zeichnungen sowie den darauffolgenden Patentansprüchen ausführlicher beschrieben.
Es ist nicht beabsichtigt, dass diese Kurzdarstellung zentrale oder wesentliche Merkmale der beanspruchten Technik identifiziert, und es ist nicht beabsichtigt, dass sie als Hilfsmittel bei der Bestimmung des Umfangs des beanspruchten Gegenstands herangezogen wird. Die hier erörterten Merkmale, Funktionen, Fähigkeiten und Vorteile können unabhängig voneinander in verschiedenen beispielhaften Umsetzungen erreicht werden oder in noch anderen beispielhaften Umsetzungen kombiniert werden, wie in der vorliegenden Schrift an anderer Stelle genauer beschrieben und was zudem für den einschlägigen Fachmann unter Bezugnahme auf die folgende Beschreibung und die folgenden Zeichnungen nachvollzogen werden kann.
Figurenliste
Ein umfassenderes Verständnis der beispielhaften Umsetzungen der vorliegenden Offenbarung kann durch Bezugnahme auf die detaillierte Beschreibung und die Patentansprüche abgeleitet werden, wenn diese gemeinsam mit den folgenden Figuren betrachtet werden, in denen sich gleiche Bezugszeichen in allen Figuren auf ähnliche oder identische Elemente beziehen. Die

Figuren und Anmerkungen darin werden zur Erleichterung des Verständnisses der Offenbarung bereitgestellt, ohne die Breite, den Umfang, den Geltungsbereich oder die Anwendbarkeit der Offenbarung einzuschränken. Die Zeichnungen sind nicht unbedingt maßstabsgetreu.
1 ist eine Veranschaulichung eines Fahrzeugs und von dessen Systemen, Steuerungen, Komponenten, Sensoren, Aktoren und Betriebsverfahren; und
2 veranschaulicht bestimmte Aspekte der Offenbarung, die in 1 dargestellt sind, wobei Komponenten zur Veranschaulichung entfernt, hinzugefügt und/oder neu angeordnet wurden.

DETAILLIERTE BESCHREIBUNG
Nach Bedarf werden in der vorliegenden Schrift detaillierte Ausführungsformen der vorliegenden Erfindung offenbart; dabei versteht es sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen ausgeführt sein kann. Die Figuren sind nicht zwingend maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Details bestimmter Komponenten zu zeigen. Demnach sind hier offenbarte konkrete strukturelle und funktionelle Details nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um den Fachmann die vielfältige Verwendung der vorliegenden Erfindung zu lehren.
Der Durchschnittsfachmann sollte verstehen, dass verschiedene Merkmale, Komponenten und Prozesse, die unter Bezugnahme auf eine beliebige der Figuren veranschaulicht und beschrieben sind, mit Merkmalen, Komponenten und Prozessen kombiniert werden können, die in einer oder mehreren anderen Figuren veranschaulicht sind, um Ausführungsformen herzustellen, die dem Fachmann ersichtlich sein sollten, aber unter Umständen nicht ausdrücklich veranschaulicht oder beschrieben sind. Bei den Kombinationen aus veranschaulichten Merkmalen handelt es sich um repräsentative Ausführungsformen für typische Anwendungen. Verschiedene Kombinationen und Modifikationen der Merkmale, die mit den Lehren dieser Offenbarung vereinbar sind, könnten jedoch für bestimmte Anwendungen oder Umsetzungen wünschenswert sein und sollten ohne Weiteres im Bereich des Fachwissens, der Fertigkeiten und Fähigkeiten derer liegen, die auf den relevanten Fachgebieten tätig sind.
Nun unter Bezugnahme auf die verschiedenen Figuren und Veranschaulichungen und auf 1 und 2 und insbesondere auf 1 ist ein schematisches Diagramm eines herkömmlichen petrochemisch angetriebenen Fahrzeugs und/oder Hybridelektrofahrzeugs 100 gezeigt, wobei solche Fahrzeuge in weiteren Beispielen außerdem ein Batterieelektrofahrzeug, ein Plug-In-Hybridelektrofahrzeug und Kombinationen und Modifikationen davon einschließen können, die hierin gemeinsam als „ein Fahrzeug“ oder „Fahrzeuge“ bezeichnet werden. 1 veranschaulicht repräsentative Beziehungen zwischen den Komponenten des Fahrzeugs 100. Die physische Platzierung und Ausrichtung sowie die Funktions- und Logikverbindungen und Beziehungen zwischen den Komponenten innerhalb des Fahrzeugs 100 können variieren. Das Fahrzeug 100 beinhaltet eine Kraftübertragung 105, die einen Antriebsstrang 110 aufweist, der eines oder mehrere von einem Verbrennungsmotor (combustion engine - CE) 115 und einer elektrischen Maschine oder einem Elektromotor/Generator/Anlasser (EM) 120 beinhaltet, die eine Leistung und ein Drehmoment erzeugen, um das Fahrzeug 100 anzutreiben.
Der Motor oder CE 115 ist ein durch Benzin, Diesel, Biokraftstoff, Erdgas oder einen alternativen Kraftstoff angetriebener Verbrennungsmotor, der zusätzlich zu anderen Formen von Elektro-, Kühl-, Heiz-, Vakuum-, Druck- und Hydraulikleistung mittels Frontend-Motornebenvorrichtungen ein Ausgangsdrehmoment erzeugt. Der EM 120 kann ein beliebiger einer Vielzahl von Arten elektrischer Maschinen sein und zum Beispiel ein Dauermagnet-Synchronmotor, Stromgenerator und Motorstarter 120 sein. Der CE 115 und EM 120 sind konfiguriert, um das Fahrzeug 100 über eine Antriebswelle 125 und zusammen mit verschiedenen verwandten Komponenten anzutreiben, die ferner außerdem ein Getriebe, (eine) Kupplung(en), Differentiale, ein Bremssystem, Räder und dergleichen einschließen können.
Der Antriebsstrang 110 und/oder die Kraftübertragung 105 beinhaltet/beinhalten ferner eine oder mehrere Batterien 130. Eine oder mehrere derartige Batterien können eine Gleichstrombatterie oder -batterien 130 mit höherer Spannung sein, die in Bereichen von etwa 48 bis 600 Volt und mitunter zwischen etwa 140 und 300 Volt oder mehr oder weniger betrieben und dazu verwendet wird (werden), um Leistung für den EM 120 zu speichern und zuzuführen, und während des Nutzbremsens zum Erfassen und Speichern von Energie sowie zum Antreiben und Speichern von Energie von anderen Komponenten und Nebenaggregaten des Fahrzeugs verwendet wird (werden). Andere Batterien können (eine) Gleichstrombatterie(n) 130 mit Niederspannung sein, die in dem Bereich zwischen etwa 6 und 24 Volt oder mehr oder weniger betrieben und dazu verwendet wird (werden), um Leistung für andere Komponenten und Nebenaggregate des Fahrzeugs zu speichern und zuzuführen.
Eine Batterie oder Batterien 130 sind durch verschiedene mechanische und elektrische Schnittstellen und Fahrzeugsteuerungen, wie in der vorliegenden Schrift an anderer Stelle beschrieben, jeweils an den Motor 115, EM 120 und das Fahrzeug 100 gekoppelt, wie in 1 dargestellt. Die Hochspannungs-EM-Batterie 130 ist außerdem durch eines oder mehrere von einem Antriebsstrangsteuermodul (power train control module - PCM), einem Motorsteuermodul (motor control module - MCM), einem Batteriesteuermodul (battery control module -BCM) und/oder eine Leistungselektronik 135, die konfiguriert sind, um durch die Hochspannungsbatterie (high voltage battery - HV-Batterie) 130 für den EM 120 bereitgestellte Gleichstromleistung (direct current - DC) umzuwandeln und zu konditionieren, an den EM 120 gekoppelt.
Das PCM/MCM/BCM/die Leistungselektronik 135 ist außerdem konfiguriert, um DC-Batterieleistung zu konditionieren, umzukehren und in Dreiphasenwechselstrom (alternating current - AC) umzuwandeln, wie er üblicherweise erforderlich ist, um die elektrische Maschine oder den EM 120 anzutreiben. Das PCM/MCM/BCM/die Leistungselektronik 135 ist außerdem konfiguriert, um eine oder mehrere Batterien 130 mit Energie aufzuladen, die durch den EM 120 und/oder Komponenten des Frontend-Nebenaggregatantriebs erzeugt wird, und bei Bedarf von anderen und an andere Fahrzeugkomponenten Leistung zu empfangen, zu speichern und zuzuführen.
Unter weiterer Bezugnahme auf 1 beinhaltet das Fahrzeug 100 ferner zusätzlich zu dem PCM/MCM/BCM/der Leistungselektronik 135 eine oder mehrere Steuerungen und Rechenmodule und -systeme, die eine Vielzahl von Fahrzeugfunktionen ermöglichen. Beispielsweise kann das Fahrzeug 100 Folgendes eingeschlossen haben: ein Karosseriesteuermodul (body control modul - BCM), bei dem es sich um eine alleinstehende Einheit handelt und/oder die als Teil einer Fahrzeugsystemsteuerung (vehicle system controller - VSC) 140 eingeschlossen sein kann, und ein(e) Fahrzeugrechensystem (vehicle computing system - VCS) und -steuerung 145, die mit dem PCM/MCM/BCM 135 in Kommunikation stehen, sowie andere Steuerungen. Beispielsweise handelt es sich zu Zwecken der Veranschaulichung, jedoch nicht zur Einschränkung, bei der VSC 140 und/oder dem VCS 145 um Folgendes und/oder hat diese bzw. dieses Folgendes integriert: SYNC.TM., APPLINK.TM., MyFord Touch.TM. und/oder Open-Source-SmartDeviceLink und/oder bordeigene oder nichtbordeigene OpenXC-Fahrzeugrechensysteme, ein fahrzeuginternes Konnektivitäts-, Infotainment- und Kommunikationssystem und Anwendungsprogrammiertschnittstellen (application programming interfaces -APIs) zur Kommunikation und Steuerung von und/oder mit nichtbordeigenen und/oder externen Vorrichtungen.
Als weitere Beispiele, jedoch nicht zum Zwecke der Einschränkung, kann/können zumindest eine und/oder eine oder mehrere der Steuerung(en), wie etwa die VSC 140 und das VCS 145, Folgendes integriert haben und kann es sich ferner hierbei um Folgendes handeln und/oder kann/können diese Folgendes beinhalten: eine oder mehrere Nabenaggregatsprotokollschnittstellenmodule (accessory protocol interface modules - APIMs) und/oder eine integrierte oder getrennte Kopfeinheit, die ein Informations- und Unterhaltungssystem (hierin aus als ein Infotainmentsystem und/oder ein audio-visuelles Steuermodul oder ACM/AVCM bezeichnet) sein, beinhalten und/oder integriert haben kann. Solche Module beinhalten Folgendes und/oder können dies beinhalten: einen Mediaplayer (MP3, Blue-Ray.TM, DVD, CD, Kassette usw.), Stereo, FM-/AM-/Satellit-Radioempfänger und dergleichen sowie eine Mensch-Maschinen-Schnittstelle (human machine interface - HMI) und/oder Anzeigeeinheit, wie an anderer Stelle hierin beschrieben.
Solche in Erwägung gezogenen Komponenten und Systeme sind von verschiedenen Quellen erhältlich und werden zu Beispielszwecken von Folgenden hergestellt oder sind von diesen erhältlich: dem SmartDeviceLink Consortium, dem OpenXC-Projekt, der Ford Motor Company und anderen (siehe beispielsweise SmartDeviceLink.com, openXCplatform.com, www.ford.com, US-Patentnr. 9,080,668, 9,042,824, 9,092,309, 9,141,583, 9,141,583, 9,680,934 und andere).
In weiteren Beispielen handelt es sich bei SmartLinkDevice (SDL), OpenXC und SYNC.TM. AppLink.TM. jeweils um Beispiele, die es zumindest einer und/oder einer oder mehreren von der (den) Steuerung(en), wie etwa der VSC 140 und dem VCS 145, ermöglichen, Remote Procedure Calls (RPCS) unter Verwendung von Anwendungsprogrammierschnittstellen (application programming interfaces - APIs) zu kommunizieren, die einen Befehl an externe oder nichtbordeigene mobile Vorrichtungen und Anwendungen und eine Steuerung davon unter Verwendung von fahrzeuginternen oder bordeigenen HMIs ermöglichen, wie etwa von graphischen Benutzerschnittstellen (graphical user interfaces - GUIs) und anderen Eingabe- und Ausgabevorrichtungen, die neben anderen Steuerungen außerdem die Hardware- und Softwaresteuerungen, -tasten und/oder -schalter sowie Lenkradsteuerungen und -tasten (steering wheel controls - SWCs), Kombiinstrumente und Bedienfeldhardware- und - softwaretasten und -schalter einschließen. Beispielhafte Systeme, wie etwa SDL, OpenXC und/oder AppLink.TM., ermöglichen, dass eine Funktionalität der mobilen Vorrichtung verfügbar ist, sowie ein aktiviertes Verwenden der HMI des Fahrzeugs 100, wie etwa SWCs und GUIs, und können außerdem Verwenden von bordeigener oder fahrzeuginterner automatisierte Erkennung und Verarbeitung von Sprachbefehlen beinhalten.
Die Steuerung(en) des Fahrzeugs 100, wie etwa der VSC 140 und des VCS 145, beinhalten eines oder mehrere von Folgendem und sind an diese gekoppelt: Fahrzeugnetzwerke mit hoher Geschwindigkeit, mittlerer Geschwindigkeit und niedrigerer Geschwindigkeit, die unter anderem ein gemultiplextes Broadcast-Controller-Area-Network (CAN) 150 einschließen, und ein größeres Fahrzeugsteuersystem und andere Fahrzeugnetzwerke, für die ein Host-Prozessor, eine Host-Steuerung und/oder ein Host-Server erforderlich sein können oder nicht und die ferner als weitere Beispiele andere mikroprozessorbasierte Steuerungen beinhalten können, wie an anderer Stelle hierin beschrieben. Das CAN 150 kann außerdem zusätzlich zu Kommunikationsverbindungen zwischen Steuerungen, Sensoren, Aktoren, Routern, fahrzeuginternen Systemen und Komponenten und zu dem Fahrzeug 100 externen nichtbordeigenen Systemen und Komponenten Netzwerksteuerungen und -router beinhalten.
Solche CANS 150 sind dem einschlägigen Fachmann bekannt und werden durch verschiedene Normen der Branche genauer beschrieben, die unter anderem zum Beispiel Folgendes einschließen: die Society of Automotive Engineers International.TM. (SAE) J1939 mit dem Titel „Serial Control and Communications Heavy Duty Vehicle Network“ und verfügbar auf standards.sae.org sowie Autoinformatiknormen, verfügbar von der International Standards Organization (ISO), 11898, mit dem Titel „Road vehicles - Controller area network (CAN)“ und ISO 11519 mit dem Titel „Road vehicles - Low-speed serial data communication“, verfügbar unter www.iso.org/ics/43.040.15/x/.
Für das CAN 150 wird in Erwägung gezogen, dass das Fahrzeug 100 ein, zwei, drei oder mehr solcher Netzwerke aufweist, die mit einer variierenden hohen, mittleren und hohen Geschwindigkeit betrieben werden, zum Beispiel im Bereich von etwa 50 Kilobit pro Sekunde (kbps) bis etwa 500 kbps oder höher. Das CAN 150 kann unter anderem außerdem Folgendes beinhalten, integriert haben und/oder daran gekoppelt sein und damit in Kommunikation stehen: interne bordeigene und externe drahtgebundene und drahtlose Personal Area Networks (PANs), Local Area Networks (LANs), Vehicle Area Networks (VANs), Wide Area Networks (WANs), Peer-to-Peer-(P2P-), Fahrzeug-zu-Fahrzeug-(V2V-) und Fahrzeug-zu-Infrastruktursowie Infrastruktur-zu-Fahrzeug-(V2I-, I2V-)Netzwerke, wie an anderer Stelle hierin beschrieben und in Erwägung gezogen.
In weiteren Beispielen kann/können die VSC 140, das VCS 145 und/oder andere Steuerungen, Vorrichtungen und Prozessoren ohne Einschränkung unter anderem Folgendes beinhalten, daran gekoppelt sein, damit konfiguriert sein und/oder zusammenwirken: eine oder mehrere integral eingeschlossene, eingebettete und/oder unabhängig angeordnete bidirektionale Kommunikationssysteme, Navigationssysteme und andere Systeme, Steuerungen und/oder Sensoren, wie etwa ein Fahrzeug-zu-Fahrzeug-Kommunikationssystem (V2V) 155 und ein Fahrzeug-zu-Straßeninfrastruktur-zu-Fahrzeug-Kommunikationssystem (V2I, I2V) 160, ein LIDAR-/SONAR-(Light- und/oder Sound-Detection-and-Ranging-) und/oder Videokamera-Straßennäherungsabbildungs- und -hindernissensorsystem 165, ein GPS oder globales Positioniersystem 170 und ein Anzeige- und Sensorsystem 175 zur Navigation und für bewegte Karten.
Das VCS 145 kann parallel, in Reihe und distributiv mit der VSC 140 sowie solchen Lenkradsteuerungen und -tasten und anderen Steuerungen, Teilsystemen und internen und externen Systemen zusammenwirken, um das Fahrzeug 100, externe Vorrichtungen und solche anderen Steuerungen und/oder Aktoren als Reaktion auf Sensor- und Kommunikationssignale, -daten, Parametern und andere Informationen zu verwalten und zu steuern, die von diesen Fahrzeugsystemen, -steuerungen und -komponenten sowie von anderen nichtbordeigenen Systemen, die zu dem Fahrzeug 100 extern und/oder davon entfernt sind, identifiziert, erhalten und empfangen bzw. an diese kommuniziert wurden.
Kommunikationssteuerungen und -systeme solcher bidirektionalen V2V 155 und V2I 160 (hierin gelegentlich gemeinsam als V2X bezeichnet) ermöglichen Peer-to-Peer, Fahrzeug-zu-Fahrzeug und Fahrzeug-zu-Infrastruktur ad hoc und ähnliche Arten von Netzwerken und Kommunikationen unter Verwendung von verschiedenen Branchenprotokollen, -normen und/oder -nachrichtenformaten, die in den Vereinigen Staaten von Amerika und anderen Ländern verfügbar sind. Solche Protokolle, Normen und/oder Nachrichtenformate werden zu Zwecken der Ermöglichung verschiedener Aspekte der Offenbarung genutzt und sind dem einschlägigen Fachmann bekannt.
Eine Anzahl an internationalen Normenorganisationen befasst sich ebenfalls mit diesem Gebiet der Technologie und hat verschiedene V2X-Ressourcen generiert, wie etwa die Telematiknorm der Society of Automotive Engineers International.TM. (SAE), und verwandte Normen schließen zum Beispiel die SAE-Norm J2735 mit dem Titel „Dedicated Short Range Communications (DSRC) Message Set Dictionary Standard," SAE J2735_201603, ein, verfügbar unter standards.sae.org/j2735_201603, und andere, die unter topics.sae.org/telematics/standards/automotive verfügbar sind. Die Kommunikations- und Nachrichtenfunktionen für V2X und andere Anwendungen sind neben anderen Referenzen in SAE J2735 als die Basic Safety Message(s) (BSMs, BSM-II) Teil 1 und 2 definiert.
Die Offenbarung bezieht sich austauschbar auf BSM- und BSM-II-Nachrichtenfunktionen und zieht in Erwägung, dass in jedem Fall hierin, in dem auf BSM Bezug genommen wird, erweiterte Daten- und Informationsfunktionen, die durch die BSM-II-Normen ermöglicht werden, erwähnt werden. Die BSM-Funktionen von SAE 2735 unterstützen und ermöglichen eine drahtlose Kommunikation zwischen Fahrzeugen und/oder zwischen Fahrzeugen (V2V) und fixierten oder mobilen Vorrichtungen, einschließlich Straßen-, Kreuzungs- und anderen Infrastrukturvorrichtungen und -systemen (V2I). Die SAE-Norm J2735 beschreibt, definiert und spezifiziert Nachrichten und Datenelemente, die Nachrichten/Dialoge spezifisch zur Verwendung durch das Fahrzeug, die Infrastruktur und andere nichtbordeigene Anwendungen ausmachen, die 5,9-Gigahertz-(GHz-)DSRC für Kommunikationssysteme mit Wireless Access in Vehicular Environments (WAVE) nutzen.
Die SAE-Norm J2945 beschreibt Kommunikationsleistunganforderungen der DSRC-Nachrichtensätze und der BSM-Datenelemente, die V2V- und V2I-Sicherheitsanwendungen unterstützen. Solche WAVE-Kommunikationen und verwandte Systeme sind in verschiedenen Normen und Berichten genauer beschrieben, die durch das Institute of Electrical and Electronics Engineers (IEEE) erstellt wurden und von diesem verfügbar sind, wie nachfolgend beschrieben. Siehe zum Beispiel standards.ieee.org und insbesondere IEEE-Norm 1609 mit dem Titel „Guide for Wireless Access in Vehicular Environments (WAVE) Architecture“, die unter standards.ieee.org/develop/wg/1609_WG.html verfügbar ist.
In einem Beispiel ermöglichen und definieren die IEEE-WAVE-Normen 1609 eine Architektur und einen standardisierten Satz an Kommunikationsdiensten und -schnittstellen, die sichere V2V- und V2I-Drahtloskommunikation ermöglichen. Diese Normen ermöglichen eine Reihe von Transport- und Navigationsanwendungen, unter anderem einschließlich Fahrzeugsicherheit, automatisierte Mauterhebung, erweiterte Navigation und Verkehrsverwaltung. Die WAVE-Funktionen von IEEE 1609 werden zusammen mit anderen genutzt, die sich auf verschiedene Aspekte von Netzwerk- und Kommunikationsnormen und - architekturen beziehen, einschließlich derer, die durch das Normengremium des Local Area Network and Metropolitan Area Network (LAN/MAN) gemäß IEEE 802 verwaltet werden, die unter www.ieee802.org sowie standards.ieee.org nachzulesen sind.
In einem weiteren Beispiel unterstützt die Norm 802.11 der IEEE Software- und Firmware-Kommunikationsdienste gemäß IEEE 1609 und ermöglichen Funktionen der Datenverbindungsmedienzugriffssteuerung (media access control - MAC) und physischen Schicht (physical layer -PHY), wie etwa Datenkommunikationen des drahtlosen lokalen Netzwerks (wireless local area network - WLAN) in verschiedenen Frequenzbändern. Die Norm 802.11 trägt den Titel „IEEE Standard for Information technology-Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications“ und ist unter ieeexplore.ieee.org/document/7792308 verfügbar.
Während das PCM/MCM/BCM 135, die VSC 140 und das VCS 145 sowie die anderen in Erwägung gezogenen Steuerungen Teilsysteme und Systeme hier zu Beispielzwecken als diskrete einzelne Steuerungen veranschaulicht sind, können sie andere Steuerungen und andere Sensoren, Aktoren, Signale und Komponenten, die Teil der größeren Fahrzeug- und Steuersysteme, externen Steuersysteme und internen und externen Netzwerke, Komponenten, Teilsysteme und Systeme sind, steuern, durch diese gesteuert werden, Signale zu und von diesen kommunizieren und Daten mit diesen austauschen.
Die in Verbindung mit jeder beliebigen spezifischen mikroprozessorbasierten Steuerung, die hier in Betracht gezogen wird, beschriebenen Funktionen und Konfigurationen können zudem in einer oder mehreren anderen Steuerungen ausgeführt sein und über mehr als eine Steuerung verteilt sein, sodass mehrere Steuerungen einzeln, gemeinsam, in Kombination und zusammenwirkend eine beliebige derartige Funktion und Konfiguration ermöglichen können. Dementsprechend soll sich eine Nennung „einer Steuerung“ oder „der Steuerung(en)“ auf derartige Steuerungen, Komponenten, Teilsysteme und Systeme in der Konnotation sowohl des Singulars als auch des Plurals sowie einzeln, gemeinsam und in verschiedenen geeigneten zusammenwirkenden und verteilten Kombinationen beziehen.
Zudem soll Kommunikation über das CAN 150 und andere interne und externe PANs, LANs und/oder WANs das Reagieren auf, Teilen, Übertragen und Empfangen von Befehlen, Signalen, Daten, Einbetten von Daten in Signalen, Steuerlogik und Informationen zwischen Steuerungen und Sensoren, Aktoren, Steuereinrichtungen und Fahrzeugsystemen und - komponenten beinhalten. Die Steuerungen kommunizieren mit einer oder mehreren steuerungsbasierten Eingabe-Ausgabe-(E/A-)Schnittstellen, die als einzelne integrierte Schnittstellen umgesetzt sein können, die eine Kommunikation von Rohdaten und Signalen und/oder Konditionierung, Verarbeitung und/oder Umwandlung von Signalen, Kurzschlussschutz, Schaltkreisisolierung und ähnliche Funktionen ermöglichen. Alternativ können ein(e) oder mehrere dedizierte Hardware- oder Firmwarevorrichtungen, Steuerungen und Ein-Chip-Systeme verwendet werden, um bestimmte Signale während der Kommunikation und vor und nach deren Kommunikation vorzukonditionieren und vorzuverarbeiten.
In weiteren Veranschaulichungen können das PCM/MCM/BCM 135, die VSC 140, das VCS 145, das CAN 150, und andere Steuerungen einen oder mehrere Mikroprozessoren oder Hauptprozessoren (central processing unit - CPU) in Kommunikation mit verschiedenen Arten von computerlesbaren Speichervorrichtungen oder -medien beinhalten. Computerlesbare Speichervorrichtungen oder -medien können flüchtige und nichtflüchtige Speicherung in Festwertspeicher (read-only memory - ROM), Direktzugriffsspeicher (random-access memory - RAM) und nichtflüchtigem Speicher oder Keep-Alive-Speicher (non-volatile/keep-alive memory -NVRAM oder KAM) einschließen. NVRAM oder KAM ist ein beständiger oder nichtflüchtiger Speicher, der dazu verwendet werden kann, verschiedene Befehle, ausführbare Steuerlogik und -anweisungen sowie Code, Daten, Konstanten, Parameter und Variablen zu speichern, die zum Betreiben des Fahrzeugs und der Systeme notwendig sind, während das Fahrzeug und die Systeme und Steuerungen und CPUs abgeschaltet oder von der Stromzufuhr getrennt sind.
Computerlesbare Speichervorrichtungen oder -medien können unter Verwendung einer Reihe von bekannten beständigen und nicht beständigen Speichervorrichtungen umgesetzt sein, wie etwa PROM (programmierbare Festwertspeicher), EPROM (elektronische PROM), EEPROM (elektronische löschbare PROM), Festplattenlaufwerke (hard disc drives - HDDs), Festkörperlaufwerke (solid state drives - SSDs), Flash-Speicher oder andere elektronische, magnetische, optische oder Kombinationsspeichervorrichtungen, die zum Speichern und Kommunizieren von Daten in der Lage sind.
Jede(r) solcher Vorrichtungen, Komponenten, Prozessoren, Microprozessoren, Steuerungen, Mikrosteuerungen, Speicher, Speichervorrichtungen und/oder Medien kann ferner außerdem Folgendes enthalten, beinhalten und/oder diese eingebettet haben: ein oder mehrere Basic Input and Output Systems (BIOSs), Betriebssysteme, Anwendungsprogrammierschnittstellen (application programming interfaces - APIs), die einen Remote Procedure Call (RPCs) aufweisen, ermöglichen und/oder implementieren, und verwandte(n) Firmware, Microcode, Software, Logikanweisungen, Befehle und dergleichen, die ein Programmieren, Personalisieren, Kodieren und Konfigurieren ermöglichen und die neben anderen Funktionen in zumindest einer solcher Vorrichtung eingebettet und/oder enthalten und/oder über eine oder mehrere solcher Vorrichtungen verteilt sein können.
In dieser Anordnung verwalten und steuern die VSC 140 und das VCS 145 zusammenwirkend die Fahrzeugkomponenten und anderen Steuerungen, Sensoren und Aktoren, einschließlich zum Beispiel und ohne Einschränkung, das PCM/MCM/BCM 135, eine Motorsteuereinheit (engine control unit - ECU) 185 und/oder verschiedene andere. Beispielsweise können die Steuerungen bidirektionale Kommunikationen mit solchen internen und externen Quellen aufbauen und Folgendes kommunizieren: Steuerungsbefehle, Logik und Anweisungen und Code, Daten, Informationen und Signale zu und/oder von dem Motor 115, EM 120, den Batterien 130, der ECU 185 und dem PCM/MCM/BCM/der Antriebselektronik 135 und anderen internen und externen Komponenten, Vorrichtungen, Teilsystemen und Systemen. Die Steuerungen können zudem andere Fahrzeugkomponenten, die dem Fachmann bekannt sind, steuern und mit diesen kommunizieren, wenngleich diese nicht in den Figuren gezeigt sind.
Die Ausführungsformen des Fahrzeugs 100 in 1 stellen zudem beispielhafte Sensoren und Aktoren in Kommunikation mit drahtgebundenen und/oder drahtlosen Fahrzeugnetzwerken und dem CAN 150 (PANs, LANs) dar, die bidirektional Daten, Befehle und/oder Signale zu der VSC 140, dem VCS 145 und anderen Steuerungen übertragen und von diesen empfangen können. Solche Steuerbefehle, Logik, Anweisungen und solcher Code, solche Daten, Informationen, Signale, Einstellungen und Parameter, einschließlich vom Fahrer bevorzugte Einstellungen und Präferenzen, können von einem Repository mit Fahrersteuerungen, -präferenzen und -profilen des Repositorys 180 sowie einem Speicher und Datenspeicher der anderen Steuerung(en) erfasst und in diesen gespeichert sowie davon kommuniziert werden.
Wie in den verschiedenen Figuren beschrieben und veranschaulicht, einschließlich 1 und 2, können die Signale und Daten, einschließlich beispielsweise Befehle, Informationen, Einstellungen, Parameter, Steuerlogik und ausführbare Anweisungen und andere Signale und Daten, außerdem weitere Signale (other signals - OS) 190 und Steuer- oder Befehlssignale (control/command signals- CS) 190 einschließen, die entweder über drahtgebundene und/oder drahtlose Daten- und Signalgebungsverbindungen von Steuerungen und Fahrzeugkomponenten und -systemen empfangen und an diese gesendet sowie von diesen untereinander ausgetauscht werden. Die OS 190 und CS 195 sowie andere Signale, verwandte Steuerlogik und ausführbare Anweisungen, Parameter und Daten können und/oder könnten an und von Steuerungen, Sensoren, Aktoren und Komponenten des Fahrzeugs sowie internen, externen und entfernten Systemen prognostiziert, generiert, erhalten, empfangen, kommuniziert und zwischen diesen ausgetauscht werden.
Ein beliebiges und/oder alle von diesen Signale können/kann rohe Analog- oder Digitalsignale und -daten oder vorkonditionierte, vorverarbeitete Daten und Signale, Kombinations- und/oder Ableitungsdaten und -signale sein, die als Reaktion auf andere Signale generiert werden, und können Spannungen, Stromstärken, Kapazitäten, Induktivitäten, Impedanzen und deren digitale Datendarstellung verschlüsseln, einbetten, darstellen und durch diese dargestellt werden, sowie Digitalinformationen, die solche Signale, Daten und Analog-, Digital- und Multimediainformationen verschlüsseln, einbetten und/oder anderweitig darstellen.
Die Kommunikation und der Betrieb der beschriebenen Signale, Befehle, Steueranweisungen und Logik sowie Daten und Informationen von den verschiedenen in Erwägung gezogenen Steuerungen, Sensoren, Aktoren und anderen Fahrzeugkomponenten können schematisch wie in 1 und anderen Figuren gezeigt und durch schematisch dargestellte Datenkommunikationsleitungen und -signale und drahtlose Signale und Datenverbindungen dargestellt werden. Derartige Diagramme veranschaulichen beispielhafte Befehle und Steuervorgänge, Steuerlogik und -anweisungen sowie Betriebsstrategien, die unter Verwendung von einer oder mehreren Rechen-, Kommunikations- und Verarbeitungstechniken umgesetzt werden können, zu denen Echtzeit, ereignisgesteuert, unterbrechungsgesteuert, Multitasking, Multithreading und Kombinationen davon gehören können.
Die gezeigten Schritte und Funktionen können in der dargestellten Abfolge und parallel, wiederholt, in modifizierten Abfolgen ausgeführt, kommuniziert und vorgenommen werden und in einigen Fällen mit anderen Vorgängen kombiniert und/oder weggelassen werden. Die Befehle, Steuerlogik und Anweisungen können in einer oder mehreren der beschriebenen mikroprozessorbasierten Steuerungen, externen Steuerungen und Systemen ausgeführt werden und vorwiegend als Hardware, Software, virtualisierte Hardware, Firmware, virtualisierte Hardware/Software/Firmware und Kombinationen davon ausgeführt sein.
1 stellt außerdem zu weiteren Veranschaulichungszwecken, jedoch nicht zu Einschränkungszwecken, eine beispielhafte Konfiguration und Blocktopologie für das VCS 145 für das Fahrzeug 100 und dessen in Erwägung gezogene Steuerungen, Vorrichtungen, Komponenten, Teilsysteme und/oder Systeme dar. Die Offenbarung bezieht sich auf die HMIs, einschließlich der Hardware- und Software-Schalter und -Steuerungen (hardware and software controls - HSCs) 195, die sich ferner unter anderen Steuerungen auf Tasten und/oder Schalter und Lenkradsteuerungen und -tasten (steering wheel controls - SWCs), Kombiinstrumente und Tasten und Schalter von Bedienfeldhardware und -software sowie GUI-Anzeigesoftwareschalter und -steuerungen beziehen, integriert haben und beinhalten.
In zusätzlichen beispielhaften Anordnungen schließen die verschiedenen Steuerungen, wie etwa das VCS 145, in einigen Anordnungen Folgendes ein oder können dieses einschließen: zumindest eine und/oder eine oder mehrere Mensch-Maschine-Schnittstelle(n) (human machine interfaces - HMIs)/graphische Benutzerschnittstelle(n) und visuelle Anzeige(n) (GUIs, HMIs) 200, die sich in einer Kabine des Fahrzeugs 100 befinden können. Die HMIs/GUIs 200 können außerdem an automatisierte Spracherkennungs- und Sprachsyntheseteilsysteme sowie an zusätzliche Hardware- und Softwaresteuerungen, Tasten und/oder Schalter gekoppelt sein, die in die HMI/GUI 200 und Kombiinstrumente und Bedienfelder des Fahrzeugs 100 integriert, in diesen beinhaltet und/oder darauf angezeigt sind, daran angrenzen und/oder Teil davon sind, und damit zusammenwirken.
Solche Steuerungen, Tasten und/oder Schalter können in die HMIs/GUIs 200 sowie in andere Fahrzeugvorrichtungen und -systeme integriert sein, die als weitere Beispiele und Veranschaulichungen ein Lenkrad und verwandte Komponenten, Fahrzeugarmaturenbrettbedienfelder und -kombiinstrumente und dergleichen einschließen können. Für zusätzliche Veranschaulichungszwecke kann das VCS 145 ohne Einschränkung einen beständigen Arbeitsspeicher und/oder Speicher-HDDS, SSDs, ROMs 205 und nicht beständigen oder beständigen RAM/NVRAM/EPROM 210 und/oder ähnlich konfigurierte beständige und nicht beständige Arbeits- und Datenspeicherkomponenten beinhalten und/oder integriert haben.
Das VCS 145 und/oder die andere(n) Steuerung(en) beinhalten in veranschaulichenden, jedoch nicht einschränkenden Beispielen, außerdem eine oder mehrere fahrzeugbasierte bidirektionale Dateneingabe, -ausgabe und/oder -kommunikationen und verwandte Vorrichtungen und Komponenten, die eine Kommunikation mit Benutzern, Fahrern und Insassen des Fahrzeugs 100 sowie mit externen nahegelegenen und entfernten Vorrichtungen, Netzwerken (Can 150, PANs, LANs, WANs) und/oder Systemen ermöglichen, haben diese integriert und/oder sind an diese gekoppelt. Die Ausdrücke „fahrzeugbasiert“ und „bordeigen“ beziehen sich auf Vorrichtungen, Teilsysteme, Systeme und Komponenten, die in das Fahrzeug 100 und dessen verschiedene Steuerungen, Teilsysteme, Systeme, Vorrichtungen und/oder Komponenten integriert, eingeschlossen, daran gekoppelt sind und/oder darin getragen werden. Im Gegensatz dazu betrifft der Ausdruck „nichtbordeigen“ solche Steuerungen, Teilsysteme, Systeme, Vorrichtungen und/oder Komponenten, die sich extern zu und/oder entfernt von dem Fahrzeug 100 befinden, und zieht diese in Erwägung.
Als zusätzliche Beispiele können das VCS 145, die GUIs 200 und andere Steuerungen des Fahrzeugs 100 fahrzeugbasierte Multimediavorrichtungen 215, (einen) Hilfseingang (Hilfseingänge) 220 und analoge/digitale (A/D-)Schaltungen 225, (einen) Universal-Serial-Bus(USB)-Anschluss (-Anschlüsse) 230, Near-Field-Communication-Sendeempfänger (NFCs) 235, drahtlose Router und/oder Sendeempfänger (wireless routers/transceivers - WRTs) 240, wie etwa „Bluetooth.TM“-Vorrichtungen, die drahtlose private und lokale Netzwerke (WPANs, WLANs) ermöglichen, oder „WiFi“ gemäß den Kommunikationsnormen IEEE 802.11 und 803.11 beinhalten, integriert haben, diesen zugeordnet, damit synchronisiert und/oder daran gekoppelt sein.
Die Steuerung(en) und Vorrichtung(en) des Fahrzeugs 100 sind außerdem an analoge und digitale Mobilfunknetzwerkmodems und -sendeempfänger (cellular network modems/transceivers - CMTs) 245 gekoppelt, haben diese integriert und/oder beinhalten diese, wobei Letztere Sprach-/Audio- und Datenverschlüsselungstechnologien und Technologien verwenden, die zum Beispiel die einschließen, die durch die International Telecommunications Union (ITU) als International-Mobile-Telecommunications-(IMT-)Normen verwaltet und oftmals als globales System für mobile Kommunikation (GSM) bezeichnet werden, Enhanced Data Rates for GSM Evolution (EDGE), universales mobiles Telekommunikationssystem (universal mobile telecommunications system - UMTS), 2G, 3G, 4G, 5G, Long-Term Evolution (LTE), eines Code-, Raum-, Frequenz-, Polarisierungs- und/oder Zeitmultiplexverfahrens (CDMA, SDMA, FDMA, PDMA, TDMA) und ähnliche sowie verwandte Protokolle, Verschlüsselungen, Technologien, Netzwerke und Dienste.
Solche in Erwägung gezogenen bordeigenen und nichtbordeigenen Vorrichtungen und Komponenten sind neben anderen konfiguriert, um bidirektionale drahtgebundene und drahtlose Kommunikationen zwischen Komponenten und Systemen des Fahrzeugs 100, dem CAN 150 und anderen externen Vorrichtungen und Systemen und PANs, LANs und WANs zu ermöglichen. Die A/D-Schaltung(en) 225 ist (sind) konfiguriert, um eine Analog-zu-Digital- und Digital-zu-Analog-Signalumwandlung zu ermöglichen. Die Hilfseingänge 220 und USBs 230 können neben anderen Vorrichtungen und Komponenten in einigen Konfigurationen außerdem Folgendes ermöglichen: drahtgebundenes und drahtloses Ethernet, bordeigene Diagnose (OBD, OBD II), optische Kommunikation im freien Raum, wie etwa Infrared (IR) Data Association (IrDA) und nichtstandardisierte Verbraucher-IR-Datenkommunikationsprotokolle, IEEE 1394 (FireWire.TM. (Apple Corp.), LINK.TM. (Sony), Lynx.TM. (Texas Instruments), EIA (Electronics Industry Association) serielle Protokolle, IEEE 1284 (Centronics-Port-Protokolle), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) sowie ähnliche Datenprotokolle, Signalgebungs- und Kommunikationsfunktionen.
Die Hilfseingänge 220 und A/D-Schaltungen 225, USBs 230, NFCs 235, WRTs 240 und/oder CMTs 245 sind an eine integralen Verstärkungs-, Signalumwandlungs- und/oder Signalmodulationsschaltung gekoppelt, die zu Folgendem konfiguriert ist/sind, sind in diese integriert und/oder schließen diese ein: Dämpfen, Umwandeln, Verstärken und/oder Kommunizieren von Signalen, und die ferner zu Folgendem konfiguriert sind: Empfangen von verschiedenen analogen und/oder digitalen Eingabesignalen, -daten und/oder -informationen, die an den verschiedenen drahtgebundenen und drahtlosen Netzwerken und Steuerungen verarbeitet und eingestellt sowie kommuniziert und zwischen diesen ausgetauscht werden.
Solche in Erwägung gezogenen verdrahteten und drahtlosen Netzwerke und Steuerungen schließen zum Beispiel, jedoch nicht ausschließlich, das CAN 150, VCS 145 und andere Steuerungen und Netzwerke des Fahrzeugs 100 ein. Die Hilfseingänge 220, A/D-Schaltungen 225, USBs 230, NFCs 235, WRTs 240 und/oder CMTs 245 und verwandte Hardware, Software und/oder Schaltungen sind kompatibel und konfiguriert, um zumindest eines von und/oder eines oder mehrere von einer Vielzahl von drahtgebundenen/r und drahtlosen/r Signalen, Signalgebung, Datenkommunikationen und/oder Datenstreams (WS) und Daten, wie etwa akustische und/oder visuelle, Navigations- und/oder Multimediasignale, -befehle, -steuerlogik, -anweisungen, -informationen, -software, -programmierung und ähnliche und verwandte Daten und Arten von Informationen, zu empfangen, zu übertragen und/oder zu kommunizieren.
Des Weiteren wird in Erwägung gezogen, das eine oder mehrere Vorrichtungen zur Eingabe- und Ausgabedatenkommunikation, Audio- und/oder Sichtgeräte in die Hilfsgeräte 220, A/D-Schaltungen 225, USBs 230, NFCs 235, WRTs 240 und/oder CMTs 245 sowie in (eine) andere in Erwägung gezogene Steuerung(en) und drahtgebundene und drahtlose zu dem Fahrzeug 100 interne und in einigen Fällen zu dem Fahrzeug 100 externe Netzwerke integriert sind, an diese gekoppelt sind und/oder mit diesen verbunden werden können. Beispielsweise schließen die eine oder mehrere Eingabe- und Ausgabevorrichtungen unter anderem Mikrophone 250, Sprachverarbeitungs- und -erkennungsvorrichtungen und -teilsysteme 255, (einen) Lautsprecher 260, (eine) zusätzliche Anzeige(n) 265, (eine) Kamera(s) 270, nomadische und mobile Vorrichtungen (nomadic and mobile devices - NMDs) 275 ein, die zumindest eine und/oder eine oder mehrere integrierte Signalgebunds- und - kommunikationsantennen und/oder -sendeempfänger (antenna/transceiver - AT) beinhalten.
Solche Eingabe und -ausgabevorrichtungen können und/oder können unter Umständen mit einem Eingabeselektor ausgewählt, verbunden, synchronisiert, betätigt und/oder diesem zugeordnet werden, bei dem es sich um eine beliebige der HSCs 195 handelt, und können außerdem die GUI 200 und die in Erwägung gezogenen Hardware- und Software-SWCs, - steuerungen, -tasten und/oder -schalter 195 beinhalten, integriert haben und/oder in diese integriert sein und/oder einen Teil davon darstellen. Bei solchen HSCs 195 kann es sich wie bereits angemerkt um Hardware oder Software oder eine Kombination davon handeln und diese können unter Verwendung von einer oder mehreren vorbestimmten, standardmäßigen und verstellbaren werkseitigen und/oder fahrerseitigen Steuerungen, Profilen und/oder Präferenzen 180 konfigurierbar sein.
Die/der in Erwägung gezogenen Mikrophone 250, Sprachverarbeitungs- und - erkennungsvorrichtungen und -teilsysteme 255, Lautsprecher 260, zusätzliche Anzeige(n) 265, Kamera(s) 270, NMDs 275 und/oder anderen tragbaren Hilfsvorrichtungen können ferner beispielsweise, jedoch nicht ausschließlich, Folgendes einschließen: Mobiltelefone, Smartphones, Satellitentelefone und -modems und Kommunikationsvorrichtungen, Tablets, persönliche digitale Assistenten, persönliche Medienwiedergabegeräte, Schlüsselanhängersicherheits- und -datenspeichervorrichtungen, persönliche Gesundheitsvorrichtungen, Laptops, tragbare drahtlose Kameras, Headsets und Kopfhörer, die Mikrophone beinhalten können, drahtlose und drahtgebundene Mikrofone, tragbare NFK-Lautsprecher und Stereo-Vorrichtungen und -Anlagen, tragbare GPS-Vorrichtungen und ähnliche Vorrichtungen und Komponenten, die jeweils integrierte Sendeempfänger und Antennen AT, drahtgebundene und eingesteckte Datenverbinder DC und verwandte Komponenten für drahtgebundene und drahtlose Multimedia- und Datenkommunikationssignale WS beinhalten können.
Solche in Erwägung gezogene Eingabe-, Ausgabe- und/oder Kommunikationsvorrichtungen, - komponenten, -teilsysteme und -systeme an Bord des Fahrzeugs 100 sind zu Folgendem konfiguriert und/oder können dazu konfiguriert sein: bidirektionales Kommunizieren über drahtgebundene und drahtlose Datenverbindungen (data connections - Dcs) und drahtgebundene und drahtlose Signale und Signalgebung und Datenkommunikationen und - streams WSs mit externen nahen und fernen nomadischen, tragbaren und/oder mobilen Vorrichtungen 275, Netzwerken und Systemen (V2X), die beispielsweise Infrastrukturkommunikationssysteme (V2I) beinhalten, wie etwa Hotspots und Drahtloszugriffspunkte (HS/wireless access points - WAPs), Nano- und Micro- und Standardmobilfunkzugriffspunkte und -türme (cellular towers - Cts), externe Router (XRs) und verwandte und zugängliche externe Remote-Server, -Netzwerke und/oder Systeme.
Unter erneuter Bezugnahme auf 1 und 2 kann durch den einschlägigen Fachmann nachvollzogen werden, dass in der Offenbarung in Erwägung gezogen wird, dass das Fahrzeug 100 zumindest eine und/oder eine oder mehrere Steuerung(en) beinhaltet, wie etwa die VSC 140, das VCS 145 und andere, die an einen fahrzeuginternen oder bordeigenen Sendeempfänger AT gekoppelt ist (sind), wie etwa die, die in Verbindung mit den USBs 230, NFCs 235, WRTs 240 und/oder CMTs 245 beschrieben ist (sind). Wenngleich Arten von drahtlosen Sendeempfängern zur Verwendung durch diese Offenbarung beschrieben und in Erwägung gezogen werden, bezieht sich die Offenbarung außerdem auf Fahrzeugkommunikationen, die nahegelegene und entferne ältere Vorrichtungen verwenden, die einigen einschlägigen Fachmännern bekannt sind.
Solche ältere Vorrichtungen haben in den letzten Jahren Fortschritte erfahren, um Drahtloskonfigurationen zu beinhalten und können als weitere Beispiele Elemente beinhalten, die durch einige in dem Fachgebiet als Fahrzeug-Gateway- und Engineering- und Konnektivitätsdienstwerkzeuge (VGs, ESTs, CSTs) bezeichnet werden. Die Steuerung(en) 140, 145 und der (die) Sendeempfänger AT sind konfiguriert, um WSs zu erfassen und sich mit nahegelegenen oder proximalen oder weit entfernten drahtgebundenen und drahtlosen Netzwerkvorrichtungen, die WSs in Reichweite aufweisen, sowie mit nichtbordeigenen, externen Vorrichtungen von Dritten zu verbinden, wie etwa nomadischen, tragbaren und/oder mobilen oder nomadischen mobilen Vorrichtungen 275.
Das Fahrzeug 100 beinhaltet außerdem die verschiedenen fahrzeuginternen und/oder bordeigenen Steuerungen, wie etwa die VSC 140, das VCS 145 und andere, welche an die verschiedenen beschriebenen drahtgebundenen und/oder drahtlosen Sendeempfänger und Netzwerkkommunikationsvorrichtungen gekoppelt sind, um diese zu beinhalten und/oder mit diesen konfiguriert zu sein, wobei Letztere konfiguriert sind, um sich mit dem Remote-Server und/oder den Remote-Servern (1) zu verbinden oder mit diesen zu kommunizieren. Die fahrzeuginterne(n) und/oder bordeigene(n) Steuerung(en) ist (sind) konfiguriert, um auf eine Remote-Softwareaktualisierungsnachricht (remote software update message - RSUM) für das Fahrzeug 100 zu reagieren, die von dem (den) Remote-Server(n) empfangen wird.
Die RSUM kann über eine beliebige der bereits beschriebenen Kommunikationsfunktionen durch den Remote-Server generiert und von diesem empfangen werden. Die RSUM kann als die in Erwägung gezogenen BSMs, die an anderer Stelle hierin beschrieben sind, konfiguriert und/oder Teil davon sein, ein Nachrichtenformat, das zur Verwendung mit OBD-II-Nachrichtenformaten, wie etwa ePIDs (elektronische Parameterkennungen), sowie mit V2I- und I2V-Open-Source-Nachrichtenformaten kompatibel ist, die zur Verwendung mit verschiedenen Originalgeräteherstellern (original equipment manufacturers - OEMs) konfiguriert sind und dadurch implementiert werden, wie etwa zu Beispielszwecken, jedoch nicht zu Einschränkungszwecken, unter anderem SmartLinkDevice (SDL), OpenXC und SYNC.TM. AppLink.TM.
Die RSUM kann eine oder mehrere softwareaktualisierungsbezogene Datenelemente beinhalten, einschließlich, zu Beispielszwecken und ohne Einschränkung, einer Fahrzeugidentifizierungsnummer (vehicle identification number - VIN), einer Softwareaktualisierungsfreigabebenachrichtigung (software update release notification - SRD), einer Softwareversionsanforderung (software version request - SVR), einer Softwareversionsliste (SVL), Softwareaktualisierungsauthentifizierungsdaten (SAD) und/oder anderer Elemente. Während diese hier zu Beispielszwecken beschrieben sind, können solche aktualisierungsbezogene Datenelemente als getrennte Datenelemente eingeschlossen und/oder als Teil eines einzigen Datenelements kombiniert sein, wie etwa BSMs, OBD-II-kompatible Nachrichten und andere Arten von Open-Source- und/oder OEM-kompatiblen Nachrichtenformaten.
In üblichen Anwendungen kann die VIN lediglich einige und/oder einen Teil der durch OEMS herausgegebenen standardisierten 17-stelligen eindeutigen Fahrzeugkennungen beinhalten und kann die dreistellige Herstellerkennung, den 5-stelligen Fahrzeugdeskriptor, die Deskriptorprüfzahl, die Jahreszahl und die Fertigungsstätte beinhalten und kann die übrige 6-stellige Herstellungsnummer ausschließen. Diese Anordnung ermöglicht es, dass die RSUM für Flotten von Fahrzeugen 100 verwendet wird, die eine Aktualisierung benötigen, ohne dass zusätzlich Identifizierungsdaten erforderlich sind. In anderen Anordnungen kann ein VIN-Bereich eingeschlossen sein, sodass jede bordeigene Steuerung eines Empfängerfahrzeugs erfassen kann, ob die RSUM anwendbar ist oder ignoriert werden kann.
Die SRD der Offenbarung ist konfiguriert, um aktualisierungsbezogene Daten zu beinhalten, die ein OEM benötigen können, um eine kürzlich veröffentlichte Aktualisierung zu ermöglichen und automatisierte Fahrzeugsoftwareaktualisierungssysteme hierüber zu informieren und um solche Aktualisierungen von bordeigener Fahrzeugsoftware für (eine) bestimmte Steuerung(en) und/oder ein bordeigenes Computerverarbeitungs- und - rechensystem zu ermöglichen. Solche SRDs können Seriennummern, Hardwareteilenummern, Herstellungsdaten und ähnliche Arten von Daten beinhalten, die Fahrzeugsoftwareaktualisierungssysteme benötigen könnten, um zu erfassen, ob verschiedene Fahrzeugsteuerungen und Rechensysteme zur Verwendung mit solchen Softwareaktualisierungen kompatible sind und/oder diese benötigen.
Die SVR kann es dem (den) Remote-Server(n) ermöglichen, Fahrzeugflotten abzufragen, um zu bestimmen, welche Versionen einer spezifischen Software auf den einzelnen Fahrzeugen 100 installiert sind, die in einem Werk oder einer Fertigungsanlage eingesetzt werden, und/oder die sich im Besitz von Kunden und Benutzern befinden. In einer beispielhaften Variation schließt die SVR eine Anforderung von dem (den) Remote-Server(n) ein, die dem Fahrzeug 100 den Befehl gibt, mit einer Liste von aktuellen installierten Softwareversionen für die bordeigene(n) Steuerung(en) und Rechensysteme zu antworten.
Die von dem (den) Remote-Server(n) übertragene SVL schließt in einem Beispiele eine Liste mit den aktuellsten Softwareversionen ein, die auf dem (den) Remote-Server(n) verfügbar sind, wodurch es den Empfängerfahrzeugen 100 ermöglicht wird, zu erfassen, ob Softwareaktualisierungen von dem (den) Remote-Server(n) verfügbar und/oder erforderlich sind. In einem weiteren Beispiel kann die SVL von den Fahrzeugen 100 an den (die) Remote-Server übertragen werden, um zu erfassen, ob die Quellenfahrzeuge 100 Softwareaktualisierungen benötigen. Die SAD beinhaltet für Zwecke weiterer Beispiele Prüfsummen, kryptologische Schlüssel und verwandte Informationen, wodurch dem Fahrzeug 100 ermöglicht wird, einen fehlerfreien Empfang von Softwareaktualisierungen zu verifizieren, die von dem (den) Remote-Server(n) heruntergeladen wurden. Die SADs können konfiguriert sein, um ferner eine Verifizierung einer erfolgreichen Installation und Flashen solcher Aktualisierungen auf die Steuerung(en) und Rechensysteme der Fahrzeuge 100 zu ermöglichen. Erfasste Fehler können auf Profilen 180 festgehalten und/oder unter anderem an eine(n) oder mehrere von (einem) Remote-Server(n), die HMI/GUI 200 des Fahrzeugs 100 und/oder NMDs 275 kommuniziert werden.
Die fahrzeuginterne(n) und/oder bordeigene Steuerung(en) ist (sind) außerdem konfiguriert, um auf die RSUM zu reagieren und zu erfassen, ob eine Softwareaktualisierung gemäß der einen oder mehreren der aktualisierungsbezogenen SRD-, SVL- und/oder SAD-Daten erforderlich und kompatibel ist. Für hierdurch identifizierte erforderliche und kompatible Softwareaktualisierungen ist (sind) die Steuerung(en) des Fahrzeugs 100 konfiguriert, um außerdem eine Softwareaktualisierung von dem (den) Remote-Server(n) auf das Fahrzeug 100 herunterzuladen. Sobald das Herunterladen abgeschlossen ist, verifiziert (verifizieren) der (die) Steuerung(en) in zusätzlichen Variationen unter Verwendung der SAD und/oder anderen aktualisierungsbezogenen Datenelementen ein fehlerfreies Herunterladen.
Die bordeigene(n) Steuerung(en) ist (sind) modifiziert, um einen aktuellen Betriebszustand des Fahrzeugs 100 zu erfassen, um zu bestimmen, ob sich das Fahrzeug 100 in einem aktiven Gebrauchszustand und/oder einem Ruhe- und Nichtgebrauchszustand befindet, sodass es verfügbar ist, um Softwareaktualisierungen an der (den) Fahrzeugsteuerung(en) und - rechensystemen durchzuführen. Ein solcher Ruhezustand beinhaltet, dass das Fahrzeug 100 und dessen Antriebsstrang und Komponenten und Systeme nicht mit Strom versorgt und nicht betriebsfähig sind. Als Reaktion auf Erfassen des Ruhezustands des Fahrzeugs 100 ist (sind) die Steuerung(en) modifiziert, um das Fahrzeug 100 automatisch aus dem Ruhezustand in einen abgesicherten Zustand zu konfigurieren, der eine Verwendung verhindert, bis der abgesicherte Modus beendet wird, sodass die Softwareaktualisierung eingeleitet und abgeschlossen werden kann.
Die Konfiguration des abgesicherten Modus beinhaltet und erzielt zu weiteren Veranschaulichungszwecken und ohne Einschränkung automatisches und elektrisches Konfigurieren eines elektronischen Schlüssels der/des Fahrzeugzündung/-antriebs/- antriebsstrangs in einen An-Zustand (KON), des Antriebsstrands und/oder Getriebes in einen Parkzustand (PKC) und des Verbrennungsmotors und/oder EM in den Aus-Zustand (EOF). Zusätzliche Systeme und Komponenten des Fahrzeugs 100 können ebenfalls wie für den abgesicherten Modus angemessen konfiguriert werden, sodass die Softwareaktualisierung ohne Unterbrechung und ohne Eingreifen von der (den) Steuerung(en) und Rechensystemen des Fahrzeugs 100 während des Softwareaktualisierungsprozesses durchgeführt werden kann.
Wenn die Softwareaktualisierungen eine aktualisierte Softwarekonfiguration für eine fahrzeuginterne Steuerung beinhalten, welche die Aufgabe hat, die Softwareaktualisierungen für das Fahrzeug 100 durchzuführen, kann die bordeigene Steuerung als ein weiteres Beispiel einer anderen bordeigenen Steuerung diese Aufgabe geben und/oder die Aktualisierungssteuerung zeitweise aufgeben und einen unabhängigen Prozess instanziieren, der auf einer andere bordeigenen Steuerung ausgeführt wird, um die erforderliche Aktualisierung durchzuführen, und die Verifizierung aktualisieren. Folglich kann der abgesicherte Modus eine Steuerungsaufgabenteilung und/oder Neuzuweisung zu einem anderen der fahrzeuginternen Steuerung(en) erforderlich machen, um die sichere Konfiguration zu ermöglichen, sodass die Softwareaktualisierung auf (einer) beliebigen solchen fahrzeuginternen Steuerung(en) und Verarbeitungs- und Rechensystemen durchgeführt werden kann.
Wenn die bordeigene(n) Steuerung(en) des Fahrzeugs 100 den abgesicherten Modus erfolgreich aktualisiert (aktualisieren), beginnt (beginnen) die Steuerung(en) die Softwareaktualisierung und/oder das Flashen von einer oder mehreren Fahrzeugsteuerungen, welche die bereits beschriebene(n) Fahrzeugsteuerung(en) einschließen können, sowie der anderen verschiedenen Fahrzeugkomponenten, -vorrichtungen und/oder -verarbeitungs- und - rechensysteme. Bei Abschluss der Softwareaktualisierung und/oder -aktualisierungen an der oder den mehreren Steuerung(en), -vorrichtungen und/oder -verarbeitungs- und - rechensystemen des Fahrzeugs 100 ist (sind) die fahrzeuginterne(n) Steuerung(en) außerdem konfiguriert, um die Aktualisierung oder Aktualisierungen zu verifizieren, und bei Verifizierung einer (von) erfolgreichen Aktualisierung(en) den abgesicherten Modus durch Wiederherstellen des vorangehenden, nicht verwendeten Ruhezustands des Fahrzeugs 100 zu beenden, indem sie zum Beispiel und ohne Einschränkung den Befehl zu dem KOF, EOF und/oder PK und/oder zu einem weiteren Satz solcher Zustände gemäß einem solchen vorangehenden Zustand des Fahrzeugs 100 vor der Konfiguration des abgesicherten Modus gibt (geben).
In dieser Offenbarung wird außerdem in Erwägung gezogen, dass die fahrzeuginterne(n) Steuerung(en) konfiguriert ist (sind), um sich in regelmäßigen Abständen mit dem (den) Remote-Server(n) zu verbinden und/oder auf Verbindungsanforderungen zu reagieren, die in regelmäßigen Abständen davon erhalten werden, um die RSUM oder andere Daten von dem (den) Remote-Server(n) zu empfangen und/oder um eine Softwarerevisionsliste daran zu übertragen. In Variationen der Steuerung(en) des Fahrzeugs 100 ist (sind) die Steuerung(en) außerdem konfiguriert, um als Reaktion auf das Empfangen der SVR von dem (den) Remote-Server(n), entweder getrennt und/oder als Teil des BSM, die in die RSUM eingebettet ist, und/oder der getrennt empfangenen RSUM eine Antwort an den Server zu generieren, welche die SVL beinhaltet. Wenn der (die) Remote-Server aus der SVL erfasst (erfassen), dass eine Softwareaktualisierung von dem Fahrzeug 100 benötigt wird, wird die Softwareaktualisierung durch die Steuerung(en) des Fahrzeugs 100 heruntergeladen und wird eine weitere RSUM an die Steuerung(en) des Fahrzeugs übertragen, welche die SAD wie bereits beschrieben beinhaltet, und durch diese empfangen.
Wenn die Verifizierung des Herunterladens gemäß der SAD fehlschlägt, ist (sind) die Steuerung(en) ferner modifiziert, um die Softwareaktualisierung erneut herunterzuladen und als Reaktion auf eine erfolgreiche Verifizierung das Fahrzeug in den abgesicherten Modus zu konfigurieren. Wie bei anderen Variationen können erfasste Fehlfunktionen oder Fehler, ein erfasster Aktualisierungsstatus und verwandte Aktualisierungsdaten ebenfalls an eine oder mehrere von dem (den) Remote-Server(n), der HMI/GUI 200 des Fahrzeugs 100 und/oder der NMDs 275 kommuniziert werden, die direkt oder durch eine Verbindung mit dem (den) Remote-Server(n) mit dem Fahrzeug 100 in Kommunikation stehen können.
Das Fahrzeug 100 beinhaltet außerdem die bordeigene(n) Steuerung(en), die konfiguriert ist (sind), um ein Planen der Softwareaktualisierung(en) während vorbestimmten Zeiträumen und Daten zu ermöglichen, sodass die Aktualisierungen und das Herunterladen von Aktualisierungssoftware lediglich gemäß einem spezifischen Plan stattfindet. Dies ermöglicht es Verwaltern von Fabrikherstellungsinventar und operativen Benutzerfahrzeugflotten nach dem Verkauf, außer während solchen spezifisch geplanten Zeiträumen, eine ununterbrochene Verfügbarkeit von Fahrzeugen sicherzustellen. Beispielsweise ist (sind) die Steuerung(en) des Fahrzeugs 100 ferner modifiziert, um in regelmäßigen Abständen einen aktuellen Zeitpunkt zu erfassen und mit einem vorbestimmten Aktualisierungsplan (predetermined update schedule - PS) zu vergleichen, wobei dieser Plan einen oder mehrere einzelne und/oder wiederkehrende Zeitpunkte und Daten beinhaltet, zu denen das Fahrzeug 100 verfügbar ist, um automatisierte softwareaktualisierungsbezogene Aufgaben durchzuführen.
Wenn erfasst wird, dass ein solcher aktueller Zeitpunkt in dem PS liegt, ist (sind) die bordeigene(n) Steuerung(en) modifiziert, um das Fahrzeug in den abgesicherten Modus zu konfigurieren. Wenn die fahrzeuginterne(n) Steuerung(en) jedoch erfasst, dass das Fahrzeug 100 nicht zum Aktualisieren verfügbar ist, da der erfasste Zeitpunkt nicht in dem PS liegt, ist (sind) die Steuerung(en) ferner angepasst, um den aktuellen Zeitpunkt zu überwachen, bis erfasst wird, dass dieser in dem Aktualisierungsplan liegt. Ferner ist (sind) die Steuerung(en) außerdem in Variationen konfiguriert, um eines oder mehrere von der Konfiguration des abgesicherten Modus, dem Herunterladen der Softwareaktualisierung und/oder dem Flashen und Aktualisieren der Software zu pausieren, bis der erfasste Zeitraum in dem Plan liegt. Stattdessen ist (sind) die Steuerung(en) des Fahrzeugs 100 in einigen Anordnungen außerdem modifiziert, um eine Nachricht „Aktualisierung ausstehend“ zu erzeugen, die an einen oder mehrere von der HMI oder GUI 200 und/oder den (die) Remote-Server kommuniziert werden kann.
Das Fahrzeug 100 der Offenbarung beinhaltet die fahrzeuginterne(n) Steuerung(en), die ebenfalls an die eine oder mehreren Batterien 130 gekoppelt ist (sind) und zum Beispiel den PCM/MCM/BCM und die Steuerung(en) 135 der Antriebselektronik und/oder ECU 185 beinhalten kann, die ferner konfiguriert sind/ist, um einen Ladezustand (state of charge - SoC) der Batterie(n) 130 zu überwachen und/oder zu erfassen, der eine Flash-Ladegrenze (flash charge limit - FCL) überschreitet. Bei der FCL handelt es sich um eine SoC-Grenze, die kalibriert wurde, um die Menge an Energie festzulegen, die in der (den) Batterie(n) 130 verfügbar sein muss, um einen erfolgreichen Abschluss der in Erwägung gezogenen Softwareaktualisierung zu ermöglichen. Wenn die SoC auf oder unter der FCL liegt, kann eine Wahrscheinlichkeit vorliegen, dass nicht ausreichend Energie in der (den) Batterie(n) 130 verbleibt, um einen erfolgreichen Abschluss der Softwareaktualisierung zu ermöglichen. Die Steuerung(en) ist (sind) in dieser Anordnung modifiziert, um das Fahrzeug 100 in den abgesicherten Modus zu konfigurieren, wenn der erfasste SoC die FCL überschreitet.
In weiteren Variationen der Offenbarung ist (sind) die bordeigene(n) Steuerung(en) außerdem konfiguriert, um die Batterie(n) 130 wiederaufzuladen, wenn der SoC auf und/oder unter der FCL liegt. Als Reaktion auf Erfassen, dass der Ladezustand (state of charge - SoC) die FCL nicht überschreitet, kann (können) die Steuerung(en) außerdem beispielsweise erfassen, ob das Fahrzeug 100 konfiguriert ist, um ein unbeaufsichtigtes und/oder automatisiertes Laden der Batterie(n) 130 zu ermöglichen. Das Fahrzeug 100 und/oder die Steuerung(en) können/kann eine Wiederaufladegenehmigung (recharge permission - RP) beinhalten, die als Teil der Steuerungen, Präferenzen und Profile 180 gespeichert ist.
Die RP ist konfiguriert, um ein automatisiertes Laden der Batterie als Reaktion auf eine Softwareaktualisierung gemäß Werks- und/oder Benutzerpräferenzen und/oder Anforderungen zu aktivieren oder deaktivieren. In einigen Anordnungen gemäß der Offenbarung kann die RP von einer NMD 275, die in Kommunikation mit dem Fahrzeug 100 steht, entweder automatisch und/oder durch eine automatisierte Anforderung von der (den) Steuerung(en) des Fahrzeugs 100 an die NMD 275 erhalten werden, was eine Benutzerauthorisierung mit RP erforderlich macht, die andernfalls ein automatisiertes, unbeaufsichtigtes Batterieladen deaktiviert.
Wenn die fahrzeuginterne(n) Steuerung(en) des Fahrzeugs 100 erfasst (erfassen), dass die RP ein automatisiertes Batterieladen aktiviert, ist (sind) (eine) solche Steuerung(en) in einigen Variationen ferner modifiziert, um das Fahrzeug 100 automatisch in den abgesicherten Modus und, um einen Zustand mit angeschaltetem Motor (EON) aufzuweisen, zu konfigurieren, sodass die Batterie(n) 130 für einen vorbestimmten Zeitraum und/oder, bis der SoC die FCL überschreitet, wiederaufgeladen wird (werden). In einem Beispiel kann (können) die Batterie(n) 130 für etwa 15 oder 30 Minuten und in anderen Variationen bis der SoC die FCL überschreitet, wiederaufgeladen werden. Sobald die SoC die FCL überschreitet, ist (sind) die Steuerung(en) konfiguriert, um den EOF aufzuweisen, und setzt (setzen) die Steuerung(en) die in Erwägung gezogene Softwareaktualisierung wie in anderer Stelle hierin beschrieben fort.
In anderen Anpassungen der Offenbarung ist (sind) die bordeigene(n) Steuerung(en) außerdem konfiguriert, um einen Aktualisierungsstatus (STAT) an eines oder mehrere von dem (den) Remote-Server(n), den NMDs 275 und/oder dem Fahrzeug 100 über die HMI oder GUI 200 zu kommunizieren und/oder ein Verlaufsprotokoll solcher Aktualisierungen in den Profilen 180 und/oder einem anderen Repository des Fahrzeugs 100 zu speichern. Der STAT ist konfiguriert, um als Reaktion auf eine oder mehrere von der Aktualisierungsverifizierung, Bestätigung der Beendigung des abgesicherten Modus, des KOF und andere aktualisierungsbezogene Daten gesendet zu werden und diese zu beinhalten.
In weiteren Variationen der Offenbarung ist (sind) die bordeigene(n) Steuerung(en) des Fahrzeugs 100 außerdem an die HMI und/oder GUI 200 gekoppelt und ferner konfiguriert, um eine Aktualisierungsanfrage als Reaktion auf eine Eingabe von der HMI/GUI 200 und/oder den NMDs 275, die mit dem Fahrzeug 100 in Kommunikation stehen/steht, zu generieren und an den (die) Remote-Server zu kommunizieren. Eine solche Aktualisierungsanfrage ermöglicht es einem Techniker und/oder Benutzer 100 des Fahrzeugs, den (die) Remote-Server abzufragen, um zu erfassen, ob Softwareaktualisierungen verfügbar sind. Die Fahrzeugsteuerung(en) sind dann ebenfalls in der Lage, als Reaktion darauf die RSUM und verwandte Softwareaktualisierungsdaten für das Fahrzeug 100 zu empfangen, sodass die Softwareaktualisierung wie bereits beschrieben fortgesetzt werden kann.
In einer weiteren Anordnung ist (sind) die fahrzeuginterne(n) Steuerung(en) außerdem konfiguriert, um auf ein Fahrzeug- und/oder Benutzerinteraktionssignal oder -signale zu reagieren, die durch die Steuerung(en) empfangen werden, während sich das Fahrzeug 100 in dem abgesicherten Modus befindet und eine Softwareaktualisierung durchgeführt wird. Ein solches Interaktionssignal/solche Interaktionssignale kann/können ein Erfassen, dass eine Tür geöffnet ist, eines elektronischen Türverriegelungs-/-entriegelungssignals und/oder einer Betätigung einer beliebigen anderen Fahrzeugkomponente, -vorrichtung und/oder eines anderen Fahrzeugsystems durch einen Benutzer beinhalten. Als Reaktion darauf ist (sind) die fahrzeuginterne(n) Steuerung(en) in einigen Variationen außerdem konfiguriert, um eine Warnmeldung über den abgesicherten Modus an eine oder mehrere von der HMI/GUI 200 und eine audiovisuelle Warnung zu generieren, um den konfigurierten abgesicherten Modus anzukündigen. Die audiovisuelle Warnung wird an zumindest eines von der HMI/GUI 200, Anzeigen 265 und/oder Frontscheinwerfern, Blinkern, Kombiinstrumentbeleuchtungen, eine externe Fahrzeughupe, ein Fahrzeugsprachsystem und/oder einen Fahrzeuglautsprecher 255, 260 und/oder andere audiovisuelle Vorrichtungen des Fahrzeugs 100 kommuniziert.
Unter erneuter Bezugnahme auf 1 und nun ebenfalls auf 2 kann der Fachmann der Technologie der Offenbarung außerdem nachvollziehen, dass die beschriebenen Anordnungen, Modifikationen und Variationen des Weiteren Betriebsverfahren beinhalten und sich auf diese beziehen, die eine oder mehrere der verschiedenen Steuerungen und Verarbeitungs- und Rechensysteme und andere Komponenten, Vorrichtungen und Systeme des Fahrzeugs 100 verwenden, die an anderer Stelle hierin beschrieben sind und die nun in 2 im Allgemeinen als (eine) Steuerung(en) 300 bezeichnet werden. Während verschiedene Verfahrensschritte in 2 in einer dargestellten Reihenfolge oder Abfolge wiedergegeben sind, dient eine solche Veranschaulichungen lediglich Beispielszwecken und ist nicht dahingehend auszulegen, dass sie eine bestimmte Reihenfolge oder Abfolge oder andere Einschränkung erforderlich macht.
Für weitere Beispiele beginnt ein Verfahren zum Steuern des Fahrzeugs 100 bei Schritt 305 und beinhaltet bei Schritt 310 Verbinden mit (einem) Remote-Server(n) in regelmäßigen Abständen und bei Schritt 315 Erfassen aktualisierter Software auf dem (den) Remote-Server(n). Wie an anderer Stelle hierin beschrieben, wird die aktualisierte Software auf dem (den) Remote-Server(n) durch eines oder mehreres von Empfangen der RSUM, SRD und/oder SVR und als Reaktion von entweder Antworten mit der SVL und/oder Empfangen einer aktualisierten SVL erfasst, sodass eines oder beide von dem (den) Remote-Server(n) und/oder der Steuerung(en) des Fahrzeugs 100 in der Lage sind, zu erfassen, ob kompatible und aktualisierte Software von dem (den) Remote-Server(n) verfügbar ist. Als Reaktion darauf beinhalten die Verfahren der Steuerung(en) und Verarbeitungs- und Rechensysteme 300 ferner bei Schritt 320 Herunterladen einer solchen aktualisierten Software auf das Fahrzeug 100 sowie SADs, die eine Verifizierung und Entschlüsselung der aktualisierten Software ermöglichen, die von dem (den) Remote-Server(n) wie bereits beschrieben empfangen wurde. Wenn die Verifizierung unter Verwendung der SAD bei Schritt 325 bestätigt, dass die Aktualisierungssoftware fehlerfrei heruntergeladen wurde, geht die Kontrolle der Verfahren der Steuerung(en) 300 zu Schritt 330 über.
Als Reaktion auf Erfassen eines Ruhezustands des Fahrzeugs 100 bei Schritt 330 beinhalten die Verfahren der Steuerung(en) 300 ferner bei Schritt 335 Erfassen, ob ein aktueller Zeitpunkt in dem vorbestimmten Plan PS liegt und, wenn dies der Fall ist, Erfassen bei Schritt 340, ob der SoC der Batterie(n) 130 die FCL überschreitet. Wenn der SoC der Batterie(n) 130 kleiner oder gleich der FCL ist, geht die Kontrolle zu Schritt 345 über und erfasst (erfassen) die Steuerung(en) 300, ob die RP ein unbeaufsichtigtes, automatisiertes Batterieladen ermöglicht. Wenn nicht, kehrt die Kontrolle zu Beginnschritt 305 zurück und kann die STAT-Nachricht, dass eine Aktualisierung aussteht, an Remote-Server und/oder die Fahrzeug-HMI/GUI 200 kommuniziert werden. Wenn die RP ein automatisiertes und unbeaufsichtigtes Batterieladen ermöglicht, geht die Kontrolle zu Schritt 350 über, um EON zu ermöglichen, bis die Batterie(n) 130 wiederaufgeladen ist (sind).
Sobald der SoC bei Schritt 340 über der FCL liegt, gehen die Verfahren der Steuerung(en) 300 zu Schritt 355 über und beinhalten Konfigurieren des Fahrzeugs 100 in den abgesicherten Modus mit dem KON, PK und EOF. Das Verfahren beinhaltet außerdem bei Schritt 360 Aktualisieren und/oder Flashen der Softwareaktualisierungen an der (den) Steuerung(en) und den Verarbeitungs- und Rechensystemen 300 und bei Abschluss Geben des Befehls zu dem KOF bei Schritt 365. Danach kehrt die Steuerung zu dem Beginnschritt 305 zurück und die Verfahren der Steuerung(en) und Verarbeitungs- und Rechensysteme 300 setzen das Überwachen bezüglich weiterer Softwareaktualisierungen fort.
Während vorstehend beispielhafte Ausführungsformen beschrieben werden, sollen diese Ausführungsformen nicht alle möglichen Formen der Erfindung beschreiben. Die in der Beschreibung verwendeten Ausdrücke sind beschreibende und keine einschränkenden Ausdrücke und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Geist und Schutzumfang der Erfindung abzuweichen. Zusätzlich können die Merkmale verschiedener umsetzender Ausführungsformen miteinander kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.
Gemäß der vorliegenden Erfindung ist ein Fahrzeug bereitgestellt, das eine bordeigene Steuerung aufweist, die zu Folgendem konfiguriert ist: als Reaktion auf Empfangen einer Remote-Softwareaktualisierungsnachricht für ein Fahrzeug, Herunterladen einer Softwareaktualisierung von einem Remote-Server auf das Fahrzeug; und als Reaktion auf Erfassen eines Fahrzeugruhezustands, Konfigurieren des Fahrzeugs in einen abgesicherten Modus, der einen Zustand mit eingeschaltetem Schlüsselschalter, Parkzustand und Zustand mit ausgeschaltetem Motor einschließt, Flashen und Verifizieren der Aktualisierung auf eine(r) oder mehrere(n) Fahrzeugsteuerungen und Beenden des abgesicherten Modus und Geben eines Befehls für einen Zustand mit ausgeschaltetem Schlüsselschalter.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die bordeigene Steuerung an eine Netzwerkkommunikationsvorrichtung gekoppelt und ferner zu Folgendem konfiguriert ist: Verbinden in regelmäßigen Abständen mit dem Remote-Server und, als Reaktion auf Empfangen einer Softwareversionsanforderung von dem Server, Generieren einer Antwort an den Server, die eine Softwareversionsliste beinhaltet, und Empfangen der Remote-Softwareaktualisierungsnachricht, die Authentifizierungsdaten zur Softwareaktualisierung beinhaltet.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die bordeigene Steuerung an einen drahtlosen Sendeempfänger gekoppelt ist und mit dem Remote-Server in Kommunikation steht und ferner zu Folgendem konfiguriert ist: als Reaktion darauf, dass eine Softwareversionsliste an den Server übertragen wird, Empfangen der Remote-Softwareaktualisierungsnachricht, die Authentifizierungsdaten zur Softwareaktualisierung beinhaltet, und Verifizieren der heruntergeladenen Softwareaktualisierung gemäß den Authentifizierungsdaten und, als Reaktion auf eine fehlgeschlagene Verifizierung, erneutes Herunterladen der Softwareaktualisierung und, als Reaktion auf eine erfolgreiche Verifizierung, Konfigurieren des Fahrzeugs in den abgesicherten Modus.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die bordeigene Steuerung ferner zu Folgendem konfiguriert ist: als Reaktion auf Erfassen, dass ein aktueller Zeitpunkt in einem vorbestimmten Aktualisierungsplan liegt, Konfigurieren des Fahrzeugs in den abgesicherten Modus und, als Reaktion auf Erfassen einer Nichtverfügbarkeit, Generieren einer Nachricht „Aktualisierung ausstehend“.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die bordeigene Steuerung ferner zu Folgendem konfiguriert ist: als Reaktion auf Erfassen, dass ein aktueller Zeitpunkt in einem vorbestimmten Aktualisierungsplan liegt, Konfigurieren des Fahrzeugs in den abgesicherten Modus und, als Reaktion auf Erfassen einer Nichtverfügbarkeit, Überwachen eines aktuellen Zeitpunkts, bis Erfassen, dass ein Zeitpunkt in dem vorbestimmten Aktualisierungsplan liegt.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die bordeigene Steuerung an eine Batterie gekoppelt und ferner zu Folgendem konfiguriert ist: Als Reaktion auf Erfassen, dass ein Batterieladezustand eine Flash-Ladungsgrenze überschreitet, Konfigurieren des Fahrzeugs in den abgesicherten Modus.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die bordeigene Steuerung ferner zu Folgendem konfiguriert ist: als Reaktion auf Erfassen einer Wiederaufladeberechtigung und, dass der Ladezustand (state of charge - SOC) die Grenze nicht überschreitet, Konfigurieren des Fahrzeugs in den abgesicherten Modus mit einem Zustand mit eingeschaltetem Motor, sodass die Batterie wiederaufgeladen wird, bis der SoC die Flash-Ladungsgrenze überschreitet.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die bordeigene Steuerung ferner zu Folgendem konfiguriert ist: als Reaktion auf eine Verifizierung der Aktualisierung und Beendigung des abgesicherten Modus, Kommunizieren eines Aktualisierungsstatus an einen oder mehrere von dem Remote-Server und dem Fahrzeug.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die bordeigene Steuerung an eine graphische Benutzerschnittstelle gekoppelt und ferner zu Folgendem konfiguriert ist: Generieren einer Aktualisierungsanfrage und Kommunizieren von dieser an den Remote-Server als Reaktion auf eine Eingabe von der graphischen Benutzerschnittstelle und Empfangen der Softwareaktualisierungsnachricht für das Fahrzeug als Reaktion darauf.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die bordeigene Steuerung an eine graphische Benutzerschnittstelle gekoppelt und ferner zu Folgendem konfiguriert ist: als Reaktion auf ein durch die Steuerung empfangenes Fahrzeug-/Benutzerinteraktionssignal, Generieren von zumindest einer von einer Warnmeldung über den abgesicherten Modus an der graphischen Benutzerschnittstelle und einer audiovisuellen Warnung, um den konfigurierten abgesicherten Modus anzukündigen.
Gemäß einer Ausführungsform ist ein Fahrzeug bereitgestellt, das eine bordeigene Steuerung aufweist, die an einen drahtlosen Sendeempfänger gekoppelt und zu Folgendem konfiguriert ist: als Reaktion auf Erfassen von aktualisierter Software auf einem Remote-Server, Herunterladen der Software auf das Fahrzeug; und als Reaktion auf Erfassen eines Ruhezustands während eines vorbestimmten Zeitraums, Konfigurieren des Fahrzeugs mit einem Zustand mit eingeschaltetem Zündschalter, einem Parkzustand und einem Zustand mit ausgeschalteten Motor, Flashen der Software auf zumindest eine Fahrzeugsteuerung und Geben eines Befehls für einen Zustand mit ausgeschaltetem Schlüsselschalter.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die bordeigene Steuerung ferner zu Folgendem konfiguriert ist: Verbinden mit dem Remote-Server in regelmäßigen Abständen und, als Reaktion auf Empfangen einer Softwareversionsanforderung von dem Server, Generieren einer Antwort an den Server, die eine Softwareversionsliste beinhaltet, und Herunterladen der Software mit Aktualisierungsauthentifizierungsdaten.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die bordeigene Steuerung ferner zum Kommunizieren mit dem Remote-Server und zu Folgendem konfiguriert ist: als Reaktion auf eine Softwareversionsliste, die an den Server übertragen wurde, Herunterladen der aktualisierten Software und Aktualisierungsauthentifizierungsdaten und Verifizieren der heruntergeladenen Softwareaktualisierung gemäß den Authentifizierungsdaten und, als Reaktion auf eine fehlgeschlagene Verifizierung, erneutes Herunterladen der aktualisierten Software und, als Reaktion auf eine erfolgreiche Verifizierung, Konfigurieren des Fahrzeugs in den Zustand mit ausgeschaltetem Schlüsselschalter.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die bordeigene Steuerung an eine Batterie gekoppelt ist und ferner zu Folgendem konfiguriert ist: als Reaktion auf Erfassen, dass ein Batterieladezustand eine Flash-Ladungsgrenze überschreitet, Konfigurieren des Fahrzeugs in den Zustand mit eingeschaltetem Schlüsselschalter, dem Parkzustand und dem Zustand mit ausgeschaltetem Motor.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die bordeigene Steuerung ferner an eine Batterie gekoppelt und zu Folgendem konfiguriert ist: als Reaktion auf Erfassen einer Wiederaufladeberechtigung und darauf, dass ein Ladezustand (state of charge - SoC) eine Flash-Ladungsgrenze nicht überschreitet, Konfigurieren des Fahrzeugs mit einem Zustand mit einem eingeschalteten Motor, sodass die Batterie wiederaufgeladen wird, bis der SoC die Flash-Grenze überschreitet.
Gemäß einer Ausführungsform ist ein Verfahren zum Steuern eines Fahrzeugs bereitgestellt, das eine bordeigene Steuerung aufweist, die an einen drahtlosen Sendeempfänger gekoppelt ist, als Reaktion auf Erfassen einer aktualisierten Software an einem Remote-Server, Herunterladen der Software auf das Fahrzeug; und, als Reaktion auf Erfassen eines Ruhezustands, Konfigurieren des Fahrzeugs mit einem Zustand mit eingeschaltetem Schlüsselschalter, Parkzustand und Zustand mit ausgeschaltetem Motor, und Geben eines Befehls für einen Zustand mit ausgeschaltetem Schlüsselschalter.
Gemäß einer Ausführungsform ist das Verfahren ferner dadurch gekennzeichnet, dass die bordeigene Steuerung Folgendes durchführt: Verbinden in regelmäßigen Abständen mit dem Remote-Server und, als Reaktion auf Empfangen einer Softwareversionsanforderung von dem Server, Generieren einer Antwort an den Server, die eine Softwareversionsliste beinhaltet, und Herunterladen der Software mit Aktualisierungsauthentifizierungsdaten.
Gemäß einer Ausführungsform ist das Verfahren ferner dadurch gekennzeichnet, dass die bordeigene Steuerung ferner zu Folgendem konfiguriert ist: Kommunizieren mit dem Remote-Server, als Reaktion auf Übertragen einer Softwareversionsliste an den Server, Herunterladen der aktualisierten Software und Aktualisierungsauthentifizierungsdaten und Verifizieren der heruntergeladenen Softwareaktualisierung gemäß den Authentifizierungsdaten und, als Reaktion auf eine fehlgeschlagene Verifizierung, erneutes Herunterladen der aktualisierten Software und, als Reaktion auf eine erfolgreiche Verifizierung, Konfigurieren des Fahrzeugs in den Zustand mit ausgeschaltetem Schlüsselschalter.
Gemäß einer Ausführungsform ist das Verfahren ferner dadurch gekennzeichnet, dass die bordeigene Steuerung an eine Batterie gekoppelt ist, als Reaktion auf Erfassen, dass ein Batterieladezustand eine Flash-Ladungsgrenze überschreitet, Konfigurieren des Fahrzeugs in den Zustand mit eingeschaltetem Schlüsselschalter, Parkzustand und Zustand mit ausgeschaltetem Motor.
Gemäß einer Ausführungsform ist das Verfahren ferner dadurch gekennzeichnet, dass die bordeigene Steuerung an eine Batterie gekoppelt ist und ferner zu Folgendem konfiguriert ist: als Reaktion auf Erfassen einer Wiederaufladeberechtigung und darauf, dass ein Ladezustand (state of charge - SoC) eine Flash-Ladungsgrenze nicht überschreitet, Konfigurieren des Fahrzeugs mit einem Zustand mit einem eingeschalteten Motor, sodass die Batterie wiederaufgeladen wird, bis der SoC die Flash-Grenze überschreitet.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

Telematiknorm der Society of Automotive Engineers International.TM. (SAE), und verwandte Normen schließen zum Beispiel die SAE-Norm J2735 mit dem Titel „Dedicated Short Range Communications (DSRC) Message Set Dictionary Standard,“ SAE J2735_201603, ein, verfügbar unter standards.sae.org/j2735_201603 [0033]
IEEE-WAVE-Normen 1609 [0036]
Norm 802.11 [0037]

Claims

Fahrzeug, umfassend: eine bordeigene Steuerung, die zu Folgendem konfiguriert ist: als Reaktion auf Empfangen einer Remote-Softwareaktualisierungsnachricht für ein Fahrzeug, Herunterladen einer Softwareaktualisierung von einem Remote-Server auf das Fahrzeug; und, als Reaktion auf Erfassen eines Fahrzeugruhezustands, Konfigurieren des Fahrzeugs in einen abgesicherten Modus, der einen Zustand mit eingeschaltetem Schlüsselschalter, Parkzustand und Zustand mit ausgeschaltetem Motor einschließt. Flashen und Verifizieren der Aktualisierung auf eine(r) oder mehrere(n) Fahrzeugsteuerungen und Beenden des abgesicherten Modus und Geben eines Befehls für einen Zustand mit ausgeschaltetem Schlüsselschalter.
Fahrzeug nach Anspruch 1, umfassend: die bordeigene Steuerung, die an eine Netzwerkkommunikationsvorrichtung gekoppelt und ferner zu Folgendem konfiguriert ist: Verbinden mit dem Remote-Server in regelmäßigen Abständen und, als Reaktion auf Empfangen einer Softwareversionsanforderung von dem Server, Generieren einer Antwort an den Server, die eine Softwareversionsliste beinhaltet, und Empfangen der Remote-Softwareaktualisierungsnachricht, die Authentifizierungsdaten zur Softwareaktualisierung beinhaltet.
Fahrzeug nach Anspruch 1, umfassend: die bordeigene Steuerung, die an einen drahtlosen Sendeempfänger gekoppelt ist und mit dem Remote-Server in Kommunikation steht und ferner zu Folgendem konfiguriert ist: als Reaktion auf eine Softwareversionsliste, die an den Server übertragen wurde, Empfangen der Remote-Softwareaktualisierungsnachricht, die Authentifizierungsdaten zur Softwareaktualisierung beinhaltet, und Verifizieren der heruntergeladenen Softwareaktualisierung gemäß den Authentifizierungsdaten und, als Reaktion auf eine fehlgeschlagene Verifizierung, erneutes Herunterladen der Softwareaktualisierung und, als Reaktion auf eine erfolgreiche Verifizierung, Konfigurieren des Fahrzeugs in den abgesicherten Modus.
Fahrzeug nach Anspruch 1, umfassend: die bordeigene Steuerung, die ferner zu Folgendem konfiguriert ist: als Reaktion auf Erfassen, dass ein aktueller Zeitpunkt in einem vorbestimmten Aktualisierungsplan liegt, Konfigurieren des Fahrzeugs in den abgesicherten Modus und, als Reaktion auf Erfassen einer Nichtverfügbarkeit, Generieren einer Nachricht „Aktualisierung ausstehend“.
Fahrzeug nach Anspruch 1, umfassend: die bordeigene Steuerung, die ferner zu Folgendem konfiguriert ist: als Reaktion auf Erfassen, dass ein aktueller Zeitpunkt in einem vorbestimmten Aktualisierungsplan liegt, Konfigurieren des Fahrzeugs in den abgesicherten Modus und, als Reaktion auf Erfassen einer Nichtverfügbarkeit, Überwachung eines aktuellen Zeitpunkts bis Erfassen eines Zeitpunkts, der in dem vorbestimmten Aktualisierungsplan liegt.
Fahrzeug nach Anspruch 1, umfassend: die bordeigene Steuerung, die an eine Batterie gekoppelt und ferner zu Folgendem konfiguriert ist: als Reaktion auf Erfassen, dass ein Batterieladezustand eine Flash-Ladungsgrenze überschreitet, Konfigurieren des Fahrzeugs in den abgesicherten Modus.
Fahrzeug nach Anspruch 6, umfassend: die bordeigene Steuerung, die ferner zu Folgendem konfiguriert ist: als Reaktion auf Erfassen einer Wiederaufladeberechtigung und darauf, dass der Ladezustand (state of charge - SoC) die Grenze nicht überschreitet, Konfigurieren des Fahrzeugs in den abgesicherten Modus mit einem Zustand mit eingeschaltetem Motor, sodass die Batterie wiederaufgeladen wird, bis der SoC die Flash-Ladungsgrenze überschreitet.
Fahrzeug nach Anspruch 1, umfassend: die bordeigene Steuerung, die ferner zu Folgendem konfiguriert ist: als Reaktion auf eine Verifizierung der Aktualisierung und Beenden des sicheren Modus, Kommunizieren eines Aktualisierungsstatus an einen oder mehrere von dem Remote-Server und dem Fahrzeug.
Fahrzeug nach Anspruch 1, umfassend: die bordeigene Steuerung, die an eine graphische Benutzerschnittstelle gekoppelt und ferner zu Folgendem konfiguriert ist: Generieren einer Aktualisierungsanfrage und Kommunizieren von dieser an den Remote-Server als Reaktion auf eine Eingabe von der graphischen Benutzerschnittstelle und Empfangen der Softwareaktualisierungsnachricht für das Fahrzeug als Reaktion darauf.
Fahrzeug nach Anspruch 1, umfassend: die bordeigene Steuerung, die an eine graphische Benutzerschnittstelle gekoppelt und ferner zu Folgendem konfiguriert ist: als Reaktion auf ein durch die Steuerung empfangenes Fahrzeug-/Benutzerinteraktionssignals, Generieren von zumindest einer von einer Warnmeldung über den abgesicherten Modus an der graphischen Benutzerschnittstelle und einer audiovisuellen Warnung, um den konfigurierten abgesicherten Modus anzukündigen.
Verfahren zum Steuern eines Fahrzeugs, umfassend: durch eine bordeigene Steuerung, die an einen drahtlosen Sendeempfänger gekoppelt ist, als Reaktion auf Erfassen einer aktualisierten Software an einem Remote-Server, Herunterladen der Software auf das Fahrzeug; und als Reaktion auf Erfassen eines Ruhezustands, Konfigurieren des Fahrzeugs in einen Zustand mit eingeschaltetem Schlüsselschalter, Parkzustand und Zustand mit ausgeschaltetem Motor, Flashen der Software auf zumindest eine Fahrzeugsteuerung und Geben eines Befehls für einen Zustand mit ausgeschaltetem Schlüsselschalter.
Verfahren nach Anspruch 11, umfassend: durch die bordeigene Steuerung, Verbinden in regelmäßigen Abständen mit dem Remote-Server und, als Reaktion auf Empfangen einer Softwareversionsanforderung von dem Server, Generieren einer Antwort an den Server, die eine Softwareversionsliste beinhaltet, und Herunterladen der Software mit Aktualisierungsauthentifizierungsdaten.
Verfahren nach Anspruch 11, ferner umfassend: durch die bordeigene Steuerung, die ferner konfiguriert ist, um mit dem Remote-Server zu kommunizieren, als Reaktion auf Übertragen einer Softwareversionsliste an den Server, Herunterladen der aktualisierten Software und Aktualisierungsauthentifizierungsdaten und Verifizieren der heruntergeladenen Softwareaktualisierung gemäß den Authentifizierungsdaten und, als Reaktion auf eine fehlgeschlagene Verifizierung, erneutes Herunterladen der aktualisierten Software und, als Reaktion auf eine erfolgreiche Verifizierung, Konfigurieren des Fahrzeugs in den Zustand mit ausgeschaltetem Schlüsselschalter.
Verfahren nach Anspruch 11, umfassend: durch die bordeigene Steuerung, die an eine Batterie gekoppelt ist, als Reaktion auf Erfassen, dass ein Batterieladezustand eine Flash-Ladungsgrenze überschreitet, Konfigurieren des Fahrzeugs in den Zustand mit eingeschaltetem Schlüsselschalter, Parkzustand und Zustand mit ausgeschaltetem Motor.
Verfahren nach Anspruch 11, ferner umfassend: durch die bordeigene Steuerung, die an eine Batterie gekoppelt und ferner zu Folgendem konfiguriert ist: als Reaktion auf Erfassen einer Wiederaufladeberechtigung und darauf, dass ein Ladezustand (state of charge - SoC) eine Flash-Ladungsgrenze nicht überschreitet, Konfigurieren des Fahrzeugs in einen Zustand mit eingeschalteten Motor, sodass die Batterie wiederaufgeladen wird, bis der SoC die Flash-Grenze überschreitet.