Part7_confirmation review

좋아, 상황 설정이 아주 명확해서 실제 Confirmation Review에서 바로 써먹을 수 있는 수준으로 만들어볼게.
아래 체크리스트는 **“내가 ISO 26262 Functional Safety Confirmation Measure 담당자이고, Safety Case에 포함된 Part 7 (Production & Operation) 관련 내용에 대해 Confirmation Review를 수행한다”**는 전제에 맞춰 작성했어.

⚠️ 관점 고정

• 나는 개발자도, 생산 담당자도 아님
• 나는 독립성 있는 Confirmation Reviewer
• 목적은 “Part 7 요구사항이 Safety Case에서 충분하고, 일관되고, 신뢰 가능하게 주장·증거화되었는지” 확인

---

ISO 26262 Confirmation Review Checklist

Safety Case – Part 7 (Production & Operation)

---

0. 기본 Review 조건 확인 (Gate)

체크 항목확인

Review 수행자의 독립성(ISO 26262-2 요구) 확보됨	☐
Review 대상 Safety Case 버전이 명확히 식별됨	☐
Part 7 적용 범위(생산, 조립, 테스트, 출하, 운영)가 정의됨	☐
Safety Case 구조 내 Part 7 위치 명확	☐
Safety Case가 Claim–Argument–Evidence 구조를 가짐	☐

❗ 이 단계에서 불명확하면 이후 모든 리뷰는 무의미

---

1. Part 7 적용 범위 및 책임 정의 (Clause 7.x 공통)

1.1 생산·운영 범위 정의

체크 항목확인

생산 범위(IQC, SMT, Assembly, EOL, Shipment)가 명확	☐
SOP / EOL 이후 운영 단계 포함 여부 명확	☐
OEM vs Supplier 책임 경계 정의됨	☐
ASIL 적용 범위가 생산 단계까지 일관되게 유지됨	☐

1.2 Safety Responsibility

체크 항목확인

Production Safety 책임자 정의	☐
Escalation 경로(OEM 포함) 정의	☐
Safety-relevant 변경 승인 권한 정의	☐

---

2. Safety-related Content of Production Planning

(ISO 26262-7: Clause 7.4.4, 7.4.5)

2.1 Production Plan – Safety Content

체크 항목확인

Safety Goal ↔ Production Activity 연결 설명	☐
생산 중 도입 가능한 안전 위험 식별됨	☐
Safety-relevant 공정 단계 식별	☐
특별 공정(특수 공정) 정의됨	☐

“생산 중 도입 가능한”이란 무슨 뜻인가?

❌ 의미가 아닌 것

• 설계 고장 ❌
• 정상 동작 중 고장 ❌
• Field 고장 ❌

✅ 정확한 의미

“설계에는 없었지만,
생산 공정의 행위로 인해 새로 생길 수 있는 고장/편차/오류”

3️⃣ 구체적인 예로 설명

예 1: Calibration 값

• 개발:
  • Sensor offset = +2.3 mV (검증 완료)
• 생산:
  • 잘못된 calibration 파일 flashing
  • calibration 중 온도 조건 미준수

➡ 결과:

• 설계에는 없던 안전 고장 발생
• 잘못된 판단 → 잘못된 제어

👉 이것이 “생산 중 도입된 안전 위험”

예 2: EOL Test 누락

• 설계:
  • Watchdog 정상 설계
• 생산:
  • EOL 테스트에서 watchdog test step 삭제
  • 테스트 시간 단축 목적

➡ 결과:

• watchdog 불량 ECU 출하 가능

👉 설계 고장이 아니라 생산 공정이 만든 안전 위험

---

예 3: Assembly 공정

• 설계:
  • Connector pin redundant
• 생산:
  • 특정 작업자가 한쪽 pin 반복 손상
  • 육안 검사만 수행

➡ 결과:

• redundancy 무력화

👉 공정 편차가 safety mechanism을 파괴

 

문서에서 이것이 어떻게 보여야 “식별됨”인가?

아래 중 하나라도 있으면 “식별됨”으로 판단 가능해.

✔ PFMEA에서 Safety 항목이 있음

• “Wrong calibration parameter”
• “Safety mechanism disabled during flashing”

✔ Production Control Plan에 반영

• calibration lock
• flashing CRC check
• EOL watchdog test mandatory

✔ Safety Case 문장

“Potential safety risks introduced during production (e.g. wrong calibration, incomplete testing) are identified and mitigated by…”

2.2 Calibration / Setup 관련

체크 항목확인

Calibration 항목이 명확히 정의됨	☐
Calibration 변경 가능 주체 제한됨	☐
Calibration 오류에 대한 안전 영향 분석 존재	☐
Calibration 데이터 무결성 보호 수단 존재	☐

---

3. Safety-related Content of Production Control Plan

(ISO 26262-7: Clause 7.4.14)

