JP5528536B2

JP5528536B2 - プログラムトレース装置

Info

Publication number: JP5528536B2
Application number: JP2012503001A
Authority: JP
Inventors: 賢吾赤穂; 隆志中川; 喜久山口
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2010-03-05
Filing date: 2011-02-24
Publication date: 2014-06-25
Anticipated expiration: 2031-02-24
Also published as: JPWO2011108232A1; DE112011100807T5; CN102782658B; CN102782658A; WO2011108232A1

Description

この発明は、分散システムにおける動作解析に用いられるプログラムトレース装置に関する。

マイクロコンピュータ、プロセッサ等を搭載した組み込み機器、計算機システムをネットワークで接続し、それぞれがネットワークを介して互いにデータ通信を行ない、所定の処理を分散して行なう分散システムがある。単体の組み込み機器または計算機システムの動作解析においては、プログラム上にログを出力するモジュールを埋め込むことで動作解析を行なうことができる。分散システムの動作解析においては、複数の組み込み機器、計算機システムが協調して動作するため、各々の組み込み機器、計算機システムからログを出力してもシステム全体の動作解析をするのが困難である。また、ログの情報量が膨大になるためにデータの保存領域の膨大化など問題があった。

このような分散システムで、システム全体の動作解析を行うためのログ（以下、トレースデータとよぶ）の取得方法には例えば以下のものが知られている。まず、トレース対象となる処理を実行するために送受されるメッセージ中にトレースを制御するデータ（トレース制御データ）を付加し、トレース制御データによりトレースの実施を指示したメッセージを処理するときにのみトレースを行うものがある。また、組み込み機器、計算機システムにおいて、ある受信メッセージに起因してタスクから送られるメッセージにその受信メッセージのトレース制御データを引き継ぐものがある。これにより、複数のノードにまたがって並行に行われる複数の処理の中で、トレース対象処理に関するプログラムだけに限定してログを取得することが可能となる（例えば、特許文献１参照）。

特開平７−９３１８２号公報（第４頁、第７図）

しかしながら、特許文献１では、分散システムにおける全ての組み込み機器、計算機システムのそれぞれでトレースデータを保存しているため、それぞれに記憶領域が必要となる。そのため、記憶領域のない、あるいは充分な容量の記憶領域が確保できない組み込み機器等を含む分散システムには適用できなかった。また、分散システム全体の動作解析の為にそれぞれの組込み機器、計算機システムで保存されたトレースデータを統合する必要があった。

この発明は、上述のような問題を解決するためになされたもので、第一の目的は、記憶領域のない、あるいは充分な記憶領域の確保ができない組み込み機器等を含む分散システムにも適用可能なプログラムトレース装置を得ることである。第二の目的は、複数の組み込み機器、計算機システムで構成される分散システムにおいて、トレースデータを一つの組み込み機器または計算機システムに集約して保存するプログラムトレース装置を得ることである。

この発明に係るプログラムトレース装置は、ネットワークに接続された複数の実行手段を備え、前記複数の実行手段のそれぞれは前記ネットワークを介して他の実行手段にメッセージを送受信し所定の処理を実行する分散システムの動作解析を行うプログラムトレース装置において、前記複数の実行手段の１つであるマスター実行手段は、前記所定の処理の実行指示データを含む第一のデータを生成する第一のアプリケーション部と、前記第一のデータに前記実行指示データの処理内容ごとに予め割り当てられたメッセージＩＤを付加するＩＤ付加部と、前記第一のデータにＣＰＵ間通信回数の所定の初期値を付加するＣＰＵ間通信回数付加部と、受信した前記メッセージにおけるＣＰＵ間通信回数を正常な処理が行われた場合の所定の値と照合することにより、前記マスター実行手段が前記メッセージを送信してから前記複数の実行手段を経由した前記メッセージを受信するまでの処理においてエラーが発生していたことを検出するエラー状態検出部と、前記エラー状態検出部の検出結果により、受信した前記メッセージからトレースデータを抽出して保存するトレースデータ保存部とを備え、前記マスター実行手段から送信される前記メッセージは前記第一のデータ、前記メッセージＩＤ及び前記ＣＰＵ間通信回数を含み、前記複数の実行手段のうち前記マスター実行手段以外であるスレーブ実行手段は、前記マスター実行手段より前記メッセージを受信した場合、受信した前記メッセージにおける前記第一のデータに格納された前記実行指示データに基づいて所定の処理を実行し第二のデータを生成する第二のアプリケーション部と、受信した前記メッセージにおける前記ＣＰＵ間通信回数を更新して設定するＣＰＵ間通信回数更新部とを備え、前記スレーブ実行手段から送信される前記メッセージは前記第二のデータ、前記メッセージＩＤ及び前記ＣＰＵ間通信回数を含む。

この発明によれば、記憶領域のない、あるいは充分な記憶領域の確保できない組み込み機器等を含む分散システムにも適用可能なプログラムトレース装置を得ることができる。

また、複数の組み込み機器、計算機システムで構成される分散システムにおいて、トレースデータを一つの組み込み機器または計算機システムに集約して保存するプログラムトレース装置を得ることができる。

この発明の実施の形態１における分散システムのプログラムトレース装置の構成図である。（ａ）この発明の実施の形態１における各実行手段間でやり取りするメッセージデータの流れを示したシーケンス図である。（ｂ）この発明の実施の形態１における各実行手段間でやり取りするメッセージのデータ構造を示す図である。この発明の実施の形態１における正常動作時通信回数テーブル５１０の構成図である。この発明の実施の形態１におけるエラー状態検出部１４０およびトレースデータ保存部１５０の処理フロー図である。この発明の実施の形態１におけるトレースデータの例を示す図である。この発明の実施の形態２における正常動作時通信回数テーブル５１０の構成例を示す図である。この発明の実施の形態２におけるエラー状態検出部１４０およびトレースデータ保存部１５０の処理フロー図である。この発明の実施の形態３におけるプログラムトレース装置の構成図である。（ａ）この発明の実施の形態３における各実行手段間でやり取りするメッセージデータの流れを示すシーケンス図である。（ｂ）この発明の実施の形態３におけるメッセージデータのデータ構造を示す図である。この発明の実施の形態４におけるプログラムトレース装置の構成図である。この発明の実施の形態４におけるメッセージデータの構成図である。この発明の実施の形態５におけるプログラムトレース装置の構成図である。この発明の実施の形態５におけるプログラムトレース装置の構成図である。この発明の実施の形態５におけるスレーブトリガ処理部２９０ａおよびＣＰＵ間通信回数更新部２６０ａの処理フロー図である。この発明の実施の形態５における各実行手段間でやり取りするメッセージデータの流れを示すシーケンス図である。

