JP2018085107A - リブートシステム及び情報処理装置 - Google Patents

Abstract

【課題】 発生した通信不良の原因に応じた部分をリブート可能なリブートシステム及び情報処理装置を提供する。【解決手段】 一実施形態に係るリブートシステムは、定期的に確認メッセージを送信する第１ＣＰＵを備える操作部と、前記確認メッセージを受信すると前記第１ＣＰＵに応答メッセージを返信する第２ＣＰＵと、第３ＣＰＵと、を備える制御部と、を備え、前記第１ＣＰＵは、前記第２ＣＰＵから前記応答メッセージを受信できない場合、前記操作部と前記制御部との間に通信不良が発生したことを前記第３ＣＰＵに通知し、前記第３ＣＰＵは、前記通信不良の発生を通知されると、前記通信不良の原因を特定するための特定処理を実行し、特定した前記原因に対応する部分をリブートする。【選択図】 図２

Description

本発明は、リブートシステム及び情報処理装置に関する。

従来、制御部が備えるＣＰＵ（Central Processing Unit）と、操作部が備えるＣＰＵと、の間で定期的に通信することにより、制御部と操作部との間の通信不良の発生を検出する画像形成装置が知られている。この画像形成装置は、ＣＰＵ間の定期的な通信の遮断を検出することにより、通信不良の発生を検出し、自動的にリブートを実行し、発生した通信不良を解消する。

しかしながら、上記従来の画像形成装置では、通信不良が検出されるたびに装置全体がリブートされたため、消費電力が増大するという問題があった。

本発明は、上記の課題に鑑みてなされたものであり、発生した通信不良の原因に応じた部分をリブート可能なリブートシステム及び情報処理装置を提供することを目的とする。

一実施形態に係るリブートシステムは、定期的に確認メッセージを送信する第１ＣＰＵを備える操作部と、前記確認メッセージを受信すると前記第１ＣＰＵに応答メッセージを返信する第２ＣＰＵと、第３ＣＰＵと、を備える制御部と、を備え、前記第１ＣＰＵは、前記第２ＣＰＵから前記応答メッセージを受信できない場合、前記操作部と前記制御部との間に通信不良が発生したことを前記第３ＣＰＵに通知し、前記第３ＣＰＵは、前記通信不良の発生を通知されると、前記通信不良の原因を特定するための特定処理を実行し、特定した前記原因に対応する部分をリブートする。

本発明の各実施形態によれば、発生した通信不良の原因に応じた部分をリブート可能なリブートシステム及び情報処理装置を提供することができる。

画像形成装置の構成の一例を示す図。 画像形成装置が動作中に実行する処理の一例を示すフローチャート。 特定処理テーブルの一例を示す図。 通信不良の原因の特定処理の一例を模式的に示す図。 制御盤が起動時に実行する処理の一例を示すフローチャート。 通信不良の原因の特定処理の一例を模式的に示す図。 通信不良の原因の特定処理の一例を模式的に示す図。 通信不良の原因の特定処理の一例を模式的に示す図。 通信不良の原因の特定処理の一例を模式的に示す図。

以下、本発明の各実施形態について、添付の図面を参照しながら説明する。なお、各実施形態に係る明細書及び図面の記載に関して、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重畳した説明を省略する。

＜第１実施形態＞
第１実施形態に係る情報処理装置１００について、図１〜図４を参照して説明する。本実施形態に係る情報処理装置１００は、情報を処理する装置であり、例えば、画像形成装置、ＰＣ（Personal Computer）、携帯電話、スマートフォン、タブレット端末などである。画像形成装置には、複合機（ＭＦＰ：Multi-Function Peripheral）、印刷装置、コピー装置、ＦＡＸ装置などが含まれる。

情報処理装置１００は、装置の少なくとも一部をリブートするリブートシステムを備える。リブートシステムは、操作部と、制御部と、を備える。操作部は、情報処理装置１００のユーザインタフェース（入出力装置）であり、制御部は、情報処理装置１００の全体を制御する制御装置である。以下では、情報処理装置１００が画像形成装置である場合を例に説明する。情報処理装置１００を、画像形成装置１００と称する。

まず、画像形成装置１００の構成について説明する。図１は、画像形成装置１００の構成の一例を示す図である。図１の画像形成装置１００は、操作パネル１と、制御盤２と、印刷機能を実現する印刷装置３と、読取機能を実現するスキャナ装置４と、を備えるＭＦＰである。

