DE102021129094A1

DE102021129094A1 - Verfahren zum Ermitteln von Ersatzteilbedarf

Info

Publication number: DE102021129094A1
Application number: DE102021129094.5A
Authority: DE
Inventors: Mohamed Kari; David Bethge
Original assignee: Dr Ing HCF Porsche AG
Current assignee: Dr Ing HCF Porsche AG
Priority date: 2021-11-09
Filing date: 2021-11-09
Publication date: 2023-05-11

Abstract

Die Erfindung betrifft ein Verfahren zum Ermitteln von Ersatzteilbedarf (1), aufweisend die folgenden Schritte, welche auf einer Computereinrichtung (2) ausgeführt werden:a. Erfassen einer Beanspruchungshistorie (3) auf Basis von einer zeitlichen Reihe von Betriebsparametern (4) über zumindest eine Funktionseinheit (5,6,7) von einer Vielzahl von Kraftfahrzeugen (8);b. auf Grundlage der in Schritt a. erfassten Beanspruchungshistorie (3), Extrapolieren einer zukünftigen Beanspruchungshistorie (9) von der zumindest einen Funktionseinheit (5,6,7);c. für einen vorbestimmten zukünftigen Zeitpunkt, Berechnen eines Restfunktionalitätsgrads für die zumindest eine Funktionseinheit (5,6,7) auf Basis eines vorbestimmten Degradationsmodells (10) und der in Schritt c. extrapolierten Beanspruchungshistorie (9); undd. wenn der berechnete Restfunktionalitätsgrad einen vorbestimmten Ersetzgrenzwert erreicht oder überschreitet, Ausgeben eines Ersatzteilbedarfs (1) für die zumindest eine Funktionseinheit (5,6,7).Mit dem hier vorgeschlagenen Verfahren ist eine bedarfsgerechte Ersatzeilplanung ermöglicht, wobei zugleich Ressourcen eingespart sind.

Description

Die Erfindung betrifft ein Verfahren zum Ermitteln von Ersatzteilbedarf, eine Computereinrichtung zum Ausführen eines solchen Verfahrens, ein Kraftfahrzeug zur Kommunikation mit einer solchen Computereinrichtung, ein Computerprogramm sowie ein Computerprogrammprodukt zum Ausführen eines solchen Verfahrens.
Predictive Maintenance (deutsch: vorausschauende Instandhaltung) ist ein bekanntes Verfahren, um für in Betrieb befindliche Geräte (beispielsweise industrielle Anlagen, Aufzüge und Kraftfahrzeuge) mittels der Auswertung von beispielsweise deren Prozessdaten, Maschinendaten und/oder Betriebsparametern Prognosen zu ermöglichen, welche die Grundlage für eine bedarfsgerechte Wartung und folglich die Reduktion von Ausfallzeiten bilden. Dazu wird der Zustand von den in Betrieb befindlichen Geräten oder von einer oder mehreren einzelnen Komponenten dieses Gerätes bestimmt, um vorauszusagen, wann eine Wartung durchgeführt werden sollte. Aus dem Stand der Technik ist bekannt, dass dazu das betreffende Gerät beziehungsweise die einzelne Komponente dieses Geräts als IoT-Gerät [englisch: Internet of Things] eingerichtet ist, um die Prozessdaten, Maschinendaten und/oder Betriebsparameter über Netzwerke (beispielsweise eine Cloud) an beispielsweise Servicestellen und/oder an den Hersteller selbst zu übermitteln. Allerdings ist die Einrichtung, Auswertung und die Analyse im Rahmen des Predictive Maintenance mit enormem Aufwand und einzig mit qualifiziertem Personal durchführbar.
Mit der zunehmenden Elektrifizierung von Kraftfahrzeugen weisen diese auch einen hohen Anteil an überwachten Komponenten auf, welche eine endliche Lebensdauer besitzen. Beispielsweise ist eine solche Komponente eine Hochvoltbatterie, eine elektrische Antriebsmaschine, eine Wärmepumpe oder aber auch ein Wälzlager oder ein Reifen eines Kraftfahrzeugs. Dabei weisen Kraftfahrzeuge ganz unterschiedliche Nutzungsprofile auf, welche abhängig sind von beispielsweise dem Fahrverhalten, dem Ladeverhalten, dem Einsatzort und/oder dem Einsatzzweck. Die Lebensdauer einer solchen Komponente ist von dem Nutzungsprofil maßgeblich beeinflusst. Um beispielsweise zukünftige Rohstoffengpässe, Produktionsverfügbarkeiten und Lieferengpässe aufseiten des OEM [engl.: Original Equipment Manufacturer; gemeint ist ein kundenbekannter Fahrzeughersteller] abfangen zu können, ist zunehmend (teilweise abweichend von einer JIT [engl.: Just In Time] Logistik) gefordert, dass Servicestellen, OEM und/oder Zulieferer den Ersatzteilbedarf vorausschauend planen. Somit lassen sich frühzeitig Austauschkomponenten fertigen beziehungsweise bestellen.
Hiervon ausgehend liegt der vorliegenden Erfindung die Aufgabe zugrunde, die aus dem Stand der Technik bekannten Nachteile zumindest teilweise zu überwinden. Die erfindungsgemäßen Merkmale ergeben sich aus den unabhängigen Ansprüchen, zu denen vorteilhafte Ausgestaltungen in den abhängigen Ansprüchen aufgezeigt werden. Die Merkmale der Ansprüche können in jeglicher technisch sinnvollen Art und Weise kombiniert werden, wobei hierzu auch die Erläuterungen aus der nachfolgenden Beschreibung sowie Merkmale aus den Figuren hinzugezogen werden können, welche ergänzende Ausgestaltungen der Erfindung umfassen.
Die Erfindung betrifft ein Verfahren zum Ermitteln von Ersatzteilbedarf, aufweisend die folgenden Schritte, welche auf einer Computereinrichtung ausgeführt werden:

a. Erfassen einer Beanspruchungshistorie auf Basis von einer zeitlichen Reihe von Betriebsparametern über zumindest eine Funktionseinheit von einer Vielzahl von Kraftfahrzeugen;
b. auf Grundlage der in Schritt a. erfassten Beanspruchungshistorie, Extrapolieren einer zukünftigen Beanspruchungshistorie von der zumindest einen Funktionseinheit;
c. für einen vorbestimmten zukünftigen Zeitpunkt, Berechnen eines Restfunktionalitätsgrads für die zumindest eine Funktionseinheit auf Basis eines vorbestimmten Degradationsmodells und der in Schritt c. extrapolierten Beanspruchungshistorie; und
d. wenn der berechnete Restfunktionalitätsgrad einen vorbestimmten Ersetzgrenzwert erreicht oder überschreitet, Ausgeben eines Ersatzteilbedarfs für die zumindest eine Funktionseinheit.

