JP2011020618A - ノード - Google Patents

Abstract

【課題】スケジュールが通信途中に切り替わる場合において、通信速度を落とさずに、ノードが起動時にどのスケジュールに従ってよいかを把握できるようにして、通信に参加できるようにすること。
【解決手段】フレームを送信せずに受信だけをするように初期化をする（Ｓ１１０）。正常なフレームを受信しないまま（Ｓ１２０ＮＯ）タイムアウトしたと判断すると（Ｓ１３０ＹＥＳ）起動時スケジュールであると判定して（Ｓ１４０）この処理を終え、起動時スケジュールに従って通信を開始する。正常なフレームを受信したと判断すると（Ｓ１２０ＹＥＳ）複数サイクル分のデータＩＤを取得して、判定処理を実行する（Ｓ１８００）。判定処理でスケジュールを判定したら（Ｓ１９０ＹＥＳ）そのスケジュールに従って通信を開始する。判定処理でスケジュール判定しなかったら（Ｓ１９０ＮＯ）通信を開始せずＳ１２０に戻る。
【選択図】図３

Description

スケジュールに従って通信をするノードに関する。

スケジュールを用いるタイムトリガ方式の通信プロトコル（ＦｌｅｘＲａｙ（登録商標）など）による通信システムでは、この通信システムに属する通信機能を備えたノード全てが、通信起動時に互いに同期を取った後、規定のスケジュールに従ってバス通信をする。このようなスケジュールは、フレームＩＤの配列として定義されている。フレームＩＤとは、各ノードが送信するフレームの時間領域に基づいて、フレームの先頭に付けられるものである。さらに、通常はフレームＩＤと送信内容を一意に関連づけて送信することにより、フレームＩＤは時間領域と送信内容の両方を示す識別子として用いられる。

ところで、既存の通信システムに新たなノードを接続する場合、その新たなノードは、元々あるノードによって継続されている通信の途中で起動しても、スケジュールなどの通信条件が把握できないので通信に参加できない。よって、通信システム全体を再起動する必要があった。そこで、元々あるノードの内の一つが、通信条件を示すデータを周期的にバスに送信する。そして、その新たなノードは、その通信条件を示すデータをバスから取得して、必要な設定をしてから通信に参加する。そうすれば、通信途中であっても、ノードを容易に追加できるようになる（特許文献１）。

特開２００８−２３６２１７号公報

スケジュールが複数用意されていて、通信途中に切り替わる通信システムを前提とする。そして、ある一つのノードが、トラブル等によって再起動をした後、他のノードによって継続されている通信に、再起動したノードを復帰させる場合を考える。この場合、特許文献１の技術によれば、通信条件を示すデータが周期的に送信されるので、そのデータに基づいてスケジュールを調べることで、通信に復帰することはできる。しかし、通信条件を示すデータが周期的に流れていることによって、通信が定常的に低速になってしまう。つまり、偶発的な事態に備えるために、本来不要な情報を周期的に送信すれば、必要な情報の通信速度が落ちてしまう。また、背景技術で述べたような、ノードを追加する場合などにおいても同様な課題が生じる。

本発明はこの課題に鑑み、スケジュールが通信途中に切り替わる場合において、通信速度を落とさずに、ノードが起動時においてどのスケジュールに従ってよいかを把握して、通信に参加できるようにすることを目的とする。

この課題を解決するための請求項１の発明は、識別子の配列によって定義される複数のスケジュール、及びその複数のスケジュールそれぞれにおいて自身に割り当てられた識別子がどれであるかを記憶しておき、複数のスケジュールの中から採用されている何れか一つのスケジュールに従って、自身に割り当てられた識別子を送信情報の一部としてバスに送信し、採用されているスケジュールが、記憶された複数のスケジュールの範囲内で通信途中に切り替わるノードである。

そして、このノードは、取得手段と判定手段とを備える。取得手段は、採用されているスケジュールが把握できない場合、送信情報のバスへの送信を禁止する一方で、他ノードによって送信された送信情報をバスから受信して、その受信した送信情報に含まれる識別子を取得する。判定手段は、取得手段によって取得された識別子に基づいて、記憶している複数のスケジュールそれぞれに基づいて、採用されているスケジュールを判定する。そして、このノードは、判定手段によって判定されたスケジュールに従って、送信情報の送信を開始する。

この発明によれば、スケジュールが通信途中に切り替わる場合において、通信速度を落とさずに、ノードが起動時にどのスケジュールに従ってよいかを把握して、通信に参加できるようになる。理由を説明する。まず、どのスケジュールに従ってよいか把握できない間は、送信情報を送信しないようになっている。よって、その間において、他ノードからの送信情報との衝突を起こして、通信を不調にさせることは無い。

