PLCプログラム開発を外注する仕様・見積・FAT/SAT

PLCプログラム開発を外注するとき、発注書を「I/Oは何点、HMIは何画面、PLCは何台」だけで作ると、同じに見える見積の中身が揃いません。ある会社は正常運転だけを想定し、別の会社は異常復旧、既設設備の調査、通信試験、バックアップ、現地立上げまで含めているかもしれないからです。安価な見積が本当に効率的なのか、必要作業が抜けているだけなのかを判断できなくなります。

発注側が買うべきものは、納入日に一度動くプログラムではなく、意図した制御を試験でき、変更履歴を追え、障害後に復元でき、別の有資格者が保守を引き継げる「制御資産」です。本記事では、I/O、状態遷移、インターロック、安全境界、異常・復旧、運転モード、権限、ログ、HMI、通信から、FAT/SAT、as-built成果物、保証・保守・変更管理までを、RFPと受入条件へ変換します。

執筆直前の公式一次情報確認では、PLC外注仕様を直接変更する発表は直近48時間以内に見つかりませんでした。参照する規格・ガイダンスの版と日付は本文で明示します。費用と効果の数値は市場相場ではなく、すべてTOMAS TECHの説明用仮定です。

PLCプログラム開発の外注で最初に定義する成果

「動く」を観察可能な受入条件へ分解する

「自動運転できること」は要求として粗すぎます。何を開始条件とし、どの状態を通り、どの入力で停止し、原因除去後にどこから復帰し、再起動後にどの状態を保持するのかが不明です。受注者は空欄を仮定で埋めるしかなく、FATで初めて発注者との解釈差が表面化します。

要求は、入力、現在状態、条件、出力、次状態、異常時の挙動、記録する証拠へ分けます。たとえば「ワークが所定位置にあり、ガード条件と上流許可信号が成立したときだけクランプを開始する。規定条件に達しなければ次工程へ進まず、アラームを保持する。原因を除去して権限者がリセットした後は安全な待機状態から再開する」という書き方なら試験できます。

成果物を四つの層で考える

外注範囲は、次の四層を一つの成果として扱うと抜けを発見しやすくなります。

I/O点数と画面枚数は実装規模の一部を示しますが、振る舞いの複雑さ、既設解析、試験量、復旧条件、引渡し品質を示しません。したがって画面枚数やI/O点数だけで価格を比較しないことが基本です。

発注前の制御仕様1｜I/Oと状態遷移を同じ言葉で結ぶ

I/Oリストには電気情報と制御上の意味を併記する

I/Oリストはアドレス帳ではありません。信号名、型、正常状態、フェイル状態、電気仕様、発生元、スケール、単位、フィルタ、更新条件、シミュレーション可否、アラームとの関係まで含めます。NC/NOの表記だけでは、断線時に安全側へなるか、PLC論理で反転するか、HMIでどの状態を正常表示するかが分かりません。

アナログ値では、生値の範囲、工学値への変換、範囲外、断線、品質不良時の扱いを決めます。通信タグでは、値だけでなく接続状態、データ更新確認、タイムアウト、古い値を区別する方法が必要です。出力には、通常制御、手動操作、強制、保守時の許可条件を明記します。

状態遷移表はシーケンスの契約書になる

フローチャートだけでは、並行動作、待機、タイムアウト、再入、電源断後の扱いが曖昧になりがちです。設備単位または機能単位で状態を定義し、各状態について入口条件、継続動作、出口条件、タイムアウト、禁止遷移、記録イベントを記載します。

状態名そのものより、現場、生産技術、電気設計者、プログラマー、試験担当が同じ事例を同じ遷移として説明できることが重要です。状態遷移表はHMI表示、アラーム、ログ、FATケースの共通索引になります。

発注前の制御仕様2｜インターロック、安全境界、異常・復旧

インターロックを「条件一覧」で終わらせない

