Systematic fault

혼자 괜히 필 받아서 글을 하나 더 올립니다.

간략하게 표제와 관련하여 설명을 해보겠습니다.

도대체 Systematic fault가 무엇인가? 그리고 이게 정말 중요한가?

제 답은 네! 중요합니다. 아~~주 중요합니다.

그러면 간략하지만 제가 가지고 있는 생각을 아래와 같이 말씀 드립니다.

참고: TUV-Saar AFSP_K2 module 중

위 그림에서 Avoidance를 Systematic faults, 그리고 Random faults로 구분하고 있습니다.

여기서 Systematic fault의 접근보다는 Random faults의 접근이 보다 확실하고 정량적이고, 분석하는 맛(?) 이 있으실 겁니다. (여러 엔지니어 분들께서 그렇게 느끼실 것 같습니다.)

제가 여기서 출처가 없는 과거에 보았던 자료의 내용은 다음과 같습니다.

제품/프로젝트에서 발생할 수 있는 오류(error)는 기술적 측면보다는 프로세스적인 부분에서 더 많이 발생한다. 그리고 그 비율은 대략 80%다~ 라고 하고 되어 있습니다.

그래서 우리는 Systematic faults에 대해서 생각하고 이를 방지하기 위한 노력을 해야 합니다.

만약에 위와 같은 Flow로 업무를 하고 있다고 가정하겠습니다.

요구사항 뽑고, 설계하고, 검증하는 Task를 가지고 있습니다.

요구사항 엔지니어가 아주 철저하게 분석하며 따져봐서 잘 뽑았습니다.

그리고 엔지니어는 요구사항을 바탕으로 아주 잘~~ 설계하였습니다. 그리고 검증하였죠.

그런데 문제가 발생하였습니다. 왜 그랬을까요?

예를 들면, 요구사항 엔지니어가 요구사항을 분석한 Version은 V02 라고 해봅시다. 그런데 설계 엔지니어가 V02를 통해서 한 것이 아니라면? V01 또는 아직 작성중으로 Baseline 되지 않은 V03으로 했다면 어떻게 될까요?

그래도 요구사항을 충분히 반영한 설계라고 볼 수 있을까요? 여기서 충분히는 최소 3가지를 생각해 보시기 바랍니다. Completeness, Consistency, 그리고 Correctness

위에서는 Configuration 측면에서 얘기했습니다. 그러면 이번에는 Change 측면에서 예를 들어보겠습니다.

요구사항 엔지니어가 V02에서 베이스라인을 긋고, 엔지니어는 V02 요구사항 기반으로 설계를 잘 했습니다. 물론 검증도 위 최소 3가지 측면에서 수행을 하였습니다. 그런데 문제가 생길 수 있습니다.

설계를 하는 중간에 변경이 필요한 부분이 발생하였다고 가정하겠습니다. 설계 엔지니어는 변경에 대한 얘기를 듣고 설계에 포함을 시켰습니다. 그런데 Requirements는 업데이트 하지 않은 것이지요.

그리고 검증 엔지니어는 업데이트가 된 설계를 검증하지 않고 V02 기반의 요구사항으로 검증을 한 것이지요. 

다른 예로 문서화 하지 않아서 결국 시간이 지나서 발생하는 경우, 설계 시 미처 고려하지 못한 부분으로 이후 영향이 있는 경우 등 많은 일들로 우리의 제품/프로젝트에 영향을 줄 수 있습니다.

이러한 부분, 즉 Systematic fault가 일어날 수 있는 부분을 우리는 Process를 준수하여 방지하거나 줄일 수 있습니다. 워치독, Lockstep과 같은 기술적인 측면이 아닌 우리가 프로세스를 준수하는 것도 Safety mechanism인 것이지요.

그러면 다음의 그림을 보시죠.

각 단계별로 Verification을 넣어봤습니다. 요구사항을 베이스라인 긋기 전에 Peer review와 같은 검토를 하고, 설계한 이후 FTA, FMEA 등 을 통해서 분석하고, 최종적으로 Verification 한 결과에 대해서 Confirmation 하는 프로세스를 통해서 앞서 말했던 Systematic fault를 줄일수 있는 Mitigation 할 수 있는 Flow를 예시로 들었습니다.

Automotive SPICE, CMMI, ISO 26262 등과 같은 산업군의 표준, 방법론 등들이 위의 체계를 수립하는데 Reference될 수 있습니다. 

이상입니다.

읽어 주셔서 감사합니다.