¿Es OpenHarmony una opción viable como sistema operativo para equipos industriales? — Comparación con Windows IoT y Linux embebido

En el artículo anterior, «Qué es OpenHarmony», separamos tres entidades distintas: OpenHarmony, HarmonyOS y HarmonyOS NEXT. A partir de aquí entramos en la práctica. ¿Es OpenHarmony realmente una opción viable como sistema operativo para instalar en un equipo?

En la selección de SO de un fabricante de equipos hay factores que se deciden antes que la comparación de funciones. No se puede instalar un SO que solo recibe mantenimiento durante dos años en un equipo que funcionará diez. Si se usa una cámara cuyo SDK de proveedor solo existe para Windows, ese SO queda descartado desde el principio. En este artículo comparamos, desde la perspectiva de la escala temporal del equipo y de la capacidad de aprovisionamiento, Windows IoT Enterprise LTSC, Linux embebido (basado en Debian o Yocto) y OpenHarmony, y resumimos en una tabla de decisión las condiciones bajo las que conviene adoptarlo y las condiciones bajo las que conviene descartarlo.

Este artículo no es «un artículo que recomienda OpenHarmony» ni tampoco «un artículo que aconseja evitarlo». En nuestra empresa trabajamos habitualmente con software de equipos para Windows, pero hemos visto muchas veces cómo, sin comparar bien las opciones, la decisión termina tomándose por «es tecnología nueva» o «viene de China». El objetivo de este artículo es reunir los elementos de juicio necesarios.

1. La conclusión, primero

• El periodo de mantenimiento es el mayor factor diferenciador. La rama Release de la comunidad OpenHarmony dura 2 años (1 año de mantenimiento activo + 1 año de mantenimiento pasivo), y la rama LTS llega solo a 3,5 años (2 años + 1,5 años). Los 10 años de Windows 11 IoT Enterprise LTSC 2024 parten de una premisa distinta.¹²
• Y, además, en los últimos años no se han publicado ramas LTS. Las LTS aparecieron al principio (1.1.0 LTS, 3.0-LTS), pero la última que figura en la tabla oficial de calendario de mantenimiento es 3.0-LTS, de septiembre de 2021. Todas las ramas publicadas desde la 3.1 en adelante son de tipo Release.³⁴
• Por tanto, no es viable instalar la versión comunitaria tal cual en un producto. Para adoptarla hace falta comprar el mantenimiento de proveedor de una distribución comercial, o contar con un equipo propio que mantenga la rama y llegue hasta las correcciones de CVE. Huawei explica que «OpenHarmony ha dado lugar a más de 100 versiones comerciales», y ese es precisamente el nivel comercial donde se produce la adopción real.⁵
• El límite inferior de recursos de OpenHarmony es abrumadoramente bajo. El sistema ligero funciona desde apenas 128 KiB en una MCU. Los requisitos mínimos de Windows 11 IoT Enterprise LTSC para dispositivos de uso especializado son 2 GB de memoria y 16 GB de almacenamiento, así que directamente compiten en terrenos distintos.⁶⁷
• No se puede trasladar el software de equipos existente para Windows. No existe un entorno de ejecución equivalente a C#/.NET, Win32, COM o WPF/WinForms; la interfaz pasa a ser ArkTS + ArkUI y los controladores a ser HDF, un esquema completamente distinto. No es un portado, es una reescritura completa.
• El cuello de botella real son los SDK de los proveedores. La mayoría de las cámaras industriales, controladores de movimiento y bibliotecas de comunicación PLC solo se ofrecen para Windows, y en segundo lugar para Linux. Comprobar si existen controladores para OpenHarmony es un paso que debe verificarse antes que la comparación de sistemas operativos.
• Apenas hay información primaria ni soporte en japonés. La documentación oficial se ofrece solo en chino e inglés, sin versión en japonés.⁸ Contar con personal capaz de leer documentación técnica en chino o inglés es un requisito de facto.
• Sí existen usos claramente adecuados. Productos destinados al mercado chino, dispositivos en los que la interconexión de varios equipos (DSoftBus) es el núcleo del valor del producto, dispositivos IoT con pantalla en los que se quiere usar la interfaz de ArkUI, y casos en los que se busca cubrir desde MCU hasta dispositivos completos con un solo esquema.⁹

