طبق گزارش انجمن هوانوردی فدرال (FAA) در سال 2017 حدود 100 هزار هواپیما روزانه در سراسر جهان به پرواز در آمده‌اند. این انجمن اعلام کرد در هر لحظه کنترل ترافیک هوایی به‌طور میانگین 5 هزار هواپیما را در محیطی به وسعت 29 میلیون مایل مربع پشتیبانی می‌کند. این در حالی است که با توجه به رشد مسافرت‌های هوایی و همچنین گسترش استفاده از هواپیماهای بدون سرنشین، این اعداد تاکنون افزایش یافته‌اند.
کاملا روشن است که سیستم‌های بحرانی هواپیما به عنوان مسئول ایمنی پرواز، باید پیش از دریافت گواهی صلاحیت پرواز هواپیما، با مقررات سخت ایمنی سازگار باشند. در نهایت تایید سطح ایمنی قابل قبول برای این سیستم‌ها و سایر اجزای هواپیما، منجر به صدور گواهینامه پرواز از سوی سازمان‌های تنظیم مقررات ایمنی هواپیما در آن کشور یا منطقه می‌شود. این سازمان‌ها می‌تواند شامل اداره هوانوردی فدرال در ایالات متحده، آژانس ایمنی هوانوردی اروپا و سازمان هواپیمایی در کشورمان باشد. با این حال توافق‌نامه‌های چندجانبه بین سازمان‌ها می‌تواند باعث اعتبار بخشیدن به یک گواهینامه صلاحیت پرواز در سایر کشورها یا مناطق شود.
سازمان‌هایی مانند FAA استانداردهای فنی تحت عنوان TSO[1] منتشر می‌کنند که حداقل نیازمندی‌های عملکرد برای یک بخش یا جزئی از هواپیما را تعیین می‌کند. این حداقل نیازمندی‌ها با همکاری و راهنمایی سازمان‌های مستقلی همچون EUROCAE، SAE[2]، ARINC و RTCA[3] تنظیم می‌شوند.
سطوح تضمین طراحی و احتمال خرابی قابل‌قبول
SAE یک انجمن بین‌المللی است که استانداردهای مهندسی را برای بسیاری از صنایع همچون هوافضا و حمل‌ونقل زمینی تدوین می‌کند. از جمله اسناد منتشر شده توسط این انجمن می‌توان به دستورالعمل‌های توصیه‌شده هوافضا (ARP[4]) اشاره کرد که نقش مهمی در طراحی هواپیما و فرآیند صدور گواهینامه ایمنی بازی می‌کنند. یکی از مطرح‌ترین استاندارد SAE سند ARP4754A است که در آن جزئیات و دستورالعمل‌های توسعه یک هواپیمای غیرنظامی و سیستم‌های آن تعریف شده است. در طراحی این دستورالعمل‌ها، SAE سیستم‌های محاسباتی مورد نیاز برای یک هواپیمای مدرن (همچون کامپیوترهای کنترل پرواز، خلبان خودکار، سیستم‌های ناوبری و کنترل ارابه‌فرود) را مورد بررسی قرار داده و در ادامه میزان اهمیت ایمنی (بحرانی بودن) و خطرات ناشی از عملکرد غیرصحیح هر یک از آن‌ها تحلیل شده است.
بازه بحرانی بودن یک سیستم از سطح بدون تاثیر (که از خرابی یک سیستم غیرضروری مانند سرگرمی مسافران انتظار می‌رود) تا سطح فاجعه‌بار (که ناشی از خرابی یک سیستم ایمنی- بحرانی است و منجر به تهدید جدی ایمنی هواپیما می‌شود) در نظر گرفته شده است. متناسب با میزان بحرانی بودن عملکردهای غیرصحیح، برای هر سیستم یک احتمال قابل‌قبول از خرابی تعیین می‌شود. برای مثال در سیستم‌های پرواز- بحرانی مانند کنترل پرواز که شکست در آن منجر به صدمات جانی می‌شود (بالاترین سطح خطر)، احتمال خرابی باید کمتر از یک در یک میلیاردم (10-9) برای هر ساعت پرواز باشد. این احتمال قابل‌قبول خرابی برای سیستم‌هایی با میزان بحرانی‌بودن کمتر، افزایش می‌یابد.
پتانسیل یک سیستم برای ایجاد یک خطر (در صورت وقوع یک خطا) و مقدار احتمال قابل‌قبول خرابی تعیین شده برای آن، سطح تضمین طراحی (DAL[5]) را تعیین می‌کند که باید برای دریافت گواهینامه پرواز رعایت شود. این بدان معناست که عناصر محاسباتی و کلیدی یک سیستم همچون کامپیوترهای تک بوردی، کارت‌های گرافیک و سیستم‌عامل‌های موجود در یک کامپیوتر کنترل پرواز یا نمایشگر پرواز باید برای اثبات برآورده کردن نیازمندی‌های DAL، آزمایش‌های سختی را بگذرانند.
جدول 1- سطوح تضمین طراحی (DAL)
استانداردهای طراحی نرم‌افزار و سخت‌افزار
در کنار SAE، آژانس RTCA نیز از دیگر سازمان‌هایی است که در زمینه‌های فنی با FAA همکاری دارد. RTCA چند سند در رابطه با توسعه سخت‌افزار و نرم‌افزارهای اویونیک تهیه کرده است که به عنوان حداقل کارایی عملیاتی سیستم‌ها مطابق با DALهای تعریف شده در جدول 1 هستند.
دو نمونه شاخص از اسناد ارائه شده از سوی RTCA، استانداردهای DO-254 (راهنمای تضمین طراحی برای سخت‌افزارهای الکترونیک هوایی) و DO-178C (ملاحظات نرم‌افزاری در سیستم‌های هوایی و گواهینامه تجهیزات) هستند. هنگام پیاده‌سازی یک سیستم تعبیه‌شده برای کاربردهای ایمنی محور، این دو سند مرجع اصلی طراحان برای توسعه اجزای سخت‌افزاری، سیستم‌عامل و برنامه‌های کاربردی است.
برای مثال یک کامپیوتر تک بوردی که برای استفاده در سیستم کنترل پرواز طراحی شده است (با توجه به جدول 1، بروز خرابی در چنین کامپیوتری باعث خطرات فاجعه‌بار می‌شود) باید نیازمندی‌های DAL-A را مطابق استانداردهای DO-254 و DO-178C برآورده کند. به‌طور مشابه یک بورد پردازش تصویر به‌کار رفته در سیستم نمایشگر پرواز نیز باید چنین الزاماتی را برآورده کند.
برای اثبات سازگار بودن یک سیستم با نیازمندی‌های اعلام شده، طراح باید تمامی اسناد و داده‌های طراحی (Artifacts) خود را که در این استانداردها بیان شده است، ارائه دهد. این داده‌های طراحی باید نشان‌دهند که هر تابع سخت‌افزاری یا ویژگی نرم‌افزاری استفاده نشده در سیستم به طور کامل غیرفعال بوده و نمی‌تواند تاثیری در کارایی یا ایمنی سیستم داشته باشد. طراح باید اثبات کند که هر تابع سخت‌افزاری غیرفعال شده تحت هیچ شرایطی نمی‌تواند به طور تصادفی فعال شود. به‌طور مشابه در بخش نرم‌افزار نیز برای هر ویژگی بلااستفاده باید به طور کامل کدهای برنامه حذف شود.
در واقع برای یک شرکت تازه کار، طراحی یک سیستم که بتواند آزمایش‌های سخت‌گیرانه استانداردهای عنوان شده را با موفقیت پشت سر گذارد و همچنین تهیه داده‌های طراحی، کاری بسیار پیچیده و زمان‌بر است. خرید این نرم‌افزار و سخت‌افزارها از فروشندگان با تجربه و متخصص که محصولاتی آماده دریافت گواهی ارائه می‌کنند، یک جایگزین مناسب برای رهایی از مشکلات مذکور است. این محصولات با مجموعه کاملی از داده‌های طراحی ارائه می‌شوند و بنابراین استفاده از آن‌ها موجب کاهش چشم‌گیر هزینه و زمان برای دریافت گواهی کل سیستم می‌شود.
مقررات برای هواپیماهای بدون سرنشین
در چند سال گذشته شاهد رشد استفاده از پرنده‌های بدون سرنشین سنگین نظامی و غیرنظامی (بالاتر از 300 کیلوگرم) بوده‌ایم. در موارد زیادی این هواپیماها در حریم‌های هوایی تجاری مورد استفاده قرار می‌گیرند و عدم حضور یک خلبان در شرایط پیش‌بینی نشده، آن‌ها را مستلزم داشتن نیازمندی‌های ایمنی اضافی می‌کند. در حالی که در هواپیماهای سرنشین‌دار یک خلبان می‌تواند تهدید‌های بالقوه را ببیند و از آن‌ها جلوگیری کند، یک UAV باید از طریق سیستم‌های موجودش تهدید را شناسایی و نحوه جلوگیری از آن را محاسبه کند. بنابراین یک UAV با تکیه بر حسگرهای خود می‌بیند و از طریق عبارت‌های ریاضی پرواز را ایمن نگه می‌دارد.
تاکنون دو TSO برای اطمینان از عملکرد UAVها منتشر شده است. اولین مورد TSO-C212 است که مطابق با استاندارد DO-366 (رادار هوا به هوا در UAVها) بوده و قوانین مربوط به شناسایی دیگر هواپیماها را برای رادار جستجوی یک UAV تعیین می‌کند. سند بعدی TSO-C211 است که استاندارد DO-365 (سیستم‌های شناسایی و پیشگیری UAV) را فراخوانی کرده و نیازمندی‌های یک سیستم با توانایی محاسبه یک مانور پیشگیرانه از برخورد با مانع را تعریف می‌کند. تمام هواپیماهای بدون سرنشین سنگین‌تر از 25 کیلوگرم برای پرواز در حریم‌های هوایی کنترل‌شده‌ی بالای 400 پا باید گواهی DO-365 را دریافت کنند.
اداره هوانوردی فدرال اخیرا در سند TSO-C213 برای هواپیماهای بدون سرنشین نیز سطوح تضمین طراحی را تعریف کرده است. دسته‌بندی سطوح DAL برای UAVها متناسب با انرژی جنبشی پرنده نسبت به زمین (با واحد پا بر پوند) انجام شده است. در جدول 2 می‌توانید سطوح تظمین طراحی برای UAVها را مشاهده کنید.
جدول2- سطوح تضمین ایمنی و احتمال خرابی قابل قبول برای سیستم‌های بدون‌سرنشین هوایی
به طور معمول هر دو عملیات رادار هوا به هوا و سیستم شناسایی و اجتناب از برخورد، روی ماژول محاسباتی مشابه انجام می‌شود. طراحی ایمن چنین سیستمی از یک سو و بهینه‌سازی اندازه، وزن و توان (به دلیل محدودیت‌های موجود در یک UAV) از سوی دیگر، چالش‌های پیش‌روی طراحان هواپیماهای بدون سرنشین است.
پذیرش استانداردهای تجاری در بخش نظامی
آژانس‌های نظامی کانادا و ایالات متحده در حال حاضر اسناد طراحی مبتنی بر استانداردهای تجاری همچون DO-254 و DO-178C را به عنوان یک مدرک معتبر برای صدور گواهینامه پذیرش می‌کنند. برای مثال سند DO-160 می‌تواند جایگزین استانداردهای MIL-STD-461 و MIL-STD-810 برای شرایط محیطی و تست شود. به طور مشابه اسناد ARP-4754 و ARP4761 به عنوان یک مرجع ارزیابی ایمنی به جای استاندارد MIL-STD-882 مورد پذیرش قرار می‌گیرند. البته ممکن است هواپیمای نظامی علاوه بر نیازمندی‌های این استانداردهای تجاری، مستلزم گذراندن برخی تست‌های ویژه مانند حمل و شلیک سلاح باشند.
غلبه بر چالش‌های پیش روی DAL A
در طراحی سیستم‌های اویونیک که نیاز به اخذ گواهینامه DAL A دارند، دستیابی به احتمال خرابی کمتر از 10-9 در هر ساعت پرواز، کاری سخت خواهد بود. به عنوان مثال یک کامپیوتر کنترل پرواز را در نظر بگیرید که با چند کامپیوتر داده‌های هوایی در ارتباط بوده و اطلاعات جمع‌آوری شده از حسگرهای مرتبط با آن‌ها (سرعت هوا، ارتفاع، شتاب‌سنج و ژایروسکوپ) را در محورهای سه‌گانه هواپیما دریافت می‌کند. کامپیوتر کنترل پرواز باید این داده‌ها را تحلیل کرده و پاسخ مناسب را برای عملگرها در بخش‌های مختلف هواپیما ارسال کرده تا ثبات هواپیما در ارتفاع مناسب حفظ شود. برای داشتن یک حلقه بازخورد مناسب، ارتباط بین این کامپیوتر و حسگرها باید در فرکانس بالایی انجام شود.
استفاده از تنها یک کامپیوتر برای مدیریت این حلقه و دستیابی به احتمال خطای کمتر از 10-9 غیر منطقی است. به عبارت دیگر داشتن یک سیستم کنترل پرواز تک کاناله که بروز خطا در هر نقطه از آن منجر به شکست حلقه خواهد شد، بسیار آسیب‌پذیر است. علاوه بر این عوامل خارجی نیز می‌توانند باعث بروز یک خرابی در سیستم شوند. به عنوان مثال تصور کنید یک UAV در حین پرواز با یک پرنده برخورد می‌کند و به سبب آن، یکی از پراب‌های UAV مسدود می‌شود. این اتفاق می‌تواند باعث دو نوع خطای قابل توجه شود. اینکه پراب به طور کامل از کار افتاده است یا شروع به ارسال اطلاعات اشتباه خطرناک کند. هر دو نوع این خطاها می‌تواند به طور بالقوه منجر به عدم محاسبه صحیح اطلاعات از سوی کامپیوتر کنترل پرواز و به دنبال آن عدم ارائه خروجی مطلوب به هر یک از زیر سیستم‌های کنترلی و در نهایت بروز فاجعه شود. بنابراین می‌توان گفت رعایت افزونگی در سیستم‌هایی با سطح DAL A ضروری است.
افزونگی مبتنی بر رای‌گیری ساده
یک سیستم با افزونگی سه‌گانه نوعی تحمل‌پذیری در برابر خطا است که در آن یک سیستم به طور فعال کنترل هواپیما را بر عهده دارد و دو سیستم اضافی دیگر در حالت آماده‌کار هستند. در صورت بروز مشکل برای سیستم فعال اصلی، هر یک از این دو مورد اضافی می‌توانند بلافاصله جایگزین شده و عملیات کنترل را بر عهده بگیرند. در واقع سیستم‌های اضافی به طور موازی با سیستم فعال اصلی و از طریق حسگرها و کامپیوتر کنترل پرواز مستقل، در حال اجرای الگوریتم‌های مربوط به خود هستند. یک طرح رای‌گیری برای مقایسه خروجی‌ها وجود دارد که مشخص می‌کند در صورت بروز خرابی در سیستم اصلی، کدام یک از دو سیستم اضافی ادامه کنترل پرواز را بدست گیرد. منطق رای‌گیری بر اساس مفهوم اکثریت است. در صورت وجود یک اختلاف در خروجی‌ها، منطق رای‌گیری باعث غیرفعال شدن خروجی دستگاهی که اختلاف را ایجاد کرده است، می‌شود.
با این حال، یک معماری با افزونگی سه‌گانه نیز نمی‌تواند احتمال خطای کمتر از 10-9 را در هر ساعت پرواز تضمین کند. برای دستیابی به گواهینامه ایمنی، طراح سیستم باید نشان دهد که هواپیما می‌تواند کاملا در برابر از دست دادن سیستم فعال اصلی مقاومت کند.
شکل 1- ساختار افزونگی مبتنی بر رای‌گیری ساده
در یک معماری که افزونگی آن بر اساس کانال‌های مشابه بنا شده است، در برابر وقوع یک خرابی حالت مشترک که منجر به از دست رفتن همه کانال‌ها می‌شود، آسیب‌پذیر است. خرابی‌های حالت مشترک مانند صاعقه، تداخلات الکترومغناطیسی و انفجار غیرقابل پیش‌بینی و پیشگیری هستند. باگ‌های نرم‌افزاری نوع دیگری از خرابی‌های حالت مشترک بوده که به دلیل پیچیدگی برنامه‌های کاربردی هوایی و وجود صدها هزار خط کد، امکان تست هر باگ نرم‌افزاری یا ترکیبی از آن‌ها وجود ندارد.
تقویت افزونگی با ناهمگونی و رای‌گیری پیچیده
ناهمگونی در افزونگی می‌تواند مانع بسیاری از خرابی‌های حالت مشترک شود. این ناهمگونی می‌تواند از طریق دو یا چند نوع پردازنده مختلف با نرم‌افزار متفاوت یا سیستم‌های جایگزینی که از نوع متفاوتی از حسگر و عملگرها نسبت به سیستم اصلی استفاده می‌کنند، بدست آید. با اجرای سیستم‌عامل‌ها و برنامه‌های متفاوت روی سخت‌افزار ناهمگن (Dissimilar)، طراح سیستم می‌تواند یک لایه محافظ اضافی در مقابل باگ‌های نرم‌افزاری ایجاد کنند.
علاوه بر این، یک معماری با سطح DAL A نیازمند سیستم رای‌گیری هوشمندتری برای مشخص کردن اینکه کدام یک از دو سیستم آماده به کار، باید جایگزین سیستم اصلی خراب شوند، خواهد بود. طرح رای‌گیری بیزانسی[6] (برگرفته از مفهوم مسئله ژنرال‌های بیزانسی) یک روش پیشرفته است که در آن رای‌گیری با استفاده از یک تحلیل پیچیده روی پارامترهای مختلف و احتمال دقت بیشتر یک سیستم در اجرای دستورالعمل‌ها نسبت به سایر سیستم‌ها، انجام می‌شود.
مثال‌هایی از سیستم‌هایی با افزونگی زیاد
یک مثال بارز از سیستمی با افزونگی قدرتمند، ناوگان شاتل فضایی ناسا است. کامپیوترهای کنترل عملیات پرواز و عملیات در شاتل‌ها به گونه‌ای طراحی شده‌اند که می‌توانند تا چند سطح از خرابی در اجزای خود را بدون به خطر افتادن عملیات، تحمل کنند. این سطح بالا از تحمل‌پذیری خرابی از طریق پنج کامپیوتر که چهار مورد آن نرم‌افزار مشابه دارند، بدست آمده است. کامپیوتر پنجم به طور مستقل بوده و برای جلوگیری از مواجهه با مشکلات نرم‌افزاری مشترک، از یک نرم‌افزار متفاوت میزبانی می‌کند.
ایرباس نمونه‌های بیشتری از افزونگی را ارائه می‌دهد. برای مثال A320 شامل پنج کامپیوتر ناهمگن است که چهار نرم‌افزار متفاوت را اجرا می‌کنند. هواپیماهای A330 و A340 دارای سه کامپیوتر کنترل پرواز اولیه و دو کامپیوتر کنترل پرواز ثانویه است.
شکل 2- افزونگی کامپیوتر کنترل پرواز در هواپیماهای A340 و A330
به طور مشابه بوئینگ 777 با سطح بالایی از افزونگی طراحی شده است. در این هواپیما سه کامپیوتر کنترل پرواز تعبیه شده است (شکل 4). هر کدام از این کامپیوترها خود دارای 3 ماژول سخت‌افزاری متفاوت است که در آن از پردازنده‌های متفاوتی از سه شرکت مختلف (اینتل، AMD و موتورولا( و حتی منابع تغذیه متفاوت استفاده شده است. ارتباط بین کامپیوترهای پرواز نیز از طریق 3 شبکه ارتباطی ARINC 629 و به طور مجزا تامین می‌شود. بوئینگ برای برنامه نویسی این کامپیوترها از سه تیم تخصصی مختلف استفاده کرده است که آن‌ها نیز برای هر پردازنده، از کامپایلر متفاوتی بهره گرفته‌اند. مسئله دیگر در این معماری چیدمان سخت‌افزاری تجهیزات در سطح هواپیما است. سه شبکه پر سرعت ARINC 629 در سمت چپ، مرکز و سمت راست هواپیما از نوک به دم هواپیما کشیده شده‌اند. همچنین کامپیوترهای کنترل پرواز نیز هر کدام در محل متفاوتی از هواپیما (بخش اویونیک، جلو و انتهای هواپیما) نصب شده‌اند. این پیچیدگی در افزونگی باعث شد تا آن را معماری ناهمگن با افزونگی 3×3 بنامند.
شکل 3- دستیابی به احتمال خطای کمتر از 10-9 در هر ساعت پرواز با استفاده از افزونگی ناهمگن
در این طراحی هر کدام از پردازنده‌های یک کامپیوتر کنترل پرواز تنها به یک منبع داده به عنوان ورودی متکی نیستند. آنان داده‌ها را از حسگرهای مختلف، خلبان و کمک‌خلبان جمع‌آوری می‌کنند. بنابراین خطاهای حالت مشترک در ورودی‌های پردازنده نیز تا حدودی حذف می‌شود. در واقع معماری کنترل پرواز هواپیمای 777 را می‌توان یک مثال شفاف از حل مسئله ژنرال‌های بیزانسی دانست که در آن هر پردازنده و در سطح بالاتر، سیستم کنترل پرواز تنها به یک منبع ورودی از اطلاعات وابسته نیستند.
شکل 4- معماری سیستم کنترل پرواز هواپیمای 777، افزونگی 3×3
طراحی یک معماری با تحمل‌پذیری خطا
در حال حاضر شرکت‌های زیادی در زمینه تولید کامپیوترهای تک بوردی (SBC) فعالیت می‌کنند که باعث شده است تنوع زیادی از آن‌ها را در بازار شاهد باشیم. با این حال تعداد محدودی از این شرکت‌ها با تکیه بر کاربردهای هوایی، محصولات خود را مطابق استانداردهای ایمنی هوانوردی عرضه می‌کنند.
کورتیس‌رایت از جمله شرکت‌های مطرح در زمینه ساخت SBC است که با تکیه بر مفهوم COTS توانسته است بوردهایی آماده دریافت گواهینامه ایمنی تولید کند. سخت‌افزار این بوردها مطابق استاندارد DO-254 بوده و شامل درایورهای پشتیبانی برای معروف‌ترین شرکت‌های ارائه دهنده نرم‌افزار همچون Green Hills، Wind River، Lynx و Sysgo است. از جمله این بوردها می‌توان به VPX3-152 اشاره کرد که طراحی آن نیازمندی‌های DAL A را برآورده می‌کند. این محصول دارای مجموعه کاملی از درایورهای سیستم‌عامل INTEGRITY-178 tuMP است. شرکت Green Hills این سیستم‌عامل را مطابق با استانداردهای DO-178 و ARINC-653-1 طراحی کرده است.
شکل 5- بورد VPX3-152 شرکت کورتیس رایت مطابق استاندارد DO-254
محصول دیگر کورتیس‌رایت بورد VPX-1220 است که می‌تواند گواهینامه ایمنی DAL-C را اخذ کند. این بورد از نسل هفتم پردازنده‌های اینتل بهره می‌برد و می‌توان سیستم‌عامل LynxOS178 را روی آن پیاده‌سازی کرد.
از مرکوری سیستمز می‌توان به عنوان یکی دیگر از شرکت‌های مطرح در زمینه ساخت SBCها با مشخصات هوایی نام برد. این شرکت طیف وسیعی از بوردهای پردازنده مبتنی بر میکروپروسسور و FPGA و همچنین بوردهای واسط گذرگاه داده مطابق با سطوح مختلف تضمین طراحی در اختیار مشتریان خود قرار می‌دهد. به عنوان نمونه می‌توان به بورد BuiltSAFE MFCC-8557 اشاره کرد که برای کاربردهایی با DAL C طراحی شده و مطابق با استانداردهای DO-178C و DO-254 است. این SBC از پردازنده Freescale QorIQ P3041 استفاده می‌کند و دارای حافظه 2/4 گیگابایتی از نوع DDR3L است. کاربر می‌تواند از سیستم‌عامل‌های VxWorks653 و لینوکس برای میزبانی برنامه‌های کاربردی خود استفاده کند.
شکل 6- بورد BuiltSAFE MFCC-8557 شرکت مرکوری سیستمز برای کاربردهایی با نیازمندی DAL C
منابع: www.mrcy.com، www. mil-embedded.com، www.curtisswright.com
[1] Technical Standard Orders
[2] Society of Automotive Engineers
[3] Radio Technical Commission for Aeronautics
[4] Aerospace Recommended Practice
[5] Design Assurance Level
[6] Byzantine Voting Scheme
ثبت ديدگاه
You must be logged in to post a comment.