そして、取得手段と判定手段との動作は、他ノードが行う「通常の通信から得られる情報」を利用して、通信に参加するためのものである。「通常の通信から得られる情報」というのは、識別子のことである（識別子は、通常の通信に用いるものであって、本来はどのスケジュールであるかを伝達するためのものではない）。よって、余分な情報を周期的に送信するなどして通信速度を落とすことがない。よって、上記の効果が得られる。

なお、バスに送信情報が流れていなければ、取得手段は識別子を取得できない。しかし、この場合でも判定手段の動作は先述した通りである。つまり「ゼロ個の識別子が取得された」という取得結果に基づいて判定をする。このように識別子が取得できない場合というのは、他ノードも送信情報を送信していない、つまり、通信システム全体の起動直後である場合を想定している。

また「採用されているスケジュールが把握できない場合」というのは、つまり起動時のことを指している。ここで言う「起動時」とは、主にはノードの電源投入または再起動による起動直後を想定しているが、これ以外にも、エラー等によって通信が中断した後に行う復帰動作時なども含む。

ところで、スケジュール判定のためには、少なくとも１サイクル分の識別子を取得するのが望ましい。毎サイクル同じ配列のスケジュールであれば、１サイクル分の情報は、正しい判定をするのに十分な情報だからである。しかし、たまたま他ノードがその時に送信情報の送信を失敗すると、スケジュールの判定を誤ってしまうことも考えられる。そこで次のようにすると良い。

請求項２のノードは、取得手段が、スケジュールの複数サイクル分の識別子を取得する。そして、判定手段は、集約手段と、算出手段とを備える。集約手段は、取得手段によって取得された複数サイクル分の識別子を取得時刻に従って配列し、その配列をスケジュールの１サイクル分に集約する。そして算出手段は、集約手段によって集約された識別子の配列と、スケジュールそれぞれの識別子の配列との差を算出する。そして判定手段は、算出手段によって算出された差の中で最少のものに対応するスケジュールが、採用されているスケジュールであると判定する。

この発明によれば、複数サイクル分の識別子に基づくので、判定の精度が上がる。なお、集約方法としては例えば、論理和や論理積が挙げられる。
ところで、集約方法が例えば論理積だと、取得した識別子が集約によって欠落することもあり、場合によっては望ましくない。そこで次のようにすると良い。

請求項３のノードは、集約手段が、取得手段によって取得された複数サイクル分の識別子を、各サイクル分同士の論理和を取ることで集約する。この発明によれば、取得した識別子を欠落させることなく集約できる。

ところで、算出された差がどれも大きい場合、判定結果の信頼性が低いことになる。そうすると、ときには判定を誤ってしまうことも考えられる。そうすると、通信に参加した際に、衝突等を起こして通信を不調にさせてしまう可能性が高まる。そこで次のようにすると良い。

請求項４のノードは、判定手段が、算出手段によって算出された差の中で最少のものが閾値未満かを検査する検査手段を備える。さらに判定手段は、検査手段の検査結果が閾値未満だと、算出手段によって算出された差の中で最少のものに対応するスケジュールが、採用されているスケジュールであると判定する一方で、検査手段の検査結果が閾値以上だと、採用されているスケジュールを判定しない。

この発明によれば、誤って通信を不調にさせる可能性が低くなる。理由を述べる。構成上、スケジュールを判定しなければ、送信を開始しないようになっている。よって、算出手段による算出結果が閾値以上であれば、スケジュールが判定されないので送信が開始されない。よって、算出手段による算出結果が閾値以上の場合、つまりスケジュールの判定が誤っている可能性が高い場合に「誤った判定に基づいて送信情報の送信を開始して、通信を不調にさせる」ということを防ぐことができる。

ところで当初の課題は次のようにしても解決できる。請求項５の発明は、互いに通信可能に接続された３つ以上のノードが、切り替え可能なスケジュールに従って送信情報を送信するための通信処理を実行する通信システムに用いられるノードである。そして、判断手段と取得手段と判定手段とを備える。

判断手段は、通信処理を開始する前に、通信処理が複数の他ノードによって既に実行されているか否かを判断する。そして、取得手段は、通信処理が複数の他ノードによって既に実行されていると判断手段によって判断された場合には、他ノードが従っているスケジュールに関するスケジュール情報を、他ノードによって送信される送信情報から取得する。また、判定手段は、取得手段によって取得されたスケジュール情報に基づいて、他ノードが従っているスケジュールを判定する。そして、このノードは、判定手段によって判定されたスケジュールに従って通信処理を開始する。

