自動車ソフトウェアのCI/CD — Web開発とは異なる課題

自動車ソフトウェアにもCI/CDは必要なのか？

自動車ソフトウェア開発にCI/CDを適用しようとすると、一般的なWeb/アプリ開発とは異なる問題に直面します。Webサービスであればコードをコミットしてテストを実行してデプロイすれば終わりですが、自動車ソフトウェアはそれほど単純ではありません。

それでもCI/CDはもはや選択肢ではありません。1台の車両に搭載されるソフトウェアが数億行に達し、数十のECUが同時に開発される状況では、手動ビルドと手動テストではスケジュールに間に合いません。特にSDV（Software-Defined Vehicle）時代に入り、OTAアップデート、機能追加、セキュリティパッチが量産後も継続的に行われる必要があるため、自動化されたパイプラインなしでは持続的なソフトウェア運用自体が不可能です。

この記事では、自動車ソフトウェア開発にCI/CDを適用する際に実際に直面する課題と、その解決方法について説明します。

WebのCI/CDと何が違うのか

自動車ソフトウェアCI/CDを初めて構築しようとするチームが最もよく犯す間違いがあります。Web開発で使っていたJenkinsパイプラインをそのまま持ってきて適用しようとすることです。もちろん基本概念は同じです。コード変更 → ビルド → テスト → デプロイ。しかし各段階の複雑さがまったく異なります。

クロスコンパイルとターゲットの多様性

Webサービスは通常x86 Linuxサーバーにデプロイします。自動車は違います。ARMベースのECU、様々なRTOS、ハイパーバイザー上で動作するソフトウェアをクロスコンパイルする必要があります。ターゲットボードごとにビルド設定が異なり、BSP（Board Support Package）も異なります。CIサーバーでこれらすべての組み合わせを管理するだけでも相当なインフラが必要です。

テスト環境の違い

WebサービスのテストはDockerコンテナ1つ起動すれば済みます。自動車ソフトウェアは実際のECUなしではテストが難しく、実際のECUがあっても物理的な接続とネットワーク構成が必要です。HIL（Hardware-in-the-Loop）装置は高価で、共有リソースのためCIパイプラインで自由に使うことができません。

そのため、Virtual ECU（仮想ECU）ベースのSIL（Software-in-the-Loop）テストが重要になっています。CIパイプラインで仮想ECUを自動生成しテストを並列実行すれば、HIL装置がなくてもかなりの水準の検証が可能です。

ビルド時間

Webフロントエンドのビルドが2〜3分だとすると、AUTOSARベースのECUソフトウェアのフルビルドは30分から1時間以上かかることが珍しくありません。CIで毎コミットごとにフルビルドを実行するとパイプラインがボトルネックになります。インクリメンタルビルド、キャッシュ戦略、変更影響度分析に基づく選択的ビルドが必須です。

開発環境管理という隠れた難題

自動車ソフトウェアCI/CDで意外に多くの時間を消費するのが開発環境管理です。

ツールチェーンのバージョン同期

1つのプロジェクトにコンパイラ、AUTOSARスタック、コードジェネレーター、静的解析ツール、テストフレームワークなど数十のツールが必要です。これらのツールのバージョンが開発者PC、CIサーバー、チームメンバー間で異なると、「自分のPCではビルドできるのに」という問題が繰り返されます。

特にセキュリティパッチやツールアップグレードの同期が大きな課題です。あるチームがコンパイラをアップグレードすると別のチームのコードが壊れ、セキュリティ脆弱性が発見されて急いでパッチを当てる必要がある際に、すべての開発環境を一括で更新するのが困難です。

新規開発者のオンボーディング

新しいチームメンバーが参加すると、開発環境のセットアップに数日かかることが珍しくありません。AUTOSARツールのインストール、ライセンス設定、ビルド環境構成、ターゲットボードの接続まで。ドキュメントがあってもOSバージョンやライブラリの競合で試行錯誤が繰り返されます。

Dockerコンテナベースで開発環境を標準化すれば、この問題を大幅に軽減できます。開発環境全体をコンテナイメージで管理すれば、新規チームメンバーがイメージを取得するだけですぐに開発を開始でき、CIサーバーと同一の環境でローカル開発が可能です。

安全認証とCI/CD

自動車ソフトウェアCI/CDで最も難しい部分が安全認証との関係です。

ISO 26262ツール適格性

ISO 26262は安全ライフサイクルで使用されるすべてのツールに対してツール適格性（Tool Qualification）を要求します。CI/CDパイプラインで使用するビルドツール、静的解析ツール、テストフレームワークも例外ではありません。ツールが安全関連の出力を生成する場合、そのツールが正しく動作するという証拠が必要です。

これは単にツールを検証しろという話ではありません。CI/CDツール自体が適格性評価の対象となり得ますし、パイプライン構成が変更されるたびに影響度分析が必要になる場合があります。そのため安全関連プロジェクトでは、CI/CDパイプラインの変更管理がソフトウェアの変更管理と同様に重要です。

静的解析の自動化

MISRA C/C++準拠は自動車ソフトウェアで事実上必須です。CI/CDパイプラインに静的解析を統合すれば、コードがコミットされるたびにMISRAルール違反を自動検出できます。これにより、コードレビューでスタイルの問題をいちいち指摘する代わりに、レビューアーがロジックと設計に集中できます。

