AUTOSAR Architecture and Behavior Modeling: Interaction Between SystemDesk and TargetLink

Transcription

1 TargetLink AUTOSAR ガイドライン TargetLink を使用した AUTOSAR ソフトウエアコンポーネントのインプリメンテーションガイドライン TargetLink 3.2/TargetLink 3.1 第 1.1 版 2011 年 3 月

2 文書改訂記録 日付版執筆者セクション改訂理由 Ulrich Eisemann すべて初稿作成 Ulrich Eisemann すべて初版完成 Ulrich Eisemann すべて 細かい訂正 変数の初期化に関する補足説明 SWC コンテナのやり取りに関するガイドラインを追加

3 dspace へのお問い合わせ 住所 : 東京都品川区北品川 御殿山トラストタワー 10 階 Tel.: Fax: info@dspace.jp Web: dspace サポートへのお問い合わせ dspace サポートへの問い合わせには 以下のさまざまな方法があります dspace ウェブサイト 電子メール support@dspace.jp dspace Support Wizard: dspace DVD に格納されている \Diag\Tools\dSPACESupportWizard.exe を実行する [ スタート ] [ プログラム ] [dspace Tools](dSPACE ソフトウエアが既にインストールされている場合 ) 以下のサイトから いつでも最新の dspace Support Wizard をダウンロードすることができます dspace サポートへのお問い合わせには dspace Support Wizard の使用をお勧めいたします ソフトウエアのアップデートとパッチ 既存の dspace インストレーションに対して 最新のパッチをダウンロードしてインストールすることを強くお勧めします ソフトウエアのアップデートとパッチについては 以下のサイトをご覧ください 重要なお知らせ 本書には 著作権法により保護された専有情報が含まれています すべての権利は留保されています dspace GmbH の書面による事前の許可なく 本出版物またはソフトウエアのすべてもしくは一部を コピー 複製 翻訳 または電子的媒体もしくは機械可読形式に変換することを禁じます Copyright : dspace GmbH Rathenaustraße Paderborn Germany AutomationDesk CalDesk ConfigurationDesk ControlDesk SystemDesk および TargetLink は 米国 その他の国 またはその両方における登録商標です その他のブランド名または製品名は その企業または組織の商標または登録商標です 本出版物と内容は 予告なく変更されることがあります dspace GmbH および dspace Japan は 本出版物に関して 商品性または特定目的に対する適合性の保証を含め明示であると黙示であるとを問わずその他一切の保証を行いません dspace GmbH および dspace Japan は 本出版物に含まれる誤りや 本出版物に記載された内容に関連し それを実行または使用した結果として被った直接的 間接的 特殊的 付随的もしくは結果的損害に対して一切責任を負いません TargetLink AUTOSAR ガイドライン 1.1 3

4 目次 目次 概要 本書の内容 バージョンの依存関係 コンテンツと関連ドキュメント ブロック線図レベルでのモデリング 一般的な AUTOSAR コード生成設定 SWC と SWC のインターナルビヘイビアの一般的なモデリングスタイル アトミックソフトウエアコンポーネントと TargetLink サブシステム ランナブルのモデリング ランナブルの境界での TargetLink Inport/Outport の使用 ランナブルおよび RTE イベントの起動 SWC Sender/Receiver ブロックの使用 同期型クライアント / サーバ通信のクライアントのモデリング AUTOSAR に関連する信号の初期化 SWC 内部での AUTOSAR に関連しない信号の初期化 Data Dictionary でのモデリング あらかじめ設定する Data Dictionary の仕様 AUTOSAR に関連する Data Dictionary オブジェクトの名前 Data Dictionary での AUTOSAR に関連するデータの構成 Data Dictionary オブジェクトへの AUTOSAR パッケージの割り当て パッケージサポートによる ARXML のインポート / エクスポートの実行 AUTOSAR プロジェクトでのタイプのモデリング Data Dictionary での AUTOSAR スケーリングの指定 (CompuMethods) Data Dictionary での AUTOSAR ユニットの指定 Data Dictionary でのセンダ / レシーバインターフェースの指定 Data Dictionary でのクライアント / サーバインターフェースの指定 Data Dictionary でのインターランナブルバリアブルの指定 制限事項 ソフトウエアコンポーネントテンプレートのサポート対象の制限 AUTOSAR コンポジションの取り扱い ソフトウエアコンポーネントの複数インスタンスは利用不可 イベントセマンティクスを使用するセンダ / レシーバ通信のシミュレーションサポートの制限 AUTOSAR SWC のモデリングとモデルリファレンス機能...49 TargetLink AUTOSAR ガイドライン 1.1 4

5 5 SystemDesk と TargetLink の間で SWC コンテナをやり取りするためのガイドライン SystemDesk と TargetLink の一般的なガイドライン ワークフロー規則の指定 SWC コンテナをやり取りするためのコンテナ設定ファイルの使用 SWC コンテナをやり取りするための SystemDesk のガイドライン ソフトウエアコンポーネントのパッケージへの分割 SystemDesk プロジェクトでのすべてのオブジェクトのパッケージの割り当て 共有データとコンポーネント固有のデータの分離 AUTOSAR パッケージのファイル名 SystemDesk のワークフロー規則の指定 SWC コンテナをやり取りするための TargetLink のガイドライン ソフトウエアコンポーネントと TargetLink サブシステム TargetLink のワークフロー規則の指定 参考資料一覧...62 TargetLink AUTOSAR ガイドライン 1.1 5

6 標準インターフェース TargetLink AUTOSAR ガイドライン 1 概要 本書では TargetLink で AUTOSAR ソフトウエアコンポーネント (SWC) をモデリングおよび実装する TargetLink ユーザ向けのガイドラインを紹介します TargetLink は Simulink /Stateflow /TargetLink でモデリングした制御ファンクションを非常に効率的な C コードの形式で実装するための量産コード生成ツールです TargetLink は特に AUTOSAR ソフトウエアコンポーネントの形式でモデルを実装する AUTOSAR ユースケースをサポートしています AUTOSAR ソフトウエアコンポーネントは dspace SystemDesk などで設計されたソフトウエアアーキテクチャの個々の要素を構成しています AUTOSAR ソフトウエアのアーキテクチャと TargetLink が対応している各部分の図を図 1 に示します なお TargetLink でサポートされるのは AUTOSAR ソフトウエアのアーキテクチャのアプリケーション層のみです TargetLink は RTE 生成ツールにはなりません TargetLink アプリケーションソフトウエアコンポーネントインプリメンテーション アプリケーションソフトウエアコンポーネント AUTOSAR インターフェース アクチュエータソフトウエアコンポーネント AUTOSAR インターフェース センサソフトウエアコンポーネント AUTOSAR インターフェース AUTOSAR ソフトウエア アプリケーションソフトウエアコンポーネント AUTOSAR インターフェース AUTOSAR ランタイム環境 (RTE) 標準インターフェース AUTOSAR 標準インターフェース 標準インターフェース AUTOSAR インターフェース AUTOSAR インターフェース サービス 通信 ECU アブストラクション オペレーティングシステム 標準インターフェース 標準インターフェース 標準インターフェース コンプレックスデバイスドライバ ベーシックソフトウエア 標準インターフェース マイクロコントローラアブストラクション ECU ハードウエア 図 1:AUTOSAR ソフトウエアのアーキテクチャ内の TargetLink が対応している各部分 :TargetLink は AUTOSAR SWC のビヘイビアをモデリングし インプリメンテーションを実現するためにのみ使用されます AUTOSAR の方法論に従うと アーキテクチャや dspace SystemDesk などの AUTOSAR オーサリングツールとビヘイビアモデリングツール TargetLink は AUTOSAR 標準 ARXML ファイルをやり取りすることによって連携します 図 2 を参照してください 図の中の重要なエレメントは AUTOSAR ソフトウエアコンポーネントの内容を記述するソフトウエアコンポーネントテンプレートです SystemDesk ユーザは ソフトウエア設計者の役割を担い ソフトウエア全体を多数のソフトウエアコンポーネントに分解し これらのソフトウエアコンポーネントが互換性のあるインターフェースを通して相互に通信を行うことを確認します ソフトウエア設計者は一般的に TargetLink を使用する複数のファンクション / ソフトウエア開発者と ARXML ファイルをやり取りし 個々のソフトウエアコンポーネントのインプリメンテーションを実現します 図 2 を参照してください TargetLink を使用すると ソフトウエアコンポーネントを実装するだけではなく Simulink/TargetLink 環境において通常の方法でソフトウエアコンポーネントをテストすることもできます 一般的に ソフトウエアコンポーネントの開発は SystemDesk や TargetLink などのツール間で何度が ARXML ファイルをやり取りし 変更を調整する反復的なプロセスです TargetLink AUTOSAR ガイドライン 1.1 6

7 ソフトウエアアーキテクチャハードウエアトポロジネットワーク通信 OS コンフィギュレーション RTE 生成 SWC デスクリプション 機能設計機能シミュレーション機能実装 AUTOSAR 準拠 SWC デスクリプション ECU 設定 RTE コード SWC コード 図 2:AUTOSAR ツールチェーンでの TargetLink の使用 dspace SystemDesk は一般的に AUTOSAR ツールチェーンで TargetLink と組み合わせて使用されるので AUTOSAR アーキテクチャツールと見なすことができます TargetLink と AUTOSAR アーキテクチャツールは AUTOSAR 標準 XML 形式に基づく SWC デスクリプションファイルをやり取りします TargetLink 3.2 と SystemDesk 3.0 の両ツールは AUTOSAR ARXML ファイルのやり取りをサポートするだけではなく いわゆる SWC コンテナをやり取りすることによってより簡単で効率的かつ分かりやすい方法で AUTOSAR ソフトウエアを開発する手段を提供します 図 3 を参照してください 本書のガイドラインは両方のアプローチに対して有効です TargetLink と SystemDesk の間で SWC コンテナをやり取りするためのガイドラインについては 特に本書の第 5 章で説明します 第 5 章の大部分では SystemDesk が TargetLink と SWC コンテナを適切にやり取りするためのガイドラインを紹介します 1.1 本書の内容 本書の規則では AUTOSAR ソフトウエアコンポーネントのモデリング AUTOSAR 準拠コードの生成 および AUTOSAR ソフトウエアコンポーネントデスクリプションファイルについて説明します 本書は以下の章で構成されています 第 2 章では ブロック線図レベルでの AUTOSAR SWC のモデリング つまり TargetLink AUTOSAR ライブラリのブロックを使用する方法に関するガイドラインを紹介します 第 3 章では Data Dictionary 内の AUTOSAR に関連するデータの指定に関するガイドラインを紹介します この章は 特に AUTOSAR に関連する多くのデータを ARXML ファイルからインポートするのではなく手作業で Data Dictionary 内に作成する場合にお読みください 第 4 章では TargetLink で AUTOSAR SWC をモデリングする場合の制約について説明します 第 5 章の大部分では SystemDesk が TargetLink と SWC コンテナを適切にやり取りするためのガイドラインを紹介します この章は SystemDesk と TargetLink 間で SWC コンテナをやり取りして AUTOSAR 準拠の開発を行う場合のみお読みください TargetLink AUTOSAR ガイドライン 1.1 7

