レシピ ジェネレータ (RecipeGenerator):
- チョコレートを製造するためのレシピを提供します
製造実行システム (ManufacturingExecutionSystem):
製造実行システム (ManufacturingExecutionSystem):
- チョコレートの最初の状態の最新情報を提供して、以下を含むロットを配信します。
- ロットを処理すべき最初のコントローラ
- 使用すべきレシピの名前
- システムを通過中のチョコレート ロットを監視します
ステーション コントローラ (StationController):
ステーション コントローラ (StationController):
- チョコレート ロットの状態の最新情報を受信します
- すべてのレシピを受信します
- チョコレート ロットの状態の更新情報をフィルタリングし、ステーション コントローラに割り当てられたチョコレート ロットまたは完了状態にあるチョコレート ロットのみを処理します
- レシピに基づいてチョコレートを「処理」します
- チョコレート ロットの状態を更新し、レシピの次のステーション コントローラに割り当てます
- ロットが完了状態にあるという通知をMESシステムが受信すると、ロットの登録が解除され、処理中の特定のロットに対するメモリの消去とその状態情報の削除が可能になります。
その他の重要点
データモデルの考慮事項
DDSでデータをモデリングする際にもっとも重要な考慮事項のひとつは、「データ ストリームに含まれる、ひとつのエレメントまたは現実の世界のオブジェクトを表すものは何か？」です。 ロットの状態をその処理中に更新するシステムでは、ロットはシステムにおいて個別のオブジェクトであることは明らかです。 このサンプルでは、ChocolateFactory.idlファイルのデータタイプをモデリングしています。RTI Connext DDSは、IDL（Interface Definition Language: OMGによって定義されるインタフェース定義言語）を使用して、言語非依存型のデータタイプを定義します。IDLの詳細は、 RTIコアライブラリとユーティリティ入門ガイド で参照できます。
DDSでは、これらの現実の世界に存在する固有のオブジェクトは[2]インスタンス としてモデリングされます。. インスタンスは、//@キーの記号で示される、 キーと呼ばれる固有識別子のセットによって記述されます。 各インスタンスに対して個別の論理キューを保持するミドルウェアなど、システム内に固有のインスタンスを持つことによる メリットは数多く あります。
このサンプルでは、キーフィールドとして、lotIDを使用します。
// ID of the lot whose status is being updated long lotID; //@key
各チョコレートロットは、固有のオブジェクトとして表されるというこの前提においてはひとつの弱点があります。それは、ロットが複数のステーションコントローラに従って動作するということです。 これは選択するオプションがあることを意味します。このデータはロットIDのみに対応付けることができます。これは、異なるステーションからの同じロットの更新情報が同じ論理キューに保管され、キューを適切に設定しないと、更新情報が相互に上書きされる可能性があるということです。 別のオプションとして、このデータをロットIDとステーション コントローラIDの両方に対応付けることができます。２番目のオプションでは、キューのサイズを1に設定し、さらに異なるステーション コントローラから受信する同じロットの更新情報が相互に上書きされないことを確信できます。
// ID of the lot whose status is being updated long lotID; //@key // ID of the Station Controller producing the status StationControllerKind controller; //@key
データモデルの考慮事項 - QoS
このサンプルのデータはすべて、以下の特性を持つ、Occasionally Changing State Data（状況によって変化する状態のデータ）としてモデリングされています。
- このデータは一部のオブジェクトの状態が変化したときのみ更新されます。このケースでは、ロットの状態の変化に従って状態の変化が発生します。
- そのオブジェクトの状態は常に変化しているというわけではありません
- その他のアプリケーションは、起動前にオブジェクトがパブリッシュされたとしても、各オブジェクトの最新の状態を知る必要があります
このデータは常に送信されているわけではないため、信頼性をもって送信される必要があります。Reliability QoS（信頼性QoS）は、レシピ プロファイルのXMLファイルで設定されています。これらの設定は、確実な配信を確保するために、DataWriterとDataReaderの両方で有効化されている必要があることに注意してください。
<reliability> <kind>RELIABLE_RELIABILITY_QOS</kind> </reliability>
状態データの送信のためにRTI Connext DDSを使用するメリットのひとつは、状態が変化すると同時にデータを送信できるだけでなく、後で接続された関連アプリケーションも起動直後に最新の状態データを確実に受信できる機能です。これが意味することは、チョコレートロットの状態は変化の発生時に送信が可能ということです。関連アプリケーションは、まだ起動していないとしても、起動直後に最新のロット状態を受信します。後で接続されたアプリケーションへの送信を可能にするには、データは一時的にローカルで送信されるか、より高いレベルの耐久性をもって送信される必要があります。
<reliability> <kind>TRANSIENT_LOCAL_DURABILITY_QOS</kind> </reliability>
各ステーション コントローラにロット状態の最新情報のみを送信するために、このXMLはロット状態インスタンス毎に1つのサイズ履歴を保持するように、DataWriterで履歴キャッシュを設定します。
<history> <kind>KEEP_LAST_HISTORY_QOS</kind> <depth>1</depth> </history>
このデータは極めて高いスループットに対応するように調整する必要はありませんが、安定した信頼性を得るように調整します。詳細は、 FactoryStateData XMLのプロファイルに記述されています。