The Korean Society Of Automotive Engineers
[ Article ]
Transactions of the Korean Society of Automotive Engineers - Vol. 27, No. 12, pp.965-975
ISSN: 1225-6382 (Print) 2234-0149 (Online)
Print publication date 01 Dec 2019
Received 11 Jun 2019 Revised 20 Sep 2019 Accepted 16 Oct 2019
DOI: https://doi.org/10.7467/KSAE.2019.27.12.965

STAMP 기반의 STPA를 활용한 ISO 26262 개발 단계 별 안전 분석 수행에 관한 연구

도성룡*
상명대학교 산학협력단
A Study on the Performing of Safety Analysis of ISO 26262 Development Phase Applying STPA Based on STAMP
Sungryong Do*
Research and Business Development Foundation, Sangmyung University, Seoul 03016, Korea

Correspondence to: *E-mail: imdsr@smu.ac.kr

Copyright Ⓒ 2019 KSAE / 168-08
This is an Open-Access article distributed under the terms of the Creative Commons Attribution Non-Commercial License(http://creativecommons.org/licenses/by-nc/3.0) which permits unrestricted non-commercial use, distribution, and reproduction in any medium provided the original work is properly cited.

Abstract

Electrical and electronic systems have increased in the automotive industry with stronger regulations on fuel efficiency and safety, along with higher consumer demands for advanced technology. The increase in E/E systems has dramatically heightened the level of complexity in vehicle designs, which also resulted in higher rates of system malfunction. However, most of the automotive parts companies are using safety analysis techniques based on chain of events, such as HAZOP, FMEA and FTA. These methods can be insufficient in analyzing the potential failure of the component interaction that can be found in complicated control systems. This research aims to provide a safety analysis of the ISO 26262 concept, system, and software development phase applying STPA based on STAMP. A case study on the smart key system in vehicles is introduced, and the new method is compared to the other existing methods so as to demonstrate the effectiveness of this study.

Keywords:

STAMP, STPA, Safety constraint, ISO 26262, Hazard identification, Safety analysis

키워드:

시스템 이론 기반의 사고 원인 분석 모델, 시스템 이론 기반의 프로세스 분석, 안전 제약사항, 도로 차량의 기능 안전 국제 표준, 해저드 식별, 안전 분석

1. 서 론

최근 자동차, 철도, 항공, 의료, 원자력 등 모든 산업군에서 전기전자제어시스템이 증가하고 있다. 특히, 자동차 산업은 연비와 안전에 대한 법규가 강화되고, 고객의 첨단 기능 요구 증가에 따라 기존의 기계 중심이 아닌, 전기전자제어시스템 중심으로 급변하고 있다. 하지만 전기전자제어시스템의 증가는 차량 내 설계 복잡도를 급격하게 높였고, 시스템의 전체적인 오동작(Malfunction)을 증가시키고 있다.

일례로, 2009년 도요타의 렉서스 ES350 자동차는 고속도로에서 195 km/h로 급가속하다 가드레일을 넘어 추락하였고, 이 사고로 일가족 4명이 사망하였다. 이 사고와 관련해서 미국의 BARR 그룹은 전기전자제어시스템에 내장된 소프트웨어를 분석하였고, 실험을 통해 소프트웨어가 급발진을 발생시킨 원인임을 증명하였다.

사고의 원인은 소프트웨어 모듈 간에 정보를 주고받을 때, 메모리 영역을 공유하는데, 공유 메모리 영역에서 간섭 현상이 발생하여, ETCS(Electronic Throttle Control System)에 잘못된 명령이 전달되었다. 이로 인해 ETCS는 Throttle을 완전히 열었고, 브레이크의 제동력이 크게 떨어지게 된 것이다. 결국 도요타는 급발진의 원인이 소프트웨어임을 인정하게 되었고, 주가하락, 리콜/수리비, 생산차질 손실 등 약 40조원의 자산가치가 추락하게 되었다. 이처럼 전기전자제어시스템의 오동작에 따른 안전사고가 새로운 이슈로 부각되고 있다.

이러한 시스템의 오동작은 컴포넌트 하나의 단순 고장이 아닌 컴포넌트들 간의 상호작용으로 인한 예상치 못한 오류가 대부분이다. 하지만, 국내 자동차 부품회사들은 여전히 HAZOP, FMEA, FTA 등의 Chain of Event 기반의 안전 분석 기법을 활용하고 있다. Chain of Event 모델은 연속적인 이벤트로 인과관계를 구성하는 신뢰성 이론에 기반을 두고 있으며, 사고가 발생하지 않도록 하기 위해서 시스템을 실패하게 한 컴포넌트를 대체한다면 사고 예방이 가능하다는 이론이다.1)

하지만, 해저드는 컴포넌트 고장뿐만 아니라 컴포넌트 간의 상호작용 및 외부 환경 요인의 변화로 인해 새롭게 발생하기도 하므로, 위의 기법들은 복잡한 제어 소프트웨어에 잠재되어 있는 해저드 분석에 있어 한계가 존재한다.

이러한 점을 극복하기 위해서 MIT의 Leveson 교수는 STAMP 모델 기반의 STPA 기법을 제안하였다.2) STPA 기법은 시스템 컴포넌트들 간의 상호작용에서 발생하는 UCA를 파악하고, 원인 시나리오를 종합적으로 분석함으로써, 안전 요구사항을 도출 할 수 있다는 장점이 있다.

