Camera failure determination method, device and computer readable storage medium

Abstract

The application discloses a camera fault determination method, device and computer readable storage medium. The camera fault determination method comprises the following steps: obtaining script data of a to-be-identified object; determining a fault identification threshold of the to-be-identified object according to a pre-trained fault model; and determining a fault determination result corresponding to the to-be-identified object according to the fault identification threshold and the script data. The to-be-identified object comprises a camera, a client and / or a video monitoring platform. The fault identification threshold of the to-be-identified object is determined through the pre-trained fault model, and the fault determination result of the to-be-identified object is determined based on the fault identification threshold and the script data. In this way, the offline troubleshooting efficiency of the camera and the accuracy of the fault determination are improved.

Description

Technical Field

[0001] This application relates to the field of security technology, and in particular to a method, apparatus and computer-readable storage medium for diagnosing camera faults. Background Technology

[0002] With the rapid development of video surveillance services, platforms are becoming increasingly large, with the number of cameras connected to these platforms gradually reaching hundreds of thousands and even millions. Current technologies for identifying offline camera faults rely on traditional maintenance methods. Upon receiving reports of offline camera faults from customers, log queries and packet captures are used to sequentially check components such as the platform, cameras, and network. Simultaneously, expert experience is used to pinpoint the cause of the failure. Therefore, this fault diagnosis method suffers from low efficiency. Summary of the Invention

[0003] This application provides a method, apparatus, and computer-readable storage medium for determining camera faults, aiming to solve the problem of low efficiency in offline fault diagnosis of existing cameras.

[0004] To achieve the above objectives, this application provides a method for determining camera faults, applied to a video surveillance platform, the method comprising:

[0005] Obtain the call detail record (CDR) data of the object to be identified;

[0006] The fault identification threshold of the object to be identified is determined based on a pre-trained fault model;

[0007] The fault determination result corresponding to the object to be identified is determined based on the fault identification threshold and the call detail record data. The object to be identified includes a camera, a client, and / or a video surveillance platform.

[0008] Optionally, the step of obtaining the call detail record (CDR) data of the object to be identified includes:

[0009] Obtain network traffic data of the object to be identified, and determine the signaling data and media data of the object to be identified based on the network traffic data;

[0010] The signaling data and the media data are marked using preset identification information;

[0011] The call detail record (CDR) data is obtained by extracting preset feature values ​​from the tagged signaling data and media data.

[0012] Optionally, before the step of obtaining the call detail record (CDR) data of the object to be identified, the following steps are included:

[0013] Obtain the tags corresponding to the fault cause indicators of the camera;

[0014] The call detail record (CDR) data is labeled with the tags to obtain target CDR data, and the fault model is obtained by training a preset neural network model based on the target CDR data.

[0015] Optionally, the step of annotating the call detail record (CDR) data according to the tags to obtain the target CDR data includes:

[0016] Retrieve the first call detail record (CDR) data within a preset time period;

[0017] Obtain the second call detail record (CDR) data corresponding to the time period during which the camera malfunctioned from the first CDR data;

[0018] The target call detail record (CDR) data is obtained by annotating the second CDR data with the aforementioned tags.

[0019] Optionally, after the step of training a preset neural network model based on the target call detail record (CDR) data to obtain the fault model, the method further includes:

[0020] Obtain preset call detail records (CDRs) and update the fault model based on the preset CDRs;

[0021] Alternatively, obtain the correction information of the fault model and correct the fault model according to the correction information.

[0022] Optionally, after the step of training a preset neural network model based on the target call detail record (CDR) data to obtain the fault model, the method further includes:

[0023] Obtain the target weight value for each of the aforementioned fault cause indicators;

[0024] The weight values ​​of each fault cause index in the fault model are adjusted according to the target weight values.

[0025] Optionally, after the step of determining the fault determination result corresponding to the object to be identified based on the fault identification threshold and the call detail record data, the method further includes:

[0026] When the fault determination result is a network fault, the fault determination result is sent to the network maintenance terminal;

[0027] When the fault determination result is a non-network fault, the object to be identified that has caused the fault is determined based on the fault determination result;

[0028] The fault determination result is sent to the object to be identified that has experienced a fault.

[0029] Furthermore, to achieve the above objectives, this application also provides a camera fault determination device, which includes an acquisition module, a first determination module, and a second determination module, wherein:

