A control method and device for collecting information of an internet of things card and a communication terminal

Abstract

The application provides a control method and device for collecting information of an Internet of Things card and a communication terminal, wherein the control method comprises the following steps: when a trigger signal of a target task is detected, a task flow corresponding to the trigger signal is obtained from a memory according to the trigger signal and is started; in the case that a first target subtask in the task flow is determined to be executed completely, a consumed time length for executing the first target subtask is stored into a task context; according to a current execution frequency, a previous execution mode and a previous consumed time length related to the first target subtask in the task context, a first execution mode for next execution of the first target subtask is determined, and the first execution mode comprises synchronous execution and asynchronous execution. The application can dynamically adjust the execution mode of the task according to the current response time, improve the collection efficiency and accuracy, and avoid the pressure on the communication terminal. Meanwhile, the execution of the task can be dynamically expanded, which is beneficial to customization.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a control method, device and communication terminal for collecting information from Internet of Things (IoT) cards. Background Technology

[0002] The power platform is primarily designed for online management and control of power equipment (charging piles, meters, substations, etc.). By collecting, controlling, and monitoring data online, it improves the unified management and maintenance of power equipment, freeing up manpower. Managing power equipment necessitates the programmed collection of basic information. Currently, power equipment uses IoT SIM cards for network communication. During the operation and maintenance of the power platform, some manual or programmed controls are required based on the operating status of the IoT SIM cards and the equipment's operational data. Furthermore, it is necessary to collect data from the equipment through interfaces provided by IoT SIM card operators, such as SIM card usage, balance plan, online status, latitude and longitude, and communication status.

[0003] IoT SIM card operators provide numerous interfaces for collecting information such as basic IoT SIM card information, data usage, Access Point Name (APN) status, online status, card balance, and card latitude and longitude. Each interface has a different response speed (for example, the basic information collection interface is faster with fewer concurrent requests to the card open platform, but concurrency slows down the response time for online status and APN status queries). The collection scenarios also differ. Initial card information entry requires collecting basic card information (card number, Integrated Circuit Card Identity (ICCID, i.e., SIM card number), International Mobile Subscriber Identity (IMSI) information, and plan information). Daily scheduled tasks require collecting data usage, balance, APN status, and online status information.

[0004] The current approach involves simple modularization and sequential calling of multiple interfaces provided by operators, followed by data collection and combination. The data collection logic is fixed and cannot be changed. This simple modular development of interfaces cannot flexibly collect or exclude certain information, nor can it dynamically adjust the IoT card information collection logic based on response speed. Furthermore, synchronous and asynchronous tasks are fixed during the development phase and cannot be flexibly adjusted to adapt to actual conditions. Summary of the Invention

[0005] The technical objective of this application is to provide a control method, device, and communication terminal for collecting IoT card information, in order to solve the problem that in current multi-task pipeline scenarios, only simple modular assembly, sequential calling, and data collection and combination are performed, resulting in the inability to flexibly adapt the logic to actual conditions.

[0006] To address the aforementioned technical problems, embodiments of this application provide a control method for collecting IoT card information, including:

[0007] When a trigger signal for a target task is detected, the task flow corresponding to the trigger signal is retrieved from memory and started according to the trigger signal;

[0008] If the first target subtask in the task flow is determined to be completed, the execution time of the first target subtask is stored in the task context. The first target subtask is any completed subtask in the task flow.

[0009] Based on the current number of executions, execution methods, and execution time associated with the first target subtask in the task context, determine the first execution method for the next execution of the first target subtask. The first execution method includes synchronous execution and asynchronous execution.

[0010] Preferably, the control method for collecting IoT card information as described above, after retrieving the task flow corresponding to the trigger signal from memory and starting it according to the trigger signal, further includes:

[0011] The first event is published to start the execution of the target task, and the subtasks in the task flow are read sequentially. The first event is used to trigger the first change step, which is to change the first parameter in the task context corresponding to the target task.

[0012] When the second target subtask is read, a second event is published regarding the second target subtask waiting to be executed, and a first result of whether to execute the second target subtask is obtained according to the task context. The second event triggers a second change step, which is to change the second parameter related to the second target subtask in the task context. The second target subtask is any subtask in the task flow.

[0013] When the first result is to execute the second target subtask, the execution is carried out according to the second execution method related to the second target subtask in the task context.

[0014] Specifically, the control method for collecting IoT card information as described above includes the following steps for obtaining the first result of whether to execute the second target subtask based on the task context:

[0015] Determine whether there exists a target execution expression corresponding to the second target subtask and the configuration parameters related to the target execution expression based on the task context;

