Discrete data-oriented objectified modeling access method and system

Abstract

The invention discloses an objectified modeling access method and system for discrete data. The method comprises the steps that unified XML model files are used for power equipment model definition, and each XML model file corresponds to one type of equipment in a discrete collection system; generating a model tree based on the defined XML model file, performing instantiation modeling on elements in the model tree in sequence by adopting a model instantiation tool, and configuring attributes for each equipment instance; based on the known attribute value of the equipment, carrying out secondary development on statistical attributes describing indirect characteristics of the equipment through a preset algorithm; constructing a model access interface for providing whole-process data access of the model for an external system; and setting an extended service label in the defined XML model file to define value-added function logic, and scanning the extended service label to realize the corresponding value-added function logic through the model access interface when the model framework is started. According to the scheme of the invention, rapid adaptation of multiple scenes of power business is realized.

Description

Technical Field

[0001] This invention belongs to the field of power business processing, and specifically relates to an object-oriented modeling and access method and system for discrete data. Background Technology

[0002] Device models, also known as business models, are the foundation of software product development. Through modeling, the attributes of real-world sensing measurements are mapped to those of digital twin devices. Modeling is the basic abstraction of all business systems and the core of business systems in the cloud-edge convergence model.

[0003] Currently, various products for power grid operations widely adopt CIM-based power system models, which are well-suited for traditional Zone I and II operations. However, with the continuous development of power services and the expansion of control station scale, the existing model topology of the platform cannot fully accommodate new scenarios. It is necessary to consider the access of numerous types of auxiliary equipment and associate measurement collection points with equipment attributes one by one. The defects and limitations of the CIM model include:

[0004] Limited scalability: Although CIM supports extensions, different vendors may use inconsistent extension methods, leading to interoperability issues. In cross-vendor environments, extended classes and attributes may not be recognized or used by other systems, reducing the model's versatility.

[0005] Insufficient standardization: Although CIM is a standard model, in practical applications, different manufacturers may implement the standard differently, and devices or systems may not be fully compatible, leading to integration difficulties;

[0006] Lack of flexibility: The class structure and attributes of the CIM model are static, making it difficult to dynamically adapt to rapidly changing IT environments. When facing emerging technologies (such as containerization and microservice architecture), the CIM model may not provide sufficient flexibility.

[0007] The State Grid Corporation of China (SGCC) has fully considered this aspect in its secondary system optimization, issuing extended specifications such as the "Information Model Specification for Intelligent Monitoring System of Centralized Control Station Equipment." These specifications aim to guide how to extend the CIM model to accommodate numerous devices beyond the primary model. Furthermore, these extended models are linked to existing equipment models through "physical IDs." In the external IoT field, the concept of digital twins provides an effective method for managing and optimizing complex devices and systems. Digital twin technology enables real-time data monitoring, analysis, and prediction by creating virtual models of physical devices. Modeling is a crucial step in this process. SCADA systems collect measurement data from various devices, which typically originate from different power protocols, internet protocols, etc., exhibiting diversity and complexity.

[0008] To effectively manage this data, a flat management approach can be adopted, integrating data from different sources onto a unified platform. Then, through equipment modeling technology, the measurement data can be associated with the attributes of the equipment model. The externally provided API interface hides the mapping relationship, and access to the equipment attributes will directly manipulate the measurement signals, simplifying (standardizing) the development process of various business systems. Summary of the Invention

[0009] To address the shortcomings of existing technologies, this invention provides an object-oriented modeling and access method and system for discrete data, aiming to solve the technical problems of expanding complex applications and statistically analyzing the basic operating data and important alarm data of key equipment.

[0010] To solve the above-mentioned technical problems, the present invention adopts the following technical solution.

[0011] This invention first discloses an object-oriented modeling and access method for discrete data, which includes the following steps:

[0012] Step 1: Define the power equipment model using a unified XML model file. Each XML model file corresponds to a type of device in the discrete acquisition system. The XML model file contains the basic information and attribute information of the corresponding device.

[0013] Step 2: Generate a model tree based on the defined XML model file, and use a model instantiation tool to instantiate and model the elements in the model tree in sequence, configuring attributes for each device instance;

