HMI画面開発｜産業用PC移行の仕様・保守・FAT/SAT

HMI 画面 開発を、従来の一体型タッチパネルから産業用PCへ移行する前提で整理すると、論点は画面の見た目ではなく、実装方式、PLCタグ連携、アラーム・ログ、ランタイム、OS保守、バックアップ、責任分界、そしてFAT/SATです。特にタイ工場の製造技術・調達担当者にとっては、RFP段階でここを曖昧にすると、立上げ後の保守負担がベンダー依存になりやすくなります。

本記事は、既存設備更新や新規ライン導入時に「産業用PCベースのHMI/SCADAにするべきか」「一体型パネルを継続するべきか」「薄型クライアント＋中央サーバ方式にするべきか」を比較しながら、実装・保守・検収のための仕様化に焦点を当てます。

なお、画面遷移、配色、アイコン、オペレータ視認性、コスト階層などの画面デザイン論は本稿の対象外です。そちらは別記事のHMIタッチパネルの画面設計をご参照ください。本稿は、あくまで実装アーキテクチャと運用保守の話です。

この記事の対象と、既存の画面設計記事との違い

本記事の目的

本記事の目的は、タイ工場の製造技術・調達担当者が、HMIの産業用PC移行を検討する際に、以下をそのまま社内検討やRFPに落とし込めるレベルで整理することです。

• 方式選定の比較軸を明確にする
• ベンダーへ依頼すべき責任範囲を分解する
• FAT/SATで何を確認すべきかを見える化する
• 保守・バックアップ・更新手順を変更管理込みで定義する
• 将来の改造や多言語展開で破綻しにくい構成にする

本記事で扱う範囲

扱うのは次の領域です。

• 産業用PC上で動作するHMIランタイムの実装
• PLCタグマッピング
• アラーム、イベント、履歴、ログ
• ユーザー権限、言語切替、監査的な操作記録
• OS、ライセンス、ランタイムバージョン管理
• バックアップ／リストア
• 停電復旧、PLCオフライン時の挙動
• FAT/SATの試験観点
• 調達仕様、RFP、責任分界

本記事で扱わない範囲

• 画面の一般的UI/UX論
• 抽象的なDX論
• HMIを安全機能として扱う設計

特に重要なのは、HMIは安全機能そのものではないという点です。安全関連の停止、インターロック、SIL/PLに関わる機能は、安全PLCや安全回路側で成立していなければなりません。HMIはその状態表示や操作インタフェースになり得ても、安全機能の成立条件ではありません。

また、ISA-101はHMIの設計・実装・管理に関するライフサイクルの参照枠組みであり、製品認証ではありません。ISA-101

同様に、IEC 62443-2-1はアセットオーナー側のセキュリティプログラムを扱う文書であり、特定製品に対する「認証保証」を意味するものではありません。IEC 62443-2-1

HMIランタイムの3方式を比較する

HMIの実装方式は、運用責任と障害点の置き方で考えるべきです。ここでは、製造現場で多い3方式を整理します。

1. 一体型パネルPC／パネルHMI

タッチパネルとランタイムが現場端末に一体化した構成です。

向く場面

• 単体装置で閉じた制御
• 装置ごとに独立運用したい
• ネットワーク分離を明確にしたい
• ベンダー標準が一体型で統一されている

利点

• 構成が分かりやすい
• 装置単位で責任範囲を切りやすい
• ネットワークやサーバ依存を抑えやすい

注意点

• 端末ごとにバックアップやバージョン管理が必要
• 画面数やデータ保持要件が増えると構成管理が煩雑になる
• 機種更新時の置換性はモデル依存になりやすい

2. 産業用PCローカル実行

装置やラインの近くに設置した産業用PCでHMIランタイムを実行し、現場モニタやタッチディスプレイを接続する方式です。

向く場面

• 複数PLCや周辺機器を横断して監視したい
• 画面、ログ、レシピ、帳票などが比較的多い
• Windows系ランタイムや拡張性を活かしたい
• 保守部品やストレージ運用を標準化したい

利点

• 画面、ログ、接続先を統合しやすい
• バックアップ、ディスク交換、イメージ展開の設計がしやすい
• 将来の機能追加に対応しやすい