3.1 Control Plan 존재성 & 완전성

체크 항목확인

Safety 전용 Control Plan 또는 명확한 섹션 존재	☐
Safety 특성(CC/SC/S) 명확히 표시	☐
PFMEA와 Control Plan 연결 논리 명확	☐
작업자 임의 변경 방지 수단 존재	☐

자동차 제조 공정에서 CC, SC, S는 제품의 품질과 안전에 직결되는 특별특성(Special Characteristics)을 분류하는 약어입니다. 이는 주로 품질 관리(FMEA) 단계에서 심각도에 따라 지정됩니다. 

1. CC (Critical Characteristic, 중대특성)

• 의미: 제품의 안전이나 정부 법규 준수에 결정적인 영향을 미치는 특성입니다.
• 기준: FMEA(고장형태 및 영향분석) 심각도 점수가 9~10점일 때 지정됩니다.
• 예시: 제동 장치(브레이크) 성능, 조향 장치, 연료 시스템 등 사고나 인명 상해와 직결되는 항목입니다.
• 관리: 매우 엄격하게 관리되며, 일반적으로 전수 검사 또는 높은 수준의 통계적 공정 관리(SPC)가 요구됩니다. 

2. SC (Significant Characteristic, 중요특성)

• 의미: 제품의 기능, 성능, 장착성 또는 고객 만족에 큰 영향을 미치는 특성입니다.
• 기준: FMEA 심각도 점수가 5~8점 수준이거나, 특정 공정에서 산포 관리가 필요할 때 지정됩니다.
• 예시: 엔진 출력, 소음 및 진동(NVH), 부품 간의 조립 공차 등 제품의 품질 경쟁력과 관련된 항목입니다.
• 관리: 공정 능력을 지속적으로 모니터링하며 SPC(통계적 공정 관리)를 통해 관리 상태를 유지해야 합니다. 

3. S (Severity, 심각도)

• 의미: 고장이 발생했을 때 그 영향이 얼마나 치명적인지를 나타내는 척도입니다.
• 역할: 위에서 언급한 CC나 SC를 결정하는 기준값이 됩니다. 보통 1점에서 10점까지 점수를 매기며, 점수가 높을수록 위험도가 높음을 의미합니다. 

이러한 분류는 자동차 제조사가 부품의 위험도에 따라 관리 자원을 효율적으로 배분하고, 결함으로 인한 사고를 사전에 방지하기 위해 사용합니다.

3.2 공정 통제의 적절성

체크 항목확인

Safety 관련 공정 파라미터 관리됨	☐
공정 능력 요구사항 정의됨	☐
재작업 제한 규칙 명확	☐

---

“Safety 관련 공정 파라미터 관리됨”

Confirmation Review 관점에서의 증거 기준

---

1️⃣ 이 문장의 정확한 의미부터 정리

❌ 흔한 오해

• “공정 파라미터가 정의돼 있다”
• “공정 조건이 WI에 적혀 있다”

✅ ISO 26262 Part 7에서 요구하는 진짜 의미

Safety에 영향을 주는 공정 파라미터가

1. 식별되었고
2. 변경 불가능하거나 통제되고
3. 이탈 시 검출되며
4. 출하 전에 안전 위반이 차단된다

---

2️⃣ Confirmation Reviewer가 보는 “증거 체인”

이 문장은 단일 문서로 증명되지 않아.
아래 연결 체인이 보여야 “관리됨”이야.

 

Safety Analysis ↓

PFMEA ↓

Control Plan ↓

Work Instruction / System Control ↓

Production Evidence

---

3️⃣ 문서별로 “잘 됐다”고 보이는 구체적 모습

---

(1) PFMEA – “식별됨”의 증거

❌ 부족

• “Soldering temperature”만 기재
• Severity만 높음

✅ 충분

• Failure Mode:
  • “Reflow temperature too low → Safety MCU cold solder joint”
• Cause:
  • “Oven profile parameter modified”
• Detection:
  • “Reflow profile monitoring (Safety CC)”

📌 핵심

파라미터 이름 + 안전 영향이 연결됨

---

(2) Control Plan – “통제됨”의 증거

❌ 부족

• Parameter: Reflow temperature
• Control method: Monitor

✅ 충분

• Parameter: Reflow temperature (Safety CC)
• Control:
  • Target: 245 ±5°C
  • Locked by Engineering
  • Operator modification prohibited
• Reaction:
  • Line stop if deviation

📌 핵심

사람이 만질 수 없게 했는가?

---

(3) Work Instruction / System Control – “변경 불가” 증거

❌ 부족

• “Follow oven profile”

✅ 충분

• Oven recipe:
  • Password protected (Engineering only)
• Change requires:
  • Safety Impact Analysis
  • FSM approval
• Change log mandatory

📌 핵심

관리자는 ‘관리’하지만,
파라미터는 ‘통제’되어야 한다

---

