WO2020125844A1 - Verfahren zum ferngesteuerten handhaben eines fehlerbefundes eines fortbewegungsmittels, fortbewegungsmittel, backend-server und system - Google Patents

Verfahren zum ferngesteuerten handhaben eines fehlerbefundes eines fortbewegungsmittels, fortbewegungsmittel, backend-server und system Download PDF

Info

Publication number
WO2020125844A1
WO2020125844A1 PCT/DE2019/100921 DE2019100921W WO2020125844A1 WO 2020125844 A1 WO2020125844 A1 WO 2020125844A1 DE 2019100921 W DE2019100921 W DE 2019100921W WO 2020125844 A1 WO2020125844 A1 WO 2020125844A1
Authority
WO
WIPO (PCT)
Prior art keywords
transportation
fault
configuration
error
backend server
Prior art date
Application number
PCT/DE2019/100921
Other languages
English (en)
French (fr)
Inventor
Axel Knaut
Stefan Juraschek
Florian Mume
Francois Bachellerie
Original Assignee
Bayerische Motoren Werke Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bayerische Motoren Werke Aktiengesellschaft filed Critical Bayerische Motoren Werke Aktiengesellschaft
Priority to CN201980081166.1A priority Critical patent/CN113168593A/zh
Priority to US17/415,753 priority patent/US12001272B2/en
Publication of WO2020125844A1 publication Critical patent/WO2020125844A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/20—Administration of product repair or maintenance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management

