기능안전(Functional Safety)

Protect method Processing Function

깡또아빠 2014. 12. 19. 15:42

ISO 26262를 하면서 표제와 같은 고민을 많이 하게 된다.


비 개발자로서 더욱 난감하고 어렵다.

그러니 더 노력하자


ARM techcon에서 발표한 자료 중에 해당 내용에 있어서 공유한다.




위 4가지 방법을 하나씩 보자.

지금부터 적는 글/내용은 나 혼자 판단해서 적는 글이오니, 이점에 대해서 자문이 있다면 적어주시기 바랍니다.


1. Single 32b device with 8/16b checker device



장점

1. 상대적으로 저렴한 비용

2. 다양한 하드웨어를 통해 Safety 가능


단점

1. 높은 SIL (Safety Integrity level)에는 적용이 어려움

2. 빈번한 온라인 모니터링으로 인한 프로세스 전력에 제한이 있을 수 있음


위에 해당하는 ISO 26262 안전 메커니즘은 무엇일까 생각해보았다.


개인적인 판단으로는 Failure detection by on-line monitoring (온라인 모니터링에 의한 고장 검출)에 해당한다고 보여진다.

해당 안전 메커니즘(Safety mechanism)의 구현 가능한 기본 진단 커버리지는 Low (60%)이다.


즉 앞서서 글을 적었던 내용을 바탕으로 하면, residual fault는 40%가 된다는 것이다.




2. Dual devices with external compare of safety outputs and optional SW message passing



장점

1. 높은 (A)SIL에 적용이 가능

2. non-safety와 관련된 중요 task에 적용 가능

3. 구현의 용이성

4. 중복 구현


단점

1. 복잡도 증가

2. 추가 비용, 추가적인 공간 필요


독립적으로 디바이스를 추가하여 처리된 결과를 비교하여 해당 값을 결정하게 된다.


ISO 26262에서는 이러한 Comparator (비교기)에 방법의 커버리지는 High (99%)에 해당된다.


ASIL D와 같은 경우 위에서 말하는 Dual devices를 고려하는 것에 깊은 고민을 해야겠다는 생각을 해본다.




3. Device with internal safety logic (CPU) in lock-step



장점

1. 높은 (A)SIL에 적용이 가능

2. 보드에 들어가는 공간을 줄일수 있음

3. SW 복잡도를 줄일 수 있음


단점

1. 개별적으로 맞춤형 구축이 필요

2. 결국 같은 CPU를 통한 처리



ISO 26262에서 해당하는 내용은 무엇일까를 생각해보았다.


아마도 Software diversified redundancy (one hardware channel)이 아닐까 싶다. 해당의 경우 가능한 커버리지는 High (99%)이다. 


한 개의 하드웨어 내에서 소프트웨어 처리를 통한 방법은 앞서서처럼 Dual device로 하는 경우보다는 부족함이 있다고 생각되었다.


한개의 CPU에서 2 개로 수행되는 결과값을 비교하기 때문에 CPU 자체의 failure가 발생할 경우를 대비하여 redundancy를 확보하지 못했기 때문에 그렇게 생각해 보았다.




4. Single device dual CPU (not in lockstep) with internal self test




장점

1. 높은 (A)SIL에 적용이 가능

2. non safety와 같은 중요한 task를 위한 멀티 코어 성능이 가능


단점

1. 개별적으로 맞춤형 구축이 필요

2. Safety SW 동기화를 위해 복잡도가 증가



으흠... 비 전공자는 더더욱 노력해야겠다는 생각을 해봤다;;


각 CPU에서 계산된 값을 바로 쏴주고, 내부적으로 테스트하여 수행한다는 것 같다.

이 또한 앞선 사례와 같은 1개의 device 내에서 처리되어진다.


ISO 26262에서 맞는 안전 메커니즘을 생각해보았다.

뭐가 있을까?


천천히 생각해보자.

앞선 그림들과 비교해보았을 때, compare가 빠져있다.

이는 우선 결과값에 대하여 비교하는 연산처리 부분이 없다는 내용일 것이다.


그리고 M이라고 표시된 부분은 뭘 하는지 모르겠다만...

CPU 1, CPU 2에서 처리된 내용을 주고 받고 하는 것 같다. 아마도 내부적인 Self test를 하기 위한 다이어그램이라고 생각된다.


아마도 Self-test by software cross exchange between two independent units 에 해당하는 것 같다. 

근데 ISO 26262에서는 이 안전 메커니즘에 대허서 진단 커버리지는 Medium (90%)로 보고 있다.


IEC 61508에서 SIL 3는 ASIL C도 가능하다면... 말이 될 것 같다.


여기서 잠시 딴 곳으로 빠져서 그러면 IEC 61508의 SIL 과 ISO 26262에서 ASIL의 등급 비교는 어떻게 될까?

IEC 61508을 본적이 없어서.... 확신이 서지는 않지만,


 


대략 그림으로 보니 SIL 3은 ASIL에서는 B, C, D까지 가능하다. 

맞는 것 같지만, 이렇게 직접 그림으로 보니 더 난감한 부분이 생기는 것 같다.


여튼..


Functional safety 는 재 밌다? ㅎ


여기서 이만 끝.



불금 되세요~ 



'기능안전(Functional Safety)' 카테고리의 다른 글

(Safety) requirements specification 중 UML 소개  (0) 2016.08.03
ACC 시스템  (0) 2015.10.04
Item definition  (0) 2014.12.18
Failure mode classification of hardware element  (2) 2014.12.18
Dependent failures  (1) 2014.12.10