API 方針

3. API仕様

RTEは，C++で記述されたSW-Cに，全てのRTEシンボルがC言語リンケージとしてインポートさ れることを保証する【rte_sws_1011】．RTE APIのシンボルのインポートはアプリケーションヘッダ で行われる．

3.1.3 RTE名前空間

接頭辞"Rte_"を使用したグローバル名前空間内のシンボル名はRTEのために予約されており，RTE はこの接頭辞をシンボルの重複を避けるために使用する．

RTEの外部シンボルは，接頭辞"Rte_"を使用する．この規則は，以下のシンボルには適用しない

【rte_sws_1171】．

・ 以下の仕様で規定されるAUTOSARデータ型で表現される型名．

 プリミティブ実装データ型〔rte_sws_7104〕

・ 列挙定数〔rte_sws_3810〕．

・ 上限値，および下限値定数〔rte_sws_5052〕．

3.1.4 SCHM名前空間

SCHMの名前空間は，以下を除き，RTEの名前空間を使用する．

・ SCHMの外部シンボル(例．関数名，データ型等)は，接頭辞"SchM_"を使用する【rte_sws_7284】．

3.1.5 APIマッピング

RTEは，RTE API名からRTE APIの実体として生成される関数(生成関数)へのマッピング(APIマ ッピング)を提供する． ECUの実行バイナリ内で生成関数名はユニークでなければならないため，

APIマッピングは必要である．RTEGENは，APIマッピングをアプリケーションヘッダに生成する

【rte_sws_1274】．

3.1.5.1 コントラクトフェーズ

コントラクトフェーズでは，APIマッピングはAPI呼出しを，RTEGENが生成したAPI実装に変換 する必要がある．コントラクトフェーズのAPIマッピングは，RTE/SCHM API呼出しの生成関数への マッピングを提供する【rte_sws_3707】．

マッピング先の生成関数の命名則

Rte_<name>_<api_extension>形式のRTE APIに対応する生成関数名は以下の規則に従う

【rte_sws_3837】．

Rte_<name>_<c>_<api_extension>

ここで，

・ <name>はAPIルート名(例えば，Rte_Writeであれば，Write)，

・ <c>はSW-C型のショートネーム，

・ <api_extension>は<name>に依存するAPIの拡張子(例えば，Rte_Writeであれば，<p>_<o>)を

表す．

APIマッピングの生成例

SW-C<c1>のクライアントポート<p1>から，引数 1つのオペレーション<a>を行う Rte_Call の場合，

以下のAPIマッピングが生成される．

#define Rte_Call_p1_a Rte_Call_c1_p1_a

3.1.5.2 ジェネレーションフェーズ

コントラクトフェーズで生成されたAPIマッピングのマッピング先である生成関数は，ジェネレー ションフェーズにおいて生成する．

前述したように，APIマッピングはAPI名と適切な生成関数をマッピングする責任がある．

RTEGENは生成関数を提供する代わりに，より効率的な実装関数を提供してもよい【rte_sws_a_0044】．

この場合，APIマッピングは，RTE/SCHM APIからRTE/SCHM内の最適化された実装関数への中継 関数として動作する．本RTEGENでは，効率的な実装関数の提供による最適化を行わない

【nrte_sws_0041】．

マッピング先の生成関数の引数

生成関数は，APIマッピングと同じ順序で同じ引数を取る【rte_sws_1153】．

3.1.5.3 関数の省略

ジェネレーションフェーズのAPIマッピングを使用すると，関数を使用せず，マクロのみで

RTE/SCHM APIを実装することが可能になる．

APIマッピングは関数を使用せず，マクロのみのRTE/SCHM API実装を提供してもよい

【rte_sws_a_0045】．本RTEGENでは，マクロのみのRTE/SCHM API実装を提供しない

【nrte_sws_0042】．

APIマッピングがRTE/SCHM APIのための生成関数を使用しない場合，ジェネレーションフェーズ のAPIマッピングは，RTE/SCHM APIの呼出し元SW-C/BSWMに対し返り値を返し，SW-C/BSWM に変更なくRTE/SCHM APIが使用できることを保証する【rte_sws_1146】．

