문서요약 - 소프트웨어 기반 안전우선 시스템의 라이센싱 프로세스 by Haapanen

제목: 소프트웨어 기반 안전우선 시스템의 라이센싱 프로세스(Licensing process for safety-critical software-based systems)

저자: Pentti Haapanen 외 2인, 핀란드

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

 

원자력 발전소의 소프트웨어 기반 오토메이션 시스템/장비의 라이센싱 프로세스에 대하여 기술한 자료(라이센스 신청자와 허가 당국 모두에게 참고 모델이 될 수 있음)

---

1장 서론

• 오늘날 원자력발전소에 프로그램가능한 컴퓨터 기반 운영 오토메이션 시스템(또는 안전 오토메이션 시스템)의 도입이 증가하는 추세
• 핀란드 원자력 산업 현황을 보면 안전 관련 제어 및 보호 기능(예, 원자로 보호 시스템)이 상용적으로 가용한 산업용 오토메이션 시스템 플랫폼 상에 구현되고 있으며, 기존 발전소의 오래된 아날로그 오토메이션 시스템도 점차 프로그램가능한 컴퓨터 기반 디지털 시스템으로 업그레이드(또는 교체)되고 있음

 

아래 그림은 전형적인 (단순화된) 프로그램가능한 안전 오토메이션 시스템의 구성을 보여준다.

• 플랜트 프로세스 상태가 감지기(sensors)에 의해 즉각 관측되고, 감지기의 신호를 보호 로직(protection logic)이 정해진 시간 간격에 주기적으로 읽어 들임
• 보호 로직은 프로세스 상태의 안전성을 평가하고 필요한 경우 프로세스 장비 구동기(actuators)를 통해 보호 조치(protective actions)을 시작시킴. 안전이 중요한 시스템이 요구하는 높은 신뢰성을 달성하기 위해 시스템이 대개 여러 중복 채널을 가짐
• 1세대 프로그램가능한 보호 시스템에서는 대개 보호 로직 만이 소프트웨어 기반 기술을 사용하여 실현되고 감지기와 구동기는 전통적인 아날로그 기술을 사용함. 하지만 감지기와 구동기에 점차 더 많은 소프트웨어 기반 특징이 포함되는 추세

[프로그램가능한 안전 오토메이션 시스템의 기본 구성]

2장 라이센싱 요구사항(Licensing Requirements)

• 라이센싱 요구사항은 그것이 달성되었을 때 원자력발전소 오퍼레이션의 안전에 대한 충분한 보장(assurance)을 제공하는 결정론적(deterministic) 그리고 확률론적(probabilistic) 규칙들의 집합으로 구성됨. 아래 그림은 이런 요구사항이 형성되는 기본 원리를 표현
• 법과 규제에 의해 설정된 기본 안전 목표(safety goals)와 플랜트의 안전 분석(safety analyses)을 함께 고려하여 특정한 안전 기능/시스템/장비(FSE)의 안전 중요도(safety importance)를 결정. 이 안전 중요도는 안전 분류(safety classification)로 표현되며, 이로부터 FSE를 위한 결정론적 그리고 확률론적 승인 기준(acceptance criteria)이 결정됨. 이렇게 도출된 승인 기준은 시스템 개발 프로세스와 평가 프로세스(라이센싱 프로세스)를 위한 필수적인 절차와 그 응용 수준을 정의함
• 당연히 안전 클래스가 더 높은 FSE가 신뢰성에 대한 더 높은 수준의 확신(confidence)을 요구함. 라이센싱 프로세스의 초기 단계에 허가 당국과 허가소지자(licensee) 간에 시스템의 의도된 안전 클래스와 해당 시스템이 달성해야 할 신뢰성 요구사항 및 보장 수준에 대한 합의를 하는 것이 중요

[라이센싱 요구사항 구축]

3장 실패 체계와 봉쇄(Failure Mechanisms and Containment)

아래 그림은 기술 시스템의 기본적인 실패 체계(failure mechanisms)를 나타낸다.

• 시스템의 오작동(malfunction)은 시스템에 있는 결함(faults)의 결과임
• 결함은 장비 생산 시의 부적절함(deficiencies)으로 인해 시스템에 내재해 있거나(예, 시스템 설계의 에러, 제조 프로세스의 결점) 또는 무작위적인 하드웨어 컴포넌트 실패(hardware component failures)로 인해 야기될 수 있다.
• 하드웨어 컴포넌트 실패는 노화/마모(ageing and wear) 또는 외적 영향(external influences)에 의해 생길 수 있다.
• 안전 시스템의 오작동은 의도한 운용 환경에서의 특정 요구사항을 장비가 충족시키는 것을 내재된 결함 또는 컴포넌트 실패가 막을 때 발생한다.

