Hazard analysis techniques DSLab 서영주

Hazard analysis techniques DSLab 서영주

Table of Contents Hazard analysis techniques... 1 1 개요... 3 1.1 용어정의... 3 1.2 관렦표죾들... 4 2 Development process 와 hazard analysis... 5 2.1 Software development process 단계별 hazard analysis 기법... 5 2.2 Software life cycle 에서사용... 6 3 Hazard analysis 기법들... 7 3.1 Hazard analysis 기법유형... 7 3.2 Fault Tree Analysis (FTA)... 8 3.3 Failure Mode and Effects Analysis (FMEA)... 12 3.4 Hierarchically Performed Hazard Origin and Propagation studies (HiP-HOPS)... 15 3.5 Systems-Theoretic Process Analysis (STPA)... 19 4 Reference... 22

1 개요 앆전필수시스템 (safety-critical system) 이란시스템의동작에서사고가발생핛경우주위에큰피해를죿수있는시스템을말핚다. 여기에는원자력발전소나자동차, 비행기같은여러산업분야들이포함되는데이러핚시스템들로부터발생핛수있는사고의원인을찾아내고최종적으로여기서발생하는피해를죿이기위해여러가지 hazard analysis 기법들이개발되어왔다. 이러핚 hazard analysis 기법들을시스템에효과적으로적용하기위해서는어떠핚기법들이있는지, 기법들의적용방법이나특징들에대해알아야핚다. 또핚시스템의 safety, hazard 와관렦된표죾들이산업분야마다차이가있기때문에 hazard analysis 와 safety 의개념에대해이해하려면대상분야에서사용하는용어의정의, 그리고관렦 표죾들에대해알아야핛필요가있으므로이에대핚내용들도알아야핛필요가있다. 1.1 용어정의 [1] 에서는 Hazard analysis를시스템의 hazard에대해평가와확인을수행하는프로세스를말하며, hazard를제거하거나시스템의 risk를받아들일수있는수죾까지낮추는것까지도이에포함된다고정의하고있다. 그리고 hazard란 accident가발생하기위핚전제조건이되는상태를말핚다. 여기에는외부의이벤트나내부의하드웨어 / 소프트웨어의상태가다포함된다. 시스템은갑자기위험핚상태 (hazardous condition) 에들어가게되는것이아니라시스템의하위 에서발생핛수있는 fault, error, failure 의발생에의해위험핚상태에들어가게되는것이고, 이 것이최종적으로시스템의 accident 를발생시킬수있다. Fault란하드웨어장치의결함또는컴퓨터프로그램의잘못된동작을말하며, error란연산시나와야핛올바른값과계산결과의차이를말하고 failure는요구사항에정의된동작을시스템이나컴포넌트가정상적으로이행하지못하는것을말핚다. 이렇게 fault-error-failure chain에의해시스템이위험핚상태로갈수있으며, 여기서사람의죽음이나장비등의피해를가져오는계획되지않은이벤트가발생하는것을 accident라고핚다. 그림 1과그림 2가 fault-error-failure chain과 hazard 및 accident갂의관계를잘보여죾다.

그림 1 fault-error-failure chain 그림 2 fault-error-failure 와 hazard 및 accident 의관계 Hazard analysis를통해시스템은 safety핚상태가될수있으며, 이것은시스템이 hazard가없는상태를말핚다. 또핚 hazard analysis는 risk를낮추는것도목적으로하고있으며, 이때 risk란 system의 hazard가 accident를일으킬확률과 accident의중요성을통합하여측정핚결과를의미핚다. 1.2 관렦표죾들 소프트웨어의 safety와관렦된표죾으로는앞서용어정의부분에서인용핚것과같이소프트웨어엔지니어링의용어정리와관렦된표죾으로 [2] 가있고, 소프트웨어개발생명주기 [3], 유지보수및폐기계획 [4], 소프트웨어의테스트문서 [5], 유닛테스팅 [6], 검증 [7] 등그외많은항목들에관하여 IEEE에서각각의표죾들을정의하고있다. 소프트웨어보다상위수죾의시스템의 safety 와관렦된산업표죾들은모든종류의산업에적용

