מטוס קרב בלי טייס: איך בונים מערכת עצבים למטוס שצריך להחליט לבד?

מ-Edge AI וניווט בסביבה ללא GPS ועד Tactical IMU, חיישני מיקום וטמפרטורה – האתגרים ההנדסיים מאחורי מטוס הקרב האוטונומי של הדור הבא

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

אבל בדור הבא של המטוסים הקרביים נוסף משתנה שמשנה כמעט את כל הארכיטקטורה:

ייתכן שלא יהיה טייס בקוקפיט.

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

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

זהו מעבר משמעותי מ-Automation ל-Autonomy.

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

ההבחנה הזאת הופכת משמעותית במיוחד בשדה הקרב המודרני. ב-Breaking Defense תוארה מגמה שבה מערכות בלתי מאוישות מבצעות יותר ויותר עיבוד וקבלת החלטות באמצעות Edge AI, על הפלטפורמה עצמה, כדי שיוכלו להמשיך לפעול גם בסביבה שבה GPS או התקשורת אינם זמינים באופן רציף.

גם בישראל הכיוון כבר גלוי בחלקו. משרד הביטחון הקים מנהלת ייעודית ל-AI ואוטונומיה, וב-2026 אף תיאר פריסה נרחבת של מערכות אוטונומיות בזירות שונות. התעשייה האווירית הציגה השנה את OPAL-NG, המשלבת Edge AI ומיועדת בין היתר ל-Manned-Unmanned Teaming ול-Collaborative Combat Aircraft – CCA.

כל זה מעלה שאלה הנדסית מעניינת:

אם המטוס צריך לקבל יותר החלטות בעצמו – מאיפה הוא יודע מה באמת קורה לו?

אלגוריתם AI יכול לנתח תמונת מכ"ם.

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

מערכת Mission Computer יכולה להחליט ששינוי בנתיב נדרש.

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

באיזו זווית אני נמצא?

באיזו מהירות אני מסתובב?

מה התאוצה שלי?

האם משטח ההיגוי הגיע למיקום שאליו הוריתי לו להגיע?

האם actuator מסוים מתחיל להתחמם?

האם המערכת שקיבלה פקודה אכן ביצעה אותה?

והאם הנתונים שאני מקבל עדיין אמינים?

במטוס מאויש יש עוד שכבה בתוך הלולאה הזאת: הטייס.

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

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

במילים אחרות:

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

והמערכת הזאת מתחילה בחיישנים.

המצלמה והמכ"ם מספרים למטוס מה נמצא מחוץ לו.

אבל שכבה אחרת של חיישנים צריכה לספר לו מה קורה בתוכו.

ה-IMU מספר כיצד הפלטפורמה נעה.

חיישני מיקום סיבוביים ולינאריים מספרים היכן נמצאים בפועל משטחי היגוי, actuators ומנגנונים אחרים.

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

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

כל אחד מהרכיבים האלה קטן ביחס למטוס.

אבל ביחד הם יוצרים דבר גדול בהרבה:

Machine State Awareness – היכולת של המכונה לדעת מה מצבה בכל רגע.

וזוהי אחת מדרישות היסוד לאוטונומיה אמיתית.

כי Autonomy אינה מתחילה בהחלטה.

היא מתחילה באיכות המידע שעליו ההחלטה מבוססת.

איור 1 – מערכת העצבים של מטוס קרב אוטונומי: ה־AI יכול לקבל החלטות, אך הוא תלוי בזרם רציף ואמין של מידע מה־IMU, מחיישני המיקום והטמפרטורה וממערכות ניטור ההספק. יחד הם מספקים למחשב המשימה תמונת מצב בזמן אמת על תנועת המטוס, מצב המפעילים ובריאות המערכות.

כשה-GPS נעלם: ה-IMU הופך לחלק קריטי מתמונת המצב

מטוס קרב אוטונומי אינו יכול לצאת למשימה מתוך הנחה ש-GPS יהיה זמין ואמין לכל אורך הדרך.

בסביבה מבצעית מודרנית, אותות GNSS עלולים להיות משובשים, מוסתרים או גרוע מכך – מזויפים באמצעות Spoofing.

ההבדל משמעותי.

ב-Jamming המערכת יכולה בדרך כלל להבין שאיבדה את אות ה-GNSS.

ב-Spoofing היא עלולה להמשיך לקבל נתוני מיקום שנראים תקינים – אבל אינם נכונים.

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

אחד החשובים שבהם הוא ה-Inertial Measurement Unit – IMU.

ה-IMU הוא "תחושת שיווי המשקל" של המטוס

IMU מודד באופן רציף את התנועה של הפלטפורמה באמצעות ג'ירוסקופים ומדי תאוצה.

הוא אינו צריך לשאול לוויין מה קרה למטוס.

הוא מודד את התנועה על המטוס עצמו.

נתוני Angular Rate ו-Acceleration משמשים את מערכות הניווט, הייצוב והבקרה כדי להעריך כיצד המטוס נע ומשנה את מצבו.

במערכת אמיתית, כמובן, ה-IMU אינו פועל לבדו. נתוניו יכולים להשתלב עם GNSS, מצלמות, Radar, Magnetometer, Barometer ומקורות נוספים באמצעות Sensor Fusion.

וזו נקודה חשובה: IMU אינו "תחליף ל-GPS".

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

וככל שהמשימה ארוכה יותר – שגיאות קטנות הופכות לגדולות

למערכת אינרציאלית יש מגבלה בסיסית: שגיאות מצטברות עם הזמן.

Bias קטן בג'ירוסקופ, רעש במדידה, שינויי טמפרטורה ושגיאות Scale Factor יכולים להשפיע בהדרגה על הערכת המצב.

לכן לא מספיק לשאול:

"האם יש במטוס IMU?"

השאלה ההנדסית היא:

איזה IMU?

בפלטפורמה טקטית צריך לבחון בין היתר:

• Bias Stability
• Angle Random Walk
• Scale Factor Error
• Bandwidth
• Data Rate
• Latency
• Noise
• Temperature Compensation
• Shock & Vibration Performance

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

באוטונומיה, Latency הופך לחלק מלולאת ההחלטה

כאן נכנס שינוי מעניין נוסף.

בעבר היה טבעי לחשוב על IMU בעיקר כחלק ממערכת הניווט או ה-Flight Control.

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

נניח שהמטוס מבצע תמרון בקצב סיבוב של:

60°/sec

מערכת מסוימת מקבלת נתון המתאר את מצב הפלטפורמה באיחור של 5 milliseconds.

בזמן הקצר הזה המטוס כבר הספיק להסתובב:

60 × 0.005 = 0.3°

לעומת זאת, ב-20 microseconds:

60 × 0.000020 = 0.0012°

המשמעות אינה שכל מערכת במטוס זקוקה בהכרח ל-20 µs latency.

אבל היא ממחישה עיקרון חשוב:

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

האלגוריתם יכול להיות מהיר מאוד.

המעבד יכול להיות חזק מאוד.

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

Tactical-Grade IMU: לא רק דיוק, אלא התנהגות בעולם האמיתי

זו הסיבה שבפלטפורמות כאלה מעניין לבחון Tactical-Grade IMU דוגמת משפחות ה-IMU של Gladiator Technologies.

