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

要不要把OpenHarmony列入裝置OS的候選，先看的不是功能多寡，而是維護、SDK與開發人力。要運作10年的裝置，不能直接搭載社群維護2年就結束的版本。若所需相機的SDK只有Windows版，使用那款相機的組態同樣不成立。

本文面向裝置廠商，比較Windows IoT Enterprise LTSC、嵌入式Linux(以Debian／Yocto為基礎)與OpenHarmony。首先把比較對象放到同一個層級上，接著依能否支撐產品壽命、能否移轉既有資產、能否推進到量產與出貨的順序逐項確認。在此基礎上，用判斷表整理出可以採用的條件與應該放棄的條件。

本公司平常處理的是Windows的裝置軟體，但本文既不是一概推薦OpenHarmony，也不是一概否定它。判斷的依據不是「因為是新技術」或「因為源自中國」，而是它是否符合裝置的時間軸、採購與人力。OpenHarmony、HarmonyOS、HarmonyOS NEXT三者的差異本身，請參閱上一篇「OpenHarmony是什麼」。

本文比較的技術資訊與維護排程以2026年7月為基準。支援期間、支援的開發板與認證要求都會變動，因此實際採用的版本與產品，請在做出判斷之前向第一手資料與廠商確認。

1. 先講結論：把採用條件與選擇理由分開來看

OpenHarmony的強項在於連小型裝置都能涵蓋，以及多台裝置之間的協同可以用標準機制處理。另一方面，既有Windows資產、工業用的廠商SDK、日文的第一手資訊則有明確的限制。¹²³

採用所需的條件有下列3項。只要有一項無法滿足，就優先選擇Windows IoT Enterprise LTSC或附商用支援的嵌入式Linux。反過來說，即使3項條件都齊備，也不代表就此決定採用OpenHarmony。產品需求要與OpenHarmony的強項吻合，以及有能力開發與維護該產品，兩者都要確認。

flowchart TB
    accTitle: 把採用條件與對產品而言的優點分開
    accDescr: 把符合產品需求的優點，與維護、SDK、人力這些實現上的條件分開，再對照兩者判斷採用與否。
    requirements["裝置的市場與產品需求"] --> value["選擇OpenHarmony的理由"]
    requirements --> conditions["維護、SDK、人力的條件"]
    value --> check["對照兩者判斷採用與否"]
    conditions --> check

圖1：把能夠運作的條件，與選擇它的理由分開來看。

依目的選讀

綜合比較在2.3節，分情況的建議在7.2節。即使是判斷表中建議採用的用途，上述3項條件也不能省略。

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 34 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

2. 把比較對象放到同一個層級：只看OS的名稱無法比較

2.1. Windows IoT、Debian、Yocto、OpenHarmony各自的定位

最先要對齊的，是要使用完成的OS產品，還是要使用打造自家產品用OS的基礎這個差異。把這兩者混在一起，就會漏看為了產品化而必須由自家公司承擔的工作。

Yocto並不是完成的OS，而是組合recipe(建置流程的定義)、為自家產品建置Linux發行版的框架。LTSC(Long-Term Servicing Channel)則是不導入功能更新、只長期提供安全性更新的Windows供應模式，適合像裝置這樣想固定組態的用途。

OpenHarmony同樣不是Windows IoT那種「買來就直接搭載的完成品」。它的定位接近Yocto，屬於以基礎打造自家產品用組態的那一類選項。不過與Yocto不同的是，它連UI框架與應用程式模型都一體備齊，因此是一套涵蓋到上層的體系。

flowchart TB
    accTitle: 完成的OS產品與打造產品用組態的基礎
    accDescr: 採購商用OS產品的路徑，與從專案的基礎打造自家產品用組態的路徑，所要承擔的工作並不相同。
    os["搭載到裝置上的執行基礎"] --> product["採購商用OS產品"]
    os --> project["選擇開發的基礎"]
    project --> config["打造產品用的組態"]
    config --> scope["決定自家公司與廠商的分工"]

圖2：同樣是OS選型，採購完成品與打造組態所負責的範圍並不相同。

2.2. 記憶體下限要在同一種系統類型下解讀