操作パネル１は、操作部の一例であり、制御盤２と共にリブートシステムを構成する。図１の操作パネル１は、操作ＣＰＵ（Central Processing Unit）１１と、ＲＯＭ（Read Only Memory）１２と、ＲＡＭ（Random Access Memory）１３と、タッチパネル１４と、ディスプレイ１５と、接続インタフェース１６と、バス１７と、を備える。

操作ＣＰＵ１１（第１ＣＰＵ）は、プログラムを実行することにより、操作パネル１の各構成を制御し、操作パネル１の機能を実現するＣＰＵである。ＲＯＭ１２は、操作ＣＰＵ１１が実行するプログラムを含む各種の情報を記憶する。ＲＡＭ１３は、操作ＣＰＵ１１に作業領域を提供する。タッチパネル１４は、入力装置であり、ユーザからの操作を受け付け、受け付けた操作に応じた情報を入力する。画像形成装置１００は、タッチパネル１４の他に、ハードウェアキー、マウス、及びキーボードなどの入力装置を備えてもよい。ディスプレイ１５は、表示装置であり、画像形成装置１００を操作するための操作画面や、ユーザに通知するメッセージなどを表示する。接続インタフェース１６は、制御盤２と接続するためのインタフェースである。バス１７は、操作ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、タッチパネル１４、ディスプレイ１５及び接続インタフェース１６を接続する。

なお、本実施形態における操作部は、操作パネル１に限られない。操作部は、操作ＣＰＵと、入力装置と、出力装置と、接続インタフェースと、を備える任意の装置で有り得る。

制御盤２は、制御部の一例であり、操作パネル１と共にリブートシステムを構成する。図１の制御盤２は、メインＣＰＵ２１と、サブＣＰＵ２２と、接続インタフェース２３と、ＲＯＭ２４と、ＲＡＭ２５と、エンジン２６と、電源部２７と、バス２８と、を備える。

メインＣＰＵ２１（第２ＣＰＵ）及びサブＣＰＵ２２（第３ＣＰＵ）は、プログラムを実行することにより、制御盤２の各構成を制御し、制御盤２の機能を実現するＣＰＵである。メインＣＰＵ２１は、画像形成装置１００の全体を制御する。サブＣＰＵ２２は、画像形成装置１００に通信不良が発生した場合の制御を行う。接続インタフェース２３は、操作パネル１と接続するためのインタフェースである。メインＣＰＵ２１及びサブＣＰＵ２２は、接続インタフェース１６，２３を介して、操作パネル１のＣＰＵ１１と双方向に通信可能である。

ＲＯＭ２４は、メインＣＰＵ２１及びサブＣＰＵ２２が実行するプログラムを含む各種の情報を記憶する。ＲＡＭ２５は、メインＣＰＵ２１及びサブＣＰＵ２２に作業領域を提供する。エンジン２６は、メインＣＰＵ２１からの指示に従って、印刷装置３やスキャナ装置４を制御する。電源部２７は、メインＣＰＵ２１及びサブＣＰＵ２２からの指示に従って、操作パネル１及び制御盤２の電源をそれぞれ制御する。バス２８は、メインＣＰＵ２１、サブＣＰＵ２２、接続インタフェース２３、ＲＯＭ２４、ＲＡＭ２５、エンジン２６及び電源部２７を接続する。

なお、本実施形態における制御部は、制御盤２に限られない。制御部は、メインＣＰＵ、サブＣＰＵ、接続インタフェース２３及び電源部２７を備える任意の装置で有り得る。また、電源部２７は、制御部とは別に設けられてもよい。

次に、本実施形態に係る画像形成装置１００が実行する処理について説明する。図２は、画像形成装置１００が動作中（起動後）に実行する処理の一例を示すフローチャートである。

まず、操作ＣＰＵ１１が、所定のタイミングでメインＣＰＵ２１に確認メッセージを送信する（ステップＳ１０１）。確認メッセージは、操作パネル１と制御盤２との間の通信が正常に行われているか確認するためのメッセージである。メインＣＰＵ２１は、操作ＣＰＵ１１から確認メッセージを受信すると、受信した確認メッセージに応答し、応答メッセージを操作ＣＰＵ１１に返信する。