[0016] When the target execution expression and / or configuration parameters do not exist, the first result is to skip the target subtask;

[0017] When a target execution expression and configuration parameters exist, the first result is determined by the second result calculated based on the configuration parameters and the target execution expression. Specifically, when the second result is true, the first result is determined to execute the second target subtask; when the second result is false, the first result is determined to skip the second target subtask.

[0018] Specifically, the control method for collecting IoT card information as described above includes the following steps in determining the first execution mode for the next execution of the first target subtask based on the current execution count, previous execution modes, and previous execution durations related to the first target subtask in the task context:

[0019] When the current number of executions is less than the preset number of executions, the first execution method for the next execution of the first target subtask is determined according to the preset alternating execution strategy and the current number of executions. The first execution method is different from the execution method in the current execution.

[0020] When the current execution count is greater than or equal to the preset execution count, obtain the first average of the execution time consumed in synchronous execution and the second average of the execution time consumed in asynchronous execution.

[0021] When the first average value is less than the second average value, the execution method corresponding to the first average value is determined as the first execution method; when the first average value is equal to the second average value, the execution method corresponding to either the first average value or the second average value is determined as the first execution method; when the first average value is greater than the second average value, the execution method corresponding to the second average value is determined as the first execution method.

[0022] Preferably, the control method for collecting IoT card information as described above, upon determining that the first target subtask in the task flow has been completed, further includes:

[0023] The third event is issued when the first target subtask finishes execution. This third event is used to trigger the third change step, which changes the execution method related to the first target subtask in the task context.

[0024] Preferably, the control method for collecting IoT card information as described above further includes:

[0025] When the task flow of the target task is determined to be completed, a fourth event indicating the completion of the entire target task is published. The fourth event is used to trigger the fourth business module listening to the fourth event to change the execution method of each subtask in the task context related to the task flow.

[0026] Preferably, the control method for collecting IoT card information as described above further includes, before detecting a trigger signal for a target task:

[0027] Pre-configure the task's Java Description Language Object Notation (JSON) structure and user configuration file;

[0028] Based on the user configuration file, the task JSON structure is loaded into memory, and the parameters related to the target task in the task context are initialized according to the user configuration file.

[0029] The task JSON structure includes at least one of the following:

[0030] Target task name;

[0031] Target task version number;

[0032] The subtasks included in the target task;

[0033] The class instance name of the subtask;

[0034] How subtasks are executed;

[0035] The execution expression for the subtask.

[0036] Another preferred embodiment of this application also provides a control device, including:

[0037] The first processing module is used to retrieve the task flow corresponding to the trigger signal from memory and start it when a trigger signal of a target task is detected.

[0038] The second processing module is used to store the execution time of the target subtask in the task context when it is determined that the first target subtask in the task flow has been completed. The first target subtask is any subtask in the task flow that has been completed.

[0039] The third processing module is used to determine the first execution method for the next execution of the first target subtask based on the current number of executions, previous execution methods, and previous execution durations related to the first target subtask in the task context. The first execution method includes synchronous execution and asynchronous execution.

[0040] Preferably, the control device described above further includes:

[0041] The fourth processing module is used to publish the first event of the start of execution of the target task and read the subtasks in the task flow in sequence. The first event is used to trigger the first change step, which is to change the first parameter in the task context corresponding to the target task.

[0042] The fifth processing module is used to publish a second event about the second target subtask waiting to be executed when the second target subtask is read, and to obtain a first result of whether to execute the second target subtask according to the task context. The second event is used to trigger a second change step, which is to change the second parameter related to the second target subtask in the task context. The second target subtask is any subtask in the task flow.

[0043] The sixth processing module is used to execute the second target subtask according to the second execution method related to the second target subtask in the task context when the first result is to execute the second target subtask.

[0044] Specifically, in the control device described above, the fifth processing module includes:

[0045] The first processing unit is used to determine, based on the task context, whether there exists a target execution expression corresponding to the second target subtask and configuration parameters related to the target execution expression;

[0046] The second processing unit is used to determine that the first result is to skip the target subtask when there is no target execution expression and / or configuration parameters.

[0047] The third processing unit is used to determine the first result based on the second result calculated from the configuration parameters and the target execution expression when a target execution expression and configuration parameters exist. Specifically, when the second result is true, the first result is determined to execute the second target subtask, and when the second result is false, the first result is determined to skip the second target subtask.

[0048] Specifically, in the control device described above, the sixth processing module includes:

[0049] The fourth processing unit is used to determine the first execution method for the next execution of the first target subtask based on the preset alternating execution strategy and the current execution number when the current execution count is less than the preset execution count. The first execution method is different from the execution method in the current execution.