[0030] The acquisition module is used to acquire call detail records (CDRs) of the object to be identified.

[0031] The first determining module is used to determine the fault identification threshold of the object to be identified based on a pre-trained fault model;

[0032] The second determining module is used to determine the fault judgment result corresponding to the object to be identified based on the fault identification threshold and the call detail record data. The object to be identified includes a camera, a client and / or a video surveillance platform.

[0033] In addition, to achieve the above objectives, this application also provides a camera fault determination device, which includes a memory, a processor, and a camera fault determination program stored in the memory and running on the processor. When the processor executes the camera fault determination program, it implements the steps of the camera fault determination method described above.

[0034] In addition, to achieve the above objectives, this application also provides a computer-readable storage medium storing a camera fault determination program, which, when executed by a processor, implements the steps of the camera fault determination method described above.

[0035] This application proposes a method for fault determination of cameras. The method involves acquiring call detail records (CDRs) of the object to be identified; determining a fault identification threshold for the object based on a pre-trained fault model; and determining the corresponding fault determination result based on the fault identification threshold and the CDRs. The object to be identified includes cameras, clients, and / or video surveillance platforms. This application improves the efficiency and accuracy of offline fault diagnosis by determining the fault identification threshold of the object through a pre-trained fault model and then determining the fault determination result based on the fault identification threshold and CDRs. Attached Figure Description

[0036] Figure 1 This is a schematic diagram of the terminal structure of the hardware operating environment involved in the embodiments of this application;

[0037] Figure 2 This is a flowchart illustrating the first embodiment of the camera fault determination method of this application;

[0038] Figure 3This is a flowchart illustrating the steps prior to obtaining the call detail record (CDR) data of the object to be identified in the camera fault determination method of this application.

[0039] Figure 4 This is a schematic diagram of the operation process of the fault determination method for the camera in this application;

[0040] Figure 5 This is a schematic diagram of the fault determination device for the camera in this application.

[0041] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0042] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0043] The main solution of this application embodiment is: to obtain call detail records (CDRs) of the object to be identified; to determine the fault identification threshold of the object to be identified based on a pre-trained fault model; and to determine the fault judgment result corresponding to the object to be identified based on the fault identification threshold and the CDRs, wherein the object to be identified includes a camera, a client, and / or a video surveillance platform.

[0044] In existing technologies, camera offline fault identification is based on traditional operation and maintenance methods. After receiving reports of camera offline faults from customers, methods such as log querying and packet capture are used to check components such as the platform, camera, and network in turn. At the same time, the cause of the service failure is determined based on expert experience. Therefore, the above fault diagnosis method suffers from low efficiency.

[0045] This application obtains call detail records (CDRs) of the object to be identified; determines the fault identification threshold of the object based on a pre-trained fault model; and determines the corresponding fault judgment result based on the fault identification threshold and CDRs. The object to be identified includes cameras, clients, and / or video surveillance platforms. This application determines the fault identification threshold of the object through a pre-trained fault model, and then determines the fault judgment result based on the fault identification threshold and CDRs, thus improving the efficiency and accuracy of offline fault diagnosis for cameras.

[0046] like Figure 1 As shown, Figure 1 This is a schematic diagram of the terminal device structure of the hardware operating environment involved in the embodiments of this application.

[0047] like Figure 1As shown, the terminal device may include: a processor 1001, such as a CPU; a network interface 1004; a user interface 1003; a memory 1005; and a communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and an input unit such as a keyboard. Optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as a disk drive. Optionally, the memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0048] Those skilled in the art will understand that Figure 1 The terminal device structure shown does not constitute a limitation on the terminal device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0049] like Figure 1 As shown, the memory 1005, which is a computer-readable storage medium, may include a camera fault diagnosis program.

[0050] exist Figure 1 In the terminal device shown, network interface 1004 is mainly used for data communication with the backend server; user interface 1003 is mainly used for data communication with the client (user end); when the terminal is a video surveillance platform, processor 1001 can be used to call the camera fault determination program in memory 1005 and perform the following operations:

[0051] Obtain the call detail record (CDR) data of the object to be identified;

[0052] The fault identification threshold of the object to be identified is determined based on a pre-trained fault model;

