מוצר חכם שיוצא מהמפעל אף פעם לא נשאר קפוא. מתגלים באגים, מתווספות יכולות, ומשתנות דרישות של יצרני מערכות ההפעלה ושל הרגולציה. עדכון קושחה דרך אפליקציה, המוכר בשם DFU (Device Firmware Update), הוא המנגנון שמאפשר לשלוח גרסת תוכנה חדשה למיקרו-בקר שבתוך המוצר ישירות מהטלפון של המשתמש, בלי מעבדה ובלי החזרת יחידות לשירות. אנחנו בפרוג'קטס האוס מתייחסים אליו כאל דרישת יסוד בכל מוצר מחובר, לא כאל תוספת נחמדה. אם עדיין לא החלטתם אם בכלל צריך אפליקציה נלווית, כדאי לקרוא קודם האם המוצר שלכם באמת צריך אפליקציה נלווית, ואז לחזור לכאן לפרטים הטכניים.

איך תהליך העדכון עובד שלב אחר שלב

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

  • משא ומתן על יכולות: המוצר מדווח על גודל הזיכרון הפנוי, גרסת ה-bootloader והפרוטוקול שהוא תומך בו.
  • העברה במנות: בבלוטות' BLE הקובץ נשלח במנות של 128 עד 512 בתים, עם אישור קבלה כל כמה עשרות מנות.
  • אימות שלמות: בסוף ההעברה מחושב סיכום ביקורת, לרוב CRC32 או גיבוב קריפטוגרפי, ומושווה לערך שהגיע עם הקובץ.
  • בדיקת חתימה: המוצר מוודא שהקושחה נחתמה במפתח היצרן, אחרת הוא פשוט מסרב להתקין.
  • הפעלה מחדש: רק אחרי שכל הבדיקות עברו, ה-bootloader מפנה את הביצוע לגרסה החדשה.

ההבדל בין ערוצי התקשורת דרמטי. תמונת קושחה של 256 קילובייט תעבור ב-BLE בין דקה לחמש דקות, תלוי במרווח החיבור ובטלפון, בעוד שב-WiFi זה עניין של שניות ספורות. על שכבת הבלוטות' עצמה הרחבנו במאמר איך אפליקציה מתחברת למוצר בבלוטות', ועל הצד השני של המשוואה במאמר חיבור המוצר ל-WiFi דרך האפליקציה.

בנק כפול וחזרה לאחור: הביטוח של המוצר

הארכיטקטורה הבטוחה ביותר היא בנק כפול (A/B): הזיכרון מחולק לשני אזורים בגודל זהה, הגרסה החדשה נכתבת לאזור הלא פעיל, ורק בסיום מוצלח מסומן האזור החדש כפעיל. אם המוצר לא מצליח לעלות תקין תוך מספר ניסיונות, ה-bootloader חוזר אוטומטית לגרסה הקודמת. המחיר הוא זיכרון: תמונה של 200 קילובייט דורשת התקן עם לפחות 512 קילובייט זיכרון פלאש, ולעיתים גם רכיב זיכרון חיצוני. זו החלטה שחייבת להתקבל בשלב בחירת הרכיבים, לא אחריה. הבסיס לכל זה הוא ה-bootloader, ומי שרוצה להבין אותו לעומק מוזמן למאמר Bootloader במיקרו-בקר. כדי שאף אחד לא יוכל להזריק קושחה זרה או לשלוף את שלכם, משלבים Secure Boot והצפנת קושחה.

מה קורה כשהעדכון נקטע באמצע

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

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

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

ניהול גרסאות והשקה מדורגת

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

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

כמה עולה לבנות מנגנון עדכון אמין

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

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

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