iButton®アプリケーションで堅牢な1-Wire®通信を実現するためのソフトウェア手法

要約

1-Wireデバイスは、単一のデータ線およびグランド基準を使用して通信を行います。1-Wireプロトコルには、ステンレス製iButtonパッケージに封止された1-Wireデバイスを使用する場合に広く見られる非常に間欠的な(｢タッチ｣)接続に対処するための特別な規定が含まれています。このアプリケーションノートでは、どのような場合にデータの完全性に対する特別な注意が必要になるかを説明するとともに、iButtonアプリケーションにおいて最も信頼性の高い通信を実現する手法について検討します。読者は、1-Wireバスプロトコルおよびマイクロコントローラを使用して1-Wire通信を生成する方法について熟知している必要があります。この文書の主な対象は信頼性の低い接続を使用するアプリケーションですが、説明されている手法のいくつかはハードワイヤ型1-Wireアプリケーションの信頼性向上にも応用することができます。

はじめに

1-Wireデバイスは、単一のデータ線およびグランド基準を使用して通信を行います。1-Wireプロトコルおよび追加の組込み機能を備えたiButtonは、非常に間欠的な(｢タッチ｣)接続に対応する必要があるアプリケーションに適しています。高セキュリティIDや金融取引などのアプリケーションにiButtonを使用する場合は、信頼性の高い通信が運用の成功にとって最も重要になります。

一般的な1-Wireデバイスの通信には、検索(バス上に存在するデバイスを特定するため)、デバイスのID番号(ネットワークアドレス、登録番号、64ビットユニークID、64ビットレーザ書込みROMなどとも呼ばれます)の読取り、デバイスのデータやステータスの読取り、メモリデータや制御情報の書込みなど、複数の機能が含まれます。場合によっては、通信障害をソフトウェアで容易に検出して修正することができます。たとえば、読取り中にエラーが発生した場合は、ソフトウェアで再度iButtonの読取りを試みることも、またはユーザがiButtonの取外しと再接続を行って新しいトランザクションを開始するのに任せることもできます。そうした修正のための動作によって生じる遅延やユーザの手間はわずかです。

しかし、iButtonへの書込みは、これよりずっと危険な作業です。確認のための読返しよりも前にiButtonが脱着した場合、データの書込みに誤りがあったかどうかさえ不明です。データの書込みに誤りが発見された場合、それを書き直す機会がないかも知れません。書込みの失敗は、非常に重大な結果につながる可能性があります。iButtonに金銭データが格納されている場合、借方(購入)の処理として、通常は購入を行うたびに変更後の金額をiButtonに書き込む操作がともないます。これらの更新の内の1つが失敗してデータが未定義状態のままになった場合、ユーザは残高の全体を失う可能性があります。

間欠的な接続上で1-Wire通信を実行するプログラムは、障害発生時のリトライの扱いについて十分考慮されたプランを備えている必要があります。ソフトウェア開発者は、試行が失敗した間に発生した可能性のあるすべての事象について考慮する必要があります。エラーの検出を後回しにせず少しでも早く行うことで、システムの応答が迅速化し、誤った(交換後の) iButtonのデータを更新する危険性が減少します。この迅速な動作は、さらに、この技術に対するユーザの信頼を強化します。お客様の満足度が重要である場合は、1-Wire通信を最も頑強にするためのステップを追加することが強く推奨されます。

エラーのメカニズム

1-Wireバスは、Wired-OR構成になっています。アイドル状態のバスはロジックハイです。通信を行う場合、1-Wireバスはマスタおよびスレーブデバイス(iButton)のローインピーダンスのドライバによってローにプルダウンされ、マスタによって供給される弱プルアップ電流によってハイレベルに復帰します。マスタによって開始される通信の他に、新たに装着するiButtonデバイスによって生成されるプレゼンスパルスおよびプローブへのiButtonの装着が不適切な場合に発生する電気的な短絡も、バスがローにプルダウンされる原因になります。

外部からの干渉によってバスが短絡状態になり、ロジック1のビットがロジック0のビットに変化する可能性があります。また、0ビットを生成しているローインピーダンスのドライバよりも干渉のエネルギーが十分に強力である場合、ロジック0のビットがロジック1のビットに変化する可能性があります。このため、ロジック1がロジック0に変化する可能性は、その逆に比べて大幅に高くなります。スレーブが0のビットを返す時点で接触が失われた場合、結果としてマスタは1のビットを読み取ることになります。さらに、1-Wireバスに注入されたいずれかの極性のノイズパルスを、スレーブデバイスが新しいタイムスロットと誤認する可能性があり、その場合は後続のすべてのビットがマスタと一致しない形で返されることになります。ソフトウェア開発者は、ビット反転、ビット欠落、ビット過多、および短絡などのビット･エラーを意識する必要があります。iButtonアプリケーションでは、バスは信頼できないものだと常に想定する必要があります。データの完全性を保証するために、あらゆる対策を講じてください。

iButtonが提供するエラー検出/防止手法