OpenHarmony有輕量、小型、標準3種系統類型。¹

附HMI的裝置主要以標準系統為比較對象，感測器節點與通訊模組則是輕量系統。小型系統的定位偏向相機類產品。

相對於輕量系統的最小128 KiB，Windows 11 IoT Enterprise LTSC針對特定用途裝置的最小需求是記憶體2GB、儲存空間16GB。一般的嵌入式Linux也以搭載MMU的處理器與數十MB以上的RAM為前提。OpenHarmony能用同一套體系涵蓋到MCU領域這一點，是很大的差異。¹⁴

不過，這並不表示128 KiB就能跑標準系統的應用程式。輕量系統是LiteOS-M、小型系統是LiteOS-A、標準系統是Linux，核心與執行環境都不同。不要以為「都是OpenHarmony所以同一個應用程式可以換著搭載」，而要從產品所需的系統類型開始選。

flowchart TB
    accTitle: 從系統類型決定執行環境
    accDescr: 先決定產品所需的系統類型，再確認核心與應用程式的執行環境，不要只憑記憶體下限判斷應用程式的相容性。
    need["產品所需的功能"] --> type["決定系統類型"]
    type --> kernel["確認核心與執行環境"]
    kernel --> app["做出符合該環境的應用程式"]
    minimum["最小記憶體的數字"] -.-> caution["並不保證應用程式相容"]

圖3：128 KiB這個下限，並不代表標準系統的應用程式可以直接運作。

2.3. 綜合比較：用同一組軸看強項與限制

把比較對象放到同一個層級之後，列出6個評估軸。符號分為 ◎＝直接適合／○＝有條件適合／△＝需要注意／×＝不適合 四個等級。這是把各章說明摘要起來的表，並不是所有裝置共通的優劣排序。

OpenHarmony拿到◎的是資源下限與裝置協同這2個軸，既有資產、SDK、日文資訊這3個軸則是×。這不代表它是「不好的OS」，而是說必須挑選採用條件吻合的產品。

面向中國市場的產品、以裝置探索與資料同步、應用程式遷移為價值核心的產品、使用ArkUI的附螢幕IoT裝置，以及想用一套體系涵蓋從MCU到高階裝置的產品線，都值得納入評估。具體的採用與否可以在第7章的判斷表中確認。²

flowchart TB
    accTitle: 把綜合比較表套用到產品的需求上
    accDescr: 不要只憑比較表的評估決定OS，而要套用到產品的核心價值與限制上，再進入採用與否的判斷。
    table["以綜合比較掌握強項與限制"] --> req["套用到自家產品的需求"]
    req --> fit["對照SDK、維護與人力"]
    fit --> decision["進入第7章的分情況判斷"]

圖4：不是去數評估符號的數量，而是套用到自家產品的條件上。

3. 敲定維護：確認承擔方、結束日期與修補範圍

3.1. 首先決定由誰承擔產品的維護

比較維護的目的，不是要判定OpenHarmony本身品質的高低，而是說把社群版原封不動搭載到運作10年的產品上再放著不管，這種做法並不成立。

若要採用，就得購買商用發行版的廠商維護，或是由自家公司維護分支、承擔到CVE修補為止。在工業採用上，實際的採購對象是廠商自行維護分支並付費提供的商用層。華為在2026年6月的說明中也表示，OpenHarmony已發布超過100個商用版本。⁹

因此，該問的不是「OpenHarmony會支援幾年」，而是「那個發行版的哪個分支、維護到什麼時候、以什麼SLA維護」。如果維護無法敲定，即使技術上跑得起來，採用判斷也要先保留。

flowchart TB
    accTitle: 銜接社群維護與產品壽命的承擔方
    accDescr: 不要把社群版原封不動搭載到長期運作的產品上就放著不管，而要由廠商或自家公司承擔產品壽命所需的維護。
    life["產品壽命所需的維護"] --> vendor["簽訂廠商維護合約"]
    life --> own["由自家公司維護分支與修補CVE"]
    vendor --> terms["確定分支、結束日期與SLA"]
    own --> terms
    terms --> adopt["敲定採用判斷的前提"]

