맨위로가기

IEC 61508

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

IEC 61508은 전기, 전자, 프로그래머블 전자 안전 관련 시스템의 기능 안전에 대한 국제 표준이다. 이 표준은 7개의 파트로 구성되어 있으며, 안전 관련 시스템의 설계, 구현, 운영 및 유지보수에 대한 요구 사항을 제시한다. IEC 61508은 기계, 전기, 소프트웨어 등 다양한 분야에 걸쳐 적용되며, 안전 무결성 수준(SIL)을 정의하여 안전 기능의 위험 감소 정도를 평가한다. 자동차(ISO 26262), 철도(IEC 62279), 공정 산업(IEC 61511), 발전소(IEC 61513), 기계(IEC 62061) 등 다양한 산업 분야에서 파생 표준으로 활용되며, 제품, 프로세스 또는 시스템이 표준의 요구 사항을 충족하는지 제3자 기관의 인증을 받을 수 있다.

더 읽어볼만한 페이지

  • 안전 - 난간
    난간은 추락 방지, 보행 보조, 안전 확보를 목적으로 설치되는 구조물로, 설치 방향과 사용 목적에 따라 다양한 종류가 있으며, 여러 재료로 제작되고 최근에는 다양한 기능이 추가된 제품이 개발되고 있고, 건축 및 대중교통 분야에서 안전을 확보하는 데 사용되며, 높이, 간격, 재질 등에 대한 규격이 존재한다.
  • 안전 - 생물학적 위험
    생물학적 위험은 감염성 물질이나 유전자 변형 생물 등으로 인해 발생하는 위험으로, 실험실 감염 사고와 생물 무기 연구를 거쳐 인식되기 시작했으며, 위험도에 따라 분류되어 관리되고, 안전 관리를 위한 생물 안전 수준과 봉쇄 방법, 바이오시큐리티 대책이 중요하게 다루어진다.
  • IEC 표준 - ISO/IEC 646
    ISO/IEC 646는 ASCII 기반의 7비트 문자 인코딩 표준으로, 국가별 변형이 존재했으나, 최종 개정판은 ASCII와 호환되도록 정의되었고, 현재는 ITU-T 권고 T.50 IRA가 현행 표준으로 유지되고 있다.
  • IEC 표준 - POSIX
    POSIX는 유닉스 기반의 이식 가능한 운영체제 인터페이스를 표준화하기 위한 IEEE 표준군으로, 프로세스 관리, 파일 시스템 접근, 스레드 처리 등 핵심 서비스들을 규정하며 운영체제 간 호환성을 높이는 데 기여한다.
IEC 61508
개요
제목IEC 61508
설명기능 안전에 관한 국제 표준
상세 정보
범위전기/전자/프로그래머블 전자 안전 관련 시스템
발행 기관IEC
상태발행됨

2. 표준의 구성

'''IEC 61508''' 표준은 총 7개의 파트로 구성되어 있으며, 전기/전자/프로그래밍 가능 전자(E/E/PE) 시스템의 기능 안전에 관한 요구사항과 지침을 다룬다. 이 중 Part 1부터 Part 4까지는 규정(normative)이며, Part 5부터 Part 7까지는 참고 자료(informative)로 분류된다.

각 파트의 주요 내용은 다음과 같다.


  • '''IEC 61508-1''': 일반 요구 사항 - 전체 표준의 기본 틀과 안전 라이프사이클, 기능 안전 관리 및 문서화 요구사항을 규정한다.
  • '''IEC 61508-2''': E/E/PE 안전 관련 시스템 요구 사항 - 주로 하드웨어 설계 및 구현에 대한 요구사항을 다룬다.
  • '''IEC 61508-3''': 소프트웨어 요구 사항 - 안전 관련 소프트웨어의 개발 및 검증에 대한 요구사항을 규정한다.
  • '''IEC 61508-4''': 용어 정의 및 약어 - 표준 전반에 사용되는 용어와 약어를 정의한다.
  • '''IEC 61508-5''': 안전 무결성 수준(SIL) 결정 방법의 예시 - SIL을 결정하는 다양한 방법론과 예시를 제공한다.
  • '''IEC 61508-6''': Part 2 및 Part 3 적용 지침 - 하드웨어 및 소프트웨어 요구사항의 실제 적용을 돕기 위한 지침을 제공한다.
  • '''IEC 61508-7''': 기술 및 기법 개요 - 안전 관련 시스템 설계 및 분석에 사용될 수 있는 기술과 기법들을 소개한다.


IEC 61508은 IEC GUIDE 104에 따른 기본 안전 규격(basic safety publication)으로 분류되며, ISO/IEC GUIDE 51에서 정의하는 A, B, C 규격 체계와는 다르다. 표준을 이해하기 위해서는 기계, 전기, 소프트웨어 등 다양한 전문 분야의 지식이 필요하며, 각 분야별로 다른 시각에서 접근하는 경향이 있다.

2. 1. Part 1: 일반 요구 사항

IEC 61508-1은 전기/전자/프로그래밍 가능 전자 안전 관련 시스템의 기능 안전에 관한 국제 표준 시리즈의 첫 번째 파트로, 일반 요구 사항(General requirements)을 규정한다. 2010년 4월에 개정된 2.0 버전(IEC 61508-1 ed2.0)이 현재 적용되고 있다.

이 파트는 전체 IEC 61508 표준의 기반이 되며, 특히 기능 안전을 효과적으로 관리하기 위한 매니지먼트 체계와 시스템 개발부터 폐기까지 전체 수명 주기에 걸쳐 필요한 문서화에 대한 구체적인 요구 사항을 제시한다. 이는 시스템의 안전성을 체계적으로 확보하고 이를 입증하는 데 필수적이다.

주요 내용은 다음과 같다:

  • 안전 라이프 사이클(Safety lifecycle)의 정의 및 각 단계별 활동 관리
  • 기능 안전 매니지먼트 시스템의 구축 및 운영 절차
  • 요구사항 정의, 설계, 구현, 검증, 유지보수 등 안전 관련 활동의 결과물에 대한 문서화 요구사항


IEC 61508-1에서 제시하는 이러한 일반 요구 사항들은 후속 파트(Part 2: 하드웨어, Part 3: 소프트웨어 등)에서 다루는 상세 기술 요구 사항을 성공적으로 적용하기 위한 기본적인 틀을 제공한다.

2. 2. Part 2: 전기/전자/프로그래머블 전자 안전 관련 시스템에 대한 요구 사항

IEC 61508 표준의 두 번째 부분인 '''IEC 61508-2'''는 "전기/전자/프로그래밍 가능 전자 안전 관련 시스템의 기능 안전 - Part 2: 전기/전자/프로그래밍 가능 전자 안전 관련 시스템에 대한 요구 사항"이라는 공식 명칭을 가진다. 이 파트는 주로 안전 관련 시스템의 하드웨어 설계 및 구현에 필요한 요구 사항을 상세히 규정하며, 시스템 및 소프트웨어 관련 내용도 일부 포함한다.

IEC 61508-2에서는 안전 관련 시스템의 하드웨어 설계 시 적용할 수 있는 다양한 기법과 모범 사례(베스트 프랙티스)를 제시한다. 여기에는 시스템이 스스로 고장을 감지하고 진단하는 자기 진단 기법, 예측 가능한 다양한 고장의 발생 가능성을 줄이는 고장 억제 기법, 그리고 단일 원인으로 인해 시스템 전체 또는 여러 부분에 동시에 문제가 발생하는 공통 원인 고장에 대한 대책 등이 포함된다.

