Method for remedying a faulty state of a communication device of a vehicle, computer program, device, and vehicle
The method uses vehicle log data to send corrective process data directly to the vehicle, allowing for remote fault correction of communication devices without a workshop visit or external connection, addressing the inefficiencies of existing methods and enhancing user experience.
Patent Information
- Application Number
- PCT/EP2024/060467
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-06-14
- Filing Date
- 2024-04-18
- Publication Date
- 2024-12-19
AI Technical Summary
Existing methods for correcting faulty communication devices in vehicles often require a workshop visit or external backend connection, which increases user effort and is inefficient.
A method that uses vehicle log data to obtain and send process data to the vehicle, allowing it to correct faulty communication device states without a workshop visit or external connection, by receiving and analyzing log data at a user terminal and sending corrective process data directly to the vehicle.
Enables remote correction of communication device faults, reducing user effort and eliminating the need for external connections, thereby improving user experience and efficiency.
Smart Images

Figure EP2024060467_19122024_PF_FP_ABST
Abstract
Description
[0001] Method for correcting a faulty state of a communication device of a vehicle, computer program, device and vehicle
[0002] Description
[0003] 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 transmitting process data for carrying out a process for correcting the faulty state of the communication device.
[0004] A problem in a communication link of a communication device, for example, internet connectivity, that prevents or impairs the connection of a vehicle's communication device to a backend system, for example, a vehicle manufacturer's backend system, is typically addressed with corrective actions. A corrective action may trigger a reset of the communication link or the vehicle's communication device after the problem is detected. However, such a corrective action requires the problem to be detected on the vehicle side. Furthermore, a corrective action by a vehicle side may not be sufficient to re-establish the communication link.
[0005] Alternatively, a problem with a vehicle's communication device can be analyzed and resolved by visiting a workshop. The workshop provides direct access to the vehicle's electrical system and thus to every system and communication device in the vehicle, for example, via a vehicle diagnostics port. However, troubleshooting a problem in a workshop increases the workload for the vehicle user.
[0006] There is therefore a need to provide an improved method for correcting a faulty state of a vehicle's communication device. The methods, the device, the computer program, and the vehicle according to the independent claims address this need.
[0007] 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 is indicative of a process to be performed by the vehicle to correct the faulty state of the communication device. The process data is obtained based on vehicle log data. By using the process data, the vehicle can receive information for correcting the faulty state of the communication device. Based on the process data, the vehicle or a control unit of the vehicle can correct the error.
[0008] Embodiments relate to a method for implementation by a user terminal for rectifying 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 receiving process data indicative of a process to be implemented by the vehicle for rectifying the faulty state of the communication device based on the vehicle log data. The method further comprises transmitting the process data for implementing 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 in the vehicle. Using vehicle log data, an analysis of the faulty state of the communication device can be performed. Based on this analysis, process data can then be obtained, for example, from a backend, containing information for rectifying the faulty state of the communication device. By sending the process data, the vehicle can receive this information for rectifying the faulty state of the communication device. This allows the faulty state of the communication device to be rectified without a visit to a workshop and without the need for a communication connection between the vehicle and a backend.
[0009] In one embodiment, 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. Obtaining the process data at the user terminal may occur by receiving the process data from the backend. The process data is received for transmission to the vehicle. By receiving the process data from the backend, the user terminal can obtain the information required to rectify the faulty state of the communication device with increased reliability. In particular, the backend can identify a plurality of faulty states of the communication device based on the malfunction data. In particular, a probability that the backend can determine process data for rectifying the faulty state of the communication device may be increased compared to the user terminal.
[0010] In one embodiment, the method may further comprise obtaining fault data indicative of a fault in a communication connection of the communication device. Furthermore, the method may 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. Receiving the fault data may trigger rectification of the faulty state of the communication device. For example, a user may detect a faulty communication connection of the communication device. The user may then perform an input on the user terminal. Based on the input, the fault data may be determined.By using the fault data, a communication connection can then be established to receive the vehicle log data as needed. This allows information to be exchanged between the user device and the vehicle when necessary.
[0011] In one embodiment, 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.
[0012] In one embodiment, 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 can be used to prove authorization of the user terminal to receive the vehicle log data. For example, the vehicle log data can be confidential. For example, the vehicle log data can only be sent to an authorized backend. By receiving the verification data from the backend and sending the verification data to the vehicle, the user terminal can prove authorization to receive the vehicle log data.In one embodiment, the method may further comprise determining the malfunction data to be sent to the backend based on the vehicle log data. By determining the malfunction data, data transfer between the backend and the user terminal can be reduced.
[0013] In one embodiment, the method may further comprise storing the vehicle log data and determining a communication connection type with the backend. Furthermore, the method may comprise sending the vehicle log data depending on the determined communication connection type. This allows data transfer between the backend and the user terminal to be adapted to an available data volume.
[0014] In one embodiment, 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. Furthermore, the method may comprise receiving further chat data indicative of a response to the user request from the user terminal from the backend. By sending the chat data, communication can take place between the user and a service person. This can improve the user experience.
[0015] Embodiments relate to a method for implementation by a control unit of a vehicle for rectifying a faulty state of the communication device. The method comprises sending, to a user terminal, vehicle log data indicative of the faulty state of the communication device. Furthermore, the method comprises receiving, from the user terminal, process data indicative of a process to be implemented by the vehicle for rectifying the faulty state of the communication device. The method further comprises implementing the process for rectifying the faulty state of the communication device based on the process data. This allows the vehicle or the control unit to rectify a faulty state of the communication device without an external connection to a backend or a visit to a workshop.
[0016] Embodiments also provide a computer program for performing one of the methods described herein when the computer program runs on a computer, a processor, or a programmable hardware component.
[0017] Another 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 configured to perform at least one of the methods described herein. Embodiments further provide a vehicle with a device as described herein.
[0018] Exemplary embodiments are explained in more detail below with reference to the accompanying figures. They show:
[0019] 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;
[0020] 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;
[0021] Fig. 3 shows a block diagram of an embodiment of a device for correcting a faulty state of a communication device of a vehicle.
[0022] Various embodiments will now be described in more detail with reference to the accompanying drawings, in which some embodiments are illustrated. In the figures, the thickness dimensions of lines, layers, and / or regions may be exaggerated for clarity.
[0023] 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 is received 110 at the user terminal from the vehicle, for example, from the communication device or another communication device of the vehicle.
[0024] By receiving 110 vehicle log data, the faulty state of the communication device can be remedied using the user terminal. A faulty state of the communication device can be a state in which not all functions of the communication device function. For example, a faulty state of the communication device can be a state in which connectivity of the communication device is limited. For example, a faulty state of the communication device can be a state in which a communication connection to a backend cannot be established and / or maintained.
[0025] 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 vehicle's condition, performance, and behavior. For example, a communication device in the vehicle can generate vehicle log data specific to the vehicle's or communication device's communication functions. This vehicle log data can include information about a wireless communication link, connectivity, a software update, a communication protocol, and / or other associated metadata. For example, the vehicle log data can include system and / or error logs.The system and / or error logs may contain log data that assists in troubleshooting and diagnosing communication problems, such as error codes, error descriptions, timestamps, and information about failed connections or transmissions. Thus, by receiving 110 the vehicle log data, the user terminal can obtain the information needed to determine the faulty state of the communication device.
[0026] The method 100 further comprises obtaining 120 process data indicative of a process to be performed by the vehicle to rectify 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 comprise receiving the process data from a backend or determining it by the user terminal. For example, the user terminal may read the process data from a storage unit. For example, process data for rectifying 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. Alternatively or optionally, the user terminal may receive the process data from a backend.
[0027] The process data can include information required to correct the faulty state of the communication device. In particular, the process data can be used to correct the faulty state of the communication device. For example, the process data can include diagnostic commands and / or diagnostic jobs. By using the process data, the vehicle, for example, a control unit of the vehicle and / or the communication device with the faulty state, can correct the faulty state of the communication device.
[0028] Furthermore, the method 100 includes sending 120 the process data for executing 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. By sending 120 the process data, 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. By receiving 110 the vehicle log data from the vehicle, the user terminal can access the vehicle log data. By sending 130 the process data, the user terminal can set diagnostic commands for the vehicle or the communication device.This allows the user device to trigger a faulty communication connection failure in the communication device if the communication connection fails. This avoids the need to analyze and resolve communication connection issues in a workshop, thus improving the user experience.
[0029] For example, an application installed on the user terminal can be used to carry out 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). The OEM app can be terminated for error analysis and / or troubleshooting of a communication device. For example, 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.
[0030] 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. For example, 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 achieved via the local communication connection. Furthermore, the local communication connection can enable remote control of diagnostic commands using the process data. This makes it possible, even in the event of a total vehicle connectivity failure, to analyze the problem remotely by accessing the vehicle log data via the user device and, if necessary, to resolve the problem by issuing diagnostic commands.
[0031] Optionally or alternatively, the OEM app can serve as a communication channel with the user (e.g., via a chat built into the OEM app). This can prompt the user to establish the necessary Wi-Fi and / or Bluetooth connection with the vehicle and / or perform other actions. Since vehicle log data is generally not enabled for the user by default, the necessary vehicle log data can also be enabled in the affected vehicle via the connection to the OEM app. After completing an analysis and, optionally, resolving the faulty status of the communication device, vehicle log data logging can be disabled or configured accordingly.
[0032] In one embodiment, 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. Obtaining 120 the process data may occur by receiving the process data from the backend. The process data is received at the user device for transmission to the vehicle. By sending the malfunction data, the backend may be informed of a malfunction, i.e., the faulty state of the communication device. This malfunction data may be identical to the vehicle log data. For example, the user device may forward the vehicle log data to the backend.
[0033] Alternatively, the user terminal can determine the malfunction data based on the vehicle log data. The malfunction data can only comprise a portion of the vehicle log data. For example, 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 contain information regarding a specific error code), the user terminal can determine malfunction data. The generated malfunction data can comprise the error code or the error description. The generated malfunction data can then be sent to the backend.This can, in particular, reduce data transfer between the user terminal and the backend. The backend can have more information regarding measures to correct the faulty state of the communication device than the user terminal. For example, 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. By connecting the user terminal to the backend, the corrective action to the faulty state of the communication device can be improved.
[0034] In one embodiment, the method 100 may further comprise obtaining fault data indicative of a fault in a communication connection of the communication device. Furthermore, the method 100 may 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. For example, 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 can then establish a communication connection, in particular a local communication connection, with the vehicle, for example, with another communication device of the vehicle. Triggered by the fault data, the user terminal can thus establish a connection with the vehicle for receiving the vehicle log data.
[0035] Alternatively or optionally, the user terminal can receive the fault data. For example, the user terminal can receive the fault data based on a user input. For example, a user can determine that a vehicle's navigation service is faulty, e.g., because the connectivity of a vehicle's navigation software 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 user input. This can trigger the user to receive the vehicle log data.
[0036] In one embodiment, method 100 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. The vehicle may not permanently store the vehicle log data, for example, to reduce storage requirements. Based on the fault data, the user terminal can trigger storage by sending the start data. This allows the vehicle to only store the vehicle log data if it might be needed to identify and / or rectify a faulty state of the communication device. This allows storage requirements for rectifying the faulty state of the communication device to be reduced and / or dynamically controlled.
[0037] In one embodiment, method 100 may further comprise receiving verification data indicative of a verification required to receive the vehicle log data. The verification data is received by the backend. 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. In particular, the vehicle log data may only be accessible to certain devices, for example, a backend of a vehicle manufacturer. Using the verification data, another device, for example, the user terminal, can be configured or authorized to receive the vehicle log data. The backend verification data can therefore certify that the user terminal is authorized to receive the vehicle log data.By sending the verification data from the user terminal to the vehicle, 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.
[0038] Optionally, the verification data can include a time limit. For example, the verification data can only be valid for a defined time window. This allows the user terminal to receive the vehicle log data only during this defined time window. The defined time window can include a time that is typically required to rectify a faulty state of the communication device. For example, the method 100 can include a first step for rectifying 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 rectify the faulty state of the communication device. The further verification data can, for example, comprise a defined time window required to rectify an identified faulty state. In one embodiment, the method 100 can further comprise determining the malfunction data for transmission to the backend based on the vehicle log data. As described above, the user terminal can determine the malfunction data. In this case, the malfunction data can comprise part of the vehicle log data. Alternatively or optionally, the malfunction data can also be merely indicative of an identified faulty state of the communication device.For example, the malfunction data can include an error code and / or a description of the faulty state of the communication device. By determining the malfunction data, data transfer between the backend and the user terminal can be reduced. In particular, transmission of the entire vehicle log data can be avoided.
[0039] In one embodiment, method 100 may further comprise storing the vehicle log data and determining a communication connection type with the backend. Furthermore, the method may comprise sending the vehicle log data depending on the communication connection type. For example, the user terminal may be connected to the backend via a mobile communication connection. In this case, a data volume of the mobile communication connection may depend on a user's contract. In particular, the data volume may be limited. Therefore, sending the vehicle log data may place a significant strain on the user's data volume. As a result, a user experience may be impaired by an unwanted increase in data consumption of the mobile communication connection.Alternatively, the user terminal can be connected to a router via a local communication connection, for example, a Wi-Fi communication connection, and to the backend via the router. The data volume of this connection can be larger than that of the mobile communication connection. Accordingly, sending the vehicle log data to the backend can be limited to a local communication connection, for example, to a router. This can improve the user experience.
[0040] In one embodiment, method 100 may further include sending chat data indicative of a user request from the user terminal. The chat data is sent to the backend. Furthermore, method 100 may include receiving further chat data indicative of a response to the user request (from a user) from the user terminal from the backend. For example, an OEM app may be used to enter the chat data. The user may receive support using the chat data. This may improve the user experience.
[0041] In one embodiment, method 100 may further include establishing a local communication connection between the user terminal and the communication device for receiving the vehicle log data. This allows the vehicle log data to be received even if the vehicle or the communication device cannot establish a mobile communication connection.
[0042] 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.
[0043] An example of a method for resolving a faulty state of the communication device can proceed as follows. A user can detect a vehicle connectivity failure, for example, due to missing traffic data on the navigation system or missing music streaming in an application. The user can enter an input using the user terminal. The user terminal can determine fault data based on the input. Alternatively or optionally, the user can contact support regarding the vehicle connectivity failure using an OEM app. For example, the user can send chat data via the OEM app in a support chat.
[0044] A support employee, such as 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 prompted to establish a Wi-Fi and / or Bluetooth connection between the vehicle and the user device. Once the Wi-Fi and / or Bluetooth connection is established, the support employee can retrieve the necessary vehicle log data via the OEM app.
[0045] Optionally, if the vehicle log data is not activated or is confidential, the support employee can initiate or trigger the activation of the vehicle log data using an appropriate security mechanism. If the vehicle connectivity failure can be attributed to a known faulty condition of a communication device with a predefined process for correcting the faulty condition, the support employee can forward the necessary diagnostic jobs to the user device. The necessary diagnostic jobs can be included in the process data. The user device can then send the process data to the vehicle. The vehicle or a vehicle control unit can then correct the faulty condition based on the diagnostic job.
[0046] After the user has confirmed vehicle connectivity, the support representative can disable in-vehicle logging and close a communication device faulty state request. If the problem cannot be assigned to a known faulty state, the support representative can forward the vehicle log data to an appropriate development department. The appropriate development department can initiate an analysis. Furthermore, the appropriate development department can inform the user of the analysis. Alternatively, if the user's device is directly connected to the vehicle via Wi-Fi and / or Bluetooth, the vehicle can automatically report the communication device faulty state to an OEM support center via the OEM app without customer interaction.This allows the Support Center to initiate the analysis and resolution of the faulty condition via the OEM app itself, resolve the issue, and contact the user if necessary.
[0047] The user terminal can generally be a device capable of wireless communication. In particular, the user terminal can be a mobile user terminal, e.g., a user terminal suitable for being carried by a user. The user terminal can be, e.g., a user terminal (UT) or user equipment (UE) within the meaning 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.
[0048] Further details and aspects are mentioned in connection with the embodiments described below. The embodiment shown in Fig. 1 may include 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).
[0049] Fig. 2 shows a schematic representation of another 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 to the method for implementation by a user terminal described with reference to Fig. 1. In particular, the method 200 can be implemented within the framework of a transmitter and receiver using the method from Fig. 1.
[0050] 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. Furthermore, the method 200 includes receiving 220, from the user terminal, process data indicative of a process to be performed by the vehicle to rectify the faulty state of the communication device. The method 200 further includes executing 230 the process for rectifying the faulty state of the communication device based on the process data. This allows the vehicle to rectify a faulty state of the communication device without an external connection to a backend or a visit to a workshop. The method 200 can be performed by a control unit that includes the communication device with the faulty state.Alternatively, method 200 may be performed by a control unit that includes another communication device. The communication device with the faulty state may be external to the control unit.
[0051] The communication device may generally be a device capable of wireless communication. The communication device may communicate with a backend, e.g., a base station, in a mobile communication system. For example, the communication device may communicate within / via a mobile communication system. The mobile communication system may include a plurality of transmission points and / or base stations capable of transmitting radio signals with the communication device.
[0052] Further details and aspects are mentioned in connection with the embodiments described below and / or above. The embodiment shown in Fig. 2 may include 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).
[0053] 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 described with reference to Fig. 1 for the user terminal or with reference to Fig. 2 for the control unit. Further embodiments include a vehicle 40 with a device 30, e.g., a control unit 30.
[0054] The interface 32 shown in Fig. 3 can, 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 configured to communicate with other network components via a (radio) network or a local area network.
[0055] In exemplary embodiments, the data processing circuit 34 can correspond to any controller or processor or a programmable hardware component. For example, the data processing circuit 34 can also be implemented as software programmed for a corresponding hardware component. In this respect, 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. Exemplary embodiments are not limited to a specific type of processor. Any processor or even multiple processors are conceivable for implementing the data processing circuit 34.
[0056] As shown in Fig. 3, the interface 32 can be coupled to the respective data processing circuitry 34 of the device 30. In examples, the device 30 can 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. Likewise, the described functions of the data processing circuitry 34 can also be implemented in software, which is then executed on one or more programmable hardware components. Such hardware components can be a general-purpose processor, a digital signal processor (DSP), a microcontroller, etc.The data processing circuit 34 may be capable of controlling the interface 32 such that any data transfer that occurs over the interface 32 and / or any interaction that the interface 32 may be involved in can be controlled by the data processing circuit 34.
[0057] In one embodiment, 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.
[0058] In examples, interface 32 may correspond to any means for obtaining, receiving, transmitting, or providing analog or digital signals or information, e.g., any terminal, contact, pin, register, input terminal, output terminal, conductor, trace, etc., that enables the provision or receipt of a signal or information. Interface 32 may be wireless or wired and may be configured to communicate with other internal or external components, e.g., to send or receive signals or information.
[0059] In at least some embodiments, the vehicle 40 may, for example, correspond 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 a control unit of the vehicle 40.
[0060] Further details and aspects are mentioned in connection with the embodiments described above. The embodiment shown in Fig. 3 may include 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).
[0061] Further embodiments are computer programs for carrying out one of the methods described herein when the computer program runs on a computer, a processor, or a programmable hardware component. Depending on specific implementation requirements, embodiments of the invention can be implemented in hardware or in software. The implementation can be carried out using 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 storage device 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.
[0062] A programmable hardware component can be formed by a processor, a computer processor (CPU = Central Processing Unit), a graphics processor (GPU = Graphics Processing Unit), a computer, a computer system, an application-specific integrated circuit (ASIC = Application-Specific Integrated Circuit), an integrated circuit (IC = Integrated Circuit), a single-chip system (SOC = System on Chip), a programmable logic element or a field-programmable gate array with a microprocessor (FPGA = Field Programmable Gate Array).
[0063] The digital storage medium can therefore be machine- or computer-readable. Some embodiments thus comprise a data carrier having electronically readable control signals capable of interacting with a programmable computer system or a programmable hardware component such that one of the methods described herein is performed. One embodiment is thus a data carrier (or a digital storage medium or a computer-readable medium) on which the program for performing one of the methods described herein is recorded.
[0064] In general, embodiments of the present invention can be implemented as a program, firmware, computer program, or computer program product with program code or data, wherein the program code or data is effective to perform one of the methods when the program runs on a processor or a programmable hardware component. The program code or data can also be stored, for example, on a machine-readable medium or data carrier. The program code or data can be present, among other things, as source code, machine code, or bytecode, as well as other intermediate code.
[0065] The above-described embodiments are merely illustrative of the principles of the present invention. It is understood that modifications and variations of the arrangements and details described herein will be apparent to others skilled in the art. Therefore, it is intended that the invention be limited only by the scope of the following claims and not by the specific details presented in the description and explanation of the embodiments herein.
[0066] List of reference symbols
[0067] 30 Device
[0068] 32 interface
[0069] 34 Data processing circuit
[0070] 40 vehicles
[0071] 100 Procedures to be performed by a user terminal to correct a faulty
[0072] Condition of a communication device
[0073] 110 Receiving vehicle log data
[0074] 120 Obtaining process data
[0075] 130 Sending the process data
[0076] 200 Method to be carried out by a control unit to rectify a faulty
[0077] Condition of a communication device
[0078] 210 Sending vehicle log data
[0079] 220 Receiving process data
[0080] 230 Perform the process to correct the faulty condition
Claims
Patent claims 1. A method (100) for performing by a user terminal for resolving a faulty state of a communication device of a vehicle, comprising: receiving (110), from the vehicle, vehicle log data indicative of the faulty state of the communication device; and Obtaining (120) process data indicative of a process to be performed by the vehicle to correct the faulty state of the communication device based on the vehicle log data; and Sending (130) to the vehicle the process data for performing the process for correcting the faulty state of the communication device.
2. The method (100) of claim 1, further comprising: Sending, to a backend, malfunction data indicative of the faulty state of the communication device; and wherein Obtaining the process data by receiving, from the backend, the process data for sending to the vehicle.
3. The method (100) of any preceding claim, further comprising; Obtaining fault data indicative of a fault in a communication link of the communication device; and Establishing a communication connection between the user terminal and the vehicle for receiving the vehicle log data in response to receiving the fault data.
4. The method (100) of claim 3, further comprising: Sending, to the vehicle, start data indicative of starting a storage of vehicle log data.
5. The method (100) according to any one of the preceding claims, further comprising: Receiving, from a backend, verification data indicative of a verification required to receive the vehicle log data; and Send, to the vehicle, the verification data to receive the vehicle log data.
6. The method (100) according to any one of claims 2-5, further comprising Determine the malfunction data to send to the backend based on the vehicle log data.
7. The method (120) of any of claims 2-6, further comprising: Saving vehicle log data; Determining a communication connection type with the backend; and sending the vehicle log data depending on the communication connection type.
8. A method (200) for performing by a control unit of a vehicle for correcting a faulty state of a communication device, comprising: Sending (210), to a user terminal, vehicle log data indicative of the faulty state of the communication device; and Receiving (220), from the user terminal, process data indicative of a process to be performed by the vehicle to correct the faulty state of the communication device; and Performing (230) the process for correcting the faulty state of the communication device based on the process data.
9. A computer program for carrying out one of the methods (100) according to one of the preceding claims, when the computer program runs on a computer, a processor, or a programmable hardware component.
10. A device (30) for diagnosing a communication device of a vehicle, comprising: an interface (32) for communication with a control unit or a user terminal; and a data processing circuit (34) configured to carry out at least one of the methods (100) according to any one of claims 1-8.
Citation Information
Patent Citations
Restarting method and device for vehicle user connection unit and computer storage medium
CN113815549A
Manage system for wireless access vehicle environment communication device
KR1020170115877A
