선택한 단어 수는 입니다.
최소 단어 이상 선택하여야 합니다.
최소 단어 이상 선택하여야 합니다.
선택한 단어 수는 30입니다.
최대 10 단어까지만 선택 가능합니다.
최대 10 단어까지만 선택 가능합니다.
문제 정의
- 본 논문에서는 차량용 임베디드 소프트웨어 FMEA에 적합한 가이드라인을 제안하여 차량용 임베디드 소프트웨어 FMEA 사용상의 효율을 향상시키고자 한다. FMEA 종류 중 프로세스 측면의 FMEA를 제외한 기능측면의 DFMEA(Design FMEA)[10]를 대상으로 한다.
- 본 연구는 전자식 주차 브레이크 시스템 개발 시 소프트웨어 FMEA의 효율성을 향상시키기 위해 진행되었다. 소프트웨어 FMEA의 효율성을 높이기 위하여 본 논문에서 제시된 가이드라인의 주요 내용은 다음과 같다.
- 비효율적이었던 원인은 불필요한 안전 메커니즘의 개수가 과다했던 것으로 분석되었다. 본 연구에서는 차량용 임베디드 소프트웨어의 특성에 적합한 소프트웨어 FMEA 가이드라인을 제안하는 것을 목표로 한다. 본 논문은 2장 안전 분석 및 소프트웨어 FMEA, 3장 문제점 분석, 4장 가이드라인의 제안, 5장 평가, 그리고 6장 결론으로 구성된다.
- 시스템을 구성하는 한 요소의 장애가 시스템 전체에 미치는 영향을 분석하여 장애를 피할 수 있도록 한다. 설계, 공정, 품질 등 각 분야에 내포된 문제를 개발단계 초기에서 제거하기 위한 목적으로 사용한다[8-10].
- 우리는 소프트웨어 설계 단계에서 개발자가 객관적이고 체계적인 안전 분석을 할 수 있도록 가이드라인을 제안하고자 하였다. 먼저 3장에서 언급한 문제점의 원인을 분석하였으며 Table 2와 같이 정리하였다.
제안 방법
- 기존에는 소프트웨어 FMEA 수행 시 하위 컴포넌트들을 동시에 분석 하였다. 각 컴포넌트의 개발자는 컴포넌트의 장애 유형과 시스템의 기능의 관계를 분석하여 컴포넌트별로 안전 메커니즘을 적용하였다. 분석결과에 따라 개발자가 적절하다고 판단하는 안전 메커니즘을 적용하였다.
- 개발자는 시스템, 하드웨어 및 소프트웨어의 개발 단계별로 안전 분석을 수행한다. 안전 분석에는 귀납적 분석기법과 연역적 분석기법이 있다.
- 4장에서는 소프트웨어의 분석, 변경, 검증 등, 유지 보수의 어려움이 소프트웨어 설계측면의 심각도에 해당한다고 분석하였다. 그리고 유지보수의 어려움을 정량화하여 소프트웨어 FMEA 가이드라인을 제안하였다.
- 해당 컴포넌트에 할당된 요구사항들만 고려하여 후순위 컴포넌트의 요구사항 충족 가능 여부만 분석되도록 하였다. 또한 분석 순서도 데이터 흐름을 기준으로 백-프런트 순서로 분석하도록 하여 후순위 컴포넌트에 대한 영향성 분석이 정확하도록 하였다.
- 마지막으로 안전 분석의 반복횟수를 비교하였다. Table 9와 같이 제안된 가이드라인 적용 시 안전 분석의 수행횟수가 줄어드는 것을 알 수 있다.
- 먼저 Table 4와 같이 안전 메커니즘의 삭제 또는 변경이 적절한지 확인하기 위해 소프트웨어 안전 요구사항 개수와 시스템 단계의 기술적 안전 요구사항 개수의 변화량을 확인하였다. 소프트웨어 안전 요구 사항 개수는 감소하였지만, 기술적 안전 요구사항 개수의 변화량은 없었다.
- 먼저 소프트웨어를 개발하는 데 있어 가장 많이 발생하는 결함의 원인을 분석하였다. 크게 소프트웨어가 동작하는 하드웨어의 결함, 개발자의 실수 등이 있었다.
- 문제의 원인을 해결하기 위해 소프트웨어 하위 컴포넌트 안전 분석 단계에서 시스템 또는 자동차의 영향은 생각하지 않도록 하였다. 해당 컴포넌트에 할당된 요구사항들만 고려하여 후순위 컴포넌트의 요구사항 충족 가능 여부만 분석되도록 하였다.
- 본 장에서는 제안된 가이드라인에 따라 소프트웨어 FMEA를 진행한 뒤 안전 분석의 효율성을 재평가한다. 제안 기법을 따르는 프로젝트의 소프트웨어 FMEA 결과와 시스템 FMEA 가이드라인을 따랐던 프로젝트의 소프트웨어 FMEA 결과를 비교하였다.
- 각 컴포넌트의 개발자는 컴포넌트의 장애 유형과 시스템의 기능의 관계를 분석하여 컴포넌트별로 안전 메커니즘을 적용하였다. 분석결과에 따라 개발자가 적절하다고 판단하는 안전 메커니즘을 적용하였다. 각각의 안전 메커니즘은 해당 컴포넌트에 적절하게 적용되었다고 할 수 있었으나, 전체 시스템 수준에서는 과다하게 설계되어 문제를 일으켰다.
- FMEA는 귀납적 분석의 대표 기법의 하나이다. 시스템을 구성하는 한 요소의 장애가 시스템 전체에 미치는 영향을 분석하여 장애를 피할 수 있도록 한다. 설계, 공정, 품질 등 각 분야에 내포된 문제를 개발단계 초기에서 제거하기 위한 목적으로 사용한다[8-10].
- 안전 메커니즘의 개수가 조정되면서 소프트웨어의 개선된 정도를 확인하기 위해 앞서 언급된 5개 컴포넌트의 실행시간을 측정하였다. 실행시간은 TRACE 32 장비를 사용하여 측정하였으며 소프트웨어는 Infineon TC27X core, 16MB RAM의 환경에서 운용되었다.
- 2처럼 장애 유형을 정의한다. 이후 장애 유형 발생의 원인과 영향성을 분석한 결과를 기준으로 RPN(Risk Priority Number) 평가 및 적절한 안전 메커니즘을 도출한다[10]. 도출된 안전 메커니즘은 소프트웨어 내부에 적절하게 적용되어야 하며 안전 메커니즘의 추가적인 적용은 개발시간과 소프트웨어의 복잡도를 증가시킨다.
- 잘못된 영향성 분석으로 “Input data trembling”이라는 원인 식별과 함께 의미 없는 “Data Saturation” 안전 메커니즘을 만들게 되었다.
- 장애 유형이 위험하다고 평가되는 경우, 출력 신호를 전달받는 후순위 컴포넌트 개발자와 협의 후 안전 메커니즘을 추가하도록 하였다. 최종적으로 소프트웨어 FMEA의 효율성 및 객관성을 확보하기 위해 아래와 같이 지켜야 할 몇 가지 제약사항을 만들었다.
- 본 장에서는 제안된 가이드라인에 따라 소프트웨어 FMEA를 진행한 뒤 안전 분석의 효율성을 재평가한다. 제안 기법을 따르는 프로젝트의 소프트웨어 FMEA 결과와 시스템 FMEA 가이드라인을 따랐던 프로젝트의 소프트웨어 FMEA 결과를 비교하였다. 두 가지 프로젝트는 설계 인원을 제외하면 시스템 기능과 안전 목표가 같다.
- 제안된 가이드라인을 사용하면 분석 컴포넌트의 기능을 명확히 한 뒤 Fig. 10과 같이 백-프런트 순서로 안전 분석을 진행한다. 그 결과 장애 유형에 대한 후순위 컴포넌트의 영향성이 적절하게 식별되었으며, 안전 메커니즘이 적절하게 도출되면서 안전 메커니즘의 재평가 횟수가 줄어들었다.
- 제안된 소프트웨어 FMEA 심각도 기준을 사용할 때 심각도 값의 변화를 확인한다. Table 5와 같이 기존에 사용하던 심각도 기준보다 제안된 심각도 기준을 사용할 때 전반적으로 심각도 값이 하향 조정된 것을 알 수 있다.
- 장애 유형이 위험하다고 평가되는 경우, 출력 신호를 전달받는 후순위 컴포넌트 개발자와 협의 후 안전 메커니즘을 추가하도록 하였다. 최종적으로 소프트웨어 FMEA의 효율성 및 객관성을 확보하기 위해 아래와 같이 지켜야 할 몇 가지 제약사항을 만들었다.
- 한 가지 예를 들면 후순위로 동작되는 컴포넌트에 기동작된 컴포넌트들의 결과를 비교하여 개연성을 확인(Plausibility check) 기능이 존재했다. 하지만 먼저 수행되는 컴포넌트의 개발자가 출력 신호에 대한 예외처리를 안전 메커니즘으로 적용하였고, 그 결과 비교 대상이었던 신호의 값은 후순위 컴포넌트 개발자의 예상을 벗어나게 되었다. 결국 후순위로 수행되는 컴포넌트에 적용되어있던 개연성 확인 기능은 정상적으로 동작하지 않았다.
- 문제의 원인을 해결하기 위해 소프트웨어 하위 컴포넌트 안전 분석 단계에서 시스템 또는 자동차의 영향은 생각하지 않도록 하였다. 해당 컴포넌트에 할당된 요구사항들만 고려하여 후순위 컴포넌트의 요구사항 충족 가능 여부만 분석되도록 하였다. 또한 분석 순서도 데이터 흐름을 기준으로 백-프런트 순서로 분석하도록 하여 후순위 컴포넌트에 대한 영향성 분석이 정확하도록 하였다.
- 제안된 가이드라인을 적용한 프로젝트와 기존의 가이드라인을 따르는 프로젝트의 자원사용에 대한 효율성을 비교하였다. 효율성 비교는 변경되거나 삭제된 안전 메커니즘 개수로 하였다.
대상 데이터
- 하지만 소프트웨어 산업에서 FMEA가 연구되기 시작한 것은 비교적 최근에 진행되었다. 2000년대 초기에 P. L. Goddard, H. Pentti 등이 소프트웨어 FMEA에 대한 기법을 제시하였지만, 분석대상이 매우 작거나 SI 분야에 한정하였다. 해당 기법을 차량용 임베디드 소프트웨어 분야에 적용하기에는 분석의 어려움이 있었다[12,13].
- 본 논문에서는 차량용 임베디드 소프트웨어 FMEA에 적합한 가이드라인을 제안하여 차량용 임베디드 소프트웨어 FMEA 사용상의 효율을 향상시키고자 한다. FMEA 종류 중 프로세스 측면의 FMEA를 제외한 기능측면의 DFMEA(Design FMEA)[10]를 대상으로 한다. 또한 소프트웨어 장애의 원인 중 동작 환경(ECU, RAM 등) 결함, 환경 오류(스케줄링, 지연 등) 등 랜덤 하드웨어 장애는 고려하지 않고 컴포넌트 개발자의 실수가 시스템 기능 장애로 이어지는 소프트웨어 설계 부분의 장애 유형만 다룬다.
- 본 연구에서는 차량용 임베디드 소프트웨어의 특성에 적합한 소프트웨어 FMEA 가이드라인을 제안하는 것을 목표로 한다. 본 논문은 2장 안전 분석 및 소프트웨어 FMEA, 3장 문제점 분석, 4장 가이드라인의 제안, 5장 평가, 그리고 6장 결론으로 구성된다.
- 안전 메커니즘의 개수가 조정되면서 소프트웨어의 개선된 정도를 확인하기 위해 앞서 언급된 5개 컴포넌트의 실행시간을 측정하였다. 실행시간은 TRACE 32 장비를 사용하여 측정하였으며 소프트웨어는 Infineon TC27X core, 16MB RAM의 환경에서 운용되었다.
- 두 가지 프로젝트는 설계 인원을 제외하면 시스템 기능과 안전 목표가 같다. 평가 대상은 Fig. 5에서 언급한 전자식 주차 브레이크 소프트웨어를 구성하는 5개 컴포넌트의 기능 및 도출된 안전 메커니즘에 대해서만 비교 분석한다.
데이터처리
- 제안된 가이드라인을 적용한 프로젝트와 기존의 가이드라인을 따르는 프로젝트의 자원사용에 대한 효율성을 비교하였다. 효율성 비교는 변경되거나 삭제된 안전 메커니즘 개수로 하였다.
성능/효과
- 우리는 브레인스토밍을 통해 개발자의 실수가 발생되는 원인과 심각도의 관계를 고민하였다. 그 결과 분석대상 컴포넌트의 출력 신호와 후순위 컴포넌트에서 사용되는 입력 신호의 관계를 고려하여 심각도 기준을 만드는 것이 타당하다고 판단하였다. 소프트웨어 안전 분석 시 객관성을 가지고 분석할 수 있도록 심각도 기준을 Table 3과 같이 작성하였다.
- 10과 같이 백-프런트 순서로 안전 분석을 진행한다. 그 결과 장애 유형에 대한 후순위 컴포넌트의 영향성이 적절하게 식별되었으며, 안전 메커니즘이 적절하게 도출되면서 안전 메커니즘의 재평가 횟수가 줄어들었다. 안전 메커니즘의 재평가 횟수가 줄어들면서 소프트웨어 FMEA 횟수 역시 줄어들었다.
- 기존의 가이드라인을 사용한 결과와 본 논문에서 제안한 가이드라인을 사용한 결과의 비교에서 제안한 가이드라인을 사용한 결과가 차량용 임베디드 소프트웨어 FMEA에 더욱 효율적인 것을 확인하였다. 안전 목표를 위한 요구사항이 13%, 소프트웨어 FMEA의 횟수가 50%이상 감소되는 것을 확인하였다.
- 본 연구와 연관되는 선행 된 프로젝트에서 차량용 임베디드 소프트웨어 FMEA가 비효율적임을 확인하였다. 비효율적이었던 원인은 불필요한 안전 메커니즘의 개수가 과다했던 것으로 분석되었다.
- 불필요한 안전 메커니즘이 과다했던 원인은 RPN 평가에 시스템에서 사용하던 FMEA 가이드라인을 따른 것과 하위 컴포넌트들을 동시에 안전 분석한 것으로 분석되었다. 해당 원인들로 소프트웨어가 체계적으로 분석되지 못했고 결국 과다한 안전 메커니즘이 만들어졌다.
- 본 연구와 연관되는 선행 된 프로젝트에서 차량용 임베디드 소프트웨어 FMEA가 비효율적임을 확인하였다. 비효율적이었던 원인은 불필요한 안전 메커니즘의 개수가 과다했던 것으로 분석되었다. 본 연구에서는 차량용 임베디드 소프트웨어의 특성에 적합한 소프트웨어 FMEA 가이드라인을 제안하는 것을 목표로 한다.
- 소프트웨어 개발 영역에서 가장 많이 삭제된 안전 메커니즘은 “입출력 값에 대한 범위검사”였다.
- 기존의 가이드라인을 사용한 결과와 본 논문에서 제안한 가이드라인을 사용한 결과의 비교에서 제안한 가이드라인을 사용한 결과가 차량용 임베디드 소프트웨어 FMEA에 더욱 효율적인 것을 확인하였다. 안전 목표를 위한 요구사항이 13%, 소프트웨어 FMEA의 횟수가 50%이상 감소되는 것을 확인하였다. 안전 메커니즘의 조정으로 소프트웨어 실행시간도 개선되었다.
- 기존의 프로젝트에서는 동료검토 이후 심각도 값을 재조정하는 논의가 많았지만, 제안된 심각도 기준을 사용한 경우 심각도 값 재조정을 위한 논의는 없었다. 제안된 심각도 기준을 사용하면 대부분의 개발자가 장애 유형에 대한 심각도를 비슷한 값으로 판단하는 것을 확인하였다.
- 소프트웨어 안전 요구 사항 개수는 감소하였지만, 기술적 안전 요구사항 개수의 변화량은 없었다. 즉 소프트웨어 안전 요구사항의 감소 및 변경에도, 시스템의 안전 목표 충족에 대한 손실은 없다는 것을 확인하였다.
- 평가를 통해 컴포넌트들을 순차적으로 안전 분석하는 것이 동시에 안전 분석하는 것보다 효과적임을 알 수 있었다. 백-프런트 순서로 분석하게 되면 컴포넌트의 분석 시점에 후순위 컴포넌트의 분석은 완료가 된다.
- 분석대상의 장애 유형과 영향성을 체계적으로 분석할 수 있게 되어, 안전 목표가 달성되는 최소한의 안전 메커니즘 설계가 더욱 용이해진다. 후순위로 수행되는 컴포넌트가 반드시 먼저 안전 분석이 완료되어야 하는 단점이 있지만, 전자식 주차 브레이크 시스템의 경우 3회의 안전 분석으로도 만족할 수 있는 결과가 도출되었다. 제안 가이드라인을 사용하면 소프트웨어 FMEA의 자원사용량과 분석 품질을 동시에 개선할 수 있게 된다.
후속연구
- 산업별로 소프트웨어의 안전 목표가 다르기 때문이다. 또한 본 연구에서는 RPN 평가에 사용되는 발생도, 검출도 기준은 제안되지 못했다. 소프트웨어 영역에서 결함의 발견은 리뷰 등의 정적 분석 또는 테스팅 등의 동적 분석 행위가 전부이며, 이러한 소프트웨어의 특성상 발생도와 검출도를 정량적으로 측정하기는 매우 어려운 부분이기 때문이다.
- 안전성 높은 자동차 시스템 개발을 위해서 임베디드 소프트웨어 FMEA 가이드라인을 제안하였으며, 제안된 가이드라인은 차량용 임베디드 소프트웨어에 적절하게 사용될 수 있다고 사료된다. 하지만 본 가이드라인을 타 소프트웨어 산업에서 사용하기에는 문제점이 있다.
- 앞으로 차량용 소프트웨어 산업은 ECU의 제공 기능의 다양화와 AUTOSAR 등의 다양한 플랫폼을 기반으로 빠르게 발전할 것이다. 따라서 소프트웨어 안전 분석 시 지금까지 고려하지 않았던 새로운 잠재적 장애 원인이 나타나게 될 것이다.
- 따라서 소프트웨어 안전 분석 시 지금까지 고려하지 않았던 새로운 잠재적 장애 원인이 나타나게 될 것이다. 자동차 시스템을 연구하는 각 영역에서 소프트웨어 안전 분석의 중요성을 인식하고 영역 간 정보 교류 및 협조 속에 수준 높은 소프트웨어 안전 분석이 가능하기를 기대한다.
- 관련된 연구로 최근 자동차 산업의 기능 안전을 위해 ISO 26262 표준이 제정되었다[1]. 해당 표준에서는 소프트웨어 기능에 대한 문제를 FMEA 등의 안전 분석 기법을 사용하여 아키텍처 설계단계에서 보완하도록 요구한다.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.