巡回冗長検査(CRC)は、すべての1-WireデバイスおよびiButtonが使用するエラー検出手法の1つです。各デバイスのID番号の一部として8ビットのCRCが含まれており、伝送にエラーがないか確認することができます。また、メモリiButtonの多くは16ビットCRCジェネレータを内蔵しており、デバイスからデータを読み取る際にデータを保護するようになっています。1-Wireファイルシステム(アプリケーションノート114 ｢1-Wire File Structure｣を参照)は、各データレコードの末尾に16ビットCRCを付加します。このCRCを算出するために、CRCジェネレータにあらかじめページ番号がロードされます。メモリページを選択するアドレスビットの伝送中にエラーが発生した場合、誤ったページにアクセスした時点でCRCの検証に失敗することになります。

CRCはビットエラーの存在を発見するための強力なツールですが、弱点もあります。すべてゼロの場合のCRCがゼロになることです。そのため、バスが短絡した場合(すべてゼロのビットが返されます)、データが完全なエラーであるにもかかわらず正しいCRCが示されることになります。したがって、ID番号の先頭バイトに格納されているファミリコードの正当性検証のような、追加のチェックまたは冗長性メカニズムを使用する必要があります。すべてゼロのCRCの問題に対する救済措置として、ビットごとに反転したCRCがiButtonのデバイスおよびデータ構造で広く使用されています。

メモリに対する書込みアクセス中のデータ破損を防ぐため、メモリiButtonはスクラッチパッドと呼ばれる一時保存用の領域を備えています。データがスクラッチパッドに書き込まれ、読返しによってエラーがないことが確認された場合、割込み不能の操作によってデータを目的位置に転送することができます。スクラッチパッドから目的位置へのデータ転送の仕組みは、メモリテクノロジによって異なります。詳細については、この後の｢NVSRAMへの高信頼性書込み｣および｢EEPROMへの高信頼性書込み｣の項をご覧ください。

通信の各段階の概要

iButtonの書込みトランザクションにおける動作をさらに詳細に検討すると、以下の各段階を識別することができます。


通信の段階	対処すべき問題
Initial contact of iButton and probe	Contact bounce
Generating time slots to read device identification number(s)	Shorts and intermittent contact
Maintaining a list of devices present on the bus	Contact bounce; multiple devices on the bus; devices coming and going
Selecting (addressing) a particular device	Devices coming and going
Reading from the selected device	The device may no longer be on the bus
Writing to the selected device	Verification of write success; the device may no longer be on the bus

信頼性の高いデータ交換を実現するために、ソフトウェア開発者は次のようなツールおよび手法を配備することができます。

書込みタイムスロットでの読返し(すべての場合)
デバイスID番号のCRC (すべての場合)
ファミリコードの正当性(すべての場合)
複数回の(冗長な)読取りおよび書き込んだデータの読返しによる確認(すべての場合)
データレコードへのCRC16埋込み(メモリiButtonの場合)
デバイスによるCRC16生成(一部のメモリiButtonの場合)
金銭アプリケーションにおけるデータおよびデバイスID番号の暗号化による検証

次項では、通信の様々な段階におけるこれらのツールの使用方法について詳述します。

通信の各段階の信頼性向上

システム割込み

内部エラー(すなわち、システムソフトウェアの不注意な設計が原因で発生するエラー)を排除するために、システム割込みを適切に管理することが重要です。低水準1-Wire通信ルーチンのレビューを慎重に行って、これらのタイムクリティカルな操作の間は割込みが抑止されることを確認してください。iButtonをプローブに確実に固定して試験を行った場合(すなわち、すべての外的エラー要因を排除した場合)、アプリケーションソフトウェアはリトライなしで動作するはずです。この点を実証した後に、初めてソフトウェア開発者の注意がエラー処理手法に向けられることになります。

接触バウンス

接触バウンスを測定するため、短絡したiButtonを使用してリーダプローブ(1kΩで5Vにプルアップ)への装着の試験を実施しました。接触を繰り返して100回のサンプリング結果を平均したオシロスコープのトレースを図1 に示します。グラフから読み取ることができるように、プローブとiButtonの間の電気的接触は、最初の接触から約12ms後まで安定しません。この試験におけるiButton装着の40%以上が、最初の接触から6ms後でも安定した接続が得られませんでした。図2の波形は、プローブ上に単一のiButtonを接触させた場合の接触バウンスを示しています。この例では、接触後の最初の4ms～6msの間、接触バウンスが激しいことに注意してください。

F図1. 短絡したiButtonを使用した100回の接触を平均した接触バウンス.

図1. 短絡したiButtonを使用した100回の接触を平均した接触バウンス.

図2. 単一のiButtonがプローブに装着した場合の接触バウンス.

図2. 単一のiButtonがプローブに装着した場合の接触バウンス.

リーダ(プローブ)に装着したiButtonは、60µs～240µsのプレゼンスパルスを生成します。リーダが毎秒17000サンプル(60µs未満)以上の速度で1-Wireバスの状態をテストする場合、プレゼンスパルスによって引き起こされる動作がほぼ確実に検出されます。iButtonがプローブと接触したことを認識したリーダは、通常はそのデバイスのID番号の読取りを試みます。標準速度でのROM読取りシーケンスの完了には約6msかかります。iButtonの装着をテストした後、直ちにID番号の読取りを試みるプログラムは、恐らく失敗することになります。高い信頼性でID番号の読取りに成功するためには、10msの待ち時間の後に複数のリセット/プレゼンス検出サイクルおよびROM読取りシーケンスの繰返しを行う必要があります。

