合同会社小村ソフト
相談する
メニュー

装置に載せるOSとしてOpenHarmonyは選択肢になるか ── Windows IoT・組込みLinuxとの比較

· · OpenHarmony, 組み込み, OS選定, 装置組み込み, Windows IoT, Linux, 製造業, 技術相談

前回の記事「OpenHarmonyとは何か」では、OpenHarmony・HarmonyOS・HarmonyOS NEXTという3つの実体を切り分けました。ここからは実務の話です。装置に載せるOSとして、OpenHarmonyは本当に選択肢に入るのか。

装置メーカーのOS選定は、機能比較よりも先に決まる要素があります。10年動く装置に、2年しか保守されないOSは載せられない。ベンダーSDKがWindowsにしかないカメラを使うなら、そのOSは最初から候補外になる。この記事では、Windows IoT Enterprise LTSC・組込みLinux(Debian / Yoctoベース)・OpenHarmonyを、装置の時間軸と調達の観点から並べて比較し、採用してよい条件と見送るべき条件を判断表にまとめます。

なお本記事は「OpenHarmonyを勧める記事」でも「やめておけという記事」でもありません。当社が普段扱っているのはWindowsの装置ソフトですが、選択肢を正しく比較できないまま「新しい技術だから」あるいは「中国発だから」で判断が決まってしまう場面を何度も見ています。判断材料を揃えることが目的です。

1. まず結論

  • 保守期間が最大の分かれ目です。OpenHarmonyコミュニティのReleaseブランチは2年(主動保守1年＋受動保守1年)、LTSブランチでも3.5年(2年＋1.5年)。Windows 11 IoT Enterprise LTSC 2024の10年とは前提が違います。12
  • しかも近年、LTSブランチは切られていません。LTSは初期には出ており(1.1.0 LTS、3.0-LTS)、公式の保守スケジュール表に残るLTSは2021年9月の3.0-LTSが最後です。3.1以降に公開されたブランチはすべてReleaseです。34
  • したがってコミュニティ版を製品にそのまま載せる運用は成立しません。採用するなら商用ディストリビューションのベンダー保守を買うか、自社でブランチを保守してCVE対応まで行う体制が要ります。Huaweiは「OpenHarmonyは100を超える商用バージョンをリリースした」と説明しており、この商用層が実際の採用先です。5
  • リソースの下限はOpenHarmonyが圧倒的に低いです。軽量システムは最小128 KiBのMCUから動作します。Windows 11 IoT Enterprise LTSCの特定用途デバイス向け最小要件はメモリ2GB・ストレージ16GBなので、そもそも土俵が違います。67
  • 既存のWindows装置ソフト資産は持ち込めません。C#/.NET、Win32、COM、WPF/WinFormsに相当する実行環境がなく、UIはArkTS＋ArkUI、ドライバはHDFという別体系になります。移植ではなく作り直しです。
  • 実際のボトルネックはベンダーSDKです。産業用カメラ、モーションコントローラ、PLC通信ライブラリの多くはWindows向け、次いでLinux向けしか提供されません。OpenHarmony向けドライバの有無は、OS比較より先に確認すべき項目です。
  • 日本語の一次情報とサポートはほぼありません。公式ドキュメントは中国語と英語の2種類で、日本語版はありません。8 中国語または英語の技術文書を読み切れる人員がいることが実質的な前提条件です。
  • 向いている用途は確実にあります。中国市場向けの製品、複数機器の連携(DSoftBus)が製品価値の中心にある機器、画面付きIoT機器でArkUIのUIを使いたいケース、MCUからリッチデバイスまでを1つの体系で揃えたいケースです。9

2. 比較の前提を揃える ── 何と何を比べているのか

比較を始める前に、対象を明確にします。「OS」と一口に言っても層が違うものを並べると議論が噛み合いません。

