JP2018055285A - 電子装置及び画像処理装置 - Google Patents

Abstract

【課題】一方の制御手段から送信されたコマンドを他方の制御手段にて処理する場合に、コマンド毎にＯＳ間通信が発生する構成と比較して、全体の処理時間を短縮する。
【解決手段】画像処理装置の制御部１１０は、処理を実行するＬｉｎｕｘ２００と、ＶｘＷｏｒｋｓ３００とを備える。Ｌｉｎｕｘ２００は、ＶｘＷｏｒｋｓ３００が実行するコマンドを生成するアプリケーション２１０と、ＶｘＷｏｒｋｓ３００が実行する複数のコマンドと、その実行手順を定めた制御コードとの対応関係を有し、アプリケーション２１０により生成された複数のコマンドに対応する制御コードが対応関係に存在する場合、複数のコマンドに制御コードを付与してＶｘＷｏｒｋｓ３００へ送信するＯＳ間通信部２２０とを備える。また、ＶｘＷｏｒｋｓ３００は、送信された複数のコマンドを受信すると、付与された制御コードに定められた実行手順に基づいて複数のコマンドを実行する。
【選択図】図６

Description

本発明は、電子装置及び画像処理装置に関する。

複数のプロセッサからなるマルチプロセッサシステムに関し、複数のマイクロプロセッサ間のデータ転送に使用される技術として、例えば、特許文献１には、転送データの書込、読出が可能な複数バイトのデータバッファと、このデータバッファにおける転送データの書込、読出が可能であるか否かの状態を記憶する状態記憶手段と、この状態記憶手段の記憶内容にもとづいてデータバッファにおける転送データの書込、読出を行うと共に、データ転送の際に状態記憶手段の記憶内容を書換えて相互に割込制御をする複数のプロセッサとを備え、転送データを複数のプロセッサ間で双方向に転送するようにしたマルチプロセッサシステムが開示されている。

また、プロセス間通信サブシステム内の無名応答ポート機構を提供する技術として、例えば、特許文献２には、クライアントである送信側タスクは、その双方向メッセージを送信／受信メッセージとして公式化し、送信／受信メッセージは、サーバである宛先タスクと応答ポートのアイデンティティとを指名するフィールドを含み、クライアントである送信側タスクは、無名応答ポートをサーバである宛先タスクからの応答のための指定ポートとして受け入れることを示す指示を、応答ポート・フィールドに入れ、この指定により、プロセス間通信サブシステムは、サーバである宛先タスクから見たように、メッセージの明らかなセンダーになる技術が開示されている。

特開昭６０−１８１９５９号公報 特開平８−１６４１１号公報

複数のＣＰＵ（Central Processing Unit）を有するマルチプロセッサ構成の電子装置では、それぞれのＣＰＵが実行するＯＳ（Operating System）間にて通信が行われる場合がある。通常、ＯＳ内で行われる処理の時間は、ＯＳ間で行われるＯＳ間通信の時間に比べて非常に短いため、ＯＳ間通信の回数が増えるほどＣＰＵによる全体の処理時間が長くなってしまう。
本発明の目的は、一方の制御手段から送信されたコマンドを他方の制御手段にて処理する場合に、コマンド毎にＯＳ間通信が発生する構成と比較して、全体の処理時間を短縮することにある。

請求項１に記載の発明は、第１ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）に基づいて処理を実行する第１制御手段と、第２ＯＳに基づいて処理を実行する第２制御手段とを備え、前記第１制御手段は、前記第２制御手段が実行するコマンドを生成するコマンド生成部と、前記第２制御手段が実行する複数のコマンドと当該複数のコマンドの実行手順を定めた制御コードとを予め対応付けた対応関係を有し、前記コマンド生成部により生成された複数のコマンドに対応する制御コードが前記対応関係に存在する場合、当該複数のコマンドに当該制御コードを付与して前記第２制御手段へ送信するコマンド送信部とを備え、前記第２制御手段は、前記コマンド送信部から送信された前記複数のコマンドを受信すると、付与された前記制御コードに定められた前記実行手順に基づいて当該複数のコマンドを実行することを特徴とする電子装置である。
請求項２に記載の発明は、前記第２制御手段は、前記複数のコマンドのそれぞれを実行する度にコマンドの実行結果を前記第１制御手段へ送信せずに、前記複数のコマンドの処理が終了した後に当該複数のコマンドの処理結果を当該第１制御手段へ送信することを特徴とする請求項１に記載の電子装置である。
請求項３に記載の発明は、前記第２制御手段は、前記複数のコマンドの処理結果として、前記第１制御手段が実行する複数のコマンドに当該複数のコマンドの実行手順を定めた制御コードを付与して当該第１制御手段へ送信することを特徴とする請求項２に記載の電子装置である。
請求項４に記載の発明は、前記第２制御手段は、前記複数のコマンドのうちの一のコマンドを実行する場合、前記制御コードに定められた前記実行手順と当該一のコマンドの実行結果とにより、当該一のコマンドを実行した後の処理を行うことを特徴とする請求項１に記載の電子装置である。
請求項５に記載の発明は、前記第２制御手段は、前記一のコマンドの実行に成功した場合、成功した場合に実行するコマンドとして前記制御コードに定められた他のコマンドを実行し、当該一のコマンドの実行に失敗した場合、当該他のコマンドを実行せずに前記複数のコマンドの実行を終了することを特徴とする請求項４に記載の電子装置である。
請求項６に記載の発明は、前記第２制御手段は、前記一のコマンドの実行に成功した場合、成功した場合に実行するコマンドとして前記制御コードに定められたコマンドを実行し、当該一のコマンドの実行に失敗した場合、失敗した場合に実行するコマンドとして当該制御コードに定められたコマンドを実行することを特徴とする請求項４に記載の電子装置である。
請求項７に記載の発明は、第１ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）に基づいて処理を実行する第１制御手段と、第２ＯＳに基づいて処理を実行する第２制御手段とを備え、前記第１制御手段は、前記第２制御手段が実行する複数のコマンド及び当該複数のコマンドの実行手順を定めた制御コードをまとめて当該第２制御手段へ送信し、前記第２制御手段は、前記第１制御手段から受信した前記制御コードの前記実行手順を基に前記複数のコマンドを実行することを特徴とする電子装置である。
請求項８に記載の発明は、第１ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）に基づいて処理を実行する第１制御手段と、第２ＯＳに基づいて処理を実行する第２制御手段とを備え、前記第１制御手段は、前記第２制御手段が実行するコマンドを生成するコマンド生成部と、ユーザにより指示された画像処理を実行するための複数のコマンドと当該複数のコマンドの実行手順を定めた制御コードとを予め対応付けた対応関係を有し、前記コマンド生成部により生成された複数のコマンドに対応する制御コードが前記対応関係に存在する場合、当該複数のコマンドに当該制御コードを付与して前記第２制御手段へ送信するコマンド送信部とを備え、前記第２制御手段は、前記コマンド送信部から送信された前記複数のコマンドを受信すると、付与された前記制御コードに定められた前記実行手順に基づいて当該複数のコマンドを実行することを特徴とする画像処理装置である。

請求項１記載の発明によれば、一方の制御手段から送信されたコマンドを他方の制御手段にて処理する場合に、コマンド毎にＯＳ間通信が発生する構成と比較して、全体の処理時間を短縮することができる。
請求項２記載の発明によれば、一方の制御手段から送信されたコマンドを他方の制御手段にて処理する場合に、コマンド毎にＯＳ間通信が発生する構成と比較して、全体の処理時間を短縮することができる。
請求項３記載の発明によれば、他方の制御手段から送信されたコマンドを一方の制御手段にて処理する場合に、さらに全体の処理時間を短縮することができる。
請求項４記載の発明によれば、一方の制御手段から送信されたコマンドを他方の制御手段にて処理する場合に、他方の制御手段から一方の制御手段に対してコマンドの実行結果を送信しなくても、他方の制御手段がコマンド実行後の処理を続けて行うことができる。
請求項５記載の発明によれば、一方の制御手段から送信されたコマンドを他方の制御手段にて処理する場合に、他方の制御手段から一方の制御手段に対してコマンドの実行結果を送信しなくても、他方の制御手段がコマンドの実行結果に応じた処理を行うことができる。
請求項６記載の発明によれば、一方の制御手段から送信されたコマンドを他方の制御手段にて処理する場合に、他方の制御手段から一方の制御手段に対してコマンドの実行結果を送信しなくても、他方の制御手段がコマンドの実行結果に応じた処理を行うことができる。
請求項７記載の発明によれば、一方の制御手段から送信されたコマンドを他方の制御手段にて処理する場合に、コマンド毎にＯＳ間通信が発生する構成と比較して、全体の処理時間を短縮することができる。
請求項８記載の発明によれば、一方の制御手段から送信されたコマンドを他方の制御手段にて処理する場合に、コマンド毎にＯＳ間通信が発生する構成と比較して、全体の処理時間を短縮することができる。

