POLICE INNOPOLISiBOC · ARCHITECTURE BRIEF 25 ต.ค. 2569   /   REV.02
National AI Platform / Proposed Architecture

เชื่อมข้อมูลเหตุของตำรวจและโรงเรียนด้วย iBOC ที่เลือกใช้ตามภารกิจ

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

ภาพจากกล้อง → ผลวิเคราะห์ → เจ้าหน้าที่ตรวจสอบ → ประสานการปฏิบัติ

01

สองหน่วยงาน แยกการบริหารข้อมูล

คงแนวคิดแพลตฟอร์มตำรวจและโรงเรียนจากข้อเสนอเดิม โดยกำหนดขอบเขตการใช้งานและเจ้าของข้อมูลของแต่ละฝั่งให้ชัดเจน

A / POLICE DOMAIN

ตำรวจ / สถานีตำรวจ / จังหวัด

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

  • FACE, PERS, OID และ LPR สำหรับค้นหาและเรียงเหตุการณ์
  • INTR, LEFT, DENS และ FT สำหรับเฝ้าระวังพื้นที่
  • SPW, ILP และโมดูลรถจักรยานยนต์ตามขอบเขตงานจราจร
B / SCHOOL DOMAIN

โรงเรียน / เขตพื้นที่ / สพฐ.

ดูแลทางเข้าออกและพื้นที่เสี่ยง ช่วยตรวจสอบเหตุ และส่งข้อมูลให้ผู้รับผิดชอบตามกระบวนการของโรงเรียน

  • INTR, LEFT และ DENS สำหรับพื้นที่และช่วงเวลาที่กำหนด
  • FT และ OID สำหรับช่วยตรวจเหตุและค้นภาพที่เกี่ยวข้อง
  • LPR สำหรับประตูหรือจุดรับส่งเมื่อมีความจำเป็น
ใช้บริการ AI ร่วมกัน ≠ เปิดค้นข้อมูลข้ามหน่วยงาน

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

FACE/PERS สำหรับงานระบุตัวบุคคลในโรงเรียนต้องกำหนดวัตถุประสงค์และผู้มีสิทธิ์ก่อนเลือกใช้ ไม่กำหนดฐานใบหน้านักเรียนทุกคนเป็นค่าเริ่มต้นของข้อเสนอนี้

02

เลือกฟังก์ชันจากงานที่ต้องทำจริง

ฐานสำหรับงาน Analytics คือ Core Platform (Standard) ร่วมกับโมดูลที่เลือก เอกสารระบุการบันทึกวิดีโอ ค้นหาวัตถุ Dashboard และ Automation/API แต่ยังต้องยืนยันเวอร์ชัน License และขนาดระบบที่จัดส่งจริง [1]

รายการด้านล่างมีในเอกสารผลิตภัณฑ์ความแม่นยำและความพร้อมต้องตรวจรับตามพื้นที่

เลื่อนตารางในแนวนอนเพื่ออ่านรายละเอียด