[시스템의 실패 체계]

아래 그림은 시스템 실패가 소프트웨어에 의해 야기되는 상황을 표현. 어떤 (알려지지 않은) 내부 시스템 상태에서 어떤 (알려지지 않은) 입력 신호 조합에 의해서 내재된 소프트웨어 결함이 활성화되고 이것이 시스템 오작동을 야기함. 소프트웨어 결함에 의해 야기된 오작동은 대개 아래 중 하나에 속한다.

• 명세되지 않은 방식으로 소프트웨어가 동작함
• 소프트웨어가 어떤 기능을 올바르게는 실행하지만 잘못된 시간에 실행함
• 어떤 기능이 그 요구된 시간에 실행되지 않음
• 기능의 결과가 정확하지 않음

[시스템 실패로 표현된 소프트웨어 결함]

4장 라이센싱 프로세스의 구조(Structure of the Licensing Process)

• 라이센싱 프로세스의 기본 목적은 허가를 받아야 할 오토메이션 시스템에 대한 안전 주장(safety claims)을 지원하는 증거(evidence)를 수집하고, 이 증거에 기반하여 시스템의 달성된 신뢰성(또는 안전성)을 평가하는 것이다.
• 시스템이 점차 복잡해짐에 따라 무작위적 컴포넌트 실패와 설계 관련 실패의 리스크가 커지고 라이센싱 프로세스도 어려워짐. 설계에 중복(redundancy)을 도입하는 것으로 임의적 하드웨어 실패를 완화할 수 있지만 설계 관련 실패(예, 소프트웨어 결함)는 이 방식으로 완화시킬 수 없음. 따라서 설계 결함이 복잡한 시스템의 안전성에 영향을 미치는 지배적 요인(dominant factor)이 되기도 함
• 안전 시스템 라이센싱 프로세스의 주요 주체는 전력 공급 업체 같은 허가소지자(licensee)와 원자력 안전 당국이다. 허가소지자는 당국에 수용가능한 증거(acceptability evidence)를 제시하고, 당국은 제공된 증거의 충분성과 정확성을 평가하여 신청된 허가의 승인 여부를 결정한다.

 

아래는 한 프로젝트에서 제안된 안전 논증 모델로, 각 안전 케이스(safety case)가 아래 요소(element)들로 구성된다.

• 시스템 또는 서브시스템의 속성(properties)에 대한 주장(claims)
• 안전 논증(safety argument)의 기초로 사용되는 증거(evidence)
• 증거(evidence)를 주장(claims)으로 연결시키는 논증(arguments)
• 논증의 단계(steps)를 위한 논리적 기초를 제공하는 추론 규칙(inference rules)

[안전 논증 모델]

5장 프로그램가능한(Programmable) 오토메이션 시스템 소프트웨어

• 안전 표준이 주로 참조하는 생명주기 모델은 소프트웨어 개발 프로세스가 폭포수 모델(the waterfall model)을 따른다고 가정함
• 하지만 현대식 프로그램가능한 오토메이션 시스템은 종종 다른 모델에 따라 개발됨(예, 소프트웨어 프로세스가 포괄적이고 재사용가능한 소프트웨어 컴포넌트에 기반하고, 그래픽 에디터와 자동화된 코드 생성 도구의 지원을 받음)
• 이런 종류의 개발 프로세스는 IEC 60880이나 IEC 601508에 의해 제안된 프로세스 모델에 직접 매핑되지 않으므로, 이 표준들이 프로그램가능한 오토메이션 시스템에 적용될 때는 주의가 필요함

 

프로그램가능한 오토메이션 시스템은 사실상 두 가지 타입의 소프트웨어 개발의 결과이다.

• 우선 애플리케이션 소프트웨어를 동작시키는데 필요한 소프트웨어 플랫폼인 ‘기본 소프트웨어(basic software)’ 개발에서 시스템 소프트웨어, 프로그램가능한 오토메이션 시스템을 위한 모든 재사용가능한 컴포넌트(예, 기능 블록), 소프트웨어 도구 등이 개발됨. 이 개발은 대개 맨 처음부터(from scratch) 시작되며 폭포수 모델을 적용한다.
• 두 번째는 ‘애플리케이션 소프트웨어(application software)’ 개발로 통상적으로 아래 표의 우측 열에 있는 단계들을 포함한다. 이는 특정 정형적 명세(formal specification) 기반의 프로세스로 소프트웨어 구현(코딩), 단위 테스팅, 통합 테스팅을 포함하지 않아 보통의 소프트웨어 프로세스와 다르다.

