A method and device for handling a failure of an IoT card

Abstract

The application provides a kind of IOT card fault processing method and device, the method comprises: receiving terminal sent IOT card fault description information;The IOT card fault description information is input into the first submodel of the preset IOT card big model to carry out fault scene analysis, obtain the fault scene corresponding to the fault information;Obtain the dialing test scheme corresponding to the fault scene, dial the link of the IOT card, obtain the IOT card dialing test result;The dialing test result is input into the second submodel of the preset IOT card big model to carry out fault diagnosis analysis, obtain target fault diagnosis result.

Description

Technical Field

[0001] This application belongs to the field of Internet of Things (IoT) technology, and in particular relates to a method and apparatus for handling IoT card faults. Background Technology

[0002] Typically, IoT SIM cards, as a core component of IoT infrastructure, serve as a network link connecting IoT devices with services and platforms. However, with the rapid development of IoT technology, the diversity of IoT devices, complex network interface protocols, and intricate inter-system interactions mean that when an IoT SIM card malfunctions, it usually requires collaborative efforts across different fields, companies, departments, and teams to handle the fault. This makes fault location and handling more complex and less efficient.

[0003] Existing technologies locate and handle IoT SIM card faults by detecting network device indicators, terminal indicators, the correlation between network KPI indices and abnormal services, and data from specific service scenarios and preset rules in service domains and O-domains. However, because existing solutions only segment and define faults and analyze the correlation or probability of possible causes, they cannot accurately diagnose the causes of faults or provide the necessary solutions and interventions to restore services. Further analysis by technical personnel is required. Therefore, accurately analyzing and diagnosing faults has become a pressing technical problem for those skilled in the art. Summary of the Invention

[0004] This application provides a method and apparatus for handling IoT card faults, which can accurately analyze and diagnose IoT card faults.

[0005] On one hand, embodiments of this application provide an IoT card fault handling method, applied to a server, the method including:

[0006] Receive IoT card fault description information sent by the receiving terminal;

[0007] The fault description information of the IoT card is input into the first sub-model of the preset IoT card large model to perform fault scenario analysis and obtain the fault scenario corresponding to the fault information.

[0008] Obtain the test plan corresponding to the fault scenario, perform link test on the IoT card, and obtain the IoT card test results;

[0009] The test results are input into the second sub-model of the preset IoT card large model for fault diagnosis analysis to obtain the target fault diagnosis result.

[0010] On the other hand, embodiments of this application provide an IoT card fault handling method, applied to a terminal, the method including:

[0011] The first input is the description of the IoT card fault provided by the user.

[0012] In response to the first input, the IoT card fault description information is sent to the server so that the server inputs the IoT card fault description information into the first sub-model of the preset IoT card large model to perform fault scenario analysis and obtain the fault scenario corresponding to the fault information.

[0013] Obtain the test plan corresponding to the fault scenario, perform link test on the IoT card, and obtain the IoT card test results;

[0014] The test results are input into the second sub-model of the preset IoT card large model for fault diagnosis analysis to obtain the target fault diagnosis result;

[0015] Receive the target fault diagnosis result returned by the server;

[0016] Display the diagnostic results of the target fault.

[0017] Furthermore, embodiments of this application provide an IoT card fault handling device, the device comprising:

[0018] Receive IoT card fault description information sent by the receiving terminal;

[0019] The fault description information of the IoT card is input into the first sub-model of the preset IoT card large model to perform fault scenario analysis and obtain the fault scenario corresponding to the fault information.

[0020] Obtain the test plan corresponding to the fault scenario, perform link test on the IoT card, and obtain the IoT card test results;

[0021] The test results are input into the second sub-model of the preset IoT card large model for fault diagnosis analysis to obtain the target fault diagnosis result.

[0022] Therefore, the IoT card fault handling method and apparatus of this application embodiment can input fault description information into a preset IoT card large model for analysis, determine the fault scenario corresponding to the fault description information based on the analysis results of the IoT card large model, and accurately analyze and diagnose the fault. It does not require fault segmentation or correlation or probability analysis of possible causes of the fault. According to the dialing test scheme corresponding to the fault scenario, the IoT card link is dialed, and the target fault diagnosis result is obtained by using the IoT card large model based on the dialing test results. No further analysis by relevant technical personnel is required, which improves the efficiency of IoT card fault handling and saves manpower and material resources. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart illustrating an IoT card fault handling method provided in one embodiment of this application;

[0025] Figure 2 This is a schematic diagram of a system scenario for an IoT card fault handling method provided in one embodiment of this application;

[0026] Figure 2a This is a schematic diagram of the interaction of the unified interaction module in a scenario provided by one embodiment of this application;

[0027] Figure 2b This is a schematic diagram of the interaction between the diagnostic analysis module and the application in a scenario provided by one embodiment of this application;

[0028] Figure 2c This is a schematic diagram illustrating the interaction of the emergency response plan module in a scenario provided by one embodiment of this application;

[0029] Figure 2d This is a schematic diagram of the repair guidance module interaction in a scenario provided by one embodiment of this application;

[0030] Figure 2e This is a schematic diagram of the interaction of the restoration monitoring module in a scenario provided by one embodiment of this application;

[0031] Figure 2f This is a schematic diagram of the structure of the collaborative scheduling module in a scenario provided by one embodiment of this application;

[0032] Figure 3 This is a flowchart illustrating an IoT card fault handling method provided in another embodiment of this application;

[0033] Figure 4a This illustration shows a scenario diagram of a terminal provided in one embodiment of this application;

[0034] Figure 4b This illustration shows another scenario diagram of a terminal provided in one embodiment of this application;

[0035] Figure 5a This illustration shows a scenario diagram of a terminal provided in another embodiment of this application;

[0036] Figure 5b A schematic diagram of a scenario for another terminal provided in another embodiment of this application is shown;

[0037] Figure 6This paper shows a schematic diagram of the structure of an IoT card fault handling device according to an embodiment of the present application;

[0038] Figure 7 A schematic diagram of the hardware structure for IoT card fault handling provided in an embodiment of this application is shown. Detailed Implementation

