Maritime Situational Awareness ตอน 6: เราไม่ได้อยู่ตัวคนเดียวในโลกนี้ ไม่รู้ให้ถามเพื่อน

มาถึงตอนสุดท้ายของซีรีส์แล้วนะจ๊ะ พวกแกร์ ตอนที่ 5 เลาปิดท้ายไว้ว่า IORIS เป็นแค่ตัวอย่างเดียว ของจริงยังมีมาตรฐานข้อมูลที่ต้องตกลงกัน สิทธิ์ที่ต้องคุมให้ได้ ความไว้ใจที่สร้างกันเป็นสิบปี แล้วก็คำถามที่ตอบยากที่สุดข้อหนึ่งของงานสายนี้ คือให้ข้อมูลเขาไปแล้วเราได้อะไรกลับมา ตอนนี้มาเคลียร์ให้ครบทั้งสี่ข้อ

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

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

ทำไมต้องไปขอเขา — เรื่องมันไม่ได้เริ่มที่หน้าบ้านเรา ​

ก่อนจะไล่ว่าใครแลกอะไรกับใคร ขอเคลียร์คำถามที่ค้างในใจหลายคนก่อน ว่าในเมื่อ sensor ก็มี fusion ก็ทำแล้ว จะไปยุ่งกับคนอื่นทำไม คำตอบสั้นที่สุดคือความผิดทางทะเลหลายแบบ ไม่ได้เกิดในน่านน้ำเราตั้งแต่ต้น มันตั้งต้นจากอีกซีกโลกแล้วค่อยๆ ลากยาวมาจนถึงเรา ของที่โผล่บนจอเราคือฉากสุดท้ายของหนังที่ฉายมาแล้วเป็นเดือน

ขอสมมติเคสขึ้นมาเล่นๆ สักเคส ย้ำว่าสมมติล้วน ไม่ใช่เคสจริงของใคร — เรือสินค้าลำหนึ่งรับของขึ้นที่ท่าในประเทศหนึ่ง ระหว่างทางแวะจอดอีกสองสามท่า ที่ศัพท์วงการเรียกว่า port call กลางทะเลมีถ่ายของข้ามไปอีกลำหนึ่งรอบหนึ่ง แล้วยังเปลี่ยนชื่อเรือกับเปลี่ยนธงที่จดทะเบียนระหว่างทางอีกอย่างละครั้ง สุดท้ายก็มาโผล่หน้าบ้านเราพร้อมเอกสารสวยงามครบทุกใบ

ทีนี้เครื่องมือทั้งกองที่เราประกอบกันมาตั้งแต่ตอนที่ 1 ถึงตอนที่ 4 เห็นอะไรบ้าง ก็เห็นแค่ช่วงท้ายสุด ตั้งแต่วินาทีที่เรือเข้ามาในระยะเสาชายฝั่งเท่านั้นเอง ส่วนคำถามที่คนต้องตัดสินใจอยากรู้จริงๆ หน้าตาประมาณนี้ ของบนเรือมาจากไหนกันแน่ ระหว่างทางแวะที่ไหนมาบ้าง ตอนจอดอยู่ท่าโน้นมีใครขึ้นไปตรวจไหม แล้วเจออะไร

ไม่มีข้อไหนเลยที่ตอบได้ด้วยของในบ้าน เพราะคำตอบอยู่ในมือคนอื่นหมด ประวัติ port call อยู่กับรัฐท่าก่อนหน้า ผลตรวจเรืออยู่กับหน่วยที่ขึ้นไปตรวจวันนั้น track ช่วงที่เรืออยู่นอกระยะเราอยู่ในกองของประเทศที่มันแล่นผ่าน ส่วนรายงานเหตุแถวนั้นนอนอยู่ในแฟ้มของศูนย์ภูมิภาค นี่คือปัญหาชุดเดียวกับ dark activities ในตอนที่ 4 และจิ๊กซอว์ตระกูล INT ในตอนที่ 5 เป๊ะ คือชิ้นที่ขาดไปไม่ได้หายไปไหน มันแค่อยู่ในมือคนอื่น

แล้วพอเราเอ่ยปากขอ เรื่องก็ไม่จบแค่นั้น เพราะของแบบนี้มันสองทางเสมอ วันหนึ่งเขาย่อมหันมาถามเราบ้างว่าเรือลำนี้เคยเข้าท่าบ้านคุณไหม ตอนนั้นตรวจแล้วเจออะไร จอดกี่วัน ออกไปทางไหน ซึ่งแปลว่าฝั่งเราต้องเตรียมของไว้สองเรื่อง

