JP2010015240A - Verification system and verification device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To make it possible to extend versatility, and to easily and accurately achieve verification in a verification system and a verification device for verifying the operation of a program to be executed in a device. <P>SOLUTION: Test specification showing a verification method can be created by an examiner so as to be visually recognizable, for example, in the format of a sequence figure through a UML modeling tool 50 (tool 50). The information showing a sequence figure T20 created by the examiner through the tool 50 is converted into a test script T22 recognizable and executable by a CAN bus monitor 52 by the generation function of a script in the tool 50. The CAN bus monitor 52 monitors the operation of an ECU 54 as the object of verification, and determines whether or not the actual operation of the ECU 54 is matched with the test specifications shown by the test script T22, and outputs a test report T24 showing the determination result to the outside. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a verification system and a verification apparatus for verifying the operation of a program executed in the apparatus.

Conventionally, as a system for verifying the operation of a program executed in an apparatus, for example, a verification system as described in Patent Document 1 is known.
The verification system of Patent Document 1 embeds a description representing a measurement point in a program to be verified, and whether or not the elapsed time from one measurement point to another measurement point matches the design value (within an allowable range). It is verified whether or not the operation of the program is normal.
JP 2002-108656 A

  However, in the verification system of Patent Document 1, since a description representing a measurement point is embedded in a program to be verified, for example, processing time (overhead) required for reading the description may occur. For this reason, in some cases, it is necessary to consider the overhead in the verification result (elapsed time from one measurement point to another measurement point), and the verification is complicated. In addition, the verification result may be inaccurate.

Also, depending on the type of program, there are cases where the description representing the measurement point cannot be used as it is, and there is a problem in terms of versatility.
Furthermore, among communication devices connected to a network, among other devices, it is a problem whether or not the contents of signals (messages) exchanged with the communication device match design values (specifications).

  In this respect, in the verification system disclosed in Patent Document 1, an elapsed time from a certain measurement point on the program installed in the communication device to another measurement point (in other words, a time required for a certain process in the communication device) is designed. Although it is possible to verify whether the value matches the value (whether it is within the allowable range), whether the content of the signal (message) exchanged in the communication device matches the design value (specification) The points to be verified are not considered. For this reason, the verification system of patent document 1 is unsuitable for verification of the program mounted in the communication apparatus on a network, and the improvement of versatility was desired.

  The present invention has been made in view of these problems, and in a verification system and a verification apparatus for verifying the operation of a program executed in the apparatus, it is possible to expand versatility and perform verification more easily and accurately. For the purpose.

  In order to achieve the above object, the invention according to claim 1 includes a monitoring device that monitors the behavior of a device (hereinafter referred to as a verification target device) on which a program to be verified is installed. A verification system that verifies the operation of a program based on a monitoring result, and includes a model generation unit, a script conversion unit, a script interpretation unit, a pass / fail determination unit, and a determination result output unit.

  The model generation means generates a model representing the behavior that the verification target device should behave (hereinafter referred to as a behavior model) based on a user input. In other words, the user can easily generate the behavior that the verification target device should behave in the model format. The behavior model is used for verification of the verification target device (that is, verification of the operation of the program executed in the verification target device). If the verification target device operates according to the behavior model, the behavior model is determined to be acceptable. If the verification target apparatus does not operate as described above, it can be determined that the apparatus is rejected. In addition, as the behavior model format, various formats such as a flow diagram format representing an operation flow and a sequence diagram format representing a message flow between objects in time series can be applied. The user may select an appropriate behavior model format according to the verification method.

  Then, the behavior that the verification target device should behave is represented by a model, which makes it easy for the user and a third party to understand. For example, it is easier for a user or a third party to understand a model than to analyze and understand a program sequence. For this reason, the man-hour at the time of verification can be reduced.

  Next, the script conversion unit converts the behavior model generated by the model generation unit into a script. A script is a simple program that can be easily executed on a computer by automating or omitting the conversion to machine language.

