Является ли OpenHarmony жизнеспособной ОС для промышленного оборудования? — сравнение с Windows IoT и встраиваемым Linux

Попадает ли OpenHarmony в список кандидатов на роль операционной системы для вашего оборудования, решают сопровождение, SDK и инженеры — а не количество функций. Нельзя поставить версию, у которой сопровождение сообществом заканчивается через два года, прямо в устройство, которому предстоит работать десять лет. Если SDK нужной вам камеры существует только под Windows, конфигурация с этой камерой тоже не сложится.

Эта статья — сравнение Windows IoT Enterprise LTSC, встраиваемого Linux (на базе Debian или Yocto) и OpenHarmony для производителей оборудования. Сначала мы приводим кандидатов к общему виду, затем в таком порядке проверяем, выдержит ли ОС срок службы продукта, можно ли перенести существующие наработки и можно ли дойти до серийного производства и отгрузки. После этого условия, при которых её можно принять, и условия, при которых следует отказаться, сводятся в таблицу решений.

Мы обычно имеем дело с ПО для Windows-устройств, но эта статья не рекомендует и не отвергает OpenHarmony огульно. Суждение строится не на «это новая технология» или «это из Китая», а на том, подходит ли она временному горизонту устройства, закупке и кадрам. О различиях между самими OpenHarmony, HarmonyOS и HarmonyOS NEXT читайте в предыдущей статье «Что такое OpenHarmony».

Сравниваемые здесь технические сведения и графики сопровождения приведены по состоянию на июль 2026 года. Сроки поддержки, поддерживаемые платы и требования к сертификации меняются, поэтому по версии и изделиям, которые вы принимаете, сверяйтесь с первоисточниками и поставщиками непосредственно перед решением.

1. Сначала вывод: условия внедрения и причины выбрать эту ОС рассматриваем раздельно

Сильные стороны OpenHarmony — способность работать на очень маленьких устройствах и поддержка взаимодействия нескольких устройств штатными механизмами. При этом есть явные ограничения: существующие наработки для Windows, промышленные вендорские SDK и первичная информация на японском языке.¹²³

Для внедрения нужны три условия ниже. Если хотя бы одно из них выполнить нельзя, приоритет отдаётся Windows IoT Enterprise LTSC или встраиваемому Linux с коммерческой поддержкой. И наоборот: выполнение всех трёх условий само по себе ещё не решает вопрос о внедрении OpenHarmony. Проверять нужно и соответствие сильных сторон OpenHarmony требованиям продукта, и способность этот продукт разрабатывать и сопровождать.

flowchart TB
    accTitle: Условия внедрения и выгоды для продукта рассматриваем раздельно
    accDescr: Разделяем выгоды, соответствующие требованиям продукта, и условия их реализации — сопровождение, SDK и кадры — и принимаем решение, сопоставив и то и другое.
    requirements["Рынок и требования к продукту"] --> value["Причины выбрать OpenHarmony"]
    requirements --> conditions["Условия по сопровождению, SDK и кадрам"]
    value --> check["Сопоставляем и принимаем решение"]
    conditions --> check

Рисунок 1: Условия, при которых система работает, и причины её выбрать рассматриваем отдельно.

Как читать в зависимости от задачи

Общее сравнение — в разделе 2.3, рекомендации по ситуациям — в разделе 7.2. Даже для сценария, который таблица решений рекомендует, три условия выше не отменяются.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 34, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Приводим кандидатов к общему виду: по одному названию ОС их не сравнить

2.1. Место Windows IoT, Debian, Yocto и OpenHarmony

Первое, что нужно уравнять, — разницу между использованием готового продукта-ОС и использованием основы, из которой строится ОС для собственного продукта. Если их смешать, можно не заметить работу, которую ваша компания берёт на себя при выводе продукта на рынок.

Yocto — не готовая ОС. Это фреймворк, в котором из рецептов (описаний шагов сборки) собирается дистрибутив Linux для вашего продукта. LTSC (Long-Term Servicing Channel, канал долгосрочного обслуживания) — модель поставки Windows, при которой функциональные обновления не выпускаются, а обновления безопасности предоставляются долго; она подходит для задач вроде оборудования, где конфигурацию нужно зафиксировать.

OpenHarmony тоже не готовый продукт, который «купил и поставил», как Windows IoT. По своему месту он ближе к Yocto: это вариант из той категории, где из основы собирают конфигурацию для собственного продукта. Но, в отличие от Yocto, здесь в один комплект входят и UI-фреймворк, и модель приложений, поэтому система охватывает и верхние слои.

