日立オートモティブシステムズ株式会社様
運転支援カメラのファームウェアを動的解析、マルチコアへの移行に伴い検証力を強化
- 企業名：
- 日立オートモティブシステムズ株式会社
- 事業内容：
- 自動車部分品及び輸送用並びに産業用機械器具・システムの開発、製造、販売及びサービス
- 導入製品：
- 動的解析ツール「TRQerS」
- 適用目的：
- ファームウェアのタイミング検証、不具合解析
日立オートモティブシステムズ株式会社（以下、日立オートモティブシステムズ）は、車載機器や産業用機器などを開発・販売しているメーカー。2008年から衝突被害軽減ブレーキやクルーズコントロールを実現する車載用ステレオカメラをカーメーカーに出荷している。
そんな日立オートモティブシステムズは、ステレオカメラの次世代機種を独自開発するにあたって、動的テスト/解析ツール「TRQerS」を採用した。マルチコアプロセッサの導入に伴い、タスクの実行タイミングを迅速に検証できる環境が必要になったという。ここでは、ステレオカメラのファームウェア開発に動的解析手法を適用した経緯について、同社 パワートレイン＆電子事業部 電子設計本部 車載カメラ設計部の武藤 善之氏と樫村 力也氏に話を伺った。
日立オートモティブシステムズ株式会社 パワートレイン＆電子事業部 電子設計本部 車載カメラ設計部 主任技師 樫村 力也（かしむら・りきや）氏
2000年、日立製作所 オートモティブシステムグループ（現 日立オートモティブシステムズ）に入社。車間距離制御システム等の制御ソフトウェア開発に従事した後、2006年から車載用外界認識センサーの開発に従事しており、現在は、ステレオカメラのファームウェア設計開発の取り纏めをしている。
日立オートモティブシステムズ株式会社 パワートレイン＆電子事業部 電子設計本部 車載カメラ設計部 技師 武藤 善之（むとう・よしゆき）氏
2005年、日立製作所 オートモティブシステムグループ（現 日立オートモティブシステムズ）に入社。車載用外界認識センサーの開発に従事しており、現在はステレオカメラのファームウェア設計開発を担当している。
- 適用対象
- 次世代ステレオカメラにマルチコアを搭載
- ツールの選定
- マルチコア対応のプロファイラとして導入
- トラブルシューティング
- 半日から数日かかっていた問題が1回の実行で解決
- TRQerSの評価
- 可視化が開発者間のコミュニケーションを促進
適用対象
次世代ステレオカメラにマルチコアを搭載
日立オートモティブシステムズのステレオカメラは二つの画像センサーを備える小さな機器で、自動車のフロントガラス上部の中央（バックミラー付近）に設置して使用する。先行車両や歩行者、道路標識、道路上の白線などを検出したり、左カメラと右カメラの見え方の違い（視差）を利用して立体物までの距離を計測したりする。いわゆるADAS（Advanced Driver Assistance System：先進運転支援システム）の機能を包含したカメラ機器である。
車載用ステレオカメラは、まさに進化の途上にある電子機器である。同社ではこれまで、内部のソフトウェア処理をシングルコアのプロセッサ上で実行していた。これに対して、現在独自開発を進めている次世代機種では、マルチコアプロセッサ（複数のCPUコアを内蔵するプロセッサ）を採用する。
「次世代機種では、立体物の認識を高精度に行うことはもちろん、検出範囲内に進入してきた立体物を早期に認識しなければなりません。
これらを実現するためには演算処理が増えるので、ハードウェアの処理能力を引き上げる必要がありました。」（武藤氏。）
同社ではリアルタイムOSなどは使用せず、自社開発のファームウェア（デバイスドライバ）によってアプリケーションソフトウェアなどの実行タイミングを制御している。マルチコア対応のファームウェアを開発するにあたって、マルチコア上で実行するタスクの挙動や処理時間を迅速に把握する手段が必要になったという。
ツールの選定
マルチコア対応のプロファイラとして導入
ステレオカメラでは、フレームに同期した処理が基本となる。カメラからのデータの取得、画像の変換やフィルタリング、画像認識、車両制御情報の出力、といった一連の処理が、フレーム速度によって決まる規定の時間内に収まるようにソフトウェアを設計しなければならない。
加えてこれらのソフトウェアをマルチコアに実装する場合、コアをまたぐ割り込みやコア間のデータの受け渡しなど、従来とは異なるタイプの処理のタイミングも管理する必要がある。
「コア間の処理が、フレームに同期した既存の処理に対して悪影響を与えないようにしなければなりません。その確認をどのように行うか。検討の結果、タスクがどのようなタイミングで実行されているかを可視化できるTRQerSを採用することにしました」（武藤氏）。
日立オートモティブシステムズは、2015年11月ころからツール導入の検討を始め、2016年3〜4月に使用を開始した。
「もともと弊社の研究部門がステレオカメラの新しいプラットフォームを先行して検討しており、その担当者が事業部の私たちにTRQerSを紹介してくれました。評価用のツールを貸し出してもらい、どのように使えるかを確認した結果、これならいけそうだということで導入を決めました。弊社では以前からadvicePRO（横河ディジタルコンピュータのJTAG ICE）を利用しており、その流れもTRQerSの採用を後押ししました」（武藤氏）。
トラブルシューティング
半日から数日かかっていた問題が1回の実行で解決
日立オートモティブシステムズは、TRQerSを導入する以前は、タイミング検証を行うためにソースコード上に人手でデバッグ用コードを追加し、シリアルポート経由で実行履歴（ログ）を取得したり、評価ボードのRAM上に時間情報を残したりしていた。しかしこれらの方法では、最終製品に搭載するソースコードとは別のコードを用意してタイミングを検証することになる。元のコードにできるだけ手を入れないように、かつデバッグ用コードの追加に起因するオーバーヘッド（処理の遅延）に気をつかいながら検証作業を進める必要があった。
「以前は、タイマーの情報を見たり、時にはデバッグ用ボードに実装したLEDを点灯させながら、ディジタルオシロを使ってタイミングをチェックしたりしていました。これでは時間がかかりすぎます。さらにタイミングがより複雑になるマルチコアへの対応も必要になり、タスクの挙動を迅速に可視化する方法が求められていました」（樫村氏）。
こうした問題は、TRQerSの導入によって大幅に緩和された。まず、ユーザーがソースコードを人手で変更する必要がなくなった。また、TRQerSの場合もチェックポイント挿入によるオーバーヘッドは存在するが、それを小さく抑える工夫が施されているため、以前ほどオーバーヘッドの影響に神経質になる必要はなくなった。さらにタスクの挙動を、関数チャートやサマリーによって容易に把握できるようになった。
また、TRQerSは長時間のロギングに対応しており、ある程度長い時間実行しないと発生しないような現象の解析にも有効だったという。例えば、特定の条件下でしか発生しない多重割り込み処理などである。
「1時間に1回しか起こらない現象を、従来のやり方で検証するのは大変でした。微妙なタイミングの問題なので、何回か繰り返し実行しないと、必要な情報にたどり着けません。ここに不具合があった場合、問題の解決には短くて半日、長いと数日かかることもありました。TRQerSでは、現象さえ再現できればすぐに解決します。対策に半日から数日かかっていた問題を、1回の実行で解決できるようになりました」（武藤氏）。
TRQerSの評価
可視化が開発者間のコミュニケーションを促進
- まとめると、日立オートモティブシステムズの評価ポイントは以下の3点に集約できる。
- ● タスクの挙動を即座に可視化できる
- ● チェックポイント挿入のオーバーヘッドが小さい
- ● 長時間のロギングに対応している
今後への期待もある。同社では、TRQerSの活用が進むと、開発者の間のコミュニケーションが円滑になる可能性がある、と見ている。例えば開発の途中で、アプリケーションタスクを実行するコアを変更しなければならない状況があるかもしれない。タスクを実行するコアが変われば、タイミングががらりと変わり、アプリケーション性能も変わる。このとき、タスクの実行タイミングを管理するファームウェアの開発者とアプリケーションソフトウェアの開発者の間で調整が必要になる局面も出てくるだろう。
「TRQerSで可視化すれば、一目瞭然でタスクの挙動が分かります。調整が必要なときにアプリケーションソフトウェアの開発者に説明したり、説得したりするのに十分な情報が得られる、と考えています」（武藤氏）。
ただしTRQerSの機能について、同社に不満がないわけではない。例えば関数チャートなどの画面に表示する関数（タスク）をフィルタリングするとき、絞り込みの設定を保存する機能がない。そのため、例えばプロジェクトファイルを別のユーザーに渡したとき、あらためて同じ絞り込みの手順をたどらなければならない。また、ユーザーがチェックポイントの関数の引き数や戻り値を設定する際に、構造体やtypedefで宣言した型を設定できないという問題もある。同社では、コード品質の維持や移植性の観点から、社内ルールによりtypedefで型を統一するようにしている。
同社はこれらの項目の改善を、ツールの開発元（横河ディジタルコンピュータ）へ依頼した。その結果、typedefについては、最新版からint、char、longといった基本型に対応できるようになった（汎用コンパイラ版の場合）。それ以外の項目についても、引き続き改善を要望している。
また、TRQerSは関数カバレッジ（網羅率）を計測する機能を備えているが、2017年2月には、新たに命令（C0）、分岐（C1）、条件（C2）の各カバレッジ計測にも対応する計画がある。信頼性確保の観点から、日立オートモティブシステムズではこうしたTRQerSのテスト機能の拡充にも期待を寄せているという。
「弊社のステレオカメラは、ECU（Electronic Control Unit：電子制御ユニット）相当の機能を搭載しています。信頼性を保証するために、ソフトウェアテストをきちんと実施していく必要があります。機能安全の要求は当然として、今後はそれ以上の水準を見据えてテストに取り組まなければならない、と考えています」（武藤氏）。