Antes de entrar en detalle, resumimos en una sola tabla el juicio global por eje de evaluación y opción. Es un resumen de lo que se trata en cada capítulo siguiente. Los símbolos siguen una escala de cuatro niveles: ◎ = encaja tal cual / ○ = encaja con condiciones / △ = requiere atención / × = no encaja.

Como se ve, OpenHarmony obtiene ◎ en dos ejes: el límite inferior de recursos y la interconexión de equipos, mientras que los tres ejes de software existente, SDK e información en japonés quedan en ×. Esta forma no indica «superioridad o inferioridad», sino que «las condiciones en que encaja son limitadas». En la tabla de decisión del capítulo 8 detallamos, caso por caso, en qué condiciones sí encaja.

2. Igualar las premisas de la comparación — qué se compara con qué

Antes de empezar la comparación conviene aclarar el objeto de análisis. Hablar de «SO» sin más, cuando en realidad se comparan capas distintas, hace que la discusión no encaje.

De la tabla conviene precisar dos términos. Yocto no es un SO terminado, sino un marco de trabajo que combina «recetas» (definiciones de pasos de compilación) para construir una distribución Linux propia para el producto de cada empresa. LTSC (Long-Term Servicing Channel) es un modelo de entrega de Windows que ofrece únicamente actualizaciones de seguridad, sin actualizaciones de funciones, durante un periodo prolongado; es la opción indicada para usos, como los equipos industriales, en los que se quiere fijar la configuración.

Aquí conviene tener claro que OpenHarmony no es un «producto terminado que se compra y se instala» como Windows IoT. Su posicionamiento se parece más al de Yocto: es un marco de trabajo sobre el que «se construye la configuración propia del producto». Ahora bien, a diferencia de Yocto, el marco de interfaz y el modelo de aplicación ya vienen decididos de forma integrada, por lo que llega más «hacia arriba» en la pila.

Las definiciones de los tipos de sistema de OpenHarmony son las siguientes.⁶

En el contexto de integración en equipos industriales, las opciones que entran en comparación son principalmente el sistema estándar (equipos con HMI) y el sistema ligero (nodos sensores, módulos de comunicación). El sistema pequeño se orienta más bien a productos de tipo cámara.

3. Comparación del periodo de soporte — cuál encaja con la escala temporal del equipo

Los PC o placas que se integran en un equipo deben seguir funcionando durante un ciclo de vida de unos 10 años, similar al del propio equipo. Al comparar cada opción bajo este criterio, la diferencia es evidente.

Esta tabla se basa en la información oficial de cada fuente a fecha de julio de 2026. El periodo de soporte y la fecha de finalización se revisan con el tiempo, así que, justo antes de tomar la decisión de adoptar una opción, confírmelo siempre con la fuente primaria. Los puntos de referencia son los siguientes:

• OpenHarmony: Version Lifecycle Management (política de gestión del ciclo de vida) y Version Definitions (tipos de rama y tabla de calendario de mantenimiento)¹³
• Windows: Microsoft Lifecycle (ciclo de vida por producto)²
• Debian: Debian Wiki LTS¹⁰
• Yocto Project: Releases¹¹

En particular, como se explica más adelante, las series 5.x y 6.x de OpenHarmony todavía no figuran en la tabla de calendario de mantenimiento. Si se considera una versión que no aparece en las filas de esta tabla, debe partirse de la base de que su periodo aún no está definido.

Hay además dos puntos que conviene leer con más detenimiento.

Primero: el «periodo de mantenimiento pasivo» de OpenHarmony reduce la calidad. Según la política oficial de gestión del ciclo de vida, durante el periodo de mantenimiento activo la comunidad publica versiones etiquetadas de forma planificada y corrige defectos y vulnerabilidades de seguridad; al entrar en el periodo de mantenimiento pasivo ya no se planifican ni publican versiones etiquetadas, y solo se corrigen las vulnerabilidades de seguridad y los defectos de gravedad crítica o superior.¹ Es decir, el periodo real de «uso con tranquilidad» debe considerarse de 1 año para la rama Release y de 2 años para la LTS.