flowchart TB
    accTitle: Готовые продукты-ОС и основы для сборки конфигурации продукта
    accDescr: Закупка коммерческого продукта-ОС и сборка конфигурации для собственного продукта из основы проекта — это разные объёмы работ.
    os["Среда исполнения для устройства"] --> product["Закупить коммерческий продукт-ОС"]
    os --> project["Выбрать основу для разработки"]
    project --> config["Собрать конфигурацию для продукта"]
    config --> scope["Определить зоны ответственности компании и поставщика"]

Рисунок 2: Даже внутри одного и того же выбора ОС закупка готового продукта и сборка конфигурации охватывают разные объёмы работ.

2.2. Нижнюю границу памяти читаем при одинаковом типе системы

В OpenHarmony три типа систем: Mini System, Small System и Standard System.¹

Для оборудования с HMI сравнение идёт в основном со Standard System, для сенсорных узлов и модулей связи — с Mini System. Small System ближе к камерным продуктам.

Против минимальных 128 KiB у Mini System минимальные требования Windows 11 IoT Enterprise LTSC для устройств специального назначения — 2 ГБ памяти и 16 ГБ накопителя. Обычный встраиваемый Linux тоже предполагает процессор с MMU и десятки мегабайт ОЗУ и больше. То, что OpenHarmony покрывает и область MCU внутри одного семейства, — существенное отличие.¹⁴

Но это не значит, что приложения Standard System работают в 128 KiB. В Mini System используется LiteOS-M, в Small System — LiteOS-A, в Standard System — Linux, то есть различаются и ядро, и среда исполнения. Не считайте, что «это же одна и та же OpenHarmony, значит, приложение можно перенести»; выбирайте исходя из того типа системы, который нужен продукту.

flowchart TB
    accTitle: Определяем среду исполнения по типу системы
    accDescr: Сначала определяем нужный продукту тип системы, затем проверяем ядро и среду исполнения приложений и не судим о совместимости приложений по одной лишь нижней границе памяти.
    need["Функции, нужные продукту"] --> type["Определяем тип системы"]
    type --> kernel["Проверяем ядро и среду исполнения"]
    kernel --> app["Создаём приложения под эту среду"]
    minimum["Значение минимальной памяти"] -.-> caution["Не гарантия совместимости приложений"]

Рисунок 3: Нижняя граница в 128 KiB не означает, что приложения Standard System заработают как есть.

2.3. Общее сравнение: сильные стороны и ограничения по одним и тем же осям

Когда кандидаты приведены к общему виду, вот шесть осей оценки рядом. Символы — четырёхуровневая шкала: ◎ = подходит как есть / ○ = подходит с условиями / △ = требует внимания / × = не подходит. Это таблица, обобщающая объяснения из разделов, а не рейтинг, справедливый для любого устройства.

OpenHarmony получает ◎ по двум осям: нижняя граница ресурсов и взаимодействие устройств. По трём осям у неё ×: существующие наработки, SDK и информация на японском. Это не делает её «плохой ОС»; это значит, что нужно выбирать продукты, условия внедрения которых с ней совпадают.

Её стоит рассматривать для продуктов, ориентированных на китайский рынок; для продуктов, центральная ценность которых — обнаружение устройств, синхронизация данных и перенос приложений; для IoT-устройств с экраном на ArkUI; для продуктовых линеек, которые хотят одним семейством закрыть всё, от MCU до мощных устройств. Конкретное «да/нет» проверяется по таблице решений в разделе 7.²

flowchart TB
    accTitle: Применяем таблицу общего сравнения к требованиям продукта
    accDescr: Не решайте выбор ОС по одним лишь оценкам в таблице сравнения, примените их к центральной ценности и ограничениям продукта, прежде чем решать.
    table["Оценить сильные стороны и ограничения по общему сравнению"] --> req["Применить их к требованиям собственного продукта"]
    req --> fit["Сопоставить SDK, сопровождение и кадры"]
    fit --> decision["Перейти к решению по ситуациям в разделе 7"]

Рисунок 4: Считайте не символы оценки, а применяйте их к условиям собственного продукта.

3. Решаем вопрос сопровождения: проверяем, кто его ведёт, дату окончания и объём исправлений

3.1. Сначала определяем, кто берёт на себя сопровождение продукта

Смысл сравнения сопровождения не в том, чтобы выстроить рейтинг качества самой OpenHarmony. Смысл в том, что поставить версию из сообщества прямо в продукт, который работает десять лет, и затем оставить её без внимания — не работает.

Если вы её внедряете, вы либо покупаете вендорское сопровождение коммерческого дистрибутива, либо ведёте ветку внутри компании и сами берёте на себя обработку CVE. В промышленном внедрении реальный канал закупки — коммерческий уровень, где поставщики сопровождают собственные форки и предлагают их за плату. В докладе Huawei в июне 2026 года также сказано, что OpenHarmony выпустила более 100 коммерческих версий.⁹

