יתרונות Windows
מערכות ההפעלה של Microsoft ממשפחת Windows מובילות כבר כמה עשורים כמערכת הפעלה דומיננטית בכל שווקי המחשוב. מערכת Embedded בנויות מעל מערכת הפעלה מסוגים שונים. כמקרה פרטי – קימות מערכות Embedded הקרויות IoT Gateways, שמחוברות בצידן האחד לאינטרנט לקבלת שירותי server מרוחק, ובצידן השני ל-Sensors and Activators. לצורך המאמר הזה נתיחס לכולן במינוח אחד כמערכות Embedded. לאור התפוצה של Windows כמערכת הפעלה לצרכים שונים – אך טבעי הוא, שכל בונה מערכת Embedded ישקול גם הוא להשתמש במערכת הפעלה Windows ויהנה מהישגי Microsoft שמאפשרים לה להישאר דומיננטית אחרי עשרות שנים.
יתרונות Windows ידועים לכל, הנה הם בקצרה:
שיפורים פונקציונליים מתמידים שכיום מתקבלים ב-Windows 10
התאמה אוטומטית לסוג המעבד ומספר הליבות
סביבת פיתוח הנוחה והמשוכללת ביותר – כיום Visual Studio 2015
זמינות רבה של תוכנות וכלים
ידע נרחב בין המתכנתים שמגדיל את התחרות ומאפשר עלויות תכנות נוחות
בוני מערכת Embedded יכולים ליהנות מכל היתרונות הנ”ל, ואכן קיימים היום אלפי פרויקטים של מערכות Embedded כאלה שמופעלות על ידי אחת ממערכות הפעלה של Microsoft.
יוצאי הדופן
המינוח “מערכת Embedded” מקיף את כל סוגי המערכות שבהן המחשב מריץ משימה או מספר משימות שאינן משימות עבור עמדת Client או Server של מחשוב אישי. מתוך אלפי היישומים האפשריים שעומדים בהגדרה הנ”ל, קיימת קבוצה של יישומים בעלי דרישות שיישומן סותר את המענה לדרישות ה”רגילות” של Windows.
Windows לא נבנתה כמערכת לזמן אמת, ומענה לדרישות זמן אמת סותר את התכונות הנדרשות כמחשב אישי, או מחשב שמספק שרותי Server.
ניתוח מעמיק של תכונות Windows ומנגנוניה וההסבר לכך שאינן מאפשרות ביצוע תוכנה בזמן אמת חורג מהמסגרת של מאמר זה. אנו נציין כאן את “השורה התחתונה” של אותן דרישות לזמן אמת בהן Windows לא יכול לעמוד:
1. מספר אפילו קטן של ממשקי חומרה – שהתגובה עבורן היא בעיכוב קטן מאד (לדוגמא – סטיה קטנה מ-50 מיקרו שניות) וקבוע – למשל – מצב בו הסטיה אינה משתנה אף פעם (למשל) ביותר מאשר 5 מיקרושניות. לתכונה שכזו קוראים דטרמיניסטיות.
2. קיימים לפחות מספר תהליכים שדורשים זיהוי נפילה והתאוששות מהירה. כלומר נפילת התהליך אינה מפילה שרותים אחרים ואינה פוגעת במנגנון הזיהוי וההתאוששות. לתכונה זו קוראים רובוסטיות.
חלק משמעותי מתוך מערכות ה-Embedded דורש אחת או יותר מהדרישות הנ”ל ונשאלת שאלה: איזה מע”ה לבחור עבור מערכת Embedded בעלת תכונות לזמן אמת?
אפשרות ראשונה היא לוותר על Windows ולנסות להתאים מערכת הפעלה שהוגדרה מראש לזמן אמת, ומספקת דטרמיניסטיות ורובוסטיות. בכך מוותרים על כל מה ש-Windows מסוגלת לספק במרכיבי המערכת המפותחת שאינם לזמן אמת (המרכיבים צוינו בתחילת המאמר).
אפשרות שניה: לשלב ב-Windows יכולות זמן אמת ש”מיובאות” ממערכת לזמן אמת אמיתית.
הפתרון המוצע כאן הוא שילוב מערכת הפעלה מלאה לזמן אמת הקרויה INtime בקונפיגורציה הקרויה INtime For Windows. בקונפיגורציה זו משולבות שתי מערכות ההפעלה על אותו ה-PC בהפרדת משאבים ביניהן.
המשאבים הניתנים להפרדה בין INtime ל-Windows הם:
ליבות זכרון פסיקות
הפסיקות של התקנים חיצוניים שדורשים טיפול בזמן אמת והתהליכים שמתעוררים על ידי Timers פנימיים שדורשים טיפול בזמן אמת, “מועברים” לצד INtime. בין שתי מערכות ההפעלה קיים פרוטוקול של הודעות שמשתמש ב-IPI – Inter Processor Interrupt. לפרוטוקול יש overhead קטן ביותר והוא פועל כל הזמן ברקע.
כמו כן ברמת המתכנת ישנן קריאות API לכמה סוגי ממשקים בין סביבת Windows לסביבת INtime כדי לאפשר תוכניות שמשלבות את שתי הסביבות.
איך עונה ה”תגבור” באמצעות INtime לשתי התכונות הנ”ל לזמן אמת שאותן Windows לא תוכנן לספק
כאמור, הדרישה מספר 1 ממערכת דטרמיניסטית היא שקים מספר אפילו קטן של ממשקי חומרה – שהתגובה עבורן היא בעיכוב קטן מאד וקבוע.
פסיקות מגיעות מהתקנים חיצוניים. אם הגדרנו את רכיב החומרה והפסיקות שלו – לקבל טיפול מ-INtime – מערכת ההפעלה Windows אינה מעורבת כלל. לשם המחשה נעקוב אחרי פסיקה מחזורית שמתקבלת מ-Timer פנימי. נבנה תכנית שגורמת לפסיקה יזומה לפי Timer שפועל במרווח קבוע, ונבדוק כמה זמן עבר מאז שה-Timer הופעל בפעם הקודמת. בכך נמדוד את ההפרשים של תחילת פעולת ה-thread שאותו מפעיל ה-Timer בין כל אירועי Timer רצופים. זוהי השונות של ה-latency – או במילים אחרות ה-jitter.
ההיסטוגרמה באיור מספר 1 מראה את פיזור ה-jitter במדידת למעלה מ-1.6 מיליון אירועים בהפרשים של 50 מיקרושניות האחד ממשנהו. עבור ניסוי זה, ה-jitter שנמדד הינו קטן ביותר כ-0.9 מיקרו שניות (ראה סימונים בעיגול). בניסוי שכזה גודלו של ה-jitter תלוי בפלטפורמה: בפלטפורמות שבנויות על מעבדים מדורות קודמים, או כאלה הפועלים ב-hyperthreading ה-jitter גבוה במקצת.
כשיש מספר רב של ממשקים – אם ניתן לליבה אחת לטפל בכולם הרי שמטבע הדברים תיווצר תחרות על משאב הריצה שהינו הליבה. כשיש מעט ארועים שצריך להגיב אליהם בצורה דטרמיניסטית, מדרגים את הארועים לפי עדיפותם ונותנים להם אחת מ-255 רמות. התוצאה תהיה שבצורה הדרגתית תינתן דטרמיניסטיות פחות טובה לאלה שעדיפותם נמוכה יותר.
כאשר מגיעים למצב שבו האירועים בעדיפות הנמוכה לא מקבלים את הדטרמיניסטיות הדרושה, ניתן לנצל תכונה מרכזית של INtime – היותה מערכת הפעלה שפועלת בריבוי ליבות מסוג Asymmetric Multi Processing . לכל ליבה נטען עותק מלא של מערכת ההפעלה, וכל ההפרדות של הזכרון והפסיקות מאפשר לריצה עצמאית של כל ליבה לטיפול בפסיקות ובתוכנות הטיפול שהוקצו לה. כך מבזרים את הארועים בין הליבות ומקטינים את התחרות על המשאבים שגורמת לפגיעה בדטרמיניסטיות. באיור מספר 2 מוצגת מדידה של אותה התכנית מאיור 1 שרצה במקביל על 4 ליבות (במקרה שבחרנו זה היה במוד hyperthreading). כל אחת מהליבות מריצה את INtime.
ניתן לראות שבהקצאה כזו ארבעה אירועי Timer בלתי תלויים יכולים לקבל דטרמיניסטיות מקסימלית ללא כל הפרעה של ארוע אחד למשנהו.
דוגמה נוספת היא לפסיקות שמגיעות מחוץ ל-PC. בחרנו לבחון את הטיפול בכרטיסי תקשורת ל-Ethernet. ב-INtime ניתן לטפל בממשקי ה-Ethernet ברמת ה-frame או ברמת ה-IP. במערכות Embedded ישנה לעיתים דרישה לתגובה בממשקי ה-Ethernet ב-latency ו-Jitter נמוכים. כאמור ניתן לנסות קודם לכן ל”שחק” עם עדיפויות התהליכים על אותה הליבה – ולתת לתהליך הדרוש שמפעיל את ממשק ה-Ethernet עדיפות גבוהה יותר. אולם אם עדיין לא משיגים את הדטרמיניסטיות הדרושה, ניתן גם כאן לבצע הפרדה לליבות. כל port מתוך אותו כרטיס רשת מרובה ports, או כרטיס רשת שלם אחר, ניתן לשייך לליבה אחרת – כפי שמתואר באיור מספר 3. בחלקו העליון של האיור מוצגת הקצאה אפשרית של NIC ports במערכת בה INtime ו-Windows רצים על אותו PC זה לצד זה, ובחלקו התחתון מוצגת ההפרדה עבור קונפיגורציה הקרויה INtime Distributed RTOS (תוסבר בהמשך) בה כל הליבות מריצות INtime.
כאמור הדרישה השניה ממערכת לזמן אמת היא לטפל במצב בו נדרש עבור מספר תהליכים לספק את זיהוי הנפילה ולאפשר התאוששות מהירה. במילים אחרות, נפילת תהליך מסוים אינה מפילה שרותים אחרים ואינה פוגעת במנגנון הזיהוי וההתאוששות.
התוכנה שמפעילה את המוצר – מריצה תהליכי מערכת ותהליכי לקוח. ככל שמפרידים את היישום לתהליכים רבים יותר (thread או process), ומספקים לכל אחד מהם בנפרד מנגנון לזיהוי חריגה, ניתן להגיע למערכת אמינה יותר. מי שמספק את התשתית למנגנונים הללו היא מערכת ההפעלה. מטבע הדברים – אם חילקנו את הפתרון למרכיב שרץ מעל Windows ולמרכיב שרץ מעל INtime, קרוב לוודאי שדאגנו שהמרכיב שנדרשת ממנו האמינות הגבוהה יותר ירוץ ב-INtime .INtime מספקת לכותב התוכנה תשתית בה כל תהליך ברמת הפניה לחומרה (Driver) או ברמת הישום שאינו פונה לחומרה, נכתב ברמה 3. זוהי רמה שאינה יכולה לפגוע ברמה 0 שבה רצה מערכת ההפעלה. ב-Windows למשל, כל ה-drivers רצים ברמה 0 ועלולים לגרום לבעיה (קריסה או אחרת) במערכת ההפעלה או בשירותיה שרצים באותה הרמה.
בנוסף להפרדה זו בין הקוד המפותח למערכת ההפעלה שמתחתיו, מספקת INtime בתוך התהליכים עצמם הפרדה בין האזורים השונים (Code, Stack, Heap) השייכים לאותו התהליך.
איור מספר 4 ממחיש את ההפרדות בזכרון בין INtime ל-Windows ובתוך INtime. כל חריגה בריצת התוכנה מטופלת על ידי exception וההחלטה מה לעשות במקרה שכזה נכתבת על ידי התכנת, ולא גורמת אוטומטית לקריסה.
התשתית הנ”ל עוזרת גם במקרה של תהליכים יזומים לבדיקת התוכנה. כל מהנדס מערכת בחומרה או תוכנה יודע מה משמעות המונח Watch Dog. זהו תהליך שרץ מחזורית ברקע של תוכנת המוצר ומבצע בדיקות ברמה מסוימת. התשתית שתוארה ב-INtime מאפשר לכתוב תהליכי watch dog שמכוונים לחלקי המערכת השונים. זיהוי התקלה כשקורה – אינו גורם לקריסת המערכת אלא מטופל עבור תת התהליך שמחייב התייחסות.
סביבת הפיתוח
בפרק הקודם הומחש המענה לדרישות לזמן אמת. ניתן בהחלט להתייחס לכך כתגבור windows לעמידה במגוון ישומי Embedded שדורשים יכולות זמן אמת.
עד שלב זה – לא התייחס המאמר לצורת הפיתוח שמאפשרת את המענה הנ”ל לדרישות.אילו היינו בוחרים במערכת הפעלה שאינה Windows היינו מפסידים את היכולת לפתח ולדבג באמצעות Visual Studio. בבחירה ב-INtime אנו מקבלים פתרון שגם הוא מפותח באמצעות VS: לצידו של פיתוח ב-VS של מרכיב ה-Windows של הפתרון, מפתחים – ב-project מסוג INtime את מרכיב הזמן אמת, ומבצעים את ה-debug באמצעות VS עבור שני החלקים.
בדרך כלל, במערכות Embedded לזמן אמת, נדרשת עמידה בנתונים מסוימים במימד הזמן. במערכות הכתובות ב-Windows ניתן לשנות את התוכנית ולאגור בזכרון או להדפיס סימוני זמנים. זוהי מטלה נוספת מעל ריצת התכנית שעלולה בעצמה לשנות את זמני הריצה המקוריים, וללקות באי דיוקים. בדרך כלל הדפסת נתונים ב-Windows במרווחי זמן קטנים אינה מעשית ואז צריך לאגור את הנתונים בזכרון בזמן ריצה, ולאחריה לנתח אותם באמצעות Excel למשל. פרט למדידת זמנים נדרש גם כלי Debug עבור מצבים בהם ארועים מסוימים חורגים (לעיתים באופן נדיר) מפרמטר תזמון נדרש, ניפוי כזה אינו אפשרי כלל ב-Windows.
מטבע הדברים מדידות ו-debug של בעיות תזמון הם “נחלתו” של מרכיב התוכנה שרץ מעל INtime ועבורם מסופק כלי ששמו INscope שמוצג באיור מספר 5. INscope רץ לצידה של התוכנה המפותחת ואוגר נתונים ב-buffer שניתן להצגה. ציר ה-X הוא ציר הזמן, וניתן לבצע zooming כדי לראות תזמונים עד לחלקי מיקרו שניה. בציר ה-Y מסומנים ה-processes וה-threads. בכל נקודת זמן הגרף נמצא ב-process ו-thread מסוימים ועליו מוצגים הארועים עם רישום הזמן בו קרו. האירועים כוללים פסיקות, פניות למערכת ההפעלה וקריאות לפונקציות C. כמו כן ניתן להוסיף ארועי משתמש על ידי סימונם בתוך התכנית. יכולת שכזו מאפשרת לנפות מקרים של Bug שגורם לסטיה (גם נדירה) מתזמון מצופה.
סביבת הריצה
בעבודה עם INtime For Windows נדרשים גם שירותים מ-Windows על אותה הפלטפורמה שבה רץ INtime. לעיתים קיים מרחק פיזי בין הממשק שמחובר להתקן וצריך לתפקד בזמן אמת, לבין העמדה שמספקת שירותים כמו Gui על ידי Windows. במקרים כאלה נבחר בקונפיגורציה בה נמצא רק INtime על כל הליבות. איור מספר 6 מראה את הקונפיגורציה (העליונה באיור) הקרויה ולצידה הקונפיגורציה INtime for Windows. בקונפיגורציה של DRTOS מקבלים את כל יכולות זמן האמת, אבל חסרים באותו הפלטפורמה את תכונות Windows כמו GUI ,File System משוכלל וכו’ שניתנים (אם נדרש) דרך ה-LAN ממחשב מרוחק שמריץ Windows.
קונפיגורציה זו של DRTOS מאפשרת יותר משאבי CPU למרכיב לזמן אמת, הקטנת זכרון, זמן עליה קצר יותר בשלב ה-Boot ואמינות גבוהה יותר.
32 ביט או 64 ביט
בשנים האחרונות מספקת Microsoft את מערכות ההפעלה Windows גם ב-64 ביט. יכולת זו, וירידת מחירי הזכרון מאפשרים למתכנן להשתמש בכמויות זכרון עצומות, הרבה מעל ה-4 ג’יגה בייט שמגבילים מערכות הפעלה ל-32 ביט. גם עבור יישומי זמן אמת נדרשים לעיתים Buffers עצומים.
כמו רוב מערכות ה-Embedded, הינה מע”ה של 32 ביט אבל כדי לאפשר גם במרכיב ה-INtime להיות גדול מעל 4 גיגה בייט – הורחב ה-memory manager שלה שמשתמש בתכונת PAE – Physical Address Extension שמצויה בכל המעבדים ממשפחת הפנטיום
אסף גליל הינו מהנדס יישומים של חברת TenAsys והחברה שבבעלותו היא נציגת TenAsys בארץ. לאסף למעלה משלושים שנות ניסיון בשוק ה-Embedded.
פרו שיצאה ב1995- ואילך.
שימוש זה מאפשר גם למרכיב לזמן אמת להיות עצום בגודל הזכרון שלו – הרבה מעל 4 ג’יגה בייט.
לסיכום
שילובי קונפיגורציות עם Windows ומע”ה לזמן אמת INtime מצד אחד, וסביבת פיתוח אחידה ומובילה – מצד שני – מאפשרים למפתחי מערכות Embedded (וכאמור מערכות מטיפוס IoT Gateway) ליהנות משני העולמות ולספק לשוק מערכות מורכבות ותחרותיות .
אסף גליל הינו מהנדס יישומים של חברת TenAsys והחברה שבבעלותו היא נציגת TenAsys בארץ. לאסף למעלה משלושים שנות ניסיון בשוק ה-Embedded.
