Method and apparatus for handling internet-of-things card fault, storage medium, and computer program product

Abstract

The present disclosure provides a method and apparatus for handling an Internet-of-Things card fault. The method comprises: receiving Internet-of-Things card fault description information sent by a terminal; inputting the Internet-of-Things card fault description information into a first sub-model of a preset Internet-of-Things card large model for fault scenario analysis, so as to obtain a fault scenario corresponding to the fault description information; and obtaining a target fault diagnosis result on the basis of the fault scenario and a knowledge base. As can be seen, according to the present disclosure, faults can be accurately analyzed and diagnosed without the need for fault segmentation and correlation or probability analysis of possible causes of the faults, or the need for further analysis by relevant technical personnel with reference to results, thereby improving the efficiency of handling Internet-of-Things card faults, and saving manpower and material resources.

Description

An IoT card fault processing method and device, a storage medium and a computer program product

[0001] Cross-reference to Related Applications

[0002] The present disclosure is based on and claims priority to Chinese Patent Application No. 202410722752.2, filed on June 4, 2024, the entire contents of which are incorporated herein by reference. TECHNICAL FIELD

[0003] The present disclosure belongs to the technical field of Internet of Things, and in particular relates to an IoT card fault processing method and device. BACKGROUND

[0004] Generally, the IoT card, as a core component of the Internet of Things infrastructure, plays a role of connecting the network link between the IoT device and the business and platform. However, with the rapid development of Internet of Things technology, diversified IoT devices, complex network interface protocols and complex inter-system interactions make it necessary to coordinate multiple resources such as cross-field, cross-company, cross-department and cross-team to handle faults after the IoT card fails, and the positioning and processing of the fault are more complex and less efficient. SUMMARY

[0005] The present disclosure provides an IoT card fault processing method and device, which can accurately analyze and diagnose IoT card faults.

[0006] In a first aspect, the present disclosure provides an IoT card fault processing method applied to a server, the method comprising: receiving IoT card fault description information sent by a terminal; inputting the IoT card fault description information into a first sub-model of a preset IoT card large model for fault scene analysis to obtain a fault scene corresponding to the fault description information; and obtaining a target fault diagnosis result according to the fault scene and a knowledge base.

[0007] In a second aspect, the present disclosure provides an IoT card fault processing method applied to a terminal, the method comprising: receiving a first input of IoT card fault description information input by a user; in response to the first input, sending the IoT card fault description information to a server to make the server input the IoT card fault description information into a first sub-model of a preset IoT card large model for fault scene analysis to obtain a fault scene corresponding to the fault description information, and obtain a target fault diagnosis result according to the fault scene and a knowledge base; receiving the target fault diagnosis result returned by the server; and displaying the target fault diagnosis result.

[0008] In a third aspect, the present disclosure provides an IoT card fault processing device, the device comprising: a unified interaction module, a scene analysis module and a determination module.

[0009] The unified interaction module is configured to receive the Internet of Things card fault description information sent by the terminal.

[0010] The scene analysis module is configured to input the Internet of Things card fault description information into a first sub-model of a preset Internet of Things card large model to perform fault scene analysis, and obtain a fault scene corresponding to the fault information.

[0011] The determination module is configured to obtain a target fault diagnosis result according to the fault scene and a knowledge base.

[0012] Therefore, according to the technical solution provided by the present disclosure, the fault description information can be input into the preset Internet of Things card large model for analysis, the fault scene corresponding to the fault description information is determined according to the analysis result of the Internet of Things card large model, the fault is accurately analyzed and diagnosed, the fault segmentation definition and the correlation or probability analysis of the possible causes of the fault are not required, the link of the Internet of Things card is probed according to the probing scheme corresponding to the fault scene, and then the target fault diagnosis result is obtained according to the probing result by using the Internet of Things card large model, without the need for relevant technical personnel to further analyze the result, thereby improving the efficiency of the Internet of Things card fault processing and saving manpower and resources. BRIEF DESCRIPTION OF DRAWINGS

[0013] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings required to be used in the embodiments of the present disclosure will be briefly introduced below. Those skilled in the art can also obtain other drawings according to these drawings without creating any creative labor.

[0014] FIG. 1 is a flow diagram of an Internet of Things card fault processing method according to an embodiment of the present disclosure.

[0015] FIG. 2 is a scene diagram of a system applying the Internet of Things card fault processing method according to an embodiment of the present disclosure.

[0016] FIG. 2a is an interaction diagram of a unified interaction module in a scene according to an embodiment of the present disclosure.

[0017] FIG. 2b is an interaction diagram of a diagnosis analysis module in a scene according to an embodiment of the present disclosure.

[0018] FIG. 2c is an interaction diagram of a disposal plan module in a scene according to an embodiment of the present disclosure.

[0019] FIG. 2d is an interaction diagram of a repair guide module in a scene according to an embodiment of the present disclosure.

[0020] FIG. 2e is an interaction diagram of a recovery monitoring module in a scene according to an embodiment of the present disclosure.

[0021] Fig. 2f is a structural schematic diagram of the cooperative scheduling module in a scenario according to an embodiment of the present disclosure.

[0022] Fig. 3 is a flowchart of a method for handling a fault of the IoT card according to another embodiment of the present disclosure.

[0023] Fig. 4a shows a schematic diagram of a terminal according to an embodiment of the present disclosure.

[0024] Fig. 4b shows another schematic diagram of a terminal according to an embodiment of the present disclosure.

[0025] Fig. 5a shows a schematic diagram of a terminal according to another embodiment of the present disclosure.

[0026] Fig. 5b shows another schematic diagram of a terminal according to another embodiment of the present disclosure.

[0027] Fig. 6 shows a structural schematic diagram of a device for handling a fault of the IoT card according to an embodiment of the present disclosure.

[0028] Fig. 7 shows a hardware structural schematic diagram of a device for handling a fault of the IoT card according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0029] The features and exemplary embodiments of the various aspects of the present disclosure will be described in detail below with reference to the accompanying drawings and specific embodiments. To make the purpose, technical solutions and advantages of the present disclosure clearer, the present disclosure will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present disclosure, but not to limit the present disclosure. The present disclosure can be implemented without some of the specific details by those skilled in the art. The following description of the embodiments is only intended to provide a better understanding of the present disclosure by showing examples of the present disclosure.

[0030] It should be noted that, in this document, relational terms such as first and second, and the like, are used solely to distinguish one entity or action from another entity or action, without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element preceded by "comprises... " does not, without more constraints, foreclose the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0031] As the core component of the Internet of Things infrastructure, the Internet of Things card plays a network link role in connecting Internet of Things devices, businesses and platforms. However, with the rapid development of Internet of Things technology, diversified Internet of Things devices, complex network interface protocols and complex system interactions make it increasingly difficult to locate and handle Internet of Things card failures in actual application scenarios. In handling these failures, multi-faceted resources such as cross-domain, cross-company, cross-department and cross-team operations are often required, which not only increases the complexity of failure handling, but also reduces the efficiency of failure handling. Therefore, Internet of Things card fault location and handling is one of the key links that affects user experience in current business processes.

