ISO 26262 프로세스 접근 시 고려사항

프로세스 아키텍처라... 말이 너무 거창한 느낌이다. (부담)

 

ISO 26262를 두고 설명하면,

자동차 전자제어장치 시스템이 안전 요구사항을 포함하고 ASIL  A 이상의 수준이 요구되는 경우, ISO 26262 요구사항을 포함하여 개발하여야 함

cf. (ASIL: Automotive Safety Integrity Level)

시스템 개발/운영 시 발생 가능한 Systematic Failure의 회피/제어는 프로세스 접근 방법을 통해 달성할 수 있음.

 

개인적으로 프로세스 엔지니어로서, ISO 26262의 프로세스를 무조건 Full 또는 Hard하게 접근하는 것은 바람직하지 않다고 생각한다.

 

조직, 개발 및 기능안전 활동의 범위와 중요도를 고려하여 크게 다음의 2 가지 타입을 고려해볼 수 있다.

 

Case A, B 옆에 이름을 Tier 1, Tier 2라고 기술했다고 뭐라 하시기 전에 제가 의도한 것은 그런게 아니라는 것을 이해해 주었으면 좋겠습니다. (하하하;;)

 

Tier 1의 경우 조직, 개발의 규모가 상대적으로 크다고/넓다고 할 수 있다. 이런 경우에는 OEM과의 업무가 많으며, 이미 조직에서는 QMS, CMMI, ASPICE 등과 같은 품질, 개발 프로세스를 보유하고 있는 경우가 대다수이다.

 

그러므로 ISO 26262 업무를 위한 프로세스를 접근할 경우, 이전 품질, 개발 프로세스와 같은 범위에서 개발하는 것이 수월하였었다.

 

물론 아닌 경우도 존재 하였다.

 

Tier 2의 경우 대체적으로는 보유한 품질, 개발 프로세스에 Functional Safety와 관련된 내용을 가미하는 경우와, FSM 프로세스를 일부 작게 가져가는 것이 수월 하였었다.

 

잠깐 다른 애기를 해보면, 몇 년 전까지만 해도 CMMI 열풍이 있었던 영향으로, 많은 업체를 통해 CMMI 프로세스와 통합된 ISO 26262 프로세스를 구축하는 일을 할 수 있었다.

 

최근에는 Automotive SPICE와 관련된 요구사항이 증가하고 있어, 이쪽으로도 맛 볼 수 있는 기회가 생겼다.

 

위 내용은 가장 기본적인 접근/고려 사항이다.

 

상세한 방법과 전략은 Gap analysis 결과와 조직에서 추구하고자 하는 방향을 함께 고려하여야만 알 수 있다.

 

상세한 내용은 조심스러우니, 요정도만 기술 하도록 한다.

 

오늘도 스마일, 그리고 화이팅!