Debugging system, debugging equipment and debugging method for intelligent electric meter

Abstract

The invention discloses a debugging system, debugging equipment and a debugging method of an intelligent electric meter, belongs to the technical field of CAN communication, and particularly relates to the technical field of CAN communication. The debugging system comprises: a window component configured with an interactive window to receive operation and display information; the hardware driving assembly comprises a CAN universal driving model, and the CAN universal driving model adopts an object-oriented architecture to provide a unified programming interface for different types of CAN interfaces, so that interaction between the programming interface and each CAN interface is realized, and each CAN interface is driven to communicate; the protocol program component responds to the operation to call the programming interface and generates information based on the feedback of the programming interface; wherein the CAN interface is used for connecting an intelligent electric meter. The debugging system based on the CAN protocol can replace traditional serial port debugging to debug the intelligent electric meter, and under the condition that the intelligent electric meter is connected to a power grid system, debugging of the intelligent electric meter is abnormal, and flexibility is high.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of smart meters, and particularly relates to a debugging system, a debugging device and a debugging method for a smart meter. BACKGROUND

[0002] CAN communication (Controller Area Network) is a serial communication protocol widely used in the fields of automobile electronics and industrial control, and has high reliability and real-time performance. Under the condition of CAN communication hardware, devices are connected through a CAN bus and communicate based on the CAN bus.

[0003] Power line communication (PLC) is a technology that uses existing power lines (power transmission lines or distribution lines) as a transmission medium to perform data communication while transmitting electric energy. Since no additional communication lines need to be laid, a large amount of wiring cost is saved, and the technology has a wide range of applications.

[0004] The smart meter integrates the two communication modes described above, communicates with collectors or data centers through power line communication, and also communicates with various devices through the CAN bus. Currently, the debugging of the smart meter is mostly performed before the smart meter is connected to the power grid system, and after the smart meter is connected to the power grid, the smart meter can only be connected to a single debugging device, which makes the debugging process complex, inefficient, and affects the operation of the power grid system. SUMMARY

[0005] The present application aims to at least solve one of the technical problems existing in the prior art. To this end, the present application provides a debugging system, a debugging device and a debugging method for a smart meter. The debugging system based on the CAN protocol can replace the traditional serial port debugging to debug the smart meter, and can debug and capture exceptions of the smart meter when the smart meter is connected to the power grid system, and has high flexibility.

[0006] In a first aspect, the present application provides a debugging system for a smart meter, comprising:

[0007] a window component configured with an interactive window to receive operations and display information;

[0008] a hardware driver component including a CAN universal driver model, the CAN universal driver model providing a unified programming interface for different types of CAN interfaces using an object-oriented architecture, realizing the interaction between the programming interface and each CAN interface, and driving each CAN interface to communicate;

[0009] a protocol program component that calls the programming interface in response to operations and generates information based on the feedback of the programming interface;

[0010] The CAN interface is used for connecting the smart meter.

[0011] According to some embodiments of the present application, the CAN universal driving model comprises:

[0012] A device management unit is configured to select a brand and / or a model of the CAN interface, extract CAN interface information, and enable, disable, and set working parameters of a communication channel;

[0013] A parameter configuration unit is configured to select a CAN protocol and a CANFD protocol and configure communication parameters;

[0014] The communication parameters include a frame format, a communication rate, a communication mode, a transmission module, and enabling / disabling of specific hardware, and the frame format includes a CAN protocol format, a CANFD protocol format, a standard ID, an extended ID, a data frame, and a remote frame.

[0015] According to some embodiments of the present application, the protocol program component comprises a message transmission unit, which comprises:

[0016] A data editing unit is configured to generate message data in response to a message editing operation;

[0017] A verification unit is integrated with cyclic redundancy check calculation units and checksum calculation units of multiple lengths, and is configured to call corresponding calculation units to verify the message data;

[0018] A first sending unit is configured to generate a message based on the message data and the verification result, and call a programming interface to send the message.

[0019] According to some embodiments of the present application, the protocol program component further comprises a log sender, which comprises:

[0020] A log analysis unit is configured to extract target information in a log file based on a configured field index rule;

[0021] A second sending unit is configured to generate a message list based on the target information, and call a programming interface to send each message in the message list.

[0022] According to some embodiments of the present application, the protocol program component further comprises:

[0023] A data diagnosis unit is configured to analyze CAN data fed back by the programming interface according to a configured diagnosis rule, to determine state information of a corresponding smart meter;

[0024] A protocol conversion unit is configured to convert the CAN data between a CAN protocol format and a CANFD protocol format;