[0032] In related technologies, the fault of the Internet of Things card is located and handled by detecting network device indicators, detecting terminal indicators, detecting the relevance of network KPI indexes and abnormal services, detecting the business domain and O-domain data of specific business scenarios and preset rules. However, since the existing solutions are based on fault segmentation definition and the correlation or probability analysis of possible causes of the fault, they cannot accurately analyze and diagnose the fault cause, cannot provide disposal solutions and intervention measures needed to eliminate the fault and restore the service, and require related technical personnel to further analyze the results. Therefore, how to accurately analyze and diagnose the fault has become a technical problem that needs to be solved by technical personnel in the field.

[0033] The related technologies mainly include the following methods: analyzing network device indicators, analyzing terminal device indicators, analyzing the relevance of network KPI index changes and business abnormal reasons, and analyzing the business domain and O-domain data of specific business scenarios and preset rules.

[0034] However, in related technologies, the network device indicator analysis method has the following problems: on the one hand, the diagnosis dimension is the network device, lacking diagnosis capability in the Internet of Things card dimension, and the diagnosis granularity is coarse; on the other hand, the diagnosis time is long, and the network device needs to be continuously monitored for 7 days (or even a longer period) to determine the continuous deterioration of the device indicator in the absence of an alarm, and the diagnosis is not timely.

[0035] The terminal device indicator analysis method relies too much on the terminal reporting capability, which increases the burden of the terminal device on the one hand by requiring the terminal to encapsulate or process fault information, and on the other hand, it may not be able to obtain the reported data, as the network and terminal may have lost connection when the service fails, making it impossible to obtain effective data for diagnostic analysis.

[0036] The correlation analysis method is based on network device indicator analysis and adds possible fault causes, so it has the disadvantages of coarse diagnosis granularity and untimely diagnosis of network device indicator analysis, and the fault cause is mainly probabilistic correlation, not based on problem analysis, and cannot be accurately diagnosed.

[0037] The method of locating faults by cross-professional data correlation analysis belongs to possibility analysis rather than causal analysis, so the location of fault causes is not accurate. The method of perceiving service quality by segmented dialing also has the shortcomings of coarse diagnostic granularity of network device indicators and untimely diagnosis. The method of path restoration by deep packet inspection (DPI) has environmental differences due to different configurations and states of business domains and network domains of different Internet of Things cards, which affects the positioning accuracy. Finally, the industry rules (specific scenarios and business rules for fault location diagnosis) need to be pre-configured manually, which has a cold start problem and is highly dependent on user experience and expertise, affecting the effect of fault analysis.

[0038] More importantly, the related art cannot accurately analyze and diagnose fault causes, and more suspicious points are proposed for further analysis by business support personnel or device operation and maintenance personnel, which reduces the processing efficiency of Internet of Things card faults.

[0039] To solve the problems of the prior art, the embodiments of the present disclosure provide an Internet of Things card fault processing method and device. First, the Internet of Things card fault processing method provided by the embodiments of the present disclosure is introduced.

[0040] FIG. 1 shows a flowchart of the Internet of Things card fault processing method provided by an embodiment of the present disclosure. As shown in FIG. 1, the method is applied to a server and includes the following steps.

[0041] S101, receiving Internet of Things card fault description information sent by a terminal.

[0042] The terminal can be determined by a user according to actual conditions. The received Internet of Things card fault description information can include the application device name of the Internet of Things card, the specific performance of the fault (for example: unable to call, unable to connect to the network, etc.), the appearance of the application device, etc. The Internet of Things card fault processing flow is started after receiving the Internet of Things card fault description information.

[0043] S102, inputting the Internet of Things card fault description information into a first sub-model of a preset Internet of Things card large model to perform fault scene analysis, and obtaining a fault scene corresponding to the fault description information.

[0044] The user's fault scene is understood and analyzed by using the IoT card large model, and the keywords in the IoT card fault description information sent by the user through the terminal in step S101 are determined according to the keywords corresponding to the IoT card fault scene. The construction method of the first sub-model can include: processing fault data according to prompt words through prompt engineering (Tree of Thoughts, ToT); combining general large models and historical fault description data in the database to identify the intent of the fault description information, and then traversing the database to find information related to the fault description information, and finally using the general large model to verify and summarize the related information; further training according to the fault description information by adjusting the parameters of the open source general large model; using the standard Transformer multi-head attention mechanism to pay attention to different words respectively, and weighting the keywords in the fault description information to obtain the fault description information most related to the disposal result. The construction of the first sub-model can be constructed according to the needs of the above construction method.

[0045] Among them, the keywords can be weighted, for example: according to the device type provided by the user for the application of the IoT card, the model of the IoT card can be determined. The keywords about the device type can be given a high weight. The scene where the IoT card is located is determined so as to improve the accuracy of the IoT card fault analysis when the IoT card large model is input subsequently.

[0046] S103, obtaining a target fault diagnosis result according to the fault scene and the knowledge base.

[0047] In some embodiments of the present application, step S103 can include steps a-b. In step a, a dialing test scheme corresponding to the fault scene is obtained, and the link of the IoT card is dialing tested to obtain a dialing test result. In step b, the dialing test result is input into the second sub-model of the preset IoT card large model for fault diagnosis analysis to obtain a target fault diagnosis result.

[0048] In some embodiments of the present application, step S103 can include steps a-b. In step a, a dialing test scheme corresponding to the fault scene is obtained, and the link of the IoT card is dialing tested to obtain a dialing test result. In step b, the dialing test result is input into the second sub-model of the preset IoT card large model for fault diagnosis analysis to obtain a target fault diagnosis result.

[0049] The dialing test scheme is obtained according to the fault scene obtained in step S102.

[0050] By means of virtual terminal, network element protocol stack simulation, and path designation, etc., terminal model parameters are virtually simulated / emulated, network elements are simulated, mobile service application is simulated to initiate service request, service condition detection and verification functions are realized, to support efficient fault diagnosis and service recovery condition checking. When generating the dialing test scheme, machine learning or deep learning algorithms can be used to understand and mine the 3rd Generation Partnership Project (3GPP) standard protocols and case knowledge, so as to find potential problems and solutions.

