1.4.2 Forward Recovery
이전에 언급했듯이,
프로그램에서 error가 발생한 후에, 회복기술은 그 시스템을 error-free상태나 옳은 상태로 되돌릴 시도를 하게 된다.
Forward Recovery는 그 시스템이 작동을 계속 할 수 있도록 할 새로운 상태를 찾아 이를 시도한다. ( a new state from which the system can continue operation)
이 상태(new state)는 그 이전error-free상태보다 퇴화된(degrade) 것일 수도 있다.
Recovery를 위해 변화 하는 이 상태로의 대안으로써(?) Forward Recovery는 error 보상을 이용할 수 있다.
As an alternative to this state transitioning for recovery, forward recovery can utilize error compensation.
에러보상은 맞는 답이나 수용할만한 답을 선택하고 얻기 위한 redundancy를 사용하는 알고리즘에 기반한다.
Fig 1.4에서 Forward-Recovery 개념을 설명한다.
중복된 소프트웨어 프로세스들은 평행하게 실행된다는 것을 기억하라.
Redundancy는 fault detection과 handling unit이 에러보상을 수행하고,
선택하거나 얻은 옳거나 수용할 만한 정답으로부터 잠재적인 결과나 답의 집합을 제공한다. (킁….)
NVP기술은 FR개념에 기반하며, fault detection과 handling unit을 사용한다. ( adjudicator )
에러보상(Error Compensation)은 여러 방법으로 수행 되어진다.
만약 Self-checking 성분을 사용하면,
상태변화는 failed 성분에서 같은 임무를 실행하는 nonfailed성분으로 바뀌는 것에 의해 유도 되어진다.
에러보상은 에러가 있거나 없거나 항상 적용 될 것이다. 이것을 fault masking이라고 부르며, 많은 가능한 voting schemes 중 하나로 사용됨으로써 실행될 것이다. (may be implemented using one of available … )
장점
. FR은 이것이 필요로하는? 오버헤드 관점에서 보면 꽤 효율적이다. 이것은 BR의 시간 오버헤드가엄격한(/강제적인) 시간 제약을 초과할 수 있는 곳에서의 실시간 어플리케이션에서는 결정적(/혹독할?)일 수 있다.
. fault가 예상된 것이라면, (잠재적인 데이터의 손실과 같은것들.. ) redundancy와 FR은 유용하고 시기적절한 접근(timely approach)이 될 수 있다.
. 빗나간 기한(? Missed deadline)을 포함하는 faults는 FR을 사용하는것이 롤링백과 리커버링에의 추가적인 지연을 소개하는 것 보다 더 나은 회복을 보일 것이다.
. fault의 특성들이 잘 이해되었을 때, FR는 좀 더 효과적인 방법을 제공하게 될 것이다.
단점도 있다.
. FR은 application-specific이다. 즉, 이것은 반드시 각각의 상황이나 프로그램에 맞게 맞춰져야한다.
. FR은 시스템 상태로부터 예측가능한 에러만 제거할 수 있다.
. FR은 error에 대한 지식이 필요하다.
. FR은 만약 그 상태가 “specificationwise recoverability”를 넘어선 손상을 입으면, 회복을 거들 수 없다.
. FR은 정확히 fault 발생을 발견해내고, fault에 의한 잠재적인 손상을 예측하고, 실재 손상을 평가하는 능력에 좌우된다.
FR은 BR을 위한 시간이 없을 때 주로 사용된다.
FR을 사용하는 기술로는 NVP, NCP, DRB 기술을 포함한다.
'종합설계' 카테고리의 다른 글
7 Adjudicating the Results (0) | 2010.07.12 |
---|---|
SW Redundancy, Information or Data Redendancy, Temporal Redundancy (0) | 2010.07.12 |
1.5 Types of Redundancy for SW FT (0) | 2010.07.12 |
Backward Recovery (0) | 2010.07.12 |
Introduction (0) | 2010.07.12 |