[소프트웨어 공학] 12. Safety Engineering

Safety

• 안전(Safety)은 시스템이 정상적이든 비정상적이든 작동하면서 인간에게 상해나 사망을 초래하지 않고 시스템 환경에 손상을 주지 않는(the system's ability to operate without danger of causing human injury or death and witout damage to the system's environment) 시스템의 능력을 반영하는 속성입니다.
• 소프트웨어 안전(software safety)을 고려하는 것이 중요합니다. 왜냐하면, 대부분의 장치들이 소프트웨어 기반 제어 시스템을 통합하고 있기 때문입니다.

Software in safety-critical systems

• 시스템은 소프트웨어로 제어되어, 소프트웨어의 결정과 그에 따른 행동이 안전에 중요한 영향을 미칠 수 있습니다.
  • 따라서, 소프트웨어의 행동은 시스템의 전체 안전성과 직접적으로 관련이 있습니다.
• 소프트웨어는 시스템의 다른 안전 중요 구성 요소를 검사하고 모니터링하는 데 광범위하게 사용됩니다.
  • 예를 들어, 모든 항공기 엔진 구성 요소는 소프트웨어를 통해 초기 고장 징후를 모니터링합니다.
  • 이 소프트웨어는 안전 중요(safety-critical)한데, 실패할 경우 다른 구성 요소들이 고장나 사고를 초래할 수 있기 때문입니다.
    • 2018~19년 Boeing 737 MAX 사고는 MCAS의 실패로 인한 것입니다.

---

Safety and reliability

reliability를 만족한다고해서 safety가 만족되는 것이 아니다

• 안전(Safety)과 신뢰성(Reliability)은 관련이 있지만 서로 다릅니다.
  • 일반적으로, 신뢰성과 가용성(availability)은 시스템 안전을 위한 필요 조건이지만 충분 조건은 아닙니다.
  • 신뢰성은 주어진 명세와 서비스 제공에 대한 준수를 다룹니다.
•  안전은 시스템이 명세에 부합하는지 여부와 상관없이 손상을 초래하지 않도록 보장하는 것과 관련이 있습니다.
  • 시스템 신뢰성(System reliability)은 안전에 필수적이지만 충분하지는 않습니다.
  • 신뢰할 수 있는 시스템도 안전하지 않을 수 있습니다.

Unsafe reliable systems

• 시스템에 오랜 시간 동안 감지되지 않다가 드물게 나타나는 잠재적인 결함이 있을 수 있습니다.
• 명세 오류(Specification errors)
  • 시스템 명세가 잘못된 경우, 시스템이 명세대로 작동하지만 여전히 사고를 일으킬 수 있습니다.
  • ex) 보잉 항공기 : 잘못된 데이터를 센서가 보내주더라도 diversity와 redundancy를 통해서 처리했어야 함
• 하드웨어 고장이 잘못된 입력을 생성함
  • 명세에서 예측하기 어렵습니다.
• 상황에 민감한 명령(Context-sensitive commands)
  • 즉, 올바른 명령을 잘못된 시점에 발행하는 경우입니다.
  • 종종 운영자의 실수로 인해 발생합니다.

Safety critical systems

• 시스템 작동이 항상 안전해야 하는 시스템, 즉 시스템이 사람이나 시스템 환경에 손상을 주지 않아야 하는 시스템.
  • 예시
    • 항공기에서 제어 및 모니터링 시스템
    • 화학 제조의 공정 제어 시스템
    • 브레이크 및 엔진 관리 시스템과 같은 자동차 제어 시스템

---

Safety terminology

 

Accident (or mishap)	계획되지 않은 사건 또는 일련의 사건으로, 인명 사상, 재산 손상, 또는 환경 피해를 초래합니다. 인슐린 과다 복용이 예입니다.
Hazard	사고를 일으킬 가능성이 있는 잠재적인 조건입니다. 예를 들어, 혈당을 측정하는 센서의 고장은 하나의 위험 요소입니다.
Damage	사고로 인한 손실의 측정입니다. 손상은 중대 사고로 많은 사람들이 죽는 것부터 경미한 부상이나 재산 손상까지 다양합니다.

 

