Apparatus and method for performing remote health management of vehicle

Abstract

According to one embodiment of the present invention, a method for remotely managing the health of a vehicle, performed by a server, comprises: (a) receiving a diagnostic request information of the vehicle from a user terminal; (b) receiving a feature point generated by sensing information from a sensor unit of the vehicle corresponding to the diagnostic request information; (c) inputting the feature point into a pre-configured fault determination model to diagnose whether the vehicle is faulty; and (d) transmitting a diagnostic result to a user terminal and updating a fault determination model based on the feature point and the diagnostic result.

Description

Technology Field

[0001] The present invention relates to an apparatus and method for receiving and analyzing noise and vibration generated in a vehicle to remotely diagnose whether the vehicle is malfunctioning (health). Background Technology

[0002] The process of measuring and analyzing vehicle noise and vibration can diagnose the condition of mechanical devices (assets) before functional failures occur and provide useful information for predictive maintenance. However, there are limitations to developing generalized diagnostic algorithms because measurement results vary depending on the type and severity of the failure, and the condition of surrounding components can influence the results.

[0003] Figure 1 is a diagram visually illustrating the limitations of conventional algorithm development.

[0004] Conventional technologies utilize frequency analysis (FFT analysis), order tracking, and acceleration envelopes; however, in most cases, results are individually analyzed and judged by experienced experts for specific cases, and automated analysis methods using generalized algorithms have not yet been commercialized.

[0005] Accordingly, there is a need for a method to enhance vehicle component diagnostic algorithms by correlating (federated learning) the analysis of sensor data collected from individual vehicles with various vehicle data collected from a central server. The problem to be solved

[0006] The present invention aims to solve the problems of the aforementioned prior art by providing an algorithm capable of determining whether a part of interest is faulty in a complex mechanical device composed of a combination of multiple mechanical parts, such as a vehicle.

[0007] Although noise and vibration measurement results may be affected by the interaction between components constituting the vehicle, the purpose is to provide an algorithm that can reliably determine whether a component of interest is faulty even under various conditions.

[0008] However, the technical problem that this embodiment aims to solve is not limited to the technical problem described above, and other technical problems may exist. means of solving the problem

[0009] As a technical means for achieving the aforementioned technical task, a method for remotely managing the health of a vehicle, performed by a server, may comprise: (a) receiving a vehicle diagnosis request information from a user terminal; (b) receiving a feature point generated by sensing information from a sensor unit of the vehicle corresponding to the diagnosis request information; (c) inputting the feature point into a pre-configured fault determination model to diagnose whether the vehicle is faulty; and (d) transmitting the diagnosis result to the user terminal and updating the fault determination model based on the feature point and the diagnosis result.

[0010] In addition, after step (a), a driving request and driving conditions for the vehicle are provided to the user terminal, and when the vehicle starts actual driving according to the driving conditions, feature points for the sensing information can be received from the sensor unit.

[0011] In addition, prior to step (b), the method includes (b1) mounting a sensor unit on a pre-configured part of a vehicle; and (b2) linking the sensor unit with a user terminal, wherein the sensor unit may be composed of at least one of a vibration sensor for measuring vibration of a part and a noise sensor for measuring noise.

[0012] Additionally, the fault determination model comprises: (c1) a step of collecting vibration data corresponding to a normal state and a fault state while varying the driving conditions of the vehicle according to the driving time of the vehicle; (c2) a step of calculating key feature points for determining the state of the vehicle from the driving conditions and vibration data after visualizing the vibration data; (c3) a step of performing analysis by applying at least one of a time domain and a frequency domain to the extracted key feature points; and (c4) a step of generating a fault determination model by applying the state of the vehicle, the key feature points, and the results of the analysis to a preset learning model, wherein the key feature points are basic feature points for generating the fault determination model, and the driving conditions may be at least one of RPM, gear stage, vehicle speed, and brake signal.

[0013] Additionally, step (c) may include (c5) a step in which a sensor unit extracts feature points from sensing information; (c6) a step in which a server inputs the feature points into a fault determination model to determine whether the vehicle is faulty; (c7) a step in which step (c5) is continuously repeated whenever the data collected during driving reaches a specific size; and (c8) a step in which the vehicle is determined to be in a faulty state depending on how many times the time interval determined to be faulty has occurred.

[0014] In addition, step (c5) can calculate feature points for determining the state of the vehicle based on variables pre-set in the sensor unit after pre-processing the sensing information in the sensor unit.

