אפשרויות פרוטוקול שכבת האפליקציה עבור פונקציונליות M2M‏ ו- IoT‏

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

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

איור 1: פונקציות IIoT באוטומציה תעשייתית מסתמכות על התקנים יותר ויותר מחוברים המשתמשים בפרוטוקולים תעשייתיים עבור רשתות. השכבות המופשטות של רשתות אלה אינן דורשות ידע על פונקציות השכבה שבבסיס ... ולכן כל כך הרבה הנדסת תכנים מתמקדת בשכבה העליונה (היישום) של רשתות מכונות. (מקור התמונה: Getty Images‏)

הגדרת פרוטוקול שכבת-היישום עבור רשתות תעשייתיות

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

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

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

השכבה הפיזית של פרוטוקול מאפשרת העברת נתונים גולמיים (ביטים דיגיטליים) כאותות חשמלים, רדיו או אופטיים. שכבה זו מגדירה את פרישות הפינים, רמות המתח, קצב הנתונים ואימפדנסי הקו של האלמנטים הפיזיים הנושאים את הנתונים. ה- Ethernet‏ הוא פרוטוקול שכבה פיזית נפוץ. קראו את מאמר DigiKey‏ EtherNet/IP לעומת PROFINET למידע נוסף בנושא זה.

שכבת קישור-הנתונים מחברת צמתים ברשת כדי לאפשר להתקנים להקים חיבורים ולתקן שגיאות בשכבה הפיזית. בתוך תקן IEEE 802‏, שכבת קישור-הנתונים מחולקת לשכבת בקרת גישה לתווך (MAC) (שוב, כדי לאפשר להתקנים להתחבר) ושכבת בקרת קישור לוגי (LLC) עבור זיהוי השכבה הבאה שתשמש (שכבת הרשת) כמו גם בדיקת שגיאות וסנכרון. קראו עוד על הפונקציות של שכבת קישור-הנתונים במאמר DigiKey מימוש Ethernet תעשייתי עם מיקרו-בקרים Bit‏-32‏. לעומת זאת, שכבת הרשת מאפשרת העברה של מנות (Packets‏) של נתונים לכתובות הרשת. כאשר פרוטוקולי אינטרנט מתייחסים למודל פרוטוקול בקרת שידור ופרוטוקול אינטרנט (TCP/IP) (המכוסה בפרק הבא במאמר זה) קיימת שכבת אינטרנט בין שכבת קישור-הנתונים לשכבות הרשת. למעשה, שכבת האינטרנט נחשבת לרוב כחלק משכבת הרשת.

הראשונה משלושת השכבות הבאות של מודל OSI היא שכבת ההעברה (TransPort‏), המבטיחה את אמינות התקשורת ואת האבטחה במהלך העברות של רצף-נתונים. ואז שכבת השיח (Session‏) שולטת כאשר ההתקנים מתחברים זה לזה בין אם החיבור הוא חד-כיווני (סימפלקס) או בשני הכיוונים (דופלקס). לבסוף, שכבת ההצגה (Presentation‏) מאפשרת תרגום הנתונים כך שהתקנים המשתמשים בתחבירים (Syntaxes) שונים יכולים לתקשר.

המוקד של מאמר זה - שכבת האפליקציה - היא רמת ההפשטה הגבוהה ביותר וזו שמולה פועלים המשתמשים ותוכנות המערכת.

איור 3: פרוטוקולי רשת מודרניים (ושכבת האפליקציה) מתוארים לרוב תוך שימוש במודל ה- OSI הקלאסי של רשתות תעשייתיות (ומסחריות). לעומת זאת, מודלים של ארכיטקטורת IoT של שלוש-שכבות מציבים את שכבת האפליקציה מעל שכבות התפישה והרשת; מודלים של ארבע-שכבות מציבים אותה מעל שכבות עיבוד הנתונים, הרשת והחישה. מודלים של פרוטוקול IoT של חמש-שכבות דומים אך מוסיפים שכבות עיבוד וארגון. (מקור התמונה: Design World)

פרוטוקולי אינטרנט באוטומציה תעשייתית

פרוטוקולי אינטרנט הם מערכות תקשורת נתונים הנקראות כך על פי הדרך בה הם מעבירים נתונים בין רשתות (ובדרך כלל בהדדיות) עבור תקשורת בתוך-גבולות. הפונקציות שלהם מתוארות לרוב באמצעות מודל ארבע-שכבות של TCP/IP שהוזכר לעיל. כאן, הרשת הפיזית או שכבת הקישור זהה לשכבה הפיזית של מודל OSI. לעומת זאת, שכבת האינטרנט TCP/IP (שהיא בקירוב שילוב של פונקציות קישור-הנתונים ושכבת הרשת של מודל OSI) מטפלת בחיבורים כמו גם במנות הנתונים. ב- IPv6, שכבה זו משתמשת בכתובות IP של 128‎-bit לזיהוי מארחים ברשת - ומאפשרת יותר מ- ^38‏10 מארחים ייחודיים.