この発明によれば、スケジュールが通信途中に切り替わる場合において、通信速度を落とさずに、ノードが起動時にどのスケジュールに従ってよいかを把握して、通信に参加できるようになる。

理由を説明する。送信情報を送信するための通信処理を開始する前に、他ノードによる通信が実行されていると判断すると、他ノードが従っているスケジュールを判定して、その判定したスケジュールに従って通信処理を開始するので、起動時にどのスケジュールに従ってよいかを把握して、通信に参加できる。

また、他ノードからの送信情報を利用したスケジュールの判定によって通信に参加するので、余分な情報を周期的に送信して通信速度を落とすようなことがない。よって、上記の効果が得られる。

ところで、通信処理を他ノードがまだ実行していない場合については、次のようにすると良い。請求項６のノードは、通信処理が複数の他ノードによってまだ実行されていないと判断手段によって判断された場合には、通信システム全体の起動時のものとして予め定められたスケジュールに従って通信処理を開始する。よって、通信処理を他ノードがまだ実行していない場合でも、通信を開始することができる。

ところで当初の課題は次のようにしても解決できる。請求項７の発明は、互いに通信可能に接続された３つ以上のノードが、切り替え可能なスケジュールに従って送信情報を送信するための通信処理を実行する通信システムに用いられるノードである。そして、取得手段と判定手段とを備える。

取得手段は、通信処理を中断した後、他ノードによる通信処理の継続中に通信処理を再開する場合、他ノードが従っているスケジュールに関するスケジュール情報を、他ノードによって送信される送信情報から取得する。また、判定手段は、取得手段によって取得されたスケジュール情報に基づいて、他ノードが従っているスケジュールを判定する。そして、このノードは、判定手段によって判定されたスケジュールに従って通信処理を再開する。

この発明によれば、請求項５と同様な効果が得られる。理由は、請求項５での説明とほぼ同様である。請求項５と異なるのは、取得手段が、他ノードによって通信処理が継続されている最中に再起動によって通信に復帰する場合を前提とした点である。よって請求項５とは異なり、判断手段を備えていない。

また、上記発明は、具体的には次のようにすると良い。請求項８のノードは、ＦｌｅｘＲａｙによって通信をする。ＦｌｅｘＲａｙは高速通信が特長であるので、通信速度を落とさない上記発明との組み合わせは有効である。

通信システムのブロック構成図。 各場面において送信されるデータＩＤを示した図。 起動処理のフローチャート。 判定処理のフローチャート。 テンプレートの説明図。

本発明の実施例を説明する。図１は、本発明が適用された通信システム１のブロック構成図である。図に示すように、通信システム１は、エンジンＥＣＵ（Electronic Control Unit：電子制御装置）１０・ＡＢＳ／ＥＣＵ２０・メータＥＣＵ３０が互いにバス通信できるように、バス９９に接続されている。そして各ＥＣＵは、ＦｌｅｘＲａｙによって通信するようになっている。また、通信システム１は、自動車に搭載されるものであり、エンジンＥＣＵ１０はエンジン、ＡＢＳ／ＥＣＵ２０はＡＢＳ、メータＥＣＵ３０はメータを制御すると共に、制御対象に関する情報としてのフレームを送受信する通信機能を備える。なお、実際の自動車には多数のＥＣＵが搭載されるが、本実施例では説明を簡略にするために３つのＥＣＵのみを示している。

図に示すように、エンジンＥＣＵ１０は、マイコン１００・トランシーバ２００を備える。マイコン１００は、トランシーバ２００を通じて、バス９９からフレームを取得したり、バス９９にフレームを送信したりできる。マイコン１００の内部構造を説明する。図に示すように、マイコン１００は、ＣＰＵ１１０・ＣＣ（コミュニケーション・コントローラ）１２０・フラッシュＲＯＭ１３０・ＲＡＭ１４０を備える。ＣＰＵ１１０は、フレームの送受信をするための通信処理の主体となる。ＣＣ１２０は、トランシーバ２００とＣＰＵ１１０とのインタフェイスである。ＲＡＭ１４０は、ＣＰＵ１１０がプログラムの実行時等に使用する記憶媒体である。フラッシュＲＯＭ１３０は、ＣＰＵ１１０に接続され、スケジュールや、フレームを送受信するためのプログラム、さらに、＜１＞（データＩＤ：Ｘを＜Ｘ＞と示す。）＜５＞・＜７＞が自装置に割り当てられていることを記憶している。

