KR20180090073A

KR20180090073A - Method of Guarantee for Software Failure

Info

Publication number: KR20180090073A
Application number: KR1020170015023A
Authority: KR
Inventors: 조재현; 이승준; 신성민; 정원대; 양준언
Original assignee: 한국원자력연구원
Priority date: 2017-02-02
Filing date: 2017-02-02
Publication date: 2018-08-10
Also published as: KR101985783B1

Abstract

본 발명은 소프트웨어의 안정성을 확인하기 위해, 무고장이 보장되는 소프트웨어를 보장하는 방법에 관한 것이다. 더욱 상세하게는, 소프트웨어의 모든 변수를 공정 변수군과 내부 변수군으로 구분하여, 각각의 경우에 대해 시험경우를 도출한뒤, 두가지 변수의 시험경우를 조합하여, 무고장 소프트웨어를 얻기 위한 방법에 관한 것이다.The present invention relates to a method for ensuring software that is guaranteed to be non-failing in order to verify the stability of the software. More specifically, all the variables of the software are divided into process variable groups and internal variable groups, and the test cases are derived for each case, and then the test cases of the two variables are combined to obtain the software for the non-failure .

Description

{Method of Guarantee for Software Failure}

본 발명은 소프트웨어 무고장 보장 방법에 관한 것으로, 더욱 상세하게는 소프트웨어의 안전성을 확인하기 위하여 수행하는 시험 방법에 관한 것이다. 즉, 원자력발전소 디지털원자로보호계통에 구현되어 있는 소프트웨어에 대해서, 모든 변수를 공정 변수군(category)과 내부 변수군으로 구분하여, 각 변수군의 시험경우를 도출하고, 두가지 변수군의 시험경우조합을 통해, 모든 시험경우에 대해서 소프트웨어 시험 수행이 이루어지도록 하여, 무고장 또는 고신뢰도 소프트웨어를 보장하는 방법에 관한 것이다.BACKGROUND OF THE INVENTION 1. Field of the Invention [0001] The present invention relates to a software failure prevention method, and more particularly, to a test method performed to confirm software safety. That is, for the software implemented in the Nuclear Reactor Digital Nuclear Reactor Protection System, all variables are divided into process variable group and internal variable group, and test cases of each variable group are derived. To ensure that software testing is performed for all test cases, thereby ensuring no-fault or high-reliability software.

디지털계측제어기술은 아날로그계측제어기술에 비하여 측정치의 드리프트가 없으며, 방대한 자료를 처리할 수 있는 저장공간, 설계의 유연성 등 많은 장점을 지니고 있기 때문에, 원자력발전소에 도입되어 있다. 디지털계측제어계통과 기존 아날로그계통의 차이는 소프트웨어인데, 소프트웨어는, 디지털 신호를 통한 논리 구조로 되어 있어, 기존 하드웨어로만 구성되어 있는 아날로그 설비들과는 고장 성격이 매우 다르다. 예를 들어, 하드웨어와 같은 경우는 사용시간이 증가할수록 고장 날 확률이 증가하는 반면, 소프트웨어는 이미 내재되어 있는 결함에 의하여 고장이 발현되므로, 출시 직후 고장이 나거나 또는 결함이 발생하더라도 결함을 확인하지 못한다면 사용하는 동안 고장이 나지 않을 수도 있다. 상기 소프트웨어의 고장 메커니즘은, 기존의 기계 고장과는 다른 메커니즘으로, 소프트웨어의 고장 메커니즘을 미리 파악하는 것이 매우 중요하다.Digital measurement and control technology has many advantages such as the storage space for processing large data, flexibility of design, and is introduced into nuclear power plants, because there is no drift of measurement compared with analog measurement control technology. The difference between the digital measurement control system and the existing analog system is the software. The software has a logic structure based on the digital signal, and the characteristics of the failure are very different from the analog equipments constituted only by the existing hardware. For example, in the case of hardware, as the use time increases, the probability of failure increases. On the other hand, since the software has a failure due to an inherent defect, even if a failure occurs immediately after the release or a defect occurs, Failure to do so may result in failure during use. The failure mechanism of the software is a mechanism different from the existing machine failure, and it is very important to grasp the failure mechanism of the software in advance.