Then, the script generated by the conversion by the script conversion means is interpreted by the script interpretation means.
In other words, a behavior model that is easy for the user to recognize is converted to a script that can be recognized by the verification system (which can be recognized by the computer in the verification system) and interpreted. There is no need to generate. For this reason, a user's effort can be saved. Further, compared with the case where the user himself / herself writes a script, the possibility of an error in the script description can be reduced.

  Then, the pass / fail determination means determines the suitability of the program operation based on whether the actual behavior of the verification target device based on the monitoring result of the monitoring device matches the behavior represented by the interpretation result of the script interpretation means, The result output means outputs information representing the determination result of the pass / fail determination means.

  According to this, the user refers to the determination result output by the determination result output unit to determine whether or not the verification target device is operating according to the behavior that the verification target device should behave. Appropriateness of the operation of the program executed in the target device can be easily grasped. For example, there is a method in which the user himself / herself analyzes the operation log of the verification target device to verify the appropriateness of the behavior of the verification target device (appropriateness of the operation of the program), but such trouble can be saved.

  Thus, according to the verification system of claim 1, the operation of the program executed in the apparatus can be easily verified. Further, since there is no need to change the verification target program (for example, a verification processing program is embedded in the verification target program), the verification can be performed accurately. Furthermore, it becomes unnecessary to worry about the type of program to be verified. That is, verification is executed regardless of the type of program to be verified.

  Next, the verification system according to claim 2 is the verification system according to claim 1, wherein the verification target device is a device connected to a network and transmitting / receiving a signal to / from a communication device on the network. Is a database that stores information on at least a signal to be transmitted / received to / from a communication device in the verification target device (hereinafter referred to as a transmission / reception signal) and stores a logical name representing the content of the transmission / reception signal for each of the transmission / reception signals The model generation means includes a behavior model by referring to a database and using a logical name of a transmission / reception signal.

  According to the verification system of the second aspect, in the behavior model, the transmission / reception signal to be transmitted / received in the verification target device is represented by a logical name representing the content of the transmission / reception signal. For this reason, it becomes easy for the user or a third party to grasp the contents of the transmitted / received signal, and consequently the contents of the behavior model are easy to understand. That is, the readability of the behavior model is improved. Therefore, it becomes possible to reduce the man-hour (time) for the user or a third party to confirm or verify the contents of the behavior model, and consequently, the man-hour for verification can be reduced.

  Next, the verification system according to claim 3 is characterized in that, in the verification system according to claim 2, the script conversion means refers to the database and generates a script using the logical name of the transmission / reception signal.

  According to such a verification system of claim 3, in the script, a description (program) representing a transmission / reception signal to be transmitted / received in the verification target apparatus is represented by a logical name representing the content of the transmission / reception signal. . For this reason, the contents of the script are easy to understand for the user or a third party. That is, the readability of the script is improved. Therefore, the man-hour (time) for a user or a third party to confirm or verify the contents of the script can be reduced.

  Next, a verification system according to a fourth aspect is the verification system according to the first to third aspects, wherein the model generation means is a model (hereinafter referred to as a condition) that represents a condition (hereinafter referred to as an environmental condition) about the operating environment of the verification target device. (Referred to as a model) is generated on the basis of a user input, and the script conversion means includes a condition script conversion means for converting the condition model generated by the condition model generation means into a script. The monitoring device includes a condition reproduction unit that reproduces the environmental condition based on the script generated by the conversion by the condition script conversion unit, and the behavior of the verification target device when the environmental condition is reproduced by the condition reproduction unit. It is characterized by monitoring.

  Specifically, examples of the operating environment include a load on the CPU of the apparatus and a traffic amount (communication amount) of the network. In the verification system according to the fourth aspect, a desired condition is set for such an operating environment, and the behavior that the apparatus should behave under can be verified. Therefore, it is possible to verify the behavior that the device should behave under various operating environments. In other words, the operation of the program can be verified under various conditions. For this reason, the operation of the program can be verified more precisely.

  Next, the invention according to claim 5 is a verification device that is connected to a device (hereinafter referred to as a verification target device) that implements a verification target program, and that verifies the operation of the program in the verification target device. Generated by a monitoring means for monitoring the behavior of the target device, a model generation means for generating a model representing the behavior that the verification target device should behave on (hereinafter referred to as a behavior model), and a model generation means. Script conversion means for converting a behavior model into a script, script interpretation means for interpreting a script generated by the script conversion means, and actual behavior of the verification target device based on the monitoring result of the monitoring means is script interpretation means. Pass / fail judgment means for judging the suitability of the program operation based on whether or not it matches the behavior represented by the interpretation result of It is characterized in that comprises a judgment result output means for outputting information indicating the determination result of the means.

  According to such a verification apparatus, the same effect as described in claim 1 can be obtained.

Embodiments of the present invention will be described below with reference to the drawings.
[First Embodiment]
First, the first embodiment will be described.

