tb1-2 - sase.or.krsase.or.kr/upload/session/24/tb1-2.pdf · 2019. 4. 22. · arp-4754a, 2010. [2]...

3
항공우주시스템공학회 2019년도 춘계학술대회 SASE 2019 Spring Conference 항공용 소프트웨어 레벨 할당을 위한 안전성 평가 고려사항 연구 윤동환 · 김현우· 채희문· 김성훈 한국정보통신기술협회 소프트웨어시험인증연구소 A Study on Safety Assessment Considerations for Software Level Assignment for Aviation Donghwan Yoon , Hyunwoo Kim, Heemoon Chae and Sunghoon Kim Software Testing & Certification Laboratory, TTA Abstract : 항공용 소프트웨어는 항공용 시스템 개발 프로세스와 동시에 수행된 안전성 평가 프로세스에 따라 소프트웨어 레벨을 할당 받는다. 소프트웨어 레벨은 해당 기능 실패로 인해 유발되는 심각도에 따 라 엄격성 결정되며, 할당된 소프트웨어 레벨은 달성해야 할 목표들(Objectives)을 가지게 된다. 할당된 소프트웨어 레벨이 높을수록 달성해야 할 목표의 개수가 증가하고, 목표의 개수가 증가함은 곧 해당 소 프트웨어 개발에 투입되는 시간과 비용이 증가됨을 의미한다. 본 논문에서는 제시하고자 하는 항공용 소프트웨어 레벨 할당을 위한 안전성 평가 고려사항은 안전성 평가 시, 기능위해 수준을 완화시키기 위 한 안전 장벽들이다. 안전 장벽은 안전성 평가를 통해 해당 기능이 유발하는 최대 심각도를 완화하여 설계 측면에서의 안전성을 확보하고 개발 효율성을 향상시키는 방법이다. 본 논문에서는 앞서 설명한 안전 방벽을 세부적으로 분류하고 안전성 평가 과정에서 이를 어떻게 활용할 수 있는지 연구하였다. Key Words : Safety Assessment(안전성 평가), Software Level(소프트웨어 레벨), Safety Design Selection(안전 설계 선택), Mitigation Strategy(완화 전략), Safety Barrier(안전 장벽) 1. 서 항공용 시스템을 개발하기 위한 표준은 미국 및 유 럽 모두 크게 안전성 평가 프로세스 영역과 시스템 개 발 프로세스 영역으로 나뉜다. Figure 1과 같이 고신뢰 성 항공용 시스템 개발은 시스템, SW 및 HW 개발 생 명주기에 맞춰 개발이 이루어짐과 동시에 모든 생명주 기 동안 안전성 평가를 수행하는 형태로 이루어진다. 이러한 형태는 본 논문의 기준인 ARP-4754A (ED- 79A), ARP-4761 (ED-135) 외에 다른 기준(예, ECSS Standards)를 사용하더라도 유사하다. 항공용 소프트웨어의 레벨은 시스템 개발 및 안전성 평가 프로세스 사이에서 산출된 기능 개발보증레벨 (FDAL, Functional Development Assurance Level)을 기반으로 할당 받는다. 하지만 소프트웨어 레벨은 시 스템의 기능/항목을 분해하는 과정에서 심각도 완화 전략을 통해 기능적 개발보증레벨 보다 덜 엄격한 수 준의 소프트웨어 레벨을 할당 받을 수도 있다. Fig. 1 Flow Chart for Development and Safety Assessment Process[1] 교신저자 ( Corresponding Author ) E-mail: [email protected] Copyright The Society for Aerospace System Engineering TB1-2 1

Upload: others

Post on 15-Mar-2021

2 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: TB1-2 - sase.or.krsase.or.kr/Upload/Session/24/TB1-2.pdf · 2019. 4. 22. · ARP-4754A, 2010. [2] Certification Authorities Software Team, Considerations for Evaluating Safety Engineering

항공우주시스템공학회 2019년도 춘계학술대회 SASE 2019 Spring Conference

항공용 소프트웨어 레벨 할당을 위한 안전성 평가 고려사항 연구

