Communication module function extension method and system applying dynamic loading

Abstract

The invention provides a communication module function extension method and system applying dynamic loading, and relates to the technical field of communication, and the method comprises the steps: firstly, determining a dynamic loading trigger condition space containing function requirements, module resources and external environment trigger conditions, and collecting data to generate a trigger condition matching data set; then screening adaptive function modules from a preset function module library, and matching corresponding information based on different triggering conditions to generate an adaptive function module set; then carrying out cooperative adaptation processing on the adaptation function module and the communication module to generate a cooperative adaptation result; dynamically injecting a module based on a collaborative adaptation result and constructing a function extension calling architecture; and finally, collecting operation interaction data to generate a communication module function extension running chart, thereby realizing flexible, efficient and stable extension of the communication module function, and improving the adaptive capacity and competitiveness of the communication module.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and more specifically, to a method and system for expanding the functionality of a communication module using dynamic loading. Background Technology

[0002] In today's rapidly developing communication technology, communication modules, as core components for realizing communication functions, are widely used in various smart terminal devices. With the continuous enrichment and complexity of business scenarios, the functional requirements for communication modules are becoming increasingly diverse and dynamic. Traditional methods for expanding the functionality of communication modules have many limitations.

[0003] On the one hand, existing functional expansions typically employ static integration, meaning all potentially needed functional modules are embedded within the communication module during the design and manufacturing phase. This approach results in the module being unable to update and expand its functionality in a timely manner when faced with emerging business requirements, lacking flexibility. For example, when a completely new communication protocol or business application emerges, statically integrated communication modules require redesigning the hardware and reprogramming the software, leading to long development cycles, high costs, and potential impacts on the stability of existing functions.

[0004] On the other hand, while some dynamic function expansion methods can achieve a certain degree of modular loading, they lack comprehensive consideration and precise matching of triggering conditions. They often focus only on a single factor, such as loading based solely on user function requests, while ignoring the resource status of the communication module itself and changes in the external communication scenario. This may lead to the forced loading of function modules under conditions of insufficient resources or incompatible scenarios, causing problems such as module performance degradation and function conflicts, and failing to guarantee the stable operation and efficient function expansion of the communication module in various complex environments. Summary of the Invention

[0005] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide a method for extending the functionality of a communication module using dynamic loading, the method comprising: A dynamic loading trigger condition space is determined. Based on the dynamic loading trigger condition space, real-time operating data of the communication module and external scene data are collected to generate a trigger condition matching dataset. The dynamic loading trigger condition space includes functional requirement trigger conditions, module resource trigger conditions and external environment trigger conditions. Functional requirement trigger conditions correspond to service function requests not covered by the communication module. Module resource trigger conditions correspond to the idle resource threshold of the communication module. External environment trigger conditions correspond to communication scene change signals. Select the appropriate functional modules from the preset functional module library that match the trigger condition matching dataset, and generate a set of appropriate functional modules based on the functional requirement trigger condition matching function interface description information in the trigger condition matching dataset, the module resource trigger condition matching resource requirement information, and the external environment trigger condition matching scenario adaptation information. Each adaptation module in the set of adaptation modules is adapted in collaboration with the communication module. The existing interface of the communication module is connected through the functional interface description information. Idle resources of the communication module are allocated based on the resource requirement information. The module operation parameters are adjusted in combination with the scenario adaptation information to generate a collaborative adaptation result. Based on the collaborative adaptation results, the adaptation function module is dynamically injected into the communication module's operating environment, and a call chain between the adaptation function module and the original function of the communication module is constructed. The call chain includes data interaction path, function execution priority sorting and exception transfer mechanism, and generates a function extension call architecture. Based on the aforementioned functional extension call architecture, the operation interaction data of the adapted functional modules and the original functions of the communication module are collected, and the descriptive information of the operation process, resource consumption and scene response effect of the extended functions are extracted to generate the communication module functional extension operation diagram.

[0006] Furthermore, embodiments of the present invention also provide a communication module function expansion system with dynamic loading, characterized in that it includes: A processor; a machine-readable storage medium for storing machine-executable instructions of the processor; wherein the processor is configured to execute the above-described application-dynamically loaded communication module function extension method by executing the machine-executable instructions.

[0007] In another aspect, embodiments of the present invention also provide a computer program product, the computer program product including machine-executable instructions, the machine-executable instructions being stored in a computer-readable storage medium, a processor of a computer device reading the machine-executable instructions from the computer-readable storage medium, the processor executing the machine-executable instructions, causing the computer device to execute the above-described application-dynamically loaded communication module function extension method.

[0008] Based on the above, a dynamic loading trigger condition space is constructed, encompassing functional requirement trigger conditions, module resource trigger conditions, and external environment trigger conditions. Based on this space, real-time operational data of the communication module and external scene data are collected to generate a trigger condition matching dataset. When selecting compatible functional modules from a pre-defined functional module library, functional interface descriptions, resource requirement information, and scene adaptation information are matched based on different trigger conditions. The compatible functional modules and the communication module undergo collaborative adaptation processing. Through functional interface integration, resource allocation, and operational parameter adjustment, a collaborative adaptation result is generated, effectively avoiding functional conflicts and resource waste, and improving the stability and reliability of functional expansion. Based on the collaborative adaptation result, compatible functional modules are dynamically injected, and a functional expansion call architecture is constructed, clarifying the data interaction path, functional execution priority ranking, and exception transfer mechanism, enabling the expanded communication module to operate efficiently and orderly. Finally, operational interaction data is collected to generate a communication module functional expansion operation graph, achieving flexible, efficient, and stable expansion of the communication module's functions and enhancing its adaptability in complex and changing environments. Attached Figure Description

[0009] Figure 1 This is a schematic diagram of the execution flow of the application-dynamically loaded communication module function expansion method provided in the embodiments of the present invention.

[0010] Figure 2 This is a schematic diagram of exemplary hardware and software components of the application-dynamically loaded communication module function extension system provided in this embodiment of the invention. Detailed Implementation

[0011] The present invention will now be described in detail with reference to the accompanying drawings. Figure 1 This is a flowchart illustrating a method for dynamically loading communication module functions according to an embodiment of the present invention. The following is a detailed description of this method for dynamically loading communication module functions.

[0012] Step S110: Determine the dynamic loading trigger condition space, collect real-time operating data of the communication module and external scene data based on the dynamic loading trigger condition space, and generate a trigger condition matching dataset. The dynamic loading trigger condition space includes functional requirement trigger conditions, module resource trigger conditions and external environment trigger conditions. Functional requirement trigger conditions correspond to service function requests not covered by the communication module, module resource trigger conditions correspond to the idle resource threshold of the communication module, and external environment trigger conditions correspond to communication scene change signals.

[0013] In this embodiment, the core communication module in a general-purpose communication terminal is taken as the object. This core communication module is responsible for connecting the terminal's display unit, input unit, data storage unit, and external network components. First, a dynamic loading trigger condition space is determined, which consists of three types of trigger conditions. Among them, the functional requirement trigger condition targets service requests that the module cannot currently implement, such as encrypted data transmission requests issued by terminal users. If the module does not integrate this function, it belongs to an uncovered service function request. The module resource trigger condition sets thresholds around the module's idle resources, such as the limits on the number of idle memory, computing units, and unused interfaces. The external environment trigger condition focuses on changes in the communication scenario, such as changes in the number of external devices connected to the module, or fluctuations in communication signals due to changes in transmission distance.

[0014] Step S111: Collect prior function extension records of the communication module, and extract the feature space that triggers the function extension from the prior function extension records. The feature space includes prior uncovered service function requests, prior module idle resource status, and prior communication scenario change information.

[0015] Prior function expansion records of the core communication module of this general communication terminal are collected. These records contain the triggering reasons for each expansion. The feature space triggering the function expansion is extracted from the records. Prior uncovered service function requests include previously submitted data compression transmission function requests and multi-protocol conversion function requests. Prior module idle resource status includes data such as the module's idle memory capacity, unused computing resource ratio, and number of idle interfaces at the time of each expansion. Prior communication scenario change information includes previously experienced significant fluctuations in communication signal strength, switching from one type of network protocol to another, and increases or decreases in the number of connected devices.

[0016] Step S112: Classify the feature space, classify the prior uncovered service function request into the function requirement space, classify the prior module idle resource status into the module resource space, and classify the prior communication scenario change information into the external environment space.

[0017] The extracted feature space is divided into categories. All prior uncovered business function requests, such as data compression transmission and multi-protocol conversion requests, are grouped into the functional requirement category space. All prior module idle resource status data, such as idle memory, computing resources, and interface idle status at different time points, are grouped into the module resource category space. All prior communication scenario change information, such as signal strength changes, protocol switching, and changes in the number of connected devices, are grouped into the external environment category space.

