Simplico
Security

สร้าง CoT Bridge: นำข้อมูลจาก NVR, AIS และโดรนขึ้นแผนที่ TAK โดยไม่ให้แผนที่รกจนใช้งานไม่ได้

October 1, 2026

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

คำตอบคือ อุปกรณ์เหล่านั้นไม่ได้พูดภาษา TAK แผนที่ TAK เข้าใจเฉพาะข้อความแบบ Cursor on Target (CoT) และแทบไม่มีอุปกรณ์นอกระบบนิเวศ TAK ที่ส่ง CoT ออกมาเองได้ NVR ส่งผลอ่านป้ายทะเบียนผ่าน Webhook ของตัวเอง เครื่องรับ AIS ส่งออกเป็นประโยค NMEA สถานีควบคุมโดรนส่ง MAVLink หรือ API ของผู้ผลิต จึงต้องมีบางอย่างคั่นกลางเพื่อแปลงแต่ละแหล่งให้เป็น CoT และต้องทำในแบบที่ทำให้แผนที่ยังใช้งานได้ ไม่ใช่จมอยู่ใต้ข้อมูล สิ่งนั้นคือ CoT Bridge และในโครงการ TAK ที่มีเซนเซอร์จำนวนมาก Bridge คืองานวิศวกรรมส่วนใหญ่ของโครงการ

บทความก่อนหน้าของเราอธิบาย ระบบ TAK ทำงานอย่างไร แนวคิดการนำ Alert จาก Wazuh ขึ้นแผนที่ TAK และ สถาปัตยกรรม Hub-and-Spoke สำหรับ OpenTAKServer หลายจุด บทความนี้ลงลึกไปอีกชั้น: Bridge ที่ใช้งานจริงต้องตัดสินใจเรื่องอะไรบ้าง ควรเชื่อมต่ออย่างไร และตัวอย่างโค้ดที่นำไปรันได้

บริการที่เกี่ยวข้อง

1. Bridge ทำอะไรบ้าง

Bridge มีหน้าที่สี่อย่าง ตามลำดับนี้:

flowchart TD
    SRC["แหล่งข้อมูล เช่น Webhook จาก NVR AIS หรือ Telemetry โดรน"] --> PARSE["อ่านและตรวจสอบข้อมูลดิบ"]
    PARSE --> FILTER["กรองข้อมูลความเชื่อมั่นต่ำและนอกพื้นที่"]
    FILTER --> MAP["แปลงเป็น CoT Event พร้อม UID Type และ Stale Time"]
    MAP --> RATE["ควบคุมอัตรา ตัดซ้ำ และเก็บเฉพาะล่าสุดต่อ UID"]
    RATE --> TLS["ส่งผ่าน Mutual TLS ไปยัง TAK Server"]
    TLS --> CLIENTS["ATAK WinTAK และ iTAK"]
    RATE --> BUF["บัฟเฟอร์ในเครื่องระหว่างลิงก์ขาด"]
    BUF --> TLS

อ่าน (Parse) ข้อมูลในรูปแบบของแหล่งนั้น กรอง (Filter) สิ่งที่ไม่ควรมีใครเห็น เช่น การตรวจจับที่ความเชื่อมั่นต่ำ ตำแหน่งนอกพื้นที่ที่สนใจ หรือข้อมูลทดสอบ แปลง (Map) ส่วนที่เหลือเป็น CoT Event ซึ่งเป็นจุดที่มีการตัดสินใจเชิงออกแบบมากที่สุด ควบคุมอัตรา เพราะเซนเซอร์รายงานถี่กว่าที่คนจะอ่านแผนที่ได้มาก แล้วจึง ส่ง ผ่านการเชื่อมต่อที่ยืนยันตัวตนแล้ว และเก็บบัฟเฟอร์ไว้เมื่อการเชื่อมต่อขาด

Bridge ที่ล้มเหลวส่วนใหญ่ข้ามขั้นกรองและขั้นควบคุมอัตรา แปลงข้อมูลได้ถูกต้องทุกตัว ส่งทุกอย่างขึ้นไป แล้วผ่านไปหนึ่งสัปดาห์ เจ้าหน้าที่ก็ปิด Layer นั้นทิ้งเพราะแผนที่อ่านไม่ออก

