A multi-measurement unit adding method, device, electronic equipment and storage medium

Abstract

This application discloses a method, apparatus, electronic device, and storage medium for adding multiple measurement units. The method includes: responding to a device addition command received by an interactive interface layer, creating and binding subclass objects for at least one measurement unit to be added; the interactive interface layer is used to form an MVVM architecture with a scheduling control layer and a device virtualization layer; the subclass objects inherit from an abstract device; the scheduling control layer allocates an independent running thread to each subclass object; and the interactive interface layer displays the data and status information of at least one measurement unit. In this embodiment, different types of measurement units are adapted through inheritance, eliminating the need to develop separate control logic for each device, greatly simplifying the access process for new devices, and enabling new measurement units to be quickly accessed and their data and status displayed synchronously, facilitating the centralized addition and deployment of multiple measurement units in batches.

Description

Technical Field

[0001] This application relates to the field of measurement unit management technology, and in particular to a method, apparatus, electronic device and storage medium for adding multiple measurement units. Background Technology

[0002] In the field of electronic measurement and automated testing, the source meter unit (SMU) is a precision instrument that combines power supply and measurement functions. It is widely used in the fields of semiconductors, materials science, and component testing for precision electrical characteristic analysis.

[0003] Currently, the industry primarily relies on dedicated host computer software provided by equipment manufacturers or self-developed single-device control programs for controlling measurement units such as source meters. This software is typically tied to a specific model or series of measurement units, and its core functions include voltage and current scanning output, custom waveform generation, real-time data acquisition, graphical display of measurement data, and basic data storage and analysis. When it is necessary to connect measurement units of different models and communication protocols for collaborative testing, the existing system software cannot be directly reused. The underlying communication protocol and control logic must be rewritten for the new devices, resulting in long development cycles and high maintenance costs. Summary of the Invention

[0004] To address existing technical problems, this invention provides a method, apparatus, electronic device, and storage medium for adding multiple measurement units. By using the abstract device and general function interface of the device virtualization layer, different types of measurement units can be adapted through inheritance, eliminating the need to develop separate control logic for each device. This significantly simplifies the process of adding new devices. Operators only need to issue device addition commands to complete the creation, binding, and thread allocation of subclass objects, lowering the operational threshold for device access. Newly added measurement units can be quickly connected and their data and status can be displayed synchronously, facilitating the centralized addition and deployment of multiple measurement units in batches.

[0005] In a first aspect, embodiments of this application provide a method for adding multiple measurement units, the method comprising: In response to a device addition command received by the interface layer, a subclass object is created and bound for at least one measurement unit to be added. The interface layer is used to form an MVVM architecture with the scheduling control layer and the device virtualization layer. The interface layer is coupled with the scheduling control layer. The subclass object inherits from the abstract device, which is a virtual device built in the device virtualization layer to define a common function interface. The subclass object is used to drive the measurement unit bound to it to implement the subclass operation corresponding to the common function interface. Each subclass object is assigned an independent running thread through the scheduling control layer; Display the data and status information of at least one measurement unit in the interactive interface layer.

[0006] Secondly, embodiments of this application provide a multi-measurement unit adding device, the device comprising: The device adding module is used to respond to the device adding command received by the interactive interface layer, and to create and bind subclass objects for at least one measurement unit to be added; the interactive interface layer is used to form an MVVM architecture with the scheduling control layer and the device virtualization layer; the interactive interface layer is coupled with the scheduling control layer; the subclass objects inherit from the abstract device, which is a virtual device built in the device virtualization layer to define a general function interface, and the subclass objects are used to drive the measurement units bound to them to implement the subclass operations corresponding to the general function interface; The thread allocation module is used to allocate an independent running thread for each subclass object through the scheduling control layer; The information display module is used to display data and status information of at least one measurement unit on the interactive interface layer.

[0007] Thirdly, embodiments of this application provide an electronic device, which includes a processor and a memory. The memory stores at least one instruction, at least one program, code set, or instruction set. The processor loads and executes the at least one instruction, at least one program, code set, or instruction set to implement the multi-measurement unit addition method of the first aspect.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing at least one instruction or at least one program, wherein the at least one instruction or at least one program is loaded and executed by a processor to implement the multi-measurement unit addition method of the first aspect.

[0009] Fifthly, embodiments of this application provide a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the multi-measurement unit addition method of the first aspect.

[0010] The multi-measurement unit addition method, apparatus, electronic device, and storage medium provided in this application have the following technical effects: In response to a device add command received from the interactive interface layer, subclass objects are created and bound for at least one measurement unit to be added. The interactive interface layer, together with the scheduling control layer and the device virtualization layer, forms an MVVM architecture. The interactive interface layer is coupled with the scheduling control layer. Subclass objects inherit from an abstract device, which is a virtual device built in the device virtualization layer to define a common functional interface. The subclass objects drive the measurement units bound to them to implement the subclass operations corresponding to the common functional interface. An independent running thread is allocated to each subclass object through the scheduling control layer. The data and status information of at least one measurement unit are displayed in the interactive interface layer. In this embodiment, through the abstract device and common functional interface of the device virtualization layer, different types of measurement units are adapted through inheritance. There is no need to develop control logic separately for a single device, which greatly simplifies the access process of new devices. Operators only need to issue a device add command to complete the creation, binding, and thread allocation of subclass objects, reducing the operational threshold for device access. New measurement units can be quickly accessed and data and status can be displayed synchronously, facilitating the centralized addition and deployment of multiple measurement units in batches. Attached Figure Description

[0011] To more clearly illustrate the technical solutions and advantages in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of an application environment provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a method for adding multiple measurement units provided in an embodiment of this application. Figure 1 ; Figure 3 This is a flowchart illustrating a method for adding multiple measurement units provided in an embodiment of this application. Figure 2 ; Figure 4 This is a schematic diagram of an MVVM architecture provided in an embodiment of this application; Figure 5 This is a schematic diagram of a device addition page provided in an embodiment of this application. Figure 1 ; Figure 6 This is a schematic diagram of a device addition page provided in an embodiment of this application. Figure 2 ; Figure 7 This is a schematic diagram of a configuration parameter page provided in an embodiment of this application. Figure 2 ; Figure 8 This is a schematic diagram of a configuration parameter page provided in an embodiment of this application. Figure 2 ; Figure 9 This is a schematic diagram of a device management page provided in an embodiment of this application; Figure 10 This is a flowchart illustrating an information display method provided in an embodiment of this application. Figure 1 ; Figure 11 This is a schematic diagram of an information display page provided in an embodiment of this application. Figure 1 ; Figure 12 This is a flowchart illustrating an information display method provided in an embodiment of this application. Figure 2 ; Figure 13 This is a schematic diagram of an information display page provided in an embodiment of this application. Figure 2 ; Figure 14 This is a flowchart illustrating an information display method provided in an embodiment of this application. Figure 3 ; Figure 15 This is a flowchart illustrating a source table debugging method provided in an embodiment of this application; Figure 16 This is a schematic diagram of a device debugging page provided in an embodiment of this application; Figure 17 This is a flowchart illustrating a log display method provided in an embodiment of this application; Figure 18 This is a schematic diagram of a log display page provided in an embodiment of this application; Figure 19 This is a flowchart illustrating an image display method provided in an embodiment of this application. Figure 1 ; Figure 20 This is a flowchart illustrating an image display method provided in an embodiment of this application. Figure 2 ; Figure 21 This is a flowchart illustrating an image display method provided in an embodiment of this application. Figure 3 ; Figure 22 This is a schematic diagram of an image display page provided in an embodiment of this application; Figure 23 This is a schematic diagram of the structure of a multi-measurement unit adding device provided in an embodiment of this application; Figure 24 This is a hardware structure block diagram of a server for a method of adding multiple measurement units provided in an embodiment of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0014] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0015] Before providing a further detailed description of the embodiments of this disclosure, the terms and concepts used in these embodiments are explained, and they are subject to the following interpretations: MVVM: Model-View-View Model is a software architecture pattern used to separate the user interface from business logic. The Model is responsible for storing data and business logic, while the View is responsible for displaying the user interface and receiving user operations. The View Model acts as a bridge between the View and the Model, responsible for synchronizing data from the Model to the View and forwarding user operations from the View to the Model. This decouples the interface from the business logic and improves the maintainability and scalability of the system.

[0016] Measurement unit: This is the controlled physical device in this application, which may include voltage source meters, current source meters, etc. of different brands, models, and communication protocols. Its core function is to receive control commands and execute specific hardware operations, while also feeding back its own operating status and collected data.

[0017] Please see Figure 1 , Figure 1 This is a schematic diagram of an application environment provided in an embodiment of this application, including multiple measurement units 101, a management server 102, and a user terminal 103. The multiple measurement units 101, the management server 102, and the user terminal 103 can be directly or indirectly connected through wired or wireless communication, and this embodiment does not impose any limitations.

[0018] In one possible embodiment, multiple measurement units 101 are physical devices to be monitored and controlled in this application, which may include source meters of different brands, models and communication protocols, such as voltage source meters, current source meters, etc. Their core function is to receive control commands and execute specific hardware operations such as output voltage, current acquisition, and device reset, while feeding back their own operating status, acquired data and other information to the management server 102. They are the controlled execution end of the entire system.

[0019] The control and management of multiple measurement units 101 may include the following functions: voltage scanning, current scanning, custom scanning, current and voltage output, scan storage, continuous data acquisition, sensor mode, waveform function, data storage, data visualization, detailed viewing of data curves, maximum value, minimum value, and average value statistics.

