WES — アプリケーション検証¶

倉庫実行管理システム

概要¶

WES はオーダー駆動型の高複雑度アプリケーションで、最も幅広いプラットフォーム機能を使用します。倉庫環境において AMR フリート、MHE（マテリアルハンドリング機器）、PDA を管理し、受信オーダーをピック/移動/配置タスクシーケンスに分解し、デバイスに割り当て、動的な倉庫フロア全体での実行をオーケストレーションします。

WES はプラットフォームの主要なストレステストです：複雑なマルチステップ実行コントラクト、高頻度の再プランニング、マルチデバイス連携、ポリシー駆動型の障害回復。Syrius Robotics が構築したファーストパーティアプリケーションとして、WES はサードパーティ開発者が利用できる同じ API を使用します——特権アクセスはありません。

利用するプラットフォームサービス¶

サービス	プレーン	用途
DeviceAdmin	データ	AMR、MHE、PDA の登録、アラートおよび OTA ステータスの監視
ThingIO	データ	フリートダッシュボード、オーダースループット分析、ゾーン利用率ウィジェット
OTAForge	データ	ポリシー駆動のファームウェアおよびマップ配信（倉庫ロボット向け）
DotID / StarGate	アイデンティティ	ロボット、オペレーター、および上流システム（OMS/WMS）を認証します
Equator	空間	倉庫マップ、ゾーン、ラック位置、充電ステーション、ランドマーク
Marie	空間	近接クエリ、経路空き確認、ゾーンベースのリソース検索
Planner	インテリジェンス	オーダーをフリート全体のピック/移動/配置タスクシーケンスに分解します
Scheduler	インテリジェンス	リソースの可用性と近接性に基づく一回限りのタスク割り当て
Execution Manager	インテリジェンス	コントラクトを通じてマルチステップタスクの実行をオーケストレーションおよびモニタリングします
Policy Service	ガバナンス	障害回復戦略、プランニング優先事項、スケジューリング優先度
AI Policy Agent	ガバナンス	オペレーターは WES ドメインスキーマを使用して会話形式で倉庫ルールを定義します

使用するプレーン¶

プレーン	WES での利用方法
Data Plane	デバイス登録（DeviceAdmin）、フリートダッシュボード（ThingIO）、ファームウェア更新（OTAForge）
Identity Plane	ロボット、オペレーター、および上流の WMS/OMS 統合の認証
Spatial Plane	倉庫フロアマップ、ラック位置、ゾーンベースのクエリ、経路空き確認
Intelligence Plane	オーダーフルフィルメントのための完全なプランニング → スケジューリング → 実行パイプライン
Governance Plane	ポリシー駆動型のプランニング、障害回復、およびオペレーター定義のルール
Ecosystem Plane	Marketplace に公開され、インストール時にドメインポリシースキーマを登録します

検証シナリオ¶

1. Complex Execution Contracts¶

WES は意思決定ポイントを持つマルチステップコントラクトを生成します：

Contract: Pick Order #4521
├── Step 1: Navigate to Rack B-12 (map excerpt included)
├── Step 2: Pick item SKU-7890 from shelf 3
├── Step 3: Navigate to Packing Station 2
├── Step 4: Place item on conveyor
├── Failure policy: Retry once, then reassign to nearest AMR
└── Constraints: Battery > 20%, complete within 15 min

この検証内容：

Execution Contract モデルはマルチステップ、マルチ意思決定ポイントのペイロードを処理します
コントラクトはオフライン実行に対して十分に自己完結しています（空間データ、制約、および障害ポリシーがプッシュ時に含まれます）

2. Edge-Cloud Reconciliation Under Load¶

繁忙な倉庫には50台以上の AMR があり、一部は RF デッドゾーンで接続を失います：

接続されている AMR はオーダーの変更に応じて再プランニングされます
オフラインの AMR はコントラクトされたタスクを予測状態として保持します
再接続時に、実際の状態（位置、タスク進捗）が整合されます

この検証内容：

Edge-Cloud Reconciliation パターンは高いデバイス密度と頻繁な接続変化の下で機能します
部分的なフリートの再プランニングは予測タスクを正しくロックし、二重割り当てを回避します

3. Policy-Driven Failure Recovery¶

AMR がピックシーケンス中に通路のブロックに遭遇します：

Execution Manager がコントラクトの失敗を検出します
Policy Service に問い合わせます——WES のアプリ定義ポリシーは「1回リトライし、その後再割り当て」と規定しています
リトライ失敗（通路は依然としてブロック中）
タスクが最も近い利用可能な AMR に再割り当てされます
Planner が残りのシーケンスを再プランニングします

この検証内容：

Policy Architecture パターンはアプリケーション定義の障害回復をサポートします
回復戦略は組み合わせ可能（リトライ → 再割り当て → エスカレーション）で、アプリケーションごとに設定可能です

4. Domain Policy Schema and AI Policy Agent¶

倉庫オペレーターが AI Policy Agent に伝えます：

「緊急オーダーを標準オーダーより優先し、1台の AMR に3タスクを超えて割り当てないこと」

エージェントは WES ドメインポリシースキーマを使用して order.priority、AMR、および task-count 制約を理解し、Planner と Scheduler が遵守する正式なポリシーを作成します。

この検証内容：

ドメインポリシースキーマにより AI Policy Agent がアプリケーション間で再利用可能になります
オペレーターはコードを書かずにアプリケーションの動作をカスタマイズできます
会話的に作成されたポリシーは有効化前に検証されます

5. One-Time Scheduling¶

WES は一回限りのオーダー駆動型スケジューリングを使用します：

オーダーが到着 → Planner が分解 → Scheduler が利用可能な AMR にタスクを割り当て
定期スケジュールなし——各オーダーは個別のスケジューリングイベントです

この検証内容：

Scheduler の一回限りスケジューリングモードは動的で予測不可能なワークロードを処理します
スケジューリング決定はポリシー制約（デバイスの可用性、バッテリー閾値、ゾーン制限）を尊重します

明らかになったアーキテクチャの洞察¶

洞察	プラットフォーム設計への影響
実行コントラクトモデルが必要	マルチステップタスクはオフライン実行のために自己完結型のコントラクトを必要とします
エッジ/クラウド間の整合が必要	高いデバイス密度と断続的な接続性は正式な状態整合を必要とします
ポリシー駆動型の回復、ハードコードではない	異なる障害タイプには異なる戦略が必要で、デプロイメントごとにカスタマイズ可能です
アプリケーション定義ポリシーとプラットフォーム実行	開発者はドメイン固有のポリシーを定義し、プラットフォームはそれらを均一に適用します
2階層プランニングの妥当性	戦略的（クラウド）プランニングと戦術的（エッジ）プランニングは根本的に異なる問題を解決します