図面 (/)

技術 情報処理装置およびプログラム

出願人 富士ゼロックス株式会社
発明者 橋本浩平
出願日 2015年1月20日 (5年10ヶ月経過) 出願番号 2015-008420
公開日 2016年7月25日 (4年3ヶ月経過) 公開番号 2016-134000
状態 特許登録済
技術分野 デバッグ/監視
主要キーワード 取得漏れ 非リアルタイム処理 リターン情報 事象報告 データ処理結果 超過分 時間制約 リアルタイムオペレーティングシステム
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2016年7月25日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (14)

課題

異なるプログラムに基づいて処理を実行する2つの制御手段間の通信において、通信プロトコルを変更することなく、実行された処理の履歴情報取得漏れを防ぐ。

解決手段

汎用OS101は、RTOS102に対して、予め定められた処理の要求に関する情報が含まれるコマンドデータ200を送信し、RTOS102は、汎用OS101から受信したコマンドデータ200の要求がログ情報の取得以外の要求である場合に、当該要求に対する応答を示すリターン情報330と、当該要求の処理が実行された際の動作履歴を示すログ情報500とを含むリターンデータ300aを汎用OS101に対して送信する。

概要

背景

特許文献1には、ホストから取得したデータに、デバイス詳細情報採取するための疑似的なコマンドを付加する周辺制御処理装置と、周辺制御処理装置から取得したデータを処理し、疑似的なコマンドを実行してデバイス詳細情報を取得し、データ処理結果である事象報告にデバイス詳細情報を付加して周辺制御処理装置に報告するデバイスとを含み、周辺制御処理装置は、デバイス詳細情報を記憶し、ホストからデバイス詳細情報を採取するためのコマンドを受け付けると、デバイス詳細情報をホストに通知するデバイス状態確認システムが開示されている。

概要

異なるプログラムに基づいて処理を実行する2つの制御手段間の通信において、通信プロトコルを変更することなく、実行された処理の履歴情報取得漏れを防ぐ。汎用OS101は、RTOS102に対して、予め定められた処理の要求に関する情報が含まれるコマンドデータ200を送信し、RTOS102は、汎用OS101から受信したコマンドデータ200の要求がログ情報の取得以外の要求である場合に、当該要求に対する応答を示すリターン情報330と、当該要求の処理が実行された際の動作履歴を示すログ情報500とを含むリターンデータ300aを汎用OS101に対して送信する。

目的

本発明の目的は、異なるプログラムに基づいて処理を実行する2つの制御手段間の通信において、通信プロトコルを変更することなく、実行された処理の履歴情報の取得漏れを防ぐことが可能な情報処理装置を提供することである。

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

予め定められたプログラムに基づいて処理を実行する第1の制御手段と、前記プログラムとは異なるプログラムに基づいて処理を実行する第2の制御手段と、を有し、前記第1の制御手段は、前記第2の制御手段に対して、予め定められた処理の要求に関する情報を含む要求データを送信し、前記第2の制御手段は、前記第1の制御手段から受信した要求データの要求が履歴情報の取得以外の要求である場合に、当該要求に対する応答を示す応答情報と当該要求の処理が実行された際の動作履歴を示す履歴情報とを含む応答データを前記第1の制御手段に対して送信する情報処理装置

請求項2

前記応答データは、予め定められた形式のデータであり、前記第2の制御手段は、前記応答情報を含めた予め定められた形式のデータにおける未使用の領域に前記履歴情報が含まれるように構成される応答データを前記第1の制御手段に対して送信する請求項1記載の情報処理装置。

請求項3

前期第1の制御手段は、前記第2の制御手段に対して、前記要求データを送信する際に、履歴情報の受信が可能か否かを示す情報を当該要求データに付加し、前期第2の制御手段は、前記第1の制御手段から受信した要求データの要求が履歴情報の取得以外の要求であり、かつ、当該要求データに履歴情報の受信が可能であることを示す情報が含まれている場合に、前記応答データを前記第1の制御手段に対して送信する請求項1または2記載の情報処理装置。

請求項4

