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

ฟังดูง่ายใช่ไหมครับ แต่ในฐานะคนทำฝั่ง Backend คำถามที่ผมว่าสำคัญที่สุดของระบบนี้ไม่ใช่จะใช้ภาษาอะไร หรือจะแบ่ง service ยังไง เป็นคำถามที่ฟังดูง่ายกว่านั้นเยอะ คือ “จะรู้ได้ยังไงว่าลดไปเท่าไร” เพราะไฟที่ไม่ได้ใช้ วัดตรง ๆ ไม่ได้

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

LAMS คืออะไร

ทำไมต้องขอให้คนลดการใช้ไฟ

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

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

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

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

แรกเริ่มเดิมที ไอเดียนี้ไม่ได้เกิดในไทยครับ หลังวิกฤตไฟฟ้าในแคลิฟอร์เนียช่วงปี 2000–2001 ทีมวิจัยที่ Lawrence Berkeley National Laboratory เริ่มพัฒนา OpenADR ตั้งแต่ปี 2002 เพื่อให้ฝั่งการไฟฟ้าส่งสัญญาณ DR ไปถึงอาคารได้โดยอัตโนมัติ แทนการโทรหรือส่งอีเมลบอกทีละราย จนเดือนมกราคม 2019 OpenADR ก็ได้รับการรับรองเป็นมาตรฐานสากลจาก IEC

ศัพท์ 7 คำที่ต้องรู้ก่อนไปต่อ

ผมรวมไว้ตรงนี้ที่เดียว อ่านไปแล้วงงคำไหน เลื่อนกลับมาดูได้ครับ

คำ	ความหมาย
DR (Demand Response)	การเปลี่ยนการใช้ไฟของผู้ใช้ไปจากรูปแบบปกติ เพื่อตอบสนองต่อราคาไฟฟ้าที่เปลี่ยนตามต้นทุนการผลิต หรือเงินสนับสนุนพิเศษที่กำหนดไว้
DRR (DR Resource)	ผู้เข้าร่วมการตอบสนองด้านโหลด คือผู้ใช้ไฟทั่วไป ทั้งที่อยู่อาศัย อาคาร และโรงงาน ที่สนใจเข้าร่วมโครงการ
LA (Load Aggregator · ผู้รวบรวมโหลด)	รวบรวมความสามารถในการลดโหลดจากผู้ใช้ไฟให้ได้ครบปริมาณตามคำสั่งจาก DRCC เป็นตัวกลางที่ทำให้ภาคการไฟฟ้าและผู้ใช้ไฟมีส่วนร่วมกัน
DRCC (Demand Response Control Center · ศูนย์สั่งการการดำเนินการตอบสนองด้านโหลด)	รับคำสั่งด้าน DR จากผู้ผลิตไฟฟ้าโดยตรง แล้วนำมาบริหารจัดการและสั่งการต่อไปยัง LA
CBL (Customer Baseline Load)	ค่าการใช้ไฟ “ที่ควรจะเป็น” ถ้าไม่มีการลด คำนวณจากการใช้ไฟช่วงเวลาเดียวกันในวันย้อนหลัง ทีละช่วง 15 นาที (96 ช่วงต่อวัน) โดยเว้นวันเสาร์–อาทิตย์ วันหยุด และวันที่เคยมี event ระบบมีสูตรให้เลือกหลายแบบ และเลือกสูตรที่คลาดเคลื่อนน้อยที่สุดสำหรับมิเตอร์แต่ละตัว ใช้เป็นฐานเทียบว่าลดได้จริงเท่าไร
Settlement	การคำนวณและจ่ายค่าตอบแทนจากการลดโหลด
OpenADR (Open Automated Demand Response)	โปรโตคอลมาตรฐานสำหรับสื่อสารข้อมูล DR

ใครสั่งใคร

