מאת: אסף גליל
מערכות משובצות מהוות שנים רבות את הלב במוצרים ומערכות שסובבים אותנו. המחשבים או המיקרומחשבים מהוים חלק חשוב, ולעיתים מרכזי במערכת – אולם הם אינם נראים בהכרח כמחשב: התקני הקלט\פלט העיקריים שלהם אינם נראים כמקלדת ומסך – ופעולתו המרכזית של המחשב הוא להפעיל התקני קלט\פלט ייעודיים התלויים ביישום. למשל מנועים של רובוט, סנסורים מסוגים שונים וכו’. קיימים פתרונות רבים לבנית מערכות משובצות. מטרת מאמר זה להציג פתרון שנבדל מאחרים בכך שנותן מענה רחב בכמה משתנים ועדיין דורש מאמץ פיתוח תוכנה אחד. המשתנים הם:
1) מספר התקני ה-I/O והביצועים
2) כמות הצמתות בקונפיגורציה מבוזרת של אותו המוצר.
3) מוצרים נגזרים מהמוצר המפותח
4) מוצרים שמלווים את המוצר המפותח: מבדקים, סימולטורים מכשירי הדגמה וכו’
שרטוט מספר 1 מערכת Real Time מבוזרת : Windows מתקשר באמצעות Over LAN NTX לכמה PCs שמריצים INtime
שרטוט מספר 2 חלוקת ליבות בין Real Time ל-Windows במוצר המכיל Windows
שרטוט מספר 3 – שלבי הפיתוח של מרכיב INtime
שרטוט מספר 4 - פיתוח תוכנת Embedded ו-Debug לקונפיגורצית מוצר שבו Windows ו-INtime רצים על אותו ה-PC התקשורת באמצעות זכרון משותף.
שרטוט מספר 5 - פיתוח תוכנת Embedded ו-Debug לקונפיגורצית מוצר שמריץ רק את INtime, התקשורת בין שני המחשבים באמצעות LAN.
מאפייני המערכות המשובצות
האתגרים בבנית מערכות משובצות שונים מאלה שאיתם מתמודדים יצרני מחשבי שולחן ,מחשבים ניידים, שרתים ואחרים.
ניתן להגדיר שלש תכונות עיקריות שמאפינות ומבדילות את המחשבים במערכות המשובצות. בכל מערכת משובצת נדרשת לפחות אחת מהתכונות. כיון שאין עדיין מושגים מדויקים בעברית שמתארים את התכונות – נשתמש במונחים הלועזיים:
דטרמיניסטיות – יכולת להגיב בזמן קצר ללא חריגות (jitter נמוך).
רובוסטיות – עמידות בפני בעיות תוכנה וחמרה שמאפשרת עבודה ברציפות ללא הפסקה או התערבות מפעיל.
סטביליות – יכולת ביצוע משימות I/O תמיד באותו סדר פעולות.
שרטוט מספר 6
בחירת החומרה למערכת המשובצת: המעבד והתקני I/O
התקני I/O הם רבים ומגוונים וקימות ארכיטקטורות רבות לחיבור ההתקנים למעבד. אנו נתרכז במאמר זה במעבד עצמו, ובארכיטקטורה של מיקום המעבד במערכת: מרכזי או מבוזר.
בחירת המעבד
בנושא המעבד המאמר מתייחס אך ורק למשפחת X86 – תוצרת Intel, AMD, VIA ואחרים.
פרמטרי המעבד החשובים הם:
1 – ביצועים ביחידות ביצוע אבסולוטיות.
2 – הספק ביחידות הספק אבסולוטיות.
3 – יחס ביצועים להספק.
4 – מחיר ביחידות אבסולוטיות.
5 – יחס מחיר לביצועים.
עקב חוזקן של יצרניות המעבדים למשפחת X86, התחרות העזה ביניהן, וגודלו של השוק של המערכות המשולבות – הולכים ומשתפרים כל הפרמטרים הנ”ל של המעבדים ממשפחת X86 מול מתחריהם בארכיטקטורות ARM PowerPC ואחרות. באמצעות חיפוש פשוט ברשת ניתן לאתר אלפי כרטיסי מחשב X86 ראשי, במיגוון גדלים, הספקים, ביצועים ומחיר. ללא ספק – מספר הכרטיסים בארכיטקטורת מעבדי X86 שניתן לרכוש עולה בצורה משמעותית על כל ארכיטקטורת מעבד אחרת.
ביזור המחשבים
סעיף נוסף חשוב בבחירת החמרה היא אופן ביזור המחשוב. במקרים רבים – המעבדים צרכים לטפל בהתקני I/O שקרובים אליו פיזית – ואם המערכת פרושה על פני מרחק של יותר ממטרים בודדים – יש לשקול לבנות את המערכת בצורה מבוזרת , כשהמעבדים מרוחקים זה מזה – ומתקשרים ביניהם בקצב מהיר. כלומר: אופצית ביזור המעבדים – במינימום שינויי תכנה – נדרשת לעיתים תכופות.
בחירת התכנה למערכת המשובצת
מענה לדרישות המיוחדות
לצורך מענה לדרישות המיוחדות פונים המתכננים לעיתים למערכות הפעלה המיוחדות למטרה זו: למשל QNX, VXWorks ,Integrity. אולם מתכננים רבים מתלהבים דווקא מהאפשרות להשתמש באחת ממערכות ההפעלה של Microsoft ובצדק. Windows פופולרי בין המשתמשים – הרגילים לממשק אדם\מכונה שלה, וגם בקרב קהילת המפתחים – כיון שניתן בנקל למצוא מתכנתים בעלי נסיון, וניתן בקלות יחסית לפתח בזכות סביבת הפיתוח המשוכללת Visual Studio.
אולם, במקרים רבים ההתלהבות מ-Windows משכיחה מהמתכננים הזקקות של היישום לאחד או יותר משלושת התכונות הנ”ל דטרמניסטיות רובוסטיות וסטביליות הנדרשות, ומכאן מגיעם ל”חלום הרטוב” ש-Windows יספק גם את שלשת התכונות הללו.
אולם – קשה עד בלתי אפשרי (עקב סתירה תכנונית) לקבל את כל התכונות – גם אלה של המחשב השולחני שבהם מע”ה Windows מצטיינת, וגם אלו של המערכת המשובצת במע”ה אחת. הפתרון של TenAsys – חברה אמריקאית הפעילה בתחום כבר 12 שנה – הוא לשלב בין שתי מע”ה, האחת היא INtime שמספקת את שלשת התכונות והשניה היא Windows. זה אינו פתרון וירטואליזציה שבו Windows מופרד גם מבחינה פיזית, וגם מבחינת סביבת הפיתוח ממערכת הפעלה יעודית. זהו פתרון של שתי מערכות הפעלה מופרדות המשולבות זו בזו מבחינת יכולת הגישה של כל אחת לאוביקטים של השניה (Mailboxes Semaphores Shared Memory), ובעלות סביבת פיתוח אחידה. כל ה-processes שדורשים אחת משלש התכונות הטיפוסיות למערכות משובצות ירוצו מעל מערכת INtime וכל היתר מעל Windows.
ניתן להשפיע על רמת השילוב במוצר המפותח על ידי בחירת סוג Windows אופן הקצאת הליבות (כמה ל-INtime וכמה ל-Windows) וביזור המערכת – קיום מחשבים שמריצים חלק מהתהליכים עם INtime בלבד, ומחוברים בחיבור LAN.
בשרטוט מספר 2 מתוארת חלוקה אפשרית: שתי ליבות “מוקצות” ל-Windows ושתיים מוקצות ל-INtime – מערכת הפעלה לזמן אמת המיועדת למערכות משובצות, גם כשהיא פועלת עם Windows וגם כשהיא פועלת ללא Windows.
Windows מחלק את המשימות שלו במנגנון Symmetrical Multi Processing – SMP. ליבה אחת מריצה את ה-Scheduler שמריץ את התהליכים השונים לפי שיקולו – ובהשפעה מסוימת ניתנת למשתמש יכולת לקבוע עבור processes מסוימים באיזה ליבה לרוץ.
INtime – נטענת בשלמותה לליבות שעבורם היא מוגדרת. יחד איתה נטענים ה-processes – בצורה סטטית, יחד עם עליית ה-kernel, או בצורה דינמית – כשהתכנית בחלק ה-Windows שלה או בחלק ה-INtime שלה מטעינה את ה-process בזמן המתאים. ה-Scheduler הוא חלק ממע”ה שנמצאת בשלמותה בכל ליבה, וקיימת התקשרות ברמת האובייקט בין הליבות המריצות INtime לבין עצמן, ובינן לבין windows.
המאמר מתיחס לקונפיגורציות שונות שבהן INtime מריץ מספר ליבות הנע מליבה אחת לסה”כ כל הליבות (ללא Windows). במקרה הזה שבו ה-PC מריץ רק את INtime ניתן להוסיף PC חיצוני – שמספק את פונקציות ה-Windows הדרושות Gui: גישה לדיסק וכו’.
מענה לדרישות שאינן ייחודיות למערכת משובצת באמצעות Windows ו-INtime
התכונות הנוספות – שמשפיעות על בחירת מערכת ההפעלה למערכת המשובצת קשורות לאופן הפיתוח של התכנה, ולתכונות הגלומות בה לשימוש המוצר:
1) ביצועים – במערכת בה רצות שתי מע”ה – כל אחת מספקת פתרון בביצועים גבוהים ל-processes שלה. Windows באמצעות SMP מבצעת זאת היטב במספר ליבות נמוך, אולם תהליך ה-Scheduling שרץ על ליבה אחת עלול להוות Bottleneck במספר ליבות גבוה. INtime שפועל בכל ליבה עם כל המשאבים, מגדיל ליניארית את הביצועים לפי מספר הליבות.
2) ממשק אדם מכונה – Windows היא התוכנה המקובלת בעולם כמע”ה בעלת ממשק אדם מכונה העשיר והמשוכלל ביותר.
3) שימוש בתוכנות מדף – עבור Windows ניתן למצוא תוכנות מדף במיליונים. התוכנות ברמת ה-source ניתנות לניצול בשינוי קטן גם ב-INtime.
4) יכולת תכנות ו-Debug נוחה באמצעות Visual Studio גם עבור קטעי הקוד של Windows וגם אלה עבור INtime. זו סביבת הפיתוח המקובלת כטובה וכמפותחת ביותר והמיוחד הוא שהמפתחים הרגילים ל-VS יכולים לדבג קוד שרץ בזמן אמת. אין כאן שום סימולציה – הקוד רץ בסביבת הפיתוח וב”השגחה” של VS בדיוק באותם התזמונים שירוץ במוצר הסופי. מימוש חלק INtime של הישום מתואר בשרטוט מספר 3.
5) הכרות קהילת המפתחים – סביבת הפתוח בחלק של INtime הוא תכנות ב-C ו\או C++. בנוסף ניתן לכתוב בצד ה-Windows ב-DOTNET ולפנות ישירות ל-Objects של INtime. השימוש בשפות אלו מוכר לכל מתכנת.
6) שימוש בחלקי תוכנה גם בשינויי קונפיגורציות חמרה. זהו אחד מהסעיפים שלעיתים קרובות נשכח. בכל פרויקט יש צורך בסביבת בדיקות סימולטיביות – סביבה בה התכנה פועלת באותם קצבים עם רכיבי I/O “מוחלפים”. קיימים גם מקרים שיש לתמוך במשפחת מוצרים שנבדלים בגודל, בביזור, במספר התקני I/O. חשוב ביותר הוא להשתמש ככל האפשר באותה התכנה ולא לפתח מספר “פרויקטים”.
המבנה של סביבת הפתוח של INtime מאפשר בדיוק את זה.
בשרטוט 4 ו-5 מופיעות קונפיגורציות הפיתוח עבור גירסת המוצר שפועלת על PC אחד , ועבור הגירסא שפועלת על שניים (או יותר PCs). הפיתוח וה-Debug זהים לחלוטין. הפניה לשכבת NTX – המימשק בין שתי מע”ה היא זהה בין אם מבצעים קונפיגורציה של פעולה על אותו ה-PC שבה המימשק בין שתי מע”ה הוא דרך הזכרון, לקונפיגורציה מבוזרת בה נמצאים שני PCs (או יותר) בחיבור רשת.
שני השרטוטים 4 ו-5 ממחישים את היתרון הגדול של צורת הפיתוח: ניתן לעבור בין קונפיגורציות ללא מאמץ פיתוח. ניתן לבצע Debugging ללא חומרה אלא בסימולצית זמן אמת שבה process ב-INtime מחליף את ה-I/O האמיתי ללא הבדל בתזמונים. ובכך להוזיל בהרבה את מחיר עמדות הפיתוח.
שרטוט מס’ 6 מסכם את מיגגון האפשרויות שעומד בפני המתכנן בבואו לממש מערכת משובצת. לעיתים רבות משתמש מתכנן משפחה של מוצרים: נגזרות שונות של אותו המוצר, או מוצרים שונים הנדרשים תוך כדי פיתוח: מבדקים,סימולטורים או מוצרי הדגמה.
בטבלה נכלל גם מוצר של TenAsys הקרוי eVM שהינו Real Time Hypervisor שמאפשר פיתוח שלם מעל מערכת הפעלה משובצת אחרת לרוץ ללא שינוי מעל ליבה של X86 ומבטיחה את התכונות הבסיסיות של תגובה לפסיקות וכו‘ שהיו במוצר המקורי.
לסיכום
העובדה ששתי מע”ה האחת של TENASYS והשניה של MICROSOFT רצות זו לצד זו בצורה מופרדת ומוגנת כשכל אחת משמרת את תכונותיה אבל יחד עם זאת בשיתוף הדוק ביניהן – מאפשרת מיגוון פתרונות רחב ביותר בכל הפרמטרים, למפתח המערכת המשולבת.
אסף גליל הינו מהנדס יישומים של חברת TenAsys והחברה שבבעלותו היא נציגת TenAsys בארץ. לאסף למעלה משלושים שנות ניסיון בשוק ה-Embedded.
