2023/2/15 - 読み終える時間: 2 分

HCL RTist Announces Two New Releases

HCL RTist、2 つの新しいリリースを発表

2023年2月10日

著者: Mattias Mohlin / Senior Solutions Architect for HCLSoftware

HCL RTist 開発チームは、2つの新しいリリースを発表します。

• RTist 11.2 2023.04
• RTist 11.3 2023.04。

HCL RTist 11.3 は、Eclipse 2022.06 と Java 17 で動作し、現在、実稼働環境での使用を推奨しています。2022.06では、Eclipseのコアの改良に加え、CDT（C/C++ Development Tooling）とEGitの新バージョンが登場し、いくつかの重要な改良が加えられています。

CDTとEGitの改善点については、こちらのプレゼンテーションをご参照ください。What's Newプレゼンテーション

RTist特有の新機能として、Pure Virtual Operations with Bodies、Make Space Tool、Diagram Appearance Improvementが両リリースで利用可能です。各機能の詳細については、こちらをご覧ください。

ボディを使ったピュアバーチャルオペレーション

HCL RTist、2つの新リリースを発表

コードビューまたはコードエディタを使用して、純粋仮想操作の実装ボディを提供することが可能になり、モデルコンパイラによってC++に変換されます。このような実装は、再定義されたオペレーションから呼び出すことができるため、純粋な仮想オペレーションを実装すると便利な場合があります。

スペース作成ツール

ほとんどのダイアグラムで、パレットに新しい "Make Space "ツールが追加されました。このツールは、シンボルや線を図の特定のポイントから移動させ、コンテンツを追加するためのスペースを確保するために使用します。シンボルはクリックしたポイントから放射状に移動し、図に十分な空きスペースができるまでクリックし続けることができます。必要であれば、ダイアグラムのサイズを自動的に大きくして、コンテンツを配置することができます。

ダイアグラムの外観の改善

ステートマシン図において、継承された要素と再定義された要素の外観が改善されました。このような要素は、デフォルトで破線で描かれるようになりました。再定義された要素には、特別なスタイルの破線が使用され、継承された要素とより簡単に区別することができるようになりました。

継承された要素と再定義された要素の線の太さも以前より太くなりましたが、新しい環境設定「リアルタイム開発-ダイアグラム-状態図-継承された要素の外観-線幅」があり、以前の外観を好む場合は「小さい」に設定することが可能です。逆に、これらの要素をさらに強調したい場合は、環境設定を "大" に設定することができます。

RTistの新機能については、Sprint Demo YouTube Playlistにあるビデオをご覧ください。

2023/2/8 - 読み終える時間: 2 分

A New Release: RTist 11.2 2022.48 の翻訳版です。

新しいリリース: HCL RTist 11.2 2022.48

2023年1月27日

著者: Mattias Mohlin / Senior Solutions Architect for HCLSoftware

HCL RTist 開発チームは、2つの新しいリリースを確定しました。

• RTist 11.2 2022.48
• RTist 11.3 2022.48です。これは、RTist 11.3 for Eclipse 2022.06 with Java 17の実験的なリリース

これらのリリースの新機能のいくつかを見てみましょう。

改良された継承の再整理

Inheritance Rearrangement ダイアログが大幅に改善され、継承の再配置によって影響を受ける参照のリストを表示することができるようになりました。各参照の処理方法を選択でき、ダイアグラム・エディター、プロジェクト・エクスプローラー、プロパティ・ビューで参照する要素を表示するように移動することが可能です。

継承の再配置ダイアログは、リファクタリング後、サブカプセル内の少なくとも1つの参照が現在のターゲット要素にバインドできない場合にのみ表示されます。すべてのターゲット要素にアクセスできる場合（新しいスーパーカプセルはすでに古いスーパーカプセルを継承しているため）、ダイアログは表示されず、継承の再配置は簡単に実行できるようになります。これは、既存の継承階層にカプセルを追加または削除する一般的なシナリオを最小限の労力で実行できるようにするための重要な改善点です。

