Method for providing customized maintenance request data for individual vehicle by using artificial intelligence learning model, and electronic device using same

Abstract

A method for providing customized maintenance request data for an individual vehicle by using an artificial intelligence learning model, according to an embodiment of the present disclosure, may comprise the operations of: receiving, from a first mobility owned by a first user, at least one piece of state data of the first mobility; extracting, on the basis of the at least one piece of state data for the first mobility, a feature for performing maintenance prediction for the first mobility; verifying a trained hybrid model for the extracted feature on the basis of a mobility model identical to that of the first mobility; and providing maintenance request data for the first mobility to the first user by using the trained hybrid model.

Description

Method for providing customized maintenance request data for individual vehicles using an artificial intelligence learning model and electronic device using the same

[0001] Embodiments of the present disclosure relate to a method for providing customized maintenance request data for a vehicle using an artificial intelligence learning model and an electronic device using the same.

[0002] With the advancement of vehicle electrical systems, various methods are emerging to maintain optimal performance by analyzing the vehicle's status in real time. Above all, the widespread adoption of electric vehicles makes it possible to determine the vehicle's condition in real time by analyzing electrically received sensing data.

[0003] If drivers' driving habits can be patterned and analyzed, the vehicle's condition can be analyzed more precisely by integrating various logs and sensing data. By accurately determining whether there are any abnormalities through this process, repairs to faulty parts can be performed promptly, thereby preventing accidents. As vehicle status data becomes increasingly vast, the use of artificial intelligence technology capable of providing maintenance alerts through more precise analysis of this data is becoming a prominent issue.

[0004] Conventional vehicle condition abnormality detection processes provided results based on a single cause, which had the problem of failing to reflect the user's vehicle usage habits or provide results based on various causes.

[0005] The embodiments of the present disclosure are intended to solve various problems, including those mentioned above, and aim to provide an artificial intelligence model for providing personalized vehicle maintenance notifications by identifying various vehicle status abnormalities and reflecting the user's vehicle usage patterns to generate a notification requesting vehicle maintenance. However, these objectives are exemplary and the scope of the present disclosure is not limited thereby.

[0006] According to one aspect of the present disclosure, a method for providing customized maintenance request data for an individual vehicle using an artificial intelligence learning model may include: receiving at least one state data for a first mobility owned by a first user; extracting a feature for performing a maintenance prediction for the first mobility based on at least one state data for the first mobility; verifying a hybrid model learned on the extracted feature based on a mobility model identical to the first mobility; and providing maintenance request data for the first mobility to the first user using the learned hybrid model.

[0007] According to one aspect of the present disclosure, the operation of receiving at least one state data may include the operation of classifying the at least one state data into time series data and numerical data, and the operation of processing the time series data and the numerical data to correspond to the input dimensions of the hybrid model.

[0008] According to one aspect of the present disclosure, the at least one state data is collected and received from an ECU (Engine Control Unit), a TCU (Transmission Control Unit), and a DCU (Domain Control Unit), and may include state data capable of determining maintenance mapped from time-series data of the first mobility and state data capable of determining maintenance mapped from numerical data of the first mobility.

[0009] According to one aspect of the present disclosure, the operation of extracting the feature may include the operation of labeling the case where at least one state data for the first mobility matches the maintenance request data.

[0010] According to one aspect of the present disclosure, the operation of training the hybrid model based on a training data set is included, and the operation of verifying the trained hybrid model may include the operation of determining a training data set used for training the hybrid model and a verification data set used for verification, and the operation of calculating a prediction error through a loss function on the result of the training.

[0011] According to one aspect of the present disclosure, the operation of validating the learned hybrid model includes the operation of evaluating the prediction accuracy of the learned hybrid model based on the validation data set and the operation of tuning the hyperparameters of the learned hybrid model based on the accuracy evaluation result, and the hyperparameters may include at least one of a learning rate, the number of hidden layers, the number of nodes of individual layers, and a sequence length.

[0012] According to one aspect of the present disclosure, the operation of providing the maintenance request data to the first user may include the operation of generating the maintenance request data in the form of a notification message using the learned hybrid model and providing it to the first user through a plurality of channels.

[0013] According to one aspect of the present disclosure, the operation of receiving at least one state data includes the operation of receiving driving path data of the first mobility from a navigation device, and the operation of providing the maintenance request data to the first user may include the operation of providing the maintenance request data valid on the driving path to the first user using the hybrid model based on the driving path data collected in real time from the navigation device.

[0014] According to one aspect of the present disclosure, the operation of providing the maintenance request data to the first user may include determining whether the first mobility is lifted up based on pressure sensing data among the numerical data of the first mobility and providing the maintenance request data to the first user.

[0015] According to one aspect of the present disclosure, the learned hybrid model may be characterized by performing learning on a second mobility owned by a second user, determining whether the first mobility and the second mobility are of the same mobility model, and cumulatively learning maintenance request data for each mobility, and providing the maintenance request data corresponding to the real-time status of the first mobility to the first user.

[0016] Other aspects, features, and advantages other than those described above will become clear from the following specific details, claims, and drawings for implementing the invention.

[0017] In addition, these general and specific aspects may be implemented using a system, a computer program, or a combination of any system or computer program.

[0018] According to an exemplary embodiment of the present disclosure as described above, a notification requesting maintenance can be provided by analyzing the condition of a vehicle owned by a user. Furthermore, by re-collecting information regarding the condition analysis and maintenance request notifications for other vehicle models owned by other users and updating an artificial intelligence model, it may be possible to provide various countermeasures for the condition of similar vehicles. Of course, the scope of the present disclosure is not limited by such effects.

[0019] FIG. 1 is a block diagram schematically illustrating a system for providing customized maintenance request data for individual vehicles using an artificial intelligence learning model according to an exemplary embodiment of the present disclosure.

[0020] FIG. 2 is a flowchart schematically illustrating a method for providing customized maintenance request data for individual vehicles using an artificial intelligence learning model according to an exemplary embodiment of the present disclosure.

[0021] FIG. 3 is a data flow diagram illustrating the update process of an artificial intelligence learning model according to an exemplary embodiment of the present disclosure.

[0022] FIG. 4 is a block diagram illustrating the learning and prediction process of an artificial intelligence learning model according to an exemplary embodiment of the present disclosure.

[0023] FIG. 5 is a block diagram illustrating an SCR monitoring process according to an exemplary embodiment of the present disclosure.

[0024] FIG. 6 is a schematic flowchart illustrating a decision process for providing maintenance request data according to an exemplary embodiment of the present disclosure.

[0025] FIG. 7 is a schematic flowchart for providing maintenance request data during driving of mobility according to an exemplary embodiment of the present disclosure.

[0026] FIG. 8 is a schematic flowchart for providing maintenance request data while a mobility is stopped, according to an exemplary embodiment of the present disclosure.

[0027] FIG. 9 is a schematic flowchart illustrating a process for determining whether a mobility is lifted according to an exemplary embodiment of the present disclosure.

[0028] FIGS. 10 to 15 are exemplary diagrams of providing SCR-related maintenance request data according to exemplary embodiments of the present disclosure.

[0029] FIGS. 16 to 19 are exemplary diagrams of providing DPF-related maintenance request data according to exemplary embodiments of the present disclosure.

[0030] FIGS. 20 to 23 are exemplary diagrams of providing engine oil-related maintenance request data according to exemplary embodiments of the present disclosure.

[0031] The present disclosure is capable of various modifications and may have various embodiments; specific embodiments are illustrated in the drawings and described in detail in the detailed description. The effects and features of the present disclosure and the methods for achieving them will become clear by referring to the embodiments described below in detail together with the drawings. However, the present disclosure is not limited to the embodiments disclosed below and may be implemented in various forms.

[0032] In the following embodiments, terms such as first, second, etc. are used not in a limiting sense, but for the purpose of distinguishing one component from another component.

[0033] In the following examples, singular expressions include plural expressions unless the context clearly indicates otherwise.

[0034] In the following embodiments, terms such as "include" or "have" mean that the features or components described in the specification are present, and do not preclude the possibility that one or more other features or components may be added.

