מה צריך לדעת כשמאפיינים MCU עם תמיכה ב-Wi-Fi

עם התפתחות האינטרנט של הדברים (IoT) התעשייתי, המגמה היא לבצע פונקציות רבות יותר ב-SoC יחיד ולא במכשירים נפרדים מרובים מכיוון שהתוצאה היא חשבון חומרים קטן יותר, פחות סיכון עיצובי וטביעת רגל קטנה יותר, בנוסף ליתרונות אחרים. דוגמה מצוינת היא ה-Wi-Fi MCU שמשלב קישוריות Wi-Fi עם מעבד וה-GPIO הנדרש כדי להתאים לצרכים של מגוון מערכי יישומים. ישנם מספר גורמים שיש לקחת בחשבון בעת אפיון אחד המכשירים הללו וכדי לבצע בחירה נבונה חשוב להבין אותם.

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

לא לשכוח את ה-ADC

המרה מאנלוגי לדיגיטלי היא אחת הפונקציות המוזנחות ביותר בעת אפיון Wi-Fi MCU, למרות שזהו רכיב העיבוד הראשון בשרשרת האותות לאחר הקלט האנלוגי. המשמעות היא שהביצועים שלו משפיעים על המערכת כולה, ולכן חשוב להבין מדדים מרכזיים לגבי ממיר מאנלוגי לדיגיטלי (ADC) וכיצד על יצרן ה-Wi-Fi MCU לטפל בהם.

אחד האפיונים הראשונים שבו מתמקדים המעצבים הוא מספר הסיביות של ה-ADC. הדבר יכול לבלבל מכיוון שבפועל מספר הסיביות יהיה נמוך מזה שבמפרט גליון הנתונים, לפעמים באופן ניכר. מה שיותר חשוב הוא המספר האפקטיבי של הסיביות (ENOB) שיש ל-ADC לביצוע ההמרה. הוא תמיד יהיה נמוך יותר מזה שבמפרט גליון הנתונים, אך הקרבה בין מפרט ה-ENOB לזה שבמפרט גליון הנתונים חשובה מאוד מכיוון שהדבר משתנה במידה ניכרת בין ה-ADCs. ככל שהסיביות הזמינות לביצוע ההמרה פחותות, כך ה-SoC מייצג את אות הקלט במדויק.

בנוסף, כמו כל המכשירים האלקטרוניים, ADCs משפיעים לרעה על יכולותיהם, כולל שגיאות כגון קוואנטיזציה ותזמון, וכן שינויים בקיזוז, רווח וליניאריות. ADCs ידועים לשמצה גם ברגישותם לשינויי טמפרטורה נרחבים הנפוצים בסביבות הפעלת מערכות IoT תעשייתיות רבות (ראו איור 1). יצרן ה-Wi-Fi MCU יכול למתן זאת, לכן חשוב ליצור קשר עם היצרנים של כל מועמד ל-Wi-Fi MCU כדי לקבוע את ה- ENOB שלהם, ביצועים על פני טמפרטורה, ליניאריות ודיוק. אם לא ניתן לספק מידע זה, עדיך להמשיך הלאה.

איור 1. ADCs בדרגה נמוכה הם בעלי דיוק וליניאריות ירודים ורגישים לסביבה וטמפרטורה.

תמיכה היקפית

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

וככל שהמערכת תגדל, סביר להניח שיתווספו לה ממשקים רבים יותר, וייתכן שיגיע זמן בו תידרש תמיכה בתכונות כגון חישת מגע ותמיכה ב-LCD. אם ל-SoC יש GPIO פנוי, ניתן לשלוט על ממסרים, מתגים ורכיבים נוספים אחרים ללא או עם מעט שיתוף פינים. מסיבה זו, על הממשקים הנתמכים של המכשיר לכלול אתרנט MAC, USB, CAN, CAN-FD, SPI, I2C, SQI, UART ו- JTAG (ואולי אף תמיכה בשליחה ותצוגה במגע) כדי להבטיח התאמה לכל תרחיש כעת ובעתיד הקרוב.

האבטחה מתחילה בפנים

האבטחה חיונית לכל יישום IoT, אך תרחישים תעשייתיים הם קריטיים למשימה. ברגע שאיום עושה את דרכו לתוך רשת IoT תעשייתית, הוא יכול לעבור בכל המתקן ואולי בחברה כולה. הרמה הראשונה של האבטחה הנדרשת היא בתוך מנוע הקריפטו המשולב של MCU, בו ההצפנה והאימות מתבצעים ברצף או במקביל. על הצפנים לכלול הצפנת AES עם גדלי מפתח של עד 256 ביט, DES ו-TDES, ועל האימות לכלול SHA-1 ו-SHA-256 ו-MD-5.

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

חשוב לציין כי מרבית ה-Wi-Fi MCUs מאחסנים אישורים בזיכרון פלאש כאשר הנתונים נגישים ופגיעים לתוכנה ולתקיפה פיזית. האבטחה הגבוהה ביותר מושגת באמצעות אחסון מידע זה באלמנט אבטחה בקידוד קשיח מכיוון שלא ניתן לקרוא את הנתונים בתוכנה חיצונית כלשהי. לדוגמה, Wi-Fi MCUs של Microchip כגון ה-WFI32 (איור 2), עושים שימוש בגישה זו בפלטפורמת Trust&GO של החברה לצורך אספקה מאובטחת של ה-MCU שלה לחיבור לרשת AWS IoT, Google Cloud, Microsoft Azure ורשתות TLS של צד שלישי.

