SW Redundancy, Information or Data Redendancy, Temporal Redundancy

1.5.1 Software Redundancy

 

SW Redundancy는 (프로그램 redundancy, 모듈러-, 기능성-, 라고도 부름) fault tolerance를 지지하기 위해 사용하는 추가적인 프로그램, 모듈, 함수(기능), 객체들을 포함한다.

Sw redundancy의 개념은 hw fault tolerance approaches 에서 빌려온다. HW faults는 전형적으로 랜덤이다. (컴포넌트 aging과 환경적 영향 때문에?)

여분의 hw 요소들의 사용이 hw faults를 효과적으로 견딜 수 있는 반면에 sw faults의 tolerance는 반드시 다른 approaches를 사용해야한다.(employ) sw faults는 압도적으로(극도로) 명세서와 디자인에러 또는 구현실수(코딩실수)의 결과로 생긴다. Sw faults를 견디기 위해 이러한 디자인과 구현문제로인해 발생하는 fauilures는 탐지되어야만한다.

 

Sw 디자인과 구현 에러는 동일한 sw units의 간단한 복제에 의해서는 탐지 될 수 없다. 같은 실수가 그 sw의 각각의 카피안에 존재 할 것이기 때문에…

만약 같은 sw가 카피되고, failure가 그 sw의 복제품(사본)중 하나에서 발생했다면, 그 failure는 또한 그 다른 복제품들에서도 발생할 것이고, 그 문제를 탐지할 방법은 없을 것이다. ( 이는 같은 인풋이 각각의 카피에 제공되어졌다고 가정한다.)

 

복제 디자인과 구현 faults 문제의 해결방법은 sw 복제품들에 다양성(차이점)을 도입하는 것이다. 차이점이 사용되면, redundant sw 컴포넌트들은 variants, versions, alternates로 불린다. 차이점(다양성)은 많은 다른 면의 sw개발과정을 사용함으로써 소개(도입)될 수 있다. 이것의 자세한 내용은 다음 챕터에서 얘기 할것이다.

 

다양성(차이점)을 추가하는 기본적인 approach는 같은 명세서에서 시작하며, variants들을 독립적으로 개발하기 위해 다른 프로그래밍 팀을 갖는다. 이것은 기능적으로 동등한 소프트웨어 컴포넌트가 된다. 소프트웨어 컴포넌트에서 증가하는 다양성의 목표는 비슷함, 공통원인, 동시발생사건, 상호관련있는 failures에대한 가능성을 감소시키는 것이고, 그 컴포넌트들이(실패했을때/고장났을때) 입력공간 subset의 분리에 실패할(? The components fail on disjoint subsets of the input space.) 가능성은 증가시키는 것이다. 이러한 목표의 달성은 그 시스템의 신뢰성을 증가시키고 failures가 발생했을 때 그를 탐지하는 능력을 증가 시킨다.

 

다양한 소프트웨어 모듈의 사용은 판결(결정)하거나, 중재(조정)하거나, 그렇지 않으면 variants에의해 얻은 결과의 용인 정도를 결정 하기 위한 몇 가지 수단이 필요하다. 이러한 임무를 수행하는 컴포넌트를 adjudicator(혹은 decision mechanism)라고 부른다. adjudication을 수행할 많은 가능한 알고리즘이 있다. 이 adjudication 모듈이 복제되지 않고, 전형적으로 대안을 갖지 않기 때문에 errors 로부터 자유롭다는 것이 중요하다..? (it is very important that it be free from errors itself.) adjudicators는 7장에서 설명할거임..

 

Sw redundancy는 많은 형태로 구조화될 수 있다. Fig.1.5에서 보이듯이, 그 구조는 밑에놓인 하드웨어에 따라 수정할 수 있다.

(a) 한 개 하드웨어 컴포넌트에 모든 복사본

(b) 다중 하드웨어 컴포넌트 안에 복사본

(c) 분리된 하드웨어 컴포넌트와 그 위의? adjudicator

덧붙여 1.5d처럼  그 복제된 소프트웨어는 전체 프로그램에서부터 코드 몇줄까지의 범위가 될 수 있다.

Sw redundancy 구조를 만들기 위한 선택들은 이용가능한 리소스들과 특정 어플에 기반한다.

1.5.2 Information or Data Redundancy

 

이전에 언급했듯이, information (or data) redundancy는 때때로 sw redundancy로 (그 일부가 되기도한다.)그룹화 하기도 한다. 그러나 data diversity의 개념을 소개하기 위해서 별개로 다룰 것이다. Information or data redundancy는 데이터를 갖는(?) information의 사용과 fault tolerance를 돕기 위한 데이터의 추가적인 형태의 사용을 포함한다. information에의 데이터 추가는 전형적으로 hw fault tolerance를 위해 사용한다. 이런 타입의 information redundancy의 예제들은 error-detecting 과 error-correcting codes를 포함한다.

 

Diverse data(간단한 redundant 카피가 아님)는 sw faults 의 tolerating을 위해 사용될 수 있다.

DRA(data re-e-pression algorithm)는 모듈의 입력데이타의 다른 대표(different representationㄴ)를 생산한다. 이 변형된 데이터는 모듈(in data diverse software fault tolerance techniques.)의 복사본의 입력이다. Data diversity는 다음 챕터에서 좀더 자세히 다룬다. Diverse data를 이용한 기술은 챕터5에서 소개한다.

1.5.3 Temporal Redundancy

 

Temporal redundancy는 fault tolerance와 관련한 임무를 수행하기 위한 추가적인 시간의 사용을 포함한다. hw와 sw fault tolerance 두 가지 모두에 사용한다.

 

Temporal redundancy는 보통 초기와 실패한 실행에 관계한 같은 sw와 hw 리소스를 사용한 실행 반복으로 이루어진다.

(Temporal redundancy commonly comprises repeating an execution using the same software and hardware resources involved in the initial, failed execution. )

 

이는 하드웨어 backward recovery schemes을 상징함.

sw faults로부터 회복하기 위해 사용하는 Backward recovery schemes는 전형적으로 temporal and woftware redundancy의 조합을 사용한다.

적당한시기(timing)나 일시적인(transient) faults는 종종 hw, sw, os간의 복잡한 상호작용으로부터 발생한다. 이러한 failures는 복제하고, 진단하는 것이 어려운데.. Heisenbugs라고 부른다.

 

Redundant sw나 같은 sw의 단순 복제는 재시작 시간에 우선하여 fault를 야기시키는 일시적인 상황(환경)들이 보통 결여되기 때문에 transient faults를 극복할 수 있다.

(Simple replication of redundant software or of the same oftware can overcome transiet faults because prior to the reexecution time, the temporary circumstances causing the fault are then usually absent.)

 

만약 그 fault를 야기시키는 조건들이 재실행의 시간에도 살아남는다면, 그 재실행은 또 다시 failure의 결과를 얻을 것이다.

 

Temporal redundancy는 몇몇의 어플에 대해 큰 장점이 있다. – redundant hd나 sw가 필요없다.

간단하게 실패한 과정을 재실행하기 위한 추가적인 시간의 이용가능성만 필요로한다. Temporal redundancy는 많은 인간상호작용 프로그램과 같은 시간이 즉시 이용가능한 어플에서 사용되어질 수 있다.  그러나 hard real-time 제약의 어플은 temporal redundancy를 사용하기에 알맞지 않다..?

재실행을 위해 사용되는 추가적인 시간은 missed deadlines을 야기 시킬 것이다. Sw redundancy를 이용한 Forward recovery 기술은 좀 더 이러한 어플에 적절하다.