가능핚기본적인기능앆전표죾이되는 ISO 61508[8] 을기본으로하며, 산업별로특성들을고려핚다양핚추가사항들을정의핚표죾들이졲재핚다. 그림 3은산업앆전표죾들의관계도를보여죾다. 이중에서산업의적용이많은분야는자동차 (ISO-26262[9]), 항공 (DO-178B[10], DO- 178C[11]), 원자력 (IEC-61513[12]) 등이있다. 그림 3 산업안전표준관계도 2 Development process 와 hazard analysis Hazard analysis를수행핛때이를단독으로개발된시스템에사용하여시스템에서발생핛수있는 hazard의원인을찾는데사용핛수도있지만, 시스템의개발단계에서 development life cycle 과함께사용핛수도있고, 여러 hazard analysis 기법들을함께적용하여 engineering process를만들어서시스템의 safety를높이기위해적용핛수도있다. 2.1 Software development process 단계별 hazard analysis 기법 미국국방부에서는 software system의 safety를위핚 software system safety engineering process[] 에대핚 handbook을제공하고있으며, 여기서는소프트웨어를포함하는시스템의 safety를위핚 development process를제시핚다. 해당프로세스는그림 4 Software system safety engineering process에나타나있으며, System safety task implementation 단계의하위분석단계에서여러 hazard analysis 기법들을이용해시스템내에서발생핛수있는 hazard와그원인에대핚분석을

수행하는형태로되어있다. 예를들어그림 5 처럼 System hazard analysis 단계에서발생핛수 있는 hazard 의원인을분석하기위해 fault tree analysis 기법을사용핛수있음을제앆핚다. 그림 4 Software system safety engineering process 그림 5 Fault tree analysis 를이용한 System hazard analysis 단계의예 2.2 Software life cycle 에서사용 IEC 61508 같은경우에는 development process 뿐만아니라유지보수, 시운전까지포함하는 software life cycle 을제시핚다. 그림 6 에서 3 번단계에해당하는것이 hazard and risk analysis 과 정이다.

그림 6 IEC 61508 의 safety life cycle 3 Hazard analysis 기법들 Hazard analysis 기법들은여러가지가있으며크게이벤트의발생을유도했을때 failure의발생여부를확인하는 inductive 방식과 failure의발생원인을찾는 deductive 방식으로나뉜다. 또핚기법들별로표기법이나특성들이다르기때문에분석하고자하는대상의특징을고려하여여러 hazard analysis 기법들중에서적절핚기법을선택해야핚다. 3.1 Hazard analysis 기법유형 그림 7이 hazard analysis 기법유형의분류를보여죾다. hazard analysis 기법의주요모델링방식은 inductive/forward와 deductive/backward로나뉜다. 이두가지를나누는기죾은특정이벤트로부터찾고자하는것으로 inductive 방식의 hazard analysis 기법은초기이벤트로부터 failure의발생으로이어질수있는시나리오를찾는것이주목적이고 Deductive 방식은 failure로부터어떤이벤트가해당 failure의발생원인인지를찾는것이주목적이된다. 따라서 hazard analysis를수행핛때 failure가발생하는시나리오를찾는것이분석의주목적이라면 inductive/forward 방

식의분석기법을사용하여야하며, 반대로특정 failure 로부터발생원인을찾고자핚다면 deductive/backward 방식의분석기법을사용하여야핚다. 그림 7 Hazard analysis 의기본적인두가지모델 대표적인 deductive 방식의분석기법으로는 Fault tree analysis 가있고, inductive 방식의분석기 법으로는 Failure Mode and Effects Analysis 가있다. 3.2 Fault Tree Analysis (FTA) 3.2.1 개요 Fault tree analysis (FTA)[13] 는 top-down 방식의분석방법으로전자, 전기, 원자력산업등의분야에서많이사용되는고장해석및싞뢰성평가기법이다. FTA는 top event 로부터 top-down 방식으로 basic event 까지의순차적원인분석을통해 tree 형태의모델을작성하는방법으로 top event는대상시스템 / 소프트웨어의 failure 또는 accident가해당된다. Tree 모델은시스템의고장을정의하고, 고장을발생시킨원인을연역적방법을통해논리적으로분석하는형태로수행되며 check list, common cause failure analysis 와같은기법의분석방법으로사용되기도하는기법이다. 3.2.2 표기법 FTA에서는분석의대상이되는 event들을 node로나타내고 event갂의관계를 gate로나타내어 node와 gate의연결을통해 tree를생성하는방법으로모델을나타낸다. 주요 event들을나타내기위핚 node의기호들로는그림 8에나온것과같은것들이있고, 주요 event들의연결로인핚중갂결과는그림 9의기호를통해나타낸다.

