신뢰성 공학

신뢰성 프로그램 계획

다수의 절차, 방법, 도구를 사용하여 신뢰성을 달성할 수 있다. 모든 시스템은 다른 수준의 신뢰성을 요구한다. 상업용 민항기는 다양한 조건 아래서 작동해야만 한다. 고장의 영향은 심대하지만 상당히 많은 예산을 투입할 수 있다. 연필깎이는 민항기 보다 신뢰성이 높을 수도 있지만, 훨씬 다른 작동 조건, 심각하지 않은 고장 영향, 훨씬 낮은 예산을 가지고 있다.
신뢰성 프로그램은 정확히 무슨 절차, 방법, 도구, 해석 그리고 시험이 특정 시스템을 위해 요구되는지 문서화하기 위해 사용된다. 복잡한 시스템의 경우 신뢰성 프로그램 계획은 별도의 문서이다. 간단한 시스템의 경우 시스템 공학 관리 계획 또는 통합 물류 지원 계획과 복합될 수 있다. 신뢰성 프로그램 계획은 성공적인 신뢰성 프로그램을 위하여 반드시 필요하고, 시스템 개발 초기에 개발된다. 신뢰성 공학자가 무엇을 하는가 뿐 아니라 다른 사람들에 의해 이루어지는 업무절차도 명세한다. 신뢰성 프로그램 계획은 프로그램 최고위 관리자가 승인한다.

신뢰성 요구사항

어떤 시스템에 있어서도 신뢰성 공학의 첫 번째 절차 가운데 하나는 알맞게 신뢰성 요구 사항을 명세하는 것이다. 신뢰성 요구사항은 시스템 자체, 시험 평가 요구 사항, 그리고 관련 절차와 문서를 가리킨다. 신뢰성 요구사항은 적절한 시스템/하부시스템 요구조건 사양서, 시험계획, 계약서에 포함되어있다.

시스템 신뢰성 매개변수

요구 조건은 신뢰성 매개변수로 명세된다. 가장 일반적인 신뢰성 매개변수는 고장 간 평균 시간 Mean_Time_Between_Failures (MTBF) 으로, 명세하는 다른 방법은 실패율 또는 주어진 기간 내의 고장 수이다. 이러한 매개변수들은 늘 사용되는 시스템에 매우 유용하다. (예를 들어 자동차, 기계류, 전자장치) MTBF가 증가하면 신뢰성도 증가한다. MTBF는 보통 시간으로 명세되지만, 다른 단위, 예를 들어 km나 싸이클로도 사용될 수 있다.
다른 경우, 신뢰성 명세는 임무 성공 확률이다. 예를 들어, 일정 대로 운행하는 정규 항공편 비행의 신뢰성은 무차원 확률변수나 백분율 값으로 명세될 수 있다.
임무 성공의 특별한 경우는 1발성 장치 또는 시스템이다. 이들은 활동 없이 가만히 있다가 딱 한번만 작동한다. 예를 들어 자동차 애어백, 열 전지 thermal battery, 미사일 등이 포함된다. 일발 신뢰성은 성공 확률로 명세되거나 관련된 매개변수에 포함된다. 일발 미사일 신뢰성은 명중률 요구 조건의 일부가 될 수 있다.
그러한 시스템의 경우, 요구시 실패 확률 probability of failure on demand (PFD) 이 신뢰성 척도가 된다. 이 PFD는, 수리 불가능한 시스템의 경우에는 임무시간과 실패율로부터 유도된다. 수리 가능한 시스템의 경우, 실패율과 평균 수리전 시간 mean-time-to-repair (MTTR) 으로 얻어진다. 이 척도는 한 시스템에 대해 유일하지 않을 수도 있다. 왜냐하면 척도가 요구의 종류에 따라 달라지기 때문이다. 시스템 수준 요구 사항 뿐 아니라, 신뢰성 요구사항은 중요 서브시스템에 관하여도 명세될 수 있다. 어떤 경우에나 신뢰성 매개변수는 알맞은 통계적 신뢰구간과 함께 명세되어야 한다.

신뢰성 시험 요구조건

