Data coding method, device and equipment for surface-oriented object of electric energy and medium

Abstract

The invention relates to the technical field of electric energy meter data management, in particular to a data coding method, device and equipment of an electric energy meter facing object and a medium. The method comprises the following steps: S1, respectively defining an object attribute structure and a general object structure; s2, obtaining an object identifier of a target object from the received message or instruction, and searching a corresponding universal object structure in a preset object set according to the object identifier; s3, according to the general object structure corresponding to the target object, verifying the access authority of the target object attribute and checking the validity of the data source of the target object attribute; and S4, in response to the readable target object attribute and the valid data source, dynamically binding and calling a corresponding coding function through a virtual method table in the object attribute structure corresponding to the target attribute, and coding the data source according to a predetermined coding rule, so as to improve expansibility, code conciseness and maintenance convenience.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of electric energy meter data management, and in particular to an electric energy meter object-oriented data encoding method, device, equipment and medium. BACKGROUND

[0002] In the process of smart grid construction and development, electric energy meters are the core terminal devices for power data acquisition, metering and transmission. The standardization and compatibility of data interaction directly affect the efficiency and stability of power grid operation. To achieve unified and efficient data communication between electric energy meters and power grid systems, State Grid has developed the State Grid 698 protocol based on A-XDR encoding rules. This protocol has a significant object-oriented feature. By defining standardized object structures, it standardizes the organization and transmission of various types of electric energy meter data (such as metering data, state data, control instruction data, etc.), and has become the core technical standard for electric energy meter research, production and application in the State Grid.

[0003] In the development of electric energy meters based on the above-mentioned State Grid 698 protocol, most electric energy meter manufacturers generally adopt the technical solution of directly nesting structures to describe all members of the object from top to bottom in order to meet the object-oriented design idea of the protocol. Specifically, at the code implementation level, this solution encodes the objects defined in the protocol (such as electric energy metering objects and event recording objects) and their contained sub-objects and member variables (such as voltage, current and power members under the metering object) in the form of nested data structures, so that the electric energy meter can directly parse and encapsulate data according to the hierarchical relationship defined in the protocol during data processing, thereby realizing the object-oriented feature required by the protocol to a certain extent and ensuring the basic compatibility of data interaction between the electric energy meter and the power grid system.

[0004] However, the above-mentioned existing technical solution has obvious limitations and cannot meet the needs of continuous expansion of current State Grid electric energy meters and frequent updates of the protocol:

[0005] Poor scalability: Due to the use of direct nesting structure design, the members of the object at all levels (including parent objects, child objects and grandchildren members) are highly coupled at the code level. When the structure of the grandchildren members of the object needs to be adjusted in actual application (such as adding new member variables, modifying member data types or deleting redundant members), not only the code of the corresponding grandchildren members needs to be modified, but also the related code and methods of their parent objects and even higher-level objects (such as object initialization methods, data serialization and deserialization methods, data validation methods, etc.) need to be reviewed and adjusted, resulting in complex and inefficient expansion operations.

[0006] Code bloat and high maintenance difficulty: with the increasing demand for functions of the State Grid electric energy meter (such as the addition of load control function, harmonic monitoring function, fee control management function, etc.), the State Grid 698 protocol is also frequently expanded and updated, and a large number of sub-objects or members need to be added on the basis of the original object structure. Based on the existing direct nested structure design scheme, a large number of nested structure codes need to be added to the original code every time the protocol is expanded, and it is often difficult to effectively clean up the historical redundant codes to ensure compatibility, resulting in the continuous expansion of the relevant code size of the electric energy meter, the increasing complexity of the code structure, and the appearance of code bloat. At the same time, the highly coupled code structure significantly increases the difficulty of subsequent code debugging, fault troubleshooting, version iteration and technical upgrading, increases the cost of electric energy meter research and maintenance, and reduces the stability and reliability of the electric energy meter operation.

[0007] In summary, the direct nested structure design scheme adopted by the State Grid 698 protocol electric energy meter based on the A-XDR coding rule has obvious defects in expansibility, code simplicity and maintenance convenience, and cannot meet the needs of smart grid for efficient development, flexible expansion and stable operation of electric energy meter, and a new technical scheme is needed to solve the above problems. SUMMARY

[0008] In order to overcome the shortcomings of the prior art, the present application provides an electric energy meter object-oriented data coding method, device, equipment and medium, which aims to improve the expansibility, code simplicity and maintenance convenience to meet the needs of smart grid for efficient development, flexible expansion and stable operation of electric energy meter.

[0009] The technical means adopted by the present application to solve its technical problems is: an electric energy meter object-oriented data coding method applied to a smart electric energy meter, wherein the improvement lies in that the method comprises the following steps:

[0010] Step S1, respectively define an object attribute structure and a general object structure; the object attribute structure at least includes a parameter pointer pointing to a data source and a virtual method table pointer, and the virtual method table contains a plurality of function pointers for operating the data source; the general object structure is used to manage one or more object attribute structures;

[0011] Step S2, obtaining the object identifier of the target object from the received message or instruction, and searching for the corresponding general object structure in the preset object set according to the object identifier;

[0012] Step S3, verifying the access authority of the target object attribute and checking the validity of the data source of the target object attribute according to the general object structure corresponding to the target object;

[0013] Step S4: In response to the target object's attributes being readable and the data source being valid, the corresponding encoding function is dynamically bound and called through the virtual method table in the object attribute structure corresponding to the target attribute, and the data source is encoded according to the predetermined encoding rules.

[0014] Step S1 in the above technical solution includes:

[0015] Step S101: Define the attributes of the target object through the ObjAttr_t structure, introduce a virtual method table to implement various operations on the attributes, and implement polymorphic behavior through function pointer jumps;

[0016] Step S102: Manage the attributes of the target object and other member objects that need to be extended through the ObjBase_t structure to achieve object abstraction and encapsulation; the management content includes the attribute list, the number of attributes, and the attribute identifiers that need to be loaded.

[0017] Step S2 in the above technical solution includes:

[0018] Step S201: Parse the object attribute descriptor (OAD) of the target object from the message or command of the query data;

[0019] Step S202: Based on the object identifier OI in the object attribute descriptor OAD, search for the object in the system's operable object list. If the target object exists, check whether the object is allowed to be accessed based on the current system security parameters and operating mode; otherwise, proceed to exception handling.

[0020] Step S203: Based on the fact that the object is allowed to be accessed, proceed to step S3.

[0021] Step S3 in the above technical solution includes:

[0022] Step S301: Determine the attribute X to be accessed of the target object based on the ATTR field of the object attribute descriptor OAD, and check whether the target object has the attribute X; otherwise, proceed to exception handling.

[0023] Step S302: Based on the fact that the target object has the attribute X, determine that all the data in the attribute X is to be read according to the INDEX field of the object attribute descriptor OAD, and perform a data existence and validity judgment.

[0024] The data existence and validity determination in step S302 of the above technical solution includes:

[0025] Step S3021: If the data in attribute X exists, further check whether its data value is out of bounds; otherwise, proceed to exception handling.

[0026] Step S3022, if the data value does not exceed the boundary, further judge whether there is a CRC check code in the structure where the data is located; otherwise, jump to the exception handling;

[0027] Step S3023, based on the fact that the data does not exceed the boundary and there is a CRC check code, recalculate the CRC check code and compare the calculation result with the original CRC check code attached in the structure body, and if the result is consistent, the check is passed and the data is valid.

[0028] The step S4 in the technical solution comprises:

[0029] Step S401, determine the general format type of the configuration parameter according to the specific protocol and the subfields contained therein, fill in the encoding corresponding to the format type and the number of subfields in the buffer;

[0030] Step S402, determine the encoding corresponding to each subfield type and the encoding corresponding to the field data according to the specific definition of each subfield;

[0031] Step S403, fill the encoded data into the response message and send it to the upper computer or transmit it to the program internal call.

[0032] The step S1 in the technical solution further comprises:

[0033] An extensibility structure for a specific function is defined, the specific function including but not limited to control parameters, storage addresses, associated objects, and supporting non-volatile storage and verification mechanism; through the extensibility structure, function customization can be flexibly realized without affecting the basic object, and the changing needs of different protocols and business scenarios can be adapted.

[0034] The technical means adopted by the application to solve the technical problems is: an object-oriented data encoding device, comprising:

[0035] A structure definition module is used to define an object attribute structure and a general object structure respectively;

[0036] An object analysis module is used to obtain the object identifier of a target object from the received message or instruction, and find the corresponding general object structure in the preset object set according to the object identifier;

[0037] A data verification module is used to verify the access authority of the target object attribute and check the validity of the data source of the target object attribute according to the general object structure corresponding to the target object;

[0038] A data encoding module is configured to, in response to the target object attribute being readable and the data source being valid, dynamically bind and call a corresponding encoding function through a virtual method table in an object attribute structure corresponding to the target attribute, and encode the data source according to a predetermined encoding rule.

[0039] The technical means adopted by the present application to solve the technical problems is: an apparatus, characterized in that comprising: at least one processor, at least one memory, wherein,

[0040] The memory stores program instructions or codes;

[0041] The program instructions or codes are loaded and executed by the processor, so that the electronic device implements the object-oriented data encoding method of the electric energy meter as described above.

[0042] The technical means adopted by the present application to solve the technical problems is: a medium storing program instructions or codes, characterized in that the program instructions or codes are loaded and executed by a processor to implement the object-oriented data encoding method of the electric energy meter as described above.

[0043] The present application has the following beneficial effects:

[0044] Good protocol compatibility and portability: based on A-XDR encoding rules, it can be seamlessly connected with multiple commonly used electric meter protocols such as DL / T 698.45 and DLMS; when porting the method, the object attribute is modified according to the specific protocol, that is, the processing steps related to OAD in the invention, so that cross-project and cross-platform migration applications can be realized.

[0045] Flexible and efficient data storage: object and data source decoupling design, supporting independent optimization of storage format, combined with compression technology and on-demand type conversion, effectively saving storage space and improving encoding efficiency;

[0046] High system scalability and maintainability: polymorphism is realized through virtual method table and function pointer, supporting dynamic expansion of attributes and methods, code reuse of objects with the same structure, and only the encoding method needs to be expanded for new data types, reducing maintenance and iteration complexity;

[0047] Low resource occupation and high execution efficiency: based on C language, it has the advantages of object-oriented characteristics, high performance and low resource occupation, small size after compilation, direct hardware resource access, and is suitable for resource-constrained embedded scenarios. BRIEF DESCRIPTION OF DRAWINGS

[0048] Figure 1 A flowchart of an object-oriented data encoding method of an electric energy meter is shown for the embodiments of the present application.

[0049] Figure 2The flow chart of step S1 shown in the embodiment of the present application is as follows:

[0050] Figure 3 The flow chart of step S2 shown in the embodiment of the present application is as follows:

[0051] Figure 4 The flow chart of step S3 shown in the embodiment of the present application is as follows:

[0052] Figure 5 The flow chart of step S302 shown in the embodiment of the present application is as follows:

[0053] Figure 6 The flow chart of step S4 shown in the embodiment of the present application is as follows:

[0054] Figure 7 The structure diagram of an object-oriented data coding device of an electric energy meter shown in the embodiment of the present application is as follows:

[0055] Figure 8 The structure block diagram of an apparatus shown in the embodiment of the present application is as follows. DETAILED DESCRIPTION

[0056] The present application will be further described below in combination with the drawings and embodiments.

[0057] The concept, specific structure and generated technical effects of the present application will be clearly and completely described below in combination with embodiments and drawings, so as to fully understand the purposes, features and effects of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments of the present application, other embodiments obtained by those skilled in the art without creative labor are within the protection scope of the present application. In addition, all the coupling / connection relations involved in the patent do not mean that the components are directly connected, but means that the better coupling structure can be composed by adding or reducing the coupling auxiliary components according to the specific implementation situation. The technical features in the present application can be combined with each other without conflict.

[0058] As shown in the accompanying drawings and embodiments, the present application provides an object-oriented data coding method of an electric energy meter, applied to a smart electric energy meter, comprising the following steps: Figure 1

[0059] Step S1, defining an object attribute structure and a general object structure respectively.

[0060] The object attribute structure comprises at least a parameter pointer pointing to a data source and a virtual method table pointer, the virtual method table comprises a plurality of function pointers for operating the data source; the general object structure is used for managing one or more object attribute structures.

[0061] ​In a possible implementation, as shown in FIG. 1, Figure 2 The step S1 includes:

[0062] In step S101, the attribute of the target object is defined by the ObjAttr_t structure, the virtual method table is introduced to implement various operations on the attribute, and the polymorphic behavior is implemented by the function pointer jump.

[0063] The function pointer in the virtual method table binds the specific operation function at runtime, implements the polymorphic behavior, so that when a new operation on the attribute is added, only the virtual method table needs to be extended and the new function needs to be implemented, without modifying the original object attribute structure.

[0064] Specifically, the object attribute structure implementation code is as follows:

[0065]

[0066] The operations of the virtual method table vmt on the object attribute include but are not limited to reading and setting, and the polymorphic behavior can be implemented by the function pointer jump (such as different data types can use different encoding functions, and different objects can use the parameter setting functions required by themselves), so that when a new operation is added, the original object structure does not need to be modified, which significantly improves the flexibility of the code.

[0067] The param pointer points to the actual data source, which realizes the decoupling of the object and the data, not only enables the same data to be shared by multiple objects, improves the code reuse rate, but also allows the data storage format to be independently designed, supports optimization means such as compression, and effectively saves storage space. Other members such as read-write permissions and data types are used to standardize the meta information of the attribute, and enhance the self-description ability of the attribute.

[0068] The virtual method table is defined as follows:

[0069]

[0070]

[0071] Wherein GetSize is the byte size of the valid data of the Attr; Encode is the specific implementation of encoding the part or all data in the Attr according to the Axdr rule, usually only called in Get. Get and GetRecord are to obtain the part or all data in the Attr encoded according to the Axdr rule, the difference is that Get is for the parameter value of the Attr such as the trigger threshold voltage of the under-voltage event of the electric energy meter and the trigger judgment time length, while GetRecord is for the specific data record corresponding to the Attr such as an under-voltage event record of the electric energy meter. Set and Get are opposite, mainly to parse the parameter value set to the Attr from the received message or instruction and save it to the corresponding RAM, Flash, EEPROM. Draw is the specific implementation process of the data in the Attr that may need to be displayed on the LCD liquid crystal screen of the electric energy meter, mainly called in DrawSelf. DrawSelf is a further encapsulation of Draw, because sometimes some specific processing is needed before or after display.

[0072] Step S102, the attributes of the target object and other member objects that need to be extended are managed through the ObjBase_t structure, realizing the abstraction and encapsulation of the object; the management content includes the attribute list, the attribute number and the attribute identifier that needs to be loaded.

[0073] The general object structure is defined as follows:

[0074]

[0075] The general object structure is used as the base class of all objects, uniformly manages the attributes of the objects and other member objects that need to be extended, and realizes the abstraction and encapsulation of the objects. This design enables the objects to be dynamically identified and operated at runtime, improving the modularization degree and maintainability of the system.

[0076] In a possible implementation manner, the step S1 further includes:

[0077] An extensibility structure for a specific function is defined, the specific function includes but is not limited to a control parameter, a storage address, an associated object, and supports a non-volatile storage and a verification mechanism; through the extensibility structure, the function customization can be flexibly realized without affecting the basic object, and the changing needs of different protocols and business scenarios can be adapted.

[0078] Step S2, an object identifier of the target object is obtained from the received message or instruction, and the corresponding general object structure is searched in a preset object set according to the object identifier.

[0079] In a possible implementation manner, as Figure 3As shown, the step S2 comprises:

[0080] Step S201, parsing the object attribute descriptor OAD of the target object from the message or instruction of the query data;

[0081] Step S202, searching for the object in the list of system operable objects according to the object identifier OI in the object attribute descriptor OAD, and checking whether the object is allowed to be accessed according to the current system security parameter and operation mode if the target object exists; otherwise, jumping to the exception handling;

[0082] Step S203, jumping to step S3 based on that the object is allowed to be accessed.

[0083] Specifically, taking the positive active energy of the target object as an example, the object attribute descriptor OAD thereof parsed from the message or instruction of the query data is 0x00100200, and the object identifier OI thereof is 0x0010. The object is searched in the list of system operable objects, and if the object does not exist, the exception handling is jumped to; if the object exists, whether the object is allowed to be accessed is checked according to the current system security parameter and operation mode; if the object is allowed to be accessed, step S3 is jumped to, otherwise, the exception handling is jumped to.

[0084] Step S3, verifying the access permission of the target object attribute and checking the validity of the data source of the target object attribute according to the general object structure corresponding to the target object.

[0085] In a possible implementation, as shown in Figure 4 As shown, the step S3 of verifying the access permission of the target object attribute according to the general object structure corresponding to the target object comprises:

[0086] Step S301, determining the to-be-accessed attribute X of the target object according to the ATTR field of the object attribute descriptor OAD, and checking whether the target object has the attribute X; otherwise, jumping to the exception handling;

[0087] Step S302, based on that the target object has the attribute X, determining that all data in the attribute X is to be read according to the INDEX field of the object attribute descriptor OAD, and performing data existence and validity judgment.

[0088] Specifically, taking the positive active electric energy as an example, the ATTR field of the object attribute descriptor OAD, i.e., the 3rd byte is 0x02, can determine that the attribute to be accessed is attribute 2. Then it is checked whether the positive active electric energy has the attribute 2, if the positive active electric energy does not have the attribute 2, it jumps to the exception processing. If the attribute 2 exists, according to the INDEX field of the object attribute descriptor OAD, i.e., the 4th byte is 0x00, it is determined that all data in the attribute 2 is to be read, and the data existence and validity judgment is performed.

[0089] In a possible implementation, as shown in the figure, Figure 5 The data existence and validity judgment in the step S302 includes:

[0090] In the step S3021, if the data in the attribute X exists, it is further checked whether the data value is out of range; otherwise, it jumps to the exception processing.

[0091] In the step S3022, if the data value is not out of range, it is further judged whether the CRC check code exists in the structure where the data is located; otherwise, it jumps to the exception processing.

[0092] In the step S3023, based on the fact that the data is not out of range and the CRC check code exists, the CRC check code is recalculated and the calculation result is compared with the original CRC check code attached in the structure, if the results are consistent, the check is passed and the data is valid.

[0093] Specifically, the data out of range judgment in the step S3021 includes the following steps:

[0094] Sometimes, data has an upper limit, a lower limit or a certain format, which is explicit or implicit. For example, by convention, the size of the "hour" field in the current time cannot exceed 24, and the size of the "minute" and "second" fields cannot exceed 60; due to special requirements, the program also stipulates that the "year" field of the current time cannot be lower than 2000. Therefore, when obtaining data, it is necessary to check whether the data is within a reasonable range according to the specific rules of different data.

[0095] Specifically, the CRC check in the step S3023 includes the following steps: the structure where some important data is located can be attached with a 2-byte CRC-16 check code, and the CRC-16 check code is recalculated every time the data value is modified; when checking the CRC check, the CRC-16 check value of all parameters (except the CRC check code) in the structure where the data is located is calculated, and then the result is compared with the CRC check code attached in the structure, if the results are consistent, the CRC check is passed.

[0096] Step S4, in response to the target object attribute being readable and the data source being valid, dynamically binding and calling the corresponding encoding function through the virtual method table in the object attribute structure corresponding to the target attribute, and encoding the data source according to a predetermined encoding rule.

[0097] In one possible implementation, as shown in Figure 6 The step S4 includes:

[0098] Step S401, determining the configuration parameter general format type and the subfields contained therein according to a specific protocol, and filling the encoding corresponding to the format type and the number of subfields in the buffer.

[0099] In an exemplary embodiment, the specific protocol includes all protocols based on A-XDR encoding rules, such as State Grid 698 protocol.

[0100] Step S402, determining the encoding corresponding to each subfield type and the encoding corresponding to the field data according to the specific definition of each subfield.

[0101] Step S403, filling the encoded data into the response message and sending it to the host computer or transmitting it to the program internal call.

[0102] Specifically, continuing with the above example of the target object being the positive active energy, assuming that the current rate number is 4, the total energy is 10 Kwh, the rate 1 energy is 1 Kwh, the rate 2 energy is 2 Kwh, the rate 3 energy is 3 Kwh, and the rate 4 energy is 4 Kwh, then during encoding:

[0103] First, according to the A-XDR encoding rule, the configuration parameter general format is determined to be an array type, and there are 1+4 subfields (total energy + 4 rate energies) inside, so 0x01 (the encoding corresponding to the array type) and 0x05 (indicating that there are 5 subfields inside the structure) are filled in the buffer.

[0104] Then the specific definition of each subfield, the total electric energy unit is 0.01V, type is u32, then the buffer needs to fill 0x06 (u32 type corresponding to the code) 0x00 0x00 0x03 0xE8 (message data using big endian, 0x3E8 corresponds to the decimal 1000, that is, 1000*0.01Kwh=10Kwh); the electric energy of rate 1~rate 4 is: unit 0.01V, type u32, then the buffer needs to fill 0x06 0x00 0x00 0x00 0x64 (rate 1, 0x64 corresponds to 100 in decimal), 0x06 0x00 0x00 0x00 0xc8 (rate 2, 0xc8 corresponds to 200 in decimal), 0x06 0x00 0x00 0x01 0x2c (rate 3, 0x12c corresponds to 300 in decimal), 0x06 0x00 0x00 0x01 0x90 (rate 4, 0x190 corresponds to 400 in decimal) in turn.

[0105] Finally, the encoding result of the positive active electric energy is "01 05 06 00 00 03e8 0600 00 00 6406 00 00 00c8 06 00 00 01 2c 06 00 00 01 90" is filled into the response message and sent to the host computer through the communication interface (such as infrared, RS485, etc.) or directly sent to the caller inside the program.

[0106] It is worth mentioning that the exception handling of the jump in the entire encoding process will generate a corresponding exception response, such as sending an exception response message to the host computer, or returning an exception response to the caller inside the program.

[0107] At the same time, although the present application describes a kind of object-oriented data encoding method of electric energy meter, its decoding process is the inverse process of the described encoding method, therefore, the method provided by the present application is inversely realized, i.e. the decoding process corresponding to the encoding method is obtained, the decoding process is also included in the range defined in the claims of the present application.

[0108] The following is an embodiment of the device of the present application, which can be used to execute the object-oriented data encoding method of the electric energy meter related by the present application. For details not disclosed in the device embodiment of the present application, please refer to the method embodiment of the object-oriented data encoding method of the electric energy meter related by the present application.

[0109] Please refer to Figure 7 In the embodiment of the present application, an object-oriented data encoding device 50 is provided, which comprises a structure definition module 501, an object analysis module 502, a data verification module 503 and a data encoding module 504.

[0110] The structure definition module 501 is configured to define an object attribute structure and a general object structure, respectively.

[0111] The object analysis module 502 is configured to obtain an object identifier of a target object from a received message or instruction, and search for a corresponding general object structure in a preset object set according to the object identifier.

[0112] The data verification module 503 is configured to verify an access right of the target object attribute and check validity of a data source of the target object attribute according to the general object structure corresponding to the target object.

[0113] The data coding module 504 is configured to, in response to the target object attribute being readable and the data source being valid, dynamically bind and call a corresponding coding function through a virtual method table in the object attribute structure corresponding to the target attribute, and code the data source according to a predetermined coding rule.

[0114] It should be noted that the above embodiment provides an electric energy meter object-oriented data coding device, which only divides the above functions for example, and in actual application, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the electric energy meter object-oriented data coding device is divided into different functional modules to complete all or part of the above described functions. The above modules can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory in the computer device in software form, so as to be called and executed by the processor to perform the operations corresponding to the above modules.

[0115] In addition, the electric energy meter object-oriented data coding device and the method embodiment of the electric energy meter object-oriented data coding method provided in the above embodiment belong to the same concept, and the specific operation of each module has been described in detail in the method embodiment, which will not be described here.

[0116] Please refer to Figure 8 In the embodiment of the present application, an electronic device 4000 is provided.

[0117] In Figure 8In the middle, the data interaction between the processor 4001 and the memory 4003 can be implemented through at least one communication bus 4002. The communication bus 4002 can include a channel for transmitting data between the processor 4001 and the memory 4003. The communication bus 4002 can be a PCI (Peripheral Component Interconnect, Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture, Extended Industry Standard Architecture) bus, etc. The communication bus 4002 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 8 In the middle, only one thick line is used to represent it, but it does not mean that there is only one bus or only one type of bus.

[0118] Optionally, the electronic device 4000 can also include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as data transmission and / or data reception, etc. It should be noted that the transceiver 4004 is not limited to one in actual application, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present application.

[0119] The processor 4001 can be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array) or other programmable logic device, a transistor logic device, a hardware component or any combination thereof. It can implement or execute various exemplary logical blocks, modules and circuits described in combination with the disclosure. The processor 4001 can also be a combination of computing functions, such as one or more microprocessor combinations, combinations of DSP and microprocessor, etc. The memory 4003 can be a ROM (Read Only Memory) or other type of static storage device that can store static information and instructions, a RAM (Random Access Memory) or other type of dynamic storage device that can store information and instructions, an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory) or other optical disk storage, an optical disk storage (including a compact disk, a laser disk, an optical disk, a digital versatile disk, a Blu-ray disk, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium capable of carrying or storing desired program instructions or code in the form of instructions or data structures and accessible by the electronic device 400, but not limited to.

[0120] The memory 4003 stores program instructions or code, which can be read by the processor 4001 through the communication bus 4002.

[0121] The program instructions or code are executed by the processor 4001 to implement the power meter object-oriented data encoding method described above.

[0122] In addition, the present application provides a storage medium, which stores program instructions or code, and the program instructions or code are loaded and executed by the processor to implement the power meter object-oriented data encoding method as described above.

[0123] The embodiment of the present application provides a computer program product, the computer program product includes program instructions or codes, the program instructions or codes are stored in a storage medium, a processor of an electronic device reads the program instructions or codes from the storage medium, loads and executes the program instructions or codes, so that the electronic device implements the power meter object-oriented data encoding method as described above.

[0124] The above is a specific description of the preferred embodiment of the application, but the application is not limited to the described embodiments, and those skilled in the art can make various equivalent modifications or replacements without departing from the spirit of the application, and these equivalent modifications or replacements are all included in the scope defined by the claims of the present application.

Claims

1. A method for encoding object-oriented data of an electric energy meter, characterized by, The method comprises the following steps: Step S1, defining an object attribute structure and a general object structure respectively; the object attribute structure comprises at least a parameter pointer pointing to a data source and a virtual method table pointer, and the virtual method table comprises a plurality of function pointers for operating the data source; the general object structure is used for managing one or more object attribute structures; Step S2, obtaining an object identifier of a target object from a received message or instruction, and searching for a corresponding general object structure in a preset object set according to the object identifier; Step S3, verifying an access right of the target object attribute and checking validity of a data source of the target object attribute according to the general object structure corresponding to the target object; Step S4, in response to the target object attribute being readable and the data source being valid, dynamically binding and calling a corresponding encoding function through a virtual method table in the object attribute structure corresponding to the target attribute, and performing an encoding operation on the data source according to a predetermined encoding rule.

2. The method of claim 1, wherein the method further comprises: The step S1 comprises: Step S101, defining an attribute of a target object through an ObjAttr_t structure, introducing a virtual method table to implement a plurality of operations on the attribute, and realizing polymorphic behavior through function pointer jumping; Step S102, managing the attribute of the target object and other member objects needing to be extended through an ObjBase_t structure, and realizing abstraction and encapsulation of the object; the management content comprises an attribute list, an attribute number, and an attribute identifier needing to be loaded.

3. The method of claim 1, wherein the method further comprises: The step S2 comprises: Step S201, parsing an object attribute descriptor OAD of a target object from a message or instruction for querying data; Step S202, searching for the object in a system operable object list according to an object identifier OI in the object attribute descriptor OAD, and checking whether the object is allowed to be accessed according to a current system security parameter and a running mode if the target object exists; otherwise, jumping to an exception processing; Step S203, jumping to step S3 based on the object being allowed to be accessed.

4. The method of claim 3, wherein the method further comprises: The step S3 comprises: Step S301, determining a to-be-accessed attribute X of the target object according to an ATTR field of the object attribute descriptor OAD, and checking whether the target object has the attribute X; otherwise, jumping to an exception processing; Step S302, based on the target object having the attribute X, determining that all data in the attribute X is to be read according to an INDEX field of the object attribute descriptor OAD, and performing data existence and validity judgment.

5. The method of claim 4, wherein the method further comprises: The data existence and validity judgment in step S302 comprises: Step S3021, if the data in the attribute X exists, further checking whether the data value is out of bounds; otherwise, jumping to an exception processing; Step S3022, if the data value is not out of bounds, further judging whether a CRC check code exists in a structure where the data is located; otherwise, jumping to an exception processing; Step S3023, based on the data without boundary and the existence of CRC check code, re-calculate the CRC check code and compare the calculation result with the original CRC check code attached in the structure, the result is consistent, the check is passed, the data is valid.

6. The method of claim 1, wherein the method further comprises: The step S4 comprises: Step S401, according to the specific protocol, determine the configuration parameter general format type and the internal contained subfield, fill in the format type corresponding code and the number of subfields in the buffer area; Step S402, according to the specific definition of each subfield, determine the code corresponding to each subfield type and the code corresponding to the field data; Step S403, fill in the encoded data into the response message, and send to the host computer or transmit to the program internal call.

7. The method of claim 1, wherein the method further comprises: The step S1 further comprises: ​ Define an extensibility structure for a specific function, the specific function includes but is not limited to control parameters, storage address, associated object, and support non-volatile storage and check mechanism; through the extensibility structure, the function customization can be realized flexibly without affecting the basic object, and the changing needs of different protocols and business scenarios can be adapted.

8. An apparatus for encoding object-oriented data of an electric energy meter, characterized by comprising: The device comprises: A structure definition module is configured to define an object attribute structure and a general object structure respectively; An object parsing module is configured to obtain an object identifier of a target object from a received message or instruction, and search for a corresponding general object structure in a preset object set according to the object identifier; A data verification module is configured to verify an access right of the target object attribute and check validity of a data source of the target object attribute according to the general object structure corresponding to the target object; A data coding module is configured to, in response to the target object attribute being readable and the data source being valid, dynamically bind and call a corresponding coding function through a virtual method table in the object attribute structure corresponding to the target object attribute, and code the data source according to a predetermined coding rule.

9. An apparatus, comprising: Comprise: At least one processor, at least one memory, wherein, Program instructions or codes are stored on the memory; The program instructions or codes are loaded and executed by the processor, so that the electronic device implements the electric energy meter object-oriented data coding method in any one of claims 1 to 7.

10. A medium having stored thereon program instructions or code, characterized in that, The program instructions or codes are loaded and executed by the processor to implement the electric energy meter object-oriented data coding method in any one of claims 1 to 7.

Images