DE102022116213A1

DE102022116213A1 - Verfahren und Steuergerät und Kraftfahrzeug, bei welchem jeweils ein Datenverwaltungsmodul einer Laufzeitumgebung abzuspeichernde Daten aus einer Applikationssoftware empfängt und diese Daten dauerhaft abspeichert

Info

Publication number: DE102022116213A1
Application number: DE102022116213.3A
Authority: DE
Inventors: Daniel Kerk; Matthias Pohl
Original assignee: Cariad SE
Current assignee: Cariad SE
Priority date: 2022-06-29
Filing date: 2022-06-29
Publication date: 2024-01-04

Abstract

Die Erfindung betrifft ein Verfahren zum Betreiben einer Prozessorschaltung (15) eines Steuergeräts (14) eines Kraftfahrzeugs (10), wobei in einer Laufzeitumgebung (16) der Prozessorschaltung (15) zumindest eine Applikationssoftware (17) ausführt und durch ein Datenverwaltungsmodul (31) der Laufzeitumgebung (16) aus der jeweiligen Applikationssoftware (17) eine jeweilige Persistierungsanfrage (33) empfangen wird, durch welche abzuspeichernde Daten (32) der Applikationssoftware (17) an das Datenverwaltungsmodul (31) übergegeben werden. Die Erfindung sieht vor, dass eine jeweilige Kopplung zu mehreren Datenspeichern (37) bereitgestellt wird, wobei jeder der Datenspeicher (37) eine speicherspezifische Speichercharakteristik (30) aufweist, und zu der jeweiligen Persistierungsanfrage (33) eine Nutzungsklasse (35) betreffend eine zukünftige Nutzung der Daten (32) ermittelt wird und durch das Datenverwaltungsmodul (31) mittels einer Zuordnungsroutine (36) anhand der ermittelten Nutzungsklasse (35) einer der Datenspeicher (37) ausgewählt wird.

Description