שכבת ההעברה (Transport‏) ב- TCP/IP‏ מורכבת באופן כללי או מפרוטוקול בקרת שידור (TCP‏) או מפרוטוקול דאטה-גרם משתמש (UDP‏). ה- TCP משמש בדרך כלל לאינטראקציות אנושיות כגון אימייל ודפדוף באינטרנט. הוא מספק חיבורים לוגיים, אימות מנות משודרות, שידור-חוזר של מנות אבודות ובקרת זרימה. עם זאת, מערכות משובצות משתמשות ב- UDP כדי להשיג תקורה נמוכה יותר וביצועים טובים יותר בזמן-אמת. UDP עובד עבור שרתי שמות דומיין (DNS) ופרוטוקול תצורת מארח דינמי (DHCP) כמו גם עבור יישומי IoT חדשים.

שכבת האפליקציה היא הרמה הגבוהה ביותר במודל הרשתות TCP/IP‏. הפונקציות כוללות את אלו הקשורות לשכבות השיח (Session‏) וההצגה (Presentation‏) של מודל OSI.

פרוטוקולי שכבת-אפליקציה TCP/IP‏ גנריים

לפרוטוקולי שכבת-אפליקציה שונים יש רוחבי-פס נתונים שונים, יכולות זמן-אמת שונות ודרישות חומרה שונות. גורמים אלה ביחד עם הבקיאות של צוות המפעל או ה- OEM עם הפרוטוקול הם לעתים קרובות קריטריון בחירה חשוב. למרות שפרוטוקולי אינטרנט מוקדמים, כולל פרוטוקול העברת היפר-טקסט (HTTP) ופרוטוקול העברת דואר פשוט (SMTP), משמשים בעיקר לתקשורת מונעת-אנוש ונצרכת-אנוש, פרוטוקולי TCP/IP עם נטיית IIoT ממוקדים יותר במכונה-למכונה (M2M) ותקשורת תעשייתית אחרת.

מה שמסבך את העניינים במידת מה הוא כיצד לפרוטוקולי שכבת-אפליקציה מבוססים המשמשים ב- TCP/IP‏ עבור אינטראקציות אנוש מבוססות-אינטרנט עם מידע יש גם שימושים עבור צרכנים ו- IoT תעשייתי. זה בוודאי נכון לגבי HTTP ו- SMTP כמו גם למעטה האבטחה (SSH) ולפרוטוקול העברת הקבצים (FTP). מימוש פונקציות IoT בטכנולוגיות אינטרנט אפשרי לרוב אם משתמשים גם בשפת eXtensible Markup Language‏ (XML‏) וב- JavaScript Object Notation‏ (JSON‏). אזהרה אחת היא שלשימוש ב- HTTP יש השלכות אבטחה. זו הסיבה שבדרך כלל עדיף אם התקני IoT כלשהם במערכות כאלה כוללים רק לקוח - ולא שרת. זה מונע מההתקן לקבל בקשות חיבור העלולות לאפשר גישה חיצונית לא-מורשית לרשת. כאן, פרוטוקול WebSocket‏ יכול להקים תקשורת דופלקס-מלא באמצעות HTTP. אחרת, פרוטוקול ההודעות והנוכחות הניתנים להרחבה (XMPP‏) עשוי להיות מועדף עבור התקנות שצריכות לתת מענה למספר גדול של התקנים עם אבטחה טובה ותקשורת נתונים בזמן-אמת.

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

MQTT עבור פונקציות תעבורת חיבוריות אנכית

פרוטוקול Message Queuing Telemetry Transport‏ (MQTT‏) הוא המושפע ביותר מהאימוץ המהיר של IIoT‏ - פרוטוקול קל-משקל המיועד תחילה עבור התקני IoT‏ עם זיכרון מוגבל. מציע פעולה בחתימות-שטח עיבוד קומפקטיות ודורש רוחב-פס מינימלי, ה- MQTT‏ פותח לראשונה על ידי חברת IBM כדי לחבר חיישנים על צינורות נפט. בניגוד לפרוטוקול היישומים המוגבל (CoAP‏), ה- MQTT‏ כבר הפך לתקן בהתאם ל- ISO/IEC 20922‏. ה- MQTT משתמש בשכבת ההעברה (Transport‏) TCP שהיא במידת מה יותר עתירת משאבים ולכן צורכת יותר הספק ... אך הודעות יכולות להיות של שני Bytes‏ - פחות מאלה של CoAP‏.

