ネットワークに接続された複数の実行手段を備え、前記複数の実行手段のそれぞれは前記ネットワークを介して他の実行手段にメッセージを送受信し所定の処理を実行する分散システムの動作解析を行うプログラムトレース装置において、前記複数の実行手段の1つであるマスター実行手段は、前記所定の処理の実行指示データを含む第一のデータを生成する第一のアプリケーション部と、前記第一のデータに前記実行指示データの処理内容ごとに予め割り当てられたメッセージIDを付加するID付加部と、前記第一のデータにCPU間通信回数の所定の初期値を付加するCPU間通信回数付加部と、受信した前記メッセージにおけるCPU間通信回数を正常な処理が行われた場合の所定の値と照合することにより、前記マスター実行手段が前記メッセージを送信してから前記複数の実行手段を経由した前記メッセージを受信するまでの処理においてエラーが発生していたことを検出するエラー状態検出部と、前記エラー状態検出部の検出結果により、受信した前記メッセージからトレースデータを抽出して保存するトレースデータ保存部とを備え、前記複数の実行手段のうち前記マスター実行手段以外であるスレーブ実行手段は、受信した前記メッセージにおける前記実行指示データに基づいて所定の処理を実行し第二のデータを生成する第二のアプリケーション部と、前記第二のデータに前記メッセージにおける前記CPU間通信回数を更新して設定するCPU間通信回数更新部とを備えたプログラムトレース装置。CPU間通信回数付加部は、メッセージIDごとに、マスター実行手段がスレーブ実行手段に前記メッセージIDを有するメッセージを送信してから前記メッセージを受信するまでの複数の実行手段の間の通信回数として正常な場合の値である正常動作時通信回数のうち最大の値を所定の初期値として設定し、CPU通信回数更新部は、スレーブ実行手段が受信したメッセージにおけるCPU間通信回数を1減じて更新し、エラー状態検出部は、受信した前記メッセージにおけるCPU間通信回数が負の値である場合にエラーと判定することを特徴とするプログラムトレース装置。マスター実行手段は、メッセージIDごとに、前記マスター実行手段がスレーブ実行手段に前記メッセージIDを有するメッセージを送信してから前記メッセージを受信するまでの複数の実行手段の間の通信回数として正常な場合の値である正常動作時通信回数を保持する正常動作時通信回数テーブルを備え、エラー状態検出部は、前記マスター実行手段が前記メッセージを受信したとき、前記メッセージに含まれるCPU間通信回数と、前記正常動作時通信回数テーブルにおける前記メッセージにおける前記メッセージIDに対する前記正常動作時通信回数とを照合することにより、エラーが発生したことを検出することを特徴とする請求項1記載のプログラムトレース装置。スレーブ実行手段は、受信したメッセージにおけるCPU間通信回数が負の値であるときにエラーと判定する通信回数エラー判定部を備えたことを特徴とする請求項2記載のプログラムトレース装置。複数の実行手段は、それぞれ個別のCPU識別子を有し、通信回数エラー判定部がエラーと判定したときに、受信したメッセージに前記スレーブ実行手段に前記メッセージを送信した前記複数の実行手段のいずれかである実行手段が有するCPU識別子および前記スレーブ実行手段が有するCPU識別子を付加して、マスター実行手段に送信することを特徴とする請求項4記載のプログラムトレース装置。スレーブ実行手段は、前記スレーブ実行手段からトレースを起動するスレーブトリガ処理を行うか否かを判定し、前記スレーブトリガ処理を行うと判定した場合には、前記スレーブ実行手段における第二のアプリケーション部が生成した第二のデータに、前記スレーブ実行手段に予め割り当てられたメッセージIDおよびCPU通信回数の所定の初期値を付加するスレーブトリガ処理部を備えたことを特徴とする請求項1に記載のプログラムトレース装置。複数の実行手段のいずれがトレース実行のトリガとなるかを設定するトレーストリガ制御部を備えたことを特徴とする請求項6記載のプログラムトレース装置。しかしながら、特許文献1では、分散システムにおける全ての組み込み機器、計算機システムのそれぞれでトレースデータを保存しているため、それぞれに記憶領域が必要となる。そのため、記憶領域のない、あるいは充分な容量の記憶領域が確保できない組み込み機器等を含む分散システムには適用できなかった。また、分散システム全体の動作解析の為にそれぞれの組込み機器、計算機システムで保存されたトレースデータを統合する必要があった。この発明は、上述のような問題を解決するためになされたもので、第一の目的は、記憶領域のない、あるいは充分な記憶領域の確保ができない組み込み機器等を含む分散システムにも適用可能なプログラムトレース装置を得ることである。第二の目的は、複数の組み込み機器、計算機システムで構成される分散システムにおいて、トレースデータを一つの組み込み機器または計算機システムに集約して保存するプログラムトレース装置を得ることである。この発明に係るプログラムトレース装置は、ネットワークに接続された複数の実行手段を備え、前記複数の実行手段のそれぞれは前記ネットワークを介して他の実行手段にメッセージを送受信し所定の処理を実行する分散システムの動作解析を行うプログラムトレース装置において、前記複数の実行手段の1つであるマスター実行手段は、前記所定の処理の実行指示データを含む第一のデータを生成する第一のアプリケーション部と、前記第一のデータに前記実行指示データの処理内容ごとに予め割り当てられたメッセージIDを付加するID付加部と、前記第一のデータにCPU間通信回数の所定の初期値を付加するCPU間通信回数付加部と、受信した前記メッセージにおけるCPU間通信回数を正常な処理が行われた場合の所定の値と照合することにより、前記マスター実行手段が前記メッセージを送信してから前記複数の実行手段を経由した前記メッセージを受信するまでの処理においてエラーが発生していたことを検出するエラー状態検出部と、前記エラー状態検出部の検出結果により、受信した前記メッセージからトレースデータを抽出して保存するトレースデータ保存部とを備え、前記複数の実行手段のうち前記マスター実行手段以外であるスレーブ実行手段は、受信した前記メッセージにおける前記実行指示データに基づいて所定の処理を実行し第二のデータを生成する第二のアプリケーション部と、前記第二のデータに前記メッセージにおける前記CPU間通信回数を更新して設定するCPU間通信回数更新部とを備えたものである。この発明によれば、記憶領域のない、あるいは充分な記憶領域の確保できない組み込み機器等を含む分散システムにも適用可能なプログラムトレース装置を得ることができる。また、複数の組み込み機器、計算機システムで構成される分散システムにおいて、トレースデータを一つの組み込み機器または計算機システムに集約して保存するプログラムトレース装置を得ることができる。実施の形態1.この発明を実施するための実施の形態1における分散システムのプログラムトレース装置の構成を図1に示す。同図に示すように、分散システムはネットワーク400に複数の実行手段100、200a、200bが接続される。一つの実行手段をマスター実行手段100、それ以外の実行手段をスレーブ実行手段と呼ぶことにする。図1には、2つのスレーブ実行手段200aおよび200bが接続されている構成例を示す。しかし、この構成に限るものではない。すなわち、マスター実行手段100に加えて、スレーブ実行手段として1つ以上が接続されているものであればよい。また、これは以下のすべての実施の形態においても同様である。ここでは説明の都合上、図1に示すように、スレーブ実行手段として200a、200bが接続された構成例について示す。本実施の形態における分散システムでは、マスター実行手段100がスレーブ実行手段200a、200bのそれぞれにトレース処理を指示するトリガとなるメッセージデータを送信し、指示したトレース処理に対する最終の処理が完了したときにはマスター実行手段100にメッセージデータが返信されるものを対象とする。マスター実行手段がトレース処理のトリガとなるものをマスタートリガ処理と呼ぶことにする。本発明における実行手段とは、1つ以上のシーケンス制御機能などが設計されたアプリケーション部を有し、入力される実行指示に基づいて所定の処理を実行するものである。これは例えば、シーケンス制御専用のマイクロコンピュータを搭載した組み込み機器、あるいは計算機システムを指す。マスター実行手段100は、正常動作時通信回数テーブル510およびトレースデータ610を記憶するバッファ記憶領域500および600を内蔵する。あるいは、マスター実行手段100が、正常動作時通信回数テーブル510およびトレースデータ610を記憶するためのバッファとのインタフェースを有するものであってもよい。一方、スレーブ実行手段200a、200bは、シーケンス制御専用のマイクロコンピュータを搭載した組み込み機器など所定の処理を行うのに必要な領域の記憶領域以外には余分な記憶領域がない、あるいは記憶容量に余裕のないものである。また、ネットワーク400は、IEEE1394規格に準拠したシリアルバスを用いたネットワーク、LAN、WANに代表される複数のコンピュータを接続するコンピュータネットワークなどを指す。次に、マスター実行手段100の構成を説明する。マスター実行手段100は、アプリケーション部110、ID付加部120、CPU間通信回数付加部130、エラー状態検出部140、トレースデータ保存部150、正常動作時通信回数テーブル510を有するバッファ記憶領域500、トレースデータ610を保存するバッファ記憶領域600を含む。また、マスター実行手段100には図示しない通信インタフェースが備えられ、ネットワーク400を介してメッセージを送受信する。アプリケーション部110は、スレーブ実行手段200a、200bへの実行指示データを含むアプリケーションデータ第一のデータを発行する。ID付加部120は、アプリケーション部110から発行された第一のデータにメッセージIDを付加する。また、CPU間通信回数付加部130は、ID付加部120の出力にCPU間通信回数として所定の初期値を付加する。次いで、マスター実行手段100はメッセージデータを、通信インタフェースを介してネットワーク400上に送信する。エラー状態検出部140はネットワーク400を介してマスター実行手段100が受信したメッセージデータに含まれるCPU間通信回数を基に、正常動作時通信回数テーブル510を参照してCPU間通信回数が正常であるかを判定する。ここで正常動作時通信回数テーブル510には、予めメッセージIDに対応付けて正常動作が行われた場合の通信回数正常動作時通信回数が保持される。トレースデータ保存部150はエラー状態検出部140の判定結果により、マスター実行手段100が受信したメッセージからトレースデータ610を抽出してバッファ600に保存する。実行指示データとは、この分散システムにおける処理実行に関する情報である。実行指示データには、例えば、対象となる実行手段に関する情報、その実行手段が有するアプリケーション部での処理内容を指す情報とその処理を行なう際に用いられる引数の情報、データなどが含まれている。これは例えば、それぞれの実行手段における所定の処理を実行するために定義されたプログラムにおける関数名、シーケンス番号等、およびそれらの処理を行なう際に用いられる引数の情報、データなどであってもよい。また、メッセージIDは、アプリケーション部110が発行する第一のデータに対して、そのデータが有する処理内容に対応付けたものである。これは同じ処理内容であっても引数など付随するデータによって正常動作時の通信回数が異なるものについてはそれぞれ別のメッセージIDとする。メッセージIDは単純な番号であっても処理内容を表す関数名などを示す文字列等であってもよい。正常動作時通信回数テーブル510は、バッファ500に記憶されており、トレースデータはバッファ600に随時保存されていくものである。これらバッファ500および600はハードディスク、フラッシュメモリ、メモリカード、DVDなどの外部記憶装置内で構成されてもよい。あるいは、マスター実行手段100が搭載するプロセッサが内蔵するメモリを用いてもよい。次に、スレーブ実行手段200a、200bの構成を説明する。スレーブ実行手段200aは、受信したメッセージデータの実行指示データに基づいて所定の処理を実行し、アプリケーションデータ第二のデータを出力する第二のアプリケーション部210a、及び前記第二のデータに当該メッセージIDと当該CPU間通信回数に所定の値として1を加算して更新したCPU間通信回数とを付加したメッセージデータを送信するCPU間通信回数更新部260aが含まれる。同様に、スレーブ実行手段200bは、受信したメッセージデータの実行指示データに基づいて所定の処理を実行し、第二のデータを出力する第二のアプリケーション部210b、及び前記第二のデータに当該メッセージIDと当該CPU間通信回数に所定の値として1を加算して更新したCPU間通信回数とを付加したメッセージデータを送信するCPU間通信回数更新部260bで構成される。図2aに、本実施の形態の構成において、各実行手段間でやり取りするメッセージデータの流れを示したシーケンスを例示する。また、メッセージのデータ構造を同図bに示す。以下、このシーケンス図の流れに沿って本実施の形態のトレースデータを抽出する動作について説明する。まず、マスター実行手段100のアプリケーション部110が実行指示データを有する第一のデータData1を生成し出力する。次に、ID付加部120で第一のデータに対して処理内容に対応付けたメッセージIDを付加する。ここでは、メッセージIDとして単純な番号を付加する例として1を付加する。さらに、CPU間通信回数付加部130でメッセージIDの付加された第一のデータにCPU間通信回数として所定の初期値、例えば、1を付加する。このメッセージIDとCPU間通信回数の初期値が付加された第一のデータをメッセージデータとしてネットワーク400上に送信する。このメッセージデータでのメッセージIDとCPU間通信回数の組み合わせをメッセージID、CPU間通信回数=1、1と示すことにする。このメッセージデータの送信先の実行手段であるスレーブ実行手段200aが受信し、アプリケーション部210aによって所定の処理を行なう。この処理が完了し、ネットワーク400を介して、マスター実行手段100へ第二のデータData2を送信するときに、CPU間通信回数更新部260aによって受信した当該メッセージID1と、受信した当該CPU間通信回数1に所定の値として1を加算してCPU間通信回数を更新してマスター実行手段100に送信する。この時メッセージID、CPU間通信回数=1、2となる。また、上記とは別の処理として、スレーブ実行手段200aが別のスレーブ実行手段200bにネットワーク400を介して通信するときの説明を行なう。この場合、アプリケーション部210aによって生成される第二のデータData3に、CPU間通信回数更新部260aによって受信した当該メッセージID1を付加する。また、受信した当該CPU間通信回数1に所定の値として1を加算してCPU間通信回数を更新する。次いで、メッセージをスレーブ実行手段200bに送信する。この時メッセージID、CPU間通信回数=1、2となる。スレーブ実行手段200bはスレーブ実行手段200aからのメッセージデータを受信し、アプリケーション部210bによって所定の処理を行なう。この処理が完了し、スレーブ実行手段200aに第二のデータData4を送信する前に、CPU間通信回数更新部260bによって受信したメッセージにおけるメッセージID1を付加する。さらに、受信したメッセージにおけるCPU間通信回数2に所定の値として1を加算してCPU間通信回数を更新する。次いで、ネットワーク400を介してスレーブ実行手段200aに送信する。この時メッセージID、CPU間通信回数=1、3となる。スレーブ実行手段200aは、スレーブ実行手段200bからのメッセージデータを受信し、アプリケーション部210aによって所定の処理を行なう。ここでのアプリケーション部210aでの処理として、ある処理で第二のデータData5をマスター実行手段100に送信するものと、これとは別の処理で第二のデータData6をマスター実行手段100に送信するものがあった場合、どちらもCPU間通信回数更新部260aによって更新されるCPU間通信回数は4メッセージID、CPU間通信回数=1、4となる。すなわち、アプリケーション部210aの処理内容が異なる場合であっても、メッセージIDおよびCPU通信回数は同じ値となる。このように、アプリケーション部210aの処理内容に依存せず、送信されたメッセージIDを伝達し、実行手段で受信する度にCPU通信回数を順次更新したメッセージデータが伝達されていく。また、マスター実行手段100が新たにアプリケーション部110から実行指示データを有する第一のデータData7を生成した場合は、ID付加部120で第一のデータにメッセージID2を付加して上述と同様の処理を行なうこととなる。図3に、正常動作時通信回数テーブル510の構成例を示す。正常動作時通信回数テーブル510は、分散システムの動作解析を行なう際に、メッセージIDに対して正常に通信を実施した場合にマスター実行手段100に返ってくるまでの通信回数として正しい回数を正常動作時通信回数として記憶したものである。図3において、例えばメッセージIDが1の処理では、マスター実行手段100に別のスレーブ実行手段から送信されるときの通信回数は2または4の場合があることを示す。同じようにメッセージIDが2の処理ではマスター実行手段100に別のスレーブ実行手段から送信されるときの通信回数は2または6の場合があることを示す。第一のデータに割り当てられるメッセージIDと処理内容は予め一意に定めて設計され、上記設計の仕様に従って、メッセージIDとそれに対応付けた正常動作時の通信回数とのテーブルを用意する。図4に、マスター実行手段100が他の実行手段からのメッセージを受信した際のエラー状態検出部140およびトレースデータ保存部150の処理フローを示す。マスター実行手段100は、スレーブ実行手段から送信されたメッセージを受信しステップST010、次いでエラー状態検出部140は受信したメッセージデータにあるメッセージIDに対応する正常動作時通信回数を正常動作時通信回数テーブル510から取得するステップST020。次に、エラー状態検出部140は、受信したメッセージにおけるCPU間通信回数が、ステップST020にて取得した正常動作時通信回数に該当する複数の値がある場合はそのいずれかに一致するか否かを判定し、YesかNoかの判定結果を出力するステップST030。ここでYesは、受信したメッセージデータにあるCPU間通信回数が、ステップST020にて取得した正常動作時通信回数に該当することを意味し、Noは該当しないことを示す。エラー状態検出部140は、ステップST030の結果がYesであれば、アプリケーション部110に受信したメッセージデータにあるデータを供給するステップST060。一方、ステップST030の結果がNoであれば、エラーがあったと判定してトレースデータ保存部150にエラーがあったことを通知するステップST040。トレースデータ保存部150はエラーがあったときに受信したメッセージデータと正常動作時通信回数テーブル510に記憶されている当該メッセージIDに対応付けられた正常動作時通信回数とから、動作解析に使用する情報をトレースデータとして抽出してバッファ600に保存するステップST050。トレースデータの例を図5に示す。同図に示すように、受信したメッセージデータのCPU間通信回数、そのメッセージデータにおけるアプリケーションデータ、メッセージID、正常動作時通信回数を保存する。これら全てをトレースデータとして保存せず、例えばメッセージ内のデータを除くなどして保存する情報量を削減してもよい。次いで、ステップST030の結果がYesの場合と同様、アプリケーション部110に受信したメッセージデータにあるデータを供給するステップST060本実施の形態によれば、マスター実行手段100のみで対象の処理フローが正常な通信回数で処理されているかの判定を行ない、その判定結果とマスター実行手段100が受信したメッセージデータとからトレースデータを抽出して保存することができる。そのため、マスター実行手段100でトレースデータ集約させて保存することが可能となり、スレーブ実行手段にトレースデータを保存する記憶領域を持つ必要がなくなるという効果を奏する。さらに、トレースデータが集約されて保存されるので動作解析の度に複数のトレースデータを統合する手間が不要となる。実施の形態2.実施の形態1では、ID付加部120によって第一のデータの処理内容に対応したメッセージIDを付加し、正常動作時通信回数テーブル510がメッセージIDに対応付けたCPU間通信回数を用意していたが、実施の形態2ではメッセージIDの代わりに、第一データが発行される毎に割り当てるシーケンス番号をID付加部120によって付加し、トレースデータとしてシーケンス番号を保存対象に含めるものである。本実施の形態におけるプログラムトレース装置の構成は図1に示したものと同様である。本実施の形態においては、アプリケーション部110が第一のデータを発行する度に、ID付加部120が個別のシーケンス番号を割り当てて付加する。また、正常動作時通信回数テーブル510にメッセージID毎に、このシーケンス番号を記憶させる。シーケンス番号は、例えば、1から番号順に設定するものとする。なお、このシーケンス番号はメッセージIDそれぞれにおいて個別であると共に、実行順序が判別可能であればよい。従って、1から採番するものに限られるものではなく、現在時刻、経過時間等に合わせて設定する方法でも良い。図6に本実施の形態における正常動作時通信回数テーブル510の構成例を示す。同図に示すように、メッセージIDに対応付けて保持された正常動作時通信回数に加えて、そのメッセージIDに対して付加されたシーケンス番号を記憶する領域が設けられており、ここにID付加部120が付加するシーケンス番号を記憶していく。本実施の形態では、メッセージデータに付加されるものがメッセージIDの代わりにシーケンス番号となるので、スレーブ実行手段200a、200bにおいてCPU間通信回数更新部260aまたは260bはアプリケーション部210aまたは210bが生成した第二のデータに、受信したメッセージにおけるシーケンス番号を付加する。さらに、受信したメッセージにおけるCPU間通信回数に所定の値として例えば、1を加算して更新したCPU間通信回数とを付加したメッセージデータを送信する。図7に、マスター実行手段100が他のスレーブ実行手段からメッセージデータを受信した際のエラー状態検出部140およびトレースデータ保存部150の処理フローを示す。マスター実行手段100が、スレーブ実行手段から送信されたメッセージを受信しステップST110、エラー状態検出部140は受信したメッセージにあるシーケンス番号に対応する正常動作時通信回数を正常動作時通信回数テーブル510から取得するステップST120。次いで、該当するシーケンス番号を正常動作時通信回数テーブル510から削除するステップST130。該当するシーケンス番号を正常動作時通信回数テーブル510から削除することで、正常動作時通信回数テーブル510の記憶領域を冗長に増加させないで済む効果を生む。次に、エラー状態検出部140は、受信したメッセージにおけるCPU間通信回数が、ステップST120にて取得した正常動作時通信回数に該当するかを判定し、YesかNoかの判定結果を出力するステップST140。以下のステップST140~ST170については実施の形態1における図4のステップST030~ST060と同様である。すなわち、エラー状態検出部140は、ステップST140の結果がYesであれば、アプリケーション部110に受信したメッセージデータにあるデータを供給するステップ170。一方、ステップST140の結果がNoであれば、エラーがあったと判定してトレースデータ保存部150にエラーがあったことを通知するステップST150。トレースデータ保存部150はエラーがあったときに受信したメッセージデータと正常動作時通信回数テーブル510に記憶されている当該メッセージIDに対応付けられた正常動作時通信回数とから動作解析に使用する情報をトレースデータとして抽出してバッファ600に保存するステップST160。ここで、トレースデータとして受信したメッセージデータのCPU間通信回数、アプリケーションデータ、メッセージID、シーケンス番号、正常動作時通信回数を保存する。これら全てをトレースデータとして保存せず、例えばアプリケーションデータを除くなどして保存する情報量を削減してもよい。本実施の形態によれば、実施の形態1と同様に、マスター実行手段100のみで対象の処理フローが正常な通信回数で処理されているかの判定を行ない、その判定結果とマスター実行手段100が受信したメッセージデータとからトレースデータを抽出して保存することができる。そのため、マスター実行手段100でトレースデータ集約させて保存することが可能となり、スレーブ実行手段にトレースデータを保存する記憶領域を持つ必要がなくなるという効果を奏する。さらに、トレースデータが集約されて保存されるので動作解析の度に複数のトレースデータを統合する手間がなくなるという効果を奏する。また、処理内容に対応付けたメッセージIDではなく、実行指示データの発行が行なわれる度にシーケンス番号を割り振って付加したメッセージデータを通信する。そのため、マスター実行手段100が受信したメッセージデータのCPU間通信回数が、該当する処理内容に対応付けた正常動作時通信回数に該当しない場合に、シーケンス番号を含めたトレースデータを保存することになる。これにより、動作解析時にシーケンス番号の情報によってエラーがあった処理を時系列に把握することが容易になるので、どのタイミングでエラーが発生しているかをより明確に把握することができ、より詳細な動作解析が可能になる。実施の形態3.以上の実施の形態においては、マスター実行手段100におけるCPU間通信回数付加部130でCPU間通信回数として例えば初期値1を付加し、スレーブ実行手段におけるCPU間通信回数更新部260aまたは260bにおいて、受信したメッセージにおけるCPU間通信回数に所定の値として1を加算してCPU間通信回数を更新していた。本実施の形態では、メッセージIDに対応付けられた正常動作時通信回数のうち一番大きいものを初期値とし、スレーブ実行手段におけるCPU間通信回数更新部において1減算してCPU間通信回数を更新するものである。図8に、本実施の形態におけるプログラムトレース装置の構成を示す。なお、図8において実施の形態1の図1と同一の符号のものにおいては、それぞれ実施の形態1の同一の符号のものと相当するものであるので、その説明を省略する。また、本実施の形態では各実行手段に個別のCPU識別子を割り当てる。CPU識別子は例えば、マスター実行手段100については100、スレーブ実行手段200a、200bはそれぞれ200a、200bとする。マスター実行手段100のCPU間通信回数付加部130は、ID付加部120から付加されたメッセージIDに対応する正常動作時通信回数を正常動作時通信回数テーブル510から読み出し、読み出された正常動作時通信回数のうち最も大きい回数をCPU間通信回数の初期値として付加したメッセージデータを送信する。これによって、正常に通信を行なっている時のメッセージデータにあるCPU間通信回数は常に0以上の値となる。スレーブ実行手段の構成について、スレーブ実行手段200aを例として説明する。以下の動作は他のスレーブ実行手段例えばスレーブ実行手段200bにおいても同様である。スレーブ実行手段200aには実施の形態1における図1の構成に加えて、通信エラー判定部270aが備えられる。通信回数エラー判定部270aは受信したメッセージにおけるCPU間通信回数が0以上であるか否かを判定する。CPU間通信回数が0以上であれば、そのままアプリケーション部210aにそのメッセージデータあるいはアプリケーションデータのみを供給する。一方、CPU間通信回数が負の値である場合は、その時点で処理が正常動作でないと判定して、メッセージデータに自己の実行手段すなわち、スレーブ実行手段200aのCPU識別子と当該メッセージデータを送信した実行手段のCPU識別子とを付加してマスター実行手段100に送信する。この場合、処理が正常動作でないため、スレーブ実行手段200aのアプリケーション部210aにそのメッセージデータあるいはアプリケーションデータを供給する必要はない。また、CPU間通信回数を例えば4bitの2進数の2の補数表現で与えるとした場合は、-1を1111と表現することになり、最上位bitを見ればCPU間通信回数が10進数形式で負の値であることを容易に判定することができる。各実行手段間でやり取りするメッセージデータの流れを示したシーケンス図の例を図9aに示す。また、同図bにスレーブ実行手段200aにおける通信回数エラー判定部270aにおいて、エラーと判定した場合のメッセージデータのデータ構造をデータ例と共に示す。図9aにおいて、スレーブ実行手段200aがスレーブ実行手段200bから第二のデータとしてData9を受けた時の動作を例として説明する図9aの白抜き矢印の部分。この時、通信回数エラー判定部270bは受信したメッセージにおけるCPU間通信回数が-1、すなわち負の値であることから、その時点で処理が正常動作でないと判断する。また、メッセージデータに自身のCPUすなわち、スレーブ実行手段200bのCPU識別子である200bとそのメッセージデータを送信した実行手段であるスレーブ実行手段200aの識別子である200aとを付加してマスター実行手段100に送信する。エラーと判定した時のデータの一例を図9bに示す。マスター実行手段100は、スレーブ実行手段200a、200bから送信されたメッセージを受信する。マスター実行手段100におけるエラー状態検出部140は、受信したメッセージデータのCPU間通信回数が0以上の場合はアプリケーション部110に受信したメッセージデータまたはアプリケーションデータを供給する。一方、CPU間通信回数が負の値である場合は、トレースデータ保存部150にエラーがあったことを通知する。トレースデータ保存部150は受信したメッセージデータと正常動作時通信回数テーブル510に記憶されている当該メッセージのメッセージIDに対応付けられた正常動作時通信回数とをトレースデータ610として抽出し、バッファ600に保存する。トレースデータ610の例として、受信したメッセージデータのCPU間通信回数、アプリケーションデータ、メッセージID、正常動作時通信回数に加え、エラーを検出した実行手段のCPU識別子と送信元CPU識別子を保存する。これら全てをトレースデータとして保存せず、例えばアプリケーションデータを除くなどして保存する情報量を削減しても構わない。このようにして、CPU間通信回数のエラー判定を各実行手段で行ない、エラーを検知したCPU番号から該当する実行手段が特定できるので、分散システムの動作解析においてエラー発生箇所の特定が容易となり、エラー発生時のより詳細なトレースデータを取得することが可能となる。本実施の形態においても、実施の形態1および2と同様の効果も得られる。実施の形態4.図10に、実施の形態4におけるプログラムトレース装置の構成を示す。なお、図10において実施の形態1における図1と同一の符号のものにおいては、それぞれ実施の形態1の同一の符号のものと相当するものであるので、その説明を省略する。また、本実施の形態では実施の形態3と同様に各実行手段に個別のCPU識別子を割り当てている。実施の形態1における図1の構成に加えて、各スレーブ実行手段200a、200bにおいて、CPU識別子付加部280a、280bが備えられる。スレーブ実行手段200a、200bでは、それぞれにおけるアプリケーション部210a、210bが第二のデータを出力した後に、CPU識別子付加部280a、280bにおいて当該実行手段のCPU識別子を順に付加する。図11にこの場合のメッセージデータの構成を示す。同図に示すように、メッセージにおいてCPU間通信回数、メッセージID、アプリケーションデータに加え、CPU識別子1、CPU識別子2、、PU識別子nCPU識別子nは付加された最終のCPU識別子を示すの情報が付加される。同図におけるCPU識別子1~nのかっこ内には付加されるCPU識別子情報の例を示す。この際、マスター実行手段100のエラー状態検出部140がエラーであると判定した場合にトレースデータ保存部150が抽出するデータとして、実施の形態1のトレースデータに加えて、メッセージデータに付加されているメッセージが経由したCPU番号の情報を保存する。以上述べたトレースデータを保存することで、エラー発生時に経由していた実行手段の経過情報を辿ることが可能となるので、分散システムの動作解析としてより詳細な解析が可能となる。本実施の形態は実施の形態2のようにシーケンス番号を用いたプログラムトレース装置においても適用でき、この場合も本実施の形態と同様の効果を奏する。本実施の形態によれば、上記のエラー発生時に経由していた実行手段の経過情報を辿ることが可能となる効果に加え、実施の形態1および2における効果も得られる。実施の形態5.以上の実施の形態1~4においてはマスター実行手段100がトレース実行のトリガとなるマスタートリガ処理ものである。本実施の形態ではスレーブ実行手段がトレース実行のトリガとなる場合においても適用可能なプログラムトレース装置の構成を示す。ここでスレーブ実行手段がトレース実行のトリガとなる、すなわち、トレースを起動する実行手段となる場合を以下、スレーブトリガ処理とよぶ。スレーブトリガ処理は、例えば、特定のスレーブ実行手段以降の処理が正しい動作であるか否か疑わしい場合に分散システムの解析を進める際に有効になる。すなわち、マスター実行手段から上記特定のスレーブ実行手段の手前までは処理が正常であることが判明しているか、あるいは確実である場合に、その特定のスレーブ実行手段以降の動作に対象を絞った分散システムの解析が容易となる。なお、本実施の形態においても、実施の形態1~4と同様に、マスター実行手段100から指示された、スレーブ実行手段に対する実行指示アプリケーション部210a、210b等に対する指示が各スレーブ実行手段に派生していき、それらの最終の処理が完了した場合には必ずマスター実行手段100にネットワーク400を介してメッセージが送信されるものを対象とする。本実施の形態におけるプログラムトレース装置の構成を図12に示す。なお、図12において実施の形態1における図1と同一の符号のものにおいては、それぞれ実施の形態1の同一の符号のものと相当するものであるので、その説明を省略する。以下、スレーブ実行手段200aを例に説明する。スレーブ実行手段200aには実施の形態1における図1の構成に加えて、スレーブトリガ処理部290aが備えられる。スレーブ実行手段200aにおけるアプリケーション部210aは実施の形態1~4と同様に、他の実行手段から送信されたメッセージにおけるアプリケーションデータ第一または第二のデータに基づいて所定の処理を実行してアプリケーションデータ第二のデータを発行する。本実施の形態では、いずれかのスレーブ実行手段がトレースのトリガとなる場合には、マスター実行手段100がトリガとなるトレースは行われないものとする。これは例えば、マスター実行手段100におけるアプリケーション部110、スレーブ実行手段200a、200bにおけるアプリケーション部210a、210b等に設定される実行指示を実施するためのプログラムにおいて、予め上記の排他処理が可能となるようにプログラムを作成しておくことにより実現できる。あるいは、図13に示すように、分散システムにおいてトレースのトリガ処理をいずれの実行手段が行うか設定するトレーストリガ制御部700を設けてもよい。このトレーストリガ制御部700が例えばディスレイ、キーボード等からなる入力手段図示せずを備え、分散システムの操作者がこの入力手段を通じて、トレーストリガとなる実行手段の設定を行うようにしてもよい。あるいは、トレーストリガ制御部700に予めプログラム等を組み込んでおき、このプログラムを動作させることにより、トレーストリガとなる実行手段を設定するものであってもよい。なお、図13において、トレーストリガ制御部700はネットワーク400を経由して、各実行手段に接続される構成例を示したが、各実行手段にネットワークを介さずに接続されるものであってもよい。上述のように、本実施の形態においてスレーブトリガ処理が行われる場合には、マスタートリガ処理は行われない。そのためマスター実行手段100からのメッセージにトレースのためのメッセージIDは含まれないことになる。この場合、マスター実行手段100から送信されるのは、スレーブ実行手段200a、200b等のアプリケーション部210a、210b等に対する指示データとなる。ここで、アプリケーションデータまたはメッセージのデータを通信インタフェースがネットワーク400に送受信するためのネットワークアドレス等は、この発明の実施の形態1~5におけるメッセージIDとは異なる情報である。すなわち、各実行手段間の通信機能は本実施の形態で述べるメッセージIDに依存せずに実現される。次に、動作について説明する。以下、図12に沿って説明するが、図13の場合でも同様である。図12において、スレーブトリガ処理部290aは、アプリケーション処理部210aの処理に続いて実行される。図14にスレーブトリガ処理部290aおよびCPU間通信回数更新部260aの処理フローを示す。スレーブトリガ処理部290aは上述のアプリケーション処理部の処理に続いて起動されるステップST200。次に、ステップST210において、自CPU、すなわち、この場合はスレーブ実行手段200aが、トレース実行のトリガであるか否かを判定する。自CPUがトレース実行のトリガであるとは、例えば、図13に示したトレーストリガ制御部700から設定される情報によって知ることができる。あるいは、トレーストリガ制御部700を用いる方法以外に、アプリケーション部210aが生成するアプリケーションデータ第二のデータ中の所定の位置に設定したフラグのONまたはOFFの情報によって判断することができる例えば、ONは処理実行のトリガである旨予め定めておく。あるいは、スレーブ実行手段200におけるアプリケーション部200aに処理実行のトリガであることを設定する命令を所定の位置に埋め込んでおき、上記命令の実行によって前述のフラグをONまたはOFFにする方法もある。あるいは、スレーブ実行手段200aにディスレイ、キーボード等からなる入力手段を備え、分散システムの操作を行う操作者からのコマンド等の入力情報によって、処理実行のトリガであることを指定される場合もある。さらに、マスター実行手段100からメッセージ等による通信によって処理実行のトリガとなることが通知されるものであってもよい。ステップST210の判定結果がYesであれば、ステップST220に進む。ステップST220において、自CPUすなわちスレーブ実行手段200aに予め割り当てられたメッセージIDを、上述のアプリケーションデータ第二のデータに付加する。次いでCPU間通信回数の初期値を付加するステップST230。ステップST210の判定結果がNoであれば、自CPUがトリガではないことになる。この場合は、マスター実行手段100がトレースのトリガである場合と、他のスレーブ実行手段がトレースのトリガである場合の2通りがある。ここで、いずれの実行手段もトリガとならない場合については本発明の対象外であるため説明を省略する。まず、マスター実行手段100がトレーストリガ処理となる場合マスタートリガ処理、ステップST250において受信したメッセージのメッセージIDをメッセージに付加した後、CPU間通信回数更新部260aにメッセージを供給する。CPU間通信回数更新部260aはステップST260において、実施の形態1~4と同様に、CPU間通信回CPU間通信回数を更新する。次に、他のスレーブ実行手段がスレーブトリガ処理を行う場合は、該当するスレーブ手段からのメッセージにはそのスレーブ実行手段が設定したメッセージIDおよびCPU通信回数が含まれるステップST220、ST230参照。従って、ステップST250、ST260において、上述のマスタートリガ処理の場合と同様に、受信したメッセージのメッセージIDをメッセージ受信したメッセージ中のアプリケーションデータをアプリケーション部210aが作成した第二のデータで更新したものに付加した後、CPU間通信回数更新部260aにより、CPU間通信回数が更新される。ステップST230、ST260いずれの場合も、次いでステップT240に進み、発行されたメッセージは通信インタフェースを介してネットワーク400に送信される。図15に、本実施の形態における、スレーブ実行手段200aが処理実行のトリガとなる場合に、各実行手段間でやり取りするメッセージデータの流れを示したシーケンス図の例を示す。同図において、スレーブ実行手段200aが処理実行のトリガとなる。スレー部実行手段200aからスレーブ実行手段200b、200aを経て、マスター実行手段100に最終のメッセージが送信されて完了する。ここで、メッセージのデータ構造は図2bに示したものと同様の構成のものを用いることができる。図15の処理フローに見るように、実施の形態1における図2に示す処理フローと比較して、トレースデータ610として保存の対象となるデータ量がさらに削減できることがわかる。ここで、図14のステップST220において、自CPUに割り当てられたメッセージIDを付加することを説明したが、これは分散システムを構成する実行手段間で予め処理のトリガとなった場合のメッセージIDを割り当てておくことによって実現できる。あるいは上述のトレーストリガ制御部700によって設定することもできる。また、他の実行手段が使用するメッセージIDも含めて、各実行手段でメッセージIDの割り当て情報を共有することもできる。この場合、図14のステップST210における判断にこのメッセージID割り当て情報を利用することができ、判断を確実に行うことができる。すなわち、例えば、アプリケーション部210aが生成したデータが受信したメッセージのアプリケーションデータを更新したものであり、既に他の実行手段に割り当てられたメッセージIDが含まれていれば、受信したメッセージが他の実行手段がトリガとなったメッセージであることの判定が容易となる。正常動作時通信回数テーブル510にはスレーブ実行手段がトリガとなる処理においても対応付けたメッセージIDとマスター実行手段100に最終送信される時のCPU間通信回数との情報も用意しておく。また、本実施の形態におけるスレーブ実行手段200aの構成は、分散システムに接続されるスレーブ実行手段すべてについて同様に構成することもできる。これにより、いずれのスレーブ実行手段もスレーブトリガ処理を行うことが可能となり、分散システムのより精細な解析が可能となる。あるいは、1つ以上幾つかのスレーブ実行手段を選択して本実施の形態におけるスレーブ実行手段200aと同様の構成とすることもできる。これにより、特定のスレーブ実行手段がトリガ処理を行うようにすることができ、必要なスレーブ実行手段からの処理に絞った精細な解析を効率よく行うことができる。本実施の形態によれば、スレーブ実行手段がトレースのトリガとした分散システムの動作を実現することができる。また、本実施の形態においてもマスター実行手段100にてトレースデータを集約して保存することができる。また、解析に必要なトレースデータに絞ってトレースデータを発生して保存することができ、分散システムのきめ細かな解析を可能にする。さらに、トレースデータ保存に必要となる記憶領域の一層の削減が可能となる。実施の形態6.以上の実施の形態においては、マスター実行手段100が他の実行手段から送信されたメッセージデータを受信したときに、エラー状態検出部140にてメッセージデータのCPU間通信回数が不正と判断されたメッセージのトレースデータのみを保存している。本実施の形態では、マスター実行手段100においてエラー状態検出部140においてエラー判定を行なわず、受信したメッセージデータのトレースデータをすべて保存するものである。マスター実行手段100で準備可能なバッファ600の容量が十分に大きい場合はこのような構成を取ることも可能である。このように、マスター実行手段100でエラー判定を実施することなく、受信したメッセージデータのトレースデータをすべて保存することで、ユーザはエラーの発生の有無にかかわらずマスター実行手段100が受信したすべてのメッセージをチェックし、分散システムの動作を詳細に解析することが可能となり、正常時の動作も含めた処理を解析することにより、システムの動作解析の精度を向上できる。