ככל שהקושחה של מוצר גדלה, בדיקה ידנית של כל גרסה הופכת לצוואר בקבוק. בדיקות HIL לקושחה (Hardware in the Loop) הן הדרך להריץ בדיקות אוטומטיות על הקוד האמיתי, כשהוא פועל על המיקרו בקר האמיתי ומחובר לחומרה או לסימולציה של הסביבה שסביבו. במקום מפתח שלוחץ כפתורים ומסתכל על נורית, מערכת בדיקה חיצונית מפעילה את המוצר, מזינה לו אותות, מודדת את התגובה ומכריזה על הצלחה או כישלון. אנחנו בפרוג'קטס האוס רואים שוב ושוב באגים שהתגלו רק בייצור, ושסטנד בדיקה פשוט היה תופס אותם כבר בשבוע הראשון של הפיתוח.

מה בדיוק רץ בסטנד HIL

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

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

למה בדיקות על המחשב לא מספיקות

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

איך בונים סטנד מעשי בלי תקציב ענק

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

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

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

מתי ההשקעה מחזירה את עצמה

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

רוצים לדעת אילו בדיקות אוטומטיות באמת נדרשות למוצר שלכם ומה עלות הסטנד? קבלו הצעת מחיר ונבנה יחד תוכנית בדיקות שמתאימה לשלב שבו אתם נמצאים.

רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.