[0053] The fault determination result corresponding to the object to be identified is determined based on the fault identification threshold and the call detail record data. The object to be identified includes a camera, a client, and / or a video surveillance platform.

[0054] refer to Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the camera fault determination method of this application.

[0055] This application provides a method for determining camera faults. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0056] The camera fault determination method in this embodiment is applied to a video surveillance platform and includes the following steps:

[0057] Step S10: Obtain the call detail record (CDR) data of the object to be identified;

[0058] It should be noted that the objects to be identified in this application include cameras, clients (including PCs, mobile terminals, VR gaming devices, etc.) and / or video surveillance platforms, wherein the video surveillance platform is connected to the cameras and clients respectively via the public network.

[0059] Probes are deployed at the entry and exit points of the video surveillance platform. These probes are used to collect network traffic data flowing into and out of the platform. This network traffic data includes parameters reported by clients, parameters reported by cameras, traffic data entering and leaving the platform, and platform alarm data.

[0060] The parameters reported by the client include: UPC usage, loading latency, and abnormal events such as video stuttering and video loss;

[0061] The parameters reported by the camera include: current temperature, video bitrate, and abnormal events such as video stuttering;

[0062] The traffic data entering the platform includes: uplink speed, uplink RTT, and uplink packet loss rate, etc.

[0063] Traffic data from the platform includes: downlink speed, downlink RTT, and downlink packet loss rate, etc.

[0064] Platform alarm data includes: device offline, IVS platform alarms, image anomalies, and image occlusion alarms.

[0065] Then, the video surveillance platform generates call detail records (CDRs) based on parameters reported by the client, parameters reported by the camera, traffic data entering and leaving the platform, and platform alarm data. These CDRs include service xDRs and abnormal event records, whereby service xDRs include transaction records and media plane records. In one embodiment, the video surveillance platform preprocesses the network traffic data collected by the probes. Since the network traffic data collected by the probes contains various network data, the video surveillance platform does not need to determine camera faults based on all the network traffic data collected by the probes. Therefore, the video surveillance platform needs to extract the required data from network traffic data, namely, the signaling data and media data of the objects to be identified. At the same time, in order to distinguish the signaling data and media data of cameras, clients, and the video surveillance platform, it is necessary to use preset identification information to mark the signaling data and media data. Then, based on the marked signaling data and media data, preset feature values ​​are extracted to obtain call detail records (CDRs). For example, the probe distinguishes the signaling packets and media packets corresponding to the objects to be identified by packet identification and coloring. Then, preset feature values ​​are periodically extracted from the colored data packets. The extracted preset feature values ​​are the CDRs. These preset feature values ​​include frame loss rate, packet loss rate, online / offline RTT, loading latency, CPU utilization, memory utilization, etc.

[0066] Furthermore, the video surveillance platform processes the network traffic data collected by the probes to obtain the call detail records (CDRs) shown in Table 1.

[0067] Table 1

[0068] Serial Number Table name use 1 DETAIL_UFDR_RTSP RTSP Transaction Documents 2 XDR_RTSP_MEDIA RTSP Media Form (Recurring) 3 TDR_RTSP_EVENT RTSP Exception Event Documents 4 DETAIL_UFDR_SIP SIP Transaction Documents 5 XDR_SIP_MEDIA SIP Media Form (Recurring) 6 TDR_SIP_EVENT SIP Abnormal Event Form

[0069] Among them, RTSP (Real Time Streaming Protocol), listed in Table 1, is an application layer protocol jointly proposed by RealNetwork and Netscape. RTSP provides a mechanism that allows audio, video, and other data to be transmitted in real time as needed, and enables controls such as pause and fast forward. SIP (Session Initiation Protocol) is an application layer signaling control protocol used to create, modify, and release sessions of one or more participants.

[0070] Step S20: Determine the fault identification threshold of the object to be identified based on the pre-trained fault model;

[0071] The video surveillance platform stores a pre-trained fault model, which is trained using call detail record (CDR) data. Based on this fault model, fault identification thresholds for cameras, clients, and the video surveillance platform can be determined. These fault identification thresholds are the critical values ​​for judging whether a camera has malfunctioned. When the threshold is greater than or equal to the critical value, the camera can be judged to have malfunctioned.

[0072] Step S30: Determine the fault judgment result corresponding to the object to be identified based on the fault identification threshold and the call detail record data. The object to be identified includes a camera, a client and / or a video surveillance platform.

