説明

ログ処理システム

【課題】動作中にCPU間の時刻合わせを行うとファームウエアの負荷が高くなる問題を回避するログ処理システムを提供する。
【解決手段】SubCPU218群の起動時刻をMainCPU205で記録しておき、各SubCPU218でタイムスタンプを付加したデバッグログを収集し、前記収集したデバックログを二次記憶装置に退避させたうえ、外部装置に転送させた後に、前記外部装置上で前記記録したSubCPU218群の起動時刻に基づき、前記デバッグログの時系列ソートを可能とした。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、異なるCPU同士の動作ログを時系列でソートするログ処理システムに関するものである。
【背景技術】
【0002】
近年の画像処理装置、たとえばプリンタや複写機はデジタル化がすすむと同時に制御ソフトウエアの規模、機能も拡大している。同時に画像処理装置を制御するコントローラも装置の機能および処理量増大に伴い、複数のCPUを備え、並列処理で装置制御を行う場合が多い。CPUを複数同時に並列動作させることで、ユーザインターフェイス(以下UIと略する)の動作と装置内での画像処理とを同時に処理し、装置全体としての性能を大きく向上させることが可能となっている。
【0003】
一方で、複数のCPU上で実行される制御ソフトウエアが相互に通信しながら装置全体の処理が行われるため、そのソフトウエア開発中のデバッグの難易度もまた高くなっているという問題がある。特に近年の画像処理装置のコントローラでは、ハードウエアによるデバッグ支援装置が提供されないCPUを採用することも増えている。その場合、おもにソフトウエア中に埋め込んだデバッグメッセージをデバッグログとして出力し、動作確認や不具合調査に使うことが広く行われている。複数のCPUがある場合、デバッグログも各CPUごとのタイムスタンプを用いてそれぞれ別々のデバッグログとしてファイルとして回収、デバッグに提供することが多い。
【0004】
このような場合、各CPUのデバッグログのタイムスタンプが共通であれば、各CPU上のソフト動作をわかりやすく把握できるため、ソフトウエアのデバッグ効率を大きく改善することができる。そのため、例えば特許文献1のように、複数のソフトウエアの動作ログのタイムスタンプの時刻合わせを高精度で実現する方法が発明されている。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2007-026048号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
しかしながら、前記引用した先行技術では時刻合わせのための処理がソフトウエア実行中に必要であり、画像処理装置の動作中にデバッグ目的のための時刻合わせの処理負荷が発生してしまうという問題があった。
【課題を解決するための手段】
【0007】
おのおの独立した内部タイマをもつ複数のCPUを用いてシステム制御を行う画像処理装置と、動作ログ分析を行う外部装置から構成されるログ処理システムで、
画像処理装置はシステムの電源オンでファームエアを読み込み自動起動される、メインCPUと、
メインCPUから起動をキックされる1つ以上のサブCPUと、
メインCPUは各サブCPUをキックした時刻をメインCPUのタイマ時刻で記憶する時間記憶手段と、
各CPUで実行されるファームウエアの動作ログを、前記タイマハードからえたタイムスタンプを付加してバッファリングするロギング手段と、
前記ロギング機能によってバッファリングされた動作ログデータを、前記時間記憶手段によって記録された各サブCPUキック時刻とともに二次記憶装置に退避する、ログ保存手段と、
前記ログ保存手段によって保存されたログを外部装置に転送する、ログ転送手段と、
ログを転送した外部装置において、前記メインCPUの動作ログから各サブCPUのキック時刻と、各サブCPUのログ用タイマ開始ラグ時間とを抽出し、各サブCPUの動作ログのタイムスタンプに前記キック時刻とタイマ開始ラグの合計値を加算することで、各CPUの動作ログの時系列でのソートしたソートログを出力することを特徴とする。
【発明の効果】
【0008】
ファームウエアの実行中、CPU間での時間合わせ処理を一切行うことなく、異なるCPU同士の動作ログを時系列でソートすることができる。
【図面の簡単な説明】
【0009】
【図1】本実施例に係るログ処理システム全体を示す概要図である。
【図2】画像処理装置Aのコントローラハード構成図である。
【図3】画像処理装置Aのコントローラソフトの構成図である。
【図4】画像処理装置Aの全体概要図である。
【図5】ホストBの構成図である。
【図6】画像処理装置Aにおけるデバッグログ出力動作のフローチャートである。
【図7】画像処理装置Aが出力するデバッグログのデータ例である。
【図8】デバッグログの回収とソート結果をえるまでのフローチャートである。
【図9】デバッグログのソート結果のデータ例である。
【発明を実施するための形態】
【0010】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【0011】
図1は本実施例のログ処理システム全体を示す概要図である。本実施例に示すログ処理システムは、画像処理装置Aと、デバッグログのソート処理を行うホストBから構成される。
【0012】
まず画像処理装置Aのカラー系画像処理装置の構成について、図4を用いて説明する。
【0013】
1Dカラー系画像処理装置は、操作部、スキャナエンジン、レーザ露光部、感光ドラム、作像部、定着部、給紙/搬送部からなるプリンタエンジン、さらに図1には不図示のコントローラユニットで構成される。コントローラユニットについては後述の図2で説明する。
【0014】
操作部はユーザからの操作や装置全体のステータス表示などを行なう入力キーや表示画面から構成され、画像処理装置とユーザとのユーザインターフェース機能を提供する。
【0015】
スキャナエンジンは、原稿台に置かれた原稿に対して、照明を当てて原稿画像を光学的に読み取り、その像を電気信号に変換して画像データを作成する。
【0016】
プリンタエンジンのレーザ露光部は、前記画像データに応じて変調されたレーザ光などの光線を等角速度で回転する回転多面鏡(ポリゴンミラー)に入射させ、反射走査光として感光ドラムに照射する。作像部は、感光ドラムを回転駆動し、帯電器によって帯電させ、前記レーザ露光部によって感光ドラム上に形成された潜像をトナーによって現像化し、そのトナー像をシートに転写する。その際に転写されずに感光ドラム上に残った微小トナーを回収するといった一連の電子写真プロセスを実行して作像する。その際、シートが転写ベルトの所定位置に巻きつき、4回転する間に、マゼンタ(M)、シアン(C)、イエロー(Y)、ブラック(K)のトナーを持つそれぞれの現像ユニット(現像ステーション)が入れ替わりで順次前述の電子写真プロセスを繰り返し実行する。4回転の後、4色のフルカラートナー像を転写されたシートは、転写ドラムを離れ、定着部へ搬送される。
【0017】
定着部は、ローラやベルトの組み合わせによって構成され、ハロゲンヒータなどの熱源を内蔵し、前記作像部によってトナー像が転写されたシート上のトナーを、熱と圧力によって溶解、定着させる。
【0018】
給紙/搬送部は、シートカセットやペーパーデッキに代表されるシート収納庫を一つ以上持っており、前記プリンタ制御部の指示に応じてシート収納庫に収納された複数のシートの中から一枚分離し、作像部・定着部へ搬送する。シートは作像部の転写ドラムに巻きつけられ、4回転した後に定着部へ搬送される。4回転する間に前述のYMCK各色のトナー像がシートに転写される。また、シートの両面に画像形成する場合は、定着部を通過したシートを再度作像部へ搬送する搬送経路を通るように制御する。
【0019】
上記各機能部はコントローラユニットで実行されるコントローラソフトによって統合制御されており、それぞれコントローラソフトと相互に通信を行ないつつ画像処理装置機能動作を実現するものである。コントローラソフトについては図3で後述する。
【0020】
ホストBの構成を図5で説明する。ホストBは画像処理装置Aの異なるCPUが独立に出力するデバッグ出力を時系列でソートするソート処理部520を備える。ソート処理部520に異なるCPUから出力されたデバッグログ510および511を入力すると、時系列でソートしたソートログ530を出力する。ここで、ホストBを構成するオペレーティングシステム、およびソート処理部520を実現するプログラムは時系列でソートされたログを出力できればその種類や実装手段にはなんら依存しないものである。これらの詳細は本発明とは関係しないため説明は割愛する。
【0021】
<画像処理装置Aのコントローラユニットの構成>
図2は、本実施形態における画像処理装置のコントローラの一構成例を示すハードウエアブロック図である。図2において、コントロールユニット200は、画像入力デバイスであるスキャナ201や画像出力デバイスであるプリンタエンジン202と接続し、画像データの読み取りやプリント出力のための制御を行う。また、コントロールユニット200は、LAN10と接続することで、画像情報やデバイス情報を入出力するための制御を行う。
【0022】
MainCPU205はおもに装置全体のシステム的な制御とアプリケーションプログラムを制御するための中央処理装置である。RAM206は、MainCPU205が動作するためのシステムワークメモリであり、MainCPUが出力するデバッグログも保持する領域も確保されている。SubCPU218は主にスキャナエンジン201、プリンタエンジン202のリアルタイム制御、および画像処理の制御をつかさどり、MainCPU205と連携してコピー機能、PDLプリント機能を実現する。RAM219はSubCPU218用のメインメモリであり、SubCPU218が出力するデバッグログ出力領域もここに割り当てられている。
【0023】
BootROM207には、コントローラの電源がON後、MainCPU205を起動するために最初に実行されるシステムのブートプログラムが格納されている。ここで、電源Onで起動されるのはMainCPU205のみである。SubCPU218の起動は、MainCPU205のファームウエアが起動し、そのファームウエアがSubCPU218用のファームウエアをロード、起動させることで行われる。
【0024】
HDD208はハードディスクドライブであり、各種処理のためのシステムソフトウェア及び入力された画像データ、さらにシステムイメージのスナップショットを等格納する。操作部I/F209は、画像データ等を表示可能な表示画面を有する操作部210に対するインタフェース部であり、操作部210に対して操作画面データを出力する。また、操作部I/F209は、操作部210から操作者が入力した情報をCPU205に伝える役割をする。ネットワークインタフェース211は、例えばLANカード等で実現され、LAN10に接続して外部装置との間で情報の入出力を行う。
【0025】
イメージバスI/F214は、システムバス213と画像データを高速で転送する画像バス215とを接続するためのインタフェースであり、データ構造を変換するバスブリッジである。画像バス215上には、ラスタイメージプロセッサ(RIP)216、デバイスI/F217が接続される。
【0026】
ラスタイメージプロセッサ(RIP)216は、ページ記述言語(PDL)コードや後述するベクトルデータをイメージに展開する。デバイスI/F部217は、スキャナ201やプリンタエンジン202とコントローラ200とを物理的に接続し、画像データの同期系/非同期系の変換を行う。
【0027】
また、画像処理部218は、スキャナ201から読み込んだ画像やプリンタ202に出力しようとしている画像に応じた補正、解像度変換等の処理を行う。画像処理はスキャナ201、プリンタ202の速度に対応したリアルタイム処理が必要なため、画像処理ボード203の高速な専用処理ハードウエアによって処理実行される。
【0028】
<画像処理装置Aのコントローラソフト構成>
図3は、本実施形態における画像処理装置のコントローラ200で実行され、画像処理装置全体の制御を行なうコントローラソフトの構成図である。
【0029】
コントローラソフトはMainCPU205で実行されるMain側310と、SubCPU218で実行されるSub側320から構成され、それぞれファームウエアが出力するデバッグログをRAM上に出力するデバッグログモジュールを含む。Main側310はおもにシステム全体制御とアプリケーション層の制御を管理し、操作部210から入力された動作指示にしたがって画像処理装置A全体としての機能動作を実現する。Sub側320はスキャナエンジン201、プリンタエンジン202、画像処理ボード203などのリアルタイム制御を行う。例えば操作部210からコピー動作の指示が行われた場合、Main側310は指示された動作内容にしたがってSub側320に必要な動作指示を行い、Sub側320はそれに応じて物理的なデバイス動作の制御を行う。より詳細には原稿読み取り開始指示とその完了通知、画像処理パラメタの通知と応答、プリント開始指示と完了通知、のようにMain側310とSub側320と通信を行い、装置全体としてのコピー機能を実現する。
【0030】
Main側310、Sub側320ともにファームウエアには内部動作状態を出力するデバッグログが埋め込まれており、動作に伴ってデバッグログモジュール311および321によってRAM上にリングバッファで管理された領域にログ出力が行われる。デバッグログモジュールはログ出力の際、自CPUの時刻情報をもとに出力のたびにタイムスタンプを付加し、デバッグを容易にする。ただし、MainCPU206とSubCPU218の時刻情報はそれぞれ独立しており、したがっておのおののデバッグログに吹かされているタイムスタンプも異なる時間となっている。
【0031】
ファームウエアのソフト例外の発生など、不具合が発生した場合はデバッグログモジュール311および321がRAM206および219に保持しているデバッグログをファイル化する。各デバッグログはHDD208のファイルとしてMain側ログ511、Sub側ログ510として保存される。HDD208にファイル化されるとRAM311および321の領域と異なり上書きされることは無く保持され、ネットワークI/F210などから外部装置に転送することができる。
【0032】
<ホストBの構成>
Main側デバッグログ510とSub側デバッグログ511のソートを行うホストBの構成を図5で説明する。ホストBは入力となるMain側とSub側のデバッグログファイル510と511をソート処理部520に入力し、Main側のタイムスタンプ基準で並び替え、ソートログとして出力する。ソートログの閲覧方法などは本発明と直接関係しないため説明は省略する。ソート処理部520の詳細については後述する。
【0033】
<ログ出力とソート処理>
続いて実際のログ出力とソート処理についてフローチャートとログデータを用いて説明する。
【0034】
図6はコントローラ200が電源OnされてからのMainCPU206およびSubCPU218の起動時のデバッグログ処理のフローチャートである。コントローラ200の電源OnでまずBootROM207経由で601でMainCPU205の電源がOnされ、デバッグログの時刻源となるハードタイマがスタートする。602でMainCPU205が管理するその他ハードウエアチェックを行い、603でオペレーティングしシステム(以下OSと略する)を読み込み起動する。この時点でSubCPU218はまだ起動していない。続いて604でMainCPUはSubCPUのファームウエアをHDDから読み込み、605でSubCPU用のRAM219に転送後、607でSubCPUを起動する。SubCPU218起動はMainCPU205からリセット解除することで行われ、これをうけてSubCPU218は630でスタートし、デバッグログ出力に使うハードタイマもスタートさせる。
【0035】
MainCPUでは607でSubCPUのリセット解除した時点で、デバッグログにリセット時刻を出力する。このリセット時刻のデバッグログは通常のデバッグログ用領域に保持すると動作に伴い上書き消滅してしまうため、上書きされない起動情報領域に保持しており、デバッグログファイル化時点で同時に付加される。このSubCPUリセット時刻は後述するログソート処理で利用される。
【0036】
以後、MainCPU206およびSubCPU218は610、631で定常動作に入り、動作に伴ってデバッグログモジュール311と321にそれぞれ独立にデバッグ出力を継続する。電源Onから定常動作を通じて、MainCPU206とSubCPU218の間では時刻合わせあるいは時刻通知の処理は一切行わない。
【0037】
図7にMain側およびSub側のデバッグログ出力例を示す。Main側デバッグログ510とSub側デバッグログ511にはそれぞれ開発者がファームウエアに埋め込んだログが行ベースで出力され、行ごとにタイムスタンプが付加されている。ただしこのタイムスタンプはMainCPU205、SubCPU218でそれぞれ異なる時刻源であるため、単純に時系列で対応付けることはできない。MainCPUの起動後のSubCPUが起動されるため、かならずMain側のデバッグログのほうがデバッグログのタイムスタンプもすすんでいる状態となっている。
【0038】
図8でデバッグログ取得からソート処理のフローチャートを示す。図8ではコントローラ200のMainCPU205とSubCPU218、さらにホストBの動作を合わせて示している。デバッグログの回収が開始されると、Main側デバッグログモジュール311が801でRAM206に保持しているデバッグログをHDD208にファイル化する。この際802で前記記録したSubCPUリセット解除時刻を付加する。803でデバッグログモジュール311は、Sub側デバッグログモジュール321にRAM219に保持しているデバッグログファイル化を指示する。Sub側デバッグログモジュールは810でSub側デバッグログをHDD208にファイル化して出力する。
【0039】
804でMain側デバッグログモジュール311はホストBへファイル化したデバッグログ510および511を転送する。本実施例ではホストBへのデバッグログファイルを転送する手段はネットワークI/F211を介するものであるが、オフラインでメモリメディアによってホストBへ運搬する方法などでも実施可能である。
【0040】
ホストBでは転送されたMain側デバッグログ510とSub側デバッグログ511のソート処理として、まず830でMain側がSubCPUをリセット解除した時刻を抽出する。さらに831でリセット解除時刻に、SubCPUのハードタイマスタートまでのタイムラグを加味して両ログのソートに必要な時間のゲタ値を算出する。832でソート処理部520はSub側デバッグログ511のタイムスタンプに前記算出したゲタ値を加えて時間変換したファイルを出力し、さらにその変換後のログをMain側デバッグログ510と時間でソートする。833でそのソート結果をソートログ530として出力し、834で終了する。
【0041】
図9にMain側デバッグログ510、Sub側デバッグログ511、およびそれをソートしたソートログ530の例を示す。図9ではコントローラ200の電源On冒頭部分をサンプルとして示しており、Main側510ではログ中の515部分でSub側のリセット解除を行っている。この時刻16.161197秒、は前述の起動時情報ようの領域にも退避される。Sub側511では時刻ゼロからデバッグログが開始しているが、Main側からみるとログ中の515に相当する時刻が時刻ゼロであり、Main側と単純な対応はつかない状態である。これをホストBでソートした結果が530で、Main側の時刻を基準としてSub側デバッグログにゲタあわせを行い、Main側の時系列で両者のデバッグログがソートされている。これによりファームウエア開発者は異なるCPU上のファームウエア動作の全容を理解しやすくなる。また画像処理装置Aの動作中は各CPUは時刻合わせ処理が一切不要である。
【符号の説明】
【0042】
A : 本発明の実施例における画像処理装置
B : 本発明の実施例における外部装置