소프트웨어 고장 메커니즘을 파악하기 위한 기술이, 일본공개특허 2000-267889호(소프트웨어의 시뮬레이션 검증방식, 이하 종래기술)에 개시된 바 있다. 종래기술에서는, 하드웨어 모델을 복수 조합하여 연동시켰을 때, 각 하드웨어 모델의 시간 경과의 시뮬레이션을, 실제 동작과 비교하여 검증하는 방식에 대하여 개시되어 있다. 하지만, 종래기술에서는, 소프트웨어의 시뮬레이션을 검증하기 위하여 하드웨어가 별도로 더 필요하였다.A technique for grasping a software failure mechanism has been disclosed in Japanese Patent Application Laid-Open No. 2000-267889 (simulation verification method of software, hereinafter referred to as prior art). The prior art discloses a method of verifying the simulation of the elapsed time of each hardware model by comparing it with an actual operation when a plurality of hardware models are linked and combined. However, in the prior art, additional hardware was required to verify the simulation of the software.

일본 공개특허 제2000-267889호(소프트웨어의 시뮬레이션 검증방식)Japanese Patent Application Laid-Open No. 2000-267889 (simulation verification method of software)

본 발명은 상기한 문제점을 해결하기 위하여 안출된 것으로, 소프트웨어의 안전성을 확인하기 위해, 무고장 소프트웨어를 보장하는 방법에 관한 것이다. 더욱 상세하게는, 소프트웨어의 모든 변수를 공정 변수군과 내부 변수군으로 구분하여, 각각의 변수군에 대해 시험경우를 도출한 뒤, 두 가지 변수군의 시험경우를 조합하여, 모든 시험 경우에 대한 소프트웨어 시험을 수행함으로써 무고장 소프트웨어를 보장하는 방법에 관한 것이다.SUMMARY OF THE INVENTION The present invention has been made in order to solve the above problems, and it relates to a method for guaranteeing non-fault software in order to confirm the safety of software. More specifically, all the variables of the software are divided into process variable group and internal variable group, and the test case is derived for each variable group. Then, the test cases of the two variable groups are combined, Lt; RTI ID = 0.0 > software failures. &Lt; / RTI >

본 발명은, 디지털 원자로 보호 시스템에 구현된 소프트웨어의 안정성을 보장하는 방법에 관한 것으로, 원자로 보호 시스템에 구현된 다수개의 트립(100)을 나열하는 제1단계, 나열된 다수개의 트립(100) 중 하나를 선택하는 제2단계, 상기 제2단계에서 선택된 트립(100)에 사용되는 소프트웨어의 모든 변수를 추출하는 제3단계, 추출된 변수를 공정 변수군과 내부 변수군으로 분리하는 제4단계, 상기 공정 변수군과 상기 내부 변수군의 시험 경우를 도출하는 제5단계 및 상기 공정 변수군과 상기 내부 변수군의 시험 경우를 조합하는 제6단계를 포함하는 것을 특징으로 한다.The present invention relates to a method of ensuring the stability of software embodied in a digital reactor protection system, comprising a first step of listing a plurality of trips (100) implemented in a nuclear reactor protection system, one of a plurality of trips A third step of extracting all variables of the software used in the trip 100 selected in the second step, a fourth step of dividing the extracted variables into process variable groups and internal variable groups, A fifth step of deriving a test case of the process variable group and the internal variable group, and a sixth step of combining the process parameter group and the test case of the internal variable group.

또한, 상기 공정 변수군은 상기 공정 변수군에 대한 시험 경우 도출 과정에서, 상기 공정 변수가 기설정된 트립설정치에 도달할 경우, 공정 변수 신호를 디지털 신호로 변환하는데 발생하는 시간 지연에 따라 발생하는 공정 변수의 트립설정치 대비 초과분에 대해서 규명하는 것을 특징으로 하며, 상기 공정 변수는 트립설정치에서 초과된 초과분에 대해서만 시험을 수행하는 것을 특징으로 한다.Also, the process parameter group may be a process that occurs in accordance with a time delay occurring in converting a process variable signal into a digital signal when the process parameter reaches a predetermined trip setting value in the process of deriving a test case for the process parameter group Wherein the process parameter is characterized in that the test is performed only for an excess exceeding the trip setting value.

또한, 상기 내부 변수군의 시험 경우는 그레이박스 분석을 수행하며, 상기 그레이박스 분석을 통해 얻은 내부 변수들에 대한 조합을 도출하는 것을 특징으로 하며, 상기 소프트웨어 무고장 보장 방법은 모든 트립에 대하여 얻어진 시험 경우에 대해서, 각 시험 경우당 적어도 1회 이상 시험을 수행하는 것을 특징으로 한다. 또한, 상기 제6단계이후, 조합된 시험 경우에 대해 소프트웨어 시험을 수행하는 것을 특징으로 한다.In addition, the test case of the internal variable group performs a gray box analysis, and a combination of the internal variables obtained through the gray box analysis is derived. The software non-failure guarantee method is obtained for all trips The test case is characterized in that the test is carried out at least once per each test case. Further, after the sixth step, a software test is performed on the combined test cases.

