Hardware resource sharing method and system based on an energy controller

Abstract

The present invention discloses a hardware resource sharing method and system based on an energy controller. The method mainly includes constructing a hardware resource management module, and constructing an access request queue and a listening request queue adapted thereto based on the hardware resources; the hardware resource management module receives an access request or a listening request sent by a service software unit for at least a certain hardware resource; the hardware resource management module inserts the access request and the listening request into the access request queue and the listening request queue corresponding to the hardware resource; access and listen to the corresponding hardware resources in sequence based on the access request queue and the listening request queue, and return the data to the service software unit. By constructing a hardware resource management module, the efficiency of resource sharing is improved, and the problems of low internal resource utilization rate and slow processing speed in the prior art are solved.

Description

Technical Field

[0001] The present invention relates to an energy controller, especially to the technology of optimizing resources of the energy controller. Background Art

[0002] The energy controller is a core device of the power grid, with functions such as data acquisition, intelligent fee control, clock synchronization, accurate metering, orderly charging, energy consumption management, loop status inspection, household-transformer relationship identification, and power outage event reporting. Due to the industry's planning and development trends, the application program (APP) deployment of the energy controller has become an important way at present and in the future. With the expansion of business, more and more APPs need to use devices such as serial ports and Bluetooth. Due to the characteristics of the hardware devices themselves, when the current APP uses a hardware device, it will monopolize one device. If other APPs want to use the same hardware, an additional device needs to be added. However, it is relatively easy to add APPs, and adding one APP means adding one device, resulting in huge overhead.

[0003] The contradiction between the growing number of APPs and the limited hardware resources is becoming increasingly fierce, and the demand for the energy controller to achieve hardware resource sharing is more urgent. At present, there is no method for the energy controller to overall manage the hardware resources. Therefore, it is urgent to propose a hardware resource sharing method based on the energy controller to meet the needs of more and more business software for hardware resources without adding hardware. Summary of the Invention

[0004] Object of the Invention: To provide a hardware resource sharing method based on the energy controller to solve the above problems existing in the prior art. And based on the above resource sharing method, to provide a system for implementing the above method.

[0005] Technical Solution: The hardware resource sharing method based on the energy controller includes:

[0006] S1. Construct a hardware resource management module, and based on the hardware resources, construct an access request queue and a listening request queue adapted to it;

[0007] S2. The hardware resource management module receives an access request or a listening request sent by a business software unit for at least a certain hardware resource;

[0008] S3. The hardware resource management module inserts the access request and the listening request into the access request queue and the listening request queue corresponding to the hardware resource;

[0009] S4. Based on the access request queue and the listening request queue, access and listen to the corresponding hardware resources in sequence, and return the data to the business software unit.

[0010] According to one aspect of the present application, step S1 specifically includes:

[0011] S11. Based on the statistically used frequency of the hardware resources, divide the hardware resources into predetermined types, and assign corresponding hardware resource weights to each predetermined type of hardware resource;

[0012] Based on the statistically business software work process, split the functions of the business software into several process sub-units, and count the total frequency of occurrence of each process sub-unit in a predetermined working scenario;

[0013] S12. Construct an access request queue with no less than the total number of hardware resources and a listening request queue with no less than the total number of hardware resources; and assign queue weights to the access request queue and the listening request queue based on the hardware resource weights and the total frequency of each process sub-unit, and configure the access request queue and the listening request queue to be arranged in descending order of the queue weights;

[0014] S13. Divide storage resources for each access request queue and listening request queue based on the queue weights.

[0015] According to one aspect of the present application, step S11 further includes:

[0016] Step S111. For each functional business work process of each business software unit, construct a workflow vector diagram based on the process sub-units; compare the workflow vector diagrams of each functional business work process to find whether there are the same process sub-units. If so, mark the process sub-unit as a shareable process sub-unit.

[0017] According to one aspect of the present application, it further includes step S112. Calculate the total weight of the shareable process sub-units, count the number of shareable process sub-units in each access request queue and listening request queue in a typical scenario, and calculate the resource usage proportion of each shareable process sub-unit.

[0018] The resource usage proportion w = (the typical time of the shareable process sub-unit × the total weight of the shareable process sub-unit) / (the sum of the products of the typical time of each process sub-unit in the request or listening request queue and its weight).