2. โครงสร้างของ CoT Event

CoT Event คือเอกสาร XML ขนาดเล็ก นี่คือ Event ที่ Bridge ตัวอย่างของเราสร้างขึ้นจากการอ่านป้ายทะเบียนหนึ่งครั้ง:

<event version="2.0" uid="anpr-gate-north-1KB1234" type="a-u-G-E-V" how="m-p"
       time="2026-10-01T04:14:14Z" start="2026-10-01T04:14:14Z" stale="2026-10-01T04:24:14Z">
  <point lat="13.7563" lon="100.5018" hae="0" ce="15.0" le="9999999"/>
  <detail>
    <contact callsign="Plate 1KB1234"/>
    <remarks>ANPR gate-north confidence 0.93</remarks>
  </detail>
</event>
ฟิลด์ ความหมาย สิ่งที่ Bridge ต้องตัดสินใจ
uid ตัวตนของสิ่งที่ถูกรายงาน คงที่ข้ามทุกการรายงาน จะสร้าง ID ที่คงที่ให้กับวัตถุจริงแต่ละชิ้นอย่างไร
type ประเภทแบบลำดับชั้น: a คือวัตถุทางกายภาพ ตามด้วยฝ่าย (f ฝ่ายเรา, h ฝ่ายตรงข้าม, n เป็นกลาง, u ไม่ทราบ) แล้วตามด้วยมิติ (G ภาคพื้นดิน, A อากาศ, S ผิวน้ำ, U ใต้น้ำ) และหน้าที่ที่เฉพาะเจาะจงขึ้น เซนเซอร์มีสิทธิ์อ้างไอคอนและฝ่ายใดได้อย่างซื่อตรง
how รายงานนี้เกิดขึ้นอย่างไร ขึ้นต้นด้วย m คือเครื่องสร้าง หรือ h คือคนป้อน สำหรับเซนเซอร์ เกือบทุกครั้งคือเครื่องสร้าง
time / start / stale เวลาที่สร้าง Event เวลาที่สถานะเริ่มมีผล และเวลาที่ควรเลิกถือว่าเป็นข้อมูลปัจจุบัน รายงานจากแต่ละแหล่งถือว่าจริงได้นานแค่ไหน
point ละติจูด ลองจิจูด ความสูงเหนือทรงรี WGS84 (hae) และค่าความคลาดเคลื่อน 1-sigma แนวราบและแนวดิ่งเป็นเมตร (ce, le) ตำแหน่งแม่นยำจริงแค่ไหน
detail ส่วนขยายแบบเปิด: contact, track, remarks และอื่น ๆ ที่ Client เข้าใจ เจ้าหน้าที่ต้องเห็นอะไรเมื่อแตะที่ไอคอน

ค่าที่ใช้กันแทนความคลาดเคลื่อนที่ "ไม่ทราบ" คือตัวเลขที่ใหญ่มาก 9999999 คือค่าที่ไลบรารี PyTAK ใช้เองเมื่อไม่มีค่าจริง การใช้ค่านี้ดีกว่าการแต่งความแม่นยำขึ้นมาเอง

3. สี่เรื่องที่ทุก Bridge ต้องตัดสินใจ

UID: วัตถุจริงหนึ่งชิ้น หนึ่ง UID ตลอดไป

UID คือสิ่งที่ทำให้ TAK รู้ว่ารายงานใหม่เป็น การอัปเดต ไอคอนเดิม ไม่ใช่ไอคอนใหม่ ถ้าออกแบบผิดจะเจอปัญหาหนึ่งในสองแบบ คือมีไอคอนใหม่ทุกครั้งที่รายงาน (เรือซ้ำกันเป็นร้อยลำบนแผนที่) หรือวัตถุจริงหลายชิ้นถูกรวมเป็นไอคอนเดียว

