במציאות הביטחונית של השנים האחרונות, ובפרט מאז אירועי 07.10.23,
ברור יותר מאי פעם: עצמאות הנדסית וגמישות טכנולוגית אינן מותרות – אלא צורך מבצעי.
בפרויקטים צבאיים ומוטסים רבים, נקודת הכשל אינה הטכנולוגיה עצמה,
אלא הפער בין רכיב שעובד מצוין בסביבה אזרחית או תעשייתית,
לבין הדרישות הקיצוניות של סביבה מוטסת וצבאית.
מהנדסי מערכת בישראל נתקלים שוב ושוב באותה דילמה:
יש כרטיס או תת-מערכת שעובדים, מאומתים פונקציונלית, ולעיתים אף משולבים כבר בפלטפורמה קיימת –
אך אינם עומדים בדרישות הסביבה, התקינה או ההזנה החשמלית של מערכת מוטסת.
המערכת עצמה נכונה.
הטכנולוגיה מוכחת.
אבל הפלטפורמה – לא סולחת.
הפתרון האינטואיטיבי – ולמה הוא כמעט תמיד טעות
התגובה האוטומטית במצבים כאלה היא Redesign:
פיתוח מחדש של הכרטיס או המערכת כך שיעמדו מלכתחילה בכל הדרישות הצבאיות.
אלא שבפרויקט קיים, Redesign מלא הוא כמעט תמיד הבחירה היקרה והמסוכנת ביותר:
-
שינוי ארכיטקטורה גורר שינוי ממשקים
-
שינוי ממשקים גורר שינוי משתמש קצה (End User)
-
שינוי End User גורר תהליכי אישור והסמכה מחדש
-
וכל זה – עבור מערכת שכבר עובדת ומוכחת מבצעית
במציאות מבצעית, אין תמיד זמן, תקציב או סבלנות לשרשרת הזו.
הגישה החלופית: שדרוג והקשחה תוך שמירה על Form, Fit & Function
במקום לפתח מחדש, ניתן להעלות מערכת קיימת לדרגה צבאית,
תוך שמירה מלאה על התכנון המקורי:
-
אותו Form – אותם ממדים, מארז ומכניקה
-
אותו Fit – אותם קונקטורים ונקודות חיבור
-
אותו Function – אותה תקשורת ואותו תפקוד מערכתית
כלפי המערכת הכוללת – לא השתנה דבר.
אבל בפועל, הרכיב מתנהג כמו רכיב צבאי מוטס לכל דבר.
זו גישה שמאפשרת להכניס יכולת מבצעית חדשה,
בלי לפתוח מחדש תכנון, בלי לשבור אינטגרציה, ובלי להפעיל End User חיצוני.
מהם תחומי ההקשחה הנדרשים במערכות מוטסות
1. הקשחה סביבתית
מערכות מוטסות פועלות בתנאים שמערכות אזרחיות כלל אינן מתוכננות אליהם:
גבהים קיצוניים, טמפרטורות נמוכות, ויברציות ודרישות EMC מחמירות.
כרטיס שעובד היטב על הקרקע עלול להיכשל לחלוטין באוויר –
אלא אם הותאם מראש לסביבה הזו.
2. הקשחה חשמלית
רשתות הזנה מוטסות שונות מהותית מרשתות תעשייתיות:
מתחים, תדרים, transient events ותרחישי קצה מחייבים תכנון הגנתי שונה לחלוטין.
לעיתים נדרש גם מנגנון שמזהה אם המערכת פועלת על הקרקע או באוויר,
ומאפשר או חוסם פעולה בהתאם לאיכות ההזנה.
3. הקשחה תפעולית
במערכת מוטסת אין מקום ל”התנהגות לא מוגדרת”.
נדרשים מנגנוני Enable / Inhibit, Built-In Test (BIT) וניטור עצמי,
וכל זאת – מבלי להוסיף תלות בתוכנה מערכתית או בשינויים מערכתיים רחבים.
דוגמאות עקרוניות (ללא חשיפת פרויקטים)
-
שדרוג כרטיסי ניווט או מיקום מסביבה אזרחית לסביבה מוטסת, תוך שמירה מלאה על ממשקים ותקשורת
-
הוספת מנגנוני הגנה והפעלה חכמה למערכות רגישות בעת עבודה קרקעית
-
שילוב יחידות חלוקת מתח קומפקטיות להוספת מטענים ויכולות חדשות לפלטפורמות קיימות
-
הפצת אותות GPS, תזמון ו-1PPS למספר מערכות על אותו כלי, כולל התאמות רמות אות ובדיקת תקינות
בכל המקרים –
ללא שינוי ממשקי משתמש, ללא Redesign מלא, וללא השפעה על שאר המערכת.
מתי הגישה הזו מתאימה – ומתי לא
הגישה של שדרוג והקשחה מתאימה במיוחד כאשר:
-
קיימת מערכת עובדת עם מגבלות סביבתיות
-
שינוי End User אינו רצוי או אפשרי
-
נדרש פתרון מהיר וגמיש בקנה מידה קטן
-
נדרשת התאמה צבאית מבלי “לפתוח” מחדש את כל התכנון
לעומת זאת, בפרויקטים חדשים לחלוטין –
ייתכן ש-Design ייעודי מהתחלה הוא הבחירה הנכונה.
סיכום: יכולת הנדסית כחול-לבן, לא מוצר מדף
שדרוג אלקטרוניקה אזרחית למערכות מוטסות אינו תרגיל קוסמטי,
אלא יכולת הנדסית עמוקה המשלבת הבנה מערכתית, תקינה צבאית וסביבה מבצעית.
כאשר היכולת הזו קיימת מקומית –
בגוף הנדסי ישראלי קטן, גמיש ובלתי תלוי –
ניתן לחסוך זמן וכסף, להקטין סיכונים,
ולהכניס יכולת מבצעית חדשה בלי לשבור תכנון קיים.
ובמקרים רבים,
זה בדיוק ההבדל בין פרויקט שנתקע –
לבין יכולת מבצעית שמגיעה לשטח בזמן,
בהסתמכות על ידע, פיתוח וייצור כחול-לבן בישראל.