KR102420514B1 - Hardware/software defect detection method using deep learning and analysis apparatus - Google Patents

Abstract

A hardware and software defect detection method using deep learning comprises the steps of: obtaining, by an analysis device, a performance log and an execution log for a specific task of a target device that is an object subject to defect detection; and detecting, by the analysis device, a software defect or a hardware defect for the specific task based on at least one of the performance log and the execution log. The analysis device detects a defect by comparing at least one piece of information extracted from the performance log and the execution log with a first constant value, or detects a defect based on a value obtained by calculating a second constant value on a value of the information. The first constant value or the second constant value is adjusted to a value output from a deep learning model trained by using an actual defect result and a defect detection result predicted based on a performance log and an execution log of a device.

Description

HARDWARE/SOFTWARE DEFECT DETECTION METHOD USING DEEP LEARNING AND ANALYSIS APPARATUS

Techniques to be described below relate to techniques for detecting hardware and software faults.

With the advent of the fourth industrial age, various software and hardware running the software are being used in various industrial fields. In particular, software malfunction may cause a major problem in a system connected to a network using technologies such as the Internet of Things.

Korean Patent Publication No. 10-2016-0061237

Software related to the 4th industry generally shares data through a network. Accordingly, factors that may cause an operation defect are currently being diversified. In addition, the conditions required for defect detection may be dynamically changed according to the network status or software execution status.

The technique to be described below detects whether a device is defective based on the execution log and performance log of the device in real time, and provides a technique for dynamically adjusting a constant value used for fault detection using a deep learning model.

A hardware and software defect detection method using deep learning includes the steps of, by an analysis device, obtaining a performance log and an execution log for a specific task of a target device that is a target of defect detection, and the analysis device based on at least one of the performance log and the execution log and detecting a software defect or a hardware defect for the specific task. The analysis device detects a defect by comparing at least one piece of information extracted from the performance log and the execution log with a first constant value, or detects a defect based on a value obtained by calculating a second constant value on the value of the information, , the first constant value or the second constant value is adjusted to a value output from a deep learning model that is learned using a defect detection result predicted based on a performance log and an execution log of the device and an actual defect result.

An analysis device that detects hardware and software defects uses the input device that receives the performance log and execution log for a specific task of the target device, which is the target device for defect detection, and the defect detection result and actual defect result predicted based on the performance log and execution log. A storage device that stores the learned deep learning model and at least one information extracted from the performance log and the execution log is compared with a first constant value to detect a defect, or a second constant value is calculated on the value of the information and an arithmetic unit for detecting a software defect or a hardware defect for the specific task based on the value. The computing device inputs a result of detecting a defect for the specific task into the deep learning model, and adjusts the first constant value or the second constant value based on a value output by the deep learning model.

The technology to be described below enables more accurate defect detection by dynamically adjusting the reference value required for defect detection according to system conditions or defect types.

1 is an example of a system for detecting hardware and software faults.
2 is an example of the operation of the defect detection module.
3 is an example of the operation of the defect classification module.
4 is an example of an operation of an analysis device for detecting hardware and software defects.
5 is an example of a learning process of a learning model.
6 is an example of the configuration of an analysis device for detecting hardware and software defects.

Since the technology to be described below can have various changes and can have various embodiments, specific embodiments are illustrated in the drawings and described in detail. However, this is not intended to limit the technology described below to specific embodiments, and it should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the technology described below.

Terms such as first, second, A, and B may be used to describe various components, but the components are not limited by the above terms, and only for the purpose of distinguishing one component from other components. used only as For example, a first component may be named as a second component, and similarly, the second component may also be referred to as a first component without departing from the scope of the technology to be described below. and/or includes a combination of a plurality of related listed items or any of a plurality of related listed items.

In terms of terms used herein, the singular expression should be understood to include the plural expression unless the context clearly dictates otherwise, and terms such as "comprises" include the described feature, number, step, operation, element. , parts or combinations thereof are to be understood, but not to exclude the possibility of the presence or addition of one or more other features or numbers, step operation components, parts or combinations thereof.

