JPH05204890A - 陸上車両に使用する多重ノード分布データ処理システム - Google Patents

Abstract

(57)【要約】 【目的】 分布データ処理システムにおいて、自動車の
ごとき陸上車両の種々の異なる分布データを効率よく処
理することを目的とする。 【構成】 本分布データ処理システムはセンサー、ユー
ザーＩ／Ｏ、データ処理装置および地理的データの大量
メモリを具えている。決定論的転送制御の後で単一（ユ
ニタリ）実体としてのみ処理でき、同時に転送を無状態
（ステートレス）に保持するシステム呼びあるいは原始
情報の限定されたライブラリを用いて、分布実時間オペ
レーティングシステムは局所化処理パワーおよび／また
はデバイス、センサー、Ｉ／Ｏおよび／またはファイル
データを共用する複数のプロセスの共存走行を許容して
いる。

Description

【発明の詳細な説明】

【０００１】

【技術分野】本発明は自動車のような陸上車両（surfac
e vehicle ）の分布データ処理（distributed data pro
cessing ）に関連する。現在の自動車情報系（car info
rmation system）は全体として車両の動作に有用な種々
の異なるデータカテゴリを管理しており、それらは、 − 実際の位置とは無関係な車両の内部状態（internal
status ）、 − 地理的位置と経路に関する情報、 − 入力作用と出力表現により表されたような運転手と
乗客に対面する情報、 のようなものである。

【０００２】

【背景技術】アクセス可能な地理的データ、経路計画と
誘導（route planning and guiding）、道路状態の通知
（road-status signalization ）、外部データ通信、自
動車内の娯楽制御（in-car entertainment control）、
電話等々のその他種々のものを蓄積する車両のエンジン
と環境の制御に対して過度の（plethora）部分的解決法
が実現されてきたし、また今後実現されるであろう。こ
れらのいくつかは独立デバイス（stand-alone device）
に変換できるが、しかしそれらの間の相互作用はその有
用性を増すであろう。その２つの例は次のようなもので
あろう。まず第１に、低い燃料レベルはそれ自身最適で
ある予め選ばれた経路でない給油所（fuel station）か
らそれるよう経路を誘導できる。第２に、入って来た自
動車電話の呼びは任意の他の音声再生を非活性化でき
る。その他多くのものはユーザー機能の改善、車両のよ
り良い物理的機能性、あるいはデータ処理能力の増大を
実行可能にしよう。バイナリ安全ベルト検知器（binary
safety-belt sensor ）対精巧な経路計画計算機（soph
isticated route planner computer）のように種々の部
分的解決法が異なる製造業者により実現され、異なる状
態あるいは実現であり、組み込み知能（built-in intel
ligence ）の広く異なるレベルを有することで１つの問
題が提示され、そのすべての問題は拡張されたソフトウ
エア展開時間（lengthening software development tim
e ）と熟練したシステムアナリストの払底（scarcity）
により一層悪化されている。

【０００３】それ故、とりわけ、本発明は以下の主要目
標の若干あるいはそのすべてを許容する分布実時間計算
機オペレーティングシステムの実現を考慮している。

【０００４】− オペレーティングシステムのシステム
ソフトウエアは容易な保守を許容すべきである。それは
簡単であり、かつ僅かな小さい単一機能ユニットから構
築されるべきである。

【０００５】− ソフトウエアはさらに精巧化（sophis
ticated ）あるいは品質低下（downgra ded）のいずれ
かができるように異なるハードウエアに対して移植可能
（portable）でなければならない。特にこのシステムは
通信の２つの異なるレベルを許容しよう。第１に、低い
レベルはオペレータの１つ以上の有限の集合（オン、オ
フ、読み取りステータス［read status ］のような）の
伝送を意味し、それに基づいて標的（target）は常に反
作用（reaction）の１つ以上の有限の集合と反作用す
る。高いレベルでは、宛先（destination ）は局所オペ
レーティングシステムにより制御されるノードあるいは
ステーションに固有なある種の非決定行為（non-determ
inistic behaviour ）のある段階を示す。この場合、反
作用の集合は有限である必要はない。さらに、回答は標
的ノードにより実施すべき種々の仕事（task）あるいは
プロセスにより遅延された非決定的なもの（要求ノード
［requesting node ］により見られたような）であり得
る。

【０００６】− ソフトウエアはその種々の構成ソフト
ウエアモジュールの間、および現在あるいは将来の応用
ソフトウエアに関して明確に規定されたインターフェー
スを有すべきである。このようにして、任意のソフトウ
エアモジュールは残りの部分を破壊（havoc ）すること
なく改善できる。

【０００７】− 主要要素は、以前のOS-9から、アイオ
ア州のデス・モイネス（DES Moines）のマイクロウエア
（Microware ）により導かれたCD-RTOS （Compact Disc
Real Time Operating System ）、あるいは比較できる
能力を持つ他のシステムのような有力な特性と容易にア
クセス可能な構造を有する各局所機能を制御するオペレ
ーティングシステムであるべきである。特に、このオペ
レーティングシステムは地形等に属する光ディスク蓄積
情報を含みかつそれを表すCD-I（CD-Interactive）サブ
システムで設計されている。

【０００８】− 相互接続回線網は決定論的メッセージ
トラヒックを許容すべきで、すなわち通常の環境の下で
データの送信と受信との間の時間遅れは予め規定できる
最悪ケースの最大値（prespecifiable worst case maxi
mum ）を有すべきであり、それはもちろんノードの数の
ような大域系特性（global system property）に依存で
きる。前にも説明したように、アークネット（ARCNET）
標準バスプロトコルは有利な実現を許容している。これ
は米国のニューヨークのホウパージ（Hauppage）の標準
マイクロシステム協会（Standard Microsystems Corpor
ation ）により発展され、かつ1988年コンポーネントカ
タログ（Components Catalog）の頁207 −222 に刊行さ
れたローカルエリアネットワーク制御装置 COM90 C26で
具現されている。

【０００９】− オペレーティングシステムと任意の応
用ソフトウエアモジュールとの間のインターフェースは
標準化すべきである。このようにして、応用ソフトウエ
アの数、特性および性能の変更は制御システムの変更を
必要としない。さらに、システムハードウエアの変更は
システムソフトウエアのただ１つの必要な変更である
が、しかし応用ソフトウエアあるいはノード特定ソフト
ウエア（node-specific software）ではない。

【００１０】

【発明の開示】従って、本発明はＣ言語で書かれた局所
モジュールに属するソフトウエアを認識し、かつ局所ハ
ードウエアおよび／またはデータベース項目を直接制御
するよう高レベル言語記述を２進コードに変換するアセ
ンブラ手段に加えて、バスプロトコルにより指示された
適当な形式に、基本量（primitives）の限られた集合の
種々の要素を変換する局所ライブラリを備えている。こ
のことはバスレベルの任意の変化（ハードウエアあるい
はソフトウエアの）がライブラリの修正のみを必要と
し、かつ第１ノードの任意の変化がバスのアクセス機能
の修正を必要とするが、しかしソフトウエアは任意の第
２ノードに決して存在しないということを許容する。そ
のような制限された集合として、本発明は以下の９つ
の、開放（open）、閉成（close ）、読み取り（rea
d）、書き込み（write ）、探索（seek）、ゲットスタ
ット（getstat ）、セットスタット（setstat ）、信号
（signal）、創成（creste）（＝創成プロセス）を十分
（そしてしばしば必然的）と見ている。これらの９つ
は、エム・ジェー・ロッキンド（M. J. Rochkind）、高
級ユニックスプログラミング（Advanced Unix Programm
ing ）、プレンティスホール社（Prentice-Hall In
c.）、イングルウッド・クリフス（Englewood Cliff
s）、ニューヨーク、米国、1985年の54の許容システム
呼び（System Call ）のサブセットとしていわゆるユニ
ックス環境のシステム呼びとして記述された。特に、ゲ
ットスタット／セットスタットペアーはOS-9で既に発展
されたオクタル（octl）システム呼びからの特殊な誘導
である。上の書籍のインデクスは今後説明されるすべて
のシステム呼びをリストしている。アークネット実現に
対して、このライプラリは適当なシステム呼びへのノー
ド発生実体（node-generated entity ）を変換すること
のみが必要である。