การประยุกต์ใช้เป็นข้อเสนอของเอกสารฉบับนี้ ส่วนชื่อและหน้าที่โมดูลอ้างอิงเอกสาร iBOC
โมดูลหน้าที่ตำรวจโรงเรียน
INTR [2]ตรวจคน รถ หรือวัตถุเข้าออกพื้นที่ / ข้ามเส้นพื้นที่หวงห้าม แนวรั้ว จุดเฝ้าระวังประตู แนวรั้ว อาคารนอกเวลา
LEFT [2]วัตถุวางทิ้ง / คนหรือรถอยู่เกินเวลากระเป๋าวางทิ้ง คนวนเวียน รถหยุดค้างวัตถุวางทิ้งและการอยู่ในพื้นที่เสี่ยงนานผิดปกติ
DENS [2]ความหนาแน่นของคน รถ หรือวัตถุจุดรวมตัว พื้นที่สาธารณะ การจราจรประตู จุดรับส่ง และพื้นที่กิจกรรม
FT [2]ตรวจลักษณะเหตุทะเลาะวิวาทแจ้งเจ้าหน้าที่ตรวจสอบเหตุชกต่อยแจ้งผู้รับผิดชอบตรวจสอบและช่วยเหลือ
OID [3]ค้นหาวัตถุด้วยข้อความหรือภาพตัวอย่างค้นคน รถ วัตถุ และภาพที่เกี่ยวข้องกับเหตุค้นภาพประกอบการตรวจสอบเหตุเฉพาะเรื่อง
FACE [4]ค้นหา / เปรียบเทียบใบหน้า / รายการเฝ้าระวังค้นบุคคลตามภารกิจและสิทธิ์พิจารณาเฉพาะกรณีที่มีความจำเป็นและขอบเขตชัดเจน
PERS [4]ค้นบุคคลจากการแต่งกายและลักษณะภายนอกค้นตามภาพหรือคำบรรยายเมื่อไม่เห็นใบหน้าชัดช่วยค้นภาพบุคคลที่เกี่ยวข้องกับเหตุ ไม่ใช่ยืนยันตัวตน
LPR [5]อ่านทะเบียน จำแนกรถ และค้นย้อนหลังรถในรายการเฝ้าระวัง จุดผ่าน และลำดับเวลาที่พบรถเข้าออก จุดรับส่ง และทะเบียนที่ได้รับอนุญาต
SPW [5]ความเร็วและการเคลื่อนที่ผิดทิศทางเฝ้าระวังความเร็ว / ย้อนศร; งานบังคับใช้ต้องตรวจเงื่อนไขเพิ่มเฝ้าระวังรถในบริเวณรับส่งเมื่อมุมกล้องเหมาะสม
ILP [5]จอดในที่ห้ามจอด ใช้งานร่วมกับ LPRจุดห้ามจอดและจอดกีดขวางทางเข้าออกและพื้นที่ที่ต้องเว้นทาง
HEM
RIDE / RIDT [5]		หมวกนิรภัย / ขี่หรือเข็น / ประเภทไรเดอร์งานรถจักรยานยนต์ตามโมดูลที่เลือกประตูและจุดรับส่งตามความจำเป็น

HEM, RIDE และ RIDT ระบุมุมกล้องด้านหลังในเอกสาร; RIDT จำแนกประเภทไรเดอร์ เช่น รถรับจ้างหรือผู้ส่งอาหาร ไม่ใช่โมดูลนับคนซ้อนท้าย [5]

อาวุธที่มองเห็นในภาพ

AI Search และคู่มือกล่าวถึงอาวุธและการแจ้งเตือน แต่การตรวจปืนอัตโนมัติต้องยืนยันโมเดล เงื่อนไขภาพ ความหน่วง และอัตราแจ้งผิด ไม่ถือว่าพร้อมใช้งานจากการมีตัวอย่างคำค้นเพียงอย่างเดียว [3][6]

ติดตามจากหลายกล้อง

แผนที่แสดงจุดและเวลาที่ตรวจพบ พร้อมเส้นทางคาดการณ์ระหว่างกล้อง ไม่ใช่พิกัดต่อเนื่องแบบ GPS และไม่รับรองว่าจับคู่บุคคลได้ถูกต้องทุกช่วง [4][5]

03

ตำแหน่งประมวลผลกำหนดเส้นทางข้อมูล

แยกการบันทึกวิดีโอ การทำ AI และการจัดการเหตุออกจากกัน หากทำ AI ที่ส่วนกลาง ต้องส่งภาพ เฟรม คลิป หรือสตรีมที่เพียงพอให้ส่วนกลางวิเคราะห์ การส่งเฉพาะ Metadata ทำได้เมื่อมีการวิเคราะห์ที่ต้นทางแล้ว

Logical architecture / รูปแบบที่เสนอ

เส้นทึบ: ผลวิเคราะห์ · เส้นประ: ภาพสำหรับ Central AI

เลื่อนผังในแนวนอนเพื่อดูทั้งสองหน่วยงาน