各インターロックには、保護対象、成立条件、監視する状態、検出時の出力動作、保持の有無、解除条件、リセット権限、表示、記録、バイパス可否を割り当てます。「安全確認OK」のような集約信号だけでは、どの条件が不成立か、復旧時に何を確認すべきかが不明です。可能な範囲で原因信号を診断できる設計にします。

プロセス保護、設備保護、品質保護、機械安全を同じ表の同じ重みで扱わないことも大切です。製品不足による停止と、人への危険を低減する安全機能では、設計、検証、変更承認の責任が異なります。

安全PLCと安全機能は独立した専門境界

安全PLCや非常停止、ガード、ライトカーテン、安全速度、安全停止などの安全機能は、一般PLCプログラムの便利な追加機能として扱えません。リスクアセスメント、要求安全機能、適用する法規・規格、アーキテクチャ、検証、妥当性確認、改造後の再評価が必要です。対象設備と設置国に適用される法規、規格、顧客基準に従い、資格と権限を持つ専門家が担当してください。

通常制御側のFATに合格したことは、機械安全や機能安全の適合を証明しません。RFPでは、安全関連範囲の責任者、提供資料、試験境界、第三者または社内承認の必要性、通常PLC/HMIとの信号境界を明示します。本記事は一般的な発注設計を説明するもので、安全認証や法的判断を代替しません。

異常・復旧仕様は停止後の誤動作を防ぐ

異常一覧にはコードとメッセージだけでなく、検出条件、遅延、優先度、停止範囲、保持、初動、原因除去、復旧前確認、再開点、関連ログを記載します。通信断、センサー不一致、アクチュエータ未到達、材料不足、品質条件逸脱、上位システム停止、電源断を含めます。

復旧は「リセットで再開」では不十分です。途中ワークが残る、出力と実機位置が一致しない、上位システムは完了と認識した、製品IDが未確定といった状態をどう整合させるか決めます。自動復旧、作業者確認、保全権限、排出・再処理、廃棄のどれを選ぶかをケース別に規定します。

発注前の制御仕様3｜モード、権限、ログ、HMI画面開発

モードは名称より操作可能範囲で定義する

自動、手動、段取り、保守、調整、シミュレーションなどのモードごとに、操作可能な出力、速度、インターロック、遷移条件、同時操作、リモート操作可否、ログを決めます。手動モードが全出力を無条件に動かせる設計では、立上げは早くても運用リスクが残ります。

物理キースイッチ、HMIログイン、上位承認の関係も整理します。誰がレシピ値を変更できるか、誰がアラームをリセットできるか、誰が保守画面や強制機能へ入れるかを役割で定義し、個人識別が必要な操作を共有パスワードへ逃がさないようにします。

HMI画面開発は枚数ではなく運転判断で評価する

HMI画面開発を「トップ、手動、アラーム、設定の計4画面」と数えても、良い操作設計かは分かりません。各画面で利用者が判断すること、必要な状態、操作前提、確認、拒否理由、関連画面への導線を定義します。

重要な設計観点は次の通りです。

• 運転状態、停止理由、次に必要な操作を同じ文脈で示す。
• 色だけに依存せず、状態と操作可否を一貫して表現する。
• アラームは原因候補、影響、初動、復旧条件へつなぐ。
• 設定値は単位、範囲、現在値、変更前後、権限を示す。
• 重要操作は対象と結果を確認し、連打や重複要求を安全に扱う。
• 通信不良や古い値を正常値のように見せない。
• 言語切替で意味、単位、文字切れ、検索性を損なわない。

画面レビューは静止画の美観だけでなく、正常運転、異常、復旧、権限不足、通信断のシナリオで実施します。納入物にはHMIの編集可能なプロジェクト、使用フォント・画像・ライブラリ、アラーム・テキスト台帳、多言語辞書を含めます。

ログは「後から説明できるか」で選ぶ

