7-1.　Blackfinをサポートしました

BlackfinのBF518FはIEEE1588アクセラレータ：TSYNCを内蔵したCPUです。

個性的ですが、IEEE1588の利に適っているアクセラレータでした。

今回はOSをLunixで挑戦したのですが、やはり面白い特徴が出ました。

Slaveの通信開始では、Masterが配信する時刻で自身の時刻を初期化します。

初期設定が終わると、次回からMasterとの時刻偏差からクロック・レートの調整となるのですが、この初期化処理時間がLinuxだと大きく揺らいでしまうので、同期開始から同期確立までの時間が安定しません。同期が　確立してしまえば、1μ秒以下（数100ナノ秒オーダ）で安定します。

Blackfinはファンも多いので、時刻同期を使用したい方は、とても有効な機能と思います。但し、TOPPERSのような軽いOSがお勧めです。

7-2. マネージメント機能について

マネージメント機能をいれました。結構便利です。

WindowsPCをマネージャにして、組込みボードを複数台制御しています。

マネージメント機能は、TLV(Type Length Value)で規定された制御データをIEEE1588手順で通信するのですが、PCから組込みボードの通信状態がリアルタイムで分かるし、複数のボードの制御を１台のPCで制御できます。この機能でシステム検証が格段としやすくなりました。

IEEE1588機能に関心のある方々は、何かアプリケーションがあって、そこに同期を取りたい理由があるから時刻同期が必要になります。モータ制御、送電制御、測定機器などの装置は、同期した時刻（クロック）を利用するためにIEEE1588を搭載します。このため、ぞれの装置で状態認識、処理制御、測定データ等の通信が必ず発生します。当然のことですが、高精度な時刻同期だけを必要とする装置は、イーサネットである必要がありません。

マネージメント機能はこの通信データを扱えるので、アプリケーションがXML/HPPTのような高レイヤな通信機能を必要としなければ、十分にIEEE1588手順だけでシステム構築が可能になります。

7-3. タイムスタンプ

タイムスタンプ・ビジネスが立ち上がり始めています。電子承認等でタイムスタンプの時刻を保証するのですが、このシステムで１μ秒以下の同期精度が必要か？ たぶん不要です。

IEEE1588はその同期精度に注目されていますが、もう一つの特徴は通信処理が簡素になっていることです。

NTPは組込みCPUで動作させるには処理負荷が大きすぎます。このため、組込みシステムではSNTPが使用される場合が多いのでが、時刻の不連続性の問題があります。

ハードウェア・アクセラレータを使用すれば、更にソフトウェア処理が軽減されるので、ネットワークを組込みCPUで構成する場合には、IEEE1588の時刻同期は非常に有効なのではないでしょうか。

高精度同期を必要としない分野にも、今後IEEE1588が採用させてゆくように思われますが、IEEE1588の正しい理解が広まることが重要と思われます。また、「ネットワークの複数装置が同一の時刻を共有する」とこで、システムの動作検証や障害解析等の分野にもIEEE1588は応用されてゆくことを期待しています。

7-4. 余談

また、半年もブログをサボってしまいました。前回「分野毎の状況を書く」などと書いてしまいましたが、IEEE1588がどうも同期精度だけに注目が集まっているように感じて、今回は同期精度以外の項目を書いてみました。とくにマネージメント機能の話しをすると、殆どの方がこの機能を知りませんでした。今回のET2011では、このマネージメント機能を中心にデモシステムを作ったのですが、好評でしたのでブログでも触れてみました。

今回のET2011ではIEEE1588のサポート・デバイスが増えたことを感じましたし、私たちのブースに来られた方々は、１年前に比べてより具体的な質問が多く、IEEE1588に興味を持たれる方が多くなったことを感じています。

6.1　通信ソフトを製品化しました。

ブログを半年もサボってしまいました。この間、IEEE1588の手順ソフトの製品化をしていまた。SH2A（SH7216）のCMTを使用してソフト同期で動作させたのですが、障害処理等を含めて、評価項目を消化するのに手間取りました。また、ナショナルセミコンダクタ社のIEEE1588アクセラレータ内蔵HPY－LSI：DP83640が実装されたSH2Aボードで、このアクセラレータ機能を使って評価しました。

ソフト同期では、他のタスクが動いていなければ高精度なのですが、他のタスク（処理）で割込みマスクを使うと、精度が１桁から２桁落ちてしまうことも分かりました。

これに対して、DP83640はソフトのタスク構造には影響されずに、高い精度を出すことができます。「完走性能」ですが、イーサケーブルを直結すると、±２０ｎS程度の精度で同期できます。こうなると、使用するHUBの中継処理時間のバラツキが、同期精度に大きく影響します。

6.2 DP83640の時刻同期

誤解があるといけないのですが、DP83640を実装すると「このような精度で時刻同期する」とストレートに考えないで下さい。