이에 본 연구에서는 STPA 기반의 ISO 26262 컨셉/시스템/소프트웨어 개발 단계에서 안전 분석을 수행하기 위한 방안을 제시한다. 이를 위해, 시스템의 동작 과정 명세에 유용한 UseCase 기술서와 STPA UCA 식별 단계를 적용한 해저드 도출 방안 및 FMEA/FTA와 STPA Causal Factor 도출 단계 기반의 원인분석 방안을 제시한다. 또한 본 연구의 효용성을 검증하기 위해 차량의 스마트키 시스템 사례를 제시하고, 기존 기법과의 비교 결과를 제시한다.

제2장 이론 연구에서는 ISO 26262 기능 안전 표준에 대해서 기술한다. 또한 Chain of Event 모델에 기반한 안전 분석 기법인 HAZOP, FMEA, FTA와 시스템 이론에 기반한 STPA 안전 분석 기법에 대해서 서술한다. 제3장은 해저드 식별 및 안전 분석 관련 기존 연구를 살펴보고, 이 연구들의 한계점을 기술한다. 제4장에서는 기존 연구의 한계점을 토대로 본 연구의 목표를 수립한다. 또한 본 연구에서 제안하는 프로세스를 설명한다. 제5장에서는 4장에서 정의한 프로세스를 기반으로 스마트키 시스템에 적용한 사례 및 타 기법과의 비교 결과를 서술한다. 제6장에서는 본 연구의 기여점과 한계점을 기술하고, 향후 계획을 서술한다.


2. 이론 연구

2.1 ISO 26262 도로 차량의 기능 안전 국제 표준

ISO 26262는 자동차에 탑재되는 전기전자시스템의 오동작과 해저드로 인한 사고를 방지하기 위해 ISO에서 2011년에 제정한 자동차 분야의 기능 안전 국제표준으로, 공식 명칭은 Road vehicles - Functional safety 이다.3) ISO 26262는 전기전자제어시스템을 위한 산업 공통 기능 안전 표준인 IEC 61508을 기반으로 자동차 분야에 특화 시켰으며, 2018년 2nd 버전으로 개정되었다. 표준의 주요 내용은 다음과 같다.

  • 1) 전기전자시스템의 컨셉개발부터 제품개발/생산/운영까지의 생명주기
  • 2) 시스템, HW/SW 구현/검증 절차 및 기법
  • 3) ASIL 수준 결정 및 기법 별 적용 지침

특히, Part 3 - Part 7까지의 ISO 26262 개발 생명주기는 Fig. 1과 같이 컨셉 개발, 제품(시스템, 하드웨어, 소프트웨어) 개발 그리고 생산/운용 단계로 구성되어 있다.4)

Fig. 1

Development lifecycle of ISO 26262

2.2 Chain of Event 모델 기반의 안전 분석 기법

Chain of Event 모델은 과거 기계 중심의 단순한시스템에서 컴포넌트들의 연속적인 Failure Event들로 인해 사고가 발생한다는 이론이다.5,6) 예를 들어, Fig. 2의 브레이크 시스템에서 브레이크 제어기가 고장 났다면, 이를 대체하는 제어기를 설계에 반영함으로써, 사고를 예방할 수 있다는 개념이다.

Fig. 2

Example of chain of event model

대표적인 Chain of Event 모델 기반의 안전 분석 기법은 HAZOP, FMEA, FTA 등이 있다.

2.3 STAMP 기반의 안전 분석 기법 : STPA

Chain of Event 모델은 기계 장치가 주를 이루던 시대에 적합한 방식이다. 그 당시 시스템들은 기계장치들로만 이루어져 있어 물리적으로 분리가 되고, 독립적으로 분석이 가능하였다. 또한 컴포넌트들 간에 상대적으로 단순한 상호작용만 존재하였기에, 시스템 설계 오류들은 대부분의 테스팅에 의해 파악되어 발견되는 즉시 제거가 가능하였다. 하지만 현재의 전기전자제어시스템은 다양한 하드웨어와 제어 소프트웨어로 구성되어 있어 설계가 복잡해짐에 따라, 더 이상 테스팅 만으로는 전수 검사가 불가능해졌다.2)

이러한 점을 극복하기 위해서 MIT의 Leveson 교수는 STAMP 모델 기반의 STPA 안전 분석 기법을 제안하였다.2)

STAMP는 사고의 인과 관계를 분석하는 모델로서, 계층형 제어구조(Hierarchical Safety Control Structure) 안전 제약사항(Safety Constraint) 그리고 프로세스 모델(Process Model)이라는 세 가지 개념에 기반을 두고 있다.

계층형 제어구조는 Fig. 3과 같이 시스템의 개발과 운영에 관여하는 모든 요소들을 포함함으로써 컴포넌트 전체가 상호작용하는 하나의 커다란 시스템으로 표현한다. 즉, 시스템을 계층적으로 이해하되 계층 간에 상호 영향을 미치는 요소를 보다 종합적인 관점에서 분석할 것을 요구한다. 따라서 STAMP에 기반의 STPA 분석을 수행하면, 시스템, 하드웨어, 소프트웨어뿐만 아니라, 사람, 정책, 개발/운영 프로세스까지 해저드를 도출할 수 있다.

Fig. 3

Hierarchical safety control structure

안전 제약사항은 안전을 보장하기 위해 시스템이 반드시 준수해야 하는 요구사항을 의미한다. STAMP에서는 사고가 특정 기능의 오동작 또는 컴포넌트의 고장이 아니라, 안전 제약사항을 수행하지 않아 발생한 것으로 본다.

