크리티컬 시스템 명세 및 개발

1. 소프트웨어 신뢰도 명세(Software reliability specification)

1) 개요
① 하드웨어 신뢰도(Hardware reliability)
□ 하드웨어 컴포넌트가 오동작할 확률은 얼마인가?
□ 컴포넌트를 수리하는데 걸리는 시간은 얼마인가?

② 소프트웨어 신뢰도(Software reliability)
□ 소프트웨어 컴포넌트가 얼마나 자주 잘못된 결과를 산출해 내는가?
□ 소프트웨어는 닳지 않는다. 따라서 고장난 소프트웨어는 잘못된 결과를 만들어내고도 계속적으로 동작할 수 있다.

③ 오퍼레이터 신뢰도(Operator reliability)
□  오퍼레이터가 얼마나 자주 실수를 범하는가?

위의 3가지 고려사항은 서로 연관되어 있기 때문에 신뢰도는 개별 컴포넌트가 아닌 시스템 전체 수준에서 고려해야 합니다. 하드웨어 오류로 인해 소프트웨어에 잘못된 입력 신호를 발생시킬 수 있고, 그 결과 시스템은 오퍼레이터의 예상대로 동작하지 않을 수 있습니다.

오퍼레이터는 이로 인해 혼란을 겪고, 실수를 범할 확률이 높아지고, 이는 또다시 새로운 시스템 오동작을 야기시킬 수 있으므로 더욱 치명적인 결과를 만들어낼 수도 있기 때문입니다.

2) 시스템 신뢰도 공학(System reliability engineering)
시스템 신뢰도 공학(System reliability engineering)은 시스템 신뢰도 평가와 관련한 시스템 공학의 한 분야로 시스템의 컴포넌트들이 고장날 확률을 다룹니다. 정확하게 어떠한 것을 다루는지 예를 통해 살펴봅시다.

① 만약 2개의 컴포넌트 A, B의 조합으로 동작하는 시스템 S의 고장확률을 P,라 하면 P, = PA + PB 이므로, 사용하는 컴포넌트의 개수가 많을수록 시스템이 고장날 확률이 높아진다.

② 만약 동일 컴포넌트들을 중복시켜 놓으면, 고장 확률은 모든 컴포넌트들이 동시에 고장날 확률과 동일하므로, n개의 동일 컴포넌트들로 구성된 경우 Ps = PAn과 같고, 따라서 신뢰도가 증가한다.

3) 신뢰도와 가용성 척도
소프트웨어의 가용성 척도는 하드웨어 컴포넌트의 신뢰도로부터 유래되었습니다. 가용성 척도 로는 다음 4가지가 있으며, 어떤 척도를 사용해야 하는지는 시스템의 종류와 응용 도메인에 따라 다릅니다.

① POFOD
□  [POFOD(Probability of failure on demand)]
□  요청에 대한 오동작 확률
□  서비스가 불규칙적으로 요청되고, 비교적 그 간격이 긴 시스템에 적합함.
□  서비스가 제공되지 않을 경우 심각한 결과를 초래하는 시스템의 측도로 사용
□  POFOD가 0.001이라는 것은 1000번의 요구(request)에 대해서 1회의 비율로 시스템이 오동작을 일으킨다는 뜻이므로, POFOD가 낮을수록 신뢰도가 높음.
□  불규칙한 서비스 요청 또는 요청 간격이 길 때(예 : 발전소의 긴급 운전정지)

② ROCOF
□  [ROCOF(Rate of failure occurrence)]
□  오동작 발생의 빈도
□  규칙적인 서비스 요청이 들어오는 시스템의 척도로 적합 (예 : 예금 인출이나 호텔 예약 시스템)
□  서비스가 정확히 제공되어야 하는 시스템의 척도로 사용
□  ROCOF가 2/100이라는 것은 100이라는 동작 시간 단위를 기준으로 볼 때 2번의 오류가 발생한다는 뜻이므로, ROCOF가 낮을수록 신뢰도가 높음.