操作ＣＰＵ１１は、メインＣＰＵ２１から応答メッセージを受信した場合（ステップＳ１０２のＹＥＳ）、操作パネル１と制御盤２との間の通信が正常に行われていると判断し、所定時間待機する（ステップＳ１０３）。その後、処理はステップＳ１０１に戻り、操作ＣＰＵ１１は、再び確認メッセージをメインＣＰＵ２１に送信する。

一方、操作ＣＰＵ１１は、メインＣＰＵ２１から応答メッセージを受信できなかった場合（ステップＳ１０２のＮＯ）、操作パネル１と制御盤２との間で通信不良が発生したと判断し、その旨をサブＣＰＵ２２に通知する（ステップＳ１０４）。すなわち、操作ＣＰＵ１１は、操作パネル１と制御盤２との間で通信不良が発生したことをサブＣＰＵ２２に通知する。

このように、本実施形態において、操作ＣＰＵ１１は、画像形成装置１００の動作中、メインＣＰＵ２１に定期的に確認メッセージを送信し、メインＣＰＵ２１から定期的に応答メッセージを受信する。これにより、操作ＣＰＵ１１は、操作パネル１と制御盤２との間の通信が正常に行われているかを確認することができる。

サブＣＰＵ２２は、操作ＣＰＵ１１から通信不良の発生を通知されると、通信不良の原因を特定するための特定処理を実行する（ステップＳ１０５）。通信不良の原因として、例えば、メインＣＰＵ２１のハングアップや、操作ＣＰＵ１１とメインＣＰＵ２１との間の信号線の故障（断線や接触不良）などが考えられる。メインＣＰＵ２１がハングアップした場合、メインＣＰＵ２１は、確認メッセージに対する応答メッセージを返信できなくなる。また、信号線の故障が発生すると、確認メッセージがメインＣＰＵ２１に届かなくなり、応答メッセージが操作ＣＰＵ１１に届かなくなる。

サブＣＰＵ２２は、上記のような通信不良の原因と、当該原因となる事象が発生しているかを判断するための処理と、を対応付けた特定処理テーブルをＲＯＭ２４から読み出し、又はＲＡＭ２５に展開した特定処理テーブルを読み出し、各処理を実行することにより、通信不良の原因を特定する。

図３は、特定処理テーブルの一例を示す図である。図３の特定処理テーブルには、通信不良の原因として、メインＣＰＵ２１のハングアップと、信号線の故障と、が保存されている。なお、通信不良の原因及び対応する処理は、図３の例に限られない。

図４は、通信不良の原因の特定処理の一例を模式的に示す図である。具体的には、図４は、メインＣＰＵ２１のハングアップが発生しているかを判断するための処理を示している。上述の通り、操作ＣＰＵ１１は、メインＣＰＵ２１から応答メッセージを受信できない場合、サブＣＰＵ２２に通信不良の発生を通知する。サブＣＰＵ２２は、操作ＣＰＵ１１から通信不良の発生を通知されると、メインＣＰＵ２１に確認メッセージを送信し、当該確認メッセージに対する応答メッセージをメインＣＰＵ２１から受信する。メインＣＰＵ２１から応答メッセージを受信できた場合、サブＣＰＵ２２は、メインＣＰＵ２１はハングアップしていないと判断する。一方、メインＣＰＵ２１から応答メッセージを受信できない場合、サブＣＰＵ２２は、メインＣＰＵ２１のハングアップを通信不良の原因として特定する。図４の処理は、図３の特定処理テーブルの１行目の処理に相当する。

サブＣＰＵ２２は、特定処理により通信不良の原因を特定できなかった場合（ステップＳ１０６のＮＯ）、操作パネル１及び制御盤２を含む画像形成装置１００の全体をリブートする（ステップＳ１０７）。具体的には、サブＣＰＵ２２は、電源部２７に画像形成装置１００の全体のリブートを要求する。この要求に応じて、電源部２７が、画像形成装置１００の全体のリブートを実行する。発生した通信不良がリブートにより解消可能なものである場合、その原因が画像形成装置１００のどこに存在するとしても、当該リブートにより通信不良を解消することができる。画像形成装置１００の全体のリブートにより通信不良が解消されると、操作パネル１と制御盤２との間の正常な通信が再開される。

一方、サブＣＰＵ２２は、特定処理に通信不良の原因を特定できた場合（ステップＳ１０６のＹＥＳ）、特定された原因を、内蔵している不揮発性メモリやＲＯＭ２４に履歴情報として記憶する。この履歴情報は、画像形成装置１００の修繕や管理のために利用することができる。

