1 điểm bởi GN⁺ 2025-11-29 | 1 bình luận | Chia sẻ qua WhatsApp
  • Kết quả phân tích các sự cố gần đây trên dòng máy bay A320 Family cho thấy bức xạ mặt trời mạnh có thể làm hỏng dữ liệu cốt lõi cần thiết cho điều khiển bay
  • Theo đó, Airbus đã xác định nhiều máy bay thuộc dòng A320 hiện đang khai thác có thể bị ảnh hưởng
  • Công ty đã phối hợp với cơ quan hàng không để phát hành Alert Operators Transmission(AOT) nhằm triển khai ngay các biện pháp phòng ngừa, và nội dung này dự kiến sẽ được phản ánh trong Emergency Airworthiness Directive của EASA
  • Airbus thừa nhận các biện pháp này có thể gây gián đoạn lịch khai thác của hành khách và khách hàng, và hiện đang phối hợp chặt chẽ với các hãng khai thác để ứng phó
  • Ưu tiên cao nhất của mọi biện pháp là đảm bảo an toàn hàng không

Tổng quan về biện pháp phòng ngừa đối với A320 Family

  • Phân tích các sự cố gần đây liên quan đến dòng máy bay A320 Family cho thấy bức xạ mặt trời mạnh (intense solar radiation) có thể làm hỏng dữ liệu cốt lõi của hệ thống điều khiển bay
    • Hiện tượng này có thể ảnh hưởng đến tính toàn vẹn của dữ liệu cần thiết cho chức năng điều khiển bay (flight controls)
  • Airbus đánh giá rằng một tỷ lệ đáng kể máy bay thuộc dòng A320 đang khai thác hiện nay có thể bị ảnh hưởng bởi vấn đề này

Biện pháp phòng ngừa và phối hợp với cơ quan chức năng

  • Airbus đã phối hợp với cơ quan hàng không để phát hành Alert Operators Transmission(AOT) nhằm triển khai ngay các biện pháp phòng ngừa
    • AOT bao gồm hướng dẫn áp dụng các biện pháp bảo vệ bằng phần mềm và/hoặc phần cứng để bảo đảm khai thác an toàn cho máy bay
    • Biện pháp này dự kiến sẽ được chính thức phản ánh trong Emergency Airworthiness Directive của Cơ quan An toàn Hàng không Liên minh châu Âu (EASA)

Ảnh hưởng đến khai thác và ứng phó

  • Airbus thừa nhận rằng các biện pháp lần này có thể gây ra một số chậm trễ hoặc gián đoạn trong lịch khai thác của hành khách và khách hàng
  • Công ty sẽ phối hợp chặt chẽ với các hãng khai thác để hỗ trợ triển khai biện pháp, đồng thời duy trì việc bảo đảm an toàn là ưu tiên hàng đầu
  • Airbus bày tỏ lời xin lỗi vì những bất tiện đã gây ra

Tài liệu liên quan

  • Có cung cấp tài liệu PDF (126.02 KB) với nội dung giống thông cáo báo chí
    • Tiêu đề tài liệu: Airbus update on A320 Family precautionary fleet action
    • Liên kết tải xuống được đăng trên trang chính thức

