JP2829040B2 - 情報集配信システム - Google Patents

Description

【発明の詳細な説明】 【発明の利用分野】

本発明は、無停止運転方式の情報集配信システムに関
し、特に端末へのサービスを止めずに端末数の増加を可
能とする情報集配信システムに関する。

【従来の技術】

従来、オンラインシステムの拡大に伴い、接続される
端末数が増加して、ホストコンピュータの処理負荷が増
大したため、この負荷を低減し、より質の高いサービス
を提供するように、複数のホストコンピュータ間の通信
によりホストコンピュータ上の資源を相互利用する分散
処理システムが開発されてきている。 このようなマルチ計算機システム、特に情報集配信シ
ステムでは、端末とその端末にサービスを行なう計算機
と、システム外部より情報を収集する計算機とが、上下
一直線に接続されて、階層構造を形成している。そし
て、同一階層上にある要素間の通信は、１階層上の要素
を介して１対１で行なっていた。第２図に、そのような
従来システムの一例を示す。 またこのようなシステムの信頼性を上げるため従来、
各要素を２重化し、システム構築時・拡張時には常にこ
の２つを１組として扱うこととしていた。 なお、この種の装置として関連するものには、例えば
“フォールトトレラントシステム，グレイ著，渡辺栄一
訳編，マグロウヒルブック株式会社,1986年”が挙げら
れる。

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

上記従来技術では、システムの２要素間、特に同じ業
務を行なう要素間での通信を上位階層の要素を介して行
なわなければならず、従って上位の要素に障害が生じた
場合、あるいは上位要素を保守拡張する場合、下位の要
素間での通信に支障が生じ、業務の冗長化や肩代わりが
できなくなる問題があった。 本発明の目的は、このような問題点を改善し、システ
ム全体として拡張性・保守性の高い情報集配信システム
を提供することにある。

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

上記目的を達成するため、本発明の計算機システムで
は、複数のホスト計算機と、複数のターミナルハンドラ
と、端末制御装置（以下CCVと称する。）のうち２つ以
上の伝送媒体に接続し、またこの伝送媒体に接続された
各要素は、各々伝送媒体より入力されるデータの中から
自身の処理に必要なデータを選択して取り込んで処理を
行ない、また必要なら処理結果を共通伝送媒体に送出す
ることを特徴とする。 また、この共通伝送媒体に送出するデータには、この
データの内容種別を示す内容コードを付してあり共通伝
送媒体に接続された各要素はコードによって選択を行な
うこととした。 また、本発明では、共通伝送媒体に接続された各要素
は、上記内容コードを付した内容コードデータの到着時
刻を計測する手段と、この到着時刻を記憶する手段と、
内容コードデータが所定時間間隔で到着したか否かを判
定する手段とを備え、内容コードデータを所定の時間間
隔で常時送出して、内容コードデータが所定の時間以内
（以下、しきい値と称する。）に到着しない場合には、
該当要素に障害が発生したと判断することに特徴があ
る。 また、ターミナルハンドラ（以下、THと略称する。）
とCCUが共通伝送媒体に接続されている場合、各TH毎に
管理する端末を設定し、各THは、管理下の端末に対する
情報を送出し、自分以外のTHの障害を検知した場合に、
この障害THが管理すべき端末に対する情報をも送出する
ことに特徴がある。 また、CCUは、THから送出された情報の要否を判定し
て、必要と判定した情報のみを自装置へ接続された端末
へ出力することに特徴がある。 また、THが管理する端末を、必要なら複数のTH間で多
重に設定し、この端末を接続するCCUは、複数のTHから
多重に送出された情報の要否を判定し、必要と判定した
情報のみを端末へ出力することとした。 また、端末が要求する情報の種類をTHへ登録する場
合、端末は、登録するデータに内容コードと、端末を示
す識別子を付加して共通伝送媒体へ送出し、登録データ
を受信したTHは、端末識別子毎に登録することに特徴が
ある。 また、THが登録データに基き、編集・加工したデータ
を送出する場合、登録データの端末識別子を付加して送
出し、CCUは自身に接続された端末の識別子と、内容コ
ードにより取り込んだデータ内の端末識別子とにより、
出力先の端末を識別してデータを出力することとした。 また、THのみ、またはシステム外部からの情報を収集
する計算機（ホスト計算機）とTHの２つのみ、のいずれ
かが共通伝送媒体に接続されている場合には、各THが、
自身が管理下におく全CCUの識別子及び、自THと管理下
にあるCCU間の接続部分の状態を含むデータ（i/0状態）
を共通伝送媒体に送出する第１の機能と、データを収集
し、THとCCUの接続状態を診断する第２の機能と、この
第２の機能により、他THの管理下にあるCCUと他THとの
間の接続に障害が生じたこと、または他THが障害を起こ
したことを検知した時に、このCCUを自THの管理下に置
く第３の機能とを備えることに特徴がある。 また、しきい値を、内容コードデータの到着時間間隔
に応じて、変化させることに特徴がある。

【作用】

本発明では、伝送媒体に接続された各要素は、自己の
必要なデータを、伝送媒体から選択して取り込み処理を
行なうので、各要素は全システムにおける役割によら
ず、自由に通信可能であり、また、伝送媒体を介するこ
とにより、各要素間での情報生成の肩代わりや冗長化を
オンラインで行なうことができる。

【実施例】

