🏒 💬 🏇🏿 libuniset2-ACSを作成するためのライブラリ。一度見た方が良い...パート1 🤴🏼 👩🏽‍💼 🦗

むかし... ...私は「libunisetの知り合い-ACSを作成するためのライブラリ」という記事を書きましたが、続きを書く計画がありましたが、うまくいきませんでした。それ以来、ライブラリは大幅に成長し、バージョン2.0がすでにリリースされました。多くの新機能が登場しました。ログとプログラム変数のリモート表示、さまざまな便利なプロトコルとデータベースのサポート、「タイムマシン」もありますが、それに関しては...

一般に、私は自分の力を集めて、特定の例で「すべてを見る」方が良いと判断しました。

したがって、興味のある方はどうぞ。

作業の段階でいくつかの記事が計画されています。

残念ながら、実際のマルチノードネットワークプロジェクトの例を作成することは困難です（少なくとも、仮想マシンのネットワーク、パッケージのインストール、展開などが必要です）。したがって、コンパイルしてローカルで実行できる簡単な例を検討し、その上での基本的なユニセットの概念の操作を示します。

例として、次の「球形」問題を取り上げます。

レベル制御のプロセスを「タンク」に記述する必要があります

プロセスはタンクを満たし（ポンプをオンにし）、レベルが所定の上限しきい値（95％）に達するとすぐにコマンドをポンプに送信し、タンクを空にします。 レベルが下限しきい値（5％）に達するとすぐに、再び満たされ始めます。 そして円で。

作業は、（1）特別なコマンド「Start Work」の到着後に開始し、「Start Work」コマンドが削除されたときに完了する必要があります（0）。

なぜなら私自身は主にALTLinuxで作業しているため、このOSではすべての例が考慮されます。

私はSisyphusに座っていますが、例はP7プラットフォームで動作します

だから...

準備手順-プロジェクトの作成、パッケージのインストール

システムでの作業に必要なパッケージをインストールします

apt-get install libuniset2-devel libuniset2-extensions-devel libuniset2-utils libomniORB-names git gitk git-gui etersoft-build-utils ccache

これでプロジェクトをレイアウトできます...

重要： libuniset2には、C ++ 11をサポートするコンパイラーが必要です。

苦しみすぎないようにするために、 http：//github.com/Etersoft/uniset2-example masterブランチをダウンロードするだけで「基礎」を準備しました。

したがって、次のディレクトリ構造があります（もちろん、どのような構造でもかまいませんが、この構造は単なる「習慣」です）

/ユーティリティ-プロジェクトが通常成長するさまざまな補助ユーティリティ（スクリプト）

/ conf-プロジェクト構成ファイル

/ docs-ドキュメンテーション（および優れたプロジェクトでそれを使用しない方法）

/ include-共有プロジェクトヘッダーファイルの場所

/ src-実際のソースコード

/ lib-共通プロジェクトライブラリの場所（共通機能のコード）

configure.ac-プロジェクトをビルドするための実際のファイル（はい、私はautotoolsを使用します）

autogen.sh-Makefile.inを生成するヘルパースクリプト

そして、もちろん「美しい」プロジェクトにあるはずのファイル。

打ち上げ

 autogen.sh && configure && make

ところで、私はjmakeの使用に慣れています。これは、システム内のccacheの存在とプロセッサの数を考慮して、 etersoft-build-utilsパッケージのmakeのラッパーです。

すべてがコンパイルされたら、さらに先に進むことができます...一般に、まだ何もありません。

ステップ1-ユニセットプロジェクトの構成

ユニセットプロジェクトでは、システム構成全体が（通常は1つに）xmlファイルに保存されます。繰り返しになりますが、これはconfigure.xmlと呼ばれ、「conf /」に配置されます。私はこのファイルのフォーマットをペイントしません。目標は「何かを始めて、できるだけ早く作品を見る」ことですが、ドキュメントには説明があります ...

構成ファイルの入力を開始するには、タスクの説明から、プロジェクトで必要な「センサー」を理解する必要があります。一般に、次のリストを取得します。

START WORKコマンド-DIセンサー
現在のタンクレベル-AIセンサー
「充填ポンプ」をオンにするコマンド-DOセンサー
「空のポンプ」をオンにするコマンド-DOセンサー

これはすべて、 センサーセクションに入力されます（一意である場合、必要なIDを割り当てます）。