איור 2. מודול ה-Wi-Fi WFI32 מבודד אישורים על ידי שמירתם בחומרה, דבר שהופך אותם לבלתי פגיעים לפריצה.

רכיבים מאובטחים שנקבעו מראש, הוגדרו מראש או מותאמים אישית מאחסנים אישורים שנוצרו בתוך מודולי (Secure Hardware (HSM של המכשיר בעת ייצורם, ומבודדים אותם מחשיפה במהלך הייצור ולאחריו. פלטפורמת Trust&Go דורשת ערכת פיתוח זולה של Microchip בלבד שבה המעצב עובד בתוך חבילת העיצוב הכלולה באמצעות הדרכות ודוגמאות קוד ליצירת קובץ המניפסט הנדרש. לאחר שקוד C עבור האלמנט המאובטח עובד ביישום, ניתן לשלוח את העיצוב לייצור.

האופן האחר של האבטחה הנדרשת היא אבטחת ה-Wi-Fi העדכנית שאושרה על ידי ה-Wi-Fi Alliance. הגרסה האחרונה היא WPA3 שבנויה על קודמתה WPA2 בתוספת תכונות שמפשטות את אבטחת ה-Wi-Fi, מאפשרות אימות חזק יותר, מספקות עוצמה קריפטוגרפית מוגברת ושומרות על חוסן הרשת. כל המכשירים החדשים חייבים להיות מאושרים על ידי WPA3 על מנת להשתמש בלוגו Wi-Fi Alliance, כך שכל שבב Wi-Fi ו- Wi-Fi MCU חייבם להיות מאושרים לאבטחה מירבית. עם זאת, יש לבדוק כדי לוודא שה-Wi-Fi MCU המועמד קיבל אישור WPA3.

הבטחת יכולת פעולה הדדית

ישנה תמיד אפשרות ש-Wi-Fi MCU לא יוכל לתקשר עם כמה נקודות גישה בשוק בשל חוסר התאמה בין RF, תוכנה וגורמים אחרים. חוסר היכולת להתחבר לנקודות גישה פופולריות עלולה לפגוע במוניטין של חברה. למרות שלא ניתן להבטיח ש-Wi-Fi MCU יעבוד עם כל נקודת גישה (AP) על פני כדור הארץ, ניתן למזער את הבעיה על ידי הבטחה כי ה-Wi-Fi MCU עבר בדיקות פעולה הדדיות עם נקודות הגישה הפופולרית ביותר בשוק. ניתן למצוא מידע זה באתרי היצרנים, אך אם הוא אינו זמין. יש להתקשר ליצרן ולבקש זאת, ואם הדבר לא מצליח יש לבחור ספק אחר.

תזדקקו לעזרה

אחרון חביב הוא הצורך בתמיכה בעיצוב. ללא פלטפורמה מקיפה של סביבת פיתוח משולבת (IDE), לא נותר למעצב אלא לשלב משאבים מהאינטרנט שעשויים להיות שימושיים, פשוטים או אמינים. לדוגמא, כמה יצרני Wi-Fi MCU מספקים פרטים בסיסיים אודות המוצר והנחיות לאבות טיפוס, אך עוצרים שם במקום לכלול את המידע הדרוש להעברתו משלב זה לייצור.

כדי להיות שימושי באמת, על היצרן לספק IDE מקיף איור 3 שכולל כל פונקציה אנלוגית ודיגיטלית שמבוצעת על ידי ה-Wi-Fi MCU ואת כל הרכיבים החיצוניים הנדרשים להטמעה ביישומים ספציפיים. הוא אמור לספק אמצעי להמחשה כיצד שינויים בתכנון באים לידי ביטוי בביצועים הכוללים וביכולת להעריך את ביצועי ה-RF של העיצוב וכן עמידה בתקנות. חלק מהכלים הבסיסיים הם חינמיים ואילו אחרים זמינים בעלות צנועה, כולל לוחות הערכה שנועדו לשרת את משפחת ה-Wi-Fi MCU של היצרן.

איור 3. פיתוח משולב כמו זה מפחית את הסיכון בכך שהוא מספק למעצב איתור באגים וכלים אחרים משלב

האב-טיפוס ועד המוצר המוגמר.

סיכום

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

שילוב של התקנים אלה פעם אחת לתת-מערכת IoT מוטמעת יכול להיות פשוט יחסית, בהנחה שמספיק משאבים זמינים מיצרן ה-Wi-Fi MCU. הוא כולל רמת אבטחה גבוהה, אמצעים פשוטים כדי להעמידו לרשות צרכי ספקי שירותי הענן, ו-IDE מקיף שמוביל את המעצב מהאב-טיפוס עד לייצור.


מאת אלכס לי, Microchip Technology

תגובות סגורות