[0019] According to one aspect of the present application, it further includes step S113.

[0020] Based on the typical working scenario, calculate the time of each access request queue and listening request queue in turn in the order of descending queue weight and descending resource usage proportion of the process sub-units, and calculate the total time of the access request queue and the total time of the listening request queue.

[0021] Switch the working scenario, adjust the queue weight order or the arrangement order of the resource usage ratio of the process subunits, recalculate the total time of the access request queue, and monitor the total time of the request queue;

[0022] Loop the above process until the total time of the access request queue and the total time of the monitoring request queue in each working scenario meet the expected values.

[0023] According to one aspect of the present application, the step S2 further includes:

[0024] S21. After the hardware resource management module receives an access request or a monitoring request for at least a certain hardware resource sent by the service software unit, for each process subunit of the service software unit, traverse the access request queue or the monitoring request queue corresponding to the hardware resource to find whether there is the same process subunit. If there is, recalculate the weight of the same process subunit, refresh the assignment, and at the same time, establish a pointer pointing to the service software unit. After the hardware resource management module accesses or monitors the hardware resource based on the same process subunit, the data is returned to the service software unit based on the above pointer;

[0025] If not, proceed to the next step;

[0026] S22. Insert them into the corresponding access request queue or monitoring request queue according to the weights of the current process subunits.

[0027] According to one aspect of the present application, it further includes step 5:

[0028] Upload the workflow vector diagram to the edge service terminal according to a predetermined time period and format.

[0029] Calculate the total time of the access request queue and the total time of the monitoring request queue under the current sorting. After adjusting the sorting, calculate the total time of the access request queue and the total time of the monitoring request queue under each sorting, and send the sorting with the least total time back to the hardware resource management module, and refresh each access request queue and monitoring request queue.

[0030] According to one aspect of the present application, it further includes step 6:

[0031] S61. Each energy controller sends the sorting and the corresponding total time of each access request queue and monitoring request queue within a predetermined period to the edge service terminal.

[0032] The edge service terminal counts the total time under different sortings, takes the total time as the optimization goal, finds the relatively optimal sorting, and sends it to each energy controller to be written into the hardware resource management module.

[0033] S62. Each energy controller sends the business software unit, the corresponding process subunit, and the workflow vector diagram within a predetermined period to the edge service terminal.

[0034] The edge service terminal calculates the total time used for the workflow vector diagram corresponding to each functional service workflow in each business software unit, arranges them in descending order, selects the first N items and marks them as the hot service workflows, where N is a natural number greater than or equal to 1.

[0035] Define each of the hot service workflows with a frequency greater than the expected value as the basic workflow, and set them in the access request queue and the listening request queue according to the preset frequency, and return the data to the business software unit in a predetermined period.

[0036] When the expected total time used for the process subunits in a certain access request queue or listening request queue is greater than the expected value, reduce the occurrence frequency of the basic workflow according to the preset mode.

[0037] A computer device includes a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the method described in any one of the above embodiments.

[0038] A computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the steps of the method described in any one of the above embodiments.

[0039] Beneficial effects: By constructing a hardware resource management module, the efficiency of resource sharing is improved, and the problems of low internal resource utilization rate and slow processing speed in the prior art are solved. Description of the Drawings

[0040] Figure 1 It is a flowchart of accessing hardware resources for a hardware resource sharing method based on an energy controller according to the present invention. Detailed Embodiments

[0041] As Figure 1 shown, the technical principle and technical details of the present invention are described in detail. Specifically, a hardware resource sharing method based on an energy controller is provided, which mainly includes the following steps:

[0042] Construct a hardware resource management module, and build an access request queue and a listening request queue adapted to it based on the hardware resources.

[0043] The hardware resource management module receives an access request or a listening request sent by a business software unit for at least a certain hardware resource.

[0044] The hardware resource management module inserts the access request and the listening request into the access request queue and the listening request queue corresponding to the hardware resource respectively;

[0045] Based on the access request queue and the listening request queue, access and monitor the corresponding hardware resources in sequence, and return the data to the service software unit.