結果は次のようになります。

 <sensors name="Sensors" ...> <item id="100" name="OnControl_S" iotype="DI" textname="  (1 - , 0 -  )"/> <item id="101" name="Level_AS" iotype="AI" textname="   "/> <item id="102" name="CmdLoad_C" iotype="DO" textname="    ''"/> <item id="103" name="CmdUnload_C" iotype="DO" textname="    ''"/> </sensors>

センサーを導入するときに、それぞれに一意の識別子（ id ）、一意の名前（ name ）を設定し、 textname = ".."がまだあることがわかります。このテキストは、後でGUIまたは他のアプリケーションに使用できます。

各センサーには、4つのタイプ（ iotype ）のいずれかがあります。ここにドキュメントへのリンクがあります。

DI-デジタル入力
DO-デジタル出力
AI-アナログ入力
AO-アナログ出力

一般的に、そのようなタイプへの分割は少し条件付きですが、実際の入力/出力を扱う作業はありません。 しかし、タイプ自体は、設計されているシステムの観点から特定のセンサーが何であるかを決定します。 「エントリ」は「システムに入る」、「出口」は「出口」（つまり、システムが形成するもの）です。

以前に選別されたセンサーで...

ステップ2-シミュレーターを作成する

実際、管理プロセスの作業をデバッグするには、もう少しシミュレーターを作成する必要があります。基本的に同じ管理プロセスで、「必要な機器」のみを模倣します。そのため、より簡単なプロセスとして始めます（ ~~一気にTDDのファンであると想定し~~ます）。

その結果、プロジェクトにはさらに2つのカタログがあります

src /アルゴリズム/コントローラー -管理プロセス（タスクの解決）

src / Algorithms / Imitator-制御プロセスを調整するためのシミュレーター

また、いくつかのサービスディレクトリ（後述）があるため、別のサブディレクトリ"Algorithms"でプロセスを選択します。

シミュレーターのタスク（最も単純な「ダム」オプション）：

コマンド「fill」により、タンクの充填をシミュレートします（タンク内のアナログレベルセンサーの値を増やします）。
コマンド「空」で、タンクを空にすることをシミュレートします（タンク内のアナログレベルセンサーの値を減らします）。

シミュレーターを記述するxmlファイルを作成する

1つのヘルパーについて説明しますが、非常に重要なunisetユーティリティ： uniset2-codegenです。

これを使用して、特別なxml記述に基づいて、作業の「ルーチン部分」全体を含むプロセスの「スケルトン」が生成されます。その後、生成されたクラス（スケルトン）から「継承」し、必要な機能を実装（仮想関数の再定義）するだけで十分です。

xml-descriptionファイルは、「入力」と「出力」を記述する単純なxmlファイルです。

このプロセスの場合（「ブラックボックス」と見なす場合）。以下を理解することが重要です。

「入力」と「出力」は本質的に、プロセスが「受信」（入力）または「セット」（出力）するセンサーです。
あるプロセスの「入力」とは何か、別のプロセスの「出力」である可能性があります。
入力/出力はセンサー自体ではなく、クラスフィールドであり、後で（開始時に）特定のセンサーに接続されます。

これをすべて実現するために、要点を理解しましょう。シミュレーターには、次のものがあります。

2つの入力はfill / emptyコマンドで、 1つの出力はタンク内の実際のシミュレーションレベルです。次に、入力/出力を記述するxmlファイルの部分は次のようになります。

  <smap> <item name="Level_s" vartype="out" iotype="AI" comment="   "> <item name="cmdLoad_c" vartype="in" iotype="DO" comment="  "> <item name="cmdUload_c" vartype="in" iotype="DO" comment="  «»"> </smap>

name-（クラスのスケルトン内の） "変数"の名前を設定します。（この入力/出力が接続されるセンサーのID）を含むクラスフィールド、および現在の値を含む変数が、この名前から生成されます。

vartype-変数「input」または「output」のタイプを定義します。入力は「読む」ものであり、「出口」は「書き込む」ものです。

コメント -doxygenスタイルのコメントになります（/ *！<xxxxx * /）

したがって、一般的には、その後いくつかのシミュレーターを起動できます。各シミュレーターはセンサーに関連付けられます...

詳細に興味がある人のために..

