AI for Demand & Supply Optimization — คืออะไร ทำงานอย่างไร

วันนี้แผนสูบจ่ายน้ำของ EWG มาจากประสบการณ์ของคน (สไลด์ 10) M6 เปลี่ยนให้เป็นโจทย์คณิตศาสตร์: "ต้องส่งน้ำให้ลูกค้าทุกรายพอ แรงดันอยู่ในเกณฑ์ ถังไม่ล้นไม่แห้ง — แล้วจะเปิดปั๊มตัวไหน เมื่อไร ดึงน้ำจากแหล่งไหน ให้ต้นทุนรวมต่ำที่สุด" คอมพิวเตอร์ลองแผนได้เป็นพัน ๆ แผนในเวลาที่คนลองได้ไม่กี่แผน แล้ว EPANET ตรวจว่าแผนที่ดีที่สุดไม่ทำให้ท่อแรงดันตก งานวิจัยรายงานว่าการจัดตารางปั๊มแบบนี้ลดค่าไฟได้ราว 10–20% (เฉลี่ย ~15% สูงสุด ~25% ในกรณีศึกษา) แต่ตัวเลขจริงขึ้นกับว่ามีถังพักให้เลื่อนเวลาสูบได้มากแค่ไหน

อ่านจากซ้ายไปขวาของสไลด์ 11: Data Source + Demand Forecast + Cost per unit → AI → Optimization

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

• •แยก 3 ระดับตามสไลด์: รายลูกค้า (นิคมฯ / ประปาท้องถิ่น) · รายพื้นที่ / แนวท่อ · โครงการใหม่ที่กำลังจะเปิด
• •วิธีที่ใช้กันมากที่สุดในงานวิจัยคือ Time-series (ARIMA ฯลฯ) ราว 25% และ Neural Network ราว 20% ของบทความที่ทบทวน — Machine Learning (Random Forest, Gradient Boosting) ทำได้ดีเมื่อมีตัวแปรประกอบ เช่น วันหยุด อุณหภูมิ ฝน
• •โครงการของ TZW (เยอรมนี) รายงานว่า ML พยากรณ์ทั้งค่าเฉลี่ยและค่า Peak ได้คลาดเคลื่อนราว 5% ใน 13 พื้นที่ ขณะที่วิธีสถิติง่าย ๆ จับ Peak ไม่ได้
• •ลูกค้าอุตสาหกรรมของ EWG ใช้น้ำค่อนข้างสม่ำเสมอ → พยากรณ์ได้แม่นกว่าบ้านเรือน แต่ต้องรู้ล่วงหน้าเมื่อโรงงานหยุดซ่อมหรือขยายกำลังผลิต (ข้อมูลจากฝ่ายขาย ไม่ใช่จากเซนเซอร์)
• •ผลลัพธ์ที่ควรได้ไม่ใช่ตัวเลขเดียว แต่เป็นช่วง (เช่น 80% มั่นใจว่าอยู่ระหว่าง X–Y) เพื่อให้ Optimizer เผื่อความเสี่ยงได้

Optimizer ต้องรู้ว่า "น้ำ 1 ลบ.ม. จากแหล่ง A ส่งผ่านเส้นทาง B ไปถึงลูกค้า C ตอนเวลา T ต้นทุนเท่าไร" ไม่อย่างนั้นจะเปรียบเทียบทางเลือกไม่ได้