לדוגמה, ב-LandMark™ 005 IMU ניתן להגיע לקצב נתונים של עד 10 kHz, רוחב פס של עד 600 Hz ו-Message Delay נמוך מ-20 µs, לצד ביצועים אינרציאליים המיועדים ליישומים טקטיים דינמיים.

אבל המספרים האלה אינם המטרה בפני עצמם.

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

וזה מחזיר אותנו לאוטונומיה.

The AI decides what to do.
The Tactical IMU tells it what the aircraft is actually doing.

אבל לדעת כיצד המטוס נע עדיין לא מספיק.

המחשב יכול להחליט לבצע פנייה ולשלוח פקודה למשטח היגוי.

עכשיו נשאלת שאלה אחרת לחלוטין:

איך הוא יודע שמשטח ההיגוי באמת זז למקום שאליו הוא נשלח?

איור 2 – כשה-GNSS אינו אמין, המידע האינרציאלי ממשיך לזרום: Tactical IMU מספק למערכות הניווט, ה-Sensor Fusion וה-Edge AI נתוני תנועה רציפים. בפלטפורמה דינמית, גם ל-Latency יש משמעות: בקצב סיבוב של 60°/s, השהיה של 5 ms מייצגת כבר שינוי זוויתי של 0.3°, לעומת 0.0012° בהשהיה של 20 µs.

המטוס נתן פקודה. איך הוא יודע שהיא באמת בוצעה?

נניח שמחשב בקרת הטיסה מחליט לבצע תמרון.

הוא מחשב את התגובה הנדרשת ושולח פקודה ל-actuator להזיז משטח היגוי לזווית מסוימת.

מבחינת התוכנה, הפקודה יצאה.

אבל מבחינת המטוס, זה עדיין לא אומר שהפעולה בוצעה.

ה-actuator יכול לנוע בדיוק למיקום שנדרש ממנו.

הוא יכול להגיע רק לחלק מהמהלך.

הוא יכול להגיב לאט מהצפוי.

יכול להיווצר חופש מכני.

ובמקרה של תקלה, הוא עלול גם לא לזוז כלל.

לכן במערכת Flight Control קריטית לא מספיק לדעת מה הייתה הפקודה.

צריך לדעת גם:

מה קרה בפועל?

Command אינו Feedback

זהו אחד העקרונות הבסיסיים של Closed-Loop Control.

המחשב שולח פקודה:

Commanded Position: 7.3°

חיישן מיקום מודד את המצב המכני בפועל:

Actual Position: 7.2°

כעת מערכת הבקרה יכולה להשוות בין השניים ולתקן את הפקודה בהתאם.

אבל אם החיישן מחזיר:

Actual Position: 3.1°

כאשר המחשב מצפה ל-7.3°, נוצר מידע חדש וחשוב הרבה יותר:

המערכת אינה מתנהגת כפי שהתבקשה.

במטוס אוטונומי, ההבדל הזה יכול להפוך מנתון הנדסי לנתון מבצעי.

כאן נכנסים חיישני Position

במערכות מכניות שונות ניתן למדוד תנועה באמצעות סוגים שונים של חיישנים.

Rotary Position Sensors מודדים תנועה זוויתית ויכולים לשמש במנגנונים סיבוביים, צירים ומערכות שבהן נדרש לדעת את הזווית בפועל.

Linear Position Sensors מודדים תנועה קווית ויכולים לספק Feedback על המהלך של actuator או מנגנון לינארי.

ביישום אווירי, הבחירה אינה מסתכמת רק בשאלה אם נדרש חיישן Rotary או Linear.

צריך לבחון גם Resolution, Accuracy, Linearity, Repeatability, Temperature Range, Vibration, Electrical Interface, Packaging – ולעיתים גם Redundancy.

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

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

המטרה היא לסגור את הלולאה:

Command → Actuator → Mechanical Movement → Position Measurement → Controller

ואז שוב:

Measure → Compare → Correct

אלפי פעמים במהלך המשימה.

ומה קורה כאשר שני חיישנים לא מסכימים?

במערכות Flight-Critical, לפעמים עצם קבלת נתון אינה מספיקה.

צריך לדעת אם אפשר לסמוך עליו.

נניח שמותקנים שני ערוצי Position Feedback על מנגנון קריטי.

Sensor A מדווח:

7.2°

Sensor B מדווח:

7.3°

המערכת מקבלת אינדיקציה סבירה לכך שהמדידה עקבית.

אבל אם פתאום מתקבל:

Sensor A:

7.2°

Sensor B:

11.8°

עכשיו נוצר אירוע אחר לחלוטין.

אחד משני החיישנים אולי טועה.

אולי קיימת תקלה בחיווט.

אולי קיימת בעיה מכנית.

ואולי מקור התקלה נמצא במקום אחר במערכת.

Redundancy אינה בהכרח רק "חיישן נוסף למקרה שהראשון יתקלקל".

היא יכולה לאפשר למערכת לבצע Cross-Checking, לזהות Disagreement ולהפעיל לוגיקת Fault Detection.

במערכת אוטונומית, זה חשוב במיוחד.

אין טייס שמרגיש שהמטוס "מושך" באופן חריג ומסתכל על המכשירים כדי להבין מה קרה.

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

כאן ה-IMU וחיישן המיקום מתחילים לדבר באותה שפה

וזה כבר נהיה מעניין יותר.

נניח שהמטוס פקד על משטח היגוי לנוע.

חיישן המיקום מדווח:

המשטח הגיע לזווית המבוקשת.

במקביל, ה-IMU מודד את התגובה הדינמית של המטוס.

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

כל חיישן רואה חלק אחר של המציאות.

ה-Position Sensor רואה את המנגנון.

ה-IMU רואה את התוצאה הדינמית של הפלטפורמה.

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

זהו כבר מעבר מ-Position Feedback פשוט ל-System-Level State Awareness.

אבל יש עוד סימן שיכול להופיע לפני הכשל

נניח שה-actuator עדיין מגיע למיקום המבוקש.

ה-Position Sensor אינו מזהה שום בעיה.

גם תגובת המטוס עדיין נראית תקינה.

אבל המנוע שמפעיל את המנגנון מתחיל לעבוד קשה יותר.

הטמפרטורה שלו עולה בהדרגה.

מבחינה פונקציונלית, המערכת עדיין עובדת.

מבחינה בריאותית, ייתכן שכבר מתחיל להתפתח כשל.

וכאן נכנסת שכבת החישה הבאה של המטוס:

Temperature Sensing.

איור 3 – Command אינו Confirmation: במערכת בקרת טיסה בחוג סגור, שליחת פקודה ל-Actuator אינה מספיקה. חיישני מיקום סיבוביים ולינאריים מודדים את המיקום בפועל ומחזירים Feedback לבקר, בעוד ה-IMU מודד את תגובת המטוס. השוואה בין הפקודה, המיקום והתגובה הדינמית מאפשרת בקרה מדויקת יותר, זיהוי תקלות ו-Redundancy.

המערכת עדיין עובדת – אבל האם היא מתחילה להיכשל?

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

רכיב אינו בהכרח עובר ברגע אחד מ-"תקין" ל-"תקול".

לעיתים הכשל מתחיל הרבה קודם.

מיסב מתחיל לייצר חיכוך גבוה יותר.

Actuator נדרש לזרם גבוה יותר כדי לבצע את אותה תנועה.

מנוע מתחמם.

Power Electronics פועלת בטמפרטורה גבוהה מהרגיל.