[0020] In one possible embodiment, the management server 102 is responsible for building and maintaining the MVVM architecture and executing core business logic such as instruction parsing, thread scheduling, device virtualization abstraction, and data processing. The management server 102 can be, but is not limited to, a standalone server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides one or more of the following basic cloud computing services: cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, and big data and artificial intelligence platforms.

[0021] Specifically, the management server 102 integrates an interactive interface layer, a scheduling control layer, and a device virtualization layer. It receives user instructions through communication with the user terminal 103 and achieves unified management and control of multiple measurement units 101 through communication with multiple measurement units 101. It is the hub connecting the user terminal 103 and the measurement units 101.

[0022] In one possible embodiment, the user terminal 103 provides an interactive entry point for the user and is the display carrier of the interactive interface layer (or view layer) in the MVVM architecture. It is responsible for receiving various instructions such as device addition instructions, device management instructions, and debugging instructions input by the user, and displaying the device status, data information, operation results, etc. fed back by the management server 102 to the user in a visual form.

[0023] Optionally, the user terminal 103 may be, but is not limited to, physical devices such as smartphones, tablets, laptops, desktop computers, smart speakers, smart wearable devices, digital assistants, augmented reality devices, and virtual reality devices, and may also include software such as applications running on the physical device.

[0024] In this embodiment, the management server 102 responds to the device addition instruction received by the interactive interface layer by creating and binding subclass objects for at least one measurement unit to be added. The interactive interface layer is used to form an MVVM architecture with the scheduling control layer and the device virtualization layer. The interactive interface layer is coupled with the scheduling control layer. The subclass objects inherit from the abstract device, which is a virtual device built in the device virtualization layer to define a general function interface. The subclass objects are used to drive the measurement units bound to them to implement the subclass operations corresponding to the general function interface. The scheduling control layer allocates an independent running thread for each subclass object. The interactive interface layer displays the data and status information of at least one measurement unit.

[0025] In this embodiment, through the abstract device and general function interface of the device virtualization layer, different types of measurement units can be adapted through inheritance. There is no need to develop control logic separately for a single device, which greatly simplifies the access process of new devices. Operators only need to issue device addition instructions to complete the creation, binding and thread allocation of subclass objects, which reduces the operation threshold for device access. New measurement units can be quickly accessed and data and status can be displayed synchronously, which is convenient for batch addition and deployment of multiple measurement units.

[0026] The following describes a specific embodiment of a method for adding multiple measurement units according to this application. Figure 2 This is a flowchart illustrating a method for adding multiple measurement units provided in an embodiment of this application. Figure 1 This specification provides method operation steps as shown in the embodiments or flowcharts, but based on conventional or non-inventive labor, more or fewer operation steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only execution order. In actual system or server products, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment). Specifically, as shown in the embodiments or drawings... Figure 2 As shown, it may include: S201: In response to the device addition instruction received by the interface layer, create and bind subclass objects for at least one measurement unit to be added; the interface layer is used to form an MVVM architecture with the scheduling control layer and the device virtualization layer; the interface layer is coupled with the scheduling control layer; the subclass objects inherit from the abstract device, which is a virtual device built in the device virtualization layer to define a common function interface, and the subclass objects are used to drive the measurement units bound to them to implement the subclass operations corresponding to the common function interface.

[0027] S202: Assign an independent running thread to each subclass object through the scheduling control layer.

[0028] S203: Display the data and status information of at least one measurement unit in the interactive interface layer.

[0029] Figure 3 This is a flowchart illustrating a method for adding multiple measurement units provided in an embodiment of this application. Figure 2 The method may include: S301: Construct an MVVM architecture that includes an interactive interface layer, a scheduling control layer, and a device virtualization layer.

[0030] In this embodiment, the user interface layer is the View in an MVVM architecture, serving as the entry point for user interaction. It interfaces with the user terminal and is responsible for receiving user commands and displaying device status and data. The scheduling and control layer is the View Model, responsible for parsing user commands, converting them into general call commands, synchronizing status data, and acting as a communication bridge between the View and the Model. The device virtualization layer is the Model, responsible for device abstraction, data processing, and business logic implementation.

[0031] In this embodiment, the interactive interface layer is coupled with the scheduling control layer. Specifically, the View and View Model are bound together, so that user commands can be quickly transmitted to the scheduling control layer, and the processing results of the scheduling control layer can be promptly fed back to the interactive interface layer, and then synchronized to the user terminal.

[0032] S302: Construct abstract devices in the device virtualization layer.

[0033] In this embodiment, the abstract device defines a general-purpose functional interface. The abstract device is a top-level abstract template for multiple measurement units, unifying the functional interfaces of these units. The abstract device only defines the interface specifications and does not involve specific functional implementations; these implementations are handled by subsequent subclass objects. The general-purpose functional interfaces are predefined functional interfaces in the abstract device that can be used by all measurement units, such as device start-up, device stop, parameter configuration, data acquisition, and device reset. These interfaces do not depend on specific measurement unit models or communication protocols, providing a standardized basis for the unified management and control of multiple measurement units.

[0034] S303: In response to a device addition instruction received from the interactive interface layer, create and bind subclass objects for at least one measurement unit to be added.

[0035] S304: Assign an independent running thread to each subclass object through the scheduling control layer.

[0036] In one possible implementation, the scheduling control layer maintains a thread pool internally, and after a subclass object is created, it allocates an independent running thread from the thread pool for each subclass object.

[0037] Having an independent running thread for each subclass object is a prerequisite for parallel control. By allocating an independent thread to each measurement unit's subclass object, parallel management and control of multiple measurement unit devices can be achieved. Each subclass object runs in an independent thread, and the operation execution and status feedback of its corresponding measurement unit will not interfere with each other. If a measurement unit fails, it will not affect the normal operation of other measurement units, greatly improving the stability and reliability of the system.

[0038] Figure 4 This is a schematic diagram of an MVVM architecture provided in an embodiment of this application, as shown below. Figure 4 As shown in the embodiments of this application, each measurement unit's subclass object inherits from the abstract device and is used to drive the measurement unit bound to it to implement the subclass operation corresponding to the general function interface.

[0039] Figure 5 This is a schematic diagram of a device addition page provided in an embodiment of this application. Figure 1 In one possible implementation, there may be no measurement unit currently being monitored and managed in the system, and the user adds the first measurement unit, such as... Figure 5 As shown, the device addition page has an add device control. Users can click on the add device control to input device addition commands in the interactive interface layer.

[0040] In another possible embodiment, the system may already have measurement units being monitored and managed, and the user may add more and different types of measurement units.

[0041] When a user needs to add a new measurement unit, the device addition command entered by the user is transmitted to the server's interactive interface layer via the user terminal. The interactive interface layer forwards the command to the scheduling and control layer, which triggers the device virtualization layer to perform the creation and binding operation of the subclass object.

[0042] Specifically, the server creates a separate subclass object for each measurement unit to be added. This subclass object inherits all the common functional interfaces of the abstract device, ensuring that it can respond to the common call commands of the abstract device. At the same time, the subclass object establishes a binding relationship with the corresponding measurement unit. Its core function is to convert the common call commands of the abstract device into native commands that the measurement unit can recognize, drive the measurement unit to perform the corresponding operations, and realize the differentiated adaptation of the common functional interfaces.

[0043] In one alternative embodiment, the abstract device also maintains a general state machine, which is inherited and maintained by multiple subclass objects of multiple measurement units.

[0044] Specifically, the general state machine defines multiple standard device states, state transition logic, and state normalization rules. The state normalization rules are used to convert subclass state information returned by multiple measurement units into standard device states. The state transition logic is the logic for switching between multiple standard device states.

[0045] In one possible embodiment, a general state machine is used to uniformly manage the operating state of all measurement units, solving the problem of inconsistent state representations among different measurement units.

[0046] The standard device status is a predefined, unified state for the abstract device, such as idle, configuration, running, alarm, and fault states, which can cover all possible states throughout the measurement unit's entire lifecycle. The status transition logic defines the switching conditions between different standard device states, such as transitioning from idle to running state after device startup, or transitioning from running to fault state when a device malfunctions.

[0047] The status descriptions of different source tables may differ. For example, the abnormal status of measurement unit A and the fault status of measurement unit B are essentially the same, but the descriptions are different. The status normalization rule is used to convert the subclass status information returned by different measurement units into a unified standard device status, ensuring that the server and user terminal can identify and display the status of all measurement units in a unified way. Specifically, it converts the abnormal status of measurement unit A into a standard "fault status".

[0048] All subclasses of this application inherit from this general state machine, ensuring that the state management of all measurement units is standardized and that users can quickly understand the state of the monitored measurement units.

[0049] In one optional embodiment, in response to a device addition instruction received by the interface layer, subclass objects are created and bound for at least one measurement unit to be added, including: S3031: In response to the device add command received from the interactive interface layer, obtain the device type of the measurement unit.

[0050] Figure 6 This is a schematic diagram of a device addition page provided in an embodiment of this application. Figure 2 In one possible implementation, the user needs to enter detailed device information when adding a device, such as... Figure 6 As shown, after the user enters the device addition command in the interactive interface layer by clicking the Add Device control, a sub-window is displayed for further input of information such as the device communication method and device type of the device to be added.

[0051] In one possible embodiment, when a user enters information such as the model, brand, and communication protocol type of the measurement unit to be added on the user terminal interface, this information is transmitted to the scheduling control layer via the interactive interface layer. The scheduling control layer obtains and parses this device information to obtain the device types of multiple measurement units. Different device types correspond to different subclass objects. Therefore, the parsed device types can provide a basis for the creation of subsequent subclass objects, thereby ensuring that the subclass objects can accurately adapt to the measurement units.