DP83640はIEEE1588のアクセラレータが内蔵されているだけです。具体的には、レート調整可能なクロックと、このクロックによるパケット送受信のタイムスタンプ取得機能を内蔵しているだけです。このため、ソフトはパケット送信や受信後に、DP83640のレジスタからタイムスタンプを読み出して、maenPathDelayやoffsetFrmMasterを計算し、更にoffsetFromMatserからデジタルPLL計算した値をDP83640のクロックへフィードバックして時刻同期を取ります。つまり、同期精度やジッタ／ワンダ値はソフトウェア処理に依存しています。

同期精度測定は、DP83640の内蔵クロックをトリガとした信号をGPIOから出力して、オシロスコープで観測しています。

DP83640の欠点は、レジスタアクセスがMDIOなので時間がかかります。タイムスタンプの読み出しは１ｍS程度かかります。このため同期精度に対して、リアルタイム性にやや問題があります。ドライバソフトを作るときは少々苦労します。また、デジタルPLL処理がソフトなので、剰余算命令を持たないCPUだとシフト演算で代行しなければならず、同期精度に影響が出ます。

長所として、一般のMAC内蔵でMIIを持つCPUであれば、外付けのPHYチップで高精度時刻同期を使用できるメリットは大きいと思います。また、DP83640の特徴としてGPIOを１２本も持ち、このGPIOにマニアックなトリガ／イベント機能が連動する事です。高精度な同期アプリケーション設計には有効になると思います。

6.3 EtherCATについて

規格を読み始めた１年前は、IEEE1588のメインターゲットはFA分野ではないかと思っていたのですが、Version.2が2002->2008年と6年も掛かってしまい、EtherCATが先行しているようです。

EtherCATは昔のアークネットを思わせるトークンリング・ネットワークですが、ETGのドキュメント読むと、通信アプリケーションの設計方法は分かります。でも、通信プロトコルの詳細部（厳密な部分）が明確化されていません。

よく、「EtherCATとIEEE1588の違いは何？」と聞かれます。EtherCATはモータ制御などにフォーカスしたデータ通信手順も含んでいますので、単に時刻同期部分のIEEE1588と同じ土俵では回答できません。回答には誤解の無いように筋道を立てて話さねばならないのです。

「IEEE1588とEtherCATと、どちらの同期精度が高いの？」という質問もあります。このような質問の回答には「冬篭り、春さり来れば鳴かざりし……」と額田王同様の回答をしなければなりません。どちらも高精度な同期を取る事が可能ですが、両者の特徴・長所・短所をお話した上で、かつ、質問した方がどのようなネットワークで、どんな精度で何を処理しようとしているのかによって結論が変わります。勿論、額田王に倣い結論は私の主観としてお話します。要は、単純に同期精度だけで両者を比較するのは無意味であると考えています。この回答をしているときは、右か左かの直球を投げ返すことができない自分を見て、いつもこの歌を思い出してしまうのです。

6.4 余談

昔のことですが、RTOSの選択に「タスクスイッチング時間」という項目があったことを思い出します。この項目にある一意的な数値で、「早いからITRON！」と結論する摩訶不思議な世界がありました。万葉集を引き合いに出すよりはこちらの方がよかったかも知れません。今回は全てが余談ですね。

ブログをサボっている間に、IEEE1588の件で３０社以上の方々とお話させていただきました。次回も技術論ではなく、分野毎の時刻同期の状況を私の主観として書きたいと思います。

技術論はもっと核論／各論になった方が面白いので、本ブログにコメントを頂ければ、ご回答できるものはご回答します。また、ご回答をお持ちの方はご回答をお願いします。

5.1. はじめに
  今回はData Set（DS）に関して書きたいと思います。PTP通信を行う上で必要となる情報はフォーマットされた制御テーブルとしてDSで階層的に規定されています。DSを構成するmember（フィールド）はビット長と属性が定義されています。またPTP通信のManagement手順で参照・設定をすることから、フォーマットと設定値は規格に従う必要があります。
  IEEE1588の動作を理解するにはDSとその構成memberを理解することが、最初の作業になると思いますので、規格を読む前のウォーミングアップ程度の内容を紹介してみます。私の理解が間違えていたり、不足している項目はご指摘ください。
  DSは目的毎に分割されていますので、ここでは代表的なDSを簡単に紹介します。

5.2. defaultDS
  自装置のプロフィールを記録するDSです。表5-1を参照ください。構成するmemberを順番に追ってみましょう。属性にはStatic/Dynamic/Configの３種類があります。Staticは製品固有の情報で製品の場合は、工場出荷後に変更することは出来ません。Dynamicは通信中に環境の変化等で逐次変更します。Configは装置毎に設定内容を変更できますが、基本的に通信中には変更しません。

