WP.29 요구 사항 및 OTA 시스템 고려 사항

UNECE WP.29 규정의 중요성을 설명하는 시리즈의 세 번째 블로그 게시물에 오신 것을 환영합니다.이제 막 따라가고 계신 분들을 위해 이미 관련 규정을 이해할 수 있는 토대를 마련해 두었습니다. 브레이킹 다운 WP.29 의 세부 사항에 대해 논의했습니다. WP.29 규정 구조.

새로운 WP.29 자동차 규정의 2024년 규정 준수 기한이 빠르게 다가오고 있어 OEM과 OTA (Over-the-Air) 소프트웨어 제공업체 모두 규정 준수를 보장하기 위한 변경 사항과 새로운 프로세스를 구현해야 합니다.이를 위반할 경우 차량 승인 지연, 거래 제한, 법적 책임 등 막대한 재정적 손실이 발생할 수 있습니다.

규제 요건을 완전히 준수하기 위해 제조업체는 규제 요건의 정의, 의미, 규정 준수 증거를 승인 기관에 제공하는 방법을 이해해야 합니다.이 문서에서는 소프트웨어 업데이트 관리 시스템 (SUMS) 과 관련된 두 번째 규정 R156의 주요 WP.29 요구 사항을 다룹니다.주요 프로세스와 시스템 및 소프트웨어 수준의 특정 요구 사항을 다룹니다.

정보 보안 모범 사례

새로운 WP.29 규정에 따라 OEM은 정보 보안 시스템의 모범 사례를 활용할 책임이 있습니다.즉, 차량 제조업체는 모든 관련 문서를 안전하게 보관하고 해당 정보를 보호하기 위한 적절한 보안 통제가 마련되어 있다는 증거를 제공할 수 있어야 합니다.직원은 보안 절차, 문서화 관행 및 품질 보증에 관한 집중 교육을 받아야 합니다.

데이터 보호를 위해 모든 서버는 보안을 유지하고 액세스를 규제하고 모니터링해야 합니다.또한 차량이 배포될 예정인 국가의 승인 기관에 데이터를 즉시 제공할 수 있어야 합니다.규정을 준수하지 않을 경우 생산 또는 유통이 지연될 수 있습니다.WP.29 규정의 이 부분이 자동차 산업에서 완전히 새로운 것은 아닙니다. 다음과 같은 다른 규정 준수에서도 유사한 절차가 필요했기 때문입니다. ISO 27001 및 SOC 유형 2.

OEM은 OTA 공급자가 이러한 모범 사례를 따르고 OTA 소프트웨어 및 데이터 스토리지 관행이 지역 규정을 준수하는지 확인하고 확인해야 한다는 점에서 추가적인 책임이 있습니다.이는 규정과 요구 사항이 다를 수 있는 여러 시장에 제품을 유통하는 OEM의 골칫거리가 될 수 있습니다.예를 들어 유럽에서 판매되는 제품도 다음을 준수해야 합니다. 티삭스 (신뢰할 수 있는 정보 보안 평가 교환).

Sibros 솔루션은 안전, 보안 및 데이터 프라이버시에 대한 여러 국제 규정 준수 표준을 준수합니다.당사의 품질 관리 시스템은 구성 제어 기능을 갖춘 보안 서버에서 모든 정보에 대한 액세스를 제어할 수 있도록 구축되었습니다.여기서 얻을 수 있는 이점은 소프트웨어 업데이트를 관리하는 동시에 각 국가에서 운영하는 데 필요한 다양한 안전, 보안 및 데이터 프라이버시 규정과 표준을 처리하는 단일 시스템에 액세스할 수 있다는 것입니다.

버전 확인

다음 요구 사항에서는 소프트웨어 및 시스템 버전에 고유 식별자가 있어야 하며 이 고유 식별자는 해당 구성 요소의 소프트웨어가 변경될 때만 변경되어야 합니다.또한 WP.29 문서에 명시된 바와 같이 이 고유 식별자는 전자 통신 또는 표준 진단 인터페이스를 사용하여 쉽게 읽을 수 있어야 합니다.BCM (Body Control Module) 과 같은 개별 구성 요소에는 부트로더, 캘리브레이션 및 응용 프로그램과 같은 여러 펌웨어 이미지가 포함될 수 있습니다. 각 구성 요소에는 해당 소프트웨어 구성 요소를 고유하게 식별할 수 있는 적절한 버전이 있어야 합니다.차량 레벨 패키지는 차량 네트워크 아키텍처의 복잡성에 따라 20~80개 이상의 ECU에 이르는 모든 차량 내 ECU 패키지를 모아 놓은 것입니다.