Die Erfindung betrifft ein Verfahren zum Betreiben einer Prozessorschaltung eines Steuergeräts eines Kraftfahrzeugs, um zumindest eine Applikationssoftware in dem Steuergerät auszuführen und Daten der jeweiligen Applikationssoftware bedarfsgerecht abzuspeichern. Zu der Erfindung gehört auch ein Steuergerät, dessen Prozessorschaltung gemäß dem Verfahren betrieben werden kann, sowie ein Kraftfahrzeug mit einem solchen Steuergerät.
In einem Steuergerät kann dessen Prozessorschaltung eine Laufzeitumgebung, beispielsweise ein Betriebssystem oder eine AUTOSAR-Laufzeitumgebung, betreiben, damit darin zumindest eine Applikationssoftware eine Fahrzeugfunktionalität, beispielsweise eine Navigationsassistenz oder die Steuerung eines Motors oder eine automatisierte Fahrfunktion, bereitstellen kann. Eine solche Applikationssoftware kann den Bedarf haben, Daten zu „persistieren“, das heißt für einen vorbestimmten Zeitraum und/oder über ein vorbestimmtes Ereignis, beispielsweise einen Neustart des Steuergeräts, hinweg abzuspeichern. Hierzu benötigt eine Applikationssoftware einen Zugriff auf einen für den Zeitraum und/oder das Ereignis geeigneten Datenspeicher. Dieser Zugriff kann in einer Laufzeitumgebung durch ein Datenverwaltungsmodul ermöglicht sein, an welches die Applikationssoftware eine entsprechende Persistierungsanfrage richten oder übergeben kann, durch welche abzuspeichernde Daten an das Datenverwaltungsmodul zum Abspeichern in einem Datenspeicher übergeben oder beschrieben werden.
In einem Steuergerät ist allerdings aus Gründen des Energiebedarfs und/oder der Herstellungskosten nicht jeder Speichertyp mit beliebig großer Speicherkapazität verfügbar. So gibt es je nach Speichertyp eine Limitierung der Speicherkapazität (z.B. für schnellen, Reset-resistenten RAM (Arbeitsspeicher/Random Access Memory)) und/oder die Zahl der zulässigen Lesezyklen und Schreibzyklen kann bei einem Massenspeicher, wie beispielsweise gemäß der Flash-Technologie begrenzt sein. Daher kann es beim Abspeichern von Daten einer Applikationssoftware zu dem Konflikt kommen, dass solche Daten in einem Datenspeicher abgespeichert werden, der bei einer zukünftigen Nutzung der Daten (z.B. einem häufigen Zugriff) zu einer Beeinträchtigung des Betriebs der Applikationssoftware führen kann, weil beispielsweise die Wiederbeschaffung oder die Zugriffszeit auf die Daten derart groß ist, dass der Betrieb der Applikationssoftware währenddessen angehalten werden muss.
Aus der DE 10 2020 121 645 A1 ist bekannt, dass Sensordaten mehrerer Sensoren in unterschiedliche Speicherbereiche eines Datenspeichers kanalisiert werden, um hierdurch eine effiziente Übertragung der Sensordaten aus den Sensoren in den Datenspeicher zu gewährleisten.
Aus der US 2009 / 0164838 A1 ist bekannt, dass ein Speicher einer Bremssteuerung eines Kraftfahrzeugs in mehrere Datenblöcke unterteilt sein kann, auf die mittels eines Mikroprozessors der Bremssteuerung selektiv in Abhängigkeit davon zugegriffen wird, ob es zuvor einen Fehler in dem jeweiligen Speicherblock gegeben hat.
Aus der DE 10 2017 223 856 A1 ist bekannt, dass bei einem Navigationssystem ein Nutzer angeben kann, ob er Routendaten einer benutzten Route dauerhaft abspeichern möchte oder nicht.
Der Erfindung liegt die Aufgabe zugrunde, in einem Steuergerät beim Abspeichern von Daten einer Applikationssoftware mittels eines Datenverwaltungsmoduls zu vermeiden, dass es bei einem späteren Abruf der Daten z.B. durch die Applikationssoftware zu einer Beeinträchtigung von deren Betrieb durch eine Verzögerung bei der Wiederbeschaffung der Daten kommt.
Die Aufgabe wird durch die Gegenstände der unabhängigen Patentansprüche gelöst. Vorteilhafte Weiterentwicklungen der Erfindung sind durch die abhängigen Patentansprüche, die folgende Beschreibung sowie die Figur beschrieben.
Als eine Lösung umfasst die Erfindung ein Verfahren zum Betreiben einer Prozessorschaltung eines Steuergeräts eines Kraftfahrzeugs. Das Verfahren geht davon aus, dass durch die Prozessorschaltung in einer Laufzeitumgebung zumindest eine Applikationssoftware ausgeführt wird. Durch ein Datenverwaltungsmodul der Laufzeitumgebung wird aus der jeweiligen Applikationssoftware eine jeweilige Persistierungsanfrage empfangen, durch welche abzuspeichernde Daten der Applikationssoftware an das Datenverwaltungsmodul übergeben werden. Dies ist eine vorteilhafte Anordnung, bei welcher eine Applikationssoftware ihre abzuspeichernden Daten, insbesondere nicht-flüchtig abzuspeichernde Daten, nicht selbst auf einem Datenspeicher abspeichert, sondern die abzuspeichernden Daten einem Datenverwaltungsmodul zum Abspeichern übergibt. So wird ermöglicht, dass die Auswahl des Datenspeichers durch die Laufzeitumgebung mittels ihres Datenverwaltungsmoduls erfolgen kann, damit in der Applikationssoftware kein Vorwissen oder keine Information zu den verfügbaren Datenspeichern bereitgestellt werden muss.
Um der jeweiligen Applikationssoftware deren Daten insbesondere gemäß den späteren Nutzungsanforderungen der Applikationssoftware wieder zur Verfügung stellen zu können, ist erfindungsgemäß vorgesehen, dass die Laufzeitumgebung eine Kopplung zu mehreren Datenspeichern bereitstellt, also nicht nur einen einzelnen Datenspeicher zum Speichern von Daten aus der zumindest einen Applikationssoftware bereithält, sondern lokal und/oder außerhalb des Steuergeräts und/oder sogar außerhalb des Kraftfahrzeugs mehrere Datenspeicher nutzen kann und/oder mit mehreren Datenspeichern gekoppelt ist. Jeder Datenspeicher weist natürlich oder immanent eine speicherspezifische Speicherspezifizierung oder Speichercharakteristik auf, die nun in dem Datenverwaltungsmodul registriert oder beschrieben ist oder angegeben oder gespeichert ist. Somit kann zu jedem Datenspeicher in dem Datenverwaltungsmodul dessen Speicherspezifizierung oder Speichercharakteristik beispielsweise als Spezifizierungsdaten des jeweiligen Datenspeichers gespeichert oder verfügbar sein.
Stellt nun eine Applikationssoftware eine Persistierungsanfrage, so wird in dem Datenverwaltungsmodul zu der jeweiligen Persistierungsanfrage eine Nutzungsklasse betreffend das Abspeichern der Daten selbst (beispielsweise das benötigte Speichervolumen) und/oder betreffend eine nach dem Abspeichern zu erwartende, zukünftige Nutzung der Daten (beispielsweise eine Abrufhäufigkeit) ermittelt. Durch das Datenverwaltungsmodul wird anhand der ermittelten Nutzungsklasse einer der Datenspeicher ausgewählt. Ein Zuordnungsroutine des Datenverwaltungsmoduls überprüft hierzu, ob der Nutzungsklasse durch die jeweilige speicherspezifische Speichercharakteristik der Datenspeicher entsprochen wird. Wird also beispielsweise durch die Nutzungsklasse angegeben, dass ein Zugriff auf die abgespeicherten Daten innerhalb von einer vorbestimmten Höchstzeitdauer, beispielsweise innerhalb von 100 Millisekunden, möglich sein muss, so wird durch die Zuordnungsroutine ein solcher der Datenspeicher ausgewählt, der dieser Nutzungsklasse entspricht oder sogar besser ist, also gemäß seiner Speichercharakteristik eine Zugriffsdauer gemäß der Höchstzugriffsdauer oder darunter, also schneller, aufweist. Es wird also ermittelt, ob eine der Nutzungsklasse entsprechende Nutzung des Datenspeichers möglich ist und/oder dies keine lebensdauerverkürzende Einwirkung auf den Datenspeicher darstellt. Mittels der Zuordnungsroutine kann der Fachmann festlegen, welche für welche Nutzungsklassen welcher Datenspeicher verwendet werden soll. Es kann ein Default-Datenspeicher festgelegt werden, der Daten aufnehmen kann, die anderweitig nicht zugeordnet werden können. Werden mehrere Datenspeicher als geeignet oder der Nutzungsklasse entsprechend ermittelt, so kann gemäß zumindest einem vorgegebenen sekundären Auswahlkriterium (beispielsweise Verschleißzustand des jeweiligen Datenspeichers) und/oder zufällig ausgewählt werden. Die abgespeicherten Daten werden dann in dem ausgewählten Datenspeicher abgespeichert.
Durch die Erfindung ergibt sich der Vorteil, dass abzuspeichernde Daten auch dahingehend klassifiziert werden, dass ihr Abspeichervorgang selbst (z.B. Datenmenge) und/oder ihre erwartete zukünftige Nutzung beim Auswählen eines aus den mehreren Datenspeichern für deren Speicherung berücksichtigt wird. Somit kann vermieden werden, dass die Daten in einem Datenspeicher abgespeichert werden, der für die Datenmenge und/oder die zukünftige Nutzung durch die Applikationssoftware und/oder durch ein anderes Gerät ungeeignet ist.
Nachdem die Daten in dem ausgewählten Datenspeicher abgespeichert wurden, kann die Applikationssoftware auf die abgespeicherten Daten wieder beispielsweise mittels einer Abrufanfrage die Daten von dem Datenverwaltungsmodul anfordern. Das Datenverwaltungsmodul liest dann die angeforderten Daten aus dem jeweiligen Datenspeicher aus und übergibt sie an die Applikationssoftware. Zusätzlich oder alternativ zu einer Abrufanfrage kann eine Applikationssoftware beispielsweise auch eine Änderungsanfrage zum Aktualisieren der Daten und/oder eines Teils der Daten beim Datenverwaltungsmodul stellen. Hierdurch kann sich dann beispielsweise ein weiterer Schreibzugriff auf die Daten ergeben, wodurch die Daten beispielsweise ergänzt oder ausgetauscht werden.
Die Erfindung umfasst auch Weiterentwicklungen, durch die sich zusätzliche Vorteile ergeben.
Um die Datenspeicher aussagekräftig voneinander zu unterscheiden, wird als Speichercharakteristik zumindest eines der folgenden Speicherattribute des jeweiligen Datenspeichers beschrieben: Zu einem Datenspeicher kann eine Verbindungsart, über welche der Datenspeicher mit der Prozessorschaltung gekoppelt ist, gespeichert werden. So kann beispielsweise angegeben werden, ob der Datenspeicher ausschließlich über eine fahrzeuginterne Datenverbindung und/oder einen steuergeräteinternen Daten-BUS und/oder ein Daten-Netzwerk des Kraftfahrzeugs (beispielsweise Ethernet) angekoppelt ist und/oder ob der Datenspeicher über einen lösbaren Anschluss und damit temporär nicht-verfügbar angeschlossen ist und/oder ob sich der Datenspeicher in einem mobilen Endgerät eines Benutzers befindet und/oder ob der Datenspeicher sogar fahrzeugextern über eine Mobilfunkverbindung und/oder eine WLAN-Funkverbindung (WLAN - Wireless Local Area Network) angebunden ist. Zusätzlich oder alternativ dazu kann als Speicherattribut angegeben sein, wo sich der Speicherort des Datenspeichers befindet, ob es sich um einen Onboard-Speicher, einen mobilen Datenspeicher und/oder einen Offboard-Datenspeicher handelt. Zusätzlich oder alternativ kann zu dem Datenspeicher als Speicherattribut eines Mindestzugriffsdauer und/oder eine Höchstzugriffsdauer angegeben sein. Die Zugriffsdauer gibt jeweils an, welche Zeitdauer oder es benötigt, um die Daten in dem Datenspeicher aufzufinden und einen Auslesevorgang zu beginnen. Als weiteres Speicherattribut kann zusätzlich oder alternativ dazu eine Speicherkapazität des Datenspeichers insgesamt und/oder eine aktuelle und/oder bereits verplante oder zugeteilte Speicherbelegung des Datenspeichers angegeben werden und/oder umgekehrt eine aktuell verfügbare Speichermenge und/oder nach der Planung noch nicht reservierte freie Speichermenge. Zusätzlich oder alternativ dazu kann als Speicherattribut eine Zyklenbelastbarkeit für Schreibzyklen und/oder Lesezyklen des Datenspeichers angegeben sein. Beispielsweise kann eine Maximalanzahl entsprechender Zyklen und/oder eine Höchstrate (Schreibvorgang und/oder Lesevorgänge pro Zeiteinheit, beispielsweise pro Sekunde) angegeben sein. Durch die beschriebenen Speicherattribute kann sich eine den Betrieb einer Applikationssoftware beeinträchtigenden Nutzungsbeschränkung bei Nutzung des entsprechenden Datenspeichers ergeben. Somit ist es von Vorteil, diese Speicherattribute in einer Speichercharakteristik anzugeben und beim Auswählen eines Datenspeichers zu berücksichtigen.
Gemäß einer Weiterentwicklung wird nach dem Abspeichern der Daten in den ausgewählten Datenspeicher durch das Datenverwaltungsmodul eine tatsächliche weitere Nutzung der abgespeicherten Daten überwacht. Das Datenverwaltungsmodul kann somit überprüfen, ob die Nutzung der Daten durch die Applikationssoftware tatsächlich der ermittelten Nutzungsklasse entspricht. Für den Fall, dass die tatsächliche Nutzung der durch die ermittelten Nutzungsklasse signalisierten erwarteten Nutzung abweicht, wird durch die Zuordnungsroutine ein anderer der Datenspeicher, dessen Speichercharakteristik der ermittelten tatsächlichen Nutzung entspricht, neu ausgewählt und die Daten werden in den neu ausgewählten Datenspeicher umgelagert. Somit wird also auch nach dem Abspeichern noch einmal sichergestellt oder die Speichercharakteristik durch Wechseln des Datenspeichers dahingehend verbessert, dass sie der tatsächlichen Nutzung entspricht. So kann es beispielsweise sein, dass für den Fall, dass die Daten längere Zeit nicht genutzt sind oder ungenutzt bleiben, also durch die Applikationssoftware kein Abruf der Daten erfolgt, die Daten in einen anderen Datenspeicher umgelagert werden, der für ein Backup oder eine Archivierung vorgesehen ist.
Eine Weiterentwicklung berücksichtigt, dass nicht nur die Nutzungsklasse allein, sondern auch der aktuelle Zustand des jeweiligen Datenspeichers für die Auswahl entscheidend sein kann. Durch die Zuordnungsroutine wird in diesem Fall zusätzlich ein aktueller und/oder ein bereits festgelegter zukünftiger Auslastungszustand desjenigen Datenspeichers überprüft, der vorläufig anhand der Nutzungsklasse der Daten zunächst ausgewählt oder ermittelt wurde. Falls der Auslastungszustand ein in dem Datenverwaltungsmodul vorgegebenes Ausschlusskriterium erfüllt, wird ein anderer der Datenspeicher anhand der Nutzungsklasse ausgewählt. Wird beispielsweise anhand der Nutzungsklasse festgestellt, dass ein RAM-Speichermodul für die Daten oder die Nutzungsklasse geeignet ist, aber anhand eines bereits festgelegten zukünftigen Auslastungszustands erkannt, dass in dem RAM bereits für eine andere Anwendungsapplikation ein Speicherblock reserviert worden ist, der aber noch nicht genutzt wird, so kann dies berücksichtigt werden und ein alternativer Datenspeicher ausgewählt werden. Wird auch bei dem alternativen Datenspeicher das Ausschlusskriterium erfüllt, so kann der Vorgang wiederholt werden, bis ein geeigneter Datenspeicher gefunden wurde.
Um einer Applikationssoftware die Möglichkeit zu geben, die zu speichernden Daten und/oder eine geplante oder zu erwartende Nutzung dieser Daten zu signalisieren, wird gemäß einer Weiterentwicklung als mögliche Nutzungsklassen zumindest eine der folgenden vorgesehen. Eine mögliche Nutzungsklasse kann sein, dass der Zugriff auf die gespeicherten Daten jederzeit erfolgen muss. Entsprechend muss durch die Zuordnungsroutine ein Datenspeicher ausgewählt werden, der dauerhaft mit der Prozessorschaltung gekoppelt ist, also beispielsweise kein temporär gekoppelter Datenspeicher sein darf. Eine Nutzungsklasse kann besagen, dass der Zugriff nur beim nächsten oder jedem Neustart der Software-Applikation erfolgen muss, wenn es sich beispielsweise um Konfigurationsdaten oder Initialisierungsdaten handelt. Dann muss der Datenspeicher entsprechend nur zu diesen Ereignissen des Neustarts mit der Prozessorschaltung gekoppelt sein oder von dieser lesbar sein. Eine Nutzungsklasse kann angeben, dass der Zugriff innerhalb einer vorgegebenen Höchstzugriffszeitdauer erfolgen können muss. Dann muss ein Datenspeicher durch die Zuordnungsroutine ausgewählt werden, der für jedes Datenelement aus den Daten das Auffinden und Auslesen des Datenelements innerhalb der Höchstzugriffszeitdauer (also auch schneller als diese) bereitstellen können muss. Eine Nutzungsklasse kann besagen, dass der Zugriff innerhalb einer Höchstwartedauer für den Erstzugriff erfolgen können muss. Dann muss die Zuordnungsroutine einen Datenspeicher ermitteln oder auswählen, zu dem die Kopplung oder eine Datenverbindung innerhalb der Höchstwartedauer aufgebaut werden können muss, wobei es sich um einen zwischendurch entkoppelten Datenspeicher, beispielsweise einen stationären Datenspeicher im Internet, handeln kann, zu dem zunächst eine Datenverbindung aufgebaut werden muss. Eine Nutzungsklasse kann einen Zugriff mit einer vorgegebenen Mindestdatenrate verlangen. Dies besagt, dass die Auslesegeschwindigkeit der Daten (Daten pro Zeiteinheit, beispielsweise pro Sekunden) größer als die Mindestdatenrate sein muss. Eine Nutzungsklasse kann auch eine Kombination mehrerer der besagten Nutzungsklassen vorsehen, beispielsweise einen Zugriff innerhalb der Höchstwartedauer für den Erstzugriff und dann einen Zugriff mit der vorgegebenen Mindestdatenrate. Dies ist eine typische Nutzungsklasse bei ausgelagerten oder entkoppelten Datenspeichern, die zunächst mit der Prozessorschaltung gekoppelt werden müssen, bevor die Daten ausgelesen werden können. Eine Nutzungsklasse kann besagen, dass der Zugriff nur durch ein fahrzeugfremdes Gerät erfolgt, also die Daten in einen Datenspeicher ausgelagert werden können, der von dem Steuergerät selbst nicht mehr gelesen können werden muss. Dies sind beispielsweise Diagnosedaten, die von einem Diagnosegerät ausgelesen können werden sollen. Eine Nutzungsklasse kann eine Aktualisierungshäufigkeit und/oder eine Aktualisierungsrate der Daten angeben, also eine Änderungsrate der Daten signalisieren. Die Zuordnungsroutine muss dann einen Datenspeicher auswählen, der eine entsprechende Zyklenbelastbarkeit aufweist. Eine Nutzungsklasse kann ein Datenvolumen der Daten angeben, wobei dies auch ein Werteintervall angeben kann, beispielsweise „wenige Daten“, „viele Daten“, wobei diesen Klassenangaben entsprechende Volumenwerte zugeordnet sein können. Eine Nutzungsklasse kann einen Kostenwert bei Datenverlust angeben, wodurch die Zuordnungsvorschrift auch einen in Bezug auf Ausfallsicherheit unsicheren Datenspeicher auswählen kann, beispielsweise einen Massendatenspeicher wie eine HDD (Hard Disc Drive). Beispiele für Daten mit geringem Kostenwert sind Fahrprotokolle, die (soweit verfügbar) für Analysen verwendet werden sollen.
Um für eine Prozessorschaltung Datenspeicher mit unterschiedlichen geeigneten Speichercharakteristiken bereitzustellen, sieht eine Weiterentwicklung vor, dass die mehreren Datenspeicher zumindest einen der folgenden umfassen:

• einen reset-festen RAM der Prozessorschaltung,
• einen Flash-Speicher der Prozessorschaltung,
• einen über ein Datennetzwerk angebundenen Flash in anderem Steuergerät des Kraftfahrzeugs,
• eine von einem Benutzer manuell entnehmbare externe SD-Karte und/oder SSD,
• eine temporär angeschlossenes mobiles Endgerät eines Benutzers,
• ein fahrzeugexterner Cloudspeicher und/oder ein Backend des Kraftfahrzeugs.

Eine Weiterentwicklung umfasst, dass bei dem Abspeichern von Daten aus mehreren zeitlich überlappenden Persistierungsanfragen mehrerer Applikationssoftwaren durch das Datenverwaltungsmodul eine Priorisierung für den Fall vorgenommen wird, dass es einen Konflikt betreffend einen Datenspeicher gibt. Die Priorisierung wird anhand von Priorisierungsdaten des Datenverwaltungsmoduls durchgeführt und für diejenigen Daten der niederprioren Applikationssoftware wird ein alternativer Datenspeicher ausgewählt. Mit anderen Worten kann eine hochpriore Applikationssoftware die Daten einer niederprioren Applikationssoftware verdrängen, falls beide Persistierungsanfragen noch zu entscheiden sind oder für beide Persistierungsanfragen noch ein Datenspeicher ausgewählt werden muss.
Allgemein kann vorgesehen sein, dass durch die Zuordnungsroutine für den Fall, dass kein geeigneter Datenspeicher zur Verfügung steht, der der Nutzungsklasse entspricht, aus den zur Verfügung stehenden Datenspeichern derjenige ausgewählt wird, der mit seiner Speichercharakteristik die größte Ähnlichkeit oder die geringste Diskrepanz zur geforderten Nutzungsklasse aufweist.
Eine Weiterentwicklung umfasst, dass die Nutzungsklasse an einer API des Datenmoduls (API - Application Programming Interface) als Teil der Persistierungsanfrage übergeben wird. Mit anderen Worten kann die Software-Applikation selbst signalisieren, welche Nutzungsklasse geplant ist. Dies führt zur zuverlässigsten Einschätzung der Nutzungsklasse. Alternativ dazu ist vorgesehen, dass das Datenverwaltungsmodul unabhängig von der Persistierungsanfrage in Konfigurationsdaten enthalten ist, die eine Zuordnung von unterschiedlichen möglichen Datentypen zu einer jeweiligen Angabe einer Nutzungsklasse enthalten. Das Datenverwaltungsmodul ermittelt einen tatsächlichen Datentyp der Daten, die zu speichern sind und mittels der Konfigurationsdaten wird dann die Nutzungsklasse zugeordnet oder ausgewählt. Der Datentyp kann beispielsweise in einem Header einer Datei, in welcher die Daten gespeichert sind, und/oder in einem Dateinamen dieser Datei ermittelt werden, um nur Beispiele zu nennen. Die beiden Möglichkeiten zum Ermitteln der Nutzungsklasse, also die API und/oder die Konfigurationsdaten, stellen keine abschließende Möglichkeit der Implementierung der Ermittlung der Nutzungsklasse dar.
Gemäß einer Weiterentwicklung wird jede Persistierungsanfrage oder werden alle Persistierungsanfragen zumindest einer Applikationssoftware oder jeder Applikationssoftware über dieselbe Schnittstelle des Datenverwaltungsmoduls empfangen. Mit anderen Worten stellt das Datenverwaltungsmodul eine zentrale Speicherverwaltung für die Prozessorschaltung oder zumindest die Laufzeitumgebung dar. Hiermit ergibt sich der Vorteil, dass die Datenspeicher und insbesondere der Zugriff und/oder die Auslastung vollständig unter der Kontrolle des Datenverwaltungsmoduls ist.
Die beschriebene Laufzeitumgebung ist gemäß einer Weiterentwicklung insbesondere eine AUTOSAR-Laufzeitumgebung. Für eine solche AUTOSAR-Laufzeitumgebung hat es sich als besonders vorteilhaft erwiesen, eine Übereinstimmung von Nutzungsklasse und Speichercharakteristik durch ein Datenverwaltungsmodul bereitzustellen. Das Datenverwaltungsmodul kann beispielsweise als ein Software-Modul oder Programmcode der Laufzeitumgebung implementiert werden.
Für Anwendungsfälle oder Anwendungssituationen, die sich bei dem Verfahren ergeben können und die hier nicht explizit beschrieben sind, kann vorgesehen sein, dass gemäß dem Verfahren eine Fehlermeldung und/oder eine Aufforderung zur Eingabe einer Nutzerrückmeldung ausgegeben und/oder eine Standardeinstellung und/oder ein vorbestimmter Initialzustand eingestellt wird.
Die Erfindung sieht als weitere Lösung ein Steuergerät für ein Kraftfahrzeug vor, das eine Prozessorschaltung aufweist, die dazu eingerichtet ist, eine Ausführungsform des erfindungsgemäßen Verfahrens durchzuführen. Das Steuergerät kann eine Datenverarbeitungsvorrichtung oder eine Prozessorschaltung aufweisen, die dazu eingerichtet ist, eine Ausführungsform des erfindungsgemäßen Verfahrens durchzuführen. Die Prozessorschaltung kann hierzu zumindest einen Mikroprozessor und/oder zumindest einen Mikrocontroller und/oder zumindest einen FPGA (Field Programmable Gate Array) und/oder zumindest einen DSP (Digital Signal Processor) aufweisen. Des Weiteren kann die Prozessorschaltung Programmcode aufweisen, der dazu eingerichtet ist, bei Ausführen durch die Prozessorschaltung die Ausführungsform des erfindungsgemäßen Verfahrens durchzuführen. Der Programmcode kann in einem Datenspeicher der Prozessorschaltung gespeichert sein. Die Prozessorschaltung kann z.B. einer sogenannten Hauptplatine (Motherboard) und/oder einem SoC (System on Chip) beruhen.
Die Erfindung umfasst als weitere Lösung ein Kraftfahrzeug, das eine Ausführungsform des erfindungsgemäßen Steuergeräts aufweist. Das erfindungsgemäße Kraftfahrzeug ist bevorzugt als Kraftwagen, insbesondere als Personenkraftwagen oder Lastkraftwagen, oder als Personenbus oder Motorrad ausgestaltet.
Als eine weitere Lösung umfasst die Erfindung auch ein computerlesbares Speichermedium, umfassend Programmcode, der bei der Ausführung durch eine Prozessorschaltung eines Computers oder eines Computerverbunds diese veranlasst, eine Ausführungsform des erfindungsgemäßen Verfahrens auszuführen. Das Speichermedium kann z.B. zumindest teilweise als ein nichtflüchtiger Datenspeicher (z.B. als eine Flash-Speicher und/oder als SSD - solid state drive) und/oder zumindest teilweise als ein flüchtiger Datenspeicher (z.B. als ein RAM - random access memory) bereitgestellt sein. Das Speichermedium kann in der Prozessorschaltung in deren Datenspeicher angeordnet sein. Das Speichermedium kann aber auch beispielsweise als sogenannter Appstore-Server im Internet betrieben sein. Durch den Computer oder Computerverbund kann eine Prozessorschaltung mit zumindest einem Mikroprozessor bereitgestellt sein. Der Programmcode können als Binärcode oder Assembler und/oder als Quellcode einer Programmiersprache (z.B. C) und/oder als Programmskript (z.B. Python) bereitgestellt sein.
Die Erfindung umfasst auch die Kombinationen der Merkmale der beschriebenen Ausführungsformen. Die Erfindung umfasst also auch Realisierungen, die jeweils eine Kombination der Merkmale mehrerer der beschriebenen Ausführungsformen aufweisen, sofern die Ausführungsformen nicht als sich gegenseitig ausschließend beschrieben wurden.
Im Folgenden sind Ausführungsbeispiele der Erfindung beschrieben. Hierzu zeigt die einzige Figur:

Fig. eine schematische Darstellung einer Ausführungsform des erfindungsgemäßen Kraftfahrzeugs.

Bei den im Folgenden erläuterten Ausführungsbeispielen handelt es sich um bevorzugte Ausführungsformen der Erfindung. Bei den Ausführungsbeispielen stellen die beschriebenen Komponenten der Ausführungsformen jeweils einzelne, unabhängig voneinander zu betrachtende Merkmale der Erfindung dar, welche die Erfindung jeweils auch unabhängig voneinander weiterbilden. Daher soll die Offenbarung auch andere als die dargestellten Kombinationen der Merkmale der Ausführungsformen umfassen. Des Weiteren sind die beschriebenen Ausführungsformen auch durch weitere der bereits beschriebenen Merkmale der Erfindung ergänzbar.
In den Figuren bezeichnen gleiche Bezugszeichen jeweils funktionsgleiche Elemente.
Die Fig. zeigt ein Kraftfahrzeug 10, bei dem es sich um einen Kraftwagen, insbesondere einen Personenkraftwagen oder Lastkraftwagen, handeln kann. Des Weiteren ist dargestellt, wie in dem Internet 11 ein Backendserver 12 für das Kraftfahrzeug 10 und/oder ein Cloudspeicher 13 bereitgestellt sein können. In dem Kraftfahrzeug 10 kann ein Steuergerät 14 angeordnet sein, das mittels einer Prozessorschaltung 15 eine Laufzeitumgebung 16 betreiben kann, in welcher zumindest eine Applikationssoftware 17 ausgeführt werden kann. Das Steuergerät 14 kann beispielsweise ein Zentralcomputer oder ein Infotainment-Steuergerät des Kraftfahrzeugs sein. Die Prozessorschaltung 15 kann beispielsweise mittels eines so genannten Motherboards oder einer Schaltungsplatine mit zumindest einem Mikroprozessor und/oder Mikrocontroller realisiert sein. Die Laufzeitumgebung 16 kann beispielsweise als ein Betriebssystem oder eine AUTOSAR-Laufzeitumgebung betrieben werden. Die jeweilige Applikationssoftware 17 kann in dem Kraftfahrzeug 10 eine jeweilige Fahrzeugfunktionalität F1, F2 bereitstellen. Auslassungspunkte 18 sollen andeuten, dass mehr oder weniger als die zwei dargestellten Applikationssoftwares 17 in der im Folgenden beschriebenen Weise betrieben oder versorgt werden können. Beispielhafte Fahrzeugfunktionen F1, F2 können sein: Das Steuern zumindest eines Aktuators des Kraftfahrzeugs, beispielsweise eines Sitzmotors und/oder eines Antriebsmotors und/oder eines Fensterhebers und/oder einer Klimaanlage und/oder einer Medienwiedergabe und/oder eines Tempomats und/oder einer Fahrassistenzfunktion und/oder einer automatisierten Fahrfunktion, um nur Beispiele zu nennen.
Die Laufzeitumgebung kann mit dem Backendserver 12 und/oder dem Cloudspeicher 13 über eine Kommunikationsverbindung 19 gekoppelt sein, die beispielsweise auf Grundlage einer Funkverbindung 20 mittels eines Kommunikationsmodems 21 des Kraftfahrzeugs 10 und beispielsweise einem Mobilfunk-Netzwerk 22 und/oder einem WLAN-Router 23 implementiert sein kann. Als Funkverbindung 20 kann entsprechend eine Mobilfunkverbindung und/oder eine WLAN-Funkverbindung vorgesehen sein. Das Kommunikationsmodem 21 kann entsprechend ein Mobilfunkmodul und/oder ein WLAN-Funkmodul sein. Innerhalb des Internets 11 kann die Kopplung mittels einer jeweiligen Internetverbindung 24 implementiert oder realisiert sein.
Die Laufzeitumgebung kann zusätzlich mit zumindest einem Onboard-Datenspeicher 25 gekoppelt sein, der in der Prozessorschaltung 15 bereitgestellt sein kann. Es kann eine Kopplung mit zumindest einem Datenspeicher 26 eines anderen Steuergeräts 14' vorgesehen sein, wie sie beispielsweise über einen Daten-BUS und/oder ein Ethernet-Datennetzwerk zu dem anderen Steuergerät 14' realisiert sein kann. Die Kopplung an den Onboard-Datenspeicher 25 kann beispielsweise über einen PCI-Daten-BUS und/oder einen SATA-Daten-BUS erfolgen. Eine weitere Kopplung kann zu einem Datenspeicher 27 eines mobilen Endgeräts 28 vorgesehen sein, das über einen Datenanschluss 29 der Prozessorschaltung 15 mit dieser gekoppelt sein kann. Beispielsweise kann eine Kopplung K zwischen dem mobilen Endgerät 28 und dem Datenanschluss 29 über einen USB-Anschluss und/oder eine Bluetooth-Funkverbindung erfolgen.
Somit stehen in der Laufzeitumgebung 16 Kopplungen zu mehreren Datenspeichern D bereit. Durch die unterschiedlichen Technologien der Datenspeicher D und/oder der Kopplungen an diese Datenspeicher D hin zu der Laufzeitumgebung 16 ergibt sich für das Abspeichern und/oder Abrufen von Daten aus diesen Datenspeichern D eine jeweilige speicherspezifische Speicherspezifikation oder Speichercharakteristik 30, die in einem Datenverwaltungsmodul 31 der Laufzeitumgebung 16 beispielsweise durch entsprechende Konfigurationsdaten oder Spezifikationsdaten angegeben oder gespeichert sein kann.
Im Folgenden ist für den Betrieb der Applikationssoftware 17 jeweils nur auf eine einzelne Applikationssoftware 17 Bezug genommen, die Erläuterungen gelten auch für weitere andere Applikationssoftwares der Laufzeitumgebung 16.
Eine Applikationssoftware 17 kann für ihren Betrieb Daten 32 benötigen, die insofern dauerhaft oder nicht-volatil gespeichert werden müssen, als dass sie beispielsweise nach einem Neustart der Applikationssoftware 17 wieder zur Verfügung stehen müssen. Andere Daten 32 müssen beispielsweise lediglich dauerhaft gespeichert werden, damit sie beispielsweise von einem anderen, fahrzeugexternen Gerät, beispielsweise einem Diagnosegerät, gelesen werden können. Um Daten 32 der Applikationssoftware 17 in einem der Datenspeicher D abspeichern zu können, wird der Speichervorgang durch das Datenverwaltungsmodul 31 vermittelt. Hierzu kann die Applikationssoftware 17 eine Persistierungsanfrage 33 an eine Schnittstelle 34 (API) des Datenverwaltungsmoduls 31 senden, mittels welcher das Datenverwaltungsmodul 31 aufgefordert wird, Daten 32 der Applikationssoftware 17 zu speichern.
Durch das Datenverwaltungsmodul 31 kann zu einer in einem Schritt S10 empfangenen Persistierungsanfrage 33 in einem Schritt S11 eine Nutzungsklasse 35 der Daten 32 ermittelt werden. Die Nutzungsklasse 35 kann angeben, wie die Daten 32 beschaffen sind, beispielsweise ihr Datenvolumen und/oder ihre Strukturierung (beispielsweise eine große Datei oder eine Vielzahl kleinerer Dateien) und/oder wie eine erwartete zukünftige Nutzung der Daten 32 voraussichtlich aussehen wird. Als Bestandteil der Persistierungsanfrage 33 der Applikationssoftware 17 kann angegeben sein oder es kann anhand der Daten 32 selbst, beispielsweise anhand einer Typenangabe der Daten 32, eine Nutzungsklasse 35 mittels einer Klassifizierungsroutine Z ermittelt werden, die von einem Fachmann im Voraus auf Grundlage beispielsweise von Erfahrungswerten festgelegt werden kann.
Auf Grundlage der Nutzungsklasse 35 kann in einem Schritt S12 durch eine Zuordnungsroutine 36 anhand der Speichercharakteristiken 30 aus den Datenspeichern D ein geeigneter Datenspeicher D ausgewählt werden, der für die Nutzungsklasse 35 zum Speichern der Daten 32 geeignet ist, also die durch die Nutzungsklasse sich ergebenden Vorgaben, beispielsweise eine maximal zulässige Zugriffsdauer und/oder eine Anzahl von Schreibzyklen, mit denen die Applikationssoftware 17 zukünftig auf die Daten zu deren Anpassung zugreifen möchte, um nur Beispiele zu nennen. Weitere Beispiele werden im Weiteren noch erläutert. Durch die Zuordnungsroutine 36 kann ein ausgewählter Datenspeicher 37 signalisiert werden, der dann in einem Schritt S13 beispielsweise durch eine Abspeicherroutine 38 angesteuert wird, um die Daten 32 aus der Applikationssoftware 17 in dem ausgewählten Datenspeicher 37 abzuspeichern. Das Abspeichern kann erfolgen, indem über die jeweilige Kopplung zu dem Datenspeicher D die Daten 32 an den ausgewählten Datenspeicher 37 übertragen werden. Entspricht dann die weitere Nutzung der abgespeicherten Daten durch beispielsweise die Applikationssoftware 17 der ermittelten Nutzungsklasse 35, so wird also der ausgewählte Datenspeicher 37 den Nutzungsanforderungen der Applikationssoftware 17 gerecht und es wird vermieden, dass ein Betrieb der Applikationssoftware 17 beeinträchtigt wird, wie es beispielsweise ansonsten erfolgen kann, wenn beispielsweise eine Zugriffsdauer auf die abgespeicherten Daten bei dem ausgewählten Datenspeicher 37 größer wäre als es der Nutzungsanforderung gemäß der Nutzungsklasse 35 entsprechen würde.
Somit wird also für Daten 32 einer Applikationssoftware 17 ein für die Daten selbst (beispielsweise ihr Datenvolumen) und/oder die zukünftige Nutzung der Daten geeigneter Datenspeicher D automatisiert durch das Datenverwaltungsmodul 31 ausgewählt und die Daten 32 in diesem ausgewählten Datenspeicher 37 abgespeichert.
Zu speichernde Daten können sehr unterschiedliche Eigenschaften bzgl.