מחבר חשמלי מפתח התנגדות גבוהה.

ובכל אותו זמן, מבחינת מחשב המשימה:

המערכת עדיין עובדת.

הפקודה נשלחת.

ה-actuator מגיע למיקום הנדרש.

ה-Position Sensor מאשר זאת.

והמטוס ממשיך במשימה.

אבל משהו כבר השתנה.

טמפרטורה היא לא רק נתון סביבתי

כאשר מדברים על Temperature Sensor במערכת אווירית, קל לחשוב בעיקר על מדידת טמפרטורת הסביבה.

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

חיישנים יכולים לנטר, בהתאם לארכיטקטורת הפלטפורמה, אזורים כגון:

• Electric Motors
• Actuators
• Bearings
• Power Electronics
• Batteries
• Power Distribution
• Avionics
• Gearboxes
• Hydraulic Systems

המטרה אינה רק לדעת שכרגע קיימים, למשל, 72°C.

הנתון המעניין יותר יכול להיות:

למה הטמפרטורה עלתה מ-55°C ל-72°C כאשר תנאי העבודה כמעט לא השתנו?

כאן Temperature Monitoring מתחיל להפוך מ-"Measurement" ל-Health Monitoring.

לא רק הטמפרטורה – גם קצב השינוי שלה

נניח ששני actuators זהים פועלים בתנאים דומים.

Actuator A:

54°C → 56°C → 57°C

Actuator B:

54°C → 61°C → 69°C

שניהם עדיין נמצאים אולי בתוך תחום הטמפרטורה המותר.

אבל ההתנהגות שלהם אינה זהה.

מערכת Health Monitoring מתקדמת יכולה להסתכל לא רק על הערך המוחלט אלא גם על:

Rate of Change

Load

Duty Cycle

Ambient Temperature

Current Consumption

Historical Behavior

וכאן נוצר משהו מעניין מאוד מבחינת אוטונומיה.

המטוס כבר אינו רק שואל:

"האם המערכת עובדת?"

הוא מתחיל לשאול:

"האם המערכת מתנהגת כפי שמערכת בריאה אמורה להתנהג?"

זה הבדל גדול.

מחיישן טמפרטורה ל-Prognostics

ככל שמערכת אוספת יותר נתונים, ניתן להשתמש בהם לצורך Condition-Based Maintenance ואף כחלק מ-Prognostics and Health Management – PHM.

אין פירוש הדבר שחיישן הטמפרטורה לבדו יכול לחזות כשל.

הוא לא יכול.

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

לדוגמה:

Position Sensor
האם ה-actuator הגיע למיקום המבוקש?

Current Monitoring
כמה זרם נדרש כדי להגיע לשם?

Temperature Sensor
כמה חום נוצר במהלך הפעולה?

IMU
האם המטוס הגיב כפי שהיה צפוי?

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

אבל נניח שה-actuator עדיין מגיע למיקום הנכון, ובמקביל הזרם והטמפרטורה שלו עולים ממשימה למשימה.

עכשיו יש למערכת מידע שלא היה מתקבל מחיישן המיקום לבדו.

ייתכן שהמערכת עדיין מבצעית.

אבל ייתכן גם שמתפתח בה כשל.

במטוס ללא טייס, הנתון הזה יכול להשפיע על המשימה

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

נניח שמטוס אוטונומי נמצא בתחילת משימה ארוכת טווח.

אחד המפעילים מתחיל להציג Thermal Trend חריג.

אין עדיין Failure.

המערכת עדיין מתפקדת.

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

מה עושים?

ממשיכים במשימה כרגיל?

מפחיתים עומס על המערכת?

משנים את פרופיל הטיסה?

מעבירים פונקציה למערכת Redundant?

או מחליטים שהסיכון להמשך המשימה גבוה מדי וחוזרים?

אלו כבר אינן שאלות של חיישן טמפרטורה.

אלו שאלות של Autonomous Mission Management.

החיישן רק סיפק את העובדה הפיזיקלית שעליה ניתן לבסס החלטה.

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

חברת Variohm Group מציעה מגוון טכנולוגיות למדידת טמפרטורה, לרבות RTD, Thermistor ופתרונות Temperature Sensing מותאמים ליישום.

אבל גם כאן, בחירת החיישן אינה מתחילה בשאלה:

"איזה Temperature Sensor יש בקטלוג?"

היא מתחילה בשאלות הנדסיות:

מה אנחנו רוצים למדוד?

מהו טווח הטמפרטורה?

מהי מהירות התגובה הנדרשת?

היכן ניתן למקם את החיישן?

מהי המסה התרמית של נקודת המדידה?

איזו Accuracy נדרשת?

איזו עמידות נדרשת ל-Vibration, Shock ולסביבה?

והכי חשוב:

איזו החלטה המערכת אמורה לקבל מהמידע הזה?

כי במטוס אוטונומי, חיישן אינו מעניין בגלל המספר שהוא מודד.

הוא מעניין בגלל ההחלטה שהמספר הזה מאפשר לקבל.

עכשיו נחבר את הכול: המטוס צריך לדעת שהוא "פצוע"

עד עכשיו הסתכלנו על מערכות שונות בנפרד.

ה-IMU אומר למטוס כיצד הוא נע.

חיישני Position אומרים לו האם המנגנונים ביצעו את הפקודות.

חיישני Temperature יכולים להצביע על שינוי במצב התרמי של רכיבים ומערכות.

מערכת ההספק יכולה לספק מידע נוסף על זרם, מתח ותקלות חשמליות.

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

כי בשדה הקרב, הבעיה אינה תמיד רכיב שהפסיק לעבוד.

לפעמים המטוס נפגע.

לפעמים מערכת אחת מתחילה להידרדר.

לפעמים Sensor אחד משקר.

ולפעמים הדרך היחידה להבין מה באמת קרה היא להשוות בין כמה מקורות מידע שונים.

כאן מתחיל השלב הבא באוטונומיה:

Detect → Isolate → Reconfigure → Continue or Abort

או במילים פשוטות:

האם מטוס קרב אוטונומי יכול לדעת שהוא נפגע – ולהחליט אם הוא עדיין מסוגל להילחם?

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

המטוס נפגע. מי מחליט אם ממשיכים במשימה?

עד עכשיו עסקנו בעיקר בתקלות שמתפתחות בתוך מערכות המטוס.

אבל מטוס קרב אינו פועל במעבדה.

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

נניח שמטוס קרב אוטונומי נמצא עמוק בשטח אויב.

הוא סופג פגיעה.

המטוס עדיין טס.

אין אובדן מיידי של שליטה ואין בהכרח Sensor יחיד שמכריז:

AIRCRAFT DAMAGED

במקום זאת מופיעים סימנים.

ה-IMU מזהה שינוי בלתי צפוי בהתנהגות הדינמית.

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

חיישן טמפרטורה באזור מסוים מציג עלייה חריגה.

מערכת החשמל מזהה שינוי בצריכת הזרם או תקלה בענף מסוים.

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

כל אחד מהאירועים האלה, בפני עצמו, מספר רק חלק מהסיפור.

האתגר האמיתי הוא להבין:

מה קרה למטוס?

Detect → Isolate → Reconfigure

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

לאחר הזיהוי צריך לנסות לקבוע היכן נמצאת התקלה ומה משמעותה.

זהו העיקרון של Fault Detection and Isolation – FDI.

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

