日経テクノロジーonline SPECIAL

ハートランド・データ ISO26262認証取得

ユーザが自社の活用事例を紹介

システム開発の現場でテスト業務に広く活用されている「DT10」は、もはや動的テストツールの代名詞的存在と言っても過言ではない。2016 年10月28日に東京都内で開催されたユーザ向けイベント「第5回DT10 活用セミナー」では、ユーザが自社の最新活用事例を紹介。それぞれのシステム開発で重要な役割を担っていることを感じさせた。

大規模な複合機の制御システムに適用 具体的なデータで修正の必要性を示す

 富士ゼロックスは複合機のコントローラソフトウエアのパフォーマンス改善に、DT10を活用した事例を紹介した。プリンタやコピー、スキャナやファクスなど複合機の各機能は、以前はそれぞれ別のソフトで提供していたが、機能の統合化をはかるためにソフトも統合を進めてきた。しかし、ネットワーク化やセキュリティ対応など、10年以上にわたる機能追加を通じてソフトが大規模化・複雑化するとともに、人の入れ替わりなどにより、システム全体の動きを把握することが難しくなってきたという。そこでパフォーマンス改善をはかるためにDT10を導入することにした。

 DT10は元のコードにテストのコードを埋め込むことでテストを行う。コンパイラによる自動埋め込みではないため、「アーキテクチャやOSに異存せず、実機やシミュレータ上でも測定できる点を評価した」と同プロジェクトのコントローラ開発本部コントローラプラットフォーム第2開発部の土樋祐希マネージャーは言う。

 またログは対象デバイスの外で取ることができるため、測定中に不具合が原因でハングアップした場合そこに至った経過を解析できる点も、同プロジェクトがDT10を選定した理由だ。

関数ごとに占有時間を計測し原因分析

[画像のクリックで拡大表示]

 DT10でパフォーマンス改善を果たした一つの例が、古いコードの高速化だ。新機種開発時にUIのパフォーマンスが急激に落ちたため、原因を特定することに取り組んだが、担当者が変わっていたり、古いコードでプログラムの構造が複雑であったりなどの理由から、原因の特定が難しかった。従来こうした問題にはprint文をコードの挿入するなどして原因を特定してきたが、挿入と再コンパイルを繰り返す必要があり、手間と時間がかかっていたという。

 DT10では関数ごとに占有時間を計測し、ランキングにすることが可能だ。その機能を活用し、土樋氏らはUIに関連するモジュールにDT10でテストポイントを埋め込み、処理を実行して分析。結果のレポートをもとにどの関数に時間がかかっているか、ムダなループなどで不要な関数呼び出しが行われていないかなどをチェックした。その結果、古いコードのアルゴリズムに問題が見つかり、その部分を改善することでパフォーマンス改善が実現できたという。

 同プロジェクトでは、オープンソース活用時のパフォーマンス改善にもDT10を利用した。新機能をオープンソースのコードを使って開発したものの、立ち上げ時の処理に想定以上の時間がかかるという問題に直面していた同プロジェクトでは、DT10で原因を分析することにした。

 オープンソースのコードにDT10のテストポイントを埋め込み、実行して占有時間のレポートを取得。それをもとに原因を探ると、想定外の処理がバックグラウンドで動いているために、処理が遅くなっていることが判明したという。「オープンソースの処理内容を全て調べきれるわけではない。

 活用する際にはDT10でパフォーマンスや動きを調べておく事で安心して活用できるようになる」と、テストを担当した同プロジェクトのコントローラ開発本部コントローラプラットフォーム第2開発部の筬島健太郎氏は指摘する。

 マルチコアCPUでのパフォーマンス調査にも、DT10は効果を発揮したという。モジュール単体ではパフォーマンスは仕様内で収まっていたものの、別のモジュールを同時に動作させると急に遅くなってしまう現象が起きていた。そこでDT10のプロセス占有率スコープ機能を使い、コア別にCPU使用率を調査した。

 同期待ちやリソース不足、競合など処理を遅くさせる事象が発生していないかを、コアごとのCPU使用率の変化をもとに調べたところ、対象のモジュールは別のモジュールを動作させた時、CPUによる処理の優先度が下がることが分かった。そこで優先度を調整するなどチューニングを行った結果、パフォーマンスを2倍以上に高めることができたという。

 筬島氏は「具体的なデータを示すことで、担当者に改善をお願いしやすくなった」とDT10の効果を評価する。「特に古いコードの修正の必要性を訴えるのに効果的だった」(筬島氏)。

 複合機のコントローラソフトは1000万行以上に及ぶ。その大規模なコードにDT10でテストポイントを埋め込むと、容量が肥大化してROMの容量を超過するだけでなく、再コンパイルの時間の増大という懸念もあったという。しかし同プロジェクトでは、テストポイントの挿入対象を関数単位に限定したほか、テストするパスを通るモジュールだけDT10に登録するなど、使用にあたって工夫を凝らしたとしている。