圖5：洽詢的對象不是OS整體的年數，而是要採購的分支與維護條件。

3.2. 不看總年數，而看結束日期是否足以涵蓋裝置的運作期間

嵌入裝置中的PC或電路板，被要求要和裝置本體一樣，以前後約10年的生命週期持續運作。以這個時間軸來比較各個OS的維護。

本表以2026年7月時點的各項官方資訊為依據。不只看年數，還要確認表中到結束日期為止的期間，是否足以涵蓋裝置的運作期間。支援期間與結束日期會修訂，因此在做出採用判斷之前應查閱的第一手資料如下。

• OpenHarmony：Version Lifecycle Management(生命週期管理政策)與Version Definitions(分支種類與維護排程表)。⁸¹¹
• Windows：各產品的Microsoft Lifecycle。⁵
• Debian：Debian Wiki LTS。⁶
• Yocto Project：Releases。⁷

flowchart TB
    accTitle: 對照裝置的運作期間與OS的維護結束日期
    accDescr: 不只看OS的支援年數，還要確認所採用版本的結束日期是否足以涵蓋裝置的運作期間。
    device["裝置預定的運作結束時間"] --> compare["對照結束日期"]
    osend["所採用版本的維護結束日期"] --> compare
    compare --> enough{"能否支撐運作期間"}
    enough -->|"不足"| contract["評估維護合約或其他選項"]
    enough -->|"足夠"| scope["再確認修補範圍"]

圖6：不要只看「10年支援」這個名目，還要把該版本的結束日期拿來和裝置的運作計畫比對。

3.3. 把主動維護與被動維護分開來看

OpenHarmony的Release分支是主動維護1年＋被動維護1年，LTS分支是主動維護2年＋被動維護1.5年。請不要只看總和就下判斷。⁸

基於這個差異，本文認為實質上「可以安心使用的期間」，Release應視為1年、LTS應視為2年。社群維護的總年數，與可以期待周全維護的期間是兩回事。⁸

flowchart TB
    accTitle: OpenHarmony維護階段的變化
    accDescr: 主動維護會有計畫地提供標籤版本，被動維護則限縮修補範圍與提供方式，最後迎來維護結束。
    active["主動維護"] --> passive["被動維護"]
    passive --> eol["維護結束"]
    active -.-> regular["有計畫的標籤版本與修補"]
    passive -.-> limited["嚴重以上等級的弱點與缺陷修補"]

圖7：同樣在維護期間內，後半段也不會延續同樣範圍的修補。

3.4. 確認所採用分支的記載

在本文參照的2026年7月時點，近年並未再開出LTS分支。官方維護排程表上列出的LTS，最後一個是3.0-LTS(2021年9月)，3.1、3.2、4.0、4.1全部都是Release。¹¹

並不是一開始就沒有LTS。發行說明索引中還留有1.1.0 LTS(2021年4月)及其系列，但都已是End of Life。3.0-LTS的系列也有列出，3.1以後則都屬於Release類型。¹²

此外，同一時點的維護排程表中沒有5.x系列與6.x系列的記載。請不要拿其他版本來斷定表上沒有的版本的維護期間。必須以期間尚未確定為前提，針對該版本逐一確認。

Windows 11 IoT Enterprise LTSC 2024採固定生命週期，結束日期確定為2034年10月10日；Debian公布了一般支援與LTS期間，Yocto Project則公布了4年的LTS支援。相對地，OpenHarmony必須逐案確認「所採用的分支要維護到什麼程度」。⁵⁶⁷

flowchart TB
    accTitle: 不要推測未列出版本的維護
    accDescr: 先查維護排程上是否列有所採用的版本，沒有記載時不要套用其他版本的期間，而要逐案確認。
    branch["確定所採用的版本與分支"] --> listed{"維護表上是否有記載"}
    listed -->|"有"| dates["確認該版本的期間與結束日期"]
    listed -->|"沒有"| ask["視為期間未定並逐案確認"]
    ask --> hold["在維護敲定之前保留判斷"]

圖8：不要用LTS這個名稱或其他版本的年數，去斷定未列出版本的維護。

