A multi-measurement unit virtualization management method and device

Abstract

The application discloses a kind of multi-measuring unit virtualization management method and device, method includes: in response to the equipment management instruction based on at least one trigger in multiple measuring units received by interactive interface layer, by scheduling control layer, equipment management instruction is converted into the general call instruction of general function interface facing abstract device;Interactive interface layer, scheduling control layer are used to and equipment virtualization layer constitute MVVM architecture;Interactive interface layer is coupled with scheduling control layer;Multiple measuring units are bound multiple subclass objects respectively, and multiple subclass objects have independent running thread;Subclass object inherits abstract device;General call instruction is sent to corresponding subclass object;General call instruction is converted into subclass operation instruction by subclass object;Subclass operation instruction is used to indicate the measuring unit of subclass object binding to execute subclass operation, can realize the synchronous control of multiple equipment, greatly improves test and production efficiency.

Description

Technical Field

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

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

[0003] Currently, industry control of source meters primarily relies on dedicated host computer software provided by equipment manufacturers or self-developed single-device control programs. This type of software is typically tied to a specific model or series of source meters, 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. Traditional software usually only allows connection and operation with one source meter device at a time, requiring users to manually set all output and measurement parameters. After starting the test, the software is responsible for issuing commands, monitoring status, and collecting data. When the same test procedure needs to be performed on multiple source meters, or even multiple models, users must repeat the same operation for each device, which is time-consuming and labor-intensive, severely restricting production testing and machine verification efficiency. Summary of the Invention

[0004] To address existing technical problems, this invention provides a multi-measurement unit virtualization management method and apparatus. By abstracting roles and unifying the command interface, the scheduling and control layer can simultaneously issue the same command to multiple devices, achieving synchronous control of multiple devices and greatly improving testing and production efficiency in mixed scenarios with multiple devices, especially multiple models of devices. By abstracting devices and defining a common interface, different models of devices are differentiated through subclasses. Source tables of various brands, models, and communication protocols can be managed in a unified way, reducing the complexity of system integration with new devices. Simultaneously, the MVVM architecture separates the user interface and device control, allowing interface design to be independent of functional implementation, enhancing the system's maintainability and scalability.

[0005] In a first aspect, embodiments of this application provide a multi-measurement unit virtualization management method, the method comprising: In response to a device management command received by the interface layer based on at least one of multiple measurement units, the scheduling control layer converts the device management command into a general call command for the general function interface of the abstract device. The interface layer, scheduling control layer, and device virtualization layer form an MVVM architecture. The interface layer and scheduling control layer are coupled. The abstract device is a virtual device built in the device virtualization layer to define the general function interface. Multiple measurement units are bound to multiple subclass objects, and each subclass object has an independent running thread. The subclass objects inherit from the abstract device and are used to drive the measurement units bound to them to implement the subclass operations corresponding to the general function interface. Send the general invocation instruction to the corresponding subclass object; The general invocation instructions are converted 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.

[0006] Secondly, embodiments of this application provide a multi-measurement unit virtualization management device, the device comprising: The first conversion module is used to respond to device management commands received by the interactive interface layer based on at least one of multiple measurement units, and converts the device management commands into general call commands for the general function interface of the abstract device through the scheduling control layer. The interactive interface layer, the scheduling control layer, and the device virtualization layer form an MVVM architecture. The interactive interface layer and the scheduling control layer are coupled. The abstract device is a virtual device built in the device virtualization layer to define the general function interface. Multiple measurement units are respectively bound to multiple subclass objects, and multiple subclass objects have independent running threads. The subclass objects inherit from the abstract device and are used to drive the measurement units bound to them to implement the subclass operations corresponding to the general function interface. 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.

