WO2024256064A1 - Verfahren zum beheben eines fehlerbehafteten zustands einer kommunikationseinrichtung eines fahrzeugs, computerprogramm, vorrichtung und fahrzeug - Google Patents

Verfahren zum beheben eines fehlerbehafteten zustands einer kommunikationseinrichtung eines fahrzeugs, computerprogramm, vorrichtung und fahrzeug Download PDF

Info

Publication number
WO2024256064A1
WO2024256064A1 PCT/EP2024/060467 EP2024060467W WO2024256064A1 WO 2024256064 A1 WO2024256064 A1 WO 2024256064A1 EP 2024060467 W EP2024060467 W EP 2024060467W WO 2024256064 A1 WO2024256064 A1 WO 2024256064A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
data
communication device
faulty state
user terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2024/060467
Other languages
English (en)
French (fr)
Inventor
David Gozalvez Serrano
Joachim Metzger
Hendrik Schweppe
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bayerische Motoren Werke AG
Original Assignee
Bayerische Motoren Werke AG
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 AG filed Critical Bayerische Motoren Werke AG
Priority to CN202480032960.8A priority Critical patent/CN121153243A/zh
Publication of WO2024256064A1 publication Critical patent/WO2024256064A1/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Definitions

  • Embodiments of the present invention relate to methods for correcting a faulty state of a communication device of a vehicle, a computer program, a device and a vehicle, in particular but not exclusively to a concept for sending process data for carrying out a process for correcting the faulty state of the communication device.
  • a problem in the area of a communication link of a communication device for example an Internet connectivity, which prevents or impairs the connection of a communication device of a vehicle with a backend system, for example a backend system of a vehicle manufacturer, is usually dealt with with corrective actions.
  • a corrective action may trigger a reset of the communication link or the communication device of the vehicle after the detection of a problem.
  • a corrective action requires the detection of the problem on the vehicle side.
  • a corrective action by a vehicle side may not be sufficient to re-establish the communication link.
  • a problem with a vehicle's communication device can be analyzed and resolved by visiting a workshop.
  • direct access can be gained to the vehicle's electrical system and thus to every system and communication device in the vehicle, for example via a vehicle diagnostic socket.
  • solving a problem in a workshop increases the workload for the vehicle user.
  • Embodiments are based on the core idea that a method for correcting a faulty state of a communication device of a vehicle can be carried out based on process data.
  • the process data are indicative of a process to be carried out by the vehicle to correct the faulty state of the Communication device.
  • the process data is obtained based on vehicle log data.
  • the vehicle can receive information for rectifying the faulty state of the communication device.
  • the vehicle or a control unit of the vehicle can rectify the fault.
  • Embodiments relate to a method for implementation by a user terminal for correcting a faulty state of a communication device of a vehicle.
  • the method comprises receiving vehicle log data indicative of the faulty state of the communication device.
  • the vehicle log data is received at the user terminal from the vehicle, for example from the communication device or another communication device of the vehicle.
  • the method further comprises obtaining process data indicative of a process to be implemented by the vehicle for correcting the faulty state of the communication device based on the vehicle log data.
  • the method further comprises sending the process data for implementing the process for correcting the faulty state of the communication device.
  • the process data is sent to the vehicle, for example the communication device or another communication device of the vehicle.
  • process data can then be obtained, for example received from a backend, which includes information for correcting the faulty state of the communication device.
  • the vehicle can receive this information to correct the faulty state of the communication device. This means that the faulty state of the communication device can be corrected without having to visit a workshop and without the need for a communication connection between the vehicle and a backend.
  • the method may further comprise sending malfunction data indicative of the faulty state of the communication device.
  • the malfunction data is sent to a backend.
  • the process data can be obtained at the user terminal by receiving the process data from the backend.
  • the process data is received for sending to the vehicle.
  • the user terminal can receive the information required to rectify the faulty state of the communication device with increased reliability.
  • the backend can identify a plurality of faulty states of the communication device based on the malfunction data.
  • a probability that the backend Process data for correcting the faulty state of the communication device may be increased compared to the user terminal.
  • the method may further comprise receiving fault data indicative of a fault in a communication connection of the communication device.
  • the method may further comprise establishing a communication connection between the user terminal and the vehicle, for example the communication device or another communication device of the vehicle, for receiving the vehicle log data in response to receiving the fault data.
  • Receiving the fault data can trigger a rectification of the faulty state of the communication device.
  • a user can determine a faulty communication connection of the communication device. The user can then make an input on the user terminal. Based on the input, the fault data can be determined.
  • a communication connection for receiving the vehicle log data can then be established as needed. This allows an exchange of information between the user terminal and the vehicle to take place if necessary.
  • the method may further comprise sending start data indicative of starting storage of vehicle log data.
  • the start data is sent to the vehicle, for example the communication device or another communication device of the vehicle. Sending the start data can trigger storage of the vehicle log data. This can in particular prevent unnecessary storage of vehicle log data.
  • the method may further comprise receiving verification data indicative of a verification required to receive the vehicle log data.
  • the verification data is received at the user terminal from the backend.
  • the method may further comprise sending the verification data to the vehicle for receiving the vehicle log data.
  • the verification data may be used to prove authorization of the user terminal to receive the vehicle log data.
  • the vehicle log data may be confidential.
  • the vehicle log data may only be sent to an authorized backend.
  • the method may further comprise determining the malfunction data to send to the backend based on the vehicle log data. By determining the malfunction data, data transfer between the backend and the user terminal may be reduced.
  • the method may further comprise storing the vehicle log data and determining a communication connection type with the backend.
  • the method may further comprise sending the vehicle log data depending on the determined communication connection type. This allows a data transfer between the backend and the user terminal to be adapted to an available data volume.
  • the method may further comprise sending chat data indicative of a user request from the user terminal.
  • the chat data is sent to the backend.
  • the method may further comprise receiving further chat data indicative of a response to the user request from the user terminal from the backend.
  • Embodiments relate to a method for implementation by a control unit of a vehicle to correct a faulty state of the communication device.
  • the method includes sending, to a user terminal, vehicle log data indicative of the faulty state of the communication device.
  • the method also includes receiving, from the user terminal, process data indicative of a process to be implemented by the vehicle to correct the faulty state of the communication device.
  • the method also includes implementing the process to correct the faulty state of the communication device based on the process data. This enables the vehicle or the control unit to correct a faulty state of the communication device without an external connection to a backend or a visit to a workshop.
  • Embodiments also provide a computer program for performing any of the methods described herein when the computer program runs on a computer, a processor, or a programmable hardware component.
  • a further embodiment is a device for correcting a faulty state of a communication device of a vehicle.
  • the device comprises an interface for communication with a control unit or a user terminal and a Data processing circuit designed to carry out at least one of the methods described herein.
  • Embodiments further provide a vehicle with a device as described herein.
  • Fig. 1 shows a schematic representation of a method to be carried out by a user terminal for correcting a faulty state of a communication device of a vehicle
  • Fig. 2 shows a schematic representation of another method for implementation by a control unit for correcting a faulty state of a communication device of a vehicle
  • Fig. 3 shows a block diagram of an embodiment of a device for correcting a faulty state of a communication device of a vehicle.
  • Fig. 1 shows a schematic representation of a method 100 for implementation by a user terminal for correcting a faulty state of a communication device of a vehicle.
  • the method 100 includes receiving 110 vehicle log data indicative of the faulty state of the communication device.
  • the vehicle log data are received 110 at the user terminal from the vehicle, for example from the communication device or another communication device of the vehicle.
  • a faulty state of the communication device can be remedied by means of the user terminal.
  • a faulty state of the communication device can be a state in which not all functions of the communication device work.
  • a faulty state of the communication device can be a state in which connectivity of the communication device is restricted.
  • a faulty state of the Communication Failure may be a state in which no communication connection to a backend can be established and/or maintained.
  • Vehicle log data is information that can be collected and/or stored by a vehicle during operation.
  • the vehicle log data can include various parameters and/or data generated by various sensors and control units in the vehicle. This data can provide important insights into the condition, performance, and behavior of the vehicle.
  • a communication device in the vehicle can generate vehicle log data that is specific to the communication functions of the vehicle or the communication device.
  • This vehicle log data can include information about a wireless communication connection, connectivity, software update, communication protocol, and/or other associated metadata.
  • the vehicle log data can include system and/or error logs.
  • the system and/or error logs can be log data that helps in troubleshooting and diagnosing communication problems, such as error codes, error descriptions, timestamps, and information about failed connections or transmissions.
  • the user terminal can obtain information needed to determine the faulty state of the communication device.
  • the method 100 further includes obtaining 120 process data indicative of a process to be performed by the vehicle to correct the faulty state of the communication device.
  • the process data is obtained 120 based on the vehicle log data.
  • Obtaining 120 the process data may include receiving from a backend or determining by the user terminal of the process data.
  • the user terminal may read the process data from a storage unit.
  • process data for correcting a known faulty state may be stored in a look-up table in a storage unit of the user terminal.
  • the user terminal may then use the vehicle log data to determine the faulty state of the communication device and read the process data from the look-up table.
  • the user terminal may receive the process data from a backend.
  • the process data can include information that is required to correct the faulty state of the communication device.
  • the process data can be used to correct the faulty state of the communication device.
  • the process data can include diagnostic commands and/or diagnostic jobs.
  • the vehicle for example a control unit of the Vehicle and/or the communication device with the faulty condition, remedy the faulty condition of the communication device.
  • the method 100 further comprises sending 120 the process data for carrying out the process for rectifying the faulty state of the communication device.
  • the process data is sent to the vehicle, for example the communication device or another communication device of the vehicle.
  • the vehicle can receive the information required to rectify the faulty state of the communication device. In particular, the need for a communication connection between the vehicle and the backend can be eliminated.
  • the user terminal can access the vehicle log data.
  • the process data the user terminal can set diagnostic commands for the vehicle or the communication device. In the event of a communication connection of the communication device failing, a rectification of a faulty state of the communication device can be triggered by the user terminal. An analysis and rectification of problems in the area of a communication connection in a workshop can thus be avoided. This can improve the user experience.
  • an application installed on the user terminal can be used to carry out the method 100.
  • the application can in particular be an application from a vehicle manufacturer, also referred to as an OEM app (original equipment manufacturer application).
  • OEM app can be terminated for error analysis and/or troubleshooting of a communication device.
  • a faulty state of a communication device can be caused by a connectivity problem.
  • a communication device can have a faulty state if it cannot establish a connection to a backend.
  • the OEM app can be installed on the user device of a vehicle user.
  • the OEM app can enable a completely separate connection channel on the user device.
  • the user device can be connected to the vehicle via a local communication connection, such as a direct WLAN (wireless local network area) and/or Bluetooth connection.
  • Access to vehicle log data can be made via the local communication connection.
  • the local communication connection can be used to remotely control diagnostic commands using the process data. This makes it possible to remotely identify the problem by accessing the vehicle log data, even in the event of a total failure of the vehicle connectivity. to be analyzed via the user terminal and, if necessary, to be remedied by issuing diagnostic commands.
  • the OEM app can serve as a communication channel to the user (e.g. using a chat built into the OEM app). This can prompt the user to establish a necessary WLAN and/or Bluetooth connection with the vehicle and/or to carry out further actions. Since the vehicle log data is usually not activated for the user by default, the necessary vehicle log data can also be activated in the affected vehicle via the connection with the OEM app. After completing an analysis and optionally correcting the faulty state of the communication device, the logging of the vehicle log data can be switched off or configured accordingly.
  • the method 100 may further comprise sending malfunction data indicative of the faulty state of the communication device.
  • the malfunction data is sent to a backend.
  • the receiving 120 of the process data can be done by receiving the process data from the backend.
  • the process data is received at the user device for sending to the vehicle.
  • the backend can be informed of a malfunction, i.e. the faulty state of the communication device.
  • This malfunction data can be identical to the vehicle log data.
  • the user device can forward the vehicle log data to the backend.
  • the user terminal can determine the malfunction data based on the vehicle log data.
  • the malfunction data can only include a portion of the vehicle log data.
  • the user terminal can determine a cause for the faulty state of the communication device based on the vehicle log data, for example an error code or an error description. If the user terminal is not configured to determine process data for rectifying the faulty state of the communication device (for example, the look-up table does not include information relating to a specific error code), the user terminal can determine malfunction data.
  • the malfunction data created can include the error code or the error description.
  • the malfunction data created can then be sent to the backend. This can in particular reduce data transfer between the user terminal and the backend.
  • the backend may have more information regarding measures to rectify the faulty state of the communication device than the user terminal.
  • the backend may have received information about a faulty state of a communication device in other vehicles.
  • the backend can then determine or create the process data and send it to the user terminal.
  • rectification of the faulty state of the communication device can be improved.
  • the method 100 may further comprise obtaining fault data indicative of a fault in a communication connection of the communication device.
  • the method 100 may further comprise establishing a communication connection between the user terminal and the vehicle, for example the communication device or another communication device of the vehicle, for receiving the vehicle log data in response to obtaining the fault data.
  • Obtaining the fault data may comprise determining the fault data.
  • the user terminal may have established a WLAN communication connection with the communication device.
  • the established WLAN communication connection may be interrupted, for example due to a faulty state of the communication device.
  • the user terminal may determine the fault data based on the interrupted WLAN communication connection.
  • the user terminal may then establish a communication connection, in particular a local communication connection with the vehicle, for example another communication device of the vehicle. Triggered by the fault data, the user terminal may therefore in particular establish a connection with the vehicle for receiving the vehicle log data.
  • the user terminal can receive the fault data.
  • the user terminal can receive the fault data based on a user input. For example, a user can determine that a navigation service of the vehicle is faulty, for example because a connectivity of a navigation software of the vehicle is faulty. The user can then, for example, make an input using the user terminal. In particular, the user can use an OEM app for the user input. This can trigger the user to receive the vehicle log data.
  • the method 100 may further comprise sending start data indicative of starting a storage of vehicle log data.
  • the start data is sent to the vehicle, for example the communication device or another communication device of the vehicle.
  • a Saving the vehicle log data can be triggered.
  • the vehicle cannot save the vehicle log data permanently, for example to reduce storage requirements.
  • the user terminal can trigger the saving by sending the start data. This allows the vehicle to save the vehicle log data only if it could be needed to identify and/or rectify a faulty state of the communication device. This allows the storage requirements for rectifying the faulty state of the communication device to be reduced and/or dynamically controlled.
  • the method 100 may further comprise receiving verification data indicative of a verification required to receive the vehicle log data.
  • the verification data is received from the backend.
  • the method 100 may further comprise sending the verification data to the vehicle for receiving the vehicle log data.
  • the vehicle log data may be confidential.
  • the vehicle log data may only be accessible to certain devices, for example a backend of a vehicle manufacturer.
  • another device for example the user terminal, can be configured or authorized to receive the vehicle log data.
  • the verification data of the backend can therefore attest to the user terminal's authorization to receive the vehicle log data.
  • the vehicle can be informed of the user terminal's authorization to receive the vehicle log data. This allows the user terminal to receive confidential vehicle log data.
  • the verification data can include a time limit.
  • the verification data can only be valid for a defined time window. This means that the user terminal can only receive the vehicle log data during this defined time window.
  • the defined time window can include a time that is usual for correcting a faulty state of the communication device.
  • the method 100 can include a first step for correcting the faulty state of the communication device. In this first step, the user terminal can receive verification data that only authorizes a one-time receipt of vehicle log data. This vehicle log data can then be sent from the user terminal to the backend. Based on the vehicle log data, the backend can send further verification data to the user terminal if further vehicle log data is required to identify and/or correct the faulty state of the communication device.
  • the further verification data can, for example, include a defined time window that is required to correct an identified faulty state.
  • the method 100 may further comprise determining the malfunction data for sending to the backend based on the vehicle log data.
  • the user terminal may determine the malfunction data.
  • the malfunction data may comprise part of the vehicle log data.
  • the malfunction data may also be merely indicative of an identified faulty state of the communication device.
  • the malfunction data may comprise an error code and/or an error description of the faulty state of the communication device.
  • the method 100 may further comprise storing the vehicle log data and determining a communication connection type with the backend.
  • the method may further comprise sending the vehicle log data depending on the communication connection type.
  • the user terminal may be connected to the backend via a mobile communication connection.
  • a data volume of the mobile communication connection may depend on a user's contract.
  • the data volume may be limited. Therefore, sending the vehicle log data may place a heavy burden on the user's data volume.
  • a user experience may be impaired by an unwanted increase in data consumption of the mobile communication connection.
  • the user terminal may be connected to a router via a local communication connection, for example a WLAN communication connection, and to the backend via the router.
  • a data volume of this connection may be larger than that of the mobile communication connection. Accordingly, sending the vehicle log data to the backend may be limited to a local communication connection, for example to a router. As a result, a user experience may be improved.
  • the method 100 may further comprise sending chat data indicative of a user request from the user terminal.
  • the chat data is sent to the backend.
  • the method 100 may further comprise receiving further chat data indicative of a response to the user request (of a user) from the user terminal from the backend.
  • an OEM app may be used to enter the chat data.
  • the user may receive support using the chat data. This may improve a user experience.
  • the method 100 may further comprise establishing a local communication connection between the user terminal and the communication device to receive the vehicle log data. This means that the vehicle log data can be received even if the vehicle or the communication device cannot establish a mobile communication connection.
  • the communication device or the further communication device can be part of a control device or a control unit of the vehicle, for example a central control unit of the vehicle.
  • An example of a method for correcting a faulty state of the communication device can be as follows.
  • a user can detect a failure of vehicle connectivity, for example due to missing traffic data on the navigation or missing music streaming in an application.
  • the user can make an input using the user terminal.
  • the user terminal can determine fault data based on the input.
  • the user can contact support using an OEM app due to the failure of the vehicle connectivity.
  • the user can send chat data via the OEM app in a support chat.
  • a support employee for example a call agent, can use additional chat data to provide the user with information to resolve the vehicle connectivity failure. For example, the user can be asked to establish a WLAN and/or Bluetooth connection between the vehicle and the user device. The established WLAN and/or Bluetooth connection allows the support employee to read out the necessary vehicle log data via the OEM app.
  • the support employee can initiate or trigger the activation of the vehicle log data using an appropriate security mechanism. If the failure of the vehicle connectivity can be attributed to a known faulty state of a communication device with an already defined process for correcting the faulty state, the support employee can forward a necessary diagnostic job to the user terminal. The necessary diagnostic jobs can be included in the process data. The user terminal can then send the process data to the vehicle. The vehicle or a control unit of the vehicle can then correct the faulty state based on the diagnostic job.
  • the support representative can turn off logging in the vehicle and close a communication device faulty state request. If the problem does not relate to a known faulty If a faulty state cannot be assigned, the support employee can forward the vehicle log data to an appropriate development department. The appropriate development department can start an analysis. The appropriate development department can also inform the user about the analysis. Alternatively, the vehicle can automatically report the faulty state of the communication device to an OEM support center via the OEM app without customer interaction if the user's user device is directly connected to the vehicle via WLAN and/or Bluetooth. This allows the support center to initiate the analysis and rectification of the faulty state itself via the OEM app, rectify it and, if necessary, contact the user.
  • the user terminal can generally be a device that is capable of communicating wirelessly.
  • the user terminal can be a mobile user terminal, e.g. a user terminal that is suitable to be carried by a user.
  • the user terminal can be, e.g. a user terminal (UT) or user equipment (UE) in the sense of the respective communication standards used for mobile communication.
  • the user terminal can be, for example, a mobile phone, such as a smartphone, or another type of mobile communication device, such as a smartwatch, a laptop, a tablet computer, autonomous augmented reality glasses, etc.
  • Fig. 1 may comprise one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or one or more embodiments described below (e.g. Figs. 2 - 3).
  • Fig. 2 shows a schematic representation of a further method 200 for implementation by a control unit for correcting a faulty state of a communication device of a vehicle.
  • the method 200 can be implemented as a counterpart of the method for implementation by a user terminal, which was described with reference to Fig. 1.
  • the method 200 can be implemented in the context of transmitter and receiver with the method from Fig. 1.
  • the method 200 includes sending 210 vehicle log data indicative of the faulty state of the communication device.
  • the vehicle log data is sent to a user terminal.
  • the method 200 also includes receiving 220, from the user terminal, process data indicative of a process to be carried out by the vehicle to remedy the faulty state of the communication device.
  • the method 200 also includes Carrying out 230 the process for correcting the faulty state of the communication device based on the process data. This allows the vehicle to correct a faulty state of the communication device without an external connection to a backend or a workshop visit.
  • the method 200 can be carried out by a control unit that includes the communication device with the faulty state. Alternatively, the method 200 can be carried out by a control unit that includes another communication device. The communication device with the faulty state can be external to the control unit.
  • the communication device may generally be a device capable of communicating wirelessly.
  • the communication device may communicate in a mobile communication system with a backend, e.g. a base station.
  • a backend e.g. a base station.
  • the communication device may communicate in/via a mobile communication system.
  • the mobile communication system may comprise a plurality of transmission points and/or base stations capable of transmitting radio signals with the communication device.
  • FIG. 2 may comprise one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or one or more embodiments described above (e.g. Fig. 1) and/or below (e.g. Fig. 3).
  • Fig. 3 shows a block diagram of an embodiment of a device 30 for correcting a faulty state of a communication device of a vehicle 40.
  • the device 30 comprises an interface 32 for communication with a control unit (e.g. for carrying out the method as described with reference to Fig. 1) or a user terminal (e.g. for carrying out the method as described with reference to Fig. 2).
  • the device 30 further comprises a data processing circuit 34 which is designed to carry out at least one of the methods described herein, for example the method which is described with reference to Fig. 1 for the user terminal or with reference to Fig. 2 for the control unit.
  • Further embodiments are a vehicle 40 with a device 30, e.g. a control unit 30.
  • the interface 32 shown in Fig. 3 may, for example, correspond to one or more inputs and/or one or more outputs for receiving and/or transmitting information, for example in digital bit values based on a code, within a module, between modules, or between modules of different entities.
  • the interface 32 can, for example, be designed to communicate with other network components via a (radio) network or a local connection network.
  • the data processing circuit 34 can correspond to any controller or processor or a programmable hardware component.
  • the data processing circuit 34 can also be implemented as software that is programmed for a corresponding hardware component.
  • the data processing circuit 34 can be implemented as programmable hardware with appropriately adapted software. Any processors, such as digital signal processors (DSPs), can be used. Embodiments are not restricted to a specific type of processor. Any processor or even multiple processors are conceivable for implementing the data processing circuit 34.
  • DSPs digital signal processors
  • the interface 32 may be coupled to the respective data processing circuitry 34 of the device 30.
  • the device 30 may be implemented by one or more processing units, one or more processing devices, any means of processing, such as a processor, a computer, or a programmable hardware component operable with appropriately adapted software.
  • the described functions of the data processing circuitry 34 may also be implemented in software that is then executed on one or more programmable hardware components.
  • Such hardware components may be a general-purpose processor, a digital signal processor (DSP), a microcontroller, etc.
  • DSP digital signal processor
  • the data processing circuitry 34 may be capable of controlling the interface 32 so that any data transfer that occurs over the interface 32 and/or any interaction in which the interface 32 may be involved can be controlled by the data processing circuitry 34.
  • the device 30 may include a memory and at least one data processing circuit 34 operatively coupled to the memory and configured to perform one of the methods described above.
  • the interface 32 may correspond to any means for obtaining, receiving, transmitting, or providing analog or digital signals or information, e.g., any port, contact, pin, register, input port, output port, conductor, trace, etc. that enables the provision or receipt of a signal or information.
  • the interface 32 may be wireless or wired and may be configured to communicate with other internal or external components can communicate, e.g. send or receive signals or information.
  • the vehicle 40 may correspond, for example, to a land vehicle, a watercraft, an aircraft, a rail vehicle, a road vehicle, a car, a bus, a motorcycle, an off-road vehicle, a motor vehicle, or a truck.
  • the device 30 may, for example, be a part of or may be a control unit of the vehicle 40.
  • FIG. 3 may comprise one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or one or more embodiments described above (e.g. Figs. 1 - 3).
  • FIG. 1 For example, a digital storage medium, for example a floppy disk, a DVD, a Blu-ray disc, a CD, a ROM, a PROM, an EPROM, an EEPROM or a FLASH memory, a hard disk or another magnetic or optical memory on which electronically readable control signals are stored that can interact or interact with a programmable hardware component in such a way that the respective method is carried out.
  • a digital storage medium for example a floppy disk, a DVD, a Blu-ray disc, a CD, a ROM, a PROM, an EPROM, an EEPROM or a FLASH memory, a hard disk or another magnetic or optical memory on which electronically readable control signals are stored that can interact or interact with a programmable hardware component in such a way that the respective method is carried out.
  • the digital storage medium can therefore be machine- or computer-readable.
  • Some embodiments therefore comprise a data carrier that contains electronically readable control signals which are capable of interacting with a programmable computer system or a programmable hardware component such that one of the methods described herein is carried out.
  • One embodiment is thus a data carrier (or a digital storage medium or a computer-readable medium) on which the program for carrying out one of the methods described herein is recorded.
  • embodiments of the present invention can be implemented as a program, firmware, computer program or computer program product with a program code or as data, wherein the program code or the data is effective to carry out one of the methods when the program runs on a processor or a programmable hardware component.
  • the program code or the data can also be stored, for example, on a machine-readable carrier or data carrier.
  • the program code or the data can be present, among other things, as source code, machine code or byte code as well as other intermediate code.

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Ausführungsbeispiele der vorliegenden Erfindung schaffen ein Verfahren (100) zur Durchführung durch ein Benutzerendgerät zum Beheben eines fehlerbehafteten Zustands einer Kommunikationseinrichtung eines Fahrzeugs. Das Verfahren (100) umfasst Empfangen (110) von Fahrzeuglogdaten indikativ für den fehlerbehafteten Zustand der Kommunikationseinrichtung. Die Fahrzeuglogdaten werden von dem Fahrzeug, beispielsweise von der Kommunikationseinrichtung oder einer weiteren Kommunikationseinrichtung des Fahrzeugs, empfangen. Das Verfahren (100) umfasst ferner Erhalten (120) von Prozessdaten indikativ für einen durch das Fahrzeug durchzuführenden Prozess zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung basierend auf den Fahrzeuglogdaten. Ferner umfasst das Verfahren (100) Senden (130) der Prozessdaten zum Durchführen des Prozesses zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung.