เมื่อต้องการลดการใช้งานไฟฟ้า ลำพังผู้ใช้ไฟฟ้าเพียงรายเดียวอาจลดไฟได้ไม่มากพอ และศูนย์สั่งการเองก็คงไม่สามารถติดต่อบ้านทีละหลังได้ จึงต้องมีตัวกลางที่เรียกว่า LA (Load Aggregator) หรือ "ผู้รวบรวมโหลด" เข้ามาทำหน้าที่รวบรวมผู้ใช้ไฟหลายๆ รายเข้าด้วยกันเป็นกลุ่มใหญ่ เพื่อให้ตอบสนองคำสั่งลดไฟฟ้าได้อย่างมีประสิทธิภาพ โดยในโครงการนี้ ฝั่งผู้แจกจ่ายไฟฟ้าจะรับบทเป็น LA และมีระบบที่เรียกว่า LAMS (Load Aggregator Management System) เป็นเครื่องมือหลักในการบริหารจัดการทั้งหมด

คำสั่งจึงไหลลงมาเป็นทอด ๆ จากผู้ผลิตไฟฟ้า จาก DRCC ไปยัง LA จนถึง DRR ซึ่งก็คือผู้ใช้ไฟที่เข้าร่วม ส่วนผลการลดโหลดก็ไหลย้อนกลับขึ้นไปทางเดิม การซื้อขายจึงแบ่งเป็นสองระดับ ระหว่าง DRCC กับ LA เรียกว่าระดับค้าส่ง (Wholesale DR) และระหว่าง LA กับ DRR เรียกว่าระดับค้าปลีก (Retail DR)

DR Event หนึ่งรอบ หน้าตาเป็นยังไง

ลองไล่ดูทีละช่วงด้วยตัวเลขสมมติครับ (ไม่ใช่ข้อมูลจริง)

ทุกอย่างเริ่มจากผู้ผลิตไฟฟ้าสั่งการ DR ไปที่ DRCC ซึ่งรับคำสั่ง บริหารจัดการ แล้วส่งต่อมายัง LAMS ผ่าน OpenADR ประมาณว่า “พรุ่งนี้ 14:00–16:00 ขอลดรวม 10 MW” จากนั้น LAMS แจ้ง DRR ทาง in-app และอีเมล ผู้ใช้แต่ละรายเลือกได้ว่าจะ opt-in (เข้าร่วม) หรือ opt-out (ไม่เข้าร่วมรอบนี้) แล้ว LAMS ตอบกลับ DRCC ว่ามีใครเข้าร่วมบ้าง

พอถึงเวลา DRR ก็ลดโหลด มิเตอร์ส่งค่าทุก 15 นาที และ LAMS ส่งรายงานค่าจริงพร้อม CBL กลับไปที่ DRCC เมื่อจบ event ระบบเทียบผลที่ลดได้จริงกับที่ตกลงไว้ในสัญญา แล้วพอสิ้นเดือนก็ทำ Settlement ออกเป็นเอกสารที่ลงนามดิจิทัล

ตัวเลขที่เป็นหัวใจของทั้งรอบคือ reduction ครับ ลองดูช่วง 15 นาทีแรก ถ้า CBL บอกว่าปกติผู้ใช้รายนี้ใช้ไฟ 500 kW แต่วันนี้มิเตอร์วัดได้ 380 kW ก็แปลว่าลดได้ 120 kW ทำแบบนี้ซ้ำทั้ง 8 ช่วงของ event แล้วรวมกัน

DR Event คือ คำสั่งลดโหลดในช่วงเวลาหนึ่ง
Reduction คือ CBL ลบด้วยค่าที่วัดได้จริงจากมิเตอร์

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

ส่วนที่ยากที่สุด: การเชื่อมต่อกับระบบภายนอก

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

ภาพรวม: สองจุดที่ธุรกิจหลักไหลผ่าน