[0015] In addition, step (c6) may allow the server to directly receive feature points from the sensor unit, or the user terminal to provide feature points to the server after receiving them from the sensor unit.

[0016] In addition, when determining whether a fault exists by performing steps (c5) to (c8) during one run on a pre-set course, the steps (c5) to (c8) are repeated while performing multiple runs, and after determining whether a fault exists for each run, if the ratio of runs determined to be in a total fault state is greater than or equal to a pre-set value, the vehicle's state can be determined to be in a final fault state.

[0017] In addition, information about the type of component to which the sensor unit is attached and the type of sensor is received along with feature points, and step (d) can correct the diagnostic result based on the information about the type of component to which the sensor unit is attached and the type of sensor.

[0018] Additionally, step (d) can receive the type of failure that occurred in the vehicle from a pre-configured repair shop terminal and perform an update along with the feature points.

[0019] In addition, during the process of updating the fault detection model based on feature points, fault types, and fault judgment results received from multiple vehicles, pre-configured variables can also be updated.

[0020] In addition, pre-configured variables can be provided to sensor units equipped in multiple vehicles of the same model to perform updates.

[0021] In addition, a device for remotely managing the health of a vehicle may include a memory in which a program for remotely managing the health of a vehicle is stored, and a processor that executes the program stored in the memory to remotely manage the health of the vehicle, wherein the processor receives diagnostic request information for the vehicle from a user terminal, receives a feature point generated by sensing information from a sensor unit of the vehicle corresponding to the diagnostic request information, inputs the feature point into a pre-set fault determination model to diagnose whether the vehicle is faulty, transmits the diagnostic result to the user terminal, and updates the fault determination model based on the feature point and the diagnostic result.

[0022] In addition, it may be a computer-readable storage medium on which a program for performing a method of remotely managing the health of a vehicle is recorded. Effects of the invention

[0023] Through the present invention, an algorithm can be provided to determine whether a part of interest is faulty in a complex mechanical device composed of a combination of multiple mechanical parts, such as a vehicle.

[0024] Although noise and vibration measurement results may be affected by the interaction between components constituting the vehicle, the purpose is to provide an algorithm that can reliably determine whether a component of interest is faulty even under various conditions. Brief explanation of the drawing

[0025] Figure 1 is a diagram visually illustrating the limitations of conventional algorithm development. FIG. 2 is a diagram showing the configuration of a system for remotely managing the health of a vehicle according to one embodiment of the present invention. FIG. 3 is a diagram showing the configuration of a server according to one embodiment of the present invention. Figure 4 is an example of a sensor that can be installed in a vehicle. FIG. 5 is a flowchart illustrating the process of remotely managing the health of a vehicle according to one embodiment of the present invention. FIG. 6 is an operation flowchart showing the process of installing a sensor unit according to one embodiment of the present invention. FIG. 7 is a flowchart illustrating the process of generating a fault determination model according to one embodiment of the present invention. FIG. 8 is a flowchart illustrating the process of an artificial intelligence determining the health of a vehicle according to an embodiment of the present invention. FIG. 9 is example data regarding vibration and noise measured according to the condition of a vehicle according to one embodiment of the present invention. FIG. 10 is a diagram showing the types of learning models that can be applied to a fault detection model according to one embodiment of the present invention. Specific details for implementing the invention

[0026] Embodiments of the present invention are described below with reference to the attached drawings so that those skilled in the art can easily implement the invention. However, the present invention may be embodied in various different forms and is not limited to the embodiments described herein. Furthermore, in order to clearly explain the present invention in the drawings, parts unrelated to the explanation have been omitted, and similar parts throughout the specification are denoted by similar reference numerals.

[0027] Throughout the specification, when a part is described as being "connected" to another part, this includes not only cases where they are "directly connected," but also cases where they are "electrically connected" with other components interposed between them. Furthermore, when a part is described as "including" a certain component, this means that, unless specifically stated otherwise, it does not exclude other components but may include additional components.

[0028] The following examples are detailed descriptions to aid in understanding the present invention and are not intended to limit the scope of the present invention. Accordingly, inventions within the same scope that perform the same function as the present invention will also fall within the scope of the present invention.

[0029] In the present specification, the term server (100) refers to a local server or cloud server of an entity that remotely manages the health of a vehicle.

[0030] FIG. 2 is a diagram showing the configuration of a system for remotely managing the health of a vehicle according to one embodiment of the present invention.

[0031] Referring to FIG. 2, the system may be composed of a server (100), a plurality of user terminals (200), and a vehicle (400) equipped with a sensor unit (300) connected to the user terminals (200). Additionally, each device is interconnected through a communication network.

