상태기반검사의 최적주기려면 조건부 블록의 두 경로를 [그림 1]에서와...

2009. 4.

(주)한국신뢰성기술서비스

상태기반검사의 최적주기

분석을 위한 시뮬레이션

Design Reliability, Design Future!!!

ii http://www.korts.co.kr

목 차

상태기반검사의 최적주기 분석을 위한 시뮬레이션........................................................... 1

1. 개요 ................................................................................................................... 1

2. 상태기반 과업의 배경 ........................................................................................... 1

3. RENO를 이용한 최적 검사주기 분석 ........................................................................ 2

3.1 한 개의 과업에 대한 최적 검사주기 분석 예제 .................................................. 2

3.1.1 추가로 고려할 사항 ............................................................................ 12

3.2 과업의 일괄처리 예제 ................................................................................... 12

4. 결론 .................................................................................................................. 16

5. 참고 문헌 .......................................................................................................... 16


http://www.korts.co.kr 1

상태기반검사의 최적주기 분석을 위한 시뮬레이션

1. 개요

본 자료에서는 RENO 소프트웨어를 활용하여 어떤 한 개 품목에 대한 상태기반검사(On-

condition Inspection)의 최적 주기를 결정하는 방법에 대해 소개한다. RCM(Reliability

Centered Maintenance) 분석의 주된 결과물은 해당 품목에 필요한 일련의 유지보수 과업에

대한 내용일 것이다. 또한 유지보수에 필요한 과업의 계획이나 일괄처리를 최적화하는 것은

중요한 일이다. RENO는 의사결정이나 위험도 분석을 위한 전용 시뮬레이션 소프트웨어이다.

2. 상태기반 과업의 배경

대다수의 품목들은 시간이 흘러감에 따라 마모가 발생한다는 생각은 점차 감소하고 있다. 이

로 인해 상태를 기반으로 한 검사 기법의 적용이 증가하게 되었고, 고가 부품에 대한 정밀검

사나 교체와 같은 Hard Time(또는 High Time) 과업의 적용은 감소하게 되었다. 그 결과 상태

기반 과업은 RCM 분석의 필수 부분으로 점차 중요하게 인식되고 있다.

상태기반 과업은 주기적 또는 연속적인 검사를 통해 기능 고장이 발생하기 전에 잠재된 고장

상태를 찾고자 하는 데 그 목적이 있다. 검사로 잠재된 고장 상태가 발견되면 사후보전(또는

예방보전) 활동이 수행되며, 발견하지 못하면 아무런 조치 없이 계속 운용된다. 상태기반검사

를 수행하게 되면 아직 수명이 다 되지 않은 품목을 교체하는 데 소요되는 적지 않은 비용을

절약할 수 있는 효과가 있다.

RCM 관련 기준서에는 안전성과 연관된 상태기반 검사는 고장 발생 확률을 허용 수준으로 저

감하기 위해 주기적으로 검사를 수행해야 한다고 언급하고 있다. 주기를 결정하기 위해서는

다음과 같은 인자들이 필요하다.

- 허용 고장 확률(고장의 심각도에 따라)

- 검출 확률(검사 종류에 따라)

- PF(Potential failure to Functional failure) 주기


2 http://www.korts.co.kr

하지만 안전성과 관련이 없는 검사의 경우에는 기기의 수명을 최대로 하기 위해 비용 기반으

로 주기를 결정하게 된다. 검사를 하거나 필요한 사후보전 활동을 수행하는 데 소요되는 비용

은 고장이 발생한 후 소요되는 비용과 비교하여 평가해야 한다. 검사 주기가 길어지면 검사

비용은 감소하게 되지만 검사 횟수가 줄기 때문에 더 많은 고장이 발생할 수 있다. 다른 한편,

검사 횟수가 많아지면 고장 발생은 줄겠지만 검사 비용이 더 증가하게 된다. 그러므로 총 기

대비용을 최소로 하는 최적 검사 주기를 결정하는 것이 필요하다.

3. RENO를 이용한 최적 검사주기 분석

