עלויות וסיכונים בפיתוח מערכות Embedded

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

רקע

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

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

על מה משליכה בחירת ארכיטקטורת התוכנה

בדרך כלל בנוסף למוצר ה-Embedded ה”ראשי” מפותחים מוצרים שונים. לעיתים זה מוצר עזר להקלת הפיתוח, ולעיתים גירסאות שונות של אותו מוצר שיש להן תכונות מעט שונות. חשוב לבחור בארכיטקטורה שמאפשרת בנית “המוצרים הנלוים” בשימוש בהשקעה ב-code base של המוצר העיקרי.

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

המאמר יתייחס לארכיטקטורה לבנית מערכות Embedded שעונה על האתגרים שהוצגו.

הקשר למערכות הפעלה זמן אמת

רוב מוצרי ה-Embedded המורכבים דורשים את אחת או יותר משלוש התכונות הבאות:

1. דטרמיניסטיות – חסם נמוך לתגובה בזמן של המערכת לסיגנלים חיצוניים ו\או הספקת סיגנלים מדויקים ללא סטיה.
2. רובוסטיות – כיון שלרוב הן אינן מאוישות המערכת צריכה להתאושש בצורה השקופה ביותר במינימום הפרעה לרצף הפעולה של המערכת – מכל בעית חומרה (ניתן לתכנן ולבצע ירידה בפונקציונליות כתגובה לבעית חומרה) או תוכנה (ניתן לתכנן זיהו של חריגה עקב bug, ולאתחל את חלק התוכנה המינימלי ה”פגוע” – thread או process – כדי להתאושש).
3. ניצול מקסימלי של כושר העיבוד- כיון שלרוב מערכות ה-Embedded אינן יכולות להשתמש במעבדים החזקים ביותר בגלל שיקולי הספק ו\או מחיר – אסור ל”בזבז” CPU cycles ללא צורך.

התשתית להשגת כל שלושת התכונות הנ”ל מסופקות על ידי מערכת הפעלה שתוכננה מלכתחילה לזמן אמת.

כשמתכנן ניגש לכתוב תוכנה לרובוט ישנה דרישה אולטימטיבית לתגובה בזמן בדיוק של מיקרושניות. במקרה זה ברור מאליו שנדרשת מע”ה לזמן אמת

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

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

התכונות הבאות משותפות לכל הפתרונות שיוצגו:

1. המעבדים הם ממשפחת X86 של אינטל כולל החדישים ביותר.
2. הפתרון מופרד למרכיב לזמן אמת שקרוי INtime ולמרכיב שאיננו לזמן אמת שהינו Windows (מכל גירסא של 32 או 64 ביט).
3. הפתרון – גם במרכיב Windows וגם במרכיב INtime מתעדכן לתמוך בארכיטקטורות PC (או דמוית PC) החדישות ביותר – ללא צורך ב-BSP .
4. סביבת הפיתוח היא של Visual Studio מכל סוג עד ל VS 2017 (נכון לרגע זה).
5. קידוד החלקים במרכיב זמן אמת נעשה ב C ו/או C++ (כולל גירסת 11 של C++).

INtime היא מערכת הפעלה מלאה וותיקה לזמן אמת. מערכת זו מתבססת על Intellectual Property מוכח באלפי מוצרים שסופקו ללקוחות בעולם וגם בארץ – של חברת אינטל. מע”ה זו מספקת את שלושת התכונות הנדרשות שצוינו לעיל: דטרמיניסטיות, רובוסטיות וניצול מקסימלי של CPU cycles. היא יכולה “לאייש” את כל הליבות, או חלק מהליבות כשהאחרות מוקצות ל-Windows. את התוכנה מקודדים ב-C או C++. כל הפיתוח וה-debug נעשים באמצעות Visual Studio בין אם ה-Target יכלול Windows או לא. בנוסף מסופקים כמה כלים יעודיים מיוחדים כמו Real Time Profiler. מערכת ההפעלה בנויה להשתמש בכלים חשובים של אינטל: IPP שהינה ספריה לפונקציות של multimedia and data processing, וגם VTune – כלי ל-Software Performance Analysis. במקרה של ריבוי ליבות כל ליבה מכילה עותק מלא של מערכת ההפעלה כולל מנגנוני ניהול המשאבים: פסיקות, וזכרון. תכונה זו מאפשרת שליטה מלאה של התכנת בהקצאת המשאבים, ובכך משפרת את הדטרמיניסטיות ואת הניצולת של ה-CPU Cycles שניתן להפיק.

התקשורת בין Windows לבין הליבות המריצות INtime – בין אם זה על אותו מעבד או מעל LAN לכיוון מערכת רחוקה נעשים על ידי שכבה הקרויה NTX – NT (Windows) Extension Library. לשימוש בפקודות של מערכת ההפעלה גם בתוך כל ליבה וגם בממשק מול Windows ניתן להשתמש ב-API שהינו Subset של Win32 – הקרוי iWin32. תכונה זו מאפשרת לקחת קוד שנכתב עבור Windows גם אם כולל שרותים של Windows ולהעביר אותו ללא שינוי או במעט שינויים למערכת ההפעלה וליצור באמצעות כלי הפיתוח, יישום לשימושה של מערכת ההפעלה שיקבל יכולות של זמן אמת על ידי שימוש נכון בפרמטרים של המערכת לזמן אמת מתחתיו.

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

