KomuraSoft LLC
Contact
Menu

Is OpenHarmony a Viable OS for Industrial Equipment? — Compared with Windows IoT and Embedded Linux

· · OpenHarmony, Embedded, OS Selection, Equipment Embedded Software, Windows IoT, Linux, Manufacturing, Technical Consulting

In the previous article, “What Is OpenHarmony?”, we separated out the three entities that are OpenHarmony, HarmonyOS and HarmonyOS NEXT. From here on it is a practical discussion. As an OS to put into a device, is OpenHarmony genuinely a viable option?

For an equipment manufacturer, OS selection has elements that are decided before any feature comparison. You cannot put an OS that is maintained for two years into a device that runs for ten. If you are using a camera whose vendor SDK exists only for Windows, that OS is out of the running from the start. In this article we line up Windows IoT Enterprise LTSC, embedded Linux (Debian- or Yocto-based) and OpenHarmony and compare them from the perspective of the device’s timescale and of procurement, and set out the conditions under which you may adopt it and the conditions under which you should pass in a decision table.

Note that this article is neither “an article recommending OpenHarmony” nor “an article telling you to steer clear”. What we normally handle is Windows equipment software, but we have repeatedly seen situations where a decision gets made on the basis of “it’s a new technology” or “it comes from China” without the options ever being compared properly. The purpose here is to assemble the material for a decision.

1. The Bottom Line First

  • The maintenance window is the biggest dividing line. The OpenHarmony community’s Release branches run two years (one year proactive maintenance plus one year passive maintenance), and even LTS branches 3.5 years (two years plus 1.5). The premises are different from the ten years of Windows 11 IoT Enterprise LTSC 2024.12
  • And in recent years no LTS branches have been cut. LTS versions did appear early on (1.1.0 LTS, 3.0-LTS), but the last LTS remaining in the official maintenance schedule table is 3.0-LTS from September 2021. Every branch published from 3.1 onwards is a Release.34
  • Consequently, running the community version straight in a product is not workable. Adopting it requires either buying vendor maintenance from a commercial distribution or having an in-house capability to maintain a branch and handle CVEs. Huawei states that “OpenHarmony has released more than 100 commercial versions”, and this commercial layer is where actual adoption happens.5
  • OpenHarmony’s resource floor is overwhelmingly lower. The mini system runs from a minimum of 128 KiB on an MCU. The minimum requirements for Windows 11 IoT Enterprise LTSC on special-purpose devices are 2 GB of memory and 16 GB of storage, so they are not even in the same arena.67
  • You cannot bring existing Windows equipment software assets across. There is no runtime equivalent to C#/.NET, Win32, COM or WPF/WinForms; the UI becomes ArkTS plus ArkUI and drivers become HDF, a different set of technologies. It is a rewrite, not a port.
  • The real bottleneck is vendor SDKs. Most industrial cameras, motion controllers and PLC communication libraries are supplied only for Windows, and then Linux. Whether an OpenHarmony driver exists is an item to check before the OS comparison, not after.
  • There is essentially no Japanese-language primary information or support. The official documentation comes in two languages, Chinese and English; there is no Japanese version.8 Having people who can read technical documents in Chinese or English from end to end is a de facto precondition.
  • There are definitely use cases it suits. Products for the Chinese market; devices where collaboration between multiple devices (DSoftBus) is central to the product’s value; screen-equipped IoT devices where you want to use ArkUI for the UI; and cases where you want to cover everything from MCU to rich device within a single family.9

2. Levelling the Ground for Comparison — What Are We Comparing With What?

Before starting the comparison, let us be clear about the subjects. “OS” is one word, but lining up things that sit at different layers makes the discussion incoherent.

Option What it actually is Kernel UI / app layer
Windows 11 IoT Enterprise LTSC Microsoft’s commercial OS product Windows NT Win32 / WinUI / WPF / WinForms, .NET
Embedded Linux (Debian-based) A distribution Linux Your choice (Qt, GTK, a Wayland compositor and so on)
Embedded Linux (Yocto-based) A framework for building your own distribution Linux Your choice
OpenHarmony standard system An OS project (needs turning into a distribution) Linux ArkUI, ArkTS, Ability
OpenHarmony small system As above LiteOS-A Standard graphics framework
OpenHarmony mini system As above LiteOS-M Lightweight graphics framework