• •ต้นทุนผันแปรที่ใหญ่ที่สุดคือค่าไฟสูบน้ำ — งานวิจัยระบุว่าค่าไฟการสูบอาจสูงถึง 70% ของต้นทุนดำเนินงานระบบจ่ายน้ำ → นี่คือเหตุผลที่ M3 (PME วัด kWh จริงรายสถานี) ต้องมาก่อน M6
• •ถ้าค่าไฟเป็น TOU ต้นทุนของน้ำลิตรเดียวกันจะต่างกันตามชั่วโมง → สูบตอน Off-Peak เก็บในถัง แล้วปล่อยตอน Peak
• •Cost Allocation ตามสไลด์: ต้นทุนคงที่ + ผันแปร แยกรายพื้นที่และรายลูกค้า → ใช้ได้ทั้งวางแผนสูบและตั้งราคา / ส่วนลด (เชื่อมกับ M5 Data Warehouse)
• •ควรรวมต้นทุนน้ำดิบแต่ละแหล่ง (น้ำฝาก / สูบผันน้ำ) และน้ำสูญเสียในเส้นท่อ เพราะเส้นทางที่ค่าไฟถูกอาจรั่วมากกว่า

เขียนการตัดสินใจทั้งวันเป็นสมการ: ตัวแปรตัดสินใจ (ปั๊มไหนเปิด/ปิด ความเร็วรอบ VSD เปิดวาล์วไหน ดึงจากแหล่งไหน ทุกช่วงเวลา) · เป้าหมาย (ต้นทุนรวมต่ำสุด) · ข้อจำกัด (ปริมาณพอทุกจุด แรงดันอยู่ในเกณฑ์ ระดับถังอยู่ระหว่างต่ำสุด-สูงสุด ปั๊มไม่เปิดปิดถี่เกิน สิทธิ์น้ำของแต่ละแหล่ง)

• •MILP (Mixed-Integer Linear Programming): แปลงชลศาสตร์ให้เป็นเส้นตรงเป็นช่วง ๆ แล้วให้ Solver หาคำตอบที่พิสูจน์ได้ว่าดีที่สุด (หรือห่างจากดีที่สุดไม่เกิน x%) — แม่น อธิบายได้ แต่ต้องประมาณสมการท่อ
• •Genetic Algorithm / Metaheuristic: สุ่มแผนจำนวนมาก ให้ EPANET ประเมิน แล้วผสมแผนที่ดีไปเรื่อย ๆ — ใช้กับโมเดลเต็มได้ตรง ๆ แต่ช้าและไม่รับประกันว่าดีที่สุด
• •Hybrid (LP + GA) และ Bayesian Optimization: ใช้ตัวแทนที่เร็วกว่าเพื่อลดจำนวนครั้งที่ต้องรัน EPANET
• •ผลที่รายงาน: งานทบทวนที่ถูกอ้างบ่อยให้ช่วงลดค่าไฟ 10–20% · กรณีศึกษา GA ได้เฉลี่ย ~15% สูงสุด ~25% เทียบกับการเดินเครื่องจริง — แต่ลดลงมากเมื่อฝ่ายปฏิบัติการเลือกเก็บน้ำในถังเผื่อไว้มาก
• •กับดักที่งานวิจัยเตือน: บางวิธีให้แผนที่ทำไม่ได้จริง (ถังล้น ปั๊มเปิดปิดถี่) → ต้องมีขั้นตรวจความเป็นไปได้ก่อนส่งให้คนเสมอ ซึ่งคือหน้าที่ของ Track B

EPANET คือโปรแกรมจำลองชลศาสตร์ของ US EPA (ฟรี โอเพนซอร์ส) คำนวณแรงดันและอัตราไหลทุกจุดในโครงข่ายจากผังท่อ ปั๊ม ถัง และความต้องการใช้น้ำ AQUIS (M4) เป็น Digital Twin เชิงพาณิชย์ที่จะเสร็จปีที่ 2 — M6 จึงใช้ EPANET ไปก่อนเพื่อไม่ต้องรอ