Description

Verfahren zum Beheben eines fehlerbehafteten Zustands einer Kommunikationseinrichtung eines Fahrzeugs, Computerprogramm, Vorrichtung und Fahrzeug
Beschreibung
Ausführungsbeispiele der vorliegenden Erfindung beziehen sich auf Verfahren zum Beheben eines fehlerbehafteten Zustands einer Kommunikationseinrichtung eines Fahrzeugs, ein Computerprogramm, eine Vorrichtung und ein Fahrzeug, insbesondere aber nicht ausschließlich auf ein Konzept zum Senden von Prozessdaten zur Durchführung eines Prozesses zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung.
Ein Problem im Bereich einer Kommunikationsverbindung einer Kommunikationseinrichtung, zum Beispiel einer Internet-Konnektivität, welches die Verbindung einer Kommunikationseinrichtung eines Fahrzeugs mit einem Backendsystem, zum Beispiel einem Backendsystem eines Fahrzeugherstellers, verhindert oder beeinträchtigt, wird in der Regel mit Korrekturmaßnahmen behandelt. Eine Korrekturmaßnahme kann ein Reset der Kommunikationsverbindung oder der Kommunikationseinrichtung des Fahrzeugs nach der Erkennung eines Problems auslösen. Solch eine Korrekturmaßnahmen erfordert allerdings die Erkennung des Problems auf der Fahrzeugseite. Ferner kann eine Korrekturmaßnahme durch eine Fahrzeugseite nicht ausreichend sein, um die Kommunikationsverbindung wieder zu etablieren.
Alternativ kann ein Problem einer Kommunikationseinrichtung eines Fahrzeugs durch einen Aufenthalt in einer Werkstatt analysiert und behoben werden. In der Werkstatt kann ein direkter Zugriff auf das Bordnetz und dadurch auf jedes System und jede Kommunikationseinrichtung des Fahrzeugs, beispielsweise über eine Fahrzeugdiagnose Dose, erfolgen. Eine Problembehebung in einer Werkstatt erhöht jedoch einen Aufwand für einen Nutzer des Fahrzeugs.
Es besteht daher ein Bedarf ein verbessertes Verfahren zum Beheben eines fehlerbehafteten Zustands einer Kommunikationseinrichtung eines Fahrzeugs zur Verfügung zu stellen. Diesem Bedarf tragen die Verfahren, die Vorrichtung, das Computerprogramm, sowie das Fahrzeug nach den unabhängigen Ansprüchen Rechnung.
Ausführungsbeispiele basieren auf dem Kemgedanken, dass ein Verfahren zum Beheben eines fehlerbehafteten Zustands einer Kommunikationseinrichtung eines Fahrzeugs basierend auf Prozessdaten durchgeführt werden kann. Die Prozessdaten sind indikativ für einen durch das Fahrzeug durchzuführenden Prozess zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung. Die Prozessdaten werden basierend auf Fahrzeuglogdaten erhalten. Durch die Verwendung der Prozessdaten kann das Fahrzeug Informationen zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung empfangen. Basierend auf dem Prozessdaten kann das Fahrzeug bzw. eine Steuereinheit des Fahrzeugs eine Behebung des Fehlers durchfuhren.
Ausführungsbeispiele betreffen ein Verfahren zur Durchführung durch ein Benutzerendgerät zum Beheben eines fehlerbehafteten Zustands einer Kommunikationseinrichtung eines Fahrzeugs. Das Verfahren umfasst Empfangen von Fahrzeuglogdaten indikativ für den fehlerbehafteten Zustand der Kommunikationseinrichtung. Die Fahrzeuglogdaten werden am Benutzerendgerät von dem Fahrzeug, beispielsweise von der Kommunikationseinrichtung oder einer weiteren Kommunikationseinrichtung des Fahrzeugs, empfangen. Das Verfahren umfasst ferner Erhalten von Prozessdaten indikativ für einen durch das Fahrzeug durchzuführenden Prozess zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung basierend auf den Fahrzeuglogdaten. Ferner umfasst das Verfahren Senden der Prozessdaten zum Durchführen des Prozesses zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung. Die Prozessdaten werden an das Fahrzeug, beispielsweise die Kommunikationseinrichtung oder eine weitere Kommunikationseinrichtung des Fahrzeugs, gesendet. Durch die Verwendung von Fahrzeuglogdaten kann eine Analyse des fehlerbehafteten Zustands der Kommunikationseinrichtung erfolgen. Basierend auf dieser Analyse können dann Prozessdaten erhalten werden, beispielsweise von einem Backend empfangen werden, die Informationen zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung umfassen. Durch das Senden der Prozessdaten kann das Fahrzeug diese Information zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung erhalten. Dadurch kann der fehlerbehaftete Zustand der Kommunikationseinrichtung ohne einen Aufenthalt in einer Werkstatt und ohne eine Notwendigkeit einer Kommunikationsverbindung zwischen dem Fahrzeug und einem Backend behoben werden.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Senden von Fehlfimktionsdaten indikativ für den fehlerbehafteten Zustand der Kommunikationseinrichtung. Die Fehlfimktionsdaten werden an ein Backend gesendet. Das Erhalten der Prozessdaten am Benutzerendgerät kann durch Empfangen der Prozessdaten von dem Backend erfolgen. Die Prozessdaten werden zum Senden an das Fahrzeug empfangen. Durch das Empfangen der Prozessdaten von dem Backend kann das Benutzerendgerät benötigte Informationen zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung mit erhöhter Verlässlichkeit erhalten. Insbesondere kann das Backend eine Vielzahl an fehlerbehafteten Zuständen der Kommunikationseinrichtung basierend auf den Fehlfimktionsdaten identifizieren. Insbesondere kann eine Wahrscheinlichkeit, dass das Backend Prozessdaten zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung bestimmen kann, erhöht sein, im Vergleich zum Benutzerendgerät.
In einem Ausfiihrungsbeispiel kann das Verfahren ferner umfassen Erhalten von Störungsdaten indikativ für eine Störung einer Kommunikationsverbindung der Kommunikationseinrichtung. Ferner kann das Verfahren umfassen Etablieren einer Kommunikationsverbindung zwischen dem Benutzerendgerät und dem Fahrzeug, beispielsweise der Kommunikationseinrichtung oder einer weiteren Kommunikationseinrichtung des Fahrzeugs, zum Empfangen der Fahrzeuglogdaten in Antwort zum Erhalten der Störungsdaten. Durch das Erhalten der Störungsdaten kann eine Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung getriggert werden. Beispielsweise kann ein Nutzer eine fehlerhafte Kommunikationsverbindung der Kommunikationseinrichtung feststellen. Der Nutzer kann dann eine Eingabe auf dem Benutzerendgerät durchführen. Basierend auf der Eingabe können die Störungsdaten bestimmt werden. Durch Verwendung der Störungsdaten kann dann bedarfsgerecht eine Kommunikationsverbindung zum Empfangen der Fahrzeuglogdaten etabliert werden. Dadurch kann ein Informationsaustausch zwischen dem Benutzerendgerät und dem Fahrzeug erfolgen, wenn erforderlich.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Senden von Startdaten indikativ für ein Starten einer Speicherung von Fahrzeuglogdaten. Die Startdaten werden an das Fahrzeug, beispielsweise die Kommunikationseinrichtung oder eine weitere Kommunikationseinrichtung des Fahrzeugs, gesendet. Durch das Senden der Startdaten kann ein Speichern der Fahrzeuglogdaten getriggert werden. Dadurch kann insbesondere ein unnötiges Speichern von Fahrzeuglogdaten vermieden werden.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Empfangen von Verifizierungsdaten indikativ für eine zum Empfangen der Fahrzeuglogdaten benötigte Verifizierung. Die Verifizierungsdaten werden am Benutzerendgerät von den Backend empfangen. Ferner kann das Verfahren umfassen Senden der Verifizierungsdaten zum Empfangen der Fahrzeuglogdaten an das Fahrzeug. Durch die Verifizierungsdaten kann eine Berechtigung des Benutzerendgeräts zum Empfangen der Fahrzeuglogdaten nachgewiesen werden. Beispielsweise können die Fahrzeuglogdaten vertraulich sein. Die Fahrzeuglogdaten können beispielsweise nur an ein berechtigtes Backend gesendet werden. Durch Empfangen der Verifizierungsdaten von dem Backend und Senden der Verifizierungsdaten an das Fahrzeug, kann das Benutzerendgerät eine Berechtigung zum Empfangen der Fahrzeuglogdaten nachweisen. In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Bestimmen der Fehlfunktionsdaten zum Senden an das Backend basierend auf den Fahrzeuglogdaten. Durch das Bestimmen der Fehlfunktionsdaten kann ein Datentransfer zwischen dem Backend und dem Benutzerendgerät verringert werden.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Speichern der Fahrzeuglogdaten und Bestimmen eines Kommunikationsverbindungstyps mit dem Backend. Ferner kann das Verfahren umfassen Senden der Fahrzeuglogdaten in Abhängigkeit von dem bestimmten Kommunikationsverbindungstyp. Dadurch kann ein Datentransfer zwischen dem Backend und dem Benutzerendgerät an ein verfügbares Datenvolumen angepasst werden.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Senden von Chat-Daten indikativ für eine Nutzeranfrage des Benutzerendgeräts. Die Chat-Daten werden an das Backend gesendet. Ferner kann das Verfahren umfassen Empfangen von weiteren Chat-Daten indikativ für eine Antwort auf die Nutzeranfrage des Benutzerendgeräts von dem Backend. Durch das Senden der Chat-Daten kann eine Kommunikation zwischen dem Nutzer und einer Serviceperson erfolgen. Dadurch kann eine Nutzererfahrung verbessert werden.
Ausführungsbeispiele betreffen ein Verfahren zur Durchführung durch eine Steuereinheit eines Fahrzeugs zum Beheben eines fehlerbehafteten Zustands der Kommunikationseinrichtung. Das Verfahren umfasst Senden, an ein Benutzerendgerät, von Fahrzeuglogdaten indikativ für den fehlerbehafteten Zustand der Kommunikationseinrichtung. Ferner umfasst das Verfahren Empfangen, von dem Benutzerendgerät, von Prozessdaten indikativ für einen durch das Fahrzeug durchzuführenden Prozess zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung. Das Verfahren umfasst ferner Durchführen des Prozesses zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung basierend auf den Prozessdaten. Dadurch kann das Fahrzeug bzw. die Steuereinheit einen fehlerbehafteten Zustand der Kommunikationseinrichtung ohne eine externe Verbindung zu einem Backend oder einen Werkstattaufenthalt beheben.
Ausführungsbeispiele schaffen auch ein Computerprogramm zur Durchführung eines der hierin beschriebenen Verfahren, wenn das Computerprogramm auf einem Computer, einem Prozessor, oder einer programmierbaren Hardwarekomponente abläuft.
Ein weiteres Ausführungsbeispiel ist eine Vorrichtung zum Beheben eines fehlerbehafteten Zustands einer Kommunikationseinrichtung eines Fahrzeugs. Die Vorrichtung umfasst eine Schnittstelle zur Kommunikation mit einer Steuereinheit oder einem Benutzerendgerät und eine Datenverarbeitungsschaltung, die zur Durchführung zumindest eines der hierin beschriebenen Verfahren ausgebildet ist. Ausführungsbeispiele schaffen darüber hinaus ein Fahrzeug mit einer Vorrichtung wie hierin beschrieben.
Ausführungsbeispiele werden nachfolgend bezugnehmend auf die beiliegenden Figuren näher erläutert. Es zeigen:
Fig. 1 zeigt eine schematische Darstellung eines Verfahrens zur Durchführung durch ein Benutzerendgerät zum Beheben eines fehlerbehafteten Zustands einer Kommunikationseinrichtung eines Fahrzeugs;
Fig. 2 zeigt eine schematische Darstellung eines weiteren Verfahrens zur Durchführung durch eine Steuereinheit zum Beheben eines fehlerbehafteten Zustands einer Kommunikationseinrichtung eines Fahrzeugs;
Fig. 3 zeigt ein Blockdiagram eines Ausführungsbeispiels einer Vorrichtung zum Beheben eines fehlerbehafteten Zustands einer Kommunikationseinrichtung eines Fahrzeugs.
Verschiedene Ausführungsbeispiele werden nun ausführlicher unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben, in denen einige Ausführungsbeispiele dargestellt sind. In den Figuren können die Dickenabmessungen von Linien, Schichten und/oder Regionen um der Deutlichkeit Willen übertrieben dargestellt sein.
Fig. 1 zeigt eine schematische Darstellung eines Verfahrens 100 zur Durchführung durch ein Benutzerendgerät zum Beheben eines fehlerbehafteten Zustands einer Kommunikationseinrichtung eines Fahrzeugs. Das Verfahren 100 umfasst Empfangen 110 von Fahrzeuglogdaten indikativ für den fehlerbehafteten Zustand der Kommunikationseinrichtung. Die Fahrzeuglogdaten werden am Benutzerendgerät von dem Fahrzeug, beispielsweise von der Kommunikationseinrichtung oder einer weiteren Kommunikationseinrichtung des Fahrzeugs, empfangen 110.
Durch das Empfangen 110 von Fahrzeuglogdaten kann mittels des Benutzerendgeräts eine Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung durchgeführt werden. Ein fehlerbehafteter Zustand der Kommunikationseinrichtung kann ein Zustand sein, in dem nicht alle Funktionen der Kommunikationseinrichtung funktionieren. Beispielsweise kann ein fehlerbehafteter Zustand der Kommunikationseinrichtung ein Zustand sein, in dem eine Konnektivität der Kommunikationseinrichtung eingeschränkt ist. Beispielsweise kann ein fehlerbehafteter Zustand der Kommunikationseinrichtung ein Zustand sein, in dem keine Kommunikationsverbindung zu einem Backend etabliert und/oder aufrechterhalten werden kann.
Fahrzeuglogdaten sind Informationen, die von einem Fahrzeug während des Betriebs erfasst und/oder gespeichert werden können. Die Fahrzeuglogdaten können verschiedene Parameter und/oder Daten umfassen, die von verschiedenen Sensoren und Steuergeräten im Fahrzeug erzeugt werden. Diese Daten können wichtige Einblicke in den Zustand, die Leistung und das Verhalten des Fahrzeugs liefern. Beispielsweise kann eine Kommunikationseinrichtung im Fahrzeug Fahrzeuglogdaten generieren, die spezifisch für die Kommunikationsfunktionen des Fahrzeugs bzw. der Kommunikationseinrichtung sind. Diese Fahrzeuglogdaten können Informationen über eine drahtlose Kommunikationsverbindung, eine Konnektivität, ein Software-Update, ein Kommunikationsprotokoll und/oder andere assoziierte Metadaten umfassen. Beispielsweise können die Fahrzeuglogdaten System- und/oder Fehlerprotokolle umfassen. Die System- und/oder Fehlerprotokolle können Protokolldaten sein, die bei der Fehlerbehebung und Diagnose von Kommunikationsproblemen helfen, wie z. B. Fehlercodes, Fehlerbeschreibungen, Zeitstempel und Informationen über fehlgeschlagene Verbindungen oder Übertragungen. Durch das Empfangen 110 der Fahrzeuglogdaten kann das Benutzerendgerät also benötigte Informationen zur Bestimmung des fehlerbehafteten Zustands der Kommunikationseinrichtung erhalten.
Das Verfahren 100 umfasst ferner Erhalten 120 von Prozessdaten indikativ für einen durch das Fahrzeug durchzuführenden Prozess zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung. Die Prozessdaten werden basierend auf den Fahrzeuglogdaten erhalten 120. Das Erhalten 120 der Prozessdaten kann ein Empfangen von einem Backend oder ein Bestimmen durch das Benutzerendgerät der Prozessdaten umfassen. Beispielsweise kann das Benutzerendgerät die Prozessdaten aus einer Speichereinheit auslesen. Beispielsweise können Prozessdaten zur Behebung eines bekannten fehlerbehafteten Zustands in einer Look-Up Tabelle in einer Speichereinheit des Benutzerendgeräts gespeichert sein. Das Benutzerendgerät kann dann die Fahrzeuglogdaten zur Bestimmung des fehlerbehafteten Zustands der Kommunikationseinrichtung verwenden und die Prozessdaten aus der Look-Up Tabelle auslesen. Alternativ oder optional kann das Benutzerendgerät die Prozessdaten von einem Backend empfangen.
Die Prozessdaten können Informationen umfassen, welche zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung erforderlich sind. Insbesondere können die Prozessdaten dazu verwendet werden den fehlerbehafteten Zustand der Kommunikationseinrichtung zu beheben. Beispielsweise können die Prozessdaten Diagnosebefehle und/oder Diagnosejobs umfassen. Durch Verwendung der Prozessdaten kann also das Fahrzeug, beispielsweise eine Steuereinheit des Fahrzeugs und/oder die Kommunikationseinrichtung mit dem fehlerbehafteten Zustand, den fehlerbehafteten Zustand der Kommunikationseinrichtung beheben.
Ferner umfasst das Verfahren 100 Senden 120 der Prozessdaten zum Durchfuhren des Prozesses zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung. Die Prozessdaten werden an das Fahrzeug, beispielsweise die Kommunikationseinrichtung oder eine weitere Kommunikationseinrichtung des Fahrzeugs, gesendet. Durch das Senden 120 der Prozessdaten kann das Fahrzeug benötigte Informationen zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung empfangen. Insbesondere kann ein Bedarf einer Kommunikationsverbindung zwischen Fahrzeug und Backend entfallen. Durch das Empfangen 110 der Fahrzeuglogdaten von dem Fahrzeug kann das Benutzerendgerät auf die Fahrzeuglogdaten zugreifen. Durch das Senden 130 der Prozessdaten kann das Benutzerendgerät Diagnosebefehle für das Fahrzeug bzw. die Kommunikationseinrichtung einsteuem. Dadurch kann bei einem Ausfall einer Kommunikationsverbindung der Kommunikationseinrichtung eine Behebung eines fehlerbehafteten Zustands der Kommunikationseinrichtung mittels des Benutzerendgeräts getriggert werden. Eine Analyse und Behebung von Problemen im Bereich einer Kommunikationsverbindung in einer Werkstatt kann dadurch vermieden werden. Dadurch kann eine Nutzererfahrung verbessert werden.
Beispielsweise kann eine Applikation, welche auf dem Benutzerendgerät installiert ist, zur Durchführung des Verfahrens 100 verwendet werden. Bei der Applikation kann sich insbesondere um eine Applikation eines Fahrzeugherstellers handeln, auch als OEM-App (engl. orignial equipment manufacturer application) bezeichnet. Die OEM-App kann für eine Fehleranalyse und/oder Fehlerbehebung einer Kommunikationseinrichtung beendet werden. Beispielsweise kann ein fehlerbehafteter Zustand einer Kommunikationseinrichtung durch ein Konnektivität-Problem hervorgerufen werden. Eine Kommunikationseinrichtung kann einen fehlerbehafteten Zustand haben, wenn sie keine Verbindung zu einem Backend herstellen kann.
Die OEM-App kann auf dem Benutzerendgerät eines Nutzers des Fahrzeugs installiert sein. Die OEM-App kann auf dem Benutzerendgerät einen komplett separaten Verbindungskanal ermöglichen. Beispielsweise kann das Benutzerendgerät über eine lokale Kommunikationsverbindung, zum Beispiel eine direkte WLAN (wireless local network area) und/oder Bluetooth Verbindung, mit dem Fahrzeug verbunden sein. Über die lokale Kommunikationsverbindung kann ein Zugriff auf Fahrzeuglogdaten erfolgen. Ferner kann über die lokale Kommunikationsverbindung eine Einsteuerung von Diagnose-Befehlen mittels der Prozessdaten aus der Feme ermöglicht werden. Damit ist es möglich, selbst bei einem Totalausfall der Fahrzeugkonnektivität, das Problem aus der Feme durch den Zugriff auf die Fahrzeuglogdaten über das Benutzerendgerät zu analysieren und gegebenenfalls über die Einsteuerung von Diagnosebefehlen zu beheben.
Optional oder alternativ kann die OEM-App als Kommunikationskanal zum Nutzer dienen (z. B. mittels eines in der OEM-App eingebauten Chats). Damit kann der Nutzer aufgefordert werden eine notwendige WLAN und/oder Bluetooth Verbindung mit dem Fahrzeug aufzubauen und/oder weitere Aktionen auszuführen. Da die Fahrzeuglogdaten in der Regel nicht standardmäßig beim Nutzer freigeschaltet sind, kann über die Verbindung mit der OEM-App auch eine Freischaltung der notwendigen Fahrzeuglogdaten im betroffenen Fahrzeug durchgeführt werden. Nach Abschluss einer Analyse und optional einer Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung kann das Logging der Fahrzeuglogdaten ausgeschalten oder entsprechend konfiguriert werden.
In einem Ausführungsbeispiel kann das Verfahren 100 ferner umfassen Senden von Fehlfimktionsdaten indikativ für den fehlerbehafteten Zustand der Kommunikationseinrichtung. Die Fehlfimktionsdaten werden an ein Backend gesendet. Das Erhalten 120 der Prozessdaten kann durch Empfangen der Prozessdaten von dem Backend erfolgen. Die Prozessdaten werden am Benutzergerät zum Senden an das Fahrzeug empfangen. Durch das das Senden der Fehlfimktionsdaten kann das Backend über eine Fehlfunktion, also den fehlerbehafteten Zustand der Kommunikationseinrichtung, informiert werden. Diese Fehlfimktionsdaten können identisch zu den Fahrzeuglogdaten sein. Beispielsweise kann das Benutzerendgerät die Fahrzeuglogdaten an das Backend weiterleiten.
Alternativ kann das Benutzerendgerät die Fehlfimktionsdaten basierend auf den Fahrzeuglogdaten bestimmen. Die Fehlfimktionsdaten können nur einen Teil der Fahrzeuglogdaten umfassen. Beispielsweise kann das Benutzerendgerät basierend auf den Fahrzeuglogdaten eine Ursache für den fehlerbehafteten Zustand der Kommunikationseinrichtung Bestimmen, zum Beispiel einen Fehlercode oder eine Fehlerbeschreibung. Sofern das Benutzerendgerät nicht dazu konfiguriert ist Prozessdaten zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung zu bestimmen (beispielsweise sind in der Look-Up Tabelle keine Informationen betreffend eines bestimmten Fehlercodes umfasst), kann das Benutzerendgerät Fehlfimktionsdaten bestimmen. Die erstellten Fehlfunktionsdaten können den Fehlercode oder die Fehlerbeschreibung umfassen. Die erstellten Fehlfimktionsdaten können dann an das Backend gesendet werden. Dadurch kann insbesondere ein Datentransfer zwischen dem Benutzerendgerät und dem Backend verringert werden. Das Backend kann über mehr Informationen hinsichtlich Maßnahmen zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung als das Benutzerendgerät verfügen. Beispielsweise kann das Backend Informationen über einen fehlerbehafteten Zustand einer Kommunikationseinrichtung anderer Fahrzeuge empfangen haben. Das Backend kann dann die Prozessdaten bestimmen bzw. erstellen und an das Benutzerendgerät senden. Durch die Verbindung des Benutzerendgeräts mit dem Backend kann also eine Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung verbessert werden.
In einem Ausführungsbeispiel kann das Verfahren 100 ferner umfassen Erhalten von Störungsdaten indikativ für eine Störung einer Kommunikationsverbindung der Kommunikationseinrichtung. Ferner kann das Verfahren 100 umfassen Etablieren einer Kommunikationsverbindung zwischen dem Benutzerendgerät und dem Fahrzeug, beispielsweise der Kommunikationseinrichtung oder einer weiteren Kommunikationseinrichtung des Fahrzeugs, zum Empfangen der Fahrzeuglogdaten in Antwort zum Erhalten der Störungsdaten. Das Erhalten der Störungsdaten kann ein Bestimmen der Störungsdaten umfassen. Beispielsweise kann das Benutzerendgerät eine WLAN- Kommunikationsverbindung mit der Kommunikationseinrichtung etabliert haben. Die etablierte WLAN-Kommunikationsverbindung kann unterbrochen werden, beispielsweise durch einen fehlerbehafteten Zustand der Kommunikationseinrichtung. Das Benutzerendgerät kann basierend auf der unterbrochenen WLAN-Kommunikationsverbindung die Störungsdaten bestimmen. Das Benutzerendgerät kann dann eine Kommunikationsverbindung, insbesondere eine lokale Kommunikationsverbindung mit dem Fahrzeug, beispielsweise einer weiteren Kommunikationseinrichtung des Fahrzeugs, etablieren. Getriggert durch die Störungsdaten kann das Benutzerendgerät also insbesondere eine Verbindung zum Empfangen der Fahrzeuglogdaten mit dem Fahrzeug etablieren.
Alternativ oder optional kann das Benutzerendgerät die Störungsdaten empfangen. Beispielsweise kann das Benutzerendgerät die Störungsdaten basierend auf einer Nutzereingabe empfangen. Ein Nutzer kann beispielsweise feststellen, dass ein Navigationsservice des Fahrzeugs fehlerhaft ist, beispielsweise weil eine Konnektivität einer Navigationssoftware des Fahrzeugs fehlerhaft ist. Der Nutzer kann dann beispielsweise eine Eingabe mittels des Benutzerendgeräts durchführen. Insbesondere kann der Nutzer eine OEM-App für die Nutzereingabe verwenden. Dadurch kann ein empfangen der Fahrzeuglogdaten durch den Nutzer getriggert werden.
In einem Ausführungsbeispiel kann das Verfahren 100 ferner umfassen Senden von Startdaten indikativ für ein Starten einer Speicherung von Fahrzeuglogdaten. Die Startdaten werden an das Fahrzeug, beispielsweise die Kommunikationseinrichtung oder eine weitere Kommunikationseinrichtung des Fahrzeugs, gesendet. Durch das Senden der Startdaten kann ein Speichern der Fahrzeuglogdaten getriggert werden. Das Fahrzeug kann die Fahrzeuglogdaten nicht permanent speichern, beispielsweise um ein Speicherbedarf zu verringern. Basierend auf den Störungsdaten kann das Benutzerendgerät die Speicherung durch das Senden der Startdaten triggern. Dadurch kann das Fahrzeug die Fahrzeuglogdaten nur dann speichern, wenn diese zur Identifizierung und/oder Behebung eines fehlerbehafteten Zustands der Kommunikationseinrichtung benötigt werden könnten. Hierdurch lässt sich ein Speicherbedarf für die Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung verringern und/oder dynamisch steuern.
In einem Ausführungsbeispiel kann das Verfahren 100 ferner umfassen Empfangen von Verifizierungsdaten indikativ für eine zum Empfangen der Fahrzeuglogdaten benötigte Verifizierung. Die Verifizierungsdaten werden von den Backend empfangen. Ferner kann das Verfahren 100 umfassen Senden der Verifizierungsdaten zum Empfangen der Fahrzeuglogdaten an das Fahrzeug. Die Fahrzeuglogdaten können vertraulich sein. Die Fahrzeuglogdaten können insbesondere nur zugänglich sein für bestimmte Geräte, beispielsweise ein Backend eines Fahrzeugherstellers. Durch die Verifizierungsdaten kann ein anderes Gerät, beispielsweise das Benutzerendgerät, dazu konfiguriert werden bzw. dazu berechtigt werden, die Fahrzeuglogdaten zu empfangen. Die Verifizierungsdaten des Backend können also dem Benutzerendgerät eine Berechtigung zum Empfangen der Fahrzeuglogdaten attestieren. Durch das Senden der Verifizierungsdaten von dem Benutzerendgerät an das Fahrzeug kann das Fahrzeug über die Berechtigung des Benutzerendgeräts zum Empfangen der Fahrzeuglogdaten informiert werden. Dadurch kann das Benutzerendgerät vertrauliche Fahrzeuglogdaten empfangen.
Optional können die Verifizierungsdaten eine zeitliche Limitierung umfassen. Beispielsweise können die Verifizierungsdaten nur für ein definiertes Zeitfenster gültig sein. Dadurch kann das Benutzerendgerät die Fahrzeuglogdaten lediglich während diesem definierten Zeitfenster empfangen. Das definierten Zeitfenster kann eine Zeit umfassen, die üblich ist zur Behebung eines fehlerbehafteten Zustands der Kommunikationseinrichtung. Beispielsweise kann das Verfahren 100 einen ersten Schritt zum Beheben des fehlerbehafteten Zustands der Kommunikationseinrichtung umfassen. In diesem ersten Schritt kann das Benutzerendgerät Verifizierungsdaten empfangen, die lediglich zu einem einmaligen Empfang von Fahrzeuglogdaten berechtigen. Diese Fahrzeuglogdaten können dann von dem Benutzerendgerät an das Backend gesendet werden. Basierend auf den Fahrzeuglogdaten kann das Backend weitere Verifizierungsdaten an das Benutzerendgerät schicken, sofern weitere Fahrzeuglogdaten zur Identifizierung und/oder Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung erforderlich sind. Die weiteren Verifizierungsdaten können beispielsweise ein definiertes Zeitfenster, welches zur Behebung eines identifizierten fehlerbehafteten Zustands erforderlich ist, umfassen. In einem Ausführungsbeispiel kann das Verfahren 100 ferner umfassen Bestimmen der Fehlfunktionsdaten zum Senden an das Backend basierend auf den Fahrzeuglogdaten. Wie oben beschrieben kann das Benutzerendgerät die Fehlfunktionsdaten bestimmen. Die Fehlfunktionsdaten können in diesem Fall einen Teil der Fahrzeuglogdaten umfassen. Alternativ oder optional können die Fehlfunktionsdaten auch lediglich indikativ für einen identifizierten fehlerbehafteten Zustand der Kommunikationseinrichtung sein. Beispielsweise können die Fehlfunktionsdaten einem Fehlercode und/oder eine Fehlerbeschreibung des fehlerbehafteten Zustands der Kommunikationseinrichtung umfassen. Durch das Bestimmen der Fehlfunktionsdaten kann ein Datentransfer zwischen dem Backend und dem Benutzerendgerät verringert werden. Insbesondere kann eine Übertragung der kompletten Fahrzeuglogdaten vermieden werden.
In einem Ausfuhrungsbeispiel kann das Verfahren 100 ferner umfassen Speichern der Fahrzeuglogdaten und Bestimmen eines Kommunikationsverbindungstyps mit dem Backend. Ferner kann das Verfahren umfassen Senden der Fahrzeuglogdaten in Abhängigkeit von dem Kommunikationsverbindungstyp. Beispielsweise kann das Benutzerendgerät über eine mobile Kommunikationsverbindung mit dem Backend verbunden sein. In diesem Fall kann ein Datenvolumen der mobilen Kommunikationsverbindung von einem Vertrag des Nutzers abhängig sein. Insbesondere kann das Datenvolumen beschränkt sein. Deshalb kann ein Senden der Fahrzeuglogdaten ein Datenvolumen des Nutzers stark beanspruchen. Dadurch kann eine Nutzererfahrung durch einen ungewollten erhöhten Datenverbrauch der mobilen Kommunikationsverbindung beeinträchtigt werden. Alternativ kann das Benutzerendgerät über eine lokale Kommunikationsverbindung, beispielsweise eine WLAN -Kommunikationsverbindung mit einem Router und über den Router mit dem Backend verbunden sein. Ein Datenvolumen dieser Verbindung kann größer als das der mobilen Kommunikationsverbindung sein. Dementsprechend kann ein Senden der Fahrzeuglogdaten an das Backend auf eine lokale Kommunikationsverbindung, beispielsweise mit einem Router, beschränkt werden. Dadurch kann eine Nutzererfahrung verbessert werden.
In einem Ausführungsbeispiel kann das Verfahren 100 ferner umfassen Senden von Chat-Daten indikativ für eine Nutzeranfrage des Benutzerendgeräts. Die Chat-Daten werden an das Backend gesendet. Ferner kann das Verfahren 100 umfassen Empfangen von weiteren Chat-Daten indikativ für eine Antwort auf die Nutzeranfrage (eines Nutzers) des Benutzerendgeräts von dem Backend. Beispielsweise kann eine OEM-App zur Eingabe der Chat-Daten dienen. Mittels der Chat-Daten kann der Nutzer ein Support erhalten. Dadurch kann eine Nutzererfahrung verbessert werden.
In einem Ausführungsbeispiel kann das Verfahren 100 ferner umfassen Etablieren einer lokalen Kommunikationsverbindung zwischen dem Benutzerendgerät und der Kommunikationseinrichtung zum Empfangen der Fahrzeuglogdaten. Dadurch können die Fahrzeuglogdaten auch dann empfangen werden, wenn das Fahrzeug bzw. die Kommunikationseinrichtung keine mobile Kommunikationsverbindung etablieren kann.
Die Kommunikationseinrichtung oder die weitere Kommunikationseinrichtung kann ein Teil eines Steuergeräts bzw. einer Steuereinheit des Fahrzeugs sein, beispielsweise einer zentralen Steuereinheit des Fahrzeugs.
Ein beispielhafter Ablauf eines Verfahrens zum Beheben eines fehlerbehafteten Zustands der Kommunikationseinrichtung kann wie folgt ablaufen. Ein Nutzer kann einen Ausfall eine Fahrzeugkonnektivität, beispielsweise durch fehlende Verkehrsdaten auf der Navigation oder fehlendes Musik-Streaming in einer Applikation, feststellen. Der Nutzer kann eine Eingabe mittels des Benutzerendgeräts durchfuhren. Das Benutzerendgerät kann basierend auf der Eingabe Störungsdaten bestimmen. Alternativ oder optional kann der Nutzer sich wegen dem Ausfall der Fahrzeugkonnektivität mittels einer OEM-App an ein Support wenden. Beispielsweise kann der Nutzer Chat-Daten über die OEM-App in einem Support-Chat senden.
Ein Support-Mitarbeiter, beispielsweise ein Call-Agent kann mittels weiterer Chat-Daten den Nutzer Informationen für eine Behebung des Ausfalls der Fahrzeug Konnektivität zur Verfügung stellen. Beispielsweise kann der Nutzer dazu aufgefordert werden eine WLAN und/oder Bluetooth Verbindung zwischen dem Fahrzeug und dem Benutzerendgerät zu etablieren. Durch die etablierte WLAN und/oder Bluetoothverbindung kann der Support-Mitarbeiter notwendige Fahrzeuglogdaten über die OEM-App auslesen.
Optional kann der Support-Mitarbeiter für den Fall, dass die Fahrzeuglogdaten nicht aktiviert sind oder vertraulich sind, eine Freischaltung der Fahrzeuglogdaten durch einen entsprechenden Security- Mechanismus veranlassen bzw. triggern. Wenn der Ausfall der Fahrzeugkonnektivität zu einem bekannten fehlerbehafteten Zustand einer Kommunikationseinrichtung mit einem bereits definierten Prozess zur Behebung des fehlerbehafteten Zustands zugeordnet werden kann, kann der Support- Mitarbeiter einen notwendigen Diagnose-Jobs an das Benutzerendgerät weiterleiten. Die notwendigen Diagnose-Jobs können von den Prozessdaten umfasst sein. Das Benutzerendgerät kann dann die Prozessdaten an das Fahrzeug senden. Das Fahrzeug bzw. eine Steuereinheit des Fahrzeugs kann dann den fehlerbehafteten Zustand basierend auf dem Diagnose-Jobs beheben.
Nachdem der Nutzer die Fahrzeugkonnektivität bestätigt hat, kann der Support-Mitarbeiter das Logging im Fahrzeug ausschalten und eine Anfrage betreffend den fehlerbehafteten Zustand der Kommunikationseinrichtung schließen. Wenn das Problem zu keinem bekannten fehlerbehafteten Zustand zugeordnet werden kann, kann der Support-Mitarbeiter die Fahrzeuglogdaten zu einer entsprechenden Entwicklungsabteilung weiterleiten. Die entsprechende Entwicklungsabteilung kann eine Analyse starten. Ferner kann die entsprechende Entwicklungsabteilung den Nutzer über die Analyse informieren. Alternativ kann das Fahrzeug automatisch ohne Kundeninteraktion über die OEM-App den fehlerbehafteten Zustand der Kommunikationseinrichtung bei einem Support Center vom OEM melden, falls das Benutzerendgerät des Nutzers direkt über WLAN und/oder Bluetooth mit dem Fahrzeug verbunden ist. Damit kann das Support Center die Analyse und Behebung des fehlerbehafteten Zustands über die OEM-App selbst einleiten, beheben und gegebenenfalls den Nutzer kontaktieren.
Das Benutzerendgerät kann im Allgemeinen ein Gerät sein, das in der Lage ist, drahtlos zu kommunizieren. Insbesondere kann das Benutzerendgerät ein mobiles Benutzerendgerät sein, z.B. ein Benutzerendgerät, das geeignet ist, von einem Nutzer mitgeführt zu werden. Das Benutzerendgerät kann z.B. ein User Terminal (UT) oder User Equipment (UE) im Sinne der jeweiligen Kommunikationsstandards sein, die für die mobile Kommunikation verwendet werden. Bei dem Benutzerendgerät kann es sich beispielsweise um ein Mobiltelefon, wie ein Smartphone, oder eine andere Art von mobilem Kommunikationsgerät, wie eine Smartwatch, einen Laptop, einen Tablet-Computer, eine autonome Augmented-Reality-Brille, etc. handeln.
Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den unten beschriebenen Ausführungsbeispielen erwähnt. Das in Fig. 1 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren unten beschriebenen Ausführungsbeispielen (z. B. Fig. 2 — 3) erwähnt wurden.
Fig. 2 zeigt eine schematische Darstellung eines weiteren Verfahrens 200 zur Durchführung durch eine Steuereinheit zum Beheben eines fehlerbehafteten Zustands einer Kommunikationseinrichtung eines Fahrzeugs. Das Verfahren 200 kann als ein Gegenstück des Verfahrens zur Durchführung durch ein Benutzerendgerät, welches mit Bezug zu Fig. 1 beschrieben wurde, durchgeführt werden. Insbesondere kann das Verfahren 200 im Rahmen von Sender und Empfänger mit dem Verfahren aus Fig. 1 durchgeführt werden.
Das Verfahren 200 umfasst Senden 210 von Fahrzeuglogdaten indikativ für den fehlerbehafteten Zustand der Kommunikationseinrichtung. Die Fahrzeuglogdaten werden an ein Benutzerendgerät gesendet. Ferner umfasst das Verfahren 200 Empfangen 220, von dem Benutzerendgerät, von Prozessdaten indikativ für einen durch das Fahrzeug durchzuführenden Prozess zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung. Das Verfahren 200 umfasst ferner Durchfuhren 230 des Prozesses zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung basierend auf den Prozessdaten. Dadurch kann das Fahrzeug einen fehlerbehafteten Zustand der Kommunikationseinrichtung ohne eine externe Verbindung zu einem Backend oder ein Werkstattaufenthalt beheben. Das Verfahren 200 kann durch eine Steuereinheit durchgeführt werden, welche die Kommunikationseinrichtung mit dem fehlerbehafteten Zustand umfasst. Alternativ kann das Verfahren 200 durch eine Steuereinheit durchgeführt werden, welche eine weitere Kommunikationseinrichtung umfasst. Die Kommunikationseinrichtung mit dem fehlerbehafteten Zustand kann extern zu der Steuereinheit sein.
Die Kommunikationseinrichtung kann im Allgemeinen ein Gerät sein, das in der Lage ist, drahtlos zu kommunizieren. Die Kommunikationseinrichtung kann in einem mobilen Kommunikationssystem mit einem Backend, z. B. einer Basisstation, kommunizieren. Zum Beispiel kann die Kommunikationseinrichtung in/über ein mobiles Kommunikationssystem kommunizieren. Das mobile Kommunikationssystem kann eine Vielzahl von Sendepunkten und/oder Basisstationen umfassen, die in der Lage sind, Funksignale mit der Kommunikationseinrichtung zu übermitteln.
Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den unten und/oder oben beschriebenen Ausführungsbeispielen erwähnt. Das in Fig. 2 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren oben (z. B. Fig. 1) und/oder unten beschriebenen Ausführungsbeispielen (z. B. Fig. 3) erwähnt wurden.
Fig. 3 zeigt ein Blockdiagram eines Ausführungsbeispiels einer Vorrichtung 30 zum Beheben eines fehlerbehafteten Zustands einer Kommunikationseinrichtung eines Fahrzeugs 40. Die Vorrichtung 30, umfasst eine Schnittstelle 32 zur Kommunikation mit einer Steuereinheit (z. B. zur Durchführung des Verfahrens wie es mit Bezug zu Fig. 1 beschrieben ist) oder einem Benutzerendgerät (z. B. zur Durchführung des Verfahrens wie es mit Bezug zu Fig. 2 beschrieben ist). Die Vorrichtung 30 umfasst ferner eine Datenverarbeitungs Schaltung 34, die zur Durchführung zumindest eines der hierin beschriebenen Verfahren ausgebildet ist, beispielsweise des Verfahrens, welches mit Bezug zu Fig. 1 für das Benutzerendgerät oder mit Bezug zu Fig. 2 für die Steuereinheit beschrieben ist. Weitere Ausführungsbeispiele sind ein Fahrzeug 40 mit einer Vorrichtung 30, z. B. einer Steuereinheit 30.
Die in Fig. 3 gezeigte Schnittstelle 32 kann beispielsweise einem oder mehreren Eingängen und/oder einem oder mehreren Ausgängen zum Empfangen und/oder Übertragen von Informationen entsprechen, etwa in digitalen Bitwerten, basierend auf einem Code, innerhalb eines Moduls, zwischen Modulen, oder zwischen Modulen verschiedener Entitäten. Die Schnittstelle 32 kann beispielsweise ausgebildet sein, um über ein (Funk)-Netzwerk oder ein lokales Verbindungsnetzwerk mit anderen Netzwerkkomponenten zu kommunizieren.
In Ausführungsbeispielen kann die Datenverarbeitungsschaltung 34 einem beliebigen Controller oder Prozessor oder einer programmierbaren Hardwarekomponente entsprechen. Beispielsweise kann die Datenverarbeitungsschaltung 34 auch als Software realisiert sein, die für eine entsprechende Hardwarekomponente programmiert ist. Insofern kann die Datenverarbeitungsschaltung 34 als programmierbare Hardware mit entsprechend angepasster Software implementiert sein. Dabei können beliebige Prozessoren, wie Digitale Signalprozessoren (DSPs) zum Einsatz kommen. Ausführungsbeispiele sind dabei nicht auf einen bestimmten Typ von Prozessor eingeschränkt. Es sind beliebige Prozessoren oder auch mehrere Prozessoren zur Implementierung der Datenverarbeitungsschaltung 34 denkbar.
Wie in Fig. 3 dargestellt, kann die Schnittstelle 32 mit der jeweiligen Datenverarbeitungsschaltung 34 der Vorrichtung 30 gekoppelt sein. In Beispielen kann die Vorrichtung 30 durch eine oder mehrere Verarbeitungseinheiten, ein oder mehrere Verarbeitungsgeräte, ein beliebiges Mittel zur Verarbeitung, wie z.B. einen Prozessor, einen Computer oder eine programmierbare Hardwarekomponente, die mit entsprechend angepasster Software betrieben werden kann, implementiert werden. Ebenso können die beschriebenen Funktionen der Datenverarbeitungsschaltung 34 auch in Software implementiert werden, die dann auf einer oder mehreren programmierbaren Hardwarekomponenten ausgeführt wird. Solche Hardwarekomponenten können ein Mehrzweckprozessor, ein digitaler Signalprozessor (DSP), ein Mikrocontroller usw. sein. Die Datenverarbeitungsschaltung 34 kann in der Lage sein, die Schnittstelle 32 zu steuern, so dass jede Datenübertragung, die über die Schnittstelle 32 erfolgt, und/oder jede Interaktion, an der die Schnittstelle 32 beteiligt sein kann, von der Datenverarbeitungsschaltung 34 gesteuert werden kann.
In einer Ausführungsform kann die Vorrichtung 30 einen Speicher und mindestens eine Datenverarbeitungsschaltung 34 umfassen, die funktionsfähig mit dem Speicher gekoppelt und so konfiguriert ist, dass sie die eines der oben beschriebenen Verfahren durchführt.
In Beispielen kann die Schnittstelle 32 jedem Mittel zum Erhalten, Empfangen, Übertragen oder Bereitstellen von analogen oder digitalen Signalen oder Informationen entsprechen, z. B. jedem Anschluss, Kontakt, Stift, Register, Eingangsanschluss, Ausgangsanschluss, Leiter, Spur usw., der die Bereitstellung oder den Erhalt eines Signals oder einer Information ermöglicht. Die Schnittstelle 32 kann drahtlos oder drahtgebunden sein und können so konfiguriert sein, dass sie mit weiteren internen oder externen Komponenten kommunizieren können, z. B. Signale oder Informationen senden oder empfangen können.
In zumindest manchen Ausführungsbeispielen kann das Fahrzeug 40 beispielsweise einem Landfahrzeug, einem Wasserfahrzeug, einem Luftfahrzeug, einem Schienenfahrzeug, einem Straßenfahrzeug, einem Auto, einem Bus, einem Motorrad, einem Geländefahrzeug, einem Kraftfahrzeug, oder einem Lastkraftfahrzeug entsprechen. Die Vorrichtung 30 kann beispielsweise ein Teil oder kann ein Steuergerät des Fahrzeugs 40 sein.
Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den oben beschriebenen Ausführungsbeispielen erwähnt. Das in Fig. 3 gezeigte Ausfiihrungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren oben (z. B. Fig. 1 - 3) beschriebenen Ausführungsbeispielen erwähnt wurden.
Weitere Ausführungsbeispiele sind Computerprogramme zur Durchführung eines der hierin beschriebenen Verfahren, wenn das Computerprogramm auf einem Computer, einem Prozessor, oder einer programmierbaren Hardwarekomponente abläuft. Je nach bestimmten Implementierungsanforderungen können Ausführungsbeispiele der Erfindung in Hardware oder in Software implementiert sein. Die Implementierung kann unter Verwendung eines digitalen Speichermediums, beispielsweise einer Floppy-Disk, einer DVD, einer Blu-Ray Disc, einer CD, eines ROM, eines PROM, eines EPROM, eines EEPROM oder eines FLASH-Speichers, einer Festplatte oder eines anderen magnetischen oder optischen Speichers durchgeführt werden, auf dem elektronisch lesbare Steuersignale gespeichert sind, die mit einer programmierbaren Hardwarekomponente derart Zusammenwirken können oder Zusammenwirken, dass das jeweilige Verfahren durchgeführt wird.
Eine programmierbare Hardwarekomponente kann durch einen Prozessor, einen Computerprozessor (CPU = Central Processing Unit), einen Grafikprozessor (GPU = Graphics Processing Unit), einen Computer, ein Computersystem, einen anwendungsspezifischen integrierten Schaltkreis (ASIC = Application-Specific Integrated Circuit), einen integrierten Schaltkreis (IC = Integrated Circuit), ein Ein-Chip -System (SOC = System on Chip), ein programmierbares Logikelement oder ein feldprogrammierbares Gatterarray mit einem Mikroprozessor (FPGA = Field Programmable Gate Array) gebildet sein.
Das digitale Speichermedium kann daher maschinen- oder computerlesbar sein. Manche Ausführungsbeispiele umfassen also einen Datenträger, der elektronisch lesbare Steuersignale aufweist, die in der Lage sind, mit einem programmierbaren Computersystem oder einer programmierbare Hardwarekomponente derart zusammenzuwirken, dass eines der hierin beschriebenen Verfahren durchgeführt wird. Ein Ausführungsbeispiel ist somit ein Datenträger (oder ein digitales Speichermedium oder ein computerlesbares Medium), auf dem das Programm zum Durchfuhren eines der hierin beschriebenen Verfahren aufgezeichnet ist.
Allgemein können Ausführungsbeispiele der vorliegenden Erfindung als Programm, Firmware, Computerprogramm oder Computerprogrammprodukt mit einem Programmcode oder als Daten implementiert sein, wobei der Programmcode oder die Daten dahin gehend wirksam ist bzw. sind, eines der Verfahren durchzuführen, wenn das Programm auf einem Prozessor oder einer programmierbaren Hardwarekomponente abläuft. Der Programmcode oder die Daten kann bzw. können beispielsweise auch auf einem maschinenlesbaren Träger oder Datenträger gespeichert sein. Der Programmcode oder die Daten können unter anderem als Quellcode, Maschinencode oder Bytecode sowie als anderer Zwischencode vorliegen.
Die oben beschriebenen Ausführungsbeispiele stellen lediglich eine Veranschaulichung der Prinzipien der vorliegenden Erfindung dar. Es versteht sich, dass Modifikationen und Variationen der hierin beschriebenen Anordnungen und Einzelheiten anderen Fachleuten einleuchten werden. Deshalb ist beabsichtigt, dass die Erfindung lediglich durch den Schutzumfang der nachstehenden Patentansprüche und nicht durch die spezifischen Einzelheiten, die anhand der Beschreibung und der Erläuterung der Ausführungsbeispiele hierin präsentiert wurden, beschränkt sei.
Bezugszeichenliste
30 Vorrichtung
32 Schnittstelle
34 Datenverarbeitungsschaltung
40 Fahrzeug
100 Verfahren zur Durchführung durch ein Benutzerendgerät zum Beheben eines fehlerbehafteten
Zustands einer Kommunikationseinrichtung
110 Empfangen von Fahrzeuglogdaten
120 Erhalten von Prozessdaten
130 Senden der Prozessdaten
200 Verfahren zur Durchführung durch eine Steuereinheit zum Beheben eines fehlerbehafteten
Zustands einer Kommunikationseinrichtung
210 Senden von Fahrzeuglogdaten
220 Empfangen von Prozessdaten
230 Durchführen des Prozesses zur Behebung des fehlerbehafteten Zustands