【００１１】その１つの態様によると、本発明の目的は
陸上車両の多重ノード分布データ処理システムを備える
ことであり、該システムは、 ａ１．上記の車両に関する物理量を検知する検知手段
（sensing means ）、 ａ２．物理的に区分されかつ固定地理的データ要素（fi
xed-geographical data）を蓄積する蓄積ノード手段、 ａ３．ユーザー方針データ（user policy data）を発生
するために上記の物理特性と上記の地理的データを処理
するデータ処理ノード手段、 ａ４．上記の処理を制御するために任意のデータ処理ノ
ードを進行させ、かつユーザーに対して上記のユーザー
方針データを制御して進行する要求データ（request da
ta）を受信するユーザーＩ／Ｏノード手段、 ａ５．ユーザー信号に対して上記のユーザーＩ／Ｏノー
ド手段をインターフェースするユーザー入力／出力手
段、および ａ６．上記のノード手段を相互接続する回線網手段であ
って、少なくとも１つのノードが上記の検知手段にイン
ターフェースし、かつ少なくとも１つのノードが応用ソ
フトウエアを実施するもの、を具え、上記のシステムが
以下の規定（provision ）、すなわち ｂ１．メッセージ可能なシステム呼びあるいは基本量の
ライブラリであって、開放、閉成、読み取り、書き込
み、探索、ゲットスタット、セットスタット、信号、創
成を具えるもの、 ｂ２．予め規定された最大時間間隔内で基本量の任意の
回線網転送を実行する決定論的回線網制御システム（de
terministic network control system）、 ｂ３．単一実体（unitary entity）としてその完全転送
に従うメッセージ処理を専ら許容するメッセージ処理組
織（message processing organization ）、 ｂ４．無状態（stateless ）でバスにわたる各ノード間
の任意の論述（discourse ）を保持する状態維持制御装
置（state-maintaining control ）、 ｂ５．局所処理パワーおよび／またはデバイスおよび／
または検知器、Ｉ／Ｏおよび／またはファイルデータを
共用する複数の各処理の共存送行（coexistent runnin
g）を許容する分布実時間オペレーティングシステム（d
istributed real-time operating system）、 を有している。

【００１２】例えば、物理量はエンジン温度、ドア閉
成、地磁気の磁界方向、他の車両の存在、車両速度、そ
の他多くのものに関連している。主メモリはRAM 、ディ
スク、テープ等として１つ以上のノードであってもよ
い。輻輳あるいは局所的雷雨のような非固定データの補
充は有利であり、データ処理は１つ以上のノードで実行
可能である。ユーザーＩ／Ｏはプッシュボタン、音声Ｉ
／Ｏ、可視表示、ある種の活性体（activator ）の阻止
を具えてもよい。回線網は１つ以上のバスを具えてもよ
いが、しかしポイントツーポイント接続や他の構成体も
また想定できる。ある種のノードは点ａ２，ａ３....の
間で１つ以上の機能を持つことができる。ライブラリは
このシステムがそれらの基本量の発生、受信および回答
を許容することを意味している。

【００１３】上記による決定論的トラヒック制御システ
ムは種々のやり方で実現できる。非常に簡単なやり方は
予期された各メッセージ資源ステーションに一様に循環
するシーケンスの１つの時間スライスを割り当てること
である。さらに効果的ないくらかのものは循環優先順位
付け（cyclic prioritizing ）であり、従って要求を送
出しようと欲しない任意の資源はほぼ瞬時にバイパスさ
れる。また、優先番号間の仲裁（arbitration ）は、も
し所定の時間の後でその優先権を上昇するような低い優
先権資源に転送機能を保証する若干の特徴が存在するな
ら、それは許容可能な解決法である。これらの制御シス
テムは計算機回線網技術の標準知識に示されている。

【００１４】単位キャラクタ（unitary character ）
は、もしその転送が完成するならメッセージが処理され
るだけであることを意味している。反対の場合、任意の
処理動作は中断できる。というのは、回線網の介在衝突
（intervening collision ）あるいはメッセージの発生
ステーション（origin station）の除去さえも入力情報
を永久的にし、かつ多分回復できないほど（irreparabl
y ）不完全にするからである。現在のシステムでは、そ
のような除去あるいは付加は他のノードに誤動作（malf
unctioning）を生じないであろう。

【００１５】さらに、２つのステーション間の論述（di
scourse ）は無状態（stateless ）である。このことは
転送中のメツセージがそのメツセージに関してその状態
を変化しないことを意味している。資源ノードはメツセ
ージに属する任意の動作を停止し、かつ宛先ノードはそ
れが完全に受信された場合に単位メツセージに反応して
動作できるだけである。その利点はもしもメツセージが
標準バスフレーム内で適合しないなら顕著であり、それ
は第１フレームの送信と最後のものの受信との間の無視
できない遅延を与え得る。

【００１６】回線網のキャラクタの多重処理を通して、
受信信号あるいは構成されたデバイス出力は独立かつ同
時に処理される。問題となっているデータファイルは蓄
積手段に存在し、あるいは各プロセッサの１つに局所的
に存在する。通常、物理的特性は温度、点火（ignitio
n）、燃料レベル、外部条件に関連しよう。地理的デー
タは記録構成され、かつ地図の一組づつの構成（parcel
-wise organization）で配向される。１つ以上のデータ
プロセッサが存在する。メモリは個別ノードであるか、
あるいはプロセッサに直接付属できる。ユーザーＩ／Ｏ
は種々の複雑なレベルで音響的なもの、LED 、CRT であ
り得る。

【００１７】上記のシステムがさらに信号に基づいて通
信の相互処理を許容することは有利である。また処理の
レベルに基づいて、これは協働レベルを増大する。

【００１８】上記の蓄積ノードでは大容量蓄積媒体（ma
ss storage medium ）の逆転可能な連結を許容すること
が有利である。光学的および他の大容量蓄積媒体（好ま
しくはディスク型の）は大容量蓄積要件の魅力的な解決
法を表している。

【００１９】上記のータ処理システムは少なくとも１つ
のノードが異なる各プロトコルの少なくとも２つのバス
にインターフェースしている複数バスシステムとして構
成されることが有利である。このことは自動車内管理系
（in-car management system）を与える容易なインター
フェースを許容する。一般に、任意のサーバープロセス
はせいぜい１つのキューを有している。

【００２０】上記のデータ処理システムはそのサーバー
プロセスのキューの最大アクセスの深さを予め規定する
任意のサーバープロセスに関するキュー管理を有してい
ることが有利である。このことは柔軟なキュー管理を許
容する。

【００２１】上記のデータ処理システムは新しいサーバ
ープロセスを創成する必要性を自動的に検出するサーバ
ー割り付け機構を有していることが有利である。このこ
とは各ユーザープロセス間の競争を円滑に解決する。

【００２２】上記のデータ処理システムは第１メモリノ
ードと、上記の第１メモリノードにおけるメモリの少な
くとも一部分だけ上記の第１メモリノードから異なって
いる第２ノードで局所的に写像（mapping ）する写像手
段とを有していることが有利である。このことは容易な
メモリアクセスを許容する。

