2026.08.23 17 人が閲覧（直近 30 日）アーキテクチャ

AUTOSAR OSとは？OSEK由来の仕様とスケーラビリティクラスの選び方を実装目線で解説

AUTOSAR OSは、Classic Platformの基盤ソフトウェア層に置かれるリアルタイムOSの仕様です。製品名ではなく仕様書の名前であり、実体はベンダー各社の実装として供給される。土台はISO 17356-3として標準化されたOSEK OSで、そこへ保護機能と段階的な構成の枠組みを足したものだと考えると輪郭がつかめます。この記事では公式配布のR25-11仕様書（文書ID 34・全410ページ）に沿って、OSオブジェクトの関係、二種類の保護、SC1〜SC4の差、そして汎用RTOSとの選び分けまでを実装解像度で整理しました。

まとめ｜AUTOSAR OSの構成で最初に決まる二つのこと

AUTOSAR OSを載せると決めた後、構成の議論は結局この2点へ収束します。

1点目はスケーラビリティクラスをどれにするか。SC1からSC4までの4段階は機能の多寡ではなく、ハードウェアに何を要求するかの段階です。メモリ保護を使うならMPUが要り、タイミング保護を使うなら高優先度割り込みを持つタイマが要る。マイコンの選定と同時に決まる話であって、ソフトの都合だけで後から上げ下げできる設定ではありません。

2点目は保護違反をどう扱うか。AUTOSAR OSは締切を監視しません。仕様書7.7.2.1は、締切を落としたタスクが原因のタスクとは限らないという理由を明示したうえで、実行予算・ロック予算・到着間隔の3つを直接縛る道を選んでいる。この設計を知らないまま「デッドライン監視があるはず」という前提で構成すると、検出したい事象が最後まで検出されないまま統合試験へ入ることになる。

AUTOSAR OSとは何か｜OSEK OSを土台に保護を足した仕様

AUTOSAR OSは、ゼロから設計されたOSではありません。仕様書7.1.1は、OSEK OSの概念が自動車業界で広く理解され実績があることを理由に、中核機能をOSEK OSへ置くと述べています。上位概念としてのOS分類は組み込みOSとは？3分類の境界とITRON系の位置づけ・選定判断を実装者向けに解説で扱った枠の中で、車載制御系に振り切った位置にあると考えてください。

OSEK OS由来の中核機能と後方互換が保たれている仕様範囲

参照文献として挙がっているのはISO 17356-3、つまりOSEK/VDX OSの国際標準版です。SWS_Os_00001は、OSEK OSのAPIと後方互換なAPIを提供することをOSモジュールへ要求している。OSEK OS向けに書かれた既存のアプリケーションがそのまま動くという前提が、仕様の側から保証されているわけです。

OSEK OSから引き継いだ性質としては、固定優先度ベースのスケジューリング、割り込みの扱い、タスクより高い優先度でしか割り込みが走らないこと、StartOSとStartupHookによる起動、ShutdownOSとShutdownHookによる停止が挙げられている。イベント駆動型であることも明記されており、回転角・ローカル時刻・グローバル時刻・エラー発生といった任意の事象をスケジューリングの契機に選べます。

AUTOSAR OSがOSEKへ課した制限と足した拡張の中身

後方互換とはいえ、保護機能を成立させるために制限も入っています。代表的なものは3つ。アラームコールバックはSC1でのみ許可される（SWS_Os_00242）。OSEKで常に存在し最高優先度を持つ特別なリソースRES_SCHEDULERは、AUTOSAR OSでは自動生成されず他のリソースと同じ扱いになる。DeclareTaskのようなオブジェクト宣言マクロは、互換のため用意はするが機能を持たない空実装でよいとされている。

逆に足されたものもあります。アラーム満了時の動作としてソフトウェアカウンタを加算できるようになり、OSEKでは相対アラームだけだった自動起動が絶対アラームでも可能になった。拡張ステータスではAPIのポインタ引数がNULLかどうかを検査し、E_OS_ILLEGAL_ADDRESSを返すことも規定されています。OSEKで未定義だった振る舞いを潰していく作業が、この節の実質です。

タスクとカウンタとアラームというOSオブジェクト間の依存関係

AUTOSAR OSが管理するオブジェクトは、タスク・ISR・カウンタ・アラーム・ScheduleTableの5種です。SWCのランナブルがどのタスクへ載るかはECU構成側で決まり、RTEがその写像に従ってタスク本体を生成する。生成側の詳細はAUTOSAR RTEとは？生成される実行環境の中身とSWC間通信を実装目線で解説にまとめてあります。

