صحت سنجی برنامه‏ های کاربردی اویونیک با FPGA

امروزه با مدرن‌سازی و افزایش پیچیدگی سیستم‏های اویونیک، عملیات صحت سنجی سخت افزارهای مربوط به آن‏ها چالش اساسی را برای طراحان تجهیزات هوایی ایجاد کرده است. یکی از راهکارهای مناسب مقابله با این چالش، استفاده از سخت‏افزارهای از قبل تایید شده است. اگرچه در صنعت روش‌های متعددی برای صحت سنجی طراحی‌های سخت افزاری وجود دارد و می‌توان از هر یک از آن‌ها برای تایید یک محصول استفاده کرد، اما در حوزه هوانوردی روش مورد استفاده باید فرایندهای دقیق‌تری برای صدور گواهینامه‏های مختلف مانند DO-254 طی کند.
طبق قوانین استاندارد DO-254 فرآیند طراحی سخت افزار و صحت سنجی سخت افزار باید مستقل از یکدیگر انجام شود. به عبارتی از نظر چرخه‌ حیات طراحی، طراحان برای نیازهای تعریف شده محصول، طراحی خود را انجام می‌دهند اما مهندسان صحت سنجی اثبات می‏کنند که طراحی انجام شده مطابق با الزامات و نیازمندی‏های تعریف شده است که در اصطلاح به آن صحت سنجی بر اساس نیازمندی‏ها (RBV) گفته می‏شود.
با اینکه ممکن است تکنیک‏های صحت سنجی نوین و به ویژه خودکار برای فرآیند صحت سنجی طراحی‏های اویونیکی استفاده شوند اما برای اهداف تاییدیه و صدور گواهینامه مناسب نیستند. به عنوان نمونه، صحت سنجی بر اساس تبادل (TBV) که معمولا برای صحت سنجی نیازمندی‏های سطح بالا استفاده می‌شود ممکن است برای صحت سنجی نیازمندی‏ها و الزامات سطح پایین مانند تایید زمان‌بندی یک سیگنال مجزا مناسب نباشد. با این حال دلیل صحت سنجی بر اساس تبادل در طراحی‏های اویونیک حال و آینده نقشی مهمی دارد. پیچیدگی‏های رو به رشد سیستم‏های اویونیکی صحت سنجی بر اساس نیازمندی‏ها را به صحت سنجی بر اساس تبادل نزدیک کرده است و به احتمال زیاد نیازمندی‏ها از طریق روش‏هایی بیان خواهند شد که منجر به صحت سنجی بر اساس تبادل می‏شوند.
چرا در فرآیند صحت سنجی شبیه‌سازی به تنهایی کافی نیست؟
در فرآیند صحت سنجی سخت افزار، شبیه سازها نقش اساسی را ایفا می‏کنند. شبیه سازها ضمن اینکه ابزاری مفید، کاربردی و البته سریع هستند، فقط می‌توانند بخش‌های مشخصی از سیستم را تحلیل کرده و به تنهایی نمی‏توانند بیانگر اطمینان در مجموعه سیستم باشند. از اینرو برای صحت سنجی طراحی کل سیستم نیاز به تعداد زیادی شبیه سازی با استفاده از شبیه سازهای متفاوت احساس می‏شود. برای نمونه، شبیه ساز HDL عملکرد و رفتارهای در نظر گرفته شده در طراحی را صحت سنجی می‏کند. این کار با تحلیل و سنتز مجموعه‌ای از کدها در سطح انتقال ثبات (RTL) و با استفاده از یک تست بنچ HDL انجام می‏شود.
شبیه سازها به دلیل استفاده از روابط ریاضی به طور کامل قطعی و معین هستند و به عبارتی برای طراحی انجام شده و تست بنچ داده شده نتایج یکسانی نشان می‏دهند. این در حالی است که سخت افزارها قطعی نیستند و نتایج آن‏ها در حال تغییر است. در شبیه‌سازها کلاک بصورت ایده‌آل در نظر گرفته می‌شود و اثراتی مانند تناقضات زمانی، نیمه پایداری و انحراف فرکانسی در نظر گرفته نمی‌شود. اگرچه شبیه‌سازهای زمانی بسیار دقیق هستند، اما به ندرت شرایط واقعی را در نظر می گیرند. دلیل اصلی این امر نیز زمان نامتناسب شبیه‌سازی است که در مقایسه با زمان فعالیت FPGA بسیار کوتاه است. همچنین استفاده از شبیه ساز RTL در طراحی‏های خیلی بزرگ به دلیل زمان اجرای شبیه‌سازی ممکن است نتایج واقعی در بر نداشته باشند. این در حالی است که برابرسازها برای سرعت دادن به فرآیند صحت سنجی استفاده می‏شوند. در فرایند صحت سنجی از طریق برابرساز، کلیه توابع طراحی اصلی بر روی یک مرجع سخت افزاری دیگر معادل‌سازی می‌شود.
برابرسازها برای صحت سنجی طراحی‏ها از چند FPGA استفاده می‏کنند و به عبارتی با قراردادن سخت افزاری در حلقه، ضریب اطمینان صحت سنجی را افزایش می‌دهند؛ با این وجود نمی‌توان گفت اطمینان از نتایج به صد درصد رسیده است. برابرساز ممکن است نتایج قطعی یا واقعی داشته باشد، همچنین ممکن است عواملی مانند نیمه پایداری و غیر ایده‌آل بودن کلاک در برابرساز لحاظ شده باشد. همه این عوامل به کیفیت نگاشت و تطبیق طراحی اصلی با طراحی برابرسازی شده روی FPGA و نحوه تولید کلاک‌ها وابسته است.
بر اساس این فناوری امکان مشاهده رفتار واقعی سخت افزار در حال اجرای عملیات برابرسازی وجود دارد. در برابرسازها هیچ فرض قبلی مانند مشاهده پاسخ تست‌ روی یک رابط معین و در زمان مشخص وجود ندارد. دلیل این امر این است که در سخت افزارهای واقعی ممکن است به خاطر پاسخ غیرقطعی برابرساز، پاسخ‌ها زودتر یا دیرتر روی یک رابط مشاهده شوند.
در تست بنچ‏های زمان بندی شده و جهتی که تنها در شبیه‌سازی‌ها انجام می‏شود، پیاده‌سازی و اجرای چنین فرضیاتی بسیار آسان و امکانپذیر است. در حالی که شرکت‌های نیمه هادی از تست بنچ‏های زمان بندی نشده‌ی تبادلی استفاده می‏کنند، در نتیجه اجرا و پیاده سازی هر کدام از فرضیات مربوط به زمان در این تست بنچ‏ها دشوار است. در این روش، پروتکل‏های رابط مورد نیاز برای ارتباط با طرح‏هایی که در حال تست هستند در بخش تبادل کننده‏ قرار دارند. بدین ترتیب تنها تبادل کننده‏ها ممکن است شامل مقدار کمی کد HDL زمان‏بندی شده‏ باشند.

