大規模化する車載ソフト、パナソニックは品質とセキュリティを確保できるのか：車載ソフトウェア（1/2 ページ）

日本シノプシスが主催するユーザーイベント「SNUG Japan 2018」に、パナソニック オートモーティブ＆インダストリアルシステムズ社 インフォテインメントシステム事業部 主任技師の古田健裕氏が登壇。「パナソニック オートモーティブ事業部門におけるソースコード品質向上の取り組み」と題して講演を行った。

[朴尚洙，MONOist]

　かつてはメカ部品の集合体だった自動車だが、1990年代以降加速度的に電子化が進んでいる。今では、ADAS（先進運転支援システム）や電動システムが広く搭載されるようになり、自動運転技術の実用化に向けた開発も進展している。

　自動車の電子化に合わせて、それらを制御するECU（電子制御ユニット）に組み込むソフトウェアの大規模化と複雑化も進んでいる。一般的にソフトウェアは、規模が大きくなればなるほどバグなどの不具合が発生しやすくなるが、ドライバーや歩行者の生死に直結する車載ソフトウェアのバグは、可能な限り低減しなければならない。大規模化への対応とソフトウェア品質の確保を同時並行で進めるためにはさまざまな施策が必要になる。

　では、カーオーディオとカーナビゲーションシステムの大手であるパナソニックでは、どのような施策を進めているのだろうか。日本シノプシスが主催するユーザーイベント「SNUG Japan 2018」（2018年6月13日）に、パナソニック オートモーティブ＆インダストリアルシステムズ社 インフォテインメントシステム事業部 主任技師の古田健裕氏が登壇。「パナソニック オートモーティブ事業部門におけるソースコード品質向上の取り組み」と題して講演を行った。

IVIのコード行数は2億行に

パナソニックの古田健裕氏

　古田氏はまず、パナソニックを取り巻く環境について説明。カーオーディオから、カーナビゲーションシステム、そしてIVI（車載情報機器）へと進化する中で、ソフトウェア規模も増大しているという。「ソースコードの行数（ステップ数）は2001年に100万行だったが、2018年には2億行に達する勢い。2009年ごろにネットワークとつながるようになって、さらに規模拡大の勢いが上がった」（同氏）。さらに、自動車向け機能安全規格であるISO 26262やサイバーセキュリティに対応することによる安心・安全の確保、LinuxなどOSS（オープンソースソフトウェア）の活用によるソフトウェアプラットフォームの共通化といった大きな変化も起こっている。

　パナソニックでの車載ソフトウェア品質関連の取り組みは2000年問題からになる。その後2001年から、ソフトウェア能力成熟度モデル（SW-CMM）やAutomotive SPICEを参照したプロセス改善活動を行いつつ、機能安全やサイバーセキュリティへの対応を進め、車載ソフトウェア技術者教育を体系的に実施してきた。ツールの活用では、車載ソフトウェアのコーディングガイドラインであるMISRA Cに対応するために静的解析ツールをいち早く導入し、チケット型の統合プロジェクト管理ツールなども採用している。2013年には、シノプシスの静的解析ツール「Coverity」を導入した。

　なお、サイバーセキュリティ関連へのプロセス対応では、早い時期から対応できているという。古田氏は「サイバーセキュリティ関連については、電機業界の方が先に問題が顕在化しており、その知見を機能安全やAutomotive SPICEに対応するプロセスに組み込んでいる」と語る。

「ソースコード品質向上」に向け静的解析ツールを活用

　古田氏が、現時点での課題と認識しているのは「ソースコード品質向上」と「セキュアコーディングへの対応」だ。さまざまな取り組みを進めてきたものの、規模拡大が続いている以上、車載ソフトウェアのソースコードの品質を向上する施策は常に必要だ。そして、コネクテッドカーとなってセキュリティ環境にも変化が起こっている中で、車載ソフトウェアのセキュアコーディングを効果的に行えるのか。これらの取り組みのベースになったツールがCoverityである。

　「ソースコード品質向上」では、ソースコード品質について、誤りのなさを示す「信頼性」、保守のしやすさを示す「保守性」、移植のしやすさを表す「移植性」といった特性に分けて検討したところ、信頼性を検証するツールが不足していた。「静的解析によるパターンマッチングやソースコードメトリクスの計測は保守性にひも付くことが多いが、信頼性との関係性は薄い。チェックリストに基づくソースコードレビューは、IVIのような大規模だと限界がある」（古田氏）。

　そこで検討したのが、Coverityのソースコードの意味論的解析（データフロー／制御バス解析）機能だ。ソフトウェア統合テストプロセス以降に検出される不具合を早期に検出することができる。例えば、約700人が開発に関わる、2億行に達するIVIの車載ソフトウェアでは約2万5000件もの指摘項目（不具合の可能性）を検出した。

　指摘項目が検出されることはいいとしても、その数が膨大では適切な対処が難しくなる。そこで行ったのが、指摘項目の解決を確実かつ効率的に実施するための仕組みやプロセスである「標準プロセスの定義」と、ソフトウェアコンポーネントの分類による対象範囲の決定、優先順位の決定と指摘対応状況の管理から成る「プロジェクトにおける運用の定義」である。

　標準プロセスの定義では、構成管理サーバやCoverityの管理インタフェース「Coverity Connect」、統合プロジェクト管理ツールなどから成る自動ビルド環境の構築と、コード検証運用手順の定義を行った。コード検証運用手順では、修正すべき「バグ」、欠陥ではなく意図通りの「意図的」、Coverityの誤検出と思われる「誤検出」に分類。分類に応じて進捗管理の対応を分ける。

　プロジェクトにおける運用の定義のうち、ソフトウェアコンポーネントの分類による対象範囲の決定では、まず自社や委託先を含めた内製コードと、OSSに分ける。内製コードは流用部分を含めて全てを検証対象とする。一方でOSSは対象外とする。「改変リスクはあるが、指摘項目はほとんどが『意図的』であり、修正するリスクの方が大きい」（古田氏）という。

　優先順位の決定と指摘対応状況の管理では、Coverityが示す影響度から層別して、リソースリークやメモリ関連など影響度の高いものから対応する。また、指摘対応状況を定期的に集計して、漸減できるようにする。

　先述したIVIの指摘項目のうち、バグが21％、意図的が36％、誤検知が7％、OSSが35％だった。これらのうちバグを修正することで、統合テスト後の修正工数を削減できた。「特に、多くのバグが潜在している影響度の高いものから対応することはすごく効果的だった。定量的には分からないが、統合テストでも検出できなかったバグもあるはずで、市場品質の向上にも大きく寄与できただろう」（古田氏）としている。