8 SWC コンテナ SWC コンテナのエクスポート SWC コンテナのインポート SWC コンテナ SWC コンテナのインポート SWC コンテナのエクスポート 図 3:AUTOSAR 準拠のソフトウエアをより快適に開発する手段としての SystemDesk と TargetLink 間での SWC コンテナのやり取り ユーザは 個々の AUTOSAR XML ファイルをやり取りする代わりに 単に SWC コンテナをインポートまたはエクスポートすることができます.c や.h などのその他の実装ファイルは 自動的に処理されます 1.2 バージョンの依存関係 本書の規則は TargetLink 3.1 以降の TargetLink に適用されます ただし それ以前のバージョンでこれらの規則が役立つ場合もあります TargetLink AUTOSAR のサポートを利用するには TargetLink AUTOSAR Module(TAS) が必要です 1.3 コンテンツと関連ドキュメント 本書で紹介する TargetLink AUTOSAR ガイドライン以外にも TargetLink で SWC を実装するために有用な情報を提供する以下のドキュメントがあります すべての TargetLink インストレーションに含まれる通常の TargetLink AUTOSAR Modeling Guide AUTOSAR の機能と TargetLink がこれらの機能をサポートする範囲の詳細なリストを含む Excel シート この Excel の表は TargetLink サポート から入手することができます 追加のアプリケーションノートや TargetLink AUTOSAR ユーティリティ TargetLink AUTOSAR オンラインセミナーなどに関するその他の資料は 以下の URL の TargetLink 製品サポートセンターからダウンロードすることができます TargetLink AUTOSAR ガイドライン 1.1 8

9 2 ブロック線図レベルでのモデリング この章では TargetLink で AUTOSAR SWC を開発する場合のブロック線図レベルに関するガイドラインを紹介します 2.1 一般的な AUTOSAR コード生成設定 TargetLink で AUTOSAR SWC を設計および実装するには TargetLink のメインダイアログの [Code generation mode] オプションに [AUTOSAR] を設定します 目的 TargetLink を使用した SWC のモデリング 例必要な [Code generation mode] の設定を図 4 に示します この設定は TargetLink のメインダイアログで行うことができます 図 4:AUTOSAR ソフトウエアコンポーネントを開発するには [Code generation mode] に [AUTOSAR] を設定します 2.2 SWC と SWC のインターナルビヘイビアの一般的なモデリングスタイル SWC の開発でしばしば使用されるモデリングスタイルでは Simulink ファンクションコールを使用して RTE イベントをモデリングします この RTE イベントはスケジューラとして機能する独立した Stateflow チャートから提供されます ランナブルは Stateflow チャートによって起動されたファンクションコールトリガサブシステムとしてモデリングされます 目的 TargetLink を使用した SWC のモデリング TargetLink AUTOSAR ガイドライン 1.1 9

10 例 TargetLink のデモモデル ar_poscontrol は このセクションで説明するガイドラインに準拠したモデリングスタイルの例です 図 5 は このデモモデルの TargetLink サブシステムを示しています 図 5: モデリングスタイルの例 TargetLink サブシステムの最上層にある SWC の内部を表しています (TargetLink の ar_poscontrol デモモデルを参照 ) ランナブルは Simulink ファンクションコール (RTE イベントをシミュレート ) によって起動され SWC Sender/Receiver ブロックが TargetLink サブシステム内の通常の TargetLink ポートの代わりに使用されています したがって SWC Sender/Receiver ブロックは SWC の実際の AUTOSAR ポートに相当します ソフトウエアコンポーネントのランナブルの外部で関数ブロックは使用されていません 2.3 アトミックソフトウエアコンポーネントと TargetLink サブシステム TargetLink サブシステムに対する AUTOSAR ソフトウエアコンポーネントのマッピングについては 次の 2 つの方法が利用できます 1. 1 つの TargetLink サブシステム内で すべてのランナブルを含む AUTOSAR ソフトウエアコンポーネントを 1 つだけモデリングする ( つまり その TargetLink サブシステム内に 他の AUTOSAR ソフトウエアコンポーネントは存在しない ) 2. 1 つの TargetLink サブシステム内で 複数の SWC をすべてモデリングする ( つまり その TargetLink サブシステム内に 複数の SWC のすべてのランナブルが存在する ) そのため 1 つのソフトウエアコンポーネントを異なる複数の TargetLink サブシステムに分割することはお勧めしません ( 図 6 を参照 ) SWC のランナブルに加えて いずれのランナブルにも属さないモデルフラグメントを TargetLink サブシステムの一部にすることができます ただし これらのモデルフラグメントは Simulink のシミュレーションでしか使用できません これは ランナブルの内容のみが SWC のコードとなり AUTOSAR アプリケーションの一部として使用できるためです アトミックソフトウエアコンポーネントは モデル内の 1 つのサブシステムまたはブロックの形式で直接的に表現する必要はありません モデリングするのはその SWC に属するランナブルで そのランナブルの内容が SWC の機能を構成します 目的 TargetLink を使用した SWC のモデリング TargetLink AUTOSAR ガイドライン

11 例図 6 は 同じ SWC の異なるランナブルを異なる TargetLink サブシステムに分割する許容されない設定例を示しています 図 7 は 2 つのランナブルで構成される SWC の典型的なモデリングスタイルを示しています ランナブル以外の関数ブロックは SWC には含まれず Simulink のシミュレーションのみで機能します 図 6: 同じソフトウエアコンポーネントのランナブル ( この図では SWC1) を異なる TargetLink サブシステム ( この図では TargetLink_Subsystem_1 と TargetLink_Subsystem_2) に分割することはできません 1 つの SWC の構成要素は 1 つの TargetLink サブシステムでしか使用できません 図 7: TargetLink サブシステムのルートレベル :1 つまたは 2 つの SWC に属する 2 つのランナブル (Controller_Runnable と Position_Linearization_Runnable) の他に (Gain という名前の )Gain ブロックが 1 つ含まれています この Gain ブロックはランナブルの外部にあるため SWC には含まれません そのため この Gain ブロックは Simulink でのシミュレーション (MIL SIL および PIL モード ) でしか機能しません TargetLink AUTOSAR ガイドライン

12 2.4 ランナブルのモデリング ランナブルのモデリングでは 以下のガイドラインに留意する必要があります ランナブルは TargetLink Function/Runnable ブロックを含む Simulink サブシステムで表す必要があります Function/Runnable ブロックの [Implement subsystem as runnable] オプションをチェックする必要があります ランナブルを含むサブシステムには任意の数の他のサブシステムを含めることができます これらのサブシステムで TargetLink の Function ブロックを使用することもできます AUTOSAR 規格でサポートされていないため ランナブルをネスト構造にすることはできません ただし 従来のサブファンクションをいくつでも含めることができます ランナブルサブシステムがアトミックサブシステムか ファンクションコールでトリガされるサブシステムか または有効もしくはエッジでトリガされるサブシステムかは ユーザが指定します アトミックサブシステムやファンクションコールでトリガされるサブシステムを使用するモデリングスタイルが 最も一般的な手法です ただし ランナブルサブシステムの起動は SWC のコードには影響しません Simulink の MIL/SIL/PIL モードでのシミュレーションにのみ使用されます 一般的に TargetLink サブシステムのルート階層をランナブルとして指定することは推奨されません ルート階層よりも下位のサブシステムを使用するようにしてください 目的 TargetLink を使用した SWC のモデリング 補足説明コードの生成を行うと 各ランナブルごとに C 関数が生成されます ランナブルサブシステムの外部に存在するモデルフラグメントは SWC の構成エレメントにはなりません ( 図 7 を参照 ) これらのモデルフラグメントのコードも生成されますが Simulink シミュレーションでしか機能しません 例図 8 はシンプルなランナブルの基本構造を示しています サブシステムを AUTOSAR ランナブルにするには 図 9 で示されているように Function/Runnable ブロックで [Implement subsystem as runnable] オプションを選択する必要があります 図 10 はランナブルをネストする許容されない設定例を示しています 図 8:Runnable ブロック ( 緑 ) が存在するため このサブシステムはランナブルになります ランナブルサブシステムに入力される またはランナブルサブシステムから出力されるすべての信号は TargetLink の Inport および Outport に直接接続する必要があります Inport および Outport は センダ / レシーバ通信 クライアント / サーバ通信 インターランナブル通信などの何らかの種類の AUTOSAR 通信メカニズムを指定する必要があります TargetLink AUTOSAR ガイドライン

13 図 9: サブシステムを AUTOSAR ランナブルとして実装するための [Implement subsystem as runnable] チェックボックスを指定する必要があります 図 10: ランナブルをネストできない設定例 Runnable ブロックを持つサブシステムに 別の Runnable ブロックを持つ別のサブシステムが含まれています このモデリングスタイルは AUTOSAR に準拠していません ただし ランナブルには通常のファンクション仕様を持つサブシステムをいくつでも含めることができます TargetLink AUTOSAR ガイドライン

