نوشته ها

ارزیابی دیسپچینگ هواپیما در چارچوب پشتیبانی تصمیم‌گیری و نمونه اولیه

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

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

این مشکلات اغلب منجر به تأخیر و هزینه‌های اضافی می‌شوند و نشان‌دهنده سه چالش بزرگ‌تر در حوزه پشتیبانی تصمیم‌گیری هستند: 1) کمبود مدل‌ها و برنامه‌های پشتیبانی تصمیم‌گیری برای فرآیندهای عملیاتی در نگهداری؛ 2) تلاش‌های نسبتاً کمی در اعمال و ارزیابی آثار در محیط‌های تجربی و عملیاتی واقعی؛ و 3) فقدان توسعه سیستماتیک، اعمال و ارزیابی تلاش‌های دیجیتالی‌سازی و اتوماسیون فرآیندهای تصمیم‌گیری پیچیده در نگهداری.

ارزیابی دیسپچینگ هواپیما

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

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

1. مقدمه

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

با این حال، نگهداری نیز می‌تواند تأثیر قابل توجهی بر عملیات پروازی داشته باشد، به عنوان مثال از طریق تأخیرها؛ 5.8٪ از تمام پروازها در اروپا همچنان به دلیل علل فنی مستقیم هواپیما تأخیر دارند که منجر به هزینه اضافی تخمینی 2.8 میلیارد یورو در هر سال می‌شود [1]. از این رو، تحقیقاتی که بر کاهش تأثیر عملیاتی مسائل نگهداری غیرمنتظره متمرکز هستند، حیاتی است.

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

معمولاً تکنسین‌ها دسترسی محدودی به تجهیزات، ابزارها و اطلاعات پشتیبانی در باند پرواز دارند که منجر به فرایند ارزیابی دیسپچ می‌شود که وقت‌گیر، طاقت‌فرسا و باعث ایجاد تصمیمات نامطلوب است. این را می‌توان با تحقیقات قبلی نشان داد، جایی که مشخص شده است که تکنسین‌ها تا 30٪ از زمان خود را به جای انجام نگهداری ، صرف جمع‌آوری اطلاعات پشتیبانی می‌کنند [2].

علاوه بر این، اگرچه استفاده از مستندات در حین اجرای نگهداری اجباری است، تکنسین‌ها معمولاً به طور مداوم بین ایمنی، قانونی بودن و کارایی معامله می‌کنند [3] زیرا زمان برای انجام ارزیابی دیسپچ و نگهداری بعدی محدود است

(معمولاً بیش از 30 دقیقه برای هواپیماهای بدنه‌باریک مانند ایرباس A320 و بوئینگ 737، که به طور معمول در حمل و نقل هوایی قاره‌ای استفاده می‌شوند، نیست) این موضوع تأثیر منفی بر عوامل خطر انسانی شناخته‌شده در نگهداری هواپیما دارد (مثلاً استرس، فشار و رضایت‌مندی) که می‌تواند منجر به خطاهای نگهداری یا حتی حوادث شود [4,5].

در حالی که این مسائل در فرآیند ارزیابی دیسپچ در نگهداری هواپیما خاص هستند، اما به مجموعه‌ای از چالش‌های بزرگتر در فرآیندهای تصمیم‌گیری اشاره می‌کنند که توجه نسبتاً کمی در تحقیقات پشتیبانی تصمیم گیری به آن‌ها شده است (به بخش 2 نیز مراجعه کنید):

• پشتیبانی تصمیم‌گیری برای فرآیندهای عملیاتی در نگهداری: کارهای موجود در برنامه‌های نگهداری تمایل دارند تا بر پشتیبانی از تصمیم‌گیری برای برنامه‌ریزی و زمان‌بندی نگهداری تمرکز کنند که شامل افق‌های زمانی هفته‌ها، ماه‌ها یا حتی سال‌ها می‌شود [6,7].
• کاربرد و ارزیابی در محیط‌های عملیاتی نگهداری واقعی: سیستم‌های پشتیبانی تصمیم‌گیری معمولاً به‌طور کامل ارزیابی می‌شوند، اما مطالعات موردی عملی که به کاربرد و ارزیابی در فرآیندهای واقعی – به ویژه زمانی که به نگهداری عملیاتی محدود می‌شود – می‌پردازند، رایج نیستند. تحقیقات نشان می‌دهند که بین سیستم‌های نظری و استفاده واقعی از سیستم، همبستگی کمی وجود دارد [8,9]. برای غلبه بر این مشکل، پژوهشگران در این حوزه بر نیاز به مطالعات موردی بیشتر تأکید می‌کنند [[10], [11], [12], [13], [14]].
• دیجیتالی‌سازی و اتوماسیون فرآیندهای تصمیم‌گیری پیچیده در نگهداری: در حالی که حوزه نگهداری الکترونیکی بر پردازش، یکپارچه‌سازی و توزیع اطلاعات برای پشتیبانی از فرآیندهای تصمیم‌گیری تمرکز دارد [15]، شکاف‌های بزرگی ، مانند کمبود مدل‌ها و روش‌شناسی‌ها برای تصمیم‌گیری در محیط‌های توزیع شده، درک تعاملات انسان-ماشین (که برای سیستم‌های پشتیبانی تصمیم‌گیری برخلاف راه‌حل‌های الگوریتمی ، بحرانی است،) و کمبود معیارهای ارزیابی [16] باقی می‌مانند.

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

1) یک چارچوب پشتیبانی تصمیم‌گیری نوین برای تصمیم‌گیری در لحظه در دیسپچ هواپیما، که بر اساس یک فرآیند تصمیم‌گیری رسمی شده ساخته شده است [17]؛

