כדאי לשלב יכולות לזמן אמת בחלק גדול ממערכות Embedded

הקדמה

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

מדוע בחירת מרכיבים למערכת Embedded הינה משימה מורכבת ?

הדרישה למערכות מחשב ליישומי Desktop ו Server גדולה מאד ולכן ליצרנים משתלם לבנות ולהציע מיגוון מערכות מחשב מלאות.משתמש הבוחר מערכת כזו אינו חייב להרכיב אותה מאבני בנין שירכוש מספקים שונים, אלא יכול פשוט לבחור מתוך דף נתונים ומחירים של מערכת מלאה. גם הבחירה במערכת ההפעלה היא פשוטה : הוא יבחר בדרך כלל בגירסא של Linux או Windows. לעומת זאת מערכות Embedded עונות למגוון עצום של דרישות ובחירת המרכיבים מסובכת יותר.

כמעט אף פעם לא ניתן לרכוש מערכת מלאה עבור ישום Embedded ויש צורך לבנות אותה מאבני בנין של יצרנים שונים. בחירת מערכת ההפעלה גם היא משימה מורכבת יותר, ובה נתרכז במאמר זה .

הדרישות מהמערכת

מהנדס המערכת המודע למכלול המרכיבים הטכניים של המוצר מגדיר את דרישותיו מהמוצר:

1. אילו ביצועים, איזה הספק איזה מחיר? – שלשת אלה יובילו לבחירת המעבד.
2. מול אילו התקנים תעבוד המערכת? – מוביל לבחירת הממשקים : מודולי \ כרטיסי ה I/O
3. באיזה אופן עובדת המערכת מול מפעיל אנושי ומול התקנים חיצוניים? – מוביל לבחירת מערכת ההפעלה .

בחירת המעבד

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

מאמר זה מתרכז במעבדים ממשפחת אינטל ותואמי אינטל – X86 המקובלים כפתרון מצוין למערכות Embedded בתחומים רבים.

בחירת הממשקים

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

בחירת מערכת ההפעלה

ממשק מול מפעיל אנושי :

האם נדרש ממשק כזה, ואם כן – האם יש יתרון לממשק GUI משוכלל או לפונקציות מורכבות של ניהול דיסק.

ממשק מול התקנים לא מאוישים

לכל פרוטוקול יש הגדרות בסיסיות. למשל עבור תקשורת טורית ישנן הגדרות של Baud Rate וממשק פיזי.

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

דרישות התזמונים של הממשקים : Jitter ו Latency

מהם Latency ו Jitter

latency (בעברית “השהיה”) הוא העיכוב מזמן הופעת הסיגנל החשמלי בכניסה למחשב עד לקריאתו על ידי תוכנת הטיפול בו.

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

אילו ה-Latency היה קבוע ניתן היה לעיתים לעקוף את הבעיה ו”לקחת אותה בחשבון”, אבל בדרך כלל ה-latency משתנה.

לשינוי המקסימלי מעל הערך הממוצע קוראים Jitter (בעברית “ריצוד”) .

איור 1 מציג תוצאה גרפית של ניסוי שמודד Jitter. בניסוי נמדדים ההפרשים בין הזמן שסיגנל הכניסה מגיע, לזמן שבו תוכנת היישום קוראת אותו. ארוע כזה קורה כל 50 מיקרו שניות (1), ונאספות תוצאות של של כ 1.6 מיליון אירועים כאלה (2). הlatency נע בין מינימום של 49.19 (3) למקסימום של 50.91 מיקרו שניות (4), כך שה-Jitter שהינו כאמור ה Worst Case ביחס ל 50 – עומד על 0.91 מיקרושניות.

מאפיני ה-Jitter וה-Latency בממשקים טוריים

בעבר הממשקים החיצוניים היו בעיקר מקבילים – מספר רב של פינים היה שולח \ מקבל מידע . זמן העברת המידע עצמו היה קצר. כלומר אם משימת הקריאה היתה בעדיפות גבוהה , מיד מרגע שהנתונים הופיעו על הפינים של הממשק התוכנה יכלה לקרוא אותם .

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

באיור מספר 2 מצורף “צילום” זמנים של ניסוי שממחיש זאת. בניסוי שולחת תוכנת Client – UDP packet לכיוון Server , וזה מחזיר לה UDP packet עם אישור קבלה ספציפי.