เรื่องแรก ระบบในบ้านต้องตอบคำขอจากข้างนอกได้จริง ข้อมูลภาคสนามที่เล่าไว้ตอนที่ 5 ถ้ายังนอนเป็นกระดาษอยู่ในแฟ้มชั้นสาม คำขอที่วิ่งเข้ามาบ่ายวันนี้ก็ตอบไม่ทัน มันต้องอยู่ในรูปที่ค้นเจอและส่งต่อได้ เรื่องที่สอง ต้องคิดล่วงหน้าไว้เลยว่าจะตอบได้ลึกแค่ไหน อะไรบอกได้ อะไรบอกไม่ได้ และบอกด้วยท่าไหนถึงจะไม่เผลอแถมของแถมไปด้วย ข้อนี้ยาวพอเป็นหัวข้อของตัวเอง เดี๋ยวไปว่ากันตอนท้ายเรื่องตรง sanitize

ภาพที่ใกล้ตัวที่สุดคือระบบยืมหนังสือข้ามห้องสมุดมหาวิทยาลัย ที่ไหนก็ขอยืมเล่มที่ตัวเองไม่มีได้ แต่ต้องยอมให้คนอื่นมายืมของตัวเองด้วยเหมือนกัน ห้องสมุดที่ขอฝ่ายเดียวแล้วไม่เคยให้ใครยืมเลย ปีถัดมาก็จะพบว่าไม่มีใครรับสาย

แลกอะไรกันได้บ้าง — ไม่ได้มีแค่หมุดบนแผนที่ ​

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

• track เรือ — จาก AIS ชายฝั่ง, AIS จากดาวเทียม, LRIT หรือเรดาร์ชายฝั่ง ของชิ้นนี้คือหมุดที่เราปั้นกันมาตั้งแต่ตอนที่ 1
• รายงานเหตุ — incident report, alert, advisory ตอบว่าเกิดอะไรขึ้น ที่ไหน เมื่อไหร่ และเรือพาณิชย์ที่จะผ่านแถวนั้นควรระวังอะไร
• เรือต้องสงสัย — vessel of interest กับ watchlist อันนี้เป็นรายชื่อ ไม่ใช่ตำแหน่ง
• ไฟล์ในเคส — เอกสาร รูป วิดีโอ ที่แปะกันไว้ในห้องของเหตุการณ์นั้น
• รายงานวิเคราะห์เป็นรอบ — รายสัปดาห์ รายเดือน รายปี ไม่เร็วเลย แต่เป็นของที่เอาไปวางแผนได้
• คน — liaison officer หรือที่เรียกย่อว่า ILO คือเจ้าหน้าที่ที่ประเทศหนึ่งส่งไปนั่งประจำอยู่ในศูนย์ของอีกประเทศจริงๆ

ข้อสุดท้ายนี่แหละที่คนสายเราชอบมองข้ามที่สุด เดี๋ยวจะกลับมาขยายให้ตอนท้าย

ทีนี้ลองวางของทั้งหกกองลงบนสองแกน คือ เร็วแค่ไหน กับ ไวแค่ไหน จะเห็นอะไรบางอย่างทันที ฝั่งที่ไหลตลอดเวลาแบบ near-real-time คือ track ที่ระดับชั้นความลับต่ำสุด ถัดมาเป็นรายงานเหตุที่วัดกันเป็นนาทีถึงชั่วโมง และต้องมีคนกดอนุมัติก่อนออก ถัดไปอีกเป็นรายงานวิเคราะห์ที่ออกเป็นรอบ ส่วนปลายสุดคือเวทีระดับนโยบายที่เจอกันปีละครั้งสองครั้ง

สังเกตว่าของที่ไหลเร็วที่สุดคือของที่ไวน้อยที่สุดเสมอ อันนี้ไม่ใช่เรื่องบังเอิญ เพราะอะไรที่ต้องให้คนเซ็นอนุมัติเป็นรายครั้ง มันวิ่งแบบ streaming ไม่ได้อยู่แล้ว

MSSIS — ส่ง feed เข้าไปเส้นเดียว ได้ภาพกลับมาทั้งกอง ​