[0046] It should be noted that, in Figure 1 the embodiment shown, the number of request queues, the number of listening queues are the same as the number of hardware resources. This is only an example. In other embodiments, the number of request queues, the number of listening queues are not the same as the number of hardware resources, and can be more or less than the corresponding number of hardware resources. For example, by increasing the number of redundant request queues or listening queues, more scalable request responses and listening responses can be provided. For some hardware resources with less access, request queues or listening queues may not be set. Therefore, in the embodiments of the present invention, the mode and number of request queues and listening queues can be constructed according to the actual situation of the hardware resources, and the listening queue or / and the request queue can meet the functional requirements of the service software.

[0047] Specifically, a hardware resource sharing method based on an energy controller applied to a certain working condition is provided to illustrate the specific process of this embodiment. This hardware resource sharing method uses a hardware resource manager to manage hardware (resources), and the service software uses the hardware resource access interface to use the hardware resources.

[0048] In this embodiment, the hardware resource manager is provided with a hardware resource access interface. Corresponding to each specific hardware resource, it has two basic structures: a request queue and a listening queue. The hardware resource access interface is a software interface provided by the hardware resource manager for the service software to access and monitor the hardware resources.

[0049] The access and listening requests from the service software are pushed into the request queue, and the service software information of the listening requests among them will be pushed into the listening queue. The hardware resource manager takes out the requests from the request queue and operates on the corresponding hardware resources according to the information of the requests. When the information returned by the corresponding hardware resource is monitored, the information will be sent to each service software in the listening queue.

[0050] This embodiment takes the serial port resource as an example to illustrate the implementation process of the present invention. This embodiment is not all embodiments of the present invention, but only one method that can implement the present invention. For the shared serial port, the following hardware resource access interface is designed:

[0051] The interface functions and interface formats are respectively:

[0052] Data transmission 01 01 name baudrate databits parity stopbits sendData

[0053] Device monitoring 02 01 name

[0054] Data return 03 01 name recvData

[0055] The form of this interface is in the form of messages. The interface of the present invention can also be in the form of an API, and is not limited to a specific software implementation.

[0056] This interface provides three functions: The first data represents the function number, 01 represents data transmission, 02 represents device monitoring, and 03 represents data return. The second data represents the serial port number, 01 represents the first serial port, name is the name of the business software, baudrate represents the serial port baud rate, databits represents the data bits, parity represents the parity bit, stopbits represents the stop bit, sendData represents the data to be sent to the serial port, and recvData represents the data received from the serial port.

[0057] In this embodiment, the business software unit accesses the hardware resources according to the following steps:

[0058] Step 1-1: The business software sends a request to access the first serial port to the hardware resource manager through the data transmission interface and waits for the access result.

[0059] Step 1-2: The hardware resource manager obtains the access request in Step 1-1 from the request queue, opens the serial port according to the serial port parameters in the access request, and transmits data to the serial port.

[0060] Step 1-3: The hardware resource manager reads the return data of the serial port and returns the data to the business software through the "data return" interface.

[0061] Step 1-4: The business software obtains the result of accessing the serial port through the data return interface of the hardware resource manager.

[0062] Furthermore, when multiple business softwares need to access the first serial port, according to Step 1-1, multiple business softwares assemble access request messages according to the format requirements of the data transmission interface and send them to the hardware resource manager. Multiple request messages will enter the request queue of the hardware resource manager. Then, according to Step 1-2, the hardware resource manager will sequentially take out the access requests from the queue and execute them. According to Step 1-3, the results will be returned to the corresponding business softwares. Finally, according to Step 1-4, each business software will receive the returned data, thus realizing data transmission sharing.

[0063] The business software unit monitors the hardware resources and proceeds as follows:

[0064] Step 2-1: The business software sends a request to the hardware resource manager through the device monitoring interface to monitor the serial port No. 1.

[0065] Step 2-2: The hardware resource manager puts the business software that sends the monitoring request into the monitoring queue.

[0066] Step 2-3: Monitor the serial port No. 1 requested in Step 3-1.

[0067] Step 2-4: If the monitored serial port receives external data, the data will be sent to all business software in the monitoring queue.

