عیب یابی و مانیتورینگ اتوماتیک روبات خودکار زیرآبی

عیب یابی و مانیتورینگ اتوماتیک روبات خودکار زیرآبی – ایران ترجمه – Irantarjomeh

مقالات ترجمه شده آماده گروه کامپیوتر

مقالات ترجمه شده آماده کل گروه های دانشگاهی

مقالات رایگان

مطالعه 20 الی 100% رایگان مقالات ترجمه شده

1- قابلیت مطالعه رایگان 20 الی 100 درصدی مقالات 2- قابلیت سفارش فایل های این ترجمه با قیمتی مناسب مشتمل بر 3 فایل: pdf انگیسی و فارسی مقاله همراه با msword فارسی -- تذکر: برای استفاده گسترده تر کاربران گرامی از مقالات آماده ترجمه شده، قیمت خرید این مقالات بسیار کمتر از قیمت سفارش ترجمه می باشد.  

چگونگی سفارش

الف – پرداخت وجه بحساب وب سایت ایران ترجمه (شماره حساب) ب- اطلاع جزئیات به ایمیل irantarjomeh@gmail.com شامل: مبلغ پرداختی – شماره فیش / ارجاع و تاریخ پرداخت – مقاله مورد نظر -- مقالات آماده سفارش داده شده عرفا در زمان اندک یا حداکثر ظرف مدت چند ساعت به ایمیل شما ارسال خواهند شد. در صورت نیاز فوری از طریق اس ام اس اطلاع دهید.

www.irantarjomeh.com

عیب یابی و مانیتورینگ اتوماتیک روبات خودکار زیرآبی

عیب یابی و اعمال مانیتورینگ اتوماتیک برای ماموریت های روبات خودکار زیرآبی (AUV)

چکیده

ربات های خودکار پیش رفته زیرآبی (AUV) ها[1]، مخصوصا آن دسته از ربات هایی که قابلیت انجام اهداف دراز مدت / طولانی را دارند، برای انجام ماموریت های پیچیده، بدون پشتیبانی متوالی از سوی کشتی مادر، باید به میزان زیادی از استقلال عمل و سیستم های خودگردان و خودکار داخلی برخوردار باشند. یکی از ویژگی های مهم این حالت، استقلال عیب یابی و اعمال فرایند مانیتورینگ می باشد. در این مقاله، ما نسبت به تشریح کاربرد سیستم تشخیصی لوینگستون 2[2] بر روی سیستم اتوساب 6000[3] اقدام نموده و علی الخصوص مسائلی را بررسی می نماییم که تضمین کننده اجرای صحیح اهداف و ماموریت های  این سیستم می باشند.

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

[1] Automatic Underwater Vehicles

[2] Livingstone 2

[3] Autosub 6000

1-  مقدمه

با شایع تر شدن ربات های اتوماتيک زیرآبی (AUV) ها، و علی الخصوص با توجه بدین موضوع که ماموریت ها از نظر زمانی طولانی تر گردیده و باید آنها را در محیط هایی انجام داد که ناشناخته تر هستند، ارتقای اطمینان پذیری این ربات از اهمیت فزاینده ای برخوردار می باشد. بالاترین سود در این زمینه احتمالا با توجه به حصول سخت افزار و سیستم های کنترلی مطمئن تر حاصل خواهد آمد، موردی که سبب خواهد شد تا فرایند طراحی ماموریت ها به صورت ایمن انجام شود [1]؛ در عین حال ما عقیده داریم که باید به تشخیص داخلی/ آنبرد[1] سیستم نیز توجه کافی شود تا آنکه بتوان نسبت به تشخیص عیوب به هنگام رخ دادن آنها اقدام نموده تا بر این اساس قابلیت انجام رویه های مقتضی جهت به حداقل رسانی تاثیرات آنها وجود داشته باشد. محیطی که این ربات ها در آنها عمل می نمایند تحت شرایطی چون فشار حاد، تاثیرات خوردگی ناشی از آب دریا، و خطر صدمه دیدگی به واسطه امواج به هنگامی که این ادوات بر روی سطح هستند و همچنین احتمال تصادم در طی فرایند راه اندازی و رویه های متعاقب می باشد، که می توان آنها را جزء فرایندهایی در نظر گرفت که نمی توان انتظار داشت که حتی بهترین سیستم هایی که از بهترین طراحی نیز برخوردار هستند بتوانند بدون عیب ماموریت های مکرر خود را انجام دهند.

