Phân hệ PM Study
  • Tình huốngTình huống thực chiến
  • Kịch bảnRa quyết định tình huống
  • Biểu mẫuKho biểu mẫu tải về
  • Thẻ ghi nhớHọc thuật ngữ PMP
  • Công cụMáy tính EVM, PERT, dự phòng
  • Hỏi đápHỏi đáp & thảo luận
  • Thử tháchMỗi ngày một câu hỏi PMP
  • Lý thuyếtBài học PMBOK 8 & ECO 2026
  • Luyện thiThi thử & ôn tập PMP
  • Bài viếtThư viện bài viết PMP
PM Study
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đáp
6 chuyên mụcXem tất cả bài viết →
  • Quản lý các bên liên quanTình huống về kỳ vọng, giao tiếp và gắn kết stakeholder.
  • Lãnh đạo & đội nhómXây dựng, dẫn dắt và giải quyết xung đột trong đội dự án.
  • Kế hoạch & tiến độLập kế hoạch, ước lượng, nén tiến độ và kiểm soát baseline.
  • Rủi ro & thay đổiNhận diện, ứng phó rủi ro và kiểm soát thay đổi phạm vi.
  • Agile & HybridLựa chọn và vận hành cách tiếp cận Agile, Predictive, Hybrid.
  • Luyện thi PMPChiến lược ôn tập và mẹo xử lý câu hỏi tình huống PMP.
Công cụBài viết
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đápChuyên mụcCông cụBài viết
/
PM Study

Học quản lý dự án và ôn thi PMP bằng tiếng Việt: lý thuyết PMBOK® Guide 8, tình huống thực tế và đề luyện thi theo ECO 2026.

Chuyên mục

  • Quản lý các bên liên quan
  • Lãnh đạo & đội nhóm
  • Kế hoạch & tiến độ
  • Rủi ro & thay đổi
  • Agile & Hybrid
  • Luyện thi PMP

Tài nguyên

  • Project Management Institute (PMI)
  • PMP Exam Content Outline
  • The Scrum Guide
  • PMI Vietnam Chapter

PM Study

  • Tất cả bài viết
  • Bài viết nổi bật
© 2026 PM StudyPMP® và PMBOK® là nhãn hiệu đã đăng ký của Project Management Institute.109 người đã truy cậpPhiên bản 1.15.0
  1. /Tình huống
  2. /Quản lý Chất lượng
  3. /Boeing 787 (2015): bộ đếm phần mềm trong bộ điều…
Số 462Quản lý Chất lượng

Boeing 787 (2015): bộ đếm phần mềm trong bộ điều khiển máy phát tràn sau 248 ngày và chỉ thị tắt nguồn định kỳ của FAA

Tháng 5/2015, Cục Hàng không Liên bang Mỹ (FAA) ban hành chỉ thị đủ điều kiện bay cho Boeing 787: nếu bốn bộ điều khiển máy phát chính được cấp nguồn liên tục 248 ngày, một bộ đếm phần mềm sẽ tràn, khiến cả bốn cùng chuyển sang chế độ an toàn và máy bay mất toàn bộ điện xoay chiều. Biện pháp tạm thời là tắt nguồn máy bay trước mốc này, chờ bản phần mềm mới. Bài học về kiểm thử điều kiện biên theo thời gian trong phần mềm an toàn.

HP
Nguyễn Thu Hà, PMP
28/08/2026
3 phút đọc 0 lượt xem
Bình luận0

Bối cảnh thực tế

Boeing 787 là máy bay "nhiều điện" — nhiều hệ thống trước đây dùng thuỷ lực hoặc khí nén nay chạy bằng điện. Bộ điều khiển máy phát (GCU) gắn với các máy phát trên động cơ, quản lý nguồn điện cho toàn bộ máy bay.