実施の形態１．
この発明を実施するための実施の形態１における分散システムのプログラムトレース装置の構成を図１に示す。同図に示すように、分散システムはネットワーク４００に複数の実行手段１００、２００ａ、２００ｂが接続される。一つの実行手段をマスター実行手段１００、それ以外の実行手段をスレーブ実行手段と呼ぶことにする。図１には、２つのスレーブ実行手段２００ａおよび２００ｂが接続されている構成例を示す。しかし、この構成に限るものではない。すなわち、マスター実行手段１００に加えて、スレーブ実行手段として１つ以上が接続されているものであればよい。また、これは以下のすべての実施の形態においても同様である。
ここでは説明の都合上、図１に示すように、スレーブ実行手段として２００ａ、２００ｂが接続された構成例について示す。

本実施の形態における分散システムでは、マスター実行手段１００がスレーブ実行手段２００ａ、２００ｂのそれぞれにトレース処理を指示するトリガとなるメッセージデータを送信し、指示したトレース処理に対する最終の処理が完了したときにはマスター実行手段１００にメッセージデータが返信されるものを対象とする。マスター実行手段がトレース処理のトリガとなるものをマスタートリガ処理と呼ぶことにする。

本発明における実行手段とは、１つ以上のシーケンス制御機能などが設計されたアプリケーション部を有し、入力される実行指示に基づいて所定の処理を実行するものである。これは例えば、シーケンス制御専用のマイクロコンピュータを搭載した組み込み機器、あるいは計算機システムを指す。マスター実行手段１００は、正常動作時通信回数テーブル５１０およびトレースデータ６１０を記憶するバッファ（記憶領域）５００および６００を内蔵する。あるいは、マスター実行手段１００が、正常動作時通信回数テーブル５１０およびトレースデータ６１０を記憶するためのバッファとのインタフェースを有するものであってもよい。一方、スレーブ実行手段２００ａ、２００ｂは、シーケンス制御専用のマイクロコンピュータを搭載した組み込み機器など所定の処理を行うのに必要な領域の記憶領域以外には余分な記憶領域がない、あるいは記憶容量に余裕のないものである。また、ネットワーク４００は、ＩＥＥＥ１３９４規格に準拠したシリアルバスを用いたネットワーク、ＬＡＮ、ＷＡＮに代表される複数のコンピュータを接続するコンピュータネットワークなどを指す。

次に、マスター実行手段１００の構成を説明する。マスター実行手段１００は、アプリケーション部１１０、ＩＤ付加部１２０、ＣＰＵ間通信回数付加部１３０、エラー状態検出部１４０、トレースデータ保存部１５０、正常動作時通信回数テーブル５１０を有するバッファ（記憶領域）５００、トレースデータ６１０を保存するバッファ（記憶領域）６００を含む。また、マスター実行手段１００には図示しない通信インタフェースが備えられ、ネットワーク４００を介してメッセージを送受信する。

アプリケーション部１１０は、スレーブ実行手段２００ａ、２００ｂへの実行指示データを含むアプリケーションデータ（第一のデータ）を発行する。ＩＤ付加部１２０は、アプリケーション部１１０から発行された第一のデータにメッセージＩＤを付加する。また、ＣＰＵ間通信回数付加部１３０は、ＩＤ付加部１２０の出力にＣＰＵ間通信回数として所定の初期値を付加する。次いで、マスター実行手段１００はメッセージデータを、通信インタフェースを介してネットワーク４００上に送信する。
エラー状態検出部１４０はネットワーク４００を介してマスター実行手段１００が受信したメッセージデータに含まれるＣＰＵ間通信回数を基に、正常動作時通信回数テーブル５１０を参照してＣＰＵ間通信回数が正常であるかを判定する。ここで正常動作時通信回数テーブル５１０には、予めメッセージＩＤに対応付けて正常動作が行われた場合の通信回数（正常動作時通信回数）が保持される。

トレースデータ保存部１５０はエラー状態検出部１４０の判定結果により、マスター実行手段１００が受信したメッセージからトレースデータ６１０を抽出してバッファ６００に保存する。

実行指示データとは、この分散システムにおける処理実行に関する情報である。実行指示データには、例えば、対象となる実行手段に関する情報、その実行手段が有するアプリケーション部での処理内容を指す情報とその処理を行なう際に用いられる引数の情報、データなどが含まれている。これは例えば、それぞれの実行手段における所定の処理を実行するために定義されたプログラムにおける関数名、シーケンス番号等、およびそれらの処理を行なう際に用いられる引数の情報、データなどであってもよい。

また、メッセージＩＤは、アプリケーション部１１０が発行する第一のデータに対して、そのデータが有する処理内容に対応付けたものである。これは同じ処理内容であっても引数など付随するデータによって正常動作時の通信回数が異なるものについてはそれぞれ別のメッセージＩＤとする。メッセージＩＤは単純な番号であっても処理内容を表す関数名などを示す文字列等であってもよい。

正常動作時通信回数テーブル５１０は、バッファ５００に記憶されており、トレースデータはバッファ６００に随時保存されていくものである。これらバッファ５００および６００はハードディスク、フラッシュメモリ、メモリカード、ＤＶＤなどの外部記憶装置内で構成されてもよい。あるいは、マスター実行手段１００が搭載するプロセッサが内蔵するメモリを用いてもよい。

次に、スレーブ実行手段２００ａ、２００ｂの構成を説明する。スレーブ実行手段２００ａは、受信したメッセージデータの実行指示データに基づいて所定の処理を実行し、アプリケーションデータ（第二のデータ）を出力する第二のアプリケーション部２１０ａ、及び前記第二のデータに当該メッセージＩＤと当該ＣＰＵ間通信回数に所定の値として１を加算して更新したＣＰＵ間通信回数とを付加したメッセージデータを送信するＣＰＵ間通信回数更新部２６０ａが含まれる。同様に、スレーブ実行手段２００ｂは、受信したメッセージデータの実行指示データに基づいて所定の処理を実行し、第二のデータを出力する第二のアプリケーション部２１０ｂ、及び前記第二のデータに当該メッセージＩＤと当該ＣＰＵ間通信回数に所定の値として１を加算して更新したＣＰＵ間通信回数とを付加したメッセージデータを送信するＣＰＵ間通信回数更新部２６０ｂで構成される。