短絡およびオープン回路

硬貨や金属片による意図的な破壊行為の他に、短絡が発生する一般的な状況として、iButtonがiButtonプローブ上に装着される際にiButtonのデータ接点がプローブのデータ接点とGND接点を繋いでしまう場合があります。そうした短絡の継続時間は、数msから1秒あるいはそれ以上まで様々です。短絡によってバス上の1-Wireデバイスが損傷することはありませんが、通信がリセットされる原因となり、それによってさらに1-Wireのデータ速度が標準速度にリセットされます。マスタがオーバドライブ速度を使用しており、短絡に気づかなかった場合、以降のオーバドライブ速度による通信の試みが失敗することになります。iButtonから見ると、接触の喪失は短絡と等価です。どちらの場合も、データとGNDの電位差がなくなります。したがって、iButtonとプローブの間の接続が失われた場合にも標準速度へのリセットが発生します。

短絡のチェックを実装するのに適した場所は、バスリセットおよびタイムスロットのサブルーチンです。短絡のテストは、必ずバスリセットまたはタイムスロットの開始時にバスをローに駆動する直前、すなわち、バスがその前のローレベルパルスから復帰するための十分な時間が経過してから行ってください。バスがローから解放された後、短絡のテストを行うまでの時間が短すぎた場合、ケーブル、プローブ、およびiButtonに由来するバスの電気容量が原因で、電圧がまだ有効なハイレベルに立ち上がっていない可能性があります。極端な場合、数µsの立上り時間も許容されます。バスリセットサブルーチンには特別な注意が必要です。短絡とプレゼンスパルスを識別するために、プレゼンス検出ウィンドウの間にバスのロジックレベルを複数回テストする必要があります。60µs～240µsの有効なプレゼンスパルスの後、バスはロジックハイレベルに復帰します。しかし短絡が存在する場合は、バスがさらに長い時間にわたってロジック0のままになります。

タイムスロットの生成

1-Wire通信はタイムスロットで行われます。タイムスロットには書込みタイムスロットと読取りタイムスロットの2種類があります。1つのタイムスロットで1ビットが伝送されます。大体において、読取りタイムスロットは単なるwrite-oneタイムスロットであり、スレーブデバイスが応答として0を返す場合に、1のビットを0のビットに書き換えます。一般に、タイムスロットを生成するサブルーチンでは読取りと書込みの機能を同時に実行します。そうしたタイムスロットのサブルーチン(図3 参照)は、次に説明する9つのステップで構成されます。タイミングの数値は標準速度の場合に相当します。

バスをローに駆動してタイムスロットを開始する。
6µs待つ。
バスに書き込むビットを出力する。1の場合、バスを解放してハイに復帰させる。0の場合、バスをローに維持し続ける。
9µs待つ。
スロットの開始から15µs後にバスのレベルをサンプリングする(ローレベル = 0、ハイレベル = 1)。
45µs待つ。
スロットの開始から60µs後にバスを解放してハイに復帰させる。write-zeroを実行していた場合は、これによって終了することになる。
バスの回復時間として10µs待つ。
サンプリングしたビットを返す。

図3. 1-Wireのタイムスロットの生成(数字は上記のステップに対応しています).

ビットがバスに書き込まれるたびに、バスの状態の読返しも行われ、呼出し元ルーチンに返されます。読取りは、1の書込みを行って、必要に応じてスレーブに1を0に変更させることによって行います。したがって、単一のサブルーチンで読取りと書込みの両方に対応可能です。バイトレベルのサブルーチンは、単にビットレベルのルーチンを8回呼び出して、結果をバイトの形で返します。

書込み中の読返しには、バス上の短絡、新たに装着したデバイスからの予期せぬプレゼンスパルス、ノイズパルス、マスタとの同期が失われたスレーブデバイスからの0ビットなど、各種のエラー状態が判明するというもう1つのメリットがあります。したがって、堅牢な通信のためには、バスに書き込んだデータと返されたデータをソフトウェアで比較することが重要です。この比較は、1-Wireスレーブ(iButton)への書込みにのみ当てはまります。読取りの場合、読み取ったデータは当然すべて1とは異なります。

書込み中の読取り機能は、DS2480B、DS2490、およびDS2482などの統合型1-Wireマスタもサポートしています。PC上のアプリケーションはポートドライバの制約を受けるため、コマンドトランザクション全体が完了するまでエラーに応答することができない可能性があります。

デバイスID番号の取得

iButtonのタッチ接続は信頼性が低いと考えるべきであるため、通信エラーを監視してできる限り早期に発見することが重要です。それによって、ソフトウェアがより早くリトライを開始することができ、時間の節約とアプリケーションの性能向上につながります。

