ISO 26262 핵심 개요

기능 안전의 주요 개념

• 일반적인 안전(Safety)의 개념
  허용할 수 없는 리스크로부터 자유로운 상태
  risk: 잠재적 문제로 가능성과 심각도의 결합으로 나타낸다.

• 안전 필수 시스템(Safety Critical System)의 개념
  인적, 환경적 심각한 피해를 야기할 수 있는 시스템으로 Life-Critical System이라고 부름

• 기능 안전(Functional Safety)의 개념
  E/E 시스템의 오작동으로 인한 해저드로 인해 허용할 수 없는 리스크가 없다.
  기능 안전을 만족하기 위해 두 가지 관점의 요구사항을 달성해야 함
  안전 기능 요구사항: 해저드 분석(Hazard Analysis)를 통해 도출됨
  안전 무결성 요구사항: 리스크 평가(Risk Assessment)를 통해 도출됨
  안전 무결성(Safety Integrity) -> 안전 관련 시스템이 명시된 기간 내의 명시된 모든 조건 하에서 요구되는 안전 기능을 만족스럽게 수행할 확률

• 기능 안전 기본 용어 정의
  Harm(위해): 사람의 건강에 영향을 주는 직/간접적인 손상
  Accident(사고): Hazardous Event가 실제로 발생하여 문제가 된 상황
  Hazardous Event(위험한 사건): Hazard와 Operation Situation이 결합되어, Accident가 발생할 수 있는 사건
  Hazard(해저드): Harm을 일으킬 수 있는 잠재적인 요인
  Malfunction(오동작): 정상적인 기능으로부터 Deviation이 발생한 상태(Loss of Function, Unintended Function등)
  Operation Situation(운용 상황): 시스템이 노출되어 있는 운용 환경
  Risk(리스크): 잠재적인 문제로, Hazard가 Accident로 이어질 가능성과 심각도의 조합으로 표현

• 소프트웨어 안전의 개념
  Freedom from Software Hazards

• SW 수준의 Mistake, Fault, Error, Failure 용어 정의
  Mistake(실수): 사람이 실수로 결함을 주입하는 행위
  Fault(결함): 오류를 일으킬 수 있는 비정상적인 상태/조건
  Error(오류): 명세된 결과와 처리 결과와의 불일치
  Failure(고장): 상위 시스템에서 요구된 기능을 수행하지 못함

• 소프트웨어 안전 확보 컨셉
  Fault Prevention(결함 예방): 사람이 실수하지 않도록 방지하기 위한 방법
  Fault Detection(결함 검출): 결함을 검출하기 위한 방법
  Fault Removal(결함 제거): 검출된 결함을 제거하기 위한 방법
  Fault Tolerance(결함 허용): 런타임시 결함이 발생해도 오류를 유발하지 않도록 하거나 오류가 발생해도 고장이 발생하지 않도록 하기 위한 방법

• Redundancy와 Diversity의 개념
  Redundancy: 특정 기능을 수행하기 위해 동일한 방식으로 설계하는 개념
  Diversity: 특정 기능을 수행하기 위해 다양한 방식으로 설계하는 개념

---

ISO 26262 개발 배경 및 소개

• ISO 26262 기능안전 표준
  자동차에 탑재되는 전기전자시스템의 오동작(Malfunction)과 해저드로 인한 사고를 방지하기 위한 기준을 제공하는 기능 안전 국제표준
  V 모델 컨셉을 갖고 있다.

• ISO 26262의 적용 대상
  자동차, 모터사이클 및 상용차(트럭, 버스)

• ISO 26262의 안전 생명주기
  Hazard analysis and risk assessment(Hara) 단계가 가장 중요한 단계
  시스템 안전 요구사항을 분석하고 시스템의 안전 요구사항 중에서 소프트웨어에서 처리할 부분을 규정한다.

• ISO 26262의 소프트웨어 안전 생명주기
  일반 소프트웨어 개발 생명주기에 안전 관련하여 수행해야 하는 활동과 기법을 포함