Shared iBOC AI กับข้อมูลแยกตามหน่วยงาน ข้อมูลจากไซต์ตำรวจและโรงเรียนส่งผลวิเคราะห์ Edge เข้าระบบหน่วยงานของตน หรือส่งภาพที่อนุญาตไปยัง Central AI ผ่านเส้นประ ผล Central AI กลับเฉพาะระบบหน่วยงานเจ้าของข้อมูล ผู้ใช้งานค้นภาพภายใต้สิทธิ์หน่วยงาน การส่งต่อเหตุระหว่างหน่วยงานแสดงแยกในลำดับการรับเหตุ Shared iBOC AI service Central inference เฉพาะงานที่ส่งเข้ามา แยกขอบเขตข้อมูลและทรัพยากรตามหน่วยงาน* ผล Central AI → ตำรวจ ผล Central AI → โรงเรียน POLICE DOMAINSCHOOL DOMAIN ระบบข้อมูลและผู้ใช้งานตำรวจ ระบบข้อมูลและผู้ใช้งาน สพฐ. Event · Search · Video access · ผู้ตรวจสอบ Event · Search · Video access · ผู้ตรวจสอบ คลังข้อมูลและดัชนีค้นหาของหน่วยงาน คลังข้อมูลและดัชนีค้นหาของหน่วยงาน ผลจาก Edge AI / Event ผลจาก Edge AI / Event ภาพ / คลิปหรือสตรีมสำหรับ Central AIตามสิทธิ์ที่อนุญาต ไซต์ตำรวจไซต์โรงเรียน CCTV · Local NVR/VMS · AI/Gateway ตามแบบCCTV · Local NVR/VMS · AI/Gateway ตามแบบ บันทึกในพื้นที่ และส่งข้อมูลตามรูปแบบประมวลผลบันทึกในพื้นที่ และส่งข้อมูลตามรูปแบบประมวลผล *ข้อกำหนดงานออกแบบและตรวจรับ ไม่ใช่การยืนยันว่า iBOC มีระบบ Multi-tenant สำเร็จรูปครบแล้ว
แผนภาพแสดงการแยกขอบเขตข้อมูลและทางเลือกทำ AI เส้นประใช้งานเมื่อเลือก Central AI ส่วน Live View และการสำรองหลักฐานมีเส้นทางแยกตามรายละเอียดด้านล่าง การแยกสิทธิ์และดัชนีค้นหาต้องทดสอบก่อนเปิดใช้งาน

Edge inference — วิเคราะห์ภาพใกล้กล้อง

CCTV / NVR→AI Server ในพื้นที่→Event + ภาพประกอบที่อนุญาต→ระบบหน่วยงาน

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

เส้นทางข้อมูลและปลายทางสิ่งที่ต้องกำหนด
Live / Playbackผู้ใช้ที่มีสิทธิ์ → VMS หรือ Video Gateway → กล้อง/NVR เจ้าของข้อมูลจำนวนผู้ดูพร้อมกัน Bitrate ระยะเวลาดู และบันทึกการเข้าถึง
Evidence / BackupNVR หรือคลังหน่วยงาน → คลังหลักฐาน/สำรองของหน่วยงานเดียวกันคัดเฉพาะเหตุหรือส่งทั้งหมด รอบส่ง Retention และความครบถ้วนของไฟล์
Cross-agency Incidentผู้รับผิดชอบยืนยันเหตุ → ส่งข้อมูลเท่าที่อนุญาตไปยังหน่วยรับเหตุขอบเขตเหตุ ผู้รับผิดชอบ สิทธิ์ข้อมูล และการยืนยันรับเรื่อง

บริการคิวงาน, MLOps, Autoscaling, Multi-tenant Isolation, Video Federation และคลังหลักฐานเป็นส่วนที่ต้องออกแบบหรือเชื่อมเพิ่ม ไม่สรุปว่าเป็นฟังก์ชันสำเร็จรูปของ iBOC จากเอกสารที่ได้รับ

04

AI แจ้งสัญญาณ คนตรวจสอบและสั่งการ

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

  1. 01 / SIGNALรับสัญญาณเหตุ

    AI Alert หรือคนแจ้งเหตุ / SOS

  2. 02 / VERIFYเจ้าหน้าที่ตรวจสอบ

    ดูภาพ เวลา สถานที่ และข้อมูลประกอบ

  3. 03 / COORDINATEประสานผู้รับผิดชอบ

    ส่งข้อมูลเฉพาะเหตุและยืนยันการรับเรื่อง

  4. 04 / ACTผู้มีอำนาจสั่งการ

    ตอบสนองตามหน้าที่และบันทึกผล

