SOVD 및 EU 수리권: SDV를 위한 확장 가능하고 규정을 준수하는 진단 액세스 아키텍처 구축

EU 시장에서 활동하는 대부분의 OEM은 이미 수리권 규정 준수에 대해 알고 있습니다.자동차 블록 면제 규정 (MVBER) 은 1995년부터 독립 수리업체에게 차별 없는 진단 서비스를 요구하고 있습니다.이는 업계에 영향을 미치는 새로운 규정이 아니라 30년 동안 유럽 자동차 시장이 운영되는 방식을 변화시켜 온 확립된 기준선입니다.

변경된 것은 차량입니다.중앙 집중식 HPC, 컨테이너화된 애플리케이션, 원격 OTA 업데이트, 클라우드 연결 서비스 워크플로우를 갖춘 소프트웨어 정의 차량은 기존의 진단 아키텍처를 점점 더 취약하게 만들고 있습니다.독립형 ECU와 물리적 워크숍 액세스 시대의 MVBER 요구 사항을 기술적으로 충족했던 접근 방식은 SDV 시대로 확장하는 데 어려움을 겪고 있습니다.

오늘날 OEM의 진정한 문제는 진단 액세스를 제공할지 여부가 아니라 이미 진단 액세스를 제공할 의무가 있습니다.차량 소프트웨어가 복잡해짐에 따라 진단 아키텍처가 실제로 관리 가능하고 안전하며 운영상 가치 있는 방식으로 액세스를 제공할 수 있는지 여부입니다.SOVD는 아키텍처상의 해답이며, SOVD의 이점은 규정 준수를 넘어 OEM이 딜러 및 독립 서비스 네트워크를 통해 점점 더 많은 소프트웨어 기반 차량을 운영할 수 있도록 지원하는 방식까지 확장됩니다.

규정 준수 기준: MVBER가 실제로 요구하는 사항

MVBER은 OEM에 프랜차이즈 딜러 네트워크 운영권을 포함한 특정 EU 경쟁법 요구 사항을 배제하는 권한을 부여합니다. 독립 수리업체는 공정한 상업적 조건으로 기술 데이터, 진단 도구 및 수리 정보에 대한 차별 없는 액세스를 받아야 한다는 명확한 의무를 부여합니다.

즉, OEM은 독점 진단 아키텍처를 사용하여 독립 수리업체보다 공인 딜러 네트워크를 선호하는 사실상의 액세스 장벽을 만들 수 없습니다.접근은 이론적으로만 허용된 것이 아니라 기술적으로도 가능해야 합니다.그리고 자동차가 점점 더 소프트웨어 정의로 발전함에 따라 '기술적 실현 가능성'에 대한 요구도 점점 더 까다로워지고 있습니다.

구체적인 그림: 한 주요 OEM은 특히 독점 진단 솔루션을 현재 형태로 EU에 배포할 수 없기 때문에 SOVD를 모색하고 있습니다.이 문제는 법적 의도가 아니라 건축상의 현실입니다.딜러 네트워크용으로 설계된 전용 시스템은 특히 진단이 소프트웨어 및 원격 도메인으로 이동할 때 MVBER에 필요한 차별 없는 액세스와 정확히 일치하지 않는 액세스 패턴을 생성합니다.

MVBER 한 눈에 보기

1995년부터 활동했으며 2028년까지 연장되었습니다.OEM이 독립 수리업체에게 공인 딜러 네트워크가 받는 것과 비슷한 수준의 차별 없는 조건으로 차량 수리 및 기술 정보를 이용할 수 있도록 요구합니다.OEM 본사가 어디에 있든 상관없이 EU 시장에서 차량을 판매하는 모든 OEM에 적용됩니다.

SDV가 아키텍처 문제를 더 어렵게 만드는 이유

기존의 진단은 안정적인 분산형 ECU 아키텍처를 중심으로 설계되었습니다.각 ECU에는 고정된 식별자, 정적 설명 파일 및 알려진 UDS 구현이 있었습니다.규정 준수를 위해서는 복잡하고 불완전하지만 실현 가능한 인터페이스를 퍼블리싱해야 했습니다.

소프트웨어 정의 차량은 다음과 같은 여러 가지 방식으로 이 모델을 망칩니다.

• 동적 소프트웨어 구성: 최신 SV는 HPC에서 컨테이너화된 애플리케이션을 실행합니다.OTA가 업데이트될 때마다 소프트웨어가 변경됩니다.출고된 차량은 6개월 후 현장에 있는 차량이 아닙니다.정적 설명 파일과 고정된 ECU 맵은 속도를 따라가지 못합니다.
  
• 원격 및 클라우드 기반 서비스 워크플로: 차량이 작업장에 도착하기 전에 원격 사전 분류, 차량 상태 모니터링, OTA 트리거 서비스 경고 등 진단이 점점 더 많이 이루어지고 있습니다.기존의 물리적 접근 진단 모델은 이에 맞게 설계되지 않았으며, 레거시 시스템에 볼트로 연결된 전용 원격 터널은 단편화를 초래합니다.
  