[0014] Step 3: Based on the known attribute values ​​of the device, perform secondary development on the statistical attributes describing the indirect characteristics of the device through a pre-set algorithm;

[0015] Step 4: Build a model access interface to provide external systems with full-process data access to the model;

[0016] Step 5: Set extended service tags in the defined XML model file to define value-added function logic. When the model framework starts, it scans the extended service tags and implements the corresponding value-added function logic through the model access interface.

[0017] The present invention further includes the following preferred embodiments:

[0018] The use of a unified XML model file for defining power equipment models further includes:

[0019] The XML model file sets device template tags, attribute tags, scheduled task tags, and event listener tags. The device template tags describe the basic information and hierarchical relationship of the device; the attribute tags are used to define the attributes of a device; the scheduled task tags describe the periodic tasks of the device, supporting multiple scheduled task configurations; and the event listener tags describe the alarm listening tasks of the device.

[0020] The attribute types include reference attributes, which are divided into measurement references and device references. Measurement references are mapped to existing measurement points in the system and are determined based on the three-dimensional coordinates of the library, table, and field. When the same device references attributes from different device tables, multiple global reference configurations are added, the table library and table are set, and in a single attribute definition, the type corresponds to the table in the global reference set, and then the field name is set separately. If the reference value of a certain attribute of a device is not in the device's global reference set, the original method is still used, and only one set of reference information is configured.

[0021] The step of using a model instantiation tool to sequentially instantiate and model the elements in the model tree further includes:

[0022] Instances are created in the order from the top-level parent device to each layer of child devices. Each time a device is created, the model framework instantiates the object, including common methods for initializing and setting the parent device, adding child devices, and associating XML scripts.

[0023] The configuration of attributes for each device instance further includes:

[0024] For reference attributes, the XML file has already set the library, table, and field referenced by this type of attribute. Select specific measurement points for the attributes of the device instance. The background records the mapping relationship between the device instance ID, attribute, and measurement point ID. Unconfigured reference attributes are highlighted in yellow. When configuring, all measurement points are listed according to the three-dimensional coordinates of the definition file, i.e., tables, libraries, and fields. The reference attribute instance information is stored in the reference attribute relationship library, including device ID, attribute name, and reference measurement ID.

[0025] Fixed-value attributes are identifying constants, including number, code, model, location, rated value, and over-limit value. The relational database for this type of attribute is distinguished by data type. After configuring the initial value, the instance information is stored in the reference attribute relational database, including device ID, attribute name, and attribute value.

[0026] For additional attributes, initial values ​​are configured for these attributes using modeling tools, and the device instance ID, attribute, and value are recorded. For additional attributes that require periodic storage of values, measurement point labels are generated in a unified format, and the new measurement point interface is called to access the time series library. For additional attributes that do not require periodic storage, historical data is managed using Redis and a relational database. After the framework starts, the data is hot-loaded into Redis for fast access. During framework operation, a synchronization strategy is used to ensure data consistency between Redis and the relational database.

[0027] The model access interface further includes:

[0028] A model interface adaptation layer is formed to handle the differences between various acquisition systems. The access layer can access the periodic acquisition data of the measurement points by connecting to the adaptation layer. After successful access, it provides external systems with storage and query functions for real-time cross-sectional data and historical process data of the model.

[0029] A model interface abstraction layer is formed to shield the interface differences of different discrete acquisition systems. Through the adaptation of the interface abstraction layer API, it can connect to different acquisition platforms and various IoT acquisition systems.

[0030] The setting of extended service tags further includes:

[0031] Alarm event monitoring tags are used to monitor the real-time load rate of main transformers and line equipment. If a heavy overload occurs, subscribers will be notified via SMS and alarm pop-up. At the same time, the duration of the heavy overload and the load rate will be recorded in the database.

[0032] The scheduled task tag is used to periodically collect tripping information for switchgear and summarize it into the relational database, and to periodically collect and store the three-phase current imbalance, so that different upper-layer applications can reuse the basic statistical data of this type of important equipment.

