Skip to main content

A-SPICE, ISO26262 & ISO21434 동시 적용에서의 고려사항

I. 배경

자동차 소프트웨어 개발 현장에서 소프트웨어의 품질 및 투명성을 향상시키기 위해 다양한 국제 표준이나 프로세스 모델들(예, Automotive SPICEⓇ, ISO 26262, ISO/SAE 21434 등)을 적용하고 있으며, OEM들의 필수적인 요구사항으로 인식되고 있습니다.

공급사에서 개발하고 공급하는 “소프트웨어 시스템”은 일반 기능부터, 안전 및 사이버보안 기능들이 하나의 제품형태로 납품되지만, 많은 공급사들이 책임부서가 다르거나, 관련 표준들을 통합하여 개발한 이력이 부족하여 별개로 적용하거나, 작업산출물을 별도로 생성하는 경우가 많이 있습니다.

물론, 표준별로 고객사의 책임부서들이 달라서, 관련 산출물 대응을 위해 별도로 작성하기도 합니다.

실제로 계획단계에서 요구되는 프로젝트 계획, 안전 계획, 사이버보안 계획 등이 개별 산출물로 작업되거나, 엔지니어링 핵심 문서인 안전 및 사이버보안 요구사항, 시스템 아키텍처의 주요 속성인 기술안전 컨셉, 사이버보안 컨셉, 소프트웨어 안전 및 사이버보안 메커니즘 등을 기존의 개발 산출물과 개별로 작성하여 관리하고 있는 사례들이 많이 발생합니다.

또한 공통적으로 요구하는 형상/변경 관리 및 문제점 관리, 품질에 대한 모니터링 방법은 A-SPICE를 사용하는 경우 중요하게 적용하나, ISO 26262, ISO/SAE 21434는 명확하게 적용한 근거를 찾기가 어려운 경우들이 종종 나타나고 있습니다.  

이러한 상황으로, 해당 프로세스 적용시 중복작업이 많이 발생하거나, 산출물 간의 일관성의 이슈들이 빈번하게 나타나고 있습니다.

본 문서에서는 이러한 이슈들에 대한 몇 가지 접근법을 기술하고자 합니다. 물론 실질적인 해결을 위해서는 여러가지 이슈나 애로사항들이 있을 수 있지만 본 기사가 관련분야의 담당자분들에게 조금이나마 도움이 되었으면 합니다.

II. 국제 표준 및 프로세스 모델의 요구사항 비교

1. 프로젝트, 기능안전 및 사이버보안 관리

위의 표와 같이, 프로젝트 수행을 위한 모든 활동(계획, 개발 및 검증 수행, 모니터링, 지원 활동 포함)을 계획하고 모니터링하고 조정해야 하는 것은 동일하게 요구하고 있습니다. 단, 기능안전 관점과 사이버보안 관점에 대한 활동이 추가됩니다. 기능안전은 확인조치(Confirmation measure)라는 활동을 요구하고, 사이버보안은 사이버보안 지원활동을 제품의 폐기까지 하는 부분까지 명기하도록 요구하고 있습니다.

원칙적으로 프로젝트 관리는 일반 기능이나, 보안 기능이나, 안전기능을 포함해서 관리해야 합니다. 그렇게 해야 완전한 제품으로써 프로젝트를 통제하면서 진행할 수 있기 때문입니다. 또한 만약 Fail-operation에 대한 기능안전 요구사항이나 소프트웨어 내에 Secure boot 및 OTA등의 사이버보안 요구사항이 있다면, 일반적으로 해당 개발활동이 분리해서 진행되지 않고, 프로젝트 내에서 동시에 진행되기 때문입니다.

그러므로 각각의 표준들이 요구하는 계획서를 효과적으로 작성 유지하기 위해서는 하나의 문서내에 모든 개발, 안전, 사이버 보안 활동들을 계획하고 모니터링 및 통제하는 것이 더 효과적일 것입니다.

물론, 필요하다면 일부 내용들에 대해서는 별도의 문서로 정리할 수 있습니다. 하지만 반드시 각 관련 산출물 간의 일관성 (내용 및 상호 참조하는 버전 등)을 유지해야 합니다.

 

2. 엔지니어링 영역

엔지니어링 활동으로 생성되는 작업 산출물은 크게 사양과 설계, 테스트케이스 및 제품 등으로 분류할 수 있습니다. 본 내용은 별도의 기사에서 좀 더 심도 있게 설명을 해야 하지만, 아래와 같이 정리할 수 있을 것 같습니다.

  • 사양: 가능할 시 하나의 문서로 작성하고, 반드시 항목들의 분리가 되고 추적이 되어야 함
  • 설계: 가능하면 하나의 문서로 작성하고, 별도의 항목으로 추적이 되어야 함 (특히 설계는 분리해서 작성시 적절히 설명되지 않을 수 있음)
  • 테스트 명세: 가능하면 같이 작성하는 것이 좋으며, 제품 전체 기능에 대한 테스트 커버지를 확인하기 유리하며, 별도의 항목으로 추적이 되어야 하는 것은 동일 함.
  • 제품: 별도로 만드는 것이 불가능함.

 

3. 형상, 변경관리 및 요구사항 관리

공통적으로 해당 활동으로 생성되는 작업 산출물들은 형상관리, 변경관리, 요구사항 관리 및 문서화 관리 등에 의해 관리되고 통제되어야 한다고 요구하고 있습니다. (A-SPICE – GP2.2.2, GP2.2.3, ISO26262 – 6.4.7, ISO/SAE 21434 – [RQ-06-11, RQ-06-12])