[0050] The fifth processing unit is used to obtain, when the current execution count is greater than or equal to the preset execution count, the first average of the execution time consumed when the execution mode is synchronous and the second average of the execution time consumed when the execution mode is asynchronous.

[0051] The sixth processing unit is configured to determine the execution mode corresponding to the first average value as the first execution mode when the first average value is less than the second average value; determine the execution mode corresponding to the first average value or the second average value as the first execution mode when the first average value is equal to the second average value; and determine the execution mode corresponding to the second average value as the first execution mode when the first average value is greater than the second average value.

[0052] Preferably, the control device described above further includes:

[0053] The seventh processing module is used to publish a third event indicating the completion of the first target subtask. This third event triggers a third change step, which changes the execution method related to the first target subtask in the task context.

[0054] Preferably, the control device described above further includes:

[0055] The eighth processing module is used to publish a fourth event indicating the completion of the entire target task when the task flow of the target task is determined to be completed. The fourth event is used to trigger the fourth business module listening to the fourth event to change the execution mode of each subtask in the task context related to the task flow.

[0056] Preferably, the control device described above further includes:

[0057] The ninth processing module is used to pre-configure the task JSON structure and user configuration files;

[0058] The tenth processing module is used to load the task JSON structure into memory according to the user configuration file, and initialize the parameters related to the target task in the task context according to the user configuration file.

[0059] The task JSON structure includes at least one of the following:

[0060] Target task name;

[0061] Target task version number;

[0062] The subtasks included in the target task;

[0063] The class instance name of the subtask;

[0064] How subtasks are executed;

[0065] The execution expression for the subtask.

[0066] Another preferred embodiment of this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the control method for collecting IoT card information as described above.

[0067] Another preferred embodiment of this application provides a communication terminal, including a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the steps of the control method for collecting IoT card information as described above.

[0068] Compared with the prior art, the control method, apparatus and communication terminal for collecting IoT card information provided in this application have at least the following beneficial effects:

[0069] The control method for collecting IoT card information provided in this application adjusts the execution mode of the next execution between synchronous and asynchronous execution based on factors such as the execution time after the subtask is completed. This allows the execution mode of the subtask to be dynamically adjusted according to the current response time. When the response speed is fast, multiple subtasks can be executed asynchronously to improve collection efficiency. When the response speed is slow, subtasks can be executed synchronously to ensure the accuracy of collection. At the same time, it avoids the pressure on the communication terminal caused by asynchronous execution when the response speed is slow, and avoids the problem of low collection efficiency caused by using a single fixed collection logic in the current collection process. In addition, the execution of tasks can be dynamically expanded by adding an event mechanism, which is conducive to customization. Attached Figure Description

[0070] Figure 1 This is one of the flowcharts illustrating the control method for collecting IoT card information in this application;

[0071] Figure 2 This is the second flowchart illustrating the control method for collecting IoT card information in this application;

[0072] Figure 3 This is the third flowchart illustrating the control method for collecting IoT card information in this application;

[0073] Figure 4 This is the fourth flowchart illustrating the control method for collecting IoT card information in this application;

[0074] Figure 5 This is a schematic diagram of the control device in this application. Detailed Implementation

[0075] To make the technical problems, technical solutions, and advantages of this application clearer, a detailed description will be provided below in conjunction with the accompanying drawings and specific embodiments. In the following description, specific details such as particular configurations and components are provided merely to aid in a comprehensive understanding of the embodiments of this application. Therefore, those skilled in the art should understand that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Furthermore, for clarity and brevity, descriptions of known functions and structures have been omitted.

[0076] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0077] In the various embodiments of this application, it should be understood that the sequence number of each process described below does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0078] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0079] In the embodiments provided in this application, it should be understood that "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information.

[0080] See Figure 1 A preferred embodiment of this application provides a control method for collecting IoT card information, including:

[0081] Step S101: When a trigger signal for a target task is detected, the task flow corresponding to the trigger signal is retrieved from memory and started according to the trigger signal;

[0082] Step S102: If it is determined that the first target subtask in the task flow has been completed, the execution time of the first target subtask is stored in the task context. The first target subtask is any completed subtask in the task flow.

[0083] Step S103: Based on the current number of executions, previous execution methods, and previous execution durations related to the first target subtask in the task context, determine the first execution method for the next execution of the first target subtask. The first execution method includes synchronous execution and asynchronous execution.