[0039] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application 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 this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0040] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0041] As a core component of IoT infrastructure, IoT SIM cards serve as the network link connecting IoT devices with services and platforms. However, with the rapid development of IoT technology, the diversity of IoT devices, complex network interface protocols, and intricate inter-system interactions make locating and handling IoT SIM card faults increasingly challenging in real-world applications. Addressing these faults typically requires collaborative efforts across domains, companies, departments, and teams, which not only increases the complexity of fault handling but also reduces its efficiency. Therefore, IoT SIM card fault location and handling is currently one of the key aspects affecting user experience in business processes.

[0042] Existing technologies mainly include the following methods: analyzing network device indicators, analyzing terminal device indicators, analyzing the correlation between changes in network KPI indicators and the causes of business anomalies, and analyzing business domain and O domain data for specific business scenarios and preset rules.

[0043] However, in the existing technology, the method of analyzing network device indicators has two main problems. First, the diagnostic dimension is network device, which lacks the ability to diagnose card dimensions, resulting in coarse diagnostic granularity. Second, the diagnostic time is relatively long. Even if the network device does not issue an alarm, it is necessary to continuously monitor it for 7 days (or even a certain period of longer) to determine that the device indicators are continuously deteriorating, which leads to untimely diagnosis.

[0044] The terminal device indicator analysis method relies too heavily on the terminal's reporting capability. On the one hand, the terminal needs to encapsulate or process fault information, which increases the burden on the terminal device. On the other hand, it may not be able to obtain the reported data. When the service fails, the network may have already lost connection, making it impossible to obtain effective data for diagnostic analysis.

[0045] The correlation analysis method is based on the analysis of network equipment indicators and adds correlation of possible causes of failure. Therefore, the network equipment indicator analysis has the disadvantages of coarse diagnostic granularity and untimely diagnosis. Its failure causes are mainly probabilistic correlations, rather than root cause analysis based on the problem, and cannot make accurate diagnoses.

[0046] The specified rule-based analysis method has several drawbacks. First, it relies on cross-disciplinary data correlation analysis to pinpoint problems as a probabilistic rather than a causal approach, resulting in inaccurate cause identification. Second, segmented testing to assess service quality suffers from coarse-grained diagnostics and untimely diagnoses due to network device metrics. Third, while DPI-based path reconstruction is used, different SIM cards have varying service and network domain configurations and statuses, leading to inconsistent link parameters, environmental differences, and impacting location accuracy. Finally, the requirement for manual pre-configuration of industry rules (setting specific scenarios and business rules for fault location and diagnosis) introduces a cold-start problem, heavily relying on user experience and expertise, thus affecting the effectiveness of fault analysis.

[0047] More importantly, existing technologies cannot accurately analyze and diagnose the causes of failures. Instead, they provide suspicious points for business support personnel or equipment maintenance personnel to refer to for further analysis, which leads to a decrease in the efficiency of handling IoT card failures.

[0048] To address the problems of existing technologies, embodiments of this application provide an IoT SIM card fault handling method and apparatus. The IoT SIM card fault handling method provided in this application embodiment is described below.

[0049] Figure 1 A flowchart illustrating an embodiment of the IoT card fault handling method provided in this application is shown. Figure 1 As shown, applied to a server, the method includes:

[0050] S101, Receive IoT card fault description information sent by the terminal.

[0051] The terminal can be determined by the user based on the actual situation. The received IoT SIM card fault description information may include the IoT SIM card application device name, the specific manifestation of the fault (e.g., inability to make calls, inability to connect to the internet, etc.), and the appearance of the application device. Upon receiving the IoT SIM card fault description information, the IoT SIM card fault handling process begins.

[0052] S102, input the IoT card fault description information into the first sub-model of the preset IoT card large model to perform fault scenario analysis and obtain the fault scenario corresponding to the fault information.

[0053] By using a large IoT SIM card model to understand and analyze user fault scenarios, and based on the keywords contained in the IoT SIM card fault description information sent by the user through the terminal in step S101 above, the corresponding IoT SIM card fault scenarios are determined. The construction of the first sub-model can include: training a mind tree prompting method through prompt word engineering, processing fault data based on prompt words; combining a general large model with historical fault data in the database to identify the intent of the fault description information, 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 obtained relevant information; further training the open-source general large model for fault information by adjusting its parameters; and employing a standard Transformer multi-head attention mechanism to assign weights to keywords in the fault information by paying attention to different words separately, obtaining the fault information most relevant to the handling result. The construction of the first sub-model can be combined with the above construction methods as needed.

[0054] These keywords can be weighted. For example, based on the device type of the IoT SIM card application provided by the user, the IoT SIM card model can be determined. Keywords related to device type can then be assigned high weight. Determining the scenario in which the IoT SIM card is used improves the accuracy of IoT SIM card fault analysis when inputting it into a larger IoT SIM card model later.

[0055] S103, obtain the dial-up test plan corresponding to the fault scenario, perform a dial-up test on the IoT card, and obtain the IoT card dial-up test results.

[0056] The testing scheme is obtained based on the fault scenario obtained in step S102 above.

[0057] By employing methods such as virtual terminals, network element protocol stack simulation, and path specification, service requests are initiated using virtual terminal model parameters, simulated network elements, and simulated mobile service applications in a software-based manner. This enables the detection and verification of service status, supporting efficient fault diagnosis and service recovery status checks. When generating dial-up testing schemes, machine learning or deep learning algorithms can be used to understand and mine 3GPP standard protocols and case knowledge, thereby discovering potential problems and solutions.

[0058] S104. Input the test result into the second sub-model of the preset IoT card large model for fault diagnosis analysis to obtain the target fault diagnosis result.

[0059] Based on the IoT SIM card test results and historical fault data, and according to the business scenario and 3GPP (3rd Generation Partnership Project) standard services, the second sub-model is input with historical fault data and diverse information such as the relevant environment and equipment status. This comprehensive approach completes the fault cause diagnosis and analysis, yielding the target fault diagnosis result. Similar to the test scheme obtained in step S103, machine learning or deep learning algorithms can also be used to improve the quality of the diagnostic analysis when performing diagnostic analysis on the test results. The construction method of the second sub-model is the same as that of the first sub-model described above, and will not be repeated here.

