문서요약 - 원자력발전소 계측제어 관련 소프트웨어의 V&V by IAEA

제목: 원자력발전소 계측제어 관련 소프트웨어의 V&V(Verification and Validation of Software Related to Nuclear Power Plant Instrumentation and Control)

저자: 국제원자력기구(International Atomic Energy Agency: IAEA)

문서유형: 기술보고서(총 136페이지), 1999년

 

원자력발전소의 다양한 컴퓨터 기반 계측제어(Instrumentation and Control: I&C) 시스템의 중요도와 타입에 따라 어떻게 소프트웨어의 효과적인 검증(Verification) 및 확인(Validation)을 달성할 수 있는지 기술한 자료

---

1장 서론

• 산업 분야에서 핵심 기능(critical functions)을 수행하는데 있어 소프트웨어의 도입이 항상 우려를 낳음. 예, 다중 통제(fly by wire) 항공기와 관련된 논란
• 안전 요구사항(safety requirements)이 특히나 높은 원자력 산업도 예외가 아니어서 초기에는 컴퓨터 기술을 사용한 시스템이 발전소 운영에 필요하지만 안전 중요도가 낮은 기능(예, 데이터 수집, 정보 디스플레이, 데이터 로깅 등)에 제한적으로 사용됨
• 하지만 점차 원자력발전소의 안전과 직결되는 기능에도 컴퓨터 기반 시스템 도입이 증가하고 있는 추세이며 이미 아래와 같은 원자로 보호 시스템이 사용중임
  — 캐나다: Point Lepreau, 달링톤, Gentilly 2 CANDU 플랜트(원자로보호시스템)
  — 프랑스: 가압수형원자로(PWR) 플랜트의 1300 MW(e) 시리즈(SPIN1 원자로보호시스템)
  — 대한민국: 월송 1 CANDU 파워 유닛(원자로보호시스템)
  — 스웨덴: Forsmark 비등수형원자로(BWR) 플랜트(중성자속 측정과 보호)
  — 영국: Dungeness B AGR(단일채널온도트립시스템), Sizewell B PWR(원자로보호시스템)
  — 미국: BWR 플랜트(노심연산기), PWR 플랜트(Eagle 21 원자로보호시스템)

2장 안전 분류(Safety Classification)와 소프트웨어 타입(Types of Software)

안전 중요도에 따라 원자력발전소의 I&C 기능/시스템/장비를 아래와 같이 분류하고 여기 속하지 않는 나머지는 비분류(unclassified: U)로 할당됨. 카테고리 A 애플리케이션은 개발팀으로부터 독립적인 팀에 의해 V&V가 수행될 것을 요구함

• 카테고리 A: 원전 안전 달성 및 유지보수에 주된 역할을 하는 기능/시스템/장비
• 카테고리 B: 안전 측면에서 카테고리 A 시스템을 지원하는 역할의 기능/시스템/장비
• 카테고리 C: 원전 안전 달성 및 유지보수에 보조적/간접적 역할을 하는 기능/시스템/장비

개발 생명 주기를 논하고 여기에 여러 다른 V&V 수단을 연관시키기 위해 소프트웨어 컴포넌트의 타입을 아래와 같이 신규 소프트웨어(a)와 기존 소프트웨어(b, c, d)로 구분함

a.      신규 소프트웨어(New software): 특정한 애플리케이션을 위해 새롭게 생성된 소프트웨어

b.      기존 접근가능한 소프트웨어(Existing accessible software): 재사용되는 기존의 유사한 애플리케이션 소프트웨어. 소스 코드와 개발 중 생성된 모든 필수 문서가 가용함

c.      기존 사유 소프트웨어(Existing proprietary software): 현 애플리케이션 요구사항을 모두(또는 일부) 충족하는 상용 소프트웨어로 다만 가용 문서가 희소