تست بنچ‏های تبادلی و جهتی

فواید صحت سنجی با سخت‌افزار

طبعا صحت سنجی با سخت افزار به فرآیند کلی صحت سنجی نزدیکتر است، اما برای یک برنامه کاربردی اویونیکی مبتنی بر FPGA، در واقع نگاشت طرح اجرا شده روی تنها یک FPGA به چند FPGA بی فایده و نامناسب است. به همین دلیل قرار دادن FPGA مورد هدف و اتصال رابط آن در یک محیط صحت سنجی بسیار آسان‏تر و کاربردی‏تر است. به تازگی بسیاری از طراحان و سازندگان محصولات اویونیکی از پلتفرم DO-254/CTS که محصول شرکت Aldec است، برای صحت سنجی طراحی‌های خود استفاده می‌کنند. این پلتفرم علاوه بر صحت‌سنجی طراحی‌ها، برای بررسی و کسب اعتبار مورد نیاز صدور گواهینامه RTCA/DO-254 نیز مورد استفاده قرار می‌گیرد. این محصول دارای دو بخش سخت افزاری شامل بورد اصلی و بورد جانبی و یک بسته نرم‌افزاری است.
در واقع Do-254/CTS یک پلتفرم سخت‌افزاری و نرم‌فزاری کامل است که هدف آن افزایش پوشش دامنه صحت سنجی است. طراحی مورد هدف از برنامه‏های کاربردی اویونیک روی بورد جانبی ( که به بورد اصلی متصل است) با سرعت اجرا می‏شود. به منظور پشتیبانی از روش صحت‌سنجی مبتنی بر نیازمندی، تست بنچ شبیه‏سازی به صورت بردار‏های تست به CTS اعمال می‌شوند. فرآیند تست با کنترل صد در صد FPGA در سطح پین انجام می‏شود. نتایج تست FPGA به سرعت ضبط شده و برای تجزیه و تحلیل پیشرفته و ایجاد سند، به صورت گرافیکی قابل نمایش است.
مراحل اجرای یک تست توسط DO-254/CTS به صورت زیر است:
1- ابتدا با استفاده از شبیه‌ساز RTL موجود در بسته نرم‌افزاری، عملیات شبیه سازی انجام می‏شود. سپس DO-254/CTS دو مجموعه از بردارها را تولید می‏کند، یک دسته بردارهای ورودی که به عنوان بردارهای تست برای آزمایش سخت‌افزار بر اساس تست بنچ در نظر گرفته می‏شود و یک دسته بردارهای طلایی که نتایج شبیه‌سازی RTL است و به عنوان پایه مقایسه درنظر گرفته می‌شود.
2- تست مورد هدف با سرعت زیاد روی بوردهای اصلی و جانبی و با استفاده از بردارهای ورودی به عنوان بردارهای مورد آزمایش انجام می‏شود.
3- نتایج تست به عنوان بردارهای خروجی ذخیره خواهند شد.
4- در مرحله آخر بردارهای خروجی با بردارهای طلایی مقایسه می‌شوند.
در اینجا یک سوال مطرح می‏شود: آیا می‏توان از روش رایج تست بنچ جهتی که در صنعت اویونیک بسیار رایج و محبوب است برای صحت سنجی سخت افزار واقعی استفاده کرد؟ پاسخ این سوال مثبت است؛ به عنوان مثال در مورد Aldec,s Do-254/CTS بردارهای تست استفاده شده در شبیه‌سازی به صورت خودکار به سخت‌افزار واقعی اعمال می‌شوند. همانطور که قبلا اشاره شد به دلیل اینکه رفتار سخت‌افزار واقعی، قطعی نیست ممکن است بین نتایج شبیه‌سازی و تست‏های سخت‌افزار واقعی عدم تطابق وجود داشته باشد. چنین تفاوت‏هایی را می‏توان با استفاده از ابزار نمایش‏ گرافیکی سیستم بررسی و مقایسه کرد.