3.1 한 개의 과업에 대한 최적 검사주기 분석 예제

ReliaSoft 사의 RENO 소프트웨어는 어떤 형태의 확률론적 또는 결정론적인 시나리오를 분석

및 시뮬레이션을 하기 위한 편리한 환경을 제공한다. RENO는 어떤 문제를 분석하기 위해 코

딩을 하는 방식 대신에 순서도를 이용하여 간단히 모델을 만들고 모델에 대한 변수나 함수 등

을 정의한 후 시뮬레이션을 수행하여 결과를 얻는 방식을 사용한다.

RENO를 이용하여 어떤 품목에 대한 최적 상태기반검사 주기를 분석하기 위해서는 여러 변수

와 상수에 대한 정의가 필요하다. 예를 들면, 상수에는 잠재된 고장의 수리를 위한 고정된 예

방 보전 비용, 시간 당 고장 비용, 고정된 검사 비용, PF 주기 등이 해당된다. 방정식의 변수

에는 기능 고장의 수리를 위한 사후 보전 비용, 최종 검사를 수행한 시간, 총 검사 비용 등이

해당된다. 확률변수에는 사후 보전 활동에 대한 수리 시간의 분포, 고장 분포 등이 해당된다.

일부 방정식 변수와 확률변수는 상황에 따라 상수(또는 반대로도 가능)로 정의될 수 있음에 유

의한다.



[그림 1] 최적주기 분석을 위한 RENO 순서도

[그림 1]은 어떤 한 개 품목 A에 대한 최적 검사 주기를 구하기 위해 만든 순서도이다. RENO

에서 이 모형을 만들려면, 우선 그 품목의 마모(즉, PF의 시작)의 시작을 나타내기 위해

Standard Block을 순서도에 추가한다.

[그림 2]의 블록은 고장 분포(확률변수로 정의: [그림 3])로부터 고장 시간을 생성한다. 생성

한 고장 시간이 PF 주기(상수로 정의: [그림 4])보다 클 경우 마모의 시작을 결정하기 위해 고

장 시간에서 PF 주기를 뺀다. 생성한 고장 시간이 PF 주기보다 작을 경우에는 고장 시간만 사

용한다.



[그림 2] 마모 시작 블록의 속성 정의

[그림 3] 확률변수 정의

[그림 4] PF 주기 정의



그런 다음, 고장 발생 전의 최종 검사가 잠재된 고장 상태를 발견했는 지에 대한 여부를 결정

하기 위해 순서도에 Conditional Block([그림 5])를 추가한다. 방정식 “Last_Inspection_A”([그

림 6])은 고장 발생 전에 얼마나 많은 검사가 수행되었는 지를 계산하는 변수로 계산을 수행

한 후 그 값을 정수로 변환하고 검사 주기(InspectionInterval 상수로 정의: [그림 7])를 곱한다.

이는 고장 전에 최종 검사가 언제 이루어질 것인지를 구하기 위한 것이다. 예를 들면, 500 시

간(확률변수 “FailureA”: [그림 3])에서 고장이 일어나고 검사 주기가 매 200 시간마다 이루어

진다면 "Last_Inspection_A" 방정식([그림 6])의 계산 결과는 400 시간이 된다.

("InspectionInterval" 상수로 입력한 초기값은 관계가 없으며 최적화 과정을 수행하는 동안에

값이 변하게 된다.)

[그림 5] 조건부(Conditional) 블록 속성 정의

[그림 6] Last_Inspection_A 방정식 정의



[그림 7] InspectionInterval 상수 정의

조건부 블록의 입력은 마모가 시작되는 시간이라는 점을 상기하자. 조건부 블록은 마모의 시

작이 최종 검사 전 또는 후에 일어나는 지를 결정한다. 마모가 최종 검사 전에 발생한다면 잠

재된 고장 상태가 존재한다는 것을 의미하며 검사하는 동안에 검출될 것으로 판단할 수 있다.

이 경우 그 품목의 기능 고장을 막기 위해 예방 보전을 수행하게 될 것이다. 그러므로 잠재적