(4) Test Plan / EOL – “이탈 검출” 증거

❌ 부족

• 공정 후 EOL만 있음

✅ 충분

• In-process monitoring:
  • Reflow profile recorded per lot
• EOL:
  • Safety function verification catches residual risk

📌 핵심

공정 중 + 공정 후 이중 방어

---

(5) Safety Case 문장 – “논리 완성”

OEM Confirmation Review에서 통과되는 문장 예:

“Safety-related production parameters (e.g. reflow temperature, calibration offset values) are identified via PFMEA, controlled in the production control plan as safety characteristics, protected against unauthorized modification, and continuously monitored. Deviations are detected and prevented from reaching the customer by defined reaction mechanisms.”

4. Production Test Plan (Safety Perspective)

4.1 Test Coverage

체크 항목확인

Safety Mechanism 검증 테스트 포함	☐
Production-introduced fault 검출 가능	☐
FMEDA Diagnostic Coverage와 연계됨	☐
ASIL 요구에 맞는 Test depth	☐

“FMEDA Diagnostic Coverage와 연계됨”

Confirmation Review 관점에서의 완성 기준

이 질문은 HW Safety의 정수이자
OEM Confirmation Review에서 FMEDA가 “숫자 놀이인지 / 안전 논리인지”를 가르는 결정적 기준이야.

아래 설명은 Confirmation Reviewer가 실제로 “이건 잘 됐다”고 판단하는 내부 기준 그대로라고 봐도 돼.

1️⃣ 이 문장의 진짜 의미 (한 문장 해석)

❌ 잘못된 이해

• “FMEDA에 DC%가 계산돼 있다”
• “DC 값이 ASIL 기준을 만족한다”

✅ ISO 26262가 말하는 정확한 의미

FMEDA에서 주장한 Diagnostic Coverage가
‘어떤 안전 메커니즘이
어떤 고장을
어떻게 잡는지’와
문서 전반에서 논리적으로 연결되어 있다

---

2️⃣ Confirmation Reviewer가 요구하는 “연계”의 정의

Reviewer가 보는 “연계됨”은 이 네 가지가 연결되는 것이야:

 

Hardware Failure Mode ↓

Safety Mechanism ↓

Detection Principle ↓

Verification Evidence

하나라도 빠지면 → “연계 안 됨”

---

3️⃣ 문서에서 “잘 됐다”고 보이는 구체적 증거들

아래는 실제 리뷰 시 PASS 판정이 나는 패턴이야.

 

📌 핵심

DC는 ‘메커니즘’의 결과여야 한다

---

(2) Safety Mechanism 설명 문서와의 연결

FMEDA에서 말한 ECC가
아래 문서에서 동일한 이름과 동일한 역할로 등장해야 함

Reviewer 확인 포인트

• HW Architecture Document
• Safety Concept (TSC)
• Safety Mechanism Description

✅ 잘 된 문장 예

“Single-bit faults in SRAM are detected and corrected by SECDED ECC logic integrated in the memory controller.”

📌 FMEDA의 “ECC”와 1:1 매칭

---

(3) Fault Assumption & Limitation 명시 (Part 9 핵심)

FMEDA DC는 항상 조건부야.

❌ 빠진 경우

• ECC 적용 범위 미정
• Timing assumption 없음

✅ 잘 된 경우

“ECC diagnostic coverage assumes continuous memory access within the defined task cycle time. Dormant memory regions are excluded.”

📌 Reviewer 질문

“DC 99%는 언제 깨질 수 있지?”

---

(4) Verification Plan & Test Case와의 연결

❌ 부족

• FMEDA 따로
• 테스트 따로

✅ 충분

Verification Plan:

• “ECC single-bit fault injection test”

Test Spec:

• Inject bit-flip → detect within 1 cycle → safe reaction

📌 핵심

DC는 ‘시험될 수 있어야’ 한다

---

(5) Integration Test Strategy와의 연결

FMEDA의 DC는
통합 환경에서도 유지됨이 보여야 함

✅ 잘 된 문장

“The diagnostic coverage claimed in FMEDA is verified at HW–SW integration level by validating fault detection and reaction latency under realistic operating conditions.”

---

(6) Safety Case 문장 (최종 판단 지점)

Confirmation Review에서 PASS 나는 문장 구조:

“The diagnostic coverage values claimed in the FMEDA are derived from explicitly defined safety mechanisms (e.g. ECC, watchdog), whose detection principles, assumptions, and limitations are documented and verified through dedicated hardware and integration tests. Therefore, the FMEDA diagnostic coverage is considered valid for the intended operating context.”

📌 이 문장이 링크 + Evidence ID와 함께 있어야 함

4️⃣ Confirmation Reviewer 실전 체크리스트

질문Yes/No

