Real-Time Workshop Release Notes

新機能

本節では、Real-Time Workshop 4.1 以降にReal-Time Workshop 5.0で追加された新機能および強化された機能を紹介します。コード生成に影響を与える多くのSimulinkの機能強化も記述されています。

最新リリースに組み込まれているReal-Time Workshopの機能に関する情報は、Real-Time Workshop 4.1 Release NotesおよびReal-Time Workshop 4.0 Release Notesを参照してください。

注意    Real-Time Workshopを拡張する最新の関連プロダクトに関する情報は、Real-Time Workshop Embedded CoderおよびxPC Targetに関するRelease Noteを参照してください。

Nonvirtualサブシステムに対するコードの再利用

Real-Time Workshop 5.0 は、nonvirtualサブシステムについてコードを再利用するための機能をインプリメントするため、生成コードが変更されています。Real-time Workshop GUIから関数やファイルの名前を指定することと同様に、この機能を選択あるいは変更することができます。

旧リリースにおいて、モデル内のnonvirtualサブシステムは、別々のコードのブロックを生成しました。ある状況においては--たとえば、ライブラリブロックが同じ方法で複数回利用される--ブロックに対して単一の共有関数を生成し、その関数を複数回呼び出すことが可能です。この方法でコードを統合することで、生成されたコードのサイズや高率を大きく改良することができます。

コードの再利用をインプリメントするには、Real-Time Workshop は、再利用されるサブシステムの呼び出し側に対して(関数引数として) 適切なデータ要素を渡さなければなりません。Real-Time Workshop 5.0 によって生成されたコードは、nonvirtualサブシステムに対して生成された関数に対してそのような引数を利用することができます。

下記のように、RTWシステムコードにおいて、ソース元の単位を利用およびReusable functionが選択されているときに、Subsystem parametersダイアログボックスによってコードを再利用することができます。

ある条件においては、Reusable functionを指定しても、Real-Time Workshopが他のRTW system codeオプションに戻るため、コードの再利用が不可能な場合がります。

詳細は、Real Time Workshopドキュメントの"Nonvirtual Subsystem Code Generation"を参照してください。

生成されたコードファイルのパッケージ化の改訂

生成されたコードの.c および.hファイルへのパッケージ化は変更されています。つぎの表は、Real-Time Workshopによって生成されるソースコードの構造をまとめたものです。すべてのコードモジュールは、ビルドディレクトリに書き出されます。

注意    Real-Time Workshop Embedded Coderのファイルのパッケージ化は、ここで記述するファイルのパッケージ化とはわずかに(しかし、はっきりと)異なります。詳細は、Real-Time Workshop Embedded Coder User's Guide の"Data Structures and Code Modules"を参照してください。

Table 1-1: Real-Time Workshopのファイルのパッケージ化

ファイル	詳細
model.c	モデルアルゴリズムをインプリメントするすべてのコードに対するエントリポイントを含みます(MdlStart, MdlOutputs, MdlUpdate, MdlInitializeSizes, MdlInitializeSampleTimes)。モデルレジストレーションコードも含みます。
model_private.h	モデルやサブシステムによって要求されるローカル定義やローカルデータを含みます。このファイルは、モデルで.cファイルによりインクルードされます。モデルの手書きコードとのインタフェースを取る際には、model_private.hをインクルードする必要はありません。 model_private.hは、model.hによってsub-included されることに注意してください。
model.h	モデルのデータ構造やエントリポイントとデータ構造とのパブリックなインタフェースを定義します。また、accessorマクロにより、リアルタイムモデルデータ構造(model_rtM)へのインタフェースを提供します。 model.h は、モデル内でサブシステムの .c ファイルによってインクルードされます。 手書きコードと1つあるいは複数のモデルに対する生成コードとのインタフェースを取る場合は、インタフェースを取りたいモデルに対する model.h をインクルードします。
model_data.c (conditional)	model_data.c は、条件付きで生成されます。パラメータのデータ構造およびconstant block I/Oデータ構造に対する宣言を含みます。これらのデータ構造がモデル内で利用されない場合は、model_data.c が生成されません。これらの構造は、model.hでexternと宣言していることに注意してください。
model_types.h	リアルタイムモデル構造およびパラメータのデータ構造に対するforward宣言を提供します。これらは、再利用可能な関数の関数宣言のために必要な場合があります。model_types.h は、モデル内のすべてのサブシステム.hファイルによりインクルードされます。
rtmodel.h	grt_main.cやgrt_malloc_main.cのようなスタティックメインプログラムモジュールによって要求される#include命令を含みます。これらのモジュールは、コード生成時に作成されないため、モデル固有のデータ構造やエントリポイントにアクセスするためにrt_model.hをインクルードします。ユーザ独自のメインプログラムモジュールを作成する場合は、rtmodel.hをインクルードすることに注意してください。