予め定められた処理の要求に関する情報を含む要求データを送信するステップと、受信した要求データの要求が履歴情報の取得以外の要求である場合に、当該要求に対する応答を示す応答情報と当該要求の処理が実行された際の動作履歴を示す履歴情報とを含む応答データを送信するステップと、をコンピュータに実行させるためのプログラム。

技術分野

0001

本発明は、情報処理装置およびプログラムに関する。

背景技術

0002

特許文献1には、ホストから取得したデータに、デバイス詳細情報採取するための疑似的なコマンドを付加する周辺制御処理装置と、周辺制御処理装置から取得したデータを処理し、疑似的なコマンドを実行してデバイス詳細情報を取得し、データ処理結果である事象報告にデバイス詳細情報を付加して周辺制御処理装置に報告するデバイスとを含み、周辺制御処理装置は、デバイス詳細情報を記憶し、ホストからデバイス詳細情報を採取するためのコマンドを受け付けると、デバイス詳細情報をホストに通知するデバイス状態確認システムが開示されている。

先行技術

0003

特開2008−217667号公報

発明が解決しようとする課題

0004

本発明の目的は、異なるプログラムに基づいて処理を実行する2つの制御手段間の通信において、通信プロトコルを変更することなく、実行された処理の履歴情報取得漏れを防ぐことが可能な情報処理装置を提供することである。

課題を解決するための手段

0005

請求項1に係る本発明は、予め定められたプログラムに基づいて処理を実行する第1の制御手段と、
前記プログラムとは異なるプログラムに基づいて処理を実行する第2の制御手段と、
を有し、
前記第1の制御手段は、前記第2の制御手段に対して、予め定められた処理の要求に関する情報を含む要求データを送信し、
前記第2の制御手段は、前記第1の制御手段から受信した要求データの要求が履歴情報の取得以外の要求である場合に、当該要求に対する応答を示す応答情報と当該要求の処理が実行された際の動作履歴を示す履歴情報とを含む応答データを前記第1の制御手段に対して送信する情報処理装置である。

0006

請求項2に係る本発明は、前記応答データが、予め定められた形式のデータであり、
前記第2の制御手段は、前記応答情報を含めた予め定められた形式のデータにおける未使用の領域に前記履歴情報が含まれるように構成される応答データを前記第1の制御手段に対して送信する請求項1記載の情報処理装置である。

0007

請求項3に係る本発明は、前期第1の制御手段が、前記第2の制御手段に対して、前記要求データを送信する際に、履歴情報の受信が可能か否かを示す情報を当該要求データに付加し、
前期第2の制御手段は、前記第1の制御手段から受信した要求データの要求が履歴情報の取得以外の要求であり、かつ、当該要求データに履歴情報の受信が可能であることを示す情報が含まれている場合に、前記応答データを前記第1の制御手段に対して送信する請求項1または2記載の情報処理装置である。

0008

請求項4に係る本発明は、予め定められた処理の要求に関する情報を含む要求データを送信するステップと、
受信した要求データの要求が履歴情報の取得以外の要求である場合に、当該要求に対する応答を示す応答情報と当該要求の処理が実行された際の動作履歴を示す履歴情報とを含む応答データを送信するステップと、
コンピュータに実行させるためのプログラムである。

発明の効果

0009

請求項1に係る本発明によれば、異なるプログラムに基づいて処理を実行する2つの制御手段間の通信において、通信プロトコルを変更することなく、実行された処理の履歴情報の取得漏れを防ぐことが可能な情報処理装置を提供することができる。

0010

請求項2に係る本発明によれば、予め定められた形式のデータにより通信を行う場合でも、履歴情報の取得漏れを防ぐことが可能な情報処理装置を提供することができる。

0011

請求項3に係る本発明によれば、履歴情報の取得以外の要求が行われた際の履歴情報の取得を行うか否かを変更することが可能な情報処理装置を提供することができる。

0012

請求項4に係る本発明によれば、異なるプログラムに基づいて処理を実行する2つの制御手段間の通信において、通信プロトコルを変更することなく、実行された処理の履歴情報の取得漏れを防ぐことが可能なプログラムを提供することができる。

