ISO 26262의 등장
Functional Safety (기능 안전)
- 기능적 고장에 의한 의도치 않은 Risk가 없는 것
- Hazard가 있는 시스템을 개발할 때는 요구 사항 분석 단계부터 Safety를 고려하여 안전 요구사항을 정립해야 한다.
- 제품 개발의 전 단계를 통해 안전 요구 사항이 지켜지도록 최선의 노력을 다해야 한다.
- 이를 통해 제품의 Malfunctioning으로 인한 Hazard의 Risk가 Tolerable한 수준으로 유지되어야 한다.
- Example
- 충돌 감지시 에어백이 터지는 것 자체는 기능 안전과 무관하다.
- 에어백은 사고시 Risk를 낮추어 Safety를 강화하기 위한 수단
- 에어백이 운전자의 생명을 구하는 것은 Functional Safety와 무관
- 에어백 시스템의 Hazard를 파악하여 Risk를 낮추는 게 Functional Safety
- 기능 안전 관점에서 Hazard의 예로는 센서나 제어기 오류로 인한 의도치 않은 에어백 전개가 있다.
Basic Concepts
- Hazard (위험원): 위험을 유발할 수 있는 원인 (뜨거운 물, 주전자)
- Harm (위해, 유해): 사망, 부상 등의 피해 (화상)
- Risk (위험도, 위험성): 위험의 정도를 확률로 표현
- Zero Risk는 존재하지 않기 때문에 Risk 최소화가 필요하다.
- Acceptable Risk: Safe state를 유지하기 위한 Risk 수준, 위험하다고 느끼지 않는 상태
- Tolerable Risk: 사회적으로 합의된 허용 가능한 Risk 수준
- Residual Risk: 안전 대책 적용 후에도 남아있는 Risk
- 안전 대책의 목적은 Residual Risk level을 tolerable risk level 까지 낮추는 것
SIL (Safety Integrity Level)
- Necessary Risk-ruduction와 같은 의미로, 상대적 위험 감소 수준 또는 목표 위험 감소 수준
- 위험도가 높은 시스템은 높은 SIL이 요구된다.
- 위험도가 낮은 시스템은 낮은 SIL로 Tolerable Risk에 달성 가능하다.
- 위험도가 Tolerable Risk보다 낮을 경우 SIL이 불필요하다.
Hazard Analysis and Risk Assessment (HARA)
- Risk Level of Hazards의 위치를 알아내는 과정으로, 결과적으로 SIL을 결정한다.
- 위험원 분석 (Hazard Analysis)
- 제품이 가진 위험원을 나열한다.
- 위험도 평가 (Risk Assessment)
- 각 위험원의 위험도를 평가
자동차 관련 법규
- 자동차관리법
- 환경 규제와 달리 자동차 안전 분야는 2003년부터 자기인증 방식이다.
- 자기인증 방식: 제작자 등이 자율적으로 확인하고 선언함으로써 인증을 완료하고 제작 또는 판매할 수 있도록 하는 제도
- ESC(횡 제어), AEB(긴급 제동) 등 전자제어 기반 안전기능이 법으로 의무화 되어있다.
- SW와 무관
- 소프트웨어 오동작으로 인한 위험원에 대한 대책, 즉 기능안전은 다루지 않는다.
- 환경 규제와 달리 자동차 안전 분야는 2003년부터 자기인증 방식이다.
- 제조물책임법
- 기능안전과 관련된 법
- 피해 규모의 최대 3배까지 징벌적 배상책임
- 레몬법, 징벌적 배상책임 강화가 추진되고 있다.
- 차량 제조사와 부품사에는 부담이지만 면책사유에 준하는 노력이 필요하다.
- 면책사유: 제조업자가 해당 제조물을 공급한 당시의 과학기술 수준으로는 결함의 존재를 발견할 수 없었다는 사실
ISO 26262
Automobilies EE systsms에 적용 가능한 기능 안전 표준
Functional safety standard for EE systems in automobiles
- V-Cycle 기반의 형태로 이루어져 있다.
- 모표준 IEC 61508에 기반을 둔다.
- 2011년 11월 Part 1~9가 제정되고 2012년 7월 Part 10이 제정되었다.
- 3.5톤 이하 양산 승용차에 설치되는 전기전자 기반 안전관련 시스템에 적용된다. 장애인 차량 등 특수차량은 해당하지 않는다.
- 2018년 개정된 2판에서는 트럭, 모터사이클 등으로 적용 대상이 확대되고 반도체 기능안전에 대한 내용이 추가되어 completed standard로 진화하였다.
ISO 26262 Structure
- Vocabulary
- Management of Functional Safety
- Concept Phase
- Product Development: System Level
- Product Development: Hardware Level
- Product Development: Software Level
- Production and Operation
- Supporting Processes
- ASIL-oriented and Safety-oriented Analyses
10.Guidelines on ISO 26262
ISO 26262 Safety Lifecycle
- Concept Phase는 OEM(완성차 회사)
- Product Development는 Supplier(공급 업체)
- After SOP(양산 이후)에는 OEM과 Supplier
1. Vocabulary
Important Terms를 정의한다.
2. Management of functional safety
- ISO/TS 16949, ISO 9001 등 품질관리 표준을 준수해야 한다.
- 회사, 조직, 프로젝트의 Safety Manager가 지정되어야 한다.
- 충분한 인력, 자원, 권한이 제공되어야 한다.
- Safety Culture: 안전을 최우선으로 하는 조직 문화 필요
3. Concept Phase
- Item definition: ISO 26262 적용 목표 시스템을 정확히 정의해야 한다.
- Item: 개발하고자 하는 것, ISO 26262가 적용될 시스템이나 기능
- ex) Airbag control system
- Initiation of the safety lifecycle: 새로운 시스템인지 기존 시스템의 변형인지 판단하여 safety plan을 결정한다.
- Hazard analysis and risk assessment: 위험원 분석, 위험도 평가, ASIL 결정, safety goal 결정
- 어떤 위험원이 있는지 brainstorming, 회의
- ASIL: Frequency(exposure), Damage impact(severity), Controllability를 기준으로 위험원의 위험도를 A에서 D까지로 표현한다.
- Exposure는 Hazard 자체에 얼마나 노출되었는지를 다루는 것이 아니고 예상되는 (잘못된) 사용 사례 중 특정 시나리오에서 시간 및 위치 측면에서 인체가 위험에 노출될 확률을 다룬다. 그 예로 "에어백이 터지는 시나리오에 얼마나 노출되어 있는가"가 될 수 있다.
- Severity에는 나중에 오는 부작용은 포함되지 않으며 직접적 부상, 사망이나 중상으로 이어지는지 판단한다. Score를 매길 때에는 부상 척도를 기준으로 S0부터 S3으로 구분한다.
- Controllability는 hazard를 막을 수 있는지를 나타내지 않고 부상을 피할 수 있는 확률을 의미한다. 예를 들어 터진 에어백을 다시 돌려놓을 수 있으면 controllability가 높아 C0 단계이다.
- OEM별로 Automotive Safety Integrity Level 기준이 존재한다.
- A는 낮은 레벨, D는 높은 레벨로 Brake, Steer이 D 레벨에 해당한다.
- Quality Management의 경우 안전화 무관하므로 ISO 26262 적용이 불필요하다.
- Risk Assessment: 얼마나 위험한 시스템인지 판단
- HARA Work Product Example
- Hazard: 의도치 않은 에어백의 전개
- ASIL: D
- Safety Goal: 의도치 않은 에어백의 작동을 피해야 한다.
- Safety State: 에어백은 사고 상황에서만 작동해야 한다.
- Fault Tolerant Time Interval (FTTI): 시스템이 fault를 버티는 time 0ms
- FRTI: 결함 감지 후 안전 상태에 도달하는 데 걸리는 시간
- FTTI: 위험한 이벤트가 발생하기 전에 시스템에 결함 또는 결함이 존재할 수 있는 시간 범위
- 에어백의 경우 0초
- Functional safety concept: Functional safety requirements 결정, 각 FSR을 시스템의 각 element에 배치한다.
- Safety Goal에 따라 FSRs가 결정된다.
- 에어백의 예시에서 Functional Safety Requirements
- 센서 오류로 인한 의도치 않은 동작은 피해야 한다.
- 컨트롤러 오류로 인한 의도치 않은 동작은 피해야 한다.
- 액추에이터 오류로 인한 의도치 않은 동작은 피해야 한다.
- 각 FSR는 architecture elements로 할당해야 한다.
4. Product development at the system level
- System Level Product Design
- Initiation: 안전 관점에서 제품 개발의 전체 계획 수립
- Technical Safety Requirement: FSR을 어떻게 만족시킬지에 대한 세부 요구사항 수립
- System Design: 안전 관점을 고려한 시스템 설계
- Technical Safety Requirement
- 각 FSR에 따른 TSR 도출
- TSR은 가정하는 기술 구조를 기반으로 구체적인 안전 메커니즘을 제시
- System Design
- FSR과 TSR을 만족시키는 시스템 디자인을 도출
- 다음의 안전 분석 기법을 사용한다.
- Deductive analysis(연역적, Top-Down)
- Inductive analysis(귀납적, Bottom-Up)
- Fault Tree Analysis(FTA)
- 연역적 분석
- Top-Down 방식으로 시스템의 Failure 시나리오를 분석한다.
- 1962년 미국에서 대륙간탄도미사일 개발을 위해 고안한 방법
- Top-level Hazardous Event에서 단계적으로 Root Causes 도출
- Root Cause에서 시작하는 확률적 분석
- ex) 소방 시스템
- Failure Mode and Effects Analysis
- 귀납적 분석
- Bottom-Up 방식으로 Failure 시나리오와 그에 대한 원인과 결과 분석 방식
- 1940년대 말부터 시작하여 미국 군수산업과 항공우주산업에서 시작되었다.
- 시스템 Failure의 모든 가능성을 worksheet 형태로 나열
- 무엇을 하는(function) 무언가가(item) 어떤 이유(cause)에 의해 어떻게(failure mode) 실패하면 어떤 결과(effect)가 생긴다. 이는 어떻게 검출(detection)할 수 있다.
- System Design 단계 주요 고려사항
- Random hardward failure 대처 방법 설계
- TSR은 HW 또는 SW에 배치되어 구현된다.
- HW-SW 인터페이스(HSI) 설계
- MCU에 프로그래밍하는 사람의 몫으로, Board Support Package 등이 있다.
- Hardward mode, Clock prescaler, Memory mapping 등
5. Product development at the hardware level
- Hardware Level Product Development
- Initiation: 안전 관점의 HW 개발 계획 수립
- HW safety requirements: 안전 관점의 HW 요구사항 도출
- HW Design: HW 설계
- Evaluation of HW architectuure metrics: SPFM and LFM
- Evaluation of safety goal violations due to random hardware failures: PMHF
- HW integration and testint
- Hardware Design
- Modular hardware design
- System level과 유사하지만 highly recommended가 조금 다르다.
- Safety analysis
- System Design과 동일
- Design verification
- 제작 전 절차 확인 방식으로, 회의하여 문제점을 찾는 walk-through 방식과 격식을 갖추어 검증하는 inspection 방식이 있다.
- Modular hardware design
- Failure mode Classes
- Safe Fault: 안전 목표를 위배하지 않는 안전한 오류
- Single-Point Fault: 하나의 Fault로 시스템 Fail
- 완벽 커버가 불가능해 안전 메커니즘이 미적용
- Residual Fault: 안전 메커니즘을 확률적으로 피해가는 Fault
- Detected/Perceived Multi-Point-Fault: 안전 메커니즘이 detect 가능하거나 운전자가 예방 가능
- 복수의 fault가 한번에 발생하여 안전 문제 발생
- Latent MPF: 감추어져 있는 MPF
- 감지되어가 예방할 수 없다.
- Fault 두 개가 동시에 발생할 확률은 매우 낮기 때문에 안전하다고도 볼 수 있다.
- 보수적으로는 여전히 불안한 문제
- Failure Model Classification
- Diagram
- Single-Pointn Fault Metric
- Latent-Fault Metric
- Random Hardware Railures
- Probabilistic Metric for random Hardware Failures
- Hardware Integration and Testing
- Testcase generation: 하드웨어 통합 및 테스트 사례 생성
- Safety Requirement Test: 안전 요구사항 테스트
- Stress Test: 시스템이 스트레스를 잘 버티는지 테스트
- 긴 시간 테스트해야 하기 때문에 시간이 빨리 흐르는 것처럼 극단적으로 테스트한다.
6. Product development at the software level
V-cycle in Part 6: 착수 이후로 요구사항 명세, 아키텍처 설계, 단위 설계 및 구현, 단위 테스트, 통합 테스트, 요구사항 검증의 단계로 진행된다.
각 단계마다 프로젝트 계획, 안전 계획, 기술안전 개념, 시스템 설계 명세서 등이 입력되고, 소프트웨어 검증 계획 및 보고서, 아키텍처 설계 명세서, 안전 분석 보고서 등 다양한 출력 산출물이 생성된다.
- 0. Initation
- 착수 단계에서는 코딩 관련하여 준비 사항, 코딩 지침이 포함된다.
- Complexity Measures
- Cyclomatic complexity measure(순환복잡도): Control Flow Graph로부터 해당 함수의 복잡도를 계산한다. 그래프에서 Edge의 개수에서 Node의 개수를 빼고 2를 더해 50을 넘으면 복잡도 관리 불가능으로 판단한다.
- pmccabe: 순환복잡도 측정 도구로 code line 수와 무관하다.
- Language Subsets
- Language Subset의 대표적인 표준으로 MISRA-C가 있다. 이는 C언어에서 사용하지 말아야하는 subset을 다룬다.
- Type System
- Static Typing(컴파일 시점에 변수의 타입이 지정되는 C언어)와 Dynamic Typing(실행 시점에 타입이 지정되는 파이썬)
- Strong Typing과 Weak Typing(type conversion)
- Graphical Representation
- Logic을 그림으로 표현하는 것
- 코딩 스타일 가이드와 작명 규칙
- Requirement Specifications
- 산출물: 소프트웨어 안전 요구사항 명세서
- Technical Safety Requirement에서 세부 요구사항을 도출한다.
- 산출물: 소프트웨어 안전 요구사항 명세서
- Architecture Design
- 계층 구조, 우선순위 기반 스케줄링이 강력히 권장된다.
- 자동차 영역에서는 소프트웨어 컴포넌트가 명확하게 설계된다.
- High Cohension-Loose Coupling
- Component 내부에서는 강하게 응집되고 Component 간의 연결성은 낮아야 한다.
- 소프트웨어 아키텍처 수준의 오류 검출 메커니즘(Code level에 가깝다)
- Parameter 값을 점검하는 것
- 주어진 제어 흐름에 따라 소프트웨어 실행이 제대로 흘러가는지 모니터링
- 소프트웨어 디자인을 분산
- 소프트웨어 아키텍처 설계 검증 방법
- 설계의 무결성을 수학적으로 검증
- 시험용 시스템 제작 등
- Unit Design and Implementation
- Design 단계에서 자연어 사용, ASIL 등급에 따라 적절한 notation을 사용해야 한다.
- Implamentation 시, 암시적 형변환, 암시적 data flow, 재귀 등은 금지된다.
- 단위 설계 및 구현 검증 방법
- Verification: 각 절차에서 product는 제대로 설계되고 있는가
- Validation: 올바른 product를 설계하고 있는가
- Code review를 통한 Verification
- Walkthrough: 개발자 주도의 비공식적 리뷰
- Code Inspection: 중재자 주도의 공식적 리뷰
- Semi-formal verification: Model 기반 설계, 시뮬레이션, 자동 코드 생성
- Online code review tools: Github, Gerrit
- Static Code Analysis: Syntatic, Semantic 분석 수행, AST
- Dynamic Code Analysis: 메모리 누수와 같이 실행 중에 분석 수행
- Unit Testing (Validation 시작)
- 단위 시험 방법
- Model과 Code의 결과 비교(타이밍, 성능, 소숫점 등)
- Test Case 생성: Input 값의 조합을 활용하여 function output 점검에 사용한다.
- 구조적 coverage
- Statement coverage: 개발 소스의 각 라인이 수행되었는지 확인하는 coverage
- Branch coverage: 각 분기문이 수행되었는지 확인하는 coverage로 T/F 각각 수행되어야 100% 달성된다.
- 단위 시험 방법
- Integration Testing
- 소프트웨어 통합 테스트 수행
- 통합 시험 방법
- 요구사항을 기반으로 interface, Fault injection, 자원 사용을 테스트한다.
- Test Case 생성하여 테스트한다.
- 구조적 coverage
- Unit 단위로 점검해야 하므로 line 별 점검은 불필요하다.
- Callee의 function coverage
- Caller의 call coverage: 함수 호출을 잘했는가
- Requirement Verifications
- 안전 요구사항 검증을 위한 시험 환경
- 실제 자동차로 테스트해야하며 ASIL 등급이 높으면 HiL이 강력히 요구된다.
- 새로운 ECU가 추가되면 ECU 데이터를 전송하며 테스트해야 한다.
- 안전 요구사항 검증을 위한 시험 환경
Hi, there 👋