大規模SCADAプロジェクトのタグ命名規則とエンジニアリングテンプレート

タグ名が乱れると後工程で払う代償

• 重複と衝突：二つのステーションがどちらも Pump1_Run を持ち、帳票が混ざり、事象がどの現場か分からない
• 画面とタグが乖離する：HMIの表示名は書き換えたのに、実体のタグは電気担当の略号のまま、障害切り分けに二系統の語彙が要る
• アラーム文をタグから生成できない：メッセージを手打ちしているため、プロセス側の改名がアラーム一覧に届かない
• 増設が乱れを複製する：次エリアを最初のエリアからコピーし、悪い名前ごと持ち込み、ラインが増えるたびに整理コストが増える
• 引継ぎが属人化する：T12 がAポンプ吐出温度だと知るのは当初の担当だけで、その人はもう現場にいない

この五つの代償は試運転の最中ではなく、その後に現れます。だから先送りしやすく、事後の挽回は高くつきます。命名規則は初週に決める方が安く、HMIが稼働してから数万点を付け替える作業は、同じ量ではありません。

命名規則がカバーすべきフィールド：エリア・設備・信号・種別

命名規則は好みの問題ではありません。すべてのタグ、アラーム文、画面オブジェクトをそこから導ける契約です。フィールドが欠けていると、後工程のスクリプトはエリアで絞れず、アラーム文を作れず、プロセス値と指令の区別もつきません。

次の四フィールドは、最初のタグを切る前に決める下限です。区切り文字・長さ・文字種も同じ規則に入れます。メーカー混在のPLCと、後のデータベース書き出しが、いいかげんな綴りを許さないからです。当社は単一プロジェクトで約80000変数、366台の設備を同一ネットワークで収集した実績があります。この数字は個別案件の記述であり、典型的な規模でも、あらゆる契約に掲げる点数の上限でもありません。示しているのは、点数が増えても規則が持つ必要がある、ということです。パイロットラインの数百点だけで綺麗でも足りません。

• エリア（サイト、ライン、建屋）：資産の地理的な所属——工場、職場、ライン、ポンプ場コード。これがないと、別棟の同一機種が衝突する
• 設備（ユニット、スキッド、単機）：資産そのもの——圧縮機、コンベヤ、ポンプユニット。同一機の信号が並ぶようにする
• 信号（測定値または機能）：読むもの、書くもの——運転フィードバック、吐出圧力、故障、設定値
• 種別（クラス）：アナログ入力、アナログ出力、デジタル入力、デジタル出力、演算点、アラーム、設定値。ヒストリアン、画面、アラームエンジンが点の性質で扱えるようにする
• 区切り・長さ・文字種：区切りは一つ（アンダースコアがよく使われる）、長さは最も短いPLCとヒストリアンの双方が受けられる値、スペースや書き出しを壊すロケール記号はタグ名に入れない

画面より先に出す工程テンプレート：I/O割付、点表、画面仕様書

画面はSCADA案件で目に見える部分なので、議論は画面から始まりがちです。大規模案件では順序を逆にします。I/O割付、点表、画面仕様書は、誰かが描く前に存在していなければなりません。この三つが無いと、後の画面は場当たりで名前を発明し、稼働中のシステムに照合できるマスターが残りません。

上記の収集規模に加え、当社は約30000アラーム点規模の案件でアラームの工程化を実施しています。これらは個別案件の実証であり、どの現場もその規模だと見込む数字ではありません。ソフトが何点まで取れるかという宣伝文句でもありません。あるセグメントの点数の上限は、帯域、ポーリング周期、サーバ余裕で決まり、試運転で初めて知るのではなく、次のテンプレートに書いておきます。

• I/O割付表：盤、スロット、チャネル、信号種別、エンジニアリングレンジ、行き先タグ名。PLCアドレス付けの前に凍結する
• 点表（タグリスト）：マスター——タグ名、説明、エリア、設備、アドレス、データ型、スキャンクラス、単位、アラームフラグ。1点1行、ファイルの責任者は一人
• 画面仕様書：どの画面があるか、どのタグをバインドするか、ナビゲーションとアラームの見せ方。作画の前に書き、作画後の後付けにしない
• アドレスとネットワーク図：どのコントローラがどの範囲を持つか、同一セグメントの台数、合意したポーリング周期におけるそのセグメントの点数の上限

悪い命名、それが起こす問題、推奨構造

下表は現場で使えるチェックリストであり、万能の規格ではありません。第3列の型は AREA_EQ_SIGNAL_TYPE です。四フィールドを自工場で埋め、綴り・区切り・長さを凍結し、以後の取り込みを同じ契約に乗せます。

推奨構造は出発点のテンプレートです。文字種、長さ、エリアと設備の具体コードは、使用中のPLCメーカーとヒストリアンに合わせて現場と合意します。

アラーム点とプロセス点は分けて管理する

プロセス点は「今いくらか」に答え、アラーム点は「人が動く必要があるか」に答えます。数百点では一点に同居させたくなりますが、数千点では扱えなくなります。アラーム一覧はプロセス点表の省略命名をそのまま継承し、後の整理にきれいなリストが残りません。

重要度の分級、抑制、復位アーカイブは別設計です。SCADAアラーム整理のコラムで扱っており、本節はその教程を繰り返しません。ここで決めるのは、後工程を可能にする分割です。二つの点群、二人の責任者、エリア・設備・信号からアラーム文を生成できる一つの命名契約です。

• 点群を分ける：アラームが必要なプロセス点には対になるアラーム点、または名前で紐づくアラーム記録を付ける。兼用点にしない
• アラーム文は命名フィールドから生成する：エリア、設備、信号で読める文を作り、改名時はタグと文を同時に更新する
• 責任者を分ける：プロセス点はI/Oとヒストリアン、アラーム点は運転側が持ち、等級とクローズ規則を付け、二つのリストは異なる周期で見直す
• アラーム等級をすべてのプロセス名にコピーしない：等級はアラーム記録に属する。HH、H、L、LL を何千ものプロセス点に書き込むと、後の再分級が大量改名になる

約30000アラーム点の案件で持ちこたえたのは、この分割であり、より大きな画面ではありません。ほとんどの工場はこの点数に達しません。数百件の段階で点群を分ける価値は、その時点のコストがまだ低いからです。