最低限、運転状態遷移、アラーム発生・解除・確認、モード変更、重要設定変更、レシピ版、手動操作、権限操作、通信状態、PLC/HMI起動、時刻変更、プログラム変更またはダウンロードを検討します。すべてを高頻度で保存するのではなく、調査に必要な粒度、時計、保存先、容量、保持、エクスポートを決めます。

工程データを上位へつなぐMES導入の考え方とPLCログの役割は異なります。PLC/HMIは設備の即時状態と制御文脈を持ち、MESは製造指図、ロット、実績などの業務文脈を持ちます。どちらを原本とし、障害時にどこで再送・照合するかをインターフェース仕様にします。

通信・ネットワーク・リモート保守を見積範囲に入れる

通信仕様はタグ対応表だけでは足りない

相手機器、プロトコル、接続主体、更新方式、データ型、バイト順、スケール、ハンドシェイク、タイムアウト、再試行、重複、順序、起動時、切断時、復旧時を定義します。生産完了のような一回性イベントは、単純なビット通知では取りこぼしや二重計上が起きやすいため、シーケンス番号、応答、再送、冪等性を設計します。

ネットワーク構成図には、機器、ポート、セグメント、アドレス、管理境界、時刻同期、上位接続、リモート接続を記載します。IPアドレス一覧だけでなく、誰が変更を承認し、交換時にどの設定を復元し、監視で何を確認するかが必要です。

OTの制約を踏まえてセキュリティを設計する

NIST SP 800-82 Rev.3は2023年9月の最終版で、OTセキュリティでは性能、信頼性、安全の要件を考慮する必要があると説明しています。したがって、IT向けの一般策を影響評価なしに設備へ当てるのではなく、資産、通信経路、権限、変更、監視、バックアップ、対応手順を設備の制約とともに設計します。NIST文書名を提案書に書くこと自体は安全の保証ではありません。

NISTは2026年6月24日に、水道・下水システム向けの安全なリモートアクセス参照設計としてSP 1800-45最終版を発表しました。多要素認証、分離、監視などを考える参考になりますが、水道分野向けの参照設計であり、すべての工場に対する法的要件ではありません。自社のリスクと適用要件で設計してください。

リモート保守を許可する場合、常時接続を前提にせず、申請、時間限定の有効化、個人認証、最小権限、接続先制限、操作記録、監視、緊急遮断、終了確認を定めます。ベンダーの共通アカウントや未管理PCからの直接接続を契約上の既定にしないことが重要です。

バックアップ・復元・開発環境を「引渡し可能」にする

CPUから吸い上げただけでは完全復元できない場合がある

「PLC内にプログラムがあるからバックアップできる」という理解は危険です。メーカー、機種、設定、保護、使用機能によっては、CPUからアップロードまたは逆変換した内容だけでは、完全なエンジニアリングプロジェクト、コメント、シンボル、ハードウェア構成、ライブラリ、HMI、ネットワーク設定を再現できない場合があります。

Siemensの2024年7月のPLC Basic Program Function Manualは、完全な復元にはプロジェクトの保存が必要で、CPUからのdecompileだけでは不十分になり得るメーカー固有の例を示します。これは全メーカー・全機種に一律に当てはまる断定ではありません。しかし発注側が「CPUから吸い上げればよい」と仮定せず、対象製品の公式手順で復元試験を求める理由になります。

開発環境の版とライセンスも成果物

引渡し台帳には、エンジニアリングソフトウェア名、正確なバージョン、更新レベル、必要オプション、ライブラリ版、デバイス記述、ドライバー、OS条件、ライセンス形態、所有者、再インストール手順を含めます。将来のPC交換時にインストーラーや権利がなく、ソースを開けない状態を避けるためです。

STEP 7の公式ページは、構成、プログラミング、試験、診断、再利用などを提供する一つのメーカー例です。ここから学ぶべきことは特定製品の採用ではなく、実行コード以外にも、構成、試験、診断、再利用資産が開発環境に依存するという点です。別メーカーでも対象ツール固有の依存関係を確認します。