[0032] The present invention is characterized by a server (100) receiving sensing information from each of the sensor units (300) of a plurality of vehicles (400) at the request of a user terminal (200), and determining the health of each vehicle (400) based on artificial intelligence and the received information.

[0033] Specifically, according to one embodiment of the present invention, when a server (100) receives diagnostic request information for a vehicle (400) from a user terminal (200), it receives characteristic points of sensing information from a sensor unit (300) installed in the vehicle (400) and inputs them into a fault determination model.

[0034] Additionally, the server (100) has the feature of providing the diagnosis result of the vehicle (400) calculated through the fault determination model to the user terminal (200) and updating the fault determination model.

[0035] At this time, the sensing information corresponds to the value measured by the sensor unit (300) as the vehicle (400) drives.

[0036] According to one embodiment of the present invention, a user terminal (200) may be connected to the Integrated Vehicle Health Monitoring (IVHM) of a vehicle (400) or directly connected to a sensor unit (300) of a vehicle (400) and may correspond to a terminal for managing the health of the vehicle (400).

[0037] Accordingly, the user terminal (200) is characterized by generating and transmitting diagnostic request information to the server (100) to diagnose the health of the vehicle (400) and receiving the diagnostic result.

[0038] Here, the diagnostic request information is information for requesting a diagnosis of the vehicle (400), and as an optional embodiment, the user terminal (200) may receive a driving request and driving conditions from the server (100). Accordingly, when the driver of the vehicle (400) starts driving in accordance with the driving conditions, the server (100) receives a feature point from the sensor unit (300).

[0039] Additionally, the process described above may be carried out through an application for remotely managing the health of a vehicle installed on a user terminal (200), and this application may be an application embedded in the user terminal (200) or an application downloaded from an application distribution server and installed on the user terminal (200).

[0040] Additionally, the user terminal (200) refers to a communication terminal capable of using a terminal application in a wired or wireless communication environment. Here, the user terminal (200) may be a portable terminal of the user. Although the user terminal (200) is depicted as a smartphone, which is a type of portable terminal, in FIG. 2, the concept of the present invention is not limited thereto and can be adopted without limitation for any terminal capable of carrying a terminal application as described above.

[0041] To explain this in more detail, the user terminal (200) may include any form of a handheld computing device (e.g., PDA, email client, etc.), a mobile phone, or any form of another type of computing or communication platform, but the present invention is not limited thereto.

[0042] According to one embodiment of the present invention, the sensor unit (300) is installed on each part of the vehicle (400) and corresponds to a sensor that measures vibration or noise generated in the part during the process of the vehicle (400) driving.

[0043] For example, the sensor unit (300) detects data generated from each component during the driving of the vehicle (400). In a specific optional embodiment, the sensor unit (300) may be composed of various sensors. For example, as illustrated in FIG. 4, the sensor unit (300) may include at least one of a pressure sensor, a flow sensor, an acceleration sensor, a temperature sensor, a gyroscope sensor, a steering angle sensor, a humidity sensor, an acoustic sensor, and a vibration sensor in the engine and transmission. Additionally, a temperature / humidity sensor, a gas sensor, and an air quality sensor may be installed in the interior of the vehicle (400). Additionally, an acceleration sensor, a ride height sensor, a steering angle sensor, an angular velocity sensor, a gravity sensor, and a torque sensor may be installed in the steering / suspension components. In addition, the eco-friendly components may be equipped with an exhaust gas sensor, a main detection sensor, and an oxygen sensor, and for convenience, a light detection sensor, an infrared sensor, a motion sensor, and an image sensor may be equipped. Furthermore, to prevent other risk factors, a collision avoidance sensor, an ultrasonic sensor, a radar sensor, an airbag sensor, and a TPMS may be equipped on the vehicle (400). However, this is merely an example, and various sensors may be utilized in an embodiment of the present invention. Even if described below based on a specific sensor, an embodiment of the present invention may include cases where multiple sensor data are utilized in addition to the specific sensor.

[0044] In addition, the sensor unit (300) can calculate a feature point for determining health based on sensing information measured from the vehicle (400). At this time, the specific method by which the sensor unit (300) calculates the feature point will be explained through FIGS. 5 to 7, which will be described later.