マルチプロセッサ構成の画像処理装置において、ＡＳＩＣを使用して処理を行う場合の従来の通信の流れの一例を示す図である。 マルチプロセッサ構成の画像処理装置において、ＳＷＩＰを使用して処理を行う場合の従来の通信の流れの一例を示す図である。 マルチプロセッサ構成の画像処理装置において、ＡＳＩＣを使用して３個のコマンドを処理する場合の従来の通信の流れの一例を示す図である。 マルチプロセッサ構成の画像処理装置において、ＳＷＩＰを使用して３個のコマンドを処理する場合の従来の通信の流れの一例を示す図である。 本実施の形態に係る画像処理装置のハードウェア構成例を示す図である。 本実施の形態に係る画像処理装置の制御部の構成例を概略的に示す図である。 本実施の形態に係る制御コードテーブルの一例を示す図である。 本実施の形態に係る制御コードテーブルの一例を示す図である。 本実施の形態に係る画像処理装置における一連の処理の流れの一例を説明するための図である。 本実施の形態に係るパッケージコマンドの処理の一例を説明するための図である。

以下、添付図面を参照して、本発明の実施の形態について詳細に説明する。
＜ＯＳ間通信の説明＞
複数のＣＰＵを有するマルチプロセッサ構成の電子装置では、それぞれのＣＰＵが実行するＯＳ間にて通信が行われる場合がある。ここで、マルチプロセッサ構成の電子装置として、画像処理を行う画像処理装置を例に挙げて、画像処理装置内のＯＳ間通信について説明する。

図１は、マルチプロセッサ構成の画像処理装置において、ＡＳＩＣ（application specific integrated circuit）を使用して処理を行う場合の従来の通信の流れの一例を示す図である。ＡＳＩＣとは、ある特定の用途に特化して製造された集積回路である。ここで、図１に示す例では、ＯＳの一例として、ソースコードが公開されるオープンソースであるＬｉｎｕｘ（登録商標）と、時間的な制約がある処理を実行するための機能や特性を備えたリアルタイムＯＳであるＶｘＷｏｒｋｓ（登録商標）を用いている。

ここで、Ｌｉｎｕｘの機能部であるＬｉｎｕｘ４００は、ユーザの操作に基づいて処理を行うアプリケーション４１０、ＯＳ間の通信を制御するＯＳ間通信部４２０を有する。また、ＶｘＷｏｒｋｓの機能部であるＶｘＷｏｒｋｓ５００は、画像処理が行われるＡＳＩＣ５３０、ＡＳＩＣ５３０における画像処理を制御するデバイスドライバ５１０、ＯＳ間の通信を制御するＯＳ間通信部５２０を有する。そして、Ｌｉｎｕｘ４００のアプリケーション４１０からＶｘＷｏｒｋｓ５００にて実行させるコマンドを送信し、ＶｘＷｏｒｋｓ５００から応答が返ってくるまでの通信の流れについて説明する。

例えば、ユーザがアプリケーション４１０により画像処理の指示を行った場合、アプリケーション４１０は、ＶｘＷｏｒｋｓ５００へのコマンドを、ＯＳ間通信部４２０へ送信する（ステップ２０１）。次に、ＯＳ間通信部４２０は、コマンドをＶｘＷｏｒｋｓ５００のＯＳ間通信部５２０へ送信する（ステップ２０２）。次に、ＯＳ間通信部５２０は、コマンドをデバイスドライバ５１０へ送信する（ステップ２０３）。次に、デバイスドライバ５１０は、コマンドを解析して、ＡＳＩＣ５３０のレジスタの値を操作して（例えば、レジスタの値を書き込んだり、レジスタの値を読み込んだりして）、画像処理を実行する（ステップ２０４）。

次に、デバイスドライバ５１０は、画像処理の処理結果を確認する（ステップ２０５）。次に、デバイスドライバ５１０は、処理結果を基に、Ｌｉｎｕｘ４００のアプリケーション４１０に対する応答（応答コマンド）をＯＳ間通信部５２０へ送信する（ステップ２０６）。この応答コマンドには、ＡＳＩＣ５３０における画像処理が成功したか否かを示す情報が含まれている。次に、ＯＳ間通信部５２０は、応答コマンドをＬｉｎｕｘ４００のＯＳ間通信部４２０へ送信する（ステップ２０７）。最後に、ＯＳ間通信部４２０は、応答コマンドをアプリケーション４１０へ送信し（ステップ２０８）、一連の処理は終了する。

ここで、画像処理装置などの電子装置では、高性能なＣＰＵを用いることにより、ＡＳＩＣの代わりに、ソフトウェアによって構成されるソフトウェアＩＰ（Intellectual Property）（以下、ＳＷＩＰと称する）を使用することも考えられる。この場合、ＡＳＩＣにて行われた画像処理がソフトウェアＩＰにて実現されることになる。付言すると、図１に示す構成では、例えば、ＶｘＷｏｒｋｓ５００にてＡＳＩＣ５３０の処理を行うのではなく、Ｌｉｎｕｘ４００にてＳＷＩＰを動作させて画像処理を行うことが可能になる。

図２は、マルチプロセッサ構成の画像処理装置において、ＳＷＩＰを使用して処理を行う場合の従来の通信の流れの一例を示す図である。ここで、Ｌｉｎｕｘ４００はオープンソースであるため、例えば、デバイスドライバ５１０の処理内容を外部に公開しない場合には、デバイスドライバ５１０をＬｉｎｕｘ４００上ではなく、ＶｘＷｏｒｋｓ５００上で動作させることになる。そこで、図２に示す構成では、ＳＷＩＰ４３０をＬｉｎｕｘ４００上で動作させる一方で、デバイスドライバ５１０をＶｘＷｏｒｋｓ５００で動作させる。

Ｌｉｎｕｘ４００は、図１の例と同様にアプリケーション４１０及びＯＳ間通信部４２０を有するとともに、新たにＳＷＩＰ４３０を有する。また、ＶｘＷｏｒｋｓ５００は、図１の例と同様にデバイスドライバ５１０及びＯＳ間通信部５２０を有する一方で、ＡＳＩＣ５３０を有していない。そして、Ｌｉｎｕｘ４００のアプリケーション４１０からＶｘＷｏｒｋｓ５００にて実行させるコマンドを送信し、ＶｘＷｏｒｋｓ５００から応答が返ってくるまでの通信の流れについて説明する。

まず、アプリケーション４１０は、ＶｘＷｏｒｋｓ５００へのコマンドを、ＯＳ間通信部４２０へ送信する（ステップ３０１）。次に、ＯＳ間通信部４２０は、コマンドをＶｘＷｏｒｋｓ５００のＯＳ間通信部５２０へ送信する（ステップ３０２）。次に、ＯＳ間通信部５２０は、コマンドをデバイスドライバ５１０へ送信する（ステップ３０３）。次に、デバイスドライバ５１０は、コマンドを解析して、Ｌｉｎｕｘ４００のＳＷＩＰ４３０にて実行させるコマンドを生成する。そして、生成したコマンドをＯＳ間通信部５２０へ送信する（ステップ３０４）。