2) یک ابزار نمونه اولیه مبتنی بر وب که از طریق برنامه های موبایلی قابل دسترسی است، که در پروژه Clean Sky 2 AIRMES توسعه یافته است [1,18]. ارزیابی این آثار از طریق دو کاربرد انجام شده است که امکان تحلیل کمی و کیفی عناصر اصلی چارچوب و نمونه اولیه را فراهم می‌کند.

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

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

2. وضعیت هنر

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

2.1. دیدگاه کلی نسبت به سیستم‌های پشتیبانی تصمیم‌گیری

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

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

در حالی که اجماع کلی وجود دارد که استفاده از DSS منجر به تصمیمات بهتری می‌شود، کمبود همبستگی بین سیستم‌های نظری و استفاده واقعی از سیستم مورد توجه قرار گرفته است [8,9].

به عنوان راه‌حل، مطالعات موردی در ادبیات علمی خواسته شده‌اند [11,13,14]. مطالعات موردی دارایی ارزشمندی برای ساخت تئوری ها هستند [22]. علاوه بر این، مطالعات موردی همکاری بین تصمیم‌گیرندگان و طراحان سیستم را بهبود می‌بخشند، که منجر به سیستم‌هایی می‌شود که مشکلات دنیای واقعی را مورد توجه قرار می‌دهند [23].

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

هدف DSR توسعه راه‌حل‌های مبتنی بر فناوری نوین برای حل مشکلات دنیای واقعی کسب و کار است و معمولاً قبل از ایجاد یک سهم علمی ،منجر به توسعه یک اثر می‌شود [24,25]. با توجه به تمرکز بر اهمیت DSR [26]، شگفت‌آور است که تعداد قابل توجهی از انتشارات فاقد ارزیابی هستند و صرفاً به توصیف آثار توسعه یافته بدون تعیین ارزش، اثربخشی یا مفید بودن آن‌ها می‌پردازند [27].

2.2. پشتیبانی تصمیم‌گیری در حوزه نگهداری

هنگام بررسی پشتیبانی تصمیم‌گیری در نگهداری، توجه به این نکته مهم است که جریان روزافزون اطلاعات، استفاده کاغذی از مستندات، تکیه بر سیستم‌های قدیمی و دیجیتالی شدن نسبتاً کند در بسیاری از حوزه‌های کاربردی نگهداری [28] مسائلی هستند که منجر به کاهش دسترسی سیستم می‌شوند.

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

با این حال، شکاف‌هایی در پژوهش‌های فعلی نگهداری الکترونیکی وجود دارد، مانند کمبود مدل‌ها و روش‌شناسی‌های معتبر برای تصمیم‌گیری در محیط‌های توزیع شده، درک تعاملات انسان-ماشین و کمبود معیارهای ارزیابی [16].

هنگام بررسی کاربردهای پشتیبانی تصمیم‌گیری در نگهداری، اکثر مقاله های اخیر بر سیاست‌های نگهداری مبتنی بر شرایط و رویکردهای نگهداری پیش‌بینی‌محور تمرکز دارند (مثلاً [[30], [31], [32]]).

تعداد قابل توجهی از کارها پشتیبانی تصمیم‌گیری برای برنامه‌ریزی استراتژیک نگهداری و زمان‌بندی تاکتیکی به منظور بهینه‌سازی دسترسی سیستم و کاهش هزینه‌ها ارائه می‌دهند. این کارها معمولاً افق‌های زمانی روزها، هفته‌ها، ماه‌ها یا حتی سال‌ها را در بر می‌گیرند [6,7].

تنها تعداد کمی از انتشارات به پشتیبانی تصمیم‌گیری عملیاتی در نگهداری هواپیما می‌پردازند، جایی که مسائل نیازمند به حل و فصل (نزدیک به) لحظه ای در نظر گرفته می‌شوند. دو تا از مرتبط‌ترین انتشارات توسط Papakostas  و همکاران (2010) و Dhanisetty و همکاران (2018) هستند، در حالی که کار Papakostas  و همکاران [33] برنامه‌ریزی نگهداری کوتاه‌مدت را در یک چارچوب پشتیبانی تصمیم‌گیری چند معیاری به منظور بهبود قابلیت عملیاتی هواپیما و کاهش هزینه‌های نگهداری بررسی می‌کند.

Dhanisetty و همکاران [34] رویکردی برای تصمیم‌گیری چند معیاری برای تصمیمات نگهداری عملیاتی با افق‌های زمانی چند ساعت یا حداکثر چند روز توسعه داده‌اند. هر دو کار فرضیات بزرگی در مورد نوع وظایف، محتوای وظیفه و افق‌های زمانی قابل قبول در فرآیندهای تصمیم‌گیری خود دارند که لزوماً بازتاب فرآیندهای نگهداری عملیاتی (نزدیک) لحظه ای نیستند، جایی که تصمیمات باید در کمتر از یک ساعت، یا معمولاً فوری، شکل بگیرند.

ترکیب مباحث قبلی سه چالش اصلی مطرح شده در مقدمه را برجسته می‌کند: 1) برنامه‌های پشتیبانی تصمیم‌گیری برای فرآیندهای عملیاتی در نگهداری نسبتاً نادر هستند؛ 2) کاربرد و ارزیابی سیستم‌های پشتیبانی تصمیم‌گیری در محیط‌های عملیاتی واقعی نیازمند بهبود است؛ و 3) دیجیتالی‌سازی و اتوماسیون فرآیندهای تصمیم‌گیری پیچیده در نگهداری به دلیل کمبود مدل‌های معتبر و تلاش‌های ارزیابی مرتبط با آن‌ها دچار عقب‌ماندگی است.