Поэтому спрашивать нужно не «сколько лет поддерживается OpenHarmony», а «какую ветку этого дистрибутива вы сопровождаете, до какого срока и по какому SLA?» Если сопровождение не удаётся зафиксировать, решение о внедрении откладывается, даже когда технически всё работает.

flowchart TB
    accTitle: Кто связывает сопровождение сообщества и срок службы продукта
    accDescr: Не ставьте версию из сообщества прямо в долго работающий продукт и не оставляйте её без внимания: сопровождение, нужное сроку службы продукта, берёт на себя либо поставщик, либо ваша компания.
    life["Сопровождение, нужное сроку службы продукта"] --> vendor["Заключить договор на вендорское сопровождение"]
    life --> own["Своими силами вести ветку и обрабатывать CVE"]
    vendor --> terms["Зафиксировать форк, дату окончания и SLA"]
    own --> terms
    terms --> adopt["Закрепить предпосылки решения о внедрении"]

Рисунок 5: Спрашивать нужно не о числе лет для ОС в целом, а о закупаемом форке и условиях его сопровождения.

3.2. Смотрим, покрывает ли дата окончания срок службы устройства, а не общее число лет

От компьютеров и плат, встраиваемых в оборудование, ожидают работы в том же примерно десятилетнем жизненном цикле, что и само оборудование. Сравнивайте сопровождение каждой ОС в этом масштабе времени.

Таблица основана на официальной информации каждого поставщика по состоянию на июль 2026 года. Проверяйте не только число лет, но и то, покрывает ли срок до указанной в таблице даты окончания период эксплуатации устройства. Сроки поддержки и даты окончания пересматриваются, поэтому первоисточники, которые нужно проверить непосредственно перед решением о внедрении, такие.

• OpenHarmony: Version Lifecycle Management (политика управления жизненным циклом) и Version Definitions (типы веток и таблица графика сопровождения).⁸¹¹
• Windows: страница Microsoft Lifecycle по каждому продукту.⁵
• Debian: Debian Wiki LTS.⁶
• Yocto Project: Releases.⁷

flowchart TB
    accTitle: Сопоставляем период эксплуатации устройства с датой окончания сопровождения ОС
    accDescr: Проверяйте не только число лет поддержки ОС, но и то, покрывает ли дата окончания выбранной версии период эксплуатации устройства.
    device["Планируемое окончание эксплуатации устройства"] --> compare["Сопоставить даты окончания"]
    osend["Дата окончания сопровождения выбранной версии"] --> compare
    compare --> enough{"Хватает ли на период эксплуатации"}
    enough -->|"Не хватает"| contract["Рассмотреть договор на сопровождение или другой вариант"]
    enough -->|"Хватает"| scope["Проверить ещё и объём исправлений"]

Рисунок 6: Сравнивайте не только название «десять лет поддержки», а дату окончания этой версии с планом эксплуатации устройства.

3.3. Активное и пассивное сопровождение читаем раздельно

Ветка OpenHarmony Release получает один год активного сопровождения плюс один год пассивного, ветка LTS — два года активного плюс 1,5 года пассивного. Не судите только по суммарным числам.⁸

Из-за этой разницы в статье принят взгляд, что период, на который можно реально полагаться, следует считать как один год для Release и два года для LTS. Общее число лет сопровождения сообществом и период, в котором можно ожидать полноценного сопровождения, — разные вещи.⁸

flowchart TB
    accTitle: Как меняются этапы сопровождения OpenHarmony
    accDescr: При активном сопровождении поставляются плановые версии с тегами, при пассивном объём исправлений и способ их предоставления ограничиваются, а затем ветка доходит до окончания сопровождения.
    active["Активное сопровождение"] --> passive["Пассивное сопровождение"]
    passive --> eol["Окончание сопровождения"]
    active -.-> regular["Плановые версии с тегами и исправления"]
    passive -.-> limited["Исправления уязвимостей и дефектов уровня «критический» и выше"]

Рисунок 7: Даже внутри одного срока сопровождения тот же объём исправлений не сохраняется до конца.

3.4. Проверяем, что записано для выбранной вами ветки

По состоянию на июль 2026 года, то есть на принятую в статье точку отсчёта, в последние годы ветки LTS не отрезались. Последняя LTS в официальной таблице графика сопровождения — 3.0-LTS (сентябрь 2021 года); 3.1, 3.2, 4.0 и 4.1 — все Release.¹¹

LTS не было не всегда. В указателе release notes по-прежнему перечислены 1.1.0 LTS (апрель 2021 года) и её линия, но все они помечены End of Life. Линия 3.0-LTS тоже указана, а начиная с 3.1 тип — Release.¹²