図面の簡単な説明

0013

本発明の一実施形態における画像形成システムの一例を示す図である。
本発明の一実施形態における画像形成装置10のハードウェア構成を示すブロック図である。
本発明の一実施形態における画像形成装置10の機能構成を示すブロック図である。
本発明の構成を有さない場合におけるOS間通信の一例を示す概念図である。
本発明の一実施形態におけるOS間通信において送受信されるデータのフォーマットの一例を示す図である。
本発明の構成を有さない場合におけるリターンデータの一例を示す図である。
本発明の一実施形態におけるログ情報取得要求に対するリターンデータの一例を示す図である。
本発明の一実施形態におけるログ情報が分割された場合のリターンデータの一例を示す図である。
本発明の一実施形態におけるリターンデータの一例を示す図である。
本発明の一実施形態におけるOS間通信の一例を示す概念図である。
本発明の一実施形態における汎用OS101側の処理の流れを示すフローチャートである。
本発明の一実施形態におけるRTOS102側の処理の流れを示すフローチャートである。
本発明の一実施形態におけるコマンドデータの一例を示す図である。

発明を実施するための最良の形態

0014

次に、本発明の実施の形態について図面を参照して詳細に説明する。

0015

図1は、本発明の一実施形態における画像形成システムの一例を示す図である。

0016

図1に示されるように、本実施形態における画像形成装置10は、ネットワーク30を介して端末装置20と接続されている。画像形成装置10は、端末装置20からネットワーク30を介して送信されてきた画像データ、および図示しない光学的に画像を読み取るプリンタなどの読み取り装置から送信されてきた画像データを用紙に印刷する。

0017

次に、画像形成装置10のハードウェアの構成を図2を参照して詳細に説明する。

0018

画像形成装置10は、図2に示されるように、CPU11と、CPU12と、メモリ13と、ネットワーク30を介して外部の装置等との間でデータの送信及び受信を行う通信インタフェース(IF)14と、ハードディスクドライブ(HDD)等の記憶装置15、タッチパネル又は液晶ディスプレイ並びにキーボードを含むユーザインタフェース(UI)装置16と、プリンタ17とを有する。これらの構成要素は、制御バス18を介して互いに接続されている。

0019

CPU11(第1の制御手段)は、メモリ13または記憶装置15に格納された制御プログラムに基づいて所定の処理を実行して、画像形成装置10の動作を制御する。また、CPU12(第2の制御手段)は、メモリ13または記憶装置15に格納され、CPU11の制御プログラムとは異なる制御プログラムに基づいて所定の処理を実行して、画像形成装置10の動作を制御する。なお、本実施形態では、CPU11及びCPU12は、メモリ13または記憶装置15内に格納された制御プログラムを読み出して実行するものとして説明したが、当該プログラムをCD−ROM等の記憶媒体に格納してCPU11及びCPU12に提供することも可能である。

0020

図3は、上記の制御プログラムが実行されることにより実現される画像形成装置10の機能構成を示すブロック図である。

0021

本実施形態における画像形成装置10においては、図3に示されるように、CPU11上において汎用オペレーティングシステム(汎用OS)101が動作し、CPU11とは異なる制御プログラムに基づいて処理を実行するCPU12上においてリアルタイムオペレーティングシステム(RTOS)102が動作する。また、画像形成装置10は、図3に示されるように、不揮発性メモリ103と、揮発性メモリ104とを有している。また、汎用OS101とRTOS102とは、予め定められた形式のデータによって送受信を行うOS間通信により相互に通信を行う。

0022

汎用OS101は、予め定められた制御プログラムに基づいてCPU11により処理が実行されることによって、ユーザインタフェースへのデータ出力といった時間制約がない処理(非リアルタイム処理)を制御する。また、汎用OS101は、予め定められた処理の要求に関する情報が含まれる予め定められた形式のデータをコマンドデータ(要求データ)としてRTOS102に対して送信する。

0023