バックアップは復元試験と一対にする

NIST NCCoEの製造分野ページには、2026年6月17日掲載のOT Backup Quick Start Guide（NIST SP 1339）が案内され、OTバックアップ戦略の考慮事項を扱っています。またCISA等の2025年1月13日のSecure by Demandガイドは、購入時に構成・エンジニアリングロジックの変更追跡や、認証されたバックアップ・復元について供給者へ問う観点を提示しています。

バックアップ仕様には、対象、正本、頻度、世代、保管場所、暗号化、アクセス、整合性確認、オフラインまたは分離コピー、復元責任者を含めます。復元試験では、予備PLCや検証環境へ戻し、ハードウェア構成、プログラム、保持値、HMI、通信、アラーム、権限、ログが所定状態になるかを確認します。「ファイルが開けた」だけでは復元完了ではありません。

PLCソフト開発外注の見積を公平に比較する

共通の前提表を全候補へ渡す

PLCソフト開発外注の見積差は、技術力だけでなく前提差から生まれます。既設ソースがあるか、コメントは読めるか、回路図はas-builtか、実機停止時間を確保できるか、模擬盤を用意するか、現地言語対応、夜間作業、旅費、予備品、教育、保証を誰が負担するかを統一します。

見積依頼には、最低限次の区分を設けます。

工数を左右する「見えない複雑さ」を質問する

同じ100点のI/Oでも、独立した単純搬送と、複数装置が並行し、品種切替、トラッキング、再投入、上位通信、複雑な復旧を持つ工程では設計・試験量が違います。同じ10画面でも、表示だけか、レシピ、監査、多言語、権限、トレンドを含むかで変わります。

候補会社には、見積工数をI/O数だけでなく、状態数、遷移数、インターロック、異常復旧ケース、外部インターフェース、品種・レシピ、権限役割、試験ケース、既設不確実性へ分解して説明してもらいます。単価だけでなく、成果物、除外、発注者側作業、変更時の価格決定方法を比較します。

電気・制御の外注範囲を組み立てる考え方は、タイ製造業の生産技術アウトソーシングも参考になります。本記事では特に、制御ソフトの受入と復元可能性へ範囲を絞っています。

電気設計外注とPLC開発の境界をなくす

回路図、部品表、端子、I/Oを一つの変更単位にする

電気設計外注とPLC開発を別契約にするときも、境界責任を切り離してはいけません。センサー追加は回路図、部品表、端子台、ケーブル、I/Oアドレス、PLCロジック、HMI、アラーム、試験へ波及します。どの成果物を誰が更新し、最終整合を誰が承認するかを変更フローにします。

部品表には、型式、仕様、数量、代替条件、供給者、設置位置、ファームウェアまたは設定依存を必要に応じて含めます。ネットワーク機器、通信モジュール、ライセンスドングル、メモリーカードなど、復元に必要だが盤内の主回路部品表から漏れやすいものも確認します。

as-builtは「赤入れを後で清書」ではなく受入対象

現地変更を紙や個人PCに残すと、PLCソース、盤図、I/O、HMI、ネットワーク構成が不一致になります。変更のたびに暫定版を管理し、SAT完了時に全成果物の版を一致させます。最終as-builtの提出を支払条件に結び、発注側がファイルを開き、検索し、代表I/Oから回路・ロジック・画面・試験記録へたどれることを確認します。

IEC 61131-3を品質ラベルではなく共通言語として使う

IEC 61131-3:2025は2025年5月22日に公開され、ST、LD、FBDとSFCの考え方を含むPLCプログラミング言語の規格です。発注仕様で言語や構造の共通語として参照できますが、「IEC 61131-3準拠」と書くだけで可読性、モジュール性、試験性、安全性、復元性が保証されるわけではありません。