データＩＤとは、送信内容を示す識別子である。スケジュールは、データＩＤとは別に、ＥＣＵがフレームを送信する時間領域に基づいて、フレームの先頭に付加されるフレームＩＤの配列によって定義される。そして、各ＥＣＵは、このスケジュールに従って通信をする。つまり各ＥＣＵは、通信中はバス９９からフレームＩＤを取得することで、スケジュール上の時刻を確認し続け、自装置に割り当てられたフレームを送信する時間領域が来たら、その時間領域に基づいてフレームの先頭にフレームＩＤを付加されたフレームに、送信内容を示すデータＩＤを付加したデータを格納して送信する。

なお、本実施例の通信システム１で規定されているスケジュールには、起動時スケジュール、及び通常スケジュールα・β・γの四つがある。さらに、それぞれのスケジュールについてテンプレートがある。これらについては後述する。

ＡＢＳ／ＥＣＵ２０・メータＥＣＵ３０は、エンジンＥＣＵ１０とハードウェア構成やフラッシュＲＯＭ１３０の記憶内容は同じである。よって、内部構成の図示を省く。ただし異なる点がある。それは、割り当てられたデータＩＤである。その割り当ては、ＡＢＳ／ＥＣＵ２０は＜２＞・＜４＞・＜６＞、メータＥＣＵ３０は＜３＞・＜９＞となっている。

ところでスケジュールは、フレームＩＤの配列として定義されていると先述したが、フレームに付加するデータＩＤを決定するために、データＩＤの配列としてのスケジュールも記憶しておく必要がある。そして本実施例では、少なくともデータＩＤのスケジュールが定まれば、フレームＩＤのスケジュールも一意に定まるように、両スケジュールの対応関係が定められている。そこで、後述するように、スケジュールの判定において、データＩＤによる方法を採用している。次から、このデータＩＤ及びスケジュールについて具体的に説明する。

図２は、各場面において、各フレームがバス９９に送信される様子を示した図である。各フレームは、データＩＤによって示す。データＩＤ後のカッコ内のＡ・Ｂ・Ｃは、送信主体のＥＣＵを確認的に示すために、エンジンＥＣＵ１０を「Ａ」、ＡＢＳ／ＥＣＵ２０を「Ｂ」、メータＥＣＵ３０を「Ｃ」に置き換えて表記したものである。

図２（ａ）は、通信システム１全体が起動する場面である。まず、各ＥＣＵは起動直後、フレームを送信せずに、受信だけをしようとする。そうすれば、当然どのＥＣＵもフレームを受信しない。そうすると各ＥＣＵは、一定時間フレームを受信しなかったことを根拠として、通信システム１全体の起動時であると判定する（図３の起動処理で詳述）。そして、互いに同期を取った後、起動時スケジュールに従って通信を開始する。起動時スケジュールは、図２（ａ）に示すように、＜１＞→＜２＞→＜３＞を１サイクルとしている。

図２（ｂ）は、起動時スケジュールから通常スケジュールαに切り替わる場面である。切り替えは、エンジンＥＣＵ１０が主導する。具体的には、まず、エンジンＥＣＵ１０が、切り替えを指示する情報をバス９９に送信する。そして、エンジンＥＣＵ１０は、その指示に対しての返事が他のＥＣＵから正常に来たことを確認した後、切り替え後のスケジュールに従って、フレームを送信する。このようにして、起動時スケジュールを終えた後は、三つの通常スケジュールの中から一つが採用されるようになっている。

通常スケジュールαは、＜５＞→＜４＞→＜９＞を１サイクルとしている。よって、図に示すように、起動時スケジュールから通常スケジュールαに切り替わると＜３＞の次に、エンジンＥＣＵ１０が＜５＞を送信する。そして、他のＥＣＵも、通常スケジュールαに従ってフレームを送信する。

図２（ｃ）は、通常スケジュールαの最中に、ＡＢＳ／ＥＣＵ２０が一時停止した場面である。原因としては電圧降下等がある。こうなると、通常スケジュールαにおいてＡＢＳ／ＥＣＵ２０に割り当てられている＜４＞の送信が行われないまま、通信が続けられることになる。

図２（ｄ）は、ＡＢＳ／ＥＣＵ２０が、上記のように一時停止した後に、再起動した場面である。再起動した直後のＡＢＳ／ＥＣＵ２０は、フレームを送信せずに、他のＥＣＵ（エンジンＥＣＵ１０・メータＥＣＵ３０）によって実施されているスケジュールの判定をする（図３の起動処理で詳述）。