プローブに装着したiButtonデバイスは、バスリセットの後にプレゼンスパルスを生成します。1-Wireマスタ(マイクロコントローラ)は、プレゼンスパルスまたは短絡などバス上の任意の活動を利用して割込みを発生させ、それによってiButtonの装着を処理するプログラムコードを呼び出すことができます。バッテリ給電式のアプリケーションの場合は、プレゼンスパルスを使用して最初にスリープ中のマイクロコントローラのウェイクアップを行い、次に装着ルーチンの呼出しを行います。別の方法として、リーダ(マスタ)が単にポーリングを行う方法、すなわちリセットパルスを繰返し発行して、バス上にデバイスが存在する証拠であるプレゼンスパルスの発生を監視する方法もあります。しかし、このポーリング方式を適用することができるのは、設計上、2個以上のiButtonがバス上に存在する可能性のないシステムだけです。この条件が満たされない場合は、より入念な方式が必要になります。詳細については、｢バス上に存在するデバイスのリストの管理｣の項をご覧ください。

プローブに装着されたiButtonからのプレゼンスパルスを検出したマスタがそのデバイスID番号を調べる方法には、Read ROM方式とSearch ROM方式の2種類があります。

Read ROM方式では、Read ROMコマンドを使用します。この方式で有効な結果を得ることができるのは、バス上に存在する1-Wireデバイスが単一の場合のみです。正しく読取りが行われたことを確認するための鍵は、ID番号末尾のCRCです。一時的な接触の喪失または短絡によってビットエラーが発生した場合、CRCの読み値がマスタによって計算されたCRCと一致せず、それによって読取りが成功していないことが示されます。iButtonがプローブに装着されていない状態でRead ROMコマンドを実行した場合、ID番号として8バイトのFFhが得られます。CRCチェックによってエラーが判明します。プローブが短絡された状態でROMの読取りを行った場合、ID番号として8バイトの00hが得られます。この場合、CRCチェックではエラーを発見することができません。しかし、00hというファミリコードは割り当てられていないという知識によって、このデータが無効であることが分かります。ビットエラーの発生にもかかわらず1/256の確率で正しいCRCになっている可能性があるため、ID番号を再度読み取って2回の結果が一致するかどうか比較することが推奨されます。これを行うことで、読取りにエラーがなかったことが保証されます。

Search ROM方式では、Search ROMコマンドを使用します。これは、より対話型のプロセスによってID番号の読取りを行うものです。Search ROMはバイナリサーチ手法を使用しており、192個のタイムスロットにわたってiButtonが双方向の通信に参加します。それによって、切断、短絡、同期喪失などのビットエラーを容易に検出することができます。Search ROMを1回行うためには、Read ROMを2回行うよりも若干長い時間がかかります。Search ROMが正常に完了した場合、たとえCRCのチェックを行わなくても、デバイスが存在して以後の通信の準備が整っていることを示す強力な指標になります。Search ROM技法の詳細な使用方法については、アプリケーションノート187 ｢1-Wire検索アルゴリズム｣をご覧ください。

バス上に存在するデバイスのリストの管理

多くのアプリケーションでは、バスに対するiButtonの装着と脱着を高い信頼性で検出することが必要になります。装着と脱着を検出するためには、バス上に存在することが分かっているデバイスおよび若干の管理情報を格納するテーブルが必要です。管理情報の構成要素の1つに、｢エイジ｣と呼ばれるものがあります。このエイジ情報は、デバウンス処理およびデバイスがバスから脱着したかどうかの判断に使用されます。デバウンス処理は、読取りエラーに起因する誤った装着/脱着の通知件数を減少させます。装着/脱着を検出する方式の1つを示すのが、次のアルゴリズムです。

Search ROMを使用したバスのスキャンを繰返し行って、個々のID番号を順番に発見する。エラーが発生しなかった場合、1回のスキャンサイクルで必要になるSearch ROMの回数は、バス上に存在するデバイスと同数になる。
デバイスを1つ識別した後、デバイステーブルを参照して、そのデバイスが以前のサイクルで発見されていたかどうかを判定する。そのデバイスがテーブルに登録されていない場合は、装着したばかりということになる。テーブルへの追加と、新規装着の通知を行う。
デバイスをテーブルに登録した場合、および識別したデバイスがすでにテーブルに登録されていた場合、そのデバイスのエイジデータに｢n｣を設定する(nは、たとえば5などの数値を表す)。
新しいスキャンサイクルを開始する前に、テーブル中のすべてのデバイスのエイジ情報をデクリメントする。エイジの値がゼロに到達した場合、そのデバイスがn回のスキャンサイクルにわたって観測されなかったことになる。このデバイスをテーブルから削除して、脱着の通知を行う。

この方式を実装するためには、各デバイスについて9バイトのエントリを備えたテーブルが必要になります。このテーブルは、バス上に存在可能なデバイスの最大数と同数のエントリを格納できるだけの十分な大きさが必要です。

装着/脱着アルゴリズムの信頼性を増大させるためには、ファミリコードの正当性の検査、CRCの正しさのチェック、および新規装着の仮扱い処理が必要です。拡張版のアルゴリズムは、次のようになります。

