Azure RTOS

解決する課題

センサーやコントローラなどの小さな組み込み機器は、メモリが数十 KB から数百 KB しかなく、汎用 OS を載せる余裕がありません。一方で、決められた時間内に確実に応答するリアルタイム性や、ネットワーク接続・暗号化といった IoT 機能は求められます。Azure RTOS は、こうした資源制約の厳しいマイコンに対して、小さく決定論的な実行基盤と組み込み向けライブラリ一式を提供します。

• 限られた RAM/ROM でも動く軽量な OS が欲しい
• 制御や計測で、応答時間を読める決定論的なスケジューリングが必要
• TCP/IP・USB・ファイルシステム・GUI などを自前実装せずまとめて使いたい
• IoT 機器をクラウドへ安全につなぐための接続・暗号化スタックを組み込みたい
• 製品ファームウェアに使える実績と保守性のある基盤を選びたい

主要概念と用語

• ThreadX: Azure RTOS の中核となるリアルタイムカーネル。スレッド管理・スケジューリング・同期・割り込み処理を担う
• スレッド: 実行単位。優先度を持ち、優先度ベースのプリエンプティブスケジューリングで切り替えられる
• プリエンプティブスケジューリング: 高優先度のスレッドが実行可能になると、低優先度スレッドを中断して即座に切り替える方式。応答時間の予測を可能にする
• NetX / NetX Duo: 組み込み向けの TCP/IP ネットワークスタック。IPv4/IPv6 や各種プロトコルを提供する
• FileX: FAT 互換の組み込みファイルシステム
• USBX: 組み込み向けの USB ホスト/デバイススタック
• GUIX: 組み込み機器の画面描画を担う GUI ライブラリ
• 決定論的（deterministic）: 同じ条件なら処理時間がほぼ一定で予測できる性質。リアルタイム制御の前提になる
• Eclipse ThreadX: Azure RTOS をオープンソース化したプロジェクト名。コードベースは共通で、MIT ライセンスで公開されている

仕様・制限・クォータ

• 対象はマイコン: Arm Cortex-M をはじめとする多数のマイクロコントローラ向けで、Linux のような汎用 OS を載せる機器とは用途が異なる
• 小さなメモリフットプリント: カーネル本体は数十 KB 程度の ROM と少量の RAM で動く設計で、構成によってさらに小さくできる
• MMU 前提ではない: 仮想メモリのない MCU 上で動くことを前提とし、保護機能はモジュール機能などで補う
• 言語: 主に C 言語で記述・利用する
• ライブラリは選択式: TCP/IP・USB・GUI などは必要なものだけリンクするため、使わない機能のコードはイメージに含めなくてよい
• 対応チップ・必要メモリ量・ライセンス条件は更新されるため、最新は公式情報で確認すること

内部の仕組み

中核の ThreadX は優先度ベースのプリエンプティブスケジューラです。各スレッドに優先度を割り当て、実行可能な中で最も高い優先度のスレッドを走らせます。高優先度のスレッドが割り込みなどで実行可能になると、走行中の低優先度スレッドを中断して即座に切り替えるため、応答時間の上限を見積もれます。これが「リアルタイム」と呼ばれる理由です。

スレッド間の協調には、セマフォ・ミューテックス・イベントフラグ・メッセージキューといった同期・通信プリミティブを使います。割り込みハンドラからこれらのオブジェクトを操作してスレッドを起こす、という流れが典型的な制御の形です。優先度の取り合いで起きる優先度逆転を避けるため、ミューテックスには優先度継承の仕組みも用意されています。

ネットワークやストレージは、カーネルとは独立したコンポーネントとして積み上げます。たとえば NetX Duo の TCP/IP スタックがスレッドとして動き、暗号化ライブラリと組み合わせて TLS 通信を行い、その上でクラウドへテレメトリを送る、といった構成です。各コンポーネントは ThreadX のスレッド・キュー上で動くため、全体として一貫したスケジューリングの下で協調します。

設計パターン / ベストプラクティス