เริ่มที่ตัวที่บรีฟสั่งมาก่อนเลย MSSIS ย่อจาก Maritime Safety and Security Information System เป็นเครือข่ายแบ่งปันข้อมูลติดตามเรือระดับโลก ชั้นความลับเป็น unclassified และทำงานแบบ near-real-time พัฒนาและดูแลโดย Volpe National Transportation Systems Center ซึ่งอยู่ใต้กระทรวงคมนาคมของสหรัฐฯ หรือ USDOT

หลักการเรียบง่ายจนน่าตกใจ ประเทศสมาชิกส่ง feed ของตัวเองเข้าไป จะเป็น AIS จากสถานีชายฝั่ง เรดาร์ชายฝั่ง หรือ sensor อื่นที่ยอมแบ่งก็ได้ แล้วได้ภาพรวมที่รวมของทุกคนกลับไปใช้ ฝั่งเทคนิคเขาเอาทุกสตรีมมารวมผ่านระบบชื่อ Transview หรือ TV32 ให้ออกมาเป็นสตรีมเดียว ตัวเลขที่เขาประกาศไว้หน้าเว็บคือมีประเทศที่ใช้งานอยู่ 75 ประเทศขึ้นไป และติดตามเรือได้เกิน 70,000 ลำ อันนี้หน้าเว็บไม่ได้ระบุปีไว้ เลยอ้างตามที่เขาเขียนไว้แบบนั้น

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

นึกภาพแอปนำทางที่เราเปิดใช้ทุกเช้าก็ได้ เครื่องเราส่งตำแหน่งกับความเร็วของตัวเองเข้าไปเส้นเดียว แล้วได้แผนที่รถติดทั้งเมืองกลับมา ไม่มีใครยกสมุดบันทึกการเดินทางทั้งเล่มให้เขา แต่ผลลัพธ์ที่ได้กลับมามันมากกว่าที่ตัวเองส่งไปหลายพันเท่า โมเดลแบบ MSSIS ทำงานบนตรรกะเดียวกันเป๊ะ

ของที่เขาบอกว่าเอาไปทำต่อได้ก็ตรงไปตรงมา คือป้อนเข้าระบบ MDA ในประเทศ ใช้เป็นฐานของ VTS ระดับภูมิภาค หรือเอาไปทำสถิติและวิเคราะห์เส้นทางเดินเรือย้อนหลัง

มีข้อหนึ่งที่ต้องเตือนตัวเองไว้เสมอ ภาพที่ไหลกลับมาไม่ใช่ความจริงของทะเล มันคือ สิ่งที่สมาชิกแต่ละคนยอมส่ง ซึ่งเป็นคนละเรื่องกัน ช่องว่างบนแผนที่รวมจึงมีได้สองความหมาย คือตรงนั้นไม่มีเรือจริงๆ กับตรงนั้นไม่มีใครส่งของให้ ถ้าเอาเข้า fusion โดยไม่แยกสองอย่างนี้ออกจากกัน ระบบจะมั่นใจในที่ที่ไม่ควรมั่นใจ

IFC กับ IRIS — เอาคนมานั่งด้วยกันก่อน ระบบค่อยตามมา ​

IFC หรือ Information Fusion Centre ที่สิงคโปร์ ตั้งเมื่อ 27 เมษายน 2009 ที่ Changi C2 Centre โดยกองทัพเรือสิงคโปร์ ตัวนี้ผมเคยเล่าไว้แล้วในบทความ Maritime Domain Awareness ด้วยตัวเลขปี 2019 รอบนี้เลยขอข้ามไปที่กลไกกับของที่ใหม่กว่าแทน

ตัวเลขช่วงปี 2022 ถึง 2025 บอกว่ามี ILO ผ่านศูนย์นี้สะสมแล้วกว่า 160 นายจาก 25 ประเทศ อันนี้เป็นยอดหมุนเวียนสะสมนะครับ ไม่ใช่นั่งอยู่พร้อมกันทั้งหมด โดยครบทั้งเก้าชาติอาเซียนบวกอีกสิบสามประเทศ และตัวศูนย์เชื่อมกับศูนย์ปฏิบัติการหรือ OPCEN มากกว่า 90 แห่งใน 40 กว่าประเทศ รวมถึงฝั่งอุตสาหกรรมเดินเรือด้วย ของที่ออกจากศูนย์เป็นรายงานเหตุ คำแนะนำ fact sheet และรายงานรายสัปดาห์รายเดือน