Prior to a detailed description of the drawings, it is intended to clarify that the classification of the constituent parts in the present specification is merely a division according to the main function that each constituent unit is responsible for. That is, two or more components to be described below may be combined into one component, or one component may be divided into two or more for each more subdivided function. In addition, each of the constituent units to be described below may additionally perform some or all of the functions of other constituent units in addition to the main function it is responsible for. Of course, it can also be performed by being dedicated to it.

In addition, in performing the method or operation method, each process constituting the method may occur differently from the specified order unless a specific order is clearly described in context. That is, each process may occur in the same order as specified, may be performed substantially simultaneously, or may be performed in the reverse order.

The technique to be described below is a technique for detecting whether there is a defect in the operation of hardware (HW) and/or software (SW) by analyzing the operation of a specific device composed of software and hardware. A device that is a target for defect detection (analysis target) is called a target device. For example, the target device may be a server, PC, smart device, IoT device, access point, RSU, vehicle, or the like. The target device may be any one of a variety of types of devices typically connected to a network. Alternatively, the target device may be a device connected to a closed system.

A device that detects a defect in a target device is called an analysis device. The analysis device may detect whether a specific target device is defective and/or a defect termination in real time based on the given input data. The analysis device may be implemented in various forms as a device for detecting defects by analyzing input data. For example, the analysis device may be a server, a PC, a smart device, a chipset built into a specific device, a router, or the like.

The analysis device utilizes a pre-built machine learning model to detect and/or classify a defect. Machine learning is a field of artificial intelligence and refers to the field of developing algorithms so that computers can learn. The learning model includes a decision tree, a random forest, a K-nearest neighbor (KNN), a naive Bayes, a support vector machine (SVM), an artificial neural network, and the like.

Artificial neural networks are statistical learning algorithms that mimic the neural networks of living things. Various neural network models are being studied. Recently, deep learning networks (DNNs) are attracting attention. DNN is an artificial neural network model consisting of several hidden layers between an input layer and an output layer. DNN can model complex non-linear relationships like general artificial neural networks. Various types of DNN models have been studied. For example, there are Convolutional Neural Network (CNN), Recurrent Neural Network (RNN), Restricted Boltzmann Machine (RBM), Deep Belief Network (DBN), Generative Adversarial Network (GAN), Relation Networks (RL), and the like.

1 is an example of a system 100 for detecting hardware and software faults. In FIG. 1 , the analysis devices 130 and 150 detect a damaged earthquake. In FIG. 1 , the analysis device is shown in the form of a server 130 and a computer terminal 150 . Meanwhile, the analysis devices 130 and 150 may be implemented in various forms.

The target device 110 generates a performance log and an execution log related to the operation during operation.

The analysis devices 130 and 150 obtain a performance log and an execution log of the target device 110 . The analysis devices 130 and 150 may be connected to the target device 100 by wire or wirelessly to receive a performance log and an execution log. Alternatively, the analysis devices 130 and 150 may be specific devices or components implemented in the target device 100 .

The analyzers 130 and 150 may analyze a performance log and an execution log of the target device 110 to detect a defect of the target device 110 in real time.

The server 130 receives the performance log and the execution log of the target device 110 . The server 130 analyzes the received performance log and execution log to detect whether the HW/SW defect and/or the defect type of the target device 110 is present. The server 130 may adjust a reference value (a constant value) for determining whether a defect exists or whether a defect is terminated according to a defect detection result using a previously built learning model. In this case, the server 130 determines whether the current target device 110 is defective or the type of defect based on the adjusted reference value. The server 130 may notify the HW/SW defect of the target device 110 to the individual target devices 11 and 12 or a separate control center through the mobile communication system and the access point 140 .

The computer terminal 150 receives the performance log and the execution log of the target device 110 . The computer terminal 150 analyzes the input performance log and the execution log to detect whether the HW/SW defect and/or the defect type of the target device 110 is present. The computer terminal 150 may adjust a reference value (a constant value) for determining whether a defect exists or whether a defect is terminated according to a defect detection result using a previously built learning model. In this case, the computer terminal 150 determines whether the current target device 110 is defective or the type of defect based on the adjusted reference value. The computer terminal 150 may output the HW/SW defect of the target device 110 and provide it to the user 20 .