FIG. 1 is a schematic configuration diagram of a verification system 1 according to the first embodiment.
The verification system 1 of the first embodiment is for verifying the operation of a program (software) installed in the test target communication device 14. The test target communication device 14 is connected to a network (not shown) and configured to be able to communicate with devices on the network.

  Specifically, the verification system 1 is connected to the test target communication device 14 so as to be communicable, and monitors the operation (and the network state) of the test target communication device 14. , And a PC 10 that is communicably connected to the PC 12.

  The PC 10 is mainly configured by a personal computer main body 10a in which a CPU, a main storage device, and the like (all of which are not shown) are built in a housing, an input device 10b including a keyboard, a mouse, and the like, and a display 10c. The Since the internal configuration of the personal computer main body 10a is well known, detailed description thereof is omitted here. Detailed descriptions of other PCs are also omitted.

  Specifically, the PC 12 monitors signals transmitted and received in the test target communication device 14 and monitors the status of various processes executed in the test target communication device 14.

  Next, the PC 10 includes a design drawing drawing tool 40 for the user to draw a drawing (for example, a sequence diagram) representing the behavior to be tested by the test target communication device 14 via the input device 10b, and the design drawing drawing tool. And a test script generation tool 42 that generates a script that can be recognized by the PC 12 from a drawing input via 40. Specifically, the design drawing drawing tool 40 and the test script generation tool 42 are applications that operate on the PC 10. In the PC 10, a script T2 generated by the test script generation tool 42 (hereinafter also referred to as a test script) T2 is output to the PC 12.

  The PC 12 includes a test script interpretation tool 44 that interprets (recognizes) the test script T2 generated by the test script generation tool 42 in the PC 10. The test script interpretation tool 44 is specifically an application that runs on the PC 12.

The outline of the verification system 1 will be further described with reference to FIG.
FIG. 2 is a conceptual diagram showing a verification flow (verification method) in the verification system 1. Note that blocks having the same configuration as in FIG. 1 are denoted by the same reference numerals as in FIG.

First, a tester who is a subject of verification uses the design drawing drawing tool 40 to input a behavior (hereinafter also referred to as a test specification) that the test target communication device 14 should behave.
In the present embodiment, as a test specification, for example, a communication procedure to be executed in the test target communication device 14 (more specifically, content of a signal to be transmitted / received in the test target communication device 14 and timing of transmission / reception) is input. Is done. For example, the test specifications are described in the form of a sequence diagram that visually describes the signal contents and signal exchange. This point will be described later with reference to FIG.

  A drawing (design drawing T10 in FIG. 2) representing a test specification input by the user using the design drawing drawing tool 40 is output to the outside by the design drawing drawing tool 40. Specifically, the design drawing T10 is displayed on the display 10c.

The contents (validity etc.) of the design drawing T10 displayed on the display 10c by the design drawing drawing tool 40 are checked by a third party (confirmer).
The design drawing T10 is checked by the confirmer and then input to the test script generation tool 42. Specifically, the design drawing T <b> 10 is input to the test script generation tool 42 when the tester or the confirmer inputs a predetermined command via the input device 10 b of the PC 10. That is, data representing the design drawing T10 is passed from the design drawing drawing tool 40 to the test script generation tool 42.

  The test script generation tool 42 generates a script (hereinafter referred to as a test script) T2 representing the input design drawing T10 and outputs it to the outside. Specifically, the test script T2 is displayed on the display 10c. A test script T2 is obtained by replacing the design drawing T10 with a form recognizable by the computer (PC 10). More specifically, the test script T2 is a simple program that can be easily executed on a computer by automating or omitting the conversion to machine language.

