ความเชื่อผิด ๆ เกี่ยวกับวงการการบินที่โปรแกรมเมอร์มักเชื่อ

• ข้อมูลการบิน มีความซับซ้อนและมีลักษณะที่ไม่เป็นมาตรฐานอยู่มาก
• นักพัฒนามักตั้งสมมติฐานที่ผิดเกี่ยวกับ เที่ยวบิน สนามบิน การนำร่อง และข้อมูลทรานสปอนเดอร์
• ในความเป็นจริง ระบบติดตามเที่ยวบิน ต้องรับมือกับกรณียกเว้นและความผิดปกติของข้อมูลที่หลากหลายได้อย่างยืดหยุ่น
• ความเข้าใจผิดจำนวนมากก่อให้เกิด ข้อผิดพลาดที่ไม่คาดคิด ในซอฟต์แวร์หรือระบบของลูกค้า
• เมื่อต้องออกแบบข้อมูล จำเป็นต้องมีมุมมองที่สะท้อน ความซับซ้อนของโลกความจริง อย่างรอบคอบ

---

ภาพรวม

FlightAware เป็นบริษัทที่พัฒนาซอฟต์แวร์สำหรับประมวลผลและเผยแพร่ข้อมูลการบินทั่วโลก อย่างไรก็ตาม ข้อมูลการบินจริงนั้นต่างจากที่หลายคนคาดไว้ เพราะ ไม่ได้มีโครงสร้างตายตัว และเต็มไปด้วยข้อยกเว้นกับความผิดปกติ นักพัฒนาจำนวนมากมักตั้งสมมติฐานเกี่ยวกับโครงสร้างข้อมูล การไหลของข้อมูล หรือระบบการระบุเอกลักษณ์ต่าง ๆ แต่ในโลกจริงสมมติฐานเหล่านี้กลับกลายเป็นความเข้าใจที่ผิด และก่อให้เกิด ข้อผิดพลาดและความไม่สอดคล้องของระบบ บทความนี้เป็นส่วนต่อเนื่องของซีรีส์ว่าด้วยความเชื่อผิด ๆ โดยสรุปความเข้าใจผิดที่เกิดขึ้นบ่อยในซอฟต์แวร์ของอุตสาหกรรมการบิน และกรณีที่เกิดขึ้นตามมาจากความเข้าใจเหล่านั้น

Flights (ข้อมูลเที่ยวบิน)

• มี ความเข้าใจผิดว่าเที่ยวบินจะออกจากเกตเสมอ แต่ในความเป็นจริงอาจมีการย้ายเกตหลายครั้ง หรือออกช้าหรือเร็วกว่าแผนอย่างมาก
• หลายคนมักคิดว่า ตารางเที่ยวบิน หรือสนามบินต้นทาง-ปลายทางจะชัดเจนแน่นอน แต่ในความเป็นจริงมีกรณีอย่างเฮลิคอปเตอร์หรือเครื่องบินทหารที่ขึ้นลงในสถานที่ที่ไม่ใช่สนามบิน
• เวลาเดินทางหรือกำหนดการบินอาจดูเหมือนควรเป็นแบบแผนสม่ำเสมอ แต่ในความจริงก็มีทั้งเที่ยวบินระยะยาวที่กินเวลาหลายวัน และการปฏิบัติการบินแบบผิดปกติอยู่บ่อยครั้ง
• มักมีการสมมติว่า หมายเลขระบุเที่ยวบิน (เช่น UAL1234) เป็นค่าไม่ซ้ำกัน แต่ในความจริงเครื่องบินลำหนึ่งอาจมีตัวระบุหรือหมายเลขหลายแบบ และหมายเลขเดียวกันก็อาจถูกใช้ในหลายบริบท
• แม้จะเป็นหมายเลขเดียวกันในเชิงการแสดงผล แต่ก็อาจปะปนกันระหว่างตัวระบุเที่ยวบิน เลขทะเบียน หรือเครื่องหมายอื่น ๆ จนทำให้เกิดความสับสน และ ตั๋ว ระบบควบคุมการจราจรทางอากาศ และนักบิน ก็อาจใช้ข้อมูลระบุตัวตนคนละแบบกัน