The analysis device detects SW/HW defects of the target device based on the performance log and execution log of the target device. Meanwhile, the performance log and the execution log may each consist of values of various items.

The analysis device may extract necessary performance logs and execution logs from data acquired from the target device and use them for analysis. Alternatively, the target device may provide only the performance log and execution log necessary for analysis to the analysis device.

The target device or analysis device collects performance logs and execution logs from a target (target device) to perform fault detection. In particular, if the performance log and the execution log are collected in real time from the target device, the performance of the target device may be deteriorated due to the collection operation. Therefore, in order to minimize the degradation of the performance of the target device, it is necessary to minimize the location or item of the monitoring target.

(1) Monitoring location

The target device or analysis device may analyze memory/parallel faults and HW/SW faults to monitor only the locations that are essential to be monitored. For example, the monitoring location is a system call/interrupt handler of an operating system (OS) that is a function of a library related to a memory fault, a function of a library related to a concurrency fault, and a call boundary of HW/SW. can

(2) Monitoring data

Furthermore, in order to reduce the overhead of the defect detection process, the log collected by the target device or the analysis device at the real-time monitoring location may also collect only data essential for defect detection and classification. For example, the monitoring data may be as shown in Table 1 below.

Device classification log division Collected data HW performance log device performance counter HW performance log Network performance counters (both Tx/Rx) SW run log Parameters passed by Caller when calling a function Return value of Callee when calling a function The time the function call occurred HW/SW run log Interrupt status

The analysis device first detects a defect using the defect detection module based on the performance log and execution log of the target device. When it is not clearly classified as a SW defect or a HW defect as a result of the primary detection, the analysis device detects the defect secondarily using the defect classification module based on the performance log and the execution log of the target device 110 . Hereinafter, the operation of the defect detection module and the defect classification module will be described.

2 is an example of the operation 200 of the defect detection module. The analyzer analyzes the execution log and the performance log of the target device using the defect detection module to detect whether a defect has occurred. The defect detection module is a functional configuration (software configuration) that operates inside the analysis device.

The defect detection module receives the execution log and the performance log of the target device ( 210 ).

The fault detection module is divided into SW fault detection and HW fault detection. The fault detection module may separately perform SW fault detection and HW fault detection.

(1) SW fault detection: The fault detection module detects whether a memory fault or a concurrency fault has occurred by analyzing the execution log of the memory-related function and the concurrency-related function. When the execution result of the system call execution log is not a normal value or an interrupt generation log exists, the fault detection module determines it as a candidate for other faults. If it is classified as other defect in SW defect detection, the defect detection module determines the corresponding defect as the final other defect according to the HW defect detection result.

(2) HW fault detection: The fault detection module detects faults by analyzing the execution log and performance log of the system call. The fault detection module detects network faults and device faults according to the type and execution result of the system call. The fault detection module determines other faults as candidates when the performance change in the performance log is out of a certain range.

The fault detection module finally judges the execution log as other fault only when (i) the execution log before/after the performance change determined as other fault in HW fault detection is (ii) the execution log judged as other fault in SW fault detection. . Other defects are cases where it is not clear whether SW defects and HW defects are not clearly distinguished. Other faults are transmitted to the fault identification module, so that the fault identification module detects the fault.

3 is an example of the operation 300 of the defect classification module. The defect classification module is for classifying defects in the case where it is finally determined as other defects in the above-described defect detection module. The analysis device classifies (classifies) defects by analyzing the execution log and performance log of the target device using the defect classification module.

The fault identification module analyzes the execution log and checks whether the task (process) is normally terminated (310).

If it is normally terminated (Yes of 310), the fault classification module classifies the fault using the execution log for the system call accessing the HW.

The defect classification module classifies software defects by using the execution result of the execution log and the system call parameters.

If an incorrect value is entered in the parameter before the system call is called (Error of 320), the fault classification module determines that the wrong value was passed to the parameter in the software before the system call is called and classifies it as a software defect (C). Determining whether a parameter is an invalid parameter depends on the system call.

