مقاله, توصیه شده

چهارم ژوئن ۱۹۹۶ روزی که موشک آریان ۵ منفجر شد!

موشک آریان 5

بالاخره بعد از ۷ میلیارد دلار هزینه و ده سال زمان برای توسعه و طراحی موشک بدون سرنشین آریان ۵، مهندسین آژانس فضایی اروپا شاهد پرتاب موشک آریان ۵ در کورو گویان فرانسه خواهند بود. همه‌چیز آماده پرتاب بود. وضعیت هوا در سایت کورو برای پرتاب مناسب بود و هیچ مانعی برای انتقال پرتابگر به سکوی پرتاب وجود نداشت، به شکل خاص رعدوبرق وجود نداشت و میدان‌های الکترومغناطیسی اندازه‌گیری شده در سایت ناچیز بودند، تنها میدان دید باعث ایجاد نگرانی و عدم قطعیت در پرتاب‌شده بود که بعد از چند ساعت مسئله مرتفع شد.

بعد از یک بار کنسل شدن پرتاب (میدان دید) بالاخره در ساعت ۹ و ۳۳ دقیقه و ۵۹ ثانیه به‌وقت محلی احتراق موتور Vulcain و دو بوستر سوخت جامد شروع شد. آریان ۵ بعد از ۳۷ ثانیه پرواز به‌طور ناگهانی از مسیر خود خارج شد و درنهایت سیستم خود تخریبگر آریان ۵ فعال شد و موشک آریان ۵ به همراه دو ماهواره‌ای که حمل می‌کرد درمجموع به ارزش ۵۰۰ میلیون دلار منفجر شد.

۰٫۷ ثانیه آخر پرتاب یعنی درست ۳۶٫۷ ثانیه بعد از پرتاب، شروع زنجیره‌ای از اتفاقات بود که باعث فعال شدن سیستم خوب تخریبگر موشک شد. اما واقعاً چه اتفاقی افتاد، در ادامه به بررسی اتفاقی که برای آریان ۵ افتاد می‌پردازیم. در ۳۶ ثانیه اول پرتاب همه‌چیز به خوبی پیش رفت و مشکلی نبود، بعدازآن سیستم مرجع اینرسی (Inertial Reference System) از کار افتاد و به دنبال آن سیستم پشتیبان مرجع اینرسی نیز از کار افتاد، به دنبال آن سیستم کنترلر پرواز از کار می‌افتد و نازل موتور Vulcain به‌شدت تغییر جهت می‌دهد و باعث انحراف موشک از مسیر اصلی می‌شود، و درنهایت سیستم خود تخریبگر آریان فعال می‌شود.

اما علت انفجار موشک آریان ۵ چه بود؟

به‌طورکلی، سیستم کنترل پرواز آریان ۵ از یک طراحی استاندارد بهره می‌برد. موقعیت موشک و حرکات آن در فضا توسط سیستم مرجع اینرسی (SRI) اندازه‌گیری می‌شود، این سیستم پردازنده (کامپیوتر) داخلی خود را دارد که در آن سرعت و زاویه حرکت و کلی داده حرکتی دیگر را با استفاده از پلتفرم اینرسی نظیر ژیروسکوپ های لیزری و شتاب سنج محاسبه می‌شود، داده‌های SRI از طریق دیتابیس (برای خودم هم عجیبه که دیتابیس ولی در مقاله دقیقاً ذکرشده دیتابیس) به کامپیوتر داخلی کنترل پرواز منتقل می‌شود و با استفاده از داده‌های SRI نازل‌های سوخت جامد و موتور برودتی Vulcain را از طریق ولوهای سرو و محرک‌های هیدرولیکی کنترل می‌کند.