[0035] In the following embodiments, when a part such as a layer, region, or component is described as being on or above another part, it includes not only cases where it is directly on top of another part, but also cases where another region, component, etc. is interposed in between.

[0036] In the drawings, the size of components may be exaggerated or reduced for convenience of explanation. For example, the size and thickness of each component shown in the drawings are depicted arbitrarily for convenience of explanation, and therefore the present disclosure is not necessarily limited to what is depicted.

[0037] Where an embodiment can be implemented differently, a specific sequence of operations may be performed differently from the order described. For example, two steps described consecutively may be performed substantially simultaneously or proceed in the reverse order of the description.

[0038] In this specification, “A and / or B” indicates the case where it is A, B, or both A and B. And, “at least one of A and B” indicates the case where it is A, B, or both A and B.

[0039] In the following embodiments, when layers, regions, components, etc. are described as being connected, this includes cases where the layers, regions, components are directly connected, or / or cases where other layers, regions, components are interposed between the layers, regions, components to form an indirect connection. For example, when layers, regions, components, etc. are described as being electrically connected in this specification, it indicates cases where the layers, regions, components, etc. are directly electrically connected, and / or cases where other layers, regions, components, etc. are interposed between them to form an indirect electrical connection.

[0040] The x-axis, y-axis, and z-axis are not limited to the three axes of an orthogonal coordinate system but can be interpreted in a broader sense that includes them. For example, the x-axis, y-axis, and z-axis may be orthogonal to each other, but they may also refer to different directions that are not orthogonal to each other.

[0041] The advantages and features of the present disclosure and the methods for achieving them will become clear by referring to the embodiments described below in detail together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below but may be implemented in various different forms. These embodiments are provided merely to ensure that the disclosure is complete and to fully inform those skilled in the art of the scope of the present disclosure, and the present disclosure is defined only by the scope of the claims.

[0042] The terms used in this disclosure are for describing the embodiments and are not intended to limit this disclosure. In this disclosure, the singular form may include the plural form unless specifically stated otherwise in the text. The terms “comprises” and / or “comprising” used in this disclosure do not exclude the presence or addition of one or more other components in addition to the components mentioned. Throughout the disclosure, the same reference numerals refer to the same components, and “and / or” may include each of the mentioned components and all combinations of one or more. Although terms such as “first,” “second,” etc., are used to describe various components, these components are not limited by these terms. These terms are used merely to distinguish one component from another. Accordingly, the first component mentioned below may be the second component within the technical scope of this disclosure.

[0043] The word "exemplary" is used in this disclosure to mean "used as an example or illustration." Any embodiment described as "exemplary" in this disclosure must not be interpreted as being preferred or having an advantage over other embodiments.

[0044] Embodiments of the present disclosure may be described in terms of functions or blocks performing functions. A block, which may be referred to as a “part” or “module” in the present disclosure, may be physically implemented by analog or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory, passive electronic components, active electronic components, optical components, hardwired circuits, etc., and may optionally be driven by firmware and software. Additionally, the term “part” as used in the disclosure refers to a hardware element such as software, FPGA, or ASIC, and the “part” may perform certain roles. However, the meaning of “part” is not limited to software or hardware. The “part” may be configured to reside in an addressable storage medium or may be configured to run one or more processors. Accordingly, as an example, a "part" may include elements such as software elements, object-oriented software elements, class elements, and task elements, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functionality provided within the elements and "parts" may be combined into a smaller number of elements and "parts" or further separated into additional elements and "parts."

[0045] Embodiments of the present disclosure may be implemented using at least one software program running on at least one hardware device and may perform network management functions to control elements.

[0046] Spatially relative terms such as "below," "beneath," "lower," "above," and "upper" may be used to facilitate the description of the relationship between one component and other components as illustrated in the drawings. Spatially relative terms should be understood as encompassing different orientations of components during use or operation, in addition to the orientations depicted in the drawings. For example, if a component depicted in a drawing is inverted, a component described as "below" or "beneath" of another component may be placed "above" of that component. Therefore, the exemplary term "below" may encompass both the lower and upper directions. Components may also be oriented in other directions, and accordingly, spatially relative terms may be interpreted according to the orientation.

[0047] Unless otherwise defined, all terms used in this disclosure (including technical and scientific terms) may be used in a meaning commonly understood by those skilled in the art to which this disclosure pertains. Additionally, terms defined in commonly used dictionaries are not to be interpreted ideally or excessively unless explicitly and specifically defined otherwise.

[0048] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings. When describing with reference to the drawings, identical or corresponding components are given the same reference numerals, and redundant descriptions thereof will be omitted.

[0049] FIG. 1 is a block diagram schematically illustrating a system (10) that provides customized maintenance request data for individual vehicles using an artificial intelligence learning model according to an exemplary embodiment of the present disclosure.

[0050] Referring to FIG. 1, the electronic device (100) may include a processor (110), a communication unit (120), and a memory (130), etc. The internal components that the electronic device (100) may include are not limited thereto. The electronic device (100) of the present disclosure may perform the function of the processor (110) through a separate processing server or cloud server instead of the processor (110).

[0051] The electronic device (100) according to the embodiment may be an on-device device that utilizes a type of machine learning model. The on-device device may include a device that provides data to another device connected to a network via an application or the web. For example, the other device may include a desktop, laptop, tablet, mobile terminal, navigation device (500), etc. As another example, the electronic device (100) may be a device that encompasses an electronic device of specifications capable of performing the operation of the present disclosure.

[0052] Referring to FIG. 1, the processor (110) may be implemented to perform data processing for checking the stress index of a worker and providing feedback data according to the stress index using the data stored in the memory (130), and a memory (130) that stores data for an algorithm or a program that reproduces the algorithm for controlling the operation of components within the electronic device (100). At this time, the processor (110) and the memory (130) may each be implemented as separate chips. Alternatively, the processor (110) and the memory (130) may be implemented as a single chip.

[0053] The processor (110) can control one or a combination of the components described above to implement various embodiments according to the present disclosure described in FIGS. 2 to 9 below in the electronic device (100).

[0054] The communication unit (120) according to the embodiment may include one or more components that enable communication with an external device. For example, the communication unit (120) may include at least one of a broadcast receiving module, a wired communication module, a wireless communication module, a short-range communication module, and a location information module.

[0055] An input / output interface (not shown) according to an embodiment serves as a passage to various types of external devices connected to the electronic device (100) of the present disclosure. Such an input / output interface may include at least one of a wired / wireless headset port, an external charger port, a wired / wireless data port, a memory card port, a port for connecting a device equipped with an identification module (SIM), an audio I / O (Input / Output) port, a video I / O (Input / Output) port, and an earphone port. The electronic device (100) of the present disclosure can perform appropriate control related to the external device connected to the input / output interface.

[0056] The memory (130) according to the embodiment can store data supporting various functions of the electronic device (100) and a program for the operation of the processor (110), and can store input / output data (e.g., images, video, etc.). The memory (130) can store a plurality of application programs (application programs or applications) running on the electronic device (100), data for the operation of the electronic device (100), and instructions. At least some of these application programs can be downloaded from an external server via wireless communication.

[0057] Such memory (130) may include at least one type of storage medium among flash memory type, hard disk type, SSD type (Solid State Disk type), SSD type (Silicon Disk Drive type), multimedia card micro type, card type memory (e.g., SD or XD memory, etc.), RAM (random access memory; RAM), SRAM (static random access memory), ROM (read-only memory; ROM), EEPROM (electrically erasable programmable read-only memory), PROM (programmable read-only memory), magnetic memory, magnetic disk, and optical disk. Additionally, the memory (130) may be a database that is separated from the electronic device (100) but connected via wired or wireless connection.

[0058] At least one component may be added or removed in response to the performance of the components illustrated in FIG. 1. Additionally, it will be readily understood by those skilled in the art that the relative positions of the components may be changed in response to the performance or structure of the device.

[0059] Meanwhile, the disclosed embodiments may be implemented in the form of a recording medium that stores instructions executable by a computer. The instructions may be stored in the form of program code and, when executed by a processor, may generate a program module to perform the operation of the disclosed embodiments. The recording medium may be implemented as a computer-readable recording medium.