選択肢 実体 カーネル UI・アプリ層
Windows 11 IoT Enterprise LTSC Microsoftの商用OS製品 Windows NT Win32 / WinUI / WPF / WinForms、.NET
組込みLinux(Debianベース) ディストリビューション Linux 任意(Qt、GTK、Wayland compositor等)
組込みLinux(Yoctoベース) 自社ビルドのディストリビューションを作る枠組み Linux 任意
OpenHarmony 標準システム OSプロジェクト(要ディストリビューション化) Linux ArkUI、ArkTS、Ability
OpenHarmony 小型システム 同上 LiteOS-A 標準グラフィックスフレームワーク
OpenHarmony 軽量システム 同上 LiteOS-M 軽量グラフィックスフレームワーク

ここで押さえるべきなのは、OpenHarmonyはWindows IoTのような「買ってきて載せる完成品」ではないということです。位置づけとしてはYoctoに近く、「これを土台に自社製品用の構成を作る」枠組みです。ただしYoctoと違い、UIフレームワークとアプリモデルまでが一体で決まっているぶん、上まで積み上がっています。

OpenHarmonyのシステムタイプの定義は次のとおりです。6

システムタイプ プロセッサ 最小メモリ 想定製品
軽量システム Arm Cortex-M、32ビットRISC-VなどのMCU 128 KiB 接続モジュール、センサー、ウェアラブル
小型システム Arm Cortex-Aなどのアプリケーションプロセッサ 1 MiB IPカメラ、ドアスコープ、ルーター、ドライブレコーダー
標準システム Arm Cortex-Aなどのアプリケーションプロセッサ 128 MiB 完全なアプリケーションフレームワークを持つ画面付き機器

装置組み込みの文脈で比較対象になるのは主に標準システム(HMI付きの装置)と軽量システム(センサーノード、通信モジュール)です。小型システムはカメラ製品寄りの位置づけになります。

3. サポート期間の比較 ── 装置の時間軸に合うのはどれか

装置に組み込むPCやボードは、装置本体と同じ10年前後のライフサイクルで動き続けることを求められます。この観点で各選択肢を並べると、差は明白です。

選択肢 サポート期間 具体例 出典
Windows 11 IoT Enterprise LTSC 2024 10年 2024年10月1日開始、2034年10月10日終了 2
Windows 10 IoT Enterprise LTSC 2021 10年 2032年1月13日終了 10
Debian(LTS込み) 約5年 Debian 12 bookwormのLTS期間は2026年6月11日〜2028年6月30日 11
Yocto Project LTS 4年 5.0 Scarthgapは2024年4月〜2028年4月、6.0 Wrynoseは2026年4月〜2030年4月 12
OpenHarmony LTSブランチ 3.5年(2年＋1.5年) 3.0-LTSは2021年9月30日〜2025年3月30日 13
OpenHarmony Releaseブランチ 2年(1年＋1年) 4.1-Releaseは2024年3月30日〜2026年3月30日 13

さらに読み込むべき点が2つあります。

1つ目。OpenHarmonyの「受動保守期間」は品質が落ちます。公式の生命周期管理ポリシーでは、主動保守期間はコミュニティがタグ版を計画的に出して不具合とセキュリティ脆弱性を修正しますが、受動保守期間に入るとタグ版の計画・リリースは行われず、重大以上のセキュリティ脆弱性と不具合のみが修正対象になります。1 つまり実質的な「安心して使える期間」はReleaseブランチで1年、LTSで2年と考えるべきです。

2つ目。近年LTSブランチが切られていません。公式の保守スケジュール表に載るLTSは3.0-LTS(2021年9月)が最後で、3.1・3.2・4.0・4.1はすべてRelease種別です。3 LTS自体はそれ以前にも出ており、リリースノート索引には1.1.0 LTS(2021年4月)とその系列が残っていますが、いずれもEnd of Lifeです。4 さらに、5.x系と6.x系はこの保守スケジュール表にまだ記載がありません。10年の装置ライフサイクルを前提にすると、「どの分岐にどれだけの保守が付くのか」がリリースごとに読めない状態が続いていることになります。

