Data creation device, protocol driver operation test system, and verification device

Abstract

To easily generate data for testing the operation of a protocol driver.SOLUTION: A PC (1) includes a data generation unit (3) which generates instruction data to be given to a simulator (22) of control equipment which transmits a response to a command transmitted based on the operation of a protocol driver for a programmable display unit to communicate with the control equipment. The data generation unit (3) includes: an extraction unit (311) which extracts test patterns corresponding to elements from a test pattern group, based on communication specification data including command / response specifications which are specifications of commands and responses corresponding to the control equipment and elements of the commands and responses, and on the test pattern group including various kinds of possible test patterns for a test; and a combination unit (312) which defines transmission patterns of a response from the simulator (22) with respect to the command by combining the test patterns with the command / response specifications.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a data creation device that creates data for testing the operation of a protocol driver, etc.

Background Art

[0002] A programmable display performs communication with a connected control device by performing processing defined by a protocol driver, which is a program for communication conforming to a communication protocol. In the development of a protocol driver, an operation test is performed to confirm that the protocol driver operates normally.

[0003] For example, Patent Document 1 discloses creating operation conditions for simulating to check the validity of the operation of a test communication control program. The operation conditions are described by a test implementer in a simple grammar based on an operation instruction simple language by an input / output device.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] However, in the technique disclosed in Patent Document 1, since a test implementer inputs operation conditions, it is not easy for a test implementer who does not have experience, knowledge, know-how, etc. to input operation conditions.

[0006] One aspect of the present invention aims to easily create data for testing the operation of a protocol driver.

Means for Solving the Problems

[0007] To solve the above problems, a data creation device according to one aspect of the present invention includes a creation unit that creates instruction data to be given to a simulator in order to operate a simulator that simulates a control device so as to send a response to a command sent in accordance with the operation of a protocol driver compliant with a communication protocol for a programmable display to communicate with the control device, the creation unit includes an extraction unit that extracts the test pattern corresponding to the element from the test pattern group based on a command-response specification which is the specification of the command and the response corresponding to the control device, and the elements of the command and the response, and a group of test patterns which includes various test patterns assumed for testing, and a combination unit that creates instruction data which defines the transmission pattern of the response that the simulator sends to the transmitted command by combining the test pattern and the command-response specification.

[0008] To solve the above problems, a data creation device according to another aspect of the present invention includes a creation unit that creates instruction data to be given to an operation program that operates a protocol driver compliant with a communication protocol for a programmable display to communicate with a control device, wherein the creation unit includes an extraction unit that extracts the test pattern corresponding to the element from the test pattern group based on a command-response specification which is a command and response specification corresponding to the control device, and communication specification data which includes the elements of the command and the response, and a group of test patterns which includes various test patterns assumed for testing, and a combination unit that creates instruction data which defines the transmission pattern of the command to be transmitted by the transmitting device by combining the test pattern and the command-response specification. [Effects of the Invention]

[0009] According to one aspect of the present invention, data for testing the operation of a protocol driver can be easily created. [Brief explanation of the drawing]

[0010] [Figure 1] This is a block diagram showing the configuration of a simulation system related to one embodiment of a device. [Figure 2] This block diagram shows the hardware configuration of the PC included in the above simulation system. [Figure 3] This figure shows the set of normal command codes and the corresponding normal response codes included in the test pattern set stored in the auxiliary storage device of the above PC. [Figure 4] This figure shows the normal range of read commands and their corresponding responses included in the above test pattern group. [Figure 5] This figure shows read commands that exceed the normal range and the corresponding error responses included in the above test pattern group. [Figure 6] This figure shows the registered codes and unregistered codes that are registered as test patterns in the above test pattern group. [Figure 7] This figure shows a test pattern included in the above set of test patterns where the number of bytes is abnormal. [Figure 8] This figure shows an example of a test pattern in the above test pattern group where the check code is abnormal. [Figure 9] The flowchart above shows the procedure for creating instruction data and behavior data using the PC. [Figure 10] This diagram shows how the instruction data is created based on the communication specification data and the above test pattern set. [Figure 11] This figure shows an example of the instruction data created above. [Modes for carrying out the invention]

[0011] [Embodiment] One embodiment of the present invention is described below based on Figures 1 to 11.

[0012] FIG. 1 is a block diagram showing the configuration of a simulation system 100 according to the present embodiment. FIG. 2 is a block diagram showing the hardware configuration of a PC included in the simulation system 100.