בשל אופיו הפתוח, ה- MQTT יכול להיות גם קל במיוחד למימוש. אין פלא ש- AWS IoT של Amazon Web Services משתמש ב- MQTT להעברת הודעות ו- (עם אזהרות) תומך ב- MQTT על בסיס מפרט v3.1.1.

ל- MQTT אכן יש מגבלות מסוימות, היכולות לנבוע מכך שלמעשה הוא נועד תחילה כפרוטוקול טלמטריה - בניגוד לפרוטוקול Lightweight Machine to Machine‏ (LwM2M‏) הספציפי ל- IoT שיכוסה בקרוב. מאפיינים כגון אובייקטים, ניטור חיבוריות ופעולות התקן מרחוק אינן כלולות בתקן, ולכן הכללה של אלה נוטה להיות ספציפית לספק, מה שמוריד מערך הפרוטוקול הסטנדרטי במידת מה. MQTT גם אינו מציע יכולות לטיפול בשגיאות. לבסוף, למרות שניתן להפוך את ה- MQTT למאובטח באמצעות פרוטוקול TLS מלא, פעולה זו מגדילה את התקורה.

בעיקר ברמת הארגון: AMQP

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

CoAP עבור חיבור התקנים פשוטים

פרוטוקול היישומים המוגבל (CoAP) של ה- Internet Engineering Task Force‏ (IETF‏) מאפשר תקשורת ברשתות בהספק-נמוך בין התקנים עם זיכרון וכוח עיבוד מינימליים. הוא יכול לפעול עם תקורה נמוכה ביותר ועם בקשות ותגובות היכולות להיות קטנות עד כדי ארבעה Bytes‏. ה- CoAP חסך את השימוש בחבילת תוכנת העברה מורכבת לטובת שימוש ב- UDP במקום זאת. קראו את מאמר DigiKey‏ EtherNet/IP לעומת PROFINET בקישור שלעיל למידע נוסףעל UDP‏. כמו HTTP, גם CoAP משתמש במודל REST - כאשר שרתים מעמידים משאבים לרשות URL ולקוחות ניגשים אליהם בשיטות POST, GET, DELETE ו- PUT. יתרה מכך, ניתן לתרגם CoAP בקלות ל- HTTP עבור שילוב עם פונקציות אינטרנט אחרות ... והוא משתלב עם XML ו- JSON. המהנדסים יגלו שחיבור התקני IoT עם CoAP דומה מאוד לחיבור התקנים עם Web API.

איור 4‏: ה- SiP מבית Nordic הוא מיקרו-בקר בהספק נמוך עם מודם IoT בפס-צר (NB) ו- LTE-M משולבים, כמו גם GPS‏. ערכת פיתוח תוכנה מאפשרת את הכינון של CoAP. (מקור התמונה: Nordic Semiconductor‏)

חיבור התקנים מוזני-סוללות עם LwM2M

פרוטוקול שכבת-יישומים מה- Open Mobile Alliance הוא פרוטוקול LwM2M שנבנה במיוחד עבור יישומי IoT. משמש ביישומי עיר-חכמה, מכולות משלוח ומעקב מטענים, רוטינות אוטומטיות מחוץ-לכבישים וניטור תשתיות, ה- LwM2M‏ מבוסס על CoAP, כך שהוא חולק רבים מתכונותיו. התקן כולל מגוון רחב של אובייקטים סטנדרטיים מוגדרים ומתוחזקים היטב, כמו גם ניטור חיבוריות ופעולות התקן-מרוחק. שדרוגי קושחה אוטומטיים גם מפשטים את הניהול של התקנים מחוברי LwM2M‏. למרות שהכללת מודולים כמו JSON מגדילה את התקורה שלו, זה גם מקל על המפתחים את עבודת התכנון. מכיוון ש- LwM2M תוכנן במיוחד עבור יישומי IoT, הוא יכול גם להפעיל פרוטוקול אבטחה DTLS חזק מבלי להגדיל את התקורה.

DDS עבור יישומים מבוזרים בזמן-אמת

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

איור 5: תוכנת Connext Drive‏ עבור רכבים אוטונומיים בנויה על תוכנת-הביניים שירות הפצת נתונים (DDS) - המשמשת כחלק מהבסיס עבור ארכיטקטורות התוכנה AUTomotive Open System .ARchitecture (AUTOSAR) Adaptive and ROS2 זו רק דוגמה אחת לאופן שבו DDS תומך בשילוב תוכנת IoT. (מקור התמונה: Real-Time Innovations‏)

סיכום: פרוטוקולי שכבת האפליקציה IIoT‏

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