知財求人 - 知財ポータルサイト「IP Force」
特開2023-111888エンドツーエンドのデータ保護を提供するシステムおよび方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023111888
(43)【公開日】2023-08-10
(54)【発明の名称】エンドツーエンドのデータ保護を提供するシステムおよび方法
(51)【国際特許分類】
H04L 1/00 20060101AFI20230803BHJP
【ＦＩ】
H04L1/00 A
【審査請求】未請求
【請求項の数】26
【出願形態】ＯＬ
【外国語出願】
(21)【出願番号】P 2023011458
(22)【出願日】2023-01-30
(31)【優先権主張番号】17/588,832
(32)【優先日】2022-01-31
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】523032401
【氏名又は名称】ルネサス デザイン （ユーケー） リミテッド
【氏名又は名称原語表記】Ｒｅｎｅｓａｓ Ｄｅｓｉｇｎ （ＵＫ） Ｌｉｍｉｔｅｄ
【住所又は居所原語表記】Ｄｕｋｅｓ Ｍｅａｄｏｗ， Ｍｉｌｌｂｏａｒｄ Ｒｏａｄ， Ｂｏｕｒｎｅ Ｅｎｄ ＳＬ８ ５ＦＨ， Ｕｎｉｔｅｄ Ｋｉｎｇｄｏｍ
(74)【代理人】
【識別番号】110002066
【氏名又は名称】弁理士法人筒井国際特許事務所
(72)【発明者】
【氏名】ウォーターウォース，ロバート
(72)【発明者】
【氏名】アダムス－ウェイト，カール
【テーマコード（参考）】
5K014
【Ｆターム（参考）】
5K014BA01
5K014BA06
(57)【要約】 （修正有）
【課題】送信側のデバイスと受信側のデバイスとの間でエンドツーエンドのデータ保護を提供するシステムを提供する。
【解決手段】送信側のデバイスと受信側のデバイスとの間のエンドツーエンドのデータ保護を提供するための方法は、送信側のデバイスが第１、第２のデータブロックを有する第１のメッセージ用の第１のチェック値を計算しＳ５１０、受信側のデバイス用の第２のメッセージを生成するために、第１、第２のデータブロックのうちの一方をリマッピングしＳ５２０、リマッピングデバイスによって、データブロックとリマッピングされたデータブロックに基づいてリマッピング値を決定しＳ５３０、受信側のデバイス用の第２のメッセージを計算し、第１、第２のデータブロックのうちの一方をリマッピングすると共に、第２のメッセージに対して計算される第２のチェック値が第１チェック値と等しくなるようにリマッピング値を決定するＳ５４０。
【選択図】図５
【解決手段】送信側のデバイスと受信側のデバイスとの間のエンドツーエンドのデータ保護を提供するための方法は、送信側のデバイスが第１、第２のデータブロックを有する第１のメッセージ用の第１のチェック値を計算しＳ５１０、受信側のデバイス用の第２のメッセージを生成するために、第１、第２のデータブロックのうちの一方をリマッピングしＳ５２０、リマッピングデバイスによって、データブロックとリマッピングされたデータブロックに基づいてリマッピング値を決定しＳ５３０、受信側のデバイス用の第２のメッセージを計算し、第１、第２のデータブロックのうちの一方をリマッピングすると共に、第２のメッセージに対して計算される第２のチェック値が第１チェック値と等しくなるようにリマッピング値を決定するＳ５４０。
【選択図】図５
【特許請求の範囲】
【請求項1】
送信側のデバイスと受信側のデバイスとの間でエンドツーエンドのデータ保護を提供するシステムであって、
第１のメッセージ用の第１のチェック値を計算するように構成され、前記第１のメッセージは第１のデータブロックおよび第２のデータブロックを含む前記送信側のデバイスと、
前記受信側のデバイスと、
前記送信側のデバイスと前記受信側のデバイスとの間の信号パス内にあり、前記受信側のデバイス用の第２のメッセージを生成するために、第１および第２のデータブロックのうちの一方またはその一部の中のデータブロックをリマッピングするように構成されたリマッピングデバイスと、
を備え、
リマッピングデバイスは、前記データブロックおよび前記リマッピングされたデータブロックに基づいてリマッピング値を決定するようにさらに構成され、その結果、前記第２のメッセージについて計算された第２のチェック値は、前記第１のチェック値と等しくなり、前記第２のメッセージは、前記第１および前記第２のデータブロックの他方と、前記リマッピングされたデータブロックと、前記リマッピング値とを含む、
システム。
第１のメッセージ用の第１のチェック値を計算するように構成され、前記第１のメッセージは第１のデータブロックおよび第２のデータブロックを含む前記送信側のデバイスと、
前記受信側のデバイスと、
前記送信側のデバイスと前記受信側のデバイスとの間の信号パス内にあり、前記受信側のデバイス用の第２のメッセージを生成するために、第１および第２のデータブロックのうちの一方またはその一部の中のデータブロックをリマッピングするように構成されたリマッピングデバイスと、
を備え、
リマッピングデバイスは、前記データブロックおよび前記リマッピングされたデータブロックに基づいてリマッピング値を決定するようにさらに構成され、その結果、前記第２のメッセージについて計算された第２のチェック値は、前記第１のチェック値と等しくなり、前記第２のメッセージは、前記第１および前記第２のデータブロックの他方と、前記リマッピングされたデータブロックと、前記リマッピング値とを含む、
システム。
【請求項2】
請求項１に記載のシステムにおいて、
前記第１のデータブロックはペイロードデータであり、前記第２のデータブロックは前記ペイロードデータに関連付けられた第１のアドレスである、
システム。
前記第１のデータブロックはペイロードデータであり、前記第２のデータブロックは前記ペイロードデータに関連付けられた第１のアドレスである、
システム。
【請求項3】
請求項２に記載のシステムにおいて、
前記リマッピングデバイスは、前記第１のアドレスを、前記受信側のデバイスを示す第２のアドレスにリマッピングするように構成された、
システム。
前記リマッピングデバイスは、前記第１のアドレスを、前記受信側のデバイスを示す第２のアドレスにリマッピングするように構成された、
システム。
【請求項4】
請求項３に記載のシステムにおいて、
前記リマッピングデバイスは、前記ペイロードデータとは独立して、前記第１および前記第２のアドレスに基づいて前記リマッピング値を決定するように構成された、
システム。
前記リマッピングデバイスは、前記ペイロードデータとは独立して、前記第１および前記第２のアドレスに基づいて前記リマッピング値を決定するように構成された、
システム。
【請求項5】
請求項１に記載のシステムにおいて、
前記第１のメッセージはさらにパディングブロックを備え、前記パディングブロックの長さは前記リマッピング値の長さに等しく、前記パディングブロックは前記第２のメッセージの前記リマッピング値によって置き換えられた、
システム。
前記第１のメッセージはさらにパディングブロックを備え、前記パディングブロックの長さは前記リマッピング値の長さに等しく、前記パディングブロックは前記第２のメッセージの前記リマッピング値によって置き換えられた、
システム。
【請求項6】
請求項１に記載のシステムにおいて、
前記第２のメッセージは、前記リマッピングデバイスが前記リマッピングを実行したかどうかを示すリマッピングフラグをさらに備える、
システム。
前記第２のメッセージは、前記リマッピングデバイスが前記リマッピングを実行したかどうかを示すリマッピングフラグをさらに備える、
システム。
【請求項7】
請求項６に記載のシステムにおいて、
前記第２のチェック値は、前記リマッピングフラグに基づいてさらに計算され、前記リマッピング値は、前記リマッピングフラグに基づいてさらに決定される、
システム。
前記第２のチェック値は、前記リマッピングフラグに基づいてさらに計算され、前記リマッピング値は、前記リマッピングフラグに基づいてさらに決定される、
システム。
【請求項8】
請求項１に記載のシステムにおいて、
前記システムは、前記信号パス内に複数の順次リマッピングデバイスを備え、後続のリマッピングデバイスは、前記第１および前記第２のデータブックのうち一方または先行するリマッピングデバイスによってリマッピングされたその一部をリマッピングするように構成され、 各リマッピングデバイスは、それぞれのリマッピング値を決定するように構成された、
システム。
前記システムは、前記信号パス内に複数の順次リマッピングデバイスを備え、後続のリマッピングデバイスは、前記第１および前記第２のデータブックのうち一方または先行するリマッピングデバイスによってリマッピングされたその一部をリマッピングするように構成され、 各リマッピングデバイスは、それぞれのリマッピング値を決定するように構成された、
システム。
【請求項9】
請求項８に記載のシステムにおいて、
前記第２のメッセージは、前記第１および前記第２のデータブロックの他方と、前記リマッピングされたデータブロックと、前記複数のリマッピングデバイスによって決定された前記リマッピング値とを備える、
システム。
前記第２のメッセージは、前記第１および前記第２のデータブロックの他方と、前記リマッピングされたデータブロックと、前記複数のリマッピングデバイスによって決定された前記リマッピング値とを備える、
システム。
【請求項10】
請求項８に記載のシステムにおいて、
前記後続のリマッピングデバイスは、任意の先行するリマッピングデバイスによって決定された前記リマッピング値に基づいてさらに前記リマッピング値を決定するように構成され、前記第２のメッセージは、前記第１および前記第２のデータブロックのうちの他方と、前記リマッピングされたデータブロックと、前記複数のリマッピングデバイスのうちの最後のリマッピングデバイスによって決定された前記それぞれのリマッピング値とを備えた、
システム。
前記後続のリマッピングデバイスは、任意の先行するリマッピングデバイスによって決定された前記リマッピング値に基づいてさらに前記リマッピング値を決定するように構成され、前記第２のメッセージは、前記第１および前記第２のデータブロックのうちの他方と、前記リマッピングされたデータブロックと、前記複数のリマッピングデバイスのうちの最後のリマッピングデバイスによって決定された前記それぞれのリマッピング値とを備えた、
システム。
【請求項11】
請求項２に記載のシステムにおいて、
前記第１のアドレスは、前記第１のメッセージ内の前記ペイロードデータの前に配置された、
システム。
前記第１のアドレスは、前記第１のメッセージ内の前記ペイロードデータの前に配置された、
システム。
【請求項12】
請求項３に記載のシステムにおいて、
前記第２のアドレスは、前記第２のメッセージ内の前記ペイロードデータの前に配置された、
システム。
前記第２のアドレスは、前記第２のメッセージ内の前記ペイロードデータの前に配置された、
システム。
【請求項13】
請求項３に記載のシステムにおいて、
前記リマッピング値が、前記第２のメッセージ内の前記第２のアドレスと前記ペイロードデータとの間に挿入された、
システム。
前記リマッピング値が、前記第２のメッセージ内の前記第２のアドレスと前記ペイロードデータとの間に挿入された、
システム。
【請求項14】
請求項５、または請求項５に従属する場合には請求項６から１３の何れか一項に記載のシステムにおいて、
前記パディングブロックが、前記第１のメッセージ内の前記第１のアドレスと前記ペイロードデータとの間に挿入された、
システム。
前記パディングブロックが、前記第１のメッセージ内の前記第１のアドレスと前記ペイロードデータとの間に挿入された、
システム。
【請求項15】
請求項２に記載のシステムにおいて、
前記リマッピングデバイスは、前記ペイロードデータまたはその一部をリマッピングするように構成された、
システム。
前記リマッピングデバイスは、前記ペイロードデータまたはその一部をリマッピングするように構成された、
システム。
【請求項16】
請求項１に記載のシステムにおいて、
前記第１および前記第２のチェック値を計算するために使用されるエラー検出アルゴリズムは、ＸＯＲ演算を伴う、
システム。
前記第１および前記第２のチェック値を計算するために使用されるエラー検出アルゴリズムは、ＸＯＲ演算を伴う、
システム。
【請求項17】
請求項１に記載のシステムにおいて、
前記リマッピング値は、前記第１および前記第２のチェック値を計算するために使用されるエラー検出アルゴリズムの逆数に基づいて決定された、
システム。
前記リマッピング値は、前記第１および前記第２のチェック値を計算するために使用されるエラー検出アルゴリズムの逆数に基づいて決定された、
システム。
【請求項18】
請求項１に記載のシステムにおいて、
前記リマッピング値は、ルックアップテーブル、ＬＵＴ、または線形方程式から決定される、
システム。
前記リマッピング値は、ルックアップテーブル、ＬＵＴ、または線形方程式から決定される、
システム。
【請求項19】
請求項１に記載のシステムにおいて、
前記第１および前記第２のチェック値を計算するために使用されるエラー検出アルゴリズムは、巡回冗長チェック、ＣＲＣベースのアルゴリズムである、
システム。
前記第１および前記第２のチェック値を計算するために使用されるエラー検出アルゴリズムは、巡回冗長チェック、ＣＲＣベースのアルゴリズムである、
システム。
【請求項20】
請求項１９に記載のシステムにおいて、
前記リマッピング値の長さは、前記ＣＲＣベースのアルゴリズムを使用して計算された前記チェック値の長さ以上である、
システム。
前記リマッピング値の長さは、前記ＣＲＣベースのアルゴリズムを使用して計算された前記チェック値の長さ以上である、
システム。
【請求項21】
請求項１に記載のシステムにおいて、
前記リマッピングデバイスは、前記リマッピングを実行する前に、
前記送信側のデバイスから送信された前記受信した第１のメッセージに基づいてチェック値を計算し、
前記送信側のデバイスと前記リマッピングデバイスとの間のエラーを検出するために、前記チェック値を前記第１のチェック値と比較する、
システム。
前記リマッピングデバイスは、前記リマッピングを実行する前に、
前記送信側のデバイスから送信された前記受信した第１のメッセージに基づいてチェック値を計算し、
前記送信側のデバイスと前記リマッピングデバイスとの間のエラーを検出するために、前記チェック値を前記第１のチェック値と比較する、
システム。
【請求項22】
請求項１に記載のシステムであって、
前記システムはバスベースのシステムであり、
前記送信側のデバイスはマスターデバイスであり、前記受信側のデバイスはスレーブデバイスまたはその逆である、
システム。
前記システムはバスベースのシステムであり、
前記送信側のデバイスはマスターデバイスであり、前記受信側のデバイスはスレーブデバイスまたはその逆である、
システム。
【請求項23】
請求項２２に記載のシステムにおいて、
前記ペイロードデータは、前記バスベースシステムのバスの動作を示す制御信号を含む、システム。
前記ペイロードデータは、前記バスベースシステムのバスの動作を示す制御信号を含む、システム。
【請求項24】
請求項１に記載のシステムにおいて、
前記システムがイーサネットベースのシステムである、
システム。
前記システムがイーサネットベースのシステムである、
システム。
【請求項25】
請求項１に記載のシステムにおいて、
前記リマッピングデバイスは、ネットワークアドレス変換、ＮＡＴ、デバイスであり、またはその一部を形成する、
システム。
前記リマッピングデバイスは、ネットワークアドレス変換、ＮＡＴ、デバイスであり、またはその一部を形成する、
システム。
【請求項26】
送信側のデバイスと受信側のデバイスとの間でエンドツーエンドのデータ保護を提供する方法であって、
前記送信側のデバイスによって、第１のメッセージ用の第１のチェック値を計算し、前記第１のメッセージは第１のデータブロックと第２のデータブロックとを含み、
リマッピングデバイスにより、前記送信側のデバイスと前記受信側のデバイスとの間の信号パス内のリマッピングデバイスによって、前記第１および前記第２のデータブロックのうちの一方またはその一部をリマッピングし、
前記リマッピングデバイスによって、前記データブロックおよび前記リマップされたデータブロックに基づいてリマッピング値を決定し、
前記リマッピングデバイスによって、前記受信側のデバイス用の第２のメッセージを生成し、前記第２のメッセージは、前記第１および前記第２のデータブロックのうちの他方、前記リマッピングされたデータブロック、および前記決定されたリマッピング値を含み、
前記リマッピング値は、前記受信側のデバイスによって前記第２のメッセージに対して計算される第２のチェック値が第１のチェック値と等しくなるように決定される、
方法。
前記送信側のデバイスによって、第１のメッセージ用の第１のチェック値を計算し、前記第１のメッセージは第１のデータブロックと第２のデータブロックとを含み、
リマッピングデバイスにより、前記送信側のデバイスと前記受信側のデバイスとの間の信号パス内のリマッピングデバイスによって、前記第１および前記第２のデータブロックのうちの一方またはその一部をリマッピングし、
前記リマッピングデバイスによって、前記データブロックおよび前記リマップされたデータブロックに基づいてリマッピング値を決定し、
前記リマッピングデバイスによって、前記受信側のデバイス用の第２のメッセージを生成し、前記第２のメッセージは、前記第１および前記第２のデータブロックのうちの他方、前記リマッピングされたデータブロック、および前記決定されたリマッピング値を含み、
前記リマッピング値は、前記受信側のデバイスによって前記第２のメッセージに対して計算される第２のチェック値が第１のチェック値と等しくなるように決定される、
方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、一般に、エンドツーエンドのデータ保護を提供するための技術を対象にされ、より具体的には、チェック値の再計算を防止するためにデータ修正の技術を対象にされる。
【背景技術】
【0002】
エンドツーエンドのデータ保護の提供が必要になる一般的な技術分野 (例えば、自動車産業) では、通常、ＣＲＣ(Cyclic Redundancy Check) などのチェック値をデータに渡って使用または適用する場合がある。もちろん、ビットサム、バーガーコードなどの他の適切なチェック値も可能であるが、それらはカバレッジが低くなる可能性があり、変更されたデータ長に依存するなどの他の不都合な点がある可能性がある。説明をし易くするために、本開示を通して、ＣＲＣは例として使用される（ただし、いかなる種類の制限としても使用されない）。しかしながら、当業者によって理解され認識されるように、本開示で提案される技術は、他の同様なチェック値にも同様に適用可能であるかもしれない(必要に応じて、小さな修正および／または適応を伴う可能性がある)。
【0003】
バスベースのシステム（例えば、自動車産業で一般的に使用される高機能かつ高性能なバス（ＡＨＢ）システムまたはＡＨＢ Ｌｉｔｅシステム）で使用される場合のＣＲＣの例示的な技術的コンテキストでは、書き込みを実行する場合、マスター（デバイス） は、通常、アドレス全体と（ペイロード）データとにＣＲＣを追加するかもしれない。したがって、スレーブ（デバイス）は、一般に、それを受信すると有効であることを確認するかもれしれない。ただし、このような一般的なアプローチは、いわゆる「リマッパー」(またはリマッピングデバイス) がマスターとスレーブの (信号パス) 間に展開されている場合に、解決を難しくし、問題を引き起こす可能性がある。
【0004】
大まかに言えば、(アドレス) リマッパーはＩＰ再利用の重要な部分と見なされる(例えば、ブロックのターゲット アドレスをＩＰにハードコーディングする代わりに、アドレス ０．．ＥＮＤをストリーミングし、リマッパーブロック（デバイス）はこれを正しい位置に送信してもよい）。これにより、ブロックＩＰが一度検証可能になり、プロジェクトごとにそれを検証しなければならない代わりに、どこでも使用可能になる。ただし、ＣＲＣは通常、上記のようにアドレス領域とデータ領域の両方に追加されるため、リマッパーで再計算する必要があるだろう。従来、リマッパーは、データフレームが部分的に（または完全に）変更されるたびに、チェック値を再計算する必要があるだろう。ＣＲＣの再計算の一般的な概念を使用した例示的に可能な実装を図１に概略的に示す。
【0005】
このような従来の技術は、一般に新しい障害メカニズムを導き、それが保護されなければならない。さらに、既存の解決策もまた、新しいＣＲＣを計算するためにアドレスステージをキャプチャしなければならず、リマッパー内に追加の領域をもたらすだろう。
【0006】
場合によっては、バスの複製もまた使用可能であるが、追加の領域オーバーヘッドをもたらすことを犠牲にするかもしれない。
【0007】
要約すると、上に示した従来のスキームを実装するために、エンジニアは一般に次の中から選択 (トレードオフ) する必要があるだろう：
ＣＲＣの並列計算に関連する大きな追加領域；
ＣＲＣ計算中に追加のサイクルが遅延し、バスの速度を遅くし、
ＩＰブロック内にリマッパーを追加し、これは、各レジスタマップの変更後にブロックを少なくとも部分的に再検証しなければならず、最終段階の変更で問題を潜在的に引き起こすだろうことを意味するかもしれない。
ＣＲＣの並列計算に関連する大きな追加領域；
ＣＲＣ計算中に追加のサイクルが遅延し、バスの速度を遅くし、
ＩＰブロック内にリマッパーを追加し、これは、各レジスタマップの変更後にブロックを少なくとも部分的に再検証しなければならず、最終段階の変更で問題を潜在的に引き起こすだろうことを意味するかもしれない。
【発明の概要】
【発明が解決しようとする課題】
【0008】
その観点から、大まかに言えば、本開示の焦点は、エンドツーエンドのデータ保護を可能にする技術、より具体的には、チェック値の再計算を防止するためのデータ修正の技術を提案することである。
【0009】
上記の技術的問題の一部またはすべてを考慮して、大まかに言えば、本開示は、チェック値をチェックまたは再計算する必要なく、メッセージが部分的に変更された場合に、通信チャネル上でエンドツーエンドの保護を提供するための技術を提供する。特に、本開示は、一般に、それぞれの独立請求項の特徴を有する、エンドツーエンドのデータ保護を提供するためのシステムおよび対応する方法を提供する。
【0010】
本開示の一態様によれば、送信側のデバイス（または単に送信機）と受信側のデバイス（または単に受信機）との間でエンドツーエンドのデータ保護を提供するシステムが提供される。システムは、バスベースのシステム（例えば、自動車産業で一般的に使用される高機能かつ高性能なバス（ＡＨＢ）システムまたはＡＨＢ Lｉｔｅシステム）、または当業者によって理解および評価される任意の他の適切なシステムであってもよい。さらに、本明細書で使用される場合、エンドツーエンドのデータ保護という用語は、一般に、送信機がメッセージ（例えば、アドレス、制御信号（例えば、読み取り／書き込みアクセス）、（ペイロード）データの形式で）を受信機に通信チャネルを通じて送信する場合、および、チャネル内でメッセージが破損している場合に、受信側は（ほとんど)すべてのケースでそのような破損メッセージ (エラー) を検出できるべきである、というシナリオを言及する。当業者によって理解され認識されるように、そのようなエンドツーエンドの保護は、チェック値の技術などの任意の適切な手段を使用することによって提供または達成されるかもしれない。大まかに言えば、チェック値は一般に、（例えば、送信中に）データが破損していないかどうかを確認するために使用されるメッセージに含まれる冗長な情報と見なしてもよい。ＣＲＣ、ハミング、または任意の他の適切なコードなど、任意の適切なチェック値を使用してもよい。さまざまな実装に応じて、チェック値は、任意の適切なエラー検出アルゴリズムなどの任意の適切な手段を使用して決定 （例えば、計算）されてもよい。また、ここで使用されるように、送信側のデバイスと受信側のデバイスという用語は、それぞれの役割（例えば、操作の開始、チェック値のチェック、またはエラーの検出） を示すために使用される名前として理解されるべきであるが、システム内の階層的な位置には関連付けられていないことに留意することもまた価値があるかもしれない。つまり、簡単に言えば、送信側のデバイスは、受信側のデバイスのあるアドレスにアクセスしようとしていると単純に見なしてもよい。別の言い方をすれば、送信側のデバイスは、一般に、対応する操作（例えば、読み取り、書き込みなど）を開始し、最初にチェック値を計算するデバイスと見なしてもよく、 一方で、受信側のデバイスは、一般に、対応する操作（例えば、読み取り、書き込みなど）を実行し、送信中に起こりうるエラーを検出するためにチェック値を（再）計算するデバイスと見なしてもよい。例えば、説明に役立つ例としてバスシステムを取り上げると、いくつかの可能な実装（例えば、バス書き込み操作中）では、送信側のデバイスは（必ずしもそうである必要はないが）マスターデバイスであり、
受信側のデバイスは（必ずしもそうである必要はないが）スレーブデバイスであってもよい。一方、いくつかの他の可能な実装（例えば、バス読み取り操作中) では、送信側のデバイスは（必ずしもそうである必要はないが）スレーブデバイスであってもよく、受信側のデバイスは（必ずしもそうである必要はないが）マスターデバイスであってもよい。
受信側のデバイスは（必ずしもそうである必要はないが）スレーブデバイスであってもよい。一方、いくつかの他の可能な実装（例えば、バス読み取り操作中) では、送信側のデバイスは（必ずしもそうである必要はないが）スレーブデバイスであってもよく、受信側のデバイスは（必ずしもそうである必要はないが）マスターデバイスであってもよい。
【0011】
特に、システムは、送信側のデバイス、受信側のデバイス、およびリマッピングデバイス（またはリマッパーと呼ばれる）を備えてもよい。より具体的には、送信側のデバイスは、第１のメッセージの第１のチェック値を計算する（例えば、コンピュータ計算する）ように構成されてもよく、第１のメッセージは、（とりわけ）第１のデータブロックおよび第２のデータブロックから構成されてもよい。本開示を通じて本明細書で使用される場合、「第１の」および「第２の」という表現は、単に時系列における（言及されている）発生の指示として使用されているが、特定（配列）の順序（例えば、メッセージに配列／カプセル化されるときの順序)の指示としてではないと、特に別段の説明がない限り、理解されるべきであることに留意すべきである。また、リマッピング装置は、送信側のデバイスと受信側のデバイスとの間の信号パスに配列（配置）されてもよい。 リマッピングデバイスは、受信側のデバイスに対する第２のメッセージを生成するために、第１および第２のデータブロックのうちの一方のデータブロックまたはその一部をリマッピング（例えば、修正）するように構成されてもよい。具体的には、リマッピングデバイスは、データブロックおよびリマッピングされたデータブロックに基づいてリマッピング値を決定するようにさらに構成されてもよく、その結果、第２のメッセージに対して計算される（例えば、コンピュータ計算される）第２のチェック値は、（例えば、送信側のデバイスで計算された）第１のチェック値と等しくなるだろう、ここで、第２のメッセージは、第１および第２のデータブロックのうちの他方、リマッピングされたデータブロック、およびリマッピング値を含んでもよい。別の言い方をすれば、第２のメッセージは、第１および第２のデータブロックのうちの一方のデータブロックまたはその一部がリマッピングデバイスによってリマッピング（修正）されている可能性があることを除いて、第１のメッセージに大部分が対応する（同一である）と見なしてもよく、その結果、第２のメッセージには、リマップ（修正）されたデータブロック（無修正の第１のメッセージと比較して）が現在含まれるであろう。最後に、本明細書で使用されるように、第１および第２のメッセージは、特定のフォーマットに従って（例えば、使用されている特定のプロトコルに応じて）カプセル化（例えば、コード化）されてもよい（必ずしもそうである必要はないが）ことに留意すべきである。場合によっては、第１および第２のメッセージは、特定の要素／構成要素の集まりを単に指すという広い意味で理解されるかもしれない。
【0012】
上記で提案されたように構成され、具体的には、メッセージ（例えば、その中のデータ ブロック) が例えば「リマッパー」によって部分的に更新／リマップ／変更されている場合に、（リマッピングデバイスによって）リマッピング値を計算して挿入することにより、ひと続きの（部分的に更新された）メッセージに渡ってチェック値は今もなお正しいであろう。そのため、通常、(リマッピングデバイスまたはリマッパーによって)部分的な更新を実行するときに、古いチェック値が正しいことを確認する必要はない。これにより、特にメッセージの大部分が変更されていない場合に、リマッパーの処理能力および／または領域を節約できる。これに反して、従来の技術では、メッセージがリマッピングデバイスによって部分的に更新されるたびに、新しいチェック値を生成しなければならないだろう。新しいチェック値を生成するには、通常、(リマップされる前の)古いメッセージがまだ有効かどうかを最初にチェックする必要があり、さもなければ、それは、送信機とリマッパーとの間で破損されていたかもしれない。さらに、リマッパーブロックには一般に「適切な値」、つまり、ＣＲＣ生成ロジックを生成する方法がないため、それは本質的に安全である。つまり、リマッパーの障害は受信機で検出され得る。さらにその上、場合によっては、古いデータブロック（つまり、リマッピング前）と新しいデータブロック（つまり、リマッピング後）との間のすべてのマッピングが既にわかっている場合、リマッピング値を事前に計算することができ、それによって大幅に、リマッパー自体の複雑さと領域を低減する。加えて、本開示で提案された技術を使用することにより、標準の更新に対して将来的に保証され得る、より堅牢なシステム設計をさらに可能にすることが可能になり得る。ＩＰの再利用も実現でき、貴重な開発および検証時間を節約することもできる。
【0013】
いくつかの実施形態では、第１のデータブロックはペイロードデータであってもよく、第２のデータブロックはペイロードデータに関連付けられた第１のアドレスであってもよい。上述のように、そのように定義された第１および第２のデータブロックは、第１および第２のメッセージを有する第１および第２のデータブロックの特定の配置（順序）を限定するものとして理解されるべきではない。当業者によって理解され認識されるように、実際には、ペイロードデータは、さまざまな実装および／または要件に応じて、第１および第２のメッセージ内の関連するアドレスの前または後に配置されてもよい。
【0014】
いくつかの実施形態では、リマッピングデバイスは、第１のアドレスを、受信側のデバイスを示す第２のアドレスにリマッピング（修正）するように構成されてもよい。すなわち、リマッピングデバイスは、受信側のデバイスがその第２のアドレスに首尾よくアクセスできるように(例えば、読み取り、書き込みなどの必要な操作を実行するために)、受信側のデバイスに対して第１のアドレスを第２のアドレスにリマッピング（修正）するように構成されてもよい。
【0015】
いくつかの実施形態では、リマッピングデバイスは、ペイロードデータとは独立して、第１および第２のアドレスに基づいてリマッピング値を決定（例えば、計算、取得など)するように構成されてもよい。つまり、リマッピング値は、メッセージの長さと（ペイロード）データ値とは無関係に、第１のアドレス（リマッピング前の古いアドレス）と第２のアドレス（リマッピング後の新しいアドレス）のみを使用して計算（または取得）されてもよい。これにより、効率的な実装が可能になる。
【0016】
いくつかの実施形態では、第１のメッセージはパディングブロックをさらに含んでもよい。いくつかの可能な場合には、そのようなパディングブロックは、（一連の）パディング（ビット）または任意の他の適切な用語として呼ばれることもある。特に、当業者によって理解および認識されるように、そのようなパディングブロックは、任意の適切な値に初期化され得る(例えば、パディングブロック内のすべてのパディングビットは、０に初期化されてもよいが、必ずしもそうである必要はない)。特に、パディングブロックの長さはリマッピング値の長さと等しくてもよく、パディングブロックは後に第２のメッセージのリマッピング値によって置き換えられてもよい。そのため、いくつかの可能な実装では、一般的に言えば、第１のチェック値は第１のメッセージ全体にわたって計算されるため、第１のチェック値は、前記パディングブロックも考慮に入れることにより(送信側のエンドデバイスによって)計算されると見なしてもよい。しかしながら、当業者によって理解され認識されるように、いくつかの可能な実装において、前記パディングブロックは、第１のチェック値を計算するときに、送信側のデバイスによって（意図的に）除外される（スキップされる）かもしれない。もちろん、システム内で事前に合意されている限り、他の適切な実装も可能かもしれない。
【0017】
いくつかの実施形態では、第２のメッセージは、リマッピングデバイスがリマッピングを実行したかどうかを示すリマッピングフラグをさらに含んでもよい。つまり、いくつかの可能な実装では、リマッピング操作を（完全に）スキップしてもよい。考えられる典型的なシナリオ（ただし、いかなる種類の制限としても）は、イーサネットなどの一部の標準 (またはプロトコル) であってもよく、リマッピングを完全にスキップできるようにするためのオプションであってもよく、それによって（イーサネット）プロトコルを下位互換性にする。当業者には理解され認識されるように、そのようなリマッピングフラグは、任意の適切な手段で実装されてもよい（例えば、１ビットが０または１のいずれかの値を有するのと同じくらい簡単である）。
【0018】
いくつかの実施形態では、第２のチェック値は、リマッピングフラグにさらに基づいて計算されてもよく、リマッピング値は、リマッピングフラグにさらに基づいて決定されてもよい。換言すれば、第２のチェック値を計算するとき、一般的に言えば、第２のチェック値は第２のメッセージ全体にわたって計算されるので、受信側のデバイスはリマッピングフラグを考慮に入れてもよい。したがって、リマッピングデバイスは、リマッピング値を決定するときに、リマッピングフラグも考慮に入れなければならないだろう。
【0019】
いくつかの実施形態では、システムは、信号パスに複数の順次リマッピングデバイスを備えてもよい（例えば、送信側のデバイスと受信側のデバイスとの間に順次配置または結合される）。特に、単一のリマッピングデバイスの場合と同様に、（複数の順次リマッピングデバイスのうちの）後続のリマッピングデバイスは、第１および第２のデータブロックのうちの一方のデータブロックまたは前のリマッピングデバイスによってリマッピングされたその一部をリマッピングするように構成されてもよい。さらに、（複数の順次リマッピングデバイス内の）各リマッピングデバイスは、それぞれのリマッピング値を決定するように構成されてもよい。別の言い方をすれば、複数の順次リマッピングデバイスの最後のリマッピングデバイス以外のすべてのリマッピングデバイスは、それぞれの（中間の）リマッピングされたデータブロックとそれぞれの（中間の）リマッピング値とを（後続のリマッピングデバイスがさらにリマッピング値をリマッピングおよび再決定するために）生成するように構成してもよく、一方、複数の順次リマッピングデバイスの最後のリマッピングデバイスは、（最終）リマッピングされたデータブロックおよび（最終）リマッピング値を生成するように（受信側のデバイスが（最終）リマッピングされたデータブロックに関連付けられた対応する操作を実行し、送信中に発生する可能性のあるエラーを検出するための第２チェック値を計算するために）構成されてもよい。
【0020】
いくつかの実施形態では、第２のメッセージは、第１および第２のデータブロックのうちの他方（すなわち、リマッピングされていないデータブロックまたはその一部）と、リマッピングされたデータブロックと、複数のリマッピングデバイスによって決定されるリマッピング値とを含んでもよい。換言すれば、第２のチェック値は、とりわけ、複数のリマッピングデバイスによって決定されたすべての（中間および最終の）リマッピング値を考慮に入れて計算されるべきである。そのような場合、上記と同様に、第１のメッセージは、対応してパディングブロックのカウントを含んでもよく、パディングブロックのカウントは、信号パス内の複数の順次リマッピングデバイスの数に対応して（例えば、等しくて）もよい。
【0021】
いくつかの実施形態では、（複数の順次リマッピングデバイスのうちの）後続のリマッピングデバイスは、任意の先行するリマッピングデバイスによって決定されたリマッピング値にさらに基づいてリマッピング値を決定するように構成されてもよい。したがって、第２のメッセージは、第１および第２のデータブロックの他方と、リマッピングされたデータブロックと、複数のリマッピングデバイスのうち最後のリマッピングデバイスによって決定されたそれぞれのリマッピング値とを含んでもよい。すなわち、複数のリマッピングデバイスによって決定されたすべての（中間および最終の）リマッピング値が第２のメッセージに含まれる上記の可能な実施形態と比較して、この場合、最後のリマッピングデバイスによって決定されたリマッピング値のみが、第２のメッセージに含まれるべきであり、その結果、第２のチェック値を計算するために使用されるべきである。したがって、１つのパディングブロックのみが、第１のメッセージに含められる必要があるかもしれない。
【0022】
いくつかの実施形態では、第１のアドレスは、第１のメッセージ内のペイロードデータの先（前）に配置されてもよい。したがって、いくつかの他の可能な実装では、第１のアドレスは、同様に第１のメッセージ内のペイロードデータに続いて（後に）配置されてもよい。それにもかかわらず、当業者によって理解され認識されるように、データの前にアドレスを配置することは、場合によってはいくつかの利益をもたらす可能性がある。たとえば、説明に役立つ例としてＣＲＣを取り上げると、アドレスが最初に配置され、データが２番目に配置されている場合、リマッピングデバイスによって最初のメッセージを受信すると、ＣＲＣの状態が知られるだろう。それは、ＣＲＣの初期値であり、それにより、リマッピングデバイスは、ペイロードデータとは独立して（リマッピングの前後に）アドレスに基づいてリマッピング値を決定 (計算) できるようになる。しかし、逆にデータを先に配置されると残念ながらＣＲＣが不明な状態になり、こういうわけでデータに基づいても計算される必要があるかもしれない。
【0023】
いくつかの実施形態では、第２のアドレスは、第２のメッセージ内のペイロードデータの前に配置されてもよい。すなわち、ペイロードデータだけでなくアドレスの配置も、第１のメッセージと第２のメッセージとの間で（すなわち、リマッピングの前後で）一貫している可能性がある。
【0024】
いくつかの実施形態では、リマッピング値は、第２のメッセージ内の第２のアドレスとペイロードデータとの間に挿入されてもよい。
【0025】
したがって、いくつかの実施形態では、パディングブロックは、第１のメッセージの第１のアドレスとペイロードデータとの間に挿入されてもよい。すなわち、第２のメッセージ内のリマッピング値の配置は、第１のメッセージ内のパディングブロックの配置と一致してもよい。
【0026】
いくつかの実施形態では、リマッピングデバイスは、ペイロードデータまたはその一部をリマッピングするように構成されてもよい。つまり、いくつかの可能な実装では、ペイロードデータに関連付けられたアドレスをリマッピングする代わりに、リマッピングデバイスは、ペイロード自体（またはその一部）をリマッピング（変更）するように構成されてもよい。
【0027】
いくつかの実施形態では、第１および第２のチェック値を計算するために使用されるエラー検出アルゴリズムは、ＸＯＲ演算を伴っても良い。たとえば、さまざまな実装に応じて、ＸＯＲ操作はニブル単位のＸＯＲ操作であってもよい。
【0028】
いくつかの実施形態では、リマッピング値は、第１および第２のチェック値を計算するために使用されるエラー検出アルゴリズムの逆数に基づいて決定されてもよい。たとえば、エラー検出アルゴリズムの逆数は、ＸＯＲ（例えば、ニブル単位）操作を伴ってもよい。
【0029】
いくつかの実施形態では、リマッピング値は、ルックアップテーブル（ＬＵＴ）または線形（多項式）方程式から決定されてもよい。特に、ＬＵＴは、古いデータブロック（すなわち、リマッピング前）と新しいデータブロック（すなわち、リマッピング後）との間のすべてのマッピングが既に知られている場合に使用されてもよく、リマッピング値を計算して事前にＬＵＴに格納することができる。これにより、リマッパー自体の複雑さと領域とが大幅に削減するかもしれない。
【0030】
いくつかの実施形態では、第１および第２のチェック値を計算するために使用されるエラー検出アルゴリズムは、巡回冗長検査（ＣＲＣ）ベースのアルゴリズムである。もちろん、すでに上で示したように、当業者によって理解および評価されるように、他の適切なアルゴリズムまたはチェック値の実装（例えば、多項式ベース）も同様に使用されてもよい。
【0031】
いくつかの実施形態では、リマッピング値の長さは、ＣＲＣベースのアルゴリズムを使用して計算されたチェック値の長さ以上であってもよい。特に、リマッピング値の長さが ＣＲＣを使用して計算されたチェック値の長さと等しい場合は、効率的な実装の１つと見なしてもよく（例えば、オーバーヘッドの観点から)、それにも関わらずに、さまざまな状況に応じて、チェック値の長さよりも長い（例えば、１ビットだけ) リマッピング値を実装することも可能である。
【0032】
いくつかの実施形態では、リマッピングデバイスは、リマッピングを実行する前に、送信側のデバイスから送信され受信された第１のメッセージに基づいてチェック値を計算し、 送信側のデバイスとリマッピングデバイスとの間のエラーを検出するためにチェック値を第１のチェック値と比較するように構成されてもよい。つまり、さまざまな実装および／または要件に応じて、（個別または専用の）ＣＲＣチェッカーをリマッパー自体に含めることも可能であり、それによってエラー検出の精度が向上される。ただし、これは、デバッグの容易さと設計領域とのトレードオフを考慮して、特定の実装まで決定されるかもしれない。
【0033】
いくつかの実施形態では、システムはバスベース（例えば、ＡＨＢ）システムであってもよく、送信側のデバイスはマスターデバイスであってもよく、受信側のデバイスは、上述したように、スレーブデバイスであってもよく、またはその逆であってもよい。
【0034】
いくつかの実施形態では、ペイロードデータは、バスベースシステムのバスの動作（例えば、バス読み取り、バス書き込み、または任意の他の適切なバス関連動作）を示す（例えば、ユーザデータ以外の）制御信号を備えてもよい。
【0035】
いくつかの実施形態では、システムはイーサネットベースのシステムであってもよい。
【0036】
いくつかの実施形態では、リマッピングデバイスは、ネットワークアドレス変換（ＮＡＴ）デバイスであるか、またはその一部を形成してもよい。当業者によって理解され認識されるように、ＮＡＴ技術は、一般に、トラフィックルーティングデバイスを横切ってデータ送信中にパケットのＩＰヘッダ内のネットワークアドレス情報を変更することによって、ＩＰアドレス空間を別のものにマッピングすることに言及するかもしれない。このような場合、送信側のデバイスの第１のアドレスは、受信側のデバイスの（関連付けられた）第２のアドレスにリマッピングされてもよい。
【0037】
本開示の別の態様によれば、送信側のデバイスと受信側のデバイスとの間でエンドツーエンドのデータ保護を提供する方法が提供される。
【0038】
特に、この方法は、送信側のデバイスによって、第１のデータブロックおよび第２のデータブロックを含んでもよい第１のメッセージ用の第１のチェック値を、計算することを含んでもよい。この方法は、送信側のデバイスと受信側のデバイスとの間の信号パス内のリマッピングデバイスによって、第１および第２のデータブロックのうちの一方のデータブロックまたはその一部をリマッピングすることをさらに含んでもよい。この方法は、リマッピングデバイスによって、データブロックおよびリマッピングされたデータブロックに基づいてリマッピング値を決定することをさらに含んでもよい。最後に、この方法は、リマッピングデバイスによって、受信側のデバイス用の第２のメッセージを生成することを含んでもよく、第２のメッセージは、第１および第２のデータブロックの他方、リマッピングされたデータブロック、および決定されたリマッピング値を含んでもよい。より具体的には、リマッピング値は、受信側のデバイスによって第２のメッセージに対して計算される第２のチェック値が第１のチェック値と等しくなるように決定されてもよい。
【0039】
上記で提案されたように構成されると、具体的には、メッセージ（例えば、その中のデータブロック）が、例えば「リマッパー」によって部分的に更新／リマップ／変更された場合に、（リマッピングデバイスによって）リマッピング値を計算して挿入することにより、 （部分的に更新された）メッセージ全体のチェック値は今でも正しいだろう。そのため、通常、（リマッピングデバイスまたはリマッパーによって）部分的な更新を実行するときに、古いチェック値が正しいことを確認する必要はないだろう。これにより、特にメッセージの大部分が変更されていない場合に、リマッパーの処理能力および／または領域を節約できる。それに対して、従来の技術では、メッセージがリマッピングデバイスによって部分的に更新されるたびに、新しいチェック値を生成しなければならないだろう。新しいチェック値を生成することにより、通常、(リマップされる前の) 古いメッセージがまだ有効かどうかを最初に確認することが必要とされ、そうでなければ、それは送信機とリマッパーとの間で破損され得たにちがいない。さらに、リマッパーブロックには一般に「適切な値」、つまり、ＣＲＣ生成ロジックを生成する方法がないため、本質的に安全である。換言すれば、リマッパーの障害は受信機で検出することができるだろう。さらに、場合によっては、古いデータブロック（つまり、リマッピング前）と新しいデータブロック（つまり、リマッピング後）との間のすべてのマッピングが既にわかっている場合、リマッピング値は事前に計算されてもよく、それによって大幅にリマッパー自体の複雑さと領域を低減する。加えて、本開示で提案された技術を使用することにより、標準の更新に対して将来的に保証され得る、より堅牢なシステム設計をさらに許容することが可能になるかもしれない。ＩＰの再利用も実現でき、貴重な開発および検証時間を節約できる。
【0040】
開示された方法の詳細は、当業者が理解するように、方法のステップの一部またはすべてを実行するように適合されたシステム（例えば、回路の形で）として実装することができ、逆もまた同様である。特に、本開示による方法は、上記の実施形態およびその変形によるシステム（または回路）を動作させる方法に関連し、システム（または回路）に関してなされたそれぞれの記述は、対応する方法やその逆にも同様に適用されることが理解される。
【0041】
本明細書において、「couple（結合）」または「coupled（結合された）」という用語は、例えばワイヤを介して直接接続されているか、または何らかの他の方法で（例えば、間接的に）接続されているかにかかわらず、互いに電気通信する要素を言及すことにも理解される。特に、結合されることの一例は、接続されることである。
【図面の簡単な説明】
【0042】
本開示の例示的な実施形態は、添付の図面を参照して以下に説明され、同様の参照番号は、同様または類似の要素を示す。
【図1】ＣＲＣの再計算を使用した可能な実装の例を概略的に示す図である。
【図2】本開示の実施形態によるリマッパーを使用するバス設計の例示的な概要を概略的に示す図である。
【図3】本開示の実施形態による、ＣＲＣを伴うバス書き込み動作のタイミング図の一例を概略的に示す図である。
【図4】本開示の実施形態による、ＣＲＣを伴うバス読み取り動作のタイミング図の一例を概略的に示す図である。
【図5】本開示の実施形態による、送信側のデバイスと受信側のデバイスとの間のエンドツーエンドのデータ保護を提供するための方法の一例を概略的に示すフローチャートである。
【発明を実施するための形態】
【0043】
上述のように、本開示における同一または同様の参照番号は、特に明記しない限り、同一または同様の要素を示し、その繰り返しの説明は簡潔にするために省略される場合がある。
【0044】
当業者によって理解され認識されるように、慣習的に言えば、多くの既存のプロトコルでは、システム内で（例えば、送信機と受信機の間で）交換されるメッセージは、通常、（全体の）アドレスに対するチェック値を使用して保護され、データ部（領域）は、一般に、アドレスとデータが何らかの形でリンクまたは関連付けられていることを意味するため、正しいデータを含む誤ったアドレス (前のサイクルなど) がチェック値によってさらに検出されるだろう。いくつかの他の可能なケースでは、アドレス部分とデータ部分 (領域)に対する個別のチェック値を実装（例えば、計算）してもよいが、効率の低下という代償を払うかもしれない。
【0045】
その観点から、広い意味で、本開示は、一般に、チェック値をチェックまたは再計算する必要なく、メッセージが部分的に変更される通信チャネル上でエンドツーエンドの保護を提供するための技術を提案する。別の言い方をすれば、アドレスがリマッパーによって変更されるなど、メッセージが部分的に更新された場合でも、メッセージ全体のチェック値が依然として正しいように、本開示で提案されている技術を適用することができる。つまり、データの一部が変更されている場合でも（例えば、リマッパーまたはリマッピング デバイスによって)、メッセージ全体を読み取ったり、正しいチェック値が含まれていることを確認したりする必要がないかもしれず、または、メッセージ全体に渡ってチェック値を再び (再) 計算する必要はないかもしれない（データの一部のみが変更されているため）。大まかに言えば、これは、以下でより詳細に説明するように、リマッピング値を決定してメッセージに挿入することによって実現される。
【0046】
前に説明したように、チェック値は一般に、データが破損していないかどうかをチェックするために使用されるメッセージに含まれる冗長な情報と見なしてもよい（例えば、送信中に)。当業者には理解され認識されるように、ＣＲＣ（巡回冗長検査）、ハミング、または他の適切な符号など、任意の適切な検査値を使用してもよい。さらに、本明細書で説明するように、メッセージは通常、アドレス、制御信号（例えば、読み取り／書き込みアクセス）、およびデータから構成されると見なされてもよいが、最後に使用されるプロトコルに依存してもよい。ドキュメント全体を通して、特に明記しない限り、簡潔にするために、制御信号は（ペイロード）データの一部として扱われると見なされてもよい。例えば、読み取り（操作）の場合、送信機（または送信側のデバイス）は通常、アドレスおよび制御信号を（例えば、メッセージの形式で）送信してもよく、受信機（または受信側のデバイス）は、そのアドレスに関連付けられた (ユーザ) データに対応して送信（アクセス）してもよい。送信機は、通信チャネルを介して受信機にメッセージを送信してもよい。メッセージがチャネル内で破損している場合、受信機は通常、(ほとんど) すべてのケースでそのようなエラーを検出できるはずである。場合によっては、別のコードワードにヒットするほどデータが破損する可能性があるため、すべてのケースをチェックするのは難しいかもしれない。 説明に役立つ例として、長さＮのＣＲＣの場合、ランダムデータでこれが発生する確率は ～２－Ｎであるかもしれない。幾つかの使用ケースでは、メッセージの一部がチャネルによって、場合によっては意図的に変更されるかもしれない。例えば、幾つかの展開シナリオでは、ネットワークアドレス変換（ＮＡＴ）デバイスによって行われるように、アドレスが変更されるかもしれない。
【0047】
特に、前述のように、説明を簡単にするために、ＣＲＣは、本開示全体を通して例として使用される（ただし、いかなる種類の制限としても使用されない）。しかしながら、当業者によって理解され認識されるように、本開示で提案される技術は、他の同様のチェック値にも同様に適用可能であってもよい（必要に応じて、小さな修正および／または適応を伴う可能性がある）。
【0048】
ここで、本開示の可能な実施形態の詳細に入る前に、本明細書で例示されるシステムは、説明を簡単にするため、最も単純な形式で、３つの部分、すなわち、送信機（または送信端／側のデバイス）、リマッパー（またはリマッピングデバイス）、および受信機（または受信端／側のデバイス)からなることができると仮定してもよい。もちろん、当業者によって理解され認識されるように、実際には（すなわち、現実の実装では）、そのシステムは、必要に応じて他の適切な要素／構成要素を確実に含んでもよい。
【0049】
一般的に言えば、そのようなシステム構成では、送信機は通常、受信機内の（または関連する）特定のアドレスにアクセスしようとする。簡潔にするために、本開示全体を通して、これは、（第１の）「メッセージ」の形で例示的に指し示され、または示されてもよい：
｛ＡＤＤＲ、ＤＡＴＡ、ＣＲＣ｝、
ここで、「ＡＤＤＲ」は一般に、送信機の観点からアクセスされように意図されたアドレスを示し、「ＤＡＴＡ」は一般に、ペイロードデータ（上に示したように、制御信号も含んでもよい）を示し、「ＣＲＣ」は一般に、適切なＣＲＣ（アルゴリズム）を使用して計算されたチェック値を示す。先で指摘したように、本明細書で使用されると、「メッセージ」自体は、特定のフォーマットに従って（例えば、使用されている対応するプロトコルに応じて）カプセル化（例えば、コード化）されてもよい（必ずしもそうである必要はない）。ただし、「メッセージ」は、特定の要素／構成要素の（仮想）コレクションを単に言及する、つまり、必ずしもそれらをエンコードする（または連結させる）ことなく、広い意味で理解できることに注意してください。
｛ＡＤＤＲ、ＤＡＴＡ、ＣＲＣ｝、
ここで、「ＡＤＤＲ」は一般に、送信機の観点からアクセスされように意図されたアドレスを示し、「ＤＡＴＡ」は一般に、ペイロードデータ（上に示したように、制御信号も含んでもよい）を示し、「ＣＲＣ」は一般に、適切なＣＲＣ（アルゴリズム）を使用して計算されたチェック値を示す。先で指摘したように、本明細書で使用されると、「メッセージ」自体は、特定のフォーマットに従って（例えば、使用されている対応するプロトコルに応じて）カプセル化（例えば、コード化）されてもよい（必ずしもそうである必要はない）。ただし、「メッセージ」は、特定の要素／構成要素の（仮想）コレクションを単に言及する、つまり、必ずしもそれらをエンコードする（または連結させる）ことなく、広い意味で理解できることに注意してください。
【0050】
さて、このアドレス（「ＡＤＤＲ」)がリマッパーに知られている場合、アドレスは受信機用に変更（リマップ）され、受信機は直ちに見る：
｛ＮＥＷ＿ＡＤＤＲ、ＤＡＴＡ、ＣＲＣ｝、
ここで、「ＮＥＷ＿ＡＤＤＲ」は、通常、受信機の観点からリマッピングされた（変更された）アドレスを示す。
｛ＮＥＷ＿ＡＤＤＲ、ＤＡＴＡ、ＣＲＣ｝、
ここで、「ＮＥＷ＿ＡＤＤＲ」は、通常、受信機の観点からリマッピングされた（変更された）アドレスを示す。
【0051】
このようなアドレスの変更により、元のＣＲＣは正しくないだろう。これが起こるのを防止するために、本開示の提案された技術を適用することによって、リマッパーは、新しいアドレスが使用されている場合でも、アドレス + データ領域に渡る元のＣＲＣが依然として正しいリマッピング値（時には「ｒｅｍａｐ＿ｖａｌｕｅ」として示される）を決定（例えば、計算）して送信しなければならないだろう。
【0052】
一部の可能な実装では、例えばハードウェアで実装されたバスの場合など、すべてのフロムツー（Ｆｒоｍ－ｔо）アドレスのペアがわかっている場合、リマッピング値を事前に計算してもよい。そのような場合、(事前に計算された) リマッピング値は、例えば、後でアクセス／検索を容易にするためにルックアップテーブル（ＬＵＴ） に事前に格納され、それによってリマッパー自体の複雑さと領域を大幅に削減してもよい。
【0053】
さまざまな実装および／または要件に応じて、リマッピング値は、例えば、ＣＲＣ（本開示を通じて「ＣＲＣ＿ＬＥＮ」と示される）と少なくとも同じ長さ（すなわち、それ以上）になるように決定されてもよい。通常、この長さにより、リマッピング値が任意のＣＲＣ値を他の任意のＣＲＣ値にマップできるようになる。実際のさまざまなＣＲＣの実装に応じて、これはたとえば８ビット（以下の例示的な例で使用および示されているように)、またはその他の適切な長さの値になるだろう。同様に、他のタイプのチェック値が使用または実装される場合、長さは、当業者によって理解され認識されるように、それに応じてそれらのチェック値の実装によって異なってもよい。
【0054】
受信機が受信した（第２の）メッセージは、直ちに、次のようになる：
｛ＮＥＷ＿ＡＤＤＲ、ｒｅｍaｐ＿ｖａｌｕｅ、ＤＡＴＡ、ＣＲＣ｝。
｛ＮＥＷ＿ＡＤＤＲ、ｒｅｍaｐ＿ｖａｌｕｅ、ＤＡＴＡ、ＣＲＣ｝。
【0055】
いくつかの可能な実装では、リマッピング値は古いアドレスと新しいアドレスのみに依存してもよく、つまり、データ値とデータ長には依存しない。
【0056】
理解を容易にするために、以下の表１ に、古い (初期) アドレスと新しい (最終) アドレスを考慮したリマッピング値の可能な例を概略的にいくつか示す。特に、以下の表の最後の列は最初の３つから計算され、主に参照用に示されている。
【0057】
【表1】
【0058】
例えば、特定の「ＣＲＣ８＿８Ｈ２Ｆ」アルゴリズム（表１の最後の列に示されているように）を使用して、最初の行に示されているような例を通してステップを実行し、例えば、幾つかの可能なオンラインを活用して実行される：
の初期アドレス (太字で示されている最後の０ｘ００は通常、パディングゼロとして挿入される) はＣＲＣ値０ｘ１２を与え；
一方、最終アドレス（例えば、リマッピング後）
（太字で示されている０ｘ５Ａは、表１の第３列目で計算されたそれぞれのリマッピング値である）も同じＣＲＣ値０ｘ１２を与える。
一方、最終アドレス（例えば、リマッピング後）
【0059】
この時点 (つまり、上記のように、最初のアドレスの０バイトと最後のアドレスのｒｅｍａｐ＿ｖａｌｕｅとの後）で同じＣＲＣを持つ両方の性質は、ＣＲＣユニットがまったく同じ状態にあるということである。そのことを知っているにも関わらず、この時点までのデータは変更されていない（つまり、破損していない）。要するに、これは通常、メッセージ全体で計算されたＣＲＣが変更されていないことを意味する。
【0060】
これを確認または検証するのはかなり簡単である（例えば、上記で使用したものと同じオンラインの「ＣＲＣ８＿８Ｈ２Ｆ」計算機を使用する)。例えば、最初の行を例にとると、次のようになる：
【0061】
【表2】
【0062】
同じことが、他の行、例えば、表１の第２行目についても示され得る；
【0063】
【表3】
【0064】
同様に、異なるデータ（異なるデータ長を含む）などについても同じことが適用できる。例えば：
【0065】
【表4】
【0066】
要約すると、上記で説明したリマッピング値により、一般に、メッセージの一部が変更されているにもかかわらず、メッセージ全体の元のＣＲＣが依然として正しいことを許容する。これは、本開示の背後にある中心的な考え方であり、他のアプリケーションに真の価値をもたらす。例えば、いくつかの例示的なプロトコルでは、データ長がキロバイト（ＫＢ）を超えるかもしれない。ここで提案された技術は、リマッパーがメッセージをやみくもに（または、言い換えると、前に示したようにチェックする必要なく）リマップできるようにし、受信機にメッセージ全体のＣＲＣが有効かどうかを処理させることを可能にし、それによって、リマッパーの非常に効率的な実装を可能にする。
【0067】
さらに、提案された技術を使用した保護は、エンドツーエンドと見なしてもよく、これは、リマッパーを含む相互接続（送信側と受信側との間）の障害により、相手側でチェックされる場合には、ＣＲＣが不正確になる可能性があるためである。
【0068】
ここで、リマッピング値がどのように計算される可能性があるかについて、特にその理解を助けるための例示的な実装のいくつかを示すことによって、より詳細に説明することは価値があるかもしれない。にも拘わらず、リマッピング値を計算するための例示的な実装は、提案された技術を理解するための例として役立つだけであり、したがって、いかなる種類の制限としても決して考慮されるべきではないことに注意してください。確かに、リマッピング値は、当業者によって理解され認識されるように、任意の他の適切な手段で決定（例えば、計算）されてもよい。さらに、本明細書で提案される例示的な実装は、チェック値技術として使用されるＣＲＣの一般的な仮定の下にある。つまり、「リマッピング値」の概念を他の可能なチェック値の実装に適用する場合、さらなる変更および／または適応が必要になるかもしれない。
【0069】
一般的に言えば、ＣＲＣなどの優れたチェック値アルゴリズムは、チェッカーの２つの状態間を（一意に）マッピングできるべきである。例えば、０ｘＢＥと０ｘＥＦのＣＲＣ 間でマッピングするために、これを、すなわち、ＣＲＣ実装のために使用される多項式０ｘＦ１２の場合には０ｘＦ４を実現できる１つ（理想的には１つだけ）の 「ｒｅｍａｐ＿ｖａｌｕｅ」（ＣＲＣと同じ長さ）が存在する。
【0070】
この品質により、一般に、ＣＲＣの１バイトを効果的に「反転」できるかもしれない。
別の言い方をすれば、「ＣＲＣの現在値とｒｅｍａｐ＿ｖａｌｕｅが与えられた場合に、新しいＣＲＣは何か？」と尋ねる代わりに、「ＣＲＣの現在の値と新しいＣＲＣの値とが与えられた場合に、ｒｅｍａｐ＿ｖａｌｕｅは何か？」と尋ねるかもしれない。
別の言い方をすれば、「ＣＲＣの現在値とｒｅｍａｐ＿ｖａｌｕｅが与えられた場合に、新しいＣＲＣは何か？」と尋ねる代わりに、「ＣＲＣの現在の値と新しいＣＲＣの値とが与えられた場合に、ｒｅｍａｐ＿ｖａｌｕｅは何か？」と尋ねるかもしれない。
【0071】
これの簡単な例は、典型的なＣＲＣ多項式Ｐ（ｘ）＝ｘ４＋ｘ０を使用することによって説明される。
【0072】
当業者によって理解され認識されるように、これは一般に、ニブル単位のＸＯＲ、すなわち、ＣＲＣ（０ｘ１、０ｘ２）＝０ｂ０００１＾０ｂ００１０＝０ｂ００１１＝０ｘ３と見なされる。同様に、ＣＲＣ（０ｘＥ、０ｘＦ）＝０ｘ１である。
【0073】
したがって、それは、
ＣＲＣ＿ＮＥＷ＝ＣＲＣ＿ОＬＤ＾ＤＡＴＡ＿ＮＥＷ
と記述されてもよく、例えば、ＣＲＣ＿ＮＥＷ、ＣＲＣ＿ОＬＤ、ＤＡＴＡ＿ＮＥＷはすべて４ビットの長さ（または、いくつかの可能な実装では他の適切な長さ）であってもよい。
ＣＲＣ＿ＮＥＷ＝ＣＲＣ＿ОＬＤ＾ＤＡＴＡ＿ＮＥＷ
と記述されてもよく、例えば、ＣＲＣ＿ＮＥＷ、ＣＲＣ＿ОＬＤ、ＤＡＴＡ＿ＮＥＷはすべて４ビットの長さ（または、いくつかの可能な実装では他の適切な長さ）であってもよい。
【0074】
そして、それは、古いＣＲＣ値と新しいＣＲＣ値
ＣＲＣ＿ＮＥＷ＝ＣＲＣ＿ОＬＤ＾ＤＡＴＡ＿ＮＥＷ
に関してデータを計算するために再配置してもよい。
ＣＲＣ＿ＮＥＷ＝ＣＲＣ＿ОＬＤ＾ＤＡＴＡ＿ＮＥＷ
に関してデータを計算するために再配置してもよい。
【0075】
上記を前の例に適用すると、ＣＲＣ＿ＲＥＶ（０ｘ１、０ｘ３）＝０ｘ２およびＣＲＣ＿ＲＥＶ（０ｘＥ、０ｘ１）＝０ｘＦが得られ、ＣＲＣ＿ＲＥＶは反転したＣＲＣ操作を示すために使用される。
【0076】
上記の概念を念頭に置いて、より現実的な例に適用でき、たとえば、古い（リマッピング前の）アドレスＦＲОＭ＿ＡＤＤＲＥＳＳ＝０ｘＣ０ＥＦと新しい（リマッピング後の）アドレスＴО＿ＡＤＤＲＥＳＳ＝０ｘＥＥＥＥを想定すると、ターゲットと現在のＣＲＣ値はそれぞれ、
ｔａｇｅｔ＿ｃｒｃ＝ＣＲＣ＊（｛ＦＲОＭ＿ＡＤＤＲＥＳＳ、ＣＲＣ＿ＬＥＮ′ｂ０｝）
＝ＣＲＣ（｛０ｘＣ０ＦＦ、０ｘ０｝）＝０ｘＣ
ｃｕｒｒｅｎｔ＿ｃｒｃ＝ＣＲＣ＊（ＴО＿ＡＤＤＲＥＳＳ）
＝ＣＲＣ（０ｘＥＥＥＥ）＝０ｘ０
として計算できる。
ｔａｇｅｔ＿ｃｒｃ＝ＣＲＣ＊（｛ＦＲОＭ＿ＡＤＤＲＥＳＳ、ＣＲＣ＿ＬＥＮ′ｂ０｝）
＝ＣＲＣ（｛０ｘＣ０ＦＦ、０ｘ０｝）＝０ｘＣ
ｃｕｒｒｅｎｔ＿ｃｒｃ＝ＣＲＣ＊（ＴО＿ＡＤＤＲＥＳＳ）
＝ＣＲＣ（０ｘＥＥＥＥ）＝０ｘ０
として計算できる。
【0077】
そして、上記の「反転」操作を適用すると、それぞれのリマッピングは、
ｒｅｍａｐ＿ｖａｌｕｅ＝ＣＲＣ＿ＲＥＶ（ｃｕｒｒｅｎｔ＿ｃｒｃ、ｔａｇｅｔ＿ｃｒｃ）＝ＣＲＣ＿ＲＥＶ（０ｘ０、０ｘＣ）＝０ｘＣ
として計算されてもよい。
ｒｅｍａｐ＿ｖａｌｕｅ＝ＣＲＣ＿ＲＥＶ（ｃｕｒｒｅｎｔ＿ｃｒｃ、ｔａｇｅｔ＿ｃｒｃ）＝ＣＲＣ＿ＲＥＶ（０ｘ０、０ｘＣ）＝０ｘＣ
として計算されてもよい。
【0078】
特に、最終的な値が正しい場合、これらのＣＲＣが実際にどのように計算されるかは一般的に問題ではない。例えば、いくつかの可能な実装では、並列実装の概念をさらに適用すると、計算は、ｎの値によって依存して、ちょうどＣＲＣ［ｎ］＝ＤＡＴＡ［０＋ｎ］＾ＤＡＴＡ［４＋ｎ］＾ＤＡＴＡ［８＋ｎ］…のように見える。
【0079】
要約すると、上記の説明を考慮して、当初の（最初の）メッセージ（つまり、リマッピング前）は、
{０ｘＣОＦＦ、０ｘ０、ＤＡＴＡ、ＣＲＣ}
として表示されるかもしれず、一方、対応する最終（第２）のメッセージ（つまり、リマッピング後）は、
{０ｘＥＥＥＥ、０ｘＣ、ＤＡＴＡ、ＣＲＣ}
として表示されるかもしれない。
{０ｘＣОＦＦ、０ｘ０、ＤＡＴＡ、ＣＲＣ}
として表示されるかもしれず、一方、対応する最終（第２）のメッセージ（つまり、リマッピング後）は、
{０ｘＥＥＥＥ、０ｘＣ、ＤＡＴＡ、ＣＲＣ}
として表示されるかもしれない。
【0080】
前述のように、これは簡単にチェックまたは検証できる（例えば、オンラインの計算機を使用することによって)。
【0081】
それにもかかわらず、いくつかの可能な実装では、一部の可能なＣＲＣスキームがいわゆる「ｆｉｎａｌ ｘоｒ」操作を適用する傾向があるため、いくつかの（追加の）注意が必要になる場合があることに注意してください。これらの計算では、最終的な値ではなく、ＣＲＣの中間値が一般的に重要な場合がある。したがって、この「ｆｉｎｌ xor」は一般的に避けるべきである。
【0082】
前に示したように、同じプロセスを他のＣＲＣ実装にも適用してよい（必要に応じて、必要な修正および／または適応を伴う可能性がある）。ここで、多項式０ｘ１２Ｆは、さらに説明する目的で、以下の別の例として使用されてもよい。
【0083】
特に、そのような場合、以下の計算が実行されてもよい。
【0084】
ｃｒｃ＿ｎｅｗ［０］＝ｒｅｍａｐ［０］＾ｒｅｍａｐ［３］＾ｒｅｍａｐ［５］＾ｒｅｍａｐ［７］＾ｃｒｃ［０］＾ｃｒｃ［３］＾ｃｒｃ［５］＾ｃｒｃ［７］
ｃｒｃ＿ｎｅｗ［１］＝ｒｅｍａｐ［０］＾ｒｅｍａｐ［１］＾ｒｅｍａｐ［３］＾ｒｅｍａｐ［４］＾ｒｅｍａｐ［５］＾ｒｅｍａｐ＾［６］＾ｒｅｍａｐ［７］＾ｃｒｃ［０］＾ｃｒｃ［１］＾ｃｒｃ［３］＾ｃｒｃ［４］＾ｃｒｃ［５］＾ｃｒｃ［６］＾ｃｒｃ［７］
ｃｒｃ＿ｎｅｗ［２］＝ｒｅｍａｐ［０］＾ｒｅｍａｐ［１］＾ｒｅｍａｐ［２］＾ｒｅｍａｐ［３］＾ｒｅｍａｐ［４］＾ｒｅｍａｐ＾［６］＾ｒｅｍａｐ［７］＾ｃｒｃ［０］＾ｃｒｃ［１］＾ｃｒｃ［２］＾ｃｒｃ［３］＾ｃｒｃ［４］＾ｃｒｃ［６］
ｃｒｃ＿ｎｅｗ［３］＝ｒｅｍａｐ［０］＾ｒｅｍａｐ［１］＾ｒｅｍａｐ［２］＾ｒｅｍａｐ［４］＾ｃｒｃ［０］＾ｃｒｃ［１］＾ｃｒｃ［２］＾ｃｒｃ［４］
ｃｒｃ＿ｎｅｗ［４］＝ｒｅｍａｐ［１］＾ｒｅｍａｐ［２］＾ｒｅｍａｐ［３］＾ｒｅｍａｐ［５］＾ｃｒｃ［１］＾ｃｒｃ［２］＾ｃｒｃ［３］＾ｃｒｃ［５］
ｃｒｃ＿ｎｅｗ［５］＝ｒｅｍａｐ［０］＾ｒｅｍａｐ［２］＾ｒｅｍａｐ［４］＾ｒｅｍａｐ［５］＾ｒｅｍａｐ［７］＾ｃｒｃ［０］＾ｃｒｃ［２］＾ｃｒｃ［４］＾ｃｒｃ［５］＾ｃｒｃ［６］＾ｃｒｃ［７］
ｃｒｃ＿ｎｅｗ［６］＝ｒｅｍａｐ［１］＾ｒｅｍａｐ［３］＾ｒｅｍａｐ［５］＾ｒｅｍａｐ［６］＾ｒｅｍａｐ［７］＾ｃｒｃ［１］＾ｃｒｃ［３］＾ｃｒｃ［５］＾ｃｒｃ［６］＾ｃｒｃ［７］
ｃｒｃ＿ｎｅｗ［７］＝ｒｅｍａｐ［２］＾ｒｅｍａｐ［４］＾ｒｅｍａｐ［６］＾ｒｅｍａｐ［７］＾ｃｒｃ［２］＾ｃｒｃ［４］＾ｃｒｃ［６］＾ｃｒｃ［７］
ｃｒｃ＿ｎｅｗ［１］＝ｒｅｍａｐ［０］＾ｒｅｍａｐ［１］＾ｒｅｍａｐ［３］＾ｒｅｍａｐ［４］＾ｒｅｍａｐ［５］＾ｒｅｍａｐ＾［６］＾ｒｅｍａｐ［７］＾ｃｒｃ［０］＾ｃｒｃ［１］＾ｃｒｃ［３］＾ｃｒｃ［４］＾ｃｒｃ［５］＾ｃｒｃ［６］＾ｃｒｃ［７］
ｃｒｃ＿ｎｅｗ［２］＝ｒｅｍａｐ［０］＾ｒｅｍａｐ［１］＾ｒｅｍａｐ［２］＾ｒｅｍａｐ［３］＾ｒｅｍａｐ［４］＾ｒｅｍａｐ＾［６］＾ｒｅｍａｐ［７］＾ｃｒｃ［０］＾ｃｒｃ［１］＾ｃｒｃ［２］＾ｃｒｃ［３］＾ｃｒｃ［４］＾ｃｒｃ［６］
ｃｒｃ＿ｎｅｗ［３］＝ｒｅｍａｐ［０］＾ｒｅｍａｐ［１］＾ｒｅｍａｐ［２］＾ｒｅｍａｐ［４］＾ｃｒｃ［０］＾ｃｒｃ［１］＾ｃｒｃ［２］＾ｃｒｃ［４］
ｃｒｃ＿ｎｅｗ［４］＝ｒｅｍａｐ［１］＾ｒｅｍａｐ［２］＾ｒｅｍａｐ［３］＾ｒｅｍａｐ［５］＾ｃｒｃ［１］＾ｃｒｃ［２］＾ｃｒｃ［３］＾ｃｒｃ［５］
ｃｒｃ＿ｎｅｗ［５］＝ｒｅｍａｐ［０］＾ｒｅｍａｐ［２］＾ｒｅｍａｐ［４］＾ｒｅｍａｐ［５］＾ｒｅｍａｐ［７］＾ｃｒｃ［０］＾ｃｒｃ［２］＾ｃｒｃ［４］＾ｃｒｃ［５］＾ｃｒｃ［６］＾ｃｒｃ［７］
ｃｒｃ＿ｎｅｗ［６］＝ｒｅｍａｐ［１］＾ｒｅｍａｐ［３］＾ｒｅｍａｐ［５］＾ｒｅｍａｐ［６］＾ｒｅｍａｐ［７］＾ｃｒｃ［１］＾ｃｒｃ［３］＾ｃｒｃ［５］＾ｃｒｃ［６］＾ｃｒｃ［７］
ｃｒｃ＿ｎｅｗ［７］＝ｒｅｍａｐ［２］＾ｒｅｍａｐ［４］＾ｒｅｍａｐ［６］＾ｒｅｍａｐ［７］＾ｃｒｃ［２］＾ｃｒｃ［４］＾ｃｒｃ［６］＾ｃｒｃ［７］
【0085】
上記の例では、一般的に言えば、初期データ「ｃｒｃ」を含む多項式 ０ｘ１２Ｆのフィードフォワード実装を取得し、新しいデータ「ｒｅｍａｐ」でクロッキングすることによって方程式が計算される。もちろん、当業者によって理解され認識されるように、他の適切な計算方法も同様に実施されてもよい。
【0086】
いくつかの可能な実装では、ガウス消去法を適用して、ｃｒｃとｃｒｃ＿ｎｅｗの関数としてｒｅｍａｐを与えてもよく、次に例のようである。
【0087】
ｒｅｍａｐ［０］＝ｃｒｃ［０］＾ｃｒｃ＿ｎｅｗ［１］＾ｃｒｃ＿ｎｅｗ［４］＾ｃｒｃ＿ｎｅｗ［７］、
ｒｅｍａｐ［１］＝ｃｒｃ［１］＾ｃｒｃ＿ｎｅｗ［０］＾ｃｒｃ＿ｎｅｗ［１］＾ｃｒｃ＿ｎｅｗ［２］＾ｃｒｃ＿ｎｅｗ［４］＾ｃｒｃ＿ｎｅｗ［５］＾ｃｒｃ＿ｎｅｗ［７］、
ｒｃ＿ｎｅｗ［７］、
ｒｅｍａｐ［２］＝ｃｒｃ［２］＾ｃｒｃ＿ｎｅｗ［０］＾ｃｒｃ＿ｎｅｗ［２］＾ｃｒｃ＿ｎｅｗ［３］＾ｃｒｃ＿ｎｅｗ［４］＾ｃｒｃ＿ｎｅｗ［５］＾ｃｒｃ＿ｎｅｗ［６］＾ｃｒｃ＿ｎｅｗ［７］、
ｒｅｍａｐ［３］＝ｃｒｃ［３］＾ｃｒｃ＿ｎｅｗ［３］＾ｃｒｃ＿ｎｅｗ［５］＾ｃｒｃ＿ｎｅｗ［６］、
ｒｅｍａｐ［４］＝ｃｒｃ［４］＾ｃｒｃ＿ｎｅｗ［４］＾ｃｒｃ＿ｎｅｗ［６］＾ｃｒｃ＿ｎｅｗ［７］、
ｒｅｍａｐ［５］＝ｃｒｃ［５］＾ｃｒｃ＿ｎｅｗ［１］＾ｃｒｃ＿ｎｅｗ［４］＾ｃｒｃ＿ｎｅｗ［５］
ｒｅｍａｐ［６］＝ｃｒｃ［６］＾ｃｒｃ＿ｎｅｗ［２］＾ｃｒｃ＿ｎｅｗ［５］＾ｃｒｃ＿ｎｅｗ［６］、
ｒｅｍａｐ［７］＝ｃｒｃ［７］＾ｃｒｃ＿ｎｅｗ［０］＾ｃｒｃ＿ｎｅｗ［３］＾ｃｒｃ＿ｎｅｗ［６］＾ｃｒｃ＿ｎｅｗ［７］。
ｒｅｍａｐ［１］＝ｃｒｃ［１］＾ｃｒｃ＿ｎｅｗ［０］＾ｃｒｃ＿ｎｅｗ［１］＾ｃｒｃ＿ｎｅｗ［２］＾ｃｒｃ＿ｎｅｗ［４］＾ｃｒｃ＿ｎｅｗ［５］＾ｃｒｃ＿ｎｅｗ［７］、
ｒｃ＿ｎｅｗ［７］、
ｒｅｍａｐ［２］＝ｃｒｃ［２］＾ｃｒｃ＿ｎｅｗ［０］＾ｃｒｃ＿ｎｅｗ［２］＾ｃｒｃ＿ｎｅｗ［３］＾ｃｒｃ＿ｎｅｗ［４］＾ｃｒｃ＿ｎｅｗ［５］＾ｃｒｃ＿ｎｅｗ［６］＾ｃｒｃ＿ｎｅｗ［７］、
ｒｅｍａｐ［３］＝ｃｒｃ［３］＾ｃｒｃ＿ｎｅｗ［３］＾ｃｒｃ＿ｎｅｗ［５］＾ｃｒｃ＿ｎｅｗ［６］、
ｒｅｍａｐ［４］＝ｃｒｃ［４］＾ｃｒｃ＿ｎｅｗ［４］＾ｃｒｃ＿ｎｅｗ［６］＾ｃｒｃ＿ｎｅｗ［７］、
ｒｅｍａｐ［５］＝ｃｒｃ［５］＾ｃｒｃ＿ｎｅｗ［１］＾ｃｒｃ＿ｎｅｗ［４］＾ｃｒｃ＿ｎｅｗ［５］
ｒｅｍａｐ［６］＝ｃｒｃ［６］＾ｃｒｃ＿ｎｅｗ［２］＾ｃｒｃ＿ｎｅｗ［５］＾ｃｒｃ＿ｎｅｗ［６］、
ｒｅｍａｐ［７］＝ｃｒｃ［７］＾ｃｒｃ＿ｎｅｗ［０］＾ｃｒｃ＿ｎｅｗ［３］＾ｃｒｃ＿ｎｅｗ［６］＾ｃｒｃ＿ｎｅｗ［７］。
【0088】
このセクションで与えられた最初の例、つまり、ｃｒｃ＝０ｘＢＥ（０ｂ１０１１＿１１１０）およびｃｒｃ＿ｎｅｗ＝０ｘＥＦ＝（０ｂ１１１０＿１１１１）に上記の計算を適用すると、次のようになる。
【0089】
【表5】
【0090】
その結果、リマップ値は、ｒｅｍａｐ＝０ｂ１１１１＿０１００＝０ｘＦ４として決定される。
【0091】
ここで、リマッピング値を計算するためのさらに別の可能な（簡略化された）実装を例示的に説明する。
【0092】
具体的には、（非フィードフォワード）ＣＲＣは典型的には、次のように計算されてもよい：
ＣＲＣ（Ａ）＝Ｆ（｛Ａ、ＣＲＣ＿ＬＥＮ＊０｝）＝a
ここに、Ｆは一般に、最後に０を追加した状態でメッセージＡに適用される関数を表している。いくつかの可能なハードウェア実装では、Ｆは通常、シフトレジスタとＸＯＲゲートを使用して実装されてもよい。
ＣＲＣ（Ａ）＝Ｆ（｛Ａ、ＣＲＣ＿ＬＥＮ＊０｝）＝a
ここに、Ｆは一般に、最後に０を追加した状態でメッセージＡに適用される関数を表している。いくつかの可能なハードウェア実装では、Ｆは通常、シフトレジスタとＸＯＲゲートを使用して実装されてもよい。
【0093】
これは、メッセージＡをＣＲＣ多項式で割ったときの剰余を計算している。次に、Ｆ（｛Ａ、a｝）＝０ となるような｛Ａ、ａ｝の新しいメッセージを与えることで、そのメッセージから剰余を差し引くことができる。
【0094】
それから、ＣＲＣからゼロ以外の値を取得するには、（ＸＯＲ操作を使用して）ターゲット値、つまり、Ｆ（｛Ａ、ａ＾ｘ｝）＝ｘを追加でき、これは一般に、２つのメッセージ間のリマッピング値を取得するために使用されるコア操作と見なすことができる。
【0095】
説明に役立つ例として、第２のメッセージ（メッセージ２)のＣＲＣを第１のメッセージ （メッセージ１）のＣＲＣと同じにするために、一般的に次のように仮定することができる：
メッセージ１：ＣＲＣ（Ａ）＝Ｆ（｛Ａ、ＣＲＣ＿ＬＥＮ＊０｝）＝ａ、
メッセージ２：ＣＲＣ（Ｂ）＝Ｆ（｛Ｂ、ＣＲＣ＿ＬＥＮ＊０｝）＝ｂ。
メッセージ１：ＣＲＣ（Ａ）＝Ｆ（｛Ａ、ＣＲＣ＿ＬＥＮ＊０｝）＝ａ、
メッセージ２：ＣＲＣ（Ｂ）＝Ｆ（｛Ｂ、ＣＲＣ＿ＬＥＮ＊０｝）＝ｂ。
【0096】
ここで、上記の概念を適用して、メッセージ２のＣＲＣを０（すなわち、剰余の減算）に等しくするために：
メッセージ２：Ｆ（｛Ｂ、ｂ｝）＝０
である。
メッセージ２：Ｆ（｛Ｂ、ｂ｝）＝０
である。
【0097】
次に、新しい必要な剰余（a）、
メッセージ２：Ｆ（｛Ｂ、ｂ＾a｝）＝a
が追加される。
メッセージ２：Ｆ（｛Ｂ、ｂ＾a｝）＝a
が追加される。
【0098】
いくつかの可能な実装では、この操作の連鎖が第３のメッセージ（特に、いくつかの可能な例では、第３のメッセージは元のメッセージと最新のメッセージのみに依存する場合がある）に対してさらに実行されてもよく、例えば、
メッセージ２：Ｆ（｛Ｂ、ｂ＾a｝）＝a、
メッセージ３：ＣＲＣ（Ｃ）＝Ｆ（｛Ｃ、ＣＲＣ＿ＬＥＮ＊０｝）＝ｃ
である。
メッセージ２：Ｆ（｛Ｂ、ｂ＾a｝）＝a、
メッセージ３：ＣＲＣ（Ｃ）＝Ｆ（｛Ｃ、ＣＲＣ＿ＬＥＮ＊０｝）＝ｃ
である。
【0099】
上記と同様に、剰余を０に設定すると｛Ｃ、ｃ｝が生成され、剰余をａに設定すると｛Ｃ、ｃ＾ａ｝が生成されるだろう。
【0100】
上記の概念は、次のように、より一般的な形式に定式化できる：
前のメッセージ：Ｆ（｛Ｍ、ＲＥＭＡＰ＿ＶＡＬ｝）＝ｒｅｍａｐ＿ｔaｇｅｔ（ここに、ＲＥＭＡＰ＿ＶＡＬは、設定される前の最初の段階では０である）、
新しいメッセージの剰余：Ｆ（｛Ｎ、０｝）＝ｎ、
リマップされた新しいメッセージ：｛Ｎ、ＮＥＷ＿ＲＥＭＡＰ＿ＶＡＬ｝＝｛Ｎ、ｎ＾ｒｅｍａｐ＿ｔａｒｇｅｔ｝
である。
前のメッセージ：Ｆ（｛Ｍ、ＲＥＭＡＰ＿ＶＡＬ｝）＝ｒｅｍａｐ＿ｔaｇｅｔ（ここに、ＲＥＭＡＰ＿ＶＡＬは、設定される前の最初の段階では０である）、
新しいメッセージの剰余：Ｆ（｛Ｎ、０｝）＝ｎ、
リマップされた新しいメッセージ：｛Ｎ、ＮＥＷ＿ＲＥＭＡＰ＿ＶＡＬ｝＝｛Ｎ、ｎ＾ｒｅｍａｐ＿ｔａｒｇｅｔ｝
である。
【0101】
ここで、理解を容易にするために、上記のスキームは、７Ｄの初期値を持つ非フィードフォワードＣＲＣ－多項式０ｘ１２Ｆを使用する例に例示的に適用される。
【0102】
【表6】
【0103】
上の表で示されるように、全てのメッセージ１～４は、０ｘ５Ｃの同じＣＲＣ値（０ｘ１２Ｆの多項式の前提の下に、０ｘＦＦの初期値および０ｘＦＦの最終ＸＯＲ）を与える。
【0104】
より長いＣＲＣ用に上記の実装を拡張すると、この方法を使用して自明にもなるだろう。可能な例は、主に例証目的で以下に概略的にも示される。
【0105】
【表7】
【0106】
簡単にチェックまたは検証できるように、非反映されたデータをもつ０ｘ４Ｃ１１ＤＢ７の多項式、０ｘＦＦＦＦＦＦＦＦの初期値、および０ｘＦＦＦＦＦＦＦＦの最終ＸＯＲの仮定の下で、すべてのメッセージ１～４は同じＣＲＣ値０ｘ５Ｆ０５ＢＦＤ５を与える。
【0107】
さて、リマッピング値がどのように決定されるか（例えば、計算されるか）に関するいくつかの可能な実装が上で非常に詳細に示されたので、本開示で提案される技術のいくつかの可能な実施形態を以下で説明されるかもしれない。
【0108】
特に、図２～４は、例示的な例としてバスベースのシステム（より正確には、ＡＨＢ（Ａｄｖａｎｃｅｄ Ｈｉｇｈ－ｐｅｒｆｏｒｍａｎｃｅ Ｂｕｓ）Ｌｉｔｅ）を使用することによって可能な実施形態を概略的に示す。より具体的には、図２は、本開示の実施形態によるリマッパーを有するバス設計の例示的なシステム概観２００を概略的に示す。図３は、本開示の実施形態による、ＣＲＣを伴うバス書き込み動作のタイミング図の一例を概略的に示す図である。図４は、本開示の実施形態による、ＣＲＣを伴うバス読み取り動作のタイミング図の一例を概略的に示す図である。しかしながら、当業者には理解され認識されるように、そのようなバスベースのシステムは単に説明のための例として役立つだけであり、いかなる種類の制限としても機能しない。本開示を通じて提案される技術は、他の適切なシステムにも確実に適用されてよい（必要に応じて、可能な修正および／または適応を伴って）。さらに、一般的に言えば、ＡＨＢ Ｌｉｔｅ は、この分野の当業者（例えば、自動車産業) にとって比較的一般的なプロトコルであると考えられているため、すでによく知られているシステムブロック（または構成要素）の一部について説明が、簡潔にするために省略されるかもしれないことにも注意してください。具体的には、本開示の実施形態に特に関心がある、または関連性があると考えられる信号（メッセージ交換）が、図２の実線の矢印で示されている。
【0109】
図２に示されるような例示的なシステム２００を参照すると、一般的に言えば、アドレスがリマッピングされている場合（おそらく以下の場合に限り）、アドレスフェーズ中に、リマッピング値は、アドレスリマッパー２１０によって更新されてもよい（例えば、上に示されたスキームのいずれかを使用して計算される）。それ以外の場合、一部の可能な実装では、リマッピング値が０のままになるかもしれない。
【0110】
このようなシステムでは、エラーは通常、読み取り失敗の場合はマスター（デバイス） によって検出され、書き込み失敗の場合はスレーブ（デバイス） によって検出される。
【0111】
より具体的には、図３を参照すると、バス書き込み時に、ＣＲＣは次のメッセージに対してマスターによって計算されるかもしれない：
｛ＡＤＤＲ＿ＬＥＮ′Ａｄｄｒｅｓｓ、ＣＲＣ＿ＬＥＮ′０、ＤＡＴＡ＿ＬＥＮ′ｄaｔa｝、
ここに「ＡＤＤＲ＿ＬＥＮ」、「ＣＲＣ＿ＬＥＮ」、および、「ＤＡＴＡ＿ＬＥＮ」という用語は、それぞれの長さを表す（名前が示すように）。上記のように、バス制御信号は、送信する（ペイロード）データの一部と見なしてもよい。
｛ＡＤＤＲ＿ＬＥＮ′Ａｄｄｒｅｓｓ、ＣＲＣ＿ＬＥＮ′０、ＤＡＴＡ＿ＬＥＮ′ｄaｔa｝、
ここに「ＡＤＤＲ＿ＬＥＮ」、「ＣＲＣ＿ＬＥＮ」、および、「ＤＡＴＡ＿ＬＥＮ」という用語は、それぞれの長さを表す（名前が示すように）。上記のように、バス制御信号は、送信する（ペイロード）データの一部と見なしてもよい。
【0112】
それから、Ｈｗｄａｔａ＿ｃｒｃが、計算したＣＲＣ値になるように更新される。
【0113】
このアドレスがリマッピングされている場合、リマッパー２１０はそれに応じてｒｅｍａｐ＿ｖａｌｕｅを次のように更新する、たとえば、
ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′оｌｄ＿aｄｄｒ、ＣＲＣ＿ＬＥＮ′０）＝＝ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′ｎｅｗ＿aｄｄｒ、ＣＲＣ＿ＬＥＮ′ｒｅｍａｐ＿ｖａｌｕｅ）。
ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′оｌｄ＿aｄｄｒ、ＣＲＣ＿ＬＥＮ′０）＝＝ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′ｎｅｗ＿aｄｄｒ、ＣＲＣ＿ＬＥＮ′ｒｅｍａｐ＿ｖａｌｕｅ）。
【0114】
次に、これは、スレーブによって同じ順序でチェックされ、すなわち、
｛ＡＤＤＲ＿ＬＥＮ′ｎｅｗ＿aｄｄｒ、ＣＲＣ＿ＬＥＮ′ｒｅｍａｐ＿ｖａｌｕｅ、ＤＡＴＡ＿ＬＥＮ′ｄａｔａ、ＣＲＣ＿ＬＥＮ′ｈｗｄａｔａ＿ｃｒｃ｝。
｛ＡＤＤＲ＿ＬＥＮ′ｎｅｗ＿aｄｄｒ、ＣＲＣ＿ＬＥＮ′ｒｅｍａｐ＿ｖａｌｕｅ、ＤＡＴＡ＿ＬＥＮ′ｄａｔａ、ＣＲＣ＿ＬＥＮ′ｈｗｄａｔａ＿ｃｒｃ｝。
【0115】
一般的に言えば、ＣＲＣおよび／またはリマッピング値は、プロトコル（例えば、ＡＨＢ、ＡＰＢ（Ａｄｖａｎｃｅｄ Ｐｅｒｉｐｈｅｒａｌ Ｂｕｓ）、または任意の他の適切なプロトコル）のデータと同じ仕様に従うように実装されてもよい。このような場合、ｈＨｗｄａｔａ＿ｃｒｃは通常Ｈｗｄａｔａに続き（同様に、図３に示すように、バス読み出しの場合に、通常Ｈｒｄａｔａ＿ｃｒｃはＨｒｄａｔａに続く)、リマッピング値はアドレスフェーズに従う。この制限を課すことは通常、すべての信号を保護できるわけではないことを意味する。例えば、書き込みサイクル（フェーズ）中、スレーブはＨｒｅａｄｙ信号とＨｒｅｓｐ信号のみを提供してもよい。その結果、これらの信号は別の方法で保護する必要がある（例えば、以下に示す反転複製信号Ｈｒｅａｄｙ＿ｉｎｖに基づく)。
【0116】
より具体的には、自動車の技術分野におけるＡＨＢ Ｌｉｔｅ バスベースのシステム２００の例に従って、メッセージ全体がそれぞれのＣＲＣチェック（例えば、ＡＵＴＯＳＴＡＲ ＣＲＣ）を合格できるように、ＣＲＣ（Ａ）が以下のように定義されてもよい：
[式１]
[式１]
【0117】
したがって、スレーブによってチェックされるときに、メッセージ全体がそれぞれのＣＲＣチェック（例えば、ＡＵＴＯＳＴＡＲ ＣＲＣ）にも合格できるように、Ｒｅｍａｐ（Ａ２） は次のように定義される：
[式２]
[式２]
【0118】
同様に、図３に示すバス読み取り操作の場合、スレーブは、メッセージ全体がそれぞれのＣＲＣチェック（例えば、ＡＵＴＯＳＴＡＲ ＣＲＣ）を合格できるように、スレーブはＣＲＣ（Ａ２）を計算して以下のように定義する：
[式３]
[式３]
【0119】
それに応じて、このような場合、メッセージ全体がそれぞれのＣＲＣチェック（例えば、ＡＵＴＯＳＴＡＲ ＣＲＣ）にも合格できるように、マスターはデータをチェックする：
[式４]
[式４]
【0120】
上に示したように、リマッピング値を計算して挿入することで、例えばリマッパーなどによってメッセージが部分的に更新／リマップ／変更された場合でも、（部分的に更新された）メッセージ全体のチェック値は正しい。そのため、部分的な更新を実行するときに、通常、古いチェック値が正しいことを確認する必要はない。これにより、特にメッセージの大部分が変更されていない場合に、リマッパーの処理能力および／または領域を節約できる。それに反して、従来の技術では、メッセージがリマッピングデバイスによって部分的に更新されるたびに、新しいチェック値を生成する必要がある。新しいチェック値を生成するには、通常、（リマップされる前の）古いメッセージがまだ有効かどうかを最初にチェックする必要があり、そうでなければ、送信機とリマッパーとの間で破損されていたからである。さらに、リマッパーブロックは一般に「適切な値」、つまり、ＣＲＣ生成ロジックを生成する方法を有さないため、本質的に安全である。要するに、リマッパーの障害は受信機で検出することができる。さらに、いくつかの可能な場合には、古いデータ ブロック（つまり、リマッピング前）と新しいデータブロック（つまり、リマッピング後）の間のすべてのマッピングが既にわかっている場合、リマッピング値を事前に計算してもよく、それによって大幅に リマッパー自体の複雑さと領域を低減する。加えて、本開示で提案された技術を使用することにより、標準の更新に対して将来的に保証され得る、より堅牢なシステム設計をさらに可能にすることが可能になるかもしれない。ＩＰの再利用も実現でき、貴重な開発および検証時間を節約できる。さらに、特にバスベースのシステムの場合、提案された技術は、同じアドレスデコーダおよび／またはマルチプレクサロジックを大幅に再利用できるので、追加の領域の利点をもたらすかもしれない。
【0121】
上述の実施形態とは別に、本開示は、その上、以下でより詳細に議論される可能な強化または代替とみなされ得る他の実施形態もカバーし得ることに留意されたい。
【0122】
具体的には、すでに例示的に説明したように、本開示で提案する技術は、アドレス（フィールドまたは領域）がリマッパーによって変更または更新される可能性がある場合に適用されてもよい。しかしながら、データ（またはその一部）が変更される可能性がある場合に、技術が類似または同様に適用可能である可能性があることを理解されたい。
【0123】
例えば（変更されていない値は太字で示されている場合に）、上記の概念
は今は、
になるだろう。
【0124】
当業者によって理解され認識されるように、アドレスがリマッピングされる場合の上記の技術（例えば、リマッピング値の計算）は、ここで等しくまたは同様に適用されるかもしれない。したがって、簡潔にするために、それぞれの説明を省略するかもしれない。
【0125】
いくつかの可能な実装では、エラー検出の粒度を高めるために、（別の）ＣＲＣチェッカーをリマッパー自体に含めることも可能でるかもしれない。ただし、これは通常、それぞれの設計者の決定次第であり、デバッグの容易さと設計領域との間のトレードオフと見なしてもよい。
【0126】
さらに、多数（２つ以上）のリマッパーがシステム（送信機と受信機の間）に展開され、同じ（ペイロード）データで動作するいくつかの可能性のある実装では、さまざまな実装および／または要件に応じて、異なるアプローチが採用されるかもしれない。
【0127】
一例として、リマッパーステージごとに、上記の図と同様に、ＣＲＣの一部として０の追加バイト（つまり、８ビット、またはさまざまな実装に応じて他の適切な長さ）を計算し、追加のリマッピング値を計算してそれをスレーブに渡すかもしれない。
【0128】
一般的に言えば、このアプローチは常に同じ長さのデータに対してＣＲＣを計算するため、スレーブの設計を簡素化するだろう。いくつかの可能な場合には、例えば側波帯信号を使用することでこれを回避することも可能かもしれない（例えば、ｒｅｍａｍｐｐｅｄ＿ｂｙ＿ｓｔａｇｅ＿１などのフラグの形式で実装、または、その他の適切な形式で実装）。 ただし、これにより、多数ステージのリマッパーの設計の複雑さを大幅に増すかもしれない。
【0129】
説明に役立つ例として２つのリマッパーのケースを取り上げると、第１のリマッパーは通常、次のことを実行する：
ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′оｌｄ＿aｄｄｒ、ＣＲＣ＿ＬＥＮ′０、ＣＲＣ＿ＬＥＮ′０）＝＝ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′ｎｅｗ＿aｄｄｒ１、ＣＲＣ＿ＬＥＮ′０、ＣＲＣ＿ＬＥＮ′ｒｅｍａｐ＿ｖａｌｕｅ１）。
ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′оｌｄ＿aｄｄｒ、ＣＲＣ＿ＬＥＮ′０、ＣＲＣ＿ＬＥＮ′０）＝＝ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′ｎｅｗ＿aｄｄｒ１、ＣＲＣ＿ＬＥＮ′０、ＣＲＣ＿ＬＥＮ′ｒｅｍａｐ＿ｖａｌｕｅ１）。
【0130】
続いて、第２のリマッパーが次の処理を実行する：
ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′ｎｅｗ＿aｄｄｒ１、ＣＲＣ＿ＬＥＮ′０）＝＝ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′ｎｅｗ＿aｄｄｒ２、ＣＲＣ＿ＬＥＮ′ｒｅｍａｐ＿ｖａｌｕｅ２）、
全体的なＣＲＣが変更されないようにしている：
ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′оｌｄ＿aｄｄｒ、ＣＲＣ＿ＬＥＮ′０、ＣＲＣ＿ＬＥＮ′０）＝＝ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′ｎｅｗ＿aｄｄｒ２、ＣＲＣ＿ＬＥＮ′ｒｅｍａｐ＿ｖａｌｕｅ２，ＣＲＣ＿ＬＥＮ′ｒｅｍａｐ＿ｖａｌｕｅ１）。
ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′ｎｅｗ＿aｄｄｒ１、ＣＲＣ＿ＬＥＮ′０）＝＝ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′ｎｅｗ＿aｄｄｒ２、ＣＲＣ＿ＬＥＮ′ｒｅｍａｐ＿ｖａｌｕｅ２）、
全体的なＣＲＣが変更されないようにしている：
ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′оｌｄ＿aｄｄｒ、ＣＲＣ＿ＬＥＮ′０、ＣＲＣ＿ＬＥＮ′０）＝＝ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′ｎｅｗ＿aｄｄｒ２、ＣＲＣ＿ＬＥＮ′ｒｅｍａｐ＿ｖａｌｕｅ２，ＣＲＣ＿ＬＥＮ′ｒｅｍａｐ＿ｖａｌｕｅ１）。
【0131】
当業者によって理解され認識されるように、リマッピング値の上記の例示的な計算は、複数のリマッピングデバイスのうち他の数（例えば、２つ以上）に容易に拡張され得る。
【0132】
別の例として、前のリマッパー値をそれ自身の計算に含めるようにリマッパーを実装することが、例えば次のように、提案されるかもしれない：
ｔａｇｅｔ＿ｃｒｃ＝ＣＲＣ（оｌｄ＿ａｄｄｒ、оｌｄ＿ｒｅｍａｐ）。
ｔａｇｅｔ＿ｃｒｃ＝ＣＲＣ（оｌｄ＿ａｄｄｒ、оｌｄ＿ｒｅｍａｐ）。
【0133】
このアプローチは一般に、１つのリマッピング値だけが最後に必要とされ、したがって、後続の (リマッピング) ステージで単純に上書きされるかもしれないことを意味する。
【0134】
説明のための例として２つのリマッパーのケースをそれでも取り上げ、さらに最初のリマッパーでｉｎｉｔａｌ＿ａｄｄｒｅｓｓ＝０ｘ００００、ｉｎｔｅｒｍｅｄｉａｔｅ＿ａｄｄｒｅｓｓ＝０ｘ１１１１、ｆｉｎａｌ＿ａｄｄｒｅｓｓ＝０ｘ２２２２と仮定する（なお、リマッピング値が任意の前のステージに設定されていないので、０′の余分なバイトに注意）：
ｔａｇｅｔ＿ｃｒｃ＝ＣＲＣ（０ｘ００００、０ｘ００）＝０ｘ６９、
ｃｕｒｒｅｎｔ＿ｃｒｃ＝ＣＲＣ（０ｘ１１１１）＝０ｘＦ５、
ｒｅｍａｐ＿ｖａｌｕｅ＝ＲＥＶ＿ＣＲＣ（０ｘＦ５、０ｘ６９）＝０ｘ４Ｄ
である。
ｔａｇｅｔ＿ｃｒｃ＝ＣＲＣ（０ｘ００００、０ｘ００）＝０ｘ６９、
ｃｕｒｒｅｎｔ＿ｃｒｃ＝ＣＲＣ（０ｘ１１１１）＝０ｘＦ５、
ｒｅｍａｐ＿ｖａｌｕｅ＝ＲＥＶ＿ＣＲＣ（０ｘＦ５、０ｘ６９）＝０ｘ４Ｄ
である。
【0135】
その結果、(最初のリマッパーでの) 新しいメッセージは｛０ｘ１１１１、０ｘ４Ｄ、ＤＡＴＡ、ＣＲＣ｝である。
次に、第２のリマッパーの場合:
ｔａｇｅｔ＿ｃｒｃ＝ＣＲＣ（０ｘ１１１１、０ｘ４Ｄ）＝０ｘ６９（予想通り、元のターゲットと同じ）、
ｃｕｒｒｅｎｔ＿ｃｒｃ＝ＣＲＣ（０ｘ２２２２）＝０ｘ２２、
ｒｅｍａｐ＿ｖａｌｕｅ＝ＲＥＶ＿ＣＲＣ（０ｘ２２、０ｘ６９）＝０ｘ９Ａ
である。
次に、第２のリマッパーの場合:
ｔａｇｅｔ＿ｃｒｃ＝ＣＲＣ（０ｘ１１１１、０ｘ４Ｄ）＝０ｘ６９（予想通り、元のターゲットと同じ）、
ｃｕｒｒｅｎｔ＿ｃｒｃ＝ＣＲＣ（０ｘ２２２２）＝０ｘ２２、
ｒｅｍａｐ＿ｖａｌｕｅ＝ＲＥＶ＿ＣＲＣ（０ｘ２２、０ｘ６９）＝０ｘ９Ａ
である。
【0136】
したがって、ｎｅｗ＿ｍｅｓｓａｇｅ２（第２のリマッパーで）＝｛０ｘ２２２２、０ｘ９Ａ、ＤＡＴＡ、ＣＲＣ｝である。
【0137】
特に、上の図からわかるように、０の（パディング）バイトは通常、（最初の）ＣＲＣ計算の一部として挿入される。
【0138】
しかしながら、幾つかの実装では、ＣＲＣ計算中に送信機（例えば、マスターデバイス） が０のバイトをスキップし、代わりに以下を実行するかもしれない：
ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′оｌｄ＿aｄｄｒ）＝＝ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′ｎｅｗ＿aｄｄｒ、ＣＲＣ＿ＬＥＮ′ｒｅｍａｐ＿ｖａｌｕ１ｅ）
である。
ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′оｌｄ＿aｄｄｒ）＝＝ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′ｎｅｗ＿aｄｄｒ、ＣＲＣ＿ＬＥＮ′ｒｅｍａｐ＿ｖａｌｕ１ｅ）
である。
【0139】
このようなアプローチの問題は通常、アドレスがリマッピングされていない場合であり、リマッピング値は未だに計算する必要があり、その結果、例えばハードウェア実装などの全体的な領域の増加を引き起こす必要がある。
【0140】
それにもかかわらず、他のいくつかの可能な標準（イーサネットなど）では、これは一般にリマップを完全にスキップできるようにするため、好ましいアプローチになる可能性があり、それによってプロトコルの背景を互換性あるようにすることに注意してください。
【0141】
実例として、これはイーサネットの８０２．１Ｑヘッダと同様に実装できる。具体的には、リマッパーがない場合、パケットは一般的に次のようになる：
｛Ｐｒｅaｍｂｌｅ、Ｄｅｓｔ、Ｓоｕｒｃｅ、ＥｔｈｅｒＴｙｐｅ、Ｐａｙｌоａｄ、ＣＲＣ｝
である。
｛Ｐｒｅaｍｂｌｅ、Ｄｅｓｔ、Ｓоｕｒｃｅ、ＥｔｈｅｒＴｙｐｅ、Ｐａｙｌоａｄ、ＣＲＣ｝
である。
【0142】
一方、つまり、リマッパーを使用すると、パケットは代わりに次のようになる：
｛Ｐｒｅaｍｂｌｅ、Ｄｅｓｔ、Ｓоｕｒｃｅ、Ｒｅｍａｐ＿ｐｒｅｓｅｎｔ、ｒｅｍａｐ、ＥｔｈｅｒＴｙｐｅ、Ｐａｙｌоａｄ、ＣＲＣ｝
であり、ここに、「Ｒｅｍａｐ＿ｐｒｅｓｅｎｔ」は、例えば、標準で定義された定数である（例えば、８０２．１Ｑの０ｘ８１００に相当）。特に、これらのケースでは、上記で説明したように、通常は１つのリマップ値のみが必要になる。
｛Ｐｒｅaｍｂｌｅ、Ｄｅｓｔ、Ｓоｕｒｃｅ、Ｒｅｍａｐ＿ｐｒｅｓｅｎｔ、ｒｅｍａｐ、ＥｔｈｅｒＴｙｐｅ、Ｐａｙｌоａｄ、ＣＲＣ｝
であり、ここに、「Ｒｅｍａｐ＿ｐｒｅｓｅｎｔ」は、例えば、標準で定義された定数である（例えば、８０２．１Ｑの０ｘ８１００に相当）。特に、これらのケースでは、上記で説明したように、通常は１つのリマップ値のみが必要になる。
【0143】
したがって、上記の同様の概念を適用すると、リマッパーの方程式は次のようになものになる：
ｔａｇｅｔ＿ｃｒｃ＝ＣＲＣ（Ｄｅｓｔ、Ｓоｕｒｃｅ）、
ｃｕｒｒｅｎｔ＿ｃｒｃ＝ＣＲＣ（ｎｅｗ＿Ｄｅｓｔ、ｎｅｗ＿Ｓоｕｒｃｅ、Ｒｅｍａｐ＿ｐｒｅｓｅｎｔ）
ｒｅｍａｐ＿ｖａｌｕｅ＝ＣＲＣ＿ＲＥＶ（ｃｕｒｒｅｎｔ＿ｃｒｃ、ｔａｒｇｅｔ＿ｃｒｃ）。
ｔａｇｅｔ＿ｃｒｃ＝ＣＲＣ（Ｄｅｓｔ、Ｓоｕｒｃｅ）、
ｃｕｒｒｅｎｔ＿ｃｒｃ＝ＣＲＣ（ｎｅｗ＿Ｄｅｓｔ、ｎｅｗ＿Ｓоｕｒｃｅ、Ｒｅｍａｐ＿ｐｒｅｓｅｎｔ）
ｒｅｍａｐ＿ｖａｌｕｅ＝ＣＲＣ＿ＲＥＶ（ｃｕｒｒｅｎｔ＿ｃｒｃ、ｔａｒｇｅｔ＿ｃｒｃ）。
【0144】
受信機では、「Ｒｅｍａｐ＿ｐｒｅｓｅｎｔ」と「Ｒｅｍａｐ」が (メッセージ全体にわたって)ＣＲＣ計算に供給されているが、それ以外の場合は使用されない。
【0145】
さらに、いくつかの可能な実装では、次のように変更されたデータ（例えば、リマップされたアドレス）とＲｅｍａｐ＿ｖａｌｕｅとを任意の順序で含めることも可能である：
ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′、３２′оｌｄ＿aｄｄｒ）＝＝ＣＲＣ（ＣＲＣ＿ＬＥＮ′ｒｅｍａｐ＿ｖａｌｕｅ、３２′ｎｅｗ＿aｄｄｒ）。
ＣＲＣ（ＡＤＤＲ＿ＬＥＮ′、３２′оｌｄ＿aｄｄｒ）＝＝ＣＲＣ（ＣＲＣ＿ＬＥＮ′ｒｅｍａｐ＿ｖａｌｕｅ、３２′ｎｅｗ＿aｄｄｒ）。
【0146】
したがって、これは次のように同じ順序でスレーブによってチェックされる：
｛ＣＲＣ＿ＬＥＮ′ｒｅｍａｐ＿ｖａｌｕｅ、３２′ｎｅｗ＿aｄｄｒ、８′ｄａｔａ、ＣＲＣ＿ＬＥＮ′ＣＲＣ｝。
｛ＣＲＣ＿ＬＥＮ′ｒｅｍａｐ＿ｖａｌｕｅ、３２′ｎｅｗ＿aｄｄｒ、８′ｄａｔａ、ＣＲＣ＿ＬＥＮ′ＣＲＣ｝。
【0147】
最後に、図５に概略的に示すように、本開示の一実施形態による、送信側のデバイスと受信側のデバイスとの間でエンドツーエンドのデータ保護を提供するための方法５００の一例を示すフロー図である。例えば、上に示したように、バスベースのシステムの技術的コンテキストでは、送信側のデバイスがマスターデバイスであり、受信側のデバイスがスレーブデバイスであってもよい。方法５００は、ステップＳ５１０において、第１のメッセージ用の第１のチェック値を送信側のデバイスによって計算することを含んでもよく、第１のメッセージは第１のデータブロックと第２のデータブロックとを備えてもよい。方法５００は、ステップＳ５２０において、送信側のデバイスと受信側のデバイスとの間の信号パス内のリマッピングデバイスによって、第１および第２のデータブロックのうちの一方のデータブロックまたはその一部をリマッピングすることをさらに含んでもよい。方法５００は、ステップＳ５５３０において、リマッピングデバイスによって、データブロックおよびリマッピングされたデータブロックに基づいてリマッピング値を決定することをさらに含んでもよい。最後に、方法５００は、ステップＳ５５４０で、リマッピングデバイスによって、受信側のデバイス用の第２のメッセージを生成することを含んでもよく、第２のメッセージは、第１および第２のデータブロックのうちの他方、リマッピングされたデータブロック、および 決定されたリマッピング値を備えてもよい。より具体的には、リマッピング値は、受信側のデバイスによって第２のメッセージに対して計算される第２のチェック値が第１のチェック値と等しくなるように決定されてもよい。
【0148】
上記で提案されたように構成され、具体的には、リマッピング値を（リマッピングデバイスにより）計算して挿入することによって、メッセージ（例えば、その中のデータブロック）が、例えば「ｒｅｍａｐｅｒ」によって部分的に更新／リマップ／変更された場合に、全体の（部分的には更新された）メッセージにわたるチェック値は未だに正しいだろう。そのため、通常、（リマッピングデバイスまたはリマッパーによって）部分的な更新を実行するときに、古いチェック値が正しいことを確認する必要はないだろう。これにより、特にメッセージの大部分が変更されていない場合に、リマッパーの処理能力や領域を節約できる。それに対して、従来の技術では、メッセージがリマッピングデバイスによって部分的に更新されるたびに、新しいチェック値を生成する必要があるだろう。新しいチェック値を生成するには、通常、(リマップされる前の) 古いメッセージがまだ有効かどうかを最初にチェックする必要があり、そうでなければ、それは送信機とリマッパーとの間で破損され得る。さらに、リマッパーブロックは一般に「適切な値」を生成する方法、つまり、ＣＲＣ生成ロジックを有さないので、それは本質的に安全である。要するに、リマッパーの障害は受信機で検出できるだろう。さらに、いくつかの可能な場合には、古いデータブロック（つまり、リマッピングする前）と新しいデータブロック（つまり、リッピングした後）との間のすべてのマッピングが既にわかっている場合、リマッピング値を事前に計算してもよく、それによって大幅にリマッパー自体の複雑さと領域を低減する。加えて、本開示で提案された技術を使用することにより、標準の更新に対して将来的に保証され得る、より堅牢なシステム設計をさらに可能にすることが可能になるかもしれない。ＩＰの再利用も実現でき、それによって貴重な開発および検証時間を節約できる。
【0149】
上述の装置の特徴は、簡潔にするために明瞭的に説明されていないが、それぞれの方法の特徴に対応することに留意されたい。本文書の開示は、そのような方法の特徴にも及ぶと考えられる。特に、本開示は、上述の回路を動作させる方法、および／またはこれらの回路のそれぞれの要素を提供および／または配置する方法に関係するように理解される。
【0150】
さらに、説明および図面は、提案された回路および方法の原理を示しているにすぎないことに留意されたい。当業者は、本明細書では明示的に説明または図示されていないが、本発明の原理を具現化し、その精神および範囲内に含まれる様々な構成を実施することができるであろう。さらに、本明細書で概説するすべての例および実施形態は、原則として、読者が提案された方法の原理を理解するのを助けるための説明目的のみであることを明示的に意図している。さらに、本発明の原理、態様、および実施形態を提供する本明細書のすべての記述、ならびにその具体的な例は、その等価物を包含するように意図している。
【図1】
【図2】
【図3】
【図4】
【図5】
【外国語明細書】