表5-1 defaultDS構成

 

5.2.1. twoStepFlag
  第２回の同期シーケンスで書いた one-Step Ckockとtwo-Step Clockの選択を本memberで指定します。

5.2.2. clockIdentity
  clockIdentityはclock(装置)のユニークな識別コードです。Identityと命名していますが、アドレスと解釈しても問題ないと思います。PTPは基本的にMAC/IPのマルチキャストアドレスで送受信しますので、このclockIdentityを全てのメッセージに設定して自局または相手局を認識します。MACアドレスと同様に管理されていますが、装置のMACアドレスから生成することもできます。
  余談ですが、PTPがマルチキャスト通信なので、当然ですが１つのclock(装置)からの送信メッセージは全てのclock(装置)で受信してしまいます。受信したメッセージが自分宛では無い場合は廃棄しなければなりません。つまり、接続装置が多く、Sync/Delay_Reqメッセージの周期時間が短くなると、メッセージ廃棄処理の負荷が増大しますので、システム設計時は注意が必要です。接続する装置の中に、非力なCPUでPTPをソフト処理する物があると、PTPメッセージの受信＋廃棄処理でCPUリソースの多くを消費する場合があります。

5.2.3. namberProts
  装置内のポート数です、1ポートだけのordinaryClockの場合は、１です。

5.2.4. clockQuality
  第３回で説明したBMC(Best Master Clock)で書いた、Clockの情報です。clockQualityは階層的に以下の３つの情報で構成します。
 ① clockClocss: 第３回で説明しました
 ② clockAccuracy: 自身のclockの動作周波数を指定します。もちろん動作周波数が高い方を優先 します。
 ③ clockOffsetScaledLogVariance: 自身のclockの精度を規格に従った計算式の結果を設定しま す。
  BMCでは、clockQualityの他に、Priority1/2とｔimePropertiesDSのtimeSource、前項のnumberProts、全部の情報が同じ場合は最後にclockIdentityを比較します。

5.2.5. Priority1、Priority2
  PTPネットワーク設計でとても重要となる項目と考えています。第４章で説明しましたが、BMCによってGrandmasterが決定し、各通信ポートではMaster/Slaveが決定して行きます。また、Grandmaster/Masterの障害時は、動的に構成変更を行います。このBMCアルゴリズムの判定を各装置(Clock)のプロフィールの比較で行いますが、プロフィールの殆どはハードウェア構成に依存していますので、優れたハードウェアの装置(Clock)が勝利してしまいます。
  Priority1は他の全てのプロフィールよりも優先して判定します。このため、GrandmasterやバックアップのGrandmasterを管理して運用する場合には、Priority1により小さい値を設定すると、ネットワークに素晴らしいハードウェアの装置(Clock)が追加されても、管理者が知らない内にその装置(Clock)がGrandmasterになることはありません。逆にSlaveOnlyの装置のPriority1に小さい値を設定すると、悲劇的なネットワークになる可能性があるので、ご注意ください。
  Priority2はclockIdentityを除く他の全てのプロフィールが全て同じ場合に比較判定します。一定の管理内で装置(Clock)の機能重視なネットワークを構築する場合に、ネットワーク設計で使用する値と考えます。

5.2.6. domainNumber
  PTPネットワークはこのdomain毎に構築します。MAC/IPネットワークの中に複数のdomainを混在させることも可能です。各装置は受信したメッセージのdomainNumberをdefaultDSのdomainNumberと比較して、異なるdomainNumberのメッセージは廃棄します。ここでもメッセージの廃棄処理が発生しますのでご注意ください。

5.2.7. slaveOnly
  clockClass=255の場合に、TRUEを設定します。

5.3. currentDS
  currentDSはSlaveとしてPTP通信を制御するテーブルとしてDynamic属性の３つのmemberで構成します。

5.3.1. stepsRemoved
  GrandmasterからのboundaryClockのホップ数を記録します。BMCではAnnounceメッセージ内のstepsRemoved値もチェックして、同一のGrandmasterに同期した複数のboundaryClockが接続された場合の、ルート選択も行っています。

5.3.2. offsetFromMaster、meanPathDelay
  offsetFromMaste はSlaveのMasterとの時刻偏差値で、meanPathDelayはMaster/Slave間の伝送遅延時間です。図５－１は概略的ですが中継器（transparent Clock）なしに接続した場合を書きました。

図5-1 offsetFromMaster、meanPathDelay

5.4. portDS
  通信ポート毎の構成情報を格納するテーブルです。ordinaryClockは１、boundaryClockは通信ポート数のportDSを保有します。表5-2に構成メンバーを書きました。

表5-2 portDS構成

5.4.1. portIdentity
  自装置(defaultDS)のclockIdentity(64bit)と、当該ポート番号(16bit)で構成します。ポート番号は１，２，３，，，Ｎを設定します。ordinaryClockは１を設定します。

