SOVDとEUの修理権：SDVのためのスケーラブルで規制に準拠した診断アクセスアーキテクチャの構築

EU市場で事業を展開するほとんどのOEMは、修理権の遵守についてすでに知っています。1995年以降、自動車ブロック免除規制（MVBER）では、独立系修理業者に差別のない診断アクセスが義務付けられています。これは業界を圧迫する新しい規制ではなく、30年にわたってヨーロッパの自動車市場の運営方法を形作ってきた確立された基準です。

変わったのは車両です。一元管理された HPC、コンテナ化されたアプリケーション、リモート OTA 更新、クラウド接続されたサービスワークフローを備えたソフトウェアデファインドビークルにより、従来の診断アーキテクチャはますます脆弱になっています。スタンドアロンECUや物理的なワークショップへのアクセスが可能だった時代に、MVBERの要件を技術的に満たしていたアプローチは、SDV時代への拡張に苦労しています。

今日のOEMにとって真の問題は、診断アクセスを提供するかどうかではありません。すでに義務付けられています。それは、自社の診断アーキテクチャが、車両ソフトウェアの複雑化に伴って、管理しやすく、安全で、運用上価値のある方法で実際にアクセスを提供できるかどうかです。SOVD はアーキテクチャの答えであり、そのメリットは、規制コンプライアンスをはるかに超えて、OEM がディーラーや独立系サービスネットワークでますますソフトウェア主導型の車両に取り組むことを可能にする方法にまで及びます。

コンプライアンスベースライン:MVBERが実際に必要とするもの

MVBERは、OEMメーカーに特定のEU競争法要件（フランチャイズディーラーネットワークを運営する権利を含む）からの除外を認めています。これは、独立した修理業者は、公正な取引条件のもと、技術データ、診断ツール、および修理情報への差別のないアクセスを受けなければならないという明確な義務と引き換えです。

つまり、OEMは独自の診断アーキテクチャを使用して、独立した修理業者よりも認定ディーラーネットワークを優先するような事実上のアクセス障壁を作り出すことはできません。アクセスは、理論的に許可されているだけでなく、技術的に実現可能でなければなりません。また、車両のソフトウェア定義が進むにつれ、「技術的に実現可能」という基準はますます厳しくなっています。

具体的なイラスト: ある大手OEMがSOVDを検討しているのは、特に自社独自の診断ソリューションを現在の形ではEUに展開できないためです。問題は法的な意図ではなく、アーキテクチャの現実です。ディーラーネットワーク向けに設計された独自のシステムでは、特に診断がソフトウェアやリモートドメインに移行する場合には、MVBER が必要とする差別のないアクセスとはうまく対応できないアクセスパターンが生成されます。

一目でわかるMVBER

1995年から活動し、2028年まで延長されました。OEM に対し、正規ディーラーネットワークが受け取るものと同等の差別のない条件で、独立修理業者に車両修理および技術情報へのアクセスを提供することを義務付けています。OEM の本社所在地に関係なく、EU 市場で自動車を販売するすべての OEM に適用されます。

SDVがアーキテクチャの問題をより困難にする理由

従来の診断は、安定した分散型ECUアーキテクチャを中心に設計されていました。各ECUには固定識別子、静的な記述ファイル、既知のUDS実装がありました。コンプライアンスとは、これらのインターフェースを公開することを意味していました。複雑で不完全ですが、実現可能です。

ソフトウェアデファインドビークルは、いくつかの点でこのモデルを破ります。

• 動的なソフトウェア構成: 最新の SDV は、コンテナ化されたアプリケーションを HPC 上で実行します。OTA が更新されるたびにソフトウェアが変わります。出荷された車両は、6か月後に現場に出回った車両ではありません。静的な記述ファイルや固定ECUマップでは対応できません。
  
• リモートおよびクラウドベースのサービスワークフロー: 遠隔地での事前選別、車両の状態監視、OTAによるサービスアラートなど、車両が工場に到着する前に診断を行うケースが増えています。従来の物理アクセス診断モデルはこのために設計されておらず、レガシーシステムに独自のリモートトンネルをボルトで固定すると、断片化が生じます。
  