[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 virtualization management 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 virtualization management 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 virtualization management method of the first aspect.

[0010] The multi-measurement unit virtualization management method and apparatus provided in this application have the following technical effects: In response to a device management command received by the interface layer based on at least one of multiple measurement units, the scheduling control layer converts the device management command into a general call command for a general function interface of the abstract device. The interface layer, scheduling control layer, and device virtualization layer form an MVVM architecture. The interface layer and scheduling control layer are coupled. The abstract device is a virtual device built in the device virtualization layer to define the general function interface. Multiple measurement units are bound to multiple subclass objects, and each subclass object has an independent running thread. The subclass objects inherit from the abstract device and are used to drive the measurement units bound to them to implement the subclass operations corresponding to the general function interface. The general call command is sent to the corresponding subclass object. The subclass object converts the general call command into a subclass operation command. The subclass operation command is used to instruct the measurement unit bound to the subclass object to execute the subclass operation. In this embodiment, by unifying the command interface through the abstract role, the scheduling control layer can simultaneously issue the same command to multiple devices, realizing synchronous control of multiple measurement units, which greatly improves the testing and production efficiency in mixed scenarios with multiple devices, especially multiple models of devices. By defining a common interface through abstract devices, different models of devices can be differentiated through subclasses. This allows for the unified management of measurement units of various brands, models, and communication protocols, reducing the complexity of system integration with new measurement units. At the same time, the MVVM architecture separates the user interface from device control, enabling interface design to be independent of function implementation, thus enhancing the maintainability and scalability of the system. 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 2This is a flowchart illustrating a multi-measurement unit virtualization management method provided in an embodiment of this application. Figure 1 ; Figure 3 This is a flowchart illustrating a multi-measurement unit virtualization management method 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 management page provided in an embodiment of this application; Figure 6 This is a flowchart illustrating an information display method provided in an embodiment of this application. Figure 1 ; Figure 7 This is a schematic diagram of an information display page provided in an embodiment of this application. Figure 1 ; Figure 8 This is a flowchart illustrating an information display method provided in an embodiment of this application. Figure 2 ; Figure 9 This is a schematic diagram of an information display page provided in an embodiment of this application. Figure 2 ; Figure 10 This is a flowchart illustrating an information display method provided in an embodiment of this application. Figure 3 ; Figure 11 This is a flowchart illustrating a source table debugging method provided in an embodiment of this application; Figure 12 This is a schematic diagram of a device debugging page provided in an embodiment of this application; Figure 13 This is a flowchart illustrating a log display method provided in an embodiment of this application; Figure 14 This is a schematic diagram of a log display page provided in an embodiment of this application; Figure 15 This is a flowchart illustrating an image display method provided in an embodiment of this application. Figure 1 ; Figure 16 This is a flowchart illustrating an image display method provided in an embodiment of this application. Figure 2 ; Figure 17 This is a flowchart illustrating an image display method provided in an embodiment of this application. Figure 3 ; Figure 18 This is a schematic diagram of an image display page provided in an embodiment of this application; Figure 19This is a schematic diagram of the structure of a multi-measurement unit virtualization management device provided in an embodiment of this application; Figure 20 This is a hardware structure block diagram of a server for a multi-measurement unit virtualization management method 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 a device management command received by the interaction interface layer based on at least one of the multiple measurement units 101, and converts the device management command into a general call command for the general function interface of the abstract device through the scheduling control layer. The interaction interface layer, the scheduling control layer, and the device virtualization layer form an MVVM architecture. The interaction interface layer is coupled with the scheduling control layer. The abstract device is a virtual device built in the device virtualization layer to define the general function interface. The multiple measurement units 101 are respectively bound to multiple subclass objects, and the multiple subclass objects have independent running threads. The subclass objects inherit from the abstract device and are used to drive the measurement units 101 bound to them to implement the subclass operations corresponding to the general function interface. The general call command is sent to the corresponding subclass object. The general call command is converted into a subclass operation command through the subclass object. The subclass operation command is used to instruct the measurement unit 101 bound to the subclass object to perform the subclass operation.

[0025] In this embodiment, by abstracting roles and unifying the command interface, the scheduling and control layer can simultaneously issue the same command to multiple devices, achieving synchronous control of multiple measurement units 101, which greatly improves testing and production efficiency in mixed scenarios with multiple devices, especially multiple models of devices. By abstracting devices and defining a common interface, different models of devices are differentiated through subclasses, allowing for unified management of measurement units 101 of various brands, models, and communication protocols, reducing the complexity of system integration with new measurement units 101. At the same time, the MVVM architecture separates the user interface and device control, allowing interface design to be independent of functional implementation, enhancing the maintainability and scalability of the system.

[0026] The following describes a specific embodiment of a multi-measurement unit virtualization management method according to this application. Figure 2 This is a flowchart illustrating a multi-measurement unit virtualization management method 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 a device management command received by the interface layer based on at least one of multiple measurement units, the scheduling control layer converts the device management command into a general call command for the general function interface of the abstract device. The interface layer, scheduling control layer, and device virtualization layer form an MVVM architecture. The interface layer and scheduling control layer are coupled. The abstract device is a virtual device built in the device virtualization layer to define the general function interface. Multiple measurement units are bound to multiple subclass objects, and multiple subclass objects have independent running threads. The subclass objects inherit from the abstract device and are used to drive the measurement units bound to them to implement the subclass operations corresponding to the general function interface.

[0027] S202: Send the general invocation instruction to the corresponding subclass object.

[0028] S203: Convert general invocation instructions into subclass operation instructions through subclass objects; subclass operation instructions are used to instruct the measurement unit bound to the subclass object to perform subclass operations.

[0029] Figure 3 This is a flowchart illustrating a multi-measurement unit virtualization management method 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 subclass objects corresponding to the abstract device and multiple measurement units 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] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

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