The thing to grasp here is that OpenHarmony is not a “finished product you buy and install” in the way Windows IoT is. In terms of position it is closer to Yocto: a framework for “building a configuration for your own product on top of this”. Unlike Yocto, though, the UI framework and app model are also fixed as part of the package, so it stacks further up the layers.

The definitions of OpenHarmony’s system types are as follows.6

System type Processor Minimum memory Target products
Mini system MCUs such as Arm Cortex-M and 32-bit RISC-V 128 KiB Connectivity modules, sensors, wearables
Small system Application processors such as Arm Cortex-A 1 MiB IP cameras, smart door viewers, routers, dashcams
Standard system Application processors such as Arm Cortex-A 128 MiB Screen-equipped devices with a complete application framework

In an equipment-embedding context, the candidates for comparison are mainly the standard system (equipment with an HMI) and the mini system (sensor nodes, communication modules). The small system sits closer to camera products.

3. Comparing Support Periods — Which One Fits the Device’s Timescale?

A PC or board built into a piece of equipment is expected to keep running for the same ten-year-or-so lifecycle as the equipment itself. Line the options up from this perspective and the difference is obvious.

Option Support period Concrete example Source
Windows 11 IoT Enterprise LTSC 2024 10 years Starts 1 October 2024, ends 10 October 2034 2
Windows 10 IoT Enterprise LTSC 2021 10 years Ends 13 January 2032 10
Debian (including LTS) About 5 years The LTS period for Debian 12 bookworm runs from 11 June 2026 to 30 June 2028 11
Yocto Project LTS 4 years 5.0 Scarthgap runs April 2024 to April 2028; 6.0 Wrynose April 2026 to April 2030 12
OpenHarmony LTS branch 3.5 years (2 years + 1.5) 3.0-LTS ran 30 September 2021 to 30 March 2025 13
OpenHarmony Release branch 2 years (1 year + 1 year) 4.1-Release ran 30 March 2024 to 30 March 2026 13

There are two further points to read into this.

First: the quality of OpenHarmony’s “passive maintenance period” drops. Under the official lifecycle management policy, during the proactive maintenance period the community issues tagged versions on a plan and fixes defects and security vulnerabilities; but once the passive maintenance period begins, no tagged versions are planned or released and only security vulnerabilities and defects of critical severity or above are in scope for fixes.1 In other words, you should treat the period you can genuinely rely on as one year for a Release branch and two years for an LTS.

Second: no LTS branches have been cut in recent years. The last LTS in the official maintenance schedule table is 3.0-LTS (September 2021); 3.1, 3.2, 4.0 and 4.1 are all of Release type.3 LTS versions did exist before that — the release notes index still carries 1.1.0 LTS (April 2021) and its series — but all of them are End of Life.4 Furthermore, the 5.x and 6.x lines are not yet listed in this maintenance schedule table. Against the premise of a ten-year device lifecycle, this amounts to an ongoing situation where “how much maintenance which branch gets” cannot be read off release by release.

Windows 11 IoT Enterprise LTSC 2024, by contrast, is on the Fixed Lifecycle Policy, with an end date of 10 October 2034 fixed from the outset.2 Debian also publishes the standard support and LTS periods for each release, and the Yocto Project states explicitly that it supports LTS releases for four years.1112

This is not a statement that OpenHarmony’s quality is low. It is simply that this maintenance model does not envisage “putting the community version straight into a product and leaving it there”. In real industrial adoption, the vendor of a commercial distribution maintains its own branch and provides that maintenance commercially. What you should be checking when assessing adoption is not “how many years is OpenHarmony supported for?” but “which branch will that distribution’s vendor maintain, until when, and under what SLA?”

4. Hardware Options

The community publishes support for 22 development boards.13 Picking out the ones likely to be relevant to equipment gives the following.