In der vorhergehenden und nachfolgenden Beschreibung verwendete Ordinalzahlen dienen, sofern nicht explizit auf das Gegenteilige hingewiesen wird, lediglich der eindeutigen Unterscheidbarkeit und geben keine Reihenfolge oder Rangfolge der bezeichneten Komponenten wieder. Eine Ordinalzahl größer eins bedingt nicht, dass zwangsläufig eine weitere derartige Komponente vorhanden sein muss.
Das hier vorgeschlagene Verfahren ist dazu geeignet, den Ersatzteilbedarf für eine Fahrzeugflotte zu einem vorbestimmten Zeitpunkt zu bestimmen. Eine Fahrzeugflotte umfasst eine Vielzahl von Kraftfahrzeugen, wobei diese Kraftfahrzeuge nach gleichen Funktionseinheiten und/oder nach (geschätztem) ähnlichem Nutzungsprofil zu dieser Fahrzeugflotte zusammengefasst sind. Die Vielzahl von Kraftfahrzeugen umfasst in einer Ausführungsform beispielsweise alle Kraftfahrzeuge eines Modells, bevorzugt aufweisend die gleichen Funktionseinheiten. In einer anderen Ausführungsform umfasst die Vielzahl von Kraftfahrzeugen unterschiedliche Modelle, jedoch bevorzugt mit zumindest einer gleichen (mittels dieses Verfahrens überwachten) Funktionseinheit unter gleichen Nutzungsbedingungen über die Vielzahl der Kraftfahrzeuge hinweg. Gegebenenfalls sind individuelle Kraftfahrzeuge einer Mehrzahl von Fahrzeugflotten zugeordnet. In einem Aspekt der Erfindung ist für zumindest eine Funktionseinheit eines bestimmten Kraftfahrzeugs für einen vorbestimmten zukünftigen Zeitpunkt der Ersatzteilbedarf ermittelt. In einem anderen Aspekt der Erfindung ist die Vielzahl der Kraftfahrzeuge lediglich eine Stichprobe aus einer Fahrzeugflotte, wobei auf den gesamten Ersatzteilbedarf für die betreffende Fahrzeugflotte (mit der Gesamtheit der davon umfassten Kraftfahrzeuge) der Ersatzteilbedarf ermittelt wird.
Dazu ist das Verfahren auf einer Computereinrichtung ausführbar. Beispielsweise umfasst eine solche Computereinrichtung ein Rechenzentrum (bevorzugt beim OEM), eine Cloud, ein EdgeDevice (bevorzugt am Fertigungsstandort) und/oder ein (Fahrzeug-) Backend. Verschiedene Schritte und vor allem hier nicht explizit genannte Unterschritte werden in einer Ausführungsform auf unterschiedlichen Entitäten einer solchen Computereinrichtung ausgeführt. Dabei ist der Ansatz Ressourcen zu schonen, eine geforderte Datensicherheit bereitzuhalten und/oder erforderliche teure Rechenkapazitäten effizient auszulasten. Die Computereinrichtung umfasst zumindest eine geeignete Kommunikationsschnittstelle, beispielsweise eine drahtlose Netzwerkschnittstelle (beispielsweise über Satellitenkommunikation, Mobilfunk, WLAN [engl.: Wireless Local Area Network], PAN [engl.: Personal Area Network] und/oder RFID [engl.: Radio-Frequency IDentification]) und/oder eine drahtgebundene Netzwerkschnittstelle (beispielsweise über ein Ladekabel einer Hochvoltbatterie oder eine Wartungsschnittstelle zum Auslesen von Fahrzeugdaten) auf.
Zunächst wird in Schritt a. eine Beanspruchungshistorie auf Basis von einer zeitlichen Reihe von Betriebsparametern über zumindest eine Funktionseinheit von einer Vielzahl von Kraftfahrzeugen mittels der Computereinrichtung erfasst. In einer Ausführungsform wird die Beanspruchungshistorie auf einem und für dieses (individuelle) Kraftfahrzeug ermittelt. In einer bevorzugten Ausführungsform ist die Beanspruchungshistorie also bereits extern (gegebenenfalls über einen längeren Zeitraum) erstellt worden und lediglich von der Computereinrichtung erfasst. In einer Ausführungsform bildet das Kraftfahrzeug beziehungsweise dessen zumindest einer ausführender Computer (beispielsweise der Bordcomputer) einen Teil der Computereinrichtung, wobei bevorzugt weitere Verfahrensschritte auf dem zumindest einen in dem Kraftfahrzeug befindlichen Computer ausgeführt werden. Alternativ übermittelt das Kraftfahrzeug lediglich eine zeitliche Reihe von Betriebsparametern über zumindest eine Funktionseinheit, welche von einem externen Computerin eine Beanspruchungshistorie übersetzt und der Computereinrichtung (beispielsweise auf Anfrage) in Schritt a. zur Verfügung gestellt werden. Die Beanspruchungshistorie der zumindest einen Funktionseinheit geht auf das eingangs beschriebene Nutzungsprofil zurück. Es ist spezifiziert auf die jeweilige Funktionseinheit. In einer vorteilhaften Ausführungsform ist bereits die Folge der Beanspruchung (also die Degradation) für die jeweilige Funktionseinheit in der Beanspruchungshistorie enthalten.
In einer Ausführungsform beginnt das Messen der zeitlichen Reihe beispielsweise mit dem vom Band Rollen des Kraftfahrzeugs in einer Produktionsstätte. Das Ende der zeitlichen Reihe entspricht dann beispielsweise dem Zeitpunkt des Erfassens in Schritt a. der Beanspruchungshistorie. Die Beanspruchungshistorie umfasst am Beispiel der Funktionseinheit einer Hochvoltbatterie zumindest Daten von einer Reihe von Betriebsparametern, welche beispielsweise Stromentnahmen in Bezug auf die Stromstärken, Einsatztemperaturen, Ladeverhalten, Einsatzzeiten und/oder Weiteres umfassen.
In einer anderen Ausführungsform werden parallel eine Vielzahl von Beanspruchungshistorien erfasst, welche jeweils unterschiedliche (Arten von) Funktionseinheiten betreffen. In einer bevorzugten Ausführungsform werden zu dem Zeitpunkt des Erfassens alle verfügbaren Beanspruchungshistorien von einer Vielzahl verschiedener Funktionseinheiten erfasst. Alternativ oder zusätzlich wird von einer Beanspruchungshistorie beziehungsweise von einem Nutzungsprofil auf eine Degradation einer weiteren (gegebenenfalls nicht oder unzureichend überwachten) Funktionseinheit geschlossen.
In einem nachfolgenden Schritt b. wird auf Grundlage der in Schritt a. erfassten Beanspruchungshistorie eine zukünftige Beanspruchungshistorie von der zumindest einen Funktionseinheit mittels der Computereinrichtung extrapoliert. Beispielsweise ist die zukünftige Beanspruchungshistorie bis zu einem Zeitpunkt extrapoliert, welcher einem Beschaffungszeitpunkt in einem Beschaffungsintervall, einem Wartungszeitpunkt in einem Wartungsintervall, einem Ende eines Garantieanspruchs, einem Ende einer definierten Nutzungsdauer und/oder einem anderen festgelegten Zeitpunkt entspricht.
Beim Extrapolieren auf Basis der jeweiligen erfassten Beanspruchungshistorie wird auf historische oder modellbasierte Daten zurückgegriffen. Es wird eine zukünftige Beanspruchungshistorie mittels einer (im weitesten Sinne) mathematischen Funktion ermittelt, wobei diese stochastisch und/oder deterministisch formuliert ist.
In Schritt c. ist nun vorgeschlagen, dass mittels der Computereinrichtung für zumindest einen vorbestimmten zukünftigen Zeitpunkt ein Restfunktionalitätsgrad für die zumindest eine Funktionseinheit auf Basis eines vorbestimmten Degradationsmodells und der in Schritt b. extrapolierten Beanspruchungshistorie berechnet wird. Beispielsweise ist der vorbestimmte zukünftige Zeitpunkt ein festgelegter Servicetermin, das Ende eines Garantieanspruchs, ein Zeitpunkt des Wiederverkaufs des Kraftfahrzeugs, und/oder ein Stichtag für eine Teilebeschaffung. Der Restfunktionalitätsgrad ist am Beispiel der Hochvoltbatterie als überwachte Funktionseinheit beispielsweise der SoH [engl.: State of Health] oder am Beispiel eines Reifens als überwachte Funktionseinheit die Reifenprofilhöhe. Der Restfunktionalitätsgrad ist somit in Abhängigkeit der untersuchten Komponente definiert und beschreibt den zu erwartenden Zustand der zumindest einen Funktionseinheit. Er ist kombiniert mit einem vorbestimmten (meist gesetzlich vorgegebenen) Grenzwert.
Das Degradationsmodell stellt die Basis für die Prognoserechnung dar, wobei hier in vier verschiedene Ansätze, nämlich ein erfahrungsbasierter Ansatz, modellbasierter Ansatz, wissensbasierter Ansatz und datenbasierter Ansatz unterschieden wird. Üblicherweise sind auch verschiedene Ansätze für eine verbesserte Prognoserechnung kombinierbar. In einer bevorzugten Ausführungsform ist für jede Funktionseinheit ein separates Degradationsmodell eingesetzt. Beispielsweise ist das Degradationsmodell für die zumindest eine Funktionseinheit händisch programmierbar. In einer bevorzugten Ausführungsform ist das Degradationsmodell alternativ oder zusätzlich mittels maschinellen Lernens (ohne oder mit geringem Vorwissen) fortlaufend trainiert.
In einer Ausführungsform wird für jede (überwachte) Funktionseinheit ein Restfunktionalitätsgrad berechnet.
In einen abschließenden Schritt d. wird nun ein Ersatzteilbedarf mittels der Computereinrichtung (beispielsweise als Ausdruck und/oder auf einem Bildschirm beziehungsweise in einer Datenbank, bevorzugt eines ERP [engl.: Enterprise Resouce Planning] Systems, hinterlegt) ausgegeben, wenn der berechnete Restfunktionalitätsgrad aus Schritt c. einen vorbestimmten Ersetzgrenzwert erreicht oder überschreitet. Hier wird also der zu einem vorbestimmten Zeitpunkt berechnete Restfunktionalitätsgrad mit einem Ersetzgrenzwert verglichen. Beispielsweise ist der Ersetzgrenzwert eine vom Hersteller vordefinierte Verschleißgrenze, eine vordefinierte Lebensdauer und/oder bei einer Batterie ein vordefinierter Ladekapazitätsgrenzwert. Es sei darauf hingewiesen, dass der Ersetzgrenzwert nicht zwangsläufig ein starrer Wert ist, sondern gegebenenfalls abängig von einem (sich bevorzugt laufend) ändernden Degradationsmodell und/oder einer in einer Gesamtabnutzung abnehmenden (kundenseitigen) Funktionalitätserwartung verzögernder Ersetzgrenzwert ist. In einer bevorzugten Ausführungsform werden für alle überwachten Funktionseinheiten der jeweilige Restfunktionalitätsgrad mit einem vorbestimmten Ersetzgrenzwert verglichen und bei Erreichen oder überschreiten ein Ersatzteilbedarf ausgegeben. Es sei darauf hingewiesen, dass hierbei zudem ein Abstand zu einem nächsten vorbestimmten Zeitpunkt mitberücksichtigt wird, also wenn der extrapolierte Restfunktionalitätsgrad zwar bis zum vorbestimmten Zeitpunkt ausreicht, aber nicht bis zu dem nächsten, wird von einem Ersatzteilbedarf ausgegangen. Weiterhin sind (gegebenenfalls zusätzliche) Sicherheitsbeiwerte und/oder stochastische Abweichungen bei dem Ermitteln des Ersatzteilbedarfs berücksichtigt.
Der Ersatzteilbedarf umfasst beispielsweise eine Typenbezeichnung der zu ersetzenden Funktionseinheit, eine zu ersetzende Menge der Funktionseinheit und/oder eine Zuordnung zu dem (individuellen) Kraftfahrzeug der (individuellen überwachten) zu ersetzenden Funktionseinheit.
In einer bevorzugten Ausführungsform werden die Schritte a. bis Schritt d. über die gesamte Nutzungsdauer der zumindest einen Funktionseinheit mehrfach wiederholt, beispielsweise in regelmäßigen zeitlichen Intervallen, ausgeführt.
Es wird weiterhin in einer vorteilhaften Ausführungsform des Verfahrens vorgeschlagen, dass das Verfahren weiterhin zumindest den folgenden Schritt umfasst:

f. Erfassen eines Funktionalitätsgrads von der zumindest einen Funktionseinheit, zu welcher in Schritt a. die Beanspruchungshistorie erfasst worden ist,

In dem hier vorgeschlagenen Schritt f. wird mittels der Computereinrichtung ein Funktionalitätsgrad von jener zumindest einen Funktionseinheit, zu welcher in Schritt a. die Beanspruchungshistorie erfasst wird beziehungsweise worden ist, erfasst. Der Funktionalitätsgrad gibt zum Zeitpunkt des Erfassens einen Wert über den Verschleißzustand der betreffenden Funktionseinheit wieder. Am Beispiel einer Hochvoltbatterie als eine überwachte Funktionseinheit ist es also der aktuelle SoH (vergleiche oben) oder am Beispiel eines Reifen als Funktionseinheit die aktuelle Profilhöhe. Der Funktionalitätsgrad und der in Schritt c. zu berechnende Restfunktionalitätsgrad sind bis auf den Zeitpunkt, auf welchen sie sich beziehen, gleich. Der Funktionalitätsgrad ist der tatsächliche (aktuelle) Wert, soweit dies mittels eines entsprechenden Sensors bestimmbar ist. Der Restfunktionalitätsgrad ist ein extrapolierter Funktionalitätsgrad und zwar auf denjenigen Zeitpunkt, an welchem der Verschleiß der überwachten Funktionseinheit so weit fortgeschritten ist, dass ein Austauschen (also Ersatz durch ein Ersatzteil) angezeigt ist. Es ergibt sich also aus dem Restfunktionalitätsgrad vielmehr die Aussage, ob ein Austauschen bis zu dem betrachteten Zeitpunkt notwendig ist oder eben nicht. Der erfasste Funktionalitätsgrad hingegen ist ein Korrekturwert, falls bereits ein Restfunktionalitätsgrad für die betreffende Funktionseinheit bestimmt worden ist.
In einer bevorzugten Ausführungsform wird für jede Funktionseinheit, zu welcher in Schritt a. die Beanspruchungshistorie erfasst worden ist, ein Funktionalitätsgrad erfasst. Beispielsweise wird dazu der jeweilige Funktionalitätsgrad mit der jeweiligen Beanspruchungshistorie verknüpft.
In einer vorteilhaften Ausführungsform ist vorgeschlagen, dass das Degradationsmodell für Schritt d. fortlaufend aus den in Schritt a. und Schritt f. erfassten Beanspruchungshistorien und Funktionalitätsgrade mittels maschinellen Lernens von einer Computereinrichtung angepasst wird.
Maschinelles Lernen (oder MachineLearning) beruht auf Algorithmen, welche ein statistisches Modell (hier das Degradationsmodell) aufbauen beziehungsweise ein vorgegebenes Modell laufend verbessern. Das Basismodell ist oftmals mittels Trainingsdaten erzeugt, also mit Daten, von denen der Eingangswert und der zugehörige Ausgangswert bekannt ist. Das Ziel ist dabei Muster und Gesetzmäßigkeiten in den Trainingsdaten zu erkennen und darauf aufbauend für unbekannte Eingangsdaten Ausgangsdaten bestimmen zu können. Diese Muster und Gesetzmäßigkeiten sind auch als Assoziationen bezeichnet. Die Eingangsdaten sind hier die Beanspruchungshistorie der überwachten Funktionseinheit. Ausgangsdaten sind der Restfunktionalitätsgrad beziehungsweise die (ausgangsseitigen) Trainingsdaten sind der (tatsächliche) Funktionalitätsgrad. Daraus ergibt sich ein Degradationsmodell, wobei dieses nicht nur annähernd und unter großem Aufwand bekannt ist. Es kommt hierbei nicht zu einem klassischen Modell, bei welchem unter vereinfachenden Annahmen eine Annäherung an eine möglichst exakte Funktion erreicht wird. Im Gegenteil bleibt der Algorithmus komplex und nicht menschlich erfassbar. Ziel ist es aus einer erfassten (unbekannten und/oder komplexen) Beanspruchungshistorie einen möglichst exakten Restfunktionalitätsgrad vorherzusagen. Je mehr Eingangsdaten und Ausgangsdaten dem Algorithmus zu Verfügung gestellt werden, desto präziser ist eine Vorhersage des Restfunktionalitätsgrads. Das Degradationsmodell wird also fortlaufend mittels maschinellen Lernens von der Computereinrichtung angepasst, und zwar auf Basis des Vergleichs des (tatsächlichen) Funktionalitätsgrads und des zuvor ermittelten Restfunktionalitätsgrads.
Es sei darauf hingewiesen, dass in diesem Zusammenhang dann von dem Restfunktionalitätsgrad nicht die Information betreffend die Notwendigkeit eine Funktionseinheit zu einem vorbestimmten Zeitpunkt auszutauschen relevant ist, sondern der (modellierte oder theoretische) Verschleißzustand der Funktionseinheit zu dem Zeitpunkt, zu welchem dann der Funktionalitätsgrad erfasst wird. Es sei darauf hingewiesen, dass es auch weniger darauf ankommt, ob ein Degradationsmodell in einer Nutzungsumgebung mit exakt bestimmten Parametern hinsichtlich Beanspruchung und Zeit stimmig ist. Vielmehr wird in einer Ausführungsform von einem ausreichend exakten Degradationsmodell als Basismodell ausgegangen. Die aufgrund ihrer Komplexität nicht beherrschbare Komponente ist vielmehr die tatsächliche Nutzungsumgebung. Wenn beispielsweise ein Kraftfahrzeug in einem überwachten Zeitraum (erfasste Beanspruchungshistorie) überdurchschnittlich intensiv genutzt wird, könnte ein exaktes Degradationsmodell zu dem Schluss kommen, dass entsprechend früher ein Ersatzteil benötigt ist. Mittels maschinellem Lernen könnte aber festgestellt werden, dass eine solche überdurchschnittlich intensive Beanspruchung sich oftmals nicht linear extrapoliert, sondern (um ein nachvollziehbares Beispiel zu nennen) auf eine Anfangseuphorie und/oder eine Nutzung des Kraftfahrzeugs auf einer Rennstrecke zurückgeht und daher sich an dieses überdurchschnittlich intensive Nutzungsverhalten eine weniger intensive Nutzung anschließt. Es werden also schwer zu fassende menschliche Verhaltensweisen berücksichtigt. Nicht ausgeschlossen ist dabei, dass ein Degradationsmodell auch auf der physikalischen Ebene de facto präzisiert wird. Die genauen Ursachen und Zusammenhänge für eine Verbesserung des Degradationsmodells mittels maschinellem Lernens sind aber auch hier nur sehr aufwendig und unzureichend mittels zusätzlicher Programme entzifferbar.
Es wird weiterhin in einer vorteilhaften Ausführungsform des Verfahrens vorgeschlagen, dass das Verfahren weiterhin zumindest die folgenden Schritte umfasst:

a1. Erfassen von Werkstattdaten über die zumindest eine Funktionseinheit, zu welcher in Schritt a. die Beanspruchungshistorie erfasst worden ist, und
a2. Integration der Werkstattdaten in die Beanspruchungshistorie.

In Schritt a1. werden zusätzlich Werkstattdaten über die zumindest eine Funktionseinheit mittels der Computereinrichtung erfasst, zu welcher in Schritt a. die Beanspruchungshistorie erfasst wird beziehungsweise worden ist. Werkstattdaten umfassen beispielsweise Informationen zu einem Teiletausch von einer Funktionseinheit oder einer Untergruppe einer Funktionseinheit, zu durchgeführten (Software-) Updates (und damit einhergehend einer angepassten Funktionsweise einer Funktionseinheit), zu einer Reparatur, Revision und/oder zu einer Modifikation einer Funktionseinheit. In einem nachfolgenden Schritt a2. werden die zuvor erfassten Werkstattdaten in die Beanspruchungshistorie der jeweiligen Funktionseinheit mittels der Computereinrichtung integriert, beispielsweise ergänzt und in einer gemeinsamen Datei abgespeichert.
Mit diesen zusätzlichen Daten lassen sich einfacher präzise Ergebnisse erzielen, weil nun nicht mehr Funktionseinheiten mit gleicher oder ähnlicher Beanspruchungshistorie miteinander gleichgesetzt werden, von denen eine (Gruppe) bereits ausgetauscht ist und die andere (Gruppe) noch beispielsweise als Originalteile betrieben werden.
Es wird weiterhin in einer vorteilhaften Ausführungsform des Verfahrens vorgeschlagen, dass auf Basis des in Schritt c. berechneten Restfunktionalitätsgrads anhand einer vorbestimmten Ausfallwahrscheinlichkeit in Schritt d1. Berechnen und Ausgeben eines vorzeitigen Ersatzteilbedarfs.
Hier ist nun vorgeschlagen, dass mittels der Computereinrichtung in einem Schritt d1. auf Basis des in Schritt c. berechneten Restfunktionalitätsgrads anhand einer vorbestimmten Ausfallwahrscheinlichkeit ein vorzeitiger Ersatzteilbedarf berechnet und ausgegeben wird. Die Ausfallwahrscheinlichkeit basiert auf Frühausfällen, Zufallsausfällen und/oder Fertigungsfehler und Montagefehler, welche zu verfrühten Verschleißausfällen führen. Diese Ausfallwahrscheinlichkeit wird beispielsweise als empirisch ermittelter oder als laufend von einem maschinellen Lernen angepasster Prozentsatz auf den regulären Ersatzteilbedarf angesetzt, welcher mittels des oben beschriebenen Verfahrens ermittelt worden ist. Es ergibt sich somit ein vorzeitiger Ersatzteilbedarf als prozentualer Anteil des regulären Ersatzteilbedarfs. Es wird also mit diesem zusätzlichen Schritt d1. ein (zusätzlicher) Ersatzteilbedarf ermittelt und gegebenenfalls eine entsprechende Anzahl von (zusätzlichen) Ersatzteilen beschafft und vorgehalten. Somit lässt sich bei einem frühzeitigen Ausfall die statistisch wahrscheinliche (oder maximal wahrscheinliche) Anzahl von defekten Funktionseinheiten ersetzen.
Der vorzeitige Ersatzteilbedarf entspricht inhaltlich dem regulären Ersatzteilbedarf, nur dass der Zeitpunkt ein anderer ist, beispielsweise für den vorzeitigen Ersatzteilbedarf ab sofort oder ab einem Zeitpunkt nach einer kürzest möglichen Beschaffungszeit.
Es wird weiterhin in einer vorteilhaften Ausführungsform des Verfahrens vorgeschlagen, dass auf Basis des Ausgebens eines Ersatzteilbedarfs, in einem Schritt e. eine automatisierte Beschaffung zumindest eines Ersatzteils für die betreffende Funktionseinheit erfolgt, bevorzugt von der Computereinrichtung.
In Schritt e. wird mittels der Computereinrichtung auf Basis des Ausgebens eines Ersatzteilbedarf eine automatisierte Beschaffung ausgelöst. Dabei ist die Anzahl von Ersatzteilen korrespondierend mit dem in Schritt d. und/oder Schritt d1. ausgegebenen Ersatzteilbedarf (also gegebenenfalls der Summe des regulären Ersatzteilbedarfs und des vorzeitigen Ersatzteilbedarfs zu einem gemeinsamen Zeitpunkt). Dazu wird automatisiert aus der Computereinrichtung der Ersatzteilbedarf ausgelesen, bevorzugt von der Computereinrichtung selbst (mittels eines entsprechenden Verfahrens beziehungsweise Computerprogramms), und an zumindest einen Zulieferer (beispielsweise einen Systemlieferanten) für die betreffende Funktionseinheit übermittelt. In einer Ausführungsform wird die Information direkt an ein EdgeDevice beispielsweise einer Werkzeugmaschine oder einer Fertigungslinie weitergegeben, wobei das EdgeDevice Teil der Computereinrichtung ist oder eine externe Komponente ist. Der EdgeDevice veranlasst dann die Fertigung der angefragten Funktionseinheit beziehungsweise eines Teils für eine Funktionseinheit, zu welcher ein Ersatzteilbedarf besteht.
Gemäß einem weiteren Aspekt wird eine Computereinrichtung vorgeschlagen, aufweisend zumindest die folgenden Komponenten:

- einen Prozessor und einen Speicher zum Durchführen eines Verfahrens nach einer Ausführungsform gemäß der obigen Beschreibung;
- eine Ausgabeeinheit zum Ausgeben von einem Ersatzteilbedarf; und
- eine Kommunikationsschnittstelle zum Senden und/oder Empfangen von Daten von einer Vielzahl von Kraftfahrzeugen und/oder von einer Datenbank.

Eine Computereinrichtung umfasst einen oder mehrere Prozessoren, beispielsweise einen Allzweck-Prozessor (CPU) oder Mikroprozessor, RISC-Prozessor, GPU und/oder DSP. Die Computereinrichtung weist beispielsweise zusätzliche Elemente wie Speicherschnittstellen auf. Wahlweise oder zusätzlich bezeichnen die Begriffe solch eine Vorrichtung, welche in der Lage ist, ein bereitgestelltes oder eingebundenes Programm, bevorzugt mit standardisierter Programmiersprache, wie beispielsweise C++, JavaScript oder Python, auszuführen und/oder Datenspeichergeräte und/oder andere Geräte wie Eingangsschnittstellen und Ausgangsschnittstellen zu steuern und/oder darauf zuzugreifen. Der Begriff Computereinrichtung bezeichnet auch eine Vielzahl von Prozessoren oder eine Vielzahl von (Unter-) Computern, welche miteinander verbunden und/oder anderweitig kommunizierend verbunden sind und möglicherweise eine oder mehrere andere Ressourcen, wie zum Beispiel einen Speicher, gemeinsam nutzen.
Ein (Daten-) Speicher ist beispielsweise eine Festplatte (HDD, SSD, HHD) oder ein (nichtflüchtiger) Festkörperspeicher, beispielsweise ein ROM-Speicher oder Flash-Speicher [Flash-EEPROM]. Der Speicher umfasst oftmals eine Mehrzahl einzelner physischer Einheiten oder ist auf eine Vielzahl von separaten Geräten verteilt, sodass ein Zugriff darauf über Datenkommunikation, beispielsweise Package-Data-Service, stattfindet. Letzteres ist eine dezentrale Lösung, wobei Speicher und Prozessoren einer Vielzahl separater Recheneinheiten anstelle eines (einzigen baueinheitlichen) zentralen Computers oder ergänzend zu einem zentralen Computer genutzt werden.
Weiterhin umfasst die Computereinrichtung eine Ausgabeeinheit zum Ausgeben von einem Ersatzteilbedarf. In einer Ausführungsform ist die Ausgabeeinheit beispielsweise ein Bildschirm, auf welchem Informationen bereitgestellt werden. In einer anderen Ausführungsform ist die Ausgabeeinheit beispielsweise derart eingerichtet, dass diese automatisiert Informationen zu dem Ersatzteilbedarf versendet, beispielsweise elektronisch an zumindest einen weiteren Computer.
Eine Kommunikationsschnittstelle ist beispielsweise eine Netzwerkschnittstelle, welche der Computereinrichtung den Zugang zum Senden und/oder Empfangen von Daten von einer Vielzahl von Kraftfahrzeugen und/oder von einer Datenbank ermöglicht. Beispielsweise basiert eine solche Kommunikationsschnittstelle auf einem Ethernet-Standard. In einer anderen Ausführungsform ist die Kommunikationsschnittstelle drahtlos ausgeführt und für eine Verbindung mit einem WLAN oder einem Mobilfunknetz eingerichtet.
Gemäß einem weiteren Aspekt wird ein Kraftfahrzeug vorgeschlagen, aufweisend zumindest die folgenden Komponenten:

