مغز شاتل‌های فضایی: نگاهی عمیق به سیستم‌های نرم‌افزاری و کامپیوتری ناسا - بخش اول

شاتل‌های فضایی ناسا، از کلمبیا تا آتلانتیس، فقط ماشین‌های عظیم آهنی نبودن؛ اونا یه شاهکار تکنولوژیک بودن که با قدرت ذهن بشر و چند خط کد به فضا پرواز کردن. تصور کن یه شاتل با سرعت ۲۸٬۰۰۰ کیلومتر بر ساعت دور زمین می‌گرده، توی جو مانور می‌ده و بعد با دقت روی باند فرود میاد. حالا فکر کن همه اینا با کامپیوتری انجام شده که حافظه‌اش از یه فلش USB امروزی هم کمتر بود! اینجاست که سیستم‌های نرم‌افزاری و کامپیوتری شاتل‌ها وارد داستان می‌شن: یه دنیای پیچیده از کد، سخت‌افزار و هوشمندی که هر خطاش می‌تونست یه مأموریت رو به فاجعه بکشونه.
توی این مقاله قراره سفری داشته باشیم به قلب این سیستم‌ها. از زبان برنامه‌نویسی خاص HAL/S که شاتل‌ها رو هدایت می‌کرد، تا کامپیوترهای قدیمی‌ای که مثل یه ارکستر هماهنگ کار می‌کردن. می‌خوام خطاهایی که نفس‌ها رو حبس کردن و درس‌هایی که ازشون گرفته شد رو باهم ببینیم. این نه فقط یه داستان فنیه، بلکه روایتی از تلاش بشر برای فتح فضاست با ابزارهایی که الان شاید ساده به نظر بیان. پس اگه کنجکاوی که بدونی چطور این غول‌های فضایی با چند خط کد زنده بودن، بیا با من همراه شو!

کامپیوترهای GPC - ستون فقرات شاتل‌ها

هر شاتل فضایی به پنج تا کامپیوتر IBM AP-101 مجهز بود که بهشون General Purpose Computers یا GPC می‌گفتن. اینا هسته مرکزی عملیات بودن و همه‌چیز، از پرتاب و کنترل مداری تا فرود، رو مدیریت می‌کردن. حالا فکر کن هر کدوم از این کامپیوترها فقط ۱ مگابایت حافظه و قدرت پردازش ۰٫۴ میلیون دستور در ثانیه داشتن. برای مقایسه، یه لپ‌تاپ معمولی امروزی هزاران برابر قوی‌تره!
چهار تا از این GPCها یه برنامه مشترک به اسم PASS (Primary Avionics Software System) رو اجرا می‌کردن و مدام با هم مقایسه می‌شدن. این طراحی "redundant" یعنی اگه یکی خراب می‌شد یا اشتباه می‌کرد، بقیه می‌تونستن تشخیص بدن و کار رو ادامه بدن. پنجمی اما یه نقش خاص داشت: فقط سیستم پشتیبان (Backup Flight System یا BFS) رو اجرا می‌کرد و برای مواقع اضطراری آماده بود.
این کامپیوترها توی شرایط سخت فضا کار می‌کردن: تشعشع کیهانی، دمای شدید و لرزش‌های وحشتناک. با این حال، ناسا طوری اونا رو ساخته بود که حتی با این محدودیت‌ها، دقتشون از دست نره. چطور؟ جواب توی نرم‌افزارهاییه که این سخت‌افزار ساده رو به یه ماشین فضایی تبدیل کرده بود. توی بخش بعدی، زبانی که این کدها رو شکل داد رو بررسی می‌کنیم.

HAL/S - زبان برنامه‌نویسی شاتل‌ها

ناسا برای شاتل‌ها نمی‌تونست سراغ زبان‌های معمولی مثل فورترن یا اسمبلی بره. به جاش یه زبان اختصاصی به اسم HAL/S (High-order Assembly Language/Shuttle) طراحی کرد که دهه ۱۹۷۰ توسط شرکت Intermetrics ساخته شد. این زبان انگار برای شاتل‌ها زاده شده بود: هم قدرتمند بود، هم بهینه برای سخت‌افزار محدود GPCها.
HAL/S برای سیستم‌های "بلادرنگ" (real-time) طراحی شده بود، یعنی می‌تونست توی کسری از ثانیه به تغییرات واکنش نشون بده؛ چیزی که توی فضا حیاتیه. مثلاً وقتی شاتل توی جو باید زاویه‌اش رو تنظیم می‌کرد، این زبان به برنامه‌نویس‌ها اجازه می‌داد زمان‌بندی دقیق دستورات رو کنترل کنن. یه نمونه کد ساده:

DCL THRUST VECTOR(3) FIXED;  
UPDATE THRUST WITH NEW_VALUES;  
SCHEDULE THRUST_ADJUST AT 0.1 SECONDS;  

اینجا یه بردار رانش تعریف می‌شه، با داده‌های جدید آپدیت می‌شه و بعد توی ۰٫۱ ثانیه تنظیم می‌شه.
یه ویژگی دیگه HAL/S، مدیریت خطاهاش بود. اگه یه متغیر از محدوده خارج می‌شد، خودش هشدار می‌داد. این برای شاتل‌ها حیاتی بود، چون یه خطای کوچیک می‌تونست فاجعه بیاره. حجم کدها هم کم نبود: PASS حدود ۴۰۰٬۰۰۰ خط کد داشت و BFS نزدیک ۱۰۰٬۰۰۰ خط. برنامه‌نویس‌ها باید این کدها رو طوری می‌نوشتن که توی ۱ مگابایت حافظه جا بشه و کند نشه. برای همین، تست‌ها و شبیه‌سازی‌ها گاهی ماه‌ها طول می‌کشید تا مطمئن بشن همه‌چیز بی‌نقصه. اما آیا واقعاً بی‌نقص بود؟ بیایم چندتا خطای واقعی رو ببینیم.

خطاهای نرم‌افزاری - لحظات نفس‌گیر

هرچند سیستم شاتل‌ها خیلی دقیق بود، اما خطاها گاهی خودشون رو نشون می‌دادن. یکی از معروف‌ترینش توی اولین پرتاب شاتل (STS-1، کلمبیا، ۱۹۸۱) بود. قرار بود ۱۰ آوریل پرتاب بشه، ولی ۲۰ دقیقه قبل از بلند شدن، سیستم قفل کرد. چهار تا GPC که PASS رو اجرا می‌کردن، باید همزمان باهم sync می‌شدن، ولی یه اختلاف یک میلی‌ثانیه‌ای توی زمان‌بندی همه‌چیز رو متوقف کرد.
مشکل از یه "race condition" توی کد HAL/S بود. یه بخش از برنامه که زمان‌بندی رو چک می‌کرد، به این شکل بود:

SYNC_CLOCKS:  
    READ MASTER_CLOCK INTO LOCAL_TIME;  
    IF LOCAL_TIME ≠ EXPECTED_TIME THEN HALT;  

یه تأخیر ریز توی انتقال داده باعث شد LOCAL_TIME مقدار قدیمی بخونه و سیستم فکر کنه یه جای کار خرابه. ناسا دو روز پرتاب رو عقب انداخت و با اضافه کردن یه بافر زمانی، مشکل رو حل کرد. این خطا نشون داد که حتی با تست‌های گسترده، شرایط نادر می‌تونن غافلگیرکننده باشن.
یه مورد دیگه توی STS-9 (۱۹۸۳) بود. وقتی شاتل کلمبیا برای فرود آماده می‌شد، دو تا GPC به‌خاطر مشکل سخت‌افزاری (شاید تشعشع کیهانی) از کار افتادن. BFS فعال شد، ولی یه باگ باعث شد یه جت کنترلی (RCS) بیش از حد روشن بمونه و شاتل یه چرخش ناخواسته بکنه. مشکل از یه متغیر بود که توی سوئیچ به BFS درست ریست نشده بود. خلبان‌ها با مهارتشون فرود رو نجات دادن، ولی ناسا بعدش کد BFS رو آپدیت کرد.
این خطاها درس‌های بزرگی داشتن: تست‌ها باید سخت‌گیرانه‌تر بشن و حتی سیستم‌های پشتیبان هم نیاز به دقت دارن.

BFS - خط دفاعی شاتل‌ها