14 2.5 ランナブルの境界での TargetLink Inport/Outport の使用 ランナブルに対する入出力信号 ( トリガポートは除く ) については 以下のガイドラインを順守してください ランナブルサブシステムに対するすべての入力データ信号は Simulink Inport ブロック以外のブロックに接続する前に TargetLink Inport に接続する必要があります TargetLink Inport は ランナブルサブシステムのルートレベルまたはそれ以下のサブシステムで直接使用します どのような場合も 信号は Simulink Inport ブロック以外のブロックに入力される前に TargetLink Inport を通る必要があります ランナブルサブシステムに対するすべての出力データ信号は Simulink Outport ブロック以外のブロックに接続した後で TargetLink Outport に接続する必要があります TargetLink Outport は ランナブルサブシステムのルートレベルまたはそれ以下のサブシステムで直接使用します どのような場合も 信号はランナブルサブシステムから出力される前に TargetLink Outport ブロックを通る必要があります ランナブルに対するすべての入出力信号は データエレメント オペレーション引数 インターランナブルバリアブルなどの AUTOSAR RTE マクロを介して読み書きされる信号です このため [Use AUTOSAR communication] オプションを選択して これらの信号の TargetLink Inport/Outport ブロックで AUTOSAR 通信メカニズムを指定する必要があります 状況によっては AUTOSAR 規格から外れて ランナブル内部のグローバル変数などとの読み書きを行うほうが好ましい場合もあります このような場合は [Use AUTOSAR communication] オプションとグローバル StrictRunnableInterfaceChecks コード生成オプションの選択を解除してください ファンクションコールイベントは AUTOSAR 規格に準拠していないので 必ず通常の Simulink Inport ではなく Trigger ポート経由でランナブルサブシステムに入力する必要があります 同様に ファンクションコールイベントはランナブルサブシステム内から出ないようにする必要があります ただし ランナブルそのものをファンクションコールトリガサブシステムにすることはできます また ランナブルの境界を越えない場合には ランナブル内のブロックからファンクションコールイベントを提供することも可能です 目的 TargetLink を使用した SWC のモデリング 補足説明状況によっては AUTOSAR 規格から外れて ランナブル内部のグローバル変数などとの読み書きを行うほうが好ましい場合もあります StrictRunnableInterfaceChecks オプションを選択していない場合は TargetLink でこの種類のモデリングを実行することができます 例図 11 は TargetLink の Inport/Outport の適切な使用例を示しています ( ランナブルレベル自体で直接使用またはサブシステム内で使用 ) TargetLink ポートでランナブルのインターフェース信号が適切に定義されていないので ランナブルのモデリング設定を行えない例を図 12 に示します 図 13 は TargetLink Inport ブロックでの AUTOSAR 通信メカニズムの指定を示します 図 14 は AUTOSAR 以外の信号もランナブルサブシステムに対して入出力するための StrictRunnableInterfaceChecks コード生成オプションを示します 図 15 では ファンクションコールイベントがランナブルの境界を横切っています このようなモデリングは許容されません TargetLink AUTOSAR ガイドライン

15 図 11: ランナブルでの TargetLink Inport/Outport の適切な使用 ランナブルに対する入出力信号はすべてランナブルに対する入出力の前に TargetLink Inport/Outport 経由で接続する必要があります ランナブルサブシステムと TargetLink ポートの境界の間では Simulink Inport/Outport を使用することができます 図 12: ランナブルサブシステムに対する入出力信号の不適切な使用 In1 入力信号は TargetLink Inport ブロックで適切に指定される前のルックアップテーブルブロックの入力信号です 同様に In1 および In2 入力信号は TargetLink Inport ブロックで適切に指定される前に多重化されます また Look-up Table ブロックによって生成される Out1 出力信号は TargetLink Outport ブロックでは適切に指定されません TargetLink AUTOSAR ガイドライン

16 図 13: ランナブルのサブシステムに対するすべての入出力信号に対して AUTOSAR 通信メカニズムを指定する必要があります センダ / レシーバ クライアント / サーバ またはインターランナブル通信の場合は [Use AUTOSAR communication] チェックボックスを選択してください Per Instance Memory を経由した通信の場合は [Use AUTOSAR communication] チェックボックスを選択せず ダイアログの [Output] タブで Per Instance Memory 変数を選択します 図 14 : StrictRunnableInterfaceChecks コード生成オプションの選択を解除すると ランナブル内部で AUTOSAR 以外の変数にアクセスできるようになります このオプションはデフォルトとして設定されています TargetLink AUTOSAR ガイドライン

17 図 15:AUTOSAR 規格に準拠しないため Function-Call Generator ブロックからランナブルにファンクションコールイベントを入力することはできません 同様に ランナブルからファンクションコールイベントを出力することもできません ただし ランナブル内部ではファンクションコールをいつでも使用することができます 2.6 ランナブルおよび RTE イベントの起動 Simulink(MIL/SIL/PIL モード ) でランナブルを正しくシミュレーションするには Simulink のセマンティクスに従ってランナブルの起動を ( 正しい順序で ) モデリングする必要があります ランナブルがファンクションコールトリガサブシステムになる場合には 正しい Simulink シミュレーションを行うために モデル内のファンクションコールでランナブルの実行をトリガする必要があります ファンクションコールのイニシエータ (Stateflow チャートや Function-Call Generator ブロックなど ) は SWC には含まれません ランナブルが通常の Simulink サブシステムになる場合 ( ランナブルが TIMING_EVENT でトリガされる場合の妥当なモデリングスタイルなど ) ランナブルの実行 ( およびその順序 ) はデータフローに基づきます (Simulink では一般的 ) RTE イベントの指定は Simulink シミュレーションには影響しませんが ECU で稼働する実際の AUTOSAR アプリケーションではランナブルの起動を定義します 目的 Simulink での SWC のシミュレーション 補足説明 Simulink(MIL/SIL/PIL モード ) での起動は ランナブルの RTE イベントの指定と区別する必要があります RTE イベントの指定は Simulink シミュレーションや生成コードには影響しませんが SWC デスクリプションファイルに書き込まれ RTE ジェネレータによって実際の AUTOSAR アプリケーションでランナブルを正しく起動するのに使用されます TargetLink AUTOSAR ガイドライン

18 2.7 SWC Sender/Receiver ブロックの使用 SWC Sender/Receiver ブロックの使用はすべて任意です SWC Sender/Receiver ブロックの目的は モデリングレベルで AUTOSAR ポートを適切に表すことです SWC Sender/Receiver ブロックを使用する場合は 次の規則を順守してください SWC Sender/Receiver ポートはランナブルの外部に配置します SWC のランナブルの内部の SWC Sender/Receiver ポートと対応する TargetLink Inport/Outport ブロック間では SL ポートと Bus Creator/Selector/Mux/Demux ブロックだけを使用します これ以外のブロックを使用した場合は SWC Sender/Receiver ブロックを AUTOSAR ポートとして解釈することができません 双方向のクライアント / サーバ通信 ( 入力および出力引数を使用するクライアント / サーバオペレーション ) には SWC Sender/Receiver ポートを使用しないでください 目的 TargetLink を使用した SWC のモデリング 補足説明 SWC Sender/Receiver ポートはモデルレベルで AUTOSAR ポートを適切に表します 例図 16 は tl_autosar_lib ライブラリの SWC Sender/Receiver ブロックを示します 図 17 は AUTOSAR ポートを表すためにモデルで SWC Sender/Receiver ブロックを使用する一般的なモデリングスタイルを示します 図 16:TargetLink AUTOSAR ライブラリの SWC Sender/Receiver ブロック ブロックの使用はオプションです TargetLink AUTOSAR ガイドライン

19 図 17: モデルレベルでの SWC Sender/Receiver ブロックの使用例 AUTOSAR ポートは Data Dictionary で指定します それぞれの AUTOSAR ポートは SWC Sender/Receiver ブロックのブロックダイアログから参照されます 2.8 同期型クライアント / サーバ通信のクライアントのモデリング TargetLink は 同期型クライアント / サーバ通信のクライアントのモデリングを以下の異なる 2 つの方法でサポートしています クライアント / サーバインターフェースのオペレーションが双方向 つまり 入力と出力を含む場合 アプリケーションエラーを返す場合 またはオペレーション引数のいずれかが構造体の場合は オペレーションコールサブシステムを使用してオペレーションをモデリングする必要があります その他のすべての場合 つまり オペレーションに入力引数または出力引数のいずれかが含まれ アプリケーションエラーも構造体もない場合は オペレーションが入力引数を含むのか出力引数を含むのかによって TargetLink Inport または TargetLink Outport を 1 つだけを使用してオペレーションをモデリングすることができます 目的 TargetLink を使用した SWC のモデリング 補足説明現在のところ TargetLink では 非同期型クライアント / サーバ通信はサポートされていません TargetLink AUTOSAR ガイドライン

20 例 1 入力および出力引数を含むクライアント / サーバオペレーションを呼び出すには Data Dictionary での適切なクライアント / サーバインターフェースの指定とともにオペレーションコールサブシステム (Function/Runnable ブロックを持つサブシステム ( 例については図 18 を参照 )) を使用する必要があります 図 19 を参照してください Function/Runnable ブロックのブロックダイアログでは [Implement subsystem as operation call] オプションを設定し 適切なオペレーションを参照する必要があります 図 20 を参照してください 各オペレーション引数は ブロックダイアログで個々のオペレーション引数を指定する TargetLink Inport/Outport ブロックを使用してモデリングする必要があります 図 21 を参照してください 図 18: 複数のオペレーション引数が関係するクライアント / サーバオペレーションを呼び出す Operation Call サブシステムの使用例 各 Operation Call サブシステムは操作を呼び出すランナブル内に存在している必要があります オペレーションに複数の入力引数が関係する場合 複数の TargetLink Inport を使用する必要があります 図 19:Data Dictionary での Saturation オペレーションの指定 このオペレーションは双方向で 入力信号と出力信号を含むので 図 18 に示されているようにオペレーションコールサブシステムを使用してモデリングする必要があります TargetLink AUTOSAR ガイドライン

