SECS入門
Factory automation standard CIM system
SECS-II
SECS-II規約はメッセージを定義しています。（SECS-E5)
SECS-I ヘッダー部のメッセージIDにStream/Functionの番号を設定してそれらが意図する内容のデータが添付されます。
書面上の表記は”S1F１”の様に記述します。
例えば、あるStream/Function番号が処理レシピの事ならデータ部に添付される情報はポジション単位の処理時間だったり使用する薬液の種類や温度等のレシピ情報に成ります。
Stream/Function番号の意味は予めSECS-IIで大まかに定義され予め装置毎に使用するStream/Function番号を限定したうえで装置-ホスト間の取り決めについて詳細に仕様を定義します。
また幾つかのStreamに対してFunction 0が存在します。
Function 0は特殊でAbort Functionに限定されています。
リクエストに対してAbort Functionが返された場合 そのトランザクションは無効となり T3 TimeOutと同等とされています。
しかしこれまでの経験では実際の通信仕様で使用することは有りませんでした。
Stream/Functionによってはヘッダーのみのメッセージも有ります。使用する全てのStream/Functionについてホスト側と装置側で仕様の整合が必要です。
Stream カテゴリ一覧表
SECS-IIのプロトコル
SECS-IIで規格されたメッセージはリスト（と言うステートメント）とアイテム（リスト以外）を使って論理的な構造化することが出来ます。（ツリー構造が出来ます。）
データ部分はアイテム毎にIH（アイテムヘッダー）と実際のデータで形成します。
ヘッダーの最初の1Byteは２桁の８進コードとレングスバイト数を表す２ビットをミックスしています。
レングスバイト数を示す２ビットの状態が
00：これはエラーです。
01：レングスバイトは１バイト構成（最大255）
10：レングスバイトは２バイト構成（最大645ｋ）
11：レングスバイトは３バイト構成（最大7.99M）
＊：レングスバイト数は占有バイト数を示し文字数では有りません。
＊：SECS-Iの場合、ブロック単位で255Byteなので基本的にレングスビットは01のみ
フォーマットコードリスト
＊：リストに関してはレングスバイトがリスト構造の要素数に成ります。
＊：2byteキャラクタに関しては先頭にコード方法を識別するためにLSH（Local String Header）
16bitが追加されます。（LSHの2byteもレングスバイト数に含みます。）
LSH コード表
データの記述例（仕様書に記載するフォーマットの例）→ SEMI-E5参照
（メッセージに使われる変数名は予めSECS−II(SEMI-E5)で形式、バイト数が定義してあります。）
S1,F13（Establish Communication Request）通信確立要求 S,H↔E 返信
L,2
1.<MDLN> → 装置の形式 ASCII 6バイト
2.<SOFTREV> → ソフトウエアのレビジョンコード ASCII 6バイト
S1,F14（ Establish Communication Request Acknowledge）通信確立要求確認 S,H↔E
L,2
1.<COMMACK> → 通信確立確認コード 1バイト ０＝確立
2.L,2
1.<MDLN> → 装置の形式 ASCII 6バイト
2.<SOFTREV> → ソフトウエアのレビジョンコード ASCII 6バイト
S1F13/S1F14は予めSECS-IIで定義されたメッセージです。
ユーザー定義で使用出来る範囲はStream1〜63ではFunction64〜255
Stream64〜127ではFunction1〜255を使用します。
装置側はホストのSECS-II仕様に準拠する必要がある
多くの場合予めホスト側の通信仕様を受ける形で装置側の通信仕様を作り込む事になります。
経験ではオンラインシーケンスからプロセスシナリオを含むフローも異なる場合が多く
仕様書のフォーマットもホスト側が提示するフォームを継承する書式が望ましい様です。
SECSの中でも仕様書のフォーマットが定義されていますがあくまでも参考というスタンスで
ホスト側の仕様書はSECSの仕様書フォーマットを継承しているケースが多いので完全に異なるフォーマットになっていることは滅多にありません。
装置独特の仕様に関しては特に詳細を明確にします。
１・アラームとワーニングの種類に関する情報
→ アラームが重異常なのか軽異常なのか明確にする必要が有ります。
それによりアラーム発生時の装置の振る舞いに関しても明確にする必要が有ります。
２・装置状態の推移に関する取り決め
→ 複合的な設備の場合ユニット単体でステータスを持っていることがあり統括する必要が有ります。
３・装置構成による特異性に関する取り決め
→ リモートコマンド（START,STOP,PAUSE,..等）に対する装置側の振る舞い
→ 装置の構成によっては他社製の設備に関する情報収集を担うことが有ります。
４・トレーサビリティ情報に関する取り決め
→ 収集できるトレーサビリティ情報の提示と明文化（収集方法や精度など）
５・標準シナリオと異なるフローでの装置の振る舞い
→ 例えば標準シナリオではプロセススタートの前にレシピ転送を標準としているがレシピ指示の
無いまま処理スタートを受けた場合の装置側の対応など
＊：経験では特に仕様変更や要求変更等が発生しやすい事柄です。
イレギュラーケースを明確にする事
仕様書の中で最も難しいのはイレギュラーケースを想定して振る舞いを定義する作業です。
通常の処理フローは基本的にホスト側のシナリオに準拠する事を求められ装置側としては
イレギュラーなフローを予め想定してその時の装置側の振る舞いを明記します。
１・タイムアウト発生時の定義（対応可能な監視タイマーの明確化）
２・イレギュラーコマンド受信時の応答の定義
３・プロセスアボート受信時の装置側の動作フローの定義
４・装置故障時のデータ欠損に関する装置側の仕様
５・装置内管理データのメンテナンス方法の定義
６・アラームとワーニングによるプロセスデータへの影響に関する詳細仕様
＊：仕様として明記された内容は全て実機試験の項目とし検査結果を残しておくことで
予期しないトラブル発生時に責任範囲の線引きとして有効な情報となる場合が有ります。
マンマシンインターフェースとサポート・システム
UIのデザインは装置側の独創性が問われますが操作性やシステムの特異性をよく考慮したデザインを
構築しないとユーザーに嫌われてしまい結果的に装置の評価が下がってしまいます。
SECSで要求される項目について列記します。
１・モニタシステムの構造や内容に関する仕様
２・ログデータについて内容、頻度、データ量、フォーマット等
３・装置モードとオペレータの介入に関する装置制御仕様
SECS-IIが定義する様々な仕様は基本的に参考値とされています。
従ってホスト側の仕様がSECS-II仕様より優先されます。
intelli-Calc
iPhone Application
Production PR
不思議な電卓アプリ intelli-Calc
計算式を入力するとその式を解析して逆計算や穴埋め計算が出来ます。計算式は名前を付けて保存できます。簡単なワリカン計算から共振周波数計算など複雑な計算まで対応！
