Tag Archives: scope

Verification 및 Validation관점에서 Safety에 대한 차이


이런 질문을 던지고 싶다.

  • Safety를 Verification 관점에서 본다면 어떻게 평가해야 할까?
  • Safety를 Validation관점에서 본다면 어떻게 평가해야 할까?

 

굳이 평가 행위를 Verification과 Validation으로 나누고 싶지는 않은데, 그냥 생각해보자는 거다.

Scope을 나누기는 하더라도 실제 평가 방법이나 평가 환경은 동일할 수도 있다. (물론 다를 수도 있다..)

Verification을 한다면 Safety function의 의도된 행위의 여부에 중점을 둬야 할 것이다. 즉 ‘의도한 대로의 행동’을 보였는가?

하지만 Validation을 한다면 Safety function의 의도적 동작이 아니라, Safety Attribute의 달성 여부에 중점을 둬야 할 것이다. 즉, ‘충분한 safety가 달성되었는가?’

시스템 개발을 할 때, 고장모드 분석을 해서 발생 가능한 failure mode를 식별해서 plan을 세웠을 것이다. 그것이 operation이 되었건, system의 logic이 되었건…

그때 verification관점에서는 failure mode의 발생으로 인한 의도된 safety function이 구현되었느냐를 확인해야 할 것이다. 예를 들어 Air bag의 경우 박치기 조건에서 펑 튀어 나오냐..

Validation관점에서는 그런 fault injection혹은 non-nominal조건으로 충분한지에 대한 검토가 필요할 것이다. 박치기의 다른 조건을 본다던지, 아니면 펑 튀어 나오는 것의 로직이 타당한지에 대한 것이나, 아니면 그 로직의 malfunction에 대한 고려를 한다던지… 뭐 그런식..

별결 다 따진다고 하는지 모르겠다. 하지만 이게 어디 scope인지를 계속 따져야 나중에 개발 및 검증 범위를 명확히 하는데 도움이 된다.

경험한 사례로 SW수준의 설계를 System 아키텍처라고 한 것이나, System 요구사항을 Sw요구사항이라고 기술된 것을 봤다. 그런 방식으로 했을 때 별일 없을 거라고 생각하면 오산이다.

개발이 안되고 검증이 안된다.

그런 개념이 장착되지 않으면 대충 개발하고 대충 검증하게 되며, 품질도 대충대충된다.

그러면서 어쩔 수 없다고 항변할 것이다.

scope의 모호함으로 생기는 문제이다.

scope을 명확하게 잡게 되면

달성해야 하는 것과 포기해야 하는 것을 명확하게 나눌 수 있다.

반드시 지켜야 하는 것과 지키지 않아도 되는 것을 나눌 수 있다.

 

 

 

 

Advertisements

System, Software 및 요구사항 및 설계의 경계를 명확하게 정하기


일반 개발자들 입장에서는 사소한것이고 별로 중요하지 않다고 생각할지 모르겠다. 막상 Safety 표준대로 준수하려고 하면 boundary를 명확하게 잡지 못해서 혼돈에 빠지는 경우를 종종 보게 된다.

요구사항과 설계의 명확한 경계란 것은 없지만, 일반적으로 통용되는 규칙은 다음과 같다.

Requirement는 Problem domain이다.  반면 Design은 solution domain이다.

이게 가장 큰 틀인데, ISO26262나 IEC61508의 경우 Safety측면이 강화되어 Safety를 강화하기 위한 구체적인 방법까지도 problem domain에 속한다. (Functional safety표준들이 요구사항에 대한 범위를 safety에 한해서는 약간 넓혔다고 생각해도 무방하다)

Software와 System 간의 경계는 이전 포스팅에서도 언급했으나, Software및 System의 interface를 정의하면 명확해진다. Software의 interface는 입출력 ‘변수’이다. 하지만 system의 interface는 physical한 실체가 존재해야 한다.(일반적으로는)

그러나 여전히 scope에 대한 불명확함이 생길 수 있다. 그렇다면 모호한 그것이 언제 태어났는지(출생일)를 기준으로 생각해 볼 수 있다. 시스템 설계에서 태어난 것이면, 그 녀석은 system의 범위에 있는 것이고, 소프트웨어 설계동안 태어난 것이면 그 녀셕은 software의 범위에 있는 것이다.

누구에게는 사소하지만, 다른 누구에게는 심각한 고민거리..