JP2012128727A - Reliability evaluation method and apparatus for software component - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a technology for evaluating how a failure in a software component is propagated, from a specification of the software component.SOLUTION: A computer including a model form verifying function executes a specification information acquisition step of acquiring specification information including an input interface specification, an output interface specification and an internal specification of a software component, a verification step of verifying the software component through the form verifying function in accordance with specification information after the input interface specification in the specification information is modified other than a normal value, and failure propagation path storage step of correspondingly storing, in the case where an example which becomes an output value not meeting the output interface specification is discovered in the verification step, input which is changed other than the normal value, and output which does not meet the output interface specification.

Description

  The present invention relates to a technique for evaluating the reliability of software components.

  In large-scale system development, generally, a method is used in which software is divided into appropriate sizes to configure components (software components), and the entire software is configured as a combination thereof. When the system to be developed is a safety-related system such as an emergency stop device, the software is also required to have high reliability. Conventionally, in software development in such a safety system, a technique for improving reliability by improving quality by improving a development process has been taken. In addition, even when reliability evaluation is performed for software architecture, it is common for evaluators to evaluate based on experience, and it is difficult to evaluate by analyzing the internal structure of components in detail. . These have a problem of a large amount of work due to manual work and a strong dependence on the experience of engineers.

  On the other hand, in recent years, a system development method called formal verification based on mathematics has been adopted. In formal verification, specifications are described mathematically and all states are inspected using computers to check for inconsistencies. As techniques for automating these, techniques such as automatic theorem proving and model checking have been studied. These techniques have the advantage that model integrity is guaranteed because all conditions and states are automatically examined. For example, Alloy Analyzer, one of the formal verification tools, has a set theory and predicate logic as its theoretical basis, and searches for examples that satisfy specified properties for a given specification (predicate verification) or specification You can look for cases that do not satisfy the specified properties (verification of assertions).

JP 2010-237855 A

  Model checking by formal verification as described above is focused on verifying whether the designed model satisfies the specifications. That is, it is not clear how the software component behaves when an abnormal input is given, that is, when a fault (bug) is given. Knowing how software components behave in response to extraneous faults, you can see how faults propagate. Such information can be used to evaluate the entire system, for example, to analyze which software component failure (bug) may cause an event that compromises safety.

  An object of the present invention is to evaluate how a fault propagates in a software component from the specification of the software component.

In the software component reliability evaluation method of the present invention,
A computer having a model formal verification function
A specification information acquisition step for acquiring specification information including input interface specifications, output interface specifications, and internal specifications of the software component;
A verification step of verifying the software component by the format verification function according to the specification information in which the input interface specification in the specification information is changed to a value other than a normal value;
When an example of an output value that does not satisfy the output interface specification is found in the verification step, the input changed to a value other than the normal value and the output that does not satisfy the output interface specification are stored in association with each other. A fault propagation path storing step;
Execute.

  As described above, by performing format verification using the specification information in which the input interface specification is changed to a value other than the normal value, it is possible to examine the behavior of the software component when there is an abnormal (failure) input. In formal verification, an example (counterexample) that does not satisfy the output specification can be found. Here, by associating and storing which output has an abnormal output, it is possible to accumulate information on which output the abnormality propagates to when an abnormal value is input.

In the present invention, the software component preferably takes a plurality of input values,
In the verification step, it is preferable to verify the software component in accordance with the specification information in which the input interface specification is changed to a value other than the normal value for each input value.

  By making a plurality of inputs one by one other than the normal value, it is possible to grasp to which output each abnormal input propagates.

  In the present invention, it is also preferable that the computer further includes a step of creating abnormal specification information in which the input interface specification is set to a value other than a normal value for each input value from the specification information acquired in the specification information acquisition step.

  The specification information is provided to the computer in a format readable by the format verification function. Here, since the computer automatically creates abnormality specification information in which the input interface specification is set to a value other than the normal value for each input value, it is possible to save the user's trouble.