신뢰성은 확률이므로 비록 매우 신뢰성 높은 시스템이라고 하더라도 고장의 확률은 있다. 그러나, 신뢰성 요구조건을 시험하는 것은 몇가지 이유에서 문제성이 있다. 한번의 검사로는 충분한 통계적 데이터를 얻을 수 없다. 복수 시험 또는 장기 시험은 보통 매우 비싸다. 어떤 시험은 비실용적이다. 신뢰성 공학으로 설계할 수 있는 것은 현실적이고 비용 부담이 적은 시험 프로그램으로, 시스템이 그 요구조건을 만족시킨다는 충분한 증거를 제공하는 것이다. 통계적 신뢰 수준으로 이러한 고민을 고려할 수 있다. 어떤 특정 매개변수는 신뢰 수준과 나란히 표시된다. (예: MTBF 1000시간에 90% 신뢰수준) 이러한 명세로부터 신뢰성 공학자는 요구 조건 만족 또는 불만족을 판명할 수 있는 명백한 시간 수 또는 고장 수 기준을 가진 시험을 설계할 수 있다.
신뢰성 매개변수값 조합과 신뢰수준은 개발 비용과 고객과 생산자 모두의 위험에 커다란 영향을 미친다. 조심스러이 최선의 조합을 선택하여야 한다. 신뢰성 검사는 여러 수준에서 이루어질 수 있다. (예를 들어 부품, 서브시스템, 시스템) 또한 극한 온도, 습도, 충격, 진동, 열 등 많은 시험 중 요소가 주지되어야 한다. 신뢰성 공학이 결정해야 하는 것은 효과적인 시험 전략으로 모든 부품이 적절한 환경에서 시험되어야 한다. 수년간 작동해야만 하는 시스템의 경우, 신뢰성 공학이 사용되어 가속 수명 시험을 고안할 수 있다.

신뢰성 절차에 관한 요구사항

신뢰성 공학은 또한 반드시 다양한 신뢰성 절차 요구사항과 시스템 개발, 시험, 생산, 그리고 운용 중의 문서화를 주지하여야 한다. 이러한 요구조건은 일반적으로 계약서 상 업무 규정에 명세되어 있으며 얼마만큼의 자유도를 계약자에게 허용하기를 원하는지에 따른다. 신뢰성 절차는 다양한 분석, 계획, 고장 보고를 포함한다. 절차 선정은 시스템의 중요성과 가격에 달려 있다. 중요한 시스템의 경우, 공식적인 고장 보고와 개발 전반에 걸친 검토 과정을 요구할 수 있다. 덜 중요한 시스템은 최종 시험 보고서만 의존할 수도 있다. 가장 일반적인 신뢰성 프로그램 절차는 신뢰성 프로그램 표준으로 문서화 되어 있다. (예: MIL-STD-785, IEEE-1332) 고장 보고 분석과 보완 시스템은 제품/절차 신뢰성 관찰을 위한 일반적인 접근법이다.

신뢰성 시험