System type Board SoC Intended uses per the documentation
Standard HiHope HH-SCDAYU200 Rockchip RK3568 NVRs, industrial gateways, home appliances
Standard MILOS_Standard0 NXP i.MX8M Mini High-performance measurement instruments for industry and healthcare, industrial control and HMI, transport, disaster prevention, buildings
Standard Yangfan Rockchip RK3399 Digital signage, unattended terminals, industrial control hosts, robotics
Standard ZLG development board Allwinner T507 Industrial control, smart cockpits, smart power
Standard Unionpi Tiger Amlogic A311D Industrial control, AI edge computing
Small BearPi-HM Micro ST STM32MP157A Smart home, central control panels
Mini Niobe407 ST STM32F407IGT6 Smart transport, industrial control
Mini HPM6750EVK2 HPMicro HPM6700 (RISC-V) Industrial control, edge computing

What matters is that the SoC vendors are not only Chinese. The fact that the NXP i.MX8M Mini and ST’s STM32 series are on the supported list has real meaning for a Japanese equipment manufacturer, because it may be possible to evaluate it on an SoC family you already have a track record with.

The caveats, however, are just as substantial.

  • The list of supported boards and the industrial boards you can actually buy are different things. What is listed here is mostly evaluation boards; whether OpenHarmony is officially supported on an industrial board with a ten-year supply guarantee needs checking separately.
  • If you put it on your own hardware, the porting is your work. Where with Windows IoT you would “buy the licence through an OEM distributor and have the vendor supply the drivers”, with OpenHarmony that becomes work for you or your distributor.
  • How drivers are handled depends on “where you use them from”. OpenHarmony has HDF (Hardware Driver Foundation), a unified driver foundation, and it is designed to be platform-independent and kernel-independent and applies to all system types.9 However, since the standard system’s kernel is Linux, it is perfectly possible to build in an existing Linux kernel driver as-is and use it through the ordinary Linux interfaces such as V4L2 or input devices. Adaptation work becomes necessary when you want that device to be handled through HDI by OpenHarmony’s system services and frameworks. If you already have a Linux BSP, you do not need to estimate “rewriting all drivers in HDF”. Decide first which devices you want to expose to OpenHarmony’s frameworks, and put only that scope into your effort estimate.

5. Development Environment and Languages — Can You Bring Existing Assets Across?

Item Windows IoT Enterprise LTSC Embedded Linux OpenHarmony
Build system MSBuild / Visual Studio Make / CMake / BitBake (Yocto) GN + Ninja9
Main languages C#, C++, VB C, C++, Python, Rust ArkTS (a TypeScript extension), C, C++
UI framework WPF, WinForms, WinUI Qt, GTK, Flutter and so on ArkUI
Drivers WDM / WDF Linux kernel drivers HDF
IDE Visual Studio Your choice DevEco Device Tool (Windows plus Ubuntu in combination) or the CLI14
Japanese documentation Yes Plentiful None (Chinese and English only)8

Viewed in terms of equipment software assets, the story is simple. Equipment software written for Windows cannot be brought across to OpenHarmony. There is no corresponding runtime for C#/.NET, Win32, COM or WPF. The UI is rewritten in ArkTS and ArkUI, and the layers underneath in C/C++.

An even more practical obstacle is the state of vendor SDK support. Industrial camera SDKs, motion controller libraries, PLC communication middleware, image processing libraries — most of these are Windows-first, and you are lucky if a Linux build is provided. Support for OpenHarmony cannot be expected. Therefore:

Before any OS comparison, draw up a list of the peripheral devices and middleware the equipment needs, and check the OpenHarmony support status of each.

Argue from an OS comparison table without doing this and you will certainly come unstuck later in the project. When we take on equipment software consultations, we start by drawing up exactly this list.

There are two entry points for the development environment: the GUI-based DevEco Device Tool (a combined setup where you edit, debug and flash code on Windows and compile on Ubuntu) and a CLI-based procedure.14 Source is obtained with the repo tool, with mirrors on gitcode.com, gitee.com and GitHub.15

6. Licensing and Intellectual Property

OpenHarmony is not a single licence. Each area you incorporate needs checking.

Subject Licence Practical caution
Many components (build system, ArkUI engine and so on) Apache License 2.016 Compliance with the copyright and patent clauses, and stating your modifications
The LiteOS-A kernel BSD 3-Clause17 The copyright notice, and reproducing the disclaimer in binary distributions
The Linux kernel portion of the standard system GPLv2 (the licence of the Linux kernel itself) When you distribute the device to a customer, an obligation to provide the recipient with the source corresponding to the distributed binaries (including your modifications). Modifications that remain in-house incur no obligation to provide
Official documentation CC BY 4.018 Attribution when quoting

