車載ソフトウェアの品質保証とSDV

SDV（Software Defined Vehicle）の進展により、車載ソフトウェアの開発規模と複雑性は拡大し続けています。OTAアップデートによる機能の継続的な更新、自動運転・運転支援機能の搭載、様々な外部デバイスとのコネクティビティの増加によって、ソフトウェアが担う品質責任範囲は広がり続けています。

しかし、こうした中でも、品質保証の基本構造は変わりません。品質の高いソフトウェアを作り上げる活動（いわゆる「品質の作りこみ」QE：Quality Engineering）を十分に実施したうえで、品質を証明（いわゆる「品質保証」QA：Quality Assurance）することが、車載ソフトウェア品質保証の原則となります。SDVへの移行によって、品質活動の範囲の拡大と速度向上は求められますが、品質保証の原則そのものを書き換えるものではありません。
本記事では、QEとQAの定義から、Automotive SPICE®を土台とする品質基準、そしてSDV時代における車両アーキテクチャの変革、車両APIとビークルOSの登場、短周期開発と継続的アップデートが品質活動に与える影響まで順に解説します。

まずは、車載ソフトウェア開発における品質活動の構成要素である、品質の作りこみ（QE）と品質保証（QA）の詳細定義を解説します。

開発チームは各工程においてソフトウェアに不具合が入り込まないように設計、実装、検査工程を遂行していき（プロダクト品質の作りこみ）、開発チームとは独立した品質部門は客観的に品質が十分であることを監査・レビューによって証明（品質保証）します。この2つの品質活動によって対外的な品質説明責任を果たすことが可能になります。

開発チームはコストや納期の制約があるなかで開発を進めており、品質が後回しになりやすい構造にあります。そのため、品質保証は開発チームと利害関係が薄く、客観性を保てる独立した組織が実施することが求められます。

品質基準とは、開発した成果物やそのプロセスが、一定以上の品質を満たしていることを示す合格条件のことであり、ここでは日本や欧州を中心に品質基準の成り立ちを含め説明します。

品質は言い換えるとエンドユーザーを含めたすべての利害関係者の満足度であり、車載ソフトウェアの開発が徐々に発展し始めた頃においては、具体的な品質を評価するものさしがないことが課題でした。

この課題を解決することを目的にAutomotive SPICE®が策定されました。Automotive SPICE®は開発プロジェクトの品質をアセスメント(評価)するための「評価モデル」であり、開発プロセスそのものではありません。しかしながら現在においてはこの評価基準を満たすようにプロセスを定義し、品質を作りこみ、その品質を保証することが、現在の日本・欧州における車載ソフトウェア開発における一般標準となりました。

安全やセキュリティ、AIなど専門特化した国際規格も、車載ソフトウェア開発にて遵守すべき品質基準として定められています。いずれもAutomotive SPICE®によって一定の品質が保たれたうえで、専門分野に対して強化した品質観点を付け加える構図となっています。

前章にてSDV時代となっても品質活動の原則は変わらず、その品質基準の土台にAutomotive SPICE®があり、リスク領域に特化した国際規格を加えて車載ソフトウェア開発が成立する構図になっていることを述べてきました。

本章では本質的な原理は変わらない中でSDVにおける以下3つの大きな変化点がどのように品質活動に影響や変化をもたらすのかを解説します。

• 車両アーキテクチャの変革
• 車両APIの共通化およびビークルOSの登場
• 短周期開発と継続的アップデート

SDVの進展によって大きく変化する事柄の1つが車両アーキテクチャの変革です。車両アーキテクチャは次の図のように分散ECU型からドメインアーキテクチャを経てゾーンアーキテクチャへと移行しつつあります。

初期の自動車は、ハード制御（ソフトウェアが介在せず、物理的な回路（ハードウェア）だけで機械を制御する方式）によって実現される部品を組み合わせて作られていました。

マイコンの登場によりハード制御を省スペースかつ安価にソフトウェア制御（ソフトウェアにより機械を制御する方式）に置き換えられるようになり、各自動車部品がソフトウェア制御によって機能を提供する時代のアーキテクチャが分散ECU型です。

ソフトウェア制御の登場によってハードウェアに比べてより複雑な演算回路を実現できることとなり、テストのルートや項目数（テストケース、テストパターン）も飛躍的に増加しました。

品質活動としては、コードカバレッジによる網羅性や静的解析の重要性、単体テストツールの需要が増すという変化が見られた時期でもあります。

