2017년 4월 10일 월요일

소프트웨어공학 포털 웹진 기사 왕중왕전




ISO26262 : 자동차 분야 국제 표준

ISO26262 는 IEC61508 을 바탕으로 자동차 분야의 적용을 위해 2011 년 11 월에 발표된 표준이다. 자동차 ECU 의 오작동으로 인한 사고 및 인명손실을 최소화 하는 것이 목적이다.

ISO26262 는 명세, 설계, 구현, 통합, 검증, 인증에 이르는 개발 전 단계에서 최신 개발 방법 및 테스트 방법을 적용하도록 하고 있으며 기능안전 규격을 준수하기 위한 각 단계에서의 요구사항을 정의한다.

세부적으로는 시스템 레벨, 하드웨어 레벨, 소프트웨어 레벨에서 각 요구사항들이 정의되어 있다. 이는 제품 개념 단계에서부터 폐기까지 전 수명주기에 걸쳐서 전자장치의 고장으로 인한 자동차의 안전성을 저해할 수 있는 위험을 체계적으로 분석하고 그 위험에 대처하는 수단이 효과적임을 보장해야 하는 것으로서 시스템공학, 하드웨어, 소프트웨어 공학, 신뢰성 공학 안전성 분석 및 프로세스 능력이 모두 요구된다.

그림. ISO26262의 구성 

Part1 Vocabulary 는 표준에서 사용되는 용어, 정의, 그리고 약어를 설명하고 있으며, 총 142 개의 용어 및 정의와 53 개의 약 어로 구성되어 있다.

Part2 Management of functional safety 는 기능안전 관리를 위한 요구사항을 정의한 파트로 기능안전에 관련된 개발활동을 계획, 조정, 그리고 추적하는 요건에 대해 기술하고 있다.

Part 3 Concept phase 는 아이템 정의를 기반으로 위험원 분석 및 리스크 평가를 통해 ASIL 수준을 판정하며, 안전 목표와 안전 메커니즘을 정의 하는 파트이다. ASIL 은 대상 시스템이 달성하고자 하는 기능 안전성의 수준을 나타내는 것으로 최저 등급인 ASIL A 부터 최고 등급인 ASIL D 총 4 개의 등급으로 구성되어 있다. ASIL 등급이 높다는 것은 해당 시스템이 사고가 날 경우 그 피해가 심각할 수 있다는 것을 의미한다.

Part4 Product development at the system level 은 제품 개발 단계 중 시스템 수준에서의 개발을 명시한다. 시스템 수준의 개발은 기본적으로 V 모델을 따른다.

Part5 Product development at the hardware level 은 하드웨어 수준의 제품 개발을 기술하며, 시스템 설계 명세를 기반으로 하여 시스템의 하드웨어 개발이 이루어진다. 이 또한 시스템 내부에서 다시 V 모델을 따르며 개발, 통합, 검증에 대한 요구사항을 포함한다.

Part6 Product development at the software level 은 소프트웨어 수준의 제품개발 또한 V 모델을 따르며 개발, 통합 검증에 대한 요구사항을 정의하고 있다.

Part7 Production and operation 은 제품의 생산, 운영, 서비스, 그리고 폐기를 위한 요구사항을 포함한다.

Part8 Supporting processes 는 안전 요구사항의 명세 및 경영, 형상관리, 변경 관리, 검증, 문서화, 소프트웨어 도구 사용에 대한 신뢰, 사용증명 논거/주장 등에 대한 요구 사항을 정의하고 있다.

Part9 Automotive Safety Integrity Level (ASIL) – oriented and safety-oriented analysis 는 ASIL 과 안전에 기반한 분석을 위한 요구사항을 기술하고 있다.

Part10 Guideline on IOS26262 는 주요 개념, 안전 케이스, ASIL 분해 등 ISO26262 의 이해에 도움이 되는 정보를 기술하고 있다.

IEC61508. 기능안전이 구현된 하드웨어에 대한 요구사항

IEC61508 에는 기능안전이 구현된 하드웨어에 대한 요구사항이 정의되어 있다. 안전 요구사항에 따라 하드웨어를 설계하고 구현하는 것과 이것들에 대한 계획, 검증, 구조적 제한, 결함방지능력, 시험, 수정시 영향분석을 정의하고 있다.

