libuniset2-ACSを作成するためのライブラリ。 一度見たほうがいい...パート4（セットアップ）

前のパート（ パート1 、 パート2 、 パート3 ）では、2つのプロセスの作成について説明しました。シミュレーターと制御プロセスです。

そのため、現時点では既に実装を完了しており、次のプロセスを開始しています。

• シミュレーター
• 管理プロセス
• ストレージ（SharedMemory）

セットアップを開始できます...

調整 導入部。

ここで何が起こっているのかを理解するための小さな説明図の時が来ました...


実際、もちろん、すべてがもう少し複雑ですが、この図は、 「情報の流れ」がどのようにあるかを理解するのに役立つように設計されています。
だから..

• すべての対話はSharedMemoryを介して行われます。
• 制御プロセスはSMコマンドへの保存を受け取り、SMはレベルセンサー（Level_s）の変更の通知を受け取ります
• 制御シミュレータは、SMからコマンドの変更の通知を受け取り、SMでシミュレートされたレベルステータスを保存します
• すべての相互作用はセンサーを経由します

すべての相互作用はセンサーを介して行われるため、セットアップは一般に「センサーの設定」と「センサーの現在の状態の監視」です。 これらの目的のために、いくつかのユーティリティがlibuniset2-utilsに含まれています。

• uniset2-adminは多機能ユーティリティですが、この場合、センサーの現在の状態を設定（ setValue ）および表示（ getValue ）することもできます。
• uniset2-smviewer -SMに登録されているすべてのセンサーのステータスをすぐに確認できるユーティリティ
• uniset2-smonit-指定されたセンサーの変更を「監視」（監視）するユーティリティ

これらのユーティリティはすべて、試運転で積極的に使用されていますが、プロセスの「外部」寿命を追跡するためのツールです。 また、内部から「プロセスの寿命」を観察できる2つの追加メカニズムがあります。

• vmonit-オブジェクトの内部変数を監視する
• LogServer-プロセスログのリモート読み取り

もちろん、2つのプロセスを一度に実行してセットアップを開始し、そこで何が起こるかを確認できます。 ただし、可能であれば、プロセスの調整を個別に実行する方が正確です。 シミュレーターから始めましょう。

シミュレーターのデバッグ

• SMを起動し ます-src / Services / SharedMemory /ディレクトリに移動します。 start_fg.shスクリプトを実行します
• シミュレーターを実行します -src / Algorithms / Imitator /ディレクトリーに移動します。 start_fg.shスクリプトを実行します

オブジェクトが使用可能であることを確認してください。 src / Services / Administrator /に移動し、。 / existを実行します
以下を見なければなりません

さあ、 最初に戻って、シミュレーターが何をすべきかを思い出してください。
シミュレーターは、 cmdLoad_C = 1コマンドの到着時に、タンクの充填のシミュレーション（ Level_ASセンサーの成長）を開始する必要があり、 cmdUnload_C = 1コマンドの到着時に、タンクの空をシミュレートする（ Level_ASセンサーの削減）必要があります。

だから私たちはする必要があります

• センサーcmdLoad_C = 1を設定し、 Level_ASの上昇を確認します
• センサーcmdUnload_C = 1を設定し、 Level_ASの減少を確認します

一般的にセンサーの現在の状態を見てみましょう。 uniset2-smviewerユーティリティを使用します 。
src / Services / SMViewerディレクトリに移動し、。 / start_fg.shを実行します
私たちはそれを見る...

ご覧のとおり、すべてがゼロです...もちろん、実際のプロジェクトには非常に多くのセンサーがあります。したがって、出力を何らかの方法でフィルター処理する場合は、 grepとともにuniset2-smviewerを使用できます（ また、そうする必要があります） ...

レベルセンサーがどのように変化するかを確認するために必要な2番目のユーティリティはuniset2-smonitです。 実行しましょう。 src / Services / SMonit /に移動し 、...

このユーティリティでは、監視するセンサーを指定する必要があるため、 -sidキーがあります
（簡単にするために、すぐにstart_fg.shに入力します ）。 --sidパラメーターとして識別子を指定するか、センサーの名前を指定できます。 Level_ASという名前を示します。

 ./start_fg.sh Level_AS 

