このブログはもともとcimetrix.comに掲載されていました。
プロトコル層の目的
プロトコル層はデータをパッケージ化し、工場ホストと機器のGEMインターフェース間で確実に転送する。
プロトコル層定義
プロトコル層は、工場ホストと機器のGEMインターフェース間で有線経由でメッセージを送信するために使用される伝送技術とデータパッキングアルゴリズムを実装する。
SEMI E5規格（SEMI Equipment Communications Standard 2 Message Content：SECS-II）は、データとして使用されるSECSメッセージを定義し、それらを転送用にバイナリバッファへパッキングする方法を規定する。
SEMI E37およびE37.1規格「高速SECSメッセージサービス（HSMS）」は、TCP/IP接続を介したSECSメッセージ交換のプロトコルを定義する。これはSECS/GEMにおいて最も広く使用されているトランスポート技術である。
HSMSプロトコルスタック
SEMI E4規格（SEMI Equipment Communications Standard 1 Message transfer：SECS-I）は、RS-232経由でSECSメッセージを交換する仕組みを定義する。これは通常、旧式の装置や、EFEMコントローラなどの装置内部のハードウェアで使用される。
この文書の残りの部分では、HSMSを介したSECSメッセージに焦点を当てます。
プロトコル層の利点
GEMのプロトコル層は接続を維持し、接続の喪失を検出するため、いずれの側もスプール処理の起動など適切な措置を講じることができる。
プロトコル層は、必要に応じてメッセージの確実な配信を保証するためのハンドシェイク機構を定義する。
プロトコル層の接続は、工場ホストと機器間のポイントツーポイント接続です。ブロードキャスト機能を持たない専用接続であり、これによりネットワーク負荷の予測が容易になります。
データ密度
SECS/GEMはオーバーヘッドが少なく高密度でデータを伝送します。これは、特定のデータセットに対してネットワーク帯域幅の使用量が少なくて済むことを意味します。
説明のために、イベントレポートの典型的な例を見てみましょう。そして、SECS/GEMメッセージングを、ある程度同等のXMLおよびJSONメッセージと比較します。
典型的なGEMインターフェースでは、IDに符号なし4バイト整数を使用し、イベントレポートには8バイト浮動小数点数と4バイト整数が含まれる。このメッセージの例を、E5に準拠したSECS/GEM形式および同等のJSON・XML形式で下表に示す。
バイナリ形式のSECS/GEMメッセージは58バイト、JSONは約206バイト、XMLは175バイトをネットワーク経由で送信します。JSONとXMLのバイト数はキー/要素名によって多少変動し、上記は数ある表現方法の1例に過ぎません。
以下の図は、例示メッセージのデータ密度比較を示しています。実際のデータサイズは、2つの4バイト整数＋2つの8バイト浮動小数点数＋1つの4バイトイベントID＋1つの4バイトレポートID＝32バイトの実データとなります。オーバーヘッドは、メッセージの総バイト数から実際のデータサイズを差し引くことで算出されます。
例示メッセージにおけるSECSのデータ密度について、データ密度のパーセンテージは下記のグラフに示されています。データ密度のパーセンテージは（実際のデータ量）÷オーバーヘッド×100で算出されます。
例示メッセージを100個の8バイト浮動小数点数に変更すると、データ密度％グラフは下記のチャートに変化します。JSONとXMLは比較的同等ですが、SECS/GEMのデータ密度が78％に増加していることに注目してください。
SECS/GEMエンコーディングのオーバーヘッドは非常に小さい。メッセージのオーバーヘッドは、メッセージを記述するヘッダーに10バイト、メッセージ本体のサイズに1～4バイトが追加される。SECSメッセージ内の4バイト整数または浮動小数点数については、6バイトが送信される。内訳は整数値4バイト＋型情報1バイト＋データバイト長1バイトである。 同様に、8バイト整数または浮動小数点数の場合は10バイトが送信されます。文字列値の場合、長さは文字数に2～4バイトが加算されます。SECSメッセージ内でリスト（上記の可読例におけるL）が現れるたびに、メッセージに2～4バイトが追加されます。
数値配列はSECS/GEMにおいて極めて効率的である。配列のオーバーヘッドは、型指定に1バイト、配列長に1～4バイト、さらにネイティブサイズのデータ分が必要となる。例：4バイト整数10個の配列は42バイトを消費し、データ密度95%を実現する！
JSONの例では、4バイト整数は16バイト＋整数を表現するのに必要な文字数、つまり17～28バイトを要する。浮動小数点数も同様のオーバーヘッドだが、値を表現するためにより多くの文字を必要とする可能性が高い。
XMLでは、オーバーヘッドはXML要素名のサイズに基づきます。上記の例で使用した要素名の場合、4バイト整数のネットワーク経由の転送バイト数は、9バイトに整数を表現するのに必要な文字数を加えた値、つまり10～21バイトとなります。浮動小数点数は、値を表現するために使用される文字列フォーマットに依存します。
要約すると、通信上の項目ごとのバイトサイズを見ると、SECS/GEMは非常に高密度である。4バイト整数の例では、SECS/GEMは通信上で6バイト、JSONは17～28バイト、XMLは10～21バイトであり、パラメータ数を増やすにつれてオーバーヘッドが顕著に影響することがわかる。 300mm半導体装置では、プロセスモジュールあたり毎秒1000個のパラメータをホストに転送することが想定される。2モジュール装置の場合、データ部分だけで以下のバイト数となる：SECS/GEM経由で12Kバイト、JSONで34K～56Kバイト、XML例で20K～42Kバイト。 これらの数値はメッセージ全体のサイズではなく、パラメータ値に関連する実際の部分のみを考慮したものです。もしそのデータを、1メッセージあたりの値が少ない多数のメッセージで転送する場合、ネットワーク負荷はさらに悪化します。あらゆるケースにおいて、より少ない数の大きなメッセージが常に望ましいのです。
XMLとJSONは、使用する伝送プロトコルによってはオーバーヘッドを増大させる可能性があります。例えば、XMLはSOAPを使用してHTTP経由で伝送されることが多く、これにより2層の追加オーバーヘッドが生じ、各メッセージごとに伝送されるバイト数が増加します。SECS/GEMのバイト数は、TCP/IP上に伝送される実際のデータ量を示しています。
データ翻訳なし
数値データはSECS/GEMにおいて変換なしで送信される。数値はネイティブ形式で送信される。例えば：8バイトの浮動小数点数は、変換、切り捨て、丸めを一切行わず、8バイトの表現形式のまま送信される。
JSONやXMLなどのプロトコルでは、これらの8バイト浮動小数点数をテキスト表現に変換する必要があります。 この変換にはエンコードとデコードのための計算リソースが必要であり、通信上ではさらに多くのバイト数を要する。IEEE754規格では、8バイト浮動小数点数を文字列として正確に表現するには17桁の十進数が必要である。符号、小数点、指数、指数符号の文字を加えると21文字となる。これはSECS/GEMが通信で送る量の2倍以上である。
回路保証
HSMSはリンクテストと呼ばれる回線保証メカニズムを定義する。プロトコル層には、アクティブなメッセージ交換がない場合に開始されるタイマーが存在する。タイマーが切れるたびに、接続がまだ開いていることを保証するためにプロトコルメッセージが交換される。
セキュリティ
HSMSはセキュリティを定義していません。接続元の検証はなく、接続に認証情報や証明書は不要です。データは通常の暗号化アルゴリズムで暗号化されませんが、データパッケージングプロセスを通じて難読化され、一般的に人間が読める形式ではありません。
工場ネットワークは外部から隔離されているため、通常はセキュリティ上の問題とは見なされない。
結論
HSMSを利用したSECS/GEMプロトコル層は、工場ホストと装置間で正確なデータを交換する非常に効率的な手段を提供する。