「SECS/HSMS通信を用いたシステム開発」

私は主にWindowsアプリケーションの開発を担当しています。先日、製造装置管理システム開発において、SECS-Iという比較的古い通信プロトコルを扱う機会がありました。

SECS通信は、製造装置とホストシステムを接続するうえで重要な技術ですが、実際に開発に携わるまでは、その仕組みや関連規格について体系的に理解できているとは言えませんでした。 また、レガシーな通信方式であるがゆえに、実装や動作確認の面で独特の難しさもありました。

本レポートでは、SECS通信に関する知識をあらためて整理するとともに、実際の開発を進める中で意識した点や難しかった点について紹介します。

SECS（SEMI Equipment Communications Standard）とは、半導体業界の国際標準であるSEMIスタンダードの中で、製造装置とホスト間のメッセージ交換に関する通信インタフェースを定義している複数規格のまとまりです。
SECS通信はSECS/GEMとして装置の通信規格として言及されることが多いですが、実際には複数のSEMIスタンダードが階層構造で構成されたものです。階層は図1のように表現されます。

図1. SECS/GEMプロトコル階層

2-1. SECS-I（SEMI Equipment Communications Standard - I）

2-2. HSMS（High-Speed SECS Message Services）

2-3. SECS-II（SEMI Equipment Communications Standard - II）

2-4. GEM（Generic Equipment Model）

なぜこのような階層の理解が必要になるかというと、「SECS通信を行っている」という事は必ずしも「GEM対応である」という事を示さないからです。特にSECS-Iで通信しているような旧世代型の装置についてはこの傾向が強く見られます。
そのため、システム開発にあたっては装置の通信仕様をしっかり確認することと、実際にどのメッセージを使用しているかを現場のログを見て確認するということが重要です。

今回の開発において特に意識する必要があったSECS-IとHSMSの相違点について説明します。

表1. SECS-IとHSMSの違い

SECS-Iはシリアル通信を前提とした規格であり、通信速度や接続形態の面で制約があります。 たとえば、一般的な9600ボーレートのSECS-I通信では、1000文字のASCIIデータを送るだけでも1秒かかります。 したがって1000文字以上のメッセージを1秒以内に受信し続ける状況であれば、受信バッファにデータが蓄積し、最終的にバッファオーバーフローを引き起こします。

アプリケーション実装上における違いとして、HSMSではメッセージ送受信におけるハンドシェイク・チェックサムの実装は必要ありませんが、SECS-Iでは必要です。 また、256バイトを超えるメッセージはSECSではマルチブロックと呼ばれる複数のブロックメッセージに分割して送信する必要があります。

この表には含めていませんが、メッセージヘッダ構造の違い、タイムアウトの種類などにも違いがあります。ただし、本レポートでは詳述しません。

SECS-IIは、製造装置とホストシステムの間でやり取りされるメッセージの内容を定義する規格です。その中でも中心となるのが、ストリーム/ファンクションによるメッセージの分類です。

SECS-IIのメッセージは、一般に S1F1 や S2F14 のような形式で表されます。ここで、S はストリーム（Stream）、F はファンクション（Function）を表します。

ストリームは、メッセージの機能的な分類を示す番号です。たとえば、装置状態に関するやり取り、制御に関するやり取り、イベント通知に関するやり取りなど、同種の目的を持つメッセージがストリーム単位で整理されています。すべては紹介しませんが、よく使用するものとしては以下のようなストリームがあります。

ストリーム1（S1)：装置の状態
ストリーム2（S2)：装置の制御と診断
ストリーム5（S5)：エラーとアラーム報告
ストリーム6（S6）：データ収集

一方、ファンクションは、そのストリームの中で個々のメッセージを識別する番号です。
ストリームが大分類、ファンクションがその中の個別メッセージを表す小分類と考えると分かりやすくなります。

SECS-IIのストリーム/ファンクションでは、一般に奇数のファンクション番号がリクエスト、偶数のファンクション番号がそのレスポンスとして対応します。たとえば、S1F1 がある情報を問い合わせる要求メッセージであれば、それに対応する応答は S1F2 となります。このように、ファンクション番号の奇数・偶数の関係を見ることで、そのメッセージが要求なのか応答なのかを把握しやすくなっています。

図2. ストリーム/ファンクションを用いたトランザクションの例

この奇数のリクエストを送信し、偶数のレスポンスが返ってくるまでの一連の送受信をトランザクションと呼びます。

今回取り上げる開発事例は図3のような構成です。

図3. システム構成

私は、サーバー内で稼働するソフトウェアの実装を担当しました。サーバーは製造装置に対するホストシステムとして動作します。

今回の要求仕様では、装置が通常運転中に行っている常時通信とは別に、操作端末から特定の操作が行われた際、操作用のストリーム／ファンクションを装置に送信するという内容がありました。つまり、通常運転用の通信が流れている最中に、必要に応じて別用途のメッセージを割り込ませて装置へ送る必要があるということです。

この要件自体は一見すると単純に見えますが、SECS-Iではハンドシェイク・マルチブロックの制約から、メッセージを割り込ませて良いタイミングをアプリケーション側が強く意識する必要があったため、実装上の難しさにつながりました。

ここからは上記のシステムをSECS-Iで実装する際に最も苦労した、HSMSとSECS-Iでの割り込みタイミングの制御方法の違いについて踏み込んで解説します。

6-1. ハンドシェイクを考慮した制御

6-2. マルチブロックを考慮した制御

6-3. トランザクションを考慮した制御

6-4. まとめ

ここまで述べてきたように、ひとくちにSECS通信と言っても、SECS-IとHSMSでは前提となる通信方式や実装内容が大きく異なります。 実際の現場でも、SECS通信といってもSECS-Iで通信されている装置、HSMSで通信していてもGEMには準拠していない装置など、構成や仕様はさまざまです。 したがって、製造装置に関するシステム開発では個別の装置ごとの仕様を理解することが欠かせません。

比較的新しい装置であれば、既存のパッケージで対応できる場合も多くあります。 しかし実際の現場では、装置ごとの独自仕様や既存システムとの接続要件、運用上の制約などにより、スクラッチでの設計・開発が必要になる場面も少なくありません。

ソフテックでは、SECS通信に限らず、各社PLCやリモートI/Oユニットなど、多様なインタフェースを用いて製造装置とシステムを接続してきた実績があります。 また、社内にはこうした分野に精通した先輩社員も多く、技術的なナレッジが蓄積されています。

私自身、レガシーな通信プロトコルを扱うシステム開発に携わることに当初は不安もありました。 しかし、上司・チームメンバーの支援を受けながら開発を進めることで、着実に理解を深めながら業務に取り組むことができました。今回の開発を通じて、既存技術を正しく理解し、現場に合わせて実装していく力の重要性を強く実感しています。

記事が、SECS通信や製造装置をつなぐシステムの開発に携わる方にとって、その概要の一端を知るきっかけになれば幸いです。