폭포수 모델	프로그램가능한 오토메이션 애플리케이션 모델
소프트웨어 요구사항	사용자가 대개 P&I 다이어그램, 다양한 기술서, 장비 목록을 포함하는 기능 요구사항들의 집합을 개발한다.
요구사항 명세	정형적인 그래픽 애플리케이션 명세
설계
구현	자동화된 코드 생성
통합과 테스팅	단위 테스팅과 통합 테스팅 없음. 애플리케이션이 통상적으로 시뮬레이션된 환경에서 테스트 됨
컴퓨터 시스템 확인(Validation)	최종 하드웨어에서 애플리케이션 확인(Application validation)

[프로그램가능한 오토메이션 시스템의 통상적인 개발 프로세스 개요]

6장 승인 증거(Acceptance Evidence)

• 안전 관련 시스템의 수용성(acceptability)을 증명하는 증거가 1) 개발 프로세스의 품질을 다룬 증거와 2) 제품의 품질을 다룬 증거의 두 개 카테고리로 나뉠 수 있음
• 프로세스 품질 증거는 표준과 지침, 방법론과 도구(명세, 생산, 테스팅, 분석, QA/QC), 개발자의 기술(skills) 등에 관심을 갖고, 제품의 품질 증거는 테스트, 분석, 운용 경험(operational experience)에 기반함
• 아래 그림은 영국의 원자력시설검사국(Nuclear Installations Inspectorate: NII)이 소프트웨어 기반 오토메이션 시스템 안전 케이스를 위하여 사용하는 안전성 증명 방법(the safety demonstration approach)을 나타냄. 안전성 증명이 한편으로는 시스템 제조의 우수성(즉, 개발 프로세스의 품질)에 대한 증거에 기반하고 있고 다른 한편으로는 최종 제품의 품질에 대한 독립적인 확신/자신감 구축에 기반하고 있음. 이 두 카테고리의 수용 증거(acceptance evidence)의 주요 원천지도 아래 그림에 표현되어 있음

[안전 증명 프로세스 - 영국]

정적 분석(Static analyses)

• 정적 분석은 소프트웨어의 속성(properties)을 실행 없이 분석하는 방법들의 집합으로 구성됨. 정적 분석에 사용되는 방법은 비공식 체크(informal checks)부터 정교한 소프트웨어 메트릭 도구까지 다양함
• 여러 정적 분석이 소프트웨어 설계 프로세스 동안 설계팀과 품질팀에 의해 수행되지만, 정적 분석이 라이센싱 프로세스에서 독립적인 평가자(independent assessors)의 중요한 도구가 되기도 한다.
• 허가를 받아야 할 애플리케이션이 산업용 오토메이션 시스템 플랫폼에서 구현되었다면 가용한 소프트웨어 문서가 대개 정적 분석에 적합하지 않음(단지 그래픽 시스템 흐름 차트와 오브젝트 코드의 메모리 덤프만이 가용함). 이 경우 평가자는 오브젝트 코드를 중간 언어(예, 어셈블러 같은 의사 코드)로 재컴파일 하는 도구를 사용한다. 아래 그림은 정적 분석 도구의 원리를 표현
• 많은 상용 정적 분석 도구 셋이 가용함. 예, MALPAS(The Malvern Program Analysis Suite by TA Group Ltd.), CATS(Code Analysis Tool Set by TÜV Nord e.V.). 특히 MALPAS 분석 스위트는 다음과 같은 분석 부분들을 포함한다.
  - 통제 흐름 분석(control flow analysis): 입구와 출구, 루프 조건적 노드, 닿지 않는 코드(unreachable code)를 포함한 모든 주요 특징을 식별하면서 프로그램 구조를 분석
  - 데이터 사용 분석(data use analysis): 입력이 출력으로 사용되거나 초기화가 누락되는 것 같은 에러를 밝히면서 데이터를 뚜렷한 용법 클래스(distinct usage classes)로 분리
  - 정보 흐름 분석(information flow analysis): 모든 출력의 데이터 의존성과 의사결정 의존성을 식별. 모든 가능한 경로에서 원치 않거나 예상치 못한 인터액션을 명확히 밝힘
  - 의미론 분석(semantic analysis): 분석 대상 하에 있는 모든 가능한 경로에서 입력과 출력 간의 정확한 관계(relationship)를 주어서 코드의 완전한 기능성을 밝힘
  - 준수성 분석(compliance analysis): 프로그램 기능을 그 명세와 비교하여 검증하는 도구(어떤 차이가 있으면 이를 보고함)