5.4.2. portStats
  第３回で説明した状態を格納します。

5.4.3. logMinDelayReqInterval
  Delay_Reqメッセージの送信周期です。logが頭に付いているのは、設定値が２のｎ乗のｎ値を設定することを意味します。具体的には1の場合は2秒、0の場合は1秒、-1の場合は0.5秒となります。
  Minが付いているので、設定値は最小値です。具体的には1の場合は2～4秒の間隔でDelay_Reqメッセージを送信します。0の場合は1～2秒の間隔で送信します。
  属性がDynamicです。これは、同期するマスタから周期を指定されますので、スレーブはこの周期に従って送信します。スレーブが勝手な周期でDelay_Reqメッセージを送信することは出来できません。
  マスタにとっては、スレーブの数が増えると処理負荷が増えるので、周期を動的に変更して、スレーブに指示できます。

5.4.4. logAnnounceInterval、logSyncInterval
  Announceメッセージとsyncメッセージの送信周期ですが、logが付いているので前項と同様です。Minが付いていないので、本DSの指定値の周期で送信します。
5.5. その他のＤＳ
  ここで説明したDS以外に、Grandmasterの情報を格納するparentDS、PTP時刻（秒とナノ秒のカウンタ）から天文時刻へ変換するための情報を格納するtimePropertiesDS、Master決定までの間に複数のMasterの情報を格納するforeignMasterDS等があります。

5.6. 余談
  IEEE1588-PTPのソフトを作成したことは前回お話しましたが、規格のフォーカス外となる(実装依存の)デジタルPLLアルゴリズムと戦ってみました。結果としては安価なHUB接続でも、1μ秒以下の精度に収束できるようになりました。ET2010の展示に間に合わせるために結構必死でした。このWebサイトでダウンロードを始めましたので、ご興味のある方はダウンロードして動作させてください。
  1μ秒以下とはoffsetFromMaster値のことです。この精度をどれだけアプリケーションで使用できるかは、 IEEE1588とは別のノウハウが必要になると思われます。
  また、HUBによって同期精度に大きく影響が出ます。安価なHUBは中継処理時間が安定しないので、同期の収束に時間がかかりますし、収束後も大きな揺らぎで同期に影響が出たりします。最近各社で出ているハードウェア・アクセラレータを使用しても、たぶん安価なHUBでは相当苦労すると思われます。
くれぐれも、安価なHUBで評価して「IEEE1588の同期精度は悪い!」というような判断しないでください。

4.1 はじめに

　今回はIEEE1588で構築するネットワークのサワリを書きたいと思います。

4.2. Clockの種類
　IEEE1588規格では、時刻同期を行う装置をClockと表現しています、Clockのは以下の５種類があるので簡単に説明します。
① Ordinary clock
② Boundary clock
③ End-to-end transparent clock
④ Peer-to-peer transparent clock
⑤ Management node

4.2.1. Ordinary clockとBoundary clock
　Ordinary clockは通信ポートが１つの装置（Clock）で一般的な端末をイメージしています。具他的には、図4-1で示した様に基本的にはMasterかSlaveで動作します。
　Boundary clockは複数の通信ポートを持つ装置（Clock）で、同期した時刻の中継装置です。ルータをイメージしています。図4-1はPort-A～Eの５つの通信ポートを持つ装置を例として書いてみました。図4-1ではPort-AはPTP通信のSlaveとなって接続したOrdinary clock Aに同期し、自装置のタイマ（時刻）を補正します。Port-B～EはPort-Aによって時刻同期されたタイマ（時刻）を使用し、PTP通信のMasterとして接続した装置へ時刻配信をします。
　Ordinary clock BはPTP通信によってBoundary clockと時刻同期を取りますが、間接的にOrdinary clock Aの時刻と同期しています。ネットワークに於けるBoundary clockの機能は、PTP通信を終端させて同期時刻を中継することです。
　図4-1のBoundary clock PortC～EにOrdinary clockやBoundary clockを接続してゆくと、樹構造のPTPネットワークが構築できます。このネットワークの全ての装置(Clock)はOrdinary clock Aに時刻同期します。このネットワークではOrdinary clock AをGrandmasterと呼びます。

 