各自動車部品の機能成熟に伴い、快適性や利便性がより強く求められるようになりました。

個々のECUが提供する機能だけでは限界があり、各ECUが持つ機能を組み合わせて新たな価値を生み出す方向へ向かっています。ある程度目的が似ている機能を持つECUをドメインとして統合し、直接ソフトウェアで連携を実現できる構図にした車両アーキテクチャがドメインアーキテクチャになります。

ドメインアーキテクチャでは、元々保有していたコアな機能をどのように連携させて実現するのかという点が重要であり、Automotive SPICE®におけるSYS.3（システムアーキテクチャ設計）、SWE.2（ソフトウェアアーキテクチャ設計）の重要性が増した時期でもあります。

品質活動としてもアーキテクチャ設計の十分な検証や、システムおよびソフトウェアの統合と、統合テストの確実な実施が重要になります。ドメイン内に存在する部品数が膨大になるとともに開発人員が増え、確実な統合のためにインテグレーションの自動化ニーズや変更管理、構成管理の重要性が高まったのもこの時期です。

自動車と外部とのコネクティビティの増加や、OTAによるソフトウェアアップデート、半導体技術の飛躍的な進歩を背景に、より中央集権型に変化したアーキテクチャがゾーンアーキテクチャとなります。

ゾーンアーキテクチャは、物理的にハード、メカ制御を行うために配置されるゾーンECUと、機能や外部との連携を組み合わせて実現されるサービスを制御するセントラルコンピューター（ECU）にて構成されます。

ゾーンECUが制御する物理対象との距離を短くすることにより車内の配線をシンプルにし、軽量化と保守性の向上を実現します。またサービスをセントラルコンピューターに集約することにより、サービス実現のための機能間連携を容易にすると共に、各ドメインでそれぞれが構築していた共通の仕組み（車両情報収集、ソフトウェアアップデート、起動終了制御など）を1つにまとめることができ開発効率の向上も期待されています。

ゾーンアーキテクチャではドメインアーキテクチャ同様にアーキテクチャ設計やその検証が重要になります。安全を確保するための機能間の連携や、サービスを実現するための機能間の連携はより複雑で直観的でなくなるため、設計の繋がりだけでなく整理された要求と設計のトレーサビリティがより重要になります。システムズエンジニアリングが注目される背景にはこうした理由があります。

自動運転やソフトウェア更新に代表されるように外部との接続を前提としたサービスが増加していくことを想定した車両アーキテクチャであるため、サイバーセキュリティの対象範囲が広がっていきます。ISO/SAE 21434では車両全体とその背後にあるサービスインフラを含めてリスク分析をすることが求められます。

車載ソフトウェアの全体像については、「車載ソフトウェア」のページをご覧ください。

SDV時代へ自動車業界が向かっていく目的の1つに、プラットフォーム共通化による根本的な開発費抑制があります。わかりやすく例えられるのが携帯電話業界におけるフィーチャーフォン（ガラケー）からスマートフォンへの変革です。

どの自動車でも基本的に提供すべき機能は変わらない中で、メーカーの違い、車両の違い、仕向け（販売エリア）の違いによって個別にモノづくりをしていては開発費が膨大になってしまいます。

スマートフォンと同じようにある程度共通化されたプラットフォームがあり、そのプラットフォームに付随する標準APIが提供する機能を使って、車両、仕向け、グレード、顧客の嗜好に合わせたサービスをアプリケーションとして提供する構図に変えることにより、サービスとしての魅力を下げずに開発費の抑制を狙っています。

この変革によって車載ソフトウェアの開発分類は今まで以上に明確に区別され、開発環境やプロセスもより差別化されたものとして精錬されていくことが予想されます。

【開発分類】

• UXサービス／アプリケーション開発車両APIを利用してユーザー体験価値を高めるサービスを開発します。サービス／アプリケーションの種類は様々で自動車の本来機能に関わるものだけでなく、利便性や嗜好性を高めるものも含まれます。これまで自動車とは無縁だった会社（サードパーティー）も参画可能になります。
• ビークルOS開発車両が持つ機能を車両APIとして提供する開発と、UXサービスやアプリケーションがビークルOS上で動作するためのサービスプラットフォームの開発です。

ビークルOSによって実機能が物理世界で実現されることを前提に、UXサービス／アプリケーションは車両APIをスタブ（テスト用の簡易的なダミー部品）とした仮想環境での開発が可能になり、短周期での開発が実現できるようになります。