[0052] S3032: Create at least one subclass object based on the device type, and bind the subclass object to the corresponding measurement unit.

[0053] In one possible embodiment, a corresponding subclass object is created for each measurement unit based on the acquired device type. For example, the source table for model A corresponds to the subclass object for model A, and the source table for model B corresponds to the subclass object for model B.

[0054] After creation, a unique binding relationship is established between the subclass object and the corresponding measurement unit to ensure that the instructions of the subclass object can be accurately issued to the corresponding measurement unit. At the same time, all subclass objects inherit the general state machine and general function interface of the abstract device, which ensures that all measurement units can respond to unified general call instructions and that the states of all measurement units can be uniformly managed and normalized.

[0055] S3033: Load configuration parameter information for each subclass object.

[0056] In one possible embodiment, the configuration parameter information consists of parameter settings required for the normal operation of the measurement unit. This ensures that the subclass object can drive the measurement unit to operate according to user needs, eliminating the need for users to repeatedly configure parameters after adding the device, thus improving operational convenience. The configuration parameter information can be set and saved by the user in advance, or it can be entered in real-time when adding the device. After loading, it is stored in the subclass object for subsequent command execution.

[0057] S3034: Register the subclass object to the scheduling control layer, and associate the state and data of the subclass object with the interactive interface layer through data binding.

[0058] In one possible embodiment, after a subclass object is registered to the scheduling control layer, the scheduling control layer can identify the state of the subclass object in real time, which facilitates the subsequent issuance of general calling instructions and monitoring of the subclass object's operation.

[0059] Through the data binding mechanism of the MVVM architecture, the standard device states inherited from the general state machine by subclass objects and the data collected by the measurement unit are associated with the interactive interface layer, and then synchronized to the user terminal to realize the real-time display of the measurement unit status and data without the need for the user to manually refresh the interface.

[0060] In an optional embodiment, the configuration parameter information includes device configuration information, operating plan information, and compensation plan information. The step of loading configuration parameter information for the subclass object specifically includes: S30331: In response to the device configuration information, operation plan information and compensation plan information received from the interactive interface layer, load configuration parameter information for the subclass object.

[0061] In this embodiment of the application, the device configuration information is the basic hardware configuration of the measurement unit, such as communication port, address, range, etc.; the operation scheme information is the operation parameter configuration of the measurement unit, such as output voltage, current, running time, etc.; and the compensation scheme information is the parameter configuration used to correct the measurement error of the measurement unit, such as temperature compensation, error calibration parameters, etc.

[0062] Figure 7 This is a schematic diagram of a configuration parameter page provided in an embodiment of this application. Figure 1 In one possible embodiment, such as Figure 7 As shown, the configuration parameter page has corresponding device configuration entry, operation scheme entry, and compensation scheme entry. After the user enters these configuration parameter information at the corresponding entry in the user terminal interface, the information is transmitted to the device virtualization layer through the interactive interface layer and the scheduling control layer. The device virtualization layer loads these parameter information into the corresponding subclass object to complete the parameter setting of the subclass object.

[0063] To facilitate the reuse of configuration parameters and avoid repeated user input, this application can also classify and save the user-inputted device configuration information, operation plan information, and compensation plan information. In the future, only the saved configuration plan needs to be called, which effectively saves the user's configuration time.

[0064] S30332: In response to the device configuration save command received by the interactive interface layer, the device configuration information is stored in the first storage space.

[0065] When a user inputs device configuration information and triggers a device configuration save command, the device configuration information is stored in the first storage space. In this embodiment, the first storage space is a dedicated storage area built into the server for storing device configuration information. When adding measurement units later and requiring the same device configuration information, the saved device configuration information can be directly retrieved from the first storage space, improving configuration efficiency. The first storage space, the second storage space, and the third storage space are independent of each other.

[0066] S30333: In response to the operation plan saving instruction received by the interactive interface layer, the operation plan information is stored in the second storage space.

[0067] When a user inputs the operation plan information and triggers the operation plan save command, the operation plan information is stored in the second storage space. The second storage space is independent of the first storage space and is dedicated to storing the operation plan information. It can be called up at any time as needed to realize the reuse of the operation plan, which is especially suitable for the batch configuration of multiple measurement units of the same type.

[0068] S30334: In response to the compensation scheme saving instruction received by the interactive interface layer, the compensation scheme information is stored in the third storage space.

[0069] When a user inputs compensation scheme information and triggers the compensation scheme save command, the compensation scheme information is stored in the third storage space. The third storage space is independent of the first and second storage spaces and is specifically used to store compensation scheme information. The partitioned storage design of this application can realize the classified management of different types of configuration parameters, making it convenient for users to quickly find, call and modify them, and improving the maintainability of the system.

[0070] Figure 8 This is a schematic diagram of a configuration parameter page provided in an embodiment of this application. Figure 2 In one possible embodiment, such as Figure 8 As shown, when a user clicks the run plan entry, a sub-window pops up. In this sub-window, detailed run plan information can be entered. By clicking the save plan control, the entered plan can be stored in the corresponding storage space. By selecting a saved run plan and clicking the load plan control, the selected run plan can be directly loaded, enabling the reuse of run plans.

[0071] In one optional embodiment, loading configuration parameter information for the subclass object specifically includes: S30331: Display a selection list of stored device configuration information, operation plan information, and compensation plan information in the interactive interface layer.

[0072] In one possible embodiment, when a user needs to load configuration parameter information for a subclass object, the server retrieves all saved configuration schemes from the first, second, and third storage spaces respectively, generates a selection list in the interactive interface layer, and synchronizes it to the user terminal. The user can quickly view all saved configuration schemes in the selection list without having to re-enter them, thus improving the convenience of operation.

[0073] S30332: In response to the scheme selection instruction received by the interactive interface layer, determine the target configuration scheme from multiple configuration schemes.

[0074] In one possible embodiment, the user selects the corresponding configuration scheme from the selection list on the user terminal according to the requirements of the measurement unit to be added and triggers the scheme selection instruction. After receiving the scheme selection instruction, the server determines the target configuration scheme selected by the user. The target configuration scheme includes target device configuration information, target operation scheme information and target compensation scheme information.

[0075] S30333: Load configuration parameter information for subclass objects based on the device configuration information, operation plan information and compensation plan information corresponding to the target configuration plan.

[0076] In one possible embodiment, based on the determined target configuration scheme, relevant configuration parameter information is retrieved from the corresponding storage space and loaded into the corresponding subclass object to complete the parameter configuration of the subclass object, thereby enabling rapid reuse of the configuration scheme and improving the efficiency of adding devices.

[0077] In one alternative embodiment, since different users have different usage scenarios and different functional requirements for the measurement unit, some users may need the measurement unit to implement exclusive or personalized functions that are not covered by the current general functional interface of the abstract device. Moreover, as the top-level abstract template of the multi-measurement unit device, the abstract device needs to have functional scalability to adapt to the customized needs of different users, while ensuring that the interfaces of all measurement units can still maintain a unified standard.

[0078] Therefore, in response to the device addition command received from the interface layer, subclass objects are created and bound for at least one measurement unit to be added, including: S3031: In response to the device addition command received from the interactive interface layer, obtain the function to be added to the measurement unit.

[0079] S3032: Determine whether the general function interface matches the function to be added. If yes, execute S3033; otherwise, execute S3034.

[0080] S3033: Create and bind subclass objects for at least one measurement unit.

[0081] S3034: Define the interface for the function to be added in the abstract device, and create and bind subclass objects for at least one measurement unit respectively.

[0082] In one possible implementation, if the general function interface matches the function to be added, subclass objects are created and bound to the multiple measurement units respectively.

[0083] In another possible embodiment, if the general function interface does not match the function to be added, the function interface to be added is defined in the abstract device, and subclass objects are created and bound to multiple measurement units respectively.

[0084] In one possible embodiment, the function to be added is the function that the measurement unit to be added needs to implement. It may include general functions, such as start-up and data acquisition, as well as proprietary functions, such as the proprietary calibration function of a certain model of source meter.

[0085] After obtaining the functions to be added, they are compared with the common function interfaces already defined in the abstract device. If the comparison matches, meaning the functions to be added are all common functions, a subclass object is directly created and a measurement unit is bound to it. The subclass object can implement these functions by inheriting the common function interface. If the comparison does not match, meaning the functions to be added include functions not defined in the common function interface, the corresponding interface for the functions to be added is first added to the abstract device, or the common function interface is extended, before creating the subclass object and binding the measurement unit. This ensures that the subclass object can implement all the functions expected by the user, improves the system's scalability, and meets the personalized needs of different users.

[0086] S305: Display data and status information of at least one measurement unit in the interactive interface layer.

[0087] S306: In response to device management commands received from the interactive interface layer, the scheduling control layer converts the device management commands into general call commands for the general function interface of the abstract device.

[0088] In this embodiment of the application, the device management command is an operation command triggered by the user on the user terminal based on one or more measurement units, such as starting a source meter, stopping multiple source meters in batches, configuring source meter parameters, etc.

[0089] Figure 9 This is a schematic diagram of a device management page provided in an embodiment of this application. In one possible embodiment, such as... Figure 9 As shown, the device management page displays the status, data, and other information of multiple measurement units currently under management. The device management page also has multiple device management controls. Users can perform batch management of devices by first selecting at least one measurement unit and then clicking on the device management control.

[0090] After a user triggers a device management command, it is transmitted to the user interface layer via the user terminal, and then forwarded to the scheduling and control layer. The scheduling and control layer first parses the device management command to determine the corresponding operation type, and then converts it into a general call command that conforms to the abstract device's general function interface specification. This ensures that the command can be recognized by all subclass objects that inherit from the abstract device, achieving unified command processing and avoiding command incompatibility issues caused by different measurement unit models.