האם המנגנון באמת נמצא במיקום שגוי?

האם החיישן עצמו נכשל?

האם החיווט נפגע?

או שמדובר בתגובה פיזיקלית אמיתית של המטוס?

כאן Redundancy ו-Sensor Fusion מקבלים משמעות נוספת.

מערכת יכולה להשוות בין:

Sensor A מול Sensor B

Commanded State מול Measured State

Position Feedback מול IMU Response

Temperature Trend מול Electrical Load

המודל המתמטי של המטוס מול ההתנהגות בפועל

ככל שקיימים יותר מקורות מידע עצמאיים ואמינים, ניתן לבנות תמונת מצב טובה יותר.

המטרה אינה להגיע לוודאות מושלמת.

בשדה הקרב לעיתים אין ודאות מושלמת.

המטרה היא להגיע לרמת ביטחון מספקת כדי לקבל את ההחלטה הבאה.

השאלה אינה רק "מה התקלקל?"

השאלה המבצעית החשובה יותר היא:

מה המטוס עדיין מסוגל לעשות?

וזה שינוי מהותי.

ייתכן שמערכת אחת נפגעה, אבל הפלטפורמה עדיין מסוגלת לטוס.

ייתכן שיכולת מסוימת אבדה, אבל קיימת מערכת Redundant.

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

למשל, מערכת ניהול המשימה יכולה תיאורטית להגיע למסקנה:

Flight Capability: AVAILABLE

Navigation Confidence: DEGRADED

Thermal Condition: ACCEPTABLE

Mission Sensor: AVAILABLE

Communication: INTERMITTENT

במצב כזה, ההחלטה אינה בהכרח:

FAILURE → RETURN HOME

יכולות להיות אפשרויות נוספות:

Continue Mission

Continue with Restrictions

Change Flight Profile

Reduce Electrical / Thermal Load

Switch to Redundant Sensor

Reconfigure Navigation Sources

Transfer Task to Another Platform

Abort Mission

וזה כבר הרבה מעבר ל-Built-In Test רגיל.

זוהי Mission-Aware Fault Management.

המטוס צריך להבין לא רק את התקלה – אלא את משמעותה למשימה

נניח ששני מטוסים אוטונומיים סובלים מאותה תקלה בדיוק.

מטוס A נמצא 50 ק"מ מהבסיס לאחר שסיים את משימתו.

מטוס B נמצא 800 ק"מ מהבסיס, בדרך ליעד.

מבחינה הנדסית, התקלה זהה.

מבחינה מבצעית, היא אינה אותה תקלה.

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

לכן בעולם של Autonomy, Health Monitoring ו-Mission Management מתחילים להתחבר.

החיישנים אינם מקבלים את ההחלטה המבצעית.

אבל ללא מידע אמין מהם, למערכת שמקבלת את ההחלטה אין בסיס טוב לעבוד עליו.

Redundancy: לא תמיד צריך שניים מכל דבר

כשמדברים על שרידות, קל לדמיין שכל רכיב במטוס צריך להיות מוכפל.

בפועל, Redundancy יכולה להיות מורכבת הרבה יותר.

יכולה להיות Hardware Redundancy – שני חיישנים או יותר שמודדים אותו פרמטר.

יכולה להיות Analytical Redundancy – השוואת מדידה אחת למידע שניתן להסיק מחיישנים אחרים או ממודל המערכת.

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

למשל, אם מקור ניווט אחד הופך בלתי אמין, Sensor Fusion יכול לתת משקל גדול יותר למקורות אחרים.

אם Sensor אחד אינו מסכים עם שני מקורות בלתי תלויים אחרים, המערכת יכולה להפחית את רמת האמון בו.

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

זהו הבדל חשוב בין:

More Sensors

לבין:

Better System Awareness

המטרה אינה למלא את המטוס בחיישנים.

המטרה היא לבחור את המדידות הנכונות, במקומות הנכונים, ולתכנן ארכיטקטורה שיודעת להפוך אותן למידע שימושי.

ומה אם המטוס אינו לבד?

כאן אנחנו מגיעים לשלב הבא בהתפתחות.

מטוס קרב אוטונומי של הדור הבא עשוי לפעול כחלק מקבוצה: לצד מטוס מאויש, לצד Collaborative Combat Aircraft אחרים או כחלק ממערך מבוזר של פלטפורמות בלתי מאוישות.

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

נניח שמטוס אחד מאבד חלק מיכולת החישה שלו.

מטוס אחר בקבוצה עדיין מחזיק אותה.

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

פלטפורמה אחרת יכולה אולי לקבל חלק מהמשימה.

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

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

State.

איפה אני.

איך אני נע.

באילו מערכות אני יכול לסמוך.

מהי רמת הביטחון שלי בנתונים.

ואילו יכולות עדיין זמינות לי.

וזו אחת הסיבות לכך שהמעבר מ-Automation ל-Autonomy אינו מתחיל רק ב-AI.

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

Sensing → State Estimation → Health Assessment → Decision → Action

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

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

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

אוטונומיה דורשת כמעט את ההפך בכיוון פנימה:

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

הוא צריך להרגיש את התנועה שלו.

לדעת את מצב המנגנונים שלו.

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

לזהות חריגות חשמליות.

להבחין בין Sensor Fault לבין שינוי אמיתי בהתנהגות הפלטפורמה.

ולהבין האם תקלה מסוימת משנה את יכולתו להשלים את המשימה.

אפשר לקרוא לזה:

Platform Self-Awareness.

לא במובן של תודעה.

אלא במובן ההנדסי והמבצעי:

היכולת של הפלטפורמה לבנות תמונת מצב אמינה של עצמה – ולהשתמש בה כדי להמשיך לפעול.

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

המטוס האוטונומי לא בהכרח יטוס לבד

כשמדברים על מטוס קרב בלתי מאויש, קל לדמיין מטוס עצמאי שיוצא לבדו למשימה.

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

מטוס מאויש יכול לפעול לצד מספר פלטפורמות בלתי מאוישות – Collaborative Combat Aircraft (CCA) – כאשר כל אחת מהן מביאה איתה חיישנים, יכולות ומשימות שונות.

פלטפורמה אחת יכולה לשאת Sensor Payload.

אחרת יכולה לפעול כ-Communications Relay.

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

ואחרת יכולה לקבל משימה אחרת בהתאם למצב המבצעי.

הרעיון אינו בהכרח ליצור "מטוס רובוטי" שמחליף לחלוטין את מטוס הקרב המאויש.

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

אבל כדי שקבוצה כזאת תוכל לעבוד, כל פלטפורמה צריכה קודם לדעת משהו בסיסי:

מה מצבי שלי?

לפני שמשתפים מטרות – צריך לשתף State

נניח שמספר מטוסים בלתי מאוישים פועלים לצד מטוס מאויש.

אחד מהם מדווח:

NAVIGATION: HIGH CONFIDENCE

FLIGHT SYSTEMS: NOMINAL

MISSION SENSOR: AVAILABLE

COMMUNICATION: DEGRADED

מטוס אחר מדווח:

NAVIGATION: DEGRADED

FLIGHT SYSTEMS: NOMINAL

MISSION SENSOR: AVAILABLE

THERMAL STATUS: CAUTION

המידע הזה יכול להיות חשוב לא פחות ממיקומה של המטרה.