• SW안전 아키텍처 설계
  SW안전 요구사항을 구현하기 위해 추가적으로 필요한 SW컴포넌트 및 컴포넌트 간 인터페이스 등을 설계에 반영하는 활동

• 해저드 분석 및 리스크 평가

  • 해저드 분석
    오동작(Malfunction) 식별: 시스템의 정상 기능으로부터 오동작을 식별
    해저드(Hazard) 식별: 시스템의 오동작으로 인해 Harm을 일으킬 수 있는 잠재적인 요인인 Hazard를 식별
    Hazardous Event 정의: 시스템이 동작하는 환경인 운용 상황(Operational Situation)을 정의
    Hazard와 Operational Situation을 조합하여 Hazardous Event를 정의
  • 리스크 평가 프로세스
    ASIL 등급 결정: Severity, Exposure, Controllability로부터 도출함 Hazardous Event를 분석하여 ASIL 등급을 결정
    안전 목표 정의: 시스템의 오동작으로 인해 발생할 수 있는 Hazard를 완화하거나 예방하기 위해 달성해야 하는 최상위 수준의 기능 안전 요구사항을 정의

• ISO 21448 SOTIF(Safety Of The Intended Functionality) 표준
  자율주행차량 내 시스템의 의도된 기능의 성능 등이 불충분하거나 부적절한 경우를 개선하기 위한 프로세스와 V&V 기법을 제공하는 국제 표준

---

V-Model 개발 및 테스트 프로세스

소프트웨어 요구사항 개발

• 요구사항의 정의
  현실 세계의 문제를 해결하기 위하여 고객에 의해 요구되거나 표준 등을 만족하기 위해 제품이 가져야 하는 서비스 또는 제약사항
  품질과 연결이 된다. 요구사항을 만족한 제품 = 높은 품질의 제품

• 요구사항의 분류
  고객 요구사항: 고객이 개발 대상 제품에 대해 원하는 기대사항(Needs)
  제품 요구사항: 고객 요구사항을 만족하기 위해 제품이 수행해야 하는 개발 관점의 구체적인 요구사항
  기능적 요구사항: 제품이 목표를 달성하기 위해 사용자에게 제공해야 하는 행위적(기능적) 속성
  비기능적 요구사항: 제품의 기능이 성능, 안정성, 사용성 등의 품질 기준을 만족시키기 위해 가져야 하는 속성

• 소프트웨어 요구사항의 중요성
  소프트웨어 제품을 전체적으로 파악하도록 하며, 전체 개발 단계의 기준 및 가이드라인으로 활용됨

• 소프트웨어 요구 공학의 정의
  소프트웨어를 개발하기 위한 요구사항을 추출, 분석, 명세, 검증하며, 개발된 요구사항의 변경 및 추적을 관리하는 공학적 접근 방법

• 요구사항 분석
  후보 요구사항에 대해 기능/비기능 요구사항을 분석하고 우선순위를 결정하여 요구사항을 확정함
  구조적 분석: 소프트웨어의 기능을 정의하기 위해서 프로세스들을 도출하고, 도출된 프로세스 간의 데이터 흐름을 중심으로 정의
  객체지향 분석: 소프트웨어의 기능을 정의하기 위해서 사용자 중심의 시나리오 분석을 중심으로 정의

• SW안전 요구사항 개발 방법
  HAZOP 등의 위험원 분석 기법을 활용하여 기능/인터페이스 측면의 위험원에 대한 완화 대책을 도출하고, 이 중 SW로 처리되어야 하는 항목을 SW안전 요구사항으로 도출함
  SW설계에 대한 FMEA(Failure Mode Effect Analysis -> Bottom-up)/FTA(Failure Tree Analysis -> Top-down) 등의 안전 분석을 수행하고 안전을 확보하기 위해 필요한 추가 대책이 식별되면 이를 SW안전 요구사항으로 도출함

• 요구사항 검증
  이해당사자 기대사항이 의도한대로 요구사항이 추출 및 분석되어, 소프트웨어 요구사항 명세서가 작성되었는지를 검토/확인하는 활동