Claims

Patentansprüche
1. Ein Verfahren (100) zur Durchführung durch ein Benutzerendgerät zum Beheben eines fehlerbehafteten Zustands einer Kommunikationseinrichtung eines Fahrzeugs, umfassend: Empfangen (110), von dem Fahrzeug, von Fahrzeuglogdaten indikativ für den fehlerbehafteten Zustand der Kommunikationseinrichtung; und
Erhalten (120) von Prozessdaten indikativ für einen durch das Fahrzeug durchzuführenden Prozess zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung basierend auf den Fahrzeuglogdaten; und
Senden (130), an das Fahrzeug, der Prozessdaten zum Durchführen des Prozesses zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung.
2. Das Verfahren (100) nach Anspruch 1, ferner umfassend:
Senden, an ein Backend, von Fehlfimktionsdaten indikativ für den fehlerbehafteten Zustand der Kommunikationseinrichtung; und wobei
Erhalten der Prozessdaten durch Empfangen, von dem Backend, der Prozessdaten zum Senden an das Fahrzeug erfolgt.
3. Das Verfahren (100) nach einem der vorhergehenden Ansprüche, ferner umfassend;
Erhalten von Störungsdaten indikativ für eine Störung einer Kommunikationsverbindung der Kommunikationseinrichtung; und
Etablieren einer Kommunikationsverbindung zwischen dem Benutzerendgerät und dem Fahrzeug zum Empfangen der Fahrzeuglogdaten in Antwort zum Erhalten der Störungsdaten.
4. Das Verfahren (100) nach Anspruch 3, ferner umfassend:
Senden, an das Fahrzeug, von Startdaten indikativ für ein Starten einer Speicherung von Fahrzeuglogdaten.
5. Das Verfahren (100) nach einem der vorhergehenden Ansprüche, ferner umfassend:
Empfangen, von einem Backend, von Verifizierungsdaten indikativ für eine zum Empfangen der Fahrzeuglogdaten benötigte Verifizierung; und
Senden, an das Fahrzeug, der Verifizierungsdaten zum Empfangen der Fahrzeuglogdaten.
6. Das Verfahren (100) nach einem der Ansprüche 2-5, ferner umfassend
Bestimmen der Fehlfunktionsdaten zum Senden an das Backend basierend auf den Fahrzeuglogdaten.
7. Das Verfahren (120) nach einem der Ansprüche 2-6, ferner umfassend:
Speichern der Fahrzeuglogdaten;
Bestimmen eines Kommunikationsverbindungstyps mit dem Backend; und Senden der Fahrzeuglogdaten in Abhängigkeit von dem Kommunikationsverbindungstyp.
8. Ein Verfahren (200) zur Durchführung durch eine Steuereinheit eines Fahrzeugs zum Beheben eines fehlerbehafteten Zustands einer Kommunikationseinrichtung, umfassend:
Senden (210), an ein Benutzerendgerät, von Fahrzeuglogdaten indikativ für den fehlerbehafteten Zustand der Kommunikationseinrichtung; und
Empfangen (220), von dem Benutzerendgerät, von Prozessdaten indikativ für einen durch das Fahrzeug durchzuführenden Prozess zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung; und
Durchführen (230) des Prozesses zur Behebung des fehlerbehafteten Zustands der Kommunikationseinrichtung basierend auf den Prozessdaten.
9. Ein Computerprogramm zur Durchführung eines der Verfahren (100) nach einem der vorhergehenden Ansprüche, wenn das Computerprogramm auf einem Computer, einem Prozessor, oder einer programmierbaren Hardwarekomponente abläuft.
10. Eine Vorrichtung (30) zur Diagnose einer Kommunikationseinrichtung eines Fahrzeugs, umfassend: eine Schnittstelle (32) zur Kommunikation mit einer Steuereinheit oder einem Benutzerendgerät; und eine Datenverarbeitungsschaltung (34), die zur Durchführung zumindest eines der Verfahren (100) nach einem der Ansprüche 1 - 8 ausgebildet ist.
PCT/EP2024/060467 2023-06-14 2024-04-18 Verfahren zum beheben eines fehlerbehafteten zustands einer kommunikationseinrichtung eines fahrzeugs, computerprogramm, vorrichtung und fahrzeug Ceased WO2024256064A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202480032960.8A CN121153243A (zh) 2023-06-14 2024-04-18 用于消除车辆的通信装置的错误状态的方法、计算机程序、装置和车辆

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102023115464.8 2023-06-14
DE102023115464.8A DE102023115464A1 (de) 2023-06-14 2023-06-14 Verfahren zum Beheben eines fehlerbehafteten Zustands einer Kommunikationseinrichtung eines Fahrzeugs, Computerprogramm, Vorrichtung und Fahrzeug

