(57)【要約】      （修正有）【課題】動作中にＣＰＵ間の時刻合わせを行うとファームウエアの負荷が高くなる問題を回避するログ処理システムを提供する。【解決手段】ＳｕｂＣＰＵ２１８群の起動時刻をＭａｉｎＣＰＵ２０５で記録しておき、各ＳｕｂＣＰＵ２１８でタイムスタンプを付加したデバッグログを収集し、前記収集したデバックログを二次記憶装置に退避させたうえ、外部装置に転送させた後に、前記外部装置上で前記記録したＳｕｂＣＰＵ２１８群の起動時刻に基づき、前記デバッグログの時系列ソートを可能とした。【選択図】図１
2012190197.tif 000002
【特許請求の範囲】
【請求項１】
おのおの独立した内部タイマをもつ複数のCPU（２０５および２１８）を用いてシステム制御を行う画像処理装置（Ａ）と、動作ログ加工を行う外部装置（Ｂ）から構成されるログ処理システムで、
画像処理装置はシステムの電源オンでファームエアを読み込み自動起動される、メインCPU（２０５）と、
メインCPU（２０５）から起動をキックされる１つ以上のサブCPU（２１８）と、
メインCPU（２０５）は各サブCPU（２１８）を起動した時刻をメインCPUのタイマ時刻で記憶する時間記憶手段と、
各CPUで実行されるファームウエアの動作ログ（５１０および５１１）を、前記タイマハードからえたタイムスタンプを付加してバッファリングするロギング手段（３１１および３２１）と、
前記ロギング機能によってバッファリングされた動作ログデータを、前記時間記憶手段によって記録された各サブCPU起動時刻とともに二次記憶装置（２０８）に退避する、ログ保存手段（３１１および３２１）と、
前記ログ保存手段によって保存されたログを外部装置に転送する、ログ転送手段と、
ログを転送した外部装置（Ｂ）において、前記メインCPUの動作ログから各サブCPUのキック時刻と、各サブCPUのログ用タイマ開始ラグ時間とを抽出し、各サブCPUの動作ログのタイムスタンプに前記キック時刻とタイマ開始ラグの合計値を加算することで、各CPUの動作ログの時系列でのソートしたソートログ（５３０）を出力することを特徴とするログ処理システム。
【請求項２】
前記各ＣＰＵのタイマはバッテリバックアップされたカレンダー時刻であることを特徴とする、請求項１に記載のログ処理システム。
【請求項３】
前記各ＣＰＵのタイマは起動からのＣＰＵクロックカウントレジスタの値であることを特徴とする、請求項１に記載のログ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、異なるCPU同士の動作ログを時系列でソートするログ処理システムに関するものである。
【背景技術】
【０００２】
近年の画像処理装置、たとえばプリンタや複写機はデジタル化がすすむと同時に制御ソフトウエアの規模、機能も拡大している。同時に画像処理装置を制御するコントローラも装置の機能および処理量増大に伴い、複数のCPUを備え、並列処理で装置制御を行う場合が多い。CPUを複数同時に並列動作させることで、ユーザインターフェイス（以下UIと略する）の動作と装置内での画像処理とを同時に処理し、装置全体としての性能を大きく向上させることが可能となっている。
【０００３】
一方で、複数のCPU上で実行される制御ソフトウエアが相互に通信しながら装置全体の処理が行われるため、そのソフトウエア開発中のデバッグの難易度もまた高くなっているという問題がある。特に近年の画像処理装置のコントローラでは、ハードウエアによるデバッグ支援装置が提供されないCPUを採用することも増えている。その場合、おもにソフトウエア中に埋め込んだデバッグメッセージをデバッグログとして出力し、動作確認や不具合調査に使うことが広く行われている。複数のCPUがある場合、デバッグログも各CPUごとのタイムスタンプを用いてそれぞれ別々のデバッグログとしてファイルとして回収、デバッグに提供することが多い。
【０００４】
このような場合、各CPUのデバッグログのタイムスタンプが共通であれば、各CPU上のソフト動作をわかりやすく把握できるため、ソフトウエアのデバッグ効率を大きく改善することができる。そのため、例えば特許文献１のように、複数のソフトウエアの動作ログのタイムスタンプの時刻合わせを高精度で実現する方法が発明されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開2007-026048号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、前記引用した先行技術では時刻合わせのための処理がソフトウエア実行中に必要であり、画像処理装置の動作中にデバッグ目的のための時刻合わせの処理負荷が発生してしまうという問題があった。
【課題を解決するための手段】
【０００７】
おのおの独立した内部タイマをもつ複数のCPUを用いてシステム制御を行う画像処理装置と、動作ログ分析を行う外部装置から構成されるログ処理システムで、
画像処理装置はシステムの電源オンでファームエアを読み込み自動起動される、メインCPUと、
メインCPUから起動をキックされる１つ以上のサブCPUと、
メインCPUは各サブCPUをキックした時刻をメインCPUのタイマ時刻で記憶する時間記憶手段と、
各CPUで実行されるファームウエアの動作ログを、前記タイマハードからえたタイムスタンプを付加してバッファリングするロギング手段と、
前記ロギング機能によってバッファリングされた動作ログデータを、前記時間記憶手段によって記録された各サブCPUキック時刻とともに二次記憶装置に退避する、ログ保存手段と、
前記ログ保存手段によって保存されたログを外部装置に転送する、ログ転送手段と、
ログを転送した外部装置において、前記メインCPUの動作ログから各サブCPUのキック時刻と、各サブCPUのログ用タイマ開始ラグ時間とを抽出し、各サブCPUの動作ログのタイムスタンプに前記キック時刻とタイマ開始ラグの合計値を加算することで、各CPUの動作ログの時系列でのソートしたソートログを出力することを特徴とする。
【発明の効果】
【０００８】
ファームウエアの実行中、ＣＰＵ間での時間合わせ処理を一切行うことなく、異なるCPU同士の動作ログを時系列でソートすることができる。
【図面の簡単な説明】
【０００９】
【図１】本実施例に係るログ処理システム全体を示す概要図である。
【図２】画像処理装置Aのコントローラハード構成図である。
【図３】画像処理装置Aのコントローラソフトの構成図である。
【図４】画像処理装置Aの全体概要図である。
【図５】ホストBの構成図である。
【図６】画像処理装置Aにおけるデバッグログ出力動作のフローチャートである。
【図７】画像処理装置Aが出力するデバッグログのデータ例である。
【図８】デバッグログの回収とソート結果をえるまでのフローチャートである。
【図９】デバッグログのソート結果のデータ例である。
【発明を実施するための形態】
【００１０】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【００１１】
図１は本実施例のログ処理システム全体を示す概要図である。本実施例に示すログ処理システムは、画像処理装置Aと、デバッグログのソート処理を行うホストBから構成される。
【００１２】
まず画像処理装置Aのカラー系画像処理装置の構成について、図４を用いて説明する。
【００１３】
１Ｄカラー系画像処理装置は、操作部、スキャナエンジン、レーザ露光部、感光ドラム、作像部、定着部、給紙／搬送部からなるプリンタエンジン、さらに図１には不図示のコントローラユニットで構成される。コントローラユニットについては後述の図２で説明する。
【００１４】
操作部はユーザからの操作や装置全体のステータス表示などを行なう入力キーや表示画面から構成され、画像処理装置とユーザとのユーザインターフェース機能を提供する。
【００１５】
スキャナエンジンは、原稿台に置かれた原稿に対して、照明を当てて原稿画像を光学的に読み取り、その像を電気信号に変換して画像データを作成する。
【００１６】
プリンタエンジンのレーザ露光部は、前記画像データに応じて変調されたレーザ光などの光線を等角速度で回転する回転多面鏡（ポリゴンミラー）に入射させ、反射走査光として感光ドラムに照射する。作像部は、感光ドラムを回転駆動し、帯電器によって帯電させ、前記レーザ露光部によって感光ドラム上に形成された潜像をトナーによって現像化し、そのトナー像をシートに転写する。その際に転写されずに感光ドラム上に残った微小トナーを回収するといった一連の電子写真プロセスを実行して作像する。その際、シートが転写ベルトの所定位置に巻きつき、４回転する間に、マゼンタ（Ｍ）、シアン（Ｃ）、イエロー（Ｙ）、ブラック（Ｋ）のトナーを持つそれぞれの現像ユニット（現像ステーション）が入れ替わりで順次前述の電子写真プロセスを繰り返し実行する。４回転の後、４色のフルカラートナー像を転写されたシートは、転写ドラムを離れ、定着部へ搬送される。
【００１７】
定着部は、ローラやベルトの組み合わせによって構成され、ハロゲンヒータなどの熱源を内蔵し、前記作像部によってトナー像が転写されたシート上のトナーを、熱と圧力によって溶解、定着させる。
【００１８】
給紙／搬送部は、シートカセットやペーパーデッキに代表されるシート収納庫を一つ以上持っており、前記プリンタ制御部の指示に応じてシート収納庫に収納された複数のシートの中から一枚分離し、作像部・定着部へ搬送する。シートは作像部の転写ドラムに巻きつけられ、４回転した後に定着部へ搬送される。４回転する間に前述のＹＭＣＫ各色のトナー像がシートに転写される。また、シートの両面に画像形成する場合は、定着部を通過したシートを再度作像部へ搬送する搬送経路を通るように制御する。
【００１９】
上記各機能部はコントローラユニットで実行されるコントローラソフトによって統合制御されており、それぞれコントローラソフトと相互に通信を行ないつつ画像処理装置機能動作を実現するものである。コントローラソフトについては図３で後述する。
【００２０】
ホストBの構成を図５で説明する。ホストBは画像処理装置Aの異なるCPUが独立に出力するデバッグ出力を時系列でソートするソート処理部５２０を備える。ソート処理部５２０に異なるCPUから出力されたデバッグログ５１０および５１１を入力すると、時系列でソートしたソートログ５３０を出力する。ここで、ホストBを構成するオペレーティングシステム、およびソート処理部５２０を実現するプログラムは時系列でソートされたログを出力できればその種類や実装手段にはなんら依存しないものである。これらの詳細は本発明とは関係しないため説明は割愛する。
【００２１】
＜画像処理装置Aのコントローラユニットの構成＞
図２は、本実施形態における画像処理装置のコントローラの一構成例を示すハードウエアブロック図である。図２において、コントロールユニット２００は、画像入力デバイスであるスキャナ２０１や画像出力デバイスであるプリンタエンジン２０２と接続し、画像データの読み取りやプリント出力のための制御を行う。また、コントロールユニット２００は、ＬＡＮ１０と接続することで、画像情報やデバイス情報を入出力するための制御を行う。
【００２２】
ＭａｉｎＣＰＵ２０５はおもに装置全体のシステム的な制御とアプリケーションプログラムを制御するための中央処理装置である。ＲＡＭ２０６は、ＭａｉｎＣＰＵ２０５が動作するためのシステムワークメモリであり、ＭａｉｎＣＰＵが出力するデバッグログも保持する領域も確保されている。ＳｕｂＣＰＵ２１８は主にスキャナエンジン２０１、プリンタエンジン２０２のリアルタイム制御、および画像処理の制御をつかさどり、ＭａｉｎＣＰＵ２０５と連携してコピー機能、ＰＤＬプリント機能を実現する。ＲＡＭ２１９はＳｕｂＣＰＵ２１８用のメインメモリであり、ＳｕｂＣＰＵ２１８が出力するデバッグログ出力領域もここに割り当てられている。
【００２３】
ＢｏｏｔＲＯＭ２０７には、コントローラの電源がＯＮ後、ＭａｉｎＣＰＵ２０５を起動するために最初に実行されるシステムのブートプログラムが格納されている。ここで、電源Ｏｎで起動されるのはＭａｉｎＣＰＵ２０５のみである。ＳｕｂＣＰＵ２１８の起動は、ＭａｉｎＣＰＵ２０５のファームウエアが起動し、そのファームウエアがＳｕｂＣＰＵ２１８用のファームウエアをロード、起動させることで行われる。
【００２４】
ＨＤＤ２０８はハードディスクドライブであり、各種処理のためのシステムソフトウェア及び入力された画像データ、さらにシステムイメージのスナップショットを等格納する。操作部Ｉ／Ｆ２０９は、画像データ等を表示可能な表示画面を有する操作部２１０に対するインタフェース部であり、操作部２１０に対して操作画面データを出力する。また、操作部Ｉ／Ｆ２０９は、操作部２１０から操作者が入力した情報をＣＰＵ２０５に伝える役割をする。ネットワークインタフェース２１１は、例えばＬＡＮカード等で実現され、ＬＡＮ１０に接続して外部装置との間で情報の入出力を行う。
【００２５】
イメージバスＩ／Ｆ２１４は、システムバス２１３と画像データを高速で転送する画像バス２１５とを接続するためのインタフェースであり、データ構造を変換するバスブリッジである。画像バス２１５上には、ラスタイメージプロセッサ（ＲＩＰ）２１６、デバイスＩ／Ｆ２１７が接続される。
【００２６】
ラスタイメージプロセッサ（ＲＩＰ）２１６は、ページ記述言語（ＰＤＬ）コードや後述するベクトルデータをイメージに展開する。デバイスＩ／Ｆ部２１７は、スキャナ２０１やプリンタエンジン２０２とコントローラ２００とを物理的に接続し、画像データの同期系／非同期系の変換を行う。
【００２７】
また、画像処理部２１８は、スキャナ２０１から読み込んだ画像やプリンタ２０２に出力しようとしている画像に応じた補正、解像度変換等の処理を行う。画像処理はスキャナ２０１、プリンタ２０２の速度に対応したリアルタイム処理が必要なため、画像処理ボード２０３の高速な専用処理ハードウエアによって処理実行される。
【００２８】
＜画像処理装置Aのコントローラソフト構成＞
図３は、本実施形態における画像処理装置のコントローラ２００で実行され、画像処理装置全体の制御を行なうコントローラソフトの構成図である。
【００２９】
コントローラソフトはＭａｉｎＣＰＵ２０５で実行されるＭａｉｎ側３１０と、ＳｕｂＣＰＵ２１８で実行されるＳｕｂ側３２０から構成され、それぞれファームウエアが出力するデバッグログをＲＡＭ上に出力するデバッグログモジュールを含む。Ｍａｉｎ側３１０はおもにシステム全体制御とアプリケーション層の制御を管理し、操作部２１０から入力された動作指示にしたがって画像処理装置Ａ全体としての機能動作を実現する。Ｓｕｂ側３２０はスキャナエンジン２０１、プリンタエンジン２０２、画像処理ボード２０３などのリアルタイム制御を行う。例えば操作部２１０からコピー動作の指示が行われた場合、Ｍａｉｎ側３１０は指示された動作内容にしたがってＳｕｂ側３２０に必要な動作指示を行い、Ｓｕｂ側３２０はそれに応じて物理的なデバイス動作の制御を行う。より詳細には原稿読み取り開始指示とその完了通知、画像処理パラメタの通知と応答、プリント開始指示と完了通知、のようにＭａｉｎ側３１０とＳｕｂ側３２０と通信を行い、装置全体としてのコピー機能を実現する。
【００３０】
Ｍａｉｎ側３１０、Ｓｕｂ側３２０ともにファームウエアには内部動作状態を出力するデバッグログが埋め込まれており、動作に伴ってデバッグログモジュール３１１および３２１によってＲＡＭ上にリングバッファで管理された領域にログ出力が行われる。デバッグログモジュールはログ出力の際、自ＣＰＵの時刻情報をもとに出力のたびにタイムスタンプを付加し、デバッグを容易にする。ただし、ＭａｉｎＣＰＵ２０６とＳｕｂＣＰＵ２１８の時刻情報はそれぞれ独立しており、したがっておのおののデバッグログに吹かされているタイムスタンプも異なる時間となっている。
【００３１】
ファームウエアのソフト例外の発生など、不具合が発生した場合はデバッグログモジュール３１１および３２１がＲＡＭ２０６および２１９に保持しているデバッグログをファイル化する。各デバッグログはＨＤＤ２０８のファイルとしてＭａｉｎ側ログ５１１、Ｓｕｂ側ログ５１０として保存される。ＨＤＤ２０８にファイル化されるとＲＡＭ３１１および３２１の領域と異なり上書きされることは無く保持され、ネットワークＩ／Ｆ２１０などから外部装置に転送することができる。
【００３２】
＜ホストＢの構成＞
Ｍａｉｎ側デバッグログ５１０とＳｕｂ側デバッグログ５１１のソートを行うホストＢの構成を図５で説明する。ホストＢは入力となるＭａｉｎ側とＳｕｂ側のデバッグログファイル５１０と５１１をソート処理部５２０に入力し、Ｍａｉｎ側のタイムスタンプ基準で並び替え、ソートログとして出力する。ソートログの閲覧方法などは本発明と直接関係しないため説明は省略する。ソート処理部５２０の詳細については後述する。
【００３３】
＜ログ出力とソート処理＞
続いて実際のログ出力とソート処理についてフローチャートとログデータを用いて説明する。
【００３４】
図６はコントローラ２００が電源ＯｎされてからのＭａｉｎＣＰＵ２０６およびＳｕｂＣＰＵ２１８の起動時のデバッグログ処理のフローチャートである。コントローラ２００の電源ＯｎでまずＢｏｏｔＲＯＭ２０７経由で６０１でＭａｉｎＣＰＵ２０５の電源がＯｎされ、デバッグログの時刻源となるハードタイマがスタートする。６０２でＭａｉｎＣＰＵ２０５が管理するその他ハードウエアチェックを行い、６０３でオペレーティングしシステム（以下ＯＳと略する）を読み込み起動する。この時点でＳｕｂＣＰＵ２１８はまだ起動していない。続いて６０４でＭａｉｎＣＰＵはＳｕｂＣＰＵのファームウエアをＨＤＤから読み込み、６０５でＳｕｂＣＰＵ用のＲＡＭ２１９に転送後、６０７でＳｕｂＣＰＵを起動する。ＳｕｂＣＰＵ２１８起動はＭａｉｎＣＰＵ２０５からリセット解除することで行われ、これをうけてＳｕｂＣＰＵ２１８は６３０でスタートし、デバッグログ出力に使うハードタイマもスタートさせる。
【００３５】
ＭａｉｎＣＰＵでは６０７でＳｕｂＣＰＵのリセット解除した時点で、デバッグログにリセット時刻を出力する。このリセット時刻のデバッグログは通常のデバッグログ用領域に保持すると動作に伴い上書き消滅してしまうため、上書きされない起動情報領域に保持しており、デバッグログファイル化時点で同時に付加される。このＳｕｂＣＰＵリセット時刻は後述するログソート処理で利用される。
【００３６】
以後、ＭａｉｎＣＰＵ２０６およびＳｕｂＣＰＵ２１８は６１０、６３１で定常動作に入り、動作に伴ってデバッグログモジュール３１１と３２１にそれぞれ独立にデバッグ出力を継続する。電源Ｏｎから定常動作を通じて、ＭａｉｎＣＰＵ２０６とＳｕｂＣＰＵ２１８の間では時刻合わせあるいは時刻通知の処理は一切行わない。
【００３７】
図７にＭａｉｎ側およびＳｕｂ側のデバッグログ出力例を示す。Ｍａｉｎ側デバッグログ５１０とＳｕｂ側デバッグログ５１１にはそれぞれ開発者がファームウエアに埋め込んだログが行ベースで出力され、行ごとにタイムスタンプが付加されている。ただしこのタイムスタンプはＭａｉｎＣＰＵ２０５、ＳｕｂＣＰＵ２１８でそれぞれ異なる時刻源であるため、単純に時系列で対応付けることはできない。ＭａｉｎＣＰＵの起動後のＳｕｂＣＰＵが起動されるため、かならずＭａｉｎ側のデバッグログのほうがデバッグログのタイムスタンプもすすんでいる状態となっている。
【００３８】
図８でデバッグログ取得からソート処理のフローチャートを示す。図８ではコントローラ２００のＭａｉｎＣＰＵ２０５とＳｕｂＣＰＵ２１８、さらにホストＢの動作を合わせて示している。デバッグログの回収が開始されると、Ｍａｉｎ側デバッグログモジュール３１１が８０１でＲＡＭ２０６に保持しているデバッグログをＨＤＤ２０８にファイル化する。この際８０２で前記記録したＳｕｂＣＰＵリセット解除時刻を付加する。８０３でデバッグログモジュール３１１は、Ｓｕｂ側デバッグログモジュール３２１にＲＡＭ２１９に保持しているデバッグログファイル化を指示する。Ｓｕｂ側デバッグログモジュールは８１０でＳｕｂ側デバッグログをＨＤＤ２０８にファイル化して出力する。
【００３９】
８０４でＭａｉｎ側デバッグログモジュール３１１はホストＢへファイル化したデバッグログ５１０および５１１を転送する。本実施例ではホストＢへのデバッグログファイルを転送する手段はネットワークＩ／Ｆ２１１を介するものであるが、オフラインでメモリメディアによってホストＢへ運搬する方法などでも実施可能である。
【００４０】
ホストＢでは転送されたＭａｉｎ側デバッグログ５１０とＳｕｂ側デバッグログ５１１のソート処理として、まず８３０でＭａｉｎ側がＳｕｂＣＰＵをリセット解除した時刻を抽出する。さらに８３１でリセット解除時刻に、ＳｕｂＣＰＵのハードタイマスタートまでのタイムラグを加味して両ログのソートに必要な時間のゲタ値を算出する。８３２でソート処理部５２０はＳｕｂ側デバッグログ５１１のタイムスタンプに前記算出したゲタ値を加えて時間変換したファイルを出力し、さらにその変換後のログをＭａｉｎ側デバッグログ５１０と時間でソートする。８３３でそのソート結果をソートログ５３０として出力し、８３４で終了する。
【００４１】
図９にＭａｉｎ側デバッグログ５１０、Ｓｕｂ側デバッグログ５１１、およびそれをソートしたソートログ５３０の例を示す。図９ではコントローラ２００の電源Ｏｎ冒頭部分をサンプルとして示しており、Ｍａｉｎ側５１０ではログ中の５１５部分でＳｕｂ側のリセット解除を行っている。この時刻16.161197秒、は前述の起動時情報ようの領域にも退避される。Ｓｕｂ側５１１では時刻ゼロからデバッグログが開始しているが、Ｍａｉｎ側からみるとログ中の５１５に相当する時刻が時刻ゼロであり、Ｍａｉｎ側と単純な対応はつかない状態である。これをホストＢでソートした結果が５３０で、Ｍａｉｎ側の時刻を基準としてＳｕｂ側デバッグログにゲタあわせを行い、Ｍａｉｎ側の時系列で両者のデバッグログがソートされている。これによりファームウエア開発者は異なるＣＰＵ上のファームウエア動作の全容を理解しやすくなる。また画像処理装置Ａの動作中は各ＣＰＵは時刻合わせ処理が一切不要である。
【符号の説明】
【００４２】
Ａ  ：  本発明の実施例における画像処理装置
Ｂ  ：  本発明の実施例における外部装置
【図１】
2012190197.tif 000003
【図２】
2012190197.tif 000004
【図３】
2012190197.tif 000005
【図４】
2012190197.tif 000006
【図５】
2012190197.tif 000007
【図６】
2012190197.tif 000008
【図７】
2012190197.tif 000009
【図８】
2012190197.tif 000010
【図９】
2012190197.tif 000011