[0018] Step S113: Construct conditional features for triggering functional requirements based on the functional requirement class space. The triggering conditions for functional requirements include business function request type, request frequency, and request urgency. The business function request type corresponds to the category of business functions not covered. The request frequency corresponds to the number of times the same request occurs within a unit of time. The request urgency corresponds to the real-time requirement of the request.

[0019] Based on the functional requirement class space, conditional features for triggering functional requirements are constructed. Business function request types are categorized according to the types of business not covered, such as data security (e.g., encrypted data transmission), data processing (e.g., compressed data transmission), and protocol adaptation (e.g., multi-protocol conversion), with each category corresponding to one business function request type. Request frequency is calculated by the number of times the same request occurs within a unit of time, for example, by counting the number of times a certain type of request occurs in a fixed time unit. Request urgency is determined based on the real-time requirements of the request; for example, the real-time requirements of data security requests are higher than those of data processing requests.

[0020] Step S1131: Classify the prior uncovered business function requests in the functional requirement class space. Divide the prior uncovered business function requests into different categories according to the business domain. Each category corresponds to a business function request type. Determine the functional description and applicable scenarios of each business function request type.

[0021] For business function requests that are not covered by prior knowledge in the functional requirement category space, they are subdivided by business domain. Requests such as encrypted data transmission and data access permission control are classified as data security requests, which are described as implementing security protection during data transmission and access, and are applicable to business scenarios involving sensitive data transmission. Requests such as data compression transmission and data format conversion are classified as data processing requests, which are described as optimizing and adapting transmitted data to different formats, and are applicable to business scenarios with limited data transmission bandwidth. Requests such as multi-protocol conversion and protocol version compatibility requests are classified as protocol adaptation requests, which are described as implementing conversion and compatibility processing between different communication protocols, and are applicable to business scenarios with heterogeneous communication between multiple devices.

[0022] Step S1132: Count the number of times each type of business function request appears per unit time in the prior record, determine the basis for dividing the request frequency based on the statistical results, associate the request frequency with the business function request type, and determine the typical request frequency range corresponding to different business function request types.

[0023] The frequency of each type of business function request in a unit of time was statistically analyzed in the prior record. For example, the frequency of security requests in each fixed time unit was statistically analyzed. Based on the results, it was found that the frequency of security requests was at a medium level; data processing requests were at a low level; and protocol adaptation requests were at a high level. Based on these statistical results, the criteria for classifying request frequencies were determined, dividing request frequencies into three levels: low, medium, and high. Then, each level was associated with the business function request type, determining that the typical frequency range for data security requests was medium, data processing requests were low, and protocol adaptation requests were high.

[0024] Step S1133: Analyze the real-time requirements of the business scenarios corresponding to each type of business function request, divide the urgency of requests into different urgency levels, associate the urgency levels with the business function request types, determine the default urgency level for each type of business function request, and each urgency level corresponds to different real-time requirements.

[0025] Analyzing the real-time requirements of each business function request type for the corresponding business scenario, the urgency of requests is categorized into three levels: urgent, moderate, and non-urgent. Data security requests, such as encrypted data transmission, involve data security and have high real-time requirements, corresponding to the urgent level, which requires a response within a short time after the request is sent. Protocol adaptation requests, such as multi-protocol conversion, have moderate real-time requirements, corresponding to the moderate level, requiring a response within a normal time. Data processing requests, such as data compression transmission, have low real-time requirements, corresponding to the non-urgent level, allowing for a longer response time. These levels are then associated with the business function request type to determine the default request urgency level for each type.

[0026] Step S1134: Establish a relationship table for business function request types, request frequency, and request urgency. The relationship table records the request frequency range and default request urgency for each type of business function request.

[0027] Create a relationship table, where each row records the request type for each business function, and the corresponding columns are filled with the request frequency range and default request urgency level. For example, the request frequency range for data security is medium, and the default request urgency level is urgent; the request frequency range for data processing is low, and the default request urgency level is non-urgent; the request frequency range for protocol adaptation is high, and the default request urgency level is moderate.

[0028] Step S1135: Based on the association table, set a trigger threshold for each type of business function request. When the frequency of actual business function requests exceeds the corresponding trigger threshold and the urgency level of the requests reaches the corresponding level, trigger the function requirement trigger condition.

[0029] Trigger thresholds are set for each type of business function request based on the relationship table. For data security requests, since the request frequency is medium, a corresponding trigger threshold is set. When the actual frequency of data security requests exceeds this threshold and the urgency level is urgent, the function request trigger condition is activated. For protocol adaptation requests, a corresponding trigger threshold is set. When the actual request frequency exceeds this value and the urgency level is moderate, the trigger condition is activated. For data processing requests, a corresponding trigger threshold is set. When the actual request frequency exceeds this value and the urgency level is non-urgent, the trigger condition is activated.

[0030] Step S1136: Integrate the classification results of business function request types, the association rules of request frequency, the level of request urgency, and the trigger threshold to form the conditional features of functional requirement triggering conditions.

[0031] The classification results of business function request types (such as data security, data processing, etc.), the association rules of request frequency (such as the frequency range corresponding to each type), the construction of request urgency levels (urgent, general, non-urgent and corresponding real-time requirements), and the set trigger thresholds are integrated to form a complete condition feature of the function requirement triggering conditions.

[0032] Step S114: Construct the condition features of the module resource triggering conditions based on the module resource class space. The module resource triggering conditions include free memory capacity, free computing resources and the number of free interfaces. The free memory capacity corresponds to the memory space not occupied by the communication module, the free computing resources correspond to the computing units not used by the communication module, and the number of free interfaces corresponds to the external docking interfaces not occupied by the communication module.

[0033] The conditional characteristics for triggering module resources are constructed based on the module resource class space. Free memory capacity refers to the currently unoccupied memory space of the communication module, which must be able to accommodate the code and running data of the functional modules to be loaded; free computing resources refer to the unused computing units in the module, which are used to process the computing tasks of the modules to be loaded; the number of free interfaces refers to the external interfaces on the module that are not connected to other devices or modules, used for connecting the modules to be loaded to external devices.

[0034] Step S115: Construct the conditional features of the external environment triggering conditions based on the external environment class space. The external environment triggering conditions include changes in communication signal strength, switching of network protocol type, and changes in the number of connected devices. The changes in communication signal strength correspond to fluctuations in signal receiving power. The switching of network protocol type corresponds to changes in the communication protocol used. The changes in the number of connected devices correspond to increases or decreases in the number of terminal devices connected to the communication module.

[0035] The external environment trigger conditions are constructed based on the external environment class space. Changes in communication signal strength are reflected by fluctuations in signal received power, such as a sudden drop or rise in signal received power from a stable state; network protocol type switching refers to a change in the protocol used by the module communication, such as switching from one common network protocol to another; changes in the number of connected devices refer to an increase or decrease in the number of external terminal devices that have established connections with this communication module.

[0036] Step S116: Integrate the conditional features of the functional requirement triggering conditions, the module resource triggering conditions, and the external environment triggering conditions to form the dynamic loading triggering condition space.

[0037] The conditional features of the completed functional requirement triggering conditions, module resource triggering conditions, and external environment triggering conditions are integrated, and all characteristic parameters of the three types of conditions are summarized to form a complete dynamic loading triggering condition space. This dynamic loading triggering condition space covers all kinds of conditional elements required to trigger functional expansion.

[0038] Step S117: Based on each trigger condition in the dynamically loaded trigger condition space, collect real-time operating data of the communication module, organize the real-time operating data and the external scene data according to the trigger condition category, and generate a trigger condition matching dataset. The real-time operating data includes the current business function request and the current resource occupancy status. At the same time, collect external scene data, which includes the current signal status, the current protocol type, and the current number of connected devices.

[0039] Based on the trigger conditions in the dynamically loaded trigger condition space, real-time operational data is collected through the module's built-in monitoring module. Current business function requests include encrypted data transmission requests (data security type) and multi-protocol conversion requests (protocol adaptation type) issued by the user; current resource occupancy status includes the current module's used memory capacity, the percentage of occupied computing resources, and the number of used interfaces, thereby calculating the free memory capacity, free computing resources, and the number of free interfaces. Simultaneously, external scene data is collected through the signal monitoring unit. Current signal status includes the current signal reception power and fluctuation; current protocol type refers to the communication protocol used by the current module; and the number of currently connected devices is the total number of external terminal devices currently connected to the module. The above real-time operational data and external scene data are organized into three categories of trigger conditions: functional requirements, module resources, and external environment, forming a trigger condition matching dataset.

