AUTOSAR RTEとは？生成される実行環境の中身とSWC間通信を実装目線で解説

AUTOSAR RTE（Runtime Environment）は、Classic Platformでアプリケーション層と基盤ソフトウェア層の間に挟まる中間層です。特徴は、この層のコードを人が書かないこと。ポートと通信の定義から、ツールが丸ごと生成します。だからRTEを理解するとは、何がいつ生成され、生成物が実行時にどう振る舞うかを把握することだと言える。この記事では公式配布のR25-11仕様書（文書ID 84・全1609ページ）に沿って、二段階生成、明示と暗黙のアクセス、RTEイベントと排他区間、デバッグの入口までを実装解像度で整理しました。

まとめ｜RTE層で実装者が実際に決める二つのこと

RTEについて実装者が判断する余地は、見た目ほど広くありません。コードは生成物であり、書き換えれば次の生成で消えるからです。実際に決めるのは次の2点に絞られる。

1点目はコントラクトフェーズの出力をいつ凍結するか。RTEジェネレータはSWCの型と内部挙動の記述だけからアプリケーションヘッダを先に吐けます。早く固めればSWC実装を並行して進められる一方、ポート名を後から変えるとAPI名が丸ごと変わる。命名の確定を実装着手より前に置くかどうかという運用の問題です。

2点目はSender-Receiver通信を明示にするか暗黙にするか。明示（Rte_Read・Rte_Write）は呼んだ瞬間に値が動く。暗黙（Rte_IRead・Rte_IWrite）はランナブル開始時にコピーが作られ、終了までそのコピーが変わらないことをRTEが保証します。周期処理で同じ値を何度も読むなら暗黙、外部イベントへ即応したいなら明示。暗黙を選べるのはランナブルが確実に終了する場合だけです。

RTEとは何か｜VFBの仮想結合をECU単位の実配線へ落とす層

Classic Platformの階層は、上からApplication Layer、RTE、Basic Software（BSW）の3層です。R25-11のLayered Software Architecture（文書ID 53・2025年11月27日付）は、RTEをECUごとに個別生成される層と明記している。BSWがECUハードウェアを抽象化するのに対し、RTEが抽象化するのは通信相手の居場所です。

仮想機能バス（VFB）の実体化としてRTEに与えられた役割と範囲

AUTOSARの設計では、まずVFB（Virtual Functional Bus）という仮想のバスの上に全SWCがつながっている、という前提で機能を設計します。この段階でSWCは、相手が同じECU上のSWCなのか、CANの向こうにいる別ECUなのかを知りません。

その仮想の結線を、実際のECU割り当てに従って本物のコードへ落とすのがRTEです。同一ECU内なら関数呼び出しやバッファのコピー、ECUをまたぐならCOM経由のシグナル送信へ変換される。SWC側のソースは、どちらに変換されても1文字も変わりません。車載ネットワークとは？CAN・LIN・FlexRay・車載Ethernetの違いと選び方を実装目線で解説で扱った物理層の選択がSWC実装から見えなくなるのは、この仕組みによります。

RTEが生成するファイル群とRte_接頭辞という命名規約の中身

RTEが吐くファイルには名前の規約があります。仕様書5.3.1は、Rte.hとRte.cを除くRTEの全ファイルにRte_接頭辞を付けると定めている。主なものは次の通りです。

SWCの実装ファイルがインクルードするのは、自分専用のアプリケーションヘッダ1本だけです。SWCの名前がmySwcならRte_mySwc.h。ここには、そのSWCのポートから導かれるAPI宣言しか並びません。記述に無い通信を実装から呼ぶことは構造上できない、という設計になっている。

RTEの二段階生成｜契約フェーズと生成フェーズを分ける理由と効果

RTEジェネレータは1回では動きません。仕様書は生成プロセスを、コントラクトフェーズと生成フェーズの二段に分けています。この分割が、SWC実装とECU構成を別々のチームで同時に進めるための土台になっている。