Even if the parameter is a normal value (Normal in 320), the return value is an error value, and if the error type is a software defect type (Error in 330), the fault classification module classifies it as a software defect.

When the fault classification module is not classified as a software fault in the execution log for the system call (Normal of 330), the fault is classified using the performance log as well as the execution log. The fault classification module classifies faults according to the following five criteria based on the HW performance counter of the performance log and the value read from the memory.

(1) Whether CPU switching occurs while performance is kept constant

The fault classification module determines whether performance is maintained by changing the trend of CPU cycles among HW performance counters in the performance log, and determines whether CPU switching occurs using CPU ID. The fault classification module determines that the performance is kept constant when the CPU cycle is within the range of Equation 1 below.

Here, CPU _aver is the average value of CPU cycles up to immediately before the current CPU cycle, CPU _counter is a CPU cycle counter value, and α is a constant that varies depending on the CPU/process type. α is a constant that varies depending on the type of CPU/process, and the initial setting value may be experimentally set to a value having the lowest false positive rate. This value may be a constant value that is adjusted using a learning model, which will be described later.

If the fault classification module determines that CPU switching has occurred (Yes of 340), the fault is classified as a HW (CPU) fault (A). In general application execution, only the low-power CPU is operated to minimize power consumption, and CPU switching occurs for the high-performance CPU to operate only when the low-power CPU has insufficient power to process. However, if performance is kept constant and CPU switching occurs when a process that repeatedly performs the same task is executed, the fault classification module can determine that an intermittent fault has occurred in the CPU, such as a temporary voltage change.

On the other hand, CPU switching occurs in multi-core CPUs. In the case of a single-core CPU, the fault classification module does not determine whether the CPU is switched or not, but uses other criteria to classify the fault. That is, the fault classification module considers that there is no CPU switching at the CPU switching determination point and classifies the fault.

(2) CPU performance degradation

An increase in CPU cycles indicates that the time taken to process the operation has increased. In other words, the increase in CPU cycles can be said to decrease the performance of the CPU. The defect classification module may determine whether the performance of the CPU is degraded based on Equation (1).

CPU performance degradation may occur for various reasons, such as interrupts during task processing in the CPU and delays in data load/store operations. Therefore, it is difficult to determine a CPU defect only by the performance degradation of the CPU. Accordingly, it is possible to determine whether the CPU is defective by additionally determining the criteria to be described below. Although the CPU performance degradation occurs in the fault classification module, if it is not a CPU fault (A), it is determined as a fault (B) of other hardware such as memory (No of 350).

(3) Whether Retry/stall occurs

If the fault classification module fails to perform operations normally in the CPU or it takes a long time to load/save data, retry/delay may occur. The fault classification module may determine whether retry/delay occurs by using the L1 cache miss ratio, the BPU miss ratio, and the stall counter. When the L1 cache miss rate, the BPU miss rate, and the delay counter are out of the range of the average values, the fault classification module may determine that retry/delay has occurred.

The fault classification module determines that the CPU performance is degraded (Yes of 350), but if retries/delays do not occur, hardware other than the CPU is defective (No of 360).

If retry/delay occurs, the fault classification module identifies the fault by further checking additional information.

(4) Whether an error occurred

The fault classification module checks whether an error has occurred in data exchanged between the CPU, memory, and external devices ( 370 ). The fault classification module may determine whether there is an error based on the error type returned from the system call and the value of the error counter. The fault classification module determines that an error has occurred if the error type < 0 or if the error counter ≠ 0.

If an error does not occur even though CPU performance degradation + retry/delay occurs, the fault classification module determines that it is a CPU defect, not a data problem, but an internal CPU problem (No of 370).

(5) Check the internal memory value

If it is confirmed that an error has occurred (Yes of 370), the fault classification module determines whether an error has occurred inside the CPU based on the error counter and the value stored in the memory. Since the error counter is incremented when an error occurs in the data in the CPU internal cache, an increase in the error counter means that there is a defect in the CPU internal cache. If the fault classification module determines that a CPU internal error has occurred (Yes of 380), it is classified as a CPU fault.

