JP4921917B2 - Software safety diagnostic device and program - Google Patents

Description

  The present invention relates to a software safety diagnostic apparatus for evaluating software reliability and safety.

In recent years, there have been frequent industrial accidents in Japan, such as factory accidents such as fire and explosion accidents, and elevator and water heater accidents. In the modern society, computers are frequently used in the control field, and safety functions that have been conventionally executed by mechanical hardware are being made into software. However, if there is a failure (failure) in these software, it cannot function as a safety system, and there is a possibility of harming employees, residents and users. In addition, safety now includes broad meanings such as property protection, environmental impact, and social impact in addition to the direct meaning of harm to humans.
Under such circumstances, IEC (International Electrotechnical Commission) established the international standard IEC 61508 for functional safety in 2000, and in Japan, JIS C 0508 “Electrical / Electronic / Programmable Electronic Safety Related Systems” It was established in 2000 as “functional safety”.

  IEC 61508 is a standard related to the safety of electrical / electronic systems and computers (software) used to reduce plant and system risks. Guideline 51 issued jointly by ISO (International Organization for Standardization) and IEC states that “absolute safety does not exist”. In other words, when intrinsic safety cannot be achieved as it is, reducing the risk to an acceptable target and ensuring a certain level of safety by using a safety system such as an emergency stop device is called “functional safety”. However, this standard requires that the risk be evaluated and kept within an acceptable range.

  By the way, a software failure (failure) is a deterministic cause failure. That is, failures (failures) are incorporated at the time of manufacture, and a probabilistic approach to general random hardware failures cannot be adopted. Therefore, this standard requires software to adopt software techniques specified according to the SIL (safety level: the level of safety reliability), and the software production is classified into 10 levels (see Fig. 1). Hereinafter, a total of about 100 software techniques are presented as best practices (best techniques according to SIL).

  Here, SIL is an index representing the reliability of the safety system. For example, SIL-1 refers to a failure probability (failure probability) that fails once at the time of operation of 10 to 100 times. As -2, 3, 4, and so on, it is defined at the stage where the reliability increases by one digit.