- Größe
- Speicherdauer
- Zugriffslatenz
- Anzahl benötigter Zugriffe
- Verfügbarkeit (bei manchen Daten ist ein Verlust kritisch, bei anderen weniger kritisch)

Daher ist es evtl. notwendig, dauerhaft benötigte Daten in einem geeigneten Datenspeicher zu speichern.
Eine Lösung ergibt sich dadurch, dass die persistente Daten in der API gelabelt (API Parameter) oder in einer Konfigurationsdatei beschrieben werden. Z.B. kann bei einem Key-Value Store pro Key die Persistenzklasse hinterlegt werden. Der Persistency Manager (Datenverwaltungsmodul) kümmert sich darum, dass die Daten an die richtige Stelle (d.h. einen geeigneten Datenspeicher) geschrieben werden.
Mögliche Speicherorte für Embedded Anwendungen wären:

• Reset-festes RAM (klein, aber schneller Zugriff, keine dauerhafte Persistenz)
• Flash
• Flash auf anderem Steuergerät
• externe SD-Karte/SSD
• Cloud

Es soll auch vorgesehen werden, dass der Persistency Manager Daten auslagern kann, wenn z.B. das reset-festes RAM voll ist, werden die Daten in den Flash geschrieben. Wenn Daten länger nicht mehr verwendet wurden, könnten Sie nachträglich in die Cloud (fahrzeugexterner Datenspeicher) ausgelagert werden. Oder die Daten sind von Anfang bereits so gelabelt, dass sie in die Cloud ausgelagert werden sollen.
Zusätzlich zu dem Label (Angabe der Nutzungsklasse) kann auch eine Priorisierung unterstützt werden, z.B. gewisse Daten haben höhere Priorität. An Hand dieser Priorität kann der Persistenzmanager (Datenverwaltungsmodul) dann über eine Auslagerung entscheiden.
Insgesamt zeigen die Beispiele, wie eine Persistenzklassifikation von abzuspeichernden Daten bereitgestellt werden kann.
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 Patentliteratur