次に、ＯＳ間通信部５２０は、ＳＷＩＰ４３０へのコマンドをＬｉｎｕｘ４００のＯＳ間通信部４２０へ送信する（ステップ３０５）。次に、ＯＳ間通信部４２０は、コマンドを解析し、レジスタの値を操作するための関数をＳＷＩＰ４３０へ送信する（ステップ３０６）。次に、ＳＷＩＰ４３０は、関数に従ってレジスタの値を操作して画像処理を実行し、その処理結果をＯＳ間通信部４２０へ送信する（ステップ３０７）。この処理結果には、ＳＷＩＰ４３０における画像処理が成功したか否かを示す情報が含まれている。次に、ＯＳ間通信部４２０は、ＳＷＩＰ４３０による処理結果をＯＳ間通信部５２０へ送信する（ステップ３０８）。

次に、ＯＳ間通信部５２０は、ＳＷＩＰ４３０による処理結果をデバイスドライバ５１０へ送信する（ステップ３０９）。次に、デバイスドライバ５１０は、ＳＷＩＰ４３０による処理結果を基に、Ｌｉｎｕｘ４００のアプリケーション４１０に対する応答（応答コマンド）をＯＳ間通信部５２０へ送信する（ステップ３１０）。次に、ＯＳ間通信部５２０は、応答コマンドをＬｉｎｕｘ４００のＯＳ間通信部４２０へ送信する（ステップ３１１）。最後に、ＯＳ間通信部４２０は、応答コマンドをアプリケーション４１０へ送信し（ステップ３１２）、一連の処理は終了する。

ここで、図１に示すＡＳＩＣ方式と、図２に示すＳＷＩＰ方式とを比較した場合、ＡＳＩＣ方式ではＯＳ間通信（ＯＳ間通信部４２０とＯＳ間通信部５２０との間の通信）の回数は２回であるが、ＳＷＩＰ方式ではＯＳ間通信の回数が４回である。言い換えると、ＳＷＩＰ方式では、ＡＳＩＣ方式に比べて、２倍の回数のＯＳ間通信が行われ、ＯＳ間通信が１往復分増えているといえる。

さらに、図１に示す例、図２に示す例では、アプリケーション４１０が１個のコマンドを送る場合について説明したが、それぞれの構成において、アプリケーション４１０が３個のコマンドを送る場合について説明する。図３は、マルチプロセッサ構成の画像処理装置において、ＡＳＩＣを使用して３個のコマンドを処理する場合の従来の通信の流れの一例を示す図である。また、図４は、マルチプロセッサ構成の画像処理装置において、ＳＷＩＰを使用して３個のコマンドを処理する場合の従来の通信の流れの一例を示す図である。

まず、図３を参照しながら、ＡＳＩＣ方式で３個のコマンドを処理する場合について説明する。ＡＳＩＣ方式では、３個のコマンドのそれぞれについて、図１に示すステップ２０１〜ステップ２０８の処理が行われる。即ち、まず、１つ目のコマンドの処理として、ステップ２０１〜ステップ２０８の処理が行われる。次に、２つ目のコマンドの処理として、ステップ２０１〜ステップ２０８の処理が行われる。さらに、３つ目のコマンドの処理として、ステップ２０１〜ステップ２０８の処理が行われる。そして、３個のコマンドを処理するために、合計６回のＯＳ間通信が行われる。

次に、図４を参照しながら、ＳＷＩＰ方式で３個のコマンドを処理する場合について説明する。ＳＷＩＰ方式では、３個のコマンドのそれぞれについて、図２に示すステップ３０１〜ステップ３１２の処理が行われる。即ち、まず、１つ目のコマンドの処理として、３０１〜ステップ３１２の処理が行われる。次に、２つ目のコマンドの処理として、ステップ３０１〜ステップ３１２の処理が行われる。さらに、３つ目のコマンドの処理として、３０１〜ステップ３１２の処理が行われる。そして、３個のコマンドを処理するために、合計１２回のＯＳ間通信が行われる。
付言すると、３個のコマンドを処理する場合、ＡＳＩＣ方式では６回のＯＳ間通信が行われるが、ＳＷＩＰ方式では１２回のＯＳ間通信が行われる。言い換えると、ＳＷＩＰ方式では、ＡＳＩＣ方式の２倍の回数のＯＳ間通信が行われる。

通常、例えばＬｉｎｕｘやＶｘＷｏｒｋｓなどのＯＳ内で行われる処理の時間は、ＯＳ間で行われるＯＳ間通信の時間に比べて非常に短く、ＯＳ間通信の回数が増えるほど全体の処理時間は長くなる。そのため、従来の方法により、図１に示すＡＳＩＣ方式で行われる処理を、図２に示すＳＷＩＰ方式で実現した場合には、ＯＳ間通信の回数が２倍に増えることになる。即ち、画像処理の処理結果は同じであるのに、全体の処理時間が長くなってしまう。言い換えると、図２に示すＳＷＩＰ方式では、図１に示すＡＳＩＣ方式よりも生産性が低下することになる。
そこで、本実施の形態では、ＯＳ間通信の回数を抑制して、全体の処理時間を短縮するようにする。以下、これを実現するための画像処理装置の構成について説明する。

＜画像処理装置のハードウェア構成＞
本実施の形態に係る画像処理装置１００のハードウェア構成について説明する。図５は、本実施の形態に係る画像処理装置１００のハードウェア構成例を示す図である。本実施の形態に係る画像処理装置１００は、例えば、画像読み取り機能（スキャナー機能）、印刷機能（プリンタ機能）、複写機能（コピー機能）及びファクシミリ機能等の各種の画像処理機能を備えた、いわゆる複合機である。

図示するように、本実施の形態に係る画像処理装置１００は、制御部１１０と、ＨＤＤ（Hard Disk Drive）１２０と、操作パネル１３０と、画像読取部１４０と、画像形成部１５０と、通信インタフェース（以下、「通信Ｉ／Ｆ」と表記する）１６０とを備える。なお、これらの各機能部はバス１７０に接続されており、このバス１７０を介してデータの授受を行う。

制御部１１０は、画像処理装置１００の各部の動作を制御する。この制御部１１０は、ＣＰＵ（Central Processing Unit）１１０ａ、ＲＡＭ（Random Access Memory）１１０ｂ、ＲＯＭ（Read Only Memory）１１０ｃにより構成される。
ＣＰＵ１１０ａは、ＲＯＭ１１０ｃ等に記憶された各種プログラムをＲＡＭ１１０ｂにロードして実行することにより、画像処理装置１００における各機能を実現する。ＲＡＭ１１０ｂは、ＣＰＵ１１０ａの作業用メモリ等として用いられるメモリ（記憶部）である。ＲＯＭ１１０ｃは、ＣＰＵ１１０ａが実行する各種プログラム等を記憶するメモリ（記憶部）である。

また、本実施の形態において、ＣＰＵ１１０ａは複数設けられており、それぞれのＣＰＵ１１０ａが実行するＯＳ間にて通信が行われる。ＣＰＵ１１０ａが実行するＯＳとしては、例えば、Ｌｉｎｕｘ、ＶｘＷｏｒｋｓ等が例示される。以下では、ＯＳの一例として、Ｌｉｎｕｘ及びＶｘＷｏｒｋｓが用いられる場合について説明することとする。

ＨＤＤ１２０は、各種データを記憶する記憶部である。ＨＤＤ１２０には、例えば、画像読取部１４０の画像読み取りによって生成された画像データや、通信Ｉ／Ｆ１６０によって外部から受信した画像データ等が記憶される。

操作パネル１３０は、各種の情報を表示すると共に、各種の機能を用いた動作を行うためのユーザからの操作を受け付ける。操作パネル１３０としては、例えばタッチパネルディスプレイを例示することができる。

画像読取部１４０は、用紙等の記録材に記録された画像を読み取って、読み取った画像のデータ（画像データ）を生成する。ここで、画像読取部１４０は、例えばスキャナーであり、光源から原稿に照射した光に対する反射光をレンズで縮小してＣＣＤ（Charge Coupled Devices）で受光するＣＣＤ方式や、ＬＥＤ光源から原稿に順に照射した光に対する反射光をＣＩＳ（Contact Image Sensor）で受光するＣＩＳ方式のものを用いるとよい。