اتوساب 6000 [2] یک ربات زیرآبی خودکار (AUV) می باشد که برای باقی ماندن بیش از 48 ساعت  در عمق بیش از 6000 متر به منظور جمع آوری داده های علمی از عمق اقیانوس طراحی  شده است. در طی بیش از 400 ماموریت علمی قبلی، اتوساب 6000 و پیشینیان آن با خطرات زیادی روبرو گردیده که شامل یک مورد مورد از دست دادن کامل ربات و یک مورد از دست دادن نسبی آن بوده است. در این دو حالت AUV با هزینه قابل توجهی با استفاده از سیستم زیرآبی از راه دور بازیافت شده است. در یک مورد اتوساب 2 در ناحیه ای به فاصله 17 کیلومتر زیر یک لایه یخ به ضخامت 200 متر در قطب جنوب، تحت عنوان Fimbul Ice Shelf، به طور دائم مفقود شد. موارد بیشماری وجود دارند که عملیات را می بایست به طور کامل متوقف نمود، اما در صورتی که عملیات بازیافت به وسیله تیم عملیاتی و کشتی پشتیبانی بصورت توام در کار باشد احتمال نجات وجود خواهد داشت. بر مبنای تجربه عملیاتی اتوساب AUVs ، پروژه ای انجام شد که هدف از آن قابلیت تشخیص اتوماتیک و روش های بازیافت ربات اتوساب 6000، با هدف عیب یابی، بواسطه احتمال برخورد ربات با بستر دریا، بوده است. برخورد با بستر دریا نامطلوب می باشد چرا که این موضوع به عنوان یکی از عوامل اصلی از دست دان ربات زیر دریایی مشخص شده است. بخش 2  حاوی توضیحات تفصیلی اتوساب، همراه با یک دسته بندی عیوبی است که در طی ماموریت های قبلی رخ داده اند.

مزیت های احتمالی عیب یابی بر روی یک AUV به وسیله تحقیق Griffiths و Brito [1]، با توجه به پیش بینی خطر از دست دادن این ربات، نشان داده شده است. آنها از یک شبکه بیزی[2] (BN) جهت پیش بینی احتمال از  دست دادن ربات در زیر یخ دریا بهره گرفته است. احتمالات BN بر مبنای داده های تاریخی بیان کننده مواردی از شکست یا بروز خرابی در مولفه ها / اجزای واحد هر سیستم، همراه با نظر متخصصین در این خصوص، می باشد که مشخص می سازد چگونه برخی از خرابی ها خاص ممکن است سبب از دست دادن زیر دریایی تحت شرایط مختلف شود. از طریق ورود مقادیر مشخص شده متغیرها نظیر درصد پوشش یخ، ضخامت یخ، غیره، این موارد با تاریخچه آنها و داده های تخصصی جمع آوری شد تا بدین وسیله قابلیت محاسبه و ارزیابی احتمالاتی بوجود آید که ممکن است در آن شاهد از دست دادن ربات باشیم. این دیدگاه در خلال پیاده سازی اخیر سیستم اتوساب 3 در منطقه قطب جنوب (آنتاریکا[3]) استفاده شده و پس از آن اهداف مربوطه مورد بازنگری قرار گرفته تا خطر از دست دادن یک سطح قابل پذیرش کاهش یابد. هدف از تشخیص عیوب سیستم از طریق ادوات داخلی/ آنبرد قابلیت جایگزینی روش هایی در خصوص احتمال از دست دادن ربات به طرق مختلف می باشد. همان گونه که در بالا ذکر شد، روش سومی جهت کاهش احتمال از دست دادن ربات وجود دارد مه همانا رویه فرایند مهندسی اجزا و وسیله های کاربردی بصورت مطمئن تر می باشد، تا از این طریق احتمال بروز عیب در اولین مرحله کاهش یابد. کل این سه دیدگاه با توجه به انواع مختلف ماموریت های سیستم های خودکار زیرآبی می توانند مهم و با ارزش باشند.