[0073] The video surveillance platform determines the fault judgment result corresponding to the object to be identified based on the fault identification threshold and call detail record (CDR) data. For example, the labeled CDR data is input into the fault model. After receiving the input CDR data, the fault model identifies the CDR data. If the CDR data includes temperature anomaly tags and packet loss rate anomaly tags, it then obtains the fault cause indicators corresponding to the temperature anomaly tags and packet loss rate anomaly tags respectively. Furthermore, it obtains the correspondence between pre-stored fault cause indicators and weight values, and then determines the weight values ​​corresponding to the temperature anomaly tags and packet loss rate anomaly tags respectively based on this correspondence. If the weight value of the temperature anomaly tag is 70% and the weight value of the packet loss rate anomaly tag is 30%, then the camera is determined to be faulty.

[0074] In one embodiment, when the fault determination result is a network fault, the fault determination result is sent to the network maintenance terminal; when the fault determination result is a non-network fault, the faulty object to be identified is determined based on the fault determination result, and the fault determination result is sent to the faulty object to be identified. Non-network faults are categorized into video surveillance platform faults, camera faults, and client faults. For example, if the fault determination result is a network problem, the fault determination result can be reported to the network maintenance center, and access network information, transmission network information, and data network information can be correlated for further location. If the fault determination result is a camera problem, the fault determination result can be reported to the camera maintenance department, and the camera manufacturer, camera model, access protocol information, etc., can be correlated for further location. If the fault determination result is a client or video surveillance platform problem, the fault determination result can be reported to the platform maintenance department for further location by relevant professionals.

[0075] This embodiment acquires call detail records (CDRs) of the object to be identified; determines the fault identification threshold of the object based on a pre-trained fault model; and determines the fault judgment result corresponding to the object based on the fault identification threshold and the CDRs. The object to be identified includes cameras, clients, and / or video surveillance platforms. This application determines the fault identification threshold of the object to be identified through a pre-trained fault model, and determines the fault judgment result of the object based on the fault identification threshold and CDRs, thereby improving the efficiency of offline fault diagnosis for cameras and the accuracy of fault judgment.

[0076] Further, refer to Figure 3 The second embodiment of the fault determination method for the camera in this application is proposed.

[0077] The difference between the second embodiment of the camera fault determination method and the first embodiment is that, before the step of obtaining the call detail record data of the object to be identified, the following steps are included:

[0078] Step S11: Obtain the tag corresponding to the fault cause index of the camera;

[0079] Step S12: Label the call detail record (CDR) data according to the tags to obtain target CDR data, and train a preset neural network model according to the target CDR data to obtain the fault model.

[0080] It should be noted that traditional methods for identifying offline camera faults primarily rely on expert experience analyzing large amounts of log and packet capture data to pinpoint the cause of failure. However, experts need extensive familiarity with the current network environment, network architecture, platform logic, access protocols, and camera characteristics to possess the necessary skills for problem localization. This places very high demands on the professional competence of maintenance personnel. Secondly, the diverse and scattered nature of the various data sources can interfere with offline camera fault identification and lead to misjudgments, thus reducing the efficiency and accuracy of fault identification. To address these issues, this application trains a fault model for cameras based on call detail record (CDR) data, and then uses this model to identify offline camera faults.

[0081] In this embodiment, the video surveillance platform stores a pre-built set of fault cause indicators for cameras. This set includes a video quality indicator set, an interactive experience indicator set, and a viewing experience indicator set, wherein:

[0082] The video quality metric set includes video clarity, video smoothness, and video fidelity, among which the corresponding camera metrics include camera status metrics (including current temperature, CPU usage, memory usage, etc.), camera abnormal events (including excessive average CPU usage, excessive average temperature, and encoding abnormalities, etc.), and camera shooting quality abnormalities (including image blur, image abnormalities, signal loss, light abnormalities, and image occlusion, etc.).