윤동환†· 김현우· 채희문· 김성훈

한국정보통신기술협회 소프트웨어시험인증연구소

A Study on Safety Assessment Considerations for Software Level

Assignment for Aviation

Donghwan Yoon†, Hyunwoo Kim, Heemoon Chae and Sunghoon Kim

Software Testing & Certification Laboratory, TTA

Abstract : 항공용 소프트웨어는 항공용 시스템 개발 프로세스와 동시에 수행된 안전성 평가 프로세스에

따라 소프트웨어 레벨을 할당 받는다. 소프트웨어 레벨은 해당 기능 실패로 인해 유발되는 심각도에 따

라 엄격성 결정되며, 할당된 소프트웨어 레벨은 달성해야 할 목표들(Objectives)을 가지게 된다. 할당된

소프트웨어 레벨이 높을수록 달성해야 할 목표의 개수가 증가하고, 목표의 개수가 증가함은 곧 해당 소

프트웨어 개발에 투입되는 시간과 비용이 증가됨을 의미한다. 본 논문에서는 제시하고자 하는 항공용

소프트웨어 레벨 할당을 위한 안전성 평가 고려사항은 안전성 평가 시, 기능위해 수준을 완화시키기 위

한 안전 장벽들이다. 안전 장벽은 안전성 평가를 통해 해당 기능이 유발하는 최대 심각도를 완화하여

설계 측면에서의 안전성을 확보하고 개발 효율성을 향상시키는 방법이다. 본 논문에서는 앞서 설명한

안전 방벽을 세부적으로 분류하고 안전성 평가 과정에서 이를 어떻게 활용할 수 있는지 연구하였다.

Key Words : Safety Assessment(안전성 평가), Software Level(소프트웨어 레벨), Safety Design

Selection(안전 설계 선택), Mitigation Strategy(완화 전략), Safety Barrier(안전 장벽)

1. 서 론

항공용 시스템을 개발하기 위한 표준은 미국 및 유

럽 모두 크게 안전성 평가 프로세스 영역과 시스템 개

발 프로세스 영역으로 나뉜다. Figure 1과 같이 고신뢰

성 항공용 시스템 개발은 시스템, SW 및 HW 개발 생

명주기에 맞춰 개발이 이루어짐과 동시에 모든 생명주

기 동안 안전성 평가를 수행하는 형태로 이루어진다.

이러한 형태는 본 논문의 기준인 ARP-4754A (ED-

79A), ARP-4761 (ED-135) 외에 다른 기준(예, ECSS

Standards)를 사용하더라도 유사하다.

항공용 소프트웨어의 레벨은 시스템 개발 및 안전성

평가 프로세스 사이에서 산출된 기능 개발보증레벨

(FDAL, Functional Development Assurance Level)을

기반으로 할당 받는다. 하지만 소프트웨어 레벨은 시

스템의 기능/항목을 분해하는 과정에서 심각도 완화

전략을 통해 기능적 개발보증레벨 보다 덜 엄격한 수

준의 소프트웨어 레벨을 할당 받을 수도 있다.

Fig. 1 Flow Chart for Development and Safety

Assessment Process[1]

†교신저자 ( Corresponding Author )

E-mail: [email protected] Copyright Ⓒ The Society for Aerospace System

Engineering

TB1-2

1

Page 2: TB1-2 - sase.or.krsase.or.kr/Upload/Session/24/TB1-2.pdf · 2019. 4. 22. · ARP-4754A, 2010. [2] Certification Authorities Software Team, Considerations for Evaluating Safety Engineering

항공우주시스템공학회 2019년도 춘계학술대회 SASE 2019 Spring Conference

본 논문에서는 소프트웨어 레벨 할당 과정에서 심각

도 완화 전략으로 사용할 수 있는 주요 고려사항을 분

석하였다.

2. 소프트웨어 레벨 할당

2.1 소프트웨어 레벨 할당 개요

Figure 2는 소프트웨어 레벨과 FDAL 그리고 심각도

분류와의 관계를 나타낸다. 소프트웨어의 고장, 오작동