• 다중 이해관계자 액세스 요구 사항: MBER에는 독립 수리공이 접근할 수 있어야 합니다.플릿 운영자들도 직접 접근할 수 있어야 합니다.OEM 중앙 지원에는 원격 가시성이 필요합니다.딜러 기술자에게는 매장 내 도구가 필요합니다.엔지니어링 팀에는 심층적인 디버그 액세스 권한이 필요합니다.독점적인 포인트-투-포인트 통합을 통해 이 모든 것을 관리하는 것은 확장이 불가능합니다.
  
• 감사 및 규정 준수 증거: UN R156과 같은 규정에는 소프트웨어 업데이트 관리 방법에 대한 구조화된 증거가 필요합니다.플릿 규모가 커짐에 따라 독점 시스템 전체에 흩어져 있는 로그로부터 규정 준수 패키지를 조합하는 것은 점점 더 어려워지고 있습니다.

그 결과, 이전 세대의 차량에 적합한 진단 아키텍처를 구축한 OEM은 서비스 및 규정 준수 의무가 확대되는 바로 그 시점에 엄청난 기술적 부채에 직면하게 됩니다.

SOVD: 확장 가능한 액세스를 위한 아키텍처 기반

SOVD (서비스 지향 차량 진단) 는 차량 진단을 위한 HTTP/REST 기반 API를 정의하는 ASAM 표준 (ISO를 통해 ISO 17978로 진행 중) 입니다.기존 진단에서는 모든 차량 프로그램에 대한 사용자 지정 통신 로직을 구현하기 위해 모든 도구가 필요했지만 SOVD는 공통 API 계약을 제공합니다.진단 콘텐츠 (결함 코드, 측정, 구성 파라미터, 소프트웨어 업데이트 상태) 는 OpenAPI 사양을 통해 자체 설명된 기능과 함께 JSON을 사용하는 표준화된 REST 엔드포인트를 통해 노출됩니다.

EU 규정 준수 의무와 SDV 서비스 복잡성을 동시에 해결하려는 OEM의 경우 SOVD는 동일한 아키텍처 투자를 통해 이 두 문제를 모두 해결합니다.

모든 액세스 시나리오에서 단일 인터페이스

SOVD는 원격 (클라우드 기반), 근접 (매장 내) 및 차량 내 시나리오에서 작동하는 통합 API를 정의합니다.작업장에서 연결하는 독립 수리공, 원격으로 모니터링하는 플릿 운영자, 서비스 방문 전 사전 심사를 수행하는 OEM 지원 엔지니어 모두 동일한 논리적 인터페이스를 통해 상호 작용합니다. 즉, 어떤 독점 도구 스택을 보유하고 있는지가 아니라 역할 기반 권한에 따라 액세스 권한이 제어됩니다.

MVBER 규정 준수의 경우 아키텍처가 기본적으로 차별 없는 액세스를 지원하므로 이 점이 중요합니다.OEM은 권한 부여 수준을 정의하며, 누가 무엇을 보는지 알 수 있지만 인터페이스 자체는 표준화되어 있으며 OEM 전용 VCI 또는 도구 체인에 국한되지 않고 모든 인증된 도구에서 사용할 수 있습니다.

통제되고 감사 가능한 액세스 - OEM의 통제 유지

강조할 가치가 있는 중요한 점은 SOVD는 누구에게도 차량 진단을 공개하지 않는다는 것입니다.OEM은 엔터프라이즈 소프트웨어 전반에서 사용되는 것과 동일한 보안 표준인 OAuth 2.0과 OpenID Connect를 통해 인증을 완벽하게 제어할 수 있습니다.역할 기반 액세스 제어는 각 클라이언트 유형이 수행할 수 있는 작업을 정확히 결정합니다.독립 수리업체는 오류 코드 및 정의된 진단 루틴에 액세스할 수 있습니다.OEM 엔지니어는 교정 및 디버그 기능을 더 자세히 이용할 수 있습니다.차량 운영자는 건강 및 상태 데이터를 볼 수 있습니다.

변경되는 것은 누가 액세스를 제어하는지가 아니라 (OEM이 여전히 통제하고 있음) 액세스가 관리되는 방식입니다.표준화되고 기록되고 감사 가능한 단일 API가 대규모 관리가 어려운 단편화된 독점 통합 세트를 대체합니다.

레거시 ECU와 HPC 기반 아키텍처의 연결

SOVD는 기존 ECU 인프라를 교체할 필요가 없습니다.클래식 진단 어댑터는 기존 ECU에 대한 SOVD 요청과 UDS 명령 간의 변환을 처리합니다. 레거시 시스템은 계속 작동합니다.새로운 HPC 기반 애플리케이션은 기본적으로 SOVD를 통해 진단을 제공할 수 있습니다.독립 수리업체 도구가 하나의 인터페이스와 통신하므로 차량이 내부적으로 라우팅을 처리합니다.따라서 전면 교체 프로그램 없이 단계적으로 도입할 수 있습니다.

부산물로서의 규정 준수 증거

