KomuraSoft LLC
Kontakt
Menü

Ist OpenHarmony ein tragfähiges Betriebssystem für Industrieanlagen? — Im Vergleich mit Windows IoT und Embedded Linux

· · OpenHarmony, Embedded-Systeme, Betriebssystemauswahl, Geräteintegrierte Software, Windows IoT, Linux, Fertigung, Technische Beratung

Im vorigen Artikel „Was ist OpenHarmony?“ haben wir die drei Entitäten OpenHarmony, HarmonyOS und HarmonyOS NEXT auseinandersortiert. Ab hier geht es in die Praxis. Ist OpenHarmony als Betriebssystem für ein Gerät wirklich eine tragfähige Option?

Für einen Gerätehersteller enthält die Betriebssystemwahl Elemente, die vor jedem Funktionsvergleich entschieden werden. Sie können kein Betriebssystem, das zwei Jahre gepflegt wird, in ein Gerät einbauen, das zehn Jahre läuft. Verwenden Sie eine Kamera, deren Hersteller-SDK nur für Windows existiert, ist dieses Betriebssystem von vornherein aus dem Rennen. In diesem Artikel stellen wir Windows IoT Enterprise LTSC, Embedded Linux (Debian- oder Yocto-basiert) und OpenHarmony nebeneinander, vergleichen sie aus der Perspektive der Zeitachse des Geräts und der Beschaffung und legen in einer Entscheidungstabelle die Bedingungen fest, unter denen Sie es einsetzen können und unter denen Sie darauf verzichten sollten.

Beachten Sie, dass dieser Artikel weder „ein Artikel, der OpenHarmony empfiehlt“ noch „ein Artikel, der davor warnt“ ist. Normalerweise befassen wir uns mit Windows-Gerätesoftware, aber wir haben wiederholt Situationen erlebt, in denen eine Entscheidung auf Grundlage von „das ist neue Technologie“ oder „das kommt aus China“ getroffen wurde, ohne die Optionen jemals ordentlich zu vergleichen. Der Zweck hier ist, das Material für eine Entscheidung zusammenzustellen.

1. Das Wichtigste zuerst

  • Das Pflegefenster ist die größte Trennlinie. Die Release-Branches der OpenHarmony-Community laufen zwei Jahre (ein Jahr aktive Pflege plus ein Jahr passive Pflege), und selbst LTS-Branches nur 3,5 Jahre (zwei Jahre plus 1,5). Die Prämissen unterscheiden sich von den zehn Jahren des Windows 11 IoT Enterprise LTSC 2024.12
  • Und in den letzten Jahren wurden keine LTS-Branches mehr geschnitten. LTS-Versionen gab es zu Beginn (1.1.0 LTS, 3.0-LTS), aber der letzte in der offiziellen Pflegeplan-Tabelle verbleibende LTS ist 3.0-LTS aus dem September 2021. Jeder ab 3.1 veröffentlichte Branch ist ein Release.34
  • Folglich ist es nicht praktikabel, die Community-Version unverändert in ein Produkt einzubauen. Der Einsatz setzt voraus, dass Sie entweder Herstellerpflege einer kommerziellen Distribution kaufen oder intern die Fähigkeit besitzen, einen Branch zu pflegen und CVEs zu behandeln. Huawei erklärt, dass „OpenHarmony mehr als 100 kommerzielle Versionen veröffentlicht hat“, und genau in dieser kommerziellen Schicht findet der tatsächliche Einsatz statt.5
  • Die Ressourcenuntergrenze von OpenHarmony liegt überwältigend niedriger. Das Mini-System läuft ab minimal 128 KiB auf einer MCU. Die Mindestanforderungen für Windows 11 IoT Enterprise LTSC auf Spezialgeräten liegen bei 2 GB Speicher und 16 GB Speicherplatz, sodass sie nicht einmal in derselben Liga spielen.67
  • Vorhandene Windows-Gerätesoftwarebestände lassen sich nicht mitnehmen. Es gibt keine Laufzeitumgebung, die C#/.NET, Win32, COM oder WPF/WinForms entspricht; die Oberfläche wird zu ArkTS plus ArkUI, und Treiber werden zu HDF — ein anderer Technologiestapel. Es ist eine Neuentwicklung, keine Portierung.
  • Der eigentliche Engpass sind Hersteller-SDKs. Die meisten SDKs für Industriekameras, Bewegungssteuerungen und PLC-Kommunikationsbibliotheken werden nur für Windows und dann für Linux bereitgestellt. Ob ein OpenHarmony-Treiber existiert, ist ein Punkt, den Sie vor dem Betriebssystemvergleich prüfen müssen, nicht danach.
  • Es gibt praktisch keine japanischsprachigen Primärinformationen oder Support. Die offizielle Dokumentation liegt in zwei Sprachen vor, Chinesisch und Englisch; eine japanische Version gibt es nicht.8 Personen zu haben, die technische Dokumente auf Chinesisch oder Englisch durchgängig lesen können, ist eine faktische Voraussetzung.
  • Es gibt definitiv Einsatzfälle, für die es passt. Produkte für den chinesischen Markt; Geräte, bei denen die Zusammenarbeit mehrerer Geräte (DSoftBus) zentral für den Produktwert ist; bildschirmausgestattete IoT-Geräte, bei denen Sie ArkUI für die Oberfläche nutzen möchten; sowie Fälle, in denen Sie alles von der MCU bis zum leistungsfähigen Gerät innerhalb einer Familie abdecken möchten.9

2. Den Vergleichsboden ebnen — Was vergleichen wir womit?

Bevor wir mit dem Vergleich beginnen, sollten wir Klarheit über die Vergleichsgegenstände schaffen. „Betriebssystem“ ist ein Wort, aber Dinge auf unterschiedlichen Schichten nebeneinanderzustellen macht die Diskussion unzusammenhängend.

Option Was es tatsächlich ist Kernel UI-/App-Schicht
Windows 11 IoT Enterprise LTSC Microsofts kommerzielles Betriebssystemprodukt Windows NT Win32 / WinUI / WPF / WinForms, .NET
Embedded Linux (Debian-basiert) Eine Distribution Linux Frei wählbar (Qt, GTK, ein Wayland-Compositor und Ähnliches)
Embedded Linux (Yocto-basiert) Ein Rahmenwerk zum Bau einer eigenen Distribution Linux Frei wählbar
OpenHarmony-Standard-System Ein Betriebssystemprojekt (muss zur Distribution ausgebaut werden) Linux ArkUI, ArkTS, Ability
OpenHarmony-kleines System Wie oben LiteOS-A Standard-Grafik-Framework
OpenHarmony-Mini-System Wie oben LiteOS-M Leichtgewichtiges Grafik-Framework

Wichtig ist hier zu begreifen, dass OpenHarmony kein „fertiges Produkt zum Kaufen und Installieren“ wie Windows IoT ist. Von der Positionierung her ist es eher mit Yocto vergleichbar: ein Rahmenwerk zum „Aufbau einer eigenen Produktkonfiguration darauf“. Anders als bei Yocto sind jedoch UI-Framework und App-Modell ebenfalls als Teil des Pakets festgelegt, sodass es weiter oben in den Schichten liegt.

Die Definitionen der Systemtypen von OpenHarmony sind wie folgt.6

Systemtyp Prozessor Mindestspeicher Zielprodukte
Mini-System MCUs wie Arm Cortex-M und 32-Bit-RISC-V 128 KiB Konnektivitätsmodule, Sensoren, Wearables
Kleines System Anwendungsprozessoren wie Arm Cortex-A 1 MiB IP-Kameras, smarte Türspione, Router, Dashcams
Standard-System Anwendungsprozessoren wie Arm Cortex-A 128 MiB Bildschirmausgestattete Geräte mit vollständigem Anwendungsframework

Im Kontext der Geräteintegration sind die Kandidaten für den Vergleich hauptsächlich das Standard-System (Anlagen mit HMI) und das Mini-System (Sensorknoten, Kommunikationsmodule). Das kleine System liegt näher an Kameraprodukten.

3. Vergleich der Pflegezeiträume — Was passt zur Zeitachse des Geräts?

Ein in eine Anlage eingebauter PC oder ein Board soll erwartungsgemäß denselben ungefähr zehnjährigen Lebenszyklus durchlaufen wie die Anlage selbst. Stellt man die Optionen aus dieser Perspektive nebeneinander, ist der Unterschied offensichtlich.

Option Pflegezeitraum Konkretes Beispiel Quelle
Windows 11 IoT Enterprise LTSC 2024 10 Jahre Beginn 1. Oktober 2024, Ende 10. Oktober 2034 2
Windows 10 IoT Enterprise LTSC 2021 10 Jahre Ende 13. Januar 2032 10
Debian (einschließlich LTS) Etwa 5 Jahre Der LTS-Zeitraum für Debian 12 bookworm läuft vom 11. Juni 2026 bis 30. Juni 2028 11
Yocto Project LTS 4 Jahre 5.0 Scarthgap läuft April 2024 bis April 2028; 6.0 Wrynose April 2026 bis April 2030 12
OpenHarmony-LTS-Branch 3,5 Jahre (2 Jahre + 1,5) 3.0-LTS lief vom 30. September 2021 bis 30. März 2025 13
OpenHarmony-Release-Branch 2 Jahre (1 Jahr + 1 Jahr) 4.1-Release lief vom 30. März 2024 bis 30. März 2026 13

Hier lassen sich zwei weitere Punkte herauslesen.

Erstens: Die Qualität von OpenHarmonys „passiver Pflegephase“ sinkt. Nach der offiziellen Lebenszyklus-Verwaltungsrichtlinie gibt die Community während der aktiven Pflegephase planmäßig getaggte Versionen heraus und behebt Fehler sowie Sicherheitslücken; beginnt jedoch die passive Pflegephase, werden keine getaggten Versionen mehr geplant oder veröffentlicht, und nur Sicherheitslücken und Fehler mit kritischem Schweregrad oder höher fallen unter die Behebung.1 Mit anderen Worten: Behandeln Sie den Zeitraum, auf den Sie sich wirklich verlassen können, als ein Jahr bei einem Release-Branch und zwei Jahre bei einem LTS.

Zweitens: In den letzten Jahren wurden keine LTS-Branches mehr geschnitten. Der letzte LTS in der offiziellen Pflegeplan-Tabelle ist 3.0-LTS (September 2021); 3.1, 3.2, 4.0 und 4.1 sind alle vom Typ Release.3 Davor gab es LTS-Versionen — der Release-Notes-Index führt noch 1.1.0 LTS (April 2021) und dessen Serie —, aber alle davon sind End of Life.4 Zudem sind die 5.x- und 6.x-Linien in dieser Pflegeplan-Tabelle noch nicht aufgeführt. Gegen die Prämisse einer zehnjährigen Gerätelebensdauer läuft das auf eine anhaltende Situation hinaus, in der sich „wie viel Pflege welcher Branch erhält“ nicht Release für Release ablesen lässt.