モデルベース開発（MBSE／MBD）との親和性も高くなり、シミュレーションテストの自動化やデジタルツインの進展によって、従来は実車で行っていた検証の一部が仮想空間で実現可能となります。仮想空間での検証の割合は、今後さらに高まると予想されます。

要求および設計、テストの確実な紐づけと効率的な自動化を進めていくためには開発ツールの適切な利用が品質活動において不可欠な要素となっていきます。

また、利便性や嗜好性に特化していく領域の品質と、人命や財産に直接的に影響する侵害されてはいけない安全やセキュリティの品質とでは、求められる水準が明確に異なります。この違いをどのように隔離して確実かつ効率的に品質活動を実施していくのかが業界課題となります。

ビークルOSの登場によって車両の原理機能が標準化され、メーカー、車両、世代、仕向け、グレードのバリエーションはコンフィグレーションの切り替えによって動的に切り替えられる構図に変わっていきます。

そのためビークルOSが達成すべき非機能の品質特性（性能効率性、互換性、信頼性、セキュリティ、保守性）はより高く求められ、非機能の品質要求を具体化できる能力および、その証明能力の向上が重要となってきます。

• 性能効率性：車のグレードによらず、組み付けるハードウェアの性能を最大限に活かせるソフトウェア性能
• 互換性：OTAによる頻繁なビークルOSアップデートに耐えうる互換性
• 信頼性：組み付けられるハードウェアの違いがあっても適切に機能を提供できる信頼性
• セキュリティ：ビークルOSに対するサイバー攻撃への耐性と、攻撃を受けた際の対応能力
• 保守性：問題発生時の原因や影響範囲の特定能力と、標準部品に対する変更のしやすさの維持

機能適合性に関しては物理的な車両と組み合わせた中での品質活動を欠かすことはできないため、メーカーとビークルOS開発組織との間での品質活動における責務分担が今後の課題となってきます。

車両APIとビークルOSが整備されることにより、ビークルOSの上に搭載されるアプリケーションの開発プロセスが変化します。ビークルOSによってハードウェア制御も含めた車両APIが提供されるため、従来のようにシステムアーキテクチャ設計の階層からソフトウェア-ハードウェア分離の階層やハードウェア制御レベルのソフトウェア詳細設計が不要になるためです。

車両APIを使ってどのようにアプリケーションを実現するかを設計するだけで良いため、従来の多段階の階層構造を経由した開発が劇的に減ることになります。

また、OTAによるソフトウェアアップデートや、配信型のアプリケーションも主流となってきます。

こうした背景の中で、UXサービス／アプリケーションの開発はより早く新しい価値をユーザーに届け、継続的にアップデートを行うことが強く求められるようになります。

開発速度を高めるために仮想開発環境やツールが変化すること、およびその影響は前述していますが、それ以外の要素として開発モデルの変化があります。

本章では開発モデルの変化がもたらす品質活動への影響、および市場投入後の品質活動の変化について記載します。

OTAによる継続的な機能更新が前提となるSDV時代では、ウォーターフォール型（予測型）の開発モデルだけでは市場の変化に追従しきれません。反復型や漸進型、スクラムをはじめとするアジャイル型（Agile：適応型）を適切に選択する必要があります。

ただし、ウォーターフォール型とアジャイル型のどちらが適切かを断言できるようなプロジェクトはほぼありません。ウォーターフォール型やアジャイル型を基本型として捉え、開発する機能やサービスの特性、開発フェーズを考慮します。そのうえで、自らのプロジェクトではその型をどのように組み合わせて開発するのが最適なのかを、プロジェクト計画として設計することが重要です。

開発モデルの組み合わせ設計を行う際の悩みの種となるのが品質保証です。

仕様が固まり切らず変更開発を繰り返すことが多い車載の量産開発においては、品質ゲートを最終フェーズで通過させる運用（最終点検）が通例になっています。この最終点検によって品質を保証するというやり方を変えていかなければ、開発速度を高めることは難しくなります。

その対策として考えられたのが、品質を確認するタイミングを前工程へ寄せる考え方（シフトレフト）です。最終フェーズでまとめて品質ゲートを通す運用では、欠陥の検出が遅れ、設計まで戻る手戻りが大きくなります。この前工程での品質の作りこみと、短いフィードバックループの中で早期に欠陥を検出できる状態を作ることが、短周期開発における品質保証では必要になります。

そのため、次のような工夫が必要になります。

