要件が厳しく複雑な車載ソフトウェア開発、コストをどう低減するか：車載ソフトウェア

車載ソフトウェア開発は、安全性の担保やメンテナンス性確保のためのコーディング規約順守などさまざまな要件が課される。最近は自動運転システムの開発やOSS（オープンソースソフトウェア）の活用増加など、単にソース単体レベルでの対応を超えたところで配慮すべき内容が増えてきた。こうした状況に対応してテクマトリックスが新しく提案しているのが、車載ソフトウェア開発向けのツールチェーンともいえるソリューションである。

[PR／MONOist]

PR

　車載ソフトウェア開発は、安全性の担保やメンテナンス性確保のためのコーディング規約順守などさまざまな要件が課される。昨今では機能安全に対応するため、「コーディング規約の厳密化」「静的テストの実施」などが強く求められている。またコネクテッドカーが一般的になってきたことで、従来にも増してセキュリティ要件が厳しくなってきている。

　こうした車載向け開発の要件に合致したテストツールとして、テクマトリックスは以前から「C++test」などを提供している。ただ最近は自動運転システムの開発やOSS（オープンソースソフトウェア）の活用増加など、単にソース単体レベルでの対応を超えたところで配慮すべき内容が増えてきた。こうした状況に対応してテクマトリックスが新しく提案しているのが、車載ソフトウェア開発向けのツールチェーンともいえるソリューションである。

　このツールチェーンは、静的解析と単体テストを担う「C++test」、OSSライセンスとセキュリティの管理を行う「FOSSID」、バイナリ差分アップデートツール「RTPatch」、アーキテクチャ分析とソースコード解析をカバーする「LATTIX/Understand」、そしてテスト自動化基盤パッケージの「CloudBees Core」から構成されている。ここからは、それぞれのツールの特徴について詳しく見て行こう。

車載ソフトウェア開発向けソリューション 出典：テクマトリックス

コーディングやセキュリティのガイドラインへの対応に役立つ「C++test」

　C++testはC/C++言語に対する静的解析と単体テストツールであり、自動車業界で要求されるコーディングのガイドラインであるMISRA C/C++やAUTOSAR C++14コーディングガイドラインへの対応、セキュリティ標準であるCERT C/C++コーディングスタンダードへの対応など、ソフトウェアの要件を満たすために必要なツールである。そもそもMISRA C/C++などでは、ガイドラインの中で静的解析ツールの利用が前提となっていることもあり、既に広く利用されているツールでもある。

　C++testの最新版ではMISRA C:2012、CERT CにおけるRule項目に完全対応しており、次バージョンではAUTOSAR C++14におけるrequired（automated）に完全対応。全体で90%以上カバーする。またシステム開発の大規模化に伴い、独自のコーディングルールを定めている自動車メーカーでは、独自コーディングルールをC++testで作成し、ツールによる検証を実施しているケースも増えている。

テクマトリックス ソフトウェアエンジニアリング事業部 ソフトウェアエンジニアリング技術部 ソフトウェアエンジニアリング技術1課の藤澤克貴氏

　また、昨今の自動運転システムは、開発、ターゲットともにLinux上で行われることが一般的になりつつあるが、C++testは静的解析/動的解析ともにLinux上での稼働に対応している。自動運転システムの開発ではLinux環境上で車両のシミュレーションを稼働させ、その上でアプリケーションの稼働を確認するといったケースも見られるが、こうした環境でC++testを用いてアプリケーション稼働時のソースコードカバレッジを収集するといった用途でも使われる。

　自動運転システムの開発においては、オープンソースソフトウェア（OSS）が採用されることは珍しくなくなっている。ところがOSSは「無料で使える＝無条件で使える」のではなく、必ずOSSの利用許諾であるライセンスに従って利用しなければいけない。利用中のOSSを正しく把握せず、もし利用条件を守らず製品として販売した場合、訴訟や当該ソフトウェアの差し止め、企業ブランドイメージの低下など、さまざまなリスクを引き起こす。また、サプライチェーンの中で、OSSの一部だけをコピー＆ペーストしたコードスニペットが紛れ込み、ソフトウェアの中身が正しく把握できなくなることも大きなリスクだ。