In the present invention, the computer includes:
For each software component of the system including a plurality of software components, execute the specification information acquisition step, the verification step, the failure propagation path storage step,
Preferably, the fault propagation path of the system is displayed based on the input and output stored in association with each other in the fault propagation path storing step.

  Since an abnormal propagation path is stored for each software component, a failure propagation path can be displayed for the entire system composed of a plurality of software components. As a result, the user can easily understand which software component has the cause of the abnormality detected in a certain software component.

  Note that the present invention can also be understood as a reliability evaluation method for performing at least a part of the above processing, or a program for realizing the method. Further, the present invention can also be understood as a reliability evaluation apparatus having each means for executing the above processing. Each of the above means and processes can be combined with each other as much as possible to constitute the present invention.

  According to the present invention, it is possible to evaluate how a fault propagates in a software component from the specification of the software component.

The outline | summary of the reliability evaluation method of the software component by this embodiment. The function structure of the reliability evaluation apparatus of the software component concerning this embodiment. The example of the specification information described by the formal description language Alloy. This is an example of an abnormal specification described in the formal description language Alloy, and a part of the input specification is changed to a value other than the normal value from the specification information of FIG. 5 is a flowchart of software component reliability evaluation processing according to the present embodiment.

  Exemplary embodiments of the present invention will be described in detail below with reference to the drawings.

  FIG. 1 is a diagram showing an outline of the reliability evaluation technique according to the present embodiment. Here, the case where the reliability of the software component 100 having two inputs x and y as inputs and two outputs a and b as outputs is described as an example. The interface specification and internal specification of the software component 100 are described in a formal description language. First, as a first step, comprehensive verification is performed using a formal verification function based on this specification. Thereby, it is verified that the software component 100 has no contradiction between the interface specification and the internal specification. Such a verification method is a method of using a general format verification function.

  In the present embodiment, next, the input specification is changed to a value other than the normal value. The “normal value” means a value specified in the acquired interface specification. Here, the software component 100 takes two inputs x and y, but changes one of the inputs to a value other than the normal value. Based on the specification information thus changed, comprehensive verification is performed using the format verification function. Here, when an instance (counterexample) that does not satisfy the output interface specification is found, if an abnormality (failure) is input to the input whose specification has been changed, the failure can propagate to the above output. I understand that. In FIG. 1, it can be seen that there is a counterexample that does not satisfy the output specification in the output a when the input y is set to a value other than the normal value. Therefore, it can be seen that the fault input for input y propagates to output a.

  Such an abnormal propagation analysis for the software component is executed for a plurality of software components constituting the system, and the failure propagation path is stored in the storage unit. From this analysis result, a fault propagation path between software components can be calculated. That is, it is possible to evaluate the reliability of the entire system.

<Outline of configuration>
FIG. 2 is a diagram illustrating a functional configuration of the reliability evaluation apparatus 1 according to the present embodiment. The reliability evaluation apparatus 1 is configured as a computer including a main storage device such as a CPU and a RAM, an auxiliary storage device such as an HDD and a DVD-ROM, an input device such as a keyboard and a mouse, and a display device such as a display as hardware. can do. The operating units (OS) and application programs (AP) stored in the HDD or the like are expanded on the memory and executed by the CPU, thereby realizing each functional unit shown in FIG. Here, an example in which the reliability evaluation apparatus 1 is configured from one computer has been described. However, the reliability evaluation apparatus 1 is configured by a plurality of computers connected via a network or the like working together. Also good. Moreover, a part or all of each functional unit may be configured by dedicated hardware.