[0084] A specific embodiment of this application provides a control method for collecting IoT card information, specifically including: when a trigger signal of a target task is detected, the corresponding task flow is retrieved from memory and started according to the trigger signal. The trigger signal and the task flow to be triggered may have a pre-agreed correspondence, or the trigger signal may carry information such as the task name and version number corresponding to the task flow to be triggered, so as to obtain the accurate task flow and start it. During the process of starting the task flow and executing it according to the task flow, if it is determined that a first target subtask in the task flow has been completed, the execution time of the first target subtask is stored in the task context for subsequent invocation. Then, based on the current execution count, previous execution methods, and previous execution times related to the first target subtask in the task context, the first execution method for the next execution of the first target subtask is determined. That is, after a subtask is completed, the execution method for the next execution is changed based on the current execution information, so that the execution method of the subtask can be dynamically adjusted according to the current response time.

[0085] In summary, the control method for collecting IoT card information provided in this embodiment adjusts the execution mode of the next execution between synchronous and asynchronous execution based on factors such as the execution time after the subtask is completed. Since the execution time is related to the response speed of the interface, the execution mode of the subtask can be dynamically adjusted according to the current response time. When the response speed is fast, multiple subtasks can be executed asynchronously to improve the collection efficiency. When the response speed is slow, the subtasks can be executed synchronously to ensure the accuracy of the collection. At the same time, it avoids the pressure on the communication terminal caused by asynchronous execution when the response speed is slow. It also avoids the problem of low collection efficiency caused by using a single fixed collection logic in the current collection process.

[0086] It should be noted that the target task can be determined based on information such as the number of the IoT card to be collected.

[0087] It should be noted that the task context refers to the environmental information used during task execution. It can be used to store variables, store or retrieve parameter information used when executing tasks and subtasks. By changing the parameter information in the context, the task execution logic can be dynamically changed during task execution.

[0088] See Figure 2Preferably, the control method for collecting IoT card information as described above, after retrieving the task flow corresponding to the trigger signal from memory and starting it according to the trigger signal, further includes:

[0089] Step S201: Publish the first event for the target task to start execution, and read the subtasks in the task flow in sequence. The first event is used to trigger the first change step, which is to change the first parameter in the task context corresponding to the target task.

[0090] Step S202: When the second target subtask is read, a second event is published regarding the second target subtask waiting to be executed, and a first result of whether to execute the second target subtask is obtained according to the task context. The second event is used to trigger a second change step, which is to change the second parameter related to the second target subtask in the task context. The second target subtask is any subtask in the task flow.

[0091] Step S203: When the first result is to execute the second target subtask, the execution is performed according to the second execution method related to the second target subtask in the task context.

[0092] In another preferred embodiment of this application, after the task flow is started, it is determined that the target task will be executed. At this time, a first event indicating the start of the target task execution is published, enabling the first business module listening to the first event to trigger a first modification step. That is, after listening to the first event, the first business module can adjust the first parameter related to the target task in the task context according to preset logic. In other words, the execution of the target task is dynamically expanded through the event mechanism, which is beneficial for customization. It should be noted that when at least one first business module adjusts the first parameter in the task context, subsequent steps will be executed according to the adjusted task context.

[0093] Furthermore, the subtasks in the task flow are read sequentially. When the second target subtask is read, a second event is published regarding the second target subtask awaiting execution. This triggers a second change step in the second business module listening for the second event. That is, after listening to the second event, the second business module can adjust the second parameters related to the second target subtask in the task context according to preset logic. This allows for dynamic expansion of the execution of the second target subtask through the event mechanism, facilitating customization. It should be noted that when at least one second business module adjusts the second parameter in the task context, subsequent steps will be executed based on the adjusted task context.

[0094] At the same time, when the second target subtask is read, the first result of whether to execute the second target subtask is obtained according to the task context. This allows the second target subtask to be executed or skipped based on the first result. In other words, by judging whether the subtask should be executed, the execution of unnecessary subtasks is avoided, which would increase the time consumption of the entire task flow and improve efficiency.

[0095] It should be noted that the first parameter mentioned above refers to parameters related to the target task, including but not limited to execution expressions, execution methods, user configuration parameters, etc.; the first parameter mentioned above also refers to parameters related to the second target subtask, including but not limited to execution expressions, execution methods, user configuration parameters, etc.

[0096] It should be noted that the task context refers to the environmental information used during task execution. It can be used to store variables, store or retrieve parameter information used when executing tasks and subtasks. By changing the parameter information in the task context, the task execution logic can be dynamically changed during task execution.

[0097] See Figure 3 Specifically, the control method for collecting IoT card information as described above includes the following steps for obtaining the first result of whether to execute the second target subtask based on the task context:

[0098] Step S301: Determine whether there is a target execution expression corresponding to the second target subtask and configuration parameters related to the target execution expression based on the task context;

[0099] Step S302: When there is no target execution expression and / or configuration parameters, determine the first result as executing the second target subtask;

[0100] Step S303: When there is a target execution expression and configuration parameters, the first result is determined based on the second result calculated according to the configuration parameters and the target execution expression. When the second result is true, the first result is determined to execute the second target subtask; when the second result is false, the first result is determined to skip the second target subtask.

[0101] In a specific embodiment of this application, when obtaining the first result of whether to execute the second target subtask based on the task context, it is first determined whether there is a target execution expression corresponding to the second target subtask and configuration parameters related to the target execution expression in the task context. If there is no target execution expression and / or configuration parameters, it is determined that the execution of the second target subtask does not need to be judged by other conditions. At this time, the first result is determined to be to execute the second target subtask, that is, to permanently execute the second target subtask.

[0102] If the task context contains a target execution expression and configuration parameters, it is determined that the execution of the second target subtask requires further judgment based on other conditions. Therefore, a second result is calculated based on the target execution expression and its corresponding configuration parameters. If the second result is true, it indicates that the conditions for executing the second target subtask are met, and the first result is determined to be executing the second target subtask. If the second result is false, it indicates that the conditions for executing the second target subtask are not met, and the first result is determined to be skipping the execution of the second target subtask. This avoids increasing the overall task flow time by executing unnecessary subtasks, which is beneficial for improving efficiency.

[0103] It should be noted that if the first result is to execute the second target subtask, then when the second target subtask is completed, it can be determined that the second target subtask is the first target subtask mentioned above.

[0104] It should be noted that the execution expression described in this application is preferably an Expression Language (EL) expression, which is used to make writing Java Server Pages (JSP) simpler, reduce Java code, and facilitate development and maintenance. The execution expression can simplify the condition judgment of subtasks and support parameter judgment.

[0105] Specifically, the control method for collecting IoT card information as described above includes the following steps in determining the first execution mode for the next execution of the first target subtask based on the current execution count, previous execution modes, and previous execution durations related to the first target subtask in the task context:

[0106] When the current number of executions is less than the preset number of executions, the first execution method for the next execution of the first target subtask is determined according to the preset alternating execution strategy and the current number of executions. The first execution method is different from the execution method in the current execution.

[0107] When the current execution count is greater than or equal to the preset execution count, obtain the first average time consumed when the execution mode is synchronous, and the second average time consumed when the execution mode is asynchronous.

[0108] When the first average value is less than the second average value, the execution method corresponding to the first average value is determined as the first execution method; when the first average value is equal to the second average value, the execution method corresponding to either the first average value or the second average value is determined as the first execution method; when the first average value is greater than the second average value, the execution method corresponding to the second average value is determined as the first execution method.

[0109] In another specific embodiment of this application, when determining the execution method of the first target subtask for the next execution based on the current execution count, previous execution methods, and previous execution duration related to the first target subtask in the task context, the relationship between the current execution count and a threshold, i.e., the preset execution count, is first determined. If the current execution count is less than the preset execution count, it indicates that the current execution count has not met the conditions for switching the execution strategy. Therefore, the execution method for the next execution is still determined according to the preset alternating execution strategy. It should be noted that the preset alternating execution strategy alternates between synchronous execution and asynchronous execution as the first execution method for the next execution. The first execution method can be configured by the user. Preferably, in one specific embodiment, the preset execution count is set to 10 times, that is, after both synchronous execution and asynchronous execution are executed five times, the alternating execution strategy is exited. Under the premise of minimizing the preset execution methods, it is beneficial to ensure the validity of the data during alternating execution and reduce the impact of random errors.

[0110] When the current execution count is greater than or equal to the preset execution count, the alternating execution strategy exits at this time. To ensure that the execution mode and response time correspond to the determined next execution, the average time consumed in executing the second target subtask under different execution modes will be obtained, namely the first average and the second average. The two averages will then be compared. Preferably, the execution mode corresponding to the smaller average value will be determined as the first execution mode for the next execution of the first target subtask, so as to ensure the execution efficiency when executing the second target subtask and the entire target task next time. When the first average is equal to the second average, the execution mode corresponding to the first average or the second average will be determined as the first execution mode, or a pre-set preferred execution mode will be determined as the first execution mode, or the first execution mode will be pre-set to be the same as or opposite to the execution mode of this time.

[0111] It should be noted that the above-mentioned determination of whether to execute and the determination of the execution method for the next execution are all dynamically calculated based on the parameters in the task context or the execution expression set by the user. This allows for dynamic adjustment of the number of subtasks, thereby achieving the effect of dynamically adjusting the task processing logic.