[0060] Computer-readable recording media include all types of recording media that store instructions that can be decoded by a computer. Examples include ROM (Read Only Memory), RAM (Random Access Memory), magnetic tape, magnetic disk, flash memory, optical data storage devices, etc.

[0061] Referring to FIG. 2, the Electronic Control Unit (ECU) (200) is an electronic control unit of a vehicle (e.g., mobility) and can perform functions to control various functions of the vehicle. The ECU (200) can adjust the fuel injection amount, ignition timing, and the ratio of air to fuel for engine control. In addition, the ECU (200) can select the shift timing or gear of an automatic transmission for transmission control. The ECU (200) controls ABS, ESP, etc. for safety system control, and can control air conditioning, electric seats, etc. for convenience function control.

[0062] The ECU (200) according to the embodiment can collect and analyze data from various sensors provided in the vehicle. The ECU (200) can generate optimal control commands based on the analyzed data.

[0063] According to an embodiment, the TCU (Transmission Control Unit) (300) may include a device for controlling the vehicle's transmission. The TCU (300) can determine the optimal shift timing and shifting method. For example, the TCU (300) monitors the vehicle's speed, engine rotation speed, accelerator pedal position, etc., and can optimize fuel efficiency and driving performance.

[0064] The TCU (300) according to the embodiment can control the transmission solenoid, pressure control solenoid, torque converter clutch solenoid, etc. based on the vehicle speed sensor, turbine speed sensor, transmission fluid temperature, throttle position sensor, brake switch, traction control system information, etc.

[0065] The Domain Control Unit (DCU) (400) according to the embodiment may be a device that performs important functions primarily in autonomous driving and advanced driver assistance systems of a vehicle. The DCU (400) can integrate data from various sensors, such as lidar, radar, cameras, and ultrasonic sensors, and generate a comprehensive solution for the vehicle's surrounding environment through advanced algorithms.

[0066] According to an embodiment, the navigation device (500) may be a device that provides traffic information such as the vehicle's driving course, driving time, and traffic congestion, average driving speed, and frequency of rapid acceleration or rapid deceleration. The navigation device (500) may generally be a panel-type device equipped in a vehicle and may include a device that primarily visualizes and provides the vehicle's real-time driving environment on a dashboard.

[0067] FIG. 2 is a flowchart schematically illustrating a method for providing customized maintenance request data for individual vehicles using an artificial intelligence learning model according to an exemplary embodiment of the present disclosure.

[0068] Referring to FIG. 2, at step S100, a processor (e.g., processor (110) of FIG. 1) may receive status data for mobility. Mobility may include a first mobility owned by a first user. Additionally, mobility may include a second mobility owned by a second user.

[0069] A processor according to an embodiment can receive at least one state data. The at least one state data may include time series data and numeric data. The processor can classify the at least one state data into time series data and numeric data.

[0070] A processor according to an embodiment can process at least one state data to correspond to the input dimension of a hybrid model. The at least one state data may be data representing a real-time state according to the driving of the mobility. For example, when the mobility is driving, the state data may be data used to determine whether to respond to a state where maintenance is requested by checking whether the current engine rotational speed of the mobility is within a certain range. As another example, when the mobility is stopped, the state data may be data used to determine whether to respond to a state where maintenance is requested by checking whether the current NOx concentration of the mobility is within a certain range.

[0071] The hybrid model according to the embodiment may include an artificial intelligence learning model for processing time series data and numerical data. For example, the hybrid model may include an LSTM layer and an FC layer, and may generate maintenance request data by summing the state data processed in each layer.

[0072] At least one state data according to the embodiment may be collected from an ECU (e.g., ECU (200) of FIG. 1), a TCU (e.g., TCU (300) of FIG. 1), and a DCU (e.g., DCU (400) of FIG. 1) and provided to an electronic device (e.g., electronic device (100) of FIG. 1). At this time, the processor may use the state data mapped from the time-series data of the first mobility to determine maintenance and the state data mapped from the numerical data to determine maintenance to predict maintenance request data through a hybrid model.

[0073] A processor according to an embodiment can receive driving path data of the first mobility from a navigation device (e.g., the navigation device (500) of FIG. 1). For example, the processor can check data regarding vehicle repair shops, oil change stations, emergency stop sections, etc. within the driving path provided through the navigation device.

[0074] In step S200, the processor may extract features for maintenance prediction. For example, the processor may label cases where at least one state data for the first mobility matches the maintenance request data. The maintenance request data may include alarm data or warning data, etc., generated to request maintenance when the mobility is in a state requiring maintenance. That is, the maintenance request data may be data intended to indicate the need for maintenance of the mobility in response to an abnormal state of the mobility.

[0075] When the processor according to the embodiment takes state data of the first mobility as input, it can match maintenance items corresponding to each state data as maintenance request data. That is, to train a hybrid model, the processor can use the state data of the mobility as input data and the measures to be taken on the mobility in response to that state as output data. The processor can train the hybrid model by labeling the maintenance request data corresponding to the state data for supervised learning of the hybrid model. At this time, the processor can proceed with training the hybrid model based on a training data set. For example, the processor can train the hybrid model to find a specific pattern by performing iterative training on the training data set multiple times. At this time, the processor can learn a pattern in which maintenance of the mobility is required when the engine temperature of the mobility exceeds a specific range and the driving distance increases. In addition, the processor can receive a hybrid model that has already been trained through an external server and generate maintenance request data corresponding to the state data of the mobility.

[0076] In step S300, the processor can validate the trained hybrid model. The processor can first determine whether it is the same mobility model as the first mobility. Afterward, the processor can validate the trained hybrid model on the extracted features after confirming that it is the same model as the first mobility.

[0077] A processor according to an embodiment can determine a training data set used for training a hybrid model and a validation data set used for validation. The processor can calculate a prediction error for the results of the training process through a loss function (e.g., Mean Squared Error (MSE)). At this time, the processor can optimize the parameters of the hybrid training model through a backpropagation algorithm to reduce the error.

[0078] According to an embodiment, the processor can evaluate the prediction accuracy of a learned hybrid model based on a validation dataset. For example, the processor can evaluate whether the hybrid learning model is correctly predicting the maintenance based on engine temperature and mileage data of the mobility. Based on the accuracy evaluation results, the processor can tune the hyperparameters of the learned hybrid model. In this case, the hyperparameters may include at least one of a learning rate, the number of hidden layers, the number of nodes in individual layers, and the sequence length.

[0079] The processor according to the embodiment can change the learning speed by adjusting the learning rate. Additionally, the processor can enable more precise predictions by increasing the complexity of the hybrid model through the addition of hidden layers. In this case, the processor can perform cross-validation by dividing the validation data into multiple folds. In this case, the generalization performance of the hybrid model can be evaluated without relying on a specific partition of the data. After cross-validation, the processor can determine the optimal combination of hyperparameters by comparing the performance of the hybrid model.

[0080] In step S400, the processor can provide maintenance request data. The processor can provide maintenance request data for the first mobility to the first user using a learned hybrid model.

[0081] A processor according to an embodiment can generate maintenance request data in the form of a notification message using a learned hybrid model. At this time, the processor can provide the notification message to a first user through a plurality of channels. For example, the plurality of channels may include the first user's mobile terminal, a navigation device, a dashboard of the first mobility, etc.

[0082] A processor according to an embodiment can provide valid maintenance request data on a driving path to a first user by using a hybrid model based on driving path data collected in real time from a navigation device. The valid maintenance request data may include, for example, data regarding maintenance requests that can be processed on a driving path among maintenance requests corresponding to the state of the first mobility determined in real time by the processor. Specifically, if the processor determines, using a hybrid model, that engine oil needs to be replenished due to a shortage of engine oil in the first mobility, it can provide information to the first user about a location on the driving path where engine oil can be replenished.

[0083] is a data flow diagram illustrating the update process of an artificial intelligence learning model according to an exemplary embodiment of the present disclosure.