특히 “요구사항 변경”, “결함으로 인한 변경”, “안전기능의 변경”, “사이버보안 기능의 변경”등은 많은 기능에 영향을 주는 매우 중요한 요소로서 변경에 대한 식별, 분석, 통제, 수행 및 검증 등이 통합되어 일관성 및 추적성을 확보할 수 있어야 합니다. 또한 이러한 기능과 관련된 항목들(특히 제품, 소스코드, 하드웨어 및 기구 등을 포함)은 명확히 형상항목으로 식별되어 형상통제 하에서 형상상태에 대한 무결성을 유지하고, 고객 및 생산으로 릴리즈 되어야 합니다.

그리고 요구사항 관리 측면에서 모든 기능들은 이해관계자 요구사항(고객, 협력업체, 내부 등)에서부터 시스템-하드웨어-소프트웨어-제품에 이르기까지 개별 항목(기능, 비기능-안전, 사이버보안, 신뢰성 등)별로 추적이 가능하고 일관성이 있어야 합니다

즉, 형상 및 변경관리와 요구사항 관리는 하나의 프로세스를 통해 영역별 단일 작업산출물 또는 필요시 통합하여 생성하는 것이 제품의 품질적인 측면만 아니라, 프로세스 품질적인 측면에서도 훨씬 유리합니다.

 

4. 품질 보증 및 문제점 관리

프로젝트 수행 시, 문제점은 일반 기능, 안전 기능 및 사이버 보안 활동 수행 및 작업 산출물 개발 시 언제든지 발생할 수 있습니다. 아래와 같이 문제점들은 아래와 같이 분류할 수 있습니다.

  • 이슈: 프로젝트 진행과정에서 계획대비 불일치가 발생하는 일정, 범위, 리소스 및 품질 이슈 등의 문제점들
  • 결함: 제품의 테스트 및 작업 산출물의 개발 시 발생하는 결함
    • 작업 산출물의 리뷰 결함: 고객, 내부, 공급사 관점 등
    • 제품의 결함: 고객, 내부, 공급사 관점 등
  • 부적합 사항: 계획되거나 정의된 프로세스 이행의 불일치 사항
    • 품질 감사로 발견된 부적합 사항
    • 기능안전 및 사이버 보안 감사 발견된 부적합 사항
    • 형상 상태 점검 및 감사로 발견된 부적합 사항
    • A-SPICE 심사, 기능안전 심사, 사이버보안 심사 시 발견된 부적합 사항 등

위의 여러가지 문제점들은 제품 개발 시 필연적으로 발생할 수 있는 인자들로서, 하나의 프로세스를 통해 통합 관리하는 것이 제품의 품질을 달성하는데 매우 효과적입니다.

이러한 문제점들의 유형(위의 내용 참조) 및 출처 등에 대한 기준과 안전 및 사이버보안 관련 문제점들을 문제점 속성내에서 식별이 가능하도록 적용한다면 작업산출물을 별도로 관리해야 하는 번거로움을 피할 수 있습니다.

 

그리고 품질 보증 측면에서 제품 개발 시 적용되는 프로세스 및 작업 산출물의 품질 감사를 수행한다면, A-SPICE의 SUP.1의 활동과 ISO 26262 Functional safety audit, ISO/SAE 21434의 Cyberseucurity audit 활동을 통합해서 수행하고 발견된 불일치 사항은 통합된 문제점 관리 프로세스로 해당 문제점들의 식별, 추적, 해결을 통해 전체적인 품질을 보장할 수 있습니다.  

만약 ISO 26262의 Confirmation measure의 하나의 요구사항인 confirmation review를 품질 활동의 하나의 방법(예, 일부 산출물의 품질 보증 활동 기준)으로 활용하는 것도 효과적입니다. 단 이러한 부분을 통합하기 위해서는 독립성 및 해당 부분에 대한 역량(Competency)의 확보가 전제가 되어야 합니다.

결론적으로

차량 “소프트웨어 시스템“에는 다양한 기능들이 탑재되어 일반적인 기능부터, 안전, 보안 기능들이 서로 융합되어 하나의 기능처럼 유기적으로 동작하기 때문에, 개별로 요구하는 프로세스 모델이나 표준들을 별개로 적용하는 것은 엔지니어들에게 이중 또는 삼중의 활동을 강요하거나, 개발에 혼란을 줄 수 있는 가능성들이 있습니다. 또한 제품의 공급하는 프로젝트의 상태를 측정하는 것 또한 어려움이 있을 수 있습니다. 그러므로 별개로 요구하는 프로세스들 중 많은 부분이 통합이 가능하기 때문에 가능하면개발을 하나의 프로세스에서 수행하도록 하는 것이 좋습니다.

제품을 개발하기 위해 프로세스를 적용하는 것은, 제품의 품질 및 납기를 만족하기 위해서 하는 활동이므로 프로세스를 수행하는 것이 목적이 되어서는 안 된다는 점을 분명히 해야 합니다.

[Reference]

  • ISO/IEC/IEE 24765(2017) Systems and software engineering — Vocabulary
  • Automotive SPICE® Process Reference Model & Process Assessment Model Version 3.1
  • Automotive SPICE® Guidelines 1st edition, September 2017
  • ISO 26262(Second edition), Road Vehicle-Functional Safety-Part 2: Management of functional safety
  • ISO 26262(Second edition), Road Vehicle-Functional Safety-Part 8: Supporting processes.
  • ISO/SAE 21434 Road vehicles — Cybersecurity engineering (2021-08)