PLC プログラム標準化の進め方：階層・命名・版管理

一、PLC プログラム標準化とは：個人の習慣を工程資産に変える

PLC プログラム標準化とは、制御プログラムの書き方を個人の習慣から、チームが再利用できる構造へと収束させることです。同じ包装機でも、二人の技術者が書けば変数命名、セクションの分け方、アラーム処理の仕方が違ってきます。納品から三年後に開発者が退職すると、引き継いだ人は数日かけてロジックを読み、ようやくインターロック条件を一つ変更できます。標準化の価値はここにあります。構造・命名・文書に共通の取り決めがあれば、誰でも同じ道筋で同じ場所にたどり着けます。

範囲は明確にしておきます。標準化が縛るのはプログラムの構成方法と成果物であり、プロセスそのものではありません。レシピ、タクト、動作順序は顧客の工程に従います。「書き方を制限するもの」と受け取られることがありますが、固定されるのは骨格とインターフェースであり、階層が明確になれば工程ロジックはかえって変更しやすくなります。IEC 61131-3:2013 はプログラム構成単位（POU）、ファンクションブロック、グローバル変数の概念をすでに定義しています。工程側の仕事は、その概念をプロジェクトのフォルダ構成、セクション順、命名規則に落とすことであり、別の仕組みを新たに作ることではありません。

判断基準は一つです。開発に関わっていない人にプログラムを渡し、「ステーションを一つ追加する」変更を頼みます。既存構造の中に挿入位置を見つけ、他のステーションのロジックに触れずに済めば、標準化は機能しています。全体を読まないと判断できないなら、標準化はファイル命名の段階で止まっています。

二、階層の切り方：設備層・ユニット層・プロセス層・共通層

階層分けの目的は、変化する頻度の異なるロジックを分けることです。設備層の動作詳細は機械構造で変わり、ユニット層の連携はライン配置で変わり、プロセス層のレシピは製品で変わり、アラーム・権限・通信といった共通層はほとんど変わりません。四種類のロジックを一つのブロックに混ぜると、どこか一箇所の変更で全体を再検証することになります。

• 設備層：一台の設備の起動停止、インターロック、リミット、単体故障処理。設備ごとに一つのファンクションブロックとし、外部には起動・停止・リセット・状態の四つのインターフェースだけを公開します。
• ユニット層：ステーション間や設備間の連携。上下游のハンドシェイク、タクト同期、バッファ判定など。この層は設備層のインターフェースだけを呼び、相手の内部変数を直接読み書きしません。
• プロセス層：レシピ、パラメータセット、工程ステップのシーケンス。レシピデータはパラメータ表やデータベースに外出しし、レシピ変更でプログラムをダウンロードし直さないようにします。
• 共通層：アラームの階級、操作権限、時刻同期、通信マッピング、データ記録。案件全体で一つを共用し、ステーションごとに書き直しません。

工程ファイルのレベルでは、階層は決まったフォルダ構成とセクション順になります。各ファンクションブロックはインターフェース記述から始まり、本体ロジック、例外処理はセクション末尾にまとめます。取り決めが決まればコードレビューにも共通言語が生まれ、レビュー担当はまずインターフェースが層を越えていないかを見て、次にロジックが工程と合っているかを見ます。

注意点として、階層は多ければよいわけではありません。設備種類が単一でバッチが小さい案件では、四層構造は保守対象を増やします。その場合は設備層と共通層の二層に留め、連携ロジックを呼び出し側に書くほうが現実的です。階層の粒度はテンプレートではなく、設備の反復度から決めるべきです。

三、命名・変数表・コメント：引き継ぐ人に読める形にする

標準化の中で費用対効果が最も高いのが命名です。同じ信号が案件によって M100、Start_OK、X12 と呼び方が変われば、保守は推測作業になります。三段式の命名は設備・機能・連番を固定し、名前を見ればどの設備の、何をする、何番目の信号かが分かります。

変数表は後追いではなく、プログラムと同時に提出します。少なくともアドレス、データ型、レンジと工学単位、所属ファンクションブロック、初期値、停電保持の有無を含めます。アナログ量は特に注意が必要です。4–20 mA と工学レンジの対応、フィルタ時間、断線判定しきい値の三項目が書かれていないと、次の人が調整した時点でずれます。

コメントはどの程度まで書けば十分か。判断方法は、コメントだけを読むことです。プログラムを見ずに、このブロックがどの条件で呼ばれ、失敗時に何が起きるかを説明できるか。できなければ、そのコメントは「動作名」を書いているだけで、「設計意図」を書いていません。

四、版管理・バックアップ・引き渡し検査

現場での変更がプログラムを不安定にする主因です。試運転期に一日十数版変わるのは日常であり、版の記録がなければ一週間後にはどれが実機で動いている版か、どれが試験版か分からなくなります。版管理が答えるべきは三つです。いま動いているのはどの版か、その版で何を変えたか、問題時にどの版へ戻すか。

• 版番号の規則：メジャー番号は工程または構造の変更、マイナー番号はパラメータと局所ロジックの調整。版番号はプログラム先頭のコメントと盤内の版ラベルの両方に記載し、一致させます。
• アーカイブの頻度：試運転期は毎日、安定後は変更のたび。アーカイブにはソースプロジェクト、変数表、コメント説明、ビルドログを含め、一つ欠けると次の担当で連鎖が切れます。
• 変更の記録：誰が、いつ、なぜ、どの範囲に影響する変更かを記録。インターロックと安全関連ロジックの変更は別途明示し、レビューします。
• バックアップと復旧：機械側にオフラインで復旧できるバックアップを一つ、サーバ側に履歴版を一つ。バックアップの有効性はファイルの存在ではなく、復旧演習で確認します。

安全関連ロジックには追加の要件があります。ISO 13849-1:2023 は制御システムの安全関連部の設計と検証の道筋を示しており、安全機能を通常のプログラムセクションにコメントで区別して書くだけでは足りません。EU 機械規則 (EU) 2023/1230 は 2027 年 1 月 20 日から適用され、安全関連部としてのソフトウェアには追跡可能な版と検証記録が求められます。IEC 62443-3-3:2013 はプログラム変更とアクセスの管理を求めており、誰がダウンロードでき、誰がパラメータを変更でき、変更が記録されるかは、納品範囲に含まれる事項です。

引き渡し検査はチェックリストで行い、五項目がそろって初めて完了とします。ソースプログラムとビルド可能なプロジェクト、変数表とコメント、版と変更記録、バックアップファイルと復旧手順、そして現場での復旧演習一回。最も飛ばされやすく、最も問題を露呈するのが演習です。バックアップファイルはあるが復旧できない、という例は少なくありません。