Communication specification generation device and communication specification generation method

Abstract

To generate communication specifications of a device whose communication specifications are unknown.SOLUTION: A communication specification generation device (101) includes a frame extraction unit (11) that extracts a frame having a specific frame length from communication log data generated by a target device (103), a header identification unit (12) that sequentially compares values in a range determined by a standard header length from a head of the frame between two consecutive frames to identify a header of the frame, and a combination identification unit (13) that extracts codes of a command and a response from the header on the basis of position information and size information about the respective codes of the command and response frames and identifies a combination of the codes of the command and the response according to a communication state of the command and response frames in the communication log data.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a communication specification generating device that generates communication specifications. [Background technology]

[0002] Patent Document 1 discloses a communication specification verification device that analyzes a communication log obtained from actual communication with a verification target device and extracts the communication specifications resulting from the communication as actual communication specifications. The communication specification verification device generates the communication log by communicating with a verification device according to a verification scenario developed from a defined communication specification defined in a communication specification. In this way, the technology disclosed in Patent Document 1 obtains actual communication specifications from the results of communication actually performed based on a known defined communication specification. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2018-121245 Summary of the Invention [Problem to be solved by the invention]

[0004] However, if the device to be verified is an old device or a special device, the communication specifications may be unknown, or even if the communication specifications exist, they may be impossible to obtain.

[0005] In such cases, the above technology cannot be applied to generate communication specifications. Therefore, it is necessary to analyze the commands and responses packet by packet from the communication log data acquired by a line analyzer or similar device that records communications with the device for which the communication specifications are to be generated. Depending on the communication specifications, this type of analysis can require a huge amount of time or be difficult to perform.

[0006] An aspect of the present invention aims to generate communication specifications for a device whose communication specifications are unknown. [Means for solving the problem]

[0007] In order to solve the above problem, a communication specification generation device according to one embodiment of the present invention is a communication specification generation device that generates communication specifications for communicating command frames and response frames as frames, and includes: a frame extraction unit that extracts frames having a frame length equal to or greater than a predetermined frame length from communication log data acquired in communication performed by a target device for which the communication specification is to be generated; a header identification unit that identifies a header in the frame by sequentially comparing, from the beginning of the extracted frame, values ​​within a range determined by one of a plurality of different pre-established standard header lengths between two consecutive frames; and a combination identification unit that extracts a command code of the command frame and a response code of the response frame from the identified header based on position information about the positions of each code of the command frame and the response frame and size information about the size of the code, and identifies a corresponding combination of the command code and the response code from the extracted command code and the response code in accordance with the communication status of the command frame and the response frame in the communication log data.

[0008] In order to solve the above problem, a communication specification generation method according to one embodiment of the present invention is a communication specification generation method for generating communication specifications for communicating command frames and response frames as frames, and includes: a frame extraction step of extracting frames having a frame length equal to or greater than a predetermined frame length from communication log data acquired in communication performed by a target device for which the communication specification is to be generated; a header identification step of identifying a header in the frame by sequentially comparing, from the beginning of the extracted frame, values ​​within a range determined by one of a plurality of different pre-defined standard header lengths between two consecutive frames; and a combination identification step of extracting a command code of the command frame and a response code of the response frame from the identified header based on position information about the positions of each code of the command frame and the response frame and size information about the size of the code, and identifying a corresponding combination of the command code and the response code from the extracted command code and the response code in accordance with the communication status of the command frame and the response frame in the communication log data. [Effects of the Invention]

[0009] According to one aspect of the present invention, it is possible to generate communication specifications for a device whose communication specifications are unknown. [Brief explanation of the drawings]

[0010] [Figure 1] 1 is a block diagram showing a configuration of a communication specification generation system according to an embodiment of the present invention. [Figure 2] 10 is a flowchart showing a procedure of a process performed by a communication specification generating device in the communication specification generating system to generate a communication specification. [Figure 3] 3 is a flowchart showing the procedure of the process for generating communication specifications following the flowchart of FIG. 2. [Figure 4] FIG. 10 is a diagram showing the structure of a frame acquired from communication log data. [Figure 5]FIG. 10 is a diagram showing the distribution of the number of frames relative to the command length and response length of the acquired frames. [Figure 6] 3 is a flowchart showing the procedure of a header analysis process in the flowchart shown in FIG. 2. [Figure 7] 4 is a flowchart showing the procedure of a code analysis process in the flowchart shown in FIG. 3. [Figure 8] FIG. 10 is a diagram showing an analysis result display screen showing analysis results of commands and responses. [Figure 9] 3 is a flowchart showing the procedure of a correction process in the flowchart shown in FIG. 2. [Figure 10] FIG. 10 is a diagram showing a correction input screen for correcting analysis results of commands and responses. [Figure 11] 3 is a flowchart showing the procedure of an analysis result verification process in the flowchart shown in FIG. 2. [Figure 12] FIG. 10 is a diagram showing a verification screen showing the results of verifying the analysis results of the command and response. DETAILED DESCRIPTION OF THE INVENTION

[0011] [Embodiment] Hereinafter, one embodiment of the present invention will be described in detail.

[0012] Overview of the communication specification generation system FIG. 1 is a block diagram showing the configuration of a communication specification generation system according to this embodiment.

[0013] As shown in FIG. 1, the communication specification generation system includes a communication specification generation device 101, a communication specification information database 102 (database), a target device 103, an HMI (Human Machine Interface) device 104, and a communication analyzer 105.

[0014] The target device 103 is a device for which communication specifications are to be generated. The target device 103 is assumed to be a control device such as a PLC (Programmable Logic Controller). The HMI device 104 is a device such as a programmable display that normally communicates with the target device 103.

[0015] The communication analyzer 105 analyzes the communication between the target device 103 and the HMI device 104, and the communication between the target device 103 and the communication specification generating device 101. The communication analyzer 105 analyzes the data communicated between the target device 103 and the HMI device 104, and between the target device 103 and the communication specification generating device 101, i.e., the communication protocol included in the data transmitted over the communication cable, and outputs the result of decoding the communication protocol as a list of numerical values ​​as communication record data.

[0016] The communication log data (first communication log data) is communication record data acquired by the communication analyzer 105 in the communication between the target device 103 and the HMI device 104. The communication log data (second communication log data) is communication record data acquired by the communication analyzer 105 in the communication between the communication specification generating device 101 and the target device 103. In the following explanations except for the Summary section described below, when the former and latter communication log data are to be distinguished, they will be referred to as "first communication log data" and "second communication log data," respectively, while when the former and latter are not to be distinguished, they will be simply referred to as "communication log data."