[0040] Step S120: Select the compatible functional modules corresponding to the trigger condition matching dataset from the preset functional module library, and generate a set of compatible functional modules based on the functional requirement trigger condition matching function interface description information in the trigger condition matching dataset, the module resource trigger condition matching resource requirement information, and the external environment trigger condition matching scenario adaptation information.

[0041] The pre-set functional module library stores multiple functional modules for general communication terminal scenarios. Each module is associated with corresponding functional interface descriptions, resource requirements, and scenario adaptation information. Based on the triggering conditions and matching dataset, the adapted functional modules are sequentially filtered according to functional requirements, module resources, and external environmental conditions, ultimately generating a set of adapted functional modules.

[0042] Step S121: Load the preset functional module library. The preset functional module library stores multiple functional modules. Each functional module is associated with functional interface description information, resource requirement information, and scenario adaptation information. The functional interface description information includes the interface type and data interaction format provided by the module. The resource requirement information includes the memory capacity and computing resource ratio required for the module to run. The scenario adaptation information includes the signal strength range, protocol type, and number of connected devices applicable to the module.

[0043] A pre-defined functional module library is loaded through the storage access interface of the communication module. This library includes multiple functional modules such as an encrypted data transmission module, a multi-protocol conversion module, a data compression transmission module, and a data format conversion module. Taking the encrypted data transmission module as an example, its interface description information indicates that the interface type is a security interface, the data interaction format is a specific format, the resource requirements information includes the required memory capacity and computing resource ratio, the applicable signal strength range is medium to high signal reception power, the applicable protocol types include multiple common protocols, and the applicable number of connected devices is medium. Similarly, the multi-protocol conversion module's interface description information indicates that the interface type is a conversion interface, the data interaction format is another specific format, the resource requirements information includes the corresponding memory and computing resource requirements, the applicable signal strength range is wide, the applicable protocol types cover multiple mainstream protocols, and the applicable number of connected devices is relatively wide.

[0044] Step S122: Extract the first relevant data of the functional requirement triggering conditions from the triggering condition matching dataset, compare the first relevant data with the functional interface description information of each functional module, filter out candidate functional modules whose interface type matches the current business function request type, and generate a first candidate functional module set. The first relevant data includes the current business function request type, the current request frequency, and the current request urgency.

[0045] Extracting the first relevant data from the trigger condition matching dataset, the current business function request types are data security (encrypted data transmission request) and protocol adaptation (multi-protocol conversion request). The current request frequency shows a corresponding number of occurrences per unit time for both encrypted data transmission requests and multi-protocol conversion requests, with urgency levels of "urgent" and "moderate," respectively. Comparing this first relevant data with the functional interface descriptions of each module in the preset functional module library, the interface type of the encrypted data transmission module is security-related, matching the interface requirements of data security requests; the interface type of the multi-protocol conversion module is conversion-related, matching the interface requirements of protocol adaptation requests. These two modules are selected to generate the first candidate functional module set.

[0046] Step S123: Extract the second related data of the module resource triggering conditions from the triggering condition matching dataset, compare the second related data with the resource requirement information of each candidate functional module in the first candidate functional module set, filter out the candidate functional modules whose resource requirements do not exceed the current idle resources, and generate the second candidate functional module set. The second related data includes the current idle memory capacity, the current idle computing resources, and the current idle interface quantity.

[0047] Secondary relevant data is extracted from the trigger condition matching dataset. The current free memory capacity, current free computing resources, and current number of free interfaces are all known data. This data is compared with the resource requirements of the encrypted data transmission module and the multi-protocol conversion module in the first candidate functional module set. If the memory capacity, computing resource ratio, and number of interfaces required by the encrypted data transmission module do not exceed the current free resources, and the resource requirements of the multi-protocol conversion module also do not exceed the current free resources, then both modules are retained, generating the second candidate functional module set. If the resource requirements of any module exceed the current free resources, that module is eliminated, and only modules whose resource requirements meet the criteria are retained in the second candidate functional module set.

[0048] Step S124: Extract the third relevant data of the external environment triggering conditions from the triggering condition matching dataset, compare the third relevant data with the scenario adaptation information of each candidate functional module in the second candidate functional module set, filter out the candidate functional modules whose applicable scenarios include the current external environment state, and generate the third candidate functional module set. The third relevant data includes the current signal strength, the current protocol type, and the number of currently connected devices.

[0049] The third relevant data is extracted from the trigger condition matching dataset. The current signal strength is medium, the current protocol type is a common protocol, and the number of currently connected devices is medium. The above data is compared with the scenario adaptation information of each module in the second candidate functional module set. The encrypted data transmission module is applicable to a signal strength range of medium or above, the applicable protocol type includes the current protocol, the applicable number of connected devices is medium, and the current external environment is within its applicable scenario. If the multi-protocol conversion module is applicable to a wide range of signal strengths, the applicable protocol type covers the current protocol, the applicable number of connected devices is relatively wide, and the current external environment is also within its applicable scenario, then both of these modules are retained to generate the third candidate functional module set.

[0050] Step S125: Sort the candidate functional modules in the third candidate functional module set according to their matching degree. The sorting is based on the comprehensive result of the matching degree of functional interface, resource requirement, and scenario adaptation. Select a preset number of candidate functional modules that are ranked first.

[0051] Step S1251: Set evaluation dimensions for functional interface matching degree, resource requirement matching degree, and scenario adaptation matching degree respectively. The evaluation dimensions for functional interface matching degree include interface type matching rate and data format compatibility. The evaluation dimensions for resource requirement matching degree include memory requirement satisfaction rate and computing resource requirement satisfaction rate. The evaluation dimensions for scenario adaptation matching degree include signal strength adaptation rate and protocol type matching rate.

[0052] Evaluation dimensions are set for the three matching degrees. The evaluation dimensions for functional interface matching degree include interface type matching rate and data format compatibility. The interface type matching rate measures the degree of matching between the candidate module's interface type and the current request type, while the data format compatibility measures the compatibility between the module's data interaction format and the module's existing format. The evaluation dimensions for resource requirement matching degree include memory requirement satisfaction rate and computing resource requirement satisfaction rate, which respectively measure the matching between the module's memory requirements, computing resource requirements, and the current available resources. The evaluation dimensions for scenario adaptation matching degree include signal strength adaptation rate and protocol type matching rate, which respectively measure the matching between the current signal strength, protocol type, and the module's applicable scope.

[0053] Step S1252: Set a scoring standard for each evaluation dimension, and give a corresponding score based on the degree of fit between the candidate functional module and the trigger condition matching dataset. The scoring result reflects the matching situation under the evaluation dimension.

[0054] Specific scoring criteria are set for each evaluation dimension. For interface type matching rate, the highest score is given if the candidate module's interface type is completely consistent with the current business function request type; a medium score is given if they are basically consistent but have minor differences; and the lowest score is given if the differences are significant. For data format compatibility, the highest score is given if the module's data interaction format is completely consistent with the module's existing format; a medium score is given if compatibility can be achieved through simple format conversion; and the lowest score is given if compatibility requires complex modifications. For memory requirement satisfaction rate, the highest score is given if the candidate module's required memory capacity is significantly lower than the current available memory capacity; a medium score is given if it is slightly lower; and the lowest score is given if it is close to the current upper limit of available memory capacity. For computing resource requirement satisfaction rate, the highest score is given if the module's required computing resource ratio is significantly lower than the current available computing resource ratio; a medium score is given if it is slightly lower; and the lowest score is given if it is close to the current upper limit of available computing resource ratio. For signal strength adaptation rate, the highest score is given if the current signal strength is in the middle range of the module's applicable signal strength range; a medium score is given if it is in the edge range of the applicable range; and the lowest score is given if it is close to the critical value of the applicable range. Regarding the protocol type matching rate, the highest score is given if the current protocol type is completely consistent with the module's applicable protocol type; a medium score is given if the current protocol type is a module-compatible protocol type; and the lowest score is given if the module needs to extend its protocol to support the current protocol type.

[0055] Step S1253: Based on the core requirements of functional expansion, assign weights to the degree of functional interface matching, the degree of resource requirement matching, and the degree of scenario adaptation matching. The degree of functional interface matching has the highest weight, followed by the degree of resource requirement matching, and then the degree of scenario adaptation matching.