コントラクトフェーズが出すのはヘッダ1本だけという割り切り方

コントラクトフェーズの入力は、SWCの型記述（ポートとインタフェース）と内部挙動記述（ランナブルとRTEイベント）の2つだけです。ECU構成も、どのSWCがどのECUに載るかも要りません。出力はアプリケーションヘッダ1本。

仕様書3.1.1は、このヘッダさえあればSWC開発者は「通信が後でローカルになるのかネットワーク越しになるのかを気にせず」ソースコードを提供できると明記し、同時に記述が変わるたびの再生成が要ることも断っています。AUTOSAR開発の工程とは？ARXMLの受け渡しとツールチェーンを実装目線で解説で整理した工程順序のうち、実装チームが最初に受け取る成果物がこのヘッダにあたる。

生成フェーズでAPI呼び出しが消えるFunction Elision

生成フェーズはECU Configuration Valuesを入力に、RTE本体を生成します。ここでAPIマッピングが確定する。仕様書5.2.6.3が定めるFunction Elisionは、通信が単純な代入で済む構成のとき、RTE関数そのものを生成せずマクロへ置き換える仕組みです。

仕様書の例ではRte_Send_p1_aの呼び出しがカンマ式のマクロへ置換され、戻り値だけStd_ReturnTypeとして返るよう保たれます。SWC側のソースは変えずに済む代わりに、実行時にはその関数がどこにも存在しない。ブレークポイントを張ろうとして関数が見つからないとき、まず疑うのがこれです。

静的解析との衝突も実務に効きます。仕様書は脚注で、この置換がMISRA Rule 12.3（カンマ演算子を使うべきでない）に反すると認めたうえで、カンマ式でなければ実現できないため規則を緩める必要があると明記している。生成コードをMISRA検査に含めている現場では、ここが恒常的な逸脱申請の対象になります。

Sender-Receiver通信｜明示アクセスと暗黙アクセスの分かれ目

データを流す側の通信がSender-Receiverです。仕様書SWS_Rte_06011は、明示（explicit）と暗黙（implicit）の両方をRTEがサポートすると規定する。

明示アクセスでAPIを呼んだ時点に送受信が起こる仕組みと使い分け

明示アクセスでは、ランナブルが自分でRte_WriteやRte_Readを呼びます。キューを持つ構成ではRte_SendとRte_Receive、直近値だけ欲しいならRte_DRead。ポート構成とランナブルのカテゴリ次第で、呼び出しはブロックする場合としない場合があります。

送信の成否はRte_Feedback、無効値としての明示的な潰しはRte_Invalidateで扱う。受信側が「未受信」と「無効値を受信」を区別できる点が、グローバル変数の共有との差です。

暗黙アクセスがコピー戦略でデータ一貫性を保証する仕組みと前提

暗黙アクセスでは、ランナブルはAPIを呼んで通信を起こしません。記述側でdataReadAccessロールのVariableAccessを付けておくと、RTEはランナブル開始時に必要な値を読み、必要ならコピーを作ります。ランナブルはRte_IReadでそのコピーを読む。仕様書は、このコピーがランナブルの生存期間を通じて他者の書き込みで変化しないことをRTEが保証すると明記しています。

書き込み側も同じで、Rte_IWriteで書いた値が他のランナブルから見えるのは最も早くてランナブル終了時です。周期タスク内で同じ入力を10回読む処理は、暗黙なら10回とも同じ値になる。

ただし前提があります。仕様書は「この概念はランナブルが実際に終了することを含意する」と断り、有限の実行時間が保証されるのはカテゴリ1Aと1Bだけだと明記している。長く待つランナブルに暗黙アクセスを付けると、コピー用のバッファが滞留します。

明示アクセスと暗黙アクセスのどちらを選ぶかを分ける五つの観点

