מי יצייר את הפיקסלים ומי ישמור על המכונה: מדריך HMI למערכות Embedded

בארכיטקטורה אחת יש מעבד ראשי שמריץ Linux ועושה הכול: הוא מצייר את המסך, קורא את המגע, מפעיל את לוגיקת המוצר, מדבר עם הרשת ושומר נתונים. זה יכול להיות פתרון יעיל מאוד. יש לוח אחד, זיכרון אחד, סביבת פיתוח אחת ופחות תקשורת בין רכיבים. למוצר שהוא בעיקר מסוף מידע, נגן, מצלמה או יחידת מולטימדיה, הריכוז הזה עשוי לחסוך חומרה וזמן פיתוח.

המחיר הוא תחום כשל משותף. קריסה של אפליקציית GUI אינה חייבת להפיל את Linux, ותהליכים נפרדים, Watchdog והרשאות יכולים לצמצם נזק. אבל Kernel, ספק כוח, זיכרון, אחסון, דרייבר GPU ו־BSP — חבילת התמיכה של יצרן השבב בלוח — עדיין משותפים. אם אחד מן היסודות האלה נופל, גם התצוגה וגם הלוגיקה עלולות להיעלם יחד. במכונה שמחממת, מניעה או לוחצת משהו, מסך שחור אינו הבעיה העיקרית; הבעיה היא שלא נשאר מחשב עצמאי שממשיך להחזיק את המערכת במצב מוגדר.

ככה מתכננים מטוס, וככה מתכננים רכב כאשר מתייחסים ברצינות לגבולות הכשל. מערכת הבידור והניווט אינה אמורה להיות הסמכות שמפעילה מנוע, הגה או בלמים. תחשבו מה היה קורה אילו Waze היה מקרטע, הזיכרון של המולטימדיה היה מתמלא, ובאותו רגע הרכב היה מפסיק להגיב לבלימה. הדוגמה קיצונית בכוונה: היא מראה מדוע ממשק עשיר ומערכת בקרה קריטית יכולים לדבר זה עם זה, אבל לא חייבים לחיות בתוך אותו תחום כשל.

בארכיטקטורה המופרדת, מעבד אחד אחראי לתצוגה ולמגע ומיקרו־בקר אחר אחראי ללוגיקת המכונה, לכניסות, ליציאות ולמצב הבטוח. ביניהם עובר פרוטוקול מצומצם: התצוגה מבקשת פעולה או מציגה מצב, אך אינה מזיזה מנוע ישירות. כך אפשר לאתחל את ה־HMI בלי לאבד את הבקרה, והבקר יכול לדחות פקודה שאינה מותרת גם אם התצוגה השתגעה. ההפרדה אינה יוצרת בטיחות מעצמה; צריך להגדיר Timeout, ערכי ברירת מחדל, Watchdog ובדיקת גרסאות. היא כן נותנת מקום ברור שבו אפשר לאכוף כל כלל.

החלק המעניין פה הוא שההפרדה יכולה ליצור Second Source במקום שבו בדרך כלל מחפשים רק רכיב חלופי. אם החוזה בין לוח התצוגה ללוח הבקרה מתועד היטב, אפשר בעתיד להחליף את מעבד התצוגה, את מערכת ההפעלה או אפילו את ספק מכלול ה־HMI בלי לכתוב מחדש את בקרת המכונה. באותה דרך אפשר לייצר גרסה עם מסך קטן וגרסה עם מסך עשיר מעל אותו לוח לוגיקה. זה Second Source ברמת המודול והארכיטקטורה, לא הבטחה ששני שבבים נראים זהים בטבלת המפיץ.

גם במפעל מתקבל יתרון של הפרד ומשול. אפשר לצרוב ולבדוק את לוח הבקרה בלי מסך, לבדוק את מכלול התצוגה מול סימולטור ולחבר ביניהם רק בתחנה מאוחרת. תקלה חוזרת למסלול ברור יותר: תצוגה, כבל, פרוטוקול או בקרה. מצד שני נוספו מחבר, קו תקשורת, ספקי כוח, שתי קושחות וניהול גרסאות. הפרדה טובה מקטינה תלות; הפרדה לא מתוכננת פשוט מעבירה את הבאג אל הכבל שבאמצע.

