כיצד לבצע עדכונים דרך-האוויר (OTA‏) באמצעות המיקרו-בקר ESP32‏ וה- ESP-IDF‏ שלו

המתכננים של מוצרי אינטרנט של דברים (IoT‏) צריכים להעריך בהתמדה את בחירת הפלטפורמות והרכיבים במטרה להוריד את העלות וההספק תוך שיפור הביצועים והאצת התכנון של יישומי חיבוריות. כיום יש לא מעט פתרונות לבחירה, אך המתכננים מתמודדים עם האתגר לבצע עדכונים אלחוטיים דרך-האוויר (OTA) על מנת לשמור על הקושחה של ההתקן מעודכנת לאחר הפרישה.

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

מאמר זה דן ביסודות ה- OTA ומדוע זוהי פונקציה קריטית שכמעט כל מערכת IoT צריכה לתמוך בה, למרות האתגרים העומדים בפני המפתחים. לאחר מכן המאמר משתמש בבקר מאופשר Bluetooth‏ ו- Wi-Fi‏ ESP32‏ מבית Espressif Systems, עם ערכות ומודולים קשורים ועם ה- ESP IoT Development Framework‏ (ESP-IDF‏), כדי להראות כיצד ליצור חלוקות OTA ולהשתמש בסקריפט otatool.py לביצוע עדכון קושחה כשהיישום עדיין בפעולה.

מבוא לעדכוני OTA‏

רוב צוותי הפיתוח מתמקדים ביישום המאפיינים הספציפיים של המוצר שלהם, כלומר ההיגיון העסקי המבדל את המוצר שלהם. עם זאת, לכל מוצר IoT יש מערך מאפיינים בסיסי שצריך לממש, להגדיר ולתחזק לאורך כל חיי ההתקן. עדכוני אבטחה הם דוגמה טובה. בהתחשב בצורך לבצע עדכונים אלה, מאפיין חשוב אך כזה שאפשר בקלות להתעלם ממנו כאשר מעריכים פלטפורמת פיתוח מתאימה הוא עדכון ה- Bootloader‏ או ה- OTA‏ של הקושחה (המכונה לעיתים רק OTA).

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

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

איור 1‏: ארכיטקטורת OTA‏ המציגה תהליך לדוגמה עבור עדכון קושחת יישום בשטח להתקנים פרושים. (מקור התמונה: Beningo Embedded Group)

