در حالیکه پردازندههای چندهستهای می‌توانند مزایای مختلفی همچون اندازه کمتر، توان مصرفی پایین و کارایی بالا را در طراحی سیستم‌های ایمنی- بحرانی اویونیک ارائه دهند، نحوه بکارگیری آن‌ها در معماری اویونیک همچنان دارای چالش‌های اساسی است. دلیل اصلی این مشکل را می‌توان در پیچیدگی فرایندهای اعتبارسنجی طراحی‌ها و اطمینان از عملکرد معماری‌های نرم‌افزاری و سخت‌افزاری جستجو کرد. نگرانی اصلی صاحبان صنایع در این‌باره مربوط به چگونگی جداسازی یک اپلیکیشن اجرا شده روی یک هسته با اپلیکیشن اجرا شده روی هسته دیگر است. این اپلیکیشن‌ها ممکن است نیازمند ارتباط با یکدیگر باشند و در عین حال طراح باید از عدم تاثیرپذیری غیرمجاز آن‌ها از یکدیگر و رعایت کامل ایمنی مطمئن شود. در واقع اجرای چند برنامه ایمنی- بحرانی مجزا روی تراشه مشترک باعث ایجاد این نگرانی‌ها شده است.
ما در نسخه‌های گذشته این مجله (شماره‌های 27، 28 و 35) به‌طور مفصل جنبه‌های مختلف استفاده از پردازندههای چندهستهای در سیستم‌های اویونیک را مورد بررسی قرار دادیم. با این حال با توجه به اهمیت این موضوع در آینده اویونیک پلتفرم‌های سرنشین‌دار و بدون سرنشین نظامی و غیرنظامی، قصد داریم در این نسخه از مجله مروری بر بهینه‌سازی معماری‌های مبتنی بر تراشه‌های چند هسته‌ای داشته باشیم. همچنین در این بخش نگاهی بر سند CAST-32A (توصیه‌های استفاده از پردازندههای چند هسته‌ای در اویونیک) خواهیم داشت.
گسترش استفاده از معماری چندهستهای در دنیای امروز الکترونیک باعث شده است تا صنعت هوایی نیز به عنوان پیشتاز استفاده از فناوری‌های نوین نگاه ویژه‌ای به آن داشته باشد. در واقع می‌توان گفت محدودیت‌های پلتفرم‌های هوایی در اندازه، وزن و توان مصرفی (SWaP) تجهیزات بخصوص در رابطه با هواپیماهای بدون سرنشین و از سوی دیگر کارایی بالای معماری چندهستهای نسبت به سیستم‌های تک هسته‌ای قدیم، طراحان را ملزم به استفاده از این فناوری کرده است.
بسیاری از سیستم‌های ایمنی- بحرانی اویونیک به‌صورت «بلادرنگ سخت» تعریف می‌شوند، به این معنی که توابع آن‌ها باید در مهلت‌های از پیش تعیین شده انجام شوند. در این سیستم‌ها، گذر از یک مهلت به معنی بروز یک شرایط خرابی است که می‌توان به یک فاجعه ختم شود. افزایش در سطوح تلفیق و یکپارچه‌سازی توابع اویونیک ایمنی- بحرانی دلیل دیگری بر لزوم استفاده از سیستم‌های چندهستهای است. به عبارت دیگر یک کامپیوتر اویونیک می‌تواند از چند برنامه ایمنی- بحرانی با شرایط بلادرنگ سخت میزبانی کند.
در حال حاضر پردازندههای چندهستهای متفاوتی در بازار وجود دارد که صنایع تجاری در مصارف مختلف از آن‌ها استفاده می‌کنند. این پردازندههای تجاری مرسوم در بازار (COTS) به دلیل قیمت پایین و ابزار توسعه پیشرفته، گزینه جذابی برای استفاده در صنعت هوایی محسوب می‌شوند. مهم‌ترین نگرانی در رابطه با استفاده از پردازندههای چندهستهای COTS، مربوط به حوزه توابع ایمنی- بحرانی است. جایی که عدم پیش‌بینی‌پذیری قطعی این پردازنده‌ها چالش‌های زیادی را برای طراحان ایجاد می‌کند.
از این‌رو در سال‌های اخیر تلاش‌های زیادی برای بهره‌مندی ساده‌تر از پردازندههای چندهستهای در سیستم‌های ایمنی- بحرانی اویونیک شده است. در همین راستا برخی از شرکت‌ها و سازمان‌های ذی‌صلاح تعدادی استاندارد و سند راهنما برای استفاده از معماری چند هسته‌ای در سیستم‌های اویونیک منتشر کرده‌اند.
از ARINC 653 می‌توان به عنوان یکی از مهم‌ترین این اسناد نام برد. تمرکز این استاندارد روی پارتیشن‌بندی فضا و زمان سیستم‌عامل‌های بلادرنگ برای اپلیکیشن‌های ایمنی- بحرانی اویونیک است. در ویرایش سال 2015 این استاندارد یک بخش برای اپلیکیشن‌های چندهستهای به آن اضافه شد. همچنین در نسخه شماره 3 از استاندارد FACE نیز شاهد پشتیبانی از معماری چندهستهای بوده‌ایم. از دیگر اسناد منتشر شده در این رابطه می‌توان به CAST-32A اشاره کرد. CAST یک گروه بین‌المللی از نمایندگان سازمان‌های صدور گواهینامه و تنظیم مقررات است که مورد تایید FAA، EASA و TCCA قرار گرفته است. در سند مذکور توصیه‌ها و راهنمایی‌هایی برای استفاده از سیستم‌های چندهستهای آورده شده است. مجموعه این اسناد با یکدیگر برخی نیازمندی‌ها برای موفقیت در استفاده از تراشه‌های چندهستهای داخل اپلیکیشن‌هایی با سطح تضمین طراحی A (بالاترین سطح تضمین طراحی نرم‌افزارهای ایمنی -بحرانی مطابق با استاندارد RTCA/DO-178C) را ارائه می‌دهند.
مزایای معماری چندهستهای
به‌طور کلی مزایای استفاده از پردازندههای چندهستهای در سیستم‌های اویونیک نظامی و غیرنظامی را می‌توان شامل موارد زیر در نظر گرفت:
کارایی بالاتر: اجرای چند اپلیکیشن روی هسته‌های مختلف یک پردازنده می‌تواند ضمن اجرای سریع عملیات‌های اویونیک، کارایی سیستم را بالا ببرد. استفاده بهینه از هسته‌ها باعث می‌شود توان خروجی سیستم متناسب با تعداد هسته‌ها به‌صورت خطی افزایش یابد.
اندازه، وزن و توان مصرفی بهتر: اجرای چند برنامه روی یک تراشه به جای استفاده از چند پردازنده تک‌هسته‌ای می‌تواند صرفه‌جویی زیادی در ابعاد، وزن و توان مصرفی نهایی سیستم کند. این مورد یکی از اهداف مهم در طراحی سیستم‌های اویونیک آینده محسوب می‌شود.
آمادگی برای رشد سیستم در آینده: کارایی بالای پردازندههای چندهستهای فضا را برای پشتیبانی از نیازمندی‌های آینده سیستم باز می‌گذارد.
دسترس‌پذیری طولانی‌تر: با توجه به رویکرد شرکت‌های تولیدکننده تراشه‌های پردازنده، بیشتر تراشه‌های تک‌هسته‌ای منقرض شده یا در حال انقراض هستند. بنابراین درخواست خرید این گونه تولیدات در آینده‌ای نزدیک می‌تواند مشکل و در عین حال مشمول صرف هزینه بسیار بیشتر نسبت به تراشه‌های چندهستهای که در ابتدای چرخه عمر خود هستند، باشد.
مزایای عنوان شده نشان می‌دهد که طراحان سیستم‌های اویونیک ناگزیر به استفاده از معماری‌های چندهستهای در سیستم‌های خود هستند.
چالش‌های معماری چندهستهای در اپلیکیشن‌های ایمنی- بحرانی
برای درک بخشی از پیچیدگی کار با پردازندههای چندهستهای اجازه دهید ابتدا نحوه کار با پردازنده تک هسته‌ای را بیان کنیم. با یک پارتیشن‌بندی دقیق و قوی روی فضای حافظه و زمان پردازش، امکان اجرای همزمان چند اپلیکیشن ایمنی- بحرانی روی یک پردازنده تک‌هسته‌ای وجود دارد. با پارتیشن‌بندی فضای حافظه، در هر زمان بخشی از حافظه به هر یک از برنامه‌های در حال اجرا اختصاص داده می‌شود. این بخش از حافظه کاملا مختص هر یک از برنامه‌ها است. واحد مدیریت حافظه (MMU) که معمولا در داخل خود پردازنده قرار دارد، وظیفه اختصاص و مدیریت استفاده از حافظه را برعهده دارد. در پارتیشن‌بندی زمانی، یک فریم زمانی ثابت به دنباله‌ای از بازه‌های زمانی کوچک که پنجره زمانی پارتیشن نامیده می‌شود، تقسیم می‌شود. به هر اپلیکیشن یک یا چند پنجره زمانی اختصاص داده می‌شود. طول و تعداد این پنجره‌های اختصاص یافته شاخصه‌ای از بدترین حالت زمان اجرای برنامه (WCET[1]) و مقدار تکرار مورد نیاز آن است. در اینجا پارتیشن‌بندی‌ها باید به‌طور کاملا دقیق انجام شود تا تداخلی بین زمان‌های اجرا و فضای حافظه هر یک از اپلیکیشن‌ها ایجاد نشود. از طرف دیگر طراح باید به منظور استفاده بهینه از پردازنده، کمترین فضا و زمان را به هر برنامه اختصاص دهد.
اعمال این روش‌های ایمنی- بحرانی به پردازندههای چند هسته‌ای منجر به بروز برخی چالش‌های پیچیده می‌شود که مشکل‌ترین آن‌ها تداخل بین هسته‌ها در هنگام استفاده از منابع مشترک است.
تداخل بین هسته‌ها
در تمام معماری‌های سخت‌افزار چندهستهای، منابع مشترکی همچون کنترل‌کننده‌های حافظه، حافظه‌های DDR، ورودی/خروجی، حافظه کَش و بافت داخلی (Internal Fabric – برای اتصال عناصر مختلف پردازنده به یکدیگر) وجود دارد (شکل 1). در اینجا مشکل زمانی ایجاد می‌شود که چند هسته می‌خواهند به‌طور همزمان به منابع اشتراکی دسترسی داشته باشند. این وضعیت به این معناست که یک اپلیکیشن با سطح حساسیت پایین‌تر می‌تواند موجب اختلال در عملکرد یک اپلیکیشن با حساسیت بالاتر شود.
شکل 1- هسته‌های مختلف یک تراشه از منابع اشتراکی همچون I/O، حافظه و کَش مشترک استفاده می‌کنند. یک بافت داخلی این عناصر را به هم ارتباط می‌دهد.
سند CAST-32A راهنمایی‌هایی را برای صدور گواهینامه در رابطه با تداخلات پردازندههای چند هسته‌ای ارائه می‌دهد. یکی از رویکردهای معرفی شده در این سند بررسی و تحلیل بدترین حالت زمان اجرا برای هر اپلیکیشن/پارتیشن و همچنین بدترین حالت استفاده از منابع مشترک است. البته این روش یک اشکال بزرگ دارد و آن نیاز به انجام تحلیل مجدد کل سیستم در صورت تغییر در هر یک از اپلیکیشن‌ها است. بدون بهره‌گیری از ابزارها و مکانیزم‌های سیستم‌عامل که می‌توانند تداخلات چنین سیستمی را کاهش دهند، هزینه‌های پایداری و ریسک توسعه سیستم بسیار زیاد خواهد بود.
بروز تداخل به دلیل دسترسی همزمان به منابع مشترک
یک رویکرد بهتر این است که سیستم‌عامل بتواند تداخلات را بر اساس در دسترس بودن ابزار، کتابخانه‌ها و مکانیزم‌ها معرفی شده در سند CAST-32A مدیریت کند. این رویکرد یک مسیر مناسب، انعطاف‌پذیر و سریع را پیش روی یکپارچه‌سازان سیستم قرار می‌دهد. همچنین در صورت استفاده از این رویکرد، افزودن برنامه‌های جدید یا تغییر در برنامه‌های گذشته نیازمند انجام مجدد تمام تحلیل‌ها مربوط به تداخلات سیستم نیست.
انتقال طراحی‌های نرم‌افزار تک‌هسته‌ای به چندهستهای
همانطور که انتقال یک سیستم ایمنی طراحی‌شده برای پردازنده تک‌هسته‌ای به یک پلتفرم چندهستهای نیازمند منابع محاسباتی بیشتری است، WCET مربوط به هر اپلیکیشن نیز به دلیل تاخیرهای طولانی مربوط به اشتراک منابع یا تداخل از دیگر هسته‌ها، با این انتقال افزایش می‌یابد. بنابراین تحلیل‌های جدید برای تعیین وضعیت رفتاری سایر منابع همچون حافظه‌ها نیاز خواهد شد. درحالی‌که منابع در پلتفرم جدید ممکن است با سرعت بیشتری انجام وظیفه کنند، احتمال توقف یک برنامه یا رفتار غیرمتعارف از اپلیکیشن وجود دارد.
استفاده موثر از منابع چندهستهای
برای دستیابی به بالاترین سطح مزایای SWaP در پلتفرم‌های چندهستهای، معماری نرم‌افزار نیازمند بیشترین استفاده از هسته‌های پردازشگر در دسترس است. در واقع برای رسیدن به این هدف باید تمام ویژگی‌های سیستم چندهستهای از انجام عملیات‌های همزمان هسته‌ها گرفته تا ارائه مکانیزمی برای ایجاد تعادل در بار مد نظر قرار گرفته شود. هرچه معماری پردازش چندهستهای نرم‌افزار انعطاف‌پذیرتر باشد، معمار سیستم ابزار بیشتری برای دستیابی به استفاده بیشتر و موثرتر از منابع چندهستهای خواهد داشت.
معماری چندهستهای نرم‌افزار
همانند سیستم‌های چند پردازنده‌ای، معماری نرم‌افزار روی پردازشگرهای چندهستهای نیز می‌تواند با توجه به نحوه دسترسی به حافظه سایر هسته‌ها یا اینکه آیا هر هسته یک نسخه از سیستم‌عامل مختص به خود را اجرا می‌کند، دسته‌بندی شود. می‌توان گفت ساده‌ترین معماری نرم‌افزار برای سیستم‌های مبتنی بر چند هسته، روش چند پردازشی نامتقارن (AMP[2]) است که در آن هر هسته به‌طور مستقل عمل می‌کند. به عبارت دیگر در این معماری هر هسته یک سیستم‌عامل مختص به خود یا یک سیستم‌عامل مهمان قرار گرفته روی هایپروایزر اصلی را دارد. هر هسته یک اپلیکیشن متفاوت را اجرا می‌کند و هماهنگی محدودی بین هسته‌ها از لحاظ زمان‌بندی‌ها وجود دارد.
این جداسازی می‌تواند منجر به عدم تعادل در بارهای هر هسته شود و فرایند کاهش نزاع هسته‌ها برای دسترسی به منابع مشترک را دشوار کند. علاوه بر این معماری AMP توانایی در انجام عملیات‌های مشترک بین هسته‌ها مثل انجام تست‌های داخلی جامع را محدود می‌کند.
در مقابل روش AMP، رویکرد مدرن‌تری با عنوان روش چند پردازشی متقارن (SMP[3]) است که در آن یک سیستم‌عامل واحد، تمام منابع را کنترل کرده و حتی تعیین می‌کند هر رشته پردازشی (thread) از یک اپلیکیشن روی کدام هسته اجرا شود. برنامه‌ریزی این معماری به دلیل دسترسی متقارن تمام هسته‌ها به منابع، آسان خواهد بود. این رویکرد به سیستم‌عامل امکان اختصاص آزادانه رشته‌های پردازشی اپلیکیشن‌ها را به هر هسته می‌دهد.
از سوی دیگر عدم اطلاع از اینکه هر رشته روی کدام هسته اجرا می‌شود، یک چالش بزرگ و خطری برای عملکرد قطعی در سیستم‌های بحرانی است. برای حل این مسئله، سند CAST-32A به استفاده از رویکرد چند پردازشی محدود (BMP[4]) اشاره دارد. روش BMP یک شکل پیشرفته و محدود از SMP است که به‌طور ایستا وظایف یک اپلیکیشن را به هسته‌های خاص متصل می‌کند. این مورد به معمار سیستم اجازه می‌دهد تا عملکرد همزمان چند هسته را به شدت تحت کنترل داشته باشد. روش BMP به‌طور مستقیم نیازمندی‌های چندهستهای تعریف شده در بخش 2-2-1 از مکمل چهارم استاندارد ARINC 653 را پیروی می‌کند.
تفاوت معماری چندهستهای در روش‌های AMP، SMP و BMP
از INTEGRITY-178 می‌توان به عنوان یک سیستم‌عامل بلادرنگ با امکان پشتیبانی از ترکیب همزمان AMP، SMP و BMP نام برد که برای کاربردهای ایمنی- بحرانی مناسب است. ویژگی چندپردازشی یکپارچه 8 متغیر با زمان (tuMP[5]) در این سیستم‌عامل سبب می‌شود تا یک انعطاف‌پذیری در انتقال، گسترش و بهینه‌سازی اپلیکیشن‌های ایمنی- بحرانی و امنیتی- بحرانی ایجاد شود.
ویژگی tuMP در سیستم‌عامل INTEGRITY-178 باعث می‌شود تا بتوان اپلیکیشن‌های مختلف را داخل هسته‌های سیستم در پنجره‌های زمانی متفاوت اجرا کرد.
علاوه بر ملاحظات نرم‌افزاری DO-178، در طراحی ایمن یک هواپیما گواهینامه DO-254 برای سخت‌افزارهای اویونیک مورد نیاز است. نیازمندی‌های فعلی و آینده صنعت هوافضا به تقاضای زیاد برای سخت‌افزارهایی با قابلیت پشتیبانی از اجرای همزمان چند اپلیکیشن اشاره دارد. جایی که اپلیکیشن‌ها ممکن است دارای ویژگی‌ها و سطوح ایمنی- بحرانی مختلفی باشند. این نیازمندی‌ها، همراه با الزامات محاسباتی شدید و معماری‌هایی که شامل پردازندههای چندهستهای هستند، به‌طور واضح بیانگر لزوم گسترش سیستم‌عامل‌های بلادرنگی است که قادر به جلوگیری از جدال بر سر منابع مشترک هستند.
فرایند طراحی ایمن
تلفیق پردازندههای چندهستهای در سیستم‌های اویونیک باید به گونه‌ای باشد که ملاحظات جبرگرایی و قطعیت در توابع اجرا شده روی آن‌ها اعمال شود. هنگام توسعه یک سیستم چندهستهای، علاوه بر تحلیل‌های ایمنی کلاسیک روی پردازشگرهای تک هسته‌ای، باید جوانب ایمنی مختلف دیگر که ممکن است یک پردازنده چندهستهای را به سمت خرابی‌های خاص حرکت دهد نیز در نظر گرفته شود.
در این شرایط، استفاده از روش‌های طراحی ایمن بالا به پایین یکی از بهترین رویکردهای توسعه سیستم است. طبق سند ARP-4754A با عنوان «راهنمایی‌هایی برای توسعه سیستم‌های هواپیمای غیرنظامی»، فرایند ایمنی اویونیک شامل یک شاخه رو به پایین به نام اختصاص و یک شاخه رو به بالا به نام تلفیق است (شکل زیر).
ساختار فرایند ایمنی مطابق سند ARP-4754A
شاخه اختصاص مربوط به طراحی ایمن است و با استفاده از روش‌های تحلیل بالا به پایین برای طراحی یک محصول مطابق با محدودیت‌های ایمنی انجام می‌شود. این روش‌های تحلیل ایمنی شامل ارزیابی خطرات عملکردی (FHA) و ارزیابی اولیه ایمنی سیستم (PSSA) می‌شود. رویکرد FHA شرایط خرابی مرتبط با عملکردهای اصلی هواپیما را با توجه به شدت آن‌ها شناسایی و طبقه‌بندی می‌کند. از سوی دیگر رویکرد PSSA به بررسی معماری سیستم با توجه به شرایط ایمنی مدنظر در FHA می‌پردازد. در این مرحله اعلام می‌شود که معماری درنظر گرفته شده برای سیستم، پاسخگوی اهداف ایمنی است یا خیر. به عبارتی روش PSSA یک فرایند تکراری است که حین تعیین نیازمندی‌های ایمنی و طراحی سیستم در جریان است.
این روش‌ها باید برای همه مخاطرات از جمله تهدید‌های خاص یک سیستم چندهستهای اعمال شود. نتیجه نهایی شامل مجموعه‌ای از الزامات کیفی ایمنی (به عنوان مثال تعریف مکانیزم‌های ایمنی برای پیاده‌سازی) و الزامات کمی ایمنی (مثل پیش‌بینی احتمال شکست یا معیارهای عملکردی برای ایمنی) است.
با توجه به سند ARP 4754A، سطوح تضمین طراحی (DAL) به تمام موارد نرم‌افزاری و سخت‌افزاری اویونیک اختصاص داده می‌شوند. بنابراین DAL با توجه به میزان حیاتی بودن هر اپلیکیشن نرم‌افزاری به آن اختصاص داده می‌شود و ممکن است چند اپلیکیشن با DAL مختلف روی یک پردازنده چندهستهای به‌طور همزمان اجرا شوند. در شاخه اختصاص از فرایند ایمنی باید تضمین شود که یک اپلیکیشن با DAL پایین‌تر نمی‌تواند اجرای یک اپلیکیشن با DAL بالاتر را به خطر اندازد.
شاخه تلفیق به ارزیابی ایمنی طراحی اشاره می‌کند. در این مرحله از روش‌هایی برای تایید رعایت اهداف ایمنی تعیین‌شده در مرحله قبل (فاز طراحی ایمن) استفاده می‌شود. ارزیابی ایمنی سیستم (SSA) منجر به جمع‌آوری مجموعه‌ای از مدارک می‌شود که به رعایت کامل الزامات ایمنی تعیین شده در مرحله قبل داخل محصول نهایی اشاره دارد.
جمع‌بندی
الزامات پردازشی و اهمیت بهینه‌سازی SWaP، لزوم استفاده از پردازندههای چندهستهای را در صنعت اویونیک به وضوح نشان می‌دهد. هرچند این فناوری مزایای بسیار زیادی را به همراه دارد، اما استفاده مشترک از منابع توسط هسته‌های مختلف می‌تواند مشکلات متعددی را ایجاد کند. استفاده از ابزار و راهکارهای جدید می‌تواند امکان مواجهه با برخی از این مشکلات را حذف کند. سیستم‌عامل‌هایی که قابلیت اجرای همزمان روش‌های AMP، SMP و BMP را دارند نمونه‌ای از این ابزارهای نرم‌افزاری هستند.
در رابطه با سیستم‌های ایمنی- بحرانی اهمیت رعایت استانداردها دوچندان می‌شود. در اینگونه سیستم‌ها انتخاب صحیح نرم‌افزار، سخت‌افزار و همچنین روش‌های تحلیل ایمنی می‌تواند علاوه بر کاهش فرایند توسعه سیستم، هزینه‌های طراحی و ساخت را نیز تا مقدار زیادی کاهش دهد.
[1] worst-case execution time
[2] Asymmetric Multi-Processing
[3] Symmetric Multi-Processing
[4] Bound Multi-Processing
[5] time-variant unified Multi-Processing
ثبت ديدگاه
You must be logged in to post a comment.