Hazard severity	특정 위험으로 인한 최악의 피해 평가입니다. 재난 수준에서 경미한 피해까지 다양할 수 있습니다.
Hazard probability	위험을 초래하는 사건이 발생할 확률입니다. 확률 값은 임의적일 수 있지만, 발생할 가능성은 '높음'에서 '불가능'까지 다양합니다.
Risk	시스템이 사고를 일으킬 확률의 측정입니다. 위험은 위험 확률, 위험 심각성, 사고로 이어질 확률(hazard probability, the harard severity, and the probability that hazard will lead to an accident)을 고려하여 평가됩니다.

 

Hazards

• 사고로 이어질 수 있는 상황이나 사건
  • 원자로 제어 시스템에서 막힌 밸브
  • 내비게이션 시스템에서 소프트웨어의 잘못된 계산
  • 약물 처방 시스템에서 알레르기 감지 실패
• 위험 요소(Hazards)는 필연적으로 사고로 이어지지 않습니다. 사고 예방 조치를 취할 수 있습니다.

Hazard-driven analysis

• 위험 요소 식별 (Hazard identification)
• 위험 요소 평가 (Hazard assessment)
• 위험 요소 분석 (Hazard analysis)
• 안전 요구 사항 명세 (Safety requirements specification)

Hazard identification

• 시스템을 위협할 수 있는 위험 요소를 식별합니다.
• 위험 요소 식별은 다양한 유형의 위험 요소를 기반으로 할 수 있습니다:
  • 물리적 위험 (Physical hazards)
  • 전기적 위험 (Electrical hazards)
  • 생물학적 위험 (Biological hazards)
  • 서비스 실패 위험 (Service failure hazards)
  • 기타 (Etc.)

Hazard assessment

• 위험 확률(probability)과 위험 심각도(severity)를 추정합니다.
• 이를 정확히 하는 것은 보통 불가능하므로 '희박함(unlikely)', '드뭄(rare)', '매우 높음(very high)' 등의 상대적인 값이 사용됩니다.
• 목표는 발생 가능성이 높거나 심각도가 높은 위험을 배제하는 것입니다.

Social acceptability of risk

• 위험의 수용 가능성은 인간, 사회, 정치적 고려에 의해 결정됩니다.
• 대부분의 사회에서, 수용 가능/불가능한 영역 간의 경계는 시간이 지나면서 위로 밀려납니다.
  • 즉, 사회는 위험을 수용하려는 의지가 줄어듭니다.
  • 예를 들어, 오염 청소 비용이 예방 비용보다 적을 수 있지만 이는 사회적으로 수용되지 않을 수 있습니다.
  • ex) 지구의 기후변화에 대한 사회의 대응을 생각해보자
• 위험 평가는 주관적입니다.
  • 위험은 '가능성 있음(probable)', '희박함(unlikely)' 등으로 식별됩니다.
  • 이는 평가를 수행하는 사람에 따라 다릅니다.

Hazard analysis

이런 방식이 있다 정도만 알아두자

• 특정 시스템의 위험 근본 원인을 발견하는 데 중점을 둡니다.
• 기술은 대부분 안전이 중요한 시스템에서 파생되었으며 다음과 같습니다:
  • 귀납적(Inductive, bottom-up) 기법
    • 제안된 시스템 고장으로 시작하여 그 고장으로 인한 위험을 평가합니다.
    • 예: 설계 실패 모드 및 영향 분석(Design Failure Modes and Effects Analysis, DFMEA)
  • 연역적(Deductive, top-down) 기법
    • 위험에서 시작하여 그 원인을 추론합니다.
    • 예: 고장수 분석(Fault Tree Analysis, FTA)

---

Risk Reduction

시험에 나오면, 아래중에서 주어진 상황에 납득할 수 있는 전략을 취하면 된다