[0045] Meanwhile, the communication network performs the role of connecting the server (100), the user terminal (200), and the sensor unit (300). That is, the communication network refers to a network that provides a connection path so that data can be transmitted and received after the user terminal (200) connects to the server (100) or the server (100) connects to the sensor unit (300). The communication network may include wired networks such as LANs (Local Area Networks), WANs (Wide Area Networks), MANs (Metropolitan Area Networks), and ISDNs (Integrated Service Digital Networks), or wireless networks such as wireless LANs, CDMA, Bluetooth, and satellite communication, but the scope of the present invention is not limited thereto.

[0046] FIG. 3 is a diagram showing the configuration of a server according to one embodiment of the present invention.

[0047] Referring to FIG. 3, a server (100) according to one embodiment of the present invention includes a memory (110), a processor (120), a communication module (130), and a database (140).

[0048] To explain in detail, the memory (110) records a program for remotely managing the health of the vehicle. It also performs the function of temporarily or permanently storing data processed by the processor (120). Here, the memory (110) may include magnetic storage media or flash storage media, but the scope of the present invention is not limited thereto.

[0049] The processor (120) is a type of central processing unit that controls the entire process of remotely managing the health of the vehicle. Each step performed by the processor (120) will be described later with reference to FIGS. 5 to 8.

[0050] Here, the processor (120) may include any type of device capable of processing data, such as a processor. Here, 'processor' may refer to a data processing device embedded in hardware having a physically structured circuit to perform a function expressed by code or instructions included in a program, for example. Examples of such data processing devices embedded in hardware may include a microprocessor, a central processing unit (CPU), a processor core, a multiprocessor, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc., but the scope of the present invention is not limited thereto.

[0051] The communication module (130) provides a communication interface necessary to provide transmission and reception signals between the server (100) and the user terminal (200) or the sensor unit (300) in the form of packet data in conjunction with a communication network. Furthermore, the communication module (130) can receive data requests from the user terminal (200) and the sensor unit (300) and perform the role of transmitting data as a response thereto.

[0052] Here, the communication module (130) may be a device including hardware and software necessary to transmit and receive signals, such as control signals or data signals, through a wired or wireless connection with another network device.

[0053] The database (140) may store feature points (or sensing information) of the received vehicle (400), a fault determination model and information for updating it, information of the vehicle (400) or user terminal (200), etc.

[0054] Although not shown in FIG. 3, some of the data regarding the remote management of vehicle health, etc., may be stored in a database (not shown) that is physically or conceptually separated from the database (160).

[0055] FIG. 5 is a flowchart illustrating the process of remotely managing the health of a vehicle according to one embodiment of the present invention.

[0056] Referring to FIG. 5, the server (100) receives diagnostic request information for a vehicle (400) from a user terminal (200) (S110).

[0057] At this time, the diagnostic request information corresponds to information for a user (or driver) to request the server (100) to diagnose the health of their vehicle (400) through the user terminal (200), as previously mentioned.

[0058] In an optional embodiment, the server (100) provides a driving request and driving conditions for the vehicle to the user terminal (200). For example, driving conditions may include whether to start driving (or the time to start driving), the speed or gear of the vehicle (400), the driving environment or route, etc. When the vehicle (400) actually starts driving according to the driving conditions, the server (100) receives feature points regarding sensing information from the sensor unit (300).

[0059] In addition, in order to perform the above process, the vehicle (400) must have a sensor unit (300) installed in advance, which will be explained through Fig. 6, which will be described later.

[0060] Next, the server (100) receives a feature point generated by sensing information (e.g., vibration data sensing information for a vehicle part) from the sensor unit (300) of the vehicle (400) corresponding to the diagnostic request information (S120).

[0061] At this time, the feature point is calculated to determine the state of the vehicle (400) based on preset variables after the sensor unit (300) preprocesses the sensing information.

[0062] For example, the sensor unit (300) measures 3-axis vibration information and 1-axis noise information from the component, respectively, as sensing information. Afterwards, as shown in FIG. 9, the measured sensing information is visualized. Since the vibration information uses a 3-axis sensor, three values ​​are output, and since the noise information uses one value, the information measured is different when the vehicle (400) is in a normal state and when it is in a fault state, respectively.

[0063] In addition, the sensor unit (300) applies Filtering or Window Function, etc. to the measured sensing information to perform preprocessing, and then calculates feature points based on preset variables.

[0064] For example, the sensor unit (300) extracts 121 types of feature values ​​that are highly likely to classify whether the vehicle (400) is normal or not through analysis based on variables after data normalization. At this time, key feature values ​​are extracted without overlapping areas at 1-second intervals. In addition, MFCC that emphasizes the low-frequency band and STFT (Short Time Fourier Transform) that reflects uniform frequency characteristics are used, and a 1-second window is applied to the time-series sensing information to uniformly preprocess information on the entire spectrum band.