이 표준은 시스템이 달성해야 하는 안전 무결성 수준(SIL)에 따라 이러한 기술적 조치를 적절히 선택하고 적용할 것을 권장한다. 즉, 요구되는 안전 수준이 높을수록 더 엄격하고 다양한 안전 기법의 적용이 필요하다.

또한, IEC 61508-6은 IEC 61508-2와 IEC 61508-3(소프트웨어 요구 사항)의 내용을 실제 시스템 개발 및 운영에 적용하는 데 필요한 구체적인 지침과 예시를 제공하여 표준의 이해와 활용을 돕는다. 현재 통용되는 IEC 61508-2의 버전은 2010년 4월에 개정된 IEC 61508-2 ed2.0이다.

2. 3. Part 3: 소프트웨어 요구 사항

IEC 61508 규격의 세 번째 부분인 '''IEC 61508-3'''은 소프트웨어 요구 사항을 다룬다. 이는 전체 규격 체계에서 소프트웨어 개발 및 검증에 대한 구체적인 지침을 제공하는 핵심 부분이다.

소프트웨어의 고장(버그 또는 오류)은 하드웨어의 임의적인 고장과 달리, 설계나 코딩 단계에서 발생하는 결정론적 원인에 따른 고장으로 본다. 즉, 소프트웨어 자체의 결함은 제작 시점에 이미 포함되어 있을 수 있으며, 이 때문에 일반적인 임의 하드웨어 고장에 적용하는 확률론적 접근 방식을 소프트웨어 안전성 평가에 그대로 적용하기는 어렵다.

따라서 IEC 61508에서는 소프트웨어의 안전성을 확보하기 위해, 안전 라이프 사이클 전반에 걸쳐 안전 무결성 수준(SIL)에 따라 적절한 소프트웨어 개발 기법, 검증 및 확인 활동을 수행하도록 요구한다. 규격은 각 SIL 등급별로 권장되거나 강력히 권장되는 다양한 소프트웨어 엔지니어링 기법들을 제시하고 있으며, 이를 통해 소프트웨어 개발 과정에서 발생할 수 있는 오류를 체계적으로 방지하고 제거하는 것을 목표로 한다.

관련하여 IEC 61508 규격 시리즈 중 다음 문서들이 Part 3과 직접적인 연관이 있다.

  • '''IEC 61508-3 ed2.0 (2010-04)''': 전기/전자/프로그래밍 가능 전자 안전 관련 시스템의 기능 안전 - Part 3: 소프트웨어 요구 사항
  • '''IEC 61508-6 ed2.0 (2010-04)''': 전기/전자/프로그래밍 가능 전자 안전 관련 시스템의 기능 안전 - Part 6: IEC 61508-2 및 IEC 61508-3 적용에 대한 지침 (Part 3의 구체적인 적용 방법을 안내)

2. 4. Part 4: 용어 정의 및 약어

IEC 61508 규격의 Part 4는 표준에서 사용되는 용어와 약어를 정의하는 부분이다. 이는 표준의 다른 부분을 정확하게 이해하고 적용하기 위한 기초를 제공한다. 해당 파트의 공식 명칭 및 버전 정보는 'IEC 61508-4 ed2.0 (2010-04) 전기/전자/프로그래밍 가능 전자 안전 관련 시스템의 기능 안전 - Part 4: 정의 및 약어'이다.

2. 5. Part 5: 안전 무결성 수준(SIL) 결정 방법의 예시

IEC 61508 규격서의 Part 5는 참고 자료로서, 안전 무결성 수준(Safety Integrity Level, SIL)을 결정하는 방법의 구체적인 사례들을 제공한다. SIL은 시스템 또는 기능이 안전 관련 목표를 얼마나 잘 달성하는지를 나타내는 지표이다.

SIL은 시스템의 작동 요구 빈도에 따라 저빈도 요구 모드(Low demand mode)와 고빈도 요구 모드(High demand mode 또는 Continuous mode)로 나누어 정의된다.

  • 저빈도 요구 모드에서의 안전 무결성 수준(SIL): 작동 요구가 발생하는 빈도가 낮은 시스템에 적용된다. 각 SIL 등급은 작동 요구 시 기능 실패가 발생할 평균 확률(Probability of Failure on Demand, PFDavg)로 정의된다.

SIL작동 요구당 설계상의 기능 실패 평균 확률 (PFDavg) [단위 없음]
SIL 1≥ 10−2 ~ < 10−1
SIL 2≥ 10−3 ~ < 10−2
SIL 3≥ 10−4 ~ < 10−3
SIL 4≥ 10−5 ~ < 10−4


  • 고빈도 요구 모드에서의 안전 무결성 수준(SIL): 작동 요구가 빈번하거나 지속적으로 발생하는 시스템에 적용된다. 각 SIL 등급은 시간당 위험 측면 실패의 평균 빈도(Average frequency of dangerous Failure per Hour, PFH)로 정의된다.

SIL안전 기능의 위험 측면 실패의 평균 빈도 (PFH) [1/h]
SIL 1≥ 10−6 ~ < 10−5
SIL 2≥ 10−7 ~ < 10−6
SIL 3≥ 10−8 ~ < 10−7
SIL 4≥ 10−9 ~ < 10−8



IEC 61508-5 문서는 이러한 SIL 등급을 실제 시스템에 어떻게 할당하고 평가하는지에 대한 다양한 방법론과 예시를 포함하고 있다.

2. 6. Part 6: Part 2 및 Part 3의 적용 지침

IEC 61508 규격의 여섯 번째 부분인 '''IEC 61508-6'''은 IEC 61508-2 및 IEC 61508-3의 실제 적용을 돕기 위한 지침을 담고 있다. 이는 규정이 아닌 참고 자료에 해당한다. 정식 명칭은 "IEC 61508-6 ed2.0 (2010-04) 전기/전자/프로그래밍 가능 전자 안전 관련 시스템의 기능 안전 - Part 6: IEC 61508-2 및 IEC 61508-3 적용에 대한 지침"이다.

2. 7. Part 7: 기술 및 기법 개요

IEC 61508 표준의 일곱 번째 파트(Part 7)는 참고 자료(guideline)로 분류된다. 정식 명칭은 '''IEC 61508-7 ed2.0 (2010-04) 전기/전자/프로그래밍 가능 전자 안전 관련 시스템의 기능 안전 - Part 7: 기술 및 조치의 개요'''이다.

이 문서는 안전 관련 시스템의 설계 및 분석에 사용될 수 있는 다양한 기술과 기법(조치)에 대한 개요를 제공한다. 이를 통해 표준의 다른 파트들, 특히 Part 2와 Part 3의 요구 사항을 충족하는 데 도움을 준다.

3. 안전 무결성 수준 (SIL)

