JP2006506862A - 例えば車両におけるサブネットワークを接続するためのゲートウェイユニット - Google Patents

Abstract

例えば車両におけるサブネットワークを接続するためのゲートウェイユニットが提案される。このゲートウェイユニットにおいては、少なくとも１つのモジュール論理ソフトウェアゲートウェイが使用され、このソフトウェアゲートウェイはメッセージをちょうど２つのサブネットワーク間でルーティングし、このようにして別個の接続経路を供給する。

Description

従来技術
本発明は、例えば車両におけるサブネットワークを接続するためのゲートウェイユニットに関する。

車両内での新たなサービスを可能にするために、異なるバスセグメントに存在する制御ユニットの通信は必要不可欠である。そのような通信は異なるバスセグメントが１つまたは複数のゲートウェイユニットを介して相互に接続されている場合にのみ行うことができる。２つのバスセグメントを相互に接続するゲートウェイユニットは、一方のバスセグメントにおいて受信されるメッセージを他方のバスセグメントに転送する（ルーティングする）タスクを有する。そのようなゲートウェイユニットの複雑性は接続すべきバスセグメントの数と共に増す。車両のネットワーク接続アーキテクチャを設計する際には、メッセージルーティングに対して許容可能な遅延、エラー許容差、フレキシビリティ、拡張性およびコストの特性に関する最適値を発見することが試みられる。

アプリケーションに応じて星形アーキテクチャを有する中央ゲートウェイユニットまたは、例えばバックボーン・バスと接続することができる複数のゲートウェイユニットが使用される。異なるバスを接続しているゲートウェイユニットは（例えばテーブルを介して）コンフィギュレーションされている。すなわちこれによって他のセグメントへの純粋なメッセージルーティングに関してはソフトウェアを変更する必要はない。しかしながら接続されているバスの種類および数が変更されるやいなや著しい変更の手間が必要とされ、このような変更では新たな要求を満たすために単に既存のコンフィギュレーションテーブルを適合させさえすれば良いのではなく、ソフトウェア全体を書き換える必要がある。すなわち中央コンフィギュレーションおよびルーティングソフトウェアの複雑性は接続されるバスセグメントの数と共に大幅に増す。

発明の利点
ソフトウェアで構成されているゲートウェイ（論理ソフトウェアゲートウェイ）がちょうど２つのサブネットワーク間でのメッセージのルーティングに対して権限を有しているゲートウェイユニットのモジュール形式の構造によって、ゲートウェイの既存のソフトウェアおよび／または既存のコンフィギュレーションテーブルの変更を必要とすることなく、ゲートウェイを拡張することができる。ネットワークトポロジが変更される際にそのようなモジュールゲートウェイを付加または除去することによって、そのような変更措置が回避される。したがって既存の接続経路に影響を及ぼすことなく、中央ゲートウェイユニットにおいてバスセグメントを切り離すことが可能である。

さらには、上述のようなモジュールゲートウェイによってエラー限定が達成される。何故ならば、機能していないゲートウェイが存在する場合には他のゲートウェイはその機能していないゲートウェイに依存せずに、引き続き自らのタスクを達成するからである。すなわちエラーは直接的に関与するゲートウェイに限定され、他のバスセグメントへの接続は関与していない。１つのバスセグメントにおいてエラーが生じた場合には、メッセージは制限されること無く別のバスセグメントを介してさらにルーティングされる。

さらに上述のコンセプトはフレキシブルに拡張可能であり、またネットワーク接続アーキテクチャに適合される。付加的なサブネットワークが中央ゲートウェイに付加される場合には、付加的なモジュールゲートウェイを付加するだけでよい。既存のモジュールゲートウェイはこれに関与しない。サブネットワークが切り離されると、このサブネットワークを接続するゲートウェイが切り離され、残りのゲートウェイはそのまま変更無く存在する。

さらに論理ゲートウェイにおいては２つの異なるサブネットワークの接続に必要とされる機能のみが常に包含されているので、メッセージは可能な限り高速にルーティングされる。メッセージのルーティングに関する不必要なオーバヘッドは回避される。論理ゲートウェイはちょうど２つのサブネットワークの接続に対して権限を有するので、機能のセキュリティがクリティカルなサブネットワークと機能のセキュリティがクリティカルでないサブネットワークとの間でデータ伝送が行われる場合には、情報の流れをさらに個別に制御することができる。すなわちこれによりファイアウォール機能に対する最適な制御可能性が供給される。この制御可能性によって各接続経路を別個に制御することができる。つまり、エアインタフェースを介してメッセージをルーティングする論理ゲートウェイは外部の危険から保護されるために、車両内の２つのＣＡＮサブネットワーク間でメッセージをルーティングし且つ外部の危険には直接曝されていない論理ソフトウェアゲートウェイよりも厳格なセキュリティメカニズムを実施することができる。

さらに、ここで説明したアーキテクチャは単一または複数のゲートウェイを個別にアクティブ化および／または非アクティブ化することができるので、このようにしてシステム状態に依存して１つまたは複数のゲートウェイをオンないしオフすることができる。

さらには、個々の論理ゲートウェイは相互にそもそも接続されていないので、全ゲートウェイユニットの複雑性は低減される。例えば３つの論理ソフトウェアゲートウェイが中央ゲートウェイまたは分離された３つのポイント・ツー・ポイントゲートウェイにおいて実行されるか否かは重要ではない。

さらなる利点は論理ゲートウェイの具体的な実施形態から明らかになる。この実施形態によれば、各ゲートウェイにはルーティングテーブルが設けられており、このルーティングテーブルを介してメッセージのルーティングが処理され、またこのルーティングテーブルはゲートウェイのソフトウェアに依存しない。このようにテーブルを基礎とするアプローチによって、ゲートウェイソフトウェアをコンフィギュレーションするためのツールを使用することができる。このアプローチによって有利にはメッセージに優先順位を付けることができるので、有利にはルーティングされるべき特定のメッセージには他のメッセージよりも高い優先順位を割り当てることができる。

さらに有利には、複数のモジュールソフトウェアゲートウェイに分割されるにもかかわらず、メッセージルーティングの順序が遵守されることを保証するスケジューラが設けられている。このようにして最初にゲートウェイに到来したメッセージをやはり最初にこのゲートウェイから発信することもできる。

さらなる利点は実施例の以下の説明ないし従属請求項から明らかになる。

図面
本発明を図面に示した実施例に基づき詳細に説明する。

図１は３つのバスセグメントを相互に接続するゲートウェイユニットの前述のアーキテクチャの原理図を示す。
図２はそのようなゲートウェイの有利な実施例を示し、この実施例は低速ＣＡＮ、高速ＣＡＮおよびＳＰＩバス間でメッセージを交換する。
図３は４つのサブネットワークを接続する中央ゲートウェイユニットを示す。
これに対し図４は前述のゲートウェイアーキテクチャを用いて４つのサブネットワークを接続するポイント・ツー・ポイントゲートウェイユニットを示す。
最後に図５は階層モデルに基づいた、制御ユニットに組み込まれているゲートウェイを示す。

実施例の説明
図１にはゲートウェイユニット１０が示されており、このゲートウェイユニット１０には３つのバスセグメント１，２，３が接続されている。またこのゲートウェイユニット１０はあるバスセグメントからのメッセージを別のバスセグメントの一方または両方にリンクさせる（ルーティング）タスクを有する。図示されているアーキテクチャの原理はモジュールゲートウェイ（論理ソフトウェアゲートウェイ）１２，１３，２３であり、ここではそのようなゲートウェイがちょうど２つのサブネットワーク間でのメッセージのルーティングに対して権限を有している。つまりゲートウェイ１２はメッセージを１から２またはその逆にルーティングし、ゲートウェイ１３はメッセージを１から３またはその逆にルーティングし、またゲートウェイ２３はメッセージを２から３またはその逆にルーティングする。したがって各論理ソフトウェアゲートウェイは２つのサブネットワークないしバスセグメント間の個々の接続経路を表す。

ここでゲートウェイ１２，１３，２３はソフトウェアプログラムとして構成されており、このソフトプログラムを用いることにより２つのサブネットワーク間でのメッセージルーティングに必要とされるプロトコル固有の適合が行われる。実施例に応じて、各サブネットワークは個々の伝送媒体である。サブネットワーク１は例えば低速ＣＡＮ、サブネットワーク２は高速ＣＡＮ、またサブネットワーク３はＳＰＩバスでよい。新たなサブネットワーク、例えばＭＯＳＴバスがさらに加わると、付加的な論理ソフトウェアが組み込まれる。既存のゲートウェイを変更する必要はない。サブネットワーク、例えばＳＰＩバスが切り離されると、論理ソフトウェアゲートウェイ１３および２３が切り離される。普遍的なゲートウェイ機能を有するために、論理ソフトウェアゲートウェイを全ての接続可能性に対して表すことができなければならない。これは実現すべきゲートウェイの設計に応じて全システムと組み合わされる。これは通常の場合、全てのサブネットワークが直接的に相互に接続されていないので、選択された接続経路のみに選択された論理的なソフトウェアゲートウェイを設けることができるようになる。

各サブネットワークが別のサブネットワークとそれぞれ接続されるべき場合には、Ｎ*（Ｎ−１）／２の論理ソフトウェアゲートウェイが必要となる。変数Ｎは全システム内に存在するサブネットワークの数に相応する。したがって３つのサブネットワークに対しては３つの論理ソフトウェアゲートウェイが生じ、４つのサブネットワークに対しては６つの論理ソフトウェアゲートウェイが生じ、５つのサブネットワークに対しては１０の論理ソフトウェアゲートウェイが生じる。これらの論理ソフトウェアゲートウェイが中央ゲートウェイに存在するか、複数の分散されたポイント・ツー・ポイントゲートウェイに存在するかはあまり重要ではない。

図２は、図１によるモジュールゲートウェイアーキテクチャの基本的特質の詳細な実施例を示す。有利には制御ユニットのマイクロコントローラにおいてプログラムとして実現されているゲートウェイ１０は図示されているモジュールソフトウェアゲートウェイ（：ＣＡＮＣＡＮ，：ＣＡＮＳＰＩ）の他に、バスシステムへのアクセスを制御するバス固有の送信ユニットを包含する。各バスセグメントには受信オブジェクト（：Ｒｘ−ＣＡＮ，：Ｒｘ−ＳＰＩ）が割り当てられており、これらの受信オブジェクトは到来するメッセージをどの論理ソフトウェアゲートウェイにルーティングするかを決定する。相応に送信過程に対してはバス固有の送信オブジェクト（：ＴｘＣＡＮ，：ＴｘＳＰＩ）が存在し、これらの送信オブジェクトはそれぞれのバスへのアクセスを制御し、且つ複数のモジュールソフトウェアゲートウェイが送信媒体を同時に占有することを回避する。

ソフトウェアゲートウェイ（図２における：ＣＡＮＣＡＮ：ＣＡＮＳＰＩ）は内部的に複数のソフトウェアオブジェクトから構成されており、これらのソフトウェアオブジェクトは到来するメッセージを中間バッファリングし、プロトコル固有の適合を行う。簡単な適合は例えば、ＩＤ１００を有する高速ＣＡＮからのＣＡＮメッセージをＩＤ２００を有する低速ＣＡＮへと送信する必要があることである。プロトコル固有の適合は相応のプログラムによって（最も簡単な場合にはテーブルによって）行われる。論理ソフトウェアゲートウェイ内部で実施されるこのプロトコル固有の適合のためにコンフィギュレーションテーブルが使用される。

有利な実施形態においてはバス固有の受信オブジェクトがいわゆるルーティングテーブルを介してコンフィギュレートされる。このルーティングテーブルを用いて、到来するメッセージが論理ソフトウェアゲートウェイに転送されないか、１つの論理ソフトウェアゲートウェイに転送されるか、２つの論理ソフトウェアゲートウェイに転送されるかが決定される。したがってルーティングテーブルには到来するそれぞれのメッセージタイプに関して、メッセージのさらなる処理が格納される。さらにはバスの異なる速度によって、所定のタイプの５つおきのメッセージ（例えば機関回転数）のみを一方のバスセグメントから他方のバスセグメントへと転送することができる。このこともまた受信オブジェクトにおける前述のルーティングテーブルを用いて実現することができる。このルーティングテーブルは本来のゲートウェイのソースコードに依存しないので、ルーティングテーブルの変更は該当するモジュールゲートウェイのソフトウェアを変更させることはない、もしくは実質的に変更させることはない。バス固有の受信ユニットは発見したメッセージをルーティングテーブルにおいて検索し、このルーティングテーブル内に包含されている情報に基づき、どの論理ソフトウェアゲートウェイがさらなる処理のためのこのメッセージを受け取るかを決定する。

バス固有の送信ユニットないしこの送信ユニットに設けられているプログラムはバスへのアクセスを制御する。バスがまさに占有されている場合には、送信ユニットはいずれの論理ソフトウェアゲートウェイも送信しないことを保証する。

上述したように、付加的に論理ソフトウェアゲートウェイがメッセージを中間バッファリングし、例えばメッセージを送信すべきバスセグメントがまさに占有されている場合にメッセージが失われることは回避される。すなわちメッセージは直接的に転送される前に待機ループに格納される。この待機ループへのメッセージの格納はゲートウェイユニットの内部スケジューラにメモされる。内部スケジューラは相応のモジュール論理ソフトウェアゲートウェイにメッセージを送信することによってメッセージの送信を指示する。次にソフトウェアゲートウェイはメッセージの送信を指示する。論理ソフトウェアゲートウェイがメッセージを送信しようとする場合には、この送信の要望をスケジューラに通知する必要がある。どのソフトウェアゲートウェイが最初にメッセージの送信に対する権限を得るかは通知の順序に依存する。

このコンセプトはメッセージの順序の遵守を保証する。システム内に殊に高い優先順位を有するメッセージが存在する場合には、スケジューラは、送信の要望を通知するために論理ソフトウェアゲートウェイを呼び出すことができる複数の方法を準備する。スケジューラは先ず高い優先順位を有する要求を処理し、次に通常の要求を処理し、優先順位に依存する送信権限を論理ソフトウェアゲートウェイに付与する。例えば各送信の要望にはメッセージの優先順位を表すデータが設けられているか、スケジューラはメッセージの優先順位がメモされているテーブルを包含し、このテーブルからスケジューラは優先順位を読み出す。

上述のアーキテクチャおよび構成によって、ゲートウェイユニットのソフトウェア自体を変更することなく、このゲートウェイユニットをテーブルを介してコンフィギュレーションすることができる。例えばメモリ内のパラメータ文の変更によってゲートウェイを別のメッセージルーティングのために再プログラミングすることができる。同一のインタフェースが使用される場合には、ゲートウェイソフトウェアは専らパラメータ文を介してコンフィギュレーションすることができる。別のインタフェースがゲートウェイに接続されている場合には、モジュールソフトウェア構成要素をゲートウェイに組み込むことができる。

したがって、種々のゲートウェイコンフィギュレーションは例えばライブラリからなるソフトウェアモジュールの統合およびルーティング情報の供給によって生成される。新たなＣＡＮマトリクスを有するＣＡＮインタフェースを新たに組み込みことは、実質的にルーティングテーブルへの新たなルーティング情報の入力に限定される。つまり、異なる構造線のＣＡＮ−ＣＡＮゲートウェイを短時間でシステムに順応させることができる。これによって、コンフィギュレーションに依存しないコードは中央で検査され、またシステムテスト以外には専ら新たな論理ソフトウェアゲートウェイないし新たなコンフィギュレーションに関する組み込みテストが実施されさえすればよいので、発生したコードの検査および検証はこれによって簡略化される。

図３は４つの異なるバスセグメント、すなわち低速ＣＡＮ、高速ＣＡＮ、ＳＰＩバスおよびＭＯＳＴバスを接続するためのゲートウェイ１０を示す。前述のアーキテクチャがここでも使用され、この際論理ソフトウェアゲートウェイ（：ＣＡＮ−ＭＯＳＴ、：ＣＡＮ−ＳＰＩ、：ＣＡＮ−ＣＡＮ、：ＳＰＩ−ＭＯＳＴ）が使用され、これらの論理ソフトウェアゲートウェイはそれぞれ別個の接続経路を実現する。これらのソフトウェアゲートウェイ以外にも、前述したようなバス固有の受信モジュール（：Ｒｘ−Ｍｏｓｔ、：Ｒｘ−ＣＡＮ、：Ｒｘ−ＳＰＩ）および送信モジュール（：Ｔｘ−Ｍｏｓｔ、：Ｔｘ−ＣＡＮ、：Ｔｘ−ＳＰＩ）が示されている。図示したアーキテクチャは、前述の４つのバスセグメントを相互に接続する中央ゲートウェイユニットを示す。

図４には別のネットワークトポロジが示されており、このネットワークトポロジは６つのポイント・ツー・ポイントゲートウェイユニット１０ａ，１０ｂ，１０ｃ，１０ｄ，１０ｅおよび１０ｆを有する。これらのポイント・ツー・ポイントゲートウェイはそれぞれバス固有の接続のための送信エレメントおよび受信エレメントを備えた上述の論理ソフトウェアゲートウェイ構造を有する。上述のアーキテクチャによって外部中央ゲートウェイとポイント・ツー・ポイントゲートウェイとの間の物理的なネットワーク接続アーキテクチャが考えられる全ての複合形態を包含できることが証明される。ソフトウェアアーキテクチャは物理的なネットワーク接続アーキテクチャに依存しないので、このソフトウェアアーキテクチャは考えられる全てのアーキテクチャにおける接続を許容する。中央ゲートウェイの変形形態ではソフトウェアがマイクロコントローラにおいて実行され、分散型の変形形態では異なるコントローラにおいて実行される点は異なってよい。

ゲートウェイユニットをコンフィギュレーションするために種々の可能性がもたらされる。ルーティング決定のコンフィギュレーションはルーティングテーブルを介して行われる。この場合にはバス固有の受信オブジェクトが、どの論理ソフトウェアゲートウェイにメッセージを転送すべきかを決定する。したがってこの受信オブジェクトは、どのメッセージがどのサブネットワークに転送されるべきか、また必要に応じていかなる周辺条件（例えば５つおきのメッセージ等）下で転送されるべきかを示すルーティングテーブルを用いてコンフィギュレーションされる。ソフトウェアゲートウェイのソフトウェアはバス固有の適合を実現し、本来のルーティング課程には依存しない。

ソフトウェアゲートウェイのコンフィギュレーションはプロトコルパラメータの適合によって行われる。この場合論理ゲートウェイは、どのようにプロトコルパラメータを変換すべきかを示すテーブルを介してコンフィギュレーションされる。ここで、識別コード１００を有するメッセージが別のネットワークセグメントへ送信される際に識別番号２００を有する必要があるということをコンフィギュレーションできる。さらには、ゲートウェイソフトウェアを異なるネットワーク接続アーキテクチャに適合させるために、バス固有の受信オブジェクトをコンフィギュレーションするルーティングテーブルを分配ないし組み込むことができる。このタスクは内部スケジューラによって処理され、この内部スケジューラは論理ソフトウェアゲートウェイを中央ゲートウェイユニットにおいて相互に調整する。スケジューラは種々のゲートウェイ変形形態に対して別個に生成する必要がある。

図５に示されている別の実施形態においては、ゲートウェイはスタンドアローンゲートウェイではなく、付加的なアプリケーション機能を有する制御装置に組み込まれているゲートウェイである。このゲートウェイではゲートウェイソフトウェアが通常の通信デッキの機能も担うことができる。すなわち、ここでもまたメッセージを本来のアプリケーションに転送し、且つメッセージを送信のためにこのアプリケーションから受信することができなければならない。これに関してメッセージを１つ上の階層ないし１つ下の階層に到達させるために、階層固有のプロトコルパラメータを除去ないし付加する機能を有する別のオブジェクトが必要とされる。

この付加的なオブジェクトは通常の場合、通常の通信ネットワークのソフトウェアの構成部分である。図５は制御装置１００の階層モデルを示し、この階層モデルにはＣＡＮ−ＣＡＮゲートウェイが組み込まれている。ここではアプリケーションシステムＩと通信システムＩＩが区別される。３つの層１，２，３が示されており、第１の層には低速ＣＡＮのためのドライバ１０２および高速ＣＡＮのためのドライバ１０４が設けられている。さらには、ネットワーク層３においては付加的なオブジェクト（ＣＡＮ層３）が挿入されており、この付加的なオブジェクトは受信オブジェクトＲｘ３および送信オブジェクトＴｘ３を介してアプリケーションＡ，ＢおよびＣと通信する。この付加的なオブジェクトは、必要であれば、メッセージの中間バッファリングを実施し、プロトコル固有のパラメータを付加または除去する。

この階層に組み込まれている論理ソフトウェアゲートウェイ（ＣＡＮ−ＣＡＮ）はメッセージを一方のバスから他方のバスへルーティングする。受信オブジェクトＲｘ２および送信オブジェクトＴｘ２は前記の説明に応じて２つのＣＡＮバス間でメッセージをルーティングするために使用される。これらのオブジェクトは階層間のインタフェースを表す。別の実施形態においては相応の拡張によって異なる階層にある２つのサブネットワークを接続することができる。このことは例えば、トランスポートプロトコル（例えばＩＳＯ ＴＰ）が使用される場合には必要である。この場合には、接続が行われている階層毎に論理ソフトウェアゲートウェイが存在する。つまり例えば、階層３にはＣＡＮメッセージ（例えば速度情報またはタンク充填状態）をこの階層３において転送するＣＡＮ−ＣＡＮゲートウェイを設けることができ、他方階層４には、例えば車両コンピュータにおける表示部のためのテキストを包含するトランスポート情報を繋ぐ別のＣＡＮ−ＣＡＮゲートウェイを設けることができる。上の階層との接続は、転送されるべきメッセージの内容を検査できるようにするためにも必要である。内容は完全なメッセージが受信されている場合にのみ分析される。

３つのバスセグメントを相互に接続するゲートウェイユニットの前述のアーキテクチャの原理図。 ゲートウェイの有利な実施例。 ４つのサブネットワークを接続する中央ゲートウェイユニット。 ４つのサブネットワークを接続するポイント・ツー・ポイントゲートウェイユニット。 制御ユニットに組み込まれているゲートウェイ。

Claims (7)

1. 少なくとも２つのサブシステムを相互に接続する、例えば車両におけるサブネットワークを接続するためのゲートウェイユニットにおいて、
   前記ゲートウェイユニットは少なくとも１つのモジュールソフトウェアゲートウェイから構成されており、該モジュールソフトウェアゲートウェイはメッセージをちょうど２つのサブネットワーク間でルーティングすることを特徴とする、ゲートウェイユニット。
2. 少なくとも３つのサブネットワークがゲートウェイユニットに接続されており、モジュールソフトウェアゲートウェイが使用され、各モジュールソフトウェアゲートウェイはメッセージをちょうど２つのサブシステム間でルーティングする、請求項１記載のゲートウェイユニット。
3. さらに各サブネットワークに対してバス固有の受信オブジェクトが設けられており、該受信オブジェクトは到来するメッセージを、選択されたソフトウェアゲートウェイに転送する、請求項１または２記載のゲートウェイユニット。
4. 前記受信オブジェクトはルーティングテーブルを包含し、該ルーティングテーブルにおいて到来するメッセージの処理がコンフィギュレーションされている、請求項３記載のゲートウェイユニット。
5. さらに各サブネットワークに対してバス固有の送信オブジェクトが設けられており、該送信オブジェクトはそれぞれのバスへのアクセスを制御する、請求項１から４までのいずれか１項記載のゲートウェイユニット。
6. 前記モジュールソフトウェアゲートウェイは到来するメッセージを中間バッファリングし且つプロトコル固有の適合を行う、請求項１から５までのいずれか１項記載のゲートウェイユニット。
7. アプリケーションシステムを有する制御装置にゲートウェイユニットを組み込む際に、少なくとも１つのモジュール論理ゲートウェイを通信システムの階層内に設け、論理ゲートウェイはちょうど２つのサブシステムを接続する、請求項１から６までのいずれか１項記載のゲートウェイユニット。

Images