d.      구성가능한 소프트웨어(Configurable software): 이미 존재하는 소프트웨어로 데이터 또는 애플리케이션에 특정한 입력 언어를 사용하여 특정 애플리케이션에 맞게 구성됨. 대표적인 예가 PLC(programmable logic controller) 애플리케이션

 

신규 소프트웨어는 현 원자력 표준에 완전 부합하게 개발할 수 있다는 장점이 있지만 기존 소프트웨어를 사용하는 것보다 대개 더 많은 비용과 V&V 활동을 요구함. 기존 소프트웨어 재사용은 소프트웨어가 즉시 가용하고 비용 소요가 적은 반면(필수적인 변경을 수행하거나 구성 데이터 준비 및 관련 V&V를 수행하는데 비용 발생) 기존 소프트웨어의 무결성 보장 수준이 문서의 상태와 가용성, 소프트웨어 공급자의 지원 정도에 의존하게 된다.

3장 소프트웨어 관련 활동(Activities)과 문서(Documents)

본 자료는 신규 소프트웨어를 위한 개발 생명 주기와 문서화를 아래와 같이 가정함. 카테고리 A 시스템에는 완전한 생명 주기가 적용되고, 카테고리 B와 C 시스템에는 단순화된 형태가 적용됨

[신규 소프트웨어의 생명 주기와 문서화]

• 시스템 요구사항 명세(System requirements specification): 전반적인 시스템 요구사항이 작성됨. 예, 결함 조건 하의 플랜트 동작 분석, 프로세스 분석, 사람-기계 인터페이스 분석, 성능 분석 등으로부터 나온 기능적 요구사항, 적용가능한 시스템 안전 원칙이나 소프트웨어 품질 보증 같은 기타 일반 요구사항
• 컴퓨터 시스템 명세(Computer system specification): ‘시스템 요구사항 명세’의 기능을 하드웨어와 소프트웨어로 나누어 각각의 요구사항이 개발됨. 소프트웨어 요구사항은 소프트웨어 설계를 위한 기반으로 소프트웨어 설계에 필수적인 모든 정보를 포함. 하드웨어 요구사항은 하드웨어 설계의 기반이며 하드웨어 설계에 필수적인 모든 정보를 포함. 통합 요구사항은 컴퓨터 시스템 내에서의 하드웨어와 소프트웨어 통합뿐만 아니라 플랜트에서 컴퓨터 시스템 통합의 기초가 됨(별도 문서로 작성되거나 또는 소프트웨어나 하드웨어 요구사항 문서에 포함될 수도 있음). 또한 컴퓨터 시스템 명세 개발과 병행하여 통합된 컴퓨터 시스템 시험 계획을 생성하는 것이 일반적임. 이 계획은 인수 시험의 목적, 입력 데이터, 성공 기준 등을 포함해야 한다.
• 소프트웨어 설계(Software design): 이 단계는 세 개 활동을 포함한다. 1) ‘소프트웨어 시스템 설계’는 소프트웨어 요구사항 명세를 분석하여 이를 기능 부품과 서브시스템으로 분할한다. 2) ‘상세 모듈 명세’는 기능 요구사항을 소프트웨어 모듈들로 나눈다(각 모듈이 대개 몇 백 라인의 코드이고 그 보다 크지 않음). 3) ‘모듈 설계’는 실제 알고리즘과 수학적 공식, 요구 기능을 수행하는데 사용되는 상세한 로직과 데이터 오퍼레이션의 정의를 포함한다(이 모듈 설계가 코딩의 기초가 됨).
• 코딩(Coding): 소프트웨어 설계가 프로그래밍 언어로 된 코드로 변환됨
• 컴퓨터 시스템 통합(Computer system integration): 이 단계는 세 개 활동으로 구성됨
  1) ‘소프트웨어 시험’은 모듈 상에, 모듈의 그룹 상에(서브시스템), 그리고 소프트웨어 요구사항 명세에 기술된 전체 소프트웨어 상에 수행될 수 있다.
  2) ‘하드웨어 통합’은 하드웨어-소프트웨어 통합 전에 반드시 완료되어야 하며, 하드웨어 요구사항 문서에 기술된 하드웨어 조립/통합 관련 모든 측면을 포함한다(예, 설치 사이트로 이전하기 전의 보드 조립, 케이블 연결 등).
  3) ‘하드웨어와 소프트웨어 통합’은 먼저 소프트웨어를 하드웨어 시스템으로 로딩하고, 하드웨어-소프트웨어 인터페이스 요구사항이 만족되는지 그리고 소프트웨어가 통합된 하드웨어-소프트웨어 환경에서 동작할 수 있는지 시험한다.