Кроме того, в таблице графика сопровождения на тот же момент нет записей по линиям 5.x и 6.x. Не определяйте срок сопровождения версии, которой нет в таблице, по другим версиям. Нужно исходить из того, что срок не определён, и уточнять его для этой версии.

У Windows 11 IoT Enterprise LTSC 2024 фиксированный жизненный цикл с подтверждённой датой окончания 10 октября 2034 года, Debian публикует сроки обычной поддержки и LTS, а Yocto Project публикует четырёхлетнюю поддержку LTS. В OpenHarmony же приходится отдельно уточнять, «до какого срока будет сопровождаться выбранный вами форк».⁵⁶⁷

flowchart TB
    accTitle: Не выводим сопровождение версии, которой нет в списке
    accDescr: Проверьте, есть ли выбранная версия в графике сопровождения, и если её там нет, уточняйте индивидуально, а не подставляйте срок другой версии.
    branch["Определить выбранную версию и ветку"] --> listed{"Есть ли она в таблице сопровождения"}
    listed -->|"Да"| dates["Проверить срок и дату окончания этой версии"]
    listed -->|"Нет"| ask["Считать срок неопределённым и уточнять индивидуально"]
    ask --> hold["Отложить решение, пока сопровождение не зафиксировано"]

Рисунок 8: Не выводите сопровождение версии, которой нет в списке, из названия LTS или из числа лет другой версии.

4. Выясняем, можно ли мигрировать: SDK, приложения, драйверы и кадры

4.1. До сравнения операционных систем инвентаризируем SDK, от которых зависим

Многие SDK и промежуточное ПО для промышленных камер, контроллеров движения, связи с ПЛК, обработки изображений и подобного выпускаются в первую очередь под Windows, а сборка под Linux появляется как второй вариант, если повезёт. Сборок под OpenHarmony изначально ожидать не стоит.

Поэтому первая работа — вот эта инвентаризация.

Перечислите периферийные устройства и промежуточное ПО, которые нужны оборудованию, и проверьте состояние поддержки OpenHarmony для каждого.

Если нужного SDK нет, а закрыть недостающее своими силами невозможно, от OpenHarmony в такой конфигурации отказываются. Если выбрать по функциям из таблицы сравнения и только потом заняться SDK, конфигурация перестанет складываться на более поздних этапах проекта. Когда к нам обращаются по поводу ПО для устройств, мы тоже начинаем с составления этого списка.

flowchart TB
    accTitle: Сужаем список кандидатов-ОС по нужным SDK
    accDescr: Перечислите периферийные устройства и промежуточное ПО, нужные оборудованию, и там, где SDK для OpenHarmony нет, проверьте, можете ли вы закрыть недостающее своими силами.
    devices["Перечислить периферию и промежуточное ПО"] --> sdk{"Есть ли нужные SDK"}
    sdk -->|"Есть"| next["Перейти к проверке объёма портирования"]
    sdk -->|"Нет"| make{"Можете ли закрыть недостающее сами"}
    make -->|"Да"| next
    make -->|"Нет"| stop["Отказаться от OpenHarmony для этой конфигурации устройства"]

Рисунок 9: Если SDK нет и закрыть пробел нечем, продолжение сравнения функций не сделает конфигурацию устройства работоспособной.

4.2. ПО для Windows-устройств нельзя перенести как есть

Если выстроить различия между стеками разработки, становится видно влияние на существующие наработки.

ПО для Windows-устройств, написанное на C#/.NET, Win32, COM или WPF/WinForms, на OpenHarmony фактически переписывается заново. Соответствующей среды исполнения нет, поэтому его переписывают на другом стеке: интерфейс — на ArkTS плюс ArkUI, нижний слой — на C/C++.

Если исходная предпосылка — использовать существующие наработки, реалистичный путь — переход на Windows IoT Enterprise LTSC. Если выбирать встраиваемый Linux, такие части, как интерфейс Windows, всё равно переписываются, но логика измерений и управления на C/C++ переносится легко, и вариант стоит рассматривать, если ограничиться устройствами, для которых поставляются нужные SDK под Linux.

Заметьте: то, что в столбце драйверов у OpenHarmony указан HDF, не означает, что все существующие драйверы Linux придётся переписывать. Разница между использованием устройства через обычные интерфейсы Linux и использованием его из фреймворка OpenHarmony объясняется в разделе 4.3 ниже.