The test script T2 generated by the test script generation tool 42 is input to the test script interpretation tool 44.
The test script interpretation tool 44 is a program (application) that cooperates with the communication monitoring device 46 (corresponding to the PC 12 in FIG. 1). In other words, the application operates on the communication monitoring device 46.

  The communication monitoring device 46 monitors the state of the test target communication device 14 and the network to which the test target communication device 14 is connected. More specifically, signals (messages) transmitted and received in the test target communication device 14 and traffic (communication amount) on the network are monitored. Then, the communication monitoring device 46 outputs the communication log T16 in the test target communication device 14 to the outside. Specifically, the communication log T16 is displayed on a display included in the communication monitoring device 46.

  On the other hand, the test script interpretation tool 44 is based on the monitoring result of the communication monitoring device 46 and the test script T2, and the actual operation of the test target communication device 14, in other words, the operation of the program installed in the test target communication device 14 is: It is determined whether or not the test specification represented by the test script T2 is met. For example, it is determined whether the content of a signal (message) transmitted / received in the test target communication device 14 and the transmission / reception time (timing or period) match the test specification.

  Then, the test script interpretation tool 44 outputs a test report T14 indicating whether or not the actual operation of the test target communication device 14 matches the test specification represented by the test script T2. Specifically, the test report T14 is displayed on a display provided in a device (here, the communication monitoring device 46) on which the test script interpretation tool 44 is mounted.

  Here, a more specific embodiment to which the present verification system 1 is applied will be described with reference to FIG. FIG. 3 is a diagram showing an example in which the present verification system 1 is applied to a vehicle network.

  In FIG. 3, specifically, an electronic control device (hereinafter referred to as an ECU) 54 connected to a CAN (Controller Area Network) as an in-vehicle LAN is a verification target (in other words, a program implemented in the ECU 54). To be verified).

  Next, the UML (Unified Modeling Language) modeling tool 50 corresponds to the design drawing drawing tool 40 of FIG. 1 or FIG. 2, and the tester uses the UML modeling tool 50 to draw a drawing representing the test specification. input. More specifically, the UML modeling tool 50 is installed in a computer (not shown), and the tester can input a drawing representing the test specification using an input device in the computer.

  UML is a standardized object-oriented modeling concept and its notation, and is a tool for system modeling. There are various types of diagrams generated in modeling using UML. For example, describe what actors (external to the system that act on the system) exist for the system. A use case diagram describing how each actor acts and how the system responds to it, a class diagram describing the static structure of the system, and signals (messages) between objects in the system There is a sequence diagram describing the exchanges.

  In this example, the content of a signal (message) to be transmitted / received in the ECU 54 and the transmission / reception time (timing or period) are represented as test specifications by the format of the sequence diagram. The sequence diagram T20 generated via the UML modeling tool 50 is output so as to be visible to the outside. Specifically, it is displayed on a display in a computer (not shown) on which the UML modeling tool 50 is mounted. Then, the contents (validity etc.) of the sequence diagram T20 are checked by the confirmer.

  Here, the function of converting the test specification (sequence diagram) into a script based on the test specification (sequence diagram) input by the tester via the UML modeling tool 50 is an extended function (added to the UML modeling tool 50). Provided as an add-on). That is, the test specification (sequence diagram) generated by the UML modeling tool 50 is converted into a script on a computer (not shown) on which the UML modeling tool 50 is mounted.

  A script (hereinafter also referred to as a test script) T22 generated by the extended function of the UML modeling tool 50 is output so as to be visible to the outside. Specifically, it is displayed on a display in a computer (not shown) on which the UML modeling tool 50 is mounted.

  Next, the CAN bus monitor 52 monitors the state of the ECU 54 and the CAN, and corresponds to the communication monitoring device 46 in FIG. 2 or the PC 12 in FIG. The test script T22 is input from the UML modeling tool 50 to the CAN bus monitor 52.

  The CAN bus monitor 52 includes (installs) a script interpreter. The script interpreter is software that is executed while converting source code described in a predetermined programming language into a format (object code) that can be executed by a computer. In other words, it is a tool that interprets and executes scripts.

  Then, the CAN bus monitor 52 is based on the monitoring results of the state of the ECU 54 and the CAN and the contents of the test script T22, and the actual operation of the ECU 54 (the operation of the program installed in the ECU 54) is represented by the test specification represented by the test script T22. It is determined whether or not it matches. Then, the CAN bus monitor 52 outputs a test report T24 representing the determination result to the outside so as to be visible. For example, it is displayed on a predetermined display. The CAN bus monitor 52 outputs the communication log T26 in the ECU 54 to the outside.

Next, the effect | action of this embodiment is demonstrated using FIG.
In the verification system 1, when verifying the operation of the ECU 54 (the operation of a program installed in the ECU 54), first, a test specification representing the verification method is defined. In this example, as shown in FIG. 4 (a), "If the CAN bus monitor 52 receives the message B from the ECU 54 within 10ms after the CAN bus monitor 52 transmits the message A to the ECU 54, the test is passed. ”, A test specification is defined.

The tester creates (inputs) a drawing (for example, a sequence diagram) representing the test specification shown in FIG. 4A via the UML modeling tool 50.
FIG. 4B shows a specific example of a sequence diagram T20 expressing the test specification of FIG. In the sequence diagram T20 of FIG. 4B, the message A transmitted from the CAN bus monitor 52 to the ECU 54 is represented by an arrow and a symbol “A” from the CAN bus monitor 52 to the ECU 54, and from the ECU 54 to the CAN bus monitor. Message B transmitted to 52 is represented by an arrow and a symbol “B” from ECU 54 to CAN bus monitor 52. Further, the CAN bus monitor 52 describes a condition that the interval from when the message A is transmitted until the message B is received is less than 10 msec.

  Next, the sequence diagram T20 of FIG. 4B is converted into a test script T22 by an add-on (an extension function for generating a test script) of the UML modeling tool 50. FIG. 4C shows a specific example of the test script T22.