4. 調查能否移轉：SDK、應用程式、驅動程式與人力

4.1. 比較OS之前，先盤點依賴的SDK

工業相機、運動控制器、PLC通訊、影像處理等SDK與中介軟體，多半是Windows版優先，其次才是有Linux版就好。OpenHarmony版的供應，一開始就不是能夠期待的狀況。

因此，第一項工作就是下面的盤點。

列出裝置所需的周邊裝置與中介軟體，逐一確認各自對OpenHarmony的支援狀況。

如果沒有必要的SDK，不足的部分又無法由自家公司補上，那麼在該組態下就放棄採用OpenHarmony。若只憑比較表上的功能做出選擇後才去調查SDK，到了後段工程組態就會不成立。本公司承接裝置軟體的諮詢時，也是從製作這份清單開始。

flowchart TB
    accTitle: 從所需的SDK縮小OS候選
    accDescr: 列出裝置所需的周邊裝置與中介軟體，若沒有OpenHarmony版SDK，就確認不足的部分能否由自家公司補上。
    devices["列出周邊裝置與中介軟體"] --> sdk{"必要的SDK是否齊備"}
    sdk -->|"齊備"| next["進入移植範圍的確認"]
    sdk -->|"不齊備"| make{"不足的部分能否自行製作"}
    make -->|"可以"| next
    make -->|"不行"| stop["在該裝置組態下放棄"]

圖9：若沒有SDK又無法自行補上，再繼續比較功能，裝置組態也不會成立。

4.2. Windows裝置軟體無法原樣搬過來

把開發體系的差異並列出來，就能看出對既有資產的影響。

以C#/.NET、Win32、COM、WPF/WinForms撰寫的Windows裝置軟體，在OpenHarmony上實質等於重寫。因為沒有對應的執行環境，UI要改用ArkTS＋ArkUI、底層要改用C/C++這套不同的體系重寫。

若以沿用既有資產為前提，換到Windows IoT Enterprise LTSC比較實際。選擇嵌入式Linux時，Windows的UI等一樣要重寫，但C/C++的量測與控制邏輯較容易移植，只要把範圍限縮在有提供所需Linux版SDK的裝置上，就可以納入評估。

另外，雖然表中OpenHarmony的驅動程式欄位寫的是HDF，但這不表示既有的Linux驅動程式全部都要重寫。從一般的Linux介面使用，與從OpenHarmony的框架使用，兩者的差異會在下一節4.3說明。

flowchart TB
    accTitle: 釐清既有Windows資產的移轉範圍
    accDescr: 把直接沿用既有Windows軟體的路徑，與為其他OS重寫UI和執行環境的路徑分開，在Linux上則確認SDK的供應與C/C++邏輯的可移植性。
    assets["既有Windows裝置軟體"] --> reuse["直接沿用既有資產"]
    assets --> port["為其他OS重寫"]
    reuse --> windows["評估Windows IoT LTSC"]
    port --> scope["區分UI、執行環境與SDK"]
    scope -.-> logic["在Linux上評估C/C++邏輯"]

圖10：更換OS時，不要把UI與執行環境、量測與控制邏輯、SDK全部混為一談。

4.3. 區分使用Linux驅動程式的路徑與適配HDF的工作

OpenHarmony的HDF(Hardware Driver Foundation)是不依賴平台、不依賴核心的統一驅動程式基礎架構，適用於所有系統類型。²

另一方面，標準系統的核心是Linux。因此，把既有的Linux核心驅動程式納入，再從V4L2或輸入裝置這類一般的Linux介面使用，本身是可行的。

如果有Linux BSP，就不需要做出「所有驅動程式都要用HDF重寫」這種估算。先決定哪些裝置需要公開給OpenHarmony的框架，再把那個範圍計入工時。

此外，即使還沒採購開發板，也可以先用QEMU確認結構與啟動流程。這個入口以及採用時的著手順序整理在第8章。

