機械設計 #44：コンフィギュレーション・ベースライン — 実際に機械で動いているバックアップはどれか

プロジェクトフォルダーに FINAL、FINAL_v2、FINAL_v2_OK、FINAL_v2_OK_new、backup_before_fix が並んでいることがあります。実機はサイトで直接編集された別版を動かし、HMI、ロボット、画像処理のバックアップ日も違うかもしれません。コントローラーが故障した時、保全チームは多くのファイルを持っていても、どれが known-goodベースライン か分かりません。

これは単なる命名問題ではありません。

コンフィギュレーション・ベースラインとは、識別・管理された構成アイテムを、特定のゲートで得た証拠と結び付けた集合です。自動機のベースラインは、次の問いに答えられなければなりません。

どの構成が承認済みか、実際に何が動いているか、どのバックアップを復元できるか、その後に何が変わったか。

本稿は、自動機のための実用的な構成管理フレームワークを示します。すべてのプラットフォームに一つのツールが合うわけではありません。アップロード、ダウンロード、比較、復元は、権限、ベンダー手順、変更プロセス、対象システムの妥当性確認に従って行います。

1. source、backup、baseline、as-runningを分ける

Source

編集可能な資料やプロジェクトです。PLC、HMI、ロボット、画像処理ジョブ、図面・CAD、レシピマスターなどが含まれます。Sourceは未コンパイル、未展開、未試験かもしれません。

Backup

データと構成を保全・復旧するためのコピーです。エンジニアリングPC、実行中デバイスからの取得、資産管理システム、ディスクイメージ、エクスポートパッケージなどから作られます。存在するだけでは、完全、読込可能、復元可能とは証明できません。

Release

レビューと承認を通り、展開または引渡しできる版です。

Baseline

設計リリース、FAT試験済み、出荷時、SAT受入れ済み、保全中など、特定のゲートで固定したアイテムと版の集合です。ZIPファイルだけではなく、識別、関係、証拠、状態を含みます。

As-running

ある時点で装置上に実際に存在する構成です。オンライン編集、サイト調整、レシピ変更、HMIだけのダウンロード、ロボットのマスタリング、ファームウェア更新、部品交換でReleaseと異なることがあります。構成管理の目的は、同一だと仮定せず、これらの関係を明示することです。

2. 「機械のバックアップ」と言う前にアイテムを定義する

自動機は一つのPLCファイルではありません。

制御

PLCプロジェクト、コンパイル・実行データ、対応可能ならシンボルとコメント、HMIアプリ、安全構成、リモートI/Oとデバイスパラメーターを含めます。

モーションとロボット

サーボ・ドライブパラメーター、モーションプロファイル、ロボットプログラム、フレーム、ツール、ユーザー座標、マスタリング、校正データを含めます。

画像処理と品質

画像処理ジョブ・モデル、校正、しきい値、基準画像、試験データセットを含めます。

生産データ

レシピ、製品マスター、交換部品の対応、限界値、受入れパラメーターを含めます。

インフラ

産業用PCのイメージとサービス、インターフェースとミドルウェア、範囲内のネットワーク・デバイス構成、ファームウェア・ソフトウェア版、ライセンス依存を含めます。

エンジニアリング情報

図面、回路図、BOM、I/Oとインターフェース一覧、アラーム一覧、マニュアル、権限に応じたリスク・妥当性確認・FAT/SAT記録を含めます。

同じリポジトリに置けないアイテムもあります。各タイプのsystem of recordと、ベースラインへ結び付ける方法を計画で定義します。

3. ベースラインには目的が必要

すべての状況に「最良」の一つのベースラインはありません。

Design-release baseline

製造・プログラミング用にリリースした情報です。最終稼働版とは限りません。

FAT-tested baseline

FATの証拠を生み出した版です。後の変更には影響評価と再試験の判断が必要です。

As-shipped baseline

出荷前に閉じた構成で、FAT試験済み版と承認済み変更から追跡できます。

SAT-accepted baseline

据付、サイト調整、インターフェース、承認済み偏差を反映した受入れ後の構成です。

As-maintained baseline

所有者が承認済み現地変更後に維持するknown-good状態です。最新ファイルが未試験で、古い版がknown-goodということもあります。NewestとBaselineは別概念です。

4. 各アイテムに識別情報を与える

重要なアイテムには、アイテムID、資産・システムID、種類、所有者、版、使用ツールと互換性、依存、system of record、アクセス分類、ベースライン所属、変更・リリース参照を持たせます。

アイテム	版の識別	記録する依存
PLC	リリースとネイティブID	エンジニアリングツール・ファームウェア
HMI	リリース・ビルド	実行版とリンクタグ
ロボット	プログラム集合・校正状態	コントローラー・ツール・フレーム
画像処理	ジョブ・モデル・校正	カメラ・ファームウェア・レンズ・設定
レシピ	データセット版	機械・ソフトウェア互換性