[0060] The 3GPP standard protocols establish standard protocols and interaction processes for different functional scenarios (such as voice, SMS, and data), storing them in a graph database or vector database. The registration process consists of initial terminal registration, registration triggered by the terminal leaving the registration area, and periodic registration updates between the terminal and the network server. This reduces the need for manual intervention and improves the system's automation level. The IoT SIM card's large model can be used to assist in user authentication, thereby improving the accuracy and security of authentication. By training and optimizing the large model, the system can learn to identify different types of user authentication requests and determine whether a user is legitimate based on historical data and pattern recognition, thus enhancing network security.

[0061] After a PDU (Protocol Data Unit) session is successfully established, the network assigns an IP address to the terminal. The terminal can then choose an SMF (Session Management Function) to create the PDU session. The AMF (Access and Mobility Management Function) within the SMF considers not only the current network status and device conditions but also leverages the predictive capabilities of the IoT SIM card's large-scale model. By analyzing historical data and industry knowledge, the AMF can predict future network conditions and device needs, and select the optimal SMF to handle PDU session establishment requests. For example, if network congestion is predicted in a certain area, the AMF can select an SMF with better performance to handle session establishment requests, providing a better user experience.

[0062] After a session is established, data network authentication is also required. Leveraging the predictive and analytical capabilities of IoT SIM cards' large-scale models, it's possible to anticipate whether authentication / authorization is needed, thereby reducing unnecessary authentication requests and improving communication efficiency. For example, in a regional data network, based on historical data and industry knowledge, the communication behavior and access needs of most users can be predicted, allowing for targeted decisions on whether or not to implement authentication / authorization. When authentication fails, a rapid troubleshooting and handling guide is provided to help users resolve the issue.

[0063] By analyzing historical data and trends collected from the IoT SIM card big data model, future network conditions and device requirements can be predicted. This allows for advance preparation when creating N3 tunnels, such as increasing bandwidth or adjusting resource allocation to meet future service request demands.

[0064] Therefore, the IoT card fault handling method and apparatus of this application embodiment can input fault description information into a preset IoT card large model for analysis, determine the fault scenario corresponding to the fault description information based on the analysis results of the IoT card large model, and accurately analyze and diagnose the fault. It does not require fault segmentation or correlation or probability analysis of possible causes of the fault. According to the dialing test scheme corresponding to the fault scenario, the IoT card link is dialed, and the target fault diagnosis result is obtained by using the IoT card large model based on the dialing test results. No further analysis by relevant technical personnel is required, which improves the efficiency of IoT card fault handling and saves manpower and material resources.

[0065] In some embodiments, after step S104, the method may further include:

[0066] The fault diagnosis result of the target is input into the third sub-model of the preset IoT card large model to obtain the fault handling plan;

[0067] Repair the corresponding functions of the IoT card according to the fault handling plan;

[0068] A repair result report is generated based on the repair results of the IoT card.

[0069] Based on the fault diagnosis, combined with 3GPP standard protocols and historical fault information in the database, and referencing historical fault data as well as various information such as the environment and equipment status, the collaborative scheduling module uses the IoT card big model to generate accurate fault handling plans from a full perspective.

[0070] The construction method of the third sub-model is the same as that of the first sub-model described above, and will not be repeated here. The session establishment process of the 3GPP standard protocol has been introduced above, and will not be repeated here.

[0071] In some embodiments, repairing the function corresponding to the IoT card according to the fault handling plan may include:

[0072] Determine whether the server contains fault handling authorization information;

[0073] In response to the server containing the fault handling authorization information, the corresponding function of the IoT card is repaired according to the fault handling plan.

[0074] When repairing IoT SIM card faults via the network, it is necessary to access the device to which the IoT SIM card is used. At this time, it is necessary to first query the server to check whether the user has fault handling authorization information. If there is authorization, the automatic repair will continue via the network, thus avoiding the risk of data leakage or security intrusion caused by unauthorized network access.

[0075] In some embodiments, after determining whether the server contains fault handling authorization information, the method may further include:

[0076] The server does not contain fault handling authorization information;

[0077] Based on the target fault diagnosis results and the fault handling plan, a diagnostic report is generated;

[0078] The diagnostic report was sent to the terminal.

[0079] In response to receiving fault handling authorization information from the terminal, the corresponding function of the IoT card is repaired.

[0080] If the server fails to find the relevant authorization information during the above steps, a diagnostic report based on the current diagnostic results and troubleshooting plan will be generated and sent to the user's terminal. The troubleshooting plan includes at least two solutions: manual and automatic. This allows for manual repair when the user does not want external access to the device containing the IoT SIM card. Alternatively, if the user finds the automatic troubleshooting plan meets their current needs, they can grant the server further authorization to continue automatically repairing the IoT SIM card's faults over the network.

[0081] Personalized or humanized notification methods can be used, such as dynamically adopting the best approach based on user habits and preferences, to enable users to quickly and accurately understand and execute the contingency plan.

[0082] In some embodiments, during the process of fault repair of the function corresponding to the IoT card according to the fault handling plan, the method may further include:

[0083] Monitor the fault repair status parameters, which include repair speed and the operational status of the repaired parts;

[0084] In response to the fact that the repair status parameters do not meet the preset conditions, the fault handling plan is adjusted;

[0085] A monitoring report is generated based on the repair status parameters and sent to the terminal.

[0086] Through fault intervention or autonomous operation, real-time tracking and recording are conducted, and dynamically adjusted fault handling plans are implemented, flexibly adjusting monitoring strategies based on new situations arising during fault handling. Various network indicators can be monitored to assess the speed and progress of IoT SIM card fault repair, and the repaired portions can also be verified. When the IoT SIM card fault repair speed or progress does not meet preset conditions, the session connection or repair strategies mentioned in the aforementioned document are adjusted. Specific repair speed standards and other parameters can be set according to specific needs and are not further limited here.

[0087] In some embodiments, the target fault diagnosis result is input into the third sub-model of a preset IoT card large model to obtain a fault handling plan, which may include:

[0088] The target fault diagnosis result is input into the third sub-model of the preset IoT card large model for solution analysis, and multiple solutions corresponding to the target fault diagnosis result are obtained.

[0089] Based on the mapping relationship between the target fault diagnosis results and the solution in the preset fault database, a fault handling plan is obtained.