画像形成部１５０は、用紙等の記録材に画像を形成する印刷機構である。ここで、画像形成部１５０は、例えばプリンターであり、感光体に付着させたトナーを記録材に転写して像を形成する電子写真方式や、インクを記録材上に吐出して像を形成するインクジェット方式のものを用いるとよい。

通信Ｉ／Ｆ１６０は、不図示のネットワークを介して他の装置との間で各種データの送受信を行う通信インタフェースである。

そして、この画像処理装置１００では、制御部１１０による制御の下、画像読取部１４０によってスキャナー機能が実現され、画像形成部１５０によってプリンター機能が実現され、画像読取部１４０及び画像形成部１５０によってコピー機能が実現され、画像読取部１４０、画像形成部１５０及び通信Ｉ／Ｆ１６０によってファクシミリ機能が実現される。

＜制御部の構成＞
図６は、本実施の形態に係る画像処理装置１００の制御部１１０の構成例を概略的に示す図である。本実施の形態に係る制御部１１０では、複数のＣＰＵ１１０ａのうちの一方のＣＰＵ１１０ａによりＬｉｎｕｘのＯＳが実行され、他方のＣＰＵ１１０ａによりＶｘＷｏｒｋｓのＯＳが実行される。そこで、Ｌｉｎｕｘが実行される機能部をＬｉｎｕｘ２００、ＶｘＷｏｒｋｓが実行される機能部をＶｘＷｏｒｋｓ３００とする。

なお、本実施の形態では、第１ＯＳの一例として、Ｌｉｎｕｘが用いられる。第２ＯＳの一例として、ＶｘＷｏｒｋｓが用いられる。また、第１制御手段の一例として、Ｌｉｎｕｘ２００が用いられる。言い換えると、Ｌｉｎｕｘ２００は、ＯＳであるＬｉｎｕｘに基づいて処理を実行する制御手段として捉えることができる。さらに、第２制御手段の一例として、ＶｘＷｏｒｋｓ３００が用いられる。言い換えると、ＶｘＷｏｒｋｓ３００は、ＯＳであるＶｘＷｏｒｋｓに基づいて処理を実行する制御手段として捉えることができる。

まず、Ｌｉｎｕｘ２００の構成について説明する。
Ｌｉｎｕｘ２００は、アプリケーション２１０、ＯＳ間通信部２２０、ＳＷＩＰ２３０を有する。本実施の形態では、コマンド生成部の一例として、アプリケーション２１０が用いられる。また、コマンド送信部の一例として、ＯＳ間通信部２２０が用いられる。

アプリケーション２１０は、各種の情報処理を実行するアプリケーションソフトウェアである。アプリケーション２１０は、例えば、ユーザの操作を受け付けて、画像処理を実行するためのコマンド、言い換えると、ＶｘＷｏｒｋｓ３００が実行するコマンドを生成し、生成したコマンドをＯＳ間通信部２２０へ送信する。

ＯＳ間通信部２２０は、アプリケーション２１０から受信したコマンドを、ＶｘＷｏｒｋｓ３００のＯＳ間通信部３２０へ送信する。ここで、ＯＳ間通信部２２０は、アプリケーション２１０からコマンドを受信すると、受信したコマンドを一時的に記憶部に格納し、アプリケーション２１０へ応答する。また、ＯＳ間通信部２２０は、受信した複数のコマンドに対して制御コードを付与して、複数のコマンド及び制御コードをパッケージングする。そして、ＯＳ間通信部２２０は、複数のコマンド及び制御コードをパッケージングしたもの（以下、パッケージコマンドと称する）を、ＯＳ間通信部３２０へ送信する。

より具体的には、ＯＳ間通信部２２０は、ＶｘＷｏｒｋｓ３００が実行する複数のコマンドと制御コードとが予め対応付けられているテーブル（以下、制御コードテーブルと称する）を有している。言い換えると、この制御コードテーブルは、ユーザにより指示された画像処理を実行するための複数のコマンドと制御コードとが予め対応付けられているテーブルと捉えることもできる。本実施の形態において、制御コードテーブルは、対応関係の一例として用いられる。
そして、ＯＳ間通信部２２０は、制御コードテーブルを参照して、一時的に記憶部に格納した複数のコマンドに対応する制御コードが存在するか否かを判定する。ＯＳ間通信部２２０は、一時的に記憶部に格納した複数のコマンドに対応する制御コードが存在すると判定した場合、一時的に記憶部に格納した複数のコマンド（即ち、アプリケーション２１０から受信した複数のコマンド）に対して、特定した制御コードを付与して、パッケージコマンドを生成する。

なお、制御コードには、パッケージコマンドに含まれる複数のコマンドの実行手順が定められている。実行手順としては、例えば、パッケージコマンドに含まれる各コマンドを実行する順番、パッケージコマンドに含まれる各コマンドの実行を終了する条件などが例示される。また、実行手順として、例えば、パッケージコマンドに含まれる一のコマンドの実行に成功した場合に次に実行されるコマンドや、パッケージコマンドに含まれる一のコマンドの実行に失敗した場合に次に実行されるコマンド等を定めても良い。制御コードの詳細については後述する。

また、後述するように、ＶｘＷｏｒｋｓ３００のＯＳ間通信部３２０も、ＯＳ間通信部２２０と同様に、デバイスドライバ３１０にて生成されたコマンド及び制御コードをパッケージングしたパッケージコマンドを生成する。そこで、ＯＳ間通信部２２０は、ＶｘＷｏｒｋｓ３００のＯＳ間通信部３２０から、このパッケージコマンドを受信する。ＯＳ間通信部２２０は、ＯＳ間通信部３２０からパッケージコマンドを受信すると、受信したパッケージコマンドに含まれる制御コードに基づいて、パッケージコマンドに含まれる各コマンドを実行する順番を把握する。そして、ＯＳ間通信部２２０は、把握した順番に従ってパッケージコマンドの中から１個ずつコマンドを取り出して、取り出したコマンドを解析し、レジスタの値を操作する関数をＳＷＩＰ２３０へ送信する。

ここで、ＯＳ間通信部２２０は、関数をＳＷＩＰ２３０に送る毎に、ＳＷＩＰ２３０からその関数の処理結果を受け取る。そして、ＯＳ間通信部２２０は、受け取った処理結果と制御コードとを照らし合わせて、以降の処理を行う。より具体的には、ＯＳ間通信部２２０は、受け取った処理結果と制御コードとに基づいて、例えば、パッケージコマンドに含まれるコマンドを引き続き実行したり、パッケージコマンドの処理を終了したりする。

ＳＷＩＰ２３０は、ＯＳ間通信部２２０から、レジスタの値を操作する関数を受け取り、受け取った関数に従ってレジスタの値を操作して画像処理を行う。そして、ＳＷＩＰ２３０は、画像処理の処理結果をＯＳ間通信部２２０へ送信する。この処理結果には、ＳＷＩＰ２３０における画像処理が成功したか否かを示す情報が含まれている。

次に、ＶｘＷｏｒｋｓ３００の構成について説明する。ＶｘＷｏｒｋｓ３００は、デバイスドライバ３１０、ＯＳ間通信部３２０を有する。

ＯＳ間通信部３２０は、Ｌｉｎｕｘ２００のＯＳ間通信部２２０から、ＯＳ間通信部２２０にて生成されたパッケージコマンドを受信する。ＯＳ間通信部３２０は、パッケージコマンドを受信すると、受信したパッケージコマンドに含まれる制御コードに基づいて、パッケージコマンドに含まれる各コマンドを実行する順番を把握する。そして、ＯＳ間通信部３２０は、把握した順番に従ってパッケージコマンドの中から１個ずつコマンドを取り出して、取り出したコマンドをデバイスドライバ３１０へ送信する。

ここで、ＯＳ間通信部３２０は、コマンドをデバイスドライバ３１０に送る毎に、デバイスドライバ３１０からそのコマンドの処理結果を受け取る。そして、ＯＳ間通信部３２０は、受け取った処理結果と制御コードとを照らし合わせて、以降の処理を行う。より具体的には、ＯＳ間通信部３２０は、受け取った処理結果と制御コードとに基づいて、例えば、パッケージコマンドに含まれるコマンドを引き続きデバイスドライバ３１０へ送信したり、パッケージコマンドの処理を終了したりする。