[0068] In a further embodiment, to improve the system processing efficiency. When multiple business software all want to monitor the serial port 1, according to Step 2-1, multiple business software assemble the monitoring request messages according to the format requirements of the device monitoring interface and send them to the hardware resource manager. According to Step 2-2, the names of multiple business software with requests will enter the monitoring queue of the hardware resource manager. Then according to Step 2-3, monitor the serial port No. 1. If the serial port receives external data, then according to Step 2-4, install the data return interface format and send the monitored data to all business software in the monitoring queue. Thus, each business software will obtain the data of this serial port, thereby realizing data monitoring sharing.

[0069] That is to say, in this embodiment, if multiple business software have the same requirements for a certain hardware resource, then according to the format requirements of the interface, requests with a time interval difference less than a predetermined value can be packaged to form a shared or common information packet. Through the splitting and combination of requirements, reduce the fragmentation of information packets and form a more complete information combination, thereby improving the efficiency of the system.

[0070] To solve the problem of the system request order and avoid the problem of low system efficiency caused by simply sorting access requests or monitoring requests according to the time order, the following solutions are provided.

[0071] According to one aspect of the present application, the step S1 specifically includes:

[0072] S11. Based on the statistically used frequency of the hardware resources, divide the hardware resources into predetermined types and assign corresponding hardware resource weights to each predetermined type of hardware resource; for example, in a certain working condition, the use frequency of the Bluetooth port is higher than other ports, then correspondingly, the weight of the Bluetooth port is set higher. Based on the existing usage situation, statistically analyze the usage of each hardware resource and divide it into a predetermined number of types, such as high frequency, medium frequency, low frequency and other types, and different types of ports are given different weights.

[0073] Based on the statistically analyzed business software work process, split the functions of the business software into several process sub-units, and count the total frequency of each process sub-unit in a predetermined work scenario.

[0074] Meanwhile, disassemble the work process of the business software to form several independent process sub-units, and count the occurrence frequency of the process sub-units within a predetermined time in the corresponding work scenario. For example, business software units 1, 3, and 5 all have a request for the same access communication module. In a certain scenario, within a complete work cycle, the request times of business software unit 1 are 3, the request times of business software unit 3 are 2, and the request times of business software unit 5 are 4. According to the demand frequency of the process sub-units within a work cycle, weight the process sub-units. The more frequently occurring process sub-units are, relatively speaking, more important.

[0075] S12. Construct an access request queue not less than the total number of hardware resources and a listening request queue not less than the total number of hardware resources; and assign queue weights to the access request queue and the listening request queue based on the hardware resource weights and the total frequency of each process sub-unit, and configure the access request queue and the listening request queue to be arranged in descending order of queue weight.

[0076] Based on the dual weighting of the above-mentioned hardware resources and software process sub-units, set the queue weights of the access request queue and the listening request queue, so as to screen out the high-frequency business processes in the software unit, give them priority processing, improve the processing priority of high-frequency services, and thus improve the overall resource utilization efficiency of the system. In fact, through the classification of hardware resources and the decomposition of software processes, it is possible to statistically map the relationship between the constructed hardware resources and software process sub-units, corresponding high-weight hardware resources to high-frequency software process sub-units, so that the business software queues that need to utilize these resources can make full use of the hardware resources, thereby obtaining better processing effects.

[0077] S13. Allocate storage resources to each access request queue and listening request queue based on the queue weight.

[0078] In this embodiment, the storage resources of the request queue and the listening queue are allocated according to the weight. The queue with a high occurrence frequency is given more storage resources, so as to reduce situations such as queuing or caching, improve the resource allocation ratio of important and high-frequency access request queues and listening request queues, and provide a basis for efficient work.

[0079] In a further embodiment, in order to improve the accuracy of the weight, the weight is normalized, the total weight is set to 1, the weight of the process sub-unit is divided by the total weight to obtain a weight ratio, and the weight ratio is used as a benchmark.

[0080] In order to further improve the work processing efficiency, improve the utilization efficiency of internal resources, and optimize the work process and work efficiency of business software units, a processing method based on a workflow vector diagram is provided.

[0081] According to one aspect of the present application, the step S11 further includes:

[0082] Step S111: For each functional business work process of each business software unit, construct a workflow vector diagram based on process subunits; compare the workflow vector diagrams of each functional business work process to find out whether there are the same process subunits. If so, mark this process subunit as a shareable process subunit.

[0083] According to one aspect of the present application, it further includes step S112: Calculate the total weight of the shareable process subunits, count the number of shareable process subunits in each access request queue and listening request queue under typical scenarios, and calculate the resource usage proportion of each shareable process subunit.

[0084] The resource usage proportion w = (the typical time of the shareable process subunit × the total weight of the shareable process subunit) / (the sum of the products of the typical time of each process subunit in this request or listening request queue and its weight).

[0085] That is to say, in this embodiment, the business software is decomposed into several process subunits with directions, and a workflow vector diagram based on the process subunits is constructed. And analyze and compare whether there are common process subunits between different business softwares, and optimize resources based on the shareable process subunits. For example, the workflow vector diagram of business software unit 1 is: ①→②→③→④→⑤, the workflow vector diagram of business software unit 2 is: ⑥→②→⑦→⑧→⑨, and the workflow vector diagram of business software unit 3 is: ⑩→③→⑤→②→⑪; and so on. Some different business software units are intertwined with each other to form a topological structure. The nodes of these topological structures jointly occupy part of the hardware resources. By analyzing the topological structure, especially the usage situation analysis of the shareable process subunits, the core nodes are optimized, so as to form a more effective work process processing and analysis. In a further embodiment, the frequencies of different-frequency business software units are different, and the main roads and branch roads of the topology can be formed.

[0086] In other words, from the perspective of the system or the architecture, the functions of the business software are divided into interrelated and topological structures. Based on the proportion of resource usage, the core nodes of the topological structure are found. The main paths and branch paths are distinguished based on frequency, and the entire system is analyzed organically. From the perspective of the system, the entire functional module is analyzed and optimized to avoid the deviation caused by the optimization of a single process, and the resource usage efficiency is higher. By optimizing the core nodes, the performance of multiple business software units related to these nodes can be improved. Analyzing the resource usage or occupancy of each software from the perspective of coupling and decoupling improves the overall analysis performance and usage efficiency of the system.

[0087] In a further embodiment, to solve the priority problem of business software units, analysis data based on work scenario statistical data is provided, and based on this analysis data, an optimized method is provided. Specifically, according to one aspect of the present application, it further includes step S113.

[0088] Based on typical work scenarios, calculate the time used for each access request queue and listening request queue in the order of decreasing queue weight and decreasing proportion of resource usage of process subunits in sequence, and calculate the total time used for the access request queue and the total time used for the listening request queue.

[0089] Switch the work scenario, adjust the order of queue weights or the arrangement order of the proportion of resource usage of process subunits, and recalculate the total time used for the access request queue and the total time used for the listening request queue.

[0090] Loop the above process until the total time used for the access request queue and the total time used for the listening request queue in each work scenario meet the expected values.

[0091] That is to say, since the app can be installed and uninstalled according to the actual situation, the same energy controller may have different app groups. At the same time, at different times or in different scenarios, the access frequencies of different apps and business unit modules are different. Therefore, in these cases, the optimization strategies are different. Therefore, by simulating the situations in different scenarios, the total time is optimized, thereby improving the working efficiency of the energy controller. Or rather, by switching the work scenarios, the optimized processing strategy is calculated, so as to use different processing strategies in different scenarios and improve the working efficiency in each scenario.

[0092] In this embodiment, or in the following embodiments, through the edge service terminal to calculate the sorting strategy or method, the corresponding results are calculated and then sent to the hardware resource management module for execution. The computing work is divided into cloud computing (backend server), edge computing (edge service terminal) and internal computing and execution modules, thereby reducing the work of the hardware resource management module. For example, according to one aspect of the present application, the step S2 further includes:

[0093] S21. After the hardware resource management module receives an access request or a listening request for at least a certain hardware resource sent by a service software unit, for each process subunit of the service software unit, traverse the access request queue or the listening request queue corresponding to the hardware resource to find whether there is the same process subunit. If there is, recalculate the weight of the same process subunit, refresh the assignment, and at the same time, establish a pointer pointing to the service software unit. After the hardware resource management module accesses or listens to the hardware resource based on the same process subunit, return the data to the service software unit based on the above pointer; if not, proceed to the next step;