The specification information acquisition unit 2 is a functional unit for importing specification information described in a formal description language into the reliability evaluation apparatus 1. FIG. 3 shows an example of specification information described in the formal description language Alloy. There are various possible ways of acquiring the specification information. For example, it is conceivable to read and acquire a specification information file stored in an HDD or DVD-ROM, or to acquire a specification information file via a network. The user may input directly from the input device. Further, design information described in an architecture description language (ADL) or the like may be acquired and automatically generated from this design information. A person skilled in the art can easily understand that specification information described in a formal description language is created from design information described in ADL.

  The abnormal specification creation unit 3 is a functional unit that creates specification information (hereinafter, referred to as an abnormal specification) in which any input other than the normal value is included in the specification information acquired by the specification information acquisition unit 2. FIG. 4 shows an example of an abnormal specification described in the formal description language Alloy. The abnormal specification can be created by inverting one of the input interface restrictions in the normal specification (logical negation operation). If a range of values that can be input is specified, a unique abnormal specification can be obtained by inverting normal input.

  The model checking unit 4 is a functional unit that comprehensively verifies whether a specification (model) described in a formal description language is satisfied by a mathematical method. As the model checking unit 4, a known model checking tool such as an Alloy Analyzer can be used.

  The fault propagation path storage unit 5 is a storage unit that stores an output that does not satisfy the output interface specification in association with an abnormal input when model checking is performed based on the abnormal specification. For example, by storing the input y and the output a in association with each other, it can be understood that a failure may propagate to the output a when there is an abnormal input to the input y. This information can be used for system reliability evaluation.

  The failure propagation path display unit 6 displays a failure propagation path over the entire system from the failure propagation path of each software component stored in the failure propagation path storage unit 5 and the connection relationship between the software components constituting the system. It is a functional part for making it display on.

<Specification description>
FIG. 3 describes the input / output interface and internal specifications shown in FIG. 1 in a formal description language Alloy. Here, a very simple case is used as an example, but more complicated specifications can be described. For example, you may describe the condition of the value that multiple outputs should take at the same time, the time series restrictions of a certain output, etc., and the normal value range will change depending on the internal state of the software component. May be.

  FIG. 4 shows an abnormal specification created by the abnormal specification creation unit 3 based on the specification shown in FIG. FIG. 4 shows an abnormal specification when y (InY) in the input is changed to a value other than the normal value. Basically, an abnormal specification can be created by applying a logical negation to the input-related constraints among normal specifications.

<Processing flow>
FIG. 5 is a flowchart showing the flow of the software component reliability evaluation processing method according to this embodiment. FIG. 5 is a flow of reliability evaluation for one software component, that is, one specification description.

In step S2, the specification information acquisition unit 2 acquires the interface specification information (normal specification) of the inspection target software component. Typically, the specification description file is read. However, the specification description file may be automatically created from design information described in ADL or the like.

  In step S4, based on the acquired normal specification information, model checking is performed by exhaustive verification using the model checking unit 4. Thereby, it is verified whether or not the software component satisfies the requirements described as the interface specification. This is a method of using a conventional model checking unit (such as an Alloy Analyzer). If a counterexample is found at this point, revisit the specification.

  In step S6, one of the software component inputs is selected, and the abnormal specification creation unit 3 creates an abnormal specification in which the specification of the input selected in step S8 is changed to indicate a value other than the normal value. In step S10, model checking is performed using the created abnormal specification. If a counterexample is found as a result of this model check (S12-YES), in step S14, the input other than the normal value is associated with the output that does not satisfy the specifications and stored in the fault propagation path storage unit 5. For example, the input y and the output a are stored in association with each other.

  In step S16, it is determined whether or not the input specification is set to a value other than the normal value for all inputs for this software component. If there is an input that has not been set to a value other than the normal value, the process returns to step S6. In the next inspection, an abnormal specification in which only a new input is set to a non-normal value is created. For example, after the model check is performed with only the input x other than the normal value, the model check is performed with only the input y other than the normal value and with the input x having a normal specification. After executing model checking for all inputs other than normal values, the reliability evaluation for this software component is terminated.

  The reliability evaluation of the software component is preferably performed not only on one component but also sequentially on a plurality of components constituting the system. That is, for each software component, processing shown in the flowchart of FIG. 5, specifically, acquisition of specification information, creation of abnormal specifications, model checking based on abnormal specifications, and storage of fault propagation paths are executed. As a result, for each software component, a combination of input and output that becomes a failure propagation path is stored in the failure propagation path storage unit 5.

  When an abnormal propagation path is calculated for each software component in this way, the failure propagation path in the entire system can be grasped based on the input and output stored in association with the failure propagation path storage unit 5. it can. For example, the failure propagation path display unit 6 can display how a failure occurring at a certain point propagates. Further, the failure propagation path display unit 6 can also display a location that can be a true cause of a failure detected at a certain location. In this way, since it is possible to clarify how the entire system behaves in response to a failure, it can also be used for evaluation of the entire system (software) composed of a plurality of software components. For example, it is possible to analyze which software component failure (bug) may cause an event that impairs safety.