また、後述するように、デバイスドライバ３１０は、ＯＳ間通信部３２０から受信したコマンドを処理することにより、ＳＷＩＰ２３０にて実行させるコマンドを生成する。即ち、ＯＳ間通信部３２０は、デバイスドライバ３１０によるコマンドの処理結果として、ＳＷＩＰ２３０にて実行させるコマンドを受信する。そこで、ＯＳ間通信部３２０は、デバイスドライバ３１０から、ＳＷＩＰ２３０にて実行させるコマンドを受信すると、受信したコマンドを一時的に記憶部に格納する。そして、ＯＳ間通信部３２０は、受信した複数のコマンドに対して制御コードを付与して、複数のコマンド及び制御コードをパッケージングしたパッケージコマンドをＯＳ間通信部２２０へ送信する。

ここで、ＯＳ間通信部３２０は、ＯＳ間通信部２２０と同様に、Ｌｉｎｕｘ２００が実行する複数のコマンドと制御コードとが予め対応付けられている制御コードテーブルを有している。そして、ＯＳ間通信部３２０は、制御コードテーブルを参照して、一時的に記憶部に格納した複数のコマンドに対応する制御コードが存在するか否かを判定する。ＯＳ間通信部３２０は、一時的に格納した複数のコマンドに対応する制御コードが存在すると判定した場合、一時的に格納した複数のコマンド（即ち、デバイスドライバ３１０から受信した複数のコマンド）に対して、特定した制御コードを付与して、パッケージコマンドを生成する。

デバイスドライバ３１０は、電子装置の内部に装着された装置や、外部に接続した機器を制御するためのソフトウェアであり、ＶｘＷｏｒｋｓ３００がこのような装置・機器を制御するための橋渡しを行うものである。このデバイスドライバ３１０は、ＶｘＷｏｒｋｓ３００に組み込まれて、Ｌｉｎｕｘ２００のＳＷＩＰ２３０を制御する。
より具体的には、デバイスドライバ３１０は、ＯＳ間通信部３２０から受信したコマンドを解析して、Ｌｉｎｕｘ２００のＳＷＩＰ２３０にて実行させるコマンドを生成する。そして、デバイスドライバ３１０は、生成したコマンドをＯＳ間通信部３２０へ送信する。

＜制御コードの説明＞
次に、制御コードについて詳細に説明する。図７−１及び図７−２は、本実施の形態に係る制御コードテーブルの一例を示す図である。図７−１に示す制御コードテーブルは、ＯＳ間通信部２２０が有する制御コードテーブルの一例である。また、図７−２に示す制御コードテーブルは、ＯＳ間通信部３２０が有する制御コードテーブルの一例である。

図７−１に示す制御コードテーブルにおいて、例えば、制御コード２１には、コマンド１〜コマンド３についての実行手順が定められている。より具体的には、例えば、「最初に実行するコマンドは、コマンド１であること」が定められている。また、例えば、「コマンド１の処理が成功した場合には、次にコマンド２を実行すること」、「コマンド２の処理が成功した場合には、次にコマンド３を実行すること」、「コマンド３の処理が成功した場合には、パッケージコマンドの処理が成功したものとして終了すること」が定められている。さらに、例えば、「コマンド１の処理が失敗した場合には、パッケージコマンドの処理が失敗したものとして終了すること」、「コマンド２の処理が失敗した場合には、パッケージコマンドの処理が失敗したものとして終了すること」、「コマンド３の処理が失敗した場合には、パッケージコマンドの処理が失敗したものとして終了すること」が定められている。

また、例えば、制御コード２２には、コマンドａ〜ｃについての実行手順が定められている。より具体的には、例えば、「最初に実行するコマンドは、コマンドａであること」が定められている。また、例えば、「コマンドａの処理が成功した場合には、次にコマンドｂを実行すること」、「コマンドｂの処理が成功した場合には、次にコマンドｃを実行すること」、「コマンドｃの処理が成功した場合には、パッケージコマンドの処理が成功したものとして終了すること」が定められている。さらに、例えば、「コマンドａの処理が失敗した場合には、次にコマンドｃを実行すること」、「コマンドｂの処理が失敗した場合には、パッケージコマンドの処理が失敗したものとして終了すること」、「コマンドｃの処理が失敗した場合には、パッケージコマンドの処理が失敗したものとして終了すること」が定められている。なお、ここでは、コマンドａの処理が失敗した場合にコマンドｃを実行することとしたが、コマンドａの代替となるコマンドの一例として、コマンドａ〜コマンドｃとは別のコマンドｄを実行することが定められていても良い。

このようにして、ＯＳ間通信部２２０が有する制御コードテーブルには、アプリケーション２１０から受信する複数のコマンドと制御コードとが予め対応付けられている。そして、制御コードには、例えば、複数のコマンドを実行する順番、複数のコマンドの実行を終了する条件等が定められている。また、例えば、複数のコマンドのうちの一のコマンドの実行に成功した場合に次に実行されるコマンドや、複数のコマンドのうちの一のコマンドの実行に失敗した場合に次に実行されるコマンド等が定められている。

また、図７−２のＯＳ間通信部３２０が有する制御コードテーブルでは、図７−１のＯＳ間通信部２２０が有する制御コードテーブルと同様に、デバイスドライバ３１０から受信する複数のコマンドと制御コードとが予め対応付けられている。
例えば、制御コード３１には、コマンド４〜コマンド６についての実行手順が定められている。より具体的には、例えば、「最初に実行するコマンドは、コマンド４であること」が定められている。また、例えば、「コマンド４の処理が成功した場合には、次にコマンド５を実行すること」、「コマンド５の処理が成功した場合には、次にコマンド６を実行すること」、「コマンド６の処理が成功した場合には、パッケージコマンドの処理が成功したものとして終了すること」が定められている。さらに、例えば、「コマンド４の処理が失敗した場合には、パッケージコマンドの処理が失敗したものとして終了すること」、「コマンド５の処理が失敗した場合には、パッケージコマンドの処理が失敗したものとして終了すること」、「コマンド６の処理が失敗した場合には、パッケージコマンドの処理が失敗したものとして終了すること」が定められている。

また、例えば、制御コード３２には、コマンドｄ〜ｆについての実行手順が定められている。より具体的には、例えば、「最初に実行するコマンドは、コマンドｄであること」が定められている。また、例えば、「コマンドｄの処理が成功した場合には、次にコマンドｅを実行すること」、「コマンドｅの処理が成功した場合には、次にコマンドｆを実行すること」、「コマンドｆの処理が成功した場合には、パッケージコマンドの処理が成功したものとして終了すること」が定められている。さらに、例えば、「コマンドｄの処理が失敗した場合には、次にコマンドｆを実行すること」、「コマンドｅの処理が失敗した場合には、パッケージコマンドの処理が失敗したものとして終了すること」、「コマンドｆの処理が失敗した場合には、パッケージコマンドの処理が失敗したものとして終了すること」が定められている。なお、ここでは、コマンドｄの処理が失敗した場合にコマンドｆを実行することとしたが、コマンドｄの代替となるコマンドの一例として、コマンドｄ〜コマンドｆとは別のコマンドｇを実行することが定められていても良い。

このようにして、ＯＳ間通信部３２０が有する制御コードテーブルには、デバイスドライバ３１０から受信する複数のコマンドと制御コードとが予め対応付けられている。そして、制御コードには、例えば、複数のコマンドを実行する順番、複数のコマンドの実行を終了する条件等が定められている。また、例えば、複数のコマンドのうちの一のコマンドの実行に成功した場合に次に実行されるコマンドや、複数のコマンドのうちの一のコマンドの実行に失敗した場合に次に実行されるコマンド等が定められている。

