הפונקציונליות של תוכנת האוויוניקה מוסיפה להתרחב. יכולות תוכנה נוספות מביאות הרבה יותר קווי קוד, וסיכויים מוגברים לשגיאות. בו בזמן, ככל שמערך של תוכנת אוויוניקה נהיה יותר קריטי, כך גובר הסיכון שלו לטרור באינטרנט ולפורצי מחשבים, כך שתוכנה קריטית-לבטיחות (safety-critical) עתידית מציעה אבטחה ובטיחות בעזרת כלי פיתוח תוכנה, שירותי בדיקה ואימות, ומערכות הפעלה חסינות בפני התערבות זרה.
“כאשר מדובר באוויוניקה, אני חושב שכולם מבינים שבכל מקום שתגיע במטוס, חייך יהיו תלויים לחלוטין בידיים של מערך תוכנה גדול ומרוכז”, מציין Robert Dewar, נשיא AdaCore מ-New York.
“למזלנו לא חווינו כל תאונת מטוס בה כשל בתוכנה יגרום לאיבוד חיי אדם”, מצביע Dewar, אבל הוא מוסיף אזהרה: אם כי איש לא נהרג מבעיית תוכנה בטיסה מסחרית ,”היו כמה מקרים די קרובים לכך; היו לנו אחד או שני מקרים מעוררי חלחלה”, הוא מציין.
בטיסת Malaysian Airlines באוגוסט 2005 היה אירוע מוטס בו התוכנה הזינה נתוני מד-תאוצה שגויים אל מחשב הטיסה העיקרי, אל הטייס האוטומטי ואל מערכות מוטסות נוספות. הבדיקה הראשונית לא גילתה כל פגם בתוכנה. “אנחנו יכולים בהחלט לשפר את מעשינו”, אומר Dewar. “לספקי תוכנת האוויוניקה ולרשות התעופה הפדראלית (Federal Aviation Administration –FAA) צריכה להיות אמונה הרבה יותר גבוהה באמינות, בטיחות ואבטחת המערכת”.
פיתוח מוקפד
“תוכנה קריטית-לבטיחות צריכה להיות חופשית מתקלות, ועליה לפעול בהתאם למפרטים”, מסביר Dewar. כאן נכנס לפעולה תקן DO-178B של ה-FAA. תקן זה, המוכר רשמית כ-Software Considerations in Airborne Systems and Equipment Certification, עשוי לייקר את פיתוח הקוד הקריטי-לבטיחות, אך הברירה איננה קבילה כלל”.
התקן הוא “בבסיסו פרוטוקול בדיקה פורמאלי הדורש ריכוז של כל הדרישות בצורה פורמאלית”, מתאר Dewar. “עליך לפתח בדיקות מקיפות הבודקות כל דרישה; המאמץ של הפקת בדיקות אלה פירושו שהקוד נבחן בקפדנות, אך הוא איננו מספק כל הוכחה מתמטית שהדברים אכן פועלים. אנשים נוטים יותר לכיוון ההוכחה המתמטית והשיטות הפורמאליות”.
ניתוח סטטי של כלי תוכנה מסוגל לנתח קוד-מקור כדי להפיק תכונות כגון שימוש מרבי בזיכרון שיכול לסייע לגלוי כשלים שלא בלטו בעיני המתכנת, בעוד כלי ניתוח דינמי יכולים לסייע להציג איזה קוד מבצע מערך בדיקה. “לכולם יש מקום שמור בפיתוח קריטי-לבטיחות”, אומר Dewar.
מהנדסים מ-Lockheed Martin Aeronautics Co. ב-Marietta, Ga. השתמשו ב-GNAT Pro של AdaCore לפיתוח תוכנת ה-Flight Management System Interface Manager and Radio Control עבור מטוס ה-C-130J Super Hercules. הם השתמשו ב-GNAT Pro High-Integrity Edition עבור מטרת PowerPC הרצה על VxWorks 653, מערכת ההפעלה (RTOS) המחולקת בזמן ובזיכרון של Wind River Systems מ-Alameda, Calif.. GNAT Pro סייעה עם שדרוג התוכנה Block 7.0 של מערכת ניהול בטיסה החדשה של ה- C-130J אשר פותחה על-ידי GE Aviation מ-Grand Rapids, Mich. ו-Lockheed Martin Aeronautics.
מתבצר ב-Ada
Ada שימש במשך עשורים כתקן לאמינות בתוכנת אוויוניקה ויישומים קריטיים-למשימה.
“עשרות מיליוני קווים של Ada מתרוצצים ב-DOD”, אומר Dewar. “Ada נעלמה מההכרה של מרבית האנשים, אך לא בתחום התוכניות הגדולות הקריטיות-לבטיחות”, מודה Dewar. “GE Aviation ביצע לא מעט פיתוח חדש של Ada עבור ה-Boeing 787; בין 40 ל-60 אחוזים של תוכנת האוויוניקה ב-787 הם ב-Ada”.
National Air Traffic Services (NATS) מ-Whiteley, אנגליה, המספקת בקרת תעבורה אווירית עבור מטוסים הטסים במרחב האווירי של הממלכה המאוחדת ובחלק המזרחי של האוקיאנוס האטלנטי הצפוני, בחרה ב-Altran Praxis, Ltd.,, מומחית בהנדסת מערכות משובצות וקריטיות מ-Bath, אנגליה, כדי לפתח את מערכת ה-iFACTS המתקדמת ולתמוך ולתחזק את ה-Traffic Load Prediction Device (TLPD) שלה. ה-iFACTS מחליפה את רצועות המידע על ניר המסורתיים בתצוגות נתונים אלקטרוניים וחדשות, מספקת כלים לחיזוי מסלולים, גילוי סכסוכים ועזרי ניטור. ה-TLPD משתמשת במסרים של תכניות טיסה, טקטיים ומכמיים.
Ada תוכננה מראש כשפה מאובטחת. “זה לא כדור קסם, אבל אתה באמת רוצה לנצל שפה שהיא משמעותית יותר מאובטחת”, ממליץ Dewar. C++ ו-Ada הם באמת יומם ולילה. אם אתה מתכנת ב-Ada ויש לך גדלים הנמדדים ביחידות מטריות או אמריקאניות, אלה יהיו סוגים שונים שלא ניתן לערב בדרך כושלת. בתכנית C/C++ טיפוסית, קל למדי לבלבל דברים כאלה. ה-Mars Climate Orbiter (MCO) נאבד בגלל הבלבול בין מידות מטריות ולא מטריות. כמובן, כל אחד יכול לכתוב זבל בכל שפה, אך שגיאה כזו היא פחות סבירה בסביבה של Ada.
תכנון מבוסס מודל
ככלל, המטרה של כל תהליך פיתוח תוכנה היא לספק תוכנה איכותית ורובוסטית העונה לדרישות הלקוח, אומר Jon Friedman, מנהל שיווק לתעשייה האווירית וההגנה ב-The MathWorks ב-Natick, Mass.. “תהליך מוגדר היטב כולל את השלבים הבאים: שלב קליטת הדרישות והאימות, תכנון ובדיקה, מימוש ושילוב, בדיקה סופית וסיום. אולם יישומים קריטיים-למשימה רבים צריכים גם להתאים או להיות מאושרים על-ידי תקני תעשייה ספציפיים, כגון IEC-61508, ISO-26262, או DO-178B.
“תקנים אלה דורשים נקיטת אמצעים מסוימים ויצירת מוצרים”, מוסיף Friedman. לדוגמה, במסגרת DO-178B, יש לקבוע דרישות ולזהות בדיקות כדי לאשר שהדרישות מולאו; בנוסף, יש לעקוב אחר כל קו של קוד לדרישה כדי שניתן יהיה להיווכח מדוע הוא כלול בקוד, הוא אומר.
ההשפעה של בדיקת תכנון בלתי-שלמה ניתנת לראות בכישלון המצער של ה-MCO, אשר נשרף באטמוספרה של המאדים כאשר הוא חדר במסלול נמוך מהמתוכנן. “התכנון המשולב הסופי לא נבדק במלואו והתוצאות היו הרות אסון”, מסביר Friedman. בדוגמה אחרת, תוכנת הבקרה של ה-Ariane 5 (501) נלקחה מה-Ariane 4, אך פרופיל המשימה של ה-Ariane 5 היה שונה. “כתוצאה, גלישה אריתמטית גרמה לסדרה של כשלים עוקבים אשר גרמו להשמדת הטיל”.
על המהנדסים ליצור ולבדוק שהתכנונים שלהם עונים לדרישות ברמת מערכת עוד יותר מורכבות. כדי לעמוד באתגר, מהנדסים רבים בחרו בתכנון מבוסס על מודלים. גישה זו מתחילה עם אותו מערך של דרישות כמו התכנון המסורתי, אך המהנדסים מפתחים מפרטים ברי-ביצוע בצורה של מודלים במקום המפרטים הכתובים, אומר Friedman.
“המהנדסים משתמשים במודלים אלה כדי לברר דרישות ומפרטים, להעריך במהרה בחירה של תכנון ותצורה ולהקל על ההדמיות כדי לבדוק שהתכנון עונה לדרישות”, מוסיף Friedman. באחד המחקרים, מהנדסים גילו יותר משלוש פעמים דרישות על-ידי שימוש בתכנון מבוסס-מודלים מאשר על-ידי שימוש בשיטות תכנון מסורתיות”. על-ידי שימוש בתכנון מבוסס-מודלים כדי לפתח בקרי טיסה, חברות תעופה דיווחו על הפחתות של 40 עד 60 אחוזים בזמן הפיתוח על-ידי מתן יכולת של טיפול בדרישות ובטעויות תכנון מוקדם בחיי התכנית.
תוך שימוש בקוד טיסה המופק אוטומטית. “כלי ה-MathWorks עבור תכנון מבוסס-מודלים סייע לנו לתכנן ולהפיק אוטומטית קוד עבור תוכנת יישומי הטיסה של SMART-1 לבקרת מיקום, בקרת הספק, בקרה תרמית ו-FDIR”, מסביר Per Bodin, מנהל של SMART-1 AOCS ב-SSC. “על בסיס הצלחה זו, אנחנו מתכננים לפתח את כל תכנת היישומים המוטסים, קרוב ל-95 אחוזים מתוכנת הטיסה המלאה, על-ידי שימוש ב-Simulink וב-Real Time Workshop Embedded Coder”.
SSC מימשה תהליך פיתוח חדש המבוסס על כלים של The MathWorks לתכנון מבוסס-מודלים כדי לדגם, לדמות, להפיק קוד אוטומטי ולבדוק את תוכנת AOCS המוטסת. SSC השתמשה בכלים של The MathWorks כדי להפיק אוטומטית את קוד יישום ה-C, אשר תורגם, שולב וקושר לתוכנה המוטסת הכללית. מהנדסים פיתחו מודלי הדמיה מדויקים כדי לחזות את התנהגות המערכת וליצור תכניות בדיקה מפורטות של המערכת ושל התוכנה, אשר ענו לתקן פיתוח התוכנה PSS-05 של ה-European Space Agency (ESA).
בנוסף לעמידה בדרישות התוכנה ברמה נמוכה, בדיקות היחידה והשילוב כללו ניתוח כיסוי קוד מבני, בדיקת תחום המבוא, ובדיקת ה-max-path. SSC ביצעה בדיקת מערכת התוכנה בסביבת הדמיה בזמן-אמת קשוחה וניתחה את התוצאות בעזרת MATLAB. הם בדקו את ה-AOCS ברמת המערכת תוך שימוש בחללית המשולבת. בדיקות אלה כללו בדיקות בלולאה פתוחה וסגורה ב-European Space Research and Technology Center בהולנד.
אימות ובדיקה
לגבי תוכנת אוויוניקה קריטית-לבטיחות , הדרישות של בדיקה ואימות הן גבוהות יותר מאשר ברוב התוכנות האחרות, מודה Andy Chou, מהנדס ראשי ב-Coverity Inc. ב-San Francisco. “כשל במערכת תוכנה של מטוס עשוי לגרום להפסדים סביבתיים ושל ציוד, במקרה הטוב ביותר, או למוות של אנשים במקרה הגרוע ביותר; לכן, עבור תוכנת אוויוניקה קיימת רמה גבוהה יותר של דרישות באשר לנכונות ההתנהגות שלה – כל הדרך מרגע הגדרת הדרישות, הגדרת תכנון ברמה גבוהה יותר יצירת מפרט מדויק, ועד לעת כתיבת הקוד. כדי להבטיח שתוכנת האוויוניקה מתנהגת כצפוי דרוש שהאימות והבדיקה ימוקדו לכל אחד משלבי התכנון והפיתוח”, מסביר Chou.
הפתרונות של מפתחי Coverity עבור בדיקת קוד אוטומטית משתמשים בניתוח סטאטי מתקדם. המשתמשים יכולים לנתח קטעים מהתוכנה ללא צורך להפעיל את כל המערכת, דבר שימושי כשמרכיבי תוכנת האוויוניקה מצטרפים מספקי צד שלישי. “הדבר נותן ידיעה מוקדמת על סוגיות הבטיחות הפוטנציאליות על-ידי גילוי כשלי תוכנה בתוכנת הספק ברמת הקוד לפני השילוב ברמת המערכת או המטוס”, מוסיף Chou.
מצד הדרישות, נציגי ההנדסה המוגדרים בתוכנה (software designated representatives-DERs) מסייעים ל-FAA לוודא תאימות, על-ידי בדיקת המידע המסופק על-ידי המועמד כדי לוודא שתהליכי ה-DO-178B בוצעו בשעת פיתוח התוכנה המוטסת. “אין שום כלי יחיד שיכול לספק הבטחת תאימות. יש להשתמש בשילוב של תהליכים וכלים מרובים. ניתוח סטאטי היא אחת הצורות של בדיקה ואימות של המפתח. בצורתו הבסיסית ביותר, אפשר להתייחס אליו כאל סקירה אוטומטית של קוד”, אומר Chou. “המטרה היא לחפש חוסר עקביות בקוד המשמש סימן אודות ביצוע העבודה. במקרה הכי טוב, חוסר עקביות כזה מראה על תהליכים מנותקים בתכנון ופיתוח”.
ספק עלום-שם של פתרונות תקשורת ואלקטרוניקה של אוויוניקה משתמש ב-Coverity כדי לסייע בשיפור שלמות התוכנה במהלך קו הייצור שלו, כמו גם כדי לספק הבטחה אודות האיכות, הבטיחות והאבטחה של הקוד שהוא מספק לשרשרת הספקת התוכנה שלו, המורכבת מיצרני מטוסים גדולים.
“החברה ערה לחשיבות האימות של DO-178B ולערך שלו, המאמת כי מבצעים תהליכים תואמים בפיתוח התוכנה”, מציין Chou. “יותר חשוב, הם מבינים שתאימות ל-DO-178B אין פירושה פטור מתקלות. מה שחשוב הוא להבטיח שכולם משתמשים בכלים וטכנולוגיה העומדים לרשותם בהתחשב באופי הקריטי-לבטיחות של תוכנת האוויוניקה שהם מייצרים, באם היא מאושרת ב-DO-178B או לא. חלק מהמניע שלהם הוא ההבנה הזאת שאפילו מפתחים של תוכנה לא קריטית-בטיחות אימצו ניתוח סטאטי כדי להבטיח שהתוכנה שלהם לא מתרסקת או פועלת בצורה בלתי-חזויה”.
קריטי-לבטיחות הוא קריט-לאבטחה
כל תוכנה קריטית-לבטיחות היא גם קריטית-לאבטחה, טוען Dewar. “כל תוכנה קריטית- לבטיחות מיועדת להיות גם קריטית-לאבטחה. אם חייך תלויים בהיעדר כשלים, אזי הם תלויים בכך שאין בחורים רעים החודרים ללא רשות במערכת כזו. תוכנה קריטית-לאבטחה חייבת להיות בלתי-חדירה למתקפות זדוניות מבחוץ. הדאגה על אבטחת המחשבים איננה זעקת “זאב”. קיימת חולשה פוטנציאלית ענקית בכל התשתית שלנו. במידה מסוימת, אני מביט על העולם המודרני וחושב שזה מדהים שדברים יותר איומים לא קרו”.
“התוצאות של השימוש בפתרון בלתי-אמין או בלתי-מוכח הן חמורות, ויכולות לכלול איבוד של המטוס והמטען שלו, מה שלא יהיה זה”, אומר John Warther, סגן נשיא של תכניות ממשלתיות ב-Green Hills Software מ-Santa Barbara, Calif.. “העובדים ב-[the and Innovative Technology Administration’s] Research Volpe National Transportation Systems Center ב-Cambridge, Mass. בוחנים חלק מסוגיות אלה, כמו גם ה-RTCA Special Committee 216 ב-Washington”.
מבחינת האבטחה, מנגנון תקשורת בדלת האחורית אל מערכת בקרת טיסה מוטס או קרקעית מהווה סיכון פוטנציאלי בפני טרוריסטים, אומר Robert Day, סגן נשיא לשיווק ב-Lynux Works Inc. מ-San Jose, Calif.. “חיבור מרחוק וקשר בהמשך עם מטוס הנמצא בטיסה עלולים לגרום לנזק טרוריסטי נרחב מכל מקום בתבל. דבר זה תקף הן למטוסים צבאיים והן למסחריים. חיוני ביותר לפתח מערכות המסוגלות לגלות ולעמוד באיומים אלה או להגביל אותם”, הוא אומר. מוצרי Lynux Works שימשו במערכות מוטסות, קריטיות- לטיסה, וקרקעיות שדרשו פונקציונליות לבטיחות וביטחון.
RTOS והפרדה
“רק מערכות הפועלות בזמן-אמת הן בנות קיימא עבור מערכות אוויוניקה כדי לספק את הרמה הגבוהה של אמינות וביטחון הדרושה”, אומר Warther. “יש לתכנן את ה-RTOS (מערכת הפעלה בזמן-אמת) מהרצפה עם הפרדה בטיחותית כדי ליהנות מהרמות הגבוהות ביותר של בטיחות והבטחה בזמן ובמרחב”.
מתזמן רובוסטי של מערך כלי הפיתוח הנבחר הוא גם שיקול ארכיטקטוני חשוב, מסביר Warther. “יש לנהל את המשאבים בהתאם לדרישות המפתח וזהו המפתח להצלחה. מרבית המימושים של RTOS משתמשים במאגר זיכרון-ליבה מרכזי כדי לענות לדרישות היישום. דבר זה עלול לגרום למשימה זדונית או ערוכה גרוע לצרוך את כל המשאבים ולגרום להופעת “שלילת שירות”.
RTOS מופרד מציע הגנת הזיכרון והיישומים על ידי הקצאת משאבים או חלוקתם, מציין Day. כל הפרדה מספקת הגנה בפני כל התנהגות שגויה המופגנת על-ידי יישומים אחרים. “במערכת אוויוניקה” חלוקה שימשה לרוב כדי להוכיח שפונקציות מרובות המופעלות על-ידי מערכת יחידה יכולות להיות מוגנות אחת מהשנייה”, הוא אומר. “מערכות הפעלה אלה משמשות לרוב כדי למנוע או לסייע בהגבלת תנאי כשל, יותר מאשר התקפות זדוניות, משום שהמערכות הן לעתים קרובות ישות עצמאית (כלומר לא מתקשרות לעולם החיצון).
“ככל שמערכות אוויוניקה מכילות יותר חומרה ומערכות פיזיות בפלטפורמה יחידה, ובו זמנית הן פונות ביותר ויותר ערוצים אל העולם החיצון, כך גדלה הסוגיה של כשלים זדוניים שניתן להחדיר לתוך המערכת”, ממשיך Day. “RTOS מחולק נכון, קריטי-לבטיחות מסוגל למנוע חלק מהם, אולם כדי להיות באמת בטוחים באוויר, ליבת הפרדה של ה-Multiple Independent Levels of Security (MILS) היא בחירה טובה יותר. היא יוצרת מערכת מחולקת עם תכונות בטיחות מובנות, והיא נחשפה לבדיקות חדירה יותר חמורות בפני התקפות זדוניות”.
צוות ה-L-3 Communications Display Systems בחר ב-RTOS LynxOS-178 של Lynux Works כדי להזין חלק מתת-המערכת Panoramic Cockpit Display (PCD) עבור המטוס F-35 Joint Strike Fighter (JSF) של Lockheed Martin. ה-RTOS המאושר על-ידי DO-178 נבחר בשל היענותו לתקנים פתוחים, התאימות ל-Linux, יתרונות הפעילות ההדדית של POSIX API והתמיכה במפרט ARINC 653. ה-RTOS LynxOS-178 מספק ביטחון באמצעות הפרדות על-ידי חומות-לבנים ממוכנות וירטואליות.
“בחרנו את מערכת ההפעלה של Lynus Works משום שהחברה הציעה RTOS וחבילת מוצרים מושלמים ביותר, ביחד עם שירותי תמיכה ומודלים עסקיים ללא תחרות מצד יצרנים אחרים”, אומר Bob McGill, נשיא L-3 Displays Group. “עם Lynus Works, יכולנו לנצל את עוצמות המוצר שלהם ולספק פיתרון שיעלה מעל הציפיות של הלקוחות שלנו באשר לביצועים ובטיחות”.
RTOS וסביבת הפיתוח
מטוס הקרב F35 Lightning II Joint Strike של Lockheed Martin גם מנצל את פתרונות התוכנה המאובטחת של Green Hills Software. מהנדסי Lockheed Martin בחרו ב-RTOS Integrity-178B וסביבת הפיתוח המשולבת AdaMULTI (IDE) של Green Hills Software כדי לפתח תוכנה קריטית-לבטיחות ולאבטחה עבור ה-F-35. תוכנת אוויוניקה מפותחת על-ידי Lockheed Martin רצה על Integrity-178B במערכות רבות מוטסות, מבוססות על Power Architecture, אומר נציג של Green Hills.
ל-Green Hills היסטוריה ארוכה של פעילות במטוסים צבאיים, מציין Warther. “כיום, מערכת ההפעלה Integrity-178B מתוכננת או כבר הושקה בכמעט כל מטוס מסחרי או צבאי חשוב מהדור הבא. ביניהם, ה-Dreamliner 787 החדש, ה-F-22 Raptor, ה-C-130J Super Hercules והמסוק VH-71 Marine One של Boeing, מטוס התובלה החדש A-400M של Airbus, המפציץ החמקן B-2 Spiritשל Northrop Grumman, מטוס התובלה C-17 Globemaster III של Boeing והמסוק S-92 של Sikorsky.
צוות האווירונאוטיקה של Lockheed Martin בחר ב-RTOS Integrity עבור ה-Color Display Processor (CDP) המוטס של מטוסי הקרב F-16. ה-CDP מפיק וידאו בזמן-אמת עבור תצוגות תא-הטייס, המאפשר לטייסים לפקח על מצב המטוס, ביצועי המנוע ותפעול מערכת הנשק תוך כדי טיסה. Lockheed Martin Aeronautics משתמשת גם בתוכנת Multi IDE של Green Hills כדי לפתח תוכנת יישומי CDP, הרצה על מעבד PowerPC PPC7400 תחת ה-RTOS Integrity.
“אנחנו זקוקים ל-RTOS אמין ביותר עבור ה-CDP”, אומר Darrell Kindley, מנהל צוות מעבדי הליבה והתצוגות של F-16 block 60 ב-Lockheed Martin Aeronautics. במיוחד, אנחנו זקוקים ל-RTOS מחולק בעל זיכרון מוגן אשר מאפשר לנו לבודד חלקים שונים מהיישום מהאחרים, כך ששגיאות בחלק אחד של היישום לא ישפיעו על חלקים אחרים של ה-CDP. הגנת הזיכרון המובנית של Integrity, ביחד עם התגובה הקשוחה בזמן-אמת שלה וזמינות המקורות המובטחת, עושות אותה לרכיב מתאים ביותר עבור יישום קריטי-לבטיחות זה.
השימוש בכלים מסחריים מהמדף (COTS) בסביבות אוויריות צבאיות איננו מוגבל לחומרה. תוכנת COTS, כולל מערכות הפעלה, סוללת בהדרגה את דרכה בפלטפורמות אוויריות-צבאיות.
“תוכנת היישום עבור ה-Vertical Situation Display (עבור המפציץ B1-B של חיל האוויר האמריקאי) נכתבה על-ידי Boeing מעל פלטפורמת COTS המאושרת GE Intelligent Platforms”, מסביר Simon Collins, מנהל מוצר ב-GE Intelligent Platforms מ-Northampton, אנגליה. “היתרונות של פיתרון COTS מאושר היו: לאפשר ל-Boeing להתחיל בפיתוח היישום שלה על הפלטפורמה מוקדם יותר מאשר אילו השתמשה בפיתרון מקובל, ובכך לצמצם את זמן הפיתוח; סיכון כללי מוקטן של שילוב מרכיבי חומרה ותוכנה; ונקודת אחריות יחידה עבור השגת האימות של הפלטפורמה וידאו/גראפית.
ה-B1-B של Boeing גם משתמש במעבד הוידאו/גראפי הקשיח Octegra3 6U VME וה-מזאנין הקשוח למבוא וידאו VIM2 של GE Intelligent Platforms , כמו גם ב-Board Support Package ו-מזיני OpenGL ES SC כדי לעבד זרמי מבואות וידאו מרובים בו-זמנית, דבר המספק מודעות למצב לצוות.
נציגי Boeing דרשו שתת-המערכות יהיו מאושרות לפי DO-178B, כלומר שתהליך הפיתוח בשימוש יתאם לדרישות האיכות החמורות שנועדו למקסם את הבטיחות של מערכות מוטסות. GE Intelligent Platforms שכר כקבלן משנה את Ultra Electronics Controls בממלכה המאוחדת כדי לבצע את הפיתוח והאימות של חבילת התמיכה המוטסת הדרושה, בעוד Presagis סיפקה גרסה תואמת-DO-178B של הפיתרון הגראפי המשובץ שלה OpenGL.
“Deos כבר אושרה לפי DO-178B Level A בתריסרי תכניות והיא טסה במטוסים מסחריים וצבאיים רבים יותר מאשר כל RTOS אחר המאושר ל-COTS” אומר Greg Rose, סגן נשיא לשיווק ב-DDC-1 ב-Phoenix. Deos מייצגת את שיא ההשקעה של מאות שנות-אדם של הנדסה”. ה-RTOS Deos, שפותח במקור ב-,Honeywell טס ב-Airbus A400M, מסוקAugusta AB-139, Australia CASA, Boeing 787, ה-Bombardier Global Express, C-5, C-17, C-130J, CV-22 Osprey, F-18, Citation V ו-Sovereign של Cessna, ופלטפורמות שונות של Dassault, Embraer, Gulfstream ו-Raytheon.
Goodrich Sensors and Integrated Systems בחרה ב-RTOS המחולק בזמן ובמרחב Deos DDC-I,ככלי הפיתוח Open/Arbor ומוצרי האימות של DO-178B לשימוש ב-Concentrator and Multiplexor לוידאו (CMV), שהוא חלק מהוידאו במערכת המצלמות החיצוניות ובתא-הטייס (ECCV).
ה-RTOS DDC-I בעל הזיכרון המוגן כולל היענות דטרמיניסטית בזמן-אמת ומשתמש ב”תזמון רופף” בעל פטנט כדי לאפשר שימוש גבוה ב-CPU. “Deos היא ה-RTOS – COTS המחולק בזמן ובמרחב היחידה בר-אישור שנבנה מהיסוד עבור יישומים קריטיים- לבטיחות”, אומר דובר החברה. “Deos גם מספקת נתיב קל וזול של COTS RTOS כלשהו לבצע אימות של DO-178B רמה A, הרמה הגבוהה ביותר של קריטיות-לבטיחות”.
תמיכת הפיתוח עבור ה-Deos כוללת ה-OpenArbor IDE מבוסס Eclipse עם מהדר (compiler) מייעל של C ו-C++, עורך מקור מקודד-צבעים, תמיכה בניהול הפרויקט, עזרי בנייה אוטומטיים ותוכנת ניפוי סמלי בעלת שפה מעורבת ורבת-חלונות.
אבטחת התוכנה
מכשירי רדיו מוגדרים בתוכנה (software-defined radios –SDR) המותאמים לפלטפורמות כגון מטוסי חיל-האוויר של ארה”ב F-22 ו-F-35, ול-Joint Tactical Radio Systems (JTRS), מבטיחים אבטחה באמצעות הצפנה. “התוכנה מאפשרת רענון הטכנולוגיה, ועל-ידי בקרים מתאימים ניתן לאבטח את כל ה-Operational Flight Program (OFP) באמצעות הצפנה”, מסביר John Balcerzak, מנהל העסקים בתכניות החלל והאוויוניקה ב-General Dynamics C4 Systems, Information Assurance Division ב-Scottsdale, Ariz..
פלטפורמות ומכשירי רדיו שאינם מבוססי-תוכנה יתקשו לאמץ שיפורי יכולות חדשים, מוסיף Balcerzak. דוגמה אחת היא ההצפנה הבנויה בתוך תקן Common Data Link (CDL) המשמש לשידור וידאו. CDL איננו מבוסס-תוכנה ונכון להיום, היה קשה להוסיף דרישת CDL לפלטפורמות F-22 ו-F-35 או לרדיו JTRS.
“בדצמבר 2009, פורסמה כתבת חדשות אודות כוחות צבא בעיראק המשתמשים בתוכנה מהמדף בשווי $26 כדי לקלוט שידורי וידאו בזמן אמת ממל”טי Predator של ארה”ב”, אומר Balcerzak. זמינות תקן וידאו מאובטח הייתה מבטלת אירוע כעין זה”.
משפחת המוצרים Advanced INFOSEC Machine (AIM) של General Dynamics C4 Systems תומכת בפלטפורמות F-22 ו-F-35 ובמרכיבי המפתח של משפחת המוצרים JTRS הנמצאת בתהליכי פיתוח. AIM כוללת יסוד של תוכנה מאובטחת בעלת אלגוריתמי הצפנה מובנים מבוססי-תוכנה לשם הגנה על מידע מסווג בפני שימוש בידי גורמים בלתי-מאושרים. משפחת המוצרים AIM תומכת במתודולוגיות רדיו מוגדרות-בתוכנה כדי לאבטח תוכנת פלטפורמות והיא ניתנת להתאמה בשדה.
“המעורבות שלנו”, מתאר Balcerzak, כוללת בניית טכנולוגיות, מוצרים ומערכות אבטחה משולבות, קטנות ממדים, משקל והספק, עבור אוויוניקה, ועבור מערכות זע”ט (Identify Friend or Foe – IFF) חדישות ומובילות בתעשייה”.
ה-AIM II של החברה אושרה על-ידי ה-National Security Agency (NSA) להגנה על נתונים מסווגים בחודש יולי 2010; ה-AIM Xcelerator, המשתמשת ב-field-programmable gate arrays (FPGAs) חד-שבביים להצפנה השלימה הערכת NSA לאותה המטרה במאי 2010.
Balcerzak מבחין בנטיה גוברת מהכוחות המזוינים וה-NSA להשתמש בפתרונות הצפנה המשותפים לכל הפלטפורמות, דבר המצמצם את הפיתוח, ההתקנה ועלויות התחזוקה לשם הגשת מאפיינים מתקדמים ופעילות הדדית לחייל הבודד. “בשעה שהשירותים מאחדים את תקני התקשורת, הרישות וניהול המפתח, תהיה מוטיבציה נוספת להשתמש בפתרונות הצפנה מקובלים. מנקודת ראות טכנולוגית, כל אבני הבניין עבור אחידות בהצפנה נמצאות במקום אם הצבא תחליט לנצל אותם”.
אותם השיעורים שנלמדו בפיתוח מכשירי רדיו מוגדרים בתוכנה ניתנים ליישום בתקני התקשורת החדשים המתפתחים עבור מערכות מוטסות ללא-טייס קטנות (small unmanned airborne systems – SUAS), במיוחד אלה מסוג המשקל הידני, אומר Balcerzak. “באמצעות השימוש בתקני הצפנה, כלים ומשפחות מוצרים, יתרונות הממדים, המשקל וההספק של פתרונות ההצפנה יכולים להגיע לרמת ה-”מיקרו”.
מרחב אווירי מחולק
מטוסים צבאיים העוברים דרך המרחב האזרחי צריכים לקבל אישור לפי התקנים שה-FAA דורשת ממטוסים אזרחיים. “זהו דבר יחסית חדש”, אומר Dewar, “והוא אפילו תקף עבור מל”טים (UAVs). ה-FAA איננה רוצה UAVs החוצים את המרחב האזרחי אלא על-פי אישור, כך שקיים לחץ לאשר את התוכנה גם כן. אני חושב שקיים חוק די מוזר שרק מספר קטן, חופן של UAVs יכולים להימצא מעל ארה”ב בו-זמנית, אלא אם שיקול זה יבוטל. הם עדיין יכולים לטוס במרחב צבאי מוגבל, אבל הוא פוחת בהתמדה; יותר ויותר מהמרחב האווירי מחולק בין המטוסים הצבאיים והאזרחיים”.
אישור ה-DO-178B דרוש עבור מטוסים הטסים במרחב המסחרי, כך שדבר זה תקף גם לגבי מל”טים, מסביר Ben Brosgol, חבר בצוות הטכני הבכיר של AdaCore. “זוהי אחת הסיבות מדוע ה-DO-178B, אשר היה בעבר תקן עבור התעופה המסחרית, מעורר את תשומת ליבו של הקהילה הצבאית. המוצר GNAT Pro High-Integrity for DO-178B של AdaCore פונה לקהילת האישור של בטיחות הטיסה ומיועד לפיתוח התוכנה של המל”טים”. הלקוח EADS-CASA של AdaCore מ-Madrid, ספרד, עובד כיום על מל”ט קרב עבור תכנית nEUROn.
ערכת הכלים של LDRA שימשה גם למל”ט קצר-טווח מוביל, כמו גם ה-Airbus A400M, ה-Eurofighter Typhoon, ה-Extended Air defense Testbed, ה-F-16 Fighting Falcon, ה-F/A-22 Raptor וה-F-35 Lightning II JSF, אומר Bill StClair, מנהל תפעול ארה”ב ב-LDRA Technology Inc. ב-San Bruno, Calif..
אנשי Lockheed Martin Aeronautics שחררו פורמאלית את תקן הקידוד JSF++ air vehicle (AV) ובחרו ב-LDRA ככלי המובחר עבור פרויקט ה-JSF. LDRA עבדה בצמוד לקבלן הראשי Lockheed Martin במהלך שלב התכנון והפיתוח של המערכת הקריטית של הפרויקט. לאחרונה, השת”פ הטכנולוגי עודד את LDRA לסייע עם פיתוח תקן הקידוד C++ המיוחד עבור חטיבת JSF Air Vehicle Systems.
מפתחי LDRA שיפרו את מערך הכלים של החברה כדי לכלול את המאפיינים האנכיים הדרושים לשם מימוש תהליך בדיקת התוכנה של תקן הקידוד של Lockheed Martin AV. הגרסה המשופרת של כלי ה-LDRA מספקת למשתמשים תהליך אוטומטי לבדיקת תקני ה-C++ הדרושים על-ידי פרויקט ה-JSF, ומסייעת להבטיח שהתוכנה מפותחת באופן עקבי, היא נגישה אל ארכיטקטורות אחרות, חופשית משגיאות מקובלות, וניתנת להבנה ולתחזוקה בידי כל חבר בצוות.
מבט קדימה
“תכנון עבור אוויוניקה קריטית-לבטיחות דורש מתודולוגיות תכנון קפדניות ביותר, יעילים ביותר ביחד עם השגחה מעולה כדי להבטיח תאימות עם מדיניות ההסדרים המיוחדת הנדרשת על-ידי ה-FAA וסוכנויות אימות אחרות”, מסבירה Michelle Lange, מנהלת תכניות DO-254 ב-Mentor Graphics ב-Wilsonville, Ore..
“הכלים הם חלק חיוני מכל תהליך תכנון תוכנה/חומרה, מודה Lange. “התכנונים של היום הם הרבה יותר מידי מורכבים כדי לפתח אותם ללא עזרה של כלים. לא היית חולם לבנות גורד-שחקים מורכב ללא כלים מאוד מתוחכמים המתאימים לעשות את התהליך יעיל והמוצר הסופי בטוח לקראת השימוש המתוכנן שלו”.
כלי האוטומציה של התכנון האלקטרוני (Electronic design automation – EDA) מחברות תעשייה כגון Mentor Graphics משחקת תפקיד דומה בבניית תכנון מורכב, קריטי- לבטיחות. “כלים הם תמיד בשימוש בתהליכי הפיתוח הללו, אולם חלק מהכלים הם יותר מתאימים להיבט התאימות של תהליכים אלה מאשר אחרים”, אומרת Lange. “לשם כך, ספק הכלים חייב להבין את המדיניות הרגולטורית ומה החברות (הלקוחות שלהן) נדרשות לעשות כדי למלא אותה. לאחר מכן הם יכולים לנצל את ההבנה הזו כדי לכוון ולהתאים את כלי הפיתוח לתמיכה בפיתוח בהקשר של התאימות. שימוש בכלי התומך בערכה תרום-מזוודת של תקני קידוד יעילים ביותר עבור התכנון של אוויוניקה קריטית-לבטיחות עשוי לסייע לחברות למלא אחר דרישה של תאימות רגולטורית, התורמת לאבטחת המוצר הסופי ובו-בזמן הופכת את התהליך ליותר יעיל”.
