وقتی یک خط کد، بوئینگ را دوباره به دردسر انداخت
به گزارش خبرنگار تابناک، ماجرای تازه بوئینگ ۷۳۷ مکس این‌بار نه به موتور مربوط است، نه بدنه و نه یک قطعه مکانیکی؛ مشکل از جایی آمده که برای مسافر قابل مشاهده نیست اما در مدیریت پرواز نقش مهمی دارد. سازمان هوانوردی فدرال آمریکا، FAA، در روزهای اخیر بررسی یک ایراد نرم‌افزاری در رایانه مدیریت پرواز برخی نسخه‌های ۷۳۷ را جدی‌تر کرد؛ ایرادی که می‌تواند در یک وضعیت مشخص پس از اجرای Go-Around یا لغو فرود، باعث قطع شدن حالت ناوبری عمودی یا VNAV شود. هیئت بررسی اقدام اصلاحی FAA پس از بررسی موضوع اعلام کرده که این نقص، خطر ایمنی غیرقابل قبول ایجاد نمی‌کند، چون خلبان همچنان کنترل کامل هواپیما را در اختیار دارد و علائم کابین نیز برای خدمه روشن و قابل تشخیص هستند. همین تصمیم مسیر صدور گواهینامه ۷۳۷ مکس ۱۰ را دوباره باز کرد، اما پرونده از نظر فنی همچنان قابل توجه است؛ چون این بار یک خطای نرم‌افزاری نشان داده که در هواپیمای مسافربری مدرن، «کار نکردن یک قابلیت اتوماتیک» با «از دست رفتن کنترل هواپیما» یکی نیست، ولی فاصله میان این دو مفهوم می‌تواند در یکی از حساس‌ترین مراحل پرواز بسیار مهم باشد.
مشکل دقیقاً کجاست؟
برای فهم این ماجرا باید از خود VNAV شروع کرد. در هواپیماهای مدرن، Flight Management System یا FMS عملاً مغز محاسباتی مسیر پرواز است؛ سامانه‌ای که اطلاعات مسیر، محدودیت‌های ارتفاعی، سرعت، عملکرد هواپیما، داده‌های ناوبری و انتخاب‌های خلبان را کنار هم قرار می‌دهد و بر اساس آنها محاسبات لازم برای اجرای مسیر را انجام می‌دهد. VNAV یکی از قابلیت‌های مهم این مجموعه است و به هواپیما اجازه می‌دهد بخش عمودی مسیر را بر اساس برنامه پروازی و محدودیت‌های تعریف‌شده مدیریت کند. خلبان همچنان فرمانده هواپیماست، اما اتوماسیون می‌تواند حجم قابل توجهی از محاسبات و کنترل مسیر را انجام دهد.
ایراد مورد بحث به نسخه‌های U14.0 و U14.1 نرم‌افزار Flight Management Computer مربوط می‌شود. سناریوی مورد توجه FAA نیز کاملاً مشخص است: هواپیما پس از یک Go-Around وارد وضعیت جدیدی شود و خدمه تصمیم بگیرند مستقیماً به یک Waypoint هدایت شوند که در مسیر Approach یا بخش انتقالی همان تقرب قرار ندارد. در این حالت، ممکن است حالت VNAV از مدار خارج شود. این به معنی خاموش شدن موتور، از دست رفتن کنترل هواپیما یا ناتوانی خلبان در ادامه پرواز نیست؛ مسئله این است که یکی از قابلیت‌های اتوماسیون که خدمه انتظار دارند در اختیارشان باشد، دیگر فعال باقی نمی‌ماند و خلبان باید وضعیت پرواز را با روش دیگری مدیریت کند. FAA در بررسی خود به این جمع‌بندی رسیده که چون خدمه همچنان کنترل کامل هواپیما را دارند و نمایشگرها وضعیت را به شکل واضح اعلام می‌کنند، این ایراد در سطح یک وضعیت ناایمن قرار نمی‌گیرد.
اهمیت قضیه از جایی بیشتر می‌شود که مشخص شده این موضوع فقط به ۷۳۷ مکس محدود نیست. بولتن اطلاعاتی FAA در تاریخ ۳ اکتبر ۲۰۲۶ دامنه بررسی را به خانواده ۷۳۷ نسل قبلی، یعنی ۷۳۷-۶۰۰، ۷۰۰، ۸۰۰، ۹۰۰ و ۹۰۰ER نیز تعمیم داده است؛ البته فقط هواپیماهایی که همین نسخه‌های U14.0 یا U14.1 از نرم‌افزار FMC را دارند. بنابراین یک ۷۳۷-۸۰۰ قدیمی‌تر هم در صورت داشتن نرم‌افزار مربوطه می‌تواند در محدوده همین اطلاعیه قرار بگیرد. FAA این اطلاعیه را الزام به انجام اصلاح اجباری ندانسته و اعلام کرده که فعلاً شرایط لازم برای صدور یک Airworthiness Directive اجباری وجود ندارد.
این نکته برای صنعت هوانوردی اهمیت زیادی دارد. هواپیما را نمی‌توان مثل یک خودرو با این منطق نگاه کرد که اگر یک آپشن نرم‌افزاری از کار افتاد، راننده فقط آن آپشن را کنار بگذارد. هر قابلیت اتوماتیک باید در زنجیره بزرگی از سناریوهای عملیاتی، Human Factors، آموزش خدمه، نمایش اطلاعات و روش‌های اضطراری ارزیابی شود. به همین علت حتی یک خطای نرم‌افزاری که مستقیماً هواپیما را غیرقابل کنترل نمی‌کند، ممکن است ماه‌ها یا سال‌ها درگیر بررسی مهندسی، آزمون، گزارش عملیاتی و تصمیم نهایی نهاد ناظر باشد.
چرا پرونده برای ۷۳۷ مکس ۱۰ حساس شد؟
حساسیت اصلی از خود ایراد نرم‌افزاری بزرگ‌تر است. بوئینگ سال‌هاست درگیر فرایند طولانی اخذ گواهینامه برای ۷۳۷ مکس ۱۰ است؛ هواپیمایی که بزرگ‌ترین عضو خانواده MAX محسوب می‌شود و برای شرکت‌های هواپیمایی در بازار هواپیماهای تک‌راهرو اهمیت بالایی دارد. بوئینگ پیش‌تر اعلام کرده بود که آزمایش‌های پروازی گواهینامه‌ای ۷۳۷-۷ و ۷۳۷-۱۰ تکمیل شده و انتظار دارد هر دو مدل در سال ۲۰۲۶ گواهینامه بگیرند.
به همین علت، ظاهر شدن یک ایراد نرم‌افزاری در مراحل پایانی صدور گواهینامه می‌توانست برنامه ورود مکس ۱۰ به بازار را دوباره عقب بیندازد. FAA هم تا روشن شدن وضعیت موضوع، صدور گواهینامه را متوقف کرده بود. بررسی انجام‌شده در سیاتل و تصمیم هیئت Corrective Action Review Board حالا این مانع را برداشته است. این تصمیم البته به معنی آن نیست که نرم‌افزار بدون تغییر به حال خود رها شده؛ بوئینگ باید دستورالعمل‌های عملیاتی مربوط به شناسایی و مدیریت وضعیت را در اختیار اپراتورها قرار دهد و یک اصلاح دائمی نیز در حال توسعه است.
جالب‌تر اینکه مشکل تازه کشف نشده است. گزارش‌های اولیه درباره این رفتار نرم‌افزاری به نوامبر ۲۰۲۴ بازمی‌گردد؛ زمانی که موضوع در عملیات مرتبط با WestJet مطرح شد. با افزایش گزارش‌ها، بوئینگ موضوع را دوباره بررسی کرد و در سال ۲۰۲۶ آن را به FAA ارجاع داد. یعنی فاصله زمانی میان مشاهده نخستین نشانه‌ها و رسیدن پرونده به مرحله بررسی رسمی نهاد ناظر، تقریباً دو سال بوده است. همین فاصله زمانی نشان می‌دهد چرا در صنعت هوانوردی نمی‌توان هر رفتار غیرعادی نرم‌افزار را فوراً یک «خرابی خطرناک» نامید؛ ابتدا باید شرایط بازتولید شود، احتمال وقوع مشخص شود، اثر آن بر عملیات سنجیده شود و مشخص شود خدمه در صورت وقوع چه میزان کنترل و چه گزینه‌هایی در اختیار دارند.
موضوع دیگری که این پرونده را پیچیده‌تر کرده، سابقه نسخه‌های مختلف نرم‌افزار FMS در ناوگان ۷۳۷ مکس است. گزارش‌های تخصصی صنعت هوانوردی نشان می‌دهد برخی شرکت‌های هواپیمایی آمریکایی نسبت به استفاده از نسخه‌های جدیدتر U14 و U14.1 محتاط بوده‌اند و بعضی اپراتورها ترجیح داده‌اند از نسخه قدیمی‌تر U13 استفاده کنند. حتی درباره برخی رفتارهای نرم‌افزاری دیگر در نسخه‌های جدیدتر نیز نگرانی‌های عملیاتی مطرح شده است. این مسئله یک تناقض جالب ایجاد می‌کند: نرم‌افزار جدید معمولاً برای رفع محدودیت‌ها، اضافه کردن قابلیت‌ها و اصلاح مشکلات قبلی توسعه پیدا می‌کند، اما ممکن است همزمان رفتارهای جدیدی ایجاد کند که اپراتور باید آنها را دوباره ارزیابی کند.
هواپیمای مدرن؛ نرم‌افزار بخشی از ایمنی است
پرونده ۷۳۷ یک واقعیت مهم درباره نسل جدید هواپیماهای مسافربری را دوباره یادآوری می‌کند. در هواپیمای مدرن، ایمنی فقط با ضخامت بدنه، قابلیت موتور یا کیفیت سیستم هیدرولیک تعریف نمی‌شود. میلیون‌ها خط کد، رایانه‌های پروازی، منطق کنترل، نمایشگرها، شبکه‌های داده و الگوریتم‌های مدیریت مسیر نیز بخشی از معماری ایمنی هستند. اما نکته کلیدی در طراحی هواپیما این است که اتوماسیون نباید جای خلبان را بگیرد؛ باید ابزار کنترل و تصمیم‌گیری او باشد.
به همین علت، در ماجرای اخیر FAA روی یک عبارت مشخص تأکید کرده است: خلبان همچنان کنترل کامل هواپیما را دارد. این جمله از نظر مهندسی بسیار مهم‌تر از آن چیزی است که در نگاه اول به نظر می‌رسد. اگر یک قابلیت اتوماتیک از کار بیفتد ولی خدمه بتوانند بلافاصله وضعیت را تشخیص دهند، کنترل دستی را در اختیار بگیرند و پرواز را طبق رویه‌های مصوب ادامه دهند، طبقه‌بندی ایمنی آن با حالتی که هواپیما خودش وارد یک فرمان ناخواسته یا غیرقابل کنترل شود کاملاً متفاوت است.
با این حال، کاهش ریسک به معنی بی‌اهمیت بودن ایراد نیست. در کابین خلبان، زمان و بار کاری اهمیت زیادی دارد. یک نقص نرم‌افزاری در مرحله‌ای آرام از پرواز ممکن است صرفاً یک پیام یا تغییر حالت اتوماسیون باشد، اما همان تغییر در هنگام Go-Around، نزدیک زمین، در هوای نامساعد یا در شرایطی که خدمه همزمان چند وظیفه را مدیریت می‌کنند، اهمیت بیشتری پیدا می‌کند. مهندسی هوانوردی دقیقاً به همین علت به جای پرسش ساده «آیا هواپیما سقوط می‌کند؟» مجموعه بزرگ‌تری از سؤال‌ها را بررسی می‌کند: خلبان چه چیزی می‌بیند؟ چه زمانی متوجه مشکل می‌شود؟ چه مقدار زمان برای واکنش دارد؟ سیستم چه هشداری می‌دهد؟ رویه جایگزین چیست؟ و احتمال خطای انسانی در اثر افزایش بار کاری چقدر است؟
بوئینگ نیز در سال‌های اخیر تحت نظارت شدیدتر FAA قرار داشته است. این نهاد آمریکایی در ژوئیه ۲۰۲۶، پس از ماه‌ها بررسی داده‌های تولید و کیفیت، اجازه داد بوئینگ دوباره صدور گواهینامه صلاحیت پروازی برخی هواپیماهای تازه‌تولید ۷۳۷ مکس و ۷۸۷ را در چارچوب نظارت FAA انجام دهد؛ اختیاری که پس از حوادث و مشکلات کیفیتی سال‌های گذشته محدود شده بود. FAA در همان زمان تأکید کرد که نظارت، بازرسی و پایش کیفیت تولید همچنان ادامه خواهد داشت.
حالا پرونده نرم‌افزاری ۷۳۷ مکس ۱۰ یک درس دیگر برای بوئینگ و حتی کل صنعت هواپیمایی دارد: در هواپیمای امروزی، یک نرم‌افزار جدید فقط یک «آپدیت» نیست. هر تغییر در منطق FMS می‌تواند با عملکرد خلبان، روش‌های عملیاتی، آموزش، کنترل ترافیک هوایی و تجهیزات هواپیما ارتباط پیدا کند و به همین علت مسیر تأیید آن به اندازه یک تغییر سخت‌افزاری جدی است. FAA فعلاً این نقص را خطر ایمنی غیرقابل قبول تشخیص نداده، اما خود فرایند بررسی نشان می‌دهد عصر هواپیماهای دیجیتال، مرز میان مهندسی هوافضا و مهندسی نرم‌افزار را تقریباً از بین برده است.
برای مسافری که روی صندلی ۷۳۷ می‌نشیند، این ماجرا شاید فقط یک خبر تخصصی درباره «U14.1» باشد؛ اما برای صنعت، موضوع بسیار بزرگ‌تر است. هواپیما باید در هر لحظه قابل پیش‌بینی باشد و خدمه باید بدانند هر فرمان، هر هشدار و هر تغییر حالت دقیقاً چه معنایی دارد. وقتی یک کد نرم‌افزاری رفتار متفاوتی نشان می‌دهد، مسئله فقط اصلاح چند خط برنامه نیست؛ پای اعتماد خلبان به اتوماسیون، اعتماد نهاد ناظر به سازنده و اعتماد مسافر به هواپیما وسط است.
