Equipment utilization rate statistical method

Abstract

The invention relates to the field of equipment utilization rate statistics, in particular to an equipment utilization rate statistical method, which comprises a statistical system, and the statistical system comprises five parts, namely a background server, a front-end server, a database, a proxy server and an internal network. According to the method, Web service, database interaction, automatic report generation, MQTT, websocket communication and other advanced technologies are creatively fused, and the method aims at solving the problem of deep binding of data and codes caused by diversity of equipment types in the field of equipment management, so that the efficiency and quality of secondary development are remarkably improved. And a flexible and configurable equipment utilization rate acquisition framework is constructed, so that data acquisition of different equipment and decoupling of the system are realized. The modular design is adopted, and each equipment management module is used as an independent plug-in and is seamlessly connected with the equipment management system through a standard interface, so that the newly added or modified equipment management does not need to touch the core test logic, and the complexity and risk of secondary development are greatly reduced.

Description

Technical Field

[0001] The present application relates to the field of equipment usage statistics, and in particular to an equipment usage statistics method. Background Art

[0002] With the expansion of business, some foundry laboratories have an unusually large number of devices, and these devices may be distributed in different laboratories. Therefore, it becomes extremely difficult to calculate the utilization rate of these devices.

[0003] In the face of this challenge, it is particularly urgent to automatically collect the utilization rate of each device. For foundry manufacturers with many devices, each device may have its own unique software interface, which further increases the complexity of obtaining device utilization statistics. Traditional equipment utilization statistics tools often tightly bind the acquisition of equipment utilization to the system. Each new device means a lot of modifications to the system and the introduction of complex branch logic, which not only increases the difficulty of development, but also may undermine the stability and maintainability of existing code, and also requires downtime to deploy new programs.

[0004] Therefore, it is crucial to optimize the current equipment utilization method. This is not only to protect the existing system from code changes, but also to improve the efficiency of secondary development and deployment, making the process of automatic acquisition of equipment utilization more flexible and scalable, so as to better adapt to the diverse needs of equipment. By adopting a more flexible plug-in architecture and data standardization, the complete decoupling of test execution and report generation can be achieved, providing OEM manufacturers with an efficient and reliable equipment utilization statistics solution.

[0005] The existing equipment utilization system has the following defects:

[0006] The usage acquisition module is deeply coupled with the system: In traditional methods, the usage statistics system often hard-codes the device status acquisition code directly into the system logic. Whenever a new device is added or changed, the developer needs to deeply analyze the original logic and adapt the new template by adding complex conditional branches. This is not only costly, but also easy to introduce errors, affecting the stability of the existing system.

[0007] Inability to perform incremental updates: Traditional equipment usage statistics systems require the entire system to be redeployed after the code for generating new equipment usage statistics is updated, which has a significant impact on the use of the tool.

[0008] In summary, the existing equipment usage statistics system still has certain defects. Based on this, the inventor has developed a equipment usage statistics method. Summary of the invention

[0009] In order to solve the above technical problems, this application provides a device usage statistics method, which realizes the decoupling of data acquisition of different devices from the system by constructing a flexible and configurable device usage acquisition framework. With modular design, each device management module is an independent plug-in, which is seamlessly connected to the device management system through a standard interface, so that adding or modifying device management does not need to touch the core test logic, which greatly reduces the complexity and risk of secondary development.

[0010] This application provides a method for calculating equipment utilization rate, which adopts the following technical solution:

[0011] A device usage rate statistics method includes a statistics system, the statistics system includes a backend server, a front-end server, a database, a proxy server and an internal network; the statistics method includes:

[0012] Backend servers, frontend servers, databases, proxy servers, and internal networks;

[0013] The backend server processes the files including the plug-in submitted by the frontend and determines whether the file is a compressed package. If not, it directly returns a notification of installation failure and error information to the frontend via HTTP. If so, it decompresses the file. If the decompression fails, it also returns a notification of installation failure and error information to the frontend via HTTP.

[0014] Search the directory after decompressing the file to see if there is a document named X.txt. If so, install all third-party libraries in place through pip-rrequirements.txt, and traverse all documents in the decompressed directory to search for documents in .py or .pyc format. If so, dynamically import the document through imp.