[0065] Next, the server (100) inputs the feature points into a preset fault detection model to diagnose whether the vehicle (400) is faulty (S130).

[0066] The specific process of diagnosing whether a malfunction has occurred will be explained again through Fig. 7, which will be described later.

[0067] Finally, the server (100) transmits the diagnosis results to the user terminal (200) and updates the fault determination model based on the feature points and diagnosis results (S140).

[0068] At this time, the server (100) can receive information about the type of part and sensor to which the sensor unit (300) is attached, along with feature points. Subsequently, the server (100) corrects the diagnosis result based on the information about the type of part and sensor to which the sensor unit (300) is attached. For example, since the data from the sensor attached to the engine and the sensor attached inside the vehicle (400) are different, the judgment result is corrected more accurately based on where the information was measured from.

[0069] Meanwhile, if the vehicle (400) has already broken down, the server (100) receives the type of breakdown that occurred in the vehicle (400) from a pre-configured repair shop terminal and updates the breakdown judgment model along with the characteristic points.

[0070] Additionally, the fault determination model may perform federated learning. For example, the server (100) updates the fault determination model based on feature points, types of faults, and fault determination results received from multiple vehicles (400), and in the process of updating the fault determination model, it also updates the pre-configured variables for calculating feature points from the sensing information.

[0071] Subsequently, the server (100) provides the preset variables to the sensor unit (300) equipped in multiple vehicles (400) of the same model to perform an update. Based on this, the sensor unit (300) is able to extract more accurate feature points to determine a fault.

[0072] FIG. 6 is an operation flowchart showing the process of installing a sensor unit according to one embodiment of the present invention.

[0073] Referring to Fig. 6, the vehicle (400) is brought to a pre-set vehicle repair shop (S111).

[0074] In an optional embodiment, the repair shop terminal and the server (100), which are managed in advance at the vehicle repair shop, are linked to each other, and the repair shop terminal transmits information regarding the entry of the vehicle (400) and the installation of the sensor unit (300), etc., to the server (100).

[0075] Next, the sensor unit (300) is installed on the part of the vehicle (400) through a mechanic (S112).

[0076] In an optional embodiment, the sensor unit (300) may be composed of at least one of a vibration sensor that measures vibration of a component and a noise sensor that measures noise.

[0077] At this time, as another optional embodiment, the repair shop terminal may provide information to the server (100) regarding which part of the vehicle (400) is equipped with which sensor. The server (100) provides guide information for attaching the sensor to the repair shop terminal, and the mechanic may refer to the guide information to perform the installation of the sensor unit (300) in the vehicle (400) and the connection with the user terminal (200).

[0078] Finally, the sensor unit (300) and the user terminal (200) are linked (S113).

[0079] At this time, a pre-configured application is installed on the user terminal (200), and the application can be linked with the server (100) and the sensor unit (300), respectively. Accordingly, the sensor unit (300) measures sensing information and generates feature points through the operation of the user terminal (200).

[0080] FIG. 7 is a flowchart illustrating the process of generating a fault determination model according to one embodiment of the present invention.

[0081] Referring to FIG. 7, the server (100) collects vibration data according to changes in RPM during the driving process of the vehicle (400) and calculates key feature points therefrom (S131).

[0082] Specifically, the server (100) changes the driving conditions according to the driving time of the vehicle (400) and collects vibration data corresponding to the normal state and the fault state. At this time, the vibration data is collected through a vibration sensor, which is a sensor unit (300) attached within each component, and corresponds to a value that measures the vibration generated during the process of driving by changing the driving conditions over time from a plurality of vehicles (400) in advance. Here, the driving conditions may be at least one of RPM, gear stage, vehicle speed, and brake signal. For example, as shown in FIG. 9, the vehicle (400) in the normal state and the fault state is driven according to a preset RPM, and vibration data (three types of data are produced by the 3-axis acceleration sensor) is produced.

[0083] Additionally, after visualizing the vibration data, the server (100) calculates key feature points for determining the state of the vehicle (400) from the driving conditions and vibration data. At this time, the vibration data according to the collected RPM is visualized as in FIG. 9, and about 121 key feature points are extracted from the 3-axis data.

[0084] Here, the key feature points correspond to the basic feature points for generating a fault identification model.

[0085] Next, the server (100) analyzes the key feature points (S132).