Airports (ข้อมูลสนามบิน)

• อาจคิดว่า ตำแหน่งและรหัสระบุของสนามบิน เป็นสิ่งคงที่ แต่ในความเป็นจริงสนามบินอาจถูกปิด ย้าย หรือรวมเข้าด้วยกัน ทำให้ตำแหน่งหรือรหัสเปลี่ยนแปลงได้
• ระบบการตั้งชื่อของเทอร์มินัล/เกต หมายเลขรันเวย์ และองค์ประกอบอื่น ๆ ก็ไม่ได้สม่ำเสมอ และมีข้อยกเว้นตามกฎจำนวนมาก
• แม้แต่ระบบรหัส ICAO/IATA ก็มีหลายกรณีที่ไม่ตรงกับสิ่งที่คนทั่วไปคาด เช่น การซ้ำกัน การมีหลายรหัส หรือความเข้าใจผิดเกี่ยวกับรหัสสถานที่
• การมีข้อมูลระบุบางอย่าง (เช่น รหัส IATA) ไม่ได้หมายความว่าจะเป็นสนามบินจริงเสมอไป เพราะมีกรณีที่สถานีรถไฟหรือสถานีขนส่งรถบัสได้รับรหัส IATA เช่นกัน
• ยิ่งไปกว่านั้น รหัส ICAO บางรายการยังถูกกำหนดให้กับสถานที่ที่ไม่ได้อยู่บนโลกด้วยซ้ำ (เช่น หลุมอุกกาบาตนอกโลก)

Airlines (ข้อมูลสายการบิน)

• เนื่องจากไม่มีการกล่าวถึงความเชื่อผิด ๆ แบบเฉพาะเจาะจงไว้ในบรรทัดแยกต่างหาก จึงละไว้

Navigation (ข้อมูลการนำร่องและเส้นทางบิน)

• มี ความเข้าใจผิดว่าชื่อเวย์พอยต์ จะต้องไม่ซ้ำกัน แต่ในความเป็นจริงมีชื่อซ้ำอยู่
• คำจำกัดความของ ระดับความสูง ที่ใช้ในการบินไม่ได้มีมาตรฐานเดียวตายตัว และอาจตีความต่างกันตามเกณฑ์หลายแบบ
• อาจคิดว่า ข้อมูลควบคุมการจราจรทางอากาศ ถูกต้องสมบูรณ์แบบ แต่ในความเป็นจริงข้อผิดพลาดหรือการเปลี่ยนแปลงเกิดขึ้นบ่อย
• การยกเลิกแผนการบิน การเปลี่ยนแปลงแผน ฯลฯ อาจไม่ถูกสะท้อนในเที่ยวบินจริง หรือเที่ยวบินเดียวกันอาจเปลี่ยนจุดหมายหลายครั้ง
• ยังมีกรณี เรดาร์ ความไม่สอดคล้องของข้อมูลระหว่างหน่วยงานควบคุมการจราจรทางอากาศ หรือความคลาดเคลื่อนของตำแหน่งจากการสังเกตพร้อมกัน

Transponders and ADS-B (ข้อมูลเกี่ยวกับทรานสปอนเดอร์และ ADS-B)

• มักมีการสมมติว่า สัญญาณ ADS-B ถูกส่งจากเครื่องบินเท่านั้น แต่ในความเป็นจริงรถภาคพื้นสนามบินหรืออุปกรณ์อื่นก็อาจส่งสัญญาณได้
• การเชื่อมั่นมากเกินไปในความแม่นยำของพิกัด GPS และความน่าเชื่อถือของสัญญาณก็เป็นความเข้าใจผิดเช่นกัน
• ข้อผิดพลาดหรือความซ้ำซ้อนในข้อมูลลงทะเบียนทรานสปอนเดอร์ (หมายเลขระบุ, ที่อยู่โหมด S ฯลฯ) การขาดการบำรุงรักษา และความผิดพลาดของรูปแบบข้อมูล ทำให้เกิด ความไม่สอดคล้อง ระหว่างข้อมูลเรียลไทม์กับข้อมูลจริงอยู่บ่อยครั้ง
• หลายคนอาจคิดว่า ข้อมูล ADS-B จะถูกรับและจัดเก็บไว้ตามที่ส่งมาทันที แต่ในความจริงมีปัญหาหลากหลาย เช่น ข้อผิดพลาดในการส่งหรือการปลอมแปลงสัญญาณ
• อุปกรณ์ขัดข้อง การดูแลจัดการที่หละหลวม และปัจจัยภายนอก (เช่น หนูกัดสายเคเบิลเสียหาย) ก็เป็นตัวแปรในโลกจริงเช่นกัน