[0091] S307: Send the general invocation instruction to the corresponding subclass object. In one possible embodiment, after generating the general call instruction, the scheduling control layer determines the corresponding subclass object based on the measurement unit specified in the device management instruction, and sends the general call instruction to these subclass objects.

[0092] If the device management command is a batch operation command, such as batch starting all source tables, the scheduling control layer will send the general call command to the subclass objects corresponding to all measurement units at the same time to achieve synchronous control of multiple devices. If the device management command is a single device operation command, it will only be sent to the subclass object corresponding to that device to ensure the accuracy of the operation.

[0093] In one optional embodiment, sending the general invocation instruction to the corresponding subclass object includes: Execution is performed on each subclass object through the scheduling control layer: S3071: Determine the currently executing subclass object as the current object.

[0094] In one possible implementation, before sending a general call instruction, the scheduling control layer will traverse all subclass objects in the thread pool, identify each subclass object as the current object in turn, and perform instruction matching one by one to ensure that no target subclass object is missed.

[0095] S3072: If the device management instruction matches the current object, send a general call instruction to the current object.

[0096] In one possible embodiment, the scheduling control layer determines whether the subclass object corresponding to the measurement unit specified in the device management instruction is the current object. If they match, that is, the current object is the target subclass object, the general call instruction is sent to the current object to ensure that the instruction can be delivered accurately.

[0097] S3073: If the device management command does not match the current object, the next subclass object will be determined as the current object.

[0098] If the current object is not the target subclass object specified by the device management instruction, the scheduling control layer will determine the next subclass object as the new current object and repeat the judgment steps of S3072 until all target subclass objects are found and a general call instruction is sent to ensure the accuracy and completeness of the instruction issuance.

[0099] S308: Converts general invocation instructions into subclass operation instructions using subclass objects.

[0100] In this embodiment, the subclass operation instruction is used to instruct the measurement unit bound to the subclass object to perform the subclass operation. In this application, all subclass objects inherit from the abstract device and strictly follow the Liskov Substitution Principle. That is, wherever the abstract device is used to receive the general call instruction, it can be replaced with any subclass object. The program behavior remains correct and no exceptions occur, ensuring that each subclass object can uniformly receive and process the general call instruction.

[0101] In one possible embodiment, after receiving the general call instruction sent by the scheduling control layer, the subclass object will convert the general call instruction into a subclass operation instruction that can be recognized by the measurement unit according to the model and communication protocol of the measurement unit it is bound to.

[0102] In this embodiment, the subclass operation instruction is to convert the unified general call instruction into a device-specific instruction, drive the measurement unit to execute the corresponding subclass operation, and execute the specific operation corresponding to the general function interface, such as starting the device and collecting data, thereby achieving precise control of the measurement unit and shielding the protocol differences between different measurement units.

[0103] For example, the general functional interface defined by the abstract device includes a data acquisition interface, and the corresponding general calling instruction is a standardized instruction. This instruction does not depend on any specific measurement unit model or communication protocol. After the scheduling control layer issues this instruction, the subclass objects corresponding to different measurement unit models will be differentiated.

[0104] Measurement unit A uses serial communication and the SCPI instruction set. Therefore, this subclass object will convert general call instructions into SCPI subclass operation instructions that measurement unit A can recognize. These instructions conform to the native instruction specifications of measurement unit A and can drive measurement unit A to perform current data acquisition operations.

[0105] Measurement unit B uses Ethernet communication and a JSON structure. Therefore, this subclass object will convert the same general call command into a JSON subclass operation command that measurement unit B can recognize, driving measurement unit B to perform the same current data acquisition operation.

[0106] Through the above conversion, the scheduling and control layer does not need to pay attention to the protocol differences between the two types of measurement units, A and B. It only needs to issue a unified general calling command to realize unified data acquisition control of different types of measurement units. This not only realizes the conversion from general commands to device native commands, but also shields the protocol differences between different measurement units, ensuring that multiple types of measurement units can be managed and controlled in a unified manner.

[0107] In an optional embodiment, after the corresponding measurement unit is driven to perform a specific operation through the subclass operation instruction, a response from the corresponding measurement unit is also received. Therefore, the response also needs to be processed uniformly. After converting the general call instruction into a subclass operation instruction through the subclass object, the method further includes: S309: If a subclass response information carrying subclass status information is received from the measurement unit, the subclass status information is converted into a standard device status based on the status normalization rule.

[0108] In one possible embodiment, after the measuring unit executes the corresponding subclass operation instruction, it encapsulates its own operating status, such as "operating normally" or "voltage abnormal", into subclass response information and sends it to the bound subclass object.

[0109] After receiving the response information from the subclass, the subclass object calls the state normalization rule of the general state machine in the abstract device to convert the subclass state information into a unified standard device state, and converts "voltage abnormality" into a standardized "alarm state", thereby achieving the unification of the states of different measurement units.

[0110] S310: A general state machine based on subclass objects bound to the standard device state update measurement unit.

[0111] In one possible embodiment, after the subclass object converts the subclass state information into the standard device state, it will update the state of the general state machine it inherits in real time to ensure that the general state machine can accurately reflect the current operating state of the measurement unit and provide a basis for subsequent state monitoring and instruction scheduling.

[0112] S311: Displays the standard device status of the measurement unit in the status display area of ​​the interactive interface layer through the MVVM architecture.

[0113] In one possible embodiment, after the general state machine state of the subclass object is updated, the standard device state can be synchronized to the interactive interface layer through the data binding mechanism of the MVVM architecture. The interactive interface layer displays it in the status display area and synchronizes it to the user terminal. The user can view the operating status of the measurement unit in real time on the user terminal, realizing visual monitoring of the status without manual query.

[0114] Figure 10 This is a flowchart illustrating an information display method provided in an embodiment of this application. Figure 1 In an optional embodiment, after receiving the subclass response information carrying subclass status information sent by the measurement unit, this application further includes a step of triggering an alarm based on the key status information therein: S401: Determine whether the subclass state information is critical state information. If yes, execute S402; otherwise, execute S403.

[0115] In one possible embodiment, the subclass state information is the real-time operating status data of the device fed back by the subclass object after the measurement unit performs the corresponding operation. Specifically, the subclass object converts the original state information sent by the measurement unit to obtain the subclass state information, which is adapted to the general state machine of the abstract device.

[0116] This application can divide the subclass status information into critical status information and general status information based on the operational safety requirements or maintenance priorities of the measurement unit. Specifically, the status judgment rules can be preset in the system configuration.

[0117] Specifically, in one possible embodiment, critical status information refers to status information that affects the normal operation of the measurement unit, poses a safety hazard, or requires emergency handling by the user, such as overcurrent, overvoltage, overload, hardware failure, or communication interruption of the measurement unit. General status information refers to status information that does not affect the safe operation of the equipment and is only used by the user to understand the normal operating status of the equipment, such as the current output voltage, current value, running time, and idle state of the measurement unit.

[0118] By using preset state judgment rules, the received subclass state information is identified, and key state information is distinguished from general state information.

[0119] S402: Write critical status information into the global variable table.

[0120] In this embodiment, the main program continuously maintains a global variable table, which is the core data carrier used by the system to store key status information of all measurement units and realize global linkage control. It has the characteristics of real-time read and write and global accessibility, and can be shared and accessed by the main program, scheduling control layer and various subclass objects.

[0121] S403: A general state machine that updates the subclass objects bound to the measurement unit based on general state information.

[0122] In one optional embodiment, if the subclass status information of the measurement unit is critical status information, the critical status information is written into the global variable table for further monitoring, which may trigger a global linkage response.

[0123] In another optional embodiment, if the subclass state information of the measurement unit is general state information, the general state machine of the subclass object bound to the measurement unit is updated based on the general state information, without triggering a global linkage response. As mentioned above, all subclass objects inherit from the abstract device and maintain the general state machine defined by the abstract device. This general state machine is used to uniformly manage the operating state of the measurement units and realize the normalized display of the states of different measurement units. The subclass object will convert the received general state information into the standard device state according to the state normalization rules preset by the general state machine, and then update the current state of the general state machine it maintains.

[0124] This application includes two display formats: a synchronous display format, which displays information about all managed measurement units on the main interface, and a sub-window display format, which displays information about the bound measurement units in each sub-window.

[0125] For general status information, a silent refresh mechanism is adopted, which binds the device thread to the target window. Specifically, when general status information is updated, it is silently refreshed in the background only in an independent thread of the corresponding device, and is not actively displayed on the main interface of the interaction interface layer. The updated general status information is only synchronously rendered to the sub-window when the user switches to and activates the sub-window corresponding to the measurement unit. If the user does not switch to the sub-window, the general status information is continuously updated in the background without consuming additional system resources, thus achieving lightweight system operation.

[0126] S404: Display key status information in the message display area of ​​the interactive interface layer.

[0127] Figure 11 This is a schematic diagram of an information display page provided in an embodiment of this application. Figure 1 ,like Figure 11 As shown, in order to enable users to know the device status in a timely manner, once the key status information is written into the global variable table, the system will synchronously display the key status information in the message display area of ​​the interactive interface layer.

[0128] The message display area is an expandable message bar in the interactive interface layer, used to centrally display key status information of all measurement units, facilitating quick viewing and unified management by users. The displayed key status information must include core content, such as the corresponding measurement unit identifier, key status type, and the time the status occurred, ensuring users can quickly locate abnormal devices and their types, providing a reference for subsequent manual intervention. Simultaneously, this display operation is synchronized with the write operation to the global variable table, ensuring users can obtain device anomaly information in real time.