データ一貫性を保つ手段として仕様書4.2.6.4が挙げるのは、割り込みブロック・OSリソースの使用・タスクブロック・コピー戦略の4系統です。暗黙アクセスの実体は最後のコピー戦略にあたる。

複数接続の扱いも要注意です。n対1も1対mも可能ですが、同一ECU上であっても複数の受信者が同時に同じ値を見る保証はないと仕様書4.3.1.4が明記している。

Client-Server通信とランナブル起動｜16種のRTEイベント

処理を依頼する側の通信がClient-Serverです。呼ぶ側はRte_Callを発行し、サーバ側のランナブルがOperationInvokedEventで起動します。

同期と非同期を一つのAPIで扱うRte_Callの二つの制約

仕様書5.6.13は、Rte_Callを同期呼び出しと非同期呼び出しの両方に使うと定めています。どちらが生成されるかは記述側のServerCallPointの種類で決まる。非同期の結果はRte_Resultか、AsynchronousServerCallReturnsEventで起きるランナブルが受けます。

制約が二つあります。SWS_Rte_03014により、同一オペレーションに同期と非同期のServerCallPointを両方持つ構成は不正。そしてCONSTR_09024により、Rte_Callは対応するServerCallPointを記述に持つランナブルからしか呼べません。共通のラッパ関数にまとめて複数ランナブルから呼ぶ書き方が通らないのは、このためです。

ランナブルの起動契機を決めるRTEイベント16種と待ち合わせ

ランナブルはRTEイベントによって起動します。R25-11の仕様書4.2.2.4が定義するのは16種類。時間駆動のTimingEventとBackgroundEvent、Sender-Receiver系の4種、Client-Server系の2種、モード系の3種、トリガ系の2種、そしてInitEvent・TransformerHardErrorEvent・OsTaskExecutionEventです。

各イベントは、ランナブルを起動する（ACT）か、WaitPointで待っているランナブルを起こす（WUP）かのどちらかに対応します。仕様書はメタモデル上あらゆる組み合わせが書ける点を認めたうえで、周期的なTimingEventで解決されるWaitPointのように意味をなさない組み合わせには制限を課している。

OSタスクへの割り付けはECU構成側の仕事で、RTEはその写像に従ってタスク本体を生成します。優先度やプリエンプションの設計はRTOSとは？リアルタイムOSの仕組み・主要製品の比較と採用判断を実装者目線で解説で扱ったリアルタイムOSの議論と地続きです。

排他区間を開くRte_Enterとネストの順序に関する二つの規定

クリティカルセクションはExclusiveAreaとして記述し、実装からはRte_Enterで入りRte_Exitで出ます。仕様書4.2.6.5は、ExclusiveAreaが具体的な実装方式ではなく作業モデルだと断っている。割り込み禁止になるのかOSリソースが取られるのかは、生成時の構成で決まります。

ネストにも規定があります。SWS_Rte_01122は、異なる排他区間を入った順の逆順で抜ける限りネストを許すと定める。裏を返せば同一の排他区間に対する入れ子はRTEに要求されていないので、再帰的に入るコードは書けません。

もう一つがソフトウェアクラスタ向けの制限です。SWS_Rte_08922は、Application Software Cluster向けの生成時にSuspendAllInterruptsなどの割り込み制御APIを呼んではならないと定めている。Os High Proxyが未対応のためで、クラスタ分割を入れると一貫性の手段はコピー戦略とOS資源へ寄ります。

BSWとの境界｜RTEとBasic Software Schedulerの受け持ち

RTEが面倒を見るのはSWCです。BSWモジュール側の実行制御は、Basic Software Scheduler（SchM）という別の仕組みが担います。同じRTEジェネレータが両方を生成するため実務では混同されやすいものの、仕様書上は明確に分かれている。

SchMが受け持つBSWモジュール側の実行制御と記述要素の対応

