小村軟體有限公司
聯絡我們
選單

作為裝置搭載的OS，OpenHarmony能否成為選項 ── 與Windows IoT、嵌入式Linux的比較

· · OpenHarmony, 嵌入式, OS選型, 裝置嵌入式, Windows IoT, Linux, 製造業, 技術諮詢

上一篇文章「OpenHarmony是什麼」中，我們釐清了OpenHarmony、HarmonyOS、HarmonyOS NEXT這三個實體的區別。接下來要談的是實務面的問題。作為裝置搭載的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應對為止的體制。華為表示「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比較先行確認的項目。
  • 幾乎沒有日文的第一手資訊與支援。官方文件只有中文與英文兩種語言，沒有日文版。8 公司內部要有能讀懂中文或英文技術文件的人員，實質上是採用的前提條件。
  • 確實存在適合的用途。包括面向中國市場的產品、以多裝置協同(DSoftBus)為產品價值核心的裝置、想在有螢幕的IoT裝置上使用ArkUI介面的情境，以及想從MCU到高階裝置都用同一套體系統一整合的情境。9

先把評估軸×選項的綜合判斷整理成一張表。這是以下各章內容的摘要。符號分為 ◎=直接適合／○=有條件適合／△=需要注意／×=不適合 四個等級。

評估軸 Windows IoT Enterprise LTSC 嵌入式Linux(Debian／Yocto) OpenHarmony 詳情
維護期間(是否足以支撐設備10年的壽命) ◎ 固定10年。2024 LTSC支援至2034年10月2 ○ Debian約5年，Yocto LTS 4年。可透過商用合約延長1011 △ 社群為Release 2年、LTS 3.5年。以購買廠商維護服務為前提1 第3章
資源下限(能小到裝在多小的裝置上) × 最小記憶體2GB、儲存空間16GB7 △ 以搭載MMU的處理器與數十MB等級的RAM為前提 ◎ 輕量系統從128 KiB的MCU即可6 第2章
廠商SDK(工業用相機、運動控制、PLC通訊) ◎ 第一優先支援對象 ○ 若有提供即可使用 × 幾乎無法期待 第5章
語言・UI體系(既有Windows資產能否延用) ◎ C#/.NET、Win32、COM、WPF可直接運作 × 需重做。不過C/C++的量測・控制邏輯較容易移植 × 需重做。ArkTS＋ArkUI，驅動程式為HDF 第5章
日文資訊・國內支援 ◎ 有日文文件與國內代理商・窗口 ○ 日文技術資訊豐富 × 官方文件僅中文・英文8 第5章
裝置協同(裝置探索・資料同步・應用程式遷移) △ 需自行實作 △ 需自行實作 ◎ 標準內建DSoftBus與分散式資料管理・分散式排程器9 第8章

如上表所示，OpenHarmony能拿到◎的，只有資源下限與裝置協同這兩個軸，既有資產、SDK、日文資訊這三個軸都是×。這種分布形態呈現的不是「優劣」，而是「能吻合的條件有限」。至於哪些條件才吻合，將在第8章的判斷表中逐一說明。

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 輕量圖形框架

表格中有兩個用語需要補充說明。Yocto並非完成品OS，而是組合recipe(建置流程的定義)、為自家產品建置Linux發行版的框架。LTSC(Long-Term Servicing Channel)是Windows的一種供應模式，不導入功能更新，只長期提供安全性更新，適合像設備這樣想固定組態的用途。

這裡要掌握的重點是，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日結束 12
Debian(含LTS) 約5年 Debian 12 bookworm的LTS期間為2026年6月11日～2028年6月30日 10
Yocto Project LTS 4年 5.0 Scarthgap為2024年4月～2028年4月，6.0 Wrynose為2026年4月～2030年4月 11
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

本表以2026年7月時點的各官方資訊為依據。由於支援期間與結束日期可能會修訂，請務必在做出採用判斷前，以第一手資料再次確認。確認管道如下。