[0129] S405: Obtain the configuration parameter information of the measurement unit.

[0130] In this embodiment, the configuration parameter information is the basic parameter for the normal operation of the measurement unit. It is input and loaded by the user in the interactive interface layer. Specifically, it includes device configuration information, operation plan information, compensation plan information, etc. These configuration parameter information are bound one by one to the subclass objects of the measurement unit and can be quickly obtained through the scheduling control layer.

[0131] In this application, after detecting that key status information has been written into the global variable table, the scheduling control layer calls the general function interface of the corresponding measurement unit subclass object to obtain the configuration parameter information of the measurement unit. Combining the key status information and configuration parameter information of the measurement unit, it accurately determines whether the measurement unit is in an alarm state that requires triggering emergency shutdown protection. Through cross-validation of key status information and configuration parameter information, misjudgments caused by key status information, such as temporary anomalies caused by instantaneous voltage fluctuations, can be avoided, reducing unnecessary shutdown operations and improving the accuracy of system control.

[0132] S406: Determine whether the measuring unit is in an alarm state. If yes, execute S407; otherwise, execute S410.

[0133] The key status information written into the global variable table is compared with the acquired measurement unit configuration parameter information, and the measurement unit is determined to be in a true alarm state according to the preset alarm status judgment rules.

[0134] If the critical status information exceeds the preset normal range of the configuration parameters, the measurement unit is determined to be in an alarm state; if the critical status information does not exceed the preset normal range of the configuration parameters, the measurement unit is determined not to be in an alarm state, but only to be in a temporary abnormality, and there is no need to trigger shutdown protection.

[0135] For example, if the key status information is an output voltage of 10V, but the rated voltage range in the configuration parameter information is 0-5V, it indicates that the measuring unit is in an overvoltage state and is in an alarm state.

[0136] By cross-validating key status information and configuration parameter information, we can ensure that protection is triggered in a timely manner when the equipment is abnormal, and avoid the impact of misoperation on the operation of the equipment, thus ensuring the stability and reliability of the system operation.

[0137] S407: Generates a fault log and generates a general stop command for the general function interface of the abstract device.

[0138] When a measurement unit is determined to be in an alarm state, the system needs to generate a fault log and immediately stop the problematic measurement unit.

[0139] First, based on the general function interface of the abstract device, a general stop command is generated. The general stop command is a type of general call command. This general stop command is a standardized shutdown command for all measurement units. It does not depend on the communication protocol of the specific measurement unit. It only corresponds to the "device stop" general function interface defined in the abstract device, ensuring that shutdown control of measurement units of different models and different protocols can be achieved through a unified command format.

[0140] Then, the log collection process is automatically started. Key data before and after the alarm occurs are extracted from the log record queue of the subclass object of the corresponding measurement unit. The data is then packaged, formatted, and used to generate a fault log file, which is stored in the preset storage space for subsequent fault tracing, cause analysis, and equipment operation and maintenance.

[0141] S408: Converts a general stop instruction into a subclass stop instruction using a subclass object of the measurement unit.

[0142] In the embodiments of this application, the general stop instruction includes a general stop instruction, and the subclass operation instruction includes a subclass stop instruction.

[0143] S409: Send the subclass stop command to the corresponding measurement unit.

[0144] S410: Continue receiving subclass response information sent by the measurement unit.

[0145] Similar to the execution logic of general call instructions, it is necessary to convert general stop instructions into subclass stop instructions through the subclass object of the measurement unit. The subclass stop instruction is a type of subclass operation instruction, which is specifically used for the stop operation of a specific measurement unit.

[0146] In another optional embodiment, if the measurement unit is not in an alarm state after cross-validation, there is no need to trigger shutdown protection and fault log generation operations. The system returns to the normal monitoring state, continues to receive subclass response information sent by the measurement unit, and continues to monitor the device status.

[0147] In this application, the MVVM architecture decouples the user interface layer from the device virtualization layer. The scheduling and control layer acts as an intermediary hub, severing the direct connection between the two layers. The user interface layer is only responsible for user command input and result display, without needing to know the specific implementation logic of the device virtualization layer. The device virtualization layer is only responsible for device abstraction, command conversion, and business logic execution, without needing to concern itself with the display format and operation entry point of the user interface layer. The two layers indirectly interact through the scheduling and control layer. The user interface layer transmits user commands to the scheduling and control layer, which converts the commands into general call commands and sends them to the device virtualization layer. After execution, the device virtualization layer feeds back the results to the scheduling and control layer, which then synchronizes them back to the user interface layer.

[0148] Decoupling the user interface layer from the device virtualization layer reduces system maintenance costs. When optimizing the user interface, such as adjusting the display layout or adding new operation controls, there's no need to modify the business logic of the device virtualization layer. Similarly, when adapting to new measurement units or adjusting the adaptation rules of the device virtualization layer, the user interface layer remains unchanged, ensuring interface stability. Furthermore, it enhances system scalability and flexibility. The user interface layer can be independently iterated and upgraded based on user needs, while the device virtualization layer can be independently extended to adapt to more measurement units with more models and protocols. The two operate independently, significantly improving the system's adaptability and iteration efficiency across multiple scenarios.

[0149] By abstracting the device and unifying the command interface, the scheduling and control layer can simultaneously issue the same command to multiple measurement units, enabling synchronous control of multiple devices and greatly improving testing and production efficiency in mixed scenarios with multiple devices, especially multiple models of devices. By defining a common interface for the abstract device, different models of devices can be differentiated through subclasses, and source tables of various brands, models, and communication protocols can be managed in a unified way, reducing the complexity of the system connecting to new devices.

[0150] Figure 12 This is a flowchart illustrating an information display method provided in an embodiment of this application. Figure 2 In one alternative embodiment, the method may include: S501: In response to individual control commands received from multiple measurement units in the interactive interface layer, multiple sub-windows are displayed in the interactive interface layer.

[0151] S502: Bind multiple sub-windows to multiple measurement units respectively.

[0152] In one possible embodiment, when a user needs to monitor the operating status and data of multiple measurement units simultaneously, they will input a separate control command on the user terminal. This command is transmitted to the server via the interactive interface layer. The server's interactive interface layer responds to the command, generating multiple sub-windows on the interface. Each sub-window is bound to a different measurement unit, with each sub-window corresponding to one measurement unit, used to display relevant information about that device individually, thus achieving synchronous monitoring of multiple devices.

[0153] Figure 13 This is a schematic diagram of an information display page provided in an embodiment of this application. Figure 2 ,like Figure 13 As shown, the information of measurement units A and B is displayed separately in sub-windows. Sub-windows can also be displayed separately on different screens to further facilitate users' focus on individual measurement units.

[0154] S503: Displays data and status information of multiple measurement units in multiple sub-windows.

[0155] In one possible embodiment, the interactive interface layer obtains the corresponding measurement unit's operating data and standard device status from each subclass object through a data binding mechanism, and then displays them in the corresponding sub-windows. Users can view the operating status of multiple measurement units simultaneously through multiple sub-windows and intuitively compare the status and data differences of each device.

[0156] In one optional embodiment, the plurality of measurement units include a first measurement unit and a second measurement unit; the plurality of sub-windows include a first sub-window and a second sub-window; the general function interface includes a proprietary function interface and a common function interface; the common function interface is used to implement the common functions of the first measurement unit and the second measurement unit; the proprietary function interface is used to implement the first proprietary function of the first measurement unit and / or the second proprietary function of the second measurement unit.

[0157] In this embodiment of the application, data and status information of multiple measurement units are displayed on multiple sub-windows, including: S5031: Display the data, status information, and first function controls of the first measurement unit on the first sub-window.

[0158] The first functional control is used to implement common functions and the first proprietary function.

[0159] In one possible embodiment, the subclass object corresponding to the first measurement unit inherits the common function interface and the first proprietary function interface of the abstract device. The first proprietary function is a function unique to the first measurement unit. The interactive interface layer displays the operating data and standard device status of the first measurement unit in the first sub-window, and sets the first function control. The first function control includes common function buttons such as start, stop, and acquisition, and a first proprietary function button such as the dedicated calibration button for the first source meter. Users can directly trigger the relevant operations of the first measurement unit through the first function control to realize the proprietary control of the first measurement unit.

[0160] S5032: Displays the data, status information, and second function controls of the second measurement unit on the second sub-window.

[0161] The second function control is used to implement common functions and second proprietary functions.

[0162] In one possible embodiment, the second sub-window displays the operating data and standard device status of the second measurement unit. The second function control includes common function buttons such as start, stop, and acquisition, as well as a second proprietary function button. The second proprietary function is unique to the second measurement unit. Users can trigger relevant operations of the second measurement unit through the second function control to achieve proprietary control over the first measurement unit.

[0163] With the above settings, when the sub-window of the first measurement unit is opened, only the relevant controls of the first measurement unit can be displayed, such as function controls a, b, and c. Function controls a and b are basic function controls common to all measurement units, while function control c is unique to the first measurement unit. When the sub-window of the second measurement unit is opened, only the relevant controls of the second measurement unit can be displayed, such as function controls a, b, and d. Function control d is unique to the second measurement unit. For a single measurement unit, less frequently used functions can also be omitted from the interface, thus allowing for a more personalized and concise interface design.

[0164] S504: In response to a batch control command received from the interactive interface layer based on inputs from multiple measurement units, display the data and status information of multiple measurement units in the interactive interface layer.