flowchart TB
    accTitle: Разграничиваем объём миграции существующих наработок Windows
    accDescr: Отделите путь, на котором существующее ПО Windows остаётся как есть, от пути, на котором интерфейс и среда исполнения переписываются под другую ОС, а на Linux проверьте наличие SDK и то, какую часть логики C/C++ можно перенести.
    assets["Существующее ПО для Windows-устройств"] --> reuse["Использовать существующие наработки как есть"]
    assets --> port["Переписать под другую ОС"]
    reuse --> windows["Рассмотреть Windows IoT LTSC"]
    port --> scope["Разграничить интерфейс, среду исполнения и SDK"]
    scope -.-> logic["На Linux рассмотреть перенос логики C/C++"]

Рисунок 10: Меняя ОС, не сваливайте в одну кучу интерфейс со средой исполнения, логику измерений и управления и SDK.

4.3. Разделяем путь через драйверы Linux и адаптацию под HDF

HDF (Hardware Driver Foundation) в OpenHarmony — единая основа для драйверов, не зависящая от платформы и от ядра и применимая ко всем типам систем.²

Ядро Standard System, с другой стороны, — Linux. Поэтому вполне возможно встроить существующий драйвер ядра Linux и работать с ним через обычные интерфейсы Linux, такие как V4L2 или подсистема ввода.

Если есть Linux BSP, оценивать «переписывание всех драйверов на HDF» не нужно. Сначала решите, какие устройства необходимо выставить во фреймворк OpenHarmony, и заложите в оценку именно этот объём.

Кроме того, ещё до закупки платы можно начать проверять структуру и процесс загрузки в QEMU. Эта точка входа и порядок работ после внедрения сведены в разделе 8.

flowchart TB
    accTitle: Повторное использование драйверов Linux и адаптация к фреймворку
    accDescr: При использовании существующих драйверов Linux в Standard System разделите дополнительную работу: использовать их через обычные интерфейсы Linux или выставлять во фреймворк OpenHarmony через HDI.
    driver["Драйвер Linux в Standard System"] --> normal["Обычные интерфейсы Linux"]
    driver --> hdi["Использование через HDI"]
    normal --> direct["Конфигурация со встроенным существующим драйвером"]
    hdi --> adapt["Адаптация на стороне OpenHarmony"]
    adapt --> framework["Системные службы и фреймворки"]

Рисунок 11: Не переписывайте все драйверы, а оцените объём, который нужно выставить в OpenHarmony.

4.4. Готовим среду разработки и сотрудников, способных читать документацию

Точки входа в разработку устройств — графический 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. Среди поддерживаемых плат есть SoC от NXP и ST

В списке поддерживаемых сообществом отладочных плат, на который ссылается статья, 22 позиции. Ниже — те, что вероятнее всего относятся к оборудованию.¹⁵

Поставщики SoC — не только китайские. Здесь есть и NXP i.MX8M Mini, и серия STM32 от ST, поэтому японский производитель оборудования может оценить её на семействе SoC, которое уже использует.

Однако эта таблица показывает назначение, указанное в документации. Она не гарантирует десятилетние поставки, распространение в Японии или официальную поддержку OpenHarmony для плат серийного производства.

flowchart TB
    accTitle: Разделяем список поддерживаемых плат и условия закупки для серийного производства
    accDescr: Список поддерживаемых отладочных плат — это точка входа для технической оценки, и он не гарантирует распространение в стране, годы поставок или официальную поддержку плат серийного производства.
    list["Список поддерживаемых отладочных плат"] --> candidate["Кандидаты для технической оценки"]
    candidate --> sale["Проверить фактическую продажу и распространение в стране"]
    sale --> supply["Проверить серийные партии и годы поставок"]
    list -.-> note["Это не гарантия долгосрочных поставок"]

Рисунок 13: Наличие имени в списке и возможность закупки на протяжении срока службы продукта — две разные проверки.

5.2. Условия закупки проверяем до заказа образца для оценки

В списке в основном отладочные платы, многие ориентированы на китайский рынок. Их не обязательно можно купить у японского дистрибьютора как нечто само собой разумеющееся. Прежде чем заказывать образец для оценки, уточните три пункта.

1. Есть ли плата на странице продаж производителя платы или в канале трансграничной электронной торговли.
2. Есть ли в Японии торговый дистрибьютор.
3. Каковы минимальная партия для серийного производства и сроки поставок.

Даже если плата есть в списке поддерживаемых, без возможности её закупить техническую проверку на реальном железе не продвинуть. Вместе со сроком сопровождения ОС проверяйте и условия поставки платы.

Если вы ставите систему на собственную плату, портирование — работа ваша или дистрибьютора. Это другой объём, нежели закупка лицензии у OEM-дистрибьютора для Windows IoT с использованием драйверов от поставщика. Если SoC уже определён, иногда практичнее оценить трудозатраты на портирование под этот SoC, чем искать отладочную плату.