[0084] Referring to FIG. 3, the electronic device (100) can exchange data with the server (600). The server (600) may be a separate device for cumulatively training a hybrid learning model.

[0085] According to an embodiment, the electronic device (100) may provide learning data (e.g., training data and validation data) for the first mobility to the server (600) (310). This may be for providing feedback to improve the performance of the prediction results of the hybrid model applied to the first mobility through the server (600).

[0086] The server (600) according to the embodiment may provide learning data for the second mobility to the electronic device (100) (320). This may be used to update the model to improve the performance of the hybrid model used through the electronic device (100). That is, the electronic device (100) may be configured to determine the model of the mobility and to apply similar cases for other models in order to predict and provide maintenance request data suitable for the mobility based on the model determination.

[0087] For example, the server (600) can perform learning on the second mobility owned by the second user. This may involve the server (600) training a hybrid model. At the same time, the processor (e.g., the processor (110) of FIG. 1) can provide the first user with maintenance request data corresponding to the real-time status of the first mobility in response to cumulatively learning maintenance request data for each mobility and determining whether the first mobility and the second mobility are of the same mobility model. Even if the first mobility and the second mobility are different models, the processor can refer to the status data and maintenance request data regarding parts compatible between the first mobility and the second mobility to use for prediction in the hybrid model. That is, by updating the hybrid model (330), the processor can generate and provide user-customized maintenance request data for the first mobility.

[0088] FIG. 4 is a block diagram illustrating the learning and prediction process of an artificial intelligence learning model according to an exemplary embodiment of the present disclosure.

[0089] Referring to FIG. 4, the hybrid model may include a Long Short-Term Memory (LSTM) layer and an FC layer. Each layer may be configured to learn data of a specific format. This reflects the characteristics of the layer, and may involve setting features suitable for learning according to the characteristics of the layer. Accordingly, the trained hybrid model can provide maintenance request data (430) as output.

[0090] The LSTM layer according to the embodiment can normalize the time series data (410) by scaling the time series data (410) to a range of 0 to 1. Accordingly, the LSTM layer can organize the data into an input sequence and an output sequence. Such a process may be a data preprocessing process for the time series data (410) of the LSTM layer.

[0091] Time series data (410) may refer to data that is measured sequentially over time. For example, time series data (410) may include data such as changes in vehicle speed, changes in fuel consumption, changes in tire pressure, changes in GPS coordinates, changes in battery charge status, brake usage patterns, acceleration patterns, and changes in the internal and external temperatures of the vehicle. Time series data (410) may have a structure that includes timestamps. Through this, the processor can continuously check the time series data (410) at regular time intervals.

[0092] According to the embodiment, the LSTM layer determines the size of the hidden state and can stack multiple layers as needed. Additionally, the LSTM layer can utilize the mean squared function as the loss function, select an optimization algorithm such as Adam or RMSprop, and set the Mean Absolute Error (MAE) as the evaluation metric. The LSTM layer performs training by setting the batch size and the number of epochs, and can perform overfitting monitoring using validation data.

[0093] The FC layer according to the embodiment can normalize the numeric data (420) by scaling the numeric data (420) to a range of 0 to 1. If necessary, the FC layer can perform encoding using one-hot encoding for categorical data. Such a process may be a data preprocessing process for the numeric data (420) of the FC layer.

[0094] Numerical data (420) may refer to a single value measured at a specific point in time and may mean data that is not directly related to the flow of time. For example, numerical data (420) may include data such as total mileage, current fuel level, current tire pressure, vehicle weight, engine oil amount, coolant amount, battery charge status, vehicle height, vehicle length, vehicle width, and number of passengers. Numerical data (420) may have a single value structure and may be data representing the state at a specific point in time.

[0095] According to the embodiment, the FC layer can be configured as an input layer by setting the number of nodes to match the number of features of the numerical data (420). Additionally, the output layer can be configured to match the shape of the value to be predicted. At this time, the hidden layer can be configured by stacking multiple FC layers, and the number of nodes in each layer can be determined according to the complexity of the problem.

[0096] The FC layer can utilize the mean squared function as the loss function for regression problems and cross-entropy for classification problems. Since the FC layer of the present disclosure often deals with classification problems, cross-entropy can be utilized. The FC layer can select an optimization algorithm such as Adam or RMSprop and set accuracy as the evaluation metric. The FC layer performs training by setting the batch size and the number of epochs, and can monitor for overfitting by utilizing techniques such as dropout.

[0097] According to an embodiment, the processor may perform data classification to provide maintenance request data for mobility. Such data classification may be included in a preprocessing process to enhance the learning of the hybrid model. For example, the processor may classify data related to mobility into time-series data (410) and numerical data (420).

[0098] For example, the processor can verify the real-time status of the mobility through the detection of physical quantity fluctuations by sensors, the detection of abnormal conditions other than sensors, and state inference based on driving information. In the case of detecting physical quantity fluctuations by sensors, the processor can detect signs of abnormalities in the mobility by collecting mobility data in real time related to temperature changes, pressure changes, gas concentration changes, fluid distribution, change patterns, and change cycles. In the case of detecting abnormal conditions other than sensors, the processor can identify potential signs of failure in the mobility by collecting abnormal condition data that is not directly detected by sensors, such as whitening, incomplete combustion, overheating, aging, and power reduction. In the case of state inference based on driving information, the processor can predict performance degradation, fuel efficiency, and component wear status according to the driver's (e.g., first user) driving style and driving environment by collecting or analyzing data such as navigation device data, driving routes, driving habits, throttle, braking timing, cycles, and patterns.

[0099] As another example, the processor can perform a state determination corresponding to changes in mobility data. This may involve the processor performing mobility state determination and verification based on multiple determinations. In the case of mobility state determination, the processor can perform a process to determine what state of mobility a combination of changes in individual physical quantities signifies. Through this, the processor can determine how the combination of changes in individual physical quantities is interpreted as a state of mobility, and whether it is normal, faulty, or performance degraded. In the case of verification based on multiple determinations, the processor can verify by inferring a specific physical quantity (e.g., temperature) as a key factor or determine the state of mobility based on combined data. If multiple causes can be inferred for a single result, the processor can apply driving information or other additional data to ultimately determine one specific cause. Through this, the processor can improve the accuracy of state determination and optimize the hybrid model by analyzing the interrelationships between various causes.

[0100] According to the embodiment, the processor can automatically classify data collected from mobility. That is, the processor can classify whether the data corresponds to time-series data (410) or numerical data (420). For example, the processor can classify time-series data (410) and numerical data (420) by utilizing metadata included in the collected data. The data type identifier may include identifiers such as "type: time_series" or "type: numeric" in each data packet. Additionally, the processor may utilize a predefined list of parameters provided to the processor by the ECU, DCU, TCU, etc.

[0101] According to an embodiment, the processor may classify data that includes timestamps related to mobility and arrives in a continuous time sequence as time series data (410). Additionally, the processor may classify data whose values ​​change continuously over a short period as time series data (410) and data that changes relatively little as numerical data (420). This may be achieved by using criteria that analyze data change patterns. As another example, the processor may utilize data volume and reception frequency as criteria. The processor may classify data received at high frequency with large volume as time series data (410) and data received at low frequency with small volume as numerical data (420). Such data classification algorithms of the processor are merely examples and are not limited to.

[0102] FIG. 5 is a block diagram illustrating an SCR monitoring process according to an exemplary embodiment of the present disclosure.

[0103] Selective Catalytic Reduction (SCR) is an aftertreatment device that purifies exhaust gases from diesel engines. In particular, the primary purpose of SCR is to reduce nitrogen oxides (NOx) generated by diesel engines. SCR can contribute to the generation of ammonia by injecting urea solution into the exhaust gas. This generated ammonia can then react with nitrogen oxides within the catalyst to be converted into harmless nitrogen and water vapor. In other words, SCR can effectively reduce harmful substances and improve fuel efficiency by enabling the engine to operate at optimal efficiency.

