SW 는 시스템의 일부분으로 위험 분석은 전체 시스템의 설계 맥락에서 수행되어야 한다. SW 그 자체만으로는 안전성 문제를 발생시키지 않고, SW 가 시스템의 일부분으로 구성될 때 비로소 문제가 발생한다. 따라서 SW 안전성은 HW 와 결합되는 지점부터 위험분석이 시작되어야한다. 또한 관련된 HW, 주변 환경, 그리고 사람 등을 고려해야 한다. 때문에 SW 위험 분석을 수행하는 분석가는 시스템 안전 기능의 수행과 시스템 제어 및 감시 기능의 수행에 있어서 SW 역할을 이해해야 하고, 해당 시스템 안전성 달성에 있어서 SW 가 시스템에 미치는 영향을 잘 파악해야 한다.
시스템 설계에 있어 안전 특성들은 기본적으로 품질, 다양성, 그리고 심층방어의 세 가지 설계 원칙으로 결정된다. 이 원칙들이 여러 계층의 설계에 적용될 수 있으며, 어디에 어떻게 적용할 것인지를 결정하는 것이 설계 공정의 중요한 활동이고, 세 가지 원칙은 다양한 형태의 공정제어 장치에 적절하게 적용 가능하다.
물리적인 관점에서 심층방어 개념을 예를 들어 살펴보면, 핵분열 생성물의 누출을 통제 하기 위해 세 계층의 심층방어 설계가 마련되어 있다. 각 계층은 어느 정도 심각한 수준의 방사선으로부터 일반 대중의 피폭을 방지할 수 있어야 한다. 첫 번째 계층은 핵연료봉이 그 피복재로 싸여져 있다. 두 번 째 계층은 핵연료봉에서 세어나온 핵분열 생성물이 E/E/PES 시스템냉각재장치(RCS)에 의해 격리된다. 세 번째 계층은 E/E/PES 시스템 건물이 E/E/PES 시스템 냉각재 장치를 에워싸고 있다. 이들 각 계층은 기본적으로 서로 다른 설계이며, 각 계층마다 다양성을 부여하고 있다.
계측제어 관점에서 살펴본 심층방어 개념으로는 각 기능이 여러 개의 독립적인 시스템들에 의하여 작동될 수 있다. 예를 들면, 제어봉은 제어 장치, E/E/PES 시스템보호장치, ATWS 완화 장치, 공학적안전설비 작동 장치(ESFAS)에 의해 자동 또는 수동으로 작동될 수 있다. 또한 컴퓨터 기반 제어 및 보호장치들을 포함한 신형 E/E/PES 시스템 설계에서는 적어도 두 개의 자동시스템이 각 안전 기능을 개시할 수 있어야 한다. 그리고 운전원이 각 안전 기능을 시작, 가동, 종료할 수 있도록 충분한 정보와 수동 제어기능을 마련하여야 한다.
2017년 4월 17일 월요일
위험 분석 절차와 수행할 안전 요구사항
- 개념
- EUC(Equipment Under Control) 이해
- 필요한 제어 기능 및 물리적 환경 정의
- 유해 사건 원인 결정, 위험원 정보, 현재 안전규정(법/제도) 등 파악
- 범위 정의
- EUC 와 제어시스템의 경계 결정
- 위험원과 리스크 분석 적용 범위(프로세스, 환경) 결정
- 고려할 외부 사건, 연관된 장비/시스템, 고려할 사건 유발 유형 결정
- 위험원 및 위험 분석
- 위험원 식별
- 위험원, 위해 사건 식별 (위험원 제거/감소 도 고려)
- 위험한 상황(결함, 예상 가능한 오용, 악의, 비 허가) 결정
- 위험성 계산
- 결정된 위해 사건으로 이어지는 사건 순서를 결정
- 명시된 상황에서 위해 사건 발생 가능성 평가
- 결정된 위해 사건과 연관된 잠재 결과 확인(심각도) - 정량적 또는 정성적인 위험원 및 리스크 분석 기법 적용
- 위험한 사건과 관련된 위험 결정(평가/추정)
- 안전 요구사항 명세
- 기능 안전성 달성(위험 제거/감소) 전체 요구사항 명세 개발
- 안전 기능(Safety Function) 요구사항 명세
- 안전 무결성(SIL, safety Integrity Level) 요구사항 명세
- 목표 안전 무결성 요구사항: 허용 리스크에 부합
- 필요한 리스크 감소 : 허용 가능한 리스크 달성
- 허용 가능한 사건 : 허용 가능한 리스크 충족
- 안전 요구사항 할당
- 안전 기능 --> 안전관련 시스템, 위험 감소 수단에 할당
- 안전 기능이 허용 가능한 리스크 달성하도록 할당 지속
- 달성이 어려우면 명세를 변경하면서 지속적으로 할당 반복
- 전체 안전 기능이 할당되고, 목표 고장 기준이 안전 기능에 할당
- 안전 무결성 수준(SIL) --> 각 안전 기능에 할당
- 확률을 조합하여 적절한 기법 이용, 공통 원인 고장 가능성 고려
- 목표 고장 기준 : 저요구/고요구/연속적 작동 모드
위험 분석 절차
위험성은 위험원의 발생빈도와 심각도의 조합으로서 발생빈도가 빈번하거나 발생빈도가 빈번하지 않더라도 사고가 발생하면 치명적인 결과를 초래하는 위험원은 위험성이 크다고 정의한다. 사고관련 위험원의 위험성을 허용할 수 있는 수준으로 제어하고자 하는 안전성 관리는 시스템 수명주기의 요구사항 분석 단계부터 안전계획을 수립하여 도출된 안전 요구사항을 바탕으로 안전한 시스템이 되도록 설계, 구현 및 시험을 수행하여 위험원을 지속적으로 관리하고 확인 및 검증을 통해 시스템의 안전성을 확보한다.
안전성 확보를 위한 위험분석 절차는 대상 제어시스템에서 위험원을 중심으로 결과, 손실, 위험성을 파악하는 위험분석 단계와 해당 위험에 대한 원인 분석을 통해 위험 제거 및 감소를 위한 안전 기능을 도출하여 SIL 을 할당하고 이를 시스템 하위 서브시스템, HW, SW 에 할당하는 단계로 정의할 수 있다.
IEC61508 에서 제시하는 전체 안전 수명주기에서 위험분석 단계로 그림과 같은 개념정의(Concept), 범위 정의(Overall Scope Definition), 위험원 및 위험 분석(Hazard & Risk Analysis), 안전 요구사항 명세(Overall Safety Requirements), 안전 요구사항 할당(Overall Safety Requirements Allocation) 으로 구성 된다.
위험성은 위험원의 발생빈도와 심각도의 조합으로서 발생빈도가 빈번하거나 발생빈도가 빈번하지 않더라도 발생 시 치명적인 결과를 초래하는 위험원은 위험성이 크다. 사고관련 위험원의 위험성을 허용할 수 있는 수준으로 제어하고자 하는 안전성 관리는 시스템 수명주기의 위험분석 단계부터 안전계획을 수립하여 도출된 안전 요구사항을 바탕으로 안전한 시스템이 되도록 설계, 구현 및 시험을 수행하여 위험원을 지속적으로 관리하고 확인 및 검증을 통해 시스템의 안전성을 확보한다.
안전성 확보를 위한 위험분석 절차는 대상 제어시스템에서 위험원을 중심으로 결과, 손실, 위험성을 파악하는 위험분석 단계와 해당 위험에 대한 원인 분석을 통해 위험 제거 및 감소를 위한 안전 기능을 도출하여 SIL 을 할당하고 이를 시스템 하위 서브시스템, HW, SW 에 할당하는 단계로 정의할 수 있다.
IEC61508 에서 제시하는 전체 안전 수명주기에서 위험분석 단계로 그림과 같은 개념정의(Concept), 범위 정의(Overall Scope Definition), 위험원 및 위험 분석(Hazard & Risk Analysis), 안전 요구사항 명세(Overall Safety Requirements), 안전 요구사항 할당(Overall Safety Requirements Allocation) 으로 구성 된다.
그림. IEC61508 기준 위험분석 절차
2017년 4월 14일 금요일
수명주기별 안전성 관리
가. 수명주기 개요
안전관련 시스템에 의해 수행되는 안전기능에 대해 필요한 안전무결성 수준을 달성하기 위한 모든 활동을 체계적인 방법으로 다루기 위하여, IEC 61508 에서는 기술 프레임워크로서 전체 안전수명주기를 제시하고자 한다. 전체 안전수명주기는 이 표준 준수를 위한 객관적 참조물로 제시되고, 각 단계의 목적과 요구사항에 충족된다면, 다른 SW 개발 안전수명주기를 이용할 수 있다.
소프트웨어 개발을 위한 안전수명주기는 IEC 61508 에 따라 전체 시스템 개발계획에 안전계획이 결정되고 명시되어야 한다. 표준에서 요구하는 사항을 만족시키는 안전수명주기 모델은 본 가이드에서 참조 가능하도록 상세하게 제시하였으며, 프로젝트나 조직의 특정한 구체적 요구에 맞추어 적절하게 조정하여 사용할 수 있다. 다음은 IEC 61508 에서 제시하는 수명주기 관련 요구사항은 다음과 같다.
안전관련 시스템에 의해 수행되는 안전기능에 대해 필요한 안전무결성 수준을 달성하기 위한 모든 활동을 체계적인 방법으로 다루기 위하여, IEC 61508 에서는 기술 프레임워크로서 전체 안전수명주기를 제시하고자 한다. 전체 안전수명주기는 이 표준 준수를 위한 객관적 참조물로 제시되고, 각 단계의 목적과 요구사항에 충족된다면, 다른 SW 개발 안전수명주기를 이용할 수 있다.
소프트웨어 개발을 위한 안전수명주기는 IEC 61508 에 따라 전체 시스템 개발계획에 안전계획이 결정되고 명시되어야 한다. 표준에서 요구하는 사항을 만족시키는 안전수명주기 모델은 본 가이드에서 참조 가능하도록 상세하게 제시하였으며, 프로젝트나 조직의 특정한 구체적 요구에 맞추어 적절하게 조정하여 사용할 수 있다. 다음은 IEC 61508 에서 제시하는 수명주기 관련 요구사항은 다음과 같다.
- 품질과 안전 보증 절차는 안전수명주기의 각 활동들과 통합되어야 한다.
- 소프트웨어 안전수명주기의 각 단계는 적용범위를 갖는 기초 활동과 각 단계를 위해 명시된 입력과 그 결과물인 산출물로 구분되어야 한다.
- SW 수명주기 단계에 관한 자세한 정보는 ISO/IEC 12207 을 참조한다.
- IEC 61508－1 의 안전수명주기 단계별 산출물들이 포함되어야 한다.
- 산출물은 E/E/PE 안전관련 시스템의 개발마다 때로는 몇 개가 병합되기도 하고 세분화되어 나누어진 별개의 문서로 제공될 수도 있다.
- 핵심적인 요구사항은 모든 안전수명주기 단계들의 산출물은 그 의도된 목적에 적합해야 한다는 것이다. 간단한 개발에서는 일부 안전수명주기 단계들이 병합될 수 있다.
- 소프트웨어 안전수명주기가 IEC61508 에서 요구하는 사항을 만족시킨다면, V 모델 단계들의 정도, 수, 작업규모를 안전무결성 및 프로젝트의 복잡성을 고려하여 일부 절차 및 활동은 조정할 수 있다.
- 표준에서 제시하는 수명주기 단계들의 전체 리스트는 대체로 규모가 크고 새로 개발된 시스템에 적합하다. 예를 들면 소규모 시스템에서는 소프트웨어 시스템 설계 및 아키텍처 설계 단계를 병합하는 것이 적합할 수도 있다.
- 표준의 모든 목적과 요구사항을 만족한다면, 다르게 소프트웨어 프로젝트를 관리할 수 있다(즉, 다른 소프트웨어 안전수명주기 모델 이용 가능).
- 각 안전수명주기 단계에서 SW 안전성 보증을 위해 적절한 기법과 수단이 이용되어야 한다.
- 소프트웨어 안전수명주기에서의 활동 결과들은 문서화되어야 한다.
나. 수명주기 개발 참조 관련 규격 및 문헌
- IEC 61508-1:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems – Part 1: General requirements
- IEC 61508-2:2010, Functional safety of electrical/electronic/programmable electronic safetyrelated systems – Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems
- IEC 61508-3:2010, Functional safety of electrical/electronic/programmable electronic safetyrelated systems – Part 3: Software requirements
- IEC 61508-4:2010 Functional safety of electrical/electronic/programmable electronic safetyrelated systems – Part 4: Definitions and abbreviations
- IEC 61508-5:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems – Part 5: Examples of methods for the determination of safety integrity levels
- IEC 61508-6:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems – Part 6: Guidelines on the application of IEC 61508-2 and IEC 61508-3
- IEC 61508-7:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems – Part 7: Overview of techniques and measures
- KS C IEC61508－1:2010 전기/전자/프로그램 가능 전자식 안전관련 시스템의 기능 안전성 - 제 1 부: 일반 요구사항
- KS C IEC61508－3:2010 전기/전자/프로그램 가능한 전자장치 안전관련 시스템의 기능안전성－제 3 부：소프트웨어 요구사항
- 철도 소프트웨어 안전 기준 및 체계 구축 연구보고서, 2008
- NUREG CR-6430 UCRL-ID-122514 SW Safety Hazard Analysis, NRC, USA
- NUREG IA-0145 RELAP5 Assessment Against - Revision 1, NRC, USA
- IEEE730 A guide to writing successful SQA plans
- IEEE829:2008 SW test documentation
- IEEE1016:2009 Software design description
- IEEE1012:2004 Standard for Software Verification and Validation
- IEEE1228:1994 IEEE Standard for Software Safety Plans
- IEEE1540:2001 Software Engineering Risk Management: Measurement-Based Life Cycle Risk Management
- ISO12207:2004 Systems and software engineering - Software life cycle processes
- SIL4 인증문서 한글 표준양식(템플릿) 적용사례 연구, 한국철도학회
- 소프트웨어 개발 프로세스에서의 안전성 분석 및 관리 활동의 적용방안, 중소기업융합학회
- 기능안전 적용을 위한 소프트웨어 개발 가이드라인, KTL
다. 안전 수명주기 구성
기능 안전 표준인 IEC61508 과 SW 수명주기 표준인 ISO12207 을 참고하여 안전 수명 주기를 구성하였다. SW 안전 수명주기는 크게 세 부문으로 구성되고 각 부문에는 아래와 같이 세분화된 단계로 구성될 수 있다.
- Analysis 부문
- 위험분석 단계
- Realization 부문
- SW 계획 단계
- SW 요구분석
- SW 설계 단계
- SW 구현 단계
- SW 통합 단계
- SW 확인 검증 단계
- Operation 부문
- SW 운영 단계
그림. 전체 안전 수명주기(IEC61508)
안전 기능과 안전 무결성
안전기능 요구사항은 위험원 분석을 통해 도출되고, 안전무결성 요구사항은 위험성 평가를 통해 도출된다. 안전 무결성(Safety Integrity)은 주어진 모든 조건하에 있는 안전관련 시스템이 주어진 시간 내에 요구되는 안전기능을 만족스럽게 수행할 수 있는 확률로 정의되고 안전무결성수준이 높을수록 해당 장비 또는 시스템의 고장 발생 가능성은 낮아진다. 그림은 안전 기능과 안전무결성의 관계를 보여준다.
예를 들어, 전자 연동 장치의 종합 안전성은 사고를 열차 충돌과 탈선으로 정의하는 경우에 전자연동장치의 출력에 의해 제어되는 선로 전환기나 신호기와 같은 장치와의 인터페이스 구조 및 전자연동장치 운영시나리오에 따라 결정된다. 따라서 연동장치가 설치될 역의 규모, 인터페이스 장치의 안전수준, 운용인력의 안전문화 등이 고려되지 않으면 열차충돌 및 탈선에 대한 안전성 확보를 평가할 수 없다. 이러한 경우 전자연동장치의 안전성을 평가하기 위해서 전자연동장치의 위험측 고장(Dangerous Failure)의 발생빈도를 평가하여 등급을 부여한 것이 안전무결성수준이다.
위험측 고장률은 위험원이라는 특별한 요건에 대한 발생빈도를 예측하고 입증하여 평가한 정량적 수치이다. 정의된 사고와 관련된 위험원을 도출하고 분석하는 단계는 위험원 관리와 같이 수행되며 위험원들의 발생빈도는 FTA(Fault Tree Analysis)와 ETA(Event Tree Analysis) 등의 기법에 의해 정량화되어 목표와 비교된다.
최종 사용자의 시스템 안전성 요구사항은 정량적 수치로 주어지기도 하지만 정성적이고 모호하게 제시되기도 한다. 이러한 경우 안전이 확보되어야 할 사고의 정의부터 위험성의 제어를 위해 필요한 안전 대책의 적용 범위도 명확히 분석되어야 한다. 시스템 개발 과정에서 공급범위를 벗어나는 안전 대책에 의해서만 위험원이 안전하게 제어되는 경우를 예측하여야 한다.
안전 요구사항의 할당은 시스템 안전성과 종합 안전성에 따라 상이하다. 시스템적 안전성만을 관리하는 경우에는 안전무결성수준과 같이 시스템에 요구되는 위험측 고장률의 목표 만족을 위한 하부 구성요소들의 위험측 고장률 목표를 설계단계에서 위험원 도출 및 분석을 통해 산출하여 배분해야 한다. 종합적 안전성의 경우 시스템적 안전성을 포함하여 설치, 테스트, 운용, 유지보수와 같이 인적요소가 가입되는 사항에 대한 안전 요구사항을 도출하여 해당 수명주기에 할당해야 한다.
그림. 안전 기능과 안전무결성
안전무결성수준(SIL)은 전기전자프로그래머블제어기의 국제규격인 IEC61508 에 명시되어 있다. 안전무결성수준이 널리 사용되는 이유는 적용 대상이 명확하게 정의되지 않은 경우에 시스템의 안전성을 평가하여 시스템의 안전성을 상호 비교할 수 있는 방법이기 때문이다.
위험측 고장률은 위험원이라는 특별한 요건에 대한 발생빈도를 예측하고 입증하여 평가한 정량적 수치이다. 정의된 사고와 관련된 위험원을 도출하고 분석하는 단계는 위험원 관리와 같이 수행되며 위험원들의 발생빈도는 FTA(Fault Tree Analysis)와 ETA(Event Tree Analysis) 등의 기법에 의해 정량화되어 목표와 비교된다.
최종 사용자의 시스템 안전성 요구사항은 정량적 수치로 주어지기도 하지만 정성적이고 모호하게 제시되기도 한다. 이러한 경우 안전이 확보되어야 할 사고의 정의부터 위험성의 제어를 위해 필요한 안전 대책의 적용 범위도 명확히 분석되어야 한다. 시스템 개발 과정에서 공급범위를 벗어나는 안전 대책에 의해서만 위험원이 안전하게 제어되는 경우를 예측하여야 한다.
안전 요구사항의 할당은 시스템 안전성과 종합 안전성에 따라 상이하다. 시스템적 안전성만을 관리하는 경우에는 안전무결성수준과 같이 시스템에 요구되는 위험측 고장률의 목표 만족을 위한 하부 구성요소들의 위험측 고장률 목표를 설계단계에서 위험원 도출 및 분석을 통해 산출하여 배분해야 한다. 종합적 안전성의 경우 시스템적 안전성을 포함하여 설치, 테스트, 운용, 유지보수와 같이 인적요소가 가입되는 사항에 대한 안전 요구사항을 도출하여 해당 수명주기에 할당해야 한다.
영국의 안전성 관리 및 문서화 지침 CASS(Conformity Assessment of Safety-related Systems)
영국과 같이 안전분야의 선진국에서는 안전관련 시스템의 도입, 수정, 유지보수의 수명주기 단계별로 안전 활동을 수행하고 그 결과물을 국가가 지정한 기관에서 심사하도록 정부차원에서 강제하고 있다.
이러한 공인 기관의 심사를 위해서는 안전성 관련 요구사항 준수여부에 대한 객관적이고 효율적인 평가를 위해 공통의 양식이 필요하게 되었으며, 이러한 요구에 의한 안전성 관리 및 문서화 지침은 CASS(Conformity Assessment of Safety-related Systems)에 공유되어 많은 사업의 안전성 관리 문서화에 활용되고 있다.
이러한 공인 기관의 심사를 위해서는 안전성 관련 요구사항 준수여부에 대한 객관적이고 효율적인 평가를 위해 공통의 양식이 필요하게 되었으며, 이러한 요구에 의한 안전성 관리 및 문서화 지침은 CASS(Conformity Assessment of Safety-related Systems)에 공유되어 많은 사업의 안전성 관리 문서화에 활용되고 있다.
그림. CASS 자료 공개 사이트(http://www.61508.org)
2017년 4월 13일 목요일
SW 영향평가 제도
SW분야에서 공공과 민간의 역할 정립을 위해 공공정보화 사업의 기획단계부터 민간시장에 미치는 부정적 영향을 평가.
정부가 민간시장을 위축시키면 안 되며 민간시장에 미치는 영향을 사전 평가하는 등 공공정보화 사업 추진절체 개선(SW중심사회 실현전략 보고회, ’14.7월)
피드 구독하기:
글
(
Atom
)