Communication bridge for an in-vehicle user interface and an OBD interface

Abstract

The invention relates to various methods for communication between in-vehicle control devices and an in-vehicle user interface, in particular an infotainment system, wherein the communication is mediated by a mobile terminal and a communication device, in particular an OBD dongle.

Description

[0001] Hella Gutmann Solutions GmbH P148757PC00

[0002] Communication bridge for a vehicle-side user interface and an OBD interface

[0003] The invention relates to various methods for communication between vehicle control units and a vehicle user interface, in particular an infotainment system, wherein the communication is mediated by a mobile terminal and a communication device, in particular an OBD dongle.

[0004] Modern vehicles are complex electrical and mechanical systems that utilize many interconnected components to ensure safe and efficient operation. These components can be susceptible to malfunctions, failures, and errors that can impair vehicle performance. When such malfunctions, failures, or errors occur, the affected component may trigger a corresponding fault code, such as a Diagnostic Trouble Code (DTC). The fault code is typically generated by a vehicle control unit and stored in the vehicle's memory. Depending on the severity of the fault, a warning signal or error message may then be displayed, prompting the driver to visit a repair shop.

[0005] The increasing networking of control units in today's motor vehicles offers ever better possibilities for influencing functionalities in the vehicle, e.g. better diagnostic possibilities in case of faults or possibilities for remote control of functions and / or components of the vehicle.

[0006] By analyzing the error code, it's possible to determine which vehicle components are faulty or defective and, for example, require repair. This so-called vehicle diagnostics typically utilizes a diagnostic interface in the vehicle, often located in the driver's footwell.

[0007] Typically, an external vehicle diagnostic tool is connected to the vehicle's diagnostic interface to read the stored fault codes. The diagnostic tool then analyzes these codes to diagnose which components need to be repaired or replaced to resolve the problem. Such vehicle diagnostic tools have proven their worth in everyday workshop practice.

[0008] Even with known error codes, it's often difficult to pinpoint the actual cause of the error message. For example, if an elevated coolant temperature is reported, the possible causes can be numerous, such as a lack of coolant due to a leak in the cooling system, insufficient fluid flow due to vapor lock or a faulty coolant pump, or overheating due to previous vehicle load and climatic conditions. For this reason, the vehicle is often taken to a workshop for diagnostics, even though the problem could sometimes be resolved on-site. It can also happen that upon arrival at the workshop, it's discovered that the appropriate spare parts, tools, or qualified personnel are lacking to fix the problem.In this case, it would have been better to visit a different workshop that would have been able to fix the problem.

[0009] There are also situations where a vehicle diagnostic tool is unavailable or where trained personnel to interpret or operate the tool are lacking. For example, if a vehicle breaks down, on-site vehicle diagnostics, let alone a comprehensive, vehicle-specific diagnostic, are often impossible. Similarly, on-site vehicle diagnostics are not always feasible during test drives in remote areas. For instance, unusual behavior might occur during the test drive, behavior that only manifests in a very specific driving situation. A thorough examination by an expert or developer would be desirable, but such an expert is rarely readily available.

[0010] Furthermore, many vehicle diagnostic functions are not possible or permitted during vehicle operation or while driving for safety reasons, so that the driver is not distracted and dangerous situations do not arise.

[0011] Thus, it is not possible for the driver to obtain information such as error codes from the control units via the infotainment system installed in many modern vehicles, or even to perform vehicle diagnostics, because the vehicle manufacturer does not allow a connection between the infotainment system and the diagnostic interface or a data transfer between the two due to commercial, legal, or safety considerations.

[0012] Due to the increasing complexity of vehicle technology, there is a need for fast and reliable fault diagnosis, especially on-site in the event of a breakdown, outside of a workshop, and / or while the vehicle is in operation. In particular, it would be desirable to find a practical solution for fault diagnosis.

[0013] KR 2020 0054369 A and US 11 254 171 Bl disclose procedures in which vehicle data is read and further used.

[0014] The present invention is defined by the subject matter of the independent claims. Advantageous embodiments are described in the following description and in the dependent claims.

[0015] According to a first aspect, a method is provided. The method is carried out by a diagnostic device configured to communicate with at least one vehicle control unit via a vehicle-side diagnostic interface and with a mobile device via a first communication link, in particular a first wireless near-field connection. The method comprises the following steps:

[0016] Requests and / or receipt of diagnostic data from at least one vehicle-side control unit,

[0017] Sending diagnostic data and / or data derived from diagnostic data and / or a diagnostic message based on diagnostic data to a vehicle-side user interface via the mobile device.

[0018] According to a second aspect, a method is provided. The method is carried out by a mobile device configured to communicate with a diagnostic device via a first communication link, in particular a first wireless near-field connection, and with a vehicle-side user interface via a second communication link, in particular a second wireless near-field connection. The method comprises the following steps:

[0019] Requesting and / or receiving diagnostic data and / or data derived from the diagnostic data and / or a diagnostic message based on the diagnostic data from the diagnostic device connected to at least one vehicle-side control unit, sending the diagnostic data and / or the data derived from the diagnostic data and / or the diagnostic message to the vehicle-side user interface.

[0020] According to a third aspect, a procedure is provided. The procedure is carried out via a vehicle-side user interface, which is designed to communicate with a mobile device via a second communication link, in particular a second wireless near-field connection or a wired connection, and the procedure comprises the following steps:

[0021] Receiving diagnostic data and / or data derived from the diagnostic data and / or a diagnostic message based on the diagnostic data from a diagnostic device connected to at least one vehicle control unit via the mobile device,

[0022] Displaying the diagnostic data and / or the data derived from the diagnostic data and / or the diagnostic message.