สรุป

รายการนี้แสดงให้เห็นถึงความซับซ้อนของความน่าเชื่อถือของข้อมูลการบิน โดยอ้างอิงจากประสบการณ์และอินไซต์ที่ทีมพัฒนา FlightAware และ Hyperfeed สั่งสมมาจากกรณีจริงจำนวนมากตลอดหลายปีที่ผ่านมา พร้อมเน้นย้ำถึงความสำคัญของการสร้างแบบจำลองข้อมูลและการปฏิบัติการที่คำนึงถึงกรณียกเว้นที่มีอยู่จริงอย่างเคร่งครัด เพื่อลดข้อผิดพลาดและความเข้าใจผิดต่าง ๆ

[ifmkl]

มาตรฐานข้อมูลนี่แหละ...สำคัญ..ฮ่าๆ

[ryj0902]

เนื้อหาสั้นมากจริง ๆ แต่มีอารมณ์แฝงอยู่;;

[aliveornot]

แค่อ่านก็ความดันขึ้นแล้ว 555

[GN⁺]

ความคิดเห็นจาก Hacker News

• มีการอธิบายสถานการณ์ที่เครื่องบินไม่มีตัวระบุเอกลักษณ์เพียงตัวเดียวที่คงเดิมตลอดเวลา แต่ละลำมีหมายเลขซีเรียลก็จริง ทว่าเพียงเท่านี้ยังไม่สามารถรับประกันความเป็นเอกลักษณ์ได้ พร้อมแบ่งปันประสบการณ์จริงว่า ชุดค่าผสม "ผู้ผลิต, รุ่น, หมายเลขซีเรียล" นั้นพอจะเป็นตัวระบุเอกลักษณ์ตลอดอายุการใช้งานได้ แต่หากตัวเครื่องเปลี่ยนประเภทจากการดัดแปลงโครงสร้าง แม้แต่ค่านี้ก็อาจเปลี่ยนได้ด้วย และยังเสริมความเห็นส่วนตัวว่ารู้สึกน่าทึ่งที่ระบบขนาดใหญ่และซับซ้อนอย่างการบินกลับไม่มีตัวระบุที่ไม่เปลี่ยนแปลง หมายเลขทะเบียนอากาศยาน (tail number) เปลี่ยนได้เหมือนป้ายทะเบียนรถยนต์ และตัวระบุ 24 บิตของ ICAO ก็ผูกกับอุปกรณ์ ADS-B จึงย้ายหรือเปลี่ยนได้อย่างอิสระ

  • แสดงความสงสัยว่าการใช้ชุด "ผู้ผลิต, รุ่น, หมายเลขซีเรียล" กลับเคยถูกจดสิทธิบัตรได้อย่างไร และอยากรู้ว่าอะไรทำให้สิ่งนี้ถูกมองว่าใหม่พอจะได้รับสิทธิบัตร

  • เชื่อมโยงประเด็นนี้กับปริศนา "เรือของเธเซอุส" เพื่อชวนคิดเชิงปรัชญาเรื่องอัตลักษณ์ของเครื่องบินและการเปลี่ยนแปลงของตัวระบุ ลิงก์วิกิพีเดีย Ship of Theseus

  • แบ่งปันภูมิหลังทางประวัติศาสตร์ว่าอุตสาหกรรมการบินพัฒนาแบบแยกส่วนตามแต่ละประเทศ ทำให้การทำมาตรฐานล่าช้า และมองว่าแค่การมีมาตรฐานระดับโลกที่ใช้ได้จริงทุกวันนี้ก็น่าทึ่งมากแล้ว พร้อมวิเคราะห์ว่าสถานการณ์นี้พอเป็นไปได้ก็เพราะปัจจุบันผู้ผลิตรายใหญ่ถูกรวมเหลือไม่กี่ราย

  • แบ่งปันประสบการณ์หน้างานว่าปัญหาเรื่องตัวระบุเอกลักษณ์ที่ “แท้จริง” โผล่ขึ้นมาบ่อยมากในโลกจริง วิธีแก้แทบจะเป็นชุด “รุ่น, ผู้ผลิต, หมายเลขซีเรียล” เสมอ และถ้าจำเป็นก็เพิ่มปีที่ผลิตเข้าไปด้วย แม้แต่ข้อมูลมนุษย์ก็ยังเคยต้องลอง de-duplication โดยใช้เกณฑ์อย่างภาษาแม่

  • ยกตัวอย่างว่าหมายเลขรันเวย์ก็เปลี่ยนได้ตามกาลเวลาเช่นกัน พร้อมแชร์เอกสารวิกิ ลิงก์วิกิพีเดีย Runway