尤其OpenHarmony如後文所述，5.x系列與6.x系列尚未列入維護排程表。若考慮採用表中未列出的版本，請以「期間尚未確定」為前提來看待。

還有兩點需要進一步深入了解。

第一，OpenHarmony的「被動維護期間」品質會下降。根據官方的生命週期管理政策，在主動維護期間，社群會有計畫地釋出標籤版本，修復缺陷與安全性弱點；但一旦進入被動維護期間，就不再規劃・釋出標籤版本，只有嚴重以上等級的安全性弱點與缺陷才會被修復。1 也就是說，實質上「可以安心使用的期間」，Release分支應視為1年，LTS應視為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年。1011

這不代表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家族來評估。

不過，需要注意的地方同樣不少。

  • 支援清單與實際能取得的工業用板子是兩回事。這裡列出的以評估板為主，OpenHarmony是否官方支援附有10年供貨保證的工業用板子，需要另行確認。表格中的「預期用途」只是文件上的定位，並非供貨保證，也不代表在日本國內有流通實績。
  • 可取得性需要從日本個別確認。這份清單中的開發板以中國市場為主，未必能在國內代理商正常買到。在安排評估機之前，請透過洽詢確認以下3點：(1)開發板廠商的銷售頁面及跨境電商是否有經手，(2)是否有國內銷售代理商，(3)量產時的最低訂購量與供貨年限。這一步若卡關，後續的技術驗證全部都會停擺。
  • 若要搭載到自家硬體上，移植會變成自家公司的工作。若是Windows IoT，「透過OEM代理商購買授權，驅動程式由廠商提供」就能解決；但在OpenHarmony上，這會變成自家公司或發行版供應商的工作。
  • 驅動程式的處理方式，會因「從哪裡使用」而不同。OpenHarmony擁有名為HDF(Hardware Driver Foundation)的統一驅動程式基礎架構，這是與平台無關、與核心無關的設計，適用於所有系統類型。9 不過標準系統的核心是Linux，因此直接組入既有的Linux核心驅動程式，透過V4L2或輸入裝置等一般Linux介面來使用，本身是可行的。需要進行相容性作業的，是想讓該裝置透過HDI，從OpenHarmony的系統服務或框架來操作的情況。如果已有既有的Linux BSP，不需要估算成「所有驅動程式都要用HDF重寫」。請先決定哪些裝置要露出給OpenHarmony的框架，只針對這個範圍估算工時。

另外，即使還處於開發板採購卡關的階段，驗證仍然可以開始進行。在購買實機之前，先用QEMU確認結構與啟動流程的步驟，已列在第9章中。此外，若自家電路板的SoC已經確定，比起尋找評估板，估算移植到該SoC的工時反而更實際的情況也不少見。

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比較表來討論，後續工程必然會出問題。本公司在接受設備軟體的諮詢時，也是從先做這份清單開始著手。

開發環境提供兩種入口：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。這一點是與Windows IoT(單一商用授權即可完結)在實務上的差異。

關於GPLv2再補充一點。義務發生的時點是發佈(distribution)的當下，而不是修改的當下。若只是在公司內部的驗證機上修改核心並運作，並不會產生提供義務；等到將該設備交付給客戶的階段，才會產生將對應所發佈二進位檔的原始碼提供給接收方的義務。對設備廠商而言，「交貨＝發佈」，所以終究還是需要因應，但請掌握「並非從公司內部試作階段起就有公開義務」這個區別(具體的因應方式請與自家公司的法務・智財部門確認)。

7. 認證與生態系參與

若要以產品形式對外宣稱「OpenHarmony相容」，必須通過開放原子基金會(OpenAtom)的相容性測評。技術基礎是OpenHarmony的XTS(X Test Suite)，官方文件說明為「提供OpenHarmony相容性測試套件群，包含目前支援的應用相容性測試套件(ACTS)，以及未來將支援的裝置相容性測試套件(DCTS)」。9 也就是說，依官方文件的記述(2026年7月時點)，目前提供的是ACTS，DCTS則屬於未來提供的定位。