[0023] The methods described in the first, second, and third aspects complement each other and are, in particular, compatible. Therefore, the features and procedures of the methods described in the first, second, and third aspects can be combined. For the sake of simplicity, the following text sometimes refers to "the method" or "at least one of the methods." It is clear to those skilled in the art that this could refer to only one of the methods, at least one, at least two, or all three methods.

[0024] Receiving or sending data can be configured such that the data is received directly from a sender or indirectly from a first sender via at least one further sender, or that the data is sent directly to a receiver or indirectly via at least one further receiver to a final receiver. This does not apply unless it is explicitly stated that the corresponding data, messages, replies, or requests come directly from a sender or are sent directly to a receiver. A direct communication link typically exists between the vehicle's control unit and the communication device, between the communication device and the mobile device, and / or between the mobile device and the vehicle's user interface. Indirect connections, therefore, generally exist between units that are not directly connected to each other.The first and / or second communication link can be wired or wireless. Both are typically configured as bidirectional connections. Data is often exchanged in the form of data packets over these links.

[0025] The communication device and the mobile device can be configured to communicate with each other via a specific first application (first app). Data can be transferred via the first application, and functions of the communication device can be used with the mobile device. Using the first application, certain functions of the communication device can be executed, while the user can control them via the mobile device.

[0026] The vehicle's user interface and the mobile device can be configured to communicate with each other via a specific second application (second app). Data can be transferred through the second application, and functions of the mobile device can be used with the user interface. Using the second application, certain application programs ("apps") can be run on the mobile device, while the user can control them via the user interface.

[0027] The second application is preferably one certified by the vehicle manufacturer. Examples of such applications include the Hella Gutmann app, Apple CarPlay, Huawei HiCar, Nokia MirrorLink, and Google Android Auto. The mobile device can thus act as a communication bridge between the communication device and the user interface. This allows functions of the communication device to be used with the user interface. Certain functions of the communication device can be executed while the user controls them via the user interface. In particular, diagnostic data, data derived from the diagnostic data, and / or the diagnostic message can be displayed on the user interface.

[0028] The communication device and the mobile terminal can be described as a communication bridge for the vehicle-side user interface and the diagnostic interface.

[0029] The procedure may include the additional step of performing a vehicle diagnostic based on the diagnostic data. This step can be carried out, for example, via the communication device, the mobile device, or the vehicle's user interface. The term "vehicle diagnostic" does not necessarily refer to a complete diagnosis of all available fault codes. Rather, the vehicle diagnostic can be limited to individual control units or their fault codes, for example, individual control units selected by the user.

[0030] From a legal perspective, vehicle diagnostics while driving are not permitted in conventional systems, as the driver should not be distracted by the use of an external device such as a mobile phone or vehicle diagnostic tool. On the other hand, the vehicle's user interface in conventional systems is specifically designed to allow the driver to use it while driving. By enabling interaction between the user interface and the communication device or control units, as described in this invention, the user can access the user interface for vehicle diagnostics. This allows vehicle diagnostics to be performed while driving, while complying with legal requirements. The invention thus enables "diagnostic drives" or "calibration drives," during which vehicle diagnostics or calibration is performed while driving.The term "user" used in this document can include, for example, driver, vehicle occupant, passenger or technician.

[0031] The procedure according to the first or second aspect may include an additional step:

[0032] Receiving an initial message from the vehicle's user interface,

[0033] Forwarding the first message to the vehicle's control unit.

[0034] The first message may contain a command to read, write and / or change data, settings and / or programs in the vehicle's control unit.

[0035] Optionally, at least one of the above-mentioned procedures may include the following steps:

[0036] Receiving user input,

[0037] Generating a second message based on user input,

[0038] Sending the second message to the vehicle's control unit.

[0039] These steps can be performed through the user interface, the mobile device and / or the communication device.

[0040] The second message can contain a command to read, write, and / or modify data, settings, and / or programs in the vehicle's control unit. This second message can be used in addition to or as an alternative to the first message. Sometimes, both messages are identical.

[0041] Before the diagnostic data, the data derived from the diagnostic data, and / or the diagnostic message are sent or forwarded—for example, by the communication device or mobile device—they can be temporarily stored or buffered, such as in a storage unit of the communication device or mobile device. The data can therefore be sent or forwarded to the mobile device or user interface with a time delay. This delay can range from seconds to hours to days. For example, if one of the communication links (first or second) is currently unavailable, the sending or forwarding of the data can be delayed until the communication link is established.Before the diagnostic data, the data derived from the diagnostic data, and / or the diagnostic message are sent or forwarded, they can be processed and / or evaluated in the communication device or mobile device. This allows the communication device to evaluate diagnostic data independently of the mobile device and, for example, make it available later if needed. The mobile device can also evaluate diagnostic data independently of the communication device and, for example, make it available later if needed. The evaluated diagnostic data or the results of this evaluation can be considered "data derived from the diagnostic data." Furthermore, data can be processed or generated based on the diagnostic data, for example, in the form of image or graphic files. This processed or generated data can also be interpreted as data derived from the diagnostic data.Sometimes the raw data, meaning the diagnostic data from at least one control unit, is incompatible with the user interface or the mobile device. This can be due to incompatibility in the format or type of communication connection. In such cases, the diagnostic data can be processed before being forwarded to the respective unit, allowing the receiving unit to read or process the processed data. The communication device and / or the mobile device can therefore be configured to evaluate the diagnostic data or data derived from it and, based on this evaluation, perform a specific action or send a message.