- zumindest eine überwachte Funktionseinheit;
- zumindest eine Erfassungseinrichtung zum Erfassen von einer zeitlichen Reihe von Betriebsparametern und/oder einer zeitlichen Reihe von Funktionalitätsgraden von der zumindest einen überwachten Funktionseinheit;
- eine Datenverarbeitungseinrichtung, welche dazu eingerichtet ist, aus den erfassten Betriebsparametern eine Beanspruchungshistorie zu erstellen; und
- eine Kommunikationsschnittstelle zum Senden der Beanspruchungshistorie und/oder des Funktionalitätsgrads an eine Kommunikationsschnittstelle einer Computereinrichtung nach einer Ausführungsform gemäß der obigen Beschreibung.

Hier ist nun ein Kraftfahrzeug vorgeschlagen, welches zumindest eine überwachte Funktionseinheit und eine korrespondierende Anzahl von Erfassungseinrichtungen zum Erfassen von einer zeitlichen Reihe von Betriebsparametern und/oder einer zeitlichen Reihe von Funktionalitätsgraden von der zumindest einen überwachten Funktionseinheit umfasst. Beispielsweise ist eine solche Funktionseinheit eine Hochvoltbatterie, eine elektrische Antriebsmaschine, ein Getriebe, ein Fahrwerksdämpfer, ein Lager und/oder ein Reifen. Die Erfassungseinrichtung ist beispielsweise ein physischer Sensor und/oder eine getriggerte Zeiterfassung, sodass sich eine Betriebsdauer (beispielsweise jeweils zwischen Starten und Deaktivieren des Kraftfahrzeugs beziehungsweise der jeweiligen Funktionseinheit) bestimmen lässt. In einer bevorzugten Ausführungsform ist jeder Funktionseinheit zumindest eine, bevorzugt genau eine einzige, Erfassungseinrichtung zugeordnet.
Mittels einer Datenverarbeitungseinrichtung, welche beispielsweise in einen Bordcomputer des Kraftfahrzeugs integriert ist, ist eine Beanspruchungshistorie aus den erfassten Betriebsparametern erstellbar. Dazu ist die zumindest eine Erfassungseinrichtung mit der Datenverarbeitungseinrichtung datenübertragend verbunden.
Die Kommunikationsschnittstelle ist zum Senden der zumindest einen Beanspruchungshistorie und/oder des zumindest einen Funktionalitätsgrads an eine Kommunikationsschnittstelle eines externen Computers der Computereinrichtung, wie sie oben beschrieben ist, eingerichtet. Die Kommunikationsschnittstelle ist beispielsweise eine Netzwerkschnittstelle, basierend auf einem Ethernet-Standard (zum Auslesen zu diskreten Zeitpunkten) und/oder drahtlos ausgeführt (bevorzugt zum jederzeitigen Auslesen). Eine drahtlose Kommunikationsschnittstelle ist beispielsweise für eine Verbindung mittels PAN, WLAN, Mobilfunk oder Satellitenkommunikation eingerichtet. In einer kabelgebundenen Ausführungsform ist die Kommunikationsschnittstelle an eine konventionelle OBD [engl.: On-Board-Diagnose] Schnittstelle angebunden. Das Senden über eine physische Netzwerkschnittstelle (Ethernet, OBD-Schnittstelle) ist beispielsweise in einer Servicestelle und/oder in einer Werkstatt ermöglicht, wohingegen die drahtlose Verbindung von jedem beliebigen Ort und dauerhaft und/oder in regelmäßigen Zeitabständen ein Senden an eine Kommunikationsschnittstelle einer Computereinrichtung erlaubt.
In einer Ausführungsform ist mittels der Kommunikationsschnittstelle die Beanspruchungshistorie unaufgefordert an die Computereinrichtung gesendet, beispielsweise in regelmäßigen zeitlichen Intervallen. In einer anderen Ausführungsform fordert zunächst die Computereinrichtung die Beanspruchungshistorie an, welche dann mittels der Kommunikationsschnittstelle gesendet wird.
Mit diesem Kraftfahrzeug beziehungsweise einer Vielzahl von solchen Kraftfahrzeugen ist das oben beschriebene Verfahren durchführbar. Das Kraftfahrzeug ist selbst beispielsweise konventionell ausgeführt. In einer Ausführungsform wird auf Basis des ermittelten Restfunktionalitätsgrads dem Kraftfahrzeug beziehungsweise dem Nutzer des Kraftfahrzeugs eine anstehende Wartung mitgeteilt. Feste Wartungsintervalle sind damit nicht notwendig sowie eine Ersatzteilplanung vereinfacht, indem ein Kraftfahrzeug erst dann zur Wartung einbestellt wird, wenn auch die betroffene(n) Funktionseinheit(en) geliefert werden können. Unter Umständen werden auch unter Umgehung von Lagerständen des OEM die einbestellende Werkstatt unmittelbar von einem Zulieferer mit der angefragten (Ersatz-) Funktionseinheit versorgt.
Gemäß einem weiteren Aspekt wird ein Computerprogramm vorgeschlagen, umfassend
einen Computerprogrammcode, wobei der Computerprogrammcode auf einer Computereinrichtung derart ausführbar ist, dass die Computereinrichtung dazu veranlasst ist, das Verfahren nach einer Ausführungsform gemäß der obigen Beschreibung auszuführen, wobei zumindest eine Einheit der Computereinrichtung:

- in einer Servicestelle angeordnet ist; und/oder
- zur Kommunikation mit einer Cloud, auf welcher bevorzugt der Computerprogrammcode bereitgestellt ist, eingerichtet ist.

Das hier beschriebene Verfahren ist gemäß dieser Ausführungsform computerimplementiert ausgeführt. Das computerimplementierte Verfahren ist als Computerprogrammcode abgespeichert, wobei der Computerprogrammcode, wenn er auf einer Computereinrichtung ausgeführt wird, die Computereinrichtung dazu veranlasst, das Verfahren gemäß einer Ausführungsform gemäß der vorhergehenden Beschreibung auszuführen.
Das computerimplementierte Verfahren ist beispielsweise durch ein Computerprogramm verwirklicht, wobei das Computerprogramm den Computerprogrammcode umfasst, wobei der Computerprogrammcode, wenn er auf einer Computereinrichtung ausgeführt wird, die Computereinrichtung dazu veranlasst, das Verfahren gemäß einer Ausführungsform nach vorhergehender Beschreibung auszuführen. Als Computerprogrammcode werden gleichbedeutend eine oder mehrere Anweisungen oder Befehle bezeichnet, welche eine Computereinrichtung oder einen Prozessor veranlassen, eine Reihe von Operationen durchzuführen, welche zum Beispiel einen Algorithmus und/oder andere Verarbeitungsmethoden darstellen.
Das Computerprogramm ist bevorzugt teilweise oder vollständig auf einem Server beziehungsweise einer Servereinheit eines Cloud-System, einem Handheld (beispielsweise einem Smartphone) und/oder auf zumindest einer Einheit der Computereinrichtung ausführbar. Mit dem Begriff Server oder Servereinheit wird hier ein solcher Computer bezeichnet, welcher Daten und/oder operative Dienste oder Dienste für ein oder mehrere andere computergestützte Geräte oder Computer bereitstellt und damit das Cloud-System bildet. Die zumindest eine Einheit der Computereinrichtung ist beispielsweise in einer Servicestelle, beispielsweise einer Produktionsstätte angeordnet und zur Kommunikation mittels der oben beschriebenen Kommunikationsschnittstelle mit einer Cloud eingerichtet. Alternativ oder zusätzlich ist die zumindest eine Einheit der Computereinrichtung zur Kommunikation mit zumindest einem Server eingerichtet, wobei der Server beispielsweise vor Ort in der Servicestelle angeordnet ist.
Gemäß einem weiteren Aspekt wird ein Computerprogrammprodukt vorgeschlagen, auf welchem
ein Computerprogrammcode abgespeichert ist, wobei der Computerprogrammcode auf einer Computereinrichtung derart ausführbar ist, dass die Computereinrichtung dazu veranlasst ist, das Verfahren nach einer Ausführungsform gemäß der obigen Beschreibung auszuführen, wobei zumindest eine Einheit der Computereinrichtung:

