Intelligent electric meter embedded control management software framework and construction method

Abstract

The application discloses a kind of intelligent electric meter embedded control management software framework and construction method, the framework includes message transmission layer, service layer and configuration file and plug-in management layer, the message transmission layer is used to process from the data that needs to be sent to the electric meter side and the data sent to the electric meter side, according to data rule to encode and decode and data transmission and reception;The service layer is used to provide service data processing and operation action response for electric meter data service and local, remote query and debugging operation;The configuration file and plug-in management layer are used to realize the management of each plug-in and interface.The whole intelligent electric meter embedded software system is constructed using plug-in technology in the application, so that the main program does not need to be changed when changing and upgrading functions, and the function can be updated by adding plug-ins and changing configurations.

Description

Technical Field

[0001] This invention relates to the field of smart meter technology, and in particular to a smart meter embedded control and management software architecture and construction method. Background Technology

[0002] Unlike traditional electricity meters that can only perform simple electricity measurement, smart meters have an internal MCU that can perform various types of electricity parameter measurement and calculation, various rate calculations, and data format uploads, in addition to traditional electricity measurement. To better standardize data processing and transmission in smart meters, the power industry has defined many different versions of meter protocols, such as the domestic DL / T series and the international IEC series. Meanwhile, as the complexity of smart meters increases, their on-site installation, deployment, and commissioning also become more complicated. Therefore, there is a strong need for embedded control and management software for smart meters that can flexibly adapt to various meter protocols, manufacturer-specific protocols, and multiple installation, deployment, and commissioning methods to reduce adaptation costs and provide more diverse and flexible installation and commissioning capabilities.

[0003] Existing embedded control and management software for smart meters generally suffers from the following drawbacks in terms of architecture and implementation: 1. Support for multiple protocols and proprietary protocols is quite complicated, and it basically requires rewriting the ROM.

[0004] 2. There are not many on-site installation and debugging methods. The function of each module needs to be debugged with the cooperation of the main station or even the monitoring center. The hardware modules mainly rely on on-site engineers to observe whether they are operating normally. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides an embedded control and management software architecture and construction method for smart meters.

[0006] This invention is implemented using the following technical solution: an embedded control and management software architecture for smart meters, comprising a message transceiver layer, a service layer, and a configuration file and plugin management layer. The message transceiver layer is used to process data that needs to be sent out from the meter side and data sent from outside to the meter side, and to encode, decode, and transmit data according to data rules. The service layer is used to provide business data processing and operation action response for meter data business processing, as well as local and remote query and debugging operations. The configuration file and plugin management layer is used to implement the system configuration file, as well as the loading, verification, data interface adaptation of each plugin, and the function of providing API interfaces to the corresponding modules of the service layer.

[0007] Furthermore, the message transceiver layer includes a message transceiver module and a message processing module. When processing data that needs to be sent out from the meter side, the message processing module processes the message data sent by the service layer and sends it to the message transceiver module. The message transceiver module encodes and decodes the message according to the message type and distributes it to the corresponding communication interface to complete the data transmission. When processing data sent from outside to the meter side, the message transceiver module receives data from each interface and, according to the different message types and the set data rules, deframes and decodes the data into an internal data structure before sending it to the corresponding interface message processing module for processing.

[0008] Furthermore, the message processing module includes a bus interface message processing module and an HTTP interface message processing module.

[0009] Furthermore, the service layer includes an initialization and thread scheduling module, an FSM (Finite State Machine) state machine service module, a meter protocol processing service module, and a built-in HTTP service module. The initialization and thread scheduling module is used to initialize the management software architecture system and load functional plugins and schedule worker threads according to the configuration. The built-in HTTP service module is used to establish local HTTP and HTTPS services. The meter protocol processing service module is used to load the meter protocol processing plugin and start the local protocol processing service. The FSM state machine service module is used to provide state transition and state triggering processing services for the meter protocol processing service module and the built-in HTTP service module.

[0010] Furthermore, the configuration file and plugin management layer includes a plugin manager module, a configuration file management module, and a system configuration file. The plugin manager module provides system configuration information and plugin information to form a list of plugins that need to be loaded. The configuration file management module provides functions for loading, analyzing, modifying, and saving configuration files. The system configuration file is used to save system configuration, functional module enablement, and plugin information.

[0011] Furthermore, the configuration file and plugin management layer also includes a bus plugin interface module, a meter protocol plugin interface module, and an HTTP service plugin interface module. The bus plugin interface module is used to load, verify, and adapt the data interface of the bus plugins to be loaded, and provide corresponding API operation interfaces to the service layer. The meter protocol plugin interface module is used to load, verify, and adapt the data interface of the meter protocol plugins to be loaded, and provide corresponding operation interfaces to the service layer. The HTTP service plugin interface module is used to load, verify, and adapt the data interface of the HTTP service plugins to be loaded, and provide corresponding API operation interfaces to the service layer.

[0012] A method for constructing an embedded control and management software architecture for smart meters includes the following steps: S1: Build the configuration file and plugin management layer; S2: Construct the service layer; S3: Build the message sending and receiving layer.

[0013] Furthermore, step S1 specifically involves: planning system configuration items and plugin types, API operation interfaces between plugins and the system, and the storage location of plugin files on local storage, and implementing the functions of each plugin, interface module, and plugin management module.

[0014] Furthermore, step S2 includes the following sub-steps: S21: Build the built-in HTTP service module; S22: Construct the meter protocol processing service module; S23: Construct the initialization and thread scheduling module.

[0015] Furthermore, step S3 includes the following sub-steps: S31: Construct the message processing module; S32: Build the message sending and receiving module.

[0016] The beneficial effects of this invention are as follows: This invention employs plug-in technology to build the software system and a built-in HTTP server to improve deployment and debugging methods. The plug-in technology used to build the entire smart meter embedded software system allows for functional updates without modifying the main program; instead, updates are achieved by changing or adding plug-ins and modifying corresponding configurations. These functional updates include multi-protocol support, support for manufacturer-specific protocols, support for multiple communication methods, and component updates. The built-in HTTP service makes deployment and debugging methods more diverse and convenient. On-site debugging personnel can directly view parameters and debug configurations on-site through the local port; it also supports direct connection from the main station and monitoring center to the meter to view parameters and debug configurations. Attached Figure Description

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

[0018] Figure 1 This is a block diagram of the invention's architecture; Figure 2 This is the working principle of the present invention; Figure 3 This is a flowchart illustrating the construction process of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0020] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0021] The following detailed description of some embodiments of the present invention is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0022] Example 1: See Figure 1 An embedded control and management software architecture for smart meters includes a message transceiver layer, a service layer, and a configuration file and plugin management layer. The message transceiver layer processes data from the meter side that needs to be sent out and data sent from outside to the meter side, and performs encoding, decoding, and data transmission and reception according to data rules. The service layer provides business data processing and operation action response for meter data services, as well as local and remote query and debugging operations. The configuration file and plugin management layer implements system configuration files, and loads, verifies, adapts data interfaces to various plugins, and provides API interface management functions to corresponding modules in the service layer.

[0023] In this embodiment, the message transceiver layer includes a message transceiver module and a message processing module. When processing data that needs to be sent out from the meter side, the message processing module processes the message data sent by the service layer and sends it to the message transceiver module, which then completes the data transmission. When processing data sent from outside to the meter side, the message transceiver module receives data from various interfaces and sends it to the message processing module for processing. Furthermore, the message processing module includes a bus interface message processing module and an HTTP interface message processing module.

[0024] When the meter needs to send data externally: the bus interface message processing module and the HTTP interface message processing module process the bus interface message data and HTTP interface message data sent from the service layer, encode and frame the above two types of data according to the set external sending rules, and send them to the message sending and receiving module. The message sending and receiving module distributes the data to the corresponding hardware interface according to the message type to complete the data external sending.

[0025] When external data is sent to the meter: the message transceiver module receives data from various communication interfaces, and decodes the data into internal data structures of the meter processing software according to the set data rules. Then, it sends the data to the bus interface message processing module and the HTTP interface message processing module for processing according to the data type.

[0026] In this embodiment, the service layer provides specific business data processing and operation action response for meter data services and local and remote query and debugging operations. Specifically, it includes four modules: initialization and thread scheduling module, FSM state machine service module, meter protocol processing service module, and built-in HTTP service module.

[0027] The initialization and thread scheduling module initializes the system based on the configuration file and system function plugins and system configuration information sent from the plugin management layer, loads function plugins, and schedules worker threads to start corresponding services. The built-in HTTP service module establishes local HTTP and HTTPS services and enables corresponding operation response functions based on the loaded HTTP service plugin. The meter protocol processing service module loads the telegraph protocol processing plugin and starts local protocol processing (parsing, encoding, reading metering data, merging and calculating business data, and providing data for bus operation / HTTP operation commands) services. The FSM state machine service module constructs an FSM to provide state transition and state triggering processing services for the meter protocol processing module and the built-in HTTP service module.

[0028] In this embodiment, the configuration file and plugin management layer includes a plugin manager module, a configuration file management module, a system configuration file, a bus plugin interface module, a meter protocol plugin interface module, and an HTTP service plugin interface module.

[0029] The plugin manager module, based on system configuration and plugin information provided by the configuration file management module, generates a list of bus plugins, meter protocol plugins, and HTTP service plugins that need to be loaded for the current program. This list is then provided to the service layer for on-demand loading to provide services. The bus plugin interface module loads, verifies, and adapts the data interfaces of the required bus plugins (each plugin supports a specific bus communication protocol) and provides corresponding operation interfaces to the relevant service modules in the service layer. The meter protocol plugin interface module loads, verifies, and adapts the data interfaces of the required meter protocol plugins (each plugin supports a specific meter protocol) and provides corresponding operation interfaces to the relevant service modules in the service layer. The HTTP service plugin interface module loads, verifies, and adapts the data interfaces of the required HTTP service plugins (each plugin provides specific server functions or service command processing functions) and provides corresponding operation interfaces to the relevant service modules in the service layer. The configuration file management module provides functions for loading, analyzing, modifying, and saving configuration files. The system configuration file stores system configuration, enabled functional modules, and plugin information.

[0030] See Figure 2 The working principle of this invention is as follows: When the system starts, (1) the plug-in management module is loaded first. This module obtains the saved system configuration and plug-in information through the configuration file management module. Then, each plug-in interface module loads, verifies the plug-in, and adapts the data interface to provide services to the relevant service modules of the "service layer". Then (2) the system loads the HTTP service and the meter protocol processing service module to prepare to provide data processing services to the internal and external parties. Because the HTTP service and the meter protocol processing service process are relatively complex, the FSM state machine in the system provides state transition services for them. Among them, the HTTP service provides the ability to respond to external commands. The external host computer can access the meter through the local port of the meter or remotely, and debug the system or obtain the corresponding data through HTTP commands. The meter protocol processing service module provides the ability to parse, encode, read metering data, and integrate and calculate business data for various meter protocols, and provides the required data for bus operation / HTTP operation commands.

[0031] The system is now fully operational. During operation (3), the system has two types of processing tasks. One is that the measurement work thread started during initialization will read the data of the electricity meter according to the set period, and complete the processing of the electricity meter data through the electricity meter protocol processing service module. Then, after packaging the data according to the agreed data format, the data will be sent out through the message sending and receiving module. The other is that external commands received by the HTTP interface and bus interface through the message sending and receiving module will be processed by the interface message processing module and then call the corresponding service of the service layer to complete the data processing. If the processed data needs to be sent back to the command sender, it will be sent out through the message sending and receiving interface.

[0032] The most critical design feature of the architecture described in this invention is its plug-in design.

[0033] See Figure 3 The architecture of this system can be constructed by following these steps: S1: Building the configuration file and plugin management layer The system configuration items and plugin types, plugin operation interfaces, and their storage locations on local storage are planned. The functions of each plugin, interface module, and plugin management module are implemented. System configurations are saved in JSON format for easy reading and parsing. Configuration items mainly include: necessary configurations for system operation, main parameters and loading locations for protocol plugins, and main parameters and loading locations for bus and HTTP plugins.

[0034] Sample code: { "sync_server": "http: / / ... / action / apiSync", "threads_cfg": { "beater_tm_sec": 3, "dlt645_enable": 0, "dlt645_tm_sec": 10, "iec103_enable": 0, "iec103_tm_sec": 10, }, "serial_ctx": {"path": "\opt\plugin\serial1", "serial_name": "ttyS0", "serial_tm_ms":50, "baud_rate":1152000, "data_bit": 8, "stop_bit": 1, "event_bit": "n" }, "iec103_protocol": { "path": "\opt\plugin\iec103", "t_wz_cnt": 5, "GI_tm_sec": 900 }, "http_dlt645_api": { "path": "\opt\plugin\http_dlt645", "tm_cnt": 3, }, } The above configuration items define: `sync_server`: the address of the external synchronization server; `threads_cfg`: the initialization thread parameters for this device; `serial_ctx`: serial port plugin configuration parameters; `iec103_protocol`: IEC103 meter protocol plugin parameters; `http_dlt645_api`: HTTP service processing plugin parameters for the DLT645 protocol. In the above example, each protocol, bus, and HTTP plugin is developed separately according to its interface definition with the system, and then deployed to the preset path in the uploaded configuration file to await loading when the system starts. Further details are omitted here.

[0035] S2: Building the Service Layer Based on the parameters loaded by S1, a built-in HTTP service module and a meter protocol processing service module are constructed respectively.

[0036] S21: The built-in HTTP service module is a module that provides HTTP services. It supports HTTP and HTTPS protocols to provide web access to external networks. Its specific processing commands and functions can be defined through the "HTTP plugin".

[0037] S22: The meter protocol processing service module is a service module for various smart meter protocols. This module implements a framework processing program and an encoding / decoding engine. With the support of the FSM state machine service module, it completes complex encoding and decoding of various protocols, reads metering data, integrates and calculates service data, and provides data for bus operation / HTTP operation commands. It also supports different smart meter protocols and manufacturer-specific protocols through various protocol plugins.

[0038] S23: Implement the initialization and thread scheduling module. This module is the driver module for the entire application system. It is loaded first after the system starts, and then loads service plugins through the configuration file and plugin management layer according to the configuration parameters, and starts the business threads.

[0039] Sample code is as follows: hal_read_check_cfg_file_json() if (-1 == system_init()) return; if (pthread_create(&h_beater, NULL, (void*)h_beater_handler,NULL)) { return -1; } if(g_cfg_data.threads_cfg.http_enable){ if (pthread_create(&h_httpd, NULL, (void*)h_httpd_handler,NULL)){ return -1; } } if(g_cfg_data.threads_cfg.dlt645_enable){ if (pthread_create(&h_dlt645, NULL, (void*)h_dlt645_handler,NULL)){ return -1; } } if(g_cfg_data.threads_cfg.iec103_enable){ if (pthread_create(&h_iec103, NULL, (void*)h_iec103_handler,NULL)){ return -1; } }

[0040] S3: Building the Message Sending and Receiving Layer The interface message processing module processes the data and enables the sending and receiving of message data through the communication interface.

[0041] S31: Implement the interface message processing module. There are two types of data to be sent and received, which need to be implemented according to the specific message interface definition. One type is HTTP interface messages, which are mainly used to process commands for communication with external systems, including debugging and reading from the main station and the local debugging port. The other type is bus interface messages, which are mainly used to process messages from the device bus, such as ModBus bus data.

[0042] S32: Implements the message sending and receiving module, calling the hardware communication port driver to send the above messages to the corresponding hardware transmission port; or to receive and process data on the hardware transmission port. This involves specific functions such as handshake, retransmission, power-off resumption, and multi-frame splicing.

[0043] S4: Build and compile the target code, load and run it, assemble and compile the code of the above modules, and complete the loading and startup of the target code. After the target code is loaded and started, the system can complete business processing according to the following process.

[0044] This invention has at least the following technical effects: This invention employs plug-in technology to construct the entire embedded software system for smart meters. This allows for functional updates and upgrades without modifying the main program; updates are achieved simply by changing and adding plug-ins and modifying configurations. Functional changes and upgrades include support for multiple protocols, manufacturer-specific protocols, various communication methods, and component updates. The built-in HTTP service makes deployment and debugging more diverse and convenient. Field personnel can directly view parameters and debug configurations on-site via the local port; it also supports direct connection from the main station and monitoring center to the meter for parameter viewing and configuration adjustments.

[0045] It should be noted that, for the sake of simplicity, the foregoing embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to this application.

[0046] The above embodiments describe the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Modifications and variations made by those skilled in the art without departing from the spirit and scope of the invention should be within the protection scope of the appended claims.

Claims

1. An embedded control and management system for smart meters, characterized in that, It includes a message sending and receiving layer, a service layer, and a configuration file and plugin management layer. The message sending and receiving layer is used to process data that needs to be sent out from the meter side and data sent from outside to the meter side, and performs encoding and decoding and data sending and receiving according to data rules. The service layer is used to provide business data processing and operation action response for meter data business and local and remote query and debugging operations. The configuration file and plugin management layer is used to manage various plugins and interfaces. The service layer includes an initialization and thread scheduling module, an FSM state machine service module, a meter protocol processing service module, and a built-in HTTP service module. The initialization and thread scheduling module is used to initialize the management system according to the configuration, load functional plugins, and schedule worker threads. The built-in HTTP service module is used to establish local HTTP and HTTPS services, and load the HTTP service plugin according to the configuration to enable the corresponding operation command response function; the meter protocol processing service module is used to load the meter protocol processing plugin and start the local protocol processing service. The FSM state machine service module is used to provide state transition and state triggering processing services for the meter protocol processing service module and the built-in HTTP service module. The configuration file and plugin management layer includes a plugin manager module, a configuration file management module, and a system configuration file. The plugin manager module provides system configuration information and plugin information to form a list of plugins that need to be loaded. The configuration file management module provides functions for loading, analyzing, modifying, and saving configuration files. The system configuration file stores system configuration, function module enablement, and plugin information. The configuration file and plugin management layer also includes a bus plugin interface module, a meter protocol plugin interface module, and an HTTP service plugin interface module. The bus plugin interface module loads, verifies, and adapts the data interfaces of the bus plugins to be loaded, and provides corresponding operation interfaces to the service layer. The meter protocol plugin interface module loads, verifies, and adapts the data interfaces of the meter protocol plugins to be loaded, and provides corresponding API operation interfaces to the service layer. The HTTP service plugin interface module loads, verifies, and adapts the data interfaces of the HTTP service plugins to be loaded, and provides corresponding API operation interfaces to the service layer.

2. The embedded control and management system for smart meters as described in claim 1, characterized in that, The message transceiver layer includes a message transceiver module and a message processing module. When processing data that needs to be sent out from the meter side, the message processing module processes the message data transmitted from the service layer and sends it to the message transceiver module. The message transceiver module completes the data encoding and outgoing. When processing data sent from outside to the meter side, the message transceiver module collects data from each interface and sends it to the corresponding message processing module for processing.

3. The embedded control and management system for smart meters as described in claim 2, characterized in that, The message processing module includes a bus interface message processing module and an HTTP interface message processing module.

4. A method for constructing an embedded control management system for a smart meter, used to construct the embedded control management system for a smart meter as described in any one of claims 2-3, characterized in that, Includes the following steps: S1: Build the configuration file and plugin management layer; S2: Construct the service layer; S3: Build the message sending and receiving layer.

5. The method for constructing an embedded control and management system for a smart meter as described in claim 4, characterized in that, Step S1 specifically involves: planning system configuration items and plugin types, API operation interfaces between plugins and the system, and the storage location of plugin files on local storage, and implementing the functions of each plugin, interface module, and plugin management module.

6. The method for constructing an embedded control and management system for a smart meter as described in claim 4, characterized in that, Step S2 includes the following sub-steps: S21: Build the built-in HTTP service module; S22: Construct the meter protocol processing service module; S23: Construct the initialization and thread scheduling module.

7. The method for constructing an embedded control and management system for a smart meter as described in claim 4, characterized in that, Step S3 includes the following sub-steps: S31: Construct the message processing module; S32: Build the message sending and receiving module.

Images