[0013] <Overview of the Simulation System> As shown in FIG. 1, the simulation system 100 includes a PC1 (data creation device) and a test system 2 (protocol driver operation test system). The simulation system 100 simulates various operations such as transmission of responses to commands transmitted by the protocol driver, processing of responses, etc. in order to test the operation of the created protocol driver.

[0014] The protocol driver is a communication program for a programmable display to communicate with a control device such as a PLC (Programmable Logic Controller), and complies with a communication protocol that defines the communication procedure. The communication protocol defines properties (attribute information) for each of the header part, body part, and footer part that constitute the communication frame.

[0015] PC1 is composed of a general-purpose computer device and functions as a data creation device that creates instruction data used in the test system 2. Specifically, PC1 creates driver instruction data as instruction data for operating the protocol driver in a transmission / reception device 21 (transmission device) described later. Also, PC1 creates simulator instruction data as instruction data for responding to commands transmitted from the transmission / reception device 21 in a simulator 22 described later. Further, PC1 creates behavior data that defines the behavior of the protocol driver in order to verify the behavior of the protocol driver by a verification device 23 in the test system 2.

[0016] The driver instruction data and the simulator instruction data are closely related and are inseparable due to the exchange of commands and responses in the instruction data. Therefore, the instruction data includes the driver instruction data and the simulator instruction data. Thus, the PC1 does not create the driver instruction data and the simulator instruction data separately, but creates instruction data in which both are mixed.

[0017] The test system 2 transmits and receives commands and responses between the transceiver 21 and the simulator 22 according to the above instruction data. In addition, the test system 2 verifies the behavior of the protocol driver by the verification device 23. The test system 2 includes the transceiver 21, the simulator 22, and the verification device 23.

[0018] The transceiver 21 transmits commands by operating a protocol driver for the programmable display to communicate with the control device, and processes responses from the simulator 22. The transceiver 21 is a general-purpose computer device (hereinafter referred to as "computer display") that functions equivalently to the programmable display when, for example, an application program that realizes the functions of the programmable display is installed.

[0019] Similar to the programmable display, the computer display has an environment for operating the protocol driver to be tested based on the screen data, and has functions such as the function of transmitting the above commands. The screen data is data for causing the programmable display to display a screen, and is created by a screen creation program.

[0020] The transmitting / receiving device 21 may be a computer display, but it is preferable to configure it as a general-purpose computer device (hereinafter referred to as "computer driver") that is specialized for the operation of the protocol driver and for executing a driver instruction program. The driver instruction program (operation program) processes data for commands to be sent to the protocol driver, data that specifies the specific processing content for responses from the simulator 22, and so on.

[0021] When testing with a computer display, the screen data used for the actual display on the programmable display is utilized, making it suitable for the final stage of protocol driver development. In contrast, the driver instruction program can realize the functions defined in the screen data. Specifically, it can request read and write operations to the device, and based on the read data, it can display the read data numerically or display bits ON / OFF based on the read bit data, according to a pre-set method. The computer driver and simulator 22 have a one-to-one command-response relationship, with a fixed response to a given command. Therefore, since work is mainly done on a PC during the development stage, testing can be efficiently performed in an environment where the driver instruction program is run based on the driver instruction data.

[0022] The simulator 22 simulates the functions of the control equipment by executing a simulation program on a general-purpose computer device; in other words, it simulates the control equipment. The simulator 22 transmits responses to commands sent from the transceiver 21 based on the simulator instruction data described above.

[0023] The verification device 23 verifies whether communication in accordance with the behavior data described above is taking place between the transceiver 21 (sender) and the simulator 22.

[0024] The transmitting / receiving device 21, simulator 22, and verification device 23 will be described in detail later.

[0025] In the test system 2, the transceiver 21, simulator 22, and verification device 23 each implement their respective functions by executing programs on general-purpose computer equipment. However, the test system 2 may also be configured to execute programs for implementing the functions of the transceiver 21, simulator 22, and verification device 23 on a single general-purpose computer equipment.

[0026] <PC Hardware Configuration> As shown in Figure 2, PC1 is a personal computer that implements a general-purpose OS (Operating System) and has an environment for running application programs as follows.

[0027] As shown in Figure 2, PC1 comprises a CPU (Central Processing Unit) 11, main memory 12, ROM (Read Only Memory) 13, auxiliary storage device 14, display panel 15, input device 16, and communication unit 17.