DC가 특정 safety mechanism에 근거하는가?	☐
그 메커니즘이 아키텍처 문서에 존재하는가?	☐
Detection 원리가 설명돼 있는가?	☐
DC 가정이 명시돼 있는가?	☐
시험으로 검증되는가?	☐

5/5 → “FMEDA DC와 연계됨”

5️⃣ OEM이 실제로 Reject하는 대표 패턴

❌ DC = 툴 출력값
❌ 메커니즘 이름 불일치
❌ “ECC 있음”만 있고 검증 없음
❌ Assumption 숨김

---

6️⃣ 한 문장으로 요약하면

“FMEDA Diagnostic Coverage와 연계됨”이란
‘DC라는 숫자가
문서 전체에서
살아 움직인다’는 뜻이다.

---

7️⃣ Confirmation Review 결론 문장 예시

✔ FMEDA diagnostic coverage is not treated as a standalone calculation result,
✔ but as a safety claim consistently supported by architecture, analysis, and verification evidence.

이 문장을 증거로 방어 가능하면 PASS야.

4.2 Test Integrity

체크 항목확인

Test limit 변경 통제됨	☐
Test SW 버전 관리됨	☐
Operator override 차단	☐
Test equipment calibration 관리	☐

“Operator override 차단”

Confirmation Review 관점에서의 완성 기준

---

1️⃣ 이 문장의 진짜 의미부터 명확히 하자

❌ 잘못된 이해

• “작업자가 하면 안 된다고 교육했다”
• “작업자가 임의로 하면 안 된다고 WI에 써 있다”

✅ ISO 26262 Part 7에서 요구하는 정확한 의미

Operator가 안전에 영향을 주는 동작을
‘의도적으로 또는 실수로’ 수행하더라도
시스템적으로 무효화되거나 차단된다

핵심 키워드:

• Structural prevention
• Not procedural

---

2️⃣ Confirmation Reviewer가 보는 “차단”의 판단 구조

Reviewer는 아래 4단계 방어 구조가 있는지 본다:

 

(1) Override 시나리오 식별 ↓

(2) 구조적 차단 수단 존재 ↓

(3) 우회 시 검출 ↓

(4) 출하 차단

하나라도 빠지면 → “차단 안 됨”

---

3️⃣ 문서별로 “잘 됐다”고 보이는 구체적 모습

---

(1) PFMEA – Override 가능성 식별

❌ 부족

• Operator error (일반)

✅ 충분

• Failure Mode:
  • “Operator disables safety test step”
  • “Operator flashes wrong SW version intentionally”
• Cause:
  • “Manual override function enabled”
• Effect:
  • “Safety mechanism not verified → unsafe ECU shipped”

📌 핵심

‘사람이 우회한다’는 시나리오가 명시됨

---

(2) Control Plan – 구조적 차단 정의

❌ 부족

• “Operator not allowed to override”

✅ 충분

• Control:
  • Test sequence locked
  • Override button physically removed or disabled
  • Safety test auto-mandatory
• Reaction:
  • Line stop if sequence interrupted

📌 핵심

허용되지 않는 게 아니라 ‘불가능’해야 함

---

(3) Work Instruction / System Design – 물리·논리적 차단

가능한 차단 수단 예시

• EOL tester:
  • Safety test cannot be skipped
  • Pass flag generated only if all safety steps executed
• Flashing:
  • Tool enforces SW + calibration consistency
  • No “force pass” mode

📌 문서에 이렇게 보여야 함:

“Operator cannot proceed to next step unless safety test is completed.”

---

(4) Test Plan / IT System – 우회 시 검출

❌ 부족

• Override 자체를 기록 안 함

✅ 충분

• Test system log:
  • Attempted override recorded
  • User ID, timestamp stored
• Alarm triggered on override attempt

📌 핵심

시도만 해도 흔적이 남는다

---

(5) Shipment Release Control – 최종 차단

❌ 부족

• 작업자가 승인

✅ 충분

• Shipping allowed only if:
  • Safety test status = PASS (system generated)
  • No override attempt flag present

📌 핵심

사람 승인 ≠ 출하 승인

“Test equipment calibration 관리”

Confirmation Review 관점에서의 완성 기준

---

1️⃣ 이 문장의 정확한 의미

❌ 흔한 오해

• “장비는 정기적으로 교정하고 있다”
• “교정 증명서가 있다”

✅ ISO 26262 Part 7에서 요구하는 진짜 의미

안전 관련 시험 결과가
‘교정 상태가 보장된 장비’에서만 생성되며,
교정 이탈 시 안전 제품이 출하되지 않도록
구조적으로 통제된다

---

2️⃣ Confirmation Reviewer가 요구하는 “증거 구조”

Reviewer는 아래 연결 체인을 본다:

 

Safety Relevance Identification ↓

Calibration Requirement Definition ↓

Calibration Execution & Status Control ↓

Test Result Gating ↓

Traceability & Evidence

하나라도 빠지면 → 관리 안 됨

---

