JP4959640B2 - Model checking support device and program - Google Patents

Description

The present invention relates to a model checking support apparatus and program capable of generating a model including not only operation specifications but also constraint conditions without requiring acquisition of a special model description language for creating a model for model checking.

  Nowadays, software is incorporated into various devices and systems that surround daily life and is becoming more complex and large-scale, and its reliability must be ensured, including when it is involved in the safety of life such as automobiles. The importance of is highly demanded.

  In the system development, a design related to the operation of the software is first performed, and then the software is created and inspected based on the design. Therefore, if it becomes clear that a defect has occurred in the software design stage during the inspection stage, the correction work goes back to the software design, the development process is delayed, and the system reliability is reduced. Problems occur. In addition, it is difficult to completely detect design errors due to omission of examination at the time of design, errors in description of design documents, misunderstanding of specifications, etc. by manual inspection.

  Therefore, in software system development, model checking technology is known as one of formal methods for verifying a system at the design stage.

  This model checking technology generates all possible operation sequences for a system modeled as a state transition system, verifies whether the constraint conditions are satisfied in each operation sequence, and outputs the result. It is.

  It is possible to prevent the occurrence of a correction work that goes back to the design due to the discovery of a defect in the inspection process after the creation of the software, and the delay of the development process associated with the correction work.

  In addition, system reliability can be improved through automatic and comprehensive model checking at the design stage in this way, and system malfunctions, unstable behavior caused by abnormalities and unexpected situations, etc. Can be prevented.

By the way, in order to apply this model checking technique, it is necessary to create a system model using a special model description language (for example, Promela language). Therefore, a model checking support device is disclosed that can create a model written in a model description language from a design document related to the operation of the system (see, for example, Patent Document 1).
JP 2007-11605 A

  However, in the technique described in Patent Document 1, a design document for creating a model must be expressed in a graphic form “logical description represented by a state transition relationship of variables” and is generally created. Unlike the design document, it was not always easy to use. Furthermore, since the model checking support apparatus described in Patent Document 1 cannot generate a constraint condition for checking, it is necessary to create a constraint condition manually.

The present invention has been made in view of such circumstances, and does not require acquisition of a special model description language for model creation for model checking, and creates a model including not only operation specifications but also constraint conditions. An object of the present invention is to provide a model checking support apparatus and program capable of performing the above.

In order to solve the above problems, a model checking support apparatus according to the present invention is based on a specification related to system operation from a model checking program that describes specifications and constraint conditions related to system operation expressed as a state transition system. A model checking support device that generates all possible operation sequences and generates a model checking program to be checked by a model checker that verifies whether or not the constraint condition is satisfied in each generated operation sequence, A specification input unit that receives specifications relating to system operation and the constraints required for the system as tabular information, and extracts specifications and constraints relating to system operation from this table in accordance with a predetermined model description language. The model checking program describing the specifications and constraints related to system operation A model generation unit, and the table includes a state transition table describing an action name executed by the system and a next transition state corresponding to an event occurring in the system and each state of the system, For each state defined in the state transition table, a constraint condition table that describes the values of the elements that constitute the system, and changes in the values of the elements that constitute the system by executing the action corresponding to the action names, An action table that defines the conditions that must be satisfied before and after the execution of the action represented by the values of the elements constituting the system, and the execution of the action or transition that can be described in the state transition table Generated by a condition determination table describing the determination conditions for determining whether or not possible as values of elements constituting the system and external actions outside the system An event table that defines a change in the value of an element constituting the system due to the occurrence of the event and an occurrence condition of the event defined by the value of the element constituting the system, and the model The inspection program changes the specifications relating to the operation of the system to the state transition table, the condition determination table, the event table, and a change in the value of an element constituting the system by executing an action defined in the action table. The constraint condition is described based on the constraint condition table and the conditions that must be satisfied before and after the execution of the action specified in the action table.

  According to the present invention, it is possible to create a model for model checking that includes not only operation specifications but also constraint conditions without the need for learning a special model description language.

[First Embodiment]
FIG. 1 is a diagram showing a flow of model checking using the model checking support device according to the embodiment of the present invention.

The user creates a state transition table 2, an action table 3, a constraint condition table 4, a condition determination table 5, and an event table 11 corresponding to the system design document, and inputs them to the model checking support device 1.
The model checking support device 1 according to the present embodiment is provided with a specification input unit 1a, a check item generating unit 1b, and a model description generating unit 1c. The model checking support device 1 further includes a state transition storage unit 1d, an action storage unit 1e, a constraint condition storage unit 1f, a condition determination storage unit 1g, a model description language dictionary 1h, and an event storage unit 1k.

  The specification input unit 1a extracts necessary information from these input tables and stores them in the state transition storage unit 1d, action storage unit 1e, constraint condition storage unit 1f, condition determination storage unit 1g, and event storage unit 1k, respectively. Store. The inspection item generation unit 1b and the model description generation unit 1c are based on information stored in the state transition storage unit 1d, the action storage unit 1e, the constraint condition storage unit 1f, the condition determination storage unit 1g, and the event storage unit 1k. A model written in the model description language (hereinafter referred to as “model checking program”) is generated.

  The model description language dictionary 1h is a dictionary that is referred to when generating a model checking program. Correspondence between the operators used in the natural language described in these tables and the operators used in the model description language. Stores relationships.

  The inspection item generation unit 1b mainly handles specifications related to operations, and the model description generation unit 1c mainly handles specifications related to constraints. In actual operations, these cooperate to generate the model checking program 6.

  The generated model checking program 6 is verified by the model checker 7 and output as the check result 8. The inspection result 8 describes the inspection result as to whether or not the model inspection program 6 satisfies the constraint conditions and whether there are inconsistencies and deficiencies in the design contents.

  The model checking support device 1 and the model checking device 7 are not limited to hardware, and may be configured by software. The tables 2 to 5 and 11 input to the model checking support device 1 are created using Excel (registered trademark) in the present embodiment, but are not limited to this, and are not limited to Word (registered trademark) and Visio. You may create using other language processing means and tools, such as (trademark).