[0112] Preferably, the control method for collecting IoT card information as described above, upon determining that the first target subtask in the task flow has been completed, further includes:

[0113] The third event is issued when the first target subtask finishes execution. This third event is used to trigger the third change step, which changes the execution method related to the first target subtask in the task context.

[0114] In another preferred embodiment of this application, when it is determined that the first target subtask has been completed, a third event indicating the end of the execution of the first target subtask will be published. This allows the third business module listening to the third event to trigger a third change step to change the execution method related to the first target subtask in the task context. This allows the third business module to adjust the execution method related to the first target subtask in the task context according to preset logic after listening to the third event. In other words, the execution of the first target subtask is dynamically expanded again through the event mechanism, which is beneficial for customization.

[0115] Preferably, the control method for collecting IoT card information as described above further includes:

[0116] When the task flow of the target task is determined to be completed, a fourth event indicating the completion of the entire target task is published. The fourth event is used to trigger the fourth business module listening to the fourth event to change the execution method of each subtask in the task context related to the task flow.

[0117] In another preferred embodiment of this application, after the task flow of the target task is determined to be completed, a fourth event indicating the completion of the entire target task will be published. This will trigger the fourth business module listening to the fourth event to change the execution expression related to the first target subtask in the task context. This will allow the fourth business module to adjust the execution expression related to the target task in the task context according to preset logic after listening to the fourth event. In other words, the execution of the first target subtask will be dynamically expanded again through the event mechanism, which is beneficial for customization.

[0118] See Figure 4 Preferably, the control method for collecting IoT card information as described above further includes, before detecting a trigger signal for a target task:

[0119] Step S401: Pre-configure the task JSON structure and user configuration file;

[0120] Step S402: Load the task JSON structure into memory according to the user configuration file, and initialize the parameters related to the target task in the task context according to the user configuration file.

[0121] The task JSON structure includes at least one of the following:

[0122] Target task name;

[0123] Target task version number;

[0124] The subtasks included in the target task;

[0125] The class instance name of the subtask;

[0126] How subtasks are executed;

[0127] The execution expression for the subtask.

[0128] In a preferred embodiment of this application, before detecting the trigger signal, the task JSON structure and user configuration file are pre-configured according to the user's configuration operation and / or input configuration file, so as to provide a data foundation for the subsequent project or task startup and execution;

[0129] Then, based on the user configuration file, the task JSON structure is loaded into memory, and the parameters related to the target task in the task context are initialized according to the user configuration file (i.e., the expression parameters and default values ​​of the configured task flow are read). Initialization helps ensure the smooth collection of IoT card information and avoids the impact of previous historical information on the current project startup. Among these steps, loading the task JSON structure into memory according to the user configuration file is preferably performed when the project containing the task flow is started.

[0130] Specifically, the task JSON structure must include at least one of the following: target task name; target task version number; subtasks contained in the target task; class instance name of the subtask; execution method of the subtask; execution expression of the subtask. This is to facilitate accurate determination of the corresponding target task and subtask based on the trigger signal, and execution of the aforementioned control methods.

[0131] See Figure 5 Another preferred embodiment of this application also provides a control device, including:

[0132] The first processing module 501 is used to retrieve the task flow corresponding to the trigger signal from memory and start it when a trigger signal of a target task is detected.

[0133] The second processing module 502 is used to store the execution time of the target subtask in the task context when it is determined that the first target subtask in the task flow has been completed. The first target subtask is any subtask in the task flow that has been completed.

[0134] The third processing module 503 is used to determine the first execution mode of the first target subtask when it is executed next, based on the current number of executions, the previous execution modes and the previous execution durations related to the first target subtask in the task context. The first execution mode includes synchronous execution and asynchronous execution.

[0135] Preferably, the control device described above further includes:

[0136] The fourth processing module 504 is used to publish the first event of the start of execution of the target task and read the subtasks in the task flow in sequence. The first event is used to trigger the first change step, which is to change the first parameter in the task context corresponding to the target task.

[0137] The fifth processing module 505 is used to publish a second event about the second target subtask waiting to be executed when the second target subtask is read, and to obtain a first result of whether to execute the second target subtask according to the task context. The second event is used to trigger a second change step, which is to change the second parameter related to the second target subtask in the task context. The second target subtask is any subtask in the task flow.

[0138] The sixth processing module 506 is used to execute the second target subtask according to the second execution method related to the second target subtask in the task context when the first result is to execute the second target subtask.