เหตุฉุกเฉินไม่ต้องรอ AI ยืนยัน

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

องค์ประกอบบทบาทสถานะที่ต้องแยกให้ชัด
iBOC + Analyticsตรวจจับ ค้นหา แสดงภาพ Dashboard และแจ้งเตือนตามเงื่อนไขมีเอกสารผลิตภัณฑ์; ทดสอบเวอร์ชันและ Use Case จริง
Incident Gateway / SOSรับเหตุ กำหนดหน่วยรับผิดชอบ ตอบรับ ติดตาม และปิดเหตุข้อเสนอระบบเพิ่มเติม ต้องกำหนดเจ้าของและ Interface
Police Apps / ระบบเดิม สพฐ.รับหรือส่งข้อมูลตาม Workflow ของเจ้าของระบบยืนยัน API สิทธิ์เชื่อมต่อ และข้อตกลงก่อนผูกในขอบเขตส่งมอบ
เจ้าหน้าที่ / ผู้มีอำนาจตรวจสอบ ประเมิน แจ้งผู้เกี่ยวข้อง และตัดสินใจสั่งการกำหนดบทบาท ผู้รับผิดชอบ และการส่งเวรให้ชัดเจน

การส่ง Webhook หรือข้อความแจ้งเตือนจาก iBOC ไม่ได้ยืนยันว่าเชื่อม 191, OnePolice, KMPPP หรือระบบ Dispatch ได้แล้ว เอกสารที่ได้รับยังไม่รองรับข้อสรุปดังกล่าว

05

คำนวณจากสมมติฐานที่มองเห็นได้

คงตัวเลขตั้งต้นจากไฟล์เดิมเพื่อใช้เปรียบเทียบ: ตำรวจ 1,430 แห่ง × 100 กล้อง และโรงเรียน 30,000 แห่ง × 16 กล้อง รวม 623,000 กล้อง ตัวเลขนี้เป็นกรอบสมมติฐานโครงการ ไม่ใช่ทะเบียนจำนวนหน่วยงานหรือกล้องที่ยืนยันแล้ว

แบบจำลอง Storage และ WAN

แก้ค่าเพื่อสำรวจภาระงาน · หน่วยฐานสิบ
ขอบเขตไซต์และกล้อง
ไซต์ตามสมมติฐาน 31,430 แห่งกล้องรวม 623,000 ตัว
การบันทึกทุกกล้องในพื้นที่
ข้อมูลที่ส่งผ่าน WAN สำหรับกล้องที่เปิด AI
วิดีโอดิบทุกกล้อง / วัน13.457 PBบันทึก 24 ชั่วโมง ยังไม่รวมส่วนเผื่อ
วิดีโอดิบตามระยะเก็บ403.704 PBรวมทุกไซต์ · 30 วัน
ข้อมูลภาพขาเข้า Central AI / วัน0 BEdge AI วิเคราะห์ภาพในพื้นที่
Event Payload / วัน4.000 GBจากกล้อง AI 1,000 ตัวตามสมมติฐาน
ข้อมูล AI ผ่าน WAN รวม / วัน4.000 GBภาพขาเข้า Central AI + Event Payload
อัตราข้อมูลเฉลี่ยเทียบเท่า0.370 Mbpsไม่ใช่ขนาดวงจรที่แนะนำ ต้องคำนวณ Peak เพิ่ม

WAN ยังไม่รวม Live/Playback, Archive/Backup, Retries และ Protocol Overhead; Storage ยังไม่รวม RAID/Replication, Index, ระบบสำรอง และพื้นที่เผื่อ แบบจำลองนี้ยังไม่ใช้กำหนดจำนวน GPU หรือราคาจัดซื้อ

สูตรและขอบเขตการนับข้อมูล

กล้องรวม N = (สถานี × กล้อง/สถานี) + (โรงเรียน × กล้อง/โรงเรียน)

วิดีโอ / วัน (Bytes) = N × Mbps × 1,000,000 × 86,400 ÷ 8