If the value stored in the memory also contains an incorrect value (data) along with the increase of the error counter, the fault classification module determines that a fault has occurred in other hardware such as memory, not inside the CPU (No of 380).

If it is not normally terminated (No in 310), the fault classification module classifies the fault by using the execution log for the system call accessing the HW. If an incorrect value is entered in the parameter before the system call is called (Error of 390), the fault classification module judges that the wrong value was passed to the parameter by the software before the system call was called and classifies it as a software defect (C). Determining whether a parameter is an invalid parameter depends on the system call.

Even if the parameter is a normal value (Normal of 390), the fault classification module analyzes the execution log and checks whether a CPU interrupt has occurred (395). If the CPU interrupt does not occur (No in 395), the fault classification module classifies it as a software fault.

The fault classification module classifies a hardware fault (CPU or other device) when a CPU interrupt occurs (Yes of 395).

4 is an example of the operation of the analysis device 400 for detecting hardware and software defects. 4 is an example explaining the operation with a focus on the functional configuration (software module) of the analysis device. Each configuration will be described.

The defect detection module 410 receives the execution log and performance log of the target device and starts defect detection. The operation of the defect detection module 410 is the same as described with reference to FIG. 2 . The defect detection module 410 detects a SW defect and/or a HW defect of the target device based on the execution log and performance log of the target device. When the defect detection module 410 cannot be clearly determined as a SW defect or a HW defect, it classifies it as another defect, and transmits information (performance log and execution log) related to the defect to the defect classification module 420 .

The defect classification module 420 classifies the defect by receiving the execution log and the performance log of the target device. The defect classification module 420 classifies defects into CPU defects (HW), non-CPU HW defects, and SW defects. The operation of the defect classification module 420 is the same as described with reference to FIG. 3 .

When the defect detection module 410 or the defect classification module 420 classifies the HW defect as a HW defect, the HW defect debugging module 431 extracts debugging information that can help debug the HW defect. The HW fault debugging module 431 records the execution log and performance log used to determine the fault, the HW device in which the fault occurred, the parameters used for the system call call, the interrupt occurrence status, and the execution call stack until the fault occurs as debugging information. extract The HW fault debugging module 431 may transmit the extracted debugging information to the analysis result output module 440 .

When the fault detection module 410 or the fault classification module 420 classifies the SW fault as a SW fault, the SW fault debugging module 432 extracts debugging information that can help debug the SW fault. The SW fault debugging module 432 extracts an execution log and performance log used for fault determination, a fault type, a parameter used when calling a function related to a fault, and a call stack until the corresponding function is executed as debugging information. The SW fault debugging module 432 may transmit the extracted debugging information to the analysis result output module 440 .

The analysis result output module 440 provides debugging information received from the HW fault debugging module 431 and the SW fault debugging module 432 when a fault detected by the fault detection module 410 or the fault classification module 420 exists. and the type of defect.

The aforementioned defect detection module 410 or defect classification module 420 analyzes an execution log and a performance log in the process of determining a SW defect or a HW defect. The defect detection module 410 or the defect classification module 420 analyzes the defect based on whether or not the performance counter value of the performance log falls within a normal range. That is, the defect detection module 410 or the defect classification module 420 performs defect detection or defect classification by comparing a specific reference value or reference range with information extracted from a current log value. A reference value or reference range is defined as a specific constant value or constant values.

The learning module 450 is a configuration for adjusting a reference value or a constant value defining a reference range. The learning module 450 includes a defect detection learning module that adjusts a constant value used in the defect detection module 410 and a defect classification learning module that adjusts a constant value used in the defect classification module 420 .

The learning module 450 transmits the defect analysis result of the defect detection module 410 or the defect classification module 420 from any one of the defect detection module 410 , the defect classification module 420 , and the analysis result output module 440 . receive The learning module 450 receives a feedback of the defect detection result, and adjusts a constant value used for defect detection or defect classification according to the defect detection result.

The content to be learned in the learning module is divided into two main categories. The first is the content of a bug report reported as a defect for the existing defect detection target, and the second is feedback on the defect detection and classification results.