ให้สร้าง UID จากตัวระบุที่คงที่ที่สุดของแหล่งข้อมูล สำหรับ AIS คือหมายเลข MMSI ของเรือ สำหรับโดรนคือหมายเลขเครื่องหรือ Remote ID ไม่ใช่หมายเลขเที่ยวบิน สำหรับกล้องอ่านป้ายทะเบียน ขึ้นอยู่กับว่าต้องการให้แผนที่แสดงอะไร กล้อง + ป้ายทะเบียน ให้ไอคอนหนึ่งอันต่อรถหนึ่งคันต่อประตู ส่วน ป้ายทะเบียน อย่างเดียวให้ไอคอนเดียวที่กระโดดไปมาระหว่างประตู ทั้งสองแบบมีเหตุผล แต่ต้องเลือกอย่างตั้งใจ และใส่คำนำหน้าตามแหล่ง (ais-, anpr-, uas-) เพื่อไม่ให้สองแหล่งชนกัน

เรื่องเฉพาะของป้ายทะเบียนไทย: ป้ายทะเบียนไทยมีพยัญชนะไทยและชื่อจังหวัด XML รองรับอักษรไทยได้ แต่ UID ควรเป็นอักขระ ASCII เพื่อความเข้ากันได้กับ Client และเครื่องมือทุกตัว แนวทางที่ใช้ได้คือแปลงพยัญชนะและจังหวัดเป็นรหัส ASCII ที่ตกลงกันไว้ หรือใช้ค่า Hash ของป้ายเป็น UID แล้วแสดงป้ายภาษาไทยจริงใน callsign ซึ่งเป็นสิ่งที่เจ้าหน้าที่เห็นบนแผนที่

Type: อ้างเฉพาะสิ่งที่เซนเซอร์รู้จริง

กล้องอ่านป้ายทะเบียนรู้ว่ามีรถ แต่ไม่รู้ว่ารถคันนั้นเป็นฝ่ายเราหรือฝ่ายตรงข้าม ฝ่ายที่ซื่อตรงจึงเป็น u คือไม่ทราบ และประเภทคือยานพาหนะภาคพื้นดิน (a-u-G-E-V) หลักเดียวกันใช้ได้ทุกที่ เป้า AIS คือเป้าผิวน้ำที่ไม่ทราบฝ่ายจนกว่าผู้มีอำนาจจะบอกเป็นอย่างอื่น โดรนของเราเองคือเป้าอากาศฝ่ายเรา Bridge ที่ติดป้าย "ฝ่ายตรงข้าม" ให้ทุกอย่างเพื่อให้เด่น จะสอนให้เจ้าหน้าที่เลิกสนใจสีแดง

Stale Time: รายงานนี้จริงอยู่ได้นานแค่ไหน

Stale Time คือฟิลด์ที่ถูกออกแบบน้อยที่สุดใน Bridge ส่วนใหญ่ และเป็นฟิลด์ที่ส่งผลต่อสิ่งที่เจ้าหน้าที่เห็นมากที่สุด เมื่อเลย Stale Time แล้ว Client จะเลิกถือว่าไอคอนนั้นเป็นข้อมูลปัจจุบัน ให้กำหนดแยกตามแหล่ง จากความถี่ที่แหล่งนั้นรายงานและความเร็วที่วัตถุเคลื่อนที่:

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

Stale Time ที่นานเกินไปทิ้ง "ผี" ไว้บนแผนที่ ที่สั้นเกินไปทำให้ไอคอนกะพริบหายไปมาระหว่างการอัปเดต ทั้งสองอย่างมองไม่เห็นในห้องแล็บที่มีอุปกรณ์ทดสอบเครื่องเดียว จึงมักหลุดรอดไป

ความคลาดเคลื่อนของตำแหน่ง: รายงานความไม่แน่นอนเท่าที่มีจริง

การอ่านป้ายทะเบียนมีตำแหน่งที่กล้อง ไม่ใช่ที่ตัวรถ ค่า ce จึงควรเป็นรัศมีการมองเห็นของกล้อง ไม่ใช่ศูนย์ ตำแหน่งจาก AIS มีความแม่นยำของตัวเอง ส่วนตำแหน่งประมาณจากรายงานของคนยิ่งคลาดเคลื่อนมากกว่า Client ใช้ ce แสดงความไม่แน่นอนได้ แต่ก็ต่อเมื่อ Bridge ใส่ค่าอย่างซื่อตรง

4. การควบคุมอัตรา: ส่วนที่ทำให้แผนที่ยังอ่านได้