flowchart TB
    accTitle: Разделяем подготовку с отладочной платой и с собственной платой
    accDescr: С отладочной платой изучают доступность и условия серийного производства, а с собственной платой или уже выбранным SoC оценивают, кто выполняет портирование и каковы трудозатраты.
    hardware["Аппаратное обеспечение продукта"] --> board["Рассмотреть отладочную плату"]
    hardware --> own["Собственная плата или выбранный SoC"]
    board --> procure["Проверить доступность и условия производства"]
    own --> port["Проверить, кто портирует, и трудозатраты"]
    procure --> plan["Спланировать вместе с сопровождением ОС"]
    port --> plan

Рисунок 14: В план закупки включайте не только покупку образца для оценки, но и работу по выводу системы на серийном железе.

6. Проверяем условия отгрузки: лицензии, сертификация и экосистема

6.1. Проверяем LICENSE каждого включаемого компонента по отдельности

OpenHarmony — это не одна лицензия. Перечислите репозитории, которые собираются в продукт, и проверяйте их по объёму включения.

Если свести всё к «OpenHarmony — это Apache 2.0, значит, всё в порядке», можно не заметить обязательств GPL для части Standard System с ядром Linux. Практическое отличие от Windows IoT, где ОС закупается по коммерческой лицензии, состоит в том числе в этой проверке лицензий по каждому компоненту.

flowchart TB
    accTitle: Проверяем лицензии исходя из объёма, включаемого в продукт
    accDescr: Не считайте OpenHarmony единой лицензией: перечислите репозитории, собираемые в продукт, и проверьте каждый LICENSE и то, что требуется при распространении.
    product["Конфигурация, собираемая в продукт"] --> repos["Перечислить целевые репозитории"]
    repos --> licenses["Проверить каждый LICENSE"]
    licenses --> delivery["Упорядочить требования при распространении"]
    delivery --> legal["Согласовать с юридическим отделом и отделом ИС"]

Рисунок 15: Не решайте по одной Apache 2.0 — проверяйте каждый компонент, который реально собираете.

6.2. Разделяем изменение ядра и распространение устройства заказчику

Обязанность по GPLv2 возникает не в момент изменения кода, а в момент распространения. Если вы только изменили ядро и запускаете его на внутренней тестовой машине, обязанность предоставлять исходники не возникает.

Когда вы передаёте устройство заказчику, возникает обязанность предоставить получателю исходный код, соответствующий распространённым бинарникам, включая ваши изменения. Для производителя оборудования передача и есть распространение, поэтому на этапе серийного производства и поставки соответствие требуется. Отделяйте то, что на этапе внутреннего прототипа обязанности публиковать нет, от того, что при передаче заказчику соответствие необходимо. Конкретный способ обеспечения соответствия согласуйте с собственными юридическим отделом и отделом интеллектуальной собственности.

flowchart TB
    accTitle: Различаем внутреннее изменение ядра и распространение заказчику
    accDescr: Рассматривая обязанность GPLv2 предоставлять исходники, разделите случай, остающийся внутри компании, и распространение заказчику устройства, содержащего бинарники ядра.
    kernel["Конфигурация, содержащая ядро Linux"] --> internal["Остаётся во внутренней проверке и использовании"]
    kernel --> distribute["Устройство распространяется заказчику"]
    internal --> no["Одни внутренние изменения обязанности не создают"]
    distribute --> corresponding["Предоставить соответствующие исходники"]

Рисунок 16: Проверяйте обязанность, разделяя момент изменения и момент передачи устройства заказчику.

6.3. Разделяем то, что система работает, и то, что её называют совместимой с OpenHarmony

Отдельно от соблюдения лицензий проверьте процедуру, необходимую для публичного заявления о совместимости.

6.3.1. Внутренняя проверка и заявление о совместимости продукта

Если вы используете её только для внутренней проверки или в единичной машине, сертификация совместимости не нужна. Если же вы хотите публично заявить о совместимости с OpenHarmony как продукт или быть частью экосистемы, оценивайте трудозатраты исходя из прохождения оценки совместимости OpenAtom Foundation.

Техническая основа — 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 года, то есть на принятую в статье точку отсчёта, источники расходятся в описании состава 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 года, то есть на принятую в статье точку отсчёта, оно находится в стадии Incubating, и его сообщество несопоставимо по размеру с самой OpenHarmony. Если второе означает «не должно содержать кода китайского происхождения», то Oniro тоже построена поверх базового слоя OpenHarmony, поэтому ограничение не снимается.

