Industrial-AIOps Energy

industrial-aiops-energy — エネルギー版（変電所／電力事業者向け）

英語 · 中文

Industrial-AIOps のエネルギー版を独立したリポジトリに分割しました。iaiops.coreを基盤として構築された、変電所／電力事業者の遠隔監視制御プロトコル向けの読み取り専用 OT コネクターを提供します。

• IEC 60870-5-104（c104）— RTU／変電所のテレメトリー
• DNP3 / IEEE 1815（pydnp3）— アウトステーションの監視
• IEC 61850 MMS（pyiec61850、Linux 専用ホイール）— 変電所 IED の読み取り

ベースパッケージの共通ガバナンス（監査／予算／リスク階層／取り消し）、プロトコル横断の分析機能（正規化された ISA-95/18.2 モデルに基づくデータフロー／アラーム／OEE／ダウンタイムの根本原因分析）、および MCP サーバーのインフラストラクチャを再利用します。このリポジトリで追加するのは、3 つのエネルギーコネクターとそのセッションビルダー、および MCP ツールのみです。読み取りを優先し、制御方向への書き込みは公開しません。 現在のリリース：0.2.0（iaiops>=0.29.0,<1.0 が必要。iaiops 0.31.0 でテスト済み）。通信上の構成：80 個のツール、読み取り専用 75 個、破壊的操作 0 個（このサーバーにマウントされたエネルギーコネクターと基本ブレインツール）。0.2.0 での新機能 — このサーバーでのすべての MCP 呼び出しについて、どのフロントエンドとクライアントが実行したかを監査記録に残すようになりました（origin=mcp、クライアントが自己申告した名前、接続ごとに 1 つの ID）。これまでは、このサーバーでの呼び出しは監査証跡に origin unknown として記録されていました。アップグレードに関する注意： iaiops 0.29 では、これらのフィールドが監査チェーンにハッシュ化されます。0.29 が書き込んだ監査証跡を古いバージョンの基本パッケージで検証すると、row_hash mismatch が報告されます。そのため、同じ IAIOPS_HOME を共有するすべてのプロセス（このサーバー、iaiops-mcp、CLI、エンタープライズ版）をまとめてアップグレードしてください。基本パッケージの新しい HTTP ベアラートークン要件はここには適用されません。このサーバーは stdio のみで通信します。CHANGELOG.md を参照してください。0.1.12 での変更 — パッケージが自身のバージョンを報告するようになりました。__version__ は 8 リリースにわたって 0.1.3 にハードコードされており、MCP ハンドシェイクでは SDK のバージョンがこのサーバーのバージョンとして報告されていました。現在は両方ともインストール済みパッケージのメタデータから取得します。0.1.11 での変更 — 3 つすべてのモニターパスが、初めて CI のゲート対象になりました。ライブテストがスキップされると、ビルドが成功するのではなく失敗するようになりました。これまで DNP3 は未対応でした。現在の Linux 環境では pip install pydnp3 が失敗するため、このリポジトリもエコシステム全体の「ホスト型ランナーではビルド不可」という状況を引き継ぎ、tests/test_dnp3_live.py はすべてのビルドでスキップされていました。しかし、ビルド不可ではありません。opendnp3 は問題なくコンパイルでき、2019 年のバインディング層に必要だった機械的な修正 3 件を scripts/build_pydnp3.sh でスクリプト化し、実際の GitHub ランナーで実行するようになりました。また、ガバナンスに関する修正 2 件も iaiops 0.20.3 から引き継いでいます（ピンのバージョンを引き上げました）。失敗した呼び出しが成功として監査記録に残されなくなりました（以前は、失敗のたびにパターン・サーキットブレーカーにも誤った情報を与えていました）。また、暴走防止ガードが、拒否された呼び出しを永遠に再試行する呼び出し元を検知できるようになりました。0.1.10 での変更 — 基本パッケージから引き継いだセキュリティ修正です。このエディションがミラーする 3 つのエグレスツール（stream_publish、stream_publish_event、historian_push）は、認証情報（NATS 認証トークンや TSDB パスワード）を平文で監査ログに書き込んでおり、audit_forward はその行を設定済みの SIEM に送信していました。これらは iaiops で定義されているため、このエディションだけでは修正できませんでした。ピンを iaiops>=0.20.2 に引き上げ、登録されたサーフェス全体に未宣言の認証情報パラメーターが再び含まれた場合にビルドを失敗させるコントラクトテストを追加しました。これらのツールにトークンまたはヒストリアンのパスワードを渡したことがある場合は、ローテーションし、既存の監査行を確認してください。エネルギーコネクター自体は認証情報パラメーターを受け取りません。0.1.9 での変更 — すべてのツールが MCP の ToolAnnotations ヒント（readOnlyHint／destructiveHint／openWorldHint）を提供します。これらは手作業で記述するのではなく、@governed_tool ハーネスから導出されるため、クライアントは [READ]／[WRITE] の docstring タグを解析しなくても、モニター読み取りと動作を実行するツールを判別できます。通信上は（0.1.9 時点で）ツール 59 個、読み取り専用 55 個、破壊的操作 0 個でした。このエディションは制御方向を公開しておらず、今では文書化だけでなくテストでもこれを強制しています。これらはヒントであり、ゲートではありません。MCP 仕様では、セキュリティ上の判断にアノテーションを頼ることは禁止されており、強制は引き続き @governed_tool が担います。ヒントの導出をここで重複実装するのではなく、mcp_server.hints からインポートするため、基本パッケージのピンを iaiops>=0.20.1 に引き上げました。 以前は0.1.8 — 基本の IAIOPS_READ_ONLY ゲートは iaiops 0.19.0 で削除されました（読み取り／書き込みの認可は呼び出し元の判断事項であり、エージェントの判断／アカウント管理によって決まります。タップ側の判断ではありません。すべてのツールは基本の @governed_tool ハーネスを通じて管理・監査されます）。そのため、このエディションでも削除しています。 IAIOPS_NO_EGRESS=1 ゲートは維持しています。これはデータ流出／エアギャップに関する軸で、登録時にデータ送信ツールを list_tools() から除外します。このエディションは独自の FastMCP インスタンスを実行するため、ゲートは独自の main() に組み込まれています。これがないと、IAIOPS_NO_EGRESS=1 を指定しても、基本の脳からミラーされた historian_push、rca_narrate、および stream_publish* の2つが引き続き公開されます。エネルギーコネクター自体は監視専用で、ゲートの影響を受けずそのまま利用できます。CHANGELOG.md を参照してください。

