תקציר
במאמר נציג מערכת הפעלה ייחודית למערכות Embedded ששמה INtime for Windows שמפותחת ונתמכת על ידי החברה האמריקאית TenAsys . יוסבר הצורך בשילוב יכולות GPOS ו RTOS במערכת Embedded אחת , ואת היתרונות המוצעים על ידי INtime for Windows בהקשר זה.
INtime נפוצה בעולם כמע”ה במספר רב של יישומים. בארץ עקב הדומינננטיות של שוק המפתחים של מכשירים לשימושים צבאיים , יש לה הצלחה רבה במגוון יישומים כמו מערכות בקרה לנשק, רדארים , מערכות Hardware In the Loop למפתחי מערכות טילים ומזלטים ועוד. ליישומים המפותחים יש דרישות שונות , ומטבע הדברים , INtime חייבת לספק מענה למיגוון דרישות בפונקציונליות , ובפיתוח.
כדי להמחיש את היתרונות בחרנו שלשה OEMs ישראליים ,שמזה כ 8 שנים מפתחים ומיצרים מערכות שמצליחות לשמר יתרון מול מתחריהן , ושמבוססות INtime For Windows . מוצג אופי הפיתוח הייחודי של כל אחד מהלקוחות הללו שמותאם לאופי השונה של המוצרים בפיתוח .
פרטי השימושים השונים , ושיטות הפיתוח השונות ממחישים את מיגוון אפשרויות הפיתוח שניתן להתאים , ובכך להקל ולקצר את הפיתוח , הסימולציה ,הבדיקות והתמיכה.
בחירת מערכת ההפעלה
ההחשיבות לבחירת מערכת ההפעלה עבור יישום הEmbedded היא בכך שהיא משליכה על הסיכונים בפרויקט ועל התחרותיות של המוצר הסופי – מול הדרישות ומול המתחרים .
קימות שתי “משפחות” של מערכות הפעלה : GPOS ו RTOS.
GPOS General Purpose Operating System – .
לדוגמא Windows Unix Linux Android .
RTOS Real Time Operating System – .
למשל , VX-Works QNX INtime For Windows , INtime Distributed RTOS, .
כל מערכת ממוחשבת : שולחניות שנמצאות מול מפעיל \ משתמש , וגם servers , שמרוחקים מהמפעיל \ משתמש , דורשת תכונות שאופיניות ל GPOS ברמת פונקציונליות זו או אחרת : טיפול במסך הפעלה , ניהול קבצים , ניהול ריבוי משימות ועוד.
פרט לתכונות הנ”ל למערכות Embedded ישנן דרישות להתחבר בצורה יעילה גם להתקנים לא מאוישים.
קימות דרישות אסינכרוניות לאיתותי כניסה שנראות כך :
סיגנל מתקבל ממערכת חיצונית דרך אפיק תקשורת כלשהוא , יישום מערכת הEmbedded צריך לייצר תגובה תוך משך זמן מסוים ( latency או בעברית שיהוי) . לרוב לא מספיק רק שהשיהוי הממוצע לתגובה הוא קצר , אלא חשוב שלא יחרוג מסטיה מקסימלית מסוימת (jitter) .
קימות גם דרישות סינכרוניות לאיתותי יציאה שנראים כך :
המערכת צריכה לעבד מידע וליזום כמה סיגנלים כל אחד בזמן אחר שיצאו אל מערכת לא מאויישת . ביישום שכזה נדרש שהעיבוד והסיגנל שמופק כתוצאה ממנו יופיעו במרווחים שווים ( Jitter נמוך) .
כשאפיון הזמנים הנדרשים לסיגנלים הנ”ל הם של מילישניות בודדות או פחות , מערכת הEmbedded חייבת להסתמך על מערכת הפעלה שיש לה את המנגנונים הדרושים שיבטיחו זאת , וכאן נכנסת מערכת ב RTOS לתמונה.
שתי התכונות של latency ו jitter נמוכים , מתומצתים במושג אחד – Determinism או ב”עברית” – דטרמיניסטיות .
חשוב לציין כי מערכת GPOS אינה יכולה להיות דטרמיניסטית ברמות של מילי שניות ומטה אפילו אם המעבדים שמריצים את המעבד הנם מהירים ביותר , כיוון שכשמתכננים GPOS נדרשות תכונות שקיומן סותר קיום מנגנונים אחרים שנדרשים עבור RTOS ומנגנוני GPOS אלה מעכבים את התגובות במשך זמן משתנה.
במילים אחרות : GPOS לא יכול להיות גם RTOS .
ומהכיוון השני – RTOS יכול תיאורטית לספק גם תכונות של GPOS אבל יכולות כאלה הן תמיד מוגבלות בגלל העלויות הגבוהות שדרושות לכך ש RTOS בשווקיו המצומצמים – יתחרה בכדאיות הפיתוח ל GPOS שיש לו מיליוני לקוחות. למשל – יצרני QNX או VX-works לא יצליחו לעולם להתחרות בעושר האפשרויות לניהול קבצים ו\או מסך שקימים ב Windows .
אז איך “מלבישים” שתי מערכות הפעלה שונות ביישום אחד ?
מכל מה שנאמר בקטע הקודם :
- GPOS אינו מספיק , וחלק משמעותי ממערכות הEmbedded צרכות גם פונקציונליות של RTOS .
- לא רצוי להשתמש ב RTOS בלבד כי אינו מספק פונקציונליות שאפשר לקבל מ GPOS
- הפתרון הינו שילוב של RTOS ו GPOS ביישום אחד
אז איך עושים את השילוב הזה ?
קיימות שלש שיטות “להלבשת” שתי מערכות ההפעלה עבור יישום אחד :
- שתי פלטפורמות שונות שמחוברות ביניהן.
מריצים GPOS על פלטפורמה אחת ו RTOS על פלטפורמה שניה. הפלטפורמה של ה RTOS יכולה להיות מחשב שלם נוסף , או כרטיס מחשב (או מיקרו מעבד) נוסף . מחברים את שתי הפלטפורמות בממשק כמו LAN . זוהי דרך שמייקרת ומסרבלת את הפיתרון ומגבילה את יכולותיו , אך עד לפני כמה שנים זו היתה הדרך היחידה לבצע את השילוב.
- פלטפורמה אחת עם Hypervisor שמעליו רצות GPOS ו RTOS .
יש שני סוגי hypervisor למשל VMware שמעליהם אפשר להריץ רק GPOS וברור שזה אינו פתרון . הסוג השני למשל ו eVM של TenAsys או LXwin של חברת Acontis .פתרונות אלה מוגדרים כ Real Time Hypervisor שמעליהם ניתן להריץ גם GPOS וגם RTOS והוא לכאורה פתרון לשילוב שתי מערכות ההפעלה במערכת Embedded אחת . ה Hypervisor הוא אמצעי שהתפתח במקור למטרה של הפרדה משיקולי עלות ובטיחות . הדרישות בבנית מערכת Embedded אחת הן הפוכות : במקום הפרדה נדרש שילוב: קצב גבוה של העברת נתונים וסנכרון בין שתי מערכות ההפעלה , סביבת פיתוח אחת שמשלבת את הפתרון לשתי מערכות ההפעלה , כלים במערכת הפעלה אחת שמשולבים במערכת השניה. דרישות אלה לשילוב במקום הפרדה , בנוסף לדרישה לשימור מלא של יכולות ה RTOS כש”מלבישים” אותו מעל Hypervisor ,לא נענות בשימוש ב Real Time Hypervisor , ולפיכך זה פתרון “בינוני” למטרה של בנית מערכת Embedded אחת .
- האפשרות השלישת המוצגת כאן כמועדפת היא פלטפורמה אחת שבה שתי מערכות ההפעלה Windows (שהינה GPOS ) וINtime ( שהינה RTOS ) רצות מעל אותה הפלטפורמה ללא שכבה חוצצת מתחתיהן. המשאבים של הפלטפורמה (ליבות ,זכרון ,פסיקות) , מחולקים בין שתי מערכות ההפעלה. האלמנט המשותף בין מערכות ההפעלה הוא שהתהליך שקורה בפסיקות ה Real Time Clock של הפלטפורמה מפעיל פונקציות בשתי מערכות ההפעלה. .לפתרון הזה לבנית מערכת Embedded יש את היתרונות הבאים :
- העלות נמוכה – רק חומרת PC אחת.
- סביבת פיתוח Visual Studio אחת לפיתוח שני חלקי המערכת .
- מגוון של ממשקים בין RTOS ל GPOS להעברת נתונים כולל ממשקים מהירים ביותר.
- מגוון אמצעים לסנכרן מספר רב של אירועים מצד ה GPOS ו\או מצד ה RTOS . (כמו למשל תהליך ב Windows מחכה ל Semaphore שיאותת מ INtime ) .
- כיוון שאין שכבה חוצצת מתחתיה – ביצועי ה RTOS מצוינים – עד פחות מ מיקרו שניה אחת של jitter .
- כלים ב Windows שנבנו במיוחד לתת שירותים בפיתוח , ב debug ובריצה למערכת INtime , כולל INscope profiler שנבנה על ידי TenAsys ו VTune שנבנה על ידי אינטל.
אנחנו נתרכז בשילוב המומלץ על ידינו – האופציה השלישית: שתי מערכות ההפעלה רצות על אותה פלטפורמה במשאבים מחולקים ע”י Explicit H/W partitioning ללא שכבה מתחתיהן.
באיור מספר 1 מומחשת הפרדת הליבות בין שתי מערכות ההפעלה . גם יתר המשאבים מחולקים בין שתי מערכות ההפעלה ישירות מעל החומרה , ללא שכבה מתחתיהן .
אופן ההפרדה
- לכל מערכת הפעלה מוקצה זכרון משלה (בדרך כלל ל INtime הרבה פחות זכרון מאשר ל Windows ) .
- ההתקנים החיצוניים מחולקים לפי המפתח : התקנים שהטיפול בהם דורש דטרמיניסטיות “מוקצים” ל INtime , והיתר ל Windows . מטבע הדברים התהליכים שמטפלים בהתקנים ש”הועברו” ל INtime צרכים גם הם לרוץ ב INtime (ההקצאה נעשיית על ידי כלי קינפוג ).
- גם תהליכי עיבוד ובקרה שאינם צמודים ישירות לסיגנל חיצוני , שצרכים להיות דטרמיניסטיים – גם הם צרכים להיות מטופלים על ידי INtime .
- קיים ממשק הודעות רציף ב low level בין שתי מערכות ההפעלה . מעל ממשק זה קימות אפשרויות רבות (ו API מתאימים ) להעברת מידע ולסינכרון בין קוד משתמש שרץ בשתי מערכות ההפעלה.
כך ניתן לבנות מערכת Embedded משני חלקים שהופרדו לפי מפתח הדטרמיניסטיות אך פועלים כמערכת אינטראקטיבית אחת , ומפותחים על ידי סביבת פיתוח אחת .
איור מספר 2 מראה את תהליכי התוכנה שרצים מעל שני ה”חלקים” .
איור מספר 2
לקחים מלקוחות ישראליים קיימים של INtime for Windows
במשך השנים האחרונות בנו מספר חברות ישראליות את קו המוצרים שלהם – כשמערכת ההפעלה INtime For Windows מהווה מרכיב חשוב במוצר .
חברת TenAsys שמתרכזת בפיתוח ובתמיכה לקו המוצרים ממשפחת INtime , הצליחה במשך אותן שנים , להוסיף יכולות פונקציונליות חדשות שמאפשרות לOEMs לשלב יכולות משופרות במוצריהן ובאופן הפיתוח שלהן. היכולות הבאות התפתחו במשך השנים וממשיכות להתפתח כל הזמן :
- התאמה לגירסאות המתעדכנות של ש Windows של 32 ו 64 ביט (כיום Windows 10 – ) ו Visual Studio (כיום VS 2019 ) .
- התאמה למעבדים החדשים ביותר של אינטל ו AMD .
- ריבוי ליבות : כשיצאה לשוק השתמשה INtime במעבדים בעלי ליבה אחת . עם התפתחות ריבוי הליבות , כל ליבה מריצה עותק מלא של מערכת ההפעלה , והיא מתקשרת ומסונכרנת לאחרות ולליבות Windows במגוון שיטת כולל חיבור virtual Lan Switch בין כולן .
- הגדלת הזכרון שניתן להקצות ל INtime עד לגיגה בייט רבים .
- אינטגרציה עם ספקי I/O מאפשרת מיגגון דרייברים.
- פיתוח פרוטוקולים מהירים מעל Ethernet כולל Time Sensitive Networks .
- עבודה בקבוצות גדולות בשימוש ברשיון צף .
ועוד .
כל התכונות שצוינו , תורמות ליישומי הלקוחות – ומאפשרות למוצריהם להיות תחרותיים יותר .
בתחילת המאמר הוסבר שהפתרון המועדף למערכות Embedded – הוא בשילוב של RTOS עם GPOS . הראינו שמבין שלשת השיטות הקיימות – INtime for Windows מספקת את הפתרון היעיל ביותר לפיתוח הדרישה המורכבת הזו.
שלשת הלקוחות שיוצגו להלן נעזרים בכל היתרונות שתוארו , אבל חילקו בצורה שונה את מערכת הEmbedded שלהם בין INtime ל Windows .
אופן החלוקה בין שני חלקי היישום לריצה על שתי מערכות ההפעלה
בתחילת הליך ה”חלוקה” הלקוחות היו צרכים לענות על שתי השאלות הבאות:
- איזה מהממשקים להקצות ל INtime ואיזה להקצות ל Windows . המשמעות היא לא רק לכך שדרוש דרייבר מתאים להתקן במערכת ההפעלה שנבחרה , אלא גם התהליך שמטפל בהתקן יהיה באותה מערכת ההפעלה שנבחרה עבורו.
- גם ללא טיפול באינפורמציה גולמית שמגיעה מבחוץ וגם כאשר נדרש עיבוד מורכב – נשאלת תמיד השאלה האם לעשות אותו ב INtime או ב Windows . חשוב גם לציין שככל שנדרש עיבוד רב יותר (למשל עיבוד תמונה או מידע RF ברזולוציה גבוהה יותר) יש להקצות יותר ליבות למערכת ההפעלה שמבצעת את העיבוד.
התשובות לשאלות הנ”ל הם שונות בין שלשת הלקוחות שיוצגו , ובעקבות זה גובש אופי פיתוח שונה. מזה למעלה מ 8 שנים מצליחות החברות לשמר סביבת פיתוח סימולציה ובדיקות יעילות ביותר.
כללנו להלן את המענה של כל אחד מהלקוחות לשאלות הרלוונטיות הזהות .
- מערכת תעשיתית ברצפת ייצור
המשימות העיקריות : עיבוד ובקרה מאד משתנים ומגוונים. במשך השנים – המיגוון וההתפתחות של המשימות חייבו מספר תכנתים גבוה .
איזה מהממשקים להקצות ל INtime : רק הממשקים לרובוטים ולתקשורות הפנים מערכתיות מטופלים על ידי INtime .
איך בזמן הפיתוח ניתן לדבג את העיבוד : קבוצה קטנה מפתחת שני מוצרים : קוד INtime לסימולטור , וקוד INtime למוצר הסופי . לכל תכנת יש PC שבו הוא יכול להריץ את התוכנה שמפתח מול סימולטור בזמן אמת , ופעם אחרת מול החומרה הסופית בגישה מרחוק ובאופן מתוזמן (החומרה יקרה ותופסת שטח גדול ) .
העיבוד ב INtime או ב Windows : כל העיבוד מבוצע ב Windows .
איך ניתן בזמן הפיתוח לדבג את העיבוד : כל העיבוד משתמש בספריות מתמטיות שפותחו עבור windows ומדובג כאמור על Windows .
המיוחד בקונפיגורצית הפיתוח של לקוח מספר 1 : כיוון שהעיבוד מתבצע ב Windows ועיקר השינויים הם בחישובים ולא ב I/O , הרי שהסימולטור שנבנה מעל INtime מקל על פיתוח הקוד ב Windows ,ומאפשר לו להיבדק באותם תנאי זמן אמת של המוצר הסופי תוך כדי שימוש ב PC זול ללא I/O יקר .זה מביא ליעילות פיתוח ולהוזלה משמעותית של עמדת הפיתוח .
- מערכת עיבוד אות צבאית
המשימות העיקריות : ממשקי proprietary רבים לחומרה שדוגמת RF . העיבוד והבקרה כמעט קבועים ומאפשרים שימוש בקבוצת תכנתים קטנה.
איזה מהממשקים להקצות ל INtime : כל הממשקים לתקשורת פנים מערכתית ולרכיבים (FPGA ) מוקצים ל INtime .משתמשים ב Windows לאיסוף מידע מהחומרה לניתוח , וגם לגישה מרחוק.
איך בזמן הפיתוח ניתן לדבג את ה I/O : כל ה I/O מדובג בעזרת כלי הפיתוח שמגיעים עם INtime .
העיבוד ב INtime או ב Windows : כל העיבוד של ה image processing מבוצע ב INtime באמצעות ספריה מתמטית של אינטל.
איך ניתן בזמן הפיתוח לדבג את העיבוד: עם כלי הפיתוח שמגיעים עם INtime.
המיוחד בקונפיגורצית הפיתוח של לקוח מספר 2 טמון באופן שילוב בין Windows ל INtime . האלגוריתמים מוכרים ומדובגים אבל התנאים שבהם המוצר נדרש לתפקד מורכבים מאד ומשתנים. לפיכך השימוש ב Windows הוא בעיקר לקבל ולאחסן נתונים בכמויות עצומת בזמן אמת . האיסוף נעשה על ידי INtime וניהול האחסון והשליפה על ידי Windows .
איסוף וניתוח כמות עצומה של נתונים בניסויי שדה מאפשרת לשפר את המערכת בהתמדה ולבדוק אותה בהסתמך על נתוני אמת.
- מערכת שליטה בכלי נשק
המשימות העיקריות : בעיקר בקרה ולוגיקה , עיבוד מועט ו I/O דרך Ethernet . הפיתוח נעשה על ידי קבוצת תכנתים בינונית בגודלה.
איזה מהממשקים להקצות ל INtime : כל הממשקים במוצר הסופי הם דרך INtime
איך בזמן הפיתוח ניתן לדבג את ה I/O : כל התוכנה מפותחת ב API שהינו Iwin32 שיכול לרוץ גם מעל INtime וגם מעל Windows . כל מודול תוכנה , כולל זה שמטפל ב I/O (בהורדת קצב) מדובג ב Windows . המודול “הופך” לקוד INtime על compile-switch ומרגע זה משולב בכל הקוד האחר שכבר בנוי מעל Intime .
העיבוד ב INtime או ב Windows: העיבוד מועט , יש בעיקר לוגיקה ובק
איור מספר 3
רה . בפיתוח הכל מדובג ב Windows ובאינטגרציה ובמוצר הסופי הכל מבוצע על ידי INtime . . במוצר הסופי Windows רק משמש לאיסוף log לבדיקת התוכנה בריצה. אינפורמציה זו מועברת למפתחים במקרים של תקלות.
איך ניתן בזמן הפיתוח לדבג את העיבוד : כל מודול שכולל עיבוד, מדובג ב Windows הקוד “הופך” לקוד INtime על ידי compile-switch ומשתלב באינטגרציה מעל Intime .
המיוחד בקונפיגורצית הפיתוח של לקוח מספר 3 הוא המעבר החלק בין מוצר שכולו Windows שאינו מספק דטרמיניסטיות , למוצר שכמעט כולו מבוסס על INtime שמספק דטרמיניסטיות. צורת פיתוח זו מאפשרת להשתמש במאגר תכנתי Windows (עובדים וקבלני משנה) , וכלי פיתוח זמינים ב Windows להגיע לתוצאות בזמן פיתוח קצר.
לסיכום
חלק משמעותי ממערכות Embedded דורש שילוב של GPOS ו RTOS וקימות כמה שיטות לשילוב כזה. מערכת INtime for Windows הוצגה כאן . קיימת עוד גירסא שיכולה להריץ את אותו קובץ בינרי והיא קרויה INtime Distributed RTOS .
באיור מספר 3 מוצגת מערכת זו לצידה של מערכת מבוססת INtime For Windows . את השירותים מ Windows (אם נדרשים) היא מקבלת דרך ה LAN ולא פנימית מליבה אחרת כפי שנעשה ב INtime For Windows .שתי גירסאות אלה של מערכת ההפעלה INtime מספקות את הפתרון הטוב ביותר מכמה בחינות הקשורות לפונקציונליות של הפתרון אבל בעיקר ביכולת הפיתוח הנוחה מאד.
הראינו את פרטי המוצרים ובמיוחד את אופן הפיתוח שכל אחד משלושת הOEMs התאים לעצמו .
אפשר ליישם רעיונות אלה של שילוב ופיתוח במוצרים אזרחיים וצבאיים רבים אחרים .
על המחבר:
אסף גליל הינו מהנדס יישומים של
אסף גליל
חברת TenAsys והחברה שבבעלותו היא נציגת TenAsys בארץ. לאסף למעלה משלושים שנות ניסיון בפיתוח , שיווק וסיוע טכני למוצרים בשוק ה Embedded .
ניתן לקבל מידע בהתקשרות ל assaf@integral-ae.com
