خطاي رايانشي كه 370 ميليون دلار خسارت بر جاي گذاشت / انفجار در اولين پرتاب آريان-5

[mahdavi3d 14,066]

[center][b][color=#800000][size=4][font=tahoma,geneva,sans-serif]انفجار اولين پرتاب پرتابگر آريان 5 [/font][/size][/color][/b][/center]
[center][b][color=#800000][size=4][font=tahoma,geneva,sans-serif]خطاي رايانشي كه 370 ميليون دلار خسارت بر جاي گذاشت[/font][/size][/color][/b][/center]

[center][size=3][font=tahoma,geneva,sans-serif][img]http://gallery.military.ir/albums/userpics/10198/V88_explosion_03.jpg[/img][/font][/size][/center]

[size=3][font=tahoma,geneva,sans-serif]در چهارم ژوئن سال 1996 اولین پرواز پرتابگر آریان-5 با شکست به پایان رسید. تنها 40 ثانیه بعد از شروع مراحل پرتاب در ارتفاع 3700 متری پرتابگر از مسیر خود منحرف و نابود شد. بلافاصله پس از سقوط تیم تحقیقی از طرف سازمان فضایی اروپا و CNES از افراد زیر تشکیل شد:[/font][/size]

[size=3][font=tahoma,geneva,sans-serif]پروفسور Jacques-Louis Lions از آکادمی علوم فرانسه (رئیس)، دکتر Lennart L.beck از شرکت فضایی سوئد (معاون)،آقای Jean-Luc Fauquembergue پیمان کار تجهیزات از فرانسه، آقای Gilles Kahn از انستیتو ملی تحقیقات کنترل و کامپیوتر فرانسه، پروفسور Ing. Wolfgang Kubbat از دانشگاه فنی دارمشتاد آلمان، دکتر Leonardo Mazzini از مرکز تحقیقات فضایی ایتالیا، آقای Didier Merle از شرکت معروف تامسون فرانسه و دکتر Colin O'Halloran از آزانس ارزیابی و تحقیق دفاعی انگلستان.
ازاین تیم تحقیقاتی موارد زیر خواسته شده بود:
• تعیین دلایل شکست در پرتاب
• تعیین اینکه آیا تستهای کیفیت و تاییده ها برای مشکل بوجود آمده کافی بوده اند یا خیر
• دادن پیشنهاد برای عملکرد درست در آینده برای اجتناب از نقاط ضعف و خطاهای ممکن.[/font][/size]

[url="http://gallery.military.ir/albums/userpics/10198/290px-Ariane_5_28mock-up29.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_290px-Ariane_5_28mock-up29.jpg[/img][/url]

[size=3][font=tahoma,geneva,sans-serif]تیم تحقیقاتی کارش را در 13 ژوئن 1996 آغاز کرد و از خدمات کمیته ای از مشاوران شامل دکتر Mauro Balduccini از (BPD) ، آقای Yvan Choquer از (Matra Marconi Space)، آقای Remy Hergott از(CNES) ، آقای Bernard Humbert از (Aerospatiale) و آقای Eric Lefort از (ESA) ، استفاده کرد.
علاوه بر این کمیته اعضای تیم Ariane-5 و اسناد آنها کمک شایانی به تیم تحقیق کرده بدیهی است که تیم تحقیق قادر به بررسی تمام جزئیات پروژه ای به عظمت ARIANE-5 نبوده است.[/font][/size]
[center]
[img]http://gallery.military.ir/albums/userpics/10198/501liftoff250_280.jpg[/img]
[size=3][font=tahoma,geneva,sans-serif]پرواز-501 پرتابگر آريان-5 / لحظه پرتاب پرتابگر 737 تني Ariane-5G[/font][/size][/center]
[size=3][font=tahoma,geneva,sans-serif][color=#800000][b][size=4]1. چگونگی حادثه[/size][/b][/color][/font][/size]

[size=3][font=tahoma,geneva,sans-serif][b]1.1. شرح ماجرا[/b]
پس از 10 سال زمان و 7 میلیارد دلار هزینه بالاخره سازمان فضایی اروپا مجهز به پرتابگری به نام آریان-5 شد که قادر بود دو ماهواره 3 تنی را بطور همزمان به فضا پرتاب کند تا اروپا به برتری در عرصه فضا دست یافته بتواند سود بیشتری از ایستگاه فضایی بین المللی ببرد و اروپا را در صنعت تجاری فضایی پیشتاز کند.آریان-5 از یک موتور اصلی وولکان با سوخت مایع کرایوژنیک (سوختی بسیار سرد که از مایع کردن گازها در دمای بسیار پایین بدست می آید (مانند هیدروژن مایع)) و دو بوستر سوخت جامد به عنوان شتابدهنده اولیه بهره می برد. پایگاه Kourou واقع در مستعمره گویان فرانسه برای این پرتاب انتخاب شد. علت این انتخاب علاوه بر آنکه به دلیل دور بودن از خاک اروپا باعث کاهش خطرات ناشی از چنین پایگاهی برای اروپایی ها می گردد، نزدیکی این محل به خط استوا است زیرا هرچه به خط استوا نزدیکتر باشیم حرکت وضعی زمین سرعت بیشتری دارد و در واقع با پرتابگر کوچکتری قادر به پرتاب محموله های سنگینتری به مدار مورد نظر هستیم زیرا پرتابگر ما دارای سرعت اولیه ناشی از حرکت زمین سریعتری است.(40 سال پیش نیز مکانی نزدیک بندرعباس به عنوان محل احداث پایگاه فضایی ایران که قرار بود اولین ماهواره خود را در سال 1981 میلادی به فضا پرتاب کند انتخاب گردید. در حالیکه نقاط دیگری که به خط استوا نزدیکتر هم باشند در ایران موجود بود) گویان منطقه ای در شمال شرق آمریکای جنوبی در همسایگی برزیل و سورینام و ونزوئلا است که کماکان به صورت مستعمره کشورهای هلند و انگلستان و فرانسه اداره می شود.به همین دلیل چند گویان مختلف وجود دارد، گویان فرانسه، گویان هلند، گویان انگلیس و ... یک لشکر پیاده لژیون خارجی فرانسه ماموریت حفاظت شدید ازپایگاه فضایی kourou در گویان فرانسه را دارد. پایگاه فضایی Kourou علاوه بر پرتابگرهای Ariane، پرتابگرهای سایوز را برای روسیه و پرتابگرهای وگا را برای ایتالیا به فضا پرتاب می کند.[/font][/size]

[size=3][font=tahoma,geneva,sans-serif]بر اساس شواهد ارائه شده به تیم تحقیق موارد زیر مشاهده شده است:
وضعیت نیمه ابری آب وهوا درصبح چهارم ژوئن سال 1996 برای پرتاب در منطقه Kourou قابل قبول بوده و به ویژه با توجه به اندازه گیری میدان الکتریکی موجود در سکوی پرتاب ریسک برخورد خطرناک صاعقه ناچیز بوده است. تنها میدان دید کاملا راضی کننده ومطابق استاندارد نبوده است. شمارش معکوس به دلیل سوخت گیری و نبود دید کافی در دقایق اولیه بازه زمانی مجاز پرتاب(ساعت 8 و 35 دقیقه)، به تعویق افتاد تا اینکه در ساعت 9 و 33 دقیقه و 59 ثانیه هنگامی که میدان دید به میزان مطلوبی رسیده بود، موتور اصلی وولکان و 2 بوستر سوخت جامد آن استارت شد و یک پرواز دقیق تا ثانیه 37 بعد از پرتاب رقم خورد. در این لحظه بود که ناگهان پرتابه از مسیر خود تغییر جهت داد و منفجر شد. بررسی اولیه داده های پرواز و تله متری (تله متری سیستمی رادیویی است که از طریق آن داده های مهم تصمیم گیری و پارامترهای مهم وضعیت پرتابه به مرکز پرتاب گزارش می شود علاوه بر پرتابگرهای ماهواره نمونه های مهندسی و حتی نیمه صنعتی موشکهای اکتیو نیز دارای سیستمی مشابه هستند) موارد زیر را نشان می دهد:
1. رفتار عادی پرتابگر تا ثانیه 36
2. ایجاد نقص در سیستم هدایت اینرسیایی پشتیبان بلافاصله پس از از کار افتادن سیستم اینرسیایی اصلی
3. چرخش خروجی نازلهای بوسترهای سوخت جامد و کمی بعد نازل موتور وولکان به نهایت درجه ممکن سبب انحراف ناگهانی پرتابگر از مسیر اصلی می شود
4. با جدایی اتصالات بین بوسترها و هسته اصلی پرتابگر، سیستم خودنابودی پرتابگر با صحت عمل می کند.
ریشه یابی حادثه خیلی سریع به سیستم کنترل پرواز و به ویژه سیستم اینرسیایی همگرا شد که بطور ناگهانی از ثانیه 36.7 بعد از پرواز از کار افتاد.

[b]1.2. داده های موجود[/b]
داده های موجود از 3 منبع تامین شده است
1. داده های دریافتی از سیستم تله متری که تا ثانیه 42 بعد از پرواز کماکان ارسال می شده است.
2. داده های بدست آمده از رادارهای دنبال کننده مسیر پرتابه
3. داده های بدست آمده از دوربینهای معمولی و مادون قرمز و بررسی قطعات بازیابی شده پس از سقوط
کلیه داده های تله متری به CNES در تولوز فرانسه برای تحلیل ارسال شد. این حادثه باعث خراب شدن چهره خوب ESA که با پروازهای موفق آریان-4 بدست آمده بود شد.(این اصل نظامی بی دلیل نیست که در لحظه پیروزی همواره احتمال شکست وجود دارد و فرمانده باید بیشترین دقت و کنترل را در این زمان داشته باشد)[/font][/size]

[size=3][font=tahoma,geneva,sans-serif][b]1.3. بازیابی قطعات پس از سقوط[/b]
قطعات پرتابگر متلاشی شده به دلیل انفجار در نزدیکی پایگاه و در ارتفاع 4000 متر همگی به زمین بازگشتند و در یک محدوده 12 کیلومتر مربعی گسترده شدند. عملیات بازیابی مشکل بود اما منجر به کشف هر دو سیستم اینرسیایی اصلی و پشتیبان شد که بررسی آنها و حافظه های EEPROM مخصوص ثبت وقایع در یافتن اینکه کدام یک از سیستمها زود تر از کار افتاده اند بسیار مفید واقع شد زیرا از روی داده های تله متری تشخیص قطعی میسر نبود.
1.4. موارد غیر عادی نامربوط به حادثه مشاهده شد
داده های تله متری مواردی از تغییرات نامناسب فشار هیدرولیک کنترلگرهای نازل موتور اصلی را با فرکانس 10 هرتز نشان می دهند که از ثانیه 22 شروع شده بود البته توضیحات خامی برای این تغییرات وجود دارد که با دقت بررسی شد به هر روی بعد از بررسیها مشخص شد که این تغییرات هر چند مهم هستند اما در بروز حادثه در ان لحظه نقشی نداشته اند.[/font][/size]
[center]
[img]http://gallery.military.ir/albums/userpics/10198/Ariane_501_Fallout_Zone_svg.png[/img][/center]

[size=3][font=tahoma,geneva,sans-serif][color=#800000][b][size=4]2. تحلیل حادثه[/size][/b][/color][/font][/size]

[size=3][font=tahoma,geneva,sans-serif][b]2.1. زنجیره پیشامدهای فنی[/b]
بطور کلی سامانه کنترل پرواز پرتابگر آریان-5 یک سیستم استاندارد است که جهت پرتابگر و حرکت آن در فضا با استفاده از یک سیستم اینرسیایی اندازه گیری می شود. این سیستم کامپیوتر مستقل خود را دارد که در آن زاویه ها و سرعتها بر اساس داده های دریافتی از پلتفرم اینرسی "Strap-down " که از ژیروسکوپهای لیزری و شتابسنجها استفاده می کند، محاسبه می شود. داده های بدست آمده در این سیستم از طریق باس داده به کامپیوتر اصلی که برنامه پرواز را اجرا می کند و نازلهای بوسترهای سوخت جامد و موتور وولکان سوخت مایع کرایوژنیک (سوخت مایع با دمای بسیار پایین مثلا هیدروژن مایع) را از طریق شیرهای سروو و کنترلگرهای هیدرولیک کنترل می کند. برای افزایش قابلیت اطمینان این سامانه از افزونگی 2 برابر در سطح تجهیزات حساس استفاده می کرد. دو سیستم اینرسیایی موازی با سخت افزار و نرم افزار مشابه در آن موجود است که یکی در حالت فعال و دیگری در حالت آماده به کار که بعنوان سیستم پشتیبان عمل می کند. سیستم پشتیبان هم به همراه سیستم فعال تمام محاسبات را انجام می دهد و فقط از نتایج محاسبات آن استفاده نمی شود و در صورت اینکه کامپیوتر پرواز تشخیص دهد که سیستم اصلی دچار اشکال شده، سیستم پشتیبان وارد مدار شده و از خروجی آن استفاده می گردد. به همین ترتیب 2 کامپیوتر پرواز وجود دارد و بسیاری دیگر از سیستمهایی از این دست دارای افزونگی دوبرابرهستند. طراحی سامانه اینرسیایی آریان-5 مشابه سامانه اینرسیایی است که درپرتابگر موفق آریان-4 مورد استفاده قرار گرفته بوده است به ویژه از نظر نرم افزار.(در سامانه آریان-5 حداقل در سطح مدارهای فرمان شاید به دلیل بسیار قدیمی بودن از Tripple Module Redundancy استفاده نشده و تنها وقوع خطای نادر در سخت افزار مد نظر قرار گرفته شده بوده است)[/font][/size]

[size=3][font=tahoma,geneva,sans-serif]بر اساس شواهد و داده های فراوانی که به دست تیم تحقیق رسید زنجیره پیشامدها ازآخر به اول در زیر آورده شده است:
• در ثانیه 39 پرتابگر شروع به از هم گسستن می کند زیرا بر اثر زاویه حمله بیش از 20 درجه بار ایروداینامیک زیادی به آن تحمیل می شود و بوسترهای سوخت جامد از طبقه اصلی جدا می شوند و به نوبه خود باعث فعال شدن سیستم خودنابودی پرتابگر می شوند.
• این زاویه حمله به دلیل چرخش ناگهانی خروجی نازلهای بوسترها و سپس موتور اصلی وولکان رخ داد
• چرخش نازلها به دلیل دستور کامپیوتر پرواز انجام شده بود که بر اساس داده های ارسالی از سیستم اینرسیایی شماره دو اتخاذ گردید. این داده ها در آن لحظه حاوی داده های مناسب پرواز نبودند بلکه بسته داده مربوط به الگوی تشخیص خطای سامانه اینرسیایی بودند که به اشتباه توسط کامپیوتر پرواز به عنوان داده های پروازی تفسیر شدند! (یعنی آقایان یک پروتکل ارتباطی ساده هم بین دو کامپیوتر نداشتند که معلوم کند کدام بسته داده است و کدام بسته دستور و ....).
• علت ارسال این داده ها به جای داده های پرواز به کامپیوتر پرواز آن بود که سامانه اینرسیایی دچار خطایی ناشی از وقوع یک Exception کنترل نشده بود.خطای Exception معمولا وقتی رخ می دهد که دسترسی به حافظه حفاظت شده بر اثر مقدار دهی اشتباه به اشاره گرها یا استفاده از اشاره گر مقداردهی نشده یا تقسیم بر صفر یا عدد ممیز شناور بزرگتر از سایز مقصد و ... داشته باشیم.
• کامپیوتر پرواز قادر به استفاده از سامانه اینرسیایی پشتیبان (سامانه شماره یک) نبود به این دلیل که آن سامانه نیز قبلا به همان Exception رسیده بود و از کار افتاده بود.
• Exception به دلیل تبدیل یک عدد 64 بیتی ممیز شناور به یک عدد صحیح 16 بیتی علامت دار بوجود آمده بود که حداکثر مقداری برابر 32767 و 32768- می توانست داشته باشد. این تبدیل باعث وقوع یک Operand Error در زبان برنامه سازی Ada شد. این دستورتبدیل در Ada از وقوع چنین خطایی حفاظت نشده بود اگرچه که دستورات مشابه در همان منطقه از برنامه همگی حفاظت شده بودند.
• خطا در قسمتی از برنامه رخ داد که تنها برای تنظیمات اولیه پلتفرم اینرسیایی "Strap-down "اجرا می شد و تنها زمانی نتایج معنی دار تولید می کرد که هنوز پرتابگر از روی زمین جدا نشده باشد و به محض اینکه از زمین جدا می شد دیگر بکار نمی آمد.
• روتین مربوط به تنظیمات برای 50 ثانیه بعد از شروع مود پروازکماکان فعال بوده بنابراین هنگام برخاستن پرتابگر کماکان به مدت 40 ثانیه فعال بوده است. این زمان بندی برای آریان-4 در نظر گرفته شده بوده که شتاب شروع حرکت کمتری داشته و به مسئولین اجاز متوقف کردن پرتاب را در لحظات اولیه می داده است و این امکان را فراهم می کرده که سیستم جهت یابی دوباره تنظیم شده و بدون نیاز به صرف زمان زیاد(حدودا نیم ساعت) عملیات شمارش معکوس در چند ثانیه قابل پی گیری مجدد باسد. اما وجود چنین روتینی ضرورتی برای آریان-5 نداشته است و در واقع یک برنامه اضافی محسوب می شده است.
• خطای Operand Error به خاطر مقدار بسیار بزرگ غیر منتظره که به دلیل سرعت غیر عادی افقی که در آن لحظه برای پرتابگر ثبت می شد، در روتین Horizontal Bias بوجود آمد.
• این عدد بزرگ بوجود آمده در متغیر BH برای آریان-5 به این خاطر بوده که نوع حرکت آریان-5 با آریان-4 در لحظات اولیه کاملا متفاوت بوده و مقادیر بیشتری به عنوان سرعت افقی برای آن ثبت میشد و آریان-5 شتاب بیشتری نسبت به آریان-4 داشت.[/font][/size]

[size=3][font=tahoma,geneva,sans-serif]تیم تحقیق با استفاده از شبیه ساز و مقادیر خوانده شده از حافظه های سامانه های اینرسیایی بازیابی شده، به سناریوی بالا رسید و گزارش تکمیلی آن در گزارش فنی آورده شده است. بنابراین اثبات می شود که رخ دادن موارد بالا منجر به بروز حادثه شده است.[/font][/size]
[center]
[img]http://gallery.military.ir/albums/userpics/10198/esa-x-1819eng_01.jpg[/img][/center]

[size=3][font=tahoma,geneva,sans-serif][b]2.2. شرحی بر سناریوی حادثه[/b]
علاوه بر خطای نرم افزاری، خطای مدیریتی و کیفیت بد تحویل گرفتن زیر سامانه ها از پیمان کار در بروز حادثه مشهود است. یک تبدیل داده ساده و ریختن آن در متغییری که جای کافی نداشته باعث خطای Arithmetic Overflow شده که کامپیوتر سامانه اینرسیایی را از کار می اندازد و منجر به یک سلسله خطاهای پی درپی و نابودی کل سامانه می گردد. فرض شده بوده است که چنین حالتی ممکن نیست رخ بدهد! زیرا قدر مطلق عدد منتقل شونده کوچک بوده است و به خاطر اینکه برای نرم افزارکامپیوتر سامانه اینرسیایی محدودیت استفاده از حداکثر 80% توان پردازشی پردازنده آن را تعریف کرده بودند!!! بنابراین همه محاسبات و تبدیلها از محافظت برخوردار نشدند!!! در تست آسیب پذیری نرم افزار معلوم گردید که تنها 7 محاسبه و تبدیل وجود دارد که ممکن است ایجاد مشکل بکنند و از این 7 نقطه خطرناک تنها 4 نقطه حفاظت شده و از حفاظت بقیه به دلیل کاهش بار پردازنده صرف نظر شده است!!! سامانه اینرسیایی با داده های شبیه سازی پرواز آریان-5 تست نشده و از آن مهمتر مشخصات پروازی آریان-5 به عنوان مشخصات و الزامات طراحی سامانه اینرسیایی برای پیمان کار تعریف نشده بوده است. گرچه وقوع خطای Exception عامل اصلی بروز حادثه تشخیص داده شده اما ساز و کار برخورد با این خطا هم خالی از عیب و ایراد نبوده به طوری که برای الزامات این سامانه تعریف کرده بودند در صورت بروز هر گونه Exception ، کد خطا باید در باس داده ظاهر شود، سپس در یک حافظه EEPROM ذخیره شود(که در نهایت توسط تیم تحقیق بازیابی و خوانده شد) ودر نهایت پردازنده سیستم اینرسیایی باید خاموش گردد!!! . الزامی که تنها برای تست سیستم ممکن است معنی داشته باشد و برای نسخه عملیاتی آن باید حذف می شده است یا به نحو دیگری کنترل می شده است. تصمیم گرفته بودند که پروسسوری را که دچار مشکل شده خاموش کنند نه RESET زیرا محاسبه جهت صحیح در صورت RESET شدن بی نهایت برای دوباره محاسبه کردن مشکل بوده است.بنابراین سامانه اینرسیایی بی فایده شد. علت پشت این نوع طراحی فرهنگ حاکم بر تیم طراحی بوده که فقط به خطاهای سخت افزاری اتفاقی توجه داشته و برای نرم افزار اصولا ارزش کمی قائل بوده است. از این نقطه نظر اگر بر فرض محال یک کامپیوتری دچار مشکل سخت افزاری شد،خیلی ساده خاموشش کرده و از سیستم پشتیبان استفاده می کنیم!! با وجود این خطای نرم افزاری اگر مدیریت خطا به گونه ای بود که سیستم به کار خود ادامه می داد می توانست اثر بروز خطا را کاهش داده و کنترل کند و دو سامانه حساسی را که از نظر سخت افزاری سالم بودند بطور همزمان از دست نمی دادیم. مسئله دیگری که در این حادثه وجود دارد استفاده از روتینی است در سامانه اینرسیایی که متعلق به زمان آماده سازی طولانی آریان-4 یوده و دیگر در آریان-5 موضوعیت نداشته است. فرهنگ اروپایی نهفته در پشت این خطا نیز این اندیشه است که "به سیستم نرم افزاری که جواب داده دست نزن مگر اینکه دلیل محکمی داشته باشی" که کاملا غلط است. فاجعه بار اینکه روتین تنظیمات سامانه جهت یابی نیازمند بی حرکت بودن پرتابگر است و اجرای آن در زمان حرکت هیچ منطقی نمی تواند داشته باشد زیرا در این صورت تنظیم قطعات مکانیکی و لیزر پلتفرم Strap-down برای پیدا کردن شمال زمین از روی حرکت چرخشی زمین و تنظیم محور x بر روی محور جاذبه نیازمند محاسبات پیچیده ای است که در زمان حرکت مختل می شود زیرا حرکات اندازه گرفته شده پرتابگر به عنوان داده های سنسورها تفسیر می گردد که کل محاسبات را خراب می کند.
تیم تحقیق اصرار دارد که نرم افزار یک طراحی بسیار پیچیده و دارای جزئیات فراوان است و نباید با آن مانند یکی از زیر سامانه های مکانیکی برخورد شود و به دلیل انعطاف پذیری و پیچیدگی فوق العاده ارزیابی آن مشکل است و باید معیوب فرض شود تا اینکه دلایل محکمی بر صحت آن وجود داشته باشد.[/font][/size]

[size=3][font=tahoma,geneva,sans-serif][b]2.3. روالهای تست و تحقبق کیفیت[/b]
تستها در آریان -5 به این گونه بوده است
• تست کیفیت تجهیزات
• تست نرم افزار کامپیوتر اصلی!!!
• تست اتصال صحیح مراحل پرتابگر
• تستهای سیستم
ایده این بوده که در هر سطح آنچه که در سطح قبلی قابل تست نبوده تست شود تا به این صورت در انتها همه چیز تست شده باشد و پوشش کافی به زیر سامانه ها داده شود.با این حال هیچ تستی که شمارش معکوس و مراحل اولیه پرتاب را برای سامانه اینرسیایی معادل سازی کند انجام نشد و تنها به جای سامانه اینرسیایی یک نرم افزار شبیه ساز گذاشته و برنامه کامپیوتر پرواز(اصلی) را تست کردند. در واقع داده های پروازی آریان-5 در الزامات عملکردی سامانه اینرسیایی سپارش داده شده به پیمان کار قرار نداشته است و پیمان کار تنها به تستهایی جهت اطمینان از اتصال مناسب به کامپیوتر پرواز و سطوح سیگنالها بسنده کرده بوده است. در حالی که در هر سطح ازتست باید تمام زیر سیستمها حاضر باشند و تنها در صورتی که در آن سطح قابل کار نباشند توجیه دارد که با یک شبیه ساز تعویض گردند تا دیگر زیر سیستمها از آن سطح تست محروم نگردند. به ویژه تست نهایی سیستم بسیار مهم است که همه زیر سیستمها در آن حضور داشته باشند. دلیل حذف تست سامانه اینرسیایی از تست نهایی کل سیستم ماهیت این سامانه است که برای تست نیاز به حرکت دارد که یا باید از میزهای متحرک بسیار گرانقیمت استفاده می کردند و یا اینکه از یک نرم افزار شبیه ساز حرکت که در طرح اولیه مورد دوم انتخاب شده بود که آن هم به دلیل کندی شبیه ساز به دقت یک میلی ثانیه مورد نیاز نرسید تا بتواند سیستم را در چرخه تست مرتبط با کامپیوتر پرواز قرار بدهد به همین دلیل از تست نهایی کل سیستم کنار گذاشته شد. با اینکه این دلایل از نظر فنی قابل قبول است اما از نظر تیم تحقیق سامانه ای با اهمیت بالا مانند این نباید به تنهایی تست می شده و به جواب دادن آن در آریان-4 اکتفا می شده است زیرا انجام تست نهایی سیستم تنها به منظور تحقیق صحت ارتباطات بین اجزا نیست بلکه برای تحقیق صحت کارکرد سیستم به عنوان مجموعه ای از تمامی اجزا است و نباید زیر سیستمی به اهمیت سامانه اینرسیایی از تست کنار گذاشته می شده است. تیم تحقیق بر این نظر است که بهتر بود در شبیه سازی و تست نهایی کل سیستم همه اجزا در کنار هم تست می گردید و دقت فدای تست یکپارچگی می شد و در فاز دیگری دقت سامانه اینرسیایی به صورت جداگانه تست می گردید. به نظر تیم تحقیق نقص در بازبینی مراحل کار و تستهای انجام شده و کدهای نوشته شده، توسط داوران و ناظرین پروژه به بروز حادثه کمک کرده است.(ولی متخصصین نرم افزار بروز نقص را در طراحی اشتباه سیستم در سطح بالا و روش سهل انگارانه تست می دانند نه در نرم افزار به ویژه که طراح سیستم از طراحان نرم افزار خواسته که از تنها 80 در صد توان CPU استفاده کنند!!!!)[/font][/size]

[size=3][font=tahoma,geneva,sans-serif][b]2.4. نقاط ضعف احتمالی دیگر سیستم[/b]
با توجه به زمان کم تیم تحقیق و نوع نقص کشف شده تیم تحقیق تصمیم به بررسی دقیق سخت افزار و نرم افزار کامپیوتر پرواز گرفت با این فرض که احتمال وجود خطاهای مشابه در آن وجود دارد و نظرات خود را در زمینه متدولوژی توسعه نرم افزار و نقصهای متن برنامه و سخت افزار پیاده شده در گزارش فنی به کار فرما اعلام نمود[/font][/size].

[size=3][font=tahoma,geneva,sans-serif][url="http://gallery.military.ir/albums/userpics/10198/esa-x-1819eng_02.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_esa-x-1819eng_02.jpg[/img][/url]

[url="http://gallery.military.ir/albums/userpics/10198/esa-x-1819eng_03.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_esa-x-1819eng_03.jpg[/img][/url]

[url="http://gallery.military.ir/albums/userpics/10198/esa-x-1819eng_04.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_esa-x-1819eng_04.jpg[/img][/url]

[url="http://gallery.military.ir/albums/userpics/10198/esa-x-1819eng_05.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_esa-x-1819eng_05.jpg[/img][/url]

[url="http://gallery.military.ir/albums/userpics/10198/esa-x-1819eng_06.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_esa-x-1819eng_06.jpg[/img][/url]

[url="http://gallery.military.ir/albums/userpics/10198/esa-x-1819eng_07.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_esa-x-1819eng_07.jpg[/img][/url][/font][/size]

[i][size=3][font=tahoma,geneva,sans-serif]ادامه دارد...[/font][/size][/i]

[size=3][font=tahoma,geneva,sans-serif][b]تيم تحقيق:[/b]
ترجمه و تحقيق: كاربر [b][url="http://www.military.ir/forums/user/12446-emp/"]EMP[/url][/b] از military.ir
پيشنهاد سوژه، جمع‌آوري تصاوير و ويدئو: كاربر [b][url="http://www.military.ir/forums/user/5027-mahdavi3d/"]mahdavi3d[/url][/b] از military.ir[/font][/size]

[b][size=3][font=tahoma,geneva,sans-serif]استفاده از اين مقاله[color=#0000cd] صرفا با ذكر نام اعضاء تيم تحقيق[/color] و ذكر [color=#ff0000]military.ir[/color] به عنوان منبع، مجاز است.[/font][/size][/b]

[mahdavi3d 14,066]

[size=3][font=tahoma,geneva,sans-serif][color=#800000][b][size=4]3. نتایج[/size][/b][/color][/font][/size]

[size=3][font=tahoma,geneva,sans-serif][b]3.1. یافته ها[/b]
• در مراحل شمارش معکوس پیشامدی که منجر به حادثه شده باشد یافت نشد
• جنس قطعات از نظر متالورژی و عوامل خارجی در بروز حادثه نقشی نداشته اند
• لرزش بدنه ثبت شده ربطی به بروز حادثه نداشته و موتورها کارکرد عادی داشته اند
• 22 ثانیه بعد از پرتاب بروز نوسان در فشار هیدرولیک کنترلگرهای موتور اصلی گرچه نگران کننده است و دلیل آن هنوز معلوم نیست اما در بروز حادثه نقشی نداشته است
• به دلیل نقص نرم افزاری در ثانیه 36.7 مقادیر بدست آمده برای سرعت افقی بیش از تحمل نرم افزار سیستم اینرسیایی پشتیبان بوده و آن را از کار انداخته است
• 0.05 ثانیه بعد سیستم اصلی به همان دلیلی که سیستم پشتیبان از کار افتاده، از کار افتاده و شکست ماموریت پرتاب ناگزیر گردیده است
• بر اثر از کار افتادن سامانه اینرسیایی، این سامانه اقدام به ارسال کد خطای درونی خود بر روی باس داده کامپیوتر پرواز کرده و نرم افزار کامپیوتر پرواز (که از پروتکل ارتباطی درستی با سامانه اینرسیایی برخوردار نبوده!) این کد خطا را به عنوان داده های اندازه گیری شده سرعت و جهت پرتابه در نظر گرفته و بر اساس آنها عمل می کند.
• عملکرد کامپیوتر پرواز بر اساس دریافت داده های غلط منجر به تصحیح نا بجای نازلهای بوسترها وسپس موتور اصلی می گردد تا خطای خیالی درمسیر پرتابگر را تصحیح کند
• تغییر سریع در مسیر پرتابه باعث وارد آمدن فشار شدید ایرو دینامیک به سازه پرتابگر و متلاشی شدن آن در ثانیه 39 می گردد
• در فاصله 1 کیلومتری و ارتفاع 3.7 کیلومتری از محل پرتاب سیستم خود نابودی پرتابگر به درستی متلاشی شدن آن را تشخیص داده و پرتابگر را منفجر می کند
• قطعات پرتابگر در یک محدوده 5 در 2.5 کیلومتر پخش شده و بعد از جمع آوری سامانه های اینرسیایی بازیابی شدند
• داده های تله متری تعداد زیادی از عملکردهای غیر عادی را ثبت کرده بود که همگی بررسی شدند اما تاثیر مهمی در بروز حادثه نداشتند
• قسمتی از نرم افزار که باعث بروز حادثه شد در واقع برای مقدار دهی آغازی قبل از پرتاب در آریان-4 مورد استفاده است و قادر به دوباره تنظیم کردن سامانه در صورت به تعویق افتادن شمارش معکوس است که در آریان-5 موضوعیت ندارد ولی این بخش از برنامه 40 ثانیه بعد از استارت کماکان فعال بوده که در آریان-4 برعکس آریان-5 مشکلی ایجاد نمی کرد
• به دلیل مقادیر بسیار کوچک سرعت افقی طراحان نرم افزار ضرورتی برای حفاظت از تبدیل اعداد مربوط به آن در نرم افزار سامانه اینرسیایی از سرریز شدن ندیدند در حالی که از دیگر متغیر ها حفاظت کردند. طراحان به این حقیقت توجه نداشتند که اگر برنامه بعد از استارت نیز مجاز به اجرا باشد چه اتفاقی برای متغیرهای درون آن خواهد افتاد
• سرعت افقی آریان-5 پنج برابر بیش از آریان-4 است که همین باعث وقوع خطای سرریز در متغیر مربوط به آن در نرم افزار سامانه اینرسیایی شد و بروز این خطا منجر به از کار افتادن کامپیوتر این سامانه گردید
• فرآیند نظارت تحلیل درستی از عملکرد نرم افزار سیستم اینرسیایی در صورتی که بعد از شروع به حرکت کردن پرتابگر به کار خود ادامه دهد نداشته
• از نظر فنی امکان تست سامانه اینرسیایی در کنار تمامی اجزای دیگر سیستم وجود داشته و بنا به دلایلی تصمیم گرفته شده که یک شبیه سازی فرض از آن در تست نهایی سیستم استفاده شود نه خود سیستم یا حتی شبیه سازی دقیق جزئیات درونی آن. در صورتی که این شبیه سازی انجام می شد، وقوع حادثه قابل کشف بود
• شبیه سازی های بعد از پرواز که بر روی کامپیوتری که نرم افزار سامانه اینرسیایی را اجرا می کرد واز داده های واقعی مسیر پرواز فاجعه بار آریان-5 استفاده می کرد نشان داد که حادثه مفروض دوباره در محیط شبیه سازی قابل تکرار است[/font][/size]

[size=3][font=tahoma,geneva,sans-serif][b]3.2. دلیل حادثه از نظر تیم تحقیق[/b]
وقوع حادثه بر اثر نقص نرم افزار سامانه اینرسیایی بوده که در طول مراحل فراوان تست، تحلیل و نظارت و داوری درستی درباره آن صورت نگرفته است و عدم تست مجموعه کامل سامانه کنترل پرواز به صورت یکپارچه باعث اصلی بوجود آمدن خطای بالقوه درون سیستم بوده است.[/font][/size]


[size=3][font=tahoma,geneva,sans-serif][color=#800000][size=4][b]4. پیشنهاد های تیم تحقیق[/b][/size][/color]
4.1. در طی پرواز هیچ نرم افزاری نباید در حال اجرا باشد مگر اینکه واقعا لازم باشد
4.2. امکانات تست را تا جایی که از نظر فنی ممکن است بر اساس شرایط واقعی آماده کنید، از داده های واقعی برای ورودی استفاده کنید ، شبیه سازی کامل سیستم قبل از هر پرتاب الزامی است و همواره سیستم به صورت کامل تست شود نه جزء به جزء
4.3. اجازه ندهید که هیچ سنسوری مانند سامانه اینرسیایی از ارسال بهترین داده ای که می تواند باز ایستد
4.4. هر قسمت از نرم افزار باید بازبینی و نظارت صنعتی جداگانه داشته باشد. هر محدودیتی در استفاده از تجهیزات باید صریحا به تیم داوری اعلام گردد
4.5. تمام نرم افزارهای پرواز به ویژه برنامه های درون میکروکنترلرها و Firmware ها باید بازبینی و داوری شوند
4.6. تمام فرضیات ضمنی انجام شده در برنامه را معین کنید و امتحان کنید که این فرضیات بر خلاف محدودیتهای دستگاه نباشد
4.7. بازه مجاز مقادیر را درون متغیرهای داخلی یا متغیرهایی که برای ارتباط با سیستم دیگر مورد نیاز هستند چک کنید
4.8. تعیین راه حل و پیاده سازی آن در سیستم برای مشکلات بالقوه که ممکن است برای کامپیوتر و نرم افزار آن پیش آید، به ویژه هنگامی که باید به دلیل خرابی از کامپیوتر دیگری استفاده شود، باید توسط تیم پروژه پیشنهاد داده شود واین پیشنهاد باید توسط متخصصینی دیگر خارج از تیم طراحی بازبینی گردیده و به اطلاع تیم تایید کیفیت برسد و نباید راسا توسط اعضای تیم اعمال شود.
4.9. در صورتی که از نظر فنی امکان پذیر باشد، خطاهای Exception را درون روتینهای سیستم محدود کنید و امکانات پشتیبانی برای آن در نظر بگیرید.
4.10. داده های تله متری را هنگام بروز خطا در یک زیر سامانه آنقدر جامع ارسال کنید که در صورت بروز حادثه نیاز به جمع آوری قطعات نباشد.
4.11. تعریف اجزاء حساس مدار را مورد بازبینی قرار دهید و وقوع خطای با منشاء نرم افزار را همواره در نظر گرفته راه حل چایگزین ارائه کنید
4.12. همواره از داورانی بیرون از مجموعه کاری خود استفاده کنید و مطمئن شوید که آنها تست و بررسی های خاص خودشان را انجام می دهند نه اینکه انجام تست توسط تیم شما را تایید کنند.
4.13. داده های مسیر پرتابه را در تعریف مشخصات و الزامات سیستم تاثیر بدهید.
4.14. اینکه تستهای انجام شده پوشش کافی برای تست تجهیزات دارند را بازبینی کرده و در صورتی که تشخیص دادید که لازم است آنها را بسط دهید.
4.15. به سند حاوی تصمیمهای مربوط به پیاده سازی برنامه، به اندازه خود برنامه اهمیت بدهید و سعی کنید توانایی فنی خود را در تثبیت برنامه و سند تصمیم گیری آن بهبود بخشید.
4.16. تیمی جهت ارزیابی و تحقیق صحت نرم افزار تشکیل دهید.
4.17. سازمانی شفاف تر دارای ارتباط خوب بین همکاران و پیمانکاران و همکاری نزدیک با پیمانکاران توام با حس مسئولیت و وظیفه شناسی لازمه موفقیت است و باید به سمت آن حرکت کرد
4.18. تلاش کنید که برنامه ای که می سازید به ذات امن باشد. برای مثال سامانه اینرسیایی هرگز نباید داده ای را برای کامپیوتر پرواز ارسال می کرد که از نظر آن کامپیوتر بی معنی باشد و نحوه ارسال داده ها نباید به طوری باشد که در مقصد فرقی بین بسته دستور و داده ارسالی نباشد و احتمال تفسیر اشتباه وجود داشته باشد. در این مثال سامانه اینرسیایی بعد از وقوع Exception باید به سادگی به کار خود ادامه می داد و حداقل بهترین تخمین خود از موقعیت را می ساخت نه اینکه از کار بیافتد
4.19. در یک سیستم امن در صورت بروز خطای بهتر است که یک روتین وقفه (اینتراپت) فراخوانی شود و در آن روتین سعی در بردن سیستم به وضعیت امن بشود نه اینکه سیستم خاموش گردد.
4.20. همواره انتظار وقوع Exception را داشته باشید و برای کنترل آن پیش بینی لازم را بکنید تا کارکرد برنامه مختل نگردد.
4.21. در اسناد نرم افزار جنبه های طراحی نرم افزار به الزامات آن مربوط گردند و برعکس به نحوی که هنگامی که الزامات یک سیستم تغییر می کند از روی سند آن بتوانیم فورا روتینهایی از برنامه را که باید تغییر بدهیم و یا حذغ کنیم را بیابیم.
4.22. برنامه هایی که قبلا برای سیستمهای دیگر کار کرده و جواب داده اند باید در صورت استفاده مجدد، تست شوند تا خطاهای نهفته و جدید آنها آشکار گردد
4.23. هنگام استفاده مجدد برنامه تک تک الزامات سیستم را برای آن تحقیق کنید و مطمئن شوید که از روی روتین های برنامه الزامات تایید می شوند و از روی الزامات روتینها.
4.24. همواره کل سیستم را از ابتدا تا انتهای ماموریت با استفاده از شبیه ساز تست کنید و در تست هیچ جزئیاتی را بی اهمیت تلقی نکنید.[/font][/size]

[size=3][font=tahoma,geneva,sans-serif][hr]
[url="http://gallery.military.ir/albums/userpics/10198/198px-Ariane_501_Cluster_svg.png"][img]http://gallery.military.ir/albums/userpics/10198/thumb_198px-Ariane_501_Cluster_svg.png[/img][/url]

[url="http://gallery.military.ir/albums/userpics/10198/Cluster-FM2.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_Cluster-FM2.jpg[/img][/url]

[b]فضاپيماي Cluster[/b]
اين منظومه 4 تايي فضاپيماها، موسوم به كلاستر، توسط آژانس فضايي اروپا (اِسا) و براي مطالعه مَگنِتوسفِر (مِغناط‌کُره) ساخته شده بودند. جرم هر فضاپيما 1200 كيلوگرم و انرژي آنها توسط سلول‌هاي خورشيدي با توان 224 وات طراحي شده بود. مدار آنها از نوع مدار با كشيدگي زياد (17200×120600 كيلومتر) و زاويه مدار 90 درجه پيش‌بيني شده بود.
فرايند پرتاب در 4 ژوئن 1996 ميلادي (15 خرداد 1375 هجري شمسي) و 12:34:06 به وقت گرينويچ آغاز شد.

[hr]
[b]ويدئو پرتاب[/b][/font][/size]
[center]
[size=3][font=tahoma,geneva,sans-serif][img]http://gallery.military.ir/albums/userpics/10198/Ariane-5-rocket_Flight-501_10.jpg[/img]
دانلود (حجم: 8.5 مگابايت)
[url="http://trainbit.com/files/9555049884/Ariane-5_Rocket_first-launch_failure-explosion_1001.flv"]http://trainbit.com/...losion_1001.flv[/url][/font][/size][/center]

[size=3][font=tahoma,geneva,sans-serif]اسكرين‌شات
[url="http://gallery.military.ir/albums/userpics/10198/Ariane-5-rocket_Flight-501_01.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_Ariane-5-rocket_Flight-501_01.jpg[/img][/url]

[url="http://gallery.military.ir/albums/userpics/10198/Ariane-5-rocket_Flight-501_02.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_Ariane-5-rocket_Flight-501_02.jpg[/img][/url]

[url="http://gallery.military.ir/albums/userpics/10198/Ariane-5-rocket_Flight-501_03.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_Ariane-5-rocket_Flight-501_03.jpg[/img][/url]

[url="http://gallery.military.ir/albums/userpics/10198/Ariane-5-rocket_Flight-501_04.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_Ariane-5-rocket_Flight-501_04.jpg[/img][/url]

[url="http://gallery.military.ir/albums/userpics/10198/Ariane-5-rocket_Flight-501_05.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_Ariane-5-rocket_Flight-501_05.jpg[/img][/url]

[url="http://gallery.military.ir/albums/userpics/10198/Ariane-5-rocket_Flight-501_06.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_Ariane-5-rocket_Flight-501_06.jpg[/img][/url]

[url="http://gallery.military.ir/albums/userpics/10198/Ariane-5-rocket_Flight-501_07.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_Ariane-5-rocket_Flight-501_07.jpg[/img][/url]

[url="http://gallery.military.ir/albums/userpics/10198/Ariane-5-rocket_Flight-501_08.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_Ariane-5-rocket_Flight-501_08.jpg[/img][/url]

[url="http://gallery.military.ir/albums/userpics/10198/Ariane-5-rocket_Flight-501_09.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_Ariane-5-rocket_Flight-501_09.jpg[/img][/url]

[url="http://gallery.military.ir/albums/userpics/10198/Ariane-5-rocket_Flight-501_11.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_Ariane-5-rocket_Flight-501_11.jpg[/img][/url]

[url="http://gallery.military.ir/albums/userpics/10198/Ariane-5-rocket_Flight-501_12.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_Ariane-5-rocket_Flight-501_12.jpg[/img][/url]

[url="http://gallery.military.ir/albums/userpics/10198/Ariane-5-rocket_Flight-501_13.jpg"][img]http://gallery.military.ir/albums/userpics/10198/thumb_Ariane-5-rocket_Flight-501_13.jpg[/img][/url]

[hr]
[b]منابع و مراجع:[/b]
[url="http://esamultimedia.esa.int/docs/esa-x-1819eng.pdf"]http://esamultimedia...a-x-1819eng.pdf[/url]
[url="http://en.wikipedia.org/wiki/Ariane_5_Flight_501"]http://en.wikipedia....ne_5_Flight_501[/url]
[url="http://de.wikipedia.org/wiki/Ariane_V88"]http://de.wikipedia....wiki/Ariane_V88[/url]
[url="http://en.wikipedia.org/wiki/French_Guiana"]http://en.wikipedia....i/French_Guiana[/url]
[url="http://www.around.com/ariane.html"]http://www.around.com/ariane.html[/url]
[url="http://www.vuw.ac.nz/staff/stephen_marshall/SE/Failures/SE_Ariane.html"]http://www.vuw.ac.nz.../SE_Ariane.html[/url]
[url="http://www.ima.umn.edu/~arnold/disasters/ariane5rep.html"]http://www.ima.umn.e...ariane5rep.html[/url]

[i]High technology systems with low
Technology Failures
Some Experience with Rockets on
Software Quality & Integration
Larry G. Craig
NASA Launch Services Program
Kennedy Space Center
February 10, 2010

The Bug That Destroyed a Rocket
Mordechai Ben-Ari
Department of Science Teaching
Weizmann Institute of Science[/i][/font][/size]

[size=3][font=tahoma,geneva,sans-serif]پايان.[/font][/size]

[size=3][font=tahoma,geneva,sans-serif][b]تيم تحقيق:[/b]
ترجمه و تحقيق: كاربر [b][url="http://www.military.ir/forums/user/12446-emp/"]EMP[/url][/b] از military.ir
پيشنهاد سوژه، جمع‌آوري تصاوير و ويدئو: كاربر [b][url="http://www.military.ir/forums/user/5027-mahdavi3d/"]mahdavi3d[/url][/b] از military.ir[/font][/size]

[b][size=3][font=tahoma,geneva,sans-serif]استفاده از اين مقاله[color=#0000cd] صرفا با ذكر نام اعضاء تيم تحقيق[/color] و ذكر [color=#ff0000]military.ir[/color] به عنوان منبع، مجاز است.[/font][/size][/b]

[i][size=2][font=tahoma,geneva,sans-serif]لطفا به علوم و فنون فضايي منتقل نماييد. متشكرم.[/font][/size][/i]

[pckho0r 3,021]

از هیبت اریان 5 خیلی خوشم میاد. یعنی میشه اون روز برسه که یه پرتابگری تو این قد و قواره پرتاب کنیم؟!

امارکاملی از شکست های این پرتابگر وجود داره؟

[mahdavi3d 14,066]

[size=3][font=tahoma,geneva,sans-serif]ليست كامل پرتاب‌هاي آريان 5 را در لينك زير ببينيد:[/font][/size]
[size=3][font=tahoma,geneva,sans-serif][url="http://en.wikipedia.org/wiki/Ariane_5#Ariane_5_flights"]http://en.wikipedia....riane_5_flights[/url][/font][/size]

[size=3][font=tahoma,geneva,sans-serif]آريان-5 تاكنون 65 پرتاب داشته (آخرين پرتابش همين امروز بوده و تاپيكش را به زودي ايجاد خواهم كرد). تنها شكست طبقه اصلي پرتابگر، همين اولين پرتابش بوده و به جز اين، كلا 2 شكست جزئي و يك شكست مربوط به عملكرد نادرست طبقه فوقاني داشته است.[/font][/size]
[size=3][font=tahoma,geneva,sans-serif]اين پرتابگر از سال 2003 ميلادي به اينطرف، شكستي نداشته و اخيرا 50 امين پرتاب موفقيت‌آميز پشت سر هم را جشن گرفت.[/font][/size]
[size=3][font=tahoma,geneva,sans-serif][url="http://www.military.ir/forums/topic/22005-50-%D8%A7%D9%85%D9%8A%D9%86-%D9%BE%D8%B1%D8%AA%D8%A7%D8%A8-%D9%85%D9%88%D9%81%D9%82%D9%8A%D8%AA-%D8%A2%D9%85%D9%8A%D8%B2-%D9%BE%D8%B1%D8%AA%D8%A7%D8%A8%DA%AF%D8%B1-%D8%A2%D8%B1%D9%8A%D8%A7%D9%865-%D9%85%D8%A7%D9%87%D9%88%D8%A7%D8%B1%D9%87%E2%80%8C/"]http://www.military....ريان5-ماهواره‌/[/url][/font][/size]

[size=3][font=tahoma,geneva,sans-serif]پرتابگر آريان-5 امروزه به عنوان يكي از قابل اطمينان‌ترين (كلا [/font][/size][size=3][font=tahoma,geneva,sans-serif][size=3][font=tahoma,geneva,sans-serif]قابل اطمينان‌ترين[/font][/size] در برخي منابع) پرتابگرهاي حال حاضر جهان شناخته مي‌شود.[/font][/size]

[size=3][font=tahoma,geneva,sans-serif]بنده جا دارد از جناب [b][url="http://www.military.ir/forums/user/12446-emp/"]EMP[/url][/b] تشكر ويژه داشته باشم كه زحمت اصلي بر عهده ايشان بوده است. [/font][/size]

[hosm 5,920]

بسم الله الرحمن الرحیم
با سلام و تشکر

این شکست مبداء شکل گیری شاخه ای در علوم و مهندسی کامپیوتر به نام Verification شد که سعی می نماید با ارائه تئوریهایی برای تست های اتوماتیک و پوشش فضای حالتای ممکن برای الگوریتم، ابزارهایی برای اطمینان از صحت الگوریتم ها و پیاده سازی آنها ایجاد نماید
شاخه Formal Verification در Model Checking سیستم های نظامی از جایگاه و آینده خوبی برخوردار خواهد بود.

[misalu2001 361]

بسیار جالب بود!

مگر یک بلوک ترای/کچ چقدر بار محاسباتی ایجاد می کند؟ اصولا مگر پردازنده کم و گران است که محدودیت بار محاسبه تا این حد جزیی باشد؟
در ضمن خیلی عجیب است که کامپیوتر مربوط به محاسبات اینرسیایی، اکسپشن را روی خط داده فرستاده!
معمولا کامپیوترها یک خط به نام "ترمینال" دارند که دیباگ و مونیتور روی آن انجام می شود و خطوط ارتباطی دیگر از "ترمینال" جداست.
(ترمینال در اینجا یک واژه عام به معنی درگاه ارتباط نیست و به درگاه خاصی اتلاق می شود که سطح دسترسی بالاتر از خود برنامه دارد و خصوصیات خاصی هم باید داشته باشد)

[EMP 6,861]

[quote name='misalu2001' timestamp='1348963388' post='274713']
بسیار جالب بود!

مگر یک بلوک ترای/کچ چقدر بار محاسباتی ایجاد می کند؟ اصولا مگر پردازنده کم و گران است که محدودیت بار محاسبه تا این حد جزیی باشد؟
در ضمن خیلی عجیب است که کامپیوتر مربوط به محاسبات اینرسیایی، اکسپشن را روی خط داده فرستاده!
معمولا کامپیوترها یک خط به نام "ترمینال" دارند که دیباگ و مونیتور روی آن انجام می شود و خطوط ارتباطی دیگر از "ترمینال" جداست.
(ترمینال در اینجا یک واژه عام به معنی درگاه ارتباط نیست و به درگاه خاصی اتلاق می شود که سطح دسترسی بالاتر از خود برنامه دارد و خصوصیات خاصی هم باید داشته باشد)
[/quote]
درود به جناب Misalu2001
معلوم است که آشنایی بسیار خوبی با ابزار دقیق و سخت افزارها و نرم افزار های مطمئن دارید.
ضمن تشکر از جناب MAHDAVI3D که زحمت ایجاد این بخش را کشیدند به عرض می رسانم که همانطور که می دانید در ساخت سخت افزارهایی که برای صنایع هوا فضا، نیروگاهی، نفتی و از این قبیل کاربرد دارند هیچگاه هزینه مطرح نیست زیرا هزینه بخش مکانیکی و خسارات جانی و حیثیتی دهها برابر بیشتر است و ما هیچ گاه در این موارد صرفه جویی نمی کنیم اما سامانه اینرسیایی آریان-5 متعلق به آریان-4 بوده و در دهه 80 میلادی تست و ساخته شده بوده است. همانطوری که اشاره کردید حتی فاقد یک پروتکل ارتباطی بوده که به کامپیوتر اصلی فرق بسته داده و بسته دستور را بفهماند!!! در آن زمان تکنولوژی در سطحی نبود که به اهمیت این مسایل توجه شود. در یکی از اسناد مربوط به حادثه آمده که ضعف در تحویل صحیح بخشهای برون سپاری شده علت اصلی حادثه بوده و حتی با تکنولوژی 1996 باید بدون وجود پروتکل ارتباطی، وسیله را تحویل نمی گرفتند. البته تراشه های ایرواسپیس گران هستند، مثلا یک تراشه زایلینکس QV ممکن است تا 60 هزار دلار یا بیشتر قیمت داشته باشد اما گرانی دلیل استفاده از پردازنده ضعیف نبوده است (هر چند که امروزه با استفاده از سینتسایزرهایی مانند precision synthesizer نسخه Hirel ساخت Mentorgraphics چندان نیازی به تراشه FPGA ایرواسپیس نیست). در دهه 80 تراشه های بهتر از این در دسترس نبوده و دردهه 90 هم پیمان کار جنس قدیمی را تحویل داده و کسی نفهمیده است یا نخواسته که بفهمد!!
یک سند داشتم در مورد ناو نشینهای آمریکایی که چند سال پیش دچار خسارات زیاد هنگام فرود می شدند که بعدا معلوم شد که پیمانکار قطعات مربوط به سیستم hooking ناو نشین، از یک پیمانکار فرعی چینی استفاده کرده و او هم از مواد تقلبی در بستها استفاده می کرده است و آمریکایی ها بعد از چندین حادثه متوجه موضوع می شوند !!! یا می خواهند که بشوند!!! که البته به همان اندازه نا باورانه هست!!! تمام اینها باید برای ما درس باشد که اشتباهات اینها را مخصوصا در جمع کردن سیستم تکرار نکنیم و جان پرسنل را به خطر نیاندازیم.

[hosm 5,920]

[quote name='misalu2001' timestamp='1348963388' post='274713']
بسیار جالب بود!

مگر یک بلوک ترای/کچ چقدر بار محاسباتی ایجاد می کند؟ اصولا مگر پردازنده کم و گران است که محدودیت بار محاسبه تا این حد جزیی باشد؟
در ضمن خیلی عجیب است که کامپیوتر مربوط به محاسبات اینرسیایی، اکسپشن را روی خط داده فرستاده!
معمولا کامپیوترها یک خط به نام "ترمینال" دارند که دیباگ و مونیتور روی آن انجام می شود و خطوط ارتباطی دیگر از "ترمینال" جداست.
(ترمینال در اینجا یک واژه عام به معنی درگاه ارتباط نیست و به درگاه خاصی اتلاق می شود که سطح دسترسی بالاتر از خود برنامه دارد و خصوصیات خاصی هم باید داشته باشد)
[/quote]

مشکل در بار محاسباتی بلوک try-catch نیست. برنامه نویس پیش فرضی داشته که عدد حاصله همیشه در 16 بیت جا می شود و تا جایی که شنیده ام خطای یکی از سنسورها پیش فرض او را باطل کرده.
به دلیل این پیش فرض Exception Handeling انجام نشده و در عمل خطای به وجود آمده در یک بخش، به بخش های دیگر هم سرایت کرده.
Model Checking و Verification که عرض کردم برای همین است که در تست، هیچ نقطه ای از فضای حالت مغفول نماند. البته این کار بسیار گران و هزینه بر نیز هست.

[EMP 6,861]

[quote name='hosm' timestamp='1348999612' post='274732']
[quote name='misalu2001' timestamp='1348963388' post='274713']
بسیار جالب بود!

مگر یک بلوک ترای/کچ چقدر بار محاسباتی ایجاد می کند؟ اصولا مگر پردازنده کم و گران است که محدودیت بار محاسبه تا این حد جزیی باشد؟
در ضمن خیلی عجیب است که کامپیوتر مربوط به محاسبات اینرسیایی، اکسپشن را روی خط داده فرستاده!
معمولا کامپیوترها یک خط به نام "ترمینال" دارند که دیباگ و مونیتور روی آن انجام می شود و خطوط ارتباطی دیگر از "ترمینال" جداست.
(ترمینال در اینجا یک واژه عام به معنی درگاه ارتباط نیست و به درگاه خاصی اتلاق می شود که سطح دسترسی بالاتر از خود برنامه دارد و خصوصیات خاصی هم باید داشته باشد)
[/quote]

مشکل در بار محاسباتی بلوک try-catch نیست. برنامه نویس پیش فرضی داشته که عدد حاصله همیشه در 16 بیت جا می شود و تا جایی که شنیده ام خطای یکی از سنسورها پیش فرض او را باطل کرده.
به دلیل این پیش فرض Exception Handeling انجام نشده و در عمل خطای به وجود آمده در یک بخش، به بخش های دیگر هم سرایت کرده.
Model Checking و Verification که عرض کردم برای همین است که در تست، هیچ نقطه ای از فضای حالت مغفول نماند. البته این کار بسیار گران و هزینه بر نیز هست.
[/quote]
درود به جناب hosm
مطابق گزارش تیم تحقیق، برنامه نویسان از امکان بروز arithmatic overflow در محل رخداد آن در روز حادثه آگاه بودند اما به دلیل اینکه در الزامات طراحی به آنها دستور داده شده بوده است که حداکثر 80% توان پردازنده را قادر به استفاده هستند و سیستم از نظر محاسباتی دچار کمبود ظرفیت بوده مجبور می شوند که در 3 نقطه از حفاظت استفاده نکنند و چند CPU سایکل ناقابل هم که شده صرفه جویی کنند!!!
سنسورها همگی به درستی به وظیفه خود عمل کرده اند و اصولا این قسمت از برنامه که باعث خطا شده وظیفه Alignment سامانه اینرسیایی را داشته، در آریان-4 این زمان 50 ثانیه Alignment قبل از کنده شدن پرتابگر از زمین، به پایان می رسیده است و هنگام حرکت، دیگر کار نمی کرده است در حالیکه شوربختانه، در آریان-5 زمان استارت تا کنده شدن از زمین بسیار کوتاه بوده و این روتین Alignment مشغول Align کردن سنسور [b][color=#ff0000][i]در زمان حرکت بوده[/i][/color][/b] [b]که این نقص سیستمی[/b] باعث ایجاد اعداد بزرگ خارج از تصور شده و در نهایت ..... . البته نمی توان از ایراد برنامه سازی صرف نظر کرد اما باید توجه داشت که برنامه سازان این سنسور از محل احتمالی وقوع خطا آگاه بودند اما اشتباهشان زمانی آغاز می شود که سعی در کاهش استفاده از CPU با کاهش حفاظت می کنند (شاید برنامه ایشان دیگر جای بهینه سازی نداشته است). اشتباه بدتر این بوده که چرا سیستم اینرسیایی آریان-4 را بدون تصحیح و بازبینی بر روی آریان-5 نصب کرده اند و چرا شرایط پروازی آریان-5 را در تست آن در نظر نگرفته اند که ی[b]ک خطای سیستمی [/b]دیگر است.
از نظر خود من هم دادن این دستور که حداکثر از 80% توان پردازنده می توانید استفاده کنید هم خیلی عجیب است و به جز محدودیت حرارتی و تامین انرژی که دلایل ضعیفی است نمی توانم دلیل منطقی دیگری برای آن بیابم که البته مورد انتقاد تیم تحقیق هم قرار گرفته است.