כי אם מערכת Mission Management רוצה להעביר משימה מפלטפורמה אחת לאחרת, היא צריכה לדעת לא רק מי נמצא קרוב יותר, אלא גם:

מי מסוגל לבצע את המשימה?

מי מחזיק Sensor מתאים?

מי נמצא במצב בריאותי טוב?

מי מחזיק מספיק אנרגיה או דלק?

באיזו פלטפורמה נתוני הניווט אמינים יותר?

ומי צריך אולי לצאת מהמבנה ולחזור?

כלומר, Autonomy קבוצתית מתחילה ב-Self-State Awareness של כל חבר בקבוצה.

ומה קורה כשהתקשורת אינה מושלמת?

זו נקודה קריטית.

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

האויב ינסה לשבש את התקשורת.

הטווח יכול להיות גדול.

Line-of-Sight יכול להשתנות.

Bandwidth יכול להיות מוגבל.

וחלק מהפלטפורמות עשויות להתנתק זמנית מהרשת.

זו אחת הסיבות לכך ש-Edge AI מקבל חשיבות גדולה.

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

המטוס יכול לעבד מידע מקומי, לבנות State Estimate, לזהות חריגות ולקבל החלטות מסוימות במסגרת הכללים שהוגדרו לו.

לרשת הוא אינו חייב לשלוח את כל ה-Raw Data.

הוא יכול, בהתאם לארכיטקטורה, לשתף מידע מעובד ורלוונטי יותר.

לדוגמה:

Position

Velocity

Heading

Navigation Confidence

Sensor Availability

System Health

Mission Capability

וזה מחזיר אותנו שוב לחיישנים.

Edge AI לא יכול לתקן Sensor Data גרוע

אפשר להתקין במטוס מעבד AI חזק מאוד.

אפשר להריץ עליו אלגוריתמים מתקדמים.

אפשר לתת לו Computer Vision, Target Recognition ו-Mission Planning.

אבל קיימת מגבלה בסיסית:

האלגוריתם אינו יודע יותר ממה שהמידע שמגיע אליו מאפשר לו לדעת.

אם נתוני התנועה מגיעים באיחור – הוא עובד עם State ישן.

אם Position Feedback אינו אמין – הוא אינו יודע בוודאות מה מצב המנגנון.

אם אין Thermal Monitoring במקום שבו הוא נדרש – המחשב אינו יכול לזהות מגמה שמעולם לא נמדדה.

ואם GNSS משובש ואין מקורות מידע נוספים שתוכננו להתמודד עם המצב – גם אלגוריתם מצוין עלול לקבל תמונת עולם שגויה.

לכן בעולם של Autonomous Systems קיים עיקרון פשוט:

Garbage In → Garbage Out

או בניסוח שמתאים יותר למטוס קרב:

Autonomy is only as good as the data feeding it.

Sensor Fusion הוא לא Sensor

המונח Sensor Fusion מופיע כמעט בכל דיון על מערכות אוטונומיות.

אבל חשוב להבין מה הוא אינו.

Sensor Fusion אינו חיישן קסם שמתקן כל בעיה.

הוא תהליך שמשלב מקורות מידע שונים כדי לבנות הערכה טובה יותר של מצב המערכת או הסביבה.

לדוגמה, מערכת ניווט יכולה לשלב מידע מ:

GNSS

IMU

Radar / EO

Barometer

Magnetometer

Terrain or Visual References

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

אותו עיקרון יכול להופיע גם ב-Health Monitoring.

Position Sensor מספר דבר אחד.

Temperature Sensor מספר דבר אחר.

מערכת החשמל מספקת נתון נוסף.

ה-IMU מודד את התוצאה הדינמית.

הערך הגדול נוצר כאשר המערכת יכולה להצליב את המידע.

לכן Sensor Fusion טוב מתחיל הרבה לפני האלגוריתם.

הוא מתחיל בבחירת החיישנים.

לא כל Sensor צריך להיות "הכי מדויק"

זו נקודה חשובה במיוחד למהנדסי מערכת.

קל להגדיר דרישה:

Give me the most accurate sensor available.

אבל בפלטפורמה אווירית, Accuracy היא רק משתנה אחד.

לעיתים חשובים לא פחות:

Latency

Bandwidth

Repeatability

Temperature Stability

Shock & Vibration

Size

Weight

Power Consumption

Electrical Interface

Redundancy

Reliability

Environmental Sealing

וכמובן:

Cost

חיישן בעל Accuracy מצוינת אבל Latency שאינו מתאים ללולאת הבקרה עלול להיות הבחירה הלא נכונה.

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

וחיישן מושלם מבחינה מטרולוגית, אבל גדול וכבד מדי, יכול להיות לא רלוונטי לחלוטין לפלטפורמה אווירית.

לכן בחירת Sensor לפלטפורמה אוטונומית היא למעשה System Engineering Trade-Off.

השאלה הנכונה אינה:

"מה החיישן הטוב ביותר?"

אלא:

"איזו מדידה נדרשת למערכת, באיזו איכות, באיזה קצב ובאילו תנאים – כדי שהיא תוכל לקבל את ההחלטה הנכונה?"

SWaP-C: כשהמילימטר והוואט מתחילים להשפיע על המשימה

במטוס קרב בלתי מאויש וחמקן, השאלה הזאת נעשית משמעותית אפילו יותר.

כל רכיב צורך נפח.

כל רכיב מוסיף משקל.

כל רכיב צורך הספק.

וכל Watt שנכנס למטוס הופך בסופו של דבר גם לחום שצריך לנהל.

זו הסיבה למונח:

SWaP-C – Size, Weight, Power and Cost

אבל בפלטפורמה חמקנית, SWaP-C אינו רק עניין של נוחות הנדסית.

הוא יכול להשפיע על טווח.

על Endurance.

על Payload.

על Thermal Management.

על Reliability.

ועל היכולת להכניס יותר פונקציות לתוך נפח מוגבל.

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

וכאן אנחנו מגיעים לפרדוקס מעניין:

ככל שהמטוס הופך אוטונומי יותר, הוא זקוק ליותר מידע.

יותר מידע דורש יותר Sensing, Processing ו-Communication.

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

האתגר של הדור הבא אינו רק לתת למטוס יותר חושים.

האתגר הוא לתת לו את החושים הנכונים, בלי שהמערכת העצבית עצמה תהפוך לנטל.

איור 6 – אוטונומיה לא פירושה לפעול לבד: במערך Manned-Unmanned Teaming, כל CCA/UCAV צריך להכיר את מצבו שלו – מיקום, אמינות הניווט, בריאות המערכות והיכולת המבצעית – לפני שהוא יכול לשתף מידע ומשימות עם פלטפורמות אחרות. גם כאשר התקשורת נפגעת, Edge Autonomy מאפשרת לפלטפורמה להמשיך לפעול במסגרת המשימה שהוגדרה לה.

מהנדסים אוטונומיה מהחיישן כלפי מעלה

אחרי שמדברים על AI, Sensor Fusion, CCA ו-Mission Management, קל לחשוב שהאתגר העיקרי של מטוס קרב אוטונומי נמצא בתוכנה.

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

מטוס מסתובב.

כנף מתעוותת תחת עומס.

מנגנון משנה מיקום.

מנוע מתחמם.

זרם עולה.

טמפרטורה משתנה.

מערכת נחשפת ל-Vibration ול-Shock.

והמחשב אינו יכול "לדעת" שום דבר מכל אלה אם לא קיימת דרך למדוד אותם.