＜画像処理装置における一連の処理の説明＞
次に、本実施の形態に係る画像処理装置１００における一連の処理の流れについて説明する。図８は、本実施の形態に係る画像処理装置１００における一連の処理の流れの一例を説明するための図である。図８に示す例では、アプリケーション２１０が３個のコマンドを送信し、ＯＳ間通信部２２０が３個のコマンドをパッケージングしてパッケージコマンドを生成するものとして説明する。なお、この３個のコマンドを、「コマンド１」、「コマンド２」、「コマンド３」とする。また、ＯＳ間通信部２２０は図７−１に示す制御コードテーブルを有し、ＯＳ間通信部３２０は図７−２に示す制御コードテーブルを有しているものとする。

まず、例えば、ユーザがアプリケーション２１０により画像処理の指示を行った場合、アプリケーション２１０は、指示された画像処理を実行するためのコマンド１〜コマンド３をＯＳ間通信部２２０へ送信する。ここで、アプリケーション２１０は、まず、１個目のコマンド１をＯＳ間通信部２２０へ送信する（ステップ１０１）。次に、ＯＳ間通信部２２０は、受信したコマンド１を一時的に記憶部に格納し、アプリケーション２１０へ応答する（ステップ１０２）。次に、アプリケーション２１０は、２個目のコマンド２をＯＳ間通信部２２０へ送信する（ステップ１０３）。次に、ＯＳ間通信部２２０は、受信したコマンド２を一時的に記憶部に格納し、アプリケーション２１０へ応答する（ステップ１０４）。次に、アプリケーション２１０は、３個目のコマンド３をＯＳ間通信部２２０へ送信する（ステップ１０５）。

ここで、制御コードテーブルには、３個のコマンド（コマンド１〜３）に対応する制御コードが存在する。そこで、ＯＳ間通信部２２０は、制御コードテーブルを参照した結果、一時的に記憶部に格納した３個のコマンド（コマンド１〜３）に対応する制御コードが存在すると判定し、その制御コードを特定する。次に、ＯＳ間通信部２２０は、３個のコマンドに対して、特定した制御コードを付与してパッケージングする。そして、ＯＳ間通信部２２０は、生成したパッケージコマンドをＶｘＷｏｒｋｓ３００のＯＳ間通信部３２０へ送信する（ステップ１０６）。なお、図８に示す例では、図７−１に示す制御コード２１が付与される。

次に、ＯＳ間通信部３２０は、受信したパッケージコマンドに含まれる制御コード２１に基づいて、パッケージコマンドに含まれる各コマンドを実行する順番を把握する。そして、ＯＳ間通信部３２０は、把握した順番に従ってパッケージコマンドの中から１個ずつコマンドを取り出して、取り出したコマンドをデバイスドライバ３１０へ送信する。ここで、ＯＳ間通信部３２０は、まず、１つ目のコマンド１をデバイスドライバ３１０へ送信する（ステップ１０７）。

次に、デバイスドライバ３１０は、コマンド１を解析して、Ｌｉｎｕｘ２００のＳＷＩＰ２３０にて実行させる１つ目のコマンド（図示の例では、コマンド４とする）を生成する。そして、デバイスドライバ３１０は、生成したコマンド４をＯＳ間通信部３２０へ送信する（ステップ１０８）。次に、ＯＳ間通信部３２０は、コマンド１の処理結果と制御コード２１とを照らし合わせて、以降の処理を行う。ここでは、コマンド４が生成されており、コマンド１の処理結果は成功なので、ＯＳ間通信部３２０は、次にコマンド２を実行することを決定する。そして、ＯＳ間通信部３２０は、２つ目のコマンド２をデバイスドライバ３１０へ送信する（ステップ１０９）。

次に、デバイスドライバ３１０は、コマンド２を解析して、Ｌｉｎｕｘ２００のＳＷＩＰ２３０にて実行させる２つ目のコマンド（図示の例では、コマンド５とする）を生成する。そして、デバイスドライバ３１０は、生成したコマンド５をＯＳ間通信部３２０へ送信する（ステップ１１０）。次に、ＯＳ間通信部３２０は、コマンド２の処理結果と制御コード２１とを照らし合わせて、以降の処理を行う。ここでは、コマンド５が生成されており、コマンド２の処理結果は成功なので、ＯＳ間通信部３２０は、次にコマンド３を実行することを決定する。そして、ＯＳ間通信部３２０は、３つ目のコマンド３をデバイスドライバ３１０へ送信する（ステップ１１１）。

次に、デバイスドライバ３１０は、コマンド３を解析して、Ｌｉｎｕｘ２００のＳＷＩＰ２３０にて実行させる３つ目のコマンド（図示の例では、コマンド６とする）を生成する。そして、デバイスドライバ３１０は、生成したコマンド６をＯＳ間通信部３２０へ送信する（ステップ１１２）。次に、ＯＳ間通信部３２０は、コマンド３の処理結果と制御コード２１とを照らし合わせて、以降の処理を行う。ここでは、コマンド６が生成されており、コマンド３の処理結果は成功なので、ＯＳ間通信部３２０は、パッケージコマンドの処理を終了することを決定する。これにより、ＯＳ間通信部２２０が生成したパッケージコマンドについての処理は終了する。次に、デバイスドライバ３１０により生成された３個のコマンド（即ち、コマンド４〜６）を含むパッケージコマンドについての処理が行われる。

ここで、制御コードテーブルには、３個のコマンド（コマンド４〜６）に対応する制御コードが存在する。そこで、ＯＳ間通信部３２０は、制御コードテーブルを参照した結果、一時的に記憶部に格納した３個のコマンド（コマンド４〜６）に対応する制御コードが存在すると判定し、その制御コードを特定する。次に、ＯＳ間通信部３２０は、３個のコマンドに対して、特定した制御コードを付与してパッケージングする。そして、ＯＳ間通信部３２０は、生成したパッケージコマンドをＬｉｎｕｘ２００のＯＳ間通信部２２０へ送信する（ステップ１１３）。なお、図８に示す例では、図７−２に示す制御コード３１が付与される。

次に、ＯＳ間通信部２２０は、受信したパッケージコマンドに含まれる制御コード３１に基づいて、パッケージコマンドに含まれる各コマンドを実行する順番を把握する。そして、ＯＳ間通信部２２０は、把握した順番に従ってパッケージコマンドの中から１個ずつコマンドを取り出して、取り出したコマンドを解析し、レジスタの値を操作する関数をＳＷＩＰ２３０へ送信する。ここで、ＯＳ間通信部２２０は、まず、１つ目のコマンド４を解析して、レジスタの値を操作する関数をＳＷＩＰ２３０へ送信する（ステップ１１４）。

次に、ＳＷＩＰ２３０は、コマンド４に基づく関数に従って画像処理を行い、その処理結果をＯＳ間通信部２２０へ送信する（ステップ１１５）。この処理結果には、ＳＷＩＰ２３０における画像処理が成功したか否かを示す情報が含まれている。次に、ＯＳ間通信部２２０は、処理結果と制御コード３１とを照らし合わせて、以降の処理を行う。ここで、処理結果が成功であれば、ＯＳ間通信部２２０は、次に、２つ目のコマンド５を実行することを決定する。そして、ＯＳ間通信部２２０は、コマンド５を解析し、レジスタの値を操作する関数をＳＷＩＰ２３０へ送信する（ステップ１１６）。

次に、ＳＷＩＰ２３０は、コマンド５に基づく関数に従って画像処理を行い、その処理結果をＯＳ間通信部２２０へ送信する（ステップ１１７）。次に、ＯＳ間通信部２２０は、処理結果と制御コード３１とを照らし合わせて、以降の処理を行う。ここで、処理結果が成功であれば、ＯＳ間通信部２２０は、次に、３つ目のコマンド６を実行することを決定する。そして、ＯＳ間通信部２２０は、コマンド６を解析し、レジスタの値を操作する関数をＳＷＩＰ２３０へ送信する（ステップ１１８）。

次に、ＳＷＩＰ２３０は、コマンド６に基づく関数に従って画像処理を行い、その処理結果をＯＳ間通信部２２０へ送信する（ステップ１１９）。次に、ＯＳ間通信部２２０は、処理結果と制御コード３１とを照らし合わせて、以降の処理を行う。ここで、処理結果が成功であれば、ＯＳ間通信部２２０は、パッケージコマンドの処理を終了することを決定する。そして、ＯＳ間通信部２２０は、コマンド４〜６の処理が成功したことを示す応答コマンドを、ＶｘＷｏｒｋｓ３００のＯＳ間通信部３２０へ送信する（ステップ１２０）。