신뢰성 시험의 목적은 잠재적 설계 문제를 가능한 빨리 발견하고 궁극적으로 시스템이 그 신뢰성 요구 조건을 만족한다는 믿음을 주는 것이다.
신뢰성 시험은 여러 단계에서 수준에서 실행될 수 있다. 복잡한 시스템은 부품, 회로기판, 단위, 조립품, 하부시스템, 그리고 시스템 수준에서 시험될 수 있다. 시험 수준을 표기하는 방법은 응용분야에 따라 다르다. 예를 들어 환경 스트레스 걸러내기 검사를 낮은 수준, 즉 조각 부품 또는 작은 조립품 수준에서 실시하면 문제를 더 높은 수준에서 발생하기 전에 발견할 수 있다. 시험은 각 통합 수준별로 최고 수준 시험, 개발 시험, 작동 시험 까지 망라하여 진행되어 따라서 프로그램 위험도를 낮춘다. 시스템 신뢰도는 각 시험 수준에서 계산된다. 신뢰성 성장 기술과 불량 보고 체제, 분석 및 수정 체제(FRACAS)가 때로 채용되어 시험이 진행됨에 따라 신뢰성을 향상시킨다. 이러한 광범위 시험의 결함은 시간과 비용이다. 고객은 더 많은 위험을 떠안는 대신 일부 또는 전부의 저수준 시험을 생략할 지도 모른다.
모든 시스템 요구 사항을 시험하는 것이 항상 가능한 것은 아니다. 어떤 시스템은 아마도 시험하기에는 너무 비쌀 것이다. 어떤 고장 양태는 몇 년 후에나 관찰할 수 있을 것이다. 어떤 복잡한 상호작용의 결과로 엄청난 수의 가능한 시험 예가 발생할 것이다. 어떤 시험은 제한된 시험 지역의 사용을 요구하거나 다른 제한된 자원의 사용을 필요로 할 것이다. 그러한 경우에는 시험에 대한 다른 접근 방식, 예를 들어 가속 수명 시험이나, 실험 설계 Design of Experiment DoE, 시뮬레이션이 사용될 수 있다.
희망하는 수준의 통계적 신뢰 구간도 신뢰성 시험에서 중요한 역할을 한다. 통계적 신뢰는 시험 시간을 늘리거나 시험 항목을 늘림으로써 증가한다. 신뢰성 시험 계획은 최소의 시험 단위와 시험 시간으로 명세된 신뢰성을 달성하도록 고안된다. 시험 계획이 달라지면 생산자와 고객에 대한 위험의 수준도 달라진다. 양자의 희망하는 신뢰성, 통계적 신뢰도, 그리고 위험 수준이 최종 시험 계획에 영향을 미친다. 좋은 시험 요구 사항은 고객과 개발자가 미리 어떠한 신뢰성 요구사항이 시험될 것인지 확인시켜 주는 것이다.
신뢰성 시험의 열쇠 중 하나는 불량을 어떻게 정의하는가 하는 것이다. 비록 이것이 뻔해 보여도 많은 경우 분명하게 불량인지 시스템 부족인지 알기 힘들다. 시험 조건의 변동, 조작자의 차이, 날씨, 예상하지 못했던 상황으로 소비자와 시스템 개발자 사이의 이견을 만들 수 있다. 이 문제에 대한 한가지 전략은 배점 회의 scoring conference를 여는 것이다. 배점 회의에는 고객, 개발자, 시험 기관, 신뢰성 기관, 그리고 때때고 독립 옵저버가 참여한다. 배점 회의 절차는 statement of work에 정의된다. 참여자 그룹이 각 시험 케이스별로 성공 또는 실패로 배점된다. 이 배점이 신뢰성 공학자가 공식적으로 사용하는 결과가 된다.
요구사항 단계의 일부로 신뢰성 공학자는 시험 전략을 고객과 함께 개발한다. 시험 전략은 가능한 많은 데이터를 원하는 신뢰성 조직의 요구와 비용, 일정, 가용 자원과 같은 제한 조건 사이에서 취사선택한다. 시험 계획과 절차가 각 신뢰성 시험을 위하여 개발되고 결과는 공식 보고서에 문서화된다.

소프트웨어 신뢰성