再起動時にモデリング・エディタを自動復元する機能

新しい環境設定 Modeling - Automatically restore modeling editors on startup は、Eclipse の再起動後に以前に開いていたモデリング・エディターを自動的にリストアするように設定できます。これは、Eclipse に組み込まれたエディタのリストアの拡張であり、モデリング・エディタはワークベンチ・エディタ・エリア で通常の Eclipse エディタの後に配置されます。

MinGw 12.2

MinGw 12.2 コンパイラーは RTist で直接使用できるようになりました。このコンパイラー用のターゲット構成が提供され、以前の MinGw 8.1 用の構成を置き換えます。このコンパイラのためのプリビルドライブラリ（TargetRTS、Connexis、LibTCPServer）も利用可能です。

この作業の一環として、Connexisにおける64ビットアプリケーションのサポートも改善されました。

コンポジットステートナビゲーションの改善

継承された複合状態に移動すると、継承されたステートマシンを開くか、状態を再定義してローカルのステートマシン図を作成するかを尋ねるプロンプトが表示されます。この選択は記憶されるため、何度もプロンプトが表示されることはありません。対応する環境設定は、RealTime Development - Diagrams - State Chart - When going inside inherited composite state（リアルタイム開発 - ダイアグラム - ステート・チャート - 継承された複合状態の内部に入るとき）です。

新機能の詳細については、Sprint Demo YouTube Playlist にあるビデオをご覧ください。

2022/5月/2 - 読み終える時間: ~1 分

HCL RTist announces End of Support for V10.3 の翻訳版です。

HCL RTist V10.3 サポート終了のお知らせ

2023年4月30日以降、HCL RTist V10.3 RTist (PID=HCL18OP1179) はサポート終了となります。

HCL RTist 10.3をお使いのお客様は、V11.0、11.1、またはそれ以降の新しいバージョンにアップグレードすることをお勧めします。アップグレードは簡単で、古いモデルも10.3と同じように動作するはずです。移行の観点からは、サポートされるコンパイラが主な違いです。

HCL RTistの異なるバージョンにおけるアップグレードのより包括的なリストについては、このリンクを参照してください。

HCL ソフトウェアは、製品の絶え間ない革新により、究極の顧客満足を提供することに専念しています。いつものように、HCLの営業担当者、または、rtist@hcl.com まで、お気軽にお問い合わせください。

2021/12/2 - 読み終える時間: 2 分

What's new in HCL RTist 11.1 2021.46 の翻訳版です。

HCL RTist 11.1 2021.46 の新機能

本日、HCL RTist の別のリリースを出荷しました。11.1 2021.46. いつものように、いくつかの新機能といくつかのバグフィックスがあります。その中からいくつかをご紹介します。

イベントデータの移動

2つのカプセル間で頻繁にデータを送信する場合や、データが大きい場合は、イベントデータを移動するという新しい機能を利用できます。上の図は、2つのカプセル間で頻繁に送信される文字列をコピーではなく移動するテストアプリケーションで、アプリケーションのパフォーマンスが約35%向上したことを示しています。

型の型記述子には、新しい移動関数が含まれています。定義されていれば、オブジェクトへのrvalue参照がsend-statementで提供されている場合、データ・オブジェクトが移動されます。例えば、std::moveを使ってrvalueの参照を得ることができます。

pb.e1(mc).send(); // コピーによる送信
pb.e1(std::move(mc)).send(); // 移動による送信

受信したイベントのデータをトランジション関数内で移動させることもできます。これを可能にするには、rtdataパラメータを非constとして宣言する必要があります。これを実現するには、新しいトランジションプロパティ Const rtdata parameter のマークを外します。

そして、イベントデータを、例えばカプセル属性に移動させることができます。

m = std::move(*rtdata);

トランジションのコピー／ペースト

あるステートマシンのトランジションをコピーして、別の（または同じ）ステートマシンのステートにペーストできるようになりました。これにより、既存のステートマシンに基づいて新しいステートマシンを作成するプロセスを大幅にスピードアップすることができます。コピーしたトランジションをステートにペーストすると、最初はそのステートの自己トランジションになります。他の状態をターゲットにしたい場合は、後からステートチャート図の中でトランジションを再ルーティングすることができます。

