소프트웨어 안전 분석

시스템 안전성 분석의 주요 목적은 기능적 요구사항과 연관된 안전성을 시스템이나 장비, 설비, 이들간의 인터페이스 설계에 안전 요구사항을 추가/고려하는 것이다.

MIL-HDBK-338B (Electronic Reliability Design Handbook)에는 안전성이 자세하게 언급되어 있는데 다음과 같은 지침을 제공하고 있다.

• 시스템 위험을 식별하기 위한 안전성 프로그램을 구현하고, 개발할 수 있는 가이드
• 위험 요소를 제거함으로써 사고를 막거나 허용할 수 있는 수준의 활동을 관리하여 관련된 위험을 축소 시킬 수 있는 설계 요구사항과 관리 및 통제에 대한 가이드

Terminologies of Safety

• Fail Safe
  A design feature that either ensures that the system remains safe, or, in the event of a failure, will revert to a state that will not cause a mishap. Fail Safe features are as important during maintenance as they are during operation. For example, aircraft have a device that prevents inadvertent operation of the landing gear while the aircraft is on the ground.
• Hazard
  A condition that is prerequisite to a mishap. Preventing injury or death to personnel begins with identifying potential hazards.
  
  
• Hazard Probability
  The aggregate probability of occurrence of the individual events that create a specific hazard.
  
  
• Hazard Material
  Any material that, due to its chemical, physical or biographical nature, causes safety, public health, or environmental concerns.
  
  
• Mishap
  An unplanned event or series of events that result in death, injury, occupational illness, or damage to or loss of equipment or property or damage to the environment. An accident.
  
  
• Risk
  An expression of the possibility of a mishap in terms of hazard severity and hazard probability.
  
  
• Risk Assessment
  A comprehensive evaluation of the risk and its associated impact.
  
  
• Safety
  Freedom from those conditions that can cause death, injury, occupational illness, or damage to or loss of equipment or property or damage to the environment.
  
  
• Safety Critical
  A term applied to a condition, event, operation, process or item of whose proper recognition, control performance, or tolerance is essential to safe operation or use; e.g. safety, critical function, safety critical path or safety critical component.

Hazard severity와 hazard probability는 (HRI) (Hazard Risk Index) matrix를 구성하는데 사용될 수 있다. HRI matrix의 각 셀은 사용자 우선순위를 기반으로 테일러링 하여 사용될 수 있다.

Hazard Severity (예)

Hazard Probability (예)

Hazard Risk Index (HRI) Matrix (예)

Note)
Red: Unacceptable Risk - Upper Management Resolution or Risk Acceptance
Yellow: Marginal Risk - Design to Eliminate
Green: Minimum Risk - Design to Minimize

Risk Acceptance Matrix (RAM) (예)

Note)

Red: Unacceptable - Upper Management Resolution or  Risk Acceptance

Yellow: Undesirable - Design to Eliminate

Green: Allowable - Design to Minimize

White: Acceptable

다양한 형태의 안전성 분석은 방대하고 복잡한 제품을 대상으로 한다. 시스템 안전성 분석에는 일반적으로 다음과 같은 기법들이 존재한다.

• System Hazard Analysis (SHA)
  SHA는 잠재적으로 사람이 발생 시킬 수 있는 오류를 포함하여 전체 시스템 설계의 주요한 안전성 문제 영역을 문서화한다. 이는 운영과 유지보수 동안, 운영자에게 위험을 발생 시킬 수 있는 설계 영역을 식별할 수 있어야 한다.
• Subsystem Hazard Analysis (SSHA)
  SSHA는 전체 시스템 및 하부 시스템 설계의 주요 안전성 문제 영역을 문서화한다. SSHA 또한 잠재적으로 사람이 발생 시킬 수 있는 모든 오류를 포함하고 있으며, 운영과 유지보수 동안, 운영자에게 위험을 발생 시킬 수 있는 설계 영역을 식별할 수 있어야 한다.
  
  
• Operating and Support Hazard Analysis (O&SHA)
  O&SHA는 개발하고자 하는 시스템의 전 단계에서 사용될 수 있는 대안을 권고하고 연관된 위험 요소를 식별한다. 운영 및 유지보수 기간에 존재할 수 있는 모든 잠재 위험 요소를 식별할 수 있어야 한다.
  
  
• Occupational Health Hazard Assessment (OHHA)
  OOHA는 인간의 건강을 해칠 수 있는 위험 요소를 식별하고 허용할 수 있는 수준의 관리 활동과 연관된 위험을 줄일 수 있는 보호 대책을 제안 할 수 있다. 운영 및 유지 보수 기간에 존재할 수 있는 모든 잠재적인 건강 위험 요소를 식별해야만 한다.

제품 설계 또는 운영, 유지보수 기간에 위험 요소를 분석하는 것 뿐 아니라, 테스트와 데모 기간 동안 사람에게 노출 될 수 있는 잠재 위험 요소를 식별하는 것 또한 중요하다. 이런 위험 요소의 평가는 T&E (Test and Evaluation) 안전성의 일부라 할 수 있다. T&E 안전성을 평가하는 목적은 안전에 대한 모든 요구사항을 테스트하기 위해 필요한 대응이나 분석 보고서 및 기타 안전 데이터를 보급하고 개발하기 위한 테스트와 평가 활동을 하는 동안 안전성을 고려하고 안전에 대한 책임을 갖도록 보장하는 것이다.