• 適応型や反復型などで小分けにした開発アイテム毎に担保すべき品質項目を事前に設計し、後回しにせずに品質を保証する
• 統合テストで変更開発における影響を確認できるようテスト設計を十分に行う
• CI/CDによって全項目再テストを実施する

変更開発における統合テストの影響範囲設計は、トレーサビリティを利用して実施するため、トレーサビリティの重要性は非常に高いものとなります。

次の図は従来とSDVにおける市場投入後の変更要因と、変更方法の比較です。

端的に言えば、SDVの時代においては市場投入後のソフトウェア変更が頻繁に行われるようになるということです。

従来の車載開発におけるリコール対応では、非常に厳格かつ慎重な品質保証プロセスが実施されてきました。OTA対応でも同等の品質保証を求められますが、それはリリースの迅速さと相反するため、両立が非常に困難な業界の課題となっています。

迅速さを求めるOTA対応の機能・サービス領域と、厳格に品質を担保すべき機能領域をシステムアーキテクチャやSDVプラットフォーム上で明確に分離して、各々の品質保証プロセスを定義して確立していくことが今後求められていきます。

本章では、ここまでの内容を3点に整理します。SDVによって品質活動の範囲と速度は変化するものの、品質保証の考え方そのものは変わりません。品質の作りこみ（QE）を尽くし、独立した立場でそれを証明する（QA）という原則は、SDV時代も変わらず有効です。この原則を、Automotive SPICE®を土台とした品質基準に沿って、変化したアーキテクチャ・開発分類・開発モデルへ反映していくことが求められます。

• 原則は変わらない：QEとQAの役割分担と、Automotive SPICE®を土台に安全・セキュリティ・AIの規格を重ねる構図は、SDVでも維持されます。
• 変わるのは
  • 対象と分担：ゾーンアーキテクチャではトレーサビリティとリスク分析の範囲が広がり、車両API／ビークルOSでは非機能品質と組織間の責務分担が論点になります。標準化された領域は業界の協調領域として共通化し、差がつく領域に品質活動の工数を配分する判断が必要になります。
  • 速度：ウォーターフォール型開発とアジャイル型開発を使い分け、迅速さを求める領域と、厳格に品質を担保すべき領域を分離した品質保証プロセスが必要です。また、シフトレフトとCI/CDで欠陥検出を前倒して、開発速度を高める取り組みを導入します。

SDVへの移行やコネクテッド技術の進化により、現在の自動車業界は、これまでの組み込みシステム（OT）の枠を超え、クラウド（IT）やサイバーセキュリティ、AIといった広範な技術領域を統合し、一気通貫で開発することが求められる局面を迎えています。富士ソフトは、こうした広範な技術領域にまたがる開発支援を担っています。

車載ソフトウェア（OT）×クラウド（IT）×AIを融合させた技術により、お客様のニーズに対してシステム一気通貫でのご提案をいたします。

当社は、「モビリティ社会の実現と普及に貢献」することをビジョンに掲げています。

当社は30年以上前から車載ソフトウェアベンダーとして、自動車業界における成長分野・先端技術分野の開発に貢献してきました。

全国6拠点・2,500名を超える技術者集団で、自社のみならず、お客様、アライアンスパートナー、業界団体との協業・共創による受託開発および自他社プロダクト事業を展開し、国内主要OEM・Tier1サプライヤーのお客様を筆頭に、国内100社以上のお客様とお取引をいただいています。

• 提案力：車載システム（OT）×クラウド（IT）×AIを融合させた技術により、システム一気通貫でのご提案をいたします。
• 案件対応力：先進技術の早期習得、確かで高度な技術力、幅広い技術範囲により、お客様の多様な案件にご対応いたします。
• 組織力：自動車開発の知見を有する2,500名を超える技術者集団としての対応体制と、Automotive SPICE®の社内アセスメントアセッサー、ISO 26262（2nd edition）のAFSP、ISO/SAE 21434のACSP-Cといった専門家を擁し、お客様のご要望にお応えしてまいります。

先行開発から量産向け開発、組み込みソフトウェア領域（下位レイヤーのドライバ、OS、アプリケーション）から、クラウドに至るまで、あらゆる領域において一気通貫でご対応します。

次世代車載ソフトウェア開発を支える当社の先端技術・開発プロセスへの取り組みを進めています。

富士ソフトは、こうした技術と体制による価値提供を通じて、お客様と共に安心・安全で心躍る未来を創り上げていきます。

※記載されている会社名および商品名は、各社の商標または登録商標です。