안전 무결성 수준(Safety Integrity Level, SIL)은 기능안전성 표준인 IEC 61508의 핵심 개념으로, 특정 안전 기능이 위험을 얼마나 효과적으로 줄일 수 있는지를 나타내는 정량적인 척도이다. 이는 시스템 또는 장비가 고장 났을 때 발생할 수 있는 위험의 심각성을 관리하기 위한 중요한 지표로 사용된다.[1] 각 안전 기능에 요구되는 목표 SIL은 위험 평가를 통해 결정되며, 설계된 시스템이 이 목표를 달성했는지는 체계적 능력(SC), 아키텍처 제약, 위험한 고장 확률 분석 등 여러 기준을 통해 종합적으로 평가된다. IEC 61508 표준은 이러한 SIL 목표 달성을 위해 안전 기능의 정의부터 구현, 검증에 이르는 전 과정에 걸쳐 체계적인 접근 방식과 문서화를 요구한다.

3. 1. SIL 등급

안전 무결성 수준(Safety Integrity Level, SIL)은 각 안전 기능이 달성해야 하는 목표 수준을 나타낸다. 위험 평가를 통해 각 안전 기능에 필요한 목표 SIL을 결정한다. 특정 설계가 목표 SIL을 달성했는지는 다음 세 가지 척도로 평가한다.

1. 체계적 능력 (Systematic Capability, SC): 설계 품질을 측정하는 척도이다. 설계에 사용된 각 장치는 SC 등급을 가지며, 전체 안전 기능의 SIL은 사용된 장치 중 가장 낮은 SC 등급으로 제한된다. SC 요구 사항은 IEC 61508 파트 2와 파트 3의 표에 명시되어 있다. 여기에는 적절한 품질 관리, 관리 프로세스, 검증 및 확인 기술, 고장 분석 등이 포함되어, 최종 시스템이 요구되는 SIL을 만족한다는 것을 합리적으로 증명할 수 있도록 한다.

2. 아키텍처 제약 (Architectural Constraints): 최소한의 안전 중복 수준을 의미하며, Route 1h와 Route 2h라는 두 가지 대안적인 방법을 통해 제시된다.

3. 위험한 고장 확률 분석 (Probability of Dangerous Failure Analysis)[1]: 이 분석에 사용되는 확률 지표는 기능적 구성 요소가 얼마나 자주 요구되는지에 따라 달라진다.

  • 높은 수요 모드 (High demand mode): 기능이 연간 1회 이상 요구되는 경우이다. 지속적으로 작동하는 기능(연속 모드) 또는 자주 작동하는 기능이 해당된다. 이 경우 SIL은 허용 가능한 시간당 위험한 고장 확률로 정의된다.
  • 낮은 수요 모드 (Low demand mode): 기능이 연간 1회 이하로 요구되는 경우이다. 간헐적으로 작동하는 기능이 해당된다. 이 경우 SIL은 요구 시 기능이 작동하지 않을 평균 고장 확률로 정의된다.
  • 기능과 시스템의 차이를 이해하는 것이 중요하다. 예를 들어, 에어백을 전개하는 전자 제어 장치(ECU)와 같은 시스템은 자주 작동할 수 있지만, 에어백 전개라는 기능 자체는 간헐적으로(낮은 수요 모드) 요구될 수 있다.


아래 표는 SIL 등급별 허용 가능한 고장 확률을 보여준다.

SIL낮은 수요 모드:
요구 시 평균 고장 확률 (PFDavg)		높은 수요 또는 연속 모드:
시간당 위험한 고장 확률 (PFH)
1≥ 10−2 ~ < 10−1≥ 10−6 ~ < 10−5
2≥ 10−3 ~ < 10−2≥ 10−7 ~ < 10−6
3≥ 10−4 ~ < 10−3≥ 10−8 ~ < 10−7 (대략 1140년에 1번의 위험한 고장)
4≥ 10−5 ~ < 10−4≥ 10−9 ~ < 10−8



IEC 61508 규격은 크게 세 가지를 요구한다. 첫째, 안전 기능의 정의부터 구현까지 전 과정의 추적성과 문서화. 둘째, 안전 무결성 수준(SIL)의 정량화 및 목표 달성 증명. 셋째, 책임 소재의 명확화 및 검증 가능성이다.

안전 목표치를 달성하기 위해서는 정성적 고장 대책(예: 설계 오류 방지)과 정량적 고장 대책(예: 확률적 고장률 관리)이 모두 필요하며, 이는 고장을 회피하는 방법과 고장을 제어(관리)하는 방법으로 구성된다. 체계적 고장(설계 오류 등 예측 가능한 원인)과 임의 고장(하드웨어의 무작위적 고장) 모두에 대한 대책으로 규격이 요구하는 내용은 다음과 같다.


  • 안전 라이프 사이클(프로세스) 준수
  • 체계적인 관리(매니지먼트)
  • 철저한 문서화
  • 감지되지 않는 위험한 고장률 및 SIL 산출과 목표 달성 증명
  • 정기적인 기능 시험
  • 적절한 기법 적용 (예: 구조화 설계, 모듈화, 고장 검출 기법, 고장 주입 시험, 고장 분석 기법, 코딩 표준 등)


또한, 이러한 대책들이 효과적으로 실행되도록 조직의 기능 안전 평가 능력 진단, 조직 구성원의 자질 및 행동 특성(competency)까지 고려하도록 요구한다.

IEC 61508은 안전 관련 시스템의 하드웨어 설계에 있어 자기 진단 기법, 다양한 고장 억제 기법, 공통 원인 고장 대책 등 다수의 구체적인 베스트 프랙티스(best practice)를 제시하며, 각 기법을 SIL 수준에 맞춰 채택할 것을 권장한다.

소프트웨어의 결함(bug)은 체계적 고장(결정론적 원인 고장)으로 간주된다. 소프트웨어 결함은 제작 단계에서 포함될 수 있으며, 일반적인 하드웨어의 임의 고장처럼 확률론적 접근 방식을 적용하기 어렵다. 따라서 IEC 61508은 소프트웨어에 대해 안전 라이프 사이클 전반에 걸쳐 SIL 수준에 따라 특정 소프트웨어 개발 기법의 채용을 권장하거나 강력히 권장한다.

3. 2. SIL 결정

안전 무결성 수준(SIL)은 각 안전 기능이 달성해야 하는 목표 수준을 의미한다. 목표 SIL은 위험 평가를 통해 각 안전 기능별로 결정된다. 설계된 시스템이 목표 SIL을 실제로 달성했는지는 다음 세 가지 척도를 통해 평가된다.

1. 체계적 능력 (Systematic Capability, SC): 설계 품질을 나타내는 척도이다. 시스템을 구성하는 각 장치는 고유한 SC 등급을 가지며, 전체 안전 기능의 SIL은 사용된 장치 중 가장 낮은 SC 등급으로 제한된다. SC 요구 사항은 IEC 61508 표준의 파트 2와 파트 3에 제시된 표들을 통해 구체화되며, 적절한 품질 관리, 관리 프로세스, 검증 및 확인 기술, 고장 분석 등을 포함한다. 이를 통해 최종 시스템이 요구되는 SIL을 만족함을 합리적으로 입증할 수 있어야 한다.

2. 아키텍처 제약 (Architectural Constraints): 시스템 구조가 안전 요구 사항을 만족하는 최소한의 중복성을 갖추었는지를 평가한다. 이는 Route 1h와 Route 2h라는 두 가지 대안적인 방법을 통해 평가된다.

3. 위험한 고장 확률 분석 (Probability of Dangerous Failure Analysis): 시스템이 위험한 상태로 고장날 확률을 정량적으로 분석하여 평가한다.[1]

