Method and system for collecting vehicle data

DE102014117750B4Active Publication Date: 2026-08-27GM GLOBAL TECHNOLOGY OPERATIONS LLC
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
DE102014117750
Authority / Receiving Office
DE · DE
Patent Type
Patents
Current Assignee / Owner
Priority Date
2013-12-05
Filing Date
2014-12-03
Publication Date
2026-08-27
Estimated Expiration
2034-12-03

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

A method for collecting vehicle data, comprising: - collecting data on at least one component of a vehicle; - sending the data from the vehicle to a decentralized server according to a normal event frequency in a normal mode; - setting an anomalous mode in response to a triggering event indicating a failure of at least one component of the vehicle, wherein the events include ignitions of the vehicle and the events include kilometers driven; and - sending the data from the vehicle to a decentralized server according to an anomalous event frequency in anomalous mode, wherein the anomalous event frequency differs from the normal event frequency.
Need to check novelty before this filing date? Find Prior Art

Description

SPECIALIZATION The field of study concerns data collection in general, and specifically the collection and transmission of data about vehicle components. BACKGROUND In modern vehicles, the operation of the vehicle and its components is monitored using sophisticated computer technology. Sensors regularly collect data on voltages, currents, pressures, temperatures, fluid levels, and other important factors affecting the vehicle's operation. While much of this data is used by onboard control units, it is also advantageous to send it to decentralized servers. This allows for efficient monitoring of long-term data trends and / or comparison with other vehicles. A typical method for discharging this data from the vehicle is via mobile and data systems. However, these systems have a limited amount of available resources, also known as "bandwidth." Furthermore, the cost of transmitting data via these systems is directly proportional to the amount of data. The amount of data generated and transmitted by millions of vehicles would be prohibitively expensive and would also require a significant amount of mobile network bandwidth. Consequently, it is desirable to provide systems and methods for reducing the amount of data transmitted by the vehicle. Furthermore, other desirable features and characteristics of the present invention are apparent from the following detailed description and the accompanying claims in conjunction with the accompanying drawings and this background of the invention. German patent DE 10 2011 006 378 A1 discloses a time-based vehicle management system and method. US patent 8 928 495 B2 discloses systems and methods for telematic monitoring and communication. US patent 8 036 788 B2 discloses systems and methods for transmitting vehicle diagnostic or predictive messages. SUMMARY A method for collecting vehicle data according to claim 1 is provided. DESCRIPTION OF THE DRAWINGS The exemplary embodiments are described below in conjunction with the following drawings, where identical reference numerals denote identical elements, and where: Fig. 1 is a schematic block diagram of a system for data collection according to one embodiment; and Fig. 2 is a flowchart of a method for data collection according to one embodiment. DETAILED DESCRIPTION The following detailed description is merely exemplary and should not be interpreted as limiting the application and possible uses. Furthermore, no commitment to any theory explicitly or implicitly presented in the preceding sections (subject area, background, summary) or in the following detailed description is intended. Figure 1 shows a data collection system 100. The system 100 comprises a server 102 for collecting data from one or more vehicles 104. The server 102 is a computer-based device configured to receive and process data, as is well known to those skilled in the art. According to the exemplary embodiments, the vehicles 104 are motor vehicles. However, the system 100 can readily be configured to collect data from other types of vehicles 104, including, but not limited to, motorcycles, aircraft, trains, and boats. The vehicles 104 are typically located some distance from the server 102. System 100 comprises a controller 105. According to the embodiment shown in Fig. 1, the controller 105 includes a communication control unit 106 and a vehicle control unit 108. It is known to those skilled in the art that the vehicle control unit 108 can alternatively also be referred to as an electronic control unit or "ECU". It should be noted that the separate control units 106 and 108 are not required for the operation of system 100. Rather, the vehicle control unit 108 and the communication control unit 106 of the controller 105 can be implemented in a single device. Conversely, the operation and function of the respective control units 106 and 108 can be distributed across several devices. The vehicle control unit 108 of the exemplary embodiment communicates with at least one component 110 of the vehicle 104. The vehicle control unit 108 can be configured to control the operation of each component 110, to send data to the component 110, and / or to receive data from the component 110. The at least one component 110 of the vehicle 104 can be any apparatus or device that is part of or carried by the vehicle 104. For example, the component 110 can be, in particular, the engine, the air conditioning system, the battery, the starter, the fuel system, and the entertainment system (e.g., radio). The vehicle control unit 108 of the exemplary embodiment contains at least one (not shown) microprocessor for executing a series of instructions (i.e., a program), storing data, and processing data. The communication control unit 106 of the exemplary embodiment also contains at least one (not shown) microprocessor for executing a series of instructions (i.e., a program), storing data, and processing data. According to the exemplary embodiment of Fig. 1, the communication control unit 106 communicates with the vehicle control unit 108. Data can be exchanged between the vehicle control unit 108 and the communication control unit 106. Thus, data about the components 110 of the vehicle 104 can be transmitted from the vehicle control unit (FCU) 108 to the communication control unit (CCU) 106. The communication control unit 106 is configured to communicate with the server 102. According to the exemplary embodiment, communication between the communication control unit 106 and the server 102 takes place at least partially via wireless methods. Specifically, according to the exemplary embodiment, this communication takes place at least partially via RF (radio frequency) methods over a mobile network (not shown). Of course, other methods for communication between the communication control unit 106 and the server 102 are well known to those skilled in the art. The controller 105 can be configured to execute one or more programs for transmitting data about the operation of the vehicle 104 to the server 102. Specifically, the controller 105 can be configured to execute a method 200 for data collection according to Fig. 2. A first embodiment of the method 200 is shown separately in Fig. 2. As described herein, other embodiments are of course also possible. Method 200 comprises multiple operating modes. According to the first embodiment, three modes are defined: a basic mode, a normal mode, and an anomalous mode. It is understood that the designations of the modes (i.e., "basic mode," "normal," "anomalous") serve only to distinguish the modes from one another. In other words, these designations are not to be interpreted as limitations of the respective modes. In procedure 201, method 200 includes collecting data about at least one component 110 of the vehicle 104. Data collection in procedure 201 can be performed in any mode. The controller 105 can store data for the components 110. In the embodiment shown in Fig. 2, the method 200 at 202 includes setting the basic mode. Specifically, this basic mode is set when the vehicle 104 is new, i.e., during the initial commissioning of the vehicle 104. Of course, the method 200 can also set the basic mode at 202 under other conditions. In basic mode, the controller 105 collects data from the components 110 regarding their operation. The controller 105 can then calculate the basic values ​​based on the normal operation of the components 110. It is understood that setting the basic mode at 202 is not necessary for all embodiments of the method 200 and the system 100. For example, the basic values ​​can be predefined (e.g., factory settings) and stored in the controller 105 before the vehicle 104 is operated. In Fig. 2, method 200 at 204 includes setting the normal mode. In one example, the normal mode is set after the basic mode. According to the first embodiment, the normal mode at 203 is set after a predetermined time has elapsed in basic mode. In another example, the normal mode is set after the components 110 have collected a predetermined amount of data. In procedure 200, part 208 further includes sending the data from vehicle 104 to the decentralized server 102 in normal mode. Specifically, the data 208 is sent according to a normal event frequency in normal mode. According to the first embodiment, the events are ignitions of vehicle 104. In other words, the events are the starting of the (not shown) engine of vehicle 104 for the first time from a non-running state. In other words, the events are the starting of the engine of vehicle 104. According to this first embodiment, the normal frequency is once every thirty events. Thus, in normal mode, data about the components 110 are sent to the server 102 once every thirty ignitions of the engine of vehicle 104. It should be noted that this normal frequency is merely an example, as any desired transmission frequency can be used. Naturally, the normal frequency and the type of events can differ according to other embodiments. According to the first embodiment, the events are, for example, the kilometers driven by vehicle 104. According to this other embodiment, the normal data transmission frequency can be every 500 km. According to yet another embodiment, the events are the vehicle's operating times. For example, the normal data transmission frequency can be once every four operating hours of vehicle 104. Other suitable events are also apparent to those skilled in the art. Method 200 further includes, at 210, the analysis of the data of components 110. In one example, the data is analyzed to determine, based on the basic values ​​stored for the respective components, whether a component has failed. If, for example, it is detected that a component 110, e.g., a starter, is drawing more current than a predetermined current, a failure of this component 110, in this case the starter, can be detected. According to the exemplary embodiments, an event trigger is set by the controller 105 when a failure is detected. Procedure 200 further includes, at 212, determining whether an event trigger has been set, and at 214, setting the anomalous mode in response to an event trigger. Thus, the anomalous mode is set when an event trigger indicates a failure of at least one component 110 of the vehicle 104. At 216, procedure 200 further includes sending the data from the vehicle 104 to the decentralized server 102 according to an anomalous event frequency in anomalous mode. The anomalous event frequency differs from the normal event frequency. According to the embodiments, the anomalous event frequency is higher than the normal event frequency, meaning that the anomalous event frequency occurs more frequently than the normal event frequency. Thus, in anomalous mode, data from one or more components 110 is sent to the decentralized server 102 more frequently than in normal mode. According to the first embodiment, the anomalous event frequency corresponds to each ignition of the vehicle. In other words, the controller 105 sends the collected data to the decentralized server 102 with each ignition of the vehicle 104. Of course, other embodiments can define different frequencies and / or events for sending the data to the server 102. By transmitting data less frequently in normal mode than in anomalous mode, bandwidth is saved when the vehicle's components 110 are functioning normally. This reduces the strain on mobile networks. Furthermore, significant cost savings can be achieved by using less bandwidth, especially since millions of vehicles 104 use the wireless network. Additionally, the server 102 infrastructure can be reduced due to the lower data transmission rate. Procedure 100 can also include determining the severity of failure of component 110 from a plurality of severity levels, as in 218. The number of severity levels can depend on numerous factors, such as the type of component 110, its operating time, and its expected service life. Of course, other factors can also be used to determine the number of severity levels. For illustrative purposes, three severity levels are used in the exemplary embodiments: a first severity level, a second severity level, and a third severity level. According to these embodiments, a first severity level corresponds to a state of least severity, a second severity level to a medium severity level, and a third severity level to the most severe state. The highest severity level can also be referred to as the maximum severity level, which corresponds to a predetermined highest acceptable severity level for component 110. According to one embodiment, the severity level is determined by comparing the specific data with a plurality of threshold values. In this embodiment, each threshold corresponds to one of the severity levels, e.g., a first threshold, a second threshold, and a third threshold. If, for example, the measured data exceeds the first threshold but falls below the second, the first severity level is set. If the measured data exceeds the second threshold but falls below the third, the second severity level is set. Finally, if the measured data exceeds the third threshold, the third severity level is set. In other embodiments, other criteria may be used to determine the severity level. The transmission of data from vehicle 104 to a decentralized server 102 in anomalous mode can occur for a specific number of events based on the severity of the failure. In the first embodiment, if the first severity level is set, data is sent from vehicle 104 to server 102 for three consecutive ignitions of vehicle 104. If the second severity level is set, data is sent for 20 consecutive ignitions. If the third severity level is set, data is sent for 60 consecutive ignitions. Naturally, the number of events can vary in other embodiments and be based on a wide range of factors. Procedure 100 can include determining whether the specified number of events has been reached at 220. If the specified number of events has not yet been reached, procedure 100 continues to transmit the data at the anomalous frequency in anomalous mode. Method 100 can also include changing at least one of the threshold values ​​in 222. According to the first embodiment, the threshold values ​​of a component 110 can be changed when the component 110 triggers the setting of the anomalous mode. Specifically, according to the first embodiment, the threshold values ​​are lowered for components 110 that frequently trigger the setting of the anomalous mode. This can increase the number of events in which the higher transmission frequency is increased for recurring disturbances where the severity does not necessarily increase. In other cases, however, the threshold values ​​can be lowered if new, higher "normal" threshold values ​​are established. Procedure 100 may also include, in the case of 224, sending a message to a user in response to the fact that the determined severity level is equal to the highest severity level. The user may be, in particular, the driver of vehicle 104, the owner of vehicle 104, a mechanic, or a maintenance advisor. Numerous methods may be used to send the message to the user. These include, in particular, displaying a message in vehicle 104, illuminating a light in vehicle 104, sending an email to the user, sending an SMS to the user, and establishing a telephone connection between the maintenance advisor and the owner of vehicle 104. Method 100 can further include, at point 226, stopping the transmission of data via component 110 in response to the determined severity level being equal to the highest severity level. In other words, data transmission via a malfunctioning component 110 is stopped when a maximum severity level is reached. Stopping data transmission in this way saves bandwidth and costs. This is particularly advantageous when a component 110 is known to have failed and further transmission of data via a known failed component is pointless. In addition to or as an alternative to stopping data transmission via component 110, method 100 can also include stopping the collection of data via component 110. Procedure 100, as described in section 228, also includes resetting to normal mode in response to a number of events greater than or equal to a predetermined number of events occurring in anomalous mode. In other words, after a certain number of events have occurred, normal mode is reset based on the severity of the anomalous events and the corresponding data transmissions. Once normal mode is restored, the differential data transmission frequency from vehicle 104 to server 102 is also reinstated. For example, after data about component 110 has been sent for each ignition cycle, data about component 110 will then only be sent once every 30 ignition cycles. Examples Example 1. Method for collecting vehicle data, comprising: collecting data about at least one component of a vehicle; sending the data from the vehicle to a decentralized server according to a normal event frequency in a normal mode; setting an anomalous mode in response to a triggering event indicating a failure of at least one component of the vehicle; and sending the data from the vehicle to a decentralized server according to an anomalous event frequency in anomalous mode, wherein the anomalous event frequency differs from the normal event frequency. Example 2. Procedure according to Example 1, where the anomalous event frequency is higher than the normal event frequency. Example 3. Method according to Example 1 or 2, wherein the events include ignitions of the vehicle. Example 4. Procedure according to Example 1 or 2, wherein the events include kilometers driven. Example 5. Procedure according to Example 1 or 2, wherein the events encompass time periods. Example 6. Method according to Example 3, wherein the anomalous event frequency is defined further than at each ignition of the vehicle. Example 7. Procedure according to one of Examples 1 - 6, furthermore including determining a severity grade of the component failure from a plurality of severity grades. Example 8. Procedure according to Example 7, wherein the sending of data from the vehicle to a decentralized server in anomalous mode occurs for a predetermined number of events based on the severity of the failure. Example 9. Method according to Example 7, wherein the plurality of severity levels for the component include a maximum severity level corresponding to a predetermined highest acceptable severity level for the at least one component. Example 10. Procedure according to Example 9, further comprising sending a message to a user in response to the fact that the determined severity level is equal to the highest severity level. Example 11. Procedure according to Example 10, further comprising terminating data transmission via the at least one component in response to the fact that the determined severity level is equal to the highest severity level. Example 12. Procedure according to one of Examples 1 - 11, further comprising setting the normal mode in response to a number of events greater than or equal to a predetermined number of events in anomalous mode. Example 13. Vehicle data collection system comprising: a server; and a controller that communicates with at least one vehicle component and is located remotely from the server and is configured to perform the following functions: receiving data from the at least one component of a vehicle; sending data from the vehicle to the server according to a normal event frequency in a normal mode; setting an anomalous mode in response to a triggering event indicating a failure of the at least one component of the vehicle; and sending data from the vehicle to the server according to an anomalous event frequency in anomalous mode, wherein the anomalous event frequency is higher than the normal event frequency. Example 14. System according to Example 13, wherein the controller is further configured in anomalous mode to determine a severity of failure of at least one component from a plurality of severity levels. Example 15. System according to Example 14, wherein the controller is further configured to send data from the vehicle to a decentralized server in anomalous mode for a predetermined number of events due to the severity of the failure. Example 16. Vehicle comprising: at least one component and a controller that communicates with the at least one component and is configured to perform the following functions: receiving data from the at least one component of a vehicle; sending data from the vehicle to a decentralized server according to a normal event frequency in a normal mode; setting an anomalous mode in response to a triggering event indicating a failure of the at least one component of the vehicle; and sending data from the vehicle to a decentralized server according to an anomalous event frequency in anomalous mode, wherein the anomalous event frequency is higher than the normal event frequency. Example 17. Vehicle according to Example 16, wherein the control system is further configured in anomalous mode to determine a severity level of component failure from a plurality of severity levels. Example 18. Vehicle according to Example 17, wherein the controller is further configured to send data from the vehicle to a decentralized server in anomalous mode for a predetermined number of events due to the severity of the failure. Example 19. Vehicle according to Example 17, wherein the events include ignitions of the vehicle. Example 20. Vehicle according to Example 17, wherein at least one component comprises a starter. Although at least one embodiment has been presented in the preceding detailed description, it is understood that numerous variations exist. Furthermore, it should be noted that the respective embodiments are merely examples and are not to be interpreted as limiting the scope, application, or configuration of the disclosed content. Rather, the preceding detailed description provides the skilled person with a convenient plan for implementing the embodiment. It is understood that various modifications to the functions and arrangement of the elements are possible without departing from the scope of protection of the invention as defined in the attached patent claims and legally equivalent documents.