次に、ＯＳ間通信部３２０は、応答コマンドをデバイスドライバ３１０へ送信する（ステップ１２１）。次に、デバイスドライバ３１０は、アプリケーション２１０への応答コマンドをＯＳ間通信部３２０へ送信する（ステップ１２２）。ここで、アプリケーション２１０への応答コマンドには、画像処理に成功した旨を示す情報が含まれる。次に、ＯＳ間通信部３２０は、アプリケーション２１０への応答コマンドを、Ｌｉｎｕｘ２００のＯＳ間通信部２２０へ送信する（ステップ１２３）。次に、ＯＳ間通信部２２０は、アプリケーション２１０への応答コマンドを、アプリケーション２１０へ送信する（ステップ１２４）。そして、画像処理装置１００における一連の処理は終了する。

このように、本実施の形態において、ＳＷＩＰ方式にて例えば３個のコマンドを処理する場合、ＶｘＷｏｒｋｓ３００は、３個のコマンドのそれぞれを実行する度にコマンドの実行結果をＬｉｎｕｘ２００へ送信するのではなく、３個のコマンドの処理が終了した後にその処理結果をＬｉｎｕｘ２００へ送信する。また、Ｌｉｎｕｘ２００も、受信したパッケージコマンドの処理が終了した後にその処理結果をＶｘＷｏｒｋｓ３００へ送信する。そして、ステップ１０６、ステップ１１３、ステップ１２０、ステップ１２３においてＯＳ間通信が行われる。言い換えると、アプリケーション２１０にて生成された３個のコマンドを処理するために、４回のＯＳ間通信が行われる。図１に示す従来のＡＳＩＣ方式では、３個のコマンドを処理する場合、上述したように、６回のＯＳ間通信が行われる。また、図２に示す従来のＳＷＩＰ方式では、３個のコマンドを処理する場合、上述したように、１２回のＯＳ間通信が行われる。

一方、本実施の形態において、制御部１１０は、複数のコマンドに制御コードを付与してパッケージコマンドを生成し、パッケージコマンドから１個ずつコマンドを取り出して実行する。また、制御部１１０は、コマンドの処理結果と制御コードとに基づいて、以降の処理を行う。このようにして、制御コードを付与して複数のコマンドを処理することにより、例えば、従来のＡＳＩＣ方式及びＳＷＩＰ方式のようにコマンド毎にＯＳ間通信が発生する構成と比較して、ＯＳ間通信の回数が削減され、全体の処理時間が短縮される。言い換えると、本実施の形態では、例えば、従来のＡＳＩＣ方式及びＳＷＩＰ方式と比較して、画像処理についての生産性の低下が抑制される。

ここで、図８に示す例では、パッケージコマンドに含まれる各コマンド（コマンド１〜６）のそれぞれの処理が成功した場合を示したが、コマンドの処理が失敗する場合も考えられる。そこで、コマンドの処理が失敗した場合について説明する。

図７−１に示す制御コード２１では、コマンド１について、「コマンド１の処理が失敗した場合には、パッケージコマンドの処理が失敗したものとして終了すること」が定められている。ここで、コマンド１の処理が失敗した場合、言い換えると、ステップ１０８でコマンド４の生成に失敗した場合、デバイスドライバ３１０は、コマンド１による処理に失敗した旨を示す情報をＯＳ間通信部３２０へ送信する。次に、ＯＳ間通信部３２０は、コマンド１の処理結果が失敗なので、２つ目のコマンド２をデバイスドライバ３１０へ送信せずに、パッケージコマンドの処理が失敗したものとして終了する。このように、パッケージコマンドの処理が終了した場合、以降のステップ１０９〜ステップ１２２の処理は行われず、ステップ１２３において、ＯＳ間通信部３２０は、アプリケーション２１０への応答コマンドをＬｉｎｕｘ２００のＯＳ間通信部２２０へ送信する。この応答コマンドには、画像処理に失敗した旨を示す情報が含まれる。

また、図７−２に示す制御コード３１では、コマンド４について、「コマンド４の処理が失敗した場合には、パッケージコマンドの処理が失敗したものとして終了すること」が定められている。ここで、コマンド４に基づく画像処理が失敗した場合、ステップ１１５において、ＳＷＩＰ２３０は、コマンド４に基づく画像処理に失敗した旨の処理結果をＯＳ間通信部２２０へ送信する。次に、ＯＳ間通信部２２０は、処理結果が失敗なので、２つ目のコマンド５をＳＷＩＰ２３０へ送信せずに、パッケージコマンドの処理を終了する。このように、パッケージコマンドの処理が終了した場合、以降のステップ１１６〜ステップ１１９の処理は行われず、ステップ１２０において、ＯＳ間通信部２２０は、コマンド４〜６の処理が失敗したことを示す応答コマンドをＶｘＷｏｒｋｓ３００のＯＳ間通信部３２０へ送信する。その後、ステップ１２１〜ステップ１２４では、ＯＳ間通信部３２０、デバイスドライバ３１０、ＯＳ間通信部２２０、アプリケーション２１０において、処理が失敗したことを示す応答コマンドが送受信される。

また、例えば、図７−１に示す制御コード２２のコマンドａや、図７−２に示す制御コード３２のコマンドｄのように、コマンドの処理が成功した場合に次に実行されるコマンドと、コマンドの処理が失敗した場合に次に実行されるコマンドとが異なっても良い。この場合、コマンドの処理結果に応じて、次に実行されるコマンドが変わることになる。

より具体的には、図８に示す例において、例えば、コマンド１について、「コマンド１の処理結果が成功の場合には、次にコマンド２を実行すること」、「コマンド１の処理結果が失敗の場合には、次にコマンド３を実行すること」が定められているとする。この場合、コマンド１の処理が失敗した場合には、ステップ１０９及びステップ１１０の処理は行われず、ステップ１１１の処理が行われる。即ち、ＯＳ間通信部３２０は、デバイスドライバ３１０に対して、２つ目のコマンド２を送信せずに、３つ目のコマンド３を送信する。この後、ＯＳ間通信部３２０は、コマンド１により生成されたコマンド４、及びコマンド３により生成されたコマンド６に対して、制御コードを付与してパッケージングする。そして、ステップ１１３において、ＯＳ間通信部３２０は、生成したパッケージコマンドをＬｉｎｕｘ２００のＯＳ間通信部２２０へ送信する。

また、図８に示す例において、例えば、コマンド４について、「コマンド４の処理結果が成功の場合には、次にコマンド５を実行すること」、「コマンド４の処理結果が失敗の場合には、次にコマンド６を実行すること」が定められているとする。この場合、コマンド４の処理が失敗した場合には、ステップ１１６及びステップ１１７の処理は行われず、ステップ１１８の処理が行われる。即ち、ＯＳ間通信部２２０は、２つ目のコマンド５を解析せずに、３つ目のコマンド６を解析して、コマンド６に基づく関数をＳＷＩＰ２３０へ送信する。この後、コマンド６に基づく関数の処理が成功した場合には、パッケージコマンドの処理は成功したこととなり、ステップ１２０において、ＯＳ間通信部３２０は、コマンド４〜６の処理が成功したことを示す応答コマンドを、ＶｘＷｏｒｋｓ３００のＯＳ間通信部３２０へ送信する。

＜パッケージコマンドの処理の説明＞
図９を参照しながら、さらに、本実施の形態に係るパッケージコマンドの処理について説明する。図９は、本実施の形態に係るパッケージコマンドの処理の一例を説明するための図である。図９に示す例では、図８に示す例と同様に、アプリケーション２１０が３個のコマンド（コマンド１〜３）を送信し、ＯＳ間通信部２２０が３個のコマンドをパッケージングしてパッケージコマンドを生成するものとする。また、以下に示すステップ、及び図９に示すステップは、図８の各ステップに対応する。