• •WNTR (Water Network Tool for Resilience) คือ Python package ของ US EPA + Sandia ที่อ่านไฟล์ EPANET ได้ จำลองชลศาสตร์และคุณภาพน้ำ สร้างเหตุการณ์ (ท่อแตก ไฟดับ) และวัดความยืดหยุ่น — ทำให้ต่อ EPANET เข้ากับ AI pipeline ใน Python ได้ตรง ๆ
• •ปัญหาคือ EPANET รันครั้งละไม่นาน แต่ Optimizer ต้องรันเป็นหมื่นครั้ง → จึงสร้าง "EPANET Surrogate Model" (ตามแผนในสไลด์ 10) = Neural Network ที่เรียนจากผล EPANET จำนวนมาก แล้วตอบแทน EPANET ได้ในเสี้ยววินาที
• •งานปี 2025 (Cambridge Prisms Water) รายงานว่าการผสม deterministic + surrogate + neural network เร่งการวิเคราะห์แบบ real-time ได้ราว 10⁵ เท่า สำหรับการจัดตารางปั๊มภายใต้ค่าไฟที่เปลี่ยนตามเวลา
• •Graph Neural Network เป็นแนวใหม่ที่ไม่ต้องเทรนใหม่ทุกครั้งที่โครงข่ายเปลี่ยน — เหมาะกับ EWG ที่ขยายท่อต่อเนื่อง
• •หลักที่ต้องรักษา: Surrogate ใช้ "ค้นหา" แผน แต่แผนสุดท้ายต้องผ่าน EPANET ตัวจริงเสมอก่อนถึงมือคน

โปรแกรมจำลองระบบท่อจ่ายน้ำของ US EPA ใช้กันทั่วโลกเป็นมาตรฐานกลางของวงการ — ให้ผังท่อ ปั๊ม วาล์ว ถัง และความต้องการใช้น้ำ แล้วคำนวณแรงดันและอัตราไหลทุกจุดในทุกช่วงเวลา (Extended Period Simulation)

• •ราคา: ฟรี เป็น Public Domain คัดลอกและแจกจ่ายได้ — ไม่มีค่า License
• •ชลศาสตร์: Pressure-dependent demand, ควบคุมปั๊มด้วยเวลาหรือ Rule-based, สูตร Headloss หลายแบบ, ปั๊มความเร็วคงที่และปรับรอบ (VSD), วาล์วหลายชนิด, ถังทุกรูปทรง และคำนวณพลังงาน + ค่าไฟการสูบในตัว
• •คุณภาพน้ำ: อายุน้ำ (Water age), ติดตามแหล่งที่มาของน้ำ (Source tracing), สารที่ทำปฏิกิริยา เช่น คลอรีน, การผสมในถัง
• •โปรแกรม GUI สำหรับ Windows รุ่นทางการล่าสุดของ EPA คือ 2.2 (ก.ค. 2020)
• •Engine / Toolkit รุ่นโอเพนซอร์ส (Open Water Analytics บน GitHub) ไปถึง 2.3.x แล้ว — เพิ่มวาล์วควบคุมตามเปอร์เซ็นต์เปิด (Positional Control Valve), แบบจำลองน้ำรั่วตามแรงดัน (FAVAD), รายงาน Flow Balance, เปิด/ปิด Control ได้, และ C# API
• •Toolkit (DLL มากกว่า 50 ฟังก์ชัน) ให้โปรแกรมอื่นเรียก EPANET ได้ → WNTR (Python) ใช้ทางนี้ จึงต่อเข้า AI pipeline ของ M6 ได้ตรง ๆ
• •ส่วนเสริม: EPANET-MSX (หลายสารทำปฏิกิริยาพร้อมกัน), EPANET-RTX (Calibrate ด้วยข้อมูลปฏิบัติการจริง), QGISRed (สร้างและวิเคราะห์โมเดลบน QGIS)
• •ข้อจำกัด: เป็น "เครื่องคิดเลข" แบบ Offline — ไม่ดึงข้อมูล SCADA เอง ไม่มีหน้าจอสำหรับผู้ปฏิบัติการ ไม่มี Optimizer ในตัว ต้องเขียนโค้ดต่อเอง (ซึ่งคืองานของ Track B)