次に、サブＣＰＵ２２は、特定された原因が、リブートにより通信不良を解消可能な原因であるか確認する（ステップＳ１０９）。サブＣＰＵ２２は、リブートにより通信不良を解消可能か否かを、上記のテーブルに、各原因と対応付けて記憶しておけばよい。

特定された原因が、リブートにより通信不良を解消不能な原因である場合（ステップＳ１０９のＮＯ）、サブＣＰＵ２２は、その旨を操作ＣＰＵ１１に通知する（ステップＳ１１０）。すなわち、サブＣＰＵ２２は、発生した通信不良がリブートにより解消不能であることを、操作ＣＰＵ１１に通知する。この際、サブＣＰＵ２２は、通信不良の原因を操作ＣＰＵ１１に通知してもよい。リブートにより解消可能な通信不良の原因として、操作ＣＰＵ１１とメインＣＰＵ２１との間の信号線の故障などが考えられる。

発生した通信不良がリブートにより解消不能であることを通知された操作ＣＰＵ１１は、操作パネル１のディスプレイ１５に、リブートにより解消不能な通信不良が発生したことや、通信不良の原因を、ユーザに知らせるメッセージを表示させる（ステップＳ１１１）。操作ＣＰＵ１１は、サービスマンコールエラーが発生したことをユーザに知らせるメッセージを表示してもよい。サービスマンコールエラーとは、ユーザによる復旧が困難であり、保守作業員（サービスマン）による修繕が必要なエラーのことである。ユーザは、当該メッセージを確認することにより、画像形成装置１００の状態を把握し、サービスマンを呼ぶなどの、適切な対処をすることができる。

一方、特定された原因が、リブートにより通信不良を解消可能な原因である場合（ステップＳ１０９のＹＥＳ）、サブＣＰＵ２２は、原因に対応する部分（以下、「対応部分」という）をリブートする（ステップＳ１１２）。具体的には、サブＣＰＵ２２は、電源部２７に対応部分のリブートを要求する。この要求に応じて、電源部２７が、対応部分のリブートを実行する。この際、サブＣＰＵ２２は、対応部分以外の部分をリブートしない。リブートにより解消可能な通信可能の原因として、メインＣＰＵ２１のハングアップなどが考えられる。

対応部分とは、独立してリブート可能な部分のうち、原因が発生している部分を含む部分のことである。例えば、操作パネル１及び制御盤２がそれぞれ独立してリブート可能な場合について考える。このとき、サブＣＰＵ２２は、原因が操作パネル１の内部（操作ＣＰＵ１１など）で発生している場合、対応部分である操作パネル１をリブートし、制御盤２を含む他の部分をリブートしない。また、サブＣＰＵ２２は、原因が制御盤２の内部（メインＣＰＵ２１など）で発生している場合、対応部分である制御盤２をリブートし、操作パネル１を含む他の部分をリブートしない。対応部分のリブートにより通信不良が解消されると、操作パネル１と制御盤２との間の正常な通信が再開される。

なお、サブＣＰＵ２２は、対応部分をリブートする際、対応部分をリブートすることや、通信不良の原因を、操作ＣＰＵ１１に通知してもよい。この通知を受けた操作ＣＰＵ１１は、ディスプレイ１５に、対応部分をリブートすることや、通信不良の原因を、ユーザに知らせるメッセージを表示させてもよい。ユーザは、当該メッセージを確認することにより、画像形成装置１００の状態を把握することができる。

以上説明した通り、本実施形態によれば、通信不良の発生が検出されると自動的にリブートが実行されるため、発生した通信不良を自動的に解消することができる。また、本実施形態によれば、通信不良の原因に応じた対応部分を選択的にリブートすることができるため、画像形成装置１００の全体をリブートする場合に比べ、リブートによる消費電力を低減することができる。また、本実施形態によれば、通信不良が発生するたびに画像形成装置１００の全体がリブートする場合に比べて、ユーザの不信感を低減することができる。

＜第２実施形態＞
第２実施形態に係る画像形成装置１００について、図５〜図９を参照して説明する。本実施形態では、制御盤２の起動時の処理について説明する。本実施形態における画像形成装置１００の構成は、第１実施形態と同様である。

図５は、制御盤２が起動時に実行する処理の一例を示すフローチャートである。図５のステップＳ２０４〜Ｓ２０９は、図２のステップＳ１０６〜Ｓ１１１と同様であるため、説明を省略する。