[0090] When generating contingency plans, machine learning or deep learning algorithms can be used to understand and mine 3GPP standard protocols and case knowledge, thereby discovering potential problems and solutions and further improving the quality of contingency plans.

[0091] When generating fault intervention or autonomous reports using IoT card large models, in addition to recording detailed operation steps and results, data analysis and mining can also be performed to discover and optimize potential problems and shortcomings.

[0092] Furthermore, a user feedback mechanism can be leveraged—that is, collecting and analyzing user feedback after fault handling is completed—to optimize and improve the contingency plan module. Simultaneously, user feedback can be used as training data for the IoT SIM card's large-scale model, enhancing the model's prediction accuracy and robustness.

[0093] In some embodiments, the link test of the IoT SIM card, to obtain the IoT SIM card test results, may include:

[0094] Send service requests to the IoT card through the link between the virtual terminal and the IoT card;

[0095] Based on the feedback information from the IoT SIM card regarding the service request, the IoT SIM card dialing test results were obtained.

[0096] By simulating terminal devices with software and configuring test card pools for them, end-to-end process testing is initiated by simulating user behavior. The test scope covers wireless networks, transmission networks, core networks, etc., to achieve verification of the entire network path and the entire business process, and to obtain full-process business indicators.

[0097] By simulating the processing capabilities of various protocol stacks in software, including simulating gNodeB (N2 / N3 network protocol stack), eNodeB (S1 interface protocol stack), and BSC (A interface protocol stack), the core network interface is connected to the existing network to simulate existing network elements, simulate the initiation of various service applications, and simulate user service requests through signaling protocol interaction.

[0098] Based on DPI data, the terminal IP, card information, card access base station, UPF (User Plane Function), cloud server IP of the service platform, local server IP, and other path information are obtained. When constructing virtual terminal or network element protocol stack simulation tasks, the relevant path information is specified according to the protocol interface parameters to achieve specified link dialing test and obtain IoT card dialing test results.

[0099] In some embodiments, before inputting the IoT card fault description information into the first sub-model of a preset IoT card large model for fault scenario analysis to obtain the fault scenario corresponding to the fault information, the method may further include:

[0100] The target prompt word information is input into the first sub-model; the target prompt word information is used to indicate the preset description format of the fault scenario output by the first sub-model;

[0101] The fault description information of the IoT card is input into the first sub-model of the preset IoT card large model for fault scenario analysis to obtain the fault scenario corresponding to the fault information, including:

[0102] The fault description information of the IoT card is input into the first sub-model of the preset IoT card large model to perform fault scenario analysis and obtain the fault scenario analysis results.

[0103] Based on the target prompt information and the analysis results of the fault scenario, a fault scenario that meets the preset description format is generated.

[0104] Inputting prompt words into the first sub-model is essentially a method to improve the quality of the model's generated results by optimizing the prompt words. This can be achieved by combining databases and network protocols to build Prompt Engineering capabilities. Inputting prompt words into the first sub-model can include the following methods:

[0105] Input-Output: The most basic method for interacting with a language model. Its significant advantage lies in its simplicity and directness; however, this technique has its limitations. For example, it does not support intermediate steps in problem-solving, nor does it provide an explicit process for reaching a specific response.

[0106] Chain of thought (CW) aims to improve input-output cues by instructing the model to create and display intermediate steps. However, while this method provides a structured way for the model to compute and solve a given task, it doesn't fully understand why this method leads to a better solution.

[0107] Tree of Thoughts: This method actively maintains a mind tree, where each "thought" is a coherent sequence of language, serving as an intermediate step in problem-solving. It allows the language model to self-evaluate the progress of different intermediate thoughts in problem-solving through a careful reasoning process instantiated with language.

[0108] In some embodiments, inputting the fault description information into the first sub-model of a preset IoT card large model for fault scenario analysis may include:

[0109] The fault description information is input into a preset general model for intent recognition to obtain the query intent request;

[0110] Based on the query intent request, the system traverses the preset fault database to obtain fault scenario information corresponding to the query intent request;

[0111] This general model is used to verify fault scenario information based on query intent requests;

[0112] Upon successful verification, the fault scenario information is used as the result of the IoT card large model analysis.

[0113] By leveraging the general large model and historical fault data in the database, the powerful language processing capabilities of the general large model and the knowledge management functions of the knowledge unit scheme can be organically combined. First, the user's intent is queried through the general large model. Then, relevant content is found in the domain knowledge base based on the question using vector databases and other methods. Finally, the summarization and generation capabilities of the general large model are used to complete the construction, that is, the historical fault data information queried is verified and integrated.

[0114] In some embodiments, the IoT SIM card fault description information is multimodal information. Before inputting the IoT SIM card fault description information into the first sub-model of a preset IoT SIM card large model for fault scenario analysis, the method may further include:

[0115] The multimodal information is input into a multimodal fusion encoder for fusion encoding, and the multimodal information is mapped to the same vector space to obtain the feature vector of the IoT card fault description information;

[0116] The fault description information of the IoT card is input into the first sub-model of the preset IoT card large model for fault scenario analysis, including:

[0117] The feature vector is input into the first sub-model of the preset IoT card large model for fault scenario analysis.

[0118] Since the IoT cards used by users are applied to different devices, multi-dimensional descriptions of the devices are required. Therefore, to support users' interaction through multimodal methods such as text, voice, and images, multimodal information is preprocessed, and different types of information are integrated into information that is easy for the model to recognize through encoding. A multimodal fusion encoder is constructed by using a text encoder, a voice encoder, and an image encoder to fuse and encode multimodal information. The corresponding encoding function formulas (1) to (6) are as follows:

[0119] P = F p (I) (1)

[0120] 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 computational variable.

[0121] V = F v (S) (2)

[0122] V represents the feature vector of the speech, and S represents the input speech.