Claims

A method for collecting vehicle data, comprising: - collecting data on at least one component of a vehicle; - sending the data from the vehicle to a decentralized server according to a normal event frequency in a normal mode; - setting an anomalous mode in response to a triggering event indicating a failure of at least one component of the vehicle, wherein the events include ignitions of the vehicle and the events include kilometers driven; and - sending the data from the vehicle to a decentralized server according to an anomalous event frequency in anomalous mode, wherein the anomalous event frequency differs from the normal event frequency. Method according to claim 1, wherein the anomalous event frequency is higher than the normal event frequency. Method according to claim 1 or 2, wherein the events comprise time periods. Method according to one of claims 1 or 2, wherein the anomalous event frequency is further defined as each ignition of the vehicle. Method according to one of claims 1-4, further comprising determining a severity grade of the component failure from a plurality of severity grades. Method according to claim 5, wherein the sending of data from the vehicle to a decentralized server in anomalous mode is performed for a predetermined number of events based on the severity of the failure. Method according to claim 5 or 6, wherein the plurality of severity levels for the component comprise a maximum severity level corresponding to a predetermined highest acceptable severity level for the at least one component. The method of claim 7, further comprising sending a message to a user in response to the fact that the determined severity level is equal to the highest severity level.

Citation Information

Patent Citations

  • Scheduled vehicle management system and procedure

    DE102011006378A1

  • Vehicle diagnostic or prognostic message transmission systems and methods

    US8036788B2

  • Systems and methods for telematics monitoring and communications

    US8928495B2