Definitions

  • the present invention relates to a method for remote-controlled handling of a finding of a means of transportation, a means of transportation, a back-end server and a system.
  • Breakdowns and diagnostic data can be evaluated in a high-performance database analysis.
  • Known customer problems can also be described in such a database using error images. These error patterns can be made up of logical combinations of different
  • Parameters such as vehicle type, production period,
  • the diagnostic data sent can be stored, for example, on an Internet server, via which the service provider can access the
  • US Pat. No. 8,676,432 B2 discloses an algorithm which, on the basis of collected vehicle fault information, can carry out a forecast of a possibly occurring fault. An alarm can be issued in response to the determined error.
  • the problem arises here that such an alarm does not provide any specific information for a direct problem solving.
  • the alarm is one-sided in nature, so that it is not possible for a workshop and / or other service provider to directly access a database that creates the algorithm and collects vehicle error data
  • the present invention relates to a method for remote-controlled handling of a fault finding of a means of transportation.
  • the term “remote-controlled handling” means in particular that the specific correction of a malfunction of the means of transportation is not exclusively on-site, e.g. B. takes place in a workshop, but with the help of a remote backend server. Additionally or alternatively, the functional error can be remedied during a journey by means of the method according to the invention, which will be explained in more detail below.
  • a "fault finding" can in particular be a determination of a
  • Malfunction e.g. B. an incomplete charging of a battery and / or a software error and / or a malfunction of a component of the
  • a fault finding can therefore include a vehicle diagnosis of a fault and / or an externally determined fault. After an external finding, the fault finding can e.g. can be entered via a selection menu and / or a drop-down menu via an input device of the means of transportation.
  • the fault finding can also be determined by sensors. For example, a faulty finding of a damaged tire, an inoperable component of the
  • Transport means concern.
  • an arrangement of a gas detector on the side of the means of transportation can also determine that fuel vapors escape at one point of the means of transportation.
  • a fault finding can in particular be determined electrically and / or optically, for example by means of a sensor system of the means of transportation.
  • an abnormal coloring and / or turbidity of the engine oil (as a fault finding) can be determined optically, for example by arranging optical sensors in the oil pan of the means of transportation.
  • the fault finding can be sent from the means of transportation to the back-end server in the form of data.
  • data can be, for example, wireless, e.g. B. via a mobile network, from the means of transportation to the back-end server.
  • an error image stored on the back-end server is automatically determined as a function of the error finding. For example, data representing the fault finding can be compared with data representing fault patterns. Error images can
  • Error images can represent a single malfunction of the means of transportation, such as an oil loss on the axle boot.
  • fault patterns can represent a chain of functional faults such as a broken toothed belt and a damaged cylinder head gasket.
  • fault patterns define the causes and consequences of the problem, which correlate with parts of the means of transportation.
  • Fault patterns can affect electronic and mechanical components of the means of transportation. For example, the data due to its content, e.g. B. on the basis of character strings. If there is a sufficiently large percentage correspondence between the contents of the data of the fault images and the fault finding, e.g. B. 80%, the relevant fault patterns can first be determined by comparing them with the fault finding.
  • a fault pattern can also include features of an electrical fault, for example a short circuit, and / or a mechanical fault, for example a deformation of a part of the locomotion, and / or a visual abnormality, for example an abnormal color of the engine oil and / or a presence an acoustic abnormality, for example an abnormal howl of an engine, and / or the presence of a temporal abnormality, for example the age of a software component (for example more than 60 days without an update).
  • an electrical fault for example a short circuit
  • / or a mechanical fault for example a deformation of a part of the locomotion
  • / or a visual abnormality for example an abnormal color of the engine oil and / or a presence an acoustic abnormality, for example an abnormal howl of an engine, and / or the presence of a temporal abnormality, for example the age of a software component (for example more than 60 days without an update).
  • a visual abnormality for example an abnormal color of the engine oil
  • Configuration requirements are information requests regarding technical components of the means of transportation, which are needed to identify or rule out an error pattern. For example, configuration requirements associated with an error pattern can
  • Configuration requirements can, for example, be a gear type, i.e. manually or automatically, and / or a
  • Further configuration requirements can e.g. Information regarding a production date and / or a country-specific hardware and / or software variant of a means of transportation component and / or a production parameter and / or a means of transportation type and / or a usage profile and / or the presence of a trailer and / or a weight of an existing trailer .
  • Usage profile can provide information about the environment in which the
  • Means of transportation was used. Examples of this information are air humidity and / or a degree of road salting and / or a degree of air pollution and / or a route profile (e.g. inclines).
  • one or more configuration requirements are therefore automatically determined depending on the stored error pattern.
  • a configuration request is created and sent, representing a union of the respective configuration requirements to the means of transportation.
  • the union can be as one
  • a combination of all configuration needs can be viewed, which are required by the backend server.
  • the configuration request is therefore to be regarded as a request for support on the part of the back-end server, by means of which the means of transportation is requested to provide specific information regarding the components.
  • the configuration request ensures that all information for one
  • a configuration specification can be created by the means of transportation. For example, all configuration data of the means of transportation can be stored in a memory of the means of transportation. Depending on the configuration request, this data can be filtered with regard to the
  • Configuration data of the means of transportation which e.g. on one
  • Means of transportation are stored, determined by the data algorithm dependency on the configuration request. In response to this determination, configuration specifications are created. In a further step, the configuration specification is sent by the
  • the configuration specification may include a serial number of a transportation component.
  • the back-end server can automatically suggest measures that are necessary in order to address the respective error image that is assigned to a particular configuration or an error image. For example, several
  • a troubleshooting measure can either fix the error yourself (e.g. by means of a software update) or provide information that is necessary to rectify the error (e.g. visiting a workshop).
  • a troubleshooting measure can therefore be understood as an aid or even a tool that is set up to deal with an error for a specific means of transportation depending on the configuration of the
  • Fix transportation For example, come as
  • Troubleshooting measures ECU tests in question which are remote, i.e. can be carried out by radio or locally in a workshop. Additionally or alternatively, a determination of a remedial measure can be carried out by comparing possible fault patterns using the physically available fault indicators (e.g. electronic measurement data and / or mechanical ones
  • Measurement data and / or measurement data relating to a gas composition and / or a color from onboard and offboard sources are carried out.
  • a history can be defined for a relevant means of transportation, wherein the members of the means of transportation have at least one common configuration-specific characteristic. Additionally or alternatively, a remedial measure can be performed depending on a ranking of the
  • Defect patterns can be determined depending on a predefined matching criterion. For example, a predefined one
  • Correspondence criterion corresponds to a degree of agreement between the fault pattern and the fault finding. Additionally or alternatively, the predefined match criterion can be defined on the basis of a predefined priority table. Furthermore or alternatively, the troubleshooting measures can be selected depending on a cost-optimized and / or time-optimized repair time. Additionally or alternatively, the
  • Probability of detection of the fault pattern can be selected. For example, a preventive exchange of one
  • Transport component can be provided if the with the
  • Means of locomotion associated with the locomotive component would only be determined again after a predefined period of time (e.g. in the next winter).
  • an error report is created on the means of transportation.
  • this error finding can be assigned to error images that are stored on the backend server.
  • the back-end server needs further special information from the means of transportation in order to do so
  • Configuration request created, which is transmitted to the means of transportation. This creates a function of the configuration request
  • the back-end server can now, based on the configuration specification, exclude error images and / or derive one or more error correction measures based on identified error images.
  • this comprises a step of sending the troubleshooting measure to the means of transportation.
  • this can be done via a mobile radio network.
  • a troubleshooting action can also include the message that the customer should go to a workshop.
  • the remedial action itself, after being sent to the
  • Locomotive has been sent, fix a bug. This can e.g. B. done by performing a software update. This saves the user from having to visit the workshop.
  • the troubleshooting measure can include automatically initiating a software update and / or determining an apparent error. For example, this can be helpful to avoid no costs and
  • a fault finding is created on the basis of on-board diagnostic data and / or entries in a fault memory of the means of transport. Additionally or alternatively, fault reports based on data from one
  • Means of transportation sensors are determined.
  • the means of transportation sensors determine that a tire has burst. The driver can get a troubleshooting action quickly and efficiently.
  • the troubleshooting measure can include a video and / or instructions. Contents of this video and / or these instructions can include, for example, a procedure regarding the fault finding and / or an instruction to take further steps.
  • the troubleshooting measure can also be a
  • Instructions specific to the vehicle model contain which tools and / or spare parts are required. In other words, it can
  • Means of transportation create a fault finding by means of their own diagnosis and send data representing this fault finding to the back-end server. In this way, a troubleshooting measure that would otherwise only be possible in a workshop can be carried out without the need to (initially) take one
  • the configuration specification relates to determining a
  • Transportation component e.g. B. a battery, and / or a position of the transportation component, e.g. B. within the engine compartment, and / or an operating state of the locomotive component, for. B. activated and / or not activated, and / or a year of construction
  • Configuration specification can be understood as a filter, which ultimately saves computing power for identifying a troubleshooting measure.
  • the error image on the backend server side can result in a malfunction of a part of the means of transportation and / or a non-function of a part of a means of transportation and / or a temperature anomaly of a part of a means of transportation and / or a software error
  • Fault memory and / or sensors of the vehicle are associated with the fault patterns on the back-end server. In other words, that's it
  • the method comprises the steps of displaying a selection of predefined fault findings, e.g. B. "Battery does not charge fully" on a display unit, e.g. B. a head-up display and / or an instrument cluster and / or a central information display.
  • a user for example an employee at a workshop and / or a driver of a vehicle, can make a selection from predefined fault findings.
  • This can take the form of user input, e.g. haptically and / or acoustically and / or by means of a user gesture.
  • a fault finding is created depending on the predefined fault finding which was selected by the user. In this way the
  • Backend server or interact with the vehicle to send a fault report.
  • a plurality of fault patterns can have respective remedial measures. For example, a software update and a detection of an apparent error in the troubleshooting measure can be provided with regard to the same error pattern, the respective configuration requirements making an inquiry regarding a serial number of a processor used in the vehicle and a memory used in the vehicle, which is connected to the processor is can affect. Additionally or alternatively, an apparent error can occur due to an incorrect diagnosis, the incorrect diagnosis due to an installation-related tolerance position
  • Transportation component comes about. For example, an incorrectly installed door contact can cause a message from the means of transportation that the door is open, although in reality the door is closed. For example, a software update could correct this incorrect tolerance compensate by recalibrating the door contact threshold in order to minimize the frequency of misdiagnoses in the future.
  • the troubleshooting measures consist of several
  • the present invention relates to a
  • Means of transport which is set up to determine a fault finding.
  • the means of transportation can send a message regarding the fault finding to a back-end server. Furthermore, that is
  • Means of transportation set up to receive a configuration request in response to the message of the fault finding. Moreover, that is
  • an evaluation unit e.g. B. a CPU and / or a microcontroller and / or an electronic control unit.
  • the method according to the invention relates to a back-end server.
  • the backend server can (automatically) receive a fault finding from a means of transportation. Furthermore, the backend server can automatically search for fault patterns that match this fault finding and determine a respective configuration requirement depending on this.
  • a configuration request representing a union of the respective configuration requirements can be determined automatically and sent to the means of transportation. Furthermore, a configuration specification can be received in response to the configuration request on the back-end server and finally a troubleshooting measure can be determined automatically on the basis of the configuration specification.
  • the present invention relates to a system comprising a means of transportation according to the second
  • an electronic service interface e.g. B. a PC, interposed, which supports the procedural steps that are to be carried out by the means of transportation.
  • a predefined fault finding can be entered by means of the PC using the PC for a particularly complicated repair within a service institution. Such a predefined fault finding can then be sent to the back-end server.
  • Service institution interface can also represent a mobile unit. Thus, it is due to the inventive method for service institutions, for. B. workshops, easy to get an inexpensive and efficient repair measure.
  • Figure 1 shows a variant of the system according to the invention
  • Figure 2 is a flow chart according to a variant of the invention
  • FIG. 3 is an illustration of an interaction between the invention
  • FIG. 1 shows a variant of the system 10 according to the invention, comprising a service institution 2, a means of transportation fleet comprising first to fourth means of transportation 1 a - 1 d and a back-end server 3
  • Means of transportation 1a - 1d of the means of transportation fleet are set up to send customer vehicle service data (relating to repairs and / or breakdowns) and diagnostic data to the back-end server 3, which can maintain this data.
  • the back-end server 3 can therefore collect error images F1-F6 from various means of transportation 1a-1d.
  • error images F1-F6 can also be obtained from a research or
  • the development department can be transferred to the back-end server 3.
  • the second means of transportation 1b of the means of transportation fleet must visit a workshop.
  • the workshop sends error reports FB to the back-end server 3 via the arrow B.
  • the back-end server 3 which will be explained in more detail later, can determine an error pattern F1-F6 as a function of the error finding FB.
  • the back-end server 3 can send data in response to the means of transportation 1 b, which is illustrated by the arrow 6.
  • FIG. 2 shows a flow chart according to a variant of the method according to the invention.
  • a first step 100 one is received
  • the fault finding FB relates to entries in the fault memory, the fault memory recording that a display unit of the
  • an error image F1 - F6 stored on the backend server 3 is automatically determined as a function of the error finding FB.
  • the error image F1-F6 relating to the situation in which the display unit switches off automatically is stored on the back-end server 3.
  • the backend server 3 requires further configuration data of the
  • a configuration requirement K1-K5 is determined automatically as a function of the stored fault pattern F1-F6.
  • a configuration requirement K1 can be assigned to the error image F1, a serial number of the display unit of the means of transportation 1b being required for the further analysis.
  • the second error pattern F2 can be assigned a configuration requirement K2, which states that a current software version, by means of which the display unit of the means of transport 1b is operated, must be queried.
  • a fourth step 400 there is an automatic creation and transmission of a configuration request representing the combination of the configuration requirements K1, K2, which states that a serial number of the display unit is required and that a software version of the display unit is required to which Means of transportation 1b.
  • the means of transportation 1b then creates a configuration specification A comprising a serial number of the display unit and a software version of the display unit.
  • the configuration specification A is sent in a fifth step 500 in response to the back-end server 3 and received by it.
  • an automatic determination of a troubleshooting measure M1-M6 is carried out on the backend server 3 using the configuration specification A.
  • the serial number that was sent by the means of transportation 1b is not assigned to the troubleshooting measure M1, which is provided for the first error image FB1.
  • This error pattern FB1 can thus be excluded.
  • the software version in connection with the error image FB2 corresponds to a specific troubleshooting measure M2, which provides for a software update of the software that operates the display unit.
  • the troubleshooting measure M2 is sent to the means of transportation 1b.
  • the back-end server 3 comprises an error image group Fx, a configuration requirement group Kx and a troubleshooting measure group Mx.
  • Each of these groups includes error patterns F1 - F6, configuration requirements K1 - K5 and error handling measures M1 - M6. This sends the
  • Means of locomotion 1a first an error finding FB to the back-end server 3.
  • error finding FB three error patterns F1, F2 and F4 are determined, which come into question for the error finding FB.
  • These error images F1, F2, F4 are in turn assigned to the configuration requirements K1, K3, K4 and K5.
  • configuration requirements K1, K3, K4 and K5 are required in order for the corresponding error images F1, F2 and F4
  • Troubleshoot action group Mx The configuration requirements K1, K3, K4 and K5 are sent to the means of transportation as illustrated above the corresponding arrow.
  • the means of transportation determines the requested configuration specification A.
  • the means of transportation sends a configuration specification A to the back-end server 3. Due to the configuration specification, error images F1 and F2 can be excluded as error images.
  • the troubleshooting measures M1 and M2 are sent to the means of transportation 1a, which is illustrated by the envelope and the corresponding arrow pointing to the means of transportation 1a.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum ferngesteuerten Handhaben eines Auffälligkeits-Musters oder Fehlerbefundes eines Fortbewegungsmittels (1a-1d) umfassend die Schritte: Empfangen des Auffälligkeitsmusters oder Fehlerbefundes von dem Fortbewegungsmittel (1a-1d) auf einem Backend-Server (3); automatisches Ermitteln eines auf dem Backend-Server (3) hinterlegten Fehlerbildes in Abhängigkeit des Auffälligkeitsmuster oder Fehlerbefundes, im Ansprechen darauf automatisches Ermitteln eines Konfigurations-Bedarfs in Abhängigkeit des hinterlegten Wissens; automatisches Erstellen und Senden einer Konfigurations-Anfrage repräsentierend eine Vereinigungsmenge der jeweiligen Konfigurations-Bedarfe an das Fortbewegungsmittel (1a-1d); Empfangen (500) einer Konfigurations-Spezifikation als Antwort auf die Konfigurations-Anfrage auf dem Backend-Server (3); und automatisches Ermitteln einer Aktion wie z.B. einer Fehlerbehebungsmaßnahme oder einer Information anhand der Konfigurations-Spezifikation durch den Backend-Server (3).

Description

Verfahren zum ferngesteuerten Handhaben eines Fehlerbefundes eines Fortbewegungsmittels, Fortbewegungsmittel, Backend-Server und System
Beschreibung
Die vorliegende Erfindung betrifft ein Verfahren zum ferngesteuerten Handhaben eines Fehlerbefundes eines Fortbewegungsmittels, ein Fortbewegungsmittel, einen Backend-Server und ein System.
Bereits heutzutage können Fahrzeug-Servicedaten von Kunden bzw.
Anwenderfahrzeugen (zum Beispiel betreffend Reparaturen und/oder
Pannenfälle) sowie Diagnosedaten (Fahrzeugbetrieb- und Servicedaten-Transfer und -Analyse und Teleservicereport-Auslesevorgänge) in einer performanten Datenbankanalyse ausgewertet werden. Bekannte Kundenprobleme können ebenfalls in einer derartigen Datenbank durch Fehlerbilder beschrieben werden. Diese Fehlerbilder können aus logischen Kombinationen verschiedener
Parameter, wie zum Beispiel Fahrzeugtyp, Produktionszeitraum,
Softwareversion, Fehlerspeichereintrag, Umweltbedingungen, Messwerte und Gewährleistungsbefunde sowie Kundenkommentaren zusammengesetzt sein. Derartige Fehlerbilder werden in der Datenbank durch Daten repräsentiert. Die Kenntnis von Kundenproblemen wird permanent durch verschiedene Methoden erweitert. Beispielsweise ist eine Verifikation von Einzelfällen bis hin zur
Anwendung automatisierter Data-Mining-Prozesse denkbar. Dadurch können Fehler betroffener Kundenfahrzeuge automatisch mit einer Wissensdatenbank verlinkt werden. Durch diese Fehlerbildererkennung kann es ermöglicht werden, Qualitätsmaßnahmen abzuleiten, die beispielsweise eine Verbesserung von Servicemaßnahmen bis hin zu einer Weiterentwicklung von Soft- und Hardware im Fahrzeug zum Gegenstand haben können. Das vorstehend beschriebene Datenbankkonzept weist allerdings den Nachteil auf, dass eine automatische Verlinkung bekannter Probleme von Kundenfahrzeugen einer
Dienstleistungsinstitution, zum Beispiel einem Händler und/oder einer Werkstatt, nicht zur Verfügung steht. Dies hat zur Folge, dass eine aufwendige manuelle Analyse bereits bekannter Probleme durch Qualitätsexperten vorgenommen werden muss. Hierbei fehlt weiterhin der Fokus auf neue aufkommende
Kundenprobleme.
DE 10 2008 022 771 A1 offenbart ein Verfahren sowie ein System zur
Übertragung von Fahrzeugdiagnosedaten zu einem Fahrzeug-Dienstleister. Dies kann beispielsweise über ein Smartphone eines Anwenders erfolgen. Die gesendeten Diagnosedaten können beispielsweise auf einem Internetserver gespeichert werden, über welchen der Dienstleister Zugriff auf die
Diagnosedaten hat. Hierbei stellt sich allerdings das vorstehend diskutierte Problem erneut, dass lediglich individuelle Fahrzeugdiagnosedaten durch den Dienstleister abgearbeitet werden können. Auf diese Weise kann es zu einer mehrmaligen Abarbeitung desselben Fehlers von unabhängigen Dienstleistern kommen.
US 8 676 432 B2 offenbart einen Algorithmus, welcher auf Basis gesammelter Fahrzeugfehlerinformationen eine Prognose eines möglicherweise auftretenden Fehlers durchführen kann. Im Ansprechen auf den ermittelten Fehler kann ein Alarm ausgegeben werden. Allerdings stellt sich hier das Problem, dass ein derartiger Alarm keine konkrete Information zu einer direkten Problembehebung bietet. Ferner ist der Alarm einseitiger Natur, sodass es für einen Werkstatt- und/oder anderen Dienstleister nicht möglich ist, mit einer Datenbank, welche den Algorithmus erstellt und Fahrzeugfehlerdaten sammelt, direkt zu
kommunizieren.
Es ist somit Aufgabe der vorliegenden Erfindung, die vorstehend diskutierten Nachteile des Standes der Technik zu lindern und eine Handhabung eines fahrzeugseitig auftretenden Fehlers effizienter zu gestalten.
Die erfindungsgemäße Lösung erfolgt durch die technischen Merkmale der unabhängigen Ansprüche. Gemäß einem ersten Aspekt betrifft die vorliegende Erfindung ein Verfahren zum ferngesteuerten Handhaben eines Fehlerbefundes eines Fortbewegungsmittels.
Als„Fortbewegungsmittel“ im Sinne der Erfindung kommen z. B. Automobile, insbesondere Pkw und/oder Lkw, und/oder Motorräder und/oder Flugzeuge und/oder Schiffe infrage.
Der Begriff„ferngesteuertes Handhaben“ bedeutet vorliegend insbesondere, dass die konkrete Behebung eines Funktionsfehlers des Fortbewegungsmittels nicht ausschließlich vor Ort, z. B. in einer Werkstatt, stattfindet, sondern mithilfe eines entfernten Backend-Servers. Zusätzlich oder alternativ kann die Behebung des Funktionsfehlers während einer Fahrt mittels des erfindungsgemäßen Verfahrens durchgeführt werden, was in der Folge genauer erläutert wird.
Als„Fehlerbefund“ kann insbesondere eine Feststellung über einen
Funktionsfehler, z. B. ein unvollständiges Laden einer Batterie und/oder ein Softwarefehler und/oder eine Fehlfunktion einer Komponente des
Fortbewegungsmittels, in Frage kommen. Ein Fehlerbefund kann also eine Fahrzeugdiagnose eines Fehlers und/oder einen extern festgestellten Fehler umfassen. Der Fehlerbefund kann nach externer Feststellung z.B. über ein Auswahlmenü und/oder ein Drop Down-Menü über eine Eingabeeinrichtung des Fortbewegungsmittels eingegeben werden. Der Fehlerbefund kann auch sensorisch Festgestellt werden. Beispielsweise kann ein Fehlerbefund einen beschädigten Reifen, eine funktionsunfähige Komponente des
Fortbewegungsmittels und/oder ein auffälliges Geräusch des
Fortbewegungsmittels und/oder einen auffälligen Geruch des
Fortbewegungsmittels betreffen. Im Falle eines auffälligen Geruchs kann beispielsweise zudem durch eine fortbewegungsmittelseitige Anordnung eines Gasdetektors festgestellt werden, dass Kraftstoffdämpfe an einer Stelle des Fortbewegungsmittels austreten. Ein Fehlerbefund kann insbesondere elektrisch und/oder optisch, z.B. mittels einer Sensorik des Fortbewegungsmittels, ermittelt werden. Beispielsweise kann eine anomale Färbung und/oder Trübung des Motoröls (als Fehlerbefund) optisch, z.B. durch eine Anordnung von optischen Sensoren in der Ölwanne des Fortbewegungsmittels, festgestellt werden. In einem ersten Schritt des erfindungsgemäßen Verfahrens erfolgt ein
Empfangen des Fehlerbefundes von dem Fortbewegungsmittel auf dem
Backend-Server. Beispielsweise kann der Fehlerbefund in Form von Daten von dem Fortbewegungsmittel auf den Backend-Server gesendet werden. Derartige Daten können beispielsweise drahtlos, z. B. über ein Mobilfunknetz, von dem Fortbewegungsmittel an den Backend-Server gesendet werden.
In einem zweiten Schritt erfolgt ein automatisches Ermitteln eines auf dem Backend-Server hinterlegten Fehlerbildes in Abhängigkeit des Fehlerbefundes. Beispielsweise können Daten repräsentierend den Fehlerbefund mit Daten repräsentierend Fehlerbilder verglichen werden. Fehlerbilder können
beispielsweise auf einer Datenbank des Backend-Servers hinterlegt sein.
Fehlerbilder können einen einzelnen Funktionsfehler des Fortbewegungsmittels, wie z.B. einen Ölverlust an der Achsmanschette repräsentieren. Weiterhin können Fehlerbilder eine Kette von Funktionsfehlern wie z.B. einen gerissenen Zahnriemen und eine beschädigte Zylinderkopfdichtung repräsentieren. Mit anderen Worten definieren Fehlerbilder Problemursachen und Problemfolgen, welche mit Teilen des Fortbewegungsmittels korrelieren. Fehlerbilder können elektronische und mechanische Komponenten des Fortbewegungsmittels betreffen. Beispielsweise können die Daten aufgrund ihrer Inhalte, z. B. aufgrund von Zeichenketten, miteinander verglichen werden. Wenn eine hinreichend große prozentuale Übereinstimmung zwischen den Inhalten der Daten der Fehlerbilder und des Fehlerbefundes vorhanden ist, z. B. 80%, können zunächst die relevanten Fehlerbilder durch deren Vergleich mit dem Fehlerbefund ermittelt werden. Ein Fehlerbild kann außerdem Merkmale eines elektrischen Fehlers, z.B. eines Vorliegens eines Kurzschlusses, und/oder eines mechanischen Fehlers, z.B. eines Vorliegens einer Deformation eines Fortbewegungsmittelteils, und/oder eines Vorliegens einer optischen Auffälligkeit, z.B. einer anomalen Farbe des Motoröls und/oder eines Vorliegens einer akustischen Auffälligkeit, z.B. eines anomalen Aufheulens eines Motors, und/oder eines Vorliegens einer zeitlichen Auffälligkeit, z.B. ein Alter einer Softwarekomponente (z.B. mehr als 60 Tage ohne Update), betreffen. Hinterlegten Fehlerbildern können mehrere Konfigurations-Bedarfe zugewiesen sein. Um das Fehlerbild und letzten Endes die Fehlerbehebungsmaßnahme genauer definieren und identifizieren zu können, kann es u. U. notwendig sein, dass Konfigurationen des Fortbewegungsmittels als Konfigurations-Bedarf durch den Backend-Server von dem Fortbewegungsmittel abgefragt werden müssen. Konfigurations-Bedarfe sind Informationsanfragen hinsichtlich technischer Komponenten des Fortbewegungsmittels, welche benötigt werden, um ein Fehlerbild identifizieren oder ausschließen zu können. Beispielsweise können Konfigurations-Bedarfe, welche mit einem Fehlerbild assoziiert sind,
Konfigurations-Bedarfe bezüglich einer Position der
Fortbewegungsmittelkomponente und/oder einer Seriennummer einer
Fortbewegungsmittelkomponente betreffen. Weiterhin können auch mehrere Fehlerbilder automatisch ermittelt werden. Konfigurations-Bedarfe können zum Beispiel eine Getriebeart, d.h. manuell oder automatisch, und/oder ein
Karosseriematerial und/oder eine Lacksorte des Fortbewegungsmittels und/oder eine Information darüber, ob das Fortbewegungsmittel ein Linkslenker oder ein Rechtslenker ist, und/oder einen Motortyp und/oder eine Kraftstoffsorte des Fortbewegungsmittels umfassen. Weitere Konfigurations-Bedarfe können z.B. Informationen über ein Produktionsdatum und/oder eine länderspezifische Hardware- und/oder Software-Variante einer Fortbewegungsmittelkomponente und/oder einen Produktionsparameter und/oder einen Fortbewegungsmitteltyp und/oder ein Nutzungsprofil und/oder ein Vorhandensein eines Anhängers und/oder ein Gewicht eines vorhandenen Anhängers betreffen. Das
Nutzungsprofil kann Informationen über die Umgebung, in der das
Fortbewegungsmittel genutzt wurde, aufweisen. Beispiele für diese Informationen sind eine Luftfeuchtigkeit und/oder ein Grad einer Straßenbesalzung und/oder ein Grad einer Luftverschmutzung und/oder ein Streckenprofil (z.B. Steigungen).
In einem dritten Schritt erfolgt daher ein automatisches Ermitteln eines oder mehrerer Konfigurations-Bedarfe in Abhängigkeit des hinterlegten Fehlerbildes.
In einem vierten Schritt erfolgt ein Erstellen und Senden einer Konfigurations- Anfrage repräsentierend eine Vereinigungsmenge der jeweiligen Konfigurations- Bedarfe an das Fortbewegungsmittel. Die Vereinigungsmenge kann als eine Kombination sämtlicher Konfigurations-Bedarfe angesehen werden, welche durch den Backend-Server benötigt werden. Die Konfigurations-Anfrage ist also als eine Unterstützungsanfrage seitens des Backend-Servers anzusehen, durch welche das Fortbewegungsmittel ersucht wird, konkrete Informationen bezüglich der Komponenten aufzuführen. Wie bereits vorstehend erläutert, kann es dazu kommen, dass mehrere Konfigurations-Bedarfe an das Fortbewegungsmittel gesendet werden müssen, wobei die Konfigurations-Bedarfe jeweils einem möglichen Fehlerbild zugeordnet sind. Durch die Konfigurations-Anfrage wird mit anderen Worten sichergestellt, dass sämtliche Informationen für eine
Fehlerbehebung vorliegen.
In einem nächsten Schritt kann in Abhängigkeit der Konfigurations-Anfrage eine Konfigurations-Spezifikation seitens des Fortbewegungsmittels erstellt werden. Beispielsweise können sämtliche Konfigurationsdaten des Fortbewegungsmittels in einem Speicher des Fortbewegungsmittels hinterlegt sein. In Abhängigkeit der Konfigurations-Anfrage kann ein Filtern dieser Daten bezüglich der
Konfigurations-Bedarfe erfolgen. Ein Filtern kann mittels Datenalgorithmen erfolgen, welche dem Fachmann bekannt sind. Hierbei werden die
Konfigurationsdaten des Fortbewegungsmittels, welche z.B. auf einem
Fortbewegungsmittelspeicher hinterlegt sind, durch den Datenalgorithmus Abhängigkeit der Konfigurations-Anfrage ermittelt. Im Ansprechen auf diese Ermittlung werden Konfigurations-Spezifikationen erstellt. In einem weiteren Schritt erfolgt ein Senden der Konfigurations-Spezifikation durch das
Fortbewegungsmittel als Antwort auf die Konfigurations-Anfrage des Backend- Servers. Die Konfigurations-Spezifikation kann, wie vorstehend bereits diskutiert, eine Seriennummer einer Fortbewegungsmittelkomponente umfassen.
In einem weiteren Schritt erfolgt ein automatisches Ermitteln einer
Fehlerbehebungsmaßnahme anhand der Konfigurations-Spezifikation und des Fehlerbildes durch den Backend-Server. Der Backend-Server mit kann anderen Worten automatisch Maßnahmen vorschlagen, welche notwendig sind, um das jeweilige Fehlerbild, welches einer jeweiligen Konfiguration bzw. einem Fehlerbild zugeordnet ist, zu adressieren. Beispielsweise können auch mehrere
Fehlerbehebungsmaßnahmen zu einem Fehlerbild, nachdem die Konfigurations- Spezifikation auf dem Backend-Server erhalten wurde, ermittelt werden. Eine Fehlerbehebungsmaßnahme kann entweder selbst den Fehler beheben (z.B. mittels eines Software-Updates) oder Informationen bereitstellen, welche notwendig sind, um den Fehler zu beheben (z.B. das Aufsuchen einer Werkstatt). Eine Fehlerbehebungsmaßnahme kann also als Hilfsmittel oder gar Werkzeug verstanden werden, welches eingerichtet ist, einen Fehler für ein spezifisches Fortbewegungsmittelproblem in Abhängigkeit der Konfiguration des
Fortbewegungsmittels zu beheben. Beispielsweise kommen als
Fehlerbehebungsmaßnahmen Steuergerätetests infrage, welche remote, d.h. über Funk, oder lokal in einer Werkstatt durchgeführt werden können. Zusätzlich oder alternativ kann eine Ermittlung einer Fehlerbehebungsmaßnahme über einen Abgleich möglicher Fehlerbilder anhand der physikalisch verfügbaren Fehlerindikatoren (z.B. elektronische Messdaten und/oder mechanische
Messdaten und/oder Messdaten betreffend eine Gaszusammensetzung und/oder einer Farbe aus Onboard- sowie Offboard-Quellen) erfolgen. Zudem oder alternativ kommt ein Ermitteln der Fehlerbehebungsmaßnahme in Abhängigkeit von Informationen einer Historie infrage, wobei die Historie bekannte
Fehlerbefunde betrifft, welche im Zusammenhang mit der konkreten
Konfigurations-Spezifikation bereits aufgetreten sind. Ferner kann eine Historie für eine relevante Fortbewegungsmittelpopulation definiert werden, wobei die Mitglieder der Fortbewegungsmittelpopulation mindestens ein gemeinsames konfigurationsspezifisches Merkmal aufweisen. Zusätzlich oder alternativ kann eine Fehlerbehebungsmaßnahme in Abhängigkeit einer Rangfolge der
Fehlerbilder in Abhängigkeit eines vordefinierten Übereinstimmungskriteriums ermittelt werden. Beispielsweise kann ein vordefiniertes
Übereinstimmungskriterium einen Übereinstimmungsgrad zwischen Fehlerbild und Fehlerbefund entsprechen. Zusätzlich oder alternativ kann das vordefinierte Übereinstimmungskriterium aufgrund einer vordefinierten Prioritätentabelle definiert sein. Weiterhin oder alternativ kann die Fehlerbehebungsmaßnahme in Abhängigkeit einer kostenoptimierten und/oder zeitoptimierten Reparaturdauer ausgewählt werden. Zusätzlich oder alternativ kann die
Fehlerbehebungsmaßnahme in Abhängigkeit einer
Entdeckungswahrscheinlichkeit des Fehlerbildes ausgewählt werden. Beispielsweise kann ein präventiver Tausch einer
Fortbewegungsmittelkomponente vorgesehen sein, wenn der mit der
Fortbewegungsmittelkomponente assoziierte Fehlerbefund erst wieder nach einer vordefinierten Zeitdauer (z.B. im nächsten Winter) ermittelt würde.
Innerhalb des erfindungsgemäßen Verfahrens kann also
fortbewegungsmittelseitig ein Fehlerbefund erstellt werden. Backend-Serverseitig können diesem Fehlerbefund Fehlerbilder, welche auf dem Backend-Server hinterlegt sind, zugewiesen werden. Allerdings benötigt der Backend-Server weitere spezielle Informationen von dem Fortbewegungsmittel, um dem
Fehlerbild eine Fehlerbehebungsmaßnahme zuweisen zu können und/oder um Fehlerbilder auszuschließen. Hierfür sind den Fehlerbildern Konfigurations- Bedarfe zugewiesen. Aufgrund dieser Konfigurations-Bedarfe wird eine
Konfigurations-Anfrage erstellt, welche dem Fortbewegungsmittel übermittelt wird. Dieses stellt in Abhängigkeit der Konfigurations-Anfrage eine
Konfigurations-Spezifikation zusammen und sendet diese an den Backend- Server. Der Backend-Server kann nun, aufgrund der Konfigurations- Spezifikation, Fehlerbilder ausschließen und/oder aufgrund identifizierter Fehlerbilder eine oder mehrere Fehlerbehebungsmaßnahmen ableiten.
Aufgrund des erfindungsgemäßen Verfahrens kann die Kundenzufriedenheit gesteigert werden, da Reparaturkosten und Zeitaufwand für eine Reparatur gesenkt werden können. Hierbei kann mit nur wenigen Kommunikationszyklen festgestellt werden, welche Fehlerbehebungsmaßnahme für einen Fehlerbefund bzw. ein Fehlerbild des Fortbewegungsmittels notwendig ist. Hierbei können weiterhin Reparaturkosten sowie Gewährleistungskosten für den Endkunden vermieden bzw. gespart werden. Außerdem können Reparaturmaßnahmen, welche ansonsten gar nicht notwendig gewesen wären, vermieden werden.
Somit kann erfindungsgemäß ein Verfahren bereitgestellt werden, wodurch Fehlerbefunde des Fahrzeuges effizienter adressiert werden können.
Die Unteransprüche haben vorteilhafte Ausgestaltung des erfindungsgemäßen Verfahrens zum Inhalt. Gemäß einer vorteilhaften Weiterbildung des erfindungsgemäßen Verfahrens umfasst dieses einen Schritt eines Sendens der Fehlerbehebungsmaßnahme an das Fortbewegungsmittel. Dies kann, wie vorstehend bereits beschrieben, über ein Mobilfunknetz erfolgen. Eine Fehlerbehebungsmaßnahme kann zudem die Nachricht beinhalten, dass der Kunde eine Werkstatt aufsuchen soll. Allerdings kann die Fehlerbehebungsmaßnahme selbst, nachdem sie an das
Fortbewegungsmittel gesendet wurde, einen Fehler beheben. Dies kann z. B. durch die Durchführung eines Software- Updates erfolgen. Somit werden dem Nutzer Werkstattaufenthalte erspart.
Gemäß einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens kann die Fehlerbehebungsmaßnahme ein automatisches Veranlassen eines Software- Updates und/oder ein Feststellen eines Scheinfehlers umfassen. Dies kann beispielsweise hilfreich sein, um zu vermeiden, dass keine Kosten und
Materialressourcen aufgewandt werden, um Fehlern nachzugehen, welche als solche gar nicht existieren.
In einer weiteren vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens wird ein Fehlerbefund aufgrund von On-Board-Diagnose-Daten und/oder Einträgen eines Fehlerspeichers des Fortbewegungsmittels erstellt. Zusätzlich oder alternativ können Fehlerbefunde aufgrund von Daten einer
Fortbewegungsmittel-Sensorik ermittelt werden. Hierbei kann z.B. seitens der Fortbewegungsmittel-Sensorik ermittelt werden, dass ein Reifen geplatzt ist. Der Fahrer kann schnell und effizient eine Fehlerbehebungsmaßnahme erhalten.
Dies kann z.B. die Aufforderung sein, eine Werkstatt aufzusuchen. Zusätzlich oder alternativ kann die Fehlerbehebungsmaßnahme ein Video und/oder eine Anleitung umfassen. Inhalte dieses Videos und/oder dieser Anleitung können beispielsweise eine Vorgehensweise bezüglich des Fehlerbefundes und/oder eine Anweisung zur Vornahme weiterer Schritte beinhalten. Beispielsweise kann die Fehlerbehebungsmaßnahme auch eine
fortbewegungsmittelmodellspezifische Anweisung enthalten, welche Werkzeuge und/oder Ersatzteile benötigt werden. Mit anderen Worten kann das
Fortbewegungsmittel durch eine eigene Diagnose einen Fehlerbefund erstellen und Daten repräsentierend diesen Fehlerbefund an den Backend-Server senden. Auf diese Weise kann eine Fehlerbehebungsmaßnahme, welche ansonsten nur in einer Werkstatt möglich wäre, ohne die Notwendigkeit, (zunächst) eine
Werkstatt aufzusuchen, effizient initiiert und kommuniziert werden.
Gemäß einer vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens betrifft die Konfigurations-Spezifikation, welche das Ermitteln einer
Fehlerbehebungsmaßnahme vereinfacht, eine Art der
Fortbewegungsmittelkomponente, z. B. eine Batterie, und/oder eine Position der Fortbewegungsmittelkomponente, z. B. innerhalb des Motorraums, und/oder einen Betriebszustand der Fortbewegungsmittelkomponente, z. B. aktiviert und/oder nicht aktiviert, und/oder ein Baujahr der
Fortbewegungsmittelkomponente und/oder eine Seriennummer der
Fortbewegungsmittelkomponente. Durch eine derartige Konfigurations- Spezifikation ist vorliegend sichergestellt, dass dem Fehlerbefund ein möglichst geringer Umfang von Fehlerbildern und somit auch eine möglichst eindeutige Fehlerbehebungsmaßnahme zugeordnet werden kann. Somit kann die
Konfigurations-Spezifikation als ein Filter verstanden werden, wodurch letztlich Rechenleistung zur Identifikation einer Fehlerbehebungsmaßnahme eingespart werden kann.
Gemäß einer weiteren vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens kann das Backend-Server-seitige Fehlerbild eine Fehlfunktion eines Teils des Fortbewegungsmittels und/oder eine Nicht-Funktion eines Teils eines Fortbewegungsmittels und/oder eine Temperaturanomalie eines Teils eines Fortbewegungsmittels und/oder einen Softwarefehler eines
Fortbewegungsmittels betreffen. Mit anderen Worten können jegliche
Fehlerbefunde betreffend die On-Board-Diagnose und/oder Einträge des
Fehlerspeichers und/oder Sensoren des Fahrzeuges mit den Fehlerbildern auf dem Backend-Server assoziiert werden. Mit anderen Worten ist also das
Fehlerbild auf einer Datenbank des Backend-Servers spezifiziert. Dem Fehlerbild sind Konfigurations-Bedarfe zugewiesen, welche durch den Backend-Server über eine Konfigurations-Anfrage, die an das Fortbewegungsmittel gesendet wird, erfragen kann. Das Fortbewegungsmittel kann eine Konfigurations-Spezifikation in Abhängigkeit dieser Anfrage erstellen und an den Backend-Server senden. Somit werden die Konfigurations-Bedarfe beantwortet und das Fehlerbild kann identifiziert werden. Zu dem identifizierten Fehlerbild existieren
Fehlerbehebungsmaßnahmen, welche durch den Backend-Server im Anschluss an das Identifizieren des Fehlerbildes vorschlagen kann.
Gemäß einer weiteren vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens umfasst dieses die Schritte eines Anzeigens einer Auswahl vordefinierter Fehlerbefunde, z. B.„Batterie lädt nicht vollständig“, auf einer Anzeigeeinheit, z. B. einem Head-Up-Display und/oder einem Kombiinstrument und/oder einem zentralen Informationsdisplay. Hierbei kann ein Anwender, beispielsweise ein Mitarbeiter bei einer Werkstatt und/oder ein Fahrer eines Fahrzeuges eine Auswahl aus vordefinierten Fehlerbefunden treffen. Dies kann in Form einer Anwendereingabe, z.B. haptisch und/oder akustisch und/oder mittels einer Anwendergeste erfolgen. Im Ansprechen darauf erfolgt ein Erstellen eines Fehlerbefundes in Abhängigkeit des vordefinierten Fehlerbefundes, welcher durch den Anwender ausgewählt wurde. Auf diese Art wird dem
Anwender eine intuitive und einfache Möglichkeit bereitgestellt, mit dem
Backend-Server bzw. mit dem Fahrzeug zu interagieren, um einen Fehlerbefund zu versenden.
Gemäß einer weiteren vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens können mehrere Fehlerbilder jeweilige Fehlerbehebungsmaßnahmen aufweisen. Beispielsweise können ein Software-Update sowie ein Feststellen eines Scheinfehlers in der Fehlerbehebungsmaßnahme bezüglich desselben Fehlerbildes vorgesehen sein, wobei die jeweiligen Konfigurations-Bedarfe eine Anfrage bezüglich einer Seriennummer eines in dem Fahrzeug verwendeten Prozessors und eines in dem Fahrzeug verwendeten Speichers, welcher mit dem Prozessor verbunden ist, betreffen können. Zusätzlich oder alternativ kann ein Scheinfehler aufgrund einer Fehldiagnose auftreten, wobei die Fehldiagnose aufgrund einer installationsbedingten Toleranzlage einer
Fortbewegungsmittelkomponente zustande kommt. Beispielsweise kann ein fehlerhaft montierter Türkontakt eine Meldung des Fortbewegungsmittelsystems verursachen, dass die Türe offen ist, obwohl die Türe in der Realität geschlossen ist. Beispielsweise könnte ein Software-Update diese fehlerhafte Toleranzlage durch eine Rekalibrierung der Türkontaktschwelle ausgleichen, um somit künftig die Häufigkeit von Fehldiagnosen zu minimieren.
Insbesondere werden die Fehlerbehebungsmaßnahmen aus mehreren
Fehlerbehebungsmaßnahmen aufgrund der Konfigurations-Spezifikationen des Fortbewegungsmittels ausgewählt. Somit kann Zeit zur
Fehlerbehebungsmaßnahmenermittlung eingespart werden. Dies hat auch ein Einsparen von Rechenleistung des Backend-Servers zur Folge.
Die folgenden erfindungsgemäßen Aspekte weisen die vorteilhaften
Ausgestaltungen und Weiterbildungen mit den wie vorstehend genannten Merkmalen sowie die generellen Vorteile des erfindungsgemäßen Verfahrens und die jeweils damit verbundenen technischen Effekte entsprechend auf. Zur Vermeidung von Wiederholungen wird deshalb auf eine erneute Aufzählung verzichtet.
Gemäß einem zweiten Aspekt betrifft die vorliegende Erfindung ein
Fortbewegungsmittel, welches eingerichtet ist, einen Fehlerbefund festzustellen. Im Ansprechen darauf kann das Fortbewegungsmittel eine Nachricht betreffend den Fehlerbefund an einen Backend-Server senden. Weiterhin ist das
Fortbewegungsmittel eingerichtet, eine Konfigurations-Anfrage als Antwort auf die Nachricht des Fehlerbefundes zu empfangen. Überdies ist das
Fortbewegungsmittel eingerichtet, eine Konfigurations-Spezifikation in
Abhängigkeit der Konfigurations-Anfrage zu erstellen und als Antwort auf die Konfigurations-Anfrage an den Backend-Server zu senden. Schließlich kann das Fortbewegungsmittel eine Fehlerbehebungsmaßnahme als Antwort auf die Konfigurations-Spezifikation empfangen und durchführen. Dies kann
beispielsweise mithilfe einer Auswerteeinheit, z. B. einer CPU und/oder eines Mikrocontrollers und/oder eines elektronischen Steuergeräts, erfolgen.
Gemäß einem dritten Aspekt betrifft das erfindungsgemäße Verfahren einen Backend-Server. Der Backend-Server kann (automatisch) einen Fehlerbefund von einem Fortbewegungsmittel empfangen. Weiterhin kann der Backend-Server automatisch nach Fehlerbildern, welche zu diesem Fehlerbefund passen, suchen und in Abhängigkeit dessen einen jeweiligen Konfigurations-Bedarf ermitteln.
Eine Konfigurations-Anfrage repräsentierend eine Vereinigungsmenge der jeweiligen Konfigurations-Bedarfe können automatisch ermittelt und an das Fortbewegungsmittel gesendet werden. Weiterhin kann eine Konfigurations- Spezifikation als Antwort auf die Konfigurations-Anfrage auf dem Backend-Server empfangen werden und schließlich eine Fehlerbehebungsmaßnahme anhand der Konfigurations-Spezifikation automatisch ermittelt werden.
Gemäß einem vierten Erfindungsaspekt betrifft die vorliegende Erfindung ein System umfassend ein Fortbewegungsmittel gemäß dem zweiten
Erfindungsaspekt sowie einen Backend-Server gemäß dem dritten
Erfindungsaspekt. Beispielsweise kann zwischen dem Backend-Server und dem Fortbewegungsmittel eine elektronische Dienstleistungs-Schnittstelle, z. B. ein PC, zwischengeschaltet sein, welche die verfahrensgemäßen Schritte, welche seitens des Fortbewegungsmittels vorzunehmen sind, unterstützt. Beispielsweise kann mittels des PCs bei einer besonders komplizierten Reparatur innerhalb einer Dienstleistungsinstitution ein vordefinierter Fehlerbefund mittels des PC eingegeben werden. Ein derartiger vordefinierter Fehlerbefund kann dann an den Backend-Server gesendet werden. Eine elektronische
Dienstleistungsinstitutionsschnittstelle kann zudem auch eine mobile Einheit darstellen. Somit ist es aufgrund des erfindungsgemäßen Verfahrens auch für Dienstleistungsinstitutionen, z. B. Werkstätten, einfach, eine kostengünstige und effiziente Reparaturmaßnahme zu erhalten.
Weitere Einzelheiten, Merkmale und Vorteile der Erfindung ergeben sich aus der nachfolgenden Beschreibung und den Figuren. Es zeigen:
Figur 1 eine Variante des erfindungsgemäßen Systems;
Figur 2 ein Flussdiagramm gemäß einer Variante des erfindungsgemäßen
Verfahrens; und
Figur 3 eine Illustration einer Interaktion zwischen dem erfindungsgemäßen
Fortbewegungsmittel und dem erfindungsgemäßen Backend-Server. Figur 1 zeigt eine Variante des erfindungsgemäßen Systems 10 umfassend eine Dienstleistungsinstitution 2, eine Fortbewegungsmittelflotte aufweisend erste bis vierte Fortbewegungsmittel 1a - 1d sowie einen Backend-Server 3. Die
Fortbewegungsmittel 1a - 1d der Fortbewegungsmittelflotte sind eingerichtet, Kundenfahrzeugservicedaten (betreffend Reparaturen und/oder Pannenfälle) und Diagnosedaten an den Backend-Server 3 zu senden, welcher diese Daten einpflegen kann. Insbesondere kann der Backend-Server 3 also Fehlerbilder F1 - F6 von verschiedenen Fortbewegungsmitteln 1a - 1d sammeln. Allerdings können derartige Daten auch seitens einer Forschungs- bzw.
Entwicklungsabteilung auf den Backend-Server 3 übertragen werden. In dem in Figur 1 gezeigten Szenario muss das zweite Fortbewegungsmittel 1 b der Fortbewegungsmittelflotte eine Werkstatt aufsuchen. Seitens der Werkstatt werden über dem Pfeil B Fehlerbefunde FB an den Backend-Server 3 gesendet. Der Backend-Server 3 kann, was später genauer ausgeführt wird, ein Fehlerbild F1 - F6 in Abhängigkeit des Fehlerbefundes FB ermitteln. Weiterhin kann der Backend-Server 3 Daten als Antwort an das Fortbewegungsmittel 1 b senden, was durch den Pfeil 6 illustriert ist.
Figur 2 zeigt ein Flussdiagramm gemäß einer Variante des erfindungsgemäßen Verfahrens. In einem ersten Schritt 100 erfolgt ein Empfangen eines
Fehlerbefundes FB von dem Fortbewegungsmittel 1b auf dem Backend-Server 3. Der Fehlerbefund FB betrifft hierbei Einträge des Fehlerspeichers, wobei der Fehlerspeicher aufgezeichnet hat, dass sich eine Anzeigeeinheit des
Fortbewegungsmittels 1b automatisch ausschaltet. In einem zweiten Schritt 200 erfolgt ein automatisches Ermitteln eines auf dem Backend-Server 3 hinterlegten Fehlerbildes F1 - F6 in Abhängigkeit des Fehlerbefundes FB. Beispielsweise ist das Fehlerbild F1 - F6, betreffend die Situation, dass sich die Anzeigeeinheit automatisch ausschaltet, auf dem Backend-Server 3 hinterlegt. Um eine eindeutige Fehlerbehebungsmaßnahme M1 - M6 identifizieren zu können, benötigt der Backend-Server 3 jedoch weitere Konfigurationsdaten des
Fortbewegungsmittels 1b. In einem dritten Schritt 300 erfolgt daher ein automatisches Ermitteln eines Konfigurations-Bedarfs K1-K5 in Abhängigkeit des hinterlegten Fehlerbildes F1 - F6. Beispielsweise können mehrere Konfigurations-Bedarfe K1-K5 für zwei Fehlerbilder F1 und F2 vorhanden sein. Beispielsweise kann dem Fehlerbild F1 ein Konfigurations-Bedarf K1 zugewiesen sein, wobei eine Seriennummer der Anzeigeeinheit des Fortbewegungsmittels 1b für die weitere Analyse erforderlich ist. Dem zweiten Fehlerbild F2 kann ein Konfigurations-Bedarf K2 zugeordnet sein, welcher besagt, dass eine aktuelle Software-Version, durch welche die Anzeigeeinheit des Fortbewegungsmittels 1 b betrieben wird, abgefragt werden muss. Dementsprechend erfolgt in einem vierten Schritt 400 ein automatisches Erstellen und Senden einer Konfigurations- Anfrage repräsentierend die Vereinigungsmenge der Konfigurations-Bedarfe K1 , K2, welche besagt, dass eine Seriennummer der Anzeigeeinheit benötigt wird sowie dass eine Software-Version der Anzeigeeinheit benötigt wird, an das Fortbewegungsmittel 1b. Das Fortbewegungsmittel 1 b erstellt daraufhin eine Konfigurations-Spezifikation A umfassend eine Seriennummer der Anzeigeeinheit und eine Software-Version der Anzeigeeinheit. Im Ansprechen darauf wird die Konfigurations-Spezifikation A in einem fünften Schritt 500 als Antwort an den Backend-Server 3 gesendet und von diesem empfangen. Auf dem Backend- Server 3 wird in einem sechsten Schritt 600 ein automatisches Ermitteln einer Fehlerbehebungsmaßnahme M1 - M6 anhand der Konfigurations-Spezifikation A durchgeführt. Hierbei wird festgestellt, dass die Seriennummer, welche durch das Fortbewegungsmittel 1b gesendet wurde, nicht der Fehlerbehebungsmaßnahme M1 , welche für das erste Fehlerbild FB1 vorgesehen ist, zugewiesen ist. Somit kann dieses Fehlerbild FB1 ausgeschlossen werden. Allerdings entspricht die Softwareversion in Verbindung mit dem Fehlerbild FB2 einer spezifischen Fehlerbehebungsmaßnahme M2, welche ein Software- Update der Software, welche die Anzeigeeinheit betreibt, vorsieht. Entsprechend wird in einem siebten Schritt 700 erfolgt ein Senden der Fehlerbehebungsmaßnahme M2 an das Fortbewegungsmittel 1b. Hierbei wird ein Software- Update auf dem
Fortbewegungsmittel 1b durchgeführt, womit der Fehler behoben ist.
Figur 3 illustriert die soeben erläuterten Schritte des erfindungsgemäßen
Verfahrens in verallgemeinerter Form. Hierbei zeigt Figur 3 ein
Fortbewegungsmittel 1a sowie einen Backend-Server 3. Der Backend-Server 3 umfasst eine Fehlerbildergruppe Fx, eine Konfigurations-Bedarfsgruppe Kx sowie eine Fehlerbehebungsmaßnahmengruppe Mx. Jede dieser Gruppen umfasst entsprechend Fehlerbilder F1 - F6, Konfigurations-Bedarfe K1 - K5 sowie Fehlerbehandlungsmaßnahmen M1 - M6. Hierbei sendet das
Fortbewegungsmittel 1a zunächst einen Fehlerbefund FB an den Backend- Server 3. Für den Fehlerbefund FB werden drei Fehlerbilder F1 , F2 und F4 ermittelt, welche für den Fehlerbefund FB infrage kommen. Diese Fehlerbilder F1 , F2, F4 sind wiederum jeweils den Konfigurations-Bedarfen K1 , K3, K4 und K5 zugewiesen. Diese Konfigurations-Bedarfe K1 , K3, K4 und K5 werden benötigt, um für die entsprechenden Fehlerbilder F1 , F2 und F4 eine
Fehlerbehebungsmaßnahme M1 - M6 aus der
Fehlerbehebungsmaßnahmengruppe Mx zu finden. Die Konfigurations-Bedarfe K1 , K3, K4 und K5 werden, wie oberhalb des entsprechenden Pfeils illustriert, an das Fortbewegungsmittel gesendet. Das Fortbewegungsmittel ermittelt im Ansprechen darauf die angefragte Konfigurations-Spezifikation A. Im Ansprechen darauf wird durch das Fortbewegungsmittel eine Konfigurations-Spezifikation A an den Backend-Server 3 gesendet. Aufgrund der Konfigurations-Spezifikation können die Fehlerbilder F1 und F2 als Fehlerbilder ausgeschlossen werden. Somit werden für das Fehlerbild F4 bezüglich der Konfigurations-Bedarfe K4 und K5 die Fehlerbehebungsmaßnamen M1 und M2 an das Fortbewegungsmittel 1a gesendet, was durch den Briefumschlag und den damit korrespondierenden, auf das Fortbewegungsmittel 1a deutenden Pfeil illustriert ist.
Bezugszeichenliste:
1a-1d Fortbewegungsmittel
2 Dienstleistungsinstitution
3 Backend-Server
4 Anonymisierung
5 Anfrage
6 Antwort
10 System
100-700 Verfahrensschritte
A Konfigurations-Spezifikation
F1-F6 Fehlerbild
Fx Fehlerbildergruppe
K1-K6 Konfigurations-Bedarf
Kx Konfigurations-Bedarfsgruppe
M1-M6 Fehlerbehebungsmaßnahme
Mx Fehlerbehebungsmaßnahmengruppe

Claims

Patentansprüche:
1. Verfahren zum ferngesteuerten Handhaben eines Fehlerbefundes (FB) eines Fortbewegungsmittels (1a-1d) umfassend die Schritte:
• Empfangen (100) des Fehlerbefundes (FB) von dem
Fortbewegungsmittel (1a-1d) auf einem Backend-Server (3);
• automatisches Ermitteln (200) eines auf dem Backend-Server (3)
hinterlegten Fehlerbildes (F1-F6) in Abhängigkeit des Fehlerbefundes (FB), im Ansprechen darauf
• automatisches Ermitteln (300) eines Konfigurations-Bedarfs (K1-K6) in Abhängigkeit des hinterlegten Fehlerbildes (F1-F6);
• automatisches Erstellen (400) und Senden einer Konfigurations-Anfrage repräsentierend eine Vereinigungsmenge der jeweiligen Konfigurations- Bedarfe (K1-K6) an das Fortbewegungsmittel (1a-1d);
• Empfangen (500) einer Konfigurations-Spezifikation (A) als Antwort auf die Konfigurations-Anfrage auf dem Backend-Server (3); und
• automatisches Ermitteln (600) einer Fehlerbehebungsmaßnahme (M1- M6) anhand der Konfigurations-Spezifikation (A) durch den Backend- Server (3).
2. Verfahren nach Anspruch 1 ferner umfassend den Schritt eines Sendens (700) der Fehlerbehebungsmaßnahme (M1-M6) an das
Fortbewegungsmittel (1a-1d).
3. Verfahren nach Anspruch 1 oder 2, wobei die Fehlerbehebungsmaßnahme (M1-M6) ein automatisches Veranlassen eines Softwareupdates und/oder ein automatisches Feststellen eines Scheinfehlers umfasst.
4. Verfahren nach einem der vorstehenden Ansprüche, wobei der
Fehlerbefund (FB) aufgrund von On-Board-Diagnose-Daten und/oder Einträgen eines Fehlerspeichers erstellt und/oder mittels einer
Fortbewegungsmittel-Sensorik ermittelt wird.
5. Verfahren nach einem der vorstehenden Ansprüche, wobei die
Konfigurations-Spezifikation (A)
• eine Art einer Fortbewegungsmittelkomponente und/oder
• eine Position der Fortbewegungsmittelkomponente und/oder
• einen Betriebszustand der Fortbewegungsmittelkomponente
und/oder
• ein Baujahr der Fortbewegungsmittelkomponente und/oder
• eine Seriennummer der Fortbewegungsmittelkomponente betrifft.
6. Verfahren nach einem der vorstehenden Ansprüche, wobei das Fehlerbild (F1-F6)
• eine Fehlfunktion eines Teils des Fortbewegungsmittels und/oder
• eine Nichtfunktion des Teils des Fortbewegungsmittels und/oder
• eine Temperaturanomalie des Teils des Fortbewegungsmittels und/oder
• einen Softwarefehler des Fortbewegungsmittels
betrifft.
7. Verfahren nach einem der vorstehenden Ansprüche ferner umfassend die Schritte:
• Anzeigen einer Auswahl vordefinierter Fehlerbefunde auf einer Anzeigeeinheit, im Ansprechen darauf
• Empfangen einer Anwendereingabe zur Auswahl der vordefinierten Fehlerbefunde, im Ansprechen darauf
• Erstellen des Fehlerbefundes (FB) in Abhängigkeit des ausgewählten vordefinierten Fehlerbefundes.
8. Verfahren nach einem der vorstehenden Ansprüche, wobei mehrere Fehlerbilder (F1-F6) mit den jeweiligen Konfigurations-Bedarfen (K1-K6) mehrere Fehlerbehebungsmaßnahmen (M1-M6) aufweisen.
9. Fortbewegungsmittel (1a-1d), welches eingerichtet ist,
• einen Fehlerbefund (FB) festzustellen,
• eine Nachricht betreffend den Fehlerbefund (FB) an einen Backend- Server (3) zu senden,
• eine Konfigurations-Anfrage als Antwort auf die Nachricht des
Fehlerbefundes (FB) zu empfangen,
• eine Konfigurations-Spezifikation (A) in Abhängigkeit der Konfigurations- Anfrage zu erstellen und als Antwort auf die Konfigurations-Anfrage an den Backend-Server (3) zu senden und
• eine Fehlerbehebungsmaßnahme (M1-M6) als Antwort auf die
Konfigurations-Spezifikation (K1-K6) zu empfangen.
10. Backend-Server (3), welcher eingerichtet ist,
• automatisch einen Fehlerbefund (FB) von einem Fortbewegungsmittel (1a-1d) zu empfangen,
• automatisch nach Fehlerbildern (F1-F6), welche zu dem Fehlerbefund (FB) passen, zu suchen und in Abhängigkeit dessen einen jeweiligen Konfiguration-Bedarf (K1-K6) zu ermitteln,
• eine Konfigurations-Anfrage repräsentierend eine Vereinigungsmenge der jeweiligen Konfigurations-Bedarfe (K1-K6) automatisch zu erstellen und an das Fortbewegungsmittel (1 a-1 d) zu senden,
• eine Konfigurations-Spezifikation (A) als Antwort auf die Konfigurations- Anfrage zu empfangen, und
• eine Fehlerbehebungsmaßnahme (M1-M6) anhand der Konfigurations- Spezifikation (K1-K6) automatisch zu ermitteln.
11. System (10) umfassend ein Fortbewegungsmittel (1a-1d) nach Anspruch 9 und einen Backend-Server (3) nach Anspruch 10.
PCT/DE2019/100921 2018-12-18 2019-10-24 Verfahren zum ferngesteuerten handhaben eines fehlerbefundes eines fortbewegungsmittels, fortbewegungsmittel, backend-server und system WO2020125844A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201980081166.1A CN113168593A (zh) 2018-12-18 2019-10-24 用于以远程控制的方式处理行进工具的故障发现的方法、行进工具、后端服务器以及系统
US17/415,753 US12001272B2 (en) 2018-12-18 2019-10-24 Method for the remote-controlled handling of an error finding in a means of transport, means of transport, backend server and system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102018132685.8 2018-12-18
DE102018132685.8A DE102018132685A1 (de) 2018-12-18 2018-12-18 Verfahren zum ferngesteuerten Handhaben eines Fehlerbefundes eines Fortbewegungsmittels, Fortbewegungsmittel, Backend-Server und System

Publications (1)

Publication Number Publication Date
WO2020125844A1 true WO2020125844A1 (de) 2020-06-25

Family

ID=68426056

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2019/100921 WO2020125844A1 (de) 2018-12-18 2019-10-24 Verfahren zum ferngesteuerten handhaben eines fehlerbefundes eines fortbewegungsmittels, fortbewegungsmittel, backend-server und system

Country Status (3)

Country Link
CN (1) CN113168593A (de)
DE (1) DE102018132685A1 (de)
WO (1) WO2020125844A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008022771A1 (de) 2007-06-22 2008-12-24 Lear Corp., Southfield Verfahren und System zum Übertragen von Fahrzeug-Diagnosedaten zu einem Internet-Server über ein Bluetooth-fähiges Mobiltelefon zum anschließenden Abrufen
US8676432B2 (en) 2010-01-13 2014-03-18 GM Global Technology Operations LLC Fault prediction framework using temporal data mining

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020007237A1 (en) * 2000-06-14 2002-01-17 Phung Tam A. Method and system for the diagnosis of vehicles
GB2366407A (en) * 2000-08-31 2002-03-06 Trw Ltd Remote diagnosis of faults in vehicles
JP2004005169A (ja) * 2002-05-31 2004-01-08 Honda Motor Co Ltd 製品問診装置及び製品問診方法
US7913242B2 (en) * 2003-11-04 2011-03-22 Gm Global Technology Operations, Inc. Low cost, open approach for vehicle software installation/updating and on-board diagnostics
US20060271255A1 (en) * 2004-12-30 2006-11-30 Teradyne, Inc. System and method for vehicle diagnostics and prognostics
US7519458B2 (en) * 2005-07-08 2009-04-14 Snap-On Incorporated Vehicle diagnostics
DE102005048337B4 (de) * 2005-10-10 2022-12-15 Robert Bosch Gmbh Verfahren zur Erhaltung und Anpassung von Betriebsfunktionen eines Kraftfahrzeugs
WO2008140363A1 (en) * 2007-05-14 2008-11-20 Volvo Technology Corporation Remote diagnosis modellin
KR20090005457A (ko) * 2007-07-09 2009-01-14 현대자동차주식회사 지능형 자기진단코드 모니터링 시스템 및 방법
US8407158B2 (en) * 2008-09-19 2013-03-26 Verizon Patent And Licensing Inc. System and method for providing interactive troubleshooting
JP5678717B2 (ja) * 2011-02-24 2015-03-04 富士通株式会社 監視装置、監視システムおよび監視方法
EP2737457B1 (de) * 2011-07-26 2019-11-20 United Parcel Service Of America, Inc. Systeme und verfahren zur verwaltung von fehlercodes
CN102830690B (zh) * 2012-05-04 2014-07-30 王蓉 一种汽车故障数据的数据处理系统
US8924071B2 (en) * 2013-04-26 2014-12-30 Ford Global Technologies, Llc Online vehicle maintenance
CN103198156A (zh) * 2013-04-27 2013-07-10 深圳市元征科技股份有限公司 汽车维修资料查询、反馈方法及服务器
DE102015214739B4 (de) * 2015-08-03 2022-12-29 Volkswagen Aktiengesellschaft Verfahren zur Bestimmung einer Fehlerursache bei einem Fahrzeug und Server zum Durchführen der Bestimmung der Fehlerursache

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008022771A1 (de) 2007-06-22 2008-12-24 Lear Corp., Southfield Verfahren und System zum Übertragen von Fahrzeug-Diagnosedaten zu einem Internet-Server über ein Bluetooth-fähiges Mobiltelefon zum anschließenden Abrufen
US8676432B2 (en) 2010-01-13 2014-03-18 GM Global Technology Operations LLC Fault prediction framework using temporal data mining

Also Published As

Publication number Publication date
US20220083411A1 (en) 2022-03-17
DE102018132685A1 (de) 2020-06-18
CN113168593A (zh) 2021-07-23

Similar Documents

Publication Publication Date Title
DE102015214739B4 (de) Verfahren zur Bestimmung einer Fehlerursache bei einem Fahrzeug und Server zum Durchführen der Bestimmung der Fehlerursache
DE102011008211B4 (de) Fahrzeugfehlerdiagnose- und Fahrzeugfehlerprognosesystem und Verfahren zur Fehlerdiagnose und Fehlerprognose
DE102014105674A1 (de) Online-fahrzeugwartung
DE102012220338A1 (de) Reparaturunterstützungssystem für eine Fahrzeugwartung
DE102010052855A1 (de) Detektieren von Abweichungen bei Feldausfalldaten
DE112009000439T5 (de) Fahrzeuginformationsaufzeichnungsvorrichtung, Fahrzeuginformationskommunikationssystem und Fahrzeuginformationskommunikationsverfahren
DE102010052998A1 (de) Software-zentrierte Methodik für die Überprüfung und Bestätigung von Fehlermodellen
EP2013060A1 (de) Diagnosesystem mit wlan übertragungsmodul und implementiertem diagnosekurztest
EP3907707A1 (de) Verfahren und diagnosevorrichtung zum durchführen einer fahrzeugdiagnose
DE10323390A1 (de) Telediagnose-Viewer
DE102018209773A1 (de) Verfahren zur rechnergestützten Bestimmung einer Fehlerdiagnose eines Fahrzeugs
DE102014219407A1 (de) Diagnoseverfahren und Erhebungsverfahren für Fahrzeuge
WO2007022849A2 (de) Verfahren zur identifikation komplexer diagnosesituationen im kundendienst
DE102015218262A1 (de) Datenverarbeitungsanlage und Verfahren für diese zur Zustandsüberwachung einer Mehrzahl an Fahrzeugen
DE102010054041A1 (de) Gewinnungsmethodologie zum Beseitigen eines ungeeigneten Setzens von Defektbedingungen unter Verwendung von Betriebsparametern
DE102020108861A1 (de) Verfahren zum Ermitteln eines Zustands eines Bauteils
DE102010005742A1 (de) Integriertes Diagnose- und Prognosesystem als Teil der Unternehmenswertschöpfungskette
WO2020125844A1 (de) Verfahren zum ferngesteuerten handhaben eines fehlerbefundes eines fortbewegungsmittels, fortbewegungsmittel, backend-server und system
DE102020123228A1 (de) Verfahren zum Betreiben einer Gerätefunktion, insbesondere eines Kraftfahrzeugss
DE102021114087A1 (de) Selektive Meldesysteme für Funktionszustandsinformationen, die integrierte Diagnosemodelle enthalten, die Informationen über die geringst- und höchstmögliche Ursache bereitstellen
DE102015214987B4 (de) Bestimmung eines defekten Bauteils eines Fahrzeugs
DE10315344B4 (de) Verfahren und Vorrichtung zur Erkennung fehlerhafter Komponenten in Fahrzeugen
WO2021185586A1 (de) Verfahren zur erzeugung von trainingsdaten, fahrzeug und trainingssystem
DE102009033806A1 (de) Verfahren zur Fertigung und Prüfung der Funktionalität in der Fertigung
DE102020107528A1 (de) System zur Fehler-Diagnose und/oder Fehler-Prognose in Kraftfahrzeugen

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19797555

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 19797555

Country of ref document: EP

Kind code of ref document: A1