Segundo: en los últimos años no se han publicado ramas LTS. La última LTS que figura en la tabla oficial de calendario de mantenimiento es 3.0-LTS (septiembre de 2021); las ramas 3.1, 3.2, 4.0 y 4.1 son todas de tipo Release.³ Antes también hubo versiones LTS —el índice de notas de versión conserva 1.1.0 LTS (abril de 2021) y su serie—, pero todas ellas están ya en fin de vida.⁴ Además, las series 5.x y 6.x todavía no aparecen en esta tabla de calendario de mantenimiento. Dando por sentado un ciclo de vida de equipo de 10 años, esto significa que sigue sin poder saberse, de antemano y para cada versión, «qué rama recibirá cuánto mantenimiento».

En cambio, Windows 11 IoT Enterprise LTSC 2024 sigue una política de ciclo de vida fija, con una fecha de finalización —el 10 de octubre de 2034— establecida desde el principio.² Debian también publica el soporte normal y el periodo LTS de cada versión, y el Yocto Project declara explícitamente que sus versiones LTS reciben soporte durante 4 años.¹⁰¹¹

Esto no significa que la calidad de OpenHarmony sea baja. Este modelo de mantenimiento simplemente no está pensado para el uso de «instalar la versión comunitaria tal cual en un producto y dejarla así». En la adopción industrial real, los proveedores de distribuciones comerciales mantienen su propia rama y ofrecen ese mantenimiento de forma remunerada. Al evaluar la adopción, la pregunta que hay que hacer no es «¿cuántos años dura el soporte de OpenHarmony?», sino «el proveedor de esa distribución, ¿qué rama mantiene, hasta cuándo y con qué SLA?».

4. Opciones de hardware

La comunidad ha publicado 22 modelos de placas de desarrollo compatibles.¹³ Si se extraen las que pueden resultar relevantes para equipos industriales, se obtiene lo siguiente.

Lo importante es que los proveedores de SoC no son solo chinos. Que NXP i.MX8M Mini y la serie STM32 de ST figuren en la lista de compatibilidad tiene un significado práctico real para los fabricantes de equipos japoneses: existe la posibilidad de evaluarlo con familias de SoC que ya se han usado antes.

Sin embargo, las advertencias pesan tanto como esa ventaja.

• La lista de placas compatibles y las placas industriales realmente disponibles son cosas distintas. Lo que figura aquí son sobre todo placas de evaluación; si OpenHarmony está oficialmente disponible en una placa industrial con garantía de suministro a 10 años es algo que hay que confirmar por separado. El «uso previsto» de la tabla es el posicionamiento que indica la documentación, no una garantía de suministro ni una prueba de distribución dentro de Japón.
• La disponibilidad debe confirmarse individualmente desde Japón. Las placas de esta lista están orientadas sobre todo al mercado chino, y no siempre se pueden comprar sin más a través de un distribuidor nacional. Antes de conseguir una placa de evaluación, confirme mediante consulta directa: (1) la página de venta del fabricante de la placa y su disponibilidad en comercio electrónico transfronterizo, (2) si existe un distribuidor nacional, y (3) el lote mínimo y los años de suministro previstos en producción en serie. Si esto se atasca, todo el trabajo de verificación técnica posterior queda detenido.
• Si se instala en hardware propio, el portado pasa a ser trabajo interno. Con Windows IoT basta, en general, con «comprar la licencia a través de un distribuidor OEM, y el proveedor entrega los controladores»; con OpenHarmony ese trabajo recae en la propia empresa o en un distribuidor.
• El tratamiento de los controladores varía según desde dónde se use el dispositivo. OpenHarmony cuenta con HDF (Hardware Driver Foundation), una base unificada de controladores de diseño independiente de la plataforma y del núcleo, aplicable a todos los tipos de sistema.⁹ Ahora bien, como el núcleo del sistema estándar es Linux, es perfectamente posible integrar tal cual un controlador de núcleo Linux existente y usarlo a través de las interfaces habituales de Linux, como V4L2 o dispositivos de entrada. El trabajo de adaptación solo es necesario cuando se quiere que ese dispositivo sea accesible, vía HDI, desde los servicios de sistema o el marco de trabajo de OpenHarmony. Si ya existe un BSP de Linux, no hace falta estimar que “todos los controladores hay que reescribirlos en HDF”. Decida primero qué dispositivos deben exponerse al marco de trabajo de OpenHarmony, y estime el esfuerzo únicamente para ese alcance.

