기능안전(ISO26262)의 Supporting Process의 관리 영역 중 가장 핵심적인 부분이 요구사항 관리 프로세스이다.
물론 Requirements Management 단독으로 Safety Function을 추적을 담보 할 수 없다.
-▶ Requirements Management + Configuration Management가 통합되어야 적절한 Traceability 를 담보 할 수 있다
국내에는 여러 요구사항 관리 툴 들이 사용되고 있다.
특히 IBM의 Rational 도구들이 많이 사용되고 있는데, (이전에 Rational을 IBM이 인수함)
-▶ Rational Doors(요구사항 관리) + Rational Clear Case (Clear Quest) 변경관리
요즈음은 요구사항개발 -> 아키텍처 -> 구현 -> 테스트 까지 전체적으로 One solution을 갖추고 있지만 실제 자동차 산업분야
에 전체적으로 적용되지 못하고 있으며, 옛날에 비해 IBM솔루션이 많이 밀려나고 있는 실정이다.
(이 부부은 개인적인 의견이므로, 다음에 다루기로 하고 또한 이 부분은 읽는 분에 따라 곡해가 있을 수 있으니 개인의 판단에
따라 이견이 있을 수 있다)
※개인적으로는 변경관리는 형상관리의 한 분야로 간주되어 적용되어 져야 한다고 생가하며 형상관리 중 가장 중요한 부분이
변경관리(Change Management)라고 판단한다.
그리고 요즈음 국내 자동차 업계에서 많이 사용하는 (Of course, Very Expensive) 'MKS 인테그리티"가 주로 OEM 및 대형 부품사 위주로 사용하고 있다.
(물론 이 툴도 MKS사 였던 툴이 PTC가 인수한 툴이다.)
이 툴에 PLM(Product Life cycle Management)의 한분야인 ALM(Application Life cycle Management)의 주요 툴로 사용하고 있다. ALM 은 물론 IT업계에서 사용되고 있는 용어이다.
하지만. IBM사의 솔루션이던 PTC사의 솔루션이던 자동차 업쳉서 기능안전 전반에 완벽하게 사용되는 툴은 한번도 본적이 없다는 것이 무척 마음이 아프다. 이렇게 고가의 툴을 제대로 사용하지 못하고 프로세에 맞지않고 현실과 동떨어진 "맞지 않는 옷을 입은 형상"을 본다는 것은 참으로 슬펀 현실이다.
그러나 이러한 부분에 대해 솔루션 업체나 담당자에 책임이 있는 것은 아니다. 기능안전의 요구사항 관리를 어떤 경우는 너무나 확대 해석을 하고, 어떤 경우는 너무나 단순하게 해
석을 해서 발생하는 문제인 것을...
좀더 본질을 들여다 보면, 기존의 Open Source나 비교적 낮은 가격의 상용 솔루션을 이용하여 보안적인 문제를 해결하면 현재의 상황을 최적하여 개선/적용을 할수 있는 여지들이 많은 것 같다.
본론으로 돌아가서 기능안전(ISO26262)의 Concept 단계의 아이템 정의서에서 부터 시스템 레벨, 하드웨어, 소프트웨어 레벨에서 요구사항 관리가 왜 필요한지에 대해 간단하게 설명하고자 한다.
- 기능안전은 개발된 제품이 최신의 기술을 통해 안전성을 담보하고 개발되어고 그것을 증명할 수 있어야 한다.
- 기능안전은 개발 초기단계에서 부터 주요 Safety Level (ASIL)이 정의되고 Safety Goal을 개발한다.
- Safety Goal이 기능안전의 첫번째 안전 요구사항이다.
- 첫 안전요구사항이 Elaboration or Decomposition되어 시스템 레벨에 상속(Inherit)되고 Detail화 된다.
- 그리고 다시 하드웨어와 소프트웨어로 상속되고 분해, 상세화된다.
- 결국 이것이 제품으로 구현되고 이 제품이 Safety를 만족하는지를 Safety Validation을 통해 확인된다.
- 이러한 Safety Evidence Set을 Safety Case 라고 한다.
일련의 과정을 담보하기 위해서는 Requirements Management + Configuration Management을 통해 가능하다.
특히 ISO26262에서 욕구하는 Requirements Management을 기능안전 요건에 맞춰 도식화 하면 위의 그림과 같이 표현 된다.
'기능안전(ISO26262)' 카테고리의 다른 글
기능 안전 배경/정의 및 이슈 - 첫번째 (0) | 2016.02.22 |
---|---|
Engineering Tool Chain - 기능안전/A-SPICE 및 CMMI 기반 요건 (0) | 2016.02.19 |
Functional Safety v.s. Development Process Improvement Model - 2 (0) | 2015.04.20 |
Functional Safety v.s. Development Process Improvement Model - 1 (0) | 2015.04.20 |
기능안전은 Umbrella 프로세스 (0) | 2015.04.20 |