프로세스 모델은 Controller가 제어하는 Control Action을 결정하는데 필요한 데이터로, 시스템 상태 변수, 제어 변수, 제어 조건 등이 해당된다. 예를 들어, 열차 제어 시스템의 Open Door라는 Control Action을 수행하기 위해서, 프로세스 모델은 Door Position, Train Position, Door State 등이 될 수 있다. Controller 내의 프로세스 모델은 다양한 형태의 피드백을 통해서 그 값이 변경되기 때문에, 누락되거나 부정확한 경우, 부적절한 Control Action이 수행될 수 있으므로, 정확한 프로세스 모델을 도출해야 한다.

STAMP에 기반한 해저드 분석 기법인 STPA는 사고 정의에서 시작하여, Causal Scenario 도출을 수행하는 하향식 분석 방법으로 수행 단계는 다음과 같다.1)

  • 1) 사고 및 해저드 정의 : 인명 피해, 환경 오염, 재산 손실 등 어떤 종류의 사고를 예방하기 위함인지 결정하고, 분석 대상이 되는 시스템의 범위를 결정한다. 세부 단계는 사고 정의, 시스템 수준의 해저드 정의, 시스템 수준의 안전 제약사항 도출로 구분된다.
  • 2) 대상 시스템의 제어 구조도 작성 : 대상 시스템의 구성요소들과 시스템의 흐름을 파악하기 위해 제어 구조도를 작성한다. 제어 구조도는 Controller, Sensor, Actuator, Controlled Process로 구성된다.
  • 3) Control Action으로부터 UCA 식별 : Controller의 Control Action이 잘못 수행된 경우를 식별하기 위해 Not Provided, Providing Causes, Too Late or Early, Too Soon or Long 가이드워드를 적용한다.
  • 4) Causal Factor 도출 : UCA가 발생한 원인 시나리오를 도출하기 위해, Fig. 4와 같이 외부입력 제어 또는 정보가 잘못되거나 없어지는 경우, 제어 알고리즘이 올바르지 않은 경우, 정보를 제공하는 시스템/센서가 잘못된 경우, 수행 대상이 실패하거나 부적절 하게 동작하는 경우에 대해 분석한다.
Fig. 4

Classification of causal factor

STPA는 제어 구조도를 기반으로 종합적인 관점에서 해저드 분석을 수행하고, 다양한 Causal Scenario 기반의 원인 분석을 통해, 안전 제약사항 및 안전 요구사항을 도출 할 수 있는 장점이 있다. 이에 해외 자동차, 철도, 항공, 원자력 등 안전필수시스템 분야를 중심으로 STPA를 적용한 사례가 발표되고 있다. 또한 STPA는 ISO/PAS 21448: Safety of the Intended Functionality에 언급되었다.7) 또한 일본의 차량 시스템 표준화 단체인 JASPAR에서도 자율주행차의 해저드 분석 시, STPA를 적용하겠다는 계획을 발표하였다. 최근에는 국내 자동차 전장업체들도 STPA 적용을 고려하고 있다.


3. 관련 연구

해저드 식별 및 안전 분석과 관련해서 PHA, HAZOP, FMEA, FTA, STPA 등의 기법을 기반으로 다양한 연구가 진행되고 있다. 본 연구와 관련된 중요한 기존 관련 연구를 다음의 조건에 의해서 선정하였다.

  • 1) 검색 사이트 : Google Scholar
  • 2) 검색 키워드 : Hazard Identification, Hazard Analysis, Safety Analysis, ISO 26262, PHA, HAZOP, FMEA, FTA, STPA
  • 3) 검색 기간 : 2005년 이후 (중요 연구는 과거 자료도 포함)
  • 4) 관련 도메인 : 자동차, 철도, 원자력 등의 안전필수시스템 분야

이장수 등8)은 2003년 연구에서 HAZOP을 원자력 분야의 소프트웨어 요구사항에 대한 안전 분석에 활용하기 위해 소프트웨어 HAZOP 절차, 지침, 체크리스트를 개발하였다. 해저드 식별을 위한 HAZOP 적용 방안을 제시하였지만, 시스템 동작 과정상의 해저드를 식별하지 못 하고, 적용 사례를 제시하지 못한 한계가 있다.

Czerny 등9)은 2005년 연구에서 소프트웨어 안전 개발 생명주기를 정의하였다. 컨셉 단계에서 PHA를 수행하여 식별된 해저드를 회피하기 위한 소프트웨어 안전 요구사항 정의 시, FTTI 개념을 도입하였다. 또한 식별된 소프트웨어 안전 요구사항을 검토하기 위한 안전 분석 방법으로 FMEA와 FTA를 적용하였다. 해저드 식별을 위한 PHA 적용 방안을 제시하였지만, 시스템 동작 과정상의 해저드를 식별하지 못 하고, 자동차 임베디드 시스템을 대상으로 포괄적인 적용 방안만 제시한 한계가 있다.

Aljazzar 등10)은 2009년 연구에서 기존 FMEA의 단점을 보완한 통계적 확률 기반의 FMEA 기법을 제시하였다. 시스템의 해저드 발생 조건을 정의하고, Sensor, Micro Controller Unit, Connection 등의 컴포넌트 별 정량적인 Failure 값으로부터 시스템 전체의 Failure 값을 도출하였다. 에어백 시스템 적용 사례를 제시하였지만, 해저드를 식별하는 과정에 대해서는 제시하지 못하고, 소프트웨어 부문에 대한 방안을 제시하지 못한 한계가 있다.