[0056] Based on the core requirements for expanding the functionality of communication modules in general communication terminals, the compatibility of functional interfaces directly determines whether the module can achieve the target business functions. Therefore, the weight of functional interface compatibility is set to the highest. The compatibility of resource requirements determines whether the module can operate stably on the module, and its weight is set to the second highest. The compatibility of scenario adaptation affects the module's operating performance, and its weight is set to the lowest. For example, the weight of functional interface compatibility is 50%, the weight of resource requirement compatibility is 30%, and the weight of scenario adaptation compatibility is 20%.

[0057] Step S1254: Based on the scores and corresponding weights of each evaluation dimension, calculate the comprehensive matching score of each candidate functional module. The comprehensive matching score is the sum of the products of the scores of each evaluation dimension and their corresponding weights.

[0058] For each candidate functional module, its scores are first obtained across six evaluation dimensions: interface type matching rate, data format compatibility, memory requirement fulfillment rate, computing resource requirement fulfillment rate, signal strength adaptation rate, and protocol type matching rate. Then, the average scores for interface type matching rate and data format compatibility are used as the functional interface matching score; the average scores for memory requirement fulfillment rate and computing resource requirement fulfillment rate are used as the resource requirement matching score; and the average scores for signal strength adaptation rate and protocol type matching rate are used as the scenario adaptation matching score. Finally, the overall matching score for the candidate functional module is obtained by multiplying the functional interface matching score by its weight, adding the resource requirement matching score multiplied by its weight, and adding the scenario adaptation matching score multiplied by its weight.

[0059] Step S1255: Sort the candidate functional modules in the third candidate functional module set from high to low according to the comprehensive matching score to form a candidate functional module sorting list.

[0060] The comprehensive matching scores of the encrypted data transmission module and the multi-protocol conversion module in the third set of candidate functional modules are compared. If the comprehensive matching score of the encrypted data transmission module is higher than that of the multi-protocol conversion module, the encrypted data transmission module is ranked first and the multi-protocol conversion module is ranked second, forming a candidate functional module ranking list; if the comprehensive matching score of the multi-protocol conversion module is higher, they are arranged in the reverse order.

[0061] Step S1256: Based on the actual expansion requirements of the communication module and the total amount of idle resources, determine the number of candidate functional modules to be selected, and select the candidate functional modules that are ranked first in the candidate functional module sorting list and whose quantity meets the preset number.

[0062] Based on the priority of the business functions that the communication module needs to implement and the total amount of idle resources, if the encrypted data transmission function is urgently needed and the idle resources can support the operation of two modules at the same time, then the selection quantity is determined to be two, and the top two encrypted data transmission modules and multi-protocol conversion modules are selected from the candidate functional module sorting list; if the idle resources can only support the operation of one module, then the selection quantity is determined to be one, and the first module in the sorting list is selected.

[0063] Step S130: Perform collaborative adaptation processing between each adaptation function module in the set of adaptation function modules and the communication module. Connect the existing interface of the communication module through the function interface description information, allocate idle resources of the communication module based on the resource requirement information, adjust the module operation parameters in combination with the scenario adaptation information, and generate collaborative adaptation results.

[0064] For each module in the set of adaptation function modules, interface docking, resource allocation and parameter adjustment are completed in sequence to ensure that each module can be adapted to the communication module and the current scenario. Finally, all processing results are integrated to form a collaborative adaptation result.

[0065] Step S131: Select an adaptation function module from the set of adaptation function modules, and extract the function interface description information of the adaptation function module. The function interface description information includes the interface type, data input and output format and interaction timing requirements.

[0066] First, select the encrypted data transmission module from the set of compatible functional modules. Extract its functional interface description information through the module information reading interface. The interface type is a security interface, the data input format is a specific plaintext data format, the data output format is the encrypted ciphertext data format, and the interaction timing requirement is that the encryption process must be completed and the ciphertext data must be output within a specified time after the data input.

[0067] Step S132: Collect the existing interface information of the communication module. The existing interface information includes the interface type, current data interaction format and idle status. Connect the functional interface description information of the adaptation function module with the existing interface information to determine the matching existing interface. If there is an incompatibility in the interface data interaction format, adjust the interface data format of the adaptation function module to be consistent with the existing interface.

[0068] The interface monitoring unit of the communication module collects existing interface information, including security interfaces and data transmission interfaces. One security interface is currently idle, and its data interaction format is a different, specific format. The functional interface description information of the encrypted data transmission module is compared with the information of this existing security interface. It is found that the interface types match, but the data interaction formats are incompatible. At this point, the module format conversion component is invoked to adjust the interface data input and output formats of the encrypted data transmission module to match the interaction format of the existing security interface, thus completing the interface integration.

[0069] Step S133: Extract the resource requirement information of the adaptation function module. The resource requirement information includes the required memory capacity, the required proportion of computing resources, and the required number of interfaces. Obtain the current idle resource data from the real-time operation data of the communication module. The current idle resource data includes the current idle memory capacity, the current idle computing resources, and the current idle number of interfaces. Allocate corresponding resources to the adaptation function module from the current idle resources according to the resource requirement information.

[0070] Extract the resource requirements of the encrypted data transmission module, including its required memory capacity, computing resource allocation, and number of interfaces. Obtain the current free memory capacity, current free computing resource allocation, and current number of free interfaces from the real-time operating data of the communication module. Based on the module's resource requirements, allocate the corresponding amount of memory space from the current free memory to the module, allocate the corresponding proportion of computing units from the current free computing resources to the module, and assign the completed security interfaces to the module for use.

[0071] Step S134: If multiple adaptation function modules compete for the same idle resource during resource allocation, resource allocation is performed based on the function priority of the adaptation function modules. The function priority is determined according to the urgency of the request in the function requirement triggering condition.

[0072] If, when allocating resources for the encrypted data transmission module and the multi-protocol conversion module, both require a certain idle computing unit, the functional priority is determined based on the urgency of the request in the functional requirement triggering conditions. The encrypted data transmission module's request urgency is urgent, while the multi-protocol conversion module's request urgency is moderate. Therefore, the encrypted data transmission module has a higher functional priority than the multi-protocol conversion module, and the idle computing unit is allocated to the encrypted data transmission module first, while other idle computing units are allocated to the multi-protocol conversion module. If no other idle computing units are available, the allocation will proceed after the encrypted data transmission module releases some computing resources.

[0073] Step S135: Extract the scene adaptation information of the adaptation function module. The scene adaptation information includes the applicable signal strength range, applicable protocol type and applicable number of connected devices. Collect the current external scene data and adjust the operating parameters of the adaptation function module according to the current external scene data. The operating parameters include signal receiving sensitivity, protocol adaptation parameters and data processing concurrency.

[0074] Extract the scenario adaptation information for the encrypted data transmission module. Its applicable signal strength range is medium to high, the applicable protocol type includes the protocol currently used by the module, and the applicable number of connected devices is medium. Collect current external scenario data: the current signal strength is medium, the current protocol type is the protocol used by the module, and the current number of connected devices is medium. Based on this data, adjust the module's operating parameters: adjust the signal receiving sensitivity to a medium level to match the current signal strength; set the protocol adaptation parameters to the value corresponding to the current protocol type; and adjust the data processing concurrency to a medium level based on the number of connected devices to ensure the module can handle encrypted data transmission requests from multiple devices simultaneously.

[0075] Step S136: After completing the collaborative adaptation of one adaptation function module, repeat the above steps of extracting the functional interface description information of the adaptation function module and adjusting the running parameters of the adaptation function module according to the current external scene data to process other adaptation function modules in the set of adaptation function modules, and record the interface docking results, resource allocation results and parameter adjustment results of each adaptation function module.

[0076] After completing the collaborative adaptation of the encrypted data transmission module, the multi-protocol conversion module is processed according to steps S131 to S135. The functional interface description information of the multi-protocol conversion module is extracted and interfaced with the existing conversion interfaces of the communication module; if the formats are incompatible, adjustments are made. Its resource requirement information is extracted, and corresponding resources are allocated from the currently available idle resources. Its operating parameters, including signal receiving sensitivity and protocol conversion rate, are adjusted based on the current external scenario data. Simultaneously, the interface interface connection results (such as the interface number and format adjustment status), resource allocation results (such as allocated memory capacity, computing resource ratio, and number of interfaces), and parameter adjustment results (such as the specific settings of each operating parameter) of both the encrypted data transmission module and the multi-protocol conversion module are recorded.

[0077] Step S137: Integrate the docking results, allocation results and adjustment results of all adaptation functional modules to generate collaborative adaptation results. The collaborative adaptation results include the adaptation details and overall adaptation status of each adaptation functional module.

