Introduction

1. Introduction

 

The cost and consequences of these systems failing can range from mildly annoying to catastrophic, with serious injury occurring or lives lost, systems (both human-made and natural) destroyed, security breached, businesses failed, or opportunities lost.

이러한 시스템 오류의 비용과 결과는 약간 성가신 정도 일수도 있고, (심각한 손상 발생이나 손실을 남기거나 시스템이 파괴되거나 보안이 깨지거나, 사업이 실패하거나 기회를 잃는 등) 최악일 수도 있다.

 

As software assumes more of the responsibility for providing functionality in these systems, it becomes more complex and more significant to the overall system performance and dependability.

Sw가 이러한 시스템에서 기능을 제공하는 책임을 맡은 이상 전체적인 시스템 퍼포먼스와 신뢰성이 더 복잡하고 더 중요해져야 한다.

 

Increasing the dependability of software presents some unique challenges when compared to traditional hardware systems. Hardware faults are primarily physical faults, which can be characterized and predicted over time. Software does not physically wear out, burn out, or otherwise physically deteriorate with time (although it can be argued that the value of specific instances of data and software may degrade over time). Software has only logical faults, which are difficult to visualize, classify, detect, and correct. Software faults may be traced to incorrect requirements (where the software matches the requirements, but the behavior specified in the requirements is not appropriate) or to the implementation (software design and coding) not satisfying the requirements. Changes in operational usage or incorrect modifications may introduce new faults. To protect against these faults, we cannot simply add redundancy, as is typically done for hardware faults, because doing so will simply duplicate the problem. So, to provide protection against these faults, we turn to software fault tolerance.

소프트웨어의 증가하는 신뢰성은 전통적 하드웨어 시스템과 비교하면 몇몇의 독특한(희귀한?) 과제(난제)들을 보여준다. 하드웨어 폴트는 주로 물질적(하드웨어적인) 결함들이고 이는 특성화시킬수 있고, 시간이 지남에 따라 예상(예언)할 수 있다. 소프트웨어는 물질적으로 닳지도 않고, 타지도않고, 시간에 따라 물질적으로 품질이 떨어지지도 않는다. (특정 데이터의 인스턴스와 소프트웨어가 가치가 시간이 지남에 따라 degrade 된다고 할 수도 있지만…) 소프트웨어는 오직 논리적인 결함만 있으며, 이를 구체화(시각화)시키거나 분류하거나 탐지하거나 정정하는 것은 어렵다. 소프트웨어 결함은 부정확한 요건(그 소프트웨어가 그 요건(자격)에는 맞으나 특정 요건상에서의 그 행동은 적절하지 않음)이나 요건을 만족하지 않는 구현(소프트웨어 디자인과 코딩)을 추적 할 것이다. 조작상 사용법이나 부정확한 수정에서의 변화 – 조작 사용법이나 부정확한 수정으로 인한 변화-는 새로운 결함을 가져 올 것이다. 이러한 결함들에 대해 보호하기 위해 우리는 -하드웨어에서 하던 것처럼- 간단하게 redundancy를 추가할 수 없다. 왜냐하면 그렇게 하는 것은 그 문제를 간단히 두 배로 만들 것이기 때문이다. 그래서 이러한 결함에 대한 보호를 제공하기 위해 우리는 software fault tolerance에 의지 해야 한다.

 

 

1.1 a few definitions

 

A fault is the identified or hypothesized cause of an error, sometimes called a “bug.” It can be viewed as simply the “consequence of a failure of some other system (including the developer) that has delivered or is now delivering a service to the given system”. An active fault is one that produces an error.

Fault는 때로는 bug로 불리며, 에러를 야기시키는 것이라고 식별하거나 가정한다. Fault는 간단하게 “주어진 시스템에 서비스를 전달했거나 지금 전달하고 있는 중인 몇몇의 다른 시스템의 failure에 의한 결과” 로 간주 할 수도 있다.  실행상태의(?) fault는 에러를 만들어낸다.

 

An error is part of the system state that is liable to lead to a failure. It can be unrecognized as an error or detected. An error may propagate, that is, produce other errors. Faults are known to be present when errors are detected.

Error는 failure를 이끌기 쉬운 시스템상태의 한 부분이다. Error는 error로 인식 되지 않거나 탐지되지 않을 수 있다. error는 다른 error를 생산하면서 번식할 것이다. Fault는 error가 탐지 되었을 때 나타난다고 알려져 있다.

 

A failure occurs when the service delivered by the system deviates from the specified service, otherwise termed an incorrect result. This implies that the expected service is described, typically by a specification or set of requirements.

Failure는 그 시스템에 의해 전달된 서비스가 특정한 서비스를 벗어날 때 발생하며, 부정확한 결과라고 부른다. 이것은 그 요구한 서비스가 전형적으로 명세서나 요건의 집합에 의해 기술되어진다는 것을 의미한다.

  

Failure-fault-error-failure-fault-…

 