基本タスクと拡張タスクを分ける待ち状態の有無という判断基準の違い

タスクは2種類あり、区別は単純です。自分で待ちに入れないのが基本タスク、OSイベントを待って自らブロックできるのが拡張タスクだと仕様書の用語集は定義している。

この差は状態遷移の数に直結します。基本タスクはSUSPENDED・READY・RUNNINGの3状態で回るのに対し、拡張タスクにはWAITINGが加わる。待てるということはスタックを保持したまま停まるということでもあり、メモリの要求量にも跳ね返ってきます。周期処理の大半は基本タスクで足りるので、拡張タスクは待ち合わせが本当に必要な箇所へ絞るのが定石です。

カウンタを起点にアラームが動く仕組みと設定時に生じる制約条件

時間の起点になるのはカウンタです。タイマなどハードウェアが値を進めるハードウェアカウンタと、IncrementCounterの呼び出しで進むソフトウェアカウンタの2系統がある。アラームはそのカウンタに紐づくソフトタイマで、満了時にタスク起動・イベント設定・カウンタ加算・コールバック実行のいずれかを起こします。

設定側には制約が付きます。相対アラームのSetRelAlarmにincrement=0を渡した場合、標準ステータスでも拡張ステータスでもE_OS_VALUEを返すと規定されている。OSEKでは未定義だった箇所を塞いだ例で、ゼロを渡して「即時満了」を期待する書き方は通りません。

ScheduleTableがアラームの寄せ集めと異なる実行上の理由

周期起動を組むだけなら、カウンタと自動起動アラームを並べれば実現できます。ではなぜScheduleTableという別の仕組みが用意されているのか。仕様書7.3.1が挙げる理由は同期です。

満了点の集合として静的に定義される構造とタスク実行の順序関係

アラームを並べた構成では、実行時に位相を変えようとすると相互の相対関係が崩れます。崩さずに変えるには、カウンタのティック割り込みを止めた状態で複数のアラームをまとめて書き換えるしかない。ScheduleTableは、この面倒を構造で回避しています。

構成要素	内容	仕様上の制約
満了点	起動するタスクと設定するイベント	最低1つの動作を持つ
オフセット	表の先頭からのティック数	表の中で一意にする
デュレーション	表全体の長さ（法）	ゼロから測る
駆動カウンタ	反復を進める時間源	厳密に1個へ紐づける

R25-11では満了点にもう一つ役割が増えました。SWS_Os_00876により、満了点からタスクの実行予算を補充できる。後述するDeferrable Serverと組み合わせるための追加です。

グローバル時刻へ同期させる二方式と構成ごとの使い分けの判断基準

ScheduleTableは複数を並行して処理できます。そのうえで、外部の時刻源へ位相を合わせる同期が用意されている。暗黙同期は駆動カウンタ自体がグローバル時刻を表す場合に成り立ち、明示同期はSyncScheduleTableで現在の時刻を与えてズレを詰めていく方式です。

使い分けの判断は構成側の事情で決まります。時刻源の刻みがそのままカウンタになるなら暗黙で足りる。ネットワーク経由でグローバル時刻を受け取り、その値でECU内の位相を合わせにいくなら明示になります。なお同期系のAPIはSC2とSC4でのみ提供されるため、クラス選定と切り離せません。

メモリ保護とタイミング保護がOS-Application単位で効く仕組み

保護機能を語るとき、単位になるのはタスクではなくOS-Applicationです。仕様書7.6は、タスク・ISR・アラーム・ScheduleTable・カウンタをひとまとまりの機能単位として束ねたものと定義している。ここに信頼と非信頼という2つのクラスがあります。

信頼と非信頼のOS-Applicationで変わるアクセス権の境目

メモリ保護が成り立つのは、ハードウェア支援のある処理器に限られます。保護の対象は実行プログラムのデータ・コード・スタックの各セクションで、OSは自身のデータとスタックへの非信頼側からの書き込みを防ぐ。非信頼のOS-Applicationは、割り当てられた周辺デバイス以外へ書き込めません。

逆に、保護が届かない場所もはっきり書かれています。カテゴリ1 ISRは実行そのものをOSが把握していないため保護できず、保護を求めるなら避けるか信頼側のOS-Applicationへ入れるしかない。同じタスク本体から呼ばれる関数どうしの保護も不可能です。違反を検出したときはE_OS_PROTECTION_MEMORYを伴ってProtectionHookが呼ばれます。

実行時間とロック時間と到着間隔の三つを縛る保護条件と監視単位