황종규 등11)은 2010년 연구에서 열차제어시스템의 해저드 식별을 위해 HAZOP 기반의 특화된 방안을 제시하였다. 기존 HAZOP의 가이드워드에 Interface, Time, Action 등의 매개변수 개념을 추가하였고, 열차제어시스템에 적용한 사례를 제시하였다. 시스템 및 소프트웨어에 대한 해저드 식별 방안을 제시하였지만, 시스템 동작 과정상의 해저드를 식별하지 못한 한계가 있다.

Mader 등12)은 2011년 연구에서 개발 초기의 해저드 식별을 위해 PHA를 적용하고, 안전 요구사항의 검증을 위해 FMEA와 FTA 적용 방안을 제시하였다. 또한 친환경 전기차 제어 시스템 적용 사례를 제시하였지만, 소프트웨어 부문에 대한 적용 방안을 제시하지 못한 한계가 있다.

권형주 등13)은 2013년 연구에서 차량 내 전기전자조향시스템의 해저드 식별을 위해 HARA 단계에서 시스템 정의를 기반으로 HAZOP을 적용하였다. 차량 내 전기전자조향시스템을 대상으로 HARA 단계에서 안전 목표를 정의하고, 리스크 완화 전략을 확인하기 위해서 해저드 테스트를 수행하였다. 해저드 식별을 위한 HAZOP 적용 방안을 제시하였지만, 시스템 동작 과정상의 해저드를 식별하지 못한 한계가 있다.

Sundaram과 Hartfelder14)은 2013년 연구에서 미국의 GM 자동차 제조업체의 System Safety Engineering 프로세스 상에 STPA를 적용하는 방안을 제시하였다. 기존의 시스템 Safety Engineering 프로세스에서 HAZOP의 가이드워드로부터 오동작(Malfunction)을 도출한 뒤, PHA를 적용함으로써 초기 해저드로 식별하였다. 식별된 해저드를 기반으로 STPA를 적용하여 Safety Constraints와 Causal Factor를 식별하였다. 기존 System Safety Engineering 프로세스에 STPA 적용 기법을 제시하였지만, FMEA/FTA 기법과의 정성적 측면에서만 비교 분석이 수행된 한계가 있다.

Hommes15)는 2015년 연구에서 ISO 26262 컨셉 개발 단계 시에 STPA를 적용하는 방안을 제시하였다. 기존 HAZOP 기반의 해저드 분석과 FMEA 기반의 안전 분석 에 STPA를 적용하는 방안을 제시하였다. STPA 기반의 원인 분석을 위해 Causal Factor로서 Controller, Sensor, Actuator, Controller Process, Communication Links, Unsafe Interaction with Other Vehicle System 등을 제시하였다. 또한 Accelerator Control 및 Electronic Throttle Controls 시스템에 대한 사례를 제시하였다. ISO 26262 컨셉 개발 단계 시에 STPA 적용 방안을 제시하였으나, 기존 기법과의 비교 분석을 수행하지 못한 한계가 있다.

Thomas16)는 2015년 연구에서 차량의 제어시스템 개발 시, ISO 26262 개발 프로세스 내에서 STPA를 반복적으로 적용하는 방법을 제시하였다. Iteration 1 단계에서는 Preliminary Design으로부터 STPA를 간략하게 적용한다. Iteration 2 단계에서는 Iteration 1 단계의 Preliminary Design을 구체화하고, STPA를 추가 적용한다. Iteration 1, 2 단계는 제어구조도의 구체화 정도에 차이가 있다. 즉, Iteration 2 단계에서는 컴포넌트 간의 상호작용 경로를 구체적으로 식별할 수 있고, 이로 인한 더 많은 해저드를 식별할 수 있다. STPA 기법의 반복적 적용 방안을 제시하였으나, 기존 기법과의 비교 분석을 수행하지 못한 한계가 있다.


4. 연구 목표 및 제안 프로세스

4.1 연구 목표

해저드 식별과 안전 분석 관련 기존 연구를 분석한 결과 아래와 같은 한계점을 도출하였다.

  • 1) 시스템 동작 과정 상의 해저드를 충분히 식별하지 못함 : PHA, HAZOP, STPA 기반의 해저드 식별 시, 시스템의 최상위 기능으로부터 해저드를 식별하기 때문에, 시스템 컴포넌트들의 동작 과정 상의 해저드를 충분히 식별하지 못함
  • 2) 컴포넌트들의 상호작용으로 발생한 Failure의 원인분석 미흡 : Chain of Event에 기반한 FMEA, FTA 등의 기법은 시스템 간의 복잡한 상호작용에 따른 Failure를 다루기에 부족
  • 3) 소프트웨어 개발 부문에 대한 적용 연구가 부족 : 소프트웨어의 역할이 중요함에도, ISO 26262의 아이템 수준에만 STPA 기법이 주로 적용되고 있으며, 소프트웨어 적용 연구가 부족
  • 4) 타 기법과의 비교연구가 부족 : PHA, HAZOP, FMEA, FTA, STPA 등 다양한 해저드 식별 및 안전 분석 기법을 기존 프로세스에 적용하는 방법과 사례를 제시하고 있지만, 기법들 간의 비교를 통한 효용성 검증 결과를 제시한 연구가 부족

이에 본 연구에서는 기존 연구의 한계점을 보완하기 위해서 STPA를 활용한 ISO 26262 컨셉, 시스템, 소프트웨어 개발 단계 별 안전 분석 수행 방안을 제시한다. 세부 연구 목표는 다음과 같다.

  • 목표 1) UseCase와 STPA 기반의 해저드 식별
  • 목표 2) FMEA/FTA와 STPA 기반의 원인 분석

4.2 제안 프로세스