Als Computerprogrammprodukt, aufweisend einen Computerprogrammcode nach Anspruch 8, ist beispielsweise ein Medium wie beispielsweise RAM, ROM, eine SD-Karte, eine Speicherkarte, einer Flash-Speicherkarte oder eine Disc, oder auf einem Server abgespeichert und herunterladbar. Sobald das Computerprogramm über eine Ausleseeinheit, beispielsweise ein Laufwerk und/oder eine Installation auslesbar gemacht ist, so ist der enthaltende Computerprogrammcode und das darin enthaltene Verfahren durch eine Computereinrichtung beziehungsweise in Kommunikation mit einer Mehrzahl von Servereinheiten, beispielsweise gemäß obiger Beschreibung, ausführbar.
Die oben beschriebene Erfindung wird nachfolgend vor dem betreffenden technischen Hintergrund unter Bezugnahme auf die zugehörigen Zeichnungen, welche bevorzugte Ausgestaltungen zeigen, detailliert erläutert. Die Erfindung wird durch die rein schematischen Zeichnungen in keiner Weise beschränkt, wobei anzumerken ist, dass die Zeichnungen nicht maßhaltig sind und zur Definition von Größenverhältnissen nicht geeignet sind. Es wird dargestellt in

1 ein Flussdiagramm eines Verfahrens zum Ermitteln von Ersatzteilbedarf;
2 eine schematische Veranschaulichung der Teilnehmer des Verfahrens zum Ermitteln von Ersatzteilbedarf; und
3 ein Diagramm zur Ersatzteilbedarfsplanung.