注意点

• OS保守、ライセンス、パッチ判断が必要
• ハード構成と現場環境適合の見極めが必要
• 立上げ時の責任分界を明確にしないと、PLC側不具合とHMI側不具合の切り分けが難しくなる

3. 薄型クライアント／中央サーバ

現場側は薄型端末やブラウザ系クライアントとし、HMIランタイムや可視化基盤をサーバ側へ寄せる方式です。たとえばワークステーション／クライアント実装や集中配信の考え方は、製品ごとに構成が異なります。Ignition Perspective Workstation

向く場面

• 複数ラインを共通基盤で管理したい
• 中央バックアップや権限管理を統一したい
• IT/OT連携や複数拠点展開を想定する

利点

• 集中管理しやすい
• 端末交換時の復旧が比較的簡単
• 多端末展開に向く

注意点

• ネットワークやサーバ可用性への依存が増える
• OTとITの責任分界が難しくなりやすい
• ローカル運転継続要件を事前に定義しないと、サーバ停止時の現場運用が曖昧になる

どれが最適かは、設備責任の置き方で決まる

「産業用PCが常に上位」ということはありません。調達判断では、次の問いに答えられる方式を選ぶべきです。

• ライン停止時に誰が現場復旧するのか
• PLC単独で自律運転できるのか
• ネットワーク断時も操作継続が必要か
• 将来改造は装置単位か工場横断か
• バックアップ主体は設備部門かIT部門か

現場調査で先に確かめること

実装方式を決める前に、現地調査で拾うべき情報があります。机上で見落とされやすいのは、性能よりも接続実態と保守動線です。

現地調査で最低限確認すべき項目

制御構成

• PLCメーカー、CPU型式、ファームウェア
• 通信プロトコル
• 既存タグ数、将来追加余地
• 既存アラーム定義の所在（PLC側、HMI側、紙仕様のみ、など）
• レシピや品種設定の保持場所

HMI運用

• 操作端末の設置位置
• 現場で必要な言語
• 権限レベルと承認フロー
• シフトごとのアラーム確認手順
• 日報やCSV出力の有無

インフラ

• 電源品質、瞬停の有無
• UPS要否
• ネットワークトポロジ、VLAN、管理主体
• リモート保守の接続可否
• 現場温度、粉塵、振動、盤内熱だまり

保守体制

• タイ工場現地で一次対応する部門
• 本社ITが関与する範囲
• ベンダーのオンサイト対応範囲
• 交換部品の保管方針
• ソフト改修時の承認者

タイ工場で特に見落とされやすい論点

• 英語、日本語、タイ語の三言語でアラーム文が一致しているか
• 夜勤担当者がOSログインやサービス再起動まで実施する想定なのか
• 停電後に自動復帰させるのか、確認画面で止めるのか
• 現地保全がバックアップ復元を自力でできるようにするのか
• 工場ネットワーク管理者がOT端末をPC資産として管理するのか

産業用PC移行の要件表

仕様を言語化する際は、ベンダーへの依頼文を曖昧な文章ではなく、要求項目・理由・検証方法・責任者で表にするのが有効です。

要求事項テーブルの例

仕様書で避けたい曖昧表現

• 「最新OSを使用」
• 「適切なセキュリティ対策を実施」
• 「必要十分なバックアップ」
• 「高速な表示」
• 「将来拡張に対応」

これらは受注時は便利でも、FAT/SATや保守時に解釈争いを生みます。代わりに、何を誰がどう確認するかまで書き切る必要があります。

PLCタグ・アラーム・ログの実装

産業用PCベースのHMIで最もトラブルが出やすいのは、画面そのものより、タグ意味のズレとアラーム運用の曖昧さです。

PLCタグ設計で決めるべきこと

タグの責任元

まず、「この値の意味を誰が定義するか」を明確にします。

• PLC側が一次定義を持つタグ
• HMI側で派生表示するタグ
• 計算値・文字列変換・単位変換をHMI側で持つタグ
• 設備共通マスタから来るタグ

ここが曖昧だと、PLC変更時にHMIだけ古い意味で残る事故が起きます。

命名とマッピング