flowchart TB
    accTitle: Ограничения на управляющий орган и на происхождение кода
    accDescr: Разделите политику закупок, нацеленную на управляющий орган, и политику, нацеленную на происхождение кода, и убедитесь, что с Oniro под европейским управлением условие о коде, производном от OpenHarmony, не меняется.
    policy["Ограничение в политике закупок"] --> governance["Управляющий орган и управление"]
    policy --> origin["Происхождение кода"]
    governance --> oniro["Рассмотреть семейство Oniro с условиями"]
    origin --> remain["Oniro тоже не снимает ограничение"]
    oniro -.-> maturity["Проверить и зрелость на июль 2026 года"]

Рисунок 19: Не путайте смену управляющего органа со сменой происхождения кода.

7. Принимаем решение: сопоставляем требования продукта с условиями, которые можем взять на себя

7.1. Судим по порядку, начиная с рынка и требований к продукту

Порядок проверки предпосылок таков: сначала рынок и требования к продукту, потом техническая оценка. В дополнение к этому проверяются SDK, сопровождение и сотрудники, способные читать техническую документацию. Даже если технически систему можно сделать, принять решение о её внедрении в оборудование, пока сопровождение не зафиксировано, нельзя.

flowchart TB
    accTitle: Основные решения о внедрении OpenHarmony как ОС для оборудования
    accDescr: Проверив требования рынка или ценность взаимодействия устройств, проверьте SDK, сопровождение и сотрудников, способных читать техническую документацию, и рассмотрите Windows IoT или встраиваемый Linux, если условия выполнить нельзя.
    S["Выбрать ОС для устройства"] --> 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. Если вариант ещё в списке кандидатов, конкретизируем его семью шагами

Если вариант прошёл таблицу решений, переходите к семи работам ниже. То, что система запустилась в QEMU или на реальном железе, и то, что её можно принять как продукт, — не одно и то же. Не утверждайте внедрение только на основании успешной технической проверки, пока условия сопровождения не закрыты.

1. Инвентаризируйте периферийные устройства и промежуточное ПО. Проверьте, можно ли поддержать на OpenHarmony камеры, ввод-вывод, связь, приводы, обработку изображений и так далее. Если здесь тупик, продвигать остальные шаги нет смысла.
2. Зафиксируйте тип системы. Определитесь между Mini System, Small System и Standard System. Вместе с этим меняются ядро (LiteOS-M / LiteOS-A / Linux) и способ написания приложений.
3. Проверьте структуру в QEMU. До покупки реального железа можно проверить сборку и процесс загрузки в окружениях device_qemu, таких как Arm Virt (LiteOS-A / Linux), Cortex-M4, Cortex-M55 и RISC-V.²⁰
4. Закрепите ветку сопровождения и обеспечьте воспроизводимость сборки. Зафиксируйте манифест repo (надёжный способ — указание тега), держите внутреннее зеркало и доведите дело до состояния, в котором те же бинарники можно пересобрать через пять лет. То, что вышестоящий хостинг сосредоточен на 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. Итоги: выбираем ОС, подходящую временному горизонту, закупке и кадрам устройства

OpenHarmony покрывает всё от MCU с 128 KiB до мощных устройств с 128 MiB и более в одном семействе и имеет в стандартной поставке взаимодействие устройств на базе DSoftBus — технически это цельная конструкция. Среди поддерживаемых плат, рассчитанных на промышленное применение, есть SoC от NXP и ST.¹²¹⁵

В то же время для оборудования, работающего десять лет, сопровождения сообществом в два года для Release и 3,5 года для LTS явно не хватает. Включая и то, что на принятую в статье точку отсчёта после 3.0-LTS новых LTS не отрезалось, внедрять её без сопровождения от коммерческого дистрибутива или без собственной команды, доходящей до обработки CVE, — не вариант.⁸¹¹¹²

Японскому производителю оборудования нужно проверить SDK для используемых устройств, сотрудников, способных читать техническую документацию, и сопровождение, покрывающее срок службы продукта. Без этого реалистичный выбор — Windows IoT Enterprise LTSC или встраиваемый Linux с коммерческой поддержкой. И наоборот: если требования китайского рынка, взаимодействие устройств или объединение всего от узлов на MCU до мощных устройств в одном семействе напрямую связаны с ценностью продукта, OpenHarmony стоит рассмотреть всерьёз.

Выбор ОС — это суждение не о том, «какая лучше», а о том, какая подходит временному горизонту, закупке и кадрам устройства. Критерии выбора на стороне Windows изложены в статье «Какой Windows ставить на промышленный компьютер?».

Похожие статьи

• Что такое OpenHarmony? — разбираем отличия от HarmonyOS и HarmonyOS NEXT
• Какой Windows ставить на промышленный компьютер? — практическое руководство по Windows IoT Enterprise / LTSC
• Реалистичные варианты после окончания поддержки Windows 10
• Практическое руководство по режиму киоска Windows (Assigned Access)