Theo chỉ thị đủ điều kiện bay AD 2015-09-07 của FAA đăng trên Công báo Liên bang ngày 1/5/2015:

  • Một bộ đếm phần mềm bên trong GCU sẽ tràn sau 248 ngày cấp nguồn liên tục, khiến GCU chuyển sang chế độ an toàn (failsafe).
  • Nếu bốn GCU chính được cấp nguồn cùng lúc, cả bốn sẽ cùng chuyển chế độ, dẫn tới mất toàn bộ điện xoay chiều bất kể máy bay đang ở giai đoạn bay nào — có thể dẫn tới mất kiểm soát.
  • Biện pháp tạm thời: các hãng phải ngắt điện máy bay định kỳ trước mốc 248 ngày; FAA coi đây là hành động tạm thời trong khi Boeing phát triển bản sửa phần mềm. Chỉ thị ước tính ảnh hưởng tới 28 máy bay đăng ký tại Mỹ.
  • Sau đó FAA ban hành chỉ thị mới (AD 2018-20-15) yêu cầu cài phần mềm GCU mới, thay thế chỉ thị năm 2015.

Phân tích nguyên nhân theo chuẩn PMP

  • Điều kiện biên theo thời gian không nằm trong kế hoạch kiểm thử

    Lỗi chỉ xuất hiện sau tám tháng cấp nguồn liên tục — điều kiện gần như không bao giờ xảy ra trong phòng thử nghiệm. Kế hoạch quản lý chất lượng phải liệt kê các giới hạn về thời gian chạy, kích thước bộ đếm và kiểm chứng bằng phân tích nếu không thể kiểm thử thực tế.

  • Dư thừa cùng thiết kế tạo ra lỗi cùng lúc

    Bốn GCU giống nhau, cùng phần mềm, cùng thời điểm cấp nguồn sẽ hỏng cùng lúc. Dư thừa chỉ bảo vệ trước lỗi độc lập; lỗi phần mềm chung là lỗi có chung nguyên nhân (common cause failure).

  • Giả định vận hành chưa được kiểm chứng

    Thiết kế có thể ngầm giả định máy bay sẽ được tắt nguồn thường xuyên trong bảo dưỡng. Giả định vận hành phải được ghi lại và đối chiếu với cách khách hàng thực sự khai thác sản phẩm.

  • Phát hiện trước khi gây sự cố

    Lỗi được tìm ra trong thử nghiệm phòng lab trước khi xảy ra trên chuyến bay thật — cho thấy giá trị của các thử nghiệm kéo dài và phân tích sau triển khai.

  • Lẽ ra PM nên làm gì

    1. 1

      Bước 1: Rà soát tĩnh mọi bộ đếm và biến thời gian

      Phân tích mã để xác định thời điểm tràn của từng bộ đếm và so với thời gian vận hành tối đa có thể xảy ra, có biên an toàn.

    2. 2

      Bước 2: Đa dạng hoá để tránh lỗi chung

      Lệch thời điểm khởi động, khác biệt thiết kế hoặc cơ chế giám sát độc lập để không phải mọi kênh dư thừa cùng hỏng một lúc.

    3. 3

      Bước 3: Phân loại phát hiện theo mức độ và biện pháp tạm thời

      Khi lỗi đã ở trên sản phẩm đang khai thác:

      • Có thể chờ

        Lỗi không ảnh hưởng an toàn: sửa ở bản phát hành kế tiếp.

      • Biện pháp vận hành

        Có thể kiểm soát bằng quy trình (ví dụ khởi động lại định kỳ): ban hành ngay, đồng thời phát triển bản sửa.

      • Ngừng khai thác

        Không có biện pháp vận hành đáng tin cậy: dừng sử dụng cho tới khi sửa xong.

    PM Takeaway (Bài học rút ra)

    Phần mềm an toàn phải đúng cả trong những điều kiện hiếm gặp như chạy liên tục nhiều tháng. Hãy đưa giới hạn thời gian chạy vào kế hoạch chất lượng, đừng coi các kênh dư thừa giống nhau là độc lập, và chuẩn bị biện pháp vận hành tạm thời có kiểm soát khi phát hiện lỗi muộn.

    Nguồn tham khảo

    • Federal Register — Airworthiness Directives; The Boeing Company Airplanes (AD 2015-09-07)
    • EASA — AD US-2018-20-15 (thay thế AD 2015-09-07)
    #Quản lý chất lượng#Phát triển phần mềm#Hàng không#Phần mềm an toàn#Kiểm thử#FAA

    Nguồn: Federal Register — Airworthiness Directives; The Boeing Company Airplanes (AD 2015-09-07, 01/5/2015) ↗ (mở trong thẻ mới)

    Trắc nghiệm tình huống PMP

    Câu 1/1
    Trong giai đoạn kiểm thử một hệ thống điều khiển công nghiệp chạy liên tục, kỹ sư phát hiện một biến đếm có thể tràn sau khoảng 200 ngày. Hệ thống có ba bộ điều khiển dư thừa chạy cùng phần mềm. Trưởng nhóm cho rằng rủi ro thấp vì "đã có dư thừa". PM nên làm gì?

    Bạn chọn phương án nào?

    Nếu là hãng hàng không nhận chỉ thị này, bạn chọn cách nào để tuân thủ?

    Tình huống này hữu ích với bạn?

    Bình luận0

    Bình luận (0)

    Đăng nhập để tham gia thảo luận.

    Tình huống tương tự

    Số 483Quản lý Chất lượng

    Vineyard Wind (2024): cánh tuabin gió ngoài khơi gãy vì lỗi sản xuất, mảnh vỡ dạt vào bãi biển và 150 cánh phải kiểm tra lại

    Ngày 13/7/2024, một cánh dài 107 m của tuabin GE Vernova tại Vineyard Wind 1 (Massachusetts) bị gãy, mảnh sợi thuỷ tinh dạt vào bãi biển Nantucket. BSEE đình chỉ phát điện toàn trang trại. GE Vernova kết luận nguyên nhân là liên kết keo không đủ trong sản xuất — lỗi mà khâu đảm bảo chất lượng lẽ ra phải phát hiện — và kiểm tra lại khoảng 150 cánh cùng nhà máy. Bài học về kiểm soát chất lượng tại nguồn.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận29/10/2026
    Số 381Quản lý Chất lượng

    NASDAQ và IPO Facebook (2012): giới hạn thiết kế của hệ thống khớp lệnh và quyết định mở giao dịch khi chưa hiểu nguyên nhân gốc

    Trong phiên IPO của Facebook ngày 18/5/2012, hệ thống khớp lệnh mở cửa (cross) của NASDAQ gặp giới hạn thiết kế. Lãnh đạo tin rằng vài dòng mã đã sửa xong và cho giao dịch tiếp tục khi chưa hiểu nguyên nhân gốc; hơn 30.000 lệnh bị kẹt hơn hai giờ. SEC phạt NASDAQ 10 triệu USD — mức cao nhất với một sở giao dịch khi đó. Bài học về quản lý chất lượng và ra quyết định khi có sự cố.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận22/10/2026
    Số 369Quản lý Chất lượng

    Cloudflare 18/11/2025: một thay đổi quyền truy vấn cơ sở dữ liệu làm tệp cấu hình phình gấp đôi và sự cố lớn nhất kể từ 2019

    Một thay đổi về quyền truy cập cơ sở dữ liệu khiến truy vấn sinh tệp đặc trưng (feature file) cho Bot Management trả về dòng trùng lặp. Tệp vượt giới hạn 200 đặc trưng, làm proxy lõi bị panic và trả lỗi 5xx trên phần lớn mạng Cloudflare gần sáu giờ. Bài học về kiểm soát chất lượng cho cấu hình do chính hệ thống nội bộ sinh ra.

    1 lượt thích 0 lượt đánh giá hữu ích 0 bình luận22/10/2026

    Nội dung

    Bối cảnh thực tếPhân tích nguyên nhân theo chuẩn PMPLẽ ra PM nên làm gìPM Takeaway (Bài học rút ra)Nguồn tham khảoTrắc nghiệmBình chọn
    Quảng cáoBộ đề thi thử PMP (mẫu)