האיור מראה את ההתרחשויות בצד ה -server. ציר ה-X הוא ציר הזמן והשנתות מופיעות כאן במיקרושניות . ציר ה y הוא ציר המשימות – threads ו process (מאגד קבוצה של threads שחולקים אותו memory pool).

Interrupts מסומנים באות Q, פקודות מערכת ההפעלה ב-A וקריאות לפונקציות בשפת C באות c . חץ כלפי מטה הוא כניסה אל מערכת ההפעלה וחץ למעלה יציאה ממנה.

המספר המסמן את העדיפות של ה-thread ניתן לקריאה ומוצג להלן. ככל שהמספר גבוה יותר העדיפות נמוכה יותר.

הארוע הראשון שמסומן ב 1 – הוא Interrupt שמתקבל מכרטיס הרשת. בעקבותיו רץ ה-driver  בעדיפות 54. מאותו הרגע רץ thread של ישום ה server  שרץ בעדיפות 155 ומופרע לעיתים על ידי threads של ה IP stack  הרצים בעדיפות 134. על החומרה המסוימת בה נערך הניסוי הפעולה , הזמן בין ה cursor בצבע תכלת ל cursor הצהוב הוא 105 מיקרו שניות ומסומן באיור ב מספר 5. כל הthreads , בין אם הם של ה server או של הפרוטוקול, מתחרים ביניהם על זמן המעבד לפי העדיפות שלהם. אם תוך כדי הטיפול (קבלה ושליחה) יתעורר לעיתים thread בעדיפות גבוהה יותר מ 155 אזי ה Jitter יגדל משמעותית – בתלות באורכי המשימות ה”מפריעות” הללו.

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

מערכת ההפעלה INtime

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

כמו כל מערכת הפעלה מלאה לזמן אמת היא בעלת התכונות הבאות

Interrupt driven – לINtime ישנן שתי אפשרויות להתיחסות ל Interrupt

Preemptive – ניתן להפסיק מיידית כל thread לפי מפתח עדיפות .

Priority – ישנן 255 רמות: 0 העדיפה ביותר 255 הפחות עדיפה.

מערכת ההפעלה בעלת פונקציות מהירות מאד.

הthreads של מערכת הפעלה מוגדרים תמיד בעדיפות נמוכה ככל האפשר (וניתנים ברובם לכוונון).

באיור מספר 3 מוצגים באדום מרכיבי INtime. קיים גרעין שמעליו רצים תהליכים המסופקים עם INtime ותהליכי היישום. לצידם (על ליבות אחרות) – משורטט בכחול: נמצאת מערכת ההפעלה Windowsוהתהליכים שהלקוח כותב מעליה. בין שני החלקים קיים ממשק הקרוי NTX שמאפשר לתהליכים של Windows לגשת לאוביקטים של INtime. פרט לגישה לזכרון משותף יש גישה ל semaphores mailbox וכו’.

הפסיקות – Interrupts

מרכיב חשוב בכל מערכת הפעלה ובמיוחד במערכות הפעלה לזמן אמת הוא אופן הטיפול ב-Interrupts. כל מערכת הפעלה תומכת ב Interrupts, אבל רק מערכות הפעלה לזמן אמת מאפשרת למשתמש ב User Mode לנהל אותם ישירות .

יכולות ההפעלה של הפסיקות ברמת ה user חשובות מאד כדי להבטיח Jitter נמוך.

בINtime קימות שתי רמות :

Interrupt handler

מופעלת על ידי חומרה. ב Handler כותבים בדרך כלל מעט מאד פקודות, והכניסה והיציאה ממנו מהירים מאד.

Interrupt thread

כשנדרשת פעולה מורכבת יותר שקורית כשמפסיקים ריצה של thread אחר, ה handler אינו חוזר ישר לנקודה בה ארע, אלא מכניס לפעולה, לפי עדיפות ,thread חדש ובו מקודדת המשימה המורכבת.

למשל בניסוי שתואר באיור מספר 2 – משימה זו היא ה driver של הכרטיס שרצה בעדיפות 54 .

איור מספר 4 מראה את שני סוגי ה-interrupt. שימוש מושכל בהם במהלך התכנון – מבטיח Jitter נמוך .

ריבוי ליבות

בשנים האחרונות הפכו המעבדים למרובי ליבות ובוני המערכות מעונינים לנצלן כמה שאפשר.