Subsequently, each of the above-described tables 2 to 5 and 11 input to the model checking support device 1 will be described.
FIG. 2 is a diagram illustrating a description example of the state transition table 2. The state transition table 2 is a table describing system state transitions.

The state transition table 2 includes a state transition table name column 2a, a state name column 2b, an entry / exit action column 2c, an event name column 2d, and an action column 2e.
In the state transition table name field 2a, the name of this state transition table is input in Japanese or alphanumeric notation. The state name column 2b is classified for each state that can be taken by the system, and the state name is input in Japanese or alphanumeric notation. In the entry / exit action column 2c, an operation when entering / exiting the above-described state is defined, and the entrance action and the exit action are input in Japanese or alphanumeric notation. The event name field 2d is classified for each event occurring in this system, and the event name is input in Japanese or alphanumeric notation. In the action column 2e, an action executed in a combination of an event and a state and a transition destination state name are input.

  Next, the contents of the action column 2e will be described. The action column 2e includes an upper stage and a lower stage as a basic configuration.

FIG. 3 is a diagram for explaining the contents in the lower part of the action column 2e.
The lower part describes the action name of the action to be executed in the case of a combination of a predetermined event and state. The processing content of this action name is defined in action table 3 to be described later.
When a plurality of actions are to be executed, a plurality of action names may be described with line breaks in the lower part of the action column 2e. Furthermore, if a condition is required for whether or not to execute the action, the condition (hereinafter referred to as “guard condition”) is described in parentheses ([]), and then the action name may be described. .

  In the action shown in FIG. 3, when an event due to “power button press” occurs in the “power OFF” state, the power ON process is executed and the guard condition “disk present” is satisfied. It is defined that the playback initialization process is executed.

FIG. 4 is a diagram for explaining the contents of the upper part of the action column 2e.
In the upper part, after executing the action in the lower part, the state to be changed to next is described by the state name. If the transition destination differs depending on the condition, write a line feed for each different transition destination. If a condition is required for the transition, the guard condition is described by enclosing it in parentheses ([]), followed by the transition destination.
In the transition shown in FIG. 4, after the action shown in FIG. 3 is executed, if the guard condition “with disk” is satisfied, the state transits to the “stop” state, and the guard condition “without disk” is satisfied. If there is, the transition to the “no disk” state is specified.

  If “/” is entered in the action column 2e, it is treated as “ignore”. “Ignore” indicates that there may be a combination with a predetermined event, but no processing is performed. When “x” is entered in the action column 2e, it is treated as “impossible”. “Impossible” indicates that there cannot be a combination of a predetermined event and a state.

FIG. 5 is a diagram for explaining the contents of the entry action and the exit action.
The entrance action is an action that is executed when transitioning to this state, and the exit action is an action that is performed before transitioning to the next state.
Here, when a plurality of actions are executed, the actions may be described with line breaks. Furthermore, when a condition is required for whether or not to execute the action, the guard condition is described by enclosing it in parentheses ([]), followed by the action name.

  Actions are executed in the order of action in the lower part of the action column 2e → exit action → entry action. In the example shown in FIG. 5, when event 1 occurs in state 1, the actions are executed in the order of action 3 → action 2 → action 4.

  The case where the current state name is described in the upper part of the action column 2e is called “self-transition”. In the case of self-transition, the state itself does not change, but the transition process is performed, and the entrance action and the exit action are executed. A case where “-(hyphen)” is described in the upper part of the action column 2e or is blank is referred to as “internal transition”. In the case of an internal transition, the action in the lower part of the action column 2e is executed, but the exit action and the entry action are not executed.

  FIG. 6 is a diagram illustrating a description example of the action table 3. In the action table 3, the contents of the “action” described in the lower part of the action column 2e and the entry / exit action column 2c of the state transition table 2 are classified into “precondition”, “processing content”, and “postcondition”. Describes the state of the component in the.

The action table 3 includes an action name field 3a, a precondition field 3b, a processing content field 3c, and a post condition field 3d.
In the action name field 3a, the same name as the action name described in the lower part of the action field 2e of the state transition table 2 and the entry / exit action field 2c is input in Japanese or alphanumeric notation.