図２（ａ）に、本実施の形態の構成において、各実行手段間でやり取りするメッセージデータの流れを示したシーケンスを例示する。また、メッセージのデータ構造を同図（ｂ）に示す。

以下、このシーケンス図の流れに沿って本実施の形態のトレースデータを抽出する動作について説明する。
まず、マスター実行手段１００のアプリケーション部１１０が実行指示データを有する第一のデータ（Ｄａｔａ１）を生成し出力する。次に、ＩＤ付加部１２０で第一のデータに対して処理内容に対応付けたメッセージＩＤを付加する。ここでは、メッセージＩＤとして単純な番号を付加する例として（１）を付加する。さらに、ＣＰＵ間通信回数付加部１３０でメッセージＩＤの付加された第一のデータにＣＰＵ間通信回数として所定の初期値、例えば、１を付加する。このメッセージＩＤとＣＰＵ間通信回数の初期値が付加された第一のデータをメッセージデータとしてネットワーク４００上に送信する。このメッセージデータでのメッセージＩＤとＣＰＵ間通信回数の組み合わせを（メッセージＩＤ、ＣＰＵ間通信回数）＝（１、１）と示すことにする。

このメッセージデータの送信先の実行手段であるスレーブ実行手段２００ａが受信し、アプリケーション部２１０ａによって所定の処理を行なう。この処理が完了し、ネットワーク４００を介して、マスター実行手段１００へ第二のデータ（Ｄａｔａ２）を送信するときに、ＣＰＵ間通信回数更新部２６０ａによって受信した当該メッセージＩＤ（１）と、受信した当該ＣＰＵ間通信回数（１）に所定の値として１を加算してＣＰＵ間通信回数を更新してマスター実行手段１００に送信する。この時（メッセージＩＤ、ＣＰＵ間通信回数）＝（１、２）となる。

また、上記とは別の処理として、スレーブ実行手段２００ａが別のスレーブ実行手段２００ｂにネットワーク４００を介して通信するときの説明を行なう。この場合、アプリケーション部２１０ａによって生成される第二のデータ（Ｄａｔａ３）に、ＣＰＵ間通信回数更新部２６０ａによって受信した当該メッセージＩＤ（１）を付加する。また、受信した当該ＣＰＵ間通信回数（１）に所定の値として１を加算してＣＰＵ間通信回数を更新する。次いで、メッセージをスレーブ実行手段２００ｂに送信する。この時（メッセージＩＤ、ＣＰＵ間通信回数）＝（１、２）となる。

スレーブ実行手段２００ｂはスレーブ実行手段２００ａからのメッセージデータを受信し、アプリケーション部２１０ｂによって所定の処理を行なう。この処理が完了し、スレーブ実行手段２００ａに第二のデータ（Ｄａｔａ４）を送信する前に、ＣＰＵ間通信回数更新部２６０ｂによって受信したメッセージにおけるメッセージＩＤ（１）を付加する。さらに、受信したメッセージにおけるＣＰＵ間通信回数（２）に所定の値として１を加算してＣＰＵ間通信回数を更新する。次いで、ネットワーク４００を介してスレーブ実行手段２００ａに送信する。この時（メッセージＩＤ、ＣＰＵ間通信回数）＝（１、３）となる。

スレーブ実行手段２００ａは、スレーブ実行手段２００ｂからのメッセージデータを受信し、アプリケーション部２１０ａによって所定の処理を行なう。ここでのアプリケーション部２１０ａでの処理として、ある処理で第二のデータ（Ｄａｔａ５）をマスター実行手段１００に送信するものと、これとは別の処理で第二のデータ（Ｄａｔａ６）をマスター実行手段１００に送信するものがあった場合、どちらもＣＰＵ間通信回数更新部２６０ａによって更新されるＣＰＵ間通信回数は４（メッセージＩＤ、ＣＰＵ間通信回数）＝（１、４）となる。すなわち、アプリケーション部２１０ａの処理内容が異なる場合であっても、メッセージＩＤおよびＣＰＵ通信回数は同じ値となる。
このように、アプリケーション部２１０ａの処理内容に依存せず、送信されたメッセージＩＤを伝達し、実行手段で受信する度にＣＰＵ通信回数を順次更新したメッセージデータが伝達されていく。

また、マスター実行手段１００が新たにアプリケーション部１１０から実行指示データを有する第一のデータ（Ｄａｔａ７）を生成した場合は、ＩＤ付加部１２０で第一のデータにメッセージＩＤ（２）を付加して上述と同様の処理を行なうこととなる。

図３に、正常動作時通信回数テーブル５１０の構成例を示す。正常動作時通信回数テーブル５１０は、分散システムの動作解析を行なう際に、メッセージＩＤに対して正常に通信を実施した場合にマスター実行手段１００に返ってくるまでの通信回数として正しい回数を正常動作時通信回数として記憶したものである。図３において、例えばメッセージＩＤが１の処理では、マスター実行手段１００に別のスレーブ実行手段から送信されるときの通信回数は２または４の場合があることを示す。同じようにメッセージＩＤが２の処理ではマスター実行手段１００に別のスレーブ実行手段から送信されるときの通信回数は２または６の場合があることを示す。

第一のデータに割り当てられるメッセージＩＤと処理内容は予め一意に定めて設計され、上記設計の仕様に従って、メッセージＩＤとそれに対応付けた正常動作時の通信回数とのテーブルを用意する。

図４に、マスター実行手段１００が他の実行手段からのメッセージを受信した際のエラー状態検出部１４０およびトレースデータ保存部１５０の処理フローを示す。マスター実行手段１００は、スレーブ実行手段から送信されたメッセージを受信し（ステップＳＴ０１０）、次いでエラー状態検出部１４０は受信したメッセージデータにあるメッセージＩＤに対応する正常動作時通信回数を正常動作時通信回数テーブル５１０から取得する（ステップＳＴ０２０）。

次に、エラー状態検出部１４０は、受信したメッセージにおけるＣＰＵ間通信回数が、ステップＳＴ０２０にて取得した正常動作時通信回数に該当する（複数の値がある場合はそのいずれかに一致する）か否かを判定し、ＹｅｓかＮｏかの判定結果を出力する（ステップＳＴ０３０）。ここでＹｅｓは、受信したメッセージデータにあるＣＰＵ間通信回数が、ステップＳＴ０２０にて取得した正常動作時通信回数に該当することを意味し、Ｎｏは該当しないことを示す。