[0015] After receiving the plugin_id sent by the front end, query the plugin information of the plugin_id from the database; delete the code in the queried code path, delete the template under the queried template path, and delete the information in the plugin information table in the database; return the front end result; then notify the deletion of this plugin in the form of MQTT or Websocket;

[0016] There is a new device interface on the front page, and the interface of the new device includes device parameters;

[0017] When the background server starts, query the information of all devices in the database, traverse all device information, and query the path of the module for obtaining the usage status in the plug-in table according to dev_type, dev_brand, and dev_model in the device information. After obtaining the path, start the scheduled background task. In the background task, the get_devices_info function in the module is executed regularly to obtain the online status, usage status, and error information of the device, and determine whether the online status, usage status, and error information of the device are in use. If in use, obtain the usage status of the device from the server's cache. If not, set a cache with the device ID as the key and the current time as the value; if not in use, obtain whether the device usage status is included from the cache. If it exists, obtain the start time of use in the device cache, and use the current time as the end time;

[0018] Then insert the device ID, start time, end time, calculated total time, and calculated non-working time into the device usage record table in the database. After obtaining the error status, record the device ID, current time, and error information into the device error information table in the data.

[0019] The front-end server is used to provide users with static files for the browser, such as html, css, and javascript pages. When the user makes a request, the server transmits the static files to the browser. After the browser completes rendering, it loads data in the background according to the control logic in Javascript. It also provides a button for plug-in installation. After clicking the button, select the compressed package to be uploaded. After the selection is completed, the front-end will upload the compressed package to the back-end and open a dialog box. The dialog box includes a text area and subscribes to the installation log topic of MQTT or Websocket. The topic information is filtered in the onmessage function of MQTT or Websocket. The received log information is then displayed in the text box in the dialog box. After the installation is completed, the dialog box is closed.

[0020] Database, used to store plug-in information, device usage information, and device error information;

[0021] Proxy server, used to coordinate agents, proxy automation tools, front-end servers, and back-end servers through MQTT\Websocket;

[0022] Internal network, used for transmitting information between servers and modules.

[0023] Preferably, when the document is successfully imported dynamically by means of imp, it is determined whether the document includes the following parameters:

[0024] 1) PLUGIN_NAME, the short name of the plug-in. Subsequent judgments are based on PLUGIN_NAME.

[0025] 2) PLUGIN_VERSION, the version of the plug-in. The format of the version is vx.xx, where x is any integer between 0 and 9, indicating the version of the installed plug-in.

[0026] 3) DEV_TYPE, the type of device;

[0027] 4) DEV_MODEL_LIST, indicating a list of device models supported by the plugin;

[0028] 5) DEV_BRAND, indicating the brand of the device supported by the plugin;

[0029] 6) get_devices_info, indicating function;

[0030] If the imported document does not include get_devices_info, the next successfully imported document is directly determined;

[0031] If the above parameters are detected in the document, check whether the plug-in name assigned by PLUGIN_NAME exists in the database. If so, it means that the plug-in has been installed. Then compare the versions. If they are consistent, return to the front end directly and show that the plug-in already exists. If they are inconsistent, determine whether it is a higher version. If it is a higher version, update the version field in the database. The updated version field comes from the PLUGIN_VERSION variable in the module.

[0032] Replace the file contained in the module_path field in the database with the current .Py file; if it is detected that the database does not include the record of the plug-in name assigned by PLUGIN_NAME; first copy the current .Py file to the path of the server, and then use the path as module_path, install_user obtains the logged-in user name from the current session, first loops the dev_model list, and then obtains each supported dev_model in the loop body, inserts plugin_name, plugin_version, install_user, dev_type, dev_model, module_path into the database, DEV_MODEL_LIST contains N models, and N corresponding entries appear in the database; after successful installation, the supported dev_model and dev_type are notified of the addition of new plug-ins via MQTT or Websocket.

[0033] Preferably, the device parameters include:

[0034] Asset code, which corresponds to the company's unified asset code for easy identification;

[0035] Device name, which is convenient for engineers to identify;

[0036] Device description, briefly describing the device information for easy identification;