In the program sequence of the test script T22 shown in FIG. 4C, the first and second lines describe (declare) that the test is a sample test.
The 3rd to 8th lines indicate that “when message B is received within 10 msec after outputting A, it is determined to pass” and “when message B could not be received within 10 msec after outputting A” "Determining that it has failed".

  As described above, as shown in FIG. 4, when verifying the operation of the ECU 54 (the operation of the program installed in the ECU 54), for example, communication (communication procedure) to be realized in the ECU 54 is determined in advance. Then, it is verified whether the actual operation (communication procedure) in the ECU 54 matches the communication procedure to be realized.

  Here, as shown in FIG. 5, in the present embodiment, for example, a desired communication load is given on the CAN to which the ECU 54 is connected, and the operation of the ECU 54 under the communication load can be verified. Yes.

Here, for example, it is assumed that the communication load on CAN is set to 30%.
The tester generates a sequence diagram T40 representing the condition “communication load 30%” via the UML modeling tool 50, as in the case of inputting the test specification. In this example, in the sequence diagram T40, an arrow indicates that a signal is exchanged, and a comment indicating “communication load 30%” is added.

  Then, a test script T42 representing the sequence diagram T40 is generated by an add-on (an extended function for generating a test script) of the UML modeling tool 50. More specifically, the test script T42 reflects (adds) a description (logic) to reduce the communication load to 30% in the test script T22 of FIG. A specific description of the test script T42 is omitted.

  Here, the flowchart shown in FIG. 5 is a flowchart showing the process executed in the CAN bus monitor 52 based on the test script T42. The CAN bus monitor 52 interprets the test script T42, and executes the process shown in the flowchart of FIG. 5 based on the description of the part representing the condition “communication load 30%”, for example. This process is started when the CAN bus monitor 52 interprets the content of the test script T42.

  In this process, first, in S110, the content of the test specification (the portion corresponding to the test script T22 in the test script T42) included in the test script T42 is analyzed, and the types of signals not used in the test specification are calculated. To do. Then, one of the unused signals is selected. For example, there are signals A to E as signal types, of which signals A and B are used in the test specification, and the remaining signals C to E are not used. In this case, one of the signals C to E is selected.

  In step S120, the selected signal is transmitted to the network (CAN). For example, if the signal C among the signals C to E is selected in S110, the signal C is sent to the CAN in S120.

After S120, the process proceeds to S130 and waits for a predetermined period.
Next, it progresses to S140, it is determined whether the communication load on CAN is less than 30%, and if it determines with it being less than 30% (S140: YES), it will transfer to S150.

  In S150, the standby period (the standby period in S130) is shortened by a predetermined interval. And it returns to S120 again. That is, after returning to S120 and transmitting the signal C, the process proceeds to S130, and waits for the period set short by the predetermined interval in S150 described above.

If it is determined in S140 that the communication load on the CAN is not less than 30%, that is, 30% or more (S140: YES), the process directly returns to S120.
In this way, the transmission interval of the signal C is gradually reduced until the communication load becomes 30% or more. When the communication load reaches 30%, the transmission of the signal C at the transmission interval at that time is continued. Become. Note that the standby period of S130 is sufficiently large so that the communication load is less than 30% in the initial setting.

  The CAN bus monitor 52 executes the processing shown in the flowchart of FIG. 5 to realize an environment in which the communication load is 30%, and then verifies the operation of the ECU 54 as described above with reference to FIGS. .

  That is, the CAN bus monitor 52 is based on the monitoring result of the state of the ECU 54 and the CAN and the contents of the test script T42, and the actual operation of the ECU 54 (the operation of the program installed in the ECU 54) is represented by the test specification represented by the test script T42. And a test report T24 representing the determination result is output to be visible to the outside.

  As described above, according to the first embodiment, the tester can create a test specification representing a verification method for verifying the operation of the verification target (for example, the ECU 54), for example, in the form of a sequence diagram. it can. For this reason, the tester can easily create a test specification. Further, since the contents of the test specification are visually easy to understand for a tester or a third party, it is possible to reduce the time required for confirming the contents (validity, etc.) of the test specification.