コーディング要件には、命名規則、コメント言語、シンボル、モジュール境界、入出力副作用、状態管理、アラームID、定数・レシピ、再利用ブロック、例外処理、未使用コード、強制・バイパス、変更履歴を定めます。特定言語に偏らず、対象PLC、保守担当の能力、工程特性に適した表現を選びます。

レビューでは、ソースの見た目より、要求IDからコードと試験へ追跡できるかを見ます。あるインターロック要求がどのブロックで実装され、どのFATケースで正常・不成立・復旧を確認したかを追える状態が望まれます。

FAT/SATをデモではなく受入証拠にする

FATは正常系より境界・故障・復旧を重視する

FATは画面を操作して一連の自動運転を見せる会ではありません。承認済み要求に対し、前提、試験手順、入力、期待結果、実績、証拠、差異、判定、署名を残します。実機がない信号は模擬方法を定義し、模擬で未確認の部分をSATへ明示的に持ち越します。

安全機能の検証は、通常制御FATと責任・手順を分け、適用要件に基づく専門家の計画へ従います。通常のインターロック試験票に安全項目を一行追加しただけで安全妥当性確認を完了扱いにしてはいけません。

SATは現場固有の不確実性を閉じる

SATでは実際の電源、盤、配線、センサー、アクチュエータ、ネットワーク、上位システム、製品、作業者で確認します。FATで模擬した信号、現地施工、設備間タイミング、性能、長時間運転、電源・通信復旧、バックアップからの戻し方を対象にします。

合否条件は「問題なく動く」ではなく、測定または観察可能にします。未解決事項には、影響、暫定対策、責任者、期限、再試験ケース、出荷・量産可否を付けます。未解決を口頭合意にせず、最終支払と保証開始の条件を契約で定めます。

引渡し成果物チェックリスト

編集可能な制御資産

• PLCの完全なエンジニアリングプロジェクトと照合用チェックサムまたは版情報。
• HMIの編集可能なプロジェクト、画像、フォント、辞書、アラーム台帳。
• コメント、シンボル、変数、データ型、ライブラリと依存関係。
• ハードウェア構成、通信設定、機器パラメータ、必要ファームウェア。
• 承認済みのコンパイル・ダウンロード手順と対象機器対応表。
• 開発ツールの版、更新レベル、オプション、ライセンス、インストーラー情報。

as-built設計文書

• I/Oリスト、状態遷移、インターロック、異常・復旧一覧。
• 電気回路図、盤配置、端子・ケーブル、部品表。
• ネットワーク構成、アドレス、ポート、通信対応表、時刻同期。
• HMI画面一覧、操作権限、設定・レシピ、ログ仕様。
• 安全境界と別途管理される安全文書への参照。
• FAT/SAT仕様、結果、差異、是正、再試験、最終承認。

運用・復元・教育

• 通常運転、段取り、異常対応、復旧、バックアップ、復元手順。
• アカウント・権限、リモートアクセス、変更申請、緊急変更の手順。
• 予備品と交換時の設定復元、校正または再確認の条件。
• 発注側担当者が実施した復元演習と教育記録。
• 保証、保守窓口、応答条件、現地対応、除外、エスカレーション。

工程パラメータや制御イベントを長期証跡へ連携する場合は、加工条件記録システムのRFP・FAT/SAT設計も参照してください。PLC引渡しはソースの保全、上位の記録システムはイベントと製造履歴の保全という役割を持ち、版と識別子を接続します。

保証・保守・変更管理を契約時に決める

不具合と仕様変更の境界を例で合意する

保証条項に「プログラム不具合を無償修正」とだけ書いても、要求の解釈差、既設機器の故障、発注後の条件変更、第三者変更を分類できません。承認済み仕様と試験結果から外れる再現可能な事象を不具合とするのか、入力条件追加や運用変更を仕様変更とするのか、例を用意します。

対応時間も、受付、一次回答、リモート診断開始、暫定復旧、現地到着、恒久対策を分けます。24時間対応の文言だけでなく、対象時間帯、言語、連絡経路、必要な発注側アクセス、部品・旅費、停止許可を決めます。