Backup Flight System یا BFS مثل یه سپر اضطراری بود. اگه PASS به هر دلیلی از کار می‌افتاد، BFS با ۱۰۰٬۰۰۰ خط کدش کنترل رو می‌گرفت. این سیستم فقط برای کارهای ضروری طراحی شده بود: نویگیشن پایه، کنترل موتورها و فرود امن.
BFS توسط تیمی جدا از PASS نوشته شده بود تا باگ‌های مشترک نداشته باشن. حتی از نسخه کمی متفاوت HAL/S استفاده می‌کرد. توی کابین خلبان، یه دکمه به اسم "BFS Engage" بود که با زدنش، GPC پنجم فعال می‌شد و شاتل رو نجات می‌داد.
توی STS-9 دیدیم که BFS چطور وارد عمل شد، ولی همون باگ جت کنترلی نشون داد که سادگی BFS هم محدودیت‌هایی داره. ناسا بعدش مطمئن شد که هر وقت BFS فعال می‌شه، همه متغیرها از نو مقداردهی بشن. این سیستم یه فلسفه مهم رو یادآوری کرد: توی فضا، گاهی ساده نگه داشتن بهترین راه‌حله.

تست‌ها و شبیه‌سازی‌ها - نبرد با ناشناخته‌ها

ناسا نمی‌تونست ریسک کنه. برای همین قبل از هر مأموریت، هزاران ساعت شبیه‌سازی انجام می‌داد. توی مرکز Shuttle Avionics Integration Laboratory (SAIL) توی هیوستون، یه نسخه کامل از شاتل ساخته شده بود که همه سناریوها رو تست می‌کرد: از پرتاب توی طوفان خورشیدی تا فرود توی شرایط بحرانی.
هر خط کد بارها اجرا می‌شد تا مطمئن بشن هیچ باگی نیست. ناسا از رویکرد "correct-by-construction" استفاده می‌کرد، یعنی کدها رو طوری می‌نوشتن که از اول درست باشن. اما همون‌طور که توی STS-1 دیدیم، بعضی خطاها فقط توی لحظه واقعی خودشون رو نشون می‌دادن.
تست‌ها انقدر دقیق بود که گاهی یه مأموریت ماه‌ها عقب می‌افتاد. مثلاً قبل از STS-1، ناسا ده ها هزار بار پرتاب رو شبیه‌سازی کرد، ولی بازم اون باگ زمان‌بندی غافلگیرشون کرد. بعد از هر خطا، سناریوهای جدید به تست‌ها اضافه می‌شد تا دیگه تکرار نشه. این دقت باعث شد توی ۱۳۵ مأموریت شاتل، هیچ فاجعه‌ای مستقیماً به‌خاطر نرم‌افزار رخ نده.

مقایسه با امروز - شاتل‌ها در برابر فضاپیما های امروزی

حالا که شاتل‌ها بازنشسته شدن، فضاپیماهای مدرن مثل Crew Dragon اسپیس‌ایکس جای اونا رو گرفتن. تفاوتشون با شاتل‌ها مثل مقایسه یه ماشین‌حساب با یه سوپرکامپیوتره. Crew Dragon از پردازنده‌های چند هسته‌ای با گیگابایت‌ها حافظه استفاده می‌کنه و نرم‌افزارش با زبان‌های مدرن مثل C++ نوشته شده.
شاتل‌ها با ۱ مگابایت حافظه و HAL/S کار می‌کردن، ولی این محدودیت باعث شده بود ناسا روی دقت و بهینه‌سازی تمرکز کنه. توی سیستم‌های مدرن، قدرت پردازش اجازه می‌ده کدها پیچیده‌تر باشن و حتی هوش مصنوعی برای تصمیم‌گیری استفاده بشه. اما یه تفاوت بزرگ اینه که شاتل‌ها برای هر مأموریت دستی تنظیم می‌شدن، در حالی که فضاپیماهای جدید مثل Crew Dragon خودکارترن.
با این حال، شاتل‌ها یه میراث بزرگ گذاشتن: نشون دادن که با منابع کم هم می‌شه کارهای بزرگ کرد. این فلسفه هنوز توی طراحی سیستم‌های فضایی دیده می‌شه.