[0040] 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.

[0041] 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".

[0042] 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.

[0043] S3021: Obtain the device type for multiple measurement units.

[0044] In this embodiment, before creating a subclass object, it is necessary to obtain the device types of multiple measurement units. When adding a device, the user needs to input detailed device information. 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.

[0045] 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.

[0046] S3022: Create multiple subclass objects based on the device type and bind the subclass objects to the corresponding measurement units.

[0047] 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.

[0048] 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.

[0049] S3023: Load configuration parameter information for each subclass object.

[0050] 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.

[0051] S3024: 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.

[0052] 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.

[0053] 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.

[0054] In one optional embodiment, the configuration parameter information includes device configuration information, operation plan information, and compensation plan information.

[0055] 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.

[0056] S303: In response to a device management instruction received by the interactive interface layer based on at least one of multiple measurement units, the device management instruction is converted into a general call instruction for a general function interface for the abstract device through the scheduling control layer.

[0057] 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.

[0058] Figure 5 This is a schematic diagram of a device management page provided in an embodiment of this application. In one possible embodiment, such as... Figure 5 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.

[0059] 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.

[0060] S304: 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.

[0061] 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.

[0062] 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: S3041: Determine the currently executing subclass object as the current object.

[0063] 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.

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

[0065] 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.

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

[0067] 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 S3042 until all target subclass objects are found and a general call instruction is sent to ensure the accuracy and completeness of the instruction issuance.

[0068] S305: Convert general invocation instructions into subclass operation instructions using subclass objects.

[0069] 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.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] 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.

[0074] 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.

[0075] 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.

[0076] 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: S306: 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.

[0077] 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.

[0078] 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.

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

[0080] 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.

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

[0082] 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.

[0083] Figure 6 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.

[0084] 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.

[0085] 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.

[0086] 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.

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

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

[0089] 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.

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

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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.

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

[0096] Figure 7 This is a schematic diagram of an information display page provided in an embodiment of this application. Figure 1 ,like Figure 11As 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.

[0097] 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.

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

[0099] 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.

[0100] 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.

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

[0102] 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.

[0103] 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.

[0104] 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.

[0105] 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.

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