כדי להבין מה מערכת התצוגה באמת עושה, נתחיל דווקא מן הסוף: מן האור שמגיע לעין. בפאנל OLED תת־הפיקסלים האדום, הירוק והכחול פולטים אור בעוצמות שונות. בפאנל LCD הם אינם מקור האור; הם מווסתים תאורה שמגיעה מאחור. בשני המקרים האלקטרוניקה של הפאנל צריכה לקבל עבור כל פיקסל ערכי צבע, שורה אחר שורה ובתזמון מדויק. אם הנתונים אינם מגיעים בקצב הנכון, המסך אינו מחכה בנימוס — הוא מציג שורה שגויה, תמונה חלקית או שום דבר.

הנתונים מגיעים לפאנל דרך ממשק חשמלי. במסך קטן עם זיכרון פנימי אפשר לשלוח פקודות וגושי פיקסלים דרך SPI, קו תקשורת סדרתי שמעדיף מעט חוטים על פני רוחב פס גבוה. במסך RGB מקבילי או MIPI-DSI במצב וידאו, המערכת מזרימה תמונה בתזמון רציף. היתרון של זרם רציף הוא קצב תצוגה גבוה; המחיר הוא שבקר התצוגה והזיכרון חייבים להאכיל את הפאנל כל הזמן, גם כאשר התמונה כמעט אינה משתנה.

מי שמייצר את הזרם הזה הוא בקר התצוגה. הוא יודע מתי מתחילה שורה, מתי מסתיים Frame ואיזה צבע לשלוח בכל רגע. אבל הוא בדרך כלל אינו יודע מהו כפתור ומה משמעותה של אזהרת טמפרטורה. הוא פשוט קורא רצף צבעים מתוך אזור זיכרון שנקרא Framebuffer. אפשר לחשוב על ה־Framebuffer כדף מצויר ועל בקר התצוגה כסורק שמקריא את הדף לפאנל שוב ושוב.

מתחת לתוכנה נמצא דרייבר התצוגה. הוא מגדיר את הרזולוציה, תדר הפיקסלים, זמני הסנכרון, פורמט הצבע וכתובת ה־Framebuffer. במסך עם זיכרון פנימי הוא גם שולח פקודות אתחול ומעתיק את האזורים שהשתנו. הדרייבר אינו מחליט כיצד נראה הכפתור; הוא יוצר מסלול אמין מן הזיכרון אל הפאנל. זו הסיבה ש־Simulator יכול להיראות מושלם בזמן שהמסך האמיתי נשאר שחור: הסצנה נכונה, אבל המסלול הפיזי עדיין אינו מוגדר נכון.

מעל הדרייבר פועל מנוע הציור. הוא מקבל הוראה לצייר מלבן, טקסט, תמונה או שכבת שקיפות ומחשב אילו ערכי צבע צריכים להיכתב ל־Framebuffer. מעליו נמצאת ספריית GUI כמו LVGL או TouchGFX. היא מנהלת את הכפתורים, המסכים, האירועים והאזורים שהשתנו. מעליה נמצאת לוגיקת הממשק, שמחליטה כי הטמפרטורה החדשה צריכה לשנות מספר, צבע או מחוון. כל שכבה יודעת פחות על החומרה ויותר על משמעות המוצר.

ניקח דוגמה מלאה. המפעיל נוגע בכפתור שמעלה את טמפרטורת היעד. בקר המגע מודד נקודה, דרייבר המגע מתרגם אותה לקואורדינטות וספריית ה־GUI מזהה שהנקודה נמצאת בתוך הכפתור. לוגיקת הממשק שולחת בקשה לבקר המכונה; הבקר בודק שהערך מותר ומחזיר יעד מאושר. הספרייה מסמנת את המספר והמחוון ככאלה שצריך לצייר מחדש. מנוע הציור כותב את הפיקסלים החדשים ל־Framebuffer, בקר התצוגה קורא אותם, הפאנל משנה את האור ולבסוף העין רואה תגובה. עכשיו אפשר לשאול בכל תחנה מה צורך זמן, מי מחזיק את הנתון ומה קורה אם הוא נעצר.