[0083] The interactive experience metric set includes live video loading time, replay video loading time, fast forward buffering time, and rewind buffering time. The corresponding network pipeline metrics under this interactive experience metric set include TCP maximum uplink rate, TCP maximum downlink rate, TCP uplink rate, TCP uplink latency, TCP uplink packet loss rate, TCP uplink average jitter, TCP uplink retransmission rate, TCP downlink rate, TCP downlink latency, TCP downlink packet loss rate, TCP downlink average jitter, TCP downlink retransmission rate, total number of abnormal events, number of interruption abnormal events, number of link interruption events, number of events with excessive packet loss rate, number of events with excessive RTT, number of rate abnormal events, number of quality abnormal events, etc.

[0084] The viewing experience metrics set includes issues such as screen tearing, stuttering, and black screen. The corresponding client status metrics under this viewing experience metrics set include CPU usage and memory usage.

[0085] The process involves obtaining labels corresponding to the camera's fault cause indicators, labeling call detail records (CDRs) with these labels to obtain target CDRs, and then training a pre-defined neural network model using these target CDRs to generate a fault model. This pre-defined neural network model can include Convolutional Neural Networks (CNNs), Recurrent Neural Networks (RNNs), and Long Short-Term Memory (LSTM) models, among others. Specifically, the process involves obtaining first CDRs within a pre-defined timeframe, extracting second CDRs from the timeframes corresponding to the camera's malfunction within these first CDRs, and labeling the second CDRs with the labels to obtain the target CDRs. For example, CDRs obtained within a fixed timeframe can be selected, and CDRs corresponding to the camera's offline time points can be extracted from these CDRs. Pre-constructed fault cause indicators and their corresponding labels can then be obtained and labeled using these labels. Next, a random forest algorithm, a classifier, and a ranking algorithm are used to randomly select 2 / 3 of the offline time points and the labeled CDRs from the same timeframes as training samples to train the neural network model. The remaining 1 / 3 of the CDRs are used as a test set to evaluate the model and improve the accuracy of the fault model's fault determination results.

[0086] To improve the accuracy of fault determination results from the fault model, it is necessary to update and modify the fault model. In one embodiment, preset call detail record (CDR) data is acquired, and the fault model is updated based on the preset CDR data. For example, existing network fault phenomena and CDR data are continuously collected, and the fault model is updated based on the collected existing network fault phenomena and CDR data. Alternatively, correction information for the fault model is acquired, and the fault model is corrected based on the correction information. For example, correction information proposed by experts is acquired, and the fault model is corrected based on the correction information.

[0087] Because adjustments are made during model training in the laboratory, these adjustments are for training the fault model. When the trained fault model is applied to the live network, it is also adjusted according to the actual situation of the live network. This adjustment is to make the fault model more suitable for the live network conditions, thereby improving the accuracy of fault determination. In one embodiment, the target weight value of each fault cause indicator is obtained, and then the weight value of each fault cause indicator in the fault model is adjusted according to the target weight value. For example, suppose the call detail record (CDR) data is labeled with tags A and B, and tags A and B correspond to different fault cause indicators. In the laboratory, suppose the weight value / threshold value of the fault cause indicator corresponding to tag A is 70%, and the weight value / threshold value of the fault cause indicator corresponding to tag B is 30%. In this case, the camera is determined to be faulty. However, in the live network, due to the influence of other factors, the client is determined to be faulty. Therefore, the weight value / threshold value of the original fault indicator needs to be adjusted, such as adjusting the weight value / threshold value of the fault cause indicator corresponding to tag A to 20%, and adjusting the weight value / threshold value of the fault cause indicator corresponding to tag B to 80%.

[0088] This embodiment trains a fault model for the camera using call detail record (CDR) data, and then performs offline fault delimitation based on the fault model. This avoids manual fault diagnosis of the camera and improves the efficiency and accuracy of fault diagnosis.

[0089] To better illustrate the fault diagnosis method for the camera in this application, refer to... Figure 4 , Figure 4 This is a schematic diagram illustrating the operation flow of the fault determination method for the camera in this application.

[0090] In this embodiment, the video surveillance platform acquires network traffic data from cameras, clients, and the video surveillance platform itself through deployed probes. Then, call detail records (CDRs) are extracted from the collected network traffic data. Simultaneously, the CDRs are expert-annotated using tags corresponding to the camera's fault cause indicators. Further, two-thirds of the CDRs are extracted as training samples, and the remaining one-third is used as a test set to evaluate the model and improve the accuracy of the fault model's fault determination results. A fault tree model (i.e., the fault model itself) is obtained by training the CDRs using random forest algorithms, classifiers, and ranking algorithms. The fault determination results output by the fault tree model are obtained. These results include network link faults and non-network link faults, where non-network link faults include video surveillance platform faults, camera faults, and client faults.

