Part2 프로세스 조정(tailoring)

기능안전 업무를 수행하는데, ISO 26262 Part2를 준수하려면, 개발 형태에 따른 개발 프로세스 조정이 필요한 것으로 알고 있거든, 예를 들어 엘리먼트 재사용이면, 이 재사용에 따른 영향 분석을 하고, 이에 따른 프로세스 조정 결과 기반의 기능안전 개발 활동이 계획이 되어야 하잖아. 근데 기본적으로 기능안전을 수행한다고 했을 때 신규 개발 일 떄는 어느 기능안전 개발 활동들이 계획되어야 하고 엘리먼트가 재사용일 때는 어느 정도가 테일러링 되어서 프로세스 조정이 되어야 하는지 감이 안 잡히거든. 그러니까 너가 실제 사례를 들어서(양이 많아도 생략하지 말고) 테일러링을 할 필요 없을 때는 어떤 기능안전 개발 활동을 계획해야 하는지, 만약 엘리먼트 재사용을 하게 된다면 테일러링을 할 필요 없을 때 대비 기능안전 개발 활동 계획이 어떻게 바뀌는지 알려줘

 

 

아래에서는 ISO 26262 Part 2(관리 프로세스) 관점에서

1. 신규 개발(New Development) 시 수행해야 하는 기능안전 개발 활동 전체 흐름을 “실제 사례 수준”으로 상세히 제시하고,
2. 엘리먼트 재사용(Pre-existing Item / SEooC / Legacy Component) 시 어떻게 테일러링이 이루어지고 활동 계획이 어떻게 바뀌는지를 “빠짐없이” 비교 설명해줄게.

---

✅ 1. “신규 개발” 시 ISO 26262 Part 2에서 요구하는 기능안전 개발 활동 (전체 흐름 + 실제 사례 수준)

여기서는 “신규 ECU(예: 전동식 파워스티어링 ECU)” 개발 프로젝트를 가정해 설명할게.

---

🔷 1) 기능안전 관리/프로세스 계획 수립 (Safety Management)

신규 개발 시 수행하는 전체 활동

1. Safety Culture & Competence Management
   • 안전 관련 역할별 자격/경력 정의
   • 기능안전 엔지니어 교육 계획 수립
2. Safety Plan 작성 (FS Plan)
   • 프로젝트 단계별 안전 활동 정의
   • HARA 일정, FSC, TSC 일정 포함
   • Safety Case 개발 계획 포함
   • 독립성(Independence) 요구사항 반영
     (예: ASIL D → 검증활동 Independent Reviewer 필요)
3. Tailoring 결정
   • 표준 프로세스를 어떤 사유로 조정하지 않고 “그대로 사용”하는지 명시
   • 예: 신규 개발이므로 표준 완전 적용
4. Change Management, Configuration Management 계획
   • 각 안전 산출물의 형상관리 정책 정의
   • 안전 영향이 있는 변경에 대한 절차 정의
5. Supplier Management
   • 공급사 선정 기준
   • ASIL 요구반영된 SW/HW 요구사항 전달
   • 인터페이스 정의 및 안전 관련 커뮤니케이션 체계

→ 신규 개발에서는 ISO 26262 Part2에서 요구되는 모든 Safety Management 활동을 Fast-track 없이 그대로 수행해야 함.

---

🔷 2) 아이템 정의(Item Definition) & HARA 수행

신규 개발 시 수행하는 전체 활동

1. 아이템 정의서 작성
   • 기능, 경계조건, 주변 시스템, 운영상 조건(Operational Scenarios), HMI 등 상세 명세
   • 예: EPS의 기능, 토크센서, ECU, 모터 etc.
2. HARA 수행
   • 기능별 Hazardous Event 분석
   • Exposure(운행빈도), Severity(중대도), Controllability(제어가능성) 평가
   • ASIL 할당
3. Safety Goals 도출
4. FSC(Functional Safety Concept) 작성
   • Safety Goal 기반 기능안전 요구사항 정의
   • 기능안전 아키텍처 정의(“기능 수준”)

---

🔷 3) 기술안전개념(TSC) & HW/SW 개발 프로세스 계획

신규 개발 시 전체 활동

1. TSC 작성
   • FSC를 SW/HW 아키텍처로 변환
   • ASIL 할당 반영된 기술 요구사항 포함
2. HW Safety Requirements, SW Safety Requirements 정의
   • HW/SW 개발 V-Cycle 전체 포함
   • ASIL에 따른 검증 활동(예: MC/DC coverage for SW 등)
3. 시스템 설계(System Architecture)
4. HW 설계, SW 설계
5. HW/SW 구현(Implementation)
6. HW/SW 검증 및 확인(Verification)
   • 코드 검증, 단위 테스트, 통합 테스트, HW FMEA 등

---

🔷 4) 안전 검증(Safety Validation) 및 Safety Case

1. Safety Validation Plan 작성
2. Vehicle-level/ System-level Validation 수행
3. Confirmation Review + Functional Safety Assessment(FSA)
4. Safety Case 작성

---

💡 결론 – 신규 개발의 특징

ISO 26262의 모든 요구 프로세스를 Full 적용한다.
Tailoring이 거의 발생하지 않는다.

---

✅ 2. “엘리먼트 재사용(Element Reuse)” 시 ISO 26262 Part 2 기준 프로세스 변화(테일러링)

여기서는 다음 두 상황을 분리하여 설명할게:

① 기존 ISO 26262 인증된 Safety Element 즉 SEooC

② ISO 26262 고려 없이 개발된 Legacy Component 재사용

두 경우 모두 “테일러링을 해야 한다”는 공통점이 있지만 내용은 다름.

---

✔ 케이스 A: SEooC (Safety Element Out Of Context) 재사용

예: 외부 공급사가 이미 ASIL B 인증 받은 “모터 드라이버 IC”를 SEooC로 제공한다고 가정.

🔷 SEooC 재사용 시 프로세스 조정(Tailoring)

ISO 26262 Part 2는 다음을 요구함:

1) 재사용 가능성 평가 (Impact Analysis / Reuse Assessment)

• SEooC의 Safety Manual을 기반으로
  "우리 Item의 Safety Goals / 운영 조건 / Fault Tolerance Time" 등과 충돌 없는지 분석
• 사용전제(Assumptions of Use)를 충족하는지 검증
• 환경 변화(전압, 온도, 주변 회로 등) 영향을 분석

➡ 신규 개발 대비 달라지는 점

• 아이템 정의 단계 일부가 “재사용 엘리먼트의 제한사항 분석” 중심으로 변경됨
• Safety Goal부터 다시 만들 필요는 없지만, “적용 가능한지” 평가 필요

---

2) Missing Requirements Gap 분석

• SEooC 문서에 ASIL 요구사항이 미비한지 확인
• Gap이 있으면 추가 SW/HW Safety Requirement 작성

---

3) 검증 활동 테일러링

• SEooC에서 제공한 검증/테스트/안전 분석 결과 활용
• 우리 시스템에서의 통합 테스트만 추가 수행

예:

• 공급사 제공 테스트 → 단품 수준 검증 인정
• 우리 회사에서는 “시스템 통합 시 요구되는 Safety Mechanism 동작 확인”만 수행
  (예: 모터 드라이버 Fail-safe 동작 확인)

---

4) Safety Plan 조정

• SEooC에서 이미 수행한 활동 제외
• “우리 시스템에서 해야 할 적용 검증만 포함”

---

5) Safety Case 조정

• SEooC Safety Case를 Evidence로 포함
• Integration Safety Case만 작성하면 됨

---

✔ 케이스 B: Legacy Component (기능안전 고려 없이 개발된 기존 엘리먼트) 재사용

예: 5년 전 개발된 MCU 드라이버 SW 모듈 재사용한다고 가정.

🔷 Legacy Component 재사용 시 테일러링 활동

1) 상황 분석 (Pre-existing Item Analysis)

ISO 26262 Part 2가 요구하는 가장 중요한 활동.

• 기존 개발 이력, 테스트 기록, 코드 품질, 변경 이력 분석
• ASIL 요구사항 충족 수준 평가
• 안전 기능 영향 분석(HW, SW Fault 영향 분석 포함)

➡ 신규 개발 대비 “안전 기본개념(FSC/TSC) 일부를 다시 작성해야 할 수도 있음”

---

2) 추정 ASIL(ASIL Decomposition)에 따른 Gap 보완

• Legacy SW가 ASIL 요구사항 충족 어려운 경우
  → Safety Mechanism 추가하여 ASIL 완화 가능

예:

• 기존 MCU Driver가 ASIL D 충족 불가 →
  SW Wrapper에 "output range monitoring" 추가하여 ASIL 요구 준수

---

3) 문서/산출물 보완 (Backfilling)

Legacy Component에는 다음이 없음:

• Safety Requirement 목록
• Safety Analysis(FMEA/FTA)
• 검증 기준(ISO26262 형식)

따라서 “재사용을 위한 최소 안전 문서 세트”를 새로 작성해야 함.

---

4) 검증 및 테스트 재수행

• 기존 테스트는 ISO 26262 기준 미달 가능
• ASIL 요구에 따라 단위 테스트/커버리지 재수행 필요

예:

• 기존 커버리지 60% → ASIL B 요구는 90%
  → 추가 테스트 필요

---

5) Safety Plan에서 Scope 대폭 확대

• Gap 보완 활동 추가
• 신규 개발보다 일정이 더 커질 수도 있음

🔥 실제 사례 스타일 예시 (결론)

▶ 신규 개발

• Safety Plan 전체 작성
• HARA → FSC → TSC 전체 수행
• HW/SW Safety Requirement 전부 신규 작성
• 테스트/검증 Full 수행
• Safety Case 처음부터 작성

▶ SEooC 재사용

• Safety Manual 기반 영향 분석
• 확인 테스트만 수행
• Safety Plan에서 이미 수행된 활동 제거
• Integration Safety Case 작성만 추가

▶ Legacy 재사용

• 영향 분석 수행
• 누락 문서 Backfilling
• 재검증 테스트 대폭 필요
• Safety Case 거의 신규 수준 작성