In the precondition column 3b, a condition value of a component that must be satisfied in order to execute the processing contents of the action is described. The processing content column 3c describes how the value of the component is changed by executing the action. In the post-condition column 3d, a condition value of a component to be established after the action content is executed is described.
These conditions or contents in the respective columns can be described in natural language, expressions, or the like. In addition, when there are a plurality of conditions or contents in each column, they may be described with line breaks. If there is no condition or content, enter “-(hyphen)” or a blank in the field.

  Here, “=” described in the precondition column 3b and the postcondition column 3d in FIG. 6 represents “condition”, and “←” described in the processing content column 3c represents “assignment”. Yes.

  The action shown in FIG. 6 defines the following. In order to execute the “disk rotation start process”, it is necessary as a precondition that the value of “disk” as a component is “present” and the value of “disk rotation” is “stop”. The processing content is that the value of “disk rotation” is set to “rotating”, and the post-condition that is the result of the processing is that the value of “disk rotation” is “rotating”. is necessary.

FIG. 7 is a diagram illustrating a description example of the condition determination table 5. The condition determination table 5 describes the contents of the guard conditions described in parentheses in each column of the state transition table 2.
The condition determination table 5 includes a condition determination name column 5a and a condition content column 5b.
In the condition determination name column 5a, the name of the guard condition described in parentheses in each column of the state transition table 2 is input in Japanese or alphanumeric notation.
In the condition content column 5b, the condition determination content of the condition determination name is entered. This may be described using natural language in addition to specific values and mathematical expressions. If there is no content, enter "-(hyphen)" or a blank in the field.

  For example, in FIG. 7, the condition “being a start track” is that the value of the component “track number” is “1”, and the condition “not a start track” is the component “track number” "Is greater than 1".

FIG. 8 is a diagram illustrating a description example of the constraint condition table 4. The constraint condition table 4 describes values that can be taken by the components in each state of the system to be verified.
The constraint condition table 4 is provided with a component name column 4a, a state name column 4b, and a constraint condition content column 4c.
In the component name column 4a, the name of each component is entered in Japanese or alphanumeric notation. In the state name column 4b, the same name as the state name in the state transition table 2 is described. In the constraint condition content column 4c, a constraint condition indicating what value a certain component must be in a certain state is described. This may be described in natural language in addition to specific values and names.

  For example, in FIG. 8, in the state “power OFF”, the value of the component “power” is “OFF”, the value of the component “audio output” is “none”, and the value of the component “disk rotation” is “stop”. It is specified that there are no restrictions on the values of the components “disk”, “track number”, and “total number of tracks”.

  FIG. 9 is a diagram illustrating a description example of the event table 11. The event table 11 describes conditions for generating an event and changes in values of components in the system due to the occurrence of the event.

The event table 11 includes an event name column 11a, an occurrence condition column 11b, and an action content column 11c.
In the event name column 11a, the same name as the event name described in the event name column 2d of the state transition table 2 is input in Japanese or alphanumeric notation. In the generation condition column 11b, a condition that must be satisfied in order for the event to occur, that is, a generation condition is described. In the action content column 11c, a change in the value of a component in the system due to the occurrence of an event, that is, the action content is described. This action content is not actively changed by the system, but is changed by an external action such as an operation by the user.

According to the event table 11 shown in FIG. 9, the event “disc insertion” does not occur when the disc is already in the CD player, and the event “track end reached” occurs only when the disc is in the CD player. Does not occur.
Here, for events other than the event “disc insertion” and “track end reached”, the generation conditions are not specified, but this means that events other than the events “disc insert” and “track end reached” can occur at any time. Represents.

Next, the operation | movement which produces | generates a model check program using the model check assistance apparatus which concerns on embodiment of this invention is demonstrated.
FIG. 10 is a flowchart showing the generation procedure of the model checking program.