③ MTTF
□  [MTTF(Mean time to failure)]
□  오동작간 평균 시간
□  트랜잭션 소요 시간이 오래 걸리는 시스템의 척도로 적합 (예 : 워드 프로세서나 CAD 시스템)
□  사람들이 계속적으로 오랫동안 사용하는 시스템의 척도로 사용
□  오동작간의 평균시간은 트랜잭션에 걸리는 평균 시간보다 길어야 함.
□  MTTF가 500이라는 것은 평균적으로 500시간 단위마다 1회의 오류가 발생한다는 뜻이므로, MTTF가 클수록 신뢰도가 높으며, 절대 오동작하지 않는 시스템이 존재 한다면 MTTF가 무한대가 됨.

④ AVAIL
□  [AVAIL(Availability)]
□  가용성
□  논스톱(non-stop) 서비스를 제공해야 하는 시스템의 척도로 사용 (예 : 전화 교환 시스템이나 철도 신호장치)
□  Availability가 0.998이라는 것은 1000시간 단위 동안 998에 해당하는 만큼 시스템이 사용 가능하다는 것이므로, Availability가 높을수록 신뢰도가 높다고 볼 수 있음(단 1보 다 커질 수는 없음.). 만약 항상 사용 가능하다는 것이 보장된다면 Availability는 1이 됨.

비기능적(Non-functional) 신뢰도 명세의 경우는 요구되는 시스템의 신뢰도가 정량적으로 (quantitatively) 표현되어야 합니다.

4) 오동작의 분류
시스템의 신뢰도에 영향을 주는 것은 소프트웨어 결함이 아니고 고장(failure)입니다. 고장의 성격이나 결과는 시스템마다 다른데, 구체적으로 어떻게 다른지 알아보도록 하겠습니다.

▪ Transient - 특정 입력에 대해서만 발생
▪ Permanent - 모든 입력에 대해서 발생
▪ Recoverable - 오퍼레이터의 도움없이 회복 가능
▪ Unrecoverable - 오동작으로부터 회복을 위해 오퍼레이터의 도움이 필요
▪ Non-corrupting - 오동작이 발생하였으나 시스템 상태나 데이터를 붕괴시키지 않음.
▪ Corrupting - 오동작으로 인해 시스템 상태나 데이터가 붕괴

<ATM 시스템에서 신뢰도 명세의 예>

Failure class	Example	Reliability metric
Permanent, non-corrupting	The system fails to operation with any card which is input. Software must be restarted to correct failure	ROCOF 1 occurrence/ 1000 days
Transient, non-corrupting	The magnetic stripe data cannot be read on an undamaged card which is input.	ROCOF 1 in 1000 transactions
Transient, corrupting	A pattern of transactions across the network causes database corruption.	Unquantifiable! Should never happen in the lifetime of the system

2. 안전성 명세(Safety specification)

1) 안전성 생명 주기(Safety life cycle)

<IEC 61508 안전성 생명 주기(The IEC 61508 safety life cycle)>

▪ Concept and Scope definition - 시스템의 범위를 정함.
▪ Hazard and risk analysis - 예상되는 해저드와 리스크 평가
▪ Safety req. derivation, Safety req. allocation - 안전성 요구사항을 명세하고 서브 시스템별로 할당
▪ Planning: Validation O & M Installation, Safety-related Systems development,
▪ External risk reduction falicities - 계획, 안전성-크리티컬 시스템의 설계와 구현, 관련 외부 시스템의 개발
▪ Safety validation, Installation and commissioning - 안전성 확인, 설치
▪ Operation and maintenance - 많은 안전 문제가 유지보수 과정에서 생기므로 유지보수성을 고려한 설계가 중요
▪ System decommissioning - 폐기시에도 안전성을 고려해야 함.(위험 물질의 처리)

2) 해저드와 리스크 분석(Hazard and risk analysis)
해저드와 리스크 분석은 시스템과 동작 환경을 분석하여, 해당 환경에서의 잠재적인 해저드 (hazard)나 해저드의 원인이 되는 요소들 또는 관련 리스크(risk)를 찾는 과정입니다.