3. روش‌ها: چارچوب ارزیابی دیسپچ و توسعه نمونه اولیه برای رسیدگی به چالش‌های شناسایی شده

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

1) یک چارچوب نوین برای پشتیبانی تصمیم‌گیری در لحظه برای مشکل ارزیابی دیسپچ؛

2) یک نمونه اولیه DSS مبتنی بر وب و موبایل برای کمک به تکنسین‌ها در ارزیابی دیسپچ و اجرای نگهداری بعدی. نمونه اولیه پس از تعریف نسخه اول چارچوب توسعه یافته است؛ نسخه‌های بعدی هر دو اثر به صورت تکراری و وابسته به هم توسعه یافته‌اند.

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

3.1. رسمی‌سازی فرآیند ارزیابی دیسپچ

در طول ارزیابی دیسپچ، تکنسین – به عنوان تصمیم‌گیرنده – نقش مرکزی در فرآیند دارد؛ او ارزیابی و کار نگهداری لازم (بعدی) را انجام می‌دهد و مسئول تأیید صلاحیت پروازی هواپیما است.

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

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

یک مثال از ذینفعان و خطوط ارتباطی آن‌ها در شرایطی که سازمان نگهداری بخشی از شرکت هواپیمایی است در شکل 1 ارائه شده است. سیستمی که اطلاعات مشترک بین ذینفعان را به اشتراک می‌گذارد، همکاری را بهبود می‌بخشد و می‌تواند کاهش سوءتفاهمات را مستقل از ساختار سازمانی به دنبال داشته باشد،.

با تعریف ذینفعان، رویکرد 8 مرحله‌ای که توسط  Bakerو همکاران [17] پیشنهاد شده است، برای رسمی‌سازی فرآیند تصمیم‌گیری دیسپچ به کار گرفته می‌شود:

مرحله 1: تعریف مشکل

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

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

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

مرحله 2: تعیین الزامات

 الزامات شرایطی را توصیف می‌کنند که راه‌حل‌های ممکن باید برآورده کنند. در دیسپچ هواپیما، مهم‌ترین الزام ایمنی و پس از آن عملکرد به موقع است. استاندارد جهانی برای تأخیر پرواز توسط اداره هوانوردی فدرال (FAA) تعریف شده است: یک پرواز در صورتی با تأخیر محسوب می‌شود که 15 دقیقه دیرتر از زمان برنامه‌ریزی شده حرکت یا رسیدن کند.

بنابراین، الزامات برای یک راه‌حل دیسپچ این است که: 1) یک راه‌حل دیسپچ نباید صلاحیت پروازی هواپیما را به خطر بیاندازد؛ 2) یک راه‌حل دیسپچ نباید منجر به حرکت‌های دیرتر از 15 دقیقه پس از زمان برنامه‌ریزی شده حرکت شود؛ 3) همه گزینه‌های موجود باید ارزیابی شوند.

مرحله 3: تعیین اهداف

 Baker و همکاران اهداف را به این صورت تعریف می‌کنند: “اهداف بیانیه‌های کلی قصد و ارزش‌های برنامه‌ریزی مطلوب را توصیف می‌کنند” [17]. با توجه به این تعریف، اهداف تصمیمات دیسپچ فردی این است که ایمنی را با پایبندی به روش‌های مستندات نگهداری تضمین کنند و زمان تصمیم‌گیری را به حداقل برسانند.

مرحله 4: شناسایی گزینه‌ها

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

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

مرحله 5: توسعه معیارهای ارزیابی

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

مرحله 6: انتخاب ابزار

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

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

مرحله 7: استفاده از ابزار و انتخاب جایگزین

یک تکنسین گزینه‌های نگهداری و نتایج احتمالی مرتبط با دیسپچ را ارزیابی کرده و سپس بهترین گزینه را انتخاب می‌کند.

مرحله 8: اعتبارسنجی

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

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

3.2. اثر 1 : چارچوبی برای پشتیبانی تصمیم‌گیری دیسپچ هواپیما

 با پیروی از رویکرد DSR، یک چارچوب نوین برای سیستم پشتیبانی تصمیم‌گیری دیسپچ توسعه یافته است. این چارچوب در شکل 2 به تصویر کشیده شده است. چارچوب شامل سه لایه اصلی برای DSS (یعنی مدل، پایگاه داده و رابط کاربری [35]) است و با لایه معیارهای تصمیم‌گیری گسترش یافته تا تأثیر معیارها بر نتیجه تصمیم را نشان دهد.

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

3.2.1.  لایه معیارها

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

در دیسپچ هواپیما تمرکز قوی بر عملکرد به موقع وجود دارد و بنابراین زمان یک معیار مهم است. هم زمان مورد نیاز برای تکمیل نگهداری پس از یک تصمیم دیسپچ و هم زمان موجود قبل از پرواز بعدی برای ارزیابی گزینه‌ها مهم هستند.

معیار دیگری که می‌توان در نظر گرفت، شانس تاریخی موفقیت یک اقدام انتخاب شده است (یعنی انتخاب یک یا چند اقدام نگهداری). با فرض اینکه داده‌های قابل اعتماد در دسترس است، تلاش‌های قبلی برای حل همان یا یک مسئله مشابه می‌تواند برای تولید احتمال موفقیت در اقدامات آینده استفاده شود.