IEC 61508 규격은 안전 관련 시스템 개발 시 다음과 같은 요구 사항들을 명시하고 있다.

  • 안전 기능의 정의부터 구현까지 전 과정의 추적성 확보
  • 안전도(안전 완전성)의 정량화 및 목표치 달성 증명
  • 책임 소재의 명확화 및 검증 가능성을 위한 문서화


안전도 목표치를 달성하기 위해서는 정성적인 고장 대책과 정량적인 고장 대책이 모두 필요하며, 이는 고장을 미리 피하는 '고장 회피'와 발생한 고장을 관리하고 제어하는 '고장 제어'로 구성된다. 규격은 체계적 고장(결정론적 원인에 의한 고장)과 임의 고장(무작위적 원인에 의한 고장)에 대응하기 위해 다음과 같은 대책들을 요구한다.

  • 안전 라이프 사이클(프로세스) 준수
  • 체계적인 관리(매니지먼트) 시스템 구축
  • 충분한 문서화
  • 감지 불가능한 위험 측 고장률 및 안전 무결성 수준(SIL)의 산출과 목표치 달성 검증
  • 정기적인 기능 시험 수행
  • 적절한 기법의 적용 (예: 구조화 설계, 모듈화, 고장 검출 기법, 고장 주입 시험, 고장 해석 기법, 코딩 기준 등)


이러한 대책들이 확실하게 이행되도록 하기 위해, 조직의 기능 안전 평가 능력 진단과 조직 구성원의 자질 및 행동 특성(competency)까지 고려하도록 요구한다.

특히 하드웨어 설계와 관련하여 IEC 61508은 자기 진단 기법, 다양한 종류의 고장을 억제하는 기법, 공통 원인 고장에 대한 대책 등 다수의 구체적인 베스트 프랙티스를 제시하며, 각 기법을 목표 SIL 수준에 맞게 채택할 것을 권장한다.

소프트웨어의 고장(결함)은 하드웨어와 달리 주로 결정론적인 원인에 의해 발생한다. 즉, 소프트웨어 결함은 개발 및 제작 단계에서 포함되는 경우가 많아, 일반적인 하드웨어의 임의 고장에 적용하는 확률론적 접근 방식을 그대로 적용하기 어렵다. 따라서 IEC 61508은 소프트웨어 개발 시 안전 라이프 사이클 전반에 걸쳐 목표 SIL 수준에 따라 특정 소프트웨어 개발 기법들을 채택할 것을 권장하거나 강력히 권장하고 있다.

4. 위험 및 리스크 분석

IEC 61508 표준은 맞춤형 시스템에 대해 위험 및 리스크 평가를 수행하도록 요구한다. 제어 대상 장비(EUC)의 리스크는 확인된 각각의 위험한 사건에 대해 평가 또는 추정되어야 한다.

이 표준은 정성적 또는 정량적 위험 및 리스크 분석 기법 사용을 권장하며, 여러 접근 방식에 대한 지침을 제공한다. 대표적으로 위험 발생 가능성과 결과의 심각성을 조합하여 리스크 등급을 매기는 정성적 분석 프레임워크가 있다. (자세한 내용은 하위 섹션 참조)

규격의 주요 요구 사항은 다음과 같다.

# 안전 기능의 정의, 구현 및 추적성 확보

# 안전 무결성(Safety Integrity)의 정량화 및 목표치 달성 증거 제시

# 책임의 명확화 및 검증 가능성을 위한 문서화

안전 무결성 목표치를 달성하기 위해서는 정성적 및 정량적 고장 대책이 필요하며, 이는 고장 회피와 고장 제어(관리 또는 제어)로 구성된다. 체계적 고장(결정론적 원인 고장) 및 임의 고장에 대한 대책으로 규격이 요구하는 내용은 대략 다음과 같다.


  • 안전 라이프 사이클(프로세스) 준수
  • 체계적인 관리
  • 충분한 문서화
  • 감지할 수 없는 위험 측 고장률 및 안전 무결성 수준(SIL)의 산출과 목표치 달성
  • 기능 시험 수행
  • 적절한 기법 적용 (구조화 설계, 모듈화, 고장 검출 기법, 고장 주입 시험, 고장 해석 기법, 코딩 기준 등)


또한, 이러한 대책의 확실성을 높이기 위해 조직의 기능 안전 평가 능력 진단, 조직 구성원의 자질 및 역량(competency)까지 고려하도록 요구한다.

IEC 61508은 안전 관련 시스템의 하드웨어 설계에 있어 자기 진단 기법, 각종 고장 억제 기법, 공통 원인 고장 대책 등 다수의 구체적인 모범 사례(베스트 프랙티스)를 제시하며, 각각의 기법을 SIL 수준에 따라 채택할 것을 권장한다.

소프트웨어의 고장(결함)은 결정론적 원인에 의한 것으로 간주된다. 소프트웨어 결함은 제작 단계에서 포함될 수 있으므로, 일반적인 임의 하드웨어 고장에 적용되는 확률론적 접근 방식을 사용할 수 없다. 따라서 IEC 61508은 소프트웨어에 대해 안전 라이프 사이클 내에서 SIL 수준에 따라 지정된 소프트웨어 기법을 채택할 것을 권장하거나 강력히 권장한다.

4. 1. 위험 평가

이 표준은 맞춤형 시스템에 대해 위험 및 리스크 평가를 수행해야 한다고 요구한다. "EUC(제어 대상 장비)의 리스크는 각 결정된 위험한 사건에 대해 평가 또는 추정되어야 합니다."

이 표준은 "정성적 또는 정량적 위험 및 리스크 분석 기법을 사용할 수 있다"고 조언하며 여러 접근 방식에 대한 지침을 제공한다. 이 중 하나는 위험의 정성적 분석을 위한 것으로, 발생 가능성 6가지 범주와 결과 4가지 범주를 기반으로 하는 프레임워크이다.
발생 가능성 범주

범주정의범위 (연간 실패 횟수)
빈번평생 동안 여러 번> 10−3
가능성 있음평생 동안 여러 번10−3 ~ 10−4
가끔평생 동안 한 번10−4 ~ 10−5
희소평생 동안 발생할 가능성 낮음10−5 ~ 10−6
드물게발생할 가능성이 매우 낮음10−6 ~ 10−7
믿을 수 없음발생할 수 있다고 믿을 수 없음< 10−7


결과 범주

범주정의
치명적다수의 사망
심각한 명의 사망
한계적한 명 이상에게 심각한 부상
무시할 수 있음기껏해야 경미한 부상



이들은 일반적으로 리스크 등급 매트릭스로 결합된다.

결과
발생 가능성치명적심각한계적무시할 수 있음
빈번IIIII
가능성 있음IIIIIII
가끔IIIIIIIII
희소IIIIIIIIIV
드물게IIIIIIIVIV
믿을 수 없음IVIVIVIV



여기서 각 등급의 의미는 다음과 같다:


  • 등급 I: 어떤 상황에서도 용납할 수 없음.
  • 등급 II: 바람직하지 않음. 리스크 감소가 불가능하거나 비용이 개선에 비해 지나치게 비합리적인 경우에만 허용 가능.
  • 등급 III: 리스크 감소 비용이 개선보다 큰 경우 허용 가능.
  • 등급 IV: 현재 상태로 허용 가능하지만 모니터링이 필요할 수 있음.

4. 2. 리스크 분석 기법