[0086] Specifically, the server (100) performs analysis by applying at least one of the time domain region and the frequency domain region to the extracted key feature points.

[0087] At this time, the time domain region can be used to generate feature points as graph-like data by applying MIN MAX, Mean, Zero Crossing Rate, Standard Deviation, and Quantile techniques, and the frequency domain region can be used to generate the spectrum of feature points by applying MFCC, which emphasizes the low-frequency band, and STFT (Short time Fourier transform), which reflects uniform frequency characteristics.

[0088] Finally, the server (100) applies the generated data to a learning model to create a fault determination model (S133).

[0089] Specifically, the server (100) generates a fault determination model by applying the state, key feature points, and spectrum of the vehicle (400) to a preset learning model.

[0090] At this time, the server (100) performs model training based on supervised or unsupervised learning, including CNN, SVM, Autoencoder, etc., using each of the data generated from the preceding step (S131) ​​or step (S132). If the server (100) generates only one data cluster during the data classification process, it considers the data cluster as normal data and determines data different from the cluster as fault data. This is because a vehicle (400) in a normal state mostly generates consistent data, whereas a vehicle (400) in a faulty state generates various abnormal data. In other words, it may be difficult to cluster abnormal data.

[0091] Meanwhile, at least one of the One-class SVM, Isolation Forest, and Autoencoder shown in Fig. 10 may be applied as a learning model.

[0092] First, as shown in Figure 10 (a), the One-class SVM calculates the optimal support vector that can explain the given data well, and applies a method of considering data outside this region as outliers. That is, data in a normal state is applied as a support vector, and data in a failure state is considered as outliers.

[0093] Next, Isolation Forest corresponds to a tree-based unsupervised outlier detection algorithm as shown in (b) of Fig. 10, and isolates all observations by splitting random data. Since this model has the strength of operating efficiently in data with many variables, it is a model that has strengths in isolating data related to various failures that may occur in a vehicle (400) by determining them as variables.

[0094] Finally, the Autoencoder corresponds to a model that compresses normal samples into a lower dimension using an encoder, as shown in (c) of Fig. 10, and then restores them to their original dimension using a decoder. In this process, the restoration error is calculated and compared with a preset threshold to determine whether the data is normal data or faulty data.

[0095] FIG. 8 is a flowchart illustrating the process of an artificial intelligence determining the health of a vehicle according to an embodiment of the present invention.

[0096] Referring to FIG. 8, the sensor unit (300) extracts feature points from the sensing information (S134).

[0097] At this time, after the sensor unit (300) preprocesses the sensing information, a feature point for determining the state of the vehicle (400) is calculated based on the pre-set variables in the sensor unit (300). Here, the feature point is information calculated from the sensing information measured by the sensor unit (300). For example, as shown in FIG. 9, the vibration values ​​(each RPM and 3-axis vibration values) measured by the vibration sensor have subtle differences when the vehicle (400) is in a normal state and when it is in a faulty state. To detect such differences, the sensor unit (300) performs preprocessing by applying an internal Fast Fourier Transform. In addition, the sensor unit (300) receives and stores the pre-set variables for extracting feature points from the server (100) in advance. The sensor unit (300) calculates the feature point from the sensing information based on the pre-stored variables, and the pre-set variables may simply correspond to a threshold value for distinguishing whether the sensing information is faulty or may correspond to a type of algorithm.

[0098] Next, the server (100) inputs the feature points into a fault detection model to determine whether the vehicle is faulty (S135).

[0099] Here, the fault detection model is a model that learns feature points received from multiple vehicles (400) and the state of the vehicle (400), and determines the state based on the feature points of the vehicle (400). At this time, as previously explained, the model may utilize supervised learning or unsupervised learning based on CNN, SVM, Autoencoder, etc., such as One-class SVM, Isolation Forest, Autoencoder, etc., and may also learn by additionally receiving customer information, repair history, driving habits, and the state of the vehicle (400).

[0100] Meanwhile, if the condition of the vehicle (400) is poor, the driver brings the vehicle (400) to a pre-configured repair shop and diagnoses where the vehicle (400) is in a faulty state. Afterward, the mechanic uses a repair shop terminal to perform data labeling on the current fault status of the vehicle (400) based on data related to past faults that occurred in the vehicle (400), and transmits this to the server (100). Based on the labeled data received from the repair shop terminal, the server (100) performs an update to the classification and fault determination model for the characteristic values ​​of the vehicle (400).

