Azure RTOSはEclipse ThreadXへ

Azure RTOSはEclipse ThreadXへ
Azure RTOSはEclipse ThreadXへ

Microsoftが、Azure RTOSをEclipse Foundationへ提供しました。Azure RTOSからEclipse ThreadXへ名前を変え、ベンダーニュートラルなオープンソースRTOSへ変わりました(2024年1月9日、MONOist)。

上記記事に筆者は驚きました。Microsoft発表は、昨年11月21日です。発表から約2か月たった現在の業界動向をまとめました。

Microsoft動向

MicrosoftがAzure RTOSを手放した経緯は、前述MONOist記事が詳しく説明しています。ごく簡単にまとめます。

Microsoftは、2019年ExpressLogic社買収で入手したThreadXを、自社クラウドサービス接続用RTOS、Azure RTOSとして育ててきた。しかし、2022年Azure RTOS開発責任者がMicrosoftを退社。結局、2023年Microsoftは、Azure RTOSをEclipse Foundationへ提供。今後、Microsoftは機能安全コストも負担しない。

※機能安全コストとは、厳格な安全やセキュリティ規格を満たすソフトウェアのメンテやサポートコスト。

Eclipse財団動向

MCU統合開発環境のデファクトスタンダード:Eclipse IDEの非営利運営団体がEclipse Foundation。

Eclipse財団は、提供Azure RTOSをEclipse ThreadXと改名。ベンダーニュートラルなオープンソースRTOSとし、一般的に有償の機能安全版も、2024年1月末目途にMIT Licenseで提供準備中。

Eclipse財団は現在Eclipse ThreadX開発者募集中で、Eclipse ThreadXの全コンポーネント(IoT MCUベンダ動向図のTCP/IPスタック等)無償配布になる可能性あり。

MCU RTOS動向

MCU RTOS動向
MCU RTOS動向

Eclipse ThreadX競合ライバルのFreeRTOS、 μT-Kernel状況が下記。特段の対応は現在無し。

FreeRTOS:機能安全版は商用ライセンスSAFERTOSで提供中。FreeRTOSは無償提供中。
μT-Kernel: IEEE標準規格:IEEE2050-2018完全準拠版μT-Kernel 3.0を無償提供中。

IoT MCUベンダ動向

本ブログ掲載IoT MCUベンダで言えば、STマイクロ>ルネサス>NXPの順に、Azure RTOSに積極的でした(FreeRTOSなら真逆)。

そのSTマイクロが、Eclipse ThreadXは、重要な開発環境の一部、とMicrosoft発表内でコメントしています。つまり、STマイクロは、これまでのAzure RTOS同様、Eclipse ThreadXをミドルウェアとして提供すると思います。

現代的ユーザMCU開発の例(出展:The ST blog)
現代的ユーザMCU開発の例(出展:The ST blog)

米市場動向

MicrosoftがAzure RTOSを手放したのは、育成済みAzure RTOSを、今さら保守・運用しなくても、自社クラウドサービスへの影響は少ない、と判断したからかもしれません。

一方、一般向けAI PCに関しては、Windows 11シェア伸び悩む、Windows 12方向性などの記事から、Microsoftは次期Windows+Copilotに注力すると思います。AI Copilotキー追加モバイルCopilotなど、最近は生成AI関連のCopilot発表一色です。

これらCopilot群は、次期AI Windows(Afterword2参照)で使い易く統合されるでしょう。

2024年1月12日、米株式市場も⽣成AI⾰命からより多くの恩恵を受けるMicrosoft時価総額を、アップルを抜き首位復活させました。

Summary:IoT MCU開発者対応

Microsoftが、Azure RTOSを手放し、Eclipse財団が、Eclipse ThreadXと改名、ベンダーニュートラルオープンソースRTOSとしたことを、業界は、冷静かつ好意的に受け止めているようです。

むしろ、AWSならFreeRTOS、AzureならAzure RTOSと2本立てIoT MCU RTOS開発が、Eclipse ThreadXで一本化、機能安全パッケージも無償提供期待の方が大きいのかもしれません。

IoT MCU開発者は、Eclipse ThreadXを含むRTOS動向に注意する必要があります。

Afterword:RTOSチェックポイント

RTOS動向チェックポイント
RTOS動向チェックポイント

MCUにRTOSを使う理由は、クラウド接続ライブラリが必要だからです。

しかし、ライブラリは関数の集合に過ぎないので、ライブラリ利用例、つまりサンプルコードが無いと使えません。ベンダーニュートラルEclipse ThreadXが、AzureとAWS両方の接続サンプルコードを提供するかがチェックポイントです。

また、サンプルコードがあっても、接続の容易さや安定性も確認したいです。評価ボードでのテストやクラウド接続ユーザ数変化、SNSなどで判るでしょう。

Eclipse ThreadXが他RTOSへ与える影響は、少なくないと思います。この辺りは、調査を続けます。

Afterword2:AI Windows12決め手

Win11敗因の1つは、TPM 2.0などのPCハードウェアとWin11アップグレード条件を、100%結び付けたことだと思います。条件を満たさないPCは、Win11アップグレートができずWin10のままです。Win10でも、PC生産性に大差はありませんが…😓。

ハードウェアとアップグレート条件の結び付きを緩くし、例えば、NPU(Neural Processing Unit)搭載最新Core Ultraプロセッサなら、自然言語入力にも対応するAI機能満載Win12、古いCPUなら、従来CUI/GUI 入力のAI Win12など、アップグレード機能/能力差を付けます。

これに近いことは、 既に昨年のWin11 23H2アップデートの段階的機能ロールアウト(Controlled Feature Rollout、CFR)で実施中です。

AI機能は、PC生産性に直結します。PC買換え需要も喚起できるでしょう。不振Win11と2025年秋Win10サポート終了前に、AI Win12リリースをMicrosoftが急ぐ理由です。

つまり、2024年内にPCハードウェアに応じたAI Win12アップグレートをMicrosoftが提供することが、低下しつつあるWindowsシェア復活の決め手になると思います。