고장을 예방하는 비용이 발생하게 되고, 순서도의 위에 있는 “True” 경로를 따라 시뮬레이션

을 수행하게 된다.

[그림 8]은 예방 보전(PM) 수행에 대한 Standard Block의 속성을 나타낸 것으로 각각의 수리

활동 비용("PMCost_A" 상수: [그림 9])를 구해서 단위 시간 당 예방 보전 비용을 계산하고,

이를 최종 검사가 수행된 시간으로 나눈다.

[그림 8] 예방 보전(PM) 수행에 대한 속성 정의



[그림 9] PMCost_A 상수 정의

다음 단계는 Standard Block(일반 블록), Function(함수) 및 Constant(상수)를 이용하여 모든

검사 비용에 대한 정보를 추가한다. "InspectionCostA_PUT" 함수([그림 10])은 고장 전에 얼

마나 많은 검사가 수행되었는 지를 결정한다. 그런 다음 고정된 각 검사 비용(상수: [그림

11])에 검사 횟수를 곱해 총 검사 비용을 구한다. 이전 방정식과 동일하게 검사 주기([그림

12])로 나누어 단위 시간 당 비용을 구한다. 이 방정식은 최소 한 번의 검사가 있을 경우에만

유효하다. 반면 검사가 한 번도 없을 경우에는 비용이 0이므로 IF 구문을 사용하여 나타낸다.

"A의 검사 비용 추가" 블록은 총 검사 비용에 이전 블록에서 계산된 PM 비용을 추가하게 되

며 시뮬레이션을 하는 동안 순서도의 “True” 경로를 따라 총 비용을 산출한다.

[그림 10] InspectionCostA_PUT 함수 정의



[그림 11] InspectionCostA 상수 정의

[그림 12] “A의 검사 비용 추가” 블록의 속성

조건부 블록([그림 5])에서 마모가 최종 검사 후에 발생했다고 결정되면 검사하는 동안에 잠

재된 고장 상태를 찾지 못했다는 것을 의미한다. 결과적으로 그 품목은 기능 고장이 일어날

것이므로 수리 비용을 구해야 한다. 이럴 경우 “False” 경로를 따라 시뮬레이션이 진행된다.

다음은 기능 고장에 대해 수리하는 비용을 추가하기 위해 사용될 Standard Block, 확률변수

및 상수에 대한 것이다. "A의 고장 비용" 블록([그림 13])에서 정의된 방정식에 따라 수리 비

용을 구하게 되며, 수리 시간([그림 14] x [그림 15])에 영향을 받는다. 그런 다음 검사 주기

로 나누어 단위 시간 당 비용을 구한다.



[그림 13] “A의 고장 비용” 블록의 속성

[그림 14] 수리시간에 대한 확률변수 정의

[그림 15] DowntimeCostPerHourA 상수 정의

검사로 향후 발생할 고장을 찾지 못했을 지라도, 검사가 수행되었기 때문에 모든 검사 비용을

추가해야 한다. 이는 순서도의 PM(“True”) 경로에 대해 위에서 언급한 것과 같이 처리된다.

반면에 순서도에서 CM(“False”) 경로에 대한 주기는 고장시간이 된다. 순서도 모형을 완성하



려면 조건부 블록의 두 경로를 [그림 1]에서와 같이 Summing Gate로 결합해야 한다. Result

Storage 블록([그림 1]에서 단위 시간 당 비용 블록)을 추가하면 총 비용에 대한 값과 그에

대한 결과를 화면에서 볼 수 있다.

시뮬레이션을 한 번 수행하면 "InspectionInterval" 상수로 입력한 초기값의 검사 주기에 대한

기대 비용을 산출하게 된다. 하지만 분석 목적은 검사 주기를 변화시켜 어떤 주기가 기대 비

용을 최소로 하는 지를 구하는 것이다. RENO의 Simulation Console 창에서 Sensitivity

Analysis 옵션을 사용하면 검사 구간을 상한과 하한뿐만 아니라 증가분을 명시하여 검사 구간