RTOS102は、CPU11とは異なる制御プログラムに基づいてCPU12により処理が実行されることによって、スキャナ等の画像読取装置や、プリンタ等の画像出力装置の制御といった要求された処理を予め定められた時間内に終了するリアルタイム性が要求される処理(リアルタイム処理)を制御する。また、RTOS102は、汎用OS101から受信したコマンドデータの要求がログ情報(履歴情報)の取得以外の要求である場合に、当該要求に対する応答を示すリターン情報(応答情報)と、当該要求の処理が実行された際の動作履歴を示すログ情報とが含まれる予め定められた形式のデータをリターンデータ(応答データ)として汎用OS101に対して送信する。

0024

また、RTOS102は、リターンデータを汎用OS101に対して送信する場合に、リターン情報を含めた予め定められた形式のデータにおける未使用の領域にログ情報が含まれるように構成される応答データを送信する。

0025

不揮発性メモリ103は、記憶された情報の保持に電源の供給を必要とせず、汎用OS101により取得された動作履歴を示すログ情報を格納する。

0026

揮発性メモリ104は、記憶された情報の保持に電源の供給を必要とし、RTOS102により処理が実行された際のログ情報を一時的に格納する。

0027

次に、まず、図4図6を参照して、本発明の構成を有さない場合に、ログ情報の取得要求以外の要求が行われる際の一般的なOS間通信の一例について説明する。

0028

図4は、汎用OS101とRTOS102との間で行われるOS間通信の一例を示す概念図である。

0029

図4に示されるように、汎用OS101は、RTOS102に対して、コマンドデータ200を送信することにより、RTOS102に対して処理の要求を行う。また、RTOS102は、コマンドデータ200を受信した場合に、コマンドデータ200を解析して汎用OS101から要求された処理を実行する。そして、RTOS102は、実行したログ情報を揮発性メモリ104に格納する。また、RTOS102は、要求に対する応答を示すリターン情報が含まれるリターンデータ300を汎用OS101に対して送信する。

0030

図5は、汎用OS101とRTOS102との間で行われるOS間通信において送受信されるデータのフォーマット(形式)の一例を示す図である。

0031

図5(A)に示されるように、汎用OS101は、RTOS102に対して処理の要求を行う場合、要求に関する情報が含まれる予め定められたフォーマットのデータを生成する。例えば、汎用OS101は、端末装置20から送信された印刷データの印刷要求を行う場合に、印刷要求に関する情報が含まれる予め定められたフォーマットのデータをコマンドデータ200として生成する。具体的には、図5(A)に示されるように、汎用OS101は、プロトコルヘッダ210(32バイト)、印刷の要求を示すコマンドID220(4バイト)、印刷の要求の具体的な指示を示すコマンド情報230(nバイト)及び未使用領域240により構成される4096(バイト)のデータをコマンドデータ200として生成する。

0032

また、図5(B)に示されるように、プロトコルヘッダ210は、プロトコルヘッダ210全体のサイズを示すプロトコルヘッダサイズ211(4バイト)、コマンドID220及びコマンド情報230の合計サイズを示すコマンドサイズ212(4バイト)及びリザーブ領域213(24バイト)により構成される。リザーブ領域とは、将来的に拡張機能実装する場合を考慮して、情報を追加可能な空き容量を示す領域である。

0033

図5(B)に示されるコマンドデータ200の一例では、プロトコルヘッダ210全体のサイズが32(バイト)、コマンドID220及びコマンド情報230の合計サイズがn+4(バイト)であることを示している。そして、図5(B)においては、プロトコルヘッダサイズ211及びコマンドサイズ212以外の残りの24(バイト)の領域がリザーブ領域213であるものとして説明する。

0034

また、図5(A)に示されるように、コマンドデータ200において、プロトコルヘッダ210が32(バイト)、コマンドID220が4(バイト)、コマンド情報230がn(バイト)である場合には、4096−(32+4+n)(バイト)分の領域が未使用領域240となる。

0035

そして、RTOS102は、汎用OS101から要求された処理を完了した場合に、要求に対する応答を示すリターン情報が含まれるリターンデータ300を汎用OS101に対して送信する。このとき、RTOS102は、コマンドデータ200と同様のフォーマットのデータによりリターンデータ300を生成する。また、リターン情報とは、例えば、要求された処理が完了したことを示す情報や要求された処理が失敗したことを示す情報等を含む要求に対する応答を示す情報である。

