2. 컴퓨팅시스템 환경 요구사항 및 지침
2.1 컴퓨팅 환경의 결함
응용 프로그램은 프로그램의 실행을 총체적으로 지원하는 SW와 하드웨어로 구성된 컴퓨팅 환경에서 존재한다.
이 환경에서 결함이 발생하면 응용 프로그램에서 다양한 결함 또는 예기치 않은 작동이 발생할 수 있으므로 위해
분석과정에서 고려해야 한다. 이러한 결함모드 중 일부 (예: 스토리지의 프로그램 Overwrite)의 경우 결과를 완벽히
예측하기가 특히 어렵다 (예: Overwrite된 영역과 거기에 Write된 패턴에 따라 다르기 때문에).
그러므로 일반적인 입증은 개발자가 이런 종류의 결함에 노출되지 않는다거나 그러한 결함이 잠재적인 위해를
나타내지 않는다는 근거를 제공하는 것이다.
2.2 CPU 선택
전체 명령 또는 데이터 워드를 독립적으로 처리하는 CPU가 명령 또는 데이터를 멀티플렉싱 하는 CPU보다 선호된다 (예: 128 비트 시스템을 에뮬레이션하는 64 비트 CPU보다 128 비트 CPU가 선호 된다).
복잡한 것보다 간단한 것을 선호한다.
별도의 명령과 데이터 메모리 및 버스를 가진 CPU가 공통 데이터/명령 버스를 사용하는 CPU보다 선호된다. 또는 프로그램 메모리와 데이터 메모리를 분리하는 메모리 보호 하드웨어 (세그먼트 또는 페이지 보호)가 더 좋다.
수학적으로 완전히 표현할 수 있는 CPU, 마이크로프로세서 및 컴퓨터는 그렇지 않은 컴퓨터보다 선호된다.
2.3 최소 클록 사이클
앞에서 언급한 지침을 준수하지 않거나 설계 기준의 한계 (예: 최대 클록 주파수 이상)에서 사용되는 CPU의 경우,
유효하지 않은 정보가 CPU에 의해 선택되지 않도록 보장하기 위해 버스 상의 기능들 간에 발생해야 하는 최소 클록
사이클 수를 결정하기 위해 분석과 측정을 수행해야 한다. 인터페이스 장치가 CPU에 주어진 시간 프레임 내에 유효한 데이터를 제공 할 수 있는지 분석을 수행해야 한다.
2.4 읽기 전용 메모리
ROM (Read Only Memories)을 사용하는 경우, ROM 데이터가 손상되거나 파괴되지 않도록 적극적인 조치를
취해야 한다.
3. Self-Check 설계 요구사항 및 지침
3.1 워치 독 타이머
마이크로프로세서 또는 컴퓨터가 제대로 작동하고 있다는 것을 보장하기 위해 워치독 타이머 또는 유사한 장치를
제공해야 한다. 타이머 재설정은 SW가 내부 루프에 들어가서 해당 루프 시퀀스의 일부로 타이머를 재설정 할 수
없도록 설계해야 한다. 이 타이머의 설계는 주 CPU 클록의 결함이 이 기능을 손상시키지 않도록 보장해야 한다.
타이머 재설정은 시스템이 알려진 안전한 상태로 되돌아가고 운용자에게 경고 (해당되는 경우)를 하도록
설계되어야 한다.
3.2 메모리 점검
메모리와 명령 및 데이터 버스에 대한 주기적인 점검을 수행해야 한다. 시험 시퀀스의 설계는 단일점 결함 또는
다중 결함들이 감지되도록 해야 한다. 안전관련 코드의 건전성을 보장하기 위해 데이터 전송 시에 체크섬과
프로그램을 로드 할 때 검증 점검 형식으로 로드 할 때와 로드 이후에 주기적으로 수행해야 한다.
3.3 결함 감지
결함 감지 및 격리 프로그램은 컴퓨팅시스템의 안전관련 서브시스템을 위해 사용되어야 한다.
결함 감지 프로그램은 관련된 안전관련기능을 실행하기 전에 잠재적인 안전관련 결함을 감지하도록 설계되어야 한다. 결함 격리 프로그램은 결함을 실행 가능한 가장 낮은 수준으로 격리하고 이 정보를 운용자 또는 정비사에게 제공
하도록 설계되어야 한다.
3.4 작동 점검
시험 가능한 안전관련시스템 요소들의 작동 점검은 관련된 안전관련 작동을 수행하기 바로 직전에 이루어져야 한다.
4. 안전관련이벤트 및 안전관련기능
시스템 및 SW의 안전 평가의 주요한 측면은 안전관련이벤트와 관련된 안전관련기능을 식별하는 것이다.
안전관련이벤트는 우연히 또는 원하지 않을 때 위해 또는 사고를 유발시키는 것들이다 (예: 발사체 발사는 안전관련
이벤트이고, 부주의한 발사체 발사는 위해이다).
시스템 수준의 안전관련이벤트는 항상 예비위해분석 (PHA)에서 직접적인 상관 관계가 있다. 그렇지 않은 경우
PHA는 불완전하다. 서브시스템 수준의 안전관련이벤트는 SSHA (Subsystem Hazards Analysis) 또는 PHA와 SSHA 모두와 상관 관계가 있다.
안전관련기능은 안전관련이벤트를 발생 또는 제어하거나 혹은 안전관련데이터를 생성 또는 조작하는 기능이다.
안전관련기능에는 하드웨어 기능, SW 기능 및/또는 운용자의 조치가 포함될 수 있다. SW에서 안전관련기능을
식별하는 것은 높은 수준의 SW 관련 위해 인과 요인을 식별 할 수 있는 기반을 제공하므로 식별된 위해 인과 요인을
완화 할 수 있도록 높은 수준의 안전 설계 요구사항을 개발할 수 있게 한다. 안전 설계 요구사항은 종종 SW 관련 위해 인과 요인의 역이다. 이 추상화 수준에서 안전 요구사항은 매우 광범위하며 안전 요구사항을 추가로 유도하기 위한
기준을 제공한다.
초기 설계 단계에서 시스템 아키텍처를 마무리하기 전에 시스템안전 엔지니어는 시스템 아키텍처,
특히 SW 아키텍처가 바람직한 안전 속성을 지원하도록 보장하는 목적을 가진 시스템의 아키텍처에 영향을 줄 수
있는 안전관련이벤트와 안전관련기능을 식별한다. 이런 동일한 프로세스는 서브시스템과 관련 SW를 포함하여
아키텍처의 각 개선 수준에 적용한다. 시스템엔지니어링이 아키텍처를 정의하고 개선함에 따라 시스템안전은
이전에 식별된 안전관련기능, 관련된 위해, 안전설계요구사항을 활용하여 구현을 위한 높은 수준의 안전 요구사항을 개발하고 개선한다. 복잡한 시스템은 단순한 시스템보다 이러한 프로세스를 더 많이 반복해야 한다.
시스템설계의 개선이 진행됨에 따라 SW안전은 SW 관련 위해 인과 요인들을 식별하여, 식별된 요인들의 위해를
평가하여 위험한 것들을 제거하거나 혹은 완화하기 위한 안전 설계 요구사항이나 또는 구현 권장사항의 개발을
개선 할 수 있다. SW를 통해 기능적 스레드를 추적하는 것은 후속 개선 수준에서 잠재적인 SW 관련 위해 인과 요인을 식별하는 한 가지 수단이다.
그러나 SW안전은 안전관련기능스레드에 악영향을 미칠 수 있는 SW의 다른 측면도 분석해야 한다. 안전관련기능
스레드의 일부를 구성하는 모듈 내의 기능은 해당 기능이 기능 스레드에 직접적인 영향을 주지 않더라도 해당 스레드의 안전한 실행에 영향을 미칠 수 있다. 이는 SW 구현의 오류나 또는 환경적 요인으로 인해 발생된 SW의 비 결정적인
조치로 인한 것일 수 있다. 마찬가지로, 안전관련기능스레드와 인터페이스하는 SW는 안전관련기능을 불안전한
방식으로 실행되게 할 수 있다. 안전 전문가들은 종종 안전관련기능에 직접적인 영향을 미치는 SW를 첫번째 레벨
인터페이스로 식별한다. 첫번째 레벨의 인터페이스 기능에는 결함이 직접적으로 위험한 조건 (예: 위해 인과 요인)을 초래하는 SW를 포함하고 있다. 안전관련기능스레드의 실행에 영향을 주지만 관련된 SW 위해 인과 요인을 직접 발생시키지 않는 SW 인터페이스는 두 번째 레벨 인터페이스로 지정된다. 두 번째 레벨 인터페이스에는 예상치 못한 조건의 다른 결함과 함께 결함이 발생할 경우 원치 않는 위해 인과 요인으로 이어지는 SW 인터페이스들이 종종 포함된다.
다음편은 12월 21일(월), SW안전기술 역량강화 홈페이지에 게재 예정입니다.
본 내용은 칼럼 작성자 개인의 의견으로 정보통신산업진흥원의 공식적인 의견이 아니며
사용되는 용어는 산업분야별로 달리 사용될 수 있음을 알려드립니다.