[0042] At least one, several, or all of the steps of the procedures described above can be performed while the vehicle is operating and / or driving. Vehicles often have numerous electronic control units (ECUs). Communication may be restricted to a specific group of ECUs from among these numerous units, particularly non-safety-related ECUs. Alternatively or additionally, ECUs or sensors related to tire pressure monitoring or associated with the vehicle's tires may be excluded from communication, especially communication with the terminal device, communication device, and / or the vehicle's user interface, or the vehicle diagnostics described in this document. Alternatively or additionally, communication with certain ECUs may only be possible in a predetermined operating state of the vehicle.The predetermined operating state can be, for example, the vehicle being stopped and / or parked. Accordingly, vehicle diagnostics may only be possible for these control units and / or only in this predetermined operating state. For example, control units related to the vehicle's braking and / or steering systems are usually classified as safety-relevant, which precludes communication or vehicle diagnostics with these control units. On the other hand, if the vehicle is parked or stopped, preferably for a predetermined minimum holding time, communication and / or vehicle diagnostics with these control units may be permitted, as this vehicle state is considered safe. The specific operating state, such as the safe vehicle state, can be detected by sensors, and the presence of the specific or...Information regarding a safe vehicle state can be sent to the communication device, the mobile device, and / or the vehicle's user interface. These units can also obtain information about whether a specific or safe vehicle state exists. The sensors can be vehicle-integrated sensors, such as engine speed sensors, speedometers, and motion sensors, or external sensors not part of the vehicle, such as sensors from the mobile device and / or the communication device. In addition to the aforementioned sensor data, motion data, such as GPS data, satellite data, and radio tracking signals, can also be used to assess whether the vehicle is moving.

[0043] The diagnostic data mentioned above can include fault codes, vehicle sensor readings, control unit settings, control unit information, and / or control unit operating parameters. The diagnostic message may contain a diagnostic result, a recommended course of action, or a prompt to the driver.

[0044] The communication device can be configured to trigger a message based on diagnostic data. It can also be configured to actively analyze diagnostic data or messages and, based on this analysis, initiate targeted notifications or actions. For example, a parameter received via the communication device exceeds (or falls below) a threshold. Due to this exceedance or fall below the threshold, a message is forwarded to the mobile device and / or stored in the communication device for further analysis.

[0045] The first and / or second wireless near-field connection can be implemented as a Wi-Fi and / or Bluetooth connection. Due to the short and local data connection from the communication device to the mobile device (P2P) via the first communication connection, and from the mobile device to the user interface via the second communication connection, the data privacy of usage data is significantly more secure than with a cellular connection. Before the control unit performs a specific action, authorization can be requested, for example, from the user. A corresponding message can then be sent to the user, i.e., to the user interface and / or the mobile device. The user can grant authorization on the mobile device or the user interface, whereupon the authorization is sent to the control unit, and the control unit is then permitted to perform the specific action.

[0046] According to a fourth aspect, a communication device is proposed, which is specifically designed to carry out the procedure according to the first aspect. The communication device can alternatively also be referred to as a diagnostic device.

[0047] According to a fifth aspect, a mobile device is proposed which is specifically designed to carry out the procedure according to the second aspect.

[0048] According to a sixth aspect, a vehicle-side user interface is proposed, which is specifically designed to carry out the procedure according to the third aspect.

[0049] This document therefore addresses the communication between various units in, on, or near the vehicle. These units include, among others, a vehicle-side control unit, a diagnostic device, a mobile terminal, and a vehicle-side user interface, which are briefly explained below.

[0050] For example, the vehicle control unit is or includes at least a drive control unit for controlling drive components of the vehicle such as the engine or transmission, a safety-relevant control unit related to the steering or braking of the vehicle, a comfort control unit for controlling comfort systems such as heating or air conditioning, a vehicle electrical system control unit, a gateway, or the like.

[0051] The communication device can be connected to a vehicle-side diagnostic interface, in particular electrically, mechanically, and / or wirelessly. The communication device is generally designed to receive diagnostic data from the vehicle's control unit. The communication device may have a connector, in particular a dongle or access protection connector, for mechanical and electrical connection to the vehicle-side diagnostic interface. Depending on the application, the diagnostic interface can be implemented as hardware and / or software. With a plug connection, the hardware component predominates, while with a wireless connection, the software component of the diagnostic interface typically predominates.

[0052] The connector can be integrated directly into the housing of the communication device, for example, in the case of a dongle. Alternatively, the connector can be connected to other components of the communication device via an extension cable, for example, in the case of a dedicated vehicle diagnostic tool. In some cases, a wireless communication connection between the communication device and the vehicle and its control units may be possible, either alternatively or additionally, for example, a short-range wireless connection such as Bluetooth or Wi-Fi. The communication device can be configured to process outgoing data streams from the vehicle's control units and / or to process incoming data streams from external units, particularly if the communication device is an OBD dongle.The communication device can have a first transmitting and receiving unit and a second transmitting and receiving unit, which are intended on the one hand for communication or data stream to the vehicle and on the other hand for communication or data stream from the vehicle.

[0053] The mobile device can be a mobile phone, smartphone, smartwatch, laptop, computer, tablet PC, or similar device. The mobile device can be uniquely identified by an identifier, such as an IMEI (International Mobile Equipment Identity). The mobile device can be communicatively connected to the diagnostic device, for example, wirelessly via Bluetooth or Wi-Fi and / or wired, for example, via USB. Furthermore, the mobile device can be connected to a mobile network via an air interface. This mobile network can be configured, for example, according to one of the standards G1, G2, G3, G4, G5, G6, or higher.