본 발명의 소프트웨어 무고장 보장 방법에 따르면, 전체 시험 경우수를 도출하는 방법론에 의하여, 디지털계통 소프트웨어의 안전성 시험을 수행해야 하는 대상을 만들 수 있으며, 소프트웨어 내부의 취약점을 파악하고 더 나은 구조를 제안 가능하다. 또한, 무고장 보장 방법에 의해 무고장이 보장되는 소프트웨어를 얻음으로써, 발전소 등에서 사용할 안전등급 소프트웨어에 대한 요건을 충족시킬 수 있다.According to the method of guaranteeing software non-failure according to the present invention, it is possible to create a target to be subjected to the safety test of the digital system software by the methodology of deriving the total number of test cases, to identify vulnerabilities in the software, It is possible. In addition, by obtaining software that is guaranteed to be fault-free by the non-fault-proof method, it can meet the requirements for the safety-grade software to be used in power plants and the like.

도1은 본 발명의 일 실시예에 따른 보장 방법을 나타낸 간략도.
도2는 본 발명의 일 실시예에 따른 트립설정치를 나타내는 그래프.
도3은 본 발명의 일 실시예에 따른 내부 변수군 시험 경우 수 도출 블록도.BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a schematic view showing a guarantee method according to an embodiment of the present invention; FIG.
2 is a graph illustrating trip settings according to an embodiment of the present invention.
FIG. 3 is a block diagram illustrating an internal variable group test case number according to an embodiment of the present invention; FIG.

이하, 본 발명의 기술적 사상을 첨부된 도면을 사용하여 더욱 구체적으로 설명한다. 이에 앞서, 본 명세서 및 청구범위에 사용된 용어나 단어는 통상적이거나 사전적인 의미로 한정해서 해석되어서는 아니 되며, 발명자는 그 자신의 발명을 가장 최선의 방법으로 설명하기 위해 용어의 개념을 적절하게 정의할 수 있다는 원칙에 입각하여 본 발명의 기술적 사상에 부합하는 의미와 개념으로 해석되어야만 한다. Hereinafter, the technical idea of the present invention will be described more specifically with reference to the accompanying drawings. Prior to this, terms and words used in the present specification and claims should not be construed as limited to ordinary or dictionary terms, and the inventor should appropriately interpret the concepts of the terms appropriately It should be interpreted in accordance with the meaning and concept consistent with the technical idea of the present invention based on the principle that it can be defined.

따라서, 본 명세서에 기재된 실시예와 도면에 도시된 구성은 본 발명의 가장 바람직한 일 실시예에 불과할 뿐이고 본 발명의 기술적 사상을 모두 대변하는 것은 아니므로, 본 출원시점에 있어서 이들을 대체할 수 있는 다양한 변형 예들이 있을 수 있음을 이해하여야 한다.Therefore, the embodiments described in this specification and the configurations shown in the drawings are merely the most preferred embodiments of the present invention and do not represent all the technical ideas of the present invention. Therefore, It should be understood that variations can be made.

이하, 본 발명의 기술적 사상을 첨부된 도면을 사용하여 더욱 구체적으로 설명한다. 첨부된 도면은 본 발명의 기술적 사상을 더욱 구체적으로 설명하기 위하여 도시한 일예에 불과하므로 본 발명의 기술적 사상이 첨부된 도면의 형태에 한정되는 것은 아니다.Hereinafter, the technical idea of the present invention will be described more specifically with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are included to provide a further understanding of the technical concept of the present invention, are incorporated in and constitute a part of the specification, and are not intended to limit the scope of the present invention.