旧リリースのReal-Time Workshopによって生成されたコードとのインタフェースを行う手書きコードがある場合は、生成されないヘッダファイルへの依存性を除去する必要がある場合があります。#include model.h命令を利用し、以下を意味する#include命令を削除してください。

• model_common.h (model_types.hおよびmodel_private.hにより置き換え)
• model_export.h (model.hにより置き換え)
• model_prm.h (model_data.cにより置き換え)
• model_reg.h (model_.cにより包含)

ほとんどのターゲットは、Root SimStructの代わりにrtModelを利用します。

GRT, GRT-Malloc, ERT, Tornadoターゲットは、ルートモデルに関する情報を格納するためにrtModel データを利用します。旧リリースでは、この情報は、SimStruct データ構造体に格納されました。SimStructデータ構造体は非インラインS-functionsによっても利用されるため、ルートモデル情報を表現するために必要でない多くのS-function固有のフィールドを含んでいました。新規のrtModelは、ルートモデルを表わす未使用のフィールドを除去する軽量のデータ構造体です。rtModel内のフィールドは、タイミング、ソルバ、ロギング、モデルデータ(ブロックI/OやDwork, パラメータのような)等に関連するモデル情報をキャプチャします。 ERTターゲットに対してコードを生成するには、rtModelデータ構造体は、考慮中のモデルに関連するフィールドのみを含むように、さらに余分なものを取り除きます。

注意    以前にカスタマイズしたGRT, GRT-Malloc, Tornadoターゲットをおもちの場合は、SimStructの代わりにrtModelを利用するために、カスタマイズされたターゲットをアップグレードしてください。このアップグレードパスに関するガイドラインは、Upgrading Customized GRT and GRT-Malloc Targets to Work with Release 13にあります。

ターゲット固有のワード特性に対するHookfiles

ワード長やオーバフローの挙動のようなターゲットハードウェア特性と通信を行うために、<target>_rtw_info_hook.mという名前のM-ファイルを与える必要があります。各システムターゲットファイルは、hookファイルをインプリメントする必要があります。たとえば、GRT (grt.tlc)に対して、ファイルはgrt_rtw_info_hook.mという名前で、MATLABパス上になければなりません。hookfileが与えられない場合は、ホストの特性を基にしたデフォルト値が利用され、適切でない場合があります。例題は、toolbox/rtw/rtw/example_rtw_info_hook.mを参照してください。さらに、TLC命令%assign DSP = 1は、影響を与えないことに注意してください。その代わりにhookファイルを与える必要があります。

Conditional Input Branch Execution

本リリースでは、conditional input branch executionと呼ばれる新規の最適化を導入し、モデルから生成されたコードのシミュレーションや実行が高速化されています。従来は、Switch あるいはMultiport Switchブロックを含むモデルをシミュレーションする際には、Simulinkは各時間ステップにおいて、各スイッチに対してすべての入力を計算するために必要はすべてのブロックを実行しました。本リリースでは、デフォルトで、Simulinkは、制御入力と、各時間ステップにおいて制御入力によって選択されたデータ入力を計算するために必要なブロックのみを実行します。同様に、Real-Time Workshopによってモデルから生成されたスタンドアロンアプリケーションは、制御入力と選択されたデータ入力を計算するために必要なコードのみを実行します。

新規のRate Transitionブロック