フラグメント・ファイルの自動作成

新しい環境設定「モデリング」-「フラグメント・ファイルの自動作成」 は、新しく作成されたモデル要素をそれぞれのフラ グメント・ファイルに配置したい場合に設定できます。これは、完全に断片化されたモデルの作成を好むユーザーにとって便利です。なお、フラグメントファイルに格納されたモデル要素の名前を変更しても、フラグメントファイルの名前は自動的に変更されません。プロジェクト・エクスプローラーのコンテキスト・メニューには、フラグメント・ファイルの名前を変更するための別のコマンド Refactor - Rename file が用意されています。

コード・コンプライアンス

環境設定 「RealTime Development」-「Build/Transformations」-「C++」-「Code compliance」-「Clang-Tidy」 では、コード内に抑制コメントを生成することで、特定の sizeof 式に対する警告も処理するようになりました。生成されたコードから警告を受けないことで、Clang-Tidyを使って手書きのコードスニペットの問題点を見つけることがより現実的になります。

このリリースの新機能については、Sprint Demo YouTube Playlist のビデオをご覧ください。

2021/11/10 - 読み終える時間: 3 分

Writing a generic type descriptor with HCL RTist の翻訳版です。

HCL RTistによる汎用型記述子の記述

2021年11月9日

著者: Mattias Mohlin / Senior Solutions Architect for HCL Software

型記述子は、クラス、typedef、型の別名など、モデル内のユーザー定義の型に関するメタデータを提供します。TargetRTSは、型記述子の情報を使って、その型のオブジェクトをどのように初期化、コピー、エンコードするかなどを知ります。多くの場合、モデルコンパイラは型に対して自動的に型記述子を生成しますが、場合によっては手動で型記述子を書く必要があります。型記述子に慣れていない方は、この記事を読んでから先に進むことをお勧めします。

ここでは、型がジェネリックである場合、つまり、1つまたは複数のテンプレートパラメータを持つ場合について見てみましょう。以前は，テンプレート型の具体的なインスタンスごとにtypedefやtype aliasを作成し，そのテンプレートのインスタンスに合わせて型記述子を記述する必要がありました．これは明らかに面倒で、しばしばコードの重複を招きました。RTist 11.1 2021.24からは、型と同じテンプレートパラメータを使用するジェネリックな型記述子を書くことができるようになりました。これにより、多くの時間を節約し、コードの重複を避けることができます。

例として，異なる種類の要素を持つベクトルを2つのカプセル間で送信する場合を考えてみましょう．まず最初に，std::vectorの型のエイリアスを定義し，vector型の型テンプレートパラメータを追加します．この場合、テンプレートパラメータを持つ型が必要なので、typedefは使えません。

次に、tを書きます。 target = new (target) std::vector<T>();

Copy 関数 target = new(target) std::vector<T>(*source);

Destroy 関数 target->~StdVector<T>();

今回の例では、これら3つの型記述子関数があれば十分ですが、汎用的なエンコードの実装方法を示すために、Encode関数も実装してみましょう。

const RTObject_class *elementTypeDescriptor = RTObject_class::fromType<T>();
if (!elementTypeDescriptor)
return 0; // Element type descriptor not available
int sum = 0;
bool first = true;
sum += coding->write_string(type->name());
sum += coding->write_string("{");
for (auto i = source->begin(); i != source->end(); i++) {
if (!first)
sum += coding->write_string(",");
first = false;
sum += elementTypeDescriptor->encode(&*i, coding);
}
sum += coding->write_string("}");
return sum;

この実装では、TargetRTSの新しいテンプレート関数であるRTObject_class::fromType()を使用して、ベクター要素の型の型記述子を取得します。その型記述子は、各ベクトル要素のエンコードに使用されます。