In step S01, the user inputs the state transition table 2, the action table 3, the constraint condition table 4, and the event table 11 to the model checking support device 1.
FIG. 11 is a diagram illustrating a description example of each table input to the model checking support device 1. In this figure, the operation by turning on / off the power button, inserting the disk, and pressing the next track button will be described. However, for the sake of simplification, the operation without using the condition determination table 5 is described.

  In the present embodiment, the state transition table 2, the action table 3, the constraint condition table 4, and the event table 11 are generated using other language processing means and tools such as Excel (registered trademark) as described above. However, the input method can take various forms. For example, the user may input data from an input device (not shown), may input each created table via a storage medium (not shown), or may be input from another external system via a communication line (not shown). Each table already created may be transmitted to the model checking support device 1. Further, except for the state transition table 2, as long as necessary data is input, it may not be created in a table format.

  In the model checking support device 1, the specification input unit 1a is activated to extract data from each input table, and a state transition storage unit 1d, an action storage unit 1e, a constraint condition storage unit 1f, and a condition determination storage unit, respectively. 1g and the event storage unit 1k. At this time, it is confirmed whether the state name of the transition destination described in the upper part of the action column 2e of the state transition table 2 shown in FIG. 2 is described in the state name column 2b. If the state name of the transition destination described in the upper part of the action column 2e does not exist in the state name column 2b, the specification input unit 1a determines that it is abnormal, and ends the operation without generating a model checking program. Similarly, the action name described in the lower part of the action column 2e of the state transition table 2 is described in the action table name field 3a of the action table 3, or parentheses ( Whether the guard condition described in []) is described in the condition determination name column 5 a of the condition determination table 5, the precondition column 3 b, the processing content column 3 c, the post-condition column 3 d, and the condition determination table of the action table 3 The component name described in the condition content column 5b of 5 is described in the component name column 4a of the constraint condition table 4, or the event name described in the event name column 11a of the event table 11 is Whether or not the event name field 2d is described is confirmed. If it does not exist, the specification input unit 1a determines that the error is abnormal, and ends the operation without generating a model checking program.

  The inspection item generation unit 1b and the model description generation unit 1c are based on the data of each table stored in the state transition storage unit 1d, the action storage unit 1e, the constraint condition storage unit 1f, the condition determination storage unit 1g, and the event storage unit 1k. Thus, the model checking program 6 is generated. When a natural language is used in descriptions of actions, constraint conditions, and condition determinations, the model description language dictionary 1h is referred to as appropriate and converted to a corresponding model description language.

  Unless otherwise specified, the inspection item generation unit 1b and the model description generation unit 1c cooperate to generate each part of the model inspection program.

In step S02, generation of the state transition unit 6c shown in FIG. 23 in the model checking program 6 is started. First, for each event name described in the event name column 2d of the state transition table 2 stored in the state transition storage unit 1d, a block for processing the event is generated in the model checking program 6.
In FIG. 12, different blocks of the events “power button ON”, “power button OFF”, “disc insertion”, and “next track button press” are generated. That is, the blocks are divided according to the value of the variable event representing the event that has occurred.

In step S03, a block for each state in the state name column 2b of the state transition table 2 stored in the state transition storage unit 1d is generated inside each generated block.
In FIG. 13, blocks of status names “power OFF state”, “standby state”, and “disk presence state” are generated. That is, the block is further divided into three blocks according to the variable state representing the current state.

In step S04, in accordance with the description in the action column 2e of the state transition table 2 stored in the state transition storage unit 1d, a call process for the action unit 6a created in step S06 is generated for each block in the generated state.
In FIG. 14, the call of the processing content “lamp lighting process” and the transition destination “standby state” are described in the block whose event is “Power button ON” and whose state is “Power OFF state”. Also, in the block where the event is “Power button OFF” and the state is “Standby state”, the calling of the processing content “Lamp off process” and the transition destination “Power OFF state” are described. Furthermore, in the block where the event is “power button OFF” and the state is “disk presence state”, the calling of the processing content “disk ejection process” and “lamp extinguishing process” and the transition destination “power OFF state” are described.

In step S05, a block for each state in the state name column 2b of the state transition table 2 stored in the state transition storage unit 1d is newly generated. Then, the calling process of the constraint condition checking unit 6b created in step S07 is generated in the generated block. That is, the quality of the constraint condition is checked for each generated state.
In FIG. 15, blocks of “power-off state”, “standby state”, and “disk presence state” which are state names are generated. In other words, a case is determined depending on the variable nextstate representing the transition destination, and a block is generated for each transition destination state. A state name is created for each block as a call name for checking the constraint condition.

In step S06, creation of the action part 6a in the model checking program 6 is started. The block is created by dividing the action name described in the action name column 3a of the action table 3 stored in the action storage unit 1e. Then, internal processing is generated in accordance with the description of the action table 3 stored in the action storage unit 1e in the generated block.
In FIG. 16, blocks are created corresponding to “next track processing” and “disk receiving processing” of action names. Then, in the “next track processing” block, the contents of the precondition column 3b stored in the action storage unit 1e are generated as assert statements using the Promela language which is a model description language. The content of the processing content column 3c is generated by conversion using the Promela language. The content of the post-condition column 3d is generated as an assert statement using the Promela language. The same processing is performed for the “disk receiving process” block.

  For example, if the content generated as an assert statement is a precondition, it is interpreted that “the track number must be smaller than the total number of tracks” before the processing is performed.

  By the processing so far, the action part 6a is created in the model checking program.

  In step S07, creation of the constraint condition checking unit 6b in the model checking program 6 is started. Blocks are created by dividing the state names described in the state name column 4b of the constraint condition table 4 stored in the constraint condition storage unit 1f.

  In FIG. 17, blocks are created corresponding to the state names “power OFF state”, “standby state”, and “disk presence state”.

In step S08, a block using the description in the constraint condition content column 4c stored in the constraint storage unit 1f is generated for the constraint check in the generated block.
In FIG. 18, in the “power OFF state” block, “lamp” which is a constraint condition is “off”, “disk” is “none”, “track number” is “0”, and “power button” is “push up”. An assert statement is generated that specifies that it must be. Also, in the “standby” block, the “lamp” that is the constraint condition is not “lit”, “disk” is “none”, “track number” is “0”, and “power button” is not “pressed”. Generated as an assert statement that stipulates not to be.
In this way, a plurality of components are described as constraints for each state.

  Through the processing so far, the constraint condition checking unit 6b is created in the model checking program 6.

  In step S09, a block for each event described in the event name column 11a of the event table 11 stored in the event storage unit 1k is generated. An internal process according to the action content column 11c stored in the event storage unit 1k is described in the generated block to create the event content unit 6f.