タグマッピング表には最低限、以下を持たせます。

malformed/stale tagへの対応

実運用では、単純な通信断以外に、形式不正や古い値の保持が問題になります。

1. malformed tag

• 型不一致
• 想定外のNULL相当
• 文字列長超過
• 破損した日付形式

2. stale tag

• PLC停止後も最後の値だけ表示され続ける
• 通信再接続前の値が新鮮に見えてしまう
• 更新時刻が見えず、オペレータが現況と誤認する

そのため、RFPには次を入れるべきです。

• 通信品質ビットの表示方法
• 最終更新時刻の扱い
• 値が古い場合の表示ルール
• 異常時に書込みを禁止する条件
• PLCオフライン時の画面挙動

PLCオフライン時の実装要件

PLCがオフラインでも、HMIアプリ自体は落ちずに次を示せる設計が望まれます。

• 通信断であること
• 最終正常更新時刻
• 書込み不可状態
• ACK禁止または制限
• ローカルログは継続するのか停止するのか

「PLCが見えない＝HMIがフリーズ」は避けるべきです。ランタイムの一般的な考え方や可視化構成は、ベンダー資料でもタグと表示のライフサイクルとして整理されています。Siemens Engineering Guideline Siemens WinCC Unified Visualizing Processes

アラーム設計で決めるべきこと

本稿では画面デザインではなく、実装・運用としてのアラームを扱います。

アラームの定義元

• PLC内で条件判定しHMIへ状態通知
• HMI側で閾値判定
• 上位サーバで集約判定

どれでもよいのではなく、どこが真実の判定主体かを決める必要があります。設備停止に関わる重要アラームは、通常はPLC側判定のほうが責任が明確です。一方、表示用補助アラームや保全分析用イベントはHMI側でも成立し得ます。

ACKの責任

アラーム確認には少なくとも次を定義します。

• 誰がACKできるか
• ACKは端末ローカルか全端末共通か
• 原因未解消でもACK可能か
• 復帰後自動消去か履歴保持か
• どの操作ログを残すか

権限と監査性

• オペレータは閲覧のみ
• 班長はACK可能
• エンジニアは抑止・無効化可能
• 管理者のみ設定変更可能

このようなロール分離を、画面上の見え方ではなく操作権限と記録で定義します。

産業用PCとOSの選定

産業用PC化で重要なのは、「高性能PCを選ぶこと」ではなく、現場条件と復旧方式に合うことです。

ハード選定の考え方

盤内・盤外条件

• 取付位置
• 盤内通風
• 熱源との距離
• フィルタメンテの可否
• 配線引き回し
• 振動源との近接

ストレージ

• SSD採用有無
• イメージバックアップ方式
• 交換手順
• 予備品との互換性

SSDは一般に産業用途でよく使われますが、発熱や連続書込み、盤内熱環境の影響確認が必要です。したがって、仕様上はSSDを採用するか否かだけでなく、熱だまり状態での動作確認方法まで入れるべきです。

UPS

UPSの要否は、単に停電対策ではなく、次の切り分けで考えます。

• 瞬停時にOS破損を避けたい
• ログを正常クローズしたい
• 制御自体はPLCが継続し、HMIだけ保護したい
• 安全停止シーケンスとの関係を整理したい

つまり、UPSは「付ける／付けない」の議論ではなく、電源喪失時に何を守るかで決めます。

OS選定で決めるべきこと

• OSエディション
• ローカル管理者権限の保有者
• 自動ログイン可否
• 自動起動対象
• 時刻同期方式
• USB利用制限
• イベントログの扱い
• パッチ適用判断者

OS更新は「常に最新にすれば安全」ではありません。OT環境では、変更管理のもとで評価し、適用可否を決めるのが前提です。アセットオーナーのセキュリティ管理プログラムという考え方はIEC 62443-2-1に沿った整理が有効です。IEC 62443-2-1

モデル固有事項の扱い

メーカー型式の記載が必要な場合は、モデル固有であることを明記します。

例として、ファンレス産業用PCの仕様や搭載条件は機種ごとに異なります。たとえばBeckhoff C6525-0060の情報は当該モデル固有です。Beckhoff C6525-0060

