カシオ計算機株式会社様
実機を動かしながら人の耳でチェック、電子楽器の性能改善に動的解析は不可欠
- 企業名：
- カシオ計算機株式会社
- 事業内容：
- 時計、電子辞書、電卓、デジタルカメラ、電子楽器などの開発・販売
- 導入製品：
- 「adviceLUNA」システムマクロトレースモデル（現 TRQerS）
- 適用目的：
- ソフトウェアの性能改善、音を鳴らしながらの解析・デバッグ
カシオ計算機株式会社（以下、カシオ計算機）は、時計、電子辞書、電卓、デジタルカメラ、電子楽器、ハンディターミナルなどの機器を開発・販売しているメーカ。同社は、1980年に電子楽器の市場に参入し、現在はデジタルピアノやキーボード、シンセサイザー、DJコントローラー（デジタルダンスミュージックギア）を発売している。
そんな同社は、2010年からDTSインサイト（旧 横河ディジタルコンピュータ）の「システムマクロトレース」技術を活用して、デジタルピアノやキーボードに搭載するソフトウェアの動的解析を行っている。例えば性能改善のためのコードの最適化や、実機を動かしながらでないと検出できない不具合の解析に適用してきた。
ここでは、電子楽器に動的解析の技術を適用した経緯について、同社 羽村技術センター 楽器事業部 開発部 第一開発室の佐藤 淳氏に話を伺った。
カシオ計算機株式会社 羽村技術センター 楽器事業部 開発部 第一開発室 佐藤 淳（さとう・じゅん）氏
1988年度、カシオ計算機入社。以降、音色作成、音楽データ作成環境の構築、ファームウェア開発、ソフトウェア開発環境の構築などに従事。30年近く電子楽器の開発に携わっている。
- 適用対象
- 電子楽器は“リアルタイムシステム”
- ツールの選定
- 有効性を確認して即導入
- トラブルシューティング
- 体感的に解析時間が約1/10
- システムマクロトレースの評価
- 機能面には満足、カバレッジ計測も活用したい
適用対象
電子楽器は“リアルタイムシステム”
カシオ計算機は、35年以上にわたってさまざまな電子楽器を開発してきた。例えばデジタルピアノの処理は、おおよそ以下のようになる。
(1) あらかじめ実際の楽器の音をサンプリング（録音）して音源データを作成し、これをROMに記録しておく
(2) 鍵盤のキーには複数のスイッチが付いており、音の高さに加えて、それぞれのスイッチがON/OFFするタイミングのずれをもとにキーをたたいた強さを読み取る
(3) これらキースキャナが検出した演奏情報をもとに、CPUが音源に発音処理を指示し、音源が波形データをROMから読み出す
(4) 演奏の強さやピッチに応じた信号処理を音源が行い、和音などの複数チャンネル信号をミックスする
(5) このデータにリバーブやコーラスなどの音響効果を施しD-A変換を行い、アンプで増幅してスピーカを鳴らす
図1 デジタルピアノのシステム構成
鍵盤すべての音をサンプリングするとデータ量が膨大になるので、サンプリングするのは一部の区間の音に限っている。別の区間のキーがたたかれた場合は、音の高さ（ピッチ）をディジタル信号処理によって変換し、出力している。
「鍵盤をたたいたタイミングで遅延なく音を鳴らさなければならない、という意味では、デジタルピアノはリアルタイムシステムです。数msの遅延であれば許容されるケースもありますが、10ms遅延すると人間の耳には分かってしまいます」（佐藤氏）。
同社では、上述の処理を行う楽器専用の音源LSIを独自に開発している。最近のデジタルピアノは単に音を鳴らすだけでなく、曲データの再生や自動伴奏などの機能を備えている。音源LSIの上で動作するソフトウェアの規模は増大しており、デバッグが難しくなったり、プログラムコードの最適化が必要になったりしているという。
そこで同社は2010年ころから電子楽器のソフトウェア開発に動的解析手法を適用している。「adviceLUNA」システムマクロトレースモデル（現 TRQerS）を、デバッグやコードの最適化に活用している。システムマクロトレースとは、チェックポイント（C言語のprintf( )のような仕組み）を埋め込んだプログラムを実機上で実行しながら、関数やタスクが実行された時刻、および変数の値などを逐次記録していく技術である。得られた実行履歴（ログ）をチャートで表示し、統計処理することにより、プログラムの細かい挙動を把握することが可能となり、ソフトウェアの性能解析や不具合解析が容易になる。adviceLUNAのほか、TRQerSとTRQerAMにも同じ技術が使われている。
現在、同社はデジタルピアノ製品とキーボード製品のほとんどの機種の開発にシステムマクロトレースを適用しているという。
図2 システムマクロトレースを適用した製品の例
ツールの選定
有効性を確認して即導入
カシオ計算機の電子楽器の開発では、OSとファイルシステム、USB通信の部分をのぞき、デバイスドライバからアプリケーションソフトウェアまで、ほぼすべてのソフトウェアを自社で作成している。音源制御や自動伴奏などの処理が重くなり、さらに細かい機能が続々と追加された結果、2010年ころに同社のソフトウェア開発の現場は危機的状況に陥った。
「とにかくデバッグに役立つものなら何でも導入したい、と思いました。当時、電子楽器のソフトウェア規模の増大に私たちのデバッグ手法が追いついていませんでした」（佐藤氏）。
ちょうどそのころ、DTSインサイト（旧 横河ディジタルコンピュータ）が、システムマクロトレースの機能を搭載したadviceLUNA（現 TRQerS）の出荷を始めていた。カシオ計算機は実機デバッグと動的解析の両方を一つのツールで行える点に注目し、さっそく評価を開始した。そして実際に効果が見込めることを確認し、ただちに導入・運用を開始した。
「システムマクロトレースは、コードの最適化に絶大な効果を発揮しました。CPUの能力以上に処理が増えてきていたので、効率の良いコードに書き換えなければならなかったのですが、最適化するべき箇所を見つけるのにとても役立ちました」（佐藤氏）。
図3 動的解析の環境
トラブルシューティング
体感的に解析時間が約1/10
電子楽器の場合、ソフトウェア処理の負荷が大きくなると、自動伴奏のリズムが狂うなどの症状が出る。リズムが狂っているかどうかは、人間が耳で聞いて判断する。実際に音を鳴らしながらチェックする必要があるので、例えばブレークポイントを設定してプログラムの実行を止めるようなやり方ではデバッグできない。その意味で、実機上でプログラムを実行し、音を鳴らしながらデバッグ用の実行履歴を取得できる動的解析手法は、電子楽器の不具合解析や性能解析と相性が良かったようだ。
「システムマクロトレースを使わない場合、内蔵のメモリにログを吐き出す方法が考えられます。しかし、これだと吐き出せるデータ量に大きな制約があり、かなり細かいステップでしか解析できません。例えば1分間連続で解析に必要なログをとり続けることは難しいでしょう。あるいは1分間ログを取れたとしても、取得できる情報量は少なくなります。正確な比較は難しいのですが、体感的には解析に要する時間が1/10くらいになったのではないかと思います」（佐藤氏）。
システムマクロトレースを適用するにあたっては、音源LSI内部の回路設計に手を加える必要があった。音源LSIに専用の通信回路（システムマクロトレースのインターフェース論理）を組み込み、プローブ接続用のI/Oピンを用意した。
「ソフトウェアのデバッグ容易性に配慮してASIC（特定用途向けIC）の回路設計に手を加える」。これは、一見なんでもないことのように思えるが、実はかなりハードルの高い取り組みだ。ハードウェア設計者にとってはASICの機能検証の工数が増え、場合によってはチップコストに影響を与える可能性もある。さらに、ハードウェア部署とソフトウェア部署の間の細かい調整や緊密な連携が欠かせない。
「JTAGポートはもちろんありましたが、それ以外のデバッグ用ポートをASICに搭載したことは、それまでありませんでした。事前の試行でシステムマクロトレースの技術が有効であることが分かっていたので、ASIC開発の担当者にお願いして、なんとかプローブ接続用のI/Oピンを確保してもらいました。この交渉はとても大変でした」（佐藤氏）。
また、同社はシステムマクロトレースを有効活用するため、OSにも手を入れている。同社は以前からデジタルピアノ製品やキーボード製品のOSとして、ITRON仕様のオープンソースOSである「TOPPERS/JSPカーネル」や「TOPPERS/ASPカーネル」を採用している。同社は、TOPPERS OS内部のログ生成のコードに手を入れ、DTSインサイト（旧 横河ディジタルコンピュータ）が提供するシステムマクロトレース用APIを利用してOSのディスパッチ（タスク切り替え）などの履歴も併せて取れるようにしているという。
システムマクロトレースの評価
機能面には満足、カバレッジ計測にも活用したい
システムマクロトレースの動的解析に対するカシオ計算機の評価は高い。いまでは、システムマクロトレースなしにコードを最適化することなど考えられないという。
図4 カシオ計算機による解析結果の例
また、今後はデバッグやコードの最適化だけでなく、ソフトウェア開発の終盤に実施するシステムテスト（全体テスト）にも適用していくことを模索している。
「システムマクロトレースを使って、コードカバレッジ（網羅率）を取得できれば、全体テストを効率化できると考えています。もちろんすべてのコードを実行したからといって、すべての不具合を検出できるわけではありません。ですが、少なくとも1度も実行していないコードが残っている状態でテスト完了にはしたくありません」（佐藤氏）。
ソフトウェア開発工程の中で定常的にカバレッジ計測を行うためにはツールの台数を増やし、より多くのソフトウェア開発者に動的解析（動的テスト）の環境が行き渡るようにする必要がある。
「当社のリクエストとして、機能面については十分満足しているので、もうちょっとツールの価格が安くなってくれたら、もっと多くの台数を導入できるのに…、という思いがありますね。」（佐藤氏）。