[0165] In one possible embodiment, when a user needs to focus on monitoring a specific measurement unit, they can input a batch control command on the user terminal to specify the target measurement unit to view. The server's interactive interface layer responds to the command, closes the multi-sub-window mode, and displays the data, status information, and corresponding function controls of the target measurement unit separately. This allows the user to focus on viewing the detailed information of the target device and improves the accuracy of monitoring.

[0166] Figure 14This is a flowchart illustrating an information display method provided in an embodiment of this application. Figure 3 In one optional embodiment, the device management instructions include target device instructions and device operation instructions. That is, when managing measurement units in batches, it is necessary to first select the target device and then perform specific operations on the selected target device.

[0167] In one optional embodiment, in response to a batch control command received by the interactive interface layer based on inputs from multiple measurement units, data and status information of the multiple measurement units are displayed on the interactive interface layer, including: S5041: In response to a batch control command received from multiple measurement units in the interactive interface layer, the data, status information and multiple third-function controls of the multiple measurement units are displayed in the interactive interface layer.

[0168] When a user initiates batch control operations in the interactive interface layer, the core data and real-time status information of all selected measurement units, as well as multiple third-party function controls, are centrally displayed on the main interface of the interactive interface layer.

[0169] The measurement unit's data includes device identification, current output parameters, and operating status; the status information includes the device's current operating status such as idle, running, and standby. All of these are displayed after being normalized by the general state machine described above to ensure a consistent display format.

[0170] In this embodiment, the third function control is the operation entry point for the functions that can be executed by multiple measurement units. Each third function control corresponds to a specific device function, and the user can initiate the corresponding device operation command by clicking the third function control.

[0171] It should be noted that, in one possible embodiment, the third functional control is initially inactive and cannot be operated or clicked. Whether it is ultimately available depends on the executable functions of all selected target measurement units to ensure the compatibility of batch operations.

[0172] In one optional embodiment, in response to a device management command received by the interface layer, the scheduling control layer converts the device management command into a general call command for a general function interface of the abstract device, including: S5042: In response to the target device instruction received by the interactive interface layer, obtain the executable function of at least one target measurement unit corresponding to the target device instruction.

[0173] After initiating batch control, the user triggers the target device command by selecting multiple measurement units, thereby clarifying the target measurement units that need to be controlled. The system responds to the target device command and calls the subclass object corresponding to each target measurement unit through the scheduling control layer to obtain the executable functions of each target measurement unit.

[0174] Specifically, executable functions are pre-stored in subclass objects for the scheduling control layer to query and retrieve. For example, the executable functions of measurement unit A include function a and function b; the executable functions stored in the subclass object of measurement unit B include function a and function c; and the executable functions stored in the subclass object of measurement unit C include function c and function d.

[0175] S5043: Determine whether the executable function has a common function. If yes, execute S5044; otherwise, execute S5045.

[0176] This step is the core judgment link of the third function control state control. The system summarizes the executable functions of all target measurement units and determines whether there are common functions supported by all target measurement units through intersection operation.

[0177] If the selected target measurement units are two units, A and B, their executable functions are (function a, function b) and (function a, function c) respectively. The intersection of the two is function a, meaning there is a common function. In this case, further batch operations can be performed on measurement units A and B. If the target measurement units are three units, A, B, and C, their executable functions are (function a, function b), (function a, function c), and (function c, function d) respectively. There is no intersection among the three, meaning there is no common function. Further batch operations cannot be performed on measurement units A, B, and C.

[0178] By following the steps above, it can be ensured that batch operations can only execute functions supported by all target measurement units, thus avoiding problems such as operation failure or equipment malfunction due to some devices not supporting the function.

[0179] S5044: Set the third function control corresponding to the public function to the available state.

[0180] In an optional embodiment, if at least one target measurement unit has a common function among its executable functions, the third function control corresponding to the common function is set to an available state.

[0181] When it is determined that there is a common function among the executable functions of all target measurement units, the system sets the third function control corresponding to the common function to an available state, that is, the control is displayed as operable, such as the control is displayed as green and clickable. Users can use the control to initiate batch operations on all target measurement units to achieve synchronous control.

[0182] For example, when there are two target measurement units, A and B, the common function is function a. The system sets the third function control corresponding to function a to an available state. After the user clicks the control, the operation command corresponding to function a can be sent to both devices A and B at the same time to achieve batch control. However, the third function controls corresponding to functions c and b remain in an inoperable state to avoid user misoperation.

[0183] S5045: Set the third function control to an unavailable state.

[0184] When it is determined that there is no common function among the executable functions of all target measurement units, the system sets all third-party function controls to an unavailable state, that is, the controls are displayed as inoperable, such as grayed out or unclickable. At the same time, a prompt message can be displayed in the interactive interface layer, such as "The selected device has no common executable function and batch operation cannot be performed", to inform the user that the current batch control cannot be executed.

[0185] For example, when there are three target measurement units, A, B, and C, and none of them have a common executable function, all third-party function controls, such as function a and function c, are set to an unavailable state. Users cannot initiate batch operations, thus avoiding device control abnormalities caused by functional incompatibility and ensuring the stability of system operation.

[0186] In another alternative embodiment, if the executable functions of at least one target measurement unit have common functions, the third function control is set to an unavailable state.

[0187] S5046: In response to the device operation command received by the interactive interface layer based on the input of the third function control corresponding to the common function, the scheduling control layer converts the device operation command into a general call command for the general function interface of the abstract device.

[0188] When the third function control is available, the user can click on it to input the corresponding device operation command. The system responds to the command, and the scheduling control layer converts it into a general call command for the general function interface of the abstract device, according to the command conversion logic described above. This general call command is a standardized command format that does not depend on the communication protocol of the specific target measurement unit. It only corresponds to the general function interface defined in the abstract device, ensuring that batch synchronous control of all target measurement units can be achieved through a unified command format.

[0189] Subsequently, the subclass objects corresponding to each target measurement unit will receive the general call instruction and convert it into subclass operation instructions that can be recognized by their own devices, and execute the corresponding operations to achieve the synchronization and consistency of batch control.

[0190] Figure 15This is a flowchart illustrating a source table debugging method provided in an embodiment of this application. The method may include: S601: In response to a device debugging command triggered by a device debugging control received in the interactive interface layer, display the device debugging page in the interactive interface layer.

[0191] Figure 16 This is a schematic diagram of a device debugging page provided in an embodiment of this application. In one possible embodiment, such as... Figure 16 As shown, the device debugging page on the user terminal has device debugging controls. When a user needs to debug a measurement unit, clicking the control triggers a device debugging command, which is transmitted to the server via the interactive interface layer. The server's interactive interface layer responds to the command, generating and displaying the device debugging page. This page includes a debugging information display area, a command sending area, a command remarks area, debugging controls, etc., providing the user with an entry point for debugging operations.

[0192] S602: In response to a dedicated debugging command received from the device debugging page, send the dedicated debugging command to the corresponding subclass object.

[0193] In this embodiment, a dedicated debugging instruction is used to instruct the measurement unit bound to the subclass object to perform a proprietary operation.

[0194] In one possible embodiment, a dedicated debugging command is a command entered by the user on the device debugging page for testing the proprietary functions of the measurement unit or troubleshooting faults. Examples include a calibration command or fault detection command specific to a particular measurement unit model. This command is transmitted to the scheduling control layer via the user interface layer. The scheduling control layer parses the command, determines the corresponding target subclass object, and sends the dedicated debugging command to that subclass object. The dedicated debugging command corresponds to a proprietary operation of the measurement unit and can only be executed by the corresponding model of measurement unit; other models of devices cannot respond.

[0195] S603: If proprietary response information is received from the measurement unit based on the dedicated debugging command, the proprietary response information will be displayed on the device debugging page.

[0196] In one possible embodiment, after receiving a dedicated debugging instruction forwarded by a subclass object, the measurement unit executes the corresponding dedicated operation and encapsulates the operation result, device status, and other information into dedicated response information, which is then sent to the bound subclass object. The subclass object forwards the dedicated response information to the scheduling control layer, which then synchronizes it to the interactive interface layer. The interactive interface layer displays this information in the debugging information display area of ​​the device debugging page. Users can determine whether the measurement unit's dedicated functions are normal, the cause of any faults, etc., based on the dedicated response information, thus completing the device debugging process.

[0197] The above debugging can achieve differentiated adaptation verification in unified management and control. The core of unified management of multiple measurement units is to achieve the unification of interfaces and states by abstracting devices and subclass objects. However, the proprietary functions of source tables of different models are different. Dedicated debugging can accurately verify the adaptation accuracy of subclass objects to proprietary functions, ensuring that subclass objects can correctly forward proprietary debugging instructions and provide proprietary response information, and avoid affecting the overall unified management and control effect due to proprietary function adaptation anomalies.

[0198] Furthermore, to ensure the stability and reliability of unified management, dedicated debugging can proactively identify and address issues such as proprietary function failures of measurement units (MMUs) and abnormal binding between subclass objects and MMUs. This allows for timely handling of potential equipment problems and prevents a single source table's proprietary function failure from spreading to the entire multi-MMU management system, ensuring the stability of unified scheduling and synchronous operation of multiple MMUs. The dedicated debugging process achieves unified management across the entire process, from equipment addition and daily control to fault debugging, further enhancing the completeness and practicality of unified MMU management. This ensures that MMUs of different models and protocols can be both uniformly scheduled and precisely debugged, comprehensively meeting the actual needs of multi-MMU management.

[0199] Figure 17 This is a flowchart illustrating a log display method provided in an embodiment of this application. The method may include: S701: Create a log recording queue for each subclass object.

[0200] In one possible embodiment, while creating a subclass object for each measurement unit, the server also creates a separate log recording queue for each subclass object to store all relevant operation logs of the measurement unit corresponding to that subclass object, thereby achieving classified management of logs and making it convenient for users to query logs by device.