[0025] According to some embodiments of the present application, the window component comprises:

[0026] a main window unit configured with interactive controls responsive to CAN interface debugging operations;

[0027] an auxiliary window unit for displaying at least one of the following units in response to a triggering operation:

[0028] a message display unit for displaying original CAN messages and corresponding interpreted text data;

[0029] an export unit for exporting the original CAN messages and the interpreted text data as a text file;

[0030] a message statistics unit for displaying real-time statistics of CAN communication, the real-time statistics including frame count and byte count.

[0031] According to some embodiments of the present application, the message display unit comprises:

[0032] a string conversion unit for converting the original CAN messages into readable text strings;

[0033] a filtering unit for filtering the original CAN messages and / or the text strings to be displayed based on configured filtering rules, the filtering rules including ID mask filtering, channel filtering, character filtering and communication direction filtering;

[0034] a buffer unit including a message list and a timer, the message list being configured to receive the information to be displayed, and the timer being configured to asynchronously update the information to be displayed to a display interface.

[0035] According to some embodiments of the present application, the string conversion unit comprises:

[0036] a format conversion unit for formatting each field of the original CAN messages into readable text strings using a QString class and a format function;

[0037] a data conversion unit for converting binary data and / or data bytes of the original CAN messages into hexadecimal data;

[0038] a log conversion unit for converting a BLF format log file into a formatted text string.

[0039] In a second aspect, the present application provides a debugging device configured with the debugging system of the smart meter according to the foregoing.

[0040] In a third aspect, the present application provides a debugging method of a smart meter, applied to the debugging device according to the foregoing, the debugging device being connected to the smart meter to be debugged through a CAN interface, the debugging method comprising:

[0041] The debugging system selects the hardware information of the CAN interface when debugging the device;

[0042] The CAN communication parameters are configured;

[0043] The debugging system is started to communicate with the smart meter to be debugged through the CAN interface.

[0044] The debugging system, the debugging device and the debugging method of the smart meter according to the present application realize the interaction with different types of CAN interfaces based on the CAN protocol, can replace the traditional serial debugging tool to debug the smart meter, and can debug, check and diagnose the smart meter when the smart meter is connected to the power grid system, and has high flexibility.

[0045] Additional aspects and advantages of the present application will be in part apparent and in part pointed out hereinafter. BRIEF DESCRIPTION OF DRAWINGS

[0046] The above and / or additional aspects and advantages of the present application will become apparent and be readily understood from the following description, taken in conjunction with the accompanying drawings, in which:

[0047] Figure 1 is a schematic diagram of the hardware structure of the debugging device provided by the embodiments of the present application;

[0048] Figure 2 is a schematic diagram of the hierarchical structure of the debugging system provided by the embodiments of the present application;

[0049] Figure 3 is a schematic diagram of the hierarchical structure of the hardware driver component provided by the embodiments of the present application;

[0050] Figure 4 is a schematic diagram of the hierarchical structure of the protocol program component provided by the embodiments of the present application;

[0051] Figure 5 is a schematic diagram of the hierarchical structure of the window component provided by the embodiments of the present application;

[0052] Figure 6 is a schematic diagram of the flow of the debugging method of the smart meter provided by the embodiments of the present application.

[0053] Reference Signs:

[0054] Debugging device 100, processing unit 110, memory 120, input unit 130, display unit 140, communication unit 150, window component 10, main window unit 11, auxiliary window unit 12, message display unit 121, export unit 122, message statistics unit 123, hardware driver component 20, CAN general driver model 21, device management unit 211, parameter configuration unit 212, TCP / UDP driver unit 22, protocol program component 30, message transmission unit 31, log sender 32, data diagnosis unit 33, protocol conversion unit 34. DETAILED DESCRIPTION

[0055] The technical solutions in the embodiments of the present application will be clearly described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art belong to the scope of protection of the present application.

[0056] The terms "first", "second", and the like in the specification and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described herein, and the objects distinguished by "first", "second", etc. are generally a category, and are not limited to the number of objects, for example, the first object can be one or more. In addition, "and / or" in the specification and claims means at least one of the connected objects, and the character " / ", generally indicates that the front and rear associated objects are in an "or" relationship.

[0057] It should be noted that in this paper, the term "include", "contain" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or includes elements inherent to such process, method, article or device. Without more limitations, the element defined by the sentence "includes a…" does not exclude the presence of another identical element in the process, method, article or device including the element. In addition, it should be pointed out that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, but can also include performing functions in a substantially simultaneous manner or in reverse order according to the functions involved, for example, the described method can be performed in an order different from the described order, and various steps can also be added, omitted or combined. In addition, the features described with reference to certain examples can be combined in other examples.