1 bình luận

 
GN⁺ 2025-11-29
Ý kiến Hacker News
  • Tôi thật sự rất muốn biết vấn đề này được phát hiện trên dòng vi điều khiển nào
    Nếu đây là một safety processor dùng lockstep, ECC, v.v. thì điều đó có nghĩa là đã xảy ra hiện tượng lật bit ở mức mà ECC cũng không phát hiện được
    Nếu là hỏng dữ liệu thì có thể không chỉ là khởi động lại đơn thuần, mà là tình huống nhiều bit trong cùng một word bị lật cùng lúc
    Nếu môi trường không khác biệt đặc biệt, cũng có thể họ đã giảm thứ gì đó như biên độ điện áp
    Tôi cũng muốn biết đó là NVM hay SRAM

    • Như đã được nhắc ở thread khác, hệ thống đó không có EDAC
      Đó không phải MCU mà là một hệ thống gồm nhiều chip, được thiết kế từ thập niên 90 và mãi đến năm 2002 mới có phiên bản phần cứng mới bổ sung EDAC
      Trong tình huống như vậy thì chuyện lật bit hoàn toàn có thể xảy ra
      Chi tiết có trong báo cáo ATSB
    • Các bản revision đầu của Raspberry Pi 2 từng bị crash khi gặp ánh sáng mạnh như đèn flash máy ảnh
      Đặc biệt, flash xenon là vấn đề lớn
      Có thể xem các trường hợp liên quan tại bài viết trên diễn đàn, thảo luận thêm, blog chính thức, video YouTube
    • Biện pháp ứng phó SEU (single-event upset) đúng nghĩa thì chỉ ECC là không đủ
      Vệ tinh hoạt động ở độ cao lớn hơn A320 rất nhiều, và phần lớn dùng Triple Modular Redundancy
      Tham khảo giải thích về TMR, khái niệm SEU
      NASA tăng N lên 5 trong các chuyến bay có người lái
      Cũng có các cách như tắt hoàn toàn cache hoặc liên tục refresh ECC RAM
      Ngoài ra còn có các biện pháp phần cứng để ngăn latch-up trong mạch số
    • Tôi thấy đáng lo khi họ cố giải quyết vấn đề phần cứng bằng bản vá phần mềm
  • Làm trong ngành máy tính đủ lâu thì bạn sẽ thấy những sự cố lật bit như thế này nhiều lần
    ECC cứu được phần lớn trường hợp, nhưng đôi khi phần mềm cũng được thiết kế để phát hiện và bỏ qua các giá trị bất thường
    Trong các hệ thống thời gian thực hoặc an toàn trọng yếu, nhiều hệ thống còn bỏ phiếu để xác minh lỗi
    Hồi thập niên 90 tôi từng khổ sở hàng tháng vì một vụ lật bit ở cache line của CPU

    • Chúng tôi cũng từng thấy hiện tượng này trong log
      Ở một dịch vụ xử lý lưu lượng rất lớn, chúng tôi tổng hợp các giá trị dạng enum và phát hiện vài giá trị không thể xảy ra
      Khi thấy chuỗi bị ghi sai mà chỉ lệch đúng một bit, chúng tôi đoán nguyên nhân có thể là do tia vũ trụ (cosmic ray)
    • Tôi từng có một đồng nghiệp cũ luôn đổ nguyên nhân sự cố cho neutrino
      Thực tế đó là một bug có thể tái hiện được, nhưng phải sau khi nghi ngờ đủ thứ từ kernel, driver đến client thì anh ta mới thừa nhận lỗi của mình
      Dù vậy anh ấy vẫn là thiên tài, và biết đâu trong vụ A320 lần này thì thật sự anh ấy đã đúng
  • The Aviation Herald có thêm chi tiết kỹ thuật hơn

    • Câu này đặc biệt đáng lo
      “Trong trường hợp xấu nhất, lỗ hổng này có thể gây ra chuyển động elevator không được điều khiển, dẫn đến vượt quá giới hạn kết cấu của máy bay”
  • Ngành hàng không vũ trụ từ lâu đã có các biện pháp đối phó lật bit
    Bản sửa lần này của Airbus/Thales là tăng cường kiểm tra lỗi và tự động khởi động lại component gặp vấn đề
    Chi tiết có trong báo cáo BEA

  • Có cảm giác rất kiểu BoFH
    “Sáng sớm thứ Sáu đi làm thì điện thoại reo. Lật qua tờ giấy biện hộ thì thấy ‘solar flare’ đang nhìn mình...”

    • Trong BoFH Excuse Generator, Solar Flares lúc nào cũng buồn cười nhất
      liên kết
    • Solar flare là cái cớ tuyệt nhất. Chỉ cần đợi một lúc là được
  • Tôi tò mò không biết vụ này đã được chẩn đoán như thế nào
    Tôi không rõ FDR (thiết bị ghi dữ liệu chuyến bay) có ghi cả lỗi mức thấp hay chỉ lưu các giá trị đầu vào mức cao
    Nếu là lật bit do bức xạ thì họ đã phát hiện ra điều đó bằng cách nào?
    Tôi cũng tự hỏi liệu có ghi lại kiểu lỗi bỏ phiếu giữa các máy tính bay chính hay không

  • Có một báo cáo phân tích sau sự cố rất hay về một trường hợp SEU (single-event upset) tương tự

  • Kiểu phản ứng như câu đùa “bay quá gần Mặt Trời”

  • Tôi tự hỏi liệu có cần đình chỉ khai thác toàn bộ đội bay vì chuyện này hay không
    Nếu là một sự cố duy nhất trong số hàng chục nghìn máy bay suốt nhiều năm, thì có lẽ cho thời hạn khoảng hai tháng để sửa cũng là đủ chứ?

    • Thực ra không phải trong nhiều năm, mà chỉ phiên bản firmware ELAC mới nhất mới bị ảnh hưởng
      Cách xử lý là hạ cấp hoặc thay bằng phần cứng phiên bản trước
    • Chi phí có lẽ sẽ do hãng hàng không gánh
      Với Airbus thì thiệt hại trực tiếp do dừng khai thác có thể không lớn, nhưng nếu xảy ra tai nạn thì rủi ro về danh tiếng và kiện tụng sẽ lớn hơn nhiều
    • Cần nhấn mạnh rằng “đây là Airbus chứ không phải Boeing”
    • Thậm chí với Airbus, chuyện này có thể còn có hiệu ứng marketing
      Kiểu như: “Chúng tôi chủ động xử lý trước, còn đối thủ chỉ hành động sau khi tai nạn xảy ra”
    • Cá nhân tôi thì sẽ không muốn lên chiếc máy bay đó trong hai tháng ấy
  • Theo báo chí, biện pháp lần này là rollback bản cập nhật phần mềm
    Tôi tò mò mục đích ban đầu của bản cập nhật đó là gì, và phần mềm máy tính bay được cập nhật thường xuyên đến mức nào