กล้องหน้าประตูที่มีรถผ่านมากเพียงตัวเดียว ก็สร้างผลอ่านป้ายได้หลายร้อยครั้งต่อชั่วโมง หลายครั้งเป็นรถคันเดิมที่จอดติดเครื่องอยู่หน้ากล้อง โดรนส่ง Telemetry หลายครั้งต่อวินาที Client TAK บนเครือข่าย 4G ไม่ต้องการข้อมูลทั้งสองแบบในอัตรานั้น

สามเทคนิคที่มักใช้ร่วมกัน:

  • ทิ้งตั้งแต่ต้นทาง ทิ้งการตรวจจับที่ต่ำกว่าเกณฑ์ความเชื่อมั่นและข้อมูลนอกพื้นที่ที่สนใจ ก่อนที่จะเสียแบนด์วิดท์
  • ตัดซ้ำต่อ UID ถ้าวัตถุเดียวกันเพิ่งถูกส่งไปไม่ถึง N วินาที และไม่ได้เคลื่อนที่อย่างมีนัยสำคัญ ให้ข้าม
  • เก็บเฉพาะล่าสุด เมื่อคิวขาออกเต็ม ให้เก็บเฉพาะ Event ล่าสุดของแต่ละ UID แทนการส่งตำแหน่งเก่าที่ค้างอยู่ตามลำดับ พฤติกรรมเริ่มต้นของ PyTAK เองก็เป็นแนวนี้ คิวขาออกเก็บได้ 100 Event และทิ้งตัวที่เก่าที่สุดเมื่อเต็ม

5. การส่งข้อมูล: ใช้ Mutual TLS ไม่ใช่ Plaintext และไม่ใช่ HTTP

การติดตั้ง OpenTAKServer แบบมาตรฐานเปิดพอร์ต 8088 สำหรับ CoT แบบ Plaintext พอร์ต 8089 สำหรับ CoT ผ่าน Mutual TLS และพอร์ต 8446 สำหรับการลงทะเบียนใบรับรองอัตโนมัติ Bridge ที่ใช้งานจริงควรเชื่อมต่อที่ 8089 ด้วยใบรับรองของตัวเอง

เรื่องนี้สำคัญกว่าแค่การเข้ารหัส เมื่อใช้ Mutual TLS เซิร์ฟเวอร์รู้ว่า Bridge ตัวไหน ส่ง Event แต่ละรายการ สามารถเพิกถอนใบรับรองของ Bridge ตัวเดียวได้หากเครื่องถูกเจาะ และจัด Bridge แต่ละตัวเข้า Group ใน TAK เพื่อไม่ให้ภาพกล้องจากจุดหนึ่งถูกกระจายไปยังทุกทีมทั่วประเทศ Bridge ที่ใช้พอร์ต 8088 แบบ Plaintext ไม่มีตัวตน และอะไรก็ตามที่เข้าถึงพอร์ตนั้นได้ ก็สามารถแทรกไอคอนลงบนแผนที่ของเจ้าหน้าที่ได้

อีกสองรายละเอียดที่เกี่ยวข้อง:

  • XML หรือ Protobuf Client และ Server ของ TAK สามารถตกลงอัปเกรดจากการเข้ารหัส XML แบบเดิม ("version 0") ไปเป็น Protocol Buffers ("version 1") ได้ แต่ Client ทุกตัวยังต้องถอดรหัส XML ได้เสมอ Bridge จึงส่ง XML แล้วให้ Server จัดการส่วนที่เหลือได้ เปลี่ยนเป็น Protobuf เฉพาะเมื่อแบนด์วิดท์ของลิงก์ที่ Bridge ใช้จำกัดจริง ๆ
  • บัฟเฟอร์เมื่อการเชื่อมต่อขาด จุดปฏิบัติการภาคสนามสูญเสียลิงก์ได้เสมอ Bridge ควรมีบัฟเฟอร์ในเครื่องที่มีขนาดจำกัด ใช้หลักเก็บเฉพาะล่าสุดต่อ UID แล้วส่งออกเมื่อเชื่อมต่อได้อีกครั้ง แทนที่จะทำข้อมูลหายทั้งหมด หรือส่งตำแหน่งย้อนหลังทั้งชั่วโมงตามลำดับ นี่คือคำถามเรื่อง Federation ที่เราคุยไว้ใน บทความ Hub-and-Spoke ในระดับของ Bridge