[0028] The CPU 11 is a processing unit that executes application programs under the management of the OS. Specifically, when executing an application program, the CPU 11 receives data from the auxiliary storage device 14, input device 16, etc., performs calculations or processing on the data, and outputs the results to the auxiliary storage device 14, display panel 15, etc.

[0029] Main memory 12 is the memory that constitutes the main storage device in PC1 and is composed of DRAM (Dynamic Random Access Memory). ROM 13 stores the OS as well as programs essential for the operation of PC1, such as the BIOS (Basic Input Output System) that is executed when PC1 starts up or resets.

[0030] The auxiliary storage device 14 is provided for storing various data, application programs, etc., that the PC1 should retain. The auxiliary storage device 14 is composed of HDDs (Hard Disk Drives), SSDs (Solid State Drives), etc.

[0031] The display panel 15 is provided to display screens for performing basic operations on the PC1, screens displayed as a result of application program execution, and so on.

[0032] The input device 16 is a device that accepts various types of input in response to user operations. The input device 16 may include a mouse, keyboard, touch panel, etc.

[0033] The communication unit 17 has the function of communicating with the test system 2.

[0034] <PC System Configuration> As shown in Figure 1, PC1 has a data creation unit 3. The data creation unit 3 creates the instruction data and behavior data described above. By having the data creation unit 3, PC1 functions as a data creation device.

[0035] The data creation unit 3 is a functional block that is realized when a data creation program, as an application program, is executed by the CPU 11. The data creation unit 3 has an instruction creation unit 31 (creation unit) to create the instruction data described above. The instruction creation unit 31 has an extraction unit 311 and a combination unit 312.

[0036] The extraction unit 311 is used in common to create simulator instruction data and driver instruction data. Specifically, the extraction unit 311 extracts test patterns corresponding to elements from the test pattern group based on the command-response specification, communication specification data including command and response elements, and the test pattern group. The command-response specification is the command and response specification corresponding to the control equipment. The test pattern group includes various test patterns assumed for testing.

[0037] The combination unit 312 creates simulator instruction data that defines the transmission pattern of the response that the simulator 22 sends in response to a transmitted command by combining the test pattern and the command-response specification. The combination unit 312 also creates driver instruction data that defines the transmission pattern of the command that the transceiver 21 sends by combining the test pattern and the command-response specification. The combination unit 312 stores the created instruction data in the auxiliary storage device 14.

[0038] The data creation unit 3 creates instruction data based on the abnormal patterns and command-response specifications included in the test pattern group. The data creation unit 3 also creates instruction data based on the abnormal and normal patterns included in the test pattern group and the command-response specifications. Here, the abnormal pattern is a test pattern that sends an abnormal response to a received normal command. The normal pattern is a test pattern that sends a normal response to a received normal command.

[0039] The data creation unit 3 may also display an item setting screen (not shown) on the display panel 15. The item setting screen is configured in a format where the test items to be executed from among the test items specified in the instruction data, and whether or not verification and result prediction for verification specified in the behavior data are necessary, can be selected using checkboxes. Basically, all tests are performed, but if you want to thoroughly test bug fixes or certain cases later, you can narrow down the test items on the item setting screen.

[0040] Here, we will explain the test pattern group. Figure 3 is a diagram showing the normal command code group and the normal response code group included in the test pattern group stored in the auxiliary storage device 14 of PC1. Figure 4 is a diagram showing the read command within the normal range and the response to it included in the above test pattern group. Figure 5 is a diagram showing the read command exceeding the normal range and the error response to it included in the above test pattern group. Figure 6 is a diagram showing the registered code that is registered as a test pattern in the above test pattern group and the unregistered code that is not registered. Figure 7 is a diagram showing the test pattern in the above test pattern group where the number of bytes is abnormal. Figure 8 is a diagram showing an example of a test pattern in the above test pattern group where the check code is abnormal.

[0041] The test pattern set is a database built, for example, on the auxiliary storage device 14, by including normal test patterns (normal patterns), error test patterns (error patterns), and abnormal test patterns (abnormal patterns).

[0042] As shown in Figure 3, a normal pattern includes a group of normal command codes consisting of multiple normal command codes and a group of normal response codes consisting of multiple normal response codes. As shown in Figure 4, a read command specifies the range of the address to read from and the number of data to read, which are associated with the normal command code. A normal response specifies the data returned by the control device in response to the read command and the number of bytes, which are associated with the normal response code. The number of bytes indicates how much data is available.

