Chris Grujon, TenAsys
המונח Virtualization מובן בצורה שונה על ידי משתמשים העוסקים בישומים שונים. רוב צורות הוירטואליזציה שבה משתמשות מחלקות IT אינן מענינות מתכננים של מערכות משובצות משום שמערכות אלה אינן מבטיחות שהעיבוד של תהליכים יהיה דטרמיניסטי. כלומר אם נרצה להריץ מעל מערכות וירטואליזציה כאלה – כמו VMware ,VirtualPC ,Xen ודומיהן קוד שיבצע משימות טיפוסיות של מערכת משובצת, התהליכים לא יוכלו לעמוד בקריטריונים של זמן אמת: latency (השהיה) ו-jitter (שונות ההשהיה) נמוכים.
תחת זו, עבור מערכות של ליבה אחת או יותר, הדרך לספק דרישות אלה היא לחלק את משאבי המערכת – זכרון, ליבות, פסיקות – למספר סביבות כך שכל סביבה רצה מעל המשאבים הטבעיים שלה (ה”סיליקון” שלה) ולא מעל קוד שמבצע דימוי של משאבים.
תחילתה של טכנולוגית הוירטואליזציה היא הרעיון שמערכת הפעלה לזמן אמת RTOS עובדת לצידה של מערכת הפעלה לשימוש כללי GPOS כגון Windows – וכל זאת על פלטפורמת מחשוב אחת. ב-EmbeddedVirtualization יוצרים סביבה נפרדת לכל אחת ממערכת ההפעלה וליישומים הרצים מעליהן כאילו רצו על מחשבים נפרדים. היתרון בכך הוא ברור: המערכת פשוטה יותר, זולה יותר ובעלת אמינות טובה יותר עקב מיעוט הרכיבים.
כבר בשנות ה-80 של המאה הקודמת, בוני מערכות החלו להשתמש ב-PC כאבן בנין. הישומים הראשונים היו פשוטים והתרכזו בניצול העלות הנמוכה יותר של ה-PC לעומת פלטפורמות מחשוב שהיו מקובלות באותה התקופה.
במקביל להתפתחות ה-PC פותחו תוכנות יישום רבות ובהדרגה נוצר סטנדרט של ממשק אדם מכונה (HMI). הסטנדרט הזה איפשר למפתחי מכשירים שהשתמשו ב-PC לפשט את ההכנה לתפעול (setup), התפעול עצמו () והתחזוקה (maintenance) – של המכשירים שפותחו. יחד עם זאת כיון ש-Windows אינה בעלת יכולות של RTOS הוסיפו המתכננים מחשב שלם נוסף שמריץ RTOS למטרה זו. כפילות מחשוב זו, הביאה לרעיון לפשט ולרכז את כל המחשוב ב-PC אחד. הרצת שתי מערכות הפעלה על מחשב אחד לא היתה כבר אז רעיון חדש. כבר 10 שנים קודם לכן רצו בסביבת מחשבי, Mainframe מעל שכבת תוכנה על אותו המחשב – מספר מערכות הפעלה והתקשרו ביניהן ועם החומרה בדומה למה שמבוצע היום על מעבדים מודרניים.
הבעיה המרכזית היתה שהפרדת התוכנה מהחומרה על שכבת תוכנת וריטואליזציה הביאה לכך שכל הגישות של תוכנת הישום למשאבי I/O כבר לא היו דטרמיניסטיים.
Embedded
Virtualization נדרש לספק דטרמיניסטיות גם כשעובדים במספר מערכות הפעלה.
המשמעות של הדרישה היא שיש למצוא דרך לחלק את משאבי המחשב כך שכל מערכת ההפעלה לזמן אמת (RTOS) תקבל גישה ישירה ל-I/O ולInterrupts- Windows כמערכת הפעלה GPOS אינה מאפשרת גישה כזו.
ככלל – מערכת כמו Windows תופשת פיקוד תוך כדי תהליך ההתקנה על כל התקני ה-I/O. היה צורך לפתח דרך שבה ל”שמור” על משאבים ו-I/O מפני ה”השתלטות” של Windows. וכיון שטכנולוגיה כזו היתה צריכה לפעול עוד בסוף שנות התשעים של המאה הקודמת, כשמעבדים היו בעלי ליבה אחת – היה צורך גם לפתח דרך מהירה של “קפיצת” ה-Context מ-GPOS ל-RTOS. כפי שמומחש באיור מספר 1.
תקשורת בין תהליכים (Processes) מאפשרת תיאום בין משימות (Tasks)
כאשר כמה מע”ה רצות על מחשב אחד כל אחד בסביבה שלו – יש צורך להעביר נתונים ביניהן. זה יכול להתבצע בפשטות על ידי שמירת אזור מסוים בזכרון, אבל דורש טיפול מתמשך על ידי היישומים עצמם שיהפוך מסובך עקב הדרישה שהודעות יועברו ויקראו במועדים מסוימים. תהליך התקשורת צריך להבנות כך שהודעה תועבר במהירות כשנדרש. העברת ההודעה צרכה לקחת בחשבון את העדיפות (priority) של ההודעה ביחס למשימות (tasks) אחרות – כדי שההודעות יגיעו בזמן ובסדר הנכונים. הדרישה הזו חשובה במיוחד בתקשורת בין GPOS ל-RTOS: ארוע בעדיפות נמוכה אסור שיפסיק משימה בעדיפות גבוהה.
ריבוי ליבות מקל על חלוקה והפרדה פונקציונליים
הימצאות מעבדים מרובי ליבות שינו כמה מהכללים: כל מע”ה היא “בעלת” ליבה אחת או יותר. אין הכרח לתת למעבד אחד להריץ כמה מע”ה. יש לשם לב
ש-Windows למשל משתלט על כל הליבות מזמן ההתקנה שלה.
הדרך לעשות את החלוקה היא “לומר” ל-Windows בזמן עליתה איזה ליבות אינן זמינות עבורה. זה מאפשר למשל במעבד בן 4 ליבות קונפיגורציות כמו 1:3 2:2 3:1 (ראה איור 2).
זה מאפשר למתכנן להתאים את דרישות כח החישוב של ה-GPOS וה-RTOS לפי הדרישות מהמוצר. במוצר בו נדרשת פעילות זמן אמת מעטה ותוכנה “כבדה” בחלק של Windows יש הגיון להקצות רק ליבה אחת ל-RTOS מתוך הארבע. אולם אם המוצר מבצע בקרה על מספר התקני I/O שפועלים במקביל אבל ה HMI הוא פשוט – אזי ה-RTOS ראוי ש”יקבל” את רוב הליבות.
עם ריבוי הליבות יש צורך לאפשר לכל ליבה של RTOS להתקשר עם GPOS וגם עם ליבות RTOS אחרות. במילים אחרות נדרשת רשת תקשורת שכל מע”ה בכל ליבה יכולה לתקשר עם אחרת. רשת כזו צרכה לשמר עבור כל RTOS את הדטרמיניסטיות – כלומר לא לאפשר שהתקשורת הנ”ל תגרום למשימות לא להתבצע במועד או בסדר הנדרשים.
וירטואליזציה מאפשרת תקשורת דטרמיניסטית
בין פלטפורמות
סביבת EmbeddedVirtualization שהוכיחה עצמה ביישומים מטיפוס MissionCritical היא משפחת מערכות ההפעלה לזמן אמת INtime שמפותחת על ידי TenAsys. זוהי חברה אמריקאית שרכשה את כל זכויות מערכות ההפעלה לזמן אמת RMX מתוצרת חברת אינטל, שהיו פופולריות מאד בארץ ובעולם החל משנות ה-80 של המאה הקודמת. המרכיבים הבסיסיים ב-Kernel של INtime לקוחים מ-RMX ואליהם התווספו במשך השנים יכולות רבות כמו “אימוץ” סביבת פיתוח משולבת Windows ותכונות רבות שנובעות מהתפתחות מערכות ההפעלה של Microsoft והתפתחות המעבדים ממשפחת X-86 של אינטל ומתחריה.
הטכנולוגיה שפיתחה TenAsys מבצעת הפרדת משאבים כדי לאפשר ל-RTOS ול-GPOS לרוץ האחת ליד השניה. התקשורת בין הליבות השונות מבוצעת על ידי רשת הקרויה : (GlobalObjectNetwork). הרשת בנויה מעל מכניזם תקשורת שמאפשר לכמה מערכות הפעלה להתקשר האחת לרעותה ברמת התהליך (process) בצורה דטרמיניסטית. פיתוח נוסף של GOBSnet הוא הרחבתו לפעול מעל Ethernet – וגם כאן בצורה דטרמיניסטית. אם נחלק את היישום ל-FunctionalBlocks – כל Block כזה יכול להיות על ליבה באחד מהמחשבים המחוברים ביניהם ברשת Ethernet או באותו המחשב עצמו. זה מאפשר לבנות (כפי שמוצג באיור 3) מערכות מבוזרות לפי שיקולים של מרחק (שמביא לביזור) או יכולת עיבוד (שמביאה לכמות הליבות בה מוטען היישום).
כל היכולות הללו מוטמעות בתוך INtime ומאפשרות ליצרנים לבנות משפחות של מוצרים במחירים שונים וביכולות שונות ללא שינוי תוכנה.
פתרונות EmbeddedVirtualization למימוש מערכות לזמן אמת התפתחו מזה למעלה מעשור. אולם הפוטנציאל המלא של התפתחויות אלו מגיע עכשיו לידי מימוש עם שכיחות של מעבדים מרובי ליבות ועם תפישת GlobalObjectNetworking שהופכת להיות ה-Standard בבנית מערכות מרובות מערכות הפעלה.
INtime מאפשרת מימוש מערכות כאלה כבר היום.
על המחבר
ChrisGrujon הינו MarketingDirector בחברת TenAsys. החברה מיוצגת בישראל מזה 8 שנים.
