(paper comment) Bridging software and hardware FMEA in complex systems


This paper address FMEA that should cover boundary between SW scope and HW scope. Considering FMEA in the SW application level of the layered architecture), it seems to be quite different.

It depends on scale of system’s size, but it covers method how to work together with system engineer, Low level SW engineer, and EE engineer.

Scope of SW level in the paper is not application level, but firmware level.

Someone may think that device drivers are outsourced from vendors, so it does not related to them. Even though it may be true, it can be related to FMEDA based on EE schematics in supplier side, and it is common problem of confusing about scope when engineers perform safety analysis. As a result it is worth reading it.

It published in 2013, and is still useful.

 

소프트웨어와 하드웨어의 경계상에 있는 지점에 대한 FMEA를 수행하려고 할 때 고려해야 할 점이다.

순수하게 application level에서 보면(layered architecture상에서 봤을때), 굉장히 거리감이 있다고 볼 수 있다.

시스템의 규모에 따라 다를 수 있을 것으로 보이는데, 이 내용은 시스템, low level SW, EE엔지니어가 co-work를 하기 위한 방법이라고 볼 수 있다.

소프트웨어의 어플리케이션 레벨은 아니고 firmware 레벨이라고 볼 수 있다.

어떻게 생각하면, 디바이스 드라이버의 경우는 공급을 받는 쪽에 가깝기 때문에 아마도 이런 수준까지 고려하지 않고 외주를 받아서 처리하는 방식으로 간주할 수 있을지도 모른다.

그럼에도 불구하고 EE레벨의 회로도를 기반으로 FMEDA와 맞닿는 부분이 있을 수 있기 때문에, 또한 실무적으로 안전 분석을 하게 될때 흔하게 발생하는 문제인 scope과 관련된 혼동이 있기 때문에, 이 논문은 그런 점에서 읽을만한 가치가 있다.

논문은 2013년 논문인데, 현재도 여전히 유용한 것 같다.

SW FMEA based on DFMEA


There are several formats in FMEA, and the format or direction of analysis may vary slightly. The DFMEA mentioned in the title is a design fmea, which usually seems to refer to the FMEA for the EE design.

It may seem similar at the time of SW FMEA, or at the system level, but I don’t think that I should follow any particular form in my opinion.

In any case, the dfmea process is shown below. I didn’t like it here; ‘Why is there a procedure to find the cause?’ . If a cause can be found, it must be exhaustive. You should not find only part of it. If only a partial search is made, problems can still occur in the latent faults. So in the case of software, I wondered if this was appropriate.

Considering the safety mechanism in the figure below is to investigate and prescribe the cause of the failure, not the failure, and to find the cause is not a bottom up but rather a rather weird way to start from the middle and go down and back up. I thought that
(finding cause is moving down, not moving up.)
. The function of the item in the first step is not bottom. It’s not atomic.

From a software perspective, analysis in this way results in a rather absurd analysis such as os fault, exception, divide by zero, misra violation, and so on.

Isn’t it just FMEA to find them? Those are some kind of common faults, you just have to check the list if you just have a list. Do you have a hard time analyzing it? If it’s not specific to a particular feature, why?

If you’re trying to cascade fmea, it’s also different. So why don’t you analyze? If this is not the case, it is necessary to flex the direction.

 

Reference


FMEA에 여러 양식이 있고, 그 양식에 따라서 분석의 방법이나 방향이 약간 달라질 수 있다. 제목에서 말한 DFMEA는 design fmea로서 보통은 EE설계도에 대한 FMEA를 지칭하는 것 같다.

SW FMEA를 할 때, 혹은 system수준에서 할때도 비슷할 것 같긴 한데, 개인적인 생각으로 어떤 특정한 양식을 반드시 따라야 한다고 생각할 필요는 없다고 본다.

어쨋든, dfmea프로세스에 대해서 아래 그림과 같이 되어 있다. 여기서 좀 마음에 들지 않았던 부분은 왜 cause를 찾을려고 하는 것인가? 에 대한 것이었다. 만약 cause를 찾을 수 있는 것이라면 그것은 exhaustive하게 다 나와야 한다. 일부분만 찾아서는 안되는 것이다. 부분적으로만 찾으면 남겨진 부분에서 여전히 문제가 발생할 수가 있는 것이다. 그래서 소프트웨어의 경우에 이게 적당한지에 대한 의문을 가졌었다.

아래 그림에서 safety mechanism을 고려하는 것은 해당 고장이 아닌 그 고장의 원인을 추가로 조사해서 처방하는 것이고, cause를 찾는 것이 bottom up이 아니고 middle-bottom-up의 방식이라고 생각이 들었던 것이다, 여기서 첫번째 step의 item의 function은 bottom이 아니다. atomic하지도 않다.

소프트웨어 관점에서 이 방식으로 분석할라고 하면 os fault, exception, divide by zero, misra violation,등과 같은 약간 황당한 방식으로 분석이 되어서 결국은 의미 없는 분석이 되어버리고 만다.

저런거 찾을라고 FMEA를 하는게 아니지 않은가? 저 원인들은 일종의 common fault들이다, 그냥 목록만 갖고 있으면 체크리스트 점검을 하면 되는거지, 뭣하러 수고스럽게 분석을 하겠는가? 특정 기능에 특화된 것도 아니라면, 굳이 왜??

cascade fmea를 하려고 한다면 저 방식과는 또한 차이가 있다. 그러므로 분석을 해보다가 어? 이 길이 아닌가보다 하면 유연하게 방향을 틀어야 할 필요가 있다.

참고

SW fault propagation model


systematic fault와 random hardware fault를 전부 고려해서 하려고 하긴 했다. 여기서 전부다 sw에서 처리하라고 하면 개발할 수 없다고 아우성을 칠 것이다. 좋은 칩을 사서 하드웨어 레벨의 고장은 거기서 걸러진다고 봐야 한다.

그러면 남은게 몇개 안되는데, 그것을 가지고 sw fmea를 하면 되는데, 사실상 fault에 대한 처리방법은 정답지와 같은 해결책이 옵션으로 몇개가 나온다. 생각해보면 답 나오는데, 그 중에 어플리케이션에서 적당한 것을 고르면 된다.

아래 그림은 해당 fault에 대응할 수 있는 safety mechanism이다. 하드웨어 레벨에서 거르는 것은 녹색으로 표시되었다. 그림에서 회색은 systematic fault인데, 일반적으로 이 부분을 safety mechanism으로 커버해야 하는지는 의문이 있기는 하지만(설계가 잘못된 것이므로), 유연하게 생각해서 고려할 수도 있을 것이라 생각한다. 다만, 기본적으로는 optional이라고 봐도 무방할 것 같다. procedure에 의해 걸러질 수 있을것이기 때문이다. 노란색은 AUTOSAR에서 지원되는 메커니즘들이다.