ここから言えるのは、「ファンレスならどの現場でも問題ない」ではなく、候補モデルごとに環境適合性を確認すべきということです。

環境・熱・電源の確認項目

RFPと試験には次を明記しておくと実務的です。

• 盤内温度測定位置
• 負荷時のCPU/ストレージ温度確認方法
• UPS切替時のランタイム挙動
• 長時間連続運転後の画面応答確認
• 電源喪失から復電までの復旧シーケンス確認
• SSD交換後のリストア手順確認

セキュリティとライフサイクル管理

HMIのセキュリティは、製品単体の「認証有無」だけで決まりません。現場で重要なのは、誰が変更できるか、いつ更新するか、どう戻せるかです。

セキュリティを運用で定義する

IEC 62443-2-1はアセットオーナー側のセキュリティプログラムを扱います。IEC 62443-2-1

また、CISAのICS向け推奨実践でも、資産把握、ネットワーク分離、変更管理、バックアップ、復旧準備といった運用面が重視されています。CISA ICS Recommended Practices

HMI/産業用PCで定義すべき運用事項

アカウント管理

• 共用アカウントの扱い
• 管理者パスワードの保管者
• ベンダー保守用アカウントの有効期限
• 退職・異動時の権限停止手順

変更管理

• OSパッチ適用の申請者
• ランタイム更新の検証環境
• 緊急修正の承認者
• ロールバック手順

バックアップ

• システムイメージ
• HMIプロジェクトファイル
• レシピ／設定ファイル
• ライセンス情報
• ログ／履歴データ

これらは同じバックアップではありません。復旧目的ごとに分けるのが実務的です。

無計画な更新を避ける

現場でよくある失敗は、保全担当やIT担当が善意で更新し、結果としてランタイムやドライバ整合性を崩すことです。

そのため仕様には、任意更新禁止ではなく、変更管理に従った更新のみ許可と書くべきです。

ライフサイクル管理

• OSサポート終了時の移行方針
• ランタイムバージョン固定期間
• ライセンス再発行条件
• 交換機のイメージ適用手順
• 後継機種への置換手順

ライフサイクルは設備納入時に終わりません。HMIの産業用PC化では、ハード更新・OS更新・ランタイム更新・PLC変更が別々のタイミングで来るため、誰がどのトリガで改修判断するかを決めておく必要があります。

既設HMIからの移行計画

一体型パネルから産業用PCへ移行する場合、単純な画面移植では終わりません。移行計画は、接続・機能・保守・運転継続の4層で考えます。

段階的な移行ステップ

1. 現行資産の棚卸し

• 現行画面一覧
• 使用タグ一覧
• アラーム一覧
• レシピ・設定項目
• ユーザー権限
• 言語資産
• バックアップ方法

2. 非互換の洗い出し

• 通信ドライバ差異
• タグ型差異
• アラーム履歴仕様差異
• フォントや多言語表示差異
• レシピファイル形式差異
• ライセンス体系差異

3. 並行検証

• PLC接続のみ先行確認
• 主要アラームのみ先行確認
• 停電復旧のみ先行確認
• ログ保存先のみ先行確認

4. 切替方式の決定

• 一括切替
• 装置単位切替
• ライン停止期間中切替
• 旧HMI併設期間を設ける切替

移行で失敗しやすい点

既存タグをそのまま持ってくる

旧HMIでは意味が通っていたタグが、PCベースで集約すると衝突したり重複したりします。移行時は、タグ辞書を一度正規化したほうが後工程で有利です。

アラーム文だけ翻訳して終わる

多言語対応では、表示文言だけでなく、操作権限説明、復旧メッセージ、エラーコード文脈まで確認が必要です。

バックアップ試験を最後に回す

最も重要なのに後回しにされやすいのが、壊れたときに戻せるかです。移行計画では、機能確認より前に復旧方針を固めるべきです。

関連するソフトウェア実装の考え方

HMIだけを単体で見るのではなく、PLC連携・PC実装・データ処理・保守性を含めた設備ソフト全体として考えると整理しやすくなります。関連論点は機械ソフトウェア開発の記事も参考になります。

発注者とベンダーの責任分界

調達で最も重要なのは、ベンダー選定そのものより、責任分界の書き方です。ここが曖昧だと、立上げ時に「PLCの問題」「HMIの問題」「ネットワークの問題」と押し合いになります。

推奨する責任分界の形

HMIベンダー

• HMIランタイム構築
• 画面実装
• タグマッピング
• アラーム・履歴設定
• ユーザー権限実装
• バックアップ／リストア手順書
• FAT実施資料作成

PLCベンダーまたは制御担当

• PLC変数定義
• アラーム判定ロジック
• 書込み許可条件
• 通信接続確認
• PLC停止時の安全成立

設備オーナー

• 権限体系承認
• 言語文言承認
• 保持ログ要件決定
• パッチ適用方針決定
• SAT立会いと受入判断

IT/OTインフラ担当

• IP設計
• ドメイン参加可否
• 時刻同期
• リモート接続方針
• サーバ／ストレージ保守

責任分界で明文化すべき論点

• PLCオフライン時のHMI表示責任
• ネットワーク断時の範囲
• OS障害時の一次切り分け担当
• ライセンス紛失時の再構成責任
• 翻訳ミスの承認責任
• FATで見つかった不具合の改修窓口

ドキュメント納入物

受入条件には、少なくとも次を入れるべきです。

• システム構成図
• タグマッピング表
• アラーム一覧
• ユーザーロール一覧
• バックアップ手順書
• リストア手順書
• バージョン一覧
• ライセンス保管情報
• FAT記録
• SAT記録
• ソース／プロジェクト納入条件

RFPに記載する項目

以下は、調達担当がそのまま使えるようにしたRFP項目例です。必要に応じて表形式で配布できます。

1. プロジェクト概要

• 対象設備名
• 新設／更新／移設
• 稼働条件
• 切替停止可能期間
• 使用言語

2. 提案対象範囲

• HMIランタイム
• 産業用PCまたはパネル
• 通信設定
• 画面実装
• アラーム／ログ
• ユーザー管理
• FAT/SAT
• 教育
• 保守

3. 提案必須記載事項

• 実行アーキテクチャ
• ハード構成
• OS構成
• ランタイム製品名／バージョン
• ライセンス形態
• PLC接続方式
• バックアップ方式
• 復旧方式
• ネットワーク前提
• 責任分界

4. 機能要求

• 画面数と分類
• タグ点数の見積方法
• アラーム定義方法
• 履歴保存方法
• CSV/PDF等出力要否
• 多言語切替
• ユーザー権限
• PLCオフライン時挙動
• 電源断復旧
• malformed/stale tag表示ルール

5. セキュリティ・運用要求

• アカウント方式
• ローカル管理者権限
• USB使用方針
• パッチ適用フロー
• 変更管理
• 監査ログ要否
• バックアップ頻度と手順責任

6. 納入成果物

• 構成図
• I/O・タグ表
• アラーム表
• 画面一覧
• 権限定義
• バージョン表
• バックアップ／リストア手順
• FAT/SAT手順書・記録
• 教育資料

7. ベンダー回答フォーマット

比較しやすくするため、自由記述ではなく以下を統一します。

FAT・SATの受入試験表

FAT/SATは、画面が出ることを見るだけでは不十分です。測定可能な方法で、運転・異常・復旧・権限・保守を確認する必要があります。

FATで確認すべき観点

FATは工場出荷前に、ベンダー環境または仮設環境で実施します。可能ならPLC実機、難しければシミュレータや強制値で再現します。

SATで確認すべき観点

SATは現地据付後に、実配線・実ネットワーク・実運用権限で確認します。FATでは見えない、時刻同期、UPS切替、言語表示、現場動線も対象です。

FAT/SAT試験マトリクス例

受入判定の書き方

固定の数値基準を本文で決め打ちする必要はありません。代わりに、各試験の受入条件は以下のように書けます。

• RFP記載仕様と一致すること
• タグ表、アラーム表、権限定義と矛盾しないこと
• 異常時表示がユーザー合意済みルールに従うこと
• バックアップ／リストア手順で再現性があること
• 現地環境で継続運転に支障がないこと

費用の内訳と変更管理

産業用PC化では、初期見積だけを見ても適否は判断できません。費用は、導入費より変更費と保守費で差が出やすいからです。

コスト構成の見方

金額は案件ごとに異なるため、ここでは項目のみ整理します。

初期導入コスト

• 産業用PC本体
• モニタ／タッチディスプレイ
• HMIランタイムライセンス
• 通信ドライバやオプション
• 設計・実装工数
• FAT/SAT工数
• 現地立上げ工数

保守関連コスト

• 予備機
• ライセンス再発行対応
• バックアップ媒体／保管
• オンサイト保守契約
• 改造時の再試験
• OS更新評価
• 翻訳更新

将来変更コスト

• PLCタグ追加
• 画面追加
• 権限ロール変更
• ログ保持方式変更
• サーバ統合
• 後継PCへの載せ替え

変更管理の実務

変更管理は大企業だけの仕組みではありません。少なくとも次を運用表にしておくと、現場が安定します。

見積比較で確認すべき質問

• プロジェクトファイルは納入対象か
• ライセンス移設条件は何か
• 交換機への復元手順は誰が実施するか
• SAT後の軽微変更は何回まで含むか
• タグ追加時の単価体系はどうか

HMI画面開発のよくある質問

Q1. 一体型パネルから産業用PCへ移行すると、必ず保守しやすくなりますか？

必ずではありません。PC化でバックアップや拡張性は整理しやすくなりますが、OS・ライセンス・更新管理が増えます。現場保全がどこまで担当するか、IT/OTがどう関与するかまで決めて初めて保守性が上がります。

Q2. HMI側で安全停止ボタンや安全解除状態を持たせても問題ないですか？

表示や入力インタフェースとして扱うことはあっても、安全機能の成立主体はHMIに置くべきではありません。安全PLCや安全回路側で独立に成立していることが前提です。HMIは安全機能ではありません。

Q3. OSパッチは止めずに定期自動更新したほうが安全ですか？

OTでは一律にそうは言えません。変更管理のもとで、影響評価、テスト、実施手順、ロールバックを定義したうえで適用判断すべきです。IEC 62443-2-1 CISA ICS Recommended Practices

Q4. FATでは何をどこまで見れば、SATが楽になりますか？

最低限、タグマッピング、アラーム発報とACK、権限、バックアップ／リストア、停電復旧、PLCオフライン時挙動までFATで潰すべきです。SATだけで確認しようとすると、現地停止時間を使って基本不具合を探すことになります。

Q5. タイ語・英語・日本語対応では、翻訳表だけ納品してもらえば十分ですか？

十分ではありません。アラーム文だけでなく、ボタン文言、確認ダイアログ、単位、日付書式、文字欠け、折返し、検索性、操作ログ上の表示までQA対象に含めるべきです。言語切替試験はFATだけでなくSATでも実施したほうが安全です。

まとめ

HMIの産業用PC移行で本当に重要なのは、画面の見栄えではなく、アーキテクチャ、PLCタグの意味管理、アラーム運用、OS/ライセンス、バックアップ／リストア、変更管理、責任分界、そしてFAT/SATの検証性です。一体型パネル、産業用PC、薄型クライアント／中央サーバにはそれぞれ適した場面があり、どれかが常に正解ではありません。調達と製造技術の立場では、方式比較そのものよりも、「障害時に誰が何をどう復旧するか」を仕様に落とし込めるかが成否を分けます。特にタイ工場では、多言語、現地保全体制、停電復旧、ネットワーク責任、ベンダーとの境界条件を先に固めることで、立上げ後の属人化を減らしやすくなります。

設備更新や新規導入で、HMI/産業用PCのRFP作成、ベンダー選定、責任分界整理、FAT/SAT観点の具体化まで一緒に進めたい場合は、要件のたたき台段階からご相談ください。現場条件に合わせて、実装方式の比較整理からお手伝いします。お問い合わせ

参照した一次資料

• ISA-101 Standards
• Siemens WinCC Unified Engineering Guideline
• Siemens WinCC Unified Visualizing Processes
• Ignition Perspective Workstation
• Beckhoff C6525-0060
• IEC 62443-2-1
• CISA ICS Recommended Practices