تشخیص اتوماتیک عیب دارای سه قاعده مفید می باشد که می توان آنها را در سیستم هایی نظیر اتوساب 6000  اجرا نمود. اولا این فرایند به سیستم اجازه تسکین / کاهش تاثیرات ناشی از یک شکست از طریق شناسایی عوامل را خواهد داد- این مورد در برخی از موارد آن قدر مطلوب است که قبل از آنکه آنها منجر به بروز هر گونه مشکل جدی شود می تواند از آن جلوگیری کند- بر این مبنا قابلیت انتخاب واکنش ها و پاسخ های مناسب وجود دارد. دوما، یک سیستم تشخیصی که بر مبنای اصول تله متری یا کنترل از راه دور کار می نماید می تواند به کنترل کننده های هر یک از این ماموریت ها کمک نماید تا نسبت به مشخص نمودن رفتار غیر قابل انتظار اقدام نموده و بدینسان قابلیت اتخاذ پاسخ های مناسب را داشته باشند. در نهایت،  تشخیص داخلی/ آنبرد قابلیت کاهش زمان گردش بین ماموریت ها از طریق بررسی دقیق سیستم های فرعی که می بایست جایگزین شوند را داشته و می تواند این مورد را کنترل نماید که سیستم از نقطه نظر اسمی دارای عملکرد مناسبی می باشد یا خیر.

دیدگاهی که ما آن را اعمال می نماییم استفاده از موتور تشخیص لوینگستون 2 (L2) بر روی اتوساب می باشد. L2 یک سیستم تشخیصی گسسته، مدل- مبنا می باشد که به صورت ترکیبی بوده و اجازه خواهد داد تا مدل های حاصله از اجزای منفرد با یکدیگر به صورت یک رویه نسبتا آسان جمع شده تا آنکه قابلیت ایجاد مدل های بزرگتری بوجود آید. طراحی L2  بصورت آنبرد، با توجه به سیستم ماهواره ای کنترل زمینی [3] بگونه ای بوده است که بر حسب ملزومات محاسباتی سبک وزن بوده و در عین حال از قابلیت مطلوبی بر مبنای استانداردهای نرم افزار پرواز[4] برخوردار باشد. بدینسان این سیستم به عنوان یک انتخاب طبیعی برای ربات اتوماتیک زیرآبی به شمار آمده و از نقطه نظرات مختلفی (همانند محدودیت های محاسباتی،  معماری های کنترلی، غیره) مشابه با سفینه فضایی می باشد. L2 به تفصیل در بخش 3 تشریح می شود و مدل تشخیصی نیز در بخش 4 ارائه خواهد شد.

به غیر از بررسی سلامت اجزای سخت افزاری ربات خودکار زیرآبی (AUV)، ما همچنین علاقمند بررسی فرایند پیاده سازی ماموریت خود می باشیم. برای سیستم اتوساب، هدف تعریف شده در فایلی تحت عنوان اسکریپت ماموریت[5] مشخص شده است که در زمان شروع هر ماموریت به سیستم آپلود یا بارگذاری خواهد شد. جهت بررسی اجرای این فرایند، و همچنین از آنجایی که اسکریپت ماموریت شامل اطلاعاتی در خصوص رفتار این ربات می باشد که در کتابچه های عملیاتی دیگر موجود نیست، ما می بایست نسبت به ایجاد یک مدل تشخیصی اسکریپت ماموریت به صورت اتوماتیک از خود این اسکریپت اقدام نماییم. در عین آنکه ما در حال ایجاد این مورد می باشیم،  همچنین می توانیم اقدام به انجام کنترل های سلامت اتوماتیک بر روی این اسکریپت نیز نماییم.