SWC側がInternalBehavior・RunnableEntity・RTEEventで記述されるのに対し、BSW側はBSW Module Description・BswInternalBehavior・BswSchedulableEntity・BswEventで記述されます。生成プロセスも、BSWスケジューラ側のコントラクトフェーズと生成フェーズが独立して置かれている。

実装者から見た効き目は、BSWモジュールの周期関数をタスクへ載せる作業がSWCのランナブル割り付けとは別枠になる点にあります。タスクやアラームなどOSオブジェクト側の仕様はAUTOSAR OSとは？OSEK由来の仕様とスケーラビリティクラスの選び方を実装目線で解説で扱っています。生成ログのエラーがどちら側かで切り分けが速くなる。

R25-11で入った周期受信APIとLdCom統合の影響範囲

R25-11（2025年11月27日付）でRTE仕様に入った変更は3点です。通信データの周期処理サポートの追加、vendor modeのサポート削除、そしてLdCom機能をLarge Data PathとしてCOMへ統合したことに伴う調整。

1点目の実体がRte_ComDataMainFunctionです。仕様書5.6.46によれば、RteComDataMappingごとにこのAPIが生成され、RteComDataMainFunctionOsTaskRefが指すタスクから実行するとComSignalやComSignalGroupの周期受信が起きます。受信をイベント駆動ではなく周期側へ寄せる入口が、標準として用意されたことになる。

3点目は移行時に効きます。従来LdComモジュールを直接参照していたECU構成は、統合後のCOM側の記述へ読み替えが要る。R25-11へ上げる作業を見積もるなら、LdComの利用有無を最初に確認しておく価値があります。

生成物のデバッグ観点｜VFBトレースの設定と最初に見るべき場所

RTEのコードは生成物なので、手書きのソースと同じ感覚では追えません。仕様書はデバッグ用にVFBトレースを標準化しています。

VFBトレースを二段構えで有効化する設定と生成までの流れの全体

VFBトレースは、SWCがVFBとやりとりする瞬間にフック関数を呼ぶ仕組みです。有効化は二段構え。まずRteVfbTraceEnabledがRTE生成時に機能全体の可否を決め、無効ならフックは一切呼ばれません。そのうえでRteVfbTraceFunctionが「どのフックを呼ぶか」を接頭辞で絞ります。

ワークフローは3段階です。構成フェーズでトレースクライアントがRteVfbTraceClientコンテナを作る。次にRTE生成でフック呼び出し込みのRTEが生成され、RTEのBSWMDに呼ぶフックとシグネチャが記録されます。最後にトレースクライアント側がそれを読んでフックを実装する。

注意点が二つあります。RTEはシグネチャは分かってもswServiceImplPolicyとMemorySectionまでは判断できないため、その補完はクライアント側の責任になる。そして仕様書は、このトレースがSWCのデバッグを意図したものでRTE自体のデバッグ用ではないと明記しています。旧リリースでコンパイルスイッチが担っていた切り替えも、責務がトレースクライアント側へ移りました。

生成されたコードを開いたときに最初に確認する三つの場所と順序

実機で挙動が合わないときは、次の順で見ます。

• タスク本体：ランナブルがどの順で呼ばれているか。記述上の意図と割り付け結果のずれを見る
• アプリケーションヘッダのマクロ定義：Function Elisionで消えた呼び出しがないかを潰す
• 排他区間の展開結果：割り込み禁止かOSリソースか。想定より広く止めていないか

計測系の入口は別で、仕様書4.2.9が規定するMcSupportDataの生成物がXCPなどから変数を見るときの土台になります。

RTE周りで手戻りを招きやすい三つのパターンと事前に打てる手

現場で繰り返し起きるつまずきは、次の3つに集約されます。

• 名前変更の波及：API名はポート名とデータ要素名から組み立てられるため、ARXML側で1つ改名すると実装側の呼び出しが軒並みコンパイルエラーになる。命名の凍結時期を決めるのが唯一の予防策
• 暗黙アクセスの付けすぎ：一貫性が自動で得られる代わりに、コピー用のRAMがSWCの数だけ積み上がる。制約に当たってから剥がすのは骨が折れる
• 未接続ポートの既定値：仕様書5.2.7が結線前のふるまいを規定している。中間ビルドで想定外の初期値が返るのは仕様どおりの挙動で不具合ではない