図２（ｅ）は、ＡＢＳ／ＥＣＵ２０が、スケジュールの判定後にフレームの送信を再開した場面である。通常スケジュールαと判定したので、それに従って、＜４＞の送信をする。

本発明の特徴は、再起動後のスケジュール判定（図２（ｄ））及びその後の通信復帰（図２（ｅ））にある。また、このようにして通信復帰をするとなると、従来とは異なり「自装置の起動時は通信システム全体の起動時」とみなすことができない。そこで、図２（ａ）の通信システム１全体の起動時においても、スケジュール判定をする必要が出てくる。次から、このスケジュール判定をするための起動処理を図３で説明する。

図３は、起動処理を示すフローチャートである。この処理は、各ＥＣＵのＣＰＵ（エンジンＥＣＵ１０の場合ならＣＰＵ１１０）が、自装置の起動直後に実行するものである。まず、フレームを送信せずに、受信だけをするようにしつつ、初期化をする（Ｓ１１０）。次に、正常なフレームを受信したかを判断する（Ｓ１２０）。受信していないと判断すると（Ｓ１２０ＮＯ）、一回目のＳ１２０の時を起点にして、タイムアウトしたかを判断する（Ｓ１３０）。タイムアウトしていないと判断すると（Ｓ１３０ＮＯ）、Ｓ１２０に戻る。一方、タイムアウトしたと判断すると（Ｓ１３０ＹＥＳ）、起動時スケジュールに従って通信を開始する状態であると判定して（Ｓ１４０）、この処理を終える。そして、起動時スケジュールに従って、通信を開始する。つまり、図２（ａ）で説明した、起動から送信開始までの内容である。

一方、正常なフレームを受信したと判断すると（Ｓ１２０ＹＥＳ）、各サイクルの開始をフレームの先頭に付加されているフレームＩＤから判断する（Ｓ１５０）。具体的には、出現するフレームＩＤの最も小さいフレームの出現時点をサイクルの先頭とする。このフレームＩＤは、スケジュール情報を示すための情報である。ＦｌｅｘＲａｙでは、フレームＩＤはサイクルの先頭から１、２、３…と順番づけられるので、最小のフレームＩＤを含むフレームが先頭のフレームであると判断できる。

フレームＩＤによりサイクルの先頭でないと判断すると（Ｓ１５０ＮＯ）、Ｓ１２０に戻る。一方、フレームＩＤによりサイクルの先頭と判断すると（Ｓ１５０ＹＥＳ）、データＩＤの取得を開始する（Ｓ１６０）。次に３サイクル分のデータＩＤを取得したかを、フレームＩＤに基づいて判断する（Ｓ１７０）。取得していないと判断すると（Ｓ１７０ＮＯ）、一回目のＳ１７０の時を起点にして、タイムアウトしたかを判断する（Ｓ１７５）。タイムアウトしていないと判断すると（Ｓ１７５ＮＯ）、Ｓ１６０に戻る。一方、タイムアウトしたと判断すると（Ｓ１７５ＹＥＳ）、Ｓ１２０に戻る。なお、このようにしてＳ１２０に戻った場合、Ｓ１３０のタイムアウトの起点は、戻った直後のＳ１２０の時点である。

一方、３サイクル分のデータＩＤを取得したと判断すると（Ｓ１７０ＹＥＳ）、判定処理を実行する（Ｓ１８００）。図４は判定処理を示すフローチャートである。まず、取得したデータＩＤに基づいて、サンプリングパターン（図５で後述）を作る（Ｓ１８１０）。次に、何れか一つのスケジュールのテンプレート（図５で後述）をフラッシュＲＯＭ１３０から読み出す（Ｓ１８２０）。

図５（ａ）は通常スケジュールβを示した図である。通常スケジュールβは、２サイクルに一回だけ送信するフレームがある。具体的には、偶数サイクルは＜５＞→空→＜４＞→空→＜９＞、奇数サイクルは＜５＞→＜７＞→＜４＞→＜６＞→＜９＞が１サイクルとなっている。

一方、スケジュールのテンプレートとは、スケジュールと、取得したデータＩＤとを比べることができるように、スケジュールを規格化したものである。具体的には、偶数サイクルと奇数サイクルとの論理和（ＯＲ）を取って、そこから自装置に割り当てられたものを除いてできるものである。これを予め作成すると共にフラッシュＲＯＭ１３０に記憶しておく。

