אסף גליל
שוק ה-Internet Of Things לא נולד היום. המונח נוצר כבר בתחילת שנות התשעים באוניברסיטת MIT היוקרתית. לאחרונה התגלה הצורך “למחזר” את המושג ולהתאימו להתפשטות העצומה שחלה באפשרויות הקישוריות באינטרנט ולפוטנציאל העצום של מכשירי קצה שישכילו להיעזר באפשרויות המתפתחות הללו.
חברות המפתחות מערכות הפעלה הצטרפו גם הן לחגיגה. ואי אפשר היה להתעלם מההכרזה האחרונה של מיקרוסופט בהקשר של שוק ה-IoT:
Microsoft making Windows free on devices with screens under 9 inches.
הכרזה כזו הינה משמעותיות: Microsoft מוכנה להפסיד כסף למען העלאת ה-market share שלה בשוק התקני IoT הקטנים. מפתחים יכולים לנצל גישה זו ולהיעזר בטכנולוגיות Microsoft בעלות נמוכה מבעבר, ללא כל התפשרות על איכויות המוצרים.
במאמר זה נתייחס למיגוון האפשרויות שעומדות לרשות מתכנן מערכות משובצות מחשב לאור ההתפתחויות האחרונות בשוק. נקודת המבט שבה נתרכז היא התקני ובקרי IoT שדורשים מהתוכנה גם יכולות של זמן אמת. פיתוח רכיבים כאלה מוביל לשימוש מושכל של מעבדים מרובי ליבות שיריצו מערכות הפעלה שונות כדי לספק פתרון כולל.
מהן יכולות זמן אמת, והיכן נזקקים להן? שתי תכונות מאפיינות את היכולות:
דטרמיניסטיות – מתן תגובות בזמן קצר ללא חריגות. למשל הזמן שלוקח לסנסור מיקום לזהות תנועה מהירה של עצם, עד לטיפולו על ידי התוכנה. בדרך כלל זמן זה חייב להיות קצר וכמעט קבוע (jitter נמוך).
רובוסטיות – עמידות של התוכנה בפני בעיות (bugs) בתוכנה עצמה ובחומרת המערכת. רובוסטיות נדרשת כיון שרוב המערכות שצפויות לשוק ה-IoT אינן מאוישות על ידי מפעיל והן אמורות לפעול ב-UP Time גבוה ולהתאושש במהירות מכל מצב.
להבדיל מ-Windows ,Unix ו-Linux שמאופינות כ- – General Purpose Operating Systems, מערכות ההפעלה המספקות את שתי התכונות הנ”ל קרויות RTOS – Real Time Operating Systems.
איך לבחור מערכת ההפעלה להתקן
חלק גדול מהתקני IoT שכבר היום נמצאים בשוק – דורשים אחת או יותר מהתכונות הנ”ל. כלומר למימושן נדרש RTOS. מאידך נדרשות לעיתים תכונות נוספות של עיבוד שאינו בזמן אמת כמו GUI ו-File System מתקדם – שאינן אופייניות למערכות RTOS. ככלל – מערכות RTOS הן בדרך כלל שמרניות יותר מאשר GPOS כמו Windows למשל, שמתפתחת במהירות ומאמצת ללא הרף סטנדרטים חדשים נוספים.
מתברר – שהתקני IoT רבים רצוי שיריצו גם RTOS וגם GPOS – והשילוב אפשרי תודות לטכנולוגיות וירטואליזציה שונות מעל מעבדים מרובי ליבות. שילובים כאלה מאפשרים פונקציונליות גבוהה ובה בעת שומרים על מחיר נמוך.
שילוב מערכות הפעלה בטכנולוגיה של TenAsys
מאז 1997 מספקת חברת TenAsys מערכת הפעלה הקרויה INtime שמאפשרת ל-PC אחד להריץ גם GPOS – Windows וגם RTOS. זוהי מערכת הפעלה לזמן אמת ששמה INtime ושורשיה הם מע”ה RMX 386 של אינטל שהייתה דומיננטית בתחומה בשנות השמונים והתשעים של המאה הקודמת.
סביבת הפיתוח (שלא כמו במוצר ההיסטורי המקורי) היא Visual Studio עבור שני חלקי המערכת, וסביבת הריצה מאפשרת הקצאה – לפי בחירה – של ליבות ל-Windows או INtime.
ניתן לשלב את INtime בריצה עם מערכות הפעלה Windows מכל הסוגים:
XP ,Windows 7 ,Windows 8, עבור 32 או 64 ביט – בגירסאות השולחניות ובגירסאות ה-Embedded המבנה הוא ש-Windows רץ כ-Native OS על מספר ליבות, ו-INtime רץ מעל ליבות אחרות. כך מתקבלים ביצועים מצוינים של זמן אמת למרכיבי INtime, וקיימת הפרעה מינימלית לתוכנה שרצה על הליבות שהוקצו ל-Windows.
התקשורת בין שני חלקי המערכת
התקשורת בין שני חלקי המערכת היא בשני מישורים:
ברמת המתכנת ישנו API הקרוי NTX. זה מאפשר לכותב תוכניות בצד ה-Windows להפעיל אובייקטים של זמן אמת, שרצים מעל INtime. הגישה אפשרית לכותבי תוכנות Windows ב-C ,C++ או # C. תיאור המבנה של שתי מערכות ההפעלה והתקשרות NTX ביניהן מופיע באיור מס’ 1.
נציין שתי דוגמאות מתוך רבות אחרות, לצורך בממשק NTX:
צד ה-Windows משנה את פרופיל העבודה של הצד לזמן אמת – על ידי הטענת תהליך חדש ל-INtime והפרמטרים בו יעבוד.
תהליך ב-Windows מחכה לסיום משימת Real Time (מחכה ל-Semaphore) כדי להמשיך ולנתח את התוצאות שהתקבלו.
מתחת למימשק NTX רצות, ללא התערבות המתכנת מערכת הודעות בתקורה נמוכה מאד. מערכת הודעות זו מעדכנת הדדית את שתי מע”ה על המצבים ברעותה. ברגע שממשק ה-NTX דורש במפורש להעביר אינפורמציה – מתווספות הודעות שעוברות כדי לטפל בבקשות אלו כך קצב ההודעות עולה, כפי שמודגם באיור מס’ 2.
התקשורת מחוץ לרכיב ה-IoT
מתוך שמו – ברור שלרכיב IoT ישנה תקשורת LAN לכיוון ה-Internet. תקשורת זו יכולה להיות למשל לצורך משלוח קבצים. במשלוח כזה אין חשיבות לתזמון המדויק של יציאת כל packet. הפרמטר החשוב הוא סה”כ משך התשדורת שמעבירה את כל הקובץ.
מאידך – ישנם יישומים שירוצו מעל רכיב IoT שבהם יש חשיבות לתזמון המדויק של כל packet, ואף התפתח לאחרונה סטנדרט הקרוי IEEE1588 שמשלב בתוך ה-packet את ה-Time Stamp של זמן יציאתו.
כלומר – גם בנושא התקשורת יש לעיתים צורך לטפל באמצעות מנגנונים של RTOS. כפי שמעבד אחד מחולק בין RTOS
ל-GPOS, כך גם יציאה פיזית אחת (LAN Port) מחולקת כך שתעבורה מסוימת מטופלת על ידי אלמנט ה-GPOS (במקרה שלנו Windows) ותעבורה אחרת על ידי
ה-RTOS (במקרה שלנוINtime).
כדי לאפשר יכולת זו – ניתן להשתמש
ב-INtime בפונקצית ה-Bridge, המתוארת באיור מס’ 3.
ה-LAN Port הפיזי היחיד מטופל על ידי INtime דואג לדטרמיניסטיות, ומזדהה בכתובת IP אחת. אותו PORT פיזי מחובר פנימית ליציאת LAN “מדומה” של (Virtual Port) שממנה נכנסת ויוצאת התעבורה מ-Windows .Windows מזוהה בכתובת IP שונה.
INtime מגדילה לעשות בנושא הזה: במקרים של מהירויות תקשורת גבוהות, ודרישה לזמנים קצרים ביותר של עיכוב בין כניסת או הוצאת המידע לבין הטיפול התוכנתי בו – ניתן לחסוך זמן יקר בטיפול ה-IP Stack – ולטפל ישירות – בזמן עיכוב קצר ביותר
ב frame שבא או יוצא מכרטיס הרשת. אותו ה-port הפיזי שדרכו עוברת תעבורת ה-IP (גם אם זה שמקונפג כ-Bridge כפי שהוסבר), מסוגל לטפל בכל Frame שמגיע, ללא טיפול של ה-IP Stack, ובכיוון השני לשלוח את ה-Frame ישירות מהיישום. יכולת זו חוסכת מיקרו שניות רבות מה latency בטיפול ובמשלוח. זהו מעין Protocol Bridge שמתואר באיור מס’ 4: תוכנת המשתמש מטפלת ב-frame ב-API הקרוי – High Performance Ethernet, לפני שה-stack מטפל בה. באפשרות המתכנן לעבד frames מסוימים, ולא להעבירם לטיפול ה-stack ובכך להקטין את ה-Latency.
הצעות לפיתרון עבור דרישות שונות
לאור מה שצויין ניתן לרכז את הקונפיגורצית לציוד IoT במטריצה המתוארת באיור מספר 5. בציר ה-X מוגדרת צורת התקשורת מול הבקרים דרך ממשק ה-Ethernet: האם נדרשת תקשורת Real Time (מצוין כ-RT) או General Purpose (מצוין כ-GP). ציר ה-Y כולל חלוקה דומה של GP/RT עבור העיבוד והממשקים האחרים. כאשר אין כלל דרישות לזמן אמת, לא בתקשורת ולא בפעולה מול ההתקנים המקומיים של רכיב ה-IOT – Windows אינו נזקק לתוספת. בכל המקרים האחרים נדרשINtime. מה שחשוב לציין שבשימוש
ב-INtime כאשר במשפחת מוצרים יש דרישות RT/GP שונות ניתן להשתמש באותו בסיס קוד, ולחסוך בזמן פיתוח.
באיור 5 מופיע גם מוצר הקרוי eVM שלא הוזכר קודם לכן במאמר. זהו Real Time Hypervisor שמעליו ניתן להריץ boot file של כל מערכת הפעלה Embedded אחרת: Embedded Linux ,VxWorks ,Windows CE ,QNX ואחרות. אופציה זו מוצעת למקרים שבהם קיים מוצר ותיק שרץ על אחת ממע”ה שצוינו ורוצים לנצל אותו As Is ללא שינוי. תוספת ה-eVM מרחיבה את כיסוי הפתרונות האפשריים ושומרת על העיקרון של ניצול קוד קיים ושימוש אופטימלי בחומרה שאופיניים לפתרונות האחרים במטריצה הנ”ל.
יכולת הרחבה וגידול
רכיב ה-IoT עשוי להיות קטן או גדול (בגודל פיזי וביצועים) לפי היישום. בנוסף גם רכיב שהחל להמכר כקטן עשוי להתפתח לפי דרישות הלקוחות.
אחת התכונות של המטריצה המוצגת באיור מספר 5 היא יכולת הגידול בשימור עלויות פיתוח התכנה.
התכנה שפותרת את דרישות העיבוד גם בצד RTOS וגם בצד GPOS מתאימה עצמה אוטומטית להוספת ליבות. ב-INtime זה מבוצע על ידי ניצול יכולות תהליך Distributed Service Manager – והקצאת אובייקטים גלובליים (ׂGlobal Objects),
וב-Windows על ידי יכולות SMP –
(Symmetrical Multi Processing).
ניתן גם להעביר בקלות קוד מסביבת GPOS לסביבת RTOS ולהיפך, כיון ששפות התכנות וסביבת הפיתוח Visual Studio זהות בשניהם.
לסיכום
השילוב ה”אינטימי” שיש ל-INtime עם Windows וסביבת הפיתוח הזהה, מספקים יתרונות רבים למפתח, ותורמים למוצר הסופי פונקציונליות ואמינות. בין אם Windows כלול בפיתרון – או לא, סביבת הפיתוח העשירה והנוחה ומחירי התוכנה הנמוכים מספקים הזדמנות לפתח ולספק מוצרים לשוק IoT בפונקציונליות גבוהה ובעלות נמוכה.
אסף גליל הינו מהנדס יישומים של חברת TenAsys והחברה שבבעלותו היא נציגת TenAsys בארץ. לאסף למעלה משלושים שנות ניסיון בשוק ה-Embedded.