본 연구는 Fig. 5와 같이 ISO 26262 컨셉/시스템/소프트웨어 안전 요구사항 개발단계에서 STPA 기반의 안전 분석 프로세스를 제시한다.

Fig. 5

Safety analysis process of ISO 26262 concept/system/software development phase

ISO 26262 컨셉/시스템/소프트웨어 안전 요구사항 개발 단계와 제안 프로세스의 안전 분석 활동과의 매핑은 Table 1과 같다.

Mapping of ISO 26262 requirement development phase and safety analysis process


5. 스마트키 시스템 적용 사례

스마트키 시스템은 키와 키 홀을 이용하지 않고, 무선통신을 이용하여 운전자 인증 및 차량 도어 잠금/해제하고, 시동을 제어한다. 즉, 운전자는 스마트키를 지닌 채 편리하게 도어 및 트렁크를 열 수 있다. 또한 차량에 탑승한 후에는 스마트키 제어기가 운전자의 스마트키를 인증한 후, 엔진제어 시스템과 통신하여 엔진에 시동이 걸리도록 한다. 스마트키 시스템은 Fig. 6과 같이 스마트키, 스마트키 제어기, 시동버튼, 전자조향 잠금장치, LF 안테나, RF 수신기로 구성된다.

Fig. 6

Structure of smartkey system

5.1 컨셉 개발 단계

첫번째 단계로, 스마트키 시스템(아이템)의 기능을 정의하기 위해, Fig. 7과 같이 UseCase Diagram 형태로 작성한다. 주요 Actor로 운전자, 변속기 제어시스템, 엔진제어 시스템, 시동 릴레이 제어 장치를 식별하였다. 또한 기능 그룹으로 Door 제어, 시동 그리고 편의 기능을 도출하였다. 본 연구에서는 안전 기능과 관련된 시동 기능에 대한 사례를 제시한다. 스마트키 시스템의 시동 기능 그룹은 스마트키 인증, 조향잠금 장치제어, 스마트키/엔진통신, 엔진시동 상태제어 UseCase로 구성되어 있다.

Fig. 7

Usecase diagram of smartkey system

또한, 스마트키 시스템의 예비 아키텍처를 설계하기 위해, Fig. 8과 같이 STPA의 Control Structure를 활용한다. 스마트키 시스템의 시동 기능 그룹에 포함되는 4가지 UseCase에 대해서 Fig. 8과 같이, 화살표의 색상을 구분하여 명시하였다. 스마트키 인증은 빨간색, 조향잠금 장치제어는 파란색, 스마트키/엔진통신은 검정색, 엔진시동 상태제어는 녹색으로 표시하였다.

Fig. 8

Preliminary architecture of smartkey system

두번째 단계로, 스마트키 시스템(아이템)의 시동기능 그룹 UseCase 별 정상 동작 흐름에 STPA 가이드워드를 적용함으로써, 비정상 동작 흐름인 UCA를 식별한다. 예를 들어, 정상 동작 흐름이 전자 조향 잠금 장치로 Unlock 신호 송신일 때, UCA는 전자 조향 잠금 장치로 Unlock 신호 미송신, 전자 조향 잠금 장치로 Lock 신호 송신, 전자 조향 잠금 장치로 Unlock 신호 늦게/빨리 송신 등이 있을 수 있다. 이처럼 시동 기능 그룹의 25개의 동작 흐름에 대해서 88개의 UCA를 도출하였다.

세번째 단계로, 차량 수준 해저드 식별 및 Safety Constraints 정의를 위해, 도출한 UCA를 기반으로 도로 위 주행 상황에서 해저드를 식별하였고, 해저드를 예방하기 위한 Safety Constraints를 정의하였다. 예를 들어, 전자 조향 잠금 장치 Lock 상태 유지로 조향 불가라는 해저드에 대해서 시동릴레이제어장치가 ACC/IGN/Start인 경우, 전자 조향 잠금 장치는 Unlock 상태이어야 한다라는 Safety Constraints를 정의하였다. 이처럼 시동 기능 그룹에 대해서 13개의 해저드와 Safety Constraints를 도출할 수 있었다.

네번째 단계로, 아이템에 대한 안전 분석을 위해, 식별된 해저드에 대해서 FMEA/FTA와 STPA의 Causal Factor 기반의 원인 분석을 수행한다. 예를 들어, 전자 조향 잠금 장치 Lock 상태 유지로 조향 불가 해저드에 대한 안전 분석 결과는 Table 2와 같다.

Example of safety analysis

다섯 번째 단계로, 아이템의 안전 요구사항을 정의한다. 세번째 단계에서 도출한 Safety Constraints에 대해서 안전 분석 결과를 반영하여 최종적으로 안전 요구사항을 정의한다. 예를 들어, 전자 조향 잠금 장치 Lock 상태 유지로 조향 불가 해저드에 대한 안전 요구사항은 다음과 같다.

  • 1) 시동릴레이제어장치가 ACC/IGN/Start인 경우, 조향 잠금장치는 Unlock 상태이어야 한다.
  • 2) 스마트키 제어기는 변속 P/R/N/D 신호를 정확히 구분해야 한다.
  • 3) 스마트키 제어기는 배터리 관리시스템의 전원 On/Off 신호를 정확히 구분해야 한다.
  • 4) 스마트키 제어기는 조향 Lock/Unlock 신호를 정확히 송신해야 한다.
  • 5) 스마트키 제어기는 전자조향잠금장치의 Lock/Unlock 상태를 모니터링 해야 한다.
  • 6) 스마트키 제어기는 전자조향잠금장치의 고장을 모니터링 해야 한다.
  • 7) 변속기 제어시스템은 변속 P/R/N/D를 정확히 구분해야 한다.
  • 8) 배터리 관리시스템은 전원 On/Off 신호를 정확히 송신해야 한다.