エラー状態検出部１４０は、ステップＳＴ０３０の結果がＹｅｓであれば、アプリケーション部１１０に受信したメッセージデータにあるデータを供給する（ステップＳＴ０６０）。一方、ステップＳＴ０３０の結果がＮｏであれば、エラーがあったと判定してトレースデータ保存部１５０にエラーがあったことを通知する（ステップＳＴ０４０）。トレースデータ保存部１５０はエラーがあったときに受信したメッセージデータと正常動作時通信回数テーブル５１０に記憶されている当該メッセージＩＤに対応付けられた正常動作時通信回数とから、動作解析に使用する情報をトレースデータとして抽出してバッファ６００に保存する（ステップＳＴ０５０）。

トレースデータの例を図５に示す。同図に示すように、受信したメッセージデータのＣＰＵ間通信回数、そのメッセージデータにおけるアプリケーションデータ、メッセージＩＤ、正常動作時通信回数を保存する。これら全てをトレースデータとして保存せず、例えばメッセージ内のデータを除くなどして保存する情報量を削減してもよい。次いで、ステップＳＴ０３０の結果がＹｅｓの場合と同様、アプリケーション部１１０に受信したメッセージデータにあるデータを供給する（ステップＳＴ０６０）

本実施の形態によれば、マスター実行手段１００のみで対象の処理フローが正常な通信回数で処理されているかの判定を行ない、その判定結果とマスター実行手段１００が受信したメッセージデータとからトレースデータを抽出して保存することができる。そのため、マスター実行手段１００でトレースデータ集約させて保存することが可能となり、スレーブ実行手段にトレースデータを保存する記憶領域を持つ必要がなくなるという効果を奏する。さらに、トレースデータが集約されて保存されるので動作解析の度に複数のトレースデータを統合する手間が不要となる。

実施の形態２．
実施の形態１では、ＩＤ付加部１２０によって第一のデータの処理内容に対応したメッセージＩＤを付加し、正常動作時通信回数テーブル５１０がメッセージＩＤに対応付けたＣＰＵ間通信回数を用意していたが、実施の形態２ではメッセージＩＤの代わりに、第一データが発行される毎に割り当てるシーケンス番号をＩＤ付加部１２０によって付加し、トレースデータとしてシーケンス番号を保存対象に含めるものである。

本実施の形態におけるプログラムトレース装置の構成は図１に示したものと同様である。
本実施の形態においては、アプリケーション部１１０が第一のデータを発行する度に、ＩＤ付加部１２０が個別のシーケンス番号を割り当てて付加する。また、正常動作時通信回数テーブル５１０にメッセージＩＤ毎に、このシーケンス番号を記憶させる。シーケンス番号は、例えば、１から番号順に設定するものとする。なお、このシーケンス番号はメッセージＩＤそれぞれにおいて個別であると共に、実行順序が判別可能であればよい。従って、１から採番するものに限られるものではなく、現在時刻、経過時間等に合わせて設定する方法でも良い。

図６に本実施の形態における正常動作時通信回数テーブル５１０の構成例を示す。同図に示すように、メッセージＩＤに対応付けて保持された正常動作時通信回数に加えて、そのメッセージＩＤに対して付加されたシーケンス番号を記憶する領域が設けられており、ここにＩＤ付加部１２０が付加するシーケンス番号を記憶していく。

本実施の形態では、メッセージデータに付加されるものがメッセージＩＤの代わりにシーケンス番号となるので、スレーブ実行手段２００ａ、２００ｂにおいてＣＰＵ間通信回数更新部２６０ａまたは２６０ｂはアプリケーション部２１０ａまたは２１０ｂが生成した第二のデータに、受信したメッセージにおけるシーケンス番号を付加する。さらに、受信したメッセージにおけるＣＰＵ間通信回数に所定の値として例えば、１を加算して更新したＣＰＵ間通信回数とを付加したメッセージデータを送信する。

図７に、マスター実行手段１００が他のスレーブ実行手段からメッセージデータを受信した際のエラー状態検出部１４０およびトレースデータ保存部１５０の処理フローを示す。

マスター実行手段１００が、スレーブ実行手段から送信されたメッセージを受信し（ステップＳＴ１１０）、エラー状態検出部１４０は受信したメッセージにあるシーケンス番号に対応する正常動作時通信回数を正常動作時通信回数テーブル５１０から取得する（ステップＳＴ１２０）。次いで、該当するシーケンス番号を正常動作時通信回数テーブル５１０から削除する（ステップＳＴ１３０）。該当するシーケンス番号を正常動作時通信回数テーブル５１０から削除することで、正常動作時通信回数テーブル５１０の記憶領域を冗長に増加させないで済む効果を生む。

次に、エラー状態検出部１４０は、受信したメッセージにおけるＣＰＵ間通信回数が、ステップＳＴ１２０にて取得した正常動作時通信回数に該当するかを判定し、ＹｅｓかＮｏかの判定結果を出力する（ステップＳＴ１４０）。以下のステップＳＴ１４０〜ＳＴ１７０については実施の形態１における図４のステップＳＴ０３０〜ＳＴ０６０と同様である。

すなわち、エラー状態検出部１４０は、ステップＳＴ１４０の結果がＹｅｓであれば、アプリケーション部１１０に受信したメッセージデータにあるデータを供給する（ステップ１７０）。一方、ステップＳＴ１４０の結果がＮｏであれば、エラーがあったと判定してトレースデータ保存部１５０にエラーがあったことを通知する（ステップＳＴ１５０）。トレースデータ保存部１５０はエラーがあったときに受信したメッセージデータと正常動作時通信回数テーブル５１０に記憶されている当該メッセージＩＤに対応付けられた正常動作時通信回数とから動作解析に使用する情報をトレースデータとして抽出してバッファ６００に保存する（ステップＳＴ１６０）。

ここで、トレースデータとして受信したメッセージデータのＣＰＵ間通信回数、アプリケーションデータ、メッセージＩＤ、シーケンス番号、正常動作時通信回数を保存する。これら全てをトレースデータとして保存せず、例えばアプリケーションデータを除くなどして保存する情報量を削減してもよい。

本実施の形態によれば、実施の形態１と同様に、マスター実行手段１００のみで対象の処理フローが正常な通信回数で処理されているかの判定を行ない、その判定結果とマスター実行手段１００が受信したメッセージデータとからトレースデータを抽出して保存することができる。そのため、マスター実行手段１００でトレースデータ集約させて保存することが可能となり、スレーブ実行手段にトレースデータを保存する記憶領域を持つ必要がなくなるという効果を奏する。さらに、トレースデータが集約されて保存されるので動作解析の度に複数のトレースデータを統合する手間がなくなるという効果を奏する。