[0017] In this embodiment, as an example, communication log data is used when the target device 103 communicates with the HMI device 104. However, the communication partner of the target device 103 is not limited to the HMI device 104.

[0018] The communication log data is stored in the form of a file in the communication specification generating device 101. Note that the communication log data is usually stored inside the communication specification generating device 101, but may also be stored outside the communication specification generating device 101.

[0019] The communication specification generation system uses the communication content acquired from the first communication log data and the communication specification information stored in the communication specification information database 102 to generate communication specifications for the unknown target device 103 by the communication specification generation device 101. Also, the communication specification generation system uses the communication content acquired from the second communication log data and the communication specification information stored in the communication specification information database 102 to generate communication specifications for the target device 103 when an error or abnormality occurs in communication by the communication specification generation device 101.

[0020] The communication specification information database 102 stores standard specifications related to command and response communication as communication specification information. The communication specification information database 102 first stores communication specification information obtained from existing communication specifications. The communication specification information database 102 also stores communication specification information obtained from communication specifications previously generated by the communication specification generating device 101. The communication specification information stored in the communication specification information database 102 will be described in detail later.

[0021] The communication specification generating device 101 is a core device in the communication specification generating system, and generates communication specifications for communicating command frames and response frames as frames. The communication specification generating device 101 is configured by a general-purpose computer such as a PC (Personal Computer).

[0022] <Configuration of communication specification generating device> The communication specification generating device 101 has a control unit 1, a storage unit 2, a display unit 3, and an input unit 4. The communication specification generating device 101 has a control device such as a CPU (Central Processing Unit).

[0023] The storage unit 2 includes various storage devices such as a RAM (Random Access Memory) and an auxiliary storage device. The RAM temporarily stores communication specification data created by the combination identification unit 13 (described later). The auxiliary storage device is configured with an HDD (Hard Disk Drive), an SSD (Solid State Drive), etc., and saves the communication specification data created by the combination identification unit 13.

[0024] The display unit 3 displays various screens and the like used in the generation process of communication specifications, which will be described later, by the communication specification generation device 101. The input unit 4 accepts various input operations by the user, including input operations such as input to the screens.

[0025] The control unit 1 is a part having functions realized by the control device executing an application program for generating communication specifications. The control unit 1 has a frame extraction unit 11, a header identification unit 12, a combination identification unit 13, a correction unit 14, a storage unit 15, an output unit 16, a command generation unit 17, a communication unit 18 (transmission unit), and a verification unit 19.

[0026] The frame extraction unit 11 extracts frames having a frame length equal to or greater than a predetermined frame length from the first communication log data. The first communication log data includes not only command frames and response frames that represent the actual state of communication, but also various other frames such as frames for initialization. The frame extraction unit 11 extracts command frames and response frames from the frames included in the first communication log data.

[0027] It is known that command frames and response frames have a frame length of, for example, 4 to 8 words. Therefore, the frame extraction unit 11 extracts frames having a frame length equal to or greater than the minimum frame length from the first communication log data, where the minimum frame length of the command frames and response frames is set as a predetermined frame length. Alternatively, the frame extraction unit 11 may extract frames having a frame length equal to or greater than the minimum frame length and equal to or less than the maximum frame length of the command frames and response frames, which is the minimum frame length plus a specified frame length.

[0028] The frame extraction unit 11 extracts from the second communication log data a frame of an error command or an abnormal command transmitted from the communication specification generating device 101 to the target device 103 via a communication unit 18, which will be described later. The frame extraction unit 11 also extracts from the second communication log data a frame of an error response transmitted from the target device 103 to the communication specification generating device 101 in response to the error command or the abnormal command.

[0029] The header identification unit 12 identifies the header in the frame based on the frame extracted by the frame extraction unit 11 and the standard header length acquired from the communication specification information database 102. Specifically, a plurality of header lengths are pre-defined in the communication specification information database 102. The header identification unit 12 selects one standard header length from the plurality of header lengths in the communication specification information database 102. The header identification unit 12 also identifies the header by sequentially comparing values ​​within a range determined by the selected header length between two consecutive frames, starting from the beginning of the extracted frame. Here, the comparison is between two consecutive command frames, and between two consecutive response frames.

[0030] Typically, the headers in a frame have the same values ​​for commands and responses. Therefore, if the header values ​​of a command and a response match within the range determined by the standard header length, it can be assumed that the position from the beginning of the frame determined by the standard header length is the end of the header. The header identification unit 12 identifies the header based on this estimation. Furthermore, if the values ​​within the above range of the two frames being compared do not match, the header identification unit 12 changes the standard header length and compares the values ​​within the above range, since it is possible that the standard header length does not indicate the end of the header.

[0031] The combination identification unit 13 extracts the command code of the command frame and the response code of the response frame from the header identified by the header identification unit 12, based on the position information and size information of the command frame and the response frame, respectively. Furthermore, the combination identification unit 13 identifies a corresponding combination of command codes and response codes from the extracted command codes and response codes, based on the communication states of the command frame and the response frame in the first communication log data. The combination identification unit 13 generates communication specifications by identifying the configurations of the command frame and the response frame based on the identified combination.

[0032] The position information is information about the position of each code in the command frame and the response frame. The size information is information about the size of each code in the command frame and the response frame. The position information and size information are stored in the communication specification information database 102. The combination identification unit 13 acquires the position information and size information from the communication specification information database 102. The combination identification unit 13 also stores the generated communication specifications in the storage unit 2 as communication specification data.

[0033] The correction unit 14 causes the display unit 3 to display the configurations of the command frame and the response frame in the communication specifications generated by the combination identification unit 13. Furthermore, the correction unit 14 corrects the communication specifications by changing the configurations of the command frame and the response frame displayed on the display unit 3 in accordance with an input operation by the user accepted by the input unit 4.

[0034] The verification unit 19 verifies the communication specifications generated by the combination identification unit 13. For the verification, the correction unit 14 displays the acquired values ​​of the first communication log data on the display unit 3 so that the values ​​correspond to the command frames and response frames in the generated communication specifications. Furthermore, when the displayed value displayed on the display unit 3 differs from the communication specifications, the correction unit 14 highlights the displayed value.