4.2.2. transparent clock
　より高い同期精度を得るには、より正確な伝送遅延時間が求められます。transparent clock はPTPメッセージの中継遅延時間をSlaveやMasterに提供する機能を持ったPTPメッセージの中継装置です。Boundary clockとの違いはPTP通信を中継する（終端しない）ことです。
　PTPメッセージのヘッダには、伝送処理時間を記録するためのcorrectionFieldがあります。 transparent clockは自身の中継処理で使用した時間を、１つ１つのPTPメッセージのcorrectionFieldに加算します。Masterが送信したメッセージはtransparent clockで中継される毎にcorrectionFieldへ中継処理時間が加算されて、Slaveに届きます。
　Slaveは伝送遅延時間を計算するときに、MasterとSlaveのTimestampの差分だけではなく、このcorrectionField情報を使用してより精度の高い計算値を得ることができます。
　IEEE1588規格ではEnd-to end transparent clockとPeer-to-peer transparent clockの２つのtransparent clockを規定しています。この２つのtransparent clockの機能を理解するには、同規格の伝送遅延測定方法（DelayMechanism）を理解する必要があります。
　DelayMechanismはEnd-to end とPeer-to-peerの２つが規定されているので（第２回参照）、この２種類のDelayMechanismをサポートするtransparent clockで、名称を分けています。
　DelayMechanism をPeer-to-peerにした場合は、Master、Slaveをクロスケーブルで接続するかPeer-to-peer transparent clock経由の接続が注意となり、一般のHUBは使用できなくなります。

4.2.3. Management node
　IEEE1588規格には大きく分けて３つ（勝手な意見ですが）の機能があると考えています。１つ目はMaster、Slave間の同期機能、２つ目はフォールトトレラント等を意識した状態制御（ジャンケン制御）、３つ目はManagement機能です。
　ManagementはTLV（Type,Length,Value）と命名された制御情報をベースにして、装置（Clock）を制御する機能です。
　TLVはSNMPのMIBの様な物で、Management手順はSNMPの様なイメージです。装置（Clock）はManagement手順で制御される機能を持つ必要があると規格に記述されています。SNMPのAgent機能に対応した機能の搭載が必要ということです。
　Management nodeとは、Management手順によって装置（Clock）を制御する装置と考えてください。ネットワーク監視装置に搭載するSNMP Managerようですね。

4.3. マスタのバックアップ構成
　IEEE1588規格から以下のバックアップ構成を考えることが出来そうです。Masterの障害に備えて、次の①～③のMasterのバックアップ装置（Clock）をPTPネットワークに接続すると、Slaveは動的にMasterを切り替えて運用を継続できます。
① 通常運用ではPassive状態で、Masterの障害時に待機する
② 通常運用ではSlave状態で、Masterの障害時に待機する
③ 通常運用ではAlternate Master状態で、Masterの障害に待機する

　図4-2.でPassive状態でのバックアップを説明しますが、前回（第３回）のBMCの説明をもう一度思い出してください。
　Clockの構成情報（プロフィール）を強力な順番で設定します。
①　Ordinary Clock A, ②　Ordinary Clock B、③　Ordinary Clock C/D/E、④　Boundary Clock
　Ordinary Clock Aが一番強力なので、通常の状態ではOrdinary Clock A がGrandmasterとして動作します。Boundary Clockはいち早くOrdinary Clock Aに同期するとともに、他装置へ広告するプロフィールを“Ordinary Clock Aに同期しているのだぞ！” とします。（Ordinary Clock Aのプロフィールで他装置と戦います）このため、他のポートでは全勝でMasterになります。Ordinary Clock C/D/EのclockCloassには128以上を設定すれば、Slaveとして動作します。Ordinary Clock BのclockCloassには127以下を設定すればPassiveで待機となります。Ordinary Clock Aに障害が発生すれば、Ordinary Clock BがOrdinary Clock Aに代わって GrandMasterになります。図4-2.のOrdinary Clock BのclockClassも128以上に設定すれば、Ordinary Clock BはSlave状態で待機できます。
　Ordinary Clock Aに障害が発生してダウンすると、Boundary ClockとOrdinary Clock B/C/D/EはOrdinary Clock Aを見捨てて、みんなでジャンケンが始まります。

　Boundary Clockは次に強力なOrdinary Clock BをGrandmasterにして、Ordinary Clock C/D/Eに勝利します。この結果、全装置がOrdinary Clock BをGrandmasterとします。
Alternate Masterは、ここでは説明を省略させてください。

4.4. 余談
　株式会社アルファプロジェクトのSHマイコン(SH7216)ボード(AP-SH2A-4A)で、IEEE1588手順をコーディングして実験してみました。純ソフト制御でも結構精度の高い同期が取れます。1m秒周期の割込みでGPIO信号をON/OFFして、Master / Slaveの観測ピン（GPIO）をオシロで測定すると±20μ秒の位相偏差で同期が取れました。また、ジッタを測定すると３～４μ秒内できれいな正規分布をしています。まだまだ、PLL論理を改良できるレベルなので、ソフト制御でも、これ以上の精度が実現できると思えます。
　IEEE1588のハードウェア・アシスト機能を搭載したLSIや、FPGAライブラリが続々出てきていますので、ハードウェア・アシスト機能を使用すれば１μ秒を遥かに下回る精度の実現が出来そうですね。