0036

具体的には、RTOS102は、図6(A)に示されるように、プロトコルヘッダ310(32バイト)、要求に対する応答を示すリターンID320(4バイト)、要求された処理が完了したことを示す情報や要求された処理が失敗したことを示す情報等を示すリターン情報330(nバイト)及び未使用領域340により構成される4096(バイト)のデータをリターンデータ300として生成する。

0037

また、図6(B)に示されるように、プロトコルヘッダ310はプロトコルヘッダ310全体のサイズを示すプロトコルヘッダサイズ311(4バイト)、リターンID320及びリターン情報330の合計サイズを示すリターンサイズ312(4バイト)及びリザーブ領域313(24バイト)により構成される。

0038

図6(B)に示されるリターンデータ300の一例では、プロトコルヘッダ310全体のサイズが32(バイト)、リターンID320及びリターン情報330の合計サイズがn+4(バイト)であることを示している。そして、図6(B)においては、プロトコルヘッダサイズ311及びコマンドサイズ312以外の残りの24バイトの領域がリザーブ領域313であるものとして説明する。

0039

そして、図6(A)に示されるように、コマンドデータ200と同様に、リターンデータ300において、プロトコルヘッダ310が32(バイト)、リターンID320が4(バイト)、リターン情報330がn(バイト)である場合には、4096−(32+4+n)(バイト)分の領域が未使用領域340となる。

0040

また、汎用OS101がRTOS102からログ情報を取得する際には、汎用OS101がログ情報の取得の要求をRTOS102に対して行い、RTOS102は、揮発性メモリ104に格納されているログ情報を含むデータをリターンデータとして汎用OS101に対して送信する。

0041

具体的には、汎用OS101からログ情報の取得の要求に関する情報が含まれるコマンドデータ200を受信した場合、図7に示されるように、RTOS102は、プロトコルヘッダ310、ログ情報の取得要求に対する応答を示すリターンID320、未送信フラグ360、ログ情報500により構成される予め定められたフォーマットのデータをリターンデータ300として生成する。

0042

また、RTOS102は、予め定められたフォーマットのデータにログ情報500が収まりきらない場合には、ログ情報500を分割して複数のリターンデータを生成する。

0043

また、未送信フラグは、1である場合には、受信したリターンデータ300の後にさらに分割されたログ情報を含むリターンデータがRTOS102から送信されることを示し、0である場合には、受信したリターンデータ300の後にログ情報が送信されないことを示す。

0044

具体的には、汎用OS101からログ情報500の取得の要求がRTOS102に対して行われた場合、まず、RTOS102は、揮発性メモリ104に格納されているログ情報500を取得する。そして、予め定められたフォーマットのデータのサイズ(4096バイト)に収まる分のログ情報を含むリターンデータを生成する。

0045

例えば、ログ情報500のサイズが5000(バイト)であり、予め定められたフォーマットのデータに4000(バイト)分のログ情報が収められる場合には、図8(A)に示されるように、ログ情報500を、4000(バイト)のログ情報500aと1000(バイト)のログ情報500bとに分割する。そして、図8(B)に示されるように、RTOS102は、ログ情報500aが含まれるリターンデータを1つ目のリターンデータ301として生成し、ログ情報500bが含まれるリターンデータを2つ目のリターンデータ302として生成する。

0046

次に、RTOS102は、1つ目のリターンデータ301の未送信フラグを1に設定して汎用OS101に対して送信した後、2つ目のリターンデータ302の未送信フラグを0に設定して汎用OS101に対して送信する。そして、汎用OS101は、受信した1つ目のリターンデータ301及び2つ目のリターンデータ302に含まれるログ情報を不揮発性メモリ103に格納する。

0047