[0054] The vehicle-side user interface is typically designed to allow the driver to interact with the vehicle or its components. The vehicle-side user interface may include a screen, preferably a touchscreen, and / or an input unit or at least one input element for a user. The vehicle-side user interface is preferably designed as an infotainment system. The input unit allows the vehicle-side user interface to receive user input. Furthermore, an output unit may be provided, for example, for visual output in the form of a screen and / or auditory output in the form of a speaker. A combined input and output unit may also be provided, for example, in the form of a touchscreen. User input means, for example...Manual user input or remote actions, such as turning on the radio / ignition, plugging in a dongle, or Bluetooth pairing, are all possible. The vehicle's user interface can be designed as a vehicle-integrated mobile device. In this case, the vehicle-integrated mobile device can be connected to a mobile network via an wireless interface. The mobile network can be configured according to standards such as G1, G2, G3, G4, G5, G6, or higher. The vehicle-integrated mobile device can be uniquely identified by an identifier, such as an IMEI (International Mobile Equipment Identity).

[0055] According to another aspect, a system is proposed which includes the diagnostic device, the mobile terminal and / or the user interface.

[0056] According to another aspect, a computer program is provided with program code means. The computer program is configured to execute a procedure according to one of the above aspects when the computer program is executed on a computing unit, in particular a computing unit in the communication device, the mobile terminal, or the user interface.

[0057] According to another aspect, a machine-readable storage medium with a computer program stored on it is provided.

[0058] By using the existing infrastructure (user interface, communication device, mobile terminal), the described procedures can be carried out advantageously, cost-effectively, and in compliance with existing security requirements.

[0059] The technology described in this document enables, among other things, the following aspects and can have the following advantages:

[0060] Data security is ensured through short data transmission paths. Data sovereignty remains with the user / driver until they release the data. Data can be processed and transmitted in a granular manner.

[0061] Use of the infotainment system for (legally) secure communication with the driver.

[0062] Autonomous data retrieval and short-term data storage are provided. More cost-effective data processing compared to cloud solutions (no data plan required).

[0063] This technology enables the processing of specified functions (e.g., targeted reading of data from the vehicle). Data / mobile network independent use is possible through data buffering.

[0064] Low-latency data display, as the data is only transferred between the OBD-smartphone infotainment system.

[0065] Vehicle manufacturer-independent reading of diagnostic data / parameters is possible. No OEM approval of data display is required.

[0066] Future-proof, as access to the OBD connector can be used by multiple solutions.

[0067] The dongle can also be used as a platform for all kinds of digital data services (trustee platform (dongle and smartphone app)).

[0068] Diagnostic tools / appliances / smartphones may not be used while driving. However, if visualization is enabled on the vehicle's built-in display, their use / operation is legally permitted.

[0069] If permission from the vehicle user is required to use certain functions, this can be done via the display in the vehicle.

[0070] A connection is created between the vehicle infotainment system and the vehicle diagnostic bus, which makes it possible to install all kinds of apps in a vehicle with a wide variety of applications.

[0071] Interaction between infotainment / application and user (driver) can and may take place alongside the display during the journey.

[0072] This technology ensures a legal framework for the use of devices while driving (operable devices that are installed at the time of vehicle acceptance may be operated while driving).

[0073] The following section explains embodiments of the invention in more detail with reference to the accompanying figures. These figures are schematic and partially simplified. They show in

[0074] Fig. 1 shows a schematic representation of a vehicle and a communication device connected to the vehicle for performing vehicle diagnostics;

[0075] Fig. 2 shows a schematic representation of a vehicle, a communication device connected to the vehicle and a mobile terminal;

[0076] Fig. 3 shows a schematic representation of a communication process between a vehicle, a communication device, a mobile terminal and a vehicle-side user interface.

[0077] Recurring features in the figures are labelled with the same reference symbols.

[0078] Figures 1-2 show schematic representations of various systems 100 for performing a diagnostic check of a vehicle 10 (vehicle diagnostics). The vehicle 10 can be, for example, a passenger car, a motorcycle, a truck, or similar. The vehicle 10 has a large number of control units 11, 12, e.g., at least 10 or more. Many or all of the control units 11, 12 are each assigned to at least one vehicle component. The increasing networking of control units 11, 12 in today's motor vehicles offers ever better possibilities for influencing functionalities in the vehicle 10, e.g., improved diagnostic capabilities in the event of a fault or possibilities for remote control of vehicle components and / or functions of the vehicle 10. Usually, the control units 11, 12 are connected to each other, e.g., via a vehicle bus system 16, typically a CAN bus system. Here, the control unit 11 in Figure 16 can be represented as the control unit 11.Figure 1 is representative of a first group of control units 11. The second control unit 12 in Figure 1 can be representative of a second group of control units 12.

[0079] The control units 11 and 12 are typically each connected to at least one or a multitude of sensors that record measured values ​​or operating parameters during vehicle operation. Possible sensor measurements include, for example, coolant temperature, engine temperature, oil temperature, vehicle speed, engine speed, engine torque, ambient temperature (outside temperature), ambient air pressure, boost pressure of an exhaust gas turbocharger of the drive engine, the selected gear of the vehicle's transmission, electrical current, electrical voltage, electrical resistance, etc. If a measured value from a sensor falls below or exceeds a certain target value range, depending on the sensor size, the corresponding control unit 11 or 12 often generates a fault code, which is usually stored in a memory of the respective control unit 11 or 12.The fault code is assigned to a fault condition and includes, for example, a code number for identifying malfunctions that can occur during the operation of a vehicle. The fault code is also referred to as a diagnostic trouble code (DTC). Furthermore, the control units 11, 12 can be connected directly or at least indirectly, e.g., via the vehicle bus system 16 such as the CAN bus system 16, to a vehicle diagnostic interface 14. Instead of individual components 11,...