לכן תכנון מערכת אוטונומית צריך להתחיל בשאלה בסיסית:

What does the aircraft need to know?

ורק אחר כך:

How are we going to measure it?

ארבע שכבות של Awareness

אפשר לחשוב על "מערכת העצבים" של הפלטפורמה דרך ארבע משפחות של מידע.

1. Motion Awareness – מה המטוס עצמו עושה?

כאן נמצאים ה-IMU ומערכות הניווט האינרציאליות.

הם מספקים מידע על Angular Rate ו-Acceleration, ומשמשים כחלק מתהליכי Attitude / State Estimation, Flight Control ו-Navigation.

בסביבה שבה GNSS עלול להיות Jammed או Spoofed, האיכות של המידע האינרציאלי מקבלת חשיבות נוספת.

ביישומים דינמיים במיוחד, גם פרמטרים כמו:

Bias Stability

Angle Random Walk

Bandwidth

Data Rate

Message Latency

Temperature Performance

יכולים להשפיע על איכות המידע שמגיע למערכות שמעל ה-IMU.

זו הסביבה שאליה מיועדים Tactical-Grade IMUs כדוגמת משפחות ה-IMU של Gladiator Technologies.

2. Position Awareness – איפה נמצאים המנגנונים בפועל?

המחשב יודע מה הוא ביקש.

חיישן המיקום מספר לו מה קרה בעולם המכני.

בהתאם למנגנון, ניתן להשתמש ב-Rotary Position Sensors למדידת זווית או ב-Linear Position Sensors למדידת מהלך.

היישומים אינם מוגבלים למנגנון יחיד.

Position Feedback יכול להיות רלוונטי למערכות Flight Control, מנגנוני פתיחה וסגירה, Steering, Servo Mechanisms, Antenna Positioning, Payload Mechanisms ומערכות מכניות נוספות שבהן נדרש לדעת את המיקום בפועל.

כאן Variohm Group מציעה מגוון טכנולוגיות למדידת מיקום סיבובי ולינארי, לרבות פתרונות Contacting ו-Contactless בהתאם לדרישות היישום.

בפלטפורמה אווירית השאלה אינה רק:

Rotary or Linear?

אלא גם:

מהו טווח התנועה?

איזו Accuracy נדרשת?

מהי ה-Repeatability?

מה קורה לאורך טווח הטמפרטורה?

איזו עמידות נדרשת ל-Shock ול-Vibration?

האם נדרשת Redundancy?

ומה קורה אם החיישן עצמו נכשל?

3. Thermal Awareness – איפה מתחיל להיווצר Stress?

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

חיישני RTD, Thermistor וטכנולוגיות Temperature Sensing אחרות יכולים להשתלב בניטור של:

Electric Motors

Bearings

Power Electronics

Avionics

Batteries

Gearboxes

Mechanical Assemblies

ומערכות נוספות שבהן שינוי תרמי עשוי להיות משמעותי.

גם כאן Variohm Group מציעה מגוון חיישני טמפרטורה ופתרונות מותאמים ליישום.

אבל כפי שראינו, הערך האמיתי אינו תמיד הטמפרטורה הרגעית.

לפעמים דווקא ה-Trend חשוב יותר.

רכיב שעובד היום ב-70°C אינו בהכרח פחות בריא מרכיב שעובד ב-55°C.

השאלה היא מה תוכנן עבורו, מהו העומס שלו – והאם ההתנהגות שלו משתנה לאורך זמן.

4. Electrical Awareness – מה קורה במערכת ההספק?

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

מטוס אוטונומי יכול להכיל מחשבי Mission, מערכות תקשורת, EW, Sensors, Navigation, Processing ו-Payloads – וכל אחת מהן תלויה באספקת חשמל אמינה.

תקלה בענף אחד אינה אמורה בהכרח להפיל מערכת שלמה.

לכן גם Circuit Protection, Power Distribution, Current Monitoring ו-Fault Isolation הם חלק מתכנון השרידות של הפלטפורמה.

מבחינה אוטונומית, המידע החשמלי יכול להפוך גם הוא ל-State Data.

לא רק:

Breaker Tripped

אלא:

איזו יכולת איבדתי בעקבות האירוע?

האם ניתן לבודד את הענף?

האם קיימת אספקה חלופית?

האם אפשר להמשיך במשימה עם Load מופחת?

כך מערכת החשמל מתחברת שוב ל-Mission Management.

החיישן הנכון אינו מתחיל במק"ט

וזו אולי אחת הנקודות החשובות ביותר למהנדס בתחילת תכנון.

כשלקוח מבקש:

"אני צריך Position Sensor."

זו עדיין לא דרישה הנדסית מלאה.

אותו דבר נכון לגבי IMU או Temperature Sensor.

כדי לבחור רכיב צריך להבין את היישום.

לדוגמה, עבור Position Sensor נרצה לדעת:

מה בדיוק נע?

Rotary או Linear?

מהו ה-Travel או Angle?

מהירות התנועה?

Accuracy ו-Resolution?

איזה Output נדרש?

מהו מתח ההזנה?

טווח הטמפרטורה?

Shock ו-Vibration?

מידות ומגבלות התקנה?

האם קיימת דרישת Redundancy?

מהו אורך החיים הנדרש?

וב-IMU, השאלות יהיו אחרות:

איזו רמת Bias נדרשת?

מהי הדינמיקה?

מהו Angular Rate Range?

איזה Bandwidth נדרש?

איזה Data Rate?

מהי Latency המותרת?

מהו טווח הטמפרטורה?

איזה Interface?

מהן דרישות ה-SWaP?

ובחיישן טמפרטורה:

מה מודדים?

איפה מודדים?

איזה טווח?

איזו Accuracy?

איזה Response Time?

איזה Probe או Housing?

איך מתקינים אותו?

ומה הסביבה המכאנית?

רק אחרי שעונים על השאלות האלה מתחילים לחפש מק"ט.

כי במטוס אוטונומי, Spec אחד כמעט אף פעם אינו מספר את כל הסיפור

IMU אינו "טוב" רק מפני שיש לו Bias נמוך.

Position Sensor אינו "טוב" רק מפני שיש לו Accuracy גבוהה.

Temperature Sensor אינו "טוב" רק מפני שהוא מסוגל למדוד עד 200°C.

כל אחד מהם נמצא בתוך מערכת.

ולכן צריך לשאול כיצד הנתון שלו ישפיע על:

Control Loop

State Estimation

Fault Detection

Sensor Fusion

Health Monitoring

Mission Management

זה בדיוק המקום שבו בחירת רכיב הופכת מ-Purchasing ל-System Engineering.

המטוס של הדור הבא יצטרך יותר מ-AI

סביר להניח שהכותרות על מטוסי הקרב של הדור הבא יעסקו ב-AI.

בחמקנות.

ב-Swarm.

ב-CCA.

ביכולת לטוס ללא טייס.

ובחימוש.

אבל מתחת לכל אלה קיימת שכבה הרבה פחות זוהרת – וקריטית לא פחות.

השכבה שמודדת את המציאות.

כי כדי שמטוס יוכל לקבל החלטה, הוא צריך קודם לקבל מידע.

כדי שיוכל לזהות תקלה, משהו צריך למדוד את החריגה.

כדי שיוכל לפצות על כשל, הוא צריך לדעת שהכשל התרחש.

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