[0037] Device type is a drop-down box that includes all installed plugin information tables containing all dev_type documents as options;

[0038] Device brand is a drop-down box that includes all installed plugin information tables containing all dev_brand documents as options;

[0039] Device model is a drop-down box that includes all installed plugin information tables containing all dev_model documents as options;

[0040] The device brand, model, and type will all listen to the MQTT or Websocket topic. When a new device is found, the new option will be added directly; when a device is deleted, the corresponding option will be deleted directly. The device IP address and port number are used for the plug-in to communicate with the device and obtain the status.

[0041] Preferably, after the backend framework receives the submitted newly added device function, it queries the plugin table for the path of the module where the usage status is located according to the dev_type, dev_brand, and dev_model in the submitted information. After obtaining the path, it starts the scheduled background task, and the get_devices_info function in the module is executed regularly in the background task to obtain the online status, usage status, and error information of the device, and determine whether it is in use. If it is in use, the usage status of the device is obtained from the server's cache. If not, a cache is set with the ID of the device as the key and the current time as the value. If it is determined that it is not in use, the usage status of the device is obtained from the cache. If it exists, the start time of use in the device cache is obtained, and the current time is used as the end time.

[0042] Then insert the device ID, start time, end time, calculated total time, and calculated non-working time into the device usage record table in the database. After obtaining the error status, record the device ID, current time, and error information into the device error information table in the data.

[0043] Preferably, the function of querying the data required by the device is defined in the backend framework so as to be used in the device plug-in;

[0044] The back-end framework provides a compressed package of plug-in development samples for the front-end to download, and provides an interface on the front-end interface to explain the overall process of plug-in development and the functions, parameter descriptions, return value descriptions, and call instructions of all functions exposed by the system.

[0045] Preferably, it also includes:

[0046] Determine whether the plug-in is a built-in plug-in. If so, the system implements the plug-ins of AC Source, DC Source, wireless comprehensive tester, various high and low temperature test chambers, and oscilloscope by default;

[0047] How to determine the equipment in use:

[0048] AC Source and DC Source use instrument-specific protocols to query all channels of these two types of devices to see if at least one channel is in output state. If so, it is in use;

[0049] The wireless comprehensive tester queries the VSA and VSG through the protocol to see whether there are any attenuation-related configurations. If so, they are in use.

[0050] The high and low temperature box is checked through the protocol to see if it is in the startup state. If so, it is in the use state;

[0051] The oscilloscope queries the various channels of the oscilloscope through the protocol to see whether the probe information is included. If so, it means that a probe is inserted in a channel and is in use.

[0052] Preferably, the front-end server further includes:

[0053] The front-end server displays the basic information of all installed plug-ins. If the plug-in is marked as a default built-in plug-in, there is no uninstall button for the plug-in. If the plug-in is installed by the user, an uninstall button will be displayed. After clicking the uninstall button, a request will be submitted, which includes the ID of the plug-in to notify the back-end to uninstall the corresponding plug-in.

[0054] The front end visualizes the monthly usage time of the device in a data table based on the device usage records;

[0055] The front end will subscribe to the topic of plug-in installation of MQTT or Websocket; when the back end pushes the newly installed plug-in through this topic, it will directly update the device type, device brand, and device model.

[0056] Preferably, the database also includes:

[0057] A table that records plugin information. The table contains the fields id, create_time, plugin_name, plugin_version, install_user, dev_type, dev_model, dev_brand, and module_path. id is an auto-incrementing index. create_time indicates the time, which defaults to the current time when the data is inserted. plugin_name indicates the name of the plugin. plugin_version indicates the version number of the plugin. install_user indicates the user who installed the plugin. dev_type indicates the name of the device corresponding to the plugin. dev_brand indicates the brand of the device corresponding to the plugin. dev_model indicates the model of the corresponding device. module_path is the location where the execution script is stored.

[0058] In summary, this application includes the following beneficial technical effects:

[0059] 1. This application innovatively integrates cutting-edge technologies such as Web services, database interaction, automated report generation, MQTT, websocket communications, etc., aiming to solve the problem of deep binding of data and code in the field of device management due to the diversity of device types, thereby significantly improving the efficiency and quality of secondary development.