ซอฟต์แวร์จัดการโครงข่ายน้ำเชิงพาณิชย์ เดิมของบริษัท 7-Technologies (เดนมาร์ก — ผู้ทำ IGSS SCADA และ TERMIS ด้วย) ซึ่ง Schneider Electric ซื้อกิจการไป ปัจจุบันอยู่ในชุด Water Network Optimization ของ Schneider Electric / AVEVA จุดต่างจาก EPANET คือเป็น "Online model" ที่รันต่อเนื่องด้วยข้อมูล SCADA จริง

• •Planning: ทำ What-if ก่อนตัดสินใจ เช่น จำลองการปิดวาล์ว แล้วเตือนถ้าจะเกินเกณฑ์ — คาดการณ์พฤติกรรมโครงข่ายล่วงหน้าหลายชั่วโมงถึงหลายวัน
• •Online / Live model: ใช้ข้อมูล Real-time จาก SCADA + พยากรณ์อากาศ ประเมิน Demand แล้วแสดงสถานะ อดีต ปัจจุบัน และอนาคตของโครงข่าย
• •Virtual sensors: ประเมินแรงดัน อัตราไหล และคุณภาพน้ำ ณ จุดที่ไม่มีเซนเซอร์จริง ("ไปถึงที่ที่ SCADA ไปไม่ถึง")
• •Leak detection (ท่อส่ง): หาตำแหน่งรั่วจากค่าไหลและแรงดันที่ต้นทาง/ปลายทาง แล้วส่ง Alarm เข้า SCADA
• •Pressure management: แนะนำค่าแรงดันที่เหมาะสม — แรงดันต่ำลงช่วยลดน้ำรั่วและท่อแตก
• •Energy & pump optimization: กำหนดว่าปั๊มตัวไหนควรเดินเมื่อไร โดยชั่งประสิทธิภาพปั๊ม ค่าไฟ และการใช้น้ำ + Reservoir optimization — ส่ง Set point กลับเข้า SCADA เป็นรอบรายชั่วโมงหรือราย 15 นาที
• •Water quality: เฝ้าระวังและเตือนล่วงหน้าเมื่อคุณภาพน้ำผิดปกติ
• •การเชื่อมต่อ: ทำงานกับ SCADA ของ Schneider และของรายอื่น ชุด WNO มีเครื่องมือเชื่อม AQUIS กับ Wonderware System Platform (= AVEVA System Platform) → ตรงกับแพลตฟอร์มที่ M1 กำลังยกระดับ
• •ตัวเลขที่ผู้ขายอ้าง (ยังไม่ได้พิสูจน์ในงานอิสระ): ลดน้ำสูญเสียได้ถึง 15%, ลดค่าไฟสูบน้ำได้ถึง 20%, ลด CO2 ได้ถึง 20%, ความแม่นยำโมเดลราว 1%

ข้อมูล AQUIS มาจากหน้าของผู้ขายและตัวแทนจำหน่าย หลายหน้าเป็นข้อมูลเก่าหลายปี — ชื่อแบรนด์ (Schneider / AVEVA) และรายการโมดูลรุ่นปัจจุบันต้องยืนยันกับผู้ขายก่อนเขียน TOR

ข้อสังเกตสำคัญ: AQUIS มีโมดูล Energy & pump optimization ของตัวเองอยู่แล้ว — ถ้า EWG ซื้อ AQUIS ครบโมดูลในปีที่ 2 ส่วน "จัดตารางปั๊ม" ของ M6 จะซ้ำกัน สิ่งที่ M6 มีแต่ AQUIS ไม่ได้ทำคือฝั่งธุรกิจ: พยากรณ์ความต้องการรายลูกค้า + โครงการใหม่, ต้นทุนต่อหน่วยรายพื้นที่/รายลูกค้า, การเลือกแหล่งน้ำดิบตามสิทธิ์น้ำและน้ำฝาก

ข้อเสนอ: วางขอบเขต M6 ให้เป็น "ชั้นธุรกิจ" (Demand + Cost + แหล่งน้ำ + Explanation) ที่ส่งเป้าหมายให้ตัวจัดตารางปั๊ม — ปีแรกใช้ Optimizer ของ M6 + EPANET ปีที่ 2 ตัดสินว่าจะใช้ Pump optimization ของ AQUIS แทน หรือคงของ M6 ไว้ โดยเทียบผลจริงจากช่วงนำร่อง

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