In FIG. 19, blocks are generated corresponding to the event names “power button ON”, “power button OFF”, “disc insertion”, and “next track button press”.
In FIG. 20, “power button = press” is described as the internal processing of the generated block “power button ON”, and “power button = press-up” is described as the internal processing of “power button OFF”. Here, only “block” is generated in “insert disc” and “press next track button” without description of action contents.

  In step S10, an event generation unit 6d that generates an event nondeterministically in the model checking program is generated using the event name column 2d of the state transition table 2 stored in the state transition storage unit 1d. Furthermore, the condition described in the event condition column 11b of the event table 11 stored in the event storage unit 1k is assigned to the event occurrence condition, and the event content part call process is generated.

In FIG. 21, “power button ON”, “power button OFF”, “disc insertion”, and “next track button press” are set as the value of a variable event representing an event. For the events “power button ON” and “power button OFF” for which the event occurrence condition is specified in the event table 11, the occurrence conditions are output, and the event “disk insertion” for which the event occurrence condition is not specified is output. Regarding “next track button press”, “true” indicating that it can always be generated is output.
Then, in FIG. 22, the event action content calling part is generated in the event generating part 6d.

FIG. 23 is a diagram showing a basic configuration of the model checking program 6 created by the above procedure.
Based on the state transition table 2, the action table 3, the constraint condition table 4 and the event table 11, the action unit 6a, the constraint condition checking unit 6b, the state transition unit 6c, and the event generating unit 6d in which the data are associated with each other. And the event content part 6f is generated. The condition determination unit 6e will be described in detail later.

  The order of generating the state transition unit 6c, the action unit 6a, the constraint condition checking unit 6b, the event generating unit 6d, and the event content unit 6f is not limited to the present embodiment.

  In generating a model checking program, declarations of variables, constants, processes, etc. are made appropriately based on the rules of the model description language that uses them.