Cabe señalar que la verificación puede empezar incluso mientras el aprovisionamiento de la placa está detenido. En el capítulo 9 se describe el procedimiento para confirmar, con QEMU, la estructura y el flujo de arranque antes de comprar un equipo real. Además, si ya está decidido el SoC de la placa propia, en ocasiones resulta más práctico estimar directamente el esfuerzo de portado a ese SoC que buscar una placa de evaluación.

5. Entorno de desarrollo y lenguaje — ¿se puede aprovechar el software existente?

Desde el punto de vista del software de equipos existente, la conclusión es sencilla. El software de equipos escrito para Windows no se puede trasladar a OpenHarmony. Ni C#/.NET, ni Win32, ni COM, ni WPF tienen un entorno de ejecución equivalente. La interfaz hay que reescribirla con ArkTS y ArkUI, y la capa inferior en C/C++.

Un obstáculo aún más real es el nivel de soporte de los SDK de los proveedores. Los SDK de cámaras industriales, las bibliotecas de controladores de movimiento, el middleware de comunicación PLC, las bibliotecas de procesamiento de imágenes: en la práctica, la mayoría de ellos están pensados primero para Windows, y ya sería una suerte que existiera una versión para Linux. No cabe esperar que exista soporte para OpenHarmony. Por tanto,

Antes de comparar sistemas operativos, elabore la lista de dispositivos periféricos y middleware que necesita el equipo, y confirme el estado de compatibilidad de cada uno con OpenHarmony.

Discutir solo con la tabla comparativa de sistemas operativos, sin hacer esto, termina fallando de forma segura en las fases posteriores. Cuando en nuestra empresa recibimos consultas sobre software de equipos, empezamos precisamente por construir esa lista.

Hay dos puntos de entrada disponibles para el entorno de desarrollo: la herramienta gráfica DevEco Device Tool (una configuración combinada en la que se edita el código, se depura y se graba desde Windows, mientras la compilación se realiza en Ubuntu) y un procedimiento mediante CLI.¹⁴ La obtención del código fuente se hace con la herramienta repo, y se indican como espejos gitcode.com, gitee.com y GitHub.¹⁵

6. Licencias y propiedad intelectual

OpenHarmony no se rige por una única licencia. Hay que confirmarla según el ámbito que se integre en cada caso.

Resumir «OpenHarmony es Apache 2.0, así que no hay problema» pasa por alto las obligaciones GPL de la parte del núcleo en el sistema estándar. La norma es enumerar los repositorios que entran dentro del alcance instalado en el equipo y confirmar la licencia (LICENSE) uno por uno. Este es un contraste práctico con Windows IoT, que se resuelve con una única licencia comercial.

Sobre GPLv2 conviene una precisión. La obligación surge en el momento de la distribución, no en el momento de la modificación. Si el núcleo se modifica y se hace funcionar solo en una máquina de verificación interna, no surge obligación de entrega; la obligación de entregar al destinatario el código fuente correspondiente al binario distribuido aparece en el momento en que ese equipo se entrega al cliente. Para un fabricante de equipos, «entrega» equivale en la práctica a «distribución», así que al final siempre hay que atenderla, pero conviene tener clara la distinción de que no existe una obligación de publicación desde la fase de prototipo interno (consulte el método de cumplimiento concreto con el departamento legal y de propiedad intelectual de su empresa).

7. Certificación y participación en el ecosistema

Para que un producto anuncie de cara al exterior ser «compatible con OpenHarmony» hace falta superar la evaluación de compatibilidad de la Fundación OpenAtom. La base técnica es el XTS (X Test Suite) de OpenHarmony; la documentación oficial lo describe como el conjunto que «ofrece los conjuntos de pruebas de compatibilidad de OpenHarmony, e incluye el conjunto de pruebas de compatibilidad de aplicaciones (ACTS), actualmente soportado, y el conjunto de pruebas de compatibilidad de dispositivos (DCTS), que se soportará en el futuro».⁹ Es decir, según la redacción de la documentación oficial (a fecha de julio de 2026), actualmente solo está disponible ACTS, y DCTS se ofrecerá en el futuro.