[0058] CAN communication is mainly used for serial communication in the field of vehicle-mounted, and has the advantages of strong anti-interference ability and support for distributed communication. Usually two CAN devices are connected through a CAN bus, and the CAN bus uses differential signal transmission and arbitration mechanism, so it can also communicate reliably in harsh electrical environments. CAN bus can also connect multiple CAN devices, which supports multiple nodes to communicate on the same bus and build a distributed network. This makes the CAN bus very suitable for applications such as automotive electronics and industrial control that require multiple device interconnection.

[0059] Currently, CAN communication is also widely used in various industries, such as automotive electronics charging piles, etc. Such charging equipment mostly integrates multiple communication methods, such as CAN communication and carrier wave communication, etc. However, the debugging of CAN is mostly made by serial protocol. Only some CAN hardware manufacturers have debugging tools specifically for their own CAN devices, or some CAN debugging tools are only for UDS diagnostic functions related to automobiles. The current debugging methods and tools are basically made by serial (Serial Ports / UDP / TCP) protocol, such as SSCOM, MobaXterm tools.

[0060] Serial communication protocol is relatively simple, so serial tools are usually more intuitive and easy to operate. Many operating systems come with serial debugging programs, or there are a large number of free or simple third-party serial tools. The hardware interface of serial communication (such as RS-232, RS-485, TTL) and the corresponding tools are usually less expensive than the hardware and tools of CAN bus. Serial ports are still widely used in various embedded systems, industrial devices and traditional instruments. Therefore, the scope of application of serial tools is also very wide. For point-to-point simple communication, serial debugging is usually easier than CAN bus involving complex network topology and arbitration mechanism.

[0061] But compared with CAN communication, serial also has the short board of limited high-speed data transmission capacity, limited transmission distance and easy to be disturbed by noise. Serial connection is usually a direct single-wire or several-wire connection, which has limitations in high-speed data transmission. Compared with CAN bus, serial may not be able to meet the needs of high-bandwidth applications. The connection of serial is relatively simple and direct, without complex network topology structure, and serial will encounter problems such as signal attenuation in long-distance communication, and the transmission distance is limited. The slow serial communication is easy to be affected by noise such as electromagnetic interference on the transmission line, resulting in data transmission errors.

[0062] The smart meter integrates power carrier communication and CAN communication, communicates with the collector or data center through power carrier communication, and can also communicate with various devices through the CAN bus. Currently, the debugging of the smart meter is mostly performed before the smart meter is connected to the power grid system, and after the smart meter is connected to the power grid system, the smart meter can only be connected to a single debugging device for debugging, which makes the debugging process complex, low in efficiency, and affects the operation of the power grid system.

[0063] Therefore, the application provides a debugging system, a debugging device and a debugging method for a smart meter, which are based on the CAN protocol to realize interaction with different types of CAN interfaces, can replace the traditional serial debugging tool to debug the smart meter, and can debug, check and diagnose the smart meter when the smart meter is connected to the power grid system, and have high flexibility.

[0064] The debugging system for the smart meter provided in the application is mainly an application program. To more clearly illustrate the structure and principle of the debugging system for the smart meter provided in the application, the following describes a debugging device provided with the application program corresponding to the debugging system.

[0065] An embodiment of the application provides a debugging device provided with the debugging system for the smart meter. The debugging device can be a terminal or other device. For example, the debugging device can be a mobile phone, a computer, a vehicle-mounted electronic device or other types of computer devices, and the like, which are not limited in the embodiments of the application.

[0066] Referring to Figure 1 , Figure 1 Fig. 1 shows a hardware structure of a debugging device. The debugging device 100 includes a processing unit 110, a memory 120, an input unit 130, a display unit 140 and a communication unit 150.

[0067] Those skilled in the art can understand that the debugging device 100 can also include a power supply (such as a battery) for supplying power to each component. The power supply can be logically connected to the processing unit 110 through a power management system, so as to realize functions such as management of charging, discharging and power consumption management through the power management system. Figure 1 The hardware structure shown in Fig. 1 does not constitute a limitation on the electronic device, and the electronic device can include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components, which will not be described here.

[0068] The processing unit 110 can include one or more microprocessors or microcontrollers, such as a central processing unit (CPU) and the like. The processing unit 110 is used for information processing and program running, and executes the application program corresponding to the debugging system to realize the debugging function configured by the debugging system.