[0107] 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.

[0108] 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.

[0109] 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 corresponding measurement unit's subclass object. The data is then packaged, formatted, and used to generate a fault log file, which is stored in a preset storage space for subsequent fault tracing, cause analysis, and equipment operation and maintenance.

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

[0111] 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.

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

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

[0114] 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.

[0115] 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.

[0116] 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.

[0117] 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.

[0118] 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.

[0119] Figure 8 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.

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

[0121] 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.

[0122] Figure 9 This is a schematic diagram of an information display page provided in an embodiment of this application. Figure 2 ,like Figure 9 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.

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

[0124] 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.

[0125] 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.

[0126] 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.

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

[0128] 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.

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

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

[0131] 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.

[0132] 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.

[0133] 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.

[0134] 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.

[0135] Figure 10This 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.

[0136] In one optional embodiment, in response to a user's batch control command input based on multiple measurement units at the interactive interface layer, data and status information of the multiple measurement units are displayed at 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.

[0137] 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.

[0138] 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.

[0139] 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.

[0140] 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.

[0141] In one optional embodiment, in response to a user's device management command triggered at least one of a plurality of measurement units at the interactive interface layer, the device management command is converted into a general call command for a general function interface of the abstract device through the scheduling control layer, 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.

[0142] 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.

[0143] 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.

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

[0145] 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.

[0146] 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.

[0147] 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.

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

[0149] 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.

[0150] 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.

[0151] 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.

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

[0153] 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.

[0154] 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.

[0155] 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.

[0156] 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.

[0157] 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.

[0158] 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.

[0159] Figure 11This 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.

[0160] Figure 12 This is a schematic diagram of a device debugging page provided in an embodiment of this application. In one possible embodiment, such as... Figure 12 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.

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

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

[0163] 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.

[0164] 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.

[0165] 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.

[0166] 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.

[0167] 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.

[0168] Figure 13 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.

[0169] 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.

[0170] 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.

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

[0172] 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.

[0173] 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.

[0174] Figure 14 This is a schematic diagram of a log display page provided in an embodiment of this application. In one possible embodiment, such as... Figure 14 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.

[0175] Figure 15 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.

[0176] 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.

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

[0178] In this embodiment, the 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 storage space for storing configuration parameter information, realizing the classified storage of data, which facilitates users to quickly retrieve and manage it.

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

[0180] 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 storage space, providing data support for curve generation.

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

[0182] In one possible embodiment, after the interactive interface layer receives the 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 equipment's operating status.

[0183] 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.

[0184] 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.

[0185] 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 16 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 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.

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

[0187] 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.

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

[0189] 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.

[0190] 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.

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

[0192] 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.

[0193] Figure 17 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.

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

[0195] 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.

[0196] 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.

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

[0198] 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.

[0199] Figure 18 This is a schematic diagram of an image display page provided in an embodiment of this application, such as... Figure 18 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.

[0200] This application also provides a multi-measurement unit virtualization management device. Figure 19 This is a schematic diagram of the structure of a multi-measurement unit virtualization management device provided in an embodiment of this application, as shown below. Figure 19 As shown, the device 1000 includes: The first conversion module 1010 is used to respond to a device management instruction received by the interactive interface layer based on at least one of multiple measurement units, and convert the device management instruction into a general call instruction for a general function interface of an abstract device through a scheduling control layer; the interactive interface layer, the scheduling control layer, and the device virtualization layer form an MVVM architecture; the interactive interface layer is coupled to the scheduling control layer; the abstract device is a virtual device constructed in the device virtualization layer for defining the general function interface; the multiple measurement units are respectively bound to multiple subclass objects, and the multiple subclass objects have independent running threads; the subclass objects inherit from the abstract device and are used to drive the measurement units bound to them to implement the subclass operations corresponding to the general function interface; Instruction sending module 1020 is used to send general calling instructions to the corresponding subclass objects; The second conversion module 1030 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.