受託開発でRTE層をどこまで引き受けるかの線引きと三つの条件

受託側が引き受けやすい層と社内に残すべき層を分ける二つの基準

受託側が引き受けやすいのは、アプリケーションヘッダが確定した後のSWC実装です。この段階まで来ればRTEのAPIは宣言として与えられており、中身は通常のC実装に近づく。制御アルゴリズム、単体テスト用スタブ、計測とログの仕込み、上位のデータ処理はいずれも切り出せます。

逆に社内へ残すべきなのは、ECU Configurationの全体設計とRTE生成の運用です。どのランナブルをどのタスクへ割り付けるかは車両全体のタイミング設計と直結するため、部分委託が成立しません。

RTE周辺の委託を見送るべき三つの条件と代わりに取るべき進め方

次のいずれかに当てはまる場合、RTE周辺の委託は見送ったほうが結果が良くなります。

• 対象機能のASILがCまたはDで、機能安全の作業成果物まで含めて委託しようとしている場合
• ARXMLの命名がまだ流動的で、アプリケーションヘッダを凍結できていない場合
• RTEジェネレータのライセンスが受託側に無く、生成結果を発注側でしか再現できない場合

2番目に当たるなら、順序を入れ替えるだけで解けます。命名を先に確定させ、コントラクトフェーズを回してヘッダを配布してから実装を出す。この順序なら委託範囲は「ヘッダのAPIを使うC実装」という検収しやすい単位に収まります。

当社では、車載に隣接する組み込み領域とIoTのソフトウェア開発をAI/IoTソリューションとして承っています。どこから外部の手を入れられるかの整理からご相談ください。

よくある質問

RTEのコードを手で書いたり修正したりしてよいですか？

やめたほうがよいです。RTEは生成される成果物なので、手を入れても次の生成で消えます。挙動を変えたいなら記述か構成の側を直し、生成し直すのが正しい手順になる。

Rte_ReadとRte_IReadはどちらを使うべきですか？

周期処理で同じ値を複数回参照するならRte_IRead、外部イベントへ即応したいならRte_Readが向きます。ただし暗黙アクセスはランナブルの終了が前提なので、待ち合わせを持つカテゴリ2には使えません。

アプリケーションヘッダはいつ再生成が必要になりますか？

SWCの型記述か内部挙動記述を変えたときです。ポートの追加、データ要素の改名、ランナブルやRTEイベントの変更はいずれもAPI宣言に影響する。仕様書自体が開発を反復的なものと位置づけ、記述の変更に応じた再生成を前提としています。

RTEはAdaptive Platformにも同じものがありますか？

ありません。RTEはClassic Platform側の仕組みで、Adaptive Platformではara::comを含むARAがその役割を担います。生成物の考え方も責務の切り方も異なるため、Adaptive AUTOSARとは？Classic Platformとの違いと使い分けを実装目線で解説を併せてご確認ください。

RTEの仕様書はどこから入手できますか？

AUTOSAR公式サイトのStandards配下で、Classic PlatformのリリースごとにPDFが公開されています。本記事が参照したSpecification of RTE Softwareは文書ID 84・R25-11版で全1609ページ。閲覧に費用はかかりません。

関連記事

• AUTOSAR開発の工程とは？ARXMLの受け渡しとツールチェーンを実装目線で解説：RTE生成に至るまでの工程と成果物
• Adaptive AUTOSARとは？Classic Platformとの違いと使い分けを実装目線で解説：RTEに相当するAP側の仕組み
• RTOSとは？リアルタイムOSの仕組み・主要製品の比較と採用判断を実装者目線で解説：ランナブルを載せるタスク設計