A method for testing the function of an energy meter based on multi-protocol identification and self-testing
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-05-09
- Publication Date
- 2026-08-14
AI Technical Summary
[0006]本发明的目的是针对目前电能表检测存在的问题,提出一种基于多协议辨识和自测试的电能表功能检测方法
[0044]本发明通过测试中上位机的数据请求帧以及电能表的应答帧,正确识别当前数据请求帧以及应答帧所属的通讯规约并提取数据帧中特征信息。
Smart Images

Figure CN115525535B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of electricity meter function testing, specifically relating to an electricity meter function testing method based on multi-protocol identification and self-testing. Background Technology
[0002] Currently, smart meters require functional testing before sampling and mass production. Common methods for testing the function of smart meters mainly include: (1) manual testing, which involves manually setting up various input quantities to determine whether the output behavior of the smart meter meets the technical requirements. (2) automated test bench functional testing, which involves setting up an automated test scheme for the smart meter function, controlling the power source of the test bench and sending out specified data request frames, and waiting for the response behavior of the smart meter. If the response behavior of the smart meter meets the preset rule requirements, the current functional test is considered qualified; otherwise, the current functional test is considered unqualified.
[0003] However, these functional testing methods all have their own problems:
[0004] (1) Manual testing is inefficient and has a long testing cycle. In the early and middle stages of software development, the code is constantly changing, which means that manual testing can only test individual functional blocks. Overall system testing is mainly concentrated in the later stages of software development, resulting in insufficient testing and increased difficulty in finding software bugs.
[0005] (2) Automated platform function testing can improve the efficiency of testing behavior to a certain extent, but it is not satisfactory in terms of the coverage of test requirements, such as program boundaries, branches, and path execution. Summary of the Invention
[0006] The purpose of this invention is to address the problems existing in current electricity meter testing by proposing a method for testing electricity meter functions based on multi-protocol identification and self-testing. This invention correctly identifies the communication protocol to which the current data request frame and response frame belong and extracts feature information from the data frames by testing the data request frame from the host computer and the response frame from the electricity meter. Simultaneously, it establishes a reference test database and a manual test database, generates test cases based on feature values, and improves the coverage and efficiency of electricity meter function testing by calculating the test contribution and path coverage of the test cases.
[0007] The technical solution of this invention is:
[0008] This invention provides a method for detecting the function of an energy meter based on multi-protocol identification and self-testing, comprising:
[0009] S1. Establish a reference test database and a manual test database, and store test cases in the corresponding databases;
[0010] S2. Identify the protocol type to which the data frame belongs from the message data of the test process, and extract the frame feature information, including the mileage marker offset information ofsMS and feature information feaInfo.
[0011] S3. Convert the frame feature information into a string of Chinese characters, numbers and letters and restore the original data frame;
[0012] S4. Identify the corresponding test cases based on the original data frame information and perform the tests.
[0013] Furthermore, in S2, the specific protocol type for identifying the data frame's origin is as follows:
[0014] A multi-protocol filtering analyzer is used to match the data frame format of the corresponding protocol with the frame header of the currently received message data, the milestone information in the corresponding protocol, and the milestone offset ofsMS.
[0015] ofsMS k+1 =PROT i (CurMS k ), (i = 0, 1, ..., m and k = 1, ..., n)
[0016] PROT i For the i-th protocol type, CurMS k This represents the current milestone node, where m is the total number of currently supported protocols, n is the total number of milestones, and ofsMS is the endpoint. k+1 Offset for the next milestone.
[0017] Furthermore, in S2, a multi-protocol filtering analyzer (profilter) is configured for all currently supported protocols, and the following operations are performed respectively:
[0018] The data structure is initialized by dividing the protocol content into corresponding milestones according to the protocol type protType. The protocol content includes the frame header start character, frame data length, communication address, control code, data identifier, data unit, frame check character, and frame tail end character.
[0019] Parse the message data and check whether the data pointed to by the data frame header pointer ptrStart matches the initial mileage marker of the current protocol. If it does not match, move the frame header pointer to the next data until a matching initial mileage marker is found.
[0020] The pointer is moved to the data after the frame header, and the offset ofsAnaly between the data and the frame header is obtained. The offset ofsAnaly is compared with the offset ofsMS of the next milestone of the protocol relative to the frame header. If they do not match, the pointer is moved to the next data and the offset ofsAnaly is incremented by 1. This process continues until an offset ofsAnaly matches the previous offset ofsMS. The first milestone is recorded, and so on. If the message data matches all the milestone offsets ofsMS of the protocol, then the message data belongs to the current protocol type.
[0021] Furthermore, the frame feature information extracted in S2 includes: mileage marker offset information ofsMS and feature information feaInfo. The feature information feaInfo is obtained as follows:
[0022] Based on the CurMS of each mile marker node in the identified protocol type, the mile marker offset ofsMS, and the position pos of the feature information in the mile marker node, the specific content of the feature information feaInfo is derived:
[0023]
[0024] Where: pos is the node number of the milestone corresponding to the xth feature information, frame is the content of a valid data frame, and ofsMS pos and ofsMS pos+1 q represents the offsets of the x-th and x+1-th feature information, respectively, and q is the total number of feature information contained in the current protocol.
[0025] Furthermore, the transformation of frame feature information in S3 is specifically as follows:
[0026] Based on the message data, obtain the control code ctrlReq in the data request frame and the control code ctrRes in the response frame, and extract the frame settings or read the content;
[0027] If the response control code ctrRes is an abnormal response for the recognized protocol, then abandon setting or extracting the content of this frame.
[0028] If the response control code ctrRes is a normal response of the recognized protocol and the control code ctrlReq in the corresponding data request frame is set, then the set content in the data request frame is extracted; if the response control code ctrRes is a normal response of a certain protocol and the control code ctrlReq in the corresponding data request frame is read, then the read content in the data response frame is extracted and denoted as the string information strInfo.
[0029] Furthermore, the frame feature information transformation also includes:
[0030] The frame feature information, namely the mileage marker offset information ofsMS and the feature information feaInfo, is mapped to the string information strInfo to obtain the string mapping table strMapTable[]. This enables the conversion of frame feature information conforming to the protocol into string information consisting of Chinese characters, letters, and numbers.
[0031] The data request and response frames are reconstructed using the feature information feaInfo, the mileage marker offset information ofsMS, and the protocol rules protRules.
[0032] Furthermore, the manual test database includes experienced test cases and random test cases. The steps for generating and updating random test cases are as follows:
[0033] When the mileage marker offset information ofsMS includes preset functional keywords, a preset set of input parameter variables and a set of output parameter variables are generated based on the aforementioned preset functional keywords; the sets of input and output parameter variables are obtained according to preset feature parameters and according to the change amount and threshold of the feature parameters;
[0034] Based on the set of input and output parameter variables, obtain a set of random test cases (OP) corresponding to a specific function, and update the manual test database.
[0035] OP = Fun(OP) input OP output )[OP pre OP post [rules]
[0036] Wherein: OP input It is the collection of all input parameter variables, OP output It is the collection of all output parameter variables, OP pre and OP post These are the preconditions and postconditions of the operation, respectively, and rules is the set of rules for the test cases.
[0037] Furthermore, the functions to be tested in the electricity meter include several test schemes, and each test scheme includes several test cases. The test contribution of similar test cases is calculated using the following formula:
[0038]
[0039] Where: j represents the test case number, t represents the test plan number; numT represents the total number of test plans included in the corresponding test function, NUM_OP t Hope represents the total number of test cases contained in the t-th test plan. jt This represents the total number of test cases for the j-th test case included in the t-th test plan.
[0040] Furthermore, the test cases include several test paths, and the coverage of the test paths is calculated using the following formula:
[0041]
[0042] Where: N t D represents the total number of test paths contained in the t-th test plan. t This represents the number of paths that have been tested in the t-th test plan.
[0043] The beneficial effects of this invention are:
[0044] This invention correctly identifies the communication protocol to which the current data request frame and response frame belong and extracts feature information from the data frame by testing the data request frame of the host computer and the response frame of the energy meter.
[0045] This invention establishes a reference test database and a manual test database, generates test cases based on feature values, and helps users understand the coverage and testing efficiency of the electricity meter's functional testing by calculating the test contribution and path coverage of the test cases. This allows users to adjust their plans more easily and reduces the involvement of testers in the entire testing process.
[0046] The manual test database of this invention includes experienced test cases and random test cases. By monitoring the test process, it can identify functional keywords and generate feature-based random test cases, which can effectively improve the detection coverage of the data value range.
[0047] Other features and advantages of the present invention will be described in detail in the following detailed description section. Attached Figure Description
[0048] The above and other objects, features and advantages of the present invention will become more apparent from the more detailed description of exemplary embodiments of the invention in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments of the invention.
[0049] Figure 1 This is a flowchart of a method for detecting the function of an energy meter based on multi-protocol identification and self-test according to an embodiment of the present invention.
[0050] Figure 2 This is a flowchart of multi-protocol identification and frame feature information extraction according to an embodiment of the present invention.
[0051] Figure 3 This is a flowchart illustrating the establishment of a reference test database and a manual test database in an embodiment of the present invention.
[0052] Figure 4This is a flowchart illustrating the generation of random test cases based on feature values according to an embodiment of the present invention.
[0053] Figure 5 This is a flowchart illustrating the generation of test cases based on the path contribution algorithm in an embodiment of the present invention. Detailed Implementation
[0054] Preferred embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While preferred embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.
[0055] This invention provides a method for detecting the function of an energy meter based on multi-protocol identification and self-testing, comprising:
[0056] S1. Establish a reference test database and a manual test database, and store test cases in the corresponding databases;
[0057] S2. Identify the protocol type to which the data frame belongs from the message data of the test process, and extract the frame feature information, including the mileage marker offset information ofsMS and feature information feaInfo.
[0058] In S2, the specific protocol type for identifying the data frame's origin is as follows:
[0059] A multi-protocol filtering analyzer is used to match the data frame format of the corresponding protocol with the frame header of the currently received message data, the milestone information in the corresponding protocol, and the milestone offset ofsMS.
[0060] ofsMS k+1 =PROT i (CurMS k ), (i = 0, 1, ..., m and k = 1, ..., n)
[0061] PROT i For the i-th protocol type, CurMS k This represents the current milestone node, where m is the total number of currently supported protocols, n is the total number of milestones, and ofsMS is the endpoint. k+1 Offset for the next milestone.
[0062] Configure the multi-protocol filtering analyzer profilter for all currently supported protocols, and perform the following operations respectively: Figure 2 As shown:
[0063] The data structure is initialized by dividing the protocol content into corresponding milestones according to the protocol type protType. The protocol content includes the frame header start character, frame data length, communication address, control code, data identifier, data unit, frame check character, and frame tail end character.
[0064] Parse the message data and check whether the data pointed to by the data frame header pointer ptrStart matches the initial mileage marker of the current protocol. If it does not match, move the frame header pointer to the next data until a matching initial mileage marker is found.
[0065] The pointer is moved to the data after the frame header, and the offset ofsAnaly between the data and the frame header is obtained. The offset ofsAnaly is compared with the offset ofsMS of the next milestone of the protocol relative to the frame header. If they do not match, the pointer is moved to the next data and the offset ofsAnaly is incremented by 1. This process continues until an offset ofsAnaly matches the previous offset ofsMS. The first milestone is recorded, and so on. If the message data matches all the milestone offsets ofsMS of the protocol, then the message data belongs to the current protocol type.
[0066] S3. Convert the frame feature information into a string of Chinese characters, numbers, and letters, and restore the original data frame. Specifically, the frame feature information conversion in S3 is as follows:
[0067] Based on the message data, obtain the control code ctrlReq in the data request frame and the control code ctrRes in the response frame, and extract the frame settings or read the content;
[0068] If the response control code ctrRes is an abnormal response for the recognized protocol, then abandon setting or extracting the content of this frame.
[0069] If the response control code ctrRes is a normal response of the recognized protocol and the control code ctrlReq in the corresponding data request frame is set, then the set content in the data request frame is extracted; if the response control code ctrRes is a normal response of a certain protocol and the control code ctrlReq in the corresponding data request frame is read, then the read content in the data response frame is extracted and denoted as the string information strInfo.
[0070] The frame feature information conversion also includes:
[0071] The frame feature information, namely the mileage marker offset information ofsMS and the feature information feaInfo, is mapped to the string information strInfo to obtain the string mapping table strMapTable[]. This enables the conversion of frame feature information conforming to the protocol into string information consisting of Chinese characters, letters, and numbers.
[0072] The data request and response frames are reconstructed using the feature information feaInfo, the mileage marker offset information ofsMS, and the protocol rules protRules.
[0073] S4. Identify the corresponding test cases based on the original data frame information and perform the tests.
[0074] Furthermore, the frame feature information extracted in S2 includes: mileage marker offset information ofsMS and feature information feaInfo. The feature information feaInfo is obtained as follows:
[0075] Based on the CurMS of each mile marker node in the identified protocol type, the mile marker offset ofsMS, and the position pos of the feature information in the mile marker node, the specific content of the feature information feaInfo is derived:
[0076]
[0077] Where: pos is the node number of the milestone corresponding to the xth feature information, frame is the content of a valid data frame, and ofsMS pos and ofsMS pos+1 q represents the offsets of the x-th and x+1-th feature information, respectively, and q is the total number of feature information contained in the current protocol.
[0078] Furthermore, the manual test database includes both experienced test cases and randomized test cases, such as... Figure 4 As shown, the steps for generating and updating random test cases are as follows:
[0079] When the mileage marker offset information ofsMS includes preset functional keywords, a preset set of input parameter variables and a set of output parameter variables are generated based on the aforementioned preset functional keywords; the sets of input and output parameter variables are obtained according to preset feature parameters and according to the change amount and threshold of the feature parameters;
[0080] Based on the set of input and output parameter variables, obtain a set of random test cases (OP) corresponding to a specific function, and update the manual test database.
[0081] OP = Fun(OP) input OP output )[OP pre OP post [rules]
[0082] Wherein: OP input It is the collection of all input parameter variables, OP output It is the collection of all output parameter variables, OP pre and OP postThese are the preconditions and postconditions of the operation, respectively, and rules is the set of rules for the test cases.
[0083] Furthermore, the functions to be tested in the electricity meter include several test schemes, and each test scheme includes several test cases. The test contribution of similar test cases is calculated using the following formula:
[0084]
[0085] Where: j represents the test case number, t represents the test plan number; numT represents the total number of test plans included in the corresponding test function, NUM_OP t Hope represents the total number of test cases contained in the t-th test plan. jt This represents the total number of test cases for the j-th test case included in the t-th test plan.
[0086] Furthermore, the test cases include several test paths, and the coverage of the test paths is calculated using the following formula:
[0087]
[0088] Where: N t D represents the total number of test paths contained in the t-th test plan. t This represents the number of paths that have been tested in the t-th test plan.
[0089] In practice:
[0090] Figure 2 The process for multi-protocol identification and content extraction in this embodiment is as follows: (1) Initialize the data structure members of the multi-protocol filter; (2) Determine whether the data unit pointed to by the frame header pointer satisfies the initial milestone. If not, the frame header pointer is moved to the next data unit, and (2) is repeated; if satisfied, execution continues downward; (3) Increment the offset of the analyzed frame by 1, and predict the offset of the next milestone relative to the frame header based on the current milestone; (4) Determine whether the offset of the analyzed frame is equal to the offset of the next milestone relative to the frame header. If not, the offset of the analyzed frame is incremented by 1, and (4) is repeated; if equal, the pointer is moved to the next milestone, and the offset of the analyzed frame is incremented by 1; (5) Determine whether the currently analyzed data is an end marker. If not, the pointer is moved to (4); if it is an end marker, a data frame conforming to a certain protocol is found, and the frame feature information and data content are recorded.
[0091] Figure 3This is a flowchart of establishing a reference test database and a manual test database in an embodiment of the present invention. The specific steps are as follows: (1) Determine whether the current test case belongs to the reference test database. If yes, then execute (2); if not, then execute (3); (2) Monitor the platform control source information, host computer data request frames and meter response frames in the reference test cases; record the string mapping table strMapTable1; add it to the reference operation mapping table MapTable. RefAction (3) Monitor the platform control source information, host computer data request frames, and meter response frames in the manual test cases; record the string mapping table strMapTable2; add it to the manual operation mapping table ActionMapTable. Manual .
[0092] Figure 4 The random test case generation process of this embodiment is as follows: (1) Initialize the value range, step size and complete operation steps of the corresponding functional parameters; (2) Generate random values of each parameter based on the features; (3) If the combination of parameters already exists in the test case, repeat (2); otherwise, generate a new random test case; (4) If the test result meets the decision test rules, the current function is deemed qualified; if the test result does not meet the decision test rules, the function is deemed unqualified and a software error is found.
[0093] Figure 5 The specific steps of the path contribution-based test case generation process in this embodiment are as follows: calculate the contribution of the test case and the path coverage; when the contribution of a certain type of test case is less than a set threshold, increase the number of times the test case is executed.
[0094] The various embodiments of the present invention have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments.
Claims
1. A method for detecting the function of an electricity meter based on multi-protocol identification and self-testing, characterized in that, include: S1. Establish a reference test database and a manual test database, and store test cases in the corresponding databases; S2. Identify the protocol type to which the data frame belongs from the message data of the test process, and extract the frame feature information, which includes milestone offset information and feature information feaInfo. S3. Convert the frame feature information into a string of Chinese characters, numbers and letters and restore the original data frame; S4. Identify the corresponding test cases based on the original data frame information and perform the tests; In S2, the specific protocol type for identifying the data frame's origin is as follows: A multi-protocol filtering analyzer is used to match the data frame format of the corresponding protocol with the frame header of the currently received message data, the milestone information in the corresponding protocol, and the milestone offset information. (i=0,1,...,m and k=1,...,n) PROT i For the i-th protocol type, CurMS k This is the current milestone node, where m is the total number of currently supported protocols, n is the total number of milestones, and ofsMS is the endpoint. k+1 Offset for the next milestone; The feature information feaInfo is obtained in the following ways: Based on the identified milestone nodes, milestone offsets, and the position (pos) of the feature information within the milestone nodes in the identified protocol types, the specific content of the feature information feaInfo is derived: ,(x=1,2,...,q) Where: pos is the node number of the milestone corresponding to the xth feature information, frame is the content of a valid data frame, and ofsMS pos and ofsMS pos+1 , respectively, are the offsets of the x-th and x+1-th feature information, and q is the total number of feature information contained in the current protocol; In S2, configure the multi-protocol filtering analyzer profilter for all currently supported protocols, and perform the following operations respectively: The data structure is initialized by dividing the protocol content into corresponding milestones according to the protocol type protType. The protocol content includes the frame header start character, frame data length, communication address, control code, data identifier, data unit, frame check character, and frame tail end character. Parse the message data and check whether the data pointed to by the data frame header pointer ptrStart matches the initial milestone of the current protocol. If it does not match, move the frame header pointer to the next data until a matching initial milestone is found. Point the pointer to the data after the frame header, obtain the offset ofsAnaly between the data and the frame header, and compare the offset ofsAnaly with the offset ofsMS of the next milestone of the protocol relative to the frame header. If they do not match, point the pointer to the next data and increment the offset ofsAnaly by 1, until an offset ofsAnaly matches the previous offset ofsMS. Record the first milestone, and so on. If the message data matches all the milestone offsets of the protocol, then the message data is of the current protocol type.
2. The method for detecting the function of an energy meter based on multi-protocol identification and self-test according to claim 1, characterized in that, In S3, the frame feature information transformation is specifically as follows: Based on the message data, obtain the control code ctrlReq in the data request frame and the control code ctrRes in the response frame, and extract the settings or read content in the frame; If the response control code ctrRes is an abnormal response for the recognized protocol, then abandon setting or extracting the content of this frame. If the response control code ctrRes is a normal response of the recognized protocol and the control code ctrlReq in the corresponding data request frame is set, then the set content in the data request frame is extracted; if the response control code ctrRes is a normal response of a certain protocol and the control code ctrlReq in the corresponding data request frame is read, then the read content in the data response frame is extracted and denoted as the string information strInfo.
3. The method for detecting the function of an energy meter based on multi-protocol identification and self-test according to claim 2, characterized in that, The frame feature information conversion also includes: Establish a mapping relationship between frame feature information and string information strInfo to obtain string mapping table strMapTable[], thereby converting frame feature information that conforms to the protocol into string information consisting of Chinese characters, letters and numbers; Data request and response frames can be reconstructed using feature information feaInfo, milestone offset information, and protocol rules protRules.
4. The method for detecting the function of an energy meter based on multi-protocol identification and self-test according to claim 1, characterized in that, The manual test database includes experienced test cases and random test cases. The steps for generating and updating random test cases are as follows: When the milestone offset information includes preset functional keywords, a preset set of input parameter variables and a set of output parameter variables are generated based on the aforementioned preset functional keywords; the sets of input and output parameter variables are sets obtained according to preset feature parameters and according to the change amount and threshold of feature parameters; Based on the set of input and output parameter variables, obtain a set of random test cases (OP) corresponding to a specific function, and update the manual test database. OP=Fun(OP input ,ON output )[ON pre ,ON post rules] Wherein: OP input It is the collection of all input parameter variables, OP output It is the collection of all output parameter variables, OP pre and OP post These are the preconditions and postconditions for the operation, respectively, and rules is the set of rules for the test cases.
5. The method for detecting the function of an energy meter based on multi-protocol identification and self-test according to claim 4, characterized in that, The functions to be tested in the electricity meter include several test schemes, and each test scheme includes several test cases. The test contribution of similar test cases is calculated using the following formula: ; Where: j represents the test case number, t represents the test plan number; numT represents the total number of test plans included in the corresponding test function, NUM_OP t Hope represents the total number of test cases contained in the t-th test plan. jt This represents the total number of test cases for the j-th test case included in the t-th test plan.
6. The method for detecting the function of an energy meter based on multi-protocol identification and self-test according to claim 5, characterized in that, The test cases include several test paths, and the coverage of the test paths is calculated using the following formula: ; in: This represents the total number of test paths included in the t-th test plan. This represents the number of paths that have been tested in the t-th test plan.
Citation Information
Patent Citations
Industrial control protocol fuzzy test case generation method based on flow tracing
CN110401581A