האם OpenHarmony היא מערכת הפעלה ריאלית לציוד תעשייתי? — השוואה ל-Windows IoT ול-Embedded Linux
· עודכן בתאריך: · Go Komura · OpenHarmony, מערכות משובצות, בחירת מערכת הפעלה, תוכנה משובצת לציוד, Windows IoT, Linux, ייצור, ייעוץ טכני
האם OpenHarmony נכנסת לרשימת המועמדים למערכת ההפעלה של הציוד שלכם נקבע לפי תחזוקה, SDK ואנשי פיתוח — לפני שנקבע לפי מספר הפיצ’רים. אי אפשר להטמיע גרסה שהתחזוקה הקהילתית שלה נגמרת בעוד שנתיים בהתקן שצריך לפעול עשר שנים. ואם ה-SDK של המצלמה שצריך קיים רק ל-Windows, גם קונפיגורציה שמשתמשת במצלמה הזאת לא מחזיקה מעמד.
המאמר הזה משווה, עבור יצרני ציוד, בין Windows IoT Enterprise LTSC, Embedded Linux (מבוסס Debian או Yocto) ו-OpenHarmony. קודם כול הוא מעמיד את המועמדים על אותו בסיס, ואחר כך בודק לפי הסדר הזה: האם מערכת ההפעלה יכולה לתמוך במשך החיים של המוצר, האם אפשר להעביר אליה נכסים קיימים, והאם אפשר להגיע עד ייצור סדרתי ומשלוח. בסוף הוא מסכם בטבלת החלטה את התנאים שבהם מותר לאמץ אותה ואת התנאים שבהם כדאי לוותר.
תוכנת הציוד שאנחנו עוסקים בה בדרך כלל היא ל-Windows, אבל זה לא מאמר שממליץ על OpenHarmony או פוסל אותה באופן גורף. ההכרעה היא לא “זו טכנולוגיה חדשה” או “זה מגיע מסין”, אלא אם היא מתאימה לציר הזמן, לרכש ולכוח האדם של ההתקן. על ההבדלים בין OpenHarmony, HarmonyOS ו-HarmonyOS NEXT עצמם אפשר לקרוא במאמר הקודם, “מהי OpenHarmony”.
המידע הטכני ולוחות הזמנים של התחזוקה שמושווים כאן הם נכון ליולי 2026. תקופות תמיכה, לוחות נתמכים ודרישות הסמכה משתנים, ולכן יש לבדוק במקורות הראשוניים ובספקים את הגרסה ואת המוצרים שאתם מאמצים ממש לפני ההחלטה.
1. קודם המסקנה: להפריד בין תנאי האימוץ לבין הסיבות לבחור בה
החוזקות של OpenHarmony הן שהיא מגיעה גם להתקנים קטנים מאוד ושהיא מטפלת בשיתוף פעולה בין כמה התקנים במנגנונים סטנדרטיים. מנגד, יש אילוצים ברורים בכל הנוגע לנכסי Windows קיימים, ל-SDK של ספקים תעשייתיים ולמידע ראשוני ביפנית.123
אימוץ מחייב את שלושת התנאים שלמטה. אם אחד מהם לא מתקיים, יש לתת עדיפות ל-Windows IoT Enterprise LTSC או ל-Embedded Linux עם תמיכה מסחרית. ומנגד, עמידה בשלושתם לא מספיקה כדי להכריע בעד אימוץ OpenHarmony. צריך לבדוק גם שהחוזקות של OpenHarmony מתאימות לדרישות המוצר וגם שאפשר לפתח ולתחזק את המוצר הזה.
| מה לבדוק קודם | התנאי שנדרש לאימוץ | פירוט |
|---|---|---|
| האם יש תחזוקה שמכסה את חיי ההתקן? | תחזוקה מספק של הפצה מסחרית, או יכולת פנימית לתחזק ענף ולטפל ב-CVE | סעיף 3 |
| אפשר להשתמש בהתקנים ההיקפיים ובמידלוור? | קיימים SDK של OpenHarmony, או שאפשר לבנות בעצמכם את מה שחסר | סעיף 4 |
| אפשר להמשיך לחקור, לפתח ולשאול שאלות? | אנשי צוות שיכולים לקרוא מסמכים טכניים בסינית או באנגלית מהתחלה ועד הסוף | סעיף 4.4 |
flowchart TB
accTitle: להפריד בין תנאי האימוץ לבין התועלת למוצר
accDescr: להפריד בין התועלת שמתאימה לדרישות המוצר לבין התנאים שמאפשרים אותה - תחזוקה, SDK ואנשי צוות - ולהכריע לפי התאמה של שניהם.
requirements["שוק ההתקנים ודרישות המוצר"] --> value["סיבות לבחור ב-OpenHarmony"]
requirements --> conditions["תנאי תחזוקה, SDK ואנשי צוות"]
value --> check["להתאים את שניהם ולהחליט"]
conditions --> check
איור 1: להפריד בין התנאים שגורמים לזה לעבוד לבין הסיבות לבחור בזה.
לקרוא לפי המטרה שלכם
| מה שרוצים להחליט עכשיו | סעיף לקריאה |
|---|---|
| להבין איך שלוש האפשרויות נבדלות | סעיף 2. מוצרי OS מול תשתיות פיתוח, סוגי מערכות וההשוואה הכוללת |
| האם היא יכולה לתמוך בחיי מוצר של כעשר שנים | סעיף 3. מי מתחזק, תאריך הסיום, היקף התיקונים והענף שאימצתם |
| האם היא יכולה לרוץ בקונפיגורציית ההתקן הקיימת שלכם | סעיפים 4 ו-5. לבדוק SDK ואת היקף ההעברה, ולבדוק את תנאי הרכש של הלוח |
| האם אפשר לשלוח אותה כמוצר | סעיף 6. רישיונות, הסמכת תאימות והאקוסיסטם מול מדיניות הרכש |
| רק ההחלטה כן/לא וסדר העבודה | סעיפים 7 ו-8. להתאים את התנאים בטבלת ההחלטה, ואז לעבור לוולידציה ולחוזים |
ההשוואה הכוללת נמצאת בסעיף 2.3 וההמלצות לפי מצב נמצאות בסעיף 7.2. גם בתרחיש שטבלת ההחלטה ממליצה עליו, אי אפשר לדלג על שלושת התנאים שלמעלה.
ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 34, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle
2. להעמיד את המועמדים על אותו בסיס: אי אפשר להשוות לפי שם מערכת ההפעלה בלבד
2.1. איפה עומדות Windows IoT, Debian, Yocto ו-OpenHarmony
הדבר הראשון שצריך ליישר הוא ההבדל בין שימוש במוצר OS מוגמר לבין שימוש בתשתית שעליה בונים מערכת הפעלה למוצר שלכם. ערבוב של השניים גורם לכך שמפספסים את העבודה שהחברה שלכם מקבלת על עצמה כדי להפוך את זה למוצר.
| אפשרות | מה זה בפועל | Kernel | שכבת UI ואפליקציות |
|---|---|---|---|
| Windows 11 IoT Enterprise LTSC | מוצר OS מסחרי של מיקרוסופט | Windows NT | Win32 / WinUI / WPF / WinForms, .NET |
| Embedded Linux (מבוסס Debian) | הפצה (distribution) | Linux | לבחירתכם (Qt, GTK, Wayland compositor וכדומה) |
| Embedded Linux (מבוסס Yocto) | תשתית לבניית הפצה משלכם | Linux | לבחירתכם |
| מערכת ה-Standard של OpenHarmony | פרויקט OS (צריך להפוך אותו להפצה) | Linux | ArkUI, ArkTS, Ability |
| מערכת ה-Small של OpenHarmony | כמו למעלה | LiteOS-A | מסגרת גרפית סטנדרטית |
| מערכת ה-Mini של OpenHarmony | כמו למעלה | LiteOS-M | מסגרת גרפית קלה |
Yocto היא לא מערכת הפעלה מוגמרת. היא תשתית שמחברת recipes (הגדרות של שלבי build) כדי לבנות הפצת Linux למוצר שלכם. LTSC (Long-Term Servicing Channel) הוא מודל התחזוקה של Windows שלא משחרר עדכוני פיצ’רים ומספק עדכוני אבטחה לאורך זמן רב, והוא מתאים לשימושים כמו ציוד שבו רוצים שהקונפיגורציה תישאר קפואה.
גם OpenHarmony היא לא מוצר מוגמר בסגנון “קונים ומתקינים” כמו Windows IoT. המיקום שלה קרוב יותר ל-Yocto: זו אפשרות בצד שבו משתמשים בתשתית כדי לבנות קונפיגורציה למוצר שלכם. בשונה מ-Yocto, לעומת זאת, היא מגיעה עם מסגרת UI ומודל אפליקציות בחבילה אחת, ולכן המערכת מגיעה גם לשכבות העליונות.
flowchart TB
accTitle: מוצרי OS מוגמרים ותשתיות לבניית קונפיגורציה למוצר
accDescr: רכישת מוצר OS מסחרי ובניית קונפיגורציה למוצר משלכם מתשתית של פרויקט הן שתי עבודות שונות.
os["פלטפורמת הרצה להטמעה בהתקן"] --> product["לרכוש מוצר OS מסחרי"]
os --> project["לבחור תשתית פיתוח"]
project --> config["לבנות את הקונפיגורציה למוצר"]
config --> scope["להחליט מה באחריותכם ומה באחריות הספק"]
איור 2: גם בתוך אותה בחירת OS, רכישת מוצר מוגמר והרכבה של קונפיגורציה הן היקפי עבודה שונים.
2.2. לקרוא את רצפת הזיכרון כשסוג המערכת מיושר
ל-OpenHarmony יש שלושה סוגי מערכות: Mini, Small ו-Standard.1
| סוג מערכת | מעבד | זיכרון מינימלי | מוצרי יעד |
|---|---|---|---|
| מערכת Mini | MCU כמו Arm Cortex-M ו-RISC-V 32-ביט | 128 KiB | מודולי קישוריות, חיישנים, מכשירים לבישים |
| מערכת Small | מעבדי אפליקציה כמו Arm Cortex-A | 1 MiB | מצלמות IP, מכשירי אינטרקום, ראוטרים, מצלמות דרך |
| מערכת Standard | מעבדי אפליקציה כמו Arm Cortex-A | 128 MiB | התקנים עם מסך שיש להם מסגרת אפליקציות מלאה |
בציוד עם HMI ההשוואה היא בעיקר מול מערכת ה-Standard; בצמתי חיישנים ובמודולי תקשורת היא מול מערכת ה-Mini. מערכת ה-Small קרובה יותר למוצרי מצלמה.
מול המינימום של 128 KiB במערכת ה-Mini, דרישות המינימום של Windows 11 IoT Enterprise LTSC להתקנים ייעודיים הן 2 GB זיכרון ו-16 GB אחסון. גם Embedded Linux טיפוסי מניח מעבד עם MMU ועשרות MB של RAM ומעלה. העובדה ש-OpenHarmony מכסה גם את תחום ה-MCU באותה משפחה היא הבדל מהותי.14
עם זאת, זה לא אומר שאפליקציות של מערכת ה-Standard רצות ב-128 KiB. מערכת ה-Mini משתמשת ב-LiteOS-M, מערכת ה-Small ב-LiteOS-A ומערכת ה-Standard ב-Linux, ולכן גם ה-kernel וגם סביבת ההרצה שונים. אל תניחו ש”זו אותה OpenHarmony, ולכן אפשר להעביר את אותה אפליקציה”; יש לבחור לפי סוג המערכת שהמוצר צריך.
flowchart TB
accTitle: לקבוע את סביבת ההרצה לפי סוג המערכת
accDescr: לקבוע את סוג המערכת שהמוצר צריך, ואז לבדוק את ה-kernel ואת סביבת ההרצה של האפליקציה, ולא לשפוט תאימות אפליקציות לפי רצפת הזיכרון בלבד.
need["הפונקציות שהמוצר צריך"] --> type["לקבוע את סוג המערכת"]
type --> kernel["לבדוק את ה-kernel ואת סביבת ההרצה"]
kernel --> app["לבנות אפליקציות שמתאימות לסביבה הזאת"]
minimum["נתון הזיכרון המינימלי"] -.-> caution["לא ערובה לתאימות אפליקציות"]
איור 3: רצפת 128 KiB לא אומרת שאפליקציות של מערכת ה-Standard רצות כמו שהן.
2.3. ההשוואה הכוללת: חוזקות ואילוצים על אותם צירים
אחרי יישור המועמדים, הנה שישה צירי הערכה זה לצד זה. הסמלים הם סקאלה בת ארבע דרגות: ◎ = מתאים כמו שזה / ○ = מתאים בתנאים / △ = דורש זהירות / × = לא מתאים. זו טבלה שמסכמת את ההסברים בכל סעיף, ולא דירוג שנכון לכל התקן.
| ציר הערכה | Windows IoT Enterprise LTSC | Embedded Linux (Debian / Yocto) | OpenHarmony | פירוט |
|---|---|---|---|---|
| חלון תחזוקה (מספיק לעשר השנים של ההתקן?) | ◎ עשר שנים קבועות. LTSC 2024 מחזיקה עד אוקטובר 20345 | ○ Debian כחמש שנים, Yocto LTS ארבע שנים. ניתן להאריך בחוזה מסחרי67 | △ הקהילה נותנת ל-Release שנתיים ול-LTS 3.5 שנים. רכישת תחזוקה מספק היא הנחת היסוד8 | סעיף 3 |
| רצפת משאבים (על איזה התקן קטן היא יכולה לרוץ?) | × מינימום 2 GB זיכרון ו-16 GB אחסון4 | △ מניח מעבד עם MMU ו-RAM בסדר גודל של עשרות MB | ◎ מערכת ה-Mini רצה החל מ-MCU עם 128 KiB1 | סעיף 2 |
| SDK של ספקים (מצלמות תעשייתיות, motion, תקשורת PLC) | ◎ הפלטפורמה הראשונה שנתמכת | ○ שמישים במקום שהם מסופקים | × אל תצפו להם מלכתחילה | סעיף 4 |
| שפת פיתוח ומסגרת UI (העברת נכסי Windows קיימים) | ◎ C#/.NET, Win32, COM ו-WPF רצים כמו שהם | × כתיבה מחדש. עם זאת, לוגיקת מדידה ובקרה ב-C/C++ מועברת בקלות | × כתיבה מחדש. ArkTS עם ArkUI, ו-HDF לדרייברים | סעיף 4 |
| מידע ביפנית ותמיכה מקומית | ◎ תיעוד ביפנית, וגם מפיצים ועמדות תמיכה ביפן | ○ שפע של מידע טכני ביפנית | × התיעוד הרשמי הוא בסינית ובאנגלית בלבד3 | סעיף 4 |
| שיתוף פעולה בין התקנים (גילוי התקנים, סנכרון נתונים, העברת אפליקציות) | △ לבנות לבד | △ לבנות לבד | ◎ DSoftBus, ניהול נתונים מבוזר ומתזמן מבוזר הם סטנדרט2 | סעיף 7 |
OpenHarmony מקבלת ◎ בשני צירים: רצפת המשאבים ושיתוף הפעולה בין התקנים. היא מקבלת × בשלושה: נכסים קיימים, SDK ומידע ביפנית. זה לא הופך אותה ל”מערכת הפעלה גרועה”; זה אומר שצריך לבחור מוצרים שתנאי האימוץ שלהם מתאימים לה.
כדאי לשקול אותה במוצרים שמיועדים לשוק הסיני, במוצרים שהערך המרכזי שלהם הוא גילוי התקנים, סנכרון נתונים והעברת אפליקציות, בהתקני IoT עם מסך שמשתמשים ב-ArkUI, ובקווי מוצר שרוצים משפחה אחת שמכסה הכול מ-MCU ועד התקנים עשירים. את ההחלטה כן/לא הקונקרטית אפשר לבדוק מול טבלת ההחלטה בסעיף 7.2
flowchart TB
accTitle: ליישם את טבלת ההשוואה הכוללת על דרישות המוצר
accDescr: לא להחליט על מערכת ההפעלה לפי הדירוגים בטבלת ההשוואה בלבד, אלא ליישם אותם על הערך המרכזי ועל האילוצים של המוצר לפני ההחלטה.
table["לתפוס חוזקות ואילוצים מההשוואה הכוללת"] --> req["ליישם אותם על דרישות המוצר שלכם"]
req --> fit["להתאים SDK, תחזוקה ואנשי צוות"]
fit --> decision["לעבור להחלטה לפי מצב בסעיף 7"]
איור 4: אל תספרו את סמלי הדירוג; תיישמו אותם על התנאים של המוצר שלכם.
3. לסגור את עניין התחזוקה: לבדוק מי עושה אותה, את תאריך הסיום ואת היקף התיקונים
3.1. קודם כול להחליט מי לוקח על עצמו את התחזוקה של המוצר
הנקודה בהשוואת תחזוקה היא לא לדרג את האיכות של OpenHarmony עצמה. הנקודה היא שהטמעה של גרסת הקהילה כמו שהיא במוצר שפועל עשר שנים ואז להשאיר אותו כך לא עובדת.
אם מאמצים אותה, או שקונים תחזוקה מספק של הפצה מסחרית, או שמתחזקים ענף בעצמכם ונושאים בעצמכם באחריות לטיפול ב-CVE. באימוץ תעשייתי ערוץ הרכש בפועל הוא השכבה המסחרית, שבה ספקים מתחזקים forks משלהם ומציעים אותם בתשלום. גם בתדרוך של Huawei ביוני 2026 נאמר ש-OpenHarmony הוציאה יותר מ-100 גרסאות מסחריות.9
לכן השאלה שצריך לשאול היא לא “כמה שנים OpenHarmony נתמכת?” אלא “איזה ענף של ההפצה הזאת מתוחזק, עד מתי, ובאיזה SLA?” אם אי אפשר לקבע את התחזוקה, מחזיקים את החלטת האימוץ גם אם זה עובד מבחינה טכנית.
flowchart TB
accTitle: מי מגשר בין התחזוקה הקהילתית לבין חיי המוצר
accDescr: לא להטמיע את גרסת הקהילה כמו שהיא במוצר שפועל שנים רבות ולהשאיר אותה כך, אלא שהספק או החברה שלכם לוקחים על עצמם את התחזוקה שנדרשת לאורך חיי המוצר.
life["התחזוקה שנדרשת לאורך חיי המוצר"] --> vendor["להתקשר על תחזוקה מספק"]
life --> own["לתחזק את הענף וה-CVE בעצמכם"]
vendor --> terms["לקבע את ה-fork, תאריך הסיום וה-SLA"]
own --> terms
terms --> adopt["לסגור את הנחות היסוד להחלטת האימוץ"]
איור 5: לשאול לא על מספר השנים של מערכת ההפעלה כולה, אלא על ה-fork שרוכשים ועל תנאי התחזוקה שלו.
3.2. להסתכל על תאריך הסיום ולא על סך השנים
מחשבים ולוחות שמוטמעים בציוד אמורים להמשיך לפעול במחזור חיים דומה של כעשר שנים כמו הציוד עצמו. יש להשוות את התחזוקה של כל מערכת הפעלה בציר הזמן הזה.
| אפשרות | תקופת תמיכה | דוגמה | מקור |
|---|---|---|---|
| Windows 11 IoT Enterprise LTSC 2024 | 10 שנים | מתחיל ב-1 באוקטובר 2024, נגמר ב-10 באוקטובר 2034 | 5 |
| Windows 10 IoT Enterprise LTSC 2021 | 10 שנים | נגמר ב-13 בינואר 2032 | 10 |
| Debian (כולל LTS) | כחמש שנים | תקופת ה-LTS של Debian 12 bookworm נמשכת מ-11 ביוני 2026 עד 30 ביוני 2028 | 6 |
| Yocto Project LTS | 4 שנים | 5.0 Scarthgap נמשך מאפריל 2024 עד אפריל 2028, ו-6.0 Wrynose מאפריל 2026 עד אפריל 2030 | 7 |
| ענף LTS של OpenHarmony | 3.5 שנים (2 + 1.5) | 3.0-LTS פעל מ-30 בספטמבר 2021 עד 30 במרץ 2025 | 811 |
| ענף Release של OpenHarmony | שנתיים (1 + 1) | 4.1-Release פעל מ-30 במרץ 2024 עד 30 במרץ 2026 | 811 |
הטבלה הזאת מבוססת על המידע הרשמי של כל ספק נכון ליולי 2026. יש לבדוק לא רק את מספר השנים, אלא אם הזמן שנותר עד תאריך הסיום בטבלה מכסה את תקופת השירות של ההתקן. תקופות תמיכה ותאריכי סיום מתעדכנים, ולכן המקורות הראשוניים שצריך לבדוק ממש לפני החלטת אימוץ הם הבאים.
- OpenHarmony: Version Lifecycle Management (מדיניות ניהול מחזור החיים) ו-Version Definitions (סוגי הענפים וטבלת לוח הזמנים של התחזוקה).811
- Windows: עמוד Microsoft Lifecycle לפי מוצר.5
- Debian: Debian Wiki LTS.6
- Yocto Project: Releases.7
flowchart TB
accTitle: להתאים את תקופת השירות של ההתקן לתאריך סיום התחזוקה של מערכת ההפעלה
accDescr: לבדוק לא רק את מספר שנות התמיכה במערכת ההפעלה, אלא אם תאריך הסיום של הגרסה שאומצת מכסה את תקופת השירות של ההתקן.
device["סיום השירות המתוכנן של ההתקן"] --> compare["להשוות את תאריכי הסיום"]
osend["תאריך סיום התחזוקה של הגרסה שאומצת"] --> compare
compare --> enough{"מספיק לתקופת השירות"}
enough -->|"קצר"| contract["לשקול חוזה תחזוקה או אפשרות אחרת"]
enough -->|"מספיק"| scope["לבדוק גם את היקף התיקונים"]
איור 6: להשוות את תאריך הסיום של אותה גרסה לתוכנית התפעול של ההתקן, ולא רק את התווית “תמיכה לעשר שנים”.
3.3. לקרוא בנפרד תחזוקה יזומה ותחזוקה סבילה
ענף Release של OpenHarmony מקבל שנה של תחזוקה יזומה ועוד שנה של תחזוקה סבילה, ו-ענף LTS שנתיים של יזומה ועוד 1.5 שנים של סבילה. אין לשפוט לפי הסכום הכולל בלבד.8
| שלב התחזוקה | מה הקהילה עושה | איך יצרן ציוד צריך לקרוא את זה |
|---|---|---|
| תחזוקה יזומה | משחררת גרסאות מתויגות לפי תוכנית ומתקנת פגמים, פרצות אבטחה וכדומה | התקופה שבה אפשר לצפות לתיקונים רציפים ולגרסאות מתויגות |
| תחזוקה סבילה | לא מתכננת ולא משחררת גרסאות מתויגות, ומתקנת רק פרצות אבטחה ופגמים בדירוג critical ומעלה | היקף התיקונים ואופן האספקה מוגבלים, ולכן היא כבר לא יסודית כמו התחזוקה היזומה |
בגלל ההבדל הזה, המאמר נוקט בעמדה שהתקופה שאפשר להסתמך עליה בפועל צריכה להיספר כשנה אחת ל-Release ובעוד שנתיים ל-LTS. סך השנים של התחזוקה הקהילתית והתקופה שבה אפשר לצפות לתחזוקה יסודית הם שני דברים שונים.8
flowchart TB
accTitle: איך משתנים שלבי התחזוקה ב-OpenHarmony
accDescr: תחזוקה יזומה מספקת גרסאות מתויגות מתוכננות, תחזוקה סבילה מגבילה את היקף התיקונים ואת אופן האספקה, ובסוף הענף מגיע לסוף התחזוקה.
active["תחזוקה יזומה"] --> passive["תחזוקה סבילה"]
passive --> eol["סוף התחזוקה"]
active -.-> regular["גרסאות מתויגות ותיקונים מתוכננים"]
passive -.-> limited["תיקונים לפגמים ולפרצות בדירוג critical ומעלה"]
איור 7: בתוך אותה תקופת תחזוקה, אותו היקף תיקונים לא נמשך עד הסוף.
3.4. לבדוק מה כתוב לגבי הענף שאימצתם
נכון ליולי 2026, נקודת הייחוס של המאמר, לא נחתך ענף LTS בשנים האחרונות. ה-LTS האחרון שמופיע בטבלת לוח הזמנים הרשמית של התחזוקה הוא 3.0-LTS (ספטמבר 2021); 3.1, 3.2, 4.0 ו-4.1 הם כולם Release.11
זה לא שלא היה LTS מעולם. מפתח ה-release notes עדיין מציג את 1.1.0 LTS (אפריל 2021) ואת הקו שלו, אבל כולם מסומנים End of Life. גם קו 3.0-LTS מופיע, ומשנת 3.1 ואילך הסוג הוא Release.12
יתרה מזאת, לטבלת לוח הזמנים של התחזוקה באותה נקודת זמן אין רשומות לקווים 5.x או 6.x. אין להסיק את תקופת התחזוקה של גרסה שלא מופיעה בטבלה מגרסאות אחרות. צריך לעבוד בהנחה שהתקופה לא נקבעה ולאמת אותה עבור אותה גרסה.
ל-Windows 11 IoT Enterprise LTSC 2024 יש מחזור חיים קבוע עם תאריך סיום מאושר של 10 באוקטובר 2034, Debian מפרסמת את תקופות התמיכה הרגילה וה-LTS שלה, ו-Yocto Project מפרסמת ארבע שנות תמיכת LTS. ב-OpenHarmony, לעומת זאת, צריך לאמת בנפרד “עד לאן יתוחזק ה-fork שאומצים”.567
flowchart TB
accTitle: לא להסיק תחזוקה לגרסה שלא מופיעה ברשימה
accDescr: לבדוק אם הגרסה שאומצת מופיעה בלוח הזמנים של התחזוקה, ואם לא, לאמת אותה בנפרד במקום להחיל עליה את התקופה של גרסה אחרת.
branch["לזהות את הגרסה ואת הענף שאימצתם"] --> listed{"מופיע בטבלת התחזוקה"}
listed -->|"כן"| dates["לבדוק את התקופה ותאריך הסיום של אותה גרסה"]
listed -->|"לא"| ask["להתייחס לתקופה כלא נקבעה ולאמת בנפרד"]
ask --> hold["להחזיק את ההחלטה עד שהתחזוקה תיסגר"]
איור 8: אין להניח תחזוקה לגרסה שלא מופיעה ברשימה לפי תווית LTS או לפי מספר השנים של גרסה אחרת.
4. לברר אם אפשר לבצע מיגרציה: SDK, אפליקציות, דרייברים ואנשי צוות
4.1. לפני השוואת מערכות הפעלה, לעשות ספירת מלאי של ה-SDK שאתם תלויים בהם
הרבה SDK ומידלוור למצלמות תעשייתיות, לבקרי motion, לתקשורת PLC, לעיבוד תמונה וכדומה הם Windows-first, עם build ל-Linux כאפשרות שנייה אם יש מזל. build ל-OpenHarmony הוא לא משהו שאפשר לצפות לו מלכתחילה.
לכן העבודה הראשונה היא ספירת מלאי כזו.
לרשום את ההתקנים ההיקפיים ואת המידלוור שהציוד צריך, ולבדוק את מצב התמיכה ב-OpenHarmony של כל אחד מהם.
אם SDK נדרש לא קיים ואי אפשר לבנות בעצמכם את מה שחסר, ותרו על OpenHarmony בקונפיגורציה הזאת. אם בוחרים לפי הפיצ’רים בטבלת השוואה ורק אחר כך בודקים SDK, הקונפיגורציה מפסיקה לעבוד בהמשך הפרויקט. גם אנחנו, כשפונים אלינו בייעוץ על תוכנת ציוד, מתחילים מבניית הרשימה הזאת.
flowchart TB
accTitle: לצמצם את מועמדי מערכת ההפעלה לפי ה-SDK שצריך
accDescr: לרשום את ההתקנים ההיקפיים ואת המידלוור שהציוד צריך, וכשאין SDK ל-OpenHarmony, לבדוק אם אפשר לבנות בעצמכם את מה שחסר.
devices["לרשום התקנים היקפיים ומידלוור"] --> sdk{"ה-SDK הנדרשים זמינים"}
sdk -->|"זמינים"| next["לעבור לבדיקת היקף ההעברה"]
sdk -->|"לא זמינים"| make{"אפשר לבנות את מה שחסר"}
make -->|"כן"| next
make -->|"לא"| stop["לוותר בקונפיגורציית ההתקן הזאת"]
איור 9: אם ה-SDK חסר ואי אפשר לסגור את הפער, המשך השוואת הפיצ’רים לא יגרום לקונפיגורציית ההתקן לעבוד.
4.2. אי אפשר להעביר תוכנת ציוד של Windows כמו שהיא
הצגת ההבדלים בין ערימות הפיתוח מראה את ההשפעה על הנכסים הקיימים.
| פריט | Windows IoT Enterprise LTSC | Embedded Linux | OpenHarmony |
|---|---|---|---|
| מערכת build | MSBuild / Visual Studio | Make / CMake / BitBake (Yocto) | GN + Ninja2 |
| שפות עיקריות | C#, C++, VB | C, C++, Python, Rust | ArkTS (הרחבה של TypeScript), C, C++ |
| מסגרת UI | WPF, WinForms, WinUI | Qt, GTK, Flutter וכדומה | ArkUI |
| דרייברים | WDM / WDF | דרייברים של Linux kernel | HDF |
| IDE | Visual Studio | לבחירתכם | DevEco Device Tool (Windows ו-Ubuntu) או ה-CLI13 |
| תיעוד ביפנית | זמין | בשפע | אין (סינית ואנגלית בלבד)3 |
תוכנת ציוד ל-Windows שנכתבה ב-C#/.NET, Win32, COM או WPF/WinForms היא בפועל כתיבה מחדש על OpenHarmony. אין סביבת הרצה מקבילה, ולכן היא נכתבת מחדש בערימה אחרת: ArkTS עם ArkUI ל-UI ו-C/C++ מתחת.
אם הנחת היסוד היא ניצול נכסים קיימים, המעבר ל-Windows IoT Enterprise LTSC הוא המסלול הריאלי. אם בוחרים ב-Embedded Linux, חלקים כמו ה-UI של Windows עדיין נכתבים מחדש, אבל לוגיקת מדידה ובקרה ב-C/C++ מועברת בקלות, וכדאי לשקול זאת אם מגבילים את עצמכם להתקנים שה-SDK הנדרשים ל-Linux מסופקים עבורם.
שימו לב שתא הדרייברים בטבלה, שאומר HDF, לא אומר שכל דרייבר Linux קיים צריך להיכתב מחדש. ההבדל בין שימוש בהתקן דרך ממשקי ה-Linux הרגילים לבין שימוש בו מהמסגרת של OpenHarmony מוסבר בסעיף 4.3 שלמטה.
flowchart TB
accTitle: לפרק את היקף המיגרציה של נכסי Windows קיימים
accDescr: להפריד בין המסלול שמשאיר את תוכנת ה-Windows הקיימת כמו שהיא לבין המסלול שכותב מחדש את ה-UI ואת סביבת ההרצה למערכת הפעלה אחרת, וב-Linux לבדוק את זמינות ה-SDK ואת מידת ההעברה של לוגיקת C/C++.
assets["תוכנת ציוד קיימת ל-Windows"] --> reuse["להמשיך להשתמש בנכסים הקיימים כמו שהם"]
assets --> port["לכתוב מחדש למערכת הפעלה אחרת"]
reuse --> windows["לשקול Windows IoT LTSC"]
port --> scope["להפריד בין UI, סביבת הרצה ו-SDK"]
scope -.-> logic["ב-Linux, לשקול העברה של לוגיקת C/C++"]
איור 10: כשמחליפים מערכת הפעלה, לא לצרף לגוש אחד את ה-UI ואת סביבת ההרצה, את לוגיקת המדידה והבקרה ואת ה-SDK.
4.3. להפריד בין המסלול שמשתמש בדרייברי Linux לבין התאמה ל-HDF
HDF (Hardware Driver Foundation) של OpenHarmony הוא תשתית דרייברים אחידה שאינה תלויה בפלטפורמה ובגרעין, ומתייחסת לכל סוגי המערכות.2
ה-kernel של מערכת ה-Standard, לעומת זאת, הוא Linux. לכן בהחלט אפשר לשלב דרייבר Linux kernel קיים ולעבוד איתו דרך ממשקי ה-Linux הרגילים כמו V4L2 או התקני input.
| מאיפה משתמשים בהתקן | עבודה שצריך להעריך |
|---|---|
| מממשקי ה-Linux הרגילים | לשקול קונפיגורציה שמשלבת ומשתמשת בדרייבר ה-Linux kernel הקיים |
| משירותי המערכת והמסגרות של OpenHarmony דרך HDI | להעריך את עבודת ההתאמה בצד OpenHarmony |
אם קיים BSP ל-Linux, אין צורך להעריך “כתיבה מחדש של כל דרייבר ב-HDF”. קודם כול להחליט אילו התקנים חייבים להיחשף למסגרת של OpenHarmony, ולהכניס את ההיקף הזה לאומדן העבודה.
כמו כן, עוד לפני שרוכשים לוח אפשר להתחיל לבדוק את המבנה ואת תהליך ה-boot ב-QEMU. נקודת הכניסה הזאת, וסדר העבודה אחרי האימוץ, מסוכמים בסעיף 8.
flowchart TB
accTitle: שימוש חוזר בדרייברי Linux והתאמה למסגרת
accDescr: בשימוש בדרייברי Linux קיימים במערכת ה-Standard, להפריד בין העבודה הנוספת של שימוש בהם דרך ממשקי ה-Linux הרגילים לבין חשיפתם למסגרת של OpenHarmony דרך HDI.
driver["דרייבר Linux במערכת ה-Standard"] --> normal["ממשקי Linux רגילים"]
driver --> hdi["שימוש דרך HDI"]
normal --> direct["קונפיגורציה שמשלבת את הדרייבר הקיים"]
hdi --> adapt["להתאים בצד OpenHarmony"]
adapt --> framework["שירותי מערכת ומסגרות"]
איור 11: במקום לכתוב מחדש כל דרייבר, להעריך את ההיקף שחייבים לחשוף ל-OpenHarmony.
4.4. להכין את סביבת הפיתוח ואת האנשים שיכולים לקרוא את התיעוד
נקודות הכניסה לפיתוח התקנים הן ה-GUI DevEco Device Tool וה-CLI. ההתקנה של DevEco Device Tool היא משולבת: עריכת קוד, דיבוג וצריבה ב-Windows, וקומפילציה ב-Ubuntu. את קוד המקור מושכים עם כלי ה-repo, ומתועדים mirrors ב-gitcode.com, gitee.com ו-GitHub.1314
התיעוד הרשמי מגיע בשתי שפות, סינית ואנגלית; אין גרסה ביפנית. גם הדיונים בקהילה וגם הספקים של הפצות מסחריות מרוכזים בסין, ומספר העמדות שאפשר לקבל בהן תמיכה בקו ראשון ביפנית מוגבל. קיומם של אנשים שיכולים לקרוא מסמכים טכניים בסינית או באנגלית מהתחלה ועד הסוף הוא לא תנאי תומך שנחשב רק אחרי שהפיתוח התחיל; בפועל זהו תנאי לאימוץ.3
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 רשומות. אלה הפריטים שסביר שיהיו רלוונטיים לציוד.15
| סוג מערכת | לוח | SoC | שימוש מיועד בתיעוד |
|---|---|---|---|
| Standard | HiHope HH-SCDAYU200 | Rockchip RK3568 | NVR, שערים תעשייתיים, מכשירי בית |
| Standard | MILOS_Standard0 | NXP i.MX8M Mini | מכשירי מדידה בעלי ביצועים גבוהים לתעשייה ולרפואה, בקרה תעשייתית ו-HMI, תחבורה, מניעת אסונות, מבנים |
| Standard | Yangfan | Rockchip RK3399 | שילוט דיגיטלי, מסופים ללא נציג, מחשבי בקרה תעשייתית, רובוטים |
| Standard | לוח פיתוח ZLG | Allwinner T507 | בקרה תעשייתית, תאי נהג חכמים, ניהול אנרגיה חכם |
| Standard | Unionpi Tiger | Amlogic A311D | בקרה תעשייתית, מחשוב edge עם AI |
| Small | BearPi-HM Micro | ST STM32MP157A | בית חכם, מסכי בקרה מרכזיים |
| Mini | Niobe407 | ST STM32F407IGT6 | תחבורה חכמה, בקרה תעשייתית |
| Mini | HPM6750EVK2 | HPMicro HPM6700 (RISC-V) | בקרה תעשייתית, מחשוב edge |
יצרני ה-SoC הם לא רק סינים. גם NXP i.MX8M Mini וסדרת STM32 של ST נמצאים שם, ולכן ייצרן ציוד יפני עשוי להעריך אותה על משפחת SoC שהוא כבר משתמש בה.
הטבלה הזאת, לעומת זאת, מציגה את השימושים המיועדים שכתובים בתיעוד. היא לא מבטיחה אספקה לעשר שנים, הפצה ביפן, או תמיכה רשמית של OpenHarmony בלוחות ייצור.
flowchart TB
accTitle: להפריד בין רשימת הנתמכים לבין תנאי הרכש לייצור סדרתי
accDescr: רשימת לוחות הפיתוח הנתמכים היא נקודת כניסה להערכה טכנית ואינה מבטיחה הפצה מקומית, שנות אספקה או תמיכה רשמית בלוחות ייצור.
list["רשימת לוחות פיתוח נתמכים"] --> candidate["מועמדים להערכה טכנית"]
candidate --> sale["לבדוק מכירה בפועל והפצה מקומית"]
sale --> supply["לבדוק מנות ייצור ושנות אספקה"]
list -.-> note["לא ערובה לאספקה ארוכת טווח"]
איור 13: הופעה ברשימה וזמינות לאורך חיי המוצר הן שתי בדיקות נפרדות.
5.2. לבדוק את תנאי הרכש לפני שמזמינים יחידת הערכה
הרשימה מבוססת בעיקר על לוחות הערכה, שרבים מהם מיועדים לשוק הסיני. הם לא בהכרח זמינים אצל מפיץ ביפן כדבר שבשגרה. לפני הזמנת יחידת הערכה, כדאי לשאול על שלוש הנקודות האלה.
- האם עמוד המכירה של ספק הלוח או ערוץ מסחר חוצה גבולות מציעים אותו.
- האם יש מפיץ מכירות ביפן.
- מהי מנת הייצור המינימלית לייצור סדרתי ומה מספר שנות האספקה.
גם אם לוח נמצא ברשימת הנתמכים, אי אפשר להתקדם בוולידציה טכנית על חומרה אמיתית בלי לרכוש אותו. לצד חלון התחזוקה של מערכת ההפעלה, יש לבדוק את תנאי האספקה של הלוח.
אם מטמיעים אותה בלוח משלכם, ההעברה (porting) היא עבודה שלכם או של מפיץ. זהו היקף שונה מרכישת רישיון ממפיץ 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 היא לא רישיון אחד. יש לרשום את המאגרים שמשולבים למוצר ולבדוק אותם לפי ההיקף.
| מטרה | רישיון | נקודה מעשית |
|---|---|---|
| רכיבים רבים (מערכת ה-build, מנוע ה-ArkUI וכדומה) | Apache License 2.016 | לעמוד בתנאי זכויות היוצרים והפטנטים, ולהצהיר על השינויים שלכם |
| ה-kernel LiteOS-A | BSD 3-Clause17 | לשחזר את הודעת זכויות היוצרים ואת כתב הוויתור בעת הפצת בינארים |
| חלק ה-Linux kernel של מערכת ה-Standard | GPLv2 (הרישיון של Linux kernel עצמו) | כשמפיצים את הציוד ללקוח, נוצרת חובה לספק למקבל את קוד המקור המתאים לבינארים שמופצים, כולל השינויים שלכם. שינויים שנשארים בתוך החברה שלכם לא יוצרים חובה לספק קוד מקור |
| התיעוד הרשמי | CC BY 4.018 | ייחוס בעת ציטוט |
התייחסות גורפת בסגנון “OpenHarmony היא Apache 2.0, אז זה בסדר” מפספסת את חובות ה-GPL של חלק ה-Linux kernel במערכת ה-Standard. ההבדל המעשי מ-Windows IoT, שבה רוכשים את מערכת ההפעלה ברישיון מסחרי, נמצא גם בבדיקת הרישיונות לפי רכיב.
flowchart TB
accTitle: לבדוק רישיונות לפי ההיקף שמשלבים למוצר
accDescr: לא להתייחס ל-OpenHarmony כרישיון אחד, לרשום את המאגרים שמשולבים למוצר ולבדוק כל LICENSE ומה צריך לעשות בעת ההפצה.
product["קונפיגורציה שמשולבת למוצר"] --> repos["לרשום את המאגרים הרלוונטיים"]
repos --> licenses["לבדוק כל LICENSE"]
licenses --> delivery["לסדר מה נדרש בעת ההפצה"]
delivery --> legal["לאמת עם המחלקה המשפטית וה-IP"]
איור 15: לא להחליט לפי Apache 2.0 בלבד; לבדוק כל רכיב שמשלבים בפועל.
6.2. להפריד בין שינוי ה-kernel לבין הפצת הציוד ללקוח
החובה לפי GPLv2 נוצרת לא ברגע שמשנים את הקוד אלא ברגע ההפצה. אם משנים את ה-kernel בלבד ומריצים אותו על מכונת בדיקה פנימית, לא נוצרת חובה לספק קוד מקור.
כשמוסרים את הציוד ללקוח, נוצרת חובה לספק למקבל את קוד המקור המתאים לבינארים שמופצים, כולל השינויים שלכם. עבור יצרן ציוד, מסירה היא הפצה, ולכן ייצור סדרתי ומסירה מחייבים עמידה בדרישות. צריך להפריד בין העובדה שאין חובת פרסום משלב האב-טיפוס הפנימי לבין העובדה שנדרשת עמידה בדרישות כשמוסרים ללקוח. יש לאמת את אופן העמידה בדרישות עם המחלקות המשפטית וה-IP שלכם.
flowchart TB
accTitle: להבחין בין שינוי kernel פנימי לבין הפצה ללקוח
accDescr: כששוקלים את חובת אספקת קוד המקור לפי GPLv2, יש להפריד בין המקרה שנשאר בשימוש פנימי לבין הפצת ציוד שמכיל בינארי kernel ללקוח.
kernel["קונפיגורציה שמכילה את ה-Linux kernel"] --> internal["נשארת בבדיקות ובשימוש פנימיים"]
kernel --> distribute["ציוד שמופץ ללקוח"]
internal --> no["שינויים פנימיים בלבד לא יוצרים חובה"]
distribute --> corresponding["לספק את קוד המקור המתאים"]
איור 16: לבדוק את החובה תוך הפרדה בין רגע השינוי לבין רגע מסירת הציוד ללקוח.
6.3. להפריד בין זה שזה עובד לבין לקרוא לזה OpenHarmony תואם
בנפרד מעמידה בדרישות הרישיון, יש לבדוק את ההליך שנדרש כדי להצהיר על תאימות כלפי חוץ.
6.3.1. ולידציה פנימית והצהרת תאימות של מוצר
אם משתמשים בזה רק לולידציה פנימית או במכונה חד-פעמית, אין צורך בהסמכת תאימות. אם, לעומת זאת, רוצים להצהיר “OpenHarmony compatible” כלפי חוץ כמוצר, או להיות מוכרים כחלק מהאקוסיסטם, יש להעריך את המאמץ בהנחה שעוברים את הערכת התאימות של קרן OpenAtom.
הבסיס הטכני הוא XTS (X Test Suite), משפחת חבילות בדיקות התאימות. הזרימה היא שהמבקש מבצע פיתוח תאימות ובדיקות עצמיות ומגיש בקשה עם דוח בדיקות מצורף.219
flowchart TB
accTitle: הכנה להסמכה למוצר שמצהיר על תאימות
accDescr: במוצר שמצהיר כלפי חוץ על תאימות ל-OpenHarmony, לבדוק את הבדיקות הנדרשות, להכין פיתוח תאימות, בדיקות עצמיות ודוח, ולהגיש בקשה להערכת התאימות.
claim["להצהיר על תאימות ל-OpenHarmony"] --> required["לבדוק את דרישות הבדיקה בזמן ההגשה"]
required --> test["פיתוח תאימות ובדיקות עצמיות"]
test --> report["להכין את דוח הבדיקות"]
report --> apply["להגיש בקשה להערכת התאימות"]
איור 17: זה שזה עובד אצלכם בפנים אינו אותו דבר כמו היכולת להצהיר שהמוצר תואם.
6.3.2. לבדוק את ACTS, HATS ו-DCTS מול הפערים בין המקורות
נכון ליולי 2026, נקודת הייחוס של המאמר, המקורות חלוקים לגבי ההרכב של XTS.
| מקור | החבילות שמופיעות |
|---|---|
| התיעוד הרשמי | ACTS (תאימות אפליקציות) שנתמך כעת, ו-DCTS (תאימות התקנים) שתיתמך בעתיד |
| חומר הליך ההסמכה של הקהילה | מבנה תלת-חלקי של ACTS, HATS (תאימות שכבת הפשטת החומרה) ו-DCTS |
בחומר הרשמי DCTS מוצג כמשהו עתידי, ואילו חומר הקהילה מתאר אותו כרכיב. אין לקבוע ש-DCTS הוא חובה; יש לבדוק בעמדת ההסמכה אילו חבילות נדרשות בפועל בזמן ההגשה. הפער הזה בתיאורים, והיעדרם של מקורות ראשוניים ביפנית, הופכים גם הם לעלות תקשורת כשאומצים את זה.219
6.4. לבדוק את האקוסיסטם שהלקוח רוצה, ואת מדיניות הרכש
אם מה שהלקוח רוצה הוא הפצה ב-AppGallery או אינטראופרציה עם אפליקציות HarmonyOS, OpenHarmony לא יכולה למלא את הדרישה. AppGallery, HMS ו-HarmonyOS SDK אינם חלק מ-OpenHarmony, והתאימות לאפליקציות HarmonyOS אינה מובטחת. מה שנדרש הוא מוצר תואם HarmonyOS ו-HarmonyOS SDK, וזה עניין שונה מהסמכת “OpenHarmony compatible”.
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 או Embedded 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, התחזוקה ואנשי הצוות.
| מצב | המלצה | סיבה |
|---|---|---|
| מחשב עם HMI שמוטמע בציוד שפועל עשר שנים, עם נכסי Windows קיימים | Windows 11 IoT Enterprise LTSC 2024 | עשר שנות תמיכה עד אוקטובר 2034. בלי עדכוני פיצ’רים. תוכנת הציוד וה-SDK של הספקים רצים כמו שהם5 |
| ציוד שפועל עשר שנים, יש SDK ל-Linux ויש אנשי Linux פנימיים | Embedded Linux עם תמיכה מסחרית | ארבע שנים עם Yocto LTS, ניתן להאריך בחוזה תמיכה ארוך טווח מהפצה מסחרית7 |
| מוצר שמשוחרר לשוק הסיני שבו הדרישה היא “חייב להיות תואם OpenHarmony” | OpenHarmony (דרך הפצה מסחרית) | דרישת השוק קובעת את מערכת ההפעלה. לרכוש עם תחזוקת ספק כלולה |
| הלקוח מבקש להשתתף באקוסיסטם של HarmonyOS (הפצה ב-AppGallery, אינטראופרציה עם אפליקציות HarmonyOS) | OpenHarmony לא יכולה למלא את הדרישה | גם AppGallery, גם HMS וגם HarmonyOS SDK אינם חלק מ-OpenHarmony, והתאימות לאפליקציות HarmonyOS אינה מובטחת. צריך מוצר תואם HarmonyOS ו-HarmonyOS SDK |
| שיתוף פעולה בין כמה התקנים (גילוי התקנים, סנכרון נתונים, העברת אפליקציות) הוא לב הערך של המוצר | OpenHarmony | DSoftBus, ניהול נתונים מבוזר ומתזמן מבוזר כלולים כסטנדרט2 |
| רוצים משפחה אחת לכל קו המוצרים, מ-MCU ועד התקנים עשירים | OpenHarmony (כדאי להעריך) | מכסה מ-128 KiB ועד 128 MiB ומעלה במשפחה אחת1 |
| צמתי חיישנים ומודולי תקשורת (MCU, כמה מאות KiB) | מערכת ה-Mini של OpenHarmony או RTOS | Windows IoT יוצאת מהמשחק (מינימום 2 GB)4 |
| רוצים עשר שנות תחזוקה מובטחות בחוזה, ואין אנשי צוות שקוראים מסמכים טכניים בסינית או באנגלית | לוותר | התחזוקה הקהילתית היא 3.5 שנים לכל היותר, ואין תיעוד ביפנית ואין תמיכת קו ראשון ביפנית83 |
| ציוד שתלוי ב-SDK של ספקים למצלמות תעשייתיות, לבקרי motion וכדומה | לוותר (לבדוק קודם) | תמיכה של OpenHarmony ב-SDK של ספקים היא לא משהו שצריך לצפות לו |
| רוצים לנצל נכסים קיימים של C#/.NET ו-COM | לוותר | אין סביבת הרצה מקבילה, ולכן זה הופך לכתיבה מחדש |
| מדיניות הרכש מגבילה את “הממשל והגוף המנהל של הפרויקט” | לשקול את משפחת Eclipse Oniro | Oniro נמצאת תחת ממשל של קרן אירופית. עם זאת, נכון ליולי 2026 היא בשלב Incubating והקהילה שלה רחוקה מאוד מגודלו של הפרויקט המרכזי |
| מדיניות הרכש מגבילה “לא להכיל קוד ממוצא סיני” | לוותר | גם Oniro בנויה על שכבת הבסיס של OpenHarmony, ולכן גם עם ממשל של קרן אירופית האילוץ על מקור הקוד לא נפתר |
8. אם היא נשארת מועמדת, להפוך אותה לקונקרטית בשבעה שלבים
אם היא שורדת את טבלת ההחלטה, עוברים לשבע העבודות שלמטה. הרצה תחת QEMU או על חומרה אמיתית אינה אותו דבר כמו היכולת לאמץ אותה כמוצר. אין לסגור אימוץ רק על סמך ולידציה טכנית מוצלחת כשתנאי התחזוקה עדיין פתוחים.
- ספירת מלאי של ההתקנים ההיקפיים והמידלוור. לבדוק אם מצלמות, I/O, תקשורת, motion, עיבוד תמונה וכדומה יכולים להיות נתמכים ב-OpenHarmony. אם נתקעים כאן, אין טעם לקדם את שאר השלבים.
- לקבוע את סוג המערכת. להחליט על Mini, Small או Standard. ה-kernel (LiteOS-M / LiteOS-A / Linux) ואופן כתיבת האפליקציות משתנים בהתאם.
- לבדוק את המבנה ב-QEMU. לפני שקונים חומרה אמיתית, אפשר לבדוק את ה-build ואת תהליך ה-boot בסביבות
device_qemuכמו Arm Virt (LiteOS-A / Linux), Cortex-M4, Cortex-M55 ו-RISC-V.20 - לקבע את ענף התחזוקה ולהבטיח שחזוריות build. לקבע את ה-manifest של
repo(ציון tag הוא הדרך האמינה), להחזיק mirror פנימי, ולהגיע למצב שאפשר לייצר מחדש את אותם בינארים גם בעוד חמש שנים. העובדה שאירוח ה-upstream מרוכז ב-gitcode.com היא סיבה נוספת להחזיק mirror מבחינת המשכיות עסקית.14 - ספירת מלאי של הרישיונות. לרשום את המאגרים שמשלבים ולסדר את חובות ה-Apache 2.0 / BSD / GPL.
- לנהל משא ומתן על חוזה התחזוקה. עם הספק של ההפצה המסחרית, לקבע “איזה ענף, עד מתי, ובאיזה SLA”. אם אי אפשר לסגור, מחזיקים את החלטת האימוץ.
- להחליט אם נדרשת הערכת תאימות. אם מתכוונים להצהיר כלפי חוץ על תאימות ל-OpenHarmony, להכניס לתוכנית מההתחלה את המאמץ של פיתוח תאימות ל-XTS, בדיקות עצמיות והגשה.
flowchart TB
accTitle: לחבר את הוולידציה הטכנית עד לתנאי האימוץ של המוצר
accDescr: לקבע את ההתקנים ההיקפיים ואת סוג המערכת ולבדוק את המבנה ב-QEMU, ואז לסגור שחזוריות build, רישיונות, חוזה תחזוקה והאם נדרשת הסמכה, לפני החלטת האימוץ.
inventory["ספירת מלאי של התקנים ו-SDK"] --> type["לקבוע את סוג המערכת"]
type --> qemu["לבדוק מבנה ו-boot ב-QEMU"]
qemu --> reproduce["לקבע ענף ושחזוריות build"]
reproduce --> conditions["לבדוק רישיונות, תחזוקה והסמכה"]
conditions --> decision["החלטת אימוץ כמוצר"]
איור 21: לא לעצור בוולידציה שזה רץ; להפוך לקונקרטיים גם את ה-build מחדש בעתיד ואת התחזוקה אחרי המשלוח.
8.1. סיכום: לבחור את מערכת ההפעלה שמתאימה לציר הזמן, לרכש ולכוח האדם של ההתקן
OpenHarmony מכסה במשפחה אחת הכול, מ-MCU עם 128 KiB ועד התקנים עשירים עם 128 MiB ומעלה, ויש לה שיתוף פעולה בין התקנים מבוסס DSoftBus כסטנדרט, וזה תכנון עקבי מבחינה טכנית. בין הלוחות הנתמכים שמיועדים לשימוש תעשייתי יש SoC של NXP ו-ST.1215
יחד עם זאת, עבור ציוד שפועל עשר שנים, תחזוקה קהילתית של שנתיים ל-Release ו-3.5 שנים ל-LTS היא בבירור לא מספיקה. כולל העובדה שלא נחתך LTS מאז 3.0-LTS נכון לנקודת הייחוס של המאמר, זו לא אפשרות לאמץ בלי תחזוקה מהפצה מסחרית או בלי יכולת פנימית שמגיעה עד טיפול ב-CVE.81112
מה שיצרן ציוד יפני צריך לבדוק הוא ה-SDK של ההתקנים שבהם הוא משתמש, אנשי צוות שיכולים לקרוא את המסמכים הטכניים, ותחזוקה שתומכת במשך חיי המוצר. בלי אלה, Windows IoT Enterprise LTSC או Embedded Linux עם תמיכה מסחרית היא הבחירה הריאלית. ומנגד, אם דרישות השוק הסיני, שיתוף פעולה בין התקנים, או איחוד הכול מ-MCU ועד התקנים עשירים במשפחה אחת קשורים ישירות לערך המוצר, כדאי להעריך את OpenHarmony ברצינות.
בחירת מערכת הפעלה היא לא שיפוט של “מי טובה יותר” אלא של מי מתאימה לציר הזמן, לרכש ולכוח האדם של ההתקן. הקריטריונים לבחירה בצד Windows מסודרים ב-“איזו Windows להתקין במחשב תעשייתי?”.
מאמרים קשורים
- מהי OpenHarmony? — סידור ההבדלים מ-HarmonyOS ומ-HarmonyOS NEXT
- איזו Windows להתקין במחשב תעשייתי? — מדריך מעשי ל-Windows IoT Enterprise / LTSC
- פתרונות מעשיים אחרי סיום התמיכה ב-Windows 10
- מדריך מעשי ל-Windows Kiosk Mode (Assigned Access)
תחומי ייעוץ קשורים
KomuraSoft LLC מסייעת בבחירת פלטפורמת ההרצה שמוטמעת בציוד, בבדיקה ראשונית אם אפשר להעביר תוכנת ציוד קיימת ל-Windows, ובסקירת קונפיגורציות שמיועדות לפעולה ממושכת. אפשר להתייעץ איתנו כבר מהשלב שבו “מערכת הפעלה חדשה עלתה כמועמדת, אבל אין לנו במה להשוות אותה”.
מקורות
-
תיעוד OpenHarmony, Quick Start Overview. על ההגדרות של שלושת סוגי המערכות - מערכת ה-Mini (MCU, מינימום 128 KiB), מערכת ה-Small (Cortex-A, מינימום 1 MiB) ומערכת ה-Standard (Cortex-A, מינימום 128 MiB) - ועל מוצרי היעד שלהן. ↩ ↩2 ↩3 ↩4 ↩5 ↩6
-
תיעוד OpenHarmony, OpenHarmony Project. על הארכיטקטורה בת ארבע השכבות ועל התכנון עם כמה גרעינים, Linux ו-LiteOS, על תשתית הדרייברים האחידה שמספק HDF (Hardware Driver Foundation), על DSoftBus, ניהול נתונים מבוזר ומתזמן מבוזר, על כך שמערכת ה-build היא GN + Ninja, ועל כך ש-XTS היא משפחת חבילות בדיקות תאימות שמתוארת כ-“the currently supported application compatibility test suite (ACTS) and the device compatibility test suite (DCTS) to be supported in future”. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
-
תיעוד OpenHarmony, README. על כך שהתיעוד הרשמי מסופק בשתי שפות, סינית (zh-cn) ואנגלית (en), בלי גרסה ביפנית, ועל המיפוי בין גרסאות לרמות API. ↩ ↩2 ↩3 ↩4 ↩5
-
Microsoft Learn, Minimum System Requirements - Windows IoT Enterprise. על כך ש-2 GB זיכרון ו-16 GB אחסון מוגדרים כדרישות המינימום ה-OPTIONAL להתקנים ייעודיים. ↩ ↩2 ↩3
-
Microsoft Learn, Windows 11 IoT Enterprise LTSC 2024 - Microsoft Lifecycle. על תאריך ההתחלה 1 באוקטובר 2024 ועל התמיכה המורחבת שנגמרת ב-10 באוקטובר 2034 (עשר שנים בסך הכול). ↩ ↩2 ↩3 ↩4 ↩5
-
Debian Wiki, LTS. על כך ש-Debian LTS הוא פרויקט שמאריך את חיי כל מהדורה יציבה לחמש שנים לפחות, ועל כך שתקופת ה-LTS של Debian 12 bookworm נמשכת מ-11 ביוני 2026 עד 30 ביוני 2028. ↩ ↩2 ↩3 ↩4
-
Yocto Project Wiki, Releases. על המדיניות של תמיכה במהדורות LTS לארבע שנים, ועל כך ש-5.0 Scarthgap שוחררה באפריל 2024 ונתמכת עד אפריל 2028 ו-6.0 Wrynose שוחררה באפריל 2026 ונתמכת עד אפריל 2030. ↩ ↩2 ↩3 ↩4 ↩5
-
OpenHarmony, OpenHarmony Version Lifecycle Management. על כך שלענף Release יש מחזור חיים של שנתיים (שנה של תחזוקה יזומה ועוד שנה של תחזוקה סבילה) ולענף LTS 3.5 שנים (2 ועוד 1.5), ועל כך שבתקופת התחזוקה הסבילה לא מתכננים ולא משחררים גרסאות מתויגות ומתקנים רק פרצות אבטחה ופגמים בדירוג critical ומעלה. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8
-
Huawei, HarmonyOS 7 Developer Beta officially launches, and the all-scenario intelligent operating system is upgraded again. על ההצהרה ב-HDC 2026 ב-12 ביוני 2026 ש-OpenHarmony הוציאה יותר מ-100 גרסאות מסחריות. ↩
-
Microsoft Learn, Windows 10 IoT Enterprise LTSC 2021 - Microsoft Lifecycle. על התמיכה המורחבת שנגמרת ב-13 בינואר 2032. ↩
-
תיעוד OpenHarmony, OpenHarmony Version Definitions. על טבלת לוח הזמנים של התחזוקה ל-ענפים מסוג LTS ו-Release (ה-LTS היחיד בטבלה הוא 3.0-LTS, בעוד 1.0.1, 3.1, 3.2, 4.0 ו-4.1 מסומנים כ-Release; התחזוקה של 4.1-Release נגמרת ב-30 במרץ 2026; והקווים 5.x ו-6.x עדיין לא מופיעים בטבלה). ↩ ↩2 ↩3 ↩4 ↩5
-
תיעוד OpenHarmony, Release Notes index. על כך ש-3.0-LTS (30 בספטמבר 2021) והקו שלו מופיעים, בעוד שהכול מ-3.1 ואילך מסומן כ-Release, על כך שלקו 1.x היו גם גרסאות LTS (1.1.0 LTS ואחרות) שמסומנות End of Life, ועל כך ש-6.1 Release (8 במרץ 2026) מופיע ברשימה. ↩ ↩2
-
תיעוד OpenHarmony, Quick Start Overview. על כך שיש שתי נקודות כניסה לפיתוח התקנים: מצב IDE שמשתמש ב-DevEco Device Tool (הרכבה היברידית עם פיתוח קוד, דיבוג וצריבה ב-Windows וקומפילציה של קוד המקור ב-Ubuntu) ומצב CLI. ↩ ↩2
-
תיעוד OpenHarmony, Source Code Acquisition. על ההליך למשיכת קוד מקור עם כלי repo, על ה-mirrors ב-gitcode.com, gitee.com ו-GitHub, ועל איך מציינים ענף או tag. ↩ ↩2
-
תיעוד OpenHarmony, OpenHarmony Development Boards List. על כך שיש 22 לוחות פיתוח נתמכים על ידי הקהילה, ועל ה-SoC והשימוש המיועד של כל לוח (למשל MILOS_Standard0 עם NXP i.MX8M Mini, שמצוינים עבורו מכשירי מדידה לתעשייה ולרפואה ובקרה תעשייתית ו-HMI, ו-Niobe407 עם STM32F407, שמצוינת עבורו בקרה תעשייתית). ↩ ↩2
-
OpenHarmony, arkui_ace_engine LICENSE ו-build LICENSE. על כך שהמאגרים של מנוע ArkUI ושל מערכת ה-build מופצים תחת Apache License 2.0. ↩
-
OpenHarmony, kernel_liteos_a LICENSE. על כך שה-kernel LiteOS-A מופץ תחת רישיון BSD 3-Clause. ↩
-
OpenHarmony, docs LICENSE. על כך שמאגר התיעוד הרשמי מסופק תחת רישיון Creative Commons Attribution 4.0 International. ↩
-
חומר קהילתי של קרן OpenAtom, OpenHarmony XTS Certification Process (מקור משני). על כך שחומר הליך ההסמכה של הקהילה מתאר את XTS כמבנה תלת-חלקי של ACTS (תאימות אפליקציות), HATS (תאימות שכבת הפשטת החומרה) ו-DCTS, ועל הזרימה שבה המבקש מקבל חשבון חברה, מבצע פיתוח תאימות ובדיקות עצמיות, ומגיש בקשה עם דוח בדיקות וגיליון בדיקה עצמית PCS מצורפים. מכיוון שהמעמד של DCTS מתנגש עם התיעוד הרשמי (“the device compatibility test suite to be supported in future”), גוף המאמר מציין את הפער הזה במפורש. ↩ ↩2
-
OpenHarmony, device_qemu README. על כך שמסופקים הליכים ליעדי אמולציה ב-QEMU, כולל Arm Virt (LiteOS-A), Arm Virt (Linux), Cortex-M4 (mps2-an386), Cortex-M55 (mps3-an547), RISC-V (riscv32_virt), Xtensa (esp32) ו-C-SKY (SmartL_E802). ↩
מאמרים קשורים
מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.
מה זה OpenHarmony? — סדר בהבדלים מ-HarmonyOS ומ-HarmonyOS NEXT
OpenHarmony אינו HarmonyOS. על בסיס מקורות ראשוניים, המאמר ממפה את מערכת ההפעלה בקוד פתוח של קרן OpenAtom, את מערכת ההפעלה המסחרית של Hua...
Time Travel Debugging — להקליט ולהריץ אחורה באגים שלא משתחררים באפליקציות ארוכות-ריצה
באג פעם בחודש משאיר ב-crash dump רק את התוצאה. מקליטים ומריצים אחורה את הביצוע עם WinDbg Time Travel Debugging (TTD): TTD.exe, ring buffe...
סיום התמיכה ב-printer drivers של Windows — איך אפליקציות עסקיות מתכוננות להדפסת דוחות ותוויות
Microsoft מפסיקה בהדרגה printer drivers מסוג v3/v4. מה Windows protected print mode מסיר, ואיך עושים inventory ומכינים הדפסת דוחות ותוויו...
רישיונות Power Automate — עד כמה Microsoft 365 מכסה בחינם, ומתי צריך Premium
במסגרת Microsoft 365 אפשר לבנות cloud flows על standard connectors בלי עלות נוספת, אבל Premium connectors כמו HTTP, SQL Server ו-Datavers...
לבנות כלי ניתוח ל-PowerShell בתוך PowerShell — לקרוא סקריפטים עם AST, לא עם ביטויים רגולריים
להציג AST אמיתי של PowerShell ולראות לאיזה אובייקט הופכת כל שורת קוד. לעבור מ-ScriptBlockAst ל-CommandAst ולמצוא היכן נקרא Write-Host, בל...
נושאים קשורים
העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.
נושאים טכניים ב-Windows
שער לנושאי פיתוח Windows, חקירת תקלות וניצול נכסים קיימים.
שאלות נפוצות
שאלות נפוצות בפניות בנושא המאמר.
- האם בטוח לאמץ את OpenHarmony כמערכת ההפעלה של ציוד תעשייתי?
- הכול תלוי בתנאים. הגורם המכריע הוא איך מטפלים בחלון התחזוקה: לענף Release של קהילת OpenHarmony יש מחזור חיים של שנתיים (שנה של תחזוקה יזומה ועוד שנה של תחזוקה סבילה), וגם לענף LTS יש רק 3.5 שנים. אם מטמיעים את גרסת הקהילה כמו שהיא בהתקן שצריך לפעול עשר שנים, תיקוני האבטחה נעצרים באמצע חיי המוצר. אימוץ מחייב או רכישה של תחזוקה מספק של הפצה מסחרית, או יכולת פנימית לתחזק ענף ולטפל ב-CVE בעצמכם. אם אי אפשר להעמיד יכולת כזו, Windows IoT Enterprise LTSC (עשר שנים) או חוזה תמיכה ארוך טווח ל-Embedded Linux מסחרי מתאימים יותר לציר הזמן של ההתקן.
- מה קל יותר, OpenHarmony או Embedded Linux?
- הרצפה של OpenHarmony נמוכה יותר. מערכת ה-Mini של OpenHarmony פועלת החל מ-128 KiB של זיכרון על MCU כמו Arm Cortex-M ו-RISC-V 32-ביט; מערכת ה-Small דורשת 1 MiB ומעלה, ומערכת ה-Standard 128 MiB ומעלה. Embedded Linux טיפוסי מניח מעבד עם MMU ועשרות MB של RAM ומעלה, ולכן היכולת לכסות גם את תחום ה-MCU באותה משפחת מערכות הפעלה היא מאפיין ייחודי של OpenHarmony. עם זאת, שימו לב שה-kernel של מערכת ה-Mini הוא LiteOS-M וסביבת ההרצה שלו שונה לחלוטין מזו של ה-Linux במערכת ה-Standard, ולכן "אותה מערכת הפעלה, ולכן אותן אפליקציות רצות" אינו נכון.
- אפשר להעביר תוכנת ציוד קיימת של Windows ל-OpenHarmony?
- בפועל זו כתיבה מחדש. לתוכנת ציוד שנכתבה ב-C#/.NET, Win32, COM או WPF/WinForms אין סביבת הרצה מקבילה ב-OpenHarmony. היא נכתבת מחדש בערימה אחרת: ArkTS עם ArkUI ל-UI, C/C++ מתחת, ו-HDF (Hardware Driver Foundation) לדרייברים. מעל זה, ה-SDK של ספקים למצלמות תעשייתיות ולבקרי motion מסופקים לרוב רק ל-Windows (ואחר כך ל-Linux), ושם נמצא צוואר הבקבוק האמיתי של ההעברה. אם הנחת היסוד היא לנצל נכסים קיימים, מעבר ל-Windows IoT Enterprise LTSC, או Embedded Linux שמוגבל להתקנים שעבורם מסופק SDK ל-Linux, הוא ריאלי יותר.
- צריך איזו הסמכה כדי להצהיר על תמיכה ב-OpenHarmony?
- כדי לקרוא למוצר "OpenHarmony compatible" צריך לעבור את הערכת התאימות (ההסמכה) של קרן OpenAtom. הבסיס הטכני לכך הוא משפחת חבילות הבדיקה XTS (X Test Suite) של OpenHarmony. ההרכב, לעומת זאת, מתואר אחרת במקורות שונים: נכון ליולי 2026 התיעוד הרשמי אומר "ACTS (application compatibility test suite) הנתמכת כעת ו-DCTS (device compatibility test suite) שתיתמך בעתיד", בעוד שחומר הליך ההסמכה של הקהילה מתאר מבנה שמוסיף להם גם HATS (תאימות שכבת הפשטת החומרה). כשמעריכים מאמץ, אין לקבוע את DCTS כדרישת חובה; יש לבדוק בעמדת ההסמכה אילו חבילות נדרשות בפועל בזמן ההגשה. הסמכה לא נדרשת אם משתמשים בזה רק לולידציה פנימית, אבל היא נדרשת למוצר שמצהיר על תאימות כלפי חוץ.
- כמה תמיכה ומידע יש בשפה היפנית?
- התיעוד הרשמי מגיע בשתי שפות, סינית ואנגלית; אין גרסה ביפנית. גם הדיונים בקהילה הם ברובם בסינית. הספקים של הפצות מסחריות הם גם הם ברובם חברות סיניות, ומספר העמדות שאפשר לקבל בהן תמיכה בקו ראשון ביפנית מוגבל. בפועל, תנאי מעשי לאימוץ הוא שיהיו בחברה אנשים שיכולים לקרוא מסמכים טכניים בסינית או באנגלית מהתחלה ועד הסוף. זהו הבדל ברור מ-Windows ומהפצות ה-Linux הגדולות.