Windows 11 IoT Enterprise LTSC 2024 unterliegt dagegen der Fixed Lifecycle Policy mit einem von Anfang an feststehenden Enddatum am 10. Oktober 2034.2 Auch Debian veröffentlicht die Standard-Support- und LTS-Zeiträume je Release, und das Yocto Project erklärt ausdrücklich, dass es LTS-Releases vier Jahre lang unterstützt.1112

Das ist keine Aussage, dass die Qualität von OpenHarmony niedrig wäre. Es bedeutet lediglich, dass dieses Pflegemodell nicht vorsieht, „die Community-Version direkt in ein Produkt einzubauen und dabei zu belassen“. Bei realem industriellem Einsatz pflegt der Anbieter einer kommerziellen Distribution seinen eigenen Branch und bietet diese Pflege kommerziell an. Was Sie bei der Einsatzbewertung prüfen sollten, ist nicht „wie viele Jahre wird OpenHarmony unterstützt?“, sondern „welchen Branch pflegt der Anbieter dieser Distribution, bis wann, und unter welchem SLA?“

4. Hardware-Optionen

Die Community veröffentlicht Unterstützung für 22 Entwicklungsboards.13 Herausgegriffen die Boards, die für Anlagen relevant sein dürften, ergibt sich Folgendes.

Systemtyp Board SoC Vorgesehene Verwendung laut Dokumentation
Standard HiHope HH-SCDAYU200 Rockchip RK3568 NVRs, Industrie-Gateways, Haushaltsgeräte
Standard MILOS_Standard0 NXP i.MX8M Mini Hochleistungsmessgeräte für Industrie und Gesundheitswesen, Industriesteuerung und HMI, Transportwesen, Katastrophenschutz, Gebäude
Standard Yangfan Rockchip RK3399 Digital Signage, unbemannte Terminals, industrielle Steuerungsrechner, Robotik
Standard ZLG-Entwicklungsboard Allwinner T507 Industriesteuerung, Smart Cockpits, Smart Power
Standard Unionpi Tiger Amlogic A311D Industriesteuerung, KI-Edge-Computing
Klein BearPi-HM Micro ST STM32MP157A Smart Home, Zentralsteuertafeln
Mini Niobe407 ST STM32F407IGT6 Smart Transport, Industriesteuerung
Mini HPM6750EVK2 HPMicro HPM6700 (RISC-V) Industriesteuerung, Edge-Computing

Wichtig ist, dass die SoC-Hersteller nicht ausschließlich chinesisch sind. Die Tatsache, dass der NXP i.MX8M Mini und die STM32-Serie von ST auf der Liste der unterstützten Boards stehen, hat für einen japanischen Gerätehersteller reale Bedeutung, weil es möglich sein könnte, auf einer SoC-Familie zu evaluieren, mit der bereits eine Erfolgsbilanz besteht.

Die Vorbehalte sind jedoch ebenso substanziell.

  • Die Liste unterstützter Boards und die tatsächlich käuflichen Industrieboards sind zwei verschiedene Dinge. Was hier aufgeführt ist, sind größtenteils Evaluierungsboards; ob OpenHarmony auf einem Industrieboard mit zehnjähriger Liefergarantie offiziell unterstützt wird, muss separat geprüft werden.
  • Setzen Sie es auf eigener Hardware ein, ist die Portierung Ihre Aufgabe. Wo Sie bei Windows IoT „die Lizenz über einen OEM-Distributor kaufen und sich die Treiber vom Hersteller liefern lassen“ würden, wird das bei OpenHarmony zur Aufgabe für Sie oder Ihren Distributor.
  • Wie Treiber gehandhabt werden, hängt davon ab, „von wo aus Sie sie verwenden“. OpenHarmony besitzt mit HDF (Hardware Driver Foundation) ein einheitliches Treiberfundament, das plattformunabhängig und kernelunabhängig konzipiert ist und für alle Systemtypen gilt.9 Da der Kernel des Standard-Systems jedoch Linux ist, lässt sich ein vorhandener Linux-Kernel-Treiber durchaus unverändert einbauen und über die gewöhnlichen Linux-Schnittstellen wie V4L2 oder Eingabegeräte verwenden. Anpassungsarbeit wird erst nötig, wenn dieses Gerät über HDI von OpenHarmonys Systemdiensten und Frameworks behandelt werden soll. Haben Sie bereits ein Linux-BSP, müssen Sie nicht „alle Treiber in HDF neu schreiben“ veranschlagen. Entscheiden Sie zuerst, welche Geräte Sie den Frameworks von OpenHarmony aussetzen möchten, und nehmen Sie nur diesen Umfang in Ihre Aufwandsschätzung auf.

5. Entwicklungsumgebung und Sprachen — Lassen sich vorhandene Bestände mitnehmen?

Punkt Windows IoT Enterprise LTSC Embedded Linux OpenHarmony
Build-System MSBuild / Visual Studio Make / CMake / BitBake (Yocto) GN + Ninja9
Hauptsprachen C#, C++, VB C, C++, Python, Rust ArkTS (eine TypeScript-Erweiterung), C, C++
UI-Framework WPF, WinForms, WinUI Qt, GTK, Flutter und Ähnliches ArkUI
Treiber WDM / WDF Linux-Kernel-Treiber HDF
IDE Visual Studio Frei wählbar DevEco Device Tool (Kombination aus Windows und Ubuntu) oder die CLI14
Deutsche Dokumentation Ja Reichlich Keine (nur Chinesisch und Englisch)8

Betrachtet man das aus Sicht der Gerätesoftwarebestände, ist die Sache einfach. Für Windows geschriebene Gerätesoftware lässt sich nicht auf OpenHarmony mitnehmen. Es gibt keine entsprechende Laufzeitumgebung für C#/.NET, Win32, COM oder WPF. Die Oberfläche wird in ArkTS und ArkUI neu geschrieben, die darunterliegenden Schichten in C/C++.

Ein noch praktischeres Hindernis ist der Stand der Hersteller-SDK-Unterstützung. SDKs für Industriekameras, Bibliotheken für Bewegungssteuerungen, Middleware für PLC-Kommunikation, Bildverarbeitungsbibliotheken — die meisten davon sind Windows-first, und Sie haben Glück, wenn ein Linux-Build angeboten wird. Unterstützung für OpenHarmony ist nicht zu erwarten. Deshalb gilt:

Erstellen Sie vor jedem Betriebssystemvergleich eine Liste der von der Anlage benötigten Peripheriegeräte und Middleware und prüfen Sie für jedes Element den OpenHarmony-Unterstützungsstatus.

Argumentieren Sie ohne das aus einer Betriebssystemvergleichstabelle heraus, werden Sie später im Projekt garantiert ins Stolpern geraten. Übernehmen wir Beratungsaufträge zu Gerätesoftware, beginnen wir genau mit dem Erstellen dieser Liste.

Es gibt zwei Einstiegspunkte für die Entwicklungsumgebung: das GUI-basierte DevEco Device Tool (eine kombinierte Einrichtung, bei der Sie Code auf Windows bearbeiten, debuggen und flashen und auf Ubuntu kompilieren) sowie ein CLI-basiertes Verfahren.14 Der Quellcode wird mit dem repo-Tool bezogen, mit Spiegeln auf gitcode.com, gitee.com und GitHub.15

6. Lizenzierung und geistiges Eigentum

OpenHarmony ist keine einzelne Lizenz. Jeder Bereich, den Sie einbinden, muss geprüft werden.

Gegenstand Lizenz Praktischer Hinweis
Viele Komponenten (Build-System, ArkUI-Engine und Ähnliches) Apache License 2.016 Einhaltung der Urheberrechts- und Patentklauseln sowie Angabe eigener Änderungen
Der LiteOS-A-Kernel BSD-3-Clause17 Der Urheberrechtshinweis sowie die Wiedergabe des Haftungsausschlusses bei Binärverteilungen
Der Linux-Kernel-Anteil des Standard-Systems GPLv2 (die Lizenz des Linux-Kernels selbst) Wenn Sie das Gerät an einen Kunden ausliefern, entsteht die Pflicht, dem Empfänger den zu den verteilten Binärdateien gehörigen Quellcode (einschließlich Ihrer Änderungen) bereitzustellen. Rein intern verbleibende Änderungen begründen keine Bereitstellungspflicht
Offizielle Dokumentation CC BY 4.018 Namensnennung bei Zitaten

Es mit „OpenHarmony ist Apache 2.0, also passt es“ zusammenzufassen, führt dazu, dass Sie die GPL-Verpflichtungen im Kernel-Anteil des Standard-Systems übersehen. Das Prinzip ist, die Repositorys im Umfang, den Sie ins Gerät einbauen, aufzulisten und deren LICENSE-Dateien einzeln zu prüfen. Das ist ein praktischer Unterschied zu Windows IoT (wo eine einzige kommerzielle Lizenz alles abdeckt).

Eine Klarstellung zu GPLv2. Die Pflicht entsteht im Moment der Verteilung, nicht im Moment der Änderung. Ändern Sie nur den Kernel und lassen ihn auf einem internen Testrechner laufen, entsteht keine Bereitstellungspflicht; sie entsteht, sobald Sie dieses Gerät an einen Kunden liefern, und dann müssen Sie dem Empfänger den zu den verteilten Binärdateien gehörigen Quellcode bereitstellen. Für einen Gerätehersteller bedeutet „Lieferung = Verteilung“, sodass Sie sich damit letztlich befassen müssen — behalten Sie aber die Unterscheidung im Kopf, dass ab der internen Prototyping-Phase keine Offenlegungspflicht besteht (klären Sie die konkreten Mittel zur Einhaltung mit Ihrer eigenen Rechts- und IP-Abteilung).

7. Zertifizierung und Teilnahme am Ökosystem

Um öffentlich zu beanspruchen, dass ein Produkt „OpenHarmony-kompatibel“ ist, müssen Sie die Kompatibilitätsprüfung der OpenAtom Foundation bestehen. Die technische Grundlage ist OpenHarmonys XTS (X Test Suite), die die offizielle Dokumentation als „eine Reihe von OpenHarmony-Kompatibilitätstestsuiten, einschließlich der derzeit unterstützten Anwendungskompatibilitätstestsuite (ACTS) und der künftig zu unterstützenden Gerätekompatibilitätstestsuite (DCTS)“ beschreibt.9 Mit anderen Worten: Laut Darstellung der offiziellen Dokumentation (Stand Juli 2026) wird derzeit ACTS bereitgestellt, und DCTS soll künftig bereitgestellt werden.

Community-Material zum Zertifizierungsverfahren beschreibt XTS dagegen als dreiteilige Struktur aus ACTS, HATS (Hardware Abstraction Layer Compatibility) und DCTS, was der Beschreibung der offiziellen Dokumentation widerspricht.19 Der Ablauf selbst — der Antragsteller führt intern Anpassungsentwicklung und Selbsttests durch und stellt mit beigefügtem Testbericht einen Antrag — ist bei beiden gleich.

Legen Sie bei der Aufwandsschätzung DCTS nicht als zwingende Anforderung fest. Welche Suiten zum Zeitpunkt der Antragstellung tatsächlich benötigt werden, klären Sie am besten direkt beim Zertifizierungsschalter. Diese Art von Situation, in der „die offizielle Dokumentation und das Community-Material nicht übereinstimmen“, sollten Sie neben dem Fehlen japanischsprachiger Primärinformationen als Kommunikationskosten des Einsatzes einkalkulieren.

Für die reine interne Verifikation oder ein einmaliges Gerät ist keine Zertifizierung nötig, aber für ein Produkt, das öffentlich Kompatibilität beansprucht, oder ein Produkt, das als Mitglied des Ökosystems behandelt werden soll, wird sie zur Voraussetzung. Das ist ein Punkt, den Sie von Anfang an in Ihre Aufwandsschätzung einbauen sollten.

8. Entscheidungstabelle — Wann einsetzen, wann verzichten

Situation Empfehlung Begründung
Ein mit HMI ausgestatteter PC, eingebaut in ein Gerät mit zehnjähriger Betriebsdauer, mit vorhandenen Windows-Beständen Windows 11 IoT Enterprise LTSC 2024 Zehn Jahre Support bis Oktober 2034. Keine Funktionsupdates. Vorhandene Gerätesoftware und Hersteller-SDKs laufen unverändert2
Ein Gerät mit zehnjähriger Betriebsdauer, Linux-SDKs verfügbar, Linux-Kenntnisse intern vorhanden Kommerziell unterstütztes Embedded Linux Vier Jahre mit Yocto LTS, erweiterbar über einen Langzeitpflegevertrag mit einer kommerziellen Distribution12
Ein Produkt für den chinesischen Markt, bei dem die Anforderung „muss OpenHarmony-kompatibel sein“ lautet OpenHarmony (über eine kommerzielle Distribution) Die Marktanforderung bestimmt das Betriebssystem. Beschaffen Sie es mit einbezogener Herstellerpflege
Der Kunde verlangt Teilnahme am HarmonyOS-Ökosystem (AppGallery-Vertrieb, Zusammenspiel mit HarmonyOS-Apps) OpenHarmony kann die Anforderung nicht erfüllen Weder AppGallery noch HMS noch das HarmonyOS SDK sind in OpenHarmony enthalten, und auch die Kompatibilität mit HarmonyOS-Apps ist nicht garantiert. Sie müssen ein HarmonyOS-unterstützendes Produkt und das HarmonyOS SDK wählen
Die Zusammenarbeit zwischen mehreren Geräten (Geräteerkennung, Datensynchronisierung, App-Migration) ist zentral für den Produktwert OpenHarmony DSoftBus, verteilte Datenverwaltung und der verteilte Scheduler sind standardmäßig enthalten9
Sie möchten eine einzige Familie, die die Produktlinie von MCU bis leistungsfähigem Gerät abdeckt OpenHarmony (erwägenswert) Deckt 128 KiB bis 128 MiB und mehr innerhalb einer Familie ab6
Sensorknoten und Kommunikationsmodule (MCU, im Bereich einiger hundert KiB) OpenHarmony-Mini-System oder ein RTOS Windows IoT ist außer Reichweite (mindestens 2 GB)7
Sie möchten vertraglich zehn Jahre Pflege garantiert haben und haben intern niemanden, der technische Dokumente auf Chinesisch oder Englisch lesen kann Verzicht Community-Pflege beträgt maximal 3,5 Jahre, und es gibt weder japanische Dokumentation noch japanischen First-Level-Support18
Anlagen, die von Hersteller-SDKs für Industriekameras, Bewegungssteuerungen und Ähnliches abhängen Verzicht (zuerst prüfen) OpenHarmony-Unterstützung durch SDK-Hersteller ist kaum zu erwarten
Sie möchten vorhandene C#/.NET- und COM-Bestände nutzen Verzicht Es gibt keine entsprechende Laufzeitumgebung; es wird eine Neuentwicklung
Ihre Beschaffungsvorgabe betrifft „die Governance und Trägerschaft des Projekts“ Erwägen Sie die Eclipse-Oniro-Linie Oniro untersteht der Governance einer europäischen Stiftung. Allerdings ist es Stand Juli 2026 Incubating, und seine Community ist bei Weitem nicht so groß wie die des eigentlichen OpenHarmony
Ihre Beschaffungsvorgabe betrifft „keinen Code chinesischen Ursprungs“ Verzicht Auch Oniro baut auf der Basisschicht von OpenHarmony auf, sodass selbst unter europäischer Stiftungs-Governance die Vorgabe zur Code-Herkunft nicht gelöst ist

9. Was zuerst zu tun ist, wenn Sie es einsetzen

Zeigt die Entscheidungstabelle auf „einsetzen“, sieht die Arbeitsreihenfolge wie folgt aus.

  1. Bestandsaufnahme von Peripheriegeräten und Middleware. Kameras, I/O, Kommunikation, Bewegungssteuerung, Bildverarbeitung — prüfen Sie für jeden Hersteller, ob OpenHarmony unterstützt wird. Bleiben Sie hier hängen, hat es keinen Sinn, mit den übrigen Schritten fortzufahren.
  2. Legen Sie den Systemtyp fest. Entscheiden Sie, ob Sie auf dem Mini-, kleinen oder Standard-System aufbauen. Das bestimmt den Kernel (LiteOS-M / LiteOS-A / Linux) und wie Sie die Apps schreiben.
  3. Prüfen Sie die Struktur unter QEMU. Bevor Sie echte Hardware kaufen, können Sie den Build- und Boot-Ablauf in den Emulationsumgebungen bestätigen, die device_qemu für Arm Virt (LiteOS-A / Linux), Cortex-M4, Cortex-M55, RISC-V und andere bereitstellt.20
  4. Legen Sie den Pflege-Branch fest und sichern Sie die Build-Reproduzierbarkeit. Fixieren Sie das repo-Manifest (die Angabe eines Tags ist der zuverlässige Weg), führen Sie einen internen Spiegel und erreichen Sie einen Zustand, in dem Sie in fünf Jahren dieselben Binärdateien erneut erzeugen können.15 Die Tatsache, dass das Upstream-Hosting sich auf gitcode.com konzentriert, ist aus Sicht der Geschäftskontinuität an sich schon ein Grund, einen eigenen Spiegel zu führen.
  5. Machen Sie eine Bestandsaufnahme der Lizenzen. Listen Sie die Repositorys im Umfang auf, den Sie einbinden, und arbeiten Sie die Apache-2.0-/BSD-/GPL-Verpflichtungen durch.
  6. Verhandeln Sie einen Pflegevertrag. Legen Sie mit dem Anbieter der kommerziellen Distribution vertraglich fest, „welcher Branch, bis wann, unter welchem SLA“. Lässt sich das nicht klären, sollte die Einsatzentscheidung zurückgestellt werden.
  7. Entscheiden Sie, ob die Kompatibilitätsprüfung (XTS) erforderlich ist. Möchten Sie öffentlich Kompatibilität beanspruchen, bauen Sie den Aufwand von Anfang an ein.

10. Zusammenfassung

  • Technisch ist OpenHarmony ein stimmiges Design: Es deckt innerhalb einer Familie alles ab, von einer 128-KiB-MCU bis zu leistungsfähigen Geräten mit 128 MiB und mehr, und besitzt Gerätezusammenarbeit (DSoftBus) standardmäßig. Es gibt für den industriellen Einsatz vorgesehene unterstützte Boards, darunter SoCs von NXP und ST.
  • Andererseits ist aus Sicht einer zehnjährigen Gerätelebensdauer das Community-Pflegefenster (zwei Jahre für Release, 3,5 für LTS) eindeutig unzureichend. Und seit 3.0-LTS im Jahr 2021 wurde kein LTS-Branch mehr geschnitten. Der Einsatz setzt Herstellerpflege einer kommerziellen Distribution voraus.
  • Für einen japanischen Gerätehersteller gibt es drei praktische Einsatzvoraussetzungen: (1) unterstützen die Hersteller-SDKs OpenHarmony, (2) haben Sie Personen, die technische Dokumente auf Chinesisch oder Englisch durchgängig lesen können, und (3) gibt es einen Anbieter, mit dem Sie die Pflege vertraglich festlegen können? Fehlt auch nur eines davon, passt Windows IoT Enterprise LTSC oder kommerziell unterstütztes Embedded Linux besser zur Zeitachse des Geräts.
  • Umgekehrt lohnt es sich, für Produkte, die auf den chinesischen Markt zielen, für Produkte, bei denen Gerätezusammenarbeit zentral für den Wert ist, sowie für Produktlinien, die Sie innerhalb einer Familie von MCU bis leistungsfähigem Gerät abdecken möchten, es direkt in Erwägung zu ziehen.

Die Betriebssystemwahl ist keine Frage von „was ist überlegen“, sondern von „was passt zur Zeitachse, Beschaffung und Personalausstattung des Geräts“. Unsere Kriterien für die Auswahl auf der Windows-Seite sind in „Welches Windows sollten Sie auf einem Industrie-PC installieren?“ dargelegt.

Verwandte Artikel

Verwandte Beratungsleistungen

Die KomuraSoft LLC unterstützt bei der Auswahl der in Anlagen einzubauenden Laufzeitplattform, bei der Einschätzung, ob sich bestehende Windows-Gerätesoftware migrieren lässt, sowie bei der Überprüfung von Konfigurationen, die für einen langfristigen Betrieb gedacht sind. Sie sind auch dann bei uns willkommen, wenn „ein neues Betriebssystem als Kandidat aufgetaucht ist, aber intern nichts vorhanden ist, um es zu vergleichen“.

  1. OpenHarmony, OpenHarmony Version Lifecycle Management. Dazu, dass der Lebenszyklus eines Release-Branch zwei Jahre (ein Jahr aktive Pflege plus ein Jahr passive Pflege) und eines LTS-Branch 3,5 Jahre (zwei Jahre plus 1,5) beträgt, sowie dazu, dass in der passiven Pflegephase keine getaggten Versionen geplant oder veröffentlicht werden und nur Sicherheitslücken und Fehler mit kritischem Schweregrad oder höher behoben werden. ↩ ↩2 ↩3 ↩4 ↩5

  2. Microsoft Learn, Windows 11 IoT Enterprise LTSC 2024 - Microsoft Lifecycle. Zum Startdatum 1. Oktober 2024 und dem Ende des erweiterten Supports am 10. Oktober 2034 (insgesamt zehn Jahre). ↩ ↩2 ↩3 ↩4

  3. OpenHarmony-Dokumentation, OpenHarmony Version Definitions. Zur Pflegeplan-Tabelle für die LTS- und Release-Branches (dass der einzige LTS in dieser Tabelle 3.0-LTS ist, dass 1.0.1, 3.1, 3.2, 4.0 und 4.1 vom Typ Release sind, dass die Pflege von 4.1-Release am 30. März 2026 endete, und dass die 5.x- und 6.x-Linien in der Tabelle noch nicht aufgeführt sind). ↩ ↩2 ↩3 ↩4

  4. OpenHarmony-Dokumentation, Release Notes index. Dazu, dass 3.0-LTS (30. September 2021) und dessen Serie geführt werden und alles ab 3.1 vom Typ Release ist; dazu, dass in der 1.x-Linie ebenfalls LTS-Versionen existierten (1.1.0 LTS und andere), diese aber als End of Life markiert sind; sowie dazu, dass 6.1 Release (8. März 2026) geführt wird. ↩ ↩2

  5. Huawei, HarmonyOS 7 开发者Beta 正式启动，全场景智能操作系统再升级. Zur Aussage auf der HDC 2026 am 12. Juni 2026, dass OpenHarmony mehr als 100 kommerzielle Versionen veröffentlicht hat. ↩

  6. OpenHarmony-Dokumentation, Quick Start Overview. Zu den Definitionen und Zielprodukten der drei Systemtypen — Mini-System (MCU, mindestens 128 KiB), kleines System (Cortex-A, mindestens 1 MiB) und Standard-System (Cortex-A, mindestens 128 MiB). ↩ ↩2 ↩3

  7. Microsoft Learn, Minimum System Requirements - Windows IoT Enterprise. Dazu, dass die OPTIONALEN Mindestanforderungen für Spezialgeräte mit 2 GB Speicher und 16 GB Speicherplatz definiert sind. ↩ ↩2

  8. OpenHarmony-Dokumentation, README. Dazu, dass die offizielle Dokumentation in zwei Sprachen bereitgestellt wird, Chinesisch (zh-cn) und Englisch (en), ohne japanische Version, sowie zur Zuordnung jeder Version zu ihrer API-Ebene. ↩ ↩2 ↩3

  9. OpenHarmony-Dokumentation, OpenHarmony Project. Zur vierschichtigen Architektur und zum Multi-Kernel-Design mit Linux und LiteOS; zum einheitlichen Treiberfundament, das HDF (Hardware Driver Foundation) bereitstellt; zu DSoftBus, verteilter Datenverwaltung und dem verteilten Scheduler; dazu, dass das Build-System GN + Ninja ist; sowie dazu, dass XTS eine Reihe von Kompatibilitätstestsuiten ist, beschrieben als „die derzeit unterstützte Anwendungskompatibilitätstestsuite (ACTS) und die künftig zu unterstützende Gerätekompatibilitätstestsuite (DCTS)“. ↩ ↩2 ↩3 ↩4 ↩5

  10. Microsoft Learn, Windows 10 IoT Enterprise LTSC 2021 - Microsoft Lifecycle. Zum Ende des erweiterten Supports am 13. Januar 2032. ↩

  11. Debian Wiki, LTS. Dazu, dass Debian LTS ein Projekt ist, das die Lebensdauer jedes Stable-Release auf mindestens fünf Jahre verlängert, sowie dazu, dass der LTS-Zeitraum für Debian 12 bookworm vom 11. Juni 2026 bis 30. Juni 2028 läuft. ↩ ↩2

  12. Yocto Project Wiki, Releases. Zur Richtlinie, LTS-Releases vier Jahre lang zu unterstützen, sowie dazu, dass 5.0 Scarthgap im April 2024 veröffentlicht und bis April 2028 unterstützt wird, und 6.0 Wrynose im April 2026 veröffentlicht und bis April 2030 unterstützt wird. ↩ ↩2 ↩3

  13. OpenHarmony-Dokumentation, OpenHarmony Development Boards List. Dazu, dass es 22 von der Community unterstützte Entwicklungsboards gibt, sowie zum SoC und den vorgesehenen Verwendungszwecken jedes Boards (etwa listet der NXP i.MX8M Mini des MILOS_Standard0 Messgeräte für Industrie und Gesundheitswesen sowie Industriesteuerung und HMI, und der STM32F407 des Niobe407 listet unter anderem Industriesteuerung). ↩

  14. OpenHarmony-Dokumentation, Quick Start Overview. Dazu, dass zwei Einstiegspunkte für die Geräteentwicklung bereitgestellt werden: ein IDE-Modus mit DevEco Device Tool (eine Hybrideinrichtung mit Codeentwicklung, Debugging und Flashen auf Windows sowie Quellcode-Kompilierung auf Ubuntu) und ein CLI-Modus. ↩ ↩2

  15. OpenHarmony-Dokumentation, Source Code Acquisition. Zum Verfahren, den Quellcode mit dem repo-Tool zu beziehen, zu den Spiegeln gitcode.com, gitee.com und GitHub sowie dazu, wie man einen Branch oder einen Tag angibt. ↩ ↩2

  16. OpenHarmony, arkui_ace_engine LICENSE und build LICENSE. Dazu, dass die Repositorys der ArkUI-Engine und des Build-Systems unter der Apache License 2.0 vertrieben werden. ↩

  17. OpenHarmony, kernel_liteos_a LICENSE. Dazu, dass der LiteOS-A-Kernel unter der BSD-3-Clause-Lizenz vertrieben wird. ↩

  18. OpenHarmony, docs LICENSE. Dazu, dass das Repository der offiziellen Dokumentation unter Creative Commons Attribution 4.0 International bereitgestellt wird. ↩

  19. OpenAtom-Foundation-Community-Material, OpenHarmony-XTS认证流程 (Sekundärquelle). Dazu, dass Community-Material zum Zertifizierungsverfahren XTS als dreiteilige Struktur aus ACTS (Anwendungskompatibilität), HATS (Hardware Abstraction Layer Compatibility) und DCTS beschreibt, sowie zum Ablauf, bei dem der Antragsteller ein Firmenkonto erhält, intern Anpassungsentwicklung und Selbsttests durchführt und mit beigefügtem Testbericht und PCS-Selbstprüfungsbogen einen Antrag stellt. Die Positionierung von DCTS widerspricht der offiziellen Dokumentation („die künftig zu unterstützende Gerätekompatibilitätstestsuite“), und der Fließtext macht diese Diskrepanz ausdrücklich. ↩

  20. OpenHarmony, device_qemu README. Dazu, dass Verfahren für die QEMU-Emulation von Arm Virt (LiteOS-A), Arm Virt (Linux), Cortex-M4 (mps2-an386), Cortex-M55 (mps3-an547), RISC-V (riscv32_virt), Xtensa (esp32) und C-SKY (SmartL_E802) bereitgestellt werden. ↩

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Ist es sicher, OpenHarmony als Betriebssystem für Industrieanlagen einzusetzen?
Das hängt von den Rahmenbedingungen ab. Entscheidend ist, wie Sie mit dem Pflegefenster umgehen: Die Release-Branches der OpenHarmony-Community haben einen zweijährigen Lebenszyklus (ein Jahr aktive Pflege plus ein Jahr passive Pflege), und selbst LTS-Branches nur 3,5 Jahre. Bauen Sie die Community-Version unverändert in ein zehn Jahre laufendes Gerät ein, enden Sicherheitskorrekturen mitten in der Produktlebensdauer. Der Einsatz setzt voraus, dass Sie entweder Herstellerpflege einer kommerziellen Distribution kaufen oder intern die Fähigkeit besitzen, einen Branch zu pflegen und CVEs selbst zu behandeln. Lässt sich diese Fähigkeit nicht aufbauen, passt Windows IoT Enterprise LTSC (zehn Jahre) oder ein Langzeitpflegevertrag für kommerzielles Embedded Linux besser zur Zeitachse des Geräts.
Was ist leichter — OpenHarmony oder Embedded Linux?
Die Untergrenze von OpenHarmony liegt niedriger. Das Mini-System von OpenHarmony läuft ab minimal 128 KiB Speicher auf MCUs wie Arm Cortex-M und 32-Bit-RISC-V; das kleine System benötigt mindestens 1 MiB, das Standard-System mindestens 128 MiB. Typisches Embedded Linux setzt einen Prozessor mit MMU und zig MB RAM oder mehr voraus, sodass die Abdeckung des MCU-Bereichs innerhalb derselben Betriebssystemfamilie ein Alleinstellungsmerkmal von OpenHarmony ist. Beachten Sie jedoch, dass der Kernel des Mini-Systems LiteOS-M ist und seine Ausführungsumgebung sich völlig vom Linux des Standard-Systems unterscheidet — „gleiches Betriebssystem, also laufen dieselben Apps“ gilt also nicht.
Kann ich vorhandene Windows-Gerätesoftware auf OpenHarmony portieren?
In der Praxis handelt es sich um eine Neuentwicklung. Für mit C#/.NET, Win32, COM oder WPF/WinForms geschriebene Gerätesoftware gibt es auf OpenHarmony keine entsprechende Laufzeitumgebung. Sie würden sie mit einem anderen Technologiestapel neu schreiben: ArkTS plus ArkUI für die Oberfläche, darunter C/C++, und HDF (Hardware Driver Foundation) für Treiber. Hinzu kommt, dass Hersteller-SDKs für Industriekameras und Bewegungssteuerungen oft nur für Windows (und dann für Linux) bereitgestellt werden, und genau dort liegt der eigentliche Engpass für die Portierung. Ist Ihre Prämisse, vorhandene Bestände zu nutzen, ist ein Wechsel zu Windows IoT Enterprise LTSC oder Embedded Linux, beschränkt auf Geräte, für die ein Linux-SDK bereitgestellt wird, realistischer.
Brauche ich eine Zertifizierung, um OpenHarmony-Unterstützung zu beanspruchen?
Um ein Produkt „OpenHarmony-kompatibel“ zu nennen, müssen Sie die Kompatibilitätsprüfung (Zertifizierung) der OpenAtom Foundation bestehen. Die technische Grundlage dafür ist die XTS-Testsuite-Familie (X Test Suite) von OpenHarmony. Die Aufschlüsselung wird jedoch von verschiedenen Quellen unterschiedlich beschrieben: Stand Juli 2026 spricht die offizielle Dokumentation von „der derzeit unterstützten ACTS (Application Compatibility Test Suite) und der künftig zu unterstützenden DCTS (Device Compatibility Test Suite)“, während Community-Material zum Zertifizierungsverfahren eine Struktur beschreibt, die diesen HATS (Hardware Abstraction Layer Compatibility) hinzufügt. Legen Sie DCTS bei der Aufwandsschätzung nicht als zwingende Anforderung fest — klären Sie beim Zertifizierungsschalter, welche Suiten zum Zeitpunkt Ihrer Antragstellung tatsächlich benötigt werden. Für die reine interne Verifikation ist keine Zertifizierung nötig, aber für ein Produkt, das öffentlich Kompatibilität beansprucht, wird sie notwendig.
Wie viel Unterstützung und Information gibt es auf Japanisch?
Die offizielle Dokumentation liegt in zwei Sprachen vor, Chinesisch und Englisch; eine japanische Version gibt es nicht. Auch die Community-Diskussion findet größtenteils auf Chinesisch statt. Anbieter kommerzieller Distributionen sind größtenteils ebenfalls chinesische Unternehmen, und die Zahl der Stellen, an denen Sie First-Level-Support auf Japanisch erhalten, ist begrenzt. Faktisch ist es daher eine praktische Voraussetzung für den Einsatz, intern Personen zu haben, die technische Dokumente auf Chinesisch oder Englisch durchgängig lesen können. Das ist ein klarer Unterschied zu Windows und den großen Linux-Distributionen.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.

Kontakt
Zurück zum Blog