另一方面，社群的認證流程資料則將XTS說明為ACTS、HATS(硬體抽象層相容性)、DCTS三大支柱，與官方文件的記述有出入。19 不過申請者自行進行相容性開發與自我測試、附上測試報告後提出申請，這個流程本身是共通的。

估算工時時，請不要把DCTS當成必要要求來認定。哪一套測試套件在申請時點會被實際要求，最保險的做法是直接向認證窗口確認。這種「官方文件與社群資料不一致」的狀況，再加上沒有日文的第一手資訊，應該一併視為採用時的溝通成本先納入考量。

若只是用於公司內部驗證或單一設備，不需要認證，但若是對外宣稱相容性的產品，或是希望被視為生態系一員的產品，就必須以通過認證為前提。這是應該從一開始就納入工時估算的項目。

8. 判斷表 ── 可採用的條件、應放棄的條件

在進入判斷表之前，先把通往判斷的流程整理成一張圖。確認前提的順序很重要，先確認市場・產品需求，技術層面的檢討放在後面。就算技術上做得出來，若無法透過合約鎖定維護，也無法搭載到設備上。

是否是否湊齊／能自行開發湊不齊能鎖定無法鎖定有沒有選擇裝置搭載的OS是否為面向中國市場的產品，或需求指定為OpenHarmony相容以DSoftBus為基礎的多裝置協同，是否為產品價值的核心周邊裝置與中介軟體的廠商SDK是否能在OpenHarmony上湊齊，不足的部分能否自行開發維護能否以合約鎖定，例如商用發行版廠商，或自家公司具備CVE應對能力的體制是否有能讀完中文或英文技術文件的人員正面檢討OpenHarmony透過商用發行版採購Windows IoT LTSC 或嵌入式Linux依既有資產與廠商SDK支援狀況決定放棄OpenHarmony

圖1：是否採用OpenHarmony的判斷流程。各分支的依據對應下方判斷表中的各列

各分支之中，實際上因Q3(廠商SDK)與Q4(維護合約)而被刷掉的案件相當多，這正是本文的主旨。以下的判斷表，是把這張圖的各個分支展開成具體狀況的結果。

狀況 建議 理由
嵌入運作10年的設備中、附HMI的PC，且已有既有Windows資產 Windows 11 IoT Enterprise LTSC 2024 支援至2034年10月，共10年。無功能更新。設備軟體・廠商SDK可直接運作2
運作10年的設備、已備齊Linux版SDK、公司內部有Linux人員 附商用支援的嵌入式Linux Yocto LTS為4年，可透過商用發行版的長期支援合約延長11
面向中國市場推出的產品，且需求為「須OpenHarmony相容」 OpenHarmony(透過商用發行版) 市場需求決定OS。連同廠商維護服務一併採購
客戶要求參與HarmonyOS生態系(AppGallery上架、與HarmonyOS應用程式協同) OpenHarmony無法滿足此需求 AppGallery、HMS、HarmonyOS SDK皆不包含在OpenHarmony中，也不保證與HarmonyOS應用程式相容。必須選擇支援HarmonyOS的產品・HarmonyOS SDK
多裝置協同(裝置探索・資料同步・應用程式遷移)是產品價值的核心 OpenHarmony 標準內建DSoftBus與分散式資料管理・分散式排程器9
想從MCU到高階裝置，用同一套體系統一整合產品線 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的manifest(以標籤指定最為確實)，建立公司內部鏡像，打造出即使5年後也能重新產生相同二進位檔的狀態。15 上游託管以gitcode.com為主這一點，從事業延續性的角度來看，也是自行建立鏡像的理由之一。
  5. 盤點授權條款。列出要納入的範圍內的所有版本庫，整理Apache 2.0／BSD／GPL各自的義務。
  6. 協商維護合約。與商用發行版廠商，以合約明確約定「維護哪個分支、到什麼時候、以什麼SLA」。若這一點無法確定，就應該暫緩採用判斷。
  7. 判斷是否需要相容性測評(XTS)。若要對外宣稱相容性，就要從一開始就把這部分工時算進去。

