기능 안전 배경/정의 및 이슈 - 2번째
표준에서의 안전의 의미를 되새기기 전에 모든 제품은 완벽한(Complete) 위험이 없는 상태이거나 결함(Defect)이 없는 상태를 구현하는 것은 이론적으로는 가능할 수 있으나 실제적으로는 구현이 불가능하다. 즉 Risk Zero 및 Zero Defect은 불가능한 영역이다.
그러므로, 안전한 제품에 대해 어느 정도 Risk를 허용하는 기준이 필요하다. 이러한 허용 기준에 대해서는 Risk의 레벨로 결정 한다.
다시 말해, 완전히 Risk가 없는 상태는 불가능하므로 실제 기술적으로 제거 가능(설계나 검증을 통해)한 범위를 제외한 Risk는 제품에 내재되어 있다고 가정한다. 이러한 개념을 적용하여 해당 제품이 수용 가능하거나 불합리한(부당한) Risk가 없는 상태를 안전 상태로 규정한다.
기능 안전 표준(차량뿐만 아니라 모든 안전관련 제품 포함)도 이러한 개념을 적용하여 안전을 정의하고 있다.
[자동차 분야에서의 Functional Safety(기능 안전)의 정의]
차량 분야의 대한 안전의 의미는 여러 가지 의미가 있지만 위의 설명대로 2가지 관점을 의미(Substantive Norms과 Normative Norms)한다.
나아가 품질/브랜드와 연관되어 2가지 의미가 발전하여 인지적인(Perceived Norms : 소비자의 안전에 대한 인식) 안전을 평가 받을 수 있다.
[기능 안전(Functional Safety)의 전반적인 이해]
기능 안전은 본질적인 의미는 관련 제품(시스템)과 상호 작용하는 사람과의 관계 측면에서 도출된다. 즉, 차량의 경우는 운전자/조수석 탑승자, 승객(Passengers), 보행자, 다른 차량에 탑승한 인원에 대해 기능적인 문제 발생(오 동작 – Malfunction)으로 이러한 인원들이 상해 또는 피해를 입는 상황이 없도록 기능이 정상적으로 동작해야 하는 상태를 의미한다.
단 차량의 경우 대량생산 및 경제적인 이유로 인해 모든 기능을 완벽하게 설계 할 수 없으므로 (기술적 한계 및 대량 생산에 따른 Cost적인 측면의 이슈 등) 이러한 문제점을 회피하기 위해 운전자 면허(Driver license)가 있는 사람만이 운전하도록 규정하고 또한 운전자 매뉴얼을 통해 관련 문제점이 발생할 수 있는 사실을 알리고, 또한 문제 발생시 계기판에 있는 Alarm 기능을 통해 문제점을 운전자에게 알리도록 되어 있음
기능 안전(Functional Safety)의 표준(ISO 26262)의 정의 - OEM에서의 위험 수준 정의
기능 안전 제품의 구현하기 위한 방안은 주로 OEM 영역에서는 다음과 같은 활동을 수행한다.
- 대상 제품의 범위 정의 : 어떤 제품을 개발할지 정의하는 단계로 개발 할 제품에 대한 기능의 정의 및 관련 안전 기능 등을 도출하는 개념 단계 필요하며, 추가적으로 이 제품이 운영자 또는 다른 제품(시스템)과 어떤 정보를 주고 받는지 정의(Interface 개념)
è 기능 안전 표준 : Part III의 아이템 정의(Item Definition) 단계 임
- 제품의 위험요소 도출 : 개발하려는 제품에 대해 사전에 관련 기능들이 제품의 운영(Operation)에 따른 오 동작 시 어떠한 위험 상황들이 발생하는지를 분석하고 평가하는 단계 (오 동작 도출, 오 동작 시 어떠한 환경 및 동작 조건에 따라 어떤 위험들이 발생하는지를 정의)
- 제품의 안전 레벨 정의 : 개발대상 제품마다 오 동작에 따른 위험의 심각도가 다르게 나타난다 (예를 들면, 고속과 저속/ 차량이 많은 곳과 적은 곳 등) 이러한 주변환경과 기능에 따라 제품에 대한 위험 등급을 결정한다. 차량의 경우 ASIL (Automotive Safety Integrity Level)이며 일반 다른 제품의 경우 (항공 및 철도차량의 경우 SIL : Safety Integrity Level)을 정의한다.
기존에 제품 품질(Quality)를 높이는 방법으로 개발(R&D) 관점보다는 주로 생산관점에서 많은 노력을 기울여 왔다. 특히 ISO9001이나 자동차의 제조 품질을 위해 TS 16949 같은 표준들을 적용하여 예를 들면 국내 모 완성차 업체는 PSO10단계(현재 PSO12단계)를 통해 설계 품질(예 FMEA 및 초기 설계 시 제품의 특별 품질 특성 및 품질 목표 등을 개발 초기에 강제)을 올리고, 생산관련 품질을 위해 Process FMEA 및 양산 승인을 위한 품질 노력들을 기울여 왔지만, 이러한 노력으로는 개발 단계에서 발생할 수 있는 문제를 사전에 방지하기가 어려워(특히 소프트웨어의 문제) CMMI(Capability Maturity Model Integration) 및 ASPICE(Automotive Software Process Improvement and Capability dEterminatioin)같은 국제 개발 프로세스 성숙도 모델을 도입함으로 개발 품질을 향상시키는 상황이다.
하지만 Safety 관점 보다는 Quality (품질)관점에서 개발 프로세스를 적용하다 보니, Mission and Safety-Critical and Intensive 제품에 대한 고장 방지 및 고장을 통제 할 수 있는 부분이 도메인 별 또는 시스템별로 엔지니어의 역량에 의존하는 방법으로는 분명 한계를 노출하고 있다. 이러한 관점에서 Safety 부분을 어떤 방법으로 표준화하고 강제 할 것인지가 이슈화 되어 있다.
요약하면, 위의 오른쪽 Dimension 차원에서 보듯이, 개발 역량 + 조직 역량 이외에도 안전관련 부분에 대한 새로운 축이 발생하였고, 즉 2차원적 과점에서 3차원적 관점으로의 인식의 전환이 필요하다. 그리고. 왼쪽 그림에서와 같이 품질 관점의 QMS(Quality Management System)에서 SMS(Safety Management System)으로 모든 개발/생산을 Safety를 최우선시 하는 체계의 변경이 진행되고 있다.
'기능안전(ISO26262)' 카테고리의 다른 글
기능 안전 역사 및 표준 종류 (0) | 2016.03.07 |
---|---|
Model Based Development (모델기반 개발) in Safety Critical Domain - (0) | 2016.03.01 |
기능 안전 배경/정의 및 이슈 - 첫번째 (0) | 2016.02.22 |
Engineering Tool Chain - 기능안전/A-SPICE 및 CMMI 기반 요건 (0) | 2016.02.19 |
요구사항관리 in ISO26262 (0) | 2015.04.28 |