First, the relationship between a specific keyword and a specific defect is learned using the conventional defect information of the learning module. The learning model may use supervised learning using a decision tree. The training data has keywords extracted from bug reports and defect determination results as data sets. Keywords can be extracted from the contents of the bug report that has already been determined whether or not it is a defect among the contents registered in a bug tracking system such as Bugzilla.

Second, what the learning module learns is feedback on a result detected by the aforementioned defect detection module and/or the defect classification module.

5 is an example of a learning process 500 of a learning model. In this process, after the learning module collects real-time execution logs and performance logs, it goes through a series of processes to detect and classify defects and learn whether the results match the actual results. The learning module adjusts the constant value used in each step of the defect detection module and the defect classification module according to the learning result. Here, the learning model may use a deep learning model.

The learning module may be divided into a defect detection learning module and a defect classification learning module. Each of the defect detection learning module and the defect classification learning module should be individually learned.

As the training data, the results of HW/SW defect detection and actual defect analysis are used. The HW/SW defect detection result may be a prediction result output by the above-described defect detection module and/or the defect classification module. The result of analyzing the actual defect is the result of analyzing the actual defect for the same task predicted by the defect detection module and/or the defect classification module.

The learning module receives the HW/SW defect detection result 511 and the actual defect analysis result 512 as inputs. The learning module repeats the process of extracting the defect type and defect detection from each defect detection result, respectively, and sampling the result. By repeating this process, the learning module can check the accuracy or false positive rate of a specific HW/SW defect detection result. Here, the accuracy or false positive rate corresponds to a feature extracted from the HW/SW defect detection prediction result in the learning module.

The learning module is trained to output information (eg, adjustment ratio) for adjusting a constant value used for HW/SW defect detection prediction based on the accuracy or false positive rate for a specific HW/SW defect detection prediction result ( 520 ).

For example, in the case of HW defects among other defects, it is assumed that the constant value adjustment ratio is set to 20, 15, 10, and 5, respectively, by classifying them based on the defect detection accuracy of less than 70%, 70-80&, 80-90%, and 90% or more. do.

In the learning process, if the defect detection accuracy of HW defects among other defects is 77.8%, and the constant value used for defect detection is currently 10%, the learning module classifies the defect detection accuracy into 70-80% and the constant value is 15% can be adjusted. Since the constant value used at this time is the allowable range of the performance value detected as a defect, it can be changed from the existing 10% to 11.5%, which is increased by 15%. Here, the constant value may be the same as α in Equation (1).

In the case of the false positive rate, it works similarly to the above. In the learning process, the false positive rate is classified based on 20% or more, 10~20%, 5~10%, or less than 5%, and the constant value adjustment ratio is set to 20, 15, 10, If it is 5, the learning module can adjust the constant value to decrease.

The learning module outputs an adjustment value (eg, adjustment ratio) for a constant used for defect detection or defect classification ( 530 ). Thereafter, the adjusted constant value may be applied to the defect detection module or the defect classification module, and the defect detection module or the defect classification module may perform defect detection based on the adjusted constant value ( 540 ). The HW/SW defect detection result detected by the defect detection module or the defect classification module can be used repeatedly in the learning process. In the end, the learning module is based on the predicted HW/SW defect detection result (result value, result type).

6 is an example of the configuration of the analysis device 600 for detecting hardware and software defects. The analysis device 600 is a device corresponding to the analysis device 130 or 150 of FIG. 1 .

The analysis device 600 detects a defect for a specific task of the target device by adjusting a performance condition or constant value required for defect detection using the above-described deep learning model. The analysis device 600 may be physically implemented in various forms. For example, the analysis device 600 may have the form of a PC, a smart device, a server on a network, a chipset dedicated to data processing, and the like.

The analysis device 600 may include a storage device 610 , a memory 620 , an arithmetic device 630 , an interface device 640 , a communication device 650 , and an output device 660 .

The storage device 610 may store the learned deep learning model using the defect detection result predicted based on the performance log and the execution log and the actual defect result. The deep learning model may be learned through the process described in FIG. 5 .

The storage device 610 may store programs or source codes required for data processing.

