Sự sụp đổ của hệ thống kiểm soát không lưu Vương quốc Anh
(jameshaydon.github.io)- Ngày 28/8/2023, sự cố FPRSA-R của NATS, đơn vị vận hành kiểm soát không lưu Vương quốc Anh, khiến hơn 2.000 chuyến bay bị hủy, với chi phí ước tính hơn 100 triệu bảng Anh
- Kế hoạch bay gây ra tình trạng hỗn loạn là một kế hoạch hợp lệ đã được Eurocontrol IFPS chấp nhận; hệ thống NATS đã cố khớp dữ liệu ADEXP với tuyến ICAO4444 để trích xuất đoạn đi qua không phận Vương quốc Anh
- Nguyên nhân trực tiếp là hai waypoint ở hai vị trí địa lý khác nhau có cùng định danh; FPRSA-R đã khớp nhầm định danh trùng lặp làm điểm rời không phận, nên không tạo được đoạn hợp lệ của Vương quốc Anh
- Hệ thống chính và hệ thống dự phòng xử lý cùng một kế hoạch bay bằng cùng logic, lần lượt phát sinh critical exception và chuyển sang maintenance mode trong vòng 20 giây, khiến xử lý tự động bị dừng
- Máy bay vẫn được kiểm soát an toàn, nhưng chế độ lỗi khiến một kế hoạch bay duy nhất làm dừng toàn bộ hệ thống xử lý tự động, cùng với việc thiếu kiểm thử và quy trình khôi phục phụ thuộc vào log cấp thấp, vẫn là các vấn đề còn tồn tại
Quy mô sự cố NATS ngày 28/8/2023
- NATS, đơn vị vận hành kiểm soát không lưu Vương quốc Anh, đã gặp một sự cố kỹ thuật nghiêm trọng vào ngày 28/8/2023
- Theo BBC, hơn 2.000 chuyến bay bị hủy và chi phí được ước tính hơn 100 triệu bảng Anh
- Sự cố có thể đã ảnh hưởng tới hàng trăm nghìn người
- Các bản tin ban đầu nêu khả năng “kế hoạch bay sai” hoặc “lỗi của một hãng hàng không Pháp”, nhưng kế hoạch bay gây ra vấn đề là một kế hoạch bay tuân thủ ICAO4444 đã được Eurocontrol IFPS chấp nhận
- Sau đó, chuyến bay thực sự kích hoạt sự cố được xác định là French Bee FBU731, bay từ LAX/KLAX đến ORY/LFPO
Luồng một kế hoạch bay đi tới NATS
- Hãng hàng không nộp kế hoạch bay cho IFPS của Eurocontrol
- Khi IFPS chấp nhận kế hoạch bay, sau khi được kiểm soát tại sân bay khởi hành cấp phép, máy bay có thể cất cánh
- Ở bước này không cần đầu vào từ NATS
- IFPS chuyển kế hoạch bay cho các nhà cung cấp dịch vụ dẫn đường hàng không liên quan
- NATS phải nhận kế hoạch bay ít nhất 4 giờ trước khi máy bay đi vào không phận Vương quốc Anh
- Khoảng 4 giờ này đóng vai trò thời gian đệm để xử lý các vấn đề trong quá trình xử lý
- Trong hoạt động En-route của NATS tại Swanwick Centre, dữ liệu được chuyển tới FPRSA-R
- FPRSA-R chuyển đổi dữ liệu định dạng ADEXP nhận từ IFPS sang định dạng tương thích với UK National Airspace System, tức NAS
- NAS là hệ thống xử lý dữ liệu bay bao gồm thông tin về không phận và tuyến đường liên quan
Khác biệt giữa ICAO4444 và ADEXP
- Kế hoạch bay ICAO4444 là định dạng máy đọc được và, khi cần, con người cũng có thể đọc được
- Phần tuyến đường bao gồm tốc độ, độ cao, waypoint, tên tuyến và chỉ báo bay thẳng như
DCT - Ví dụ
N0440nghĩa là 440 knot,F310nghĩa là Flight Level 310
- Phần tuyến đường bao gồm tốc độ, độ cao, waypoint, tên tuyến và chỉ báo bay thẳng như
- IFPS chuyển đổi kế hoạch bay ICAO4444 sang định dạng ADEXP để chuyển tiếp
- ADEXP chứa kế hoạch bay ICAO4444 gốc cùng với các waypoint địa lý bổ sung cho tuyến đường khu vực châu Âu
- Với các chuyến bay đi qua không phận Vương quốc Anh nhưng không hạ cánh tại Vương quốc Anh, nó cũng có thể bao gồm các waypoint cần cho chặng sau bên ngoài Vương quốc Anh
RTEPTScủa ADEXP chứa chi tiết hơn về độ cao và thời gian dự kiến đi qua của từng waypoint- Tuyến ICAO có thể có 9 waypoint, nhưng danh sách mở rộng ADEXP có thể chứa 21 waypoint
- Điểm khởi hành và điểm đến trong tuyến ICAO nằm ở các trường riêng, nên không được đưa lại vào danh sách tuyến
Waypoint trùng lặp tạo ra sự cố
- Danh sách waypoint ADEXP có vấn đề chứa hai waypoint ở vị trí địa lý khác nhau nhưng có cùng designator
- ICAO và các tổ chức khác đã nỗ lực loại bỏ tên waypoint không duy nhất, nhưng trên toàn cầu vẫn còn các tên trùng lặp
- Tiêu chuẩn mới nhất quy định các waypoint có cùng định danh phải cách nhau rất xa về mặt địa lý
- Trong sự kiện này, cả hai waypoint đều nằm ngoài Vương quốc Anh; một ở đầu tuyến, một ở cuối tuyến, cách nhau khoảng 4.000 hải lý
- Trong kế hoạch bay mở rộng của chuyến bay được xác định là FBU731, waypoint tên DVL xuất hiện hai lần
- Một là Devil’s Lake ở Wisconsin, Mỹ
- Một là Deauville ở Normandy, Pháp
- Waypoint sau được xác định là xuất hiện ở phần sau của chuyến bay trong quá trình mở rộng đường hàng không
UN859
Quy trình xử lý của FPRSA-R và điểm lỗi
- FPRSA-R tìm điểm vào không phận Vương quốc Anh bằng cách quét từ đầu dữ liệu waypoint ADEXP
- Sau đó nó tìm điểm rời không phận Vương quốc Anh, rồi cố tìm đoạn tương ứng trong phần ICAO4444
- Tuyến ICAO không nhất thiết phải bao gồm điểm rời không phận
- Phần mềm được thiết kế để nếu điểm rời không có trong tuyến ICAO thì dùng điểm gần tiếp theo trong tệp ADEXP để tìm lại
- Trong sự kiện này, phần mềm lần theo các waypoint tiếp theo trong ADEXP và tìm thấy một định danh trùng lặp tồn tại trong tuyến ICAO
- Nhưng định danh đó không phải waypoint sau khi thực sự rời không phận Vương quốc Anh, mà là một waypoint địa lý khác ở đầu tuyến
- Kết quả là thứ tự hoặc đoạn giữa điểm vào và điểm rời không hợp lệ, nên không thể trích xuất đoạn ICAO tương ứng với không phận Vương quốc Anh
- Báo cáo của NATS chỉ ra đây là root cause của sự kiện và kết luận có thể loại trừ yếu tố liên quan đến an ninh mạng
Vì sao hệ thống chính và dự phòng dừng đồng thời
- Phần mềm an toàn trọng yếu được thiết kế để chuyển sang trạng thái cần can thiệp thủ công khi không thể tiếp tục một cách an toàn
- Hệ thống FPRSA-R chính xác định rằng nó không thể bảo đảm dữ liệu chính xác của kế hoạch bay nên phát sinh critical exception
- Ghi tệp log vào log hệ thống
- Chuyển sang maintenance mode
- Hệ thống C&M phát hiện hệ thống chính không còn khả dụng
- Hệ thống dự phòng được thiết kế để tiếp quản xử lý khi hệ thống chính gặp sự cố
- Đặt trên phần cứng riêng, nguồn điện riêng và feed dữ liệu riêng
- Tuy nhiên, nó áp dụng cùng logic cho cùng kế hoạch bay và phát sinh critical exception với cùng kết quả
- Từ lúc nhận thông điệp ADEXP đến khi cả hệ thống chính và dự phòng đều vào maintenance mode mất chưa tới 20 giây
- Lúc 08:32, xử lý kế hoạch bay tự động bị dừng, và sau đó cần nhập kế hoạch bay thủ công trong khoảng thời gian đệm 4 giờ
Quy trình khôi phục và tác động vận hành
- Đội hỗ trợ 1st Line nhận biết sự cố qua hệ thống C&M chuyên dụng, hệ thống C&M trung tâm và phản hồi từ đội vận hành
- Phản ứng ban đầu là quy trình khôi phục tiêu chuẩn: khởi động lại hệ thống con qua hệ thống C&M trung tâm
- Nhiều lần thử khôi phục thất bại
- Đội kỹ thuật 2nd Line được huy động và hỗ trợ kỹ sư tại chỗ qua liên kết video từ xa
- Khi 1st Line và 2nd Line không khôi phục được dịch vụ hoặc xác định chính xác nguyên nhân, đội Technical Design và hỗ trợ từ nhà sản xuất hệ thống con được yêu cầu tham gia
- Nhà sản xuất phân tích log phần mềm cấp thấp và xác định kế hoạch bay dường như đã gây ra sự cố
- Sau khi hiểu kế hoạch bay đó, họ cung cấp quy trình chính xác để khôi phục hệ thống theo cách được kiểm soát và an toàn
- Khi xảy ra sự cố, có sẵn các quy trình nhập thủ công và phối hợp thủ công giữa các phân khu, nhưng khi chuyển sang quy trình thủ công thì phải áp dụng hạn chế kiểm soát không lưu để giảm lưu lượng giao thông qua Vương quốc Anh
Frequentis AG và FPRSA-R
- Hệ thống con FPRSA đã tồn tại tại NATS trong nhiều năm; năm 2018, hệ thống cũ được thay thế bằng phần cứng và phần mềm mới của Frequentis AG
- Frequentis AG là một công ty Áo và là một trong các nhà cung cấp hệ thống kiểm soát không lưu
- Các sản phẩm ATC của nhà sản xuất này được cho là đang vận hành tại khoảng 150 quốc gia và có vị thế toàn cầu trong lĩnh vực quản lý thông tin hàng không và hệ thống xử lý thông điệp
- Trang tuyển dụng của Frequentis AG nhắc đến
Ada,C++,Java,Pythonliên quan đến hệ thống kiểm soát không lưu, trong đóJavaxuất hiện phổ biến nhất
Lỗi phần mềm và vấn đề kiểm thử
- FPRSA-R đã không trích xuất được đoạn ICAO tương ứng với không phận Vương quốc Anh từ một kế hoạch bay hợp lệ đã được IFPS chấp nhận
- Định danh waypoint không phải là duy nhất trên toàn cầu, và đây là vấn đề đã biết
- Nếu các waypoint trùng lặp ở rất xa nhau, kế hoạch bay thông thường vẫn có thể không mơ hồ
- Nhưng phần mềm lẽ ra phải xử lý điều kiện này một cách vững chắc
- NATS cho biết có thể xem xét, thông qua chính phủ Vương quốc Anh, việc loại bỏ một số ít tên waypoint trùng lặp liên quan đến sự kiện này khỏi bộ dữ liệu toàn cầu do ICAO quản lý
- CEO NATS Martin Rolfe nói với BBC rằng sự kiện này có xác suất “1 trên 15 triệu”
- Ông nói hệ thống đó được đưa vào sử dụng năm 2018 và đã xử lý 15 triệu kế hoạch bay trong thời gian qua
- Với hệ thống an toàn trọng yếu, các bước xử lý kế hoạch bay, đặc biệt là bước quan trọng như trích xuất đoạn Vương quốc Anh, cần được kiểm thử
- Các bài kiểm thử không xét đến tên waypoint trùng lặp có thể đã không phát hiện được lỗi này
- Fuzzing bằng cách đưa vào số lượng lớn kế hoạch bay ngẫu nhiên có thể đã giúp tìm ra các đầu vào khiến hệ thống rơi vào chế độ lỗi xấu
Vấn đề của chế độ lỗi
- Một kế hoạch bay duy nhất đã làm dừng toàn bộ hệ thống xử lý tự động FPRSA-R, và kết quả là không kế hoạch bay nào được xử lý tự động
- Chế độ lỗi tốt hơn là đưa riêng kế hoạch bay có vấn đề vào một hàng đợi chậm để con người xử lý thủ công
- NATS cho biết trong các biện pháp đã hoặc đang thực hiện, họ sẽ thêm bộ lọc thông điệp cụ thể vào luồng dữ liệu giữa IFPS và FPRSA-R để lọc các kế hoạch bay phù hợp với điều kiện đã gây ra sự kiện
- Khi FPRSA-R dừng, kế hoạch bay liên quan chỉ được xác định trong log phần mềm cấp thấp
- Nếu lỗi xử lý một kế hoạch bay cụ thể trong hệ thống xử lý kế hoạch bay làm dừng toàn bộ hệ thống, tốt hơn là cảnh báo có chứa kế hoạch bay đó nên được gửi ngay tới đội giám sát
- NATS cho biết họ đã xây dựng hướng dẫn vận hành để có thể nhanh chóng khôi phục FPRSA-R nếu cùng tình huống tái diễn, và các kỹ thuật viên vận hành đã được đào tạo để thực hiện quy trình mới
- Hoạt động cũng sẽ được giám sát bởi hệ thống theo dõi tăng cường và thêm nhân sự chuyên môn kỹ thuật
Khả năng kiểm chứng hình thức
- Không có dấu hiệu rõ ràng rằng kiểm chứng hình thức đã được sử dụng ở bước và hệ thống liên quan trong sự kiện này, và báo cáo cũng không đề cập
- Kiểm chứng hình thức hoặc model checking có thể đã giúp giảm các loại lỗi như thế này
- Tuy nhiên, kiểm chứng hình thức đầu-cuối cho hệ thống quy mô lớn vẫn còn ở giai đoạn đầu, và ngay cả khi có dùng một phần kiểm chứng hình thức, mã lỗi vẫn có khả năng lọt vào môi trường vận hành
- Cần có kết quả điều tra cuối cùng mới biết thêm thực tế đã sử dụng phương pháp kiểm chứng nào
An toàn và báo cáo công khai
- Máy bay trên bầu trời Vương quốc Anh vẫn được giữ an toàn trong suốt sự kiện
- Các kiểm soát viên không lưu giàu kinh nghiệm giám sát máy bay thông qua các kế hoạch bay đã biết, liên lạc vô tuyến, radar và quan sát trực quan
- Kết quả không phải là nguy cơ về tính mạng, mà là chỉ có thể cho cất cánh ít chuyến bay hơn nhiều hoặc phải bay vòng tránh không phận Vương quốc Anh
- NATS duy trì an toàn bằng cách thực hiện các biện pháp giảm số chuyến bay
- Báo cáo được công bố khá minh bạch và chi tiết, và việc báo cáo như vậy là quan trọng đối với hạ tầng trọng yếu
- Michael O’Leary của Ryanair chỉ trích báo cáo này là “rubbish” và nói rằng nó giảm nhẹ tác động đối với ngành hàng không, nhưng cũng có đánh giá cho rằng phạm vi của báo cáo ban đầu không nhằm phân tích mức độ thất bại của NATS
Hướng triển khai vững chắc hơn
- Vấn đề là xử lý hai chuỗi waypoint
- ADEXP: danh sách đầy đủ các waypoint
- ICAO: một dãy con của các waypoint ADEXP
- Vì kế hoạch ICAO không nhất thiết bao gồm điểm vào/rời không phận, việc tìm đoạn liên tục nhỏ nhất của ICAO tương ứng với không phận Vương quốc Anh không hề đơn giản
- Vấn đề của thuật toán sai là nó thao tác các con trỏ đồng thời trỏ vào dữ liệu ICAO và ADEXP, trong khi đặt các invariant không rõ ràng bên ngoài mã
- Cách tiếp cận được đề xuất là trước hết khớp dữ liệu ICAO và ADEXP thành một cấu trúc kế hoạch bay Combined, rồi sau đó trích xuất đoạn Vương quốc Anh
- Tính tất cả các reconciliation có thể để phát hiện trường hợp mơ hồ
- Nếu có 0 reconciliation thì không thể khớp ICAO và ADEXP
- Nếu có nhiều reconciliation thì đó là trường hợp mơ hồ và có thể đưa vào xử lý thủ công
- Bản triển khai ví dụ bằng Haskell xử lý tường minh các lỗi
NonUkPlan,CannotReconcileIcaoAdexp,AmbiguousReconciliationsOfIcaoAdexp - Trong ví dụ, ngay cả khi danh sách ADEXP có định danh trùng lặp
Q, nếu dữ liệu ICAO và ADEXP được khớp không mơ hồ thì đoạn Vương quốc Anh đúng vẫn được trả về - Toàn bộ mã nằm tại uk-portion-of-ICAO
1 bình luận
Ý kiến trên Hacker News
Về cơ bản là họ đã bỏ sót giới hạn phạm vi tách biệt theo địa lý trong truy vấn kế hoạch bay. Trước đây khi xây dựng hệ thống dẫn đường bay, tôi đã biết lỗi này, cũng từng thấy nó ngoài thực tế, và từng làm theo đặc tả yêu cầu đưa geofence vào để tránh lỗi này
Đoạn “hệ thống dự phòng áp dụng cùng một logic cho kế hoạch bay và cho ra cùng kết quả” mới là vấn đề. Trong phần mềm, hệ thống dự phòng nên dùng logic khác
Trước đây khi làm ở Boeing với hệ thống trim stabilizer của 757, có hai máy tính avionics được nối vào dây điều khiển trim, thông qua một bộ so sánh. Nếu hai hộp không đồng thuận thì cả hai đều mất quyền điều khiển
Hai hộp được thiết kế với thuật toán khác nhau, ngôn ngữ lập trình khác nhau, CPU khác nhau, mã do các nhóm khác nhau được ngăn cách bằng firewall viết; mục đích là để một lỗi ở một bên không làm hỏng bên kia theo cùng một cách
Hệ thống kiểm soát không lưu tối thiểu phải là 2oo3[1], tức là luôn phải có 2 trong 3 hệ thống được phát triển độc lập đồng thuận. Như vậy nếu một hệ thống thất bại, hai hệ thống còn lại vẫn tiếp tục vận hành và không ảnh hưởng đến tính sẵn sàng của ngành hàng không
Dùng con người làm dự phòng là bất khả thi vì nhân lực và độ phức tạp. Hệ thống kiểm soát không lưu phải có khả năng cung cấp kiểm soát phân cách trong điều kiện IFR[2] và CVFR[3]
[1] https://en.wikipedia.org/wiki/Triple_modular_redundancy
[2] https://en.wikipedia.org/wiki/Instrument_flight_rules#Separa...
[3] https://en.wikipedia.org/wiki/Visual_flight_rules#Controlled...
J. Gall
Tôi nhớ ở NATS cũng từng có một sự cố khác gây ra hiệu ứng tương tự. Hệ thống chính sập nên họ chuyển sang hệ thống phụ, rồi hệ thống phụ cũng sập vì đúng cùng một lý do
Có lẽ chỉ nên chuyển đổi dự phòng khi biết vấn đề nằm ở chính hệ thống chính chứ không phải ở phần mềm. Cách chỉ đơn giản chuyển sang hệ thống khác chỉ càng củng cố cảm giác rằng hệ thống không phơi bày đủ thông tin để người vận hành phán đoán thực sự cần làm gì
Điều khó chịu hơn là dường như không có một phương thức kiểu “ValidateFlightPlan”, nên nếu vì bất kỳ lý do nào không thể parse được thì nó ném lỗi, và không có một nhánh xử lý thật đơn giản cho lỗi đó. Tôi khó hình dung có lập trình viên nào nhìn vào bộ xử lý đầu vào bên ngoài mà không nghĩ “nếu đầu vào xấu làm hỏng hệ thống thì làm gì?”
Chức năng an toàn thật sự là khoảng đệm 4 giờ trước khi cần đến xử lý thủ công
Trong hàng không, kiểm soát an toàn cốt lõi không hẳn là “làm sao để nó không hỏng ngay từ đầu”, mà gần hơn với “nếu vì bất kỳ lý do nào nó hỏng thì ta sẽ làm gì”
Phong cách lập trình rất mệnh lệnh, và chỉ qua mô tả thì nghe như quy trình đang thao tác trực tiếp trên biểu diễn văn bản của kế hoạch bay, chứ không phải trên cấu trúc dữ liệu được parse từ file văn bản. Nếu đúng là vậy thì khá đáng lo, dù cũng có thể chỉ là do cách mô tả
Nếu đúng như mô tả này, tôi cũng sẽ không ngạc nhiên nếu họ chỉ chạy regex hoặc so khớp chuỗi con trên văn bản, trong một kiến trúc không có class, object hay cấu trúc dữ liệu. Cũng phải tính đến khả năng đây là mã C hàng chục năm tuổi mà toàn bộ hàng không Anh phụ thuộc vào, không thể viết lại hay thay thế
Hệ thống chính thất bại vì tràn số nguyên, và hệ thống phụ giống hệt cũng tràn theo. Góc tấn tăng lên, booster tách ra, rồi tên lửa phát nổ
[1] https://en.wikipedia.org/wiki/Ariane_flight_V88
Tôi không hiểu tại sao họ chỉ đưa những kế hoạch bay bị lỗi vào hàng đợi chờ con người xem xét mà không thể tiếp tục xử lý các chuyến bay còn lại. Điều khó hiểu nhất là họ không có “tính năng” đó
Khi xảy ra lỗi “tuyệt đối không được xảy ra”, hệ thống không thể biết điều gì đang sai, mức ảnh hưởng lớn và rộng đến đâu. Như lần này, có thể vẫn tiếp tục được, nhưng cũng có thể phần mềm vừa phát sinh một lỗi mới nghiêm trọng, âm thầm làm nhiễm bẩn tất cả các kế hoạch bay khác và khiến người ta thiệt mạng. Nếu không biết tiếp tục có an toàn hay không thì phải dừng lại
Nếu có thể ngăn chiếc máy bay cụ thể có vấn đề không cất cánh thì vẫn có thể để hệ thống tiếp tục chạy, nhưng nếu nó đã ở trên không thì câu chuyện khác
Việc quyết định rằng “có một máy bay sẽ vào không phận Anh đang trên đường bay, nhưng không biết nó sẽ vào lúc nào và ở đâu. Tạm dừng các kế hoạch bay bổ sung cho đến khi biết vị trí của máy bay đó” không phải là hoàn toàn vô lý
Nếu thật sự không thể xử lý kế hoạch bay, một giải pháp hợp lý có thể là chuyển hướng và cho máy bay đó hạ cánh trước khi tới Anh, nhưng việc như vậy cuối cùng vẫn phải chờ can thiệp thủ công
Hệ thống nào cũng có thể trục trặc, nên điều quan trọng là trục trặc theo cách tốt và những người phụ trách đã chuẩn bị cho tình huống đó
Chỉ một kế hoạch bay đơn lẻ gây vấn đề, rồi toàn bộ hệ thống FPRSA-R chết, khiến không kế hoạch bay nào được xử lý. Nếu một kế hoạch bay có vấn đề, nó phải được chuyển sang một hàng đợi riêng chậm hơn để con người xử lý thủ công. NATS cũng thừa nhận trong các “biện pháp đã thực hiện hoặc đang tiến hành” rằng họ sẽ thêm một bộ lọc thông điệp vào luồng dữ liệu giữa IFPS và FPRSA-R để lọc ra các kế hoạch bay có điều kiện đó
Nói rằng lẽ ra lỗi này phải được xử lý như một lỗi đã biết là hợp lý, nhưng nhìn rộng ra thì cũng giống như nói “đáng ra phải viết mã không có bug”. Ngay cả khi đã parse thành struct, nó vẫn có thể giống như việc mã giả định có một khóa tùy chọn rồi đột nhiên KeyError bật ra
Phân tích hậu sự cố và cải tiến cho những việc như thế này phải đặt trên giả định rằng một lỗi không xác định, chưa được xử lý và không thể dự đoán rồi sẽ xảy ra vào một lúc nào đó, và khi đó phải xử lý tốt hơn ra sao. Cách giải quyết bug là sửa bug, nhưng nguyên nhân của sự cố lớn là kế hoạch khôi phục thảm họa không thể thực thi trong thời gian hợp lý. Dù dùng thực hành lập trình, phong cách, ngôn ngữ hay công cụ nào, một sự kiện ở cấp tương tự chắc chắn với xác suất 1 rồi cũng sẽ xảy ra lại, ngay cả với các lập trình viên giỏi nhất
Nếu từ góc nhìn của mã, nó trông giống như lỗi toàn vẹn của cơ sở dữ liệu điểm bay dẫn đường nền, thì quyết định dừng xử lý kế hoạch bay dễ hiểu hơn nhiều
Ví dụ, nếu mã hỏi kho lưu trữ điểm bay và đường hàng không rằng “hãy tìm cho tôi điểm bay trên đường hàng không này rời khỏi không phận Anh”, rồi tìm đoạn đường hàng không chứa điểm bay đó, sau đó khẳng định rằng đoạn đó đi qua không phận Anh nhưng khẳng định ấy thất bại, thì điều này có thể trông không giống vấn đề của kế hoạch bay mà giống như một giả định được nhúng trong dữ liệu đường hàng không đã bị phá vỡ
Theo một nghĩa nào đó, nó thật sự cũng có thể là một bug nghiêm trọng. Sự cố này cho thấy các giả định mà thuật toán đặt ra về dữ liệu là sai, và nó có khả năng trả về đáp án sai
Các bài liên quan
Hệ thống kiểm soát không lưu Anh bị đánh lừa vì tên điểm bay trùng hợp - https://news.ycombinator.com/item?id=37430384 - tháng 9 năm 2023, 64 bình luận
Dữ liệu kế hoạch bay xấu gây sự cố kiểm soát không lưu tại Anh - https://news.ycombinator.com/item?id=37402766 - tháng 9 năm 2023, 20 bình luận
Báo cáo sự cố kiểm soát không lưu của NATS nêu chi tiết nguyên nhân gốc rễ và giải pháp - https://news.ycombinator.com/item?id=37401864 - tháng 9 năm 2023, 19 bình luận
Sự cố mạng kiểm soát không lưu Anh - https://news.ycombinator.com/item?id=37292406 - tháng 8 năm 2023, 23 bình luận
Việc họ đổ lỗi cho kế hoạch bay của Pháp vốn đã được Eurocontrol chấp nhận là bằng chứng cho thấy họ không thật sự hiểu phần mềm của mình hoạt động ra sao. Và công ty Áo cũng phải chịu một phần trách nhiệm vì thiếu kiểm thử tập trung
Bài viết rất hay. Đọc xong thì tôi nghĩ ý chính là như sau
Tên waypoint được dùng trên toàn thế giới không phải là duy nhất, và như một kiểu vá víu để tránh nhầm lẫn, tiêu chuẩn mới nhất yêu cầu các định danh giống nhau phải được đặt đủ xa nhau về mặt địa lý. Dù vậy, trên cùng một đường bay, cùng một tên waypoint vẫn có thể chỉ các vị trí khác nhau
Phần mềm đã không tính đến khả năng đó, việc tính toán đường bay thất bại, ném ra “ngoại lệ nghiêm trọng” và chuyển sang “chế độ bảo trì”. Nói cách khác là chết hẳn
Hệ thống dự phòng tiếp quản, nhưng với cùng dữ liệu thì gặp đúng cùng lỗi nên cũng chết, còn đội hỗ trợ thì khổ sở. Cuối cùng chỉ sau khi liên hệ với nhà cung cấp phần mềm, họ mới tìm được log cấp thấp hé lộ nguyên nhân
Một người bạn phi công không quân đã nghỉ hưu của tôi tốt nghiệp Cranfield University; đây là một cơ sở sau đại học tiêu biểu của Vương quốc Anh về kỹ thuật hàng không vũ trụ và còn có sân bay riêng phục vụ đào tạo, nghiên cứu[1]. Người bạn đó nói rằng ở Cranfield anh ấy đã học hệ điều hành, giờ tôi mới hiểu lý do
Nhìn các bình luận khác thì có vẻ tiêu chuẩn không gian tên đã tồn tại, nhưng NATS/ATC dường như không dùng. Hy vọng sau vụ này họ sẽ bắt đầu dùng. Bình luận trên cùng nói về lỗi geofencing, nhưng nếu NATS/ATC dùng đúng không gian tên thì rất có khả năng ngay từ đầu đã không cần geofencing
[1] Cranfield University:
https://en.wikipedia.org/wiki/Cranfield_University
“Chỉ nhìn phần mô tả thì nghe như quy trình đang thao tác trực tiếp trên biểu diễn văn bản của kế hoạch bay, chứ không phải trên cấu trúc dữ liệu được parse từ tệp văn bản. Nếu đúng là vậy thì khá đáng lo, nhưng cũng có thể chỉ do cách mô tả”
Trong công việc của ngành hàng không, cách này rất phổ biến. Hỏi lập trình viên về domain model hay parsing là họ thường nhìn bạn với vẻ ngơ ngác. Họ thích mã kiểm chứng, và nếu không kiểm chứng được thì thích bỏ cuộc luôn. Tất cả đều là các pipeline dữ liệu ngớ ngẩn, hoàn toàn không có mã nào mô hình hóa các hoạt động diễn ra trong thế giới thực
Trong bất kỳ hệ thống nào cũng không có thứ như kiểu “kế hoạch bay” có hành vi, hay một tập hợp các kiểu waypoint. Dù có kiểu thì cũng chỉ là struct chuỗi theo góc nhìn C, và mỗi lần truy cập thành viên của struct đó thì lại parse, không phải một lần mà là lần nào cũng vậy. Như bài viết nói, “phong cách lập trình trông rất mệnh lệnh” là đúng
Chết vì đầu vào xấu là sai, nhưng cố diễn giải dữ liệu chưa được kiểm chứng mà không có đặc tả thì rất dễ dẫn đến bất đồng trong cách hiểu về sau, vấn đề tương thích và các điều kiện biên không ngờ tới. Không ai muốn trả tiền cho một hệ thống xử lý mọi trường hợp đã được kiểm thử đầy đủ, công cụ mô phỏng đầu vào sai, và kiểm chứng hình thức cho parser cùng toàn bộ mã sử dụng kết quả parser
Vốn đã có nhiều vấn đề vì các bộ phát dữ liệu không tuân thủ, legacy, có lỗi, cộng thêm độ phức tạp về ngữ nghĩa giao diện và timing. Nếu cố phản ứng một cách thông minh với dữ liệu sai định dạng hay sai encoding thì còn nguy hiểm hơn
Chỉ riêng việc tạo ra một hệ thống hoạt động đúng theo đặc tả đã khó và đắt đỏ. Những biến thể tinh vi chấp nhận rộng rãi hơn các hành vi không được đặc tả hoặc là lời mời gọi lỗi, hoặc là tạo ra một hệ thống đắt hơn không vượt qua được tiêu chí giá mua
“Kiểm soát không lưu Anh: điều tra liệu lỗi từ Pháp có gây ra sự cố hay không”
Tất nhiên là không. Đây là hệ thống của Anh thì sao lại là lỗi của một hãng hàng không Pháp được? Những hệ thống kiểu này phải có kiến trúc chống lỗi với dự phòng
Chỉ cần từ chối một mục bị lỗi rồi tiếp tục chạy có lẽ đã đủ
Đó là một ngày tôi không muốn nhớ lại. Điểm đến lẽ ra chỉ mất 2 giờ thì tôi mất 15 giờ mới tới
Tôi đi tàu, xe buýt, rồi lại tàu; 30 phút sau khi tôi đặt vé thì vé cho cả hai ngày đều bán hết