以下本発明の一実施例を図面により詳細に説明する。 1.システム構成 第１図（ａ）は、本発明を実施したシステム全体の構
成図である。記号01,02,11〜1nはCPUであり、そのうち0
1,02は回線により外部に接続されている。また計算機0
1,02,11〜1nは、共通伝送媒体３に接続されている。本
図ではリング型ネットワークで表わしているが、バス型
ネットワークや、完全グラフ構造の１対１接続でも差し
つかえない。41〜4mは端末とCPU間の通信を制御するCCU
であり、511〜5mkは端末である。また、CCUはCPUと接続
可能な２個以上の通信ポートを持ち、各々異なるCPUと
接続されている。端末511〜5mkはCCU41〜4mのいずれか
と接続され、このCCUを介してCPU11〜1nのいずれかから
のサービスを受けるように構成されている。また、各CP
U11〜1nは各々ディスク装置（以下、DISCと称する。）2
1〜2nを、CPU01,02はDISC1,2を持つ。 DISC20の内容は、回線00より受信したオンラインデー
タの変化歴（以下ヒストリデータと称する。）からな
る。また、DISC21〜2nには、オンラインデータの最新値
（以下カレントデータと称する。）が記憶されている。
なお、このような蓄積ができる例としては、株式の現値
情報がある。 2.通常稼動時の動作 本システムの業務は、（１）回線より受信されるデー
タに基くユーザ端末画面の自動更新、（２）ユーダ端末
からの自動更新対象データ項目登録、（３）ユーザ端末
からのカレントデータ問合せ、（４）ユーザ端末からの
ヒストリデータ問合せ、の４種に分けられる。以下、各
々の場合についてシステムの動作を説明するが、その前
にいくつかの用語を定義する。 各CPUについて、物理的に回線接続されているCCUを
「可担当CCU」と呼ぶ。可担当CCUに対し接続割込みをか
け、論理回線を開いてサービス可能とすることを単に
「接続」という。なお、CCUの通信ポート中いずれが有
効となるかは、後着優先により決まる。例えば、2CPUを
相前後して1CCUに接続しようとした場合、最後に接続し
たものが有効となるようにCCUのハードウェアは構成さ
れている。 さらに、CPUによって接続されて、サービス可能とな
っている（他のCPUによって奪われていない。）CCUを、
当該CPUの「担当CCU」と称する。全システムが正常なる
時、各CPUが引き込んでいるCCUを「専用CCU」と称す
る。 更に、CPU11〜1nは自CPUの可担当端末（可担当CCU下
の端末）について、各々がどのデータ項目を表示中かを
示す「端末管理テーブル」を持つ。第２図に、同テーブ
ルの形式の一例を示す。 （１）自動更新の手順を第１図（ｂ）により説明すると
以下の通りである。まず回線00からオンラインデータが
受信された時、CPU10はこのデータをDISC20へ蓄積する
と共に、回線01〜0nを介してCPU11〜1nへ同報する。第
１図（ｂ）の矢線601が、この際のデータの流れを示
す。次に、このデータを受信したCPU11〜1nは、各々に
接続されたDISC21〜2n内のカレントデータを更新すると
共に端末管理テーブルを参照し、自CPUの「担当CCU」を
介して、データ表示中端末（例えば、「Ｘ社の株価現
値」なるオンラインデータなら、「Ｘ社株価」を表示中
の端末）の画面を更新する。第１図（ｂ）の矢線602
は、CCU41がCPU11の「担当CCU」であって、そのうち端
末511のみが同該データ表示中であった場合の、CPU11か
ら先のデータの流れを示す。また、CPU12の「担当CCU」
に接続している端末にデータが表示されていない場合
の、CPU12から先のデータの流れを矢線603で示す。 （２）自動更新対象データ項目を登録する手順を第１図
（ｃ）に従い説明する。端末521が新たな項目名を入力
すると、この電文はCCU42を介し、このCCUを担当中のCP
U（ここでは11とする）へ送信される。これを受信したC
PU11は、電文に従い自内の端末管理テーブルを更新した
後、電文を伝送媒体３へブロードキャストする。これを
受信した他CPU11〜1nは、入力元端末521が可担当端末で
あれば自内の端末管理テーブルを更新する。そうでなけ
れば電文は捨てる。ここで、端末521を可担当端末とす
るCPUは11,12の２つであったとして、その時の登録電文
の流れを矢線604で示す。 （３）カレント情報問合わせの手順を第１図（ｄ）によ
り説明する。例として、CCU41がCPU11の「担当CCU」で
あり、端末511からカレント情報問合わせ行なった場合
について述べる。端末511から入力された電文はCCU41を
介して、CPU11に受信される。CPU11は、該この電文がカ
レント情報の問合わせであると判断した時、DISK21の内
容により応答画面を編集し、これをCCU41を介して端末5
11へ出力する。この時の問合せ電文の流れを矢線605
で、応答画面の流れを606で示す。 （４）ヒストリ情報問合わせ時の手順を第１図（ｃ）に
より説明する。例として、CCU4mを担当CCUとするCPUが1
nで、端末5m1からヒストリ情報問合わせを行なった場合
について述べる。入力された問合わせ電文は、CCU4mを
介してCPU1mに受信される。ここで、この電文がヒスト
リ情報の問合わせであると判断すると、CPU1nはこの電
文をCPU10へ送信する。この電文を受信したCPU10は、DI
SC20の内容を参照して応答画面を編集し、これをCPU1n
へ送信する。最後に、応答画面を受信したCPU1nは、CCU
4mを介し端末5m1へ出力される。この時の問合せ電文の
流れを矢線607、応答画面の流れを矢線608で示す。 3.構成制御 以下、CPU11〜1nに障害が生じた時の構成制御機能に
ついて述べる。以下、簡単のためｎ＝4,m＝８として説
明するが、その前にいくつか用語とテーブルを定義す
る。 可担当CCUであって専用CCUでないCCUを、「バックア
ップCCU」と呼ぶ。各CPUに対応する専用CCU、バックア
ップCCUの割り当ては、どのCCUにも、このCCUを自CPUの
専用CCUとするCPUが１つあり、また、このCCUを自CPUの
バックアップCCUとするCPUが１つ以上あるように構成さ
れているとする。例えば第５図の通りとする。この情報
を納めておくテーブルを「CCU割り当てテーブル」と称
し、各CPU内で持つものとする。ただし、このテーブル
を全て持つ必要はなく、各CPUは自CPUに対応する行をも
てば十分である。 上記CCU割り当てテーブルの他に、各CPUは全CPUがど
のCCUに接続されているか（すなわち担当している
か）、を表わす、「CCU接続テーブル」なるテーブルを
保持する。第６図に、その形式の一例を示す。なお、図
にあるB_EXPとはバス＝エクスパンダの略で、各CPUに実
装され、CCUとの接続を行なうデバイスである。本実施
例では３個までとしたが、可担当CCUの数（本例なら４
つ）を越えない数ならそれより大でもよい。なお同図で
「０」とあるのは、CPUのB_EXPが接続をしていないこと
を意味する。 また、各CPUは、全CPUのi/0状態、例えばディスク装
置（FX/D）、B_EXPなどの正常・異常を格納する「i/0状
態テーブル」を持つ。第７図にそのフォーマットの一例
を示す。なお、他のi/0の情報は略した。 4.構成制御ソフト構成と動作 本システムにおける構成制御のソフト管理は、データ
駆動的に行なわれる。すなわち、各CPUがネットワーク
へ出力するデータには、その内容種別を示す内容コード
を付し、メッセージとして伝送媒体３へブロードキャス
トする。そして、各CPU11〜1nがこのメッセージを内容
コードにより判別し、メッセージ中データが自内のプロ
グラム実行に必要であるなら取り込んで処理を行ない、
必要ないなら取り込まない。本プロトコルの詳細につい
ては、例えば、特開昭57−146361号公報，特開昭62−42
260号公報が参照できる。 次に、CPU内の、構成制御に関わる３つのプログラム
モジュールについて説明する。これらは、各CPUを通し
て共通である。 （１）i/0状態検知モジュール 本モジュールは、CCUへの接続を制御するサブシステ
ム（以下接続制御と称する。図示はしない。）または、
後述する診断モジュールにより、CCU接続テーブル、ま
たはi/0状態テーブル上自CPUに対応する行の情報が更新
された時に限り、両テーブルの自CPUに対応する情報を
「i/0情報メッセージ」としてネットワークへ送出す
る。第８図に、このメッセージのフォーマット例を示
す。CC1は内容コード、SAは送信者であるCPUidコード
（以下、P1〜P4とする。）B_EXP1〜B_EXP3は、自CPUのi
/0状態である。なお、全情報でなく、どこがどのように
更新されたか、という情報のみ乗せてもよい。また、前
述のように更新時のみメッセージ出力するには例えば、
モジュール自身を定周期で起動し、２つのテーブルの内
容が前回起動時の値と比較して変化があった時のみメッ
セージを出力することにすればよい。あるいは、更新動
作を行なった他モジュールが起動してもよい。本実施例
では前者をとるものとする。 （２）i/0診断モジュール 本モジュールは、（１）で示したモジュールの出力メ
ッセージにより起動され、そのメッセージの内容に基き
テーブルを更新し、障害発生時にはメッセージを出力す
る。以下、本モジュールの動作について、第３図（ａ）
のフローに従い説明する。 まず受信したメッセージが自CPUからのものであるな
ら（ステップ001）、何も行なわずに終わる。もし他CPU
からのメッセージであれば、このメッセージの内容と、
CCU接続テーブル上のメッセージ送信CPU（以下送信者と
称する）と対応する行とを比較し、いかなる変化が生じ
たかを判定する（ステップ002）。そしてその変化が、
送信者の今まで空いていたB_EXPに新しいCCUが接続され
たということであるならば（ステップ003）そのようにC
CU接続テーブルの該当する行を更新する（ステップ00
4）。そして、特に、該当CCUが自CPUが担当していたも
のであれば（ステップ005）、CCU接続テーブルの自CPU
に対応する行に書かれたCCU番号を０クリアする（ステ
ップ006）。これを以下、仮想切り離して称する。ま
た、メッセージの示す変化が、送信者がCCUを切り離し
た、ということであれば（ステップ007）、その通りにC
CU接続テーブルを更新する（ステップ008）。また、ス
テップ003,007いずれの条件も満たさなければ、本メッ
セージは不合理なものとしてそのまま処理を終える。次
に、i/0状態テーブルとメッセージ内容を比較し、i/0に
障害が発生したならば（ステップ009）、メッセージ内
容によるi/0状態テーブル更新の後発生障害の内容と、C
PUに接続されているCCU番号（いずれも受信メッセージ
より得られる）を付した「障害情報メッセージ」を送出
する（ステップ010）。第９図に、そのフォーマット例
を示す。CC2は内容コード、SAは自CPU番号、ENOは障害
の発生したCPUid,ECは障害内容（ディスク障害，バス＝
エクスパンダ障害など）、B_EXP1〜３はこの障害CPUの
接続CCU番号である。さらに、MY_EXP1〜３は、自CPUの
接続CCU番号である。 なお、本メッセージのデータを利用するのは自CPU内
のモジュールのみなので、本メッセージはネットワーク
へ送出する必要はなく、この該データを用いる自CPU内
モジュールにデータを渡し、起動するだけでもよい。 （３）構成管理モジュール 本モジュールは、障害情報メッセージにより起動され
る。その動作を以下、第３図（ｂ）のフローに従い説明
する。 まず、メッセージの送信者が自CPUでないなら（ステ
ップ011）、何も行なわない。なお、障害情報メッセー
ジをネットワークに送出していないなら、ステップ011
は不要である。もし自CPUであるなら、メッセージ内容
によりバックアップされるべきCCU（対象CCU）を決定す
る（ステップ012）。例えばCPUのディスク障害で全サー
ビスが不能であれば、メッセージ上B_EXP1〜３に書かれ
たCCU全てが対象CCUである。また、バス＝エクスパンダ
障害なら、該当するバス＝エクスパンダで接続されたCC
Uのみが対象CCUである。 次に、CCU割り当てテーブルを参照して、対象CCUが自
CPUの可担当であり、かつ接続可能（すなわちバス＝エ
クスパンダが空いている。）かどうかをチェックする
（ステップ013）。もしそうであれば、接続制御を起動
し、CCUを接続する（ステップ014）。そして、その接続
が成功したならば、この時接続制御は、CCU接続テーブ
ルの、自CPUに対応する一行のみ更新する。すなわち、C
CU接続テーブル全体で重複するCCUが現われることを許
す。 5.診断動作の例 最後に、第１図（ｅ），（ｆ）により、CPU11（P1）
のバス＝エクスパンダ２番に障害が生じた時を例にと
り、ｎ＝4,m＝８として診断動作を説明する。 初期状態においてCCU42はCPU11に接続され、このCPU
からのサービスを受けている矢線609はその接続を示
す。障害が生じると、まず、P1のi/0状態検知モジュー
ルが検知情報を送出する（第１図（ｅ）矢線610）。P2
〜P4のi/0診断モジュールがこれを受信し、障害が発生
したという診断結果を各々メッセージとして送出する
（第１図（ｆ）矢線611）。次にP2〜P4の構成管理モジ
ュールは、各々自CPUの送出した診断メッセージにより
起動し、対象CCUがP1のB_EXP2に接続中のCCU、即ち42で
あることを知る。そしてこの場合はCPUP2のみが、該CCU
は接続可能と判断し、接続する。矢線612はCPU（P2）に
よる接続動作を、矢線613はその結果生じた接続関係を
示す。 以下この結果が各CPUのCCU接続テーブルに反映される
手順を第10図に従い述べる。まずP1,P2,P3（P4）の接続
テーブルは当初記号801〜803の通りである。接続時P2の
テーブルは記号804のようになり、この時送出されるi/0
情報メッセージの接続CCU情報及びその流れは、記号805
で示される。 次に、検知メッセージを受信したP1,P3,P4の診断モジ
ュールは、CCU接続テーブルを更新する。特に、P1はCCU
42の仮想切り離しも行なう。記号806はP1における更新
後のCCU接続テーブル、807はP3,P4における更新後の同
テーブルである。 仮想切り離しを行なったP1は、再びi/0情報メッセー
ジを送出する。その内容と流れは記号808の通りであ
る。このメッセージを受けて、P2〜P4は各々、P1と同じ
内容に更新される（記号809,810）。なお、もしCCU42を
バックアップCCUとするCPUが２つ以上あっても、先に述
べたようにCCUへの接続は後着優先ゆえ、後に接続した
状態が有効となり、テーブルもそのように更新される。 6.第１の実施例の効果 以上説明したように本実施例では、カレントデータを
蓄積し、端末へ表示する画面を管理する機能を複数のプ
ロセサに分散し、かつ各々を共通伝送媒体に接続したの
で、端末やオンライン情報量の増加など、システム規模
の増加に柔軟に対応し、ホスト計算機及びTHをオンライ
ンで拡張することができるという効果を奏する。またこ
れら複数のプロセサにおける構成制御については、各CP
UがどのCCUと接続しているか、i/0の状態がどうかにつ
いての情報を一計算機または共通メモリ上で管理するの
でなく、ネットワーク上へブロードキャストし、各CPU
がメッセージを独自に収集し診断することとしたので、
部分障害によって診断機能が失なわれることがなく、各
CPUのi/0状態の診断が確実に行なわれるという効果があ
る。また、CCUへの接続を後着優先とし、他CPUが処理引
き継ぎのためにCCUを接続する前に、障害CPUの例のリザ
ーブをチェックする必要をなくしたため、各CPU間で複
雑なACKのやりとりを行なったら、同期をとる必要など
がなく、CCUへのサービスのバックアップを容易に３種
以上にすることができるという効果がある。 7.その他の実施例 （１）第２の実施例 上記第１の実施例では、自i/0の変化時のみ「i/0情報
メッセージ」を出力することとしていた。これに対し、
変化のあるなしに関わらず、定期的でメッセージを送出
することとしてもよい。その場合機能が変化するのは
「i/0状態検知モジュール」のみであり、他のモジュー
ルには変更はない。この第２の実施例によれば、第１の
実施例における効果の他、周期的に送出されるi/0情報
メッセージを生存信号として、他CPUの完全停止まで含
めた障害を診断することができる、という効果がある。
なお、この生死判定機能については、第６の実施例にて
詳述する。 （２）第３の実施例 また、第１の実施例または第２の実施例においては、
各CPUが送出したメッセージの送出順序通りに受信可能
であるとは限らないこと、すなわちメッセージの追い越
しが起こり得ることを考慮していない。これを解決する
ための一手段として送信時に各CPUが、i/0情報メッセー
ジに通し番号・送信時刻等の情報を付加することが考え
られる。以下、これを第３の実施例として述べる。 まず、各CPUは「通番テーブル」を保持する。第11図
に、このテーブルのフォーマットと内容の例を示す。シ
ステム立ち上げ時の初期値は、全CPUの行について０で
ある。また、「i/0情報メッセージ」は第12図の通りで
ある。第１の実施例との相異点は、送信時に通番MCが付
けられることのみである。以下、第１の実施例との相異
点について述べる。 i/0状態検知モジュールの相異点は、送信前に通番テ
ーブルの、自CPUに対応する行の値を１加算すること、
及びその結果の通番をメッセージに付加すること、の２
点である。 i/0診断モジュールの相異点は、ステップ001（第３図
（ａ））において送信者が自CPUでないことをチェック
した後、メッセージの通番を通番テーブルと比較するこ
とである。そして、メッセージの通番が、通番テーブル
上の、送信者に対応する行に記された番号より大である
時に限り、この通番テーブルをメッセージの通番で更新
し、ステップ002へ進む。そうでなければ、処理を終わ
る。 構成管理モジュールには、相異点はない。 この第３の実施例によれば、第１の実施例での効果に
加え、例えば1CPUで連続してi/0状態変化が生じ、第１
の状態変化に基くメッセージの方が、第２の状態変化に
基くメッセージより後に、他CPUに受信されたとして
も、前者により後者の情報が取り消されることはない。
すなわち、追い越し発生による誤診断を防止できる、と
いう効果を奏する。 第３の実施例における通番は、各CPUの内部時計に基
く時刻であってもよい。この場合、「通番テーブル」は
「送信時刻テーブル」という名称に変わるが、それ以外
の変更はない。なお、この「送信時刻」とは、あくまで
送信者の内部時計に基くものであり、診断を行なうCPU
の内部時計には無関係である。 （３）第４の実施例 前記第1,第2,第３の実施例においては、i/0情報メッ
セージを送出するモジュールと、受信するモジュールの
更新するテーブルは同じであった。これに対し、送出す
る側の参照するテーブルを別に設けてもよい。すなわ
ち、i/0状態テーブル及び、CCU接続テーブルの、自CPU
に対応する行に相当するテーブルを別に設けてもよい。
本実施例によれば、i/0診断モジュールにおいてメッセ
ージの送信者チェックを行なう必要がなくなり、動作が
単純になるという効果がある。 （４）第５の実施例（システム拡張時） 以上の実施例では、CPUの数はｎ個で固定としてい
た。しかし、本発明の考え方はCPU、およびCCUをオンラ
インでアドオンする場合にも有効である。以下その手順
について、第５の実施例として説明する。第１図（ｇ）
は、ｎ＋１番目のCPU（Pn＋１）とｍ＋１番目のCCU4m＋
１を接続した所である。ただし、CPU00,DISC等は省略し
てある。この時、Pn＋１を立ち上げる前に、物理的に接
続したCCUの番号が何であるかを補助記憶部に記録して
おく必要がある。この例では、Pn＋１はCCU4m−1,4m,4m
＋１と接続可能であり、そのうち専用CCUは4m＋１であ
る。また、CCU4m＋１をバックアップするCPUはPnと仮定
する。 システム拡張の手順は以下の通りである。まずCCUPn
内の割り当てテーブルに、バックアップCCUとしてCCU4m
＋１を登録し、かつCCU4m＋１と物理的につなぐ。な
お、CPU1mのバス・エクスパンダ及びCCUの通信ポートに
は、未使用のわくがあるものとすることは言うまでもな
い。この時必要なら、CPUPnは停止しても、サービスの
連続性は損なわない。次にCPUPm＋１を立ち上げると、
このCPUは、専用CCUへ接続し、自身の構成情報（自CPU
番号，自接続中CCU番号等）をネットワークへブロード
キャストする。第１図（ｇ）の矢線614は、構成情報で
ある。それを受信した他CPUは、これをきっかけに自内
の構成情報をブロードキャストする。この情報を受信す
ることによりCPU（Pn＋１）はシステムの全体構成を知
り、以後は必要あれば前述の構成制御を行なう。 前述の拡張によれば、CCU4m−1,4mに対するバックア
ップを行なうCPUが一つ増加し、CCUへのサービスの信頼
性がさらに高まる。また、端末も増加する。このように
本実施例においては、システムを停止することなく容易
に、多重度の向上やシステムの拡張が可能である、とい
う効果を奏する。 （５）第６の実施例 以上５つの実施例では、THと通信制御装置は１対１に
接続されており、切り替え可能な構成になっているもの
としていた。これに対し、全てのTH、および通信制御装
置が１つの共通伝送媒体に接続されていてもよい。以
下、そのような構成例について述べる。 第14図は、本発明の一実施例における分散処理システ
ムの構成図、第15図は本発明の一実施例におけるメッセ
ージフォーマットの説明図である。 本実施例の分散処理システムは、第14図のように、共
通伝送媒体200、伝送制御装置201〜207、ホスト計算機2
11,212、TH221,222、CCU231〜233、端末241〜246および
記憶装置251,252を備える。 このホスト計算機211,212は、端末241〜246に送出す
る情報の源となるデータを、システム外から常時受け取
って、共通伝送媒体200に送出する。 また、TH221,222は、ホスト計算機211,212が共通伝送
媒体200に送出したデータを入力し、記憶装置251,252の
記憶内容を利用して加工・編集処理を行い、共通伝送媒
体200を介してCCU231〜233へ送る。さらに、この情報は
端末241〜246へ出力される。 また、記憶装置251,252は、端末241〜246が何の情報
を要求しているかを記憶する。この記憶内容の更新は、
共通伝送媒体200を介して得た端末241〜246からのデー
タにより行う。 また、伝送制御装置201〜207は、ホスト計算機211,21
2、TH221,222、および端末制御装置231〜233が相互に共
通伝送媒体200を介して情報送受を行う際の制御を行
う。 また、本実施例におけるデータの送受信は、第14図に
示すように、データ（DATA）120の内容を示す内容コー
ド（CC）110を付加したデータを使用して行う。これに
より、各TH221,222、ホスト計算機211,212、および端末
制御装置231〜233は内容コード110を見て、そのデータ1
20の要否を判定することができる。 なお、内容コードを用いたデータ伝送方式について
は、例えば、特開昭57−146361号公報および特開昭62−
42260号公報において詳述されている。 次に、処理装置間の相互監視について述べる。 第13図は、本発明の一実施例における処理装置間の相
互監視処理を示すフローチャート、第16図は本発明の一
実施例における処理装置間の相互監視時のメッセージの
流れを示す説明図、第17図は本発明の一実施例における
相互監視テーブル例図である。 本実施例では、共通伝送媒体200を介してTH221〜223
間の相互監視を行う場合、各処理装置221〜223は、自装
置が稼働中である限り、稼働中であることを示す内容コ
ードを付けたデータ（以下生存信号と呼ぶ。）を所定の
時間間隔で送出する。なお、このデータ自体には、自処
理装置の識別子（第20図参照）を付ける。 例えば第16図のように、223に障害が起きた場合、TH2
21,222は、内容コードCC_Aとデータ自体A,Bから構成され
た生存信号401,402を送出するが、TH223は、このような
データを送出することはできない。 また、TH間の相互監視を行う場合の処理手順について
は、第13図のように示される。 すなわち、各THは、現在時刻を更新して（ステップ10
00）、他のTHからの生存信号到着時刻を、生存信号に記
述されたTH識別子と自TH内タイマ（図示せず）により、
第17図のような相互監視テーブル上に記憶する（ステッ
プ1001,1002）。 また、一定時間以上、生存信号が到着しない場合、そ
のTHには障害が発生したと判定する（ステップ1003,100
4）。 次に、THにおける端末へのサービス処理について述べ
る。 第18図は、本発明の一実施例における端末のデータ登
録時のメッセージの流れを示す説明図、第19図は本発明
の一実施例におけるホスト計算機から端末までのサービ
ス情報の流れを示す説明図、第20図は本発明の一実施例
における登録データの説明図、第21図は本発明の一実施
例におけるTHがホスト計算機からのサービス情報を多重
に設定した端末へ送る場合の説明図である。 本実施例において端末241へのサービスを行う場合、
第18図のように、端末241は、CCU231、伝送制御装置20
5、および共通伝送媒体200を介して、所望するサービス
を示す情報615をTH221,222に送り、TH221,222は、この
情報615を記憶装置251,252に登録する。 これに対し、第17図のように、処理装置221は、ホス
ト計算機211からの情報を加工・編集処理し、その登録
情報に従って端末241に送信する。 また、登録されるデータは第20図に示され、そのデー
タが登録されることを示す内容コードCC110と、登録コ
ード（S_CODE）801と、自端末の識別子（T_ID）802とか
ら構成される。従って、端末241は、内容コードCC110、
登録コード801、および自端末の識別子802とを付加し
て、第18図に示したデータ15を共通伝送媒体200に送出
する。 なお、識別子S_IDは常に必要ではなく、処理装置221,
222側で端末毎に、この登録情報を管理する機能を設け
る場合のみ必要となる。 また、この情報を受信する際、その内容コードは既知
であるとする。従って、登録コード（S_CODE）801と内
容コード110とは対応付けが可能であるとする。また、
これらのコードは同一のものを使用してもよい。 さらに、端末241からの登録データを受け取ったTH221
は、この登録データを記憶し、第16図のように、ホスト
計算機211からの情報616を受け取って、この登録データ
を基に情報を必要としている端末241の有無を確め、必
要と判断すると、加工・編集し、その情報617を共通伝
送媒体200に送出する。また、この送出情報617には、必
要に応じて登録データの端末識別子802を付加する。 また、端末241からデータ615を送出する際、識別子80
2を付けない場合には、登録データ801の情報を要求する
端末が存在するということのみがTH221,222で判断さ
れ、それに対応したサービス情報に内容コードが付加さ
れて共通伝送媒体200に送られる。この場合、第21図の
ように、ホスト計算機からの情報618を基にして、TH221
および222とも、必要とされる情報を加工・編集し、そ
れぞれが同じ内容のデータ（サービス情報）619,620を
多重に送出することもできる。 次に、本実施例におけるTHのバックアップについて述
べる。 第22図は、本発明の一実施例における構成テーブル例
図である。 本実施例では、各THが管理する端末を固定的に設定す
る場合、THが障害を起こすと、管理下の端末へのサービ
スが低下する。このため、THには、第22図のようにTH識
別子および管理端末識別子を格納した構成テーブルを備
え、TH間の相互監視により記述した結果を用い、相互バ
ックアップを行う。 まず、管理下端末の認識については、次に示すよう
に、（ｉ）管理する端末が固定されている場合と、（i
i）端末に変更があった場合における認識がある。 （ｉ）管理する端末が固定されている場合、事前に構
成が固定してあり、各THの構成テーブルを見て、各THが
どの端末を管理するかを認識する。 また、（ii）端末に変更があった場合には、加入や離
脱等の変更を行ったTHが、その変更情報を共通伝送媒体
に送出し、他の各THが受け取って更新する。この場合の
認識方法については、構成が固定されている場合と同様
に行う。 また、バックアップについては、障害を検知したTH
は、管理下の端末を認識し、その端末に対する情報送出
を行う。なお、その端末に対する登録データは共通伝送
媒体より登録時に取り込む。 次に、本実施例におけるTHの並行稼働について述べ
る。 本実施例では、TH毎に端末割り当てを行わず、登録終
了したコードに対して全てのTHが情報サービスを行う。
その結果、共通伝送媒体には、多重のデータが流れる可
能性がある。多重に流れてきたデータの処理は受け側の
CCUで行う。 受け側のCCUは （ｉ）受信した多重データをそのまま端末へ送信する。 （ii）一定時間待って多重データを収集しその中の一つ
を端末へ送信する。 （iii）THがデータ送信時に該データ送信元アドレスを
付加しておき、端末処理装置が受信時にアドレス毎に端
末への送信可否を判定するというような受け側ロジック
により処理する。 次に、CCUにおける端末への情報出力について述べ
る。 本実施例では、CCUは、内容コードを見て必要と判断
したデータを取り込み、端末へ出力する。この場合の情
報出力には、（ｉ）全端末報告と（ii）特定端末出力と
がある。 この（ｉ）全端末報告については、上記データをCCU
に直接接続された端末の全てに出力する。 また（ii）特定端末出力については、そのデータ内に
端末識別子が付加されている場合、その識別子に対応す
る端末が、自CCUに接続されているか否かを判定し、接
続されている場合には、その端末にのみ情報を出力す
る。 以上述べたように第６の実施例によれば、第１の実施
例に述べた効果の他、CCUの数をもオンラインで容易に
増減し、端末数を増大できる、という効果を奏する。 （６）第７の実施例 上記第６の実施例におけるTH間の相互監視は生存信号
を一定周期で送るものと仮定していた。しかしながら、
必ずしもそうでない場合にも本発明は有効である。以下
これを第７の実施例として説明する。なお、監視機能は
処理装置の種類（ホスト,THなど）には無関係ゆえ、以
下では単に処理装置、またはCPUと称する。 各CPU（以下d1〜d4の４つとする）間の生死監視は、
２つのプログラムR,Sにより実現されている。 Ｓの機能は、一定周期で起動し前述の生存信号を送出
することである。Ｒの機能は、生存信号受信をきっかけ
として起動し、他処理装置の生死診断を行なうことであ
る。以下、その方法について述べる。 まず、モジュールＲの参照する監視情報テーブルの形
式と、システム立ち上げ時の初期状態を、第23図に示
す。なお、ハイフンの入っている項が不定値であり、
「受信間隔カウンタ」が０であることの他は、システム
作成時に自由に決めてよい。本例では、しきい値を４と
おく。「しきい値」「受信間隔カウンタ」「前回受信間
隔」なる呼称は、後に述べる役割のゆえにつけられてい
る。 生存信号受信時のＲの動作は、第26図の処理フローに
従い次の通りである。生存信号の送信者が自CPUであれ
ば、Ｒは監視情報テーブル上の、受信間隔カウンタ（た
だし自CPUの分を除く。）を１加算する。例えば、自CPU
＝２番（d2）なら、第５図のテーブルで第１行１列,3行
１列,4行１列の成分を１加算する。（ステップ1006,100
7）この時、各行についてしきい値を超えた受信間隔カ
ウンタ（以下カウンタと呼ぶ。）があるか否かを見て、
もしあれば、監視情報テーブル上該当するCPUの生死状
態を「生」から「死」とする。不定値であれば、何もし
ない。（ステップ1008,1009）第24図は自CPUを２番とし
て、この時のテーブル更新の様子の一例を示したもので
ある。そして、生死状態に変化があれば、端末へアラー
ム出力すると共に、第25図に示すような内容・フォーマ
ットを持つ変化情報メッセージを必要なだけ送信する。
第６図の例なら、２つ必要である。（ステップ1010〜10
11） また、送信者が自CPUでなく、かつ監視情報テーブル
上該当CPUが「死」であったなら、その情報を「死」か
ら「生」へと更新し、受信間隔カウンタを０リセットす
る。また、変化情報アラーム及びメッセージを出力す
る。（ステップ1006,1012,1013,1014,1010,1011）一
方、送信者が自CPUでなく、かつ監視情報テーブル上該
当CPUが「生」であったなら、後に述べる「しきい値調
節」の後、受信間隔カウンタを０リセットし、処理を終
了する（ステップ1006,1012,1015,1016） 「しきい値調節」の手順は第26図のフロー図に示すよ
うに、次の通りである。送信CPU＃ｉ（di）の受信間隔
カウンタと前回受信間隔を比較し、前者の方が後者より
ｍ以上（ｍ＞０）大きいならば、CPU＃ｉのしきい値を1
UPする。（ステップ1017,1018,1019）逆に前者の方が後
者よりｍ以上小さいなら、CPU＃ｉ（di）のしきい値を1
DOWNする。（ステップ1017,1018,1021）そしてどの場合
でも、最後に前回受信間隔を受信間隔カウンタの値で更
新する（ステップ1020）ここで、ｍはシステム構成時に
定めた定数であるが、稼動途中で変えてもよい。第28図
にしきい値を高くした場合のテーブル更新の例を、第29
図にしきい値を低くした場合のテーブル更新の例を示
す。ただし、自CPU番号は２、送信者CPU番号は第28図で
１、第29図で３、ｍ＝２とする。 実際に第28図で示すようなテーブル更新が起きるの
は、次のような場合である。すなわち、ホスト計算機3
1,32からのデータ量が増加するなどの原因によりネット
ワーク負荷が増大し、従来ｐ秒周期で到着していたCPUd
1の生存信号が3p秒前後の周期で到着するようになった
場合である。平常時、受信間隔カウンタの値は０から２
にしかならないが、この時カウンタは３という値をとっ
ている。このため前回受信間隔１と比べて２増加し、そ
の結果しきい値が４から５へと増加した。この結果、更
に負荷が増大して、周期4p秒をわずかに越えることがあ
っても、CPUd2はCPUd1の状態を「死」と誤認することは
ない。ただし、この更新によりCPUd1が真に障害を起こ
した場合、その検知時間は4p秒でなく5p秒となる。 また、実際に図29に示すようなテーブル更新が起きる
のは、次のような場合である。即ち、CPUd3またはネッ
トワークの負荷が減少し、それまで3p秒前後の周期でCP
Ud2に到着していたCPUd3の生存信号が、もと通りｐ秒周
期で到着するようになった場合である。第29図での更新
と同様の手順に従いしきい値が４から３へ減少したた
め、この後CPUd3が障害を起こし生存信号が停止した場
合、その検知時間は4p秒から3p秒へ減少し、より速やか
に障害検知が行なわれる。 最後に新たなCPUを付加した場合の動作について、説
明する。当該CPUの番号＝５とし、このCPUの監視情報テ
ーブルの初期値に、第５図と同じとする。また、ネット
ワークに接続され、立ち上げると、直ちにd5の生存信号
は送信されるものとする。この時の、他CPU内のモジュ
ールＲの動作は次の通りである。CPUd5からの生存信号
が、既にテーブルに登録済みのCPUd1〜d4のいずれでも
ないとわかると、Ｒは監視情報テーブルの末尾に、新た
な一行を付加し、第29図のようにする（本図は、d2のテ
ーブル）。このためには、あらかじめ監視情報テーブル
用のメモリ領域を、CPU拡張の場合まで考慮して大きく
しておく必要がある。以後は、前述の通りの動作を行な
えばよい。CPUd5のモジュールＲでは、上述のようなテ
ーブル拡張の必要はなく、通常の動作を行なうのみであ
る。 なお、上記実施例においては、他CPUからの生存信号
受信間隔を、自CPUの生存信号の受信間隔を基準として
測定しているが、その他にも方法は考えられる。例え
ば、モジュールＲをOSにより一定周期でタイマ起動さ
せ、タイマ起動された時に上記実施例における「自CPU
生存信号受信時」の処理を行ない、生存信号受信時には
上記実施例における「他CPU生存信号受信時」の処理を
行なうとしてもよい。 本実施例によれば、ネットワーク負荷の増大により生
存信号受信間隔の変動が生じても、生存中処理装置を障
害と誤認することがない生死監視が実現できる、という
効果を奏する。 （７）第８の実施例 上記第７の実施例においては、生存信号の送信周期は
各CPU毎に一定と仮定していた。しかしながら、必ずし
もそうである必要はない。生存信号に、現時点での生存
信号送出周期に関する情報を付加する場合が考えられ
る。この場合の生存信号のフォーマットは第31図の通り
であり、モジュールＲにおける処理フローは、第７の実
施例と同様であるが、「しきい値調節」の部分が一部異
なる。以下、同相異部分について説明する。 第32図は、本実施例での監視情報テーブルである。し
きい値調整の手続きは以下の通り、自CPUの生存信号送
出周期（またはタイマー起動周期）をq msecとして、受
信した生存信号に付加された送信周期がr msecならば、 （〔 〕はガウス記号を新たなしきい値とする。 本実施例によれば、第７の実施例における効果の他、
あるCPUを計画的に停止して、それに基く構成制御動作
が生じないようにしたい場合、このCPUの生存信号の送
信周期ｒを十分大とするだけでよい、という効果を奏す
る。また、定周期で送信されるとは限らないので、次の
３条件を満たすメッセージであれば何でも生存信号とし
て用いられる、という効果を奏する。 条件１）送信CPU番号が付加されていること ２）どのCPUも共通に送信する種類のメッセージで
あること ３）次に送信するまでの時間が送信CPUにとって明
らかであること （８）第９の実施例 以上８つの実施例では、情報の集配信システムにおい
て、（１）ホスト計算機とTHが共通伝送媒体に接続され
ている場合、（２）ホスト計算機,TH,CCUの３つが全て
共通伝送媒体に接続されている場合、の２種類の構成上
で論じた。しかしながら、本発明は他の構成でも有効で
ある。例えば、ホスト計算機とTHは１対１の回線で接続
されており、THとCCUが共通伝送媒体に接続されてい
る、という構成であってもよい。第33図に、そのシステ
ム構成を示す。この構成と第２のシステム構成との相異
は、ホスト計算機が共通伝送媒体に接続されておらず、
THと１対１回線で結ばれている点のみである。そのシス
テム動作については、第６の実施例にて説明したものと
同様である。 本実施例によれば、第６の実施例の効果に合わせて、
ホスト計算機の収集するオンライン情報が直接共通伝送
媒体上に流れないため、共通伝送媒体上の通信負荷が低
減されるという効果を奏する。 （９）第10の実施例 第１の実施例，第６の実施例にて説明した動作は、他
の構成でも可能である。例えば、第34,35図に示したよ
うな構成であっても第１の実施例と同じ動作は可能であ
るし、また共通伝送媒体が３つに分離され、かつTHとCC
U双方の機能を持った計算機を含む、第36図のような構
成であっても、第６の実施例と同じ動作が可能である。
これらの実施例では、前記第1,第６の実施例の効果に加
え、伝送媒体に流れるデータ量が減少するという効果を
奏する。