Summarising it as “OpenHarmony is Apache 2.0, so we’re fine” will cause you to miss the GPL obligations in the standard system’s kernel portion. The principle is to enumerate the repositories in the scope you are putting into the device and check their LICENSE files one at a time. This is a practical difference from Windows IoT (where a single commercial licence covers it).

One clarification on GPLv2. The obligation arises at the point of distribution, not at the point of modification. If you are only modifying the kernel and running it on an in-house test machine, no obligation to provide arises; it arises once you deliver that device to a customer, at which point you must provide the recipient with the source code corresponding to the distributed binaries. For an equipment manufacturer, “delivery = distribution”, so you will need to deal with it in the end — but keep the distinction in mind that there is no disclosure obligation from the in-house prototyping stage (check the specific means of compliance with your own legal and IP departments).

7. Certification and Participating in the Ecosystem

To claim publicly that a product is “OpenHarmony compatible”, you need to pass the OpenAtom Foundation’s compatibility assessment. The technical basis is OpenHarmony’s XTS (X Test Suite), which the official documentation describes as “providing a set of OpenHarmony compatibility test suites, including the currently supported application compatibility test suite (ACTS) and the device compatibility test suite (DCTS) to be supported in future”.9 In other words, on the official documentation’s account (as of July 2026), what is provided at present is ACTS, and DCTS is to be provided in future.

Community certification-procedure material, on the other hand, describes XTS as a three-part structure of ACTS, HATS (hardware abstraction layer compatibility) and DCTS, which conflicts with the official documentation’s description.19 The flow itself — the applicant carries out adaptation development and self-testing in-house and applies with a test report attached — is common to both.

When you estimate effort, do not fix DCTS as a mandatory requirement. Which suites are actually required at the time you apply is best confirmed directly with the certification desk. This kind of situation, where “the official documentation and community material do not agree”, is something you should budget for as a communication cost of adoption, alongside the absence of Japanese-language primary information.

Certification is not required if you are only using it for internal verification or a one-off device, but it becomes a precondition for a product that claims compatibility publicly, or a product you want treated as a member of the ecosystem. It is an item to build into your effort estimate from the start.

8. Decision Table — When to Adopt, When to Pass

Situation Recommendation Reason
An HMI-equipped PC built into a device with a ten-year operating life, with existing Windows assets Windows 11 IoT Enterprise LTSC 2024 Ten years of support to October 2034. No feature updates. Existing equipment software and vendor SDKs run as-is2
A device with a ten-year operating life, Linux SDKs available, Linux people in-house Commercially supported embedded Linux Four years with Yocto LTS, extensible via a long-term support contract with a commercial distribution12
A product shipping to the Chinese market where the requirement is “must be OpenHarmony compatible” OpenHarmony (via a commercial distribution) The market requirement determines the OS. Procure it with vendor maintenance included
The customer requires participation in the HarmonyOS ecosystem (AppGallery distribution, interworking with HarmonyOS apps) OpenHarmony cannot meet the requirement Neither AppGallery nor HMS nor the HarmonyOS SDK is included in OpenHarmony, and compatibility with HarmonyOS apps is not guaranteed either. You need to choose a HarmonyOS-supporting product and the HarmonyOS SDK
Collaboration between multiple devices (device discovery, data synchronisation, app migration) is central to the product’s value OpenHarmony DSoftBus, distributed data management and the distributed scheduler are included as standard9
You want a single family covering the product line from MCU to rich device OpenHarmony (worth considering) Covers 128 KiB up to 128 MiB and beyond within one family6
Sensor nodes and communication modules (MCU, in the hundreds of KiB) OpenHarmony mini system, or an RTOS Windows IoT is out of the arena (2 GB minimum)7
You want ten years of maintenance guaranteed contractually, and you have no one in-house who can read technical documents in Chinese or English Pass Community maintenance is 3.5 years at most, and there is no Japanese documentation or Japanese first-line support18
Equipment that depends on vendor SDKs for industrial cameras, motion controllers and the like Pass (verify first) OpenHarmony support from SDK vendors can hardly be expected
You want to make use of existing C#/.NET and COM assets Pass There is no corresponding runtime; it becomes a rewrite
Your procurement constraint is about “the project’s governance and operating body” Consider the Eclipse Oniro line Oniro is under European foundation governance. That said, it is Incubating as of July 2026, and its community is nowhere near the scale of OpenHarmony proper
Your procurement constraint is about “containing no code of Chinese origin” Pass Oniro too is built on top of OpenHarmony’s base layer, so even with European foundation governance the constraint on code provenance is not resolved