[0060] 2. This application achieves the decoupling of data acquisition of different devices from the system by building a flexible and configurable device usage acquisition framework. With modular design, each device management module is an independent plug-in, which is seamlessly connected to the device management system through a standard interface, so that adding or modifying device management does not need to touch the core test logic, greatly reducing the complexity and risk of secondary development.

[0061] 3. This application provides a dynamic modular device management mechanism, which uses an advanced modular architecture to support the status acquisition of different devices. Each module operates independently, and functional integration is achieved through a dynamic call mechanism, ensuring complete isolation between modules. This design reduces the interdependence between modules, so that modifying any module will not affect other modules, greatly simplifies the logical structure, reduces the complexity of the code, and significantly improves the maintainability and scalability of the code.

[0062] 4. This application provides seamless plug-in installation, which makes the plug-in installation process easier and faster than ever before for system administrators. Administrators can easily install new plug-ins without interrupting server operation or performing tedious redeployment, and this process has no effect on the acquisition of usage information by other devices in the system, ensuring high system availability and continuity of user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] Figure 1 It is a system architecture diagram of the statistical method in the embodiment of the present application.

[0064] Figure 2 It is a schematic diagram of the principle of the statistical method in the embodiment of the present application. DETAILED DESCRIPTION

[0065] The present application is further described in detail below in conjunction with the accompanying drawings.

[0066] The embodiment of the present application discloses a method for counting equipment usage rate.

[0067] Reference Figure 1 ,The statistical method includes a statistical system, which includes five parts: a back-end server, a front-end server, a database, a proxy server and an internal network.

[0068] Statistical methods include:

[0069] The backend server is used for: Test report plug-in installation interface: The backend server processes the files including plug-ins submitted by the frontend, and determines whether the file is a compressed package. If not, it directly returns the notification of installation failure and error information to the frontend via HTTP. If so, it decompresses the file. If the decompression fails, delete all files in the decompressed path, and also returns the notification of installation failure and error information to the frontend via HTTP. In order to avoid the frontend being stuck due to the long interface response rate, after processing the above two steps, add a background task, and then directly return the notification of the processing results of the backend via HTTP.

[0070] In the report plugin installation background task function, search for the X.txt document in the directory after the file is decompressed. If so, install all third-party libraries in place through pip-rrequirements.txt, and traverse all documents in the decompressed directory to search for documents in .py or .pyc format. If so, dynamically import the document through imp.

[0071] When the document is successfully imported dynamically through imp, it is determined whether the document contains the following parameters:

[0072] 1) PLUGIN_NAME, the short name of the plug-in. Subsequent judgments are based on PLUGIN_NAME.

[0073] 2) PLUGIN_VERSION, the version of the plug-in. The format of the version is vx.xx, where x is any integer between 0 and 9, indicating the version of the installed plug-in.

[0074] 3) DEV_TYPE, the type of device;

[0075] 4) DEV_MODEL_LIST, indicating a list of device models supported by the plugin;

[0076] 5) DEV_BRAND, indicating the brand of the device supported by the plugin;

[0077] 6) get_devices_info, indicating function;

[0078] If the imported document does not include get_devices_info, the next successfully imported document is directly determined;

[0079] The naming of the above variables can be meaningful and does not necessarily follow the above naming rules;

[0080] If the above parameters are detected in the document, check whether the plug-in name assigned by PLUGIN_NAME exists in the database. If so, it means that the plug-in has been installed. Then compare the versions. If they are consistent, return to the front end directly and show that the plug-in already exists. If they are inconsistent, determine whether it is a higher version. If it is a higher version, update the version field in the database. The updated version field comes from the PLUGIN_VERSION variable in the module.

[0081] Replace the file contained in the module_path field in the database with the current .Py file; if it is detected that the database does not include the record of the plug-in name assigned by PLUGIN_NAME; first copy the current .Py file to the path of the server, and then use the path as module_path, install_user obtains the logged-in user name from the current session, first loops the dev_model list, and then obtains each supported dev_model in the loop body, inserts plugin_name, plugin_version, install_user, dev_type, dev_model, module_path into the database, DEV_MODEL_LIST contains N models, and N corresponding entries appear in the database; after successful installation, the supported dev_model and dev_type are notified of the addition of new plug-ins via MQTT or Websocket.