本実施形態では、制御盤２が起動すると、サブＣＰＵ２２が、通信不良の原因を特定するための特定処理を開始する（ステップＳ２０１）。この時点では、通信不良が発生するか不明であり、通信不良が発生しなかった場合には、その原因は特定されない。

図６〜図９は、通信不良の原因の特定処理の一例を模式的に示す図である。具体的には、図６〜図８は、操作パネル１と制御盤２との間の信号線が故障しているかを判断するための処理を示している。また、図９は、ＢＩＯＳ（Basic Input/Output System）が故障しているかを判断するための処理を示している。

図６の例では、信号線は、操作パネル１内でプルアップ抵抗に接続され、制御盤２内でプルダウン抵抗に接続されている。図６の信号線が正常である場合、制御盤２の起動時に、サブＣＰＵ２２にはＨレベルの信号が入力される。このため、サブＣＰＵ２２は、制御盤２の起動時に入力される信号のレベルを監視することにより、信号線の故障を検出することができる。図６の例では、サブＣＰＵ２２は、制御盤２の起動時に、Ｈレベルの信号が入力された場合、信号線は正常と判断し、Ｌレベルの信号が入力された場合、信号線は故障していると判断すればよい。信号線が故障していると判断された場合、信号線の故障が通信不良の原因として特定される。なお、上記のＨレベル及びＬレベルは、逆であってもよい。

図７の例では、サブＣＰＵ２２は、制御盤２の起動時に、操作ＣＰＵ１１とメインＣＰＵ２１との間の信号線上で行われる通信を監視することにより、信号線の故障を検出する。図７の例では、サブＣＰＵ２２は、制御盤２の起動時に、信号線上で通信が行われた場合、信号線は正常と判断し、信号線上で通信が行われなかった場合、信号線は故障していると判断すればよい。信号線が故障していると判断された場合、信号線の故障が通信不良の原因として特定される。

なお、サブＣＰＵ２２が、通信の監視を開始してから信号線が故障していると判断するまでの期間は、任意に設定可能である。また、図７の方法は、操作ＣＰＵ１１とメインＣＰＵ２１との間の通信が、シングルエンド方式で行われる場合に適している。これは、シングルエンド方式の場合、信号線上の信号を監視することにより、容易に通信の有無や内容を確認できるためである。

図８の例では、メインＣＰＵ２１は、制御盤２の起動時に、操作ＣＰＵ１１との間の通信が確立すると、その旨をサブＣＰＵ２２に通知する。サブＣＰＵ２２は、この通知を確認することにより、信号線の故障を検出することができる。図８の例では、サブＣＰＵ２２は、制御盤２の起動時に、メインＣＰＵ２１から通信の確立を通知された場合、信号線は正常と判断し、メインＣＰＵ２１から通信の確立を通知されない場合、信号線は故障していると判断すればよい。信号線が故障していると判断された場合、信号線の故障が通信不良の原因として特定される。図８の処理は、図３の特定処理テーブルの２行目の処理に相当する。

なお、サブＣＰＵ２２が、メインＣＰＵ２１からの通知の受け付けを開始してから信号線が故障していると判断するまでの期間は、任意に設定可能である。また、図８の方法は、操作ＣＰＵ１１とメインＣＰＵ２１との間の通信が、シングルエンド方式の場合であっても差動方式の場合であっても利用可能である。

図９の例では、サブＣＰＵ２２は、制御盤２の起動時に、メインＣＰＵ２１によるＢＩＯＳの実行を監視することにより、ＢＩＯＳの故障を検出する。図９の例では、サブＣＰＵ２２は、制御盤２の起動時に、メインＣＰＵ２１がＢＩＯＳを実行し、メインＣＰＵ２１が正常に起動した場合、ＢＩＯＳは正常と判断すればよい。一方、サブＣＰＵ２２は、メインＣＰＵ２１によるＢＩＯＳの実行中にエラーが発生し、メインＣＰＵ２１が正常に起動しなかった場合、ＢＩＯＳは故障していると判断すればよい。ＢＩＯＳが故障していると判断された場合、ＢＩＯＳの故障が通信不良の原因として特定される。

なお、サブＣＰＵ２２が、メインＣＰＵ２１によるＢＩＯＳの実行を監視する代わりに、メインＣＰＵ２１がＢＩＯＳを実行し、正常に起動した後に、その旨をサブＣＰＵ２２に通知してもよい。

