Chris Grujon, TenAsys Corp.
כבר לפני 25 שנה ראו מתכנני מערכות את הפוטנציאל שטמון בשילוב Windows ו-PC.
הם ראו את אפשרויות השימוש ביכולות הגרפיות של Windows לעומת אלטרנטיבה של שימוש ביכולות הגרפיות הפרימיטיביות של DOS ומערכות ההפעלה המיוחדות (Proprietary) האחרות. שילוב Windows איפשר למתכננים של מערכות שונות, מימשק אדם מכונה מתקדם שאיפשר הפעלה ותחזוקה נוחים ביותר.
אולם הבעיה של Windows היא שאינה מספקת תגובה בזמן אמת. ניקח לדוגמא מערכות של Factory Automation. הן מטפלות ביחידות של Motion Control שדורשות תגובה מדוייקת לחיישני תנועה בזמן קצר וקבוע. כיון ש-Windows לא תוכננה לכך – נבנו רוב המערכות משניים או יותר מחשבים: האחד שמריץ Windows להספקת ממשק אדם מכונה מתקדם, והשני (או הנוספים במקרה ונדרשו כמה מחשבים נוספים) שמריצים מע”ה לזמן אמת (RTOS). מערכת הפעלה כזו מספקת את התגובות הדרושות בעיכובים קטנים ובדיוק רב.
בשנים האחרונות החלו מחשבים תעשיתיים לנצל את עוצמות החישוב של המעבדים המודרניים ואת ריבוי הליבות שלהם. ההתפתחות הזו איפשרה להם לבצע משימות שבעבר בוצעו על ידי יחידות חומרה למטרות ספציפיות כמו Digital Signal Processors על מעבד אחד מרובה ליבות.
כדי שמעבד אחד יצליח לעמוד במשימותיו, נדרש לאפשר חלוקה של משימות שבעבר בוצעו על ידי יחידות חומרה נפרדות, ושרובן אמורות לספק תגובות בזמן אמת, לתוך מעבד אחד. המעבד נדרש גם להמשיך ולספק את המטלות המסורתיות שלו כמו מימשק אדם מכונה. כל השילוב הזה צריך להתבצע מבלי לרדת בתגובתיות המערכת לאירועים – בעיכובים קצרים ביותר ודיוק רב.
עקרונות מערכות בקרה
כדי להבין את הקושי בהרצת כמה יחידות פונקציונליות של המערכת (למשל כמה יחידות של Motion Control) על מחשב מרובה ליבות, כדאי להבין את הדרישות שמוטלות על התוכנה. מכונות נשלטות על ידי תוכנת בקרה בלולאה. מערכת הבקרה שולחת פקודה ודוגמת את המערכת בצורה מחזורית כדי לבצע תיקונים. התיקונים ממשיכים עד שהמערכת הנעה הגיעה ליעדה. ככל שהפעולה מורכבת ומהירה יותר – נדרש זמן לולאת תוכנה קצר יותר.
מימוש לולאת הבקרה בתוכנה נעשה על ידי התעוררות של תהליך בעדיפות גבוהה במערכת הפעלה לזמן אמת.
הארוע נוצר על ידי שעון פנימי שיוצר פסיקה (interrupt) שמפסיקה את ריצת המעבד שבאותו הזמן רץ על קטעי תוכנה אחרים. תוך כדי הפסיקה נקראים הסנסורים ובסיום הפסיקה מתבצעת פעולת “אפשור פסיקות” כדי שהמעבד יוכל להגיב לארועים אחרים. מנגנון התזמון (scheduling) של מערכת ההפעלה גורם למשימה שבעדיפות הגבוהה מאלו המחכות בתור לקבל את המעבד לשימושה. בדרך כלל המשימה היא עיבוד המידע שהתקבל כדי לייצר תגובה מתאימה, או המשימה יכולה להיות עדכון מימשק אדם מכונה שרץ לצידה של מערכת הבקרה. אם אין משימות לביצוע – המעבד יכול להיות במצב של “משימת מנוחה” (idle thread) עד לפסיקה הבאה של השעון. מהלך היישום שתואר כאן מודגם באיור מספר 1. ציר ה-X הוא ציר “תדירות הדגימה”, ציר ה-Y הוא יכולת הביצוע של המעבד. כשמגדילים את יכולת העיבוד (למשל עוברים למעבד יותר חזק) מתקדמים בציר ה-Y מבלי לקצר את זמן ה-control loop ואז מקבלים idle time גבוה יותר.
כשמתקדמים בציר ה-X – כלומר מעלים את תדר הדגימה באותו מעבד – עוברים
ל-A2 וה-idle time קטן.
המצב נעשה מורכב יותר כשמנסים לתת למעבד אחד לטפל בשתי לולאות בקרה ויותר. לדוגמא מימשק לשני מנועים בפרוטוקול מעל Ethernet הקרוי Ethercat. הפרוטוקול הזה מאפשר למספר רב של התקנים “לשבת” על Ethernet Bus. כל אחד מההתקנים “שולף” ביטים המשויכים אליו שמגיעים מה-master ו”שם” ביטים משלו בתוך מבנה ה-packet “שעושה סיבוב” בין כל ה-slaves בדרך חזרה
ל-master. ממשק זה מאפשר בקרה מהירה ביותר למרחקים גדולים במחיר זול.
עשינו ניסוי בשתי לולאות בקרה שמפעילות ממשק Ethercat והוא מתואר באיור מספר 2. לולאה אחת A – של מילי שנייה אחת ושנייה B – של שלש מילישניות.
עבור היישום הזה על המתכנן לקחת בחשבון את הנושאים הבאים:
1 – דגימת הנתונים חייבת להתבצע במועדים מסוימים בתוך לולאת הבקרה – ולבטח לא לחרוג ממשך הלולאה. המשמעות היא שה-thread של הדגימה חייב להית בעדיפות הגבוהה ביותר. בנוסף, כשהמעבד מריץ שתי לולאות בקרה, ה-thread של דגימת הנתונים בלולאה הקצרה חייב להיות בעדיפות גבוהה יותר ממקבילו בלולאה הארוכה, כיון שאילוץ אי החריגה מגבולות הלולאה קשה יותר עבורו.
להלן תיאור העדיפויות של ה-threads מהגבוהה לנמוכה:
דגימה של לולאה A >>> דגימה של לולאה B >> עיבוד של לולאה A >> עיבוד של לולאה B >>> כל ה-threads האחרים.
2 – בכל פעם ש-thread נאלץ להפסיק את פעולתו מתבצע context switching שגוזל זמן. ככל שמספר לולאות הבקרה עולה – גדלה ההסתברות ל-context switches ונגזל זמן יקר. בדוגמא שלנו ישנם רק שתי לולאות, ואפילו בה יארע context switch אחת לכמה זמן.
3 – מאחר ששתי לולאות הבקרה אינן מסונכרנות ביניהן ישנה אפשרות ש threads שמבצעים דגימות יקרו באותו הזמן. כשקורה מצב כזה שמתואר באיור 2 – thread הדגימה של A הוא בעל העדיפות הגבוהה יותר. הדגימה צרכה להתבצע מהר ככל האפשר כי במשך כל זמן ריצתה תהיה דחיה ב-thread הדגימה של B.
העיגולים הגדולים מתארים משימות שסך הכל הזמן שלהן הוא 3 מילישניות. רואים מצב ש-thread של העיבוד של לולאה A מופסק על ידי תהליך הדגימה של לולאהB ולפיכך הוא מסתיים בזמן Tc2 שארוך מ-Tc1 שהיה מסתיים אם רק לולאה A היתה רצה. גם thread העיבוד של לולאה B מתארך ואפילו משמעותית כיון שהוא בעדיפות נמוכה יותר משני ה-threads של לולאה A, ועד שלא יסתיימו הוא לא יתקדם. ההתארכות האקראית של הזמנים שצוינה משפיעה לרעה על התיקונים שמבצעות לולאות הבקרה.
כשנשתמש במעבד חזק יותר נקטין
את הזמן הנדרש לעיבוד ונוכל להריץ מספר גדול יותר של לולאות בקרה, ונוכל לקצר גם את זמני הלולאות. אולם לא נוכל
למנוע שלולאות יפסיקו אחת את השניה מדי כמה זמן – ויגרמו לחלק מה-thread לקחת יותר זמן.
מהם latency ו-jitter
המונח latency הוא הזמן מהארוע של היוזמה לפעולה עד לזמן התגובה. בדרך כלל כשהמעבד מהיר מספיק, והמידע זמין לתוכנה בדיוק כשהיא נדרשת – ניתן לקבל latency שהינו בעל סטיות קטנות (jitter small). במערכות בקרה הסטיות הן מקור לתקלות מסוגים שונים – ואפילו סיכוני בטיחות.
קיימים שני סוגים של jitter שיש לקחת בחשבון: ה-jitter בפעולת הדגימה, והjitter בפעולת התיקון. בדוגמא שתוארה באיור 2 ישנן שתי לולאות שרצות על אותו מעבד. רואים שמשך הזמן של thread התיקון של לולאה A (בצבע תכלת) מתארך מאד. בנוסף, כיון שהלולאות אינן מסונכרנות זו לזו (אלה מנועים שונים) הזמנים בהם קורות החפיפות הללו בין האירועים משתנים. הסטיות הללו בעיכובים הינם
ה-jitter של tread התיקון.
ניתן לעיתים – במקרים מסוימים להקריב תכונות שאינן חשובות למערכת מסוימת כדי להבטיח jitter נמוך בפעולות חשובות, אבל ככל שתדירות לולאות הבקרה עולה, ואי האחידות בין תדירות הלולאות עולה, קשה יותר ויותר לספק פתרון בעל jitter נמוך על מעבד אחד.
איך ריבוי ליבות משפר את המצב
ריבוי ליבות פותח לפני המתכנן אפשרויות חדשות. מאידך אפשרויות אלה מחייבות בדיקה כיון שברור שעבור מערכת הפעלה קשה לדעת איך ומתי להקצות משאבים כדי לענות על האתגרים שהוצגו. כמה מערכות הפעלה מקצות ליבות לפי האלגוריתם של “as busy as possible” מבלי להתחשב בדרישות התזמון של משימות מסוימות. הטכניקה הזו קרויה SMP – Symmetrical Multi Processing. בצורת תזמון זו ישנה ליבה שמריצה את כל מערכת התזמון והקצאות הזכרון, והיא זו שמחליטה על הקצאת המשימות לליבות האחרות. כאשר ברקע קיימות דרישות ספציפיות של latency ו-jitter ברור שקשה מאד למערכת תזמון של מערכת ההפעלה להעריך כמה משאבי ליבה עליה להקצות למשימות שונות, וזה עוד יותר קשה כשהמשימות מתקשרות זו עם זו. במצבים אלה כמו של היישומים של motion control השימוש המועדף הוא של AMP – Asymmetrical Multi Processing. בשיטה זו כל ליבה מריצה מערכת הפעלה מלאה עם מנגנוני התזמון והקצאות הזכרון שלה. בצורת הקצאה כזו ישנו תמיד כח חישוב קבוע זמין למטלות. כמה מערכות הפעלה אף מקדמות את הרעיון של “עצמאות הליבה” בכך שהן מאפשרות לשייך פסיקות של התקני I/O לליבות מסוימות. זה מאפשר שהתקני ה-I/O יגרמו להפסקות רק של העיבודים הנוגעים למשימות שלהם ובכך לאפשר מקסימום של משאבי ליבה למשימות אחרות שגם הן נדרשות לעמוד
ב-latency ו-jitter נמוכים.
איך לאפשר למשימות לתקשר ביניהן
לאחר שהקצנו את הליבות בשיטת AMP שמאפשרת לבודד את המשימות כך שתוכלנה לעמוד בדרישות התזמונים, השלב הבא הוא לאפשר לכל המשימות “לנגן” ביחד. יש צורך לאפשר לתקשורתIPC – Inter Process Communication. מימוש נכון של התקשורת הזו יאפשר שהתקשורת בין משימות שרצות על אותה הליבה להיות זהה לזה שמאפשר תקשורת בין משימות על ליבות שונות. תכונה כזו תאפשר שנוכל להשתמש באותו Code Base לקונפיגורציות של מעבדים בעלי מספר ליבות שונה – בהתאם לדרישות הביצועים.
באיור מספר 3 רואים מעבר כזה ממערכת הבנויה על מעבד בן ליבה אחת שמריצה שלש “לולאות בקרה” למעבד בן 4 ליבות. הגיון ההקצאה של הליבות הוא שלולאהA הינה בעלת זמן מחזור מהיר בהרבה מהלולאות האחרות ולפיכך תוקצה לה ליבה שלמה – ליבה 2. יתר לולאות הבקרה תרוצנה על ליבה 3. מערכת ה-HMI תרוץ על ליבות 0 ו-1 המריצות Windows שמשתמשת בהקצאת SMP בין ליבותיה. ברור שאפשרי גם להשתמש בשלש ליבות להרצת לולאות הבקרה ורק אחת ל-HMI. הטכניקה של ההתקשרות בין לולאות הבקרה מאפשרת מעבר קל באותו Code Base – ללא שינוי ב code.
INtime – משפחת מערכות ההפעלה של TenAsys
הפתרונות שתוארו לעיל לבעיות ולדרישות האופיניות של מערכות בקרה ממומשים במשפחה של מערכות הפעלה הקרויה INtime. לפני כ-16 שנה כבר הוכרזה INtime שמבוססת על Virtualization Technology שאיפשרה ל-Windows ולמערכת הפעלה מלאה לזמן אמת לרוץ על מעבדים בני ליבה אחת. התפתחות זו איפשרה כבר אז לבנות מערכות בקרה שה-HMI שלהן ותוכנת הבקרה לזמן אמת שלהן ירוצו על אותו המחשב. במשך השנים עם ההתפתחות במעבדים מרובי ליבות, קידמה TenAsys את התכונות הנוספות הדרושות:
יכולת הקצאה סטטית לכל אחת מהליבות להריץ מערכת הפעלה מלאה לזמן אמת INtime או Windows.
יכולת הקצאה סטטית של איזה פסיקות ישויכו לאיזו מהליבות המריצות INtime.
יכולת הקצאה סטטית לפי מסך קונפיגורציה, או דינמית לפי החלטת התוכנה (ב-Windows או ב-INtime) אילו משימות יטענו לכל ליבה של INtime.
יכולת תקשורת בין משימות הקרויה Global Object Communication או GobsNet – שמאפשרת ליצור מנגנוני תקשורת שהפעלתם זהה בין אם המשימות רצות על אותה הליבה, על ליבות אחרות השיכות לאותו מעבד, או על ליבות השייכות ל-PC אחר שמריץ INtime ומחובר ברשת.
יכולת זיהוי של התכנה לתשאל על אודות קונפיגורצית החומרה שהיא רצה עליה: איזה וכמה ליבות על אותו מחשב, ואיזה וכמה ליבות על מחשבים אחרים המחוברים ברשת LAN.
יכולת של INtime לרוץ על כל הליבות של פלטפורמת PC ללא Windows. במערכות כאלה ה-HMI פרימיטיבי יכול לרוץ על הפלטפורמה הזו, ובמידה ו-HMI משוכלל נדרש (או נדרשות תכונות שקיימות
ב-Windows אבל לא ב-) מקבלים אותן דרך הרשת ממחשב Windows מרוחק.
כפועל יוצא של התכונות הבסיסיות שהוזכרו, ניתן לאפשר code base אחד לכל הקונפיגורציות בהן משולבים Windows ו-INtime. השילובים שונים בביצועים בדטרמיניסטיות ובביזור, אבל זהים מבחינת ה-code. קונפיגורציה מורכבת כזו מתוארת באיור מספר 4 . באיור רואים PC אחד המשלב Windows ו-INtime ו-PC שני המריץ רק INtime.
איך לאפיין ולפתור דרישות הנוגעות ל-latency ו-jitter
מטרת המאמר היתה להציג ולהסביר את דרישות “זמן אמת” של מערכות. המאמר בחר לדון ביישומים של motion control משום שעבורן קל להדגים ולהסביר מה החשיבות של עמידה ב-latency ו-jitter נמוכים וכמה בדיוק הם חיבים להיות.
יחד עם זה , קיימים יישומים רבים אחרים שבהם יש חשיבות לתכונות הנ”ל אולם המתכנן לא ער להגדרה כמותית של אותן התכונות. בחלק גדול מהמקרים הוא יממש את המערכת באמצעות Windows. גם כשישלים את תכנות המערכת יקשה עליו למדוד את הפרמטרים הללו. ואולם בבדיקות המערכת יופיע לעיתים bugs או “glitches” שמקורם באי התחשבות ב-latency ו\או ב-jitter בזמן התכנון. במקרים כאלה מכיון שסביבת המדידה לא הוכנה, יהיה קשה לאתר את הגורם הבעיתי ועלולים להיגרם עיכובים בפרויקט.
הפתרון ל”מלכוד” הזה הוא לבצע ניתוח תיאורטי שמבוסס על הדרישות של התקני ה-I/O לפני בחירת הקונפיגורציה. באמצעות חישובים וניתוחי worst case עבור כל ההתקנים – להגדיר את ה-latency וה-jitter הדרושים ביישום, ואת אמצעי המדידה שלהם.
לא תמיד ניתוח תיאורטי מסוגל לתת את התשובות הרצויות. במקרים כאלה לא מומלץ להמתין לסוף הפרויקט רק כדי לדעת אם המערכת שפותחה עומדת בדרישות. עוד לפני הפיתוח של המוצר ניתן לבנות באמצעות INtime על מיגוון הקונפיגורציות וקלות הפיתוח שלה, מערכת “מוקטנת” למדידת הערכים הדרושים של ה-latency וה-jitter מול התקני ה-I/O. ל-INtime ישנם אמצעי עזר רבים לפיתוח מערכת “מוקטנת” למדידות. הפיתוח הוא באמצעות Visual Studio בכל חלקי הפיתוח וה-debug, ועומדים לרשות המפתח כלי מדידת זמנים גרפיים המקלים על המדידות. בנוסף אפשר להשתמש בתוכנית דוגמא להצגת היסטוגרמה שתראה את התפלגות
ה-latency וה-jitter לאורך זמן. אם רוצים להסתמך על בדיקה חיצונית אוביקטיבית ניתן לבצעה באמצעות אוסצילוסקופ, ושילוב פקודות בתוכנה של המערכת המוקטנת שיפעילו סיגנלים שזמנם ימדד על ידי האוסצילוסקופ. קיימים היום אוסצילוסקופים שאוספים מידע (למשל של jitter או latency) לאורך זמן ומציגים את ההיסטוגרמה שלו.
אם בהרצת המערכת ה”מוקטנת” מול התקני ה-I/O מתברר שנחוצים פרמטרים “נוקשים”, אזי ברור ש-Windows לא תוכל לבדה לספק את המענה, ונדרשת תוספת של מערכת לזמן אמת כמו INtime. במקרים כאלה ניתן להיעזר בקוד שכבר פותח לצורך בנית מערכת המדידה ה”מוקטנת” הנ”ל, ולספק מערכת שבה INtime משמש המרכיב בטיפול ב-I/O ה”נוקשה בדרישותיו” ובתהליכים הקשורים אליו.
About the Writer:
This article was written by Christophe Grujon, Marketing Director at TenAsys Corp. Beaverton, Oregon USA.