【発明の効果】

本システムは以上説明したように構成されているの
で、以下に説明するような効果を奏する。 システム外部からの情報を収集する計算機と、収集し
た情報を処理・配信する計算機と、端末への入出力を制
御する通信制御装置の各要素が、共通伝送媒体に接続さ
れているので、これら要素はそのシステム全体における
役割の違いに関わりなく、自由に通信が可能である。即
ち階層による通信の制限がない。また、通信は、内容コ
ードを付したデータのブロードキャストと、各要素の内
容コードを用いた選択受信によるので、各要素は自身の
機能の引き継ぎ先を意識することなく、各要素間での情
報生成の肩代わりや冗長化が可能である。

【図面の簡単な説明】

第１図（ａ）〜（ｇ）は本発明の一実施例におけるシス
テム構成図および各業務におけるデータの流れを示す
図、第２図は従来のシステム構成例、第３図（ａ），
（ｂ）は構成制御の動作フロー図、第４図は端末管理テ
ーブルのフォーマット例を示す図、第５図はCCU割り当
てテーブルのフォーマット例を示す図、第６図はCCU接
続テーブルのフォーマット例を示す図、第７図はi/0状
態テーブルのフォーマット例を示す図、第８図はi/0情
報メッセージのフォーマット例を示す図、第９図は障害
情報メッセージのフォーマット例を示す図、第10図はCC
U接続切替え時、各処理装置のCCU接続テーブルがメッセ
ージにより更新される様子を表わす図、第11図は通番テ
ーブルのフォーマット例を示す図、第12図は通番がつい
た場合のi/0の情報メッセージのフォーマット例を示す
図、第13図は処理装置間の生死監視方法の処理フロー
図、第14図は第６の実施例におけるシステム構成図、第
15図はメッセージフォーマットを示す図、第16図は処理
装置間の相互監視時のメッセージフローを示す図、第17
図は相互監視テーブルのフォーマット例を示す図、第18
図は第６の実施例における端末データ登録時のデータの
流れを示す図、第19図は第６の実施例におけるホスト計
算機から端末までのサービス情報の流れを示す図、第20
図は第６の実施例における登録データの例を示す図、第
21図は処理装置がホスト計算機からのサービス情報を多
重に設定した端末へ送る場合の説明図、第22図は構成テ
ーブルのフォーマット例を示す図、第23図は第７の実施
例における監視情報テーブルのフォーマット例を示す
図、第24図は監視情報テーブルが、自処理装置の生存信
号受信をきっかけにして修正される様子を示す図、第25
図は状態変化メッセージのフォーマット例を示す図、第
26図，第27図は第７の実施例における相互監視機能の処
理フロー図、第28図，第29図は他処理装置の生存信号受
信時におけるテーブル更新の例を示す図、第30図は新た
な処理装置をシステムに加えた際の監視情報テーブルを
示す図、第31図は、第８の実施例における生存信号のフ
ォーマット例を示す図、第32図は第８の実施例における
監視情報テーブルを示す図、第33図は第９の実施例にお
けるシステム構成例を示す図、第34〜36図は第10の実施
例におけるシステム構成例を示す図である。