[0051] Based on the dialing test results combined with historical fault description data, according to the business scenarios and 3GPP standard services, combined with historical fault description data and related environmental, equipment state and other multi-element information, the second sub-model is input, and the fault reason is diagnosed and analyzed through a comprehensive perspective, and the target fault diagnosis result is obtained. At the same time, the dialing test scheme obtained in step S103 is the same, and when the dialing test results are diagnosed and analyzed, machine learning or deep learning algorithms can also be used to improve the quality of diagnosis and analysis. The construction method of the second sub-model is the same as the construction method of the first sub-model described above, and will not be repeated here.

[0052] According to the 3GPP standard protocol, the standard protocol and interaction process of different function scenarios (such as voice, short message, data, etc.) are constructed and stored in the graph database or vector database. The registration process is triggered by the terminal initial registration, the registration when moving out of the registration area, and the periodic registration update between the terminal and the network server. This can reduce the need for manual intervention and improve the automation level of the system. The Internet card large model can be used to assist in completing user verification, thereby improving the accuracy and security of verification. By training and optimizing the large model, the system can learn to identify different types of user verification requests, and judge whether it is a legal user according to historical data and pattern recognition, to enhance the security of the network.

[0053] After the PDU (Protocol Data Unit) session is successfully created, the network allocates an IP address to the terminal. The SMF (Session Management Function) can be selected to create the PDU session, and the AMF (Access and Mobility Management Function) in the SMF not only considers the current network status and device conditions, but also utilizes the prediction ability of the IoT card large model. By analyzing historical data and industry knowledge, the AMF can predict future network conditions and device requirements, and select the optimal SMF to handle the PDU session establishment request. For example, when predicting that network congestion will occur in a certain area, the AMF can select an SMF with better performance to handle the session establishment request to provide better user experience.

[0054] After the session is established, the data network needs to be authenticated. By utilizing the prediction and analysis capabilities of the IoT card large model, it can be known in advance whether authentication / authorization is needed, thereby reducing unnecessary authentication requests and improving communication efficiency. For example, in a data network in a certain area, based on historical data and industry knowledge, the communication behavior and access requirements of most users can be predicted, so as to determine whether authentication / authorization is needed or authentication pruning is needed. When authentication fails, a quick troubleshooting and processing guide is provided to help users solve the problem.

[0055] By analyzing the historical data and trends collected in the IoT card large model, future network conditions and device requirements can be predicted. In this way, when creating an N3 tunnel, appropriate preparations can be made in advance, such as increasing bandwidth or adjusting resource allocation, to meet future service request requirements.

[0056] As can be seen, the IoT card fault processing method and device of the embodiments of the present disclosure can input the fault description information into the preset IoT card large model for analysis, determine the fault scenario corresponding to the fault description information according to the analysis result of the IoT card large model, accurately analyze and diagnose the fault, without the need for fault segmentation definition and correlation or probability analysis of the possible causes of the fault, according to the fault scenario corresponding to the fault scenario, the link of the IoT card is probed, and then the target fault diagnosis result is obtained according to the probing result by using the IoT card large model, without the need for related technical personnel to refer to the result for further analysis, thereby improving the efficiency of the IoT card fault processing and saving manpower and resources.

[0057] In some embodiments, after step S103, the method can further include: inputting the target fault diagnosis result into a third sub-model of a preset Internet of Things card big model to obtain a fault handling plan; performing fault repair on the function corresponding to the Internet of Things card according to the fault handling plan; and generating a repair result report according to the repair result of the Internet of Things card.

[0058] Based on the fault diagnosis situation, combined with the 3GPP standard protocol and the historical fault description information in the database, the historical fault description data and the multi-element information such as related environment and equipment state are referred to, and the collaborative scheduling module uses the Internet of Things card big model to generate an accurate fault handling plan through full-view generation.

[0059] The third sub-model is constructed in the same way as the first sub-model described above, and will not be described again here. The session establishment process of the 3GPP standard protocol has been introduced above, and will not be described again here.

[0060] In some embodiments, performing fault repair on the function corresponding to the Internet of Things card according to the fault handling plan can include: determining whether the server contains fault handling authorization information; and in response to the server containing the fault handling authorization information, performing fault repair on the function corresponding to the Internet of Things card according to the fault handling plan.

[0061] When repairing the fault of the Internet of Things card through the network, the device to which the Internet of Things card is applied needs to be accessed, at which time the server needs to be queried first to find out whether the user has fault handling authorization information. If the fault handling authorization information exists, the automatic repair through the network is continued, avoiding the hidden danger of data leakage or security intrusion caused by autonomous access of the network.

[0062] In some embodiments, after determining whether the server contains fault handling authorization information, the method can further include: in response to the server not containing the fault handling authorization information, generating a diagnosis report according to the target fault diagnosis result and the fault handling plan, and sending the diagnosis report to the terminal; and in response to receiving the fault handling authorization information sent by the terminal, performing fault repair on the function corresponding to the Internet of Things card.

[0063] In the above step, when the server fails to find the relevant authorization information, the current diagnosis result and the fault handling plan are generated into a diagnosis report and sent to the terminal of the user. The fault handling plan includes at least two solutions of manual handling and automatic handling, so as to facilitate manual repair when the user does not want the device where the Internet of Things card is located to be accessed externally. On the other hand, when the user sees that the automatic fault handling plan meets the current needs of the user, the user can further authorize the server, that is, continue to automatically repair the fault of the Internet of Things card through the network.

[0064] The user can quickly and accurately understand and execute the fault handling plan through personalized or humanized notification methods, such as dynamically adopting the best way according to the user's usage habits and preferences.

[0065] In some embodiments, during the process of repairing the functions corresponding to the IoT card according to the fault handling plan, the method can further include monitoring the fault repair state parameter, the repair state parameter including the repair speed and the running state of the repaired part; in response to the repair state parameter not meeting the preset condition, adjusting the fault handling plan; and generating a monitoring report according to the repair state parameter and sending it to the terminal.

[0066] Through fault intervention or autonomous cases, real-time tracking and recording are performed, and a dynamically adjusted fault handling plan is adopted to flexibly adjust the monitoring strategy according to new situations occurring during fault handling. The network indicators can be detected to achieve the purpose of detecting the fault repair speed and progress of the IoT card, and the repaired part can also be verified. When the fault repair speed or progress of the IoT card does not meet the preset condition, the session connection or repair strategy mentioned in the above file is adjusted, and the specific repair speed standard and other parameters can be set according to specific needs, which are not limited here.

[0067] In some embodiments, inputting the target fault diagnosis result into a third sub-model of a preset IoT card large model to obtain a fault handling plan can include: inputting the target fault diagnosis result into the third sub-model of the preset IoT card large model to perform solution analysis, obtaining a plurality of solutions corresponding to the target fault diagnosis result; and obtaining a fault handling plan according to the mapping relationship between the target fault diagnosis result and the solution in the preset fault database.