در بخش 5، ما استفاده از فرایند تشخیصی هم به صورت آنبرد، و هم به صورت خارج از ربات/ افبرد[6] با استفاده از سیستم تله متری ارسال شده به کشتی پشتیبانی، با استفاده از سیستم های صوتی، را به بحث می گذاریم. این مورد دارای پتانسیل لازم و کاملا مفید با عملیات AUV، مخصوصا با توجه به اسکریپت ماموریت و فرآیند نظارتی می باشد. از آنجایی که سیستم تشخیصی افبرد تنها دارای دسترسی به زیر- مجموعه محدودی از متغیرها می باشد، رویه های تشخیصی که می توان آنها به صورت افبرد اعمال داشت در مقایسه با رویه هاي آنبرد  کاملا محدود می باشند. با این وجود، برخی از خطاهای بحرانی را می توان مشخص نمود، اگر چه با یک تغییر معنی دار در مقایسه با رویه تشخیص آنبرد. ما نتایج اولیه خود، بغیر از مبحث آنبرد و آفبرد، را در بخش 6 مورد بررسی قرار خواهیم داد.

الف. تحقیقات مرتبط

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

[1] On-board

[2] Bayesian

[3] Antarctica

[4] flight software

[5] mission script

[6] off-board

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

تحقیق در خصوص عیب یابی و تحمل خرابی برای AUV و ROV ها در مرجع [5] ارائه شده است. بسیاری از این دیدگاه ها مدل- مبنا می باشند، اما این ویژگی صرفا برای سیستم هاي فرعی محدود، به طور مثال برای راه اندازها / محرک های ذکر شده در مرجع [6] مدنظر می باشد. این مدل ها در چنین وضعیتی به صورت سیستم پیوسته، به جای سیستم گسسته که L2 استفاده می کند، بوده و معایب شامل تغییراتی در پارامترهای سیستم هستند.

ارتباط بین این انواع دیدگاه ها و دیدگاهی که ما  حاصل آورده ایم آن است که L2 فراهم آورنده عیب یابی سطح – سیستمی، به جای سطح- جزئی می باشد. در حقیقت، خروجی خطا یا عیوب جزئی قابلیت کنترل موارد مشخص شده در مرجع [6] را داشته تا  احتمال کاربرد آنها بعنوان ورودی های بسیار مناسبی برای L2  بوجود آید. ما این ایده را در بخش 7 باز  نموده و در آن اقدام به تشریح یکپارچه سازی مدل های سیستم مبنای هیبرید همراه با مدل های گسسته L2 خواهیم نمود.

2- آنالیز خطاهای اتوساب 6000

معماری اتوساب 6000 شامل شبکه ای از اجزای مختلف، در بردارنده ادوات علمی، سطوح کنترل و موتورها، می باشد که همگی به وسیله یک جزء واحد، که وظیفه آن کنترل ماموریت از طریق اجرای اسکریپت ماموریت می باشد، کنترل گردیده [7] و بعلاوه این جزء قابلیت توزیع دستورات داخلی به مولفه ها یا اجزای مختلف دیگر را نیز خواهد داشت. اطلاعات خوانده شده حسگر، از اجزای مختلف، از طریق شبکه به سمت جزء کنترل کننده ماموریت و همچنین ثبات[1]  که یک کامپیوتر شخصی (PC) با قابلیت ذخیره سازی داده ها می باشد انتقال یافته و سپس از این طریق داده ها به موتور تشخیصی هدایت شده و آن را برای اعمال فرآیندهای تله متری / دور سنجی صوتی در اختیار سیستم موجود / کشتی در سطح دریا می گذارد.