در حالی که به دلیل عدم وجود یا محرمانه بودن داده‌های ثبت شده در کار فعلی شامل نشده است، معیار تأثیر عملیاتی می‌تواند با در نظر گرفتن هزینه‌های کل مرتبط با یک اقدام نگهداری خاص، شامل هزینه‌های مستقیم (مانند قطعات یدکی، نیروی کار)، هزینه‌های روی زمین (مانند پارکینگ، یدک‌کشی) و هزینه‌های اختلال (مانند تأخیر، لغو) [34] اضافه شود.

از بین این موارد، مخصوصاً هزینه‌های اختلال پیچیده هستند. نمونه‌هایی در ادبیات علمی به بحث در مورد کاهش این هزینه‌ها از طریق مدل‌های بهینه‌سازی پرداخته‌اند که شامل هزینه‌هایی مانند تأخیر مسافر و هزینه‌های لغو پرواز می‌شود [36,37].

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

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

3.2.2. لایه پایگاه داده

لایه پایگاه داده اطلاعات مورد نیاز برای انجام مراحل در مدل فرآیند (به زیر بخش بعدی مراجعه کنید) را فراهم می‌کند و شامل منابع زیر است:

• دفترچه فنی هواپیما: شامل تاریخچه نگهداری هواپیما، از جمله اطلاعات نقص/خطا. این دفترچه به طور سنتی به صورت کاغذی بوده، اما به تدریج به نسخه دیجیتال منتقل می‌شود. دفترچه فنی هواپیما باید در حین عملیات پروازی در هواپیما باشد.
• جزئیات هواپیما: شامل اطلاعات دقیق هر هواپیما در ناوگان، مانند شماره دم، سازنده، مدل، سری، شماره سریال سازنده (MSN) و شماره سریال مشتری (CSN). این اطلاعات در مراحل بعدی فرآیند مورد نیاز است، مثلاً برای وارد کردن برنامه پرواز و تعیین محتوای قابل اعمال در دستورالعمل‌های نگهداری.
• مستندات نگهداری: شامل مستندات نگهداری که توسط سازنده ارائه شده است. نمونه‌های مرتبط برای ارزیابی دیسپچ شامل دفترچه راهنمای عیب‌یابی (TSM)، دفترچه راهنمای نگهداری هواپیما (AMM)، دفترچه راهنمای شماتیک هواپیما (ASM) و دفترچه راهنمای روش‌های استاندارد الکتریکی (ESPM)، و فهرست حداقل تجهیزات (MEL) است که تجهیزاتی را توصیف می‌کند که تا زمانی که شرایط عملیاتی و/یا نگهداری متعاقب آن‌ها رعایت شود، می‌تواند غیرفعال باشد. مستندات نگهداری به طور مرتب به‌روزرسانی می‌شوند و استفاده از آخرین نسخه در هنگام اجرای نگهداری از اهمیت بالایی برخوردار است. یک عامل پیچیده برای استفاده از این داده‌ها این است که اسناد می‌توانند در فرمت‌های دیجیتال مختلف (مانند SGML/XML یا PDF) ارائه شوند که هر کدام نیاز به روش‌های متفاوتی برای پردازش دارند.
• داده‌های ارزیابی معیارها: شامل داده‌هایی است که برای ارزیابی با توجه به معیارهای خاصی استفاده می‌شود. به عنوان مثال، برنامه پرواز و داده‌های مربوط به زمان متوسط برای تکمیل یک وظیفه نگهداری می‌توانند برای ارزیابی یک گزینه با توجه به معیار زمان استفاده شوند. اطلاعات موجود در این پایگاه داده بسیار پویا است و نیاز به پردازش در لحظه دارد. به عنوان مثال، برای محاسبه زمان موجود برای دیسپچ و نگهداری متعاقب آن، ضروری است از آخرین اطلاعات برنامه پرواز استفاده شود.

3.2.3. لایه مدل فرآیند

مدل فرآیند توسعه‌یافته شامل شش مرحله زیر است:

مرحله I : جمع‌آوری گزارش‌های نقص

اولین گام تعیین این است که آیا مشکل گزارش شده ای در هواپیما وجود دارد یا خیر. هر هواپیما یک دفترچه فنی دارد که شامل وضعیت و تاریخچه نگهداری است. با انتقال به نسخه دیجیتال دفترچه فنی هواپیما (مثلاً دفترچه الکترونیکی ELB)، این فرآیند در ابزار پشتیبانی تصمیم‌گیری دیسپچ نمونه اولیه خودکار شده است.

مرحله II : جمع‌آوری داده‌های هواپیما

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

مرحله III : شناسایی گزینه‌های نگهداری

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

مرحله IV : فیلتر و رتبه‌بندی گزینه‌های نگهداری

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

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

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

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

مرحله V : ارائه نمای کلی از نتایج جایگزین دیسپچ

سیستم یک نمای کلی از گزینه‌های موجود را ارائه می‌دهد و به محض انتخاب یک گزینه، نتیجه دیسپچ مورد انتظار را نشان می‌دهد. نتیجه دیسپچ مورد انتظار با ارزیابی گزینه‌ها با توجه به معیارها تعیین می‌شود.

بر اساس بازخورد کارشناسان صنعت، پنج نتیجه دیسپچ تعریف شده است که نسخه توسعه‌یافته‌ای از تعریف توسط Tiassou و همکارانش [38] است. اولین و کم‌اختلال‌ترین نتیجه دیسپچ GO است، جایی که تکنسین نمی‌تواند مشکل گزارش شده را پیدا یا بازتولید کند.

این وضعیت به عنوان No Fault Found (NFF) شناخته می‌شود و معمولاً توسط MCC برای تکرار نظارت می‌شود. دوم، GO-IF(P) شامل مشکلی است که ایمنی یا عملکرد را تحت تأثیر قرار نمی‌دهد، اما ممکن است محدودیت‌های خاصی بر اپراتور اعمال شود (مثلاً یک صندلی با سیستم سرگرمی در پرواز معیوب فروخته نمی‌شود).

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

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