<Deformation>
In this example, Alloy is used as the formal description language, and Alloy Analyzer is used as the model checking tool. However, input specifications, internal specifications, and output specifications can be described, and it is verified whether the above specifications are satisfied by mathematical methods. Any technique can be used as long as it is possible. For example, SPIN, Promela, SMV, LTSA, etc. can be used.

In the above description, both model checking based on the acquired specification (step S4 in FIG. 5) and model checking based on the specification whose input is changed to a value other than the normal value (step S10 in FIG. 5) are performed. Does not necessarily have to be done. In other words, if it is guaranteed that the created specifications are consistent, only the model check based on the abnormal specifications may be performed to examine only how the fault propagates.

  In the above description, only the case where inputs are set abnormally one by one has been described. However, it is also possible to perform model checking with a plurality of inputs set to abnormal simultaneously.

DESCRIPTION OF SYMBOLS 1 Reliability evaluation apparatus 2 Specification information acquisition part 3 Abnormal specification preparation part 4 Model check part 5 Fault propagation path memory | storage part 6 Fault propagation path display part

Claims (8)

A computer having a model formal verification function
A specification information acquisition step for acquiring specification information including input interface specifications, output interface specifications, and internal specifications of the software component;
A verification step of verifying the software component by the format verification function according to the specification information in which the input interface specification in the specification information is changed to a value other than a normal value;
When an example of an output value that does not satisfy the output interface specification is found in the verification step, the input changed to a value other than the normal value and the output that does not satisfy the output interface specification are stored in association with each other. A fault propagation path storing step;
A method for evaluating the reliability of software components. The software component takes a plurality of input values,
In the verification step, for each input value, the software component is verified according to the specification information in which the input interface specification is changed to a value other than the normal value.
The software component reliability evaluation method according to claim 1. The computer further creates, from the specification information acquired in the specification information acquisition step, abnormal specification information in which the input interface specification is other than a normal value for each input value,
The software component reliability evaluation method according to claim 2. The computer is
For each software component of the system including a plurality of software components, execute the specification information acquisition step, the verification step, the failure propagation path storage step,
Displaying the fault propagation path of the system based on the input and output stored in association with each other in the fault propagation path storing step;
The software component reliability evaluation method according to claim 1. Storage means;
Specification information acquisition means for acquiring specification information including software interface input interface specifications, output interface specifications, and internal specifications;
When the software component is verified by formal verification according to the specification information obtained by changing the input interface specification in the specification information to a value other than a normal value, and an example in which the output value does not satisfy the output interface specification is found in the verification The verification means for storing the input changed to other than the normal value and the output not satisfying the output interface specification in the storage means in association with each other,
A software component reliability evaluation apparatus comprising: The software component takes a plurality of input values,
The verification means, for each of the input values, to verify the software component according to the specification information that has changed the input interface specification other than the normal value,
The software component reliability evaluation apparatus according to claim 5. From the specification information acquired by the specification information acquisition means, further comprising abnormal specification information creating means for creating abnormal specification information in which the input interface specification is other than the normal value for each input value,
The software component reliability evaluation apparatus according to claim 6. For each software component of the system including a plurality of software components, verify by the verification means,
Displaying a fault propagation path of the system based on the input and output stored in association with each other in the storage means;
The reliability evaluation apparatus of the software component in any one of Claims 5-7.

Images