בחירת השילוב המתאים ל-Target שבנוי מ-PC אחד

איור מספר 2 מתאר את ארבעת הקונפיגורציות האפשריות לבנות מערכת בשימוש באותו code Base.

במערכת הבנויה מע PC אחד, ניתן להשתמש ב-INtime Only או בשילוב של INtime ו-Windows.

שתי הקונפיגורציות הללו מופיעות כ-1 ו-2 באיור. ב-3 ו-4 מתוארת האפשרות לבנות מערכת מבוזרת.

מתי נשתמש בקונפיגורציה 1 ומתי ב-2 עבור ה-Target

טבלה 1. מדגישה את ההבדלים בין הקונפיגורציות.

הימצאות של Windows בפתרון 2 מאפשרת מגוון שרותים למשל GUI מתקדם, או File System משוכלל. בנוסף יש אפשרת להשתמש בישומים קימים – בצורת ה EXE שלהם. אם יש צורך ביכולות כאלה הרי קונפיגורציה זו מצוינת לקבלת יישומים ופתרונות עשירים ומגוונים בעלות נמוכה.

אם אין דרישה ליכולות אלו וניתן להסתפק ב-Text Only Human Interface ו-FAT32 file system מומלץ להשתמש בקונפיגוציה של INtime Only (מספר 1 בטבלה) .

בקונפיגורציה זו זמן עלית המחשב הוא של שניות בודדות – כיון שאין צורך לחכות לעלית Windows. יש פחות קוד של מערכת הפעלה (Windows לא נמצא כלל ב-Target) ואין תהליכים שאין להם נגיעה ליישום – כך שהאמינות גבוהה יותר. בנוסף – המשאבים שצורך Windows – ליבות, זכרון RAM, נפח דיסק ומחיר רישוי ל Windows נחסכים.

מתי נרצה לבזר את המעבדים במערכת ה-Target

קונפיגורציות 3 ו-4 באיור 2 רלוונטיות למערכות מבוזרות: 3 “מעט מבוזרת” ו-4 – מבוזרת מאד. במערכות אלה ניתן להרחיק את בקרת ה-I/O המבוצעת מעל מערכת ההפעלה ממערכת הבקרה המרכזית הבנויה מעל Windows. במעבר בין הקונפיגורציות השונות אין צורך בשינוי תוכנה אלא בשינוי פרמטר. אפשר לשים על אותה רשת פנימית של LAN מספר תחנות מכל אחת מהקונפיגורציות שתוארו באיור 2. בעמדות רצה תוכנת INtime (עצמאית או לצידה של Windows) ותוכנת Windows שנעזרת בתוכנה הקרויה Host שמספקת את תקשורת NTX גם למחשב שאין בו מערכת הפעלה  כלל.

בצורה זו – גם בקונפיגורציות שונות מהקונפיגורציה העיקרית נשמרת ההשקעה בפיתוח.

סביבת הפיתוח

איור מספר 3 מתאר את עמדות העבודה לפיתוח. המערכת שבה משולב Windows ומערכת ההפעלה על אותו ה-PC הינה המערכת שעליה עובד התכנת. על המערכת הזו אפשר להריץ Visual Studio ולדבג את הקוד של התוכנית ש-VS מייצר עבור INtime.

קיימות שתי אפשרויות להציג את ה-I/O למהנדס המפתח:

במקרה שה-I/O פשוט ו/או זול מאד – ניתן לספק לכל מפתח מערכת מטיפוס 4 באיור מספר 3. במידה וה-I/O מורכב או יקר – ניתן להשתמש בקונפיגורציה 5 המוצגת באיור מספר 3. בונים צורה מפושטת של הדרייבר ל-I/O האמיתי – והיא מהווה את הסימולטור. סימולטור כזה מספק ליתר חלקי התכנה תגובת זהה בתזמוניה ל-I/O האמיתי.

כשיש כמה תכנתים ויש צורך לעבור בין עמדות פיתוח בשלבים שונים של הפרויקט – מסופקת קונפיגורציה פיתוח ברשת (מספר 6 באיור מספר 3). שימוש בחיבור רשת בין עמדות הפיתוח ושימוש ב-License Server מאפשרים סביבה נוחה שחוסכת זמן, וחוסכת עלויות רשיונות ריצה ורשיונות פיתוח.

לסיכום

במאמר צוינו הגורמים להוזלת פיתוח התוכנה והקטנת הסיכונים:

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

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

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

שימוש בסימולטור לזמן אמת שהוא By-Product של תוכנת פיתוח הגישה ל-I/O האמיתי, וניהול כל עבודת הקבוצה ברשת, מוזילים את עלות תשתית הפיתוח.

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

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

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