[0139] Specifically, in the control device described above, the fifth processing module 505 includes:

[0140] The first processing unit 5051 is used to determine, based on the task context, whether there is a target execution expression corresponding to the second target subtask and configuration parameters related to the target execution expression;

[0141] The second processing unit 5052 is used to determine that the first result is to skip the target subtask when there is no target execution expression and / or configuration parameters.

[0142] The third processing unit 5053 is used to determine the first result based on the second result calculated from the configuration parameters and the target execution expression when a target execution expression and configuration parameters exist. Specifically, when the second result is true, the first result is determined to execute the second target subtask, and when the second result is false, the first result is determined to skip the second target subtask.

[0143] Specifically, in the control device described above, the sixth processing module 506 includes:

[0144] The fourth processing unit 5061 is used to determine the first execution method for the next execution of the first target subtask based on the preset alternating execution strategy and the current execution number when the current execution count is less than the preset execution count. The first execution method is different from the execution method in the current execution.

[0145] The fifth processing unit 5061 is used to obtain, when the current execution count is greater than or equal to the preset execution count, the first average value of the execution time when the execution mode is synchronous and the second average value of the execution time when the execution mode is asynchronous.

[0146] The sixth processing unit 5062 is used to determine the execution mode corresponding to the first average value as the first execution mode when the first average value is less than the second average value; to determine the execution mode corresponding to the first average value or the second average value as the first execution mode when the first average value is equal to the second average value; and to determine the execution mode corresponding to the second average value as the first execution mode when the first average value is greater than the second average value.

[0147] Preferably, the control device described above further includes:

[0148] The seventh processing module 507 is used to publish a third event indicating the completion of the first target subtask. The third event is used to trigger a third change step, which is to change the execution method related to the first target subtask in the task context.

[0149] Preferably, the control device described above further includes:

[0150] The eighth processing module 508 is used to publish a fourth event indicating the completion of the entire target task when the task flow of the target task is determined to be completed. The fourth event is used to trigger the fourth business module listening to the fourth event to change the execution mode of each subtask in the task context related to the task flow.

[0151] Preferably, the control device described above further includes:

[0152] The ninth processing module 509 is used to pre-configure the task JSON structure and user configuration file;

[0153] The tenth processing module 5010 is used to load the task JSON structure into memory according to the user configuration file, and initialize the parameters related to the target task in the task context according to the user configuration file.

[0154] The task JSON structure includes at least one of the following:

[0155] Target task name;

[0156] Target task version number;

[0157] The subtasks included in the target task;

[0158] The class instance name of the subtask;

[0159] How subtasks are executed;

[0160] The execution expression for the subtask.

[0161] The embodiment of the control device of the present invention is a control device corresponding to the embodiment of the control method for collecting IoT card information described above. All implementation means in the above method embodiment are applicable to the embodiment of this control device and can achieve the same technical effect.

[0162] Another preferred embodiment of this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the control method for collecting IoT card information as described above.

[0163] Another preferred embodiment of this application provides a communication terminal, including a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the steps of the control method for collecting IoT card information as described above.

[0164] It should be noted that when adjusting the parameters, the first and second business modules mentioned above can also add some of their own business processing logic.

[0165] Optionally, the first, second, third, and fourth service modules mentioned above can be separate modules that do not interfere with each other, or they can be the same module. They can be in the same system or different systems of the current communication terminal, or in other communication terminals. No specific limitation is made here.

[0166] It should be noted that configuring the time spent on information interface acquisition of IoT cards, i.e. the time spent executing subtasks, as task time or inventory query time in different multi-task pipeline scenarios also falls within the scope of protection of this application.

[0167] Furthermore, reference numerals and / or letters may be repeated in different examples within this application. Such repetition is for the purpose of simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or settings discussed.

[0168] It should also be noted that, in this document, relational terms such as "first" and "second" are used only 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.

[0169] The above description is the preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principles described in this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A control method for collecting information from an Internet of Things (IoT) card, characterized in that, include: When a trigger signal for a target task is detected, the task flow corresponding to the trigger signal is retrieved from memory and started according to the trigger signal; If it is determined that the first target subtask in the task flow has been completed, the execution time of the first target subtask is stored in the task context. The first target subtask is any one of the completed subtasks in the task flow. Based on the current number of executions, previous execution methods, and previous execution durations related to the first target subtask in the task context, the first execution method for the next execution of the first target subtask is determined, and the first execution method includes synchronous execution and asynchronous execution. After retrieving and starting the task flow corresponding to the trigger signal from memory based on the trigger signal, the control method further includes: The first event is published to start the execution of the target task, and the subtasks in the task flow are read sequentially. The first event is used to trigger a first change step, which is to change the first parameter in the task context corresponding to the target task. When the second target subtask is read, a second event is published regarding the second target subtask waiting to be executed, and a first result of whether to execute the second target subtask is obtained according to the task context. The second event is used to trigger a second change step, which is to change a second parameter related to the second target subtask in the task context. The second target subtask is any subtask in the task flow. When the first result is to execute the second target subtask, the execution is performed according to the second execution method related to the second target subtask in the task context.