ทีม BML แยก LAMS ออกเป็นหลาย service ทั้งส่วนธุรกิจหลัก ส่วนข้อมูลมิเตอร์ ส่วนรับส่ง OpenADR และหน้าเว็บ แต่ถ้าดูเฉพาะเส้นทางที่เงินไหลผ่าน จะเหลือจุดเชื่อมต่อแค่สองจุด

จุดที่ 1 DRCC รับคำสั่ง DR เข้ามา และส่งรายงานกลับ ผ่านมาตรฐาน OpenADR
จุดที่ 2 ข้อมูลมิเตอร์ วัตถุดิบของ CBL, reduction และค่าตอบแทน

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

ตัวอย่างที่ 1: LAMS ↔ DRCC

ปัญหา A: ข้อความต้องไม่หาย และต้องไม่ซ้ำ

ข้อความระหว่าง LAMS กับ DRCC ไม่ใช่ข้อความธรรมดา ถ้า event หาย DRR ก็ไม่รู้ว่าต้องลดโหลด ถ้า event ซ้ำ ผู้ใช้ก็โดนแจ้งเตือนสองรอบ (และคงสงสัยว่าต้องลดสองเท่าหรือเปล่า)

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

ครึ่งแรก ฝั่งส่งรับประกันแค่ว่า “อย่างน้อยหนึ่งครั้ง” (at-least-once) ด้วยรูปแบบที่เรียกว่า outbox หรือ กล่องขาออก คือบันทึกงานกับข้อความที่ต้องส่งลงฐานข้อมูลใน transaction เดียวกัน แล้วให้ตัว relay ทยอยหยิบข้อความจาก outbox ไปส่ง ถ้าส่งไม่ผ่านก็ retry ตามรอบ ถ้าเกินจำนวนครั้งที่กำหนดก็ย้ายไปไว้ที่ DLQ (Dead Letter Queue) หรือ คิวพักข้อความที่ส่งไม่สำเร็จ ให้คนเข้ามาตรวจ ข้อความจึงไม่หายไปเงียบ ๆ

ครึ่งหลัง ฝั่งรับต้อง “รับซ้ำได้โดยไม่เสียหาย” (idempotent) ด้วย inbox หรือ สมุดจดว่าข้อความไหนเคยทำไปแล้ว ข้อความที่มาซ้ำจะถูกตอบรับตามปกติแต่ไม่ถูกทำซ้ำ สำหรับ event จาก OpenADR สิ่งที่ใช้แยกว่าซ้ำหรือไม่คือรหัส event คู่กับเลขรอบการแก้ไข event เดิมที่ถูกแก้ไขจึงไม่นับเป็นของซ้ำ

นึกภาพตอนกดโอนเงินในแอปธนาคารแล้วเน็ตค้างครับ เราไม่รู้ว่ารายการผ่านไปแล้วหรือยัง เลยกดใหม่ ที่เงินไม่ถูกตัดสองรอบก็เพราะระบบจ่ายเงินจำเลขรายการไว้ เห็นเลขเดิมก็ตอบว่า “รายการนี้สำเร็จแล้ว” โดยไม่ตัดเงินซ้ำ ฝั่งส่งของเราคือคนที่กดซ้ำได้อย่างสบายใจ ส่วน inbox คือระบบที่จำเลขรายการไว้นั่นเอง

ปัญหา B: ปลายทางไม่ได้ตรงมาตรฐานเป๊ะ

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

วิธีแก้ของเราคือแยกพฤติกรรมของปลายทางไว้เป็น profile ต่างหากจากมาตรฐาน โค้ดหลักยังพูดภาษามาตรฐาน ส่วนที่เบี่ยงอยู่ใน profile ของคู่ค้ารายนั้นที่เดียว ทุกจุดที่เบี่ยงต้องจดไว้ว่าเบี่ยงจากข้อไหนของมาตรฐาน เพราะอะไร อยู่ตรงไหนในโค้ด และเมื่อไรควรกลับมาทบทวน แล้วมีเทสต์ล็อกพฤติกรรมนั้นไว้ ไม่ให้ใครเผลอ refactor รวมสองพฤติกรรมเข้าด้วยกันโดยไม่รู้ตัว