[0082] Plugin uninstallation interface: after receiving plugin_id sent from the front end, query the plugin information of the plugin_id from the database; delete the code in the queried code path, delete the template under the queried template path, and delete the information in the plugin information table in the database; return the result to the front end; then notify the deletion of this plugin via MQTT or Websocket;

[0083] Newly added device interface: There is a newly added device interface on the front-end page, and the newly added device interface includes device parameters;

[0084] Device parameters include:

[0085] Asset code, which corresponds to the company's unified asset code for easy identification;

[0086] Device name, which is convenient for engineers to identify;

[0087] Device description, briefly describing the device information for easy identification;

[0088] Device type is a drop-down box that includes all dev_type documents in the installed plugin information table as options;

[0089] Device brand is a drop-down box that includes all installed plugin information tables containing all dev_brand documents as options;

[0090] Device model is a drop-down box that includes all installed plugin information tables containing all dev_model documents as options;

[0091] The device brand, model, and type will all listen to the MQTT or Websocket topic. When a new device is found, the new option will be added directly; when a device is deleted, the corresponding option will be deleted directly. The device IP address and port number are used for the plug-in to communicate with the device and obtain the status.

[0092] After the backend framework receives the submitted new device function, it queries the plugin table for the path of the module that obtains the usage status according to the dev_type, dev_brand, and dev_model in the submitted information. After obtaining the path, it starts the scheduled background task. The background task periodically executes the get_devices_info function in the module to obtain the online status, usage status, and error information of the device, and determines whether it is in use. If it is in use, it obtains the usage status of the device from the server's cache. If not, it sets a cache with the device ID as the key and the current time as the value. If it is determined that it is not in use, it obtains the usage status of the device from the cache. If it exists, it obtains the start time of use in the device cache, and uses the current time as the end time.

[0093] Then insert the device ID, start time, end time, calculated total time, and calculated non-working time into the device usage record table in the database. After obtaining the error status, record the device ID, current time, and error information into the device error information table in the data.

[0094] When the background server starts, query the information of all devices in the database, traverse all device information, and query the path of the module for obtaining the usage status in the plug-in table according to dev_type, dev_brand, and dev_model in the device information. After obtaining the path, start the scheduled background task. In the background task, the get_devices_info function in the module is executed regularly to obtain the online status, usage status, and error information of the device, and determine whether the online status, usage status, and error information of the device are in use. If in use, obtain the usage status of the device from the server's cache. If not, set a cache with the device ID as the key and the current time as the value; if not in use, obtain whether the device usage status is included from the cache. If it exists, obtain the start time of use in the device cache, and use the current time as the end time;

[0095] Then insert the device ID, start time, end time, calculated total time, and calculated non-working time into the device usage record table in the database. After obtaining the error status, record the device ID, current time, and error information into the device error information table in the data.

[0096] The backend framework defines the functions for device querying required data so that they can be used in device plug-ins. This is to avoid exposing the relevant parameters of the server database during plug-in development and improve the security of the overall system.

[0097] The back-end framework provides a compressed package of plug-in development samples for the front-end to download, and provides an interface on the front-end interface to explain the overall process of plug-in development and the functions, parameter descriptions, return value descriptions, and call descriptions of all functions exposed by the system.

[0098] Determine whether the plug-in is a built-in plug-in. If so, the system implements the plug-ins of AC Source, DC Source, wireless comprehensive tester, various high and low temperature test chambers, and oscilloscope by default;

[0099] How to determine the equipment in use:

[0100] AC Source and DC Source use instrument-specific protocols to query all channels of these two types of devices to see if at least one channel is in output state. If so, it is in use;

[0101] The wireless comprehensive tester queries the VSA and VSG through the protocol to see whether there are any attenuation-related configurations. If so, they are in use.

[0102] All kinds of high and low temperature boxes can be checked through the protocol to see if they are in the startup state. If so, they are in the use state;

[0103] The oscilloscope queries the various channels of the oscilloscope through the protocol to see whether the probe information is included. If so, it means that a probe is inserted in a channel and is in use.