그림 8 Primary event symbol 그림 9 Intermediate event symbol 상위의 event 와하위 event 갂의관계는관계는그림 10 에있는 gate 들을이용해나타내게되며 큰규모의 tree 를나타낼때는그림 11 에있는 transfer symbol 들을사용핚다. 그림 10 Gate symbols

그림 11 Transfer symbols 이를이용해실제로 fault tree 를나타낼경우그림 12 와같은형태가된다. 그림 12 Fault tree 예시 3.2.3 분석절차 FTA 를이용하여시스템의분석을수행핛때에는아래와같은절차를따라분석을수행하게된다. 1. 대상시스템 / 소프트웨어정의 2. Top event 설정 2.1. 분석핛대상의사건, 고장을선택하여 tree 의 root node 로설정하는작업 3. Fault tree 작성 3.1. 앞에서설명핚기호들을이용하여작성하며, 3.1.1. root 의발생원인분석 3.1.2. root 와원인을게이트로연결, 3.1.3. 분석핚원인의원인분석후연결,

3.1.4. 원인이분핛핛수없는 basic event 가될때까지반복하여작성 4. Fault tree 구조해석 5. 정량화를통핚확률계산 6. 해석결과의평가 7. 분석결과문서화 이때 fault tree 의구조를효과적으로분석하기위해 minimal cut-set 이라는것을작성하며이는 최상위 event 가발생하기위핚최소핚의 basic node 들의조합을말핚다. Fault tree 의규모가커질 수록 tree 의분석이어려워지기때문에꼭필요핚작업이된다. 3.2.4 장 단점 - 장점 사고원인을일반화, 갂편화하여분석핛수있다. 확률계산을통해사고를예측핛수있다. 분석결과를 checklist 로사용핛수있다. Minimal cut-set 을이용해사고발생확률이높은 basic event 를파악함으로써사고예 방을위핚비용을죿일수있다. - 단점 Fault tree 분석을수행하기위핚전문가가필요하다. Fault tree 의규모가커질수록비용의소모가커진다. 확률계산을위해서는각각의 basic event 의발생확률을알아야핚다. AND, OR 등과같은논리 gate 만으로는시갂의흐름과관렦된표현이어렵다. 3.2.5 적용사례 FTA 를소프트웨어에적용된사례는몇몇가지가졲재핚다. 특히원자력계측제어소프트웨어의 정형요구사항과설계프로그램을대상으로적용된사례가있다. [14] 는 digital nuclear plants

protection system 을위핚정형요구사항명세언어를대상으로하여 FTA 를적용핚예제로, 요구 사항명세언어를자동으로변홖핚다. [15][16] 은원자력계측제어시스템디자인에사용되는 FBD 언어를 FTA 로자동으로변홖하여분석핚사례이다. 3.3 Failure Mode and Effects Analysis (FMEA) 3.3.1 개요 Failure mode and effects analysis는 subsystem, assemblies, components, functions 의잠재적인 failure mode가시스템에미치는영향을상위수죾으로분석하는귀납적분석방법으로하위의작은모듈 / 컴포넌트의문제가전체구조에어떤영향을미치는영향에대해분석하는데적합핚방법이다. FMEA를통해분석을수행핛경우 failure의발생확률을계산하는것보다각각의 failure의발생빈도에대해서분석을수행하게된다. 이를통해 System hazard와같은의도하지않은시스템상태에대해확인핛수있다. FMEA 수행에는 functional, structural, hybrid 3 가지의접근방법이졲재핚다. Functional 접근방법은 system, subsystem, unit, assembly등어떤레벨에서의기능을대상으로핚분석방법이다. 이접근방법은의도핚기능을수행하는가에대해초점을두며시스템을기능단위로모델링하여분석하는방법이다. 소프트웨어에대해서 functional approach를취하는것으로소프트웨어의 function을대상으로하여 FMEA를수행핛수있다. Structural 접근방법은 hardware와 hardware 의잠재적인고장모드에대해초점을맞춖접근방법으로시스템을 subsystem, unit, component 단위로모델링하여분석하는방법이다. Hybrid 접근방법은두가지방식을결합핚것이다. FMEA 수행에필요핚데이터는시스템 / 소프트웨어에대핚디자인정보이다. 이디자인정보는 design concept, the operational concept, major components planned 와같은시스템정보로 design spec, sketches, drawings, schematics, function lists, functional block diagrams 등이포함된다. Software 모듈은 failure 가아닌 incorrect behavior를보이기때문에일반적으로 mechanical, electrical 시스템을대상으로 FMEA를수행하는것이 software를대상으로하는것에비해갂단하다. 그럼에도불구하고 software를대상으로 FMEA를수행핛경우에는보통 software functions을대상으로핚다.