• •ทุกแผนที่แนะนำต้องบอก: ประหยัดเท่าไรเทียบกับแผนเมื่อวาน · ข้อจำกัดตัวไหนตึงที่สุด (เช่น "ถัง X เหลือ 32% ตอน 18:00") · ใช้ค่าพยากรณ์อะไร มั่นใจแค่ไหน
• •Dashboard แยกตามบทบาท: ผู้บริหาร = บาท/ลบ.ม., kWh/ลบ.ม., ความเสี่ยงรวม · ผู้ปฏิบัติการ = ตารางเปิดปิดปั๊มรายชั่วโมง ระดับถัง แรงดันจุดวิกฤต
• •เสนอ 2–3 ทางเลือก (ถูกที่สุด / สมดุล / ปลอดภัยที่สุด) แทนคำตอบเดียว ให้คนเลือก — ตรงกับ "จัดลำดับทางเลือก" ในสไลด์
• •บันทึกว่าแผนไหนถูกเลือก ทำจริงแล้วผลเป็นอย่างไร → ใช้วัดผลและสอนโมเดลรอบถัดไป

M6 อยู่ปลายสาย — ทุกโมดูลก่อนหน้าคือข้อมูลที่ M6 กิน

• •Garbage in, garbage out: สไลด์ M4 บอกเองว่าข้อมูล GIS / ท่อ / ปั๊มไม่ตรงหน้างาน — EPANET ที่ไม่ได้ Calibrate จะรับรองแผนที่ผิด
• •ตัวเลขประหยัด 10–25% มาจากงานวิจัยในต่างประเทศ ไม่ใช่ของ EWG ควรวัด Baseline (kWh/ลบ.ม. ปัจจุบัน จาก M3) ก่อน แล้ววัดผลจริงในพื้นที่นำร่อง
• •เริ่มแบบ Advisory: ระบบแนะนำ คนตัดสินใจ อย่างน้อยจนกว่าจะเทียบผลได้หลายเดือน ไม่ให้ AI สั่ง SCADA ตรง
• •ความรู้ต้องอยู่กับทีม EWG: สไลด์ระบุให้ทีมเดียวกับ AQUIS ทำ M6 — ดีเพราะลดการพึ่งที่ปรึกษา (ปัญหาเดียวกับที่ M4 ระบุ)
• •สิทธิ์น้ำและเงื่อนไขสัญญากับลูกค้า (ปริมาณขั้นต่ำ น้ำฝาก) เป็นข้อจำกัดทางธุรกิจที่ต้องใส่ในโมเดล ไม่ใช่แค่ข้อจำกัดทางวิศวกรรม