Смежные области консультаций

Komura Software LLC занимается поддержкой выбора среды исполнения, которая ставится в оборудование, разбором того, можно ли перенести существующее ПО для Windows-устройств, и ревью конфигураций, рассчитанных на длительную работу. К нам можно обратиться на том этапе, когда «в качестве кандидата появилась новая ОС, но внутри компании не с чем её сравнить».

• Технические консультации и ревью дизайна
• Разработка Windows-приложений с мягким реальным временем
• Разработка приложений для Windows
• Контакты

Справочные материалы

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Безопасно ли использовать OpenHarmony в качестве ОС для промышленного оборудования?

Зависит от условий. Решающим оказывается вопрос сопровождения: жизненный цикл ветки Release в сообществе OpenHarmony — два года (один год активного сопровождения плюс один год пассивного), а у ветки LTS — всего 3,5 года. Если поставить версию из сообщества прямо в устройство, работающее десять лет, исправления безопасности прекратятся на середине срока службы изделия. Внедрение предполагает либо покупку вендорского сопровождения коммерческого дистрибутива, либо собственную команду, которая ведёт ветку и сама обрабатывает CVE. Если такой команды не создать, временному горизонту устройства лучше соответствуют Windows IoT Enterprise LTSC (десять лет) или договор долгосрочной поддержки коммерческого встраиваемого Linux.

Что легче — OpenHarmony или встраиваемый Linux?

У OpenHarmony нижняя граница ниже. Мини-система (Mini System) OpenHarmony работает от минимальных 128 KiB памяти на MCU вроде Arm Cortex-M и 32-битных RISC-V; малой системе (Small System) нужно от 1 MiB, стандартной (Standard System) — от 128 MiB. Обычный встраиваемый Linux предполагает процессор с MMU и десятки мегабайт ОЗУ и больше, поэтому то, что область MCU покрывается внутри одного семейства ОС, — отличительная черта OpenHarmony. Заметьте, однако, что ядро мини-системы — LiteOS-M, и её среда исполнения полностью отличается от Linux в стандартной системе, так что утверждение «одна и та же ОС, значит, работают одни и те же приложения» здесь неверно.

Можно ли перенести существующее ПО для Windows-устройств на OpenHarmony?

Фактически это переписывание заново. У ПО для устройств, написанного на C#/.NET, Win32, COM или WPF/WinForms, на OpenHarmony нет соответствующей среды исполнения. Его придётся переписать на другом стеке: ArkTS плюс ArkUI для интерфейса, C/C++ в нижнем слое и HDF (Hardware Driver Foundation) для драйверов. Вдобавок вендорские SDK для промышленных камер и контроллеров движения часто поставляются только под Windows (в лучшем случае ещё и под Linux), и именно здесь находится настоящее узкое место переноса. Если исходная предпосылка — использовать существующие наработки, реалистичнее переход на Windows IoT Enterprise LTSC или на встраиваемый Linux, ограниченный устройствами, для которых поставляется SDK под Linux.

Нужна ли какая-либо сертификация, чтобы заявлять о поддержке OpenHarmony?

Чтобы называть продукт «совместимым с OpenHarmony», нужно пройти оценку совместимости (сертификацию) OpenAtom Foundation. Техническая основа для неё — семейство наборов тестов XTS (X Test Suite) в OpenHarmony. Однако состав описывается в разных источниках по-разному: по состоянию на июль 2026 года официальная документация говорит о «поддерживаемом сейчас ACTS (наборе тестов совместимости приложений) и DCTS (наборе тестов совместимости устройств), поддержка которого появится в будущем», тогда как материалы сообщества о процедуре сертификации описывают структуру, в которой к ним добавляется HATS (совместимость уровня аппаратной абстракции). При оценке трудозатрат не фиксируйте DCTS как обязательное требование, а уточните в службе сертификации, какие наборы действительно требуются на момент подачи заявки. Для внутренней проверки сертификация не нужна, но для продукта, публично заявляющего о совместимости, она становится необходимой.

Насколько велики поддержка японского языка и объём информации на нём?

Официальная документация выходит на двух языках, китайском и английском; японской версии нет. Обсуждения в сообществе тоже в основном на китайском. Поставщики коммерческих дистрибутивов — в большинстве китайские компании, и число служб, где можно получить первичную поддержку на японском, ограничено. Фактически, таким образом, практическое условие внедрения — наличие в компании людей, способных прочитать техническую документацию на китайском или английском от начала до конца. Это явное отличие от Windows и основных дистрибутивов Linux.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.