שני מחשבים, שתי אחריות

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

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

הממשק ביניהם

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

מודולריות

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

סימולציה — לא מותרות

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

לוגים

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

עדכונים בשטח

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

איזו גרסה טסה

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

רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.