ส่วนระบบที่คนสายเราน่าจะอยากรู้คือ IRIS ย่อจาก IFC Real-time Information-sharing System เปิดตัว 14 พฤษภาคม 2019 มันคือภาพทางทะเลสดๆ ที่หลอมมาจาก AIS, LRIT, OPCEN ของกองทัพเรือและยามฝั่งพันธมิตร หน่วยงานพลเรือน ไปจนถึงภาคเดินเรือพาณิชย์ หน้าตาเป็นแผนที่ที่ค้นหาและติดตามเป้าได้ มีเวอร์ชันมือถือ และมีห้องแชทให้แชร์เอกสาร รูป วิดีโอ กันตอนเกิดเหตุ

เห็นแชทโผล่มาเป็นฟีเจอร์เด่นอีกแล้วไหมฮะ ตอนที่แล้วผมบ่นไว้ว่าฟีเจอร์แรกในลิสต์ของ IORIS คือแชทไม่ใช่แผนที่ พอมาดู IRIS ก็เรื่องเดียวกันอีก ของที่คนทำงานจริงต้องการตอนมีเหตุคือช่องทางคุยกับคนอีกฝั่งที่ถือข้อมูลอีกครึ่งหนึ่ง แผนที่เป็นแค่ของที่เอาไว้ชี้ประกอบ

ที่เจ๋งกว่านั้นคือเขาเอา IRIS ไปใช้ในการฝึกจริง อย่างการฝึกระดับภูมิภาคที่ชื่อ MARISX กับ SEACAT ศูนย์ปฏิบัติการของประเทศอื่นเข้าร่วมผ่าน IRIS จากที่ตั้งตัวเองได้เลย ไม่ต้องบินไปนั่งในห้องเดียวกัน อันนี้คือการทดสอบระบบที่ตรงกับชีวิตจริงที่สุด เพราะวันเกิดเหตุจริงก็ไม่มีใครได้บินไปไหนเหมือนกัน

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

ฝั่งมหาสมุทรอินเดียมีศูนย์พี่น้องกันชื่อ IFC-IOR ตั้งเมื่อ 22 ธันวาคม 2018 ที่เมือง Gurugram โดยกองทัพเรืออินเดีย ดูแลพื้นที่ตั้งแต่ช่องแคบมะละกายาวไปถึงสุเอซ มี ILO จากประเทศพันธมิตรราวสิบห้าประเทศ ซึ่งบ้านเราอยู่ในรายชื่อนั้นด้วย โดยมีข่าวเปิดว่าส่ง ILO ไปประจำเมื่อปี 2024

สังเกตแพตเทิร์นของสองศูนย์นี้ไหมครับ ทั้งคู่ไม่ได้เริ่มจากการเขียน interface spec แล้วประกาศให้ทุกคนมาต่อ แต่เริ่มจากหาที่ให้คนมานั่งด้วยกันก่อน ระบบเป็นของที่งอกตามมาทีหลัง ซึ่งตรงข้ามกับวิธีที่พวกเราถูกฝึกมาแบบสุดขั้ว

ReCAAP — ช้ากว่า real-time หลายขุม แต่เปลี่ยนเส้นทางเรือได้จริง ​

ReCAAP คือความตกลงระดับภูมิภาคว่าด้วยการต่อต้านโจรสลัดและการปล้นเรือในเอเชีย มีผลบังคับใช้เมื่อปี 2006 เริ่มจาก 14 ประเทศ ปัจจุบันเป็น 21 ประเทศ บ้านเราเป็นภาคีอยู่ด้วย และปี 2026 นี้ก็ครบรอบ 20 ปีพอดี ส่วนตัวเลขเหตุการณ์ปี 2024 ผมเล่าไว้ในบทความ MDA แล้ว รอบนี้เอาของใหม่กว่า คือปี 2025 มีรายงานเหตุรวม 132 เหตุ ซึ่งเทียบกับปีก่อนหน้าแล้วเส้นกราฟไม่ได้ลง

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

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

เทียบกับของใกล้ตัวก็เหมือน status page กับ incident report ของบริษัทซอฟต์แวร์ เขาไม่ได้สตรีม metric ทุกวินาทีให้ลูกค้าดู แต่พอมีเหตุ ประกาศมันโผล่ในนาทีนั้น แล้วปลายเดือนมีสรุปให้อ่านว่าล่มกี่ครั้งเพราะอะไร ช้ากว่ากราฟสดเยอะ แต่เป็นของที่เอาไปตัดสินใจได้จริง

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