ただし、静的解析ツールの実行時間が長くなる場合があるため、変更されたファイルのみを分析するインクリメンタル分析と、全コードを分析するフル分析を分けて運用する戦略が実務的です。コミット時にはインクリメンタル分析を、ナイトリービルドではフル分析を実行する方式です。

認証プロセスのボトルネック

安全関連システムは広範な検証が必要です。自動化なしにこの検証を行うと、認証プロセス自体がプロジェクトのボトルネックになります。テスト実行、結果収集、レポート生成、トレーサビリティマトリクスの更新を手動で行うと、リリースごとに数週間かかります。

CI/CDパイプラインに検証自動化を統合すれば、毎ビルドごとにテスト結果とカバレッジレポートが自動生成され、認証に必要なエビデンスが蓄積されます。リリース時点で「あの時実行したテスト結果はどこにあるのか」ではなく、すべてのビルドの検証履歴がすでに記録されている状態になります。

ASPICE 4.0とDevOps

2023年11月にリリースされたASPICE 4.0は、自動車ソフトウェア開発方法論に大きな変化をもたらしました。3.1から4.0への移行に関する詳細はASPICE 4.0移行ガイドをご参照ください。従来のASPICEはV-Modelベースの逐次的開発プロセスを前提としていましたが、ASPICE 4.0はAgileとDevOps方法論を明示的に含むよう範囲が拡張されました。

これは単なるドキュメントの更新ではありません。OEM審査で「Agileで開発しているのにASPICE評価をどう受ければいいのか」と悩んでいたチームにとって、ASPICE 4.0はDevOpsベースの開発がASPICEと両立可能であるという公式的な根拠を提供します。

ただし、これは「CI/CDさえ構築すればASPICE 4.0対応は完了」という意味ではありません。ASPICEが要求するのはプロセスの体系的な実行とその証拠です。CI/CDはその証拠を自動生成・管理するツールであり、プロセス自体を代替するものではありません。

中央集中型HPCアーキテクチャとCI/CD

近年、自動車のE/Eアーキテクチャが分散型ECU構造から中央集中型HPC（High-Performance Computer）構造へと移行しています。数十のECUが担当していた機能を数台の高性能コンピューターに統合するのです。

この変化はCI/CDにも直接的な影響を及ぼします。HPC1台で動作するソフトウェアの規模が大きくなるにつれて、ビルドとテストの複雑度が比例して増加します。複数のドメイン（ADAS、インフォテインメント、ボディコントロール）のソフトウェアが1つのプラットフォーム上で統合される必要があるため、統合テストの重要性がさらに高まっています。

主要なクラウド/IT企業がSDV DevOpsツールチェーンのリファレンスアーキテクチャを提供し始めたのも、こうした変化に対応するための業界の動きの一つです。自動車ソフトウェア開発に特化したCI/CDインフラへの需要がそれだけ大きくなっているということです。

実務でCI/CDを始めるには

自動車ソフトウェアCI/CDは一度に完璧に構築するのは困難です。段階的にアプローチするのが現実的です。

ステップ1：ビルド自動化

手動ビルドの自動化から始めます。コードがコミットされると自動的にビルドが実行され、ビルド失敗時に担当者に通知が届くだけでも大きな改善です。

ステップ2：静的解析の統合

MISRA C/C++静的解析をCIパイプラインに追加します。コミットごとにインクリメンタル分析、ナイトリーでフル分析と分けて運用すれば実行時間の負担を軽減できます。

ステップ3：テスト自動化

ユニットテストからCIに統合し、段階的に統合テスト、SILテストへと拡張します。Virtual ECUを活用すればHIL装置がなくてもかなりの水準の自動化が可能です。

ステップ4：コンテナベースの環境標準化

開発環境をDockerコンテナで標準化し、ローカル開発とCI環境の一貫性を確保します。

ステップ5：認証エビデンスの自動化

テスト結果、カバレッジレポート、トレーサビリティマトリクスを自動生成して、ASPICE/ISO 26262認証対応を自動化します。

PopcornSARのCI/CDソリューション

PopcornSARは自動車ソフトウェア開発に特化したCI/CDツールとソリューションを提供しています。

PopcornSARはDockerコンテナベースの開発環境標準化をサポートしています。開発環境全体がコンテナで管理されるため、チーム全体の環境一貫性が保証され、新規開発者のオンボーディングが迅速化します。CI/CDパイプラインでVirtual ECUを自動生成し、複数の仮想ECUで並列テストを実行できるため、HIL装置への依存度を減らしながら検証範囲を広げることができます。

PARVISはAIベースの自動化でCI/CDパイプラインの各段階を強化します。PARVIS-CoderはMISRA C/C++準拠を自動化してCIの静的解析段階に統合されます。PARVIS-Verifyはテストケースを自動生成してCI/CDのテスト段階に投入します。要求仕様が変更されると、影響を受けるテストを自動的に識別してアップデートします。PARVIS製品ページで詳しくご覧いただけます。

AutoSAR.ioはARXML設定ファイルの構成管理をサポートし、CI/CDワークフローでAUTOSAR構成変更を体系的に管理できるようにします。

自動車ソフトウェアCI/CD構築についてさらに詳しく知りたい場合は、お問い合わせページからお気軽にご連絡ください。