上記のログ情報の取得方法では、汎用OS101からログ情報の取得の要求が行われる前に、既に揮発性メモリに格納されているログ情報と、RTOS102において実行された処理のログ情報との合計量が揮発性メモリの容量を超えた場合、以前のログ情報が超過分のログ情報に上書きされるため、ログ情報の取得漏れが発生することがある。

0048

次に、本発明の一実施形態における汎用OS101とRTOS102との間でログ情報の取得要求以外の要求の際に行われるOS間通信の一例について、図面を参照して説明する。なお、汎用OS101により送信されるコマンドデータについては、上述した一般的なOS間通信の一例と同様であるため説明を省略する。

0049

図9は、本実施形態におけるリターンデータ300aの一例を示す図である。

0050

図9に示されるように、本実施形態においては、RTOS102は、汎用OS101から受信したコマンドデータの要求がログ情報の取得以外の要求である場合に、この要求に対する応答を示すリターン情報と当該要求の処理が実行された際の動作履歴を示すログ情報とが含まれる予め定められたフォーマットのデータをリターンデータ300aとして汎用OS101に対して送信する。

0051

具体的には、RTOS102は、図9(A)に示されるように、プロトコルヘッダ310a(32バイト)、要求に対する応答を示すリターンID320(4バイト)、要求された処理の内容を示すリターン情報330(nバイト)、ログ情報が含まれるか否かを示すログ情報フラグ350(4バイト)及びRTOS102において処理が実行された際の動作履歴を示すログ情報500(mバイト)により構成される4096(バイト)のサイズのリターンデータ300aを生成する。本実施形態においては、RTOS102は、リターンデータ300aを汎用OS101に送信する場合に、汎用OS101から要求された処理を実行した際に揮発性メモリ104に格納されたログ情報500を取得する。

0052

また、本実施形態におけるリターンデータ300aは、図9(A)に示されるように、図6(A)に示されるリターンデータ300における未使用領域340にログ情報フラグ350及びログ情報500が含まれるように構成されている。つまり、上述した一般的なOS間通信の一例におけるリターンデータ300に対して、本実施形態におけるRTOS102は、未使用領域340にログ情報フラグ350及びログ情報500が格納されるようにリターンデータ300aを生成する。

0053

また、図9(B)に示されるように、本実施形態においては、プロトコルヘッダ310aは,プロトコルヘッダ310a全体のサイズを示すプロトコルヘッダサイズ311(4バイト)、リターンID320及びリターン情報330の合計サイズを示すリターンサイズ312(4バイト)、ログ情報500及びログ情報フラグ350の合計サイズを示すログサイズ314(4バイト)及びリザーブ領域313により構成される。また、本実施形態においては、図9(B)に示されるように、上述した一般的なOS間通信の一例として図6(B)に示されるようなプロトコルヘッダ310に対して、ログサイズ314がリザーブ領域313に含まれるように構成される。

0054

図9(B)に示されるプロトコルヘッダ310aの一例では、プロトコルヘッダ310aの全体のサイズが32(バイト)、リターンサイズがn+4(バイト)、ログサイズがm+4(バイト)であることを示している。

0055

そして、図10に示されるように、汎用OS101から受信したコマンドデータ200の要求がログ情報の取得以外の要求である場合、RTOS102は、要求された処理を実行した後、上述したリターンデータ300aを汎用OS101に対して送信する。

0056

そして、汎用OS101は、RTOS102から受信したリターンデータ300aを解析して、リターンデータ300aに含まれるログ情報フラグ350が1である場合には、ログ情報が含まれると判定し、リターンデータに含まれるログ情報500を取得して不揮発性メモリ103に格納する。また、汎用OS101は、リターンデータ300aに含まれるログ情報フラグ350が0である場合には、ログ情報が含まれていないと判定し、リターン情報に基づく完了処理を行う。

0057

なお、本実施形態においては、ログ情報フラグが1であるか0であるかに基づいてリターンデータにログ情報が含まれるか否かを判定するものとして説明したが、プロトコルヘッダ310aに含まれるログ情報のサイズを示す情報314が0(バイト)よりも大きいか否かに基づいて、リターンデータ300aにログ情報が含まれるか否かを判定するようにしてもよい。

0058

