기능안전(Functional Safety)

Railway system standards

깡또아빠 2019. 2. 10. 17:14

안녕하세요. 설날이 지났네요. 다시한번 새해 복 많이 받으세요.


요즘 개인적인 관심사로 표제의 내용으로 관련 표준과 서적을 읽고 있습니다.

참고로 관련 표준에서는 IEC 62279:2015를 서적으로는 "CENELEC 50128 and IEC 62279 Standards"를 보고 있습니다.

혹시 추천해주실 참고자료가 있다면 말씀 부탁 드립니다.


저의 경우에는 처음에는 전체를 파악하고, 한번 빠르게 본 다음, 관심가는 것이나 필요한 내용을 발췌하고 그리고 정독하는 스타일로 공부(?)하는 편입니다. 현재는 전체를 보는 아주 입문 of 입문 단계입니다.


Railway에서는 다음과 같은 형태로 시스템 구성과 관련된 표준이 있다고 이해하였습니다.



IEC 62278: Railway applications - Specification and demonstration of reliability, availability, maintainability and safety (RAMS)

IEC 62280: Railway applications - Communication, signalling and processing systems - Safety related communication in transmission systems

IEC 62279: Railway applications - Communication, signalling and processing systems - Software for railway control and protection systems

IEC 62425: Railway applications - Communication, signalling and processing systems - Safety related electronic systems for signalling


IEC 기준으로 표준 명을 기재하였습니다.

Railway에서는 IEC 국제표준명도 사용하지만, 대체적으로 해당 직군에 종사하시는 분들께서는 EN 명으로 말씀을 많이 하시네요. 그래서 위와 같이 두 표준명을 모두 기재하였으니 이점 참고 부탁 드립니다.


위 표준에서 저는 EN 50128, IEC 62279 소프트웨어 부분부터 먼저 보고 있습니다. 차근차근 천천히 기회가 되면 다른 것들도 보도록 하겠습니다.

해당 표준에서는 SIL (Safety Integrity level)을 역시나 0 (QM) 부터 4까지 정의하고, 각 레벨 별로 요구하는 방법(Technique/Measure)들을 정리하고 있었습니다.


ISO 26262를 주로 보는 저에게 좀 신선(?)했던 것은, SIL 레벨 별로 정의한 방법에서 combination 하는 경우 권장하는 룰이 있다는 것이었습니다.


Software architecture에서 SIL 3 또는 4의 경우를 예로 들면, 


1) 노란색으로 음영을 칠한 부분 (1,7,19,22)과 파란색 밑 줄 (4, 5, 12, 21)에서 하나의 방법을 조합하여 사용하는 것을 Approved 한다고 되어 있습니다.


오호라... 위에서 제시한 방법으로 조합하는 경우에는 Assessment에서 다른 Rationale, Evidence에 대해서 설명해야하는 수고(?)를 덜 수도 있겠구나 하고 생각해봤습니다.


다음으로 신선했던 부분은 Organization structure도 명확하게 정의를 하고 있다는 점이었습니다.


위 그림에서 선택적인 부분들도 있었습니다.

SIL 3 and 4에서 VER과 VAL이 동일인이 될 수 있었습니다. 물론 independence 가 필요합니다.


ISO 26262보다는 구체적으로 딱 딱 짚어주는 부분들이 장점이면서도, 유연하게 적용하기에는 어려운 부분이 있다고 생각도 들었습니다.

물론 Railway의 경우 자동차와 같은 Series 생산을 하지 않고, 분산 개발에 있어서 보다 한정적일 것이라고 생각됩니다. 이런 산업 부분에서는 위와 같은 요구사항이 필요할 수도 있겠다 싶었습니다.


또한 ISO 26262를 고려한 프로세스 정립 시 위와 같은 방법들, 특히 조직 구성에 있어서 Independence 를 고려한 부분들은 참고할 만하다고 생각되었습니다.


반대로 Tool evaluation의 경우 ISO 26262의 방법이 보다 구체적이라고 생각되었습니다.

해당 표준에서는 T1, T2, T3로 Tool Class를 구분하고, 요구사항과 Methodology를 언급하고 있습니다만 상대적으로 General하게 기술되어 있음을 알 수 있었습니다.


또한 빠르게 보았을 때에는 Software 개발에서 ISO 26262보다는 많은 산출물/결과물을 요구하고 있었습니다.

Software Deployment Manual, Application Preparation Verification Report, Overall software Test Report 등 여러 산출물을 명시하고 있었습니다. (프로젝트의 범위, 테일러링, 구체적인 전략에 따라 달라질 수 있습니다. 이러한 부분을 고려치 않고 보는 부분임을 감안해주시기 바랍니다.)


앞으로 개인적으로 Study 하는 내용들을 연구노트(?) 식으로 글을 올리도록 하겠습니다.

틀린 부분, 수정이 필요한 부분, 추가 내용이 있는 경우 댓글 꾹꾹 눌러주세요. (잇섭님 따라하기)


이상 읽어주셔서 감사합니다.