3️⃣ 문서에서 “잘 됐다”고 보이는 구체적 모습

---

(1) Safety relevance 식별 (출발점)

📄 PFMEA / Test Plan

❌ 부족

• “EOL tester”

✅ 충분

• “EOL tester channel for watchdog timeout measurement (Safety-related)”

📌 핵심

모든 장비가 아니라 ‘안전 관련 채널’이 식별됨

---

(2) Calibration 요구 정의

📄 Control Plan / Test Equipment Specification

❌ 부족

• “Calibrate periodically”

✅ 충분

• Calibration item:
  • Channel: Voltage measurement CH3
  • Accuracy: ±1%
  • Interval: 6 months
  • Reference standard: Traceable to national standard

📌 핵심

무엇을, 어느 정확도로, 왜 교정하는지

---

(3) Calibration 실행 & 상태 관리

📄 Calibration Procedure / IT System

❌ 부족

• 엑셀 관리
• 스티커만 부착

✅ 충분

• Calibration status:
  • Stored in MES / Test system
  • Valid / Expired / Quarantined
• Automatic lock:
  • Tester disabled if expired

📌 핵심

교정 만료 = 사용 불가

---

(4) Test Result Gating (가장 중요한 포인트)

📄 Test System Logic / Release Procedure

❌ 부족

• 교정 만료여도 테스트 가능

✅ 충분

• Test execution allowed only if:
  • Equipment calibration status = VALID
• Historical test results invalidated if calibration later found invalid

📌 핵심

사람이 판단하지 않음

---

(5) Traceability & Evidence

📄 Test Log / Calibration Record

❌ 부족

• 별도 보관

✅ 충분

• Each test record contains:
  • Equipment ID
  • Calibration certificate ID
  • Calibration validity date

📌 핵심

EOL 결과 ↔ 교정 상태 연결

4️⃣ Confirmation Reviewer 실전 체크리스트

질문Yes / No

Safety-related test channels가 식별되었는가?	☐
교정 요구사항이 명확히 정의되었는가?	☐
교정 만료 시 장비 사용이 차단되는가?	☐
Test 결과가 교정 상태와 연계되는가?	☐

4/4 → “Test equipment calibration 관리됨”

---

5️⃣ OEM이 실제로 Reject하는 전형적 패턴

❌ “Calibration certificate available upon request”
❌ “Operator checks sticker before use”
❌ “Calibration is handled by quality department” (통제 없음)

---

6️⃣ 한 문장으로 요약하면

“Test equipment calibration 관리”란
‘교정한다’가 아니라
‘교정되지 않으면 아무 일도 일어나지 않게 만든다’는 뜻이다.

---

5. Nonconforming Product & Escalation

(ISO 26262-7: Clause 7.4.15)

체크 항목확인

Safety 관련 불량 격리 절차 존재	☐
OEM 통보 기준 명확	☐
반복 불량 시 안전 영향 분석 요구	☐
Rework 후 재검증 규칙 존재	☐

---

6. Traceability & Data Retention

체크 항목확인

Safety 관련 항목 Serial-level 추적	☐
SW/Calibration/Test 결과 연계	☐
Data 보존 기간 ASIL 요구 충족	☐
Recall 대응 가능성 입증	☐

1️⃣ 이 문장의 정확한 의미부터 정리

❌ 흔한 오해

• “Traceability가 있다”
• “Recall 프로세스 문서가 있다”

✅ ISO 26262 Part 7에서 요구하는 진짜 의미

안전 문제가 발생했을 때

• 영향을 받는 제품을 정확히 식별할 수 있고
• 불필요한 과다 리콜 없이
• 시간 내에
• OEM이 요구하는 단위로
  조치할 수 있음을 문서 + 구조로 입증

즉, **“지금 당장 리콜을 하라고 해도 실행 가능한 상태”**여야 한다.

---

2️⃣ Confirmation Reviewer가 요구하는 “입증 구조”

Reviewer는 아래 6단계 체인을 본다:

 

(1) Recall Trigger 정의 ↓

(2) Safety 영향 분석 가능 ↓

(3) Affected Population 식별 ↓

(4) Physical Traceability ↓

(5) Containment & Action 가능 ↓

(6) OEM Communication 준비

👉 이 중 하나라도 빠지면 “입증 안 됨”

---

3️⃣ 문서에서 “잘 됐다”고 보이는 구체적 모습

---

(1) Recall Trigger 정의됨

📄 Safety Case / Incident Handling Procedure

❌ 부족

• “In case of issue…”

✅ 충분

• Recall trigger examples:
  • Field failure linked to safety goal violation
  • Production deviation affecting safety mechanism
  • FMEDA assumption invalidated

📌 핵심

언제 ‘리콜’이라는 단어를 꺼낼지 기준이 있음

---

(2) Safety 영향 분석 가능함

📄 Safety Impact Analysis Template

