بررسی سیستم‌عامل‌های مطلوب برای معماری اویونیک ماژولار یکپارچه

ما را در شبکه‌های اجتماعی دنبال کنید:

20 خرداد 1397

بررسی سیستم‌عامل‌های مطلوب برای معماری اویونیک ماژولار یکپارچه

در سال‌های اخیر برخی صنایع و شرکت‌های فعال کشور که در زمینه هوانوردی فعالیت دارند با مزایا و قابلیت‌های معماری اویونیک ماژولار یکپارچه (IMA) و اهمیت آن در آینده هواگردهای مختلف، آشنا شده‌اند. ما نیز در تعدادی از نسخه‌های این مجله به طور مفصل به جنبه‌های مختلف این نوع معماری و ویژگی‌های آن پرداخته‌ایم. در آن مطالب اشاره شد که یکی از مهم‌ترین بخش‌ها در معماری اویونیک ماژولار یکپارچه، سیستم‌عامل است. حتی در نسخه‌هایی از مجله (شماره 22، 23 و 28) به طور اختصاصی برخی از سیستم‌عامل‌های شناخته‌شده برای این معماری نیز تشریح شد. اما برای بسیاری از طراحان سیستم‌‌های تعبیه شده این سوال مطرح است که کدام سیستم‌عامل برای معماری IMA مناسب‌تر است. در این مقاله ما به بررسی نیازمندی‌های یک سیستم‌عامل مناسب برای کاربردهای هوایی خواهیم پرداخت.

با توجه به رویکرد ماژولارسازی سامانه‌های اویونیک هواپیما و حرکت به سمت معماری IMA در کشور، نیاز است بررسی‌‌های کاملی برای تعیین برخی از ویژگی‌های هر یک از اجزای سیستم انجام شود. در واقع سهم زیاد تجهیزات اویونیک در هزینه نهایی تولید هر هواپیما (35-40 درصد هزینه در هواپیماهای غیرنظامی و بیش از 50 درصد هزینه در هواپیماهای نظامی)، اهمیت چنین تحلیل‌هایی را بیشتر نشان می‌دهد.

تا اواخر قرن 20 میلادی معماری وابسته (Federated) ساختار و مفهوم قالب در توسعه تجهیزات اویونیک بود. وجود عیوب و مشکلات جدی در رابطه با یکپارچه‌سازی سیستم‌ها و اخذ گواهینامه، موجب شد تا طراحان به سمت مفهوم جدیدی با نام معماری اویونیک ماژولار یکپارچه (IMA) حرکت کنند. از جمله ویژگی‌های خاص این معماری می‌توان به موارد زیر اشاره کرد:

  • معماری شبکه باز؛ شبکه منطبق با راهکارها و طراحی‌های استاندارد است.
  • بوردهای محاسباتی واحد؛ ساختار کلی سخت‌افزار شامل مجموعه‌ای از بوردهای (ماژول‌های پردازنده مرکزی، ماژول‌های حافظه، ماژول‌های شبکه و …) واحد در داخل یک کابینت است.
  • سیستم محاسباتی چندکاره؛ این معماری قابلیت اجرای چند برنامه کاربردی مختلف با سطوح امنیتی متفاوت را روی یک پلتفرم سخت‌افزاری مشابه دارد.
  • برنامه‌های کاربردی قابل حمل؛ برنامه‌های کاربردی که به صورت نرم‌افزاری نوشته شده‌اند می‌توانند با تغییرات جزئی در پروژه‌های دیگر که از پلتفرم‌ سخت‌افزاری متفاوت استفاده می‌کنند، اجرا شود.
  • تغییر محل اجرای برنامه کاربردی حین اجرا؛ سخت‌افزار اجرا کننده برنامه‌های کاربردی می‌تواند حین اجرای آن تغییر کنند. بنابراین در هنگام بروز مشکل برای یک ماژول سخت‌افزاری، برنامه‌های کاربردی آن می‌توانند به سایر ماژول‌ها منتقل شوند.