[0035] The storage unit 15 stores information including a specified frame length, a standard header length, position information, and size information in the communication specification information database 102 based on the communication specifications generated by the combination identification unit 13 or the communication specifications corrected by the correction unit 14.

[0036] The output unit 16 outputs the communication specifications created by the communication specification generation device 101 in various file formats. Examples of such file formats include the XML (eXtensible Markup Language) format, but other file formats may also be used.

[0037] The command generation unit 17 generates an error command or an abnormal command based on the communication specification data stored in the storage unit 2. Specifically, the command generation unit 17 generates an error command by changing a normal value in a normal command obtained from the communication specification data to a value that will cause an error. For example, the command generation unit 17 generates an error command by making changes to a normal command, such as changing the address range, specifying a non-existent variable, or specifying a non-existent device address.

[0038] Furthermore, the command generation unit 17 generates an abnormal command by changing a normal value in a normal command obtained from the communication specification data to an abnormal value. For example, the command generation unit 17 generates an abnormal command by changing the code, numerical value, and check code of a normal command to abnormal values. An abnormal code is a code that does not exist in the communication specification or a code with an abnormal value. Examples of abnormal codes include command codes with abnormal values. An abnormal numerical value is a numerical value such as the number of data or the number of bytes that does not match the accompanying information in the frame. An abnormal check code is a check code that does not match the calculated value in the actual frame. Check codes are provided to detect and correct communication errors such as checksums, CRCs, and parities.

[0039] The communication unit 18 transmits the error command or abnormal command generated by the command generation unit 17 to the target device 103. The communication unit 18 also receives an error response transmitted (returned) from the target device 103 in response to the transmitted error command or abnormal command. An error command indicates an abnormality in a parameter, and an abnormal command indicates an abnormality in a command code. Therefore, the target device 103 recognizes the error command or abnormal command as an error and transmits an error response.

[0040] <Information stored in the communication specification information database> The communication specification information database 102 stores the above-mentioned predetermined frame length, standard header length, position information, and size information. The communication specification information database 102 also stores, as standard communication specification information, the frame format of commands and responses, frame length, header length, checksum and CRC calculation formulas, and data format.

[0041] Examples of command frame formats include a first format in which a "command code," "device code," "address," and "data length" are arranged, and a second format in which multiple pieces of "data" follow in addition to the first format. Examples of response frame formats include a first format in which a "response code," "device code," "address," "status," "data length," and multiple pieces of "data" are arranged, and a second format in which the multiple pieces of "data" are removed from the first format.

[0042] The first form of the command frame corresponds to the first form of the response frame, and the second form of the command frame corresponds to the second form of the response frame.

[0043] Examples of command frame lengths include a read command frame length of 8 bytes (header) and a write command frame length of 8 bytes (header) + 256 bytes. Examples of response frame lengths include a read response frame length of 10 bytes (header) + 256 bytes and a write response frame length of 10 bytes (header). These frame lengths are used as the predetermined frame lengths.

[0044] Header lengths include 4 bytes, 6 bytes, 8 bytes, 16 bytes, and 32 bytes. These frame lengths are used as standard header lengths. Checksum and CRC calculation formulas include a hexadecimal string of the last two digits of the result of adding the byte data of the header data and parameter data. Data formats include ACI, binary, and BCD.

[0045] These pieces of information can be customized by the user. Basic information as communication specifications is registered in advance in the communication specification information database 102.

[0046] <Generation of communication specifications by communication specification generation device> Fig. 2 is a flowchart showing the procedure of the process (communication specification generation method) by which the communication specification generation device 101 generates communication specifications. Fig. 3 is a flowchart showing the procedure of the process of generating communication specifications following the flowchart of Fig. 2. Fig. 4 is a diagram showing the configuration of frames acquired from the first communication log data. Fig. 5 is a diagram showing the distribution of the number of frames with respect to the command length and response length of the acquired frames.

[0047] 2, first, the control unit 1 determines whether or not to perform communication specification analysis based on a user instruction (step S1). In step S1, if the control unit 1 determines that communication specification analysis is to be performed in response to the user instruction (YES), the frame extraction unit 11 acquires frames from the first communication log data (step S2).

[0048] As shown in Figure 4, a frame is configured with a header, parameters, and delimiters arranged in this order. The header is an area where data indicating the start of a frame is placed. The parameters are an area where data exchanged between devices through communication is placed. The delimiter is an area where data indicating the end of a frame is placed.

[0049] The frame extraction unit 11 checks the frame length of the acquired frames and checks the number of frames for each frame length (step S3). Next, the frame extraction unit 11 acquires the minimum frame length from the communication specification information database 102 (step S4). The minimum frame length is the minimum frame length of a command frame and a response frame.

[0050] The frame extraction unit 11 extracts frames having a frame length equal to or greater than the minimum frame length from the acquired frames (step S5, frame extraction step). In extracting the frames, the frame extraction unit 11 may extract frames having a frame length equal to or greater than the minimum frame length and equal to or less than the maximum frame length.

[0051] Frame extraction unit 11 may store the extracted frames in a predetermined area of ​​storage unit 2, for example. Frame extraction unit 11 may also store the extracted frames separately into command frames and response frames in storage unit 2. Frame extraction unit 11 not only extracts normal command and response frames as described above, but also extracts the above-mentioned error command and error response frames and abnormal command and error response frames.

[0052] The frame extraction unit 11 displays the statistical results for the extracted frames on the display unit 3 (step S6). For example, as shown in Fig. 5, the frame extraction unit 11 displays a diagram showing the distribution of the number of frames relative to the command / response length, which indicates the frame length, as the statistical results. Fig. 5 shows that frames within the range where the minimum frame length is "4" and the maximum frame length is "8" (indicated by the dashed line in the figure) were extracted.

[0053] When the statistical results are displayed, the control unit 1 determines whether or not to continue the analysis based on a user instruction (step S7). If the control unit 1 determines in step S7 that the analysis should be continued in response to the user instruction (YES), the header identification unit 12 performs a header analysis process (step S8, header identification step). The header analysis process is a process for identifying a header by identifying the range of the header in the extracted frame. The header analysis process will be described in detail later. The header identification unit 12 displays the analysis result on the display unit 3 as a result of the header analysis process (step S9).