• มีความเห็นว่ารายการแบบนี้จะมีประโยชน์กว่ามากเสมอถ้ามีคำอธิบายที่ละเอียดกว่านี้ติดมาด้วย แต่ข้อมูลในแหล่งอ้างอิงที่ลิงก์ไว้หลายส่วนก็มีประโยชน์มาก เช่น กรณีที่หลุมอุกกาบาตบนดาวอังคารได้รับรหัสสนามบิน ICAO (JZRO) ลิงก์วิกิพีเดียหลุมอุกกาบาต Jezero, ตัวอย่างเที่ยวบินที่ออกเดินทางตามปกติแต่ลงจอดช้ากว่าเดิม 40 ชั่วโมง

  • ชี้ว่าหลายกรณีในรายการจริง ๆ แล้วมีเหตุผลที่ธรรมดาจนน่าเบื่อ เช่น เที่ยวบินยาว 2 สัปดาห์คือ Google Balloon, การล่าช้า 40 ชั่วโมงก็แค่สภาพอากาศเลวร้าย และค่า ADS-B นั้นนักบินเป็นผู้กรอกซึ่งมักใส่ผิดได้บ่อย

• ตั้งข้อสงสัยอีกครั้งว่าชุดผู้ผลิต-รุ่น-หมายเลขซีเรียลนั้นดูเป็นเรื่อง очевидent มาก แล้วมันผ่านการจดสิทธิบัตรได้อย่างไร และทุกวันนี้ยังมีใครหากำไรจากสิทธิบัตรนี้อยู่หรือไม่

• จากประสบการณ์พัฒนาซอฟต์แวร์วิเคราะห์ข้อมูลการบิน มีการเล่าว่าเฮลิคอปเตอร์และเครื่องบินขึ้นลงได้จากหลายสถานที่มาก ทั้งโรงพยาบาล ดาดฟ้า ลานจอดรถ สนามกีฬา สนามบิน สนามกอล์ฟ ฯลฯ จนทำให้นักพัฒนาต้องใช้เวลาส่วนใหญ่อยู่กับ “คำโกหกสารพัดเกี่ยวกับการบิน”