flowchart TB
    accTitle: Linux驅動程式的再利用與對框架的適配
    accDescr: 在標準系統上使用既有Linux驅動程式時，要依從一般Linux介面使用，或經由HDI公開給OpenHarmony框架，分開看待額外的工作。
    driver["標準系統的Linux驅動程式"] --> normal["一般的Linux介面"]
    driver --> hdi["經由HDI使用"]
    normal --> direct["納入既有驅動程式的組態"]
    hdi --> adapt["適配到OpenHarmony端"]
    adapt --> framework["系統服務與框架"]

圖11：不是把所有驅動程式重寫，而是估算要公開給OpenHarmony端的範圍。

4.4. 準備開發環境，以及能讀技術文件的人力

裝置開發的入口有GUI的DevEco Device Tool與CLI。DevEco Device Tool的架構是在Windows上編輯程式碼、偵錯與燒錄，在Ubuntu上編譯的併用方式。取得原始碼使用repo工具，官方列出gitcode.com、gitee.com、GitHub的鏡像。¹³¹⁴

官方文件只有中文與英文兩種，沒有日文版。社群的討論與商用發行版的廠商也以中國方面為主，能用日文獲得第一線支援的窗口相當有限。有能讀完中文或英文技術文件的人員，不是開發開始之後的輔助條件，而是實質上的採用條件。³

flowchart TB
    accTitle: 取得原始碼與裝置開發的執行環境
    accDescr: 使用repo取得的原始碼進行裝置開發時有CLI與DevEco Device Tool兩個入口，後者會結合Windows上的編輯、偵錯、燒錄與Ubuntu上的編譯。
    source["以repo取得原始碼"] --> cli["用CLI開發"]
    source --> ide["DevEco Device Tool"]
    ide --> win["在Windows上編輯、偵錯與燒錄"]
    ide --> ubuntu["在Ubuntu上編譯"]

圖12：除了準備工具之外，還需要能持續閱讀中文或英文技術文件的體制。

5. 確認能否採購：支援的開發板與量產條件

5.1. 支援的開發板中也包含NXP與ST的SoC

本文參照的社群支援開發板清單共22款。以下摘出其中可能與裝置相關的項目。¹⁵

SoC廠商並不只有中國系。清單中也有NXP i.MX8M Mini與ST的STM32系列，因此有可能用日本裝置廠商已經採用的SoC家族來評估。

不過，這張表呈現的是文件上的預期用途。它並不保證10年的供應與在日本國內的流通，也不保證OpenHarmony對量產用電路板的官方支援。

flowchart TB
    accTitle: 區分支援清單與量產的採購條件
    accDescr: 支援的開發板清單是技術評估的入口，並不保證日本國內流通、供應年限，也不保證量產用電路板的官方支援。
    list["支援的開發板清單"] --> candidate["技術評估的候選"]
    candidate --> sale["確認實際銷售與日本國內流通"]
    sale --> supply["確認量產批量與供應年限"]
    list -.-> note["不是長期供應的保證"]

圖13：名字出現在清單上，與產品壽命期間都採購得到，是兩件要分別確認的事。

5.2. 訂購評估機之前，先確認採購條件

清單的主體是評估板，其中也有不少是面向中國市場的產品，未必能在日本國內的代理商輕易買到。在調度評估機之前，要先洽詢下列3點。

1. 開發板廠商的銷售頁面或跨境電商是否有販售。
2. 日本國內是否有銷售代理商。
3. 量產時的最低批量與供應年限為何。

即使列在支援清單上，只要採購不到需要的開發板，就無法用實機推進技術驗證。請連同OS的維護期間，一起確認開發板的供應條件。

若要搭載到自家電路板上，移植是自家公司或發行版商的工作。這與在Windows IoT上向OEM代理商採購授權、使用廠商提供的驅動程式，負責範圍並不相同。如果SoC已經確定，與其去找評估板，估算移植到該SoC的工時有時反而更實際。

flowchart TB
    accTitle: 評估板與自家電路板要分開準備
    accDescr: 使用評估板時要調查取得難易度與量產條件，使用自家電路板或已決定的SoC時則要估算移植的負責範圍與工時。
    hardware["產品所使用的硬體"] --> board["評估使用評估板"]
    hardware --> own["自家電路板或已決定的SoC"]
    board --> procure["確認取得難易度與量產條件"]
    own --> port["確認移植的負責範圍與工時"]
    procure --> plan["與OS維護一起規劃"]
    port --> plan

