(57)【要約】【課題】  組込みシステムを使用するユーザが、対象となる組込みシステムのどの部分を不満に思っているか、設計・開発者が把握しきれないという課題がある。【解決手段】  本発明では、該当する組込みシステムに様々なセンサを取りつけ、それらの情報を元に、ユーザが不満に思った際の様々なアクションを検出する。左記検出結果をトリガーにし、そのアクションを取ったタイミングにおけるシステムの挙動情報を、設計・開発者がアクセス出来る開発環境に送信する。設計・開発者は、任意のタイミングで上記挙動情報を任意の設計ツールから読み込む。設計ツールは、挙動情報で示された不満が、設計上の何処に対応するかを引当てる。最後に、その結果を画面上に表示し、設計・開発者にシステムのどの部分に問題があるのかを明示する。【選択図】図１
2014041390.tif 000002
【特許請求の範囲】
【請求項１】
組込みシステムの設計・開発支援システムであって、出荷後の組込みシステムの使用中に、ユーザが処理に不満を思う挙動を示した際に、ユーザの動向を各種センサの情報から検知し、検知したタイミングでシステムの挙動情報を収集、ホスト環境に通知、ホスト環境上の記録装置に記録し、設計・開発者が任意のタイミングで、ユーザが不満を示した際に動作していた機能の情報を、ホスト環境の設計・開発ツール上に表示することを特徴とする設計・開発支援システム。
【請求項２】
請求項１に記載の設計・開発支援システムにおいて、幾つかのセンサ群から入力された情報を元に、ユーザが実施中の機能に対し、不満を持っているか否かを自動識別し、設計・開発者にフィードバックすることを特徴とする設計・開発支援システム。
【請求項３】
請求項１、２に記載の設計・開発支援システムにおいて、センサ群から入力された情報が異常と判定されなかった場合の情報を元に自動で追加学習をすることで、ユーザの特性に合わせ、高い識別精度でユーザの不満を検出することを特徴とする設計・開発支援システム。
【請求項４】
請求項１、２又は３のいずれかに記載の設計・開発支援システムにおいて、ネットワーク的に独立した環境においても、記録媒体を経由することで、ユーザの不満を設計・開発者にフィードバックできることを特徴とする設計・開発支援システム。
【請求項５】
請求項１、２又は３のいずれかに記載の設計・開発支援システムにおいて、単一の筺体で実現することを特徴とする設計・開発支援システム。
【請求項６】
請求項１に記載の設計・開発支援システムにおいて、ユーザの不満を直接設計・開発者に送信することが出来る機能を備え、不満を持った際に直接設計・開発者に情報を送信することを特徴とする設計・開発支援システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、組込みシステムの設計・開発支援システムに関する。
【背景技術】
【０００２】
従来、組込みシステムの操作感（ユーザビリティ）を改善すること難しかった。理由は、使用者の主観に依存する部分があり、設計・開発者や商品企画者ら（以下、「設計・開発者」という）が顧客の不満に関する情報を、完全に収集出来ない点にある。その様なユーザビリティの向上については、これまでに幾つかの発明がされている。そもそも不満を収集する以前に、ソフトウェアの障害が発生した際に、障害情報を採取し、その情報を別の装置に対して送信したり、外部から参照したりする方法が検討されている。特許文献１では障害発生時のログ収集をするシステムにおいて、複数のログ記録先がある場合に、記録のズレなく記録を実施し、複数の記録先に外部から情報を参照出来るインタフェースを備えることで、該ログ記録機能のどれかに障害が発生しても、情報を収集可能とする技術を提案している。次に、ユーザビリティの改善については、特許文献２に示す様に、ユーザの操作内容を収集し、正しい操作方法と比較することで、操作性を悪くしている設計要素を絞り込むユーザビリティ改善システムが提案されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平９−２５９０１３号公報
【特許文献２】特開２００４−２８７７１６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記従来技術では、障害が発生することや、操作方法に間違いがある等の、明確な契機なり、設計・開発者が想定出来る条件時の情報しか収集出来ない。しかし、ユーザビリティは使用者の主観に依存する部分があり、設計・開発者が意図しない点で、該組込みシステムユーザが不満を抱いていることも考えられる。
従って、組込みシステムを使用するユーザが、対象となる組込みシステムのどの部分を不満に思っているかを設計・開発者が把握することは一般に困難であり、設計・開発者や、一部の声高なユーザの主観に依存しない、使いやすいシステムを提供することは難しいという課題がある。
【課題を解決するための手段】
【０００５】
本発明では、該当する組込みシステムに様々なセンサを取りつけ、それらの情報を元に、ユーザが不満に思った際の様々なアクションを検出する。左記検出結果をトリガーにし、そのアクションを取ったタイミングにおけるシステムの挙動情報を、設計・開発者らがアクセス出来る開発環境に送信する。設計・開発者は、任意のタイミングで上記挙動情報を任意の設計ツールから読み込む。設計ツールは、挙動情報で示された不満が、設計上の何処に対応するかを引当てる。最後に、その結果を画面上に表示し、設計・開発者にシステムのどの部分に問題があるのかを明示することで、ユーザが組込みシステムの何処に不満を持っているかを明らかにする。
【０００６】
本発明の特徴は、（１）組込みシステムの設計・開発支援システムであって、出荷後の組込みシステムの使用中に、ユーザが処理に不満を思う挙動を示した際に、ユーザの動向を各種センサの情報から検知し、検知したタイミングでシステムの挙動情報を収集、ホスト環境に通知、ホスト環境上の記録装置に記録し、設計・開発者が任意のタイミングで、ユーザが不満を示した際に動作していた機能の情報を、ホスト環境の設計・開発ツール上に表示することにある。
【０００７】
（２）（１）において、幾つかのセンサ群から入力された情報を元に、ユーザが実施中の機能に対し、不満を持っているか否かを自動識別し、設計・開発者にフィードバックすることが望ましい。
【０００８】
（３）（１）、（２）において、センサ群から入力された情報が異常と判定されなかった場合の情報を元に自動で追加学習をすることで、ユーザの特性に合わせ、高い識別精度でユーザの不満を検出することもできる。
【０００９】
（４）（１）、（２）または（３）において、ネットワーク的に独立した環境においても、記録媒体を経由することで、ユーザの不満を設計・開発者にフィードバックすることもできる。
【００１０】
（５）（１）、（２）または（３）において、単一の筺体で実現することができる。
【００１１】
（６）（１）において、ユーザの不満を直接設計・開発者に送信することが出来る機能を備え、不満を持った際に直接設計・開発者に情報を送信しても良い。
【発明の効果】
【００１２】
本発明により、多くのユーザが潜在的に不満に感じていた箇所と、設計上の位置情報の対応付けが可能となる。それにより、設計・開発者や、一部の声高なユーザの主観に依存しない、使いやすいシステムを提供することが可能になる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施形態の全体構成の一例を示す図。
【図２】システムの挙動情報を保存する際のデータ構造の一例を示す図。
【図３】異常検出装置００５の一例を示す図。
【図４】異常検出処理の処理シーケンスの一例を示す図。
【図５】ユーザの異常行動を学習する処理シーケンスの一例を示す図。
【図６】本発明を実施する上で、通常の組込みシステムの設計・開発ツールの拡張に必要な機能の一例を示す図。
【図７】解析情報のデータ構造の一例を示す図。
【図８】挙動情報収集結果を、設計・開発ツールに反映するための処理の一例を示す図。
【発明を実施するための形態】
【実施例１】
【００１４】
まず、本発明の第一の実施形態を説明する。
【００１５】
図１は、本発明による機能改善システムの一例の説明図である。本発明による機能改善システムは、機能の改善対象であるターゲットシステム１と、改善対象のターゲットシステムの設計・開発を実施するホスト環境２からなる。
【００１６】
ターゲットシステム１は、ターゲットシステムの挙動情報を記録するためのバッファメモリ００１と、システムの制御や、ターゲットシステムの様々な機能を提供し、本機能改善システムによって改善される対象となる調査対象プログラム００２と、調査対象プログラム００２の挙動情報を収集し、バッファメモリ００１に記録するトレーサ００３、プロファイラ００４と、ユーザの不満をセンシングし、ユーザが普段の振る舞いと異なる異常を検出し、異常と判断したタイミングで、トレーサ００３や、プロファイラ００４が、バッファメモリ００１に記録した調査対象プログラム００２の挙動情報を、それらトレーサ００３、プロファイラ００４経由で収集し、ホスト環境２に送信するために、通信モジュール００６に引き渡す異常検出装置００５と、異常検出装置００５から取得した上記挙動情報を、ホスト環境２の通信モジュール０１１に対し送信、また、ホスト環境で作成されたトレーサ０１２を受信し、トレーサ００３を更新する通信モジュール００６と、異常検出時に使用する学習結果を保存しておく記録装置００７からなる。
【００１７】
ホスト環境２は、ターゲットシステムの調査対象プログラムを設計・開発する際に使用する設計・開発ツール００８と、記録装置０１０に記録された、調査対象プログラム００２の挙動情報を、同じく記録装置０１０に記録された、挙動情報と、設計・開発情報を用いて、設計・開発ツールの、該当機能情報に重ね合わせて表示するための、データ解析機能００９と、調査対象プログラム００２の挙動情報や、設計・開発ツール００８を用いて、調査対象プログラム００２の設計・開発をした際に生成される設計・開発情報を記録する記録装置０１０と、ターゲットシステム１の通信モジュール００６と、通信を実施し、調査対象プログラム００２の挙動情報の取得や、新規に作成された、調査対象プログラムのトレーサ０１２を送信するための通信モジュール０１１と、調査対象プログラム００２の解析を進める上で、トレース対象を変更するために新規に作成、若しくは記録箇所を更新したトレーサ０１２からなる。
【００１８】
バッファメモリのデータ構造：
図２は、トレーサ００３や、プロファイラ００４が収集するシステムの挙動情報を一時的または恒久的に保存するための、バッファメモリ００１のデータ構造の一例を示す図である。バッファメモリは、ターゲットシステム１に含まれるトレーサ００３や、プロファイラ００４等の挙動情報収集機能の取得情報の内容に従う。図２は、トレーサ００３についてのバッファメモリのデータ構造の一例であり、シーケンス番号（００１−００１）、イベント名称（００１−００２）、時刻（００１−００３）、内容１（００１−００４）、内容２（００１−００５）等の属性を持つ。シーケンス番号（００１−００１）は、トレーサが取得したイベント情報のシーケンス番号である。リソースが有限な場合は、定められた閾値を境にラップアラウンドする。イベント名称（００１−００２）は、取得するイベントの名称である。例えば、プロセスの切り替えや、割り込み、メモリ確保・解放やタイマ起動等の内容が記録される。ここではアプリケーション固有のイベント名称は書かなかったが、その様な内容が記録されても構わない。開発する対象がデジタルテレビの場合は、一例として、チャンネル切り替え、音量調整等が挙げられる。時刻（００１−００３）は、イベント名称（００１−００２）が発生した時刻である。内容１（００１−００４），内容２（００１−００５）．．等の内容は、イベント名称（００１−００２）を解析する際に必要な補助情報が記録される。一例を挙げると、シーケンス番号１のプロセス切り替えというイベントでは、プロセス切り替えが起こったということだけがわかるよりも、それに付随し、どのプロセスから、どのプロセスへプロセス切り替えが発生したかということが判る方が、システムの挙動を正確に把握可能である。その様な、イベント名称だけでは不足する挙動解析を支援する補足情報である。プロファイラ００４についても、同様にプロファイリングした情報が記録されるが、ここでは省略する。
【００１９】
異常検出装置の例：
次に、図１のターゲットシステム１に示した異常検出装置００５の詳細について、図３にて説明をする。異常検出装置００５は、ユーザが該組込みシステムの使用時における不満を、様々なセンサから得られるセンシングデータを元に、検出するための装置である。異常検出装置００５は、ユーザのアクションをセンシングするための様々なセンサ群５−００１と、センシングした情報からユーザの正常な状態や、異常な状態を判断するための、学習・識別処理をするために、データのＡ／Ｄ変換や、サンプリング等、様々なプリ・プロセッシングをするための形式変換装置５−００２と、形式変換されたデータと、既にユーザの正常状態を、学習装置５−００６を用いて学習した結果である学習結果５−００４を用いて、逐次ユーザが組込みシステムに不満を抱いているか、否かを判定し、不満がある（正常ではない…異常である）と判断した場合には、トレーサ００３、プロファイラ００４経由で、それら挙動情報収集ツールが収集した情報を、通信モジュール００６に転送し、ホスト環境２の通信モジュール０１１に送信する様、通信モジュール００６に依頼し、不満が無いと判断した場合には、その時点でバッファメモリ５−００５に蓄積されているセンシングデータを使い、ターゲットシステム１のユーザの正常状態を学習する様に、学習装置５−００６に対し処理依頼を実施する識別装置５−００３と、形式変換装置５−００２によって変換されたデータを、学習データとして使用出来るか否か、識別装置５−００３が判定を終えるまで、一時的に情報を格納しておくバッファメモリ５−００５と、識別装置５−００３から発行された処理依頼を契機に、バッファメモリ５−００５に蓄積された情報を用いて、機械学習のアルゴリズム等を用い、正常な状態を学習し、識別装置が使用する学習結果５−００４と、記録装置００７に保存されている学習結果を更新する学習装置５−００６からなる。
【００２０】
異常検出装置の処理シーケンス：
図４は異常検出処理の処理シーケンスの一例を示すフローチャートである。システムの起動時などに、異常判定処理は開始する。処理開始後、ステップＳ−０１に進み、記録装置００７に保存されている過去の学習結果を読みだし、ワーキングメモリ上に学習結果５−００４として読み出し、ステップＳ−０２に進む。ステップＳ−０２では、異常判定要求があったか、メモリを走査し、処理を停止するか否かを判定する。処理を停止する場合はそのまま終了し、そうでない場合はステップＳ−０３に進む。ステップＳ−０３では学習結果５−００４と、５−００２から取得したセンサ情報を元に、異常度を算出する。異常度の算出処理は、一般的には、機械学習の識別アルゴリズムのスコアを用いる。一例を挙げると、クラスタリングという手法がある。正常時の挙動情報を元に、それら挙動情報を、ベクトル空間上でクラスという塊に分類し、それらクラスの重心や代表ベクトルと、入力されたベクトルデータの距離を求め、その距離や、その距離を正規化したものを異常度として扱う。この様な異常度算出が終了すると、ステップＳ−０４に進む。ステップＳ−０４異常度比較では、学習結果５−００４に記録されている閾値と、ステップＳ−０３で求めた異常度を比較する。比較したらステップＳ−０５に進む。ステップＳ−０５では、ステップＳ−０４で求めた比較結果を元に、次ステップ以降の処理の分岐を実施する。異常度が、閾知を超えていない場合は、ユーザが正常な状態であると判断し、正常状態の追加学習を行うため、ステップＳ−０８に進む。閾値を越えた場合は、その時点で処理している調査対象プログラム００２の機能の情報を収集するために、ステップＳ−０６に進む。ステップＳ−０６では、トレーサ００３や、プロファイラ００４によって、バッファメモリ００１に記録された挙動情報を、トレーサ００３やプロファイラ００４が提供するＡＰＩや、記録領域へのアクセス用のディスクリプタやアドレス情報等を参考に収集し、ステップＳ−０７に進む。ステップＳ−０７では、収集した情報を元に、通信モジュール００６に対し、ステップＳ−０６で収集した挙動情報を、ホスト環境２の通信モジュール０１１に対して送信して貰うよう、依頼を実施し、ステップＳ−０２へ戻る。ステップＳ−０８では、その時点で、ステップＳ−０３にて算出した異常度の値から正常と判断されたため、正常状態の追加学習をするために、学習装置５−００６に対し、学習を実施する様処理を依頼し、ステップＳ−０２に進む。
【００２１】
図５は、異常検出装置００５の一部である、学習装置５−００６において実施される学習処理の処理シーケンスの一例を示すフローチャートである。識別装置５−００３から、学習の依頼があった際に実施される処理である。処理の依頼を受け付けると、学習処理を開始し、ステップＳ−０８に進む。ステップＳ−０８では、バッファメモリ５−００５に蓄積された学習結果を読み出して、ステップＳ−０９に進む。ステップＳ−０９ではステップＳ−０８で読み出したデータを元に、学習を実施する。一般的には、機械学習等で用いられる学習アルゴリズムを使い、学習を実施する。一例を挙げると、クラスタリングという手法がある。取得した正常時の挙動情報を元に、それら挙動情報を、ベクトル空間上でクラスという塊に分類し、それらクラスの重心や代表ベクトルを求める処理である。学習が終わるとステップＳ−１０に進む。ステップＳ−１０では、ステップＳ−０９で求めた学習結果を基に、学習結果を保存するメモリである学習結果５−００４と、記録装置００７に保存されている学習結果を更新する。更新修了後、ステップＳ−１１に進む。ステップＳ−１１では、学習対象データの残存数をチェックし無い場合には処理を終了、有る場合にはステップＳ−０８に戻る。
【００２２】
図６に設計・開発ツール００８と記録装置０１０における、通常の組込みシステムの設計・開発ツールに追加し、組込みシステムユーザがどの機能で不満を持っていたか、設計・開発時の情報に反映するための定義情報を作成するために、通常の組込みシステムの設計・開発ツールに追加する機能の一例を示す。通常の組込みシステムの設計・開発ツールは多岐にわたる。例を挙げると、システムの設計をする場合でも、ＵＭＬというモデリング言語を使い、ＵＭＬのモデル記述をサポートするモデリングツールを使用して記述する場合もあれば、ドキュメントファイル作成プログラムを用いて、フローチャートを記述する場合もある。この様に、設計手法や、設計ツールは多岐に亘る。同様に、開発ツールも多岐にわたる。プログラミング言語だけでもかなりの数がある上、その言語から実行バイナリを生成するコンパイラや、関連する解析ツールは、言語の数より更に多い。なので、ここでは、それら設計環境、開発環境そのものではなく、それらの他に必要な通常の組込みシステムの設計・開発ツールに追加する部分の一例を示す。設計・開発ツール００８には、設計ツールによって設計され、記録装置０１０に保存されている設計情報０１０−００１と、開発ツールによって作成され、記録装置０１０に保存されている作成プログラム０１０−００２から、処理イベントと対応する位置情報の一覧を抽出し、記録装置０１０解析情報０１０−００３として保存するオブジェクト解析ツール００８−００１と、オブジェクト解析ツールによって解析され、保存された解析情報０１０−００３と、トレース処理の関数名称等のラベル名称が登録された、ユーザが作成した定義情報０１０−００４からトレース用に挿入されたフックやトレース文そのものを抽出し、解析情報０１０−００３を更新するトレース箇所登録ツール００８−００２と、上記した設計情報０１０−００１，作成プログラム０１０−００２，解析情報０１０−００３，定義情報０１０−００４と、それらを記録しておく記録装置０１０から成る。
【００２３】
図７は、記録装置０１０に保存されている解析情報０１０−００３のデータ構造の一例を示す図である。解析情報０１０−００３は、設計に使うツールや、設計手法、プログラムの作成に使うコンパイラやツールチェイン等によって様々に変わる。解析情報０１０−００３のデータ構造は、管理ＩＤ（０１０−００３−００１），ラベル名称（０１０−００３−００２），イベント名称（０１０−００３−００３），アドレス（０１０−００３−００４），問題箇所（０１０−００３−００５）から成る。管理ＩＤ（０１０−００３−００１）は、トレースを取得する先を管理するためのＩＤである。ラベル名称（０１０−００３−００２）は、トレースを取得する位置を示す関数名称や、関数名称とそのオフセット等で表わされる名称である。イベント名称（０１０−００３−００３）は、トレースやプロファイルの内容を示す名称である。アドレス（０１０−００３−００４）は、トレースを取得するラベル名称に対応するアドレス、即ちトレースを取るアドレスである。問題箇所（０１０−００３−００５）は、後述するトレース結果反映処理において、どの機能で組込みシステムユーザが不満を持ったか、システムが結果を書き込むための領域である。
【００２４】
図８は、取得した挙動情報より、該組込みシステムのどの機能の実行時に挙動情報が取得されたかを引当て、解析情報０１０−００３の更新をするための関連処理について示す。通常の組込みシステムの設計・開発ツール００８には、設計情報０１０−００１と、作成プログラム０１０−００２と、解析情報０１０−００３を活用し、設計情報に記録された、ラベル名称、イベント名称と、解析情報０１０−００３の問題箇所（０１０−００３−００５）で問題と記されているラベル名称イベント名称を引当て、設計・開発情報に解析結果を重ね合わせるための解析結果重ね合わせ処理００８−００３の追加を実施する。解析結果の重ね合わせは、該当する機能の表示方法を変更することでも実現出来る。また、該当する機能に、ポインタ等を重ね合わせる方法で実現しても構わない。次に、データ解析機能００９について示す。データ解析機能００９は、以下３つの処理を組み合わせることで、取得した挙動情報０１０−００５、解析情報０１０−００３から、図７で示した解析情報０１０−００３における問題箇所（０１０−００３−００５）の更新を実現する。記録装置０１０に記録された挙動情報０１０−００５を読み込み、ワークメモリ００９−００２を更新し、名前解決処理００９−００３に処理依頼をする挙動情報読み込み処理００９−００１と、挙動情報読み込み処理００９−００１から、データを貰い、図２に示した様なデータ構造でデータを一時的に記録すると同時に、名前解決処理００９−００３処理時に、解析情報０１０−００３を図７に示すデータ構造で一時的に記録し、名前解決処理００９−００３によって、問題箇所か否かの判定結果の更新時の一時記憶として利用される、ワークメモリ００９−００２と、挙動情報読み込み処理００９−００１の処理依頼を受け、記録装置０１０から、解析情報０１０−００３をワークメモリ上に読み出し、ワークメモリ上に展開されている図２に示す挙動情報の先頭から順に、図７に示す解析情報０１０−００３に合致するイベント名称があるかマッチングをし、マッチングがある場合は、解析情報０１０−００３の問題箇所（０１０−００３−００５）を更新し、全ての挙動情報０１０−００５に対し処理が終了した後、設計情報更新処理０９０−００４に対し、記録装置０１０に記録されている設計情報０１０−００１を更新する様処理依頼をする名前解決処理００９−００３と、名前解決処理００９−００３からの処理依頼を受け、ワークメモリ上で更新された解析情報を元に、設計情報０１０−００１の該当する機能のラベルやイベント名称に付加情報を追記・更新するための設計情報更新処理００９−００４からなる。
【実施例２】
【００２５】
実施例１では、ホスト環境とターゲットシステムが、ネットワークによって接続されている例を示したが、ネットワークで接続されてなくても構わない。例えばその場合、通信モジュール００６、０１１は、挿抜可能な記録装置で実現する。普段は、ターゲットシステム１側の通信モジュール００６箇所に、ＳＤカード等に代表される挿抜可能な記録装置を接続しておき、ターゲットシステム１を使用しているユーザが不満に思った際の挙動情報等を記録しておく。そして、開発者やターゲットシステム１のユーザが望んだ段階で、ターゲットシステム１から取り外し、ホスト環境に挿入して、実施例１と同じ内容で、解析を実施する。トレーサ０１２に一例を示すと、トレーサ等挙動情報収集用のツールを更新する場合は、更新したいタイミングで、ホスト情報から挿抜可能な記録装置に記録し、記録された記録装置をターゲットシステム１に挿入して、挙動情報収集用のツール更新処理を実施する。
【実施例３】
【００２６】
実施例１，２は、ターゲットシステム１とホスト環境２が、別々の環境となっているが、同一の環境（筺体）に収まっていても構わない。その場合は、通信モジュールを介したやり取りは実施されず、直接装置や機能間のやり取りが実施される。
【実施例４】
【００２７】
実施例１において、センサ群の情報を自動的に識別する代わりに、ユーザが不満を直接提示出来る機能を備え、不満を持った際に、直接設計者に意思表示することが出来ても構わない。
【産業上の利用可能性】
【００２８】
多くのユーザが潜在的に不満に感じていた箇所と、設計上の位置情報の対応付けが可能となり、組込みシステムを使用するユーザが、対象となる組込みシステムのどの部分に不満に思っているかを設計・開発者が把握することが容易となり、設計・開発者や、一部の声高なユーザの主観に依存しない、使いやすいシステムを提供することが可能となる。
【符号の説明】
【００２９】
１…ターゲットシステム、２…ホスト環境、００１…バッファメモリ、００２…調査対象プログラム、００３…トレーサ、００４…プロファイラ、００５…異常検出装置、００６…通信モジュール、００７…記録装置、００８…設計・開発ツール、００９…データ解析機能、０１０…記録装置、０１１…通信モジュール、０１２…トレーサ。
【図１】
2014041390.tif 000003
【図２】
2014041390.tif 000004
【図３】
2014041390.tif 000005
【図４】
2014041390.tif 000006
【図５】
2014041390.tif 000007
【図６】
2014041390.tif 000008
【図７】
2014041390.tif 000009
【図８】
2014041390.tif 000010