[0054] When the analysis result is displayed, the header identification unit 12 determines whether or not to continue the analysis based on a user instruction (step S10). If the header identification unit 12 determines not to continue the analysis in response to the user instruction (NO) in step S10, it determines whether or not a header length to be used for the header analysis process has been input (step S11). In step S11, the header identification unit 12 displays a screen (not shown) for inputting the header length on the display unit 3, and accepts input of the header length by the user.

[0055] In step S11, if the header specification unit 12 determines that the header length has been input (YES), the process proceeds to step S8. In addition, in step S11, if the header specification unit 12 determines that the header length has not been input (NO), the process of analyzing the communication specifications ends.

[0056] Furthermore, if the control unit 1 determines in step S7 that the analysis should not be continued in response to a user instruction (NO), the frame extraction unit 11 determines whether a minimum frame length has been input based on the user instruction in order to extract frames again (step S12). In step S12, the frame extraction unit 11 displays a screen (not shown) for inputting the minimum frame length on the display unit 3, and receives input of the minimum frame length by the user.

[0057] If the frame extraction unit 11 determines in step S12 that the minimum frame length has been input (YES), it sets the input minimum frame length (step S13) and proceeds to step S5. If the frame extraction unit 11 determines in step S12 that the minimum frame length has not been input (NO), it ends the analysis of the communication specifications.

[0058] Furthermore, if the control unit 1 determines in step S1 that communication specification analysis is not to be performed (NO), the verification unit 19 performs a verification process (step S21) to be described later. The verification unit 19 displays the verification result on the display unit 3 as a result of the verification process (step S22), and ends the analysis process of the communication specifications. The verification process will be described in detail later.

[0059] In step S10, if the header identification unit 12 determines that the analysis should be continued in response to a user instruction (YES), the combination identification unit 13 performs a code analysis process (step S14, combination identification step), as shown in Fig. 3. Then, the combination identification unit 13 displays the communication specifications as the analysis results on the display unit 3 as the results of the code analysis process (step S15). The code analysis process will be described in detail later.

[0060] Thereafter, the correction unit 14 performs a correction process to correct the communication specifications based on the analysis result by the combination identification unit 13 (step S16). Then, the output unit 16 outputs the corrected communication specifications in a preset file format (step S17), thereby completing the analysis process of the communication specifications. Furthermore, by outputting the communication specifications thus generated in various file formats, the communication specifications can be used effectively. The correction process will be described in detail later.

[0061] <Header analysis process> The header analysis process in step S8 shown in Fig. 2 will now be described. Fig. 6 is a flowchart showing the procedure of the header analysis process in the flowchart shown in Fig. 2.

[0062] 6, first, the header specification unit 12 determines whether or not the header length was input in the above-mentioned step S11 (step S81). If the header specification unit 12 determines in step S81 that the header length was not input (NO), the header specification unit 12 acquires the standard header length from the communication specification information database 102 and defines the tentative header length N based on the standard header length (step S82).

[0063] Next, the header identification unit 12 selects the frame with the highest frame count number from among the frames extracted by the frame extraction unit 11 (step S83). For example, as shown in FIG. 5, the header identification unit 12 selects the frame with the highest frame count number of "60" and frame length of "5".

[0064] The header identification unit 12 sets the initial values ​​of frame count variables X and Y for the selected frame to 1 and 2, respectively, and sets the initial value of difference count value Z to 0 (step S84). The frame count variables X and Y are variables for counting two consecutive frames among the extracted frames. The difference count value Z is a value that is added when there is a difference between the values ​​of the two frames identified by the frame count variables X and Y, which will be described later.

[0065] The header identification unit 12 compares the values ​​of two consecutive Xth and Yth frames within the range of the tentative header length from the beginning of the Xth and Yth frames (step S85). The consecutive frames compared are two command frames and two response frames.

[0066] The header identification unit 12 compares the values ​​of the Xth and Yth frames and determines whether there is a difference between the two values ​​(step S86). If the header identification unit 12 determines that there is a difference between the two values ​​in step S86 (YES), it saves the position in the Xth and Yth frames where the value difference exists in variable W and adds 1 to the difference count value Z. The "position where the value difference exists" above is the position from the beginning of the frame.

[0067] Next, the header identification unit 12 determines whether the difference count value Z is 10 or more (step S88). If the header identification unit 12 determines in step S88 that the difference count value Z is not 10 or more (is less than 10) (NO), it determines whether the frame count variable Y has reached the maximum frame count number (step S89).

[0068] In step S89, if the header identification unit 12 determines that the frame count variable Y has reached the maximum frame count number (YES), it determines the header area using the tentative header length N as a return value (S90) and returns the process to the main routine shown in Fig. 2. For example, as shown in Fig. 5, when the frame values ​​are compared for a frame having a frame length of "5", the maximum frame count number for that frame is 60.

[0069] Furthermore, in step S81, if the header identification unit 12 determines that the header length has been input (YES), the process proceeds to step S83. As a result, the header identification unit 12 performs the processes from step S83 onward using the input header length instead of the tentative header length N.

[0070] Furthermore, if the header identification unit 12 determines in step S86 that there is no difference between the two values ​​(NO), it determines whether or not the frame count variable Y has reached the maximum frame count number (step S91). If the header identification unit 12 determines in step S91 that the frame count variable Y has reached the maximum frame count number (YES), it proceeds to step S90. If the header identification unit 12 determines in step S91 that the frame count variable Y has not reached the maximum frame count number (NO), it modifies the frame count numbers X and Y by adding 1 to each (step S92), and proceeds to step S85.

[0071] Furthermore, if the header identification unit 12 determines in step S88 that the difference count value Z is 10 or more (YES), it changes the tentative header length N to the position saved in variable W, initializes frame count variables X and Y and difference count value Z (step S93), and proceeds to step S85. For example, if the tentative header length N defined in step S82 is 8 bytes and the position where the value differs in step S87 is 6 bytes, the tentative header length N is changed to 6 bytes.

[0072] In this way, the header identification unit 12 repeats the comparison of the values ​​of the Xth and Yth frames within the range of the tentative header length N from the beginning of the frame, changing the frame count variables X and Y, if there is no difference between the two values. Also, if there is a difference between the two values, the header identification unit 12 adds 1 to the difference count Z and compares the two values.