3. 第３回
3.1. はじめに
　IEEE1588では、StatelessとStatefulの２つの状態制御を規定しています。StatelessはIEEE1588規格で規定する状態制御を持たないものです。例として、マスタまたはスレーブと決めたら、P-noからP-offまで決めた動作をするような装置（通信ポート)でしょう。
　Statefulは規格に規定する状態を持ち、規定に従う状態制御を行うものです。Stateful制御では原則として装置（通信ポート）は、みんなでジャンケンをして勝ち残った装置がマスタとなり、負けた装置がスレーブになります。また、規格ではパッシブ(PASSIVE)状態があります。のこ状態は複数ポートの装置のために用意されている状態ですが、単ポートの装置でも発生する状態です。

3.2. Announceメッセージ
　さしずめAnnounceメッセージはジャンケンのグー/チョキ/パーです。
Announceメッセージは自身のプロフィールを、他装置へ広告するメッセージです。原則としてマスタが周期的に送信します。
　Announceメッセージを受信した装置（通信ポート）は、自身のプロフィールとAnnounceメッセージのプロフィールを比較して、動作状態（マスタorスレーブorパッシブ）を決めます。この判定論理をBMC (Best Master Clock)として規定しています。
　マスタではない装置（通信ポート）は、常時マスタからのAnnounceメッセージを受信し、変化するかもしれないマスタのプロフィールと自身のプロフィール（自身のプロフィールも変化する可能性があります）を比較します。また規定時間（announceRecceiptTimeout）内に、1つもAnnounceメッセージを受信しない場合は、自身がマスタとなってAnnounceメッセージを送信します。

3.3. メッセージの送信周期
　マスタはSyncメッセージ送信周期 (syncInterval)時間値とAnnounceメッセージ送信周期 (announceInterval)時間値を持ちます。スレーブが送信するDelay_Req送信周期 (delayReqInterval) 時間も、なぜかマスタが持ちます。
　規格ではsyncIntervalはlogSyncIntervalとなっており、値は2の階乗(2のn乗の値)秒となります。具体的には、logSyncInterval=1は2秒、logSyncInterval=2は4秒、更にlogSyncInterval=0は1秒、logSyncInterval=-1は500m秒、logSyncInterval=-2は250m秒,,,となります。
　基本的は考え方だと、syncIntervalを短くすれば、同期精度が上がりますが、ネットワーク負荷やマスタの処理負荷が上がりますので、このトレードオフで値を決めます。（一般論です）
　Announce Intervalも規格ではlogAnnounceIntervalとなっており、値は2の階乗(2nのnの値)秒となります。
　Delay_Req IntervalはlogMinDelayReqInterval値で、syncIntervalと同様に2の階乗秒です。しかし、名称にMinがついています。これはLogMiniDelayReqInterval=nに対してLogMiniDelayReqInterval=n+1の範囲でランダムな周期を生成する必要があります。マスタが複数のスレーブと同期する場合に、各スレーブからのDelay_Req送信がネットワークに集中することを回避するためです。また、LogMinDelayReqInterval値はマスタが持ち、Delay_Respメッセージで随時スレーブに指定することで、スレーブの台数が増えた場合の、ネットワーク負荷調整がしやすいことを考えています。
  スレーブはDelay_Respメッセージで指定された時間＋乱数で、Delay_Req送信トリガとなるタイマ制御をします。

3.4. BMC
　プロフィールの比較論理です。これは少し具体的に書く必要がありそうです。
　プロフィールで最も重要と思われる情報はclockClassです。詳細は規格を読んで頂きたいのですが、このclockClassは0 – 255の数値です。小さい値ほど強い装置で、4つに分類できます。
　(1) 0 : 使用禁止（将来に向けての予約）
　(2) 1 – 127 : マスタでしか動作できない
　(3) 128 – 254 : マスタでもスレーブでも動作可能
　(4) 255 : スレーブでしか動作できない

　clockClassが1 – 127の装置（通信ポート）は、ジャンケンで勝った場合はマスタ状態になります。負けた場合は悲劇的で、マスタでしか動作できない装置はパッシブ状態となり、ただ黙ってマスタが居なくなるのを待ちます。
　clockClassが128–254の装置（通信ポート）は、ジャンケンで勝った場合はマスタ状態になります。　負けた場合は、単ポートの装置ではスレーブ状態になります。複数ポート装置
（Hub/ルータ/スイッチ）では、更に判定が続きますがここでは省略します。
　clockClassが255の場合は、Annouceメセージを常に受信して、一番強い装置をマスタとして同期します。
　この場ではここまでにして、更なる奥地は後にします。

3.5. 状態制御
　代表的な状態遷移を図 3.1に書きました。厳密な状態遷移は規格書を参照してください。
 規格で規定された状態は図 3.1にある７状態と記述していない「FAULTY」、「DISABLED」です。基本的な動作は、初期化が終わると「INITIALIZING」状態から「LISTENING」
