원자력 전산코드 중심의 품질보증 프로세스

Ⅰ. 서 론

안전 소프트웨어는 시스템 안전의 부분집합이다. 안전 소프트웨어는 안전성-필수, 안전성-관련 및 비안전으로 분류할 수 있다. 기능안전이란 운용자 오류, 하드웨어 및 소프트웨어 고장, 환경적 변화 등에 대한 안전한 관리를 포함, 주어진 입력에 대하여 정확히 동작하는 안전관련 시스템(또는 장비)에 의존하는 하나의 시스템(또는 장비)의 전체적인 안전성을 의미한다. 이러한 산업 분야는 예를 들면 자동차, 철도, 의료기기, 항공우주, 선박 및 원자력 분야가 있다. 즉, 기능안전은 안전의 일부분으로 시스템이나 장비에 의해 좌우되는 안전을 의미한다. 이러한 시스템이나 장비는 상위 레벨의 시스템 설계사양 {FDR(Functional Design Requirement), SD(System Description), SDR(System Design Requirement), DS(Design Specification), IR(Interface Requirement)}부터 계획, 요구사항, 설계, 구현, 통합, 시험.검증, 유효성 확인, 생산 및 배포에 이르기 까지 철저하게 형상관리, 검증 및 확인, 안전성 분석 등의 일련의 품질보증 프로세스가 종합적으로 수행되어야 한다[1].

