תאר לעצמך מצב בו אתה מהנדס שנדרש לתכנן מזל”ט. אתה בוחר ומרכיב את החלקים יוצר את התוכנה ומתחיל סדרת בדיקות לפני המסירה ללקוח.
כדי לדמות את צורת ההפעלה של הלקוח, אתה מוסר את המזל”ט ומערכת המפעיל לאדם מטעמך, והוא מנסה את המזל”ט במצבי תעופה שונים.
עד לפני מספר שנים זה היה אופי הבדיקות לגבי מזל”טים ומוצרים דומים, אבל בהדרגה התגבשה ההכרה בחסרונות צורת הבדיקה הזו. בפשטות – בשיטה הקיימת נשארה תמיד רמה של חוסר ביטחון האם אותרו ונבדקו כל המצבים שבהם יופעל המכשיר.
המפתחים והלקוחות דרשו שיטת בדיקה בגמר פיתוח שתענה על הדרישות הבאות (נתיחס כדוגמא לפיתוח מזל”ט):
בדיקת התנהגות בתנאי סביבה קיצוניים שעשויים להשפיע על ניהוג המזל”ט: גשם טמפרטורה ורוח ברמות שונות.
בדיקת ההתאוששות של המזל”ט ממצבי תקלה שקורים תוך כדי טיסה.
הגדלת יעילות הבדיקות – הקטנת יחס הזמן שמוקדש לבדיקות לעומת כמות המצבים האמיתיים הנבדקים.
מענה על הדרישות הנ”ל בניסויי שדה של מזל”ט או ציוד דומה מחייבת אמצעים רבים: ציוד מדידה, מצלמות, צוות בודקים גדול וכו’. הבדיקה לוקחת זמן משמעותי ומשאבים כספיים. לעיתים לא ניתן לספק בניסויי שדה את כל המצבים הקיצוניים, וכך, גם אחרי ההשקעה הגדולה נשארת רמה מסוימת של אי ודאות.
ב”לחץ” הדרישות “נולדה” שיטה חדשה ושמה Hardware In The Loop – HIL. במקום שהמזל”ט (לדוגמא) יטוס באויר החופשי – הוא “יטוס” במעבדה. ניתן לראות את זה באיור מספר 1. מערכת הבקרה של המוצר המפותח (הריבוע האפור) פועלת במהלך הבדיקות עם ה-I/O הרגיל שלה: היא מבצעת output למערכת הניהוג שמשפיע על המנוע והכנפונים ובנוסף היא קוראת (מבצעת input) את התנהגותה במרחב באמצעות GPS
ו\או מודד אינרציאלי. את מצב הכנפונים ניתן לקרוא באמצעות Encoders שמופעלים על ידי היחידה במלבן הכחול שבשרטוט מספר 1, וגם ה-GPS ו\או התזוזות של גוף המזלט בפועל – מתקבלים ממלבן הכחול – מערכת HIL.
כלומר – המכשיר הנבדק (למשל המזל”ט) מתנהג בחדר הבדיקות כפי שהיה מתנהג “באויר החופשי”. חלק מרכזי שנדרש כאן הוא יחידת חישוב שפועלת בזמן אמת ופועלת ב-latency (עיכוב) ו-jitter (ערך מקסימלי לסטיות מהעיכוב) נמוכים. למשל המידע על זוית הכנפונים מוזן לאלגוריתם הסימולציה – שמוציא ללא דיחוי את המידע החדש על מיקום המזל”ט בכל הצירים.
בנית מערכת HIL
בהסתכלות על איור מספר 1 ניתן להבחין בין שתי יחידות: המלבן הרחב מבצע אלגוריתמים בזמן אמת, וגם כוללת פונקציות I/O שפועלות בזמן אמת (latency ו-jitter נמוכים). הריבוע הכחול השני כולל את ממשק המפעיל: הכנסת פרמטרים לבדיקה, ומצד שני קבלת המידע מהבדיקות, לרוב גם בצורה גרפית.
Windows הוא בדרך כלל הבחירה המועדפת ל-Operator Interface. מערכת הפעלה זו נפוצה ומוכרת וקיים עושר בלתי נדלה של אמצעים לייצור ממשק מפעיל GUI – עשיר, אמין ומוכר.
למרכיב המלבן הכחול של מערכת HIL ניתן לבחור מתוך רשימה של מספר מערכות הפעלה, אולם כאן נתאר פתרון שבו גם המלבן הרחב וגם הריבוע שלידו ממומשים על אותו PC – זוהי מערכת ההפעלה לזמן אמת INtime תוצרת חברת TenAsys. מערכת הפעלה זו פועלת על אותו ה-PC שבו רץ גם מרכיב Windows של היישום.
לאחר שבחרנו במערכת ההפעלה לזמן אמת ניגש לבחור את אופן הפעלת ה-I/O שלה. קיימים יצרנים רבים שמציעים ממשקי I/O לפרוטוקולים שונים. בוחרים כרטיס PCI שמבצע קריאת Analog Input (למשל), בוחרים כרטיס אחר שמבצע High Speed Serial Output (למשל), מחפשים עבור שניהם Drivers או מפתחים את ה-Driver, וכך משלימים את כל הממשקים הדרושים. מאידך יתואר במאמר אופן מימוש נח הרבה יותר של כל (או רוב) ממשקי ה-I/O על ידי יצרן אחד – חברת UEI שמציעה יחידה חיצונית מוקשחת שמכילה את ממשקי ה-I/O הדרושים. מערכת ה-I/O הזו הקרויה PowerDNA ומתוארת באיור מספר 2.
כרטיס ביקור קצר של TENASYS ו-UEI
חברת TenAsys האמריקאית מתמחה במערכות הפעלה לזמן אמת מעל פלטפורמות שהמעבד שלהן הוא ממשפחת X86. מערכת ההפעלה INtime הינה פיתוח המשך של מערכת הפעלה לזמן אמת RMX של אינטל בשילובים עם Windows לפיתוח וריצה. מערכות הפעלה אלו שימשו ומשמשות אלפי ישומים בטלקומוניקציה, ציוד רפואי, רובוטיקה, מערכות צבאיות ובהקשר של המאמר הזה – מערכות בדיקה, סימולציה
ו-HIL.
חברת UEI האמריקאית הינה חברה מובילה בעיבוד נתונים של Acquisition Logging recording ועוד. הפיתוח המהפכני שלה הוא יחידה הקרויה PowerDNA שהינה יחידה קומפקטית ומוקשחת שמצידה האחד מחוברת בממשק GigaBit Ethernet למחשב, ולתוכה נתקעים כרטיסונים מהרכב של כ-50 סוגי כרטיסים שמממשים פרוטוקולי ממשק ותקשורת מגוונים.
תרומתה של INtime למימוש מערכת HIL
רוב לקוחות HIL שמשתמשים ב-INtime מקצים לה ליבה אחת או יותר, ויתר הליבות מריצות Windows. במערכות HIL נדרשות מ-Windows מטלות של ממשק מפעיל, שבדרך כלל אינן דורשות כח עיבוד רב. עיקר הביצועים נדרשים בביצוע אלגוריתמים מורכבים של סימולציה. גוף כמו מזל”ט מתואר בשלושה רכיבי מקום בקוורדנטית קרטזיות ובשלושה רכיבי מהירות שאינם תלויים זה בזה. סימולציה כזו מכונה – “שש דרגות חופש” והיא בנויה ממשוואות מתמטיות שמחזור התוכנה שמממש אותה חייב להסתיים באופן קבוע בזמני מחזור קצרים. באותם זמני מחזור קצרים חייבים כל הממשקים מ-ואל הבקר הנבדק להעביר את האינפורמציה הדרושה. בתוך הפעולות הללו ניתן להבחין בקטעים שניתן לבצע במקביל – ולהקצות להם ליבות שונות. מספר הליבות שיוקצה ל-Windows ול-INtime תלוי בדרישות הנ”ל וביכולת המקביליות של האלגוריתמים ופעולות ה-I/O. קימת גם אפשרות להקצות את כל הליבות במחשב לזמן אמת ל-INtime ולבצע בפועל את ממשק המפעיל על מחשב Windows חיצוני שמריץ התקנה של INtime Host. פרוטוקול ייחודי שבנוי מעל UDP מתקשר עם מחשב המפעיל. פרט לתוספת ביצועים במחשב לזמן אמת, מימוש כזה מאפשר גם ריחוק מערכת המפעיל מסביבת ה-I/O. בשונה מחיבור PC ב-Remote Access – ניתן בשיטה זו לבנות מערכת מפעיל שכוללת תוכנה נוספת מעל Windows שרצה על מחשב המפעיל, ושרצוי שלא תרוץ על מרכיב ה-Windows של מערכת ה-HIL.
ההחלטות על הקונפיגורציה הסופית שתבחר יכולות להדחות, ואינן צרכות להשפיע על פיתוח התכנה. השינויים נעשים בפרמטר שניתן לקבוע כשמאזן העומסים והמקביליות ברור יותר. בזמן זה מפצלים את המערכת ללא שינוי בתכנה.
השימוש ב-INtime והשילובים עם Windows בבנית מערכות HIL מספק לבונה המערכת כמה יתרונות ברורים:
במרכיב ממשק המפעיל –
Windows מאפשרת GUI מתקדם, וגרפיקה משוכללת. מאד נוח לפתח ולהריץ את הקוד המפותח על אותה פלטפורמה.
בזמן הפיתוח הראשוני –
מנתחים את המקביליות של האלגוריתם ומודדים על מעבד נתון את הביצוע של האלגוריתם וההפניות ל-I/O. חישוב זה מהווה בסיס אמין לבחירת המעבד, ולעיתים נוכחים שניתן להשתמש במעבד “חלש” יותר. החלטה כזו היא אמינה כיוון שבמעבדים של היום שמריצים INtime ה-jitter של הפלטפורמה הוא פחות ממיקרו שניה כך שהסטיות בזמני ביצוע בין ניסויים הן קטנות. יכולות אלו מאפשרות בקלות התאמה למספר ליבות שונה, ואפילו לשימוש בקונפיגורציה במרכיב הזמן אמת – ללא Windows.
בפיתוח מרכיב Windows ו-INtime –
המתכנת משתמש באותה סביבת עבודה של Visual Studio (כולל הגירסא החדשה VS 2013). בצד מרכיב ה-Real Time ניתן להשתמש ב-C או C++. בצד מרכיב המפעיל – ניתן גם להשתמש ב-C#. מסופק Wrapper שמאפשר לקוד בסביבת DOTNET לפנות ישירות לאובייקטים שמוגדרים ופעילים בצד INtime. ראה איור 3 לתיאור סביבת הפיתוח.
מהירות התקשורת בין Windows
ל-INtime –
הממשק נמצא משני צידי החץ ביחידה השמאלית שבאיור מספר 1.
עבור מהירות של מאות Megabytes/Secבוחרים בזכרון משותף, עבור מהירויות נמוכות יותר בוחרים ב-Virtual LAN.
Quick Start –
ישנה כמות גדולה של דוגמאות קוד וקורס קצר לצורך התחלה מהירה (Quick Start) שמצורפים למוצר INtime. בנוסף זמין באמזון – בגירסא אלקטרונית – ספר מורחב להדרכה ותרגול ששמוReal Time Programming , from Theory to Practice.
Jitter –
בתוכנת ההתקנה של INtime נמצא כלי לבחינת הפרמטרים שמוגדרים עבור הפלטפורמה שיכולים להיות להם השפעות שליליות על עמידה בדרישות זמן אמת. בנוסף – נמצא כלי שמודד בפועל את הדטרמיניסטיות (Jitter) של הפלטפורמה. שינוי הפרמטרים במערכת לפי ההמלצות שמתקבלות עשוי לשפר את הדטרמיניסטיות בצורה משמעותית.
כלי Debug שונים –
בנוסף ל-debug באמצעות Visual Studio מסופקים כלי Debug שונים: Spider
ו-SDM שעונים לדרישות Debug בהם VS אינו מספיק. בנוסף מסופק Profiler ששמו INscope שמציג בצורה גרפית זמנים שונים: זמן של כל Thread, זמן של כל קריאה לשרותי INtime או לפונקצית C ואפילו זמן מדויק של ביצוע שורות קוד מסוימות בתוכנת המערכת. זהו כלי הכרחי בבדיקת מענה נכון לדרישות תזמון.
IP Stack –
כפי שהוזכר לעיל, החיבור בתוך מערכת HIL בין המערכת לזמן אמת (INtime) ותוכנת המפעיל שרצה על Windows יכול להיות ממומש ב-shared memory או Virtual LAN (נקבע בתלות בקצב העברת הנתונים). במערכת שה I/O שלה מסופק על ידי PowerDNA של UEI – ההתחברות היא ב Physical LAN במהירות של 1 Giga Bit per second. נקודת הצומת הזו מאד חשובה לסה”כ הביצועים. INtime משתמש
ב-freebsd IP Stack. זהו Stack מאד יציב, בעל פונקציונליות רבה מאד, והוא מקנה לכל התקן שמחובר באמצעות LAN ל-INtime את היתרונות הבאים: אמינות, ביצועי Real Time מצויינים, תאימות למגוון עצום של כרטיסי רשת, יכולת הגדרות פרמטרים נוחה, ומיגוון קונפיגורציות כמו הפעלת כמה יחידות PowerDNA שמחוברות לכרטיס LAN מרובה פורטים: כל ליבה מריצה תוכנה התומכת ביחידת PowerDNA שונה. (ראה איור 6).
תרומת ה-PowerDNA למימוש מערכת ה-HIL
ברור שניתן לחבר את המחשב שמריץ INtime באמצעות מיגוון של כרטיסי PCI למערכת הבקרה של הציוד הנבדק (המזל”ט לדוגמא). אנחנו נתאר דרך מומלצת יותר באמצעות ה-PowerDNA.
באיור מספר 4 רואים את היחידה הראשית. יחידה זו בנויה על כרטיס אם שמריץ מערכת הפעלה קטנה ו”זריזה” לזמן אמת שמצד אחד פונה לכרטיסים הנתקעים, ומצד שני ל-Host PC באמצעות Phisical LAN שמהירותו 1 Giga Bit Per SEcond.
כל כרטיס נתקע שמממש פרוטוקול מסוים – יוצא באמצעות D-Type Connector לכבלים החיצוניים (מסופקים גם אמצעי כבילה שונים).
קימים סוגי כרטיסים רבים:
• Analog Input,
• Analog Output
• Digital I/O
• Communications: Avionics :MIL-1553, ARINC-429, ARINC-708
• Serial: RS-232, RS-422/485 (baud rates up to 4 Mb)
• CAN-Bus
• WIFI and GSM for the UEIPAC
• Counters and Timers
• Frequency generation and measurement
• PWM input and output
• Quadrature encoder inputs
• Power Conversion
התקשורת בין ה-PowerDNA והמחשב שמריץ INtime מבוצעת בפרוטוקולים שונים שנבנו מעל פרוטוקול UDP. בצד ה-Host – כל הממשקים של ה-PowerDNA נראים כמעט אותו דבר: העברת מידע לזכרון
ב-Host וממנו. ההבדלים בין הפרוטוקולים הינם משמעותיים בצד שמטופל על ידי UEI ואילו ב-Host כותבים תוכנה לשני מצבים:
בתחילת התוכנית – מגדירים את אפיק התקשורת: איזה סוג תקשורת זה לעולם החיצוני, איזה פרוטוקול תקשורת בין ה-PC
ל-PowerDNA, לאיזה כרטיס פיזי מתחברים, מה זמן מחזור הפניה ל-PowerDNA וכו’.
בצורה מחזורית מבצעים – קריאת מידע שמגיע, וכתיבת מידע אחר.
קיימים מספר פרוטוקולים שהוגדרו כאמור מעל UDP – בהתקשרות בין ה-PoerDNA
ל-Host:
Immediate I/O
RTDMap –
RTVMap –
Asynchronous
DqEngine + ACB
DqEngine + Dmap
DqEngine + Messaging
הדיון המפורט במאפייני הפרוטוקולים השונים חורג ממסגרת מאמר זה ומפורט בהרחבה במסמך המצורף לתוכנה שמגיעה מ-UEI.
שניים מהפרוטוקולים שהשימוש ביניהם נפוץ יותר, מתוארים באיור מספר 5.
האחד קרוי DMAP שמעביר Buffers בגודל קבוע אל ומ-ה-PowerDNA. הפרוטוקול שימושי בהעברת מידע כמו
Analog Input/Output ומידע אחר שהינו קבוע לאורך זמן.
הפרוטוקול השני קרוי VMAP שמעביר Buffers בגודל משתנה. הפרוטוקול שימושי בהתקשרות לכרטיסי תקשורת – Async
ו-Sync מסוגים שונים.
למרות השוני של כל פרוטוקול בטיפול באינפורמציה מול ההתקנים החיצוניים, קיים דמיון רב בפעולות הנדרשות בצד ה-Host.
ניתן לסכם את היתרונות בשימוש בצורה זו של מימוש I/O ברשימה הבאה:
UEI מספקת מיגוון עשיר ביותר של ממשקים וגם אם במהלך הפרויקט נוספות דרישות להתחברות לציוד שונה נוסף – קרוב לוודאי שימצא ב-UEI פתרון חומרה , ותוכנה כמעט זהה לזו שכבר בשימוש.
אם היינו בוחרים שימוש בכרטיסי PCI נפרדים לכל פרוטוקול, ה-PC היה צריך להיות בעל חריצי הרחבה (Slots) רבים. קיימת דרישה נוספת שלא יהיה אף Interrupt שמשותף ל-INtime ו-Windows – וזה מוסיף קושי לבחירת PC וגם מייקר אותו. בעבודה עם PowerDNA הדרישה מצומצמת למדי – נדרש רק Ethernet פורט אחד. כל PC סטנדרטי מסופק עם ממשק כזה.
כתיבת תוכנה בצד ה-Host עבור PowerDNA פשוטה מאד. ישנן תוכניות דוגמא לכל ממשק, והן דומות למדי ביניהן. באלטרנטיבה של עבודה עם כרטיסים מיצרנים שונים – לכל פרוטוקול יש הבדל גדול בכתיבת קוד מעל ה-drivers, ולעיתים ה-driver לא קיים כלל ונדרש לכתוב אותו.
הכרטיסים שנתקעים ב-PowerDNA
וה-Drivers בתוך היחידה נמצאים בשימוש במגוון מוצרים נוסף של UEI פרט לזה שמתחבר ל-Host. החברה מציעה את החומרה והתוכנה שלה עם 10 שנות התחייבות לתמיכה אחרי הכרזת End Of Life. האלטרנטיבה באמצעות כרטיסים נפרדים לכל פרוטוקול מספקת הרבה פחות אחריות לתמיכה בעתיד, ועלולה להשאיר את מנהלי פרויקט עם בעיות קשות זמן לא רב אחרי תום הפרוייקט.
יחידת ה-PowerDNA הינה מוקשחת. לעיתים אותו ציוד HIL או יישום דומה – חייבים לעבור ניסוי בתנאי שדה – או ניסויי טיסה. PowerDNA מונע את הצורך לתכנן את המערכת מחדש עבור פיתרון מוקשח.
בחיבור INtime ל-PowerDNA יש למתכנן אפשרויות הרחבה רבות, בשלשה מישורים בלתי תלויים. באיור מספר 6 רואים חלק מהקונפיגורציות האפשריות:
בחירת Chassis עם מספר slots רב יותר – עד 12 slots.
בריבוי ליבות ניתן להריץ INtime מחובר לכמה physical ports – כל ליבה מריצה את ה-stack שלה, את UEI Drivers שלה, על הפורט הפרטי שלה.
ניתן להפעיל כמה יחידות שמריצות INtime ללא Windows – שכל אחד פועלת מול יחידת PowerDNA אחרת. ה-PC שמריץ Windows מחובר ברשת ופועל בפרוטוקול של TenAsys (שגם הוא בנוי מעל UDP).
סיכום
שני היצרנים TenAsys ו-UEI מצטיינים כל אחד בתחומו. אבל כשמחברים את מוצריהם ביישומי HIL מתברר שתכונות “טבעיות” שלהן מקבלות עוד דחיפה לכיוון של יתרונות רבים נוספים ביחס לאלטרנטיבות.
במהלך עריכת הכתבה ערכנו שיחות עם מספר יצרנים ישראליים שכיום בונים את מערכות ה-HIL שלהם עם INtime
ו-PowerDNA. מהנדסים אלה עבדו בעבר גם עם מערכות הפעלה אחרות וגם עם יצרני יחידות I/O אחרים וכולם הצביעו על השילוב בין המוצרים הנ”ל כמוצלח ביותר גם מבחינה אבסולוטית (זמן פיתוח ועלות ביחס לציפיות) וגם בצורה יחסית לעומת אלטרנטיבות אחרות.
לאור הניסיון החיובי ביותר שלהם הם מסרו לנו שגם בפיתוח גירסאות המשך הם ידבקו בשילוב זה.
חשוב לציין ששילוב כמו שהוצג עבור יישומי HIL יכול להתאים גם ליישומים אחרים.
על המחברים
ארז רם הינו מנהל תחום נציגויות בחברת פורמטסט המייצגת בין השאר את חברת UEI. לארז יש ניסיון של למעלה מ-20 שנה בשוק ההיי-טק בארץ ובחו״ל.
אסף גליל הינו מהנדס יישומים של חברת TenAsys והחברה שבבעלותו היא נציגת TenAsys בארץ. לאסף למעלה משלושים שנות ניסיון בשוק ה-Embedded.
- איור 1. מרכיבי מערכת HIL
- איור 2. מימוש מערכת HIL בשילוב Windows INtime ו-PowerDNA
- איור 3. סביבת פיתוח של מרכיבי INtime ו-Windows בבנית מערכת משולבת
- איור 4. דוגמא ליחידת PowerDNA בת 6 slotsוכרטיס תקשורת סינכרונית (לדוגמא) שנתקע ב-PowerDNA
- איור 5. DMAP ו-VMAP
- איור 6. חלק מהקונפיגורציות האפשריות בחיבור-INtime ו-Windows עם PowerDNA