21 . 図 20 : クライアント / サーバインターフェースのオペレーションの呼び出しを指定するには Function/Runnable ブロックで [Implement subsystem as operation call] オプションを設定する必要があります さらに Data Dictionary 内の必要なオペレーションを参照する必要があります 図 21: オペレーションの各入出力引数は ブロックダイアログから個々のオペレーション引数を参照する TargetLink Inport/Outport ブロックを使用してモデリングする必要があります TargetLink AUTOSAR ガイドライン

22 例 2 TargetLink の MCDC デモモデルでは 単純な Get/Set 関数形式のクライアント / サーバ通信の例が示されています ここでは オペレーションコールサブシステム全体をモデリングする必要はありません 代わりに 単純な TargetLink Inport/Outport ブロックを使用して Get/Set オペレーションをモデリングすることができます 単純な Get/Set オペレーションに使用できるモデリングスタイルを図 22 に示します TargetLink Inport/Outport のブロックダイアログで必要な仕様は 図 23 に示します 図 24 に示されているように Data Dictionary 内でオペレーションを指定してください 図 22:position ブロックは 1 つの信号だけを取り出すクライアント / サーバオペレーションである単純な Get 関数を指定するために使用します 例 1 に示されているように このような状況ではオペレーションコールサブシステム全体をモデリングする必要はありません 単純な TargetLink Inport/Outport ブロックで十分です 図 23:TargetLink Inport ブロックからの一方向クライアント / サーバオペレーションの参照 TargetLink AUTOSAR ガイドライン

23 図 24: クライアント / サーバでの一方向オペレーションの指定 このオペレーションには Position という引数が 1 つだけ含まれています この引数は ARGOUT オペレーション引数です したがって このオペレーションは図 22 と図 23 に示されているように 1 つの TargetLink Inport ブロックだけでモデリングすることができます 2.9 AUTOSAR に関連する信号の初期化 TargetLink AUTOSAR モデルにはさまざまな種類の AUTOSAR に関連する信号 ( シミュレーションビヘイビアが初期化値によって異なる場合に MIL および SIL/PIL シミュレーションモードでシミュレーションのために適切に初期化する必要があるインターランナブルバリアブルやポート ) が含まれています これには TargetLink Outport を適切に初期化する必要があるファンクションコールでトリガされるサブシステムなどの 条件付きで実行されるサブシステムとしてランナブルをモデリングする場合などが考えられます 信号の種類が異なると AUTOSAR に関連する仕様に従って Outport を初期化するために適用されるメカニズムも若干異なります センダ / レシーバ通信の Outport は AUTOSAR 定数の指定として使用される DD 変数オブジェクトの value プロパティを参照することにより初期化することができます 例 1 を参照してください インターランナブル通信の Outport は Data Dictionary に含まれるインターランナブルバリアブルの value プロパティを参照することにより初期化することができます 例 2 を参照してください 補足説明実際の ECU 上での AUTOSAR に関連する信号 ( 特定の Per-Instance-Memory は除く ) は ソフトウエアコンポーネントデスクリプションファイル内の仕様に基づいて RTE によって初期化されます これ以降の例で説明されている TargetLink Outport の初期化は MIL/SIL/PIL モードでのシミュレーションでのみ使用されます TargetLink AUTOSAR ガイドライン

24 例 1: ファンクションコールでトリガされるランナブルサブシステムでのセンダ / レシーバ通信用 TargetLink Outport の初期化図 25 の例では Simulink での実行がファンクションコールによってトリガされるランナブルを示します 結果として ランナブルサブシステムの TargetLink Outport( この場合 upi ブロック ) をある値で初期化でき また初期化する必要があります 図 26 を参照してください 図 25: 初期値がシミュレーションのビヘイビアに影響を与える場合には ( たとえば ファンクションコールによってトリガされるなど ) 条件付きで実行されるランナブルサブシステムの Outport をシミュレーションのために適切に初期化する必要があります 図 26: 左 : 図 25 の upi Outport に対してセンダ / レシーバ通信が指定されています 右 :upi Outport を適切に初期化するために AUTOSAR ポートの初期化に使用される定数値を表す DD 変数オブジェクトの value プロパティが参照されます この処理には TargetLink の ddv コマンドが使用されます この定数を表す Data Dictionary 変数オブジェクトは ARXML のインポート中に自動的に作成されます もちろん 手作業で作成することも可能です TargetLink AUTOSAR ガイドライン

25 図 27:AUTOSAR 規格に従い Sender/Receiver ポートの初期化値は ARXML のインポート / エクスポート中にインポートまたはエクスポートされる Data Dictionary 変数オブジェクト ( ここでは Init_Value_upi と呼びます ) への参照を介して指定します 図 28:: シミュレーション目的でポートを初期化するために図 26 の TargetLink Outport から参照される Init_Value_upi DD 変数オブジェクトの value プロパティ TargetLink AUTOSAR ガイドライン

26 例 2: ファンクションコールでトリガされるランナブルサブシステムでのインターランナブル通信用 TargetLink Outport の初期化図 29 の例では Simulink での実行がファンクションコールによってトリガされるランナブルを示します 結果として ランナブルサブシステムの TargetLink Outport( この場合 lin_pos ブロック ) をある値で初期化できます 図 26 を参照してください 図 29: ファンクションコールによってトリガされるランナブルサブシステム内部の TargetLink Outport( この例では lin_pos) lin_pos Outport の初期化値を指定する必要があります 図 30: 左 : 図 29 の lin_pos Outport に対してインターランナブル通信が指定されています 右 :lin_pos Outport を適切に初期化するために インターランナブルバリアブルを表す DD 変数オブジェクトの value プロパティが参照されます この処理には TargetLink の ddv コマンドが使用されます このインターランナブルバリアブルを表す Data Dictionary 変数オブジェクトは ARXML のインポート中に自動的に作成されます もちろん 手作業で作成することも可能です TargetLink AUTOSAR ガイドライン

27 図 31: インターランナブルバリアブルを表す Data Dictionary 変数オブジェクト 初期化値は 変数オブジェクトの Value プロパティに保存されます AUTOSAR 規格に従い インターランナブルバリアブルはスカラー変数を指定する必要があります 2.10 SWC 内部での AUTOSAR に関連しない信号の初期化 特定の AUTOSAR 信号ではないソフトウエアコンポーネント内部の信号を適切に初期化する必要がある場合もあります 初期化後の状態は 最初の状態です RTE はこれらの信号を初期化しないので このような信号は SWC のランナブル向けに作成されているコードによって初期化する必要があります これらは以下の 2 つの異なる方法で初期化することができます 定義で初期化 RestartFunction タイプの AUTOSAR ランナブルで初期化 目的変数の適切な初期化 ( 必要な場合 ) 例 1 図 32 の Unit Delay ブロックの状態変数は 変数クラスとして default を選択することによって定義で初期化することができます 図 33 を参照してください この結果 状態変数は定義で直接初期化されます 図 34 を参照してください TargetLink AUTOSAR ガイドライン

28 図 32:AUTOSAR ランナブルの一部であるはずの Unit Delay ブロックを持つモデルの一部 Unit Delay ブロックの状態変数は適切に初期化する必要があります この状態変数は定義で初期化する ( 最も一般的 ) ことも RestartFunction タイプのランナブルで初期化することもできます 図 33:Unit Delay ブロックの状態 変数クラスはデフォルトに設定されているので 状態変数は定義で初期化されます 図 34 を参照してください この例は 図 32 に示された部分が属するランナブルに対して作成されるファイルの一部を示しています 図 34:Unit Delay ブロックの状態変数を定義および初期化するために作成されるコードの一部 TargetLink AUTOSAR ガイドライン

29 例 2 図 32 の Unit Delay ブロックの状態変数は 特別な再起動ランナブルで初期化されます このためには 図 35 に示されている必要プロパティを含む変数クラスが必要です この変数クラスは状態変数のブロックダイアログで選択されます 図 36 を参照してください 変数が属する SWC に対しては RestartFunction タイプのランナブルが必要です 図 37 を参照してください その結果 状態変数は再起動ランナブルで初期化されるようになります 図 38 を参照してください 図 35:RestartFunction タイプのランナブルで SWC の内部変数を初期化するには InitAtDefinition に off が設定され RestartFunctionName が明示的に default のままである変数クラスが必要です 図 36: 図 37 で指定されている特別な 再起動ランナブル で開始変数を初期化するためのブロックダイアログから変数クラスへの参照 TargetLink AUTOSAR ガイドライン

30 図 37: RestartFunction タイプのランナブルで SWC の内部変数を初期化するには Kind プロパティに RestartFunction を設定したランナブルを SWC に含める必要があります この手順を行うと TargetLink は 再起動ランナブルで変数クラスのプロパティ InitAtDefinitiion = off と RestartFunctionName = default を使用して SWC のすべての内部変数を初期化します 図 38:RestartFunction タイプの別のランナブルでの状態変数の初期化 TargetLink AUTOSAR ガイドライン