[0078] The interface integration results, resource allocation results, and parameter adjustment results of the encrypted data transmission module and the multi-protocol conversion module are summarized to generate an adaptation details file for each module, recording in detail the processing information of each module during the adaptation process. Simultaneously, it is determined whether all modules have completed interface integration, resource allocation, and parameter adjustment, and whether the total allocated resources do not exceed the total idle resources of the communication module. If all conditions are met, the overall adaptation status is considered successful; if any module fails to complete adaptation or exceeds resource allocation limits, the overall adaptation status is considered failed, and the reason for the failure is indicated. The above information is then integrated to generate a collaborative adaptation result.

[0079] Step S140: Based on the collaborative adaptation results, dynamically inject the adaptation function module into the communication module's operating environment, construct the call link between the adaptation function module and the original functions of the communication module, the call link includes data interaction path, function execution priority sorting and exception transfer mechanism, and generate a function extension call architecture.

[0080] When the adaptation result is successful, the adaptation function module is injected into the operating environment of the communication module, and the calling relationship between the module and the original function is established to form a complete function extension calling architecture, ensuring that the extended function and the original function run together.

[0081] Step S141: Based on the interface docking results in the collaborative adaptation results, determine the docking node between each adaptation function module and the existing interface of the communication module, and inject the program code of each adaptation function module into the communication module's operating environment through the docking node, while maintaining the normal operation of the original functions of the communication module during the injection process.

[0082] Based on the interface docking results in the collaborative adaptation, the docking nodes for the encrypted data transmission module and the existing security interfaces of the communication module, as well as the docking nodes for the multi-protocol conversion module and the existing conversion interfaces, are determined. Through these docking nodes, the program code of both modules is injected into the communication module's runtime memory in batches. The injection process uses an incremental loading method, loading only a portion of the code at a time to avoid consuming excessive computing resources and ensure that the original data transmission, device connection, and other functions of the communication module remain unaffected and continue to operate normally.

[0083] Step S142: Collect the call relationship data of the original functions of the communication module. The call relationship data includes the call order, data transmission path and execution priority between the original functions. Associate the functional requirements of the adaptation function module with the call relationship of the original functions to determine the insertion position of the adaptation function module in the original call relationship.

[0084] The function call monitoring component of the communication module collects the call relationship data of the original functions, including basic data receiving, basic data sending, and device authentication. The call order is as follows: after device authentication, basic data receiving and basic data sending are called sequentially. The data transmission path is that the basic data receiving function passes the received data to the basic data sending function. The execution priority is: device authentication is the highest, followed by basic data receiving, and then basic data sending. The functional requirements of the encrypted data transmission module (encrypted data transmission) are associated with the original call relationship, determining its insertion position after basic data receiving and before basic data sending. Similarly, the functional requirements of the multi-protocol conversion module (protocol conversion) are associated with the original call relationship, determining its insertion position before basic data receiving. This module converts received data from different protocols into data supported by the module.

[0085] Step S143: Construct a data interaction path between the adaptation function module and the original function based on the insertion position. The data interaction path determines the source function of the data received by the adaptation function module and the target function of the data sent, and at the same time constructs the format and frequency of data interaction.

[0086] Based on the insertion position, a data interaction path is constructed. For the encrypted data transmission module, the source function for receiving data is the basic data receiving function, the target function for sending data is the basic data sending function, the data interaction format is the adjusted interface data format, and the interaction frequency is consistent with the interaction frequency of the basic data receiving and sending functions; that is, the basic data receiving function transmits data to the encrypted data transmission module once for each data received. For the multi-protocol conversion module, the source function for receiving data is the data sending function of an external device, the target function for sending data is the basic data receiving function, the data interaction format is a format compatible with both the external device and the basic data receiving function, and the interaction frequency is the frequency of data transmission by the external device.

[0087] Step S144: Based on the urgency of the request in the functional requirement triggering conditions and the execution priority of the original function, determine the execution priority of the adapted functional module, and integrate the execution priority of the adapted functional module with the execution priority of the original function to form a unified functional execution priority ranking.

[0088] Based on the urgency of requests in the functional requirement trigger conditions, the encrypted data transmission module has an urgent urgency, while the multi-protocol conversion module has a moderate urgency. Combining this with the execution priorities of existing functions, the execution priority of the encrypted data transmission module is determined to be higher than the basic data receiving and sending functions, but lower than the device authentication function; the execution priority of the multi-protocol conversion module is higher than the basic data receiving function, but lower than the encrypted data transmission module and the device authentication function. Integrating these priorities, a unified execution priority ranking is formed: device authentication function is the highest, followed by the encrypted data transmission module, then the multi-protocol conversion module, then the basic data receiving function, and finally the basic data sending function.

[0089] Step S145: Construct an exception transfer mechanism. When an exception occurs during the operation of the adaptation function module, the exception transfer mechanism transfers the function request of the adaptation function module to the original function with similar function in the communication module or other adaptation function modules, and records the exception type and transfer process.

[0090] Step S1451: Collect the possible exception types that may occur in the adaptation function module. The exception types include interface interaction failure, resource usage exceeding limits, and data processing errors. Construct corresponding exception identification features for each exception type. The exception identification features include error codes, log information, and running status parameters.

[0091] This module collects potential anomalies from the encrypted data transmission module and the multi-protocol conversion module, including interface interaction failures, resource usage exceeding limits, and data processing errors. It constructs anomaly identification features for interface interaction failures, including specific error codes, log information indicating interface connection timeouts, and runtime status parameters showing an disconnected interface. For resource usage exceeding limits, it constructs anomaly identification features, including corresponding error codes, log information indicating resource usage exceeding the threshold, and resource usage parameters. For data processing errors, it constructs anomaly identification features, including specific error codes, log information indicating incorrect data format, and runtime status parameters showing invalid data processing results.

[0092] Step S1452: Construct anomaly monitoring rules. The anomaly monitoring rules are constructed based on anomaly identification features. When information that matches the anomaly identification features appears in the running data of the adaptation function module, the anomaly monitoring rules are triggered, and it is determined that the operation of the adaptation function module is abnormal.

[0093] Anomaly monitoring rules are constructed based on anomaly identification features. For interface interaction failures, the rule is triggered when the running data of the adapted functional module contains a corresponding error code, the log information shows an interface connection timeout, and the interface status parameter is disconnected. For resource usage exceeding limits, the rule is triggered when the running data contains a corresponding error code, the log information shows a resource usage rate exceeding a threshold, and the resource usage rate parameter reaches a set value. For data processing errors, the rule is triggered when the running data contains a corresponding error code, the log information shows an incorrect data format, and the data processing result parameter is invalid. When any of the above rules are met, the adapted functional module is determined to have malfunctioned.

[0094] Step S1453: Collect information on existing functions and other adapted function modules with similar functions in the communication module. The information includes function description, interface type and current running status. Establish a similar function mapping table. The similar function mapping table records a list of similar functions corresponding to each adapted function module.

[0095] Collect information on existing functions and other compatible modules with similar capabilities within the communication module. If an existing function includes a simple data encryption function, its function description is basic data encryption processing, the interface type is a security interface, and its current operating status is normal. The multi-protocol conversion module and other protocol conversion-related modules currently have no similar functions. Establish a similar function mapping table, where the list of similar functions corresponding to the encrypted data transmission module is the simple data encryption function; the list of similar functions corresponding to the multi-protocol conversion module is empty.

[0096] Step S1454: When the anomaly monitoring rule is triggered, search the list of similar functions corresponding to the current anomaly adaptation function module based on the similar function mapping table, and filter the functions in the similar function list that are currently in normal operation.

[0097] If the encrypted data transmission module malfunctions, the anomaly monitoring rules are triggered. Based on the similar function mapping table, the corresponding list of similar functions, i.e., the simplified data encryption function, is searched. The current operating status of this function is checked; if it is normal, it is selected as a candidate transfer target; if it is malfunctioning, there is no candidate transfer target.

[0098] Step S1455: Based on the functional similarity ranking of similar functions and abnormal adaptation function modules, select the normal operation function with the highest similarity as the transfer target, and transfer the function request of the abnormal adaptation function module to the transfer target.

[0099] The similarity between the simplified data encryption function and the encrypted data transmission module was compared. Both have data encryption functions and are highly similar. The simplified data encryption function was selected as the transfer target. The function request originally sent to the encrypted data transmission module was transferred to the simplified data encryption function, which then completed the data encryption process.

[0100] Step S1456: Record the exception type, exception occurrence time, transfer target, and function operation status after transfer to form an exception transfer record, and add the exception transfer record to the exception transfer mechanism.

[0101] The exception type was recorded as an interface interaction failure, the time of occurrence was specified, the target of the transfer was a simple data encryption function, and the function's operation was normal after the transfer. This information was compiled into an exception transfer record and added to the exception transfer mechanism for future querying and analysis.

