- 시스템, 하드웨어 또는 소프트웨어의 올바른 기능과 요구사항 명세의 불일치, 소프트웨어와 시스템 사이의 인터페이스 불일치
- 안전 요구사항 명세에서 누락(예를 들면, 서로 다른 모드들로 운영되는 동안에 관련된 모든 안전 기능이 나타나지 않는 고장)
- 전체 시스템 관점에서 요구사항 완전성 부족하면 도출된 요구사항을 모두 구현했더라도 전체 시스템 관점에서는 불안전한 상태임
- 요구사항이 시스템 안전을 위해 필요한 특정 행위를 미반영, 요구사항 이외에 소프트웨어가 의도하지 않는 행위를 수행
- 하드웨어 우발 고장 메커니즘을 소프트웨어에 미반영
- 공통 소프트웨어 고장에 의한 영향
- 인적 오류(소프트웨어 조작자의 실수)
- 환경적인 영향(예를 들면, 전자기, 온도, 기계적인 현상들)
- 공급 시스템 전압 불안정(예를 들면, 공급 손실, 전압 감소, 공급의 재연결)
2017년 4월 6일 목요일
최근 많이 발생되고 있는 소프트웨어 안전성을 위배하는 오류들
최근 많이 발생되고 있는 소프트웨어 안전성을 위배하는 오류들
안전관련 소프트웨어의 제어 분류
소프트웨어는 하드웨어와 달리 제품이 마모 파손되거나 허용 오차가 증가와 같은 방식으로 오류 발생하지 않으며 일반적으로 구현 오류 (코드 오류, 설계 요구 사항을 잘못 해석) 혹은 외부 소프트웨어에 오류에 대하여 발생한다.
따라서 소프트웨어와 관련된 위험을 평가하는 것은 다소 복잡하다. 정확하게 소프트웨어 오류 발생을 예측할 수 없기 때문에 추가적으로 위험 분류의 방법이 필요하다. 소프트웨어의 동작에 영향을 주거나 일반 요인을 이용하여 위험 분류 방법은 표와 같다.
따라서 소프트웨어와 관련된 위험을 평가하는 것은 다소 복잡하다. 정확하게 소프트웨어 오류 발생을 예측할 수 없기 때문에 추가적으로 위험 분류의 방법이 필요하다. 소프트웨어의 동작에 영향을 주거나 일반 요인을 이용하여 위험 분류 방법은 표와 같다.
표. 안전관련 소프트웨어의 제어 분류
소프트웨어의 안전성
소프트웨어의 안전성은 과거 소프트웨어 중심의 프로세스 안전성 관점에서 시스템과 소프트웨어를 동시에 바라보는 개념으로 변화하고 있다. 이같은 변화는 소프트웨어를 전체 시스템의 일부로 인식하여 전체 시스템 레벨에서 위험성 분석을 선행하고, 시스템 위험분석 결과로 도출된 시스템 안전요구사항을 바탕으로 소프트웨어 안전요구사항을 도출해야 한다는 것을 의미한다.
소프트웨어 안전성을 보증한다는 의미는 소프트웨어가 가지고 있는 여러 가지 속성 중에서 특히 안전기능(Safety Function)이 올바르게 선정되었는지를 확인할 수 있어야 하고, 최종 개발 결과물이 수행하는 안전기능이 정상적으로 작동하는가를 확인하는 것이다.
예를 들어 “원자로를 안전하게 보호할 수 있고, 위험성을 알릴 수 있는 SW 를 개발하자” 라는 안전 요구사항을 기반으로 프로젝트를 시작한다고 하면 먼저 사업계획서를 만들고, 요구사항 명세서를 정리하고, 상세기술 명세서를 만들고, 소스코드를 만드는 등 여러 엔지니어들의 손과 머리를 거치게 된다. 하지만 작업이 끝난 후엔 처음에 의도했던 바와 전혀 다른 결과물이 나올 수 있게 된다. 그렇기 때문에 처음에 의도한 안전 요구사항과 최종 결과물의 일치성을 확보하고, 특히 안전기능(Safety Function)이 원래 의도한대로 개발되었는가를 반드시 검사해야 한다.
안전 소프트웨어 개발이라는 목표 달성이라는 측면에서 볼 때 가장 중요한 요소는 세가지로 구분된다.
첫째, SW 개발 안전 수명주기에 대한 이해이다. SW 개발 안전 수명주기는 개발 조직 내의 모든 개발자가 숙지하고 각 단계 별 결과물들을 사전에 계획된 바에 따라 생성해 나가야 하는 것인데 수명주기는 경우에 따라 국제표준에서 제시하는 가이드를 일부 테일러링하여 개발 프로젝트에 최적화시킬 수 있다.
둘째, 시스템 및 소프트웨어 위험분석 기법에 대한 이해가 필요하다. 안전한 소프트웨어 개발은 시스템 위험분석을 통하여 도출된 시스템 안전기능 요구사항을 근간으로 개발이 이루어 지기 때문이다. 시스템 레벨에서 도출된 안전기능 요구사항 중에서 소프트웨어가 수행하여야 하는 요구사항들이 소프트웨어 관점에서 명세화되고 이를 바탕으로 소프트웨어가 구현되어야 한다.
셋째, 소프트웨어 안전기능이 의도한 바와 같이 구현이 되었는지를 확인하는 올바른 검증 시험 방법을 적용하는 것이 중요하다. 소프트웨어의 안전성을 검증하는 시험은 디바이스 레벨에서 이루어지며, 검증의 목표는 시스템 안전 요구사항 및 소프트웨어 안전 요구사항이 원래 의도와 같이 구현되었는지를 검증하는 것이기 때문이다.
안전 기능으로 다뤄지는 항목들은 대개 표의 범주를 벗어나지 않으며, 아래 항목에 있는 부분들은 최상위 안전등급으로 다뤄져야 한다.
소프트웨어 안전성을 보증한다는 의미는 소프트웨어가 가지고 있는 여러 가지 속성 중에서 특히 안전기능(Safety Function)이 올바르게 선정되었는지를 확인할 수 있어야 하고, 최종 개발 결과물이 수행하는 안전기능이 정상적으로 작동하는가를 확인하는 것이다.
예를 들어 “원자로를 안전하게 보호할 수 있고, 위험성을 알릴 수 있는 SW 를 개발하자” 라는 안전 요구사항을 기반으로 프로젝트를 시작한다고 하면 먼저 사업계획서를 만들고, 요구사항 명세서를 정리하고, 상세기술 명세서를 만들고, 소스코드를 만드는 등 여러 엔지니어들의 손과 머리를 거치게 된다. 하지만 작업이 끝난 후엔 처음에 의도했던 바와 전혀 다른 결과물이 나올 수 있게 된다. 그렇기 때문에 처음에 의도한 안전 요구사항과 최종 결과물의 일치성을 확보하고, 특히 안전기능(Safety Function)이 원래 의도한대로 개발되었는가를 반드시 검사해야 한다.
안전 소프트웨어 개발이라는 목표 달성이라는 측면에서 볼 때 가장 중요한 요소는 세가지로 구분된다.
첫째, SW 개발 안전 수명주기에 대한 이해이다. SW 개발 안전 수명주기는 개발 조직 내의 모든 개발자가 숙지하고 각 단계 별 결과물들을 사전에 계획된 바에 따라 생성해 나가야 하는 것인데 수명주기는 경우에 따라 국제표준에서 제시하는 가이드를 일부 테일러링하여 개발 프로젝트에 최적화시킬 수 있다.
둘째, 시스템 및 소프트웨어 위험분석 기법에 대한 이해가 필요하다. 안전한 소프트웨어 개발은 시스템 위험분석을 통하여 도출된 시스템 안전기능 요구사항을 근간으로 개발이 이루어 지기 때문이다. 시스템 레벨에서 도출된 안전기능 요구사항 중에서 소프트웨어가 수행하여야 하는 요구사항들이 소프트웨어 관점에서 명세화되고 이를 바탕으로 소프트웨어가 구현되어야 한다.
셋째, 소프트웨어 안전기능이 의도한 바와 같이 구현이 되었는지를 확인하는 올바른 검증 시험 방법을 적용하는 것이 중요하다. 소프트웨어의 안전성을 검증하는 시험은 디바이스 레벨에서 이루어지며, 검증의 목표는 시스템 안전 요구사항 및 소프트웨어 안전 요구사항이 원래 의도와 같이 구현되었는지를 검증하는 것이기 때문이다.
안전 기능으로 다뤄지는 항목들은 대개 표의 범주를 벗어나지 않으며, 아래 항목에 있는 부분들은 최상위 안전등급으로 다뤄져야 한다.
표. Safety Critical 소프트웨어 유형
피드 구독하기:
글
(
Atom
)