SOVDとは？SDV時代に必要な新しい診断規格

近年、自動車業界では「ソフトウェア定義車両（Software-Defined Vehicle：SDV）」という言葉を耳にする機会が増えています。簡単に言うと、SDVはこれまでの「機械としてのクルマ」から、「コンピュータとしてのクルマ」へと大きくシフトしていく流れのことです。その中心にいるのが、高い処理能力と計算能力を備えた高性能コンピュータ（HPC：High Performance Computer）です。クルマの中に、まるでデータセンターのサーバーが載っているようなイメージです。このHPCがあるからこそ、ソフトウェア定義車両（SDV）は周囲の状況をリアルタイムに理解し、自ら判断して動く高い自律性や、クラウドや他の車両・インフラとつながる高い相互接続性を手に入れることができます。

一方で、「車両診断」という観点から見ると、ここには大きなパラダイムシフトが生まれようとしています。これまでの診断基準は、主にセンサーやアクチュエーター、その配線、ECU間をつなぐバスシステムの故障を見つけることに焦点を当ててきました。例えば、「このセンサーの値がおかしい」「このECUとの通信が途切れている」といった、ハードウェアや配線レベルのトラブルを検出することが中心でした。

しかし、HPCによって駆動されるSDVでは、それだけでは不十分となる可能性があります。「どこかの部品が壊れているかどうか」を見るだけではなく、HPC上で動作している複雑なソフトウェアそのものについても、その動作状況を詳細に分析し、異常や不具合を的確に診断する必要があります。つまり、SDV時代の診断は、従来のようなハードウェア中心の「壊れた部品探し」から、「ソフトウェアとハードウェアを一体として捉え、そのライフサイクル全体を管理・検証する診断」へと役割が拡大しています。こうした新しい要求が、従来とは異なる新たな診断基準や診断フレームワークを定義する動きにつながっており、その代表例の一つが本稿で取り上げるSOVD（Service Oriented Vehicle Diagnostics）です。

SOVDとは何か

従来の車両診断は、車載ECU（電子制御ユニット）ごとに個別に設計された診断プロトコル（主にUDS：Unified Diagnostic Services）を使って行われてきました。現在もこのアプローチは広く利用されていますが、近年のSDV化によって車両ソフトウェアが複雑化し、HPCをはじめとする車載コンピュータの役割が拡大する中で、ECU単位での診断だけでは将来の要求を十分に満たしきれないのではないかという課題が指摘されるようになってきました。

この課題に対応するため、業界標準の整備を行う団体であるASAM（Association for Standardisation of Automation and Measuring Systems）がSOVDの標準化プロジェクトを立ち上げました。ASAMは、車両の診断・試験・検証に関する標準的な仕様を策定し、国際的に普及させることで、自動車メーカーやサプライヤー間の製品やサービスの互換性を高めつつ、診断の高度化と効率化を促進している団体です。SOVD（Service Oriented Vehicle Diagnostics）は、その名のとおり車両診断を「サービス」として捉え直すための標準です。従来の診断では、診断テスターと各ECUが直接対話し、UDS（ISO 14229）などのプロトコルを用いてECU単位でDTCを読み出したり、計測値を取得したり、ソフトウェアを書き換えたりしていました。これに対してSOVDは、車両内に存在する診断機能や状態情報を「サービス群」として抽象化し、そのサービスに対して工場の診断機器、クラウド上のバックエンドシステム、HPC上で動作する車内アプリケーションなど、さまざまなクライアントが共通のインターフェースとデータモデルでアクセスできるようにすることを目指します。言い換えれば、車両全体を「診断サービスを提供するプラットフォーム」と見なし、その入り口を統一するためのAPI仕様がSOVDです。なお、ASAMで策定されたSOVDの内容は、現在ISO 17978シリーズとして国際標準化も進められており、その一部は「ISO/DIS 17978-3」としてAPI仕様がドラフト公開されています。

なぜSOVDが必要になるのか

SOVDが必要とされている根本的な理由は、「SDVというコンセプトそのもの」よりも、それを支えるHPC中心・ゾーン型アーキテクチャへのシフトにあります。従来は、診断テスターがUDSを使ってECUごとに直接アクセスする構成が前提でした。現在もこの方式は広く使われており、多くのケースにおいて問題なく機能しています。しかし、HPCがハブとなって機能を集約し、Ethernetベースのバックボーン上でソフトウェアサービスが多数動作する構成に移行していく中で、「ECU単位の診断」を前提としたアーキテクチャだけで今後もプラットフォーム全体の状態把握やソフトウェアライフサイクル管理に対応し続けられるのかについて、運用性やスケーラビリティの面から懸念が指摘されるようになってきました。どの車両に、どのHPC構成とソフトウェアバージョンが載っていて、どのサービスがどのような依存関係で動作しているのかなどの情報を、近接診断・遠隔診断・車内診断のいずれからでも一貫した形で扱える枠組みが今後必要になる可能性が高い、というのが現在の問題意識です。