[0043] As a normal pattern, test patterns are provided for ranges such as addresses and the number of data points. For example, there is a pattern that tests whether the sum of the minimum address value and the maximum number of data points is within the address range. In this test pattern, for example, if the address range is D0000 to D1999, the number of words to read is 100, and a maximum of 256 words can be read, then the minimum address value is "D0000" and the maximum number of data points is "256". Reading 256 words from D1900 exceeds the address range and is therefore inappropriate.

[0044] Furthermore, the relationship between "maximum address value + 1 - minimum number of data" and "minimum number of data" is tested at the upper and lower limits near the limits of the normal range, such as whether an error is returned when reading the minimum number of data "1" for the address (D1999 + 1 - 1) = D1999. This test pattern verifies whether writing and reading can be done normally even when command parameters are set at the upper and lower limits. In the normal pattern, such a calculation formula is predefined.

[0045] As shown in Figure 5, the error pattern includes a read command that exceeds the normal range and an error response to that read command. Such error commands and error responses are the possible error commands and error responses that are specified in the protocol driver's specifications. For example, exceeding the address range, specifying a non-existent variable, or specifying a non-existent device address are errors defined in the protocol driver's specifications.

[0046] An abnormal pattern defines a response that would not normally be returned if the control device is functioning correctly. For example, if a device other than a PLC is used as the control device, and that device uses the same communication protocol as the PLC (or forcibly emulates the same communication protocol), it may be able to communicate with other devices using that protocol. If such a device does not fully support the PLC's communication specifications, communication that should not occur may occur. Also, with new PLC products, there is a suspicion of bugs, and in such cases, an abnormal response may be returned.

[0047] If an abnormal response occurs, the programmable display may hang up due to an abnormal response from the control equipment. As a result, the programmable display may not be able to display (monitor) the status of the control equipment on the screen, and the programmable display may not be operable on the screen. To recover the programmable display from the hung state, an attempt is made to restart only the programmable display by turning on the power, but since that power supply is not a separate power supply for the programmable display, it is necessary to turn on the power supply for the entire control system. This could lead to a serious situation where production must be temporarily stopped. To avoid such a situation, abnormal responses must be anticipated and verified. Abnormal patterns include abnormalities in command codes and response codes, numerical values, and check codes.

[0048] As shown in Figure 6, anomalies in command and response codes occur when an unregistered code is used for each registered code group. Since the control device (simulator 22) does not use unregistered codes, it is impossible for it to output such codes during normal operation. The behavior data defines the error handling, command retransmission, and other actions that the programmable indicator should take in response to such unregistered codes.

[0049] Numerical anomalies are patterns where the number of data points, byte count, etc., do not match the accompanying information within the frame. For example, in the example shown in Figure 7, if the number of data points "n" for data with 2 bytes is 10, the correct number of bytes in decimal is 20, but an anomaly occurs when a number other than 20 is used.

[0050] An anomaly in the check code is a pattern where the check code, which is normally included in the footer to detect and correct communication errors such as checksums, CRCs, and parity, does not match the calculated value in the actual frame. For example, the example shown in Figure 8 is a pattern where the calculated value within the checksum calculation range does not match the value of the check code. Programmable indicators need to be able to handle such anomaly responses without hanging up.

[0051] Anomaly patterns are defined based on an IID (Irregular ID), which is an ID specific to abnormal situations. These abnormal patterns include data out of range, response data length out of range, multiple response anomalies, variable name anomalies, response anomalies, response code anomalies, command code anomalies, and communication timing anomalies.

[0052] Here, the test pattern set includes patterns for the command and response element data (element data). This pattern is design data (design element data) and is managed based on a data-specific ID called DID (Design ID), and contains information representing the correspondence with abnormal patterns (IID), normal patterns, and error patterns. The pattern defines patterns such as command code, response code, data length, device code, device address, response subcode, response time, command subcode, error code, and transmission wait time. The same applies to normal patterns and error patterns, which are defined based on their respective unique IDs.

[0053] Next, I will explain the communication specifications data.

[0054] As described above, the communication specification data includes command-response specifications and command and response elements. The communication specification data can also utilize frame design data created separately by a protocol driver creation program. The frame design data includes design data for the header, body, and footer sections that constitute the communication frame, and in particular, the body section contains various information that forms the command and response.