31 3 Data Dictionary でのモデリング この章では Data Dictionary 内の AUTOSAR に関連するデータを指定する場合に関係のあるガイドラインを紹介します AUTOSAR XML をインポートして AUTOSAR に関連するデータをインポートすると AUTOSAR に関連するデータがこの章のガイドラインに沿った形で自動的に整理されます 3.1 あらかじめ設定する Data Dictionary の仕様 AUTOSAR 準拠コードを生成するには 以下のように TargetLink で Data Dictionary ファイルのいくつかのオブジェクトをあらかじめ設定しておく必要があります ステータス信号用の変数 (RTE_E_OK RTE_E_TRANSMIT_ACK) インターランナブルバリアブル用の変数クラス (RTE マクロなど ) RTE マクロ用関数クラスインターランナブル通信用アクセス関数 AUTOSAR Data Dictionary テンプレートファイル dsdd_master_autosar.dd を使用するか または DD Merge Explorer を使用してプロジェクトの Data Dictionary ファイルにテンプレートファイルを統合すると AUTOSAR に関連するこれらの Data Dictionary オブジェクトを簡単に設定することができます 目的 TargetLink を使用した SWC のモデリング 補足説明 AUTOSAR 関連プロジェクトの Data Dictionary テンプレートファイルは 次の場所にあります <TL_Root>\Dsdd\Config\dsdd_master_autosar.dd 例 AUTOSAR 準拠のコード生成のために Data Dictionary プロジェクトであらかじめ設定する必要のある AUTOSAR に関連するオブジェクトを図 39 にいくつか示します 図 40 は Data Dictionary Merge Explorer を使用した既存の Data Dictionary ファイルの dsdd_master_autosar.dd の AUTOSAR に関連するオブジェクトへの統合を示します 図 39:dsdd_master_autosar.dd テンプレートのあらかじめ設定する必要のある AUTOSAR に関連する Data Dictionary オブジェクト TargetLink AUTOSAR ガイドライン

32 図 40:DD Merge Explorer を使用すると dsdd_master_autosar.dd テンプレートの AUTOSAR に関連する Data Dictionary オブジェクトと既存の Data Dictionary ファイルを統合することができます Merge Explorer は Data Dictionary Manager の View メニューで利用できます オブジェクトはコンテキストメニュー ( マウスの右クリック ) を使用して右から左へコピーできます 3.2 AUTOSAR に関連する Data Dictionary オブジェクトの名前 AUTOSAR に関係する Data Dictionary オブジェクト ( インターフェース ソフトウエアコンポーネント モード Typedef スケーリングなど ) の名前では 以下の規則を順守する必要があります Data Dictionary 内の AUTOSAR に関連するすべてのオブジェクトの名前は 長さを 31 文字以内とします AUTOSAR に関連するすべてのオブジェクトの名前は有効な C 識別子とする必要があります 目的 AUTOSAR 規格 つまり autosar.xsd スキーマファイルの準拠 補足説明 AUTOSAR 4.0 より前の AUTOSAR 規格では すべての AUTOSAR 識別子の名前の長さが 31 文字に制限されます この規定は RTE マクロやパス / パッケージ情報を含む名前には適用されません さらに AUTOSAR エレメントの場合は有効な C 識別子が必要です 一般的に 最大長を含む AUTOSAR 識別子の有効性は autosar.xsd スキーマファイルで指定します 図 41 を参照してください TargetLink AUTOSAR ガイドライン

33 TargetLink 3.2 は 長い識別子が使用された場合に警告を出すように変更できる IdentifierWarningLevel インポート / エクスポートオプションを提供しています デフォルトは 32 に設定されています TargetLink インストレーションに含まれる dsdd_autosar_config.xml ファイルを参照してください Validate インポート / エクスポートオプションに On が設定されている場合は ARXML のインポート / エクスポート時に autosar.xsd スキーマファイルの準拠が確認されます 場合によっては Data Dictionary データモデル自体がオブジェクトが有効な C 識別子であることを必要とし 自動的にこれらのチェックを実行します ただし これはソフトウエアコンポーネントなどの一部のオブジェクトの場合だけで AUTOSAR プロジェクトで必要なすべての Data Dictionary オブジェクトに対して当てはまるわけではありません 図 41:AUTOSAR 識別子に使用できる文字と文字数を指定する AUTOSAR 3.0 の autosar.xsd スキーマファイルの一部 TargetLink の autosar.xsd スキーマファイルは <TL_Root>\Dsdd\Autosar のサブディレクトリに保存されています 例 AUTOSAR に関連するオブジェクトの名前として不適切なものを図 42 と図 43 に示します 図 42: インターフェースとタイプの例の長さが 31 文字を超えています このような名前は避けてください TargetLink AUTOSAR ガイドライン

34 図 43: ユニットなどの AUTOSAR に関連する Data Dictionary オブジェクトの名前は有効な C 識別子で構成する必要がありますが この例ではそうなっていません 3.3 Data Dictionary での AUTOSAR に関連するデータの構成 適切な AUTOSAR ワークフローと他の AUTOSAR に関連するツールとの行き来 ( ラウンドトリップ ) のためには 以下のような特定の AUTOSAR に関連するオブジェクトのあらかじめ設定された構造を Data Dictionary に含める必要があります ソフトウエアコンポーネントインターフェースモード宣言グルーブ Typedefs スケーリング 上記の種類のオブジェクトの AUTOSAR に関連するすべてのオブジェクトは 各種オブジェクトの上位レベルのグループオブジェクトのサブグループに保存してください つまり 上記のオブジェクトは以下のサブグループに保存します /Pool/Autosar/SoftwareComponents/<SWC_GroupName> /Pool/Autosar/Interfaces/<Interface_GroupName> /Pool/Autosar/ModeDeclarationGroups/<ModeDeclaration_GroupName> /Pool/Typedefs/<Typedef_GroupName> /Pool/Scalings/<Scaling_GroupName> サブグループオブジェクトは 図 44 に示されているように AUTOSAR パッケージに直接関連付けられています 目的 TargetLink を使用した SWC のモデリング反復的な開発プロセスでの AUTOSAR の適切なラウンドトリップとアップデートの実行 TargetLink AUTOSAR ガイドライン

35 補足説明 EnablePackageSupport オプションが有効な場合 ( デフォルトの推奨設定 ) は ARXML のインポート時 TargetLink が新たにインポーされた AUTOSAR オブジェクトをこの規則に従って自動的に構成します Data Dictionary の AUTOSAR に関連するオブジェクトを最初から作成する場合 この規則により ARXML を何度かインポート / エクスポートする反復的な開発プロセスでこれらのオブジェクトを適切にアップデートすることができます 以降の規則で説明されるように AUTOSAR に関連する他のいくつかのオブジェクトは適用外です 当然のことながら AUTOSAR と関連のない Data Dictionary オブジェクトも適用外です 例図 44 は AUTOSAR に関連するオブジェクトの Data Dictionary 内の必須構造を示します TargetLink の各リリースに同梱されている TargetLink AUTOSAR デモモデルでも Data Dictionary の必須構造が示されています 図 44:Data Dictionary のソフトウエアコンポーネント インターフェース モード宣言グループの必須構造 3.4 Data Dictionary オブジェクトへの AUTOSAR パッケージの割り当て オブジェクトが属するパッケージ (arxml ファイルも ) を分かりやすく定義するために いわゆる AUTOSAR エレメントに対応する Data Dictionary 内の AUTOSAR に関連する各オブジェクトにパッケージ情報を明示的に割り当てる必要があります 規則 3.3 に示されているオブジェクトの AUTOSAR パッケージは 以下の方法で指定します 規則 3.3 のサブグループの名前は 最下層の AUTOSAR サブパッケージの名前に対応する必要があります 3.3 のサブグループには AUTOSR パッケージ情報全体を Package プロパティに保存する GroupInfo ノードを含める必要があります 目的 AUTOSAR に関連する他のツールを使用した適切な AUTOSAR ラウンドトリップ AUTOSAR エレメントのファイルへの適切な分割 TargetLink AUTOSAR ガイドライン

36 補足説明パッケージ情報は TargetLink による ARXML のエクスポート時のファイルの分割にも影響を与えます Data Dictionary 内の AUTOSAR エレメントに対してパッケージ情報が指定されていない場合 ( この規則に従うと避けるべき状態 ) は ARXML のエクスポート時に指定したファイル名を基にその AUTOSAR エレメントにファイルとパッケージが割り当てられます ユニットオブジェクトのパッケージ情報は別の方法で指定します 3.8 を参照してください 例図 45 は ソフトウエアコンポーネントの AUTOSAR パッケージ情報の指定を示します TargetLink の各リリースに同梱されている TargetLink デモモデルでも Data Dictionary のパッケージ情報の指定が示されています 図 45:Data Dictionary でのソフトウエアコンポーネントのパッケージ情報の指定 :AUTOSAR に関連するオブジェクトをパッケージに含めるためには まずグループオブジェクトと関連 GroupInfo ノードを作成する必要があります ( ここでは Sensors というソフトウエアコンポーネントグループ ) パッケージ情報は GroupInfo ノードの Package プロパティに保存されます 最上位のパッケージは ApplicationSWC で サブパッケージ名は Sensors です サブグループの名前も Sensors とします したがって AUTOSAR パッケージ情報全体は ApplicationSWCs/Sensors となります 3.5 パッケージサポートによる ARXML のインポート / エクスポートの実行 AUTOSAR のインポート / エクスポート時に AUTOSAR パッケージ情報を常に考慮に入れるために EnablePackageSupport オプションにはデフォルトとして On を設定します 目的 AUTOSAR に関連する他のツールを使用した適切な AUTOSAR ラウンドトリップ 例図 46 は <TL_Root>\Dsdd\config ディレクトリに保存され 他の値が明示的に指定されている場合を除きデフォルトの ARXML インポートおよびエクスポートオプションを保存するために使用される dsdd_autosar_config.xml ファイルの内容を示しています 図 47 は TargetLink AU- TOSAR インポートダイアログの EnablePackageSupport オプションを示しています TargetLink AUTOSAR ガイドライン

37 図 46:dsdd_autosar_config.xml ファイルで指定する EnablePackageSupport オプションに On を設定します これは TargetLink のデフォルトでもあります 図 47: パッケージ情報をサポートするためには SWC デスクリプションファイルのインポート / エクスポート時に Enable package support オプションを選択しておく必要があります TargetLink AUTOSAR ガイドライン