[Second Embodiment]
In the second embodiment, an operation for processing the entry / exit action of the condition determination table 5 and the state transition table 2 in the generation of the model checking program will be described. Accordingly, the same parts as those in the first embodiment are denoted by the same reference numerals, and detailed description thereof is omitted.

  FIG. 24 is a diagram illustrating a description example of each table input to the model checking support device 1. Compared to the first embodiment shown in FIG. 11, the condition determination table 5 is read, and the state transition table 2 includes “no disk”, [ The difference is that “With disk” is described.

In step S04 of the model checking program generation flow shown in FIG. 10, the contents of each column in the action column 2e of the state transition table 2 stored in the state transition storage unit 1d are described in each block of the generated state.
In FIG. 25, in the block where the event is “Power button ON” and the state is “Power OFF state”, the processing content “Lamp lighting process”, transition destination “[No disk] standby state” and “[Disk present] disk present state” Is described.
First, a block for each state in the state name column 2b of the state transition table 2 is newly generated. Then, the calling process of “lamp lighting process” in the lower part of the action column 2e is described in the generated block.

  Next, a process for generating a call process of the condition determination unit 6e for determining the upper condition of the action column 2e and changing the transition destination according to the determination result will be described. FIG. 25 stipulates that when “no disk” is established, the transition destination is “standby state”, and when “disk present” is established, the transition destination is “disk present state”.

  In FIG. 26, the processing contents “[no disk] disk receiving process” and “lamp lighting process” and the transition destination “disk present state” are described in the block whose event is “disk inserted” and whose state is “power OFF state”. ing.

  When condition determination is used in the lower part of the action column 2e of the state transition table 2, a call process of the condition determination unit 6e for determining the condition is generated, and whether or not the corresponding action is executed according to the determination result is determined. The process to change is described. In FIG. 26, it is defined that “disk receiving process” is executed only when “no disk” is established.

Next, the process of the condition determination table 5 will be described.
After step S08 of the model checking program generation flow shown in FIG. 10 is completed, the process of the condition determination table 5 is executed.

In the condition determination table process, a block is generated with the condition determination name of the condition determination table 5 stored in the condition determination storage unit 1g, and the process name is written in the generated block according to the contents of the condition determination table 5.
In FIG. 27, blocks are created corresponding to the condition determination names “with disk” and “without disk”, and the contents of the condition determination table 5 are defined for each block.

  The part of the program generated based on this condition determination table 5 is added as a condition determination unit 6e to the model checking program 6 shown in FIG. The condition determination unit 6e is generated before the state transition unit 6c.

Next, “impossible” and “ignore” will be described.
“Impossible” is a case where “x” is entered in the action column 2e, and indicates that there cannot be a combination of the event and the status that are “impossible”.

In FIG. 28, the event “power button ON” must not occur in the “standby state” and “disk presence state”, and the event “power button OFF” must not occur in the “power OFF state”. It is described.
When the action column 2e is “impossible”, an assert statement is inserted in each block generated in step S04. This indicates that this block must not be executed.

“Ignore” is a case where “/” is entered in the action column 2e, and indicates that there is a combination of the event and the state that are “ignore”, but no processing is performed.
In this case, nothing is written in the block corresponding to the action column 2e.

Next, the entry / exit action will be described.
The entry action is an action that is executed when transitioning to this state, and the exit action is an action that is performed before transitioning to the next state.
In the state transition table 2 shown in FIG. 29, “Lamp-off process” is executed as an entrance action when transitioning to “Power OFF state”, and when transitioning from “Power OFF state” to another state, It is defined that “lamp lighting process” is executed as an exit action.

  When this entry / exit action is described in the state transition table 2, a block for processing the entry / exit action is generated at the end of the state transition part of the model checking program 6 shown in FIG. Inside the processing block for the entrance action and the processing block for the exit action, a block corresponding to the state of the state transition table 2 is generated, and the contents described in the entrance action column and the exit action column are the model description language. Generated using.

  Next, the role of the event table 11 will be described in detail by taking an example of checking a program incorporated in the kitchen timer.

FIG. 30 is a block diagram illustrating a configuration of the kitchen timer 20.
The kitchen timer 20 is provided with a start button 21, a stop button 22 and an alarm (alarm) 23. Then, the CPU 25 receives the operation signals of the start button 21 and the stop button 22, exchanges information with the timer 26, and controls the alarm sounding operation of the alarm 23.

The specification of the kitchen timer 20 is as follows.
When the start button 21 is pressed, the timer 26 is activated, and the alarm 23 sounds when a certain time has elapsed. When the stop button 22 is pressed while the alarm 23 is sounding, the alarm 23 stops sounding. When a certain time elapses while the alarm 23 is sounding, the alarm 23 stops sounding.
After the alarm 23 stops sounding, the timer 26 is stopped, and the start button 21 is pressed again to start the timer 26. If the stop button 22 is pressed after the start button 21 is pressed and before the alarm 23 sounds, the timer 26 stops.

The specifications of the timer 26 built in the kitchen timer 20 are as follows.
When the timer 26 receives a counter setting signal from the CPU 25, the timer 26 immediately starts counting down. If the CPU 25 has output an interrupt permission signal to the timer 26, the timer 26 outputs a timer interrupt signal to the CPU 25 when the count reaches zero.

  Even if the timer interrupt signal is output to the CPU 25, the timer 26 is not automatically disabled. If the counter is set again, the timer 26 immediately starts counting down and generates a timer interrupt signal.

FIG. 31 is a diagram illustrating an example in which the kitchen timer 20 is designed.
The contents of the state transition table 2, the constraint condition table 3, the action table 4, and the event table 11 that define the above-described operations are shown. The result of checking the model checking program 6 generated according to each table by the model checker 7 is “good”, and there is no defective part.

  However, in the model checking program 6 generated without using the event table 11, that is, with the occurrence condition column 11 b and the action content column 11 c blank, in the case of the conventional apparatus in the check with the model checker 7, An error is pointed out.

It is a case where a “timer interrupt” event occurs and a transition to the “alarming” state occurs before the “start button pressed” event occurs in the “waiting” state, and the interrupt is DISABLE. It is. In other words, the constraint condition table 3 is a warning that it is in violation of the definition that the interrupt must be ENABLE in the “alarming” state.
However, it is unreasonable to generate a “timer interrupt” event because the “timer interrupt permission” action is not executed before the “start button pressed” event occurs in the “waiting” state. . That is, the model checking device 7 detects an impossible event and generates an error.

The reason for this is that, since all the events can always occur, the inspection is proceeded, and therefore, the constraint condition violation triggered by the occurrence of the event in a situation where it cannot originally occur is erroneously detected. In general, there is a possibility of the same false detection in the following situation.
That is, until now, the value of the component in the system to be inspected has changed only by the active processing (action) of the system. When the system is a “closed system”, the values of the constituent elements are consistent within the system. However, if the system is an “open system” and the value of the component in the system may passively change due to an action from outside the system (external action), the result of inconsistent component values , Violations of constraints may be detected incorrectly.

In order to eliminate the problems of the conventional apparatus as described above, the inventors have repeatedly studied fundamentally about the requirement for preventing the occurrence of errors, and have devised the following countermeasures.
(1) In order to eliminate the detection of an erroneous constraint violation due to an impossible event occurrence, the event occurrence condition can be specified.
(2) In order to eliminate detection of an erroneous constraint violation due to an illegal value of a component in the system, it is possible to define a change in the value of the component in the system due to the occurrence of an event.

  The event table 11 is provided in order to eliminate defects caused by this external action. In this way, by detecting the system and the outside acting on the system as one closed system, it is possible to eliminate detection of erroneous constraint violations that occur when only the system that is an open system is the target of inspection. .

In the event table 11 shown in FIG. 31, “occurrence condition” is defined so that a “timer interrupt” event can be generated only when “interrupt” is ENABLE. Thus, when interpreted in combination with the state transition table 2, it is defined that a “start button press” event occurs and a “timer interrupt” event can be generated only after executing a “timer interrupt permission” action.
The change in the value of the component in the system due to the occurrence of the “timer interrupt” event can be defined in “action content”.

Furthermore, by using this event table 11, it is possible to enhance the inspection functions of “impossible” and “ignore”.
As described above, until now, since all the events can always occur, the inspection has proceeded, so “impossible” that cannot be reached has always been reachable. Therefore, it was not possible to perform an inspection distinct from “ignorance” that could be reached.
By the way, in the event table 11, by making it possible to specify an event occurrence condition, it is possible to distinguish between “impossible” and “ignore” and to check the reachability to impossibility.

FIG. 32 is a diagram illustrating an example of a non-reachability test using the event table.
In this vending machine, coins can be inserted when there is no coin being held in the vending machine or only one is being held. Therefore, when there are two or more coins held in the vending machine, the “100 yen coin insertion” event does not occur. However, since this “impossible” was also reachable in the inspections so far, it was necessary to check each time whether there was a problem in the design.
On the other hand, as shown in FIG. 32, non-reachability to non-reachability is realized by defining “less than two coins are held” in the occurrence condition of “100-yen coin insertion” event in the event table 11 It is possible to check whether or not

[Effect of the embodiment]
The model checking support device according to the present embodiment has the following characteristic functions.

Data necessary for generating the model checking program is created in the form of a design document. For example, the format of the state transition table corresponds to how to write a design document generally used in embedded system development.
Thus, since a model checking program can be automatically generated from a document, learning of a model description language is unnecessary.

  Further, by automatically generating the model checking program from the design document, it is possible to immediately perform the model checking after the design document is created without manually creating the model checking program.

  In addition, a unique action table and a constraint condition table are introduced, and the constraint conditions can be described as data necessary for generating the model checking program. As a result, the constraint condition to be verified can be automatically generated in the model checking program.

  In the constraint table, the properties required for the system are clearly indicated by a combination of the system state and the component values. Therefore, it is possible to prevent the specification from becoming ambiguous due to omission of the description of the constraint condition.

  In the action table, not only the content of the action but also the precondition and the postcondition are described, so that not only the operation specifications but also the constraint conditions can be described concisely and confirmed by model checking.

  In the event table, by making it possible to specify the occurrence condition for each event, it is possible to eliminate the detection of false constraint violations due to the occurrence of an event that is not possible, and further it is possible to check for non-reachability to `` unavailable cells '' can do. Further, by making it possible to define a change in the value of a component in the system due to the occurrence of an event, it is possible to eliminate detection of an erroneous constraint violation due to an incorrect value of a component in the system.

  Although the model support apparatus according to the present embodiment has such a feature, it is naturally possible for a person who has mastered the model description language to use it effectively. For example, data necessary for generating the model checking program may be described in a model description language (for example, Promela language). FIG. 33 shows an example in which “pre-condition”, “processing content”, and “post-condition” in the action table are created in the model description language. By using the model description language, it is possible to describe simpler and more rigorous than natural language.

  Each function described in the above embodiment may be configured using hardware, or may be realized by reading a program describing each function into a computer using software. Each function may be configured by appropriately selecting either software or hardware.

  Furthermore, each function can be realized by causing a computer to read a program stored in a recording medium (not shown). Here, as long as the recording medium in the present embodiment can record a program and can be read by a computer, the recording format may be any form.

  Note that the present invention is not limited to the above-described embodiment as it is, and can be embodied by modifying the constituent elements without departing from the scope of the invention in the implementation stage. Further, various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the embodiment. For example, some components may be deleted from all the components shown in the embodiment. Furthermore, you may combine suitably the component covering different embodiment.

The figure which shows the flow of the model check using the model check assistance apparatus which concerns on embodiment of this invention. The figure which shows the example of a description of a state transition table. The figure explaining the content of the lower stage of an action column. The figure explaining the content of the upper stage of an action column. The figure explaining the content of an entrance action and an exit action. The figure which shows the example of a description of an action table. The figure which shows the example of a description of a condition determination table. The figure which shows the example of a description of a constraint table. The figure which shows the example of a description of an event table. The flowchart which shows the production | generation procedure of a model check program. The figure which shows the example of description of each table | surface input into a model check assistance apparatus. The figure which shows the creation condition of a model check program. The figure which shows the creation condition of a model check program. The figure which shows the creation condition of a model check program. The figure which shows the creation condition of a model check program. The figure which shows the creation condition of a model check program. The figure which shows the creation condition of a model check program. The figure which shows the creation condition of a model check program. The figure which shows the creation condition of a model check program. The figure which shows the creation condition of a model check program. The figure which shows the creation condition of a model check program. The figure which shows the creation condition of a model check program. The figure which shows the basic composition of a model check program. The figure which shows the example of description of each table | surface input into a model check assistance apparatus. The figure which shows the creation condition of a model check program. The figure which shows the creation condition of a model check program. The figure which shows the creation condition of a model check program. The figure which shows the basic composition of a model check program. The figure which shows the basic composition of a model check program. The block diagram which shows the structure of a kitchen timer. The figure which shows the example which designed the kitchen timer. The figure which shows the non-reachability test example to the impossible cell using an event table. The figure which shows the example which produced the action table in the model description language.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 ... Model check assistance apparatus, 1a ... Specification input part, 1b ... Check item production | generation part, 1c ... Model description production | generation part, 1d ... State transition storage part, 1e ... Action storage part, 1f ... Restriction condition memory | storage part, 1g ... Condition Determination storage unit, 1h ... model description language dictionary, 1k ... event storage unit, 2 ... state transition table, 2a ... state transition table name column, 2b ... state name column, 2c ... entry / exit action column, 2d ... event name column, 2e ... Action column, 3 ... Action table, 3a ... Action name column, 3b ... Precondition column, 3c ... Processing content column, 3d ... Post-condition column, 4 ... Restriction condition table, 4a ... Component name column, 4b ... Status Name field, 4c ... Restriction condition content field, 5 ... Condition determination table, 5a ... Condition determination name field, 5b ... Condition content field, 6 ... Model check program, 6a ... Action part, 6b ... Restriction condition check part, 6c ... State Transition part, 6d ... Event Generator, 6e ... condition judging unit, 7 ... model checker, 8 ... inspection results, 11 ... event table, 11a ... event name column, 11b ... Condition column, 11c ... Function Content field.

Claims (6)

Generates all possible operation sequences based on the system operation specifications from the model checking program that describes the system operation specifications and constraints expressed as state transition systems, and in each generated operation sequence A model checking support device that generates a model checking program to be checked by a model checker that verifies whether a constraint condition is satisfied,
A specification input unit that receives specifications relating to the operation of the system and the constraints that are required for the system as tabular information;
A model generation unit that extracts specifications and constraint conditions related to system operation from this table and generates the model checking program describing specifications and constraint conditions related to system operation using a predetermined model description language, and
The table
A state transition table that describes the name of an action executed by the system and the next transition state corresponding to the event that occurs in the system and each state of the system,
For each state defined in the state transition table, a constraint table describing values of elements constituting the system,
Corresponding to the action name, a change in the value of an element constituting the system by execution of the action and a condition that must be satisfied before and after execution of the action represented by the value of the element constituting the system. A prescription action table;
A condition determination table described as a value of an element constituting the system, a determination condition for determining whether or not an action or a transition can be executed, which can be described in the state transition table;
An event that prescribes a change in the value of an element that constitutes the system due to the occurrence of the event and an occurrence condition of the event that is defined by the value of the element that constitutes the system for the event that occurs due to an external action outside the system With a table,
The model checking program is
A specification relating to the operation of the system is described based on the state transition table, the condition determination table, the event table, and a change in the value of an element constituting the system due to the execution of the action specified in the action table. ,
The model checking support device, wherein the constraint condition is described based on the constraint condition table and a condition that must be satisfied before and after execution of an action defined in the action table.   When the occurrence condition is satisfied and the event due to an external action occurs, the model checking program sets the specified value as a value of an element constituting a system in the system corresponding to the event. The model checking support device according to claim 1, wherein the model checking support device is described in claim 1. The state transition table is:
A disabled state in which the combination of the event and the system state does not occur; and
The model checking support apparatus according to claim 1, further defining an ignorance state in which no action is executed even if a combination of the event and the system state occurs.   The said model check program is described so that the said event may not be generated when the said generation | occurrence | production conditions of the said event by external action are not satisfied. The model checking support device described.   5. The model checking program is described so that an event can always be generated when the generation condition of the event due to an external action is not defined. Model checking support device. Generates all possible operation sequences based on the system operation specifications from the model checking program that describes the system operation specifications and constraints expressed as state transition systems, and in each generated operation sequence A program for causing a computer mounted on a model checking support device to generate a model checking program to be checked by a model checker that verifies whether or not the constraint condition is satisfied,
A specification input step for receiving, as tabular information, specifications relating to system operation and the constraints required for the system;
A model generation step of extracting specifications and constraint conditions related to system operation from this table and generating the model checking program describing specifications and constraint conditions related to system operation using a predetermined model description language; and
The table
A state transition table that describes the name of an action executed by the system and the next transition state corresponding to the event that occurs in the system and each state of the system,
For each state defined in the state transition table, a constraint table describing values of elements constituting the system,
Corresponding to the action name, a change in the value of an element constituting the system by execution of the action and a condition that must be satisfied before and after execution of the action represented by the value of the element constituting the system. A prescription action table;
A condition determination table described as a value of an element constituting the system, a determination condition for determining whether or not an action or a transition can be executed, which can be described in the state transition table;
An event that prescribes a change in the value of an element that constitutes the system due to the occurrence of the event and an occurrence condition of the event that is defined by the value of the element that constitutes the system for the event that occurs due to an external action outside the system With a table,
The model checking program is
A specification relating to the operation of the system is described based on the state transition table, the condition determination table, the event table, and a change in the value of an element constituting the system due to the execution of the action specified in the action table. ,
The program characterized in that the constraint condition is described based on the constraint condition table and a condition that must be satisfied before and after the execution of the action specified in the action table.

Images