Những ngộ nhận sai lầm mà lập trình viên tin về lĩnh vực hàng không
(flightaware.engineering)- Dữ liệu hàng không có nhiều đặc tính phức tạp và phi tiêu chuẩn
- Lập trình viên thường đưa ra các giả định sai về chuyến bay, sân bay, điều hướng, thông tin transponder
- Trên thực tế, hệ thống theo dõi chuyến bay phải linh hoạt xử lý nhiều tình huống ngoại lệ và bất thường dữ liệu
- Nhiều hiểu lầm gây ra lỗi không lường trước trong phần mềm hoặc hệ thống khách hàng
- Khi thiết kế dữ liệu, cần có góc nhìn phản ánh kỹ lưỡng độ phức tạp của thực tế
Tổng quan
FlightAware là công ty phát triển phần mềm xử lý và phân phối dữ liệu hàng không trên toàn thế giới. Tuy nhiên, dữ liệu hàng không thực tế, trái với trực giác, không có tính cấu trúc chặt chẽ và chứa rất nhiều ngoại lệ lẫn biến thể bất thường. Nhiều lập trình viên thường đặt ra các tiền đề về cấu trúc dữ liệu, luồng dữ liệu, hệ thống định danh..., nhưng trong thực tế các giả định này lại sai và dẫn đến lỗi hệ thống cùng sự không nhất quán. Bài viết này, tiếp nối loạt bài về những ngộ nhận sai lầm, tổng hợp các hiểu lầm thường gặp trong phần mềm của ngành hàng không và những trường hợp phát sinh từ đó.
Flights (Thông tin chuyến bay)
- Có ngộ nhận rằng chuyến bay luôn khởi hành từ cổng, nhưng trên thực tế có thể đổi cổng nhiều lần, hoặc khởi hành muộn hay sớm hơn rất nhiều so với dự kiến
- Nhiều người dễ nghĩ lịch bay hay sân bay đi/đến là thông tin rõ ràng, nhưng trực thăng, máy bay quân sự... có thể cất/hạ cánh ở những nơi không phải sân bay
- Thời gian bay hay lịch trình của chuyến bay có vẻ như sẽ đều đặn, nhưng các chuyến bay kéo dài qua nhiều ngày hoặc vận hành bất quy tắc cũng xảy ra thường xuyên
- Rất dễ giả định mã định danh chuyến bay (ví dụ: UAL1234) là duy nhất, nhưng trên thực tế một máy bay có thể được gán nhiều định danh hoặc số hiệu, và cùng một số có thể được dùng trong nhiều tình huống
- Dù bề ngoài là cùng một số, định danh chuyến bay, số đăng ký và các ký hiệu khác có thể bị trộn lẫn gây nhầm lẫn, và thông tin định danh mà vé, kiểm soát không lưu, phi công sử dụng cũng có thể khác nhau
Airports (Thông tin sân bay)
- Có thể nghĩ rằng vị trí sân bay và mã định danh là cố định, nhưng trên thực tế sân bay có thể đóng cửa, di dời hoặc sáp nhập, khiến vị trí hay mã bị thay đổi
- Hệ thống đặt tên cho nhà ga/cổng, số đường băng... cũng không nhất quán và có nhiều quy tắc ngoại lệ
- Ngay cả với hệ thống mã ICAO/IATA cũng tồn tại nhiều trường hợp trùng lặp, một địa điểm có nhiều mã, hoặc hiểu sai về mã vị trí, tức là nhiều trường hợp không khớp với thực tế
- Việc có một thông tin định danh nào đó (ví dụ: mã IATA) không nhất thiết bảo đảm đó là một sân bay thực sự; cũng có những trường hợp ga tàu hoặc bến xe được cấp mã IATA
- Thậm chí trong các mã ICAO còn có trường hợp được gán cho nơi không nằm trên Trái Đất (ví dụ: miệng hố ngoài hành tinh)
Airlines (Thông tin hãng hàng không)
- Phần này không nêu riêng các ngộ nhận cụ thể theo từng dòng nên được lược bỏ
Navigation (Thông tin điều hướng và đường bay)
- Có ngộ nhận rằng tên waypoint là duy nhất, nhưng thực tế có trùng lặp
- Định nghĩa độ cao trong hàng không không được thống nhất thành một kiểu duy nhất, mà được diễn giải khác nhau tùy theo nhiều chuẩn
- Có thể nghĩ rằng dữ liệu kiểm soát không lưu hoàn toàn chính xác, nhưng trên thực tế lỗi hoặc thay đổi xảy ra thường xuyên
- Việc hủy kế hoạch bay, thay đổi flight plan... có thể không được phản ánh vào chuyến bay thực tế, và cùng một chuyến bay có thể đổi điểm đến nhiều lần
- Cũng tồn tại sự không khớp dữ liệu giữa radar và các cơ quan kiểm soát không lưu, hoặc hiện tượng lệch vị trí khi quan sát đồng thời
Transponders and ADS-B (Thông tin về transponder và ADS-B)
- Có thể giả định tín hiệu ADS-B chỉ được phát từ máy bay, nhưng thực tế xe trong sân bay hoặc các thiết bị khác cũng có thể phát
- Việc quá tin tưởng vào độ chính xác của tọa độ GPS và độ tin cậy của tín hiệu cũng là một hiểu lầm
- Sai sót/trùng lặp trong thông tin đăng ký transponder (mã định danh, địa chỉ Mode S...), thiếu sót bảo trì, lỗi định dạng... khiến sự không khớp giữa dữ liệu thời gian thực và thông tin thực tế xảy ra thường xuyên
- Mọi người dễ nghĩ thông tin ADS-B được nhận/lưu trữ nguyên xi, nhưng thực tế có nhiều vấn đề như lỗi truyền dẫn, giả mạo tín hiệu...
- Hỏng hóc thiết bị, quản lý bất cẩn, hay yếu tố bên ngoài (ví dụ: chuột cắn hỏng cáp) cũng là những biến số rất thực tế
Kết luận
Danh sách này cho thấy mức độ phức tạp của độ tin cậy dữ liệu hàng không, được xây dựng dựa trên kinh nghiệm và insight mà đội ngũ phát triển FlightAware và Hyperfeed tích lũy qua nhiều năm từ vô số tình huống thực tế. Bài viết nhấn mạnh tầm quan trọng của việc mô hình hóa và vận hành dữ liệu với sự cân nhắc kỹ lưỡng đến các tình huống ngoại lệ có thật, nhằm giảm thiểu các loại lỗi và hiểu lầm.
4 bình luận
Bởi vậy việc chuẩn hóa dữ liệu mới... quan trọng... haha
Phần thân bài thật sự rất ngắn gọn, nhưng cảm xúc ẩn chứa bên trong thì;;
Chỉ đọc thôi mà cũng thấy tăng huyết áp luôn haha
Ý kiến Hacker News
Giải thích về việc trong lĩnh vực hàng không không tồn tại một mã định danh duy nhất, cố định theo thời gian cho máy bay. Chia sẻ kinh nghiệm thực tế rằng mỗi phương tiện bay đều có số sê-ri, nhưng chỉ riêng số này không đảm bảo tính duy nhất. Tổ hợp "nhà sản xuất, kiểu loại, số sê-ri" là thứ gần nhất với mã định danh duy nhất trong suốt vòng đời, nhưng ngay cả điều đó đôi khi cũng thay đổi nếu máy bay đổi loại do cải tạo kết cấu. Cũng bày tỏ cảm giác cá nhân rằng thật lạ khi một hệ thống khổng lồ và phức tạp như hàng không lại không có mã định danh bất biến. Số đăng ký máy bay (tail number) có thể thay đổi như biển số xe, còn mã định danh 24-bit của ICAO gắn với thiết bị ADS-B nên cũng có thể được chuyển hoặc thay đổi tự do
Bày tỏ sự tò mò rằng việc dùng tổ hợp "nhà sản xuất, kiểu loại, số sê-ri" lại từng được cấp bằng sáng chế. Đặt câu hỏi làm sao một thứ như vậy lại được công nhận là mới để có thể được cấp bằng sáng chế
Liên hệ câu chuyện này với nghịch lý 'Con tàu của Theseus', giới thiệu sự liên tưởng mang tính triết học về bản sắc của máy bay và sự thay đổi mã định danh liên kết Wikipedia về Ship of Theseus
Chia sẻ bối cảnh lịch sử rằng ngành hàng không đã phát triển theo kiểu các silo tách biệt ở từng quốc gia, nên việc tiêu chuẩn hóa bị chậm. Theo góc nhìn này, việc các tiêu chuẩn toàn cầu thực sự được thiết lập đã là điều đáng kinh ngạc. Phân tích thêm rằng hiện tại điều đó phần nào khả thi vì các nhà sản xuất lớn đã được hợp nhất chỉ còn số ít
Chia sẻ kinh nghiệm thực địa rằng trong môi trường thực tế, vấn đề về mã định danh duy nhất "thực sự" xuất hiện rất thường xuyên. Giải pháp gần như luôn là tổ hợp “mẫu, nhà sản xuất, số sê-ri”, và nếu cần thì thêm cả năm sản xuất. Thậm chí còn nhắc đến một trường hợp thử de-duplication dữ liệu con người dựa trên các tiêu chí như ngôn ngữ (tiếng mẹ đẻ)
Chia sẻ ví dụ rằng ngay cả số đường băng cũng thay đổi theo thời gian, kèm tài liệu wiki liên kết Wikipedia về Runway
Có ý kiến cho rằng những danh sách kiểu này sẽ luôn hữu ích hơn nhiều nếu có giải thích chi tiết hơn. Tuy vậy, trong các nguồn được liên kết vẫn có khá nhiều thông tin thú vị, chẳng hạn trường hợp miệng núi lửa trên sao Hỏa được gán mã sân bay ICAO (JZRO) liên kết Wikipedia về miệng núi lửa Jezero, ví dụ chuyến bay cất cánh bình thường nhưng hạ cánh chậm 40 giờ
Đặt câu hỏi rằng tổ hợp nhà sản xuất - kiểu loại - số sê-ri có vẻ quá hiển nhiên, vậy mà làm sao lại được cấp bằng sáng chế, và liệu hiện giờ có ai đang kiếm lợi từ bằng sáng chế đó hay không
Từ kinh nghiệm phát triển phần mềm phân tích dữ liệu bay, chia sẻ nỗi khổ của lập trình viên thực tế khi trực thăng và máy bay đều có thể cất/hạ cánh ở đủ loại nơi như bệnh viện, mái nhà, bãi đỗ xe, sân thể thao, sân bay, sân golf..., nên phần lớn thời gian phải sống giữa “muôn kiểu điều sai về hàng không”
Mỗi khi đọc loạt bài "Falsehoods...", có người thấy thú vị ở chỗ rất nhiều lập trình viên rơi vào ảo tưởng rằng các hệ thống xoay quanh con người sẽ tuân theo những quy tắc nghiêm ngặt
Thừa nhận rằng lập trình viên thích quy mọi thứ về một hệ thống quy tắc chặt chẽ, nhưng thế giới thực thì không như vậy
Phân tích rằng bản chất của nghề lập trình chính là làm giao diện giữa các hệ thống con người linh hoạt và các cỗ máy vận hành bằng quy tắc cứng nhắc
Chia sẻ thế tiến thoái lưỡng nan và sự hỗn loạn mà lập trình viên gặp phải khi mô hình hóa thế giới thành phần mềm: nhiều giả định tưởng là hiển nhiên nhưng thực tế lại hoàn toàn không đúng. Ví dụ, người ta dễ mặc định rằng chuyến bay đương nhiên phải có sân bay khởi hành và sân bay đến, nhưng ngoài đời không phải lúc nào cũng vậy
Lập luận rằng do bản chất của phần mềm, việc mô hình hóa miền nghiệp vụ bắt buộc phải tạo thành một tập quy tắc. Nếu không có quy tắc thì sẽ không thể cung cấp bất kỳ chức năng nào. Vì những ngoại lệ như 'leap second' khi giải thích cho người bình thường rất dễ bị xem là nói nhảm, nên đôi khi chính lập trình viên lại là nhóm ý thức rõ hơn về các ngoại lệ và độ phức tạp của thế giới
Đề xuất cách tiếp cận loạt "Falsehoods Programmers Believe..." bằng cách xem từng mục như một test case. Có thể mở rộng chúng thành các bài test unit/integration để kiểm chứng những giả định sai đã bị cài cắm trong chương trình
Nhắc đến việc trong quá khứ, hệ thống hàng không ở Brazil từng mặc định tuyệt đối rằng “chuyến bay cất/hạ cánh ở sân bay”, và có trường hợp đã phải vá tạm để xử lý. Đồng thời phê phán rằng giả định “sân bay/đường băng không thay đổi vị trí hay hướng” cũng bị sai quá thường xuyên. Có người còn đề xuất phải thêm cả giả định “máy bay chỉ hạ cánh ở đường băng hoặc bãi đáp trực thăng”
Chia sẻ video của CGP Grey tóm tắt rất hay về quá trình lộn xộn của mã sân bay liên kết YouTube. Video cũng giải thích cả những đặc thù riêng của hệ thống
Giới thiệu thêm một cuộc thảo luận trên diễn đàn FlightAware về cùng chủ đề liên kết diễn đàn FlightAware
Từ góc nhìn của một lập trình viên, có người chia sẻ cảm giác như đầu óc nổ tung khi nhận ra rằng mình từng nghĩ mọi giả định trong danh sách này đều hợp lý, rồi muộn màng và đau đớn mới hiểu ra thực tế. Đồng thời khen đây là một bản tổng kết xuất sắc