【００２３】本発明はまた前述の説明に従う多重ノード
データ処理システムとして使用するデータ処理システム
にも関連している。このシステムは固有のデータ処理か
ら、すなわちハードウエアとソフトウエアからなってい
るが、しかし車両機能により明記されているものの固有
のデータ処理により明記されない特定の検知手段とユー
ザーＩ／Ｏを有していない。

【００２４】本発明の別の利点は従属クレームに列挙さ
れている。

【００２５】本発明を図面に示されている好ましい実施
例によって今後説明する。

【００２６】

【実施例】今後、第１に一般的ハードウエアサブシステ
ムに関して、第２にその一般ソフトウエアサブシステム
に関して好ましい実施例が開示される。今後、本発明の
種々の有利な特徴が詳細に強調される。さて、図１は本
発明による分布データ処理システムと対象指向応用イン
ターフェース（object-oriented application interfac
e ）を線図で示している。説明のために、まずOSI 通信
モデルの７層、すなわち物理層、リンク層、ネットワー
ク層、トランスポート層、セッション層、プレゼンテー
ション層、および応用層が以下のように簡単に概観され
ている。すなわち − 媒体にわたってビットストリームを転送する物理
層、 − 直接接続されたシステムの間にデータを転送するデ
ータリンク層、 − 中間システムを通して経路設定しかつ中継するネッ
トワーク層、 − 通信プロセス間の対話（dialogue）を構成しかつ同
期するセッション層、 − 標準化されたやり方で情報の提示（presentation）
を与えるプレゼンテーション層、 − ユーザーに最も密接したインターフェースとサービ
スあるいは応用プログラムからなり、かつ実際のネット
ワークサービスをユーザーに与える応用層、 である。

【００２７】これらのすべての層はバスあるいは回線網
で実際に起こる現象の記述を表しているが、しかし適当
な構成レベルから見ている（コンピュータデザイン、19
88年２月15日の頁511 を注意）。

【００２８】さて、本発明によると、分布計算機システ
ムはハードウエアの物理的位置を知らないが、同じやり
方ですべての周辺装置にアクセスする。そのような周辺
装置がユーザーインターフェースノードあるいはCDプレ
ーヤ上に配置されているかどうかは航行盤（navigation
board）上の他の周辺装置とは何らの差異はない。

【００２９】図１において、各円は関連プロセスで実施
されるユーザー応用ソフトウエアを表している。この図
では、２つのそのような応用ソフトウエア手順あるいは
モジュール24, 26が示されている。機能的に、それらは
破線のラインペアーとして示された応用インターフェー
ス20を介して相互通信できる。水平破線ラインペアー22
は任意のシステムプロセスに任意の応用プロセスをイン
ターフェースするシステムインターフェースを表してい
る。もちろん物理的には、ユーザーソフトウエアモジュ
ール24, 26はこのシステムを介して回線網あるいはバス
機能と通信する。さらに矩形はシステムソフトウエアモ
ジュールを表している。第１に、ブロック28は応用ソフ
トウエアモジュールによる、あるいはそれに向かうすべ
ての要求の取扱（handling）を表している。回線網にイ
ンターフェースされた物理的に局所化された各ステーシ
ョンあるいはノードは局所オペレーティングシステム3
0,32, 34を有している。局所ステーションの１つに直接
（すなわち回線網を介さずに）通信する局所化された各
デバイスあるいはモジュールは関連ソフトウエアを表す
各ブロック36, 38, 40, 42, 44により描かれている。

【００３０】図１のハードウエア対応物としての図２は
車両データ処理システムの物理モジュール間の協働動作
を示している。３つの主要なステーションが存在し、す
なわちブロック50はその光学的記録を持つCD-Iあるいは
CD-ROMを表している。CD-ROMや同様なシステムは広く市
販されている。光学機械的レベルではCD-Iは同一で、そ
れはエス・ロピーケット（S. Ropiequet）等の「CD-RO
M」、光学出版（Optical publishing）、マイクロソフ
ト印刷所（Microsoft Press ）、レッドモンド（Redmon
d ）、ワシントン州、1987年、頁162 ／163 に記載され
ているように画像の蓄積のために種々の基準が規定され
ている。そのような記録は地理的および位相的（topolo
gical ）マップデータ、プログラムデータ、娯楽デー
タ、データベース情報、音声データ等を含むことができ
る。ブロック52はいわゆる航法計算機（NAV ：navigati
on computer ）である。それは回線網いるいはバスから
直接にあるいはそれを介してセンサーセット54からのセ
ンシング信号を受信する。これは絶対値コンパス（abso
lute compass）あるいは差分コンパス（differential c
ompass）、車両の車輪に連結された走行距離計（odomet
er）、道路内信号符号発生器用センサー（sensor for i
n-road signal codo generator）、温度、燃料レベル、
誤動作通知（malfunction signalization ）等に関連で
きる。要素56は人間−機械インターフェースモジュール
である。それは可視表示要素58および／または音声再生
要素60にユーザー方針データ（user policy data）を出
力する。そのような方針データは種々のキャラクタを有
していてもよい。それらは単一方針を示し、かつそのよ
うに助言（advisory）、勧告（exhortative ）、指示
（directing ）、警告（warning ）、あるいは非難情報
（invective information ）を表してもよい。

【００３１】代案として、それらはメニュー形式のよう
な選択であってもよい。なおさらに、それらは自動車運
転者が選択できる車両に開放されている種々のパーキン
グ空間を持つ地図の表示によるように開放選択を行う勧
誘を表している。さらに、インターフェースモジュール
（MMI ）56は入力要素（INP ）62からユーザー要求入力
を受信する。入力要素62は物理的にはキー、キーボー
ド、マウス、ソフトキー表示、あるいはその他の適当な
ものであってよい。ユーザー個人は入力要求信号を入力
できる。これはある種の地理的位置、情報要求、選択器
信号、肯定応答（acknowledge ）等をアクセスする要求
を表すことができる。示されていないあるケースでは、
イグニションあるいは照明制御のような車両を直接制御
する物理的な運転者出力を有することができる。ユーザ
ー入力信号の制御の下で、人間−機械インターフェース
モジュールは要素58, 60による表現を選択的に制御する
ことができる。また、それは例えばそのような要求信号
の許容性あるいは実行可能性のチェックのように航法計
算機52にユーザー要求信号の転送を選択的に制御でき
る。航法計算機52はライン64上のユーザー要求信号ある
いは他の信号、ライン66上の地図データ、およびライン
68上のセンサーデータを受信する。それは車両の実際の
位置やユーザー入力宛先位置あるいは宛先表示の制御の
下で車両の最適経路を計画できる。最適化は最小旅行時
間、最小旅行距離、あるいは他の判断規準であってよ
い。航法計算機52はまた現在の影像のスケーリング・回
転、街路名あるいは給油ステーションのような詳細な強
調地図（highlighting map）によって種々の異なる道路
の特定の表示を制御できる。それはブランキング、窓明
け（windowing ）あるいはカーソル化（cursoring ）に
より他の情報を挿入できる。それはユーザーが１つ以上
の項目を選択するメニューに従って、あるいはそれを提
示する作用を計算できる。

【００３２】さて、図２の表現は大いに概略的であり、
64, 65, 66, 67, 68のような主要データストリームのみ
が示されている。下に説明されるように、これらのスト
リームは１つ以上のバスに点毎に（point-to-point）割
り当てるかあるいは写像することができる。さらに、あ
る種の機能が人間インターフェースとセンサーのような
１つ以上のノードに写像できる。代案として、異なる機
能ブロックの一部分は単一ノードに共に写像できる。こ
の選択は利用可能なハードウエアおよび／または所要の
機能性レベルの方向で開発者に開放されている。