旧リリースでは、Zero-Order Hold およびUnit Delayブロックは、異なるサンプルレートをもつブロック間でのデータの統合性や、確定的なデータ転送を取り扱う必要がありました。

新規のRate Transitionブロックを使って、マルチレートアプリケーションにおいて、Zero-Order HoldおよびUnit Delayブロックよりも、簡単で、フレキシブルにサンプルレート遷移を扱うことができます。

Rate Transitionブロックは、両方のタイプのレート遷移(fast to slowおよびslow to fast)を取り扱います。異なるサンプルレートをもつ2つのブロックの間に挿入された場合は、Rate Transitionブロックは、2つのレートを検出し、適切な遷移タイプに対する入出力サンプルレートを自動的に設定します。

Rate Transitionブロックは、以下の操作モードをサポートします。

• Protected/Deterministic: デフォルトでは、Rate Transitionブロックは、Zero-Order Hold (fast to slow遷移) あるいはUnit Delay (slow to fast遷移)のように操作し、既存のモデル内のこれらのブロックを、モデルのパフォーマンスを変更することなく置き換えることができます(例外が1つあります。連続ブロックと離散ブロック間の遷移ではZero-Order Holdを利用しなければなりません)

• このデフォルトの操作モードでは、Rate Transitionブロックは、データ転送の統合性とデータ転送が確定的であることを保証します。

• Protected/Non-Deterministic: このモードでは、データの統合性は、レート間で転送されるデータをダブルバッファリングすることにより、保護されます。Rate Transitionからのブロックのダウンストリームは、Rate Transitionブロックに接続するブロックから常に最新の可能なデータを利用します。最大の待ち時間は、速い方のタスクの1サンプル区間以下です。

• このモードの欠点は、非確定的なタイミングと余分なメモリバッファの利用です。このモードの長所は、待ち時間が短いことです。

• Unprotected/Non-Deterministic: このモードは、最も安全でなく、ミッションクリティカルなアプリケーションには推奨されません。このモードの待ち時間は、Protected/Non-Deterministicモードと同じですが、ダブルバッファリングがないため、メモリの必要量は削減されます。

Real-Time WorkshopでのRate Transitionブロックの利用に関する情報は、Real-Time Workshop User's Guide のModels With Multiple Sample Ratesを参照してください。Rate TransitionブロックGUIの利用とそのシミュレーションでの利用に関する情報は、Using Simulink を参照してください。

S-Function APIはReal-Time Workshop DWorkプロパティを定義可能なように機能強化されています

S-Function APIは、S-Functionが作成する各々のdWorkに対するReal-Time Workshop識別子、ストレージクラス、タイプ識別子の指定が可能なように機能強化されています。強化部分は、以下のマクロで構成されます。

• ssGetDWorkRTWIdentifier(S,idx), ssSetDWorkRTWIdentifier(S,idx,val)
• ssGetDWorkRTWStorageClass(S,idx)
• ssSetDWorkRTWStorageClass(S,idx,val)
• ssGetDWorkRTWTypeQualifier(S,idx)
• ssSetDWorkRTWTypeQualifier(S,idx,val)

data store memoryまたは離散ブロックの状態をもつ場合は、Real-Time Workshop識別子は、Simulink.Signalオブジェクトを解除する場合があります。例題は、"その他"カテゴリのsfundemosに追加されています。

生成コードに対する識別子作成が簡略化されています

変数や関数の識別子の作成のためにReal-Time Workshopが用いる方法は、機能強化されており、識別子はわかりやすく、カスタマイズしやすくなっています。この機能強化の結果として、以下のことが行われています。

• モデルのセクションへの変更により、識別子は別の位置へ変更しません。
• 再利用される関数の入力引数は、inportブロックからそれらの名前を取得します。
• サブシステム関数名は、名前の重複によるリンクエラーを回避するため、モデル名が先頭に付加されます。
• ユーザは、最長の識別子を指定することができます(> 31 キャラクタ)。
• 識別子内にデータタイプの頭文字を含めるための新規オプションがあります。
• 名前の重複を回避するための、識別子の接尾辞_a, _b, ... の利用が、大幅に削減されています。