התחנה הראשונה שבה אפשר לחסוך או לבזבז הרבה עבודה היא מנוע הציור. במסלול תוכנתי אין מנוע גרפי ייעודי: ה־CPU שמריץ את קוד המוצר מחשב גם את הצבעים, השקיפויות, הקווים והטקסט. היתרון הוא חומרה פשוטה וקוד שניתן להעביר בין הרבה מיקרו־בקרים. המחיר הוא שכל פיקסל מתחרה עם לוגיקת המוצר על זמן מעבד ועל רוחב הפס לזיכרון. מסך קטן עם מספרים וכפתורים יכול לעבוד מצוין כך; מסך גדול עם צללים ואנימציות עלול לבלוע את התקציב.

השלב הבא הוא מאיץ דו־ממדי. זהו מנוע חומרה קטן שיודע לבצע פעולות שחוזרות בכל ממשק: מילוי אזור בצבע, העתקת תמונה, ערבוב שקיפות והמרה בין פורמטים. ה־CPU מכין לו עבודה וממשיך לעסוק בדבר אחר. אם המאיץ אינו יודע לסובב תמונה או לצייר צורה מסוימת, אותה פעולה חוזרת למסלול התוכנתי. מרוויחים זמן מעבד, אבל מקבלים אתגר חדש: צריך לסנכרן בין CPU, מאיץ, Cache וזיכרון חיצוני כדי שכולם יראו את אותה גרסת תמונה.

כאשר רוצים שינויי גודל, סיבוב, טקסטורות, וקטורים או תלת־ממד, נכנס GPU רחב יותר. במקום לתת לו העתקה אחת, התוכנה בונה רשימת פקודות ומשאבים והוא מצייר פעולות רבות במקביל. כך אפשר לקבל ממשק עשיר וחלק, אך נוספת ערימה של Driver, זיכרונות פקודה וטקסטורה וכלי ניתוח. GPU חזק שאינו מקבל Driver מתאים ל־Kernel, לזיכרון ול־Framework עלול להישאר כמעט לא מנוצל. המילה GPU בדף המוצר אינה מדד; רשימת הפעולות המואצות והמסלול שחוזר לתוכנה הם המדד.

LVGL ו־TouchGFX יושבים מעל האפשרויות האלה; הם אינם המנוע הפיזי שמזיז את הפיקסלים. אותו LVGL יכול לצייר בעזרת ה־CPU, למסור חלק מן העבודה ל־PXP או VGLite של NXP, ל־D/AVE 2D של Renesas או ל־DMA2D במשפחת STM32, ובמערכת Linux להשתמש גם ב־OpenGL ES. גם TouchGFX יכול לצייר בתוכנה או להשתמש ב־Chrom-ART וב־NeoChrom בהתאם לדגם STM32. לכן השוואה בין ספריות GUI והשוואה בין מנועי חומרה הן שתי החלטות מחוברות, אך שונות.

על מעבד שמריץ Linux אותה זרימה מקבלת עוד שכבות. היישום משנה ערך, Qt או LVGL יוצרים עבודת ציור, מנוע תוכנתי או GPU מרנדר אותה, ותת־המערכת DRM/KMS מנהלת את משטחי התמונה ואת החיבור למסך. EGL מחבר בין היישום לממשק הגרפי, ו־Wayland יכול להוסיף Compositor שמרכיב כמה חלונות. כאשר כל השרשרת נתמכת היטב מתקבלים ביצועים ובידוד בין תהליכים. כאשר Driver ה־GPU אינו מתאים ל־Kernel או ל־BSP, מעבד חזק יכול ליפול לציור תוכנתי ולהרגיש איטי יותר ממערכת MCU שתוכננה היטב.

גם הזיכרון צריך הסבר במספרים. מסך של 800 על 480 פיקסלים בצבע RGB565 שומר שני בתים לכל פיקסל, ולכן Framebuffer מלא דורש 768,000 בתים. שני Buffers דורשים 1,536,000 בתים, עוד לפני פונטים, תמונות, Stack, ‏Heap ולוגיקת המוצר. רק סריקת מסך כזה 60 פעם בשנייה קוראת בערך 46 מגה־בייט בשנייה; הציור עצמו מוסיף קריאות וכתיבות. זו הסיבה שמהירות ה־RAM ורוחב הפס של האפיק חשובים לא פחות מכמות הזיכרון הרשומה בכותרת.