1. 1.ข้อมูลที่ M6 ต้องใช้มีอยู่แล้วแค่ไหน: ประวัติการใช้น้ำรายลูกค้า (Billing), ค่าแรงดัน/อัตราไหล (SCADA, M2), kWh ต่อสถานี (PME, M3) — ย้อนหลังกี่ปี ละเอียดรายชั่วโมงหรือรายวัน
2. 2.EWG มีไฟล์ EPANET (.inp) ของโครงข่ายอยู่แล้วหรือไม่ และ Calibrate ล่าสุดเมื่อไร — Track B เริ่มได้เร็วแค่ไหนขึ้นกับข้อนี้
3. 3.อัตราค่าไฟของสถานีสูบเป็น TOU (On-Peak / Off-Peak) หรือไม่ — ถ้าใช่ การเลื่อนเวลาสูบคือแหล่งประหยัดที่ใหญ่ที่สุด
4. 4.ถังพัก / Head Tank มีความจุเผื่อเท่าไร และฝ่ายปฏิบัติการยอมให้ระดับถังต่ำสุดเท่าไร — ตัวเลขนี้กำหนดว่าประหยัดได้มากหรือน้อย
5. 5.ใครเป็นคนกดอนุมัติแผนรายวัน — M6 ควรเริ่มแบบ "แนะนำ" (advisory) ก่อนจะสั่งเครื่องเอง
6. 6.ตัวชี้วัดความสำเร็จที่ตกลงกัน: บาท/ลบ.ม., kWh/ลบ.ม., จำนวนครั้งแรงดันต่ำกว่าเกณฑ์, น้ำสูญเสีย
7. 7.AQUIS ที่จะซื้อใน M4 รวมโมดูล Energy & pump optimization ด้วยหรือไม่ — ถ้ารวม ขอบเขตจัดตารางปั๊มของ M6 ต้องตัดสินใหม่ไม่ให้จ่ายซ้ำ
8. 8.AQUIS รุ่นปัจจุบัน Import/Export ไฟล์ EPANET (.inp) ได้หรือไม่ — กำหนดว่าโมเดลที่ M6 สร้างในปีแรกใช้ต่อใน M4 ได้หรือต้องทำใหม่

• Luna et al. (2019) — Improving energy efficiency in water supply systems with pump scheduling optimization (GA: เฉลี่ย ~15%, สูงสุด ~25%)· accessed 14 ต.ค. 2026
• Water Resources Management (2016) — MILP pump scheduling; อ้าง Boulos et al. 2001: ลดค่าไฟ 10–20%· accessed 14 ต.ค. 2026
• Optimal Scheduling of Variable Speed Pumps using MILP (arXiv 2309.04715) — ค่าไฟการสูบถึง 70% ของต้นทุนดำเนินงาน· accessed 14 ต.ค. 2026
• Water (2023) — ตรวจแผนจัดตารางปั๊มที่ทำไม่ได้จริง· accessed 14 ต.ค. 2026
• Cambridge Prisms: Water (2025) — Modelling flow and pressure controlled pump stations with application to optimal pump scheduling (surrogate ~10⁵ เท่า)· accessed 14 ต.ค. 2026
• Candelieri et al. (2018) — Bayesian optimization of pump operations in water distribution systems· accessed 14 ต.ค. 2026
• Kerimov et al. (EGU 2022) — Graph neural network surrogates trained on EPANET· accessed 14 ต.ค. 2026
• US EPA — WNTR (Water Network Tool for Resilience) บน GitHub· accessed 14 ต.ค. 2026
• WNTR documentation· accessed 14 ต.ค. 2026
• A Critical Review of Short-Term Water Demand Forecasting Tools — What Method Should I Use? (Cambridge)· accessed 14 ต.ค. 2026
• TZW — Short-term water demand forecasting (ML คลาดเคลื่อน ~5% ใน 13 พื้นที่)· accessed 14 ต.ค. 2026
• Smart Water Re-implementation v2 — สไลด์ 10–11 (Module 6)· accessed 14 ต.ค. 2026
• US EPA — EPANET (ความสามารถ, รุ่น 2.2, Public Domain, Toolkit)· accessed 14 ต.ค. 2026
• Open Water Analytics — EPANET releases (2.3.x)· accessed 14 ต.ค. 2026
• QGISRed — สร้างและวิเคราะห์โมเดล EPANET บน QGIS· accessed 14 ต.ค. 2026
• Syscom Automation — Aquis Water Network Management (โมดูลและตัวเลขที่ผู้ขายอ้าง)· accessed 14 ต.ค. 2026
• Water Online — Aquis Water Network Management· accessed 14 ต.ค. 2026
• Water Online — Water Network Optimization Suite (Schneider Electric / AVEVA)· accessed 14 ต.ค. 2026
• Schneider Electric — 7-Technologies is now Schneider Electric· accessed 14 ต.ค. 2026
• Schneider Electric blog (2021) — hydraulic modeling software for water networks, EcoStruxure for Water· accessed 14 ต.ค. 2026