6. ตัวอย่างที่ใช้งานได้: ผลอ่านป้ายทะเบียนสู่ CoT

นี่คือ Bridge ขนาดเล็กที่ครบถ้วน รับผลอ่านป้ายทะเบียนจาก NVR กรองและตัดซ้ำ แล้วส่ง CoT ด้วย PyTAK ไลบรารี Python แบบโอเพนซอร์สสำหรับ TAK เราทดสอบกับตัวรับข้อมูลในเครื่อง จากตัวอย่างสามรายการ คือการอ่านที่ดีหนึ่งครั้ง ป้ายเดิมซ้ำทันทีหลังจากนั้น และการอ่านที่ความเชื่อมั่นต่ำ มี CoT Event ถูกส่งออกไปเพียงหนึ่งรายการตามที่ควรเป็น (ในตัวอย่างใช้ป้ายแบบ ASCII เพื่อความเรียบง่าย สำหรับป้ายไทยจริงให้ใช้แนวทางในหัวข้อที่ 3)

"""Minimal ANPR-to-CoT bridge: NVR plate reads in, CoT events out to a TAK server."""
import asyncio
import time
import xml.etree.ElementTree as ET
from configparser import ConfigParser

import pytak

# Fixed camera positions come from the site survey, not from the NVR payload.
CAMERAS = {
    "gate-north": {"lat": 13.7563, "lon": 100.5018, "ce": 15.0},
}
MIN_INTERVAL_S = 30   # same plate at the same camera: at most one update per 30 s
STALE_S = 600         # a plate sighting stops being "current" after 10 minutes

def anpr_to_cot(read: dict) -> bytes:
    """Map one NVR plate read to a CoT event."""
    cam = CAMERAS[read["camera_id"]]
    plate = read["plate"].replace(" ", "").upper()
    event = ET.Element(
        "event",
        version="2.0",
        uid=f"anpr-{read['camera_id']}-{plate}",   # stable per plate and camera
        type="a-u-G-E-V",                          # unknown ground vehicle
        how="m-p",                                 # machine-generated, relayed by the bridge
        time=pytak.cot_time(),
        start=pytak.cot_time(),
        stale=pytak.cot_time(STALE_S),
    )
    ET.SubElement(event, "point", lat=str(cam["lat"]), lon=str(cam["lon"]),
                  hae="0", ce=str(cam["ce"]), le="9999999")
    detail = ET.SubElement(event, "detail")
    ET.SubElement(detail, "contact", callsign=f"Plate {plate}")
    ET.SubElement(detail, "remarks").text = (
        f"ANPR {read['camera_id']} confidence {read['confidence']:.2f}"
    )
    return ET.tostring(event)

class AnprSender(pytak.QueueWorker):
    """Reads plate events from a local queue, rate-limits per UID, sends CoT."""

    def __init__(self, tx_queue, config, source: asyncio.Queue):
        super().__init__(tx_queue, config)
        self.source = source
        self.last_sent: dict[str, float] = {}

    async def handle_data(self, data: bytes) -> None:
        await self.put_queue(data)              # hand the CoT event to pytak's TX worker

    async def run(self, number_of_iterations=-1):
        while True:
            read = await self.source.get()
            if read["confidence"] < 0.80:      # drop low-confidence reads at the edge
                continue
            key = f"{read['camera_id']}-{read['plate'].replace(' ', '').upper()}"
            now = time.monotonic()
            if now - self.last_sent.get(key, 0) < MIN_INTERVAL_S:
                continue                        # duplicate within the window
            self.last_sent[key] = now
            await self.handle_data(anpr_to_cot(read))

async def main(cot_url: str, reads: list[dict]):
    config = ConfigParser()
    config["bridge"] = {"COT_URL": cot_url}
    # For mutual TLS on port 8089, also set PYTAK_TLS_CLIENT_CERT,
    # PYTAK_TLS_CLIENT_KEY and PYTAK_TLS_CLIENT_CAFILE here.
    source: asyncio.Queue = asyncio.Queue()
    for r in reads:
        source.put_nowait(r)
    clitool = pytak.CLITool(config["bridge"])
    await clitool.setup()
    clitool.add_tasks({AnprSender(clitool.tx_queue, config["bridge"], source)})
    await clitool.run()