Search ROMを使用したバスのスキャンを繰返し行って、個々のID番号を順番に発見する。エラーが発生しなかった場合、1回のスキャンサイクルで必要になるSearch ROMの回数は、バス上に存在するデバイスと同数になる。
デバイスを1つ識別した後、ID番号をチェックして、ファミリコードがゼロでないことおよびCRCが正しいことを確認する。
正当なファミリコードとCRCを持つID番号についてデバイステーブルの照会を行い、そのデバイスが以前のサイクルで発見されていたかどうかを判定する。
そのデバイスがテーブルに登録されていない場合は、装着したばかりということになる。テーブルへの追加を行う。エイジデータに3を設定して、その装着が仮のものであることを示すフラグをセットする。
そのデバイスがすでにテーブルに登録されており、仮扱いのフラグがセットされている場合、エイジの値を2ずつインクリメントする。エイジの値が3より大きい場合、エイジバイトへのnの設定、仮扱いフラグのクリア、および装着イベントの通知を行う。
そのデバイスがすでにテーブルに登録されており、仮扱いのフラグがセットされていない場合、最大nになるまで(しかしnは超えない範囲で)エイジの値を1ずつインクリメントする。
新しいスキャンサイクルを開始する前に、バスが短絡されていない状態で、テーブル中のすべてのデバイスのエイジ情報を1ずつデクリメントする。エイジの値がゼロに到達した場合、そのデバイスがn回のスキャンサイクルにわたって観測されなかったことになる。このデバイスをテーブルから削除して、そのデバイスの仮扱いのフラグがセットされていない場合、脱着の通知を行う。

デバイスの装着が通知されるためには、そのデバイスが連続する2回のスキャンサイクルで発見されることが必要です。デバイスの脱着が通知されるためには、そのデバイスが連続するn回のスキャンサイクルにわたって発見されないことが必要です。バスが良好に動作している場合、どのエントリにも仮扱いのフラグがセットされず、エイジの値はnに等しくなります。スキャンサイクルで時々発見できなくなるデバイスは、エイジの値がnより小さくなります。1-Wireバスの装着および脱着の通知に関しては、このアルゴリズムが最も信頼性が高いことが実証されています。1-Wireバス上で短絡が検出された場合、短絡が除去されるまで装着/脱着アルゴリズムを停止すると良いでしょう。この例外を設けない場合には、短時間ですべてのデバイスが脱着したことになる可能性があります。

デバイスに対する高信頼性アドレス指定

新たにプローブに装着したデバイスのID番号が正しいことを確認した後、その番号を使用して以後の通信の対象となるデバイスを選択します。バス上に存在可能なデバイスが1個のみのシステムの場合、Match ROMの代わりにSkip ROMを使用したいと考えるかも知れません。しかし、以前識別されたデバイスが脱着して、別のデバイスが装着している可能性があるため、それは望ましくありません。したがって、少なくともMatch ROMシーケンスを使用して各トランザクションを開始する必要があります。

1-Wireデバイスのアドレス指定には、Match ROMの他に｢Strong Access｣と呼ばれる方法があります。Strong Accessは、シーケンス中の各ビットについて、あらかじめ定義された方向にSearch ROM機能を使用します。言い換えると、発見すべきデバイスをすでに知っている検索によってデバイスが発見されることになります。最終的な結果はMatch ROMと同じですが、Search ROMはデバイスからのフィードバックとして128ビットの正しいビットを必要とし、それによってアドレス指定の対象デバイスがまだ存在することを保証します。存在しないデバイスは適切なレスポンスを返すことができないため、Search ROM方式は数ビット時間以内にデバイスが存在しないことを発見します。

特定のアプリケーションについてMatch ROMまたはSearch ROMのどちらが正しい選択かを判断するためには、2つの手法についてシステムの応答性を知っておく必要があります。標準速度でのMatch ROMは、完了に約5.6ms (オーバドライブ速度では0.7ms)かかります。Search ROMシーケンスは、完了に約14ms (オーバドライブ速度では1.7ms)を必要とします。たとえば、トランザクションの完了までに10回のアクセスサイクルを必要とするアプリケーションの場合、Strong Access方式では標準速度において84msが追加されます。これは、ユーザに受け入れられない可能性があります。最近の1-Wireデバイスは、｢Resume｣と呼ばれるROM機能コマンドをサポートしています。このコマンドにはSkip ROMと同一の時間がかかりますが、以後のメモリまたは制御機能コマンドに対して最大1個のデバイスが応答することが保証されます。これによって、対象デバイスがバスから脱着した場合に、別のデータを誤って削除する危険性が排除されます。一般に、ユーザに受け入れてもらうために短いシステム応答時間が非常に重要である場合は、オーバドライブ速度の使用を検討してください。詳細については、｢1-Wireの速度について｣の項をご覧ください。

デバイスからの高信頼性読取り

高信頼性でのデバイスのアドレス指定が終わった後、マスタはRead Memoryコマンド、対象メモリアドレス、および目的のメモリデータを読み取るために必要な数の読取りタイムスロットを送信します。Read Memoryコマンドがエラーなしで受信された場合でも、対象メモリアドレスの伝送がエラーによる損傷を受け、マスタへの伝送中にメモリデータがエラーの影響を受ける可能性があります。Read Memoryコマンドがエラーなしで受信されなかった場合、iButtonは(高い確率で)そのコマンドを無視します。