一方、Windows 11 IoT Enterprise LTSC 2024は固定ライフサイクルポリシーで、2034年10月10日という終了日が最初から確定しています。2 Debianも各リリースの通常サポートとLTS期間が公表され、Yocto ProjectもLTSリリースを4年間サポートすると明示しています。1112

これはOpenHarmonyの品質が低いという話ではありません。この保守モデルは「コミュニティ版をそのまま製品に載せて放置する」使い方を想定していない、というだけです。実際の産業採用では商用ディストリビューションのベンダーが自社で分岐を保守し、保守を有償で提供します。採用検討時に確認すべきは「OpenHarmonyのサポートは何年ですか」ではなく、「そのディストリビューションのベンダーは、どのブランチを、いつまで、どういうSLAで保守しますか」です。

4. ハードウェアの選択肢

コミュニティが対応を公表している開発ボードは22機種です。13 装置に関係しそうなものを抜き出すと次のようになります。

システムタイプ ボード SoC ドキュメント上の想定用途
標準 HiHope HH-SCDAYU200 Rockchip RK3568 NVR、産業ゲートウェイ、家電
標準 MILOS_Standard0 NXP i.MX8M Mini 産業・医療向け高性能計測機器、産業制御とHMI、交通、防災、ビル
標準 Yangfan Rockchip RK3399 デジタルサイネージ、無人端末、産業制御ホスト、ロボット
標準 ZLG開発ボード Allwinner T507 産業制御、スマートコックピット、スマート電力
標準 Unionpi Tiger Amlogic A311D 産業制御、AIエッジコンピューティング
小型 BearPi-HM Micro ST STM32MP157A スマートホーム、中央制御画面
軽量 Niobe407 ST STM32F407IGT6 スマート交通、産業制御
軽量 HPM6750EVK2 HPMicro HPM6700(RISC-V) 産業制御、エッジコンピューティング

重要なのは、SoCベンダーが中国系だけではないという点です。NXP i.MX8M MiniやSTのSTM32シリーズが対応リストに入っているのは、日本の装置メーカーにとって現実的な意味があります。既に採用実績のあるSoCファミリで検討できる可能性があるからです。

ただし注意点も同じくらい大きいです。

  • 対応ボードのリストと、実際に手に入る産業用ボードは別物です。ここに載っているのは評価ボード中心で、10年供給保証付きの産業用ボードにOpenHarmonyが公式に載っているかは別途確認が必要です。
  • 自社のハードウェアに載せるならポーティングが自社作業になります。Windows IoTなら「OEM代理店経由でライセンスを買い、ドライバはベンダーが供給する」で済むところが、OpenHarmonyでは自社かディストリビュータの作業になります。
  • ドライバの扱いは「どこから使うか」で変わります。OpenHarmonyはHDF(Hardware Driver Foundation)という統一ドライバ基盤を持ち、これはプラットフォーム非依存・カーネル非依存の設計で全システムタイプに適用されます。9 ただし標準システムのカーネルはLinuxなので、既存のLinuxカーネルドライバをそのまま組み込み、V4L2や入力デバイスといった通常のLinuxインターフェース経由で使うこと自体は可能です。適合作業が必要になるのは、そのデバイスをOpenHarmonyのシステムサービスやフレームワークからHDI経由で扱わせたい場合です。既存のLinux BSPがあるなら、「全ドライバをHDFで書き直す」と見積もる必要はありません。どのデバイスをOpenHarmonyのフレームワークに露出させるかを先に決めて、その範囲だけを工数に積んでください。

5. 開発環境と言語 ── 既存資産は持ち込めるか

項目 Windows IoT Enterprise LTSC 組込みLinux OpenHarmony
ビルドシステム MSBuild / Visual Studio Make / CMake / BitBake(Yocto) GN + Ninja9
主要言語 C#、C++、VB C、C++、Python、Rust ArkTS(TypeScript拡張)、C、C++
UIフレームワーク WPF、WinForms、WinUI Qt、GTK、Flutter等 ArkUI
ドライバ WDM / WDF Linuxカーネルドライバ HDF
IDE Visual Studio 任意 DevEco Device Tool(Windows＋Ubuntu併用)またはCLI14
日本語ドキュメント あり 豊富 なし(中国語・英語のみ)8