[0055] Furthermore, the data creation unit 3 also has a specification creation unit 32, and the specification creation unit 32 may create the communication specification data. The specification creation unit 32 provides an input screen (not shown) for creating the communication specification as a user interface and displays it on the display panel 15. The specification creation unit 32 saves the created communication specification data to the auxiliary storage device 14.

[0056] In the input screen described above, elements such as the command code, address, and data length can be entered for the command; elements such as the code, data length, and data can be entered for the normal response; and elements such as the code, address range error, and data length error can be entered for the error response. Furthermore, the input screen also allows input of ranges such as command code range and response code range (element range specifications, i.e., command-response specifications), as well as abnormal patterns defined by the IID mentioned above.

[0057] When the specification creation unit 32 receives commands, responses, and element range specifications from the input screen, it checks whether the element data exists in the test pattern group. If the element data exists in the test pattern group, the specification creation unit 32 outputs the input command and response type, error response, element range specification, and DID number as communication specification data. If the element data does not exist in the test pattern group, and the specification creation unit 32 is instructed to add element data, it outputs the new DID number, the added element data, the command and response type, error response, and element range specification as communication specification data.

[0058] The specification creation unit 32 also specifies in the communication specification data the retransmission process and error display performed by the transceiver 21 when a response other than a normal response is transmitted from the simulator 22.

[0059] The data creation unit 3 includes a behavior creation unit 33 for creating the behavior data described above.

[0060] The behavior creation unit 33 creates behavior data based on the elements of the communication specification data and the response transmission pattern specified in the instruction data. The communication specification data also specifies the abnormal response error to be displayed and the command to be sent in response to the abnormal response error. The behavior creation unit 33 creates the behavior of the protocol driver regarding the abnormal response based on the elements of the abnormal response from such communication specification data and the transmission pattern specified in the instruction data. The behavior creation unit 33 saves the created behavior data to the auxiliary storage device 14.

[0061] <Creation of instruction data and behavior data using a PC> Figure 9 is a flowchart showing the procedure for creating instruction data and behavior data by PC1. Figure 10 shows the creation of instruction data based on communication specification data and test pattern sets. Figure 11 shows an example of the created instruction data.

[0062] As shown in Figure 9, first, the extraction unit 311 of the data creation unit 3 reads the DID number included in the element data of the communication specification data (step S1). As shown in Figure 10, the extraction unit 311 reads the DID number, such as DID1, which represents the command code, from the element data ED.

[0063] Next, the extraction unit 311 determines whether the read DID number is included in the test pattern group (step S2). In step S2, if the extraction unit 311 determines that the DID number is included in the test pattern group (YES), it reads the test pattern corresponding to the DID number from the test pattern group (step S3).

[0064] Next, the combination unit 312 creates instruction data from the test patterns corresponding to the command-response elements (step S4). In creating the instruction data, the combination unit 312 creates the instruction data by combining the command-response specification CRS and the test patterns read by the extraction unit 311, as shown in Figure 10. Note that, for convenience, the command-response specification CRS is not shown in Figure 10.

[0065] Furthermore, the behavior creation unit 33 creates behavior data from the communication specification data and the instruction data created as described above (step S5). In creating the behavior data, the behavior creation unit 33 obtains, for example, an abnormal response code as element data ED of the communication specification data and a transmission pattern for sending a response that indicates an abnormal response code as a transmission pattern, and combines these. In addition, the behavior creation unit 33 specifies, for example, in the behavior data that the transceiver 21 resends a read command in response to the above response.

[0066] Then, the data creation unit 3 determines whether or not the following communication specification data format exists (step S6). In step S6, if the data creation unit 3 determines that the following communication specification data format does not exist (NO), it terminates the process. Also, in step S6, if the data creation unit 3 determines that the following communication specification data format exists (YES), it returns to step S1.

[0067] Furthermore, in step S2, if the extraction unit 311 determines that the DID number is not included in the test pattern group (NO), it determines whether or not to skip the corresponding DID number (step S7). In step S7, if the extraction unit 311 determines to skip the corresponding DID number (YES), it proceeds to step S6. Also in step S7, if the extraction unit 311 determines not to skip the corresponding DID number (NO), it displays an error on the display panel 15 (step S8) and ends the process.

[0068] As shown in Figure 11, the instruction data created in this manner associates instruction items such as "Receive read command" with commands and responses.