9. What to Do First If You Adopt It

If the decision table points to “adopt”, the order of work is as follows.

  1. Take stock of peripheral devices and middleware. Cameras, I/O, communications, motion, image processing — check whether each vendor can support OpenHarmony. If you get stuck here, there is no point proceeding with any of the other steps.
  2. Fix the system type. Decide whether you are building on the mini, small or standard system. This determines the kernel (LiteOS-M / LiteOS-A / Linux) and how you write the apps.
  3. Examine the structure under QEMU. Before buying real hardware, you can confirm the build and boot flow in the emulation environments device_qemu provides for Arm Virt (LiteOS-A / Linux), Cortex-M4, Cortex-M55, RISC-V and others.20
  4. Pin the maintenance branch and secure build reproducibility. Pin the repo manifest (specifying a tag is the reliable way), keep an internal mirror, and get to a state where you can regenerate the same binaries five years from now.15 The fact that upstream hosting is centred on gitcode.com is itself a reason, from a business continuity point of view, to keep your own mirror.
  5. Take stock of licences. Enumerate the repositories in the scope you are incorporating and work through the Apache 2.0 / BSD / GPL obligations.
  6. Negotiate a maintenance contract. Nail down with the commercial distribution’s vendor, in a contract, “which branch, until when, under what SLA”. If this cannot be settled, the adoption decision should be held.
  7. Decide whether compatibility assessment (XTS) is required. If you are going to claim compatibility publicly, build the effort in from the start.

10. Summary

  • Technically, OpenHarmony is a coherent design: it covers everything from a 128 KiB MCU to rich devices with 128 MiB and up within a single family, and it has device collaboration (DSoftBus) as standard. There are supported boards aimed at industrial use, including SoCs from NXP and ST.
  • On the other hand, from the perspective of a ten-year device lifecycle, the community maintenance window (two years for Release, 3.5 for LTS) is clearly insufficient. And no LTS branch has been cut since 3.0-LTS in 2021. Adopting it presupposes vendor maintenance from a commercial distribution.
  • For a Japanese equipment manufacturer there are three practical conditions for adoption: (1) do the vendor SDKs support OpenHarmony, (2) do you have people who can read technical documents in Chinese or English from end to end, and (3) is there a vendor with whom you can pin maintenance down contractually? If even one of these is missing, Windows IoT Enterprise LTSC or commercially supported embedded Linux fits the device’s timescale better.
  • Conversely, for products aimed at the Chinese market, products where device collaboration is central to the value, and product lines you want to cover from MCU to rich device within one family, it is worth considering head-on.

OS selection is not a question of “which is superior” but of “which meshes with the device’s timescale, procurement and staffing”. Our criteria for selecting on the Windows side are set out in “Which Windows Should You Install on an Industrial PC?”.

At KomuraSoft LLC we support the selection of the runtime platform to put into equipment, the triage of whether existing Windows equipment software can be migrated, and reviews of configurations intended for long-term operation. You are welcome to come to us at the stage of “a new OS has come up as a candidate, but we have nothing in-house to compare it against”.

