기능 안전에 관한 오해

제조업체들은 종종 시스템 또는 하위 시스템에 대한 PFD/PFH 값을 계산한 후 이것으로 SIL을 만족했다 주장합니다. PFH는 안전 관련 시스템 (또는 하위 시스템)의 시간당 위험한 오류 가능성을 나타내며, PFD는 안전 관련 시스템 (또는 하위 시스템)의 요구 대비 위험한 오류 가능성을 나타냅니다. 두 값 모두 임의의 하드웨어 결함(Random Hardware Fault)을 해결하는 데 쓰이며, 일반적으로 고장 유형, 영향 및 진단 분석(FMEDA – Failure Mode, Effect and Diagnostic Analysis)을 사용하여 계산합니다. 특정 SIL(Safety Integrity Level, 안전 무결성 수준)을 충족하려면 하드웨어의 임의 오류(Random Hardware Failure)을 제어하는 것뿐만 아니라 하드웨어 및 소프트웨어의 시스템적인 오류(Systematic Failure)에 대한 회피 및 제어가 필요합니다. 소프트웨어의 체계적인 오류 방지는 SC(Systematic Capability, 1에서 4까지의 값, 4개의 SIL 값에 해당함)으로 표현하며 안전 관련 시스템 개발 중에 사용된 방법 및 기술을 반영합니다. 따라서 안전 무결성 수준(SIL)은 언제나 PFD/PFH와 개발 프로세스, 즉 SC의 견고성에 대한 측정으로 구성됩니다.

때때로 시스템 통합 업체 및 플랜트 제조업체는 공급업체에 정상적인 작동을 위해 안전 무결성 수준(SIL)을 충족시키는 제어 시스템을 제공할 것을 요구하는데, 그렇게 함으로써 제어 시스템 및/또는 각종 유틸리티(utility)의 특정 신뢰성이 보장될 것이라고 믿기 때문입니다. 그러나 안전 기능(안전 관련 시스템에 의해 수행됨)의 목적은 제어 장비 (EUC - Equipment Under Control)의 안전 상태(Safe state)로 가도록 하는 것이지 가용성(availability)을 높이는 것은 아닙니다.

제어 장비(EUC)의 안전 상태(Safe state)는 위험원 및 위험성 분석(Hazard and risk analysis)의 결과이며 운영 모드에 따라 달라질 수 있습니다. 이러한 맥락에서, 고장 발생 시에 제어 장비(EUC)가 작동을 멈추는 것과 같은 fail safe(안전측 고장) 시나리오와, 제어 장비(EUC)가 최대한 작동하게 하는 것과 같은 fail operation 시나리오에 대한 전략 및 개념에 대한 오해를 자주 접하게 됩니다.

임의 하드웨어 오류(Random hardware failures) (및 신뢰성)는 고장률을 기반으로 계산합니다. 기능안전 측면에서, 고장률은 안전 장애와 위험 장애로 나뉩니다. PFD/PFH 값을 계산할 때는, 오직 위험 장애(안전 기능이 의도한 대로 작동하지 않는 경우)만 반영됩니다. 따라서 안전 무결성 수준 (SIL)은 안전 기능이 제어 장비 (EUC)를 안전 상태(Safe state)에 가도록 요구되었을 때 의도한 대로 수행되는지를 가늠하는 신뢰성 정도에 불과합니다.

아직까지도 운영 경험 (IEC 61508의 Route 2S)을 기반으로 기존 소프트웨어의 시스템 기능을 요구하는 접근법이 사용되고 있습니다. IEC TS 61508-3-1에 따르면, 관찰 기간에 소프트웨어의 모든 개별 장애를 감지하고 보고해야 하며, 입력 데이터의 모든 조합과 실행 순서 및 시간 관계를 문서화해야 합니다. 그러나 이 접근법은 일반적으로 실용적인 관점에서는 불가능합니다.

일반적으로 안전하지 않은 부품/구성 요소/디자인 요소들이 안전한 요소들과 혼합된 시스템 설계를 관찰하게 되는데, 이것은 복잡성과 시스템 비용을 줄이기 위한 표준 접근 방식입니다. 그러나 혼합된 안전 무결성 수준 설계 기법을 사용할 경우 무간섭의 보장(Freedom of interference)에 대한 증거가 필요합니다. 그리고 비 안전 부품의 가능한 고장 형태 및 안전 부품에 대한 관련 영향(예: 과전압, 잘못된 데이터, 안전 부품이 아닌 부분의 단락 등)을 고려하여, 하드웨어나 소프트웨어를 상세한 수준으로 분석해야 합니다.