[0123] M t =F h (W t M t-1 (3)

[0124] M t W represents the semantic vector of the first t words in the text sequence. t This represents the t-th word in the input text sequence.

[0125] H t =F a (P, V, M) t (4)

[0126] H t This represents the vector generated by the multimodal generator.

[0127]

[0128] This represents the fusion vector generated by the fusion encoder.

[0129]

[0130] Y t b represents the probability that the model predicts for t fused codes. p It's about adjusting the parameters.

[0131] The multimodal fusion encoder architecture uses the outputs of all layers in the multimodal fusion encoding process and the generated multi-model input vectors. It generates descriptions of the multimodal inputs through a cross-attention mechanism and uses cross-attention layers and position-feedforward network layers to form the fusion decoder. The multimodal fusion encoder fuses images, speech, and text through image encoders, speech encoders, and text encoders respectively, mapping different modal features to the same vector space. This allows for better fusion of semantic information between different modalities, thereby improving model performance.

[0132] Figure 2 This illustration shows a scenario diagram of a system for handling IoT card faults according to an embodiment of this application. Figure 2 As shown,

[0133] Based on 3GPP standard communication protocols, the fault point is accurately identified through a designated link simulation testing system. Combined with a large model and knowledge base, a fault handling plan is generated. With full authorization, users are guided to intervene to restore services, achieving a closed-loop process for fault analysis and handling. In addition, a unified, end-to-end interactive solution without handover is provided, enabling users to quickly restore services without complex interactions, improving fault handling efficiency and accuracy, and further enhancing customer satisfaction.

[0134] It includes a unified interaction module 210, a diagnostic analysis module 220, a contingency plan module 230, a repair guidance module 240, a restoration monitoring module 250, a collaborative scheduling module 260, and an IoT card large model 270, as shown in the figure.

[0135] The unified interaction module 210, such as Figure 2a This application provides an embodiment of a system scenario illustrating the interaction of a unified interaction module. The module allows users to input multimodal information, such as text, voice, and images, into a terminal, which can be a PC or a mobile device. The terminal then sends this multimodal information to the unified interaction module 210. The unified interaction module 210 encodes and integrates the multimodal information to obtain fault description information, which is then sent to the collaborative scheduling module 260 for use by the IoT SIM card large model 270. In other words, the unified interaction module 210 is used for user interaction and employs an IoT SIM card industry large model to support multimodal methods such as natural language, voice, images, rich text, and H5.

[0136] The diagnostic analysis module 220, such as Figure 2bThis application provides a schematic diagram of the interaction between the diagnostic analysis module and the system in a scenario, which is used to receive fault description information sent by the unified interaction module 210 through the collaborative scheduling module 260, perform dialing tests using the dialing test scheme provided by the IoT card big model 270, combine the results obtained by the dialing test unit with historical fault data in the knowledge unit to perform fault diagnosis analysis, and, based on the 3GPP standard protocol and combined with scenario knowledge, accurately locate the cause of the problem through the dialing test system to obtain the target fault diagnosis result, and feed the target fault diagnosis result back to the collaborative scheduling module 260.

[0137] Among them, the emergency response plan module 230, such as Figure 2c This application provides an embodiment of a system scenario-based emergency response module interaction diagram. The module receives the target fault diagnosis result sent by the diagnostic analysis module 220 through the collaborative scheduling module 260. The emergency response module 230 establishes a session with the IoT card using a protocol unit, and generates a fault handling plan by combining the fault signal fed back by the IoT card with historical fault information in the knowledge unit, sending it to the collaborative scheduling module 260. The fault handling plan in the collaborative scheduling module 260 is then sent to the IoT card's large model 270. Based on the fault diagnosis, combined with 3GPP standard protocols and scenario case knowledge, the IoT card's large model 270 generates an emergency response plan and feeds it back to the collaborative scheduling module 260.

[0138] Among them, the boot module 240 is repaired, such as Figure 2d This application provides an embodiment of a scenario illustrating the interaction of a repair guidance module. After receiving a handling plan from the collaborative scheduling module 260, the module uses an authorization unit to guide the user to carry out business recovery work according to the handling plan. With reasonable authorization, the module configures and maintains or performs fault self-management on the business support, network, and other system functions corresponding to the IoT card, eliminates business obstacles, and can also send the real-time repair results to the IoT card big model 270 through the collaborative scheduling module 260, and use the IoT card big model 270 to generate a fault intervention or self-management report.

[0139] Among them, the restoration monitoring module is 250, such as Figure 2e This application provides an embodiment of a scenario illustrating the interaction of a recovery monitoring module, used to track the recovery status of customer services, obtain real-time repair results from the collaborative scheduling module 260, continuously improve the diagnostic and case knowledge base based on 3GPP standard protocols and the service usage based on dial-up testing and service usage, enhance the ability of large model analysis, diagnosis and contingency planning, and provide rapid feedback on customer service recovery to improve customer satisfaction.

[0140] The collaborative scheduling module 260, such as Figure 2fA schematic diagram of the structure of a collaborative scheduling module in a scenario provided in one embodiment of this application may include: a prompting unit 2601, a memory unit 2602, a vector unit 2603, a proxy unit 2604, a parsing unit 2605, and a model unit 2606.

[0141] The prompting unit 2601 is responsible for processing the prompt word templates for interaction with the large model. The prompt template can generate prompts repeatedly and be quickly reused. It contains a text string ("template"), obtains a set of parameters from the user, and generates prompts, thus converting it into the exact input type expected by the large model (such as text or chat messages). This unit also adapts to the prompt word engineering scheme for the IoT SIM card large model; please refer to the preceding sections.

[0142] The memory unit 2602 is responsible for remembering all previous chat interaction data and then passing this interaction data back to the large model for aggregation or combining it in other ways (such as the prompting unit 2601 chain) to send it back. This helps maintain context and improve the model's understanding of the dialogue, thereby enhancing the continuity of user interaction.

[0143] The Vector Unit 2603 is responsible for handling tools and functions for different types of indexes and retrievers, such as vector databases and text splitters. It provides an interface for retrieving relevant documents and combining them with the language model, making it easier for large language models to interact with them, for example, for the collaborative interaction between knowledge units and protocol units. This unit is also compatible with the general large model + knowledge unit solution for IoT SIM cards; please refer to the preceding sections.

[0144] The agent unit 2604 is responsible for executing tasks using appropriate tools, such as driving the testing unit to perform testing tasks, and coordinating with the support unit and network element unit to complete parameter modifications or operation and maintenance configurations. It determines which tools to invoke based on user input, and promotes decision-making and implementation in cases of duplicate authorization. Of course, specific tasks can also be accomplished through chain combinations of agent units 2604.

[0145] The parsing unit 2605 is responsible for constructing the large model response into a more convenient format, allowing the large model to output more structured information. Two main methods are used: one to provide formatting instructions, and the other to parse the language model's response into a structured format, making it easier to process output data in each module.

[0146] The model unit 2606 is responsible for the coordination of different large models, such as ChatGLM in China and the LLaMA series abroad. It can further compare and merge the response and knowledge units and protocol units of multiple large models to improve relevance and generalization capabilities. Simultaneously, the model unit 2606 supports the mixed use of multiple single-modal large models (such as language large models, image large models, speech large models, etc.) and also supports interfacing with multimodal large models. It is used to coordinate the unified interaction module 210, diagnostic analysis module 220, emergency response plan module 230, repair guidance module 240, recovery monitoring module 250, and IoT card large model 270, organically scheduling and completing diagnostic and repair work.

[0147] The IoT SIM card large model 270 is used for scheduling by the collaborative scheduling module 260 at any time, assisting the diagnostic analysis module 220 and the emergency response plan module 230 in obtaining analysis results and generating diagnostic results and emergency response plans. Through understanding user interaction intent, IoT SIM card industry knowledge, 3GPP protocol standards, result analysis of relevant interaction modules, and the generation of various reports, reports are generated during the processing of the diagnostic analysis module 220, the emergency response plan module 230, the repair guidance module 240, or the recovery monitoring module 250.

[0148] The aforementioned knowledge units address the issues of multi-source and heterogeneous IoT SIM card multimodal data by constructing an IoT SIM card data acquisition, processing, and management system. This system accumulates IoT SIM card domain corpus, including IoT SIM card products, processes, security risk control, usage rules, application scenarios, and implementation cases. It also integrates multimodal domain knowledge from industry support, networks, and platforms, as well as an after-sales handling contingency plan knowledge base. This results in high-quality IoT SIM card domain knowledge that is large in volume, diverse, and unbiased, for use by the diagnostic analysis module and the contingency plan module. This supports efficient fault analysis and troubleshooting, as well as the training of large IoT SIM card models.

[0149] The aforementioned protocol units, based on 3GPP standard protocols, construct standard protocols and interaction processes for different functional scenarios (such as voice, SMS, and data), and store them in a graph database or vector database for use by the diagnostic analysis module and the emergency response module, in order to support efficient fault analysis and troubleshooting, as well as IoT card large model training.

[0150] Figure 3 A flowchart illustrating an embodiment of the IoT card fault handling method provided in this application is shown. Figure 3 As shown, applied to a terminal, the method includes:

[0151] S301, the first input for receiving IoT card fault description information input by the user;

[0152] S302, in response to the first input, send the IoT card fault description information to the server so that the server inputs the IoT card fault description information into the first sub-model of the preset IoT card large model to perform fault scenario analysis and obtain the fault scenario corresponding to the fault information.

[0153] S303, Obtain the test plan corresponding to the fault scenario, perform link test on the IoT card, and obtain the IoT card test results;

[0154] S304. Input the test results into the second sub-model of the preset IoT card large model for fault diagnosis analysis to obtain the target fault diagnosis result;

[0155] S305, Receive the target fault diagnosis result returned by the server;

[0156] S306 displays the fault diagnosis results for this target.

[0157] In step S301, the terminal is mainly used to receive multimodal information input by the user. The terminal can adopt suitable user interaction and user interface rendering methods, adapt appropriate interaction methods according to different user devices, adopt IoT card industry large model multimodal technology, support natural language, voice, images, rich text, H5 and other methods, and receive IoT card fault description information input by the user.

[0158] The terminal receives signals from the user's IoT SIM card and analyzes the user's fault scenario using a large IoT SIM card model. Based on keywords contained in the IoT SIM card fault description information sent by the user through the terminal, the system determines the corresponding IoT SIM card fault scenario and sends the signal back to the terminal. Specifically, the large IoT SIM card model determines the corresponding IoT SIM card fault scenario based on keywords contained in the IoT SIM card fault description information sent by the terminal.

[0159] By using methods such as virtual terminals, network element protocol stack simulation, and path specification, service requests are initiated in software using virtual terminal model parameters, simulated network elements, and simulated mobile service applications. This enables the detection and verification of service status, supporting efficient fault diagnosis and service recovery status checks, and ultimately obtaining the target fault diagnosis results fed back by the server.

[0160] Ultimately, the target fault diagnosis results are presented to the user in a user-friendly manner, which can be configured according to the user's habits and specific needs.

[0161] Figure 4a and Figure 4b A schematic diagram of a scenario for a terminal provided in one embodiment of this application is shown. For example... Figure 4a and Figure 4b As shown,

[0162] Figure 4aWhen the terminal is a PC, the user inputs a text-based description of the fault, providing information about the device containing the IoT SIM card, including the device type (e.g., children's watch), the serial number of the IoT SIM card used in the device, and a brief description of the fault: inability to make calls. The server receives the fault diagnosis results from the IoT SIM card's large-scale model analysis, identifies the cause of the call failure, and provides a fault handling plan, such as adding the failed call number to a whitelist. After the user authorizes the server through the terminal, the server repairs the device associated with the IoT SIM card, and the terminal displays the repair results and a repair report. Figure 4b Receive and display to the user.

[0163] PC-based systems, with their larger screen size and multiple human-computer interaction methods, are suitable for scenarios where users need to perform complex business verification and configuration maintenance, such as checking, verifying, and modifying voice whitelists. They integrate functions from various platforms, including business support, network, and operations management, reducing the need for users to switch between platforms and improving the efficiency of troubleshooting and restoring services.

[0164] Figure 5a and Figure 5b A schematic diagram of a scenario for a terminal provided in another embodiment of this application is shown. For example... Figure 5a and Figure 5b As shown,

[0165] Figure 5a When the terminal is a mobile device, the user primarily uses voice and images to describe the fault information, providing information about the device on which the IoT SIM card is located, including the device type (SIM card) and the SIM card model (image of the SIM card). Upon receiving the fault diagnosis results from the server's large-scale IoT SIM card analysis, the server identifies the cause of the internet connection failure and provides a fault handling plan, thus triggering the device-SIM card binding restriction. After the user authorizes the server through the terminal, the server repairs the device on which the IoT SIM card is attached, and the terminal displays the repair results as follows: Figure 5b Show it to the user.

[0166] Typing on mobile devices is inconvenient, while voice input is more convenient for users. Because it is portable, the mobile device's camera can capture key basic information such as the card number, such as taking a photo of the IoT card, without the need for tedious manual input of the IoT card number, greatly improving the efficiency and convenience of product use.

[0167] Figure 6 A schematic diagram of an IoT card fault handling device according to an embodiment of this application is shown, which is applied to a server. Figure 6 As shown,

[0168] The unified interaction module 610 is used to receive IoT card fault description information sent by the terminal;

[0169] The scenario analysis module 620 is used to input the IoT card fault description information into the first sub-model of the preset IoT card large model to perform fault scenario analysis and obtain the fault scenario corresponding to the fault information.

[0170] The dial test module 630 is used to obtain the dial test plan corresponding to the fault scenario, perform link dial test on the IoT card, and obtain the IoT card dial test results.

[0171] The diagnostic analysis module 640 is used to input the test results into the second sub-model of the preset IoT card large model for fault diagnosis analysis to obtain the target fault diagnosis results.

[0172] The technical effects of the deployment analysis and implementation of the IoT card fault handling device are the same as those in steps S101 to S104 above, and will not be repeated here.

[0173] In some embodiments, after the diagnostic analysis module 640 obtains the target fault diagnosis result, the device may further include:

[0174] The contingency plan module is used to input the fault diagnosis result of the target into the third sub-model of the preset IoT card large model to obtain the fault handling plan; to repair the corresponding function of the IoT card according to the fault handling plan; and to generate a repair result report based on the repair result of the IoT card.

[0175] In some embodiments, the above-mentioned contingency plan module can also be used to determine whether the server contains fault handling authorization information; in response to the server containing the fault handling authorization information, to repair the corresponding function of the IoT card according to the fault handling contingency plan.

[0176] In some embodiments, after the contingency plan module determines whether the server contains fault handling authorization information, the contingency plan module can also be used to:

[0177] The server does not contain authorization information for handling this fault.

[0178] Based on the target fault diagnosis results and the fault handling plan, a diagnostic report is generated;

[0179] The diagnostic report was sent to the terminal.

[0180] In response to receiving fault handling authorization information from the terminal, the corresponding function of the IoT card is repaired.

[0181] In some embodiments, the device may further include a recovery monitoring module, used to monitor the fault repair status parameters during the process of the emergency response module repairing the function corresponding to the IoT card according to the fault response plan. The repair status parameters include the repair speed and the operating status of the repaired part.

[0182] In response to the fact that the repair status parameters do not meet the preset conditions, the fault handling plan is adjusted;

[0183] A monitoring report is generated based on the repair status parameters and sent to the terminal.

[0184] In some embodiments, the emergency response module inputs the target fault diagnosis result into the third sub-model of the preset IoT card large model to obtain a fault response plan. The emergency response module can also be used to input the target fault diagnosis result into the third sub-model of the preset IoT card large model for solution analysis to obtain multiple solutions corresponding to the target fault diagnosis result.

[0185] Based on the mapping relationship between the target fault diagnosis results and the solution in the preset fault database, a fault handling plan is obtained.

[0186] In some embodiments, the above-mentioned dialing test module 630 can also be used to send a service request to the IoT card through the link between the virtual terminal and the IoT card; and obtain the IoT card dialing test result based on the IoT card's feedback information on the service request.

[0187] In some embodiments, before the scene analysis module 620 inputs the IoT card fault description information into the first sub-model of the preset IoT card large model to perform fault scene analysis and obtain the fault scene corresponding to the fault information, the scene analysis module 620 can also be used to input target prompt word information into the first sub-model; the target prompt word information is used to indicate the preset description format of the fault scene output by the first sub-model; 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 obtain the fault scene corresponding to the fault information includes: 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 obtain the fault scene analysis result; generating a fault scene that meets the preset description format based on the target prompt word information and the fault scene analysis result.

[0188] In some embodiments, the scenario analysis module 620 inputs fault description information into the first sub-model of a preset IoT card large model for fault scenario analysis. This can be used 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 scenario information corresponding to the query intent request; verify the fault scenario information using the general large model according to the query intent request; and in response to successful verification, use the fault scenario information as the analysis result of the IoT card large model.

[0189] In some embodiments, the IoT card fault description information is multimodal information. Before inputting the IoT card fault description information into the first sub-model of a preset IoT card large model for fault scenario analysis, the device can also be used to input the multimodal information into a multimodal fusion encoder for fusion encoding, mapping the multimodal information to the same vector space to obtain the 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 scenario analysis includes:

[0190] The feature vector is input into the first sub-model of the preset IoT card large model for fault scenario analysis.

[0191] An IoT SIM card fault diagnosis device, applied to a terminal, the device comprising:

[0192] The receiving module is used to receive the first input of IoT card fault description information input by the user;

[0193] In response to the first input, the IoT card fault description information is sent to the server so that the server inputs the IoT card fault description information into the first sub-model of the preset IoT card large model to perform fault scenario analysis and obtain the fault scenario corresponding to the fault information.

[0194] Obtain the corresponding test plan for the fault scenario, perform link test on the IoT card, and obtain the IoT card test results;

[0195] The test results are input into the second sub-model of the preset IoT card large model for fault diagnosis analysis to obtain the target fault diagnosis results;

[0196] Receive the fault diagnosis result for the target returned by the server;

[0197] Displays the fault diagnosis results for this target.

[0198] Figure 7 A schematic diagram of the hardware structure for IoT card fault handling provided in an embodiment of this application is shown.

[0199] The IoT card fault handling device may include a processor 701 and a memory 702 storing computer program instructions.

[0200] Specifically, the processor 701 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0201] Memory 702 may include mass storage for data or instructions. For example, and not limitingly, memory 702 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 702 may include removable or non-removable (or fixed) media. Where appropriate, memory 702 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 702 is non-volatile solid-state memory.

[0202] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0203] The processor 701 reads and executes computer program instructions stored in the memory 702 to implement any of the IoT card fault handling methods in the above embodiments.