[0069] As described above, PC1, by including the instruction creation unit 31 of the data creation unit 3, can create instruction data for testing whether the protocol driver operates correctly in response to the simulator 22's response. Furthermore, the instruction creation unit 31 enables the creation of instruction data without requiring experience, knowledge, or know-how.

[0070] Furthermore, when a control device receives a normal command sent by the protocol driver, it sends a normal response, but it does not send an abnormal command unless there is a bug or other abnormality. For this reason, it was difficult to perform verification assuming that an abnormality occurred in the control device. In contrast, with the instruction creation unit 31, instruction data is created based on abnormal patterns, so it is possible to perform verification assuming that an abnormality occurs in the control device.

[0071] Furthermore, there are protocol drivers that can be considered to be operating correctly if they receive a normal response to a normal command. In contrast, some protocol drivers, due to various factors, may have a mix of situations where they should send a normal response to a normal command and situations where they should send an abnormal response to a normal command. According to the instruction creation unit 31, not only can such protocol drivers be properly verified, but potential defects in the protocol driver, such as bugs, can also be found.

[0072] Potential defects include not only relatively simple defects, but also internally latent defects that do not occur in tests with only normal responses, or in tests with only abnormal responses. With the above configuration, it is possible to detect such internally latent defects that cannot be found with conventional tests.

[0073] Furthermore, by including the behavior creation unit 33 of the data creation unit 3, PC1 can verify whether the protocol driver operates correctly in response to the simulator 22's response based on the behavior data. Specifically, it verifies whether error code processing, command retransmission processing, etc., are performed correctly.

[0074] <Testing using instruction data> In test system 2, the transceiver 21 acquires instruction data as driver instruction data from the auxiliary storage device 14 and transmits a command by operating the protocol driver according to the instruction data. Meanwhile, in test system 2, the simulator 22 acquires instruction data as simulator instruction data from the auxiliary storage device 14 and, upon receiving a transmitted command, transmits a response corresponding to the command based on the instruction data. In response, the transceiver 21 processes the command based on the instruction data.

[0075] The transceiver 21 outputs and saves error log data (error records) for errors that occur in the protocol driver, specifically errors recognized by the transceiver 21 through error responses or abnormal responses sent from the simulator 22. On the other hand, the simulator 22 outputs and saves communication log data (communication records) for communication that takes place between the transceiver 21 and the simulator 22, such as sending a response to a received command.

[0076] Test system 2 allows for the transmission of normal responses to normal commands and error responses to error commands, as was done conventionally. Furthermore, in test system 2, the transceiver 21 executes the aforementioned driver instruction program based on driver instruction data created based on the abnormal pattern. This makes it possible to test normal abnormal cases such as command code abnormalities and out-of-range address cases, which cannot be performed in communication tests using the programmable display of the actual device. Specifically, the driver instruction program performs the above tests by directly calling the protocol driver interface.

[0077] When using the actual programmable display, general abnormal condition tests, such as error checking (timeout errors, response code abnormal errors), which can be performed in the simulator 22, are conducted. In contrast, the transceiver 21 that executes the driver instruction program can perform tests that result in abnormalities requested by the programmable display, such as command code abnormalities, out-of-range address conditions, and data length exceeding limits.

[0078] <Verification using behavioral data> In test system 2, the verification device 23 acquires behavioral data from the auxiliary storage device 14 and verifies the communication between the transceiver 21 and the simulator 22 according to the behavioral data. The verification device 23 has a verification unit 231 for verification. The verification unit 231 verifies whether communication according to the behavioral data is taking place between the transceiver 21 (sender) which sends commands by operating a protocol driver and the simulator 22.

[0079] Specifically, the verification unit 231 performs verification by checking whether each of the behaviors defined in the behavior data is being performed, based on the error log data acquired from the transceiver 21 and the communication log data acquired from the simulator 22. The communication log data includes the contents of commands and responses, etc. The error log data includes the contents of error codes. The verification unit 231 generates verification data as a result of the verification based on this communication log data and error log data.

[0080] Here, the communication log data is the command and response data (line data) between the transceiver 21 and the simulator 22. For this reason, data analyzed by a protocol analyzer on the line may be used as the communication log data, or, if the test system 2 consists of a single computer device, the command and response logs may be recorded on that computer device.