TargetRTSでは、すべての組み込みC++型に対してRTObject_class::fromType()のテンプレート特殊化を提供していますが、StdVectorを他の型でも使用したい場合には、同様の特殊化を記述する必要があります。例については、TargetRTS ファイルの RTObject_class.h を参照してください。

Decode関数は、解析を必要とするため、通常、型記述子関数の中で最も実装が難しい関数です。この関数を実装することは、このニュースレターの範囲外です。しかし、モデルコンパイラが型記述子を生成しないため、完全に空けることはできません。

デコード関数

// NOT IMPLEMENTED

return 1;

最後に、StdVector用のコードスニペットを2つ用意しておきます。

Header Preface #include <vector>

これにより、StdVector型を使用する際に、基礎となるstd::vector型が利用できるようになります。

Header Ending

template <> const char* RTName_StdVector<int>::name = "StdVector<int>";
template <> const char* RTName_StdVector<char>::name = "StdVector<char>";

これらのテンプレートの特殊化は厳密には必要ではありませんが、デバッグの際に役立ちます。デフォルトでは、型記述子の名前はモデル型の名前（この例ではStdVector）に設定され、その名前は型記述子のすべてのインスタンスで同じになります。使用するテンプレートのインスタンスに対して特殊化を行うことで，より具体的な名前を得ることができます．

なお，すべてのコンパイラが，このような特殊化をヘッダファイルに記述できるわけではありません。

それでは、StdVector型記述子をテストしてみましょう。2つのカプセルを持つサンプルモデルを作成し、1つ目のカプセルから2つ目のカプセルにintのベクターを送信し、2つ目のカプセルから1つ目のカプセルにcharsのベクターを送信します。自分でモデルを作りたくない場合は、添付のモデルを使うことができます。そのモデルを構築して実行すると、このような出力が出力されます。

Reached Cap2 State 1
Reached Cap1 State1 and sending Integer
Success: Received sendInteger event with data at Cap2.
Received: StdVector<int>{1,2,3}
Reached Cap2 State2 and sending Chars
Success: Received sendChar event with data at Cap1.
Received: StdVector<char>{'a','b','c'}
Reached Cap1 State2 and received Chars

2021/4/5 - 読み終える時間: 2 分

Storing Code in Model Files Using CDATA の翻訳版です。

HCL RTist: CDATAを使ったモデルファイルへのコードの格納

ng Code in Model Files Using CDATA profile image Mattias Mohlin Senior Solutions Architect for HCL Software

RTistのモデルは、XMLファイル（.emx、.efx）に格納されています。このようなファイルをテキストエディタで開いたことがある方は、モデルに格納されているコードスニペットが、XMLで義務付けられている特定の文字のエンコーディングのために、非常に読みづらいことに気づかれたことでしょう。以下にその例を示します。

一部のコードスニペットはXMLの属性として格納されており、改行もコードスニペット全体が1行で表示されるようにエンコードされているため、見た目がさらに悪くなります。

RTist 11.0 2020.33からは、コードスニペットがXMLファイルのCDATAセクションに保存されるように設定することができます。これにより、コードをエスケープする必要がなくなり、読みやすさが大幅に向上します。この環境設定は「モデルファイルの保存時にCDATAを使用」というもので、「モデリング」環境設定ページにあります。この設定は、コード・スニペットだけでなく、ドキュメント・テキストの保存方法にも影響します。

この環境設定を設定すると、上記の例のコード・スニペットは次のようになります。

なお、RTistの古いバージョンでも、CDATAを使ったモデルファイルを読むことができます。その意味で、この機能は後方互換性があります。ただし、そのような古いバージョンのツールでモデルを編集して保存すると、コードスニペットは再びCDATAを使用せずに保存されることに注意してください。 モデルファイルにCDATAを使用することにした場合、ワークスペース内のすべてのファイルを新しいフォーマットで使用するために手動で保存し直すのは少々面倒です。簡略化するために、モデルフィクスアップを実行すると、すべてのモデルファイルが自動的にCDATAを使用するように変換されます。

詳細はこちらのビデオをご覧ください。