[정적 분석 도구 셋의 원리]

FMEA(Failure Mode and Effects Analysis) 테이블

발생한 실패를 요약하는데 좋은 방법은 FMEA 테이블을 사용하는 것이다. 이 테이블은 실패에 대한 가변적인 서술과 실패 모드의 식별 그리고 실패 원인 정보도 제공함. 프로그램가능한 시스템의 경우 가장 흥미로운 실패는 소프트웨어 에러에 의해 야기됨(이것이 아래 예와 같이 FMEA 테이블에 기술되어야 함). 여기서 소프트웨어 결함의 영향은 애플리케이션의 성격에 크게 의존적임을 유의할 것. 즉, 잘못된 출력의 영향이 플랜트 제어에 사용되는 시스템이 무엇인지에 따라 달라지므로 실패 영향의 일반적인 리스트를 개발하기가 어렵다.

 [실패 원인의 분류]

소프트웨어 에러의 타입	실패의 통상적인 영향
1. 시스템 소프트웨어 결함	대개 시스템이 그대로 멈추거나 또는 시작(start-up) 단계에서 잘못된 값이 설정된다.
2. 시스템의 모듈을 프로그래밍하는데 있어서 소프트웨어 결함
2.1 비교, 분기, 루프에 있어서 구조적 결함	잘못된 출력, 잘못된 모드에서 동작, 또는 프로그램이 그대로 멈춰 버림
2.2 프로그램 문장(statements) 또는 식(formulas)에 있어서 결함	잘못된 출력, 시스템 에러
2.3 변수의 타입에 있어서 결함	잘못된 출력, 시스템 에러
2.4 데이터를 읽거나 쓰는데 있어서 결함	잘못된 출력, 순서가 잘못된 데이터
2.5 비트 레벨 상의 계산 결함	잘못된 출력, 시스템 에러
3. 모듈을 논리적 수준에서 하나의 프로그램으로 통합하는데 있어서 결함
3.1 잘못된 모듈의 사용	잘못된 출력, 프로그램가능한 시스템에 의해 통제되는 시스템의 잘못된 통제
3.2 잘못된 실행 순서	잘못된 출력
3.3. 입력 또는 출력의 잘못된 연결	잘못된 출력, 프로그램가능한 시스템에 의해 통제되는 시스템의 잘못된 통제
3.4 패러미터 또는 상수의 잘못된 연결	모듈이 잘못된 방식으로 사용됨, 출력이 틀림
4. 소프트웨어 사용 동안에 야기된 실패
4.1 용법 실패(Usage failures)	잘못된 위치에서 수동/자동 선정, 출력이 틀림
4.2 자원(메모리, 버퍼 등)을 다루는데 있어서의 문제	시스템이 꼼짝 않고 멈춰 버림

7장 증거 결합하기(Combining the Evidence)

• 오토메이션 시스템의 신뢰성 평가와 그 안전 수준 수용에 대한 결정을 내리기 위해서 여러 다른 종류의 정성적 그리고 정량적 증거에 가중치를 주고(weighting) 결합하는(combination)이 작업이 요구됨
• 이것은 효율적인 도구가 필요한 어려운 작업이다. 특히 Bayesian Belief Networks(BBN)가 이 불확실성 하의 의사결정 지원 문제의 해결책으로 큰 관심을 받고 있음
• BBN은 변수들간의 확률 관계를 표현한 그래픽 네트워크이며, 다른 이름으로 Belief Networks, Causal Probabilistic Networks, Causal Nets, Graphical Probability Networks, Probabilistic Cause-Effect Models, Probabilistic Influence Diagrams 등이 있음

[BBN의 예]

9장 요약

라이센싱 프로세스는 허가를 받을 시스템에 대한 안전 주장(safety claims)을 지원하는 증거를 수집하고 이 증거에 기반하여 시스템의 신뢰성/안전성을 평가하는 목표를 가진 상호연결된 활동들의 집합으로 정의된다. 이 프로세스의 기본 구조는 아래 그림과 같다. 

[라이센싱 프로세스의 기본 구조]