[0102] Step S146: Integrate the data interaction path, function execution priority sorting and exception transfer mechanism to form the call chain between the adapted function module and the original function, extract all call chains according to function category, and generate the function extension call architecture.

[0103] The established data interaction paths, function execution priority ranking, and exception transfer mechanisms are integrated to form a complete call chain. This links the data interaction paths between the encrypted data transmission module, the multi-protocol conversion module, and existing functions, along with a unified function execution priority ranking and exception transfer mechanisms for each module. Specifically, the call chain for the encrypted data transmission module includes its data interaction paths with the basic data receiving and sending functions, its position in the overall execution priority, and the corresponding exception transfer rules. Similarly, the call chain for the multi-protocol conversion module includes its data interaction paths with the external device data sending and basic data receiving functions, its position in the execution priority, and the corresponding exception transfer rules.

[0104] Next, all call chains are extracted according to functional categories. Call chains for encrypted data transmission modules involving data security functions are categorized as data security call chains, and call chains for multi-protocol conversion modules involving protocol conversion functions are categorized as protocol adaptation call chains. These categorized call chains are then logically organized to form a functional extension call architecture that includes information such as functional category, module name, associated original functions, data flow, execution priority, and exception handling methods.

[0105] Step S150: Based on the functional extension call architecture, collect the operation interaction data of the adapted functional module and the original function of the communication module, extract the descriptive information of the operation process, resource consumption and scene response effect of the extended function, and generate the functional extension operation diagram of the communication module.

[0106] Based on the functional expansion call architecture, the system continuously collects operational data from the adapted functional modules and the original functions, extracts key descriptive information, and presents the overall operational status after functional expansion in a visual way, forming a functional expansion operation diagram.

[0107] Step S151: Based on the data interaction path in the function extension call architecture, collect real-time data interaction records between the adapted function module and the original function. The real-time data interaction records include data sending function, data receiving function, data content and interaction time.

[0108] Based on the data interaction path defined in the functional extension call architecture, the data flow monitoring component of the communication module collects real-time data interaction records between the encrypted data transmission module, the multi-protocol conversion module, and the original functions. For example, the record of the multi-protocol conversion module receiving data from the external device data transmission function includes the following: the data transmission function is the external device data transmission function; the data reception function is the multi-protocol conversion module; the data content is the protocol data transmitted by the external device; and the interaction time is the specific moment of data reception. The record of the multi-protocol conversion module sending converted data to the basic data reception function includes the following: the data transmission function is the multi-protocol conversion module; the data reception function is the basic data reception function; the data content is the converted standard protocol data; and the interaction time is the specific moment of data transmission. The records of the encrypted data transmission module receiving data from the basic data reception function and sending encrypted data to the basic data transmission function also include the above-mentioned fields.

[0109] Step S152: Extract the data flow from the real-time data interaction record, analyze the data transmission process between the adapted functional module and the original function in chronological order, and extract the operation flow description information of the extended function in combination with the function execution priority sorting. The operation flow description information includes the function execution order, data interaction nodes and execution duration.

[0110] The data flow is extracted from the collected real-time data interaction records. Following the chronological order of interaction time, the complete data transmission process is traced from the external device data sending function to the multi-protocol conversion module, then to the basic data receiving function, followed by the encrypted data transmission module for encryption, and finally back to the basic data sending function. Based on a unified function execution priority ranking, the execution order of each function is determined as follows: device authentication function executes first, followed by the encrypted data transmission module, the multi-protocol conversion module, the basic data receiving function, and the basic data sending function. During this process, the data interaction nodes between the multi-protocol conversion module and the external device data sending and basic data receiving functions, as well as the data interaction nodes between the encrypted data transmission module and the basic data receiving and basic data sending functions, are marked. Simultaneously, the time interval from receiving data to processing and sending data for each function is calculated as the execution duration of each function. The function execution order, data interaction nodes, and execution duration are integrated to form the operational flow description information of the extended functions.

[0111] Step S153: Collect real-time data on resource usage of the communication module, statistically analyze resource usage changes at time intervals, and extract descriptive information on resource usage. The real-time data on resource usage includes the memory capacity, computing resources, and number of interfaces occupied by the adaptation function module and the original function.

[0112] The resource monitoring module of the communication module collects real-time resource usage data, which is broken down into the memory capacity, computing resource ratio, and number of interfaces used by the encrypted data transmission module, the multi-protocol conversion module, and each existing function. At fixed time intervals, the resource usage data is statistically analyzed, recording the changes in resource usage values ​​for each module and existing function within each time interval. For example, whether the memory capacity used by the encrypted data transmission module increased compared to the previous interval, or whether the computing resource ratio used by the multi-protocol conversion module fluctuated. Based on the statistical results, descriptive information on resource usage is extracted, covering the peak, average, and trend of resource usage for each module and existing function.

[0113] Step S154: Collect external scene data and scene response data of the adapted functional modules, associate the scene response data with the external scene data, analyze the response effect of the adapted functional modules under different external scenes, and extract scene response effect description information. The scene response data includes response latency, data processing success rate and functional coverage.

[0114] External scene data is continuously collected through the signal monitoring unit, including real-time changes in communication signal strength, network protocol type, and the number of connected devices. Simultaneously, scene response data is collected through the built-in monitoring components of the adaptation function modules. Response latency is the time interval between the module receiving a data request and returning a processing result; data processing success rate is the ratio of the number of successfully processed data requests to the total number of data requests; and functional coverage is the range of connected devices that the module can normally serve. Scene response data is correlated with corresponding external scene data. For example, when communication signal strength decreases, the system analyzes whether the response latency of the encrypted data transmission module increases and whether the data processing success rate decreases; when the number of connected devices changes, the system analyzes whether the functional coverage of the multi-protocol conversion module adjusts. Based on the correlation analysis results, scene response effect description information is extracted to illustrate the response performance of each adaptation function module under different external scene parameters.

[0115] Step S155: Visually map the process description information, resource usage description information, and scene response effect description information according to the structure of the function extension call architecture. Use different graphic elements to represent the adapted function modules, original functions, and data interaction paths, and use colors to represent function execution priority and resource usage status.

[0116] Based on the hierarchical and logical structure of the functional extension call architecture, the descriptions of the execution flow, resource consumption, and scene response effects are visualized and mapped. Different graphical elements are used to distinguish between the adapted functional modules and the original functions; for example, rectangles represent the original functions, and rounded rectangles represent the adapted functional modules. Arrowed line segments represent data interaction paths, with the arrow direction indicating the data flow. Different colors are used to indicate the execution priority of functions; for example, the highest priority device authentication function is represented by a dark color, and the lower priority basic data sending function is represented by a light color. Simultaneously, color variations indicate resource consumption status; for example, the higher the percentage of computing resources used by a module, the darker the corresponding graphic color. Furthermore, key information such as module name, execution duration, resource consumption value, and response latency are labeled next to the graphical elements.

[0117] Step S156: Add diagram description information, which explains the meaning of graphic elements, color identification rules and data sources, and integrates the visualization mapping results and diagram description information to generate a communication module function extension operation diagram.