[0033] This invention also discloses an object-oriented modeling and access system for discrete data that utilizes the aforementioned object-oriented modeling and access method for discrete data, comprising:

[0034] The model definition module is used to define power equipment models using a unified XML model file. Each XML model file corresponds to a type of device in the discrete acquisition system. The XML model file contains the basic information and attribute information of the corresponding device.

[0035] The instantiation module is used to generate a model tree based on a defined XML model file, and to use a model instantiation tool to instantiate and model the elements in the model tree in sequence, configuring attributes for each device instance;

[0036] The attribute secondary development module is used to perform secondary development on statistical attributes that describe indirect characteristics of the device based on the device's known attribute values ​​and through a pre-defined algorithm.

[0037] The access interface building module is used to build model access interfaces, which provide external systems with full-process data access to the model.

[0038] The extended service module is used to set extended service tags in the defined XML model file to define value-added function logic. When the model framework starts, it scans the extended service tags and implements the corresponding value-added function logic through the model access interface.

[0039] Accordingly, this application also discloses a terminal, including a processor and a storage medium;

[0040] The storage medium is used to store instructions;

[0041] The processor is configured to operate according to the instructions to perform the steps of the aforementioned object-oriented modeling access method for discrete data.

[0042] Accordingly, this application also discloses a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the aforementioned object-oriented modeling and access method for discrete data.

[0043] The beneficial effects of this invention are that, compared with existing technologies, it provides an object-oriented modeling and access method and system for discrete data. Addressing the issues of power equipment expansion and incompatibility between different acquisition systems, it can reuse existing model measurement configurations and horizontally add various fixed values ​​and complex measurement point definition methods. By abstracting the mapping relationship between equipment attributes and acquisition points, it shields historical data access details to achieve flattened management of measurement data, improving the model's cross-platform compatibility. Simultaneously, it provides open personalized development interfaces for attributes, vertically expanding various business needs and strengthening the model's value-added functionality. The standardized model possesses cross-system and cross-business universality, enabling rapid adaptation to multiple power business scenarios. Attached Figure Description

[0044] Figure 1 This is the overall architecture diagram of object-oriented modeling in this invention.

[0045] Figure 2 This is a schematic diagram illustrating the content structure and hierarchical relationship of the model definition file in this invention;

[0046] Figure 3 This is a schematic diagram of the modeling tool interface in this invention;

[0047] Figure 4This is a schematic diagram of a set of device models constructed based on the model definition file in this invention;

[0048] Figure 5 This is a schematic diagram of the model definition instantiation process in this invention;

[0049] Figure 6 This is a schematic diagram of the model framework and the data access process of the modeling tool during runtime in this invention;

[0050] Figure 7 This is a schematic diagram illustrating the instantiation and registration of extended services in this invention. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0052] The embodiments described in this application are merely some, not all, embodiments of the present invention. Based on the spirit of the present invention, all other embodiments obtained by those skilled in the art without inventive effort are within the protection scope of the present invention.

[0053] To address the shortcomings of existing technologies, this invention proposes an object-oriented modeling and access method and system for discrete data. It constructs a standardized modeling method for discrete measurement processes of equipment in different power scenarios, possessing cross-level and cross-platform versatility. The model definition tool provides application developers with tools for defining reference / attached attributes, extended services, and hierarchical relationships. The modeling tool provides engineers with the ability to instantiate a set of equipment models based on the model definition and implement basic configurations for various attributes of any device. The model development API provides application developers with a secondary development interface for the model, offering custom operation methods for additional attributes beyond those mapped from measurements, improving system extensibility. The model access API shields the interface differences between different discrete acquisition systems, and through the API adaptation of the interface abstraction layer, it connects to different discrete acquisition platforms and various IoT acquisition systems. Above the interface abstraction layer, it provides storage and query functions for real-time cross-sectional data and historical process data of the model. Through these interfaces, model developers / users can access the entire process data of the model. Extended services are set with extended service tags in the model definition file; these tags are applicable to all instances under this type of device. Customized device models for various products can be implemented using standardized modeling techniques. Furthermore, through an interface abstraction layer, most of the model's functionality can work across systems, avoiding redundant development caused by data acquisition system changes and migrations. A general underlying model is abstracted for differentiated scenarios, and objects at different levels are constructed using a unified format, with customizable interfaces for additional attributes provided for each device object.

[0054] The method includes the following steps:

[0055] Step 1: Define the power equipment model using a unified XML model file. Each XML model file corresponds to a type of device in the discrete acquisition system. The XML model file contains the basic information and attribute information of the corresponding device.

[0056] For discrete data acquisition systems with varying plant and station levels, a complete and uniformly formatted XML file is used to describe the device model, achieving full device model definition. Each XML file corresponds to a type of device, with different tags describing different information about the device. The content includes:

[0057] Basic equipment information and hierarchical relationships, including equipment name, description, class name, and parent equipment name;

[0058] The definition of all device attributes, which are divided into reference types, static base types, and additional base types;

[0059] Extended information includes features such as scheduled tasks and event listening to meet the customization needs of this type of device.

[0060] In a specific embodiment, the XML file includes tags for "Device Template," "Attributes," "Scheduled Tasks," and "Event Listeners." Specifically:

[0061] The "Device Template" tag describes the device's own attribute types. These mainly include:

[0062] The device name is consistent with the definition file name and is globally unique within a set of device models;

[0063] The class name is used by the instantiation tool to generate the class name and needs to be defined according to the naming rules for class names;

[0064] Parent device: The name of the parent device to which this device belongs. It is used to describe the device hierarchy. If a device has multiple parent devices, they are separated by commas.

[0065] Whether it is a singleton or not, this type of device only allows one object to be instantiated, which is used for some global application attribute classification scenarios;

[0066] Whether it is visible, and whether it is displayed in the model tree.

[0067] The "Attributes" tag is used to define the attributes of a device. The definition of device attributes mainly includes the following parameters:

[0068] Attribute types are categorized into reference attributes, fixed-value attributes, and additional attributes. Reference attributes are further divided into measurement references and device references. Measurement references are mapped to existing measurement points in the system, determined based on the three-dimensional coordinates of the database, table, and field. When the same device references attributes from different device tables, multiple global reference configurations are added, setting the table database and table. In a single attribute definition, the type corresponds to a table in the global reference set, and then the field name is set separately. If a device's attribute reference value is not in the device's global reference set, it can still be configured using the original method, requiring only one set of reference information. Fixed-value and additional attributes include integer, long integer, floating-point, double-precision, and string types.

[0069] Attribute names: Each attribute name for a type of device must be unique and can only consist of alphanumeric characters, consistent with the naming rules for variables, and will be used in subsequent code generation and methods.

[0070] Descriptive information used for displaying modeling tools;

[0071] Units used for web display or exporting statistical data;

[0072] The coefficient is used to calculate the reference count. The attribute value = reference count * coefficient, which is used for normalization.

[0073] The “Scheduled Tasks” label describes the device’s periodic tasks, supports multiple scheduled task configurations, and the scheduling period is configured according to the crontab format.

[0074] The "Event Listening" tab describes the device's alarm listening tasks. It supports configuration of notification methods and notification lists. The model definition file is managed using the MinIO distributed storage engine. Figure 2 A diagram illustrating the hierarchy and content of the model definition file is provided.

[0075] By providing standardized model definition files for different power sites, the system meets the needs of building device models at different depths. Each device layer has the ability to configure reference attributes, additional attributes, and add personalized extended services.

[0076] Step 2: Generate a model tree based on the defined XML model file, and use a model instantiation tool to instantiate and model the elements in the model tree in sequence, configuring attributes for each device instance.

[0077] This system provides construction workers with management tools for instantiating equipment and developers with methods for calling entity classes, enabling the process from model templates to instantiated equipment. The model tree expands hierarchically according to the XML definition, creating instances in the order of the top-level parent device to each layer of child devices. For each device created, the model framework instantiates the object: initializing the parent device, adding child devices, and using common methods to associate XML scripts. Double-clicking any device instance displays a property table area listing all the properties of that device class.

[0078] Figure 3 The modeling tool shown obtains a complete set of definition files from the MinIO system and generates a model tree according to the parent-child relationships in the definition files. For each new element in the tree, the model-class framework generates device entity class code, where the methods for injecting objects include: setting a device instance object, setting a parent device, setting a definition file, and adding this child device instance to the parent device. Correspondingly, the device instance information is stored in the model relationship database (device ID, parent device ID, device name, template name). Figure 4 Provide a set of instantiated device trees. Figure 6 The process of accessing data during the runtime of modeling tools is described.

[0079] Next, the properties are configured for each device instance. The property table of the modeling tool lists all the reference properties, fixed-value properties, and statistical properties of the device model.

[0080] For referenced attributes, the XML file defines the libraries, tables, and fields referenced by these attributes. Specific measurement points are selected for the device instance's attributes. The mapping relationship between the device instance ID, attribute, and measurement point ID is recorded in the background and stored in the framework's reference configuration library. Unconfigured referenced attributes are highlighted in yellow. During configuration, all measurement points are listed according to the three-dimensional coordinates (tables, libraries, fields) defined in the file. After selection by engineers, the referenced attribute instance information is stored in the referenced attribute relationship library (device ID, attribute name, referenced measurement ID).

[0081] Fixed-value attributes are identifying constants, such as number, code, model, location, rated value, and over-limit value. The relational database for these attributes is categorized by data type. After configuring initial values, instance information is stored in the referenced attribute relational database (device ID, attribute name, attribute value). For statistical attributes, if values ​​are stored periodically, measurement point labels are registered with the time-series database when saving the model.

[0082] The instance object uses attribute names and attribute values ​​as key-value pairs. Optionally, the attribute value can be retrieved by the attribute name; a real-time value can be set by the attribute name; or a time-series value can be set by the attribute name and the time. For reference type attributes, the get / set methods internally determine the measurement point based on the mapping relationship between the attribute name and the referenced measurement ID and the discrete coordinates of the measurement, hiding the mapping details from the caller and directly retrieving historical data based on the attribute. Figure 5 The modeling process is described in detail.

[0083] For additional attributes, initial values ​​are configured using modeling tools, recording the device instance ID, attribute, and value, specifically stored in the framework's basic data type library. For additional attributes requiring periodic value storage, measurement point labels are generated in a unified format, and the new measurement point interface is called to access the time-series library (only for numeric attributes). For additional attributes not requiring periodic storage, historical data is managed using Redis and a relational database. After the framework starts, the data is hot-loaded into Redis for fast access. During framework operation, a synchronization strategy ensures data consistency between Redis and the relational database.

[0084] Step 3: Based on the known attribute values ​​of the device, perform secondary development on the statistical attributes describing the indirect characteristics of the device through a pre-set algorithm.

[0085] This provides application developers with a secondary development interface for the model, allowing for customized processing of indirect attributes based on device constant values ​​and reference measurements. Among the additional attributes, a type of statistic describes the indirect characteristics of the device, requiring the design of relevant algorithms based on electrical knowledge. Using the device's known constant values ​​and reference measurements as a basis, developers can implement customized rewriting in the set / save methods according to specified algorithms, and then call the time-series library storage interface to append historical data according to the storage period.

[0086] In the model definition file, statistical attributes are also basic data types. Unlike fixed-value attributes, statistical values ​​are indirect attributes of the device, requiring certain logical operations to be derived. They have summarizing and predictive significance for the device's performance analysis. Defining each statistical value means that the corresponding statistical logic needs to be developed in the backend.

[0087] Taking the string current dispersion rate calculation as an example, this value is calculated as the ratio of the standard deviation to the average value of the collected current. Within the statistical time period, the standard deviation and average value of the collected current at each fixed interval are calculated to determine the dispersion rate for each interval. The daily dispersion rate is obtained by weighted averaging of the dispersion rates for each interval. Based on the above analysis, the fixed-value attributes that need to be configured include: the start / end time of the dispersion rate statistics, the statistical interval, and the weighting coefficient array. The execution cycle of the corresponding string current dispersion rate statistics task should be configured, for example, executing at 22:00 daily: from the start time to the end time, the collected string current values ​​within each interval are assembled according to the set interval (referencing the collection sequence of the current measurement points), the standard deviation and average value are calculated according to the formula (which can be obtained through the time series library interface), and then the dispersion rate of that interval is calculated. After obtaining the dispersion rates of all intervals, the daily string current dispersion rate is calculated based on the weighting coefficient array. Subsequently, the `set` method is called to append the historical records of the dispersion rate and time of this statistical attribute to the time series library. The `get` method only needs to obtain the real-time value based on the string current dispersion rate calculation attribute name and time (measurement point labels have been registered during modeling).

[0088] Step 4: Build a model access interface to provide external systems with full-process data access to the model.

[0089] For various IoT discrete data acquisition systems, a model interface adaptation layer is developed to handle the differences between the systems. The access layer can access the periodic data acquisition of measurement points by connecting to the adaptation layer, without needing to concern itself with the underlying details. After successful integration, it provides external systems with storage and query functions for real-time cross-sectional data and historical process data of the model. Through these interfaces, model developers / users can access the entire process data of the model.

[0090] Then, a model interface abstraction layer is formed to shield the interface differences of different discrete acquisition systems. Through the adaptation of the API of the interface abstraction layer, it can connect to different acquisition platforms and various IoT acquisition systems.

[0091] For fixed-value attributes, Redis and a relational database are used to manage historical data changes. After the framework starts, the data is hot-loaded into Redis for fast access. During framework operation, a synchronization strategy ensures data consistency between Redis and the relational database.

[0092] For device reference attributes and periodically stored statistical attributes, the data access process is uniformly integrated into the time series library. First, measurement tags are maintained. Reference attributes already have measurement point tags; only the mapping relationship between attributes and measurement points needs to be maintained when saving the model. Statistical attributes require new tag points (integer, long integer, floating-point, double-precision). The tag naming rule can use the following: application.table.id.attribute. When submitting tags, synchronous or asynchronous submission can be selected. Specifically, the interface for adding time series library tags individually or in batches is called, and the success or failure of the addition is determined based on the return value. After all device attributes have successfully added measurement tags, the time series library service maintains the storage and query functions for model references, real-time cross-sectional data of statistical attributes, and process historical data through a network interface. When saving data, the server caches and submits it in batches; when querying, the results are encapsulated as serialized objects and returned to the calling method. Figure 6 This describes the process of accessing data during model framework runtime. It provides storage and query functions for real-time cross-sectional data and historical process data of the model. Through these interfaces, model developers / users can access the model's entire process data.

[0093] Step 5: Set extended service tags in the model definition file to define value-added function logic. When the model framework starts, it scans the extended service tags and implements the corresponding value-added function logic through the model access interface.

[0094] In the model definition file of step 1, extended service tags are set. These tags are applicable to all instances under this type of device. This helps to improve the model's numerical statistical capabilities vertically. Each service tag implements processing logic through the personalized interface described in step 4. Value-added functions include, but are not limited to:

[0095] Alarm event monitoring tags: For example, monitor the real-time load rate of main transformers and line equipment. If a heavy overload occurs, immediately notify subscribers via SMS, alarm pop-ups, etc. At the same time, record the duration of the heavy overload and the load rate into the database to provide data support for subsequent qualitative and trend analysis.

[0096] Scheduled task tags: For example, for switchgear, periodically collect tripping information and summarize it in the relational database, and periodically collect and store the three-phase current imbalance so that different upper-layer applications can reuse the basic statistical data of this type of important equipment.

[0097] After defining the extended service tags and implementing the corresponding logic, the model framework scans the extended tags of the device class when it starts: the listener tags start the listener threads in sequence, and the scheduled task tags are connected to the distributed task scheduling platform XXL-JOB for unified management. Among them, the scheduled tasks of a type of device are managed by the same scheduler, and the execution efficiency is improved through concurrent scheduling. Figure 7The process of instantiating and registering extended services is presented. By setting extended service tags, complex applications can be extended to the model, facilitating the collection of basic operational data and important alarm data of key equipment.

[0098] The beneficial effects of this invention are that, compared with existing technologies, it provides an object-oriented modeling and access method and system for discrete data. Addressing the issues of power equipment expansion and incompatibility between different acquisition systems, it can reuse existing model measurement configurations and horizontally add various fixed values ​​and complex measurement point definition methods. By abstracting the mapping relationship between equipment attributes and acquisition points, it shields historical data access details, achieving flattened management of measurement data, improving the model's cross-platform compatibility, and strengthening the model's value-added functionality. Furthermore, it provides personalized development interfaces for attributes, vertically expanding to meet various business needs. By abstracting standardized models for different acquisition systems and opening custom interfaces for equipment object attributes, it achieves flattened management of discrete data. The standardized model possesses cross-system and cross-business universality, enabling rapid adaptation to multiple scenarios in power business.

[0099] This invention can be a system, method, and / or computer program product. This invention also discloses a system for object-oriented modeling and accessing discrete data based on the aforementioned object-oriented modeling and access method for discrete data, comprising:

[0100] The model definition module is used to define power equipment models using a unified XML model file. Each XML model file corresponds to a type of device in the discrete acquisition system. The XML model file contains the basic information and attribute information of the corresponding device.

[0101] The instantiation module is used to generate a model tree based on a defined XML model file, and to use a model instantiation tool to instantiate and model the elements in the model tree in sequence, configuring attributes for each device instance;

[0102] The attribute secondary development module is used to perform secondary development on statistical attributes that describe indirect characteristics of the device based on the device's known attribute values ​​and through a pre-defined algorithm.

[0103] The access interface building module is used to build model access interfaces, which provide external systems with full-process data access to the model.

[0104] The extended service module is used to set extended service tags in the defined XML model file to define value-added function logic. When the model framework starts, it scans the extended service tags and implements the corresponding value-added function logic through the model access interface.

[0105] Based on the spirit of this invention, those skilled in the art will readily conceive of a computer program product derived from the aforementioned object-oriented modeling and access method for discrete data. The computer program product may include a computer-readable storage medium on which computer-readable program instructions are loaded to enable a processor to implement various aspects of this disclosure. That is, this application also includes a terminal comprising a processor and a storage medium; the storage medium is used to store instructions; the processor is used to operate according to the instructions to perform the steps according to the aforementioned object-oriented modeling and access method for discrete data.

[0106] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination of the foregoing. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0107] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0108] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0109] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the claims of the present invention.

Claims

1. An object-oriented modeling and access method for discrete data, characterized in that, Includes the following steps: Step 1: Define the power equipment model using a unified XML model file. Each XML model file corresponds to a type of device in the discrete acquisition system. The XML model file contains the basic information and attribute information of the corresponding device. Step 2: Generate a model tree based on the defined XML model file, and use a model instantiation tool to instantiate and model the elements in the model tree in sequence, configuring attributes for each device instance; Step 3: Based on the known attribute values ​​of the device, perform secondary development on the statistical attributes describing the indirect characteristics of the device through a pre-set algorithm; Step 4: Build a model access interface to provide external systems with full-process data access to the model; Step 5: Set extended service tags in the defined XML model file to define value-added function logic. When the model framework starts, it scans the extended service tags and implements the corresponding value-added function logic through the model access interface.

2. The object-oriented modeling and access method for discrete data according to claim 1, characterized in that, The use of a unified XML model file for defining power equipment models further includes: The XML model file sets device template tags, attribute tags, scheduled task tags, and event listener tags. The device template tags describe the basic information and hierarchical relationship of the device; the attribute tags are used to define the attributes of a device; the scheduled task tags describe the periodic tasks of the device, supporting multiple scheduled task configurations; and the event listener tags describe the alarm listening tasks of the device.

3. The object-oriented modeling and access method for discrete data according to claim 2, characterized in that, The attribute types include reference attributes, which are divided into measurement references and device references. Measurement references are mapped to existing measurement points in the system and are determined based on the three-dimensional coordinates of the library, table, and field. When the same device references attributes from different device tables, multiple global reference configurations are added, the table library and table are set, and in a single attribute definition, the type corresponds to the table in the global reference set, and then the field name is set separately. If the reference value of a certain attribute of a device is not in the device's global reference set, the original method is still used, and only one set of reference information is configured.

4. The object-oriented modeling and access method for discrete data according to claim 3, characterized in that, The step of using a model instantiation tool to sequentially instantiate and model the elements in the model tree further includes: Instances are created in the order from the top-level parent device to each layer of child devices. Each time a device is created, the model framework instantiates the object, including common methods for initializing and setting the parent device, adding child devices, and associating XML scripts.

5. The object-oriented modeling and access method for discrete data according to claim 4, characterized in that, The configuration of attributes for each device instance further includes: For reference attributes, the XML file has already set the library, table, and field referenced by this type of attribute. Select specific measurement points for the attributes of the device instance. The background records the mapping relationship between the device instance ID, attribute, and measurement point ID. Unconfigured reference attributes are highlighted in yellow. When configuring, all measurement points are listed according to the three-dimensional coordinates of the definition file, i.e., tables, libraries, and fields. The reference attribute instance information is stored in the reference attribute relationship library, including device ID, attribute name, and reference measurement ID. Fixed-value attributes are identifying constants, including number, code, model, location, rated value, and over-limit value. The relational database for this type of attribute is distinguished by data type. After configuring the initial value, the instance information is stored in the reference attribute relational database, including device ID, attribute name, and attribute value. For additional attributes, initial values ​​are configured for these attributes using modeling tools, and the device instance ID, attribute, and value are recorded. For additional attributes that require periodic storage of values, measurement point labels are generated in a unified format, and the new measurement point interface is called to access the time series library. For additional attributes that do not require periodic storage, historical data is managed using Redis and a relational database. After the framework starts, the data is hot-loaded into Redis for fast access. During framework operation, a synchronization strategy is used to ensure data consistency between Redis and the relational database.

6. The object-oriented modeling and access method for discrete data according to claim 5, characterized in that, The model access interface further includes: A model interface adaptation layer is formed to handle the differences between various acquisition systems. The access layer can operate the periodic acquisition data of the measurement points by connecting to the adaptation layer. After successful access, it provides external systems with storage and query functions for real-time cross-sectional data and historical process data of the model. A model interface abstraction layer is formed to shield the interface differences of different discrete acquisition systems. Through the adaptation of the interface abstraction layer API, it can connect to different acquisition platforms and various IoT acquisition systems.

7. The object-oriented modeling and access method for discrete data according to claim 6, characterized in that, The setting of extended service tags further includes: Alarm event monitoring tags are used to monitor the real-time load rate of main transformers and line equipment. If a heavy overload occurs, subscribers will be notified via SMS and alarm pop-up. At the same time, the duration of the heavy overload and the load rate will be recorded in the database. The scheduled task tag is used to periodically collect tripping information for switchgear and summarize it into the relational database, and to periodically collect and store the three-phase current imbalance, so that different upper-layer applications can reuse the basic statistical data of this type of important equipment.

8. An object-oriented modeling and access system for discrete data, characterized in that, include: The model definition module is used to define power equipment models using a unified XML model file. Each XML model file corresponds to a type of device in the discrete acquisition system. The XML model file contains the basic information and attribute information of the corresponding device. The instantiation module is used to generate a model tree based on a defined XML model file, and to use a model instantiation tool to instantiate and model the elements in the model tree in sequence, configuring attributes for each device instance. The attribute secondary development module is used to perform secondary development on statistical attributes that describe indirect characteristics of the device based on the device's known attribute values ​​and through a pre-defined algorithm. The access interface building module is used to build model access interfaces, which provide external systems with full-process data access to the model. The extended service module is used to set extended service tags in the defined XML model file to define value-added function logic. When the model framework starts, it scans the extended service tags and implements the corresponding value-added function logic through the model access interface.

9. A terminal, comprising a processor and a storage medium; characterized in that: The storage medium is used to store instructions; The processor is configured to operate according to the instructions to perform the steps of the object-oriented modeling and access method for discrete data according to any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the object-oriented modeling access method for discrete data as described in any one of claims 1-7.

Images