업데이트를 수행하기 전에 소프트웨어 버전은 시스템 수준, 소프트웨어 수준 및 하드웨어 수준에서 요구 사항을 확인하는 검증 주기를 거쳐야 합니다.이는 차량 업데이트 중에 발생할 수 있는 보안 해킹을 차단하고 식별하는 데 있어 매우 중요합니다.

버전 검사를 실시하면 위험을 완화하고 소프트웨어 개발 라이프사이클 동안 진행 상황을 추적하는 데 도움이 될 뿐만 아니라 규제 당국이 구성 요소에서 실행되는 소프트웨어 버전이 OEM에서 정의한 것과 일치하는지 확인할 수 있습니다.특정 프로세스 및 검증 도구에 관한 세부 정보를 제공하면 이 요구 사항이 충족되었음을 입증할 수 있습니다.

Sibros의 Deep Connectivity Platform은 구성 요소의 펌웨어 이미지가 올바른 이미지로 업데이트되었는지 확인하고 모든 버전 식별자를 수신하라는 요청을 차량에 전송하여 이러한 요구 사항을 간소화합니다.시스템은 먼저 차량 버전 매니페스트를 생성하여 전체 프로세스를 실행합니다. 차량 버전 매니페스트는 펌웨어 패키지의 일부이며 메타데이터와 함께 ECU 버전의 컬렉션입니다.이 정보는 차량의 ECU별 업데이트가 필요한지 여부를 결정하는 데에도 사용됩니다.장애 발생 시 Sibros는 딥 업데이터 오류를 식별하고 버전을 재시도하고 재검사하여 업데이트가 성공적으로 완료되었는지 확인합니다.소프트웨어 업데이트 프로세스 중 어느 시점에서든 장애가 발생하면 차량 펌웨어가 현재 소프트웨어 버전에 대한 정보가 포함된 세부 배포 로그를 OEM에 업로드하여 문제를 추가로 해결합니다.

표적 식별 프로세스

종종 소프트웨어 업데이트는 특정 모델 플릿의 일부 차량에만 적용됩니다.포드의 2020년을 예로 들어 보겠습니다. LED 헤드라이트 리콜 217,185대의 F150 트럭 중 조명이 너무 밝아서 해당 연식 차량의 약 28% 에 해당합니다 (포드는 2020년에 787,000대의 F150을 판매했습니다).WP.29 요구 사항의 이 부분에는 OEM이 소프트웨어 업데이트 대상 차량을 식별할 수 있는 프로세스를 마련해야 한다고 명시되어 있습니다.

대상 소프트웨어 업데이트를 출시하는 기능은 다양한 차량 속성을 기반으로 특정 대상 그룹을 생성할 수 있기 때문에 OEM에게 가장 중요한 기능 중 하나라고 할 수 있습니다.이러한 속성은 색상, 제조사, 모델 또는 변속기 유형과 같은 정적 속성일 수도 있고 F150 헤드라이트 리콜 예시와 같은 변수 및 데이터 관련 속성을 기반으로 하는 속성일 수도 있습니다.Sibros는 다음과 같은 점에서 다른 OTA 제공업체와 차별화됩니다. 딥 로거 수신되는 차량 데이터를 동적으로 분석하고 소프트웨어 업데이트가 필요할 때 OEM에 경고하는 제품입니다.

F150 헤드라이트의 예로 돌아가서 Sibros의 Deep Logger 시스템은 모든 차량의 데이터를 기록하고 결함이 발생한 차량만 식별할 수 있습니다.그런 다음 해당 차량의 진단 데이터를 사용하여 결함을 수정하기 위해 적절한 소프트웨어 패키지 업데이트가 필요한 대상 그룹을 만듭니다.OEM이 소프트웨어를 개발, 개선 및 테스트하고 적절한 승인을 받으면 Deep Updater 시스템은 대상 그룹의 차량에만 소프트웨어 업데이트를 전송합니다.