[0080] For the sake of simplicity, reference below to vehicle 10 is sometimes made only to vehicle 10.

[0081] System 100 includes at least the units 20, 30 and 40, which will be discussed in more detail below.

[0082] Figures 1 and 2 show a communication device 20, which typically comprises a control and processing unit, a memory, and at least one receiver and transmitter unit. The communication device 20 is sometimes also referred to as a diagnostic device 20 in the following. The diagnostic device 20 can usually be connected to the vehicle diagnostic interface 14 of the vehicle 10 via signal lines 15 (i.e., wired) and thus communicate with the CAN bus system 16 and the control units 11, 12.

[0083] In some embodiments, the diagnostic device 20 is designed as a dedicated vehicle diagnostic device and is configured as such to perform a diagnosis of the vehicle 10 at least partially or completely.

[0084] In some embodiments, the diagnostic device 20 can be designed as an OBD dongle, which primarily mediates communication between the vehicle 10 and an external unit 30, see Fig. 2. The abbreviation OBD used in this document stands for "on-board diagnosis". However, in addition to communication, the OBD dongle 20 can also perform other functions, such as processing or evaluating the diagnostic data or generating messages, commands, etc.

[0085] The communication device 20 typically has a connector that is compatible with and can be plugged into the vehicle diagnostic interface 14. Connecting the connector to the vehicle diagnostic interface 14 creates an electrical and mechanical connection between the two. The connector can be directly attached to a housing of the communication device 20, for example, in the case of a dongle / stick. Alternatively, the connector can also be connected to other components of the communication device 20 via an extension cable, for example, in the case of a dedicated vehicle diagnostic tool.

[0086] In some cases, an alternative or additional wireless communication connection between the diagnostic device 20 and the vehicle 10 and the control units 11, 12 may be possible, for example a wireless close connection such as Bluetooth or WiFi / WLAN.

[0087] The communication device 20 can be configured to process outgoing data streams from the control units 11, 12 and / or to process data streams from external units 30, 40 to the vehicle 10, particularly if the communication device is an OBD dongle. The communication device 20 can have a first transmitting and receiving unit and a second transmitting and receiving unit, one for communication or data streams to the vehicle 10 and the other for communication or data streams from the vehicle 10. If the same communication protocols are used, only one transmitting and receiving unit can be provided, which communicates with the control units 11, 12 on the one hand and the mobile terminal 30 on the other.

[0088] As shown in Fig. 1, communication is only possible between the vehicle and the diagnostic device 20, i.e. without further units 30, 40.

[0089] The communication device 20 can be communicatively connected to the mobile device 30 via a first communication link 24. The communication link 24, which connects the communication device 20 to the mobile device 30, can be a wireless near-field connection, for example, Bluetooth or WiFi / WLAN. Alternatively, the first communication link 24 can also be a wired communication link between the communication device 20 and the mobile device 30.

[0090] The mobile device 30 is connected to a vehicle-side user interface 40 via a second communication link 25.

[0091] The vehicle-side user interface 40 is often designed as an infotainment system. The vehicle-side user interface 40 often features a screen designed as an output element and / or at least one input element of an input unit for a user. If the screen is designed as a touchscreen, both user input and output can occur via this screen. The vehicle-side user interface 40 can also be designed as a vehicle-side mobile device.

[0092] Input elements often consist of buttons and rotary knobs. In addition, other operating elements are usually employed. These include rotary / push switches in the center console or on the dashboard, touchscreens, touchpads, and / or buttons or rotary switches on the steering wheel. Modern vehicle user interfaces or infotainment systems can also be operated via voice control or gesture control. In this case, the input elements are cameras or microphones. An infotainment system is typically defined as a system of components that provide various comfort and safety functions. These can include air conditioning, radio, multimedia, navigation, and / or connectivity functions. Infotainment systems are usually configured to relieve the driver, inform them, and / or entertain them.

[0093] The connection between control units 11 and 12 and user interface 40 is usually intentionally or legally restricted, so that the user or driver does not have access to the diagnostic data of control units 11 and 12 via user interface 40. This is intended to prevent the driver from being distracted while driving or, conversely, to prevent control units 11 and 12 from being accidentally misconfigured, which in the worst case could lead to a malfunction while driving or even an accident.

[0094] The mobile device 30 can be or become connected to a mobile network via an air interface. The air interface can, for example, include a connection via a mobile network according to one of the mobile communication standards G1-G5 or higher. The mobile device 30 can be uniquely identifiable by an identification feature, e.g., IMEI (international mobile equipment identity).

[0095] In some embodiments, the control unit 11 is configured to receive and send data via the vehicle bus system 16 within the vehicle 10. The control unit 11 may, for example, be responsible for ensuring safety functions. Exemplary control units 11 include an on-board power supply control unit and / or a gateway. Depending on the manufacturer, the gateway and / or the on-board power supply control unit are present in the vehicle 10 and, together with the diagnostic interface 14, form a communication bridge between the vehicle 10 and external units 20, 30.

[0096] The gateway is typically designed as a communication device within the vehicle 10 and enables communication between the vehicle 10 and the outside world via the diagnostic interface 14. Specifically, the gateway is configured to exchange data or communicate with the communication device 20. The gateway can thus act as a data distributor for communication within the vehicle 10 and with the outside world via the communication interface 14. Often, the gateway supports various vehicle bus systems 16 such as Ethernet, CAN, and LIN, and can, for example, be connected to an additional diagnostic bus system. The diagnostic bus system can be part of the vehicle bus system 16 or exist separately from the vehicle bus system 16 and be connected to it via the gateway.