본 논문에서는 안전 관련 산업분야(예를들면, 자동차, 교통, 철도, 통신, 의료, 엘리베이터, 전력, 항공, 조선, 빌딩, 스마트시티, 원자력, 전력, 지하철, 차량, 무기체계, 공항, 항만, 보안, 금융, 가전, 제조, 놀이기구, 재난 대응 등)에 응용할 수 있는 안전소프트웨어 대한 품질보증 프로세스를 원자력 전산코드를 중시으로 제시하였다. 안전성-필수 소프트웨어 및 안전성-관련 소프트웨어의 개발과 검증시에는 반드시 적용 법규와 기술 표준(Codes and Standards)을 준수하여야 한다. 이들 소프트웨어의 개발과 검증 전에 준비단계로서 첫째, 사업 특성에 맞는 품질보증매뉴얼과 품질보증절차서를 작성한 후 적용 법규와 기술 기준의 Cut-off Date 기준선(baseline)을 설정한다. 둘째, 용어를 정의하고 약어집을 발행한다. 셋째, 사업 전과정의 공정 스케줄과 함께 누가 어떤 문서를 작성하고 검토(관리적 독립검토 및 기술적검토 포함)하며 승인하는 지에 대한 문서생산 목록을 작성한다. 안전성-필수 소프트웨어와 안전성-관련 소프트웨어의 개발 산출물에 대한 품질보증 활동(assurance activities)은 크게 4가지의 범주(소프트웨어 안전성 분석, 소프트웨어 검증과 확인, 소프트웨어 형상관리, 일반규격품 품질인증(Commercial Grade Item Dedication : CGID)으로 구분하는 것이 일반 정보통신 산업계와의 차이점이 있다. 사전준비 단계가 끝나면 소프트웨어 개발 생명주기(software development life cycle) 모델을 설정한다. 약 15가지의 소프트웨어 개발 생명주기 모델이 있지만 기능안전 분야에는 계획 단계, 개념 단계, 요구사항 단계, 설계 단계, 구현 단계, 시험 단계, 설치와 점검단계, 운영과 유지보수 단계를 표준 모델로 제안하고자 한다. 기능안전 분야에서의 개발과 검증 소프트웨어의 품질보증 적합성 평가를 위해서는 총43종의 많은 문서들을 생산하여야 한다. 본 논문은 안전 관련 산업분야중 원자력 전산코드 분야에 적합한 소프트웨어 품질보증 적합성 평가 프로세스를 개발과 검증 체계의 2가지 관점에서 제시하였다. 원자력 산업 분야에는 여러 가지 다양한 많은 종류의 소프트웨어가 있다. 이들 중 본 논문에서는 원자력분야의 전산코드(Computer Code : 설계 관련 응용소프트웨어 패키지를 전산코드라는 용어로 사용함)를 대상으로 안전 소프트웨어를 위한 품질보증 프로세스를 제안한다. 전산코드라 함은 원자로 설계{노심설계(핵연료), 원자로 용기, 내부 구조물 설계}, 냉각계통설계(기기와 유체계통 설계), 제어/보호계통 설계, 계통의 성능 및 안전성 평가를 수행하는 소프트웨어를 통칭하는 용어이다. 본 논문에서는 설계시 사용하는 전산코드를 중심으로 소프트웨어 인허가 확보를 위한 소프트웨어 품질보증 적합성 평가 기준, 평가체계 및 방법론을 제시한다. 본 논문은 소프트웨어 검증 및 확인의 국제표준 동향분석, 승인 프레임워크, 품질인증 활동 및 전산코드 분류에 따른 생명주기 맞춤 정책을 제안한다,

본 논문은 기존의 ASME/NQA-1, 1994, 1995a에 기반의 전산코드 품질인증체계를 ASME/NQA-1, 2008, 2009a 기반의 체계로 갱신하여 최신 국제표준 동향에 맞게 적용법규와 기술표준 기준선 갱신(Updating of Code Cut-Off Date Baselne) 문제를 해결한다. 또한 제안한 품질보증 프로세스에 따라 개발한 7종의 가이드 종류를 제시한다. [17][18][19]

종전의 전산코드 품질보증 프로세스와 본 논문에서 제시한 품질보증 체제에 따라 업그레이한 차이점을 ASME/NQA-1 관점에서 비교하면 그림 1과 같다.

Fig. 1.

Comparison of the difference between the previous and the latest computer code quality assurance process

기존과 종전과의 차이점은 첫째, 계획단계에서 소프트웨어 확인 및 검증계획서 한개만을 요구하였으나 최근에는 소프트웨어 확인 및 검증계획서 이외에 소프트웨어 품질보증계획서가 추가 되었다. 둘째, 소프트웨어 개발단계에서 종전에는 요구사항 기반의 시험 위주였으나 구조기반의 통합시험 부분이 추가 되었다.

Ⅱ. 전산코드 적합성 평가체계

본 논문은 국제표준의 기술기준 및 승인 프레임워크를 분석하여 원자력 전산코드에 적합한 품질적합성 기준, 평가체계 및 방법론을 제시 하였다. 이들중 최근 핵심 이슈가 되고 있는 시험활동 계획과 패키징 부분 그리고 최근 이슈가 되고 있는 보안 개발환경 및 운영계획에 공통적으로 포함하여 할 주요 항목들도 함께 제안하였다. 이외, 전산코드를 Category A, Category B 및 Category C로 구분하여 각각의 등급에 맞는 소프트웨어 공정 프로세스와 활동들을 제시하였다.

2-1 검증 및 확인의 국제표준 동향분석

안전 소프트웨어에 대한 검증 및 확인의 국제표준 동향을 요약하고자 한다. 그림2는 안전 소프트웨어 산업분야에 대한 과거, 현재 그리고 미래에 대한 기술동향 흐름이다. 초기에는 시험을 활동을 검증 및 확인 분야로 간주하였다. 소프트웨어 검증은 추적성, 철저한 시험과 함께 안전성과 보안성을 중요시 여긴다. 과거에는 소프트웨어를 하나의 항목(Item)으로 생각하였는데 최근에는 소프트웨어와 하드웨어의 결합(Embedded), 펌웨어(Firmware) 및 SoC(System on Chip)도 하나의 항목 개념으로 취급한다. 개별 항목 중심에서 병합된 형태로 개념이 바뀌었다. 즉, 시스템 위주로 통합하여 취급한다. 국제표준은 크게 미국의 US-NRC(United State-Nuclear Regulatory Commission)를 중심으로 한 IEEE-Std와 유럽의 IAEA(International Atomic Energy Agency)를 중심으로 한 IEC-Std 표준 프레임 워크가 있다. 우리나라의 경우 미국의 US-NRC를 중심으로 한 IEEE-Std를 준수하고 있다. 필요에 따라 유럽의 IEC-Std를 참고한다. 한국 고유의 전력산업기술기준 KEPIC(Korea Electric Power Industry Code)이 있으나 국내 특성을 고려한 부분을 제외하고는 US-NRC를 중심으로 한 IEEE-Std 프레임워크와 거의 유사하다. [1]

Fig. 2.

International trend analysis of verification and validation

2-2 승인 프레임워크

안전성-필수 소프트웨어 및 안전성-관련 소프트웨어의 개발.검증 산출물에 대한 품질보증 활동(assurance activities: (소프트웨어 안전성 분석, 소프트웨어 검증 및 확인, 소프트웨어 형상관리, 일반규격품 품질인증{Commercial Grade Item Dedication : CGID)}의 상호 연계관계를 요약하면 그림3와 같다. 음영 부분이 검증 및 확인 활동이며 나머지 부분이 개발활동이다. 안전 소프트웨어를 위한 품질보증 프로세스는 그림3과 같은 유기적인 상호 활동하에서 이루어 져야 한다.[1] 특히, 일반규격품품질인증은 구매가 이루어지기 이전에 수행되어야 한다. 일반산업계와 다른점은 안전성 분석, 독립 시험, 형상관리, 일반규격품품질인증 활동이 크게 다르다. 일반 산업계에서는 안전성 분석이 없으며 독립시험을 요구하지 않는다. 그리고 형상관리의 경우는 반드시 형상관리 위원회를 두고 철저한 배포관리를 하여야 한다. 일반규격품품질인증은 도구의 직접사용과 간접 사용응로 수분하여 “도구 품질평가”와 상용인증으로 구분한다.

Fig. 3.

Relationship of quality evaluation system

그림3에 표기된 영문 약어들의 의미는 다음과 같다. 소프트웨어 관리 계획 : SMP(Software Management Plan), 소프트웨어 개발계획 : SDP(Software Development Plan), 소프트웨어 품질 보증 계획 : SQAP(Software Quality Assurance Plan), 소프트웨어 검증 및 확인 계획 : SVVP (Software Verification and Validation Plan), 소프트웨어 형상관리 계획 : SCMP(Software Configuration Management Plan), 소프트웨어 안전 계획 : SSP(Software Safety Plan), 일번규격품 품질인증계획 : CDP{COTS(Commercial Off-The Shelf) Dedication Plan}, 소프트웨어 품질보증 SQA(Software Quality Assurance), 소프트웨어 검증 및 확인 : SVV(Software Verification and Validation), 소프트웨어 형상관리 : SCM(Software Configuration Management), 소프트웨어 안전성 분석 : SSA(Software Safety Analysis), 소프트웨어 관리계획 : SPMP(Software Project Management Plan), 기능형상감사 : FCA(Functional Configuration Audit), 물리형상감사 : PCA(Physical Configuration Audit)

소프트웨어 품질보증그룹은 품질보증 매뉴얼 및 품질보증 절차를 작성하고 이들의 기준에 따라 검토, 감사 및 인스팩션을 수행한다. 안전성 분석그룹은 안전성 분석을 수행하는데 개발자 및 검증자가 사용할 상용도구들에 대하여 품질평가 및 일반규격품품질인증을 수행한다. 소프트웨어 검증 및 확인 그룹은 독립적인 입장에서 개발자의 산출물에 대하여 검토, 감사, 분석, 시험 및 평가 등의 검증 및 확인 활동을 수행한다. 소프트웨어 형상관리 조직은 형상관리위원회를 운영하고 형상식별, 형상통제, 형상상태기록, 형상평가 및 형상기록, 연계성 통제, 배포 관리 및 인도 등 기준선(baseline)을 관리한다.

그림 3의 13개의 계획문서들 중 최근 중요시 되고 있는 보안 개발환경 및 운영계획은 크게 2단계(개발단계, 운영 및 유지보수 단계)로 구분한다. 첫째 개발단계는 보안성이 확보된 개발 환경이다. 즉, 개발 과정에서 사용되는 도구들 및 각종 소프트웨어 들이 원치 않은, 필요하지 않은, 문서화되지 않은 기능이 포함되지 않음을 보장하여야 한다. 연결된 시스템의 원치않은 행위와 부주의한 접근으로부터 발생할 수 있는 사건으로 인해 시스템의 신뢰성 있는 운영이 저해되지 않게 하기 위한 논리적, 행정적 통제 특성을 가져야 한다.

둘째, 운영 및 유지보수 단계는 운영중에 악의적 사이버 공격으로부터 보호하기 위한 수단 및 통제 체계가 수립되어야 한다는 것이다. 이들의 접근방법은 기술적, 운영적(관리적) 측면에서 적용할 수 있어야 한다.

보안 개발환경 및 운영계획서는 각각 2개의 문서로 별도 작성하여야 한다. 보안 개발환경계획서는 소프트웨어 개발초기에 작성한다. 운영 및 유지보수 계획은 사용자가 소프트웨어를 인도 받은 후에 운영시설에서 필요한 계획서이다. 이들 2개의 계획서는 각각 따로따로 작성하여야 하지만 공통적으로 다음과 같은 내용들을 포함하여야 한다. (그림4)

Fig. 4.

Major contents for secure development and operation environment

• ㅇ 개요
• ㅇ 보안성이 확보된 개발 및 운영환경
• ㅇ 보안성 운영환경(Secure Development and Operational Environment : SDOE) 설계특성
• ㅇ 조직의 책임 및 역할(Division of Responsibility : DOR) 관리방안
• ㅇ 소프트웨어 생명주기 단계별 보안성 평가 활동
• ㅇ 문서화 및 Secure 형상 DB(Data Base)

다음은 안전 소프트웨어 품질의 두 번째 이슈인 소프트웨어 시험 공정과 활동에 대하여 언급하고자 한다. 소프트웨어 시험이란 시스템이 정해진 요구를 만족하는지,예상과 실제 결과가 어떤 차이를 보이는지 수동 또는 자동 방법을 동원하여 검사하고 평가하는 일련의 과정을 의미하는데 시험은 일반적으로 단위시험, 통합시험, 시스템 시험으로 구분한다. 여기서 통합시험은 통합시험 단위(Granule Under Test : GUT)에 따라 여러 가지 조합이 있을 수 있는데 크게 소프트웨어와 소프트웨어의 통합(SW+SW), 그리고 통합된 소프트웨어와 하드웨어와의 통합(Integrated SW+HW)으로 분류할 수 있다. 전산코드에서의 시험방법과 관련 산출물들은 다음과 같다.

• ㅇ 시험방법 : 구조시험, 기능시험, 스트레스시험, 회귀시험 및 검증시험
• ㅇ 시험계획, 시험절차 및 시험결과
  - 컴포넌트 시험계획, 절차서 및 결과보고서
  - 통합 시험계획, 절차서 및 결과보고서
  - 시스템 시험계획, 절차서 및 결과보고서
  - 시스템통합 시험계획, 절차서 및 결과보고서

여러 가지 종류의 시험계획서, 시험절차서 및 시험결과보고서를 요약하여 마스터 시험 계획(MTP : Master Test Plan)에 포함하여야 한다.[2]

원자력 산업 분야와 같은 기능안전 분야의 경우, 기능(Function)-시스템(System)-서부시스템(Subsystem)-컴포넌트(Component)-기기(Equipment)-센서(Sensor) 등의 계층 구조가 복잡하고 여기에 탑재 되는 소프트웨어 종류 또한 다양하기 때문에 이들의 계층을 어떻게 명확히 구분하여 명명하는 것이 매우 중요하다.

본 논문에서는 컴포넌트(Component) , 유닛(Unit), 시스템(System)/원채널(One Channel), 그리고 계통통합(system integration)으로 구분하여 계층화 및 통합의 범위 등을 명확히 구분하였다. 이렇게 구분한 이유는 시스템이 구조화 되어 있고 적용할 수 있는 레벨이 다양하기 때문이다.

• ㅇ 컴포넌트(Component) : 모듈의 관점
• ㅇ 유닛(Unit) : 통합의 여러 가지 형태 조합에 따른 관점
• ㅇ 시스템(System)/원채널(One Channel) : 서브시스템 통합의 관점
• ㅇ 계통통합 시험 : 전체 종합의 관점

계통통합 시험을 제외한 3가지의 설계단계(V-모델의 왼쪽) 부분과의 시험.검증의 매핑 관계는 그림5와 같이 제시하였다.

Fig. 5.

V-model mapping according to test typeNote : MT(Module Test), IT(Integration Test), ST(System Test), SW(Software), HW(Hardware)

여기서 초록색 부분(왼쪽)은 개발자의 활동이며 주황색(왼쪽 일부와 오른쪽 부분)은 검증 및 확인 활동 부분이다. 그림5는 시험의 관점에서 초기에 GUTGranule Under Test) 정의에 따라 통합 수준을 다양화 할 수 있도록 하였다.

2-3 품질인증 활동

안전 소프트웨어를 위한 품질보증 프로세스는 앞서 언급한 그림3와 같은 소프트웨어 산출물의 체계적인 개발과 검증 활동속에서 수행된다. 그림5의 V-Model은 기존의 V-Model을 수정.보완하여 소프트웨어 생명주기에 따라 세부적으로 소프트웨어 안전성 분석, 소프트웨어 검증 및 확인, 소프트웨어 형상관리, 일반규격품 품질인증 수행과 연계될 수 있도록 재구성하였다. 이들의 책임사항과 역할 그리고 세부적으로 적용하여야 할 기술 활동들은 표1과 같다.

Table 1.

Division of responsibility and technical activity for quality assurance

Ⅲ. 전산코드 분류에 따른 생명주기 맞춤 정책(tailoring policy)

본 논문에서는 원전 계통설계시 사용되는 전산코드에 대하여 소프트웨어 생명주기를 크게 개발이행전 단계, 개발이행 단계 그리고 개발이행후 단계로 구분하였다. 이들 생명주기 공정 활동들을 카테고리로 묶으면 다음과 같다. 소프트웨어 생명주기 공정에서 SDV(Software Design Verification) 단계, SVVR(Software Verification and Validation Report) 단계 및 코드 인증서(Certificate of Compliance) 발행 단계를 제시한 것이 일반정보통신 산업계와 다르다. [3]

• ㅇ 개발 이행전 단계
  - 계획단계(planning phase)
  - 개념단계(concept phase)
• ㅇ 개발이행 단계
  - 요구사항 단계(requirement phase)
  - 설계 단계(design phase)
  - 구현 단계(implementation phase)
  - 시험 단계(test phase)
    . 통합시험(integration test)
    . 승인시험(acceptance test)
  - SDV(Software Design Verification) 단계
  - 매뉴얼작성 단계
  - SVVR(Software Verification and Validation Report) 단계
  - 설치와 검사 단계(installation & checkout phase)
  - 코드 인증서(C of C : Certificate f Compliance) 발행단계
• ㅇ 개발이행 이후 단계
  - 운영과 유지보수 단계(Operation & Maintenance Phase)
  - 폐기단계(Retirement Phase)

표1에 표기된 영문 약어들의 의미는 다음과 같다. 소문자 r(Management Review)은 관리적인 관점에서의 검토를 의미한다. 대문자 R(Technical Review)은 기술적인 검토를 의미한다, 대문자 V(Verification)는 독립검증을 의미한다., 대문자 S(Safety Analysis 활동)는 안전성 분석을 의미한다. 기능적 형상감사는 FCA(Functional Configuration Audit) 이다. 물리적 형상감사는 PCA(Physical Configuration Audit) 이다. 인-프로세스 감사는 IA(In-Process Audit) 이다. 소프트웨어 검증 및 확인활동을 SVV(Software Verification and Validation)라고 표기하였다. 소프트웨어 품질보증은 SQA(Software Quality Assurance) 이다. 소프트웨어 형상관리는 SCM(Software Configuration Management) 이다. 소프트웨어 안전성 분석은 SSA(Software Safety Analysis) 이다. 그림3의 품질적합성 평가체계 활동들을 소프트웨어 생명주기 공정에 따라 매핑한 결과가 표1이다.

표1을 좀더 자세히 기술하면 앞서 언급한 그림3의 품질적합성 평가체계의 상호관계도를 소프트웨어 안전성 분석, 소프트웨어 검증 및 확인, 소프트웨어 형상관리 및 일반규격품 품질인증을 표1의 오른쪽 DOR(Division of Responsibility : 책임사항 및 역학분담)으로 놓고 생명주기 공정상의 관점에서 품질 적합성 평가 활동들을 할당한 것이다.

이들중 소프트웨어 생명주기상의 개념단계, SDV 단계 및 매뉴얼 작성 단계는 생명주기 공정상에서 플랫폼, 적용대상,복잡도 및 프로그램의 예상 크기에 따라 앞뒤의 순서, 생략 등 융통성 있게 적용할 수 있다.

앞에서 언급한 바와 같이, 안전 소프트웨어는 안전성-필수, 안전성-관련 및 비안전으로 분류할 수 있다고 하였다. 사용목적 및 분야에 따라 2차원적으로 세분화 하면 전산코드는 설계코드, 해석코드 및 연구개발(R&D) 코드로 재분류할 수 있다. 재분류의 목적은 안전 중요도의 등급분류(class)에 따라 생명주기 맞춤정책(tailoring policy)으로 차등 적용할 수 있기 때문이다. 표2와 같이 안전 중요도에 따라 Class A, Class B 및 Class C로 소프트웨어 생명주기를 차등 적용하면 비용 효과적인 접근방법(cost effective approach)이 가능하다.

Table 2.

Software Development Life Cycle for Safety-grade

Ⅳ. 결 론

본 연구는 원전 계통설계의 전산코드를 중심으로 소프트웨어 인허가 확보를 위한 소프트웨어 품질보증 적합성 평가기준, 체계 및 방법론을 제시하였다. 소프트웨어 생명주기 동안 품질보증 프로그램과 문서화된 절차에 따라 소프트웨어 개발 산출물에 대하여 소프트웨어 검증 및 확인, 안전성 분석, 일반규격품 품질인증 그리고 엄격한 형상관리 등의 품질인증 체계를 제시하였다. 이외, 보안성이 확보된 개발 및 운영환경계획서와 사이버보안계획서에 공통적으로 포함하여야할 내용들도 함께 제시하였다.

본 논문에서 제안한 전산코드 품질보증체제에 따라 다음과 같은 7종의 가이드를 개발하였다.

• ㅇ [전산코드 가이드1] 총괄편(공통), NuICT-COD-GUD101
• ㅇ [전산코드 가이드2] 개발 및 변경 가이드(PART-I), NuICT-COD-GUD102
• ㅇ [전산코드 가이드3] 분류 가이드(PART-II), NuICT-COD-GUD103
• ㅇ [전산코드 가이드4] 시험관리 가이드(PART-III), NuICT-COD-GUD104
• ㅇ [전산코드 가이드5] 검토.승인 가이드(PART-IV), NuICT-COD-GUD105
• ㅇ [전산코드 가이드6] 일반규격품 품질인증 가이드(PART-V), NuICT-COD-GUD106
• ㅇ [전산코드 가이드7] 형상관리 가이드(PART VI), NuICT-COD-GUD107

소프트웨어 품질 적합성 평가 기준 및 체계는 USNRC-based IEEE 표준을 기반으로 소프트웨어 분류 등급에 따라 맞춤정책으로 제안하였다. 특히 시험의 경우 통합 수준에 따라 다양한 시나리오가 있을 수 있는데 GUTGranule Under Test) 정의에 따라 통합 수준을 다양화 할 수 있도록 하였다. 이러한 품질보증 체제는 기능안전 분야에서 규제기관의 인허가 확보를 위한 징검다리로써 활용할 수 있다.