[0104] Referring to FIG. 5, an electronic device (e.g., the electronic device (100) of FIG. 1) can receive status data regarding mobility from an ECU (e.g., the ECU (200) of FIG. 1), a TCU (e.g., the TCU (300) of FIG. 1), and a DCU (e.g., the DCU (400) of FIG. 1). Specifically, the ECU, TCU, and DCU can collect various sensing data from mobility. More specifically, a processor (e.g., the processor (110) of FIG. 1) can identify the sensing data collected by the ECU, TCU, and DCU as status data representing the state of mobility. Each sensing data can be detected through a sensing unit (e.g., a first sensing unit (510), a second sensing unit (520), a third sensing unit (530), and a fourth sensing unit (540)). The processor can identify state data capable of determining the state of mobility based on sensing data detected through the sensing unit. In other words, the processor can determine which sensing data indicates which state of mobility.

[0105] According to the embodiment, failure of the SCR system in mobility may occur when conditions for converting urea solution into ammonia gas are not properly met, causing only the water in the urea solution to evaporate and the remaining urea to form crystals. Additionally, types of failures in the SCR system may include electrical system problems such as abnormal battery voltage, short circuits, pump failures, or sensor malfunctions, or problems caused by component damage such as hose leakage, broken heating wires, or damage to the DPF carrier. At this time, the causes of the formation of urea crystals may include, for example, exhaust temperatures below 180 degrees, unstable exhaust pressure, over-injection of urea solution, or insufficient atomization of the injector's exposed injection state.

[0106] Referring to FIG. 5, the processor can determine a primary failure of the SCR system based on sensing data detected through the second sensing unit (520). This may be based on sensing data related to the urea tank, dosing pump, injector, etc. The processor can determine a secondary failure of the SCR system based on sensing data detected through the third sensing unit (530) and the fourth sensing unit (540). This may be based on sensing data related to the mixer or SCR. Additionally, the processor can determine a tertiary failure based on sensing data detected through the first sensing unit (510). This may be based on sensing data related to the DPF or engine.

[0107] Generally, one of the symptoms of SCR system failure is urea clogging. This usually occurs when low exhaust pressure or temperature causes only the water in the urea solution to evaporate, preventing the urea from converting into ammonia gas. The clogging can be caused by the whitening of the urea solution due to temperature fluctuations even after the engine is turned off. Locations where clogging can occur include injectors, pump nozzles, and hoses.

[0108] Another example is urea precipitation, which is a symptom of SCR system failure. Precipitation can occur when using substandard urea solution containing urea residues such as triuret, or when dissolved urea settles after being left unattended for a long period during the winter. This can occur in the urea tank or urea filter. Yet another example is urea coating, which is a symptom of SCR system failure. Coating occurs when urea injected from the injector fails to convert into ammonia gas, adsorbing onto the carrier and clogging the micro-pores. If left untreated, this coating can lower exhaust pressure, place a reverse load on the DPF and engine, and cause urea to backflow, potentially damaging the DPF. This coating can occur in the SCR carrier, mixer, or DPF.

[0109] FIG. 6 is a schematic flowchart illustrating a decision process for providing maintenance request data according to an exemplary embodiment of the present disclosure.

[0110] In step S610, a processor (e.g., processor (110) of FIG. 1) can determine whether the mobility is driving. For example, the processor can determine whether the mobility is driving based on the mobility's speed and movement.

[0111] If the speedometer reading is 0, the processor may determine that the mobility is stationary. If the GPS coordinates are continuously changing, the processor may determine that the mobility is in motion. As another example, the processor may determine that the mobility is in motion if the engine RPM is above idle speed. If the transmission is in D or another forward gear, the processor may determine that the mobility is in motion.

[0112] As another example, the processor can determine that the mobility is in motion if driving-related sensors are activated. The processor can also determine that the mobility is in motion if continuous movement of the steering wheel is detected. Additionally, the processor can determine whether the mobility is in motion based on the driver's (e.g., first user's) forward gaze, driving posture, and continuous pedal operation. Furthermore, if continuous changes in the surrounding environment of the mobility are detected via cameras or sensors, or if changes in road surface conditions or vibrations are detected, the processor can determine whether the mobility is in motion.

[0113] In step S620, the processor can determine whether there is an abnormality in the engine system. The abnormality in the engine system can be determined based on the engine rotational speed. For example, the processor can check whether the engine rotational speed is below a first reference engine rotational speed. The first reference engine rotational speed may be 700 to 900 RPM. This may vary depending on the model of the mobility.

[0114] Subsequently, if the processor detects an engine speed of 900 RPM or less than the first reference engine speed, it may determine that the mobility is stationary. Subsequently, if the current engine speed of the mobility is 800 RPM or less than the second reference engine speed, the processor may additionally check whether the current engine speed of the mobility is fixed. This is because it may be associated with conditions requiring maintenance, such as a failure of the SVC (Secondary Air Valve Control) sensor, ECU malfunction, RPM sensor failure, or instrument panel failure.

[0115] In step S630, the processor can determine whether there is an abnormality in the power system. The abnormality in the power system may be related to the battery voltage. For example, the processor can check whether the battery voltage is below a threshold voltage value (e.g., 12.6V). If the battery voltage of the mobility is below the threshold voltage value, the processor can determine that there is a problem with the power system. In this case, the processor can provide maintenance request data due to the power system abnormality.

[0116] In step S640, the processor can determine whether there is an abnormality in the exhaust system. The abnormality in the exhaust system may be related to the exhaust temperature. For example, the exhaust temperature may be the exhaust temperature of the SCR upstream section. For example, if the exhaust temperature of the SCR upstream section is below a certain temperature (e.g., 190 degrees) while the mobility is in operation, the processor may determine that there is a problem with the exhaust system. In this case, the processor may provide maintenance request data due to the exhaust system abnormality.

[0117] In step S650, the processor can determine whether there is an abnormality in the SCR system. The abnormality in the SCR system may be related to the urea line pressure, injector injection amount, SCR ammonia residue rate, upstream NOx concentration, downstream NOx concentration, SCR purification efficiency, and urea concentration. For example, if there is no change in numerical data even after chemical injection while the urea line pressure is outside a certain range (e.g., 60,000 to 70,000 hPa), the processor may determine that there is an abnormality in the SCR system. In this case, the processor may provide maintenance request data.

[0118] According to the embodiment, if the injector injection amount is less than 30%, the processor may determine that there is an SCR system abnormality due to a dosing nozzle failure in response to no change in numerical data after chemical injection. If the SCR ammonia residual rate falls outside the range of 0.9 to 1, the processor may determine that there is an SCR system abnormality due to a nozzle failure or a defective catalyst or urea solution in response to no change in numerical data after chemical injection.

[0119] According to the embodiment, if the upstream NOx concentration deviates from 100 to 200 ppm, the processor may determine that there is an SCR system malfunction by determining that it is due to engine overheating or sensor failure. Additionally, if the downstream NOx concentration deviates from 70 ppm by a 5% margin of error, the processor may determine that there is an SCR system malfunction due to sensor failure or defects in the catalyst or urea solution.

[0120] According to the embodiment, if the SCR purification efficiency is less than 0.7, the processor can determine an abnormality in the SCR system caused by a failure of the upstream / downstream sensors. In addition, if the urea solution concentration deviates by an error of 0.8% from the standard of 32.5%, the processor can determine an abnormality in the SCR system caused by poor quality of the urea solution.

[0121] In this way, the processor can check the status of the mobility through various mobility data for SCR monitoring and provide the user with measures necessary for the current mobility based on the checked status. The measures necessary for the current mobility can correspond to maintenance request data, which can be utilized as a dataset for training the hybrid model. That is, maintenance request data refers to measures requiring a response due to mobility anomalies, and may correspond to the labeling target for at least one status data.

[0122] FIG. 7 is a schematic flowchart for providing maintenance request data during driving of a mobility according to an exemplary embodiment of the present disclosure. Referring to FIG. 7, an electronic device (e.g., the electronic device (100) of FIG. 1) can match maintenance request data indicating that a breakdown or diagnosis of the mobility is required with various status data of the mobility and provide it to the user.

[0123] In step S611, the processor (e.g., the processor (110) of FIG. 1) may determine that the mobility is in motion. The criteria for the processor determining that the mobility is in motion may include at least one.