関数を使用しないAPIマッピングの生成例

ポートp1のデータ要素aに対するRte_Sendの場合，ジェネレーションフェーズのAPIマッピング は以下のように記述できる．

#define Rte_Send_p1_a(s, a) (<var> = (a), RTE_E_OK)

ここで，<var>は，送信側-受信側間の連携のために，RTEが生成するバッファのシンボル名であ る．

3.1.5.4 API命名規則

SW-Cはポート経由でその他のSW-C，およびBSWMと連携を行うため，RTE API名は以下を組み 合わせた名前となる【rte_sws_a_0051】．

・ APIのルート名(Rte_Writeであれば，Write)．

・ APIが動作する箇所(以下，APIアクセスポイント)．

ポート経由で動作するAPIの場合，APIアクセスポイントはポート名を含む．

S/Rインタフェースは複数のデータ要素，C/Sインタフェースは複数のオペレーションをサポートす る．そのためRTE APIは，APIアクセスポイント上のデータ要素名やオペレーション名を含むことに よって，ポート上のどのデータ要素，もしくはオペレーションにアクセスするかを示す．

またRTE APIは，RTEの名前空間内に含まれるため，シンボル名は接頭辞"Rte_"で始まる．

3.1.5.5 API引数

API引数は以下のいずれかに分類される．

API引数の分類 内容

IN引数 APIへの入力引数．API関数により内容が参照される．

OUT引数 APIの処理結果の出力引数．API関数により内容が更新される．

INOUT引数 APIへの入力，および処理結果の出力の両方に使用する引数．API関数

により内容が参照，および更新される．

"In"引数の値の引き渡し方法

プリミティブ実装データ型のIN引数への値の入力は値渡しで行う【rte_sws_1017】．

"Out"引数への参照先の引き渡し方法

プリミティブ実装データ型のOUT引数への参照先の入力は参照渡しで行う【rte_sws_1019】．

"In/Out"引数への参照先の引き渡し方法

プリミティブ実装データ型のINOUT引数への参照先の入力は参照渡しで行う【rte_sws_1020】．

3.1.5.6 エラー処理

RTEは，以下の2つのエラーを扱う．

エラー分類 内容

通信基盤エラー 資源獲得の失敗，もしくは不当な入力パラメータによって発生する エラー．このエラーは通信の失敗時等にBSWM，もしくはハードウ ェアで発生する．

アプリケーションエラー SW-Cによって通知されるエラー．

通信基盤エラーとアプリケーションエラーのどちらであるかは，SW-Cから識別可能である．

RTEは以下の契機で発生したアプリケーションエラーを扱うことができる．

・ C/S連携におけるサーバランナブルの返り値．

・ データセマンティックスのS/R連携におけるデータ無効化．

RTEでは，エラーおよび状態に関する情報はStd_ReturnType型により指定する．

RTE APIの呼び出しにおいて検出したエラーはAPIの返り値で呼び出し側に通知する．RTEは，エ

ラー状態(エラーなし状態を含む)を，RTE APIの返り値としてのみSW-Cに渡す【rte_sws_1034】．

あるRTE APIの呼び出しは通信サービスで非同期に動作する場合がある．その場合，APIからの返

り値はAPI呼出し中に検出したエラーのみを示す．API呼び出し完了後に検出したエラーは別のAPI により通知する．

3.1.6 同一でないポートインタフェース間の接続の扱い

提供側インタフェースのデータ要素やオペレーションのうち，要求側インタフェースに存在しない ような要素を，「未接続要素」と定義する．

提供側インタフェースのデータ要素，もしくはオペレーションに対して，「未接続要素」となるよう な要求側インタフェースのデータ要素，もしくはオペレーションを，接続されていないものとして扱 う【rte_sws_1369】．

以下の条件を満たす提供側データ要素について，Rte_Send，およびRte_Writeはポートが未接続で あるように動作する【rte_sws_1370】．

・ S/R連携の送信側ポートのあるデータ要素について，全ての接続先の要求側ポートにおいて「未 接続要素」となる．