ファイル名は属性の一つにすぎません。識別を命名者だけに依存しないでください。

5. 「何が動いているか」を証明する

「その版をダウンロードしたはず」という記憶に頼りません。プラットフォームに応じて、オンライン比較、保護ベースラインとのアップロード比較、ネイティブのチェックサム・署名、実行版・ビルド情報、展開ログ、コントローラーID、時刻とユーザーの変更記録を証拠にします。

一致するチェックサムも、正しい対象を覆っている場合にだけ有効です。オンラインパラメーター、外部レシピ、校正、保持データ、サービス、ファームウェア、デバイス状態まで一つのチェックサムが証明すると仮定しません。どの証拠がどのアイテムを証明するかを計画へ書きます。

6. Sourceだけでなく展開を記録する

Source管理は、誰が何を変えたか、どの版・ブランチ・リリースかを答えます。しかし、どの資産へいつダウンロードしたか、成功したか、どのパラメーターを適用したか、後に何を試験したかは自動では残りません。

展開記録には、資産ID、ベースライン・リリースID、アイテム版、変更承認、実施者、時刻、ツールと対象状態、結果、検証・再試験参照、偏差を含めます。共有範囲の広い記録へ認証情報や鍵を直接保存しません。

7. 一つのプロジェクトファイルでは復旧に足りない

復旧には、Source、実行・エクスポートパッケージ、デバイス・ファームウェア互換性、ライブラリとパッケージ版、HMI・ロボット・画像処理成果物、ドライブ値、レシピとマスター、校正・マスタリング、ライセンス手順、PCイメージとOS依存、復元手順が必要になることがあります。

コントローラーからの取得にはコメント、シンボル、Source構造、外部依存がない場合があります。逆に、ノートPCのSourceには実行中の最新調整がないかもしれません。取得元、対象、対象外、必要ツール・版、各依存の所在を記録します。

8. バックアップ、比較、保護ベースライン

「毎月ファイルをコピーする」より強い流れは次の通りです。

保護された承認済みベースラインを決める。
スケジュールまたはイベントで資産からバックアップを取得する。
ベースラインと比較する。
差分を警告・レポートする。
承認済み、期待値、未承認、未知へ分類する。
変更記録へ照合する。
承認と試験が完了した変更だけベースラインへ反映する。

資産管理ツールは自動バックアップ、比較、版アーカイブ、監査追跡を支援できますが、能力は資産、エンジニアリングソフト、ライセンスに依存します。ツールは構成所有者の代わりになりません。差分が出た時の担当と期限を決めます。

9. Known-goodはNewestではない

レビュー・リリース済み、正しい範囲へ展開済み、影響に応じて試験・妥当性確認済み、既知の偏差が記録済み、再現可能なバックアップと復元ルートがある時に、版をknown-goodと呼びます。

Newestは作業中、未回帰試験のHotfix、説明のない変更を含む取得版、コンパイルだけで未展開のSourceかもしれません。障害時にNewestを戻すと、停止原因を再現する場合があります。

10. 復元リハーサルはファイルを開くだけではない

ファイルを読めるか、ツール・版・依存が揃うか、対象ハードウェアとファームウェアが合うか、管理された対象・シミュレーター・予備へ復元できるかを確認します。起動とインターフェース、レシピと校正、必要な妥当性確認、実際の復旧時間も確認します。

本番コントローラーで試しません。適切な隔離・管理対象とロールバック手順を用意します。リハーサルしていないバックアップには、未知のリスクが残ります。

11. 緊急変更でベースラインは壊れやすい

停止中にエンジニアがオンライン編集することがあります。合理的な変更でも照合が必要です。暫定イベントを記録し、as-runningを取得し、ベースラインと比較し、残す変更を決め、Sourceを更新し、影響に応じてレビュー・試験し、新しいベースラインを発行し、再度バックアップと比較を行います。

実行版だけを変更して放置すると、次の古いプロジェクトのダウンロードでHotfixが消えます。取得版を「new」と改名するだけでは、Sourceの履歴と理由が失われます。

12. Status accountingで変更の位置を知る

現在のベースライン、提案・承認・実装された変更、展開済み資産、完了試験、未更新文書、未解決偏差を表で管理します。

変更	Source更新	リリース	展開	試験	Baseline更新
EC-xxx	Yes/No	Yes/No	資産一覧	証拠	Yes/No

小さな状態表は何百通ものメールより有効です。「コードは変わったが図面、試験、マニュアルは古い」という状態を防ぎます。

13. 紙のベースラインと実機を監査する