[0204] In one example, the IoT SIM card fault handling device may also include a communication interface 703 and a bus 710. Wherein, as Figure 7 As shown, the processor 701, memory 702, and communication interface 703 are connected through bus 710 and complete communication with each other.

[0205] The communication interface 703 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0206] Bus 710 includes hardware, software, or both, that couples components of an IoT card fault handling device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel 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 other suitable buses, or combinations of two or more of these. Where appropriate, bus 710 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0207] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0208] 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 application are programs or code segments used to perform the required tasks. 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.

[0209] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application 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.

[0210] 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.

[0211] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for handling IoT card faults, characterized in that, Applied to a server, the method includes: Receive IoT card fault description information sent by the receiving terminal; The IoT card fault description information is input into the first sub-model of the preset IoT card large model to perform fault scenario analysis, thereby obtaining the fault scenario corresponding to the IoT card fault description information. Obtain the test plan corresponding to the fault scenario, perform link test on the IoT card, and obtain the IoT card test results; The test results are input into the second sub-model of the preset IoT card large model for fault diagnosis analysis to obtain the target fault diagnosis result.

2. The method according to claim 1, characterized in that, After obtaining the target fault diagnosis result, the method further includes: The target fault diagnosis result is input into the third sub-model of the preset IoT card large model to obtain the fault handling plan; Repair the corresponding functions of the IoT card according to the fault handling plan; A repair result report is generated based on the repair results of the IoT card.