状態に遷移して、回線からAnnounceメッセージ受信を待ちます。
　LISTENING状態ではforeignMasterTimeWindowで設定した時間内に受信したAnnounceメッセージ受信を全てBMCで比較して、その中で一番強い装置（他装置）をEbestとします。
　foreignMasterTimeWindowが終了すると、Ebestと自身のプロフィルをBMCで比較します。この結果をBMC_MASTER/BMC_SLAVE/BMC_PASSIVEとします。
　図 3.1のTimeout(*)はannounceRecceiptTimeout時間内に「信用できる」Announceメッセージを受信しない場合は、MASTER状態になります。「信用できる」Announceメッセージとは、foreignMasterTheshHoldで規定する回数、同一のAnnounceメッセージを受信したものをいいます。このため、MASTER状態の装置がダウンした場合に、他装置（通信ポート）は全てMASTERになる可能性があります。（いっせいにジャンケンを始めます）
　「PER-MASTER」は多ポートを持つ装置で（Boundary Clock）に必要な状態なので、単ポートの装置は、無条件に「PER-MASTER」から「MASTER」に遷移できます。

 

図３－１

3.6. 余談
　趣旨と違い、すこし細かい話になってしまいました。サラッと読めませんね。
解りにくくないですか。私は、「Ebest/Erbestって何だろう」から始めて、BMCと状態制御に関して、規格の意図が解るまで結構時間がかかりました。
　規格での「状態」はあくまでも規格であって、実装する場合は更に細分化した状態が必要になると思われます。例えば、「UN-CALIBRATED」(同期確立待ち状態とでも訳しましょうか）実装毎に同期の確立とか同期はずれの意味が変わりますから、装置毎にこの状態の細分化が変わると思います。
　また、「LISTENING」状態では２つのタイマが時間監視しています。Announceメッセージ受信待ち時間：announceRecceiptTimeoutと、Announceメッセージ確定時間：foreignMasterTimeWindowです。このタイマの起動関係が不明確なので、実装では考慮が必要と思います。

2. 第２回

2.1. はじめに

今回は、非常にシンプルに同期シーケンスを書きたいと思います。

2.2. 同期シーケンス

同期シーケンス概要は１台のマスタが、周期的（周期時間をSyncIntervalといいます）に、時刻カウンタ(Timestump)を入れたSyncメッセージをマルチキャスト送信します。この配布シーケンスをOne-Step Clockといいます。（図 2.1参照）

マスタはTimestump(t1)をSyncメッセージへ設定し送信ます。スレーブはSyncメッセージを受信すると、Syncメッセージに設定されたt1と自身の時刻：Timestump (t2)との差分を補正値としてスレーブの時刻を補正します。　マスタはt1をSyncメッセージへ送信前に設定するので、補正値には、

①マスタがSyncメッセージへTimestumpを設定してから送信するまでの時間と、②Syncメッセージの伝送遅延時間が含まれます。

②の伝送遅延時間は次項で記載するDelayメカニズムで測定します。　①の時間が補正値に対して大きい装置は、Two-Setp Clock（図 2.2参照）で時刻を配布します。

Two-Setp Clockの場合にマスタは、Syncメッセージ送信時刻のTimestump (t1)をFollow_upメッセージに設定して送信します。

スレーブは受信したSyncメッセージのメッセージヘッダにあるtwoSetpFlagを参照して、One-Step ClockかTwo-Setp Clockかを判断します。twoSetpFlagがTRUEの場合は、Syncメッセージの受信時刻 (t2) を記録して、次に受信するFollow_upメッセージに設定されたt1との差分を補正値にします。

  

図 2‑1 One-Step Clock

図 2‑2 Two-Step Clock

 

2.1. Delayメカニズム

スレーブは、前項で補正値に入り込んだ伝送遅延時間を測定して、さらに自身の時刻を補正します。Delayメカニズムには End To End (e2e)　と　Peer To Peer (p2p)の２つが規定されていますが、ここではe2eについて書きます。（図 2.3参照）

スレーブはマスタへ周期的にDelay_Reqメッセージを送信し、このメッセージの送信時刻(t3)を記録します。マスタはDelay_Reqメッセージの受信時刻 (t4) をDelay_Respメッセージに設定して、送信元のスレーブに送信します。

スレーブはDelay_Respメッセージを受信すると、記録したt3とDelay_Respメッセージのt4との差分の1/2を補正値にします。

1/2の理由ですが、まず時刻t3（スレーブの時刻）はSyncメッセージの補正値がフィードバックされていることが前提です。つまりt3にはSyncメッセージの伝送遅延時間のズレが入っています。このため、t4 – t3 は（Syncメッセージの伝送遅延時間）　＋　(Delay_Reqメッセージの伝送遅延時間)です。　「伝送遅延時間が双方向で同じである」とすると、補正値は(t4 – t3)/2となります.

. 第１回
1.1. はじめに
  IEEE1588の2008年版(Version.2)の規格書を読みました。今まで規格書を読む前には、雑誌の特集などを読み、事前に規格の内容をある程度把握してから規格書を読んでいました。しかし、今回はインタネットの情報だけで、「非常にシンプルな手順」であるという先入観を持ってしまい、気軽な気持ちで読み始めたところ、期待を大きく裏切られてしまいました。
  e=mc2シンプルな式から、難解な一般相対性理論に足を踏み入れるような（相当オーバーですが）、Sync/Follow_Upメッセージの周期的なシーケンスと、Delay_Req/Delay_Respメッセージのシーケンスの単純な通信手順で同期するために、これだけの規格量が必要であったのかを理解するのに、相当の時間を要してしまいました。
  ここでは、規格を読む前の事前知識として利用いただければ幸いと思い、規格の概要を少しずつまとめようと考えています。内容にご意見をいただければ幸いです。

1.2. IEEE1588の特徴
  IEEE1394はAV機器の接続をターゲットにして同期信号を出していましたが、イーサネットは早い物勝ちの非同期通信です。
  どんどん高速化され利用されるシーンが増えるイーサネットはポート単価が下がり、デジタル通信の主役となっています。しかし、同期が取れない。そこで最近では、「リアルタイム・イーサ」とか「同期イーサ」という言葉で、イーサネット通信を利用した同期プロトコルが紹介されていますが、そのひとつがIEEE1588です。
  IEEE1588の特徴は、一般のイーサネット通信の中に違和感なく実装できることです。また、NTPと比べると、時刻情報（カウンタ）がナノ秒単位まで拡張されているので、高精度の時刻同期が可能です。更に同期通信シーケンス部分を簡素化しハードウェ化しやすい特徴があります。

1.3. 利用シーン
  AVデジタル通信では、エンコーダ装置とデコーダ装置間でリアルタイム処理を行う場合に、AV処理の基本クロックを同期することで、アンダランやオーバランの発生を抑止できます。携帯電話の基地局のデジタル化では、IEEE1588が注目されています。
  FA（工場の生産設備）通信では、制御メカ（モータ）制御で複数のメカ部を、高精度に同期させる
ために、より精度の高い（１μ秒オーダの）精度要求があります。FAではEtherCATをはじめ、通信媒体としてイーサネットを利用した沢山の同期通信手順が提案されて、製品化されています。
  大きなネットワークとしては電力会社の送電制御ネットワーク（スマートグリット）でも注目されています。
  利用目的は、通信装置間が処理に利用する基本クロックの周波数を同期したい場合と、通信装置間の処理の同時性の同期があると思われます。

1.4. 同期とは
  よく「IEEE1588はナノ秒精度の同期」と表記されていますが、何?と何?の何?を同期するのかを理解して、IEEE1588を検討する必要があると思います。
イーサネット通信でIEEE1588を実装するだけで、複数の端末の制御メカやアプリケーションソフトが同時に動き始めると誤解しがちですが、このIEEE1588が規定するPTP ( Precision Time Protocol )は、装置間で「時刻」を同期する通信手順です。PTP手順を実装するだけでは、制御メカは同時に動きません。
 通信システムで接続された複数端末が独自のクロック源で時刻を更新している場合に、時刻同期するとは、時刻更新の周波数を合わせることと、時刻の位相を合わせることになります。
  「周波数を合わせる」とは、実装によりますがPTPを使いうことで、マスタとスレーブ間で、時刻の更新間隔の誤差を、ある絶対時間内に入れることです。「時刻の位相を合わせる」は、時刻更新の同時性で、やはり誤差を絶対時間内に入れることができます。このため、制御メカやアプリケーションソフトを同時に動かすためには、IEEE1588規格外の機能
が必要となります。
  「ナノ秒精度」とは、PTPで扱う時刻（カウンタ）がナノ秒まで扱えることで、同期精度は規格で規定されていません。

  規格書が理解しにくい理由のひとつに、ノード（装置）は通信ポートを複数持つことが前提で規定されています。通信ポートが１つの装置だとどんな意味を持つのだろうと考えると、とても難しいものでした。話を簡単にするためにまずは、通信ポートが１つの装置で、私の理解した内容を書いていきます。

1.5. 余談
  次回から、規格の内容に入ろうと思います。
 厳密性を追及すると、規格書の順番に書かないと、用語が定義が前後したり、規定内容が順不同になったりします。でも、読み難いので、思いついた所から、できるだけ簡単に、私見をいれながら書いていきます。このため間違えがや誤解を招く表現があるかもしれません、気がついたならば、是非、ひとこと注意頂ければ幸いです。