[0069] The memory 120 can be used to store software programs and various data. The application programs corresponding to the debugging system can be stored in the memory 120, and various data generated by the debugging system in the process of running the CAN communication function can also be stored in the memory 120. The memory 120 can include volatile memory or non-volatile memory, or the memory 120 can include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus random access memory (Direct Rambus RAM, DRRAM). The memory 120 in the embodiments of the present application includes but is not limited to these and any other suitable type of storage medium.

[0070] The input unit 130 can include a touch panel, a microphone, a physical keyboard, function keys, a mouse, or an operation lever, etc. The input forms thereof include but are not limited to language, touch, and physical keys, etc. The display unit 140 can include a display screen, which can be configured in the form of a liquid crystal display, an organic light-emitting diode, etc. In some examples, the display screen can also be configured with a touch unit to serve as a touch panel, thereby giving consideration to both input and display functions.

[0071] The communication unit 150 at least includes a CAN interface unit, which can include multiple CAN interfaces, each of which can be of different types, such as different manufacturers or different models. In addition, the communication unit 150 can also include a network communication module, a Bluetooth communication module, or a radio frequency communication module, etc., which are not limited in the embodiments of the present application.

[0072] The debugging device 100 is connected with at least one smart meter. The CAN interface of the debugging device 100 is connected with the CAN interface of the smart meter through the CAN bus. Of course, the smart meter itself can also be integrated with other types of communication modules, such as a serial port module, a network communication module or a power carrier communication module, for communication and data transmission. The debugging device 100 is connected with the smart meter, and runs the corresponding application program of the debugging system to debug the smart meter based on CAN communication.

[0073] Referring to Figure 2 , Figure 2 The hierarchical structure of a debugging system is shown, and one embodiment of the present application proposes a debugging system of a smart meter.

[0074] In the present embodiment, the debugging system of the smart meter includes a window component 10, a hardware driver component 20 and a protocol program component 30. The window component 10 is configured with an interactive window to receive operations and display information. The hardware driver component 20 includes a CAN universal driver model 21, which provides a unified programming interface for different types of CAN interfaces using an object-oriented architecture, realizes the interaction between the programming interface and each CAN interface, and drives each CAN interface to communicate. The protocol program component 30 calls the programming interface in response to operations, and generates information based on the feedback of the programming interface. The CAN interface is used to connect the smart meter.

[0075] The application program follows a modular architecture, including a window layer, a protocol layer and a hardware driver layer, and shields the complexity of the lower layer through layering to provide a more concise interface for the upper layer. The window layer provides user operation abstraction, corresponding to the window component 10; the protocol layer provides debugging command abstraction, corresponding to the protocol program component 30; and the hardware driver layer provides byte stream transmission abstraction, corresponding to the hardware driver component 20.

[0076] The interactive window can include an image interface, which can be displayed through the display unit 140. The image interface can include a display window and an operation window. The display window is used to provide a visual operation interface for the user, and to display CAN information during the debugging process. The operation window is used to receive the input of the user, such as a setting instruction for a CAN debugging project, an information display instruction. Some operation windows also have a display function, which displays the input information while receiving the input of the user, for the user to check. Some operation windows can also link multiple image interfaces in the form of links, and the user can browse different image interfaces by operating such windows. The specific window configuration of each image interface can be set according to the requirements.

[0077] The hardware driver component 20 is used to implement the driver of the CAN interface to realize the sending and receiving of CAN information. The debugging system requires high compatibility, and therefore the hardware driver component 20 needs to be able to drive different types of CAN interfaces, which refer to the manufacturers and models of the CAN interfaces.

[0078] The CAN general driver model 21 is designed using an object-oriented architecture, which has a basic abstract class defining the interface and specific implementations for different types of CAN interfaces. The CAN general driver model 21 can be integrated on the basis of the original drivers of different types of CAN interfaces, so that the same programming instructions can perform the same interaction on different types of CAN interfaces.

[0079] In some embodiments, the hardware driver component 20 further includes a TCP / UDP driver unit 22, which is used to drive the TCP / UDP serial port to communicate in response to the call of the protocol program component 30.

[0080] The debugging system can also implement TCP / UDP serial port communication, and the corresponding debugging device 100 is provided with a serial port unit. The debugging device 100 can be connected with other computer devices or servers through the serial port unit, which can be used for the transmission and backup of debugging information. In addition, the debugging configuration information sent by other devices can also be received through the serial port unit to configure the CAN debugging process.