OSSの部分利用も検出し、利用中のOSSを管理する

　そこで、プロジェクトの中でどんなOSS由来のソースコードが利用されているかを検出して管理するのがFOSSIDである。FOSSIDはソースコードをスキャンし、OSSを丸ごと利用するパターンだけでなく、OSSの一部だけを利用をしているコードスニペットの場合にも検出ができる。開発中に紛れ込んでしまったOSSや、サプライヤーからの納品物に意図せず含まれるOSSの検出に非常に有効だ。FOSSIDを導入することにより、ソフトウェアの中で利用されているOSSとライセンスを正しく把握し、管理していくことができる。

　FOSSIDはまた、セキュリティ問題の確認にも役に立つ。OSSには脆弱性が見つかることが多々ある。脆弱性を持つOSSをソフトウェアの中で利用している場合、FOSSIDはその脆弱性情報を表示する。OSSの脆弱性対策は、利用中OSSのバージョンを正しく把握し、脆弱性に早期に対応することが重要だ。FOSSIDのデータベースは最新のセキュリティ情報を入手するため、NVD（National Vulnerability Database：米国立標準技術研究所（NIST）の脆弱性情報データベース）の情報を毎日1回アップデートしている。この迅速さも大きな特徴であり、早急な対策が求められるOSSのセキュリティ問題について有効な手だてになる。

　当然、こうしたソフトウェア内で利用中のOSS情報は、SPDX（Software Package Data Exchange）やHTML形式に出力可能だ。

メンテナンスフェーズにもともとの開発者が携われなくても

　車載ソフトウェア開発が終了するとデプロイを行うが、それが1回だけで済むことはない。例えばナビゲーションシステムなら定期的に地図データの更新があるし、インフォテインメントシステムなら機能追加や周辺機器対応などが考えられる。ECU（電子制御ユニット）でもアップデートが発生する。こうしたアップデートは、定期点検や車検の際にディーラーで行うのが一般的ではあるが、他にリコールでの緊急対処も想定される。

　ここで問題になるのが、配布するファームウェアやソフトウェア、データ類の最終的なバイナリの大きさである。ディーラーなどでは専用の機器を用いて30分〜1時間近くをバイナリ転送に費やすことも珍しくない。今後は通信回線を用いたOTA（Over The Air）のサービスが提供されるが、ここでもやはりバイナリの大きさが転送時間という形で問題になる。そこで、既存のバイナリと新規のバイナリの差分を取り、その差分だけを転送する形で、転送すべきバイナリを最小限に抑えるためのツールがRTPatchである。RTPatchはさまざまなプラットフォームで利用可能なトランスポータブルな構成で、最終的に搭載されるECUや機器のメモリ容量に65KBほどの空きがあればアップデートが可能となる。また、バイナリ差分のみを転送することにより、情報窃盗のセキュリティリスクが低減されるというメリットもある。

　実は開発の過程においても、この転送サイズの最小化という機能は、特にテストなどで煩雑にアップロードとテストを繰り返す際に効果的である。より迅速にテストを繰り返せることで、開発期間の短縮効果が期待できることになる。

　さて、サプライヤーは自動車メーカーにシステムを納入してしまえば開発が終わりになるかというと、そんなことはない。例えば、FOSSIDで新たなセキュリティの問題がレポートされたら、その対策を行って新しいバイナリを作成、RTPatchでサイズを削減しつつクルマに転送してアップデート、という作業は、その車両のサポート期間が続く限り発生する。問題は、こうしたメンテナンスフェーズにおいて、もともとの開発者や開発会社が必ずしも携わるとは限らないことである。この結果として、元のコードを眺めても、何がどうなっているのか分からなかったり、そもそもコードのロジックが意味不明だったりといった事態がしばしば起こり得る。こうした状況で元のコードを解析して修正する作業には、少なからぬ労力と時間が必要になる。