まず、アプリケーション２１０は、コマンド１〜３を１個ずつＯＳ間通信部２２０へ送信する（ステップ１０１〜ステップ１０５）。次に、ＯＳ間通信部２２０は、制御コードテーブルを参照して、３個のコマンド（コマンド１〜３）に対応する制御コードを付与してパッケージングする。そして、ＯＳ間通信部２２０は、パッケージコマンドをＶｘＷｏｒｋｓ３００のＯＳ間通信部３２０へ送信する（ステップ１０６）。なお、図９に示す例では、図７−１に示す制御コード２１が付与されるものとする。

次に、ＯＳ間通信部３２０は、受信したパッケージコマンドに含まれる制御コード２１に基づいて、１つ目のコマンド１を取り出して、デバイスドライバ３１０へ送信する（ステップ１０７）。次に、デバイスドライバ３１０は、コマンド１を解析して、Ｌｉｎｕｘ２００のＳＷＩＰ２３０にて実行させる１つ目のコマンド（図８と同様に、コマンド４とする）を生成する。そして、デバイスドライバ３１０は、生成したコマンド４をＯＳ間通信部３２０へ送信する（ステップ１０８）。

次に、ＯＳ間通信部３２０は、コマンド１の処理結果と制御コード２１とを照らし合わせて、コマンド２を実行することを決定する。そして、ＯＳ間通信部３２０は、コマンド２をデバイスドライバ３１０へ送信する（ステップ１０９）。次に、デバイスドライバ３１０は、コマンド２を解析して、Ｌｉｎｕｘ２００のＳＷＩＰ２３０にて実行させる２つ目のコマンド（図８と同様に、コマンド５とする）を生成する。そして、デバイスドライバ３１０は、生成したコマンド５をＯＳ間通信部３２０へ送信する（ステップ１１０）。

次に、ＯＳ間通信部３２０は、コマンド２の処理結果と制御コード２１とを照らし合わせて、コマンド３を実行することを決定する。そして、ＯＳ間通信部３２０は、コマンド３をデバイスドライバ３１０へ送信する（ステップ１１１）。次に、デバイスドライバ３１０は、コマンド３を解析して、Ｌｉｎｕｘ２００のＳＷＩＰ２３０にて実行させる３つ目のコマンド（図８と同様に、コマンド６とする）を生成する。そして、デバイスドライバ３１０は、生成したコマンド６をＯＳ間通信部３２０へ送信する（ステップ１１２）。

このように、アプリケーション２１０が送信したコマンドに対して制御コードが付与され、パッケージングされる。また、制御コードに定められた実行手順に従ってパッケージコマンドの中のコマンドが順番に取り出されて、実行される。なお、図９にはステップ１０１〜ステップ１１２の処理しか示していないが、ステップ１１２の処理の後、図８のステップ１１３以降の処理が行われる。

なお、本実施の形態において、画像処理装置１００はＳＷＩＰ２３０を有するものとしたが、このような構成に限られるものではない。例えば、図１に示すようなＡＳＩＣを有するマルチプロセッサ構成の画像処理装置においてもＯＳ間通信は行われるため、このようなＯＳ間通信に対しても、本実施の形態を適用することができる。

また、本実施の形態では、Ｌｉｎｕｘ及びＶｘＷｏｒｋｓにおけるＯＳ間通信について説明したが、このような構成に限られるものではない。Ｌｉｎｕｘ、ＶｘＷｏｒｋｓではない他のＯＳでＯＳ間通信が行われる場合にも、本実施の形態を適用することができる。

さらに、本実施の形態を画像処理装置１００に適用した例について説明したが、本実施の形態の適用対象は画像処理装置１００に限定されない。マルチプロセッサ構成の電子装置であって、個々のＣＰＵが使用するメモリ（記憶部）が独立しておりＯＳ間通信が行われる種々の機器（電子装置）であれば、本実施の形態を適用することができる。

なお、上記では種々の実施形態および変形例を説明したが、これらの実施形態や変形例どうしを組み合わせて構成してももちろんよい。
また、本開示は上記の実施形態に何ら限定されるものではなく、本開示の要旨を逸脱しない範囲で種々の形態で実施することができる。

１００…画像処理装置、１１０…制御部、２００…Ｌｉｎｕｘ、２１０…アプリケーション、２２０…ＯＳ間通信部、２３０…ＳＷＩＰ、３００…ＶｘＷｏｒｋｓ、３１０…デバイスドライバ、３２０…ＯＳ間通信部

Claims (8)

1. 第１ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）に基づいて処理を実行する第１制御手段と、第２ＯＳに基づいて処理を実行する第２制御手段とを備え、
   前記第１制御手段は、
   前記第２制御手段が実行するコマンドを生成するコマンド生成部と、
   前記第２制御手段が実行する複数のコマンドと当該複数のコマンドの実行手順を定めた制御コードとを予め対応付けた対応関係を有し、前記コマンド生成部により生成された複数のコマンドに対応する制御コードが前記対応関係に存在する場合、当該複数のコマンドに当該制御コードを付与して前記第２制御手段へ送信するコマンド送信部とを備え、
   前記第２制御手段は、前記コマンド送信部から送信された前記複数のコマンドを受信すると、付与された前記制御コードに定められた前記実行手順に基づいて当該複数のコマンドを実行すること
   を特徴とする電子装置。
2. 前記第２制御手段は、前記複数のコマンドのそれぞれを実行する度にコマンドの実行結果を前記第１制御手段へ送信せずに、前記複数のコマンドの処理が終了した後に当該複数のコマンドの処理結果を当該第１制御手段へ送信すること
   を特徴とする請求項１に記載の電子装置。
3. 前記第２制御手段は、前記複数のコマンドの処理結果として、前記第１制御手段が実行する複数のコマンドに当該複数のコマンドの実行手順を定めた制御コードを付与して当該第１制御手段へ送信すること
   を特徴とする請求項２に記載の電子装置。
4. 前記第２制御手段は、前記複数のコマンドのうちの一のコマンドを実行する場合、前記制御コードに定められた前記実行手順と当該一のコマンドの実行結果とにより、当該一のコマンドを実行した後の処理を行うこと
   を特徴とする請求項１に記載の電子装置。
5. 前記第２制御手段は、前記一のコマンドの実行に成功した場合、成功した場合に実行するコマンドとして前記制御コードに定められた他のコマンドを実行し、当該一のコマンドの実行に失敗した場合、当該他のコマンドを実行せずに前記複数のコマンドの実行を終了すること
   を特徴とする請求項４に記載の電子装置。
6. 前記第２制御手段は、前記一のコマンドの実行に成功した場合、成功した場合に実行するコマンドとして前記制御コードに定められたコマンドを実行し、当該一のコマンドの実行に失敗した場合、失敗した場合に実行するコマンドとして当該制御コードに定められたコマンドを実行すること
   を特徴とする請求項４に記載の電子装置。
7. 第１ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）に基づいて処理を実行する第１制御手段と、
   第２ＯＳに基づいて処理を実行する第２制御手段とを備え、
   前記第１制御手段は、前記第２制御手段が実行する複数のコマンド及び当該複数のコマンドの実行手順を定めた制御コードをまとめて当該第２制御手段へ送信し、
   前記第２制御手段は、前記第１制御手段から受信した前記制御コードの前記実行手順を基に前記複数のコマンドを実行すること
   を特徴とする電子装置。
8. 第１ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）に基づいて処理を実行する第１制御手段と、第２ＯＳに基づいて処理を実行する第２制御手段とを備え、
   前記第１制御手段は、
   前記第２制御手段が実行するコマンドを生成するコマンド生成部と、
   ユーザにより指示された画像処理を実行するための複数のコマンドと当該複数のコマンドの実行手順を定めた制御コードとを予め対応付けた対応関係を有し、前記コマンド生成部により生成された複数のコマンドに対応する制御コードが前記対応関係に存在する場合、当該複数のコマンドに当該制御コードを付与して前記第２制御手段へ送信するコマンド送信部とを備え、
   前記第２制御手段は、前記コマンド送信部から送信された前記複数のコマンドを受信すると、付与された前記制御コードに定められた前記実行手順に基づいて当該複数のコマンドを実行すること
   を特徴とする画像処理装置。

Images