[0201] 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 abstract module is used to construct subclass objects corresponding to the abstract device and multiple measurement units in the device virtualization layer. The abstract device maintains a general state machine. Multiple subclass objects of multiple measurement units 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.

[0202] In an optional embodiment, it further includes: The third conversion module is used to convert the subclass status information into standard device status based on the status normalization rule if it receives subclass response information carrying subclass status information sent by the measurement unit. The state update module is used to update the general state machine of the subclass objects bound to the standard device state update measurement unit. The first display module is used to display the standard device status of the measurement unit in the status display area of ​​the interactive interface layer through the MVVM architecture.

[0203] In an optional embodiment, the general invocation instruction includes a general stop instruction; the subclass operation instruction includes a subclass stop instruction; and further includes: The information writing module is used to write the key status information into the global variable table if the subclass status information of the measurement unit is key status information. The second display module is used to display key status information in the message display area of ​​the interactive interface layer; The first acquisition module is used to acquire the configuration parameter information of the measurement unit; The instruction generation module is used to generate a fault log and a general stop instruction for the general function interface of the abstract device if the configuration parameter information and key status information indicate that the measurement unit is in an alarm state. The fourth conversion module is used to convert general stop instructions into subclass stop instructions through subclass objects of measurement units; The first sending module is used to send the subclass stop command to the corresponding measurement unit.

[0204] In an optional embodiment, it further includes: The first determination module is used to determine the currently executing subclass object as the current object; The second sending module is used to send a general calling instruction to the current object if the device management instruction matches the current object; or, if the device management instruction does not match the current object, determine the next subclass object as the current object.

[0205] In an optional embodiment, it further includes: The third display module is used to display multiple sub-windows in the interactive interface layer in response to individual control commands received from multiple measurement units. The binding module is used to bind multiple sub-windows to multiple measurement units respectively; The fourth display module is used to display the data and status information of multiple measurement units on multiple sub-windows respectively; or; The fifth display module is used to respond to batch control commands received from multiple measurement units in the interactive interface layer and display the data and status information of multiple measurement units in the interactive interface layer.

[0206] 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; and further includes: The sixth display module is used to display the data, status information and first function control of the first measurement unit on the first sub-window; the first function control is used to implement common functions and first proprietary functions; The seventh display module is used to display the data, status information and second function controls of the second measurement unit on the second sub-window; the second function controls are used to implement common functions and second proprietary functions.

[0207] In one optional embodiment, the device management instructions include target device instructions and device operation instructions; and further include: The eighth display module is used to respond to batch control commands received from multiple measurement units in the interactive interface layer, and to display the data, status information and multiple third-function controls of multiple measurement units in the interactive interface layer. The second acquisition module is used to acquire the executable function of at least one target measurement unit corresponding to the target device instruction received from the interactive interface layer in response to the target device instruction. The status setting module is used to set the third function control corresponding to the common function to an available state if at least one target measurement unit has a common function. The fifth conversion module is used to respond to device operation commands received from the interactive interface layer based on the input of the third function control corresponding to the common function, and convert the device operation commands into general call commands for the general function interface of the abstract device through the scheduling control layer.

[0208] In an optional embodiment, it further includes: The ninth display module is used to display the device debugging page in the interactive interface layer in response to the device debugging command triggered by the device debugging control received by the interactive interface layer. The third sending module is used to respond to the dedicated debugging command received from the device debugging page and send the dedicated debugging command to the corresponding subclass object; the dedicated debugging command is used to instruct the measurement unit bound to the subclass object to perform a dedicated operation; The tenth display module is used to display proprietary response information on the device debugging page if it receives proprietary response information returned by the measurement unit based on a dedicated debugging command.

[0209] In an optional embodiment, it further includes: The queue creation module is used to create a log recording queue for each subclass object; The logging module is used to record user interface operation events related to subclass objects, subclass operation instructions sent to the measurement unit, and subclass response information received from the measurement unit in chronological order in the log logging queue; user interface operation events, subclass operation instructions, and subclass response information are displayed with different colors or symbols.

[0210] In an optional embodiment, it further includes: The sixth conversion module is used to respond to the data storage instruction based on the target measurement unit input received by the interactive interface layer, and convert the data of the bound measurement unit into standard format data through the subclass object corresponding to the target measurement unit; Storage modules are used to store standard format data in storage space.

[0211] In an optional embodiment, it further includes: The first data retrieval module is used to respond to the curve generation command triggered by multiple measurement units received by the interactive interface layer and retrieve standard format data of multiple measurement units from the storage space. The first curve generation module is used to generate multiple curve charts based on standard format data from multiple measurement units. The eleventh display module is used to respond to the overlay display command received by the interactive interface layer and display multiple curve charts in the same coordinate area of ​​the interactive interface layer.

[0212] In an optional embodiment, it further includes: The second data retrieval module is used to retrieve standard format data of the measurement unit from the storage space in response to the curve generation instruction triggered by the measurement unit based on the input received by the interactive interface layer; the standard format data includes multiple sub-data corresponding to different time information; The second determining module is used to determine the transparency information of each corresponding sub-data based on time information and preset transparency mapping rules; The second curve generation module is used to generate a transparency gradient curve based on multiple sub-data, time information, and transparency information of the sub-data.

[0213] In an optional embodiment, it further includes: The third data retrieval module is used to respond to the curve generation command triggered by the measurement unit received by the interactive interface layer and retrieve the standard format data of the measurement unit from the storage space; the standard format data includes multiple sub-data corresponding to different time information; The third determination module is used to determine the tone information corresponding to each sub-data based on time information and preset tone mapping rules; The third curve generation module is used to generate a hue gradient curve based on multiple sub-data, time information, and hue information of the sub-data.

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

[0215] 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 20 This is a hardware structure block diagram of a server for a multi-measurement unit virtualization management method provided in an embodiment of this application. For example... Figure 20 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 OS X™, Unix™, Linux™, FreeBSD™, etc.

[0216] 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.

[0217] Those skilled in the art will understand that Figure 20 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 20 The more or fewer components shown, or having the same Figure 20 The different configurations shown.

[0218] 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.

[0219] 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 virtualization management 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 virtualization management method.

[0220] 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.

[0221] As can be seen from the embodiments of the multi-measurement unit virtualization management method, apparatus, electronic device, or storage medium provided in this application, in response to a device management instruction received by the interaction interface layer based on at least one of multiple measurement units, the scheduling control layer converts the device management instruction into a general call instruction for a general function interface of the abstract device; the interaction interface layer and the scheduling control layer are used to form an MVVM architecture with the device virtualization layer; the interaction interface layer is coupled with the scheduling control layer; the abstract device is a virtual device constructed in the device virtualization layer for defining a general function interface; multiple measurement units are respectively bound to multiple subclass objects, and multiple subclass objects have independent running threads; the subclass objects inherit from the abstract device and are used to drive the measurement units bound to them to implement the subclass operations corresponding to the general function interface; the general call instruction is sent to the corresponding subclass object; the general call 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. In this embodiment, by abstracting roles and unifying the command interface, the scheduling and control layer can simultaneously issue the same command to multiple devices, achieving synchronous control of multiple measurement units and greatly improving testing and production efficiency in mixed scenarios with multiple devices, especially multiple models of devices. By abstracting devices and defining a common interface, different models of devices can be differentiated through subclasses, allowing for unified management of measurement units of various brands, models, and communication protocols, reducing the complexity of system integration with new measurement units. Simultaneously, the MVVM architecture separates the user interface from device control, enabling interface design to be independent of functional implementation, enhancing the system's maintainability and scalability.

[0222] 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.

[0223] 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.

[0224] 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.

[0225] 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 virtualized management of multiple measurement units, characterized in that, include: Construct an MVVM architecture that includes an interactive interface layer, a scheduling and control layer, and a device virtualization layer; In the device virtualization layer, abstract devices and subclass objects corresponding to multiple measurement units are constructed respectively; the abstract device maintains a general state machine; the multiple subclass objects of the multiple measurement units all inherit 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 state; In response to a device management command received by the interactive interface layer based on at least one of multiple measurement units, the scheduling control layer converts the device management command into a general call command for a general function interface for the abstract device; the interactive interface layer, the scheduling control layer, and the device virtualization layer form an MVVM architecture; the interactive interface layer is coupled to the scheduling control layer. The abstract device is a virtual device constructed in the device virtualization layer to define a general function interface; the multiple measurement units are respectively bound to multiple subclass objects, and the multiple subclass objects have independent running threads; the subclass objects inherit from the abstract device and are used to drive the measurement units bound to them to implement the subclass operations corresponding to the general function interface; 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.

2. The multi-measurement unit virtualization management method according to claim 1, characterized in that, After the general invocation instruction is converted into a subclass operation instruction through the subclass object, the following is included: If a subclass response information carrying the subclass status information is received from the measurement unit, the subclass status information is converted into the standard device status based on the status normalization rule; The general state machine of the subclass object bound to the measurement unit is updated based on the state of the standard equipment. The standard device status of the measurement unit is displayed in the status display area of ​​the interactive interface layer through the MVVM architecture.

3. The multi-measurement unit virtualization management method according to claim 2, characterized in that, The general invocation instruction includes a general stop instruction; the subclass operation instruction includes a subclass stop instruction; the method further includes: If the subclass status information of the measurement unit is critical status information, the critical status information is written into the global variable table; The key status information is displayed in the message display area of ​​the interactive interface layer; Obtain the configuration parameter information of the measurement unit; If the configuration parameter information and the key status information indicate that the measurement unit is in an alarm state, a fault log is generated, and a general stop command for the general function interface of the abstract device is generated; The general stop instruction is converted into a subclass stop instruction through a subclass object of the measurement unit; The subclass stop command is sent to the corresponding measurement unit.

4. The multi-measurement unit virtualization management method according to claim 1, characterized in that, Sending the general invocation instruction to the corresponding subclass object includes: The following is executed for each of the subclass objects through the scheduling control layer: The currently executing subclass object is identified as the current object; If the device management instruction matches the current object, the general invocation instruction is sent to the current object; or, if the device management instruction does not match the current object, the next subclass object is determined as the current object.

5. The multi-measurement unit virtualization management method according to claim 1, characterized in that, The method further includes: In response to individual control commands received by the interactive interface layer based on the input of the plurality of measurement units, a plurality of sub-windows are displayed on the interactive interface layer; Each of the multiple sub-windows is respectively bound to the multiple measurement units; The data and status information of the multiple measurement units are displayed on the multiple sub-windows respectively; or; In response to the batch control command received by the interactive interface layer based on the input of the plurality of measurement units, the data and status information of the plurality of measurement units are displayed on the interactive interface layer.

6. The multi-measurement unit virtualization management method according to claim 5, characterized in that, 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; The display of data and status information of the multiple measurement units on the multiple sub-windows includes: The data, status information, and first function control of the first measurement unit are displayed on the first sub-window; the first function control is used to implement the common function and the first proprietary function. The data, status information, and second function control of the second measurement unit are displayed on the second sub-window; the second function control is used to implement the common function and the second proprietary function.

7. The multi-measurement unit virtualization management method according to claim 5, characterized in that, The equipment management instructions include target equipment instructions and equipment operation instructions; The step of responding to a batch control command received from the multiple measurement units in the interactive interface layer, and displaying the data and status information of the multiple measurement units in the interactive interface layer, includes: In response to the batch control command received by the interactive interface layer based on the input of the plurality of measurement units, the data, status information and a plurality of third function controls of the plurality of measurement units are displayed on the interactive interface layer; The step of responding to a device management command received from the interactive interface layer based on at least one of the plurality of measurement units, and converting the device management command into a general call command for the general function interface of the abstract device through the scheduling control layer, includes: In response to the target device instruction received by the interactive interface layer, the executable function of at least one target measurement unit corresponding to the target device instruction is obtained; If the executable functions of the at least one target measurement unit have a common function, the third function control corresponding to the common function is set to an available state; In response to the device operation command received by the interactive interface layer based on 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.

8. The multi-measurement unit virtualization management method according to claim 1, characterized in that, The method further includes: In response to a device debugging command triggered by a device debugging control received by the interactive interface layer, a device debugging page is displayed on the interactive interface layer. In response to a dedicated debugging instruction received on the device debugging page, the dedicated debugging instruction is sent to the corresponding subclass object; the dedicated debugging instruction is used to instruct the measurement unit bound to the subclass object to perform a dedicated operation; If the proprietary response information returned by the measurement unit based on the dedicated debugging command is received, the proprietary response information is displayed on the device debugging page.

9. The multi-measurement unit virtualization management method according to claim 1, characterized in that, The method further includes: Create a log recording queue for each of the subclass objects; 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 are recorded in the log recording queue in chronological order; the user interface operation events, the subclass operation instructions, and the subclass response information are displayed with different colors or symbols.

10. A multi-measurement unit virtualization management method according to claim 1, characterized in that, The method further includes: In response to the data storage instruction based on the target measurement unit received by the interactive interface layer, the data of the bound measurement unit is converted into standard format data through the subclass object corresponding to the target measurement unit; The standard format data is stored in the storage space.

11. The multi-measurement unit virtualization management method according to claim 10, characterized in that, The method further includes: In response to the curve generation instruction triggered by the plurality of measurement units received by the interactive interface layer, standard format data of the plurality of measurement units are retrieved from the storage space; Multiple curves and charts are generated based on the standard format data from the multiple measurement units; In response to the overlay display instruction received by the interactive interface layer, the multiple curve charts are overlaid and displayed in the same coordinate area of ​​the interactive interface layer.

12. The multi-measurement unit virtualization management method according to claim 10, characterized in that, The method further includes: 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 storage space; the standard format data includes multiple sub-data corresponding to different time information; Based on the time information and the preset transparency mapping rules, the transparency information corresponding to each of the sub-data is determined; A transparency gradient curve is generated based on multiple sub-data, the time information, and the transparency information of the sub-data.

13. The multi-measurement unit virtualization management method according to claim 10, characterized in that, The method further includes: 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 storage space; the standard format data includes multiple sub-data corresponding to different time information; Based on the time information and the preset tone mapping rules, determine the tone information corresponding to each of the sub-data. A hue gradient curve is generated based on multiple sub-data, the time information, and the hue information of the sub-data.

14. A multi-measurement unit virtualization management device, characterized in that, The device 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 abstract module is used to construct subclass objects corresponding to the abstract device and multiple measurement units in the device virtualization layer. The abstract device maintains a general state machine. Multiple subclass objects of multiple measurement units 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. The first conversion module is used to respond to a device management command received by the interactive interface layer based on at least one of multiple measurement units, and convert the device management command into a general call command for a general function interface of an abstract device through a scheduling control layer; the interactive interface layer, the scheduling control layer, and the device virtualization layer form an MVVM architecture; the interactive interface layer is coupled to the scheduling control layer; the abstract device is a virtual device constructed in the device virtualization layer for defining the general function interface; the multiple measurement units are respectively bound to multiple subclass objects, and the multiple subclass objects have independent running threads; the subclass objects inherit from the abstract device and are used to drive the measurement units bound to them to implement the subclass operations corresponding to the general function interface; The instruction sending module is used to send the general calling instruction to the corresponding subclass object; The second conversion module is used to convert the general call instruction 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.

Images