[0073] The header identification unit 12 performs the above comparison until the frame count variable Y reaches the maximum frame count number, and if the number of times a difference has occurred between the two values ​​is less than a predetermined value of 10, it determines that the end of the header is located at a position from the start of the frame that is tentative header length N. Furthermore, if the header identification unit 12 performs the comparison until the frame count variable Y reaches the maximum frame count number, and the number of times a difference has occurred between the two values ​​is 10 or more, it updates the position where the values ​​differ to tentative header length N and compares the two values.

[0074] This process allows the header area to be identified based on the tentative header length N, which has little difference between the two values. The header area is identified not only for normal commands and responses, but also for error command and abnormal command frames and the corresponding error response frames.

[0075] Code analysis processing The code analysis process in step S14 shown in Fig. 3 will be described. Fig. 7 is a flowchart showing the steps of the code analysis process in the flowchart shown in Fig. 3. Fig. 8 is a diagram showing an analysis result display screen 200 showing the analysis results of the command and response.

[0076] As shown in Fig. 7, first, the combination identification unit 13 acquires position information and size information of the command code from the communication specification information database 102 as first candidate information, and sets these as code analysis variable K (step S141). The position information is information indicating the position of the command code in the header. The size information is information indicating the code length of the command code. For example, if the command code is "Code A", the code length is treated as a 2-byte value of "0x000A".

[0077] Next, the combination identification unit 13 acquires statistical values ​​of the code values ​​identified by the code analysis variable K (step S142). In step S142, the combination identification unit 13 acquires multiple command code positions and code lengths as code values ​​identified by the code analysis variable K from the multiple header areas identified by the header identification unit 12, and takes statistics of them. The statistical results are obtained as standard deviations of the command code positions and code lengths with respect to the code analysis variable K.

[0078] The combination identification unit 13 determines whether the statistical result acquired as described above is normally distributed (step S143). If the combination identification unit 13 determines that the statistical result is normally distributed (YES) in step S143, it extracts a plurality of command codes whose statistical result is normally distributed (step S144).

[0079] In step S143, if the combination identification unit 13 determines that the statistical results are not normally distributed (NO), it obtains the position information and size information of the next candidate command code from the communication specification information database 102, sets them as the code analysis variable K (step S145), and proceeds to step S142.

[0080] Next, the combination identification unit 13 acquires the position information and size information of the response code from the communication specification information database 102 as first candidate information, and sets these as the code analysis variable M (step S146). The position information is information indicating the position of the response code in the header. The size information is information indicating the code length of the response code. For example, if the response code is "Code D", the code length is treated as a 2-byte value of "0x000D".

[0081] Next, the combination identification unit 13 acquires statistical values ​​of the code values ​​identified by the code analysis variable M in the same manner as for the command code (step S147). The combination identification unit 13 determines whether the acquired statistical results are normally distributed (step S148). If the combination identification unit 13 determines in step S148 that the statistical results are normally distributed (YES), it extracts multiple response codes whose statistical results are normally distributed (step S149).

[0082] In step S148, if the combination identification unit 13 determines that the statistical results are not normally distributed (NO), it obtains the position information and size information of the next candidate response code from the communication specification information database 102, sets them as the code analysis variable M (step S150), and proceeds to step S147.

[0083] Furthermore, the combination identification unit 13 creates a comparison data table (not shown) of the extracted command codes and response codes from the transmission and reception status of the first communication log data (step S151). In the first communication log data, commands and responses are paired and the pairs are arranged in order. Therefore, in step S151, the combination identification unit 13 can create a correspondence table in which the command codes and response codes that make pairs are combined and the combinations are arranged in order based on the command and response pairs in the first communication log data.

[0084] Then, the combination specifying unit 13 specifies the combination of the command code and the response code using the table data of the comparison data table as a return value, and returns the process to the main routine shown in FIG.

[0085] In step S15 described above, the combination identification unit 13 identifies a pair of command frames and response frames from the command code and response code obtained as the analysis result, and creates communication specifications. The combination identification unit 13 stores the communication specifications as a communication specification data file in, for example, the storage unit 2. The combination identification unit 13 also displays the created communication specifications on an analysis result display screen 200 shown in FIG. 8, and displays the analysis result display screen 200 on the display unit 3.

[0086] The analysis result display screen 200 has a pair display area 201. In the pair display area 201, paired commands and responses are displayed in order from top to bottom. The pair display area 201 can be scrolled to display subsequent command and response pairs that are not currently displayed.

[0087] In this way, the combination identification unit 13 extracts command codes and response codes from the statistical results based on the position information and size information of the codes in the header identified by the header identification unit 12. Furthermore, the combination identification unit 13 identifies combinations of the extracted command codes and response codes from the relationship between the exchanges of command frames and response frames in the first communication log data. Then, communication specifications for the commands and responses are generated based on these combinations.

[0088] The combination identification unit 13 identifies the combination of the extracted error command code and error response code from the relationship between the exchange of the error command frame and the error response frame in the second communication log data. The combination identification unit 13 also identifies the combination of the extracted abnormal command code and error response code from the relationship between the exchange of the abnormal command frame and the error response frame in the second communication log data. To identify the combination, the combination identification unit 13 performs the above-mentioned code analysis process, substituting the first communication log data for the second communication log data.

[0089] As a result, the communication specifications for the error commands and error responses and the communication specifications for the abnormal commands and error responses described above are generated in the same way as the communication specifications for normal commands and responses. This makes it possible to generate communication specifications for when an error or abnormality occurs in communication. Therefore, it is possible to obtain communication specifications that assume communication exchanges with the target device 103 that would not actually occur.

[0090] Furthermore, the correction unit 14 accumulates communication specification information from the newly generated communication specifications in the communication specification information database 102. This makes it possible to improve the accuracy of generating communication specifications.

[0091] Correction Processing Fig. 9 is a flowchart showing the procedure of the correction process in the flowchart shown in Fig. 2. Fig. 10 is a diagram showing a correction input screen 300 for correcting the analysis results of the command and response.

[0092] As shown in Fig. 9, first, the correction unit 14 causes the display unit 3 to display a correction input screen 300 shown in Fig. 10 (step S161). Next, the correction unit 14 determines whether or not correction has been made on the correction input screen 300 (step S162). If the correction unit 14 determines in step S162 that correction has been made (YES), it changes the command and response based on the correction made (step S163) and returns the process to the main routine shown in Fig. 3. If the correction unit 14 determines in step S162 that correction has not been made (NO), it returns the process to the main routine shown in Fig. 3.