本実施形態において、サブＣＰＵ２２は、制御盤２の起動中に、上記のような特定処理を実行する。その後、制御盤２が正常に起動し、操作パネル１と制御盤２との間の通信が開始された場合（ステップＳ２０２のＹＥＳ）、起動時の処理が終了する。その後、図２の処理が開始される。この場合、通信不良は発生しないため、通信不良の原因は特定されない。

一方、制御盤２が正常に起動されず、操作パネル１と制御盤２との間の通信が開始されない場合（ステップＳ２０２のＮＯ）、操作ＣＰＵ１１は、操作パネル１と制御盤２との間で通信不良が発生したと判断し、その旨をサブＣＰＵ２２に通知する（ステップＳ２０３）。すなわち、操作ＣＰＵ１１は、操作パネル１と制御盤２との間で通信不良が発生したことをサブＣＰＵ２２に通知する。その後、ステップＳ２０４以降の処理が実行される。

このように、本実施形態において、操作ＣＰＵ１１は、制御盤２の起動時に、操作パネル１と制御盤２との間の通信が開始されるか否かを監視し、開始されない場合、操作パネル１と制御盤２との間で通信不良が発生したと判断する。操作ＣＰＵ１１が起動してから通信不良が発生したと判断するまでの期間は、任意に設定可能である。また、本実施形態では、通信不良の原因の特定処理は、操作ＣＰＵ１１により通信不良が検出されるより前に、サブＣＰＵ２２により予め実行される。

以上説明した通り、本実施形態によれば、制御盤２の起動時に通信不良の原因の特定処理が予め実行されるため、通信不良の検出後に特定処理を実行する場合に比べて、通信不良の検出後の処理に要する時間を短縮することができる。また、本実施形態によれば、ＢＩＯＳの故障のような、制御盤２の起動時にしか特定できない通信不良の原因を特定することができる。

なお、上記実施形態に挙げた構成等に、その他の要素との組み合わせなど、ここで示した構成に本発明が限定されるものではない。これらの点に関しては、本発明の趣旨を逸脱しない範囲で変更することが可能であり、その応用形態に応じて適切に定めることができる。

１：操作パネル
２：制御盤
１１：操作ＣＰＵ
２１：メインＣＰＵ
２２：サブＣＰＵ
１００：画像形成装置

特開２０１５−０４９７３１号公報

Claims (9)

1. 定期的に確認メッセージを送信する第１ＣＰＵ（Central Processing Unit）を備える操作部と、
   前記確認メッセージを受信すると前記第１ＣＰＵに応答メッセージを返信する第２ＣＰＵと、第３ＣＰＵと、を備える制御部と、
   を備え、
   前記第１ＣＰＵは、前記第２ＣＰＵから前記応答メッセージを受信できない場合、前記操作部と前記制御部との間に通信不良が発生したことを前記第３ＣＰＵに通知し、
   前記第３ＣＰＵは、前記通信不良の発生を通知されると、前記通信不良の原因を特定するための特定処理を実行し、特定した前記原因に対応する部分をリブートする
   リブートシステム。
2. 前記第３ＣＰＵは、前記原因が前記操作部で発生している場合、前記操作部をリブートする
   請求項１に記載のリブートシステム。
3. 前記第３ＣＰＵは、前記原因が前記制御部で発生している場合、前記制御部をリブートする
   請求項１又は請求項２に記載のリブートシステム。
4. 前記第３ＣＰＵは、前記原因に対応する部分をリブートすることを、前記第１ＣＰＵに通知する
   請求項１乃至請求項３のいずれか１項に記載のリブートシステム。
5. 前記第３ＣＰＵは、前記原因が特定できない場合、前記操作部及び前記制御部をリブートする
   請求項１乃至請求項４のいずれか１項に記載のリブートシステム。
6. 前記第３ＣＰＵは、リブートにより前記通信不良を解消できない場合、その旨を前記第１ＣＰＵに通知する
   請求項１乃至請求項５のいずれか１項に記載のリブートシステム。
7. 前記第３ＣＰＵは、特定した前記原因の履歴情報を記憶する
   請求項１乃至請求項６のいずれか１項に記載のリブートシステム。
8. 前記第２ＣＰＵは、前記制御部の起動時に前記特定処理を実行する
   請求項１乃至請求項７のいずれか１項に記載のリブートシステム。
9. 請求項１乃至請求項８のいずれか１項に記載のリブートシステムを備える情報処理装置。

Images