ISO 26262 맛보기 - 자동차 개발자 컨퍼런스 20130515

2013년 5월 15일.. 스승의 날이지만, 스승님은 주말에 뵈었다.

MDS테크놀로지에서 주최하는 "자동차 개발자 컨퍼런스"에 다녀왔다. 

처음 가본 양재동 L타워... 헐~~~ 좋긴 좋구만..

앉은 자리에서 식사까지 다 가능하다. 양식코스.. @.@

회사를 빼먹고 간것이냐고? 아니다. 오후 3시가 넘어서 복귀했다. 야근하러 출근하는게 기분이 상콤했다.

회사서 지원받아서 간것이냐고? 아니다. 무료 세미나다. 그러니까 보내준거다. 

여튼 서론은 요정도로 하고, 내가 참석한 Track은 ISO 26262의 튜토리얼을 포함해서 개발 Tool을 활용하여 Item definition부터 상세 요구사항까지 도출하는 과정을 소개하는 과정이라고 보면 된다.

자동차의 전문가도 아니고, 개발자도 아닌 내가 다른 Track에서 집중있게 들을만한 내용이 아니었기에 열심히 Track#1에서 쫑긋 들어보았다.

ISO 26262는 총 10개의 part로 구성되어 있다. 자동차의 기능/품질에 안전을 추가(?) 혹은 보장할 수 있도록 기능안전 프로세스, 기능안전 프로젝트로 인증을 받는 제도라고 이해했다. 난 그렇게 이해했다.

프로세스로 인증을 받으려면 최소 3년간의 준비가 필요하다고 말하는 거 보니, 대충해서는 안되는 것 같다.

(말이 너무 직설적이라고 생각하지 마세요. 현실 아시잖아요?)

Track#1에서 이해한 내용을 아래에 약간 기재해보겠다.

safety-related systems, E/E Systems, passenger cars, 3.5ton 이하에 적용
- Scope의 범위에 따라 주의해서 파악할 것. (최소한의 개념으로 이해)
- 안정성에 대한 3가지 법률
    ① Product safety law
    ② 제조물 책임법(Product liability & manufacturer’s liability
        * ISO 26262는 DIS 제정부터 “최신 과학기술(the state of the art) 준수를 권장함
    ③ 중상의 경우 형사 책임

cf) ISO 26262의 2차 개정에는 기존 개념과 달리 4개 미만의 바퀴를 가진 모터 사이클에 확장이 가능할 것으로 파악하고 있다. (3.5ton 이상의 다른 상용 차량에도 적용 가능함)

- 2판 개정에 오토바이 부품사들이 참여하고 있다는 사실로 유추해 볼 수 있음

Harm(people에 한함), Hazard, Risk, Safety, Functional safety 정의

- Total Risk = S × E × C
  ① Severity of harm,
  ② Exposure frequency,
  ③ Driver controllability
      * 운전자의 조작능력(controllability)에 따라 Risk의 경감이 가능하다.

- 3개로 구분하여 이들의 연관성/곱으로 Risk를 산출함. QM/ASIL A, B, C, D

추적성(Traceability), 일관성(Consistency)의 중요성

- HARA(H&R) 분석을 통해 도출된 Safety Goal 및 Requirements들은 System의 설계, 분석과 연결이 되어야 한다. 즉 각 항목간의 추적성 및 일관성을 유지해야 한다.

  ① 영향 분석 (Impact Analysis) 가능

  ② 산출물 (Work product)에 대한 Safety Assessment 가능

  ③ 표준에 규합하는 Safety Case 생성 가능

Item: 차량 Level에서 ISO 26262에 준하는 기능을 수행하기 위한 시스템 또는 배열

시스템(System): 최소 하나 이상의 Sensor, Controller, Actuator를 포함하고 있는 Element들의 조합을 말함

Item Definition: Item의 설계 및 안전 분석과 관련된 모든 정보들의 집합

  ① Item의 목적과 설명 (Item Description)

  ② Item 운영상의 환경적 제약조건 (Item Description)

  ③ Item의 기능 (Functions) 및 기능 간 연관성 (Item Function 정의)

  ④ 각 기능별 요구사항 (Requirements) (Item Function 정의)

  ⑤ 잘못된 기능 수행 (Malfunction)의 정의와 잠재적 결과 (Malfunction 정의)

  ⑥ 초안 아키텍처/Outline (Initial Architecture)