은 결국 소프트웨어가 할당 받은 기능에 대한 고장 및

오작동을 야기할 수 있다. 이러한 이유로 시스템 기능

의 심각도를 완화하는 전략은 곧 소프트웨어의 심각도

를 완화할 수 있는 시스템 수준의 효과적인 방법이 될

수 있다.

Fig. 2 Relationship between SW Level, FDAL

and Severity Classifications

2.2 시스템에서 소프트웨어 레벨 할당

Figure 3의 왼쪽은 시스템의 주요 기능이 소프트웨

어로 직접 할당된 경우이다. 기능에 할당된 FDAL A가

그대로 소프트웨어 레벨 A로 할당된다. 반면, 오른쪽

부분은 FDAL A의 기능을 독립적인 세부 기능 혹은 독

립적인 기능과 안전 장벽을 구현함으로써, 소프트웨어

레벨이 A가 아닌 B를 할당 받게 된다.

Fig. 3 Allocation from FDAL to SW Level

3. 주요 고려사항

시스템 및 소프트웨어는 항상 안전한 상태에서 시작

되어야 한다[2]. 이를 위해 안전성 관리자는 기능실패

위험 감소를 위한 완화 전략을 통해 고장에 대비하는

안전설계를 고려해야 한다.

3.1 안전 설계

안전 설계는 고장 안전 설계 및 안전 장벽으로 구성

되며 안전 장벽은 다음과 같이 3가지 방법으로 구분된

다.

(1) 물리적 방법 : 물리적 요소를 추가하여 완화

(2) 전자적 방법 : 전자적 요소를 추가하여 완화

(3) 절차적 방법 : 절차적 요소를 추가하여 완화

3.2 완화 전략

완화 전략은 다음과 같이 3가지 방법으로 구분된다.

(1) 제거(Elimination) : 위험원을 제거

(2) 완화(Mitigation) : 위험원의 위험도를 완화

(3) 통제(Control) : 위험 통제/차단

Figure 4는 위험 완화 절차를 나타내며, 식별된 위험

심각도가 시스템 기능의 안전성 목표를 달성할 수 없

는 경우, 완화 전략에 따라 안전 설계 기법을 통해 안

전 장벽을 설계해야 한다.

Fig. 4 Risk Mitigation Strategy[3]

4. 결론

본 논문에서는 항공용 소프트웨어의 레벨 할당 과정

및 소프트웨어 레벨 할당 과정에서 안전성 관리자가

고려해야할 2가지 주요 사항을 소개하였다.

시스템에서 소프트웨어 레벨로 할당이 이루어질 때,

안전성 관리자는 시스템 및 소프트웨어의 안전 상태

달성을 위해 해당 기능이 유발할 수 있는 위험도를 완

화하기 위한 전략을 고려해야 한다. 이러한 완화 과정

은 제거, 완화, 통제로 구성되며, 해당 전략은 물리적,

2

Page 3: TB1-2 - sase.or.krsase.or.kr/Upload/Session/24/TB1-2.pdf · 2019. 4. 22. · ARP-4754A, 2010. [2] Certification Authorities Software Team, Considerations for Evaluating Safety Engineering

항공우주시스템공학회 2019년도 춘계학술대회 SASE 2019 Spring Conference

전자적, 절차적 완화 방법을 고려하여 적용할 수 있다

본 논문에서 소개한 소프트웨어 할당 절차 및 주요

고려사항은 안전성 관리자가 시스템 설계 시, 효율적

인 소프트웨어 레벨을 할당하고 시스템 전체적인 안전

성을 확보하는데 사용할 수 있다.

참 고 문 헌

[1] SAE S-18 and WG-64 Committees, Guidelines for

Development of Civil Aircraft and Systems, SAE

ARP-4754A, 2010.

[2] Certification Authorities Software Team,

Considerations for Evaluating Safety Engineering

Approaches to Software Assurance, Position

Paper CAST-9, 2002.

[3] ECSS Secretariat, Space product assurance –

Hazard analysis, ECSS-Q-ST-40-02C, 2008.

3