【記号の説明】

01〜02,C1〜C2……ホスト計算機、11〜1n,d1,d2……タ
ーミナルハンドラ（TH）、21〜2n,1,2……記憶装置、3,
4,5……共通伝送媒体、または完全グラフ構造の１対１
接続によるネットワーク、41〜4m,e1〜e3……CCU、511
〜5mk,f1〜f6……端末、601〜620……データの流れ、CC
……内容コード、SA……送信者の識別子、B_EXP……バ
スエキスパンダ、IOSTS……i/0状態、MY_EXP……自THの
バスエキスパンダ、801〜810……診断テーブル更新の流
れ、ａ……第２のシステム構成例での共通伝送媒体、b1
〜b5……伝送制御装置。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 森 欣司 神奈川県川崎市麻生区王禅寺1099番地 株式会社日立製作所システム開発研究所 内 (72)発明者 笠嶋 広和 茨城県日立市大みか町５丁目２番１号 株式会社日立製作所大みか工場内 (72)発明者 篠本 学 茨城県日立市大みか町５丁目２番１号 株式会社日立製作所大みか工場内 (72)発明者 鈴木 靖雄 神奈川県川崎市麻生区王禅寺1099番地 株式会社日立製作所システム開発研究所 内 (72)発明者 織茂 昌之 神奈川県川崎市麻生区王禅寺1099番地 株式会社日立製作所システム開発研究所 内 (56)参考文献 特開 昭60−3052（ＪＰ，Ａ)