필수 안전 소프트웨어의 개발에서 자동화 도구의 사용은 오늘날 효율성과 안전 측면에서 최신 기술입니다. 하지만 우리는 그러한 도구들이 오용되는 것을 여러 번 보았습니다. 소스 코드의 화이트 박스(white-box) 분석뿐만 아니라 소프트웨어 단위/모듈 사양을 기반으로 먼저 단위 테스트 사양을 작성하여야 합니다. 이때 목표는 소프트웨어의 일부분이 원하는 기능적 동작을 하는지 테스트하는 것입니다. 화이트 박스 분석이 요구될 수 있는 코드 레벨에서 요구되는 테스트 범위의 증거 제공 역시 충족되어야 하지만, 이것이 단위 테스트의 유일한 목표는 아닙니다.

현대의 복잡한 안전 관련 시스템에서 스마트 센서의 사용이 점점 더 중요 해지고 있습니다. 센서의 기능에는 필수 무결성(Integrity)이 제공되거나 전체 안전 기능에 대한 무간섭(freedom of interference)이 보장되어야 합니다. 일부 시스템 설계는 복잡한 스마트 센서(예: 로직 처리 장치, 통신 프로토콜 등)의 고장 모드를 어떤 외부 안전장치에 의존해, 필요한 진단 범위에 따라 고장 감지/반응 시간 등의 요소를 통해 진단 및 완화할 수 있다는 가정에 근거하여 이루어지는데, 이것은 잘못된 것입니다.

전원 공급 장치의 보호/감시 누락과 관련된 반복적인 문제가 있습니다. 안전기준에는 과전압/저전압 문제 조치를 어떻게 구현해야 하는지에 대해서는 구체적으로 명시되어 있지 않지만, 필요한 SIL 수준에 따라 적절한 보호 메커니즘이 마련되어야 합니다.  예를 들어 HFT>1이 필요한 설계에 대해 이중화된 과전압 보호 메커니즘을 사용하지 않는 것은 반복적으로 발생하는 전형적인 문제입니다. 전압 공급 모니터링(스위치 오프 및 안전 상태와 같은 필수 반응을 포함)은 전압 범위가 더 넓을 수 있기 때문에 과전압/저전압 상태에 의해 영향을 받지 않는 별도의 구성 요소에 의해 수행되어야 합니다. 짧은 순간의 과전압도 마이크로컨트롤러 일부를 영구적으로 손상할 수 있으므로, 과전압 후 마이크로컨트롤러 리셋은 적절한 조치가 아닙니다. 저전압의 경우, 저전압 문제가 지속하지 않는 한 리셋은 적절한 조치가 될 수 있습니다.

과열의 경우 지정된 범위를 벗어나도 올바르게 작동하는 구성 요소(예: 마이크로컨트롤러)는 과열 감지 및 (안전 상태(safe state) 실행, 전원 오프 등)의 적절한 반응을 할 수 없습니다. 이 경우에는 간단한 리셋 역시 도움이 되지 않으며, 과열 상태가 지속되고 있거나 스위치가 켜져 있는 동안에 이미 과열된 상태라고 가정해야 합니다. 저온의 경우, 안전 표준(예: EN 50129)에 의해 고려되지 않는 경우가 있지만, 적용 조건(사용자 설명서)은 장치가 모든 구성 요소에 대하여 지정된 온도 범위 내에서만 구동하는지 명확히 해야 합니다.

약어 SIL (안전 무결성 수준 Safety Integrity Level)은 여러 표준에서 사용됩니다. 그러나 표준마다 다른 프로세스, 건축 및 기술 요구 사항이 관련 있으며, 일부 표준은 ASIL (자동차 안전 무결성 수준 Automotive SIL)과 같은 다른 약어를 사용합니다. 어떤 사람들은 혼동과 오해의 위험이 있는 동일한 약어 (SIL)를 사용합니다.

예를 들어 SIRF (Sicherheitsrichtlinie Fahrzeug; EBA)에서 사용하는 SAS 수준 (독일어: 안전 무결성 수준 "Sicherheitsanforderungsstufe")은 EN 50128/EN 50129에서 사용하는 SIL 수준 ("안전 무결성 수준")과 다릅니다. SIRF (SAS)는 EN 50129의 부록 E에 열거된 조치의 일부만 사용하고, 조직적 조치 및 프로세스 조치가 적으며, 위험률에 대한 정의된 제한 사항 역시 없습니다. IEC 61508의 맥락에서의 SIL은 EN 50129의 맥락에서의 SIL과 다릅니다. SIL을 안전 무결성 수준 대신 소프트웨어 무결성 수준으로 정의할 경우 문제는 더 복잡해집니다 (예: EN 50657 참조).