" 위험을 보는 것, 인지하는 것, 식별하는 것이 안전의 시작이다."

HARA(공식명칭: H&R) 분석의 3가지 기본 STEP

  ① 상황 분석과 위험 정의 (Situation Analysis and Hazard Identification)

      - Hazardous Event를 발생시킬 수 있는 Item의 잠재적 Unintended Behavior를 정의

  ② 위험 유형 (Hazard Classification)

      - Item의 Hazard로부터 고려된 Severity, Exposure, Controllability를 결정

  ③ ASIL과 Safety Goal의 결정 (Determination of ASIL and Safety Goals)

      - 요구되는 자동차 통합 안전 등급(Automotive Safety Integrity Level)을 결정

      - ASIL이 결정된 각각의 Hazardous Event마다 Safety Goal을 결정

         cf) 신뢰성/객관성/통계적 분석 등을 통한 SEC가 판별되어야 한다. → 유증무죄/무증유죄

Part3. Concept Phase

  ① Safety Goal: H&R 분석을 통해 도출한 안전 목표

  ② Functional Safety Requirement: 안전 목표를 만족하기 위한 차상위 기능안전 요구사항

  ③ Technical Safety Requirement: 기능안전 요구사항을 만족하기 위해 System level에서 고려할 수 있는 기술적 요구사항 (개발자들의 이해를 도울 수 있음)

  ④ HW/SW Safety Requirement: 기술 요구사항을 만족하기 위해 HW/SW 구현을 위한

    요구사항

Hardware의 Key Metric 종류

  ① Single Point Fault Metric (SPFM)

      - 잠재적으로 위험한 결함들이 얼마나 많이 안전하게 되거나 검출되는지를 정량화

  ② Latent Fault Metric (LFM)

      - 아직 다른 Application에 영향을 주지 않은 잠재적 위험한 결함들이 얼마나 많이 안전하게 되거나 검출되는지를 정량화

        cf) 위험한데, 검출되지 않은 Fault를 계산해서 증빙하는 것이 중요함.

Software Testing (part6. S/W의 약 50%이상 차지) → Table1, Table8~15

Hardware Metric, Software Coverage에 대한 관리가 중요

   - Hardware: Single Point Fault Metric, Latent Fault Metric

   - Software: 타겟 환경에서의 Code Coverage 확보

ISO 26262 각 part별 요구사항은 Concept단계에서 산출된 결과물을 바탕으로 수행한다.

Item Definition → H&R → Functional Safety Concept → Technical Safety Concept → HW/SW Development

 

Major Concepts

  ① Safety: 사람에 대한 안전

  ② Verification: 개발 단계의 상위 요구사항에 따라서 제품이 개발되는지 여부를 조사

  ③ Validation: 개발 단계의 요구사항에 따라서 제품이 작동하는지 여부를 검증

  ④ System: 하드웨어 + 소프트웨어 통합 개념

제품 개발 시 주요 활동

  ① 요구사항 정의: 제품/시스템/하드웨어/소프트웨어

  ② 아키텍처 정의: Semi-formal notation 기반 모델

  ③ Safety Concept 정의

      → 반복적으로 수행하며 정교화, 상세화, 운영화 시키도록 한다.

        - part.3: Functional Safety Requirements (FSR)

        - part.4: Technical Safety Requirements (TSR)

        - part.6: Software Safety Requirements (SSR)