[0081] The protocol program component 30 implements the interaction between the window component 10 and the hardware driver component 20, is responsible for analyzing the input instructions of the window component 10, and performs the corresponding functions. For example, the data input by the window component 10 is converted into a message conforming to the CAN protocol, and the hardware driver component 20 is called to send; or in response to the display instruction of the window component 10 for a specific content, the corresponding data is filtered and converted into readable text for display.

[0082] The debugging system of the smart meter proposed in the present application realizes the interaction with different types of CAN interfaces based on the CAN protocol, can replace the traditional serial port debugging, and can be used to carry out debugging, checking and diagnosis on devices that cannot be disassembled, or even on devices that are still connected to the CAN bus and working, which is highly flexible.

[0083] Reference Figure 3 , Figure 3 A hierarchical structure of a hardware driver component 20 is shown. The hardware driver component 20 includes a CAN general driver model 21 and a TCP / UDP driver unit 22, the CAN general driver model 21 is used to drive different types of CAN interfaces, and the TCP / UDP driver unit 22 is used to drive the serial port unit.

[0084] In some embodiments, the CAN universal drive model 21 includes a device management unit 211 and a parameter configuration unit 212, the device management unit 211 is used for brand and / or model selection of the CAN interface, CAN interface information extraction, and enablement, disablement and working parameter setting of the communication channel; the parameter configuration unit 212 is used for selection of the CAN protocol and the CANFD protocol and configuration of the communication parameters.

[0085] The CAN universal drive model 21 abstracts multiple functions, while the window component 10 provides corresponding operation windows. The functions and the corresponding operation windows are converted through the protocol program component 30, so that the user can configure the functions. The device management unit 211 is an abstracted hardware management function, which is used for management of hardware information of the CAN interface involved in the debugging process. The parameter configuration unit 212 is an abstracted communication parameter configuration function, which is used for configuration of the communication parameters in the debugging process.

[0086] The CAN interface information can include serial number and version number, etc. Some smart meters include multiple physical channels, and the device management unit 211 is used for enablement and disablement control of the channels, so as to test the corresponding channels in a targeted manner. The working parameters of the channels can include signal level and / or terminal resistance, etc.

[0087] In some embodiments, the communication parameters include frame format, communication rate, communication mode, transmission module and enablement / disablement of specific hardware, the frame format includes CAN protocol format, CANFD protocol format, standard ID, extended ID, data frame and remote frame, etc.

[0088] The communication rate can include multiple baud rates, the communication mode can include Normal mode or listen-only mode, etc., the transmission module can include normal transmission, delay transmission and periodic transmission, etc. The specific hardware refers to physical electronic components of the CAN node, such as CAN controller and CAN transceiver, etc., and the physical state of the CAN interface can be configured by enablement / disablement of such components, so as to realize multi-dimensional debugging.

[0089] Referring to Figure 4 , Figure 4 A hierarchical structure of the protocol program component 30 is shown. In some embodiments, the protocol program component 30 includes a message transmission unit 31, the message transmission unit 31 includes a data editing unit, a verification unit and a first sending unit, the data editing unit is used for generating message data in response to a message editing operation; the verification unit integrates multiple length cyclic redundancy check calculation units and checksum calculation units, which are used for calling corresponding calculation units to verify the message data; the first sending unit generates a message based on the message data and the verification result, and calls a programming interface to send the message.

[0090] The message transmission unit 31 is configured to generate messages and call the CAN general driver model 21 to send the messages. The message editing operation includes data content input by the user through the window component 10, and the data editing unit is configured to convert the data content into message data in a corresponding format according to a selected CAN protocol or CANFD protocol.

[0091] The cyclic redundancy check calculation unit of multiple lengths includes CRC16 and CRC32, etc. The check unit can select a corresponding check mode according to the length of the message data, so as to check the indefinite length data, and the length of the input data can not be limited.

[0092] The first sending unit is configured to call the CAN general driver model 21 and send the message data to the corresponding CAN interface to realize message sending. The first sending unit can also be configured to send the time, such as immediate sending, delayed sending or specified interval.

[0093] In the related art, the vehicle-mounted protocol is implemented in 8 / 64 byte integer multiples by referring to the hardware characteristics of CAN, and lacks flexible length sending, so the function of message sending plus CRC calculation is not considered. The embodiment can send indefinite length data by flexible check.

[0094] In some embodiments, the protocol program component 30 further includes a log sender 32, which includes a log parsing unit and a second sending unit. The log parsing unit extracts target information in a log file based on a configured field index rule; and the second sending unit generates a message list according to the target information, and calls a programming interface to send each message in the message list.