3. The method according to claim 2, characterized in that, The step of repairing the corresponding functions of the IoT card according to the fault handling plan includes: Determine whether the server contains fault handling authorization information; In response to the server containing the fault handling authorization information, the corresponding function of the IoT card is repaired according to the fault handling plan.

4. The method according to claim 3, characterized in that, After determining whether the server contains fault handling authorization information, the method further includes: The server does not contain the aforementioned fault handling authorization information; A diagnostic report is generated based on the target fault diagnosis results and the fault handling plan; Send the diagnostic report to the terminal; In response to receiving fault handling authorization information from the terminal, the corresponding function of the IoT card is repaired.

5. The method according to claim 2, characterized in that, In the process of repairing the corresponding functions of the IoT card according to the fault handling plan, the method further includes: Monitor the status parameters of fault repair, including repair speed and the operating status of the repaired parts; In response to the repair status parameters not meeting the preset conditions, the fault handling plan is adjusted; A monitoring report is generated based on the repair status parameters and sent to the terminal.

6. The method according to claim 2, characterized in that, The step of inputting the target fault diagnosis result into the third sub-model of the preset IoT card large model to obtain the fault handling plan includes: The target fault diagnosis result is input into the third sub-model of the preset IoT card large model for solution analysis, and multiple solutions corresponding to the target fault diagnosis result are obtained. Based on the mapping relationship between the target fault diagnosis results and the solution in the preset fault database, a fault handling plan is obtained.