完全な説明ファイルは次のようになります。

 <?xml version="1.0" encoding="utf-8"?> <!-- name -   msgcount -       sleep_msec -       type ==== in -  (  ) out -  () --> <Imitator> <settings> <set name="class-name" val="Imitator"/> <set name="msg-count" val="30"/> <set name="sleep-msec" val="150"/> </settings> <variables> <item name="stepVal" type="long" const="1" default="6" comment="  ()"/> <item name="stepTime" type="long" const="1" default="500" comment="   , "/> </variables> <smap> <item name="Level_s" vartype="out" iotype="AI" comment="   "/> <item name="cmdLoad_c" vartype="in" iotype="DO" comment="  "/> <item name="cmdUload_c" vartype="in" iotype="DO" comment="  ''"/> </smap> <msgmap> </msgmap> </Imitator>

シミュレーターのコードを書く

入力/出力を形成したら、スケルトンを生成できます。詳細に入ることなく、これは次のコマンドで実行されます。

 uniset2-codegen -n Imitator --ask --no-main imitator.src.xml

パラメーター--ask-変更通知に基づいてプロセスを生成するように指示します（センサーの順序付け）

パラメーター--no-main-main.ccを生成しないように指示します独自に作成します。

-nオプションは、スケルトンが生成されるクラスの名前です。

一般に、このコマンドはに追加されます

Makefile.am

 bin_PROGRAMS = imitator BUILT_SOURCES = Imitator_SK.h Imitator_SK.h imitator_LDADD = $(top_builddir)/lib/libUniSetExample.la #imitator_CPPFLAGS = imitator_SOURCES = Imitator_SK.cc Imitator.cc imitator-main.cc Imitator_SK.h Imitator_SK.cc: imitator.src.xml @UNISET_CODEGEN@ -n Imitator --topdir $(top_builddir)/ --ask --no-main imitator.src.xml clean-local: rm -rf *_SK.cc *_SK.h *.log

その結果、2つのファイルが生成されます。

Imitator_SK.h-ヘッダー

Imitator_SK.cc-実装

これらはそこで行われていることを研究するための非常に興味深いファイルですが、今のところ私たちはそれらに任せていません...

したがって、実際の実装を行います。作業のロジックを実装する2つのファイルを作成します。

Imitator.h

Imitator.cc

Imitator.hをさらに詳しく見てみましょう。

Imitator.h

 #ifndef Imitator_H_ #define Imitator_H_ // ----------------------------------------------------------------------------- #include <string> #include "Imitator_SK.h" // ----------------------------------------------------------------------------- /*! \page_Imitator     (   ) - \ref sec_imitator_Common \section sec_loadproc_Common      ""(cmdLoad_c)     ( ).   ""(cmdUnload_c)     ( ). */ class Imitator: public Imitator_SK { public: Imitator( UniSetTypes::ObjectId id, xmlNode* cnode, const std::string& prefix = "" ); virtual ~Imitator(); enum Timers { tmStep }; protected: virtual void sensorInfo( const UniSetTypes::SensorMessage* sm ) override; virtual void timerInfo( const UniSetTypes::TimerMessage* tm ) override; private: }; // ----------------------------------------------------------------------------- #endif // Imitator_H_

ユニセットシステムでは、センサーに関する通知を受信し、一般に何らかの方法で外部とやり取りするすべてのオブジェクトには、システム内で一意の識別子が必要です。これに加えて、プロセスは入力/出力を特定のセンサーに接続する必要があります。このため、configure.xmlでは、各プロセスに独自の構成セクションがあります。

その結果、コンストラクターでは、オブジェクトの識別子と、このプロセスの設定を持つ特定のxml-nodeへのポインターを渡します。さらに、プレフィックスがあります（これはコマンドライン引数を処理するためのものです。後で使用する方法を示します）。

シミュレーターの説明に基づいて、コマンド処理（入力）とタイマーを使用して、時間の充填/排出を実装する必要があります。これを行うには、2つの関数のみを定義（再定義）します。

  //     : virtual void sensorInfo( const UniSetTypes::SensorMessage* sm ) override; //   : virtual void timerInfo( const UniSetTypes::TimerMessage* tm ) override;