안전검증이 안 되었거나, 동종 이중화가 적용된 시스템이 결합된 시스템의 SIL 수준을 올리는 것은 불가능합니다. 예를 들어, 여러 SIL2 시스템/채널을 단순히 결합하여 SIL을 SIL4로 증가시킬 수 없습니다 (예: 여러 SIL2 제어 시스템을 사용해 SIL3에 도달). 한 가지 이유는 SIL2 소프트웨어 프로세스가 SIL4 프로세스와 동일한 방식(무결성)으로 시스템 소프트웨어 오류를 방지하지 않기 때문입니다. IEC 61508 표준은 2개의 독립적인 시스템이 이중 채널 구조로 사용되는 경우 시스템 기능을 +1 증가시키지만, 동종 이중화의 경우에는 이것이 불가능합니다. 다른 표준(즉, EN 50129)은 이러한 가능성을 제공하지 않습니다.

결함 계통도 분석 (FTA – Fault Tree Analysis)시 공통 원인(common cause)을 놓치지 않아야 합니다. 모든 관련 분야에서 여러 부분에 동시에 영향을 줄 수 있는 고장(예: 전원 공급 장치 손실)은 basic event로 시스템의 결함 계통도에 포함되어야 합니다. 대안으로써 결함 계통도 분석 (FTA) 툴에서 "베타 계수[1]"를 사용하여 일반적인 원인 결함을 찾는 것 역시 가능합니다.

[1] Beta Factor(베터 계수): CCF (공통 원인 오류Common Cause Failures)는 여러 구성 요소의 고장을 초래하는 단일 결함임. β 계수는 고장율의 β %가 CCF에 기인하고 (1-β) %가 부품의 랜덤 고장율에 해당하는 것으로 추정됨.

SIL(안전 무결성 수준)의 정의는 특정 종류의 위험 분석/분류에서 파생된 원래 기능에 적용됩니다. 시스템/구성 요소의 경우 “SIL2 컨트롤러”, “SIL3 브레이크 시스템” 등과 같은 용어들이 일반적으로 사용됩니다. SIL이라는 용어는 정확하게 말하면, 특정 (안전) 기능에만 적용됩니다. 어떤 기능들이 안전 기능에 포함되는지 정의하는 것이 위험도 분석(risk analysis)의 목표입니다. 좀 더 정확히 정의하자면 "시스템이 최대 SILx까지 안전 기능을 구현할 수 있다”라고 정의할 수 있습니다. 이것은 해당 시스템이 표준의 프로세스, 설계 및 기술 요구사항을 충족했음을 의미합니다.

프로젝트를 시작할 때는, 안전성 관점에서 분석해야 할 시스템의 경계와 다른 시스템 과의 인터페이스가 명확하게 정의되지 않는 경우가 있습니다. 예를 들어 어떤 구성 요소가 시스템의 일부인지, 어떤 센서/액추에이터 변형을 고려해야 하는지는 명확하지 않습니다. 범위를 정의하지 않고 안전 분석을 시작할 수 없으며, 범위 변경 발생 시에 여러 번의 반복된 작업을 피할 수 없습니다.

특정 SIL로 분류된 안전 기능에 속하는 고장 감지 및 모니터링 블록 (진단 프로그램) 이라는 별도의 안전 무결성 수준 (SIL) 레벨은 존재하지 않습니다. 일부 표준에서는 필수 무결성 요구수준을 1씩 줄일 수 있지만, 기능적 안전 관점에서 진단은 안전 기능의 일부입니다. 무결성 요구 사항은 진단에도 적용됩니다. 추가 분해 분석을 통해 무결성 수준을 줄일 수 있지만, 일반적으로 안전 요구 사항을 배제하지는 않습니다.

일부 무결성/진단 조치는 시스템 시동 시 매번 수행됩니다(예: RAM 테스트, 플래시 CRC 검사, 출력 테스트 등). 이러한 시험은 진단 조치의 검증이나 안전 분석의 고장 감지 시간(fault detection time, 시험 간격 (test interval))에 사용되기 때문에 매우 중요합니다. 그러나 경우에 따라 운전 조건이 변경될 수 있습니다(새로운 프로젝트, 새로운 요구사항 등). 일부 시스템은 정기적으로 전원이 꺼진 상태 혹은 장시간 동안 전원이 켜진 상태로 유지됩니다. 예를 들어, 최근에 현대식 철도 시스템은 아침마다 재시동하지 않고 계속해서 전원을 켜 놓는 경우가 많습니다. 이러한 경우 의도된 진단 방법이 효과적이지 않을 것이기 때문에, 안전 분석 시 필요한 경우 정기적인 재시동은 안전 매뉴얼, 작업자 문서 등에 명시되어야 합니다.