DE 102020121645 A1 [0004]
DE 102017223856 A1 [0006]

Claims

Verfahren zum Betreiben einer Prozessorschaltung (15) eines Steuergeräts (14) eines Kraftfahrzeugs (10), wobei in einer Laufzeitumgebung (16) der Prozessorschaltung (15) zumindest eine Applikationssoftware (17) ausführt und durch ein Datenverwaltungsmodul (31) der Laufzeitumgebung (16) aus der jeweiligen Applikationssoftware (17) eine jeweilige Persistierungsanfrage (33) empfangen wird, mittels welcher abzuspeichernde Daten (32) der Applikationssoftware (17) an das Datenverwaltungsmodul (31) übergegeben werden, dadurch gekennzeichnet, dass eine jeweilige Kopplung zu mehreren Datenspeichern (37) bereitgestellt wird, wobei jeder der Datenspeicher (37) eine speicherspezifische Speichercharakteristik (30) aufweist, und zu der jeweiligen Persistierungsanfrage (33) eine Nutzungsklasse (35) betreffend das Abspeichern der Daten (32) und/oder betreffend eine nach dem Abspeichern zu erwartende, zukünftige Nutzung der Daten (32) ermittelt wird und durch das Datenverwaltungsmodul (31) anhand der ermittelten Nutzungsklasse (35) einer der Datenspeicher (37) ausgewählt wird, wobei die Zuordnungsroutine (36) überprüft, ob durch die speicherspezifische Speichercharakteristik (30) einer jeweiligen Nutzungsanforderung der Nutzungsklasse (35) entsprochen wird, und die abzuspeichernden Daten (32) in dem ausgewählten Datenspeicher (37) abgespeichert werden.
Verfahren nach Anspruch 1, wobei die Speichercharakteristik (30) zumindest eines der folgenden Speicherattribute umfasst: • eine für die Kopplung verwendete Verbindungsart und/oder ein Speicherort, • eine Mindestzugriffsdauer und/oder eine Höchstzugriffsdauer, • eine Speicherkapazität und/oder eine aktuelle und/oder geplante Speicherbelegung, • ein Zyklenbelastbarkeit für Schreibzyklen und/oder Lesezyklen.
Verfahren nach einem der vorhergehenden Ansprüche, wobei nach dem Abspeichern der Daten (32) in den ausgewählten Datenspeicher (37) durch das Datenverwaltungsmodul (31) eine tatsächliche weitere Nutzung der abgespeicherten Daten (32) überwacht wird und für den Fall, dass die tatsächliche Nutzung von der durch die ermittelte Nutzungsklasse (35) signalisierten erwarteten Nutzung abweicht, durch die Zuordnungsroutine (36) ein anderer der Datenspeicher (37), dessen Speichercharakteristik (30) der ermittelten tatsächlichen Nutzung entspricht, neu ausgewählt und die Daten (32) in den neu ausgewählten Datenspeicher (37) umgelagert werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei durch die Zuordnungsroutine (36) zusätzlich ein aktueller und/oder eine bereits festgelegter zukünftiger Auslastungszustand eines anhand der Nutzungsklasse (35) aus den Datenspeichern (37) vorläufig ausgewählten Datenspeichers (37) ermittelt wird und falls der Auslastungszustand ein in dem Datenverwaltungsmodul (31) vorgegebenes Ausschlusskriterium erfüllt, ein anderer der Datenspeicher (37) anhand der Nutzungsklasse (35) ausgewählt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei als mögliche Nutzungsklassen (35) zumindest eine der folgenden vorgesehen ist: • Zugriff auf die gespeicherten Daten (32) muss jederzeit erfolgen, • Zugriff nur bei nächstem oder jedem Neustart der Softwareappli kation, • Zugriff innerhalb einer vorgegebenen Höchstzugriffszeitdauer, • Zugriff innerhalb einer Höchstwartedauer für den Erstzugriff auf, • Zugriff mit einer vorgegebenen Mindestdatenrate, • Zugriff nur durch fahrzeugfremdes Gerät, • eine Aktualisierungshäufigkeit und/oder eine Aktualisierungsrate, • ein Datenvolumen der Daten (32), • ein Kostenwert bei Datenverlust.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die mehreren Datenspeicher (37) zumindest einen der folgenden umfassen: • einen reset-festen RAM der Prozessorschaltung (15), • einen Flash-Speicher der Prozessorschaltung (15), • einen über ein Datennetzwerk angebundenen Flash in anderem Steuergerät (14) des Kraftfahrzeugs (10), • eine von einem Benutzer manuell entnehmbare externe SD-Karte und/oder SSD, • eine temporär angeschlossenes mobiles Endgerät (28) eines Benutzers • ein fahrzeugexterner Cloudspeicher und/oder ein Backend des Kraftfahrzeugs (10).
Verfahren nach einem der vorhergehenden Ansprüche, wobei bei beim Abspeichern von Daten (32) aus mehreren zeitlich überlappenden Persistierungsanfragen (33) mehrerer Applikationssoftwares (17) durch das Datenverwaltungsmodul (31) eine Priorisierung bei einem Konflikt betreffen eines der Datenspeicher (37) anhand von Priorisierungsdaten (32) des Datenverwaltungsmoduls (31) durchgeführt wird und für die Daten (32) der niederprioren Applikationssoftware (17) ein alternativer Datenspeicher (37) ausgewählt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Nutzungsklasse (35) an einer API des Datenmoduls als Teil der Persistierungsanfrage (33) übergeben wird oder wobei das Datenverwaltungsmodul (31) unabhängig von der Persistierungsanfrage (33) in Konfigurationsdaten (32) eine Zuordnung von unterschiedlichen möglichen Datentypen zu einer jeweiligen Angabe einer Nutzungsklasse (35) gespeichert hält und das Datenverwaltungsmodul (31) eine tatsächlichen Datentyp der abzuspeichernden Daten (32) ermittelt und mittels der Konfigurationsdaten (32) die Nutzungsklasse (35) ermittelt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei alle Persistierungsanfragen (33) zumindest einer oder jeder Applikationssoftware (17) über dieselbe Schnittstelle (34) des Datenverwaltungsmodul (31) empfangen werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei als die Laufzeitumgebung (16) eine AUTOSAR-Laufzeitumgebung (16) betrieben wird.
Steuergerät (14) für ein Kraftfahrzeug (10), wobei das Steuergerät (14) eine Prozessorschaltung (15) aufweist, die dazu eingerichtet ist, ein Verfahren nach einem der vorhergehenden Ansprüche durchzuführen.
Kraftfahrzeug (10) mit einem Steuergerät (14) nach Anspruch 11.