動的テストツールの採用で組み込みソフトの処理性能計測工数を60％削減：ソフトウェアテスト

ハートランド・データの動的テストツール「DT+」のユーザーズカンファレンスにアズビルの加地孝敏氏が登壇。ビルディングオートメーション事業で展開する制御機器の組み込みソフトウェア開発における処理性能計測や不具合解析の事例を紹介した。

[PR／MONOist]

PR

　組み込み機器は、AI（人工知能）やIoT（モノのインターネット）などの機能を取り込みつつ進化を続けている。組み込み機器が複雑性を増し、一般的な静的解析ツールだけではプログラムの動作を十分に検証できなくなっている。

　複雑な挙動検証や不具合解析に役立つのがハートランド・データの動的テストツール「DT+」だ。2009年発売の「DT10」の機能を拡張する形で2020年にリリースされたDT+は採用実績を積み重ねており、シリーズ累計で1000社以上に利用されている。

　このDT+のユーザー事例が発表されたのが、2024年7月26日にリアルとオンラインのハイブリッドで開催された「DT+ユーザーズカンファレンス2024」だ。本稿では、アズビル ビルシステムカンパニー 開発本部 開発2部 係長の加地孝敏氏による「アズビルにおけるDT+使用事例紹介」の講演内容を紹介する。

制御機器や関連サービスを提供するazbilグループ

アズビル ビルシステムカンパニー 開発本部 開発2部 係長の加地孝敏氏

　azbilグループは、「人を中心としたオートメーション」の理念の下、計測と制御の技術で人や社会の安心、快適、達成感の実現や地球環境への貢献を目指している。事業の柱は

• オフィスビル、ホテル、ショッピングセンターなどを対象にしたビルディングオートメーション事業
• 工場や石油化学プラントを対象にしたアドバンスオートメーション事業
• ガス水道など生活に密着したライフオートメーション事業

の3つだ。

　加地氏は、ビルディングオートメーション事業において調節器コントローラー、センサーや計測機器、バルブや操作器、ユーザーズオペレーション機器などの組み込み製品を担当している。同氏が紹介したDT+の事例も組み込み機器を対象にしたものだ。

事例1：共通化アプリケーションの処理性能計測にDT+を活用

　加地氏はDT+の活用方法として2つの事例を紹介した。1つ目の事例が「処理性能計測」だ。

　同事業部は製品ごとにアプリケーションソフトウェアを開発するアプローチを採用してきた。この手法のメリットはソフトウェア性能やフットプリント（サイズ）を最適化しやすいことだ。だが、製品の種類が増えるにつれて開発コストの増大や開発期間の長期化を招くという課題があった。

　そこで、新製品群の開発ではソフトウェアの共通化と部品化を進めて製品に必要な機能を実現する方法を採用することにした。ハードウェアやOSの違いは抽象化レイヤーで吸収する。

　ただし、新たな課題も浮上した。「アプリケーションを共通化するアプローチによって開発投資や開発期間を抑えられるなどのメリットが得られる一方で、製品ごとに最適化が可能な従来の手法よりも処理性能が低下するという懸念がありました」（加地氏）

新製品群の開発では処理性能計測が必須に［クリックで拡大］ 提供：アズビル

　所定の処理性能が得られなければ、該当するソフトウェア部品の最適化や部品の分割などの対策が必要になる。そこで加地氏らは、新しいアーキテクチャで開発している製品群に対して定常処理や高負荷処理、異常処理などのさまざまなケースで実行周期や処理時間を計測することにした。

　同社が検討した処理性能の計測方法は4つある。1つ目はタイムスタンプをそのままコンソールに出力する方法。2つ目はタイムスタンプをいったんソフトウェア上のバッファにためてからコンソールに出力する方法。3つ目は使用していない汎用（はんよう）出力（GPO）ポートに信号を出力してオシロスコープなどで計測する方法。4つ目はDT+を使ってテストポイントを信号によって計測する方法だ。

　機器の準備や調達、ソースコードの修正、計測の時間分解能、計測点数、本来の処理への影響（オーバーヘッド）、過去の利用実績について机上で評価した。

処理性能の計測方法とそれぞれの比較［クリックで拡大］ 提供：アズビル

　最終的に、計測点数にほぼ制限がないこと、オーバーヘッドが極めて小さいと考えられることなどを評価して、DT+の採用を決めた。計測方法の比較においてDT+の「機器の準備」欄が△になっているのは、信号計測用のプローブボックスと接続するために信号の引き出しが必要という意味だ。

　実際の計測では、計測オーバーヘッドを最小化するためにDT+とプローブボックスを非同期バスモードで使用した。「コンソール出力では約1.7msのオーバーヘッドがかかりますが、DT+の非同期バス接続であればオーバーヘッドはわずか350nsと小さく、ほとんど無視できるレベルであることが分かりました」（加地氏）