[0097] The term "on-board network control unit" or abbreviated BSG, in English "body control module" (BCM), refers to one or more control units in the vehicle 10 that directly control electrical consumers or components in the vehicle's electrical system (such as lighting or windshield washer system), process data from the vehicle bus systems 16 (LIN, CAN, FlexRay), and / or also function as a gateway for diagnostic services. Comfort functions such as seat heating or ambient lighting are also typically controlled by the BCM.

[0098] The diagnostic device 20, the mobile terminal 30, and / or the vehicle-side user interface 40 can each have at least one transmitting and receiving unit (transceiver) to enable communication with the other units. The two-way communication between units 20, 30, and 40 is indicated by lines in Figures 1-2. Dashed lines indicate wireless communication or communication via an air interface, while solid lines indicate wired communication. Wired communication is also possible, and vice versa; see above for further details.

[0099] Furthermore, the communication device 20, the mobile terminal 30, and / or the vehicle-side user interface 40 can each have a processor for evaluating and / or processing diagnostic data. The diagnostic data can be received via the transmitter and receiver of units 20, 30, and 40 and subsequently evaluated or forwarded so that the evaluation or processing of the diagnostic data can take place in another unit. The procedure can be carried out while the vehicle 10 is in operation and / or while driving. Alternatively, the procedure can also be carried out in the workshop or at another location. The steps of the procedure are explained in more detail below.

[0100] A communication link 15 is established between the vehicle 10 and the communication device 20 via the diagnostic interface 14 (S5). Using the communication link 15, diagnostic data can now be sent from the control units 11, 12 to external units 20, 30 that are not part of the vehicle.

[0101] After or before or simultaneously with the establishment of the communication connection 15, a first communication connection 24 is established between the communication device 20 and the mobile terminal 30 (S10).

[0102] Afterwards – or before or simultaneously – a second communication connection is established between the mobile device 30 and the user interface 40 (S20). The establishment of the first communication connection 24 can automatically trigger the establishment of the second communication connection 25, or vice versa. Alternatively, the second communication connection 25 can be triggered by another event, for example, user input at the user interface 40. Alternatively, the second communication connection 25 can already exist before the first communication connection 24 is established. For example, the second communication connection 25 can be established automatically when the driver is near the vehicle 10 with their mobile device or enters the vehicle 10.

[0103] The communication links 15, 24, 25 are generally designed as bidirectional communication channels, so that messages and data can be sent and exchanged via these links 15, 24, 25. The communication links 15, 24, 25 thus enable a communication link 26 between the communication device 20 and the vehicle-side user interface 40 via the mobile terminal 30, as well as a communication link 27 between the vehicle-side control units 11, 12 and the vehicle-side user interface 40 via the communication device 20 and the mobile terminal 30.

[0104] The communication device 20 and the mobile terminal 30 are now able to mediate communication between the vehicle 10, in particular the vehicle-side control units 11, 12, and the vehicle-side user interface 40 via communication links 26, 27. Thus, the units 20, 30 can transmit diagnostic data, data derived from the diagnostic data, or messages from the vehicle-side control units 11, 12 to the user interface 40 and vice versa using the bidirectional communication channels 15, 24, 25. The diagnostic data can include, for example, fault codes, vehicle sensor readings, control unit settings, control unit information, and / or operating parameters of the control units 11, 12. Before sending or receiving the data, the following steps are performed:When forwarding the diagnostic data, it can be read, processed, packaged into data packets, correlated or combined with other data, evaluated, coded, encrypted or decrypted, so that data derived from the diagnostic data can be generated, which can then be sent or forwarded to the next unit 30, 40.

[0105] The diagnostic data, the data derived from the diagnostic data, or the diagnostic message can be temporarily stored or buffered in a memory of one of the units 20 or 30 before being sent. The data can therefore be sent or forwarded to the mobile device 30 or the user interface 40 with a time delay. This time delay can be in the range of seconds, hours, or days. For example, if one of the communication links 24, 25, 26, or 27 is currently unavailable, sending or forwarding the data can be delayed until the communication link 24, 25, 26, or 27 has been established.

[0106] The communication device 20 performs the following steps:

[0107] Requests S40 and receive S41 of diagnostic data from the at least one vehicle control unit 11, 12, sends S42 of the diagnostic data and / or data derived from the diagnostic data and / or a diagnostic message based on the diagnostic data to the vehicle user interface 40 via the mobile device 30.

[0108] The diagnostic message mentioned in this document may contain a diagnostic result, e.g., vehicle battery faulty or windshield wipers defective, a recommendation for action or a request to the driver, e.g., tire change, refilling of oil or coolant, vehicle battery replacement or visiting a workshop.

[0109] The sending step S42 typically also includes forwarding the diagnostic data from the mobile terminal 30 to the vehicle-side user interface 40.

[0110] The S40 request for diagnostic data can also be initiated by the mobile device 30, so that the procedure in this case comprises the following steps:

[0111] Requests S50 and receipts S51 of diagnostic data and / or data derived from the diagnostic data and / or a diagnostic message based on the diagnostic data from the communication device 20 connected to at least one vehicle control unit 11, 12,

[0112] Send S52 the diagnostic data and / or the data derived from the diagnostic data and / or the diagnostic message to the vehicle-side user interface 40.

[0113] The request step S50 typically also includes forwarding the request to the control unit 11, 12 via the communication device 20. Similarly, the receive step S51 typically also includes forwarding the diagnostic data via the communication device 20 to the mobile terminal 30.

[0114] Steps S40, S41, and S42 are shown in Fig. 4 as occurring before steps S50, S51, and S52. However, they can also occur after steps S50, S51, and S52.