[0124] In step S621, the processor can determine whether there is an abnormality in the engine system based on the engine speed. In this case, the processor can check the engine speed under the premise that the vehicle is in motion. If the processor determines that there is an abnormality in the engine speed of the mobility, the processor can provide detailed maintenance request data, such as repairs to the engine system, repairs to the SVC sensor, repairs to the ECU, repairs to the RPM sensor, or instrument panel failures.

[0125] In step S631, the processor can determine whether there is an abnormality in the power system through the battery voltage. For example, if the processor determines that the battery voltage is below a threshold voltage value (e.g., 12.6V), the processor can determine that there is a problem with the power system of the mobility. In this case, the processor can provide a battery replacement notification as maintenance request data due to the power system abnormality.

[0126] In step S641, the processor can determine whether there is an abnormality in the exhaust system through the exhaust temperature of the SCR upstream. For example, if the processor determines that the exhaust temperature of the SCR upstream is below a certain temperature (e.g., 190 degrees) while the mobility is in operation, the processor can determine that there is a problem with the exhaust system of the mobility. In this case, the processor can provide a fault notification for the SCR upstream as maintenance request data due to the exhaust system abnormality.

[0127] In step S651, if the urea line pressure is outside a certain range, the processor takes measures to inject a chemical and checks whether there is no change in numerical data even after the chemical injection. If the processor confirms that there is no change in the numerical data of the urea line pressure, the processor may determine that there is a problem with the mobility's SCR system. For example, if the urea line pressure is 70,000 hPa or higher, the processor may provide a notification of a clogged urea line nozzle as maintenance request data. For another example, if the urea line pressure is 60,000 hPa or lower, the processor may provide a notification of a urea line leak or a urea line pump inspection as maintenance request data.

[0128] In step S652, the processor can determine an abnormality in the SCR system based on the injector injection amount value. If the processor confirms that the injector injection amount of the mobility is less than 30%, the processor can take measures to inject a chemical and check whether there is a change in the injector injection amount value data thereafter. If the processor confirms that there is no change in the injector injection amount value data, the processor can provide a notification of suspected failure of the dosing nozzle injecting the injector as maintenance request data.

[0129] In step S653, the processor can determine an abnormality in the SCR system based on the SCR ammonia residual rate. If the SCR ammonia residual rate falls outside the range of 0.9 to 1, the processor can determine to inject a chemical. Subsequently, if the processor confirms that the SCR ammonia residual rate data is 1.5 or higher, the processor can provide a notification of nozzle failure as maintenance request data. If the processor confirms that the SCR ammonia residual rate data is 0.5 or lower, the processor can provide a notification of catalyst or urea solution defect as maintenance request data.

[0130] In step S654, the processor can determine an abnormality in the SCR system based on the shear NOx concentration. If it is confirmed that the shear NOx concentration has deviated from 100 to 200 ppm and increased by 30% or more, the processor can provide an engine overheating notification as maintenance request data. Alternatively, if it is confirmed that the NOx value is abnormal, the processor can provide a sensor failure notification as maintenance request data.

[0131] In step S655, the processor can determine an abnormality in the SCR system based on the downstream NOx concentration. For example, if the downstream NOx concentration deviates from 70 ppm by a 5% margin of error, the processor can check the change in numerical data after chemical injection. Subsequently, if the upstream NOx value and the downstream NOx value are similar, the processor can provide a notification of catalyst or urea solution failure as maintenance request data. As another example, if the downstream NOx concentration is identified as abnormal, the processor can provide a sensor failure notification as maintenance request data.

[0132] In step S656, the processor can determine an abnormality in the SCR system based on the SCR purification efficiency. If the SCR purification efficiency is less than 0.7, the processor checks for a change in numerical data after chemical injection. If there is no change in the chemical numerical data, the processor can provide a failure notification of the upstream / downstream sensors as maintenance request data.

[0133] In step S657, the processor can determine an abnormality in the SCR system based on the urea solution concentration. If it is confirmed that the urea solution concentration deviates from 32.5% by an error of 0.8%, the processor can provide a notification of poor urea solution quality as maintenance request data.

[0134] FIG. 8 is a schematic flowchart for providing maintenance request data while a mobility is stopped according to an exemplary embodiment of the present disclosure. Referring to FIG. 8, an electronic device (e.g., the electronic device (100) of FIG. 1) can match maintenance request data indicating that a breakdown or diagnosis of the mobility is required with various status data of the mobility while it is stopped and provide it to the user.

[0135] In step S612, the processor (e.g., the processor (110) of FIG. 1) may determine that the mobility is stopped. The criteria for the processor determining that the mobility is stopped may include at least one.

[0136] In step S622, the processor can determine whether there is an abnormality in the engine system based on the engine speed. In this case, the processor can check the engine speed on the premise that the vehicle is stationary. For example, if the mobility is stationary and the engine speed exceeds 800 RPM, the processor can provide an SVC sensor repair notification as maintenance request data.

[0137] In step S632, the processor can determine whether there is an abnormality in the power system through the battery voltage. For example, if it is confirmed that the battery voltage is below a threshold voltage value (e.g., 12.6V) while the mobility is stationary, the processor can determine that there is a problem with the mobility's power system. In this case, the processor can provide a battery replacement notification or a battery inspection notification as maintenance request data.

[0138] Step S661 is replaced with the description of Step S651. The judgment criteria in Step S661 may be similar to those in Step S651, except that the mobility is in a driving state. Step S662 is also replaced with the description of Steps S654 and S655, provided that the respective NOx concentration criteria are appropriately changed to suit a stationary state. Step S663 is replaced with the description of Step S657.

[0139] FIG. 9 is a schematic flowchart illustrating a process for determining whether a mobility is lifted according to an exemplary embodiment of the present disclosure.

[0140] In step S410, a processor (e.g., processor (110) of FIG. 1) can check pressure sensing data of the mobility. For example, the pressure sensor may be provided in the suspension or shock absorber of the mobility. The processor can check the pressure value detected in the suspension or shock absorber. For another example, the pressure sensor may be provided in the tire of the mobility.

[0141] In step S420, the processor can determine whether the mobility is lifted up. For example, if the processor confirms that the pressure value from the suspension or shock absorber is 0, the processor can determine that the mobility is lifted up.

[0142] As another example, the processor may determine that the mobility is lifted when it detects that the tire pressure value is 32 to 35 bar. This may be because, if the processor sets the standard tire pressure range to 0 to 50 bar for a mobility weight of 1 to 2 tons, it determines the pressure value (32 to 35 bar) when the weight of the mobility is not added as a lifted state.

[0143] In step S430, the processor may provide maintenance request data for the mobility. In response to confirming the oil change history status data of the mobility, the engine performance degraded status data of the mobility, or the second derivative of the drive system sensor graph turned positive status data, the processor may provide oil change maintenance request data or engine system maintenance request data.

[0144] A processor according to an embodiment can diagnose the condition of a vehicle through condition data that can be collected from the vehicle and, if maintenance is required, provide maintenance request data to the user. Such condition data may be determined based on condition data regarding engine oil, incomplete combustion, transmission oil, etc.

[0145] According to an embodiment, the processor can identify the driving status or habits of the user, who is the owner of the vehicle. For example, the processor can identify the personalized status of the vehicle by synthesizing and verifying various status data recorded in the vehicle, such as engine oil refill timing, tire inflation timing, and battery charging timing. This data may be referenced to reflect the user's driving habits or patterns, or the user's vehicle maintenance status. In other words, the processor can determine whether maintenance is required by classifying data sensed from the vehicle itself into time-series data and numerical data. The data sensed from the vehicle itself can be matched to maintenance requirements based on numerical values ​​that serve as standards for maintenance in the vehicle model (e.g., standard values ​​provided by the manufacturer). In this disclosure, by utilizing a hybrid model, which is an artificial intelligence learning model, a vehicle maintenance notification can be provided by combining the accumulated numerical values ​​from the data analyzing patterns based on the aforementioned standard numerical values ​​and the user's driving habits. Through this, the processor can provide customized vehicle maintenance notifications to the user.