또한 시스템 뿐 아니라 하부 시스템 설계의 변경까지도 이후의 안전성 분석이 수행되어야 한다. 모든 공학적 변경, 즉 변경 제안 및 편차가 심한 변경이나 변경 포기에 대한 요청이 안전에 어떤 영향을 미치는지 평가해야만 한다.

Software Safety Analysis

소프트웨어 안전성 분석은 운영 환경에서 소프트웨어 프로그램이 사람이나 장비를 대상으로 위험 조건이 되는 원인이 발생하지 않도록 평가하는 것이다. 소프트웨어는 그 자체로 고장을 갖지 않을 수도 있으나, 위험 조건을 만들 수 있는 메커니즘을 포함하고 있다. 그러므로 소프트웨어 안전성 분석 결과는 그러한 메커니즘 내에서 심각한 안전성 결함을 제거하거나 완화함으로써 소프트웨어의 신뢰성에 긍정적인 영향을 갖는다.

다음은 소프트웨어 안전성 문제의 근본 원인을 나타낸다.

• Specification Error
  소프트웨어 명세서는 소프트웨어가 무엇을 수행하는지 (어떻게 수행되는지)에 대한 정의를 포함하고 있다. 만약 소프트웨어/하드웨어 인터페이스에 대한 계획이 없다면 예측하지 못한 안전성 문제가 발생할 수 있다.
  
  
• Design Error
  정확하지 않은 알고리즘으로 인한 오류나 테스팅 부족, 부정확한 결함 허용 범위 및 부정확한 인터페이스는 안전성 문제를 일으킬 수 있다.
  
  
• Coding Error
  정확하지 않은 주석, 무한 루프, 사용하지 않는 로직, 문법적 오류 등 일반적으로 안전성과 관련된 문제 보다는 신뢰성 품질 문제로 인해 발생된다.
  
  
• Hardware-Induced Error
  원치 않는 수정으로 인해 발생하는 고장으로 잠재적으로 소프트웨어 명령의 의미가 변경될 수 있다.

다음은 소프트웨어 위험의 분류 예를 나타낸다.

안전한 소프트웨어 개발을 보증하는 방법

• Software Development Techniques
  소프트웨어 수명 주기의 각 단계 별 소프트웨어 개발 프로세스에서 적용해야 하는 공학적 기법이 필요하다. 예를 들어 설계 및 프로그래밍 단계동안의 모듈화된 설계 및 구조적 프로그램 개발이나 테스팅 단계에서의 시뮬레이션 기법을 의미한다.
  
  
• Software Management Techniques
  소프트웨어에 적용하는 전형적인 관리 기법에서 중요한 것은 형상관리, 적절한 일정 관리와 소프트웨어 변경에 따라 최신 문서로 갱신하는 것을 의미한다.
  
  
• Safety Analysis Techniques
  분석적 기법은 엔지니어가  hazard 와 관련있는 소프트웨어를 식별하고 통제하기 위해 사용된다.
  
  
• Software Safety Standard
  소프트웨어 모듈에 적용 가능한 안전성 표준과 요구사항이 필요하다.
  
  
• Standard Software Modules
  하드웨어 표준과 비슷하게 검증된 소프트웨어 모듈만이 특정 기능에서 요구하는 시스템에 적용되고 개발되어져야 한다.
  
  
• Safety Configuration Control
  소프트웨어 코드의 변경이 시스템 안전성에 어떤 영향을 주는지 산정한다.

소프트웨어 안전성 체크리스트 예제

1. Are logic decisions made in software verified by special logic built into each module?
2. Does software logic verify the sequence and logic of all keyboard actions?
3. Are routines that compute and/or set critical signals distributed over as many short sequence paths as possible?
4. Is control returned to the local executive as soon as practical after completion of a critical signal routine?
5. Is there more than one critical signal state processed in any of the critical signal paths?
6. Are internal software representations of functional discrete regularly updated and are flags represented by multi bit patterns or bytes?
7. Do critical program routines use primary command inputs for logic and computation?
8. Are input data erased after reading? Does software test the data buffer for presence of new data at the time of the next reading?
9. Does the software include a comprehensive self-test program that will be activated frequently when the system program is in operation? Does the self-test program have the capability of detecting all discrepancies in global data caused by the interference of other software, read-only protection error, and effects of inadvertent or malicious program alterations?
10. Are adequate provisions made for system backup or redundancy?
11. Are alarms used to warn of inadvertent or unauthorized software actions?
12. Are protocols and data extraction techniques for communication between data systems explicitly stated?
13. Are procedures documented that assure the prompt detection/correction of deficiencies that could otherwise result in noncompliant software?
14. Are provisions made for a transition to a degraded or manual mode if hardware failure or software error occurs?