디지털원자로보호계통에 구현되는 소프트웨어의 경우 안전성을 확인하기 위하여 시험을 수행한다. 소프트웨어 시험에서는 시험 경우를 개발하고, 이를 반복적으로 소프트웨어에 넣어주어 예상하는 출력이 나오는 것을 확인한다. 본 발명의 일 실시예에 따른 소포트웨어 안전성 보장 방법은, 디지털 원자로 보호 시스템에 구현된 소프트웨어의 안전성을 보장하는 방법에 관한 것으로, 전체 시험 경우를 구하고 이에 대해서 소프트웨어 시험을 수행함으로써 무고장 또는 고신뢰도 소프트웨어임을 보장하는 방법에 관한 것이다.For software implemented in the digital reactor protection system, tests are performed to confirm safety. In software testing, you develop a test case and repeatedly insert it into the software to verify that the expected output is coming. A method for securing a software security according to an embodiment of the present invention relates to a method for securing the safety of software implemented in a digital reactor protection system, Lt; RTI ID = 0.0 > software. &Lt; / RTI >

도1은 본 발명의 일 실시예에 따른 보장 방법을 나타낸 간략도이다.FIG. 1 is a schematic view showing a guarantee method according to an embodiment of the present invention.

도1을 참조하여, 본 발명의 일 실시예에 따른 소프트웨어 무고장 보장 방법에 대해 좀 더 상세히 설명한다.Referring to FIG. 1, a method of ensuring software failure according to an embodiment of the present invention will be described in more detail.

즉, 본 발명의 일 실시예에 따른 소프트웨어 무고장 보장 방법은, 상기 디지털원자로보호시스템에 구현된 다수개의 트립을 나열하는 제1단계를 포함한다. 또한, 상기 제1단계에서 나열된 다수개의 트립중 하나를 선택하는 제2단계를 포함하며, 상기 제2단계에서 선택된 트립에 사용되는 소프트웨어의 모든 변수를 추출하는 제3단계를 포함한다. 즉, 하나의 트립에 포함된 모든 변수를 제3단계에서 추출하게 된다.That is, the method for guaranteeing software failure according to an embodiment of the present invention includes a first step of listing a plurality of trips implemented in the digital reactor protection system. The third step includes a second step of selecting one of the plurality of trips listed in the first step, and a third step of extracting all the parameters of the software used in the trip selected in the second step. That is, all the variables included in one trip are extracted in the third step.

상기 제3단계에서 추출된 변수들은, 제4단계에서 공정 변수과 내부 변수로 분리될 수 있다. 상기 제4단계에서 분리된 공정 변수 및 내부 변수는 각 변수의 시험 경우를 도출하는 제5단계를 거치게 된다.The variables extracted in the third step may be separated into process variables and internal variables in the fourth step. The process variables and internal variables separated in the fourth step are subjected to a fifth step of deriving test cases of the respective variables.

본 발명의 일 실시예에 따른 디지털원자로보호시스템은, 계통에 구현된 특정 트립을 포함하고 있다. 트립이란, 원자로에 이상현상이 발생하였을 때 원자로 안전회로 중의 하나가 작동하여 긴급히 제어봉을 노내에 삽입하여 핵분열 연쇄반응을 정지시키는 것으로, 원자로 보호 시스템은 다수개의 트립을 포함하고 있다.The digital reactor protection system according to an embodiment of the present invention includes a specific trip implemented in the system. Tripping means that when an abnormality occurs in a reactor, one of the reactor safety circuits operates and the control rod is urgently inserted into the furnace to stop the fission chain reaction. The reactor protection system includes a plurality of trips.

상기 공정 변수는, 외부에서 받아들이는 변수로서 소프트웨어의 주요 목적을 작동시키는 변수로서, 일 실시예로, 소프트웨어의 역할이 원자로의 압력이 낮아져 특정 압력이하가 되었을 때 트립을 발생시키는 경우엔, 원자로의 압력이 공정 변수군이다. 즉, 상기 공정 변수는 상태에 따라 변하는 변수로서, 원자력발전소 등과 같이 소프트웨어를 사용하는 곳에서 사용되는 디지털기기에 구현되어있는 소프트웨어, 즉 본 발명의 일 실시예에 따른 소프트웨어는 모두 원자력발전소의 공정 변수군들을 살펴보고 이 공정 변수군이 트립설정치에 도달하는 지를 모니터링 하다가, 트립설정치에 도달하면 신호를 내보내도록 구성되어 있다.The above process variable is a parameter for operating the main purpose of the software as an externally accepted variable. In one embodiment, when the role of the software causes a trip when the pressure of the reactor is lowered to a certain pressure or less, Pressure is the process variable group. That is, the process variable is a variable that varies depending on the state, and software implemented in a digital device used in a place where software is used, such as a nuclear power plant, that is, software according to an embodiment of the present invention, It is configured to look at the groups and monitor whether this process variable reaches the trip setpoint, and to signal when the trip setpoint is reached.