יש שלוש דרכים נפוצות לנהל את התמונה. Buffer יחיד חוסך RAM, אך המעבד עלול לכתוב בזמן שבקר התצוגה קורא וליצור Tearing — קו שבו חצי מסך שייך לתמונה הישנה וחצי לחדשה. Double Buffer נותן לציור דף אחד ולמסך דף אחר ומחליף ביניהם בזמן מתאים, במחיר של פי שניים זיכרון. Partial Buffer מחזיק רק רצועה או אזור קטן ומעביר אותו לפאנל בחלקים; הוא יכול לאפשר מוצר זול בלי RAM חיצוני, אבל מגדיל את מספר ההעברות ואת הסיכון לפספס את קצב הסריקה. ב־60 הרץ נשארות בערך 16.7 אלפיות שנייה להשלים תמונה.

עכשיו אפשר לנסח דרישות מוצר בלי להתחיל בשם Framework. מה צריכה המכונה להציג, כמה מהר הנתונים משתנים, האם יש גרפים, וידאו או רק מספרים, ומהו הזמן המותר מן הלחיצה עד לתגובה? כמה שניות מותר לחכות לאחר חיבור מתח, ומה חייב להמשיך לעבוד בזמן שהמסך עולה מחדש? האם נדרש מסך ראשון בתוך חצי שנייה, או שמותר ל־Linux ולאפליקציה להשלים אתחול ארוך יותר? כל תשובה מזיזה את הבחירה בין MCU קטן, MCU עם מאיץ, MPU עם Linux או פלטפורמת Android.

לצד הביצועים צריך לשאול איך מתקנים ומעדכנים. האם ניתן להחליף את יחידת התצוגה בלי לפרק את בקרת המכונה? האם עדכון GUI יכול להיכשל בלי להשבית את המוצר? האם קיימת דרך לחזור לגרסה קודמת, והאם אפשר לראות ביומן איזה צד לא עלה? הפרדת המעבדים מאפשרת גם פיתוח מקביל: צוות ה־HMI עובד מול סימולטור של הבקר, וצוות הבקרה עובד מול כלי שמדמה את התצוגה. כל צוות יכול לבנות, לבדוק ולתקן את הצד שלו לפני שהחומרה השלמה זמינה.

המודל מזכיר Full Stack, אך עובר התאמה לעולם Embedded. מעבד התצוגה הוא Client שמבקש פעולות ומציג מצב. מעבד הבקרה הוא Server שמחזיק את האמת על החיישנים והמפעילים. הפרוטוקול ביניהם הוא API עם פקודות, תשובות וגרסה. ההבדל הוא שה־Server אינו שירות ענן שאפשר לרענן; הוא מחובר למנוע ולגוף חימום. לכן ניתוק תקשורת, הודעה כפולה, Timeout או Client מגרסה ישנה חייבים לקבל התנהגות מוגדרת, ולא רק הודעת שגיאה במסך.

גם הרכש והתקינה נובעים מן הארכיטקטורה ולא מגיעים כרשימת בדיקות בסוף. נניח שמעבד התצוגה נעלם מן השוק. במערכת מאוחדת צריך להעביר גם את ה־GUI, גם את הלוגיקה, גם את הדרייברים ולעיתים גם את תיק התקינה. במערכת מפוצלת אפשר להחליף את לוח התצוגה כל עוד החוזה נשמר, אך עדיין צריך לבדוק EMC, בטיחות, זמני עלייה והתנהגות בזמן ניתוק. ההפרדה אינה מוחקת את האישור; היא מצמצמת את שטח השינוי שצריך להסביר ולבדוק.