また、処理内容に対応付けたメッセージＩＤではなく、実行指示データの発行が行なわれる度にシーケンス番号を割り振って付加したメッセージデータを通信する。そのため、マスター実行手段１００が受信したメッセージデータのＣＰＵ間通信回数が、該当する処理内容に対応付けた正常動作時通信回数に該当しない場合に、シーケンス番号を含めたトレースデータを保存することになる。これにより、動作解析時にシーケンス番号の情報によってエラーがあった処理を時系列に把握することが容易になるので、どのタイミングでエラーが発生しているかをより明確に把握することができ、より詳細な動作解析が可能になる。

実施の形態３．
以上の実施の形態においては、マスター実行手段１００におけるＣＰＵ間通信回数付加部１３０でＣＰＵ間通信回数として例えば初期値１を付加し、スレーブ実行手段におけるＣＰＵ間通信回数更新部（２６０ａまたは２６０ｂ）において、受信したメッセージにおけるＣＰＵ間通信回数に所定の値として１を加算してＣＰＵ間通信回数を更新していた。本実施の形態では、メッセージＩＤに対応付けられた正常動作時通信回数のうち一番大きいものを初期値とし、スレーブ実行手段におけるＣＰＵ間通信回数更新部において１減算してＣＰＵ間通信回数を更新するものである。

図８に、本実施の形態におけるプログラムトレース装置の構成を示す。なお、図８において実施の形態１の図１と同一の符号のものにおいては、それぞれ実施の形態１の同一の符号のものと相当するものであるので、その説明を省略する。また、本実施の形態では各実行手段に個別のＣＰＵ識別子を割り当てる。ＣＰＵ識別子は例えば、マスター実行手段１００については１００、スレーブ実行手段２００ａ、２００ｂはそれぞれ２００ａ、２００ｂとする。

マスター実行手段１００のＣＰＵ間通信回数付加部１３０は、ＩＤ付加部１２０から付加されたメッセージＩＤに対応する正常動作時通信回数を正常動作時通信回数テーブル５１０から読み出し、読み出された正常動作時通信回数のうち最も大きい回数をＣＰＵ間通信回数の初期値として付加したメッセージデータを送信する。これによって、正常に通信を行なっている時のメッセージデータにあるＣＰＵ間通信回数は常に０以上の値となる。

スレーブ実行手段の構成について、スレーブ実行手段２００ａを例として説明する。以下の動作は他のスレーブ実行手段（例えばスレーブ実行手段２００ｂ）においても同様である。
スレーブ実行手段２００ａには実施の形態１における図１の構成に加えて、通信エラー判定部２７０ａが備えられる。
通信回数エラー判定部２７０ａは受信したメッセージにおけるＣＰＵ間通信回数が０以上であるか否かを判定する。ＣＰＵ間通信回数が０以上であれば、そのままアプリケーション部２１０ａにそのメッセージデータ（あるいはアプリケーションデータのみ）を供給する。

一方、ＣＰＵ間通信回数が負の値である場合は、その時点で処理が正常動作でないと判定して、メッセージデータに自己の実行手段（すなわち、スレーブ実行手段２００ａ）のＣＰＵ識別子と当該メッセージデータを送信した実行手段のＣＰＵ識別子とを付加してマスター実行手段１００に送信する。この場合、処理が正常動作でないため、スレーブ実行手段２００ａのアプリケーション部２１０ａにそのメッセージデータ（あるいはアプリケーションデータ）を供給する必要はない。
また、ＣＰＵ間通信回数を例えば４ｂｉｔの２進数の２の補数表現で与えるとした場合は、−１を（１１１１）と表現することになり、最上位ｂｉｔを見ればＣＰＵ間通信回数が１０進数形式で負の値であることを容易に判定することができる。

各実行手段間でやり取りするメッセージデータの流れを示したシーケンス図の例を図９（ａ）に示す。また、同図（ｂ）にスレーブ実行手段２００ａにおける通信回数エラー判定部２７０ａにおいて、エラーと判定した場合のメッセージデータのデータ構造をデータ例と共に示す。

図９（ａ）において、スレーブ実行手段２００ａがスレーブ実行手段２００ｂから第二のデータとして（Ｄａｔａ９）を受けた時の動作を例として説明する（図９（ａ）の白抜き矢印の部分）。この時、通信回数エラー判定部２７０ｂは受信したメッセージにおけるＣＰＵ間通信回数が−１、すなわち負の値であることから、その時点で処理が正常動作でないと判断する。また、メッセージデータに自身のＣＰＵ（すなわち、スレーブ実行手段２００ｂ）のＣＰＵ識別子である２００ｂとそのメッセージデータを送信した実行手段であるスレーブ実行手段２００ａの識別子である２００ａとを付加してマスター実行手段１００に送信する。エラーと判定した時のデータの一例を図９（ｂ）に示す。

マスター実行手段１００は、スレーブ実行手段２００ａ、２００ｂから送信されたメッセージを受信する。マスター実行手段１００におけるエラー状態検出部１４０は、受信したメッセージデータのＣＰＵ間通信回数が０以上の場合はアプリケーション部１１０に受信したメッセージデータ（またはアプリケーションデータ）を供給する。一方、ＣＰＵ間通信回数が負の値である場合は、トレースデータ保存部１５０にエラーがあったことを通知する。トレースデータ保存部１５０は受信したメッセージデータと正常動作時通信回数テーブル５１０に記憶されている当該メッセージのメッセージＩＤに対応付けられた正常動作時通信回数とをトレースデータ６１０として抽出し、バッファ６００に保存する。

トレースデータ６１０の例として、受信したメッセージデータのＣＰＵ間通信回数、アプリケーションデータ、メッセージＩＤ、正常動作時通信回数に加え、エラーを検出した実行手段のＣＰＵ識別子と送信元ＣＰＵ識別子を保存する。これら全てをトレースデータとして保存せず、例えばアプリケーションデータを除くなどして保存する情報量を削減しても構わない。

このようにして、ＣＰＵ間通信回数のエラー判定を各実行手段で行ない、エラーを検知したＣＰＵ番号から該当する実行手段が特定できるので、分散システムの動作解析においてエラー発生箇所の特定が容易となり、エラー発生時のより詳細なトレースデータを取得することが可能となる。
本実施の形態においても、実施の形態１および２と同様の効果も得られる。