38 3.6 AUTOSAR プロジェクトでのタイプのモデリング AUTOSAR 信号 ( データエレメント オペレーション引数 インターランナブルバリアブル Per Instance Memory など ) に使用するタイプの指定については 以下の規則を順守する必要があります 3.3 で説明されているように AUTOSAR に関連するすべてのタイプを /Pool/Typedefs/<Typedef_GroupName> に置く必要があります 3.2 で説明されているように タイプの名前は 31 文字以下の有効な C 識別子とする必要があります AUTOSAR 信号にはユーザタイプだけを使用します つまり BaseType プロパティは off にします /Pool/Typedef の直下にある In16 Int32 などのあらかじめ設定されたデータタイプは 使用しないでください 同様に /Pool/Typedef/platformtypes の下にあるあらかじめ設定された AUTOSAR に関連するタイプも AUTOSAR 信号には使用しないでください すべての Integer AUTOSAR タイプには スケーリングオブジェクトを指定した constraints サブノードを含める必要があります タイプの最小値と最大値も制約として指定することができます AUTOSAR 信号に使用するタイプの ModuleRef プロパティには n.a. または Rte_Type を設定する必要があります SWC/ ランナブルの内部信号にのみ使用し AUTOSAR 信号には使用しないタイプでは ModuleRef プロパティに Rte_Type を設定しないでください 目的 TargetLink を使用した SWC のモデリング 例 AUTOSAR 信号に使用してはいけないあらかじめ設定されたデータタイプおよび基本タイプの一部を図 48 に示します 図 49 は AUTOSAR 整数タイプの場合にスケーリングオブジェクトをどのように参照する必要があるのかを示します 図 50 は AUTOSAR 信号に使用するタイプに使用できない ModuleRef 値を示します 図 48:/Pool/Typedefs/PlatformTypes にあるあらかじめ設定されたデータタイプは使用しないでください 同様に /Pool/Typedef の直下にある Int16 Int32 UInt8 などの TargetLink 基本タイプは 使用しないでください TargetLink AUTOSAR ガイドライン

39 図 49: すべての AUTOSAR 整数データタイプには タイプの Constraints サブノードで参照されるスケーリングオブジェクトを含める必要があります さらに タイプに対して Min および Max の値を指定することができます 図 50:AUTOSAR 信号に使用するタイプには n.a.( 割り当てなし ) または Rte_Type 以外の値を持つ ModuleRef プロパティを含めないでください TargetLink AUTOSAR ガイドライン

40 3.7 Data Dictionary での AUTOSAR スケーリングの指定 (CompuMethods) AUTOSAR 信号 ( データエレメント オペレーション引数 インターランナブルバリアブル Per Instance Memory など ) に使用するタイプの指定については 以下の規則を順守する必要があります スケーリングは 3.3 の規則で説明されているように /Pool/Scalings のサブグループに保存する必要があります サブグループオブジェクトは 規則 3.4 で説明されているように最下層の AUTOSAR パッケージに対応します スケーリングオブジェクトの名前は 規則 3.2 で説明されているように 31 文字以下の有効な C 識別子とする必要があります Data Dictionary のデータモデルでは他の識別子を使用することもできます AUTOSAR ユニットをスケーリングに関連付ける場合は スケーリングオブジェクトの UnitRef プロパティからユニットオブジェクトを参照します Unit プロパティに文字列として入力しないでください 目的 AUTOSAR に関連する他のツールを使用した適切な AUTOSAR ラウンドトリップ 補足説明 Data Dictionary のスケーリングオブジェクトは AUTOSAR 規格ではいわゆる CompuMethods に対応します 上記の規則は AUTOSAR 信号に使用されるスケーリングにのみ適用されます SWC の内部で使用する信号で順守する必要はありません 例 AUTOSAR 信号に使用できるスケーリングオブジェクトの適切な指定を図 51 に示します 図 51:Pool/Scalings の DataTypeSemantics というサブグループオブジェクトに保存されているスケーリングオブジェクト SC_ref スケーリングは /Config/Units に保存されている MyMeter という AUTOSAR ユニットを参照します TargetLink AUTOSAR ガイドライン

41 3.8 Data Dictionary での AUTOSAR ユニットの指定 AUTOSAR 信号 ( データエレメント オペレーション引数 インターランナブルバリアブル Per Instance Memory など ) に使用するユニットの適切な指定については 以下の規則を順守する必要があります ユニットオブジェクトは /Config/Units の下に作成します サブグループオブジェクトは作成できず 作成してはいけません ユニットが属する AUTOSAR パッケージは ユニットオブジェクトの package プロパティで指定する必要があります ユニットオブジェクトの名前は 規則 3.2 で説明されているように 31 文字以下の有効な C 識別子とする必要があります Data Dictionary のデータモデルでは他の識別子を使用することもできるため この自動チェックは行われません 図 51 に示されているように ユニットオブジェクトはスケーリングオブジェクトからのみ参照します 目的 AUTOSAR に関連する他のツールを使用した適切な AUTOSAR ラウンドトリップ 補足説明上記の規則は AUTOSAR 信号に使用されるユニットにのみ適用されます SWC の内部で使用する信号で順守する必要はありません 例 AUTOSAR 信号に使用できるユニットオブジェクトの適切な指定を図 52 に示します 図 52:AUTOSAR パッケージのユニットの指定 ソフトウエアコンポーネント インターフェースなどとは異なり AUTOSAR パッケージ情報は個々のユニットオブジェクトの Package プロパティに直接保存されます すべてのユニットは Data Dictionary の /Config/Units ノードに直接保存されます サブグループは作成できず 作成してはいけません TargetLink AUTOSAR ガイドライン

42 3.9 Data Dictionary でのセンダ / レシーバインターフェースの指定 Data Dictionary でのセンダ / レシーバインターフェースオブジェクトの指定については 以下の規則を順守する必要があります インターフェースオブジェクトは 規則 3.3 で説明されているように /Pool/Autosar/Interfaces のサブグループに保存する必要があります サブグループオブジェクトは 規則 3.4 で説明されているように最下層の AUTOSAR パッケージに対応します インターフェースオブジェクトの名前は 規則 3.2 で説明されているように 31 文字を超えない長さである必要があります Data Dictionary のデータモデルでは 名前が有効な C 識別子であることを自動的にチェックします インターフェース内のデータエレメントまたはモードエレメントの名前は 31 文字以下とします Data Dictionary のデータモデルでは 名前が有効な C 識別子であることをチェックします データエレメントとモードエレメントが混在するのではなくデータエレメントのみまたはモードエレメントのみを含むセンダ / レシーバインターフェースを指定することをお勧めします 配列であるデータエレメントには width プロパティを設定します すべてのデータエレメントには type プロパティを設定します Scaling プロパティにはスケーリングオブジェクトを指定しないことをお勧めします 規則 3.6 で説明されているように スケーリングオブジェクトは参照されているタイプを介して間接的に指定すべきです TargetLink 3.1p1 以降では 範囲が参照されているタイプに対して指定されている範囲のサブセットである場合 データエレメントの Min および Max プロパティに値を指定することができます 目的 AUTOSAR に関連する他のツールを使用した適切な AUTOSAR ラウンドトリップ 例データエレメントを含むセンダ / レシーバインターフェースの適切な指定を図 53 に示します 図 53: データエレメントを 1 つだけ含むセンダ / レシーバインターフェースの適切な指定 インターフェースオブジェクト IF_upi は PortInterface と呼ばれる /Pool/Autosar/Interfaces のサブグループオブジェクトに保存されます データエレメント upi は スケーリングオブジェクトではなく信号のタイプを参照します TargetLink AUTOSAR ガイドライン

43 3.10 Data Dictionary でのクライアント / サーバインターフェースの指定 Data Dictionary でのクライアント / サーバインターフェースオブジェクトの指定については 以下の規則を順守する必要があります インターフェースオブジェクトは 規則 3.3 で説明されているように /Pool/Autosar/Interfaces のサブグループに保存する必要があります サブグループオブジェクトは 規則 3.4 で説明されているように最下層の AUTOSAR パッケージに対応します インターフェースオブジェクトの名前は 規則 3.2 で説明されているように 31 文字を超えない長さである必要があります Data Dictionary のデータモデルでは 名前が有効な C 識別子であることを自動的にチェックします インターフェースのオペレーション引数の名前は 31 文字を超えない長さである必要があります Data Dictionary のデータモデルでは 名前が有効な C 識別子であることをチェックします 配列であるオペレーション引数には width プロパティを設定します すべてのオペレーション引数には type プロパティを設定します Scaling プロパティにはスケーリングオブジェクトを指定しないことをお勧めします 規則 3.6 で説明されているように スケーリングオブジェクトは参照されているタイプを介して間接的に指定すべきです TargetLink 3.1p1 以降では 範囲が参照されているタイプに対して指定されている範囲のサブセットである場合 オペレーション引数の Min および Max プロパティに値を指定することができます 目的 AUTOSAR に関連する他のツールを使用した適切な AUTOSAR ラウンドトリップ 例オペレーションを 1 つ含むクライアント / サーバインターフェースの適切な指定を図 54 に示します 図 54: Saturation というオペレーションを 1 つだけ含むクライアント / サーバインターフェースの適切な指定 インターフェースオブジェクト IF_Saturation は PortInterface と呼ばれる /Pool/Autosar/Interfaces のサブグループオブジェクトに保存されます オペレーション引数 Input は スケーリングオブジェクトではなく信号のタイプを参照します TargetLink AUTOSAR ガイドライン