을 가변적으로 설정할 수 있다. 이 예에 대한 시뮬레이션 설정은 [그림 16]과 [그림 17]과 같

다.

[그림 16] Simulation Console 창의 General 탭



[그림 17] Simulation Console 창의 Sensitivity Analysis 탭

시뮬레이션이 수행되면 “단위 시간 당 비용 vs. 검사 주기”에 대한 결과 플롯이 [그림 18]과

같이 나타난다. 최적 검사 주기는 단위시간 당 비용을 최소로 하는 시점이 최적 검사 주기가

된다. 여기서는 매 60 시간이며 이때 단위시간 당 기대 비용은 0.093이 된다.

ReliaSoft RENO - www.ReliaSoft.com

단위 시간 당 비용 vs. 검사 주기

Flowchart: Optimum Inspection Interval for Single Task - Simulations per run: 20000 - Sensitiv ity Analysis (One Way): InspectionInterval - Multiple Analyses Disabled

검사 주기

단위 시

간 당

비용

30.000 70.00038.000 46.000 54.000 62.0000.080

0.400

0.144

0.208

0.272

0.336

Optimum Inspection Interval for Single Task

단위 시간 당 비용

User's NameCompany2009-03-04오후 7:01:58

[그림 18] 단위 시간 당 비용 vs. 검사 주기 플롯



3.1.1 추가로 고려할 사항

2.1 절에서 언급한 예제는 RENO를 이용하여 유지보수에 대한 최적주기를 구한 것이다. 비교

적 간단한 예제였지만 동일한 원리를 이용해 좀 더 복잡한 형태의 순서도나 의사결정 로직에

적용이 가능하다. 예를 들면, 잠재적 고장 상태가 있을 경우 항상 검출이 가능한 경우나 주어

진 과업에 대한 특정 검출 확률로 추정될 경우라면 검사 형태에 대해 좀 더 자세하게 순서도

를 만들어야 할 것이다. 잠재적 고장 상태의 검출 확률이 90%라면 90%는 검출이 되어 사후

보전 활동이 수행되지만 나머지 10%는 고장 날 때까지 동작하게 된다. 이러한 분석은 순서도

내에 조건부 블록을 하나 추가하면 된다.

모형에 추가로 고려할 수 있는 것은 비용에 관한 요소이다. 예를 들면, 검사와 사후 활동에 대

한 고정된 비용 대신에 복잡한 방정식을 사용한 시간에 종속적인 변수로 만드는 것이다. 또한

방정식 대신 비용에 대한 분포를 사용할 수도 있다.

3.2 과업의 일괄처리 예제

과업의 일괄처리(Packaging)란 여러 개별 작업을 효율적이면서 이행 가능한 유지보수 프로그

램으로 만드는 프로세스를 말한다. 이를 적절하게 사용한다면 고장이나 수리로 인한 정지 시

간을 줄일 수 있으며 자원을 효과적으로 활용할 수 있다.

이번 예제는 두 개 이상의 유지보수 과업을 일괄적으로 처리하는 방법에 관한 것이다. [그림

19]는 두 가지 과업에 대한 순서도이다. 이 순서도에서 각 과업은 고장 분포, 수리 시간, 비용,

PF 주기 등과 같은 자체의 특성이 각각 정의되어 있다. 여기서는 하나의 검사 주기만으로 두

개의 과업에 대해 일괄처리를 하려고 한다. 각 과업에 대한 순서도를 하나의 Summing Gate로

결합하면 두 개의 과업을 함께 수행할 때의 단위 시간 당 기대 비용을 최소화하게 된다.



[그림 19] 두 개 과업의 최적화를 위한 순서도

여러 과업의 일괄처리를 위한 더 효율적인 방법은 각 과업의 특성을 파악하기 위해 일반적인

모형을 만들고 RENO 프로젝트 내에서 표로 통합하는 것이다. [그림 22]는 이에 대한 순서도

를 보여준다. 일반적인 모형은 Start Flag 블록으로 시작하고, 현재 시뮬레이션을 수행하고 있