Lookup Tableブロックは、小さいコードに対して新規のRun-time Libraryを利用します

Lookup Table (2-D) およびLookup Table (3-D) ブロックは、Real-Time Workshopランタイムライブラリで多くの新規の最適化された固有のlook-up table操作をターゲットとするCコードを生成します。これにより、コードサイズが大幅に小さくなります。ライブラリルックアップ関数は、ほとんどのオプション設定、特に線形内挿に対して、速度を改良するため、実際のルックアップアルゴリズム用に強化された機能を組み込んでいます。

Expression folding APIのドキュメントが利用可能です

Expression folding APIはドキュメント化され、特に、手書きのインラインS-Functionに対して、カスタマが利用することを奨励しています。さらに、%roll命令内でのTLCユーザ制御変数(ucv)をサポートする拡張機能が利用可能で、Selectorのようなブロックに対して式を折りたたむことができます。Real-Time Workshop documentationの "Supporting Expression Folding in S-Functionsを参照してください。

Relayブロックはフレームベース処理をサポートします

Relayブロックは、フレームベースの入力信号を取り扱うことができます。フレームベース入力信号内の各行は、フレーム内の別々のサンプルで、各列は異なる信号チャネルを表わします。ブロックパラメータは、信号チャネル数と等しい長さのスカラまたは行ベクトルです。ブロックは、連続フレームベース入力信号は利用できません。

Rapid Simulation Targetは、可変ステップソルバをサポートします

Rapid Simulation (RSIM) targetに対して生成される実行モジュールは、可変ステップソルバを含むSimulinkソルバモジュールを利用することができます。この機能を利用するには、ターゲットは、生成されたRSIM実行モジュールの実行時に、Simulinkライセンスをチェックする必要があります。(すなわち、固定ステップソルバのみ, with no need to check out a Simulink license) Rapid Simulation code generation optionsダイアログのUse Simulink solver moduleオプションの選択を外すことにより、下位互換性を維持することができます。

ERTに対するエクスターナルモードのサポートの追加

Real-Time Workshop Embedded Coderは、Simulinkのエクスターナルモードのすべての機能をサポートします。エクスターナルモードを使って、Simulinkブロック線図を、外部ハードウェア上で動作する、あるいはホストコンピュータ上の別のプロセスで、ターゲットプログラムのフロントエンドとして利用し、パラメータをチューニングし、信号をターゲットプログラムの実行に従って、表示またはロギングすることが可能です。

エクスターナルモードはすべてのストレージクラスの信号のアップロードをサポートします

customを含むすべてのストレージクラスの信号は、エクスターナルモードでアップロードすることができます。

Transport DelayおよびVariable Transport Delayの改良

Transport DelayおよびVariable Transport Delayを含むモデルに対するコード生成は、より容量的に効率化されています。

LCCは、ディレクトリsys/lcc/libにライブラリをリンクします

template makefilesは、sys/lcc/libに対してのリンクを含むように更新されています。

Real-Time WorkshopとStateflowのコード生成の統合

旧リリースでは、モデル内のStateflowチャートから生成されたコードは、(model.c, model.h等のような)モデルの残り部分から生成されるソースコードファイルとは別に、ソースコードファイルに書き出されました。

現在は、デフォルトで、StateflowはReal-Time Workshopと別のファイルを生成しません。さらに、Stateflowの生成コードは、別の生成コードとシームレスに統合されます。たとえば、すべてのStateflow初期化コートはインライン化されます。

デフォルトを変更して、Stateflowチャートに対しては、Real-Time Workshopで別のコードファイル内で別の関数を生成するように指定することができます。そのためには、StateflowチャートのBlock parametersダイアログのRTWシステムコードオプションを利用します(Real-Time WorkshopのNonvirtual Subsystem Code Generationを参照)。関数名と生成されたコードファイルの名前を設定することができます。

すべてのターゲットで可能なGenerate HTML Reportオプション

従来のリリースでは、Generate HTML reportオプションは、Real-Time Workshop Embedded Coderに対してのみ利用可能でした。現在のリリースでは、レポートは、(except the S-Function targetとRapid Simulation target以外の)すべてのターゲットに対して利用可能です。