• 통합된 컴퓨터 시스템 시험(Integrated computer system tests): 시스템이 사이트로 이전되고 설치되기 전에 수행되어야 함. 이 시험 동안 시스템이 입력 신호의 정적 및 동적 시뮬레이션에 의해 실행됨(정상 오퍼레이션, 예상되는 운영상의 발생 및 사고 조건, 예상되는 컴퓨터 시스템 입력 상의 에러를 시뮬레이션 함). 각각의 기능이 대표성을 가진 시험에 의해 확인되어야 하며 성능 경계(한계)도 조사하는 것이 일반적이다.
• 확인과 시운전 시험(Validation and commissioning tests): 컴퓨터 시스템이 플랜트의 나머지에 정확하게 연결되었고 시스템의 동작(정상적 오퍼레이션, 예상되는 사고 조건, 예상 결함 등)이 정확한지 보기 위해 수행됨. 이 시험은 종종 장비의 오퍼레이션과 유지보수에 대한 검증을 포함하는 사이트 인수 시험(Site Acceptance Test)과 결합됨
• 시스템 인계(System handover): 프로젝트 단계라기 보다는 프로젝트 이정표. ‘확인과 시운전 시험’이 성공적으로 완료되면 시스템 책임이 개발자(시스템 공급자)로부터 사용자로 이전됨
• 운영, 유지보수, 변경(Operation, maintenance and modification): 운영중인 시스템에 주기적 시험, 수정(기능 개선, 에러 수정), 패러미터 변경, 진단 활동, 하드웨어 컴포넌트 교체 등이 일어남. 변경이 필요한 경우 이를 구현하기 위한 적절한 생명 주기가 요구됨(V&V를 포함한 주요 개발 단계들, 영향 분석과 회귀 시험도 수반됨)

4장 단계별 검증(Verification By Phase)

검증(VER)은 정의된 단계들 간의 정보의 변환(translation)을 체크하기 위해 소프트웨어 생명 주기 전반에 거쳐 수행됨. 즉, 한 단계로부터 나온 개발 산출물이 해당 단계의 입력 역할을 하는 정보를 정확히 반영하는지를 확실히 하기 위해서 생명 주기의 각 단계에서 VER이 수행됨

 