WP.29 SUMS 규정의 모든 측면과 마찬가지로 OEM은 승인 기관에 이 요구 사항을 준수했다는 증거를 제시해야 합니다.Sibros OTA 솔루션은 이러한 모든 요구 사항을 충족하므로 OEM은 정적인 대상 그룹을 뛰어넘어 소프트웨어 문제가 발생할 때 이를 동적으로 평가하고 수정할 수 있습니다.

안전 보장 메커니즘

언제 어디서나 업데이트할 수 있는 휴대폰과 달리 차량 업데이트는 부적절하게 수행될 경우 큰 안전 위험이 따릅니다.차량이 도로에 있는 동안 업데이트를 하면 운전자, 승객 및 기타 무고한 구경꾼의 안전이 위험해질 수 있습니다.이런 현상은 이미 자동차 산업에서는 시기상조였을 때 이미 목격되어 왔습니다. OTA 업데이트 한 운전자가 바쁜 고속도로에서 몇 시간 동안 발이 묶였어요.또한 WP.29에서 언급한 바와 같이 OEM은 위험 분석 및 위험 평가 (HARA) 를 기반으로 실패한 업데이트를 관리하기 위한 안전 상태를 결정해야 합니다 (HARA에 대한 자세한 내용은 ISO 26262의 섹션 6, 챕터 3: 개념 단계 참조).이전 버전으로 롤백하는 것이 불가능하거나 바람직하지 않은 경우에는 차량의 성능이나 기능이 저하되더라도 안전 상태를 구현해야 합니다.

WP.29 SUMS 규정의 일부에는 차량이 안전하지 않은 상태일 때 소프트웨어 업데이트가 발생하지 않도록 하는 안전 장치가 필요하다는 것은 놀라운 일이 아닙니다.여기에는 차량 사용 시기 인식부터 전력 부족 문제 해결, 차량 기술이 업데이트를 수용할 수 있는지 확인하는 것까지 모든 것이 포함됩니다.기능 안전 요구사항과 관련된 모든 사항은 ISO 26262의 여러 장에 있는 권고사항을 준수해야 하며 안전 분석을 거쳐야 합니다.소프트웨어 업데이트 관리 시스템 (SUMS) 과 관련하여 이러한 기능 안전 요구 사항의 예로는 소프트웨어 업데이트가 실행되기 전에 차량이 정지 상태여야 한다는 것이 있습니다.

OTA 시스템은 업데이트를 출시하기 전에 특정 조건이 충족되었는지 확인할 수 있어야 하며 업데이트 실패 시 차량 기능도 복원해야 합니다.Sibros의 소프트웨어는 고장 분석을 포함한 엄격한 안전 검사를 거쳐 에 설명된 대로 모든 기술 안전 요구 사항을 검증합니다. ISO 26262 충족됩니다.

소프트웨어 업데이트 관리 시스템에 대한 Sibros 솔루션

WP.29 소프트웨어 업데이트 관리 시스템 요구 사항을 이해하는 것이 성공적인 제품 출시를 위한 첫 단계입니다.Sibros와 파트너 관계를 맺으면 당사의 심층 연결 플랫폼을 통해 귀사는 모든 WP.29 요구 사항을 증거 기반으로 준수할 수 있습니다. 

Sibros 솔루션을 통해 OEM은 규정을 준수할 수 있는 OTA 플랫폼을 이용할 수 있을 뿐만 아니라 안전하고 안전한 롤아웃을 수행하기 위한 모범 사례에 대한 교육 및 지침을 얻을 수 있습니다.여기에는 단계별 출시를 구현하는 방법, 안전 관련 조건을 테스트하는 방법, 테스트 책임을 이해하는 방법, 안전 가정을 설정하는 방법이 포함됩니다.

더 자세히 알아보고 싶으신가요?문의하기 딥 커넥티비티 플랫폼을 시연하고 Sibros가 조직이 자동차에 대한 WP.29 시스템 요구 사항을 탐색하는 데 어떻게 도움이 되는지 알아보십시오. 소프트웨어 업데이트 관리 시스템.