In addition, it is convenient to verify the appropriateness of the type of signal transmitted / received in the verification target (for example, the ECU 54) and the transmission / reception timing.
In addition, since the sequence diagram created by the tester based on the test specifications is converted into a script that can be recognized by the computer, and the script is executed on the computer, the verification can proceed. There is no need for the user to create a new script. Therefore, the number of man-hours required for verification can be greatly reduced.

  In addition, a condition such as a communication load on the network (CAN) to which the verification target (ECU 54) is connected can be included in the test specification, and the verification can be executed under a desired condition. Can be verified more precisely.

  In addition, since it is not necessary to rewrite a program mounted on the verification target (ECU 54) or embed verification processing in the program, precise verification can be performed. For example, when verifying a program mounted on the verification target (ECU 54), if processing for verification is embedded in the program, processing time for the verification itself is required or a new load is generated. Therefore, the operation of the program to be verified may be affected, but according to the verification system 1 of the first embodiment, such a problem can be avoided.

In the first embodiment, the design drawing drawing tool 40 and the UML modeling tool 50 correspond to model generation means and condition model generation means, the sequence diagram T20 corresponds to a behavior model, the test script generation tool 42 and UML modeling. An add-on (an extension function for generating a test script) of the tool 50 corresponds to a script conversion unit and a condition script conversion unit, and the test script interpretation tool 44 and the CAN bus monitor 52 include a script interpretation unit, a pass / fail determination unit, a determination result output unit, The process corresponds to condition reproduction means and monitoring means, and in particular, the processing shown in the flowchart of FIG. 5 corresponds to condition reproduction means.
[Second Embodiment]
Next, the verification system 1 of the second embodiment will be described focusing on differences from the verification system 1 of the first embodiment.

FIG. 6 is a conceptual diagram of the verification system 1 of the second embodiment.
The verification system 1 according to the second embodiment is different from the verification system 1 according to the first embodiment in that an XML (Extensible Markup Language) file is handled. Note that XML is one of markup languages for describing the meaning and structure of documents and the meaning and structure of data. A document written using XML becomes a text file. That is, the XML file is a text file.

Differences from the first embodiment will be described more specifically.
First, a CAN bus monitor 64 that handles XML files is used. The CAN bus monitor 64 includes an XML parser (software that converts an XML document into a format that can be easily used by an application).

  Secondly, as the design drawing drawing tool 40, a UML modeling tool 60 having a function of converting a drawing (for example, a sequence diagram representing a test specification) input (generated) by a tester into XML is used. .

  Third, an XML conversion program 62 that converts an XML file generated by the UML modeling tool 60 into an XML file that matches the specifications of the CAN bus monitor 64 is used as the test script generation tool 42.

  The UML modeling tool 60 and the XML conversion program 62 are mounted on the PC 10 in FIG. 1, the CAN bus monitor 64 corresponds to the PC 12 in FIG. 1, and the ECU 54 corresponds to the test target communication apparatus 14 in FIG.

In FIG. 6, the tester inputs a test specification via the UML modeling tool 60. More specifically, a sequence diagram representing the test specification is created.
The sequence diagram T30 generated by the tester via the UML modeling tool 60 is output so as to be visible to the outside.

  Further, the UML modeling tool 60 converts the test specification (sequence diagram T30) input by the tester into an XML file T32 and outputs the XML file T32. Specifically, the XML file T32 is input (passed) to the XML conversion program 62.

  The XML conversion program 62 further converts the XML file T32 received from the UML modeling tool 60 into an XML file T34 that conforms to the specifications of the CAN bus monitor 64.

The XML file T34 generated by the XML conversion program 62 is input to the CAN bus monitor 64.
The CAN bus monitor 64 is configured so that the actual operation of the ECU 54 (the operation of the program installed in the ECU 54) matches the test specification represented by the XML file T34 based on the monitoring result of the state of the ECU 54 or CAN and the contents of the XML file T34. Judge whether to do. Then, the CAN bus monitor 64 outputs a test report T36 representing the determination result to the outside so as to be visible. The CAN bus monitor 64 outputs the communication log T38 in the ECU 54 to the outside.