[0104] The above-mentioned different types of devices, different brands, and different models of devices have different plug-in codes to execute. The get_devices_info function of these plug-ins passes in two parameters: IP address and port number, and then returns three parameters: online status, usage status, and error information. Different protocols are implemented in the get_devices_info function in different modules to communicate with the target device to obtain information.

[0105] Front-end server, web front-end server can be selected to provide users with static files of browser, html, css, javascript pages. When the user makes a request, the server transmits the static files to the browser. After the browser renders, it loads data in the background according to the control logic in Javascript. It also provides a button for plug-in installation. After clicking the button, select the compressed package to be uploaded. After the selection is completed, the front-end will upload the compressed package to the back-end and open a dialog box. The dialog box includes a text area and subscribes to the installation log topic of MQTT or Websocket. The topic information is filtered in the onmessage function of MQTT or Websocket. Then the received log information is displayed in the text box in the dialog box. After the installation is completed, the dialog box is closed.

[0106] The front-end server also includes:

[0107] The front-end server displays the basic information of all installed plug-ins. If the plug-in is marked as a default built-in plug-in, there is no uninstall button for the plug-in. If the plug-in is installed by the user, an uninstall button will be displayed. After clicking the uninstall button, a request will be submitted, which includes the ID of the plug-in to notify the back-end to uninstall the corresponding plug-in.

[0108] The front end visualizes the monthly usage time of the device in a data table based on the device usage records;

[0109] The front end will subscribe to the topic of plugin installation of MQTT or Websocket; when the back end pushes the newly installed plugin through this topic, it will directly update the device type, device brand, and device model. Selecting the option in the drop-down box will directly update the option in the drop-down box of device type, device brand, and device model; allowing users to obtain the newly installed plugin options without re-requesting;

[0110] Database, used to store plug-in information, device usage information, and device error information;

[0111] The database also includes:

[0112] A table that records plugin information. The table contains the fields id, create_time, plugin_name, plugin_version, install_user, dev_type, dev_model, dev_brand, and module_path. id is an auto-incrementing index. create_time indicates the time, which defaults to the current time when the data is inserted. plugin_name indicates the name of the plugin. plugin_version indicates the version number of the plugin. install_user indicates the user who installed the plugin. dev_type indicates the name of the device corresponding to the plugin. dev_brand indicates the brand of the device corresponding to the plugin. dev_model indicates the model of the corresponding device. module_path is the location where the execution script is stored.

[0113] Proxy server, used to coordinate agents, proxy automation tools, front-end servers, and back-end servers through MQTT\Websocket;

[0114] The proxy server can use MQTT Broker or Websocket proxy;

[0115] The internal network is used to transmit information between servers and modules, and is the carrier for transmitting information. The transmission of messages between the above modules must be transmitted through the internal network, so the network must ensure stability.

[0116] In summary, the working process of the equipment utilization rate statistics method can be summarized as follows, please refer to Figure 2 :

[0117] Server startup, including the startup of backend servers, front-end servers, databases, proxy servers, and internal networks;

[0118] Query the device table in the data, and then loop through the devices in the data device table, that is, query the information of all devices in the database and traverse all device information;

[0119] Get the device's dev_type, dev_brand, and dev_model, and query the plug-in table based on the three parameters to obtain the plug-in module path. That is, query the plug-in table based on the dev_type, dev_brand, and dev_model in the device information to obtain the path of the module in use;

[0120] Start the scheduled background task, that is, after obtaining the path, start the scheduled background task;

[0121] The module corresponding to the dynamic import module, that is

[0122] Execute the get_devices_info function, that is, the get_devices_info function in the module is executed regularly in the background task;

[0123] Then, the background tasks are created in a loop, and the devices in the data device table are queried in a loop again, and the corresponding tasks are queried and executed again, and then the statistical work of the device usage rate is completed.

[0124] The above are all preferred embodiments of the present application, and the protection scope of the present application is not limited thereto. Therefore, any equivalent changes made according to the structure, shape, and principle of the present application should be included in the protection scope of the present application.

Claims