References

  1. OpenHarmony, OpenHarmony Version Lifecycle Management. On the lifecycle of a Release branch being two years (one year proactive maintenance plus one year passive maintenance) and an LTS branch 3.5 years (two years plus 1.5), and on the passive maintenance period involving no planning or release of tagged versions and fixing only security vulnerabilities and defects of critical severity or above. ↩ ↩2 ↩3 ↩4 ↩5

  2. Microsoft Learn, Windows 11 IoT Enterprise LTSC 2024 - Microsoft Lifecycle. On the start date of 1 October 2024 and end of extended support on 10 October 2034 (ten years in total). ↩ ↩2 ↩3 ↩4

  3. OpenHarmony Documentation, OpenHarmony Version Definitions. On the maintenance schedule table for the LTS and Release branches (that the only LTS in this table is 3.0-LTS, that 1.0.1, 3.1, 3.2, 4.0 and 4.1 are of Release type, that maintenance for 4.1-Release ended on 30 March 2026, and that the 5.x and 6.x lines are not yet listed in the table). ↩ ↩2 ↩3 ↩4

  4. OpenHarmony Documentation, Release Notes index. On 3.0-LTS (30 September 2021) and its series being listed and everything from 3.1 onwards being of Release type; on LTS versions (1.1.0 LTS and others) also having existed in the 1.x line but being marked End of Life; and on 6.1 Release (8 March 2026) being listed. ↩ ↩2

  5. Huawei, HarmonyOS 7 开发者Beta 正式启动，全场景智能操作系统再升级. On the statement at HDC 2026 on 12 June 2026 that OpenHarmony has released more than 100 commercial versions. ↩

  6. OpenHarmony Documentation, Quick Start Overview. On the definitions and target products of the three system types — mini system (MCU, minimum 128 KiB), small system (Cortex-A, minimum 1 MiB) and standard system (Cortex-A, minimum 128 MiB). ↩ ↩2 ↩3

  7. Microsoft Learn, Minimum System Requirements - Windows IoT Enterprise. On the OPTIONAL minimum requirements for special-purpose devices being defined as 2 GB of memory and 16 GB of storage. ↩ ↩2

  8. OpenHarmony Documentation, README. On the official documentation being provided in two languages, Chinese (zh-cn) and English (en), with no Japanese version, and on the correspondence between each version and its API level. ↩ ↩2 ↩3

  9. OpenHarmony Documentation, OpenHarmony Project. On the four-layer architecture and the multi-kernel design with Linux and LiteOS; the unified driver foundation provided by HDF (Hardware Driver Foundation); DSoftBus, distributed data management and the distributed scheduler; the build system being GN + Ninja; and XTS being a set of compatibility test suites described as “the currently supported application compatibility test suite (ACTS) and the device compatibility test suite (DCTS) to be supported in future”. ↩ ↩2 ↩3 ↩4 ↩5

  10. Microsoft Learn, Windows 10 IoT Enterprise LTSC 2021 - Microsoft Lifecycle. On extended support ending on 13 January 2032. ↩

  11. Debian Wiki, LTS. On Debian LTS being a project that extends the lifetime of each stable release to at least five years, and on the LTS period for Debian 12 bookworm running from 11 June 2026 to 30 June 2028. ↩ ↩2

  12. Yocto Project Wiki, Releases. On the policy of supporting LTS releases for four years, and on 5.0 Scarthgap being released in April 2024 and supported to April 2028, and 6.0 Wrynose being released in April 2026 and supported to April 2030. ↩ ↩2 ↩3

  13. OpenHarmony Documentation, OpenHarmony Development Boards List. On there being 22 community-supported development boards, and on the SoC and intended uses of each board (for example the MILOS_Standard0’s NXP i.MX8M Mini listing measurement instruments for industry and healthcare and industrial control and HMI, and the Niobe407’s STM32F407 listing industrial control, among its intended uses). ↩

  14. OpenHarmony Documentation, Quick Start Overview. On two entry points being provided for device development: an IDE mode using DevEco Device Tool (a hybrid setup with code development, debugging and flashing on Windows and source compilation on Ubuntu) and a CLI mode. ↩ ↩2

  15. OpenHarmony Documentation, Source Code Acquisition. On the procedure for obtaining the source with the repo tool, the gitcode.com, gitee.com and GitHub mirrors, and how to specify a branch or a tag. ↩ ↩2

  16. OpenHarmony, arkui_ace_engine LICENSE and build LICENSE. On the ArkUI engine and build system repositories being distributed under Apache License 2.0. ↩

  17. OpenHarmony, kernel_liteos_a LICENSE. On the LiteOS-A kernel being distributed under the BSD 3-Clause licence. ↩

  18. OpenHarmony, docs LICENSE. On the official documentation repository being provided under Creative Commons Attribution 4.0 International. ↩

  19. OpenAtom Foundation community material, OpenHarmony-XTS认证流程 (secondary source). On community certification-procedure material describing XTS as a three-part structure of ACTS (application compatibility), HATS (hardware abstraction layer compatibility) and DCTS, and on the flow in which the applicant obtains a corporate account, carries out adaptation development and self-testing, and applies with a test report and a PCS self-check sheet attached. The positioning of DCTS conflicts with the official documentation (“the device compatibility test suite to be supported in future”), and the body text makes that discrepancy explicit. ↩

  20. OpenHarmony, device_qemu README. On procedures being provided for QEMU emulation of Arm Virt (LiteOS-A), Arm Virt (Linux), Cortex-M4 (mps2-an386), Cortex-M55 (mps3-an547), RISC-V (riscv32_virt), Xtensa (esp32) and C-SKY (SmartL_E802). ↩

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Frequently Asked Questions