以前は0.1.6 — 3つの読み取り専用コネクターに対する監査強化パスです。DNP3では、オフラインのアウトステーションをオンラインと報告したり、部分的な整合性ポーリングデータベースを返したりしなくなりました。IEC-61850では、上限付きの接続／リクエストタイムアウトを導入し、失敗時に 0.0 や空の成功結果を捏造しなくなりました。変電所アナライザーは、単独のブレーカー開放を「選択遮断」と呼ばなくなりました。テストでは IAIOPS_HOME を分離し、ガバナンスエンドポイントのスコープ修正が適用されるよう、基本パッケージの固定バージョンを iaiops>=0.14 に引き上げました。CHANGELOG.md の§0.1.6を参照してください。（0.1.5ではIEC-104の監視パスを検証しました。Linuxコンテナー内で、実際の c104 クライアント↔サーバー間の往復通信を確認しています。tests/test_iec104_live.py を参照してください。） 物理RTU／IEDは未検証のままです。 0.1.3以降、サーバーは独自のMCP IDを持っています。iaiops-energy-mcp はエネルギー固有の指示（IEC-104／DNP3／IEC-61850、読み取り優先、制御／操作なし）を備えた専用の FastMCP("iaiops-energy") インスタンスを実行し、基本のクロスプロトコル脳ツールをミラーしています。さらに、エディションスキル（skills/iaiops-energy/SKILL.md。登録済みツール群との整合性をテスト済み）とプロトコル整合性契約テストも備えています（すべてのツールにガバナンスマーカー、[READ]形式のリスクタグ、Args: セクション、正規の {error, hint} エラー形式が必須です。登録済みツールにガバナンスマーカーがない場合、サーバーは起動を拒否します）。

🧪 ベータテストと共同開発