タイミング保護の設計思想は独特です。仕様書は締切監視を採らないと明言し、その理由を例で示している。高優先度タスクAと中優先度タスクBが仕様より長く走り、Bが予定より早く到着すると、正しく動いている低優先度タスクCだけが締切を落とす。障害の伝播であり、締切を落とした側を止めても原因は残ります。

縛る対象	設定する値	典型的な検出対象
実行時間	実行予算という上限	タスクの走りすぎ
ロック時間	ロック予算という上限	割り込み禁止の長期化
到着間隔	時間枠という下限	割り込みの過剰な多発

到着間隔保護の用途として仕様書が挙げるのは、他ECUからフレームを受け取るたびに割り込むCANコントローラのような多発源です。CAN通信とは？CANバスの仕組み・アービトレーションとCAN FDの違いを実装目線で解説で扱ったバス側の異常が、ECU内部の時間資源を食い潰す経路をここで塞ぎます。

R25-11で入ったDeferrable Serverと予算枯渇状態の扱い

従来、予算超過を検出したときの反応はProtectionHookの呼び出しに限られ、実際の対処はタスクの強制終了かOS停止という破壊的なものへ寄りがちでした。R25-11の変更履歴に載る「非周期サーバ向けタイミング保護の拡張」が、この選択肢を増やしています。

該当タスクにOsTaskTimingProtectionDeferrableServerを設定すると、予算を使い切った時点でBUDGET_EXHAUSTEDという状態へ静かに退避し、OSは別のタスクを走らせる。補充されるまでスケジュールされないという扱いです。補充はBudgetReplenishの呼び出し・アラームの動作・ScheduleTableの満了点のいずれかで行い、補充の責任は利用者側にある。周期アラームで定期的に補充する構成が想定例として示されています。

スケーラビリティクラスSC1〜SC4の機能差とハードウェア前提条件

4つのクラスは、機能をグループにまとめて構成を段階化したものです。仕様書7.11のSWS_Os_00241が対照表を持っており、どのクラスで何が有効になり、そのために何のハードウェアが要るかが1枚で分かります。

四つのクラスで有効になる保護機能とハードウェア前提の違いを示す対照表

機能	SC1	SC2	SC3	SC4	ハード前提
OSEK OS中核	有	有	有	有	なし
ScheduleTable	有	有	有	有	なし
スタック監視	有	有	有	有	なし
タイミング保護	—	有	—	有	高優先度のタイマ
時刻同期支援	—	有	—	有	グローバル時刻源
メモリ保護	—	—	有	有	MPU
サービス保護	—	—	有	有	なし
信頼関数の呼出	—	—	有	有	特権と非特権モード

数の下限も定められています。ScheduleTableの最小サポート数はSC1とSC3が2、SC2とSC4が8。OS-Applicationの最小数はSC3とSC4が2で、SC1とSC2は0。ソフトウェアカウンタは4クラスとも8が下限です。

クラスを上げたときにOS構成へ跳ね返る三つの制約条件と実装負担

上位クラスを選ぶと、設定側にも影響が出ます。押さえておきたいのは3点。

第一に、SC3とSC4では常に拡張ステータスが使われる（SWS_Os_00327）。標準ステータス前提のコードサイズ見積もりは崩れます。第二に、アラームコールバックはSC1でしか許可されないため、SC2以上へ上げる構成変更ではコールバックを別の手段へ置き換える作業が発生する。第三に、単一コアではOS-ApplicationがSC3とSC4でしか使えない一方、マルチコアではSC1とSC2でもOS-Applicationを扱えると規定されており、コア数によって前提が変わります。設定値がどの工程へ跳ね返るかという観点はAUTOSAR開発の工程とは？ARXMLの受け渡しとツールチェーンを実装目線で解説で整理しました。

マルチコア構成で増えるスピンロックとIOCの役割および制約条件

マルチコアのECUでは、単一コアには無かった仕組みが2つ加わります。コアをまたぐ排他制御としてのスピンロックと、コアや保護境界をまたぐ通信としてのIOCです。

スピンロックがデッドロックを招く二つの典型パターンと回避策の原則

スピンロックはロック変数をポーリングするビジーウェイトの仕組みで、OSEKのリソース型に似たSpinlockTypeをオフラインで構成します。用途は他コア上のタスクとの排他に限られ、同一コア上のタスク間で使うとエラーが返る。意味を成さないからです。

仕様書はデッドロックの型を2つ図で示しています。1つは、低優先度タスクがロックを持ったまま、同じコアで高優先度タスクが起きて延々とスピンする型。SuspendAllInterruptsで囲うか、OsSpinlockLockMethodでOSに自動でやらせて防ぎます。もう1つは、2コアが別々の順序で2つのロックを取る型。異なるスピンロックの入れ子は原則として禁止され、入れ子にするなら循環のない一意な順序を定義し、解放はLIFOで行うと定められている。