또한 하드웨어는 정량적인 신뢰성 예측(고장율)을 통해 안전무결성수준을 검증하게 되는데, 다음과 같이 신뢰성 예측기술과 안전무결성수준 검증 기술을 다루고 있다.


  • 안전 요구사항 정의, 설계, 검증(validation), 확증(verification), 구조상 제약사항, 결함방지능력(fault tolerance), 시험, 수정활동과 같은 수명주기활동 정의 
  • 설정된 안전무결성수준 목표치에 대비하여 정량적인 신뢰성 분석을 통한 평가(예측)의 필요성을 설명하고 신뢰성 예측 
  • 시스템적인 하드웨어 고장에 대비하기 위한 기술과 절차 
  • SIL 에 대한 구조상 제약사항(architectural constraint) 정의 


IEC61508 에는 소프트웨어를 설계하는데 요구되는 활동 및 설계기술의 요구사항도 정의되어 있다. 안전 시스템의 구성 중 소프트웨어 경우 실제 고장률을 측정한다는 불가능하므로 주로 시스템이 결합되는 하드웨어 및 시스템의 전체 고장률 또는 허용 가능한 범위의 고장률을 결정하여 목표하는 SIL(안전무결성)을 결정한 다음, IEC61508 에서 제시하는 단계별 요구사항을 따르도록 하고 있다. 즉 SW 에 대해서는 SIL 에 대한 달성정도를 증명하지 않고, 단계별 기술 요구사항에 따라 수행해야할 활동에 대한 증거를 확인함으로써 목표하는 SIL 을 달성되었다고 가정한다. 이는 소프트웨어의 경우 수명주기 접근 방법에 따라 필수적으로 수행해야 할 활동들에 의하여 결함이 각 수명주기마다 추가되는 가능성을 낮추거나 방지 가능하다는 것을 전제로 하고 있다.

  • 소프트웨어라는 특성상, 시스템적인 고장에 대해서 다루고 있으며 정량적인 신뢰성 예측은 포함되지 않는다. 
  • 소프트웨어 설계기술들에 대해 각 SIL 마다 적용가능성과 수행해야할 활동에 대해서 표로 제공하고 있다. 


IEC61508 은 목표안전 달성을 위하여 먼저, 어떤 안전기능을 추가할 것인가를 결정(안전기능 요구사항)하고 그 다음으로 정의한 안전기능의 달성 가능한 정도(안전기능의 성능 정도)를 안전무결성 수준(SIL: Safety Integrity Level)으로 결정하는 절차를 제시한다.

즉, 시스템 전체 안전기능 요구사항은 안전무결성 요구사항(SIL)과 함께 구성되어 각 하위 시스템의 요구사항으로 할당함으로써, 하위 시스템의 구조 또는 각 시스템의 기능들을 구현하는 기술 및 측정법을 결정하게 되는 것이다. 안전 기능요구사항과 안전무결성 요구사항을 시스템 설계측면에서 그 역할의 차이를 구별한다면, 안전 기능 요구사항은 시스템을 구성하는 서브시스템(Sub-system) 또는 컴퍼넌트의 생성에 영향을 미치고, 안전무결성 요구사항은 구조에 영향을 미치는 것이다. 안전무결성 요구사항에 의해 시스템의 구조가 결정이 되고, 시스템의 구조를 어떻게 정의하느냐에 따라서 SIL 즉, 고장확률 수준이 결정된다고 할 수 있다.

안전공학(Safety Engineering) 측면에서 리스크(Risk) 제로상태는 불가능 하므로 허용가능한 수준의 위험까지 리스크를 줄이도록 하는 리스크 평가 및 관리가 오히려 더 중요. 이 점을 고려하여 International Electronic Commitment(이하 IEC)는 완전무결한 시스템은 불가능함을 수용하고 허용 가능한 범위의 리스크에 대해 정의하였다.

즉 IEC61508 의 기능안전 요구사항은 시스템의 위험한 사건의 원인이 될 수 있는 위험원에 대응 하도록 예측 가능한 모든 위험을 제거하고 남은 허용 가능한 위험수준을 안전무결성 요구사항으로 정의하여 시스템의 SIL 을 정의하도록 한 것이다.

또한, IEC61508 은 다른 안전 표준들과 달리 단순한 안전 요구사항만을 제시하는 것이 아니라 위험 감소를 위한 정량적인 측정법을 이용하여 구현된 안전 기능이 달성되었음을 평가 및 검증단계와 결합되어 있다. 평가 및 검증은 정성적인 평가뿐만 아니라 고장률, 즉 확률적 고장률을 이용한 안전무결성수준(Safety Integrity Level, SIL) 에 대한 정의를 통해 정량적인 접근을 제공한다.