smonitが起動し、変更を待機してハングします。 同時に、センサーの現在の状態が最初に表示されます。 出力から、 名前 、最後の変更の時間 （マイクロ秒を含む）、このセンサーをSMに保存したプロセスの識別子 （この場合はImitator1）、および現在の値 （およびfloat- fvalueの形式）を確認できます。

すべての準備が整ったようで、cmdLoad_C = 1センサーを設定し、Level_ASセンサーがどのように変化したかを確認します。
adminを使用して設定します。

 [pv@pvbook Administrator]$ ./setValue CmdLoad_C=1 

smonitが実行されているコンソールに切り替えて、センサーがどのように実行されたか（0から100まで）を確認します。

したがって、増加は機能します。 削減は同じ方法でチェックされます...最初に、前のコマンドをリセットすることを忘れないでください、そして私たちは一挙にそれをします

 [pv@pvbook Administrator]$ ./setValue CmdLoad_C=0,CmdUnload_C=1 

smonitは他の方法で実行しました（100から0）

オブジェクト内部変数の監視（vmonit）

次に、オブジェクトの内部変数を表示できるメカニズムについて説明します。 一般的に、すべてが非常に簡単です。 オブジェクトの識別子または名前がわかれば、単純に情報を要求できます。
したがって、すべてが稼働しています。 Imitator1オブジェクトが示すものを見てみましょう。
src / Services / Administratorに移動して、コマンド./oinfo Imitator1を実行します

出力からわかるように、 oinfoコマンドを使用すると、

• センサーにバインドされたオブジェクトのすべての入力および出力の状態（ 内部のin_、out_変数）
• 現在の稼働タイマーのリスト、残りの稼働時間など。
• プロセスが開始されるすべての変数の値（ src.xmlで宣言 ）
• オブジェクトの内部情報（メッセージキューのサイズ、最大値、オーバーフローがあったかどうか）
• ユーザー情報と同様に

ユーザー情報についてもう少し言います...
各オブジェクト（より正確には、クラスのスケルトン）には特別な機能があります

 virtual std::string getMonitInfo() override; 

これを再定義すると、情報をテキスト（文字列）の形式で表示できます。 この場合、たとえば、シミュレーターは「Current Operating Mode：Fill」（または「empty」）を書き込みます。 もっと複雑なものを書くことができます。

情報出力に変数を追加する

もちろん、管理プロセスを作成するとき、おそらく、xmlファイルで宣言された変数に加えて、独自のクラスフィールドがいくつかあります。 そしてもちろん、現在の状態と変数についてもフォロー（情報を表示）したいと思うでしょう。 簡単なものはありません 。 シミュレーターに2つのコマンドカウンターを追加するとします。

次に、 oinfoの出力でそれらを表示する場合は、コンストラクターで2つの魔法の呼び出しを行うだけです。

つまり 変数をvmonit（xxx）でラップしただけです。 それは確かにマクロマジックなしではできませんでしたが、おそらくあまり気にしません...
その結果、画面上には既に変数が表示されています（ 他の要素が散らかっています ）。

重要：これまでのところ、標準の単純型（bool、int、longなど）のみがサポートされています。その他すべてには、汎用関数getMonitInfo（）があります。

ログのリモート読み取り（組み込みLogServer）

ご存知のように、デバッグメカニズムがいくつ存在しても、お気に入りのcout （ またはお気に入りの printfで はない ）が引き続き使用されます。 まあ、libunisetもこのメソッドを提供します。 実際、トピックは非常に広範囲に渡っており、すべての機能と詳細を公開する場合、これは別の記事のトピックです。 したがって、アプリケーションを表示し、いくつかの詳細を説明します...
生成されたクラスのスケルトンには、logs- logの特別なオブジェクトがあります 。 それは本質的にcoutのようなインターフェースを持ち、それはshared_ptrのみであるため、ポインターとして使用する必要があります。 例えば

 log->info() << "......information.." << endl; 

または

 log->crit() << "......critical" << endl; 

ログには15のレベルがあり、それらを「並行して」有効にすることができます（つまり、info、warn、critなど）、ログを書き込むファイルを指定できます。各行の先頭で日付と時刻の出力を有効または無効にできます。 。 一般的に、多くの標準機能。 各オブジェクトについて、起動時にコマンドライン引数を指定するだけでログを有効または無効にできます

しかし、 LogServerのようなメカニズムの存在がなければ、これはそれほど面白くないでしょう。 各オブジェクトには組み込みのLogServerがあり、デフォルトでは起動しません。したがって、リソースを消費せず、まったく表示されません。 しかし、単純なコマンドライン引数

 --ObjectName-run-logserver 

有効にできます。 デフォルトでは、 localhostで実行され、オブジェクト識別子をポートとして使用します。 ただし、 ホストとポートを強制的に実行することもできます。

オブジェクトがLogServerを実行した後、そのログをリモートで読み取ることができます 。 指定されたホストとポートに接続するだけです。 ログを読み取るための特別なユーティリティuniset2-logがあります 。 これを使用すると、ログの読み取りに加えて、ログ出力のレベル、ファイルへの書き込みなども制御できます。 オブジェクトのログを完全に制御します。 これは非常に便利なメカニズムです。 プログラムを再起動せずにログを有効または無効にすることができます （ プロセスを停止することはできませんが、実際に内部で何が起こっているかを確認する必要があります）。
...見せてみましょう...
そのため、すべてが開始され、start_fg.shシミュレーターに行を追加しました

 --Imitator1-run-logserver 

ところで、./ oinfoの出力では、誰かが気付いていない場合、LogServerが実行されているかどうかに関する情報が表示されます。 ただし、もう一度表示します（ src / Services / Administator /ディレクトリに移動し、./oinfo Imitator1コマンドを実行します ）。

そのため、logserverはlocalhostおよびポート20001で実行されています。 ただし、デフォルトでは（もちろん、開発者が強制的にオンにしない限り） 、ログは無効になっています。 したがって、接続するだけでなく、 すべての （任意の）ログをすぐに有効にして 、すぐに表示できるようにします。 接続しましょう（-vスイッチを追加して、接続先のデバッグ情報を表示します）

 uniset2-log -i localhost -p 20001 -v -a any 

出力用のタイマー機能にログ（レベル3）を追加して、操作を示しました。

次に（上記のように）接続し、別のコンソール（ src / Services / Administratorに移動 ）でコマンドを設定します

 ./setValue CmdLoad_C=1,CmdUnload_C=0 

...しかし、しばらくすると反対

 ./setValue CmdLoad_C=0,CmdUnload_C=1 

そして、これがログに表示されるものです（ リモートで読み取り可能 ）

ログをリモートで読み取る機会を利用して、ログを有効にした場合、ログも実際のシステムでは機能しないため、 入力/出力は高価な喜びであることを忘れないようにすることが重要です。 それでも、これまでに明らかにしなかった小さな機会を紹介します。

• LogAgregator-複数のオブジェクトからログを集約し、それらを「集中的に」管理できるオブジェクト
• LogAgregatoreは正規表現（C ++ 11）をサポートしているため、どのログ（ どのオブジェクトから ）を読みたいかをより柔軟に選択できます。
• uniset2-logで複数のコマンドを一度に指定して、一部のログを有効にし、他のログを無効にして、たとえば3番目のログを読み取る機能。 これらすべてを1つのチームで行います。

実際のアプリケーションでは、 LogServerはすべてのオブジェクト（単一の実行可能ファイル内）で単独で実行され、 LogAgregatorを使用して階層に配置され、柔軟に管理できます。

簡単な要約

私は毎回いくつかのメカニズムについて話し、内部機能の詳細と外部使用の容易さのバランスをとろうとします。 つまり 「 既製のチームを以下に示します 。 それらはすぐに使用できます 。」 したがって、私はあまり語りませんでした、そしておそらく何かが明らかでないままでした...私はあなたの質問に答えようとします。
一般に、通常のテストが「テスト」よりもはるかに大きいと仮定しない場合（境界ケース、max、minの設定、同時コマンドの発行など）、シミュレータのセットアップは完了です。 主なことは、libuniset2に含まれるデバッグツールを実証することでした。

• センサーを操作し、その状態を監視するためのユーティリティ
• オブジェクトの内部変数の状態をリモートで表示するメカニズム
• リモート読み取りおよびロギング制御メカニズム（各オブジェクト用）

管理プロセスの作業はほぼ同じ方法で調整できますが、制御アルゴリズムの調整については、より高度な例の設定方法（ uniset2-testsuiteを使用した機能テストの作成）を使用してより適切に示します。 次の部分でそれについて...

さて、最後に、いつものように、参照：

• githubのLibuniset2プロジェクト
• サンプルソース
• バグジラプロジェクト