The storage device 610 may store the above-described defect detection module, defect classification module, defect debugging module, analysis result output module, and learning module.

The storage device 610 may store input performance logs and execution logs.

The storage device 610 may store a defect analysis result of the target device or a defect analysis result for a specific task of the target device.

The memory 620 may store data and information generated while the analysis device 600 detects a HW/SW defect.

The interface device 640 is a device that receives predetermined commands and data from the outside. The interface device 640 may receive the performance log and execution log of the target device from a physically connected input device or an external storage device.

The interface device 640 may receive a learning model for data analysis. The interface device 640 may receive learning data, information, and parameter values for training a learning model.

The communication device 650 refers to a configuration for receiving and transmitting certain information through a wired or wireless network. The communication device 650 may receive a performance log and an execution log of the target device from an external object. The communication device 650 may also receive data for model learning.

The communication device 650 may transmit a defect detection result for the target device analyzed based on the performance log and the execution log to an external object.

The communication device 650 or the interface device 640 are devices that receive predetermined data or commands from the outside. The communication device 650 or the interface device 640 may be referred to as input devices.

The output device 660 is a device that outputs certain information. The output device 660 may output an interface necessary for a data processing process, an analysis result, and the like. The output device 660 may output a defect detection result. The output device 660 may output debugging information.

The arithmetic unit 630 may detect a defect based on at least one piece of information extracted from the performance load and execution log. The calculation unit 630 may classify the defect into a SW defect, a HW defect, or other defects as described with reference to FIG. 2 using the defect detection module.

The arithmetic unit 630 may specifically classify other defects as CPU defects, HW combinations other than CPU defects, or SW combinations as described with reference to FIG. 3 by using the defect classification module.

The arithmetic unit 630 may detect a defect by comparing at least one piece of information extracted from the performance load and execution log with a specific constant value.

Alternatively, the computing device 630 may detect a software defect or a hardware defect for a specific task based on a value obtained by calculating a specific constant value on the value of at least one information extracted from the performance load and execution log.

The computing device 630 may output information (adjustment value or adjustment ratio) for adjusting a constant value used for defect detection by inputting a result of detecting a defect for a specific task into the deep learning model. The arithmetic unit 630 may detect a software defect or a hardware defect for a specific task based on the adjusted constant value.

For example, the arithmetic unit 630 extracts the CPU cycle average value and the CPU cycle counter from the performance log to the immediately preceding time point, and determines whether to maintain CPU performance based on the CPU cycle average value and the CPU cycle counter as in Equation 1, and CPU performance If this is maintained, it can be determined as a hardware defect other than the CPU (see FIG. 3 ). In this case, the arithmetic unit 630 may determine whether to maintain CPU performance based on whether the CPU cycle counter belongs to a specific category. The computing device 630 may determine whether a defect is detected by adjusting α of Equation 1 according to the adjustment value output by the deep learning model.

The arithmetic unit 630 may generate a defect type for a software defect or a hardware defect, parameters used in a function related to the defect, and a call stack until the function is executed as debugging information.

The computing device 630 may be a device such as a processor, an AP, or a chip embedded with a program that processes data and processes a predetermined operation.

In addition, the HW and/or SW defect detection method or defect classification method as described above may be implemented as a program (or application) including an executable algorithm that can be executed in a computer. The program may be provided by being stored in a temporary or non-transitory computer readable medium.

The non-transitory readable medium refers to a medium that stores data semi-permanently, rather than a medium that stores data for a short moment, such as a register, cache, memory, and the like, and can be read by a device. Specifically, the various applications or programs described above are CD, DVD, hard disk, Blu-ray disk, USB, memory card, ROM (read-only memory), PROM (programmable read only memory), EPROM (Erasable PROM, EPROM) Alternatively, it may be provided while being stored in a non-transitory readable medium such as an EEPROM (Electrically EPROM) or flash memory.

Temporarily readable media include Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (Enhanced) SDRAM, ESDRAM), Synchronous DRAM (Synclink DRAM, SLDRAM) and Direct Rambus RAM (Direct Rambus RAM, DRRAM) refers to a variety of RAM.