Claims (11)

(57)【特許請求の範囲】
1. 【請求項１】外部から情報を入力する１つまたは複数の
   インタフェイス装置としての第１の装置群と、該第１の
   装置群から入力されたデータを加工する１つまたは複数
   の演算処理装置としての第２の装置群と、該第２の装置
   群が加工した結果を配信する１つまたは複数の出力装置
   としての第３の装置群とからなるシステムであって、上
   記第１、第２および第３の装置群がそれぞれ行なう処理
   は、逐次的に進める１つ、または複数の部分処理からな
   る情報集配信システムにおいて、どの装置も１つまたは
   複数の部分処理を行ない、またどの部分処理を行なう装
   置も１つまたは複数あって（以下、同一の部分処理を行
   なう装置の集まりを層と称する。）各装置は、自身の部
   分処理に必要なデータを、自身が属するのと別のある層
   に属する１つまたは複数の装置より受け取り（以下この
   層を、１つ上の層と称する。）部分処理を行ない、該部
   分処理結果を、自身の属する層とも、上記１つ上の層と
   も異なるある層（以下この層を１つ下の層と称する。）
   に属する１つまたは複数の装置に送り、また、同一層内
   に属する装置間、また異なる層に属する装置間は伝送媒
   体にて結ばれており、該伝送媒体上には各装置の関連情
   報が流れ、この情報を収集することによりどの装置であ
   っても、伝送媒体を介して他装置の障害状態を診断し、
   該障害装置の部分処理を代行することが可能であり、あ
   る層に属する装置から、該装置の１つ上の層に属する１
   つまたは複数の装置に情報が渡された時、該情報は１つ
   または複数の装置により処理されて、もとの装置へ返さ
   れるか、または更に１つ上の層に属する１つまたは複数
   の計算機へ渡されることを特徴とする情報集配信システ
   ム。