変更ごとにソース・文書・バックアップ・試験を同期する

変更要求には目的、対象、リスク、影響するI/O・状態・HMI・通信・安全境界、実施版、ロールバック、試験、承認を記録します。オンライン変更や緊急変更を許すなら、後日正式版へ反映し、CPU上の版、保管ソース、as-built、バックアップを一致させる期限を決めます。

CISA等のSecure by Demandが購入者に提起する、構成・エンジニアリングロジック変更の追跡や認証済みバックアップ・復元という観点は、保守契約の質問票にも使えます。ただしガイド名を挙げるだけでは実装されません。誰が変更を検知・承認し、どの証拠を残し、どの頻度で復元を試すかを契約へ落とします。

TOMAS TECH説明用の費用・効果モデル

以下は外注価格の相場でも効果保証でもありません。仕様と引渡しを整えることで、停止・変更対応の作業と長時間復旧損失の一部が減るという説明用仮定です。自社の停止履歴、限界利益、保守体制で全入力を置き換えてください。

基準ケース

• 初期開発見積: 1,850,000 THB
• 年間保守: 240,000 THB
• 現状の停止・変更対応: 月6回 × 4人 × 3.5時間 × 220 THB/時間 × 12 = 221,760 THB/年
• 現状の長時間復旧: 年8回 × 9時間 × 32,000 THB/時間 = 2,304,000 THB/年
• 改善率仮定: 停止・変更対応工数40%減、長時間復旧損失30%減

停止・変更対応の効果:

221,760 × 40% = 88,704 THB/年

長時間復旧損失の効果:

2,304,000 × 30% = 691,200 THB/年

粗効果:

88,704 + 691,200 = 779,904 THB/年

純効果:

779,904 - 240,000 = 539,904 THB/年

単純回収:

1,850,000 ÷ 539,904 = 3.4265... ≈ 3.43年

感度分析

このモデルは、運転停止損失の改善仮定が結果を支配することを示します。停止・変更対応の221,760 THBは人の対応工数、2,304,000 THBは出力停止による損失という別項目ですが、自社計算では同じ費用を両方へ入れて二重計上しないでください。改善率は、仕様書が存在するだけで達成できる値ではなく、復元演習、予備品、保守契約、教育、現場運用を含む実績から測ります。

BOI Announcement 15/2565の非公式英訳には、機械と統合されたsoftware、program、ITへの支出の扱いが記載されていますが、古い資料の現行適用を本記事から断定できません。BOIのeligible activitiesページは2025年10月28日更新と表示され、2026年のprivate machinery/equipment investment indexも投資環境の背景にはなります。しかし、どちらも個別プロジェクトの優遇適用やROIの証明ではありません。申請時点の条件をBOIへ個別確認してください。

発注前・契約前・受入前の実務チェック

発注前

• 対象設備、既設変更、停止可能時間、発注者側の責任を確認した。
• I/O、状態遷移、インターロック、異常・復旧を相互参照できる。
• 安全関連の責任、適用要件、専門家、通常制御との境界が決まった。
• モード、権限、ログ、HMI、通信、ネットワークを要求に含めた。
• 開発環境、ライセンス、バックアップ、復元を成果物にした。

契約前

• 全候補へ同じ前提、模擬範囲、FAT/SAT条件を渡した。
• 画面数・I/O点数以外の複雑さと除外を比較した。
• ソース、コメント、シンボル、部品表、図面、as-builtの形式を定めた。
• 変更価格、保証範囲、保守応答、第三者変更の扱いを定めた。
• 支払節目を設計承認、FAT、SAT、最終引渡しへ結び付けた。

受入前

• 正常、境界、異常、復旧、通信断、再起動、権限を試験した。
• CPUからの吸い上げではなく、承認プロジェクトから復元を実演した。
• PLC、HMI、回路図、I/O、ネットワーク、部品表の版が一致した。
• 未解決事項に影響、暫定対策、責任者、期限、再試験がある。
• 発注側担当者がバックアップを探し、開き、復元手順を説明できる。