In 1 ist ein Flussdiagramm eines Verfahrens zum Ermitteln von Ersatzteilbedarf 1,12 dargestellt. In einem Schritt a. wird eine Beanspruchungshistorie 3 auf Basis von einer zeitlichen Reihe von Betriebsparametern 4 über zumindest eine Funktionseinheit 5,6,7 von einer Vielzahl von Kraftfahrzeugen 8 mittels einer Computereinrichtung 2 erfasst. Es sind in dieser Ausführungsform (rein optional drei) Funktionseinheiten 5,6,7 überwacht. Eine (erste) Funktionseinheit 5 ist beispielsweise eine Hochvoltbatterie, eine (zweite) Funktionseinheit 6 ist beispielsweise ein Fahrzeugreifen und eine (dritte) Funktionseinheit 7 ist beispielsweise ein Fahrwerksdämpfer. Für jede Funktionseinheit 5,6,7 ist somit eine separate Beanspruchungshistorie 3 erfasst.
Rein optional werden in einem Schritt a1. Werkstattdaten 11 der Funktionseinheiten 5,6,7 mittels der Computereinrichtung 2 erfasst, zu welcher zuvor in Schritt a. die Beanspruchungshistorien 3 erfasst worden sind. Es sei darauf hingewiesen, dass der Zeitpunkt und die Abfrage von Beanspruchungshistorien 3 für eine Mehrzahl von oder jede der Funktionseinheiten 5,6,7 unabhängig sind. In einem nachfolgenden Schritt a2. werden die zuvor erfassten Werkstattdaten 11 in die Beanspruchungshistorien 3 der jeweiligen Funktionseinheit 5,6,7 mittels der Computereinrichtung 2 integriert, beispielsweise ergänzt und in einer gemeinsamen Datei abgespeichert.
In einem (Schritt a. oder Schritt a2.) nachfolgenden Schritt b. wird auf Grundlage der in Schritt a. erfassten Beanspruchungshistorien 3 jeweils eine separate zukünftige Beanspruchungshistorie 9 für jede Funktionseinheit 5,6,7 mittels der Computereinrichtung 2 extrapoliert. Beispielsweise ist eine jede zukünftige Beanspruchungshistorie 9 bis zu einem Zeitpunkt extrapoliert, welcher einem Beschaffungszeitpunkt in einem Beschaffungsintervall, einem Wartungszeitpunkt in einem Wartungsintervall, einem Ende eines Garantieanspruchs, einem Ende einer definierten Nutzungsdauer und/oder einem anderen festgelegten Zeitpunkt entspricht.
In Schritt c. wird mittels der Computereinrichtung 2 für einen vorbestimmten zukünftigen Zeitpunkt, beispielsweise ein festgelegter Servicetermin und/oder ein Stichtag für eine Teilebeschaffung, auf Basis der zukünftigen Beanspruchungshistorie 9 gemäß Schritt b. ein Restfunktionalitätsgrad für (beispielsweise jede) Funktionseinheit 5,6,7 berechnet. Die Berechnung basiert auf einem vorbestimmten Degradationsmodell 10, welches rein optional für jede Funktionseinheit 5,6,7 separat angepasst ist und der in Schritt b. extrapolierten Beanspruchungshistorien 9 einer jeweiligen Funktionseinheit 5,6,7. Der Restfunktionalitätsgrad ist am Beispiel einer Hochvoltbatterie (erste Funktionseinheit 5) beispielsweise ein State of Health (SoH) in Prozent, am Beispiel eines Reifens (zweite Funktionseinheit 6) eine Profilhöhe in Millimeter und am Beispiel eines Fahrwerkdämpfers (dritte Funktionseinheit 7) eine ansteigende Reibkraft beziehungsweise Veränderung der Dämpferkennlinie.
In einem rein optionalen Schritt f., welcher dem Schritt c. vorgelagert ist, wird ein Funktionalitätsgrad von (beispielsweise jeder) Funktionseinheit 5,6,7 erfasst, zu welcher in Schritt a. die Beanspruchungshistorie 3 erfasst worden ist. Der Funktionalitätsgrad gibt zum erfassten Zeitpunkt den Verschleißzustand der betreffenden Funktionseinheit 5,6,7 wieder und dient als ein Korrekturwert für das Degradationsmodell 10, mittels welchem in Schritt c. der jeweilige Restfunktionalitätsgrad für die betreffende Funktionseinheit 5,6,7 berechnet worden ist. Bevorzugt wird dies mittels maschinellem Lernen von der Computereinrichtung 2 ausgeführt.
In einem auf Schritt c. nachfolgenden Schritt d. wird ein (regulärer) Ersatzteilbedarf 1 mittels der Computereinrichtung 2 ausgegeben, wenn der jeweilige berechnete Restfunktionalitätsgrad aus Schritt c. einen vorbestimmten korrespondierenden Ersetzgrenzwert erreicht beziehungsweise überschreitet. Hier wird also der zu einem vorbestimmten Zeitpunkt berechnete Restfunktionalitätsgrad mit einem Ersetzgrenzwert verglichen. Der Ersatzteilbedarf 1 umfasst beispielsweise eine Typenbezeichnung der zu ersetzenden Funktionseinheit 5,6,7 und/oder eine zu ersetzende Menge der Funktionseinheit 5,6,7. Bei einer Ausführungsform des Verfahrens, bei welcher ein individueller und nicht rein statistischer Datenbestand vorliegt, ist bevorzugt zudem eine Zuordnung zu dem Kraftfahrzeug 8 der zu ersetzenden Funktionseinheit 5,6,7 in dem Ersatzteilbedarf 1 enthalten.
Rein optional wird in einem Schritt d1. jeder der in Schritt c. berechneten Restfunktionalitätsgrade mittels der Computereinrichtung 2 anhand einer vorbestimmten (individuellen) Ausfallwahrscheinlichkeit ein vorzeitiger Ersatzteilbedarf 12 der jeweiligen Funktionseinheit 5,6,7 berechnet und ausgegeben. Es ergibt sich somit ein vorzeitiger Ersatzteilbedarf 12 als prozentualer Anteil des regulären Ersatzteilbedarfs 1. Es wird also mit diesem zusätzlichen Schritt d1. ein zusätzlicher Ersatzteilbedarf 12 ermittelt, wobei dieser nur mit einer gewissen Wahrscheinlichkeit eintritt. Damit wird in einem angemessenen Umfang ausreichend Ersatzteile für frühzeitige Ausfälle bereitgehalten. Es sei darauf hingewiesen, dass ein solcher vorzeitiger Ersatzteilbedarf 12 sich nicht als Ergebnis einer (regulären) Degradation aus dem Degradationsmodell 10 ergibt und bevorzugt ein tatsächlicher frühzeitiger Ausfall keinen Einfluss auf das Degradationsmodell 10 nimmt.
In einem bevorzugten (abschließenden) Schritt e. wird mittels der Computereinrichtung 2 auf Basis des Ausgebens des (regulären) Ersatzteilbedarfs 1 und des vorzeitigen Ersatzteilbedarfs 12 eine automatisierte Beschaffung ausgelöst. Dabei ist die Anzahl von Ersatzteilen korrespondierend mit dem in Schritt d. und/oder Schritt d1. ausgegebenen Ersatzteilbedarf 1,12 (also gegebenenfalls der Summe des regulären Ersatzteilbedarfs 1 und des vorzeitigen Ersatzteilbedarfs 12 zu einem gemeinsamen Zeitpunkt). Alternativ wird dieser Schritt e. erst nach menschlicher Prüfung ausgeführt.
Rein optional werden die Schritte a. bis Schritt d(1). beziehungsweise bis Schritt e. über die gesamte Nutzungsdauer jeder Funktionseinheit 5,6,7 mehrfach wiederholt, beispielsweise in regelmäßigen zeitlichen Abständen, ausgeführt.
In 2 ist eine schematische Veranschaulichung über die Teilnehmer an dem Verfahren zum Ermitteln von Ersatzteilbedarf 1,12 gezeigt. Dazu ist hier exemplarisch eine Vielzahl von Kraftfahrzeugen 8 dargestellt, wobei pars-pro-toto nur eines mit detaillierteren Bezugszeichen versehen ist.
Rein optional weisen die Kraftfahrzeuge 8 (rein repräsentativ drei) jeweils gleiche Funktionseinheiten 5,6,7 auf, sodass von den drei Kraftfahrzeugen 8 eine Fahrzeugflotte gebildet ist. Rein optional ist die erste Funktionseinheit 5 eine Hochvoltbatterie, die zweite Funktionseinheit 6 ein Fahrzeugreifen und die dritte Funktionseinheit 7 ein Fahrwerksdämpfer. Jeder dieser Funktionseinheiten 5,6,7 ist eine korrespondierende Erfassungseinrichtung 16 (beispielsweise ein geeigneter Sensor) zugeordnet, welche regelmäßig misst, also eine zeitliche Reihe von relevanten Betriebsparametern 4 der jeweiligen Funktionseinheit 5,6,7 aufstellt.
Diese Betriebsparameter 4 werden an eine Datenverarbeitungseinrichtung 17 (beispielsweise ein Steuergerät und/oder einen Bordcomputer) des Kraftfahrzeugs 8 gesendet. Hier ist pars-pro-toto nur die Erfassungseinrichtung 16 für die erste Funktionseinheit 5 mit einem Bezugszeichen versehen. Rein optional ist die Datenverarbeitungseinrichtung 17 dazu eingerichtet, aus der jeweiligen Reihe von Betriebsparametern 4 der zugehörigen Funktionseinheit 5,6,7 eine für jede Funktionseinheit 5,6,7 separate Beanspruchungshistorie 3 zu erstellen. In der dargestellten Ausführungsform sind also korrespondierend zu den drei Funktionseinheiten 5,6,7 drei separate Beanspruchungshistorien 3 erstellbar. Die Beanspruchungshistorien 3 jedes der gezeigten Kraftfahrzeuge 8 sind mittels einer jeweiligen Kommunikationsschnittstelle 18 rein optional unaufgefordert und drahtlos an eine (Automotive-) Cloud 21 verschickbar.
Rein optional sind die Datenverarbeitungseinrichtung 17 (beziehungsweise der Bordcomputer) des Kraftfahrzeugs 8 und die Cloud 21 ein Teil einer (gemeinsamen) Computereinrichtung 2. Alternativ sind alle fahrzeug-internen Computereinheiten von der Computereinrichtung 2 separate Einheiten. Ein Teil (beispielsweise ein Server) der Computereinrichtung 2 ist in einer Servicestelle 19 (beispielsweise als EdgeDevice) angeordnet und mittels einer weiteren rein optional (drahtlosen) Kommunikationsschnittstelle 14 mit der Cloud 21 (oder alternativ unmittelbar mit der Datenverarbeitungseinrichtung 17 des Kraftfahrzeugs 8) verbunden. Weiterhin sind an die Cloud 21 eine Vielzahl von (hier repräsentativ drei) Produktionsstätten 20 datenübertragend verbunden. Beispielsweise ist eine solche Produktionsstätte 20 ein Teilezulieferer, ein Systemlieferant oder ein Komponentenlieferant. Weiterhin ist rein optional eine Werkstatt für den Austausch von Werkstattdaten 11 (vergleiche Schritt a1.) datenübertragend mit der Cloud 21 verbunden.
Die Computereinrichtung 2 und/oder jener in der Servicestelle 19 (oder auch in einer Produktionsstätte 20) angeordnete Teil der Computereinrichtung 2 ist dazu eingerichtet, dass in 1 beschriebene Verfahren teilweise oder in Gänze auszuführen. Es wird insoweit auf vorhergehende Beschreibung verwiesen. In einer anderen Ausführungsform sind die Verfahrensschritte auf der Datenverarbeitungseinrichtung 17 und/oder in der Cloud 21 ausführbar.
Rein optional ist in dieser Ausführungsform der in Schritt d. (beziehungsweise in Schritt d1.) ausgegebene Ersatzteilbedarf 1,12 in einer Datenbank 15 hinterlegt. Zumindest der reguläre Ersatzteilbedarf 1 (gegebenenfalls der vorzeitige Ersatzteilbedarf 12) und hier zudem das Degradationsmodell 10 und die extraploierte zukünftige Beanspruchungshistorie 9 sind hier auf einer Ausgabeeinheit 13 (beispielsweise ein Bildschirm) für eine menschliche Nachvollziehbarkeit sichtbar gemacht. In dem rein optionalen Schritt e. wird mittels der Computereinrichtung 2 auf Basis des Ausgebens des Ersatzteilbedarfs 1,12 eine automatisierte Beschaffung ausgelöst. Dazu wird automatisch (beispielsweise zu festgelegten Zeitpunkten) von der Computereinrichtung 2 der Ersatzteilbedarf 1,12 (beispielsweise aus der Datenbank 15) ausgelesen und an zumindest eine Produktionsstätte 20 (beispielsweise einen Systemlieferanten) für die betreffende Funktionseinheit 5,6,7 (mittels der Cloud 21 oder unmittelbar) übermittelt.
In 3 ist ein Diagramm zur Ersatzteilbedarfsplanung gezeigt. Auf der Abszisse 22 ist die Zeit aufgetragen, beispielsweise stellt ein jeder Strich ein Quartal eines Kalenderjahrs dar. Auf der Ordinate 23 ist der Ersatzteilbedarf beispielsweise für die zweite Funktionseinheit 6 (Fahrzeugreifen in Stück) aufgetragen.
Hier ist nun Anfangs (darstellungsgemäß der Nullpunkt des Diagramms) das Verfahren gemäß 1 ausgeführt und für rein optional zwei vorbestimmte Zeitpunkte (zweites Quartal und viertes Quartal) in Schritt d. ein regulärer Ersatzteilbedarf 1 (darstellungsgemäß diagonal schraffiert) ausgegeben. Der reguläre Ersatzteilbedarf 1 ist zum ersten Zeitpunkt (zweites Quartal) rein optional niedriger, als der reguläre Ersatzteilbedarf 1 zum zweiten Zeitpunkt (viertes Quartal).
Rein optional ist hier zusätzlich in Schritt d1. auf Basis des in Schritt c. berechneten Restfunktionalitätsgrads anhand einer vorbestimmten Ausfallwahrscheinlichkeit ein vorzeitiger Ersatzteilbedarf 12 für die Funktionseinheit 6 berechnet und ausgegeben. Der vorzeitige Ersatzteilbedarf 12 ist darstellungsgemäß horizontal schraffiert. Es ergibt sich ein vorzeitiger Ersatzteilbedarf 12 beispielsweise als prozentualer Anteil des regulären Ersatzteilbedarfs 1, wobei der vorzeitige Ersatzteilbedarf 12 im Ergebnis dem regulären Ersatzteilbedarf 1 entspricht. Jedoch ist der Zeitpunkt, auf welchen sich die Berechnung bezieht und für den der Bedarf entsteht, ein anderer.
Hier ist für den zuerst berechneten Zeitpunkt der vorzeitige Ersatzteilbedarf 12 ab sofort (darstellungsgemäß vom Nullpunkt an, also noch keine oder nur geringe Degradation) vorzuhalten, um bei einem sehr frühzeitigen Ausfall (beispielsweise aufgrund eines Fertigungsfehlers und/oder Montagefehlers) der Funktionseinheit 6 einen Austausch dieser durchführen zu können. Für den zweiten vorbestimmten Zeitpunkt ist somit ebenfalls ein vorzeitiger Ersatzteilbedarf 12 berechenbar, welcher dann rein optional zum gleichen Zeitpunkt vorzuhalten ist, wie der reguläre Ersatzteilbedarf 1 zum ersten Zeitpunkt. In diesem Beispiel ist gezeigt, dass der vorzeitige Ersatzteilbedarf 12 im Vergleich zum Nullpunkt abgenommen hat. Beispielsweise liegt das daran, dass die zukünftige Beanspruchungshistorie 9 eine geringere vorzeitige Ausfallwahrscheinlichkeit bedingt als dies bei einem Neuzustand abschätzbar war.
Mit dem hier vorgeschlagenen Verfahren ist eine bedarfsgerechte Ersatzeilplanung ermöglicht, wobei zugleich Ressourcen eingespart sind.
Bezugszeichenliste

