הרגע שבו מאבדים שליטה על הקושחה

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

סכמת גרסאות שאומרת משהו

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

צריבה בייצור: הגרסה היא חלק מהמפרט

קובץ הקושחה שנצרב בפס הייצור חייב להיות מתועד בהוראת הייצור כמו כל רכיב ברשימת הרכיבים — כולל גרסה, סיכום הצפנתי של הקובץ ותצורת ברירת מחדל. תחנת הצריבה צריכה לאמת אחרי הצריבה שהקוד שנכתב הוא הקוד שנשלח, ולרשום לכל מספר סידורי איזו גרסה קיבל ומתי. פרקטיקה מומלצת היא "קושחת ייצור" רזה שנצרבת במפעל ומריצה בדיקות קו, ורק בהפעלה הראשונה או בתחנה האחרונה נטענת קושחת המוצר המלאה. את היסודות של מנגנון הטעינה עצמו כיסינו במאמר על Bootloader במיקרו-בקר, ומי שחדש בעולם הזה יכול להתחיל מהמאמר מה זו קושחה.

עדכונים בשטח: משמעת של הדרגה

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

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

עקיבות: לוח מחוונים אחד לכל הצי

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

לבנות את זה נכון מהיום הראשון

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

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