❌ 부족

• Ad-hoc 판단

✅ 충분

• Standard template:
  • Safety goal impacted?
  • ASIL affected?
  • Single-point or latent fault?

📌 핵심

“이 문제는 리콜 대상인가?”를 구조적으로 판단 가능

---

(3) Affected Population 식별 가능

📄 Traceability Matrix / MES

❌ 부족

• “Potentially all units”

✅ 충분

• Filterable by:
  • Production date/time
  • Line / station
  • SW version
  • Calibration version
  • Test equipment ID

📌 핵심

리콜 범위가 ‘줄어들 수 있음’

---

(4) Physical Traceability 확보

📄 Production Traceability Concept

❌ 부족

• Lot-level only

✅ 충분

• Serial-level traceability:
  • SN ↔ PCB ↔ MCU lot
  • SN ↔ SW & calibration
  • SN ↔ EOL test result

📌 핵심

“이 ECU 하나가 어떤 과정을 거쳤는지” 재현 가능

---

(5) Containment & Corrective Action 가능

📄 Recall & Containment Procedure

❌ 부족

• “Stop shipment”

✅ 충분

• Defined actions:
  • Block shipment in ERP
  • Quarantine in-stock units
  • Field action definition (reflash / replace)

📌 핵심

‘그래서 뭘 할 건데?’에 답이 있음

---

(6) OEM Communication 준비됨

📄 OEM Notification Procedure

❌ 부족

• “Inform OEM”

✅ 충분

• Defined content:
  • Affected population
  • Safety impact
  • Immediate containment
  • Proposed corrective action
• Time requirement (e.g. 24h)

📌 핵심

OEM이 요구하는 언어로 설명 가능

6️⃣ OEM이 실제로 Reject하는 전형적 패턴

❌ “Traceability exists” (범위·단위 불명)
❌ Lot-level only
❌ Safety impact 판단 기준 없음
❌ Recall은 OEM responsibility라고 주장

---

7️⃣ 한 문장으로 요약하면

“Recall 대응 가능성 입증”이란
‘문제가 생기면 어떻게든 한다’가 아니라
‘지금 이 순간 바로 실행할 수 있다’는 상태를 증명하는 것이다.

---

7. Change Management (Safety Impact)

체크 항목확인

생산 변경 시 Safety Impact Analysis 요구	☐
Test / Calibration 변경 관리됨	☐
OEM 승인 조건 명확	☐
변경 이력 추적 가능	☐

---

8. Training & Human Factor

체크 항목확인

Safety 관련 작업자 교육 정의	☐
자격 인증 요구	☐
재교육 주기 명확	☐
교육 기록 증빙 가능	☐

---

9. Safety Case 논리 일관성 (Confirmation Review 핵심)

체크 항목확인

Claim이 Part 7 요구사항을 정확히 반영	☐
Argument가 “계획 → 통제 → 검증” 흐름 가짐	☐
Evidence가 문서 수준이 아닌 실행 수준	☐
개발(Part 6) 주장과 생산(Part 7) 주장 모순 없음	☐

---

10. Reviewer Judgment (Mandatory)

질문Yes / No

Part 7 활동이 Safety Goal 달성에 충분한가?	☐
생산 단계에서 Safety degradation 가능성이 관리되고 있는가?	☐
OEM에 제공해도 방어 가능한 Safety Case인가?	☐

---

11. Confirmation Review Conclusion

• ☐ Acceptable
• ☐ Acceptable with Findings
• ☐ Not Acceptable

주요 Finding 요약

• Finding ID:
• Clause:
• Severity:
• Required Action:

---

🔑 마지막으로 아주 중요한 포인트

Confirmation Review에서 절대 하면 안 되는 실수는 이거야:

❌ “문서가 있다” → OK
✅ “이 문서가 실제 생산에서 안전을 보장하는가?” → Review

 

 

 

"OEM이 실제로 지적하는 Part 7 Confirmation Review Finding Top 10"

 

좋아. 이건 진짜 실무에서 OEM Confirmation Review / Audit 때 가장 자주 터지는 포인트들이라서
형식적인 TOP 10이 아니라,
👉 “OEM이 실제로 빨간 줄 긋는 Finding” 기준으로 정리해줄게.

관점은 계속 동일해:

• ISO 26262 Part 7
• Safety Case 기반 Confirmation Review
• ASIL C / D 기준
• “문서 있음”이 아니라 “현장 안전 보장 논리” 관점

---

OEM이 실제로 지적하는

ISO 26262 Part 7 Confirmation Review

Top 10 Findings

---

🟥 1. Production Control Plan이 “품질 문서” 수준에 머물러 있음

OEM 지적 포인트

“이건 IATF Control Plan이지, ISO 26262 Safety Control Plan이 아닙니다.”

전형적인 문제

• Safety Goal / Safety Requirement 언급 없음
• CC/SC 표시가 형식적
• PFMEA ↔ Safety Goal 연결 부재

OEM이 원하는 것

• 왜 이 공정 통제가 안전에 중요한지 설명
• Safety Case에서 논리적 주장으로 사용 가능해야 함

---

🟥 2. PFMEA가 Safety 분석이 아니라 “공정 불량 리스트” 수준

전형적인 문제

• Severity 기준이 고객 품질 기준
• Safety impact 항목 없음
• ASIL 개념 미반영

OEM 코멘트 예

“이 Failure Mode가 Safety Goal을 위반하면 Severity가 왜 6입니까?”

핵심

➡️ PFMEA에서 안전 영향이 있는 항목은 무조건 Safety 관점 Severity

---

🟥 3. Production Test Plan이 Safety Mechanism을 검증하지 않음

자주 나오는 케이스

• EOL에서 기능 테스트만 수행
• ROM/RAM BIST, Watchdog 미검증
• ECC는 “설계에 있다”고만 주장

OEM 질문

“이 Safety Mechanism이 실제로 생산 중 고장을 잡는다는 증거는?”

---

🟥 4. Calibration / Flashing 통제가 불충분

OEM이 특히 민감한 부분

문제 예

• Calibration 데이터 관리 주체 불명확
• 생산 라인에서 수정 가능
• CRC/Signature 검증 없음

OEM 판단

➡️ “Production에서 Safety Requirement를 무력화할 수 있다”

---

🟥 5. Nonconforming Product 처리에서 Safety 관점 누락

전형적인 문제

• 품질 불량 프로세스만 존재
• Safety Impact Analysis 요구 없음

OEM 질문

“이 불량이 Safety Goal에 영향 있는지 누가 판단합니까?”

---

🟥 6. Rework 정책이 Safety를 고려하지 않음

실제 Finding 예

• Rework 후 부분 재시험
• Safety Test 재실행 안 함

OEM 요구

➡️ Safety 관련 항목은 Rework = Full retest

---

🟥 7. Production Change Management가 ASIL 관점에서 약함

문제

• 공정 변경은 관리하지만
• Safety Impact Analysis 요구 없음

OEM 질문

“Test limit 변경이 ASIL에 어떤 영향을 주는지 설명해보세요.”

---

🟥 8. Traceability가 Safety Case 주장 수준을 못 따라감

흔한 상황

• Lot-level까지만 추적
• Calibration / Test version 미연계

OEM 판단

➡️ “Recall 시 Safety 제품 선별 불가”

---

🟥 9. Training이 형식적 (Human Factor 무시)

문제

• 교육 자료는 있음
• Safety-specific 내용 없음

OEM 질문

“이 작업자가 Safety 관련 작업을 한다는 걸 알고 있습니까?”

---

🟥 10. Safety Case 내 Part 7 주장이 “선언” 수준

가장 치명적인 Finding

문제

• “생산은 통제된다”
• “테스트는 충분하다”

❌ 근거 없음
❌ Evidence 없음

OEM 요구

➡️ Claim → Argument → Evidence 구조

---

🔥 OEM이 특히 싫어하는 한 문장

❌ “This is covered by quality process.”

OEM의 실제 해석:

“그럼 Functional Safety는 안 봤다는 거죠?”

---

🎯 Confirmation Reviewer로서의 핵심 방어 질문 5개

이 5개에 답 못 하면 거의 Finding 나옴:

1. 이 생산 활동이 어떤 Safety Goal을 보호하는가?
2. 이 공정/테스트가 어떤 생산 고장을 검출하는가?
3. 이 통제가 없으면 ASIL 위반이 발생하는가?
4. 변경되면 Safety Impact Analysis가 자동으로 트리거되는가?
5. OEM이 요청하면 즉시 Evidence를 제시할 수 있는가?

---

📌 실무 팁 (중요)

Confirmation Review에서 가장 강력한 한 줄 코멘트:

“Safety Case에서 주장하는 생산 안전 논리가
실제 생산 라인에서 깨질 수 있는 지점이 보입니다.”

 

 

✔ Top 10 Finding을 예방하는 Safety Case 문장 예시

 

이건 Confirmation Reviewer + OEM Reviewer 양쪽 시선을 동시에 만족시키는 문장들이라서,
그냥 “있어 보이는 문장”이 아니라 Finding을 사전에 차단하는 문장 구조로 써야 해.

아래는 아까 말한 OEM Top 10 Finding 각각에 대해
👉 **Safety Case에 실제로 써먹을 수 있는 “예방용 문장 예시”**야.
(Claim–Argument–Evidence 구조를 최대한 유지)

---

Top 10 Finding 예방용

Safety Case 문장 예시 (Part 7)

---

🟥 1. “Control Plan이 품질 문서 수준” Finding 예방

❌ 나쁜 문장

“Production is controlled by Control Plan.”

✅ 예방 문장 예시