สามเรื่องที่ควรสังเกต:

  • ตำแหน่งมาจากการสำรวจพื้นที่ ไม่ใช่จาก NVR พิกัดและรัศมีการมองเห็นของกล้องอยู่ในค่าตั้งของ Bridge เพราะ NVR ส่วนใหญ่ไม่รู้ว่าตัวเองอยู่ที่ไหน
  • ต้องเขียน handle_data เอง ใน QueueWorker ของ PyTAK เมธอดนี้เป็นเพียงตัวว่าง ต้องเขียนให้ส่ง Event เข้าคิวขาออก เราพบเรื่องนี้จากการทดสอบจริง รอบแรกมีเพียง Ping การเชื่อมต่อของ PyTAK เองที่ถูกส่งออกไป
  • TLS เป็นเรื่องของค่าตั้ง ไม่ใช่โค้ด ตั้ง COT_URL เป็น tls://your-server:8089 แล้วชี้ PYTAK_TLS_CLIENT_CERT, PYTAK_TLS_CLIENT_KEY และ PYTAK_TLS_CLIENT_CAFILE ไปที่ใบรับรอง คีย์ของ Bridge และ CA ของเซิร์ฟเวอร์ ปล่อย PYTAK_TLS_DONT_VERIFY ไว้ที่ค่าเริ่มต้น 0

เวอร์ชันที่ใช้งานจริงจะเพิ่มตัวรับ Webhook แทนรายการตัวอย่าง บัฟเฟอร์แบบถาวร ตัวชี้วัดสุขภาพระบบ และ Heartbeat Event เพื่อให้เจ้าหน้าที่เห็นได้ว่าตัว Bridge เองหยุดรายงานแล้ว

7. การดูแล Bridge ในการใช้งานจริง

Bridge คือบริการที่คนจะเลิกเชื่อถือตั้งแต่ครั้งแรกที่มันแสดงข้อมูลผิด จึงต้องดูแลเหมือนบริการ Production ตัวอื่น:

  • ทำให้ Bridge มองเห็นได้ ส่ง Heartbeat CoT ของ Bridge เอง เมื่อ Bridge ของจุดใดหยุดทำงาน เจ้าหน้าที่ควรเห็นไอคอนของมันหมดอายุ ไม่ใช่สูญเสีย Layer ไปเงียบ ๆ
  • บันทึกสิ่งที่ทิ้ง ไม่ใช่แค่สิ่งที่ส่ง เมื่อมีคนถามว่าทำไมรถคันหนึ่งไม่ขึ้นบนแผนที่ คำตอบมักเป็นตัวกรองตัวใดตัวหนึ่ง และคุณต้องชี้ได้ว่าตัวไหน
  • ทำเวอร์ชันให้กับการแปลงข้อมูล Type Code, Stale Time และเกณฑ์ต่าง ๆ คือการตัดสินใจเชิงปฏิบัติการ ควรเก็บเป็นค่าตั้งใน Version Control เพื่อให้ทุกการเปลี่ยนแปลงตรวจทานและย้อนกลับได้
  • หนึ่งใบรับรองต่อหนึ่ง Bridge ห้ามใช้ใบรับรองร่วมกันข้าม Bridge หรือข้ามจุด การเพิกถอนจะได้ผลก็ต่อเมื่อใบรับรองหนึ่งใบผูกกับสิ่งเดียวเท่านั้น

8. มุมมองสำหรับหน่วยงานไทย: ข้อมูลป้ายทะเบียนคือข้อมูลส่วนบุคคล

ภายใต้ พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล ป้ายทะเบียนที่เชื่อมโยงกับเจ้าของรถได้ถือเป็นข้อมูลส่วนบุคคล หน่วยงานที่นำ Layer กล้องอ่านป้ายขึ้น TAK ไม่ว่าจะเป็นด่าน จุดตรวจ หรือนิคมอุตสาหกรรมในพื้นที่ EEC ควรตัดสินใจล่วงหน้าว่าใครมีสิทธิ์เห็น Layer นี้ จัดไว้ใน TAK Group ที่จำกัดสิทธิ์ และตั้ง Stale Time ให้สั้น เพื่อให้แผนที่เป็นภาพสถานการณ์ปัจจุบัน ไม่ใช่ประวัติการเดินทางของคน ส่วนการเก็บบันทึกย้อนหลังควรอยู่ในระบบที่มีนโยบายระยะเวลาเก็บรักษาชัดเจน ไม่ใช่บนแผนที่ปฏิบัติการ