ผลพลอยได้คือ เวลามีคนถามว่า “ทำไมตรงนี้ไม่ตรงสเปก” เราตอบได้ด้วยลิงก์เดียว ไม่ต้องไปขุดแชตเก่ากันครับ

ตัวอย่างที่ 2: ข้อมูลมิเตอร์ → CBL → ค่าตอบแทน

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

แล้วก็มาถึงจุดที่ผมว่าสำคัญที่สุดของบทความนี้ครับ ลองนึกว่าช่วง 15 นาทีหนึ่งข้อมูลหายไป ถ้าระบบเข้าใจว่าช่วงนั้น “ใช้ไฟศูนย์” สูตรจะคำนวณว่า CBL 500 ลบ 0 เท่ากับลดได้ 500 kW กลายเป็นผลงานดีที่สุดของเดือน จากมิเตอร์ที่แค่ส่งข้อมูลไม่ถึง และระบบก็พร้อมจะจ่ายเงินให้ไฟที่ไม่ได้ลดจริง

ข้อมูลหายจึงไม่เท่ากับศูนย์ ระบบต้องแยกให้ออกตั้งแต่ชั้นเก็บข้อมูลว่าช่วงไหน “ไม่มีข้อมูล” และช่วงไหน “วัดได้ศูนย์จริง” ไม่งั้น reduction และเงินจะเพี้ยนทั้งหมด สิ่งที่เราทำมีสี่อย่าง

รับข้อมูล 3 ทาง คือ สตรีมแบบเรียลไทม์ ดึงจาก API เป็นชุด และ backfill จากไฟล์ย้อนหลัง ทางไหนพลาด อีกทางยังเติมให้ได้
ฝั่งดึงจาก API ใส่ retry และ circuit breaker หรือ ตัวตัดวงจร ที่จะหยุดยิงคำขอชั่วคราวเมื่อปลายทางล่มติดกันหลายครั้ง
ใช้ allowlist หรือ รายชื่อมิเตอร์ที่อนุญาต กรองเฉพาะมิเตอร์ของโครงการ และถ้า allowlist ชุดใหม่เล็กลงผิดปกติ ระบบจะปฏิเสธชุดนั้นแทนที่จะเชื่อทันที เพราะรายชื่อที่หายไปครึ่งหนึ่งในคืนเดียว มีโอกาสเป็นบั๊กมากกว่าลูกค้าลาออกพร้อมกัน
มีหน้าตรวจ coverage ที่ระบุชัดว่าช่วงไหนข้อมูลหาย ทีมจึงเห็นและตามข้อมูลมาเติมได้

บทเรียนที่ได้

ถ้าต้องสรุปงานนี้ให้เหลือสามบรรทัด ผมขอเป็นแบบนี้ครับ

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

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

ส่วนบิลค่าไฟที่บ้านผม เดือนนี้ก็ยังไม่ได้ลดเลยครับ ไว้ค่อยสมัครเป็น DRR ดูบ้าง

แหล่งอ้างอิง

OpenADR & Communications · Berkeley Lab
Lab Research Streamlines Modern Grid (OpenADR ได้รับการรับรองจาก IEC) · Berkeley Lab
Demand Response Research Center – Final Report · Berkeley Lab
รูปแบบการดำเนินการ Demand Response ในบริบทของประเทศไทย · Thai Smart Grid
ทิศทางการพัฒนาธุรกิจผู้รวบรวมโหลด (Load Aggregator) ของไทย · Thai Smart Grid
ศูนย์พยากรณ์การผลิตไฟฟ้าจากพลังงานหมุนเวียน และศูนย์ควบคุมการตอบสนองด้านโหลด · กฟผ.

เบื้องหลัง LAMS ระบบที่เปลี่ยน “การลดใช้ไฟ” ให้เป็นรายได้