Common questions about the topic of this article.

Is it safe to adopt OpenHarmony as the OS for industrial equipment?
It depends on the conditions. The deciding factor is how you handle the maintenance window: the OpenHarmony community's Release branches have a two-year lifecycle (one year of proactive maintenance plus one year of passive maintenance), and even LTS branches only 3.5 years. If you put the community version straight into a device that runs for ten years, security fixes will stop partway through the product's life. Adopting it presupposes either buying vendor maintenance from a commercial distribution, or having an in-house capability to maintain a branch and handle CVEs yourself. If you cannot put that capability in place, Windows IoT Enterprise LTSC (ten years) or a long-term support contract for commercial embedded Linux fits the device's timescale better.
Which is lighter, OpenHarmony or embedded Linux?
OpenHarmony's floor is lower. OpenHarmony's mini system runs from a minimum of 128 KiB of memory on Arm Cortex-M and 32-bit RISC-V MCUs; the small system needs 1 MiB or more, and the standard system 128 MiB or more. Typical embedded Linux assumes a processor with an MMU and tens of MB of RAM or more, so covering the MCU space within the same OS family is a distinguishing feature of OpenHarmony. Note, however, that the mini system's kernel is LiteOS-M and its execution environment is completely different from the standard system's Linux — so "same OS, therefore the same apps run" does not hold.
Can I port existing Windows equipment software to OpenHarmony?
In practice it is a rewrite. Equipment software written with C#/.NET, Win32, COM or WPF/WinForms has no corresponding runtime on OpenHarmony. You would rewrite it in a different set of technologies: ArkTS plus ArkUI for the UI, C/C++ underneath, and HDF (Hardware Driver Foundation) for drivers. On top of that, vendor SDKs for industrial cameras and motion controllers are often supplied only for Windows (and then Linux), and that is where the real bottleneck for porting lies. If your premise is to make use of existing assets, moving to Windows IoT Enterprise LTSC, or embedded Linux limited to devices for which a Linux SDK is supplied, is more realistic.
Do I need any certification to claim OpenHarmony support?
To call a product "OpenHarmony compatible" you need to pass the OpenAtom Foundation's compatibility assessment (certification). The technical basis for it is OpenHarmony's XTS (X Test Suite) family of test suites. The breakdown, however, is described differently by different sources: as of July 2026 the official documentation says "the currently supported ACTS (application compatibility test suite) and the DCTS (device compatibility test suite) to be supported in future", while community certification-procedure material describes a structure that adds HATS (hardware abstraction layer compatibility) to those. When estimating effort, do not fix DCTS as a mandatory requirement — check with the certification desk which suites are actually required at the time you apply. Certification is not required if you are only using it for internal verification, but it becomes necessary for a product that claims compatibility publicly.
How much Japanese-language support and information is there?
The official documentation comes in two languages, Chinese and English; there is no Japanese version. Community discussion is also mostly in Chinese. Vendors of commercial distributions are largely Chinese companies too, and the number of places where you can get first-line support in Japanese is limited. In effect, then, a practical condition for adoption is having people in-house who can read technical documents in Chinese or English from end to end. This is a clear difference from Windows and the major Linux distributions.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.

Contact
Back to the Blog