(57)【要約】      （修正有）【課題】費用効果的な高データレート乗物ネットワークの実現。【解決手段】方法は、乗物Ｖにおいて、第１装置１０と一組の第２装置２０とをバス３０を介して結合し、第１装置をマスタ装置として構成してバス上を、第２装置２０ｉによる実行のための動作データメッセージ部分を担持している第１メッセージ及び第２装置へアドレスする、予期されている反応期間内に第１装置に対して夫々の反応を要求する第２装置の識別子を伝達する第２メッセージを送信し、第２装置をスレーブ装置として、マスタ装置から送信される第１メッセージをバス上で受信し、動作データメッセージ部分を読み取り、メッセージ部分の関数として夫々の動作を実行し、マスタ装置として構成されている第１装置から送信される第２メッセージをバス上で受信し且つマスタ装置へ向けて反応メッセージをバス上への送信により予期されている反応期間内に第２メッセージに関して反応させる。【選択図】図１
2019176474.tif 000002
【特許請求の範囲】
【請求項１】
第１装置（１０）と一組の第２装置（２０１，２０２，．．．，２０ｎ）とをバス（３０）を介して結合し、
該第１装置（１０）をマスタ装置として構成して該バス（３０）上を、
ａ）該一組の第２装置（２０１，２０２，．．．，２０ｎ）における第２装置による実行のための動作を表す一組の動作データメッセージ部分を担持している第１メッセージ、及び
ｂ）該一組の第２装置（２０１，２０２，．．．，２０ｎ）における第２装置へアドレスする第２メッセージであって、該第２メッセージがアドレスされて夫々の予期されている反応期間内に該第１装置（１０）に対して夫々の反応を要求する該第２装置（２０１，２０２，．．．，２０ｎ）の夫々のものを識別する識別子を伝達する該第２メッセージ、
を送信し、及び
該第２装置（２０１，２０２，．．．，２０ｎ）をスレーブ装置として構成して、
ｃ）マスタ装置として構成されている該第１装置（１０）から送信される該第１メッセージを該バス（３０）上で受信し、前記一組の動作データメッセージ部分における夫々の動作データメッセージ部分を読み取り、且つ読み取った該夫々の動作データメッセージ部分の関数として夫々の動作を実行し、
ｄ）マスタ装置として構成されている該第１装置（１０）から送信される該第２メッセージを該バス（３０）上で受信し且つマスタ装置として構成されている該第１装置（１０）へ向けて反応メッセージを該バス（３０）上を送信させることにより前記夫々の予期されている反応期間内に該第２メッセージに関して反応させる、
ことを包含している方法。
【請求項２】
マスタ装置として構成されている該第１装置（１０）が、マスタ装置として構成されている該第１装置（１０）から該バス（３０）上を送信される該第１メッセージ内のどの動作データメッセージ部分がスレーブ装置として構成されている該第２装置（２０１，２０２，．．．，２０ｎ）の夫々のものに対して専用であるかを表す初期化データを有する初期化メッセージを該バス（３０）上を送信し、
スレーブ装置として構成されている該第２装置（２０１，２０２，．．．，２０ｎ）が、マスタ装置として構成されている該第１装置（１０）から該バス（３０）上を送信される該初期化メッセージを受信し且つ前記一組の動作データメッセージ部分においてそれに対して専用とされている夫々の動作データメッセージ部分を読み取るために前記初期化データの関数として初期化を行う、
請求項１記載の方法。
【請求項３】
スレーブ装置として構成されている該一組の第２装置（２０１，２０２，．．．，２０ｎ）における前記第２装置を複数の第２装置の複数のサブセットに配置させることを包含しており、その場合にマスタ装置として構成されている該第１装置（１０）は該第１動作メッセージが専用とされている前記第２装置の該サブセットを識別するサブセット識別インデックスを有している第１メッセージを該バス（３０）上を送信する、
請求項１又は２記載の方法。
【請求項４】
マスタ装置として構成されている該第１装置（１０）が一定のレートで該バス（３０）上を前記第１メッセージを送信する、
請求項１乃至３の内のいずれか１項に記載の方法。
【請求項５】
該一組の第２装置（２０１，２０２，．．．，２０ｎ）における第２装置が夫々のウオッチドッグタイマーの満了の結果としてフェイルセーフモードにスイッチする、
請求項１乃至４の内のいずれか1項に記載の方法。
【請求項６】
該一組の第２装置（２０１，２０２，．．．，２０ｎ）における第２装置が、マスタ装置として構成されている該第１装置（１０）から、前記第１メッセージ及び前記第２メッセージの内から選択されるメッセージを受信することの結果として、前記夫々のウオッチドッグタイマーをリセットさせる、
請求項５に記載の方法。
【請求項７】
該第１装置（１０）が、
該一組の第２装置（２０１，２０２，．．．，２０ｎ）における第２装置から要求される夫々の反応が前記夫々の予期されている反応期間内に該第１装置（１０）へ到達しないことに対して感応し、及び／又は
該一組の第２装置（２０１，２０２，．．．，２０ｎ）における第２装置からの夫々の反応が前記夫々の予期されている反応期間内に該第１装置（１０）へ到達しないことを表す夫々のウオッチドッグエラー信号をトリガする、
請求項１乃至６の内のいずれか１項に記載の方法。
【請求項８】
前記バス（３０）が差動配線バスを有している、
請求項１乃至６に記載の方法。
【請求項９】
第１装置（１０）とバス（３０）を介して結合されている一組の第２装置（２０１，２０２，．．．，２０ｎ）とを有しており、該第１装置（１０）及び該第２装置（２０１，２０２，．．．，２０ｎ）が、夫々、マスタ装置及びスレーブ装置として構成されており、該マスタ装置及び該スレーブ装置が請求項１乃至８の内のいずれか１項に記載の方法で動作すべく構成されている、システム。
【請求項１０】
バス（３０）を介して一組の第２装置（２０１，２０２，．．．，２０ｎ）へ第１装置として結合させる装置（１０）において、該第１装置は該バス上を、
該一組の第２装置（２０１，２０２，．．．，２０ｎ）における第２装置による実行のための動作を表す一組の動作データメッセージ部分を担持している第１メッセージ、及び
該一組の第２装置（２０１，２０２，．．．，２０ｎ）における第２装置に対してアドレスされている第２メッセージであって、夫々の予期されている反応期間内に該第１装置（１０）に対して夫々の反応を要求し、該第２メッセージがアドレスされる該第２装置（２０１，２０２，．．．，２０ｎ）の夫々のものを識別する識別子を伝達する該第２メッセージ、
を送信させる構成とされている装置（１０）。
【請求項１１】
該装置は、
該一組の第２装置（２０１，２０２，．．．，２０ｎ）における第２装置から要求される夫々の反応が前記夫々の予期されている反応期間内に該第１装置（１０）へ到達しないことに感応し、及び／又は
該一組の第２装置（２０１，２０２，．．．，２０ｎ）における第２装置からの夫々の反応が前記夫々の予期されている反応期間内に該第１装置（１０）へ到達しないことを表す夫々のウオッチドッグエラー信号をトリガさせる構成とされている、
請求項１０に記載の装置（１０）。
【請求項１２】
バス（３０）を介して第１装置（１０）へ結合されている一組の第２装置（２０１，２０２，．．．，２０ｎ）内に包含させるための装置（２０ｉ）において、該装置が、
該一組の第２装置（２０１，２０２，．．．，２０ｎ）における第２装置による実行のための動作を表している一組の動作データメッセージ部分を担持している第１メッセージを該バス（３０）上で受信し、前記一組の動作データメッセージ部分における少なくとも一つの夫々の動作データメッセージ部分を読み取り、且つ読み取った該少なくとも一つの夫々の動作データメッセージ部分の関数として少なくとも一つの夫々の動作を実行し、
前記夫々の第２メッセージがアドレスされる該第２装置（２０１，２０２，．．．，２０ｎ）の内の該一つとして該装置を識別する識別子を伝達する夫々の第２メッセージであって夫々の予期されている反応期間内に該第１装置（１０）に対する夫々の反応を該装置から要求する該夫々の第２メッセージを該バス（３０）上で受信し、且つ前記夫々の予期されている反応期間内にそれについて反応し、その場合に前記装置からの反応メッセージがマスタ装置として構成されている該第１装置（１０）へ向けて該バス（３０）上を送信される装置（２０ｉ）。
【請求項１３】
夫々のウオッチドッグタイマーの満了の結果としてフェイルセーフ状態へスイッチする構成とされている請求項１２に記載の装置（２０ｉ）。
【請求項１４】
前記バス（３０）を介して前記第１装置（１０）から受信したメッセージの結果として前記夫々のウオッチドッグタイマーをリセットさせる構成とされている請求項１３に記載の装置（２０ｉ）。
【請求項１５】
その中に実現されている応用特定ハードウエアを具備しているＨＷ通信及びプロトコルコントローラ（２０１）を有している請求項１２乃至１４の内のいずれか１項に記載の装置（２０ｉ）。
【請求項１６】
好適には乗物ライトドライバ（２０１，２０２，．．．，２０ｎ）であるライト照射供給源ドライバを有している請求項１２乃至１５の内のいずれか１項に記載の装置（２０ｉ）。
【請求項１７】
請求項９に基づくシステムを具備している乗物（Ｖ）。
【請求項１８】
請求項９に基づくシステムにおいて第１装置（１０）から一組の第２装置（２０１，２０２，．．．，２０ｎ）へメッセージを送信するためにバス（３０）上を送信可能な信号において、該信号が、
ａ）該一組の第２装置（２０１，２０２，．．．，２０ｎ）における第２装置による実行のための動作を表す一組の動作データメッセージ部分を担持している第１メッセージ、及び
ｂ）該一組の第２装置（２０１，２０２，．．．，２０ｎ）における第２装置に対してアドレスされている第２メッセージであって、夫々の予期されている反応期間内に該第１装置（１０）に対して夫々の反応を要求し、該第２メッセージがアドレスされている該第２装置（２０１，２０２，．．．，２０ｎ）の夫々のものを識別する識別子を伝達する該第２メッセージ、
を包含している信号。
【請求項１９】
スレーブ装置として構成されている該第２装置（２０１，２０２，．．．，２０ｎ）に対して専用とされている一組の動作データメッセージ部分を担持している前記第１メッセージが一定のレートで発生する請求項１８に記載の信号。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば自動車適用例において使用するための、バスサポート型通信に関するものである。
【０００２】
例えば、一つ又はそれ以上の実施例は乗物のライト（例えば、前部ライト、後部ライト、室内ライト）の電子制御ユニット（ＥＣＵ）と対応するライティングモジュール（例えば、ＬＥＤライトモジュール）との間の通信へ適用させることが可能である。
【背景技術】
【０００３】
例えば自動車分野においての種々の適用例は、一つ又はそれ以上のバスネットワーク上でのデータの交換が関与する。高データレート、堅牢性、欠陥検知、安全性、及び低コストがこの様な適用例に対して望ましい特徴である。
【０００４】
既存の高データレート（例えば、１Ｍｂ／ｓ）の標準化された乗物通信システムは、外部部品を使用する複雑且つ正確なプロトコル制御器が関与する場合がある。これらは高価なものとなる場合があり、特に単一チップアナログ／バイポーラ応用特定集積回路（ＡＳＩＣ）及び／又は応用特定標準製品（ＡＳＳＰ）として実現される場合にはそうである。
【０００５】
乗物のライト（例えば、前部ライト、後部ライト、室内ライト）は益々洗練化され且つ分散化（例えば、マトリックスＬＥＤ，アンビエントＬＥＤ）されてきている。この様な洗練化され且つ分散化されたシステムを制御することは、高データレート制御が関与する場合がある。更に、特に前部及び後部のライティングシステムに対しては、オートモーティブグレイドの安全性と堅牢性とが望ましい。
【０００６】
ＬＥＤドライバは、例えばバイポーラ−ＣＭＯＳ−ＤＭＯＳ（ＢＣＤ）技術などの単一チップ技術を使用する場合には、費用効率的である場合がある。そうでない場合には、例えばＢＣＤ技術を使用する高データレートプロトコル制御器は高価なものであり且つ正確なクロック供給源（クリスタル）に依存するものとなる。
【０００７】
堅牢性を容易とさせるためにクロック信号及びデータ信号に対して差動配線を採用することが可能であるが、そのことはワイヤ「ハーネス」コストを増加させる場合がある。
【０００８】
従って、例えばＬＥＤマトリクスなどの分散型照明光源を駆動するために乗物における通信ネットワークの増加する複雑性は、生産コストを増加させることとなる場合があり、そのことは自動車業界におけるビジネスモデルと殆ど適合性のないものである場合がある。
【０００９】
一つ又はそれ以上の実施例は、例えば、ＣＡＮ（コントローラエリアネットワーク）バスに対して適用可能である。これは、ホストコンピュータ無しで、乗物に搭載されている装置と例えばマイクロコントローラとの間の通信を容易化させることが可能な公知の取り決めである。ＣＡＮバスの動作は、例えばＩＳＯ１１８９８−２：２０１５及びＩＳＯ１１８９８−２：２０１６等のスタンダードにおいて取り扱われているようにメッセージに基づくプロトコルに基づくものとすることが可能である。
【先行技術文献】
【非特許文献】
【００１０】
【非特許文献１】ＩＳＯ１１８９８−２：２０１５及びＩＳＯ１１８９８−２：２０１６
【発明の概要】
【発明が解決しようとする課題】
【００１１】
この分野における広範な活動にも拘わらず、更に改良された解決手段が望まれている。
【００１２】
例えば、堅牢性、欠陥検知、及び安全性の観点で自動車の条件に適合する分散型ＬＥＤ光源を駆動するための費用効果的な高データレート乗物ネットワークを実現することなどを容易化させることが可能な解決手段が望まれている。同様の解決手段は、又、例えば、生産オートメーションシステム等における実施のための高データレートネットワークの実現化を容易化させることが可能である場合がある。
【課題を解決するための手段】
【００１３】
一つ又はそれ以上の実施例の一つの目的はこのような改良された解決手段を提供することに貢献することである。
【００１４】
一つ又はそれ以上の実施例によれば、この様な目的は以下の特許請求の範囲に記載される特徴を具備する方法によって達成させることが可能である。
【００１５】
一つ又はそれ以上の実施例は、対応するシステムに関連する場合がある。
【００１６】
一つ又はそれ以上の実施例は、例えば一緒に動作することが意図されている送信機と受信機（インターフェース）等の対応する装置に関連する場合がある。
【００１７】
一つ又はそれ以上の実施例は、対応する信号に関連する場合がある。
【００１８】
一つ又はそれ以上の実施例は、例えば自動車等の動力車等の対応する乗物に関連する場合がある。
【００１９】
特許請求の範囲は、実施例に関連して本書で提供される技術的教えの一体的な部分である。
【００２０】
一つ又はそれ以上の実施例は、例えば電子制御装置（ＥＣＵ）とＬＥＤライトモジュール等のライティングモジュールとの間の通信用の通信ネットワークを実現するために適切なハードウエア解決手段を提供することが可能である。
【００２１】
一つ又はそれ以上の実施例は、自動車適用例において使用することが可能なマスタ−スレーブ通信バスインターフェースを実現することが可能である。
【００２２】
自動車適用例において使用するためのこの様な通信バスインターフェースは、乗物におけるライトモジュール（「ＣＡＮ  ＦＤ  ライト」）を駆動するための標準化されているＣＡＮ  ＦＤ（フレキシブルデータレート）プロトコルに依存することが可能である。
【００２３】
一つ又はそれ以上の実施例は、例えばオートメーションシステム等の非自動車適用例において使用するための標準化ＣＡＮ  ＦＤネットワーク以外のネットワーク技術に依存することが可能である。
【００２４】
例えば、一つ又はそれ以上の実施例は差動バス配線を使用することが可能であり且つ同期目的のための定義されたエッジ密度（例えば、各１０個のビットに対しての一つのリセッシブからドミナントへのエッジ）を提供することが可能である。
【００２５】
一つ又はそれ以上の実施例は、安全性の理由のために巡回冗長検査（ＣＲＣ）及びエラーチェックを実施することが可能である。
【００２６】
一つ又はそれ以上の実施例において、データ交換はマスタ−スレーブスキームに依存することが可能であり、その場合には、スレーブである「サテライト」はマスタ装置からの要求に依存して（のみ）で通信バスを介してデータを送信する。この様な動作スキームは、通常動作が衝突を回避することを意図することが可能である場合には、衝突をエラーとして処置する衝突解決特徴が関与しない場合がある。
【００２７】
一つ又はそれ以上の実施例において、通信バスの通常動作は、マスタがスレーブへ（定期的に）データを送信することに関与する場合がある。この様な（定期的な）データストリームは、一種のネットワーク「ハートビート」又はウオッチドッグとしてスレーブによって使用することが可能である。定義されている時間スロット内に定期的なデータストリームが受信されない場合には、スレーブはフェイルセーフ（又はリンプホーム）モードに入ることが可能である。
【００２８】
一つ又はそれ以上の実施例において、スレーブからの診断データ等のデータは、例えば専用のコマンドフレームを使用することにより、マスタにより要求することが可能である。或るアドレスされたスレーブはこの様な要求に対して或る時間フレーム内に反応することが可能である。この様な反応はスレーブの利用可能性を検出するためにマスタによって使用することが可能である。
【図面の簡単な説明】
【００２９】
【図１】実施例の可能な実現例の概略図。
【図２】実施例におけるマスタ装置の可能な実現例の概略図。
【図３】実施例におけるスレーブ装置の可能な実現例の概略図。
【図４】実施例の可能な動作の例示的概略図。
【図５】「ブロードキャスト」フレームを管理する実施例の可能な動作の例示的ブロック図。
【図６】「診断」フレームを管理する実施例の可能な動作の例示的ブロック図。
【図７】「エラー」フレームを管理する実施例の可能な動作の例示的ブロック図。
【図８】実施例におけるマスタ通信サイクルの可能な実現例の例示的ブロック図。
【図９】実施例におけるスレーブ通信サイクルの可能な実現例の例示的ブロック図。
【発明を実施するための形態】
【００３０】
以下の記載において、この記載の実施例の例示の深い理解を与えることを目的として一つ又はそれ以上の特定の詳細が例示される。実施例は、その特定の詳細の内の一つ又はそれ以上無しで、又はその他の方法、部品、物質等と共に、実現することが可能である。その他の場合には、実施例の或る側面がぼやかされることがないように、公知の構造、物質、又は動作は詳細には例示するか又は記載するものではない。
【００３１】
本記載の枠組みにおいての「一つの実施例」又は「１個の実施例」との言及は、その実施例に関連して記載される特定の形態、構造、又は特性が少なくとも一つの実施例において構成されていることを表すことを意図している。従って、本記載の一つ又はそれ以上のポイントにおいて存在することのある「一つの実施例において」又は「１個の実施例において」という表現は必ずしも一つ且つ同一の実施例を言及するものではない。更に、特定の形態、構造、又は特性は、一つ又はそれ以上の実施例において任意の適宜の態様で結合させることが可能である。
【００３２】
本書において使用されている文献は単に便宜上提供されているに過ぎず、保護範囲又は実施例の範囲を定義するものではない。
【００３３】
注記した如く、一つ又はそれ以上の実施例は、自動車適用例において使用することが可能な「堅牢な」マスタ−スレーブバスインターフェースを提供することを意図している場合がある。
【００３４】
一つ又はそれ以上の実施例は、標準化されているＣＡＮ  ＦＤ物理的インターフェース及びプロトコルに依存することが可能であり且つ同期目的のために或るエッジ密度を提供しながら差動バス配線を使用することが可能である。
【００３５】
一つ又はそれ以上の実施例は、安全性順守のために循環冗長検査（ＣＲＣ）及びエラーチェックを実現することが可能である。
【００３６】
図１の図面は構成の例示的概略図であり、そこでは、第１装置１０と例えば乗物Ｖに搭載されている一組の第２装置２０１，２０２，．．．，２０ｎ，とがバス３０を介して結合されている。例えば、バス３０は差動バスとすることが可能である。ＣＡＮバスはこの様な可能な差動バスの一例である。
【００３７】
図１に例示されるようなこの様な構成において、第１装置１０は一組の動作データメッセージ部分を担持する「第１」メッセージをバス３０上を送信し、且つ該一組の第２装置２０１，２０２，．．．，２０ｎにおける夫々の第２装置は該第１メッセージ中においてそれらにアドレスされているそれぞれの動作データメッセージ部分を識別して夫々の動作を実行することによってそれらに反応する。
【００３８】
図１に例示されている如く、一つ又はそれ以上の実施例は、例えばＬＥＤクラスタ（例えば乗物の複数のライト）を駆動するために、ローカル通信バスネットワークへ適用することが可能である。この様なバスネットワークが標準ＣＡＮ  ＦＤネットワークと適合性がある場合には、それらは本書においては「ＣＡＮ  ＦＤライト」ネットワークとして言及される。
【００３９】
そうでない場合には、この様な可能な適用例に対する言及は単に例示的な目的のためのみであって、実施例を制限するものとして解釈されるべきものではない（間接的にであっても）ことが理解される。
【００４０】
例えば、図１に例示されているような通信システムは、乗物の前部ライト即ち前灯及び／又は車内ライト即ち室内灯用のドライバと共に使用することも適切である場合がある。
【００４１】
それらがマスタ−スレーブアーキテクチャに依存することが可能である限り、任意のその他のタイプのＥＣＵ及びドライバ（必ずしも乗物内であることはない）と共に使用するために同様の通信システムが適している場合がある。
【００４２】
図１は、マスタ装置１０、例えば乗物における後部ライトにおけるＬＥＤクラスタ用の電子制御ユニット（ＥＣＵ）、を有する実施例に基づくシステムの例である。
【００４３】
再度強調しておくが、この様な可能な適用例に対する参照は単に例示目的のためであって、実施例を制限するものとして解釈されるべきものではない（例え間接的にであっても）。
【００４４】
一つ又はそれ以上の実施例は、複数個の「サテライト」即ちスレーブ装置２０１，２０２，．．．，２０ｎ、例えば通信バス３０を介して該マスタ装置と通信する（リニア）ＬＥＤ駆動回路、を包含することが可能である。
【００４５】
一つ又はそれ以上の実施例において、マスタ装置１０及びスレーブ装置２０１，２０２，．．．，２０ｎの両方に電源４０、例えば乗物内に設けられているバッテリ、から電力を供給させることが可能である。
【００４６】
一つ又はそれ以上の実施例において、該マスタ装置１０及びスレーブ装置２０１，２０２，．．．，２０ｎを異なるグラウンド即ち接地へ参照させることが可能である。
【００４７】
図１に例示されている如きマスタ装置１０は、以下の部品、即ち、
−メイン（例えば、「バック」）コンバータ１０１、
−オプションの（例えば、再度「バック」）コンバータ１０２、
−低ドロップアウト（ＬＤＯ）リニア電圧レギュレータ、スタンドバイ、リセット及びウィンドウ、及びウオッチドッグ回路ブロック１０３、
−電圧スーパーバイザ、電力良好、オシレータ及びイネーブル回路ブロック１０４、
−マイクロコントローラ１０６、
該乗物内に搭載されている可能性のあるその他のＥＣＵと通信するためのトランシーバ回路１０５（例えば、ＬＩＮ２．２／ＨＳ−ＣＡＮトランシーバ）、及び、
−該乗物内に設けられているその他のＥＣＵと通信するためにトランシーバ１０５へ接続されている外部通信バス１０７に対するアクセスポイント、
の内の一つ又はそれ以上を有することが可能である。
【００４８】
一つ又はそれ以上の実施例において、マイクロコントローラ１０６はメインコンバータ１０１から及び／又はオプションのコンバータ１０２から供給させることが可能である。マイクロコントローラ１０６は回路ブロック１０３と及びトランシーバ１０５と結合させることが可能であり、且つ通信バス３０との通信及び／又は共同作業のために適合させることが可能である。
【００４９】
以下に説明する側面に対するもの以外、マスタ装置１０に対するこの様なアーキテクチャは従来技術であり、従って本書においてより一層詳細な説明を提供することを不必要としている。
【００５０】
一つ又はそれ以上の実施例において、装置１０の「マスタ」機能性は、マイクロコントローラ１０６及びＣＡＮ  ＦＤトランシーバ（図１には示されていない）内に埋め込まれているプロトコルコントローラを使用して実現させることが可能である。
【００５１】
例えば、本書において例示されているような一つ又はそれ以上の実施例において、マスタ１０はバス通信を取り扱うマイクロコントローラ（μＣ）である。この様なマイクロコントローラは、ソフトウエアの介入無しでＣＡＮ  ＦＤプロトコルを取り扱うことが可能な埋込型ＣＡＮ  ＦＤプロトコルコントローラを使用することが可能である。このことは、マイクロコントローラコアの資源を占有することとなり且つ不所望に遅いこととなる場合があるようなＳＷを介して異なるコントローラを稼働させることと比較して望ましい選択である場合がある。従って、一つ又はそれ以上の実施例は、ＣＡＮ  ＦＤメッセージを送信し且つそれらのコンテントをソフトウエアで制御することで既存のハードウエアプロトコルコントローラを再使用することを容易化させる。
【００５２】
一つ又はそれ以上の実施例において、スレーブ装置２０はＢＣＤ技術を使用するＬＥＤドライバとして実現させることが可能である。
【００５３】
一つ又はそれ以上の実施例において、通信バス３０上のデータ交換はマスタ−スレーブスキームに依存することが可能であり、その場合に、スレーブ２０１，２０２，．．．，２０ｎは、マスタ装置１０からの要求があると、通信バス３０（のみ）を介してデータを送信することが可能である。
【００５４】
注記したように、一つ又はそれ以上の実施例において、
−この様な動作スキームは、通常動作が衝突を回避することを意図することが可能である限り、衝突をエラーとして処理することで、衝突解消特徴が関与するものではない場合があり、
−通信バス３０の通常動作は、マスタ１０がスレーブ２０１，２０２，．．．，２０ｎへデータを定期的に（即ち、定義されている時間間隔で）送信し、この様なデータは（全ての）スレーブ２０１，２０２，．．．，２０ｎによって受信されるということが関与する場合がある。この様な定期的なデータストリームは該スレーブによってネットワーク「ハートビート」又はウオッチドッグとして使用することが可能である。この定期的なデータストリームが定義されている時間スロット内に受信されないことの結果として、該スレーブはフェイルセーフ（又はリンプホーム）モードに入ることが可能である。
【００５５】
一つ又はそれ以上の実施例において、スレーブ２０１，２０２，．．．，２０ｎからの診断データ等のデータが、例えばバス３０上をマスタ１０によって送信される「第２」メッセージ等の専用コマンドフレームを使用することによってマスタ１０によって要求される場合がある。或る（一つの）アドレスされたスレーブ２０ｉが反応することが可能であり、例えば或る時間フレーム内に該マスタによって発行された要求に応答することが可能である。この様なバスネットワーク３０を介してスレーブ２０ｉによって送信される応答は、スレーブ２０ｉの利用可能性及び／又は正しい動作を検知するためにマスタ１０によって使用することが可能である。
【００５６】
次のことが理解される、即ち、
−ここで議論される第１メッセージは、基本的に、例えばＣＡＮバスプロトコル等のメッセージを基礎としたプロトコルにおいて従来送信されているブロードキャストメッセージに対応するものであり、ＣＡＮバスプロトコルにおいては、一つの装置によってバス上を送信されるメッセージは（全ての）その他の装置によって（同時的に）受信され、これらのメッセージを受信した装置はこの様なブロードキャストメッセージによって伝達される動作データ部分の関数として夫々の動作を実行することが可能であり、
−一つの（マスタ）装置によってバス上を所謂「物理的に」ブロードキャストされる一方、該第２メッセージは、実際には、基本的には要求メッセージとしてその他の（スレーブ）装置の個々のものへ「論理的に」アドレスされ、それにより、該スレーブ装置は、例えば診断メッセージ等の夫々の応答を−或る時間間隔（期間）内に−該マスタ装置へ向けて送信することによって反応することが要求され、該マスタ装置が該夫々のスレーブ装置に対して夫々の非衝突性応答間隔（期間）を割り当てる限りにおいてこの様な応答の可能な衝突は回避されることとなる。
【００５７】
更に注意すべきことであるが、本記載の枠組みにおいて、「フレーム」及び「メッセージ」の両方の用語は通信バス３０における参加者間で交換されるメッセージを表すために使用される場合がある。
【００５８】
一つ又はそれ以上の実施例において、該通信プロトコルは、ビットレートスイッチング無しで且つ標準ＩＤ有りでＣＡＮ  ＦＤフォーマットフレーム（のみ）を使用することが可能である。
【００５９】
拡張型ＩＤをサポートする等の拡張、古典的ＣＡＮフレーム又はビットレートスイッチングをオプションとして包含させることが可能である。実現例によってサポートされていないフレームは無視することが可能であり、これらの動作モードを変えるために意図されているビットはそれらの固定値に維持される。
【００６０】
図２は、幾つかの実施例に基づくマスタ装置１０の可能な実現例の例示的ブロック図である。
【００６１】
本書に添付した図にわたって、同様の部品又は要素は同様の参照／番号で表してあり、且つ対応する記載は簡潔性のために反復されることはない。
【００６２】
従って、図２はマスタ装置１０を示しており、それは、
−通信バス３０、例えばＣＡＮバス、へのアクセスポイント、
−第２通信バス１０７へのアクセスポイント、
−通信バス１０７との共同のためのトランシーバ回路１０５、
−通信バス３０との共同のための例えばＣＡＮ  ＦＤトランシーバ等のトランシーバ回路１０８、
−例えばＣＡＮ  ＦＤプロトコルコントローラ等の（ＨＷ及び／又はＳＷ）通信プロトコルコントローラ１０６２と、例えば「ＣＡＮ  ＦＤライト」プロトコル拡張などの通信プロトコル拡張（例えば、ＳＷ）１０６１と、及び可能性としてその他の回路ブロック１０６３とを包含しているマイクロコントローラ１０６、
を具備することが可能である。
【００６３】
一つ又はそれ以上の実施例において、本書において例示されるように、ＣＡＮ  ＦＤライトプロトコルのマスタ側を実現するために、付加的なＣＡＮ  ＦＤプロトコル拡張１０６１がＣＡＮ  ＦＤプロトコルコントローラ１０６２を制御することが可能である。
【００６４】
一つ又はそれ以上の実施例において、バス３０の物理的インターフェースへのアクセスは、そうでなければ従来のＣＡＮ  ＦＤトランシーバ１０８を使用することによって与えることが可能である。
【００６５】
図３は、幾つかの実施例に基づくスレーブ装置２０ｉの可能な実現例の例示的ブロック図である。
【００６６】
図３に例示されるように、スレーブ装置２０ｉは、
−例えば「ＣＡＮ  ＦＤライト」通信及びプロトコルコントローラ等の通信及びプロトコルコントローラ回路２０１、
−メモリエリア２０２、
−通信バス３０との共同のための例えばＣＡＮ  ＦＤトランシーバ等のトランシーバ２０３、及び
−可能性としてのその他のＥＣＵ回路ブロック２０４、
を具備することが可能である。
【００６７】
以下に説明する側面に対するもの以外、スレーブ装置２０ｉについてのこの様なアーキテクチャは従来技術であり、従って本書で一層詳細な記載を提供することは必要ではない。
【００６８】
例えば、一つ又はそれ以上の実施例において、通信及びプロトコルコントローラ回路２０１の実現は、ソフトウエアを稼働させるための埋込プロセッサの必要性を減少させるために応用特定ハードウエアによるものとすることが可能である。
【００６９】
一つ又はそれ以上の実施例において、通信及びプロトコルコントローラ回路２０１は、データビットの発生及びサンプリングに使用するために正確なオシレータ（図３中には不図示）を有する場合がある。
【００７０】
図４は、例えばＣＡＮ  ＦＤライト通信及びプロトコルコントローラ回路等の通信及びプロトコルコントローラ回路２０１の可能な動作を例示する概略図である。
【００７１】
図４に例示されるような通信及びプロトコルコントローラ２０１は、
−通信コントローラ２０１０、
−送信機回路２０１２と、送信エラーカウンタ（ＴＥＣ）回路２０１３と、受信機回路２０１４と、受信エラーカウンタ（ＲＥＣ）回路２０１５とを有するプロトコルコントローラ２０１１、及び
−オプションとして電圧、プロセス及び温度の補償型及び／又は対応的にトリム型のオシレータ２０１６、
を有している。
【００７２】
一つの又はそれ以上の実施例において、送信機回路２０１２及び／又は受信機回路２０１４は、バス３０上での通信のために、例えばＣＡＮ  ＦＤトランシーバ等のトランシーバ２０３と共同すべく構成することが可能である。
【００７３】
一つ又はそれ以上の実施例において、送信機回路２０１２は、フレーム準備（２０１２ａ）、ビットスタッフィング（２０１２ｂ）、ＣＲＣ挿入（２０１２ｃ）、フレームエラーチェック（２０１２ｄ）、エラーカウンティング（２０１２ｅ）、及びアクノレッジ（２０１２ｆ）を実施する構成とすることが可能である。
【００７４】
一つ又はそれ以上の実施例において、受信機回路２０１４は、ビットデコーディング（サンプリング−２０１４ａ）、エラー検知（２０１４ｂ）、ビットデスタッフィング（２０１４ｃ）、ＣＲＣ検証（２０１４ｄ）、及びアクノレッジ発生（２０１４ｅ）を実施する構成とすることが可能である。
【００７５】
一つ又はそれ以上の実施例において、通信コントローラ２０１０は、通信を制御するために、夫々、プロトコルコントローラ２０１１へデータを送信し、該プロトコルコントローラ２０１１から、夫々、データを受信することが可能である。
【００７６】
一つ又はそれ以上の実施例において、ＣＡＮ  ＦＤを基礎とした通信バス３０に対してマスタ−スレーブアーキテクチャを適用することは、ＣＡＮ  ＦＤプロトコルの利点（例えば、高データレート、堅牢な差動信号処理、安全性目的のためのＣＲＣ）を享受する可能性を与えると共に、その欠点である例えばマルチラテラル通信のための正確なクロックタイミング（例えば、仲裁、エラー信号処理、すべてのＥＣＵによるフレームチェックのため）の必要性、高い複雑性、及び中央通信マスタの不存在に起因する保証された通信スロットの不存在等の欠点を解消している。
【００７７】
本書に例示するような一つ又はそれ以上の実施例において、高い帯域幅（例えば、５００ｋｂ／ｓ、好適には１Ｍｂ／ｓ）を使用することが可能であり、且つ通信はＡＳＩＬ  Ｂ（自動車安全完全性レベルＢ）安全性条件に対するチェックを関与させることが可能である。例えば、この様な安全性条件を充足することは、各データフレームと共に送信されるＣＲＣ値によって容易化させることが可能である。
【００７８】
本書に例示するような一つ又はそれ以上の実施例において、例えばバス３０上をマスタ１０によって送信される「第１」メッセージ等のデータフレームを受信することの結果として、受信者（スレーブ２０１，２０２，．．．，２０ｎ）は「アクノレッジ（acknowledge）」ビットを送信し、従ってシステムが正しく動作している場合には少なくとも１個のアクノレッジビットが送信者（マスタ１０）によって受信されることとなる。
【００７９】
従って、スレーブ２０１，２０２，．．．，２０ｎから少なくとも１個のアクノレッジビットを受信することの結果として、マスタ１０はそれが未だにバスネットワーク３０へ結合されていることを検知することが可能である。バスネットワーク３０の参加者は同じワイヤ即ち配線へ接続されているので、送信機はそれが正しく動作していないかを検知することが可能であり、且つその結果、バス通信を妨げることがないように「受動的」状態に入ることが可能である。
【００８０】
一つ又はそれ以上の実施例において、受動的（例えば、リセッシブ（recessive））状態にあるバスネットワーク３０の参加者はバス差動電圧の値を検知することが可能であるが、バスを駆動することが可能ではない場合があり、即ち、バス差動電圧の或る値を強制することができない場合がある。
【００８１】
一つ又はそれ以上の実施例において、複数の受信機回路において個別的にデータサンプリングクロックを発生させることが可能である。従って、データストリームの最小エッジ密度が有益的であり、例えば少なくとも各例えば１０番目ビット毎のリセッシブからドミナントへのエッジがある場合であり、従って受信機回路のデータストリームへの同期を容易化させることとなる。
【００８２】
一つ又はそれ以上の実施例において、差動バスネットワークは低コストでの「堅牢な」データ転送を容易化させる。一つ又はそれ以上の実施例において、ネットワーク上のウエイクアップも実現することが可能であり、且つスレーブ２０１，２０２，．．．，２０ｎは、ＩＳＯ１１８９８−２：２０１５スタンダードに従ってウエイクアップパターン（ＷＵＰ）を使用して、例えばフィルタ時間Ｔｆｉｌｔｅｒ（ショート）を使用して、ウエイクアップさせることが可能である。
【００８３】
従って、一つ又はそれ以上の実施例は、例えば１Ｍｂ／ｓにおいて、適合性の理由に対するビットレートスイッチング無しで、従来のＣＡＮ  ＦＤプロトコルを利用することが可能である。従って、従来のＣＡＮ  ＦＤプロトコルのサブセットの特徴（のみ）（ビットレートスイッチング特徴を実行せずに）を（そうでなければ従来のＣＡＮ  ＦＤプロトコルコントローラにおいて）実行することによって適合性を探求することが可能である。
【００８４】
本書に記載するような通信ネットワークは、概念的に、任意のＣＡＮ及び／又はＣＡＮ  ＦＤプロトコル「フレイバー（flavors）即ち風味」と共に使用するのに適している。
【００８５】
例えば、本書に例示されるような一つ又はそれ以上の実施例において、
−例えば各フレームのデータペイロードを増加させるために（例えば、フレーム当たり最大で６４バイトまで）、拡張型ＩＤに訴える必要性なしに、ＣＡＮ  ＦＤベースフレームフォーマット（ＦＢＦＦ）（のみ）を使用することが可能であり、
−制御フィールド内のビットを固定し且つ拡張型ＩＤ（ＥＩＤ，ＩＤＥビットは常にドミナント）、ビットレートスイッチ（ＢＲＳ，常にドミナント）及びエラー状態表示（ＥＳＩ，常にドミナント）をサポートさせる必要性無しに、一つのフレームフォーマット（ＦＢＦＦ）（のみ）をサポートすることが可能であり、例えばＦＤフレーム（ＦＤＦ）を（定常的に）リセッシブへセットすることが可能である。
【００８６】
一つ又はそれ以上の実施例において、一つ（のみ）のフレームフォーマット、例えばＣＡＮ  ＦＤベースフレームフォーマット、をサポートすることは、一層簡単な実現例となる場合があり且つコスト低下を容易化させる場合がある。
【００８７】
ＣＡＮ  ＦＤベースフレームフォーマットにおけるデータフィールドは最大で６４バイトの長さとすることが可能である。データバイト数に依存して、ＣＲＣ１７又はＣＲＣ２１のいずれかを計算することが可能である。一つ又はそれ以上の実施例において、一つ（のみ）のＣＲＣデリミタビットを送信し且つ受け付けることが可能である。
【００８８】
一つ又はそれ以上の実施例において、ネットワーク参加者２０は、受信エラーカウンタ（ＲＥＣ）２０１５及び送信エラーカウンタ（ＴＥＣ）２０１３を有することが可能である。
【００８９】
一つ又はそれ以上の実施例において、ネットワーク参加者２０１，２０２，．．．，２０ｎの中のネットワーク参加者２０ｉにおける受信エラーカウンタ２０１５が或るスレッシュホールドに到達した結果として、ネットワーク参加者２０ｉの通信バス３０への結合が失われたものと仮定することが可能である。
【００９０】
一つ又はそれ以上の実施例において、ネットワーク参加者２０１，２０２，．．．，２０ｎの中のネットワーク参加者２０ｉにおける送信エラーカウンタが或るスレッシュホールドに到達した結果として、ノード２０ｉはデータを送信することを停止し且つ該バスを混乱させることを回避するために受動的状態（リセッシブ状態）に入ることが可能である。
【００９１】
一つ又はそれ以上の実施例において、ネットワーク参加者２０１，２０２，．．．，２０ｎの中のいずれかの送信エラーカウンタは、或る時間期間の間にノード２０ｉからのデータが受信されていないことの結果として或る参加者２０ｉへ送信することが可能なマスタ１０からのコマンドによってリセットさせることが可能である。或るスレーブ２０ｉにおけるリセットコマンドの受信は例えば何らかの例外的な条件（例えば、ひずみ）に起因して受動的状態に入っている場合のあるそのスレーブをアンロックさせることが可能である。
【００９２】
一つ又はそれ以上の実施例は、それらがＣＡＮバスの「事実上」のスタンダードにおいて（既に）提供されている限り、ＲＥＣ／ＴＥＣを採用することが可能である。
【００９３】
一つ又はそれ以上の実施例の安全性概念は、マスタ−スレーブプロトコル構造及び与えられた時間フレーム内にメッセージを送信すること及びこれらのメッセージを正しく受信することが関与する動作に関して構築することが可能である。
【００９４】
一つ又はそれ以上の実施例は以下に説明するような状況を目論む場合がある。
【００９５】
ａ．ＴＥＣスレッシュホールド超過
ｉ．マスタにおけるＴＥＣ：マスタは最早スレーブと結合されていないことを認識しており−＞警告メッセージが発行される（例えば、ドライバに対して：ランプ、ダッシュボードメッセージ等）
ｉｉ．スレーブにおけるＴＥＣ：或るスレーブはマスタへ診断メッセージを送信することが不可能であることを認識−＞フェイルセーフ状態（「リンプホーム」）へ入る、例えばＬＥＤバックライトをターンオンさせる。
【００９６】
ｂ．ＲＥＣスレッシュホールド超過
ｉ．マスタにおけるＲＥＣ：ネットワークに「ひずみ発生」（例えば、短絡ケーブル又はその他の理由）−＞マスタがスレーブへフェイルセーフコマンドを送信し且つ警告メッセージを（例えば、ドライバへ）発行する。
【００９７】
ｉｉ．スレーブにおけるＲＥＣ：ネットワークに「ひずみ発生」−＞スレーブは通信を停止し（従って、該バスが他のスレーブの通信をブロックすることの潜在的な危険性を回避）且つフェイルセーフ状態へ入る。
【００９８】
ｃ．マスタが「第１」メッセージを送信
ｉ．マスタはアクノレッジを受信せず−＞ＴＥＣがマスタにおいて増加し、上述したのと同一の反応。
【００９９】
ｉｉ．スレーブが与えられた時間フレームにおいて「第１」メッセージを受信せず−＞ネットワークにひずみ発生（スレーブにおけるＲＥＣ障害と同じ、上述したのと同一の反応）。
【０１００】
ｄ．マスタが「第２」メッセージを送信
ｉ．マスタがアクノレッジ（ＡＣＫ）を受信せず−＞上述したのと同一の反応。
【０１０１】
ｉｉ．マスタはアドレスしたスレーブから応答を受信せず−＞ネットワークにひずみ発生（少なくとも関連するスレーブにおいて、上述したのと同一の反応）。
【０１０２】
ｉｉｉ．スレーブが「第２」メッセージを受信せず−＞動作無し；通信は「第１」メッセージによって検証され、その点に関しては上述したのと同一の反応。
【０１０３】
ｅ．スレーブが診断フレームを送信することにより「第２」メッセージに応答
ｉ．マスタは或る時間フレーム内に診断フレームを受信しないか又はひずみ発生応答を受信−＞ネットワークにひずみ発生（少なくとも関連するスレーブにおいて、マスタにおけるＲＥＣ障害に対して上述したのと同一の反応）。
【０１０４】
ｉｉ．スレーブはアクノレッジを受信せず：ネットワークにひずみ発生−＞スレーブにおけるＴＥＣ障害に対して上述したのと同一の反応；スレーブにおけるＴＥＣのありうる不存在において（以下も参照）何らの反応も提供されず且つマスタからの「第１」メッセージの受信によって通信が検証される。
【０１０５】
上述した如く、一つ又はそれ以上の実施例は、スレーブに対するＲＥＣ／ＴＥＣ概念を「捨て去る（dropping）」と共に、例えばオリジナルのＣＡＮ（ＦＤ）プロトコルの一部として、マスタにおいて（のみ）それを維持することを目論むことが可能であり、従ってマスタ（のみ）がそのＴＥＣ／ＲＥＣを評価する。
【０１０６】
一つ又はそれ以上の実施例において、フェイルセーフ／リンプホーム状況において、スレーブ（例えば、自動車におけるバックライトのＬＥＤドライバ）はセーフ状態に入り、例えば、バックライトを（少なくとも部分的に）ターンオンさせ、従ってその自動車を暗闇におけるその他の運転手によって見ることが可能であり、尚且つ例えば過剰温度又はその他の障害を回避するために電力消費を増加させる場合があるその他の付随的な機能を遮断する。
【０１０７】
勿論、フェイルセーフ／リンプホーム状況のタイプ及び性質は関与するスレーブの種類の関数として異なる場合があり、例えば、夜間運転期間中に運転手の困惑を回避するために室内ライトを単純にターンオフさせる場合がある。
【０１０８】
一つ又はそれ以上の実施例において、バス１０７を介してのメインコントローラ（シャシー／ボディコントローラ、一層高いレベルのコントローラ）へのネットワーク接続に障害が発生した場合には、マスタはフェイルセーフ状態に入る場合もある。マスタがフェイルセーフ状態に入ることの結果として、マスタはそれと結合されているスレーブへコマンドを送信して夫々フェイルセーフ状態に入ることが可能である。又、マスタは警告メッセージによってネットワークのひずみ発生に反応することが可能であり、例えば、警告ランプ及び／又はダッシュボードメッセージを介して運転手に通知する。
【０１０９】
一つ又はそれ以上の実施例において、いずれかの送信機は、受信機がデータフレームを正しく受信したことの結果としてアクノレッジ（「ＡＣＫ」）ビットを少なくとも一つの受信機から受信することが可能である。従って、送信機は、それが未だにネットワークの少なくとも一部へ結合されているか否かを識別することが可能である。例えば、送信機の送信エラーカウンタは、その送信機によってＡＣＫビットが受信されない結果として増加される。
【０１１０】
例えば、一つ又はそれ以上の実施例において、本書に例示するように、マスタ１０は「ウオッチドッグトリガ」及び／又はネットワーク「ハートビート」として使用することが可能な定期的な時間期間でメッセージを送り出す。従って、受信用スレーブ２０１，２０２，．．．，２０ｎはマスタ１０が通信しているか否かを認識することが可能である。マスタ１０は、周期的に各接続しているスレーブ２０からステータス情報を要求する場合がある。スレーブ２０１，２０２，．．．，２０ｎの中のスレーブ２０ｉがマスタ１０によって発行されたステータス情報要求に応答しない場合には、スレーブ２０ｉの「不存在」（例えば、障害）を検知することが可能である。
【０１１１】
例えば、本書に例示する如き一つ又はそれ以上の実施例において、どの送信機も、通信バス３０を介してそれが送信するビットをバス３０上で受信したビットと比較するように構成することが可能である。送信ビットと受信ビットとが等しくないことが判別される結果として、エラーの存在を仮定することが可能であり、従って、送信機の送信エラーカウンタを増加させることが可能である。送信機ノードは、対応するＴＥＣが或るスレッシュホールドに到達したことの結果としてデータを送信することを停止し、該送信機を受動的状態に入りさせることが可能である。
【０１１２】
例えば、本書において例示される如き一つ又はそれ以上の実施例において、受信されたフレームは、例えば、以下の特徴の内の一つ又はそれ以上をチェックすることによって、正確性を検証することが可能である。
【０１１３】
即ち、その特徴とは、
−受信したＣＲＣの正確性、
−ＣＲＣフィールドに続くＣＲＣデリミターとしての一つのリセッシブビットの受信、
−受信フレームのビットスタッフィング（bit stuffing）の正確性、
である。
【０１１４】
一つ又はそれ以上の実施例において、受信したＣＲＣが受信したフレームと整合しない場合の結果として、受信したフレームを廃棄することが可能であり且つ受信機のＲＥＣを増加させることが可能である。
【０１１５】
一つ又はそれ以上の実施例において、受信したフレームのビットスタッフィングが正しくないことの結果として、受信したフレームを廃棄することが可能であり且つ受信機のＲＥＣを増加させることが可能である。
【０１１６】
一つ又はそれ以上の実施例において、送信したフレームを、例えば以下の特徴の内の一つ又はそれ以上をチェックすることによって、正確性について検証することが可能である。その特徴とは、
−送信したビットはトランシーバによって受信されるので、送信したビットと受信したビットとの間の均等性、
−少なくとも一つの受信機からＡＣＫビットを発行することによって、少なくとも一つの受信機回路による送信フレームのアクノレッジ。
【０１１７】
一つ又はそれ以上の実施例において、送信されたビットと受信されたビットとが同一ではないことが判明した結果として、送信されたフレームは無効であると考えることができ、送信は中止され且つ送信機のＴＥＣは増加される。
【０１１８】
一つ又はそれ以上の実施例において、送信機回路が受信器からＡＣＫビットを受信することがないことの結果として、送信されたフレームは受信機のいずれによっても受信されていないものとして考えることができ、送信機のＴＥＣを増加し且つ送信したフレームは再送信しないものとする場合がある。
【０１１９】
一つ又はそれ以上の実施例において、スレーブ装置２０１，２０２，．．．，２０ｎのオシレータ２０１６は、例えば予測される値の±２％であるそれらの振動周波数の最大の許容される逸れを有することが可能である。従って、一つ又はそれ以上の実施例における２つのスレーブの間の最大の周波数オフセットは最大値、例えば振動周波数の最大±４％、に到達することが可能である。
【０１２０】
一つ又はそれ以上の実施例において、一つのスレーブによって送信されたフレームは同一の通信バス３０上の別のスレーブによってデコードされることが意図されているものではない場合がある。一つのスレーブが別のスレーブによって送信されたフレームを受信することの結果として、該第１スレーブの受信エラーカウンタが増加する場合がある。エラーフレームはこれらのスレーブによって送信されることはなく、従ってその通信にひずみが発生することはない。
【０１２１】
従って、一つ又はそれ以上の実施例において、受信機のＲＥＣは、以下における表１に例示される如く、この様に受信されたフレームの長さに従って、エラーのないフレームを受信することの結果として、減少される場合がある。
【０１２２】
一つ又はそれ以上の実施例において、受信機のＲＥＣは、例えば古典的なＣＡＮ拡張型フレームフォーマット（ＣＥＦＦ）と共に動作するＣＡＮ部分的ネットワーキング（ＣＡＮ  ＰＮ）に従って、最大で８までのデータ長コード（ＤＬＣ）に対して１単位だけ減少される場合がある。一層長いフレームの場合には、この様な挙動は通信コントローラ２０１０内において考慮することが可能である。何故ならば、スレーブから発生する多くのフレームは通信バス３０におけるその他のスレーブによって認識されない場合があるからである。最悪の場合には、スレーブから発生するフレームの（すべて）は通信バス３０内のその他のスレーブによって認識されない場合がある。更に、受信機のＲＥＣは受信されたフレーム当たりに１単位を超えて増加される場合がある。何故ならば、スタッフィングエラー、ＣＲＣエラー、及びＣＲＣデリミターエラーが加算される場合があるからである。
【０１２３】
一つ又はそれ以上の実施例において、マスタは、スレーブよりも各スレーブ応答に対して一層多くの８バイトデータパケットを送信する。実際に、一つ又はそれ以上の実施例において、スレーブ応答はマスタによって送信されるフレームよりも一層短い場合がある（例えば、一層低い数のデータバイトを担持している）。
【０１２４】
バス３０上を一つのスレーブによって送信されバス３０へ結合されている他のスレーブへ通じるスレーブ応答がそれらのＲＥＣを増加させることを「補償」するために、スレーブによって正しく受信されるマスタにより送信される長いフレームが、表１に例示される如く、該マスタにより送信される該フレームの長さに従う長さだけ該スレーブのＲＥＣを減少させることが可能である。
【０１２５】
【表１】
2019176474.tif 000003
【０１２６】
図５は、一つ又はそれ以上の実施例において実行される「ブロードキャスト」フレームプロトコルを記載した可能な論理フローを例示するブロック図であって、例えばマスタが「第１」メッセージを送信し且つスレーブがこの様なメッセージを受信する場合である。
【０１２７】
図５において、太い縦線の左側に存在する論理ブロックはマスタ装置１０によって実行される動作を表しており、その太い縦線の右側に存在している論理ブロックはスレーブ装置２０１，２０２，．．．，２０ｎの中でいずれかのスレーブ装置２０ｉにおいて実行される動作を表している。
【０１２８】
図５中の論理ブロックの意味は以下の通りである。
【０１２９】
−３００：ブロードキャストＩＤで「第１」メッセージを送信、
−３０１：「第１」メッセージの受信、
−３０２：受信した「第１」メッセージにおいてエラーを検知（Ｙ＝エラー検知、Ｎ＝エラー不検知）、
−３０３：ブロック３０２の正（Ｙ）出力の場合に該スレーブのＲＥＣを増加、
−３０４：送信終了、
−３０５：ブロック３０２の負（Ｎ）出力の場合にＡＣＫビットを送信、
−３０６：該スレーブのＲＥＣを減少、
−３０７：「受信成功」状態で終了、
−３０８：ＡＣＫビットを受信、
−３０９：受信したＡＣＫビットにおいてエラー検知（Ｙ＝エラー検知、Ｎ＝エラー不検知）、
−３１０：ブロック３０９の負（Ｎ）出力の場合に「送信成功」状態で終了、
−３１１：ブロック３０９の正（Ｙ）出力の場合に、オプションとして該マスタのＴＥＣを増加し、且つエラーフレームを送信、
−３１２：送信終了、
−３１３：エラーフレームを受信、
−３１４：該スレーブのＲＥＣを増加、
−３１５：送信終了。
【０１３０】
図５のブロック図に記載される動作について理解を容易にさせるために以下に更に簡単に説明する。
【０１３１】
図５に例示される如く、一つ又はそれ以上の実施例において、動作値をセットするため、例えばアクチュエータ値をセット即ち設定するために、マスタ１０からスレーブ２０１，２０２，．．．，２０ｎへ「第１」メッセージを送信することが可能である。
【０１３２】
一つの実施例においては、「第１」メッセージは通信バス３０へ接続されているスレーブ２０１，２０２，．．．，２０ｎの全てに対しての設定値を包含している場合がある。
【０１３３】
別の実施例においては、「第１」メッセージは通信バス３０へ接続されているスレーブ２０１，２０２，．．．，２０ｎの全ての中の或るサブセットのスレーブ、例えばスレーブ２０１，２０２，．．．，２０ｎの中で単一のスレーブの場合もある、に対して設定値を包含している場合がある。
【０１３４】
一つ又はそれ以上の実施例において、マスタ１０は「第１」メッセージを送信した後にスレーブ２０１，２０２，．．．，２０ｎから戻される応答を予期しない場合もあるが、少なくとも一つのスレーブから少なくとも一つのアクノレッジビット、例えばＣＡＮアクノレッジスロットにおいて、を予期する場合もある。
【０１３５】
本書において例示するような一つ又はそれ以上の実施例において、マスタ１０が少なくとも一つのスレーブからどのようなアクノレッジビットも受信することがない、例えばＣＡＮアクノレッジスロットにおいて、ことの結果として、マスタ１０はその送信エラーカウンタを増加させる。一つ又はそれ以上の実施例において、マスタ１０は通信バス３０上にエラーフレームを送信する場合もある。
【０１３６】
本書で例示する如き一つ又はそれ以上の実施例において、スレーブ２０１，２０２，．．．，２０ｎは受信した「第１」メッセージの完全性をチェックし且つ受信した「第１」メッセージがエラーの無いものである場合にはアクノレッジビットを送信することが可能であり、このような場合には該「第１」メッセージは有効であると考慮される。一つ又はそれ以上の実施例において、付加的なエラーフレームを受信することは何らの付加的な反応無しで受信エラーカウンタを増加させることとなる。
【０１３７】
一つ又はそれ以上の実施例において、スレーブ２０１，２０２，．．．，２０ｎは、それらに対して有効である「第１」メッセージからデータをピック即ち採取する場合がある。一つ又はそれ以上の実施例において、「第１」メッセージはブロードキャストＩＤ、例えばＣＡＮメッセージの標準ＩＤフィールドにおいて、を担持している場合がある。
【０１３８】
図６は、一つ又はそれ以上の実施例において実行される診断フレームプロトコルを記載している可能な論理フローを例示するブロック図であって、例えばマスタが「第２」メッセージを送信し且つ一つのスレーブがそのようなメッセージを受信し且つそれについて反応する場合である。
【０１３９】
図５における如く、図６中の太い縦線の左側に存在する論理ブロックはマスタ装置１０において実行される動作を表しており、且つ該太い縦線の右側に存在する論理ブロックはスレーブ２０１，２０２，．．．，２０ｎ中のいずれかのスレーブ装置２０ｉにおいて実行される動作を表している。
【０１４０】
図６中の論理ブロックの意味は以下の通りである。
【０１４１】
−４００：（ターゲット）スレーブＩＤで「第２」メッセージを送信、
−４０１：「第２」メッセージを受信、
−４０２：受信した「第２」メッセージにおけるエラー検知（Ｙ＝エラー検知、Ｎ＝エラー不検知）、
−４０３：ブロック４０２の正（Ｙ）出力の場合に該スレーブのＲＥＣを増加、
−４０４：送信終了、
−４０５：ブロック４０２の負（Ｎ）出力の場合にＡＣＫビットを送信、
−４０６：該スレーブのＲＥＣを減少、
−４０７：１０ビットバスアイドル待機、
−４０８：エラー検知（Ｙ＝エラー検知、Ｎ＝エラー不検知）、
−４０９：スレーブＩＤ付きで反応メッセージを送信、
−４１０：ＡＣＫビットを受信、
−４１１：受信したＡＣＫビットにおけるエラー検知（Ｙ＝エラー検知、Ｎ＝エラー不検知）、
−４１２：ブロック４１１の正（Ｙ）出力の場合に該マスタのＴＥＣを増加させ且つエラーフレームを送信、
−４１３：エラーフレームを受信、
−４１４：該スレーブのＲＥＣを増加、
−４１５：送信終了、
−４１６：ＴＲＥＣを待機、
−４１７：ＴＲＥＣタイムアウトに到達したか否かをチェック（Ｙ＝ＴＲＥＣタイムアウトに到達、Ｎ＝ＴＲＥＣタイムアウトに到達せず）
−４１８：ブロック４１７の正（Ｙ）出力の場合にウオッチドッグ失敗をトリガ、
−４１９：ブロック４１７の負（Ｎ）出力の場合に反応メッセージを受信、
−４２０：受信した反応メッセージにおけるエラー検知（Ｙ＝エラー検知、Ｎ＝エラー不検知）、
−４２１：ブロック４２０の正（Ｙ）出力の場合に該マスタのＲＥＣを増加させ且つエラーフレームを送信、
−４２２：エラーフレームを受信、
−４２３：該スレーブのＴＥＣ及びＲＥＣを増加、
−４２４：送信終了、
−４２５：ブロック４２０の負（Ｎ）出力の場合にＡＣＫビットを送信、
−４２６：該マスタのＲＥＣを減少、
−４２７：「受信成功」状態で終了、
−４２８：ＡＣＫビットを受信、
−４２９：受信したＡＣＫビットにおけるエラー検知（Ｙ＝エラー検知、Ｎ＝エラー不検知）、
−４３０：ブロック４２９の正（Ｙ）出力の場合に該スレーブのＴＥＣを増加、
−４３１：送信終了、
−４３２：ブロック４２９の負（Ｎ）出力の場合に該スレーブのＴＥＣを減少、
−４３３：「送信成功」状態で終了。
【０１４２】
図６のブロック図によって記載されている動作についても理解を容易にさせるために以下において簡単に説明する。
【０１４３】
図６において例示される如く、一つ又はそれ以上の実施例において、マスタ１０は、メッセージＩＤ内に、例えばＣＡＮメッセージのスタンダードＩＤフィールド、スレーブ２０ｉの識別スレーブＩＤを包含させることによって通信バス３０に接続されているスレーブ２０１，２０２，．．．，２０ｎの中で或るスレーブ２０ｉからの診断データを要求する「第２」メッセージを送信することが可能である。該マスタ１０は特定の時間ウィンドウＴＲＥＣ内にそのアドレスされたスレーブからの応答、例えば反応メッセージ、を待機する場合がある。その時間ウィンドウＴＲＥＣ内に該マスタ１０が応答を受け取らなかったことの結果として、ウオッチドッグエラーをトリガさせることが可能である。
【０１４４】
一つ又はそれ以上の実施例において、バス３０上をマスタ１０によって送信された「第２」メッセージを正しく受信した結果として、スレーブ２０ｉはＡＣＫスロットにおけるＡＣＫビットで応答し且つ或る時間間隔（期間）、例えばバスアイドルのすくなくとも１０ビット、待機した後にその反応メッセージを送信する。
【０１４５】
一つ又はそれ以上の実施例において、スレーブ２０１，２０２，．．．，２０ｎ中のその他のスレーブは反応メッセージを不正確に受信する場合がある（例えば、マスタ１０の周波数に関連して夫々のオシレータの周波数オフセットに起因して）。この様な反応メッセージを不正確に受信することの結果として、受信するスレーブ２０１，２０２，．．．，２０ｎのＲＥＣが増加される場合がある。
【０１４６】
本書で例示される如き一つ又はそれ以上の実施例において、マスタ１０によって発行された「第２」メッセージによってアドレスされないスレーブは応答せず且つアドレスされたスレーブによって送信される反応メッセージを無視する。
【０１４７】
本書で例示される如き一つ又はそれ以上の実施例において、マスタ１０からの要求によってフレームがスレーブ２０１，２０２，．．．，２０ｎによって（のみ）送信される。従って、エラーが発生した場合には、スレーブ２０１，２０２，．．．，２０ｎは何らのフレームも再送信することはない。
【０１４８】
本書で例示される如き一つ又はそれ以上の実施例において、「第２」メッセージはアドレスされたスレーブのＩＤによってラベル付けされる場合がある。オプションとして、「第２」メッセージは、スタンダードＩＤフィールド中の使用されていないＩＤビットによってブロードキャストフレームとしてラベル付けさせることが可能である（例えば、スタンダードＩＤフィールドの下位１０ビットがアドレスされたスレーブを示すことが可能であり、一方１１番目のビットがそのフレームをブロードキャストフレームとしてマーク付けすることが可能である）。
【０１４９】
図７は、一つ又はそれ以上の実施例において実行されるエラー及びオーバーロードフレームプロトコルを記載している可能な論理フローを例示しているブロック図である。
【０１５０】
図５及び６における如く、図７中の太い縦線の左側に存在する論理ブロックはマスタ装置１０によって実行される動作を表しており、且つその太い縦線の右側に存在する論理ブロックはスレーブ装置２０１，２０２，．．．，２０ｎ中のいずれかのスレーブ装置２０ｉにおいて実行される動作を表している。
【０１５１】
図７中の論理ブロックの意味は以下のとおりである。
【０１５２】
−５００：エラー検知（Ｙ＝エラー検知、Ｎ＝エラー不検知）、
−５０１：ブロック５００の負（Ｎ）出力の場合には「送信成功」状態で終了、
−５０２：ブロック５００の正（Ｙ）出力の場合には該マスタのＴＥＣを増加させ且つエラーフレームを送信、
−５０３：送信終了、
−５０４：エラーフレームを受信、
−５０５：該スレーブのＲＥＣを増加、
−５０６：送信終了。
【０１５３】
図７のブロック図によって記載される動作も理解を容易にするために以下において簡単に説明する。
【０１５４】
一つ又はそれ以上の実施例において、エラーフレームはスレーブ２０１，２０２，．．．，２０ｎではなくマスタ１０によって（のみ）送信される。エラーフレームを受信することは該スレーブのＲＥＣを１だけ増加させることとなる場合がある。同じ挙動がエラーフレームとして取り扱われるオーバーロードフレームの場合にも適用することが可能である。
【０１５５】
一つ又はそれ以上の実施例において、バス参加者（スレーブ２０１，２０２，．．．，２０ｎ）はバス３０上の通信を仲裁することが可能なものではない。何故ならば、通信はマスタ１０によって（のみ）開始及び／又は制御させることが可能であるからである。
【０１５６】
本書に例示される如き一つ又はそれ以上の実施例において、バス３０上でのどのような衝突も関連するエラーカウンタを増加させることとなる。マスタ１０は、必ずしもそのフレームを再送信すること無しに、エラーを衝突として検知し且つその送信エラーカウンタを増加させることが可能である。スレーブ２０１，２０２，．．．，２０ｎ中の一つのスレーブがバス３０上で誤りのビット（例えば、予期されているリセッシブの代わりのドミナントビット）を検知し且つその送信エラーカウンタを増加させる場合がある。
【０１５７】
理解されるように、エラーメッセージは、いわば、エラー自身であり、即ちそれらはＣＡＮプロトコル要件を充足するものではない場合がある。それらは、単に、一組の、例えば６個の、連続するドミナントビットである場合がある。従って、それらはエラーであると看做して、スレーブ側ではそれらに対して何らの反応をすること無しに、廃棄することが可能である。
【０１５８】
一つ又はそれ以上の実施例の根底にある一つの概念は、「第１」メッセージ及び「第２」メッセージがマスタによって送信された（唯一の）メッセージである限り、「第１」メッセージ及び／又は「第２」メッセージを正しく受信した場合に（のみ）ウオッチドッグタイマーをリセットすることである。
【０１５９】
図８は、一つ又はそれ以上の実施例において、マスタユニット１０の通信サイクルの可能な実行例を表しているブロック図である。
【０１６０】
図８中の論理ブロックの意味は以下のとおりである。
【０１６１】
−６００：通信を開始、
−６０１：スレーブ２０ｉに対して診断データに対する要求が発行されるべきであるか否かを決定（Ｙ＝スレーブ２０ｉに対して診断データ要求を発行、Ｎ＝スレーブ２０ｉに対して診断データ要求を発行せず）、
−６０２：ブロック６０１の正（Ｙ）出力の場合にスレーブ２０ｉに対して「第２」メッセージを送信、
−６０３：スレーブ２０ｉのウオッチドッグタイマーをリセット、
−６０４：スレーブ２０ｉから診断データ付きの反応メッセージが受信されたか否かをチェック（Ｙ＝診断データ受信、Ｎ＝診断データ受信せず）、
−６０５：スレーブ２０ｉのウオッチドッグタイマーが満了したか否かをチェック（Ｙ＝ウオッチドッグ満了、Ｎ＝ウオッチドッグ満了せず）、
−６０６：ブロック６０５の正（Ｙ）出力の場合にスレーブ２０ｉに対するウオッチドッグタイムアウトを検知、
−６０７：ブロック６０１の負（Ｎ）出力である場合に「第１」メッセージを送信、
−６０８：オプションとして、ＴＷＡＩＴ待機。
【０１６２】
一つ又はそれ以上の実施例において、マスタ１０は「第１」メッセージを、例えばアクチュエータセッティングのために、（例えば循環的に）スレーブ２０１，２０２，．．．，２０ｎへ送信することが可能であり、それらのスレーブはこの様なサイクルをウオッチドッグトリガとして使用することが可能である。「第１」メッセージがウオッチドッグ時間内にスレーブ２０ｉによって受信されないことの結果として、ウオッチドッグタイムアウトを検知することが可能である。ウオッチドッグタイムアウトが検知されることの結果として、スレーブ２０ｉはフェイルセーフ状態に入ることが可能である。
【０１６３】
一つ又はそれ以上の実施例において、マスタ１０は或るアドレスされたスレーブ２０ｉから診断データを要求する場合がある。アドレスされたスレーブ２０ｉが或る量の時間以内に応答しないことの結果として、ウオッチドッグタイマーをトリガさせることが可能であり、従って該マスタはそのスレーブ２０ｉとの通信の喪失に関して動作することが可能である。
【０１６４】
本書で例示する如き一つ又はそれ以上の実施例において、データは少なくとも２つの異なる態様でスレーブ２０１，２０２，．．．，２０ｎへ送信することが可能である。
【０１６５】
第１のケースにおいては、「第１」メッセージをマスター１０が全てのスレーブ２０１，２０２，．．．，２０ｎへ送信することが可能である。この様な場合には、マスタ装置１０はスレーブ２０１，２０２，．．．，２０ｎからの応答を期待しない場合がある。
【０１６６】
第２のケースにおいては、「第２」メッセージをマスタ１０が特定のスレーブ２０ｉへ送信することが可能である。スレーブ２０１，２０２，．．．，２０ｎは「第２」メッセージを、例えばアクチュエータセッティングのための、ブロードキャストフレームとして取り扱うことが可能である。従って、アドレスされたスレーブ（のみ）が反応メッセージにおいてその診断データを送り戻すことによって「第２」メッセージに関して反応する。この様な診断データはバス３０上のその他のスレーブによって無視される。該スレーブ間の周波数オフセットに起因して、該スレーブ中の一つによって送信される反応メッセージはその他のスレーブによって誤りフレームとして看做される場合があり且つそれらの夫々のＲＥＣを増加させる場合がある。
【０１６７】
一つ又はそれ以上の実施例において、該「第２」メッセージは専用のフレームである場合もあり、それはその他のスレーブによっては無視される場合がある。
【０１６８】
一つ又はそれ以上の実施例において、「第１」メッセージは特定したブロードキャストＩＤを使用する場合があり、且つ「第２」メッセージはそのアドレスされたスレーブのＩＤを包含している場合がある。
【０１６９】
一つ又はそれ以上の実施例において、スタンダードＩＤフィールド中の使用可能な残りのビットは、該複数のスレーブへの診断要求送信データとアドレスされたスレーブのみへの特定要求との間を区別するために使用することが可能である。
【０１７０】
図９は一つ又はそれ以上の実施例におけるスレーブユニット２０１，２０２，．．．，２０ｎの通信サイクルの可能な実行例を表すブロック図である。
【０１７１】
図９中の論理ブロックの意味は以下の通りである。
【０１７２】
−７００：通信開始、
−７０１：ウオッチドッグタイマーをリセット、
−７０２：有効なメッセージが受信されたか否かを検知（Ｙ＝有効なメッセージを受信、Ｎ＝有効なメッセージを受信せず）、
−７０３：ブロック７０２の正（Ｙ）出力である場合に受信した該有効なメッセージが「第１」メッセージであるか又は「第２」メッセージであるかを決定（Ｙ＝「第１」メッセージを受信、Ｎ＝「第２」メッセージを受信）、
−７０４：ブロック７０３の負（Ｎ）出力である場合に診断データ付き反応メッセージを送信、
−７０５：ブロック７０２の負（Ｎ）出力である場合にウオッチドッグが満了したか否かをチェック（Ｙ＝ウオッチドッグ満了、Ｎ＝ウオッチドッグ満了せず）、
−７０６：ブロック７０５の正（Ｙ）出力である場合にウオッチドッグ失敗を発行。
【０１７３】
一つ又はそれ以上の実施例において、マスタ１０がスレーブ２０１，２０２，．．．，２０ｎに対して（循環的に）データを送信する。この様なデータは夫々のウオッチドッグをリセットさせるために夫々のスレーブによって使用することが可能である。リセットすることが意図されていないフレームである場合には、夫々のウオッチドッグは該ウオッチドッグが満了する前に一つのスレーブによって受信され、ウオッチドッグ失敗がセット即ち設定される場合がある。この様なウオッチドッグ失敗はフェイルセーフ状態に入るために該スレーブによって使用される場合がある。
【０１７４】
一つ又はそれ以上の実施例において、スレーブ２０ｉがそれに対してアドレスされた「第２」メッセージを受信することの結果として、受信するスレーブ２０ｉは要求された診断データを包含している反応メッセージを送信することによって応答する。
【０１７５】
一つ又はそれ以上の実施例において、マスタ１０は単一のデータフレームにおいて例えば６４バイト（即ち、５１２ビット、尚１バイトは８ビットに等しい）のデータを送信する場合がある。バス参加者、例えばスレーブ２０１，２０２，．．．，２０ｎ、はマスタ１０から送信されるこの様なデータを受信する。従って、一つのスレーブはマスタ１０から受信した５１２ビットのデータの内の任意の一組からそれが必要とする情報を「ピック」即ち採取することが可能である。この種類のフレームは「第１」メッセージと呼称される。
【０１７６】
或る「第１」メッセージにおいて一つのスレーブが読み取る場合があるビット数は通信バスの特定の実施例に依存して異なる場合がある。或るスレーブの該データの位置は初期化シーケンス期間中に決定することが可能である。
【０１７７】
例えば、各スレーブは「第１」メッセージにおける８ビットのデータを読み取る場合がある。或る「第１」メッセージにおいてマスタ１０によって送信されるデータの全量が、例えば、６４バイト（即ち、５１２ビット）である場合には、「第１」メッセージ当たりのデータを最大で６４個のスレーブへ供給することが可能である。「第１」メッセージにおけるマスタ１０によって送信されるデータ量と「第１」メッセージにおいてスレーブによって読み取られるデータ量とが定義されると、「第１」メッセージによってアドレス可能なスレーブの最大数を対応して定義することが可能である。
【０１７８】
一つ又はそれ以上の実施例において、可能なバス参加者の数（即ち、スレーブの数）は、スレーブの「複数のチェーン」を供給することによって増加させることが可能である。その場合には、１番目の「第１」メッセージは第１チェーンのスレーブ（例えば、６４個のスレーブを含んでいる）へアドレスし、２番目の「第１」メッセージは第２チェーンのスレーブをアドレスする等、以下同様とすることが可能である。該複数のスレーブチェーンはメッセージＩＤフィールド内の専用のＩＤ（例えば、ＣＡＮ  ＦＤ  ＩＤフィールド）によってアドレスすることが可能である。
【０１７９】
一つ又はそれ以上の実施例において、一つのスレーブはそのスレーブアドレスを使用することによって個別的にアドレスさせることが可能であり、且つそのアドレスされたスレーブはこの診断要求フレームに関して反応する。
【０１８０】
一つ又はそれ以上の実施例において、マスタ１０によって送信される「第２」メッセージ及びスレーブ２０１，２０２，．．．，２０ｎによって送信される反応メッセージのデータ内に例えばＳＴグループに属する会社によって開発されたＳＴ  ＳＰＩ（シリアルペリフェラルインターフェース）４．１プロトコル等のプロトコルを埋め込むことは、或るアドレスに対しての或るデータを読み取ること又は書き込むことを容易化させる。
【０１８１】
一つ又はそれ以上の実施例において、該マスタからの「第２」メッセージのデータ内に埋め込まれたＳＴ  ＳＰＩプロトコルに基づくＳＰＩコマンドは、メモリアドレスと該要求（読取／書込）に対するデータバイトの数とから構成することが可能である。該スレーブは、該アドレスおよび該要求されたメモリアドレスのデータバイトの代わりに、特定のバイトでＳＴ  ＳＰＩプロトコルに応答することが可能である。この様な特定のバイトは「グローバルステータスバイト」（ＧＳＢ）と呼称され且つ重要なステータスビットを包含しており、この様なステータスビットは、例えば、発生したエラー、発生したリセット、等を表すものである。従って、該グローバルステータスレジスタを各診断応答と共に送り戻すことが可能である。
【０１８２】
一つ又はそれ以上の実施例において、「第１」メッセージが、バスネットワーク３０内の（全ての）スレーブ２０１，２０２，．．．，２０ｎへマスタ１０によｔって送信される。「第１」メッセージのＩＤフィールドは、その「第１」メッセージによってアドレスされる一つのチェーンの識別番号を包含している場合がある。そのアドレスされたチェーンに属しているスレーブはそのフレームによって転送されたデータ（例えば、最大で６４バイトのデータ）からそれらのデータを採取することが可能である。一つのスレーブによって読み取られるデータビットの数は、その機能の実行時に定義される（例えば、所謂「ハードコード化」値である）。「第１」メッセージの全体的なデータフィールドにおいてアドレスされたチェーンの或るスレーブへ指向されたデータの位置は、チェーン初期化期間中に決定することが可能である。
【０１８３】
一つ又はそれ以上の実施例において、「第１」メッセージは、例えば、「１」で始まり且つ３個の「１」が続く１１ビットフレームＩＤとアドレスされるチェーン識別数、例えば７ビット数、を使用する場合がある。例えば、５ビットにコード化されているチェーン識別番号を使用することは最大で６４個のスレーブチェーンの識別及び割り当てを可能とさせ、その場合に各チェーンは、例えば、最大で６３個のスレーブを包含している。
【０１８４】
一つ又はそれ以上の実施例において、特定の「第１」メッセージ、尚ここでは「初期化フレーム」と呼称される、を通信バス３０内のスレーブ２０１，２０２，．．．，２０ｎへ送信して、或るチェーンにおけるそれらの「メンバーシップ」と該チェーン内のそれらの相対的な位置とを設定させることが可能である。初期化フレームを受信することの結果として、該スレーブは、通信バス３０上で受信されるブロードキャストフレームからそれらに対して意図されたデータを読み取る条件とされる。例えば、或る「第１」メッセージにおいて一つのスレーブによって読み取られるビット数は、該スレーブの全てに対して同じであり且つバス実行において定義される場合がある（例えば、ハードコード化値）。
【０１８５】
一つ又はそれ以上の実施例において、チェーン初期化フレームに対するＩＤは、例えば、「１＿０１１０＿００００＿００」とすることが可能である。
【０１８６】
一つ又はそれ以上の実施例において、一つのスレーブは初期化フレームから例えば３バイトののデータを読み取る場合があり、例えば、その第１バイトはそれが属するチェーンを表し、その第２バイトは該チェーン内のその位置を表し、且つその第３バイトはアドレスされたスレーブを表す場合がある。従って、該初期化フレームのデータフィールドのバイトでのディメンジョン即ち大きさと適切に初期化されるべき一つのスレーブによって必要とされるデータの量とに依存して、制限された数のスレーブを初期化するために単一の初期化フレームを使用することが可能である。例えば、該初期化フレームのデータフィールドが例えば６４バイトの長さであり且つ一つのスレーブが適切に初期化されるために例えば３バイトのデータを必要とする場合には、一つのＣＡＮ  ＦＤフレームで最大で２１個のスレーブを初期化させることが可能である。
【０１８７】
一つ又はそれ以上の実施例において、ウエイクアップパターン（ＷＵＰ）を特定の「第１」メッセージとして実行させることが可能である。ウエイクアップパターンのＩＤは、例えば１Ｍｂ／ｓでのＴＦＩＬＥＴＥＲ（ｓｈｏｒｔ）でもって、ＩＳＯ１１８９８−２のウエイクアップパターン要件を満足すべく選択することが可能である。通信バスが一層低いビットレートで動作される場合には、ＴＦＩＬＥＴＥＲ（ｌｏｎｇ）を使用することが可能である。
【０１８８】
一つ又はそれ以上の実施例において、予約されているＷＵＰ  ＩＤは「１＿０００＿１１１＿０００」である場合がある。該ＷＵＰは、ウエイクアップフレームのオプションのデータバイトにおいて繰り返すか又はエンハンスさせることが可能である。
【０１８９】
一つ又はそれ以上の実施例において、マスタ１０は、ＣＡＮ  ＦＤフレームであるように選択することが可能な「第２」メッセージを送信することによって特定のスレーブ２０ｉからデータを要求する場合がある。「第２」メッセージのそのＣＡＮ  ＦＤ  ＩＤは、スレーブＩＤ、例えば９ビットスレーブＩＤ、及びこの様なフレームを「第２」フレームとして識別する１個のビット、及びこの様なフレームをユニキャストフレームとして識別する１個のビットを包含する場合がある。
【０１９０】
一つ又はそれ以上の実施例において、バス３０において使用される該ＣＡＮ  ＦＤ  ＩＤの最大桁ビット（ＭＳＢ）は、所謂「ユニキャスト」フレーム、即ち或る一つのスレーブのみにアドレスされているフレーム、を識別する場合には「０」と等しく、且つ「ブロードキャスト」フレーム、即ち全てのスレーブに対してアドレスされるフレーム、を識別する場合には、「１」と等しい場合があり、そこでは、更に、チェーン初期化フレームとウエイクアップフレームとを包含している。理解されるように、夫々「１」及び「０」の値への参照は単に例示的なものであって、一つ又はそれ以上の実施例では、実際に、相補的選択（例えば、夫々、「０」及び「１」の値）を採用する場合がある。
【０１９１】
一つ又はそれ以上の実施例において、ユニキャストフレームが何らのデータも包含していないことの結果として、そのアドレスされたスレーブは、実行において定義される如く、デフォルトの診断データを送信する場合がある。そうでない場合で、ユニキャストフレームがデータを包含している場合には、この様なデータはＳＴ  ＳＰＩ  ４．１プロトコルに基づくＳＰＩコマンドである。
【０１９２】
一つ又はそれ以上の実施例において、上述した如きＳＰＩコマンドを包含しているユニキャストフレームを受信するスレーブは、ＳＴ  ＳＰＩ  ４．１プロトコルによってコード化された「第２」メッセージによって要求されたデータで応答する。
【０１９３】
一つ又はそれ以上の実施例において、マスタ１０は、ＣＡＮ  ＦＤ  ＩＤフィールド内のスレーブＩＤを包含しているフレームを送信することによってスレーブ２０ｉをアドレスすることが可能である。そのオプションとしてのデータバイトはＳＴ  ＳＰＩ  ＳＤＩ（ＳＴシリアルペリフェラルインターフェースシリアルデータインプット）フレームを包含している場合がある。
【０１９４】
一つ又はそれ以上の実施例において、スレーブ２０ｉは、通信バス３０上を反応メッセージ、例えば診断応答フレーム、を送信することによって受信した「第２」メッセージに応答することが可能である。その反応メッセージはＣＡＮ  ＦＤフレームであるように選択することが可能である。反応メッセージのＣＡＮ  ＦＤ  ＩＤは、スレーブＩＤ、例えば９ビットスレーブＩＤ、と、この様なフレームを反応メッセージとして識別する１個のビットと、この様なフレームをユニキャストフレームとして識別する１個のビットとを包含することが可能である。
【０１９５】
一つ又はそれ以上の実施例において、反応メッセージのデータバイトは、ＳＴ  ＳＰＩ  ＳＤＯ（ＳＴグループの会社によって開発された如きシリアルペリフェラルインターフェースシリアルデータアウトプット）フレームを包含することが可能である。スレーブによって受信された「第２」メッセージがフレームデータフィールド内にデータを包含するものではない場合には、そのスレーブは、そのデータバイトがグローバルステータスバイト（ＧＳＢ）のみを包含している場合があるＣＡＮ  ＦＤフレームでその受信した「第２」メッセージに応答する場合がある。
【０１９６】
一つ又はそれ以上の実施例において、異なるデフォルト応答を使用することが可能であり且つ装置のデータシートに明細を記載することが可能である。
【０１９７】
幾つかの実施例におけるフレームＩＤ、例えばＣＡＮ  ＦＤスタンダードフレームＩＤ、の可能な使用態様を以下の表２に例示的に示してある。
【０１９８】
【表２】
2019176474.tif 000004
【０１９９】
一つ又はそれ以上の実施例において、プロトコルコントローラが前述した如くにＣＡＮ  ＦＤプロトコルを実行する場合がある。
【０２００】
一つ又はそれ以上の実施例において、ＣＡＮ  ＦＤウエイクアップフレーム検知を実行するためのビルディングブロックを、簡単化したマスタ／スレーブ通信構造の実現を容易化するために使用し且つ修正することが可能であり、その場合に、該スレーブは該マスタによる要求に（のみ）応答する。
【０２０１】
既に注記した如く、
−本記載を介して説明した「第１」メッセージは、基本的に、例えば一つの装置によってバス上を送信されるメッセージは（同時的に）（全ての）その他の装置によって受信されて、これら後者の装置はブロードキャストメッセージによって運ばれる動作データ部分の関数として夫々の動作を実行することが可能であるようなＣＡＮバスプロトコル等のメッセージを基礎としたプロトコルにおいて従来送信されるようなブロードキャストメッセージに対応しており、
−同様に、一つの（マスタ）装置によってバス上をいわば「物理的に」ブロードキャストするものであるが、本記載の全体にわたり説明した該第２メッセージは、実際には、基本的には要求メッセージとしてその他の（スレーブ）装置の個々のものへ「論理的に」アドレスされるものであり、その場合に、該スレーブ装置は、例えば診断メッセージ等の夫々の応答を−或る時間間隔内で−該マスタ装置へ送信することによって反応することが要求され、その際に該マスタ装置が該スレーブ装置に対して夫々の非衝突性の応答間隔を割り当てる限りにおいてこの様な応答の可能な衝突は回避される。
【０２０２】
従って、該第１メッセージは真の「ブロードキャスト」メッセージとして看做すことが可能であり、逆に言えば、一つの（マスタ）装置によってバス３０上を物理的にブロードキャストする一方、該第２メッセージが該スレーブ装置の個々のものへの論理的にアドレスされる限りにおいて該第２メッセージを基本的に「ユニキャスト」メッセージとして看做すことが可能である。
【０２０３】
一つ又はそれ以上の実施例において、一つの方法が、
−バス（例えば３０）を介して第１装置（例えば、１０）と一組の第２装置（例えば、２０１，２０２，．．．，２０ｎ）とを結合させ；
−該第１装置を該バス上で送信するマスタ装置として構成し、
−ａ）該一組の第２装置における第２装置による実行のための動作を表す一組の動作データメッセージ部分を担持する第１メッセージ；及び
−ｂ）該一組の第２装置における第２装置へアドレスされている第２メッセージであって、該第２メッセージがアドレスされて夫々の予期された反応期間内に該第１装置に対して夫々の反応を要求する該第２装置の夫々のものを識別する識別子を担持している該第２メッセージ；及び
−該第２装置をスレーブ装置として構成し；
−ｃ）マスタ装置として構成された該第１装置から送信された該第１メッセージを該バス上で受信するために、該一組の動作データメッセージ部分における夫々の動作データメッセージ部分を読み取り且つ読み取られた該夫々の動作データメッセージ部分の関数として夫々の動作を実行し；
−ｄ）マスタ装置として構成されている該第１装置から送信された該第２メッセージを該バス上で受信し且つマスタ装置として構成されている該第１装置へ反応メッセージを該バス上で送信することにより該夫々の予期されている反応期間内にそれについて反応する、
を包含している。
【０２０４】
一つ又はそれ以上の実施例において、マスタ装置として構成されている第１装置は、マスタ装置として構成されている該第１装置から該バス上を送信される第１メッセージにおけるどの動作データメッセージ部分がスレーブとして構成されている第２装置の夫々のものへ専用とされているかを表す初期化データを有している初期化メッセージをバス上を送信することが可能であり、且つスレーブ装置として構成されている第２装置は、マスタ装置として構成されている該第１装置から該バス上を送信される該初期化メッセージを受信することが可能であり且つ該一組の動作データメッセージ部分においてそれに対して専用とされている夫々の動作データメッセージ部分を読み取るために該初期化データの関数として初期化することが可能である。
【０２０５】
一つ又はそれ以上の実施例において、一つの方法は、スレーブ装置として構成されている一組の第２装置を複数のサブセットの第２装置に配置させることを包含することが可能であり、その場合に、マスタ装置として構成されている第１装置は、第１動作メッセージが専用とされている該サブセットの第２装置を識別するサブセット識別インデックスを有する第１メッセージをバス上を送信することが可能である。
【０２０６】
一つ又はそれ以上の実施例において、マスタ装置として構成されている第１装置は、一定のレート即ち割合でバス上を第１メッセージを送信することが可能である。
【０２０７】
一つ又はそれ以上の実施例において、一組の第２装置における第２装置は、夫々のウオッチドッグタイマーの満了の結果としてフェイルセーフ状態へスイッチすることが可能である。
【０２０８】
一つ又はそれ以上の実施例において、一組の第２装置における第２装置は、マスタ装置として構成されている第１装置から第１メッセージ及び第２メッセージから選択されたメッセージを受信する結果として夫々のウオッチドッグタイマーをリセットすることが可能である。
【０２０９】
一つ又はそれ以上の実施例において、第１装置は、一組の第２装置における第２装置から要求された夫々の反応が夫々の予期されている反応期間内に該第１装置へ到達しないことに感応することが可能であり、及び／又は一組の第２装置における第２装置からの夫々の反応が夫々の予期されている反応期間内に該第１装置へ到達しないことを表す夫々のウオッチドッグエラー信号をトリガすることが可能である。
【０２１０】
一つ又はそれ以上の実施例において、バスは差動配線バスを有することが可能である。
【０２１１】
一つ又はそれ以上の実施例において、システムが、第１装置（例えば、１０）と、バス（例えば、３０）を介して結合されている一組の第２装置（例えば、２０１，２０２，．．．，２０ｎ）とを有しており、該第１装置及び該第２装置は、夫々、マスタ装置及びスレーブ装置として構成することが可能であり、且つ該マスタ装置及び該スレーブ装置は一つ又はそれを超える実施例の内の該方法で動作する構成とすることが可能である。
【０２１２】
一つ又はそれ以上の実施例において、バス（例えば、３０）を介して一組の第２装置（例えば、２０１，２０２，．．．，２０ｎ）へ第１装置として結合させる装置（例えば、１０）は、該バスを介して、
−該一組の第２装置における第２装置による実行のための動作を表す一組の動作データメッセージ部分を担持している第１メッセージ、及び
−該一組の第２装置における第２装置へアドレスされる第２メッセージであって、夫々の予期されている反応期間内に該第１装置に対して夫々の反応を要求し、且つ該第２メッセージがアドレスされる該第２装置の夫々のものを識別する識別子を担持している該第２メッセージ、
を送信する構成とすることが可能である。
【０２１３】
一つ又はそれ以上の実施例において、バスを介して一組の第２装置へ第１装置として結合させる装置が、該一組の第２装置における第２装置から要求された夫々の反応が夫々の予期されている反応期間内に該第１装置へ到達することがないことに感応することが可能であり、及び／又は該一組の第２装置における第２装置からの夫々の反応が夫々の予期されている反応期間内に該第１装置へ到達しないことを表す夫々のウオッチドッグエラー信号をトリガさせる構成とすることが可能である。
【０２１４】
一つ又はそれ以上の実施例において、バス（例えば、３０）を介して第１装置（例えば、１０）へ結合されている一組の第２装置（例えば、２０１，２０２，．．．，２０ｎ）内に包含させる装置（例えば、２０ｉ）が、
−該一組の第２装置における第２装置による実行のための動作を表す一組の動作データメッセージ部分を担持している第１メッセージを該バス上で受信し、該一組の動作データメッセージ部分における少なくとも一つの夫々の動作データメッセージ部分を読み取り、且つ該読み取った少なくとも一つの夫々の動作データメッセージ部分の関数として少なくとも一つの夫々の動作を実行し、
−該バス上を夫々の第２メッセージがアドレスされる該第２装置の内の該一つとして
該装置を識別する識別子を伝達する該夫々の第２メッセージであって、夫々の予期されている反応期間内に該第１装置に対して夫々の反応を該装置から要求する該夫々の第２メッセージを受信し、且つ該夫々の予期されている反応期間内にそれについて反応する、
構成とさせることが可能であり、該装置からの反応メッセージがマスタ装置として構成されている該第１装置へ向けて該バス上を送信される。
【０２１５】
一つ又はそれ以上の実施例において、バスを介して第１装置へ結合されている一組の第２装置内に包含させる装置が、夫々のウオッチドッグタイマーの満了の結果としてフェイルセーフ状態へスイッチする構成とすることが可能である。
【０２１６】
一つ又はそれ以上の実施例において、バスを介して第１装置へ結合されている一組の第２装置内に包含させる装置が、該バスを介して該第１装置から受信されたメッセージの結果として夫々のウオッチドッグタイマーをリセットさせる構成とさせることが可能である。
【０２１７】
一つ又はそれ以上の実施例において、バスを介して第１装置へ結合されている一組の第２装置内に包含させる装置が、その中に実現されている応用特定ハードウエアを有しているＨＷ通信及びプロトコルコントローラ（例えば、２０１）を有することが可能である。
【０２１８】
一つ又はそれ以上の実施例において、バスを介して第１装置へ結合されている一組の第２装置内に包含させる装置が、光照射供給源ドライバ、好適には乗物ライトドライバ、を有することが可能である。
【０２１９】
一つ又はそれ以上の実施例において、乗物（例えば、Ｖ）に一つ又はそれを超える実施例に基づくシステム具備させることが可能である。
【０２２０】
一つ又はそれ以上の実施例において、一つ又はそれを超える実施例に基づくシステムにおいて第１装置（例えば、１０）から一組の第２装置（例えば、２０１，２０２，．．．，２０ｎ）へメッセージを送信するためにバス（例えば、３０）上を送信可能な信号が、
−該一組の第２装置における第２装置による実行のための動作を表す一組の動作データメッセージ部分を担持している第２メッセージ、及び
−該一組の第２装置における第２装置へアドレスされている第２メッセージであって、夫々の予期されている反応期間内に該第１装置に対しての夫々の反応を要求し、該第２メッセージがアドレスされる該第２装置の夫々のものを識別する識別子を担持している該第２メッセージ、
を有することが可能である。
【０２２１】
一つ又はそれ以上の実施例において、スレーブ装置として構成されている第２装置に対して専用とされている一組の動作データメッセージ部分を担持している第１メッセージを送信する信号が一定のレート即ち割合で発生することが可能である。
【０２２２】
基礎となる原理を損なうこと無しに、該詳細及び実施例は、保護範囲を逸脱すること無しに、例示としてのみ記載されていることに関して例え顕著にでも異なるものとなる場合がある。
【０２２３】
以上、本発明の具体的実施の態様について詳細に説明したが、本発明の技術的範囲を逸脱すること無しに種々の変更が可能であることは勿論である。
【符号の説明】
【０２２４】
１０：第１装置
２０ｉ：第２装置
３０：バス
Ｖ：乗物
【図１】
2019176474.tif 000005
【図２】
2019176474.tif 000006
【図３】
2019176474.tif 000007
【図４】
2019176474.tif 000008
【図５】
2019176474.tif 000009
【図６】
2019176474.tif 000010
【図７】
2019176474.tif 000011
【図８】
2019176474.tif 000012
【図９】
2019176474.tif 000013