이 표준은 맞춤형 시스템에 대해 위험 및 리스크 평가를 수행해야 한다고 요구한다. "EUC(제어 대상 장비)의 리스크는 각 결정된 위험한 사건에 대해 평가 또는 추정되어야 한다."

이 표준은 "정성적 또는 정량적 위험 및 리스크 분석 기법을 사용할 수 있다"고 조언하며 여러 접근 방식에 대한 지침을 제공한다. 이 중 하나는 위험의 정성적 분석을 위한 것으로, 발생 가능성 6가지 범주와 결과 4가지 범주를 기반으로 하는 프레임워크이다.

''' 발생 가능성 범주 '''

범주정의범위 (연간 실패 횟수)
빈번평생 동안 여러 번> 10−3
가능성 있음평생 동안 여러 번10−3 ~ 10−4
가끔평생 동안 한 번10−4 ~ 10−5
희소평생 동안 발생할 가능성 낮음10−5 ~ 10−6
드물게발생할 가능성이 매우 낮음10−6 ~ 10−7
믿을 수 없음발생할 수 있다고 믿을 수 없음< 10−7



''' 결과 범주 '''

범주정의
치명적다수의 사망
심각한 명의 사망
한계적한 명 이상에게 심각한 부상
무시할 수 있음기껏해야 경미한 부상



이들은 일반적으로 리스크 등급 매트릭스로 결합된다.

결과
발생 가능성치명적심각한계적무시할 수 있음
빈번IIIII
가능성 있음IIIIIII
가끔IIIIIIIII
희소IIIIIIIIIV
드물게IIIIIIIVIV
믿을 수 없음IVIVIVIV



여기서 각 등급의 의미는 다음과 같다:


  • '''등급 I:''' 어떤 상황에서도 용납할 수 없음.
  • '''등급 II:''' 바람직하지 않음. 리스크 감소가 불가능하거나 비용이 개선에 비해 지나치게 비합리적인 경우에만 허용 가능.
  • '''등급 III:''' 리스크 감소 비용이 개선보다 큰 경우 허용 가능.
  • '''등급 IV:''' 현재 상태로 허용 가능하지만 모니터링이 필요할 수 있음.

5. 고장의 종류

IEC 61508 규격에서는 고장의 원인에 따라 크게 시스테마틱 고장(Systematic Fault)과 랜덤 고장(Random Fault) 두 가지로 분류한다. 시스테마틱 고장은 주로 설계나 개발 과정에서의 오류로 인해 발생하며, 랜덤 고장은 하드웨어 부품 등에서 예측 불가능하게 발생하는 고장을 의미한다.

또한, 원인별 분류 외에도 규격은 다음과 같은 고장 유형들을 정의한다.[17]


  • 공통 원인 고장 (Common Cause Failure): 단일 사건으로 인해 둘 이상의 요소가 동시에 고장 나는 경우.
  • 종속 고장 (Dependent Failure): 한 요소의 고장이 다른 요소의 고장을 유발하는 경우.
  • 안전 측 고장 (Safe Failure): 고장 발생 시 시스템을 안전한 상태로 전환시키는 경우.
  • 위험 측 고장 (Dangerous Failure): 고장 발생 시 시스템의 안전 기능을 저해하여 위험한 상태를 초래할 수 있는 경우.


특히 소프트웨어에서 발생하는 고장이나 불량은 모두 시스테마틱 고장으로 간주한다. 이는 소프트웨어의 결함이 개발 단계에서 만들어지는 것으로 보기 때문이다. 이러한 다양한 고장 유형을 관리하고 안전 목표를 달성하기 위해, IEC 61508은 안전 수명 주기 전반에 걸친 체계적인 접근 방식과 문서화, 검증 가능한 기법 적용 등을 요구한다.

5. 1. 시스테마틱 고장 (Systematic Fault)

시스테마틱 고장은 소프트웨어 및 하드웨어의 설계 개발 과정에서 발생하는 고장, 불량 또는 버그 등을 의미한다. 주로 사양의 모호함, 설계 과정에서 예상하지 못한 상황, 테스트 누락 등이 원인이 된다.[1] JIS 규격에서는 "올바른 지식, 인식, 대책의 부족 등 원인과 결정적으로 관련된 예측 불가능한 고장 또는 실패. 이 원인은 설계 부분의 수정, 제조 과정, 운전 절차, 문서화 또는 기타 관련 요인의 수정에 의해서만 제거될 수 있다 [IEV 191(IEC 60050-191)-04-19]"고 정의한다.[2]

이러한 고장은 설계 오류나 제조 과정의 실수 등 주로 사람의 실수(human error)에 의해 발생하며, 결정론적인 원인을 가진다. 따라서 시스테마틱 고장에 대한 대책은 고장을 미리 피하는 '고장 회피'와 발생한 고장을 관리하고 제어하는 '고장 관리'로 구성된다.[3] IEC 61508 표준은 전체 안전 수명 주기(life cycle)의 16단계에 걸쳐 안전 평가와 대책을 마련하고, 재발 방지를 위한 문서화를 요구함으로써 시스테마틱 고장을 예방하고자 한다.[3]

규격에서 요구하는 주요 사항은 안전 기능의 명확한 정의와 구현, 추적성 확보, 안전도(안전 완전성)의 정량화 및 목표 달성 증명, 책임 소재의 명확화 및 검증 가능성을 위한 문서화이다.[3] 안전도 목표 달성을 위해서는 정성적 및 정량적 고장 대책이 모두 필요하며, 이는 앞서 언급된 고장 회피 및 고장 제어(관리) 기법들을 통해 이루어진다.[3] 시스테마틱 고장 및 임의 고장에 대한 대책으로 규격이 요구하는 주요 내용은 다음과 같다.[3]

  • 안전 수명 주기(프로세스) 관리
  • 안전 관련 활동의 매니지먼트
  • 체계적인 문서화
  • 감지되지 않는 위험 측 고장률 및 안전도 수준(SIL)의 산출과 목표 달성
  • 주기적인 기능 시험 수행
  • 적절한 기법의 적용 (예: 구조화 설계, 모듈화, 고장 검출 기법, 고장 주입 시험, 고장 분석 기법, 코딩 표준 등)


또한, 이러한 대책의 효과를 보장하기 위해 조직의 기능 안전 평가 능력 진단 및 조직 구성원의 역량(competency)까지 고려하도록 요구한다.[3]

IEC 61508은 안전 관련 시스템의 하드웨어 설계 시 자기 진단 기법, 다양한 고장 억제 기법, 공통 원인 고장 대책 등 여러 베스트 프랙티스를 구체적으로 제시하며, SIL 등급에 따라 적절한 기법을 선택하여 적용할 것을 권장한다.[4]

소프트웨어의 고장 또는 불량은 본질적으로 시스테마틱 고장에 해당한다. 소프트웨어 버그는 제작 단계에서 이미 포함되어 있는 경우가 많아, 일반적인 하드웨어 임의 고장처럼 확률론적인 접근 방식을 적용하기 어렵다.[5] 따라서 IEC 61508은 소프트웨어에 대해 안전 수명 주기 동안 SIL 등급에 따라 특정 소프트웨어 개발 기법들을 채택할 것을 권장하거나 강력히 권장한다.[6]

5. 2. 랜덤 고장 (Random Fault)