نگهداری اصلاحی باید انجام شود و می‌تواند بدون تضاد با معیارها تکمیل شود. پنجمین و اختلال‌آمیزترین نتیجه NO GO است، جایی که مشکل نمی‌تواند به تعویق بیفتد زیرا یک آیتم حیاتی ایمنی است یا با یک آیتم تعویق یافته موجود تضاد دارد. نگهداری اصلاحی باید انجام شود و منجر به عدم رعایت یک یا چند معیار تصمیم می‌شود. پرواز به تأخیر می‌افتد یا لغو می‌شود و ممکن است اقدامات بازیابی لازم باشد (مثلاً تعویض هواپیما [39]).

مرحله VI : اعلام و ذخیره تصمیم

هنگامی که تکنسین جایگزین نگهداری بهینه را تعیین می‌کند و کاپیتان آن را تأیید می‌کند، تصمیم باید بین ذینفعان (مثلاً MCC، OCC) منتشر شود. تصمیم و متغیرهای مرتبط در پایگاه داده برای مرجع آینده ذخیره می‌شوند.

3.2.4. لایه رابط کاربری

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

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

انتخاب نقص:

کاربر فرآیند ارزیابی دیسپچ را با انتخاب نقص از دفترچه فنی هواپیما که می‌خواهد بر روی آن تمرکز کند، آغاز می‌کند.

انتخاب جایگزین:

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

تأیید جایگزین:

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

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

جزئیات خاصی در مورد UI توسعه یافته برای ابزار نمونه اولیه برای ارزیابی دیسپچ در بخش بعدی شرح داده شده است.

3.3.  اثر 2: نمونه اولیه

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

از منظر فناوری، ابزار موبایل نمونه اولیه برای تصمیم‌گیری دیسپچ بر پایه Node.js است. Node.js به دلیل پردازش سریع، غیرهمزمان و تعداد زیاد اتصالات همزمان موجود با توان عملیاتی بالا، پلتفرم مناسبی برای DSSهای مبتنی بر وب در لحظه فراهم می‌کند.

 Node.js از فرآیندهای سمت سرور پشتیبانی می‌کند، که عمدتاً لایه‌های پایگاه داده و مدل فرآیند توصیف شده در بالا را پوشش می‌دهند. یک رابط کاربری (UI) سمت کلاینت با استفاده از HTML و CSS توسعه یافته و به یک اپلیکیشن اندروید بسته شده است. تکنسین‌ها می‌توانند به نمونه اولیه در رایانه‌های رومیزی از طریق مرورگر اینترنت و در تبلت‌ها با استفاده از اپلیکیشن مذکور دسترسی پیدا کنند.

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

مدل فرآیند 6 مرحله‌ای که در بخش 3.2.3 معرفی شد، برای توضیح عناصر فرآیند نمونه اولیه اعمال شده است؛ جزئیات مربوط به فناوری زیرین و UI به عنوان بخشی از این عناصر به‌طور مفصل‌تر بحث و تجسم شده‌اند.

مرحله I : جمع‌آوری گزارش‌های نقص

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

مرحله II : جمع‌آوری داده‌های هواپیما

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

مرحله III : شناسایی گزینه‌های نگهداری

سه دفترچه نگهداری در نمونه اولیه پیاده‌سازی شده و مشاوره می‌شوند: دفترچه راهنمای عیب‌یابی (TSM) برای شناسایی دلایل و راه‌حل‌های ممکن برای نقص گزارش شده، فهرست حداقل تجهیزات (MEL) برای شناسایی گزینه‌های به تعویق انداختن و دفترچه راهنمای نگهداری هواپیما (AMM) برای ارائه روش‌های نگهداری در طول اجرای وظیفه.

مشاوره با TSM

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

مشاوره با MEL

برای برخی مشکلات، MEL گزینه‌هایی برای به تعویق انداختن نگهداری اصلاحی برای یک بازه زمانی خاص تعیین شده توسط ساعات عملیاتی، بر اساس دسته‌بندی (به جدول 1 مراجعه کنید) ارائه می‌دهد. این امر به اپراتور امکان می‌دهد تا بدون اینکه برنامه پرواز را مختل کند ، نگهداری اصلاحی را در زمان و مکان مناسب‌تری برنامه‌ریزی کند.

جدول 1: دسته‌بندی‌های بازه تعمیر MEL

اتوماسیون شناسایی جایگزین‌ها

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

 TSM و AMM در فرمت SGML ارائه شده‌اند، در حالی که MEL در فرمت XML ارائه می‌شود. این دفترچه‌ها توسط یک پارسر سفارشی پردازش می‌شوند که قادر به ایندکس کامل محتوای فایل‌های مبتنی بر SGML (مانند SGML و XML) است. پارسر یک فایل JSON برای هر سند ایجاد می‌کند که شامل اطلاعات همه تگ‌ها (مانند شاخص‌ها، ویژگی‌ها) است که سپس می‌تواند برای بازیابی محتوای واقعی به‌سرعت و به‌طور کارآمد استفاده شود.

همزمان، متادیتا (مانند مرجع وظیفه، عنوان، اثربخشی CSN، فصل و بخش ATA، تاریخ بازنگری) برای هر وظیفه در دفترچه‌ها در فایل‌های JSON جداگانه برای مرجع بعدی ذخیره می‌شود.