برای بهبود قابلیت اطمینان دو سامانه SRI با سخت‌افزار و نرم‌افزار دقیقاً یکسان تعبیه‌شده که به شکل موازی باهم کار می‌کنند، یکی از SRI ها در حالت فعال و دیگری در حالت آماده‌به‌کار است که در صورت ازکارافتادن SRI عملیاتی وارد عمل شود. به همین ترتیب دو سامانه کنترل پرواز (OBC) وجود دارد. طراحی SRI در آریان ۵ عملاً همان طراحی SRI در آریان ۴ است به‌ویژه در قسمت نرم‌افزاری.

حال که با ساختار کلی کنترل پرواز موشک آریان ۵ آشنا شدیم، بیایید باهم به زنجیره اتفاقاتی که موجود شد مأموریت ۵۰۱ با شکست مواجه شود بپردازیم:

  • موشک در ثانیه ۳۹ بعد از پرتاب به دلیل فشارهای زیاد آرودینامیکی و البته زاویه حرکت بیش از ۲۰ درجه شروع به متلاشی شدن کرد، که منجر به جدا شدن بوسترهای سوخت جامد و فعال شدن سیستم خود تخریبگر موشک شد.
  • تغییر زاویه حرکت موشک به دلیل انحراف کامل نازل‌های تقویت‌کننده‌های سوخت جامد و موتور اصلی بود.
  • انحراف نازل‌ها توسط نرم‌افزار OBC (on-board computer) و بر اساس داده‌های ارسال‌شده توسط مرجع اینرسی پشتیبان فرمان داده‌شده بود.
  • عدم صحت داده‌های SRI2 یک خطای نرم‌افزاری بود (software exception)
  • OBC نمی‌توانست از داده‌های SRI1 استفاده کند چراکه آن واحد در چرخه قبلی (۷۲ میلی‌ثانیه قبل) به همان دلیل SRI2 ازکارافتاده بود.
  • خطای نرم‌افزاری رخ‌داده در SRI به دلیل تبدیل داده ممیز شناور ۶۴ بیتی به یک عدد علامت‌دار ۱۶ بیتی رخ‌داده بود، عدد ممیز شناور داری ارزشی بیشتر از 32767 بود و در پردازنده یک خطای Operand ایجاد شد. دستورالعمل‌های تبدیل داده (در کد Ada) از ایجاد خطای Operand محافظت نمی‌شوند.
  • این خطا در بخشی از برنامه اتفاق افتاد که در هنگام بلند شدن پارامترهای مهمی را محاسبه می‌کند و بعدازآن کاربرد خاصی ندارد.
  • عملیات هم‌ترازی به مدت ۵۰ ثانیه پس از شروع پرواز در آریان ۴ لازم است اما در آریان ۵ این زمان ۳ ثانیه اول پرواز است بااین‌حال این عملیات تا ۵۰ ثانیه ادامه داشته است.

با دقت در زنجیره بالا درمی‌یابیم که اگر برنامه برای آریان ۵ نوشته‌شده بود احتمالاً این اتفاق رخ نمی‌داد، چراکه در چند ثانیه اول پرواز موشک شتاب کمی دارد و احتمالاً خطای Operand اتفاق نمی‌افتاد، یا اگر خطای Operand هندل شده بود این اتفاق نمی‌افتاد.

در سناریوی خرابی، دلایل فنی اولیه خطای Operand هنگام تبدیل متغیر بایاس افقی (BH) و عدم محافظت از این تبدیل است، برخی از تبدیل‌ها در مقابل خطای تبدیل محافظت‌شده‌اند و برخی از آنها محافظت نشده‌اند، زیرا حداکثر مصرف 80 درصد برای رایانه SRI تعیین‌شده بود. برای تعیین آسیب‌پذیری کد محافظت نشده، تجزیه‌وتحلیلی بر روی هر عملیاتی که می‌تواند منجر به استثنا شود، ازجمله یک خطای Operand انجام شد.
 
به‌طورخاص، تبدیل مقادیر ممیز شناور به اعداد صحیح مورد تجزیه‌وتحلیل قرار گرفت و عملیات شامل هفت متغیر درخطر منجر به خطای عملوند بود. بااین‌حال، سه تا از متغیرها بدون محافظت رها شدند. هیچ اشاره‌ای به توجیه این تصمیم نشده است.
دلیل محافظت نشدن سه متغیر باقیمانده، ازجمله متغیری که نشان‌دهنده سوگیری افقی است، این استدلال بود که نشان داد که آنها یا ازنظر فیزیکی محدود هستند یا حاشیه ایمنی زیادی وجود دارد، استدلالی که در مورد متغیر BH مشخص شد.
اگرچه دلیل عدم موفقیت مأموریت آریان ۵ خطای Operand ذکرشده است، اما این به‌خودی‌خود باعث شکست مأموریت نشد. مکانیزم رسیدگی به‌استثناء نیز به شکست کمک کرده است.
 

منبع 1، منبع 2، منبع 3

انتشار مطالب با ذکر نام و آدرس وب سایت سیسوگ، بلامانع است.

شما نیز میتوانید یکی از نویسندگان سیسوگ باشید.   همکاری با سیسوگ

بازگشت به لیست

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد.

8 دیدگاه در “چهارم ژوئن ۱۹۹۶ روزی که موشک آریان ۵ منفجر شد!

  1. احمدمحمدنژاد گفت:

    در گذشته تبدیل اعداد اعشاری به صحیح و برعکس چالش کمپایلرها بود:
    https://frama-c.com/2013/10/09/Overflow-float-integer.html

    1. Zeus ‌ Zeus ‌ گفت:

      بسیار جالب بود
      هرچند فکر میکنم الان هم همچنان به شکل چالش هستند اعداد اعشاری مخصوصا در سیستم های امبدد

      1. احمدمحمدنژاد گفت:

        بی گمان
        در 99.9 درصد سیستمهای امبدد به اعداد اعشاری نیاز نمیشه و براحتی میشه با مقیاس کردن اعداد صحیح، از اعشار پرهیز کرد. اما بندرت در معادلات غیرخطی رنج دینامیکی بالایی لازمه که چاره ای جز استفاده از اعشار نیست. در این موارد حتما باید محاسبات را در همه حالتها بررسی کرد تا محدودیت های کمپایلر و پردازنده باعث گرفتاری نشوند.
        https://www.st.com/resource/en/application_note/dm00047230-floating-point-unit-demonstration-on-stm32-microcontrollers-stmicroelectronics.pdf

        1. Zeus ‌ Zeus ‌ گفت:

          اتفاقا همیشه از اعداد اعشاری فراری بوده ام، چون هم هزینه حافظه بالایی بر روی سیستم اعمال می‌کنند هم پردازش سنگینی دارند، تا جای ممکن سعی میکنم که محاسبات به ساده ترین شکل ممکن انجام بشه ولی خوب گاهی واقعا هیچ راه فراری نیست و مجبور به انجام محاسبات اعشاری هستیم ، هرچند که سخت افزار های جدید مجهز به واحد های fpu هستند با این حال ممکنه که سرعت محاسبات را جبران کنند ولی همچنان سعی میکنم روش سنتی خودم رو پیش بگیرم
          🙂

  2. احسان گفت:

    این به
    A million dollar bug
    معروف هست …

    1. Sisoog Os Sisoog Os گفت:

      خیلی هم بهش میاد 🙂

  3. Mahdi.h   Mahdi.h   گفت:

    ممنون از شما.
    ولی سطح توضیحات زیادی بالا بود😅(مبحث سنگین بود).

    1. Zeus ‌ Zeus ‌ گفت:

      خواهش میکنم، تازه سعی کردم تا جای ممکن ساده و گویا باشه
      ولی خوب کلیت ماجرا مهمه که چطور این طورخطا ها توی پروژه های این چنین بزرگ پیش میآد