בדוגמה זו, OEM משתמש ב- IoT Core של (Amazon Web Services (AWS כדי להעלות גרסות קושחה חדשות ולאחר מכן משתמש ביכולות ה- Job המובנות להתקנת העדכונים בהתקנים בשטח. זוהי רק דוגמה אחת מנירבות, וכמעט לכל ספק ענן יש פתרון דומה.

ישנן אפשרויות מיקרו-בקר רבות התומכות ב- OTA הזמינות כיום. מיקרו-בקר פופולרי הן למערכות בעלות נמוכה והן בקרב יוצרנים (Makers) הוא ה- ESP32. ישנן מספר סיבות לכך שה- ESP32 הוא כה פופולרי, כולל:

• יש לו מיקרו-בקר משולב עם מודולי הרשאה Wi-Fi/Bluetooth זמינים
• עלות נמוכה
• סביבת פיתוח בקוד-פתוח ומסגרות-עבודה לתוכנה כגון ESP-IDF ו- ESP Audio Development Framework‏ (ESP-ADF‏)
• דוגמאות רבות של יישומים קיימים זמינות חינמית באינטרנט

בחירת מודול ESP32 לבדיקת OTA

ישנם מספר מודולים ולוחות פיתוח ESP32 שונים שמשתמשים יכולים לרכוש כדי לבחון דוגמאות של OTA. קח לדוגמא את לוח Huzzah Feather‏ ESP32‏ 3405‏ מבית Adafruit (איור 2). זהו לוח פיתוח בעלות נמוכה הכולל את כל המעגלים כדי לתכנת את ה- ESP32 ולהזין אותו באמצעות מחבר USB.

איור 2‏: לוח Huzzah Feather‏3405 כולל מודול Wi-Fi/Bluetooth‏ מורשה ESP32 WROOM-32D‏ עם Mbytes‏ 4 של זיכרון Flash‏. הלוח כולל את כל החומרה הדרושה לתכנות ותקשורת עם המודול באמצעות USB. (מקור התמונה: Adafruit)

בליבת ה- 3405 נמצא מודול ESP32-WROOM-32D המגיע עם זיכרון Flash‏ של Mbyte‏ 4‏, Wi-Fi, Bluetooth ומערך היקפי שלם עבור כמעט כל יישום.

לוח פיתוח נוסף שניתן להשתמש בו הוא לוח האודיו ESP32-LYRATD-SYNA‏ מבית Espressif Systems (איור 3). לוח פיתוח זה כולל את מודול ESP32-WROVER-B‏.

איור 3: לוח ESP32-LYRATD-SYNA מבוסס על מודול Wi-Fi/Bluetooth מורשה SP32 WROVER-B עם זיכרון Flash‏ של Mbytes‏ 4‏. הוא מאפשר למתכננים לתכנת ולתקשר עם המודול באמצעות USB, ויש לו גם את המעגל הדרוש לפיתוח יישומי אודיו. (מקור התמונה: Espressif Systems‏)

למודול ESP32-LYRATD-SYNA יש גם זיכרון Flash‏ של Mbytes‏ 4‏, כמו גם את כל המעגלים עבור יישומי אודיו. הלוח כולל Codec אודיו, מגבר אודיו ושקעי אוזניות ורמקולים לבדיקה מלאה של יישומי אודיו.

לוח פיתוח אחרון שיכול לשמש לבדיקת OTA הוא לוח הפיתוח ESP32-S2-SAOLA-1RI מבית Espressif (איור 4). כשזה מגיע ללוחות פיתוח, זה הכי פחות יקר. הלוח מכיל מודול ESP32 Wrover ביחד עם המעגל לתכנות השבב. אין שום מאפיינים מיותרים מעבר לפינים המאפשרים להכניס אותו בקלות ללוח אב-טיפוס לצורך בדיקה.

איור 4: ה- ESP32-S2-SAOLA-1RI, המבוסס על מודול Wrover‏, הוא לוח פיתוח עירום בעלות נמוכה אך כולל מספיק מעגלים כדי לתכנת את המודול על-הלוח.. (מקור התמונה: Espressif Systems‏)

הלוח הספציפי שנבחר לבדיקה לא משנה יותר מדי מכיוון שכל מודול ESP32 ממנף את ה- ESP-IDF. מסגרת-עבודה זו נועדה להקל על פעילויות פיתוח תוכנה עבור מפתחים על ידי הכללת מנהלי התקנים, חומרת-ביניים (Middleware)‏, RTOS, וחשוב במיוחד למטרות מאמר זה, Bootloaders‏, כמו גם ספריות OTA.

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

תהליך עבודה של פיתוח OTA‏

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

באופן כללי, תהליך כינון של עדכון OTA ב- ESP32 כולל את השלבים הבאים:

1. הגדרת התצורה של טבלת החלוקות של ה- ESP32‏
2. הורדת קושחה התומכת ב- OTA
3. פיתוח כלי הפועל כשרת ודוחף קושחה חדשה
4. הורדת הקושחה העדכנית ביותר ל- ESP32
5. החלפה ליישום החדש

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

• HTTPS OTA
• OTA‏ טבעי
• OTA פשוט
• כלי OTA‏ (דוגמה של סקריפט Python‏)

איור 5 מציג את שלבי תהליך המימוש והעדכון. המפתח יצטרך לבצע את השלבים באדום תחילה כדי לממש את פתרון OTA במודול ESP32. השלבים בכתום הם הבאים והם מתבצעים כדי להקל על עדכון OTA.

איור 5: דוגמאות עדכון OTA מבית Espressif Systems הנמצאות ב- GitHub מספקות למפתחים מספר דוגמאות פשוטות להבאת ה- ESP32 שלהם לבצע עדכוני OTA. (מקור התמונה: Espressif Systems‏)

הגדרת יישום ESP32 עבור OTA

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

טבלה 1‏: טבלת חלוקות ESP32‏ סטנדרטית המראה איזה סוג נתונים והיכן הוא ממוקם במיקרו-בקר. (מקור הטבלה: Beningo Embedded‏)

יש את אפליקציית factory ולאחר מכן מקטע עבור ספריית NVS‏ ונתוני האתחול (init) של השכבה הפיזית (PHY). על מנת להשתמש בפונקציונליות OTA, יש לעדכן טבלה זו כך שיהיו מקומות זיכרון מוגדרים עבור קושחת עדכון OTA, בנוסף לאפליקציה הראשית (factory). עבור OTA, בדרך כלל ישנן שתי חלוקות המוקצות עבור עדכונים. חלוקה אחת היא עבור הקושחה המעודכנת הפעילה, וחלוקה שנייה היא עבור הקושחה שהורדה ואשר תהפוך לגרסה העדכנית ביותר. זה מאפשר לאפליקציית factory להישאר ללא שינוי. טבלת חלוקות OTA‏ מעודכנת תיראה כמו טבלה 2‏.

טבלה 2‏: טבלת חלוקות OTA‏ מעודכנת טיפוסית של ESP32‏. (מקור הטבלה: Beningo Embedded‏)

כפי שמוצג, יש כעת מקטעי אפליקציה ota_0 ו- ota_1 בגודל של Mbyte‏ 1‏, בנוסף לקטע נתונים (otadata) שהוא זיכרון RAM המוקצה עבור תהליך העדכון. טבלה זו ניתנת לשינוי ועדכון על ידי המפתח כדי להתאים ליישום.

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

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

• קריאה, כתיבה ומחיקה של חלוקות OTA‏
• החלפת חלוקות Boot
• החלפה לחלוקת factory

את סקריפט הדוגמה ניתן לבצע פשוט על ידי הרצת הדוגמה במסוף באמצעות הפקודה:

./otatool_example.sh

או באמצעות Python‏:

python otatool_example.py

כשזה מגיע להגדרת ה- ESP32 עבור OTA, יש לוודא שהחלוקות מוגדרות, וזה שלב קריטי.

טיפים וטריקים לשימוש

פתרון EPS32 OTA יכול להאיץ ולפשט את פתרון עדכוני הקושחה של המפתח. כדי למנוע מהפתרון להפוך לנטל על הפיתוח, יש לזכור מספר "טיפים וטריקים":

• במידת האפשר, יש למנף את מסגרת-העבודה הקיימת של ה- OTA‏ הכלולה אצל ספק הענן של החברה. זה יכול לפשט דרמטית את הפיתוח והאינטגרציה.
• יש להשתמש בלוח פיתוח בעלות נמוכה לבדיקת יכולות ו- Bootloaders‏. ל- ESP32 יש מספר אפשרויות, וייתכן שיידרשו כמה ניסיונות כדי לקבוע איזו מהן מתאימה ביותר עבור היישום המדובר.
• עבור פתרונות מותאמים-במיוחד, ניתן למנף את דוגמאות OTA‏ ESP32‏ שב- GitHub‏.
• עבור יישומים שבהם המוצר משמש כנתב או רכזת Wi-Fi, יש לשקול להוריד את תמונת הקושחה לזיכרון חיצוני ולבצע את העדכון מתוך התקן אחסון בנפח גדול.
• יש להקדיש זמן לבדיקת תיעוד ESP32 בנושא טבלת החלוקות. זה שונה מעט מאשר מימוש מיקרו-בקר טיפוסי.
• מטעמי אבטחה, עדיף להשבית את החזרת היישום לגרסה קודמת. אם היישום יכול לחזור לגרסה קודמת, תוקפים פוטנציאליים עלולים לדחוף גרסה עם אקספלויט ידוע ולסכן את המערכת.

המפתחים שיעקבו אחר "טיפים וטריקים" אלה יגלו שהם חוסכים לא מעט זמן וצער בעת ניסיון למנף את ESP32, או כל פתרון OTA‏ אחר, לפי העניין.

סיכום

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

בקר האלחוט ESP32 מצא את דרכו למגוון רחב של התקנים, וכפי שהוצג יש לו פתרון OTA מן-מוכן. על ידי ניצול ה- ESP-IDF והמודולים והפלטפורמות הקשורים, כמו גם שימוש במספר טיפים וטריקים מבוססי-ניסיון, המפתחים יכולים לקצר דרמטית את זמן התכנון ולהביא את פתרון OTA משלהם עצמם לפעולה.