Acknowledgments

본 연구는 2020년도 과학기술정통부의 주요사업 “원자력 ICT 안전성 검증체계 구축 및 운영(1711122841)” 지원에 의하여 이루어진 연구로서, 관계부처에 감사드립니다.

References

• Jang-Yeol Kim, “Acceptable FPGA Framework based on the IEEE Std-1012 and IEC Std-62566”, 11th International Workshop on Application of FPGA in NPPs, Dallas, Texas.
• Jang Yeol Kim, “FPGA V&V Framework based on IEEE 1012 and IEC 62566”, 2020 Spring Workshop of Nuclear I&C, HFE, and Automatic Remote, Korea Nuclear Society(KNS)
• Jang-Yeol Kim, “Configuration Management Process using Classified Computer Code”, NPIC&HMIT 2019, Orlando, FL, February 9-14, 2019.
• Jang-Yeol Kim, Soon-Gohn Kim, “Software Qualification Approach for Safety-critical Software of the Embedded System”, The 2012 International Conference on Future Generation Communication and Networking (FGCN), Kangwondo Korea, December 16-19, 2012
• J. Y. Kim, Kee-Choon Kwon, “The Commercial Off The Shelf(COTS) Dedication of QNX Real Time Operating System(RTOS),” International Conference on Reliability, Safety and Hazard-2010, Mumbai India, December 14-16, 2010.
• J.Y. Kim, S.W. Cheon, J.S. Lee, Y.J. Lee, K.H. Cha, and Kee-Choon Kwon, “Software V&V Methods for a Safety Grade Programmable Logic Controller,” International Conference on Reliability, Safety and Hazard-2005, Mumbai India, December. 1-3, 2005.
• 10CFR 50 Appendix A,4/94, “General Design Criteria”
• ASME NQA-1-1997 “Quality Assurance Requirements for Nuclear Facility Applications”
• NUREG-0800, Mar. 2007, “Standard Review Plan (Ch. 7): Instrumentation and Controls.” IEC 62566, Jan.2012, “Nuclear power plants – Instrumentation and control important to safety–Development of HDL-programmed integrated circuits for systems performing category A functions »
• USNRC Reg. Guide 1.152, Rev. 02, 2006, “Criteria for Programmable Digital Computers System Software in Safety Related Systems of Nuclear Power Plants”
• USNRC Reg. Guide 1.172, Rev. 00, Jul. 1997, “Software Requirements Specifications for Digital Computer Software Used in Systems of Nuclear Power Plants”
• IEEE Std. 7-4.3.2-2003, “Standard Criteria for Digital Computers in Safety System of Nuclear Power Generating Stations”
• IEEE Std. 829-1998, “IEEE Standard for Software Test Documentation”
• IEEE Std. 1008-1987, “IEEE Standard for Software Unit Testing”
• IEEE Std. 1012-1998, “IEEE Standard for Software verification and validation”
• IEEE Std-1016, “IEEE Recommended Practice for Software Design Descriptions,” 1998.
• ASME/NQA-1, 1994/1995a, NQA-1-1994 w/addendum NQA-1a-1995 (Note: This edition is a consolidation of NQA-1 and NQA-2), “Quality Assurance Requirements for Nuclear Facility Applications,” American Society of Mechanical Engineers, New York, NY.
• ASME NQA-1-2008, “Quality Assurance Requirements for Nuclear Facility Applications,” American Society of Mechanical Engineers, New York, NY.
• ASME NQA-1a-2009 Addenda to ASME NQA-1-2008, “Quality Assurance Requirements for Nuclear Facility Applications,” American Society of Mechanical Engineers, New York, NY.