　DT+を用いた計測では、テストポイントを挿入した2点間の実行時間や関数単位の実行時間を中心にトレースデータを収集した後、手動でグラフ化した。「DT+の画面を設計者に見せても理解しにくいところがあったので、性能的に課題になりそうなところを整理してから設計者に提示。ソフトウェアを修正した後に再計測して確認、といった作業を繰り返しました」

　「DT+は、設計チームとのやりとりの中で再計測する場合を含めてテストポイントをソースコードに自動的に挿入してくれるので、計測に要する工数をかなり削減できたと感じています。一度に多くの計測が可能であり、効率的に分析できました。体感的には、計測に要する工数を60％程度削減できたと考えています」

　品質面でも効果があったという。「許容時間を超える処理に対して機能分割などの対策を製品リリース前に実施できました。その結果、高負荷によって処理が回り切らない、といった障害は今のところ発生していません」

事例2：発生頻度が低い通信不具合の解析にDT+を活用

　続いて「不具合解析」にDT+を用いた事例を紹介した。

　解析の対象になった不具合は、アプリケーションから通信ドライバにメッセージの送信を要求したとき、ごくまれに通信ドライバからメッセージが送信されないことがあるという内容だ。それまでの解析で、通信ドライバはレスポンスの受信待ちで固まっていること、アプリケーションからの送信要求はリジェクトされていることなどが分かっていた。

アプリケーションから通信ドライバへの送信要求が処理されないという不具合が発生［クリックで拡大］ 提供：アズビル

　発生頻度が極めて低い場合、不具合の発生と同時に原因にたどり着けるのが理想だ。そこで、過去に不具合が発生した環境の他にエミュレータを接続したデバッグ環境とDT+を用いた環境を用意し、3つの環境を並行動作させて不具合の発生を待った。DT+環境では、アプリケーション内にある通信関連の全関数の入口と出口にテストポイントを挿入した。

　10週間後に実環境で不具合が発生したものの、エミュレータ環境とDT+環境では発生しなかった。このとき、不具合が発生した実環境の解析から発生箇所がある程度推測できたため、原因の候補であるアプリケーションの関数にDT+環境で1ステップごとにテストポイントを挿入し、再び不具合の発生を待った。

不具合の発生と絞り込みの手順［クリックで拡大］ 提供：アズビル

　その1週間後にDT+環境で不具合が発生した。DT+で取得したデータを解析すると、アプリケーションの特定ステップの処理中に通信ドライバへのディスパッチが発生したときにのみ、この現象が現れることが分かった。「『特定ステップの実行中にディスパッチが発生した場合』という極めてまれな条件を見つけるには、1ステップごとにテストポイントを挿入して解析する必要があります。しかし、テストポイントを通過したトレースデータをメモリのバッファにためる一般的な方法ではバッファ容量が厳しくなってしまいます。そう考えると、DT+を使用していなければ見つけられなかった可能性もあると思います」

　上記のディスパッチが発生してから通信ができなくなるまでに約30分の時間差があったため、DT+のトレースデータを30分以上さかのぼって解析する必要があった。「DT+であれば30分程度はまったく問題なくトレースデータを取得できるので、その意味でもDT+がなければ原因究明は難しかったでしょう」

DT+活用のまとめと今後の要望

　2つの活用事例について、加地氏は「DT+を処理性能計測と不具合解析に適用することで、開発工数の削減と品質の確保を実現できました」と総括する。

　特に、ソースコードを変更したときを含めてテストポイントの自動挿入が極めて効率的であったこと、非同期バス接続による計測オーバーヘッドが350ns程度と極めて小さいことを大きなメリットとして挙げた。

　一方で、DT+が取得するトレースデータは30分で約2GB、24時間では約96GBに達するなど膨大で、不具合調査ではテストポイントの絞り込みを含めていかにデータ量を抑えるかが今後の活用の課題になると述べた。「数千万ステップをCSVとして一括出力して確認するのは現実的ではないので、手動で50万ステップに分割して確認するなどの工夫をしました。データ量の削減やデータ分割の自動化などを今後のDT+のエンハンスでは期待しています」（加地氏）。DT+の画面に表示されるトレースデータはそのままでは理解しにくいため、他部署とも簡単に共有できるように分かりやすく見える化する機能も要望した。

　最後に今後の展望として、開発が一通り終わった段階での検証だけではなく開発プロセスや保守などにも広くDT+を活用していきたいとした。起動時のタスク処理順の確認やプログラムの動きを把握できるというDT+の特性を利用した教育目的での活用なども挙げた。