Also by such 2nd Embodiment, the effect similar to 1st Embodiment can be acquired. In particular, since the XML file is handled, the tester can read the contents of the XML file by using a text editor, and can edit the XML file by using the text editor. For this reason, in some cases, it becomes easy for the tester to proceed with the verification work.
[Third Embodiment]
Next, the verification system 1 of the third embodiment will be described focusing on differences from the verification system 1 of the first embodiment.

  FIG. 7 is a conceptual diagram of the verification system 1 according to the third embodiment. In the third embodiment, the test script generation function 72 is a function of the UML modeling tool 70 (an extended function of the UML modeling tool 70), but is described in a separate block for convenience. The test function 74 is a function of the monitoring software 76, but is described in a separate block for convenience.

  The UML modeling tool 70 and the test script generation function 72 are mounted on the PC 10 in FIG. 1, the test function 74 and the monitoring software 76 are mounted on the PC 12 in FIG. 1, and the ECU 54 corresponds to the test target communication device 14 in FIG.

  The verification system 1 according to the third embodiment is different from the verification system 1 according to the first embodiment in that a CAN database (hereinafter also referred to as DB) 80 is provided. The CANDB 80 is a database in which for each signal exchanged on the CAN, a physical value of the signal is associated with a logical name. The logical name is attached so as to express the content / property of the signal.

  Then, in the drawing of the sequence diagram T50 based on the tester's input, the UML modeling tool 70 refers to the CANDB 80 when a physical value representing a signal is input by the tester, for example. It is expressed by a logical name. That is, on the sequence diagram T50, the signal is represented by a logical name representing the content / property of the signal.

  Information representing the sequence diagram T50 generated by the UML modeling tool 70 is passed to the test script generation function 72. The test script generation function 72 transmits the information representing the sequence diagram T50 to the test function 74 included in the monitoring software 76. Is converted into a test script T52 that can be recognized. The test script generation function 72 refers to the CANDB 80 in the generation of the test script T52 and describes the signal with a logical name.

  The test script T52 is passed to the test function 74 of the monitoring software 76. The test function 74 is a test that the actual operation of the ECU 54 (the operation of the program installed in the ECU 54) is represented by the test script T52 based on the monitoring results on the ECU 54 and CAN by the monitoring software 76 and the contents of the test script T52. It is determined whether or not the specification is met, and a test report T54 representing the determination result is output. The monitoring software 76 outputs a communication log T56 in the ECU 54.

  As described above, in the third embodiment, signals are described by logical names in the sequence diagram T50 representing the test specification and the test script T52 obtained by converting the sequence diagram T50. For this reason, the readability is improved for the tester or a third party (confirmer). Therefore, the tester or a third party (confirmer) can easily grasp the contents of the sequence diagram T50 and the test script T52, and consequently, the time required for confirming and checking the contents can be reduced.

By the way, in the verification system 1 of the said 1st-3rd embodiment, you may comprise like the following modifications 1,2.
<Modification 1>
First, Modification 1 will be described with reference to FIG.

  In Modification 1 of FIG. 8, the PC 20 has the function of the verification system 1 as shown in the first embodiment, for example. In other words, the PC 20 has the functions of both the PCs 10 and 12 of the first embodiment.

  Specifically, the PC 20 is connected to the test target communication device 14 and monitors the operation of the test target communication device 14. The PC 20 includes a design drawing drawing tool 40, a test script generation tool 42, and a test script interpretation tool 44.

  In the verification system 1 having such a configuration, a tester creates a test specification on the PC 20 (in other words, a sequence diagram representing the test specification is created), and the created test specification (sequence diagram) is stored in the PC 20. The test script is converted into a test script that the PC 20 can recognize. The PC 20 determines whether or not the actual operation of the test target communication device 14 matches the test specification represented by the test script.

As described above, the configuration of the verification system 1 described in the first embodiment can be realized by a single computer. According to this, cost and installation space can be saved as compared with the case where a plurality of computers are used.
<Modification 2>
Next, Modification 2 will be described with reference to FIG.

  9 includes a PC 30 having a design drawing drawing tool 40, a PC 32 having a test script generation tool 42, a PC 34 having a test script interpretation tool 44, and a test target communication device 14. And a communication monitoring device 36 for monitoring the operation of the above. That is, a dedicated computer is provided for each function.

  In this second modification example, the tester uses the PC 30 to draw a drawing (for example, a sequence diagram) representing the test specification. Information representing the sequence diagram T6 drawn on the PC 30 is output from the PC 30 to the PC 32.

  The PC 32 converts information representing the sequence diagram T6 input from the PC 30 into a test script T4 that can be recognized by the computer. The test script T4 converted by the PC 32 is output from the PC 32 to the PC 34.

The PC 34 interprets the test script T4 input from the PC 32.
The communication monitoring device 36 monitors the test target communication device 14 and the state of the network to which the test target communication device 14 is connected, and outputs the monitoring result to the PC 34.

  Then, based on the interpretation result of the test script T4 and the monitoring result input from the communication monitoring device 36, the PC 34 determines whether the actual operation of the test target communication device 14 matches the test specification represented by the test script T4. Judging.

  In this second modification example, since a dedicated computer is provided for each function, the processing load is distributed to each computer. Therefore, the time required for processing can be shortened.