مفهوم IMA از اواخر دهه 1990 میلادی وارد صنعت هوایی شد. ایرباس A380، بوئینگ 787، سوپرجت سوخو، F-22 و رافائل از جمله هواپیماهایی هستند که سیستم‌های اویونیک آن‌ها از مفهوم نسل اول IMA پیروی می‌کند. در سال‌های اخیر نیز اتحادیه اروپا پروژه‌هایی را برای دستیابی به فناوری‌های نسل دوم IMA آغاز کرده است. همگام با انجام این تحقیقات، شرکت‌های نرم‌افزاری نیز سعی در ارائه سیستم‌عامل‌هایی مطابق با نیازمندی‌های صنعت هوایی داشته‌اند. این شرکت‌ها تلاش دارند تا محصول نهایی خود را با چارچوب‌ها و استانداردهای تعیین شده برای آینده معماری IMA سازگار کنند.

استاندارد ARINC 653 مشخصات نرم‌افزاری را برای پارتیشن‌بندی فضا و زمان در سیستم‌عامل‌های بلادرنگ اویونیک ایمنی- بحرانی تعریف می‌کند. بنابراین یکی از اساسی‌ترین ملاک‌های انتخاب سیستم‌عامل برای IMA، سازگاری آن با مشخصات تعیین شده در این استاندارد است. در ادامه مطلب به بیان دقیق‌تر مشخصات سیستم‌عامل مطلوب خواهیم پرداخت.

نیازمندی‌ها برای سیستم‌عامل بلادرنگ مطلوب

برخی از مهم‌ترین نیاز‌مندی‌ها برای تعیین یک سیستم‌عامل بلادرنگ مطلوب در معماری اویونیک ماژولار یکپارچه به شرح زیر است:

  • قابلیت حمل بین چند پلتفرم سخت‌افزاری؛ عدم وابستگی سیستم‌عامل به سخت‌افزار خاص یا حداقل بودن تغییرات نرم‌افزاری کرنل در هنگام جابه‌جایی پلتفرم از نکات قابل توجه در این انتخاب است.
  • پشتیبانی از بخش‌های مختلف استاندارد ARINC 653؛ سیستم‌عامل باید سازگاری کامل با نیازمندی‌های تعیین شده در بخش‌های مختلف این استاندارد (به خصوص بخش‌های اول، دوم و چهارم) داشته باشد.
  • پشتیبانی از رابط‌های استاندارد اویونیک؛ پشتیبانی از رابط‌های استاندارد و رایج اویونیک مانند ARINC 429، AFDX، CAN، MIL-STD 1553 و ARINC 825
  • ابزار پیشرفته؛ محیط توسعه یکپارچه (IDE) ابزاری مانند خطایابی، صحت‌سنجی و شبیه‌سازی
  • شفافیت سیستم‌عامل برای تطبیق با سخت‌افزارهای خاص؛ در دسترس بودن زیرساخت‌های لازم برای توسعه درایورها و بسته‌های پشتبیبانی بورد
  • پشتیبانی از رابط‌های برنامه‌نویسی گرافیکی؛ همچون OpenGL و استاندارد ARINC 661
  • سازگاری و تطبیق با استانداردهای ایمنی
  • پشتیبانی از پردازنده‌های چند هسته‌ای
  • مطابق با شرایط ذکر شده در استاندارد DO-178C؛ شامل نیازمندی‌های سطح-‌ بالا، توسعه مشخصات سطح- پایین، توسعه اسناد برای اجزای نرم‌افزار، توسعه موارد لازم برای صدور گواهینامه، روش‌های فرمال برای صحت‌سنجی اجزای نرم‌افزار

در واقع می‌توان گفت سازگاری با سخت‌افزارها و تطابق با استاندارد‌های هوایی جهت صدور گواهینامه، مهمترین ملاک‌های انتخاب یک سیستم‌عامل بلادرنگ برای کاربردهای اویونیک است.

انواع معماری‌ سیستم‌عامل‌های بلادرنگ

سیستم‌های تعبیه‌شده به طور معمول نیازمندی‌های بسیار متفاوتی با رایانه‌های خانگی دارند. در سیستم‌های تعبیه‌شده معمولا سیستم‌عامل برای اجرای برنامه‌های کاربردی خاص طراحی می‌شود و از این‌رو ایستایی بیشتری نسبت به یک سیستم‌عامل همه منظوره دارد. با این حال با توجه به نیاز ویژگی بلادرنگ بودن، طراحی یک سیستم‌عامل برای سیستم‌های تعبیه شده نیاز به ظرافت خاص دارد. سرویس‌های پایه مانند مدیریت پردازش‌ها، ارتباطات درون پردازشی، رسیدگی به وقفه‌ها یا همگام‌سازی پردازش باید در بهترین نحو ممکن و با استفاده از منابع بسیار محدود انجام شود.

طراحی کرنل یکی از رایج‌ترین معماری‌های سیستم‌عامل است که جداسازی شفاف بین سیستم‌عامل و برنامه‌های کاربردی اجرا شده روی آن را ارائه می‌دهد. در این معماری پردازش‌ها می‌توانند با استفاده از فراخوان سیستم (system calls) به توابع و قابلیت‌های کرنل دسترسی داشته ‌باشند. در واقع فراخوان سیستم یک وقفه نرم‌افزاری است که اجازه سوئیچ از برنامه کاربردی به سیستم‌عامل را فراهم می‌کند.

رویکرد‌های مختلفی همچون روش‌های مبتنی بر کتابخانه، کرنل یکپارچه

[1]، میکروکرنل یا ماشین‌های مجازی برای ساختار یک سیستم‌عامل توسعه یافته‌اند، که هر کدام از آن‌ها پاسخ‌گوی نیازهای خاصی هستند. چالش اصلی چگونگی اجرای موثر برنامه‌های کاربردی روی منابع محدود است به طوری که نیازهایی مانند زمان‌بندی صحیح، کارایی، قابلیت اطمینان و عملکرد درست برطرف شود.

  • معماری مبتنی بر کتابخانه

همه سیستم‌های تعبیه‌شده نیازی به پشتیبانی توسط قابلیت‌های سیستم‌عامل ندارند. در واقع ساده‌ترین سیستم‌های تعبیه‌شده بدون یک سیستم‌عامل صریح و واضح ساخته می‌شوند. چنین سیستمی نیازی به مکانیزم‌های پیچیده یا زمان‌بندی بلادرنگ وظایف همزمان ندارند، بنابراین اجرای آن‌ها با استفاده از یک حلقه اصلی ساده یا رویکرد چرخشی امکان‌پذیر است. علاوه بر این سیستم‌های تعبیه‌شده‌ی شبکه‌های اختصاصی معمولا نیازی به سیستم‌عامل ندارند و تنها یک پروتکل پشته مستقل[2] برای آن‌ها کافی است.

برای مثال در سیستم‌های بدون واحد مدیریت حافظه، سیستم‌عامل بلادرنگ به صورت یک کتابخانه متصل به برنامه‌های کاربردی ساخته می‌شود. نتیجه این کار یک برنامه اجرایی واحد است که می‌تواند در یک فضای آدرس خاص اجرا شود. در این مورد فراخوان سیستم به راحتی اجرا شده و در آن هنگام نیازی به تعویض زمینه (Context-Switch) نیست. علاوه بر این در آغاز کار و هنگام اجرا، نیازی به یک بارگذار برای بارگذاری برنامه‌های کاربردی نخواهد بود.

از طرف دیگر وقتی یک سیستم‌عامل بلادرنگ مبتنی بر کتابخانه روی سیستمی بدون واحد مدیریت حافظه به کار گرفته می‌شود، ما امنیتی روی جداسازی حافظه سخت‌افزار نخواهیم داشت. پیاده‌سازی تمام برنامه‌های کاربردی و فعالیت‌های سیستم‌عامل روی یک فضای آدرس مشابه انجام می‌شود. بنابراین وجود باگ در یک قسمت، به راحتی در تمام سیستم منتشر خواهد شد.

  • معماری کرنل یکپارچه

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

شمای کلی از کرنل یکپارچه

شمای کلی از کرنل یکپارچه

  • معماری میکروکرنل

معماری میکروکرنل با هدف بهبود سازماندهی در کرنل‌های یکپارچه توسعه یافت. فرض اصلی در میکروکرنل، تمرکز بیشتر بر اجرای سرویس‌های غیر ضروری مانند درایور دستگاه‌ها در محیط فضای کاربری است. سرویس‌هایی مثل زمان‌بندی و مدیریت حافظه در خود میکروکرنل جای می‌گیرند. بنابراین می‌توان گفت مزیت میکروکرنل در مقایسه با کرنل یکپارچه، در جداسازی سرویس‌ها از خود کرنل است که منجر به قابلیت اطمینان بیشتر و نگهداری ساده‌تر می‌شود. اما به منظور ایجاد این ساختار، کرنل نیازمند تعداد بسیار زیادی ارتباط درون فرایندی (IPC) و تعویض زمینه است.

شمای کلی از میکروکرنل

شمای کلی از میکروکرنل

  • معماری چند هسته‌ای

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

در هنگام استفاده از معماری چندهسته‌ای، دو روش اساسی برای مدیریت هسته‌ها وجود دارد. در روش چند پردازشی متقارن[3] (SMP) سیستم‌عامل چند هسته را کنترل می‌کند. هنگامی که یک هسته در دسترس باشد، سیستم‌عامل نخ بعدی را روی آن اجرا می‌کند. اما در روش چند پردازشی نامتقارن[4] (AMP) برای هر هسته، یک سیستم‌عامل به کار گرفته می‌شود. سیستم‌عامل‌ها می‌توانند کاملا مشابه به هم بوده یا سیستم‌عامل‌های کاملا متفاوت برای هر هسته در نظر گرفته شود.

مزیت‌ها و معایبی برای هر دو روش وجود دارد و انتخاب گزینه مناسب کاملا به مورد استفاده بستگی دارد. مزیت اصلی روش SMP امکان بالانس کردن نخ‌ها روی هسته‌های مختلف است. علاوه بر این مدیریت و توسعه ساده‌تر تنها یک هسته نسبت به هسته‌های بیشتر ویژگی دیگر این روش است. اما در روش AMP به دلیل نیاز کمتر به همگام‌سازی بین هسته‌ها، کارایی بیشتری وجود دارد. ویژگی دیگر این روش قابلیت اطمینان بالاتر است، زیرا در صورت بروز مشکل برای یک هسته، سایر هسته‌ها می‌توانند بدون مشکل به کار خود ادامه دهند.

  • معماری ماشین‌ مجازی

ایده اصلی سیستم‌های مبتنی بر ماشین‌های مجازی ارائه یک کپی کاملا مشابه از سخت‌افزار در دسترس برای هر ماشین مجازی است. بنابراین یک برنامه کنترلی کوچک برای اختصاص سخت‌افزار موجود به ماشین مجازی مورد نیاز است. این برنامه در اصطلاح ناظر ماشین مجازی یا هایپروایزر نامیده می‌شود. در نسخه قبل مجله نیز به طور مفصل به نحوه کارکرد و قابلیت‌های هایپروایزر پرداختیم. برای مثال با مجازی‌سازی CPU، شما می‌توانید چند CPU مجازی را روی یک هسته یا CPU فیزیکی اجرا کنید.

سیستم‌عامل‌های تعبیه‌شده بلادرنگ

سیستم‌عامل‌های رایجی مانند VxWorks و QNX شامل مجموعه زیادی از رابط‌های برنامه‌نویسی هستند و به حجم زیادی از حافظه نیاز دارند. اینگونه سیستم‌عامل‌ها مناسب سیستم‌هایی با منابع CPU و حافظه زیاد بوده و از قابلیت‌هایی همچون پردازش چند-وظیفه‌ای، محافظت از حافظه، شبکه TCP/IP و رابط‌های برنامه‌نویسی استاندارد POSIX بهره‌ می‌برند که برای کاربرد گره‌های شبکه حسگر مناسب نیست.

سیستم‌عامل بلادرنگ QNX Neutrino از معماری میکروکرنل و الگوی زمانبندی رایج در SMP استفاده می‌کند. این سیستم‌عامل هنگامی که تمامی هسته‌ها برای برنامه‌ریزی و زمان‌بندی نخ‌ها تنظیم شده باشند، امکان انتقال نخ‌ها از یک پردازنده به دیگری را فراهم می‌کند. در این سیستم‌عامل می‌توان از روش دیگری برای مدیریت هسته‌ها استفاده کرد که چند پردازشی محدود[5] (BMP) می‌گویند. در این روش مشابه با SMP تنها یک نمونه از سیستم‌عامل تمامی پردازنده‌ها را کنترل می‌کند، اما در آن امکان انتقال نخ‌ها از یک هسته به دیگری وجود ندارد.

سیستم‌عامل بلادرنگ VxWorks از معماری کرنل یکپارچه استفاده می‌کند و قابلیت چند پردازشی به هر دو روش SMP و AMP در آن فراهم است. در حالت SMP این سیستم‌عامل می‌تواند به صورت خودکار بالانس نخ‌ها را بین هسته‌های مختلف سیستم ایجاد کند. یکی از نقاط قوت این سیستم‌عامل امنیت بالا و تضمین بلادرنگ بودن عملیات‌‌ها است. این ویژگی‌ها در کنار پشتیبانی از طیف گسترده‌ای از سخت‌افزار‌ها باعث شده است تا از VxWorks به عنوان محبوب‌ترین سیستم‌عامل بلادرنگ برای سیستم‌های تعبیه شده یاد شود. در نسخه‌های جدید این سیستم‌عامل پروتکل‌هایی مانند SSL، SSH و IPsec برای امنیت انتقال اطلاعات و پروتکل افزونگی روتر مجازی برای بحث قابلیت اطمینان شبکه‌ افزوده شده است.

در سال 1986 رایج‌ترین سیستم‌عامل بلادرنگ منبع باز با نام eCos[6] منتشر شد. این سیستم‌عامل یک ابزار پیکر‌بندی گرافیکی و یک ابزار پیکر‌بندی کد‌نویسی را برای شخصی‌سازی و تطبیق خود با نیازمندی‌های برنامه‌های کاربردی خاص ارائه کرد. پیکر‌بندی کرنل می‌تواند از طریق برنامه‌ریز bitmap یا برنامه‌ریز صف چند سطحی انجام شود. هر دو این روش‌ها می‌توانند از برنامه‌ریزی مبتنی بر اولویت (تا 32 سطح مختلف) بهره‌مند شوند.

در حال حاضر سیستم‌عامل‌هایی همچون لینوکس به دلیل قابلیت پشتیبانی از برنامه‌های کاربردی بلادرنگ نرم[7] در برخی از سیستم‌های تعبیه‌شده مورد استفاده قرار می‌گیرند. لینوکس همچنین نسخه‌های توسعه‌ یافته‌ای دارد که قابلیت پشتیبانی از برنامه‌های کاربردی بلادرنگ سخت را دارند. از جمله این سیستم‌عامل‌ها می‌توان به RTAI اشاره کرد که تنها برای سیستم‌های بلادرنگ بزرگ مناسب هستند. از دیگر نسخه‌های لینوکس می‌توان به Embedded Linux و µClinux اشاره کرد که سازگاری بیشتری با سیستم‌های تعبیه شده دارند، اما بلادرنگ نیستند. این نسخه‌ها بسیار مشابه لینوکس از معماری استفاده می‌کنند، با این تفاوت که فاقد سخت‌افزار مدیریت حافظه هستند.

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

مشخصات سیستم‌های تعبیه‌شده توسط RTOS

مشخصات سیستم‌های تعبیه‌شده توسط RTOS

سیستم‌عامل بلادرنگ برای سیستم‌های ایمنی- بحرانی

منظور از سیستم‌های ایمنی- بحرانی کامپیوترهایی است که مسئولیت اجرای وظایف بحرانی را بر عهده دارند. معمولا در اینگونه‌ سیستم‌ها یک انحراف کوچک در شرایط محیطی یا رفتار سیستم، بروز یک عیب و وقوع خطا منجر به وضعیت خطرناک و حتی فاجعه‌آمیز می‌شود. بنابراین در سیستم‌های ایمنی-بحرانی نه تنها باید رفتار بلادرنگ تضمین شود، بلکه نیازمند قابلیت اطمینان مطلق و دردسترس بودن دائمی دستگاه‌های جانبی هستند.

روند تغییر فناوری در سیستم‌های اویونیک به سمت تلفیق برنامه‌های کاربردی با سطوح حساسیت متفاوت روی یک پلتفرم سخت‌افزاری مشابه است. از این‌رو سیستم‌عامل‌ها در مورد برنامه‌های ایمنی- بحرانی با چالش زمان‌بندی پردازنده و دسترسی به منابع مواجه هستند.

در حوزه اویونیک بیشترین فعالیت‌ها جهت دستیابی به این اهداف تحت عنوان IMA انجام می‌شود. همانطور که در ابتدای این مطلب بیان شد، استاندارد ARINC 653 مشخصاتی را برای رابط برنامه‌نویسی و روش‌های پارتیشن‌بندی زمان و فضا در سیستم‌عامل‌های بلادرنگ تعریف می‌کند. این استاندارد یک رابط برنامه‌نویسی تحت نام APEX برای پارتیشن‌بندی زمان و فضا تعریف می‌کند تا در سیستم‌هایی که چند‌ برنامه کاربردی از یک پردازنده و حافظه اشتراکی استفاده می‌کنند، تضمینی برای عدم تاثیرگذاری یک برنامه معیوب بر دیگر برنامه‌ها باشد. هر پارتیشن در یک سیستم مبتنی بر ARINC 653 برای یک برنامه کاربردی ایجاد می‌شود و فضای حافظه اختصاصی به آن تعلق می‌گیرد.

رویکرد «چند سطح مستقل امنیت و ایمنی[8]» (MILS) به منظور ارائه یک چارچوب با قابلیت استفاده مجدد برای صحت‌سنجی سیستم‌هایی با تضمین امنیت بالا ایجاد شده است. در معماری MILS، کرنل تنها مسئول اجرای 4 کار ساده شامل جداسازی داده‌ها، کنترل جریان اطلاعات، پردازش دوره‌‌ها و همچنین سیاست‌های محدودسازی آسیب‌ها است. هر کدام از این وظایف پاسخ‌گوی یک یا چند تهدید اساسی علیه امنیت سیستم است. سیستم‌عامل‌های LynxSecure و PikeOS مثال‌هایی از سیستم‌عامل مبتنی بر MILS هستند که به طور ویژه در صنایع نظامی و اویونیک استفاده می‌شوند.

LynxSecure محیطی قدرتمند را فراهم می‌کند که در آن سیستم‌عامل‌های مختلف امن و غیر امن می‌توانند به طور همزمان و حتی بدون سازگاری در امنیت، قابلیت اطمینان و داده‌ها، اجرا شوند. در واقع LynxSecure نسخه‌ای از سیستم‌عامل بلادرنگ LynxOS است که به آن قابلیت پارتیشن‌بندی زمان و فضا و همچنین مجازی‌سازی سیستم‌عامل اضافه شده است.

سیستم‌عامل بلادرنگ PikeOS (در نسخه 28 مجله به طور مفصل ویژگی‌ها و قابلیت‌های آن معرفی شد) از معماری مبتنی بر میکروکرنل استفاده می‌کند و گزینه مناسبی برای سیستم‌های تعبیه‌شده ایمنی- امنیتی- بحرانی است. این سیستم‌عامل یک محیط پارتیشن‌بندی شده برای چند سیستم‌عامل با اهداف طراحی مختلف و نیازمندی‌های ایمنی و امنیتی متفاوت داخل یک ماشین سخت‌افزاری واحد ایجاد می‌کند. هدف PikeOS ارائه پارتیشن‌هایی شامل مجموعه‌ای از منابع سیستم‌ است. زمان پردازش را می‌توان به عنوان نمونه‌ای از این منابع در نظر گرفت. بنابراین انتظار می‌رود که پارتیشن‌ها میزبان سیستم‌عامل‌هایی با نیازمندی‌های متفاوت برای زمان‌های اجرا باشند. در واقع PikeOS برای رسیدن به مفهوم MILS ترکیبی از پارتیشن‌بندی منابع و مجازی‌سازی را به کار می‌گیرد. این سیستم‌عامل دارای یک بخش نظارت بر سلامت داخلی است که تمامی ویژگی‌های ذکر شده در استاندارد ARINC 653 را اجرا می‌کند.

[9]RTEMS یک سیستم‌عامل منبع‌باز و رایگان است که با معماری MILS سازگاری نداشته و برای کاربردهای نظامی و اویونیک مورد استفاده قرار می‌گیرد. می‌توان گفت RTEMS برای سه لایه پشتیبانی سخت‌افزاری، کرنل و رابط برنامه‌نویسی (API) تعریف می‌شود. کاربر برنامه‌ کاربردی خود را با استفاده از APIهای موجود توسعه می‌دهد. لایه پشتیبانی سخت‌افزار نیز فایل‌ها و کتابخانه‌های مربوط به پردازنده و اجزای بورد سخت‌افزاری را فراهم می‌کند.

از دیگر سیستم‌عامل‌های مطرح بازار که مطابق با استاندارد ARINC 653 طراحی شده‌اند می‌توان به VxWorks 653 اشاره کرد که در نسخه‌ 23 مجله به طور مفصل معرفی شد. این سیستم‌عامل از معماری میکروکرنل استفاده می‌کند و با معماری MILS سازگاری دارد. در واقع این نسخه از سیستم‌عامل VxWorks با هدف بکارگیری در سیستم‌های اویونیک مبتنی بر IMA طراحی شده و از نظر ایمنی در سطح A استاندارد DO-178C قرار دارد. نکته قابل توجه دیگر در مورد این سیستم‌عامل امکان استفاده از رابط‌های کاربری با پشتیبانی از زبان‌های برنامه‌نویسی مختلف همچون C، C++، Java و Ada است. این سیستم‌عامل از یک واحد نظارت بر سلامت بهره‌ می‌برد که مسئولیت نظارت و گزارش خرابی‌ها و شکست‌ها در سخت‌افزار، برنامه‌های کاربردی و سیستم‌عامل را بر عهده دارد. این واحد با ایزوله کردن خرابی‌ها، از انتشار شکست و خرابی به بخش‌های دیگر سیستم جلوگیری می‌کند.

در جدول زیر خلاصه‌ای از برخی ویژگی‌های سیستم‌عامل‌های معرفی شده در این بخش مشاهده می‌شود. تمام این سیستم‌عامل‌ها مطابق با مشخصات استاندارد ARINC بوده و در آن‌ها تمرکز اصلی بر امنیت و ایمنی است. اما در آن‌ها برخی از نیازمندی‌های اساسی برای سیستم‌های تعبیه‌شده مثل محدودیت منابع و بلادرنگ بودن به طور ویژه مورد توجه قرار نگرفته است. علاوه ‌بر این به نظر می‌رسد رسیدگی به عیب‌ها و خطاها، نگرانی اصلی برای این سیستم‌عامل‌ها نیست.

مشخصات سیستم‌های تعبیه‌شده RTOS برای اویونیک

مشخصات سیستم‌های تعبیه‌شده RTOS برای اویونیک

جمع‌بندی

در این مطلب ما ابتدا به برخی از نیازمندی‌های یک سیستم‌عامل مطلوب برای کاربرد در معماری اویونیک ماژولار یکپارچه پرداختیم. سپس چند نوع از سیستم‌عامل‌های بلادرنگ و غیر بلادرنگ که می‌توانند در سیستم‌های تعبیه‌شده مورد استفاده قرار گیرند، معرفی شد. در نهایت می‌توان گفت انتخاب سیستم‌عامل مطلوب کاملا وابسته به کاربرد و نوع سخت‌افزار انتخابی است. ما در این مطلب سعی کردیم مقایسه‌ای اجمالی روی تعدادی از ویژگی‌های سیستم‌عامل‌های مطرح موجود در بازار داشته باشیم، با این‌حال ممکن است جنبه‌هایی دیگر از این سیستم‌عامل‌ها نیز بر انتخاب گزینه مطلوب تاثیرگذار باشند. همچنین سیستم‌عامل‌های دیگری همچون LynxOS-178، LynxOS-SE RTOS و Integrity نیز وجود دارند که می‌توانند برای بکارگیری در معماری IMA مورد بررسی قرار گیرند.

در این میان سیستم‌عامل‌های PikeOS و VxWorks با توجه به قابلیت‌های گسترده و پشتیبانی از سخت‌افزارهای مختلف، بیشتر از سایر سیستم‌عامل‌ها مورد توجه صنایع و به خصوص صنعت هوایی قرار گرفته‌اند. در حال حاضر خانواده محصولات VxWorks از طیف وسیعی از پردازنده‌های 32 و 64 بیتی و همچنین پردازنده‌هایی با معماری چند هسته‌ای پشتیبانی می‌کند. قابلیت‌های گسترده این سیستم‌عامل باعث شده است تا شرکت‌هایی معتبری همچون ایرباس، بوئینگ، میتسوبیشی، نورثروپ گرومن و البته ناسا از VxWorks در توسعه محصولات خود استفاده کنند.

[1] Monolithic Kernels

[2] Stand-Alone Protocol Stack

[3] Symmetric Multiprocessing

[4] Asymmetric Multiprocessing

[5] Bound Multiprocessing

[6] Embedded Configurable Operating System

[7] Soft Real-time Applications

[8] Multiple Independent Levels Of Security And Safety

[9] Real-time Executive For Multiprocessor Systems

اگر مطلب برای شما مفید بود آن را در شبکه‌های اجتماعی به اشتراک بگذارید. بسترهای خود را انتخاب کنید!

سایر مقالات علمی و محتوای آموزشی پژوهشکده اویونیک