• マルチステークホルダーのアクセス要件: MVBERは独立した修理業者のアクセスを必要とします。フリートオペレーターにも独自のアクセス権が必要です。OEM 中央サポートにはリモートでの可視性が必要です。ディーラーの技術者には店内のツールが必要です。エンジニアリングチームには詳細なデバッグアクセスが必要です。これらすべてを、独自のポイント・ツー・ポイント統合で管理するのはスケーラブルではありません。
  
• 監査とコンプライアンスの証拠: UN R156のような規制では、ソフトウェア更新の管理方法に関する構造化された証拠が必要です。保有システムの規模が大きくなるにつれ、プロプライエタリ・システムに散在するログからコンプライアンス・パッケージをまとめることはますます難しくなっています。

その結果、前世代の車両に適した診断アーキテクチャを構築したOEMは、サービスとコンプライアンスの義務が拡大するにつれて、まさに複雑な技術的負債に直面することになります。

SOVD: スケーラブルなアクセスのためのアーキテクチャ基盤

SOVD（サービス指向の車両診断）は、車両診断用の HTTP/REST ベースの API を定義する ASAM 規格（ISO 17978 としてISOを通じて発展中）です。従来の診断ではすべてのツールですべての車両プログラムにカスタム通信ロジックを実装する必要がありましたが、SOVD では共通の API コントラクトを提供しています。診断コンテンツ (障害コード、測定値、構成パラメーター、ソフトウェア更新ステータス) は JSON を使用して標準化された REST エンドポイントを通じて公開され、その機能は OpenAPI 仕様で自己記述されています。

EUのコンプライアンス義務とSDVサービスの複雑さを同時に満たすOEMにとって、SOVDは同じアーキテクチャ投資を通じてその両方に対応します。

1 つのインターフェイスであらゆるアクセスシナリオに対応

SOVDは、リモート（クラウドベース）、近接（店内）、および車内のシナリオで機能する統合APIを定義しています。ワークショップで接続する独立修理業者、リモートで監視している車両オペレーター、サービス訪問前に事前選別を行うOEMサポートエンジニアは、すべて同じ論理インターフェースを介してやり取りします。つまり、アクセスは、たまたま持っている独自のツールスタックではなく、役割ベースの権限によって制御されます。

アーキテクチャは本質的に差別のないアクセスをサポートしているため、MVBERコンプライアンスにとってこれは重要です。OEM が認証レベルを定義し、誰が何を見るかは OEM が定義しますが、インターフェース自体は標準化されており、OEM 固有の VCI やツールチェーンに縛られることはなく、どの認定ツールでも利用できるようになっています。

制御された監査可能なアクセス-OEM が統制を維持

強調しておくべき重要な点は、SOVDは車両診断を誰にも公開していないということです。OEM は OAuth 2.0 と OpenID Connect を通じて認証を完全に制御できます。これは、エンタープライズソフトウェア全体で使用されているのと同じセキュリティ標準です。役割ベースのアクセス制御によって、各クライアントタイプで何ができるかが決まります。独立した修理業者が障害コードや定義済みの診断ルーチンにアクセスできます。OEMエンジニアは、キャリブレーションおよびデバッグ機能をより深く理解できます。フリートオペレーターは、ヘルスデータとステータスデータを確認できます。

変更されるのは、誰がアクセスを制御するか（OEM は今でもそうですが）ではなく、そのアクセスをどのように管理するかです。標準化され、ログに記録され、監査可能な 1 つの API が、大規模に管理するのが難しい断片化された独自の統合のセットに取って代わります。

レガシーECUとHPCベースのアーキテクチャの橋渡し

SOVDでは、既存のECUインフラストラクチャを交換する必要はありません。クラシック診断アダプタは、従来のECUのSOVD要求とUDSコマンド間の変換を処理し、レガシーシステムは引き続き機能します。新しいHPCベースのアプリケーションでは、SOVDを介して診断機能をネイティブに公開できます。独立系修理業者のツールは1つのインターフェースと通信します。ルーティングは車両が内部で処理します。これにより、総入れ替えプログラムなしで、段階的な導入が現実的になります。

副産物としてのコンプライアンス証拠