[0068] When generating a fault handling plan, machine learning or deep learning algorithms can be used to understand and mine 3GPP standard protocols and case knowledge, so as to discover potential problems and solutions and further improve the quality of the fault handling plan.

[0069] When the IoT card large model generates a fault intervention or autonomous report, in addition to recording detailed operation steps and results, data analysis and mining can also be performed to discover and optimize potential problems and deficiencies.

[0070] In addition, a user feedback mechanism can be used, that is, after the fault handling is completed, user feedback information is collected and analyzed to optimize and improve the handling plan module. At the same time, the user feedback information can be used as training data for the IoT card large model to improve the prediction accuracy and robustness of the model.

[0071] In some embodiments, the link probing of the IoT card obtains a probing result, which can include: sending a service request to the IoT card through a link between the virtual terminal and the IoT card; and obtaining the probing result according to feedback information of the IoT card on the service request.

[0072] By simulating terminal equipment through software, a test card pool is configured for the terminal equipment, user behavior is simulated to initiate end-to-end flow testing, and the testing range covers wireless networks, transmission networks, core networks, and the like, thereby realizing verification of a full path of a network and a full flow of a service and obtaining full-flow service indicators.

[0073] By simulating various protocol stack processing capabilities through software, communication network elements such as a gNodeB (N2 / N3 network protocol stack), an eNodeB (S1 interface protocol stack), and a BSC (A interface protocol stack) are simulated, the core network interface is accessed to a live network to simulate live network elements, various types of service applications are simulated to be initiated, signaling protocol interactions are simulated, and user service requests are simulated.

[0074] According to DPI data, terminal IP, card information, card access base station, UPF (User Plane Function), cloud server IP of a service platform, local server IP, and the like are obtained, when a virtual terminal or a network element protocol stack simulation task is constructed, relevant path information is specified according to protocol interface parameters, specified link probing is realized, and a probing result of the IoT card is obtained.

[0075] In some embodiments, before the fault scene analysis of the fault description information of the IoT card is performed by inputting the fault description information into a first sub-model of a preset IoT card large model, the method can further include: inputting target prompt word information into the first sub-model, the target prompt word information being used to indicate a preset description format of the fault scene output by the first sub-model; and performing the fault scene analysis of the fault description information of the IoT card by inputting the fault description information into the first sub-model of the preset IoT card large model, to obtain a fault scene corresponding to the fault description information, which includes: performing the fault scene analysis of the fault description information of the IoT card by inputting the fault description information into the first sub-model of the preset IoT card large model, to obtain a fault scene analysis result; and generating a fault scene that meets the preset description format according to the target prompt word information and the fault scene analysis result.

[0076] Inputting prompt word information into a first sub-model is essentially a method for improving the quality of a model generation result by optimizing prompt words, and can combine databases and network protocols to build a Prompt Engineering capability. Inputting prompt word information into a first sub-model can include the following several ways:

[0077] Input-Output (IO) prompting: the most basic method of interacting with a language model, with the notable advantage of its simplicity and directness, but this technique has its limitations. For example, it does not support intermediate steps in problem solving, nor does it provide an explicit process to arrive at a particular response.

[0078] Chain of thought (CoT) prompting: aims to improve IO prompting by instructing the model to make and display intermediate steps. However, while this method provides a structured way for the model to compute and solve a given task, it does not fully understand why this approach leads to better solutions.

[0079] Tree of thoughts (ToT) prompting: actively maintains a tree of thoughts, where each "thought" is a coherent language sequence, as an intermediate step in problem solving. It allows the language model to self-evaluate the progress of different intermediate thoughts in solving a problem through a careful reasoning process instantiated in language.

[0080] In some embodiments, inputting the fault description information into the first sub-model of the preset IoT card large model for fault scene analysis can include: inputting the fault description information into a preset general large model for intent recognition to obtain a query intent request; traversing a preset fault database according to the query intent request to obtain fault scene information corresponding to the query intent request; verifying the fault scene information according to the query intent request using the general large model; and in response to the verification being passed, taking the fault scene information as an IoT card large model analysis result.

[0081] Using the general large model and the historical fault description data in the database, the powerful language processing capability of the general large model and the knowledge management function of the knowledge unit scheme can be organically combined. First, the user's intent is queried through the general large model, and then the relevant content in the domain knowledge base is found according to the problem using a vector database or the like. Finally, the general large model's summarization and generation capabilities are used to complete the construction, i.e., the queried historical fault description data information is verified and integrated after integration.

[0082] In some embodiments, the IoT card fault description information is multi-modal information, and before inputting the IoT card fault description information into the first sub-model of the preset IoT card large model for fault scene analysis, the method can further include: inputting the multi-modal information into a multi-modal fusion encoder for fusion encoding, mapping the multi-modal information to the same vector space to obtain a feature vector of the IoT card fault description information; inputting the IoT card fault description information into the first sub-model of the preset IoT card large model for fault scene analysis, including: inputting the feature vector into the first sub-model of the preset IoT card large model for fault scene analysis.

[0083] Since the devices applied by the Internet of Things card used by the user are different, the device needs to be described in multiple dimensions, so as to support the user to interact through multiple modalities such as text, voice, image, etc. Through preprocessing of multi-modal information, different types of information are integrated into information convenient for model recognition through coding. A multi-modal fusion encoder is constructed through a text encoder, a voice encoder and an image encoder to fuse and encode multi-modal information. The corresponding encoding function formulas (1)-(6) are as follows: P=F p (I) (1)

[0084] P represents the feature vector of the image, I represents the input image, F is the encoding function, and the subscript of F corresponds to the calculation variable. V=F v (S) (2)

[0085] V represents the feature vector of the voice, and S represents the input voice. M t =F h (W t ,M t-1 ) (3)

[0086] M t represents the semantic vector of the first t words in the text sequence, W t represents the tth word in the input text sequence. H t =F a (P,V,M t ) (4)

[0087] H t represents the vector generated by the multi-modal generator.

[0088] represents the fusion vector generated by the fusion encoder.

[0089] Y t represents the probability of the model predicting t fusion encodings, b p is an adjustment parameter.

[0090] The multi-modal fusion encoder architecture adopts the outputs of all layers in the multi-modal fusion encoding and the generated multi-model input vector to generate a description of the multi-modal input through a cross-attention mechanism, and uses a cross-attention layer and a position feedforward network layer to form a fusion decoder. The multi-modal fusion encoder fuses the image, voice and text through an image encoder, a voice encoder and a text encoder respectively, maps the features of different modalities to the same vector space, and enables better fusion of semantic information between different modalities, thereby improving the performance of the model.

[0091] FIG. 2 shows a scene diagram of a system applying the fault processing method of the Internet of Things card according to an embodiment of the present disclosure. As shown in FIG. 2,