Publications (1)

Publication Number Publication Date
WO2024256064A1 true WO2024256064A1 (de) 2024-12-19

Family

ID=90904578

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2024/060467 Ceased WO2024256064A1 (de) 2023-06-14 2024-04-18 Verfahren zum beheben eines fehlerbehafteten zustands einer kommunikationseinrichtung eines fahrzeugs, computerprogramm, vorrichtung und fahrzeug

Country Status (3)

Country Link
CN (1) CN121153243A (de)
DE (1) DE102023115464A1 (de)
WO (1) WO2024256064A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170115877A (ko) * 2016-04-08 2017-10-18 한국전자통신연구원 Wave 통신 장치를 위한 관리 시스템
CN113815549A (zh) * 2021-09-26 2021-12-21 上汽通用五菱汽车股份有限公司 车辆用户连接单元的重启方法、装置及计算机可读介质

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170115877A (ko) * 2016-04-08 2017-10-18 한국전자통신연구원 Wave 통신 장치를 위한 관리 시스템
CN113815549A (zh) * 2021-09-26 2021-12-21 上汽通用五菱汽车股份有限公司 车辆用户连接单元的重启方法、装置及计算机可读介质

Also Published As

Publication number Publication date
CN121153243A (zh) 2025-12-16
DE102023115464A1 (de) 2024-12-19