5.2 시스템 개발 단계

컨셉 개발 단계와 마찬가지로 Fig. 4에 따라 스마트키 제어기를 대상으로 시스템 수준의 안전 분석 활동을 수행한다. 최종적으로 도출한 시스템 안전 요구사항은 다음과 같다.

  • 1) 시동제어모듈은 브레이크 On, 변속 P단 On, 시동버튼 On, 전원 On 입력신호가 수신되었는지 모니터링 되어야 한다.
  • 2) 시동제어모듈은 전자조향 잠금제어모듈, 엔진제어 시스템모듈, 시동릴레이 제어모듈의 On신호가 수신되었는지 모니터링 해야 한다.
  • 3) 시동제어모듈은 브레이크 On, 변속 P단 On, 시동버튼 On, 전원 On 입력신호를 처리해야 한다.
  • 4) 시동제어모듈은 전자조향 잠금제어 모듈이 조향 Unlock 신호가 수신되었는지 모니터링해야 한다.
  • 5) 시동제어모듈은 전자조향 잠금제어 모듈의 고장을 모니터링 해야 한다.

5.3 소프트웨어 개발 단계

컨셉 및 시스템 개발 단계와 마찬가지로 Fig. 4에 따라 스마트키 제어기의 시동제어 모듈을 대상으로 소프트웨어 수준의 안전 분석 활동을 수행한다. 최종적으로 도출한 소프트웨어 안전 요구사항은 다음과 같다.

  • 1) 모니터링 SW모듈은 시동입력 SW모듈이 시동, 브레이크, 변속 P단, 전원데이터 수신을 확인하고, 하나라도 미수신시 재송신 요청해야 한다.
  • 2) 잠금제어 입력 SW모듈은 잠금 Unlock 데이터를 송신해야 한다.
  • 3) 잠금제어 입력 SW모듈은 잠금 Unlock 인증 데이터를 송신해야 한다.
  • 4) 모니터링 SW모듈은 릴레이제어처리 SW모듈이 IGN/Start인 경우, 잠금제어 처리 SW모듈이 Unlock 되었는지 모니터링 해야 한다.
  • 5) 모니터링 SW모듈은 잠금제어 처리 SW모듈의 처리결과가 Lock/Unlock인지 모니터링 해야 한다.
  • 6) 모니터링 SW모듈은 전자조향 잠금제어 SW모듈의 처리현황을 모니터링 해야 한다.
  • 7) 잠금제어 처리 SW모듈은 변속 P단 On, 전원 On 데이터의 Lock/Unlock을 제어해야 한다.
  • 8) 잠금제어 처리 SW모듈은 잠금 Lock/Unlock 데이터를 처리 결과를 송신해야 한다.

5.4 연구 결과 분석

연구 결과 분석은 연구 목표 별 타 분석 기법과의 비교 결과를 제시한다.

  • 1) 목표 : UseCase와 STPA 기반의 해저드 식별
    연구목표 1에 대해서 효과를 비교한 결과 Fig. 9와 같다. 본 연구에서 제시한 UseCase 기술서와 STPA를 기반으로 해저드를 식별한 결과, 44개의 해저드가 식별된 것을 확인할 수 있었다. 반면, 기존 HAZOP 기법을 적용했을 때에는 9개의 해저드를 식별할 수 있었다.
    UseCase 기술서와 STPA 기반의 해저드 식별 방법의 정성적인 연구 효과는 다음과 같다.
    ① UseCase 기술서를 통해 시스템 간 상호작용을 상세하게 명세 가능
    ② 시스템 동작 과정 상의 해저드 식별이 가능
    ③ UCA 가이드워드를 통해 체계적 접근 가능
  • 2) 목표 : FMEA/FTA와 STPA 기반의 원인분석
    연구목표 2에 대해서 효과를 비교한 결과 Fig. 10과 같다. 본 연구에서 제시한 FMEA/FTA와 STPA를 적용했을 때, 42개의 원인이 분석된 것을 확인할 수 있었다. 반면, 기존 FMEA/FTA 기법을 적용 시에는 13개의 원인을 분석할 수 있었다. 즉, STPA 적용을 통해 29개의 원인을 추가 식별할 수 있었다.
    FMEA/FTA와 STPA 기반의 원인 분석 방법의 정성적인 연구 효과는 다음과 같다.
    ① 시스템 부분이 아닌 전체적인 측면에서 원인 분석 가능
    ② 시스템 상호작용 과정 상의 추가 원인 도출 가능
    ③ Causal Factor 기준을 통해 체계적 접근 가능
Fig. 9

Comparison result for research objective 1

Fig. 10

Comparison result for research objective 2