44 3.11 Data Dictionary でのインターランナブルバリアブルの指定 Data Dictionary でのインターランナブルバリアブルの指定については 以下の規則を順守する必要があります SWC と SWC のインターナルビヘイビアのすべてのインターランナブルバリアブルは /Pool/Variables/<SWC_Name>/IRV サブグループで作成すべき Data Dictionary 変数オブジェクトとして表す必要があります ソフトウエアコンポーネントの下の RelatedVariables オブジェクトの InterrunnableVariablesRef プロパティで変数グループオブジェクト /Pool/Variables/<SWC_Name>/IRV を明示的に指定することをお勧めします インターランナブルバリアブルはソフトウエアコンポーネントのインターナルビヘイビアに自動的に属するので パッケージ情報は指定することができず 指定してはいけません インターランナブルバリアブルオブジェクトの名前は 規則 3.2 で説明されているように 31 文字以下の有効な C 識別子とする必要があります Data Dictionary のデータモデルではこのチェックを自動的には実行しません 公式の TargetLink AUTOSAR Modeling Guide で説明されているように インターランナブルバリアブルでは Class および NameTemplate プロパティに特定の設定を行う必要があります RTE によりインターランナブルバリアブルを適切に初期化する必要がある場合は Value プロパティに初期化値を設定します インターランナブルバリアブルは AUTOSAR 規格で求められているとおりスカラー値である必要があるので width プロパティは設定しません 適切なタイプを割り当てるために type プロパティを設定します AUTOSAR 規格でサポートされていないため インターランナブルバリアブル向けにローカルスケーリングオブジェクトを作成することはできません 目的 TargetLink を使用した AUTOSAR SWC の適切なモデリング 例図 55 図 56 および図 57 は Data Dictionary でのインターランナブルバリアブルの指定を示します 図 55 : インターランナブルバリアブルの適切な指定 InitConstantName InitConstantUuid および InitConstantPackage プロパティを使用すると インターランナブルバリアブルの初期化値に定数オブジェクトを割り当てることができます ( この場合 0) TargetLink AUTOSAR ガイドライン

45 図 56: インターランナブルバリアブルオブジェクトに対してローカルスケーリングオブジェクトを使用することはできません 図 57: インターランナブルバリアブルを保存する変数グループオブジェクト (/Pool/Variables/<SWC_Name>/IRV) を明示的に指定することをお勧めします TargetLink AUTOSAR ガイドライン

46 4 制限事項 この章では TargetLink を使用して AUTOSAR ソフトウエアコンポーネントをモデリングする場合の主な制限事項について説明します 4.1 ソフトウエアコンポーネントテンプレートのサポート対象の制限 TargetLink は ソフトウエアコンポーネントテンプレートに定義されているすべての AUTOAR 機能のサブセットをサポートしています すべての機能と TargetLink によるサポート範囲の詳細なリストは 公式の TargetLink サポート から Excel シート形式で入手することができます TargetLink で SWC を開発するときには これらの制約を順守してください 目的 TargetLink を使用した SWC のモデリング 4.2 AUTOSAR コンポジションの取り扱い TargetLink はコンポジション (1 つの SWC に集約される SWC の集まりで コンポジションと呼ばれる ) をサポートしておらず アトミックソフトウエアコンポーネントのみをサポートしています 目的 TargetLink を使用した SWC のモデリング 補足説明コンポジションの直接サポートはありませんが dspace Data Dictionary でコンポジションを含む SWC デスクリプションファイルをインポートすることはできます このインポートメカニズムでは コンポジションそのものは無視されますが コンポジションに含まれるアトミックソフトウエアコンポーネントはインポートされます コード生成後に 個々のアトミックソフトウエアコンポーネントを SWC デスクリプションファイルにエクスポートすることはできますが コンポジションにまとめることはできません 例図 58 は 2 つのアトミックソフトウエアコンポーネントで構成されるコンポジションを含む SWC デスクリプションファイルの一部です AUTOSAR xml ファイルは dspace の Data Dictionary にインポートできますが インポートされるのはアトミックソフトウエアコンポーネントだけです ( 図 59 を参照 ) コード生成後は アトミックソフトウエアコンポーネントを SWC デスクリプションファイル形式でエクスポートできます ただし コンポジションに関する記述は含まれません 図 58:Composition_SWC1_SWC2 という名前のコンポジションを含む SWC デスクリプションファイルの一部 このコンポジションには ASWC1 と ASWC2 という名前の 2 つのアトミックソフトウエアコンポーネントが含まれます TargetLink AUTOSAR ガイドライン

47 図 59: 図 58 の xml ファイルをインポートすると アトミックソフトウエアコンポーネント (ASWC1 および ASWC2) が Data Dictionary に保存されますが これにはコンポジションに関する記述は含まれません 4.3 ソフトウエアコンポーネントの複数インスタンスは利用不可 TargetLink は 同じ AUTOSAR ソフトウエアコンポーネントの複数インスタンスに対応していません このため Data Dictionary 内のソフトウエアコンポーネントオブジェクトの SupportsMultipleInstantiation プロパティには on を設定しないでください 目的 TargetLink を使用した SWC のモデリング 補足説明 AUTOSAR ソフトウエアコンポーネントの複数インスタンスを使用して複数のインスタンスでコードを共有すると コードサイズの削減に役立ちます しかし 現在のところ AUTOSAR のこの機能は TargetLink でサポートされていません 例図 60 は SWC が複数インスタンスをサポートするかどうかを指定する SWC の SupportsMultipleInstantiation プロパティを示しています TargetLink で SWC の複数インスタンスが許可されていないため このプロパティは off に設定する必要があります ( 使用している RTE ジェネレータでこのプロパティを設定する必要がない場合は <n.a.>) TargetLink AUTOSAR ガイドライン

48 図 60:Data Dictionary 内のソフトウエアコンポーネントの SupportsMultipleInstantiation プロパティには on を設定しないでください 4.4 イベントセマンティクスを使用するセンダ / レシーバ通信のシミュレーションサポートの制限 イベントセマンティクスが指定されたデータエレメントのセンダ / レシーバ通信は 通常の Simulink のデータエレメントセマンティクスと同様に MIL/SIL/PIL モードでシミュレートされます そのため これらのデータエレメントのキューはシミュレートされず キューのオーバーランなどが発生することはありません 注 :AUTOSAR アプリケーションで イベントセマンティクスを使用するデータエレメントは個々の値の読み書きを行うキューを持っています この動作を Simulink で正しくシミュレートすることはできません そのため TargetLink は Simulink ユーザにとって一般的なシミュレーション用のキューを持たない通常のデータエレメントセマンティクスを使用します 目的 TargetLink を使用した SWC のシミュレーション 補足説明データエレメントでイベントセマンティクス ( および関連するキュー ) を指定するかどうかは SWC のコードに影響を及ぼします これは データおよびイベントセマンティクスの RTE マクロが異なるためです また この指定は SWC デスクリプションファイルの一部になります AUTOSAR アプリケーション全体を構築する際に必要なキューを提供するのは RTE ジェネレータの役割です 例図 61 はデータエレメントでのキューの使用 ( イベントセマンティクスの使用 ) の有無を示しています このプロパティは SWC デスクリプションファイルのインポートおよびエクスポートに対応していますが シミュレーション時には無視されます TargetLink AUTOSAR ガイドライン

49 図 61: データエレメントの IsQueued プロパティでは データエレメントでのイベントセマンティクスの使用 (isqueued = on) または不使用 (isqueued = off) を指定します Data Dictionary でキュー長を指定するには 関連するポートで EventReceiverComSpec オブジェクトを指定する必要があります 4.5 AUTOSAR SWC のモデリングとモデルリファレンス機能 AUTOAR ソフトウエアコンポーネントをモデリングするためにモデルリファレンスを適用する場合は 以下の規則が適用されます AUTOSAR に関連するすべての信号は 参照されているモデルの境界を越えない必要があります モデルリファレンスは AUTOSAR 信号が参照されているモデルの境界を越えない限り AUTOSAR ランナブルの内部で使用することができます 目的 TargetLink を使用した SWC のモデリング TargetLink AUTOSAR ガイドライン

50 5 SystemDesk と TargetLink の間で SWC コンテナをやり取りするためのガイドライン この章では TargetLink と SystemDesk の間で SWC コンテナをやり取りするためのガイドラインについて 特に説明します SWC コンテナのやり取りは AUTOSAR ワークフローを改善し 透過性を高め AUTOSAR ラウンドトリップを効率化し TargetLink AUTOSAR ユーザが SystemDesk のシミュレーション機能に簡単にアクセスできるようにするために TargetLink 3.2 と SystemDesk 3.0 で新たに導入されました この章では SWC コンテナのスムーズなやり取りを行うための SystemDesk と TargetLink の両方 ( 大部分は SystemDesk) に関するモデリングガイドラインを紹介します したがって この章のガイドラインは SystemDesk を使用しないユーザには関係ありません 注 :SystemDesk と TargetLink 間の SWC コンテナのやり取りを使用できるのは SystemDesk バージョン 3.0 以降と TargetLink バージョン 3.2 以降です 5.1 SystemDesk と TargetLink の一般的なガイドライン ワークフロー規則の指定 SystemDesk と TargetLink の間での SWC コンテナのやり取りはさまざまな設定が可能で 会社固有の要件に合わせて調整することができます このためには SystemDesk と TargetLink のインストレーションで ContainerWorkflowDefinition.ctw ファイルを調整する必要があります たとえば 以下のような項目を設定することができます SWC コンテナ内の各種ファイルのフォルダ構造ファイルカテゴリを自動的に割り当てるための命名スキームファイルカテゴリに基づくコンテナの同期を決定するワークフロー規則 目的会社固有の適切な AUTOSAR ワークフロー 例ユーザが調整できるコンテナワークフロー定義ファイルの一部を図 62 と図 63 に示します SWC コンテナをやり取りするためのコンテナ設定ファイルの使用 コンテナをインポートおよび同期するには 提供されている GUI でコンテナ設定ファイルを選択する必要があります ユーザがコンテナカタログファイルを直接操作する必要はありません 目的 TargetLink と SystemDesk の間でのコンテナの効率的なやり取り 例 SystemDesk または TargetLink プロジェクトに SWC コンテナをインポートする方法を図 64 と図 65 に示します コンテナのインポートを開始し ( 図 65 を参照 ) 初めにコンテナ設定ファイルを選択します 次に [Catalog History] から具体的なコンテナを選択します TargetLink AUTOSAR ガイドライン

51 図 62:SystemDesk と TargetLink のコンテナのエクスポート / インポート / 同期ビヘイビアに影響を与えて会社固有のワークフロー要件を満たすためにユーザが調整できる TargetLink と SystemDesk のインストレーションに含まれるワークフロー定義ファイルの一部 図 63: ワークフロー定義ファイルの一部 ( 別の部分 ) TargetLink AUTOSAR ガイドライン