[0201] S702: Record user interface operation events related to the subclass object, subclass operation instructions sent to the measurement unit, and subclass response information received from the measurement unit in the log recording queue in chronological order.

[0202] In one possible implementation, the log recording queue records logs in chronological order, specifically from morning to night.

[0203] Among them, user interface operation events are interface operation events related to the measurement unit triggered by the user on the user terminal, such as adding a device, starting a device, debugging a device, etc.; subclass operation instructions are subclass operation instructions sent by the subclass object to the measurement unit, such as start instructions, acquisition instructions, etc.; subclass response information is subclass response information returned by the measurement unit to the subclass object, such as device status, acquired data, etc.

[0204] To help users distinguish between different types of log information, user interface operation events, subclass operation instructions, and subclass response information are displayed with different colors or symbols.

[0205] Figure 18 This is a schematic diagram of a log display page provided in an embodiment of this application. In one possible embodiment, such as... Figure 18 As shown, this application displays user operation events in blue, operation commands in black, and response information in yellow. Users can quickly identify various types of information when viewing logs, improving log viewing efficiency. Simultaneously, the log recording queue will permanently store log information, facilitating users to trace operation history and troubleshoot equipment malfunctions later.

[0206] Figure 19 This is a flowchart illustrating an image display method provided in an embodiment of this application. Figure 1 The method may include: S801: In response to the data storage instruction received by the interactive interface layer based on the input of the target measurement unit, the data of the bound measurement unit is converted into standard format data through the subclass object corresponding to the target measurement unit.

[0207] In one possible embodiment, when a user needs to store the operational data of a measurement unit, they input a data storage command on the user terminal. This command is transmitted to the device virtualization layer via the interactive interface layer and the scheduling control layer. After receiving the command, the subclass object of the device virtualization layer collects the operational data of the bound measurement unit and converts the raw data into standard format data according to the predefined standard data format of the abstract device. This unifies the data from different measurement units and provides a basis for subsequent data comparison and analysis.

[0208] S802: Store standard format data in the fourth storage space.

[0209] In this embodiment, the fourth storage space is a dedicated data storage area built into the server, used to uniformly store standard format data of all measurement units. It is independent of the first, second, and third storage spaces that store configuration parameter information, realizing classified storage of data and facilitating quick retrieval and management by users.

[0210] S803: In response to a curve generation command triggered by multiple measurement units received from the interactive interface layer, standard format data of multiple measurement units are retrieved from the fourth storage space.

[0211] In one possible embodiment, when a user needs to analyze the operational data trends of multiple measurement units, they specify the target measurement units and input a curve generation command on the user terminal. There can be multiple target measurement units. The curve generation command is transmitted to the scheduling and control layer via the interactive interface layer. The scheduling and control layer responds to the command by retrieving standard-format data from the specified multiple measurement units from the fourth storage space, providing data support for curve generation.

[0212] S804: Generates multiple graphs and charts based on standard format data from multiple measurement units.

[0213] In one possible embodiment, after the interactive interface layer receives standard format data retrieved by the scheduling control layer, it generates corresponding curves and charts for each measurement unit according to the data type and time dimension. The curves and charts can intuitively display the changing trend of the measurement unit's operating data, making it easy for users to quickly analyze the operating status of the equipment.

[0214] S805: In response to the overlay display instruction received by the interactive interface layer, multiple curve charts are overlaid and displayed in the same coordinate area of ​​the interactive interface layer.

[0215] In one possible embodiment, when a user needs to compare the changing trends of the operating data of multiple measurement units, they can input an overlay display command on the user terminal. The server's interactive interface layer responds to the command and overlays multiple generated curves and charts in the same coordinate area. The user can intuitively compare the data differences and consistency of changing trends of multiple devices, thereby improving the efficiency and accuracy of data comparison and analysis.

[0216] If colors are randomly added to the loaded waveform curves, there is a lack of memory points, making the analysis less intuitive. Therefore, the time-series color card mechanism of this application was designed to improve the intuitiveness and readability of data display by mapping time through colors. Figure 20 This is a flowchart illustrating an image display method provided in an embodiment of this application. Figure 2 The method may include: S901: In response to the curve generation command triggered by the measurement unit received by the interactive interface layer, the standard format data of the measurement unit is retrieved from the fourth storage space.

[0217] In one possible embodiment, the standard format data includes multiple sub-data corresponding to different time information.

[0218] In one possible embodiment, the standard format data retrieved by the scheduling control layer contains multiple sub-data, each sub-data corresponding to a specific time point, such as data collected every 100ms, providing time and data dimension support for the generation of the gradient curve.

[0219] S902: Determine the transparency information for each sub-data based on time information and preset transparency mapping rules.

[0220] In one possible embodiment, the preset transparency mapping rule is a predefined transparency allocation rule based on time information. In this application, the predefined preset transparency mapping rule is that the later the time, the lower the transparency, and the earlier the time, the higher the transparency.

[0221] The interactive interface layer assigns corresponding transparency information to each sub-data based on the time information corresponding to each sub-data and in combination with the preset transparency mapping rules, so that the curve presents different transparency at different time periods.

[0222] S903: Generates a transparency gradient curve based on multiple sub-data, time information, and transparency information of the sub-data.

[0223] In one possible implementation, the user interface layer combines the numerical value of each sub-data point, the corresponding time information, and the assigned transparency information to generate a transparency gradient curve. Different segments of the final generated curve exhibit varying transparency, visually demonstrating the data's trend over time, enhancing the curve's visual appeal, and making it easier for users to distinguish data changes across different time periods.

[0224] Figure 21 This is a flowchart illustrating an image display method provided in an embodiment of this application. Figure 3 The method may include: S901: In response to a curve generation command triggered by the measurement unit received from the interactive interface layer, standard format data of the measurement unit is retrieved from the storage space.

[0225] S902: Determine the tone information corresponding to each sub-data based on time information and preset tone mapping rules.

[0226] In one possible embodiment, the preset tone mapping rule is a predefined tone allocation rule based on time information. In this application, the predefined preset tone mapping rule is that the earlier the time, the cooler the color, and the later the time, the warmer the color.

[0227] The interactive interface layer assigns corresponding color information to each sub-data based on the time information corresponding to each sub-data and in combination with the preset color mapping rules.

[0228] S903: Generates a hue gradient curve based on multiple sub-data, time information, and hue information of the sub-data.

[0229] In one possible embodiment, the interactive interface layer combines the numerical value of each sub-data, the corresponding time information, and the assigned hue information to generate a hue gradient curve.

[0230] Figure 22 This is a schematic diagram of an image display page provided in an embodiment of this application, such as... Figure 22 As shown, the different segments of the final generated curve present different hues, which can not only intuitively show the trend of data changes over time, but also distinguish the early and late data values ​​through hue differences, thus improving the intuitiveness and readability of the data display.

[0231] This application also provides a multi-measurement unit adding device. Figure 23 This is a schematic diagram of the structure of a multi-measurement unit adding device provided in an embodiment of this application, as shown below. Figure 23 As shown, the device 1000 includes: The device adding module 1010 is used to respond to the device adding command received by the interactive interface layer, and to create and bind subclass objects for at least one measurement unit to be added; the interactive interface layer is used to form an MVVM architecture with the scheduling control layer and the device virtualization layer; the interactive interface layer is coupled with the scheduling control layer; the subclass objects inherit from the abstract device, which is a virtual device built in the device virtualization layer to define a common function interface, and the subclass objects are used to drive the measurement units bound to them to implement the subclass operations corresponding to the common function interface; The thread allocation module 1020 is used to allocate an independent running thread for each subclass object through the scheduling control layer; The information display module 1030 is used to display data and status information of at least one measurement unit on the interactive interface layer.

[0232] In an optional embodiment, it further includes: The architecture building module is used to build an MVVM architecture that includes an interactive interface layer, a scheduling and control layer, and a device virtualization layer. The device virtualization module is used to build abstract devices in the device virtualization layer. The abstract device maintains a general state machine. Multiple subclass objects inherit from and maintain the general state machine. The general state machine defines multiple standard device states, state transition logic, and state normalization rules. The state normalization rules are used to convert the subclass state information returned by multiple measurement units into standard device states.

[0233] In an optional embodiment, it further includes: The first acquisition module is used to acquire the device type of the measurement unit in response to the device addition command received from the interactive interface layer; The object creation module is used to create at least one subclass object based on the device type and bind the subclass object to the corresponding measurement unit; the subclass object inherits the general state machine and general function interface of the abstract device; The first information loading module is used to load configuration parameter information for each subclass object; The data binding module is used to register subclass objects to the scheduling control layer and associate the state of subclass objects with data to the interactive interface layer through data binding.

[0234] In one optional embodiment, the configuration parameter information includes device configuration information, operation plan information, and compensation plan information; it also includes: The second information loading module is used to load configuration parameter information for subclass objects in response to device configuration information, operation plan information and compensation plan information received from the interactive interface layer. The first storage module is used to store the device configuration information in the first storage space in response to the device configuration save command received by the interactive interface layer. The second storage module is used to store the running plan information in the second storage space in response to the running plan saving instruction received by the interactive interface layer. The third storage module is used to store the compensation scheme information in the third storage space in response to the compensation scheme saving instruction received by the interactive interface layer; the first storage space, the second storage space and the third storage space are independent of each other.

