Software FMEA Techniques


소프트웨어 안전분석에는 여러가지 관점에서 여러가지 scope로 존재한다. 이건 그 중의 하나의 approach로 생각하는 것이 좋을 것이다.

이 논문에서는 두 가지 타입의 sw-FMEA에 대한 overview에 대해 기술한다.

1) System software FMEA

2) Detailed software FMEA

System level software FMEA는 소프트웨어 디자인 프로세스에서 일찍 수행될 수 있으며, 선택된 소프트웨어 아키텍처의 safety assessment를 허용한다. System level software FMEA는 top level software design을 기반으로 한다.

Detailed software FMEA는 design프로세스에서 늦게 적용되며, 적어도 소프트웨어 모듈의 pseudo code가 적어도 한번은 available할 때 가능하다. Detailed software FMEA는 top level design에서 의도한 protection을 검증하고 system level software FMEA가 목표를 달성할 수 있는지를 assess하기 위해서 사용된다.

System 및 detailed software FMEA는 hazardous system behavior를 preventing하는데 있어서 효과적인지를 평가한다.

failure에 대한 정확한 원인을 파악하는 것은 여기서 중요한 것은 아니다. Software FMEA는 system design이 system safety를 보장하기 위해서 당초 예상했던 방식대로 시스템이 동작하는 능력을 평가한다.

(중략)

Hardware and system FMEA와는 다르게 software FMEA는 system level hazard를 쉽게 identify할 수 없다. 그러므로 hw or system level의 hazard를 SW level hazard로 translate해야 한다.

SW FMEA를 수행하기 전에 system preliminary hazard analysis(PHA)가 있어야 하고, PHA는 잠재적인 cause로서 software가 가질 수 있는 모든 hazard를 포함하고 있어야 한다.

software hazard analysis를 수행하기 위하여 analyst는 PHA에서의 각각의 identified hazard에서 시작하여 hazard의 잠재적 원인을 분석하는 fault tree analysis를 수행한다.

(중략)

System software FMEA

system software FMEA는 design process에서 가능한 빨리 수행되어야 하는데, 그 이유는 analysis로 인한 design의 영향을 최소화시키기 위함이다. analysis는 top level software design이 진행됨에 따라 주기적으로 업데이트 되어야 할 필요가 있으며 final system SW FMEA는 detailed software FMEA에 update되어야 한다. 이 작업은 labor intensive작업이기 때문에 cost를 고려해서 적절하게 수행되어야 한다.

소프트웨어의 failure mode를 정의하고(Fig 4), 그 정의로부터 소프트웨어에 failure mode를 적용하여 output의 영향을 분석한다. 만약 이전에 수행된 소프트웨어 hardware analysis로 위험을 극복할 수 있다면 상관없지만, 과거의 analysis로도 위험이 극복이 되지 않는다면 추가적인 requirement를 작성하여 해당 violation을 막기 위한 mechanism을 작성한다.

Detailed software FMEA

Detailed software FMEA는 implemented software design이 safety requirement를 달성했음을 validate하기 위한 용도로 사용된다. Detailed software FMEA는 component level hardware FMEA와 유사하다. 이 분석 역시 labor intensive한 작업이다.

Detailed software FMEA를 하기 위해서는 software design및 pseudo code가 있어야만 한다. detailed software FMEA에서의 requirement는 software requirement documentation, top level design description, detailed design description이다. detailed software FMEA는 hw에서 detailed software FMEA를 지원하는 기능이 있다면 별로 필요하지 않다. (Memory management, communication management) 하지만 hw에서 지원하지 않는다면 detailed software FMEA는 필요하다.

수행 절차

1) Variable mapping: input variable, output variable, local variable, global variable

2) processing에 대한 software thread를 개발(Thread는 input variables, various stages of variables, output variables의 chain이다.)

3) 알고리즘에 대한 FMEA개발

4) detailed software FMEA수행

Analysis Limitations

1) Software FMEA는 software single point failure의 조건하에서 시스템의 행동을 분석한다.

대부분의 경우 single point failure의 assumption은 fully justify하기 어렵다

2) single point memory failure assumptions이 safe하지 않을 수 있음. 그 이유는 analyst가 모르는 것이 있을 수 있기 때문

3) software FMEA는 unfailed operation의 조건하에 있는 software intensive system의 행동에 대한 평가를 제공하지 못함

4) timing 변화와 관련된 safety risk에 대해 제한된 insight를 제공함. 이런 문제를 극복하기 위해worst case interrupt interval, resource demand에 대한 timing and sizing analysis가 software FMEA동안 수행되어야 할 필요가 있음.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s