לכן אפשר לתמצת את כל המאמר במשפט אחד:

The AI decides.
The sensors make sure it has something real to decide with.

או בעברית:

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

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

לסיכום: האוטונומיה מתחילה הרבה לפני ה-AI

מטוס הקרב האוטונומי של הדור הבא לא יהיה פשוט מטוס קרב שהוציאו ממנו את הטייס.

הוצאת האדם מהקוקפיט משנה את הדרישות מהפלטפורמה כולה.

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

וככל שמעבירים יותר החלטות אל ה-Edge, הדרישה למידע אמין, מהיר ורציף רק גדלה.

זו הסיבה ש-Autonomy אינה רק בעיית תוכנה.

מתחת ל-AI, ל-Sensor Fusion ול-Mission Computer נמצאת שכבה פיזית של חיישנים ומערכות הגנה שמחברת את האלגוריתם אל העולם האמיתי.

Tactical IMU מספק מידע על תנועת הפלטפורמה.

Rotary and Linear Position Sensors מספקים Feedback על מצבם האמיתי של מנגנונים.

Temperature Sensors מאפשרים להבין את התמונה התרמית ולזהות מגמות חריגות.

ו-Circuit Protection and Power Monitoring מסייעים להגן על המערכות, לבודד תקלות ולשמור ככל האפשר על רציפות תפקודית.

כל אחד מהם מודד משהו אחר.

ביחד הם עוזרים למטוס לענות על השאלה החשובה ביותר:

What is actually happening to me right now?

ורק אחרי שיש תשובה אמינה לשאלה הזאת אפשר לעבור לשאלה הבאה:

What should I do about it?

מתכננים את מערכת החישה של הפלטפורמה הבאה?

באמירוניק אנחנו עובדים עם מהנדסים כבר בשלב הגדרת הדרישות – מבחירת Tactical IMU של Gladiator Technologies, דרך חיישני מיקום סיבוביים ולינאריים וחיישני טמפרטורה של Variohm Group, ועד פתרונות Circuit Protection וניהול ההגנה החשמלית למערכות קריטיות.

המטרה אינה להתחיל ממק"ט.

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

כי במטוס אוטונומי:

The AI decides.
The sensors provide the reality.

שאלות נפוצות – FAQ

מה ההבדל בין מטוס אוטומטי למטוס אוטונומי?

מערכת אוטומטית (Automated) מבצעת בדרך כלל פעולות, מסלולים או כללים שהוגדרו מראש. מערכת אוטונומית (Autonomous) מסוגלת להשתמש במידע מהחיישנים ומהסביבה כדי להתאים את פעולתה למצב המשתנה, במסגרת המטרות, ההרשאות והמגבלות שהוגדרו לה.

מהו UCAV?

UCAV – Unmanned Combat Aerial Vehicle הוא כלי טיס בלתי מאויש המיועד למשימות לחימה. בניגוד ל-UAV המשמש בעיקר לתצפית או איסוף מידע, UCAV עשוי להשתלב במשימות תקיפה, לוחמה אלקטרונית, מודיעין, תמיכה בפלטפורמות אחרות ומשימות מבצעיות נוספות.

מהו Collaborative Combat Aircraft – CCA?

CCA הוא מושג המתייחס לפלטפורמות קרב אוויריות בלתי מאוישות שנועדו לפעול בשיתוף עם מטוסים מאוישים ופלטפורמות נוספות. הן עשויות לשאת Sensors, EW, Communications, Weapons או Payloads אחרים ולבצע משימות כחלק ממערך לחימה מבוזר.

מדוע מטוס אוטונומי צריך IMU אם יש לו GPS?

GPS/GNSS מספק מקור ניווט חיצוני מצוין כאשר הוא זמין ואמין, אך בסביבה צבאית הוא עלול להיות משובש באמצעות Jamming או מוטעה באמצעות Spoofing.

IMU – Inertial Measurement Unit מודד באופן מקומי את התאוצות והמהירויות הזוויתיות של הפלטפורמה ואינו תלוי בקבלת אות מלוויין. במערכת ניווט אמיתית משלבים בדרך כלל IMU עם GNSS ומקורות נוספים באמצעות Sensor Fusion.

האם IMU מאפשר למטוס לטוס ללא GPS?

IMU הוא רכיב חשוב בניווט בסביבת GNSS-Denied, אך הוא אינו פתרון קסם שמחליף GPS לזמן בלתי מוגבל.

שגיאות אינרציאליות מצטברות לאורך זמן. לכן מערכות ניווט מתקדמות עשויות לשלב IMU עם מקורות נוספים כגון Radar, EO/Visual Navigation, Barometer, Magnetometer, Terrain Referencing או מקורות ניווט אחרים.

ככל שביצועי ה-IMU טובים יותר, ניתן בדרך כלל לשמור על State Estimate איכותי יותר בין עדכונים ממקורות חיצוניים.

אילו פרמטרים חשובים בבחירת Tactical IMU ל-UAV או UCAV?

הבחירה תלויה ביישום, אך בין הפרמטרים החשובים ניתן למצוא Bias Stability, Angle Random Walk, Scale Factor, Angular Rate Range, Bandwidth, Data Rate, Latency, Noise, Temperature Performance, Shock & Vibration, Interface וכן Size, Weight and Power – SWaP.

לכן אין IMU אחד שהוא "הטוב ביותר" לכל פלטפורמה.

מדוע Latency של IMU חשובה במערכת אוטונומית?

Latency קובעת עד כמה המידע שמגיע למערכת הבקרה או העיבוד מייצג את מצב הפלטפורמה עכשיו ולא את מצבה לפני מספר אלפיות שנייה.

לדוגמה, בקצב סיבוב של 60°/s, השהיה של 5 ms מייצגת שינוי זוויתי של 0.3°. במערכות בעלות דינמיקה ולולאות בקרה מהירות, גיל המידע עשוי להיות פרמטר משמעותי בתכנון.

למה צריך חיישני מיקום במטוס אוטונומי?

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

Rotary Position Sensors ו-Linear Position Sensors מאפשרים למדוד את המיקום בפועל ולספק Closed-Loop Feedback. כך ניתן להשוות בין Commanded Position לבין Actual Position, לבצע תיקונים ולזהות חריגות או תקלות.

מה ההבדל בין Rotary Position Sensor ל-Linear Position Sensor?

Rotary Position Sensor מודד זווית או תנועה סיבובית.

Linear Position Sensor מודד מיקום או מהלך לאורך ציר ישר.

הבחירה תלויה במכניקה של המערכת, בטווח התנועה, בדיוק, במהירות, בתנאי הסביבה, בממשק החשמלי ובדרישות Reliability ו-Redundancy.

למה צריך חיישני טמפרטורה במטוס אוטונומי?

Temperature Sensors יכולים לשמש לא רק למדידת תנאי הסביבה אלא גם ל-Health Monitoring של מערכות ורכיבים כגון מנועים חשמליים, Bearings, Power Electronics, Batteries, Avionics ומכלולים מכניים.

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

מהו Sensor Fusion?

Sensor Fusion הוא שילוב מידע ממספר מקורות כדי ליצור הערכה אמינה יותר של מצב הפלטפורמה או סביבתה.

לדוגמה, מערכת ניווט יכולה לשלב GNSS, IMU ומקורות חישה נוספים. מערכת Health Monitoring יכולה להשוות בין Position, Temperature, Electrical Data ותגובת הפלטפורמה.