[0235] In an optional embodiment, it further includes: The list display module is used to display a selection list of stored device configuration information, operation plan information, and compensation plan information in the interactive interface layer; the selection list includes multiple configuration plans. The determination module is used to determine the target configuration scheme from multiple configuration schemes in response to the scheme selection instruction received by the interactive interface layer. The third information loading module is used to load configuration parameter information for subclass objects based on the device configuration information, operation plan information and compensation plan information corresponding to the target configuration plan.

[0236] In an optional embodiment, it further includes: The second acquisition module is used to acquire the functions to be added to the measurement unit in response to the device addition command received by the interactive interface layer; The interface definition module is used to create and bind subclass objects for at least one measurement unit to be added if the general function interface matches the function to be added; or, if the general function interface does not match the function to be added, to define the function interface to be added in the abstract device and create and bind subclass objects for at least one measurement unit to be added.

[0237] In an optional embodiment, it further includes: The first conversion module is used to respond to the device management instructions received by the interactive interface layer and convert the device management instructions into general call instructions for the general function interface of the abstract device through the scheduling control layer. The instruction sending module is used to send general invocation instructions to the corresponding subclass objects; The second conversion module is used to convert general call instructions into subclass operation instructions through subclass objects; the subclass operation instructions are used to instruct the measurement unit bound to the subclass object to perform subclass operations.

[0238] The apparatus and method embodiments in this application are based on the same application concept.

[0239] The methods and embodiments provided in this application can be executed on a computer terminal, server, or similar computing device. Taking running on a server as an example, Figure 24 This is a hardware structure block diagram of a server for a method of adding multiple measurement units provided in an embodiment of this application. For example... Figure 24 As shown, the server 1100 can vary significantly due to different configurations or performance. It may include one or more Central Processing Units (CPUs) 1110 (CPUs 1110 may include, but are not limited to, microprocessors (MCUs) or programmable logic devices (FPGAs), a memory 1130 for storing data, and one or more storage media 1120 (e.g., one or more mass storage devices) for storing application programs 1123 or data 1122. The memory 1130 and storage media 1120 may be temporary or persistent storage. The program stored in the storage media 1120 may include one or more modules, each module may include a series of instruction operations on the server. Furthermore, the CPU 1110 may be configured to communicate with the storage media 1120 and execute the series of instruction operations stored in the storage media 1120 on the server 1100. Server 1100 may also include one or more power supplies 1160, one or more wired or wireless network interfaces 1150, one or more input / output interfaces 1140, and / or one or more operating systems 1121, such as Windows Server™, Mac OSX™, Unix™, Linux™, FreeBSD™, etc.

[0240] The input / output interface 1140 can be used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of server 1100. In one example, the input / output interface 1140 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the input / output interface 1140 may be a radio frequency (RF) module used for wireless communication with the Internet.

[0241] Those skilled in the art will understand that Figure 24 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, server 1100 may also include... Figure 24 The more or fewer components shown, or having the same Figure 24 The different configurations shown.

[0242] This application provides an electronic device, which includes a processor and a memory. The memory stores at least one instruction, at least one program, code set, or instruction set. The processor loads and executes the at least one instruction, at least one program, code set, or instruction set to implement the above-described data processing method.

[0243] Embodiments of this application also provide a computer-readable storage medium, which can be disposed in a server to store at least one instruction, at least one program, code set, or instruction set related to implementing a multi-measurement unit addition method in the method embodiment. The at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by the processor to implement the above-described multi-measurement unit addition method.

[0244] Optionally, in this embodiment, the storage medium may be located at at least one of the multiple network servers in a computer network. Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0245] As can be seen from the embodiments of the multi-measurement unit adding method, apparatus, electronic device, or storage medium provided in this application, in response to the device adding instruction received by the interactive interface layer, subclass objects are created and bound for at least one measurement unit to be added; the interactive interface layer is used to form an MVVM architecture with the scheduling control layer and the device virtualization layer; the interactive interface layer is coupled with the scheduling control layer; the subclass objects inherit from the abstract device, which is a virtual device constructed in the device virtualization layer to define a general function interface, and the subclass objects are used to drive the measurement units bound to them to implement the subclass operations corresponding to the general function interface; an independent running thread is allocated to each subclass object through the scheduling control layer; and the data and status information of at least one measurement unit are displayed in the interactive interface layer. In this embodiment, through the abstract device and general function interface of the device virtualization layer, different types of measurement units can be adapted through inheritance. There is no need to develop control logic separately for a single device, which greatly simplifies the access process of new devices. Operators only need to issue device addition instructions to complete the creation, binding and thread allocation of subclass objects, which reduces the operation threshold for device access. New measurement units can be quickly accessed and data and status can be displayed synchronously, which is convenient for batch addition and deployment of multiple measurement units.

[0246] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, specific embodiments have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0247] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0248] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0249] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for adding multiple measurement units, characterized in that, include: In response to the device addition command received from the interactive interface layer, create and bind subclass objects for at least one measurement unit to be added; The interactive interface layer is used to form an MVVM architecture with the scheduling control layer and the device virtualization layer; the interactive interface layer is coupled with the scheduling control layer. The subclass object inherits from the abstract device, which is a virtual device constructed in the device virtualization layer to define a general function interface. The subclass object is used to drive the measurement unit bound to it to implement the subclass operation corresponding to the general function interface. The scheduling control layer allocates an independent running thread to each of the subclass objects. The interactive interface layer displays data and status information of at least one of the measurement units.

2. The method for adding multiple measurement units according to claim 1, characterized in that, Before creating and binding subclass objects for at least one measurement unit to be added in response to a device addition instruction received from the interface layer, the method further includes: Construct an MVVM architecture that includes the interactive interface layer, the scheduling control layer, and the device virtualization layer; The abstract device is constructed in the device virtualization layer; the abstract device maintains a general state machine; multiple subclass objects inherit from and maintain the general state machine; the general state machine defines multiple standard device states, state transition logic, and state normalization rules; the state normalization rules are used to convert the subclass state information returned by the multiple measurement units into the standard device states.

3. The method for adding multiple measurement units according to claim 2, characterized in that, The process of responding to a device addition command received from the interface layer by creating and binding subclass objects for at least one measurement unit to be added includes: In response to a device add command received by the interactive interface layer, the device type of the measurement unit is obtained; At least one subclass object is created based on the device type, and the subclass object is bound to the corresponding measurement unit; the subclass object inherits the general state machine and general function interface of the abstract device; Load configuration parameter information for each of the subclass objects; The subclass object is registered to the scheduling control layer, and the state and data of the subclass object are associated with the interactive interface layer through data binding.

4. The method for adding multiple measurement units according to claim 3, characterized in that, The configuration parameter information includes equipment configuration information, operation plan information, and compensation plan information; The step of loading configuration parameter information for each of the subclass objects includes: In response to the device configuration information, the operation plan information, and the compensation plan information received by the interactive interface layer, the configuration parameter information is loaded for the subclass object; In response to the device configuration save command received by the interactive interface layer, the device configuration information is stored in the first storage space; In response to the operation plan saving instruction received by the interactive interface layer, the operation plan information is stored in the second storage space; In response to the compensation scheme saving instruction received by the interactive interface layer, the compensation scheme information is stored in the third storage space; the first storage space, the second storage space, and the third storage space are independent of each other.

5. The method for adding multiple measurement units according to claim 4, characterized in that, The step of loading configuration parameter information for the subclass object also includes: The interactive interface layer displays a selection list of the stored device configuration information, operation plan information, and compensation plan information; the selection list includes multiple configuration plans. In response to the scheme selection instruction received by the interactive interface layer, a target configuration scheme is determined from the plurality of configuration schemes; The configuration parameter information is loaded for the subclass object based on the device configuration information, the operation scheme information, and the compensation scheme information corresponding to the target configuration scheme.

6. The method for adding multiple measurement units according to claim 1, characterized in that, The process of responding to a device addition command received from the interface layer by creating and binding subclass objects for at least one measurement unit to be added includes: In response to the device addition command received by the interactive interface layer, the function to be added to the measurement unit is obtained; If the general function interface matches the function to be added, create and bind subclass objects for each of the at least one measurement unit to be added; or, if the general function interface does not match the function to be added, define the function interface to be added in the abstract device, and create and bind subclass objects for each of the at least one measurement unit to be added.

7. The method for adding multiple measurement units according to claim 1, characterized in that, The method further includes: In response to the device management command received by the interactive interface layer, the scheduling control layer converts the device management command into a general call command for the general function interface of the abstract device; Send the general invocation instruction to the corresponding subclass object; The general invocation instruction is converted into a subclass operation instruction through the subclass object; the subclass operation instruction is used to instruct the measurement unit bound to the subclass object to perform the subclass operation.

8. A multi-measurement unit adding device, characterized in that, The device includes: The device adding module is used to create and bind subclass objects for at least one measurement unit to be added in response to a device adding command received from the interactive interface layer. The interactive interface layer is used to form an MVVM architecture with the scheduling control layer and the device virtualization layer. The interactive interface layer is coupled with the scheduling control layer. The subclass objects inherit from the abstract device, which is a virtual device constructed in the device virtualization layer to define a general function interface. The subclass objects are used to drive the measurement units bound to them to implement the subclass operations corresponding to the general function interface. A thread allocation module is used to allocate an independent running thread for each of the subclass objects through the scheduling control layer; An information display module is used to display data and status information of at least one of the measurement units on the interactive interface layer.

9. An electronic device comprising a processor and a memory, the memory storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is loaded and executed by the processor to implement the multi-measurement unit addition method as described in any one of claims 1-7.

10. A computer-readable storage medium storing at least one instruction or at least one program, wherein the at least one instruction or at least one program is loaded and executed by a processor to implement the multi-measurement unit addition method as described in any one of claims 1-7.

Images