アイテム一覧が完全か、リポジトリと記録が一致するか、as-runningが承認ベースラインと一致するか、未知の変更に担当者がいるか、最新バックアップが成功したか、比較警告を処理したか、復元リハーサルが有効か、ツール・ライセンスを維持できるか、アクセス・保存期間が適切か、変更から証拠へ追跡できるかを監査します。

監査は人のミス探しだけではありません。プロセスや記録が実機のアーキテクチャを反映しなくなったことを見つけます。

14. 引渡しは復旧能力を移管する

USBを渡すだけでは不十分です。SAT後の所有者、system of record、承認・展開権限、バックアップ予定と成功確認、比較対象、保存期間、適切なオフサイト・オフラインコピー、復元ツールと依存の維持、ベンダー遠隔支援の変更記録方法を決めます。

同じノートPCや同じサイトだけに置いたバックアップは、生産設備と同じ事故で失われます。重要な独立故障をリスクとして考えます。

15. サイバーセキュリティと構成の完全性

構成には、ネットワーク情報、アカウント、証明書・鍵、安全設定、レシピ、工程知識、顧客データが含まれる場合があります。公開ファイル名へパスワードを入れない、管理されない経路で送らない、全員に上書き権限を与えない、共有アカウントを使わない、便利だから保護を切らないことが重要です。

構成成果物、秘密・認証情報、アクセス方針、監査・変更記録を分離します。復旧可能でありながら、機密性、完全性、アクセス制御を守ります。

16. 安全構成には独立したルートが必要

安全構成の変更は、安全機能、アーキテクチャ、診断カバレッジ、タイミング、妥当性確認へ影響します。通常の生産パラメーターとして扱いません。

承認変更、権限者、安全影響、関連計算・解析、妥当性確認・再確認、as-running証拠へ追跡できる記録を残します。保護された安全データや保護回避の手順を公開しません。

17. 構成管理の失敗モード

実行版より古いバックアップ、複数の「マスター」、PLCだけがベースラインでHMI・ロボット・画像処理が別、レシピ・校正がバックアップ外、現行ツールで開けないプロジェクト、ライブラリ・ライセンス不足、Sourceやコメントを失う取得、古いプロジェクトでHotfixを消す、緊急編集の未照合、未試験のNewest、監視されないバックアップ失敗、本番と同時に失うバックアップ、技術的に復元できても再コミッショニングしていない状態が典型です。

該当する場合はFMEA、原因分析、事業継続計画へ組み込みます。

18. 自動機ベースラインチェックリスト

[ ] すべての構成アイテムを識別した。
[ ] 各アイテムに所有者、ID、system of record、アクセス分類がある。
[ ] 各ベースラインの目的とゲートが明確である。
[ ] FAT試験済み、出荷時、SAT受入れ済み、保全中を追跡できる。
[ ] as-runningの証拠がある。
[ ] 展開記録がリリースと資産を結んでいる。
[ ] Source、実行版、レシピ、校正、依存をバックアップしている。
[ ] ツール、ファームウェア、ライブラリ、ライセンス互換性を記録した。
[ ] 保護ベースラインと比較ワークフローがある。
[ ] 未知差分に担当とトリアージルートがある。
[ ] 最新だからではなく試験・証拠でknown-goodを示せる。
[ ] 管理環境で復元をリハーサルした。
[ ] 緊急変更の照合ルートがある。
[ ] 状態表で資産、試験、文書への到達を追跡できる。
[ ] 認証情報と鍵を分離・保護している。
[ ] 安全変更に承認と個別の再妥当性確認がある。

まとめ

コンフィギュレーション・ベースラインは「final backup」というフォルダーではありません。構成アイテム、承認版、資産への展開、実際に動く構成、バックアップと比較の証拠、復元証拠、変更・状態・監査記録を管理された関係として結ぶものです。

このリンクが揃っていれば、コントローラーが故障しても保全チームは正しいファイルを推測しません。どの機械に合うか、どのゲートで試験したか、どう制御して復旧するかが分かるknown-goodベースラインを持てます。

公開参考資料

ISO 10007:2017 — Guidelines for configuration management: https://www.iso.org/standard/70400.html
ISO — Configuration management and information security: https://www.iso.org/information-security/configuration-management
Rockwell Automation — FactoryTalk AssetCentre: https://www.rockwellautomation.com/en-us/products/software/factorytalk/maintenancesuite/assetcentre.html
Rockwell Automation — Disaster Recovery capability: https://www.rockwellautomation.com/en-pl/docs/factorytalk-assetcentre/16-00-00/ftacmainen-ditamap/welcome-to-factorytalk-assetcentre/ftac-disaster-recov-capability.html
Beckhoff — TwinCAT 3 Source Control: https://download.beckhoff.com/download/document/automation/twincat3/tc3_sourcecontrol_en.pdf

MINATAの技術記事をすべて見る