[0093] Next, a description will be given of the correction input screen 300. When the user selects one pair from the multiple pairs of commands and responses displayed on the above-described analysis result display screen 200, the correction unit 14 causes the display unit 3 to display the correction input screen 300.

[0094] The correction input screen 300 has a pair display area 301. In the pair display area 301, as in the above-described pair display area 201, paired commands and responses are displayed in order from top to bottom. The correction unit 14 displays at least one candidate command and response pair for one pair selected by the user in the pair display area 301. In the example shown in FIG. 10 , a candidate pair of a command having code A and a response having code D is displayed in the pair display area 301.

[0095] The correction unit 14 accepts a correction input by the user using the input unit 4 for the command and response in the pair display area 301. For a command and response pair selected by the user from the above candidates, the correction unit 14 changes the contents of the command and response according to the input correction, and displays the changed command and response in the pair display area 301. For example, corrections can be made to change incorrect parts, such as when the position of a command code is misaligned or when a part identified as a delimiter is a CRC.

[0096] In addition, the pair display area 301 is provided with a next candidate button 303 and a done button 304 .

[0097] The next candidate button 303 is a button that is operated when there are multiple candidate pairs and the next candidate is to be selected. It becomes possible to input corrections for the selected command and response pair. For example, the correction input screen 300 shown in the upper part of FIG. 10 displays two pairs of commands and responses arranged vertically, and the correction input screen 300 shown in the lower part of FIG. 10 displays one pair. From this state, each time the next candidate button 303 is operated, the candidate to be selected changes.

[0098] The done button 304 is a button that is operated when the selection of candidates is completed and the display is returned to the analysis result display screen 200.

[0099] The correction unit 14 displays statistical information about pairs of commands and responses (normal responses) in statistical information display areas 305 to 307 provided in the pair display area 301. The statistical information includes, as value information in statistical data of patterns of multiple communication specifications (frame configurations) for pairs of commands and responses obtained in the code analysis process, the median, second value, third value, etc. The statistical information also includes information on the probability that the pattern of pairs of commands and responses occupies the first communication log data. The correction unit 14 displays the pairs in the pair display area 301 in descending order of the degree (probability) that they are assumed to be correct from the viewpoint of normal distribution.

[0100] In this way, the correction unit 14 displays the created communication specifications on the correction input screen 300. This allows the configuration of the command frame and response frame to be visually confirmed. Therefore, the commands and responses of the communication specifications can be corrected as desired.

[0101] Furthermore, the correction unit 14 stores communication specification information based on the communication specifications corrected as described above in the communication specification information database 102. This makes it possible to improve the accuracy of correction of the communication specifications.

[0102] <Verification process> Fig. 11 is a flowchart showing the procedure of the verification process in the main routine shown in the flowchart of Fig. 2. Fig. 12 is a diagram showing a verification screen 400 showing the results of verifying the analysis results of the command and response.

[0103] 11, first, the verification unit 19 displays a file name input screen (not shown) for the communication specification data on the display unit 3 (step S211). The verification unit 19 determines whether or not the file name input on the file name input screen is valid (step S212). In step S212, the verification unit 19 checks whether or not there is a file name corresponding to the input file name for the files of the communication specification data stored in the storage unit 2.

[0104] In step S212, if the verification unit 19 determines that the file name entered on the file name input screen is valid (YES), it causes the display unit 3 to display a file name input screen (not shown) for entering a file name for the first communication log data (step S213). In step S213, the verification unit 19 determines whether the file name entered on the file name input screen is valid (step S214). In step S214, the verification unit 19 checks whether or not a file name corresponding to the entered file name exists for the file of the first communication log data.

[0105] In step S214, if the verification unit 19 determines that the input file name is valid (YES), it acquires the communication specification data and the first communication log data as files with the input file names, and reads them into the storage unit 2 (step S215). The verification unit 19 extracts the command and response frames to be verified from the first communication log data read into the storage unit 2, and displays the frames on the display unit 3 so that they conform to a predetermined format (step S216). The verification unit 19 displays the command and response frames of the first communication log data on a verification screen 400 shown in FIG. 12, and displays the verification screen 400 on the display unit 3.

[0106] The verification unit 19 determines whether there is a difference between the displayed frame and the command and response frames of the communication specification corresponding to the frame (step S217). If it determines that there is a difference between the two frames (YES) in step 217, the verification unit 19 highlights the difference between the two frames on the verification screen 400 and displays a comment about the difference (step S218).

[0107] The verification unit 19 determines whether or not to correct the portion where there is a difference between both frames based on a user instruction (step S219). In step S219, if the verification unit 19 determines that the portion where there is a difference between both frames is to be corrected based on the user instruction (YES), the verification unit 19 shifts the processing to the correction processing described above (step S16). If the verification unit 19 determines that the portion where there is a difference between both frames is to be corrected, the verification unit 19 notifies the correction unit 14 of the correction. Upon receiving this notification, the correction unit 14 performs the correction processing on the portion.

[0108] When the verification unit 19 receives notification of the completion of the correction process from the correction unit 14, it determines whether or not there is next data to verify (step S220). If the verification unit 19 determines in step S220 that there is next data to verify (YES), it proceeds to step S215. Alternatively, if the verification unit 19 determines that there is next data to verify (YES), it may proceed to step S216. Also, if the verification unit 19 determines in step S220 that there is no next data to verify (NO), it ends the verification process and returns to the main routine shown in FIG. 2.

[0109] Furthermore, if the verification unit 19 determines in step S217 that there is no difference between the two frames (NO), it displays the verification result on the verification screen 400 (step S221), and moves the process to step S220.

[0110] Furthermore, in step S212, if the verification unit 19 determines that the input file name is invalid (NO), it displays an error on the display unit 3 (S222), and determines whether or not it has recognized that the user has re-input the input file (step S223). The user instructs re-input by clicking a re-input button (not shown) displayed on the verification screen 400. The verification unit 19 recognizes that the input file has been re-input based on this instruction. In step S223, if the verification unit 19 determines that the re-input of the file name has been recognized (YES), the process proceeds to step S211. In addition, in step S223, if the verification unit 19 determines that the re-input of the file name has not been recognized (NO), the verification process ends and the process returns to the main routine shown in FIG.