1. A method for counting equipment usage, characterized in that: Including statistical system, statistical system includes back-end server, front-end server, database, proxy server and internal network; statistical methods include: The backend server processes the files including the plug-in submitted by the frontend and determines whether the file is a compressed package. If not, it directly returns a notification of installation failure and error information to the frontend via HTTP. If so, it decompresses the file. If the decompression fails, it also returns a notification of installation failure and error information to the frontend via HTTP. Search the directory after decompressing the file to see if there is a document named X.txt. If so, install all third-party libraries in place through pip-rrequirements.txt, and traverse all documents in the decompressed directory to search for documents in .py or .pyc format. If so, dynamically import the document through imp. After receiving the plugin_id sent by the front end, query the plugin information of the plugin_id from the database; delete the code in the queried code path, delete the template under the queried template path, and delete the information in the plugin information table in the database; return the front end result; then notify the deletion of this plugin in the form of MQTT or Websocket; There is a new device interface on the front page, and the interface of the new device includes device parameters; When the background server starts, query the information of all devices in the database, traverse all device information, and query the path of the module for obtaining the usage status in the plug-in table according to dev_type, dev_brand, and dev_model in the device information. After obtaining the path, start the scheduled background task. In the background task, the get_devices_info function in the module is executed regularly to obtain the online status, usage status, and error information of the device, and determine whether the online status, usage status, and error information of the device are in use. If in use, obtain the usage status of the device from the server's cache. If not, set a cache with the device ID as the key and the current time as the value; if not in use, obtain whether the device usage status is included from the cache. If it exists, obtain the start time of use in the device cache, and use the current time as the end time; Then insert the device ID, start time, end time, calculated total time, and calculated non-working time into the device usage record table in the database. After obtaining the error status, record the device ID, current time, and error information into the device error information table in the data. The front-end server is used to provide users with static files for the browser, such as html, css, and javascript pages. When the user makes a request, the server transmits the static files to the browser. After the browser completes rendering, it loads data in the background according to the control logic in Javascript. It also provides a button for plug-in installation. After clicking the button, select the compressed package to be uploaded. After the selection is completed, the front-end will upload the compressed package to the back-end and open a dialog box. The dialog box includes a text area and subscribes to the installation log topic of MQTT or Websocket. The topic information is filtered in the onmessage function of MQTT or Websocket. The received log information is then displayed in the text box in the dialog box. After the installation is completed, the dialog box is closed. Database, used to store plug-in information, device usage information, and device error information; Proxy server, used to coordinate agents, proxy automation tools, front-end servers, and back-end servers through MQTT\Websocket; Internal network, used for transmitting information between servers and modules.

2. A method for counting equipment usage according to claim 1, characterized in that: When the document is successfully imported dynamically through imp, it is determined whether the document contains the following parameters: 1) PLUGIN_NAME, the short name of the plug-in. Subsequent judgments are based on PLUGIN_NAME. 2) PLUGIN_VERSION, the version of the plug-in. The format of the version is vx.xx, where x is any integer between 0 and 9, indicating the version of the installed plug-in. 3) DEV_TYPE, the type of device; 4) DEV_MODEL_LIST, indicating a list of device models supported by the plugin; 5) DEV_BRAND, indicating the brand of the device supported by the plugin; 6) get_devices_info, indicating function; If the imported document does not include get_devices_info, the next successfully imported document is directly determined; If the above parameters are detected in the document, check whether the plug-in name assigned by PLUGIN_NAME exists in the database. If it does, it means that the plug-in has been installed. Then compare the versions to see if they are consistent. If they are consistent, return to the front end directly and show that the plug-in already exists. If they are inconsistent, determine whether it is a higher version. If it is a higher version, the version field in the database is updated. The updated version field comes from the PLUGIN_VERSION variable in the module. Replace the file contained in the module_path field in the database with the current .Py file; if it is detected that the database does not contain a record of the plugin name assigned by PLUGIN_NAME, first copy the current .Py file to the server path, and then use the path as module_path. install_user obtains the logged-in user name from the current session, first loops through the dev_model list, and then obtains each supported dev_model in the loop body and inserts plugin_name, plugin_version, install_user, dev_type, dev_model, module_path to the database, DEV_MODEL_LIST contains N models, and N entries appear in the database accordingly; after successful installation, the supported dev_model and dev_type will be notified of the addition of a new plugin via MQTT or Websocket.

