ประกวดราคาจ้างเหมาเพิ่มประสิทธิภาพแพลตฟอร์มบริหารจัดการข้อมูลเชิงพื้นที่จากเซ็นเซอร์แบบเรียลไทม์
สำนักงานพัฒนาเทคโนโลยีอวกาศและภูมิสารสนเทศ (สทอภ.) มีความต้องการพัฒนาและเพิ่มประสิทธิภาพแพลตฟอร์มบริหารจัดการข้อมูลเชิงพื้นที่จากเซ็นเซอร์แบบเรียลไทม์ เพื่อให้สามารถรองรับการจัดเก็บ ประมวลผล และให้บริการข้อมูลปริมาณมากจากอุปกรณ์ IoT ได้อย่างมีเสถียรภาพ รวดเร็ว และปลอดภัยตามมาตรฐานสากล OGC SensorThings API โดยมีเป้าหมายเพื่อสนับสนุนการบูรณาการข้อมูลและการตัดสินใจเชิงนโยบายในบริบทต่างๆ เช่น การติดตามสิ่งแวดล้อม การจัดการภัยพิบัติ และการพัฒนาเมืองอย่างยั่งยืน
ขอบเขตงานประกอบด้วยการบริหารจัดการโครงการร่วมกับ สทอภ. เริ่มตั้งแต่การประชุมเริ่มโครงการ การจัดทำแผนบริหารโครงการ การวิเคราะห์ระบบบริการข้อมูลเชิงพื้นที่ (SDS) ที่มีอยู่เดิมเพื่อนำไปสู่ข้อเสนอแนะในการพัฒนา จากนั้นจึงดำเนินการปรับปรุงการจัดเก็บและให้บริการข้อมูลเชิงพื้นที่จากเซ็นเซอร์แบบเรียลไทม์ โดยต้องออกแบบสถาปัตยกรรมให้รองรับมาตรฐาน OGC และสภาพแวดล้อมของ สทอภ. พัฒนาระบบให้สามารถเชื่อมต่อข้อมูลจากสถานีตรวจวัดภาคพื้นดินต่างๆ และรองรับการสื่อสารแบบ Pub/Sub ผ่าน WebSocket และ MQTT รวมถึงระบบแจ้งเตือนเมื่อข้อมูลผิดปกติ
ผู้รับจ้างต้องดำเนินการปรับปรุงการจัดเก็บข้อมูลอย่างเป็นระบบทั้งในรูปแบบไฟล์และฐานข้อมูลเชิงพื้นที่ (Geospatial Database) พร้อมออกแบบกระบวนการบริหารจัดการข้อมูลแบบ Hot Data และ Archive Data นอกจากนี้ยังต้องพัฒนาต่อยอดแพลตฟอร์ม จัดฝึกอบรมเชิงปฏิบัติการและจัดทำคู่มือสำหรับบุคลากรของ สทอภ. และจัดทำแผนการบำรุงรักษาระบบหลังการส่งมอบ
English summary
This project aims to develop and enhance the efficiency of the Geo-Spatial and Geophysics Research Institute’s (GISTDA) real-time sensor data management platform. The primary objective is to enable the platform to store and serve data from IoT devices in compliance with the international OGC SensorThings API standard. The goal is to create a scalable, stable, and secure central platform for real-time sensor data to support data integration, policy decision-making, and applications in environmental monitoring, disaster management, and sustainable urban planning.
The scope of work includes collaborative project management with GISTDA, starting with a kick-off meeting, project plan development, and a thorough analysis of the existing Spatial Data Service (SDS) system to inform the upgrade strategy. The contractor must then redesign and upgrade the real-time geospatial sensor data storage and service architecture to align with OGC standards and GISTDA’s infrastructure. This involves developing the system to connect data from various ground-based field stations (e.g., air quality, water level stations), support Pub/Sub communication via WebSocket and MQTT protocols, and implement alerting mechanisms for data anomalies.
Furthermore, the contractor is required to systematically improve data storage in both file-based and Geospatial Database formats, designing data management processes for Hot Data and Archive Data. Additional responsibilities include further platform development, organizing hands-on training workshops and creating manuals for GISTDA personnel, and formulating a comprehensive system maintenance plan post-delivery.
ไม่ระบุสถานที่ตั้งโครงการที่ชัดเจน (เป็นโครงการพัฒนาระบบซอฟต์แวร์/แพลตฟอร์ม)
ข้อมูลเชิงลึกของโครงการ
AI วิเคราะห์ ปลดล็อกแล้วเป้าหมายโครงการ
- เพื่อเพิ่มประสิทธิภาพแพลตฟอร์มบริหารจัดการข้อมูลเชิงพื้นที่จากเซ็นเซอร์แบบเรียลไทม์ ให้สามารถรองรับการจัดเก็บและให้บริการข้อมูลเชิงพื้นที่จากอุปกรณ์ IoT (Internet of Things) เป็นไปตามมาตรฐาน OGC SensorThings API
ขอบเขตของงาน
งานหลักประกอบด้วย 5 ด้าน ดังนี้
-
บริหารจัดการโครงการร่วมกับ สทอภ.
- จัดประชุมเริ่มโครงการ (Kick-off Meeting) ภายใน 15 วันหลังลงนามสัญญา
- จัดทำแผนการบริหารโครงการเสนอต่อคณะกรรมการตรวจรับพัสดุเพื่อขอความเห็นชอบ
- วิเคราะห์การทำงานของระบบบริการข้อมูลจากสถานีตรวจวัดทางด้านอากาศ (SDS) ที่มีอยู่เดิม พร้อมจัดทำข้อเสนอแนะและแนวทางการพัฒนาต่อยอด รวมถึงจัดทำเอกสารสรุปผลการวิเคราะห์
- จัดประชุมอัปเดตความก้าวหน้าอย่างน้อยเดือนละ 1 ครั้ง
-
ปรับปรุงการจัดเก็บและให้บริการข้อมูลเชิงพื้นที่จากเซ็นเซอร์แบบเรียลไทม์
- ศึกษา ออกแบบ พัฒนาและปรับปรุงให้สอดคล้องกับ Infrastructure และ Environment ของ สทอภ.
- ออกแบบการจัดเก็บและให้บริการข้อมูล IoT/Geospatial Sensor Data ตามมาตรฐาน OGC SensorThings API
- ดำเนินการเชื่อมต่อข้อมูลจาก Field Station ของ สทอภ. (เช่น สถานีตรวจวัดคุณภาพอากาศ, สถานีตรวจวัดระดับน้ำ)
- พัฒนาระบบให้รองรับการเชื่อมต่ออุปกรณ์ IoT ด้วยกลไก Publish/Subscribe ผ่าน WebSocket และ MQTT
- พัฒนาระบบให้รองรับการรับ-ส่งข้อมูลสํารวจ (Observation) จาก Sensor แบบต่อเนื่อง
- พัฒนาระบบแจ้งเตือนเมื่อไม่มีข้อมูลเข้ามาหรือข้อมูลผิดปกติ
- พัฒนา APIs Health Check สำหรับตรวจสอบสถานะบริการ
- ปรับปรุงการจัดเก็บข้อมูลจาก Sensor ให้เป็นระบบอย่างมีมาตรฐาน ทั้งในรูปแบบไฟล์และ Geospatial Database
-
พัฒนาและปรับปรุงต่อยอดแพลตฟอร์มบริหารจัดการข้อมูลเชิงพื้นที่จากเซ็นเซอร์แบบเรียลไทม์
- นำผลการวิเคราะห์ระบบเดิมมาใช้เป็นแนวทางในการพัฒนาและปรับปรุงระบบตามขอบเขตงาน
-
จัดฝึกอบรมเชิงปฏิบัติการเพื่อพัฒนาศักยภาพบุคลากรของ สทอภ. พร้อมจัดทำคู่มือ
- จัดฝึกอบรมเชิงปฏิบัติการ
- จัดทำคู่มือการใช้งาน/บำรุงรักษา
-
จัดทำแผนการบำรุงรักษา (Maintenance Plan)
- จัดทำแผนสำหรับการบำรุงรักษาระบบหลังการส่งมอบ
สิ่งที่ต้องส่งมอบ
- รายงานสรุปการประชุมเริ่มโครงการ (Kick-off Meeting)
- แผนการบริหารโครงการ (Project Management Plan) ที่ได้รับความเห็นชอบ
- เอกสารสรุปผลการวิเคราะห์การทำงานระบบ SDS เดิม พร้อมข้อเสนอแนะในการพัฒนาปรับปรุง
- รายงานการประชุมความก้าวหน้า (อย่างน้อยเดือนละ 1 ครั้ง)
- แพลตฟอร์มที่พัฒนาตามมาตรฐาน OGC SensorThings API และข้อกำหนดทางเทคนิคทั้งหมด
- เอกสารการออกแบบโครงสร้างการจัดเก็บข้อมูล (ทั้งไฟล์และฐานข้อมูล)
- APIs Health Check
- ระบบที่เชื่อมต่อกับ Field Station ของ สทอภ. ตามที่กำหนด
- ระบบแจ้งเตือนเมื่อข้อมูลผิดปกติ
- คู่มือการใช้งาน/บำรุงรักษา
- แผนการบำรุงรักษาระบบ (Maintenance Plan)
- รายงานสรุปการจัดฝึกอบรมเชิงปฏิบัติการ
ระยะเวลาดำเนินการ
- เริ่มโครงการ: ต้องจัดประชุม Kick-off Meeting ภายใน 15 วัน นับถัดจากวันลงนามในสัญญา
- ระยะเวลาในการดำเนินงาน: ไม่ได้ระบุระยะเวลาสัญญาหรือวันสิ้นสุดโครงการที่ชัดเจนในเอกสาร TOR ที่ให้มา ระยะเวลาจะระบุในแผนการบริหารโครงการ (Gantt Chart) ที่ผู้รับจ้างต้องเสนอเพื่อขอความเห็นชอบ
- การรายงานความก้าวหน้า: ต้องจัดประชุมอัปเดตความก้าวหน้าอย่างน้อยเดือนละ 1 ครั้ง
คุณสมบัติผู้เสนอราคา
- Eligibility Requirements: ผู้ยื่นข้อเสนอต้องเป็นนิติบุคคลที่มีอาชีพรับจ้างที่ประกวดราคาอิเล็กทรอนิกส์ (ข้อ 3.7)
- Standards Compliance: -
- Experience: -
- Previous Project Cost: -
- Technical Capabilities: -
- Personnel: -
(หมายเหตุ: จากเอกสาร TOR ที่ให้มา ไม่มีข้อกำหนดเฉพาะทางเทคนิคเกี่ยวกับคุณสมบัติผู้ยื่นข้อเสนอ นอกเหนือจากข้อกำหนดพื้นฐานทางกฎหมายและการไม่ต้องห้ามตามระเบียบการจัดซื้อจัดจ้างภาครัฐ)
เกณฑ์การพิจารณา
- ไม่ได้ระบุเกณฑ์การประเมินข้อเสนอ (Evaluation Criteria) ไว้ในส่วนของ TOR ที่ให้มา
ข้อกำหนดทางเทคนิค
โครงการมุ่งพัฒนาระบบให้สอดคล้องกับมาตรฐานและสถาปัตยกรรมสมัยใหม่ ดังนี้
- มาตรฐาน: ระบบต้องเป็นไปตามมาตรฐาน OGC SensorThings API สำหรับการให้บริการข้อมูลเซ็นเซอร์เชิงพื้นที่ และควรพิจารณามาตรฐาน Cloud-Optimized Geospatial Formats สำหรับการจัดเก็บข้อมูล
- สถาปัตยกรรมระบบ: ควรออกแบบตามแนวคิด Microservices และรองรับการทำงานแบบ Containerized บน Kubernetes หรือสถาปัตยกรรมอื่นที่เหมาะสมกว่า
- การเชื่อมต่อข้อมูล: ระบบต้องสามารถเชื่อมต่อข้อมูลจากอุปกรณ์ภาคพื้นดิน (Field Station) ของ สทอภ. เช่น สถานีตรวจวัดคุณภาพอากาศและระดับน้ำ
- โปรโตคอลการสื่อสาร: ต้องรองรับกลไก Publish/Subscribe (Pub/Sub) ผ่าน WebSocket และ MQTT สำหรับการเชื่อมต่ออุปกรณ์ IoT
- การจัดการข้อมูล: ต้องออกแบบกระบวนการบริหารจัดการข้อมูลจาก Sensor แยกเป็น Hot Data (สำหรับให้บริการทันที) และ Archive Data (สำหรับจัดเก็บเรียกย้อนหลัง) ทั้งในรูปแบบไฟล์และ Geospatial Database
- การแจ้งเตือน: ระบบต้องสามารถแจ้งเตือนผ่านอีเมลหรือช่องทางที่เหมาะสมเมื่อไม่มีการรับส่งข้อมูลหรือข้อมูลมีค่าผิดปกติ
- การตรวจสอบระบบ: ต้องพัฒนา APIs Health Check เพื่อตรวจสอบสถานะบริการ
- การออกแบบส่วนต่อประสานผู้ใช้: ต้องออกแบบ Screen Designs โดยใช้เครื่องมือเช่น Figma เพื่อนำเสนอเบื้องต้น
เงื่อนไขสัญญา
- การประชุมเริ่มโครงการ: ต้องจัดภายใน 15 วันหลังลงนามสัญญา
- การส่งมอบและพิจารณา: ผู้รับจ้างต้องเสนอแผนบริหารโครงการ, ผลการวิเคราะห์ระบบเดิม, และแบบ Screen Designs ต่อคณะกรรมการตรวจรับพัสดุเพื่อขอความเห็นชอบก่อนดำเนินการ
- การเปลี่ยนแปลงขอบเขตงาน: กรณีอุปกรณ์ Field Station ไม่พร้อมให้ข้อมูล สามารถเสนอเปลี่ยนการเชื่อมต่อได้ โดยต้องแจ้งและขอความเห็นชอบจากคณะกรรมการตรวจรับพัสดุก่อนดำเนินการ
- การรายงาน: ต้องจัดประชุมรายงานความก้าวหน้าอย่างน้อยเดือนละ 1 ครั้ง
- เงื่อนไขการจ่ายเงิน/บทลงโทษ: ไม่ได้ระบุในส่วน TOR ที่ให้มา
คำถามที่พบบ่อย (FAQ)
-
Q: โครงการนี้ต้องการพัฒนาระบบเดิมหรือสร้างระบบใหม่ทั้งหมด?
A: เป็นการเพิ่มประสิทธิภาพและพัฒนาต่อยอดจากแพลตฟอร์มบริหารจัดการข้อมูลเชิงพื้นที่จากเซ็นเซอร์แบบเรียลไทม์ที่มีอยู่เดิมของ สทอภ. โดยผู้รับจ้างต้องเริ่มจากการวิเคราะห์ระบบเดิม (SDS) ก่อนนำไปออกแบบและพัฒนาต่อ -
Q: ระบบต้องเชื่อมต่อกับแหล่งข้อมูลใดบ้าง?
A: ระบบต้องสามารถเชื่อมต่อข้อมูลจากอุปกรณ์เก็บข้อมูลภาคพื้นดิน (Field Station) ของ สทอภ. เป็นหลัก เช่น สถานีตรวจวัดคุณภาพอากาศและสถานีตรวจวัดระดับน้ำ รวมถึงอาจมีข้อมูลจากระบบ GNSS และกล้อง CCTV ตามที่ สทอภ. กำหนดในภายหลัง -
Q: ระบบต้องรองรับการเชื่อมต่อกับอุปกรณ์ IoT ผ่านช่องทางใด?
A: ระบบต้องรองรับกลไกการสื่อสารแบบ Publish/Subscribe (Pub/Sub) ผ่านโปรโตคอล WebSocket และ MQTT ซึ่งเป็นมาตรฐานที่ใช้กันทั่วไปในอุปกรณ์ IoT -
Q: ข้อมูลที่จัดเก็บมีรูปแบบใดบ้าง และจัดการอย่างไร?
A: ข้อมูลจะถูกจัดเก็บทั้งในรูปแบบไฟล์ (file base) และระบบจัดการฐานข้อมูลเชิงพื้นที่ (Geospatial Database) โดยจะออกแบบแบ่งประเภทการจัดการเป็น Hot Data (สำหรับให้บริการทันที) และ Archive Data (สำหรับจัดเก็บเรียกย้อนหลัง) -
Q: มีความต้องการด้านการแจ้งเตือนอะไรบ้าง?
A: ระบบต้องสามารถแจ้งเตือนอัตโนมัติไปยังผู้ดูแลผ่านอีเมลหรือช่องทางอื่นเมื่อตรวจพบว่าไม่มีข้อมูลไหลเข้า系統 (Data Gap) หรือข้อมูลที่เข้ามามีค่าผิดปกติเกินเกณฑ์มาตรฐานที่กำหนด -
Q: ผู้รับจ้างต้องส่งมอบเอกสารการออกแบบใดบ้าง?
A: ต้องจัดทำเอกสารการออกแบบหลายประเภท เช่น สถาปัตยกรรมภาพรวม, Interaction Overview Diagrams, User Flow Diagrams, โครงสร้างการจัดเก็บข้อมูล (ทั้งไฟล์และ E-R Model ของฐานข้อมูล) และ Screen Designs เบื้องต้นด้วย Figma -
Q: โครงการมีกิจกรรมฝึกอบรมด้วยหรือไม่?
A: ใช่ ผู้รับจ้างมีหน้าที่จัดฝึกอบรมเชิงปฏิบัติการเพื่อพัฒนาศักยภาพบุคลากรของ สทอภ. ที่จะมาใช้และดูแลระบบ พร้อมทั้งจัดทำคู่มือประกอบการฝึกอบรมและการใช้งาน -
Q: หลังส่งมอบระบบแล้ว โครงการจบเลยหรือไม่?
A: ไม่จบทันที ผู้รับจ้างมีหน้าที่จัดทำแผนการบำรุงรักษาระบบ (Maintenance Plan) มอบให้กับ สทอภ. เพื่อใช้เป็นแนวทางในการดูแลระบบต่อไปหลังโครงการสิ้นสุด -
Q: ระบบต้องมีฟังก์ชันตรวจสอบสุขภาพ (Health Check) หรือไม่?
A: ใช่ ผู้รับจ้างต้องพัฒนา APIs Health Check ขึ้นมาเฉพาะสำหรับใช้ตรวจสอบสถานะการให้บริการของ API ต่างๆ ในระบบทั้งหมด เพื่อความสะดวกในการดูแลและตรวจสอบ -
Q: หากอุปกรณ์ภาคพื้นดินที่กำหนดเชื่อมต่อไม่ได้ จะทำอย่างไร?
A: ผู้รับจ้างสามารถเสนอปรับเปลี่ยนการเชื่อมต่อข้อมูลจากอุปกรณ์นั้นได้ หากอุปกรณ์ไม่มีความพร้อมในการรับส่งข้อมูลหรือข้อมูลไม่มีคุณภาพ แต่ต้องแจ้งและขอความเห็นชอบจากคณะกรรมการตรวจรับพัสดุก่อนดำเนินการ
เอกสารขอบเขตงาน (TOR) ฉบับเต็ม
หน้า 1/19
ขอบเขตของงาน (Term of Reference: TOR)
จ้างเหมาเพิ่มประสิทธิภาพแพลตฟอร์มบริหารจัดการข้อมูลเชิงพื้นที่จากเซ็นเซอร์แบบเรียลไทม์ ภายใต้แผนงานการบํารุงรักษาระบบโครงสร้างพื้นฐานการบริการภูมิสารสนเทศแบบออนไลน์
- หลักการและเหตุผล
ปัจจุบัน สํานักงานพัฒนาเทคโนโลยีอวกาศและภูมิสารสนเทศ (องค์การมหาชน) หรือ สทอภ. มีบทบาท
สําคัญในการจัดเก็บบริหารจัดการและให้บริการข้อมูลภูมิสารสนเทศเพื่อสนับสนุนการตัดสินใจของหน่วยงาน
ภาครัฐ ภาคเอกชน และประชาชน การเพิ่มขึ้นอย่างต่อเนื่องของข้อมูลจากระบบเซ็นเซอร์หลากหลายประเภท โดยเฉพาะข้อมูลที่มีการไหลเวียนแบบเรียลไทม์ ทําให้เกิดความท้าทายในการจัดเก็บ ประมวลผล และให้บริการ ข้อมูลที่มีปริมาณมาก (high-volume) และต้องการความถูกต้องแม่นยํา รวดเร็ว และปลอดภัย เพื่อรองรับ ความต้องการดังกล่าวจึงจําเป็นต้องพัฒนาและเพิ่มประสิทธิภาพแพลตฟอร์มบริหารจัดการข้อมูลเชิงพื้นที่
จากเซ็นเซอร์แบบเรียลไทม์ ให้สามารถจัดเก็บและให้บริการข้อมูลจํานวนมากได้อย่างเสถียรและขยายตัวได้ (Scalable) พร้อมรองรับการแลกเปลี่ยนและบูรณาการข้อมูลระหว่างหน่วยงานอย่างไร้รอยต่อตามมาตรฐานสากล OGC SensorThings API ซึ่งเป็นมาตรฐานที่ใช้สําหรับจัดเก็บและให้บริการข้อมูลเซ็นเซอร์เชิงพื้นที่จากอุปกรณ์ Internet of Things (IoT) สามารถนําข้อมูลไปประยุกต์ใช้ในหลากหลายบริบท เช่น การติดตามสถานการณ์ สิ่งแวดล้อม การบริหารจัดการทรัพยากรธรรมชาติ การจัดการภัยพิบัติ และการวางแผนพัฒนาเมืองอย่างยั่งยืน
ดังนั้นการดําเนินงานนี้จะเป็นกลไกสําคัญในการยกระดับความสามารถของแพลตฟอร์มบริหารจัดการ ข้อมูลเชิงพื้นที่จากเซ็นเซอร์แบบเรียลไทม์ ให้มีประสิทธิภาพตามมาตรฐาน OGC Sensor Things API มุ่งสู่เป็น แพลตฟอร์มฯศูนย์กลางการให้บริการข้อมูลเซ็นเซอร์แบบเรียลไทม์ ของ สทอภ. เพื่อสนับสนุนการบูรณาการข้อมูล
การตัดสินใจเชิงนโยบาย และการสร้างคุณค่าจากข้อมูลเชิงพื้นที่ได้อย่างสูงสุด - วัตถุประสงค์
เพื่อเพิ่มประสิทธิภาพแพลตฟอร์มบริหารจัดการข้อมูลเชิงพื้นที่จากเซ็นเซอร์แบบเรียลไทม์ ให้สามารถ รองรับการจัดเก็บและให้บริการข้อมูลเชิงพื้นที่จากอุปกรณ์ IoT (Internet of Things) เป็นไปตามมาตรฐาน OGC
Sensor Things API - คุณสมบัติของผู้ยื่นข้อเสนอ
3.1 มีความสามารถตามกฎหมาย 3.2 ไม่เป็นนิติบุคคลล้มละลาย
3.3 ไม่อยู่ระหว่างเลิกกิจการ
2428
ประธาน
กรรมการ
กรรมการ
Bow
กรรมการ
หน้า 2/19
3.4 ไม่เป็นนิติบุคคลซึ่งอยู่ระหว่างถูกระงับการยื่นข้อเสนอหรือทําสัญญากับหน่วยงานของรัฐไว้ชั่วคราว เนื่องจากเป็นผู้ที่ไม่ผ่านเกณฑ์การประเมินผลการปฏิบัติงานของผู้ประกอบการตามระเบียบที่ รัฐมนตรีว่าการกระทรวงการคลังกําหนดตามที่ประกาศเผยแพร่ในระบบเครือข่ายสารสนเทศของ
กรมบัญชีกลาง
3.5 ไม่เป็นนิติบุคคลซึ่งถูกระบุชื่อไว้ในบัญชีรายชื่อผู้ทิ้งงานและได้แจ้งเวียนชื่อให้เป็นผู้ทิ้งงานของ หน่วยงานของรัฐในระบบเครือข่ายสารสนเทศของกรมบัญชีกลางซึ่งรวมถึงนิติบุคคลที่ผู้ทิ้งงานเป็น หุ้นส่วนผู้จัดการ กรรมการผู้จัดการ ผู้บริหาร ผู้มีอํานาจในการดําเนินงานในกิจการของนิติบุคคลนั้น 3.6 มีคุณสมบัติและไม่มีลักษณะต้องห้ามตามที่คณะกรรมการนโยบายการจัดซื้อจัดจ้างและการบริหาร
พัสดุภาครัฐกําหนดในราชกิจจานุเบกษา
3.7 นิติบุคคลที่มีอาชีพรับจ้างที่ประกวดราคาอิเล็กทรอนิกส์ ดังกล่าว
3.8 ไม่เป็นผู้มีผลประโยชน์ร่วมกันกับ ผู้ยื่นข้อเสนอ รายอื่นที่เข้ายื่นข้อเสนอ ให้แก่ สทอภ. ณ วันประกาศ ประกวดราคาอิเล็กทรอนิกส์ หรือไม่เป็นผู้กระทําการอื่นเป็นการอันเป็นขัดขวางการแข่งขันราคาอย่าง เป็นธรรมในการ ประกวดราคาอิเล็กทรอนิกส์ ครั้งนี้
3.9 ไม่เป็นผู้ได้รับเอกสิทธิ์หรือความคุ้มกัน ซึ่งอาจปฏิเสธไม่ยอมขึ้นศาลไทย เว้นแต่รัฐบาลของผู้ยื่น
ข้อเสนอได้มีคําสั่งให้สละเอกสิทธิ์และความคุ้มกันเช่นว่านั้น
3.10 ผู้ยื่นข้อเสนอ ที่ยื่นข้อเสนอในรูปแบบของ “กิจการร่วมค้า" ต้องมีคุณสมบัติดังนี้
3.10.1 กรณีที่ข้อตกลงระหว่างผู้เข้าร่วมค้า กําหนดให้ผู้เข้าร่วมค้ารายใดรายหนึ่งเป็นผู้เข้าร่วม ค้าหลัก ข้อตกลงระหว่างผู้เข้าร่วมค้าจะต้องมีการกําหนดสัดส่วนหน้าที่ และความรับผิดชอบ ในปริมาณงาน สิ่งของ หรือมูลค่าตามสัญญาของผู้เข้าร่วมค้าหลักมากกว่าผู้เข้าร่วมค่ารายอื่น
ทุกราย
3.10.2 กรณีที่ข้อตกลงระหว่างผู้เข้าร่วมค้า กําหนดให้ผู้เข้าร่วมค้ารายใดรายหนึ่งเป็นผู้เข้าร่วมค้า หลัก กิจการร่วมค้านั้นต้องใช้ผลงานของผู้เข้าร่วมค้าหลักรายเดียว เป็นผลงานของกิจการ ร่วมค้าที่ยื่นข้อเสนอ
สําหรับข้อตกลงระหว่างผู้เข้าร่วมค้า ที่ไม่ได้กําหนดให้ผู้เข้าร่วมค้ารายใดเป็นผู้เข้าร่วมค้าหลัก
ผู้เข้าร่วมค้าทุกรายจะต้องมีคุณสมบัติครบถ้วนตามเงื่อนไขที่กําหนดไว้ในเอกสารเชิญชวน
3.10.3 กรณีที่ข้อตกลงระหว่างผู้เข้าร่วมค้า กําหนดให้มีการมอบหมายผู้เข้าร่วมค้ารายใดรายหนึ่งเป็น ผู้ยื่นข้อเสนอในนามกิจการร่วมค้า การยื่นข้อเสนอดังกล่าวไม่ต้องมีหนังสือมอบอํานาจ สําหรับข้อตกลงระหว่างผู้เข้าร่วมค้า ที่ไม่ได้กําหนดให้ผู้เข้าร่วมค้ารายใดรายหนึ่งเป็นผู้ยื่น
ข้อเสนอ ผู้เข้าร่วมค้าทุกรายจะต้องลงลายชื่อในหนังสือมอบอํานาจ ให้ผู้เข้าร่วมค้ารายใด
รายหนึ่งเป็นผู้ยื่นข้อเสนอในนามกิจการร่วมค้า
Mas
ประธาน
سطلاح
กรรมการ
กรรมการ
In
กรรมการ
หน้า 3/19
3.11 ผู้ยื่นข้อเสนอต้องลงทะเบียนที่มีข้อมูลถูกต้องครบถ้วนในระบบจัดซื้อจัดจ้างภาครัฐด้วยอิเล็กทรอนิกส์
(Electronic Government Procurement: e-GP) ของกรมบัญชีกลาง
3.12 กรณีผู้ยื่นข้อเสนอเป็นผู้ประกอบการที่ได้ขึ้นทะเบียนเป็นผู้ประกอบการวิสาหกิจขนาดกลางและขนาด
ย่อม (SMEs) จะต้องยื่นสําเนาใบทะเบียนผู้ประกอบการวิสาหกิจขนาดกลางและขนาดย่อม (SMEs) - ขอบเขตการดําเนินงาน
4.1 บริหารจัดการโครงการร่วมกับ สทอภ.
4.2 ปรับปรุงการจัดเก็บและให้บริการข้อมูลเชิงพื้นที่จากเซ็นเซอร์แบบเรียลไทม์
4.3 พัฒนาและปรับปรุงต่อยอดแพลตฟอร์มบริหารจัดการข้อมูลเชิงพื้นที่จากเซ็นเซอร์แบบเรียลไทม์ 4.4 จัดฝึกอบรมเชิงปฏิบัติการเพื่อพัฒนาศักยภาพบุคลากรของ สทอภ. พร้อมจัดทําคู่มือ
4.5 จัดทําแผนการบํารุงรักษา (Maintenance) - ข้อกําหนดทางเทคนิค
5.1 บริหารจัดการโครงการร่วมกับ สทอภ. ดังนี้
5.1.1 ผู้รับจ้างต้องจัดประชุมเริ่มโครงการ (Kick-off Meeting) ร่วมกับคณะกรรมการตรวจรับพัสดุ และเจ้าหน้าที่ของ สทอภ. ภายใน 15 วัน นับถัดจากวันลงนามในสัญญา พร้อมสรุปรายงาน
การประชุม
5.1.2 ผู้รับจ้างต้องจัดทําแผนการบริหารโครงการเสนอต่อคณะกรรมการตรวจรับพัสดุ
เพื่อพิจารณาให้ความเห็นชอบ โดยมีรายละเอียดอย่างน้อย ดังต่อไปนี้
5.1.2.1 กรอบแนวคิดในการดําเนินงาน
5.1.2.2 โครงสร้างบุคลากรและหน้าที่ความรับผิดชอบ
5.1.2.3 แผนการดําเนินงานปรับปรุงและพัฒนาระบบ (Implementation Plan) ที่มี รายละเอียดกิจกรรมในแต่ละขั้นตอน ระยะเวลาดําเนินการ และสิ่งที่ต้องส่งมอบใน แต่ละกิจกรรม ในรูปแบบ Gantt Chart
5.1.3 ผู้รับจ้างต้องวิเคราะห์การทํางานระบบบริการข้อมูลจากสถานีตรวจวัดทางด้านอากาศ (Spatial data service : SDS) ที่มีอยู่เดิม โดยให้ข้อเสนอแนะและจัดทําแนวทางในการพัฒนา ต่อยอด ดังนี้
5.1.3.1
สถาปัตยกรรมภาพรวมของระบบ ต้องสอดคล้องตามหลักแนวคิด Microservices
และรองรับการทํางานแบบ Containerized บน Kubernetes หรือสถาปัตยกรรม อื่นๆ ที่เหมาะสมกว่า
08745
ประธาน
กรรมการ
กรรมการ
In
กรรมการ
หนา 4/19
5.1.3.2 สถาปัตยกรรมการให้บริการข้อมูล IoT (Internet of things) ต้องสอดคล้องตาม
หลักแนวคิดตามมาตรฐาน OGC หรือมาตรฐานอื่นๆ ที่เหมาะสมกว่า
5.1.3.3 สถาปัตยกรรมการจัดเก็บข้อมูล IoT (Internet of things) ต้องเป็นไปตาม มาตรฐาน OGC หรือให้เป็นไปตาม Cloud-Optimized Geospatial Formats หรือสถาปัตยกรรมอื่นๆ ที่เหมาะสมกว่า
5.1.3.4 รายการข้อมูลและเซอร์วิสทั้งหมดบนระบบ
5.1.3.5
5.1.3.6
Interaction Overview Diagrams ต้องครอบคลุมทุกส่วนของระบบ
User Flow Diagrams แสดงการใช้งานของผู้ใช้
5.1.3.7 ออกแบบ Screen Designs โดยใช้ figma เพื่อเสนอคณะกรรมการตรวจรับพัสดุ ใน
เบื้องต้น
5.1.3.8 ผู้รับจ้างต้องนําผลที่วิเคราะห์ได้มาใช้เป็นแนวทางในการพัฒนาและปรับปรุงตาม
ขอบเขตงานในโครงการจ้างครั้งนี้
5.1.3.9 ผู้รับจ้างต้องจัดทําเอกสารสรุปผลการวิเคราะห์การทํางานระบบ SDS ที่มีอยู่เดิม
พร้อมข้อเสนอแนะในการพัฒนาปรับปรุงระบบ
5.1.4 ผู้รับจ้างต้องจัดให้มีการประชุมอัปเดตรายงานความก้าวหน้าการดําเนินงานตามแผนงาน อย่าง น้อยเดือนละ 1 ครั้ง หรือตามความเหมาะสมของเนื้องาน และสรุปรายงานการประชุม
5.2 ปรับปรุงการจัดเก็บและให้บริการข้อมูลเชิงพื้นที่จากเซ็นเซอร์แบบเรียลไทม์
5.2.1 ต้องศึกษา ออกแบบ พัฒนาและปรับปรุงให้สอดคล้องกับสถาปัตยกรรมโครงสร้างพื้นฐาน
(Infrastructure) และสภาพแวดล้อมการทํางาน (Environment) ของ สทอภ.
5.2.2 ออกแบบการจัดเก็บและให้บริการข้อมูล IoT และข้อมูลเชิงพื้นที่ (Geospatial Sensor Data)
ต้องเป็นไปตามมาตรฐาน OGC SensorThings API
5.2.3 ผู้รับจ้างต้องดําเนินการเชื่อมต่อข้อมูลจากอุปกรณ์เก็บข้อมูลภาคพื้นดิน (Field Station) เช่น สถานีตรวจวัดคุณภาพอากาศ ของ สทอภ., สถานีตรวจวัดระดับน้ํา ของ สทอภ. ข้อมูลจาก ระบบนําทางด้วยดาวเทียม (GNSS) (ถ้ามี), กล้อง CCTV ตามที่ สทอภ. กําหนด (ถ้ามี) หรือ ตามที่ สทอภ. กําหนด ทั้งนี้สามารถปรับเปลี่ยนการเชื่อมต่อข้อมูลจากอุปกรณ์เก็บข้อมูล ภาคพื้นดินได้ ในกรณีอุปกรณ์นั้นๆ ไม่มีความพร้อมในการรับส่งข้อมูล หรือข้อมูลไม่มีคุณภาพ ซึ่งต้องดําเนินการแจ้งและเสนอต่อคณะกรรมการตรวจรับพัสดุ เพื่อพิจารณาให้ความเห็นชอบ
กอนดําเนินการ
5.2.4 ระบบต้องสามารถเชื่อมต่ออุปกรณ์ IoT รองรับกลไกการสื่อสารแบบ Publish/Subscribe
(Pub/Sub) ผ่านโปรโตคอล WebSocket และ MQTT ได้
mns
ประธาน
กรรมการ_
AN
กรรมการ
An
กรรมการ
225
หน้า 5/19
5.2.5 ระบบต้องรองรับการรับ-ส่งข้อมูลสํารวจ (Observation) จากอุปกรณ์ตรวจวัด (Sensor)
แบบต่อเนื่อง
5.2.6 ระบบต้องสามารถแจ้งเตือน กรณีที่ไม่มีการรับส่งข้อมูลมายังระบบฯ หรือข้อมูลมีค่าผิดปกติไม่ เป็นไปตามเกณฑ์ช่วงค่ามาตรฐาน ผ่านช่องทาง email หรือช่องทางอื่นๆ ที่เหมาะสม ถึง ผู้รับผิดชอบในการดูแลอุปกรณ์โดยตรง
5.2.7 ผู้รับจ้างต้องดําเนินการพัฒนา APIs Health Check สําหรับใช้ตรวจสอบสถานะบริการทั้งหมด
ของระบบ
5.2.8 ผู้รับจ้างต้องปรับปรุงการจัดเก็บข้อมูลจากอุปกรณ์ตรวจวัด (Sensor) ให้เป็นระบบอย่างมี
มาตรฐาน
5.2.8.1 ออกแบบโครงสร้างการจัดเก็บข้อมูลทั้งรูปแบบไฟล์ (file base) และระบบจัดการ
ฐานข้อมูลเชิงพื้นที่ (Geospatial Database) พร้อมจัดทําเอกสารการออกแบบ 5.2.8.2 ทําการตรวจสอบและทําความสะอาดข้อมูลของระบบเดิม (Data Cleansing) 5.2.8.3 ออกแบบและปรับปรุงกระบวนการบริหารจัดการข้อมูลจากอุปกรณ์ตรวจวัด (Sensor) ในรูปแบบไฟล์ (file base) โดยออกแบบแบ่งประเภทข้อมูลดังนี้ 5.2.8.3.1 ข้อมูลสําหรับให้บริการบนเว็บแอปพลิเคชันหรือให้บริการในรูปแบบ
APIs (Hot Data)
5.2.8.3.2 ข้อมูลสําหรับจัดเก็บเพื่อเรียกดูย้อนหลังและพร้อมที่จะนํามาใช้งานต่อ
ได้เมื่อต้องการ (Archive Data)
5.2.8.3.3 ดําเนินการย้ายข้อมูลไปยังที่จัดเก็บตามที่ได้ออกแบบ ตามข้อ
5.2.8.3.1 และ 5.2.8.3.2
5.2.8.4 ออกแบบและปรับปรุงกระบวนการบริหารจัดการข้อมูลจากอุปกรณ์ตรวจวัด
(Sensor) ในรูปแบบระบบจัดการฐานข้อมูลเชิงพื้นที่ (Geospatial Database) 5.2.8.4.1 ออกแบบโครงสร้างฐานข้อมูลเชิงแนวคิด (E-R Model) ให้รองรับ การจัดเก็บข้อมูลปริมาณมากและรองรับการดึงข้อมูล (Query) เพื่อ แสดงผลเชิงสถิติและเชิงพื้นที่ได้อย่างรวดเร็ว พร้อมจัดทําเอกสารการ
ออกแบบ
5.2.8.4.2 ดําเนินการย้ายข้อมูลไปยังระบบจัดการฐานข้อมูลเชิงพื้นที่ตามที่ได้
ตามข้อ
ออกแบบ ตามขอ 5.2.8.4.1
ประธาน
22
กรรมการ
बॉल
กรรมการ
Rom
กรรมการ