[0115] The request for diagnostic data S40 or S50 can also be initiated by user interface 40 or by user input via user interface 40, so that the procedure in this case comprises the following steps:

[0116] Requests S60 and receipts S61 of diagnostic data and / or data derived from the diagnostic data and / or a diagnostic message based on the diagnostic data from at least one vehicle control unit 11, 12,

[0117] It should be noted that units 20, 30, and 40 do not necessarily have to send an active request. They can also passively listen for the diagnostic data, the data derived from the diagnostic data, and / or the diagnostic message. Therefore, steps S40, S50, and S60 are optional.

[0118] After receiving the data or message, user interface 40 can perform the following step:

[0119] Displaying the diagnostic data and / or the data derived from the diagnostic data and / or the diagnostic message.

[0120] The display informs the user and allows them to assess the situation and, if necessary, take action, such as entering data at user interface 40. This enables guided human-machine interaction.

[0121] The communication device 20 and the mobile terminal 30 can perform the following steps, which are summarized in Fig. 7 by the reference numeral S70:

[0122] Receiving an initial message from the vehicle's user interface 40, forwarding the initial message to the vehicle's control unit 11, 12,

[0123] The first message can, for example, contain a command to read, write, and / or modify data, settings, and / or programs in the vehicle's control unit 11, 12. The vehicle's control unit 11, 12 can then, for example, send an acknowledgment to the user interface, S71.

[0124] Additionally or alternatively, the following steps may be provided, which are preferably carried out via user interface 40:

[0125] Receiving user input,

[0126] Generating a second message based on user input,

[0127] Sending the second message to the vehicle's control unit 11, 12,

[0128] These steps can alternatively or additionally be carried out using the mobile device 30 or the communication device 20.

[0129] The second message may contain a command to read, write, and / or modify data, settings, and / or programs in the vehicle's control unit 11, 12. The second message may be used in addition to or as an alternative to the first message.

[0130] It may be intended that control units 11 and 12 are in a data transmission mode by default, and that access to control units 11 and 12 in data transmission mode is not possible. Access in this context means that data, settings, or programs in control units 11 and 12 can not only be read but also modified.

[0131] The first and / or second message may also include or be an activation message. The activation message may enable access to control units 11 and 12, or an access mode for control units 11 and TI.

[0132] 12 activates access to control units 11 and 12. Optionally, access mode can be enabled only after a user consent message has been received. For example, a user or the vehicle driver may be required to explicitly consent to access to control units 11 and 12 via an input on the user interface 40. Alternatively, the consent message can be received by the mobile device 30 or entered there by the user. The activation message can, for instance, only be sent to the control unit in a specific vehicle state. For example, if the vehicle 10 is in motion, access to safety-relevant control units 11 and 12 can be blocked. When the vehicle is stationary or parked, control units 11 and 12 can be enabled, thus allowing access.

[0133] The following step is optional: Switching from data transmission mode to access mode based on the activation message and / or the consent message or a vehicle status.

[0134] The consent message ensures that remote access via remote access server 40 is only granted after a user has confirmed and authorized it. The consent message can be sent or received before or after the activation message.

[0135] At least one, several, or all of the steps described above can be performed while the vehicle 10 is operating or even while it is moving. "Operating the vehicle 10" means that the vehicle 10 is started, but not necessarily moving.

[0136] The access mode should preferably only be activated when the vehicle 10 is stationary. If changes are made to the control units 11 and 12 while the vehicle 10 is in motion, this could endanger the safety of the vehicle 10 and its occupants. Conversely, the data transmission mode can also be activated when the vehicle 10 is moving. To determine whether the vehicle 10 is moving, the engine speed sensor, speedometer, motion sensors, and other vehicle-side sensors can be used. Furthermore, motion data such as GPS data, satellite data, and radio tracking signals can also be used for this purpose. Sensors in units 20, 30, or 40, or motion data obtained by these units 20, 30, or 40, can also be used to determine whether the vehicle is moving or stationary.If it is detected that vehicle 10 is moving, the access mode may be locked.

[0137] As an additional or alternative safety measure, the ferry operation of vehicle 10 can be blocked as long as the access mode is activated. Only when remote access is complete and control units 11 and 12 are back in data transmission mode can the ferry operation be reactivated.

[0138] It may be provided that communication is limited to a specific group of control units 11, 12 from the multitude of control units 11, 12, in particular non-safety-related control units 11, 12. It may be provided that communication with certain control units 11, 12 is only possible in a predetermined operating state of the vehicle.

[0139] The aim of vehicle diagnostics is to determine the severity of a malfunction, identify which component in vehicle 10 is potentially defective, and determine how this component can be repaired. To identify the defective component of vehicle 10, at least one of units 20, 30, or 40 evaluates the fault codes. These codes, as described above, are generated during vehicle 10's operation by evaluating sensor readings from at least one vehicle control unit 11 or 12 and stored in the vehicle's memory. Therefore, at least one of units 20, 30, or 40 can perform vehicle diagnostics based on the diagnostic data from control units 11 and 12.

[0140] Upon a corresponding request, the vehicle control units 11 and 12 are configured to read the fault codes stored in the vehicle 10 and transmit them to the communication device 20. The communication device 20 can therefore communicate directly with the respective vehicle control units 11 and 12 to request and obtain the necessary fault codes. By analyzing the fault codes, it can be diagnosed whether and which vehicle components need to be repaired or replaced to resolve the problem. Thus, by evaluating the fault codes (vehicle diagnostics), a statement can be made about which vehicle components are defective and require repair. The evaluation or analysis of the fault codes can take place in one of the units 20, 30, or 40.