3. The device usage rate statistics method according to claim 1, characterized in that: The device parameters include: Asset code, which corresponds to the company's unified asset code for easy identification; Device name, which is convenient for engineers to identify; Device description, briefly describing the device information for easy identification; Device type is a drop-down box that includes all dev_type documents in the installed plugin information table as options; Device brand is a drop-down box that includes all installed plugin information tables containing all dev_brand documents as options; Device model is a drop-down box that includes all installed plugin information tables containing all dev_model documents as options; The device brand, model, and type will all listen to the MQTT or Websocket topic. When a new device is found, the new option will be added directly; when a device is deleted, the corresponding option will be deleted directly. The device IP address and port number are used for the plug-in to communicate with the device and obtain the status.

4. The device usage rate statistics method according to claim 1, characterized in that: After the backend framework receives the submitted new device function, it queries the plugin table for the path of the module that obtains the usage status according to the dev_type, dev_brand, and dev_model in the submitted information. After obtaining the path, it starts the scheduled background task. The background task periodically executes the get_devices_info function in the module to obtain the online status, usage status, and error information of the device, and determines whether it is in use. If it is in use, it obtains the usage status of the device from the server's cache. If not, it sets a cache with the device ID as the key and the current time as the value. If it is determined that it is not in use, it obtains the usage status of the device from the cache. If it exists, it obtains the start time of use in the device cache, and uses the current time as the end time. Then insert the device ID, start time, end time, calculated total time, and calculated non-working time into the device usage record table in the database. After obtaining the error status, record the device ID, current time, and error information into the device error information table in the data.

5. The device usage rate statistics method according to claim 1, characterized in that: The backend framework defines the function for device querying required data so that it can be used in the device plug-in; The back-end framework provides a compressed package of plug-in development samples for the front-end to download, and provides an interface on the front-end interface to explain the overall process of plug-in development and the functions, parameter descriptions, return value descriptions, and call instructions of all functions exposed by the system.

6. A method for counting equipment usage rate according to claim 1, characterized in that: Also includes: Determine whether the plug-in is a built-in plug-in. If so, the system implements the plug-ins of AC Source, DC Source, wireless comprehensive tester, various high and low temperature test chambers, and oscilloscope by default; How to determine the equipment in use: AC Source and DC Source use instrument-specific protocols to query all channels of these two types of devices to see if at least one channel is in output state. If so, it is in use; The wireless comprehensive tester queries the VSA and VSG through the protocol to see whether there are any configurations related to attenuation. If so, they are in use. The high and low temperature box is checked through the protocol to see if it is in the startup state. If so, it is in the use state; The oscilloscope queries the various channels of the oscilloscope through the protocol to see whether the probe information is included. If so, it means that a probe is inserted in a channel and is in use.

7. The device usage statistics method according to claim 1, characterized in that: The front-end server also includes: The front-end server displays the basic information of all installed plug-ins. If the plug-in is marked as a default built-in plug-in, there is no uninstall button for the plug-in. If the plug-in is installed by the user, an uninstall button will be displayed. After clicking the uninstall button, a request will be submitted, which includes the ID of the plug-in to notify the back-end to uninstall the corresponding plug-in. The front end visualizes the monthly usage time of the device in a data table based on the device usage records; The front end will subscribe to the topic of plug-in installation of MQTT or Websocket; when the back end pushes the newly installed plug-in through this topic, it will directly update the device type, device brand, and device model.

8. The device usage rate statistics method according to claim 1, characterized in that: The database also includes: A table that records plugin information. The table contains fields id,create_time,plugin_name,plugin_version,install_user,dev_type,dev_model,dev_brand,module_path; id is an auto-incrementing index, create_time indicates the time, which defaults to the current time when the data is inserted, plugin_name indicates the name of the plugin, plugin_version indicates the version number of the plugin, install_user indicates the user who installed the plugin, dev_type indicates the name of the device corresponding to the plugin, dev_brand indicates the brand of the device corresponding to the plugin, and dev_model indicates the model of the corresponding device; module_path is the storage location of the execution script.

Images