[0081] The verification data includes information about the test behavior, specifically the content of the test, information about errors that should occur in the transceiver 21, and information about whether the transceiver 21 resent a command in response to an error. The occurrence of an error code can be determined from the error log data. For example, if the verification data includes information about an error such as "Display Error0x2BA," and the transceiver 21 generates an error code for that information, then the result obtained is as specified in the behavior data. The verification unit 231 records the result in the verification data.

[0082] Furthermore, the verification unit 231 determines, based on the communication log data, whether a command in response to an error has been retransmitted from the transceiver 21. If the communication log data indicates that an abnormal response was returned in response to the transmission of a command, and that the transceiver 21 has retransmitted the command in response, then the result is as specified in the behavior data. The verification unit 231 records this result in the verification data.

[0083] As described above, the test system 2, equipped with a verification device 23, performs verification based on communication log data and error log data obtained in the communication between the transceiver 21 and the simulator 22, which operates according to the instruction data. This allows for highly accurate verification of the results of the protocol driver operation test.

[0084] [Examples of implementation using software] The functions of PC1 can be realized by a program that enables PC1 to function as a data creation device. Specifically, this program is a program that enables PC1 to function as a data creation unit 3.

[0085] In this case, PC1 has at least one CPU 11 and at least one main memory 12 as hardware for executing the above program. By executing the above program using the CPU 11 and main memory 12, each of the functions described in the above embodiment is realized.

[0086] The above program may be recorded on one or more computer-readable recording media, not temporary ones. This recording media may or may not be present on PC1. In the latter case, the program may be supplied to the device via any wired or wireless transmission medium.

[0087] 〔summary〕 A data creation device according to aspect 1 of the present invention includes a creation unit that creates instruction data to be given to a simulator in order to operate a simulator that simulates a control device so as to send a response to a command sent in accordance with the operation of a protocol driver compliant with a communication protocol for a programmable display to communicate with the control device, the creation unit includes an extraction unit that extracts the test pattern corresponding to the element from the test pattern group based on a command-response specification which is the specification of the command and the response corresponding to the control device, and the elements of the command and the response, and a group of test patterns which includes various test patterns assumed for testing, and a combination unit that creates instruction data which defines the transmission pattern of the response that the simulator sends to the transmitted command by combining the test pattern and the command-response specification.

[0088] With the above configuration, it is possible to test whether the protocol driver operates correctly in response to the simulator's response. Furthermore, the creation unit allows for the creation of instruction data without requiring experience, knowledge, or know-how.

[0089] In the data creation apparatus according to embodiment 2 of the present invention, in embodiment 1, the creation unit may create the instruction data based on the abnormal pattern included in the test pattern group, which transmits an abnormal response to a received normal command, and the command-response specification.

[0090] When a control device receives a normal command sent by the protocol driver, it sends a normal response. However, unless there is a bug or other abnormality, it will not send an abnormal command. Therefore, it was difficult to perform verification assuming a malfunction in the control device. In contrast, with the above configuration, since the instruction data is created based on abnormal patterns, it becomes possible to perform verification assuming a malfunction in the control device.

[0091] In the data creation apparatus according to embodiment 3 of the present invention, in embodiment 2, the creation unit may create the instruction data based on the abnormal pattern included in the test pattern group, the normal pattern for transmitting a normal response to the received normal command, and the command-response specification.

[0092] With the above configuration, it is possible to properly verify protocol drivers where, due to various factors as described above, there are cases where a normal response should be sent to a normal command and cases where an abnormal response should be sent to a normal command. Furthermore, it is possible to detect potential defects in the protocol driver as described above.

[0093] A test system according to aspect 4 of the present invention includes a simulator that simulates the control device to send a response to a command transmitted by the protocol driver operating in accordance with the instruction data created by a data creation device in any of aspects 1 to 3.

[0094] With the above configuration, it is possible to test whether the protocol driver works correctly in response to the simulator's response.

[0095] In any of embodiments 1 to 3, the data creation device according to embodiment 5 of the present invention may have the creation unit create behavior data that defines the behavior of the protocol driver based on the elements of the communication specification data and the instruction data.

[0096] With the above configuration, it is possible to verify whether the protocol driver operates correctly in response to the simulator's response based on behavioral data. Specifically, it verifies whether error code handling, command retransmission, and other processes are performed correctly.

[0097] A verification device according to aspect 6 of the present invention includes a verification unit that verifies whether communication in accordance with the behavior data created by the data creation device of aspect 5 is taking place between a source that transmits the command by operating the protocol driver and the simulator, and the verification unit verifies whether each of the behaviors defined in the behavior data is taking place based on the communication record of the communication taken between the source and the simulator and the error record of the error recognized by the source by the error response or abnormal response transmitted from the simulator.