최종적으로 기존 방법보다 더 구체적이고, 많은 원인과 아이템/시스템/소프트웨어 안전 요구사항을 도출할 수 있었다. 해저드부터 최종 소프트웨어 안전 요구사항까지 식별한 일부 예시는 다음과 같다.

  • 1) 해저드 : 조향잠금장치 Lock 상태유지로 조향불가
  • 2) 원인 : 변속 P/R/N/D 구분 알고리즘이 잘못됨
  • 3) 아이템 안전 요구사항
    : 스마트키 제어기는 변속 P/R/N/D 신호를 정확히 구분해야 한다.
  • 4) 시스템 안전 요구사항
    ① SW 시동제어 모듈은 변속 P단 On 신호가 수신되었는지 모니터링 되어야 한다.
    ② SW 시동제어 모듈은 변속 P단 On, 전원 On 입력 신호를 처리해야 한다.
  • 5) 소프트웨어 안전 요구사항
    ① 모니터링 모듈은 시동 입력 모듈의 변속 P단, 전원 On 데이터 수신을 확인하고, 미 수신시 재송 요청해야 한다.
    ② 잠금제어 입력모듈은 잠금 Unlock 데이터를 송신해야 한다.
    ③ 잠금제어 입력모듈은 잠금 Unlock 인증 데이터를 송신해야 한다.
    ④ 잠금제어 처리모듈은 변속 P단 On, 전원 On 데이터의 Lock/Unlock을 제어해야 한다.
    ⑤ 잠금제어 처리모듈은 잠금 Lock/Unlock 데이터 처리 결과를 송신해야 한다.
    ⑥ 모니터링 모듈은 잠금제어 처리모듈의 처리결과가 Lock/Unlock인지 모니터링 해야 한다.

6. 결 론

기존에는 사고의 원인을 시스템의 컴포넌트 고장에 초점을 두고, HAZOP, FMEA, FTA 등의 기법이 활용되어 왔다. 하지만, 실제로 많은 사고가 시스템 컴포넌트의 단순 고장만이 아니라, 시스템의 상호작용 속에서 더 많은 원인이 있다는 것을 발견하였다.

이에 최근에는 소프트웨어 결함을 포함한 디자인 에러, 컴포넌트 상호작용 에러 등을 다루는 STPA 안전 분석 기법이 다양한 산업군에서 활용되고 있다. 실제, 2012년도부터 진행되고 있는 미국 MIT 대학의 STAMP Workshop에서는 전 세계 수많은 국가의 다양한 산업군에서 STPA를 적용한 사례가 발표되고 있다.

하지만, 기존에 STPA 관련 연구들을 검토한 결과, 자동차 전기전자제어시스템을 대상으로 STPA를 적용한 연구가 부족하였으며, 특히, 소프트웨어에 적용한 사례가 부족하였다. 이에 본 연구에서는 STPA 기반의 ISO 26262 컨셉/시스템/소프트웨어 안전 분석 체계를 수립하였다. 또한 자동차 부문의 스마트키 시스템 사례에 적용하였으며, 기존 HAZOP, FMEA, FTA 기법과의 비교 결과를 제시하였다. 본 연구를 통해 다음의 효과를 확인할 수 있었다.

  • 1) UseCase 기술서를 통해 시스템 간 상호작용을 상세화할 수 있으며, 그 결과로부터 시스템 동작 과정 상의 구체적인 해저드 식별이 가능하다. 구체적으로 식별된 해저드는 원인분석 단계에 활용이 가능하다.
  • 2) 시스템의 부분이 아닌 전체측면에서 원인 분석이 가능하다. 즉, 시스템 상호작용 과정상의 잠재된 추가 원인 도출이 가능하다.

그러므로 본 연구를 적용하는 조직에서는 개발 초기에 시스템 내 잠재하고 있는 더 많은 해저드와 원인 그리고 안전 요구사항 도출이 가능하며, 결과적으로 시스템 품질 향상 및 품질 비용을 줄일 수 있을 것으로 기대한다.

하지만 본 연구는 자동차의 시스템 중, 스마트키 시스템 사례만 적용하였다. 또한 HAZOP, FMEA, FTA 등 일부 안전 분석 기법과의 비교만 수행하였다.

최근에는 인공지능 등의 기술을 활용한 ADAS 및 자율주행 시스템에 대한 안전성 확보가 중요해 지고 있다.17) 이에 본 연구 효과의 객관성을 확보하기 위해, LKAS (Lane Keeping Assistance System), ACCS(Advanced Cruise Control System) 등의 ADAS 시스템이 탑재된 다양한 차종으로 확대하고, FHA(Functional Hazard Analysis), SWHA (SoftWare Hazard Analysis) 등 타 기법과의 비교를 수행할 계획이다. 또한 최근 사이버 보안의 위협으로 인한 안전성 위배에 대한 연구 동향에 맞춰, STPA-sec을 통합한 연구를 수행할 예정이다.

Nomenclature

ASIL : automotive safety integrity level
FMEA : failure mode and effects analysis
FHA : functional hazard analysis
FTA : fault tree analysis
FTTI : fault tolerant time interval
HARA : hazard analysis and risk assessment
HAZOP : hazard and operability study
JASPAR : japan automotive software platform and architecture
PHA : preliminary hazard analysis
STAMP : system-theoretic accident model and processes
STPA : system theoretic process analysis
SWHA : software hazard analysis
UCA : unsafe control action

