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

Whether OpenHarmony belongs on the shortlist of operating systems for your equipment is decided by maintenance, SDKs and development staff before it is decided by feature count. You cannot put a version whose community maintenance ends in two years straight into a device that has to run for ten. If the SDK for the camera you need exists only for Windows, a configuration that uses that camera does not hold together either.

This article compares Windows IoT Enterprise LTSC, embedded Linux (Debian- or Yocto-based) and OpenHarmony for equipment manufacturers. It first puts the candidates on the same footing, then checks, in this order, whether the OS can support the product’s lifetime, whether existing assets can be moved onto it, and whether you can get as far as volume production and shipment. It then summarizes, in a decision table, the conditions under which you may adopt it and the conditions under which you should pass.

The equipment software we normally work on is for Windows, but this is not an article that recommends or dismisses OpenHarmony across the board. The judgment is not “it is a new technology” or “it comes from China”, but whether it fits the device’s timescale, procurement and staffing. For the differences between OpenHarmony, HarmonyOS and HarmonyOS NEXT themselves, see the previous article, “What Is OpenHarmony”.

The technical information and maintenance schedules compared here are as of July 2026. Support periods, supported boards and certification requirements change, so check primary sources and vendors for the version and the products you adopt immediately before you decide.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (34 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

1. The Conclusion First: Keep the Conditions for Adoption Separate from the Reasons to Choose It

OpenHarmony’s strengths are that it reaches down to very small devices and that it handles collaboration between multiple devices through standard mechanisms. Against that, there are clear constraints around existing Windows assets, industrial vendor SDKs and Japanese-language primary information.¹²³

Adoption requires the three conditions below. If any one of them cannot be met, give priority to Windows IoT Enterprise LTSC or commercially supported embedded Linux. Conversely, meeting all three does not by itself settle the decision to adopt OpenHarmony. Check both that OpenHarmony’s strengths match the product’s requirements and that you can develop and maintain that product.

flowchart TB
    accTitle: Separate the conditions for adoption from the benefits to the product
    accDescr: Separate the benefits that fit the product requirements from the conditions for realizing them - maintenance, SDKs and staffing - and decide by matching both.
    requirements["Device market and product requirements"] --> value["Reasons to choose OpenHarmony"]
    requirements --> conditions["Maintenance, SDK and staffing conditions"]
    value --> check["Match both and decide"]
    conditions --> check

Figure 1: Keep the conditions for making it run separate from the reasons for choosing it.

Read According to Your Purpose

The overall comparison is in Section 2.3 and the situation-by-situation recommendations are in Section 7.2. Even for a use case the decision table recommends, the three conditions above cannot be skipped.

2. Put the Candidates on the Same Footing: You Cannot Compare by OS Name Alone

2.1. Where Windows IoT, Debian, Yocto and OpenHarmony Stand

The first thing to align is the difference between using a finished OS product and using a foundation for building an OS for your own product. Mixing the two up means overlooking the work your own company takes on in order to productize it.

Yocto is not a finished OS. It is a framework for combining recipes (definitions of build steps) to build a Linux distribution for your own product. LTSC (Long-Term Servicing Channel) is the Windows servicing model that ships no feature updates and provides security updates over a long period, and it suits uses such as equipment where you want the configuration frozen.

OpenHarmony is not a “buy it and install it” finished product like Windows IoT either. Its position is closer to Yocto: it is an option on the side where you use a foundation to build a configuration for your own product. Unlike Yocto, however, it comes with a UI framework and an application model as one package, so the system extends up into the higher layers as well.

flowchart TB
    accTitle: Finished OS products and foundations for building a product configuration
    accDescr: Procuring a commercial OS product and building a configuration for your own product from a project foundation involve different work.
    os["Runtime platform to put in the device"] --> product["Procure a commercial OS product"]
    os --> project["Choose a development foundation"]
    project --> config["Build the configuration for the product"]
    config --> scope["Decide what you and the vendor own"]

Figure 2: Even within the same OS selection, procuring a finished product and assembling a configuration cover different scopes.

2.2. Read the Memory Floor with the System Type Aligned

OpenHarmony has three system types: mini, small and standard.¹

For equipment with an HMI, the comparison is mainly against the standard system; for sensor nodes and communication modules it is the mini system. The small system sits closer to camera products.

Against the mini system’s 128 KiB minimum, the minimum requirements for Windows 11 IoT Enterprise LTSC on special-purpose devices are 2 GB of memory and 16 GB of storage. Typical embedded Linux also assumes a processor with an MMU and tens of MB of RAM or more. That OpenHarmony can cover the MCU space within the same family is a major difference.¹⁴

That said, it does not mean that standard-system applications run in 128 KiB. The mini system uses LiteOS-M, the small system LiteOS-A and the standard system Linux, so both the kernel and the runtime environment differ. Do not assume “it is the same OpenHarmony, so the same app can be moved across”; choose from the system type the product needs.

flowchart TB
    accTitle: Decide the runtime environment from the system type
    accDescr: Decide the system type the product needs, then check the kernel and the application runtime, and do not judge application compatibility from the memory floor alone.
    need["Functions the product needs"] --> type["Decide the system type"]
    type --> kernel["Check the kernel and runtime"]
    kernel --> app["Build apps that fit that environment"]
    minimum["The minimum memory figure"] -.-> caution["Not a guarantee of app compatibility"]

Figure 3: The 128 KiB floor does not mean standard-system applications run as they are.

2.3. The Overall Comparison: Strengths and Constraints on the Same Axes

With the candidates aligned, here are six evaluation axes side by side. The symbols are a four-level scale: ◎ = fits as is / ○ = fits with conditions / △ = needs care / × = does not fit. This is a table that summarizes the explanations in each section, not a ranking that holds for every device.

OpenHarmony gets a ◎ on two axes: the resource floor and multi-device collaboration. It gets a × on three: existing assets, SDKs and Japanese-language information. That does not make it a “bad OS”; it means you have to pick products whose conditions for adoption match it.

It is worth considering for products aimed at the Chinese market, for products whose central value is device discovery, data synchronization and app migration, for IoT devices with a screen that use ArkUI, and for product lines that want a single family covering everything from MCUs to rich devices. The concrete go/no-go can be checked against the decision table in Section 7.²

flowchart TB
    accTitle: Apply the overall comparison table to the product requirements
    accDescr: Do not decide the OS from the ratings in the comparison table alone, apply them to the product's central value and constraints before deciding.
    table["Grasp strengths and constraints from the overall comparison"] --> req["Apply them to your own product requirements"]
    req --> fit["Match SDKs, maintenance and staffing"]
    fit --> decision["Move on to the situation-based decision in Section 7"]

Figure 4: Do not count the rating symbols; apply them to your own product’s conditions.

3. Settle Maintenance: Check Who Does It, the End Date and the Scope of Fixes

3.1. First, Decide Who Takes On Maintenance for the Product

The point of comparing maintenance is not to rank OpenHarmony’s own quality. The point is that putting the community version straight into a product that runs for ten years and then leaving it alone does not work.

If you adopt it, you either buy vendor maintenance from a commercial distribution or maintain a branch in-house and take on CVE handling yourself. In industrial adoption, the actual procurement channel is the commercial layer, where vendors maintain their own forks and offer them for a fee. Huawei’s June 2026 briefing also states that OpenHarmony has released more than 100 commercial versions.⁹

So the question to ask is not “how many years is OpenHarmony supported?” but “which branch of that distribution do you maintain, until when, and under what SLA?” If maintenance cannot be pinned down, hold the adoption decision even when it runs technically.

flowchart TB
    accTitle: Who bridges community maintenance and the product lifetime
    accDescr: Do not put the community version straight into a long-running product and leave it alone, either the vendor or your own company takes on the maintenance the product lifetime needs.
    life["Maintenance the product lifetime needs"] --> vendor["Contract vendor maintenance"]
    life --> own["Maintain the branch and CVEs in-house"]
    vendor --> terms["Fix the fork, end date and SLA"]
    own --> terms
    terms --> adopt["Settle the premises for the adoption decision"]

Figure 5: Ask not about the number of years for the OS as a whole but about the fork you procure and its maintenance terms.

3.2. Look at Whether the End Date Covers the Device’s Service Period, Not the Total Number of Years

PCs and boards built into equipment are expected to keep running for the same roughly ten-year lifecycle as the equipment itself. Compare each OS’s maintenance on that timescale.

This table is based on each vendor’s official information as of July 2026. Check not only the number of years but whether the time left until the end date in the table covers the device’s service period. Support periods and end dates get revised, so the primary sources to check immediately before an adoption decision are as follows.

• OpenHarmony: Version Lifecycle Management (the lifecycle management policy) and Version Definitions (the branch types and the maintenance schedule table).⁸¹¹
• Windows: the per-product Microsoft Lifecycle page.⁵
• Debian: Debian Wiki LTS.⁶
• Yocto Project: Releases.⁷

flowchart TB
    accTitle: Match the device service period against the OS maintenance end date
    accDescr: Check not only the number of years of OS support but whether the end date of the version you adopt covers the device's service period.
    device["Planned end of device service"] --> compare["Compare the end dates"]
    osend["Maintenance end date of the version adopted"] --> compare
    compare --> enough{"Can it support the service period"}
    enough -->|"Short"| contract["Consider a maintenance contract or another option"]
    enough -->|"Enough"| scope["Check the scope of fixes too"]

Figure 6: Compare that version’s end date with the device’s operating plan, not just the “ten-year support” label.

3.3. Read Proactive and Passive Maintenance Separately

An OpenHarmony Release branch gets one year of proactive maintenance plus one year of passive maintenance, and an LTS branch two years of proactive plus 1.5 years of passive. Do not judge from the totals alone.⁸

Because of that difference, this article takes the view that the period you can rely on in practice should be counted as one year for Release and two years for LTS. The total number of years of community maintenance and the period in which you can expect thorough maintenance are two different things.⁸

flowchart TB
    accTitle: How OpenHarmony maintenance stages change
    accDescr: Proactive maintenance delivers planned tagged versions, passive maintenance limits the scope of fixes and the delivery method, and the branch finally reaches end of maintenance.
    active["Proactive maintenance"] --> passive["Passive maintenance"]
    passive --> eol["End of maintenance"]
    active -.-> regular["Planned tagged versions and fixes"]
    passive -.-> limited["Fixes for critical and higher vulnerabilities and defects"]

Figure 7: Within the same maintenance period, the same scope of fixes does not continue to the end.

3.4. Check What Is Written for the Branch You Adopt

As of July 2026, the reference point for this article, no LTS branch has been cut in recent years. The last LTS listed in the official maintenance schedule table is 3.0-LTS (September 2021); 3.1, 3.2, 4.0 and 4.1 are all Release.¹¹

It is not that there was never an LTS. The release notes index still lists 1.1.0 LTS (April 2021) and its line, but they are all End of Life. The 3.0-LTS line is listed as well, and from 3.1 onward the type is Release.¹²

Furthermore, the maintenance schedule table at that same point in time has no entries for the 5.x or 6.x lines. Do not decide the maintenance period of a version that is not in the table from other versions. You have to work on the premise that the period is undetermined and confirm it for that version.

Windows 11 IoT Enterprise LTSC 2024 has a fixed lifecycle with a confirmed end date of October 10, 2034, Debian publishes its regular support and LTS periods, and the Yocto Project publishes four years of LTS support. With OpenHarmony, by contrast, you have to confirm individually “how far the fork you adopt will be maintained”.⁵⁶⁷

flowchart TB
    accTitle: Do not infer maintenance for a version that is not listed
    accDescr: Check whether the version you adopt appears in the maintenance schedule, and when it does not, confirm it individually instead of applying another version's period.
    branch["Identify the version and branch you adopt"] --> listed{"Is it in the maintenance table"}
    listed -->|"Yes"| dates["Check that version's period and end date"]
    listed -->|"No"| ask["Treat the period as undetermined and confirm individually"]
    ask --> hold["Hold the decision until maintenance is settled"]

Figure 8: Do not assume maintenance for an unlisted version from the LTS label or from another version’s number of years.

4. Find Out Whether You Can Migrate: SDKs, Applications, Drivers and Staff

4.1. Before Comparing Operating Systems, Inventory the SDKs You Depend On

Many SDKs and middleware for industrial cameras, motion controllers, PLC communication, image processing and the like are Windows-first, with a Linux build as a second option if you are lucky. OpenHarmony builds are not something you can expect from the outset.

That is why the first piece of work is this inventory.

List the peripheral devices and middleware the equipment needs, and check the OpenHarmony support status of each.

If a required SDK does not exist and you cannot build what is missing yourself, pass on OpenHarmony for that configuration. If you choose on the features in a comparison table and only then investigate SDKs, the configuration stops working later in the project. When we are consulted about equipment software, we start from building this list too.

flowchart TB
    accTitle: Narrow the OS candidates from the SDKs you need
    accDescr: List the peripheral devices and middleware the equipment needs, and where no OpenHarmony SDK exists, check whether you can build what is missing yourself.
    devices["List peripherals and middleware"] --> sdk{"Are the required SDKs available"}
    sdk -->|"Available"| next["Move on to checking the porting scope"]
    sdk -->|"Not available"| make{"Can you build what is missing"}
    make -->|"Yes"| next
    make -->|"No"| stop["Pass for this device configuration"]

Figure 9: If the SDK is missing and you cannot fill the gap, continuing the feature comparison will not make the device configuration work.

4.2. Windows Equipment Software Cannot Be Brought Over As Is

Lining up the differences between the development stacks shows the impact on existing assets.

Windows equipment software written with C#/.NET, Win32, COM or WPF/WinForms is effectively a rewrite on OpenHarmony. There is no corresponding runtime, so it gets rewritten on a different stack: ArkTS plus ArkUI for the UI and C/C++ underneath.

If making use of existing assets is the premise, moving to Windows IoT Enterprise LTSC is the realistic route. If you choose embedded Linux, parts such as the Windows UI still get rewritten, but C/C++ measurement and control logic ports easily, and it is worth considering if you restrict yourself to devices for which the required Linux SDKs are supplied.

Note that the OpenHarmony driver cell in the table saying HDF does not mean every existing Linux driver has to be rewritten. The difference between using a device through the ordinary Linux interfaces and using it from OpenHarmony’s framework is explained in Section 4.3 below.

flowchart TB
    accTitle: Separate the migration scope for existing Windows assets
    accDescr: Separate the route that keeps existing Windows software as it is from the route that rewrites the UI and runtime for another OS, and on Linux check SDK availability and how far C/C++ logic can be ported.
    assets["Existing Windows equipment software"] --> reuse["Keep using the existing assets as they are"]
    assets --> port["Rewrite for another OS"]
    reuse --> windows["Consider Windows IoT LTSC"]
    port --> scope["Separate UI, runtime and SDKs"]
    scope -.-> logic["On Linux, consider porting C/C++ logic"]

Figure 10: When you change the OS, do not lump the UI and runtime, the measurement and control logic, and the SDKs together.

4.3. Separate the Route That Uses Linux Drivers from Adapting to HDF

OpenHarmony’s HDF (Hardware Driver Foundation) is a unified driver foundation that is platform-independent and kernel-independent and applies to all system types.²

The standard system’s kernel, on the other hand, is Linux. It is therefore entirely possible to build in an existing Linux kernel driver and use it through the ordinary Linux interfaces such as V4L2 or input devices.

If a Linux BSP exists, there is no need to estimate “rewriting every driver in HDF”. First decide which devices have to be exposed to OpenHarmony’s framework, and put that scope into the effort estimate.

Also, even before you procure a board, you can start checking the structure and the boot flow in QEMU. That entry point, and the order of work once you adopt it, are summarized in Section 8.

flowchart TB
    accTitle: Reusing Linux drivers and adapting to the framework
    accDescr: When using existing Linux drivers on the standard system, separate the extra work for using them through the ordinary Linux interfaces from exposing them to the OpenHarmony framework via HDI.
    driver["Linux driver on the standard system"] --> normal["Ordinary Linux interfaces"]
    driver --> hdi["Use via HDI"]
    normal --> direct["Configuration that builds in the existing driver"]
    hdi --> adapt["Adapt to the OpenHarmony side"]
    adapt --> framework["System services and frameworks"]

Figure 11: Rather than rewriting every driver, estimate the scope you have to expose to OpenHarmony.

4.4. Prepare the Development Environment, and Staff Who Can Read the Documentation

The entry points to device development are the GUI DevEco Device Tool and the CLI. The DevEco Device Tool setup is a combined one: code editing, debugging and flashing on Windows, compiling on Ubuntu. Source is fetched with the repo tool, and mirrors on gitcode.com, gitee.com and GitHub are documented.¹³¹⁴

The official documentation comes in two languages, Chinese and English; there is no Japanese version. Community discussion and the vendors of commercial distributions are also centered on China, and the number of desks where you can get first-line support in Japanese is limited. Having people who can read technical documents in Chinese or English end to end is not a supporting condition that matters once development has started; it is in practice a condition for adoption.³

flowchart TB
    accTitle: Source acquisition and the device development environment
    accDescr: Device development from source fetched with repo has two entry points, the CLI and DevEco Device Tool, and the latter combines editing, debugging and flashing on Windows with compilation on Ubuntu.
    source["Fetch the source with repo"] --> cli["Develop with the CLI"]
    source --> ide["DevEco Device Tool"]
    ide --> win["Edit, debug and flash on Windows"]
    ide --> ubuntu["Compile on Ubuntu"]

Figure 12: On top of preparing the tools, you need a team that can keep reading technical documents in Chinese or English.

5. Confirm You Can Procure It: Supported Boards and Volume Production Conditions

5.1. The Supported Boards Include NXP and ST SoCs

The community list of supported development boards this article refers to has 22 entries. Here are the ones likely to be relevant to equipment.¹⁵

The SoC vendors are not only Chinese ones. The NXP i.MX8M Mini and ST’s STM32 series are there too, so a Japanese equipment manufacturer may be able to evaluate it on an SoC family it already uses.

This table, however, shows the intended uses given in the documentation. It does not guarantee ten-year supply, distribution within Japan, or official OpenHarmony support for production boards.

flowchart TB
    accTitle: Separate the supported list from volume production procurement conditions
    accDescr: The supported development board list is an entry point for technical evaluation and does not guarantee domestic distribution, years of supply, or official support on production boards.
    list["Supported development board list"] --> candidate["Candidates for technical evaluation"]
    candidate --> sale["Check actual sales and domestic distribution"]
    sale --> supply["Check production lots and years of supply"]
    list -.-> note["Not a guarantee of long-term supply"]

Figure 13: A name on the list and availability throughout the product’s life are two separate checks.

5.2. Check Procurement Conditions Before You Order an Evaluation Unit

The list is centered on evaluation boards, many of them aimed at the Chinese market. They are not necessarily available from a Japanese distributor as a matter of course. Before ordering an evaluation unit, ask about these three points.

1. Whether the board vendor’s sales page or a cross-border e-commerce channel carries it.
2. Whether there is a sales distributor in Japan.
3. What the minimum lot for volume production and the years of supply are.

Even if a board is on the supported list, you cannot make progress with technical validation on real hardware unless you can procure it. Along with the OS maintenance window, check the board’s supply conditions.

If you are putting it on your own board, porting is work for you or for a distributor. That is a different scope from procuring a license from an OEM distributor for Windows IoT and using vendor-supplied drivers. If the SoC is already fixed, it is sometimes more practical to estimate the porting effort for that SoC than to look for an evaluation board.

flowchart TB
    accTitle: Separate preparation for evaluation boards and for your own board
    accDescr: With an evaluation board, investigate availability and volume production conditions, and with your own board or a fixed SoC, estimate who does the porting and how much effort it takes.
    hardware["Hardware used in the product"] --> board["Consider an evaluation board"]
    hardware --> own["Own board or a fixed SoC"]
    board --> procure["Check availability and production conditions"]
    own --> port["Check porting ownership and effort"]
    procure --> plan["Plan it together with OS maintenance"]
    port --> plan

Figure 14: Include not only buying an evaluation unit but the work of bringing it up on production hardware in the procurement plan.

6. Check the Conditions for Shipping: Licenses, Certification and the Ecosystem

6.1. Check the LICENSE of Every Component You Include, One by One

OpenHarmony is not a single license. List the repositories you build into the product and check them by scope.

Lumping it together as “OpenHarmony is Apache 2.0, so it is fine” means overlooking the GPL obligations of the Linux kernel part of the standard system. The practical difference from Windows IoT, where you procure the OS under a commercial license, also lies in this per-component license check.

flowchart TB
    accTitle: Check licenses from the scope you include in the product
    accDescr: Do not treat OpenHarmony as a single license, list the repositories built into the product and check each LICENSE and what has to be done at distribution.
    product["Configuration built into the product"] --> repos["List the target repositories"]
    repos --> licenses["Check each LICENSE"]
    licenses --> delivery["Organize what distribution requires"]
    delivery --> legal["Confirm with legal and IP"]

Figure 15: Do not decide on Apache 2.0 alone; check each component you actually build in.

6.2. Separate Modifying the Kernel from Distributing the Equipment to a Customer

The obligation under GPLv2 arises not at the moment you modify the code but at the moment of distribution. If you only modify the kernel and run it on an in-house test machine, no obligation to provide source arises.

When you deliver the equipment to a customer, an obligation arises to provide the recipient with the source code corresponding to the distributed binaries, including your changes. For an equipment manufacturer, delivery is distribution, so volume production and delivery require compliance. Keep the fact that there is no publication obligation from the in-house prototype stage separate from the fact that compliance is required when delivering to a customer. Confirm the specific compliance method with your own legal and IP departments.

flowchart TB
    accTitle: Distinguish in-house kernel modification from distribution to a customer
    accDescr: When considering the GPLv2 obligation to provide source, separate the case that stays within in-house use from distributing equipment containing kernel binaries to a customer.
    kernel["Configuration containing the Linux kernel"] --> internal["Stays within in-house testing and use"]
    kernel --> distribute["Equipment distributed to a customer"]
    internal --> no["In-house changes alone create no obligation"]
    distribute --> corresponding["Provide the corresponding source"]

Figure 16: Check the obligation by separating the moment of modification from the moment of delivering the equipment to a customer.

6.3. Separate Making It Run from Calling It OpenHarmony Compatible

Separately from license compliance, check the procedure needed to state compatibility publicly.

6.3.1. In-House Validation and a Product’s Compatibility Claim

If you are only using it for in-house validation or in a one-off machine, compatibility certification is not needed. If, on the other hand, you want to claim “OpenHarmony compatible” publicly as a product, or to be treated as part of the ecosystem, estimate the effort on the premise of passing the OpenAtom Foundation’s compatibility assessment.

The technical basis is XTS (X Test Suite), the family of compatibility test suites. The flow is that the applicant carries out the conformance development and self-testing and applies with a test report attached.²¹⁹

flowchart TB
    accTitle: Certification preparation for a product that claims compatibility
    accDescr: For a product that publicly claims OpenHarmony compatibility, check the required tests, prepare the conformance development, self-testing and report, and apply for the compatibility assessment.
    claim["Claim OpenHarmony compatibility"] --> required["Check the test requirements at application time"]
    required --> test["Conformance development and self-testing"]
    test --> report["Prepare the test report"]
    report --> apply["Apply for the compatibility assessment"]

Figure 17: Having confirmed that it works in-house is not the same as being able to state that the product is compatible.

6.3.2. Check ACTS, HATS and DCTS Against the Differences Between Sources

As of July 2026, the reference point for this article, sources differ on the breakdown of XTS.

In the official material DCTS is treated as a future offering, while the community material describes it as a component. Do not fix DCTS as mandatory; check with the certification desk which suites are actually required at the time you apply. This discrepancy in the descriptions, and the absence of Japanese-language primary sources, also become a communication cost when you adopt it.²¹⁹

6.4. Check the Ecosystem the Customer Wants, and the Procurement Policy

If what the customer wants is AppGallery distribution or interoperation with HarmonyOS apps, OpenHarmony cannot meet the requirement. AppGallery, HMS and the HarmonyOS SDK are not part of OpenHarmony, and compatibility with HarmonyOS apps is not guaranteed. What is needed is a HarmonyOS-compatible product and the HarmonyOS SDK, and that is a different matter from “OpenHarmony compatible” certification.

flowchart TB
    accTitle: Separate OpenHarmony compatibility from HarmonyOS requirements
    accDescr: Work out whether what the customer wants is OpenHarmony compatibility or AppGallery distribution and HarmonyOS app interoperation, and treat the latter as a requirement for HarmonyOS-compatible products and the SDK.
    customer["Requirements the customer wants"] --> oh["OpenHarmony compatibility"]
    customer --> harmony["AppGallery and HarmonyOS interoperation"]
    oh --> cert["OpenHarmony compatibility assessment"]
    harmony --> commercial["HarmonyOS-compatible products and SDK"]

Figure 18: OpenHarmony compatibility certification cannot substitute for HarmonyOS distribution and interoperation requirements.

For the procurement policy too, separate constraints on the governing body from constraints on where the code comes from. For the former, the Eclipse Oniro family under a European foundation’s governance is a candidate, but as of July 2026, this article’s reference point, it is Incubating, and its community is nowhere near the size of OpenHarmony proper. If the latter means “must contain no code of Chinese origin”, Oniro is also built on top of OpenHarmony’s foundation layer, so the constraint is not resolved.

flowchart TB
    accTitle: Constraints on the governing body and constraints on the origin of the code
    accDescr: Separate procurement policies that target the governing body from those that target where the code comes from, and confirm that with Oniro under European governance the condition of OpenHarmony-derived code does not change.
    policy["Constraint in the procurement policy"] --> governance["Governing body and governance"]
    policy --> origin["Origin of the code"]
    governance --> oniro["Consider the Oniro family with conditions"]
    origin --> remain["Oniro does not resolve the constraint either"]
    oniro -.-> maturity["Check its maturity as of July 2026 too"]

Figure 19: Do not confuse changing the governing body with changing where the code comes from.

7. Decide: Match the Product’s Requirements Against the Conditions You Can Take On

7.1. Judge in Order, Starting from Market and Product Requirements

The order for checking the premises is market and product requirements first, technical evaluation second. On top of that, check SDKs, maintenance, and staff who can read technical documents. Even if you can build it technically, you cannot decide to adopt it for equipment while maintenance is not pinned down.

flowchart TB
    accTitle: The main decisions for adopting OpenHarmony as an equipment OS
    accDescr: After checking the market requirements or the value of multi-device collaboration, check SDKs, maintenance and staff who can read technical documents, and consider Windows IoT or embedded Linux if the conditions cannot be met.
    S["Choose the OS to put in the device"] --> Q1["Aimed at the Chinese market or compatibility mandated"]
    Q1 -->|"Yes"| Q3["SDKs available or buildable in-house"]
    Q1 -->|"No"| Q2["Is multi-device collaboration core to product value"]
    Q2 -->|"Yes"| Q3
    Q2 -->|"No"| OTH["Windows IoT LTSC / Linux"]
    Q3 -->|"Available / buildable in-house"| Q4["Can maintenance be pinned down"]
    Q3 -->|"Not available"| NG["Pass on OpenHarmony"]
    Q4 -->|"Yes"| Q5["Is there anyone who reads Chinese or English"]
    Q4 -->|"No"| NG
    Q5 -->|"Yes"| OH["Evaluate OpenHarmony seriously"]
    Q5 -->|"No"| NG
    NG --> OTH
    OH -.-> vendor["Procure through a commercial distribution"]
    OTH -.-> assets["Choose by existing assets and SDK support"]

Figure 20: Starting from market and product requirements, check the SDK, maintenance and staffing conditions in order.

In practice, the conditions most often fail at Q3 (vendor SDKs) and Q4 (the maintenance contract) — that is the main point of this article. This diagram shows the main decision flow. Individual conditions such as MCU use cases, unifying a product line and procurement policy are judged together with the table below.

7.2. The Situation-by-Situation Decision Table

The support years in the table are the lifecycles of each version. Whether they fit the device’s operating period has to be checked including the end dates in Section 3. Also, a use case where the table recommends OpenHarmony does not make the SDK, maintenance and staffing conditions unnecessary.

8. Once It Is Still a Candidate, Make It Concrete in Seven Steps

If it survives the decision table, move on to the seven pieces of work below. Running under QEMU or on real hardware is not the same as being adoptable as a product. Do not finalize adoption on the strength of a successful technical validation alone while the maintenance terms are still open.

1. Inventory the peripheral devices and middleware. Check whether cameras, I/O, communication, motion, image processing and so on can be supported on OpenHarmony. If you get stuck here, there is no point in advancing the other steps.
2. Fix the system type. Decide on mini, small or standard. The kernel (LiteOS-M / LiteOS-A / Linux) and the way applications are written change with it.
3. Check the structure in QEMU. Before buying real hardware, you can check the build and boot flow on device_qemu environments such as Arm Virt (LiteOS-A / Linux), Cortex-M4, Cortex-M55 and RISC-V.²⁰
4. Pin the maintenance branch and secure build reproducibility. Pin the repo manifest (specifying a tag is the reliable way), keep an in-house mirror, and get to a state where you can regenerate the same binaries five years from now. That the upstream hosting is centered on gitcode.com is another reason to keep a mirror from a business continuity standpoint.¹⁴
5. Inventory the licenses. List the repositories you build in and organize the Apache 2.0 / BSD / GPL obligations.
6. Negotiate the maintenance contract. With the vendor of the commercial distribution, pin down “which branch, until when, under what SLA”. If it cannot be settled, hold the adoption decision.
7. Decide whether compatibility assessment is needed. If you are going to claim OpenHarmony compatibility publicly, build the effort for XTS conformance development, self-testing and application into the plan from the start.

flowchart TB
    accTitle: Connect technical validation through to the conditions for product adoption
    accDescr: Fix the peripherals and the system type and check the structure in QEMU, then settle build reproducibility, licenses, the maintenance contract and whether certification is needed before the adoption decision.
    inventory["Inventory devices and SDKs"] --> type["Fix the system type"]
    type --> qemu["Check structure and boot in QEMU"]
    qemu --> reproduce["Pin the branch and build reproducibility"]
    reproduce --> conditions["Check licenses, maintenance and certification"]
    conditions --> decision["Adoption decision as a product"]

Figure 21: Do not stop at validating that it runs; make future rebuilds and post-shipment maintenance concrete too.

8.1. Summary: Choose the OS That Fits the Device’s Timescale, Procurement and Staffing

OpenHarmony covers everything from a 128 KiB MCU to rich devices with 128 MiB and more in a single family, and it has DSoftBus-based device collaboration as standard, which is a technically coherent design. The supported boards intended for industrial use include NXP and ST SoCs.¹²¹⁵

At the same time, for equipment that runs for ten years, community maintenance of two years for Release and 3.5 years for LTS is clearly not enough. Including the fact that no LTS has been cut since 3.0-LTS as of this article’s reference point, it is not an option to adopt without either maintenance from a commercial distribution or an in-house capability that goes as far as CVE handling.⁸¹¹¹²

What a Japanese equipment manufacturer has to check is the SDKs for the devices it uses, staff who can read the technical documents, and maintenance that supports the product’s lifetime. Without those, Windows IoT Enterprise LTSC or commercially supported embedded Linux is the realistic choice. Conversely, if Chinese market requirements, device collaboration, or unifying everything from MCUs to rich devices in one family ties directly to product value, OpenHarmony is worth evaluating seriously.

OS selection is not a judgment about “which one is better” but about which one fits the device’s timescale, procurement and staffing. The selection criteria on the Windows side are laid out in “Which Windows Should You Put on an Industrial PC?”.

Related Articles

• What Is OpenHarmony? — Sorting Out How It Differs from HarmonyOS and HarmonyOS NEXT
• Which Windows Should You Put on an Industrial PC? — A Practical Guide to Windows IoT Enterprise / LTSC
• Practical Options After Windows 10 End of Support
• A Practical Guide to Windows Kiosk Mode (Assigned Access)

Related Consulting Areas

KomuraSoft LLC handles support for selecting the runtime platform that goes into equipment, triage of whether existing Windows equipment software can be migrated, and reviews of configurations designed for long-running operation. You can consult us from the stage where “a new OS has come up as a candidate, but we have nothing in-house to compare it against”.

• Technical Consulting and Design Review
• Soft Real-Time Windows Application Development
• Windows Application Development
• Contact Us

References

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 the maintenance window is handled: an OpenHarmony community Release branch has a two-year lifecycle (one year of proactive maintenance plus one year of passive maintenance), and even an LTS branch has only 3.5 years. If you put the community version straight into a device that runs for ten years, security fixes 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 MCUs such as Arm Cortex-M and 32-bit RISC-V; 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 on a different stack: 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 desks 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.