① Hazard identification
□  해저드 확인 발생
□  가능한 잠재적 해저드를 찾음.
□  시스템 환경에 좌우됨.

② Risk analysis and Hazard classification
□  리스크 분석 및 해저드 분류
□  해저드는 분리되어 처리됨.
□  몇몇 해저드(예 : 번개가 치면서 지진이 일어나는 경우)는 발생할 확률이 거의 없기 때문에 제외시키기도 함.

③ Hazard decomposition
□  해저드 분해
□  각각의 해저드는 잠재적 원인을 발견하기 위해 독립적으로 분해/분석됨.
□  결함-나무 분석(Fault-tree analysis)과 같은 기술이 사용되기도 함.

④ Risk reduction assessment
□  리스크 감소 평가
□  확인된 리스크를 줄이거나 제거하는데 필요한 방법들이 제안됨.
□  이러한 정보는 보다 세밀한 안전성 요구사항을 만들기 위해 사용되기도 함.


3) 결함-나무 분석(Fault-tree analysis)
▪ 확인된 결함으로부터 시작해서 거꾸로 결함의 원인을 찾는 해저드 분석의 방법
▪ 예비 분석에서부터 세부 소프트웨어 확인에 이르기까지 모든 해저드 분석 단계에서 사용될 수 있음.
▪ 기본적으로는 Top-down 방식이지만, 오동작의 원인으로부터 시작해서 해저드를 유도하는 Bottom-up 방식과 함께 사용될 수 있음.

<인슐린 전달 시스템에 대한 결함 나무의 예(Fault tree for insulin delivery system)>

 

4) 리스크 평가(Risk assessment)
리스크 평가는 모든 해저드가 확인된 후에 진행하며, 이때 각 해저드의 심각성, 발생 확률 및 사고로 이어질 확률 등을 고려합니다. 해저드 별로 용인(acceptability) 수준을 판단하는데, 용인 수준의 단계는 다음과 같습니다.

▪ 용인 수준의 단계
① Intolerable - 해당 해저드는 절대로 발생하지 않도록 설계되어야 한다.
만약 이에 속하는 해저드가 발생하게 되면 사고로 이어지게 된다.

② As low as reasonably practical (ALARP)
- 비용을 포함한 실제적인 문제 때문에 허용하는 해저드이지만 가능한 최소화 시키는 것이 좋다.

③ Acceptable - 가능한 해저드의 발생확률을 낮추되, 이것 때문에 비용 증가나 다른 비기능적 시스템 속성에 변화가 생기지 않도록 해야 한다.


▪ 리스크의 수준(Levels of risk)

□  영역간 경계는 시스템의 종류에 따라 위 또는 아래로 이동
□  좌우 너비는 설계 비용을 반영

5) 리스크 감소(Risk reduction)
잠재적 해저드와 원인이 확인되면, 이러한 것들이 사고로 이어지지 않도록 시스템이 명세되어야 합니다.

Hazard avoidance	해저드가 발생하지 않도록 시스템을 설계한다.
Hazard detection and removal	해저드가 발견되면 사고로 이어지기 전에 무력화 시키도록 설계한다.
Damage limitation	사고로 인한 피해가 최소화되도록 설계한다.

▪ 금지 행위 명세 (Specifying forbidden behavior)
□  보안이나 안정성 같은 경우의 명세는 특정 행위에 대한 금지 형식인 경우가 많다.
□  예 : 시스템은 권한을 가지지 않은 사용자에 의해 수정되어서는 안된다.(보안) 시스템은 동시에 3개 이상의 경고 신호를 보내서는 안된다.(안전성)  


▪ 인슐린 펌프에서 안전성 요구사항의 예

SR1	The system shall not deliver a single dose of insulin that is greater than a specified maximum dose for a system user.
SR2	The system shall not deliver a daily cumulative dose of insulin that is greater than a specified maximum for a system user.
SR3	The system shall include a hardware diagnostic facility that shall be executed at last 4 times per hour.
SR4	The system shall include an exception handler for all of the exceptions that are identified in Table 3.
SR5	The audible alarm shall be sounded when any hardware anomaly is discovered and a diagnostic message as defined in Table 4 should be displayed.