圖14：採購計畫裡不能只有評估機的採購，還要納入搭載到產品用硬體上的工作。

6. 確認出貨的條件：授權、認證與生態系

6.1. 逐一確認納入範圍內的LICENSE

OpenHarmony並非單一授權。請列出要納入產品的版本庫，依範圍逐一確認。

如果一概認為「OpenHarmony是Apache 2.0所以沒問題」，就會漏看標準系統中Linux核心部分的GPL義務。與以商用授權採購OS的Windows IoT相比，實務上的差異也在於這種逐一元件確認授權的工作。

flowchart TB
    accTitle: 從產品所含的範圍確認授權
    accDescr: 不要把OpenHarmony整體視為單一授權，而要列出納入產品的版本庫，確認各自的LICENSE與散發時應有的處理。
    product["納入產品的組態"] --> repos["列出對象版本庫"]
    repos --> licenses["確認各個LICENSE"]
    licenses --> delivery["整理散發時的處理"]
    delivery --> legal["與法務及智慧財產權部門確認"]

圖15：不要只憑Apache 2.0就下判斷，而要針對實際納入的每個元件逐一確認。

6.2. 區分修改核心與把裝置散發給客戶

GPLv2產生義務的時間點不是修改的當下，而是散發(distribution)的時間點。如果只是在公司內部的驗證機上修改核心並執行，不會產生提供原始碼的義務。

把裝置交付給客戶時，就會產生向散發對象提供與所散發二進位檔對應之原始碼(包含修改的部分)的義務。對裝置廠商而言「交付＝散發」，因此量產與交付時必須處理。請把並非從公司內部試作階段就有公開義務，與交付給客戶時必須處理這兩件事分開。具體的合規方式，請與自家公司的法務及智慧財產權部門確認。

flowchart TB
    accTitle: 區分公司內部修改核心與對客戶散發
    accDescr: 檢討GPLv2的原始碼提供義務時，要把僅止於公司內部使用的情況，與把含有核心二進位檔的裝置散發給客戶的情況分開。
    kernel["包含Linux核心的組態"] --> internal["僅止於公司內部驗證與使用"]
    kernel --> distribute["把裝置散發給客戶"]
    internal --> no["僅公司內部修改不產生提供義務"]
    distribute --> corresponding["處理對應原始碼的提供"]

圖16：把修改的時間點與交付裝置給客戶的時間點分開，再確認各自的義務。

6.3. 區分跑得起來與自稱OpenHarmony相容

除了授權方面的處理之外，還要確認對外宣告相容性所需的程序。

6.3.1. 公司內部驗證與產品的相容性宣告

如果只是公司內部驗證或單一台裝置上使用，不需要相容性認證。另一方面，若要以產品形式對外宣稱「OpenHarmony相容」，或希望被視為生態系的一員，就要以通過開放原子基金會(OpenAtom)的相容性測評為前提來估算工時。

技術基礎是相容性測試套件群組XTS(X Test Suite)。流程是由申請者進行合規開發與自我測試，附上測試報告後提出申請。²¹⁹

flowchart TB
    accTitle: 宣告相容性的產品該做的認證準備
    accDescr: 對外宣稱OpenHarmony相容的產品，要確認被要求的測試，準備合規開發、自我測試與報告，再向相容性測評提出申請。
    claim["宣告OpenHarmony相容"] --> required["確認申請時點的測試要求"]
    required --> test["合規開發與自我測試"]
    test --> report["準備測試報告"]
    report --> apply["向相容性測評申請"]

圖17：在公司內部確認過可以運作，與能夠宣告產品的相容性，並不是同一件事。

6.3.2. ACTS、HATS、DCTS要結合資料差異來確認

在本文參照的2026年7月時點，XTS的組成內容依資料來源而有差異。

官方資料把DCTS當成未來才提供，社群資料卻把它說明為組成要素。不要斷定DCTS是必要條件，請向認證窗口確認申請時點實際要求的套件。這種記述上的差異，加上沒有日文的第一手資料，在採用時也會成為溝通成本。²¹⁹