는 과업에 대해 기록하는 Counter 블록([그림 20])을 그 다음에 연결한다. 시뮬레이션을 할

때마다 Counter 블록은 1씩 증가한다. 다음은 Conditional 블록([그림 21])으로 시뮬레이션이

모형 내의 모든 과업을 분석했는 지를 확인한다. 이것은 카운터 블록의 값과 모형 내에 있는

과업의 총 수를 비교하게 된다.

[그림 20] Counter 블록의 속성



[그림 21] Conditional 블록의 속성

모든 과업에 대해 분석했다면 모든 비용의 합계는 Storage 블록을 이용하여 얻을 수 있다. 모

든 과업에 대해 분석하지 않았다면 순서도를 기반으로 시뮬레이션을 하게 된다. 몇 번의 검사

가 수행되었는 지와 최종 검사 시간에 대한 정보를 저장하기 위해 몇 개의 블록을 추가한다.

순서도의 끝에는 Start Flag에 다시 연결하기 위해 “Go to” Flag를 추가한다.

[그림 22] 여러 과업을 위한 일반적인 순서도



각 과업의 특성을 파악할 수 있도록 Table을 만들어 각 데이터를 저장한다. 이 표를 이용하여

사용자는 확률변수나 상수를 추가할 수 있으며 이를 모형에 추가할 수도 있다. [그림 23]은

일괄처리를 위한 두 가지 과업의 입력 정보를 갖고 있는 표이다.

[그림 23] Table 속성

위 표는 함수에 대한 변수를 만들 때 사용된다. 예를 들면, [그림 24]의 “Failure_Function”

함수는 해당 품목이 와이블 분포를 따르며 [그림 23]의 Input_Data 표에서 모수에 대한 정보

를 가져온 것이다. 순서도에서 "Get Failure" 블록은 함수를 참조하는 것으로 고장 시간을 얻기

위한 것이다. 수리 시간을 얻기 위한 함수에서도 동일한 로직이 사용된다.

[그림 24] Failure_Function 함수 정의



[그림 25] Get Failure 블록 정의

순서도 내의 대다수 블록은 동일한 방법으로 그 표를 참조한다. 예를 들어, 새로운 과업을 추

가해야 한다면, 새 블록을 추가할 필요가 없으며, 변수나 상수를 새로 추가할 필요도 없다. 단

지 표에 추가해야 할 과업의 특성을 추가하면 된다.

4. 결론

3절에서는 한 개의 유지보수 과업에 대한 최적 주기와 과업의 일괄처리를 최적화하기 위해

RENO 소프트웨어를 이용한 예제를 보여주었다. 유지보수에 대한 효율성과 유연성에 대한 요

구가 점차 증가하고 있기 때문에 이러한 형태의 모델링 방법은 유지보수를 계획하는 사람들에

게 현 상황을 변경하거나 적합한 계획을 새로 수립하는 데 유용하게 이용될 수 있다.

게다가 RENO의 시뮬레이션 기법을 이용하면 복잡한 유지보수 문제를 해결하는 데 소요되는

비용과 시간을 절약할 수 있다. 또한 여러 과업을 한번에 분석할 때 많은 연산이 필요하지만

짧은 시간 내에 해결할 수 있다.

5. 참고 문헌

[1] Moubray, John, Reliability-Centered Maintenance II, New York: Industrial Press, 1997.

[2] SAE JA1011, Evaluation Criteria for Reliability-Centered Maintenance Processes, 1999.

[3] SAE JA1012, A Guide to the Reliability-Centered Maintenance Standard, 2002.

[4] ReliaSoft, Reliability Edge, http://www.reliasoft.com/newsletter/v9i2/index.htm



주소: 서울시 송파구 오금동 80-7 큐빗빌딩 3층

전화:02-409-6701 팩스:02-409-6721

Email: [email protected] Web site: www.korts.co.kr

mailto:[email protected]

상태기반검사의 최적주기려면 조건부 블록의 두 경로를 [그림 1]에서와...

Documents