بورد اصلی در پلتفرم Do-254/CTS

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

نحوه عملکرد پلتفرم Aldec,s Do-254/CTS

استفاده از تست بنچ‏ های تعاملی در پلتفرم FPGA

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

نحوه ارتباطات در تست بنچ‏های تبادلی

تست بنچ‏های جهتی رایج نیز می‌توانند به صورت تعاملی باشند و به وقفه‌ها و تاخیرهای ایجاد شده ‌روی رابطه‌های سیستم تحت تست واکنش نشان دهند. اما چرا از این نوع تست بنچ‌ها روی سخت افزارهای واقعی استفاده نمی‌شود؟ حتی اگر یک تست بنچ جهتی بتواند به صورت تعاملی عمل کند، به دلیل محدودیت‌های سرعت نمی‌توان از آن روی سخت افزار واقعی استفاده کرد. شبیه سازهای HDL برای ارتباط با سخت افزارهای واقعی به اندازه کافی سریع نیستند بنابراین اگر تست بنچ شبیه سازی شده برای ارائه بردارهای تست به سخت افزار خیلی کند باشد، بردارهای تست باید در یک فایل جمع آوری شده و سپس روی سخت افزار با سرعت واقعی اعمال شود. از بین این روش‏ها، روش TBV بسیار انعطاف پذیر است. تست بنچ TBV از طریق تبادل‌گرها با طراحی تحت تست ارتباط برقرار می‌کند. همانطور که پیش از این بیان شد، تبادل‌گرها بر روی برابرساز پیاده سازی و اجرا می‏شوند و در سرعت مشابه با طراحی تحت تست کار می‏کنند.
تبادل‌گرها می‏توانند به عنوان یک پل ارتباطی سرعت بین تست بنچ و طراحی تحت تست عمل کنند. بنابراین اگر تست بنچ‏ خیلی کند باشد و سرعت پایینی داشته باشد، تبادل‌گرها این قابلیت را دارند که طراحی در حال تست را در حالت انتظار نگه دارند. علاوه بر این، تست بنچ‏های تبادلی به دلیل کوتاه بودن اندازه پیام مخابره شده توسط تبادل‌گر خیلی سریع هستند.