Generate HTML reportオプションは、下記の図のように、シミュレーションパラメータダイアログボックスのReal-Time Workshop ページのGenerate code generation optionsカテゴリにあります。

このオプションは、デフォルトでonです。

Data Store Memoryブロックに対するストレージクラス

モデル内のData Store Memory blocksは生成コード内で格納、表現される方法は、ストレージクラスとタイプ識別子を割り当てることによって制御することができます。これは、ブロックの状態に対してストレージクラスやタイプ識別子を割り当てるのとほとんど全く同じ方法で行います。Data Store Memoryブロックとsignalオブジェクトを関連付け、signalオブジェクトによってブロックのコード生成を制御することも可能です。

詳細は、Real-Time Workshop User's Guide のStorage Classes for Data Store Memory Blocksを参照してください。

定数パラメータに対するマクロの定義

定数パラメータがインライン化され、チューニング不可能と宣言されているとき、つぎのコード生成オプションが利用できます。

• ベクトルパラメータは、従来はrtPベクトルに定数パラメータとして格納されました。現在は、適切なタイプの定数ベクトルとして宣言されます。
• スカラパラメータは、従来は文字としてインライン化されました。これに加えて、現在は、スカラパラメータを#defineマクロ定義として表現するオプションをもちます。

インラインパラメータに対するコードスタイルの制御は、Real-Time WorkshopダイアログボックスのGeneral code generation options (cont.)カテゴリにある、新規プルダウンメニューGenerate scalar inline parameters as: [literals | macros]を使って調べます。

複数のサブグループに再構成された診断ページ

診断の選択を簡素化するために、シミュレーションパラメータダイアログの診断ページは、以下のように、各グループ内で機能、およびアルファベット順に再構成されています。

TLC %assert命令の実行に対するGUI制御

従来のバージョンでは、TLCの%assert命令を実行するために、-da Target Language Compilerコマンドラインフラグの指定が必要でした。現在は、Real-Time WorkshopダイアログページのTLCデバッグのEnable TLC Assertionsボックスをチェックすることによって、簡単に%assert コードをトリガすることができます。デフォルトの状態は、assertsを実行しません。assertionの取り扱いは、MATLABコマンドウィンドウからも制御できます。

set_param(model, 'TLCAssertion', 'on|off')は、設定または設定の解除を行います。デフォルトはOffです。

get_param(model, 'TLCAssertion')は、現在の設定を表示します。

組み込み関数SPRINTFのTLCへの追加

Cライクなsprintf書式化関数が追加され、変数引数からデータを使って符号化されたTLC文字列を出力します。

$assign str = SPRINTF(format,var,...) は、指定したformat文字列の制御の基に、変数var (およびその他の変数引数内)のデータを書式化し、値を含む文字列変数を出力します。出力がsprintfの引数に含まれるのでなく、戻り値であること以外は、Cライブラリsprintf()のように機能します。

関数BlockInstanceDataは利用しません

S-function TLCファイルは、BlockInstanceDataメソッドを利用しません。ブロックが利用するすべてのデータは、データタイプ作業ベクトル(DWork)を利用して宣言されます。

ドキュメントの機能強化

Real-Time Workshop

Real-Time Workshop User's Guideは、Version 5.0 では、大きく更新および再構成されています。データ構造体やサブシステムに関する情報が追加され、アクセスしやすくなっており、新機能やGUIの変更点がドキュメント化されています。さらに、新規の印刷版およびオンラインの紹介版Getting Started with Real-Time Workshopが存在します。このドキュメントは、基本的なReal-Time Workshopの概念を説明し、アクセスしやすいチュートリアル、User's Guideではより詳しく説明されているクロスリファレンスで構成されます。

Target Language Compiler

Target Language Compiler Reference Guideは、Version 5.0 では大きく更新され、再構成されています。改訂されたチュートリアルの例により新規ユーザはTLCシンタックスのより基本的な紹介を得ることができます。TLC関数ライブラリとmodel.rtwファイルの内容に関するドキュメントも更新されています。

Real-Time Workshop 5.0

メジャーバグフィックス