Conventionally, regarding safety evaluation by this SIL, Patent Document 1 proposes a system that inputs a safety level target value and a design parameter, calculates a safety level based on the SIL model, and displays it together with the input target value. Has been.
JP 2004-341814 A ISO / IEC Guidelines 51 “Guidelines for Putting Safety in Standards”, Japanese Standards Association, 1997 IEC 61508 “Functional Safety of Electrical / Electronic / Programmable Electronic Safety Related Systems”, 1998-2000 JIS C 0508 “Functional safety of electrical / electronic / programmable electronic safety-related systems”, Japanese Standards Association, 2000

  However, the problem here is that newly created software should use the best practices specified for each in accordance with the above life cycle, but for ready-made software or software purchased from other companies, SIL cannot be evaluated. If the SIL cannot be evaluated, it cannot be adopted for safety, and all conventional technical heritage is wasted. No effective and useful proposals have yet been shown for methods and devices for evaluating SIL for off-the-shelf software or software purchased from other companies.

  In addition, the above-described conventional technology determines whether or not the design materials are available in a check sheet format. If this is applied to purchased software, whichever survey is performed on the manufacturer, There are many cases where we do not know the quality of the materials, and it is not possible to make a proper evaluation simply by conducting a questionnaire survey.

  The present invention has been made in view of the above-mentioned circumstances, and SIL can be evaluated easily and simply for software that has already been produced by the company or software purchased from another company. When the required SIL is not satisfied as a result of the evaluation, it is easily and easily diagnosed which phase of the life cycle is insufficient and which technique in that phase can be additionally executed to achieve the required SIL. It is an object of the present invention to provide a software safety diagnostic device that can perform the above.

  In order to achieve the above object, a software safety diagnostic apparatus according to the present invention includes best practice data storage means for storing best practice data including software technique data and recommended guide data of software techniques for each safety level, Display means for displaying the software technique with reference to best practice data, and application for determining whether the application condition is satisfied or not for each software technique based on the application status input to the software technique displayed by the display means SIL that determines whether or not the level is satisfied for each safety level using the status input unit, the determination result of the application status input unit, and the recommended guideline data stored in the best practice data storage unit Diagnostic means and output of judgment result of the SIL diagnostic means And output means that, characterized by comprising a.

  In the present invention, the software technique stored by the best practice data storage means is displayed on a display or the like by the display means. And a user inputs the application condition with respect to a software technique with an application condition input means, confirming each software technique and detailed description which were displayed by the display means. Then, the SIL diagnosis means performs diagnosis by comparing the input data with the recommended guidelines of the technique stored in the best practice data storage means, and outputs the diagnosis result to the output means. The diagnosis result output means can easily evaluate the SIL of the target software by outputting the diagnosis result output from the SIL diagnosis means to a display, a printer, or the like. In this SIL diagnosis process, the SIL diagnosis is not executed immediately from the input application status, but the establishment or non-establishment of the application condition is determined for each software technique from the application status, and the SIL diagnosis is executed based on the determination result. Therefore, it is possible to make a diagnosis in a flexible manner corresponding to a survey of the importance and application status of software techniques for purchased software and the like.

  The software safety diagnosis apparatus according to the present invention further includes technique data correction means for correcting best practice data stored in the best practice storage means. Preferably, these detailed contents are stored in association with the software technique or recommended guideline, and a guidance function for displaying the detailed contents of the displayed software technique or recommended guideline is provided. This makes it easier to maintain best practices and enter application status.

  The software safety diagnostic device according to the present invention further includes an input unit for inputting a target SIL before diagnosis, reaches a determination result and a target SIL, a determination unit for the SIL diagnosis result and the target SIL, and the determination result and the target SIL. It has a means for outputting a technique application guideline necessary for the operation.

  In the present invention, when the target SIL is determined, the target SIL is input from the target SIL input means, and compared with the output result from the SIL diagnosis means, so that the SIL determination means can determine the determination result and the target SIL. Outputs application guidelines for techniques required for. By outputting the determination result by the SIL determination means and the application guideline of the technique necessary for reaching the target SIL to a display, a printer, etc., the wear technique required for the target software to reach the target SIL can be easily performed. Can be checked.

  The software safety diagnosis apparatus according to the present invention further includes a score defining means for defining a weighted score in the software technique data, a score storing means for storing the defined weighted score, and an application to the software technique. And a score calculation means for calculating the score of the software to be diagnosed based on the weighted score based on the situation and outputting it as the SIL reliability of the software.

  In the present invention, the SIL reliability is obtained as an objective numerical value by weighting each software technique and adding the weighted points according to the application situation.

  Thereby, it is possible to know not only whether or not the target SIL level is satisfied, but also the reliability of those satisfying the target SIL level.

  At this time, it is preferable to provide means for storing correction data of weighted scores for each piece of software to be diagnosed, and correction data changing means for changing the correction data according to the evaluation test result of the software. In addition to simply displaying the score by weighting, the SIL reliability in line with the actual situation can be obtained by correcting the weighting by confirming the accuracy of the application status and the quality of the software technique by an evaluation test using a questionnaire or the like. .

  The correction data changing means changes the correction data based on the ratio between the number of steps of the software and the number of test items performed for each language used for the software to be diagnosed, Each test item and the degree of association with the test item are stored, and the SIL reliability is calculated for each software technique by the score calculation means. When this SIL reliability is less than or equal to a predetermined value, the software technique can be easily improved by improving the quality or improving the quality of the software technique.

  The software safety diagnostic apparatus according to the present invention includes: an alternative technique defining means for defining an alternative method of software techniques; an alternative technique storing means for storing the defined alternative techniques; and an application status input to the software technique. An alternative technique display means for displaying the alternative technique, and a composite diagnosis means for determining whether or not a safety level is satisfied based on the application status for the input software technique and the application status for the alternative technique. Features. In the present invention, SIL diagnosis is performed including alternative techniques.

  In addition, the software safety diagnosis program according to the present invention stores best practice data including software technique data and recommended guide data of software techniques for each safety level, and is used on a computer that diagnoses the safety of software. A program that operates and displays software techniques by referring to the best practice data; and a process of determining an application type for each software technique based on an application situation input to the displayed software technique; Determining whether the application condition is satisfied or not from the application type, determining whether or not the safety condition level is satisfied for each safety level using the determination result and the recommended guideline data, and determining the result. And causing the computer to execute an output process.

  In the present invention, the application type is determined from the application status of the software technique, and whether the general application condition that is not affected by the safety level is satisfied or not is determined from the application type. Based on the determination result and the recommended guideline data. SIL diagnosis is executed to determine whether the safety level is satisfied.

  According to the present invention, it is possible to easily and easily evaluate SIL for software that has already been produced by the company or software purchased from another company.

  Moreover, when the required SIL is not satisfied as a result of the evaluation, which phase of the life cycle is insufficient and which technique in that phase is additionally executed can easily and easily determine whether the required SIL can be achieved. Diagnosis is possible.