コアや保護境界を越える通信をIOCが担う範囲と設定上の制約条件

IOCはInter OS-Application Communicatorの略で、SWS_Os_00671によりOSの一部として実装されると規定されています。位置づけは第3の通信経路です。OS-Application内部の通信はRTEが扱い、ECU間の通信はCOMが扱う。その間に残るコア間・メモリ保護境界間の通信をIOCが受け持ちます。

実装上の注意として、OSコードとIOCコードは同じベンダーのジェネレータから、同じOS構成をもとに生成すべきだと明記されている。ソフトウェアクラスタごとに複数のIOCインスタンスを生成する構成では、OS側のコードが特定のIOC構成へ依存しないことが前提になります。

汎用RTOSとAUTOSAR OSのどちらを選ぶかの判断条件

ここまでの内容を選定の言葉に置き換えます。AUTOSAR OSは万能の上位互換ではなく、AUTOSAR CPの構成に組み込まれることを前提にした仕様です。単体で採用する対象ではありません。

AUTOSAR OSを選ぶ条件と汎用RTOSで要件を満たせる場面

AUTOSAR OSが要るのは、次の3条件が揃う場合だと考えてよい。ECUがAUTOSAR CPのBSW構成を採る、SWCとRTEを介した構成管理を前提に組織をまたいで成果物をやり取りする、そしてメモリ保護かタイミング保護のどちらかを設定で担保する必要がある。3つ目が無ければ、機能面では汎用RTOSでも同等のことは書けます。

逆に、単発の制御ボードやAUTOSARを採らない産業機器では、汎用RTOSのほうが構成も調達も軽い。概念と製品比較はRTOSとは？リアルタイムOSの仕組み・主要製品の比較と採用判断を実装者目線で解説を、POSIX系のマイクロカーネル製品を検討するならQNXとは？マイクロカーネル型RTOSの構造とSDP 8.0・安全認証から採用判断まで実装者向けに解説を先に読むほうが早い。OSの選択はマイコンとE/E構成の選択とほぼ同義で、ソフト側だけで決められる領域は思うより狭いのです。

受託開発でOS層に関与できる範囲と案件を見送るべき条件の判断基準

受託の立場でOS層に関われるのは、OSそのものの実装ではありません。現実的な範囲は、タスクとランナブルの割り付け設計、ScheduleTableの構成、保護設定とProtectionHookの実装、そして予算値を決めるための実行時間計測です。OSカーネル自体はベンダー実装を使うため、ここへ手を入れる話は原則として出てきません。

見送るべき条件も明確にしておきます。安全水準の割り当てが未確定のまま保護設定だけ先に決めたい案件、OS実装ベンダーとツールチェーンが未定の案件、そして予算値の根拠になる実行時間の計測環境が用意できない案件。いずれも後から構成をやり直す確率が高く、工数見積もりが成立しません。組み込み寄りの周辺開発からの接続を検討するなら、AI・IoTソリューションで扱っている範囲を出発点にしてもらうと話が早いはずです。

よくある質問

AUTOSAR OSとOSEK OSは別物ですか？

別物ではなく、OSEK OSを中核に据えた上位の仕様です。仕様書はOSEK OS（ISO 17356-3）のAPIとの後方互換を要求しており、OSEK OS向けのアプリケーションはAUTOSAR OS上で動くという前提が置かれている。ただしアラームコールバックやRES_SCHEDULERの扱いなど、保護機能を成立させるための制限は加わっています。

AUTOSAR OSに締切の監視機能はありますか？

ありません。仕様書7.7.2.1が、デッドライン監視ではタイミング障害を起こした当事者を正しく特定できないという理由を挙げて採用していません。代わりに実行予算・ロック予算・時間枠という3つの上限と下限を直接縛る方式が採られています。

スケーラビリティクラスは後から変更できますか？

設定値としては変更できますが、実質はハードウェアの選定と一体です。メモリ保護にはMPU、タイミング保護には高優先度割り込みを持つタイマ、時刻同期にはグローバル時刻源が要る。加えてSC3以上では常に拡張ステータスになるため、コードサイズと処理時間の見積もりもやり直しになります。

カテゴリ1 ISRは使わないほうがよいのですか？

保護機能を効かせたい構成では避けるのが基本です。カテゴリ1 ISRはOSが起動を把握しないため、実行中は保護が働きません。どうしても使う場合、OS-Applicationを併用する構成では信頼側のOS-Applicationへ所属させる必要があると規定されています。タイミング保護との併用も仕様書は勧めていません。