3. 보안 명세(Security specification)

1) 보안 명세를 위한 단계
아래 그림에서 볼 수 있듯이 보안 명세를 위한 단계는 은행이나 군사용의 기존 시스템에서 사용되었던 방법을 컴퓨터 기반 시스템에 적용한 것입니다.

<보안 명세(Security specification)>

□  Asset identification - 데이터와 프로그램과 같은 재산(asset)과 요구되는 보호 수준을 확인한다.

(예 : 암호 파일은 매우 중요함.)
□  Threat analysis and risk assessment - 잠재적인 보안 위협을 확인하고 각각의 위협과 관련된 리스크를 판단한다.
□  Technology analysis - 각각의 데이터와 프로그램에 대해 관련된 위협들의 리스트를 배정한다.
□  Threat assignment - 확인된 위협에 대해 가능한 보안 기술 및 적용 가능 여부를 파악한다.
□  Security req.specification - 보안 요구사항이 명세된다.


4. 결함 최소화(Fault minimization)
좋은 소프트웨어 프로세스는 fault-free software의 개발이라는 목적을 가지고 있어야 합니다. Fault-free software란 정확히 명세에 일치하도록 동작하는 소프트웨어를 말합니다.

1) 개요
다음 그림에서 볼 수 있듯이 에러의 수가 줄어들수록 에러를 제거하는데 드는 비용은 기하급 수적으로 증가합니다. 즉 결함이 적은 신뢰성 있는 소프트웨어의 개발은 많은 테스팅 비용으 로 인해 비용이 커지므로, 시스템에 따라서는 결함 발견보다 고장의 대가가 더 받아들일 만할 수도 있습니다.

2) Fault-free software 개발 요구사항
Fault-free software 개발 요구사항으로는 위의 6가지가 있으며, 결함 회피 방법으로는 프로그래밍 기술(결함 최소화)과 정적/동적 확인(validation)기술(결함 발견)이 있습니다.

① 구현될 시스템을 정의하는 정확한(정형적인) 시스템 명세가 있어야 한다.
② 소프트웨어를 개발하는 조직이 소프트웨어 품질에 대한 문화를 가져야 한다.
즉, 소프트웨어 프로세스는 품질에 의해 움직이며 개발자는 버그없는 프로그램을 작성하는데 목적을 두어야 한다.
③ 소프트웨어 설계상의 정보은닉(Information hiding)이나 캡슐화(encapsulation)는 필수적이다.
④ Strongly typed programming language를 사용해야 한다.
⑤ 에러를 유발하기 쉬운 방법으로 프로그래밍을 해서는 안된다.
⑥ 믿을만하고 반복적으로 적용 가능한 개발 프로세스가 있어야 한다.

Dijkstra는 goto 문장이 에러를 유발하기 쉬운 프로그래밍 구조를 만든다는 것을 지적했습니다. goto는 상태변화를 지역화시키기 어렵게 만들기 때문에 구조화 프로그래밍(Structured programming)이 등장하게 되었습니다.

▪ 구조화 프로그래밍(Structured programming) 의 특징
① 1970년대 처음으로 발견되었음.
② goto를 사용하지 않음.
③ 제어문장으로는 while loop와 if만을 사용함.
④ Top-down 설계 방식
⑤ 프로그램을 더 쉽게 읽고 이해할 수 있음


