離散イベントシミュレーション ＋ 強化学習
AI
4分
システムシミュレーションの手法は、主に離散事象シミュレーション（DES）、マルチエージェントシミュレーション（ABM）、システムダイナミクス（SD）の3つに分類されます。今回は、このうちDESについて解説します。
DES（離散事象シミュレーション）とは？
DES（Discrete Event Simulation：離散事象シミュレーション）とは、システムの挙動や性能をシミュレートする手法です。時間の経過に伴う個々の不連続なイベントのシーケンスとして、システムの動作をモデル化します。各イベントは特定の時点で発生し、システムの状態変化をもたらします。
この手法では、システムの維持や状態定義を行うイベントのスケジュール設定と実行が行われます。シミュレーションはこれらのイベントを一つずつ処理することで進行し、システムの変動性を再現するためにランダムな要素が含まれる場合もあります。また、離散事象シミュレーションにおける重要な概念として「クロック」があります。これは環境内のタイマーとして現在時刻を記録するもので、イベントのトリガー時刻に達すると該当のイベントが発生します。
「イベント」とは、システムの状態を変化させるあらゆる出来事を指します。「離散（ディスクリート）」という言葉は、これらのイベントが発生する特定の瞬間のみに焦点を当て、それ以外の時間は考慮しないことを意味します。こうしたイベントの例としては、顧客の到着と退出、リソースの割り当てと解放、さらには業務に影響を与える地震のような突発的な災害などが挙げられます。
リソースが限られている場合、離散事象シミュレーションにおいて頻繁に発生するシナリオが、リソースの「割り当て待ち」です。例えば、患者が診察のために受付エリアで待機する状況や、サービスカウンターで商品を購入するために列に並ぶ状況などがこれに該当します。
UNSの構築方法
1. データモデリングフレームワークとMQTTトピックの定義
MQTTトピック形式の定義には、ISA95 Part 2やSparkplug Bといったスキーマが広く採用されています。前者は企業レベルのデータ統合に、後者はデバイスレベルのデータ統合に用いられます。このプロセスにおいては、方法論と事前の調査が極めて重要です。
2. データ処理とコンテキスト化
例えば、ゲートウェイ経由で熱電対を接続する場合、ゲートウェイ自体が定義したペイロード（例：整数値「00355」）が送信されます。この値「00355」は「35.5℃」に対応しています。これを利用可能なデータにするには、ツールを使用して「00355」を「35.5」に変換し、JSONペイロードを再構成した上でMQTTブローカーにパブリッシュ（送信）する必要があります。この一連の処理は、通常IIoTプラットフォームやNode-REDなどのソフトウェアが担います。
3. 接続の確立（サブスクライブ ＆ パブリッシュ）
MQTTブローカーでトピック（例：Site1/Unit1/ThermoCouple1）を定義し、前ステップの熱電対データをNode-REDからこのトピックにパブリッシュします。この熱電対のリアルタイムデータを必要とするシステムは、このトピックをサブスクライブ（受信）するだけでデータを取得できます。
これら3つのステップを完了することで、最もシンプルなUNSが構築されます。この手法により、各種ソフトウェア層の間でリアルタイムなデータ交換が可能になります。
シナリオ設定
病院におけるシナリオを想定します。各診療科には患者の行列があり、診察時間や緊急度はそれぞれ異なります。ここでの目的は、緊急性の高いケースに優先的に対応しつつ、全体の待ち時間を最小限に抑えることです。このコンテキストにおいて、DES（離散イベントシミュレーション）を用いたシミュレーションを行うことで、RL（強化学習）エージェントは、リスクのない仮想環境下で、患者フローの管理、診察順序の最適化、効果的な優先順位付けなど、さまざまな戦略を試行できます。
DESによる病院のキューモデル
患者の到着： 緊急度、診断科、推定診察時間などの主要な属性を付与して患者の到着をシミュレートします。
キュー管理： 診療科ごとに個別のキュー（待機列）を設けます。従来のキュー管理は、先着順（FIFO）または固定された優先順位ルールに基づいて行われます。
診察・処置： 診療科のスタッフが患者を治療するプロセスをシミュレートします。
RL（強化学習）の統合
状態（State）： 各キューの患者数、現在診察中の患者、待機中の患者の緊急度などを含むシステムの状態を定義します。
行動（Actions）： 各意思決定プロセス（例：ある患者の診察が終了し、次に診察する患者を選択する必要がある時点）において、任意のキューから次に診察する患者を選択する行動を指します。
報酬（Reward）： 長時間の待ち時間（特に緊急性の高い症例）に対してペナルティを課し、緊急性の低い症例の待ち時間が短い場合には報酬を与える設計にします。
導入ステップ
DESを用いた環境シミュレーション： DESを使用して患者のフローとサービスの仕組みをモデル化します。DESは、患者の到着、待機、診察の動的な流れを処理します。
意思決定へのRLの適用： RLエージェントを使用して、キューから患者を選択するための最適な選択プロセスを学習させます。エージェントはキューの状態を観察し、その行動（患者の選択）の結果に基づいて報酬を受け取ります。
トレーニング： RLエージェントは、個々の相互作用（各患者の診察完了と次の患者の選択）から継続的に学習します。時間をかけて、キュー管理を改善するための最適なパターンと戦略を特定します。
統合： RLによる意思決定プロセスをDESに統合し、意思決定のタイミングごとに、RLエージェントが次に診察する患者を選択できるようにします。
固定されたルールとは異なり、RLエージェントは、患者の突発的な増加や診断科の対応状況の変化など、流動的な状況に適応できます。RLは、緊急症例の適切なケアを最大化しつつ、待ち時間を最小化するという複数の目的を両立させます。システムは、より多くのデータが収集されるにつれて改善し続け、患者の新たな到着パターンや病院運営の変化にも適応していくことが可能です。
実験計画
Pythonで病院の待ち行列問題などの離散イベントシステム（DES）をシミュレーションするには、SimPyライブラリが有効です。SimPyは、プロセス指向の離散イベントシミュレーションにおけるPythonの標準的なフレームワークです。