References

  • N. G. Leveson and J. P. Thomas, STPA Handbook, Non-commercial, 2018.
  • N. G. Leveson, Engineering a Safer World: Systems Thinking Applied to Safety, The MIT Press, Cambridge, 2011. [https://doi.org/10.7551/mitpress/8179.001.0001]
  • ISO Standard, ISO 26262 Road Vehicles - Functional Safety, 2018.
  • S. Lee and S. Shin, “Software Fault Injection Test Methodology for the Software Verification of ISO 26262 Standards-based,” Transactions of KSAE, Vol.22, No.3, pp.68-74, 2014. [https://doi.org/10.7467/KSAE.2014.22.3.068]
  • R. L. Benner, “Accident Investigations: Multilinear Events Sequencing Methods,” Journal of Safety Research, Vol.7, No.2, pp.67-73, 1975.
  • N. G. Leveson, “A New Accident Model for Engineering Safer Systems,” Safety Science, Vol.42, No.4, pp.237-270, 2004. [https://doi.org/10.1016/S0925-7535(03)00047-X]
  • ISO Standard, ISO/PAS 21448 - Road vehicles - Safety Of The Intended Functionality, 2019.
  • J. S. Lee, S. W. Cheon, H. S. Sohn, K. H. Cha, J. Y. Kim, Y. J. Lee and K. C. Kwon, “HAZOP Method for Safety Analysis of Software Requirements Specification,” Proceedings of the Korean Nuclear Society Spring Meeting, pp.87-97, 2003.
  • B. J. Czerny, J. G. D’Ambrosio, B. T. Murray and P. Sundaram, “Effective Application of Software Safety Techniques for Automotive Embedded Control Systems,” SAE Technical Paper Series, SAE World Congress, 2005. [https://doi.org/10.4271/2005-01-0785]
  • H. Aljazzar, M. Fischer, L. Grunske, M. Kuntz, F. Leitner-Fischer and S. Leue, “Safety Analysis of an Airbag System Using Probabilistic FMEA and Probabilistic Counterexamples,” 6th International Conference on the Quantitative Evaluation of Systems, pp. 299-308, 2009. [https://doi.org/10.1109/QEST.2009.8]
  • J. G. Hwang, H. J. Jo, C. H. Han, W. S. Cho, J. Ahn and D. M. Ha, “A Study on the HAZOP-KR for Hazard Analysis of Train Control Systems,” Journal of the Korean Society for Railway, Vol.13, No.4, pp.396-403, 2010.
  • R. Mader, E. Armengaud, A. Leitner, C. Kreiner, Q. Bourrouilh, G. Grießnig, C. Steger and R. Weiß, “Computer-Aided PHA, FTA and FMEA for Automotive Embedded Systems,” International Conference on Computer Safety, Reliability, and Security, pp.113-127, 2011. [https://doi.org/10.1007/978-3-642-24270-0_9]
  • H. Kwon, R. Itabashi-Campbell and K. McLaughlin, “ISO26262 Application to Electric Steering Development with a Focus on Hazard Analysis,” SysCon 2013 - 7th Annual IEEE International Systems Conference, pp.655-661, 2013.
  • P. Sundaram and D. Hartfelder, Compatibility of STPA with GM System Safety Engineering Process, 2013.
  • V. E. Hommes, “Safety Analysis Approaches for Automotive Electronic Control Systems,” Society of Automotive Engineers’ Meeting, 2015.
  • J. P. Thomas, Iterative Application of STPA for an Automotive System, STAMP Workshop Presentation, 2015.
  • D. R. Ahn, S. G. Shin, K. H. Park, I. S. Choi and H. K. Lee, “Functional Safety Concept Design and Verification for Longitudinal Driving Assistance System of an Autonomous Vehicle,” Transactions of KSAE, Vol.26, No.2, pp.149-158, 2018. [https://doi.org/10.7467/KSAE.2018.26.2.149]

Fig. 1

Fig. 1
Development lifecycle of ISO 26262

Fig. 2

Fig. 2
Example of chain of event model

Fig. 3

Fig. 3
Hierarchical safety control structure

Fig. 4

Fig. 4
Classification of causal factor

Fig. 5

Fig. 5
Safety analysis process of ISO 26262 concept/system/software development phase

Fig. 6

Fig. 6
Structure of smartkey system

Fig. 7

Fig. 7
Usecase diagram of smartkey system

Fig. 8

Fig. 8
Preliminary architecture of smartkey system

Fig. 9

Fig. 9
Comparison result for research objective 1

Fig. 10

Fig. 10
Comparison result for research objective 2

Table 1

Mapping of ISO 26262 requirement development phase and safety analysis process

ISO 26262 Requirement development phase Safety analysis process
Part 3.
Concept Dev.
Item definition Define item function and design preliminary architecture
Identify task flow of item function
HARA Identify hazard and define safety constraints in vehicle level
Functional safety concept Perform safety analysis in item level
Define safety requirement in item level
Part 4.
System Dev.
System functional requirement definition Define system function and design preliminary architecture
Identify task flow of system function
Refine hazard and define safety constraints in vehicle level
Technical safety requirement specification Perform safety analysis in system level
Define safety requirement in system level
Part 6.
Software Dev.
Software functional requirement definition Define software function and design preliminary architecture
Identify task flow of software function
Refine hazard and define safety constraints in vehicle level
Software safety requirement specification Perform safety analysis in software level
Define safety requirement in software level

Table 2

Example of safety analysis

Element Type Causal factor
Smartkey controller Control input or external information wrong or missing ・Start relay status
(Off/ACC/IGN/Start)
information is wrong
Inadequate control algorithm ・Shift P/R/N/D control algorithm is inadequate
(e.g., Recognition of P stage as R/N/D stage)
・Battery On/Off control algorithm is inadequate
・Steering Lock/Unlock control algorithm is inadequate
・Transmitting Unlock signal to Electric Steering Column Lock is failed
Inadequate operation ・On signal from Battery Management System is not received
・On signal from Battery Management System is received as Off signal
Transmission management system Inadequate operation ・P stage signal from driver is not received ・P stage input signal from driver is received as R/N/D stage ・P stage signal is not send to Smartkey Controller ・R/N/D stage signal is send to Smartkey Controller as P stage
Battery management system ・On signal is not send to Smartkey Controller
・On signal is send to Smartkey Controller as Off signal
Electric steering column lock Component failures ・Unlock signal from Smartkey Controller is not received
・Electric Steering Column Lock is failed
Steering system ・Steering System is failed