[0118] The visualization includes explanatory text explaining the functional types represented by each graphic element, the execution priority levels and resource consumption standards corresponding to different colors, and the data sources (e.g., resource consumption data from the resource monitoring module and scene response data from the module's built-in monitoring components). The visualization is then integrated with the explanatory text to ensure a one-to-one correspondence between the information and the graphics, facilitating viewer comprehension. Finally, a complete extended operation diagram of the communication module's functions is generated, visually demonstrating the operational flow, dynamic resource consumption, and scene response effects of the extended functions.

[0119] Based on the same inventive concept, please refer to Figure 2 This paper shows a schematic block diagram of a communication module function extension system 100 for performing the above-described inspection video stream processing method, which is dynamically loaded by the application according to an embodiment of this application. The communication module function extension system 100 may include a communication unit 110, a machine-readable storage medium 120, and a processor 130.

[0120] In this embodiment, both the machine-readable storage medium 120 and the processor 130 are located within the application-dynamically loaded communication module function extension system 100 and are separately configured. However, it should be understood that the machine-readable storage medium 120 may also be independent of the application-dynamically loaded communication module function extension system 100 and may be accessed by the processor 130 via a bus interface. Alternatively, the machine-readable storage medium 120 may also be integrated into the processor 130 and may communicate and interact with external systems through the communication unit 110.

[0121] The processor 130 is the control center of the dynamically loaded communication module function expansion system 100. It connects to various parts of the system via various interfaces and lines. By running or executing software programs and / or modules stored in the machine-readable storage medium 120, and by calling data stored in the machine-readable storage medium 120, it executes various functions and processes data of the dynamically loaded communication module function expansion system 100, thereby providing overall monitoring of the system. Optionally, the processor 130 may include one or more processing cores; for example, the processor 130 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor. The machine-readable storage medium 120 stores machine-executable instructions for executing the scheme of this application, and the processor 130 executes the machine-executable instructions stored in the machine-readable storage medium 120 to implement the inspection video stream processing method provided in the aforementioned method embodiments.

[0122] It should be noted that, in order to simplify the description of the present invention and thus help to understand one or more embodiments of the invention, multiple features may sometimes be grouped into one embodiment, drawing or description thereof in the foregoing description of the embodiments of the present invention.

Claims

1. A method for extending the functionality of a communication module using dynamic loading, characterized in that, The method includes: A dynamic loading trigger condition space is determined. Based on the dynamic loading trigger condition space, real-time operating data of the communication module and external scene data are collected to generate a trigger condition matching dataset. The dynamic loading trigger condition space includes functional requirement trigger conditions, module resource trigger conditions and external environment trigger conditions. Functional requirement trigger conditions correspond to service function requests not covered by the communication module. Module resource trigger conditions correspond to the idle resource threshold of the communication module. External environment trigger conditions correspond to communication scene change signals. Select the appropriate functional modules from the preset functional module library that match the trigger condition matching dataset, and generate a set of appropriate functional modules based on the functional requirement trigger condition matching function interface description information in the trigger condition matching dataset, the module resource trigger condition matching resource requirement information, and the external environment trigger condition matching scenario adaptation information. Each adaptation module in the set of adaptation modules is adapted in collaboration with the communication module. The existing interface of the communication module is connected through the functional interface description information. Idle resources of the communication module are allocated based on the resource requirement information. The module operation parameters are adjusted in combination with the scenario adaptation information to generate a collaborative adaptation result. Based on the collaborative adaptation results, the adaptation function module is dynamically injected into the communication module's operating environment, and a call chain between the adaptation function module and the original function of the communication module is constructed to generate a function extension call architecture. The call chain includes a data interaction path, function execution priority sorting, and an exception transfer mechanism. Based on the aforementioned functional extension call architecture, the operation interaction data of the adapted functional modules and the original functions of the communication module are collected, and the descriptive information of the operation process, resource consumption and scene response effect of the extended functions are extracted to generate the communication module functional extension operation diagram.

2. The method for expanding the functionality of a communication module by dynamic loading according to claim 1, characterized in that, The process of determining the dynamic loading trigger condition space, collecting real-time operating data of the communication module and external scene data based on the dynamic loading trigger condition space, and generating a trigger condition matching dataset includes: Collect prior function extension records of communication modules, and extract the feature space that triggers function extensions from the prior function extension records. The feature space includes prior uncovered service function requests, prior module idle resource status and prior communication scenario change information. The feature space is classified into the functional requirement space, the prior uncovered service function request is classified into the module resource space, and the prior communication scenario change information is classified into the external environment space. Based on the functional requirement class space, the condition features for triggering functional requirements are constructed. The triggering conditions for functional requirements include the business function request type, request frequency, and request urgency. The business function request type corresponds to the category of business functions that are not covered. The request frequency corresponds to the number of times the same request occurs per unit time. The request urgency corresponds to the real-time requirement of the request. Based on the module resource class space, the condition features for triggering module resources are constructed. The module resource triggering conditions include free memory capacity, free computing resources, and the number of free interfaces. The free memory capacity corresponds to the memory space not occupied by the communication module, the free computing resources correspond to the computing units not used by the communication module, and the number of free interfaces corresponds to the external interfaces not occupied by the communication module. Based on the external environment class space, the condition features of the external environment triggering conditions are constructed. The external environment triggering conditions include changes in communication signal strength, switching of network protocol type, and changes in the number of connected devices. The changes in communication signal strength correspond to fluctuations in signal receiving power. The switching of network protocol type corresponds to changes in the communication protocol used. The changes in the number of connected devices correspond to increases or decreases in the number of terminal devices connected to the communication module. The conditional features of the functional requirement triggering conditions, the module resource triggering conditions, and the external environment triggering conditions are integrated to form the dynamic loading triggering condition space; Based on the trigger conditions in the dynamically loaded trigger condition space, real-time operation data of the communication module is collected. The real-time operation data and the external scene data are organized according to the trigger condition category to generate a trigger condition matching dataset. The real-time operation data includes the current business function request and the current resource occupancy status. At the same time, external scene data is collected, which includes the current signal status, the current protocol type, and the number of currently connected devices.

3. The method for expanding the functionality of a communication module by dynamic loading according to claim 2, characterized in that, The conditional features for constructing functional requirement triggering conditions based on the functional requirement class space include: Classify the prior uncovered business function requests in the functional requirement class space, divide the prior uncovered business function requests into different categories according to business domain, each category corresponds to a business function request type, and determine the functional description and applicable scenarios of each business function request type. The number of times each type of business function request appears per unit time in the prior record is counted. Based on the statistical results, the criteria for dividing the request frequency are determined. The request frequency is associated with the business function request type to determine the typical request frequency range corresponding to different business function request types. Analyze the real-time requirements of the business scenarios corresponding to each type of business function request, divide the request urgency into different request urgency levels, associate the request urgency levels with the business function request types, determine the default request urgency level corresponding to each type of business function request, and each request urgency level corresponds to different real-time requirements; Establish a relationship table for business function request types, request frequencies, and request urgency. The relationship table records the request frequency range and default request urgency for each type of business function request. Based on the aforementioned association table, a trigger threshold is set for each type of business function request. When the frequency of actual business function requests exceeds the corresponding trigger threshold and the urgency level of the requests reaches the corresponding level, the function requirement trigger condition is triggered. The classification results of business function request types, the association rules of request frequency, the construction of request urgency levels and trigger thresholds are integrated to form the conditional features of function requirement triggering conditions.

4. The method for expanding the functionality of a communication module by dynamic loading according to claim 1, characterized in that, The step involves selecting compatible functional modules from a preset functional module library that correspond to the trigger condition matching dataset, generating a set of compatible functional modules based on the functional requirement trigger condition matching function interface description information in the trigger condition matching dataset, the module resource trigger condition matching resource requirement information, and the external environment trigger condition matching scenario adaptation information. This set includes: Load a preset functional module library, which stores multiple functional modules. Each functional module is associated with functional interface description information, resource requirement information, and scenario adaptation information. The functional interface description information includes the interface type and data interaction format provided by the module. The resource requirement information includes the memory capacity and computing resource ratio required for the module to run. The scenario adaptation information includes the signal strength range, protocol type, and range of connected devices applicable to the module. Extract the first relevant data of the functional requirement triggering conditions from the triggering condition matching dataset, compare the first relevant data with the functional interface description information of each functional module, filter out the candidate functional modules whose interface type matches the current business function request type, and generate the first candidate functional module set. The first relevant data includes the current business function request type, the current request frequency, and the current request urgency. The second related data of the module resource triggering conditions is extracted from the triggering condition matching dataset. The second related data is compared with the resource requirement information of each candidate functional module in the first candidate functional module set. Candidate functional modules whose resource requirements do not exceed the current idle resources are selected to generate the second candidate functional module set. The second related data includes the current idle memory capacity, the current idle computing resources and the current idle interface quantity. The third relevant data of external environment triggering conditions is extracted from the triggering condition matching dataset. The third relevant data is compared with the scenario adaptation information of each candidate functional module in the second candidate functional module set. Candidate functional modules whose applicable scenarios include the current external environment state are selected, and a third candidate functional module set is generated. The third relevant data includes the current signal strength, the current protocol type and the number of currently connected devices. The matching degree of each candidate functional module in the third candidate functional module set is sorted. The sorting is based on the comprehensive result of the matching degree of functional interface, resource requirement, and scenario adaptation. A preset number of candidate functional modules with the highest ranking are selected. The selected candidate functional modules are organized to form a set of adapted functional modules.

5. The method for expanding the functionality of a communication module by dynamic loading according to claim 4, characterized in that, The matching degree ranking of each candidate functional module in the third candidate functional module set is based on a comprehensive result of the matching degree of functional interface, resource requirement, and scenario adaptation. A predetermined number of candidate functional modules with the highest ranking are selected, including: Evaluation dimensions are set for the degree of matching of functional interfaces, the degree of matching of resource requirements, and the degree of matching of scenario adaptation. The evaluation dimensions for the degree of matching of functional interfaces include interface type matching rate and data format compatibility. The evaluation dimensions for the degree of matching of resource requirements include memory requirement satisfaction rate and computing resource requirement satisfaction rate. The evaluation dimensions for the degree of matching of scenario adaptation include signal strength adaptation rate and protocol type matching rate. A scoring standard is set for each evaluation dimension, and a corresponding score is given based on the degree of fit between the candidate functional module and the dataset matching the triggering conditions. The scoring result reflects the matching situation under that evaluation dimension. Based on the core requirements of functional expansion, weights are assigned to the degree of matching of functional interfaces, the degree of matching of resource requirements, and the degree of matching of scenario adaptation. The degree of matching of functional interfaces has the highest weight, followed by the degree of matching of resource requirements, and then the degree of matching of scenario adaptation. Based on the scores and corresponding weights of each evaluation dimension, a comprehensive matching score is calculated for each candidate functional module. The comprehensive matching score is the sum of the products of the scores of each evaluation dimension and their corresponding weights. The candidate functional modules in the third candidate functional module set are sorted from high to low according to the comprehensive matching score to form a sorted list of candidate functional modules; Based on the actual expansion requirements of the communication module and the total amount of idle resources, determine the number of candidate functional modules to be selected, and select the candidate functional modules that are ranked first in the candidate functional module sorting list and whose quantity meets the preset number.

6. The method for expanding the functionality of a communication module by dynamic loading according to claim 1, characterized in that, The process involves coordinating and adapting each adaptation module in the set of adaptation modules with the communication module, connecting to the existing interfaces of the communication module through the functional interface description information, allocating idle resources of the communication module based on the resource requirement information, adjusting the module operating parameters in conjunction with the scenario adaptation information, and generating a coordinating adaptation result, including: Select an adaptation function module from the set of adaptation function modules, and extract the function interface description information of the adaptation function module. The function interface description information includes the interface type, data input and output format and interaction timing requirements. Collect existing interface information of the communication module, which includes interface type, current data interaction format and idle state. Connect the functional interface description information of the adaptation module with the existing interface information to determine the matching existing interface. If there is an incompatibility in the interface data interaction format, adjust the interface data format of the adaptation module to be consistent with the existing interface. Extract the resource requirement information of the adaptation function module. The resource requirement information includes the required memory capacity, the required proportion of computing resources, and the required number of interfaces. Obtain the current idle resource data from the real-time operation data of the communication module. The current idle resource data includes the current idle memory capacity, the current idle computing resources, and the current idle number of interfaces. Allocate corresponding resources to the adaptation function module from the current idle resources according to the resource requirement information. If multiple adaptation function modules compete for the same available resource during resource allocation, resource allocation is performed based on the function priority of the adaptation function modules. The function priority is determined according to the urgency of the request in the function requirement triggering conditions. Extract the scene adaptation information of the adaptation function module. The scene adaptation information includes the applicable signal strength range, applicable protocol type and applicable number of connected devices. Collect the current external scene data and adjust the operating parameters of the adaptation function module according to the current external scene data. The operating parameters include signal receiving sensitivity, protocol adaptation parameters and data processing concurrency. After completing the collaborative adaptation of one adaptation module, repeat the steps of extracting the functional interface description information of the adaptation module and adjusting the running parameters of the adaptation module according to the current external scene data to process other adaptation modules in the set of adaptation modules, and record the interface docking results, resource allocation results and parameter adjustment results of each adaptation module. The docking results, allocation results, and adjustment results of all adapted functional modules are integrated to generate a collaborative adaptation result, which includes the adaptation details and overall adaptation status of each adapted functional module.

7. The method for expanding the functionality of a communication module by dynamic loading according to claim 1, characterized in that, Based on the collaborative adaptation results, the adaptation function module is dynamically injected into the communication module's operating environment, a call chain between the adaptation function module and the original functions of the communication module is constructed, and a function extension call architecture is generated, including: Based on the interface docking results in the collaborative adaptation results, the docking node between each adaptation function module and the existing interface of the communication module is determined. The program code of each adaptation function module is injected into the communication module's operating environment through the docking node. During the injection process, the normal operation of the original functions of the communication module is maintained. Collect the call relationship data of the original functions of the communication module. The call relationship data includes the call order, data transmission path and execution priority between the original functions. Associate the functional requirements of the adaptable function module with the call relationship of the original functions to determine the insertion position of the adaptable function module in the original call relationship. Based on the insertion position, a data interaction path is constructed between the adaptation function module and the original function. The data interaction path determines the source function for receiving data and the target function for sending data in the adaptation function module, and at the same time, the format and frequency of data interaction are constructed. Based on the urgency of the requests in the functional requirement triggering conditions and the execution priority of the original functions, the execution priority of the adapted functional modules is determined, and the execution priority of the adapted functional modules is integrated with the execution priority of the original functions to form a unified functional execution priority ranking. An exception transfer mechanism is constructed. When an exception occurs during the operation of the adaptation function module, the exception transfer mechanism transfers the function request of the adaptation function module to the original function with similar function in the communication module or other adaptation function modules, and records the exception type and transfer process. The data interaction path, function execution priority sorting, and exception transfer mechanism are integrated to form a call chain that adapts to the functional modules and the original functions. All call chains are extracted according to function categories to generate a function extension call architecture.

8. The method for expanding the functionality of a communication module by dynamic loading according to claim 7, characterized in that, The aforementioned exception transfer mechanism, when an adaptation function module encounters an error, transfers the function request of that adaptation function module to an existing function in the communication module with similar functionality or other adaptation function modules. Simultaneously, it records the exception type and the transfer process, including: Collect the possible exception types that may occur in the adaptation function module. The exception types include interface interaction failure, resource consumption exceeding the limit, and data processing error. Construct corresponding exception identification features for each exception type. The exception identification features include error code, log information, and running status parameters. An anomaly monitoring rule is constructed based on anomaly identification features. When information matching the anomaly identification features appears in the running data of the adaptation function module, the anomaly monitoring rule is triggered, and it is determined that the operation of the adaptation function module is abnormal. Collect information on existing functions and other adaptable function modules with similar functions in the communication module. The information includes function description, interface type and current running status. Establish a similar function mapping table. The similar function mapping table records a list of similar functions corresponding to each adaptable function module. When an anomaly monitoring rule is triggered, the similar function list corresponding to the current anomaly adaptation function module is searched based on the similar function mapping table, and the functions in the similar function list that are currently in normal operation are filtered. Based on the functional similarity ranking of similar functions and abnormal adaptation function modules, the normal operation function with the highest similarity is selected as the transfer target, and the function requests of the abnormal adaptation function module are transferred to the transfer target. Record the exception type, exception occurrence time, transfer target, and functional operation status after transfer to form an exception transfer record, and add the exception transfer record to the exception transfer mechanism.

9. The method for expanding the functionality of a communication module by dynamic loading according to claim 1, characterized in that, Based on the aforementioned functional extension calling architecture, the system collects operational interaction data between the adapted functional modules and the original functions of the communication module, extracts descriptive information on the extended function's operational flow, resource consumption, and scene response effects, and generates a communication module functional extension operation diagram, including: Based on the data interaction path in the functional extension call architecture, real-time data interaction records between the adapted functional modules and the original functions are collected. The real-time data interaction records include data sending function, data receiving function, data content and interaction time. Data flow is extracted from real-time data interaction records. The data transmission process between the adapted functional modules and the original functions is analyzed in chronological order. Combined with the function execution priority sorting, the operation flow description information of the extended functions is extracted. The operation flow description information includes the function execution order, data interaction nodes and execution duration. Collect real-time data on resource usage of the communication module, statistically analyze changes in resource usage at time intervals, and extract descriptive information on resource usage. The real-time data on resource usage includes the memory capacity, computing resources, and number of interfaces occupied by the adaptive functional module and the original function. Collect external scene data and scene response data of the adapted functional modules, associate the scene response data with the external scene data, analyze the response effect of the adapted functional modules under different external scenes, and extract scene response effect description information. The scene response data includes response latency, data processing success rate and functional coverage. The description information of the operation process, resource usage, and scene response effect are visualized and mapped according to the structure of the function extension call architecture. Different graphic elements are used to represent the adapted functional modules, original functions, and data interaction paths, and colors are used to represent the function execution priority and resource usage status. Add diagram description information, which explains the meaning of graphic elements, color coding rules, and data sources. Integrate the visualization mapping results and diagram description information to generate a functional extension operation diagram of the communication module.

10. A communication module function expansion system using dynamic loading, characterized in that, include: processor; A machine-readable storage medium for storing machine-executable instructions of the processor; The processor is configured to execute the application-dynamically loaded communication module function extension method according to any one of claims 1 to 9 by executing the machine-executable instructions.

Images