하드웨어의 고장률 곡선에서 주로 일정한 고장률을 보이는 기간(상수 고장률 기간)에 발생하는 고장을 의미한다. 일본 산업 규격(JIS)에서는 랜덤 하드웨어 고장을 "시간에 관해 무질서하게 발생하며, 하드웨어의 다양한 노후화 메커니즘으로부터 발생하는 고장"으로 정의하고 있다. 이는 주로 하드웨어 부품이나 재료의 노후화, 제품 생산 과정에서의 편차 등으로 인해 발생한다.

IEC 61508 규격에서는 소프트웨어의 고장은 모두 체계적 고장(시스테마틱 고장)으로 간주하며, 랜덤 고장은 존재하지 않는다고 본다. 소프트웨어의 결함은 개발 또는 제작 단계에서 포함되는 것으로 보기 때문에, 하드웨어 랜덤 고장처럼 확률론적 접근 방식을 적용하기 어렵다.

랜덤 하드웨어 고장은 완전히 피할 수 없으므로, 고장을 관리하고 제어하는 방식으로 대응해야 한다. 이를 위해 시스템 신뢰성을 높이기 위한 중복 설계나 다양화, 자기 진단 기능 설치 등의 대책이 필요하다.

IEC 61508에서는 랜덤 하드웨어 고장을 다음과 같이 분류하여 관리한다.

  • 안전측 고장 (Safe Failure) / 위험측 고장 (Dangerous Failure)
  • 검출 가능한 고장 (Detected Failure) / 검출 불가능한 고장 (Undetected Failure)


이 중 가장 위험한 유형인 "위험측이면서 검출 불가능한 고장"(DU 고장) 발생 확률이 목표 안전도 수준에서 규정하는 PFD(Probability of Failure on Demand) 또는 PFH(Probability of Failure per Hour) 값 미만임을 증명하는 것이 중요하다.

IEC 61508은 안전 관련 시스템의 하드웨어 설계 시 자기 진단 기법, 다양한 고장 억제 기법, 공통 원인 고장 대책 등 구체적인 베스트 프랙티스(최상의 경험)를 다수 제시하며, SIL(Safety Integrity Level)에 따라 이러한 기법들을 채택할 것을 권장한다.

6. 기능 안전 관리

IEC 61508은 기능 안전을 체계적으로 관리하기 위한 요구 사항을 제시한다. 이 규격의 요구 사항은 크게 세 가지로 요약할 수 있다. 첫째, 안전 기능의 정의부터 구현까지 전 과정에 걸친 추적성과 검증 가능성을 확보하기 위한 문서화이다. 둘째, 안전도(안전 완전성)를 정량적으로 평가하고 설정된 목표치를 달성했음을 증명하는 것이다. 셋째, 관련된 책임을 명확히 하고 이를 검증할 수 있도록 하는 것이다.

안전도 목표치를 달성하기 위해서는 정성적인 고장 대책과 정량적인 고장 대책이 모두 필요하며, 이는 고장을 회피하는 방법과 고장을 제어(관리)하는 방법으로 구성된다. 체계적인 고장(결정론적 원인에 의한 고장)과 임의적인 고장 모두에 대응하기 위해 규격이 요구하는 주요 대책은 다음과 같다.


  • 안전 라이프 사이클(프로세스) 관리
  • 기능 안전 매니지먼트 시스템 구축 및 운영
  • 체계적인 문서화 관리
  • 감지되지 않는 위험 측 고장률 및 SIL의 산출과 목표 달성 검증
  • 주기적인 기능 시험 수행
  • 구조화 설계, 모듈화, 고장 검출 기법, 고장 주입 시험, 고장 분석 기법, 코딩 표준 등 적절한 기술 기법의 적용


이러한 대책들이 효과적으로 실행되도록 하기 위해, 조직 차원의 기능 안전 관리 역량을 진단하고, 조직 구성원 개개인의 자질과 행동 특성, 즉 역량(competency)을 확보하는 것 또한 중요하게 다루어진다.

IEC 61508은 안전 관련 시스템의 하드웨어 설계에 있어 자기 진단 기법, 다양한 고장 억제 기법, 공통 원인 고장에 대한 대책 등 여러 구체적인 베스트 프랙티스를 제시하며, SIL 수준에 따라 이러한 기법들을 채택할 것을 권장한다. 반면, 소프트웨어의 고장(결함)은 주로 설계나 코딩 단계에서 발생하는 결정론적 원인에 의한 것이므로, 일반적인 하드웨어 임의 고장에 적용하는 확률론적 접근 방식과는 다르다. 따라서 IEC 61508에서는 소프트웨어에 대해 안전 라이프 사이클 전반에 걸쳐 SIL에 따라 지정된 특정 소프트웨어 개발 기법 및 검증 활동의 적용을 권장하거나 강력히 권장한다.

기능 안전 관리는 품질 경영 시스템 표준인 ISO 9001과 유사한 측면을 가지지만, 안전 목표 달성에 초점을 맞춘다는 점에서 차이가 있다.

6. 1. 책임과 권한

IEC 61508 규격에서 기능 안전 관리에 관한 요구 사항을 정리하면 다음과 같은 책임과 권한 분담이 필요하다[18].

  • 책임(responsible)
  • 조직은 조직 전체의 책임자, 프로젝트 전체의 책임자와 각 단계의 책임자를 결정해야 한다. 이들은 겸임할 수도 있다. 책임자는 기능 안전 관리에 관한 전문 지식을 가진 인원에게 업무를 위임하는 것이 바람직하다.

  • 기능 안전 관리(functional safety management)
  • 책임자는 기능 안전 전문 지식을 가진 기능 안전 관리자를 임명한다. 규격상 책임자가 기능 안전 관리자를 겸임하는 것을 금지하지는 않지만, 기능 안전 관리자는 적어도 프로젝트 책임자와 동등한 지위를 가진 다른 사람으로 하는 것이 좋다. 기능 안전 관리자는 기능 안전 평가자(functional safety assessor)와 기능 안전 감사자(functional safety auditor)를 임명한다.

  • 기능 안전 평가(functional safety assessment)
  • 기능 안전 관리자는 기능 안전 전문 지식을 갖추고, 목표 SIL에 따라 독립성이 요구되는 기능 안전 평가자를 임명한다. 일반적으로 책임자, 기능 안전 관리자, 설계 개발부의 인원은 기능 안전 평가자를 담당하지 않는다. 적어도 품질 보증 부서의 관리직이나 기능 안전 전문 조직의 관리직, 또는 기능 안전 인증 기관이 담당하는 것이 일반적이다. 이들은 대상 제품의 기능 안전 목표 달성 여부를 평가(assessment)한다.

  • 기능 안전 감사(functional safety audit)
  • 기능 안전 관리자는 기능 안전 프로세스를 이해하고, 프로세스의 미비점을 지적할 수 있는 기능 안전 감사자를 임명한다. 조직 내부의 프로젝트 관계자가 아닌 인원이 담당하거나, 인증 기관의 기능 안전 평가자가 담당할 수도 있다.

  • 담당(타당성 확인 담당 포함) 및 검증(타당성 확인 검증 포함)
  • 프로젝트 책임자는 기능 안전 라이프 사이클의 각 단계별 책임자, 담당자 및 검증자를 임명한다. 담당자와 검증자는 서로 다른 사람이어야 하며, 기능 안전에 대한 지식을 갖추는 것이 바람직하다.

6. 2. 역량 (Competency)