次に、本実施形態における画像形成装置10の処理について、図11及び図12のフローチャートを参照して説明する。

0059

まず、汎用OS101側の処理について、図11のフローチャートを参照して説明する。

0060

まず、汎用OS101は、RTOS102に対して、予め定められた処理の要求に関する情報が含まれるコマンドデータ200を送信する(ステップS101)。

0061

次に、汎用OS101は、RTOS102からリターンデータ300aを受信する(ステップS102)。そして、汎用OS101は、受信したリターンデータ300aにログ情報が含まれているか否かを判定する(ステップS103)。リターンデータにログ情報が含まれていないと判定された場合(ステップS103においてno)、ステップS105に進む。

0062

また、リターンデータ300aにログ情報が含まれていると判定された場合(ステップS103においてyes)、汎用OS101は、リターンデータ300aに含まれるログ情報500を取得する(ステップS104)。また、汎用OS101は、取得したログ情報500を不揮発性メモリ103に格納する。

0063

そして、汎用OS101は、リターンデータ300aに含まれるリターン情報330に基づく完了処理を行う(ステップS105)。

0064

次に、RTOS102側の処理について、図12のフローチャートを参照して説明する。

0065

まず、RTOS102は、汎用OS101からコマンドデータ200を受信する(ステップS201)。そして、RTOS102は、受信したコマンドデータ200を解析して、ログ情報の取得の要求であるか否かを判定する(ステップS202)。

0066

そして、ログ情報の取得以外の要求である場合には(ステップS202においてno)、RTOS102は、汎用OS101から要求された処理を実行する(ステップS203)。そして、RTOS102は、実行した処理のログ情報500を取得して、要求に対する応答を示すリターン情報330と取得されたログ情報500とを含むリターンデータ300aを送信する(ステップS204)。

0067

また、ログ情報の取得の要求である場合には(ステップS202においてyes)、RTOS102は、揮発性メモリ104に格納されているログ情報500を取得して(ステップS205)、取得したログ情報500を含むリターンデータ300を送信する(ステップS206)。

0068

なお、本実施形態における汎用OS101は、プロトコルヘッダ210、コマンドID220、コマンド情報230及び未使用領域240により構成されるコマンドデータ200を送信するものとして説明したが、図13に示されるように、コマンドデータ200の未使用領域240に、ログ情報の受信が可能であるか否かを示すログ情報受信可否フラグ250が含まれるように構成されるコマンドデータ200aをRTOS102に対して送信するようにしてもよい。例えば、RTOS102は、汎用OS101から受信したコマンドデータ200aの要求がログ情報の取得以外の要求であり、かつ、ログ情報受信可否フラグ250が1である場合に、リターン情報とログ情報とが含まれるリターンデータ300aを汎用OS101に対して送信するようにしてもよい。また、RTOS102は、汎用OS101から受信したコマンドデータに含まれるログ情報受信可否フラグ250が0である場合には、ログ情報が含まれないリターンデータ300を汎用OS101に対して送信するようにしてもよい。

0069

また、本実施形態においては、画像形成装置10に適用した例を説明したが、本発明が適用される装置は、画像形成装置10に限らない。本発明は、複数のオペレーティングシステムが動作する装置であれば適用可能である。特に、本発明は、リアルタイムオペレーティングシステムと汎用オペレーティングシステムとを併用している装置に好適である。

0070

10画像形成装置
11、12 CPU
13メモリ
14通信IF
15記憶装置
16 UI部
17プリンタ
18制御バス
20端末装置
30ネットワーク
101汎用OS
102RTOS
103不揮発性メモリ
104揮発性メモリ
200コマンドデータ
210、210a、310、310aプロトコルヘッダ
211、311 プロトコルヘッダサイズ
212 コマンドサイズ
213、313リザーブ領域
220 コマンドID
230コマンド情報
240、340未使用領域
250ログ情報受信可否フラグ
300、300a、301、302リターンデータ
312 リターンサイズ
314ログサイズ
320 リターンID
330リターン情報
350 ログ情報フラグ
360 未送信フラグ
500、500a、500b ログ情報

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