גם ידע הצוות הוא משאב חומרה כמעט כמו RAM. צוות שמכיר C, ‏RTOS וניתוח Timing עשוי להגיע מהר יותר עם ספרייה קלה על MCU. צוות שמכיר Qt, ‏Linux ו־GPU Drivers יכול לנצל MPU בלי להיבהל מ־Yocto או DRM. צוות Frontend יכול לבנות מסך יפה במהירות, אך יזדקק למהנדס מערכת שיגדיר את הגבול אל החומרה. כלי נוצץ אינו מקצר לוח זמנים כאשר אף אחד אינו יודע לנתח את השכבה שמתחתיו.

מכאן מתחיל סקר השוק, אבל לא בשאלה מי הטוב ביותר. לכל יצרן יש דרך לפתור כאב מסוים. השאלה היא אם הכאב שלו דומה לכאב של המוצר שלכם, ומה קורה ביום שבו תרצו לעבור שבב, מסך או כלי. נבחן כל מסלול דרך אותה תבנית: איזו בעיה הוא פותר, כיצד הוא עושה זאת ואיזה אתגר חדש הוא מכניס.

ניקח צוות שבחר MCU מסוג i.MX RT של NXP ורוצה לעצב מסכים בלי לכתוב כל Widget ביד. GUI Guider של NXP מאפשר לבנות ממשק חזותי, לייצר קוד C המבוסס על LVGL ולשלב אותו בפרויקט MCUXpresso. בחומרה מתאימה אפשר להפעיל מאיצים כמו PXP או VGLite כדי להעביר חלק מעבודת הפיקסלים מן ה־CPU. הבעיה של זמן ההקמה מתקצרת, אך האחריות על החיבור המדויק בין הלוח, הפאנל, הזיכרון והגרסה נשארת. פרויקט לדוגמה על לוח נתמך הוא נקודת פתיחה, לא הוכחה למוצר מותאם.

ב־Renesas אפשר להגיע לאותה מטרה במסלול אחר. חבילת FSP למשפחת RA כוללת תמיכה ב־LVGL, ב־GUIX וב־emWin, וכלי QE for Display עוזר להגדיר את בקר ה־LCD ולחבר את emWin ו־AppWizard לפרויקט. בדגמים מתאימים מנוע D/AVE 2D מאיץ את הציור. היתרון הוא שסביבת הפיתוח מכירה את רכיבי התצוגה של המשפחה. המחיר הוא שצריך לבדוק איזו ספרייה, איזו גרסת FSP ואיזה מאיץ נתמכים דווקא ב־MCU שנבחר; המילה Renesas אינה תצורה.

Microchip פותרת את בעיית הפיצול בין כלי העיצוב, הדרייברים והפרויקט בעזרת Microchip Graphics Suite בתוך MPLAB Harmony. ‏MGS Composer מספק עורך חזותי, והספריות משתלבות עם MCU ו־MPU של החברה, עם RTOS או Bare Metal ובחלק מן המסלולים גם עם Linux. זה מתאים לצוות שכבר חי בתוך MPLAB ורוצה שגרף הפרויקט וה־GUI ידברו באותה שפה. המחיר הוא תלות עמוקה יותר ב־Harmony ובמבנה הפרויקט שלו; הבטחה לניידות בין משפחות Microchip אינה הבטחה למעבר חופשי לכל יצרן אחר.

ב־STM32 המסלול המקביל הוא TouchGFX. ה־Designer, ‏CubeMX ותבניות הלוחות יכולים לחבר את ה־GUI ל־LTDC, ל־DMA2D שנקרא Chrom-ART ולמאיץ NeoChrom בדגמים המתאימים. עבור צוות שכבר בחר STM32 זו יכולה להיות הדרך הקצרה ביותר ממסך מצויר לחומרה עובדת. האתגר מופיע כאשר חורגים מן הלוח הנתמך או משנים גרסת כלי: קוד שנוצר, Linker Script והגדרות זיכרון צריכים לעבור Diff ובדיקה. האינטגרציה העמוקה היא היתרון, והיא גם מקור התלות.

