در پروژه های فضایی از چه سیستم عاملی استفاده می‌شود؟
آژانس فضایی اروپا به‌تازگی مدارپیمایی خورشیدی را به فضا فرستاد. این کاوشگر قرار است سال‌های آینده را در یکی از ناخوشایندترین و خشن‌ترین محیط‌های منظومه‌ی شمسی یعنی نواحی مجاور خورشید بگذراند. مدارپیمای خورشیدی در طول مأموریت خود نسبت به سیاره‌ی عطارد، ۱۰ میلیون کیلومتر به خورشید نزدیک‌تر خواهد شد. درحالی‌که حتی دمای سطح عطارد در نزدیکی خورشید به ۴۵۰ درجه‌ی سانتی‌گراد می‌رسد.
مدارپیمای خورشیدی برای مقاومت در برابر دماهای بالا از پوشش محافظتی مخصوصی برخوردار است. این محافظ گرمایی تنها در صورتی از فضاپیما محافظت می‌کند که در جهت مستقیم به سمت خورشید قرار داشته باشد و از اطراف یا پشت کاوشگر محافظت نمی‌کند. به همین دلیل آژانس فضایی اروپا سیستم عاملی آنی (RTOS) را طراحی کرده است که با حداقل پیش‌نیازها اجرا می‌شود. در صورت بروز مشکل، مدارپیمای خورشیدی تنها ۵۰ ثانیه زمان دارد تا واکنشی نشان دهد. به‌گفته‌ی ماریا هرنک، سرپرست بخش سیستم‌های نرم‌افزاری پرواز در ESA: «ریبوت پلتفرم‌های این چنینی دقیقا ۴۰ ثانیه زمان می‌برد؛ اما در مجموع ۵۰ ثانیه زمان داریم تا مشکل را پیدا کنیم و مدارپیما را به وضعیت اولیه‌ی آن برگردانیم.»
درنتیجه سیستم‌عامل مدارپیمای خورشیدی تنها باید در ۵۰ ثانیه ریبوت و بازیابی شود وگرنه آتش می‌گیرد. فضاپیمایی مثل مدارپیمای خورشیدی در شرایط سخت با سیستم‌عامل‌های آنی هدایت می‌شود. عملکرد این سیستم‌عامل‌ها کاملا با عملکرد سیستم عامل‌‌های لپ‌تاپ‌های معمولی، متفاوت است. معیارهای بررسی ویندوز یا macOS نسبتا ساده هستند. سیستم‌عامل‌های معمولی، محاسباتی را انجام می‌دهند، اگر محاسبات صحیح باشد، وظیفه‌ی مدنظر به درستی انجام می‌شود.
اما سیستم‌عامل‌های پروژه‌های فضایی، محدودیت‌هایی دارند. برای مثال، محاسبات این سیستم‌ها دارای مهلت زمانی یا ضرب‌الاجل مشخصی است. در صورتی که مهلت زمانی برآورده نشود، وظیفه‌ی مدنظر شکست خورده یا از بین می‌رود. در پروازهای فضایی، عدم رعایت مهلت زمانی اغلب اوقات می‌تواند به‌معنی تبدیل فضاپیما به گویی از آتش یا قرار گرفتن آن در مداری نادرست باشد. در این سیستم‌ها تمام وظایف باید با دقتی بسیار بالا اجرا شوند.
بر اساس تعریف ساعتی، زمان به تیک‌های مستقل تقسیم می‌شود. به بیان ساده، سیستم‌عامل‌های فضایی هم به گونه‌ای طراحی شدند که هر وظیفه در مجموعه‌ی مشخصی از تیک‌های تخصیص‌یافته اجرا شود. برای مثال بارگذاری داده از سنسورها نیاز به سه تیک دارد یا چهار تیک به روشن کردن موتورها اختصاص می‌یابد. از طرفی به هر وظیفه اولویتی مشخص داده می‌شود؛ بنابراین وظیفه‌ای که در اولویت بالا قرار دارد می‌تواند از وظایف دیگر سبقت بگیرد. مهندس نرم‌افزار در این شرایط می‌داند در هر سناریوی مشخص باید کدام وظیفه را انجام دهد و چه مقدار زمان برای اجرای هر وظیفه لازم است.
در مقابل سرعت سیستم‌عامل‌های فضایی، سیستم‌عامل‌های متداولی مثل تلفن‌های هوشمند مدرن را می‌توان در نظر گرفت. برای مثال گوشی هوشمند آیفون XS مکس یا سامسونگ S10 پلاس از پرچم‌داران تلفن همراه هستند. هر دو تلفن قبل از تست ری‌استارت شدند و حافظه‌ی کش آن‌ها پاک شد. سامسونگ در مدت ۲ دقیقه و سی ثانیه و آیفون در مدت ۲ دقیقه و ۵۴ ثانیه کل اپلیکیشن‌های خود را بارگذاری کردند. در نوبت دوم تست، کل اپلیکیشن‌ها بسته شدند و بدون ری‌استارت یا پاکسازی رم باز شدند. ازآنجاکه اپلیکیشن‌ها هنوز در رم فعال بودند، گوشی سامسونگ در ۴۶ ثانیه و آیفون در ۴۲ ثانیه کل اپلیکیشن‌ها را بارگذاری کردند.
اما حتی اگر تلفن‌های هوشمند یادشده از سیستم‌عامل‌های آنی مشابه پروازهای فضایی برخوردار بودند، تغییری در زمان بارگذاری اپلیکیشن‌ها به وجود نمی‌آمد؛ زیرا زمان تنها مزیت سیستم‌عامل‌های فضایی نیست. مزیت دیگر این سیستم‌ها قطعیت است. برای مثال اگر بتوانید کریگ فدریگی (نایب رئیس ارشد بخش مهندسی نرم‌افزار اپل) را قانع کنید تا در یکی از تست‌های مقایسه‌ی سرعت تلفن همراه شرکت کند و سپس از او بخواهید مقدار زمان لازم آیفون برای تکمیل یک تست را پیش‌بینی کند احتمالا ایده‌ای نخواهد داشت. شاید هم در نهایت بگوید «سریع» یا به اندازه‌ی کافی سریع است، اما هیچ مقدار مشخصی از دقت آیفون ارائه نمی‌دهد. هیچ کدام از سیستم‌های iOS یا اندروید، سیستم‌های قطعی نیستند. تعداد معیارهای تأثیرگذار بر سرعت تلفن همراه گسترده‌اند و پیش‌بینی دقیق سرعت را عملا غیرممکن می‌سازند؛ اما اگر تلفن همراه‌با سیستم عاملی فضایی اجرا شود، مهندسی که به سیستم دسترسی داشته باشد می‌داند چه عاملی در یک توالی مشخص باعث افزایش سرعت شده و می‌تواند زمان لازم برای اجرای یک وظیفه را به‌طور دقیق محاسبه کند. نرم‌افزارهای فضایی هم کاملا قابل پیش‌بینی هستند و در مهلت‌های زمانی کاملا دقیقی اجرا می‌شوند.
در زمان پرتاب آپولو، سیستم عامل‌ها برای هر مأموریت سفارشی می‌شدند. قطعا بخشی از کدها مجددا مورد استفاده قرار می‌گرفتند. برای مثال، بخش‌هایی از نرم‌افزار پروژه‌ی آپولو به پروژه‌ی شاتل و اسکای لب راه پیدا کردند؛ اما بخش زیادی از کارها از صفر انجام می‌شدند. در نهایت ناسا سیستم عاملی از شرکت WindRiver را انتخاب کرد. این شرکت مستقر در آلامدای کالیفرنیا، سیستم عاملی آنی و تجاری به‌نام VxWorks را در سال ۱۹۸۷ منتشر کرد. با اینکه VxWorks اولین سیستم‌عامل آنی نبود، به سرعت به یکی از گزینه‌های محبوب طراحان مأموریت ناسا تبدیل شد.
اولین مأموریت VxWorks، کاوشگر قمری کلمنتاین بود که نام دیگر آن آزمایش علمی اعماق فضا است. به این ترتیب از اوایل دهه‌ی ۱۹۹۰ رویکرد ناسا به مأموریت‌های سنگینی مثل آپولو تغییر کرد. همه چیز به سرعت با بودجه‌ای کمتر و محدودتر توسعه یافت. عملکرد سیستم VxWorks به قدری خوب بود که به یکی از گزینه‌های مأموریت پت فایندر مریخ هم تبدیل شد.
سیستم‌عامل‌های جدید هم خالی از اشکال نیستند. برای مثال باگی مثل مشکل وارونگی اولویت، مشکلات زیادی را برای تیم کنترل زمینی ناسا به وجود آورد. سیستم پت فایندر پس از فرود به دلایل نامعلوم ریبوت شد و ارسال داده‌ها به زمین، به تأخیر افتاد. در نهایت سه هفته طول کشید تا مشکل پیدا شده و پس از ۱۸ ساعت رفع شود؛ در نهایت مشخص شد مشکل از عملکرد VxWorks بود.