[0111] Furthermore, in step S214, if the verification unit 19 determines that the input file name is invalid (NO), it displays an error on the display unit 3 (S224) and determines whether or not it has recognized re-input of the input file (step S225). In step S225, if the verification unit 19 determines that it has recognized re-input of the file name (YES), it transitions the process to step S213. In step S225, if the verification unit 19 determines that it has not recognized re-input of the file name (NO), it ends the verification process and returns the process to the main routine shown in FIG.

[0112] Next, the verification screen 400 will be described. As shown in the upper part of Fig. 12, the verification screen 400 has a frame display area 401. In the frame display area 401, command and response frames extracted from the first communication log data read into the storage unit 2 are displayed in a predetermined format. For example, the format is a format in which the name and value of each part of the frame are displayed side by side.

[0113] The frame display area 401 is provided with a Next button 403 and a Done button 404. The Next button 403 is operated to display the next command and response frame to be verified. The Done button 404 is operated to complete the verification and close the verification screen 400.

[0114] If it is determined in step S217 above that there are differences between the two frames (YES), the verification unit 19 highlights the differences in each part of the frames displayed in the frame display area 401, as shown in the lower part of Fig. 12. For example, the verification unit 19 highlights the differences by underlining them, as shown in the lower part of Fig. 12. Furthermore, the verification unit 19 may highlight the differences by using bold, coloring, or the like. For highlighting by coloring, red is preferred as it is easily noticeable.

[0115] In the example shown at the bottom of Figure 12, for a command frame, when the "DM" in the "Dev Name" (device name), which is actually two bytes, is analyzed as one byte, it shifts one character toward the "Address" side. As a result, "Dev Name" is displayed as "D," and the correct "Address" displayed as "0x0100" is displayed as "0x4D01" including a "D." Furthermore, the "Data Length" is displayed as 0x0000 because extra data that is shifted from the "Address" is included, indicating that "Append: 0xFF" has occurred as extra data outside the communication specifications. Furthermore, in the example shown at the bottom of Figure 12, for a response frame, "Data N," which is "0x0033" in the first communication log data, is displayed as "0x33" because one byte is missing in the communication specification data.

[0116] Similar to the correction input screen 300, the verification screen 400 is configured to allow the user to input corrections by operating the input unit 4. Then, the verification unit 19 accepts the correction input on the verification screen 400 and corrects the communication specifications.

[0117] In this way, on the verification screen 400, if the communication specifications have been generated correctly, the value of the first communication log data and the displayed value will match, whereas if the communication specifications have not been generated correctly, the value of the first communication log data and the displayed value will not match and the displayed value will be highlighted. Furthermore, on the verification screen 400, the command and response codes of the first communication log data are displayed in a format that is easy for the user to understand. This makes it easy to verify whether the communication specifications have been generated correctly. Furthermore, errors in the communication specifications can be easily confirmed and corrected.

[0118] [Software implementation example] The functions of the communication specification generation device 101 (hereinafter referred to as the "device") are realized by a program for causing a computer to function as the device. The program causes the computer to function as each control block of the device (particularly each unit included in the control unit 1).

[0119] In this case, the device has at least one control device and at least one storage device as hardware for executing the program. The control device and storage device execute the program to realize each function described in the above embodiment.

[0120] The program may be non-transitory and may be recorded on one or more computer-readable recording media. The recording media may or may not be included in the device. In the latter case, the program may be supplied to the device via any wired or wireless transmission medium.

[0121] In addition, some or all of the functions of the control blocks can be realized by logic circuits. For example, an integrated circuit in which a logic circuit that functions as the control block is formed is also included in the scope of the present invention. In addition, the functions of each control block can be realized by, for example, a quantum computer.

[0122] Furthermore, each process described in the above embodiment may be executed by AI (Artificial Intelligence). In this case, the AI ​​may run on the control device or on another device (for example, an edge computer or a cloud server).

[0123] 〔summary〕 A communication specification generation device according to a first aspect of the present invention is a communication specification generation device that generates communication specifications for communicating command frames and response frames as frames, and includes: a frame extraction unit that extracts frames having a frame length equal to or greater than a predetermined frame length from communication log data acquired in communication performed by a target device for which the communication specification is to be generated; a header identification unit that identifies a header in the frame by sequentially comparing, from the beginning of the extracted frame, values ​​within a range determined by one of a plurality of different pre-established standard header lengths between two consecutive frames; and a combination identification unit that extracts a command code of the command frame and a response code of the response frame from the identified header based on position information about the positions of each code of the command frame and the response frame and size information about the size of the code, and identifies a corresponding combination of the command code and the response code from the extracted command code and the response code according to the communication status of the command frame and the response frame in the communication log data.

[0124] In the above configuration, frames having a certain frame length, such as command frames and response frames, are extracted from the communication log data as frames having a frame length equal to or greater than a predetermined frame length.

[0125] The header in a frame has the same value for commands and responses. Therefore, if the header values ​​of the command and response match within the range determined by the standard header length, it can be assumed that the position from the beginning of the frame determined by the standard header length is the end of the header. In this way, the header is identified. Also, if the values ​​of both headers do not match, it is possible that the standard header length does not indicate the end, so the standard header length is changed and the values ​​within the above range are compared.

[0126] Based on the location information and size information of the code in the identified header, the command code of the command frame and the response code of the response frame are extracted. Then, the combination of the command code and the response code is identified from the relationship between the exchange of the command frame and the response frame in the communication log data. The combination thus identified provides the communication specifications. Therefore, the communication specifications of a device whose communication specifications are unknown can be generated.

[0127] The communication specification generation device according to aspect 2 of the present invention may be configured in accordance with aspect 1, further comprising a display unit, an input unit that accepts input operations by a user, and a correction unit that displays the configuration of the command frame and the response frame in the created communication specification on the display unit and corrects the communication specification by changing the configuration in accordance with the input operation by the user accepted by the input unit.

[0128] In the above configuration, the created communication specifications are displayed, allowing the user to visually check the configurations of the command frame and the response frame. This allows the user to easily correct the communication specifications by checking and changing the configurations of the command frame and the response frame.

[0129] The communication specification generation device according to aspect 3 of the present invention may further include a verification unit that, in aspect 2, displays the acquired values ​​of the communication log data on the display unit so as to correspond to the created command frame and response frame, and highlights the displayed value when the displayed value differs from the value.