FAQ｜PLCソフト開発外注・電気設計・HMI画面

PLCプログラム開発を外注するとき、最初に渡す資料は何ですか？

設備目的、対象製品、現状図面、I/O、状態遷移、インターロック、安全境界、異常・復旧、モード、HMI、通信、受入条件を渡します。未確定事項は隠さず、誰がいつ決め、見積をどう調整するかを一覧にします。既設改造では現物とas-builtの差を調査範囲に含めます。

PLCソフト開発外注の価格をどう比較すべきですか？

I/O点数やHMI画面枚数だけで比較せず、現状調査、設計、状態・復旧の複雑さ、通信、試験ケース、現地立上げ、編集可能ソース、開発環境、バックアップ復元、as-built、教育、保証を共通区分で比較します。除外と発注者側作業も金額と並べてください。

電気設計外注とPLC開発を別会社にできますか？

可能ですが、変更の最終整合責任が必要です。回路図、部品表、端子、I/O、PLC、HMI、アラーム、試験へ同じ変更IDを通し、最終版を一致させます。境界の空白を発注者が管理できない場合は、統合責任者を置きます。

HMI画面開発では何を受け入れますか？

画面枚数ではなく、利用者が状態、停止理由、次の操作、権限不足、通信不良を誤解なく判断できるかをシナリオで受け入れます。編集可能プロジェクト、画像・フォント、アラーム台帳、多言語辞書、権限表も成果物です。

CPUからプログラムをアップロードすればバックアップになりますか？

必ずしもなりません。対象メーカー・機種・保護・機能によって、コメント、シンボル、ハードウェア構成、ライブラリ、HMIなどが完全には戻らない場合があります。公式手順を確認し、承認済みエンジニアリングプロジェクトを保管して、別環境への復元試験で確認してください。

FATとSATの違いは何ですか？

FATは主に受注者側の環境で、要求に対するロジック、HMI、通信、異常・復旧を実機または模擬で確認します。SATは工場の実配線、設備、ネットワーク、製品、作業者で、現場固有の統合と復旧を確認します。FAT合格がSAT合格を自動的に意味するわけではありません。

安全PLCも通常PLCと同じFATで確認できますか？

通常制御とのインターフェース確認はできますが、安全機能の妥当性確認を代替できません。資格ある専門家が、対象設備と地域に適用される法規、規格、リスクアセスメント、安全要求に従って別途計画・実施する必要があります。

外注先へソースを渡すとき、サイバーセキュリティで何を決めますか？

受渡し経路、暗号化、保管、利用者、再配布、秘密情報、持込PC、リモート接続、作業記録、終了時の削除・返却を決めます。現場アクセスは時間限定、個人認証、最小権限、監視を基本にし、設備の性能・信頼性・安全への影響も評価します。

まとめ｜納入日に動くコードではなく、復元できる制御資産を買う

PLCプログラム開発の外注で発注側が守るべき中心線は、要求、実装、試験、引渡しの一致です。I/Oと状態遷移、インターロック、安全境界、異常・復旧、モード、権限、ログ、HMI、通信を観察可能な条件にし、FAT/SATで正常だけでなく境界・故障・再起動・復元を試します。

そして、編集可能なソース、コメント、シンボル、ハードウェア構成、ライブラリ、HMI、部品表、ネットワーク図、開発環境の版とライセンス、バックアップ、as-built、保証・保守・変更手順まで受け取ります。価格比較では画面枚数やI/O点数に閉じず、受入証拠と将来の復元可能性を同じ表で比較してください。

仕様がまだ完全でなくても、既設調査の範囲、RFPの骨格、FAT/SATケース、引渡し台帳から段階的に整理できます。タイ工場でPLC・HMI開発の外注条件を検討中であれば、構想段階からお問い合わせフォームで相談できます。