1. 서론: 자동차 제어 시스템의 안전 기능 분류의 딜레마
자동차 전자제어 시스템(E/E Systems)의 복잡성이 기하급수적으로 증가함에 따라, 기능 안전(Functional Safety)의 확보는 차량 개발의 가장 핵심적인 과제로 인식되고 있습니다. ISO 26262 표준은 이러한 안전성을 체계적으로 확보하기 위한 방법론을 제시하며, 특히 시스템의 오작동으로 인한 위험(Hazard)을 허용 가능한 수준으로 완화하기 위해 다양한 안전 메커니즘(Safety Mechanism)과 아키텍처 설계를 요구하고 있습니다.
본 글에서는 기능 안전 적용 과정에서 빈번하게 발생하는 핵심적이고 구조적인 질문, 즉 “기존의 의도된 기능(Intended Function)”과 “ASIL 분해(Decomposition)를 통해 QM(Quality Management) 등급으로 할당된 기능”을 “안전 기능(Safety Function)”으로 분류할 수 있는가? 입니다.
기능안전의 적용은 구체적으로 안전 목표(Safety Goal)에 영향을 주는 의도된 기능이 고장 났을 때 이를 감지하고 조치하는 독립적인 안전 메커니즘을 개발하고, 이를 통해 의도된 기능을 QM 레벨로 설정하며, 간섭 무결성(Freedom From Interference, FFI)을 만족시키는 것을 전제하고 있습니다.
이러한 상황에서 QM으로 지정된 의도된 기능이 과연 안전 기능의 범주에 포함될 수 있는지에 대한 의문은 단순한 용어 정의를 넘어, 안전 목표의 달성 전략, 하드웨어 및 소프트웨어의 개발 프로세스, 그리고 최종적인 안전 입증(Safety Argumentation)의 논리적 구조를 결정짓는 기준입니다.
이 문제를 해결하기 위해서는 ISO 26262 표준이 정의하는 용어의 엄밀한 의미, ASIL 분해의 수학적 및 논리적 배경, E-GAS 컨셉과 같은 산업 표준 아키텍처의 철학, 그리고 간섭 무결성이 가지는 구조적 함의를 포괄적으로 고찰합니다. 본 내용에서는 이러한 요소들을 다각도로 분석하고, QM으로 할당된 의도된 기능은 ‘안전 관련 요소(Safety-Related Element)’에는 해당하지만, 엄밀한 의미에서의 ‘안전 기능(Safety Function)’으로는 분류될 수 없음을 설명하고자 합니다.
2. ISO 26262의 “의도된 기능”과 “안전기능”의 이원론
기능 안전 표준에서 용어는 단순한 명칭이 아니라 해당 요소가 시스템 내에서 수행하는 역할과 책임을 규정하는 법적, 기술적 구속력을 가집니다. 따라서 질문의 핵심에 접근하기 위해서는 먼저 ISO 26262 Part 1 (Vocabulary)과 관련 문헌들이 정의하는 ‘기능(Function)’의 이원론적 구조를 명확히 이해해야 합니다.
2.1 의도된 기능(Intended Function)의 정의와 본질
의도된 기능은 시스템이 존재한 본래의 목적을 수행하는 동작을 의미하며, 이는 차량의 거동을 제어하거나 사용자의 편의를 제공하기 위해 설계된 핵심 로직입니다. 예를 들어, 전기차(EV)의 트랙션 모터 제어 시스템에서 운전자의 가속 페달 입력에 따라 토크를 생성하여 차량을 전진 또는 후진 시키는 행위, 혹은 전동식 파워 스티어링(EPS) 시스템에서 운전자의 조향 의지를 보조하기 위해 모터를 구동하는 행위 등이 이에 해당됩니다.
의도된 기능의 가장 중요한 특징은 그것이 위험(Hazard)의 잠재적 원천이라는 점입니다. 기능 안전의 관점에서 볼 때, 의도된 기능이 설계된 대로 완벽하게 작동할 때는 가치를 창출하지만, 오동작(Malfunction)을 할 경우에는 즉각적인 위험을 초래합니다. 엘리베이터가 사용자의 층수 요청에 따라 움직이는 것은 의도된 기능이지만, 문이 열린 채로 움직이거나 과속으로 하강하는 것은 의도된 기능의 오작동이며, 이는 곧 승객의 안전을 위협하는 위험원이 됩니다. 따라서 의도된 기능은 ‘안전(Safety)’을 목적으로 하는 것이 아니라 ‘성능(Performance)’을 목적으로 하며, 안전 분석의 대상(Target of Analysis)이 됩니다.
ISO 26262는 의도된 기능의 수행 능력이 전자 시스템의 핵심이라고 정의하며, 여기에는 제동, 조향 등 안전에 치명적인 영향을 줄 수 있는 기능들이 포함된다고 명시합니다. 그러나 ‘안전에 치명적인 영향을 주는 기능’이라는 표현이 곧 ‘안전 기능’을 의미하는 것은 아니며, 이는 해당 기능이 고장 날 경우 심각한 사고로 이어질 수 있다는 ‘안전 관련성(Safety-Relevance)’을 의미할 뿐, 그 기능 자체가 사고를 예방하는 실체임을 의미하지 않습니다.
2.2 안전 기능(Safety Function)의 정의와 역할
반면, 안전 기능은 시스템의 고장이나 오작동이 발생했을 때 위험한 사건(Hazardous Event)이 발생하는 것을 방지하거나 그 영향을 완화하여 시스템을 안전 상태(Safe State)로 유도하는 기능을 의미합니다. 안전 기능은 HARA(Hazard Analysis and Risk Assessment)를 통해 도출된 안전 목표(Safety Goal)를 달성하기 위해 존재하며, 그 자체로 시스템의 성능을 높이는 것이 아니라 리스크를 줄이는 데 목적이 있습니다.
안전 기능의 핵심은 ‘보호(Protection)’와 ‘통제(Control)’에 있으며, 트랙션 모터 예시에서, 모터가 과도한 토크를 생성하여 급 발진할 위험이 있을 때, 이를 감지하고 인버터의 전원을 차단하거나 토크를 0으로 만드는 기능이 바로 안전 기능입니다. 이 경우 안전 기능은 의도된 기능(토크 생성)을 억제하거나 중단시키는 역할을 수행합니다. ISO 26262는 안전 기능에 대해 ASIL을 할당하며, 이는 해당 기능이 수행해야 할 리스크 감소의 수준을 정량적, 정성적으로 요구합니다.
중요한 점은 안전 기능이 반드시 별도의 하드웨어로만 구현되는 것은 아니라는 점이며, 하나의 ECU 내에서 소프트웨어적으로 구현될 수도 있고, 별도의 센서나 액추에이터를 포함할 수도 있습니다. 그러나 개념적으로 안전 기능은 의도된 기능과 구별되는 ‘감시자(Monitor)’ 혹은 ‘보호자(Guardian)’의 위치에 있습니다. 즉 안전 기능은 시스템이 의도되지 않은 사용이나 오용 상황에서도 특정 기능을 올바르게 수행하거나 위험한 고장을 자동으로 방지하도록 설계된 상태를 의미한다.
2.3 안전 메커니즘(Safety Mechanism)과 안전 기능의 관계
안전 메커니즘은 안전 기능을 구현하기 위한 구체적인 기술적 수단이며, 이는 고장을 탐지(Detection)하거나 고장의 영향을 제어(Control)하여 안전 상태를 달성하는 하드웨어적, 소프트웨어적 장치를 의미합니다.
일반적으로 안전 기능은 하나 이상의 안전 메커니즘들의 조합으로 구성되며 예를 들어, “과속 방지”라는 안전 기능을 수행하기 위해 “휠 속도 센서 모니터링(고장 탐지)”, “토크 계산 값 비교(오류 탐지)”, “연료 차단 밸브 제어(안전 상태 천이)”라는 세부 안전 메커니즘들이 유기적으로 작동해야 합니다. 따라서 아키텍처 상에서 안전 메커니즘은 안전 기능의 실체이며, 의도된 기능이 오작동할 때 최후의 방어선 역할을 수행합니다.
2.4 안전 관련 요소(Safety-Related Element)와의 혼동 방지
가장 빈번하게 발생하는 오해는 ‘안전 관련 요소’와 ‘안전 기능’을 동일시하는 것입니다. 안전 관련 요소는 안전 목표를 위반할 잠재력을 가진 모든 요소를 지칭하며, 의도된 기능이 고장 나면 안전 목표를 위반할 수 있으므로, 의도된 기능은 명백히 ‘안전 관련 요소’입니다. 그러나 어떤 요소가 안전과 관련되어 있다는 사실이 그 요소가 안전 기능을 의미하지는 않습니다.
마치 칼(Knife)이 위험하므로 ‘안전 관련 도구’이지만, 칼 자체가 ‘안전 장치’는 아닌 것과 같으며, 칼집이 바로 안전 장치(안전 기능)가 됩니다. 칼이 없으면 요리를 할 수 없으므로 칼은 ‘의도된 기능’을 수행하고, 칼집은 요리를 하지 못하지만 사용자가 다치지 않게 하므로 ‘안전 기능’을 수행합니다. 즉, QM으로 할당된 의도된 기능은 칼과 같고, ASIL D로 할당된 모니터링 메커니즘은 칼집과 같습니다. 칼을 아무리 잘 만들어도(QM 수준의 품질 관리), 그것이 칼집의 역할을 하는 것은 아닌 것입니다.
3. ASIL 분해의 구조적 해석과 QM(D)의 의미
ASIL 분해 란, 안전목표(Safety Goal)에 요구되는 높은 ASIL 수준의 요소를 여러 개의 독립적인 기능 또는 아키텍처 요소로 나누어 할당함으로써, 각 요소가 더 낮은 ASIL 수준을 가지더라도 전체적으로는 원래의 안전목표와 동등한 위험 저감 효과를 달성하도록 설계하는 방법입니다.
3.1 ASIL 분해의 대수학(Algebra)과 논리
ASIL 분해는 리스크 감소의 책임을 분산시키는 과정입니다. 원래의 안전 목표가 ASIL D 수준의 무결성을 요구한다고 가정하고, 이를 단일 경로로 처리하려면 그 경로의 모든 부품과 소프트웨어가 ASIL D 수준으로 개발되어야 합니다. 이는 비용과 기술적 난이도 측면에서 매우 부담스럽고, 따라서 시스템 아키텍처를 ‘기능 수행 경로’와 ‘모니터링 경로’로 분리하고, 이 두 경로가 동시에 고장 날 확률이 낮음(독립성 확보)을 증명함으로써 각각의 경로에 낮은 ASIL을 할당하는 것입니다.
예. ASIL D → QM(D) + ASIL D(D)
여기서 중요한 점은 이 수식이 성립하기 위한 전제 조건이 필요하며, 두 요소(QM 경로와 ASIL D 경로) 사이에는 충분한 독립성(Independence)이 보장되어야 하며, 만약 두 요소가 종속 고장(Dependent Failure)을 일으키고, 즉 의도된 기능의 고장이 모니터링 기능까지 무력화시킨다면, 분해는 무효화되고 QM(D)는 원래의 ASIL D 요구사항으로 복원되어야 합니다.
3.2 QM(D) 표기법의 의미
분해 결과로 얻어진 QM(D)라는 표기는 단순한 QM(Quality Management)과는 본질적으로 다르며, 괄호 안의 (D)는 이 요소가 본래 ASIL D 안전 목표의 달성에 기여하고 있음을 나타내는 ‘꼬리표(Tag)’입니다.
1) 품질 관리 수준: QM(D) 요소는 ISO 26262의 안전 생명주기(Safety Lifecycle)에 따른 엄격한 안전 프로세스 대신, IATF 16949나 ISO 9001 등의 표준적인 품질 관리 프로세스를 따라 개발되며, 이는 개발 비용과 시간을 절감하는 주된 요인입니다.
2) 안전 책임의 면제: QM(D) 할당은 해당 요소가 “스스로 안전을 보장할 필요가 없다”는 것을 의미하며, 시스템의 안전 논리(Safety Argument)에서 QM(D) 요소는 ‘신뢰할 수 없는’ 부분으로 간주됩니다. 안전 개념은 “QM(D) 요소는 언제든지 고장 날 수 있으나, ASIL D(D) 요소가 이를 100% 감지하고 차단할 것이므로 전체 시스템은 안전하다”는 논리 위에 전개됩니다.
3) 안전 관련성 유지: 비록 개발 프로세스는 QM 수준이지만, 이 요소는 여전히 안전 관련 시스템의 일부입니다. 따라서 형상 관리, 변경 관리 등의 측면에서 추적성이 유지되어야 하며, 특히 ASIL D(D) 요소와의 인터페이스 변경 시 엄격한 영향성 분석이 요구되며, 통합 시 반드시 ASIL D 수준의 검증 활동을 요구합니다
3.3 QM(D) 요소는 안전 기능인가?
이 점에서 “QM(D) 분해된 요소”는 안전기능인가의 질문에 대한 답은 결론적으로 “안전 기능이 아니다” 입니다. 그 이유는 다음과 같습니다.
- 목적의 불일치: 의도된 기능의 목적은 차량의 거동(토크 생성 등)을 구현하는 것이지, 위험을 방지하는 것이 아니며, 위험 방지는 전적으로 ASIL D로 할당된 안전 메커니즘이 담당 합니다.
- 요구사항의 부재: 안전 기능의 정의상, 안전 기능은 안전 목표를 달성하기 위한 구체적인 안전 요구사항(Safety Requirement)을 수행해야 합니다. 그러나 QM 등급은 “ISO 26262에 따른 안전 요구사항이 없음”을 의미하며, 안전 요구사항이 없는 기능이 안전 기능일 수는 없습니다. 안전 기능(‘보호(Protection)’와 ‘통제(Control)’)이 없는 기능은 안전기능으로 분류할 수 없음.
- 신뢰의 부재: 아키텍처에서 QM(D) 요소는 ‘감시 대상(Monitored Element)’이지 ‘감시 주체(Monitoring Element)’가 아니며, 안전 기능이 시스템을 감시하고 통제하는 주체여야 합니다.
즉 이러한 구조에서 안전 메커니즘이 시스템의 안전 무결성을 책임지며, 의도된 기능(QM)은 시스템적 이슈(안전에 대한 위험 등)를 가질 수밖에 없습니다.
4. 간섭 무결성(FFI)의 본질과 분류학적 의미
간섭 무결성(FFI : Freedom From Interface)은 QM으로 분류된 의도된 기능이 안전 기능을 무력화시키는 것을 방지하는 핵심 기술 요소이며, FFI의 존재 자체가 의도된 기능과 안전 기능의 ‘이질성’과 ‘분리’를 증명합니다.
4.1 FFI의 기술적 구현과 의미
FFI는 종속 고장 분석(DFA)을 통해 식별된 공통 원인 고장(Common Cause Failure)이나 연쇄 고장(Cascading Failure)을 차단하는 것을 목표로 하며, 예를 들면 다음과 같은 방법이 있습니다.
- 공간적 간섭(Spatial Interference) 방지: MPU(Memory Protection Unit)를 사용하여 QM 소프트웨어가 ASIL 안전 메커니즘의 메모리 영역을 침범하거나 덮어쓰는 것을 하드웨어적으로 차단.
- 시간적 간섭(Temporal Interference) 방지: 워치독(Watchdog) 타이머나 스케줄링 감시를 통해 QM 기능이 CPU 자원을 독점하여 안전 기능의 실행을 방해하는 것을 방지.
- 통신 간섭(Communication Interference) 방지: E2E(End-to-End) 프로텍션을 사용하여 QM 기능이 생성한 데이터가 안전 기능으로 전달될 때 데이터 오염 여부를 검사.
4.2 FFI가 증명하는 “신뢰의 부재”
FFI는 본질적으로 “불신(Distrust)”에 기반한 기술이며, QM 기능을 신뢰하지 않기 때문에, 그것이 안전 기능을 망가뜨리지 못하도록 격리벽(Firewall)을 세우는 것입니다. 만약 의도된 기능이 “안전 기능”의 일부라면, 그것은 신뢰받는 요소여야 하며, 내부적으로 안전 무결성을 갖추어야 합니다. 그러나 FFI를 적용한다는 것은 의도된 기능을 ‘잠재적 가해자’로, 안전 메커니즘을 ‘피해를 입어서는 안 되는 보호자’로 설정하는 행위입니다.
따라서 FFI를 만족시킨다는 사실은 의도된 기능이 안전 기능으로 승격됨을 의미하는 것이 아니라, 오히려 의도된 기능이 안전 아키텍처 내에서 “격리되어야 할 비안전 요소(Non-Safety Element)”임을 확증하는 논리적 근거가 됩니다.
5. 산업 표준 사례 분석: E-GAS 모니터링 컨셉
이러한 논의를 실제 자동차 산업 현장의 표준 아키텍처에 대입해보면 결론은 더욱 명확 합니다. 가장 대표적인 사례는 독일 자동차 산업 협회(VDA) 주도로 정립된 엔진 제어 시스템용 표준 안전 아키텍처인 E-GAS 모니터링 컨셉입니다 [1]
5.1 3-Level 아키텍처의 구조
E-GAS 컨셉은 ECU 소프트웨어를 기능적 역할에 따라 세 가지 레벨로 분리합니다.
6. 의도된 기능을 "안전 기능"으로 분류할 수 있는가?
지금까지의 내용을 바탕으로, “의도된 기능도 안전 기능이라고 이야기할 수 있는가?”에 대한 답을 종합적으로 정리해 보도록 하겠습니다.
6.1 기능적 관점: NO
기능 안전의 목적은 위험(Risk)을 줄이는 것이며, 의도된 기능은 토크나 조향력을 발생시킴으로써 위험(급발진, 급조향)을 생성(Generate)하는 역할을 합니다. 반면, 안전 메커니즘은 이 출력을 제한함으로써 위험을 제거(Eliminate)하거나 완화(Mitigate)를 하게 됩니다.
위험을 생성하는 기능과 위험을 제거하는 기능은 정반대의 벡터를 가집니다. 따라서 의도된 기능을 안전 기능이라 부르는 것은 “불을 피우는 것(의도된 기능)”을 “소방 활동(안전 기능)” 이라고 부르는 것과 같은 논리적 모순을 만들 수 있습니다.
6.2 안전 무결성(Metric) 관점: NO
하드웨어 메트릭(SPFM, LFM, PMHF) 산출 시, QM 부분의 고장률(FIT)은 그 자체로 단일 점 고장(Single Point Fault)으로 계산되지 않습니다. ASIL 분해 아키텍처에서 QM 부분의 고장은 안전 메커니즘이 존재하기 때문에 잔존 결함(Residual Fault) 혹은 다중 점 고장(Multiple Point Fault)의 일부로 처리됩니다.
만약 의도된 기능이 안전 기능이라면, 그 자체의 신뢰성이 안전 목표 달성의 척도가 되어야 합니다. 그러나 QM(D) 아키텍처에서는 의도된 기능의 신뢰성보다는 안전 메커니즘의 진단 커버리지(Diagnostic Coverage)가 훨씬 더 중요한 안전 척도가 됩니다.
6.3 예외적 고려: 시스템 레벨의 호칭
다만, 마케팅적인 차원에서 “이 시스템은 안전 기능을 갖추고 있다”라고 말할 때, 일반 사용자는 의도된 기능과 안전 메커니즘을 구분하지 못할 수 있습니다. 예를 들어 “스마트 크루즈 컨트롤” 전체를 안전 편의 기능이라고 부르기도 합니다. 그러나 이는 엔지니어링이나 ISO 26262 인증 차원에서의 용어가 아니므로 엔지니어링 문서(예. Safety Case, Technical Safety Concept 등)에서는 엄격하게 구분해야 합니다.
7. SOTIF(의도된 기능의 안전)와의 비교를 통한 명확화
최근 자율주행 기술의 발전으로 대두된 SOTIF (Safety of the Intended Functionality, ISO 21448) 개념을 도입하면 이 구분은 더욱 명확 해집니다.
기능 안전(ISO 26262)은 시스템의 고장(Failure)에 집중하는 반면 SOTIF는 시스템이 고장 나지 않았음에도 불구하고, 성능의 한계나 오인식으로 인해 발생하는 위험을 다룹니다. SOTIF의 명칭 자체가 “의도된 기능의 안전(Safety of the Intended Functionality)”이며, 이는 의도된 기능이 ‘안전의 주체’가 아니라 ‘안전 확보의 대상(Subject)’임을 명시적으로 보여줍니다.
- ISO 26262: 의도된 기능이 고장 나면 안전 메커니즘이 보호함.
- ISO 21448: 의도된 기능의 성능 부족을 보완하기 위해 센서를 개선하거나 알고리즘을 수정함.
두 표준 모두에서 의도된 기능은 “완벽하게 만들어야 하거나(SOTIF), 고장 시 막아야 하는(FuSa)” 대상일 뿐, 그 자체가 안전을 보장하는 “Safety Function”으로 정의되지 않는다는 점입니다.
8. 적용 예제: 문서화 및 논리 전개 전략
현장에서 안전 문서(Safety Case 등)에 적용할 때 혼란을 피하기 위해 다음과 같은 전략을 권장할 수 있습니다.
8.1 아키텍처 기술 (Architecture Description)
안전 컨셉 기술서(FSC/TSC)에서 아키텍처를 기술할 때, 다음과 같이 명확히 역할을 분담하여 서술해야 합니다.
- System/Item: 예: 트랙션 인버터 시스템
- Intended Function (QM): 토크 지령 생성 및 모터 구동 (구현: Main Core SW + Driver HW)
- Safety Function (ASIL D): 비의도적 토크 감지 및 안전 상태(Free-wheeling) 천이 (구현: Monitoring Core SW + Lockstep + Watchdog + Safety Switch 등)
- Safety Argument: 의도된 기능(QM)의 우발적 하드웨어 고장 및 소프트웨어 결함은 독립적인 안전 메커니즘(ASIL D)에 의해 100% 탐지되고 제어되며, FFI 분석을 통해 두 요소 간의 종속 고장 가능성은 배제됨.
8.2 용어 사용의 주의
문서 내에서 QM 요소를 지칭할 때는 절대 ‘Safety Function’이라는 용어를 사용해서는 안 되며, 대신 다음과 같은 용어를 사용하는 것이 표준에 부합니다.
- Intended Function (의도된 기능)
- Nominal Function (정상 기능)
- Function Level (기능 레벨 – E-GAS 용어)
- Performance Related Function (성능 관련 기능)
반면, ASIL D 요소를 지칭할 때는 다음과 같이 표현하는 것이 바람직합니다.
- Safety Mechanism (안전 메커니즘)
- Safety Function (안전 기능)
- Monitoring Function (모니터링 기능)
- Checker / Supervisor (감시자)
8.3 하드웨어 부품의 경우
만약 의도된 기능을 수행하는 하드웨어(예: 마이크로컨트롤러, 센서)가 안전 메커니즘과 공유된다면, 그 하드웨어 부품 자체는 QM이 될 수 없습니다. 소프트웨어는 논리적으로 분리가 가능(Partitioning)하지만, 하드웨어는 물리적으로 공유되기 때문입니다. 이 경우 하드웨어는 안전 관련 요소로서 ISO 26262-5(하드웨어 수준의 제품 개발)의 요구사항을 따라야 하며, 하드웨어 아키텍처 메트릭(HAM) 분석에 포함되어야 합니다. “의도된 기능을 QM으로 만든다”는 것은 주로 소프트웨어 및 시스템 아키텍처 레벨에서의 분해를 의미하는 것으로 해석하는 것이 적절합니다.
9. 결론
요약하자면, ISO 26262의 규범적 정의와 아키텍처 원칙, 그리고 산업계의 통용되는 표준(E-GAS 등)에 비추어 볼 때, 본연의 의도된 기능이나 ASIL 분해로 QM(D)로 할당된 기능은 ‘안전 기능(Safety Function)’이라고 부를 수 없습니다.
그것은 안전 목표에 영향을 주는 ‘안전 관련 요소(Safety-Related Element)’이자 위험의 잠재적 원천인 ‘의도된 기능(Intended Function)’입니다. 안전 기능이라는 호칭은 위험을 능동적으로 감지하고, 차단하며, 시스템을 안전 상태로 이끄는 ‘안전 메커니즘(Safety Mechanism)’에게만 부여되어야 합니다.
만약 설계한 아키텍처가 QM 기능 + ASIL 모니터링 + FFI 확보의 설계는 매우 훌륭하고 효율적인 기능 안전 전략입니다. 그러나 용어의 혼용은 안전 논리의 명확성을 해치고, 향후 기능 안전 심사(Assessment) 과정에서 불필요한 지적 사항을 유발할 수 있으므로, 의도된 기능과 안전 기능을 명확히 구분하여 명명하는 것이 프로젝트의 성공적인 인증과 안전성 입증에 필수적입니다.
참고 자료
- Standardized E-Gas Monitoring Concept for Gasoline and Diesel Engine Control Units Version 6.0
- ISO 26262, Second edition 2018-12, Road vehicles — Functional safety Part 1~12