• มีมุมมองว่าสิ่งที่น่าสนใจทุกครั้งเวลาอ่านซีรีส์บทความ "Falsehoods..." คือการที่นักพัฒนาจำนวนมากมักเผลอเชื่อว่าระบบที่มนุษย์เป็นศูนย์กลางจะต้องดำเนินตามกฎที่เข้มงวดเสมอ

  • ยอมรับว่านักพัฒนาชอบลดทอนทุกอย่างให้เป็นระบบกฎที่เคร่งครัด แต่โลกจริงไม่ได้เป็นเช่นนั้น

  • วิเคราะห์ว่างานเขียนโปรแกรมโดยเนื้อแท้แล้วคือการเป็นตัวเชื่อมระหว่างระบบมนุษย์ที่ยืดหยุ่นกับเครื่องจักรที่ทำงานตามกฎอย่างเข้มงวด

  • แบ่งปันภาวะกลืนไม่เข้าคายไม่ออกและความสับสนที่โปรแกรมเมอร์พบเจอเมื่อสร้างแบบจำลองโลกเป็นซอฟต์แวร์ โดยมักคิดว่าสมมติฐานบางอย่างควรเป็นจริง ทั้งที่ในความเป็นจริงกลับไม่ใช่เลย เช่น การสมมติว่าเที่ยวบินย่อมต้องมีสนามบินต้นทางและปลายทาง

  • ยืนยันว่าโดยธรรมชาติของซอฟต์แวร์แล้ว การทำ domain modeling จำเป็นต้องสร้างออกมาเป็นชุดกฎ ไม่เช่นนั้นก็ไม่อาจให้ฟังก์ชันอะไรได้เลย อีกทั้งหากอธิบายข้อยกเว้นอย่าง "leap second" ให้คนทั่วไปฟัง ก็มักถูกเข้าใจว่าเป็นเรื่องเหลวไหลเสียด้วยซ้ำ จึงมองว่าหลายครั้งนักพัฒนากลับเป็นฝ่ายที่ตระหนักถึงข้อยกเว้นและความซับซ้อนของโลกได้ดี

• มีการเสนอวิธีมองแต่ละข้อในซีรีส์ "Falsehoods Programmers Believe..." ให้เป็น test case ซึ่งสามารถขยายเป็น unit/integration test เพื่อตรวจสอบสมมติฐานผิด ๆ ที่ฝังอยู่ในโปรแกรมได้

  • เล่าว่าในทางปฏิบัติเคยมีการสร้างเทสต์ตามแต่ละข้อจริง และตอนทำงานอยู่มีเทสต์มากกว่าพันรายการ ตั้งแต่เรื่องในชีวิตประจำวันไปจนถึงกรณีสุดขั้ว พร้อมรำลึกว่าทีมนั้นให้คุณค่ากับคุณภาพและวิศวกรรมอย่างมาก

• มีการกล่าวถึงว่าข้อสมมติ "เที่ยวบินขึ้น/ลงที่สนามบิน" เคยถูกฝังแบบตายตัวในระบบการบินเก่าของบราซิล และมีกรณีที่ต้องแก้แบบเฉพาะหน้า อีกทั้งยังวิจารณ์ว่าแนวคิดว่า "สนามบิน/รันเวย์จะไม่เปลี่ยนตำแหน่งหรือทิศทาง" ก็เป็นสมมติฐานที่มักผิดบ่อยเกินไป และเสนอว่าควรต้องเพิ่มสมมติฐานอีกข้อว่า "อากาศยานลงจอดได้เฉพาะบนรันเวย์หรือเฮลิพอร์ต"

  • มีคนถามว่าอยากรู้รายละเอียดมากขึ้นว่าระบบการบินเก่าในบราซิลจัดการปัญหาเหล่านี้แบบแก้ขัดอย่างไร

• แชร์วิดีโอของ CGP Grey ที่สรุปความยุ่งเหยิงของรหัสสนามบินได้ดี พร้อมอธิบายลักษณะเฉพาะของระบบ ลิงก์ YouTube

• แนะนำการสนทนาในฟอรัม FlightAware ที่พูดถึงหัวข้อเดียวกัน ลิงก์ฟอรัม FlightAware

• มีการแบ่งปันความรู้สึกว่าในฐานะโปรแกรมเมอร์ ตอนแรกคิดว่าสมมติฐานทั้งหมดในรายการนี้ฟังดูสมเหตุสมผล แต่เมื่อค่อย ๆ ตระหนักถึงความจริงอันเจ็บปวดในภายหลัง ก็รู้สึกราวกับสมองระเบิด และชื่นชมว่านี่เป็นสรุปที่ยอดเยี่ยม