• 優先度設計を最初に決める: 応答時間が厳しい処理ほど高優先度に置く。優先度の付け方がリアルタイム性を左右する
• 割り込みは短く: 割り込みハンドラ内では最小限の処理にとどめ、重い処理はスレッドへ委ねる（イベントフラグやキューで起床させる）
• 必要な部品だけ組み込む: 使わない NetX/USBX/GUIX をリンクしないことで、イメージサイズと攻撃面を抑える
• 静的確保を優先: 動的メモリの断片化を避けるため、スレッドスタックやオブジェクトはなるべく静的に確保する
• 優先度逆転に備える: 共有資源を守るミューテックスでは優先度継承を活用し、長時間のロックを避ける
• スタックサイズを実測する: スレッドごとのスタック消費を計測し、余裕を持たせてオーバーフローを防ぐ

運用・監視

• トレースで挙動を可視化: イベントトレース機能でスレッドの切り替えや同期イベントを記録し、専用ツールでタイミングを分析する
• スタック使用量の監視: スタックの最大使用量を追跡し、オーバーフローの兆候を早期に検知する
• ウォッチドッグ: ハングや暴走に備え、ハードウェアウォッチドッグと組み合わせて自己復旧させる
• ファームウェア更新: 現場の機器を更新できるよう、OTA（無線経由）更新やデバイス管理サービスと連携する運用を設計する
• クラウド連携の監視: テレメトリ送信や接続状態を、接続先の IoT Hub などクラウド側から把握する

コスト

Azure RTOS は現在、オープンソースの Eclipse ThreadX として MIT ライセンスで公開されており、コンポーネント自体の利用に料金は発生しません。費用が生じるのは主に、機器をつなぐ先のクラウドサービス（IoT Hub のメッセージ課金など）や、開発に使うツールチェーン、そして機器のハードウェア・開発工数の側です。つまり OS ライセンスではなく、周辺の開発・運用・クラウド費用で総額を見積もるのが実態に合います。

セキュリティ

• 暗号ライブラリ: 組み込み向けの暗号スタックを備え、TLS による通信の暗号化や証明書ベースの認証を実装できる
• 小さい攻撃面: 使うコンポーネントだけをリンクするため、不要な機能を含めないことでコードの攻撃面を減らせる
• メモリ保護: モジュール機能などを使い、信頼境界を分けてスレッド間の不正アクセスを抑える設計ができる
• セキュアブートとの連携: 改ざんを防ぐため、ハードウェアのセキュアブートや信頼の起点（ルートオブトラスト）と組み合わせる
• 安全な更新: ファームウェアの署名検証と OTA 更新で、現場機器の脆弱性を継続的にふさぐ

関連サービス・比較

Azure RTOS は機器側のファームウェア基盤であり、単体ではクラウドにつながりません。実運用では、機器をクラウドへ束ねる Azure IoT Hub とセットで使い、IoT Hub が接続・認証・テレメトリ受信を担います。位置づけとしては、AWS の組み込み RTOS である FreeRTOS に相当します。ここでは同じレイヤーの組み込み RTOS どうしとして FreeRTOS と比較します。

ハンズオン / CLI例

Azure RTOS 自体はマイコン上で動くため、開発はソースコードと組み込みツールチェーンで行います。ここでは、機器の接続先となる IoT Hub をクラウド側に用意し、デバイスを登録する例を示します。

# IoT 拡張機能を追加（未導入なら）
az extension add --name azure-iot

# リソースグループと IoT Hub を作成
az group create --name demo-rg --location japaneast
az iot hub create \
  --resource-group demo-rg \
  --name demo-iothub \
  --sku S1

# Azure RTOS 機器が接続するデバイスを登録
az iot hub device-identity create \
  --hub-name demo-iothub \
  --device-id rtos-device-01

# 機器のファームウェアに設定する接続文字列を取得
az iot hub device-identity connection-string show \
  --hub-name demo-iothub \
  --device-id rtos-device-01 \
  --output tsv

# 機器から届くテレメトリをクラウド側でモニタリング
az iot hub monitor-events \
  --hub-name demo-iothub \
  --device-id rtos-device-01