[0095] The log parsing unit allows the user to load a CAN log file, for example, reads the log file line by line, and uses spaces as delimiters to split each line into multiple fields. Then, the corresponding information is extracted according to the configured field index rule. The fields used for indexing in the field index rule can include time, CAN ID indexed by a specified CAN ID, number of data bytes in a byte index, actual number of data bytes from a starting index, etc.

[0096] As an example, the sending process of the second sending unit is as follows: traverse each queued message; convert the stored string data into binary format; send each message through the CAN general driver model 21 to drive the CAN interface; apply a configured delay between messages; handle special waiting conditions for specific CAN IDs or data values; update the progress indicator; repeat the entire process for a configured number of loops. In this way, real CAN traffic can be simulated for testing and debugging.

[0097] In some embodiments, the protocol procedure component further comprises a data diagnosis unit 33 and a protocol conversion unit 34. The data diagnosis unit 33 is configured to analyze the CAN data fed back by the programming interface according to the configured diagnosis rules to determine the state information of the corresponding smart meter; and the protocol conversion unit 34 is configured to convert the CAN data between the CAN protocol format and the CANFD protocol format.

[0098] The data diagnosis unit 33 can analyze the ID, timestamp, data content, protocol version, rate period or occurrence times of each frame of the CAN data to determine whether the abnormality exists in the driving of the sending end device. The specific diagnosis rules can be configured according to the requirements, and the diagnosis is more comprehensive.

[0099] Generally, the devices using the CANFD protocol support the CAN frame, but the devices using the CAN protocol do not support the CANFD frame, which makes the two devices unable to communicate normally. The protocol conversion unit 34 can convert the data frame of a specific ID in response to the configuration operation, such as converting the data frame in the CAN protocol format into the data frame in the CANFD protocol format, to realize the communication between the two devices and improve the compatibility and flexibility of the debugging system.

[0100] Referring to Figure 5 , Figure 5 A hierarchical structure of a window component 10 is shown. In some embodiments, the window component 10 comprises a main window unit 11 and an auxiliary window unit 12. The main window unit 11 is configured with interactive controls responding to CAN interface debugging operations; and the auxiliary window unit 12 is configured to respond to triggering operations to display at least one of a message display unit 121, an export unit 122 and a message statistics unit 123. The message display unit 121 is configured to display the original CAN message and the corresponding interpreted text data; the export unit 122 is configured to export the original CAN message and the interpreted text data into a text file; and the message statistics unit 123 is configured to display real-time statistical data of CAN communication, including the frame number and the byte count.

[0101] The CAN interface debugging operations mainly include hardware management functions and communication parameter configurations, corresponding to the functions abstracted by the device management unit 211 and the parameter configuration unit 212. The interactive controls can include an information editing window for writing or deleting information, facilitating the editing of communication data; or a filtering window for providing supported hardware and communication parameters for quick selection by the user. The main window unit 11 mainly provides the basic operations required for CAN debugging, so as to facilitate the user to quickly make the corresponding configurations required for CAN debugging.

[0102] The auxiliary window unit 12 is used to provide more tools for users to monitor the CAN debugging in more detail, and the auxiliary window unit 12 is hidden and displayed when needed, which can reduce the occupation of window resources.

[0103] The message display unit 121 is used to display message information, and the original CAN message and the corresponding interpreted text data can be used to monitor the CAN communication process more comprehensively. The message display unit 121 can be displayed by using an HTML web page, and HTML tags can be used to set the text color, size, and alignment, the color and alignment of different fields, so that the data display is more intuitive. In addition, the message display unit 121 can also add a time stamp when displaying information, or distinguish different information in different display modes. For example, the TX / RX message can be highlighted in different colors, or different information can be displayed in different font sizes, thicknesses, etc.

[0104] The export unit 122 is used to export the original CAN message and the interpreted text data, and the message format and channel information can be retained to facilitate further analysis of the CAN communication process. The message statistics unit 123 is used to display the specific process of CAN communication in real time, so that users can monitor the CAN debugging process in time.

[0105] As an example, the message display unit 121 can include a string conversion unit, a filtering unit, and a buffer unit. The string conversion unit is used to convert the original CAN message into a readable text string. The filtering unit filters the original CAN message and / or the text string to be displayed based on the configured filtering rules to obtain the information to be displayed. The filtering rules include ID mask filtering, channel filtering, character filtering, and communication direction filtering. The buffer unit includes a message list and a timer. The message list is used to receive the information to be displayed, and the timer is used to update the information to be displayed to the display interface asynchronously.