7. The method according to claim 1, characterized in that, The link test of the IoT SIM card, obtaining the IoT SIM card test results, includes: Send service requests to the IoT card through the link between the virtual terminal and the IoT card; Based on the IoT SIM card's feedback information regarding the service request, the IoT SIM card dialing test results are obtained.

8. The method according to claim 1, characterized in that, Before inputting the IoT SIM card fault description information into the first sub-model of the preset IoT SIM card large model for fault scenario analysis to obtain the fault scenario corresponding to the IoT SIM card fault description information, the method further includes: The target prompt word information is input into the first sub-model; the target prompt word information is used to indicate the preset description format of the fault scenario output by the first sub-model; The step of inputting the IoT SIM card fault description information into the first sub-model of a preset IoT SIM card large model for fault scenario analysis, and obtaining the fault scenario corresponding to the IoT SIM card fault description information, includes: The fault description information of the IoT card is input into the first sub-model of the preset IoT card large model to perform fault scenario analysis and obtain the fault scenario analysis results. Based on the target prompt information and the fault scenario analysis results, a fault scenario that meets the preset description format is generated.

9. The method according to claim 1, characterized in that, The step of inputting the fault description information into the first sub-model of the preset IoT card large model for fault scenario analysis includes: The fault description information is input into a preset general large model for intent recognition to obtain the query intent request; Based on the query intent request, the preset fault database is traversed to obtain fault scenario information corresponding to the query intent request; The fault scenario information is verified using the general large model based on the query intent request; Upon successful verification, the fault scenario information is used as the result of the IoT card large model analysis.

10. The method according to claim 1, characterized in that, The IoT card fault description information is multimodal information. Before inputting the IoT card fault description information into the first sub-model of the preset IoT card large model for fault scenario analysis, the method further includes: The multimodal information is input into a multimodal fusion encoder for fusion encoding, and the multimodal information is mapped to the same vector space to obtain the 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 for fault scenario analysis includes: The feature vector is input into the first sub-model of the preset IoT card large model for fault scenario analysis.

11. A method for diagnosing IoT card faults, characterized in that, Applied to a terminal, the method includes: The first input is the description of the IoT card fault provided by the user. In response to the first input, the IoT card fault description information is sent to the server so that the server inputs the IoT card fault description information into the first sub-model of the preset IoT card large model to perform fault scenario analysis and obtain the fault scenario corresponding to the IoT card fault description information. Obtain the test plan corresponding to the fault scenario, perform link test on the IoT card, and obtain the IoT card test results; The test results are input into the second sub-model of the preset IoT card large model for fault diagnosis analysis to obtain the target fault diagnosis result; Receive the target fault diagnosis result returned by the server; Display the diagnostic results of the target fault.

12. An IoT card fault diagnosis device, characterized in that, The device includes: The unified interaction module is used to receive IoT card fault description information sent by the terminal; The scenario analysis module is used to input the IoT card fault description information into the first sub-model of the preset IoT card large model for fault scenario analysis, and obtain the fault scenario corresponding to the IoT card fault description information. The dial-up test module is used to obtain the dial-up test plan corresponding to the fault scenario, perform dial-up test on the IoT card, and obtain the IoT card dial-up test results. The diagnostic analysis module is used to input the test results into the second sub-model of the preset IoT card large model for fault diagnosis analysis, and obtain the target fault diagnosis result.

Images