UN R156은 OEM이 업데이트 계획, 실행 및 검증 방법에 대한 구조화된 증거와 함께 소프트웨어 업데이트 관리 시스템을 유지하도록 요구합니다.SOVD의 표준화되고 기록된 API 상호 작용은 이러한 증거를 자연스럽게 생성합니다.소프트웨어 인벤토리, 준비 상태 검사, 업데이트 후 검증 및 감사 로그는 일반적인 SOVD 작업의 결과이며 규정 준수 검토 시 취합된 별도의 포렌식 작업이 아닙니다.

딜러 및 서비스 네트워크 어드밴티지

SOVD는 규정 준수 외에도 SDV에 서비스를 제공하는 딜러 및 독립 서비스 네트워크가 이를 통해 얻을 수 있는 더 깊은 가치를 제공합니다.여기서 운영 ROI가 구체화됩니다.

워크숍 방문 전 원격 사전 심사

OEM 중앙 지원 부서는 서비스가 도착하기 전에 SOVD를 통해 차량에 액세스하여 로그를 검색하고, 결함 패턴을 식별하고, 고해상도 데이터 캡처를 구성하고, 대부분의 경우 직접 방문하지 않고도 문제를 해결할 수 있습니다.워크숍 방문이 필요한 경우 기술자는 백지 상태가 아닌 컨텍스트를 파악한 상태로 도착합니다.최초 수리 성공률이 향상됩니다.불필요한 부품 교체가 줄어듭니다.보증 비용이 절감됩니다.

소프트웨어 업데이트와 보조를 맞추는 딜러 도구

소프트웨어 정의 차량에서는 OTA 업데이트가 있을 때마다 차량의 진단 프로파일이 변경될 수 있습니다.SOVD의 자체 설명 아키텍처를 사용하면 딜러 도구가 이미 오래되었을 수 있는 정적 설명 데이터베이스에 의존하지 않고 런타임 시 현재 차량 기능을 찾아낼 수 있습니다.딜러는 6개월 전의 소프트웨어 스냅샷이 아니라 현재 존재하는 차량을 사용합니다.

IP 노출 없는 독립 수리공 지원

수리 권리의 핵심 갈등 중 하나는 항상 독점적인 캘리브레이션 소프트웨어, ECU 코드 및 고가치 알고리즘을 노출하지 않고도 의미 있는 진단 액세스를 제공할 수 있느냐는 것이었습니다.SOVD는 서비스 캡슐화를 통해 이 문제를 해결합니다.API는 수리 업체가 차량을 진단하고 서비스하는 데 필요한 정보 (결함 코드, 측정값, 정의된 테스트 루틴) 를 기본 소프트웨어 구현을 노출하지 않고도 노출합니다.OEM은 진단 서비스 경계를 정의하고 SOVD는 이를 적용합니다.

플릿 운영자를 위한 확장 가능한 액세스

차량 운영자는 많은 차량 수, 가동 시간이 중요한 운영, 지리적으로 분산된 차량 등 가장 까다로운 서비스 시나리오를 대표합니다.SOVD를 사용하면 개별 차량 진단에 사용되는 것과 동일한 API를 통해 차량 수준의 상태를 모니터링할 수 있습니다. 즉, 고장 패턴을 집계하고, 차량 전체의 소프트웨어 버전을 추적하고, 고장으로 발전하기 전에 사전 서비스 요구 사항을 파악할 수 있습니다.

시브로스 SOVD: 평가부터 생산까지
‍Sibros는 전체 건물을 만들었습니다. SOVD 오퍼링 - 차량 내 서버 기능과 클라우드/백오피스 툴링을 모두 포함합니다. 아키텍처 평가에서 생산 배포로 전환하는 OEM을 위해 설계되었습니다.당사 제품에는 다음이 포함됩니다.

• SOVD 클라이언트 및 관리자 플랫폼: 차량 라이프사이클 전반에 걸친 역할 기반 액세스 제어, 원격 및 근접 진단 워크플로우, 구조화된 감사 로깅.
• 제조 및 판매 후 통합: 동일한 SOVD 인프라가 별도의 구현 없이 최종 라인 구성, 딜러 서비스 도구 및 원격 플릿 모니터링을 지원합니다.
• OTA 및 로깅 에코시스템: SOVD 진단 및 소프트웨어 업데이트 관리 Sibros와 함께 통합 인프라에서 작업 딥 로거 및 OTA 기능.
• SOVD 컨설팅 서비스: 아키텍처 결정을 평가하거나, 공급업체 요구 사항의 범위를 지정하거나, 차량 프로그램 전반에서 SOVD 단계적 도입을 계획하는 OEM에 적합합니다.‍

‍EU 수리 규정 준수는 30년 동안 기준이었습니다.변화하는 것은 차량, 그리고 그에 따라 소프트웨어 정의 플릿 전반에 걸쳐 대규모로 규정 준수를 제공해야 하는 구조적 요구입니다.현재 SOVD를 중심으로 진단 인프라를 구축하는 OEM은 단순히 규정 준수 문제를 해결하는 데 그치지 않습니다.이들은 SDV 시대를 위한 서비스 운영 기반을 구축하고 있습니다.