ยังมีอีกกอง — LRIT, IPMDA และเวทีที่ไม่มี feed สักเส้น ​

LRIT ย่อจาก Long-Range Identification and Tracking เป็นของ IMO ตามอนุสัญญา SOLAS ข้อ V/19-1 เรือที่เข้าข่ายต้องส่งตำแหน่งตัวเองทุก 6 ชั่วโมงผ่านดาวเทียมเข้า Data Centre ของรัฐธง จะเป็นศูนย์ระดับชาติ ระดับภูมิภาค หรือศูนย์ร่วมก็ได้

จุดที่ต่างจาก AIS แบบคนละขั้วคือ AIS เป็น broadcast ใครมีเครื่องรับก็ฟังได้ เรื่องนี้ผมเล่าไว้ยาวในตอนที่ 1 แต่ LRIT เป็น request และ response ที่มีเจ้าของข้อมูลชัดเจน รัฐภาคีกับหน่วยค้นหาช่วยเหลือขอดูข้อมูลเรือลำอื่นได้ตามสิทธิ์ที่มีเท่านั้น คือเป็นรัฐธงของเรือลำนั้น เป็นรัฐท่าที่เรือกำลังจะเข้า หรือเป็นรัฐชายฝั่งเมื่อเรืออยู่ในระยะ 1,000 ไมล์ทะเล คำขอวิ่งผ่านตัวกลางชื่อ International Data Exchange หรือ IDE และสิทธิ์ทั้งหมดถูกเขียนไว้ในเอกสารที่เรียกว่า Data Distribution Plan

อ่านแล้วคุ้นไหมล่ะ มันคือ API ที่มี scope กับ policy engine ยืนอยู่ข้างหน้านั่นเอง ต่างกันแค่ policy ถูกเขียนเป็นข้อตกลงระหว่างรัฐ ไม่ใช่ไฟล์ YAML ในรีโปที่เราแก้เองได้ตอนบ่ายสาม

IPMDA ย่อจาก Indo-Pacific Partnership for Maritime Domain Awareness ประกาศเมื่อปี 2022 โดยกลุ่ม Quad คือสหรัฐฯ ออสเตรเลีย อินเดีย และญี่ปุ่น ลงขันกันเกิน 120 ล้านดอลลาร์ แนวคิดคือซื้อข้อมูลติดตามเรือจากดาวเทียมพาณิชย์ ทั้งแบบ RF และ AIS จากวงโคจรที่เล่าไว้ตอนที่ 4 แล้วส่งต่อให้ภูมิภาคผ่าน hub สามแห่ง คือ IFC-IOR ที่อินเดีย IFC ที่สิงคโปร์ และ FFA ที่หมู่เกาะแปซิฟิก ประเทศในภูมิภาคอย่างบ้านเรารับภาพผ่าน hub พวกนี้ ไม่ได้ต่อตรงกับโครงการ

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

ปิดท้ายด้วยของอีกแบบที่หน้าตาไม่เหมือนชาวบ้าน HACGAM ย่อจาก Heads of Asian Coast Guard Agencies Meeting ตั้งเมื่อปี 2004 มีสมาชิก 20 กว่าประเทศและเขตเศรษฐกิจทั่วเอเชีย บ้านเราเป็นสมาชิกด้วย และยังมี ASEAN Coast Guard Forum หรือย่อว่า ACF ที่บ้านเราร่วมเหมือนกัน

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

เทียบกับงานเราก็ประมาณว่าเวทีพวกนี้คือที่ที่ตกลง convention กัน ส่วน feed คือโค้ดที่รันจริง ถ้าข้ามเวทีแรกไป โค้ดฝั่งเราก็จะ implement ของที่อีกฝั่งไม่ยอมรับอยู่ดี แล้วมารู้ตัวตอนวันเดโม

มุมคนทำระบบ — จะต่อกับเขาจริงๆ ต้องทำอะไรบ้าง ​

ทีนี้มาถึงหัวใจของตอนนี้ สมมติวันดีคืนดีมีคนเดินมาบอกที่โต๊ะว่าเราจะเชื่อมกับศูนย์นั้นศูนย์นี้นะ งานที่ตกมาถึงมือคนทำระบบจริงๆ มีประมาณนี้

หนึ่ง ตกลงกันก่อนว่าจะพูดภาษาอะไร ฟังดูเป็นงานง่ายสุดในลิสต์ แต่กินเวลานานสุดเสมอ ต้องเคลียร์ว่า timestamp เป็น UTC ทุกช่องไหม ใช้ระบบพิกัดเดียวกันหรือเปล่า ความเร็วเป็น knot หรือ m/s รหัสประเภทเรือของสองฝั่งแปลงไปมายังไง และข้อที่คนลืมบ่อยสุดคือ ค่าว่างแปลว่าอะไร เพราะฝั่งหนึ่ง null อาจแปลว่าไม่มีข้อมูล ส่วนอีกฝั่งอาจแปลว่าศูนย์ พอเอามาหลอมกันโดยไม่ถามข้อนี้ เรือทุกลำที่ไม่รู้ความเร็วจะกลายเป็นเรือจอดนิ่งทันที

สอง เปลี่ยนโหมดคิดจาก need-to-know เป็น need-to-share สองคำนี้ต่างกันที่ค่าเริ่มต้น แบบแรกตั้งต้นว่าปิดไว้ก่อน ใครอยากได้ต้องพิสูจน์ก่อนว่าทำไมถึงต้องรู้ แบบหลังตั้งต้นว่าของชิ้นนี้ควรถึงมือใครบ้างงานถึงจะเดิน แล้วค่อยหาเหตุผลว่าทำไมถึงไม่ให้ ในทางปฏิบัติไม่มีใครเลือกข้างใดข้างหนึ่งสุดทาง สิ่งที่ทำได้จริงคือซอยข้อมูลเป็นชั้นแล้วตั้งค่าเริ่มต้นคนละแบบในแต่ละชั้น ตำแหน่งเรือพาณิชย์กับผลวิเคราะห์เชิงลึกไม่ควรใช้กฎเดียวกันอยู่แล้ว

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

ท่าที่ใช้กันก็มีไม่กี่ท่า

• ตัด field ที่บอกที่มาทิ้งก่อนส่ง
• ลดความละเอียดลง ทั้งปัดตำแหน่ง ลดความถี่การอัปเดต หรือหน่วงเวลาให้ช้าลงนิดหน่อย
• ส่งเฉพาะผลลัพธ์ที่หลอมแล้ว ไม่ส่ง detection ดิบจาก sensor ตัวใดตัวหนึ่ง
• ติดป้ายสิทธิ์กำกับทุกระเบียนว่าใครส่งต่อได้ถึงไหน

หน้าตาของสิ่งที่เกิดขึ้นก่อนกับหลังผ่านขั้นนี้ ย่อให้สั้นที่สุดก็ประมาณนี้

ในบ้าน : track_id, lat, lon, time, source=coastal_radar_07, accuracy_m=25, update_rate_s=2, conf=0.91
ส่งออก : track_id, lat, lon, time, source=national_system, releasable_to=PARTNER-A, conf=high

ความยากไม่ได้อยู่ที่การเขียนฟังก์ชันตัด field นะครับ อันนั้นเด็กฝึกงานก็เขียนได้ในสิบนาที ความยากอยู่ที่ว่าใครเป็นคนตัดสินว่าอะไรตัดได้บ้าง และคำตอบนั้นเปลี่ยนไปตามประเทศปลายทาง ตามภารกิจ และบางทีก็ตามสถานการณ์ของสัปดาห์นั้น แปลว่ากฎชุดนี้ต้องอยู่ในที่ที่แก้ได้โดยไม่ต้อง deploy ใหม่ ไม่ใช่ if-else ที่ฝังแน่นอยู่กลางโค้ด

สี่ ป้ายสิทธิ์ต้องติดไปกับข้อมูล ไม่ใช่นอนอยู่ในเอกสาร Data Distribution Plan ของ LRIT เป็นตัวอย่างที่ดีมากของการเขียนสิทธิ์ให้ชัดตั้งแต่ระดับข้อตกลง แต่ถ้าฝั่ง implement ปล่อยให้สิทธิ์อยู่แค่ในไฟล์ PDF ที่ไม่มีใครเปิด สุดท้ายก็จะมีคน copy ข้อมูลออกไปใช้ต่อโดยไม่รู้ตัวว่าผิดเงื่อนไข ป้ายต้องติดอยู่กับทุกแถว ระบบปลายทางถึงจะบังคับใช้ให้ได้