3) 에러를 유발하기 쉬운 구성(Error-prone constructs)
① Floating-point numbers - 본질적으로 정확히 표현되지 않기 때문에 잘못된 비교연산을 일으킬 수 있다.
② Pointers - 잘못된 메모리 영역을 참조하는 것은 데이터를 붕괴시킬 수도 있을 뿐 아니라, 별칭(aliasing)은 프로그램을 이해하고 변경하기 어렵게 만든다.
③ Dynamic memory allocation(동적 메모리 할당) - 실행시간에 메모리를 할당하는 것은 메모리 오버플로우(memory overflow)를 야기할 수 있다.
④ Parallelism - 병행 처리가 확인하기 힘든 상호작용에 의한 시간차 때문에 에러가 발생 할 수도 있다.
⑤ Recursion - 메모리 오버플로우를 일으키기 쉽다.
⑥ Interrupts - 인터럽트는 중요한 연산을 중지시킬 수 있기 때문에 프로그램을 이해하기 어렵게 만든다. goto의 사용과 비슷하다.
⑦ Inheritance - 코드가 지역화되지 않기 때문에 코드가 바뀌는 경우 예상치 못한 결과가 생길 수 있고, 이해하기 어렵다는 문제점을 가진다.
⑧ Aliasing - 프로그램상의 동일 개체에 대해 다른 이름이 사용되기 때문에 이러한 것들을 모두 고려해주어야 하므로 프로그래밍시 혼란을 야기시킬 수 있다.
 

5. 결함 내성(Fault tolerance)

1) 결함 내성의 4가지 관점
결함 내성의 4가지 관점으로는 결함 발견, 손실 평가, 결함 회복, 결함 수정이 있습니다. 그러면, 각각에 대해 좀 더 자세히 살펴보도록 합시다.

① 결함 발견(Fault detection)
▪ 시스템은 고장으로 이어질 수 있는 잘못된 시스템 상태를 감지할 수 있어야 한다.
▪ 종류
- Preventative fault detection : 상태 변화가 수행되기 전에 결함 감지 메커니즘이 동작 한다. 그러므로, 오류상태가 발견되면 상태 변화가 이루어지지 않는다.
- Retrospective fault detection : 시스템의 상태 변화가 수행된 후에 결함 감지 메커니즘 이 동작한다. 그러므로, 오류가 발견되면, 예외가 발생하게 되고 이를 복구하기 위한 메커니즘이 실행된다. (Exception handling)

② 손실 평가(Damage assessment)
▪ 상태 변화를 피하기 힘들 때나 개별적으로는 정확하나 전체적 시스템 상태에 문제가 있는 경우 결함에 의해 영향을 받는 시스템 상태가 어느 부분인지를 감지해야 한다. 결함의 복구가 아니다.  

▪ 평가 기술(Technique)
- 데이터 전송에서 결함 평가를 위해 체크섬(Checksum)이 사용된다.
- 연결된 데이터 구조의 확인을 위해 여분의 포인터가 사용될 수 있다.
- 감시 타이머(Watch-dog timer) 가 종료하지 않은 프로세스를 감시하는데 사용될 수 있다.

③ 결함 회복(Fault recovery)
▪ 잘못된 시스템 상태를 안전한 상태로 복구시켜야 한다.
▪ 종류
- Forward recovery : 붕괴된 시스템 상태를 수정하는데 사용된다. 상태 수정을 위해 특정 도메인 지식이 필요하다.
- Backward recovery : 안전한 상태로 시스템의 상태를 복귀시키는데 사용된다.
안전 상태의 정보가 유지되면서 붕괴된 시스템 상태를 덮어쓰게 된다.

④ 결함 수정(Fault repair)
시스템이 결함의 재발을 방지하기 위해 수정되어야 한다.

2) 결함 내성을 위한 구현 기술
결함 내성을 위해서 구현하는 기술로는 다음 2가지가 있습니다. 각각에 대해 자세히 살펴보도록 합시다.

[기술1] Defensive programming
시스템의 코드에 에러가 있다고 가정하여 상태를 검사하는 코드를 삽입한다. 즉, 만약 에러가 감지될 때 이를 처리할 수 있는 코드를 미리 삽입해둔다. 하드웨어와 소프트웨어간의 상호작용에서 발생하는 오류를 처리하기 어렵다.

[기술2] Fault-tolerant architecture
결함내성을 지원하는 하드웨어 또는 소프트웨어 아키텍쳐를 사용한다.

 

3) 결함내성 아키텍쳐(Fault-tolerant architectures)