Software fault tolerance : using a variety of software methods, faults(whose origins are related to software) are detected and recovery is accomplished.

 

 

1.3 Organization and intended use

신뢰할만한 소프트웨어를 달성하기 위해 다양한 기술적 수단들에 대해 간략히 알아보자.

 

The concepts related to dependable software can be classified in the form of a tree as shown in fig.1.2, a dependability concept classification. The tree illustrates the impairments, means, and attributes of dependability. The impairments, or those things that stand in the way of dependability, are faults, errors, and failures. The attributes of dependability enable the properties of dependability and provide a way to assess achievement of those properties. Additional attributes can be derived from the properties of those listed. For example, the dependable system attribute security is derived from the properties of integrity, availability, and confidentiality.

 

신뢰할만한 소프트웨어에 관련한 개념은 fig1.2에 보여진 트리의 형태로 분류해 볼 수 있다. 그 트리는 신뢰성에대한 손상(impairment), 수단(mean), 속성(attribute)을 설명하고 있다. 손상들이나 신뢰성에대한 그것들은 faults, errors, 그리고 failures 이다. (뭐?) 신뢰성의 속성(attribute)은 신뢰성의 특성(properties)을 가능하게(작동시키게)하고, 그런 특성(properties)에의 달성에대한 가치평가의 방법을 제공한다. 추가적인 속성(attributes)은 그 리스트의 특성에서 벗어날 수도 있다. 예를 들어보면, 신뢰할만한 시스템 속성 보안이 무결, 유효, 기밀의 특성에서 벗어나는 것이다.

 

 

The means to achieve dependability falls into two major groups :

(1) those that are employed during the software construction process (fault avoidance and fault tolerance), and

(2) those that contribute to validation of the software after it is developed (fault removal and fault forecasting).

신뢰성을 달성하기 위한 수단은 두 개의 주요 그룹으로 분류한다.

(1) 소프트웨어 건설과정 동안 사용되는 것들 (폴트회피, 폴트허용?내성?용인?)

(2) 개발 이후 그 소프트웨어의 허가 시 기여하는 것들 ( 폴트제거, 폴트예측)

 

Briefly, the techniques are :

Fault avoidance or prevention : to avoid or prevent fault introduction and occurrence;

Fault removal : to detect the existence of faults and eliminate them;

Fault/failure forecasting : to estimate the presence of faults and the occurrence and consequences of failures;

Fault tolerance : to provide service complying with the specification in spite of faults.

 

간략히 그 기술들은…

Fault avoidance or prevention : 폴트 도입과 발생을 회피하거나 예방하기 위함

Fault removal : 폴트의 존재를 탐지하고 제거하기 위함

Fault/failure forecasting : failures의 결과와 발생과 faults의 영향력을 측정하기 위함

Fault tolerance : fault임에도 불구하고 명세서에 따라 서비스를 제공하기 위함

 

 

 

1.3.1 Fault Avoidance or Prevention

 

Fault avoidance or prevention techniques are dependability enhancing techniques employed during software development to reduce the number of faults introduced during construction.  These avoidance, or prevention, techniques may address, for example, system requirements and specifications, software design methods, reusability, or formal methods.

Fault avoidance techniques contribute to system dependability through rigorous specification of system requirements, use of structured design and programming methods, use of formal methods with mathematically tractable languages and tools, and software reusability.

Fault avoidance나 prevention 기술은 건설 중에 생산되는 폴트를 줄이기 위한 소프트웨어 개발동안 사용하는 신뢰성 향상 기술이다.

회피 기술들은 시스템 요건, 구조디자인과 프로그래밍 방법의 사용, 수학적으로 다루기 쉬운 언어와 도구를 이용한 형식적 방법의 사용, 그리고 소프트웨어 재사용성에 대한 정확한 설계명세서를 통해 시스템 신뢰성에 공헌한다.

 

1.3.1.1 System Requirements specification

 

The specification of system requirements is currently an imperfect process at best. A system failure may occur due to logic errors incorporated into the requirements. This results in software that is written to match the requirements, but the behavior specified in the requirements is not the expected or desired system behavior. This type of fault often occurs because software  requirements specification lies at the intersection between software engineering and system engineering, and these two disciplines suffer from a lack of communication.

 

그 시스템 요건의 명세서는 현재 기껏해야 불완전한 과정일 뿐이다. 시스템 failure는 그 요건에 속한 논리적 error 때문에 발생할 것이다. 이것은 요구에 맞게 쓰여진 소프트웨어가 되나, 그 요건에서 명시된 그 행동은 기대하거나 바라던 시스템의 행동이 아니다. 이런 류의 fault가 종종 발 생하는 이유는 소프트웨어 요구 명세서가 소프트웨어 엔지니어링과 시스템 엔지니어링 사이의 교차로에 놓여있기 때문이고, 이 두 부문은 소통의 부족으로 고통받고 있다 -_-