As mentioned above, although one Embodiment of this invention was described, this invention is not limited to the said embodiment, A various form can be taken within the technical scope of this invention.
For example, in the above embodiment, the design drawing output via the design drawing drawing tool 40 and the test script output via the test script generation tool 42 may be printed out. Also, a test report and a communication log may be printed out.

  In the above embodiment, the test specification is expressed in the form of a sequence diagram. However, any model may be used for expressing the test specification.

It is the schematic showing the hardware constitutions of the verification system 1 of 1st Embodiment. It is a conceptual diagram showing the flow (verification method) of the verification in the verification system 1. It is drawing showing the example which applied the verification system 1 to the network of vehicles. 2 is a diagram illustrating an operation of the verification system 1. It is a drawing showing the operation of the verification system 1 and particularly explaining the setting of the communication load. It is a conceptual diagram showing the verification system 1 of 2nd Embodiment. It is a conceptual diagram showing the verification system 1 of 3rd Embodiment. 10 is a diagram illustrating a hardware configuration of Modification 1. 10 is a diagram illustrating a hardware configuration of Modification 2.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... Verification system, 10a ... Personal computer main body, 10b ... Input device, 10c ... Display, 14 ... Test target communication device, 36 ... Communication monitoring device, 40 ... Design drawing drawing tool, 42 ... Test script generation tool, 44 ... Test Script interpretation tool 46 ... Communication monitoring device 50 ... UML modeling tool 50 ... Modeling tool 52 ... CAN bus monitor 60 ... UML modeling tool 62 ... XML conversion program 64 ... CAN bus monitor 70 ... UML modeling tool 72 ... Test script generation function, 74 ... Test function, 76 ... Monitoring software.

Claims (5)

A verification system comprising a monitoring device that monitors the behavior of a device (hereinafter referred to as a verification target device) that implements a verification target program, and that verifies the operation of the program based on the monitoring result of the monitoring device,
Model generation means for generating a model representing the behavior that the verification target device should behave (hereinafter referred to as a behavior model) based on a user input;
Script conversion means for converting the behavior model generated by the model generation means into a script;
Script interpreting means for interpreting a script generated by conversion by the script converting means;
Pass / fail judgment means for judging suitability of the operation of the program based on whether or not the actual behavior of the verification target device based on the monitoring result of the monitoring device matches the behavior represented by the interpretation result of the script interpretation means; ,
Determination result output means for outputting information indicating the determination result of the pass / fail determination means;
A verification system characterized by comprising: The verification system according to claim 1,
The verification target device is a device that is connected to a network and transmits / receives a signal to / from a communication device on the network,
The behavior model includes at least information on a signal to be transmitted / received to / from the communication device in the verification target device (hereinafter referred to as a transmission / reception signal),
A database storing logical names representing the contents of the transmission / reception signals for each of the transmission / reception signals;
The verification system characterized in that the model generation means generates the behavior model by using the logical name of the transmission / reception signal with reference to the database. The verification system according to claim 2,
The script conversion unit refers to the database and generates a script using a logical name of the transmission / reception signal. The verification system according to any one of claims 1 to 3,
The model generation unit includes a condition model generation unit that generates a model (hereinafter referred to as a “conditional model”) representing a condition (hereinafter referred to as an “environmental condition”) about an operating environment of the verification target device based on a user input. ,
The script conversion means includes condition script conversion means for converting the condition model generated by the condition model generation means into a script,
The monitoring apparatus includes a condition reproduction unit that reproduces the environmental condition based on the script generated by conversion by the condition script conversion unit, and the verification target apparatus when the environmental condition is reproduced by the condition reproduction unit A verification system characterized by monitoring the behavior of the machine. A verification apparatus that is connected to an apparatus (hereinafter referred to as a verification target apparatus) that implements a verification target program, and that verifies the operation of the program in the verification target apparatus;
Monitoring means for monitoring the behavior of the verification target device;
Model generation means for generating a model representing the behavior that the verification target device should behave (hereinafter referred to as a behavior model) based on a user input;
Script conversion means for converting the behavior model generated by the model generation means into a script;
Script interpreting means for interpreting a script generated by conversion by the script converting means;
A pass / fail judgment means for judging the suitability of the operation of the program based on whether the actual behavior of the verification target device based on the monitoring result of the monitoring means matches the behavior represented by the interpretation result of the script interpretation means;
Determination result output means for outputting information indicating the determination result of the pass / fail determination means;
The verification apparatus characterized by comprising.

Images