[0101] Additionally, the server (100) may directly receive feature points from the sensor unit (300), or the user terminal (200) may provide feature points to the server (100) after receiving them from the sensor unit (300). For example, if the sensor unit (300) is equipped with a communication function capable of directly exchanging data with the server (100), or if the vehicle (400) is equipped with an OBD (On-board diagnostics) capable of data communication, data can be directly exchanged with the server (100); however, if the communication function is simply short-range communication such as Bluetooth, the feature points are transmitted to the server (100) through the user terminal (200).

[0102] Next, the server (100) performs steps (S134, S135) for each received data (S136), and if a failure result greater than a preset ratio is produced, the server (100) determines the vehicle (400) to be in a failure state (S137).

[0103] Specifically, since the fault detection model cannot properly perform judgments if the raw data size is too large, instead of inputting the entire data from the moment the vehicle starts until it stops into the fault detection model, the model continuously inputs raw data of a specific size whenever it is received to perform fault detection. For example, feature point extraction and judgment through the fault detection model can be performed in batches of 2,048 data points. The data continuously collected while driving can amount to tens of thousands or hundreds of thousands, and feature point extraction and judgment through the fault detection model can be performed on the time-series input data up to a fixed data size. In this case, a total of X number of fault detections (e.g., 100 times) are performed until the final drive ends, and the presence of a fault can be determined by referring to the number of detected faults and the number of detected normals. For example, if the number of detected faults exceeds a threshold, or if the ratio between the number of detected faults and the number of detected normals exceeds a threshold, it can be determined that a fault exists.

[0104] Furthermore, to determine whether a fault exists based on only one drive, and to make a more accurate determination, the vehicle (400) is made to perform a pre-set number of drives (y times), and the server (100) repeats steps (S134) to (S137) for each drive (S138), and, considering whether a fault exists for each drive (for example, if the number of drives in which a fault is determined exceeds a pre-set ratio), determines the state of the vehicle as a final fault state (S139).

[0105] This means that if the condition of the vehicle (400) is determined by performing multiple diagnoses in one drive through step (S136), step (S138) corresponds to the step of finally determining the condition of the vehicle through multiple drives. That is, the server (100) improves the accuracy of the diagnosis of the health of the vehicle (400) through arithmetic statistical diagnosis by duplicate judgment.

[0106] One embodiment of the present invention may also be implemented in the form of a recording medium comprising computer-executable instructions, such as program modules executed by a computer. A computer-readable medium may be any available medium accessible by a computer and includes both volatile and non-volatile media, and both removable and non-removable media. Additionally, a computer-readable medium may include a computer storage medium. A computer storage medium includes both volatile and non-volatile, removable and non-removable media implemented by any method or technique for storing information, such as computer-readable instructions, data structures, program modules, or other data.

[0107] Although the method and system of the present invention have been described in relation to specific embodiments, some or all of their components or operations may be implemented using a computer system having a general-purpose hardware architecture.

[0108] The foregoing description of the present invention is for illustrative purposes only, and those skilled in the art will understand that other specific forms can be easily modified without altering the technical spirit or essential features of the present invention. Therefore, the embodiments described above should be understood as illustrative in all respects and not restrictive. For example, each component described as a single unit may be implemented in a distributed manner, and components described as distributed may likewise be implemented in a combined form.

[0109] The scope of the present invention is defined by the claims set forth below rather than by the detailed description above, and all modifications or variations derived from the meaning and scope of the claims and equivalent concepts thereof should be interpreted as being included within the scope of the present invention. Explanation of the symbols

[0110] 100: Server 200: User terminal 300: Sensor section 400: Vehicle

Claims