装置ソフトの資産という観点で見ると、話は単純です。Windowsで書かれた装置ソフトは、OpenHarmonyには持ち込めません。C#/.NETもWin32もCOMもWPFも、対応する実行環境がありません。UIはArkTSとArkUI、下回りはC/C++で書き直しになります。

さらに現実的な障害は、ベンダーSDKの対応状況です。産業用カメラのSDK、モーションコントローラのライブラリ、PLC通信のミドルウェア、画像処理ライブラリ ── これらの多くはWindows向けが第一で、Linux向けが提供されていれば良いほう、というのが実情です。OpenHarmony向けの提供は期待できません。したがって、

OS比較より先に、装置に必要な周辺デバイスとミドルウェアのリストを作り、それぞれのOpenHarmony対応状況を確認する。

これをやらずにOS比較表だけで議論すると、後工程で確実に破綻します。当社が装置ソフトの相談を受けるときも、最初にこのリストを作るところから入ります。

開発環境の入口は2つ用意されています。GUIのDevEco Device Tool(Windowsでコード編集・デバッグ・書き込み、Ubuntuでコンパイルという併用構成)と、CLIによる手順です。14 ソース取得はrepoツールで、gitcode.com・gitee.com・GitHubのミラーが案内されています。15

6. ライセンスと知財

OpenHarmonyは単一ライセンスではありません。組み込む範囲ごとに確認が必要です。

対象 ライセンス 実務上の注意
多くのコンポーネント(ビルドシステム、ArkUIエンジン等) Apache License 2.016 著作権・特許条項の遵守、変更点の表示
LiteOS-Aカーネル BSD 3条項17 著作権表示とバイナリ頒布時の免責条項の再掲
標準システムのLinuxカーネル部分 GPLv2(Linuxカーネル本体のライセンス) 装置を顧客へ頒布するときに、頒布したバイナリに対応するソース(改変分を含む)を頒布先へ提供する義務。社内利用にとどまる改変には提供義務は生じない
公式ドキュメント CC BY 4.018 引用時の表示

「OpenHarmonyはApache 2.0だから安心」とまとめてしまうと、標準システムのカーネル部分のGPL義務を見落とします。装置に載せる範囲のリポジトリを列挙し、LICENSEを1つずつ確認するのが原則です。この点はWindows IoT(商用ライセンス1本で完結)との実務的な差になります。

GPLv2について1点補足します。義務が発生するのは頒布(distribution)の時点であって、改変した時点ではありません。社内の検証機でカーネルを改変して動かしているだけなら提供義務は生じず、その装置を顧客に納入した段階で、頒布したバイナリに対応するソースコードを頒布先に提供する義務が発生します。装置メーカーにとっては「納品＝頒布」なので結局対応が必要になりますが、社内試作の段階から公開義務があるわけではない、という区別は押さえておいてください(具体的な適合方法は自社の法務・知財部門と確認してください)。

7. 認証とエコシステム参加

製品として「OpenHarmony互換」を対外的にうたうには、OpenAtom財団の互換性測評を通す必要があります。技術的な土台はOpenHarmonyのXTS(X Test Suite) で、公式ドキュメントでは「OpenHarmony互換性テストスイート群を提供し、現在サポートされているアプリケーション互換性テストスイート(ACTS)と、将来サポートされるデバイス互換性テストスイート(DCTS)を含む」と説明されています。9 つまり公式ドキュメントの記述(2026年7月時点)では、現時点で提供されているのはACTSで、DCTSは将来提供という扱いです。

一方、コミュニティの認証手順資料では、XTSをACTS・HATS(ハードウェア抽象層互換性)・DCTSの3本立てとして説明しており、公式ドキュメントの記述と食い違っています。19 申請者が自社で適合開発とセルフテストを行い、テストレポートを添えて申請する、という流れ自体は共通です。