ห้า ขาออกต้อง audit ได้เท่ากับขาเข้า เราทุ่มเวลาให้ pipeline ขาเข้ากันเยอะมาก แต่วันที่มีคนถามว่าข้อมูลชุดนี้ไปถึงมือใครแล้วบ้างเมื่อไหร่ ถ้าคำตอบคือขอไปไล่หาในเมลเก่าก่อน ก็จบเห่ ต้องมี log ที่ตอบได้ในนาทีนั้น

หก ILO คือ API ที่เป็นคน กลับมาที่ข้อสุดท้ายของรายการประเภทข้อมูลตอนต้นเรื่อง ลองมองเจ้าหน้าที่ติดต่อหนึ่งคนเป็น endpoint ดูสิ มันเป็น endpoint เดียวที่รู้ว่าฝั่งบ้านตัวเองเก็บอะไรไว้ตรงไหน รู้ว่าอะไรปล่อยได้อะไรปล่อยไม่ได้โดยไม่ต้องเปิดคู่มือ และต่อรองได้ ซึ่งไม่มี REST endpoint ตัวไหนในโลกทำสามอย่างนี้พร้อมกันได้

แน่นอนว่าคุณสมบัติอื่นแย่กว่าเครื่องทุกประตู เพราะ deploy ด้วยตั๋วเครื่องบิน uptime ผูกกับตารางเวร และ rate limit คือจำนวนชั่วโมงที่มีในหนึ่งวัน แต่ latency ของการขอของที่ยังไม่มีใน spec ต่ำที่สุดในบรรดา interface ทุกแบบที่มีอยู่ ถ้าระบบเราออกแบบมาดี ILO ควรมีเครื่องมือที่ทำให้หาของเจอเร็วขึ้น ไม่ใช่ต้องโทรกลับมาหาทีมเราทุกครั้งที่มีคำถาม

ของที่ไหลกลับเข้ามาก็ไม่ได้เสียบใช้ได้เลยนะ มันต้องไปต่อคิวใน pipeline เดิมที่เราสร้างกันไว้ตั้งแต่ตอนที่ 3 เป๊ะๆ คือหลอมเข้ากับ track ที่มีอยู่ จับคู่ด้วยเวลาและพื้นที่ แล้วเก็บไว้ด้วยว่าค่านี้ใครเป็นคนบอก เพราะพอ track เดียวกันมีสองเวอร์ชันจากสองแหล่งแล้วค่าไม่ตรงกัน คำถามแรกที่ทุกคนในห้องจะถามคือของใครถูก ซึ่งตอบไม่ได้เลยถ้าไม่ได้เก็บที่มาไว้ตั้งแต่แรก กฎข้อ "เก็บว่าใครบอก ไม่ใช่แค่บอกว่าอะไร" จากตอนที่แล้ว ใช้กับข้อมูลข้ามประเทศได้ตรงตัวที่สุด

ส่วนคำถามที่ว่าของข้างนอกมันชนกับของในบ้านยังไง ขอเล่าเป็นภาพทั่วไปของงาน integration นะ ไม่ใช่เคสจริงของที่ไหนทั้งนั้น อาการที่คนทำระบบฝั่งรับต้องเตรียมใจไว้มีสามแบบ แบบแรกคือ track เดียวกันกลายเป็นสองระเบียน เพราะ id ที่ติดมากับข้อมูลเป็นของระบบเขา คนละชุดกับที่เราออกเอง แบบที่สองคือเวลาเพี้ยน เพราะฝั่งหนึ่งส่งมาเป็น local time หรือนาฬิกาต้นทางเดินไม่ตรง พอเรียงตามเวลาแล้วเรือเลยดูเหมือนวิ่งถอยหลัง แบบที่สามคือพิกัดคนละ datum หรือปัดทศนิยมคนละระดับ ตำแหน่งจุดเดียวกันเลยห่างกันได้ตั้งแต่ไม่กี่เมตรไปจนถึงหลักร้อย ทางแก้ไม่ได้หวือหวาอะไรเลย คือ normalize ให้จบตั้งแต่ปากทาง ตามแถวขาเข้าในภาพเมื่อกี้ อย่าปล่อยของดิบไหลไปถึงชั้น fusion แล้วค่อยตามแก้ทีหลัง ที่เหลือก็ปล่อยให้กฎเก็บว่าใครบอกทำงานของมันไป

ให้ข้อมูลเขาไปแล้วเราได้อะไรกลับมา ​

มาถึงคำถามที่ค้างไว้ตั้งแต่ท้ายตอนที่แล้วซะที คำตอบที่ผมรวบรวมได้มีสามข้อ

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

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

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