iButtonのメモリは、32または64バイトのページで構成されます。DS1920、DS1971、DS1990、およびDS1991を例外として、iButtonは前述のアプリケーションノート114で解説されている1-Wire File Structureと互換性があります。このファイルシステムでは、各ページの先頭に長さバイトが挿入され、データフィールドの末尾に継続ポインタと反転CRC16が追加されます。このシステムは、iButtonメモリデータの読取りにあたって高水準のエラー制御を提供します。CRCジェネレータにはあらかじめメモリページ番号がロードされるため、1-Wire File Structureはデータストリーム中のビットエラーに対する保護だけでなく、対象アドレスのエラーも判明します。DS1971またはDS1991を使用する場合は、アプリケーションノート114で説明されているものと同様にデータパケットをフォーマットしてください。

1-Wire File Structureとの互換性の他に、DS1921、DS1922、DS1923、DS196xシリーズ、DS1977、DS198xシリーズの各iButtonは、メモリの読取りアクセスを保護するためのCRCジェネレータを内蔵しています。DS1982を除いて、デバイスが生成するCRCは16ビット型です。内蔵CRCジェネレータは、作動のために通常は拡張読取りコマンドが必要になり、メモリページの最後のバイトが転送された後にCRCが挿入されます。このCRCジェネレータに依存する場合は、ページデータをフォーマットする必要はありません(アプリケーションノート144のフォーマットに対して、1ページにつき4バイトの節約になります)。ページデータがフォーマットされている場合は、デバイスが生成するCRCによってデータの完全性を検証するためのレイヤがもう1つ提供されます。

読取りエラーが判明した場合、標準的な救済措置は同じデータ(またはページ)を再度読み取ることです。メモリデータがフォーマットされておらず、iButtonがCRCを生成しない場合にも、複数回の読取りが推奨されます。

アプリケーションによっては、データが暗号化されていること、またはメッセージ認証コード(たとえばSHA-1 MACなど)がページに埋め込まれていることが要求される場合があります。復号化の失敗や不正なMACが読取りエラーを示すという考え方があるかも知れません。それはその通りですが、読取りエラーと不正目的の意図的な改竄が区別不可能になるため、システムをそのように構成するのは軽率です。したがって、これまでに説明した手段を使用して最初にデータの物理的な完全性をチェックして、その後、第2段階として暗号化に関する検証を適用してください。そうして初めて、適切な行動を取り、有効な統計情報を収集することができます。

NVSRAMへの高信頼性書込み

NVSRAMベースのメモリiButtonは、スクラッチパッドのデータのバックアップおよび伝送中の1-Wireバス上の活動に関係なく対象メモリへの転送を完了するためのエネルギーを提供する内蔵バッテリを備えています。通信に成功したことを確認するためには、1)スクラッチパッド内のデータの検証、2)更新したメモリページの読返し、および3)意図したデータとの比較が必要になります。

全体のプロセスの説明は、自動販売機での購入などの例を使用するのが最も分かりやすいでしょう。この場合、セキュリティのためにデータが暗号化されます。次に示す各ステップでは、これまでのページで説明してきた機能を使用しています。詳細については、eCashの評価キット(型番：DSECASH)を参照してください。

iButtonの装着を検出する。
iButtonのID番号を取得して、完全性をチェックする(すなわち、ファミリコード、CRC)。
iButtonのアドレス指定を高い信頼性で行う。アドレス指定に失敗した場合は、END (失敗)。
残高を格納したページの読取りを高い信頼性で行う。これにはデータの完全性の検証が含まれる(1-Wireのデータ構造を使用する場合、このステップには複数ページのシーケンシャルまたはランダム読取りが必要になる)。複数回の試行後も成功しない場合、iButtonが脱着するのを待つ。END (失敗)。
暗号化に関するページデータの検証を行い、十分な資金があるかチェックする。これらのステップに失敗した場合、エラーメッセージを表示して、iButtonが脱着するのを待つ。END (失敗)。
iButtonのアドレス指定を高い信頼性で行う。アドレス指定に失敗した場合、END (失敗)。
新しい残高を暗号化してスクラッチパッドに書き込む。iButtonのモデル、バイトオフセット、および書き込むバイト数によっては、Write Scratchpadコマンドが転送の完全性チェックのためのCRCを返す場合がある。その場合は、そのCRCを適宜使用する。
iButtonのアドレス指定を高い信頼性で行う。アドレス指定に失敗した場合、END (失敗)。
スクラッチパッドの読取りを行い、アドレスおよびデータについて、スクラッチパッドに書き込んだデータとの比較を行う。一致しない場合、6)へ。
iButtonのアドレス指定を高い信頼性で行う。アドレス指定に失敗した場合、END (失敗)。
Copy Scratchpadコマンドを発行して、32µs待つ。
iButtonのアドレス指定を高い信頼性で行う。アドレス指定に失敗した場合、END (失敗)。
更新したページの読取りを行い、意図したデータと比較する。データが一致する場合、製品を送出して、END (完了)。一致しない場合、8)へ。