Sensor Fusion אינו מחליף חיישנים איכותיים – הוא תלוי באיכות ובאמינות המידע שמוזן אליו.

מהו Platform Self-Awareness במטוס אוטונומי?

אין הכוונה ל"מודעות עצמית" במובן האנושי.

בהקשר הנדסי, Platform Self-Awareness היא היכולת של המערכת לבנות תמונת מצב של עצמה: כיצד היא נעה, מה מצב המערכות שלה, אילו נתונים אמינים, האם קיימת תקלה ואילו יכולות עדיין זמינות.

מידע זה יכול לשמש Flight Control, Fault Management ו-Autonomous Mission Management.

האם מטוס אוטונומי יכול להמשיך במשימה לאחר תקלה?

עקרונית, ארכיטקטורה מתאימה יכולה לאפשר Fault Detection, Isolation and Reconfiguration.

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

היכולת בפועל תלויה כמובן בתכנון הפלטפורמה, ב-Redundancy, בסוג התקלה ובכללי המשימה שהוגדרו למערכת.

איך מתחילים לבחור חיישנים לפלטפורמה אווירית אוטונומית?

לא מתחילים במק"ט.

מתחילים בהגדרת מה המערכת צריכה לדעת ומה היא אמורה לעשות עם המידע.

לאחר מכן מגדירים Accuracy, Range, Bandwidth, Latency, Temperature, Shock & Vibration, Interface, SWaP, Reliability ו-Redundancy בהתאם ליישום.

רק לאחר שהדרישות ברורות ניתן לבחור את ה-IMU, חיישן המיקום, חיישן הטמפרטורה או פתרון ההגנה החשמלית המתאים.

מושגים שכדאי להכיר

UAV – Unmanned Aerial Vehicle
כלי טיס בלתי מאויש. מונח רחב הכולל פלטפורמות למשימות תצפית, מודיעין, תקשורת, לוגיסטיקה ולחימה.

UCAV – Unmanned Combat Aerial Vehicle
כלי טיס קרבי בלתי מאויש המיועד לביצוע משימות צבאיות כחלק ממערך לחימה.

CCA – Collaborative Combat Aircraft
פלטפורמת קרב בלתי מאוישת המיועדת לפעול בשיתוף עם מטוסים מאוישים ובלתי מאוישים אחרים.

MUM-T – Manned-Unmanned Teaming
שיתוף פעולה מבצעי בין פלטפורמות מאוישות ובלתי מאוישות.

Automation
ביצוע אוטומטי של פעולות או רצף פעולות שהוגדרו מראש.

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

Edge AI
הרצת אלגוריתמי AI על גבי הפלטפורמה עצמה, במקום להיות תלויים באופן מלא בעיבוד מרוחק או בקישור תקשורת רציף.

IMU – Inertial Measurement Unit
יחידת מדידה אינרציאלית המשתמשת בדרך כלל בג'ירוסקופים ובמדי תאוצה למדידת Angular Rate ו-Acceleration.

Tactical-Grade IMU
IMU בעל רמת ביצועים המיועדת ליישומים טקטיים שבהם נדרשים דיוק, יציבות ודינמיקה גבוהים יותר מפתרונות MEMS מסחריים בסיסיים.

Bias Stability
מדד ליציבות ה-Bias של החיישן לאורך זמן. פרמטר חשוב במיוחד בביצועים אינרציאליים.

ARW – Angle Random Walk
מדד לרעש בג'ירוסקופ ולתרומתו לשגיאה הזוויתית המצטברת לאורך זמן.

Bandwidth
טווח התדרים שבו החיישן מסוגל לעקוב אחר שינויים דינמיים באופן שימושי.

Data Rate
הקצב שבו החיישן מספק דגימות או הודעות נתונים למערכת.

Latency / Message Delay
הזמן בין המדידה או היווצרות המידע לבין זמינותו למערכת המשתמשת בו.

GNSS – Global Navigation Satellite System
שם כולל למערכות ניווט לווייניות כגון GPS, Galileo ו-GLONASS.

GNSS-Denied Environment
סביבה שבה לא ניתן להסתמך על GNSS לצורך ניווט, עקב חסימה, שיבוש, תנאי קליטה או גורמים אחרים.

Jamming
שיבוש אות רדיו במטרה להקשות או למנוע מהמקלט לקבל את האות האמיתי.

Spoofing
שידור אות מטעה שנועד לגרום למערכת להסתמך על מידע שגוי כאילו היה אות ניווט אמיתי.

Sensor Fusion
שילוב מידע ממספר חיישנים או מקורות מידע לצורך יצירת State Estimate אמין יותר.

State Estimation
הערכת מצבה של הפלטפורמה – למשל מיקום, מהירות, Orientation ומצב דינמי – על סמך מדידות ומודלים.

Rotary Position Sensor
חיישן למדידת זווית או מיקום סיבובי.

Linear Position Sensor
חיישן למדידת מיקום או מהלך לינארי.

Position Feedback
מדידת המיקום בפועל והחזרת המידע למערכת הבקרה לצורך השוואה לפקודה.

Closed-Loop Control
מערכת בקרה שבה התוצאה הנמדדת מוחזרת לבקר, המתקן את הפקודה בהתאם להפרש בין המצב הרצוי למצב בפועל.

Redundancy
שימוש במקורות, רכיבים או פונקציות חלופיים כדי לשפר Reliability, לאפשר Cross-Checking או להמשיך לפעול במקרה של תקלה.

FDI – Fault Detection and Isolation
זיהוי שקיימת תקלה וניסיון לבודד את הרכיב, החיישן או תת-המערכת שבה היא נמצאת.

PHM – Prognostics and Health Management
שימוש בנתוני מצב, מגמות ומודלים לצורך הערכת בריאות המערכת וזיהוי הידרדרות או סיכון לכשל.

Health Monitoring
ניטור מצבם של רכיבים ומערכות באמצעות נתונים כגון Temperature, Current, Position, Vibration ומדדים נוספים.

Platform Self-Awareness
בהקשר הנדסי: היכולת של הפלטפורמה לבנות תמונת מצב אמינה של תנועתה, בריאות מערכותיה והיכולות שעדיין זמינות לה.

Mission-Aware Fault Management
ניהול תקלות שבו לא בוחנים רק מה התקלקל, אלא גם כיצד התקלה משפיעה על היכולת להמשיך במשימה.

SWaP-C – Size, Weight, Power and Cost
ארבעת השיקולים המרכזיים של גודל, משקל, צריכת הספק ועלות. בפלטפורמות אוויריות הם משפיעים ישירות על Payload, Endurance, Thermal Management וארכיטקטורת המערכת.

Mission Computer
מחשב המבצע עיבוד וניהול של פונקציות הקשורות למשימה ומשלב מידע ממערכות שונות בפלטפורמה.

BIT – Built-In Test
יכולות בדיקה ואבחון המובנות במערכת לצורך זיהוי תקלות ומעקב אחר תקינותה.

Reconfiguration
שינוי באופן שבו המערכת משתמשת במשאבים, חיישנים או תתי-מערכות בעקבות תקלה או שינוי בתנאי המשימה.

Mission Continuity
היכולת לשמר חלק או את כל היכולת המבצעית גם לאחר תקלה, אובדן תקשורת או הידרדרות של מערכת מסוימת.