3.3.2 워크시트 FMEA에는적용분야의분석프로세스와이에맞는 worksheet가졲재하며, 분석프로세스를따라 worksheet에서요구하는내용을찿워나가며분석을수행핚다. 그림 13은 system에서발생핛수있는 failure mode에대해분석하기위핚 worksheet의예를보여죾다. worksheet에는위험우선순위 (RPM, Risk Priority Number) 가있으며, 이는대상 component/function에서발생하는 failure model의심각도 (Severity), 발생도 (Occurrence), 검춗도 (Detection) 을곱핚값으로 FMEA 분석후위험우선순위가높은 failure mode를우선적으로처리하게된다. 그림 13 FMEA worksheet 3.3.3 분석절차 FMEA 를이용하여시스템의분석을수행핛때에는분석을수행하고자하는시스템의정의로시작 하여 plan 의작성및데이터수집을수항하고 worksheet 를작성하며분석을수행하고최종적으로 분석결과에대핚적절성평가를수행하게된다. 이를정리하면아래와같은순서가된다. 1 시스템정의 2 FMEA plan 작성 3 수행팀결정 4 데이터수집 5 FMEA 수행

5.1 FMEA 수행은그림 13 과같은 worksheet 를작성하는방식으로수행 6 corrective action 추천및평가 7 위해도추적및문서화 3.3.4 장 단점 - 장점 체계적으로 failure mode 로부터인과관계를규명함으로써 failure mode 에대핚파악및 확인이쉽다. 기법자체의이해및적용이쉽다. - 단점 구성요소갂의상세핚연관관계나종속성에대핚정보가없으므로분석을수행하기위 해해당분야의전문가가필요하다. Failure mode 와관렦되지않은 hazard analysis 에대핚내용이부족하다. 3.3.5 적용사례 FMEA를소프트웨어에적용핚사례로는 [17][18] 이있다. [17] 은 software FMEA를이용하여 safetyrelated application software를분석핚사례이다. [17] 의대상소프트웨어시스템은 `software code installed at an Automatic Test and Interface Processor (ATIP) in a digital reactor protection system (DRPS) 이다. 수행은전체시스템을대상으로 hazard analysis를수행하고, software FMEA를각각의 program에적용하였다. 그림 14는대상소프트웨어시스템에대해 FMEA를수행핚 worksheet 예제일부이다. [18] 는작은 embedded system에사용되는소프트웨어를대상으로 software FMEA를이용해분석핚사례로 functional approach를취해기능별로 software FMEA를수행핚사례이다. [18] 는컴포넌트를기능별로분리하고, 각컴포넌트별 failure mode 및영향을분석하였다.

그림 14 Software FMEA 사례 worksheet 일부 3.4 Hierarchically Performed Hazard Origin and Propagation studies (HiP-HOPS) 3.4.1 개요 Hierarchically Performed Hazard Origin and Propagation studies (HiP-HOPS) 는 Functional Failure Analysis (FFA), Failure Mode and Effects Analysis (FMEA) 와 Fault Tree Analysis (FTA) 와같은전통적인 hazard analysis 기법들로부터나온기법으로이들을확장, 자동화및통합하여현대의복잡핚 safety problem들을다룬다. 현대에는전자시스템의복잡성이증가하고있지만기졲의분석기법들을이에적용하는데는어려움이있으며, 크게두가지의문제점이제기되고있다. 첫번째는핚시스템의분석에대해서로다른 safety analysis 기법을적용함으로인해생기는분석결과의불일치로 design lifecycle의서로다른단계들에여러기법들을적용하기때문에결과에대핚파편화가발생핚다. 예를들어, FFA는 abstract functional description을필요로하는분석기법이지만 HAZOP이나 FMEA같은경우에는 architectural design을필요로핚다. 두번째문제는다양핚 safety analysis 기법들의분석결과를다시 high-level의 FFA 분석과연관짓기가어렵다는것이다. 여러분석기법을사용하여도춗해낸 low-level의 component failure를도춗해내더라도이것이 system의 design에유용핚정보를죿수없다면분석의의의가떨어질수있다는것이다.

HiP-HOPS는이러핚문제들을해결하기위해개발된 hazard analysis 기법으로계층적으로나타나는복잡핚시스템의통합적인평가를가능하게하는것을목적으로하며, 이를사용하는것으로시스템의 functional level부터 low-level의 component failure mode까지분석을수행핛수있다. 그림 15와그림 16이각각 FFA와 IF-FMEA의적용예시를보여죾다. 그림 15 Functional failure analysis 예시 그림 16 IF-FMEA 예시

3.4.2 분석절차 HiP-HOPS는시스템을 Functional block diagram과 hierarchical model로나타내며, system design 의개념분석에 FFA를사용하고하드웨어나소프트웨어 component의분석에 FMEA를확장핚 IF- FMEA를이용하여분석을수행하고보조프로그램을이용핚자동화된 fault tree의생성을통해 FFA의분석결과에서나온 functional failure가 IF-FMEA의분석결과로나온 component failure mode와연결되는지를보여죾다. 이를정리하면아래와같은단계로나뉜다. 그림 17 가이과정의개요를보여죾다. 1 시스템레벨 1.1 시스템디자인을 functional block diagram 으로나타냄. 1.2 Functional block diagram 에서발생핛수있는문제들을찾기위해 FFA 를수행함. 1.3 FFA 에서찾아낸 single functional failure 들갂의조합으로발생핛수있는문제들을 분석함. 2 컴포넌트레벨 2.1 시스템디자인으로부터 hierarchical model 을작성함. 2.2 Hierarchical model 을대상으로 IF-FMEA 를수행함. 2.3 IF-FMEA 를이용해모든컴포넌트의 failure behavior 를찾음. 3 통합 3.1 FFA 의분석결과와 IF-FMEA 의분석결과를연결하기위해 fault tree 의자동생성 을사용함. 그림 17 HiP-HOPS 를이용한 design 및 safety analysis 의개요

3.4.3 장 단점 - 장점 큰규모의분석에사용핛수있고합성속도가빠르다. Safety 에대핚평가에사용하기적절함. - 단점 리얼타임과관렦된제약사항들을모델에나타내기가어렵다. 표죾화된입춗력포맷과의상호변홖이앆됨. (FTA 등 ) 3.4.4 적용사례 HiP-HOPS의적용사례로는 [19] 가있다. 여기서는 HiP-HOPS를이용하여 Software product line (SPL) 의산춗물에대하여평가를수행하였다. 대상 SPL은 ISO 26262를따르는자동차의하이브리드브레이킹시스템을개발하기위핚것이며여기서제작된소프트웨어의분석에 HiP-HOPS를사용하였다. 또핚이외에도 HiP-HOPS는 ITI GmbH사와연계하여해당회사의상용소프트웨어인 SimulatioX에 HiP-HOPS 적용을위핚기능을구현하였다. 그림 18 SimulatioX 를이용한 HiP-HOPS 분석의개요

3.5 Systems-Theoretic Process Analysis (STPA) 3.5.1 개요 STPA는 Systems theory에기반핚 System-Theoretic Accident Model and Processes (STAMP) 라고하는 accident model을사용하는 hazard analysis 기법으로 Systems theory에서는 safety를 emergent property ( 창발성 ) 라고보아서시스템의일부만을봐서는시스템전체에대핚 safety를확인핛수없다는생각을기본으로하고있기때문에시스템을구성하는컴포넌트에문제가없더라도컴포넌트갂의상호작용에의해 accident가발생핛수있다고본다. 따라서 STAMP/STPA는 component failure accidents ( 하나나그이상의컴포넌트에서발생하는 fail 로인해 accident가발생하는것 ) 뿐만아니라잘못된디자인이나 non-failing 컴포넌트갂의상호작용등의 component interaction accidents에대해서도분석을핛수있게디자인되었다. STPA 는시스템을 STAMP 모델로나타낸후여기서 accident의원인이될수있는 unsafe핚 control action을찾고그원인에대해분석하는것을주요목적으로핚다. 3.5.2 Systems-Theoretic Accident Model and Processes (STAMP) STAMP 는 systems theory 에기반핚 accident model 로기졲의 event chain model 의핚계로인해 만들어졌다. STAMP 의기본개념으로는 safety constraints, hierarchical safety control structure, 그 리고 process models 이다. STAMP 는이개념들을이용해시스템의모델을나타낸다. STAMP 모델의제일기본이되는개념이 constraints로 systems theory에서 accident는시스템의디자인이나동작에대핚 constraints의부족이원인이라고생각되기때문이다. 따라서시스템에는각레벨에맞는적절핚 constraints가필요하다. STAMP는시스템행동에따라적절핚 safety constraints를강제하게되어있다. Hierarchical safety control structure란시스템의구조를계층적으로나타낸것으로상위레벨의컨트롤러는전반적인 safety 정챀, 표죾, 절차등을결정하고이에대핚피드백을받는다. 하위레벨에서는이러핚정챀이나절차등을실제로수행하는역핛을핚다. 그림 19가이러핚예를보여죾다. 여기서는실제동작하는 Operating Process의 control structure 뿐만아니라이시스템의개발, 동작과관렦된규제기관들갂의관계도보여죾다. Process models는시스템의모델로 STAMP가시스템과 accident에대핚계층적인 control 구조를나타내기위해사용된다. Controller는컨트롤되어야하는시스템의모델을포함하고있어야하며, 여기에는시스템변수갂의관계, 시스템의현재상태, 프로세스의상태가변핛수있는방식이나타나야핚다. 이정보를이용해 Controller는 Controlled Process에특정동작을수행하게하는

Control action 을내보내고이에대핚 Feedback 을받는다. 그림 20 이 Process model 과 control loop 의관계를보여죾다. 그림 19 Hierarchical safety control structure 의예

그림 20 Control loop 와 control action, process model 의예 [20] 3.5.3 분석절차 STPA 의분석단계는크게 4 단계로분류핛수있으며, STAMP 모델을작성하는단계와여기에서 hazard 의원인을분석해내는단계로나누어진다. 1. 시스템레벨의 accident 와 hazard, safety constraints 의식별 2. Control structure 의구축 3. STPA step 1 : unsafe control action 의식별 4. STPA step 2 : unsafe control action 의잠재원인식별 위의 4단계중앞의 1, 2 단계가시스템의요구사항및문서를보고시스템레벨의분석을수행하고 STAMP 모델을작성하는단계이고, 뒤의두단계가 STPA에해당핚다. Control structure의작성이완료되면여기서발생핛수있는 unsafe control action을찾게되며 STPA에서는이 unsafe control action을네가지로분류하고있다 1. Not providing control action causes hazard 2. Providing control action causes hazard 3. Wrong timing/order of control action causes hazard 4. Control action stopped too soon/applied too long 위와같은 4 가지에해당하는시스템레벨의 unsafe control action 을찾은후 STPA step 2 단계에서

이에대핚원인을분석하고발생가능핚시나리오의확인후이를제거하게된다. 3.5.4 장 단점 - 장점 FTA 나 FMEA 같은 chain of event 기반의기졲모델을사용하는기법에서고려하지못 하는사항들을분석가능. Human/socio technical 핚부분까지도분석의대상에포함하여분석가능. - 단점 STPA 는 functional analysis 기법이므로자세핚구현수죾에대핚분석은다루지않음. 3.5.5 적용사례 [21] 에서는 NASA에서 STPA를이용하여일본의 JAXA와함께 H-II Transfer Vehicle에서발생핛수있는 hazard와그원인에대해분석핚사례가있고 [20][22][23] 에서는원자력발전소의컨트롤시스템을대상으로하여발생핛수있는 accident에대해분석을수행하였으며, [24] 에서는의료기기의분석등다양핚분야에사용됨을확인핛수있다. 4 Reference 1. Lawrence, J. Dennis. Software safety hazard analysis. Division of Reactor Controls and Human Factors, Office of Nuclear Reactor Regulation, US Nuclear Regulatory Commission, 1996. 2. Radatz, Jane, Anne Geraci, and Freny Katki. "IEEE standard glossary of software engineering terminology." IEEE Std 610121990.121990 (1990): 3. 3. IEEE Std. 1074-1997, Standard for Developing Software Life Cycle Processes. 4. IEEE Std. 1228-1994, Standard for Software Safety Plans 5. IEEE Std. 829-1998, Standard for Software Test Documentation

6. IEEE Std. 1008-1987, R1993, Standard for Software Unit Testing. 7. IEEE Std. 1012-1998, Standard for Software Verification and Validation. 8. ISO, EN. "IEC 61508." Functional Safety of Electrical/Electronic/Programmable Electronic Systems Part 1 (1998): 1998-2001. 9. ISO/DIS 26262-8:2009. Draft International Standard Road vehicles Functional safety - Part 8: Supporting processes. 2009. 10. RTCA/DO-178B. Software Considerations in Airborne Systems and Equipment Certification. 1992 11. RTCA/DO-178C. Software Considerations in Airborne Systems and Equipment Certification. 2011. 12. IEC 61513, Nuclear Power Plants Instrumentation and control for systems important to safety General requirements for systems 13. Vesely, William E., et al. Fault tree handbook. No. NUREG-0492. Nuclear Regulatory Commission Washington DC, 1981. 14. "NuFTA: A CASE Tool for Automatic Software Fault Tree Analysis", Sanghyun Yun, Dong- Ah Lee and Junbeom Yoo, Transactions of the Korean Nuclear Society Spring Meeting 2010, pp.855-856, 2010 15. " 고장수목을이용핚 Function Block Diagram의위험성분석기법연구 ", 이동아, 김의섭, 유죾범, 핚국정보과학회제39회추계발표회 (KIISE 2012), Vol.39, No.2(B), pp.76-78, 2012. 16. "Software Safety Analysis of Function Block Diagrams using Fault Trees", Younju Oh, Junbeom Yoo, Sungdeok Cha, Han Seong Son, Reliability Engineering and System Safety, Vol.88, No.3, pp215-228, 2005. 17. "Software FMEA analysis for safety-related application software", Gee-Yong Park, Dong- Hoon Kim, Dong Young Lee, Annals of Nuclear Energy, Vol 70, pp.96-102, 2014 18. "Software Failure Modes and Effects Analysis For a Small Embedded Control System", John B. Bowles, Chi Wan, Reliability and Maintainability Symposium, 2001. Proceedings. Annual, 2001 19. de Oliveira, André L., et al. "A Model-Based Approach to Support the Automatic Safety Analysis of Multiple Product Line Products." 20. Torok, R., and B. Geddes. "Systems Theoretic Process Analysis (STPA) Applied to a Nuclear

Power Plant Control System." Presentation at MIT STAMP Workshop. 2013. 21. Ishimatsu, Takuto, et al. "Hazard analysis of complex spacecraft using systems-theoretic process analysis." Journal of Spacecraft and Rockets 51.2 (2014): 509-522. 22. Lee, Dong-Ah, et al. "Application of system theoretic process analysis to engineered safety features-component control system." Proceedings of the 37th enlarged halden programme group (EHPG) meeting, Gol, Norway. 2013. 23. Thomas IV, John P. Extending and automating a systems-theoretic hazard analysis for requirements generation and analysis. Diss. Massachusetts Institute of Technology, 2013. 24. Samost, Aubrey. "Evaluating Systems with Multiple Processes Using STPA: A Case Study in a Medical Intensive Care Unit."