10. 總結

  • OpenHarmony在技術上是條理清晰的設計，能以同一套體系涵蓋從128 KiB的MCU到128 MiB以上的高階裝置，並標準內建裝置協同(DSoftBus)。也有預想工業用途的支援開發板，其中還包括NXP與ST的SoC。
  • 另一方面，從設備10年生命週期的角度來看，社群的維護期間(Release 2年、LTS 3.5年)明顯不足。而且LTS分支自2021年的3.0-LTS之後就沒有再釋出。若要採用，前提是要有商用發行版廠商的維護服務。
  • 對日本的設備廠商而言，實質上的採用條件有三個。(1)廠商SDK是否支援OpenHarmony，(2)公司內部是否有能讀完中文或英文技術文件的人員，(3)是否有能以合約鎖定維護的廠商。只要缺少其中一項，Windows IoT Enterprise LTSC或附商用支援的嵌入式Linux，都會更符合設備的時間軸。
  • 反過來說，對於面向中國市場的產品、以裝置協同為產品價值核心的產品、想從MCU到高階裝置都用同一套體系統一整合的產品線，則值得正面檢討。

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 ↩6 ↩7

  2. Microsoft Learn, Windows 11 IoT Enterprise LTSC 2024 - Microsoft Lifecycle。關於2024年10月1日開始，延伸支援結束於2034年10月10日(共計10年)。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  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 ↩5

  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 ↩4

  7. Microsoft Learn, Minimum System Requirements - Windows IoT Enterprise。關於針對特定用途裝置的OPTIONAL最小需求，定義為記憶體2GB、儲存空間16GB。 ↩ ↩2 ↩3

  8. OpenHarmony Documentation, README。關於官方文件僅以中文(zh-cn)與英文(en)兩種語言提供，沒有日文版，以及各版本與API等級的對應關係。 ↩ ↩2 ↩3 ↩4

  9. OpenHarmony Documentation, OpenHarmony Project。關於4層架構與Linux/LiteOS的多核心設計、HDF(Hardware Driver Foundation)統一驅動程式基礎架構、DSoftBus・分散式資料管理・分散式排程器、建置系統為GN+Ninja，以及XTS是相容性測試套件群，文件中記載為「目前支援的應用相容性測試套件(ACTS)，以及未來將支援的裝置相容性測試套件(DCTS)」等內容。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  10. Debian Wiki, LTS。關於Debian LTS是將各穩定版本的壽命至少延長至5年的專案，以及Debian 12 bookworm的LTS期間為2026年6月11日至2028年6月30日。 ↩ ↩2 ↩3 ↩4

  11. Yocto Project Wiki, Releases。關於LTS版本採4年支援方針，5.0 Scarthgap於2024年4月發布，支援至2028年4月；6.0 Wrynose於2026年4月發布，支援至2030年4月。 ↩ ↩2 ↩3 ↩4 ↩5

  12. Microsoft Learn, Windows 10 IoT Enterprise LTSC 2021 - Microsoft Lifecycle。關於延伸支援結束於2032年1月13日。 ↩

  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三大支柱，以及申請者需取得企業帳號、進行相容性開發與自我測試、附上測試報告與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為前提，因此能以同一套OS體系涵蓋到MCU範圍，是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當成必要條件，請在申請時向認證窗口確認實際要求的套件。若只是在公司內部驗證使用，不需要認證，但若是對外宣稱相容性的產品則必須通過。
日文的支援或資訊有多少？
官方文件只有中文與英文兩種語言，沒有日文版。社群的討論也以中文為主。商用發行版的廠商也以中國企業為主，能以日文獲得第一線支援的窗口相當有限。因此，公司內部要有能讀懂中文或英文技術文件的人力，實質上就是採用的前提條件。這一點與Windows或主要Linux發行版相比，是很明顯的差異。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

聯絡我們
回到部落格一覽