Claim 1 A method for remotely managing the health of a vehicle, performed by a server, comprises: (a) receiving a diagnostic request information of the vehicle from a user terminal; (b) receiving a feature point generated by sensing information from a sensor unit of the vehicle corresponding to the diagnostic request information; (c) inputting the feature point into a pre-configured fault determination model to diagnose whether the vehicle is faulty; and (d) transmitting a diagnostic result to the user terminal and updating the fault determination model based on the feature point and the diagnostic result, wherein prior to step (a), (a1) the sensor unit changes the driving conditions of the vehicle according to the driving time of the vehicle, collects the sensing information corresponding to a normal state and a fault state, visualizes the sensing information, and then calculates a key feature point for determining the state of the vehicle from the driving conditions and the sensing information. and (a2) the server performs an analysis by applying at least one of the time domain region and the frequency domain region to the extracted key feature points, and applies the state of the vehicle, the key feature points, and the results of the analysis to a preset learning model to generate the fault detection model, wherein the key feature points are the basic feature points for generating the fault detection model, and the driving conditions are at least one of RPM, gear stage, vehicle speed, and brake signal, and the sensing information is data including at least one of a pressure sensor, a flow sensor, a gyroscope sensor, a temperature and humidity sensor, a vibration sensor, an acoustic sensor, and an acceleration sensor, and the step (d) is to update the sensor unit by transmitting a preset variable related to the updated fault detection model to the sensor unit, a method for remotely managing the health of a vehicle. Claim 2 A method for remotely managing the health of a vehicle according to claim 1, wherein, after step (a), a driving request and driving conditions for the vehicle are provided to the user terminal, and when the vehicle starts actual driving according to the driving conditions, a feature point for the sensing information is received from the sensor unit. Claim 3 A method for remotely managing the health of a vehicle according to claim 1, comprising the steps of: (b1) mounting the sensor unit on a preset part of the vehicle prior to step (b); and (b2) linking the sensor unit with the user terminal, wherein the sensor unit is composed of at least one of a vibration sensor for measuring vibration of the part and a noise sensor for measuring noise. Claim 4 delete Claim 5 A method for remotely managing the health of a vehicle, wherein step (c) comprises: (c5) a step in which the sensor unit extracts the feature points from the sensing information; (c6) a step in which the server inputs the feature points into the fault determination model to determine whether the vehicle is faulty; (c7) a step of continuously repeating steps (c5) and (c6) whenever the data collected during driving reaches a specific size; and (c8) a step of determining the vehicle to be in a faulty state according to how many times the time interval determined to be faulty has occurred. Claim 6 A method for remotely managing the health of a vehicle, wherein the step (c5) involves preprocessing the sensing information in the sensor unit and then calculating the characteristic point for determining the state of the vehicle based on the preset variable in the sensor unit. Claim 7 A method for remotely managing the health of a vehicle, wherein the step (c6) is the server directly receiving the feature point from the sensor unit or the user terminal providing the feature point to the server after receiving it from the sensor unit. Claim 8 A method for remotely managing the health of a vehicle according to claim 5, wherein steps (c5) to (c8) are performed during one drive on a pre-set course to determine whether a fault exists, steps (c5) to (c8) are repeated while driving multiple times to determine whether a fault exists for each time, and if the ratio of the total drive determined to be in a fault state is greater than or equal to a pre-set value, the state of the vehicle is determined to be in a final fault state. Claim 9 A method for remotely managing the health of a vehicle, wherein, in claim 3, information regarding the type of component and sensor to which the sensor unit is attached is received together with the feature point, and step (d) corrects the diagnostic result based on the information regarding the type of component and sensor to which the sensor unit is attached. Claim 10 A method for remotely managing the health of a vehicle, wherein step (d) involves receiving the type of failure that occurred in the vehicle from a preset repair shop terminal and performing an update together with the feature points. Claim 11 delete Claim 12 delete Claim 13 A device for remotely managing the health of a vehicle comprises a memory storing a program for remotely managing the health of the vehicle and a processor for remotely managing the health of the vehicle by executing the program stored in the memory. The processor receives a vehicle diagnosis request information from a user terminal, receives a feature point generated by sensing information from a sensor unit of the vehicle corresponding to the diagnosis request information, inputs the feature point into a pre-configured fault determination model to diagnose whether the vehicle is faulty, transmits the diagnosis result to the user terminal, updates the fault determination model based on the feature point and the diagnosis result, the sensor unit changes the driving conditions of the vehicle according to the driving time of the vehicle, collects the sensing information corresponding to a normal state and a fault state, visualizes the sensing information, and then calculates a key feature point for determining the state of the vehicle from the driving conditions and the sensing information, the processor performs an analysis by applying at least one of a time domain and a frequency domain to the extracted key feature point, and generates the fault determination model by applying the state of the vehicle, the key feature point, and the analysis result to a pre-configured learning model, and the key A device for remotely managing the health of a vehicle, wherein the feature point is a basic feature point for generating the fault detection model, the driving condition is at least one of RPM, gear stage, vehicle speed, and brake signal, the sensing information is data including at least one of a pressure sensor, a flow sensor, a gyroscope sensor, a temperature and humidity sensor, a vibration sensor, an acoustic sensor, and an acceleration sensor, and the process of updating the fault detection model is to update the sensor unit by transmitting a preset variable related to the updated fault detection model to the sensor unit. Claim 14 A computer-readable storage medium having a program recorded thereon for performing a method of remotely managing the soundness of a vehicle according to claim 1.

Images