6.4. 確認客戶要求的生態系與採購方針

如果客戶要的是AppGallery上架或與HarmonyOS應用程式的協同，OpenHarmony無法滿足這些需求。AppGallery、HMS、HarmonyOS SDK都不包含在OpenHarmony裡，HarmonyOS應用程式的相容性也不受保證。需要的是支援HarmonyOS的產品與HarmonyOS SDK，這和「OpenHarmony相容」的認證是兩回事。

flowchart TB
    accTitle: 區分OpenHarmony相容與HarmonyOS的需求
    accDescr: 先釐清客戶要的是OpenHarmony相容，還是AppGallery上架與HarmonyOS應用程式協同，後者要當成支援HarmonyOS的產品與SDK的需求來處理。
    customer["客戶要求的條件"] --> oh["OpenHarmony相容"]
    customer --> harmony["AppGallery與HarmonyOS協同"]
    oh --> cert["OpenHarmony的相容性測評"]
    harmony --> commercial["支援HarmonyOS的產品與SDK"]

圖18：OpenHarmony的相容性認證，無法取代HarmonyOS端的上架與協同需求。

採購方針方面同樣要區分針對營運主體的限制與針對程式碼來源的限制。若屬前者，位於歐洲基金會治理之下的Eclipse Oniro系可以列入評估，但在本文的基準時點2026年7月仍處於Incubating階段，社群規模也無法與OpenHarmony本體相比。若後者是「不得包含源自中國的程式碼」，由於Oniro同樣建構在OpenHarmony的基礎層之上，這項限制並不會解除。

flowchart TB
    accTitle: 針對營運主體的限制與針對程式碼來源的限制
    accDescr: 把採購方針針對營運主體的情況與針對程式碼來源的情況分開，確認即使是歐洲治理的Oniro，源自OpenHarmony的程式碼這項條件仍然不變。
    policy["採購方針的限制"] --> governance["營運主體與治理"]
    policy --> origin["程式碼的來源"]
    governance --> oniro["有條件地評估Oniro系"]
    origin --> remain["用Oniro也無法解除限制"]
    oniro -.-> maturity["也要確認2026年7月時點的成熟度"]

圖19：不要把更換營運主體與更換程式碼來源混為一談。

7. 決定採用與否：對照產品需求與能夠承擔的條件

7.1. 從市場與產品需求開始依序判斷

確認前提的順序是市場與產品需求在前，技術評估在後。在此之上，再確認SDK、維護，以及能讀技術文件的人力。即使技術上做得出來，只要維護沒有敲定，就無法決定在裝置上採用。

flowchart TB
    accTitle: 把OpenHarmony採用為裝置OS的主要判定
    accDescr: 先確認市場需求或裝置協同的價值，再確認SDK、維護與能讀技術文件的人力，無法滿足條件時就評估Windows IoT或嵌入式Linux。
    S["選擇裝置要搭載的OS"] --> Q1["是否面向中國市場或指定相容"]
    Q1 -->|"是"| Q3["SDK是否齊備或能自行製作"]
    Q1 -->|"否"| Q2["裝置協同是否為產品價值的核心"]
    Q2 -->|"是"| Q3
    Q2 -->|"否"| OTH["Windows IoT LTSC / Linux"]
    Q3 -->|"齊備／可自行製作"| Q4["維護能否敲定"]
    Q3 -->|"不齊備"| NG["放棄OpenHarmony"]
    Q4 -->|"可以敲定"| Q5["是否有人能讀中文或英文"]
    Q4 -->|"無法敲定"| NG
    Q5 -->|"有"| OH["正式評估OpenHarmony"]
    Q5 -->|"沒有"| NG
    NG --> OTH
    OH -.-> vendor["以商用發行版採購"]
    OTH -.-> assets["依既有資產與SDK支援來選"]

圖20：以市場與產品需求為入口，依序確認SDK、維護與人力的條件。

實際上，多數案子會卡在Q3(廠商SDK)與Q4(維護合約)而無法滿足條件，這正是本文的主旨。這張圖呈現的是主要判定的流程。MCU用途、產品線統一、採購方針等個別條件，請搭配下一張表一起判斷。