UN R156は、OEMに対し、更新の計画、実行、検証の方法に関する構造化された証拠を備えたソフトウェア更新管理システムを維持することを義務付けています。SOVD の標準化されたログに記録された API インタラクションは、この証拠を自然に生み出します。ソフトウェアインベントリ、準備状況チェック、更新後の検証、監査ログは通常のSOVD業務の出力であり、コンプライアンスレビュー時に個別のフォレンジック作業を行うものではありません。

ディーラーとサービスネットワークの利点

コンプライアンスだけでなく、SOVDのより深い価値は、SDVにサービスを提供するディーラーや独立系サービスネットワークにもたらすものです。ここで、運用上のROIが具体的になります。

ワークショップ訪問前のリモート事前トリアージ

OEMのセントラルサポートは、サービスに到着する前にSOVDを通じて車両にアクセスできるため、ログの取得、障害パターンの特定、高解像度のデータキャプチャの設定が可能になり、多くの場合、実際に訪問しなくても問題を解決できます。ワークショップへの訪問が必要な場合、技術者は白紙の状態ではなく、背景情報を伝えて到着します。初回修理完了率が向上します。不要な部品交換が減ります。保証費用が下がります。

ソフトウェアアップデートに対応できるディーラーツール

ソフトウェア定義の車両では、OTAが更新されるたびに車両の診断プロファイルが変わる可能性があります。SOVD の自己記述型アーキテクチャにより、ディーラーツールは既に古くなっている静的な記述データベースに頼るのではなく、実行時に現在の車両機能を検出できます。ディーラーは、6 か月前のソフトウェアのスナップショットではなく、現在存在する車両を対象としています。

IPにさらされない独立修理業者による支援

修理権をめぐる争いの核心の一つは、独自のキャリブレーションソフトウェア、ECUコード、価値の高いアルゴリズムを公開することなく、有意義な診断アクセスを提供するにはどうすればよいか、という点です。SOVD は、サービスのカプセル化を通じてこの問題を解決します。このAPIは、基礎となるソフトウェア実装を公開することなく、修理担当者が車両の診断とサービスに必要なもの (故障コード、測定値、定義済みのテストルーチン) を公開します。OEM が診断サービスの境界を定義し、SOVD がそれを適用します。

車両オペレーター向けのスケーラブルなアクセス

車両数が多い、稼働時間が重要な運用、地理的に分散した車両など、車両オペレーターは最も要求の厳しいサービスシナリオの一部です。SOVD では、個々の車両診断に使用されているのと同じ API を使用して車両全体の状態を監視し、障害パターンを集約し、車両全体のソフトウェアバージョンを追跡し、故障が発生する前に予防的なサービスニーズを明らかにします。

シブロスSOVD: 評価から生産まで
‍シブロスはフルビルドしました SOVD オファリング -車載サーバー機能とクラウド/バックオフィスツールの両方を網羅し、アーキテクチャ評価から量産展開に移行するOEM向けに設計されています。当社のサービスには以下が含まれます。

• SOVD クライアント と管理プラットフォーム： ロールベースのアクセス制御、リモートおよび近接診断ワークフロー、車両ライフサイクル全体にわたる構造化された監査ロギング。
• 製造とアフターセールスの統合： 同じSOVDインフラストラクチャが、個別に実装しなくても、エンドオブライン構成、ディーラーサービスツール、リモート車両監視をサポートします。
• OTA とロギングエコシステム: SOVD 診断と ソフトウェア更新管理 Sibrosと並ぶ統合インフラストラクチャでの作業 ディープロガー およびOTA機能。
• SOVD コンサルティングサービス: アーキテクチャに関する意思決定の評価、サプライヤの要件の絞り込み、または車両プログラム全体にわたる段階的なSOVDの導入を計画しているOEM向けです。‍

‍30年間にわたり、欧州連合（EU）の遵守を是正する権利が基準となってきた。変化しているのは手段であり、それに伴い、ソフトウェアデファインドフリート全体でそのコンプライアンスを大規模に提供するというアーキテクチャ上の要求も変化しています。現在 SOVD を中心に診断インフラストラクチャを構築している OEM は、コンプライアンス問題を解決するだけではありません。SDV 時代のサービス運営基盤を構築しています。