まず、sensorInfo（）の実装を詳しく見てみましょう。

 void Imitator::sensorInfo( const UniSetTypes::SensorMessage* sm ) { if( sm->id == cmdLoad_c ) { if( sm->value ) { myinfo << myname << "(sensorInfo):   ''..." << endl; askTimer(tmStep,stepTime); //     } } else if( sm->id == cmdUnload_c ) { if( sm->value ) { myinfo << myname << "(sensorInfo):   ''..." << endl; askTimer(tmStep,stepTime); //     } } }

ここではすべてが単純です...「fill」コマンドが来ました（cmdLoad_c = 1）-タイマーを開始します...（以前はわかりませんでした）。

「空の」コマンドが来ました（cmdUnload_c = 1）-タイマーも開始します。すべてのロジックはタイマーに含まれています。

（もちろん、これをすべて別の方法で実装することができます...タイマーをどのように使用するかをどうにかして示す必要があります:)）

timerInfo（）の実装を見てみましょう。

  void Imitator::timerInfo( const UniSetTypes::TimerMessage* tm ) { if( tm->id == tmStep ) { if( in_cmdLoad_c ) //  .. { out_Level_s += stepVal; if( out_Level_s >= maxLevel ) { out_Level_s = maxLevel; askTimer(tmStep,0); //   ( ) } return; } if( in_cmdUnload_c ) //   { out_Level_s -= stepVal; if( out_Level_s <= minLevel ) { out_Level_s = minLevel; askTimer(tmStep,0); //   ( ) } return; } } }

tmStepタイマーがトリガーされたとき（タイマーはいくつでも構いません）。チームが現在「保持」していることを確認し、「満たされている」場合（ in_cmdLoad_c = 1 ）、 out_Level_sを増分ステップ（ stepVal ） 増やし 、「空にする」場合、 out_Level_sをstepVal減らします。同時に、最大と最小を確認します。

そして今、このキッチン全体のちょっとした分析...

「どこで」in_cmdLoad_c、in_cmdUnload_c、out_Level_sフィールドがクラスに現れました。

実際にはスケルトンで生成されます。

すべての「入力」（ vartype = "in" xml記述ファイルを参照）について、次のフィールドがスケルトンに生成されます

name-この「入力」が関連付けられているセンサーの識別子を含むフィールド

in_name-現在のセンサー値を含むフィールド

すべての「終了」（ vartype = "out" xml記述ファイルを参照）について、次のフィールドがスケルトンに生成されます

name-この「出力」が関連付けられているセンサーの識別子を含むフィールド

out_name-センサーを設定するためのフィールド。

タイマーはどのように機能しますか

同じスケルトンには、特別な関数askTimer（timerId、msec、count）があります

timerId-タイマーID（これは何らかの種類の番号であるため、タイマーを区別できます）

msec- 「コッキングタイマー」のミリ秒単位の時間。 0に設定すると、タイマーは無効になります。

count-タイマーをトリガーする回数のオプションのパラメーター（デフォルトでは、停止するまでミリ秒ごとに発生します）。

タイマーが「開始」されると、 msecミリ秒ごとに、 timerInfo関数が呼び出され（const UniSetTypes :: TimerMessage * tm） 、アクティブ化されたタイマーの識別子を含むTimerMessage構造体が渡されます。

重要：

まだリアルタイムではないため、タイマーは指定された時間よりも「早く」動作しないことを保証するだけです。
したがって、タイマーは非同期ではありません（！）。メッセージは順番に処理されます。 何らかのハンドラー（xxx）を呼び出すことでハンドラーのどこか（例えばsensorInfo ）でスタックした場合、タイマーはこの時間「待機」します。

タイマーは、パラメータのxml-fileで指定された時間の最小「量子」（ステップ）の倍数でなければなりません

 <set name="sleep-msec" val="150"/>

つまりここで150ミリ秒が示されている場合、50ミリ秒タイマーは150ミリ秒後も動作します。

これらの詳細に注意を払わないことをお勧めしますが、それらについては後で...

sensorInfoの仕組み

sensorInfo（）関数は、入力の値が変更されるたびに呼び出されます。実際、センサーの変更に関する通知はSharedMemoryから送信されます （プロセスが通知で実行される場合）。

ロジックが決定しました。 実際にmain（）を記述する必要があります。

コードを表示し、コメントするだけです...

関数メイン（）

main.cc

 #include <UniSetActivator.h> #include "UniSetExampleConfiguration.h" #include "Imitator.h" // ----------------------------------------------------------------------------- using namespace UniSetTypes; using namespace std; // ----------------------------------------------------------------------------- int main( int argc, const char** argv ) { try { auto conf = uniset_init(argc, argv); auto act = UniSetActivator::Instance(); auto im = UniSetExample::make_object<Imitator>("Imitator1", "Imitator"); act->add(im); SystemMessage sm(SystemMessage::StartUp); act->broadcast( sm.transport_msg() ); act->run(false); return 0; } catch( const Exception& ex ) { cerr << "(imitator): " << ex << endl; } catch( const std::exception& ex ) { cerr << "(imitator): " << ex.what() << endl; } catch(...) { cerr << "(imitator): catch(...)" << endl; } return 1; } // -----------------------------------------------------------------------------

まず、プロジェクトの構成をダウンロードし、libunisetが機能するために必要なすべてを初期化する必要があります。これはすべて、すべてのニーズに対してグローバルポインター（shared_ptr）conf（構成）を返す関数uniset_init（argc、argv）で行われます。また、プログラムのどこからでも入手できます。

 auto conf = uniset_conf();

この例では、使用していません（明示的にですが、実際にはmake_objectを使用しています）。

uniset_init（）で、configure.xmlファイルがロードされます（同じ名前のファイルはデフォルトでロードしようとしています）。に3番目の引数を渡すことで再定義できます

 uniset_init(argc,argc,"myconfigure.xml")

、またはコマンドラインで--confile myconfile.xmlパラメーターを設定します。

すべてのユニセットオブジェクトを「アクティブ化」する必要があります。その後、それらは通知を受信し、一般に外部と対話できるようになります。このために、システムにはUniSetActivatorがあります（コードからわかるように、これはsingletonです ）。アクティベーションプロセスは簡単です。 オブジェクトを作成してアクティベーターに追加します （より正確には、オブジェクトごとにshared_ptr）。

上記のように、 Imitatorクラスのオブジェクトを作成するには、その一意の識別子と、設定を含むxml-nodeへのポインターを渡す必要があります。わかりやすくするために、テンプレート関数make_object <>がUniSetExampleConfigurationで宣言され、オブジェクトのテキスト名（configure.xmlのセクション内の名前）とconfigure.xmlのこのオブジェクトの構成ノード<XXXNodeName name = "ObectName />の名前を渡し ます。 make_object <>関数は、これらのパラメーターを使用してObjectIdオブジェクトを取得し、 configure.xmlで xmlNode *を見つけるという「魔法」をすべて隠しています。この例は、 configure.xmlに 「Imitator1」という名前のオブジェクト（識別子）と構成セクション<Imitator name = "Imitator1" ... />が必要であることを示しています

これはconfigure.xmlでの見た目です

 <objects name="Objects" section="Objects"> ... <item id="20001" name="Imitator1"/> ... </objects>

そして、通常は設定セクションで作成されたチューニングセクション

  <settings> <Imitator name="Imitator1"/> ... </settings>

これにより、シミュレータのコーディングが終了しました。

シミュレーター構成

構成プロセス自体は、 configure.xmlを設定し 、センサーをプロセスの入力と出力にバインドすることで構成されます。この問題を解決するために、特別なユーティリティuniset-linkeditorがあります。これはバインディングエディタであり、グラフィカルにバインディングを作成したり、xml記述ファイルで宣言されている他のパラメータを編集したりできます。 Uniset-linkeditor自体は python で書かれています。別のパッケージとしてインストールされます。最初にインストールする必要があります

 apt-get install uniset-configurator

src / Algorithms / Imitator ディレクトリには、バインディングエディターを起動する特別なスクリプトedit_imitator.shが含まれています。実際には、コマンド（入力）をCmdLoad_CおよびCmdUnload_Cセンサーに 関連付け 、タンク内のレベル（ シミュレーターの出力）をLevel_ASセンサーにアタッチする必要があります。これは手動で行うことができ、複雑なことはありません...結果として、シミュレーターの構成セクション（ configure.xmlプロジェクトファイル内）は次の形式になります。

 <Imitator name="Imitator1" Level_s="Level_AS" cmdLoad_c="CmdLoad_C" cmdUnload_c="CmdUnload_C"/>

ご覧のとおり、バインディングは簡単に作成できます。各入力または出力は、システム内のセンサーに関連付けられています。

小計

「多くの手紙」があったという事実にもかかわらず、実際、私たちはほとんど何もしませんでした

configure.xmlプロジェクトファイルを作成（入力）しました
シミュレーターimitator.src.xmlを記述するファイルを作成し、そこからクラスの「スケルトン」を生成しました
ロジックの実装を作成しました（ 2つの関数のみ ）
Wrote（ ほぼ定型文 ） main（）
シミュレーターを構成しました（ 特定のセンサーを結び付けました ）

それだけです...

実行しようとするのは今のままです。

次の部分になります...

興味のある方へ：

libuniset2-ACSを作成するためのライブラリ。 一度見た方が良い...パート1