そして、ＡＢＳ／ＥＣＵ２０が記憶する通常スケジュールβ用テンプレートは、＜５＞→＜７＞→空→空→＜９＞となる（図５（ｂ））。通常スケジュールβの場合「偶数サイクルＯＲ奇数サイクル＝奇数サイクル」であり、ＡＢＳ／ＥＣＵ２０には＜４＞・＜６＞が割り当てられているからである。

同じようにして、起動時スケジュール及び通常スケジュールα・γについてもテンプレートを作成・記憶しておく。ただし、起動時スケジュールや通常スケジュールαの場合は、毎サイクル同じなので、論理和を取る必要はない。（通常スケジュールγの具体的な説明は省く。）
一方、サンプリングパターンの作成は、Ｓ１６０で取得したデータＩＤを元にして、テンプレート作成と同じように行う。具体的には、まず、取得したデータＩＤをサイクル毎に配列する。このとき、サイクルの開始を示す信号に挟まれたデータＩＤを、１サイクル分のものとする。そして、テンプレートと簡単に比べられるように、各サイクル同士の論理和を取ることで、１サイクル分に集約する。ただし、テンプレートの作成とは異なり、自装置に割り当てられたデータＩＤを省くことはしない。なぜなら、自装置に割り当てられたデータＩＤは、スケジュール判定の時点で実施されているスケジュールにおいては送信されないはずなので、省く必要がないからである。

このような手順で、Ｓ１８２０で読み出すテンプレートを予め作成すると共に、サンプリングパターン作成をする（Ｓ１８１０）。なお、Ｓ１８２０はスケジュールの数だけ繰り返すステップであり、一度読み出したものを二度は読み出さない。

次に、作成したサンプリングパターンと、直前のＳ１８２０で読み出したテンプレートとを比べて、テンプレートには含まれないのに対して、サンプリングパターンには含まれるデータＩＤがあるかを判断する（Ｓ１８３０）。このようなデータＩＤがあると判断すると（Ｓ１８３０ＹＥＳ）、Ｓ１８２０に戻る。つまり、このようなテンプレートに対応するスケジュールは、スケジュール判定の時点で実施されているスケジュールではないと直ぐに判断できるので、後のステップを省いている。

一方、サンプリングパターンのみに含まれるデータＩＤは無いと判断すると（Ｓ１８３０ＮＯ）、テンプレートとサンプリングパターンとの差を取ると共にＲＡＭ１４０に保持する（Ｓ１８４０）。つまり、サンプリングパターンには含まれないのに対して、テンプレートには含まれるデータＩＤを探す。次に、このようなデータＩＤが無く、差がゼロであるかを判断する（Ｓ１８５０）。差がゼロであると判断すると（Ｓ１８５０ＹＥＳ）、そのテンプレートに対応するスケジュールが、スケジュール判定の時点で実施されているスケジュールであると判定して（Ｓ１８６０）、この処理を終える。

一方、差がゼロではないと判断すると（Ｓ１８５０ＮＯ）、全テンプレート（四つ）を読み出したかを判断する（Ｓ１８７０）。まだ読み出していないと判断すると（Ｓ１８７０ＮＯ）、Ｓ１８２０に戻る。

一方、全テンプレートを読み出したと判断すると（Ｓ１８７０ＹＥＳ）、Ｓ１８４０で算出した差の中で最少（つまりテンプレートのみに含まれるデータＩＤの個数が最少）のテンプレートが複数あるかを判断する（Ｓ１８７５）。つまり、最少のものが一つだけなのか、複数あるのかを判断する。複数あると判断すると（Ｓ１８７５ＹＥＳ）、スケジュールを判定することなく、この処理を終える。なぜなら、このような場合は、スケジュールを一意に判定できないからである。

一方、差が最少のテンプレートは一つしかないと判断すると（Ｓ１８７５ＮＯ）、そのテンプレートの差が閾値未満かを判断する（Ｓ１８８０）。閾値以上と判断すると（Ｓ１８８０ＮＯ）、スケジュールを判定することなく、この処理を終える。なぜなら、このような場合は「差が最少のテンプレートに対応するスケジュールが、スケジュール判定の時点で実施されているスケジュールである」という判定は、信頼できないからである。

一方、閾値未満と判断すると（Ｓ１８８０ＹＥＳ）、そのテンプレートに対応するスケジュールがスケジュール判定の時点で実施されているスケジュールであると判定して（Ｓ１８９０）、この処理を終える。

図３に戻る。判定処理後、「記憶しているスケジュールの何れか一つが、スケジュール判定の時点で実施されているスケジュールであるという判定を判定処理でしたか」を判断する（Ｓ１９０）。判定をしたと判断すると（Ｓ１９０ＹＥＳ）、この処理を終える。そして、判定したスケジュールに従って、通信に参加して、送信フレームの送信を再開する。つまり、図２（ｃ）（ｄ）（ｅ）で説明した内容である。