工数を見積もるときは、DCTSを必須要件と決め打ちしないでください。どのスイートが申請時点で実際に要求されるかは、認証窓口に直接確認するのが確実です。この種の「公式ドキュメントとコミュニティ資料が一致しない」状況は、日本語の一次情報がないことと合わせて、採用時のコミュニケーションコストとして見込んでおくべきものです。

社内検証や単発の装置に使うだけなら認証は不要ですが、対外的に互換性をうたう製品、あるいはエコシステムの一員として扱われたい製品では通す前提になります。工数として最初から見積もっておくべき項目です。

8. 判断表 ── 採用してよい条件、見送るべき条件

状況 推奨 理由
10年稼働の装置に組み込むHMI付きPC、既存Windows資産あり Windows 11 IoT Enterprise LTSC 2024 2034年10月まで10年サポート。機能更新なし。装置ソフト・ベンダーSDKがそのまま動く2
10年稼働の装置、Linux向けSDKが揃っている、社内にLinux要員あり 商用サポート付き組込みLinux Yocto LTSで4年、商用ディストリビューションの長期サポート契約で延長可能12
中国市場向けに出す製品で、要件が「OpenHarmony互換であること」 OpenHarmony(商用ディストリビューション経由) 市場要件がOSを決める。ベンダー保守込みで調達する
顧客がHarmonyOSエコシステム(AppGallery配信、HarmonyOSアプリ連携)への参加を求める OpenHarmonyでは要件を満たせない AppGalleryもHMSもHarmonyOS SDKもOpenHarmonyには含まれず、HarmonyOSアプリの互換性も保証されない。HarmonyOS対応製品・HarmonyOS SDKを選ぶ必要がある
複数機器の連携(機器発見・データ同期・アプリ移行)が製品価値の中核 OpenHarmony DSoftBusと分散データ管理・分散スケジューラが標準で載る9
MCUからリッチデバイスまで、製品ラインを1つの体系で揃えたい OpenHarmony(検討価値あり) 128 KiBから128 MiB以上まで同一体系でカバー6
センサーノード・通信モジュール(MCU、数百KiB級) OpenHarmony軽量システムまたはRTOS Windows IoTは土俵外(最小2GB)7
10年保守を契約で保証したい、社内に中国語・英語の技術文書を読む要員がいない 見送り コミュニティ保守は最大3.5年、日本語ドキュメント・日本語一次サポートがない18
産業用カメラ・モーションコントローラ等のベンダーSDKに依存する装置 見送り(要事前確認) ベンダーSDKのOpenHarmony対応はまず期待できない
既存のC#/.NET・COM資産を活かしたい 見送り 対応する実行環境がなく、作り直しになる
調達方針の制約が「プロジェクトのガバナンス・運営主体」に対するもの Eclipse Oniro系を検討 Oniroは欧州財団ガバナンス下。ただし2026年7月時点でIncubatingで、コミュニティ規模も本体とは比較にならない
調達方針の制約が「中国由来のコードを含まないこと」に対するもの 見送り OniroもOpenHarmonyの基盤層の上に構築されるため、ガバナンスが欧州財団でもコード由来の制約は解消しない

9. 採用するなら最初にやること

判断表で「採用」に振れた場合、着手順はこうなります。

  1. 周辺デバイスとミドルウェアの棚卸し。カメラ、I/O、通信、モーション、画像処理 ── 各ベンダーのOpenHarmony対応可否を確認します。ここで詰まるなら、他の工程を進める意味がありません。
  2. システムタイプの確定。軽量/小型/標準のどれで作るかを決めます。これでカーネル(LiteOS-M / LiteOS-A / Linux)もアプリの書き方も変わります。
  3. QEMUでの構造確認。実機ボードを買う前に、device_qemuが用意しているArm Virt(LiteOS-A / Linux)、Cortex-M4、Cortex-M55、RISC-Vなどのエミュレーション環境で、ビルドと起動の流れを確認できます。20
  4. 保守分岐の固定とビルド再現性の確保。repoのマニフェストを固定し(タグ指定が確実です)、社内ミラーを持ち、5年後に同じバイナリを再生成できる状態を作ります。15 上流のホスティングがgitcode.com中心である点も、事業継続の観点では自社ミラーを持つ理由になります。
  5. ライセンス棚卸し。組み込む範囲のリポジトリを列挙し、Apache 2.0 / BSD / GPLの義務を整理します。
  6. 保守契約の交渉。商用ディストリビューションのベンダーと、「どのブランチを、いつまで、どのSLAで」保守するかを契約で固めます。ここが決まらないなら採用判断を保留すべきです。
  7. 互換性測評(XTS)の要否判断。対外的に互換性をうたうなら、工数を最初から積みます。