این ربات دارای چهار راه انداز / محرک، موتور، رها کننده های وزنه های کاهش وزن[2]، سکان عمودی عقب[3] و باله عقب[4] می باشد. حتی بدون رها سازی وزنه های کاهش وزن، این ربات هنوز به صورت مثبتی قابلیت شناوری در عملیات نرمال را خواهد داشت. این ربات نیروی خود را از 12 باتری پلیمری لیتیوم سفارشی می گیرد که قابلیت فراهم آوردن نیروی مورد نیاز در محدوده ای بیش از 550 کیلومتر و ماموریت فراتر از 85 ساعت را خواهد داشت [8]. سیستم فرعی نیرو، قابلیت تفکیک توان برای بارهای حیاتی (موتور) و ابزارهای علمی (هتل) را خواهد داشت. راه اندازها و حسگرها که در تعامل با سیستم ناوبری ربات هستند متصل به مدار حیاتی برق می باشند، در مقابل ادوات علمی به یک مدار مجزای غیر حیاتی متصل می باشد.

[1] logger

[2] abort weights

[3] rudder

[4] stern-plane

الف. بروز مواردی از شکست و خطا در ماموریت های قبلی

اتوساب 6000 تاکنون 36 ماموریت را انجام داده است و انواع ربات های قبلی آن تحت عناوین اتوساب 1، اتوساب 2، اتوساب3 تواما بیش از 430 ماموریت را به اتمام رسانده اند. بنابراین، ما از موقعیت ممتازی، در زمینه دسترسی به مقادیر بسیار زیادی از داده های ثبت شده، هم به صورت اسمی و هم داده های خطا، برخوردار می باشیم و این بدان معنا می باشد که به جای تست سیستم عیب یاب با استفاده از یک شبیه ساز، می توانیم از داده های ثبت شده حقیقی که برای اهداف ارزیابی در دسترس می باشند استفاده نماییم. لیستی از موارد منتج به شکست/ خرابی که تاکنون مشاهده نمودیم در جدول 1 مشخص شده است. این لیست بر مبنای آنالیز کامل ماموریت های اتوساب 6000 می باشد، اما در خصوص سیستم های دیگر تنها به تحلیل نسبی بسنده شده است. تعداد زیاد خطاهای راه انداز باله عقب، در مقایسه با سیستم هاي فرعی دیگر، ممکن است به صورت نسبی بواسطه طبیعت یا ذات بحرانی باله عقب باشد، که حتی تغییرات اندک در رفتار را بسیار جدی قلمداد می کند. اتوساب 3 و اجداد آن از فناوری بسیار مختلفی از نظر باتری در مقایسه با اتوساب 6000 استفاده نموده اند، بنابراین ما هیچ گونه تلاشی را جهت پیگیری مشکلات در این زمینه بر روی ادوات قدیمی تر انجام ندادیم. تعداد زیادی از مشکلات باتری احتمالا در ابتدا مرتبط با این حقیقت می باشند که چندین باتری بصورت آنبرد / داخل ربات وجود داشته است، اما مسایل مرتبط با کاربرد فناوری های نوین در باتری اتوساب 6000 را نیز باید مد نظر قرار داد.

3- تشخیص مدل- مبنا با استفاده از لوینگستون 2

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