① 하드웨어 결함 내성(Hardware fault tolerance)
□  TMR(Triple-modular redundancy)
□  동일한 입력을 받는 3개의 동일한 컴포넌트를 중복 사용하여 결과를 비교한다.
□  만약 하나의 결과가 다르다면, 그것은 무시되고 그 컴포넌트는 오류가 발생한 것으로 간주한다.
□  설계상의 오류라기 보다는 컴포넌트 자체의 오류를 허용하기 위한 것이며, 동시에 컴포넌트들이 오류 발생을 일으킬 확률은 아주 낮다.
□  결과 비교기(output comparator)는 비교적 단순한 하드웨어 유닛이다.
□  다수결 투표를 하는 것과 같은 원리
□  결과 비교기(output comparator)는 결함 관리자(Fault manager)에 연결된다.

② 소프트웨어 결함 내성(Hardware fault tolerance)
□  TMR은 다음을 기본적으로 가정하고 있다.
- 하드웨어 컴포넌트는 공통적인 설계 결함을 가지지 않는다.
- 컴포넌트는 임의적으로 오동작하며, 모든 컴포넌트가 동시에 오동작할 확률은 아주 낮다.

□  하지만, 소프트웨어의 경우는 이러한 2가지 가정이 성립하지 않는다.
- 하드웨어의 경우는 동일한 설계의 컴포넌트라 할지라도 서로 다른 결과를 낼 수 있지만, 소프트웨어의 경우는 설계가 동일한 경우는 동일한 결과를 내게 되므로, TMR의 경우와 같은 비교는 의미가 없다. 그러므로, 설계의 다양성이 요구된다.

<Triple-modular reduendancy to cope with hardware failure>

□  동일한 명세에 대해 서로 다른 팀들에 의해 다양한 구현이 이루어진다. 각각의 버전들 은 동시에 입력을 받아 계산을 하고 결과를 모아서 비교하게 된다. (사용 사례 - Airbus 320)

□  각 팀들이 동일한 실수를 범할 확률은 낮지만, 경우에 따라 거의 동일한 알고리즘이 만들어지기도 한다. (실제로 서로 다른 팀이라고 해도 동일한 문제에 대해 유사한 방법 으로 접근하는 경우가 많다.)  

N-version programming과 Recovery blocks 방법은 설계와 구현의 다양성(diversity),
즉 같은 명세에 대한 다른 버전의 소프트웨어는 같은 결함을 가지지 않을 거라는 가정에 기초하고 있습니다.

□  동일한 명세에 대해 명시적으로 다른 버전을 만들어서 순차적으로 실행된다.
□  인수 검사(Acceptance test)가 실제로 전송될 결과를 선택하는데 사용된다.


[요약정리]
■ POFOD, ROCOF, MTTF, AVAIL 등의 다양한 신뢰도 측도가 있다.
■  해저드 분석은 안전성 명세 프로세스에서 필수적인 작업으로, 시스템의 안전성을 저해할만한 조건들을 찾는 것이다. 이를 통해 해저드가 발생하지 않거나, 혹 발생하더라도 사고로 이어지 지 않도록 시스템 요구사항을 만들게 된다.
■  리스크 분석은 시스템에서 제거되어야 할 해저드를 찾고 그 심각성에 따라 리스크를 분류하 는 것이다.
■  잘 정의되어서 반복적으로 적용가능한 프로세스는 시스템의 결함을 최소화 시키는데 필요하 다.
■  결함 허용에는 Failure detection, damage assessment, fault recovery와 fault repair의 4가지 방식이 있다.
■  Defensive programming은 프로그램상에서 오류를 확인하고 그것을 복구하는 프로그래밍 기술이다. 즉, 시스템 오동작을 일으키기 전에 오류가 감지된다.
■  N-version programming과 recovery block은 프로그램 유닛을 중복시킴으로써 결함 허용을 지원하는 아키텍쳐이다.

[참고자료]
Software Reliability Engineering by John D. Musa

The first practical guide to Software Reliability Engineering (SRE), this book puts
the efficiency-enhancing benefits of SRE within reach of all software developers and testers. Organized for quick learning and rapid application, this book leads you through the entire SRE process with the Fone Follower case study, adapted from a Bell Laboratories product.