Safety Case

비가 오는 일요일 아침입니다. 글 하나 쓰고서 밀린 일 좀 해보려고 합니다.

Safety Case, 안전 가방?, 안전 케이스? 이것이 무엇이란 말인가? 

사실 Safety Case는 ISO 26262에서 처음 등장한 용어는 아니다. ISO 26262외 IEC 61508, 철도 등의 기능안전 표준에서 이를 다루고 있다.

ISO 26262 Part 1 vocabulary의 정의를 보면

argument that the safety requirements for an item (1.69) are complete and satisfied by evidence compiled from work products of the safety activities during development

안전 케이스 (Safety Case): 아이템의 안전 요구사항이 완전하고 부합된다는 논거로서, 개발하는 동안 작성된 작업산출물이 논거에 대한 증거가 된다.

여기서 키 포인트는 "안전 요구사항이 완전하고 부합된다는 논거"이다. 이를 작업 산출물로 보여줄 수 있다는 것이겠다.

조금 더 관련된 내용을 ISO 26262의 Safety Case는 Part 2에서 찾아보면

6.4.6.1. 이 요구사항은 ASIL (A), B, C, D로 최소 한 가지 안전 목표가 있는 아이템에 부합하여야 한다. 안전 케이스는 안전 계획에 따라 개발되어야 한다.

6.4.6.2. 안전 케이스는 안전 수명주기 동안 생성된 작업 산출물을 꾸준히 계속해서 엮는 것이 좋다.

정리를 해보면 우리가 개발하는 아이템(제품)에 대해서 이것이 안전 요구사항을 고려하여 완전하고 부합될 수 있도록 개발이 되었다. 이를 작업 산출물들로 엮어서 보여줄 수가 있다는 것이다. 이 때에 한 가지 더 명심할 것은 우리가 개발하는 안전 수명주기를 고려해야 한다는 것이다.

자동차 분야는 여러 많은 상생관계, 협력관계로 이뤄져 있다. 각 개발하는 범위 내에서는 충분하게 안전 요구사항을 고려하였음을 보여줄 수 있어야 한다. 

(출처: SGS-TUV Saar AFSP 교재 중 캡처)

그림에서와 같이 Safety Case는 ISO 26262와 관련된 개발 전 생명주기를 고려할 수 있고, Safety Case에 명시된 목적/범위 등의 내에서 작업산출물들을 고려하여 이를 보여줄 수 있다는 것이다.

ISO 26262 Part 10. Figure 6를 살펴 보자. 여기서는 Safety Case를 크게 3가지 카테고리? 컴포넌트로 구분해서 구조를 보여주고 있다.

첫 번재로 Requirements이다. (Safety Goal도 결국은 Requirements이다. Safety Requirements인 것이다.) 결국은 우리의 제품은 Safety Requirements를 만족하고 있음을 보여줄 수 있어야 한다. 그것을 어떻게? 작업산출물로 말이다. 추가로 Argument를 고려해!

두 번째로 ISO 26262 Work products이다. Safety Requirements와 Objectives를 만족하는 작업산출물로 어떠 어떠한 것들이 있다는 것이다.

세번째로 Safety Argument이다. (이 부분이 처음에 이해하기 어려웠었다) Argument? 논거? 무슨말일까? 간단하게 설명하면 ISO 26262 Work products, 작업 산출물이 왜! Safety Goal, Safety requirements를 만족한다는 설명이다. 그리고 우리가 고려한 방법론, 제한 사항 등 제품 개발에 포함된 선택의 이유, 근거들을 가지고 설명한다는 것이다.

예로 들면, ISO 26262에서는 여러 Method를 제안하고 있다. 이러한 Method는 ASIL에 따라 ++ High recommendation, 또는 + recommendation으로 구분되어 있다. 만약에 우리의 개발 생명주기, 안전 생명주기 동안 이를 충분하게 다~ 완벽하게 Perfect하게 따를 수 없다면 우리는 ISO 26262를 적용할 수 없는 것인가? 내 의견은 아니다.! 

ISO 26262도 하나의 개발 관점(Perspective) 인 것이다. 우리가 고려할 수 있고, 적용할 수 있고, 할 수 있는 범위 내에서 이를 충분하게 만족하고 있음을 보여줄 수 있어야 한다. 그것이 첫 번째가 아닐까? 표준에서 제안하는 방법에서 A, B, C... 안에 따른 선택할 수 있는 부분이 있었다면, 왜 그것을 선택하였는지 Argument를, High recommendation이 아닌 Recommendation을 따랐다면 왜 그래야 했는지! 이해관계자도 납득할 수 있을만한 Argument였는지? 를 보여주자는 것이다. 

이러한 Safety Case는 결국 Communication의 한 수단과 방법으로 활용될 수 있다. 내 의견은 그렇다. 우리가 개발하는 제품에 깊숙히 들어가서 이해하지 못한다면, 다른 3자나 다른 고객이라면 우리의 안전 요구사항과 이를 완전하고 부합되게 개발했다는 것을 이해하려면 Safety Case가 첫 번째가 되는 것이라고 생각한다.

다음 시간에는 Argument에 대한 좀 더 자세한 이해와 Safety Case 설계(?)에 대해서 얘기해보겠다.

(사실 시간을 들여서 한 번에 글을 쓰면 좋겠지만, 게을러서 그렇게 준비를 하지 못하고 그때 그때 생각날 때 글을 쓰다보니 잘 안된다.;;;)

그럼 Have a nice sunday!