一方、スケジュールの判定をしていないと判断すると（Ｓ１９０ＮＯ）、Ｓ１２０に戻る。よって、スケジュールを判定しない限り、起動処理を延々と繰り返すことになり、通信に参加することができない。よって「スケジュールが把握できないまま通信に参加して、衝突等を起こす」ことを防いでいる。

効果をまとめる。各ＥＣＵは、一時停止して再起動した後も通信に復帰でき、しかも、衝突を起こしたり、通信速度を低くしたりすることがない。また、複数サイクル分のＩＤの論理和を取ってテンプレートと比べるので、１サイクル分だけ取得する方法とは異なり、「たまたまその時だけフレームが送信されなかった」という理由で、判定を誤ることが少ない。また、スケジュール判定が信頼できない場合は通信に復帰しないので、衝突等を起こす可能性が低い。

変形例を述べる。タイムトリガ方式の他のプロトコル、例えばＬＩＮを用いてもよい。また、Ｓ１５０、Ｓ１８３０、並びにＳ１８５０及びＳ１８６０を省いてもよい。Ｓ１５０を省いた場合は、サンプリングパターン作成（Ｓ１８１０）のときに、先頭を示す信号を初めて受信する以前のデータＩＤを無視する。また、Ｓ１８３０、並びにＳ１８５０及びＳ１８６０は、他のステップを飛ばすことを目的としたものであるので、これらのステップを省けば実行する処理が冗長にはなるが、各処理に対応するプログラムは簡潔になる。

また、テンプレートの形式を変えても良い。図５を用いて説明する。図５（ｃ）（ｄ）（ｅ）は、テンプレートの変形例である。図５（ｃ）は論理和を取り、自装置に割り当てられたデータＩＤを除かないようにしたものである。このようにすると、サンプリングパターンとの差がゼロになることはないので、必然的にＳ１８５０及びＳ１８６０を省くことになる。

図５（ｄ）は、２サイクルをそのままテンプレートにしたものである。この場合のサンプリングパターン作成は、例えば、６サイクル分を取得して、偶数サイクル同士・奇数サイクル同士の論理和を取って行う。

図５（ｅ）は、論理積を取る方法である。毎サイクル送信されるデータＩＤのみが対象となり、そうでないデータＩＤは無視することになる。よって、情報に欠落が出てしまう。しかし、毎サイクル送信されるデータＩＤについては判定が厳しくなるので、より安全になる。つまり、論理和だと一回でも受信すればサンプリングパターンに反映されるのに対して、論理積だと一回でも受信できないとサンプリングパターンに反映されない。よって、テンプレートとの差が大きくなりやすいので、判定が厳しくなる。

また、スケジュール判定ができないことによって、起動処理を延々と繰り返す場合、一定回数繰り返したら、通信への途中復帰を諦めて、エラーメッセージを送信したり、通信システム全体の再起動を促したりしてもよい。

またＳ１７０で、規定時間分のデータＩＤを取得したかを判断するようにしてもよい。この場合は、Ｓ１７５のタイムアウトは省くことになる。またＳ１７０で、データＩＤの個数で判断するようにしてもよい。

また、先頭のフレームを検出する方法は、検出したフレームＩＤからサイクルの先頭を逆算して、サイクルの時間管理に用いるタイマの値を補正する方法でもよい。
また、実施例ではデータＩＤによって定義されるスケジュールを判定したが、フレームＩＤによって定義されるスケジュールを判定するようにしてもよい。両ＩＤは、スケジュールを定義するものであると共に、各フレームに含まれるものなので、どちらを用いてもスケジュール判定は可能である。また、データＩＤを付加しないフレームフォーマットを採用する場合もあるので、この場合は当該変形例が特に有用である。

また、自動車に搭載されるＥＣＵでなくても、通信機能を備える他の装置に適用しても良い。また、スケジュール判定に用いるためのデータＩＤは、実施例ではバスを流れる全てのものを取得したが、記憶しているテンプレートに合わせて一部を取得するようにしても良い。

実施例と特許請求の範囲との対応を説明する。Ｓ１１０〜Ｓ１３０が判断手段、Ｓ１６０／Ｓ１７０が取得手段、Ｓ１２０／Ｓ１４０／判定処理が判定手段、Ｓ１８１０が集約手段、Ｓ１８２０／Ｓ１８４０が算出手段、Ｓ１８８０が検査手段、のソフトウェアに相当する。また、ＥＣＵがノード、データＩＤが識別子およびスケジュール情報、フレームが送信情報、に相当する。