Por otro lado, el material comunitario sobre el procedimiento de certificación describe el XTS como una estructura de tres partes —ACTS, HATS (compatibilidad de la capa de abstracción de hardware) y DCTS—, lo que no coincide con la redacción de la documentación oficial.¹⁹ El flujo en sí, en el que el solicitante realiza por su cuenta el desarrollo de adaptación y las autopruebas, y presenta la solicitud junto con un informe de pruebas, es común a ambas fuentes.

Al estimar el esfuerzo, no dé por sentado que DCTS es un requisito obligatorio. Lo más seguro es confirmar directamente con la ventanilla de certificación qué conjunto se exige realmente en el momento de la solicitud. Este tipo de situación en la que «la documentación oficial y el material comunitario no coinciden» debe contabilizarse, junto con la ausencia de información primaria en japonés, como un coste de comunicación adicional a la hora de adoptar la plataforma.

Para uso interno de verificación o para un equipo puntual no hace falta certificación, pero sí se da por sentada en productos que anuncian compatibilidad de cara al exterior, o en productos que quieren tratarse como parte del ecosistema. Es un elemento que conviene estimar como esfuerzo desde el principio.

8. Tabla de decisión — condiciones para adoptarlo y condiciones para descartarlo

Antes de entrar en la tabla de decisión, resumimos en una sola imagen el flujo de juicio que lleva hasta ella. El orden en que se confirman las premisas importa: primero el mercado y los requisitos del producto, después el análisis técnico. Aunque sea técnicamente posible construirlo, si el mantenimiento no se puede fijar por contrato, no se puede instalar en el equipo.

flowchart TD
    S["Elegir el SO que se instalará en el equipo"]
    Q1["¿Es un producto destinado al mercado chino, o el<br/>requisito exige compatibilidad con OpenHarmony?"]
    Q2["¿La interconexión de varios equipos (DSoftBus)<br/>es el núcleo del valor del producto?"]
    Q3["¿Están disponibles en OpenHarmony los SDK de proveedor<br/>de los periféricos y el middleware necesarios?<br/>（¿se puede cubrir internamente lo que falte?）"]
    Q4["¿Se puede fijar el mantenimiento por contrato?<br/>（proveedor de distribución comercial,<br/>o equipo propio hasta las correcciones de CVE）"]
    Q5["¿Se cuenta con personal capaz de leer<br/>documentación técnica en chino o inglés?"]
    OH["Evaluar OpenHarmony de frente<br/>Adquirirlo a través de una distribución comercial"]
    OTH["Windows IoT LTSC o Linux embebido<br/>Decidir según el software existente y el soporte de SDK"]
    NG["Descartar OpenHarmony"]

    S --> Q1
    Q1 -->|"Sí"| Q3
    Q1 -->|"No"| Q2
    Q2 -->|"Sí"| Q3
    Q2 -->|"No"| OTH
    Q3 -->|"Disponible / se puede cubrir internamente"| Q4
    Q3 -->|"No disponible"| NG
    Q4 -->|"Se puede fijar"| Q5
    Q4 -->|"No se puede fijar"| NG
    Q5 -->|"Sí hay"| OH
    Q5 -->|"No hay"| NG
    NG --> OTH

Figura 1: Flujo de decisión para adoptar OpenHarmony. La base de cada bifurcación se corresponde con las filas de la tabla de decisión de más abajo

De estas bifurcaciones, la idea central de este artículo es que en la práctica muchos casos caen en Q3 (SDK de proveedor) y Q4 (contrato de mantenimiento). La tabla de decisión siguiente desarrolla cada bifurcación de esta figura en situaciones concretas.

9. Si se adopta, lo primero que hay que hacer

Si la tabla de decisión se inclina hacia «adoptar», el orden de trabajo es el siguiente.