본 발명의 일 실시예에 따른, 상기 공정 변수군에 대한 시험을 도출하는 과정에 대해 좀 더 상세히 설명한다. 상기 공정 변수군이 트립설정치 이하에 있다면 이에 대하여 시험을 할 필요가 없다. 시험경우는 공정 변수군이 트립설정치에 정확히 도달하는 경우와 그 이후 '약간'에 대해서만 도출하면 된다. '약간'에 대한 설명은 아래와 같다. 공정 변수군은 계측기기에서 나오는 전압 및 전류로서 아날로그신호로 시작된다. 이것이 디지털기계로 들어가면서 아날로그신호-디지털신호 변환기 (Analog to Digital Convertor: ADC) 에 의하여 디지털 신호로 변경된다. 이 때 실시간으로 잡히는 아날로그신호는 스캔시간 (Scan Time Interval)에 의하여 시간 지연이 되면서 디지털신호로 저장이 된다. 이 때, 실제 아날로그 신호는 트립설정치에 도달하였으나, 스캔시간 지연에 의하여 디지털신호는 아날로그 신호가 트립설정치를 넘어선 지점에서 신호를 읽게 되는데, 이때 넘어서는 정도가 '약간'에 해당한다.The process of deriving the test for the process variable group according to an embodiment of the present invention will be described in more detail. If the process variable group is below the trip setting value, it is not necessary to test it. The test case can be derived only when the process variable group reaches the trip setpoint exactly and then only a little. The explanation of 'little' is as follows. The process variable family begins with an analog signal as the voltage and current from the measuring instrument. As this enters the digital machine, it is converted to a digital signal by an analog to digital converter (ADC). At this time, the analog signal captured in real time is stored as a digital signal with a time delay due to a scan time (Scan Time Interval). At this time, the actual analog signal reaches the trip setting value. However, due to the scan time delay, the digital signal reads the signal at a point where the analog signal exceeds the trip setting value.

도2는 본 발명의 일 실시예에 따른 공정 변수 시험 경우의 수를 나타낸 도출 그래프이다. 좀 더 상세하게는, 도2는 컴퓨터코드를 이용하여 특정 사고시 공정 변수 변화를 예측한 결과를 나타낸 그래프이다. 도2를 참조하여, 공정 변수군의 실시예에 대해 상세히 설명한다. 기입력된 컴퓨터코드를 이용하여 어떤 사고가 발생하는 경우에 대해서 공정 변수군이 어떻게 변하는지 그래프와 같이 예측 한다. 상기 도2에 도시된 바와 같이, 아날로그신호가 시간 Tm에서 트립설정치에 도달하였지만, 실제로는 디지털신호는 스캔시간 지연에 의하여 S1,S2,S3,..,S7 시점에서만 신호를 읽기 때문에, 실제로 트립은 S6에서 일어나게 된다. 따라서 공정 변수군에 대해서는 트립설정치에서부터 S6 때의 공정 변수군 값까지를 모두 시험을 수행해야 한다.2 is a graph showing the number of process variable test cases according to an embodiment of the present invention. More specifically, FIG. 2 is a graph showing the result of predicting a process variable change in a specific accident using a computer code. Referring to Fig. 2, an embodiment of the process variable group will be described in detail. Using the previously entered computer codes, predict how the process variable group changes when an accident occurs. As shown in FIG. 2, although the analog signal reaches the trip setting value at time Tm, the digital signal actually reads the signal only at S1, S2, S3, .., S7 due to the scan time delay, Lt; / RTI > occurs at S6. Therefore, for the process variable group, the test should be performed from the trip setting value to the process variable group value at S6.

상기 내부변수는 소프트웨어의 논리를 구성하는 모든 변수를 의미한다. 소프트웨어는 논리로 구성되어 있으며, 내부변수들에 의하여 논리가 구성 된다. 도3은 본 발명의 일 실시예에 따른 내부 변수군 시험 경우 수 도출 블록도이다. 내부 변수군에 대한 시험경우를 도출하기 위해서는 그레이박스 분석을 수행해야 한다. 상기 그레이박스는, 블랙박스와 화이트박스의 중간개념으로서, 내부의 변수들을 들여다보고 각 변수들의 의존성을 살펴보는 것을 의미한다.The internal variable means all variables that constitute the logic of the software. Software is composed of logic, and logic is constructed by internal variables. 3 is a block diagram illustrating an internal variable group test case number according to an embodiment of the present invention. In order to derive the test case for the internal variable group, a gray box analysis should be performed. The gray box is an intermediate concept between a black box and a white box, which means to look at the internal variables and look at the dependency of each variable.