• 단계1: 시스템 요구사항 명세의 검증(Verification of system requirements specification): ‘시스템 요구사항 명세’가 상위 레벨의 개념 문서에 표현된 사용자 요구(needs)를 충족하는 시스템 요구사항을 나타내는지 체크. 요구사항 검토, 요구사항 명세에 적용된 방법론과 작업자의 과거 경험 검토, 유지보수 요구사항 검토가 수행됨
• 단계2: 컴퓨터 시스템 명세의 검증(Verification of computer system specification): 제안된 컴퓨터 시스템이 ‘시스템 요구사항 명세’에 표현된 시스템 요구사항들을 반영하는지 확인하고, 이 요구사항들을 해당 명세로 역추적함. 하드웨어, 소프트웨어, 인터페이스로 할당된 기능들이 명확하게 식별되고 적절하게 할당되었는지도 체크. 컴퓨터 시스템 명세 검토, 기능 할당 검토, 설계 방법론과 설계자의 과거 경험 검토, 유지보수 요구사항 검토, 소프트웨어 요구사항 검토, 하드웨어/사용자/타 소프트웨어와의 인터페이스 검토, 추적용이성 검토가 수행됨. 또한 ‘시스템 요구사항 명세’에 명세되고 ‘컴퓨터 시스템 요구사항 명세’에 상세 기술된 기능들이 적절한 시험의 대상이 되는지 확인하는 시스템 시험 계획의 VER도 수행됨(모든 요구사항이 시험가능한지 체크)
• 단계3: 소프트웨어 설계 명세의 검증(Verification of software design specification): ‘소프트웨어 설계 명세’가 소프트웨어 요구사항을 정확히 반영하고 시스템 문서에 표현된 사용자 요구를 충족하는지 체크. 소프트웨어 설계 명세 검토, 설계의 정형적 검증(Formal Verification), 성능 패러미터 평가, 할당된 기능 추적, 요구 데이터 평가(소프트웨어 요구사항과 관련한 데이터 요구사항을 평가하고 요구되는 데이터가 가용한지 체크), 결함 허용 분석, 설계가 요구 기능으로 추적가능한지 추적용이성 검토가 수행됨
• 단계4: 소프트웨어 코딩의 검증(Verification of software coding): 소프트웨어 설계에서 소프트웨어로 할당된 기능들을 소스 코드와 구성 데이터가 정확하게 나타내는지 체크. 소스 코드 모듈 분석, (하드웨어, 사용자, 타 모듈과의) 모듈 인터페이스 구현 검토, 구현 표준 및 관행의 준수 검토, 유지보수용이성 검토(미래 유지보수 활동에서 생길 수 있는 요구를 고려), 이 단계 동안 완료된 단위 시험이나 코드 분석 같은 시험 결과 검토, 특정 코딩 요소를 소프트웨어 설계로 추적하는 추적용이성 검토가 수행됨
• 단계5: 컴퓨터 시스템 통합의 검증(Verification of computer system integration): 시스템 설계에서 소프트웨어로 할당된 기능들이 통합된 소프트웨어 상에 수행된 시험에서 정확하게 시연되는지 체크. 통합이 두 단계(소스 코드 모듈 및 컴포넌트의 통합, 통합된 소프트웨어가 타겟 하드웨어와 결합)로 일어날 수 있음. 이 VER에서 시험 커버리지 검토, 모듈 통합 및 시험 검토, 소프트웨어 시험 결과 검토, 하드웨어-소프트웨어 통합 시험 결과 검토, 성능 평가, 추적용이성 검토가 수행됨
• 단계6: 통합된 컴퓨터 시스템 시험의 검증(Verification of integrated computer system tests): 통합된 컴퓨터 시스템의 실제 기능/성능에 대한 시험을 명세된 기능/성능과 비교하여 체크함. 또한 하드웨어/사용자/타 모듈과의 모듈 인터페이스가 완전하고, 정확하고, 일관적인지 체크. 통합된 하드웨어와 소프트웨어 모듈의 VER에서는 주요 성능 패러미터가 달성되었는지, 중요 기능(critical functions)이 요구대로 수행되는지, 하드웨어-소프트웨어 인터페이스 요구사항이 충족되었는지를 평가함
• 단계7: 확인과 시운전 시험의 검증(Verification of validation and commissioning tests): 통합된 컴퓨터 시스템이 정확하게 설치되었고 올바르게 준비되었는지 체크. 기능 시험 결과 검토, 시스템 타이밍과 성능 검토, 타 시스템으로의 인터페이스 검토, 이상/에러 수정 검토, 설치 검토, 사이트 조건 충족 여부 검토, 추적용이성 검토가 수행됨
• 단계8: 시스템 인계의 검증(Verification of system handover): 시스템의 운영 및 유지보수에 필요한 모든 문서가 인계에 앞서 제자리에 준비되어 있는지 체크. 해당 문서들의 체계적 검토가 수행됨
• 단계9: 운영, 유지보수, 변경의 검증(Verification of operation, maintenance and modification): 소프트웨어 변경이 없는 경우 VER이 주기적인 시험 결과 확인에 제한됨. 소프트웨어 변경이 있는 경우는 VER의 목적이 유지보수(소프트웨어 변경) 프로세스가 적절한지, 변경된 소프트웨어가 원래의 요구사항을 정확하게 구현하는지, 그리고 ‘이차적 에러’가 소프트웨어로 도입되지는 않았는지 체크하는데 있음. 즉, 변경 영향 분석 검토, 신규 소프트웨어 개발 단계에 따라 수행될 태스크 검토, 비회귀 분석(non-regression analysis)의 검토가 수행됨

