Đường Chiếm Văn dừng lại một chút, đổi giọng nói: "Về phần phần mềm điều khiển bay của tiêm kích JH-7A, tôi nghĩ vẫn nên mời chuyên gia Cao Minh từ Viện 618 đưa ra ý kiến. Bởi vì hệ thống điều khiển bay này là thành quả hợp tác giữa hai viện, ngoại trừ các thuật toán điều khiển, về cơ bản đều do phía họ chủ trì phụ trách."
Lúc này, mọi ánh mắt đều đổ dồn về phía người đàn ông trung niên - chuyên gia điều khiển bay Cao Minh của Viện 618.
Trong quá trình thiết kế và chế tạo tiêm kích JH-7A, Viện 618 đảm nhận phần lớn công việc nghiên cứu và phát triển hệ thống điều khiển bay. Là trung tâm nghiên cứu phát minh về kỹ thuật dẫn đường, chỉ đạo và điều khiển tích hợp thiết kế, phát triển, sản xuất và dịch vụ của Tập đoàn Công nghiệp Hàng không Trung Quốc, viện này bao phủ nhiều lĩnh vực sản xuất và khoa học kỹ thuật quốc phòng. Sản phẩm của họ trải dài từ các linh kiện nhỏ nhất đến toàn bộ hệ thống tổng thể của nhiều loại phương tiện bay.
Dù là nghiên cứu chế tạo hệ thống máy telex cho tiêm kích J-8II, hay phát triển hệ thống điều khiển bay cho tiêm kích J-10, đều có sự góp mặt của họ. Nói cách khác, toàn bộ phần mềm điều khiển bay cho chiến đấu cơ nội địa đều do Viện 618 đảm nhiệm.
Cao Minh là chuyên gia hệ thống phần mềm bay với kinh nghiệm vô cùng phong phú, từng tham gia phát triển hệ thống điều khiển cho nhiều dòng máy bay. Trong dự án JH-7A, ông chính là tổng phụ trách mảng phát triển phần mềm điều khiển bay.
Cao Minh trầm giọng nói: "Thưa các vị lãnh đạo, các chuyên gia, dưới góc độ điều khiển bay, tôi xin đưa ra phân tích về nguyên nhân sự cố trong chuyến bay thử nghiệm lần này. Việc nghiên cứu chế tạo phần cứng và biên soạn mã nguồn phần mềm điều khiển bay đều do viện chúng tôi hoàn thành, cá nhân tôi chịu trách nhiệm tổng thể. Chúng tôi đã tiến hành phân tích nghiêm túc về sự cố này. Về phần mềm điều khiển, như Tổng công trình sư Đường vừa nói, chúng ta đã áp dụng kỹ thuật dung sai, xác suất xảy ra lỗi về cơ bản là không có. Mọi người đều rõ, tỷ lệ lỗi của phần mềm điều khiển bay chỉ rơi vào khoảng một phần mười triệu giờ bay. Nói cách khác, tiêm kích JH-7A của chúng ta phải tích lũy đủ mười triệu giờ bay mới có khả năng xuất hiện một lỗi, mọi người hãy nghĩ xem, điều này gần như là không thể xảy ra."
"Hơn nữa, bộ phần mềm này dù do viện chúng tôi biên soạn, nhưng cũng đã được Viện Thiết kế máy bay kiểm tra, sau đó cùng nhau lắp đặt thử nghiệm. Tại hội nghị thẩm định lúc đó, hội đồng chuyên gia cũng đã đánh giá rất cao. Vì vậy, khả năng phần mềm điều khiển bay có khiếm khuyết là không thể xảy ra. Kết quả phân tích đối chiếu về độ tin cậy của hệ thống giữa hai viện cho thấy, hệ thống này vận hành rất tốt. Chúng ta đã đột phá được một loạt kỹ thuật then chốt như: cấu hình dư thừa, thuật toán đồng bộ, chia sẻ thông tin giữa các kênh dư thừa, tương thích điện từ, cách ly lỗi và tái cấu trúc hệ thống, cùng các bài kiểm tra tự động nội bộ. Vì vậy, việc máy bay mất kiểm soát tư thế lần này, chúng tôi cho rằng không liên quan đến hệ thống điều khiển bay, mà nên tìm nguyên nhân từ các yếu tố bên ngoài." Cao Minh nói xong liền không giải thích thêm.
Lúc này, hội nghị rơi vào bế tắc. Nếu hệ thống điều khiển bay không có vấn đề, thao tác của phi công cũng không sai sót, vậy thì vấn đề nằm ở đâu?
Buổi họp phân tích sự cố hôm nay, e rằng khó mà đưa ra được kết quả.
Chỉ có Lâm Bằng mới biết, nguyên nhân thực sự của sự cố chính là một lỗi ẩn trong mã nguồn phần mềm.
Nhưng là người có tư lịch thấp nhất trong phòng họp, anh không thể đứng lên nói được. Hơn nữa, dù có nói ra, e rằng cũng chẳng ai tin. Quan trọng hơn, các chuyên gia của Viện 618 đã khẳng định phần mềm không có vấn đề, nếu anh đứng lên phản bác, chẳng khác nào vả vào mặt người khác. Tất nhiên, đó cũng là vả vào mặt Viện 603, Viện Thiết kế máy bay và cả Tổng công trình sư Đường!
Thế nhưng, làm sao để giải quyết vấn đề này đây?
Lâm Bằng rơi vào thế khó xử. Làm thế nào để mọi người nhận ra vấn đề và khắc phục nó mà không làm tổn hại đến hòa khí, thể diện, lại càng không thể để lộ việc anh biết về lỗi trong mã nguồn phần mềm?
Lâm Bằng thực sự đang ở trong tình thế tiến thoái lưỡng nan.
Lúc này, các chuyên gia trong phòng họp cũng đang nghị luận xôn xao, thì thầm to nhỏ. Ai cũng hiểu, khi xảy ra vấn đề lớn như vậy, chẳng ai muốn trách nhiệm đổ lên đầu mình.
Tổng công trình sư Đường Chiếm Văn cũng không biết nên nói gì, bởi phần mềm điều khiển bay đúng là sản phẩm hợp tác của hai bên, dù thiết bị và mã nguồn chủ yếu do Viện 618 chủ đạo, Viện 603 chỉ phụ trách các luật điều khiển bay.
Hệ thống điều khiển bay này đã trải qua các bài kiểm tra nghiêm ngặt, khi đó kết quả rất khả quan, hội đồng chuyên gia nhất trí cho rằng nó đã đạt trình độ dẫn đầu trong nước.
Thậm chí, việc mã hóa phần mềm cũng đã được tổ chức chuyên gia thẩm định. Các bài kiểm tra mô-đun, kiểm tra tổng hợp và kiểm tra tổng thể phần cứng - phần mềm của hệ thống này đều cho kết quả rất tốt.
Điểm thiếu sót duy nhất có lẽ là việc chưa tiến hành thử nghiệm trên giàn mô phỏng hệ thống điều khiển (Iron Bird), bởi lẽ vào thời điểm đó, chúng ta không có đủ điều kiện để xây dựng thiết bị này. Tại quốc nội, giàn mô phỏng vẫn là một rào cản kỹ thuật khó vượt qua; phải đến khi Viện nghiên cứu 611 phát triển dòng tiêm kích thế hệ thứ ba như J-10, họ mới dần dần mày mò và chế tạo thành công.
Tuy nhiên, dù không có giàn mô phỏng, các bài kiểm tra tổng hợp và thử nghiệm bay thực tế đã chứng minh hệ thống điều khiển bay số hóa ba trục dự phòng này vẫn vô cùng đáng tin cậy.
Thế nhưng, nếu vấn đề không nằm ở hệ thống điều khiển bay, vậy nguyên nhân gây ra sự cố lần này là gì? Chẳng lẽ lại để sự việc rơi vào bế tắc không lời giải đáp? Điều này chắc chắn không được phép, và cũng không thể vượt qua sự kiểm duyệt gắt gao từ cấp trên.
Đúng lúc này, Đường Chiếm Văn bỗng cảm thấy điện thoại trong túi rung lên vài nhịp. Khi đang họp, anh đã chủ động chuyển máy sang chế độ im lặng.
Đường Chiếm Văn thầm nghĩ, giờ này ai lại nhắn tin cho mình? Anh lấy điện thoại ra xem, người gửi tin nhắn chính là Lâm Bằng.
Khi đọc nội dung tin nhắn, anh không khỏi chấn động.
Nội dung Lâm Bằng gửi rất ngắn gọn, chỉ đề cập đến hai từ khóa: "ưu tiên" và "đảo ngược", cùng với sự kiện tàu thăm dò Hỏa tinh của Mỹ năm 1997.
Nhìn thấy gợi ý này từ Lâm Bằng, Tổng sư Đường Chiếm Văn cảm thấy trong đầu như có tiếng ong vang lên. Dường như anh đã tìm ra điểm mấu chốt! Tuy nhiên, đây mới chỉ là phỏng đoán của Lâm Bằng, việc nó có chính xác hay không không thể chỉ dựa vào suy luận hay lời nói suông để chứng minh.
Dù thế nào đi nữa, cuộc họp phân tích sự cố hôm nay bắt buộc phải có kết quả. Vì vậy, Đường Chiếm Văn quyết định dù có phải đánh đổi thể diện cũng phải nói ra. Với tư cách là Tổng sư, anh hiểu rất rõ về hệ thống điều khiển bay. Mặc dù không trực tiếp biên soạn mã nguồn, nhưng anh nắm vững nguyên lý cơ bản và cấu trúc vận hành của nó.
Vậy sự kiện tàu thăm dò Hỏa tinh năm 1997 là thế nào? Năm đó, sau khi tàu thăm dò Hỏa tinh của Mỹ hạ cánh xuống bề mặt hành tinh đỏ được mười ngày, nó bắt đầu có biểu hiện bất thường. Thiết bị liên tục khởi động lại một cách vô quy luật, mỗi lần khởi động đều gây ra tình trạng mất dữ liệu.
Khi ấy, NASA giải thích rằng máy tính trên tàu thăm dò đã cố gắng thực hiện quá nhiều tác vụ cùng lúc, dẫn đến xung đột hệ thống.
Tại cuộc họp phân tích thời điểm đó, công ty phát triển phần mềm điều khiển tự động cho tàu thăm dò đã đưa ra một cách giải thích rất đáng chú ý: đó là sự "đảo ngược ưu tiên".
Nhiệm vụ khí tượng của tàu thăm dò Hỏa tinh vốn là một tác vụ có mức ưu tiên thấp. Trong quá trình viết mã cho bus dữ liệu, một ngắt quãng phát sinh khiến tác vụ truyền tin bị điều phối không ổn thỏa. Cuối cùng, do tác vụ truyền tin vận hành quá thời gian cho phép, tác vụ quản lý bus dữ liệu bị quá hạn (timeout) và phản hồi lỗi. Kết quả dẫn đến việc hệ thống buộc phải khởi động lại.