Event / วัน (Bytes) = กล้อง AI × Event/วัน × Payload MB × 1,000,000

เฟรมเข้า AI / วัน (Bytes) = กล้อง AI × FPS × KB/เฟรม × 1,000 × 86,400

สตรีมเข้า AI / วัน (Bytes) = กล้อง AI × Mbps × 1,000,000 × 86,400 ÷ 8

WAN AI รวม = สื่อขาเข้า Central AI + Event Payload โดยสมมติว่าภาพและ Event แต่ละชุดข้าม WAN หนึ่งครั้ง หากผล Event ถูกใช้ในศูนย์เดียวกันให้แยกส่วนนั้นออกจาก WAN ของไซต์ ไม่รวมการส่งซ้ำข้ามหลายระบบ

ค่าที่กรอกว่าง ติดลบ หรือเกินช่วงที่รับได้ จะแจ้งเตือนและจำกัดเฉพาะการคำนวณ; จำนวนกล้อง AI ที่คำนวณไม่เกินกล้องรวม

ขนาด AI Server ต้องอิงผลทดสอบต่อโมดูล

ระบุจำนวนช่อง AI พร้อมกัน, FPS ที่โมเดลใช้, การ Decode, โมเดลที่รันร่วมกัน, ขนาดภาพ, ความหน่วง p95 และงานค้นย้อนหลัง ก่อนเลือก GPU หรือ NPU ต้องให้ทีม iBOC ยืนยัน Runtime ที่รองรับและทดสอบชุดงานเดียวกับที่จะส่งมอบ

06

คงกรอบสองระยะ ตรวจรับตามภาระงาน

คงกรอบดำเนินงานจากข้อเสนอเดิม: ระยะที่ 1 ภาคกลางและภาคตะวันออก ระยะที่ 2 พื้นที่ที่เหลือ โดยทดสอบภายในงานออกแบบและตรวจรับแต่ละระยะ ไม่เพิ่มโครงการ PoC หรือ Phase 0 แยกต่างหาก

PHASE 01 / CENTRAL & EAST

ติดตั้งระบบและเปิดบริการระยะแรก

  • ยืนยันบัญชีจังหวัด ไซต์ กล้อง และโมดูลที่เปิดใช้จริง
  • ติดตั้งระบบหน่วยงาน iBOC และโครงสร้างพื้นฐานตามแบบที่อนุมัติ
  • เชื่อม Workflow รับเหตุและระบบเดิมตาม Interface ที่ได้รับอนุญาต
  • ทดสอบความแม่นยำ ภาระงาน สิทธิ์ข้อมูล และการทำงานเมื่อ WAN ขาด
  • ส่งมอบและตรวจรับตามเกณฑ์ที่กำหนดก่อนทดสอบ
PHASE 02 / REMAINING REGIONS

ขยายพื้นที่และกำลังประมวลผล

  • ขยายไซต์ตามบัญชีและขอบเขตระยะที่ 2 ที่ได้รับอนุมัติ
  • เพิ่ม AI, Database, Video, WAN และ Storage จากภาระงานที่วัดได้
  • ขยายการรับแจ้งเหตุและเจ้าหน้าที่รับผิดชอบให้ครบพื้นที่
  • ทดสอบการกระจายงาน การกู้คืน และผู้ใช้พร้อมกันตามแบบขยาย
  • ตรวจรับก่อนเปิดบริการแต่ละชุดพื้นที่