5장 확인(Validation)

확인(VAL)은 시스템 통합 단계 후에 그리고 시스템이 서비스에 들어가기 전에 수행되며, 나중에 소프트웨어에 어떤 변경이 가해지면 시스템이 서비스로 돌아가기 전에 재확인(revalidation)이 요구됨. VAL의 목적은 하드웨어와 소프트웨어의 통합된 시스템이 ‘시스템 요구사항 명세’에 정의된 기능들을 정확하게 실행함을 실증하는(demonstrate) 것이다.

 

• 신규 소프트웨어: VAL 프로세스가 완전한 시스템의 요구사항에 기반함(즉, 소프트웨어를 포함하는 시스템 개발의 수단에 의존적이지 않음). VAL 시험 설계는 요구되는 입력 신호를 그 순서(sequences) 및 값(values)과 함께 정의하고 또한 예상 출력 신호를 그 순서(sequences), 값(values), 신호 수준 승인 기준과 함께 기술함. VAL 프로세스에서 시험 커버리지 검토, VAL 시험 결과 검토, 이상 기록 검토, VER 문서 검토, 운영 및 유지보수 기록 검토, 시스템 문서 검토, 추적용이성 기록/매트릭스 검토가 수행됨
• 기존 접근가능한 소프트웨어: 기존 소프트웨어의 VAL은 문서가 가용한 한해서 신규 소프트웨어의 VAL과 동일한 과정을 거친다. 변경이 요구되는 경우는 그에 따른 유지보수 절차를 사용해야 함(이 절차가 변경 영향을 받은 소프트웨어 부분에 VAL이 반복될 것을 요구함). 만일 소스 코드와 오브젝트 코드가 접근 가능하지 않다면 기능 명세서, 인터페이스 명세서, 설계 문서, 시험 파일 등이 분석된다.
• 기존 사유 소프트웨어: 대개 문서(사유 소프트웨어 개발 동안 생성된 VER 문서, 소스 코드, 소프트웨어 요구사항 등)가 VAL을 위해 가용하지 않음. 일정 기간의 운영 이력(릴리즈 이력, 인허가 받은 사람의 수와 사용 정도, 에러 및 수정 이력 등)을 평가하여 해당 소프트웨어의 성능과 제안된 시스템에 이 소프트웨어 사용의 적합성에 대한 자신감(확신)을 얻는다. 만약 확신이 생기지 않는 부분이 있다면 이 곳에 추가적인 VAL 시험이 정의되어야 한다.
• 구성가능한 소프트웨어: VAL이 두 부분(기본 소프트웨어의 VAL과 구성 데이터의 VAL)으로 나뉨. 기본 소프트웨어의 VAL은 위의 기존 소프트웨어에 서술된 접근 방법을 따르고, 소프트웨어의 구성된(configured) 측면은 신규 소프트웨어처럼 VAL되어야 한다.
• 데이터: 사용된 데이터 값의 VAL과 데이터베이스 관리 도구의 VAL의 두 부분으로 나뉨. 데이터 VAL은 운영 상태에 있는 시스템의 데이터 각 항목이 요구사항에 대해 정확함을 보장하려는 목적이며, 데이터 사전(data dictionary) 검토와 VAL 시험 결과 검토가 수행된다. 데이터 관리를 위해 자동 도구가 사용되는 경우 해당 도구가 철저하게 테스트되거나 또는 사용할 도구 선정 시에 신중한 평가가 수반되어야 한다.