【特許請求の範囲】
【請求項1】
おのおの独立した内部タイマをもつ複数のCPU(205および218)を用いてシステム制御を行う画像処理装置(A)と、動作ログ加工を行う外部装置(B)から構成されるログ処理システムで、
画像処理装置はシステムの電源オンでファームエアを読み込み自動起動される、メインCPU(205)と、
メインCPU(205)から起動をキックされる1つ以上のサブCPU(218)と、
メインCPU(205)は各サブCPU(218)を起動した時刻をメインCPUのタイマ時刻で記憶する時間記憶手段と、
各CPUで実行されるファームウエアの動作ログ(510および511)を、前記タイマハードからえたタイムスタンプを付加してバッファリングするロギング手段(311および321)と、
前記ロギング機能によってバッファリングされた動作ログデータを、前記時間記憶手段によって記録された各サブCPU起動時刻とともに二次記憶装置(208)に退避する、ログ保存手段(311および321)と、
前記ログ保存手段によって保存されたログを外部装置に転送する、ログ転送手段と、
ログを転送した外部装置(B)において、前記メインCPUの動作ログから各サブCPUのキック時刻と、各サブCPUのログ用タイマ開始ラグ時間とを抽出し、各サブCPUの動作ログのタイムスタンプに前記キック時刻とタイマ開始ラグの合計値を加算することで、各CPUの動作ログの時系列でのソートしたソートログ(530)を出力することを特徴とするログ処理システム。
【請求項2】
前記各CPUのタイマはバッテリバックアップされたカレンダー時刻であることを特徴とする、請求項1に記載のログ処理システム。
【請求項3】
前記各CPUのタイマは起動からのCPUクロックカウントレジスタの値であることを特徴とする、請求項1に記載のログ処理システム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate


【公開番号】特開2012−190197(P2012−190197A)
【公開日】平成24年10月4日(2012.10.4)
【国際特許分類】
【出願番号】特願2011−52308(P2011−52308)
【出願日】平成23年3月10日(2011.3.10)
【出願人】(000001007)キヤノン株式会社 (59,756)
【Fターム(参考)】