[0141] It is understood that the features or steps shown in Figures 1-3 and described above can be combined with each other, provided that the combinations are not mutually exclusive.

[0142] Reference symbol list

[0143] 10 vehicles

[0144] 11 Vehicle control unit

[0145] 12 Vehicle control unit

[0146] 14 OBD interface

[0147] 15 signal lines

[0148] 16 vehicle bus system

[0149] 20 Vehicle diagnostic device / OBD dongle

[0150] 24 first communication link

[0151] 25 second communication link

[0152] 26 Communication link

[0153] 27 Communication link

[0154] 30 mobile devices

[0155] 40 vehicle-side user interface or infotainment system

[0156] 100 System

Claims

Hella Gutmann Solutions GmbH P148757PC00 Patent claims 1. Method carried out by a communication device (20) which is configured to communicate with at least one vehicle control unit (11, 12) via a vehicle-side diagnostic interface (14) and with a mobile terminal unit (30) via a first communication link (24), in particular a first wireless near-field link, the method comprising the steps: Requests (S40) and / or receipts (S41) of diagnostic data from at least one vehicle control unit (11, 12), Sending (S42) the diagnostic data and / or data derived from the diagnostic data and / or a diagnostic message based on the diagnostic data to a vehicle-side user interface (40) via the mobile device (30).

2. Method carried out by a mobile terminal (30) which is configured to communicate with a communication device (20) via a first communication link (24), in particular a first wireless near-field link, and with a vehicle-side user interface (40) via a second communication link (25), in particular a second wireless near-field link, the method comprising the steps: Requests (S50) and / or receipts (S51) of diagnostic data and / or data derived from the diagnostic data and / or a diagnostic message based on the diagnostic data from the communication device (20) connected to at least one vehicle control unit (11, 12), Sending (S52) the diagnostic data and / or the data derived from the diagnostic data and / or the diagnostic message to the vehicle-side user interface (40).

3. Method carried out by a vehicle-side user interface (40) which is configured to communicate with a mobile terminal (30) via a second communication link (25), in particular a second wireless near-field link or a wired link, the method comprising the steps: Requests (S60) and / or receipts (S61) of diagnostic data and / or data derived from the diagnostic data and / or a diagnostic message based on the diagnostic data from a communication device (20) connected to at least one vehicle control unit (11, 12) via the mobile terminal (30), Displaying the diagnostic data and / or the data derived from the diagnostic data and / or the diagnostic message.

4. Method according to one of the foregoing claims insofar as it relates back to claims 1 and 2, with the additional step: Receiving an initial message from the vehicle's user interface (40), Forwarding the first message to the vehicle control unit (11, 12), wherein the first message contains a command to write and / or change data, settings and / or programs in the vehicle control unit (11, 12).

5. Method according to one of claims 1-3 with the further step: Receiving user input, Generating a second message based on user input, Sending the second message to the vehicle control unit (11, 12), wherein the second message contains a command to write and / or change data, settings and / or programs in the vehicle control unit (11, 12).

6. Method according to any of the preceding claims, wherein at least one of the steps, a plurality of the steps or all of the steps are carried out during the operation of the vehicle (10) or during driving.

7. Method according to one of the preceding claims, wherein the vehicle (10) has a plurality of control units (11, 12), wherein communication is limited to a specific group of control units (11, 12) from the plurality of control units (11, 12), namely non-safety-relevant control units (11, 12).

8. Method according to claim 7, wherein control units (11, 12) are safety-relevant and are assigned to the braking system or the steering system of the vehicle, wherein tire pressure sensors, tire pressure control units or tire-associated sensors or control units are also excluded from communication.

9. Method according to one of the preceding claims, wherein the vehicle (10) has a plurality of control units (11, 12), wherein communication is limited to a specific group of control units (11, 23) from the plurality of control units, wherein communication with specific control units (11, 12) is only possible in a predetermined operating state of the vehicle (10), and the predetermined operating state is a stopping and / or parking of the vehicle.

10. Method according to any of the preceding claims, wherein the diagnostic data includes fault codes and / or control unit settings, wherein the diagnostic message contains a diagnostic result, a recommendation for action or a request to the driver.

11. Method according to one of the preceding claims, wherein the diagnostic data comprise vehicle sensor measurements, control unit information and / or operating parameters of the control unit (11, 12), wherein the diagnostic message includes a diagnostic result, a recommendation for action or a request to the driver.

12. Method according to one of the preceding claims, with the additional step of: performing a vehicle diagnosis based on the diagnostic data.

13. Method according to one of the preceding claims, wherein the communication device (20) has a plug, in particular a dongle or access protection plug, for mechanical and electrical connection to the vehicle-side diagnostic interface (14) or wherein the communication device (20) is designed as a dedicated vehicle diagnostic device.

14. Method according to any of the preceding claims, wherein the mobile terminal (30) is or comprises a mobile phone, in particular a smartphone, smartwatch, laptop or tablet PC.

15. Method according to one of the preceding claims, wherein the vehicle-side user interface (40) comprises a screen, preferably a touch-sensitive screen, and / or an input unit or at least one input element for a user, wherein the vehicle-side user interface (40) is preferably designed as an infotainment system.

16. Communication device (20), in particular diagnostic device, dongle or vehicle diagnostic device, configured to carry out the method according to one of the preceding claims insofar as it relates back to claim 1.

1. Mobile terminal (30), designed to carry out the procedure according to one of the preceding claims insofar as it relates back to claim 2.

18. Vehicle-side user interface (40), designed to perform the method according to one of the preceding claims insofar as it relates back to claim 3.

Images