【００３３】さて、本発明の具現の１つの結果は、ハー
ドウエアの付加（あるいは除去）の標準的やり方が提案
されているが、すべてのハードウエアデバイスがほぼ一
様なやり方で応用ソフトウエアによりアクセスできると
いうことである。例えば、もし標準同期リンクがもっと
早い接続に変更されるなら、動作速度のみが改善される
が、しかしどんなジョブも別々に進行しないであろう。
システムのそのような変更は、直接影響されたものより
も任意の別のステーションの動作が危険になることな
く、システムの動作（進行）の間に影響されさえしよ
う。もちろん、もし第１ステーションが別のステーショ
ンに所属するハードウエアあるいはソフトウエアを必要
とするなら、第２ステーションの取り外しは問題となっ
ているジョブが実施できなくなるが、しかし原理的に実
施の可能性を与えると、この実施は実現されよう。回線
網にわたって機能をそのようにアクセスする装置の特徴
は「リソース共有（resource sharing）」と呼ばれてい
る。同じノードあるいは別のノードにせよ、各ノードの
各プロセスから任意の他のプロセスへのすべての相互プ
ロセス通信機構は、通信動作がそこに含まれた２つのノ
ードの局所動作システムにより支持されるなら使用でき
る。もしそうなら、転送機構は実時間能力で有利な分布
動作システムを有効に生成する。実際に、ユーザープロ
セス（ユーザープログラムの表現）は所定のノードに分
岐（fork）（あるいは写像）できるが、しかし識別情報
（identification information）の送出により任意の他
のプロセスあるいはデバイスにアクセスできる。この解
決法はプロセッサのタイプに敏感ではない。局所オペレ
ーティングシステム30, 32, 34は前に引用されたOS-9/C
D-RTOSシステムにより実現できる。

【００３４】機能性 システム層は次のような多数の一般機能、 − プロセス創成、ここでそのように創成された各プロ
セスは創成プロセスの固有の通路および／または環境で
あり、 − 信号、セマフォー信号（semaphore ）、パイプ、ス
トリームおよびパケットによる相互プロセス通信、 − ファイル動作、 − 標準CD-Iグラヒックスインターフェース、および − 好ましくは、それ自身では未知であるが図２の（示
されていない）共用メモリ、 を備えている。

【００３５】特に、後者（共用メモリ）は別のノードに
物理的に配置されるかあるいは別のノードに割り付けら
れるメモリを局所的に写像することを許容している。好
ましい実施例によると、メモリは存在しない空間に写像
される。そのアクセスはバスエラー信号を発生し、従っ
て局所的なトラップを発生しよう。それに基づいて、ト
ラップサービスルーチンにおいて、メモリの内容は所要
によりフェッチされるかあるいは書き込まれる。それ
故、この手順はバスエラー状態からの完全な回復を許容
するプロセスのみを支持している。この解決法はたとえ
直接的ではあるが、局所オペレーティングシステムが速
度および／またはシステム統一性の理由で問題の代案の
解決法を許容しない場合にのみ使用されることが好まし
い。

【００３６】別々に考えると、これらの種々の機能の１
つは他の既知のオペレーティングシステムに見いだされ
るが、しかし組合せは本システムをオペレーティングシ
ステムゲートウェイとして非常に適当にする。

【００３７】実例として、今後説明はCD-RTOS オペレー
ティングシステムに特定する。他のオペレーティングシ
ステムへの変換は直接的である。本発明は種々のユーザ
ーアクセス可能なステーションに対する製造業者により
規定できる一様ユーザーインターフェースを必要としな
い。本発明は全システムのレベルにその効果を有する
が、特定のユーザーインターフェースには影響しないス
テーション間通信の制御システムを提案する。

【００３８】さて、遠隔リソースのアクセスは局所リソ
ースのアクセスとして同じシステムインターフェースを
介して行われる。バデイスの名前と引き続くファイル規
定はアクセスが遠隔アクセスかあるいは局所アクセスか
どうかを決定するただ１つの手段である。CD-RTOS の下
で、識別子（identifier）表現の第１スラッシュ（slas
h ）に続く名前は選ばれた管理子（manager ）を決定す
る記述子（descriptor）を名付ける。識別子の残部の走
査は後者の管理子により行われる。一例として、もし任
意の遠隔サービスの名前がその前に /c0/ nodeid/ を有
するなら、-nodeid-はリソースが配置されているノード
の番号である。表示 -c0- はノードが接続されている回
線網に独自（unique）である。さて、各応用プログラム
は必要とする各機能の位置を知らなければならない。た
とえいくつかのリソースが一般に各ノード端末ラインで
利用可能なら（ram disk 等）、別の機能は特定のノー
ドに限定される。通常、デバイスは適当な時間に実名に
変換される論理名により識別される。遠隔プロセス創成
の場合には、インターフェースは標準機能と同等のまま
であるが、しかし分離子（separator ）（すなわちスラ
ッシュ）が使用されるべきで、かつノード識別子（-nod
eid-）は規定されなければならない。通信は実体、-sig
nals- 、-files- 、-pipes- 、および-packages- を使
用することにより以下のように実行される。信号はプロ
セスの間の基本事象情報（elementaryevent informatio
n）を伝える。一般情報キャラクタは２バイト語であ
る。情報信号の受信を必要とする各プロセスは信号ハン
ドラーを設定する。ファイルは開かれ、各ノード毎にア
クセスされる。ファイルシステムの識別子は残留ノード
識別子（residence node identification ）を具えてい
る。パイプは類別されないメッセージ（untyped messag
e ）を通信する２つ以上のプロセス間のチャネルであ
る。パケットはプロセス間で変数の共用に使用される。
各プロセスはパケットに連結できる。

【００３９】種々の協働的特徴 図３は種々のプロセス間の協働動作を概略的に例示して
いる。簡単のために、要求と回答のフローのみが示さ
れ、読み取り／書き込みデータフローは示されていな
い。この基本的ではあるが代表的システムにおいて、双
方ともブロックで表された２つの回線網、すなわちARC-
net 70とカーエリア回線網（CAN ：Car AreaNetwork）7
2が存在する。カーエリア回線網（CAN ）は主としてシ
ステムを通って伝送された非航法情報に専用されてい
る。このシステムは３つのノードを有し、各ノードは問
題となっているノードのプロセッサの管理子74, 76, 78
により象徴されている。各ノードは各回線網に対する個
別の回線網駆動装置（80, 82, 84, 86）を必要とし、一
方、中間ノードは双方の回線網に接続されている。さら
に、このシステムはユーザープロセス88, 90とサーバー
89, 92, 94, 96, 98を具えている。各回線網に対して、
各ノードはルートサーバー（root server ）を有してい
る。ユーザープロセスはその局所ルートサーバーをアク
セスする。ルートサーバーは必要によりサブサーバーを
創成しかつその後でそれにアクセスする。サブサーバー
の創成の後で、ユーザープロセスは引き続いて回線網を
介して直接そのようなサブサーバーにアクセスできる。
そのようなサブサーバーはその創成者（creator ）のデ
ータ環境を有している。ユーザープロセス88はその局所
管理子76に要求（REQ ）を送信し、かつそれから回答
（REP ）を受信する。

【００４０】いわゆる CAROS（CAR-Operating-System）
フレームに形式化されたメッセージは回線網プロトコル
に適応される適当な駆動装置（82, 84）と通信される。
メッセージが他の端末で駆動装置（80, 86）により受信
されると、後者はその内容からどのサーバーキュー（9
1, 100, 102, 106 ）で情報が送出すべきかを知るであ
ろう。各サーバーはそれ自身のキューから読み取り、か
つそこに蓄積された各指令を実施し、各メッセージが単
一の指令に限定されている。このことはサーバーに直接
先行している限り、キューからの別のコピーを必要とし
ないことを意味している。もし実施が失敗すると、これ
は原始プロセス（originator process）に通報される。
サーバーはその結果をそのノードの管理子に直接通報す
る。要求および回答メッセージは元来生起した要求に回
答を連結する参照情報を含んでいる。回答管理子は返答
を備え、かつそれを適当な駆動装置に送出する。駆動装
置はユーザープロセスへのデータの進行が取り扱われて
いる要求ノードに回答を送り戻す。管理子はいつトラン
ズアクションが終了するかを駆動装置により通知され、
かついつユーザープロセスが再び可能となるかを知る。