Similar Documents

Publication Publication Date Title
EP1516291B1 (de) Verfahren und vorrichtung für einen fahrzeugbezogenen telematikdienst
EP1518383B1 (de) Verfahren und vorrichtung zum senden und/oder zum empfang von informationen in verbindung mit einem fahrzeug
DE102015216121B4 (de) Weiterleitungsvorrichtung
US9805520B2 (en) Method and system for providing vehicle security service
DE102018122152A1 (de) Systeme und verfahren zur eindringungserkennung in das netzwerk im fahrzeug
DE102017121073A1 (de) Diagnostic methods and apparatuses in vehicle network
DE102018122143A1 (de) Systeme und verfahren zur eindringungserkennung in das netzwerk im fahrzeug
DE102017200958A1 (de) Betriebsmodus-übergangsverfahren in einem netz
DE102015207657A1 (de) Gerät und verfahren zur fehlerüberwachung mit einem diagnosemodul
DE112012001923T5 (de) Zur Zusammenarbeit fähiges Multi-Agentensystem zur Fehlerdiagnose an einem Fahrzeug sowie zugehöriges Verfahren
CN102780713A (zh) 车辆诊断系统及方法
DE102018114778A1 (de) Verfahren zum Verhindern von Diagnosefehlern im Fahrzeugnetzwerk und Vorrichtung dafür
DE102017206422A1 (de) Verfahren zur energieversorgung in einem netzwerk und vorrichtung hierfür
DE102016210274A1 (de) Betriebsverfahren eines kommunikationsknotens in einem fahrzeugnetz
DE102016208749A1 (de) Betriebsverfahren eines kommunikationsknotens in einem automobil-netzwerk
DE10257030A1 (de) Verfahren und Vorrichtung für einen fahrzeugbezogenen Telematikdienst
DE102020209221A1 (de) Verfahren zum Koppeln und Ankoppeln eines Sensors und Kommunikationsnetzwerk
KR20240017005A (ko) 원격 차량 통신 필터링
DE102014202826A1 (de) Teilnehmerstation für ein Bussystem und Verfahren zur Erhöhung der Datenrate eines Bussystems
DE102013017951A1 (de) Elektronische Steuervorrichtung und Verfahren zum Überprüfen einer Rücksetzfunktion
DE102020208536A1 (de) Gateway-vorrichtung, abnormitätsüberwachungsverfahren und speichermedium
DE102016208750A1 (de) Betriebsverfahren eines kommunikationsknotens in einem fahrzeugnetz
DE102023115464A1 (de) Verfahren zum Beheben eines fehlerbehafteten Zustands einer Kommunikationseinrichtung eines Fahrzeugs, Computerprogramm, Vorrichtung und Fahrzeug
DE102010028485B4 (de) Verfahren und Vorrichtung zur Absicherung von über eine Schnittstelle zu übertragenden Datenpaketen
DE102021207870A1 (de) Verfahren und Recheneinheit zum Verwalten von Diagnoseanfragen in einem Netzwerk

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: 24721889

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE