A working method for shared data access of power system fusion terminals

Abstract

The present invention provides a working method for shared data access of power system fusion terminals, designs an App access shared data architecture according to business needs; uses an App name with a unique identifier to determine the access order based on the access priority according to the access of different Apps; counts the number of accesses within a time window for Apps with the same priority; performs stateful judgment on Apps whose accesses within the time window exceed a threshold; data sharing performs interface adaptation based on the type of accessed data, and realizes unified data access and data sharing between different Apps through the data storage interface. Through the above scheme, when sharing data, it is only necessary to access it according to the interface required by oneself. When the data storage interface changes, it is only necessary to change the shared data access scheme without updating the application App; by counting the number of App accesses according to the time window and adopting a balancing strategy, it is guaranteed that each App has the opportunity to access, and prevents a certain App from blocking data processing due to high-frequency access.

Description

Technical Field

[0001] The present invention relates to the technical field of distribution network automation, and in particular to a working method for shared data access of power system fusion terminals. Background Art

[0002] With the continued development of smart grid technology, especially the large-scale application of new energy, a large amount of intelligent power distribution and utilization data for various business types has emerged in the power grid industry. This data is stored in different ways for different businesses, and existing application layers need to access this collected data. However, existing data centers still have certain drawbacks in terms of universality and convenience in accessing shared data. Traditional data center designs are no longer able to meet the diverse application requirements of converged terminal systems within smart power distribution and utilization networks. Currently, there is a lack of an efficient, convenient, and scalable design for sharing data across converged terminal devices for marketing, distribution, and other new energy sources in power information collection systems.

[0003] Currently, data centers for smart terminals mainly provide different interfaces and storage methods for various businesses. When different types of applications access other types of data, they need to obtain data according to different businesses. In this way, when multiple data are stored in one terminal, one application requires multiple access interfaces to access different types of data. When accessing shared data, there is no limit on the concurrent access volume of a business. During the access process, frequent access by an app may cause other apps to be unable to access it in a timely manner. The traditional data center's access method of different business data separately can no longer meet the shared data access needs of converged terminals. There is still a lack of an efficient, stable and convenient access solution for accessing multiple traditional business data and large data volumes.

[0004] Existing apps access shared data through data access interfaces for different business types. If there are multiple business types, multiple access interfaces need to be designed to access different types of data.

[0005] Currently, accessing different types of data presents the following problems:

[0006] For an application App to access shared data of multiple businesses, it is necessary to develop access interfaces for each business, which is a lot of work. In addition, when the data of each business changes, all related application Apps need to be updated.

[0007] The shared data access interface does not control the number of concurrent accesses. If an application App accesses the data continuously at a high frequency, it will block the access efficiency of other apps and easily cause access timeouts for other apps. Summary of the Invention

[0008] To overcome the deficiencies of the prior art, the present invention mainly provides a method for conveniently accessing shared data of a fusion terminal, aiming to reduce the development workload of shared data for application Apps and ensure reliable and effective access to shared data by multiple application Apps.

[0009] The present invention is implemented through the following technical solutions: A working method for accessing shared data of a power system fusion terminal specifically includes the following steps:

[0010] Step (1): The system for accessing shared data of the power system fusion terminal includes a three-layer architecture, namely, an application presentation layer, a business logic layer, and a data interface layer; external application Apps communicate and send requests in JSON format through the MQTT communication interface; after receiving the message through the mosquitto client in the application presentation layer, the received message and topic are stored in the message synchronization queue, and at the same time, the business logic layer is notified that a message has arrived.

[0011] Step (2): After receiving the message notification, the access control module in the business logic layer retrieves the received message from the message queue; according to the topic format of "sending app name / shared data access name / request category" and whether the message content contains a priority, if there is a priority prm that meets the requirements, prm is retrieved. If prm < PRIOR_LMTLVL, a thread is directly applied to execute data access; if there is no prm or prm ≥ PRIOR_LMTLVL, the sending application app name appName is obtained from the topic. If there is information about this appName in the receiving queue, the received request count recMsgCnt related to this appName is incremented by 1. If not, information about this appName is newly added to the queue and recMsgCnt is set to 1.

[0012] Step (3): If the receiving status of appName is abnormal: recMsgCnt > the specified threshold within the time slip window of TW_LIMIT, an echo message is immediately returned and the busy flag is set; in the case of recMsgCnt ≤ TW_LIMIT, if recMsgCnt > the comprehensive threshold of TW_VALID and the number of external access apps recQueue.size() > 1, a busy message is returned.

[0013] Step (4): The message processing function ProMsg is placed in the task queue of the thread pool, and a thread is applied to the thread pool for execution; when there is an idle thread, the data processing process is directly executed; at this time, the request content is further parsed and checked, the corresponding request parameters are obtained according to the request type, and according to the different data types of the request, the data storage interface to be accessed is confirmed, and the access message is organized according to the corresponding interface.

[0014] Step (5): Send the organized message to the corresponding object through MQTT. After sending the message, wait for the message response within expTime. If the message is received, compare the packet sequence number. If it is equal to the sent packet sequence number, end the waiting; if the packet sequence number is not equal, continue to wait within the specified time.

[0015] Step (6): After receiving the message returned by the data center or storage module, the data content is parsed. If the format is incorrect, a database access failure message is returned to the requesting application APP; if the data format is correct, the data content is parsed and the data is stored in the memory cache; if there is a subsequent frame, the subsequent frame flag is sent to request; if there is no subsequent frame, the data is processed and organized in JSON format;

[0016] Step (7): Convert the format of all accessed data, classify the data according to JSON, and process it according to the type of request; after organizing the data, fill in the same token value, and send a message to the requesting APP through MQTT according to the corresponding response topic.

[0017] Step (8): Perform statistics regularly according to the time specified in the time window.

[0018] As a preferred solution, the external application app in step (1) includes IEC104 and MQTT-IOT.

[0019] As a preferred solution, the organized message in step (5) is sent to the corresponding object via MQTT, including accessing the power distribution data in JSON format and accessing the marketing data in A-XDR format.

[0020] As a preferred solution, in step (7), data classification is performed in JSON format, and processing is performed according to the type of request, including: real-time data is deduplicated, and only one data item is retained; historical data is organized according to time scales.

[0021] As a preferred solution, step (8) specifically includes the following steps: when the time window wndTime arrives, the number of messages received in the time window corresponding to the received APP, recMsgCnt, is counted, and the statistical number wndTimeCnt of the time window is increased by 1; if the time period validity flag wndFlag is invalid, if wndTimeCnt is greater than the number of times in the specified time period MAXWNDTIMECNT, wndFlag is set to be valid; if wndTimeCnt≤MAXWNDTIMECNT, no processing is performed and the next cycle is continued; if wndFlag is valid, the header of the time window statistics queue recQueue is deleted; the number of times the time window is received, recMsgCnt, is placed in the recQueue queue, and recMsgCnt is cleared; the average value of the recQueue queue is counted, and the time period status is corrected.

[0022] Due to the adoption of the above technical solution, the present invention has the following beneficial effects compared with the prior art: through the above solution, when an application app accesses shared data in different businesses, it only needs to access it according to the interface it needs. When the data storage interface changes, only the shared data access scheme needs to be changed, and there is no need to update the application app; by counting the number of app accesses according to the time window and adopting a balancing strategy, it is guaranteed that each app has the opportunity to access, preventing a certain app from blocking data processing due to high-frequency access.

[0023] Additional aspects and advantages of the invention will become apparent from the description which follows, or may be learned by practice of the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments with reference to the accompanying drawings, in which:

[0025] Figure 1 It is a structural schematic diagram of the present invention;

[0026] Figure 2 Request processing flow chart for the application;

[0027] Figure 3 Returns a flow chart for accessing data;

[0028] Figure 4 The following is a flowchart of the access control process. DETAILED DESCRIPTION

[0029] In order to more clearly understand the above-mentioned objects, features and advantages of the present invention, the present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be noted that, in the absence of conflict, the embodiments of the present application and the features therein can be combined with each other.

[0030] In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Therefore, the scope of protection of the present invention is not limited to the specific embodiments disclosed below.

[0031] The following combination Figures 1 to 3 The working method of shared data access by the power system converged terminal according to the embodiment of the present invention is described in detail.

[0032] like Figure 1 、 Figure 2 As shown, the present invention proposes a working method for shared data access of power system fusion terminals, and the principle of the method is: the design of the fusion terminal software shared data framework, and the design of the App access shared data architecture according to business needs, each App is deployed using containerization technology, and accesses the shared data it needs respectively; according to the access of different apps, the app name with a unique identifier is used to determine the access order based on the access priority; the number of accesses within the time window of apps with the same priority is counted; for apps whose access times within the time window exceed the threshold, a stateful judgment is made, and a data access busy status flag is responded to apps in the access restriction state; data sharing performs interface adaptation based on the type of accessed data, and realizes unified data access and data sharing between different apps through the data storage interface.

[0033] The specific steps include:

[0034] Step (1): Overall framework design as follows Figure 1 As shown in the figure, the system for shared data access of power system converged terminals includes a three-layer architecture, namely the application presentation layer, the business logic layer, and the data interface layer. External application apps including IEC104 and MQTT-IOT communicate and send requests in JSON format through the MQTT communication interface. After receiving a message through the mosquitto client, the application presentation layer stores the received message and topic in the message synchronization queue and notifies the business logic layer of the message arrival.

[0035] Step (2): After receiving the message notification, the access control module of the business logic layer takes out the received message from the message queue. The processing flow is as follows: Figure 2As shown in the figure; according to the "send app name / shared data access name / request category" theme format, and whether the message content contains a priority level, if there is a priority level prm that meets the requirements, then extract prm. If prm < PRIOR_LMTLVL, directly apply for a thread to execute data access; if there is no prm or prm ≥ PRIOR_LMTLVL, then obtain the sender application app name appName from the theme. If there is information about this appName in the receive queue, increment the receive request count recMsgCnt related to this appName by 1. If not, add information about this appName to the queue and set recMsgCnt to 1.

[0036] Step (3): If the receive status of appName is abnormal: if recMsgCnt is greater than the specified threshold within the TW_LIMIT time slip window, immediately return a response message and set the busy flag; in the case of recMsgCnt ≤ TW_LIMIT, if recMsgCnt > TW_VALID comprehensive threshold and the number of external access apps recQueue.size() > 1, then return a busy message.

[0037] Step (4): Put the message processing function ProMsg into the task queue of the thread pool and apply to the thread pool for an execution thread; when there is an idle thread, directly execute the data processing process; at this time, further parse and check the request content, obtain the corresponding request parameters according to the request type, confirm the data storage interface to be accessed according to the different data types of the request, and organize the access message according to the corresponding interface.

[0038] Step (5): Send the organized message to the corresponding object through MQTT, including accessing distribution data in JSON format; accessing marketing data in A-XDR format, etc.; after sending the message, wait for a message response within the expTime time. If a message is received, compare the packet sequence numbers. If they are equal to the sent packet sequence number, end the wait; if the packet sequence numbers are not equal, continue to wait within the specified time.

[0039] Step (6): After receiving the message returned by the data center or storage module, the processing flow is as Figure 3 shown. Parse the data content. If the format is incorrect, return a message indicating that the database access of the requesting application APP has failed; if the data format is correct, parse the data content and store the data in the memory buffer; if there is a subsequent frame, continue to send a request for the subsequent frame flag; if there is no subsequent frame, perform data processing and organize the data in JSON format.

[0040] Step (7): Convert the format of all accessed data, classify the data in JSON format, and process it according to the type of request; deduplicate the real-time data and keep only one data item; organize the historical data according to the time scale; after organizing the data, fill in the same token value and send a message to the requesting APP through MQTT according to the corresponding response topic.

[0041] Step (8): Perform statistics regularly according to the time specified in the time window. The processing flow is as follows Figure 4 As shown, when the time window wndTime arrives, the number of messages received in the time window corresponding to the received APP, recMsgCnt, is counted, and the statistical number of the time window, wndTimeCnt, is increased by 1; if the time period validity flag, wndFlag, is invalid, and if wndTimeCnt is greater than the number of times in the specified time period, MAXWNDTIMECNT, wndFlag is set to be valid; if wndTimeCnt≤MAXWNDTIMECNT, no processing is done and the next cycle is continued; if wndFlag is valid, the header of the time window statistics queue, recQueue, is deleted; the number of times the time window is received, recMsgCnt, is placed in the recQueue queue, and recMsgCnt is cleared; the average value of the recQueue queue is counted, and the time period status is corrected.

[0042] In the description of the present invention, the term "plurality" refers to two or more than two. Unless otherwise expressly defined, the orientations or positional relationships indicated by the terms "upper" and "lower" are based on the orientations or positional relationships shown in the accompanying drawings. They are intended only to facilitate the description of the present invention and simplify the description. They do not indicate or imply that the devices or components referred to must have a specific orientation, be constructed and operated in a specific orientation. Therefore, they should not be understood as limitations on the present invention. The terms "connect," "install," and "fix" should be understood in a broad sense. For example, "connection" can mean a fixed connection, a detachable connection, or an integral connection; it can be a direct connection or an indirect connection through an intermediate medium. For those skilled in the art, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0043] Throughout this specification, terms such as "one embodiment," "some embodiments," and "specific embodiments" mean that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of the present invention. In this specification, schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0044] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Those skilled in the art will readily appreciate that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.

Claims

1. A working method for shared data access of power system fusion terminals, characterized in that , specifically including the following steps: Step (1): The system for sharing data access of the power system integration terminal includes a three-layer architecture, namely the application presentation layer, the business logic layer, and the data interface layer in sequence; the external application app communicates and sends requests in JSON format through the MQTT communication interface; after receiving the message through the mosquitto client, the application presentation layer stores the received message and topic in the message synchronization queue, and at the same time notifies the business logic layer that a message has arrived; Step (2): After receiving the message notification, the access control module of the business logic layer retrieves the received message from the message synchronization queue; according to the "sender app name / share data access name / request category" topic format and whether the message content contains a priority, if there is a priority prm that meets the requirements, prm is retrieved. If prm < PRIOR_LMTLVL, a thread is directly applied to execute data access; if there is no prm or prm ≥ PRIOR_LMTLVL, the sender application app name appName is obtained from the topic. If there is information about this appName in the receive queue, the receive request count recMsgCnt related to this appName is incremented by 1. If not, the appName information is newly added to the queue and recMsgCnt is set to 1; Step (3): If the receive status of appName is abnormal: if recMsgCnt > the specified threshold within the time slip window of TW_LIMIT, an echo message is immediately returned and the busy flag is set; in the case of recMsgCnt ≤ TW_LIMIT, if recMsgCnt > the comprehensive threshold of TW_VALID and the number of external access apps recQueue.size() > 1, a busy message is returned; Step (4): The message processing function ProMsg is placed in the task queue of the thread pool, and a thread is applied to the thread pool for execution; when there is an idle thread, the data processing process is directly executed; at this time, the request content is further parsed and checked, the corresponding request parameters are obtained according to the request type, and according to the different data types of the request, the data storage interface to be accessed is confirmed, and the access message is organized according to the corresponding interface; Step (5): The organized message is sent to the corresponding object through MQTT. After sending the message, wait for the message response at the expTime. If the received message is compared with the packet sequence number and is equal to the sent packet sequence number, end the wait; if the packet sequence numbers are not equal, continue to wait within the specified time; Step (6): After receiving the message returned by the data center or storage module, the data content is parsed. If the format is incorrect, a database access failure message is returned to the requesting application APP; if the data format is correct, the data content is parsed and the data is stored in the memory buffer; if there is a subsequent frame, continue to send the request for the subsequent frame flag; if there is no subsequent frame, data processing is performed and the data is organized in JSON format; Step (7): Convert all accessed data into different formats, classify the data in JSON format, and process them according to the type of request. After organizing the data, fill in the same token value and send a message to the requesting APP through MQTT according to the corresponding response topic. Step (8): Perform statistics regularly according to the time specified in the time window.

2. A method for shared data access by power system fusion terminals according to claim 1, characterized in that ,The ,organized message in the step (5) is sent to the corresponding object via MQTT, ,including accessing the power distribution data in JSON format and accessing the ,marketing data in A-XDR format.

3. A method for shared data access by power system fusion terminals according to claim 1, characterized in that ,In the step (7), data is classified in JSON format and processed according to the ,type of request, including: deduplication of real-time data, leaving only one data ,for one data item; historical data is organized according to time ,marks.

4. A method for shared data access by power system fusion terminals according to claim 1, characterized in that , the step (8) specifically includes the following steps: when the time sliding window wndTime arrives, the number of received requests recMsgCnt in the time window corresponding to the APP received is counted, and the statistical number wndTimeCnt of the time sliding window is increased by 1; if the time period validity flag wndFlag is invalid, if wndTimeCnt is greater than the number of times in the specified time period MAXWNDTIMECNT, wndFlag is set to be valid; if wndTimeCnt≤MAXWNDTIMECNT, no processing is done and the next cycle is continued; if wndFlag is valid, the header of the time window statistics queue recQueue is deleted; the number of times the time window is received recMsgCnt is placed in the recQueue queue, and recMsgCnt is cleared to zero; the average value of the recQueue queue is counted, and the time period status is corrected.

Images