実施の形態４．
図１０に、実施の形態４におけるプログラムトレース装置の構成を示す。なお、図１０において実施の形態１における図１と同一の符号のものにおいては、それぞれ実施の形態１の同一の符号のものと相当するものであるので、その説明を省略する。また、本実施の形態では実施の形態３と同様に各実行手段に個別のＣＰＵ識別子を割り当てている。

実施の形態１における図１の構成に加えて、各スレーブ実行手段２００ａ、２００ｂにおいて、ＣＰＵ識別子付加部２８０ａ、２８０ｂが備えられる。
スレーブ実行手段２００ａ、２００ｂでは、それぞれにおけるアプリケーション部２１０ａ、２１０ｂが第二のデータを出力した後に、ＣＰＵ識別子付加部２８０ａ、２８０ｂにおいて当該実行手段のＣＰＵ識別子を順に付加する。図１１にこの場合のメッセージデータの構成を示す。同図に示すように、メッセージにおいてＣＰＵ間通信回数、メッセージＩＤ、アプリケーションデータに加え、ＣＰＵ識別子１、ＣＰＵ識別子２、・・・、ＰＵ識別子ｎ（ＣＰＵ識別子ｎは付加された最終のＣＰＵ識別子を示す）の情報が付加される。同図におけるＣＰＵ識別子１〜ｎのかっこ内には付加されるＣＰＵ識別子情報の例を示す。

この際、マスター実行手段１００のエラー状態検出部１４０がエラーであると判定した場合にトレースデータ保存部１５０が抽出するデータとして、実施の形態１のトレースデータに加えて、メッセージデータに付加されているメッセージが経由したＣＰＵ番号の情報を保存する。

以上述べたトレースデータを保存することで、エラー発生時に経由していた実行手段の経過情報を辿ることが可能となるので、分散システムの動作解析としてより詳細な解析が可能となる。
本実施の形態は実施の形態２のようにシーケンス番号を用いたプログラムトレース装置においても適用でき、この場合も本実施の形態と同様の効果を奏する。
本実施の形態によれば、上記のエラー発生時に経由していた実行手段の経過情報を辿ることが可能となる効果に加え、実施の形態１および２における効果も得られる。

実施の形態５．
以上の実施の形態１〜４においてはマスター実行手段１００がトレース実行のトリガとなる（マスタートリガ処理）ものである。本実施の形態ではスレーブ実行手段がトレース実行のトリガとなる場合においても適用可能なプログラムトレース装置の構成を示す。ここでスレーブ実行手段がトレース実行のトリガとなる、すなわち、トレースを起動する実行手段となる場合を以下、スレーブトリガ処理とよぶ。
スレーブトリガ処理は、例えば、特定のスレーブ実行手段以降の処理が正しい動作であるか否か疑わしい場合に分散システムの解析を進める際に有効になる。すなわち、マスター実行手段から上記特定のスレーブ実行手段の手前までは処理が正常であることが判明しているか、あるいは確実である場合に、その特定のスレーブ実行手段以降の動作に対象を絞った分散システムの解析が容易となる。

なお、本実施の形態においても、実施の形態１〜４と同様に、マスター実行手段１００から指示された、スレーブ実行手段に対する実行指示（アプリケーション部２１０ａ、２１０ｂ等に対する指示）が各スレーブ実行手段に派生していき、それらの最終の処理が完了した場合には必ずマスター実行手段１００にネットワーク４００を介してメッセージが送信されるものを対象とする。

本実施の形態におけるプログラムトレース装置の構成を図１２に示す。なお、図１２において実施の形態１における図１と同一の符号のものにおいては、それぞれ実施の形態１の同一の符号のものと相当するものであるので、その説明を省略する。

以下、スレーブ実行手段２００ａを例に説明する。
スレーブ実行手段２００ａには実施の形態１における図１の構成に加えて、スレーブトリガ処理部２９０ａが備えられる。
スレーブ実行手段２００ａにおけるアプリケーション部２１０ａは実施の形態１〜４と同様に、他の実行手段から送信されたメッセージにおけるアプリケーションデータ（第一または第二のデータ）に基づいて所定の処理を実行してアプリケーションデータ（第二のデータ）を発行する。

本実施の形態では、いずれかのスレーブ実行手段がトレースのトリガとなる場合には、マスター実行手段１００がトリガとなるトレースは行われないものとする。
これは例えば、マスター実行手段１００におけるアプリケーション部１１０、スレーブ実行手段２００ａ、２００ｂにおけるアプリケーション部２１０ａ、２１０ｂ等に設定される実行指示を実施するためのプログラムにおいて、予め上記の排他処理が可能となるようにプログラムを作成しておくことにより実現できる。

あるいは、図１３に示すように、分散システムにおいてトレースのトリガ処理をいずれの実行手段が行うか設定するトレーストリガ制御部７００を設けてもよい。このトレーストリガ制御部７００が例えばディスレイ、キーボード等からなる入力手段（図示せず）を備え、分散システムの操作者がこの入力手段を通じて、トレーストリガとなる実行手段の設定を行うようにしてもよい。あるいは、トレーストリガ制御部７００に予めプログラム等を組み込んでおき、このプログラムを動作させることにより、トレーストリガとなる実行手段を設定するものであってもよい。なお、図１３において、トレーストリガ制御部７００はネットワーク４００を経由して、各実行手段に接続される構成例を示したが、各実行手段にネットワークを介さずに接続されるものであってもよい。

上述のように、本実施の形態においてスレーブトリガ処理が行われる場合には、マスタートリガ処理は行われない。そのためマスター実行手段１００からのメッセージにトレースのためのメッセージＩＤは含まれないことになる。この場合、マスター実行手段１００から送信されるのは、スレーブ実行手段２００ａ、２００ｂ等のアプリケーション部２１０ａ、２１０ｂ等に対する指示データとなる。
ここで、アプリケーションデータまたはメッセージのデータを通信インタフェースがネットワーク４００に送受信するためのネットワークアドレス等は、この発明の実施の形態１〜５におけるメッセージＩＤとは異なる情報である。すなわち、各実行手段間の通信機能は本実施の形態で述べるメッセージＩＤに依存せずに実現される。