もう一つの理由は、エコシステム全体の効率性です。現状では、OEMごとに診断アクセス方式やバックエンド連携の仕組みが大きく異なり、診断ツールベンダーやサプライヤーはOEMごとに別々のインターフェースへ個別対応する必要があります。SDV化に伴いソフトウェア更新の頻度や機能追加のペースが上がれば上がるほど、この「OEMごとのばらつき」はそのまま開発・運用コストやリリーススピードのリスク要因となる可能性があります。SOVDは、こうした状況に対して、車両診断やソフトウェア更新にアクセスするための外部インターフェースをサービス指向で共通化することを目指しています。車両内部でどのようなアーキテクチャ（AUTOSARベースか独自OSか、どのようなゾーン構成か）を採用するかは各社の裁量に委ねつつ、HPCやゲートウェイにSOVDインターフェースを実装することで、工場のテスター、フリート管理システム、クラウドアプリケーション、車内エージェントといった複数のクライアントが同じルールで車両にアクセスできるようにするのがSOVDの目的です。結果として、SDV時代に求められる高頻度のソフトウェア更新や高度な遠隔サービスを、よりスケーラブルかつ持続可能な形で支える基盤になり得る診断規格、それがSOVDに期待されている役割と言えます。

従来の診断方式とSOVDとの違い

ここまで見てきたように、SOVDは「まったく新しい診断」をゼロから発明するものではなく、むしろ既存の診断基盤を活かしながら、その上にサービス指向の共通インターフェースを設けるという発想に近い標準です。一方で、従来の診断方式と比べると、前提としているアーキテクチャや、どこを診断の単位とみなすかという考え方には、明確な違いがあります。

従来の診断方式は、基本的に「ECU単位の診断」を前提としてきました。多くのECUがCANバス上に接続されており、診断テスターはUDSなどのプロトコルを使って個々のECUに直接アクセスします。DTCの読み出しやライブデータの取得、ソフトウェア書き換えといった操作は、テスターとターゲットECUとの間のやり取りとして完結します。この構造はシンプルで分かりやすく、今日でも幅広く利用されていますが、診断の視点はどうしても「どのECUにどんな故障コードが出ているか」「どの通信ラインに異常があるか」といったコンポーネントレベルになります。

これに対してSOVD方式では、診断の単位がECUではなく、車両プラットフォーム上のサービスやリソースへと引き上げられます。HPCやゾーンECUが集約した情報をもとに、「この車両にはどの機能群・ソフトウェアバージョンが載っていて、今どういう状態で動作しているのか」という視点で診断リソースをモデル化し、そのリソースに対して近接診断・遠隔診断・車内診断のいずれからも同じSOVDインターフェースでアクセスできるように設計されています。つまり、SOVDではECUの向こう側にある“機能・サービス”を診断の入口として扱うことを前提としており、ECU間の詳細なやり取りや既存のUDSサービスは、その背後でプラットフォーム側が吸収するイメージになります。

もう一つの違いは、アクセスパスの一貫性にあります。従来方式では、工場での近接診断と、テレマティクス経由の遠隔診断、車内での自己診断は、それぞれ別々の仕組みとして実装されることが一般的でした。同じ情報に到達するにも、経路ごとに別のAPIやデータ形式が存在し、OEMごとの差も大きくなりがちです。SOVDでは、これらを「異なる経路から、同じ診断サービスにアクセスするだけ」という形に揃えようとします。工場のテスターであれ、フリート管理システムであれ、車内エージェントであれ、最終的には同じSOVDのサービス定義にもとづいて診断リソースにアクセスするという姿を目指している点が、従来方式との大きな違いです。

このように、SOVDは既存のUDS/DoIPベースの診断を否定するものではなく、「ECU中心の診断」から「サービス／プラットフォーム中心の診断」へ視点を拡張し、アクセス経路を統一するための枠組みとして位置づけることができます。現時点でSOVDが業界全体に完全に普及しているわけではありませんが、HPCやゾーンアーキテクチャを前提とした次世代車両を考えるうえで、従来方式とのこうした構造的な違いを理解しておくことが、今後の診断設計を検討する際の重要な前提になっていきそうです。

SOVDをどう位置付けるべきか

今後も、車両側のE/Eアーキテクチャ、クラウドやバックエンドの構成、セキュリティ要件、さらには規制動向などに応じて、新しい標準やフレームワーク、ベンダー独自のソリューションが次々と登場してくることが予想されます。その中で重要になるのは、「どの技術がトレンドか」を追いかけることそのものよりも、自社の車両アーキテクチャやサービス戦略との関係の中で、SOVDのような標準をどう位置付けるかを冷静に整理することです。SOVDは、それ自体が目的というよりも、SDV時代の診断アーキテクチャを考えるうえでの「共通言語」の一つです。本記事をきっかけに、自社の製品やプラットフォームとどのように連携し得るのか、どのレイヤーで活用すべきかを検討する入り口としてSOVDを捉えていただければと思います。