1. Inventario de dispositivos periféricos y middleware. Cámaras, E/S, comunicaciones, motion, procesamiento de imágenes: confirme la compatibilidad con OpenHarmony de cada proveedor. Si aquí se atasca, no tiene sentido avanzar con el resto del proceso.
2. Determinación del tipo de sistema. Decida si se construirá como sistema ligero, pequeño o estándar. Esto cambia tanto el núcleo (LiteOS-M / LiteOS-A / Linux) como la forma de escribir las aplicaciones.
3. Confirmación de la estructura con QEMU. Antes de comprar una placa real, se puede confirmar el flujo de compilación y arranque con los entornos de emulación que ofrece device_qemu: Arm Virt (LiteOS-A / Linux), Cortex-M4, Cortex-M55, RISC-V, entre otros.²⁰
4. Fijar la rama de mantenimiento y asegurar la reproducibilidad de la compilación. Fije el manifiesto de repo (indicar una etiqueta concreta es lo más seguro), mantenga un espejo interno y llegue a un estado en el que sea posible regenerar el mismo binario dentro de cinco años.¹⁵ El hecho de que el alojamiento en origen se concentre en gitcode.com también es, desde el punto de vista de la continuidad del negocio, una razón para contar con un espejo propio.
5. Inventario de licencias. Enumere los repositorios que entran dentro del alcance instalado y organice las obligaciones de Apache 2.0, BSD y GPL.
6. Negociación del contrato de mantenimiento. Fije por contrato con el proveedor de la distribución comercial «qué rama, hasta cuándo y con qué SLA» se mantendrá. Si esto no queda cerrado, la decisión de adopción debería quedar en suspenso.
7. Decisión sobre la necesidad de la evaluación de compatibilidad (XTS). Si se va a anunciar compatibilidad de cara al exterior, incluya el esfuerzo desde el principio.

10. Resumen

• OpenHarmony tiene, desde el punto de vista técnico, un diseño coherente: cubre con un solo esquema desde MCU de 128 KiB hasta dispositivos completos de 128 MiB o más, y ofrece de serie la interconexión de equipos (DSoftBus). Existen placas compatibles pensadas para uso industrial, entre ellas SoC de NXP y de ST.
• Sin embargo, desde la perspectiva del ciclo de vida de 10 años del equipo, el periodo de mantenimiento de la comunidad (2 años en Release, 3,5 años en LTS) resulta claramente insuficiente. Y, además, no se ha publicado ninguna rama LTS desde 3.0-LTS en 2021. Adoptarlo da por sentado el mantenimiento de proveedor de una distribución comercial.
• Para un fabricante de equipos japonés, el requisito de facto para la adopción se reduce a tres puntos: (1) si los SDK de proveedor son compatibles con OpenHarmony, (2) si se cuenta con personal capaz de leer documentación técnica en chino o inglés, y (3) si existe un proveedor que pueda fijar el mantenimiento por contrato. Si falta cualquiera de los tres, Windows IoT Enterprise LTSC o un Linux embebido con soporte comercial se ajustan mejor a la escala temporal del equipo.
• A la inversa, en productos destinados al mercado chino, productos en los que la interconexión de equipos es el núcleo del valor, o líneas de producto que quieren cubrir desde MCU hasta dispositivos completos con un solo esquema, sí vale la pena evaluarlo de frente.

La selección de SO no es una cuestión de «cuál es superior», sino de «cuál encaja con la escala temporal del equipo, el aprovisionamiento y el personal disponible». Los criterios de selección del lado de Windows están organizados en «Qué versión de Windows conviene instalar en un PC industrial».

Artículos relacionados

• Qué es OpenHarmony — diferencias con HarmonyOS y HarmonyOS NEXT
• Qué versión de Windows conviene instalar en un PC industrial — guía práctica de Windows IoT Enterprise / LTSC
• La solución realista tras el fin de soporte de Windows 10
• Guía práctica del modo kiosco de Windows (Assigned Access)

Áreas de consultoría relacionadas

KomuraSoft LLC ofrece apoyo en la selección de la plataforma de ejecución que se instala en el equipo, en el análisis de la viabilidad de migrar software de equipos existente para Windows, y en la revisión de configuraciones pensadas para un funcionamiento de larga duración. Puede consultarnos incluso desde la fase en la que «ha surgido un nuevo SO como candidato, pero no hay material interno para compararlo».

• Consultoría técnica y revisión de diseño
• Desarrollo de aplicaciones Windows de tiempo real blando
• Desarrollo de aplicaciones Windows
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Es seguro adoptar OpenHarmony como sistema operativo de un equipo industrial?