次に、動作について説明する。以下、図１２に沿って説明するが、図１３の場合でも同様である。
図１２において、スレーブトリガ処理部２９０ａは、アプリケーション処理部２１０aの処理に続いて実行される。
図１４にスレーブトリガ処理部２９０ａおよびＣＰＵ間通信回数更新部２６０ａの処理フローを示す。スレーブトリガ処理部２９０ａは上述のアプリケーション処理部の処理に続いて起動される（ステップＳＴ２００）。次に、ステップＳＴ２１０において、自ＣＰＵ、すなわち、この場合はスレーブ実行手段２００ａが、トレース実行のトリガであるか否かを判定する。

自ＣＰＵがトレース実行のトリガであるとは、例えば、図１３に示したトレーストリガ制御部７００から設定される情報によって知ることができる。
あるいは、トレーストリガ制御部７００を用いる方法以外に、アプリケーション部２１０ａが生成するアプリケーションデータ（第二のデータ）中の所定の位置に設定したフラグのＯＮまたはＯＦＦの情報によって判断することができる（例えば、ＯＮは処理実行のトリガである旨予め定めておく）。あるいは、スレーブ実行手段２００におけるアプリケーション部２００ａに処理実行のトリガであることを設定する命令を所定の位置に埋め込んでおき、上記命令の実行によって前述のフラグをＯＮまたはＯＦＦにする方法もある。

あるいは、スレーブ実行手段２００ａにディスレイ、キーボード等からなる入力手段を備え、分散システムの操作を行う操作者からのコマンド等の入力情報によって、処理実行のトリガであることを指定される場合もある。
さらに、マスター実行手段１００からメッセージ等による通信によって処理実行のトリガとなることが通知されるものであってもよい。

ステップＳＴ２１０の判定結果がＹｅｓであれば、ステップＳＴ２２０に進む。ステップＳＴ２２０において、自ＣＰＵ（すなわちスレーブ実行手段２００ａ）に予め割り当てられたメッセージＩＤを、上述のアプリケーションデータ（第二のデータ）に付加する。次いでＣＰＵ間通信回数の初期値を付加する（ステップＳＴ２３０）。ステップＳＴ２１０の判定結果がＮｏであれば、自ＣＰＵがトリガではないことになる。この場合は、マスター実行手段１００がトレースのトリガである場合と、他のスレーブ実行手段がトレースのトリガである場合の２通りがある。ここで、いずれの実行手段もトリガとならない場合については本発明の対象外であるため説明を省略する。

まず、マスター実行手段１００がトレーストリガ処理となる場合（マスタートリガ処理）、ステップＳＴ２５０において受信したメッセージのメッセージＩＤをメッセージに付加した後、ＣＰＵ間通信回数更新部２６０ａにメッセージを供給する。ＣＰＵ間通信回数更新部２６０ａはステップＳＴ２６０において、実施の形態１〜４と同様に、ＣＰＵ間通信回ＣＰＵ間通信回数を更新する。
次に、他のスレーブ実行手段がスレーブトリガ処理を行う場合は、該当するスレーブ手段からのメッセージにはそのスレーブ実行手段が設定したメッセージＩＤおよびＣＰＵ通信回数が含まれる（ステップＳＴ２２０、ＳＴ２３０参照）。従って、ステップＳＴ２５０、ＳＴ２６０において、上述のマスタートリガ処理の場合と同様に、受信したメッセージのメッセージＩＤをメッセージ（受信したメッセージ中のアプリケーションデータをアプリケーション部２１０ａが作成した第二のデータで更新したもの）に付加した後、ＣＰＵ間通信回数更新部２６０ａにより、ＣＰＵ間通信回数が更新される。ステップＳＴ２３０、ＳＴ２６０いずれの場合も、次いでステップＴ２４０に進み、発行されたメッセージは通信インタフェースを介してネットワーク４００に送信される。

図１５に、本実施の形態における、スレーブ実行手段２００ａが処理実行のトリガとなる場合に、各実行手段間でやり取りするメッセージデータの流れを示したシーケンス図の例を示す。同図において、スレーブ実行手段２００ａが処理実行のトリガとなる。スレー部実行手段２００ａからスレーブ実行手段２００ｂ、２００ａを経て、マスター実行手段１００に最終のメッセージが送信されて完了する。ここで、メッセージのデータ構造は図２（ｂ）に示したものと同様の構成のものを用いることができる。

図１５の処理フローに見るように、実施の形態１における図２に示す処理フローと比較して、トレースデータ６１０として保存の対象となるデータ量がさらに削減できることがわかる。

ここで、図１４のステップＳＴ２２０において、自ＣＰＵに割り当てられたメッセージＩＤを付加することを説明したが、これは分散システムを構成する実行手段間で予め処理のトリガとなった場合のメッセージＩＤを割り当てておくことによって実現できる。あるいは上述のトレーストリガ制御部７００によって設定することもできる。
また、他の実行手段が使用するメッセージＩＤも含めて、各実行手段でメッセージＩＤの割り当て情報を共有することもできる。この場合、図１４のステップＳＴ２１０における判断にこのメッセージＩＤ割り当て情報を利用することができ、判断を確実に行うことができる。すなわち、例えば、アプリケーション部２１０ａが生成したデータが受信したメッセージのアプリケーションデータを更新したものであり、既に他の実行手段に割り当てられたメッセージＩＤが含まれていれば、受信したメッセージが他の実行手段がトリガとなったメッセージであることの判定が容易となる。

正常動作時通信回数テーブル５１０にはスレーブ実行手段がトリガとなる処理においても対応付けたメッセージＩＤとマスター実行手段１００に最終送信される時のＣＰＵ間通信回数との情報も用意しておく。
また、本実施の形態におけるスレーブ実行手段２００ａの構成は、分散システムに接続されるスレーブ実行手段すべてについて同様に構成することもできる。これにより、いずれのスレーブ実行手段もスレーブトリガ処理を行うことが可能となり、分散システムのより精細な解析が可能となる。
あるいは、１つ以上幾つかのスレーブ実行手段を選択して本実施の形態におけるスレーブ実行手段２００ａと同様の構成とすることもできる。これにより、特定のスレーブ実行手段がトリガ処理を行うようにすることができ、必要なスレーブ実行手段からの処理に絞った精細な解析を効率よく行うことができる。

本実施の形態によれば、スレーブ実行手段がトレースのトリガとした分散システムの動作を実現することができる。また、本実施の形態においてもマスター実行手段１００にてトレースデータを集約して保存することができる。また、解析に必要なトレースデータに絞ってトレースデータを発生して保存することができ、分散システムのきめ細かな解析を可能にする。さらに、トレースデータ保存に必要となる記憶領域の一層の削減が可能となる。