برای تعیین جایگزین‌های نگهداری در TSM، ابزار موبایل نمونه اولیه از پیام خطا برای شناسایی وظایف مرتبط TSM استفاده می‌کند. سپس، محتوای هر یک از این وظایف TSM برای جدول اطلاعات مرجع بررسی می‌شود که از آن جایگزین‌های فردی (AMM) استخراج می‌شوند. برای MEL، فرآیند بر اساس شماره فصل و بخش ATA مرتبط با یک مسئله است.

محتوای MEL مرتبط با این فصل و بخش به جایگزین‌های خاص AMM برای به تعویق انداختن نقص اشاره دارد. کل فرآیند استخراج اطلاعات از دفترچه‌ها و شناسایی جایگزین‌های نگهداری در ابزار موبایل نمونه اولیه خودکار شده و منجر به یک فایل JSON واحد با تمام جایگزین‌های نگهداری برای مشکل مورد نظر می‌شود.

مرحله IV : فیلتر و رتبه‌بندی جایگزین‌های نگهداری

اولین اقدام در این مرحله حذف گزینه‌هایی است که برای یک هواپیمای خاص قابل اجرا نیستند. ابزار نمونه اولیه موبایل به‌طور خودکار این گزینه‌ها را با بررسی قابلیت اجرا در فایل‌های متادیتای وظیفه به فرمت JSON حذف می‌کند.

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

زمان موجود

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

در حالی که FAA تأخیر پرواز را در صورتی تعریف می‌کند که 15 دقیقه دیرتر از زمان برنامه‌ریزی شده حرکت کند، ابزار موبایل نمونه اولیه به اپراتور اجازه می‌دهد تا بسته به اهداف عملیاتی آن‌ها ، “تأخیر مجاز” را به‌طور دستی بیشتر یا کمتر از استاندارد 15 دقیقه تنظیم کند. بنابراین، زمان موجود به صورت زیر رسمی می‌شود:

جایی که Ta زمان موجود است، Tstd زمان محلی برنامه‌ریزی شده برای خروج است، Tc زمان محلی فعلی است و Tad زمان تأخیر مجاز است.

زمان مورد نیاز

 زمان مورد نیاز برای فرآیند ارزیابی دیسپچ، مجموع زمان مورد نیاز برای اتخاذ تصمیم و زمان مورد نیاز برای انجام وظیفه نگهداری بعدی است:

جایی که Tr زمان کل مورد نیاز برای دیسپچ هواپیما است، Tdt زمان تصمیم‌گیری و Tmtt زمان وظیفه نگهداری است.

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

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

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

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

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

مرحله V :ارائه نمای کلی از نتایج جایگزین-دیسپچ

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

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

هنگامی که یک مسئله در سمت چپ انتخاب می‌شود، سمت راست “جزئیات نقص” مانند تاریخ ایجاد گزارش و مرحله پرواز زمانی که مسئله رخ داده است را نمایش می‌دهد. “اقدامات دیسپچ” موجود نیز نمایش داده می‌شود، که گزینه‌های دیسپچ را لیست می‌کند. هنگامی که یکی از این گزینه‌ها انتخاب می‌شود، “نتیجه دیسپچ مورد انتظار” در سمت راست نمایش داده می‌شود.

مرحله VI . اعلام و ذخیره تصمیم

 اعلام تصمیم به سایر ذینفعان و ذخیره تصمیم با متغیرهای مرتبط برای مراجعه بعدی در حال حاضر در ابزار موبایلی نمونه اولیه پیاده‌سازی نشده است.

۴. نتایج: کاربرد و ارزیابی دستاورد

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

4.1. ارزیابی بازیابی اطلاعات

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