[0094] S22. Insert it into the corresponding access request queue or listening request queue according to the weights of the current process subunits.

[0095] That is to say, in this embodiment, when a new access request or listening request is generated, after splitting it into process subunits, first check whether there is the same request. If there is, establish a pointer, and there is no need to queue repeatedly, and sort according to the weights, so as to improve the utilization of system resources, reduce the resource occupation of queuing, reduce the memory occupation, reduce duplicate requests, and speed up the processing speed.

[0096] In order to improve the working efficiency of the energy controller terminal, part of the computing work is transferred to the edge service terminal.

[0097] According to one aspect of the present application, it further includes step 5.

[0098] Upload the workflow vector diagram to the edge service terminal according to a predetermined time period and format.

[0099] Calculate the total time used by the access request queue and the total time used by the listening request queue under the current sorting. After adjusting the sorting, calculate the total time used by the access request queue and the total time used by the listening request queue under each sorting, and return the sorting with the least total time to the hardware resource management module, and refresh each access request queue and listening request queue.

[0100] Upload the workflow diagram to the edge service terminal, calculate and optimize the topological structure based on the workflow vector diagram through the powerful computing power of the edge service terminal, and return the optimal solution. In subsequent work, execute the new optimization solution to improve the overall working efficiency. Through the method of edge computing, solve the internal structure changes caused by reasons such as app update or uninstallation of the system, or changes in the topological structure of the workflow vector diagram due to changes in the working scenario, and improve the overall optimization effect of the system.

[0101] In order to further improve the optimization effect, the following solution can also be adopted.

[0102] According to one aspect of the present application, it further includes step 6:

[0103] S61. Each energy controller sends the sorting of each access request queue and listening request queue within a predetermined period and the corresponding total time used to the edge service terminal.

[0104] The edge service terminal counts the total time used under different sortings, takes the total time used as the optimization goal, searches for the relatively optimal sorting, and sends it to each energy controller to be written into the hardware resource management module.

[0105] S62. Each energy controller sends the service software unit, the corresponding process sub-unit, and the workflow vector diagram within a predetermined period to the edge service terminal.

[0106] The edge service terminal calculates the total time used for the workflow vector diagram corresponding to each functional service workflow in each service software unit, arranges them in descending order, takes the first N items and marks them as hot service workflows, where N is a natural number greater than or equal to 1.

[0107] Each of the hot service workflows with an occurrence frequency greater than the expected value is defined as a basic workflow, and is set in the access request queue and the listening request queue according to a preset frequency, and data is returned to the service software unit in a predetermined period.

[0108] When the expected time used for the total process sub-units in a certain access request queue or listening request queue is greater than the expected value, the occurrence frequency of the basic workflow is reduced according to the preset mode.

[0109] That is to say, in a certain system, there may be 100 energy controllers. The working scenarios of different energy controllers are different, and the topological structures of the internal workflow vector diagrams are different. Based on different situations, the average workflow is statistically analyzed, and the hot services are distinguished. Thus, starting from the entire system of energy controllers, the entire system is optimized to improve the average efficiency of each energy controller.

[0110] In a further embodiment, the similarity of the scenario types of the energy controllers is compared, that is, the type and quantity of the APPs, and the occurrence frequency of the process sub-units of each APP. The processing efficiency with a scenario type similarity greater than the threshold is also compared. The solution with the minimum total time used is uploaded to the server and pushed to other energy controllers with a scenario similarity greater than the threshold according to a preset method.

[0111] In a further embodiment, a computer device and a computer-readable storage medium are provided.

[0112] A computer device includes a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the method described in any one of the above embodiments.

[0113] A computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the method described in any one of the above embodiments are implemented.

[0114] It should be noted that, for each of the specific technical features described in the above specific embodiments, they can be combined in any suitable manner without conflict. This method is divided into a construction process and an execution process. Some supplements can be used in both the construction process and the execution process. It can be constructed first and then executed, or a non-optimal solution can be executed first, and then a new solution can be constructed based on the situation and then executed. To avoid unnecessary repetition, the present invention will not separately describe various possible combination methods.