このパッケージが最も必要としているのは、稼働中の変電所RTU／IED／IEC-104でのフィールドテストです。 IEC-104、DNP3、IEC-61850の監視パスはライブラリのループバックテストで検証済みで、現在は3つすべてがCIビルドごとに実行されます。スキップするとビルドは成功せず、失敗します。（2026-08-01以降：DNP3の証拠は、以前は2026-07-02の手動実行1回のみでした。これは、ホステッドランナーでは pydnp3 をビルドできないと考えられていたためです。その認識は誤りでした。scripts/build_pydnp3.sh を参照してください。）実機のRTU／IEDは未検証のままです。 認可されたテスト環境で実際の変電所設備に対して iaiops doctor を実行できる場合は、ぜひ結果をお知らせください。検証済みのデバイスはサポートマトリックスに名前を記載します。結果（プロトコル＋デバイスモデル＋iaiops doctor の出力）は、基本リポジトリにピン留めされた課題から報告してください。 👉 industrial-aiops#28 — フィールドテストパートナー募集（v0.10.0）

リポジトリを分ける理由

エネルギー分野は対象となる購入者（電力会社／変電所）が異なり、プラットフォーム固有の依存関係（pyiec61850 はLinux専用のSWIGホイール、pydnp3 はネイティブ拡張をビルドします）が重く、独自のコンプライアンス範囲（中国の電力監視システム安全保護制度）もあります。分割することで、基本パッケージのインストールを軽量に保てます。計画については、基本リポジトリの docs/ENERGY-SPINOUT.md を参照してください。

インストール

pip install iaiops-energy[energy]      # all three energy protocols
pip install iaiops-energy[iec104]      # just IEC-104

iaiops-energy は共有コアである iaiops を自動的にインストールします。

使い方（MCP）

iaiops-energy-mcp                       # brain + energy tools over stdio

~/.iaiops/config.yaml で、接続先を変電所設備に設定してください（protocol: iec104|dnp3|iec61850、host、port、common_address ／ unit_id）。

エッジデプロイとエコシステム（エッジネイティブ／Margo）

ベースパッケージと同様に、energy エディションは、強化され一元管理された エッジホスト 上で、ポータブルでガバナンスに準拠した エッジアプリケーション として動作します。これは Margo のエッジ相互運用性ロール（不変のホスト · 準拠したオーケストレーター · iaiops-energy = OT ドメインアプリ）に対応し、OCI Managed Container としてデプロイできます（変電所の RTU／IED へのアウトバウンド通信のみで、インバウンド通信はありません）。コンテナーと margo.org/v1-alpha1 アプリケーション記述のスケルトンは deploy/margo/ にあります。完全な整合性と率直なギャップ分析は、ベースリポジトリの docs/MARGO-ALIGNMENT.md を参照してください。記述子は、すべての PR で Margo が公開している margo.org/v1-alpha1 LinkML スキーマに照らして検証され、問題なく通過します（CI ジョブ margo-descriptor）。これは構造的な妥当性のみを確認するものです。詳細は deploy/margo/schema/PROVENANCE.md を参照してください。

率直なステータス： 自然な Margo エッジアプリケーションですが、まだ Margo 準拠ではありません。イメージのビルド、ホストされた署名付きパッケージ、および公開された適合性の結果は、ロードマップ上の項目として ⏳ です。その結果が出るまでは準拠を主張しません。また、上記のスキーマ検証の通過は、その実現に向けた一歩ではありません。適合性テストスイートはまだ存在しないため、現時点では実行できません（margo 組織に適合性リポジトリはなく、2026-01-15 時点では最初の PR1 垂直スライスの範囲がまだ検討中でした）。

検証状況（正直な評価）

ベースリポジトリと同じ誠実さの基準です。ドライバーのコーデック／API サーフェスは実際のライブラリに対して検証済みです。モック／モンキーパッチを用いたユニットテストはハードウェアなしで CI で実行されます。プロトコルの昇格方法については、ベースリポジトリの docs/PREVIEW-VERIFICATION.md の手順書を参照してください。