【００４１】上記に関して、今後サーバーの種々の態様
が説明される。第１に、プロセスが特定ノードに創成で
きる。備えられたシステムライブラリは特定ノードの配
置を注意し、これが局所あるいは遠隔であるかを決定
し、かつ適当なシステム呼びを実施する。

【００４２】もしプロセスが遠隔ノードに分岐されるな
ら、実在の子供（real child）として振る舞うようその
プロセスに十分な情報が与えられ、すなわち正しい通路
と環境を有し、その親（parent）のプロセス・アイディ
ー（process-id：pid ）を決定でき、かつ子供に信号を
送るために親により使用できるプロセス・アイディー
（pid ） を親に戻す。

【００４３】分岐プロセスは管理子への遠隔分岐システ
ム要求の以下の異なる実施状態により説明されよう。 （１）ユーザープロセスは遠隔ノードのプロセスを分岐
するために管理子に要求を送出する。ライブラリにおい
て、分岐すべきプロセスが遠隔ノードで進行するよう実
際に要求され、従って管理子が呼ばれることが決定され
る。ライブラリ呼びの第１作用は、ユーザープロセスの
すべての通路を自動的に継承し、その通路にデータをコ
ピーしかつそれからデータをコピーすること役立つ局所
的独立（local stand-alone ）サーバーを分岐すること
である。 （２）要求はアークネットを介して送出され、かつサー
ビスされる。遠隔ノードに送出されたメッセージはその
ノードのプロセス創成呼びに対応するOS９EXEC動作の実
行に必要なすべての情報を含んでいる。受信ルートサー
バーは子供を分岐する前に元の親プロセスのルートサー
バーを反映するそのＩ／Ｏをまず変化する。この瞬間か
ら、子供は継承されたＩ／Ｏと環境で走行する。 （３）子供は退出（exit）する。子供が走行を停止する
場合に、局所親（localparent）は信号によって通知さ
れる。これは何時子供が分岐されるかを規定する。遠隔
親プロセスのノードで独立サーバーに信号を送出するこ
とによりサーバーは反応し、子供の終了を通知する。独
立サーバーは順次親に通知し、かつ退出する。元の親に
より見られた信号は子供のノードアイディー（nodeid）
とプロセスアイディー（pid ）を反映する。このことは
遠隔分岐の場合に、子供の拡張されたプロセス・アイデ
ィーがプロセスの要求により見られることを意味してい
る。どんな支持プロセスも元の機構と干渉しない。

【００４４】サーバープロセスの相互プロセス通信の具
現に対して、各タイプの通信で個別メッセージは利用可
能である。

【００４５】信号は直接的な態様で取り扱われる。メッ
セージは以下のような情報、宛先プロセス・アイディ
ー、送出プロセスの信号値とプロセス・アイディーを含
んでいる。この最後の情報は厳密には必要ではないが、
しかし一層の強調（enhancement ）と容易なテバッギン
グを許容するのに非常に便利である。メッセージは各々
が最大長要件（maximum length requirement）に従う１
つ以上のフレームに適合できる。もしメッセージが単一
フレームに適合しないなら、第１フレームがメッセージ
の長さを表示する。さもなければ、必要な情報のみが送
出される。メッセージは宛先ノードのルートサーバーに
送出する管理子に送出される。サーバーはそれを特定プ
ロセスに送出する。

【００４６】ファイルＩ／Ｏは利用可能なたいていの通
信機構の基礎を形成する。それは次の３つの部分に分割
される。 − 通路の開放、 − 読み取り、書き込み、および探索（seek）動作であ
って、ここで探索（-seek-）は特定記録へのファイルポ
インターの設定を意味しており、 − 通路の閉成。

【００４７】開放（-open-）呼びはそれ自身のメッセー
ジを有している。メッセージはまず受信サーバーにより
分布されるべきである。順要求（forward request ）と
呼ばれた特殊関数がこれを行い、それは図４に関連して
説明される。

【００４８】割り付けられたサーバーに要求が到着した
後で、開放関数（-open- function）が実施される。サ
ーバープロセスは標準Ｉ／Ｏライブラリと連結され、こ
のようにして戻された値が規定される。この戻された通
路はサーバーアイディー（serverid）とノードアイディ
ーと結合され、かつ要求プロセスに戻される。

【００４９】読み取りおよび書き込み 読み取り、書き込みおよび探索動作は、どのノードとサ
ーバーに要求が発行されるべきかを反映する通路に向け
られる。送出ノードと受信ノードの双方の管理子はこの
ことを留意する。従って要求のどんな再経路決定も必要
ではない。要求は直ちに取り扱われ、バイトが送り返さ
れ、あるいはファイルに（あるいはデバイスに、この場
合新しい探索アドレスが使用される）書き込まれる。

【００５０】閉成（-close- ）は以下のように行われ
る。もし通路が存在するなら、通路は閉成される。局所
通路番号はサーバーのアレイから削除され、新しい通路
の空間を創成する。アレイは許容された開放ファイルの
標準最大番号に適応する。回線網トラヒックで使用され
た通路番号はこのアレイのインデクスである。通常、そ
の時のただ１つのプロセスのみが特定のサーバーを使用
できる。

【００５１】パイプ、ストリームおよびパケットはファ
イルＩ／Ｏと同様に取り扱われる。サーバーがプロセス
により請求されるから、多数の要求プロセスにより使用
された単一サーバーにより取り扱われた異なるパイプで
のデッドロックは回避される。これらの機能は相互プロ
セス通信に所属しているが、それらのインターフェース
のためにここで扱われている。

【００５２】図４は例えばファイルアクセス要求のよう
な要求へのサーバープロセスの割り付けを図式的に示し
ている。そのようなアクセスの第１部分は通路開放（op
en apath ）である。この呼びはそれ自身のメッセージ
を有している。それは受信サーバーによりまず分布され
る。割り付けの後で、機能が実施され、次にどのノード
とサーバーに要求が発出されるべきかを示す通路に読み
取りおよび／または書き込みが向けられる。送信側と受
信側双方の管理子はここでは活性である。最後に、閉成
（-close- ）作用が（もし存在するなら）通路を閉成す
る。さもなければ、エラー信号が戻される。この作用が
成功するかどうかは局所システムの走行時間ライブラリ
イ（run time library）により効率的に決定される。と
にかく、閉成において、通路番号はサーバーから削除さ
れる。さて、図４において、ノード識別子（nid ）と要
求プロセスのプロセス識別子（pid ）を含む特殊識別子
および例えば現在選択されたデータデイレクトリのよう
な特殊環境決定ラベル（particular environment-deter
mined label ）であるサーバー取扱のチェックにより、
要求のプロセスがサーバーの所有者であるかどうかをこ
の機能がまずチェックする（110 ）。この取扱はまたど
のプロセスが特殊データ環境の元の所有者であるかを示
す。特に、それは外部あるいは内部（domestic）チャネ
ル動作（chx/chd ）を示し、かつサーバーのアクセスに
使用される。

