רקע
מטוס זעיר ללא טיס (מזל”ט), מטוס ללא טיס (מל”ט), כלי טיס בלתי מאויש (כטב”מ) ונכון להיום, כלי טיס מאויש מרחוק, ובראשי תיבות כטמ”ם…באיזה שם שלא תבחר העובדה היא שהשימוש במערכות מוטסות בלתי מאוישות מתרבה באופן מהיר ביישומים מגוונים החל ממערכות מוטסות נושאות נשק קטלני, או אחרות השומרות על שלום הציבור דרך כלי טיס העוקב אחרי שינויים גאולוגיים ועד שילוח חבילות.
התרחבות השימוש בכטב”מים, מאתגרת את מטרתה הרשמית של רשות התעופה האמריקאית FAA שחרתה על דגלה “לספק את המערכות המוטסות הבטוחות והיעילות ביותר בעולם”. ללא התערבות טיס אנושי על ההגאים, תוכנות הבקרה המוטסות אחראיות באופן בלעדי לתחזק את בטיחות ואבטחת הכטב”מ. ולכן לא מפתיע שה-FAA מביע דאגה מהשימוש המתרחב בכלי טיס אלו ביישומים צבאיים ומסחריים כאחד. מטוסים ללא צוות ונוסעים מהווים סכנה לכלי טיס אחרים עם צוות ונוסעים באוויר, ולאדם ורכוש על הקרקע. כיצד אישור רשות התעופה האמריקאית לתוכנת אוויוניקה, ה-DO-178B, מיושם במקרים אלו?
ואז יש כמובן את נושא הביטחון ואבטחה מפני קוד זדוני ותקיפות סייבר ללא קשר למטען שנושא כלי הטיס. כיצד בעצם אפשר לספק הבטחה אפקטיבית במקרים אלו?
- איור 1. נלקח ממסמך AMC RPAS.1309: דוגמה לכשל שיכול לגרום להתנגשות באוויר בין שני מטוסים על אותו נתיב בכיוונים הפוכים
- איור 2. תוכנת בקרת טיסה ותקשורת במל”ט טיפוסי
- איור 3. ארכיטקטורה המציגה את ההפרדה של מכונות וירטואליות שונות
- איור 4. תרשים כללי של ההפרדה של ARINC 653 עבור מל”ט
מד סטנדרטים בתעשייה בהתהוות
כמו בכל התעשיות בתחילת דרכן, דרכי ההתפתחות של גופי הסמכה שונים אינם דומים, וכל אחד לוקח כיוון שונה. באופן זה, נעשו ניסיונות של גופים שונים ללוקליזציה של סטנדרטים מקומיים, דבר שגרם לבלבול נוסף לחברות שרצו להתפתח לשווקים בינלאומיים.
כדי לתת מענה לבעיה, הוקם גוף בשם JARUS המאויש ע״י צוות מומחים מרשויות וסוכנויות תעופה אמריקאיות ובינלאומיות. תפקידו של JARUS זה להכין המלצות טכניות של בטיחות מערכות טיסה ודרישות אופרטיביות של רישיון כלי טיס ללא טייס. מטרתו הסופית של JARUS, להכין חומרי מידע והכוונה כדי להקל על הרשויות השונות לכתוב את דרישותיהן ולמנוע שכפול מאמצים ע״י הרשויות השונות.
למרות שעבודתם עדיין לא הסתיימה, מה שפורסם עד כה מספיק כדי להאיר את הדרך בסביבה לא ברורה. מה שברור זה השפעתו של תקן DO-178C על הסטנדרט המתהווה.
שיקולי הבטחה
תפיסת המזל״ט של ה-CIA באירן בשנת 2011, הדגיש את העובדה שאם המערכת לא מסוגלת להתגונן ממתקפת סייבר, בטיחות תישאר בעיה. באותה תקרית טענו הרשויות האירניות שהסיטו את כלי הטיס ע״י פריצה למערכת ה-GPS שלו. טענה זו צברה אמינות כאשר פרופ׳ טוד המפריס וצוות חוקרים מאוניברסיטת טקסס פרצו למל״ט מול עיניהם המשתאות של נציגי המשרד לביטחון פנים של ארה״ב. הצוות הערים על מקלט ה-GPS בכלי הטיס תוך החזות לאותות המיקום הגלובלי המשודרים, ובכך יכלו בקלות לגרום לו לטוס למקום אחר.
נכון להיום ארגון ה-JARUS לא פרסם דבר הקשור לאבטחת המל״ט. עם זאת, בהתחשב במינוף שעושה הגוף בסטנדרט DO-178C בענייני הבטיחות, הגיוני שמסלול דומה יעשה בנוגע לנושא האבטחה. אבל סטנדרטים מבוססי אבטחה כמו DO-355 אינם נכללים בחלקים המתהווים של הסטנדרט החדש.
לעת עתה ההכוונה הנראית סבירה ביותר מגיעה ממסמך ה-DO-178C המלא. המסמך קובע כי מערכת בטיחות קריטית ששלמותה מוטל בספק עקב היותה בסכנה של פרצת אבטחה לא תהיה ברמה הנדרשת ולכן לא תקבל אישור תעופתי.
כדוגמא, אחד החששות הכבדים מהתפשטות השימוש במל״טים טמון בפוטנציאל של התנגשות באוויר כפי שמוצג באיור 1 שנלקח ממסמך AMC RPAS.1309.
הפרדה והסגמנט המוטס
אישור לרמת בטיחות הגבוהה ביותר של רשות התעופה האמריקאית ה-FAA, DAL A, יקר מאוד ולכן הדבר ההגיוני המתבקש זה לאשר כל רכיב במערכת לרמה שנדרשת. כדי להמחיש טענה זו, אפשר לשקול מל״ט טיפוסי עם חבילת “Flight Stack” המחוברת לחבילה תקשורת “Communication Stack” המתקשרת עם תחנת הבסיס, כפי שנראה באיור 2.
חבילת תוכנת המל”ט, flight stack כוללת שלוש שכבות.
1. מערכת הפעלה זמן אמת. מערכת הפעלה זמן אמת מהווה את בסיס הקושחה המוטסת דרך הפשטת החומרה הבסיסית ומתן יכולות המקביליות. מערכות זמן אמת הינן קריטיות עבור בקרת טיסה, ביצועים ובטיחות תוך שהן מבטיחות כי משימות בקרת טיסה יושלמו בזמן קצוב וידוע מראש. מערכות אלו חיוניות עבור בטיחות וביצועי זמן קריטי של המל”ט.
2. תָוְוכָה התווכה הינה אוסף של כלים, מנהלי התקנים וספריות הקשורות לבקרת הטיסה. החבילה כוללת מנהלי התקנים שמטפלים בחיישנים וציוד היקפי אחר. התווכה מכילה גם ספריות בקרת טיסה כגון פרוטוקולים שליטה מרחוק, עזרי מתמטיקה ובקרת מסננים.
3. בקרת טיסה. שכבה זו מכילה רוטינות שליטה ובקרה ונושאים כמו הערכת מצב, בקרת טיסה, כיול מערכת, טלמטריה, בקרת מנוע והיבטים אחרים של בקרת טיסה.
מערכת זיהוי ומנע (Detect and Avoid) תיקבע באופן ברור על ידי כל השכבות האלו כדי לבצע תפקידה בצורה נכונה. עם זאת, פיתוח תוכנה כדי לקבל אישור ל-DAL A יקר ומערכת זיהוי ומנע לא תהיה תלויה בשכבת התקשורת ואולי אפילו לא בכל שכבת ה Flight Stack. קיימת אפשרות להפרדת הפונקציונליות של DAL A לאלמנטים פחות קריטיים של המערכת ואז לאשר אותם בהתאם.
כל עקרון ההקצאה של רמות שונות של קריטיקליות עבור הרכיבים השונים במערכת, מרמז על קונספט של הפרדה. ובצורה כזו שלא יהיה ניתן לסכן את המערכות הקריטיות ביותר ע”י מערכות עם פונקציות פחות קריטיות – ובכך לגרום למל”ט להיות פגיע יותר למתקפת סייבר. הדבר הזה דורש הפרדה כך שגם אם תהיה חדירה, המערכת בכללותה תהיה עדיין יעילה בהגנה אפילו אם הורידו את דרישות רמת דרישות האישור הבטיחותי לרמה הנדרשת עבור חבילת התקשורת מסיבות של נוחות.
מערכת הפעלה זמן אמת (RTOS) מבוססת ARINC-653
פתרון קיים, מדבר על שימוש במערכת הפעלה זמן אמת מתאימה. ARINC 653 (Avionic Application Standard Software Interface) הינו מפרט תוכנה למערכות הפעלה זמן אמת, אשר עושה שימוש בחלוקה למחיצות זמן ומרחב למערכות אוויוניקה הדורשות רמת בטיחות קריטית. המערכת מאפשרת אירוח של מספר יישומים של תוכנות שונות עם רמות קריטיקליות שונה על אותה חומרה בהקשר של ארכיטקטורת אוויוניקה מודולרית משולבת (IMA.)
סטנדרט התוכנה ARINC 653 מגדיר APplication EXecutive יצירת יישומים עבור מחיצות מרחב וזמן (time and space partition) בהם יישומים שונים אמורים לשתף מעבד יחיד עם זיכרון ולהבטיח כי יישום אחד לא יכול להביא לכשל של יישום אחר במערכת. כל מחיצה במערכת ARINC 653 מייצגת יישום נפרד ועצמאי המשתמש בזיכרון המוקצה וייעודי לו בלבד. באופן דומה, ה-APEX מתיר זמן ייעודי לכל מחיצה לבצע את המטלה שלה. כל מחיצה במערכת ARINC 653 תומכת בריבוי משימות.
איור 3 מציג את הארכיטקטורה הטיפוסית של המערכת LynxOS-178. כל אחת מהמחיצות מפעילה יישום של המערכת כאשר היישומים עצמם אינם מודעים לקיומם של היישומים האחרים למרות שהם יכולים לתקשר איתם לפי הצורך.
בקיצור, מפרט 653 ARINC דורש בידוד של יישומים כדי להתאים לדרישות DO-178 אשר מריצות יישומים עם רמות שונות של אבטחה כאשר הם רצים על מחשב המל”ט (איור 4.) זה הופך להיות יותר אטרקטיבי כאשר צריך לשקל את מנגנוני הבקרה הקשורים לבטיחות מטען קריטי.
גישה כזו הופכת מערכת תואמת ARINC 653 אידיאלית עבור מקטע התוכנה האווירית של המל”ט. אז נכון, אולי שימוש במערכת הפעלה כזו שנועדה להשיג אישור DO-178 יכולה להיחשב כ-over-kill, אבל מצד שני כל יישום רץ באותה סביבה כמו יישום אחר, והמערכת רצה בסביבה בטוחה ממתקפות סייבר.