[0146] FIGS. 10 to 15 are exemplary diagrams of providing SCR-related maintenance request data according to exemplary embodiments of the present disclosure.

[0147] Referring to Fig. 10, 1040 corresponds to the exhaust temperature graph of the mobility. The value of 200 for the exhaust temperature is a threshold (lower limit) for the normal exhaust temperature and can be set through learning about the mobility. Within the range of 1010, the processor can learn the normal exhaust temperature range and set the average exhaust temperature of the corresponding mobility. Within the range of 1020, the processor can provide the mobility owner with a warning and a graph of future forecasts when the measured value continuously drops while within the normal exhaust temperature range. Within the range of 1030, the processor provides maintenance request data to promptly display a warning to the mobility owner and induce the immediate implementation of response methods when the normal exhaust temperature is deviated from.

[0148] For example, the processor may provide maintenance request data based on an analysis indicating that although the exhaust temperature is within the normal range, it is highly likely to deviate from the normal range within a few days because it has been dropping for six consecutive days. Subsequently, the processor may compare and analyze other data, such as checking DPF performance degradation data or driving records, to identify the cause of the drop in exhaust temperature. Finally, the processor may provide maintenance request data as an analysis of the drop in exhaust temperature and a corresponding solution. For example, the maintenance request data may include a notification recommending highway cruising for at least 30 minutes within a few days to maintain the condition of the aftertreatment device, noting that the duration of driving in congested areas has recently increased.

[0149] Referring to Fig. 11, 1140 corresponds to the shear NOx concentration graph of the mobility. The value of 300 for the shear NOx concentration is a threshold (upper limit) for normal shear NOx concentration and can be set through learning about the mobility. Within the range of 1110, the processor can learn the normal NOx data range and set the average shear NOx concentration of the corresponding mobility. Within the range of 1120, the processor can provide the mobility owner with a warning and a graph of future forecasts when the measured value continuously rises while within the normal shear NOx concentration range. Within the range of 1130, the processor provides maintenance request data to prompt the mobility owner to display a warning and immediately implement response measures when the normal shear NOx concentration deviates.

[0150] For example, the processor may provide maintenance request data based on an analysis indicating that although the shear NOx concentration is within the normal range, it is highly likely to exceed the normal level within a few days because the measured values ​​have been rising for six consecutive days. Subsequently, the processor may compare and analyze other data, such as checking engine overheating data or driving records, to identify the cause of the rise in shear NOx concentration. Finally, the processor may provide maintenance request data as an analysis of the rise in shear NOx concentration and a corresponding solution. For example, the maintenance request data may include a notification recommending an engine oil change within the next few days, as the recent average engine oil temperature measurement has improved and engine overheating is in progress.

[0151] Referring to Fig. 12, 1240 corresponds to the rear-end NOx concentration graph of the mobility. The rear-end NOx concentration value of 120 is the threshold for normal rear-end NOx concentration (upper limit of normal measurement value), and the value of 300 is the threshold for failure of the rear-end NOx sensor (upper limit of failure measurement value); these values ​​can be set through learning about the mobility. Within the range of 1210, the processor can learn the normal NOx data range and set the average rear-end NOx concentration of the corresponding mobility. Within the range of 1220, the processor can provide the mobility owner with a warning awareness and a future forecast graph when the measurement value continuously rises while within the normal rear-end NOx concentration range. Within the range of 1230, the processor provides maintenance request data to promptly display a warning to the mobility owner and induce the immediate implementation of response methods when the rear-end NOx concentration deviates from the normal range.

[0152] For example, the processor may provide maintenance request data based on an analysis indicating that although the downstream NOx concentration is within the normal range, the measured value has been rising for four consecutive days, making it highly likely that the normal urea solution warning light will illuminate within a few days. Subsequently, to identify the cause of the rise in downstream NOx concentration, the processor may compare and analyze other data, such as checking injector test duty data (nozzle condition check), SCR ammonia residue rate data (catalyst check), SCR purification efficiency data (sensor check), and urea solution concentration sensor data (urea solution check). Finally, the processor may provide maintenance request data as an analysis of the rise in downstream NOx concentration and a corresponding solution. For example, the maintenance request data may include a notification recommending the use of an additive and monitoring the situation, based on a comprehensive analysis of injector test injection volume and ammonia residue rate data, as the accumulation of urea crystals in the dosing nozzle is suspected.

[0153] Referring to Fig. 13, 1310 corresponds to the exhaust temperature graph of the mobility. The value of 200 for the exhaust temperature is the threshold (lower limit) for the normal exhaust temperature, and the value of 300 is the threshold (upper limit) for the normal exhaust temperature, and can be set through learning of the mobility. Fig. 13 may be an example of a graph for displaying data values ​​deviating from the normal range of the exhaust temperature and checking the frequency and density.

[0154] Referring to Fig. 14, 1410 corresponds to the shear NOx concentration graph of mobility. The value of 300 for the shear NOx concentration is a threshold (upper limit) for normal shear NOx concentration and can be set through learning of mobility. Fig. 14 may be an example of a graph to display data values ​​deviating from the normal range of shear NOx concentration and to check the frequency and density.

[0155] Referring to Fig. 15, 1510 corresponds to the rear-end NOx concentration graph of the mobility. The rear-end NOx concentration value of 100 is the threshold value (upper limit of normal measurement value) for normal rear-end NOx concentration, and the value of 300 is the threshold value (upper limit of failure measurement value) for failure of the rear-end NOx sensor, and can be set through learning of the mobility. Fig. 15 may be an example of a graph for displaying data values ​​deviating from the normal range of rear-end NOx concentration and checking frequency and density.

[0156] A processor according to an embodiment can provide maintenance request data by analyzing the graphs of FIGS. 13 to 15. For example, regarding the frequency of deviation from normal exhaust temperature, the processor can confirm that over the past month, there were deviations from the lower limit of exhaust temperature 54 times, the upper limit of exhaust temperature 7 times, the upper limit of the front NOx sensor sensing value 44 times, and the upper limit of the rear NOx sensor sensing value 38 times. Subsequently, the processor can compare and analyze RPM data, driving speed data, driving record data, etc., to check the cause of the deviation from normal exhaust temperature. Finally, the processor can provide maintenance request data as a solution corresponding to the analysis of the deviation from normal exhaust temperature. For example, based on the results of a comprehensive analysis of data such as deviations from the lower exhaust temperature limit, deviations from the upper exhaust temperature limit, deviations from the upper limit of the upstream NOx sensing value, and deviations from the upper limit of the downstream NOx sensing value, the processor may indicate that SCR operation was not smooth due to a drop in exhaust temperature caused by driving during heavy traffic hours over the past month, and that if the current driving environment is repeated, it may lead to injection failure of the dosing nozzle. Additionally, since the downstream NOx sensing value has been outside the normal range for 7 days, it may provide a notification recommending the use of one bottle of urea additive for efficient management, intensive monitoring until the downstream NOx data is normalized, and recommending an inspection at a nearby service center if it is not normalized within one period.

[0157] FIGS. 16 to 19 are exemplary diagrams of providing DPF-related maintenance request data according to exemplary embodiments of the present disclosure.

[0158] Referring to Fig. 16, 1630 and 1640 correspond to graphs of the PM collection completion distance and PM collection amount of the mobility, respectively. Within the range of 1610, the processor can learn the collection completion distance and set the average distance of the mobility. Within the range of 1620, if the PM collection completion distance falls below the average, the processor can provide DPF monitoring and a warning notification to the mobility owner.

[0159] Referring to Fig. 17, 1740 corresponds to the PM capture graph. The value of 10 for the PM capture is a threshold (lower limit of normal measurements) for normal PM capture and can be set through learning about the mobility. Within the range of 1710, the processor can learn the PM capture and set the average PM capture for the corresponding mobility. Within the range of 1720, the processor can provide a warning notification to the mobility owner along with intensive data monitoring when the PM capture continuously decreases. Within the range of 1730, the processor can provide a notification to the mobility owner encouraging the implementation of a rapid response method along with a DPF performance degradation warning notification when the PM capture drops below 50%.