2. The control method for collecting IoT card information according to claim 1, characterized in that, The step of obtaining a first result regarding whether to execute the second target subtask based on the task context includes: Based on the task context, determine whether there exists a target execution expression corresponding to the second target subtask and configuration parameters related to the target execution expression; When the target execution expression and / or the configuration parameters do not exist, the first result is determined to skip the target subtask; When the target execution expression and the configuration parameters exist, the first result is determined by the second result calculated based on the configuration parameters and the target execution expression. When the second result is true, the first result is determined to execute the target subtask; when the second result is false, the first result is determined to skip the target subtask.

3. The control method for collecting IoT card information according to claim 1, characterized in that, The step of determining the first execution method for the next execution of the first target subtask based on the current execution count, previous execution methods, and previous execution duration related to the first target subtask in the task context includes: When the current execution count is less than the preset execution count, the first execution method for the next execution of the first target subtask is determined according to the preset alternating execution strategy and the current execution count, wherein the first execution method is different from the execution method in the current execution. When the current execution count is greater than or equal to the preset execution count, the first average of the time consumed in each execution when the execution mode is synchronous, and the second average of the time consumed in each execution when the execution mode is asynchronous are obtained respectively. When the first average value is less than the second average value, the execution mode corresponding to the first average value is determined to be the first execution mode; when the first average value is equal to the second average value, the execution mode corresponding to the first average value or the second average value is determined to be the first execution mode; when the first average value is greater than the second average value, the execution mode corresponding to the second average value is determined to be the first execution mode.

4. The control method for collecting IoT card information according to claim 1, characterized in that, If it is determined that the first target subtask in the task flow has been completed, the control method further includes: A third event is published indicating that the first target subtask has finished executing. The third event is used to trigger a third change step, which is to change the execution mode related to the first target subtask in the task context.

5. The control method for collecting IoT card information according to claim 1 or 4, characterized in that, Also includes: When it is determined that the task flow of the target task has been completed, a fourth event indicating that the entire target task has been completed is published. The fourth event is used to trigger a step in the fourth business module that listens for the fourth event to change the execution mode associated with each subtask in the task flow within the task context.

6. The control method for collecting IoT card information according to claim 1, characterized in that, Before detecting a trigger signal for a target task, the control method further includes: Pre-configure the task's Java description language object abbreviation JSON structure and user configuration file; According to the user configuration file, the task JSON structure is loaded into the memory, and the parameters related to the target task in the task context are initialized according to the user configuration file. The task JSON structure includes at least one of the following: Target task name; Target task version number; The subtasks included in the target task; The class instance name of the subtask; How subtasks are executed; The execution expression for the subtask.

7. A control device, characterized in that, include: The first processing module is used to retrieve the task flow corresponding to the trigger signal from memory and start it when a trigger signal of a target task is detected. The second processing module is used to store the execution time of the target subtask in the task context when it is determined that the first target subtask in the task flow has been completed. The first target subtask is any one of the completed subtasks in the task flow. The third processing module is used to determine the first execution method for the next execution of the first target subtask based on the current execution count, previous execution methods, and previous execution duration related to the first target subtask in the task context. The first execution method includes synchronous execution and asynchronous execution. Also includes: The fourth processing module is used to publish the first event of the start of execution of the target task and read the subtasks in the task flow in sequence. The first event is used to trigger the first change step, which is to change the first parameter in the task context corresponding to the target task. The fifth processing module is used to publish a second event about the second target subtask waiting to be executed when the second target subtask is read, and to obtain a first result of whether to execute the second target subtask according to the task context. The second event is used to trigger a second change step, which is to change the second parameter related to the second target subtask in the task context. The second target subtask is any subtask in the task flow. The sixth processing module is used to execute the second target subtask according to the second execution method related to the second target subtask in the task context when the first result is to execute the second target subtask.

8. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, and when executed by a processor, the computer program implements the steps of the control method for collecting IoT card information as described in any one of claims 1 to 6.

9. A communication terminal, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein when the program or instructions are executed by the processor, they implement the steps of the control method for collecting IoT card information as described in any one of claims 1 to 6.

Images