9. สิ่งที่ Simplico สร้าง และสิ่งที่กำหนดขอบเขตตามภารกิจ

การสร้าง Bridge เป็นงานแบบขอบเขตคงที่ตามที่ระบุไว้ในหน้า TAK Integration คือ Bridge สำหรับชุดแหล่งข้อมูลที่กำหนด ส่งมอบซอร์สโค้ดพร้อมการส่งต่องาน แหล่งข้อมูลที่เราเชื่อมบ่อย ได้แก่ Telemetry โดรนและ UAV เหตุการณ์จาก CCTV/NVR และกล้องอ่านป้ายทะเบียน เครื่องติดตาม GPS, AIS, ADS-B, เซนเซอร์แนวรั้ว และสัญญาณเตือนจาก SCADA

กำหนดขอบเขตตามภารกิจ: Plugin เฉพาะสำหรับ ATAK หรือ WinTAK (เช่น Tile วิดีโอ หรือหน้าจอเฉพาะภารกิจ) การส่งต่อวิดีโอสด การส่งข้อมูลแบบ Protobuf และการเชื่อมสองทางระหว่าง SOC กับ TAK ที่ทำให้การตรวจจับภัยไซเบอร์กลายเป็นเหตุการณ์บนแผนที่ และเหตุการณ์ภาคสนามกลายเป็น Case แต่ละเรื่องเป็นงานแยก กำหนดราคาเมื่อเข้าใจแหล่งข้อมูลและสภาพแวดล้อมการปฏิบัติงานแล้ว

นอกขอบเขต: ตัวเซนเซอร์เอง เราเชื่อมต่อกล้อง เครื่องรับ และโดรนที่คุณมีอยู่หรือจัดซื้อเอง เราไม่จัดหาหรือบวกกำไรจากฮาร์ดแวร์

คำถามที่พบบ่อย

ส่ง Event ไปยัง TAK Server ด้วย HTTP POST เลยได้ไหม?

สำหรับต้นแบบ ได้ สำหรับการใช้งานจริง การเชื่อมต่อแบบ Streaming ผ่าน Mutual TLS เป็นค่าเริ่มต้นที่ดีกว่า เพราะระบุตัวตนของแต่ละ Bridge ได้ รองรับการกำหนดเส้นทางตาม Group และการเพิกถอน และไม่มีภาระต่อคำขอแบบ HTTP สำหรับแหล่งข้อมูลที่ส่งถี่

Bridge ควรรันที่จุดภาคสนามหรือที่ส่วนกลาง?

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

ใช้กับ TAK Server ตัวไหนได้บ้าง?

Bridge ส่ง CoT มาตรฐานผ่าน TCP หรือ TLS จึงใช้กับ OpenTAKServer, FreeTAKServer และ TAK Server ทางการได้ พอร์ตและวิธีลงทะเบียนต่างกันไปตามเซิร์ฟเวอร์ ตัวเลขในบทความนี้เป็นของ OpenTAKServer

เซนเซอร์ทุกตัวต้องมี Bridge แยกหรือไม่?

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

บทความที่เกี่ยวข้อง

อ่านบทความทั้งหมด →

ถ้าคุณมีเซนเซอร์ที่ควรขึ้นแผนที่ TAK แต่ยังไม่ได้ขึ้น การประเมินความพร้อมสองสัปดาห์ ของเราจะสำรวจทุกแหล่งข้อมูล อัตราการส่ง และการเชื่อมต่อของแต่ละแหล่งก่อนเริ่มสร้างอะไรเลย ติดต่อ hello@simplico.net โทร (+66) 97 496 6397 WhatsApp (+66) 83 001 0222 หรือ LINE iiitum1984

แหล่งที่มา:

บทความล่าสุด

Ready to talk about your project?

Share goals and constraints. We'll assemble architects and engineers to move fast with you.

Get in touch