“Safety-related production steps are controlled by a dedicated safety-focused Control Plan,
in which all characteristics linked to Safety Goals SG-01 and SG-02 are explicitly marked as safety characteristics (S),
derived from DFMEA, PFMEA, and FMEDA results.”

포인트

• “Safety Goal 번호” 명시
• Control Plan이 안전 전용 통제임을 주장

---

🟥 2. PFMEA가 Safety 관점이 아님 Finding 예방

❌ 나쁜 문장

“PFMEA was performed.”

✅ 예방 문장 예시

“PFMEA includes all production-induced failure modes that could violate functional safety requirements.
Failure modes with potential impact on safety goals are evaluated with safety-oriented severity criteria,
independent from customer quality severity definitions.”

포인트

• “품질 Severity와 분리”
• Safety Goal 위반을 기준으로 판단

---

🟥 3. Safety Mechanism 생산 테스트 미검증 Finding 예방

❌ 나쁜 문장

“Safety mechanisms are implemented in the design.”

✅ 예방 문장 예시

“Safety mechanisms relevant to ASIL D, including ROM/RAM self-tests, watchdog supervision, and communication integrity checks,
are verified during end-of-line testing to detect production-induced faults affecting their availability.”

포인트

• “설계에 있다” ❌
• “생산에서 검증된다” ⭕

---

🟥 4. Calibration / Flashing 통제 미흡 Finding 예방

❌ 나쁜 문장

“Calibration data is flashed during production.”

✅ 예방 문장 예시

“Software and calibration data are flashed automatically using a controlled production toolchain.
Calibration modification by operators is technically prevented, and data integrity is ensured by CRC and digital signature verification.”

포인트

• “누가 못 바꾸는지”
• “기술적으로 차단됨” 강조

---

🟥 5. Nonconforming Product의 Safety 영향 미고려 Finding 예방

❌ 나쁜 문장

“Nonconforming parts are handled according to quality procedures.”

✅ 예방 문장 예시

“All nonconforming products related to safety characteristics trigger a mandatory safety impact analysis.
Escalation to the functional safety manager and OEM is performed if a potential safety goal violation cannot be excluded.”

포인트

• Safety Impact Analysis 명시
• Escalation 조건 명확

---

🟥 6. Rework 후 Safety 재검증 누락 Finding 예방

❌ 나쁜 문장

“Reworked parts are re-tested.”

✅ 예방 문장 예시

“Reworked products affecting safety-related characteristics are subject to full repetition of all safety-related production tests,
including end-of-line safety mechanism verification, before release.”

포인트

• “부분 테스트”라는 오해 차단
• Full retest 명시

---

🟥 7. Production Change Management의 Safety 영향 미흡 Finding 예방

❌ 나쁜 문장

“Production changes are controlled.”

✅ 예방 문장 예시

“Any production change affecting processes, test limits, calibration, or equipment used for safety-related characteristics
requires a documented safety impact analysis and approval by functional safety management prior to implementation.”

포인트

• 변경 대상 구체화
• Safety Impact Analysis 필수화

---

🟥 8. Traceability 부족 Finding 예방

❌ 나쁜 문장

“Traceability is ensured.”

✅ 예방 문장 예시

“Serial-number–based traceability is ensured for all safety-related products,
linking material lots, software and calibration versions, production test results, and test equipment IDs,
enabling safety-relevant recall actions if required.”

포인트

• “Recall 가능”까지 주장해야 OEM이 만족

---

🟥 9. Training이 형식적 Finding 예방

❌ 나쁜 문장

“Operators are trained.”

✅ 예방 문장 예시

“Operators performing safety-related production and test activities receive dedicated functional safety training,
including awareness of safety goals, safety characteristics, and consequences of incorrect handling.”

포인트

• Safety Goal 인식까지 포함

---

🟥 10. Safety Case Part 7 주장이 선언 수준 Finding 예방

❌ 나쁜 문장

“Production ensures functional safety.”

✅ 예방 문장 예시

“Functional safety during production is ensured by a combination of preventive controls, detection mechanisms, and escalation processes.
The effectiveness of these measures is demonstrated by PFMEA-derived controls, safety-focused production tests,
and objective evidence from production records.”

포인트

• “선언” → “논리 + 증거” 전환

---

🔑 Confirmation Reviewer 관점에서 가장 강력한 문장 패턴

OEM이 좋아하는 문장 구조는 항상 이거야:

“…could violate Safety Goals…”
“…therefore…”
“…is prevented or detected by…”

예:

“Production-induced faults that could violate Safety Goal SG-03 are detected by end-of-line safety mechanism tests.”

---

🎯 실무 팁 (진짜 중요)

Safety Case에서 Part 7 문장은 반드시 “동사”가 있어야 해:

• prevents
• detects
• controls
• ensures
• triggers
• restricts

❌ “is described”
❌ “is documented”
⭕