株式会社沖データ様
“初めて”の不安をTRQerSで払拭、複合機ファームの性能チューニングに活用
- 企業名：
- 株式会社沖データ
- 事業内容：
- プリンタや複合機の開発・販売
- 導入製品：
- 動的解析ツール「TRQerS」
- 適用目的：
- ファームウェアの性能改善、再現性が低い不具合の初期解析
株式会社沖データ（以下、OKIデータ）は、プリンタや複合機を開発・販売しているメーカ。同社は、内部構造がシンプルで小型化しやすい、LED方式のプリンタを世界で初めて製品化した企業である。
そんな同社は2013年に初めて、複合機のタッチパネル・システムの内製とAndroidプラットフォームの導入に取り組んだ。ファームウェアの性能チューニング、および再現性が低い不具合の初期解析に動的テスト/解析ツール「TRQerS」を適用した。
ここでは、タッチパネル用ファームウェアの開発の経緯について、同社 商品事業本部 ソフトウェアセンターの佐潟 修氏に話を伺った。
株式会社沖データ 商品事業本部 ソフトウェアセンター ソフト設計第三部 佐潟 修（さがた・おさむ）氏
1992年、OKIに入社。1999年、OKIデータ研究所に配属。以降、ファームウェア開発、ファームウェア開発環境としてのシミュレータの開発などに携わる。現在はファームウェアのOSの選定、および開発環境の選定を担当している。
- 適用対象
- 二つの“初めて”、手探りしながらファームを開発
- ツールの選定
- 実行時のオーバーヘッドやサポート言語を評価
- トラブルシューティング
- Javaアプリからのライブラリの呼び出しがネックに
- TRQerSの評価
- トラブル対応の手段を確保、将来の保守効率化に期待
適用対象
二つの“初めて”、手探りしながらファームを開発
OKIデータは、複合機開発の内製化率を段階的に引き上げている。例えば複合機のスキャナ部分やタッチパネル部分について、かつては外部の協力企業に開発を委託してきた。これに対して2014年後半に発売した機種では、初めてタッチパネル・システム（液晶ディスプレイ、感圧タッチセンサ、プリント基板、ファームウェアなど）を自社開発した。ファームウェアについては、同社にとって初めてAndroidプラットフォームを採用した開発案件となった。
複合機は、ファームウェアのコード量が非常に多い機器である。タッチパネルの表示画面は数千ページに及ぶ。“初めての内製”、かつ“初めてのAndroid”。二つの“初めて”が重なるプロジェクトということで、開発者には大きな不安があった。
「OSが変わる、というのが一つのリスクでした。長らく私たちは、カーネルも含めてすべてのモジュールが一つに結合されて動いているリアルタイムOSの世界で製品を開発してきました。LinuxやAndroidのようにマルチプロセスで、自分たちのよく知らないプロセスが裏でたくさん走っている、という世界は初めてだったのです。『その中で何が起きるのか』、『何か起きたときにどうやって調べればいいのか』といった不安がありました」（佐潟氏）。
この不安は的中した。リファレンス基板による性能評価も含めて、入念な準備と技術的な検討を行ってから開発をスタートしたのだが、ある程度、作業が進んだところで、ファームウェアの性能が目標値に到達しないことが分かってきた。目標値との性能差は数十％。ファームウェア・コードに性能改善のためのチューニングを施す必要が出てきた。
ツールの選定
実行時のオーバーヘッドやサポート言語を評価
Androidプラットフォームには、性能解析（プロファイリング）を行うためのツールが用意されている。OKIデータは、複合機の製品開発を念頭に置いてそれらのツールを評価した。その結果、それらのツールは実行時のオーバーヘッドが大きく、処理コードの実行タイミングにずれ（遅延）が生じて、解析結果に影響を与えてしまう可能性がある、と同社は判断した。さらに、JavaとC/C++を個別に解析しなければならない、という問題もあった。これ以外にもいくつかのツールを併せて評価し、最終的に同社はTRQerSの「ソフトウェアモデル」を採用することにした。
TRQerSは、プログラムの中にチェックポイント（チェックコード）を埋め込み、プログラムの実行履歴を収集する、一種のトレース解析ツールである。チェックポイントの挿入やログ情報（トレース情報）の集計はツールが自動的に行う。TRQerSには二つの運用モデルがある。「ハードウェアモデル」では、プローブを介してトレース情報を基板から取り出し、外部の専用装置に蓄積する。一方、OKIデータが採用した「ソフトウェアモデル」では、トレース情報をユーザシステムのメモリ（ファイルシステム）上に記録する。ユーザシステムに専用装置を外付けする必要はない。
ツールを選定するにあたって、機能面の優劣は重要な項目だ。しかし、同社がTRQerSの採用を決めた理由は、それだけではないという。
「これまで私たちは、リアルタイムOSベンダが提供するなにがしかのツールを常に持っていました。何か困ったことがあれば、『まずは聞いちゃえ』という感覚でOSベンダのサポートを利用していました。しかしAndroidになると『ちょっと聞く』相手が周りにいません。何も持っていないことが不安になってきた、というのが正直なところです」（佐潟氏）。
何か起こったときに備えて問題解決の足がかりとなるつながりを持っておきたい。そのような思いから、同社はフリーのツールではなく、開発元によるサポートを期待できるTRQerSを選択した。
トラブルシューティング
Javaアプリからのライブラリの呼び出しがネックに
OKIデータは、性能解析を実施するにあたって同社が作成した全ソースに対してチェックポイントを挿入し、実行履歴を収集した。以下に、同社による解析結果の例を示す。
こうした解析結果から、JNI（Java Native Interface）を介して、JavaアプリケーションからC/C++ネイティブライブラリを呼び出すところのやり取りに、かなりの時間を取られていることが分かった。そこで、同社は呼び出し命令をコンパクトにまとめるチューニングを施すことにした。これにより、おおむね目標性能をクリアすることができた。
「C/C++ネイティブライブラリは、既存の（シングル・ファンクション）プリンタ用のモジュールをそのまま持ってきたものだったので、そもそも呼び出しの方法や呼び出し回数についてきちんと考慮されていませんでした。そこで、APIを変更できるところは変更し、その変更が難しいところについては、複数の呼び出しをひとまとめにしました。1回の呼び出しで複数の仕事をこなし、戻ってくる、という処理に変更しました」（佐潟氏）。
これとは別に、同社はプロジェクトの終盤（出荷直前、最悪の場合は出荷後）に見つかる、再現性の低い不具合の初期解析（原因究明の手がかりがまったくない段階の解析）にもTRQerSを適用した。上述の性能解析の場合と異なり、同社が作成した全ソースに加えて、OSやプロトコルスタックなどの階層にも浅く広くチェックポイントを埋め込み、テストを行った。
「それほど多くはないのですが、再現性の低い不具合が数件見つかりました。解決に一番手間取った数件です。例えばスリープ状態に入るところやスリープ状態から復帰するところ。ここは、複数の基板が歩調を合わせて動作する必要があり、トラブルが多い部分です」（佐潟氏）。
TRQerSの評価
トラブル対応の手段を確保、将来の保守効率化に期待
OKIデータでは、現在、一人の担当者がTRQerSを操作・運用しており、問題が起こったときに緊急出動する“トラブルシューティング用のツール”という位置づけで利用している。
「これまでの製品開発の中でそれなりに問題を解決してきているので、いつも性能の問題に悩まされているわけではありません。しかし、いざ問題が起こったときに対処するための手段を持っている、手ぶらではない、と言える点が、現時点におけるTRQerS導入の一番大きな意義です」（佐潟氏）
将来に対する期待もある。同社の佐潟氏は、動的解析の技術がファームウェア開発時の解析/テストだけでなく、製品出荷後の不具合解析やメンテナンス（保守）の効率化にも役立つ、と見ている。同社の複合機には、ログ出力やデバッグのための機能が組み込まれているが、製品出荷時にはこれらが機能しないように設定されている。そして、製品出荷後に不具合解析を行う必要が生じたとき、初めてこれらの機能が活性化され、ログ出力が可能となる。ただしこの場合、客先で発生した実際の不具合時の情報を取得することができない。発生条件を模索しながら、あらためて不具合状態を再現する作業が必要になる。一方、複合機の稼働中に、あたかもドライブレコーダのように実行履歴やデバッグのための情報を記録し続けることができるようになれば、状況は変わる。客先で発生した不具合時の情報をすくい取れる可能性が出てくる。不具合解析やメンテナンスの効率は格段に向上する。
「昔と比べると、複合機本体の制御基板のCPU性能に余裕が出てきています。ストレージも、ひと昔前は数MバイトのRAMとROMでどう動かすのか、というところで苦労していましたが、現在は数十GバイトのeMMC（Embedded Multi Media Card）を搭載しています。昔よりリソースに余裕があるので、（稼働中に取得した）ログやデバッグ情報を置いておくことは不可能ではないでしょう」（佐潟氏）。
複合機のファームウェアにあらかじめ組み込んでおく、ログやデバッグ情報を生成する仕掛け、および製品出荷後に行う不具合解析の環境として、TRQerSのソフトウェアモデルの技術を応用できる可能性があると、同氏は見ている。