IEC 61508 규격은 기능 안전 관련 대책의 확실성을 확보하기 위해, 조직을 구성하는 개인의 자질 또는 행동 특성(역량)을 중요한 요소로 고려한다.[19] 기능 안전 관리에 관련된 업무를 수행하는 인원은 담당하는 역할에 요구되는 기능 안전 관련 전문 지식과 기술, 즉 역량을 갖추고 있음을 입증해야 한다.[19]

이러한 역량 증명은 일반적으로 공인된 인증 기관이나 관련 단체에서 제공하는 교육 과정을 이수하고 평가를 통과함으로써 이루어진다.[19] 예를 들어, 일본에서는 일반 재단법인 일본규격협회[19]나 독일의 인증 기관인 TÜV Rheinland|튀프 라인란트de, TÜV SÜD|튀프 쥐트de 등에서 관련 교육 프로그램을 운영하고 있다.[19]

7. 인증 (Certification)

IEC 61508 인증은 제품, 프로세스 또는 시스템이 인증 프로그램의 모든 요구 사항을 충족한다는 제3자 증명이다. 해당 요구 사항은 '인증 스키마'라는 문서에 나열되어 있다.

7. 1. 인증 기관 (Certification Body)

인증은 제품, 프로세스 또는 시스템이 특정 요구 사항을 모두 충족한다는 것을 제3자가 증명하는 절차이다. 이러한 요구 사항은 '인증 스키마'라는 문서에 명시된다. IEC 61508 인증 프로그램은 인증 기관(Certification Body, CB)이라고 하는 공정한 제3자 기관에서 운영한다.

이러한 인증 기관은 ISO/IEC 17065(제품, 프로세스 및 서비스 인증기관 요구사항) 및 ISO/IEC 17025(시험 및 교정기관 역량 요구사항)를 포함한 국제 표준에 따라 운영되도록 공인받는다. 인증 기관은 인정 기관(Accreditation Body, AB)으로부터 감사, 평가 및 시험 작업을 수행할 능력이 있음을 인정받는다. 각 국가에는 일반적으로 하나의 국가 인정 기관이 존재한다.

인정 기관은 ISO/IEC 17011(적합성 평가기관 인정기관 요구사항) 표준의 요구 사항에 따라 운영된다. 이 표준은 인정 기관의 역량, 일관성 및 공정성에 대한 요구 사항을 포함한다. 인정 기관은 관리 시스템, 제품, 서비스 및 인력 인증과 관련하여 IAF(국제인정포럼)의 회원이고, 실험실 인정의 경우 ILAC(국제시험기관인정협력체)의 회원이다. 인정 기관 간의 다자간 상호 인정 협정(Multilateral Recognition Arrangement, MLA)은 인증된 인증 기관의 인증 결과가 국제적으로 통용되도록 보장한다.

IEC 61508 인증 프로그램은 여러 국제적인 인증 기관에서 설립하여 운영하고 있다. 각 기관은 IEC 61508 및 기타 기능 안전 표준을 기반으로 자체적인 인증 스키마를 정의한다. 이 스키마는 참조된 표준을 나열하고, 시험 방법, 사후 관리 감사 정책, 공개 문서 정책 및 프로그램의 기타 특정 측면을 설명하는 절차를 지정한다.

IEC 61508 인증은 exida, 인터텍, SGS-TÜV Saar, TÜV Nord, TÜV Rheinland, TÜV SÜD, UL 등 여러 공인된 인증 기관에서 전 세계적으로 제공하고 있다.

인증 기관에 의한 기능 안전 규격 적합 인증에는 제품 인증과 프로세스 인증 등이 있다. 특히, 대상 제품의 목표 SIL(Safety Integrity Level)이 SIL 3 이상인 경우에는 인증 기관에 의한 심사를 받아야 한다.

7. 2. 인증 절차

인증은 제품, 프로세스 또는 시스템이 특정 인증 프로그램의 모든 요구 사항을 충족함을 제3자가 증명하는 과정이다. 이러한 요구 사항은 '인증 스키마'라는 문서에 명시된다. IEC 61508 인증 프로그램은 '인증 기관'(CB, Certification Body)이라 불리는 공정한 제3자 기관에 의해 운영된다. 이들 인증 기관은 ISO/IEC 17065 및 ISO/IEC 17025와 같은 다른 국제 표준에 따라 운영되도록 인증받는다.

인증 기관은 다시 '인정 기관'(AB, Accreditation Body)에 의해 감사, 평가 및 테스트 작업을 수행하도록 인증받는다. 각 국가에는 보통 하나의 국가 인정 기관이 존재하며, 이들은 적합성 평가 기관을 인증할 때 인정 기관의 역량, 일관성, 공정성에 대한 요구 사항을 담은 표준인 ISO/IEC 17011의 요구 사항에 따라 운영된다. 인정 기관들은 관리 시스템, 제품, 서비스, 인력 인증과 관련하여 국제인정포럼(IAF)의 회원이며, 실험실 인증의 경우 국제시험기관인정협력체(ILAC)의 회원이다. 인정 기관 간의 다자간 상호 인정 협정(MLA)은 인증된 인증 기관의 국제적인 인정을 보장한다.

IEC 61508 인증 프로그램은 여러 글로벌 인증 기관에서 설립되었으며, 각 기관은 IEC 61508 및 기타 기능 안전 표준을 기반으로 자체 스키마를 정의한다. 이 스키마는 참조된 표준을 나열하고 테스트 방법, 사후 관리 감사 정책, 공개 문서 정책 등 프로그램의 특정 측면을 설명하는 절차를 지정한다. IEC 61508 인증 프로그램은 exida, 인터텍(Intertek), SGS-TÜV Saar, TÜV Nord, TÜV Rheinland, TÜV SÜD, UL을 포함한 여러 인정된 인증 기관에서 전 세계적으로 제공하고 있다.

인증 기관에 의한 기능 안전 규격 적합 인증에는 제품 인증과 프로세스 인증 등이 있다. 대상 제품의 목표 SIL(Safety Integrity Level)이 SIL3 이상인 경우, 인증 기관에 의한 심사를 받아야 한다.

제품 인증 절차는 인증 기관에 따라 다소 차이가 있을 수 있으나, 일반적인 예는 다음과 같다.[20][21][22]

1. 컨셉 심사 단계: 초기 개념 및 계획 검토.

2. 메인 인스펙션 단계: 상세 설계 및 구현 검토.

3. 인증 단계: 최종 평가 및 인증서 발급.

컨셉 심사 단계에서는 다음 네 가지 문서를 제출하여 심사를 받는다.

  • 안전 계획서(Safety Plan): 프로젝트의 기능 안전 관리 방안을 구체적으로 기술한 문서이다. 조직 구성, 담당 책임자의 적정 능력, 안전 설계에 도입할 방책과 기법 등을 포함한다.
  • V&V 계획서(Verification and Validation Plan): 설계 프로세스의 각 단계에서 사용할 도구, 수행할 검증 및 유효성 확인 방법, 그리고 그 결과를 문서화하는 방식을 기술한 문서이다.
  • 안전 요구 사항 명세서(SRS: Safety Requirement Specification): 상정하는 안전 상태, 시스템, 작동 환경 등 필요한 안전 요구 사항을 구체적으로 기술한 문서이다.
  • 안전 개념 설명서(SC: Safety Concept): 안전 요구 사항 명세서(SRS)를 바탕으로 안전 기능을 어떻게 실현할 것인지, 특히 타이밍 문제나 비안전 관련 부분에서 안전 관련 부분으로의 영향 회피 방책 등을 구체적으로 기술한 문서이다.