明電舎

 明電舎でパワーエレクトロニクス製品の開発を担当する井上稔也氏は、UPS(無停電電源装置)の開発にDT10を活用した事例を紹介した。一般的なデバッグ方法として、ブレークポイントでプログラムの動作を意図的に停止させ、挙動をチェックする方法があるが、UPS はインバータを常に制御させる必要があるため、制御プログラムを停止させることができない。同社はシリアル通信で内部変数を取得する自作のツールを活用していたが、トレースができないため再現試験を何度も繰り返す必要があった。

[画像のクリックで拡大表示]

 またインバータが意図した動作を行っているかをチェックするには、制御状態をマイクロ秒単位でサンプリングしなくてはならない。そこでアナログ出力して計測器で解析していたが、アナログのため演算結果を正確に確認することができなかったという。

 そこで同社ではDT10 を導入することにした。DT10 ではトレースした情報から処理の流れを可視化することができ、また機器内部のデジタルデータを高速でサンプリングできるからだ。

 DT10 をUPS の制御プログラムに適用するにあたり問題となるのがテストポイント挿入によるオーバーヘッドの影響だ。そこで同社ではFPGA で自作したドライバを活用した。ターゲットのCPU を、DT10 専用ハードのDynamicTracer とサンプルドライバでつなぐのではなく、間にFPGA で開発したドライバをはさみ、CPU からのテストポイント通過情報をFPGA のレジスタに書き込む。FPGA からはGPIO 接続用のフォーマットでDynamicTracerに出力する形だ。GPIO 接続のためにサンプルドライバで引数を出力するのに比べて、オーバーヘッドを大幅に削減できたという。

 GPIO 接続を活用するにあたって、井上氏はターゲットとDynamicTracer を結ぶ配線の延長を開発元のハートランド・データに要望したという。GPIO 接続専用として提供されているプローブは短く、大型のUPS と接続してテストしにくかったためだ。そのまま延長するとUPS からノイズを拾ってしまい、誤検出のもとになってしまう。

 ハートランド・データは、明電舎のケースは他のテストでも起こりうると考え、配線を延長するだけでなく、間にノイズをなくす絶縁回路をはさんだ。井上氏は「相談からわずか3 カ月で期待以上の試作品を作ってくれた」と迅速な対応を評価している。この試作品は現在、「GPIO-NoiseIsolator」として製品化済みだ。

岡山理科大学

 DT10 はISO26262 対応のAutomotiveEdition の登場により、自動車分野でも今後活用が広がることが予想されるが、既に活用されている事例もある。その事例を紹介したのが、岡山理科大学工学部電気電子システム学科で電気自動車のモータ制御用インバータを研究する笠展幸教授だ。

[画像のクリックで拡大表示]

 笠氏は、電気自動車のホイール内に実装できるモータの制御に取り組んでいる。4 つのホイールにそれぞれ搭載すれば、4 つのホイールを個別に制御できるようになり、クルマの複雑な動きが可能になるほか、重いドライブシャフトが不要になって軽量化も進み、デザインの自由度も高まるというメリットがある。

 インホイールのモータを実現するためには、それぞれのモータの位置角を検出し、速度演算やベクトル制御を行って、上位のマイコンから車両の制御情報を受け取って必要なトルク制御を行わなくてはならない。しかしその一連の制御を約100 マイクロ秒内で行う必要がある。それに対し車両ネットワークのCAN の通信周期は約10 ミリ秒であり、CAN ベースでは速度が追いつかずデバッグすることができない。また電気自動車のインバータは約300Vという高電圧で、通常のマイコンエミュレータではノイズのために検証が難しいという問題があった。

 そこで笠氏はDT10 を活用することにしたという。DT10 により位置角検出や速度演算などの割り込み処理を見える化し、「意図通りの順番で行われているかなどを確認することができた」(笠氏)。その結果、1 台目の電気自動車の完成に至ったのである。

 さらに2 台目の開発では、外乱にも強いトルク制御を目指すことにした。

インホイールモータは極数が多いため、高速で回転させると誘起電圧が高くなり、やがては電池の電圧を超えてしまって走行が乱れてしまう恐れがある。それを防ぐための制御系の開発に、DT10 を活用した。

 笠氏は弱め界磁を自動的に調整することで高速回転でも出力を一定に保つ制御方式を考え、そのモデルをDT10で検証。トルクが振れる現象を回避することができ、モータの出力テストにも合格して実車による公道試験が可能になったという。

 笠氏は「実験の過程ではハートランド・データにいろいろ支援してもらった」と話す。DT10 の機能とハートランド・データによるサポートが、インホイールモータ搭載の電気自動車をさらに実現に近づけたというわけだ。

DT10の動的テスト

DT10が組み込みシステム開発で幅広く使われている大きな理由の一つは、テスト手法の「いいとこどり」を実現している点にある。プログラムの内部構造を認識したうえで、ユーザが求める要件を見たしているか検証できるテストを実行する。内部構造に基づいたテストを行うため、テスト漏れを防げると同時に、パフォーマンスのようなユーザの感覚を左右する機能も検証できる点が、他のテストツールとの大きな違いだ。

