SW는 위험한 안전 관련 기능의 작동과 제어에서 점점 더 중요한 역할을 하고 있습니다.
컴퓨터 기반 시스템의 안전은 시스템이 작동 시 나타나는 결과이며, SW는 시스템 작동에 기여하고 있어,
SW안전으로 인해 발생하는 위험 결과는 곧 사람, 돈, 환경에 영향을 미칩니다. SW안전의 목표는 시스템 안전계획에 원활하게 통합되어 SW로 인해 직접적으로나 혹은 SW에 의해 유도된 간접적인 위해가 위험한 상태(위험의 발생확률과 심각도를 고려)로 분석됐을 때 받아 드릴 수 있는 최저 리스크 수준으로 완화시키는 솔루션을 제공하는 것입니다.
SW안전은 시스템의 작동 결함률을 줄이거나, SW신뢰성과 SW보안을 향상시키는 것과는 무관하고, SW안전
요구사항은 안전 관련 시스템의 시스템 설계 결과로 할당되는 SW요구사항과 시스템 안전공학의 안전 분석 결과로
얻어지는 SW안전 요구사항으로 도출됩니다. 일반적으로 제품의 시스템과 SW의 안전 능력을 강화하는 방법은 제품의 수명주기 프로세스와 프로세스 단계별로 요구되는 안전 기술로 나눌 수 있습니다. 그리고 SW 수명주기 프로세스는 SW의 직접 개발, 외주 개발, 상용 구매, 통합 개발에 적용 가능하고, 각 개발 방법에 따른 SW안전 측면에서 적절한
프로세스와 기술은 각기 다르게 요구됩니다.
필자는 항공 분야에 다년간 근무한 전문가로서 그 동안 접했던 다양한 안전 필수 시스템 사업의 경험으로 얻어진
교훈을 전달하기 위해 안전 관련 SW가 포함된 시스템 설계와 개발에서 중요한 기본적이고 일반적인 SW안전 설계
지침을 8개 부문으로 나누어서 소개하고자 합니다. 설계 지침의 배경이나 구체적인 이론적 근거, 관련된 교훈들과
검증 방법에 대해서는 지면상 제외하였으며 가능한 한 특정 산업분야, 설계 접근, 구현 논리와 무관하게 고려하여
각 지침들을 기술하였습니다. 필자는 글로벌 경쟁력을 확보하기 위해 고군분투 중인 다양한 산업분야의 중소기업에서 새롭게 SW안전부문에 참여하는 엔지니어들에게 이 칼럼이 널리 참고 될 수 있기를 기대해봅니다.
1. 시스템 설계 요구사항
1.1 2인 규칙
적어도 두 사람은 시스템에 있는 각 SW 모듈의 설계, 코드, 시험 및 작동에 대해 철저히 숙지해야 한다.
1.2 프로그램 패치 금지
개발 과정에서 패치를 허용해서는 안되고, 모든 SW 변경은 운용 또는 시험 장비에 들어가기 전에 소스 언어로
코딩되고 컴파일 되어야 한다.
1.3 설계 안전 상태
시스템에는 각 후속 작동 단계를 위해 식별된 적어도 하나의 안전 상태가 있어야 한다.
1.4 안전한 상태 복귀
SW는 불안전한 조건이 감지되면 SW 제어 하에 있는 하드웨어 하위 시스템 조건을 설계된 안전한 상태로 되돌아가게 해야 한다. 배틀쇼트(최악의 경우에도 종료되지 않는 기능)에 의해 안전하게 무시될 수 있는 조건을 식별하고 분석하여 위험이 허용 가능한지 확인해야 한다.
1.5 불안전한 조건 우회
시스템 설계는 감지된 불안전한 상태를 우회하도록 허용해서는 안되며, 시스템에 "배틀쇼트"나 혹은 "안전아크
(최악의 조건에서도 안전한 상태에서 빠져나가지 않는 조건)" 조건이 필요한 경우, 부주의로 혹은 승인 없이 활성화
될 수 없도록 설계해야 한다.
1.6 외부 하드웨어 결함
SW는 외부 하드웨어 입력 또는 출력 하드웨어 장치의 결함을 감지하고, 결함 발생 시 안전한 상태로 되돌리도록 설계되어야 한다. 설계는 관련된 하드웨어의 잠재적인 결함모드(작동 중이지 않아 숨어 있는 결함)를 고려해야 한다.
1.7 안전커널 결함
시스템은 안전커널의 결함 (구현된 경우)을 감지하고, 시스템이 지정된 안전한 상태로 되돌아 가도록 설계되어야 한다.
1.8 폴백(대비책) 및 복구 시스템은 시스템의 구성요소에 결함이 발생할 경우 저하된 시스템 기능적 능력의 안전한
상태로 폴백과 복구를 포함하도록 설계되어야 한다.
1.9 컴퓨팅시스템 결함
시스템은 컴퓨팅시스템의 결함이 감지되면 안전한 상태로 리턴하도록 설계되어야 한다.
1.10 정비 인터록(안전을 지켜주고, 제품 작동을 보호해주는 기능)
컴퓨팅시스템 및 관련 장비를 정비하는 정비사에 대한 위험을 방지하기 위해 정비 인터록, 안전 인터록, 안전 핸들 및/또는 안전 핀이 제공되어야 한다. 이들 인터록이 무효화되는 동안 실행 가능하다면 인터록 상태를 운용자나 혹은 시험컨덕터의 콘솔에 시현해야 한다.
1.11 인터록 복원
시험, 교육 또는 정비를 수행하기 위해 인터록이 무효화되거나 혹은 제거되어야 하는 경우, 시스템이 작동 용도로 복원되고 난 후, 실수로 무효화되거나 혹은 무효화된 상태로 남아 있지 않도록 인터록을 설계해야 한다. 인터록의 무효화는 컴퓨팅시스템에 의해 제어되지 않아야 한다.
1.12 시뮬레이터
시뮬레이션 된 항목, 시뮬레이터 및 시험 장비들이 필요한 경우, 장치들의 고유 작동 특성은 fail-safe가 되도록 시스템을 설계하고, 그리고 작동 하드웨어가 시뮬레이션 된 항목, 시뮬레이터 또는 시험 장비들로 부주의하게 동일화되지 않도록 시스템을 설계해야 한다.
1.13 안전 오류 로깅
안전관련 루틴의 오류는 발생 후 가능한 한 빨리 기록을 남기고 운용자에게 알려야 한다.
1.14 긍정적인 피드백 메커니즘
필수기능의 SW 제어에는 기능 생성에 대한 적절한 긍정적 표시를 제공하는 피드백 메커니즘이 있어야 한다. 이러한 피드백 메커니즘은 다른 기능에 불안전한 간섭을 일으키지 않아야 한다.
1.15 최대 부하 조건
시스템과 SW는 설계 안전 요구사항이 최대 부하 조건에서 위반되지 않도록 설계되어야 한다.
1.16 정비 용이성
시스템과 SW는 정비의 용이함을 위해 설계되고 문서화되어야 한다.
1.17 장기간 운용 이슈
시스템과 SW는 안전관련 이상현상이 발생하지 않으면서 규정된 기간 동안 지속적으로 작동하도록 설계, 개발 및 시험되어야 한다. 규정된 기간은 규격서 요구사항의 1.5 배 또는 최대 예상임무시간이어야 한다. 검증은 작동 환경을 대표하는 환경에서 수행되어야 한다.
1.18 오류 처리
시스템 및 SW는 애플리케이션, OS 또는 프로세서에서 errors, faults, failures 및 exceptions이 발생된 경우 시스템과 SW는 강건하고 안전하게 유지되도록 설계되어야 한다.
1.19 독립형 프로세서
실행 가능한 경우 안전관련기능은 독립형 컴퓨터에서 수행해야 한다. 이렇게 실행할 수 없다면, 안전관련기능은 비 안전관련기능과 실행 가능한 한 최대 범위로 분리되어야 한다.
1.20 입력/출력 레지스터
비안전관련기능에 동일한 안전설계 기준이 적용되지 않는 한, 입력/출력 레지스터 및 포트는 안전관련기능과 비 안전관련기능 모두에 사용되지 않아야 한다.
1.21 파워 업 초기화
시스템은 정해진 안전 상태로 전원이 켜지도록 설계되어야 한다. 검증 가능한 시스템 모니터 점검은 시스템이 정해진 안전한 상태에 있는지를 검증하는 설계에 통합되어야 한다. 이 점검은 또한 메모리 건전성과 프로그램 로드를 검증하여야 한다.
1.22 파워다운 전환
시스템은 정해진 안전 상태로 전원이 꺼지도록 설계되어야 한다. 검증 가능한 시스템 모니터 점검은 시스템이 정해진 안전한 상태에 있는지를 검증하는 설계에 통합되어야 한다.
1.23 전원 결함
시스템 및 컴퓨팅시스템은 전원 공급 결함, 전원 차단 결함, 간헐적 결함 또는 시스템에 악영향을 미칠 수 있는 전원 변동이나 혹은 전원 손실이 발생할 시 시스템이 안전한 상태에 있도록 설계되어야 한다.
1.24 시스템 수준 점검
SW는 SW에 의해 제어되는 하드웨어를 포함한 안전관련기능에 전원을 공급하기 전에 시스템이 안전하고 제대로 작동하는지를 검증하기 위해 파워 업 시스템 수준 점검을 수행하도록 설계되어야 한다. 주기적인 SW 시험이 안전한 작동 조건을 보장할 수 있는 시스템의 상태를 모니터 하도록 수행되어야 한다.
1.25 리던던시 관리
설계에 리던던시가 포함되어 있는 경우, 리던던시 계획과 관련된 모든 잠재적인 결함모드들을 식별하여 시스템에 미치는 영향이 위험으로 평가된 결함모드들은 해당 위험을 수용할 수 있는 수준으로 적절히 완화시키는 대책을 시스템/SW 요구사항으로 반영해야 한다.
다음편은 12월 14일(월), SW안전기술 역량강화 홈페이지에 게재 예정입니다.