เกณฑ์ตรวจรับที่ต้องระบุในขอบเขตงาน
ทดสอบแยกตามโมดูลและกล้องจริง: Precision/Recall, False Alerts ต่อกล้องต่อวัน, ความหน่วงตั้งแต่ตรวจพบถึงแจ้งผู้รับ, ภาระผู้เฝ้าระวัง, งานค้นหา, ผู้ใช้พร้อมกัน, การขาดเครือข่าย และการกู้คืน ไม่กำหนด Accuracy หรือ SLA ตัวเลขเดียวให้ทุก Use Case
การแยกข้อมูลและการเข้าถึง
ยืนยันผู้มีสิทธิ์ดูภาพ ค้นบุคคล ส่งต่อเหตุ และนำข้อมูลออก แยกข้อมูลและดัชนีค้นหาตามหน่วยงาน ทดสอบการปฏิเสธสิทธิ์ข้ามหน่วยงาน พร้อมกำหนด Retention, Audit และขั้นตอนจัดการข้อมูลร่วมกับผู้รับผิดชอบของแต่ละหน่วยงาน
ความต่อเนื่องและหลักฐาน
แยกทดสอบ Local Recording, Local AI, Local Alert และ Central Services ตามองค์ประกอบที่ติดตั้งจริง กำหนดข้อมูลระบุแหล่งภาพ เวลา เหตุ ผู้เข้าถึง และความครบถ้วนของไฟล์สำหรับการส่งออกหลักฐาน ส่วน Hash, Legal Hold และคลังหลักฐานต้องยืนยันระบบที่รองรับ ไม่ถือว่า iBOC จัดให้ครบโดยอัตโนมัติ
การเชื่อมต่อและการสนับสนุน
ระบุรุ่นกล้อง โปรโตคอล VMS API, License, ข้อจำกัด Runtime และผู้รับผิดชอบแต่ละรอยต่อ กำหนดผู้ดูแลประจำวัน การส่งเวร การฝึกอบรม Support และแผนเปลี่ยนผู้ให้บริการก่อนปิดขอบเขตจัดซื้อ
07

แหล่งข้อมูลและประเด็นที่ยังต้องยืนยัน

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

  1. [1]
    01 iBOC Core Platform - Automation Rules.pdf

    หน้า 6–11: Core Standard, NVR, Object Search, Automation, API/Webhook และ Dashboard

  2. [2]
    02 iBOC Analytics Modules.pdf

    หน้า 2–4: INTR, LEFT, DENS, SPW และ FT

  3. [4]
    05 iBOC Face Recognition.pdf

    หน้า 3–10: FACE, การติดตามบนแผนที่ และ PERS; เส้นทางระหว่างกล้องเป็นการคาดการณ์

  4. [5]
    04 iBOC LPR _ Traffic Enforcement.pdf

    หน้า 3–4 และ 7–16: LPR, เงื่อนไขทะเบียนไทย, SPW, ILP, HEM, RIDE, RIDT และข้อกำหนดมุมกล้อง

  5. [6]
    iBOC Manual .docx

    คู่มือ App Version 2024.35.1: การค้นหา กล้อง ระบบอัตโนมัติ และ API Testing; ต้องยืนยัน Release ที่จะจัดส่งอีกครั้ง

  6. [7]
    Police_Innopolis_National_AI_Platform.html — ต้นฉบับ

    ที่มาของชื่อโครงการ สมมติฐาน 1,430 สถานี / 30,000 โรงเรียน และกรอบสองระยะ ไม่ใช่แหล่งยืนยันจำนวนไซต์จริง

สิ่งที่ปรับจากต้นฉบับ
  • ย้ายตัวเลขจำนวนไซต์และกล้องจากยอดยืนยันมาเป็นสมมติฐานที่แก้ไขได้
  • แยก Edge AI และ Central AI พร้อมข้อมูลภาพที่ต้องส่งจริง
  • เติมฟังก์ชัน iBOC ตามเอกสาร และแยกระบบที่ต้องพัฒนาหรือเชื่อมเพิ่ม
  • แก้ลำดับตรวจสอบเหตุและส่งต่อให้ผู้มีอำนาจ โดยไม่ปิดกั้นช่องทางฉุกเฉินเดิม
  • เพิ่ม WAN ขาเข้า AI ในแบบจำลอง และแยกจาก Storage, Live และ Archive
  • เปลี่ยนจากการล็อก Cloud/GPU เป็นทางเลือกตาม Runtime และผลทดสอบ
รายการที่เจ้าของโครงการต้องยืนยัน
บัญชีไซต์และจังหวัดแต่ละระยะ, จำนวนกล้องเดิม/ใหม่, ช่อง AI ต่อโมดูล, ตำแหน่งประมวลผล, เวอร์ชันและ License iBOC, ระบบเดิมและสิทธิ์ API, นโยบายข้อมูล/หลักฐาน และเกณฑ์ตรวจรับของแต่ละหน่วยงาน