[0160] Referring to Fig. 18, 1840 corresponds to the DPF temperature graph during normal driving, 1850 corresponds to the DPF temperature graph during DPF regeneration, 1860 corresponds to the DPF downstream temperature graph, and 1870 corresponds to the DPF upstream temperature graph. Within the range of 1810, the processor can measure the DPF upstream and downstream temperatures and record the average temperature values. Within the range of 1820, the processor can notify the mobility owner that clogging of the DPF catalyst (carrier) has begun if a temperature difference occurs between the DPF upstream and downstream. Within the range of 1830, the processor can provide a notification that cleaning or carrier replacement is urgently required due to DPF performance degradation if the temperature difference between the DPF upstream and downstream is maximized.

[0161] Referring to Fig. 19, 1940 corresponds to the DPF regeneration time graph. Within the range of 1910, the processor can measure the DPF regeneration time and record the average regeneration time. Within the range of 1920, the processor interprets the reduction in DPF regeneration time as a decrease in the accumulated amount of soot, highlights the accumulated amount of ash within the DPF, and provides a warning notification regarding performance degradation. Within the range of 1930, the processor determines that the repeated short DPF regeneration times indicate a severe level of DPF performance degradation due to ash, and can provide a notification to the mobility owner for cleaning or replacement. If DPF regeneration failures (interruptions) occur frequently, the processor can provide a notification to improve the DPF regeneration environment, attributing this to potential causes of performance degradation.

[0162] A processor according to an embodiment can interpret a graph of various data related to DPF failure to provide DPF maintenance request data, and can identify the cause by analyzing the graph based on various sensing data. Accordingly, the processor can provide DPF-related maintenance request data to the mobility owner.

[0163] FIGS. 20 to 23 are exemplary diagrams of providing engine oil-related maintenance request data according to exemplary embodiments of the present disclosure.

[0164] Referring to Fig. 20, 2040 corresponds to the engine oil temperature graph of the mobility. The value of 100 for the engine oil temperature is a threshold (upper limit) for normal engine oil temperature and can be set through learning about the mobility. Within the range of 2010, the processor can record the engine oil temperature and set the average engine oil temperature of the corresponding mobility. Within the range of 2020, the processor can intensively monitor if the engine oil temperature rises above the average engine oil temperature and provide a warning alert to the mobility owner regarding oil performance degradation. Within the range of 2030, the processor can raise awareness by determining that the upper limit of the normal engine oil temperature has been exceeded and providing a notification that forces an oil change due to poor performance.

[0165] Referring to Fig. 21, 2130 corresponds to the average fuel efficiency graph of the mobility. Within the range of 2110, the processor can check the average fuel efficiency for driving the mobility and set the average fuel efficiency for each driving environment of the mobility. Within the range of 2120, if a decrease in fuel efficiency is continuously observed under the same driving conditions, the processor can provide a notification that the engine oil change time has arrived.

[0166] Referring to Fig. 22, 2230 corresponds to the shear NOx concentration graph of the mobility. Within the range of 2210, the processor can determine whether the engine oil is normal by referring to the SCR NOx sensor sensing value. Within the range of 2220, the processor can compare and analyze data on whether exhaust gas has increased based on the SCR NOx sensor sensing value. Referring to Fig. 23, 2330 corresponds to the PM capture amount graph of the mobility. Within the range of 2310, the processor can compare engine oil-related data with the PM capture amount. Within the range of 2320, the processor can provide a notification of engine oil performance degradation in response to the continuous increase in PM capture amount and the shortening of the regeneration cycle.

[0167] In this way, the processor can train an artificial intelligence model to comprehensively analyze various data related to the generation of individual maintenance request data within the mobility. Accordingly, the processor can provide the mobility owner with notifications based on maintenance request data that enable an appropriate response at the optimal time.

[0168] Although the present disclosure has primarily described electronic devices so far, it is not limited thereto. For example, a method for manufacturing such electronic devices is also considered to fall within the scope of the present disclosure.

[0169] Although the present disclosure has been described with reference to the embodiments illustrated in the drawings, this is merely illustrative, and those skilled in the art will understand that various modifications and equivalent alternative embodiments are possible therefrom. Accordingly, the true technical scope of protection of the present disclosure should be determined by the technical spirit of the appended claims.

Claims

1. A method for providing customized maintenance request data for individual vehicles using an artificial intelligence learning model, The operation of receiving at least one state data for the first mobility from the first mobility owned by the first user; An operation to extract features for performing maintenance prediction for the first mobility based on at least one state data for the first mobility; An operation to verify a hybrid model trained on the extracted features based on a mobility model identical to the first mobility; and A method for providing customized maintenance request data, comprising the operation of providing maintenance request data for the first mobility to the first user using the above-mentioned learned hybrid model.

2. In Paragraph 1, The operation of receiving at least one state data above is, The operation of classifying at least one state data into time series data and numerical data; and A method for providing customized maintenance request data, comprising the operation of processing the time series data and the numerical data to correspond to the input dimensions of the hybrid model.

3. In Paragraph 1, The above at least one state data is, A method for providing customized maintenance request data, comprising state data capable of determining maintenance that is collected and received from an ECU (Engine Control Unit), a TCU (Transmission Control Unit), and a DCU (Domain Control Unit), and mapped from time-series data of the first mobility, and state data capable of determining maintenance that is mapped from numerical data of the first mobility.

4. In Paragraph 1, The operation of extracting the above features is, A method for providing customized maintenance request data, comprising the operation of labeling the case where at least one state data for the first mobility matches the maintenance request data.

5. In Paragraph 1, It includes an operation to train the above hybrid model based on a training data set, and The operation of validating the above-mentioned learned hybrid model is, An operation to determine a training data set used for training the above hybrid model and a validation data set used for validation; and A method for providing customized maintenance request data, comprising an operation to calculate a prediction error through a loss function for the above learning progress results.

6. In Paragraph 5, The operation of validating the above-mentioned learned hybrid model is, An operation to evaluate the prediction accuracy of the learned hybrid model based on the above verification data set; and It includes an operation to tune the hyperparameters of the learned hybrid model based on the accuracy evaluation results above, and A method for providing customized maintenance request data, wherein the hyperparameters include at least one of a learning rate, the number of hidden layers, the number of nodes of individual layers, and the sequence length.

7. In Paragraph 1, The operation of providing the above maintenance request data to the first user is, A method for providing customized maintenance request data, comprising the operation of generating the maintenance request data in the form of a notification message using the above-mentioned learned hybrid model and providing it to the first user through a plurality of channels.

8. In Paragraph 1, The operation of receiving at least one state data above is, The method includes the operation of receiving driving path data of the first mobility from a navigation device. The operation of providing the above maintenance request data to the first user is, A method for providing customized maintenance request data, comprising the operation of providing maintenance request data valid on the driving path to the first user using the hybrid model based on the driving path data collected in real time from the navigation device.

9. In Paragraph 1, The operation of providing the above maintenance request data to the first user is, A method for providing customized maintenance request data, comprising the operation of determining whether the first mobility is lifted up based on pressure sensing data among the numerical data of the first mobility and providing the maintenance request data to the first user.

10. In Paragraph 1, The above-mentioned learned hybrid model is, Perform learning on the second mobility owned by the second user, and A method for providing customized maintenance request data, characterized by providing maintenance request data corresponding to the real-time status of the first mobility to the first user in response to determining whether the first mobility and the second mobility are the same mobility model and accumulatingly learning maintenance request data for individual mobilitys.

11. An electronic device that provides customized maintenance request data for individual vehicles using an artificial intelligence learning model, Communications Department; Memory; and It includes at least one processor electrically connected to the communication unit and the memory, and The above-mentioned at least one processor is, A customized maintenance request data providing electronic device configured to receive at least one state data for a first mobility owned by a first user, extract a feature for performing a maintenance prediction for the first mobility based on at least one state data for the first mobility, verify a hybrid model learned on the extracted feature based on a mobility model identical to the first mobility, and provide maintenance request data for the first mobility to the first user using the learned hybrid model.

Images