(57)【特許請求の範囲】
【請求項１】
外部装置から送信される情報を受信し、所定の処理を行った後に他の外部装置へその処理後の情報を送信する通信装置におけるフレーム同期システムであって、
前記通信装置は前記外部装置から送信される情報を受信しその情報をバスを介して内部の受信手段へ送信する送信手段と、
前記送信手段から送信される情報を受信し、所定の処理を行った後に前記他の外部装置へその処理後の情報を送信する前記受信手段とを含んでおり、
前記送信手段は少なくとも前記情報とは非同期のフレーム同期信号を定期的に前記受信手段へ送信し、
前記受信手段は前記フレーム同期信号を受信すると所定の処理を開始し、
前記送信手段は予め次の同期フレームで処理される情報まで含めて前記情報を前記受信手段へ送信し、
前記受信手段は前記複数の情報を格納するメモリを有しており、今回の同期フレームで処理されるべき情報が処理できない場合、前記メモリから今回の同期フレームで処理されるべき情報を読出し処理することを特徴とするフレ−ム同期システム。
【請求項２】
外部装置から送信される情報を受信し、所定の処理を行った後に他の外部装置へその処理後の情報を送信する通信装置におけるフレーム同期方法であって、
前記通信装置は前記外部装置から送信される情報を受信しその情報をバスを介して内部の受信手段へ送信する送信手段と、
前記送信手段から送信される情報を受信し、所定の処理を行った後に前記他の外部装置へその処理後の情報を送信する前記受信手段とを含んでおり、
前記送信手段は少なくとも前記情報とは非同期のフレーム同期信号を定期的に前記受信手段へ送信し、
前記受信手段は前記フレーム同期信号を受信すると所定の処理を開始するフレーム同期信号受信ステップを含み、
前記送信手段は予め次の同期フレームで処理される情報まで含めて前記情報を前記受信手段へ送信し、
前記受信手段は前記複数の情報を格納するメモリを有しており、今回の同期フレームで処理されるべき情報が処理できない場合、前記メモリから今回の同期フレームで処理されるべき情報を読出し処理するメモリ読出しステップを含むことを特徴とするフレ−ム同期方法。
【請求項３】
外部装置から送信される情報を受信し、所定の処理を行った後に他の外部装置へその処理後の情報を送信する通信装置におけるフレーム同期プログラムであって、
前記通信装置は前記外部装置から送信される情報を受信しその情報をバスを介して内部の受信手段へ送信する送信手段と、
前記送信手段から送信される情報を受信し、所定の処理を行った後に前記他の外部装置へその処理後の情報を送信する前記受信手段とを含んでおり、
前記送信手段は少なくとも前記情報とは非同期のフレーム同期信号を定期的に前記受信手段へ送信し、
前記受信手段は前記フレーム同期信号を受信すると所定の処理を開始するフレーム同期信号受信ステップを含み、
前記送信手段は予め次の同期フレームで処理される情報まで含めて前記情報を前記受信手段へ送信し、
前記受信手段は前記複数の情報を格納するメモリを有しており、今回の同期フレームで処理されるべき情報が処理できない場合、前記メモリから今回の同期フレームで処理されるべき情報を読出し処理するメモリ読出しステップを含むことを特徴とするフレ−ム同期プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はフレーム同期システム及び同期方法並びに同期プログラムに関し、特にＣＯＲＢＡ（Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ）とリアルタイムＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）の組み合わせによるソフトウェア構成の通信装置におけるフレーム同期システム及びム同期方法並びに同期プログラムに関する。
【０００２】
【従来の技術】
オブジェクト技術の国際的な標準化団体であるＯＭＧ（Ｏｂｊｅｃｔ  Ｍａｎａｇｅｍｅｎｔ  Ｇｒｏｕｐ）が策定しているＣＯＲＢＡは、分散システム環境構築において必須となるアプリケーション間の通信とアプリケーションを利用するためのインタフェースを規定している。ＯＭＧが提供する分散オブジェクトモデルＯＭＡ（Ｏｂｊｅｃｔ  Ｍａｎａｇｅｍｅｎｔ  Ａｒｃｈｉｔｅｃｔｕｒｅ）によるＣＯＲＢＡでは、オブジェクト間の通信を行う為のミドルウエア（ｍｉｄｄｌｅｗａｒｅ；ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）とアプリケーションの中間に位置するソフトウエア））であるＯＲＢ（Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ）とリアルタイム性に優れたリアルタイムＯＳとの組み合わせを用いて伝送を行っている。
【０００３】
図１６はソフトウェア構成の通信装置を含む通信システムの一例の全体構成図である。同図を参照すれば分かるように、通信装置１０１は伝送路１０２を介して外部装置Ａ１０３と接続され、伝送路１０４を介して外部装置Ｂ１０５と接続されている。そして、通信装置１０１は外部装置Ａ１０３から送信されたデータを受信し、そのデータを処理した後、外部装置Ｂ１０５へ送信する。同様に、通信装置１０１は外部装置Ｂ１０５から送信されたデータを受信し、そのデータを処理した後、外部装置Ａ１０３へ送信する。このように、通信装置１０１は双方向データの処理を行う。
【０００４】
次に、従来のＣＯＲＢＡ及びリアルタイムＯＳの組み合わせによるソフトウェアの通信装置の構成及び動作について説明する。図１７は従来のソフトウェア構成の通信装置の一例の構成図である。
【０００５】
図１７を参照すると、従来の通信装置は送信側装置がアプリケーション１１１と、ＣＯＲＢＡ１１２と、リアルタイムＯＳ１１３と、バス（Ｂｕｓ）１１４とから構成され、受信側装置がバス（Ｂｕｓ）１１５と、リアルタイムＯＳ１１６と、ＣＯＲＢＡ１１７と、アプリケーション１１８とから構成されている。又、バス１１４，１１５間は図示しない伝送路で接続されている。
【０００６】
そして、主信号Ｓ１は、送信側アプリケーション１１１からＣＯＲＢＡ１１２、リアルタイムＯＳ１１３、バス１１４及び伝送路を介して受信側装置のバス１１５に伝送される。一方、受信側装置では、バス１１５に入力された主信号Ｓ１がリアルタイムＯＳ１１６及びＣＯＲＢＡ１１７を介して、受信側装置のアプリケーション１１８でソフトウェアの処理が行われる。この受信側アプリケーション１１８には、基準信号がなく主信号Ｓ１は非同期に伝送される。
【０００７】
なお、従来のＣＯＲＢＡを用いた通信装置の他の例が特開２０００−５６９９７号公報、特開２００１−５６７６７号公報及び特開平９−３３０２２３号公報に開示されている。
【０００８】
【発明が解決しようとする課題】
しかし、従来のＣＯＲＢＡ及びリアルタイムＯＳの組み合わせによるソフトウェアの通信装置においては、次のような課題がある。その課題を図１８及び図１９を用いて説明する。図１８は従来の通信装置の動作を示すタイミングチャート、図１９は従来の通信装置と本発明の通信装置との効果の相違を説明するためのタイミングチャートである。
【０００９】
第１の課題は、非同期伝送のため、受信側アプリケーション１１８において、信号が伝送されない状態ではソフトウェアの処理待ちが発生することである。図１８（Ａ）は主信号Ｓ１が送信側アプリケーション１１１からＡ，Ｂ，Ｃの順に不定期に送信される様子を示している。図１８（Ｂ）はこの主信号Ｓ１を受信する受信側アプリケーション１１８のタイミングを示している。図１８（Ｂ）から分かるように、受信側アプリケーション１１８において主信号Ａを受信するまでの間は待ち時間Ｔ１となる。又、主信号Ａの処理終了後、主信号Ｂを受信するまでの間も待ち時間Ｔ２となる。即ち、図１９（Ａ）に示すように、従来の受信側アプリケーション１１８では主信号Ｓ１を受信するまでの時間Ｔ３は全て待ち時間となっていたのである。一方、後述するが本発明では図１９（Ｂ）に示すように受信側アプリケーション１１８はフレーム同期信号を受信した後に主信号Ｓ１待ちに入るため，待ち時間Ｔ４は従来の待ち時間Ｔ３よりも短くなる。
【００１０】
第２の課題は、非同期伝送のため、受信側アプリケーション１１８において、受信される主信号Ｓ１の間隔に変動があった場合では、処理がオーバーフローすることである。即ち、図１８（Ａ），（Ｂ）を参照すると、主信号ＡとＢとは受信側アプリケーション１１８で処理が可能な時間間隔をもって受信側アプリケーション１１８で受信されたため、受信側アプリケーション１１８で正常に処理することが可能である。一方、主信号Ｃは処理可能な時間間隔よりも短い時間間隔で受信側アプリケーション１１８で受信されたため、受信側アプリケーション１１８ではこの主信号Ｃを処理することができない。これは、主信号Ｃを受信した時点ではまだ主信号Ｂの処理を実行中であり、主信号Ｂの処理と主信号Ｃの処理とがぶつかりオ−バフロ−するからである。
【００１１】
そこで本発明の目的は、ソフトウェアの処理待ちを減少させ、かつ処理がオーバーフローするのを防止することが可能なフレーム同期システム及びフレーム同期方法を提供することにある。
【００１２】
【課題を解決するための手段】
前記課題を解決するために本発明によるフレーム同期システムは、外部装置から送信される情報を受信し、所定の処理を行った後に他の外部装置へその処理後の情報を送信する通信装置におけるフレーム同期システムであって、前記通信装置は前記外部装置から送信される情報を受信しその情報をバスを介して内部の受信手段へ送信する送信手段と、前記送信手段から送信される情報を受信し、所定の処理を行った後に前記他の外部装置へその処理後の情報を送信する前記受信手段とを含んでおり、前記送信手段は少なくとも前記情報とは非同期のフレーム同期信号を定期的に前記受信手段へ送信し、前記受信手段は前記フレーム同期信号を受信すると所定の処理を開始し、前記送信手段は予め次の同期フレームで処理される情報まで含めて前記情報を前記受信手段へ送信し、前記受信手段は前記複数の情報を格納するメモリを有しており、今回の同期フレームで処理されるべき情報が処理できない場合、前記メモリから今回の同期フレームで処理されるべき情報を読出し処理することを特徴とする。
【００１３】
又、本発明によるフレーム同期方法は、外部装置から送信される情報を受信し、所定の処理を行った後に他の外部装置へその処理後の情報を送信する通信装置におけるフレーム同期方法であって、前記通信装置は前記外部装置から送信される情報を受信しその情報をバスを介して内部の受信手段へ送信する送信手段と、前記送信手段から送信される情報を受信し、所定の処理を行った後に前記他の外部装置へその処理後の情報を送信する前記受信手段とを含んでおり、前記送信手段は少なくとも前記情報とは非同期のフレーム同期信号を定期的に前記受信手段へ送信し、前記受信手段は前記フレーム同期信号を受信すると所定の処理を開始し、前記送信手段は予め次の同期フレームで処理される情報まで含めて前記情報を前記受信手段へ送信し、前記受信手段は前記複数の情報を格納するメモリを有しており、今回の同期フレームで処理されるべき情報が処理できない場合、前記メモリから今回の同期フレームで処理されるべき情報を読出し処理するメモリ読出しステップを含むことを特徴とする。
【００１４】
又、本発明によるフレーム同期プログラムは、外部装置から送信される情報を受信し、所定の処理を行った後に他の外部装置へその処理後の情報を送信する通信装置におけるフレーム同期プログラムであって、前記通信装置は前記外部装置から送信される情報を受信しその情報をバスを介して内部の受信手段へ送信する送信手段と、前記送信手段から送信される情報を受信し、所定の処理を行った後に前記他の外部装置へその処理後の情報を送信する前記受信手段とを含んでおり、前記送信手段は少なくとも前記情報とは非同期のフレーム同期信号を定期的に前記受信手段へ送信し、前記受信手段は前記フレーム同期信号を受信すると所定の処理を開始し、前記送信手段は予め次の同期フレームで処理される情報まで含めて前記情報を前記受信手段へ送信し、前記受信手段は前記複数の情報を格納するメモリを有しており、今回の同期フレームで処理されるべき情報が処理できない場合、前記メモリから今回の同期フレームで処理されるべき情報を読出し処理するメモリ読出しステップを含むことを特徴とする。
【００１５】
本発明によれば、送信手段から定期的に送信されるフレーム同期信号を受信手段が受信すると、受信手段は所定の処理を開始するため、ソフトウエアの処理待ちを減少させることが可能となる。さらに、送信手段は予め次の同期フレームで処理される情報まで含めて送信し、受信手段はこれを受信するため、処理がオーバーフローするのを防止することも可能となる。
【００１６】
【発明の実施の形態】
以下、本発明の実施の形態について添付図面を参照しながら説明する。本発明は、ＣＯＲＢＡとリアルタイムＯＳの組み合わせによるソフトウェア構成の通信装置における、アプリケーション間の伝送方式において、定期的にフレーム同期信号を伝送し、ある範囲内の同期を常に維持し、ソフトウェアの処理待ちの低減及び処理のオーバーフローの回避を特徴としている。
【００１７】
図１は本発明に係るフレーム同期システムの最良の実施の形態の構成図である。同図を参照すると、本発明の通信装置は送信側装置がアプリケーション１と、ＣＯＲＢＡ２と、リアルタイムＯＳ３と、バス（Ｂｕｓ）４とから構成され、受信側装置がバス（Ｂｕｓ）５と、リアルタイムＯＳ６と、ＣＯＲＢＡ７と、アプリケーション８とから構成されている。又、バス４，５間は図示しない２本の伝送路で接続されている。
【００１８】
そして、ＣＯＲＢＡとリアルタイムＯＳの組み合わせによるソフトウェア構成の通信装置は、アプリケーション間の伝送を行う場合は、送信側装置のアプリケーション１から、フレーム同期信号Ｓ２を定期的にＣＯＲＢＡ２、リアルタイムＯＳ３及びバス４及び伝送路を介して、受信側装置のバス５に伝送する。受信側装置では、バス５に入力された同期フレーム信号Ｓ２をリアルタイムＯＳ６、ＣＯＲＢＡ７を介して、受信側装置のアプリケーション８でソフトウェアの処理が行われる。
【００１９】
そして、送信側装置のアプリケーション１でイベント（ｅｖｅｎｔ）が発生した場合、送信側装置のアプリケーション１では、フレーム同期信号Ｓ２とは別処理で、主信号Ｓ１を、ＣＯＲＢＡ２、リアルタイムＯＳ３，バス４及び伝送路を介して受信側装置のバス５に伝送する。
【００２０】
次に、フレーム同期信号Ｓ２と主信号Ｓ１との関係について説明する。図２はフレーム同期信号Ｓ２の送信タイミングを示すタイミングチャート、図３はフレーム同期信号Ｓ２と主信号Ｓ１との受信タイミングを示すタイミングチャートである。図２（Ａ）を参照すると、送信側アプリケーション１は、定期的にフレーム同期信号Ｓ２を送信している。一方、受信側アプリケーション８は、定期的にフレーム同期信号Ｓ２を受信している。
【００２１】
そして、受信側アプリケーション８は、フレーム同期信号Ｓ２が入力されれば、処理を開始し、ある一定時間内に主信号Ｓ１を受信しなければ、処理を終了（タイムアウト：ｔｉｍｅ  ｏｕｔ）する（図２（Ｂ）参照）。一方、受信側アプリケーション８は、フレーム同期信号Ｓ２を受信後、一定時間内に主信号Ｓ１を受信した場合（図３（Ａ），（Ｂ）参照）、主信号Ｓ１の処理を行う。即ち、受信側アプリケーション８は、最初のフレーム同期信号Ｓ２−１を受信すると処理を開始し、次いで主信号Ａの処理を行う。そして、主信号Ａの処理が終了すると正常終了となる。同様に、２番目のフレーム同期信号Ｓ２−２を受信すると処理を開始し、次いで主信号Ｂの処理を行う。そして、主信号Ｂの処理が終了すると正常終了となる。同様に、３番目のフレーム同期信号Ｓ２−３を受信すると処理を開始し、次いで主信号Ｃの処理を行う。そして、主信号Ｃの処理が終了すると正常終了となる。
【００２２】
さらに、本発明では、送信側アプリケーション１において、フレーム同期信号Ｓ２に併せて、主信号Ｓ１がソフトウェア処理ブロック単位で同一フレーム内に複数個伝送されるよう構成されている（図３（Ｂ）参照）。図３（Ｂ）はソフトウェア処理ブロック単位で同一フレーム内に主信号Ｓ１が２個ずつ受信側アプリケーション８で受信される場合を示している。なお、受信側アプリケーション８にはこの２個の主信号Ｓ１を一時記憶するためのメモリ（ダブルバッファ）が設けられている。
【００２３】
図４は同一フレーム内に主信号Ｓ１が２個ずつ伝送される場合の受信側アプリケーション８の動作を示すタイミングチャートである。図４を参照すると、受信側アプリケーション８は、フレーム同期信号Ｓ２を受信し、主信号Ｓ１のソフトウェアの処理を開始する。即ち、受信側アプリケーション８は、最初のフレーム同期信号Ｓ２−１を受信すると処理を開始し、次いで主信号Ａの処理を行う。そして、主信号Ａの処理が終了すると正常終了となる。同様に、２番目のフレーム同期信号Ｓ２−２を受信すると処理を開始し、次いで主信号Ｂの処理を行う。そして、主信号Ｂの処理が終了すると正常終了となる。しかし、３番目のフレーム同期信号Ｓ２−３よりも先に主信号Ｃが受信された場合、受信側アプリケーション８はこの主信号Ｃの処理を実行することができない。そこで、受信側アプリケーション８はメモリ（ダブルバッファ）からフレーム同期信号Ｓ２−２を受信した際に受信した主信号Ｂ，Ｃのうちの主信号Ｃを読み出し、その処理を実行する。このように、受信側アプリケーション８は複数個ある主信号Ｓ１のうちの現在処理すべき信号を認識し、処理を正常に終了する。
【００２４】
なお、フレーム同期信号Ｓ２−３よりも先に主信号Ｃが受信される場合が存在する理由は、送信側装置と受信側装置間の伝送経路に時間的変動が発生するため、送信側装置でフレーム同期信号Ｓ２が主信号Ｓ１よりも先に送信されたにもかかわらず、受信側装置には主信号Ｓ１の方がフレーム同期信号Ｓ２よりも先に到達する場合が存在するからである。
【００２５】
このようにして、本発明では、ＣＯＲＢＡとリアルタイムＯＳの組み合わせによるソフトウェア構成の通信装置において、送信側アプリケーション１から同期フレーム信号Ｓ２を定期的に伝送することにより、受信側装置アプリケーション８に主信号Ｓ１が伝送されない状態であっても、受信側アプリケーション８は処理待ちを続けることなく、フレーム同期信号Ｓ２を認識した段階で処理開始として動作する。
【００２６】
そして、その処理開始からある一定時間主信号Ｓ１が入力されないと判断するとタイマーにより処理終了として動作するので、受信側装置のソフトウェアの処理待ちの低減を図ることができる。さらに、送信側アプリケーション１でイベントが発生した場合、送信側アプリケーション１で別処理された主信号Ｓ１は同一フレーム内に、ソフトウェア処理ブロック単位で複数個伝送されることにより、アプリケーション間の伝送経路に時間的変動があった場合に起こる、フレーム同期信号Ｓ２と主信号Ｓ１のタイミングずれにも、前フレームに受信した主信号Ｓ１をメモリより呼び出すことにより、その信号を現在処理しなければいけない信号として認識し、その信号を処理することにより、受信側アプリケーション８でのオーバーフローを回避することができる。
【００２７】
【実施例】
次に、本発明の実施例について説明する。まず、第１実施例について説明する。図５は第１実施例の構成図である。同図を参照すると、本発明の一実施例として、ソフトウェア構成の通信装置のアーキテクチャ（ａｒｃｈｉｔｅｃｔｕｒｅ）が示されている。同図において、通信装置は送信側装置及び受信側装置とからなり、送信側装置、受信側装置ともに、バス（Ｂｕｓ）１４，１５上に夫々リアルタイムＯＳ１３，１６及びミドルウェアであるＣＯＲＢＡ１２，１７が、その上位層に送信側装置はマンマシンアプリケーション（ｍａｎ−ｍａｃｈｉｎｅ  ａｐｐｌｉｃａｔｉｏｎ）１１、受信側装置は変復調アプリケーション１８がある。又、バス（Ｂｕｓ）１４，１５間には主信号Ｓ１及びフレ−ム同期信号Ｓ２を夫々伝送するための図示しない２本の伝送路が接続されている。
【００２８】
次に、第１実施例の動作について説明する。マンマシンアプリケーション１１が変復調アプリケーション１８に対して信号を伝送する時は、ＣＯＲＢＡ１２、リアルタイムＯＳ１３、バス（Ｂｕｓ）１４及び伝送路を介して受信側装置のバス（Ｂｕｓ）１５に伝送する。受信側装置では、バス（Ｂｕｓ）１５に入力された同期フレーム信号Ｓ２をリアルタイムＯＳ１６、ＣＯＲＢＡ１７を介して、受信側装置の変復調アプリケーション１８でソフトウェアの処理を行う。フレーム同期信号Ｓ２は定期的にマンマシンアプリケーション１１から変復調アプリケーション１８に伝送される。一方、主信号Ｓ１は、マンマシンアプリケーション１１にイベントが発生した時点で、マンマシンアプリケーション１１でソフトウェア処理された後、マンマシンアプリケーション１１から変復調アプリケーション１８へ伝送される。その後、変復調アプリケーション１８でソフトウェア処理される。マンマシンアプリケーション１１から変復調アプリケーション１８へ伝送される主信号Ｓ１は、同期フレーム内に通常ソフトウェア処理単位で伝送されるところ、予め次の同期フレームで処理される信号分まで含めて伝送される。
【００２９】
図６はマンマシンアプリケーション１１の一例の構成図である。同図を参照すると、マンマシンアプリケーション１１はインタフェース２１と、メモリ２２と、フォーマット変換部２３と、信号処理部２４と、タイミング制御部２５と、インタフェース２６とから構成されている。
【００３０】
即ち、マンマシンアプリケーション１１は、通信装置と外部とのインタフェース変換（インタフェース２１及び２６で行われる）、信号処理（信号処理部２４で行われる）、フォーマット変換（フォーマット変換部２３で行われる）、タイミング制御（タイミング制御部２５で行われる）等を行うアプリケーションで、主信号Ｓ１をソフトウェア処理した後、変復調アプリケーション１８へ伝送する。なお、予め次のフレーム同期分までの主信号Ｓ１を含めて伝送するため、メモリ２２は、２個以上のダブルバッファを備えている。
【００３１】
図７は変復調アプリケーション１８の一例の構成図である。同図を参照すると、変復調アプリケーション１８はインタフェース３１と、変調処理部３２と、復調処理部３３と、メモリ３４と、インタフェース３５とから構成される。
【００３２】
即ち、変復調アプリケーション１８は、マンマシンアプリケーション１１から伝送されてくる信号を通信装置外部へ伝送しやすいように変調処理（変調処理部３２で行われる）を行い、アナログ信号として伝送するアプリケーションである。又、変復調アプリケーション１８側でもフレーム同期信号Ｓ２と主信号Ｓ１のタイミングずれにそなえて、メモリ３４は２個以上のダブルバッファを備えている。又、変復調アプリケーション１８は、通信装置が受信するアナログ信号の復調処理（復調処理部３３で行われる）を行うアプリケーションでもある。又、インタフェース３１及び３５は通信装置と外部とのインタフェース変換を行う。
【００３３】
以上詳細に第１実施例の構成を述べたが、図６のマンマシンアプリケーション１１、図７の変復調アプリケーション１８及びメモリ（ダブルバッファ）２２，３４は当業者にとってよく知られており、また本発明とは直接関係しないので、その詳細な構成は省略する。
【００３４】
なお、上記第１実施例では、ＯＳとして、リアルタイムＯＳを挙げたが、例えばＵＮＩＸ（登録商標）等のＯＳでも構成できる。又、アプリケーションは、ネットワークアプリケーション、信号処理アプリケーション等、通信装置に関わるアプリケーションでも構成できる。
【００３５】
次に、第２実施例について説明する。第２実施例は変復調アプリケーション１８の動作に関するものである。その動作をフローチャートを使用して説明する。図８から図１１は変復調アプリケーション１８の動作を示すフローチャートである。図８は主信号Ｓ１の入力がない場合の動作を示している。同図を参照すると、フレーム同期信号Ｓ２が変復調アプリケーション１８に伝送されると（Ｓ１１）、変復調アプリケーション１８は、フレーム同期信号Ｓ２を認識し、ソフトウェア処理を開始する（Ｓ１２）。ここで、主信号Ｓ１がある一定時間内に伝送されない場合は、主信号Ｓ１入力なしと認識し（Ｓ１３）、タイマーで処理終了となる（Ｓ１４）。そして、再びフレーム同期信号Ｓ２が入力されれば（Ｓ１１）、ソフトウェア処理を開始する（Ｓ１２）。以降、上記の動作の繰り返しとなる。
【００３６】
図９は主信号Ｓ１の入力がある場合の動作を示している。同図を参照すると、フレーム同期信号Ｓ２が変復調アプリケーション１８に伝送されると（Ｓ２１）、変復調アプリケーション１８はフレーム同期信号を認識し、ソフトウェア処理を開始する（Ｓ２２）。次に、主信号Ｓ１がフレーム同期信号Ｓ２とほぼ同時に伝送されると、主信号Ｓ１入力ありと認識し（Ｓ２３）、ソフトウェアの処理を開始し、その後ソフトウェアの処理が正常に終了する（Ｓ２４）。そして、再びフレーム同期信号が入力されれば（Ｓ２１）、ソフトウェア処理を開始する（Ｓ２２）。以降、上記の動作の繰り返しとなる。
【００３７】
図１０はソフトウェアの処理がハングアップを起こした場合の動作を示している。同図を参照すると、フレーム同期信号Ｓ２が変復調アプリケーション１８に伝送されると（Ｓ３１）、変復調アプリケーション１８はフレーム同期信号Ｓ２を認識し、ソフトウェア処理を開始する（Ｓ３２）。次に、主信号Ｓ１がフレーム同期信号Ｓ２とほぼ同時に伝送されると、ソフトウェア処理を開始する。ここで、ソフトウェアの処理が不正処理等によりハングアップを起こした場合は（Ｓ３３）、フレーム同期信号Ｓ２からのタイムアウト処理により強制的にその処理を終了する（Ｓ３４）。そして、再びフレーム同期信号Ｓ２が入力されれば（Ｓ３１）、ソフトウェア処理を開始する（Ｓ３２）。以降、上記の動作の繰り返しとなる。
【００３８】
図１１はフレーム同期信号Ｓ２が主信号Ｓ１の伝送より時間的に遅くて受信された場合の動作を示している。同図を参照すると、フレーム同期信号Ｓ２が変復調アプリケーション１８に伝送されると（Ｓ４１）、変復調アプリケーション１８はフレーム同期信号Ｓ２を認識し、ソフトウェア処理を開始する（Ｓ４２）。次に、主信号Ｓ１がフレーム同期信号Ｓ２とほぼ同時に伝送されると、ソフトウェア処理を開始する。ここで、フレーム同期信号Ｓ２が主信号Ｓ１の伝送より時間的に遅くて受信された場合、その主信号Ｓ１は処理すべきではない信号と認識され（Ｓ４３）、前のフレームで既に伝送されてあるソフトウェア処理ブロック単位の信号をメモリ３４より呼び出して、そのフレームを処理する（Ｓ４４）。そして、ソフトウェアの処理が正常に処理され（Ｓ４５）、再びフレーム同期信号Ｓ２が入力されれば（Ｓ４１）、ソフトウェア処理を開始する（Ｓ４２）。以降、上記の動作の繰り返しとなる。
【００３９】
次に、第３実施例について説明する。図１２は第３実施例の動作を示すタイミングチャートである。第３実施例はフレーム同期信号Ｓ２に次いで主信号Ｓ１が３個ずつ伝送される場合を示している。同図を参照すると、変復調アプリケーション１８はフレーム同期信号Ｓ２−１に次いで３個の主信号Ａ，Ｂ，Ｃを受信し、フレーム同期信号Ｓ２−２に次いで３個の主信号Ｂ，Ｃ，Ｄを受信し、フレーム同期信号Ｓ２−３に次いで３個の主信号Ｃ，Ｄ，Ｅを受信する。そして、フレーム同期信号Ｓ２−３よりも主信号Ｃの方が先に変復調アプリケーション１８に到達したため、変復調アプリケーション１８はこの主信号Ｃの処理を行うことができず、従って、フレーム同期信号Ｓ２−２を受信した際の主信号Ｃをメモリ３４から読出して処理している。これは前述した動作と同様である。
【００４０】
しかし、第３実施例では３番目の主信号までメモリ３４に書込む構成であるため（この場合、メモリ３４はトリプルバッファ構成となる）、主信号を３個続けて伝送した場合は、２個伝送する場合に比べフレーム同期信号Ｓ２の時間的変動に対して、より保証されることになる。
【００４１】
なお、主信号Ｓ１が４個以上伝送される場合も同様に説明できる。要は、フレーム同期信号Ｓ２フレーム同期信号の間隔は、受信側の変復調アプリケーション１８が主信号Ｓ１をソフトウェアで処理できる時間幅に設定されており、送信側及び受信側のメモリ２２，３４はフレーム同期信号Ｓ２に次いで連続して伝送される複数の主信号Ｓ１を書込むだけの記憶領域を有している。
【００４２】
又、別の効果として、変復調アプリケーション１８では、定期的に受信されるフレーム同期信号Ｓ２のタイミングを予め予測することができるので、その範囲の時間において主信号Ｓ１をソフトウェア処理することもできる。
【００４３】
このように、本実施例では、フレーム同期信号Ｓ２の間隔を主信号Ｓ１がソフトウェアで処理できる間隔で伝送しているので、ソフトウェア処理のオーバーフローを回避できるという効果が得られる。又、フレーム同期信号Ｓ２のタイミングを予め予測することができるので、ソフトウェアの処理待ちの低減が図られる。
【００４４】
次に、第４実施例について説明する。図１３は第４実施例の構成図である。図１３は図１に対応するものである。図１３において図１と同様の構成部分には同一番号を付し、その説明を省略する。図１３から分かるように、第４実施例の通信装置の構成は図１の最良の実施の形態の構成と同様である。ただし、主信号Ｓ１とフレーム同期信号Ｓ２の伝送方向が図１と反対になっている点が相違する。
【００４５】
即ち、前述の図１６に示したように、通信装置１０１は外部装置Ａ１０３から送信されたデータを外部装置Ｂ１０５へ送信する機能とともに、外部装置Ｂ１０５から送信されたデータを外部装置Ａ１０３へ送信する機能も有するのである。図１３は外部装置Ｂ１０５から送信されたデータを外部装置Ａ１０３へ送信する場合の通信装置１０１内部の信号の伝送経路を示している。
【００４６】
図１３を参照すると、受信側アプリケーション８から、フレーム同期信号Ｓ２を定期的にＣＯＲＢＡ７、リアルタイムＯＳ６及びバス５及び伝送路を介して、送信側のバス４に伝送する。送信側では、バス４に入力された同期フレーム信号Ｓ２をリアルタイムＯＳ３、ＣＯＲＢＡ２を介して、送信側のアプリケーション１でソフトウェアの処理が行われる。
【００４７】
そして、受信側のアプリケーション８でイベントが発生した場合、受信側のアプリケーション８では、フレーム同期信号Ｓ２とは別処理で、主信号Ｓ１を、ＣＯＲＢＡ７、リアルタイムＯＳ６，バス５及び伝送路を介して送信側のバス４に伝送する。なお、フレーム同期信号Ｓ２と主信号Ｓ１との関係は最良の実施の形態と同様であるため説明を省略する。
【００４８】
次に、第５実施例について説明する。図１４は第５実施例の構成図である。図１４は図５に対応するものである。図１４において図５と同様の構成部分には同一番号を付し、その説明を省略する。図１４から分かるように、第５実施例の通信装置の構成は図５の第１実施例の構成と同様である。ただし、主信号Ｓ１とフレーム同期信号Ｓ２の伝送方向が図５と反対になっている点が相違する。図１４に示すように、主信号Ｓ１とフレーム同期信号Ｓ２の伝送方向が図５と反対の構成も可能である。なお、主信号Ｓ１とフレーム同期信号Ｓ２の伝送経路については第４実施例と同様であるため、その説明を省略する。
【００４９】
次に、第６実施例について説明する。図１５は第６実施例の構成図である。なお、図１５において図５と同様の構成部分については同一番号を付し、その説明を省略する。図１５を参照すると、第６実施例に示す通信装置は１個の送信側装置と２個の受信側装置とから構成されている。又、送信側装置及び各受信側装置は図示しない伝送路を介して相互接続されている。詳細には、送信側装置のバス（Ｂｕｓ）１４と受信側装置のバス（Ｂｕｓ）１５−１とが図示しない２本の伝送路を介して接続され、受信側装置のバス（Ｂｕｓ）１５−１と１５−２とが図示しない２本の伝送路を介して接続されている。
【００５０】
次に、第６実施例の動作について説明する。図１５を参照すると、マンマシンアプリケーション１１が変復調アプリケーション１８−１，１８−２に対して信号を伝送する時は、ＣＯＲＢＡ１２、リアルタイムＯＳ１３、バス（Ｂｕｓ）１４及び伝送路を介して受信側装置のバス（Ｂｕｓ）１５−１，１５−２に伝送する。この場合、マンマシンアプリケーション１１から伝送される信号には変復調アプリケーション１８−１宛の信号と変復調アプリケーション１８−２宛の信号との両方が含まれる。
【００５１】
一方の受信側装置は、バス（Ｂｕｓ）１５−１に入力された同期フレーム信号Ｓ２をリアルタイムＯＳ１６−１、ＣＯＲＢＡ１７−１を介して、変復調アプリケーション１８−１でソフトウェアの処理を行う。フレーム同期信号Ｓ２は定期的にマンマシンアプリケーション１１から変復調アプリケーション１８−１に伝送される。一方、主信号Ｓ１は、マンマシンアプリケーション１１にイベントが発生した時点で、マンマシンアプリケーション１１でソフトウェア処理された後、マンマシンアプリケーション１１から変復調アプリケーション１８−１へ伝送される。この時、変復調アプリケーション１８−１は伝送されてきた主信号Ｓ１のうち自装置宛の信号のみを選択する。その後、選択された主信号Ｓ１は変復調アプリケーション１８−１でソフトウェア処理される。マンマシンアプリケーション１１から変復調アプリケーション１８−１へ伝送される主信号Ｓ１は、同期フレーム内に通常ソフトウェア処理単位で伝送されるところ、予め次の同期フレームで処理される信号分まで含めて伝送される。
【００５２】
他方の受信側装置は、バス（Ｂｕｓ）１５−２に入力された同期フレーム信号Ｓ２をリアルタイムＯＳ１６−２、ＣＯＲＢＡ１７−２を介して、変復調アプリケーション１８−２でソフトウェアの処理を行う。フレーム同期信号Ｓ２は定期的にマンマシンアプリケーション１１から変復調アプリケーション１８−２に伝送される。一方、主信号Ｓ１は、マンマシンアプリケーション１１にイベントが発生した時点で、マンマシンアプリケーション１１でソフトウェア処理された後、マンマシンアプリケーション１１から変復調アプリケーション１８−２へ伝送される。この時、変復調アプリケーション１８−２は伝送されてきた主信号Ｓ１のうち自装置宛の信号のみを選択する。その後、選択された主信号Ｓ１は変復調アプリケーション１８−２でソフトウェア処理される。マンマシンアプリケーション１１から変復調アプリケーション１８−２へ伝送される主信号Ｓ１は、同期フレーム内に通常ソフトウェア処理単位で伝送されるところ、予め次の同期フレームで処理される信号分まで含めて伝送される。
【００５３】
次に、第７実施例について説明する。第７実施例はフレーム同期プログラムに関するものである。即ち、図８から図１１までにフローチャ−トで示す変復調アプリケーション１８の処理をプログラム化する。そして、そのプログラムを変復調アプリケーション１８に実行させる。
【００５４】
【発明の効果】
本発明による第１の発明によれば、外部装置から送信される情報を受信し、所定の処理を行った後に他の外部装置へその処理後の情報を送信する通信装置におけるフレ−ム同期システムであって、前記通信装置は前記外部装置から送信される情報を受信しその情報をバスを介して内部の受信手段へ送信する送信手段と、前記送信手段から送信される情報を受信し、所定の処理を行った後に前記他の外部装置へその処理後の情報を送信する前記受信手段とを含んでおり、前記送信手段は少なくとも前記情報とは異なるフレ−ム同期信号を定期的に前記受信手段へ送信し、前記受信手段は前記フレ−ム同期信号を受信すると所定の処理を開始する構成であるため、ソフトウェアの処理待ちを減少させることが可能となる。さらに、送信手段は予め次の同期フレームで処理される情報まで含めて情報を送信し、受信手段はこれを受信するため、処理がオーバーフローするのを防止することも可能となる。
【００５５】
又、本発明による第２及び第３の発明も上述した第１の発明と同様の効果を奏する。
【００５６】
具体的には、第１の効果は、定期的にフレーム同期信号を伝送し、そのフレーム同期信号の受信をもって主信号の処理を開始するので、ソフトウェアの処理の待ち時間が低減されることにある。
【００５７】
第２の効果は、送信側アプリケーションは、同一フレーム内にソフトウェア処理ブロック単位で主信号を複数個伝送しているので、フレーム同期信号と主信号に時間的変動のずれがあった場合でも、既に伝送された信号をメモリより呼び出して処理することでソフトウェアのオーバーフローを回避することにある。
【００５８】
第３の効果は、定期的にフレーム同期信号を伝送しているので、ある一定の時間幅で同期している為、他のソフトウェア処理に対して、時間的タスク管理ができることにある。
【図面の簡単な説明】
【図１】本発明に係るフレーム同期システムの最良の実施の形態の構成図である。
【図２】フレーム同期信号Ｓ２の送信タイミングを示すタイミングチャートである。
【図３】フレーム同期信号Ｓ２と主信号Ｓ１との受信タイミングを示すタイミングチャートである。
【図４】同一フレーム内に主信号Ｓ１が２個ずつ伝送される場合の受信側アプリケーション８の動作を示すタイミングチャートである。
【図５】第１実施例の構成図である。
【図６】マンマシンアプリケーション１１の一例の構成図である。
【図７】変復調アプリケーション１８の一例の構成図である。
【図８】変復調アプリケーション１８の動作を示すフローチャートである。
【図９】変復調アプリケーション１８の動作を示すフローチャートである。
【図１０】変復調アプリケーション１８の動作を示すフローチャートである。
【図１１】変復調アプリケーション１８の動作を示すフローチャートである。
【図１２】第３実施例の動作を示すタイミングチャートである。
【図１３】第４実施例の構成図である。
【図１４】第５実施例の構成図である。
【図１５】第６実施例の構成図である。
【図１６】ソフトウェア構成の通信装置を含む通信システムの一例の全体構成図である。
【図１７】従来のソフトウェア構成の通信装置の一例の構成図である。
【図１８】従来の通信装置の動作を示すタイミングチャートである。
【図１９】従来の通信装置と本発明の通信装置との効果の相違を説明するためのタイミングチャートである。
【符号の説明】
１，８  アプリケーション
２，７，１２，１７  ＣＯＲＢＡ
３，６，１３，１６  リアルタイムＯＳ
４，５，１４，１５  バス
１１  マンマシンアプリケーション
１８  変復調アプリケーション
２２，３４  メモリ
【図１】
0003758531.tif 000002
【図２】
0003758531.tif 000003
【図３】
0003758531.tif 000004
【図４】
0003758531.tif 000005
【図５】
0003758531.tif 000006
【図６】
0003758531.tif 000007
【図７】
0003758531.tif 000008
【図８】
0003758531.tif 000009
【図９】
0003758531.tif 000010
【図１０】
0003758531.tif 000011
【図１１】
0003758531.tif 000012
【図１２】
0003758531.tif 000013
【図１３】
0003758531.tif 000014
【図１４】
0003758531.tif 000015
【図１５】
0003758531.tif 000016
【図１６】
0003758531.tif 000017
【図１７】
0003758531.tif 000018
【図１８】
0003758531.tif 000019
【図１９】
0003758531.tif 000020