אם צוות העיצוב צריך לעבוד באופן דומה מעל כמה משפחות שבבים, קיימים פתרונות מסחריים כמו Qt for MCUs, ‏Embedded Wizard ו־Crank Storyboard, ולצדם פתרונות חדשים יותר כמו Slint. הם מנסים להפריד בין תיאור הממשק לבין המימוש המדויק על החומרה ולתת כלי עבודה משותף למעצב ולמפתח. זה יכול לחסוך בניית תשתית וכלי עיצוב פנימיים. המחיר עובר לרישיון, ל־Runtime, לזמינות קוד המקור ולשאלה אם הלוח והמאיץ המדויקים נתמכים ברמת ייצור ולא רק בדמו.

כאשר הממשק כבר צריך וידאו, דפדפן, כמה תהליכים, אחסון גדול ורשת עשירה, ייתכן שהבעיה כבר גדולה מדי ל־MCU. כאן Embedded Linux פותר צורך אמיתי: הוא מביא ניהול תהליכים, קבצים, דרייברים, מולטימדיה וכלי פיתוח. Qt Quick יכול לרוץ במסך מלא מעל EGLFS, ומערכת עם כמה יישומים יכולה להשתמש ב־Wayland. המחיר אינו רק RAM ומעבד; הוא BSP, בניית Image, זמן Boot, עדכוני אבטחה והתאמה ארוכת שנים בין Kernel ל־GPU Driver.

Android מוסיף עוד קומה מעל Linux: סביבת אפליקציות, מגע עשיר, WebView, מולטימדיה ומנגנוני מערכת רחבים. מתחת למסך פועלים SurfaceFlinger, ‏BufferQueue, ‏Hardware Composer ו־HALs שמחברים את Android לחומרה. זו בחירה הגיונית כאשר המוצר באמת צריך את עולם האפליקציות או כאשר לצוות כבר יש מומחיות Android עמוקה. למסך יחיד של מכונה זו עלולה להיות ערימה גדולה מדי. AOSP פתוח אינו מוצר מוכן; עדיין צריך BSP, זמן עלייה, אחסון, בדיקות ועדכוני אבטחה.

אפשרות מפתה נוספת היא לכתוב את ה־UI בטכנולוגיות Frontend: ‏HTML, ‏CSS ו־JavaScript, לעיתים עם React, ולהציג אותו בתוך Chromium, ‏Qt WebEngine או Android WebView. היתרון ברור: מאגר מפתחים גדול, כלי עיצוב מצוינים ואפשרות לפתח את המסכים בנפרד מן החומרה. זה גם מתחבר יפה למודל Client ו־Server. אבל אל המוצר נכנסים מנוע דפדפן שלם, תלויות רבות, תהליך או שרת מקומי ושרשרת קבועה של תיקוני אבטחה. מה שנראה כמו חיסכון בחודש הראשון עלול להפוך לחבילת תוכנה גדולה שצריך לתחזק במשך עשור.

האינטגרציה בין Frontend ללוגיקת המכונה היא הנקודה המסוכנת. אם JavaScript מקבל גשר ישיר ל־GPIO, לקבצים או לפקודות תנועה, טעות בבדיקת מקור, בהרשאה או בקלט הופכת את שכבת התצוגה לשער אל המוצר. תיעוד Android מזהיר שגשר WebView לא מוגן יכול לאפשר ל־JavaScript להפעיל קוד מקומי בהרשאות האפליקציה. פתרון Web אינו בלתי מאובטח מעצם היותו Web, אך הוא צריך API מצומצם ומאומת, תוכן מהימן, הפרדת הרשאות, ביטול Debug בייצור ותהליך לעדכון מנוע הדפדפן והתלויות.

כשקוראים פורומים, Issues ורשימות Known Issues, אותן משפחות של בעיות חוזרות תחת שמות שונים. ה־Simulator נראה מצוין אבל המסך האמיתי שחור; המגע עובד אך מסובב ב־90 מעלות; האנימציה חלקה עד שמגיע עדכון מן הרשת; והמערכת קורסת רק כאשר שני Tasks משנים Label באותו זמן. תלונה אחת אינה מדד איכות לשום Framework. אוסף התלונות כן מלמד איפה לשים מדידות ושומרי גבול בפרויקט.