52 図 64:SystemDesk でのコンテナのインポート 図 65:SWC コンテナのインポート : コンテナカタログファイルではなくコンテナ設定ファイルを使用することをお勧めします ( この例では Components.cts ファイル ) インポートするコンテナを選択するには まずコンテナに含まれるコンテナ設定ファイルを選択し [Catalog History] で必要なコンテナを選択します コンテナカタログファイルを直接選択する必要はありません TargetLink AUTOSAR ガイドライン

53 5.2 SWC コンテナをやり取りするための SystemDesk のガイドライン このセクションでは SystemDesk の使用時に順守する必要があるガイドラインを説明します ソフトウエアコンポーネントのパッケージへの分割 複数のパッケージへのソフトウエアコンポーネントの分割には以下の規則が適用されます TargetLink でやり取りするあらゆるソフトウエアコンポーネントは それぞれ個別のパッケージ内に保存する必要があります 複数のソフトウエアコンポーネントを 1 つのパッケージに保存することはできません パッケージ ( より具体的には ソフトウエアコンポーネントを含むサブパッケージ ) の名前は ソフトウエアコンポーネントの名前に一致させる必要があります 目的 : 別々のファイルへの複数のソフトウエアコンポーネントの適切な分割 SystemDesk と TargetLink でのコンテナカタログファイルに対する同一名の使用 補足説明 TargetLink の将来のバージョンでは 上記の制限は廃止される予定です SystemDesk ソリューションプール ( の PackageSynch スクリプトを使用すると SystemDesk の Project Manager でオブジェクトとフォルダ構造に基づいてパッケージ構造を自動的に作成することができます 上記のガイドラインに準拠するためには SWC を別々のフォルダに保存し SWC とフォルダの名前を一致させる必要があります 例図 66 の例は 異なるパッケージ内にある 2 つの異なる SWC( この例では ControllerSWC と SignalProcessingSWC) を示します パッケージ ( 最下層のサブパッケージ ) の名前は SWC の名前と一致させる必要があります SystemDesk プロジェクトでのすべてのオブジェクトのパッケージの割り当て TargetLink でやり取りする SystemDesk プロジェクトのあらゆるオブジェクトは AUTOSAR パッケージに割り当てる必要があります 目的 : すべての AUTOSAR エレメントのファイルとパッケージへの適切な分割 補足説明 SystemDesk ソリューションプール ( の PackageSynch スクリプトを使用すると SystemDesk の Project Manager のすべてのオブジェクトをパッケージに自動的に割り当てることができます TargetLink AUTOSAR ガイドライン

54 図 66: 異なる SWC( この例では ControllerSWC と SignalProcessingSWC) は別々のパッケージに保存します ( スクリーンショット右部分の Package Manager を参照 ) これらを 1 つのパッケージにまとめないでください さらに SWC の名前はパッケージ / 最下層のサブパッケージの名前に一致させる必要があります SystemDesk ソリューションプール ( の PackageSynch スクリプトを使用すると Project Manager でオブジェクトとフォルダ構造に基づいてパッケージ構造を自動的に作成することができます ( スクリーンショット左部分を参照 ) このためには SWC を異なるフォルダに保存し フォルダ名を SWC の名前に一致させる必要があります TargetLink AUTOSAR ガイドライン

55 5.2.3 共有データとコンポーネント固有のデータの分離 SWC などのコンポーネント固有のエレメントはインターフェースやデータタイプのように複数の開発者が共有するので 別々のパッケージとファイルに保存する必要があります 具体的には 尐なくとも以下の異なるパッケージが必要です インターナルビヘイビアとインプリメンテーションを含む各ソフトウエアコンポーネントのパッケージ SWC インターナルビヘイビア およびインプリメンテーションは同じパッケージに保存します インターフェースは インターフェース専用の別のパッケージに保存します データタイプとスケーリングは別のパッケージに保存し コンポーネントおよびインターフェースと混在しないようにします 目的コンポーネント固有のデータと共有データの別々のパッケージとファイルへの適切な分割と各種ファイルに対する TargetLink/SystemDesk ユーザの責任の明確化 補足説明インターフェースやデータタイプなどの共有データに対する責任は SystemDesk ユーザ / ソフトウエア設計者が負うべきです 例上記のガイドラインに準拠するための SystemDesk Project Manager/Package Manager の適切な構造の例を図 67 に示します AUTOSAR パッケージのファイル名 TargetLink で SWC コンテナをスムーズにやり取りするために SystemDesk からエクスポートする ARXML ファイルの名前は以下の規則を順守する必要があります サブパッケージを含まないパッケージの場合 ( 拡張子のない )ARXML ファイル名がパッケージの名前に一致する必要があります 構造 MyPackage/MySubpackage/MySubsubpackage などを含むサブパッケージの場合 arxml ファイルの名前は MyPackage.MySubpackage.MySubsubpackage にする必要があります 目的 SystemDesk と TargetLink での同一の ARXML ファイル名の使用 補足説明 TargetLink 3.2 は パッケージ名を基にファイル名が自動的に作成される ARXML ファイルの上記の命名スキームを使用します TargetLink の将来のバージョンでは 上記の制限は廃止される予定です SystemDesk ソリューションプール ( の PackageSynch スクリプトを使用すると SystemDesk の Project Manager でオブジェクトとフォルダ構造に基づいてパッケージとファイル名を自動的に作成することができます 例上記の要件に従った適切なファイル名の例を図 68 に示します TargetLink AUTOSAR ガイドライン

56 図 67: コンポーネント固有のデータと共有データを分離するための Project Manager と Package Manager の適切な構造の例 TargetLink AUTOSAR ガイドライン

57 図 68: パッケージ構造に従い TargetLink とツールの適切な相互運用性を確保する適切な ARXML ファイル名 サブパッケージを使用する場合 すべてのパッケージとサブパッケージを連結し それぞれドットで区切ったものを ARXML ファイル名とします TargetLink AUTOSAR ガイドライン

58 5.2.5 SystemDesk のワークフロー規則の指定 SystemDesk と TargetLink の間での SWC コンテナのやり取りはさまざまな設定が可能で 会社固有の要件に合わせて調整することができます SystemDesk による SWC コンテナのインポートとエクスポートに影響を与えるためには 以下のファイルを調整する必要があります <SystemDesk_Root> \Config\ContainerWorkflowDefinition.ctw ここで <SystemDesk_Root> は SystemDesk インストレーションのルートディレクトリです 目的会社固有の適切な AUTOSAR ワークフロー 備考上記のコンテナワークフロー定義ファイルの指定は Container Manager を SystemDesk から起動するときにも関係します 例ユーザが調整できるコンテナワークフロー定義ファイルの一部を図 69 に示します 図 69:SystemDesk のインストレーションに含まれ SystemDesk のコンテナのエクスポート / インポート / 同期ビヘイビアに影響を与えて会社固有の要件を満たすためにユーザが調整できるワークフロー定義ファイルの一部 TargetLink AUTOSAR ガイドライン

59 5.3 SWC コンテナをやり取りするための TargetLink のガイドライン このセクションでは TargetLink を使用する場合に順守する必要があるガイドラインを説明します ソフトウエアコンポーネントと TargetLink サブシステム 異なるソフトウエアコンポーネントは別々の TargetLink サブシステムに分割する必要があります 複数のソフトウエアコンポーネントを 1 つの TargetLink サブシステムに分割することはできません 目的 SystemDesk での適切な SWC コンテナのやり取り 補足説明 TargetLink の将来のバージョンでは この制限は廃止される予定です 例 1 つの TargetLink モデルで複数の SWC を開発するために複数の TargetLink サブシステムを含む TargetLink モデルを図 70 に示します 複数の SWC を別々の TargetLink サブシステムに保存するのか 1 つの TargetLink サブシステムに保存するのかを決定する tl_generate_swc_model API ファンクションの関連オプションを図 71 に示します 図 70:1 つの TargetLink モデルで複数の SWC をモデリングする場合は 複数の SWC を別々の TargetLink サブシステムに保存する必要があります ここでは それぞれ別々の TargetLink サブシステムに保存されている 4 つの異なる SWC をモデリングします TargetLink AUTOSAR ガイドライン

60 図 71:1 つの TargetLink モデル内の複数の SWC と組み合わせて tl_generate_swc_model ファンクションを使用する場合は [Use one TL Subsystem for all components] オプションの選択を解除して異なる SWC を別々の TargetLink サブシステムに分割する必要があります ( ダイアログは TargetLink AUTOSAR ユーティリティの一部です ) TargetLink のワークフロー規則の指定 SystemDesk と TargetLink の間での SWC コンテナのやり取りはさまざまな設定が可能で 会社固有の要件に合わせて調整することができます TargetLink による SWC コンテナのインポートとエクスポートに影響を与えるためには 以下のファイルを調整する必要があります <TargetLink_Root>\Dsdd\Config\ ContainerWorkflowDefinition.ctw ここで <TargetLink_Root> は TargetLink インストレーションのルートディレクトリです 目的会社固有の適切な AUTOSAR ワークフロー 備考上記のコンテナワークフロー定義ファイルの指定は Container Manager を TargetLink から起動するときにも関係します TargetLink AUTOSAR ガイドライン

61 例ユーザが調整できるコンテナワークフロー定義ファイルの一部を図 72 に示します 図 72:SystemDesk のインストレーションに含まれ SystemDesk のコンテナのエクスポート / インポート / 同期ビヘイビアに影響を与えて会社固有の要件を満たすためにユーザが調整できるワークフロー定義ファイルの一部 TargetLink AUTOSAR ガイドライン

62 6 参考資料一覧 [1] TargetLink AUTOSAR Modeling Guide, dspace GmbH, 2010 [2] dspace Release 7.0 AUTOSAR-Support.xls あらゆる種類の AUTOSAR 機能と TargetLink と SystemDesk がこれらの機能をサポートするかどうかを示す詳細リストの Excel シートです この Excel シートは TargetLink サポート から入手することができます [3] TargetLink AUTOSAR オンラインセミナーなどのその他の資料は からダウンロードできます TargetLink AUTOSAR ガイドライン