DT10はソフトの構造からテストすべきポイントを見つけ、テスト用のコードを埋め込む
[画像のクリックで拡大表示]
カバレッジ計測でテスト未処理の部分を洗い出す
[画像のクリックで拡大表示]
関数ごとの実行時間を計測・表示し、パフォーマンス改善に必要なポイントを見極める
[画像のクリックで拡大表示]

 DT10 は、テスト対象のプログラムを実際に動かしながら検証する動的テストツール。コードを一つひとつ追いながら検証する静的テストと違い、実際に動かすことで、より効率的に不具合を見つけ出すことが可能になる。

 一般的なテスト手法は大きく分けて2 つある。プログラムの内部構造に基づいてテストを行うホワイトボックステストと、プログラムを外から見た動きでテストを行うブラックボックステストだ。

 ホワイトボックステストは、プログラム内で条件分岐やループなど指定した動きをさせる場面で、与えた値に応じた正しい動きをするかどうかをチェックする。値を変えながらすべてのパスを必ず一度は動作させて、意図したとおりの動きになるかを確認することで、プログラムの内容に間違いがないかを検証する。プログラムが動作しうる状態をすべて再現するため、プログラム全体に渡る網羅的なテストができる半面、開発するソフトの設計意図を開発者がもともと誤認していたような場合は、製品になるまで誤りが分からないということもありえる。

 一方、ブラックボックステストは、製品の設計意図からプログラムの内容をチェックする手法だ。プログラムの外から与えた値に対して、製品の仕様どおりの動作をするか確認する。プログラムの内部構造は問わず、ある意味“ 結果オーライ” でテストするものであり、製品としては機能が正しく実行できることを保証できる。しかしプログラムの中に余計なコードが含まれていたりしても、テストで気づくことはできない。そのコードは未チェックのまま世に出てしまうことになり、特殊な条件によっては、その未チェック部分のコードがプログラムの動作に影響を与える可能性もある。

 DT10 はその両者の長所を組み合わせたテストを可能にする。プログラムの内部構造に基づいた網羅的なテストを、実際にプログラムを動かしながら製品の観点から行うことができる。ホワイトボックステストとブラックボックステスト、両方の要素を持ったテストを行うことから、DT10 が行うテストは「グレーボックステスト」とも呼ばれる。

少ないテストでも大きな効果

 ただし網羅的に行うといっても、必ずしも全体を完全に網羅するわけではない。テストに掛けられる時間を考えるとそれは非現実的だ。かといってテスト対象をランダムにサンプリングするのでは、ソフトの品質保証はおぼつかない。開発者が経験や勘をもとにテスト対象を決めて、そこにブレークポイントを設定して値や動きを確認する方法もあるが、しょせん勘や経験頼みであり、不安は残る。

 DT10 は、プログラムの内部構造を解析したうえでテストすべきポイントを抽出し、そこを対象として動的テストを行う。構造的にテスト対象を決めてそこにテストのためのポイントを自動的に埋め込むため、少ないテストでも大きな効果を上げることができるわけだ。

 DT10 のテストは、ハードウエアに関連した部分も対象にできる。CPU 周辺のセンサやポートなどの状態を、プログラムの状態と同時に計測ができるため、プログラムの動作にともなってそれらハードがどのような状態に変化しているかが分かる。不具合の要素がプログラムによるものかハードによるものか、切り分けることが可能だ。

 通常のブラックボックステストでも、プログラム全体のどのくらいを網羅してテストしたかは、DT10 のカバレッジ計測機能で把握できる。実際、DT10 のユーザのうち、主な使用目的をカバレッジ計測とするユーザは43%にのぼる。カバレッジ計測目的だけでもDT10 は十分導入理由となっているようだ。

 DT10 のカバレッジ測定機能をユーザが重視しているのには、もう一つ理由がある。意図しない機能が存在しないか、洗い出すことができるからだ。カバレッジが十分でなかった場合の対応策として、テストされていない部分を重点的にレビューするという方法があるが、もともとDT10 はテストすべき点を構造解析により抽出しているため、テスト対象にならなかった時点で重要性は薄いと考えられる。そこにフォーカスしてレビューすれば、そもそもの必要性が疑われる可能性も十分あるはずだ。

 意図しない機能の存在を、コード全体を眺めて見つけ出すことは不可能に近い。意図しない機能を見つけて整理することは、プログラム容量の節約だけでなく、不具合発生のリスク低減にも効果がある。

動作のボトルネックを見つける

 DT10 のもう一つ大きな特徴は、パフォーマンスの改善にも活用できる点だ。プログラムを動かしながら、個々の関数の実行時間や周期時間、プロセスの占有率などを見える化することができる。プログラムのどの部分にどのくらいの時間がかかっているかが分かれば、パフォーマンス向上のために改善すべきボトルネックを見極めることが可能になる。

 プログラムの不具合解消に比べ、パフォーマンス改善は後回しになりがちだ。バグをつぶすことが優先されてほぼ完成した後では、動作速度を追求する余地は小さく、大きな向上は望みにくい。しかしDT10 を使うことで、不具合解消とパフォーマンス改善を同時並行で行うことが可能になる。不具合解消だけに目を奪われることなく、パフォーマンスも含めた製品のトータルでの完成度向上が実現するのである。

お問い合わせ