[0130] According to the above configuration, if the communication specifications are generated correctly, the value of the communication log data and the displayed value will match, whereas if the communication specifications are not generated correctly, the value of the communication log data and the displayed value will not match and the displayed value will be highlighted. This makes it possible to verify whether the communication specifications are generated correctly. Furthermore, errors in the communication specifications can be easily confirmed and corrected.

[0131] A communication specification generation device according to a fourth aspect of the present invention is any one of the first to third aspects, wherein the predetermined frame length, the standard header length, the position information, and the size information may be stored in a database.

[0132] According to the above configuration, the predetermined frame length, the reference data length, and the size information obtained from the past analysis results can be used to generate the communication specifications.

[0133] The communication specification generating device of aspect 5 of the present invention may further include a storage unit that stores information including the specified frame length, the standard header length, the position information, and the size information in the database based on the created communication specification or the corrected communication specification in aspect 4.

[0134] According to the above configuration, each time a new communication specification is generated or corrected, information based on the communication specification is accumulated in the database, thereby improving the accuracy of the generation and correction of the communication specification.

[0135] A communication specification generating device according to aspect 6 of the present invention may be configured in accordance with aspect 1, further comprising a command generating unit that generates an error command or an abnormal command based on the generated communication specification, a transmitting unit that transmits the error command or the abnormal command to the target device, and a frame extracting unit that extracts from the communication log data a frame of the error command or the abnormal command to the target device and a frame of an error response from the target device to the error command or the abnormal command.

[0136] According to the above configuration, it is possible to generate communication specifications for when an error or abnormality occurs in communication, thereby enabling the generation of communication specifications that assume communication exchanges with the target device that would not normally occur.

[0137] The communication specification generation device according to a seventh aspect of the present invention is in accordance with the first aspect and may further include an output unit that outputs the generated communication specification.

[0138] In the above configuration, the generated communication specifications can be output in various formats, allowing the communication specifications to be used effectively.

[0139] A communication specification generation method according to an eighth aspect of the present invention is a communication specification generation method for generating communication specifications for communicating command frames and response frames as frames, and includes: a frame extraction step of extracting frames having a frame length equal to or greater than a predetermined frame length from communication log data obtained in communication performed by a target device for which the communication specifications are to be generated; a header identification step of identifying a header in the frame by sequentially comparing, from the beginning of the extracted frame, values ​​within a range determined by one of a plurality of different pre-established standard header lengths between two consecutive frames; and a combination identification step of extracting a command code of the command frame and a response code of the response frame from the identified header based on position information about the position of each code of the command frame and the response frame and size information about the size of the code, and identifying a corresponding combination of the command code and the response code from the extracted command code and the response code according to the communication status of the command frame and the response frame in the communication log data.

[0140] As with the communication specification generation device described above, command codes and response codes are extracted from a header identified based on a frame extracted from communication log data, and a combination of these codes is identified based on the communication log data. This combination provides the communication specification. Therefore, it is possible to generate communication specifications for a device whose communication specification is unknown.

[0141] [Additional Notes] The present invention is not limited to the above-described embodiments, and various modifications are possible within the scope of the claims. Furthermore, embodiments obtained by appropriately combining the technical means disclosed in the respective embodiments are also included in the technical scope of the present invention. [Explanation of symbols]

[0142] 3 Display section 4 Input section 11 Frame Extraction Unit 12 Header Identification Part 13 Combination identification section 14 Correction unit 15 Preservation Department 16 Output section 17 Command Generation Unit 18 Communication unit (transmitter) 19 Verification Department 101 Communication specification generator 102 Communication specification information database (database) 103 Target Device

Claims

1. A communication specification generation device that generates communication specifications for communicating a command frame and a response frame as frames, comprising: a frame extraction unit that extracts frames having a frame length equal to or greater than a predetermined frame length from communication log data acquired in communication performed by a target device for which the communication specifications are to be generated; a header identifying unit that identifies a header in the frame by sequentially comparing values ​​within a range determined by one of a plurality of different predefined standard header lengths from the beginning of the extracted frame between two consecutive frames; a combination specifying unit that extracts a command code of the command frame and a response code of the response frame from the specified header based on position information about the positions of each code of the command frame and the response frame and size information about the sizes of the codes, and specifies a corresponding combination of the command code and the response code from the extracted command code and the response code in accordance with the communication status of the command frame and the response frame in the communication log data.

2. A display unit; an input unit that accepts an input operation by a user; 2. The communication specification generation device according to claim 1, further comprising: a correction unit that displays configurations of the command frame and the response frame in the created communication specification on the display unit, and corrects the communication specification by changing the configurations in accordance with the input operation by a user accepted by the input unit.

3. 3. The communication specification generation device according to claim 2, further comprising a verification unit that displays the acquired values ​​of the communication log data on the display unit so as to correspond to the created command frame and the created response frame, and highlights the displayed value when the displayed value differs from the value.

4. 4. The communication specification generating device according to claim 1, wherein the predetermined frame length, the standard header length, the position information, and the size information are stored in a database.

5. 5. The communication specification generating device according to claim 4, further comprising a storage unit that stores information including the predetermined frame length, the standard header length, the position information, and the size information in the database based on the generated communication specification or the corrected communication specification.

6. a command generation unit that generates an error command or an abnormal command based on the generated communication specification; a transmitter that transmits the error command or the abnormal command to the target device; 2. The communication specification generation device according to claim 1, wherein the frame extraction unit extracts from the communication log data a frame of the error command or the abnormal command to the target device and a frame of an error response from the target device to the error command or the abnormal command.

7. The communication specification generating device according to claim 1 , further comprising an output unit that outputs the generated communication specification.

8. A communication specification generation method for generating communication specifications for communicating a command frame and a response frame as frames, comprising: a frame extraction step of extracting frames having a frame length equal to or greater than a predetermined frame length from communication log data acquired in communication performed by a target device for which the communication specifications are to be generated; a header identifying step of identifying a header in the frame by sequentially comparing values ​​within a range determined by one of a plurality of different predefined standard header lengths from the beginning of the extracted frame between two consecutive frames; a combination specifying step of extracting a command code of the command frame and a response code of the response frame from the specified header based on position information about the positions of each code of the command frame and the response frame and size information about the sizes of the codes, and specifying a corresponding combination of the command code and the response code from the extracted command code and the response code in accordance with the communication status of the command frame and the response frame in the communication log data.

Images