[0106] The string conversion unit is used to parse and convert the original CAN message to provide readable information for users. The parsing can include extracting different fields of different original CAN messages, etc., and the conversion process mainly converts the extracted information into the information required by the user. The information format of the information required by the user can be configured according to the needs.

[0107] The smart meter is usually in a bus, and the filtering unit can provide multiple filtering options for CAN messages to facilitate problem positioning in multi-device data analysis. The ID mask filtering can use a bitwise mask to filter messages by CAN ID. The channel filtering is used to view messages from a specific channel or all channels. The character filtering is used to filter specific text content. The communication direction can include TX or RX, and the filtering function can display either direction or both directions simultaneously.

[0108] The buffer unit can include a plurality of buffer areas, use a message list buffer to receive data, and update a display asynchronously through a timer to avoid interface lag.

[0109] As an example, the string conversion unit can include a format conversion unit, a data conversion unit, and a log conversion unit. The format conversion unit uses a QString class and a format function to format fields of the original CAN message into readable text strings. The data conversion unit converts binary data and / or data bytes of the original CAN message into hexadecimal data. The log conversion unit converts a log file in BLF format into a formatted text string.

[0110] In this example, the QString class and format functions of Qt are used to construct display text. The QString::asprintf function is used to format various fields of the CAN message, including channel number, direction, and ID, into readable text strings.

[0111] The data conversion unit can convert binary data into readable hexadecimal text and convert data bytes of the CAN message into a hexadecimal string for user reading. For example, the data conversion unit can use the char2str function to convert binary data.

[0112] In this example, the log conversion unit is also configured to convert log files for user reading. For example, CANFD messages can be converted from BLF files into formatted text strings containing timestamp, channel, ID, and other information.

[0113] In addition, the string conversion unit can also convert network data and display it in a formatted string for user reading. Display of network messages can include timestamp, IP address filtering, and character conversion functions.

[0114] Referring to Figure 6 , Figure 6 A flow of a debugging method of a smart meter is shown, and one embodiment of the present application further provides a debugging method of a smart meter. In the present embodiment, the debugging method of the smart meter is applied to the aforementioned debugging device, and the debugging device is connected to a smart meter to be debugged through a CAN interface. The debugging method includes steps 10, 20, and 30.

[0115] Step 10, selecting hardware information of the CAN interface by the debugging system of the debugging device;

[0116] Step 20, configuring CAN communication parameters;

[0117] Step 30, start the debugging system to communicate with the smart meter to be debugged through the CAN interface.

[0118] In this embodiment, the execution subject of the debugging method is the debugging device. The debugging device is installed with the application program corresponding to the debugging system, and the debugging device responds to external operations during execution and runs the application program corresponding to the debugging system to implement the debugging method.

[0119] The hardware information of the CAN interface can include the brand, model, serial number, version number of the CAN interface, or the enablement, disablement of the communication channel, etc. The CAN communication parameters can include the frame format, communication rate, communication mode, transmission module, and enablement / disablement of specific hardware, and the frame format includes the CAN protocol format, CANFD protocol format, standard ID, extended ID, data frame, and remote frame, etc.

[0120] The debugging device includes an input unit 130 and a display unit 140. The user can operate the input unit 130 to configure the above-mentioned information, and the display unit 140 can display the user's input for the user to view. For example, the input unit 130 can include a keyboard, and the display unit 140 can include a display screen. The keyboard can be an external keyboard, or a virtual keyboard displayed on the display screen and can be operated by touch.

[0121] In step 30, the protocol program component 30 in the debugging system parses the information configured by the user and generates corresponding messages and corresponding communication strategies; the protocol program component 30 calls the hardware driver component 20 to send the messages through the CAN interface. The communication strategy can include the sending interval and the sending times, etc. The protocol program component 30 can also accept the feedback information from the hardware driver component 20 and transmit it to the window component 10 for display after parsing and conversion, providing the user with CAN communication information.

[0122] During the CAN debugging process, the debugging system can also respond to various text display operations. The protocol program component 30 parses the corresponding text display instructions, parses and converts the corresponding information, and then transmits it to the window component 10 for display. The specific structure of the debugging system can be referred to the implementation of the corresponding functions in the above-mentioned embodiments, which will not be described here in this embodiment.

[0123] The embodiments of the application are described above in conjunction with the accompanying drawings, but the application is not limited to the specific embodiments described above, which are only illustrative and not restrictive. Those skilled in the art can make many forms under the inspiration of the application without departing from the scope of the application and the protection scope of the claims.