10. まとめ

  • OpenHarmonyは技術的には筋の通った設計で、128 KiBのMCUから128 MiB以上のリッチデバイスまでを1つの体系でカバーし、機器連携(DSoftBus)を標準で持ちます。産業用途を想定した対応ボードもあり、NXPやSTのSoCも含まれます。
  • 一方、装置の10年ライフサイクルという観点では、コミュニティの保守期間(Release 2年、LTS 3.5年)は明確に足りません。しかもLTSブランチは2021年の3.0-LTS以降切られていません。採用するなら商用ディストリビューションのベンダー保守が前提です。
  • 日本の装置メーカーにとっての実質的な採用条件は3つです。(1)ベンダーSDKがOpenHarmonyに対応しているか、(2)中国語または英語の技術文書を読み切れる要員がいるか、(3)保守を契約で固められるベンダーがいるか。どれか1つでも欠けるなら、Windows IoT Enterprise LTSCか商用サポート付き組込みLinuxのほうが装置の時間軸に合います。
  • 逆に、中国市場向けの製品、機器連携が製品価値の中核にある製品、MCUからリッチまでを1体系で揃えたい製品ラインでは、正面から検討する価値があります。

OS選定は「どれが優れているか」ではなく「装置の時間軸・調達・要員とどれが噛み合うか」の問題です。Windows側の選定基準については「産業用PCにはどのWindowsを入れるべきか」に整理しています。

関連記事

関連する相談領域

合同会社小村ソフトでは、装置に載せる実行基盤の選定支援、既存Windows装置ソフトの移行可否の切り分け、長期稼働を前提とした構成のレビューを扱っています。「新しいOSが候補に挙がったが、社内に比較できる材料がない」という段階からご相談いただけます。