この例では、特別なセキュリティ機能を備えていないiButtonを想定しています。DS1963Sは複数の書込みサイクルカウンタを備えており、該当するメモリページへの書込みアクセスごとにインクリメントされるようになっています。このカウンタ値を暗号化に含めることによって、金額値の独自インスタンスを生成することができ、たとえば反復攻撃を防止することが可能になります。副作用として、同一のデータを2回書き込むというようなエラーからの回復処理がより複雑になります。書込み失敗からの回復を試みる際には、数ステップさかのぼって、データの暗号化に新しいカウンタ値が正しく含まれるようにする必要があります。

EEPROMへの高信頼性書込み

EEPROM iButtonも、スクラッチパッドを新しいデータの一時的な保存および検証に使用します。しかし、バックアップ用のバッテリを備えていないため、それらのスクラッチパッドは揮発性です。Copy Scratchpadコマンドの10msの書込みサイクルが完了する前に接触が途切れた場合、対象のメモリ位置が消去される可能性があります。メモリへの書込みが必要なアプリケーションでEEPROM iButtonを使用する場合、更新サイクルを完了することができなかった場合に旧データを維持するために、2回の書込みアクセスが必要になります。スクラッチパッドのデータを検証すること、および意図したデータとの比較のために更新したメモリページの読返しを行うことが絶対に必要です。EEPROM iButtonの場合、メモリデータの完全性をチェックするための唯一の方法を提供する方式であることから、アプリケーションノート114で解説されている1-Wire File Structureの実装が強く推奨されます。デバイスが生成するCRCは(利用可能な場合でも)通信エラーに対する保護しか提供しません。EEPROM iButtonの面倒な要素の1つがスクラッチパッドのサイズであり、DS1961SおよびDS1972の場合メモリページの¼のサイズしかありません。次に示す例は、メモリページと等しいサイズのスクラッチパッドを備えたデバイスに当てはまるものです。

この例の前提条件

デバイス(たとえばDS1973またはDS1977)が、アプリケーションノート114にしたがってフォーマットされています。すなわち、ページ0にデバイスディレクトリが格納されています。単一ページのデータファイルとして、ページ1と2が交互に使用されます。ファイルのディレクトリエントリから、ページ1またはページ2のどちらが有効かが分かります。ファイルが更新されるたびにインクリメントされるカウンタとして使用するために、データファイル内の1バイトがアプリケーションソフトウェア用に予約されています。

課題：データファイルを安全に更新する。これまでのページで説明した機能を使用して、以下のステップにしたがって処理を行う。

iButtonの装着を検出する。
iButtonのID番号を取得して、完全性をチェックする(すなわち、ファミリコード、CRC)。
iButtonのアドレス指定を高い信頼性で行う。アドレス指定に失敗した場合、END (失敗)。
ディレクトリページの読取りを高い信頼性で行う。これには、データの完全性の検証およびバッファへのディレクトリデータの格納が含まれる。複数回の試行後も成功しない場合、iButtonが脱着するのを待つ。END (失敗)。
iButtonのアドレス指定を高い信頼性で行う。アドレス指定に失敗した場合、END (失敗)。
ファイルデータの読取りを高い信頼性で行う。これには、データの完全性の検証が含まれる。複数回の試行後も成功しない場合、iButtonが脱着するのを待つ。END (失敗)。
iButtonのアドレス指定を高い信頼性で行う。アドレス指定に失敗した場合、END (失敗)。
代替のメモリページを使用して、新しいファイルデータをスクラッチパッドに書き込む。iButtonのモデル、バイトオフセット、および書き込むバイト数によっては、Write Scratchpadコマンドが転送の完全性チェックのためのCRCを返す場合がある。その場合は、そのCRCを適宜使用する。
iButtonのアドレス指定を高い信頼性で行う。アドレス指定に失敗した場合、END (失敗)。
スクラッチパッドの読取りを行い、アドレスおよびデータについて、スクラッチパッドに書き込んだデータとの比較を行う。一致しない場合、7)へ。
iButtonのアドレス指定を高い信頼性で行う。アドレス指定に失敗した場合、END (失敗)。
Copy Scratchpadコマンドを発行して、10ms (t_PROG)待つ。
iButtonのアドレス指定を高い信頼性で行う。アドレス指定に失敗した場合、END (失敗)。
更新したページの読取りを行い、意図したデータと比較する。一致しない場合、7)へ。
代替のメモリページに応じてバッファ内のディレクトリ情報を更新する。これには、使用ページのビットマップおよびディレクトリデータ末尾の新しいCRC16の更新が含まれる。
iButtonのアドレス指定を高い信頼性で行う。アドレス指定に失敗した場合、END (失敗)。
更新したディレクトリ情報をバッファから(ページ0の)スクラッチパッドに書き込む。Write Scratchpadが転送の完全性チェックのためのCRCを返す場合は、そのCRCを適宜使用する。
iButtonのアドレス指定を高い信頼性で行う。アドレス指定に失敗した場合、END (失敗)。
スクラッチパッドの読取りを行い、アドレスおよびデータについて、バッファ内のデータとの比較を行う。一致しない場合、16)へ。
iButtonのアドレス指定を高い信頼性で行う。アドレス指定に失敗した場合、END (失敗)。
Copy Scratchpadコマンドを発行して、10ms (t_PROG)待つ。
iButtonのアドレス指定を高い信頼性で行う。アドレス指定に失敗した場合、END (失敗)。
ディレクトリページの読取りを行い、バッファ内のデータとの比較を行う。一致しない場合、16)へ。
データが一致する場合、終了(成功)。