2. 【請求項２】前記伝送媒体が共通伝送媒体であって、該
   共通伝送媒体に送出するデータには、該データの内容種
   別を示す内容コードを付してあり、共通伝送媒体に接続
   された各装置は、該コードによって該データを受信する
   か否か決定することを特徴とする請求項１に記載の情報
   集配信システム。
3. 【請求項３】共通伝送媒体に接続された各計算機は、上
   記内容コードを付した内容コードデータの到着時刻を計
   測する手段と、該到着時刻を記憶する手段と、該内容コ
   ードデータが所定時間間隔で到着したか否かを判定する
   手段とを備え、上記各装置は該内容コードデータを所定
   の時間間隔で常時送出して、該内容コードデータがしき
   い値としての所定の時間以内に到着しない場合には、該
   計算機に障害が発生したと判断することを特徴とする請
   求項２に記載の情報集配信システム。
4. 【請求項４】情報の処理、及び配信を行なうターミナル
   ハンドラ、及び通信制御装置が共通伝送媒体に接続され
   ている場合、各ターミナルハンドラ毎に管理する端末を
   設定し、各ターミナルハンドラは管理下の端末に対する
   情報を送出し、該ターミナルハンドラが自身以外のター
   ミナルハンドラの障害を検知した場合に、該障害ターミ
   ナルハンドラが管理すべき端末に対する情報をも送出す
   ることを特徴とする請求項２に記載の情報集配信システ
   ム。