実施の形態６．
以上の実施の形態においては、マスター実行手段１００が他の実行手段から送信されたメッセージデータを受信したときに、エラー状態検出部１４０にてメッセージデータのＣＰＵ間通信回数が不正と判断されたメッセージのトレースデータのみを保存している。本実施の形態では、マスター実行手段１００においてエラー状態検出部１４０においてエラー判定を行なわず、受信したメッセージデータのトレースデータをすべて保存するものである。

マスター実行手段１００で準備可能なバッファ６００の容量が十分に大きい場合はこのような構成を取ることも可能である。
このように、マスター実行手段１００でエラー判定を実施することなく、受信したメッセージデータのトレースデータをすべて保存することで、ユーザはエラーの発生の有無にかかわらずマスター実行手段１００が受信したすべてのメッセージをチェックし、分散システムの動作を詳細に解析することが可能となり、正常時の動作も含めた処理を解析することにより、システムの動作解析の精度を向上できる。

１００マスター実行手段、１１０、２１０ａ、２１０ｂアプリケーション部、１２０ＩＤ付加部、１３０ＣＰＵ間通信回数付加部、１４０エラー状態検出部、１５０トレースデータ保存部、２００ａ、２００ｂスレーブ実行手段、２６０ａ、２６０ｂＣＰＵ間通信回数更新部、２７０ａ、２７０ｂ通信回数エラー判定部、２８０ａ、２８０ｂＣＰＵ識別子付加部、２９０ａ、２９０ｂスレーブトリガ処理部、４００ネットワーク、５００、６００バッファ（バッファ）、５１０正常動作時通信回数テーブル、６１０トレースデータ、７００トレーストリガ制御部。

Claims

ネットワークに接続された複数の実行手段を備え、前記複数の実行手段のそれぞれは前記ネットワークを介して他の実行手段にメッセージを送受信し所定の処理を実行する分散システムの動作解析を行うプログラムトレース装置において、
前記複数の実行手段の１つであるマスター実行手段は、前記所定の処理の実行指示データを含む第一のデータを生成する第一のアプリケーション部と、
前記第一のデータに前記実行指示データの処理内容ごとに予め割り当てられたメッセージＩＤを付加するＩＤ付加部と、
前記第一のデータにＣＰＵ間通信回数の所定の初期値を付加するＣＰＵ間通信回数付加部と、
受信した前記メッセージにおけるＣＰＵ間通信回数を正常な処理が行われた場合の所定の値と照合することにより、前記マスター実行手段が前記メッセージを送信してから前記複数の実行手段を経由した前記メッセージを受信するまでの処理においてエラーが発生していたことを検出するエラー状態検出部と、
前記エラー状態検出部の検出結果により、受信した前記メッセージからトレースデータを抽出して保存するトレースデータ保存部とを備え、前記マスター実行手段から送信される前記メッセージは前記第一のデータ、前記メッセージＩＤ及び前記ＣＰＵ間通信回数を含み、
前記複数の実行手段のうち前記マスター実行手段以外であるスレーブ実行手段は、
前記マスター実行手段より前記メッセージを受信した場合、受信した前記メッセージにおける前記第一のデータに格納された前記実行指示データに基づいて所定の処理を実行し第二のデータを生成する第二のアプリケーション部と、
受信した前記メッセージにおける前記ＣＰＵ間通信回数を更新して設定するＣＰＵ間通信回数更新部とを備え、前記スレーブ実行手段から送信される前記メッセージは前記第二のデータ、前記メッセージＩＤ及び前記ＣＰＵ間通信回数を含む、
プログラムトレース装置。
ＣＰＵ間通信回数付加部は、メッセージＩＤごとに、マスター実行手段がスレーブ実行手段に前記メッセージＩＤを有するメッセージを送信してから前記メッセージを受信するまでの複数の実行手段の間の通信回数として正常な場合の値である正常動作時通信回数のうち最大の値を所定の初期値として設定し、
ＣＰＵ通信回数更新部は、スレーブ実行手段が受信したメッセージにおけるＣＰＵ間通信回数を１減じて更新し、
エラー状態検出部は、受信した前記メッセージにおけるＣＰＵ間通信回数が負の値である場合にエラーと判定することを特徴とする請求項１に記載のプログラムトレース装置。
マスター実行手段は、メッセージＩＤごとに、前記マスター実行手段がスレーブ実行手段に前記メッセージＩＤを有するメッセージを送信してから前記メッセージを受信するまでの複数の実行手段の間の通信回数として正常な場合の値である正常動作時通信回数を保持する正常動作時通信回数テーブルを備え、
エラー状態検出部は、前記マスター実行手段が前記メッセージを受信したとき、前記メッセージに含まれるＣＰＵ間通信回数と、前記正常動作時通信回数テーブルにおける前記メッセージにおける前記メッセージＩＤに対する前記正常動作時通信回数とを照合することにより、エラーが発生したことを検出することを特徴とする請求項１に記載のプログラムトレース装置。
スレーブ実行手段は、受信したメッセージにおけるＣＰＵ間通信回数が負の値であるときにエラーと判定する通信回数エラー判定部を備えたことを特徴とする請求項２に記載のプログラムトレース装置。
複数の実行手段は、それぞれ個別のＣＰＵ識別子を有し、
通信回数エラー判定部がエラーと判定したときに、受信したメッセージに前記スレーブ実行手段に前記メッセージを送信した前記複数の実行手段のいずれかである実行手段が有するＣＰＵ識別子および前記スレーブ実行手段が有するＣＰＵ識別子を付加して、マスター実行手段に送信することを特徴とする請求項４に記載のプログラムトレース装置。
スレーブ実行手段は、前記スレーブ実行手段からプログラムのトレースを開始する処理であるスレーブトリガ処理を行うか否かを判定し、前記スレーブトリガ処理を行うと判定した場合には、前記マスター実行手段が初期値を付加する処理に替えて、前記スレーブ実行手段における第二のアプリケーション部が生成した第二のデータに、前記スレーブ実行手段に予め割り当てられたメッセージＩＤおよびＣＰＵ通信回数の所定の初期値を付加するスレーブトリガ処理部を備えたことを特徴とする請求項１に記載のプログラムトレース装置。
複数の実行手段のいずれがトレース実行のトリガとなるかを設定するトレーストリガ制御部を備えたことを特徴とする請求項６に記載のプログラムトレース装置。