במערכות הפעלה כמו Windows או Linux עליהם רצחם מאות או אלפי threads בכל יחידת זמן – מנהלת מערכת ההפעלה עצמה את חלוקת המשאבים “בצורה הוגנת” בשיטת (SMP (Symmetrical Multi Processing. ליבה אחת מבצעת תזמון והקצאת משאבים (זכרון וזמן מעבד) עבור כל הליבות. ניהול כזה אינו מאפשר Jitter נמוך, ובנוסף ניפוי שגיאות בנושא תזמונים הוא משימה מורכבת ביותר.

מערכות לזמן אמת שחייבות Jitter נמוך, אינן יכולות להעביר את השליטה למנגנון “הוגן”, ובנויות כך שכל ליבה מנהלת את המשאבים שלה. זוהי שיטת AMP – Asymmetric Multi Processing.

איור מספר 5.1 מציג שלש קונפיגורציות בהן INtime רצה לצידה של Windows.

Windows רצה ב-SMP מעל כל הליבות “שלה” ו-INtime ב-AMP .על כל ליבה “של” INtime רצה מערכת הפעלה מלאה שמתקשרת עם האחרות באמצעים שונים.

במידה ולא נדרשות יכולות Windows מהיישום, ניתן להשתמש באותו Code Base בקונפיגורציה המוצגת באיור 5.2. INtime מבצע Boot בכל הליבות שלו ישירות מהדיסק , ולא דרך תהליכים של Windows ש”מעירים” אותו.

איך נבנה את הפרויקט

הפתרון המומלץ לבנית מערכת Embedded שיש (או קרוב לוודאי שיהיו עבורה) דרישות timing למממשקים:

הגדרת המערכת הבסיסית עם INtime for Windows

העברת הממשקים שעבורם יש דרישות תזמון ל INtime

במהלך הפרויקט ניתן לשנות את נקודת החלוקה בין ההתקנים והתהליכים מצד INtime לצד windows ולהיפך, ואפילו להגיע לקונפיגורציה ללא Windows בכלל. כל הפיתוח נעשה ב Visual Studio גם בצד INtime וגם בצד Windows כך שהעברת הקוד בין שתי הסביבות קלה ביותר.

כפי שראינו בדוגמא של הממשק הטורי (הוצג ממשק UDP) , משימות רבות, שחלקן אפילו מסופק על ידי מערכת ההפעלה, מתחרות על המשאב החיוני – זמן CPU .

מצד שני – אם מאות משימות תתחרינה על המשאב הזה , ונרצה להבטיח Jitter נמוך – ניאלץ לבצע עבודת כוונון מורכבת של ניסוי וטעיה.

לכן נשאיר את כל התהליכים שאינם מחייבים Jitter נמוך ב Windows .

לעומת זאת אם אין כלל תהליכים “טבעיים” ל Windows (כמו GUI או File System מורכב או Drivers שקיימים ב-Windows ואינם קיימים ב INtime) כדאי לשקול להשתמש בקונפיגורציה של INtime Only .

בקונפיגורציה כזו נחסכים משאבי זכרון RAM ודיסק, משתפרת האמינות (פחות תהליכים) וזמן עליה קצר מאד אחרי הדלקת מתח

סיכום

המאמר תיאר את בחירת המרכיבים לבנית מערכת Embedded והתרכז בבחירת מערכת ההפעלה .

יש הסבורים שהמעבדים החדשים הם כל כך מהירים שיוכלו להגיב תמיד בזמן קצר מאד לכל התקן ואין חשיבות באיזה מערכת הפעלה נבחר. אבל אמירה זו שגויה: אכן – ככל שהמעבד מהיר יותר ממוצע זמן התגובה יהיה נמוך יותר – אבל ה Jitter שהינו ה worst case deviation כמעט לא ישתנה ועלול לגרום לכשל.

רק מערכת הפעלה לזמן אמת יכולה להבטיח Jitter נמוך.

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

התרכזנו בפתרון מערכת הפעלה INtime עבור מעבדי X86. הפתרון הזה ייחודי בכך שמאפשר שילובים מגוונים בזמן הפיתוח ובמוצר הסופי עם Windows . בנוסף – סביבת הפיתוח של Visual Studio בכתיבה גם בצד INtime מקילה על הפיתוח, ומאפשרת ל INtime להשתמש בקטעי קוד שפותחו עבור Windows .

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

על המחבר

אסף גליל הוא מהנדס יישומים של חברת TenAsys. לאסף למעלה מ 30 שנות נסיון במערכות משובצות מחשב עם דגש על מעבדים ותוכנות למשפחות X86 .