המשפחה הראשונה היא מסלול הפיקסלים: כתובת Framebuffer לא נכונה, Stride שאינו מתאים לרוחב השורה, Pixel Format שונה בין הספרייה לפאנל או העברה שאינה מסתיימת לפני הסריקה הבאה. אחריה מגיעות תקלות Cache ו־DMA, שבהן ה־CPU, המאיץ ובקר התצוגה אינם מסכימים איזה עותק של התמונה הוא החדש. המשפחה השנייה היא בעלות על זמן: Callback ארוך חוסם את לולאת ה־GUI, שתי משימות נוגעות באותו אובייקט, או מחולל קוד מחזיר הגדרה ישנה. המסך רק חושף את התקלה; השורש נמצא בחוזה בין השכבות.

יש גם סיכון שמגיע מן הקהל עצמו. מפעיל עם כפפות, יד רטובה, שמש על המסך או אזעקה ברקע אינו משתמש כמו המהנדס ליד שולחן. כפתור קטן, צבע שהוא האינדיקציה היחידה, הודעת שגיאה באנגלית או אישור שמופיע מאוחר יכולים להפוך תקלה טכנית לטעות אנוש. HMI טוב מונע פקודה בלתי אפשרית ומבדיל בין פעולה רגילה לפעולה מסוכנת. במוצר בטיחותי אסור שהאנימציה היפה תהיה המקור היחיד לאמת; הבקר צריך להחליט אם הפעולה מותרת.

לפני שמשווים פתרונות צריך לומר מה מנסים לבחור: לא את ה־Framework המהיר ביותר במבחן כללי, אלא את הארכיטקטורה הנכונה עבור הלקוח והמוצר. לקוח אחד צריך מסך ראשון בתוך חצי שנייה, אחר צריך וידאו, ושלישי צריך עשר שנות תיקונים ומקור חלופי. ההשוואה הבאה נועדה לחשוף את הפער בין ההבטחה לבין הדרישה: האם הפתרון עומד בחוויית המשתמש, במחיר היעד, בתהליך הייצור, ביכולת הצוות ובהתנהגות בזמן כשל.

לכן מתחילים במסך מבחן שמייצג את המוצר: שלושה מסכים, גרף שמתעדכן, עברית, מגע, אנימציה והתראה. מודדים זמן מן המתח עד למסך מגיב, זמן ממגע עד פיקסל, RAM ו־Flash, זמן Frame ממוצע ובמקרה הגרוע, עומס CPU ו־GPU, צריכת חשמל וזמן Build. אחר כך מנתקים את המסך, מעכבים הודעה, ממלאים את התור, מפילים את אפליקציית ה־GUI ועוצרים עדכון באמצע. המדד החשוב אינו רק כמה פריימים התקבלו, אלא מה המכונה עשתה כאשר הממשק לא היה במיטבו.

הבחירה המעשית כבר אינה מתחילה בשם. ממשק קטן, זמן עלייה קצר וחומרה זולה מצביעים בדרך כלל על MCU עם מנוע GUI שמתאים לידע הצוות ולמאיץ הזמין. רצון לעבור בין יצרנים נותן משקל לספרייה פתוחה או לפתרון רב־פלטפורמי; אינטגרציה עמוקה אצל יצרן אחד יכולה לחסוך זמן כאשר שרשרת האספקה והחומרה כבר נקבעו. גרפיקה עשירה, רשת ומולטימדיה מצביעים על Embedded Linux, ו־Android מוצדק כאשר באמת נדרש עולם האפליקציות שלו. מעל הכול נשארת שאלת הכשל: האם מסך שנפל רשאי להפיל גם את המכונה?

החלק המעניין פה הוא שה־Framework הוא רק הקומה העליונה. מתחתיו נמצאים חוזה האחריות בין התצוגה לבקרה, האור בפאנל, הממשק החשמלי, בקר התצוגה, ה־Framebuffer, מנוע הציור, הדרייבר והמפעל שצריך לצרוב ולבדוק הכול. HMI טוב אינו הממשק המרשים ביותר שאפשר להציג על לוח פיתוח. הוא הממשק הקטן ביותר שנותן למשתמש את החוויה הנדרשת, משאיר למכונה התנהגות מוגדרת בזמן תקלה ואינו הופך את המסך למקור החוב הגדול ביותר במוצר.