Embodiments of the present invention will be described below.
FIG. 3 is a functional block diagram of the software safety diagnostic apparatus according to the first embodiment. Here, the software safety diagnostic apparatus 1 is configured by a general-purpose computer system, and the storage unit stores best practice data including software techniques presented in IEC61508 and recommended guidelines for each safety level. Practice data storage means 2 is provided. Further, as an arithmetic processing function executed by the CPU, a best practice correction means 10 for correcting software techniques and recommended guideline data stored in the best practice data storage means 2, and a best practice display for displaying the best practices on a display or the like. Means 3, best practice application status input means 4 for inputting the best practice application status via an input device such as a mouse or a keyboard or a network, recommended guidelines stored in the best practice data storage means 2, and the applied status entered SIL diagnosis means 5 for performing diagnosis processing, diagnosis result output means 6 for outputting a diagnosis result to a display, a printer, a network or the like, target SIL input means 7 for inputting a target SIL when there is a target SIL, SI SIL determination means 8 for making a determination based on the diagnosis result and the target SIL, and a target unachieved technique output means 9 for outputting the determination result and an application guideline for a technique necessary for reaching the target SIL to a display, a printer, a network, etc. Have.

  Next, the operation of the software safety diagnostic apparatus 1 having the above configuration will be described with reference to FIGS.

  As is well known, various standards related to computer software are defined by standardization standards in Japan or internationally. These standards are updated as needed. The best practice data storage means 2 is a database for storing the best practices presented in IEC61508, an international standard for functional safety. As shown in FIG. 4, a technique or measurement technique (software technique) and each technique It consists of detailed explanations and application guideline data that is mandatory or optional for each safety integrity level.

  Then, according to an instruction from the operator, the best practice display means 3 displays an input screen for best practice and application status for each phase on a display or the like. In addition, the detailed explanation of the best practice is displayed and output, which is used for the operator's reference, thereby making it easy to input the application status.

  The best practice application status input means 4 inputs the application status for each software technique according to the procedure shown in the flowchart of FIG. First, the operator is prompted to input the application / non-application of the best practice application status (step S1). If the input application status is “apply” (“Yes” in step S1), The user is prompted to enter presence / absence, and if there is a basis document based on the operator's input, the application type 1 is set, and if there is no basis material, the application type 2 is set (step S2). On the other hand, if the best practice is not applied in step S1, next, the input of presence / absence of a logical basis is prompted, and if there is a logical basis that is not applied based on the operator's input, it is applied type 3; Type 4 is set (step S3). In this way, the application status is classified into application types 1, 2, 3, and 4 in steps 4, 5, 6, and 7.

  An example of the input result is shown in FIG. In this way, the application type is input for all items of the software technique. However, in the case where the application is selected from the same technique according to the regulation, the input means outputs a guide that enables selection input, and inputs the input. Assist.

  Next, the SIL diagnosis means 5 compares the best practice application status with the recommended guidelines of the best practice data storage means 2 and performs diagnosis. Referring to the flowchart of FIG. 7, first, in step 8, the type of recommended guideline (required, optional, or none) is confirmed. If the recommended guideline is required, the application type is determined next (step S9). Outputs whether the condition is met or not. For example, when the type of the recommended guideline is “required”, the application status is confirmed in step 9, the condition of step 10 is satisfied for the application types 1 and 3, and the condition of step 11 is satisfied for the application types 2 and 4. Condition is not satisfied. On the other hand, if the recommended guideline is optional or absent in step S8, the conditions are satisfied (step S12, step S13).

  An example of the diagnosis result is shown in FIG. The above processing is executed for each software technique unit and each SIL unit. After the diagnosis is completed for all software techniques, the calculation and calculation are performed for each phase unit of the software life cycle, and each phase unit and the entire SIL are output.

  The diagnosis result output means 6 outputs the above-described diagnosis result to each phase of the software life cycle and the entire SIL to a display, a printer or the like.

  Further, by additionally inputting the target SIL from the target SIL input means 7, the SIL determination means 8 performs the determination by comparing the target SIL and the entire SIL based on the SIL diagnosis result and the target SIL, and sets the target SIL to the target SIL. On the other hand, by selecting the best practice that does not satisfy the condition, the best practice necessary to reach the target SIL is output as an application guideline. The target unachieved technique output means 9 outputs a determination result and an application guideline to a display, a printer, etc. for each phase of the software life cycle.

  According to the present embodiment, it is possible to know the SIL of the target software by diagnosing the SIL of the target software at the final stage of off-the-shelf software, software purchased from another company, or product development. This makes it possible to determine whether the target software should be adopted for the safety system. In addition, by inputting the target SIL additionally, the judgment result for the target and the application guideline for the best practice necessary to reach the target SIL can be obtained, so the final stage of product development by applying the best practice additionally It is possible to increase the SIL of off-the-shelf software or software purchased from other companies. At this time, additional application can be easily made by referring to the detailed explanation of the best practice and the application method.

  In addition, by diagnosing software SIL in the early stage of product development, the technique to be applied is clarified, so that the implementation plan of the applied technique in the future phase of the software life cycle as shown in FIGS. Can stand up. Similarly, by diagnosing the SIL of software under development at the milestone of the software life cycle, the diagnosis result up to the present state becomes clear, which leads to reduction of reworking work.

  This makes it possible to always control the initial stage of development as well as the SIL of the software under development.

  As mentioned above, the software techniques that are always presented in the latest IEC61508 and the best practice data of the recommended guidelines can be easily reflected, and the software safety diagnostic device can perform diagnosis with the latest best practice data. It becomes.