• تنظیمات آزمایشی: یک آزمایش تنظیم شده است که در آن از مجموعه ای از کارآموزان تکنسین نگهداری هواپیما (AMT) (N = 17) درخواست شده تا مجموعه‌ای از شش مورد مشکل را که شامل شناسایی و بازیابی مستندات وظیفه‌محور است، با استفاده از دو حالت بازیابی انجام دهند. بنابراین، آزمایش یک مطالعه اندازه‌گیری تکراری درون‌موضوعی است، با مجموع 204 (17 × 6 × 2) مشاهده. شرکت‌کنندگان قبل از شروع آزمایش آموزش دیده‌اند تا از هر دو حالت بازیابی استفاده کنند. برای جلوگیری از اثرات یادگیری در طول آزمایش، ترتیب موارد مشکل و حالت‌های جستجو به صورت تصادفی انتخاب شده‌اند. کارآموزان در مرحله پیشرفته‌ای از آموزش خود هستند؛ همراه با انتخاب دقیق موارد مشکل، اطمینان حاصل شد که عملکرد آن‌ها با آنچه از تکنسین‌های مجرب انتظار می‌رود قابل مقایسه باشد. شش مورد مشکل تعریف شد: هر مورد شامل توضیح مختصری از یک مشاهده نگهداری بود که با پردازش صحیح، منجر به یک وظیفه نگهداری خاص و منحصر به فرد همان‌طور که در دفترچه نگهداری هواپیما (AMM) مشاهده شده است می‌شود. برای حفظ پیچیدگی مطابق با آنچه در محیط‌های عملیاتی در دسترس است، فصل ATA (که یک سیستم هواپیما خاص را توصیف می‌کند) به عنوان بخشی از اطلاعات مورد در دسترس قرار گرفت. از تکنسین‌ها خواسته شد تا از دو حالت بازیابی اطلاعات استفاده کنند: 1) انجام جستجوی یک نسخه PDF از فصل AMM، که نمایانگر عملیات‌های روزمره در نگهداری خطی در بسیاری از تنظیمات است؛ 2) انجام جستجوی دستی با استفاده از نسخه ساده‌شده‌ای از نمونه اولیه (که مراحلی مانند پردازش گزارش نقص، تولید جایگزین و ارزیابی از نمونه اولیه حذف شده بود). نسخه ساده‌شده نمونه اولیه از الگوریتم Best-Matching 25 (BM25) برای تعیین مرتبط بودن مستندات با توجه به جستجوی کاربر استفاده می‌کند. نمونه اولیه ۲۰ نتیجه برتر را به مشتری بازمی‌گرداند. توجه داشته باشید که این تنظیم متفاوت از ارزیابی دیسپچ توصیف‌شده است: در آنجا، اطلاعات بسیار خاص‌تری از گزارش‌های نقص موجود است تا وظایف نگهداری مرتبط را به‌طور مستقیم بازیابی کند. بنابراین، زمان لازم برای بازیابی اطلاعات یک برآورد محافظه‌کارانه است که این آزمایش را با کاربرد نمونه اولیه برای ارزیابی دیسپچ در یک محیط عملیاتی واقعی مقایسه می‌کند (به بخش 2 نیز مراجعه کنید). آزمایش در یک محیط کلاس درس بر روی یک لپ‌تاپ یا کامپیوتر دسکتاپ انجام شده است، و بنابراین تکنسین‌های کارآموز عوامل انسانی مرتبط با محیط عملیاتی معمول را تجربه نکرده‌اند. زمان‌ها به‌طور دستی برای روش جستجوی PDF با استفاده از یک تایمر مشاهده و ثبت شدند و به‌طور خودکار برای روش جستجوی نمونه اولیه با استفاده از ضبط زمان سیستم ثبت شدند.
• نتایج ارزیابی: آزمایش با استفاده از چندین شاخص عملکرد اندازه‌گیری شده است. برای هر حالت بازیابی اطلاعات، تعداد مشاهداتی که نتیجه صحیح را به دست آورده‌اند (یعنی یافتن سند صحیح بر اساس توضیحات مورد مشکل) به عنوان یک معیار تقریبی کیفیت شمارش شده‌اند. برای حالت بازیابی نمونه اولیه، تعداد تکرارهای هر مشاهده برای یافتن نتیجه صحیح ردیابی شده است: از آنجایی که نمونه اولیه اجازه مرور بین ۲۰ نتیجه برتر رتبه‌بندی‌شده را می‌دهد، ممکن است کاربر برای شناسایی نتیجه صحیح در لیست رتبه‌بندی به بیش از یک تکرار نیاز داشته باشد. در نهایت، میانگین زمان مورد نیاز برای یافتن سند صحیح به ثانیه ثبت شده است. نتایج تجمیعی آزمایش در جدول ۲ نشان داده شده است. اولین شاخص (تکنسین‌های نگهداری که سند صحیح را یافته‌اند) تفاوت کمی بین حالت‌های بازیابی PDF و نمونه اولیه را به نفع حالت دوم نشان می‌دهد؛ در حالی که نمی‌توان نتیجه‌گیری قطعی انجام داد، این یک نشانه قوی است که کیفیت بازیابی تحت تأثیر منفی روش جدید جستجو با استفاده از نمونه اولیه قرار نگرفته است. در بیشتر موارد، تکنسین‌های نگهداری نیز قادرند با یک تلاش به سند صحیح دست یابند. در نهایت، میانگین زمان مورد نیاز برای یافتن سند مناسب به‌طور قابل‌توجهی کاهش یافته است، که معادل ۷۳٪ کاهش است. شایان ذکر است که این کاهش زمان شامل زمان اضافی که با داشتن قابلیت جستجو در محل صرفه‌جویی می‌شود، نمی‌شود، که این امر زمان لازم برای دسترسی فیزیکی به مستندات را حذف می‌کند.

جدول ۲. نتایج تجمیعی آزمایش بازیابی اطلاعات.

4.2. کاربرد و برآورد ارزیابی دیسپچ در شرایط واقعی

 ارزیابی نمونه اولیه در تأسیسات نگهداری TAP Air Portugal در لیسبون انجام شد. یک سناریوی نگهداری از گزارش یک مشکل غیرمنتظره از طریق دفترچه الکترونیکی (ELB) تا تکمیل وظایف نگهداری اصلاحی اجرا می‌شود.

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

با توجه به این الزامات، مسئله‌ای با سوپاپ ضد یخ بال (WAIV) در یک ایرباس A321–211 به عنوان مطالعه موردی انتخاب شد. ایرباس A321–211 دو WAIV دارد، یکی در هر بال، و بخشی از سیستم ضد یخ هستند.  WAIV در سمت راست ممکن است با سوپاپ در موقعیت باز یا بسته غیرعملیاتی باشد که منجر به تأثیرات عملیاتی مختلف می‌شود.

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

• تنظیمات آزمایشی: برای ارزیابی نمونه اولیه در یک محیط عملیاتی واقعی، یک سناریوی نمایشی تنظیم شده است که ۵ بار شبیه‌سازی و ارزیابی شده است، که شامل مجموعه‌ای از سه تکنسین نگهداری است که نماینده سه ذینفع اصلی (تکنسین، TS و MCC) هستند. در مطالعه موردی، خلبان یک هشدار “WING ANTI ICE R VALVE OPEN” را بر روی نمایشگر مرکزی الکترونیکی هواپیما (ECAM) گزارش می‌دهد که نشان‌دهنده مشکل در WAIV سمت راست هواپیما است. هنگامی که یک نقص در دفترچه الکترونیکی ایجاد می‌شود (یعنی نسخه دیجیتالی دفترچه فنی هواپیما) آن به یک سرور زمینی کپی شده و توسط نمونه اولیه بازیابی می‌شود. بر اساس اطلاعات نقص، نمونه اولیه به‌طور خودکار AMM، TSM و MEL را برای شناسایی گزینه‌های نگهداری مشورت می‌کند و سپس آن‌ها را فیلتر و رتبه‌بندی می‌کند، مطابق با مراحل توضیح داده شده در بخش 3. در این مرحله، تکنسین می‌تواند فرآیند ارزیابی دیسپچ را آغاز کند.