تشخیص مدل – مبنا (MBD) [11] به عنوان جایگزینی برای سیستم های تخصصی به شمار می آید که به طور موفقیت آمیزی در تعدادی از حوزه ها به کار گرفته شده است. این دیدگاه از یک مدل رفتار فيزيکی سیستم بهره می جوید. رویه تشخیص خطا همراه با مقایسه رفتار پیش بینی شده سیستم، بر مبنای این مدل و با توجه به رفتار مشاهده شده سیستم و با استفاده از انواع مختلف رابط ها جهت تشریح هر گونه اختلاف،  مد نظر می باشد. برخی از سیستم ها،  نظیر GDE [11]، لوینگستون [12]، هاید[1] [13] و لیدیا[2] [14] بر اساس این دیدگاه توسعه یافته اند. کلیه این موارد کاملا از نظر ظرفیت مشابه هستند، با این حال هاید به طور مثال، اجازه به کار گیری مجموعه ای از غنی تری از مدل ها، شامل مدل های سیستم گسسته – پیوسته هیبرید، را خواهد داد. دلیل استفاده ما از سیستمی که ما در لوینگستون 2 بکار گرفته شده است دسترسی آزادانه / مجانی بدان است و بعلاوه بدین علت است که این سیستم قبلا در کاربردهای مشابهی مورد استفاده قرار گرفته است.

[1] Hyde

[2] Lydia

الف. کاربرد L2 برای اتوساب

در بخش 2 ما نگاه خود را معطوف به آنچه منجر به بروز شکست یا عدم موفقیت ماموریت های قبلی شده است می نماییم. قبل از استفاده L2 جهت تشخیص اتوساب، ما از این داده ها جهت مشخص نمودن عیوب حیاتی، که ممکن است سیستم را با ریسک روبرو سازد، استفاده می نماییم. به طور مثال، با آنکه عیب on-switch در ماموریت 15، که در نهایت منجر به کنسل نمودن پروژه گردید، بوجود آمد، این عیب سبب نشد تا خود ربات در معرض خطر قرار گیرد. از طرف دیگر، بروز خطا در راه انداز باله عقبی در ماموریت 12، همراه با عیوب مشابه دیگر در اتوساب3  سبب گردد تا این ربات به طور مستقیم در معرض خطر برخورد با بستر دریا قرار داشته باشد. بنابراین، ما به منظور تشخیص نسبت به مشخص نمودن کنترل عمق به عنوان یک اولویت اقدام می نماییم. به علاوه، از آنجایی که کنترل عمق غالبا شامل ارسال ربات به عمق مورد نظر و سعی در کنترل ربات در آن شرایط می باشد، این سیستم فرعی را می توان بعنوان یک مورد مناسب جهت مدل سازی در L2، با توجه به تفاوت بین عمق درخواستی و عمق حقیقی، در نظر گرفت و میزان تغییر در این تفاوت را می توان جهت مدل سازی مطلوب و دقیق رفتار این ربات مورد استفاده قرار داد. سیستم فرعی دومی که ما جهت مدل سازی انتخاب نمودیم باتری ها هستند که علت آن عمدتا به واسطه خطاها یا عیوب قابل توجهی است که در آنها مشاهده می شود. علاوه براین، ما تصور می کنیم که مدل سازی این سیستم فرعی چالش برانگیز بوده و بر این مبنا ارزیابی شایستگی نسبی دیدگاه ثبات – محور[1] در برابر یک دیدگاه آماری- محور[2] بیشتر در خصوص تشخیص با استفاده از فیلتر های جزء مفید باشد [17]، [18].

[1] consistency-based approach

[2] statistical based approach

ب. تسکین عیوب و خطاها در اتوساب 6000

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

[1] commanded transitions

[2] redundancy

[3] redundant pathway

[4] overhead

4- مدل تشخیصی اتوساب 6000

جهت نشان دادن دیدگاه تشخیص ثبات – محور ما یک مدل تشخیصی ساده شده زیر مجموعه اتوساب 6000 را ارائه داده و اقدام به بحث در خصوص ویژگی هاي کلیدی چنین مدلی نمودیم. اولین ناحیه ای که ما اقدام به بررسی آن می نماییم سیستم کنترل عمق می باشد، چرا که ما دارای داده های معیوبی از این سیستم می باشیم (ماموریت 12 اتوساب 6000)، و بواسطه آنکه این سیستم به عنوان یک مولفه حیاتی برای ایمنی ربات زیرآبی به شمار می آید.

اتوساب 6000 داراي مودهای مختلف کنترل عمق می باشد که در آن متغیرهای  مختلف شبکه معنی دار خواهد بود. این موضوع در شکل 2 نشان داده شده است. نمودار سمت چپ نشان دهنده رفتار اسمی این ربات در طی فاز غوطه وری می باشد. خط قرمز متشکل از علامت های « +» معرف سنجش عمق می باشد و خط آبی که با علامت های « ×» نشان داده شده است بر مبنای تقاضاهای عمقی است که از اطلاعات حاصله از ماموریت 12 بدست آمده است. توجه شود که برای دوره های طولانی که در آن عمق مورد تقاضا 200 متر می باشد، ربات زیردریایی همچنان به غوطه وری ادامه می دهد. این مورد به واسطه آن است که ربات در یک مود غوطه وری زاویه باله عقبی ثابت[1] در حال پایین رفتن می باشد ک در آن تقاضاهای عمق نادیده انگاشته می شود. بنابراین، چنین رفتاری به صورت اسمی خواهد بود. ستاره های سیاه معرف لحظاتی است که خطوط مقتضی در اسکریپت ماموریت آغاز می شوند.

[1] fixed stern plane angle dive mode

الف. پروفایل عمق

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

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

[1] waypoint

5- تشخیص خارج از ربات / از راه دور

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

یکی از دیگر کاربردهای سیستم تشخیص عیب اتوماتیک برای اتوساب 6000 ربات خودکار زیرآبی مانیتورینگ یا کنترل از راه دور از طریق سیستم تله متری به عنوان یک راهکار کمکی برای اپراتورها می باشد. تله متری یا دورسنجی قابلیت برقراری ارتباط از اتوساب به کشتی پشتیبان از طریق لینک صوتی را خواهد داشت. به هنگامی که این لینک صوتی اقدام به برقراری ارتباط تا محدوده 7 کیلومتری می نماید، عملکرد آن محدود به 80 بایت پاکتی می باشد که هر 20 الی 30 ثانیه یک بار ارسال می گردد. احتمال اتلاف پاکت با توجه به فاصله افزایش خواهد یافت و مشاهده اتلاف پاکت به میزان بیش از 20 درصد مورد تعجب برانگیزی به شمار نمی آید. برای فرآیند تشخیص، چنین موردی یک چالش قابل توجه بحساب می آید چرا که رویه تشخیصی ما بر مبنای داده های بسیار اندکی بوده و برخی از دستورات و اطلاعات حالات ممکن است برای زمانی طولانی از دست بروند.

6- آزمایشات

جهت کنترل کارایی سیستم تشخیصی ثبات – محور و همچنین مدل های ما، اقدام به راه اندازی موتور تشخیصی بر روی داده های ثبت شده از 25 ماموریت حقیقی اتوساب 6000، شامل ماموریتی که متشکل از داده های اسمی و پتانسیل سنج خطا که در شکل 2 نشان داده شده است، نمودیم. برای مقایسه، ما این مدل تشخیصی را بدون اعمال مدل اسکریپت ماموریت انجام دادیم. در کلیه موارد، این مدل ها هیچ گونه خطای مثبت کاذب را نداشته اند. با این وجود، در مورد سناریوی عیب پتانسیل سنج، مدلی که شامل جزء اسکریپت ماموریت نبوده است قابلیت تشخیص خطا را نداشت، در حالیکه مدلی که داراي جزء اسکریپت ماموریت بوده است قابلیت تشخیص خطا در زمان ماموریت 5:32:40 را داشت، تقریبا 54 ثانیه پس از بروز شواهد اولیه خطا در داده ها و 8 ثانیه قبل از رها سازی وزنه های کاهش وزن، چرا که این ربات از حداکثر عمق مجاز عبور نموده بود. بدون جزء اسکریپت ماموریت، سیستم تشخیصی قابلیت مشخص نمودن این موضوع که سیستم هنوز در مود کنترل عمق می باشد را نخواهد داشت، بنابراین چنین موردی قابلیت تشریح رفتار معیوب از طریق این فرض را خواهد داشت که ربات به مود کنترل باله عقبی سوییچ نموده و تقاضاهای مربوط به عمق را نادیده می گیرد.

7- تحقیقات آتی

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

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

در نهایت، ما در این مقاله به برخی از سیستم های فرعی که نمی توان آنها به سادگی با استفاده از دیدگاه گسسته L2 مدل سازی کرد توجه نداشته ایم. ما قبلا در خصوص تحقیقات مرتبط با تشخیص پیشرانه ها برای ربات های زیرآبی خودکار صحبت نمودیم [6]، در عین حال به طور السویه می بایست نگرانی خود در خصوص مسایل مرتبط با پیشرانه و چگونگی تشخیص آنها به هنگام رویارویی با جریانات قدرتمند را بیان نماییم. مثال دیگر باتری ها هستند. در حال حاضر ما دارای یک مدلی کاملا تجریدی هستیم که غالبا سبب حصول این نتیجه می گردد که یک خطای ناشناخته وجود دارد، چرا که قابلیت تشخیص رفتارهای مکفی وجود ندارد. یک مدل هیبرید که دارای خطاهای گسسته می باشد اما همچنین قابلیت پیش بینی رویه های سنجشی پیوسته حسگر را دارد امید بیشتری، برای بهره گیری از این سیستم های تشخیصی همانند چنین مواردی، را به ارمغان می آورد. ما نسبت به ایجاد الگوریتم های تشخیصی برای این نوع از مدل ها [18] بر مبنای الگوریتم های فیلترینگ جزء اقدام نمودیم، اما در حال حاضر، ما آنها را در L2 به کار نبرده ایم. دیدگاه های فیلترینگ عملی برای سیستم های فرعی کوچک متناسب هستند، اما در فرم کنونی آنها را نمی توان در مدل های سیستمی بزرگ به کار گرفت، بنابراین ما امید داریم تا قابلیت استفاده از L2 جهت یکپارچه سازی اطلاعات تشخیصی از یک محدوده تشخیص گرهاي ساده برای سیستم های فرعی را داشته باشیم.

[1] Autosub Long Range

8- نتیجه گیری

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

بر مبنای این نتایج ما عقیده داریم که MBD به عنوان یک ابزار کاملا مفید جهت افزایش طول عمر یا دیرپایی بکارگیری ربات های خودکار زیرآبی مد نظر بوده و بنابراین می تواند به ما در خصوص آغاز ماموریت های طولانی مدت تر و خودمختاری بیشتر تعداد زیادی از رویه های کاربردی کمک نماید. سیستم تشخیصی که ما در حال استفاده از آن می باشیم یک سیستم کلی است، بنابر این می توان آن را بر روی ابزارهای دیگر نیز به کار گرفت؛ بر این مبنا، ما به آهستگی اقدام به ایجاد کتابخانه ای از مدل ها و مولفه های مختلفی می نماییم که می توان از آنها مجددا برای کاربرد در وسایل مختلف دیگر به غیر از اتوساب 6000 استفاده نمود. با این حال، ذکر این نکته مهم است که هنوز وظایف مدلسازی قابل توجهی وجود دارند تا بتوان به سیستمی همانند L2 رسید که قابلیت کارکرد در ربات های جدید را داشته باشد: مدل سازان می بایست قابلیت درک چنین سیستم هایی را داشته باشند. مدل های گسسته را می بایست تولید نمود، مانیتورها را می بایست در تعامل با این مدل ها طراحی کرده و به راه انداخت و در نهایت پارامترهای این مدل را نیز می بایست متناسب ساخت. ما در حال ایجاد ادواتی هستیم که چنین روندی را ساده تر می سازد، اما هنوز اقدامات زیادی وجود دارند که باید آنها را انجام داد. 

عیب یابی و مانیتورینگ اتوماتیک روبات خودکار زیرآبی