Next, a second embodiment will be described.
FIG. 9 is a functional block diagram of the software safety diagnostic apparatus according to the present embodiment.
3 is different from FIG. 3 in that the storage unit stores a weight storage unit 21 that stores weighting points defined for each software technique data, correction data storage unit 22 that stores correction data for weighting points, and information such as the number of test items. Is added to the calculation unit, and the calculation unit 31 calculates the score of the software to be diagnosed by the weighted score, and the correction data changing unit changes the weighted score according to the evaluation test result of the software. 32 is added. The weighting is high when application of software techniques is essential, and low when arbitrary. Others are the same as in FIG. 3, and the same functions are denoted by the same reference numerals and description thereof is omitted.

Next, the operation of the software safety diagnostic apparatus 1 having the above configuration will be described.
FIG. 10 is a flowchart showing the processing procedure of the score calculation means 31 and the correction data change means 32.

  First, the software safety level to be diagnosed is selected (S101). This may be selected by an input by an operator, or the safety level may be automatically selected in order by a computer and executed.

  Then, it is determined whether or not a condition is satisfied for the software technique, and when the condition is satisfied, a weighted score is extracted with reference to the score storing means 21 (S104).

  Then, the correction coefficient is calculated by a predetermined algorithm stored in the correction data storage means 22 (S106). FIG. 11 is a data example of the correction data storage means. In addition to language coefficients for each programming language, algorithm information for calculating correction coefficients is stored.

  As an algorithm for calculating the correction coefficient, for example, the correction coefficient can be obtained by equation (1).

Correction coefficient = (number of test items performed / number of program steps) × language coefficient (1)
Equation (1) is to calculate the correction coefficient according to the number of test items performed, the number of program steps, and the language of the program, and the correction coefficient increases as the number of tests performed increases. Moreover, the higher the language, the larger the language coefficient.

  Then, the weighted score is corrected with the calculated correction coefficient (S107), and the corrected score is added in consideration of the influence ratio of the test (S108).

  FIG. 12 shows an example of data stored in the score storage unit 21. For each software technique, a weighting score, a test type for verifying the software technique, and an influence ratio of the test to the software technique (a ratio with other tests) are stored. The test type and the number of test items for each test type are stored in the test data storage unit 23 illustrated in FIG.

  Using the data stored in these storage means, step S107 and step S108 can be calculated by the following equations.