هر شبیه‌سازی منجر به مجموعه‌ای از جایگزین‌های دیسپچ (معمولاً شامل ۳ تا ۵ گزینه قابل اجرا، بسته به شرایط اولیه که عمدتاً به زمان موجود بر اساس برنامه پرواز بستگی دارد) می‌شود که به ترتیب بر اساس معیار زمانی رتبه‌بندی می‌شوند.

برای توضیح این موضوع، شکل 5 نتیجه دیسپچ مورد انتظار برای یک گزینه تعویق انتخاب شده “غیرفعال‌سازی سوپاپ کنترل ضد یخ بال راست به موقعیت باز” را نشان می‌دهد. نتیجه دیسپچ مورد انتظار بر اساس تفاوت بین زمان موجود (معادله ۱) و زمان مورد نیاز (معادله ۲) است و به سه دسته تقسیم می‌شود:

1. GO-IF(P/O/M) بدون تأخیر مورد انتظار، با رنگ سبز نشان داده شده است؛ Tr ≤ Ta با Tad = ۰.
2. GO-IF(P/O/M) با تأخیر قابل قبول مورد انتظار، با رنگ زرد نشان داده شده است؛ Tr ≤ Ta.
3. NO GO، لغو پرواز یا تعویض هواپیما، با رنگ قرمز نشان داده شده است؛ Tr > Ta.

• نتایج ارزیابی: با خودکارسازی شناسایی و ارزیابی جایگزین‌های دیسپچ و ارائه پشتیبانی تصمیم‌گیری به تکنسین بر روی پلتفرم، زمان تصمیم‌گیری می‌تواند به طور قابل توجهی کاهش یابد. تمام تکنسین‌های شرکت‌کننده در شبیه‌سازی و ارزیابی مشاهده و مصاحبه شدند. از آنجایی که شبیه‌سازی در یک محیط عملیاتی واقعی انجام شد، امکان کافی برای 1) ثبت یک خط مبنای دقیق برای فرآیندهای روزمره کنونی و 2) جمع‌آوری نمونه‌ای بزرگ‌تر از اندازه‌گیری‌ها برای تحلیل آماری معنادار نتایج وجود نداشت. از دیدگاه کیفی، مشاهدات و مصاحبه‌ها نشان داد که ابزار موبایلی نمونه اولیه می‌تواند زمان تصمیم‌گیری را تا 98٪ کاهش دهد (یعنی از میانگین ۱۵ دقیقه برای هر فرآیند ارزیابی دیسپچ به ۱۵ ثانیه). توجه داشته باشید که بخش عمده‌ای از این کاهش زمان می‌تواند به بازیابی اطلاعات خودکار از مستندات اختصاص یابد (مطابق با کاربرد آزمایشی که قبلاً توضیح داده شد)، اما این باید به صرفه‌جویی‌های اضافی از یکپارچه‌سازی فرآیند ارزیابی دیسپچ انتها به انتها گسترش یابد. با توجه به تعداد کم اجراها، توزیع دقیق صرفه‌جویی‌ها قابل تعیین نبود. مزایای کیفی شامل توانایی در نظر گرفتن و مقایسه بیشتر جایگزین‌های دیسپچ، اشتراک یک منبع اطلاعاتی ثابت بین ذینفعان و بهبود دسترسی به مستندات نگهداری است.

5. نتایج و توصیه‌ ها

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

مصنوعات معرفی شده چندین مسئله شناسایی شده در ادبیات را با

1) ارائه پشتیبانی تصمیم‌گیری برای یک فرآیند عملیاتی خاص در نگهداری؛

2) اعمال و ارزیابی نمونه اولیه از طریق دو مطالعه موردی در تنظیمات آزمایشی و عملیاتی واقعی؛ و

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

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

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

برای دیدن چگونگی دستیابی به این موضوع، ارزش دارد که جایگزین‌های خاص هواپیما در چارچوب ارائه شده در شکل ۲ با سایر دارایی‌های پیچیده جایگزین شوند، جایی که شباهت‌هایی در ثبت نقص‌ها، بازیابی اطلاعات از مستندات پیچیده و استفاده از معیارهایی مانند ایمنی، زمان، تأثیر عملیاتی (هزینه) و/یا مکان برای اطلاع‌رسانی به تصمیم‌گیری‌های بعدی وجود دارد.

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

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

1) می‌تواند برای ارزیابی نتیجه مورد انتظار دیسپچ با نتیجه واقعی استفاده شود و

2) سپس این اطلاعات می‌تواند برای پیاده‌سازی روش‌های یادگیری ماشین در مرحله IV مدل فرآیند به منظور بهبود ارزیابی و رتبه‌بندی جایگزین‌ها استفاده شود، که به طور بالقوه پشتیبانی تصمیم‌گیری مؤثرتری ارائه می‌دهد. ثانیاً، پایگاه داده حاوی داده‌های ارزیابی معیارها می‌تواند با منابع اضافی (مانند اطلاعات مکان یا موجودی) گسترش یابد تا بتوان جایگزین‌ها را با استفاده از معیارهای اضافی و روش‌های تصمیم‌گیری چندمعیاره (MCDM) رسمی ارزیابی کرد.

منبع