[0091] This embodiment combines AI algorithms with expert experience, constructing a fault tree model to establish a rule base for delimiting various fault causes, quickly locating the root cause of fault problems. Furthermore, it is not limited by the model or manufacturer of the front-end equipment; all can be used for fault delimitation using this method, demonstrating good compatibility and scalability. Compared to traditional camera fault diagnosis solutions, this embodiment achieves precise monitoring of data indicators for different video surveillance services. Simultaneously, the rapid matching based on AI algorithms and expert experience helps users efficiently and accurately locate the cause of camera offline problems, making it highly user-friendly even for those lacking professional background knowledge.

[0092] Furthermore, to achieve the above objectives, this application also provides a camera fault determination device. The camera fault determination device includes a memory, a processor, and a fault determination program stored in the memory and running on the processor. The device acquires call detail records (CDRs) of an object to be identified; determines a fault identification threshold for the object based on a pre-trained fault model; and determines a fault determination result corresponding to the object based on the fault identification threshold and the CDRs. The object to be identified includes a camera, a client, and / or a video surveillance platform. This device determines the fault identification threshold of the object through a pre-trained fault model, and determines the fault determination result based on the fault identification threshold and the CDRs, thereby improving the efficiency of offline camera fault diagnosis and the accuracy of fault determination.

[0093] Further, refer to Figure 5 , Figure 5 This is a schematic diagram of the fault determination device for the camera in this application.

[0094] The camera fault determination device 100 includes an acquisition module 10, a first determination module 20, and a second determination module 30, wherein:

[0095] The acquisition module 10 is used to acquire the call detail record (CDR) data of the object to be identified;

[0096] The first determining module 20 is used to determine the fault identification threshold of the object to be identified based on a pre-trained fault model;

[0097] The second determining module 30 is used to determine the fault judgment result corresponding to the object to be identified based on the fault identification threshold and the call detail record data. The object to be identified includes a camera, a client and / or a video surveillance platform.

[0098] Furthermore, the acquisition module 10 includes an acquisition unit, a marking unit, and an extraction unit;

[0099] The acquisition unit is used to acquire network traffic data of the object to be identified, and to determine the signaling data and media data of the object to be identified based on the network traffic data;

[0100] The marking unit is used to mark the signaling data and the media data using preset identification information;

[0101] The extraction unit is used to extract the call detail record (CDR) data by performing preset feature value extraction based on the tagged signaling data and media data.

[0102] Furthermore, the acquisition module 10 also includes a training unit;

[0103] The acquisition unit is also used to acquire the tag corresponding to the fault cause index of the camera;

[0104] The training unit is used to annotate the call detail record (CDR) data according to the tags to obtain target CDR data, and to train a preset neural network model according to the target CDR data to obtain the fault model.

[0105] Furthermore, the training unit includes an acquisition subunit and a labeling subunit;

[0106] The acquisition subunit is used to acquire the first call detail record data within a preset time period;

[0107] The acquisition subunit is also used to acquire the second call detail record (CDR) data corresponding to the time period during which the camera malfunctioned from the first CDR data;

[0108] The annotation subunit is used to annotate the second call detail record (CDR) data according to the tags to obtain the target CDR data.

[0109] Furthermore, the training unit also includes an update sub-unit and a correction sub-unit;

[0110] The update subunit is used to acquire preset call detail record (CDR) data and update the fault model based on the preset CDR data.

[0111] The correction subunit is used to acquire correction information of the fault model and correct the fault model according to the correction information.

[0112] Furthermore, the training unit also includes an adjustment subunit;

[0113] The acquisition subunit is also used to acquire the target weight value of each of the fault cause indicators;

[0114] The adjustment subunit is used to adjust the weight value of each fault cause index in the fault model according to the target weight value.

[0115] Furthermore, the second determining module 30 includes a sending unit and a second determining unit;

[0116] The sending unit is used to send the fault determination result to the network maintenance terminal when the fault determination result is a network fault.

[0117] The second determining unit is used to determine the object to be identified that has experienced a fault based on the fault determination result when the fault determination result is not a network fault.