Depende de las condiciones. El factor decisivo es el tratamiento del periodo de mantenimiento: las ramas Release de la comunidad OpenHarmony tienen un ciclo de vida de 2 años (1 año de mantenimiento activo + 1 año de mantenimiento pasivo), y las ramas LTS llegan solo a 3,5 años. Si se instala la versión comunitaria tal cual en un equipo que funcionará 10 años, las correcciones de seguridad se detienen a mitad de la vida útil del producto. Adoptarlo exige comprar el mantenimiento de un proveedor de una distribución comercial, o contar con un equipo propio que mantenga la rama y se encargue de las correcciones de CVE. Si no se puede montar ese equipo, Windows IoT Enterprise LTSC (10 años) o un contrato de soporte a largo plazo de Linux embebido comercial se ajustan mejor a la escala temporal del equipo.

¿Qué es más ligero, OpenHarmony o Linux embebido?

El límite inferior de OpenHarmony es menor. El sistema ligero de OpenHarmony funciona desde tan solo 128 KiB de memoria en MCU como Arm Cortex-M o RISC-V de 32 bits; el sistema pequeño requiere 1 MiB o más, y el sistema estándar 128 MiB o más. El Linux embebido habitual da por sentado un procesador con MMU y decenas de MB de RAM como mínimo, así que cubrir el rango de las MCU con el mismo esquema de sistema operativo es una característica propia de OpenHarmony. Ahora bien, el núcleo del sistema ligero es LiteOS-M, cuyo entorno de ejecución es completamente distinto al Linux del sistema estándar, así que no se cumple el supuesto de que 'al ser el mismo SO, funcionan las mismas aplicaciones'.

¿Se puede portar a OpenHarmony el software de un equipo que ya funciona con Windows?

En la práctica implica reescribirlo desde cero. El software de equipos escrito en C#/.NET, Win32, COM o WPF/WinForms no tiene un entorno de ejecución equivalente en OpenHarmony. Habría que reescribir la interfaz de usuario con ArkTS + ArkUI, la capa inferior en C/C++ y los controladores con el esquema HDF (Hardware Driver Foundation), completamente distinto. Además, los SDK de proveedores de cámaras industriales o controladores de movimiento suelen ofrecerse solo para Windows (y en segundo lugar para Linux), y ese suele ser el cuello de botella real del portado. Si se quiere aprovechar el software existente, resulta más realista migrar a Windows IoT Enterprise LTSC, o bien limitarse a Linux embebido con dispositivos que sí cuenten con SDK para Linux.

¿Se necesita alguna certificación para anunciar compatibilidad con OpenHarmony?

Para que un producto se presente como 'compatible con OpenHarmony' hace falta superar la evaluación de compatibilidad (certificación) de la Fundación OpenAtom. La base técnica es el conjunto de pruebas XTS (X Test Suite) de OpenHarmony. Ahora bien, las fuentes describen el desglose de forma distinta: la documentación oficial de julio de 2026 habla de 'ACTS (conjunto de pruebas de compatibilidad de aplicaciones), actualmente soportado, y DCTS (conjunto de pruebas de compatibilidad de dispositivos), que se soportará en el futuro'. Por su parte, el material comunitario sobre el trámite de certificación describe una estructura que añade HATS (compatibilidad de la capa de abstracción de hardware). Al estimar el esfuerzo, no dé por sentado que DCTS es un requisito obligatorio: confirme con la ventanilla de certificación qué conjunto se exige realmente en el momento de la solicitud. Para uso exclusivamente interno de verificación no hace falta certificación, pero sí es necesaria en productos que anuncian compatibilidad de cara al exterior.

¿Cuánto soporte e información en japonés hay disponible?

La documentación oficial se ofrece en chino e inglés; no existe versión en japonés. Los debates de la comunidad también giran principalmente en torno al chino. Los proveedores de distribuciones comerciales son mayoritariamente empresas chinas, y los canales para recibir soporte de primera mano en japonés son limitados. Por lo tanto, contar internamente con personal capaz de leer documentación técnica en chino o inglés se convierte en un requisito de facto para adoptarlo. Este es un contraste claro frente a Windows o las distribuciones principales de Linux.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.