بالاخره بعد از ۷ میلیارد دلار هزینه و ده سال زمان برای توسعه و طراحی موشک بدون سرنشین آریان ۵، مهندسین آژانس فضایی اروپا شاهد پرتاب موشک آریان ۵ در کورو گویان فرانسه خواهند بود. همه‌چیز آماده پرتاب بود. وضعیت هوا در سایت کورو برای پرتاب مناسب بود و هیچ مانعی برای انتقال پرتابگر به سکوی پرتاب وجود نداشت، به شکل خاص رعدوبرق وجود نداشت و میدان‌های الکترومغناطیسی اندازه‌گیری شده در سایت ناچیز بودند، تنها میدان دید باعث ایجاد نگرانی و عدم قطعیت در پرتاب‌شده بود که بعد از چند ساعت مسئله مرتفع شد.
بعد از یک بار کنسل شدن پرتاب (میدان دید) بالاخره در ساعت ۹ و ۳۳ دقیقه و ۵۹ ثانیه به‌وقت محلی احتراق موتور Vulcain و دو بوستر سوخت جامد شروع شد. آریان ۵ بعد از ۳۷ ثانیه پرواز به‌طور ناگهانی از مسیر خود خارج شد و درنهایت سیستم خود تخریبگر آریان ۵ فعال شد و موشک آریان ۵ به همراه دو ماهواره‌ای که حمل می‌کرد درمجموع به ارزش ۵۰۰ میلیون دلار منفجر شد.
۰٫۷ ثانیه آخر پرتاب یعنی درست ۳۶٫۷ ثانیه بعد از پرتاب، شروع زنجیره‌ای از اتفاقات بود که باعث فعال شدن سیستم خوب تخریبگر موشک شد. اما واقعاً چه اتفاقی افتاد، در ادامه به بررسی اتفاقی که برای آریان ۵ افتاد می‌پردازیم. در ۳۶ ثانیه اول پرتاب همه‌چیز به خوبی پیش رفت و مشکلی نبود، بعدازآن سیستم مرجع اینرسی (Inertial Reference System) از کار افتاد و به دنبال آن سیستم پشتیبان مرجع اینرسی نیز از کار افتاد، به دنبال آن سیستم کنترلر پرواز از کار می‌افتد و نازل موتور Vulcain به‌شدت تغییر جهت می‌دهد و باعث انحراف موشک از مسیر اصلی می‌شود، و درنهایت سیستم خود تخریبگر آریان فعال می‌شود.
اما علت انفجار موشک آریان ۵ چه بود؟
به‌طورکلی، سیستم کنترل پرواز آریان ۵ از یک طراحی استاندارد بهره می‌برد. موقعیت موشک و حرکات آن در فضا توسط سیستم مرجع اینرسی (SRI) اندازه‌گیری می‌شود، این سیستم پردازنده (کامپیوتر) داخلی خود را دارد که در آن سرعت و زاویه حرکت و کلی داده حرکتی دیگر را با استفاده از پلتفرم اینرسی نظیر ژیروسکوپ های لیزری و شتاب سنج محاسبه می‌شود، داده‌های SRI از طریق دیتابیس (برای خودم هم عجیبه که دیتابیس ولی در مقاله دقیقاً ذکرشده دیتابیس) به کامپیوتر داخلی کنترل پرواز منتقل می‌شود و با استفاده از داده‌های SRI نازل‌های سوخت جامد و موتور برودتی Vulcain را از طریق ولوهای سرو و محرک‌های هیدرولیکی کنترل می‌کند.
حال که با ساختار کلی کنترل پرواز موشک آریان ۵ آشنا شدیم، بیایید باهم به زنجیره اتفاقاتی که موجود شد مأموریت ۵۰۱ با شکست مواجه شود بپردازیم:
- موشک در ثانیه ۳۹ بعد از پرتاب به دلیل فشارهای زیاد آرودینامیکی و البته زاویه حرکت بیش از ۲۰ درجه شروع به متلاشی شدن کرد، که منجر به جدا شدن بوسترهای سوخت جامد و فعال شدن سیستم خود تخریبگر موشک شد.
- تغییر زاویه حرکت موشک به دلیل انحراف کامل نازل‌های تقویت‌کننده‌های سوخت جامد و موتور اصلی بود.
- انحراف نازل‌ها توسط نرم‌افزار OBC (on-board computer) و بر اساس داده‌های ارسال‌شده توسط مرجع اینرسی پشتیبان فرمان داده‌شده بود.
- عدم صحت داده‌های SRI2 یک خطای نرم‌افزاری بود (software exception)
- OBC نمی‌توانست از داده‌های SRI1 استفاده کند چراکه آن واحد در چرخه قبلی (۷۲ میلی‌ثانیه قبل) به همان دلیل SRI2 ازکارافتاده بود.
- خطای نرم‌افزاری رخ‌داده در SRI به دلیل تبدیل داده ممیز شناور ۶۴ بیتی به یک عدد علامت‌دار ۱۶ بیتی رخ‌داده بود، عدد ممیز شناور داری ارزشی بیشتر از 32767 بود و در پردازنده یک خطای Operand ایجاد شد. دستورالعمل‌های تبدیل داده (در کد Ada) از ایجاد خطای Operand محافظت نمی‌شوند.
- این خطا در بخشی از برنامه اتفاق افتاد که در هنگام بلند شدن پارامترهای مهمی را محاسبه می‌کند و بعدازآن کاربرد خاصی ندارد.
- عملیات هم‌ترازی به مدت ۵۰ ثانیه پس از شروع پرواز در آریان ۴ لازم است اما در آریان ۵ این زمان ۳ ثانیه اول پرواز است بااین‌حال این عملیات تا ۵۰ ثانیه ادامه داشته است.
با دقت در زنجیره بالا درمی‌یابیم که اگر برنامه برای آریان ۵ نوشته‌شده بود احتمالاً این اتفاق رخ نمی‌داد، چراکه در چند ثانیه اول پرواز موشک شتاب کمی دارد و احتمالاً خطای Operand اتفاق نمی‌افتاد، یا اگر خطای Operand هندل شده بود این اتفاق نمی‌افتاد.
در گذشته تبدیل اعداد اعشاری به صحیح و برعکس چالش کمپایلرها بود:
https://frama-c.com/2013/10/09/Overflow-float-integer.html
بسیار جالب بود
هرچند فکر میکنم الان هم همچنان به شکل چالش هستند اعداد اعشاری مخصوصا در سیستم های امبدد
بی گمان
در 99.9 درصد سیستمهای امبدد به اعداد اعشاری نیاز نمیشه و براحتی میشه با مقیاس کردن اعداد صحیح، از اعشار پرهیز کرد. اما بندرت در معادلات غیرخطی رنج دینامیکی بالایی لازمه که چاره ای جز استفاده از اعشار نیست. در این موارد حتما باید محاسبات را در همه حالتها بررسی کرد تا محدودیت های کمپایلر و پردازنده باعث گرفتاری نشوند.
https://www.st.com/resource/en/application_note/dm00047230-floating-point-unit-demonstration-on-stm32-microcontrollers-stmicroelectronics.pdf
اتفاقا همیشه از اعداد اعشاری فراری بوده ام، چون هم هزینه حافظه بالایی بر روی سیستم اعمال می‌کنند هم پردازش سنگینی دارند، تا جای ممکن سعی میکنم که محاسبات به ساده ترین شکل ممکن انجام بشه ولی خوب گاهی واقعا هیچ راه فراری نیست و مجبور به انجام محاسبات اعشاری هستیم ، هرچند که سخت افزار های جدید مجهز به واحد های fpu هستند با این حال ممکنه که سرعت محاسبات را جبران کنند ولی همچنان سعی میکنم روش سنتی خودم رو پیش بگیرم
🙂
این به
A million dollar bug
معروف هست …
خیلی هم بهش میاد 🙂
ممنون از شما.
ولی سطح توضیحات زیادی بالا بود?(مبحث سنگین بود).
خواهش میکنم، تازه سعی کردم تا جای ممکن ساده و گویا باشه
ولی خوب کلیت ماجرا مهمه که چطور این طورخطا ها توی پروژه های این چنین بزرگ پیش میآد