１…通信システム、１０…エンジンＥＣＵ、２０…ＡＢＳ／ＥＣＵ、３０…メータＥＣＵ、９９…バス、１００…マイコン、１１０…ＣＰＵ、１２０…ＣＣ、１３０…フラッシュＲＯＭ、１４０…ＲＡＭ、２００…トランシーバ

Claims (8)

1. 識別子の配列によって定義される複数のスケジュール、及びその複数のスケジュールそれぞれにおいて自身に割り当てられた識別子がどれであるかを記憶しておき、
   前記複数のスケジュールの中から採用されている何れか一つのスケジュールに従って、前記自身に割り当てられた識別子を送信情報の一部としてバスに送信し、
   前記採用されているスケジュールが、前記記憶された複数のスケジュールの範囲内で通信途中に切り替わるノードであって、
   前記採用されているスケジュールが把握できない場合、前記送信情報の前記バスへの送信を禁止する一方で、他ノードによって送信された前記送信情報を前記バスから受信して、その受信した送信情報に含まれる前記識別子を取得する取得手段と、
   前記取得手段によって取得された識別子に基づいて、前記記憶している複数のスケジュールそれぞれに基づいて、前記採用されているスケジュールを判定する判定手段とを備え、
   前記判定手段によって判定されたスケジュールに従って、前記送信情報の送信を開始する
   ことを特徴とするノード。
2. 前記取得手段は、前記スケジュールの複数サイクル分の識別子を取得して、
   前記判定手段は、
   前記取得手段によって取得された複数サイクル分の識別子を取得時刻に従って配列し、その配列を前記スケジュールの１サイクル分に集約する集約手段と、
   前記集約手段によって集約された識別子の配列と、前記スケジュールそれぞれの識別子の配列との差を算出する算出手段とを備えると共に、
   前記算出手段によって算出された差の中で最少のものに対応するスケジュールが、前記採用されているスケジュールであると判定する
   ことを特徴とする請求項１のノード。
3. 前記集約手段は、前記取得手段によって取得された複数サイクル分の識別子を、各サイクル分同士の論理和を取ることで集約する
   ことを特徴とする請求項２のノード。
4. 前記判定手段は、
   前記算出手段によって算出された差の中で最少のものが閾値未満かを検査する検査手段を備えると共に、
   前記検査手段の検査結果が前記閾値未満だと、前記算出手段によって算出された差の中で最少のものに対応するスケジュールが、前記採用されているスケジュールであると判定する一方で、
   前記検査手段の検査結果が前記閾値以上だと、前記採用されているスケジュールを判定しない
   ことを特徴とする請求項２又は請求項３のノード。
5. 互いに通信可能に接続された３つ以上のノードが、切り替え可能なスケジュールに従って送信情報を送信するための通信処理を実行する通信システムに用いられるノードであって、
   前記通信処理を開始する前に、前記通信処理が複数の他ノードによって既に実行されているか否かを判断する判断手段と、
   前記通信処理が複数の他ノードによって既に実行されていると前記判断手段によって判断された場合には、他ノードが従っているスケジュールに関するスケジュール情報を、他ノードによって送信される前記送信情報から取得する取得手段と、
   前記取得手段によって取得されたスケジュール情報に基づいて、他ノードが従っているスケジュールを判定する判定手段とを備え、
   前記判定手段によって判定されたスケジュールに従って前記通信処理を開始する
   ことを特徴とするノード。
6. 前記通信処理が複数の他ノードによってまだ実行されていないと前記判断手段によって判断された場合には、前記通信システム全体の起動時のものとして予め定められたスケジュールに従って前記通信処理を開始する
   ことを特徴とする請求項５のノード。
7. 互いに通信可能に接続された３つ以上のノードが、切り替え可能なスケジュールに従って送信情報を送信するための通信処理を実行する通信システムに用いられるノードであって、
   前記通信処理を中断した後、他ノードによる前記通信処理の継続中に前記通信処理を再開する場合、他ノードが従っているスケジュールに関するスケジュール情報を、他ノードによって送信される前記送信情報から取得する取得手段と、
   前記取得手段によって取得されたスケジュール情報に基づいて、他ノードが従っているスケジュールを判定する判定手段とを備え、
   前記判定手段によって判定されたスケジュールに従って前記通信処理を再開する
   ことを特徴とするノード。
8. ＦｌｅｘＲａｙ（登録商標）によって通信をすることを特徴とする請求項１〜請求項７何れかのノード。

Images