[0124] In the description of the application, reference has been made to descriptive terms such as "one embodiment", "some embodiments", "an embodiment", "example", "specific example" or "some examples" etc. It is emphasized that each of these terms refers to a specific feature, structure, material or characteristic described in connection with a particular embodiment or example. The descriptive terms are not necessarily referring to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0125] Although embodiments of this application have been shown and described, it is to be understood that various modifications, substitutions, combinations, and variations can be made thereto by those of ordinary skill in the art without departing from the spirit and scope of the present application, which is defined by the following claims and their equivalents.

Claims

1. A debugging system for a smart meter, characterized in that: include: Window component, configured with an interactive window to receive operations and display information; A hardware driver component includes a CAN universal driver model, which uses an object-oriented architecture to provide a unified programming interface for different types of CAN interfaces, enabling interaction between the programming interface and each of the CAN interfaces to drive each of the CAN interfaces to communicate; a protocol program component that calls the programming interface in response to the operation and generates the information based on feedback from the programming interface; The CAN interface is used to connect to a smart meter.

2. The debugging system for a smart meter according to claim 1, characterized in that: The CAN general driver model includes: Device management unit, used for selecting the brand and / or model of the CAN interface, extracting CAN interface information, and enabling, disabling, and setting operating parameters of the communication channel; Parameter configuration unit, used for selecting CAN protocol and CANFD protocol and configuring communication parameters; The communication parameters include frame format, communication rate, communication mode, transmission module and enabling / disabling specific hardware, and the frame format includes CAN protocol format, CANFD protocol format, standard ID, extended ID, data frame and remote frame.

3. The debugging system for a smart meter according to claim 1 or 2, characterized in that: The protocol program component includes a message transmission unit, and the message transmission unit includes: A data editing unit, configured to generate message data in response to a message editing operation; A check unit, integrating cyclic redundancy check calculation units of various lengths and a checksum calculation unit, for calling corresponding calculation units to check the message data; The first sending unit generates a message based on the message data and the verification result, and calls the programming interface to send the message.

4. The debugging system for a smart meter according to claim 3, characterized in that: The protocol program component further includes a log sender, and the log sender includes: The log parsing unit extracts target information from the log file based on the configured field indexing rules; The second sending unit generates a message list according to the target information, and calls the programming interface to send each message in the message list.

5. The debugging system for a smart meter according to claim 4, characterized in that: The protocol program components also include: A data diagnosis unit, configured to analyze the CAN data fed back by the programming interface according to configured diagnostic rules to determine the status information of the corresponding smart meter; The protocol conversion unit is used to convert the CAN data between the CAN protocol format and the CANFD protocol format.

6. The debugging system for a smart meter according to claim 1 or 2, characterized in that: The window components include: The main window unit is configured with interactive controls that respond to CAN interface debugging operations; Auxiliary window unit, used to respond to trigger operations to display at least one of the following units: Message display unit, used to display the original CAN message and the corresponding interpretation text data; An export unit, configured to export the original CAN message and the interpreted text data into a text file; The message statistics unit is used to display real-time statistics of CAN communication, including frame count and byte count.

7. The debugging system for a smart meter according to claim 6, characterized in that: The message display unit includes: String conversion unit, used to convert raw CAN messages into readable text strings; a screening unit, which screens the original CAN message and / or the text string to be displayed based on configured screening rules to obtain information to be displayed, wherein the screening rules include ID mask screening, channel screening, character screening, and communication direction screening; The buffer unit includes a message list and a timer, wherein the message list is used to receive the information to be displayed, and the timer is used to asynchronously update the information to be displayed to the display interface.

8. The debugging system for a smart meter according to claim 7, characterized in that: The character string conversion unit includes: The formatting conversion unit uses the QString class and formatting functions to format each field of the original CAN message into a readable text string; A data conversion unit, configured to convert binary data and / or data bytes of the original CAN message into hexadecimal data; The log conversion unit is used to convert the log file in BLF format into a formatted text string.

9. A debugging device, characterized in that: The debugging device is configured with a debugging system for a smart meter according to any one of claims 1 to 8.

10. A method for debugging a smart meter, characterized in that: Applied to the debugging device according to claim 9, the debugging device is connected to the smart meter to be debugged via a CAN interface, and the debugging method includes: Selecting hardware information of the CAN interface in the debugging system of the debugging device; Configure CAN communication parameters; The debugging system is started to communicate with the smart meter to be debugged through the CAN interface.

Images