تبادل‌گرها در پلتفرم Aldec,s Do-254/CTS

روش TBV بطور معمول با زبان‏های SystemC و System Verilog و کتابخانه‏هایی همچون TLM، SCV، VMM، OVM یا UVM پیاده‌سازی می‌شود. در حال حاضر در صنعت اویونیک تست بنچ System Verilog همراه با کتابخانه UVM استفاده می‏شود، با این حال روش TBV محدود به یک زبان و کتابخانه خاص نمی‏شود. یک تست بنچ VHDL می‏تواند به صورت تبادلی باشد و در سطح بالاتر نوشته شود و همچنین با طراحی در حال تست از طریق تبادل‌گرها در ارتباط باشد. شکل بالا نشان می‏دهد که چطور می‌توان از تکنیک تبادل‌گرها در پلتفرم Aldec,s Do-254/CTS استفاده کرد. چنین معماری از تست بنچ برای بهره‌مندی از سرعت و انعطاف‌پذیری صحت‌سنجی با تکنیک سخت‌افزار در حلقه کافی و مناسب است. این تکنیک در حال حاضر در صنعت هوافضا استفاده می‏شود.
طبق بررسی‏های انجام شده روی 05 برنامه‏ کاربردی اویونیکی مبتنی بر FPGA با استفاده از پلتفرم Aldec,s Do-254/CTS، مشاهده شده است که رابط‏های پر سرعتی مانند ARINC 818 با روش سطح-تبادلی همیشه مورد تایید قرار می‏گیرند. دلیل آن نیز این است که سرعت بالای عملیات در این رابط‏ها در سطح بیت قابل تجزیه و تحلیل نیست. آن‏ها باید در ابتدا رمزگشایی شده و برای تجزیه و تحلیل در سطح بالاتر آماده شوند. از اینرو روش سطح-بیت رایج تنها برای رابط‏ها با سرعت پایین استفاده می‏شود.

جمع بندی

TBV توسط طراحان تجهیزات اویونیکی پذیرفته و به تصویب رسیده است. اگر چه TBV غالبا برای صحت سنجی رابط‏هایی با تعامل و سرعت بالا استفاده می‏شود اما احتمالا در آینده‏ای نزدیک تست بنچ‏های اویونیکی کاملا تبادلی خواهند بود. شتاب وقوع چنین اتفاقی با محبوبیت رو به رشد System Verilog، کتابخانه UVM و نزدیک شدن SOC FPGA به پروژه‏های اویونیکی بیشتر و بیشتر خواهد شد.
همانطور که اشاره شد، توسعه دهندگان تجهیزات مبتنی بر FPGA به دنبال ارائه راهکار برای مقابله با چالش‏های قابل توجه Do-254، طراحی مبتنی بر نیازمندی‏ها و فرآیند صحت سنجی سخت افزار برای اطمینان از عملکرد محصولات جدید هستند. در این راستا بسیاری از تولید کنندگان تجهیزات اویونیکی از پلتفرم Aldec,s Do-254/CTS که سازگار با راه‌کارها و قواعد Do-254 است برای پشتیبانی از صحت‌سنجی بر اساس نیازمندی‏‏ها استفاده می‏شود.

منبع: www.intelligent-aerospace.com