8. 산업별/응용 분야별 변형

IEC 61508은 특정 산업 분야에 국한되지 않고 범용적으로 적용될 수 있는 기본적인 기능 안전 표준이다.[2][3][6] 하지만 각 산업 분야의 특수한 환경과 요구사항을 만족시키기 위해, IEC 61508을 기반으로 해당 분야에 맞게 내용을 구체화하거나 수정한 여러 파생 표준들이 개발되어 사용되고 있다. 이러한 산업별 표준들은 IEC 61508의 기본 원칙을 따르면서도 각 분야의 안전 요구사항을 보다 효과적으로 충족시키도록 돕는다. 대표적인 예로는 자동차 산업의 ISO 26262[2], 철도 산업의 IEC 62279[6], 공정 산업의 IEC 61511, 원자력 발전소 계측 및 제어 시스템을 위한 IEC 61513[7], 기계류의 안전 관련 전기 제어 시스템을 위한 IEC 62061 등이 있다.

8. 1. 자동차

ISO 26262는 자동차 전기/전자 시스템을 위한 IEC 61508의 적용판이다. 주요 자동차 제조업체들이 널리 채택하고 있다.[2]

ISO 26262가 출시되기 전에는 안전 관련 자동차 시스템 소프트웨어 개발이 주로 자동차 산업 소프트웨어 신뢰성 협회(Motor Industry Software Reliability Association, 이하 MISRA)의 가이드라인에 의해 다루어졌다.[3] MISRA 프로젝트는 도로 차량 전자 시스템에서 임베디드 소프트웨어를 개발하기 위한 가이드라인을 개발하기 위해 구상되었다.[3] 1994년 11월, 차량 기반 소프트웨어 개발을 위한 가이드라인이 발표되었다.[4] 이 문서는 당시 새롭게 부상하던 IEC 61508 표준의 원칙에 대한 최초의 자동차 산업 해석을 제공했다.[3]

오늘날 자동차 산업 소프트웨어 신뢰성 협회(MISRA)는 C 및 C++ 언어를 사용하는 방법에 대한 가이드라인으로 가장 널리 알려져 있다.[5] MISRA C는 대부분의 안전 관련 산업에서 임베디드 C 프로그래밍의 사실상 표준이 되었으며, 안전이 주요 고려 사항이 아닌 경우에도 소프트웨어 품질을 개선하는 데 사용된다.

8. 2. 철도

IEC 62279는 철도 분야에 적용하기 위해 IEC 61508을 구체적으로 해석한 표준이다. 이는 통신, 신호 및 처리 시스템을 포함한 철도 제어 및 보호 소프트웨어 개발을 다루기 위한 것이다. EN 50128 및 EN 50657은 IEC 62279와 동등한 CENELEC 표준이다.[6]

8. 3. 공정 산업

공정 산업 부문에는 정유 공장, 석유화학, 화학, 제약, 펄프 및 제지, 전력 등 다양한 유형의 제조 공정이 포함된다. IEC 61511은 계측기를 사용하여 산업 공정의 안전을 보장하는 시스템 엔지니어링의 관행을 규정하는 기술 표준이다.

8. 4. 발전소

IEC 61513은 원자력 발전소의 안전에 중요한 계측 제어 시스템에 대한 요구 사항 및 권장 사항을 제공한다. 이 규격은 기존의 하드와이어드 장비, 컴퓨터 기반 장비 또는 두 가지 유형의 장비를 모두 포함하는 시스템에 대한 일반적인 요구 사항을 나타낸다. 원자력 발전소에 특정한 안전 규범에 대한 개요 목록은 ISO에서 발행한다.[7]

8. 5. 기계

IEC 62061은 IEC 61508의 기계류 특화 구현이다. 이는 모든 유형의 기계 안전 관련 전기 제어 시스템의 시스템 레벨 설계 및 복잡하지 않은 서브 시스템 또는 장치의 설계에 적용 가능한 요구 사항을 제공한다.

9. 소프트웨어 테스팅

IEC 61508 표준에 따라 작성된 소프트웨어는 달성해야 하는 SIL(Safety Integrity Level)에 따라 단위 테스트가 필요할 수 있다. 단위 테스트의 주요 요구 사항은 소프트웨어가 함수 수준에서 완전히 테스트되고, 소프트웨어의 모든 가능한 분기와 경로가 실행되도록 하는 것이다. 일부 더 높은 SIL 수준의 응용 프로그램에서는 소프트웨어 코드 커버리지 요구 사항이 훨씬 더 엄격해지며, 단순한 분기 커버리지 대신 MC/DC(Modified Condition/Decision Coverage) 코드 커버리지 기준이 사용된다. MC/DC 커버리지 정보를 얻으려면 단위 테스트 도구가 필요하며, 이는 소프트웨어 모듈 테스트 도구라고도 한다.

참조

[1] 서적 Control Systems Safety Evaluation and Reliability ISA
[2] 간행물 Application of ISO 26262 in Distributed Development ISO 26262 in Reality https://doi.org/10.4[...] SAE International 2009-04-20
[3] 웹사이트 MISRA Web site > MISRA Home > A brief history of MISRA https://www.misra.or[...] 2021-02-23
[4] 서적 Development Guidelines for Vehicle Based Software MISRA
[5] 웹사이트 MISRA Web site > News https://www.misra.or[...] 2021-02-23
[6] 간행물 Application of Case-Based Reasoning to the safety assessment of critical software used in rail transport https://www.scienced[...] 2020-11-01
[7] 웹사이트 ISO - 27.120.20 - Nuclear power plants. Safety https://www.iso.org/[...] 2021-02-23
[8] 웹사이트 Relationship between ISO 26262 and IEC 61508 https://ez.analog.co[...] 2021-04-11
[9] 웹사이트 Automotive vs Industrial Functional Safety https://ez.analog.co[...] 2021-04-11
[10] 웹사이트 IEC 60730-1:2013+AMD1:2015+AMD2:2020 CSV {{!}} IEC Webstore https://webstore.iec[...] 2021-04-11
[11] 문서 JIS C 0508:2012(IEC 61508)
[12] 문서 機能安全を ご存じですか !? https://www.mhlw.go.[...]
[13] 문서 機能安全のバカ https://embeddedsoft[...]
[14] 문서 ETSSを利用した機能安全対応スキル判定と教育訓練 https://jglobal.jst.[...]
[15] 문서 組込みシステムの安全性向上の勧め（機能安全編） https://www.ipa.go.j[...]
[16] 문서 표지 およびIEC61508-1の1.4절やIEC61508-2,3,4に記載
[17] 문서 JIS C 0508-4:2012(IEC 61508-4)
[18] 문서 JIS C 0508-1:2012(IEC 61508-1)
[19] 웹사이트 一般財団法人 日本規格協会 機能安全教育 http://www.jsa.or.jp[...]
[20] 웹사이트 IEC 61508 認証について 機能安全と認証プロセス 第 1 回 http://www.tuv.com/m[...]
[21] 웹사이트 IEC 61508 認証について 機能安全と認証プロセス 第 2 回 http://www.tuv.com/m[...]
[22] 웹사이트 IEC 61508 認証について 機能安全と認証プロセス 第 3 回 http://www.tuv.com/m[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com