[0092] Based on the 3GPP standard communication protocol, the specified link simulation test system is used to accurately determine the fault point, and the fault handling plan is generated in combination with the large model and the knowledge base. In the case of sufficient authorization, the user is guided to intervene to restore the failed service, achieving the full-process closed-loop purpose of fault analysis and disposal. In addition, a unified end-to-end interaction scheme without switching is provided, so that the user can quickly restore the failed service without complex interaction, improving the efficiency and accuracy of fault handling and further improving customer satisfaction.

[0093] As shown in FIG. 2, the system includes a unified interaction module 210, a diagnostic analysis module 220, a disposal plan module 230, a repair guidance module 240, a recovery monitoring module 250, a collaborative scheduling module 260, and an Internet of Things card large model 270.

[0094] As shown in FIG. 2a, the interaction diagram of the unified interaction module 210 in the scene of the system according to an embodiment of the present disclosure is configured to input multi-modal information such as text, voice, and pictures into the terminal by the user. The terminal can be a PC terminal or a mobile terminal. The terminal sends the multi-modal information to the unified interaction module 210, which encodes and integrates the multi-modal information to obtain fault description information, and sends the fault description information to the collaborative scheduling module 260 for use by the Internet of Things card large model 270. In other words, the unified interaction module 210 is configured for user interaction, and uses the multi-modal technology of the Internet of Things card industry large model to support the input of multi-modal information such as natural language, voice, pictures, rich text, H5, etc. into the terminal.

[0095] As shown in FIG. 2b, the interaction schematic diagram of the diagnostic analysis module 220 in the scene of the system provided by one embodiment of the present disclosure is configured to receive the fault description information sent by the unified interaction module 210 through the collaborative scheduling module 260, perform a ping test using the ping test scheme provided by the IoT card large model 270, combine the results obtained by the ping test unit with the historical fault description data in the knowledge unit to perform fault diagnosis analysis, accurately locate the problem cause through the ping test system based on the 3GPP standard protocol and in combination with the scene knowledge, obtain a target fault diagnosis result, and feed back the target fault diagnosis result to the collaborative scheduling module 260.

[0096] As shown in FIG. 2c, the interaction schematic diagram of the disposal plan module 230 in the scene of the system provided by one embodiment of the present disclosure is configured to receive the target fault diagnosis result sent by the diagnostic analysis module 220 through the collaborative scheduling module 260. The disposal plan module 230 establishes a session with the IoT card using the protocol unit, combines the fault signal fed back by the IoT card with the historical fault description information in the knowledge unit, generates a fault disposal scheme, and sends the fault disposal scheme to the collaborative scheduling module 260. The disposal plan module 230 sends the fault disposal scheme in the collaborative scheduling module 260 to the IoT card large model 270, generates a disposal plan through the IoT card large model 270 according to the fault diagnosis situation, in combination with the 3GPP standard protocol and the scene case knowledge, and feeds back the disposal plan to the collaborative scheduling module 260.

[0097] As shown in FIG. 2d, the interaction schematic diagram of the repair guide module 240 in the scene provided by one embodiment of the present disclosure is configured to guide the user to carry out business recovery work according to the fault disposal plan using the permission unit after receiving the disposal plan sent by the collaborative scheduling module 260, to configure and maintain or autonomously troubleshoot the system functions such as the industry branch and the network corresponding to the IoT card under reasonable authorization, to exclude business obstacles, and to send the real-time repair result to the IoT card large model 270 through the collaborative scheduling module 260, to generate a fault intervention or autonomous report using the IoT card large model 270.

[0098] As shown in FIG. 2e, the interaction schematic diagram of the recovery monitoring module 250 in the scene provided by one embodiment of the present disclosure is configured to track the customer business recovery situation, to obtain the real-time repair result from the collaborative scheduling module 260, to constantly improve the diagnosis based on the 3GPP standard protocol and the case knowledge base according to the ping test and the business use situation, to improve the large model analysis diagnosis and disposal plan capability, to quickly give feedback to the customer business recovery, and to improve the customer satisfaction.

[0099] As shown in FIG. 2f, the structural diagram of the collaborative scheduling module 260 in the scenario provided by one embodiment of the present disclosure can include a prompt unit 2601, a memory unit 2602, a vector unit 2603, a proxy unit 2604, an analysis unit 2605, and a model unit 2606.

[0100] The prompt unit 2601 is responsible for processing and large model interaction prompt templates. The prompt templates can repeatedly generate prompts and quickly reuse them. They contain a text string ("template") that takes a set of parameters from the user and generates a prompt, which can be converted into the exact input type (such as text or chat messages) expected by the large model. At the same time, the prompt unit 2601 adapts the prompt word engineering solution of the ThingCard large model, please refer to the foregoing.

[0101] The memory unit 2602 is responsible for remembering all previous chat interaction data, and then passing these chat interaction data back to the large model for summarization or other ways (such as the prompt unit 2601 chain) combination, which helps to maintain the context and improve the understanding of the model to the dialogue, and improve the continuity of user interaction.

[0102] The vector unit 2603 is responsible for processing different types of index and retriever tools and functions, such as vector databases and text splitters, which are configured to obtain relevant documents and provide an interface for combining them with language models, making it easier for large language models to interact with them, such as for the interaction of knowledge units and protocol units. At the same time, the vector unit 2603 adapts the general large model + knowledge unit solution of the ThingCard large model, please refer to the foregoing.

[0103] The proxy unit 2604 is responsible for using appropriate tools to perform tasks, such as driving the dialing unit to implement dialing tasks, and cooperating with the industry unit and network element unit to complete parameter modification or operation and maintenance configuration. The proxy unit 2604 decides to call the corresponding tools according to the user input, and promotes decision-making implementation in the case of repeated authorization. Of course, specific tasks can also be completed in a chained combination way through the proxy unit 2604.

[0104] The analysis unit 2605 is responsible for constructing the response of the large model into a more convenient format, which can make the large model output more structured information. Two main methods are used: one is used to provide formatting instructions, and the other is used to parse the response of the language model into a structured format, making it easier for each module to process output data.

[0105] The model unit 2606 is responsible for the cooperation of different large models, such as ChatGLM in China and LLaMA series abroad, and can further compare and combine the responses of multiple large models with the knowledge unit and the protocol unit to improve relevance and generalization ability. At the same time, the model unit 2606 supports the mixed use of multiple single-modal large models (such as language large models, picture large models, and voice large models), and supports the connection of multi-modal large models. The model unit 2606 is used for organic scheduling of the unified interaction module 210, the diagnostic analysis module 220, the treatment plan module 230, the repair guidance module 240, the recovery monitoring module 250, and the IOT card large model 270 to complete the diagnosis and repair work.

[0106] The IOT card large model 270 is configured to be dispatched by the cooperative scheduling module 260 at any time to assist the diagnostic analysis module 220 and the treatment plan module 230 to obtain analysis results and generate diagnostic results and treatment plans. Through the understanding of user interaction intent, IOT card industry knowledge, 3GPP protocol standards, relevant interaction module result analysis, and the ability to generate various reports, the IOT card large model 270 generates reports in the process of the diagnostic analysis module 220, the treatment plan module 230, the repair guidance module 240, or the recovery monitoring module 250.

[0107] The above-mentioned knowledge unit is used to construct an IOT card data acquisition processing management system for the multi-source and heterogeneous problems of IOT card multi-modal data, deposit IOT card product, process, security risk control, use rules, application scenarios, implementation cases, and other IOT card field corpus, integrate industry, network, platform multi-modal field knowledge and after-sales processing plan knowledge base, form high-quality IOT card field knowledge with large data volume, diversification, and no bias, and provide the diagnostic analysis module and the treatment plan module for use to support efficient fault analysis and troubleshooting and IOT card large model training.

[0108] The above-mentioned protocol unit constructs standard protocols and interaction processes for different functional scenarios (such as voice, short message, and data) according to 3GPP standard protocols, and stores them in a graph database or a vector database for use by the diagnostic analysis module and the treatment plan module to support efficient fault analysis and troubleshooting and IOT card large model training.

[0109] FIG. 3 shows a flowchart of an IOT card fault processing method according to an embodiment of the present disclosure. As shown in FIG. 3, the method is applied to a terminal and includes the following steps:

[0110] S301, receiving a first input of user input IOT card fault description information;

[0111] S302, in response to the first input, sending the Internet of Things card fault description information to the server, so that the server inputs the Internet of Things card fault description information into a first sub-model of a preset Internet of Things card large model for fault scene analysis, obtains a fault scene corresponding to the fault description information, and obtains a target fault diagnosis result according to the fault scene and a knowledge base;

[0112] S303, receiving the target fault diagnosis result returned by the server;

[0113] S304, displaying the target fault diagnosis result.

[0114] In step S301, the terminal is mainly used for receiving multi-modal information input by the user. The terminal can adopt a suitable user interaction and user interaction interface rendering mode, adopt a suitable interaction mode according to different devices of the user, adopt an Internet of Things card industry large model multi-modal technology, support natural language, voice, picture, rich text, H5 and other modes, and receive the Internet of Things card fault description information input by the user.

[0115] The terminal receives a signal sent back by the terminal by using an Internet of Things card large model to understand and analyze the fault scene of the user, determines the Internet of Things card fault scene corresponding to the keywords contained in the Internet of Things card fault description information sent by the user through the terminal, and determines the Internet of Things card fault scene corresponding to the keywords contained in the Internet of Things card fault description information sent by the user through the terminal. The above-mentioned Internet of Things card large model determines the Internet of Things card fault scene corresponding to the keywords contained in the Internet of Things card fault description information sent by the terminal.

[0116] Through virtual terminal, network element protocol stack simulation and path designation, etc. Methods, virtual terminal model parameters in a software manner, simulate network elements, simulate mobile service applications to initiate service requests, realize service condition detection and verification functions, support efficient fault diagnosis and service recovery condition checking, and finally obtain the target fault diagnosis result fed back by the server.

[0117] Finally, the target fault diagnosis result is displayed to the user in a humanized manner, which can be set according to the habits and specific needs of the user.

[0118] FIGS. 4a and 4b show a scene schematic diagram of the terminal provided by an embodiment of the present disclosure. As shown in FIGS. 4a and 4b,

[0119] Fig. 4a is a text form of fault description information input by a user when the terminal is a PC terminal, and provides information of a device where the IoT card is located, including a device type of a children's watch, a serial number of the IoT card in the device or application, and a simple description of the fault condition "unable to make a call". The server receives the fault diagnosis result obtained by the IoT card big model analysis, queries the reason for the call failure and provides a fault handling plan, i.e., adding the call failure number to the whitelist. After the user authorizes the server through the terminal, the server repairs the device where the IoT card is applied, and the terminal receives the repair result and repair report (as shown in Fig. 4b) and displays them to the user.

[0120] The PC terminal is suitable for scenarios such as complex business checking and configuration maintenance, for example, checking and modifying the voice whitelist, because of its large screen size and multiple human-computer interaction means. The PC terminal integrates various platform-related functions such as industry support, network, and operation management, reduces user cross-platform switching, and improves the efficiency of troubleshooting and business recovery.

[0121] Figs. 5a and 5b show a scene schematic diagram of a terminal according to another embodiment of the present disclosure. As shown in Figs. 5a and 5b,

[0122] Fig. 5a is a scene schematic diagram of a terminal according to another embodiment of the present disclosure. As shown in Figs. 5a and 5b,

[0123] Since it is not convenient for the user to type on the mobile terminal, it is more convenient to use voice. Since the user can conveniently carry the mobile terminal, the mobile terminal camera can capture key basic information such as the card number, i.e., take a photo of the IoT card without the need for tedious manual input of the IoT card number, thereby greatly improving the product use efficiency and convenience.

[0124] Fig. 6 shows a structure schematic diagram of an IoT card fault processing apparatus according to an embodiment of the present disclosure, which is applied to a server. As shown in Fig. 6, the apparatus includes a unified interaction module 610, a scene analysis module 620, and a determination module 630.

[0125] The unified interaction module 610 is configured to receive IoT card fault description information sent by a terminal.

[0126] The scene analysis module 620 is configured to input the fault description information of the IoT card into a first sub-model of a preset IoT card large model to perform fault scene analysis, and obtain a fault scene corresponding to the fault description information.

[0127] The determination module 630 is configured to obtain a target fault diagnosis result according to the fault scene and the knowledge base.

[0128] In some embodiments, the determination module 630 includes a stress test sub-module configured to obtain a stress test scheme corresponding to the fault scene, perform link stress test on the IoT card to obtain a stress test result; and a diagnosis analysis sub-module configured to input the stress test result into a second sub-model of the preset IoT card large model to perform fault diagnosis analysis, and obtain a target fault diagnosis result.

[0129] The technical effects of the unfolding analysis and implementation of the IoT card fault processing apparatus are the same as those of steps S101-S103 in the foregoing, and will not be described here again.

[0130] In some embodiments, after the determination module 630 obtains the target fault diagnosis result, the apparatus can further include a treatment plan module configured to input the target fault diagnosis result into a third sub-model of the preset IoT card large model to obtain a fault treatment plan; perform fault repair on a function corresponding to the IoT card according to the fault treatment plan; and generate a repair result report according to a repair result of the IoT card.

[0131] In some embodiments, the treatment plan module can be further configured to determine whether the server contains fault treatment authorization information; and perform fault repair on the function corresponding to the IoT card according to the fault treatment plan in response to the server containing the fault treatment authorization information.

[0132] In some embodiments, after the treatment plan module determines whether the server contains the fault treatment authorization information, the treatment plan module can be further configured to: generate a diagnosis report according to the target fault diagnosis result and the fault treatment plan in response to the server not containing the fault treatment authorization information, and send the diagnosis report to a terminal; and perform fault repair on the function corresponding to the IoT card in response to receiving fault treatment authorization information sent by the terminal.

[0133] In some embodiments, the apparatus can further include a recovery monitoring module configured to monitor a fault repair state parameter during the process in which the treatment plan module performs fault repair on the function corresponding to the IoT card according to the fault treatment plan, the repair state parameter including a repair speed and an operation state of a repaired part; adjust the fault treatment plan in response to the repair state parameter not satisfying a preset condition; and generate a monitoring report according to the repair state parameter and send the monitoring report to a terminal.

[0134] In some embodiments, the treatment plan module inputs the target fault diagnosis result into a third sub-model of a preset industrial card large model to obtain a fault treatment plan. The treatment plan module can also be configured to input the target fault diagnosis result into the third sub-model of the preset industrial card large model for solution analysis to obtain a plurality of solutions corresponding to the target fault diagnosis result; and obtain a fault treatment plan according to a mapping relationship between the target fault diagnosis result and the solutions in a preset fault database.

[0135] In some embodiments, the dialing test sub-module can also be configured to send a service request to the industrial card through a link between the virtual terminal and the industrial card; and obtain a dialing test result according to feedback information of the industrial card to the service request.

[0136] In some embodiments, before the scene analysis module 620 inputs the industrial card fault description information into a first sub-model of a preset industrial card large model for fault scene analysis to obtain a fault scene corresponding to the fault description information, the scene analysis module 620 can also be configured to input target prompt word information into the first sub-model; the target prompt word information is used to indicate a preset description format of the fault scene output by the first sub-model; and the scene analysis module 620 inputs the industrial card fault description information into the first sub-model of the preset industrial card large model for fault scene analysis to obtain a fault scene corresponding to the fault description information, including: the scene analysis module 620 inputs the industrial card fault description information into the first sub-model of the preset industrial card large model for fault scene analysis to obtain a fault scene analysis result; and the scene analysis module 620 generates a fault scene satisfying the preset description format according to the target prompt word information and the fault scene analysis result.

[0137] In some embodiments, the scene analysis module 620 inputs the fault description information into the first sub-model of the preset industrial card large model for fault scene analysis can be configured to input the fault description information into a preset general large model for intent recognition to obtain a query intent request; traverse a preset fault database according to the query intent request to obtain fault scene information corresponding to the query intent request; use the general large model to verify the fault scene information according to the query intent request; and in response to the verification being passed, use the fault scene information as an analysis result of the industrial card large model.

[0138] In some embodiments, the IoT card fault description information is multi-modal information, and before inputting the IoT card fault description information into the first sub-model of the preset IoT card large model for fault scene analysis, the apparatus can be further configured to input the multi-modal information into a multi-modal fusion encoder for fusion encoding, map the multi-modal information to the same vector space, and obtain a feature vector of the IoT card fault description information; and input the IoT card fault description information into the first sub-model of the preset IoT card large model for fault scene analysis, including inputting the feature vector into the first sub-model of the preset IoT card large model for fault scene analysis.

[0139] An IoT card fault diagnosis apparatus applied to a terminal, including: a first receiving module configured to receive a first input of IoT card fault description information input by a user; a sending module configured to send, in response to the first input, the IoT card fault description information to a server, so that the server inputs the IoT card fault description information into a first sub-model of a preset IoT card large model for fault scene analysis, obtains a fault scene corresponding to the fault description information, and obtains a target fault diagnosis result according to the fault scene and a knowledge base; a second receiving module configured to receive the target fault diagnosis result returned by the server; and a display module configured to display the target fault diagnosis result.

[0140] FIG. 7 shows a hardware structure diagram of IoT card fault processing provided by an embodiment of the present disclosure.

[0141] The IoT card fault processing apparatus can include a processor 701 and a memory 702 storing computer program instructions.

[0142] Specifically, the processor 701 can include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement one or more embodiments of the present disclosure.

[0143] The memory 702 can include a mass storage for data or instructions. By way of example and not limitation, the memory 702 can include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive or a combination of two or more of these. Where appropriate, the memory 702 can include removable or non-removable (or fixed) media. Where appropriate, the memory 702 can be internal or external to the integrated gateway disaster recovery apparatus. In some embodiments, the memory 702 is a non-volatile solid-state memory.

[0144] The memory can include read-only memory (ROM), random access memory (RAM), magnetic disk storage mediums devices, optical storage mediums devices, flash memory devices, electrical, optical, or other physical / tangible memory storage devices. Thus, generally, the memory includes one or more tangible (non-transitory) computer-readable storage mediums (e.g., memory devices) encoded with software that, when executed (e.g., by one or more processors), is operable to perform the operations described with reference to the methods according to an aspect of the present disclosure.

[0145] The processor 701 implements the any one of the above-described embodiments of the iot card failure processing method by reading and executing computer program instructions stored in the memory 702.

[0146] In one example, the iot card failure processing device can further include a communication interface 703 and a bus 710. As shown in FIG. 7, the processor 701, the memory 702, and the communication interface 703 are connected through the bus 710 and complete communication with each other.

[0147] The communication interface 703 is mainly used to realize the communication between the modules, devices, units and / or equipment in the embodiments of the present disclosure.

[0148] The bus 710 includes hardware, software, or both, that couples components of the iot card failure processing device to each other. By way of example, and without limitation, a bus can include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand™ interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or another suitable bus or a combination of two or more of these. Where suitable, the bus 710 can include one or more buses. Although particular buses are described and shown in the embodiments of the present disclosure, the present disclosure contemplates any suitable bus or interconnect.

[0149] It needs to be made clear that the present disclosure is not limited to the specific configurations and processes described above and shown in the drawings. Detailed descriptions of known methods are omitted here for the sake of brevity. In the above-described embodiments, several specific steps are described and shown as examples. However, the method processes of the present disclosure are not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order of the steps, after understanding the spirit of the present disclosure.

[0150] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this disclosure are programs or code segments used to perform the required tasks. The programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0151] It should also be noted that the exemplary embodiments mentioned in this disclosure describe methods or systems based on a series of steps or apparatus. However, this disclosure is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0152] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in 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, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0153] The above merely describes a specific implementation of the present disclosure. It can be clearly understood by a person skilled in the art that, for the convenience and brevity of description, the specific working processes of the system, module and unit described above can refer to the corresponding processes in the foregoing method embodiments, which will not be described herein again. It should be understood that the protection scope of the present disclosure is not limited to this. Any person skilled in the art can easily think of various equivalent modifications or replacements within the technical range disclosed by the present disclosure, and these modifications or replacements should be encompassed in the protection scope of the present disclosure.

Claims

1. A method for handling a fault of an IoT card, applied to a server, the method comprising: receiving fault description information of the IoT card sent by a terminal; inputting the fault description information of the IoT card into a first sub-model of a preset IoT card large model to perform fault scene analysis, and obtaining a fault scene corresponding to the fault description information of the IoT card; and obtaining a target fault diagnosis result according to the fault scene and a knowledge base.

2. The method of claim 1, wherein obtaining the target fault diagnosis result according to the fault scene and the knowledge base comprises: obtaining a test scheme corresponding to the fault scene, performing link test on the IoT card to obtain a test result; and inputting the test result into a second sub-model of the preset IoT card large model to perform fault diagnosis analysis, and obtaining the target fault diagnosis result.

3. The method of claim 1, wherein obtaining the target fault diagnosis result according to the fault scene and the knowledge base comprises: obtaining the target fault diagnosis result by using the IoT card large model according to the fault scene, the fault description information of the IoT card, and the knowledge base. After obtaining the target fault diagnosis result, the method further comprises: inputting the target fault diagnosis result into a third sub-model of the preset IoT card large model to obtain a fault handling plan; performing fault repair on a function corresponding to the IoT card according to the fault handling plan; and generating a repair result report according to a repair result of the IoT card. The performing fault repair on the function corresponding to the IoT card according to the fault handling plan comprises: determining whether the server contains fault handling authorization information; and performing fault repair on the function corresponding to the IoT card according to the fault handling plan in response to the server containing the fault handling authorization information. After determining whether the server contains the fault handling authorization information, the method further comprises: generating a diagnosis report according to the target fault diagnosis result and the fault handling plan in response to the server not containing the fault handling authorization information, and sending the diagnosis report to the terminal; and performing fault repair on the function corresponding to the IoT card in response to receiving fault handling authorization information sent by the terminal. During the performing fault repair on the function corresponding to the IoT card according to the fault handling plan, the method further comprises: monitoring a state parameter of the fault repair, wherein the repair state parameter comprises a repair speed and an operation state of a repaired part; adjusting the fault handling plan in response to the repair state parameter not satisfying a preset condition; and generating a monitoring report according to the repair state parameter and sending the monitoring report to the terminal. The inputting the target fault diagnosis result into the third sub-model of the preset IoT card large model to obtain the fault handling plan comprises: inputting the target fault diagnosis result into the third sub-model of the preset IoT card large model to perform solution analysis, and obtaining a plurality of solutions corresponding to the target fault diagnosis result; and obtaining the fault handling plan according to a mapping relationship between the target fault diagnosis result and the solutions in a preset fault database. The performing link test on the IoT card to obtain the test result comprises: ​ ​ 4. The method of claim 1, wherein, ​ ​ ​ ​ 5. The method of claim 4, wherein, ​ ​ ​ 6. The method of claim 5, wherein, ​ ​ ​ 7. The method of claim 4, wherein, ​ ​ ​ ​ 8. The method of claim 4, wherein, ​ ​ ​ 9. The method of claim 1, wherein, ​ sending a service request to the IOT card through a link between the virtual terminal and the IOT card; and obtaining the stress test result according to feedback information of the IOT card to the service request.

10. The method of claim 1, wherein, Before the step of inputting the IOT card fault description information into the first sub-model of the preset IOT card large model to perform fault scene analysis and obtaining the fault scene corresponding to the IOT card fault description information, the method further comprises: inputting target prompt word information into the first sub-model, wherein the target prompt word information is used to indicate a preset description format of the fault scene output by the first sub-model; the step of inputting the IOT card fault description information into the first sub-model of the preset IOT card large model to perform fault scene analysis and obtaining the fault scene corresponding to the IOT card fault description information comprises: inputting the IOT card fault description information into the first sub-model of the preset IOT card large model to perform fault scene analysis and obtaining a fault scene analysis result; and generating a fault scene satisfying the preset description format according to the target prompt word information and the fault scene analysis result.

11. The method of claim 1, wherein, the step of inputting the fault description information into the first sub-model of the preset IOT card large model to perform fault scene analysis comprises: inputting the fault description information into a general large model to obtain a query intent request through intent recognition; traversing a preset fault database according to the query intent request to obtain fault scene information corresponding to the query intent request; verifying the fault scene information according to the query intent request by using the general large model; in response to a verification pass, taking the fault scene information as an analysis result of the IOT card large model.

12. The method of claim 1, wherein, the IOT card fault description information is multi-modal information, before the step of inputting the IOT card fault description information into the first sub-model of the preset IOT card large model to perform fault scene analysis, the method further comprises: inputting the multi-modal information into a multi-modal fusion encoder to perform fusion coding, mapping the multi-modal information to the same vector space, and obtaining a feature vector of the IOT card fault description information; the step of inputting the IOT card fault description information into the first sub-model of the preset IOT card large model to perform fault scene analysis comprises: inputting the feature vector into the first sub-model of the preset IOT card large model to perform fault scene analysis.

13. An IOT card fault diagnosis method applied to a terminal, the method comprising: receiving a first input of IOT card fault description information input by a user; in response to the first input, sending the IOT card fault description information to a server, so that the server inputs the IOT card fault description information into a first sub-model of a preset IOT card large model to perform fault scene analysis, obtains a fault scene corresponding to the IOT card fault description information, and obtains a target fault diagnosis result according to the fault scene and a knowledge base; receiving the target fault diagnosis result returned by the server; and displaying the target fault diagnosis result.

14. An IOT card fault diagnosis apparatus, the apparatus comprising: a unified interaction module configured to receive IOT card fault description information sent by a terminal; ​ The scene analysis module is configured to input the fault description information of the Internet of Things card into a first sub-model of a preset Internet of Things card big model to perform fault scene analysis, and obtain a fault scene corresponding to the fault description information of the Internet of Things card. The determination module is configured to obtain a target fault diagnosis result according to the fault scene and a knowledge base.

14. A communication device comprising: A processor and a memory for storing instructions, wherein the processor implements the method of any one of claims 1 to 12 or the method of claim 13 when executing the instructions.

15. A computer-readable storage medium having instructions stored therein, wherein, The instructions are executed by the processor to implement the method of any one of claims 1 to 12 or the method of claim 13.

16. A computer program product comprising instructions which, when executed by a processor, implement the method of any one of claims 1 to 12 or the method of claim 13.

Images