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

Hệ thống tên lửa Patriot tại Dhahran (1991): sai số làm tròn trong đồng hồ phần mềm và bản sửa lỗi đến chậm một ngày

Ngày 25/2/1991, một hệ thống Patriot tại Dhahran (Ả Rập Xê Út) không đánh chặn được tên lửa Scud, khiến 28 binh sĩ Mỹ thiệt mạng. Theo GAO, sai số làm tròn khi chuyển đổi thời gian trong phần mềm tích tụ theo thời gian chạy liên tục; khẩu đội đã chạy hơn 100 giờ. Dữ liệu cảnh báo có từ hai tuần trước, nhưng hướng dẫn gửi đơn vị không nói rõ "chạy lâu" là bao lâu, và bản phần mềm sửa lỗi tới nơi một ngày sau vụ tấn công. Bài học về giả định vận hành và truyền đạt biện pháp tạm thời.

Nguyễn Thu Hà, PMP

25/08/2026

3 phút đọc 0

Bình luận0

Bối cảnh thực tế

Hệ thống Patriot ban đầu được thiết kế để đánh chặn máy bay, trong môi trường cơ động, thường không chạy liên tục quá lâu tại một vị trí. Trong Chiến tranh vùng Vịnh, nó được dùng để đánh chặn tên lửa Scud bay nhanh hơn nhiều, và các khẩu đội chạy liên tục nhiều ngày.

Theo báo cáo GAO/IMTEC-92-26 của Văn phòng Kiểm toán Chính phủ Mỹ:

Hệ thống ghi thời gian theo đơn vị một phần mười giây; việc chuyển đổi sang dạng số dùng để tính toán gây sai số làm tròn, tích tụ theo thời gian chạy liên tục và làm lệch "cửa sổ" dùng để theo dõi mục tiêu.
Ngày 11/2/1991, dữ liệu thực địa cho thấy cửa sổ theo dõi bị lệch sau 8 giờ chạy liên tục; ước tính sau khoảng 20 giờ hệ thống sẽ không theo dõi và đánh chặn được Scud.
Bản phần mềm sửa lỗi được phát hành ngày 16/2. Trong khi chờ, đơn vị được thông báo rằng thời gian chạy rất dài có thể gây vấn đề, nhưng không được cho biết bao lâu là "rất dài".
Ngày 25/2/1991, khẩu đội tại Dhahran đã chạy liên tục hơn 100 giờ; hệ thống không theo dõi được Scud, tên lửa rơi trúng doanh trại, 28 binh sĩ Mỹ thiệt mạng.
Bản phần mềm sửa lỗi tới Dhahran ngày 26/2 — một ngày sau vụ tấn công.

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

Môi trường vận hành thay đổi nhưng yêu cầu chất lượng không đổi theo
Phần mềm được thiết kế cho mục tiêu chậm hơn và thời gian chạy ngắn. Khi dùng cho nhiệm vụ mới với điều kiện khác, giả định về thời gian chạy và độ chính xác cần được đánh giá lại như một yêu cầu mới.
Sai số tích luỹ là lỗi điều kiện biên
Lỗi không thể hiện ở các bài kiểm thử ngắn. Kế hoạch chất lượng phải có phân tích số học và kiểm thử với thời gian chạy dài nhất có thể xảy ra trong thực tế.
Biện pháp tạm thời được truyền đạt mơ hồ
Thông điệp "chạy rất lâu có thể gây vấn đề" mà không có con số cụ thể khiến đơn vị thực địa không biết phải làm gì. Một biện pháp tạm thời không hành động được thì không phải là biện pháp kiểm soát.

Hệ thống tên lửa Patriot tại Dhahran (1991): sai số làm tròn trong đồng hồ phần mềm và bản sửa lỗi đến chậm một ngày

Bối cảnh thực tế

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

Môi trường vận hành thay đổi nhưng yêu cầu chất lượng không đổi theo

Sai số tích luỹ là lỗi điều kiện biên

Biện pháp tạm thời được truyền đạt mơ hồ

Phân phối bản sửa lỗi chậm so với mức độ nghiêm trọng

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

Bước 1: Đánh giá lại yêu cầu khi sản phẩm được dùng cho nhiệm vụ mới

Bước 2: Biện pháp tạm thời phải cụ thể và kiểm tra được

Bước 3: Phân loại lỗi để chọn kênh triển khai

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

Nguồn tham khảo

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

Nếu là quản lý dự án phần mềm Patriot ngày 11/2/1991, khi có dữ liệu về độ lệch, bạn ưu tiên việc nào?

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

Bình luận (0)