5. 【請求項５】上記通信制御装置は、上記ターミナルハン
   ドラから送出された情報の要否を判定して、必要と判定
   した情報のみを自装置へ接続された端末へ出力すること
   を特徴とする請求項３に記載の情報集配信システム。
6. 【請求項６】上記ターミナルハンドラが管理する端末
   を、複数のターミナルハンドラ間で多重に設定し、上記
   通信制御装置は上記複数のターミナルハンドラから多重
   に送出された情報の要否を判定し、必要と判定した情報
   のみを端末へ出力することを特徴とする請求項４に記載
   の情報集配信システム。
7. 【請求項７】上記端末が要求する情報の種類を上記ター
   ミナルハンドラへ登録する場合、該端末は登録するデー
   タに上記内容コードと、該端末を示す識別子を付加して
   共通伝送媒体へ送出し、該登録データを受信したターミ
   ナルハンドラは該端末識別子毎に登録することを特徴と
   する請求項４に記載の情報集配信システム。
8. 【請求項８】上記ターミナルハンドラが登録データに基
   き、編集・加工したデータを送出する場合、該登録デー
   タの端末識別子を付加して送出し、上記通信制御装置は
   自身に接続された端末の識別子と、内容コードにより取
   り込んだデータ内の端末識別子とにより、出力先の端末
   を識別してデータを出力することを特徴とする請求項４
   に記載の情報集配信システム。
9. 【請求項９】共通伝送媒体に接続されている各装置は、
   共通伝送媒体を介さず直接に自身と結ばれた他計算機・
   i/0との接続状態、または自内の状態を含むi/0状態の情
   報を共通伝送媒体に送出し、同該情報を収集し、システ
   ムの状態を診断し、他装置の障害を検知した場合に、該
   障害により欠けた機能を代行するように構成したことを
   特徴とする請求項１に記載の情報集配信システム。
10. 【請求項１０】前記しきい値を、内容コードデータの到
    着時間間隔に応じて変化させることを特徴とする請求項
    ３に記載の情報集配信システム。
11. 【請求項１１】前記i/0状態に送信順を示す通し番号を
    付しておくことを特徴とする請求項９に記載の情報集配
    信システム。