'בישול מוצר מחובר'

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

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

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

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

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

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

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

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

קורס קישוריות

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

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

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

קורס השבבים

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

אם אתה זקוק לקישוריות סלולרית עם צריכת חשמל נמוכה, עם LTE-M או NB-IoT, מכשיר כמו ה- nRF9160 הנורדי הוא חבילה משכנעת של מעבד, זיכרון RAM, פלאש, GPS ומודם. אבל, אם אתה יכול להרשות לעצמך את PCB אולי אתה מעדיף את הגמישות של "תקן" מיקרו ו-LTE נפרד מודול. סיפור דומה חל על תקנים אלחוטיים כמו Wi-Fi ו-Bluetooth, שבהם יש מיקרו-בקרים זמינים עם הרדיו מובנה, וגם מודולים עצמאיים של מודם.

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

קורס הליבה

שלב זה כולל הכנסת תוכנה קיימת (למעשה "צד שלישי") הכוללת: ליבת מערכת ההפעלה (או מערכת הפעלה בזמן אמת); מנהלי ההתקנים של ערכת השבבים; ואת חבילת התמיכה בלוח (BSP) המתאימה מנהלי התקנים אלה עבור עיצוב ה- PCB הספציפי שלך.

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

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

קורס הקוד

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

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

שפת התכנות C הייתה ברירת המחדל כבר כמעט 40 שנה, אבל אולי יש ערך לנסות שפת מערכות בטוחה בזיכרון, כמו Rust או אפילו משהו כמו MicroPython. אבל אם אתה מוצא את ערכת השבבים שלך או Core לא יכולים להתמודד עם הבחירה המועדפת עליך כאן, ייתכן שתצטרך לחזור ולחשוב מחדש.

קורס הענן

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

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

ולבסוף ... קורס Comms

פרוטוקול התקשורת המוגדר כברירת מחדל שהקוד שלך ישתמש בו כדי לדבר עם ספק הענן שלך יהיה בדרך כלל מבוסס טקסט (כגון JSON או XML) שרץ על קישור HTTP מונחה חיבור מוצפן.

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

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

כדאי לזכור

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