도3을 참조하면, 본 발명의 일 실시예에 따른 소프트웨어에는 세 개의 Function Block Diagram (FBD)이 존재하며 각 FBD에는 여러 개의 입력과 여러 개의 출력이 존재한다는 것을 알 수 있다. 이 때, Safety System에 직접적으로 영향을 주는 것은 출력 C1이며, 출력 C2는 Safety System에는 영향을 주지 않는 것을 알 수 있다. 또한 출력 C1을 결정하는 것은 입력 C1, 입력 C2, 입력 C3이다. 또한, 입력 C1 및 입력 C2는 다른 FBD의 출력들에 의하여 결정되므로, 이는 시험 경우의 고려 대상이 아니다. 상기 소프트웨어의 내부 변수군 의존성 여부를 판단함으로써, 도3에 도시된 바와 같이, 입력 A3, 입력 A4, 입력 A5, 입력 B3, 입력 C3을 고려해서 시험 경우를 추출된다. 여기서 내부 변수군 의존성 여부에 의해 도출된 A3, A4, A5, B3, C3를 핵심변수라 일컫는다.Referring to FIG. 3, it can be seen that there are three Function Block Diagrams (FBD) in the software according to one embodiment of the present invention, and that there are several inputs and several outputs in each FBD. At this time, it can be seen that the output C1 directly affects the safety system and the output C2 does not affect the safety system. It is also the input C1, the input C2, and the input C3 that determine the output C1. Also, since the inputs C1 and C2 are determined by the outputs of the other FBDs, this is not a consideration of the test case. By determining whether or not the software is dependent on the internal variable group, a test case is extracted in consideration of the input A3, the input A4, the input A5, the input B3, and the input C3 as shown in FIG. Here, A3, A4, A5, B3, and C3 derived by internal variable dependency are called key variables.

상기 제5단계에서 공정 변수와 내부 변수에서 각각 추출된 시험 경우를 조합하는 제6단계를 거치게 된다. 또한, 본 발명의 일 실시예에 따른 무고장 보장 방법은, 상기 제6단계 이후, 조합된 시험 경우에 대해 소프트웨어 시험을 수행하는 것을 특징으로 한다.In the fifth step, a sixth step of combining test cases extracted from process variables and internal variables is performed. The method for guaranteeing non-failure according to an embodiment of the present invention is characterized in that after the sixth step, a software test is performed on a combined test case.

또한, 상기 공정 변수의 시험 경우는, 선택된 트립에 대해, 기설정된 컴퓨터코드에 따라 공정 변수 결과값을 예측할 경우, 기설정된 트립설정치로부터 실제 트립이 일어난 공정 변수 값 중에서 선택되는 것을 특징으로 한다.The test case of the process variable may be selected from process variable values that actually trip from the predetermined trip setting value when the process variable result value is predicted according to a predetermined computer code for the selected trip.

본 발명은 상기한 실시예에 한정되지 아니하며, 적용범위가 다양함은 물론이고, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 다양한 변형 실시가 가능한 것은 물론이다.It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.

100 : 트립100: Trip

Claims

A method for ensuring the stability of software implemented in a digital reactor protection system,
A first step of arranging a plurality of trips (100) implemented in a reactor protection system;
A second step of selecting one of the plurality of trips (100) listed;
A third step of extracting all variables of software used in the trip 100 selected in the second step;
A fourth step of separating the extracted variables into process variable groups and internal variable groups;
A fifth step of deriving a test case of the process variable group and the internal variable group; And
A sixth step of combining the process variable group with the test case of the internal variable group;
The method comprising the steps of:

The method according to claim 1,
When the process variable reaches the predetermined trip setting value in the process of deriving the test parameter set for the process parameter group, it is determined that the process parameter is in excess of the trip setting value of the process variable generated according to the time delay occurring in converting the process variable signal into the digital signal Wherein the step of identifying the software failure is performed.

3. The method of claim 2,
Wherein the test is performed only for an excess exceeding the trip setting.

The method of claim 1, wherein the test case of the internal variable group
Performing a gray box analysis, and deriving a combination of the internal variables obtained through the gray box analysis.

2. The method of claim 1, wherein the software fault-
Characterized in that for each test case obtained for all trips, the test is carried out at least once per each test case.

2. The method of claim 1, further comprising, after the sixth step,
And performing a software test on the combined test case.