از توسعه سیستم‌های اویونیکی مدل محور تا اویونیک ‘Plug&Fly’

[1] یا بهینه‌سازی معماری اویونیک کامپیوتری از روش‌های پیشنهادی هستند. اما در حال حاضر برای حل بسیاری از مسائل دیگر، هنوز در سطح تعریف دقیق مفاهیم هستیم. در این مقاله خلاصه‌ای از تحقیقات گذشته، حال حاضر و نتایج بدست آمده از تحقیقات دانشگاه اشتوتگارت و نحوه دستیابی به Plug&fly شرح داده می‌شود. یکی از نتایج میان مدت این تحقیقات رویکرد مدل معماری اویونیک باز^[2] (OAAM) است.

مقدمه

معماری IMA که امروزه یکی از متداول‌ترین معماری‌های اویونیک است، بستری را فراهم می‌کند تا عملیات‌های مختلف اویونیک بتوانند به صورت یکپارچه و با استفاده از منابع اشتراکی اجرا شوند. در واقع این معماری که در هواپیمای نظامی و غیرنظامی کاربرد دارد، منابع را بین توابع مختلف سیستم‌های ایمنی- بحرانی و ایمنی- غیربحرانی به اشتراک می‌گذارد. توابع سیستم به عنوان پارتیشن‌های نرم‌افزاری جداگانه بارگذاری می‌شوند. از این‌رو ماژول‌های I/O و محاسباتی در نرم‌افزار پیکربندی می‌شوند تا در چندین تابع سیستم مورد استفاده قرار گیرند.

اگر چه رویکرد IMA مقدار سخت‌افزار، هزینه، وزن و فضا را کاهش می‌دهد اما دو چالش اساسی دارد: 1- درجه آزادی طراحی و 2- تعداد بسیار زیاد پارامترهای پیکربندی. در بحث طراحی سوالاتی مانند ساده‌ترین معماری کدام است؟ یا چه تعداد ماژول محاسباتی مورد نیاز است؟ یا بهینه‌ترین توزیع I/O بین ماژول‌ها چیست؟ مطرح می‌شود. در بحث پیکر‌بندی نیز می‌توان گفت سیستم‌های IMA امروزی دارای پارامترهای بسیار زیادی هستند که می‌توانند باعث بروز خطا و عدم ثبات در سیستم شوند.

از حدود 10 سال پیش برای بهبود این وضعیت یک مدل خاص دامنه^[3] (نوعی مدل‌سازی که مخصوص حوزه خاصی از دانش است) برای طراحی معماری‌های اویونیک کامپیوتری^[4] (CAD) توسعه پیدا کرد. این مدل ضمن حفظ معماری‌کلی، نیازمندی‌های سیستم مانند توابع، منابع مورد نیاز و محدودیت‌های ایمنی را نیز اضافه می‌کند.

در این روش مدل سازی برای مرحله طراحی تنها نیاز به حداقل اطلاعات ضروری سیستم‌ها است. این مدل می‌تواند به صورت خودکار برای نمونه در مسائلی مانند تخصیص توابع، مسیریابی و اندازه ماژول‌ها به مسئله بهینه‌سازی ریاضی تبدیل شود. روند پیاده‌سازی‌ها در روش طراحی IMA مدل محور در شکل زیر نشان داده شده است.

فرآیند روش طراحی معماری IMA مدل‌‌- محور

مدل‌سازی اویونیک

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

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

اولین نمونه از مدل معماری اویونیک خاص- دامنه در چند برنامه تحقیقاتی فضایی و هوایی استفاده شد. در اواخر سال 2017 نسل دوم مدل خاص دامنه ارائه شد که بیشتر روی سخت‌افزار و گذرگاه داده تمرکز دارد. این نسل از مدل به صورت منبع باز در دسترس قرار گرفته است و به عنوان مدل معماری اویونیک باز (OAAM) شناخته می‌شود.

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

بهینه‌سازی معماری اویونیک

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

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

روال‌های بهینه‌سازی معماری اویونیک در پروژه plug&fly

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

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

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

راه‌اندازی خودکار سیستم‌های ایمنی- بحرانی مدل محور (روش پلتفرم اویونیک انعطاف‌پذیر^[5])

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

لازم به ذکر است محققان تاکنون از این روش برای طراحی معماری اویونیک و تجهیز دو هواپیمای هوانوردی عمومی طبق رویکرد fly-by-wire استفاده کرده‌اند.

اویونیک خودتنظیم‌کننده (پلتفرم اویونیک انطباقی)

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

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

محققان ابتدا برای تست این فناوری، سعی در استفاده از آن در سیستم‌هایی با سطح ایمنی کمتر داشته‌اند. از همین‌رو یک سیستم مدیریت کابین انطباقی^[6] (ACMS) طراحی و ساخته شد. این سیستم تقریبا بدون هیچ پیکر‌بندی ابتدایی بود و آزمایش‌ها نشان داد که می‌تواند حدودا 2 دقیقه بعد از نصب، تنظیمات خود را تکمیل و فرآیند عملیات عادی خود را آغاز کند.

اویونیک Plug&Fly

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

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

مفهوم سیستم اویونیک Plug&Fly (PAFA) که قابلیت‌ها و توپولوژی را روی خود تشخیص می‌دهد و این اطلاعات را در یک مدل فرمال مدیریت می‌کند.

مدل معماری اویونیک باز (OAAM)

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

ساختار مدل معماری اویونیک باز در 9 لایه اصلی

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

به طور فنی OAAM با زبان مدل‌سازی ECORE از چارچوب مدل‌سازی اکلیپس^[7] (EMF) تحقق پیدا کرده است. چارچوب مدل‌سازی اکلیپس یک محیط توسعه نرم‌افزاری چندزبانه برای محیط توسعه مجتمع با قابلیت اضافه کردن افزونه است. مدل‌های OAAM درون یک نمونه اکلیپس خاص ویرایش، صحت‌سنجی و ارزیابی می‌شوند. در واقع این چارچوب تنها مفهوم مدل‌سازی است که منجر به ساختارهای قطعی شده و اجازه یکپارچه‌سازی در سیستم ایمنی- بحرانی embedded را می‌دهد. مدل و چارچوب اکلیپس OAAM که در شکل زیر نشان داده شده است، به عنوان یک منبع باز در آدرس www.oaam.de موجود است.

چارچوب ویرایش OAAM در Eclipse IDE

جمع‌بندی

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

[1] Adaptive Avionics

[2] open avionics architecture model

[3] Domain- Specific Model

[4] Computer-aided Design

[5] Flexible Avionics Platform Approach

[6] Adaptive Cabin Management System

[7] Eclipse framework