参考リンク

  1. OpenHarmony, OpenHarmony Version Lifecycle Management. Releaseブランチの生命周期が2年(主動保守1年＋受動保守1年)、LTSブランチが3.5年(2年＋1.5年)であること、受動保守期間ではタグ版の計画・リリースを行わず重大以上のセキュリティ脆弱性と不具合のみを修正することについて。 ↩ ↩2 ↩3 ↩4 ↩5

  2. Microsoft Learn, Windows 11 IoT Enterprise LTSC 2024 - Microsoft Lifecycle. 2024年10月1日開始、延長サポート終了が2034年10月10日(計10年)であることについて。 ↩ ↩2 ↩3 ↩4

  3. OpenHarmony Documentation, OpenHarmony Version Definitions. LTS・Releaseブランチの保守スケジュール表(この表に載るLTSは3.0-LTSのみで、1.0.1・3.1・3.2・4.0・4.1がRelease種別であること、4.1-Releaseの保守終了が2026年3月30日であること、5.x系・6.x系がまだ表に記載されていないこと)について。 ↩ ↩2 ↩3 ↩4

  4. OpenHarmony Documentation, Release Notes 索引. 3.0-LTS(2021年9月30日)とその系列が掲載され3.1以降はすべてRelease種別であること、1.x系にもLTS(1.1.0 LTSほか)が存在したがEnd of Lifeとされていること、および6.1 Release(2026年3月8日)が掲載されていることについて。 ↩ ↩2

  5. 華為, HarmonyOS 7 開発者Beta 正式启动，全场景智能操作系统再升级. 2026年6月12日のHDC 2026において、OpenHarmonyが100を超える商用バージョンをリリースしたと説明されていることについて。 ↩

  6. OpenHarmony Documentation, Quick Start Overview. 軽量システム(MCU、最小128 KiB)、小型システム(Cortex-A、最小1 MiB)、標準システム(Cortex-A、最小128 MiB)という3システムタイプの定義と想定製品について。 ↩ ↩2 ↩3

  7. Microsoft Learn, Minimum System Requirements - Windows IoT Enterprise. 特定用途デバイス向けのOPTIONAL最小要件としてメモリ2GB・ストレージ16GBが定義されていることについて。 ↩ ↩2

  8. OpenHarmony Documentation, README. 公式ドキュメントが中国語(zh-cn)と英語(en)の2言語で提供され、日本語版が存在しないこと、および各バージョンとAPIレベルの対応について。 ↩ ↩2 ↩3

  9. OpenHarmony Documentation, OpenHarmony Project. 4層アーキテクチャとLinux/LiteOSのマルチカーネル設計、HDF(Hardware Driver Foundation)による統一ドライバ基盤、DSoftBus・分散データ管理・分散スケジューラ、ビルドシステムがGN+Ninjaであること、XTSが互換性テストスイート群であり、「現在サポートされているアプリケーション互換性テストスイート(ACTS)と、将来サポートされるデバイス互換性テストスイート(DCTS)」と記述されていることについて。 ↩ ↩2 ↩3 ↩4 ↩5

  10. Microsoft Learn, Windows 10 IoT Enterprise LTSC 2021 - Microsoft Lifecycle. 延長サポート終了が2032年1月13日であることについて。 ↩

  11. Debian Wiki, LTS. Debian LTSが各安定版リリースの寿命を少なくとも5年に延長するプロジェクトであること、Debian 12 bookwormのLTS期間が2026年6月11日から2028年6月30日であることについて。 ↩ ↩2

  12. Yocto Project Wiki, Releases. LTSリリースが4年間サポートされる方針であること、5.0 Scarthgapが2024年4月リリースで2028年4月まで、6.0 Wrynoseが2026年4月リリースで2030年4月までサポートされることについて。 ↩ ↩2 ↩3

  13. OpenHarmony Documentation, OpenHarmony Development Boards List. コミュニティ対応の開発ボードが22機種であること、および各ボードのSoCと想定用途(MILOS_Standard0のNXP i.MX8M Miniが産業・医療向け計測機器と産業制御・HMIを、Niobe407のSTM32F407が産業制御を想定用途に挙げていることなど)について。 ↩

  14. OpenHarmony Documentation, Quick Start Overview. デバイス開発の入口としてDevEco Device Toolを使うIDEモード(Windowsでコード開発・デバッグ・書き込み、Ubuntuでソースコンパイルというハイブリッド構成)とCLIモードの2種類が用意されていることについて。 ↩ ↩2

  15. OpenHarmony Documentation, Source Code Acquisition. repoツールによるソース取得手順と、gitcode.com・gitee.com・GitHubの各ミラー、ブランチ指定・タグ指定の方法について。 ↩ ↩2

  16. OpenHarmony, arkui_ace_engine LICENSE および build LICENSE. ArkUIエンジンおよびビルドシステムのリポジトリがApache License 2.0で配布されていることについて。 ↩

  17. OpenHarmony, kernel_liteos_a LICENSE. LiteOS-AカーネルがBSD 3条項ライセンスで配布されていることについて。 ↩

  18. OpenHarmony, docs LICENSE. 公式ドキュメントリポジトリがCreative Commons Attribution 4.0 Internationalで提供されていることについて。 ↩

  19. 開放原子開源基金会コミュニティ資料, OpenHarmony-XTS認証流程(二次情報). コミュニティの認証手順資料がXTSをACTS(アプリ互換性)・HATS(ハードウェア抽象層互換性)・DCTSの3本立てとして説明していること、申請者が企業アカウントを取得し、適合開発とセルフテストを行い、テストレポートとPCS自己点検表を添えて申請する流れであることについて。DCTSの位置づけは公式ドキュメント(「将来サポートされるデバイス互換性テストスイート」)と食い違うため、本文ではその差を明示している。 ↩

  20. OpenHarmony, device_qemu README. QEMUによるエミュレーション対象としてArm Virt(LiteOS-A)、Arm Virt(Linux)、Cortex-M4(mps2-an386)、Cortex-M55(mps3-an547)、RISC-V(riscv32_virt)、Xtensa(esp32)、C-SKY(SmartL_E802)の手順が用意されていることについて。 ↩

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