➤ 주요 3가지를 상세 히 살펴보자.

  ① Functional Concept

     - 제품에서 요구되는 Top-Level 기능 요구사항

     - Safety-related 요구사항 및 Non Safety-related 요구사항 포함

     - 제품에 요구되는 주요 기능을 식별하여 Use-Case를 만든다.

     - Use-Case에 대한 요구사항을 정의하여 Requirement Element를 추출한다.

     - Functional Concept 분석 활동의 목적은 제품에 대한 요구사항을 정의하는 것.

     - 요구사항 관리를 위한 요건으로는 다음과 같다.

        - 문장 단위 요구사항 관리 + 문맥에 따른 요구사항 구조화 + 속성 컬럼

        - 요구사항 추적성 링크 관리

        - 요구사항 추적성 분석 기능: 매트릭스, 영향도 분석

        - Work Product 자동 산출

  ② Preliminary Architecture

     - 제품의 Conceptual-level 아키텍처 모델

     - 제품과 통신하는 외부 요소를 식별, 제품 Context 구조를 도식화

     - Block Diagram: Block Concept 기반

     - 제품을 구성하는 내부 요소를 식별, Conceptual level 아키텍처

     - 제품 외부 요소와 통신을 위한 네트워크 토폴로지 정의, Conceptual level 아키텍처

     - 주요 기능 수행을 위해 요구되는 세부 액티비티(Function)을 식별

     - 식별된 액티비티 간 제어 흐름을 분석

     - Use-Case 중심: Use-Case에 대한 Requirements Diagram 기반

     - Activity = Functional Concept = Process Block (Input/Output 처리)

     - 실행 스토리 분석 → 기본 스토리, 변경 스토리, 예외 스토리

       세부 요구사항 도출 → 제약사항, 조건 (비기능 요구사항)

       Sequence Diagram: 시간 순서에 따른 실행 스토리를 표현

     - Operational Mode/State 식별

        State-machine Diagram

        - State: 상태 또는 모드

        - Transition: 상태 간 전이

        - Event: 대상에 작용하는 자극

        - Action: Transition에서 수행되는 조치사항

    - 모델링 시 요구사항 및 제약 사항 등을 식별

      식별사항: Requirements/Constraints/Rationalbe/Testcase

  ③ Functional Safety Concept

     - Safety Requirements + ASIL + Allocation to Architectural Elements

     - Safety Requirements 정의

        ASIL 판정

        Allocation Link to Architectural Elements

        cf) Architectural Elements

             - Preliminary Architectural Assumptions

             - External Measures

             - Other Technology

     - Safety Measures = Safety Mechnism

     - Functional Safety Requirements 정의

  

Hazard Analysis & Risk Assessment (H&R)

  ① Behavior shortfall 식별: include Hazards and Failure Modes

     Hazardous Event 식별

     HAZOP분석 or Safety-FMEA

       - Hazard: 사람에게 피해(Harm)을 줄 수 있는 Malfunctioning-Behavior

       - Hazardous Event: Hazard + Operational Situation

  ② Hazardous Event에 대한 ASIL 산정

     Safety Goal 정의 = Top-level safety requirements

     ASIL 판정: QM/A/B/C/D

       - Severity Class

       - Controllability Class

       - Probability of Exposure Class

전문도구 (일부만 소개)

  ① Doors: ISO 26262 인증 받은 Requirements Management 도구

  ② Rhapsody: SysML 지원 (ISO 26262-3,4 아키텍처 모델링 지원)

               AUTOSAR 지원 (ISO 26262-6 SW 모델링 지원)

               모델 검증 지원 (UTP 기반 MIL/SIL 지원)

  ③ MediniAnalyze: ISO 26262 Safety Management 도구

결론적으로, ISO 26262가 무엇이냐?

떠오르는 안전에 대한 규격인증이다. 선진국, 선두기업에서 강력하게 추진하고 있는 인증이다.

결국 자동차 업종에서 종사한다면, 결국은 언젠가는 부딪칠 수 밖에 없을 것 같다.

언젠가는 지금의 ISO 9001/14001처럼.. 당연시 해야 할 지도 모르지만, 그건 좀 먼것 같고..

이 하나의 글에서 ISO 26262을 자세히 소개할 수는 없다. 

어떠한 이유보다도, 아직 나도 이제 맛보는 중이니 머리에서 정리 좀 하고 기재해야 할 듯 싶다.

오랜만에 블로그에 들어왔다.

점점 관리하기가 힘들다. 사실 게을렀다. 야근하고 야근하고 야근하니까...

지금 근무하고 있는 곳에서는 보안상의 문제로 블로그에 글 하나 올릴 수가 없다.  허.....

여튼... 오랜만에 글을 쓰고 잔다.

늦었지만, 상쾌하다.