最初の更新(ファイルデータ)が失敗した場合、何の情報も失われず、後で更新を再試行することができます。ディレクトリの更新が失敗した場合は、両方のデータセットがiButtonの中に存在しますが、ディレクトリは最新状態ではありません。データファイルの場所として2つの可能性があることを知っており(システムの知識)、両方のバージョンを読み取ることによって、データファイル内のカウンタ値から、どちらのバージョンが最新であるかが分かります。このようにして、次にそのiButtonがプローブに装着した機会に、ディレクトリデータを修正することが可能です。

スクラッチパッドのサイズがメモリページの¼であるデバイスの場合、この方式に変更を加える必要があります。この場合、ファイルのデータページの2番目と3番目の¼ページ分が、交互に使用されることになります。管理用データ(すなわち、継続ポインタ、CRC16)を除くと、データおよび更新カウンタ用にわずか5バイトしか残りません。メモリページの最初の¼に格納されるのは、2番目または3番目の¼ページ分が有効かどうかを示す長さバイトだけです。最初の更新サイクルで、交互に使用する場所に新しいデータが書き込まれます。第2のサイクルで、長さバイトが更新されます。この｢A-B方式｣の例として、DS1961Sを使用した自販機アプリケーションの説明が、アプリケーションノート1820 ｢White Paper 1: SHA Devices Used in Small Cash Systems｣の表3およびそれに関連する本文(p.6～7)とステップBF3 (p.58～60)に記載されています。

1-Wireの速度について

多くのiButtonアプリケーションでは、ケーブル長と負荷の関係でオーバドライブ(高速)モードの使用が不可能になっています。しかし、組込みの電子回路がiButtonのプローブと非常に近い位置にあるアプリケーションでは、この高速通信モードによってトランザクション時間を大幅に短縮することが可能です。

オーバドライブ対応のiButtonをオーバドライブモードに移行させる方法は2種類あります。1つの方法はOverdrive Skipコマンドを使用するもので、これによってバス上のすべてのデバイスがオーバドライブに移行します。もう1つの方法はOverdrive Matchコマンドを使用するもので、ID番号が一致するデバイスだけがオーバドライブに移行します。移行したデバイスは、標準速度の1-Wireリセットを受け取るか、またはバスから切断されるまで、オーバドライブモードのままになります。デバイスがプローブに装着したときは、常に標準速度からスタートします。

次の例は、単純なRead ROM機能について時間短縮効果を示したものです。


ステップ	説明	STD速度での時間	OD速度での時間
標準速度での1-Wireリセット/プレゼンス検出サイクル		960µs	960µs
Overdrive Skip ROMコマンド	8 time slots	N/A	8 × 65µs
オーバドライブ速度での1-Wireリセット/プレゼンス検出サイクル		N/A	96µs
Read ROMコマンド	8 time slots	8 × 65µs	8 × 8µs
デバイスID番号の読取り	64 time slots	64 × 65µs	64 × 8µs
	合計時間	5640µs	2152µs

オーバドライブ速度にするための余分なコマンドとリセットサイクルにもかかわらず、デバイスID番号の取得にかかる時間が、標準速度の5640µsに比べてオーバドライブを使用した場合は2152µsになっています。オーバドライブで行われる通信が多いほど、時間短縮効果が大きくなります。オーバドライブを使用するデメリットとしては、短絡または接触の喪失が発生した場合に、より多くの注意が必要になるという点があります。詳細については、｢短絡およびオープン回路｣の項をご覧ください。

上記の計算では、タイムスロットの時間を標準速度で65µs、オーバドライブで8µsとしていますが、これは最近のデバイスのデータシートに一致する値です。マイクロコントローラによってリアルタイムでタイムスロットを生成する場合は、タイミングがデータシートの仕様から離れることになります。たとえば、｢タイムスロットの生成｣の項ではタイムスロットを70µsとしていますが、読返しのためのサンプリング(図3の5)が十分に早く行われ、十分な回復時間(図3の8)が存在する限り、この値で問題ありません。

まとめ

間欠的な(タッチ)接続を通して、iButtonとの間で非常に信頼性の高い通信を行うことが前提になるアプリケーションでは、慎重な設計、特別なアルゴリズム、および徹底的なテストが要求されます。エラーの早期検出、効果的なリトライ、およびエラー回復手法を、システムの応答時間を軽視することなく提供するようにプログラムフローを設計する必要があります。しかし、適切な対策を講じることによって、間欠的な接続にもかかわらず非常に信頼性の高いiButton通信を実現することが可能です。