[0118] The sending unit is further configured to send the fault determination result to the object to be identified that has experienced a fault.

[0119] The implementation of the functions of each module of the above-mentioned camera fault determination device is similar to the process in the above method embodiment, and will not be described in detail here.

[0120] In addition, this application also provides a computer-readable storage medium storing a camera fault determination method program, which, when executed by a processor, implements the steps of the camera fault determination method described above.

[0121] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0122] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable camera fault diagnosis device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable camera fault diagnosis device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0123] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable camera fault diagnosis device to operate in a specific manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0124] These computer program instructions can also be loaded onto a computer or other programmable camera fault diagnosis device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0125] It should be noted that any reference signs placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. This application can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0126] Although alternative embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make further changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the alternative embodiments as well as all changes and modifications falling within the scope of this application.

[0127] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for diagnosing camera malfunctions, characterized in that, Applied to a video surveillance platform, the method includes: Obtain the tags corresponding to the indicators of camera malfunction causes; The target call detail record (CDR) data is obtained by labeling the tagged CDR data, and a fault model is obtained by training a preset neural network model based on the target CDR data. Obtain the target weight value for each of the fault cause indicators, and adjust the weight value of each of the fault cause indicators in the fault model according to the target weight value; Obtain network traffic data of the object to be identified, and determine the signaling data and media data of the object to be identified based on the network traffic data; The signaling data and the media data are marked using preset identification information; Based on the marked signaling data and media data, preset feature values ​​are extracted to obtain the call detail record (CDR) data of the object to be identified. The fault identification threshold of the object to be identified is determined based on the pre-trained fault model; The fault determination result corresponding to the object to be identified is determined based on the fault identification threshold and the call detail record data of the object to be identified. When the fault determination result is a network fault, the fault determination result is sent to the network maintenance terminal; When the fault determination result is a non-network fault, the object to be identified that has caused the fault is determined based on the fault determination result; The fault determination result is sent to the object to be identified that has malfunctioned, including cameras, clients and / or video surveillance platforms.

2. The camera fault determination method as described in claim 1, characterized in that, The step of annotating the target call detail record (CDR) data based on the tagged CDR data includes: Retrieve the first call detail record (CDR) data within a preset time period; Obtain the second call detail record (CDR) data corresponding to the time period during which the camera malfunctioned from the first CDR data; The target call detail record (CDR) data is obtained by annotating the second CDR data with the aforementioned tags.

3. The fault determination method for a camera as described in claim 1, characterized in that, After the step of training a preset neural network model based on the target call detail record (CDR) data to obtain a fault model, the following steps are included: Obtain preset call detail records (CDRs) and update the fault model based on the preset CDRs; Alternatively, obtain the correction information of the fault model and correct the fault model according to the correction information.

4. A fault diagnosis device for a camera, characterized in that, The camera fault determination device includes an acquisition module, a first determination module, and a second determination module, wherein: The acquisition module is used to acquire the tags corresponding to the fault cause indicators of the camera, label the call detail records (CDRs) based on the tags to obtain target CDRs, train a preset neural network model based on the target CDRs to obtain a fault model, acquire the target weight value of each fault cause indicator, adjust the weight value of each fault cause indicator in the fault model based on the target weight value, acquire the network traffic data of the object to be identified, determine the signaling data and media data of the object to be identified based on the network traffic data, mark the signaling data and media data using preset identification information, and extract the CDRs of the object to be identified based on the marked signaling data and media data using preset feature values. The first determining module is used to determine the fault identification threshold of the object to be identified based on the pre-trained fault model; The second determining module is used to determine the fault determination result corresponding to the object to be identified based on the fault identification threshold and the call detail record data of the object to be identified. When the fault determination result is a network fault, the fault determination result is sent to the network maintenance terminal. When the fault determination result is not a network fault, the object to be identified that has malfunctioned is determined based on the fault determination result, and the fault determination result is sent to the object to be identified that has malfunctioned. The object to be identified includes a camera, a client and / or a video surveillance platform.

5. A fault determination device for a camera, characterized in that, The camera fault determination device includes a memory, a processor, and a camera fault determination program stored in the memory and running on the processor. When the processor executes the camera fault determination program, it implements the steps of the method as described in any one of claims 1 to 3.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a fault diagnosis program for the camera, which, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 3.

Images