Claims

1. A hardware resource sharing method based on an energy controller, characterized in that, Including: S1. Construct a hardware resource management module, and based on the hardware resources, construct an access request queue and a listening request queue adapted to it; S2. The hardware resource management module receives an access request or a listening request sent by a service software unit for at least a certain hardware resource; S3. The hardware resource management module inserts the access request and the listening request into the access request queue and the listening request queue corresponding to the hardware resource; S4. Based on the access request queue and the listening request queue, access and listen to the corresponding hardware resources in sequence, and return the data to the service software unit; Step S1 further includes: Step S111. For each functional service workflow of each service software unit, construct a workflow vector diagram based on the process subunits; compare the workflow vector diagrams of each functional service workflow to find whether there are the same process subunits. If so, mark the process subunit as a shareable process subunit; Step S112. Calculate the total weight of the shareable process subunits, count the number of shareable process subunits in each access request queue and listening request queue in a typical scenario, and calculate the resource usage ratio of each shareable process subunit; The resource usage ratio w = (Typical time of the sharable process subunit × Total weight of the sharable process subunit) / (Sum of the products of the typical time and weight of each process subunit in the request or monitoring request queue); Based on the typical working scenario, calculate the time used for each access request queue and listening request queue in the order of decreasing queue weight and decreasing resource usage ratio of the process subunit, and calculate the total time used for the access request queue and the total time used for the listening request queue; Switch the working scenario, adjust the order of the queue weights or the arrangement order of the resource usage ratios of the process subunits, and recalculate the total time used for the access request queue and the total time used for the listening request queue; Loop the above process until the total time used for the access request queue and the total time used for the listening request queue in each working scenario meet the expected values.

2. The hardware resource sharing method based on an energy controller according to claim 1, characterized in that, The said step S2 further includes: S21. After the hardware resource management module receives an access request or a listening request sent by a service software unit for at least a certain hardware resource, for each process subunit of the service software unit, traverse the access request queue or the listening request queue corresponding to the hardware resource to find whether there is the same process subunit. If there is, recalculate the weight of the same process subunit, refresh and assign the value, and at the same time, establish a pointer pointing to the service software unit. After the hardware resource management module accesses or listens to the hardware resource based on the same process subunit, return the data to the service software unit based on the above pointer; If not, proceed to the next step; S22. Insert it into the corresponding access request queue or listening request queue with the weights of the current process subunits.

3. The hardware resource sharing method based on an energy controller according to claim 1, characterized in that, It also includes step 5: Upload the workflow vector diagram to the edge service terminal according to a predetermined time period and format; Calculate the total time used for the access request queue and the total time used for the listening request queue under the current sorting. After adjusting the sorting, calculate the total time used for the access request queue and the total time used for the listening request queue under each sorting, and return the sorting with the least total time to the hardware resource management module, and refresh each access request queue and listening request queue.

4. The hardware resource sharing method based on an energy controller according to claim 3, characterized in that, It also includes step 6: S61. Each energy controller sends the sorting of each access request queue and listening request queue within a predetermined period and the corresponding total time used to the edge service terminal. The edge service terminal counts the total time used under different sortings, takes the total time used as the optimization goal, searches for the relatively optimal sorting, and sends it to each energy controller to be written into the hardware resource management module. S62. Each energy controller sends the service software unit, the corresponding process sub-unit, and the workflow vector diagram within a predetermined period to the edge service terminal. The edge service terminal calculates the total time used for the workflow vector diagram corresponding to each functional service workflow in each service software unit, arranges them in descending order, takes the first N items and marks them as hot service workflows, where N is a natural number greater than or equal to 1. Each of the hot service workflows with a frequency of occurrence greater than the expected value is defined as a basic workflow, and is set in the access request queue and the listening request queue according to a preset frequency, and the data is returned to the service software unit in a predetermined period. When the expected time used for the total process sub-units in a certain access request queue or listening request queue is greater than the expected value, the occurrence frequency of the basic workflow is reduced according to the preset mode.

5. A computer device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 4.

6. A computer-readable storage medium, on which a computer program is stored, characterized in that, When the computer program is executed by the processor, it implements the steps of the method according to any one of claims 1 to 4.

Images