뒤늦게 알게 된 기능안전 - Part 2

○ 프로젝트 초기에 해야 할 것 중에 헷갈린 개념?

▶아이템 영향 분석 : 기존 아이템 수정, 수정된 환경을 포함한 기존 아이템일 경우

▶엘리먼트 영향 분석: 재사용되는 엘리먼트 존재할 경우 → 재사용되는 운용 상황

고려하여 재사용 엘리먼트가 해당 엘리먼트에 할당된 안전 요구사항을 준수할 수 

있는지 분석 필요

 

↑ 위 활동들은 안전활동 테일러링을 지원한다. 테일러링 시에는 테일러링한 

논리적 근거와 그 논리적 근거 결과에 대한 검토가 필요함

 

○safety management로 해야할 것

▶안전활동 계획 및 조정, 안전활동 진행 상황 추적, 테일러링된 활동에 대한

    설명 및 정당화

▶DIA 수행, 문서화

▶확인 수단 보장

    →확인 검토: 핵심 작업 산출물이 기능안전 달성에 대한 그들의 기여도에 대해

                         충분하고 설득력 있는 증거를 제공하는지 판단(←개발도중

                         기능안전 완성도 높이기 위함)

    →FS audit: 안전 활동에 필요한 프로세스 표현에 대한 평가

    →FS assessment: 아이템 및 엘리먼트 개발에 관한 기능안전 달성에 대한

                                   기여도 판단(←최종 체크를 위함)                  

 

○기능안전 달성을 위해 요구된 자원?

▶인적, 물적 자원, 도구, 데이터베이스, 지침서 및 작업 지시사항

 

○프로젝트 관리자 업무 중 하나?

▶안전관리자 임명되도록 해야함, 안전 관리자는 역할의 개념으로 조직에 따라

  그 역할에 필요한 업무를 여러 사람에게 할당이 가능

 

※아이템 수정 종류

아이템 수정 / 수정된 아이템 환경

a) 요구사항(설계 수정) : 아이템 행위에 영향 줄 수 있음

b) 구현 수정: 요구사항 수정이 아닌 구현 방법에 대한 수정임: 아이템 행위 영향

미칠 수 있지만 아이템의 명세 및 성능에 영향을 미치기 위한 것은 아님

c) 온도, 고도, 습도, 진동, 전자기 간섭 및 연료 유형 등

 

a),b)는 아이템 수정에 속하고, c)는 수정된 아이템 환경에 속함

→수정일 경우 분석은 기능안전과 관련된 수정의 영향평가와 그 영향에 기반하여

수행되어야 함 안전활동 식별 및 설명 가능해야 함

 

◆Safety case: Safety goal 위배를 하지 않음을 입증하기 위한 보고서

 

구성:

요구사항 (the requirement) : 안전목표 및 관련 안전 요구사항

논거        (the arguments  ) : '증거'로 '요구사항' 만족함을 어떻게 달성했는지?

증거        (the evidence    ) : 26262 개발 산출물
                                             ← 작성 시 증거에 대한 참조 표시 필수

 

※이따금 논거는 무시될 수 있으며 이 경우 증거와 요구사항 간의 관계를 

설명하는 대신 여러장의 개발 산출물을 증거로 제시 가능

※논거와 증거는 상호 보완 관계임

 

◎논거의 구성

▶프로덕트: 시스템 특징으로 안전 주장(ex: timing watchdog 동작)

▶프로세스:개발과 평가 프로세스 특징으로 안전 주장(ex:채택된 설계
                    명세 표기법)

 

기본적으로 프로덕트는 프로세스의 결과물이므로

이 두 과정을 논거로 확신을 주면 충분한 요구사항 만족의 논거가 됨

 

◎안전 케이스 작성 시점:

주로

TSR의 검증 완료시점 → 시스템 설계 검증의 완료 시점 → 기능안전 평가 전 시점

 

※안전 케이스에 대한 확인검토 할 떄:

시스템 변경시, 수정시 안전 케이스에 대한 영향도 평가 필요

→필요시 안전 케이스는 변경 점 고려하여 업데이트 됨

 

케이스 레포트 계층

1. 안전 목표 계층

2. FSR 계층

3. TSR 계층

4. 컴포넌트 계층

 

HKMC경우 Process arguments는 confirmation measure로 

대체 가능