　本来であれば大規模なリファクタリングを行うことでコードを整理するとともに問題箇所を訂正すべきところだが、そうしたコストも開発人員も割けないケースは珍しくない。こうしたシチュエーションで助けとなるのが、LATTIX/Understandである。LATTIXは、マトリックスを使った可視化・分析手法であるDSM（Dependency Structure Matrix）の技法を利用し、アプリケーションあるいはデータベースの構成要素の関係性をマトリックス形式で表示してくれるツールで、要素間の依存関係やコード修正を行った場合の影響範囲の確認といったアーキテクチャ解析のサポートに加え、循環参照モジュールや階層構造の崩れなど、既にあるアプリケーションの問題点の把握を容易にする助けとなる。

　一方のUnderstandは、プログラミングの現場においてソースコードレベルでの解析を行い、フロー制御や構造、クラス継承、関数や変数の呼び出し関係などをグラフィカルに可視化できるツールだ。修正に携わるエンジニアの負荷を減らすとともに、修正の確実性の引き上げも可能にしてくれる。これらを利用することで、リリース後のメンテナンスに掛かる労力や時間を削減するのは、長期に渡る車載向けシステムの保守コスト削減、更に言えば既存のコードをメンテナンス可能にすることで、そのソフトウェアそのものの劣化を最小限に抑えるという観点からも重要といえる。

Jenkinsのメリットはそのまま、運用しやすく

テクマトリックス ソフトウェアエンジニアリング事業部 ソフトウェアエンジニアリング技術部 ソフトウェアエンジニアリング技術4課の酒井利治氏

　さて、これらのツールはもちろん単独で利用することもできる。しかしながら、複数のツールを連携させて自動的に処理を行わせることで、作業負荷の軽減が図れ、定められた基準に合格したソフトウェアのみが製品としてリリースされるという体制を構築できる。例えば、ソースコードのチェックインをきっかけにC++test、Lattix、Understand、FOSSIDを順番に実行し、実行完了次第その結果を開発者にレポートするといった一連の流れを自動化することが可能だ。これは特に開発者の数が増えつつある昨今の車載向けシステム開発では、重要なポイントである。

　こうした自動化ツールとしてJenkinsが広く知られている。JenkinsそのものはOSSで提供されており、これを利用している開発者は少なくない。その一方で、OSSであるがゆえに、Jenkinsをスムーズに稼働できる様にするまでの環境構築は誰でもできるわけではなく、製品を開発すべき開発者が独力でJenkinsを管理しているという問題もある。またさまざまなプラグインが利用できるというJenkinsのメリットが、逆にプラグイン同士の干渉やバージョンミスマッチによる障害といった運用の苦労を引き起こしているのも事実だ。

　CloudBees Coreは、Jenkinsのメリットをそのまま享受しつつ、初期設定や運用コストの削減を可能とするソリューションである。特に社内で複数のチームが別々に開発している場合に、全てのチームが車載ソフトウェアの開発プロセスに確実に準拠した自動化環境を構築することは、多数のチームにとって製品開発とは別の大きな負担だ。こうしたケースでCloudBees Coreを利用することで、環境構築の手間とコストを大幅に削減できる。

　またプラグインに関しては、あらかじめ組み合わせ動作を含めて検証済のプラグインが提供されており、プラグインに起因する運用トラブルを最小限に抑えられる。Jenkinsを利用することでCI（継続的インテグレーション）/CD（継続的デリバリー）の環境を容易に構築できるが、そのためにはJenkins自身が継続的に利用できなければ意味がない。これを担保してくれるのがCloudBees Coreというわけだ。

　テクマトリックスは他にも多数の開発環境向けソリューションを提供しているが、今回ご紹介した6製品は、同社が提供するソリューションの中から、まさに車載ソフトウェア開発に適したものをよりすぐったもの、と考えて頂ければ良いだろう。

テクマトリックス ソフトウェアエンジニアリング事業部メンバー