소프트웨어 신뢰성은 신뢰성 공학의 특별한 면이다. 시스템 신뢰성은 그 정의에 따라 시스템의 모든 부분을 포함하며, 하드웨어, 소프트웨어, 운용자와 절차도 해당된다. 전통적으로 신뢰성 공학은 시스템의 주요 하드웨어 부품에 초점을 두었다. 디지털 집적회로가 널리 사용됨에 따라 소프트웨어가 거의 모든 시스템에서 점차로 중요한 부분이 되었다. 그러나, 소프트웨어와 하드웨어의 작동 방식에는 심대한 차이가 있다. 대부분의 하드웨어 불량은 부품 또는 재료 불량의 결과로 시스템이 그 의도된 기능을 수행하지 못하는 것이다. 하드웨어 부품을 수리 또는 교체 하는 것으로 시스템이 고장나기 전으로 돌아간다. 그러나 소프트웨어는 하드웨어가 고장나는 방식으로 고장나지 않는다. 대신, 소프트웨어 불량은 예측하지 못했던 소프트웨어 작동의 결과이다. 심지어 상대적으로 작은 소프트웨어 프로그램도 천문학적인 수의 입력 및 상태 조합이 가능하다. 소프트웨어를 초기 상태로 돌려놓아도 똑같은 입력과 상태를 만나면 똑같은 의도하지 않은 결과를 불러온다. 소프트웨어 신뢰성 공학은 이를 반드시 고려하여야 한다.
소프트웨어와 하드웨어 사이의 고장원인에 대한 차이점 - 소프트웨어는 마모되지 않는다 - 에도 불구하고 소프트웨어 신뢰성 공학을 연구자들 가운데는 하드웨어 신뢰성 연구에 사용되는 통계적 모델이 소프트웨어 신뢰성 척도로 유용하다고 믿는 사람들도 있다. 소프트웨어 사용자의 경험상, 소프트웨어를 오래 사용할 수록 결국 시험한 적 없는 방식으로 사용하게 되고 고장으로 이어지는 숨어있던 결함을 발견하게 된다는 것이다.
하드웨어와 마찬가지로 소프트웨어 신뢰성도 양질의 요구조건과 설계와 구현에 의존한다. 소프트웨어 신뢰성 공학은 중하게 소프트웨어 공학 절차에 의존하여 의도되지 않은 결과를 예측하고 대응 설계안을 만든다. 소프트웨어 품질 공학과 소프트웨어 신뢰성 공학은 하드웨어 품질과 신뢰성 보다 많이 겹친다. 우수한 소프트웨어 개발 계획은 소프트웨어 신뢰성 프로그램의 주요 요소이다. 소프트웨어 개발 계획은 설계 및 코드 작성 표준, 동료 검토, 단위 시험 unit test, 형상 관리 configuration management, 개발중 사용될 소프트웨어 척도 software metric와 소프트웨어 모델을 서술한다.
일반적인 신뢰성 척도는 소프트웨어 불량의 수로, 보통 1000 라인당 불량 수로 표현된다. 이 척도는 소프트웨어 실행 시간과 함께 대부분의 소프트웨어 신뢰성 모형과 예측에 주요한 역할을 한다. 이론상 소프트웨어 신뢰성은 결함 또는 결함 밀도가 적을 수록 높아진다. 그러나 결함 밀도와 고장 사이 평균 시간 MTBF 를 직접 연결시키는 것은 어렵다. 소프트웨어 결함이 코드에 분산되어 있는 방식, 결함의 위험도, 그리고 결함을 맞닥뜨리게 하는 입력의 조합의 확률 때문이다. 그럼에도 불구하고 결함 밀도는 신뢰성 공학자에게 유용한 척도로 사용된다. 다른 소프트웨어 척도, 예를 들어 복잡성도 또한 사용된다.
소프트웨어에 있어서 시험은 하드웨어에서보다도 더 중요하다. 비록 최선의 소프트웨어 개발 프로세스라고 하더라고 어떤 소프트웨어 결함을 초래하며 시험해 보기 전에는 거의 알 수 없다. 하드웨어에서와 같이, 소프트웨어도 개개의 단위로부터 시작하여 통합을 거쳐 최상위 수준까지 여러 수준에서 시험된다. 하드웨어와는 달리, 소프트웨엇 테스트에서 수준을 건너뛰는 것은 추천할만한 일이 아니다. 모든 단계에 걸쳐서 소프트웨어의 결함이 발견, 수정, 재시험된다. 신뢰성 예측은 결함 밀도와 다른 척도에 의해 갱신된다. 시스템 수준에서 MTBF 자료가 수집되고 신뢰성을 예측하기 위해 사용된다. 하드웨어와 달리, 정확히 같은 시험을 정확히 같은 소프트웨어 설정에 실시한다고 해서 통계적 신뢰도를 향상시키지는 못한다. 대신, 소프트웨어 신뢰도는 시험 실시 범위와 같은 다른 척도를 사용한다.
궁극적으로 소프트웨어는 하드웨어와 최상위 수준 시스템에서 통합되고, 소프트웨어 신뢰성이 시스템 신뢰성에 합산된다. 소프트웨어 공학 연구소의 역량 성숙도 모델이 일반적으로 신뢰성과 품질 면에서 전반적인 소프트웨어 개발 절차의 평가 수단이다.