プロトコル	ステータス	CI カバレッジ	エビデンス
DNP3 / IEEE 1815	検証済み（監視パス）	✅ プッシュのたびに実行 ¹	実稼働中の opendnp3 アウトステーション（pydnp3）に対する実際のマスター↔アウトステーション間のラウンドトリップです。is_online() は実際のチャネルの OnStateChange を反映し、integrity_poll()（Class 0/1/2/3）は、種別ごとにグループ化された、初期値を設定したバイナリ／アナログ／カウンターデータベースを返します。tests/test_dnp3_live.py（@pytest.mark.integration）を参照してください。物理 RTU は使用しません。
IEC 60870-5-104	検証済み（監視パス）	✅ プッシュのたびに実行	プロセス内の c104 サーバーに対する実際のクライアント↔サーバー間のラウンドトリップです（tests/test_iec104_live.py + tests/iec104_server_harness.py、@pytest.mark.integration。Linux コンテナーで合格します）。iec104_connection_info は初期値を設定したステーションを検出し、iec104_interrogate（総合問い合わせ／C_IC）は品質情報付きで初期値を設定した M_ME_NC_1 + M_SP_NA_1 ポイントを返し、iec104_read_point は測定値を読み取ります。誤った IOA では 捏造された値を返さず、found=False になります。また、サーバー側の ASDU キャプチャにより、制御 ASDU（C_SC / C_DC / C_SE）が一切発行されないことを確認します。c104 は macOS 用のホイールを提供していないため、テストは macOS ではスキップされます（CI／Linux では実行されます）。物理 RTU は使用しません。監視／読み取り専用です。
IEC 61850（MMS）	検証済み（監視パス）	✅ プッシュのたびに実行	pyiec61850 のサーバー API で構築した、プロセス内の libiec61850 MMS サーバーに対する実際のクライアント↔サーバー間の MMS ラウンドトリップです。iec61850_device_directory は論理デバイスを一覧表示し（論理ノード／データオブジェクトも参照します）、iec61850_read は実際の ISO-on-TCP 経由で初期値を設定した測定値（TotW.mag.f、FC MX）を返します。誤った参照では、捏造された値ではなく MMS データアクセスエラーが発生します。tests/test_iec61850_live.py（@pytest.mark.integration。pyiec61850／そのサーバー API がない場合はスキップ）を参照してください。物理 IED は使用しません。読み取り／監視専用です — 制御／GOOSE／SV は対象外です。

¹ 3 つすべての監視パスが現在 CI のゲート対象です。スキップは成功扱いではなくビルド失敗になります（「実プロトコルのテストはスキップ不可」）。以前は次の説明でした。「CI のゲート対象は IEC-104 のみ。DNP3 と IEC-61850 は CI 外の実行に依存しており、緑色のバッジには依存していない。」 これは当時は事実でしたが、現在は当てはまりません。

最後に対応したのは DNP3 です。ここにある以前の注記も、CI ジョブも、この README も、何か月もの間、同じ誤った結論を繰り返していたため、その理由を記録しておく価値があります。pip install pydnp3 は現在のどの Linux 環境でも失敗するため、ホステッドランナーではビルド不能だと見なされていました。しかし、実際には違います。opendnp3 自体は問題なくコンパイルできます。劣化していたのは 2019 年のバインディング層でした。opendnp3 にパッチを当てることなく、機械的な修正を 3 つ行いました。

1. Python ヘッダーが必要です（python3-dev）。これがないとビルドは Python.h: No such file or directory で失敗し、これが「ビルド不能」に見えていた原因でした。
2. 同梱されている 214 個のヘッダーで #include <python2.7/Python.h> を <Python.h> に書き換えました。
3. 同梱の pybind11 は CPython 3.11（3.11 では不透明になった PyFrameObject の内部を読み取ります）と GCC 13（<cstdint> なしで std::uint16_t を使用します）より古いため、pybind11 v2.13.6 に置き換えました。

scripts/build_pydnp3.sh が 3 つすべての修正を適用し、インポートを検証します。2 コアで初回ビルドに約 3 分かかります。ここから得られる教訓は一般化できます。「エコシステムがビルドできないと言っている」は、引き継ぐべき主張ではなく、検証すべき主張です。

DNP3 に関する注記：読み取り専用／監視方向のみです（制御なし）。DNP3Manager.Shutdown() は長時間稼働するインタープリターでブロックする場合があるため、コネクターは終了処理に上限を設け（_Pydnp3MasterAdapter.shutdown）、テストでは短時間で終了する子プロセス内でラウンドトリップを実行します。

ライセンス

MIT — © wei. ベンダー中立でガバナンスされた Industrial-AIOps ラインの一部です。