This embodiment and the drawings attached to this specification merely clearly show a part of the technical idea included in the above-described technology, and within the scope of the technical idea included in the specification and drawings of the above-described technology, those skilled in the art can easily It will be apparent that all inferred modified examples and specific embodiments are included in the scope of the above-described technology.

Claims (10)

acquiring, by the analysis device, a performance log and an execution log for a specific task of a target device that is a defect detection target; and
Detecting, by the analysis device, a software defect or a hardware defect for the specific task based on at least one of the performance log and the execution log,
The analysis device detects a defect by comparing at least one piece of information extracted from the performance log and the execution log with a first constant value, or detects a defect based on a value obtained by calculating a second constant value on the value of the information, ,
The first constant value or the second constant value is a value output from a deep learning model that is learned using a defect detection result predicted based on a performance log and an execution log of the device and an actual defect result using deep learning. How to detect hardware and software faults. According to claim 1,
The analysis device first detects a software defect or a hardware defect based on at least one of the performance log and the execution log,
When the first detection result is not classified as a software defect or a hardware defect, the analysis device uses the execution result extracted from the execution log, the system call parameter extracted from the execution log, and the hardware performance counter extracted from the performance log to determine the specific A hardware and software defect detection method using deep learning that classifies a task into any one of a CPU defect, a non-CPU hardware defect, or a software defect. According to claim 1,
The analysis device extracts the CPU cycle average value and CPU cycle counter from the performance log to the immediately preceding time point, determines whether CPU performance is maintained based on the CPU cycle average value and the CPU cycle counter, and if the CPU performance is maintained, hardware other than the CPU A hardware and software defect detection method using deep learning that judges defects as defects. 4. The method of claim 3,
The analysis device determines whether to maintain CPU performance based on whether the CPU cycle counter belongs to a specific category,
The specific category is determined based on the CPU cycle average value and the second constant value, and the second constant value is a hardware and software defect detection method using deep learning that is adjusted according to an adjustment value output by the deep learning model. According to claim 1,
Hardware using deep learning further comprising the step of generating, by the analysis apparatus, a defect type for the software defect or the hardware defect, a parameter used for a function related to the defect, and a call stack until the function is executed as debugging information and software flaw detection methods. an input device for receiving a performance log and an execution log for a specific task of a target device that is a defect detection target;
a storage device for storing a deep learning model trained using a defect detection result predicted based on a performance log and an execution log and an actual defect result; and
A defect is detected by comparing at least one piece of information extracted from the performance log and the execution log with a first constant value, or a software defect for the specific task based on a value obtained by calculating a second constant value on the value of the information; a computing unit that detects hardware faults;
The computing device inputs a result of detecting a defect for the specific task into the deep learning model, hardware for adjusting the first constant value or the second constant value based on a value output by the deep learning model; An analysis device that detects software defects. 7. The method of claim 6,
The computing device first detects a software defect or a hardware defect based on at least one of the performance log and the execution log,
When the first detection result is not classified as a software defect or a hardware defect, the computing unit uses the execution result extracted from the execution log, the system call parameter extracted from the execution log, and the hardware performance counter extracted from the performance log to determine the specific An analysis device that detects hardware and software faults that classify faults as either CPU faults, non-CPU hardware faults, or software faults for a task. 7. The method of claim 6,
The arithmetic unit extracts the CPU cycle average value and CPU cycle counter from the performance log to the immediately preceding time point, determines whether CPU performance is maintained based on the CPU cycle average value and the CPU cycle counter, and if the CPU performance is maintained, hardware other than the CPU An analysis device that detects hardware and software defects that are judged to be defects. 9. The method of claim 8,
The arithmetic unit determines whether to maintain CPU performance based on whether the CPU cycle counter belongs to a specific category,
The specific category is determined based on the CPU cycle average value and the second constant value, and the second constant value is an analysis device for detecting hardware and software defects that are adjusted according to the adjustment value output by the deep learning model. 7. The method of claim 6,
The arithmetic unit is an analysis device for detecting hardware and software defects that further generate the software defect or a defect type for the hardware defect, parameters used in a function related to the defect, and a call stack until the function is executed as debugging information .

Images