【００５３】そのようにして獲得された情報値はサーバ
ー記述記録（server description record ）に蓄積され
る。もしこの値が正しいなら、要求は適合できる（112
）。もしこの値が正しくないなら、不整合の種々の上
昇段階が存在しよう。まず（114 ）で、このサーバーに
所有者プロセスが存在するかどうかサーバーリストでチ
ェックされる。もしイエスなら、サーバーの要求はその
キューに入れられ、そしてサーバーがキューの問題とな
った項目に到達するまで未決定のままである。もしノウ
なら、実際のプロセス識別子とノード識別子が現行のサ
ーバーを参照するかどうかがチェックされる（118 ）。
もしイエスなら、取扱が見いだされるかどうかが検出さ
れる（120 ）。もしイエスなら、環境（ある種のプロセ
スパラメータ）がコピーされ、かつ要求が取扱われる
（122 ）。もしノウなら、要求が取扱われる（124 ）。
もしブロック118 で結果がネガティブなら、プロセス識
別子とノード識別子がサーバーリストの要求の送出器に
対応するかどうかチェックされる（126 ）。もしイエス
なら、それらは異なるサーバーに関連し、それ故、要求
は割り付けられ、すなわちは要求を入れる（put reques
t ）。もしノウなら、取扱が見いだされるかどうかがチ
ェックされる（130 ）。もしイエスなら、取扱が現行サ
ーバーに関連するかどうかがチェックされる（132 ）。
もしイエスなら、新しいサーバーが創成され（分岐さ
れ）、その親環境を継承する子供と要求は適合される
（134 ）。もしノウなら、要求は意図されたサーバーに
割り付けられる（136 ）。もしノウなら、取扱はブロッ
ク130 に見いだすことができ、空のサーバーが見いだす
ことができるかどうかがチェックされる（138 ）。もし
イエスなら、要求は問題となったサーバーに割り付けら
れる（140 ）。もしノウなら、現在のサーバーは分岐さ
れ（142 ）、要求はそこに割り当てられる。

【００５４】もしノード識別子とプロセス識別子が正し
いが、取扱がそうでないなら、このことは割り付けられ
た遠隔サーバーでプロセスが進行する古いスロットを新
しいプロセスが引き継ぐことを意味している。次に、サ
ーバーは新しいプロセスに再び割り付けられ、サーバー
リストは要求プロセスとして同じ取扱でサーバーに対し
て走査される。もしこのサーバーが見いだされるなら、
その取扱通路は現行サーバーにコピーされる。その欠点
は、以前の所有者の可能な子供がそのタイプの取扱をな
お有し、かつその障害通路（その元の環境パラメータは
もはや正しくない）の遠隔アクセスを請求しようと試み
よう。しかしこのリスクは小さい。逆の場合（取扱は正
しいが、識別子はそうでない）は、第１にサーバーリス
トが正しいプロセスアイディーとノードアイディーを持
つサーバーを走査するという最初のものに類似してい
る。もし見いだされたなら、制御は前と同様に転送され
る。もし見いだされなかったなら、新しいサーバーが分
岐され、その親サーバーから同じ通路を継承する。もし
取扱と識別子の双方が正しくないなら、これはエラー条
件を明らかに反映する。というのは、新しく生まれたプ
ロセスはルートサーバーと同一な取扱０を常に使用する
からである。従って、取扱は常に見いだされるべきであ
る。この場合、もし利用可能なら空のサーバーが割り付
けられ、さもなければ新しいサーバーが分岐される。一
般に、クライアントサーバーと要求ユーザープロセスは
異なるノードにある。

【００５５】システム仲裁機能 （system arbitrage facilities ） 分布動作システムは特定の標準Ｃライブラリ呼びを部分
的に取り替えるライブラリを具え、かついくつかのサー
バープロセスを具えている。このライブラリはサーバー
要求がローカルエリア回線網の遠隔ノードで実施すべき
かどうかをこの呼びから決定する。もしそうでないと、
標準Ｃライブラリ呼びが実施される。遠隔動作の場合
に、管理子は必要なパケットを構築し、かつこの情報へ
のポインターをアークネット駆動装置に通過させ、順次
これらのパケットを遠隔ホストに送出する。

【００５６】アークネットパケットは図５に示されたテ
ーブルへのポインターを通して管理子／駆動装置に伝え
られる。書き込み作用は完全なメッセージが送出される
まで休止され、これはメッセージが前に規定されたよう
に単一（unitary ）であることを意味している。

【００５７】矢印150 はアークネット管理子151 へのフ
レーム記述記録要求を表示し、一方、要求の取扱を設定
するステータス、通路探索およびフレーム記述子ポイン
ター（frame descriptor pointer）を規定する。記録は
フレーム番号表示154 、回答バイトの期待数を表示する
回答カウント表示（reply count indication）156 、回
答バッファ160 の現行アドレスを指示する回答ポインタ
ー158 、および１ヘッダーフレーム空間164 に関するカ
ウントとポインターの同様な対、零あるいはそれ以上の
後続フレーム空間166 、場合によっては矢印168 により
象徴的にアクセスされた別の空間を具えている。回答デ
ータは矢印170 に従ってアークネットにより提示されて
いる。ヘッダーフレームの構成は172 に示されている。
それは第１に、管理子を意図した多重バイト固定部分17
4 、サーバーを専ら意図した一連の個別の可変バイトを
伴う駆動装置あるいはサーバーである。

【００５８】３種類のサーバープロセスが存在する。す
なわち （１）通路専用サーバープロセス（path dedicated ser
ver processes ）（名前＝記述名＋プロセス［name＝de
scrname ＋ prc］）であって、ここで各プロセスは割り
付けられた専用サーバープロセスを有している。これら
のプロセスはルートサーバーにより創成され、かつ各々
はその関連ユーザープロセスの環境を持つサブサーバー
プロセスからなっている。 （２）システム呼び専用プロセス（system call dedica
ted processes ）。含まれた呼びは遠隔分枝と遠隔信号
である。これらのプロセスはまたルートサーバーにより
創成される。ルートサーバーそれ自身はまたこのタイプ
のものである。 （３）独立サーバープロセス（stand-alone server pro
cesses）。これらの作業は遠隔子供プロセス（remote c
hild process）を表している。その親プロセスと同じノ
ードに基づく場合にそれらは後者の完全な環境を継承す
る。それとは反対に、ルートサーバーは関連ユーザープ
ロセスの環境を有さないが、しかし故障環境（default
environment ）のみを有している。

【００５９】受信プロセス（専用の通路／システム呼
び）と独立サーバープロセスは回線網により充填される
キューを取り扱う。特定のメッセージへの１つ以上の割
り当てが上に記載されている。第１フレームはフレーム
中のメッセージの長さを常に通知する。第１フレームが
送出された後で、送出器がｘｏｎを受信する前に別の送
信は行われない。このようなやり方で、信号ｘｏｎ（送
信を進める）とｘｏｆｆ（送信を停止する）は転送を直
接的に制御する。

【００６０】図６は局所キューの構造を例示している。
このキューは固定長（36バイト）のメモリブロックを保
持するメモリプールからなっている。フリーリストアレ
イ180 はメモリ182 のフリーブロックを指示する。さら
に、レジスタ184 はキューの開始を指示し、一方、第２
レジスタ186 はキューのフリー部分の開始を指示する。
キューの各要素はその先行者（ｎｘｔ）の表示を含み、
もしそうでないなら−０−を含む。36バイトの標準フレ
ームサイズより長いＩＯ要求に対して、サーバープロセ
スは拡張空間188 へのメモリ割り付けを実施する。さ
て、キュー管理は２つの連続レベルで行われる。第１
に、小さいメッセージに対して、たいていの固定スロッ
トサイズが割り付けられる。特定メッセージが所望な
ら、関連固定サイズスロットは１つの拡張スロットに連
結される。前者（固定サイズスロット）は具現されたダ
イナミックに暗黙なｘｏｆｆプロトコルである。要求の
フェッチあるいは要求単位は多数の固定長スロットに表
現される連鎖の最大の深さまで完全に受信された要求に
基づいて行われる。特に、このことはキューから要求を
フェッチする応答時間の決定論的振る舞いを維持し、か
つ決定論的メッセージ転送を許容する。第２に、このこ
とは分布レベルのデータファイルとして種々のプログラ
ムモジュールのアクセスを許容する。

【００６１】上記は短いメッセージについて説明されて
いる。36バイトより長い任意のメッセージに対して、送
出器はそのmalloc（memory allocation ：メモリ割り付
け）が成功したというサーバープロセス通知からｘｏｎ
を待機しよう。自動的に送出器は拡張情報を転送しよ
う。成功した創成／開放呼びに基づいて戻されたプロセ
ス／通路識別子は図７に示されたような３つの個別フィ
ールド、すなわちサーバープロセスのプロセス識別子
（190 ）、宛先プロセスのノード識別子（192 ）、およ
び局所通路／プロセス識別子（194 ）を持つ長いワード
からなっている。要求識別子は短いワードとしての大き
さを持っている。それはアークネット駆動装置としての
み知られ、かつサーバープロセスにより透明に（transp
arently ）伝えられる。特に、ビット１は現在のフレー
ムが最後のものであるかどうか、あるいは１つ以上のフ
レームが後続するかどうかを表示している。ビット２は
これが第１フレームであるかどうか、あるいはそれが多
重フレームメッセージの後のフレームであるかどうかを
表示している。ビット３，４はそれが要求フレーム、回
答フレーム、あるいは制御フレームであるかかどうかを
表示している。（16ビットの）最後の12ビットは例えば
リンク識別子のような特定要求を識別する。

【００６２】キュー機能 今後基本キュー機能がリストされる。第１に、機能名が
リストされる。次にそれは識別子、動作およびパラメー
タにより規定され、一方、最後に簡単な説明が続く。 Crest queue(nslots) SRVRQUEP crest queue(nslots) int nslots； 記述：最初割り付けられた「nslots」によりキューを創
成する。 Del queue(qhdrp) int del queue(qhdrp)＊qhdrp SRVRQUEP qhdrp； 記述：通過したポインタにより規定されたキューを削除
する。退出する場合にサーバープロセスによる使用が意
図される。 Put queue(srvrid, reqhdrp) int put queue(srvrid, reqhdrp) uchar srvrid； REQ HEADER＊reqhdrp ； 記述：タイプREQ HEADERの記録をキューに挿入し、拡張
が必要かどうかをチェックし、もしそうならそれを受信
するために拡張キューを準備する。 Get queue(frmtp, reqhdrp, depth) int get queue(frmtp, reqhdrp, depth) SRVQUEP frmtp ； REQHDRP ＊reqhdrp ； int depth; 記述：キューから要求ヘッダーを探索する。完全に受信
された要求の第１「深さ（depth ）」キュー要素のみを
走査する。もしget queue が、拡張空間を必要とするそ
の要求ヘッダーが受信されるキューで要求を検出するな
ら、これは割り付けられ、かつｘｏｎは要求のソースに
送られる。 Put subframe(frmtp, reqid, framep, cnt, interleav
e) int put subframe(frmtp, reqid, framep, cnt, interl
eave） SRVRQUEP frmtp； short reqid ； unsigned char ＊framep； int cbt ；int interleave； 記述：スタティックシーケンシャルなポインターを使用
して、「framep」、「cnt 」、および「interleave」に
より規定された所与のデータから「reqid 」により識別
された要求に属する拡張空間を充填する。このポインタ
ーは駆動装置の汎用スタティックデータの一部分であ
る。インターリーブは所与のデータを保持するバッファ
の２つの連続バイトの間の空隙空間を記述する。

【００６３】形式 演算コード（Opcodes ）。各要求は特定演算を参照する
演算コードを有している。呼び（Calls ）。キュー通信
ライブラリイにより与えられた呼びは以下のようにリス
トされる。put queue ；put subframe；creat queue ；
del queue ；get queue ；creatrequidtbl ；creat req
id ；del reqid ；get reqid ；del reqidtbl。標準ヘ
ッダー（Standard header ）。すべての要求は以下のよ
うにリストされるこの情報を伴っている。すなわち、re
qid, comprising srcnid, destnid ；srvrid；および第
１フレームに対してreqsize 。要求id構造送出器。要求
（request ） id は例えば−reqid ；−reply buffer p
ointer；−prcid waiting process ；−reply count, a
ttributes のような受信機に関して送出器に個別に使用
されている。

【００６４】一般的に、３つの異なる種類のメッセージ
が存在し、それらは以下の通りである。 要求（request ）

【表１】 回答（reply ）：

【表２】 制御（control ）：

【表３】

【００６５】図８はキュー管理を説明するメモリ割り付
けの瞬時状態を描いている。最左端列210 はシステムレ
ベルの汎用スタティック蓄積を与える。このスタティッ
クキャラクタは任意のプロセスが必要な情報を配置でき
ることを意味している。スタティック蓄積において、項
目212 でlocreqidtblpが蓄積され、それは要求識別子と
テーブルバイト長ポインターが蓄積されているアドレス
である。さらに、212でlocreqidtblpはサーバーテーブ
ルバイト長ポインターが蓄積されているアドレスを表示
する。最後に、scrnidはソースノード識別子を与え、ro
otsrvid はルートサーバー識別子を与える。項目212 か
ら、各ポインターは示されたような別の領域を表示して
いる。領域214 において、要求識別子テーブル、reqidt
bl、第１フリーチャンク（free chunk）をリストし、次
に、示されたように連鎖されている別のフリーチャンク
をリストしている。その後で、第１要求スロットは発動
プロセス識別子（initiator process identifier）、回
答バッファポインター、残りのフリー位置のカウント、
および属性（attribute ）を含んでいる。示されたよう
に、この構造は最後の要求スロットに到達するまで進行
する。属性フィールドはｘｏｎ／ｘｏｆｆ指示器とロッ
ク／アンロック指示器を含むことができる。

【００６６】さらに、第１フリー識別子から最後のフリ
ー識別子までのフリー要求識別子を含むテーブルが示さ
れている。メモリの使用法について、薄くハッチされた
手段は拡張領域であり、濃くハッチされた領域は充填ス
ロットであり、ハッチされない領域はフリースロットで
ある。さらに要素216 はサーバーテーブルであり、それ
がキュー派生ポインター（queue descendent pointer）
を蓄積するサーバー識別子をインデクスする。要素216
はキュー派生専用の蓄積領域218 のポインターを有して
いる。そこに、キューヘッダー、読み取りスロットポイ
ンター、書き込みスロットポインター、最終フリーポイ
ンター、拡張要求220 の要求キューの同様な繰り返し
（図９を見よ）、フリースロットの番号、使用スロット
の番号、要請されたスロットの番号、および要請された
チャンクの点に使用できるチャンク属性がシーケンシヤ
ルに蓄積されている。例えば、項目222 はカロス（Caro
s ）要求チャンクの形式を示している。それはチャンク
ヘッダー、右手の矢印により表示された一組の連結され
た充填スロット、およびこれまた連結されている一組の
連結された空スロットを含んでいる。また読み取りスロ
ット（最初の充填スロットの開始）と書き込みスロット
（最初の空スロットの開始）および最後のフリースロッ
トの二重ポインターが示されている。

【００６７】図９は図８に非常に似ているが、しかしそ
れは拡張要求のキューに関連している。図８の要素210,
216, 218, 222はそれらの対応物210 Ａ，216 Ａ，218
Ａを有している。ブロック224 はカロス拡張要求チャン
クである。それはブロック222 に非常に似ているが、拡
張ブロック226 については、それは部分的に充填され
（上部）かつ残りの部分に対して空である。それはポイ
ンター228 により指示されている。

【図面の簡単な説明】

【図１】図１は分布データ処理システムと対象指向応用
インターフェースの線図により示されている。

【図２】図２は車両航法システムのモジュール間の協働
を示している。

【図３】図３は種々のユーザープロセス間の協働を例示
している。

【図４】図４はサーバープロセスの割り付けを示してい
る。

【図５】図５はアークネットパケットの通過を示してい
る。

【図６】図６は局所キューの構造を例示している。

【図７】図７はプロセス／通路識別子を示している。

【図８】図８は瞬時メモリ割り付けを例示している。

【図９】図９は拡張要求キューに対する図８に対応して
いる。

【符号の説明】

20 応用インターフェース 22 水平破線ラインペアー 24 応用ソフトウエア手順あるいはモジュール 26 応用ソフトウエア手順あるいはモジュール 28 ブロック 30 局所オペレーティングシステム 32 局所オペレーティングシステム 34 局所オペレーティングシステム 36 関連ソフトウエアブロック 38 関連ソフトウエアブロック 40 関連ソフトウエアブロック 42 関連ソフトウエアブロック 44 関連ソフトウエアブロック 50 ブロック（CD-1） 52 ブロックあるいは航法計算機（NAV ） 54 センサーセット（SENS） 56 要素あるいはインターフェースモジュール（MMI ） 58 可視表示要素 60 音声再生要素 62 入力要素（INP ） 64 ラインあるいはデータストリーム 65 データストリーム 66 ラインあるいはデータストリーム 67 データストリーム 68 ラインあるいはデータストリーム 70 アークネット（ARCNET） 72 カーエリア回線網（CAN ） 74 管理子 76 （局部）管理子 78 管理子 80 回線網駆動装置 82 回線網駆動装置 84 回線網駆動装置 86 回線網駆動装置 88 ユーザープロセス 89 ルートサーバー 90 ユーザープロセス 91 サーバーキュー 92 ルートサーバー 94 サブサーバー 96 ルートサーバー 98 ルートサーバー 100 サーバーキュー 102 サーバーキュー 106 サーバーキュー 110 ブロック（現行サーバー＝所有者か：current se
rver＝owner ） 112 ブロック（要求の取扱：handle request） 114 ブロック（所有者がサーバーリストに存在する
か：owner exists in server list ） 116 ブロック（要求を入れる：put request ） 118 ブロック（現行サーバーのpid −nid か：pid-ni
d of current server） 120 ブロック（取扱が見いだされたか：handle foun
d） 122 ブロック（取扱のコピー，要求の取扱：copy env
of handle, handle request） 124 ブロック（要求の取扱：handle request） 126 ブロック（pid −nid が見いだされたか：pid-ni
d found ） 128 ブロック（要求を入れる：put request ） 130 ブロック（取扱が見いだされたか：handle foun
d） 132 ブロック（現行サーバーを取扱うか：handle cur
rent server ） 134 ブロック（サーバーを分岐，要求を入れる：fork
server, put request） 136 ブロック（要求を入れる：put request ） 138 ブロック（空サーバーが見いだされたか：empty
server found） 140 ブロック（要求を入れる：put request ） 142 ブロック（サーバーを分岐，要求を入れる：fork
server, put request） 150 矢印 151 アークネット管理子 154 フレーム番号表示 156 回答カウント表示 158 回答ポインター 160 回答バッファ 164 ヘッダーフレーム空間 166 フレーム空間 168 矢印 170 矢印 172 ヘッダーフレーム 174 多重バイト固定部分 180 フリーリストアレイ 182 メモリ 184 レジスタ 186 第２レジスタ 188 拡張空間 190 サーバープロセス（srvrid） 192 宛て先プロセス（destnid ） 194 局所通路／プロセス識別子（pid/fcode ） 210 最左端列あるいは要素（network static storag
e） 210A 要素（network static storage） 212 項目 214 領域（reqidtbl） 216 要素（servertbl ） 216A 要素（servertbl ） 218 蓄積領域あるいは要素（queue desc） 218A 要素（queue desc） 220 拡張要求 222 項目あるいは要素（caros request chank ） 224 ブロック（caros extension request chank ） 226 拡張ブロック（extension ） 228 ポインタ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ペトラス マリア アントニウス ファン トーレン オランダ国 5621 ベーアー アインドー フェン フルーネバウツウェッハ１

Claims (9)

【特許請求の範囲】
1. 【請求項１】 陸上車両の多重ノード分布データ処理シ
   ステムにおいて、該システムが、 ａ１．上記の車両に関する物理量を検知する検知手段、 ａ２．物理的に区分されかつ固定された地理的データ要
   素を蓄積する蓄積ノード手段、 ａ３．ユーザー方針データを発生するために上記の物理
   特性と上記の地理的データを処理するデータ処理ノード
   手段、 ａ４．上記の処理を制御するために任意のデータ処理ノ
   ードを進行させ、かつユーザーに対して上記のユーザー
   方針データを制御して進行する要求データを受信するユ
   ーザーＩ／Ｏノード手段、 ａ５．ユーザー信号に対して上記のユーザーＩ／Ｏノー
   ド手段をインターフェースするユーザー入力／出力手
   段、および ａ６．上記のノード手段を相互接続する回線網手段であ
   って、少なくとも１つのノードが上記の検知手段にイン
   ターフェースし、かつ少なくとも１つのノードが応用ソ
   フトウエアを実施するもの、を具え、上記のシステムが
   以下の規定、すなわち ｂ１．メッセージ可能なシステム呼びあるいは基本量の
   ライブラリであって、開放、閉成、読み取り、書き込
   み、探索、ゲットスタット、セットスタット、信号、創
   成を具えるもの、 ｂ２．予め規定された最大時間間隔内で基本量の任意の
   回線網転送を実行する決定論的回線網制御システム、 ｂ３．単一実体としてその完全転送に従うメッセージの
   処理を専ら許容するメッセージ処理組織、 ｂ４．無状態でバスにわたる各ノード間の任意の論述を
   保持する状態維持制御装置、 ｂ５．局所処理パワーおよび／またはデバイスおよび／
   または検知器、Ｉ／Ｏおよび／またはファイルデータを
   共用する複数の各処理の共存送行を許容する分布実時間
   オペレーティングシステム、 を有する多重ノード分布データ処理システム。
2. 【請求項２】 信号に基づいて通信の相互処理をさらに
   許容する請求項１に記載のデータ処理システム。
3. 【請求項３】 上記の蓄積ノードが大量蓄積媒体と逆転
   可能な連結を許容する請求項１あるいは２に記載のデー
   タ処理システム。
4. 【請求項４】 少なくとも１つのノードが異なる各プロ
   トコルの少なくとも２つのバスにインターフェースする
   複数バスシステムとして構成される請求項１から３のい
   ずれか１つに記載のデータ処理システム。
5. 【請求項５】 サーバープロセスのキューの最大アクセ
   ス深さの規定を許容する任意のサーバープロセスに関す
   るキュー管理を有する請求項１から４のいずれか１つに
   記載のデータ処理システム。
6. 【請求項６】 新しいサーバープロセスを創成する必要
   性を自動的に検出するサーバー割り付け機構を有する請
   求項１から５のいずれか１つに記載のデータ処理システ
   ム。
7. 【請求項７】 上記の割り付け機構が、上記の特定資源
   に関する環境を前以て維持しないユーザープロセスから
   特定の資源の局所受信要求に反応する請求項６に記載の
   データ処理システム。
8. 【請求項８】 第１メモリノードと、上記の第１メモリ
   ノードにおけるメモリの少なくとも一部分だけ上記の第
   １メモリノードから異なっている第２ノードで局所的に
   写像する写像手段を具える請求項１から７のいずれか１
   つに記載のデータ処理システム。
9. 【請求項９】 請求項１から８のいずれか１つに記載の
   多重ノード分布データ処理システムとして使用するデー
   タ処理システム。