แล้วฝั่งที่เสียไปล่ะ มีแน่นอน อย่างน้อยคือเราเสียทางเลือกที่จะเงียบ เพราะพอเข้าเครือข่ายแล้ว การไม่ส่งก็กลายเป็นข้อมูลอย่างหนึ่งไปโดยปริยาย อันนี้ตลกร้ายชุดเดียวกับตอนที่ 4 เป๊ะ ที่บอกว่าการดับ AIS ไม่ได้ทำให้เรือหายไปไหน มันแค่เปลี่ยนคำถามจากเรือลำนั้นอยู่ไหน เป็นทำไมมันถึงเงียบ

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

และอีกข้อคือเรื่องของการเจรจาต่อรอง เพราะการแลกเปลี่ยนเป้าระหว่างประเทศ มันจะมีความยากไม่ใช่การ integrate ระบบอย่างที่บอก แต่ความสำคัญของ VoI (Vessel of Interest) ของแต่ละที่ไม่เหมือนกัน ฉันเห็นว่าเป้านี้สำคัญ เป็นภัยคุกคาม แต่อีกที่นึงบอกว่า ไม่เห็นสำคัญเลย และเป็นผลดีกับฉันเอง ซะงั้นเอ้า อยู่ไม่ไหว เฮ้ย!

หกตอนจบ — ไล่กลับตั้งแต่ต้นทาง ​

ซีรีส์นี้จบที่ตรงนี้แหละ ลองไล่ย้อนกลับไปดูทั้งกองอีกรอบ

• ตอนที่ 1 Signal Chain กับ AIS ว่าด้วยการพาคลื่นในอากาศมาเป็นข้อความที่โปรแกรมอ่านรู้เรื่อง
• ตอนที่ 2 เรดาร์ชายฝั่งสาม message format กับกล้อง EO/IR ที่หันตามเป้าให้อัตโนมัติ
• ตอนที่ 3 fusion กับ correlation จนเรือหนึ่งลำเหลือหมุดเดียว แล้วพล็อตลงบนแผนที่ GIS
• ตอนที่ 4 dark activities, RF กับ SAR จากวงโคจร และ Machine Learning ทั้งกอง
• ตอนที่ 5 ตระกูล INT ทั้งหลายที่ตอบคำถามว่าใคร ซึ่ง sensor ตอบไม่ได้สักตัว
• ตอนที่ 6 คือตอนนี้ เอาทุกอย่างที่มีไปต่อกับของคนอื่น

ถ้าไล่มาครบทั้งหกตอนจะเห็นว่ามันเป็นเรื่องเดียวกันมาตลอด คือการลดความไม่แน่นอนลงทีละนิด จากคลื่นเป็นจุด จากจุดเป็นหมุด จากหมุดเป็นเรือ จากเรือเป็นเรื่อง แล้วจากเรื่องของเราคนเดียวกลายเป็นภาพที่ต่อกับของคนอื่นได้ ทุกขั้นได้ความแน่นอนเพิ่มมานิดหน่อย และทุกขั้นก็มีทางพังเป็นของตัวเองเหมือนกัน

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

ส่วนกฎที่ตั้งไว้ตั้งแต่ตอนที่ 1 ยังเหมือนเดิมไม่เปลี่ยน คือ ระบบยกมือ คนตัดสิน ไม่ว่าข้อมูลจะมาจากเสาหน้าบ้านเราเองหรือมาจากศูนย์ที่อยู่คนละมหาสมุทรก็ตาม

ใครเคยทำ integration ข้ามองค์กรแล้วต้องมานั่งเถียงกันว่า schema ช่องไหนหมายถึงอะไร หรือเคยเจอเคสที่ null ของสองฝั่งแปลไม่เหมือนกันจนข้อมูลเพี้ยนทั้งชุด มาเล่าสู่กันฟังได้เลยครับ ผมว่าประสบการณ์แนวนี้ของแต่ละคนสนุกกว่าเอกสาร spec เยอะ

ซีรีส์ Maritime Situational Awareness จบเท่านี้ ขอบคุณทุกคนที่อ่านมาจนครบหกตอนนะฮะ ของที่ยังค้างคออยู่อีกหลายชิ้นซึ่งยัดลงซีรีส์ไม่ไหว เดี๋ยวจะทยอยเขียนเป็นบทความเดี่ยวต่อไปเรื่อยๆ