ISO 26262 파트 4의 중요성: 자동차 시스템 수준 제품 개발

배경과 문제

시스템 수준이란 무엇입니까? ISO 26262에서 시스템은 요소 집합으로 정의됩니다.

기능 안전은 분석 기법 자체보다, 산출물 간 연결성과 변경 시점의 갱신 속도가 실무 성과를 좌우합니다. 감사/고객 리뷰는 “무엇을 했는가”보다 “근거가 연결되어 있는가”를 봅니다.

핵심 내용

시스템 수준이란 무엇입니까?

ISO 26262에서 시스템은 요소 집합으로 정의됩니다. 단일 시스템이 하나의 아이템이 될 수도 있고, 여러 시스템이 하나의 아이템을 구성할 수도 있습니다. 일반적으로 시스템은 일반적으로 단일 컨트롤러를 나타냅니다. '시스템 레벨'이란 자동차를 구성하는 다양한 기술이 하나의 시스템으로 통합되는 레벨을 말한다. 여기에는 하드웨어, 소프트웨어, 광학, 유압, 기계 등이 포함됩니다. 그러나 ISO 26262는 전기/전자 부품과 관련된 하드웨어 및 소프트웨어에 중점을 둡니다.

시스템 수준이 왜 중요한가요?

전통적으로 자동차 회사는 하드웨어 개발과 소프트웨어 개발을 위한 별도의 팀을 보유하고 있습니다. 이는 종종 두 팀 간의 협력 부족으로 이어집니다. 프로젝트 관리자가 조정을 시도하는 동안 시스템 수준이 명확하게 고려되지 않을 수 있습니다. 그러나 자동차 시스템이 안전하려면 시스템 수준의 통합과 조정이 핵심 요소입니다.

시스템 수준 참조 모델

ISO 26262 4부에서는 시스템 수준의 안전 활동을 세 가지 주요 섹션으로 분류합니다.

1. 기술 안전 개념(4-6): 하드웨어 및 소프트웨어 개발의 전제 조건인 시스템 수준 요구 사항, 아키텍처 및 기술 안전 개념을 정의합니다.

2. 시스템 및 항목 통합 및 테스트(4-7): 하드웨어 및 소프트웨어 개발 후 HW-SW 통합 및 테스트, 시스템 통합 및 테스트, 항목 통합 및 테스트를 수행합니다.

3. 안전 검증(4-8): 안전 목표가 달성되었는지 확인합니다.

이미지 설명: (1) SLP 1024x565: 기능 안전 개념을 설명하기 위한 참고 이미지

기술적 안전 개념

기술 안전 요구사항(TSR)은 기능 안전 요구사항에서 파생됩니다. TSR에는 오류를 감지하고 제어하는 ​​안전 메커니즘 구현이 포함되며, 오류 감지 시 시스템이 안전한 상태로 전환되도록 보장합니다. 이러한 TSR은 아키텍처 요소에 할당되어야 합니다. 또한 안전 관련 요소와 비안전 관련 요소가 모두 단일 아키텍처 내에서 구현되어야 합니다.

시스템 및 항목 통합 및 테스트

통합 및 테스트 단계는 하드웨어 및 소프트웨어 개발 결과를 기반으로 합니다. 하드웨어 및 소프트웨어 개발이 완료된 후 HW-SW 통합 및 테스트, 시스템 통합 및 테스트, 아이템 통합 및 테스트를 수행합니다. 이 단계에서는 테스트 목표를 체계적으로 설정하고 조정표준 근거와 함께 수행검증 기준을 명확히 두고 진행해야 합니다. ISO 26262는 하드웨어-소프트웨어, 시스템, 차량 수준에서 시스템을 통합하고 테스트하기 위한 요구 사항을 정의합니다.

최근 다양한 컨트롤러가 통합 컨트롤러 형태로 통합되면서 통합 및 테스트 전략이 점점 더 중요해지고 있습니다. 실제 시스템 수준 개발 중에 이러한 측면이 간과되지 않도록 하는 것이 핵심 요소입니다.

안전성 검증

안전 검증은 차량 수준에서 안전 목표가 달성되었는지 확인하는 프로세스입니다. 여기에는 항목 기능이 구현되었는지 확인하기 위해 실제 차량에서 장기 테스트가 포함되며, 기능적 안전 개념이 적절하게 적용되어 체계적이거나 무작위적인 하드웨어 오류가 발생할 경우 안전 목표 위반을 방지하며, 오류가 발생하는 경우 운전자가 차량을 제어할 수 있습니다.

요약

ISO 26262 4부에서는 5가지 핵심 사항을 제공합니다.

1. 안전 활동은 시스템 수준에서 조정되어야 합니다.

2. 기능 안전 요구사항(FSR)은 기술 안전 요구사항(TSR)으로 세분화되어 시스템 아키텍처에 구현되어야 합니다.

3. 시스템적 오류(설계 오류 또는 버그)와 무작위 하드웨어 오류를 모두 고려표준 근거와 함께 수행검증 기준을 명확히 두고 진행해야 합니다.

4. 안전 분석에서는 결함의 원인과 영향을 체계적으로 식별표준 근거와 함께 수행검증 기준을 명확히 두고 진행해야 합니다.

5. 시스템 개발 결과는 하드웨어-소프트웨어 통합부터 차량 전체 수준까지 체계적으로 통합되고 테스트되어야 합니다.

이 개요가 ISO 26262 Part 4에 따라 시스템 수준에서 제품 개발의 전반적인 측면을 이해하는 데 도움이 되기를 바랍니다. 감사합니다!

실무 적용 가이드

1. Item/기능 경계를 명확히 하고 HARA 범위를 고정합니다.
2. Safety Goal→요구사항(HW/SW)→검증 케이스를 양방향으로 연결합니다.
3. 설계 변경 시점마다 SPFM/LFM/PMHF와 근거 산출물을 함께 갱신합니다.

체크리스트

• Safety Goal과 검증 케이스가 1:1로 추적되는가?
• 변경 이력(누가/언제/왜)과 승인 근거가 남아 있는가?
• Safety Case 제출 시 “근거 묶음”을 즉시 생성할 수 있는가?

마무리

정리하면 기능 안전은 “완벽한 문서”보다 “연결된 근거와 빠른 갱신”이 품질을 만듭니다. 팀이 반복 가능한 운영 패턴을 갖추는 것이 장기적으로 가장 큰 비용 절감으로 이어집니다.

다음 단계: 프로젝트 산출물 샘플(추적 매트릭스/증적 패키지)이 필요하면 Hermes Solution Technical Briefing을 요청해보세요.