Software technique score = Weighted score x Correction factor x Test influence ratio (2)
For example, if the number of test items performed is 50, the number of program steps is 10,000, and the language coefficient is 100, the correction coefficient is 0.5 from the above equation (1), and the weighting score is 50 and the test influence ratio is 0.8. Then, from the equation (2), the score in the test of the software technique is 20.

  The above steps S106 to S108 are repeated for all test types (S105a, S105b).

  Next, it is determined whether or not the calculated score exceeds a predetermined maximum value (S109). If it does not exceed the maximum value, the calculated score is stored as it is (S111). If the maximum value is exceeded, the maximum value is stored (S110).

  After the processing from step S103 to step S111 is repeated for all software techniques (S102a, S102b), the score for each software technique is added to calculate the score of software to be diagnosed.

  On the other hand, if the condition is not satisfied in step S103, it is determined that the safety level is not satisfied, and SIL nonconformity is output (S113).

  Among the above procedures, steps S105a to S111 are correction data changing means, and the others are processing procedures of the score calculating means.

  In general, even if there is evidence that software techniques are implemented, it takes a lot of labor and time to evaluate the quality of the evidence. In the present embodiment, the score is corrected by the number of steps of the program and the number of test items, with a pre-defined weighting score as an initial value. Therefore, the accuracy of application of the software technique, that is, the quality of the basis material is objectively evaluated. be able to.

  As a result, for example, it is possible to adopt a method in which verification is performed until the probability reaches 80% by the acceptance test on the purchase side.

  The software safety diagnostic apparatus according to the present invention can be used in the software industry for producing high-quality programs.

It is explanatory drawing of the life cycle in the software preparation by IEC61508. It is a model diagram of the life cycle in software creation by IEC61508. It is a functional block diagram of the software safety diagnostic apparatus by the 1st Embodiment of this invention. It is an example of a data of the best practice (best technique) data storage means of FIG. It is a flowchart which shows the process sequence of the adaptation condition input in the application condition input means of FIG. It is an example of the processing result of the application condition input means of FIG. It is a flowchart which shows the process sequence of the SIL diagnostic means of FIG. It is an example of the processing result of the SIL diagnostic means of FIG. It is a functional block diagram of the software safety diagnostic apparatus by the 2nd Embodiment of this invention. It is a flowchart which shows the process sequence of the score calculation means of FIG. 9, and a correction data change means. It is an example of a data structure of the correction data storage means of FIG. It is an example of a data structure of the score preservation | save means of FIG. It is a data structural example of the test data storage means of FIG.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... Software safety diagnostic device, 2 ... Best practice data storage means, 3 ... Best practice display means, 4 ... Best practice application status input means, 5 ... SIL diagnostic means, 6 ... Diagnosis result output means, 7 ... Target SIL input means,
8 ... SIL determination means, 9 ... target unachieved technique output means, 10 ... best practice data correction means, 21 ... score storage means, 22 ... correction data storage means,
23 ... Test data storage means, 31 ... Point calculation means, 32 ... Correction data change means

Claims (4)

A best practice data storage means for storing best practice data including software technique data and software technique recommendation guidelines data for each safety integrity level;
Display means for displaying software techniques with reference to the best practice data;
Application status input means for determining an application type for each software technique based on the application status input for the software technique displayed by the display means;
Using the application type and the recommended guideline data stored in the best practice data storage means, SIL diagnosis means for determining whether the condition is satisfied or not for each safety level for each software technique ;
Output means for outputting a result of determination by the SIL diagnosis means;
A software safety diagnostic device comprising:

2. The software safety diagnostic device according to claim 1, further comprising technique data correction means for correcting best practice data stored in the best practice storage means. The best practice storage means stores a detailed description in association with each item of the software technique data or the recommended guideline data,
3. The software safety diagnosis apparatus according to claim 1, wherein the display means has a guidance function for displaying a detailed explanation of the displayed software technique or recommended guideline. Target SIL input means for inputting a safety level target value of software to be diagnosed;
Determination means for determining a software technique necessary to reach the safety level target value from the diagnosis result by the SIL diagnosis means;
The software safety diagnostic apparatus according to claim 1, further comprising: