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

معماری وابسته (Federated)

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

شکل 1 سیستم فرود هواپیما را در معماری وابسته نشان می‌دهد. این سیستم از 3 واحد مجزا که به وسیله کانال‌های ارتباطی اختصاصی به یکدیگر متصل شده‌اند، تشکیل می‌شود. یکی از آن‌ها رابط بخش کاربری است که شامل واحد پردازش سیستم فرود، نمایشگرها و کنترل سامانه می‌شود. این رابط کاربری برای کنترل بازخوردهای دریافت شده از بخش سنسورها استفاده می‌شود. در این مثال، 3 واحد پردازش مرکزی (CPU)، 5 ماژول I/O، ماژول رابط شبکه و چهار کانال ارتباطی فیزیکی وجود دارد.

معماری وابسته سیستم فرودشکل1- معماری وابسته سیستم فرود

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

شکل 2 نشان می‌دهد که داده‌ها در معماری وابسته به اشتراک گذاشته نمی‌شوند و هر یک از سیستم‌ها به عنوان یک بخش مجزا سخت‌افزار و نرم‌افزار ویژه خود را دارد.

اشتراک گذاری داده در سیستم Stand-alone در معماری وابسته

شکل 2-اشتراک گذاری داده در سیستم Stand-alone در معماری وابسته

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

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

در معماری اویونیک ماژولار یکپارچه پردازنده‌های متعدد و جدا از هم و همچنین واحدهای قابل تعویض[3] (LRU) با تعداد کمی واحدهای پردازش متمرکز جایگزین می‌شوند. این تغییر در سخت‌افزار به طور قابل توجهی وزن و عملیات تعمیر و نگهداری در نسل جدید هواپیماهای تجاری را کاهش می‌دهد. برای انتقال سیستم‌های اویونیکی از معماری وابسته به IMA دو نوع معماری پیش روی طراحان قرار دارد. این دو راهکار در اصطلاح با عنوان معماری باز و معماری بسته شناخته می‌شوند.

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

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

در معماری‌های IMA قابلیت اشتراک گذاری داده وجود دارد از اینرو منابع I/O بین توابع اویونیکی مختلف تقسیم‌بندی می‌شوند (شکل 3). بنابراین توابع نرم‌افزاری قرار گرفته در پردازنده‌ها می‌توانند اطلاعات ورودی خود را از ماژول‌های I/O مختلف سراسر سیستم دریافت کنند.

اشتراک گذاری داده در معماری IMA

شکل 3-اشتراک گذاری داده در معماری IMA

 یکی از ویژگی‌های اصلی ماژول‌های قابل تعویض[4] (LRM) در معماری IMA تطابق آن‌ها با استانداردهای اختصاصی تعریف شده این معماری است. برای سهولت در پیاده‌سازی و کاهش سخت‌افزارهای منسوخ، ماژول‌ها یک طرح فیزیکی استاندارد متناسب با محل نصب‌شان در پلتفرم دارند.

یکی دیگر از فواید این معماری، پارتیشن‌بندی ذاتی بین توابع اویونیکی است که موجب تسهیل در صدور گواهینامه‌های لازم می‌شود. ویژگی دیگر IMA استفاده از گذرگاه‌های اویونیکی دیجیتال مدرن مانند ARINC 659، ARINC 629، MIL-STD 1553 و دیگر گذرگاه‌های اختصاصی پرسرعت و امن است.

شکل 4، پیاده‌سازی سیستم فرود را با استفاده از معماری IMA بسته نشان می‌دهد که شامل مجموعه‌ای بهینه از منابع مشترک است. همچنین این معماری منابع فیزیکی کمتری نسبت به سیستم وابسته استفاده می‌کند. حتی تعداد واحدهای پردازش مرکزی (CPU) از 3 به 1 کاهش پیدا کرده است و در نهایت تعداد کانال‌های ارتباطی فیزیکی از 4 به 1 کاهش پیدا می‌کند.

معماری IMA سیستم فرود هواپیما

شکل 4- معماری IMA سیستم فرود هواپیما

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

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

معماری سیستم‌های اویونیک روند رو به رشدی به سمت کامپیوترهای اویونیک همه منظوره[5] دارد که تحت عنوان پلتفرم معرفی می‌شوند. یک پلتفرم به خودی خود توابع اویونیکی را انجام نمی‌دهد؛ بلکه ارتباطات، محاسبات و منابع حافظه را برای برنامه‌های کاربردی (نرم‌افزاری) اویونیک فراهم می‌کند (شکل 5). در واقع می‌توان گفت پلتفرم شبیه به دسکتاپ یک PC است که منابع مورد نیاز (سخت‌افزاری، ارتباطاتی، حافظه و سیستم عامل ) برنامه‌های کاربردی را فراهم می‌کند.

اشتراک پلتفرم سیستم معماری IMA باز با یک برنامه کاربردی

شکل 5- اشتراک پلتفرم سیستم معماری IMA باز با یک برنامه کاربردی

این معماری دارای یک پردازنده عمومی است که چند عملیات سیستمی را میزبانی می‌کند. هسته نرم‌افزاری درون پلتفرم وظیفه پارتیشن‌بندی توابع را بر عهده دارد. از سوی دیگر پلتفرم‌ها ماژول‌های دیجیتالی مشترک با رابط‌های ورودی/خروجی استاندارد هستند. داده‌های جمع‌آوری شده توسط سنسورها و دیگر تجهیزات از طریق شبکه‌ای مثل AFDX به رابط‌های ورودی/خروجی و در ادامه به پلتفرم‌ها منتقل می‌شوند.

هر کامپیوتر اویونیک یک رابط استاندارد سیستم باز دارد که به عنوان رابط برنامه نویسی کاربردی (API) در نظر گرفته می‌شود و شبیه به استاندارد ARINC 653 است. بهره‌گیری از چنین رابطی موجب شود شرکت‌های ثالث بتوانند برنامه‌های کاربردی پلتفرم را توسعه دهند.

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

معماری کامپیوتر اویونیک

شکل 6- معماری کامپیوتر اویونیک

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

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

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

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

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

نتیجه گیری

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

منبع:

http://www.nasscom.in

پانویس ها:

[1]  data transfer standard

[2]  Integrated Modular Avionics

[3] line replaceable units

[4] replaceable modules

[5] general-purpose avionics computers

[6] Intellectual Property Rights

[7] Commercial Off-The Shelf