産業機器のOSとしてOpenHarmonyを採用しても大丈夫ですか？
条件次第です。決め手になるのは保守期間の扱いで、OpenHarmonyコミュニティのReleaseブランチは生命周期が2年(主動保守1年＋受動保守1年)、LTSブランチでも3.5年です。10年稼働する装置にコミュニティ版をそのまま載せると、製品寿命の途中でセキュリティ修正が止まります。採用するなら、商用ディストリビューションのベンダー保守を購入するか、自社でブランチを保守しCVE対応まで行う体制を持つことが前提になります。この体制が用意できないなら、Windows IoT Enterprise LTSC(10年)や商用組込みLinuxの長期サポート契約のほうが装置の時間軸に合います。
OpenHarmonyと組込みLinuxはどちらが軽いですか？
OpenHarmonyのほうが下限は低いです。OpenHarmonyの軽量システムはArm Cortex-Mや32ビットRISC-VのMCUで最小128 KiBのメモリから動作し、小型システムは1 MiB以上、標準システムは128 MiB以上です。一般的な組込みLinuxはMMU付きプロセッサと数十MB以上のRAMが前提なので、MCU領域まで同じOS体系でカバーできるのはOpenHarmonyの特徴です。ただし軽量システムのカーネルはLiteOS-Mで、標準システムのLinuxとは実行環境がまったく異なるため、「同じOSだから同じアプリが動く」わけではない点に注意してください。
既存のWindows装置ソフトをOpenHarmonyへ移植できますか？
実質的に作り直しになります。C#/.NETやWin32、COM、WPF/WinFormsで書かれた装置ソフトは、OpenHarmony上には対応する実行環境がありません。UIはArkTS＋ArkUI、下回りはC/C++、ドライバはHDF(Hardware Driver Foundation)という別体系で書き直すことになります。さらに産業用カメラやモーションコントローラのベンダーSDKはWindows(次いでLinux)向けしか提供されないことが多く、そこが移植の実際のボトルネックになります。既存資産を活かす前提なら、Windows IoT Enterprise LTSCへの載せ替えか、Linux向けSDKが提供されているデバイスに限定した組込みLinuxのほうが現実的です。
OpenHarmony対応をうたうには何か認証が必要ですか？
製品として「OpenHarmony互換」を名乗るには、OpenAtom財団の互換性測評(認証)を通す必要があります。技術的な土台はOpenHarmonyのXTS(X Test Suite)というテストスイート群です。ただし内訳は出典によって記述が異なり、2026年7月時点の公式ドキュメントは「現在サポートされているACTS(アプリケーション互換性テストスイート)と、将来サポートされるDCTS(デバイス互換性テストスイート)」と書いています。一方、コミュニティの認証手順資料はこれにHATS(ハードウェア抽象層互換性)を加えた構成で説明しています。工数を見積もるときは、DCTSを必須要件と決め打ちせず、申請時点で実際に要求されるスイートを認証窓口に確認してください。社内検証だけで使う分には認証は不要ですが、対外的に互換性をうたう製品では必要になります。
日本語のサポートや情報はどれくらいありますか？
公式ドキュメントは中国語と英語の2種類で、日本語版はありません。コミュニティの議論も中国語が中心です。商用ディストリビューションのベンダーも中国企業が中心で、日本語で一次サポートを受けられる窓口は限られます。したがって、社内に中国語または英語の技術文書を読み切れる人員がいることが実質的な採用条件になります。この点はWindowsや主要Linuxディストリビューションと比べたときのはっきりした差です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

お問い合わせ
ブログ一覧に戻る