[0098] According to the above configuration, verification is performed based on communication records and error records obtained during communication between the source and the simulator, which operates according to the instruction data created by the data creation device. This allows for highly accurate verification of the results of the protocol driver's operation test.

[0099] A data creation device according to aspect 7 of the present invention includes a creation unit that creates instruction data to be given to an operation program that operates a protocol driver compliant with a communication protocol for a programmable display to communicate with a control device, wherein the creation unit includes an extraction unit that extracts the test pattern corresponding to the element from the test pattern group based on a command-response specification which is a command and response specification corresponding to the control device, and the elements of the command and the response, and a group of test patterns which includes various test patterns assumed for testing, and a combination unit that creates instruction data which defines the transmission pattern of the command to be transmitted by the transmitting device by combining the test pattern and the command-response specification.

[0100] According to the above configuration, based on the instruction data, it is possible to generate and transmit commands that have abnormal command patterns, such as abnormal commands and abnormal requests, which cannot be conventionally represented by the above transmitting device.

[0101] A test system according to aspect 8 of the present invention includes a transmitting device that causes the protocol driver to send the command according to the instruction data created by the data creation device of aspect 7.

[0102] According to the above configuration, the transmitting device can generate and transmit commands such as abnormal commands and abnormal requests by operating a protocol driver based on instruction data.

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

[0104] 1 PC (Data Creation Device) 2. Test System (Protocol Driver Operation Test System) 21. Transmitting and receiving equipment (sender, transmitter) 22 Simulators 23 Verification device 31 Instruction Creation Department (Creation Department) 311 Extraction part 312 Combination section

Claims

1. The system includes a creation unit that creates instruction data to be given to a simulator in order to operate a simulator that simulates a control device, such that the simulator sends a response to a command sent in accordance with the operation of a protocol driver compliant with a communication protocol for a programmable display to communicate with the control device, The creation unit includes a command-response specification, which is the specification of the command and response corresponding to the control device, and communication specification data including the elements of the command and response, and a group of test patterns including various test patterns assumed for testing, and an extraction unit that extracts the test pattern corresponding to the element from the group of test patterns. A data creation device characterized by having a combination unit that creates instruction data defining the transmission pattern of the response that the simulator transmits in response to the transmitted command by combining the test pattern and the command-response specification.

2. The data creation device according to claim 1, characterized in that the creation unit creates the instruction data based on the abnormal pattern included in the test pattern group, which transmits an abnormal response to a received normal command, and the command response specification.

3. The data creation device according to claim 2, characterized in that the creation unit creates the instruction data based on the abnormal pattern and the normal pattern that transmits a normal response to the received normal command, which are included in the test pattern group, and the command response specification.

4. A protocol driver operation test system characterized by comprising a simulator that simulates the control device to send a response to a command transmitted by the protocol driver operating in accordance with the instruction data created by the data creation device according to any one of claims 1 to 3.

5. The data creation device according to any one of claims 1 to 3, characterized in that the creation unit creates behavior data that defines the behavior of the protocol driver based on the elements of the communication specification data and the instruction data.

6. The system includes a verification unit that verifies whether communication in accordance with the behavior data created by the data creation device described in claim 5 is taking place between the source that transmits the command by operating the protocol driver and the simulator, The verification device is characterized in that the verification unit performs verification by checking whether each of the behaviors defined in the behavior data is being performed based on the communication record of the communication that took place between the source and the simulator, and the error record of the error recognized by the source based on the error response or abnormal response transmitted from the simulator.

7. The programmable display unit includes a creation unit that creates instruction data to be given to operate the protocol driver, which is compliant with a communication protocol, for the programmable display unit to communicate with the control device. The creation unit includes a command-response specification which is a command and response specification corresponding to the control device, communication specification data which includes the elements of the command and the response, and a group of test patterns which includes various test patterns assumed for testing, and an extraction unit which extracts the test patterns corresponding to the elements from the group of test patterns. A data creation device characterized by having a combination unit that creates instruction data defining the transmission pattern of the command to be transmitted by the transmitting device by combining the test pattern and the command-response specification.

8. A protocol driver operation test system characterized by comprising a transmitting device that causes the protocol driver to transmit the command according to the instruction data created by the data creation device described in claim 7.

Images