7.2. 分情況的判斷表

表中的支援年數是各版本的生命週期。是否與裝置的運作期間相符，請連同第3章的結束日期一併確認。此外，即使是表中建議採用OpenHarmony的用途，SDK、維護與人力的條件也不會因此變得不必要。

8. 若仍留在候選名單，用7項工作把它具體化

若在判斷表中仍留在候選名單，就進入下列7項工作。在QEMU或實機上跑起來，與能否作為產品採用是兩回事。請不要在維護條件尚未確定的情況下，僅憑技術驗證成功就決定採用。

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等環境，確認建置與啟動的流程。²⁰
4. 固定維護分支，確保建置的再現性。固定repo的manifest(指定標籤最為確實)，建立公司內部鏡像，做到5年後也能重新產生相同的二進位檔。上游託管以gitcode.com為主這一點，從事業延續性的角度來看也是自建鏡像的理由。¹⁴
5. 盤點授權。列出要納入的版本庫，整理Apache 2.0／BSD／GPL各自的義務。
6. 協商維護合約。與商用發行版的廠商敲定「維護哪個分支、到什麼時候、以什麼SLA」。若無法敲定，就保留採用判斷。
7. 判斷是否需要相容性測評。若要對外宣稱OpenHarmony相容，就要從一開始就把以XTS進行的合規開發、自我測試與申請的工時計入。

flowchart TB
    accTitle: 把技術驗證銜接到產品的採用條件
    accDescr: 確定周邊裝置與系統類型後用QEMU確認結構，再敲定建置再現性、授權、維護合約與認證需求，然後進入採用判斷。
    inventory["盤點裝置與SDK"] --> type["確定系統類型"]
    type --> qemu["用QEMU確認結構與啟動"]
    qemu --> reproduce["固定分支與建置再現性"]
    reproduce --> conditions["確認授權、維護與認證"]
    conditions --> decision["作為產品的採用判斷"]

圖21：不要停在運作驗證，還要把未來的重新建置與出貨後的維護一併具體化。

8.1. 總結：選擇符合裝置時間軸、採購與人力的OS

OpenHarmony能用一套體系涵蓋從128 KiB的MCU到128 MiB以上的高階裝置，並標準內建以DSoftBus實現的裝置協同，技術上是條理清楚的設計。預期用於工業用途的支援開發板中，也包含NXP與ST的SoC。¹²¹⁵

另一方面，對於運作10年的裝置而言，社群維護的Release 2年、LTS 3.5年明顯不足。加上在本文的基準時點，3.0-LTS之後未再開出LTS，若沒有商用發行版的維護，或是由自家公司負責到CVE修補為止的體制，就不是可以採用的選項。⁸¹¹¹²

日本的裝置廠商該確認的是所用裝置的SDK、能讀技術文件的人力，以及支撐產品壽命的維護。這些若無法齊備，Windows IoT Enterprise LTSC或附商用支援的嵌入式Linux比較實際。反過來說，如果中國市場的需求、裝置協同、從MCU到高階裝置的體系統一直接關係到產品價值，那麼正式評估OpenHarmony是有價值的。

OS選型不是「哪一個比較優秀」的判斷，而是哪一個符合裝置的時間軸、採購與人力的判斷。Windows端的選型標準，整理在「工業用電腦該安裝哪一種Windows」中。

相關文章

• OpenHarmony是什麼 ── 整理它與HarmonyOS、HarmonyOS NEXT的差異
• 工業用電腦該安裝哪一種Windows ── Windows IoT Enterprise / LTSC 實踐指南
• Windows 10支援結束後的現實解方
• Windows Kiosk模式(Assigned Access)的實務指南

相關諮詢領域

合同會社小村軟體提供裝置搭載執行基礎的選型支援、既有Windows裝置軟體移轉可行性的釐清，以及以長期運作為前提的架構審查。從「有新的OS成為候選，但公司內部沒有可比較的材料」這個階段開始，就歡迎與我們洽詢。

• 技術諮詢與設計審查
• 軟即時Windows應用程式開發
• Windows應用程式開發
• 聯絡我們

參考連結

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

工業設備的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 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。