• 위험 회피(Hazard avoidance)
  • 시스템이 일부 유형의 위험이 발생할 수 없도록 설계됩니다.
  • ex) hazard 확률이 낮고, severity가 높은 경우?
• 위험 감지 및 제거(Hazard detection and removal)
  • 시스템이 사고로 이어지기 전에 위험을 감지하고 제거하도록 설계됩니다.
• 피해 제한(Damage limitation)
  • 시스템에는 사고로 인한 피해를 최소화하는 보호 기능이 포함됩니다.

---

Formal verification

수학적으로 specifiction을 세부적으로 정의

• 수학적 명세가 작성될 때 형식적 기법(formal methods)을 사용할 수 있습니다.
• 개발 과정의 다양한 단계에서 사용할 수 있는 궁극적인 정적 검증 기법입니다:
  • 형식적 명세를 개발하고 일관성을 수학적으로 분석할 수 있습니다.
    • 이는 명세 오류 및 누락을 발견하는 데 도움이 됩니다.
  • 프로그램이 수학적 명세에 부합하는지 여부를 확인하는 형식적 논증을 개발할 수 있습니다.
    • 이는 프로그래밍 및 설계 오류를 발견하는 데 효과적입니다.
• 이는 매우 비용이 많이 들기 때문에 널리 사용되지는 않으며, 다른 방법으로도 유사한 수준의 신뢰성을 달성할 수 있습니다.

Model checking

• 시스템의 확장된 final state model을 생성하고, 모델 검사기(model checker)를 사용하여 오류를 검사합니다.
• 모델 검사기는 모델의 모든 가능한 경로를 탐색하고 사용자 지정 속성이 각 경로에 대해 유효한지 확인합니다.
• 모델 검사는 테스트하기 어려운 동시성 시스템 검증(verifying concurrent systems)에 특히 유용합니다.
• 모델 검사는 계산적으로 매우 비용이 많이 들지만, 이제는 소규모에서 중간 규모의 중요한 시스템 검증에 실용적으로 사용할 수 있습니다.

Static program analysis

• 정적 분석기(static analysers)는 소스 텍스트 처리를 위한 소프트웨어 도구입니다.
• 프로그램 텍스트를 구문 분석하고 잠재적으로 잘못된 조건을 발견하여 V&V 팀에 이를 알립니다.
• 정적 분석기는 검사의 보조 수단으로 매우 효과적이며, 검사를 대체하는 것은 아닙니다.

Levels of static analysis

• 특성 오류 검사(Characteristic error checking)
  • 정적 분석기는 특정 언어를 사용하는 프로그래머가 범하는 오류의 패턴을 코드에서 검사할 수 있습니다.
• 사용자 정의 오류 검사(User-defined error checking)
  • 프로그래밍 언어의 사용자가 오류 패턴을 정의하여 감지할 수 있는 오류 유형을 확장합니다. 이를 통해 프로그램에 적용할 특정 규칙을 허용합니다.
• 단언 검사(Assertion checking)
  • 개발자는 프로그램 내에 반드시 충족해야 하는 형식적 단언을 포함합니다. 정적 분석기는 코드를 상징적으로 실행하고 잠재적인 문제를 강조합니다.

Use of static analysis

• C와 같이 약한 타입을 가진 언어가 사용되는 경우, 컴파일러에 의해 감지되지 않는 많은 오류가 있으므로 특히 유용합니다.
• 보안 검사(security checking)에 특히 유용합니다.
  • 정적 분석기는 버퍼 오버플로우 또는 확인되지 않은 입력과 같은 취약성을 발견할 수 있습니다.
• 정적 분석은 이제 많은 안전 및 보안 중요한 시스템 개발에 일상적으로 사용됩니다.
  • 예: Clang (C/C++), FindBugs (Java), ESLint (JavaScript), Pylint (Python), Coverity, SonarQube(한국에서 많이 씀) 등
  • 보통 ~Lint(er)가 static analysis나 program inspection을 해준다.