1: regulärer Ersatzteilbedarf
2: Computereinrichtung
3: erfasste Beanspruchungshistorie
4: Betriebsparameter
5: erste Funktionseinheit
6: zweite Funktionseinheit
7: dritte Funktionseinheit
8: Kraftfahrzeug
9: zukünftige Beanspruchungshistorie
10: Degradationsmodell
11: Werkstattdaten
12: vorzeitiger Ersatzteilbedarf
13: Ausgabeeinheit
14: computerseitige Kommunikationsschnittstelle
15: Datenbank
16: Erfassungseinrichtung
17: Datenverarbeitungseinrichtung
18: fahrzeugseitige Kommunikationsschnittstelle
19: Servicestelle
20: Produktionsstätte
21: Cloud
22: Abszisse
23: Ordinate

Claims

Verfahren zum Ermitteln von Ersatzteilbedarf (1), aufweisend die folgenden Schritte, welche auf einer Computereinrichtung (2) ausgeführt werden: a. Erfassen einer Beanspruchungshistorie (3) auf Basis von einer zeitlichen Reihe von Betriebsparametern (4) über zumindest eine Funktionseinheit (5,6,7) von einer Vielzahl von Kraftfahrzeugen (8); b. auf Grundlage der in Schritt a. erfassten Beanspruchungshistorie (3), Extrapolieren einer zukünftigen Beanspruchungshistorie (9) von der zumindest einen Funktionseinheit (5,6,7); c. für einen vorbestimmten zukünftigen Zeitpunkt, Berechnen eines Restfunktionalitätsgrads für die zumindest eine Funktionseinheit (5,6,7) auf Basis eines vorbestimmten Degradationsmodells (10) und der in Schritt c. extrapolierten Beanspruchungshistorie (9); und d. wenn der berechnete Restfunktionalitätsgrad einen vorbestimmten Ersetzgrenzwert erreicht oder überschreitet, Ausgeben eines Ersatzteilbedarfs (1) für die zumindest eine Funktionseinheit (5,6,7).
Verfahren nach Anspruch 1, wobei das Verfahren weiterhin zumindest den folgenden Schritt umfasst: f. Erfassen eines Funktionalitätsgrads von der zumindest einen Funktionseinheit (5,6,7), zu welcher in Schritt a. die Beanspruchungshistorie (3) erfasst worden ist, wobei bevorzugt das Degradationsmodell (10) für den Schritt d. fortlaufend aus den in Schritt a. und Schritt f. erfassten Beanspruchungshistorien (3) und Funktionalitätsgrade mittels maschinellen Lernensvon einer Computereinrichtung (2) angepasst wird.
Verfahren nach Anspruch 1 oder Anspruch 2, wobei das Verfahren weiterhin zumindest die folgenden Schritte umfasst: a1. Erfassen von Werkstattdaten (11) über die zumindest eine Funktionseinheit (5,6,7), zu welcher in Schritt a. die Beanspruchungshistorie (3) erfasst worden ist, und a2. Integration der Werkstattdaten (11) in die Beanspruchungshistorie (3).
Verfahren nach einem der vorhergehenden Ansprüche, wobei auf Basis des in Schritt c. berechneten Restfunktionalitätsgrads anhand einer vorbestimmten Ausfallwahrscheinlichkeit in Schritt d1. Berechnen und Ausgeben eines vorzeitigen Ersatzteilbedarfs (12).
Verfahren nach einem der vorhergehenden Ansprüche, wobei auf Basis des Ausgebens eines Ersatzteilbedarfs (1,12), in einem Schritt e. eine automatisierte Beschaffung zumindest eines Ersatzteils für die betreffende Funktionseinheit (5,6,7) erfolgt, bevorzugt von der Computereinrichtung (2).
Computereinrichtung (2), aufweisend zumindest die folgenden Komponenten: - einen Prozessor und einen Speicher zum Durchführen eines Verfahrens nach einem der vorhergehenden Ansprüche; - eine Ausgabeeinheit (13) zum Ausgeben von einem Ersatzteilbedarf (1,12); und - eine Kommunikationsschnittstelle (14) zum Senden und/oder Empfangen von Daten von einer Vielzahl von Kraftfahrzeugen (8) und/oder von einer Datenbank (15).
Kraftfahrzeug (8), aufweisend zumindest die folgenden Komponenten: - zumindest eine überwachte Funktionseinheit (5,6,7); - zumindest eine Erfassungseinrichtung (16) zum Erfassen von einer zeitlichen Reihe von Betriebsparametern (4) und/oder einer zeitlichen Reihe von Funktionalitätsgraden von der zumindest einen überwachten Funktionseinheit (5,6,7); - eine Datenverarbeitungseinrichtung (17), welche dazu eingerichtet ist, aus den erfassten Betriebsparametern (4) eine Beanspruchungshistorie (3) zu erstellen; und - eine Kommunikationsschnittstelle (18) zum Senden der Beanspruchungshistorie (3) und/oder des Funktionalitätsgrads an eine Kommunikationsschnittstelle (14) einer Computereinrichtung (2) nach Anspruch 6.
Computerprogramm, umfassend einen Computerprogrammcode, wobei der Computerprogrammcode auf einer Computereinrichtung (2) derart ausführbar ist, dass die Computereinrichtung (2) dazu veranlasst ist, das Verfahren nach einem von Anspruch 1 bis Anspruch 5 auszuführen, wobei zumindest eine Einheit der Computereinrichtung (2): - in einer Servicestelle (19) angeordnet ist; und/oder - zur Kommunikation mit einer Cloud (21), auf welcher bevorzugt der Computerprogrammcode bereitgestellt ist, eingerichtet ist.
Computerprogrammprodukt, auf welchem ein Computerprogrammcode abgespeichert ist, wobei der Computerprogrammcode auf einer Computereinrichtung (2) derart ausführbar ist, dass die Computereinrichtung (2) dazu veranlasst ist, das Verfahren nach einem von Anspruch 1 bis Anspruch 5 auszuführen, wobei zumindest eine Einheit der Computereinrichtung (2): - in einer Servicestelle (19) angeordnet ist; und/oder - zur Kommunikation mit einer Cloud (21), auf welcher bevorzugt der Computerprogrammcode bereitgestellt ist, eingerichtet ist.