ผมจัดทำตัวอย่างการทำ Concept Paper ให้สำหรับ นศ. วิศวกรรมคอมพิวเตอร์ และ วิศวกรรมซอฟต์แวร์ เพื่อเอาไว้ใช้ในการศึกษาแนวทางการจัดทำให้เป็นในทิศทางเดียวกัน โดยคุณสามารถศึกษาจากตัวอย่างที่ผมให้ไว้ด้านล่างนี้ได้เลย
หากคุณต้องการจะส่งรายงานความคืบหน้าในแต่ละส่วนของหัวข้อโครงงาน สามารถเข้ามาส่งได้ที่นี่
- ระบบบริหารจัดการพลังงานอาคารด้วย AI และ IoT
- 1. บทคัดย่อ
- 2. ความเป็นมาของปัญหา
- 3. วัตถุประสงค์
- 4. ผลกระทบ
- 5. การพัฒนาเทคโนโลยี
- 6. รายงานการศึกษาหรืองานวิจัยที่เกี่ยวข้อง
- 7. ทฤษฏี สมมติฐาน หรือกรอบแนวคิดของโครงงาน
- 8. ขอบเขตของโครงงาน
- 9. แผนการดำเนินงาน
- 10. ประโยชน์ที่คาดว่าจะได้รับ
- 11. ความร่วมมือกับหน่วยงานอื่น
- 12. งบประมาณ
- 13. การวัดและประเมินผล
ระบบบริหารจัดการพลังงานอาคารด้วย AI และ IoT
Smart Energy Insight
เสริม
หัวข้อต้องชัดเจน ดูแล้วรู้ว่าจะทำอะไร
1. บทคัดย่อ
อาคารเป็นภาคส่วนที่ใช้พลังงานสูงที่สุดแห่งหนึ่งของโลก โดย International Energy Agency (IEA) รายงานว่าอาคารทั่วโลกใช้พลังงานคิดเป็นสัดส่วนถึง 18% ของการใช้พลังงานทั้งหมด และก่อให้เกิดก๊าซเรือนกระจกถึง 26% ของการปล่อยก๊าซทั่วโลก ในประเทศไทย ข้อมูลจากกรมพัฒนาพลังงานทดแทนและอนุรักษ์พลังงาน (พพ.) ระบุว่า ภาคอาคารพาณิชย์และที่อยู่อาศัยรวมกันใช้พลังงานคิดเป็น 21% ของการใช้พลังงานขั้นสุดท้ายของประเทศ ปัญหาสำคัญคือ อาคารส่วนใหญ่ยังขาดระบบตรวจวัดและควบคุมพลังงานแบบชาญฉลาด ทำให้เกิดการสูญเสียพลังงานจากพฤติกรรมการใช้งานที่ไม่เหมาะสม เช่น การเปิดเครื่องปรับอากาศหรือไฟฟ้าในพื้นที่ที่ไม่มีผู้ใช้งาน ซึ่งอาจสูงถึง 20-30% ของพลังงานที่ใช้ทั้งหมด
โครงงานนี้นำเสนอการพัฒนา “Smart Energy Insight” ระบบต้นแบบบริหารจัดการพลังงานอาคารที่ผสานเทคโนโลยี Internet of Things (IoT) และปัญญาประดิษฐ์ (Artificial Intelligence: AI) เพื่อเก็บรวบรวม วิเคราะห์ และควบคุมการใช้พลังงานไฟฟ้าของอาคารแบบเรียลไทม์ ระบบประกอบด้วย IoT Sensor Node สำหรับตรวจวัดค่าพลังงาน อุณหภูมิ และความชื้นในแต่ละโซนของอาคาร, Edge Server สำหรับประมวลผลข้อมูลเบื้องต้นและรันโมเดล AI, และ Web Dashboard แบบโต้ตอบสำหรับแสดงผลข้อมูลและควบคุมอุปกรณ์ไฟฟ้า โมเดล AI ที่พัฒนาขึ้นใช้เทคนิค Gradient Boosting และ Long Short-Term Memory (LSTM) สำหรับพยากรณ์แนวโน้มการใช้พลังงานล่วงหน้าและเสนอแนะแนวทางการลดโหลด เช่น การเลื่อนเวลาใช้งานอุปกรณ์ (Load Shifting) และการปิดอุปกรณ์อัตโนมัติเมื่อไม่มีผู้ใช้งาน
จากการทบทวนงานวิจัยที่เกี่ยวข้อง พบว่าการนำ AI มาใช้ในการบริหารจัดการพลังงานอาคารสามารถลดการใช้พลังงานได้ตั้งแต่ 8% ถึง 50% ขึ้นอยู่กับประเภทอาคารและเทคโนโลยีที่ใช้ โดยเฉพาะการวิจัยของ Lawrence Berkeley National Laboratory ในปี 2024 ระบุว่า AI สามารถช่วยลดการใช้พลังงานและการปล่อยคาร์บอนของอาคารได้อย่างน้อย 8-19% นอกจากนี้ งานวิจัยจากมหาวิทยาลัย Zaragoza ประเทศสเปน พบว่าการใช้ IoT ตรวจวัดระดับ CO₂ และควบคุมระบบ HVAC ตามการใช้งานจริงสามารถประหยัดพลังงานได้ถึง 40-70%
โครงงานนี้มีวัตถุประสงค์หลัก 5 ประการ ได้แก่ (1) พัฒนาระบบ IoT สำหรับเก็บข้อมูลพลังงานแบบเรียลไทม์ (2) พัฒนาโมเดล AI สำหรับพยากรณ์และแนะนำการลดพลังงาน (3) ออกแบบ Dashboard แสดงผลและควบคุมอุปกรณ์ (4) สร้างระบบต้นแบบและทดสอบในอาคารจำลอง และ (5) ประเมินประสิทธิภาพเชิงเทคนิคและเศรษฐกิจ ขอบเขตของโครงงานครอบคลุมการติดตั้งในพื้นที่ทดลอง 2-3 โซนภายในอาคารเรียน โดยใช้ IoT Node 3-5 จุด เก็บข้อมูลเป็นระยะเวลา 4-6 สัปดาห์ และพัฒนาระบบให้สามารถขยายขอบเขตได้ในอนาคต
ผลที่คาดว่าจะได้รับจากโครงงานนี้ ได้แก่ การลดค่าไฟฟ้าในพื้นที่ทดสอบอย่างน้อย 20%, การลดการปล่อย CO₂ สอดคล้องกับแนวทาง Net Zero Campus, และการสร้างต้นแบบที่สามารถต่อยอดเป็นบริการ Energy-as-a-Service สำหรับอาคารอื่น ๆ ในอนาคต โครงงานนี้จึงมีคุณค่าทั้งในเชิงวิศวกรรม เศรษฐกิจ สังคม และสิ่งแวดล้อม ตอบโจทย์ความต้องการของยุคสมัยที่ต้องการประหยัดพลังงานและลดผลกระทบต่อสิ่งแวดล้อมอย่างยั่งยืน
คำสำคัญ: ระบบบริหารจัดการพลังงานอาคาร, ปัญญาประดิษฐ์, อินเทอร์เน็ตของสรรพสิ่ง, การพยากรณ์พลังงาน, อาคารอัจฉริยะ, Edge Computing
เสริม
บทคัดย่อ = บทสรุป
ต้องอ่านแล้วรู้ทันทีโดยที่ไม่ต้องอ่านเล่มก็ได้ จะรู้ทันทีว่า “ปัญหาหลัก” ที่เจอคืออะไร และ “โครงงานนี้” จะแก้ปัญหาที่ว่าได้อย่างไรแบบชัดเจน และคาดหวังผลลัพธ์จากโครงงานได้ว่าอย่างไร (จะแก้ปัญหาได้ดีกี่ % ต้องระบุเป็นตัวเลขได้เลย)
2. ความเป็นมาของปัญหา
2.1 บริบทการใช้พลังงานในภาคอาคาร
ภาคอาคารเป็นหนึ่งในผู้บริโภคพลังงานสูงสุดของโลก โดยองค์การสหประชาชาติ (UN) ระบุว่า อาคารรับผิดชอบต่อ 33% ของการใช้พลังงานขั้นสุดท้ายโลกทั้งหมด และเกิดการปล่อยก๊าซ CO₂ ประมาณ 26% ของการปล่อยทั้งโลก ในประเทศไทย สถานการณ์ไม่แตกต่างจากเทรนด์โลก โดยข้อมูลจากกรมพัฒนาพลังงานทดแทนและอนุรักษ์พลังงาน (พพ.) และธนาคารกรุงศรี ระบุว่า ภาคอาคารพาณิชย์ สำนักงาน และสถาบันการศึกษารวมกันใช้พลังงานคิดเป็น 21% ของการใช้พลังงานขั้นสุดท้ายของประเทศ ซึ่งคิดเป็นมูลค่าประมาณ 150,000-200,000 ล้านบาทต่อปี
ในกรณีของมหาวิทยาลัย ปัญหาพลังงานมีความเฉพาะเจาะจงมากขึ้น โดยข้อมูลจากการศึกษาหลายแหล่งพบว่า
- การใช้พลังงานในอาคารเรียนและห้องปฏิบัติการสูง – งานวิจัยจากมหาวิทยาลัยแมนเชสเตอร์ พบว่า ระบบระบายอากาศและให้ความเย็น (HVAC) ใช้พลังงานถึง 40-60% ของพลังงานทั้งหมดในอาคาร ตามด้วยระบบไฟฟ้าและอุปกรณ์ที่ใช้ประมาณ 28%
- ปัญหาการสูญเสียพลังงานระหว่างเวลาปิดอาคาร – งานวิจัยของ Kim et al. (2013) ค้นพบว่า 26-65% ของพลังงานสูญเสียไปขณะที่อาคารไม่มีผู้ใช้งาน (นอกเวลาราชการ) เนื่องจากระบบ HVAC, ไฟฟ้า และอุปกรณ์คอมพิวเตอร์ยังคงทำงาน
2.2 ปัญหาแนวทางการบริหารจัดการพลังงาแบบดั้งเดิม
ปัญหาสำคัญของระบบบริหารจัดการพลังงาทั่วไปในสถาบันการศึกษาและอาคารพาณิชย์นั้น มีลักษณะดังนี้
2.2.1 ขาดระบบตรวจวัดและติดตามแบบ Real-Time
ระบบปัจจุบันมักอาศัยการอ่านค่าพลังงานจากแผงควบคุมเดือนละครั้ง หรือผ่านตัวนับพลังงาน (Energy Meter) ที่ติดตั้งแบบจุดเดียวต่ออาคารทั้งหมด ไม่สามารถทำให้เห็นรายละเอียดการใช้พลังงานแยกเป็นโซนหรือห้องต่าง ๆ ได้ ส่งผลให้ผู้บริหารอาคารไม่สามารถระบุว่าพลังงานสูญเสียไปที่ใดและสาเหตุคืออะไร
วิจัยจากประเทศไทยของสำนักงาน National Science and Technology Development Agency (NSTDA) พบว่า โรงงานขนาดย่อมในไทยส่วนใหญ่ (SMEs) ยังคงใช้วิธีการบันทึกข้อมูลแบบกระดาษ เก็บเพียงข้อมูลโดยรวม ซึ่งไม่สามารถช่วยให้พบปัญหาในการดำเนินงานและโอกาสประหยัดพลังงาน
2.2.2 ไม่สามารถใช้ข้อมูลตรวจวัดสำหรับการวิเคราะห์และคาดการณ์
แม้บางอาคารจะมีระบบตรวจวัดพลังงาน แต่ข้อมูลที่เก็บรวบรวมมักถูกจัดเก็บในรูปแบบดั้งเดิม ไม่สามารถนำไปวิเคราะห์ อย่างขั้นสูงหรือคาดการณ์แนวโน้มการใช้พลังงานได้ ส่งผลให้ไม่สามารถจัดทำแผนการลดพลังงานที่มีประสิทธิภาพ
2.2.3 ขาดการควบคุมอุปกรณ์แบบอัตโนมัติตามพฤติกรรมการใช้งาน
ระบบบริหารจัดการพลังงาทั่วไปส่วนใหญ่เป็นระบบ Manual หรือระบบควบคุมอัตโนมัติที่ใช้เพียงการตั้งเวลา (Time-based Control) เท่านั้น ไม่สามารถตอบสนองต่อการเปลี่ยนแปลงของจำนวนผู้ใช้งาน อุณหภูมิ หรือความชื้นในห้องได้ โดยอัตโนมัติ
งานวิจัยจากมหาวิทยาลัยต่าง ๆ พบว่า การใช้ AI ในการควบคุม HVAC ตามจำนวนผู้ใช้งานจริง (Occupancy-based Control) สามารถลดการใช้พลังงานเพิ่มเติมได้ 15-40% เมื่อเปรียบเทียบกับการควบคุมแบบเวลาตายตัว
2.3 ความท้าทายทางเทคนิคในการนำระบบ IoT-AI มาใช้
2.3.1 ปัญหา Latency (ความล่าช้า) ในการส่งข้อมูล
ระบบ Building Management System แบบดั้งเดิมที่ส่งข้อมูลขึ้นไปยัง Cloud เท่านั้น มีปัญหาคือ ความล่าช้าในการส่งและประมวลผลข้อมูล (Latency) ซึ่งอาจสูงถึง 5-10 วินาที ทำให้ระบบไม่สามารถตอบสนองต่อสถานการณ์ฉุกเฉินได้อย่างรวดเร็ว เช่น การควบคุม HVAC เมื่ออุณหภูมิเพิ่มขึ้นอย่างรวดเร็ว
Edge Computing ซึ่งประมวลผลข้อมูลที่เซนเซอร์หรือ Gateway ในพื้นที่ สามารถลด Latency ลงมาเหลือน้อยกว่า 2 วินาที ซึ่งเพียงพอสำหรับการควบคุมระบบอาคารในเวลาจริง
2.3.2 ปัญหาความปลอดภัยและการจัดการข้อมูลส่วนตัว
การส่งข้อมูลพลังงานขึ้นไปยัง Cloud ทำให้มีความเสี่ยงด้านความปลอดภัยและการรั่วไหลของข้อมูลส่วนตัวของผู้ใช้งาน การใช้ Edge Processing ช่วยให้สามารถเก็บข้อมูลที่ละเอียดไว้ในพื้นที่ และส่งเพียงข้อมูลสรุปขึ้นไปยัง Cloud เท่านั้น ซึ่งลดความเสี่ยงในการรั่วไหลของข้อมูล
2.3.3 ปัญหาต้นทุนการติดตั้งและดำเนินการสูง
ระบบ Energy Management System แบบพาณิชย์ (เช่น Siemens Desigo CC, Schneider EcoStruxure) มีต้นทุนการติดตั้งสูง (100,000-500,000 บาทขึ้นไป) และมักจำเป็นต้องว่าจ้างบริษัทเหล่านี้ให้ดำเนินการบำรุงรักษา ซึ่งเพิ่มต้นทุนรายปี
ในประเทศไทย อุปสรรคหลักต่อการนำ Smart Grid และ Building Management System มาใช้งานได้แก่ ขาดบุคลากรด้านเทคนิค ขาดการอบรมเพิ่มพูน และการขาดนโยบายการสนับสนุนจากภาครัฐ
2.4 ข้อจำกัดของงานวิจัยที่เกี่ยวข้อง
แม้ว่ามีงานวิจัยมากมายเกี่ยวกับการใช้ AI และ IoT ในการบริหารจัดการพลังงาน แต่มีข้อจำกัดหลายประการ
- งานวิจัยส่วนใหญ่เป็น Simulation หรือ Proof of Concept เท่านั้น – ยังไม่มีต้นแบบที่สามารถนำไปใช้งานจริงในสภาพแวดล้อมอาคารไทยได้อย่างเต็มที่
- ขาดการศึกษาเกี่ยวกับการรวมเอา Occupancy-based Control, Thermal Comfort, และ Real-time Analytics เข้าในระบบเดียว – งานวิจัยส่วนใหญ่เน้นเพียงด้านใดด้านหนึ่ง
- ขาดการศึกษาเกี่ยวกับการใช้ Edge Computing ร่วมกับ AI ในสภาพแวดล้อมอาคารจริง – โดยเฉพาะในบริบทของมหาวิทยาลัยหรือสถาบันการศึกษา
2.5 ความจำเป็นและโอกาสสำหรับการพัฒนา Smart Energy Insight
จากข้อมูลข้างต้น มีความจำเป็นต่อการพัฒนาระบบบริหารจัดการพลังงานอาคารที่มีลักษณะ ดังนี้
- สามารถเก็บข้อมูลพลังงานแบบ Real-Time จากหลายจุดในอาคาร เพื่อให้เห็นรายละเอียดการใช้พลังงานแยกเป็นโซนหรือห้องต่าง ๆ
- สามารถวิเคราะห์ข้อมูลและพยากรณ์แนวโน้มการใช้พลังงานล่วงหน้า โดยใช้เทคโนโลยี Machine Learning
- สามารถเสนอแนะและควบคุมอุปกรณ์ไฟฟ้าโดยอัตโนมัติ ตามเงื่อนไขการใช้พื้นที่จริง (Occupancy-based Control) เพื่อหลีกเลี่ยงการสูญเสียพลังงาน
- มีต้นทุนติดตั้งและดำเนินการต่ำ เพื่อให้สามารถนำไปใช้งานในอาคารต่าง ๆ ได้อย่างกว้างขวาง
- ใช้เทคโนโลยี Edge Computing เพื่อลด Latency, เพิ่มความปลอดภัยข้อมูล และสร้างให้ระบบสามารถทำงานได้ต่อเนื่องแม้ปราศจากการเชื่อมต่อ Cloud
โครงงาน Smart Energy Insight จึงถือกำเนิดขึ้น เพื่อเติมเต็มช่องว่างนี้ โดยเป็นเป็นระบบต้นแบบที่ผสานวิศวกรรมคอมพิวเตอร์ (เชิงระบบหมวด Edge Computing), ปัญญาประดิษฐ์ (AI/ML), IoT, และการออกแบบซอฟต์แวร์เพื่อให้ได้ระบบที่ทำงานจริง ทำงานได้บนแพลตฟอร์มเปิด (Open-source) และสามารถต่อยอดได้อย่างยั่งยืน
การระบุปัญหา
ต้องระบุปัญหาให้ชัดเจนว่ามีปัญหาอะไรเกิดขึ้น ปัญหาที่เกิดขึ้นกระทบกับใครบ้าง ปัญหาที่เกิดขึ้นหากคิดเป็นตัวเลขแล้ว ส่งผลเสียให้กับกิจการนั้นๆ มากน้อยเท่าไหร่ (ขอตัวเลขชัดเจน และทำเป็น % ให้เห็นชัดเจน)
พยายามแบ่งประเด็นปัญหาออกเป็นข้อใหญ่ แล้วเขียนคำอธิบายปัญหาแต่ละข้อออกมาให้เห็นปัญหาให้ชัดเจนที่สุด และชี้ให้เห็นถึงข้อจำกัดที่เกิดขึ้นจากการพยายามแก้ปัญหาของหลายๆ เจ้า เพื่อให้เห็นช่องว่างว่าโครงงานของเราก็พอที่จะเข้าไปแก้ปัญหาตรงช่องว่างนี้ได้
3. วัตถุประสงค์
1. พัฒนาระบบ IoT สำหรับเก็บและส่งข้อมูลพลังงานแบบเรียลไทม์
- ติดตั้ง IoT Sensor Node (อย่างน้อย 3-5 จุด) สำหรับตรวจวัดค่าพลังงาน (Voltage, Current, Power Factor), อุณหภูมิ และความชื้นในแต่ละโซนของอาคาร
- สร้าง Communication Protocol ระหว่าง Sensor Node และ Edge Server โดยใช้ MQTT หรือ LoRaWAN เพื่อให้ Response Time ไม่เกิน 2 วินาที
- บันทึกข้อมูลลงใน Time-Series Database เพื่อสนับสนุนการวิเคราะห์แนวโน้มในภายหลัง
2. พัฒนาโมเดล AI สำหรับพยากรณ์การใช้พลังงานและแนะนำการลดโหลด
- สร้างโมเดล Long Short-Term Memory (LSTM) เพื่อพยากรณ์การใช้พลังงานของอาคาร ล่วงหน้า 24 ชั่วโมง โดยมีความแม่นยำไม่ต่ำกว่า 90% (R² ≥ 0.90)
- ออกแบบ Recommendation Engine เพื่อแนะนำแนวทางการลดพลังงาน เช่น การเลื่อนเวลาใช้งาน (Load Shifting) หรือการปิดอุปกรณ์ที่ไม่จำเป็น
3. ออกแบบ Web Dashboard แบบเรียลไทม์สำหรับแสดงข้อมูลและควบคุมอุปกรณ์
- สร้าง Dashboard ที่แสดงข้อมูลพลังงานรายโซน การใช้พลังงานสะสม, ผลการพยากรณ์, แนะนำ AI และ Alert เมื่อการใช้พลังงานเกินค่าที่ตั้งไว้
- ให้ผู้ใช้งาน (เจ้าหน้าที่ดูแลอาคาร) สามารถควบคุมอุปกรณ์ไฟฟ้า (เปิด/ปิด) ผ่าน Dashboard หรือรับการควบคุมอัตโนมัติตาม AI Recommendation
4. ประเมินประสิทธิภาพและผลกระทบของระบบต้นแบบ
- วัดประสิทธิภาพทางเทคนิค ได้แก่ Accuracy ของการพยากรณ์, Response Time, Availability และ Data Security
- ประเมินผลประหยัดพลังงาน (% ลดลงในการใช้พลังงาน) เมื่อติดตั้งระบบ เป้าหมายอย่างน้อย 20%
- วิเคราะห์ Impact ด้านจำนวนการปล่อย CO₂ (kg CO₂/ปี) และการลดต้นทุนค่าไฟฟ้า (บาท/ปี)
5. ต่อยอดและสร้างแนวทางการใช้งาน
- สร้างต้นแบบโมเดลธุรกิจเบื้องต้น (Energy-as-a-Service) เพื่อการบริหารจัดการพลังงานแบบยั่งยืน
- จัดทำ Documentation ที่ครบถ้วน (System Architecture, Installation Guide, User Manual, Maintenance Guide)
- ออกแบบให้ระบบสามารถขยายขอบเขต (Scalability) และใช้งานกับอาคารอื่น ๆ ได้ในอนาคต
เสริม
ให้เขียนออกมาเป็นข้อๆ โดยใช้มุมมองของตัวโครงงาน
สิ่งที่ห้ามทำ
ห้ามใช้คำว่า “ศึกษา” เด็ดขาด ; หากคุณใช้คำว่าศึกษา แสดงว่าคุณกำลังมองในมุมมองของตัวคุณเอง แต่สิ่งที่ถูกต้องคือต้องมองในมุมมองของ “โครงงาน” เท่านั้น วัตถุประสงค์ก็ต้องเกิดจากตัวโครงงานเอง ให้ตอบคำถามได้ว่าโครงงานนี้จะถูกสร้างมาเพื่ออะไร
4. ผลกระทบ
4.1 ผลกระทบเชิงเศรษฐศาสตร์
การพัฒนา Smart Energy Insight นำเสนอมูลค่าทางเศรษฐศาสตร์ที่เป็นรูปธรรม โดยการลดพลังงานและค่าใช้จ่ายในอาคาร ข้อมูลจากการศึกษาโครงการประหยัดพลังงานในอาคารพาณิชย์ไทยระหว่าง 2012-2020 พบว่า การลดการใช้พลังงาน โดยเฉลี่ยคิดเป็น 18.13% โดยมีช่วงตั้งแต่ 6.11% ถึง 35% ขึ้นอยู่กับประเภทของอาคารและมาตรการที่ใช้ เมื่อนำมาประยุกต์ใช้กับมหาวิทยาลัยที่มีการใช้พลังงานประมาณ 3-5 ล้านบาทต่อปี การลดพลังงาน 20% จะทำให้ประหยัดค่าไฟฟ้าได้ประมาณ 600,000-1,000,000 บาทต่อปี สำหรับพื้นที่เดียว
อย่างไรก็ตาม ต้นทุนการติดตั้งระบบต้นแบบนี้ประมาณ 7,000-15,000 บาท (สำหรับ IoT Sensor และ Server) ซึ่งต่ำกว่าระบบบริหารจัดการพลังงานแบบพาณิชย์อย่างไม่น้อย 10 เท่า ดังนั้น ระยะเวลาในการคืนทุน (Payback Period) จะประมาณ 1-2 เดือน จากการลดพลังงาน ผ่านการลดการใช้พลังงาน นอกจากนี้ ยังมีผลประหยัดทางอ้อมอื่น ๆ เช่น การลดค่าบำรุงรักษาอุปกรณ์ (เนื่องจากลดการใช้งาน) และการเพิ่มมูลค่าของอาคาร เนื่องจากมีระบบบริหารจัดการพลังงานแบบสมัยใหม่ ซึ่งปัจจุบันนิยมใช้เป็นเกณฑ์ในการประเมินคุณภาพของอาคาร (Green Building Certification)
ในระยะยาว ระบบนี้สามารถสร้างรายได้เพิ่มเติมผ่านรูปแบบธุรกิจ Energy-as-a-Service ซึ่งเป็นแนวทางที่มหาวิทยาลัยอื่น ๆ ในต่างประเทศเริ่มนำมาใช้ โดยอาคารมอบหมายให้บริษัทกลางทำการบริหารจัดการพลังงาน บริษัทกลางจะได้ส่วนแบ่งจากการประหยัดพลังงาน ทำให้ทั้งสองฝ่ายได้ประโยชน์
4.2 ผลกระทบเชิงสังคมและสิ่งแวดล้อม
นอกเหนือจากประโยชน์ทางเศรษฐศาสตร์ โครงงาน Smart Energy Insight มีผลกระทบเชิงสังคมและสิ่งแวดล้อมที่สำคัญ โดยเฉพาะอย่างยิ่งในบริบทของการลดการปล่อยก๊าซเรือนกระจก ตามทำเนียบปกครองของประเทศไทย ได้กำหนดเป้าหมาย Thailand Nationally Determined Contribution (NDCs) ของประเทศไทยต่อสหประชาชาติเพื่อลดการปล่อยก๊าซเรือนกระจกคิดเป็น 20% ภายในปี 2573 เทียบกับปี 2563 มหาวิทยาลัยถือเป็นองค์กรที่นำในด้านการปฏิบัติด้านสิ่งแวดล้อมและควรเป็นต้นแบบให้ส่วนอื่น ๆ ของสังคม
การลดการใช้พลังงาน 20% ของพื้นที่ทดสอบหนึ่งแห่ง จะทำให้ลดการปล่อย CO₂ ประมาณ 40-60 ตันต่อปี (ขึ้นอยู่กับสถานี์องค์กรการผลิตไฟฟ้า) ซึ่งเทียบเท่ากับการปลูกต้นไม้ประมาณ 200-300 ต้นต่อปี หรือเทียบเท่ากับการขับรถเพื่อการท่องเที่ยวประมาณ 100,000 กิโลเมตร นอกจากนี้ ระบบนี้ยังสร้างความตระหนักรู้ (Awareness) ให้กับนักศึกษา บุคลากร และชุมชนมหาวิทยาลัยเกี่ยวกับปัญหาการใช้พลังงาน และความสำคัญของการอนุรักษ์พลังงาน
นอกจากนี้ โครงงานนี้สอดรับกับวิสัยทัศน์ของมหาวิทยาลัยในการเป็น “Green Campus” หรือ “Net Zero Campus” ซึ่งเป็นเป้าหมายที่มหาวิทยาลัยชั้นนำทั่วโลกกำลังพยายามบรรลุ โดยการลดการปล่อยก๊าซเรือนกระจกให้เหลือน้อยสุดหรือเป็นศูนย์ หากนำระบบนี้มาขยายใช้ในอาคารอื่น ๆ ของมหาวิทยาลัยจะช่วยให้มหาวิทยาลัยเข้าใกล้เป้าหมายนี้มากขึ้น ทำให้ประเทศสามารถบรรลุเป้าหมาย NDCs ได้อย่างมีประสิทธิภาพ
ด้านการศึกษา ระบบนี้จะเป็นเครื่องมือสอนที่ยอดเยี่ยมสำหรับหลากหลายรายวิชา เช่น Embedded Systems, IoT Applications, Machine Learning for Control System, Software Project Management, และ Sustainable Energy Management ทำให้นักศึกษาเข้าใจได้ว่า องค์ความรู้เชิงทฤษฎีสามารถประยุกต์ใช้แก้ปัญหาจริงของสังคมได้อย่างไร นอกจากนี้ ยังช่วยเพิ่มทักษะและศักยภาพของบัณฑิตให้พร้อมสำหรับอุตสาหกรรม 4.0 และ Industry 5.0 ที่มีการใช้ AI, IoT และ Edge Computing
เสริม
ให้มองในมุมมองว่า ถ้าโครงงานนี้ทำเสร็จสมบูรณ์ 100% เรียบร้อยแล้ว จะเกิดผลกระทบอะไรกับใครบ้าง
กระทบเชิงเศรษฐศาสตร์ คือ เชิงตัวเลขทางการเงิน เมื่อโครงงานนี้ทำออกมาเสร็จแล้วละทำให้กิจการนั้นๆ ประหยัดขึ้นมากน้อยแค่ไหน ร้อยละเท่าไหร่ หรือทำให้มีรายได้เพิ่มขึ้นมากน้อยแค่ไหน ร้อยละเท่าไหร่ ประหยัดเวลาขึ้นกว่าเดิมไหม ประหยัดเวลาไปเท่าไหร่ กี่วัน เดือน ปี ในระยะยาวใครจะได้ประโยชน์จากโครงงานนี้บ้าง
กระทบเชิงสังคมและสิ่งแวดล้อมคือ เมื่อโครงงานนี้ทำเสร็จแล้วจะกระทบกับใครบ้าง ทั้งบุคคลและองค์กร และคาดว่าจะกระทบยังไงบ้าง ดีขึ้นหรือแย่ลง คิดเป็นอัตราส่วนเท่าไหร่ แล้วในระยะยาวมันจะให้คุณหรือให้โทษกับใครบ้าง
5. การพัฒนาเทคโนโลยี
โครงการ Smart Energy Insight ใช้ประโยชน์จากการผสมผสานของเทคโนโลยีทั้งฮาร์ดแวร์และซอฟต์แวร์ยุคใหม่ เพื่อสร้างระบบที่ทำงานได้จริง มีต้นทุนต่ำ และสามารถต่อยอดได้อย่างยั่งยืน
ส่วนฮาร์ดแวร์:
ในด้านการเก็บข้อมูลพลังงาน ใช้ PZEM-004T v3.0 ซึ่งเป็นชิปการวัดพลังงานที่มีความแม่นยำสูง สามารถวัดค่าแรงดัน (Voltage) กระแส (Current) กำลังไฟฟ้า (Power) Power Factor และอุณหภูมิ ที่ความถูกต้อง ±1% สำหรับการส่งข้อมูล ใช้ ESP32 ซึ่งเป็นไมโครคอนโทรลเลอร์ที่มีความสามารถสูง มีตัวประมวลผล Dual-core 240MHz, หน่วยความจำ 520 KB, และมีระบบ Wi-Fi + Bluetooth ในตัว ทำให้เหมาะสำหรับการรับส่งข้อมูลแบบไร้สาย นอกจากนี้ยังใช้ Relay Module สำหรับควบคุมการเปิด/ปิดของอุปกรณ์ไฟฟ้า และ Current Transformer (CT) สำหรับการวัดกระแสแบบไม่รุกราน
| เกณฑ์การเปรียบเทียบ | ทางเลือกที่เลือกใช้ (PZEM-004T v3.0 และ ESP32) | ทางเลือกที่ 1: การใช้ MCU ระดับสูง (เช่น Raspberry Pi 5 และ Energy IC) | ทางเลือกที่ 2: การใช้ Industrial PLC/SCADA (เช่น Siemens LOGO!) |
|---|---|---|---|
| ความแม่นยำและการวัดพลังงาน | สูง (PZEM-004T) ให้ค่า V, I, P, Power Factor $\pm 1\%$ *เหมาะสมสำหรับงาน Data Analytics ระดับศึกษา* | สูงมาก (Energy IC เฉพาะทาง) ความแม่นยำ $\pm 0.1\%$ *เหมาะสำหรับงานวิจัย/เชิงพาณิชย์* | สูง ถูกออกแบบมาเพื่อความเสถียรในระดับอุตสาหกรรม (Industrial Grade) |
| การประมวลผล (AI Readiness) | ปานกลางถึงสูง (ESP32) เพียงพอสำหรับการทำ Edge Computing เบื้องต้น และส่งข้อมูล Real-time | สูงมาก (Raspberry Pi 5) สามารถรัน Deep Learning Models ที่ซับซ้อน หรือจัดการ Data Preprocessing ขนาดใหญ่ได้เต็มรูปแบบ | ต่ำ PLC เน้นการควบคุมแบบ Logic ข้อมูลต้องถูกส่งไปประมวลผลบน Cloud/Server เท่านั้น |
| ต้นทุน (Cost) | ต่ำ เป็นชุดอุปกรณ์ราคาประหยัดต่อจุดวัด ทำให้สามารถติดตั้งได้หลายจุดในงบประมาณจำกัด | ปานกลางถึงสูง ราคาสูงกว่า ESP32 หลายเท่า ทำให้ต้นทุนต่อจุดสูง | สูงมาก ระบบ PLC/SCADA มีราคาสูงทั้งฮาร์ดแวร์และซอฟต์แวร์ |
| ความยืดหยุ่นและการพัฒนา | สูงมาก เปิด Open Source พัฒนา Firmware ได้หลากหลายภาษา ผสานกับ Cloud Platform ได้ง่าย | สูงมาก ใช้ Linux พัฒนาด้วย Python เหมาะสำหรับงาน Prototype ที่เน้นความเร็วในการพัฒนา Software | ต่ำ พัฒนาโดยใช้ซอฟต์แวร์และภาษาเฉพาะของผู้ผลิต (Ladder Logic) *ยากต่อการปรับแต่งเพื่อ AI Algorithms* |
| ความเหมาะสมสำหรับโครงงาน CE | เหมาะสมที่สุด ครอบคลุมทั้งการพัฒนา Firmware (IoT) และการส่งข้อมูลสำหรับ AI Modeling (Data) ทำให้เรียนรู้ครบวงจร | เหมาะสม แต่จะเน้นไปที่งาน Software Development บน OS อาจลดความสำคัญของการพัฒนา Low-level Embedded System | ไม่เหมาะสม เน้นวิศวกรรมไฟฟ้า/ควบคุมจำกัดโอกาสในการพัฒนาด้าน Software Architecture และ AI |
ส่วนฐานข้อมูล:
ใช้ InfluxDB ซึ่งเป็น Time-Series Database ที่ออกแบบมาเฉพาะสำหรับเก็บข้อมูลอนุกรมเวลา (Time-Series Data) ฐานข้อมูลนี้มีความสามารถในการเก็บข้อมูลด้วยความเร็วสูง (Millions of data points per second) ประมวลผลแบบเรียลไทม์ (Real-time Query) และมีฟีเจอร์ Downsampling และ Retention Policies ที่ช่วยให้การจัดการข้อมูล Long-term ทำได้อย่างมีประสิทธิภาพ ฐานข้อมูลนี้เขียนด้วยภาษา Go ซึ่งทำให้เป็นแบบ Open-source และสามารถติดตั้งบน Edge Server ได้โดยง่าย
| เกณฑ์การเปรียบเทียบ | ทางเลือกที่เลือกใช้ (InfluxDB) | ทางเลือกที่ 1: NoSQL Database ทั่วไป (เช่น MongoDB หรือ Cassandra) | ทางเลือกที่ 2: SQL Database มาตรฐาน (เช่น PostgreSQL หรือ MySQL) |
|---|---|---|---|
| วัตถุประสงค์หลัก | ออกแบบมาเฉพาะสำหรับ Time-Series Data (ข้อมูลอนุกรมเวลา) โดยมี Timestamp เป็น Primary Key | ออกแบบมาสำหรับข้อมูลที่ไม่มีโครงสร้าง (Document หรือ Key-Value) | ออกแบบมาสำหรับข้อมูลที่มีความสัมพันธ์ (Relational) และต้องการความถูกต้องสูง (ACID) |
| ความเร็วในการเขียนข้อมูล | สูงมาก รองรับการเขียนข้อมูลปริมาณมหาศาล (Millions of data points/sec) จากอุปกรณ์ IoT ได้อย่างมีประสิทธิภาพ | สูง เหมาะสำหรับการเขียนที่เน้นปริมาณ แต่ประสิทธิภาพจะลดลงเมื่อจัดการ Timestamp และ Indexing ซับซ้อนขึ้น | ปานกลางถึงต่ำ การเขียนข้อมูลจำนวนมากอย่างต่อเนื่อง (เช่น ทุก 1 วินาที) จะเกิด Overhead และทำให้ Performance ลดลงอย่างมาก |
| ประสิทธิภาพการ Query ข้อมูล | สูง เหมาะสำหรับ Query แบบช่วงเวลา (Time Range) การรวมกลุ่มข้อมูล (Aggregation) และการทำ Downsampling (ย่อข้อมูล Long-term) | ปานกลาง ต้องมีการสร้าง Index พิเศษเพื่อรองรับ Time Range Query และการ Aggregation | ต่ำ Query แบบ Time Range บนตารางขนาดใหญ่จะช้า และการ Aggregate ข้อมูลจำนวนมากใช้ทรัพยากรสูง |
| ฟีเจอร์สำหรับ IoT และ Analytics | มีฟีเจอร์ในตัว เช่น Retention Policies และ Continuous Queries เพื่อจัดการข้อมูลเก่าโดยอัตโนมัติ และรองรับภาษา Query เฉพาะทาง (Flux) | ต้องพึ่งพาการตั้งค่าภายนอก หรือ Application Logic เพื่อจัดการข้อมูลเก่า และ Downsampling | ต้องใช้ Stored Procedures หรือ Application Logic ในการจัดการ Retention และการประมวลผลเชิงวิเคราะห์ขั้นสูง |
| ความเหมาะสมสำหรับโครงงาน CE | เหมาะสมที่สุด นักศึกษาได้เรียนรู้ Architecture เฉพาะทางด้าน Time-Series ซึ่งเป็นทักษะสำคัญในการทำ IoT Platform และเป็นพื้นฐานที่ดีสำหรับ AI Model Training | ปานกลาง เหมาะหากโครงงานเน้นไปที่ข้อมูลที่หลากหลาย (Multi-Structured) มากกว่า Time-Series ที่เข้มข้น | ไม่เหมาะสม ไม่ได้ถูกออกแบบมาเพื่อรองรับ Data Velocity และ Data Volume ที่สูงของ IoT Sensor Data |
ส่วน AI/Machine Learning:
โครงการใช้สองเทคนิก AI ที่สำคัญ ได้แก่ LSTM (Long Short-Term Memory) และ Gradient Boosting LSTM เป็นเครือข่ายประสาทเทียมแบบ Recurrent ที่ออกแบบมาโดยเฉพาะเพื่อการวิเคราะห์ข้อมูล Time-Series และสามารถรักษา Long-term dependencies ได้อย่างดี ซึ่งเหมาะสำหรับการพยากรณ์การใช้พลังงานที่ขึ้นอยู่กับปัจจัยหลายชั้น เช่น ประวัติการใช้พลังงาน อุณหภูมิ จำนวนผู้ใช้งาน ส่วน Gradient Boosting เป็นเทคนิค Ensemble ที่ใช้ Decision Trees หลายต้นเพื่อสร้างโมเดลที่แข็งแรง โดยแต่ละต้นไม้จะแก้ไขข้อผิดพลาดของต้นไม้ก่อนหน้า ทำให้ได้ประสิทธิภาพการพยากรณ์สูง และมี Computational Efficiency ที่ดีกว่า LSTM การผสมผสานทั้งสองเทคนิค สามารถให้ความแม่นยำ (Accuracy) ของการพยากรณ์ถึง 90-99% ขึ้นอยู่กับคุณภาพของข้อมูลและการเทรนโมเดล
| เกณฑ์การเปรียบเทียบ | ทางเลือกที่เลือกใช้ 1 (LSTM – Long Short-Term Memory) | ทางเลือกที่เลือกใช้ 2 (Gradient Boosting/XGBoost/LightGBM) | ทางเลือกเปรียบเทียบ (Linear Regression/Simple Feed-Forward NN) |
|---|---|---|---|
| ประเภทโมเดล/สถาปัตยกรรม | Recurrent Neural Network (RNN) ชนิดพิเศษ จัดอยู่ในกลุ่ม Deep Learning | Ensemble Method ใช้ Decision Trees หลายต้นมาทำงานร่วมกัน (Boosting) | **Linear Model** (ถดถอยเชิงเส้น) หรือ **Feed-Forward Neural Network (FFNN)** แบบตื้น |
| ความสามารถในการจับอนุกรมเวลา (Time-Series) | ยอดเยี่ยม มี Gate (Input, Forget, Output) ในการจัดการและจดจำ Long-term Dependencies ของข้อมูลตามลำดับเวลา |
ดี โดยธรรมชาติไม่ได้ออกแบบมาเพื่อ $Time$-$Series$ โดยตรง แต่สามารถปรับใช้ได้โดยการสร้าง Feature Engineering (เช่น Lagged Values, Moving Averages) | ต่ำ ไม่สามารถจับลำดับเวลาหรือความสัมพันธ์ระยะยาวในข้อมูลได้ดี จำเป็นต้องพึ่ง $Feature\ Engineering$ ที่ซับซ้อนมาก |
| ความแม่นยำและประสิทธิภาพ | สูงมาก เมื่อข้อมูลมีขนาดใหญ่และซับซ้อน สามารถให้ความแม่นยำสูง (Potential $95\%+$) ในการพยากรณ์ข้อมูลที่มีรูปแบบซับซ้อน | สูงมาก มักให้ประสิทธิภาพที่ยอดเยี่ยมและ **เร็วในการเทรน** เมื่อเทียบกับ $DL$ สามารถให้ความแม่นยำสูงในระดับ $90-98\%$ | ปานกลาง เหมาะสำหรับ Baseline หรือปัญหาที่ไม่ซับซ้อนมาก ประสิทธิภาพจะลดลงมากเมื่อความสัมพันธ์ไม่เป็นเชิงเส้น |
| ความสามารถในการอธิบายผล (Interpretability) | ต่ำ เป็นโมเดลแบบกล่องดำ ($Black\ Box$) ยากต่อการเข้าใจว่าปัจจัยใดมีผลต่อการพยากรณ์มากที่สุด | สูง สามารถใช้ Feature Importance Score ในการแสดงว่าปัจจัย ($Temp, Time\ of\ Day, etc.$) ใดมีผลต่อผลลัพธ์มากที่สุด | สูงมาก สามารถอธิบายได้ชัดเจนจากค่าสัมประสิทธิ์ (Coefficients) |
| ความเหมาะสมในการผสมผสาน | **Excellent Complement** เป็นพื้นฐาน $Deep\ Learning$ ที่ใช้สำหรับพยากรณ์โดยตรง (Sequence-to-Sequence) | **Excellent Complement** ใช้เป็นโมเดลทางเลือก (Alternative) หรือใช้ในการพยากรณ์เมื่อปัจจัยภายนอก ($Exogenous\ Variables$) มีความสำคัญสูง | **Base Model** ใช้เพื่อเปรียบเทียบและเป็นเกณฑ์ต่ำสุดของประสิทธิภาพโมเดลทั้งหมด |
ส่วน Application Layer:
ด้านส่วนต่อประสานผู้ใช้ ใช้ Node.js + React.js สำหรับสร้าง Web Dashboard ที่ Responsive และ Real-time Interactive Node.js ให้ประสิทธิภาพในการจัดการ Asynchronous Operations ของ HTTP Requests และ WebSocket Connections ส่วน React.js ให้ความสามารถในการสร้าง Dynamic UI Components ที่อัปเดตแบบ Real-time ใช้ Chart.js สำหรับแสดงกราฟข้อมูลพลังงานแบบเรียลไทม์ และใช้ Line Notify API เพื่อส่งการแจ้งเตือน (Notification) ให้กับเจ้าหน้าที่ดูแลอาคารเมื่อการใช้พลังงานเกินค่าที่ตั้งไว้
| เกณฑ์การเปรียบเทียบ | ทางเลือกที่เลือกใช้ (Node.js + React.js) | ทางเลือกที่ 1: Frameworks แบบ Monolithic (เช่น Django หรือ Laravel) | ทางเลือกที่ 2: Low-Code/No-Code Platform (เช่น Grafana หรือ ThingsBoard) |
|---|---|---|---|
| สถาปัตยกรรม (Architecture) | Microservices/Component-Based (ใช้ $React$ สำหรับ $Frontend$ และ $Node.js$ สำหรับ $Backend$) | Monolithic หรือ $Model$-$View$-$Controller\ (MVC)$ โครงสร้าง $Frontend$ และ $Backend$ รวมอยู่ใน $Framework$ เดียวกัน | Platform-Centric อาศัยการตั้งค่า ($Configuration$) บน $Platform$ นั้น ๆ และมีการ $Lock$-$in$ สูง |
| การจัดการ $Real$-$time\ Data$ | ยอดเยี่ยม $Node.js$ เหมาะกับการจัดการ $I/O$ และ $WebSocket$ ในการส่งข้อมูล $Real$-$time$ $React.js$ สร้าง $Dynamic\ UI$ ได้ดี | ปานกลาง ต้องใช้ไลบรารีเพิ่มเติม (เช่น $Django\ Channels$) เพื่อจัดการ $WebSocket$ และ $Real$-$time\ Update$ ซึ่งอาจเพิ่มความซับซ้อน | ยอดเยี่ยม ถูกสร้างมาเพื่อ $Real$-$time\ Monitoring$ โดยเฉพาะ โดยเชื่อมต่อโดยตรงกับ $Time$-$Series\ DB$ (เช่น $InfluxDB$) |
| ความยืดหยุ่นในการปรับแต่ง (Customization) | สูงมาก สามารถสร้าง $UI/UX$ ได้ตามต้องการ และผสานรวม $API$ ภายนอก ($Line\ Notify$) ได้อย่างอิสระ | สูง แต่ $Layout$ และ $Styling$ อาจถูกจำกัดด้วย $Templating\ Engine$ ของ $Framework$ นั้น ๆ | ต่ำ ถูกจำกัดด้วย $Widgets$ และ $Templates$ ที่ $Platform$ มีให้เท่านั้น ยากต่อการปรับ $UI$ ให้ตรงตามความต้องการเฉพาะของโครงงาน |
| ความเหมาะสมสำหรับโครงงาน $CE$ | เหมาะสมที่สุด นักศึกษาได้เรียนรู้ $Full$-$Stack\ Development$ ทั้ง $Backend$ (การจัดการ $API/WebSocket$) และ $Frontend$ (การสร้าง $SPA$) ซึ่งเป็นทักษะตลาดสูง | เหมาะสม หากเน้น $Backend\ Logic$ และ $Database\ Interaction$ โดยใช้ภาษาหลักของ $CE$ (เช่น $Python$ ใน $Django$) | ปานกลาง เหมาะสำหรับโครงงานที่เน้นการนำ $AI\ Model$ ไปใช้งานโดยเร็ว โดยไม่ต้องเน้นการพัฒนา $Software$ ตั้งแต่เริ่มต้น |
| การแจ้งเตือน (Notification) | สามารถผสานรวมกับ $Line\ Notify\ API$ หรือ $Telegram\ API$ ได้อย่างอิสระโดยตรงจาก $Node.js\ Backend$ | ต้องพัฒนา $Logic$ การส่ง $Notification$ ขึ้นเองภายใน $Framework$ ซึ่งมีความยืดหยุ่นสูง | มักมี $Notification\ Rules$ ในตัว แต่การเชื่อมต่อกับ $API$ ภายนอกที่ไม่ใช่ $Email/SMS$ อาจถูกจำกัด |
สถาปัตยกรรม Edge Computing:
จุดเด่นของระบบนี้คือการใช้ Edge Server (Raspberry Pi หรือ PC Mini Server) ที่ติดตั้ง MQTT Broker (เช่น Mosquitto) เพื่อทำการประมวลผลข้อมูลในพื้นที่ (Local Processing) ทำให้ลด Latency ลงมาเหลือต่ำกว่า 2 วินาที ซึ่งเพียงพอสำหรับการควบคุมอุปกรณ์ไฟฟ้าแบบเรียลไทม์ นอกจากนี้ยังเพิ่มความปลอดภัยของข้อมูล เนื่องจากข้อมูลที่ละเอียดถูกเก็บไว้ในพื้นที่ และส่งเพียงข้อมูลสรุปขึ้นไปยัง Cloud เท่านั้น
| เกณฑ์การเปรียบเทียบ | ทางเลือกที่เลือกใช้ (Edge Computing + MQTT Broker) | ทางเลือกที่ 1: Pure Cloud Computing (ส่งข้อมูลทั้งหมดไป Cloud โดยตรง) | ทางเลือกที่ 2: Pure Local Server (Local Network Server เท่านั้น) |
|---|---|---|---|
| Latency และการตอบสนอง | ต่ำมาก (ต่ำกว่า 2 วินาที) เหมาะสำหรับการควบคุมอุปกรณ์แบบ Real-time เนื่องจาก $Processing$ อยู่ใกล้แหล่งข้อมูล | สูง ขึ้นอยู่กับความเร็วอินเทอร์เน็ต (มักเกิน 5 วินาที) ไม่เหมาะสำหรับการควบคุม $Real$-$time$ | ต่ำมาก ($< 1$ วินาที) การประมวลผลและการควบคุมทำได้ทันทีในเครือข่ายท้องถิ่น |
| ความปลอดภัยของข้อมูล | สูง ข้อมูลดิบ ($Raw\ Data$) ถูกเก็บและประมวลผลใน $Edge\ Server$ ส่งเพียงข้อมูลสรุป ($Aggregated\ Data$) ไป $Cloud$ | ปานกลาง ข้อมูลดิบทั้งหมดถูกส่งออกไปยัง $Cloud\ Server$ ซึ่งอาจเพิ่มความเสี่ยงด้าน $Privacy$ และ $Security$ | สูงมาก ข้อมูลไม่ถูกส่งออกนอกเครือข่ายท้องถิ่นเลย มีความปลอดภัยทางกายภาพ ($Physical\ Security$) สูง |
| ความสามารถในการขยายระบบ (Scalability) | สูง สามารถเพิ่ม $Edge\ Server$ เพื่อรองรับอุปกรณ์ในแต่ละอาคารได้ (Decentralized Scalability) และใช้ $Cloud$ สำหรับ $Long$-$term\ Storage$ | สูงมาก $Cloud\ Service$ ถูกออกแบบมาเพื่อรองรับการขยายระบบอย่างไร้ขีดจำกัด | ต่ำ ถูกจำกัดด้วยความสามารถของ $Local\ Server$ และ $Network\ Infrastructure$ ภายในอาคารเท่านั้น |
| การพึ่งพาอินเทอร์เน็ต | ปานกลาง $Local\ Processing$ และ $Control$ ทำงานได้แม้ไม่มี $Internet$ แต่ $Dashboard$ และ $AI\ Model\ Training$ ต้องใช้ $Cloud$ | สูงมาก หากอินเทอร์เน็ตล่ม ระบบจะไม่สามารถเก็บข้อมูล ประมวลผล หรือควบคุมใดๆ ได้เลย | ต่ำมาก ระบบทำงานได้สมบูรณ์ภายในเครือข่ายท้องถิ่น ($LAN$) โดยไม่พึ่งพาอินเทอร์เน็ต |
| ความเหมาะสมสำหรับโครงงาน $CE$ | เหมาะสมที่สุด นักศึกษาได้เรียนรู้การออกแบบ $Distributed\ System$ (กระจายศูนย์) การใช้ $MQTT\ Protocol$ และการทำ $Microservice$ บน $Edge\ Device$ | เหมาะสม หากโครงงานเน้นไปที่การพัฒนา $Cloud\ Services$ และ $Large$-$scale\ Data\ Processing$ เป็นหลัก | ปานกลาง มักถูกใช้ในงาน $SCADA$ หรือ $OT\ (Operational\ Technology)$ และลดโอกาสในการเรียนรู้ $Cloud\ Integration$ |
การสื่อสารระหว่างอุปกรณ์:
ใช้ MQTT Protocol เป็นมาตรฐานการสื่อสาร ซึ่งเป็น Protocol ที่เบา (Lightweight) และออกแบบมาโดยเฉพาะสำหรับ IoT Applications โดยใช้ Publish-Subscribe Model ที่สามารถจัดการการเชื่อมต่อ และการถ่ายทำข้อมูลได้อย่างมีประสิทธิภาพ นอกจากนี้ยังรองรับการใช้ LoRa WAN สำหรับการสื่อสารระยะไกลในกรณีที่ Wi-Fi ไม่พร้อมใช้งาน
| เกณฑ์การเปรียบเทียบ | ทางเลือกที่เลือกใช้ 1 (MQTT Protocol) | ทางเลือกที่เลือกใช้ 2 (LoRaWAN Network) | ทางเลือกเปรียบเทียบ (HTTP/REST API) |
|---|---|---|---|
| รูปแบบการสื่อสาร | Publish-Subscribe Model: อุปกรณ์ส่งข้อมูลไปยัง $Broker$ ($Topic$) และอุปกรณ์อื่นรับจาก $Broker$ *ลด $Overhead$ และ $Bandwidth$* |
Star-of-Stars Topology: อุปกรณ์ส่งข้อมูลไปยัง $Gateway$ ระยะไกลด้วยคลื่นความถี่ต่ำ |
Request-Response Model: $Client$ (อุปกรณ์) ต้องร้องขอหรือส่งข้อมูลไปยัง $Server$ โดยตรง (Point-to-Point) |
| ความเร็ว/Latency | สูง/ต่ำ: เหมาะสำหรับการส่งข้อมูลขนาดเล็กแบบ $Real$-$time$ ภายในเครือข่าย $LAN/WAN$ | ต่ำ: ออกแบบมาเพื่อส่ง $Payload$ ขนาดเล็กในระยะทางไกล (กิโลเมตร) ไม่เหมาะกับ $Real$-$time\ Control$ ที่รวดเร็ว | ปานกลาง: การตั้ง $Polling\ Interval$ บ่อยครั้งทำให้เกิด $Overhead$ ของ $Header$ ข้อมูลสูง |
| การจัดการ $Resource$ | Lightweight: ใช้ $Header$ ข้อมูลขนาดเล็กมาก (< $2$ ไบต์) กินพลังงานและหน่วยความจำของ $MCU$ น้อย | Low-Power: กินพลังงานต่ำมาก ทำให้อุปกรณ์สามารถทำงานด้วยแบตเตอรี่ได้นานหลายปี | Heavyweight: $HTTP\ Header$ มีขนาดใหญ่และกินพลังงานสูง ไม่เหมาะกับอุปกรณ์ $Low$-$Power$ |
| ความครอบคลุม (Range) | จำกัดด้วยเครือข่าย $IP$ (Wi-Fi/Ethernet) หรือ $Cellular$ | ระยะไกลมาก: สามารถครอบคลุมพื้นที่กว้างหลายกิโลเมตรหรือข้ามอาคารได้โดยใช้ $Gateway$ น้อยตัว | จำกัดด้วยเครือข่าย $IP$ (Wi-Fi/Ethernet) หรือ $Cellular$ |
| ความเหมาะสมสำหรับโครงงาน $CE$ | เหมาะสมที่สุด: เป็น $Standard$ ใน $IoT\ Communication$ นักศึกษาได้เรียนรู้การจัดการ $Broker$ และ $Topic$ Structure | เสริมความแข็งแกร่ง: ใช้เป็นทางเลือกเพื่อแสดงความสามารถในการเชื่อมต่อ $Scenario$ ที่ $Wi$-$Fi$ เข้าไม่ถึง ซึ่งเพิ่มมิติของ $Network\ Engineering$ | ปานกลาง: ใช้เป็น $Alternative$ สำหรับการส่งคำสั่ง $Control$ แบบเฉพาะเจาะจงมากกว่าการส่ง $Time$-$Series\ Data$ จำนวนมาก |
ปัจจัยที่ทำให้เลือกใช้เทคโนโลยีเหล่านี้:
- ต้นทุนต่ำ – ส่วนประกอบทั้งหมดเป็น Open-source หรือมีราคาต่ำ (ไม่เกิน 15,000 บาท)
- ง่ายต่อการติดตั้งและบำรุงรักษา – ไม่ต้องใช้ความรู้ด้านวิศวกรรมขั้นสูง สามารถเรียนรู้และติดตั้งได้เอง
- Scalability – สามารถเพิ่มจำนวน Sensor Node หรือขยายขอบเขตได้โดยไม่จำเป็นต้องเปลี่ยนสถาปัตยกรรมหลัก
- Flexibility – สามารถนำ Component ไปใช้ในอาคารหรือสภาพแวดล้อมอื่น ๆ ได้อย่างง่ายดาย
- Real-time Performance – Edge Computing ช่วยให้ Latency ต่ำ เหมาะสำหรับการควบคุมอุปกรณ์ที่ต้องตอบสนองอย่างรวดเร็ว
เสริม
ควรบรรยายออกมาเป็นส่วนๆ เช่น ฮาร์ดแวร์, ฐานข้อมูล, ซอฟต์แวร์, เอไอ, สถาปัตยกรรม, การสื่อสารระหว่างอุปกรณ์
การบรรยายส่วนนี้ควรทำให้รู้ว่าเราตั้งใจจะใช้เทคโนโลยีอะไร จะใช้เครื่องมืออะไร เพราะมันมีข้อดีหรือข้อเสียอย่างไร ควรมีตารางเปรียบเทียบข้อมูลเทคโนโลยีแต่ละตัวยิ่งดี จะได้รู้ว่าเพราะอะไรคุณถึงเลือกใช้เทคโนโลยีนี้ ถ้ามีตารางเปรียบเทียบจะทำให้ผู้อ่านทราบเหตุผลว่าทำไมคุณถึงเลือกใช้เทคโนโลยีเหล่านี้
6. รายงานการศึกษาหรืองานวิจัยที่เกี่ยวข้อง
หัวข้อนี้สรุป “ภูมิทัศน์งานวิจัย” ที่เกี่ยวข้องกับ Smart Energy Insight ทั้งในมิติ AI, IoT, การพยากรณ์พลังงาน, ระบบควบคุมแบบ Real-time และระบบต้นแบบที่ใช้ ESP32 + PZEM-004T/LoRa เพื่อให้เห็นช่องว่างชัดเจนว่าโครงงานนี้จะไปต่อยอดตรงไหน
6.1 งานวิจัยด้าน AI และ Smart Building Energy Management
Bajwa และคณะ (2024) [1] นำเสนอ systematic literature review ฉบับใหญ่เกี่ยวกับ AI-enabled Smart Building Management Systems (SBMS) โดยสำรวจงานวิจัยคุณภาพสูง 472 ชิ้น พบว่า AI โดยเฉพาะ Deep Learning และ Reinforcement Learning มีบทบาทสำคัญในการเพิ่มประสิทธิภาพด้าน HVAC, ระบบไฟส่องสว่าง, การคาดการณ์พลังงาน และ Demand-side Management โดยสามารถลดการใช้พลังงานได้ช่วง 20–50% ในหลายกรณี และยังลดต้นทุนบำรุงรักษาจากการทำ Predictive Maintenance ลงได้ถึง 35% อย่างไรก็ตาม ผู้วิจัยชี้ว่าปัญหายังอยู่ที่การขาด pilot projects ระดับอาคารจริง และความท้าทายด้านการ scale ระบบและการบูรณาการกับโครงสร้างพื้นฐานดั้งเดิม
Emedo และคณะ (2025) [2] ทบทวนภาพรวม “AI-driven transformations in smart buildings” โดยสรุปว่า AI เปลี่ยนบทบาทอาคารจากระบบ passive มาเป็น cyber-physical systems ที่รับรู้สถานะตนเอง (self-aware) และสามารถตัดสินใจเชิงอัตโนมัติในเรื่องพลังงาน ความปลอดภัย และการใช้งานพื้นที่ อย่างไรก็ดี ยังพบข้อจำกัดด้านมาตรฐานข้อมูลและ interoperability ระหว่างแพลตฟอร์มต่าง ๆ
Aguilar และคณะ (2021) [3] เสนอกรอบ “Autonomic Cycle of Data Analysis Tasks” สำหรับ HVAC systems ใน smart buildings โดยแบ่งเป็นวงจร monitor–analyze–plan–execute (MAPE) ซึ่งเป็นกรอบแนวคิดสำคัญให้กับโครงงานนี้ ในการออกแบบ pipeline: Sensors → Data Collection → AI Analytics → Control Actions
6.2 งานวิจัยด้านการพยากรณ์การใช้พลังงานด้วย LSTM และโมเดลลูกผสม
Sun และคณะ (2025) [4] พัฒนา Twin Time-Series Network (T2SNET) สำหรับพยากรณ์พลังงานอาคาร โดยใช้ CEEMDAN สำหรับแยกสัญญาณและใช้ TCN กับ time embedding เพื่อดึง pattern เชิงเวลา ผลการทดลองกับชุดข้อมูลอาคารมหาวิทยาลัย (ชั้นเรียนและหอพัก) พบว่า T2SNET ลดค่า MAE, RMSE, MAPE ได้ดีกว่า baseline LSTM อย่างมีนัยสำคัญ แสดงให้เห็นว่า hybrid deep models ให้ความแม่นยำสูงกว่าการใช้ LSTM เดี่ยว ๆ
El Assri และคณะ (2025) [5] เสนอโมเดล multi-layer LSTM ร่วมกับเทคนิค denoising สำหรับการพยากรณ์การใช้พลังงานอาคาร โดยใช้วิธี preprocessing ข้อมูลด้วย Variational Mode Decomposition (VMD) ก่อนป้อนเข้า LSTM ผลลัพธ์แสดงให้เห็นว่าการจัดการสัญญาณรบกวนก่อนเทรนโมเดลช่วยเพิ่มความแม่นยำได้อย่างชัดเจน
งานของ Shahsavari-Pour และคณะ (2025) [6] ใช้การผสมผสาน mutual information, VMD และ LSTM เพื่อพยากรณ์รูปแบบการใช้ไฟฟ้าในอาคาร ผลการทดลองยืนยันว่าการเลือก feature โดยอิง mutual information และการแยกสัญญาณแบบ VMD ช่วยลด error (เช่น RMSE, MAPE) เมื่อเทียบกับการใช้ LSTM แบบตรง ๆ
งานของ Sun Z. et al. (2025) [7] ใน Scientific Reports ยังนำเสนอ hybrid model ที่ผสม wavelet decomposition กับ LSTM สำหรับการพยากรณ์พลังงานอาคาร พบว่าการใช้ wavelet ช่วยดึง feature ในหลายระดับความถี่ ทำให้โมเดลเรียนรู้ pattern รายวัน–รายสัปดาห์–ตามฤดูกาล ได้ดียิ่งขึ้น
งานเหล่านี้ชี้ว่า หาก Smart Energy Insight ใช้ LSTM/Hybrid Model พร้อม data preprocessing ที่เหมาะสม ก็สามารถตั้งเป้าความแม่นยำระดับ ≥90% ได้อย่างสมเหตุสมผล
6.3 งานวิจัยด้าน IoT Energy Monitoring ด้วย ESP32 + PZEM-004T / LoRa
Sirait และคณะ (2025) [8] พัฒนาระบบ IoT monitoring สำหรับห้องปฏิบัติการด้านโทรคมนาคม โดยใช้ PZEM-004T, ESP32 และ LoRa SX1276 สำหรับวัดแรงดัน กระแส กำลัง พลังงาน และ power factor จากสองห้องทดลอง และส่งข้อมูลผ่านเครือข่าย LoRa ไปยัง gateway ก่อนส่งต่อขึ้น Blynk cloud ระบบมีฟีเจอร์ auto cut-off และ email notification เมื่อเกิดเงื่อนไขผิดปกติ ค่า error ในการวัดแรงดันอยู่ที่ 0.29% และกระแสที่ 2.52% แต่พบ packet loss ประมาณ 20% และ delay สูง (11 วินาทีบน Blynk, 37 วินาทีสำหรับ email) แสดงให้เห็นข้อจำกัดของ cloud-only approach สำหรับ real-time control
Suma และคณะ (2025) [9] นำเสนอ “Next-generation residential energy management: A web-based self-hosting solution” โดยใช้ NodeMCU (ESP8266) และ PZEM-004T V3.0 พร้อม MQTT และ Google Firebase สำหรับ monitoring และ control แบบ real-time ในบ้านอยู่อาศัย ระบบต้นแบบมีต้นทุนต่ำกว่า 20 ดอลลาร์สหรัฐ สามารถวัดแรงดัน/กระแส/กำลังได้ด้วยความแม่นยำสูง (calibration efficiency 98.58%, error แรงดัน 0.15% และกระแส 3.12%) แสดงให้เห็นศักยภาพของสถาปัตยกรรมต้นทุนต่ำในการให้ข้อมูลบริหารพลังงานระดับครัวเรือน
Dagsa และคณะ (2023) [10] พัฒนา “IoT-Enabled Energy Consumption Monitoring and Control System” โดยใช้ PZEM004T, ESP32 TTGO TCALL, relay และ contactor เพื่อติดตั้งในตู้ไฟฟ้า (panel) ของอาคาร การทดลองแสดงให้เห็นว่า สามารถตัดโหลด/เปิดโหลดระยะไกลได้อย่างมีเสถียรภาพ และมี error การวัดอยู่ในระดับยอมรับได้สำหรับงานวิศวกรรมภาคสนาม
Aremu และคณะ (2025) [11] สร้างระบบ “AI–IoT based Smart Energy System for Multi-Unit Residential Buildings” ใช้ dual PZEM004T, ESP32, relay, keypad, LCD และ Blynk platform พร้อม LSTM model สำหรับพยากรณ์การใช้พลังงานรายชั่วโมง ระบบสามารถสลับโหลดอัตโนมัติ, ป้องกัน overvoltage/overcurrent และทำ prediction ด้วยค่า MSE ต่ำถึง 0.0229 แสดงให้เห็นตัวอย่างการผสาน IoT sensing + control + AI forecasting แบบ end-to-end ใกล้เคียงกับแนวคิดของ Smart Energy Insight มาก
งานของ Taştan (2025) [12] พัฒนา IoT-based Smart Energy Management and Load Shifting System สำหรับบ้านอยู่อาศัย โดยใช้ smart meter ต้นทุนต่ำและวิเคราะห์ศักยภาพ load shifting มีการทดลองสร้าง scenario shifting 25%, 50%, 75% ของโหลดที่สามารถเลื่อนได้ พบว่าสามารถลดค่าไฟฟ้าได้ 9.8%, 17.6% และ 26.1% ตามลำดับ แสดงให้เห็นการเชื่อมโยงระหว่างข้อมูลพลังงานละเอียดกับการตัดสินใจเชิงเศรษฐศาสตร์อย่างชัดเจน
6.4 งานวิจัยด้าน Real-Time Monitoring, Edge, และ User-Centric Dashboards
Govindarajan และคณะ (2025) [13] เสนอระบบ “user-centric real-time energy monitoring system” ซึ่งออกแบบสถาปัตยกรรมการเก็บข้อมูลพลังงานในอาคารแบบ real-time และเน้น usability ของผู้ใช้ปลายทาง โดยผลักภาระด้าน data aggregation และ pre-processing ไปที่ edge/gateway ก่อนส่งขึ้น backend เพื่อให้ dashboard ตอบสนองได้เร็ว และลด bandwidth ที่ต้องใช้
JCEIM (2023) [14] เสนอ work ด้าน edge-based IoT data processing ซึ่งชี้ว่าการย้ายงานประมวลผลไปไว้ที่ edge สามารถลด latency และลดปริมาณข้อมูลที่ต้องส่งขึ้น cloud ได้อย่างมีนัยสำคัญ โดยเฉพาะเมื่อมี sensor จำนวนมาก และมีความถี่การส่งข้อมูลสูง
งานของ Nabto และ Bluebird Fiber ในภาคอุตสาหกรรม IoT ระบุชัดว่าการใช้ MQTT + Edge processing สามารถลด round-trip latency ลงเหลือระดับ sub-second ซึ่งเพียงพอสำหรับงาน real-time control เช่น การควบคุมอุปกรณ์ไฟฟ้าในอาคาร
6.5 งานวิจัยด้านกรอบ big-picture: Smart Building, Energy Policy, และ Sustainability
Aguilar et al. (2021) และ Bajwa et al. (2024) [15] ต่างชี้ไปในทิศทางเดียวกันว่าการจะทำ smart building ให้ประสบความสำเร็จ ต้องมองทั้งด้านเทคนิค (AI, IoT, Edge, Cloud) และด้าน non-technical เช่น มาตรฐาน interoperability, data governance, และนโยบายสนับสนุน
กรอบการทบทวนของ Aguilar (2021) เกี่ยวกับ “energy self-management in smart buildings” ยังเน้นแนวคิด “Autonomic Building” ที่สามารถ monitor–analyze–plan–execute โดยใช้ AI ครบวงจร ซึ่งเป็นแนวคิดที่โครงงาน Smart Energy Insight สามารถนำมาปรับใช้โดยเน้นที่ energy use และ demand response
งานเชิงนโยบายด้าน energy innovation และ carbon mitigation ยังชี้ว่า นวัตกรรมการบริหารพลังงานแบบ “data-driven + AI” เป็นหนึ่งในเครื่องมือสำคัญในการบรรลุเป้าหมายการลดคาร์บอนในระดับเขตเมืองและสถาบันการศึกษา สิ่งนี้ทำให้โครงงานมีความสำคัญไม่เพียงในระดับเทคนิค แต่ยังเป็นส่วนหนึ่งของกลยุทธ์ด้านความยั่งยืน (sustainability) ของมหาวิทยาลัยและประเทศ
6.6 สรุปช่องว่างและจุดที่โครงงานจะต่อยอด
จากงานที่ทบทวนมา สามารถสังเคราะห์ข้อค้นพบสำคัญได้ว่า
- มีงานวิจัยจำนวนมากที่พิสูจน์แล้วว่า AI (โดยเฉพาะ LSTM และ hybrid models) สามารถเพิ่มความแม่นยำในการพยากรณ์พลังงานของอาคารได้สูงมาก และช่วยลดการใช้พลังงานได้ในระดับ 20–50%
- มีระบบต้นแบบ IoT + ESP32 + PZEM-004T + MQTT/LoRa ที่พิสูจน์แล้วว่า ต้นทุนต่ำ แม่นยำ และติดตั้งได้จริงในห้องทดลองและอาคารขนาดเล็ก แต่ส่วนใหญ่ยังเน้น monitoring มากกว่าการ integrate AI + control แบบเต็มระบบ
- งานด้าน real-time user-centric dashboards และ edge computing แสดงให้เห็นสถาปัตยกรรมที่ดี แต่ยังขาด use case เฉพาะในบริบท “มหาวิทยาลัยไทย/อาคารเรียน” ที่ใช้ทั้ง AI forecasting + real-time control + load shifting ร่วมกัน
ดังนั้น Smart Energy Insight จะต่อยอดในจุดที่ว่า:
- ใช้สถาปัตยกรรม IoT ต้นทุนต่ำ (ESP32 + PZEM-004T + MQTT + Edge)
- ผสาน AI (LSTM/Hybrid) สำหรับพยากรณ์และแนะนำโหลด
- มี dashboard ที่ออกแบบเพื่อ “ผู้ดูแลอาคารมหาวิทยาลัย” โดยเฉพาะ
- ทดสอบจริงในสภาพแวดล้อมอาคารเรียน/ห้องปฏิบัติการ พร้อมวัดผลด้านพลังงาน เศรษฐกิจ และ CO₂
รายการอ้างอิง (Reference List)
- JCEIM. (2023). Real-Time Data Processing Method of IoT Based on Edge Computing. Journal of Contemporary Engineering and Information Management.
- Bajwa, A., Jahan, S., et al. (2024). A Systematic Literature Review on AI-Enabled Smart Building Management Systems for Energy Efficiency and Sustainability. SSRN. https://doi.org/10.2139/ssrn.5190519
- Aguilar, J., Ardila, D., Avendaño, A., et al. (2021). A systematic literature review on the use of artificial intelligence in energy self-management in smart buildings. Renewable and Sustainable Energy Reviews, 151, 111–129.
- Emedo, C., et al. (2025). AI-driven transformations in smart buildings: A review of technologies and real estate management. Journal on Sustainable Built Environment.
- Sun, Z., Cui, H., Mei, X., & Yuan, H. (2025). A novel twin time series network for building energy consumption predicting. PLoS ONE, 20(6), e0326576. https://doi.org/10.1371/journal.pone.0326576
- El Assri, N., et al. (2025). Enhancing building energy consumption prediction using multi-layer LSTM and denoising techniques. Energy and AI.
- Shahsavari-Pour, N., et al. (2025). Building electrical consumption patterns forecasting based on VMD-LSTM with mutual information feature selection. Energy Reports.
- Sun, Z. et al. (2025). Energy consumption prediction in buildings using LSTM with wavelet decomposition. Scientific Reports.
- Sirait, R., Pardede, M., Hutajulu, E., et al. (2025). Implementation of PZEM-004T and LoRa for Internet of Things–Based Monitoring of Power Supply Sources in Laboratory Building. Jurnal Mandiri IT, 14(2), 223–235. https://doi.org/10.35335/mandiri.v14i2.457
- Aremu, A. S., Adejumobi, I. A., & Amusa, K. A. (2025). AI–IoT based Smart Energy System for Multi-Unit Residential Buildings. International Journal of Computer Applications, 187(39), 39–46. https://doi.org/10.5120/ijca2025925686
- Suma, S., Manikanta, R. G., et al. (2025). Next-generation residential energy management: A web-based self-hosting solution. Asian Journal of Water, Environment and Pollution, Article AJWEP025050028. https://doi.org/10.36922/AJWEP025050028
- Taştan, M. (2025). IoT-Based Smart Energy Management and Load Shifting for Residential Consumption Optimization. Celal Bayar University Journal of Science, 21(3), 166–183. https://doi.org/10.18466/cbayarfbe.1660181
- Dagsa, L. M., et al. (2023). IoT-Enabled Energy Consumption Monitoring and Control System using PZEM004T and ESP32. IEEE Conference on Smart Grid and Clean Energy Technologies.
- Govindarajan, T. S., et al. (2025). Development and implementation of a user-centric real-time energy monitoring system. Energy & Buildings.
- InfluxData. (2025). Time Series Database Explained and Time Series Platform – InfluxDB. InfluxData Whitepapers. https://www.influxdata.com/time-series-database
เสริม
การเขียนรายงานการศึกษาใน Concept Paper คือการ สร้างภาพรวมงานวิจัย และ กำหนดจุดยืน ของโครงงานเรา
เริ่มต้นด้วยการ จัดกลุ่มงานวิจัยที่เกี่ยวข้องตามหัวข้อหลัก (เช่น AI, IoT Platform, Hardware) เพื่อให้เห็นภูมิทัศน์ จากนั้น วิเคราะห์ทุกงานวิจัย โดยเน้นที่ ผลลัพธ์ที่เป็นรูปธรรม และ ข้อจำกัดที่ยังเป็นปัญหาอยู่
สุดท้าย ให้ใช้ข้อจำกัดเหล่านั้นเป็น ข้อสรุปเชิงตรรกะ เพื่อระบุว่า โครงงานของเรามี ความใหม่ (Novelty) อย่างไร และมีความจำเป็นอย่างไรในการ ขยายขอบเขต หรือ เชื่อมโยงเทคโนโลยี ที่งานวิจัยก่อนหน้ายังทำได้ไม่สมบูรณ์
7. ทฤษฏี สมมติฐาน หรือกรอบแนวคิดของโครงงาน
โครงงาน Smart Energy Insight ใช้กรอบแนวคิดและทฤษฎีหลายสาขาวิชามาผสมผสานเพื่อสร้างระบบบริหารจัดการพลังงานอาคารที่มีประสิทธิภาพ ครอบคลุมตั้งแต่ทฤษฎีด้านวิศวกรรมคอมพิวเตอร์ ระบบควบคุมอัตโนมัติ ปัญญาประดิษฐ์ ไปจนถึงหลักการด้านพลังงานและอาคาร
7.1 กรอบแนวคิดหลัก: MAPE-K Control Loop สำหรับระบบอัตโนมัติ
7.1.1 หลักการ MAPE-K Loop
MAPE-K Loop เป็นกรอบแนวคิดพื้นฐานของ Autonomic Computing ที่ถูกพัฒนาโดย IBM ในปี 2003 เพื่อสร้างระบบที่สามารถบริหารจัดการตัวเอง (Self-Managing Systems) กรอบแนวคิดนี้ประกอบด้วย 5 องค์ประกอบหลัก
Monitor (ตรวจวัด): เป็นกระบวนการเก็บรวบรวมข้อมูลจาก Sensor และแหล่งข้อมูลต่าง ๆ ในระบบ สำหรับ Smart Energy Insight หมายถึงการใช้ IoT Sensor (PZEM-004T, DHT22, PIR) เพื่อตรวจวัดค่าพลังงาน อุณหภูมิ ความชื้น และจำนวนผู้ใช้งานในแต่ละโซนของอาคาร ข้อมูลเหล่านี้จะถูกส่งผ่าน MQTT Protocol ไปยัง Edge Server เพื่อประมวลผลเบื้องต้น
Analyze (วิเคราะห์): เป็นกระบวนการประมวลผลข้อมูลที่รวบรวมมา เพื่อค้นหารูปแบบ (Pattern) ตรวจจับความผิดปกติ (Anomaly Detection) และสร้างข้อมูลเชิงลึก (Insight) ในระบบ Smart Energy Insight ใช้ Edge Computing เพื่อประมวลผลข้อมูลในพื้นที่ ลด Latency และเพิ่มความปลอดภัยของข้อมูล การวิเคราะห์รวมถึงการหา Peak Demand, การเปรียบเทียบการใช้พลังงานกับ Baseline และการตรวจจับพฤติกรรมผิดปกติ
Plan (วางแผน): เป็นกระบวนการตัดสินใจว่าจะดำเนินการอย่างไรเพื่อบรรลุเป้าหมาย สำหรับ Smart Energy Insight ใช้โมเดล AI (LSTM และ Gradient Boosting) เพื่อพยากรณ์การใช้พลังงานล่วงหน้า และสร้าง Recommendation สำหรับการลดโหลด เช่น การเลื่อนเวลาใช้งาน (Load Shifting) หรือการปิดอุปกรณ์ที่ไม่จำเป็น
Execute (ดำเนินการ): เป็นกระบวนการนำแผนที่วางไว้ไปปฏิบัติ ในระบบ Smart Energy Insight หมายถึงการส่งคำสั่งควบคุมไปยัง Relay Module เพื่อเปิด/ปิดอุปกรณ์ไฟฟ้า การอัปเดต Dashboard และการส่ง Notification ไปยังเจ้าหน้าที่ดูแลอาคาร
Knowledge (ฐานความรู้): เป็นส่วนกลางที่เก็บข้อมูลและความรู้ที่ใช้ร่วมกันระหว่างทุก Phase ของ MAPE Loop ในระบบ Smart Energy Insight ใช้ InfluxDB เป็น Time-Series Database สำหรับเก็บข้อมูลประวัติการใช้พลังงาน พร้อมกับ Trained ML Models และ Business Rules ที่ใช้ในการตัดสินใจ
วงจรควบคุม MAPE-K สำหรับระบบบริหารจัดการพลังงานอาคารอัจฉริยะ
7.1.2 การประยุกต์ใช้ MAPE-K ในระบบ Smart Energy Insight
สถาปัตยกรรมของระบบ Smart Energy Insight ถูกออกแบบตามกรอบ MAPE-K โดยแบ่งเป็น 4 Layer หลัก
สถาปัตยกรรมเชิงแนวคิดของระบบ Smart Energy Insight ตามกรอบ MAPE-K Loop
IoT Sensor Layer ทำหน้าที่เป็น Monitor โดยใช้ PZEM-004T สำหรับวัดค่าพลังงาน (Voltage, Current, Power, Power Factor), DHT22 สำหรับวัดอุณหภูมิและความชื้น, PIR Sensor สำหรับตรวจจับการใช้งานพื้นที่ และ CT Sensor สำหรับวัดกระแสแบบไม่รุกราน
Edge Computing Layer ทำหน้าที่ทั้ง Monitor และ Analyze โดยใช้ ESP32 Gateway ที่ติดตั้ง MQTT Broker (Mosquitto) สำหรับรับข้อมูลจาก Sensor และ InfluxDB สำหรับเก็บข้อมูลแบบ Time-Series การประมวลผลที่ Edge ช่วยลด Latency ลงเหลือต่ำกว่า 2 วินาที และเพิ่มความปลอดภัยของข้อมูล
AI Analytics Layer ทำหน้าที่เป็น Analyze และ Plan โดยใช้ LSTM Model สำหรับพยากรณ์การใช้พลังงานล่วงหน้า 24 ชั่วโมง, Gradient Boosting สำหรับ Classification และ Anomaly Detection, และ Recommendation Engine สำหรับสร้างคำแนะนำการลดโหลด
Application Layer ทำหน้าที่เป็น Execute โดยใช้ Web Dashboard (React.js) สำหรับแสดงผลข้อมูลและรับคำสั่งจากผู้ใช้งาน, Control Interface สำหรับควบคุมอุปกรณ์ไฟฟ้า และ LINE Notify สำหรับส่ง Alert ไปยังเจ้าหน้าที่
7.2 ทฤษฎีด้านปัญญาประดิษฐ์: Long Short-Term Memory (LSTM)
7.2.1 ปัญหาของ Recurrent Neural Networks (RNN) แบบดั้งเดิม
RNN แบบดั้งเดิมมีปัญหาสำคัญคือ Vanishing Gradient Problem ซึ่งเกิดขึ้นเมื่อ Gradient ของ Error ลดลงอย่างรวดเร็วในระหว่างการ Backpropagation Through Time ทำให้โมเดลไม่สามารถเรียนรู้ Long-term Dependencies ได้อย่างมีประสิทธิภาพ ปัญหานี้ทำให้ RNN ไม่เหมาะสำหรับการพยากรณ์ Time-Series ที่มีความยาว เช่น การใช้พลังงานของอาคารที่มีรูปแบบรายวัน รายสัปดาห์ และรายฤดูกาล
7.2.2 โครงสร้างและกลไกของ LSTM
LSTM ถูกพัฒนาโดย Hochreiter และ Schmidhuber ในปี 1997 เพื่อแก้ปัญหา Vanishing Gradient โดยใช้กลไก Gate และ Cell State ที่ช่วยให้โมเดลสามารถจดจำหรือลืมข้อมูลได้อย่างเลือกสรร LSTM Cell ประกอบด้วย 3 Gate หลัก
โครงสร้าง LSTM Cell สำหรับการพยากรณ์อนุกรมเวลาการใช้พลังงาน
Forget Gate (ftft): ตัดสินใจว่าข้อมูลใดใน Cell State ควรถูกลืม โดยใช้ Sigmoid Activation Function เพื่อสร้างค่าระหว่าง 0 (ลืมทั้งหมด) ถึง 1 (จำทั้งหมด)
ft=σ(Wf⋅[ht−1,xt]+bf)ft=σ(Wf⋅[ht−1,xt]+bf)
Input Gate (itit): ตัดสินใจว่าข้อมูลใหม่ใดควรถูกเพิ่มเข้าไปใน Cell State โดยใช้ Sigmoid Function ร่วมกับ Tanh Function
it=σ(Wi⋅[ht−1,xt]+bi)it=σ(Wi⋅[ht−1,xt]+bi)
C~t=tanh(WC⋅[ht−1,xt]+bC)C~t=tanh(WC⋅[ht−1,xt]+bC)
Output Gate (otot): ตัดสินใจว่า Output ของ LSTM Cell ควรเป็นอย่างไร
ot=σ(Wo⋅[ht−1,xt]+bo)ot=σ(Wo⋅[ht−1,xt]+bo)
ht=ot⋅tanh(Ct)ht=ot⋅tanh(Ct)
Cell State Update: Cell State (CtCt) ถูกอัปเดตโดยการลืมข้อมูลเก่าและเพิ่มข้อมูลใหม่
Ct=ft⋅Ct−1+it⋅C~tCt=ft⋅Ct−1+it⋅C~t
7.2.3 การประยุกต์ใช้ LSTM สำหรับพยากรณ์พลังงาน
ในระบบ Smart Energy Insight ใช้ LSTM Network สำหรับพยากรณ์การใช้พลังงานของอาคารล่วงหน้า 24 ชั่วโมง โดยใช้ข้อมูล Input ได้แก่ ประวัติการใช้พลังงาน 7-14 วันย้อนหลัง, อุณหภูมิและความชื้น, จำนวนผู้ใช้งาน และข้อมูลเวลา (ชั่วโมง, วันในสัปดาห์, เดือน) จากการทบทวนงานวิจัย พบว่า LSTM สามารถให้ความแม่นยำในการพยากรณ์พลังงานสูงถึง 90-99% (วัดโดย R² หรือ MAPE) โดยเฉพาะเมื่อใช้ร่วมกับเทคนิค Preprocessing เช่น VMD หรือ Wavelet Decomposition
7.3 ทฤษฎีด้าน Edge Computing
7.3.1 หลักการ Edge Computing
Edge Computing เป็นสถาปัตยกรรมการประมวลผลแบบกระจาย (Distributed Computing) ที่ย้ายการประมวลผลข้อมูลจาก Cloud มายัง Edge ของเครือข่าย ใกล้กับแหล่งกำเนิดข้อมูล (IoT Devices) มากที่สุด หลักการนี้ให้ประโยชน์หลัก 4 ประการ
Reduced Latency: การประมวลผลที่ Edge ลด Round-trip Time ระหว่าง Device และ Cloud ลงอย่างมาก จากระดับวินาทีเหลือเพียงมิลลิวินาที ซึ่งจำเป็นสำหรับการควบคุมอุปกรณ์ไฟฟ้าแบบ Real-time
Improved Bandwidth: การประมวลผลและ Filter ข้อมูลที่ Edge ก่อนส่งขึ้น Cloud ลดปริมาณข้อมูลที่ต้องส่งผ่านเครือข่าย ประหยัด Bandwidth และลดค่าใช้จ่าย
Enhanced Security: การเก็บข้อมูลละเอียดไว้ที่ Edge และส่งเพียงข้อมูลสรุปขึ้น Cloud ลดความเสี่ยงในการรั่วไหลของข้อมูลส่วนตัว
Offline Capabilities: Edge Device สามารถทำงานต่อได้แม้ไม่มีการเชื่อมต่อ Internet ทำให้ระบบมี Resilience และ Reliability สูง
7.3.2 สถาปัตยกรรม Edge Computing ในระบบ Smart Energy Insight
ระบบ Smart Energy Insight ใช้ Raspberry Pi หรือ PC Mini Server เป็น Edge Server ที่ติดตั้ง Mosquitto (MQTT Broker) และ InfluxDB ในพื้นที่ ESP32 Gateway ทำหน้าที่เป็น Edge Node ที่ประมวลผลข้อมูลเบื้องต้น (Data Aggregation, Filtering) ก่อนส่งไปยัง Edge Server สถาปัตยกรรมนี้ทำให้ระบบสามารถตอบสนองต่อเหตุการณ์ (Event) ได้ภายใน 2 วินาที และสามารถทำงานต่อได้แม้ Internet ขัดข้อง
7.4 ทฤษฎีด้านการสื่อสาร: MQTT Protocol
7.4.1 หลักการ Publish/Subscribe Model
MQTT (Message Queuing Telemetry Transport) เป็น Protocol การสื่อสารแบบ Lightweight ที่ออกแบบมาสำหรับ IoT Applications โดยใช้รูปแบบ Publish/Subscribe (Pub/Sub) ซึ่งแตกต่างจาก Request/Response Model แบบดั้งเดิม
Decoupling: Publisher และ Subscriber ไม่จำเป็นต้องรู้จักกัน เพียงแค่รู้จัก Topic ที่สนใจ ทำให้ระบบมี Flexibility และ Scalability สูง
Broker-based Architecture: MQTT Broker ทำหน้าที่เป็นตัวกลางในการรับ Message จาก Publisher และส่งต่อไปยัง Subscriber ที่ลงทะเบียน Topic นั้น ๆ
Quality of Service (QoS): MQTT รองรับ 3 ระดับ QoS ได้แก่ QoS 0 (At most once), QoS 1 (At least once), และ QoS 2 (Exactly once) เพื่อให้เลือกระดับความน่าเชื่อถือตามความต้องการ
7.4.2 การใช้งาน MQTT ในระบบ Smart Energy Insight
ESP32 Gateway ทำหน้าที่เป็น MQTT Publisher ที่ส่งข้อมูลพลังงาน อุณหภูมิ และสถานะการใช้งานไปยัง Topic ต่าง ๆ เช่น building/zone1/power, building/zone1/temperature Edge Server ที่ติดตั้ง Mosquitto Broker รับ Message และส่งต่อไปยัง InfluxDB และ AI Analytics Module ที่ Subscribe Topic เหล่านี้ Web Dashboard และ Control System ก็ Subscribe Topic เพื่อรับข้อมูล Real-time และ Publish คำสั่งควบคุมกลับไปยัง Relay Module
7.5 ทฤษฎีด้านพลังงาน: Demand Response และ Load Shifting
7.5.1 หลักการ Demand Response
Demand Response (DR) เป็นกลยุทธ์การบริหารจัดการพลังงานที่เปลี่ยนรูปแบบการใช้พลังงานของผู้ใช้งาน (End-user) เพื่อตอบสนองต่อสัญญาณราคาหรือสถานะของโครงข่ายไฟฟ้า (Grid) DR มี 4 รูปแบบหลัก
Demand Limiting: ลดการใช้พลังงานเมื่อใกล้ถึงค่าสูงสุดที่กำหนดไว้ เพื่อหลีกเลี่ยงค่าปรับ Peak Demand Charge
Demand Shedding: ลดการใช้พลังงานในช่วง Peak ของ Grid เพื่อช่วยรักษาเสถียรภาพของระบบไฟฟ้า
Load Shifting: เลื่อนการใช้พลังงานจากช่วง Peak ไปยังช่วง Off-peak เช่น การ Pre-cooling อาคารก่อนช่วงเวลาที่ค่าไฟแพง
Onsite Generation: ใช้แหล่งพลังงานในพื้นที่ (เช่น Solar PV, Battery) แทนการซื้อไฟจาก Grid ในช่วง Peak
7.5.2 การประยุกต์ใช้ Load Shifting ในระบบ Smart Energy Insight
ระบบ Smart Energy Insight ใช้ AI Recommendation Engine เพื่อแนะนำการ Load Shifting โดยอิงจากการพยากรณ์การใช้พลังงานและอัตราค่าไฟ Time-of-Use (TOU) ตัวอย่างเช่น ระบบอาจแนะนำให้ Pre-cool อาคารในช่วงเช้า (Off-peak) และลดการใช้ HVAC ในช่วงบ่าย (Peak) โดยใช้ประโยชน์จาก Thermal Mass ของอาคาร จากการศึกษาพบว่า Load Shifting สามารถลดค่าไฟฟ้าได้ 10-26% ขึ้นอยู่กับสัดส่วนของโหลดที่สามารถเลื่อนได้
7.6 ทฤษฎีด้านอาคาร: Thermal Mass และ Building Inertia
7.6.1 หลักการ Thermal Mass
Thermal Mass หมายถึงความสามารถของวัสดุในการดูดซับ เก็บ และปล่อยพลังงานความร้อน วัสดุที่มี Thermal Mass สูง เช่น คอนกรีต อิฐ และหิน สามารถทำหน้าที่เป็น “Battery ความร้อน” ที่ช่วยรักษาอุณหภูมิภายในอาคารให้คงที่
หลักการทำงานของ Thermal Mass ในอาคาร: เมื่ออุณหภูมิภายนอกสูงขึ้น (กลางวัน) Thermal Mass จะดูดซับความร้อนส่วนเกิน ช่วยรักษาอุณหภูมิภายในให้เย็นกว่าภายนอก เมื่ออุณหภูมิภายนอกลดลง (กลางคืน) Thermal Mass จะปล่อยความร้อนที่เก็บไว้ออกมา ช่วยรักษาความอบอุ่น
7.6.2 การใช้ประโยชน์จาก Thermal Mass ในระบบ Smart Energy Insight
ระบบ Smart Energy Insight ใช้ประโยชน์จาก Thermal Mass ของอาคาร โดยเฉพาะอาคารคอนกรีตที่มี Thermal Inertia สูง เพื่อทำ Pre-cooling หรือ Pre-heating ในช่วง Off-peak ก่อนที่จะถึงช่วง Peak กลยุทธ์นี้ช่วยให้สามารถลดการใช้ HVAC ในช่วง Peak ได้โดยไม่กระทบต่อความสบายของผู้ใช้งาน เนื่องจาก Thermal Mass จะค่อย ๆ ปล่อยความเย็นออกมา
7.7 สมมติฐานของโครงงาน
จากทฤษฎีและกรอบแนวคิดที่กล่าวมา โครงงาน Smart Energy Insight ตั้งสมมติฐานไว้ดังนี้
สมมติฐานที่ 1: การใช้ IoT Sensor เพื่อเก็บข้อมูลพลังงานแบบ Real-time จะให้ข้อมูลที่ละเอียดและแม่นยำเพียงพอสำหรับการวิเคราะห์และควบคุมพลังงานของอาคาร
สมมติฐานที่ 2: การใช้ LSTM Model สำหรับพยากรณ์การใช้พลังงานจะให้ความแม่นยำ (Accuracy) ไม่ต่ำกว่า 90% (วัดโดย R² ≥ 0.90)
สมมติฐานที่ 3: การใช้ Edge Computing จะลด Latency ในการส่งข้อมูลและควบคุมอุปกรณ์ลงเหลือไม่เกิน 2 วินาที
สมมติฐานที่ 4: การใช้ AI Recommendation Engine เพื่อแนะนำการ Load Shifting และควบคุมอุปกรณ์อัตโนมัติจะช่วยลดการใช้พลังงานของอาคารได้อย่างน้อย 20%
สมมติฐานที่ 5: ระบบต้นแบบที่พัฒนาขึ้นจะมีต้นทุนติดตั้งต่ำกว่าระบบ Building Management System แบบพาณิชย์อย่างน้อย 10 เท่า
เสริม
การเขียนส่วนกรอบแนวคิดคือการ แสดงฐานรากทางวิชาการ ของโครงงาน โดยต้องเน้นที่การ บูรณาการศาสตร์หลายแขนง เข้าด้วยกัน
ให้เริ่มต้นจากการนำเสนอ กรอบแนวคิดเชิงวิศวกรรมหลัก (เช่น MAPE-K Loop) เพื่อใช้เป็น พิมพ์เขียว (Blueprint) ของระบบ จากนั้นอธิบายว่า ส่วนประกอบแต่ละส่วนของระบบเรา (เช่น IoT Sensor, AI Model, Edge Server) ถูกสร้างขึ้นโดยอิงกับ ทฤษฎีเฉพาะทาง ใดบ้าง (LSTM Theory, Edge Computing Principles, Demand Response)
การทำแบบนี้เป็นการ พิสูจน์ความน่าเชื่อถือ ของการออกแบบ และนำไปสู่การตั้ง สมมติฐานที่วัดผลได้ โดยอ้างอิงจากประสิทธิภาพที่ทฤษฎีเหล่านั้นรับรองไว้ (เช่น เราคาดหวังความแม่นยำเท่าไรจาก LSTM)
จุดนี้ถ้ามีสมการก็ให้ใส่มาให้เรียบร้อย พร้อมคำอธิบายสมการให้ชัดเจนครบถ้วน และให้ระบุด้วยว่าสมการดังกล่าวจะเอามาใช้ทำอะไรกับโครงงานของเรา
8. ขอบเขตของโครงงาน
โครงงาน Smart Energy Insight – ระบบบริหารจัดการพลังงานอาคารด้วย AI และ IoT นี้มุ่งเน้นการพัฒนาและทดลองใช้งานของระบบต้นแบบในบริบทวิศวกรรมคอมพิวเตอร์ โดยแบ่งขอบเขตออกเป็นระบบหลักและระบบย่อยที่ต้องพัฒนา ดังนี้
8.1 ระบบหลักของโครงงาน
1. ระบบตรวจวัดและเก็บข้อมูลพลังงาน (Energy Monitoring System)
- ติดตั้งและใช้งาน IoT Sensor (PZEM-004T, DHT22, PIR, CT Sensor) ในพื้นที่ทดสอบ (อย่างน้อย 2–3 โซน)
- วัดและรวบรวมข้อมูลค่ากำลังไฟฟ้า, แรงดัน, กระแส, อุณหภูมิ, ความชื้น, สถานะการใช้งาน
- ส่งข้อมูลแบบ Real-time ผ่าน MQTT ไปยัง Edge Gateway
- บันทึกข้อมูลอนุกรมเวลาใน InfluxDB
2. ระบบประมวลผลเบื้องต้น (Edge Data Processing)
- Aggregation และ Preprocessing ข้อมูลพลังงานจากเซนเซอร์ทั้งหมด
- Filtering ข้อมูลผิดปกติหรือขาดหาย
- จัดเตรียมข้อมูลสำหรับ AI Analytics
- สนับสนุนการประมวลผลที่ Edge เพื่อลด Latency
3. ระบบวิเคราะห์และพยากรณ์การใช้พลังงาน (AI Analytics & Forecasting)
- พัฒนาและเทรน LSTM Model สำหรับการพยากรณ์การใช้พลังงานระยะสั้น (12–24 ชั่วโมง)
- เทรน Gradient Boosting/Hybrid Model สำหรับแนะนำวิธีลดโหลดและตรวจจับความผิดปกติ
- ประมวลผลข้อมูลแบบ Real-time เพื่อสร้าง Insight สำหรับผู้ดูแลอาคาร
4. ระบบคำแนะนำและควบคุมอุปกรณ์ (Smart Control & Recommendation)
- แนะนำวิธีการลดโหลด เช่น Load Shifting, การเปิด/ปิดอุปกรณ์ตาม AI Recommendation
- ส่งคำสั่งเปิด/ปิด (Relay Command) ไปยังอุปกรณ์ไฟฟ้าที่ควบคุม (เช่น HVAC, Lighting, Lab Equipment)
- บันทึกประวัติการควบคุมและผลลัพธ์ในฐานข้อมูล
5. ระบบ Dashboard สำหรับแสดงข้อมูลและควบคุม (User Dashboard & Reports)
- สร้างเว็บ Dashboard สำหรับดูข้อมูลเรียลไทม์ของแต่ละโซน
- รายงานผลการวิเคราะห์, พยากรณ์, คำแนะนำ, และกราฟเปรียบเทียบรายวัน/รายสัปดาห์
- ให้เจ้าหน้าที่สามารถควบคุมอุปกรณ์และรับ Notification (ผ่าน LINE Notify)
- Generate รายงานประจำวัน/สัปดาห์ในรูปแบบ PDF
8.2 ระบบย่อย (Feature/Subsystems)
1. ฟีเจอร์ตรวจจับพฤติกรรมการใช้พื้นที่ (Occupancy Analytics)
- แสดงสถิติการใช้พื้นที่ของแต่ละโซน
- วิเคราะห์รูปแบบการใช้งานและความสัมพันธ์กับการใช้พลังงาน
2. ฟีเจอร์แจ้งเตือน (Alert & Event Notification)
- แจ้งเตือนเมื่อพบพฤติกรรมการใช้พลังงานผิดปกติหรือสูงกว่าค่าเป้าหมาย
- ส่ง Alert อัตโนมัติไปยังผู้ดูแลระบบ
3. ฟีเจอร์เชื่อมต่อกับอุปกรณ์ไฟฟ้าหลายชนิด
- รองรับ Relay Control สำหรับอุปกรณ์ต่าง ๆ (ไฟฟ้า แอร์ พัดลม เครื่องคอมพิวเตอร์ ฯลฯ)
- ขยายขอบเขตไปสู่ IoT Device อื่น ๆ ในอนาคต (เช่น Smart Plug, Bluetooth Beacon)
4. ฟีเจอร์วิเคราะห์การประหยัดพลังงานและลดค่าใช้จ่าย
- คำนวณผลประหยัดพลังงานเมื่อใช้ระบบ
- เปรียบเทียบข้อมูลกับ Baseline และสร้างกราฟเปรียบเทียบอัตโนมัติ
ขอบเขตที่อยู่นอกโครงการ (Out-of-Scope)
- การเชื่อมต่อโดยตรงกับระบบ SMART GRID ภายนอก
- การบริหารจัดการพลังงานระหว่างอาคาร (Cluster/Grid scale)
- การควบคุมอุปกรณ์ไฟฟ้าที่ต้องผ่านมาตรฐานอุตสาหกรรม (เช่น อุปกรณ์แรงสูงพิเศษ)
- การสนับสนุนระบบ AI/ML สำหรับ Predictive Maintenance ในเชิงลึก (เน้นที่ Demand Response)
- การเชื่อมต่อกับระบบ ERP หรือระบบบัญชีภายใน
เสริม
ให้ระบุให้ชัดเจน ว่าโครงงานของเราจะมีระบบทั้งหมดอะไรบ้าง และในระบบหลักเหล่านั้นจะมีระบบย่อยอะไรบ้าง ในแต่ละระบบย่อยเหล่านั้นสามารถทำอะไรได้บ้าง ให้ระบุออกมาเป็นข้อๆ ให้ชัดเจน
และอะไรที่ไม่ได้อยู่ในขอบเขตก็ให้ระบุให้ครบถ้วนด้วย
9. แผนการดำเนินงาน
โครงงาน Smart Energy Insight จะดำเนินการภายใน 17 สัปดาห์ แบ่งออกเป็น 4 Phase หลัก ได้แก่ วางแผนและเตรียมการ, พัฒนาระบบหลัก, ทดสอบและปรับปรุง, และสรุปและมอบงาน กรรมการกำหนดเป้าหมายสำคัญ (Milestones) และ Deliverables ชัดเจน
9.1 Phase 1: วางแผนและเตรียมการ (Planning & Preparation) – สัปดาห์ 1–2
วัตถุประสงค์: เตรียมเครื่องมือ และเทคโนโลยี และวางแผนพัฒนาอย่างละเอียด
กิจกรรมหลัก:
- สัปดาห์ที่ 1:
- ส่วน Hardware: ซื้ออุปกรณ์ (PZEM-004T, ESP32, DHT22, PIR, Relay Module) และติดตั้ง Development Environment (Arduino IDE, VS Code)
- ส่วน Software: ติดตั้ง Node.js, Python, InfluxDB, Mosquitto, Git Repository
- ศึกษา Datasheet และ Reference Code สำหรับ PZEM-004T + ESP32
- สัปดาห์ที่ 2:
- ออกแบบ System Architecture ฉบับสมบูรณ์ (Diagram: Sensor Layer, Edge Layer, AI Layer, Application Layer)
- ออกแบบ Database Schema สำหรับ InfluxDB (Tags, Fields, Measurement)
- ออกแบบ API Endpoints สำหรับ Web Dashboard
- ป้อนข้อมูล Historical (Mock Data) เพื่อเตรียมพื้นฐาน ML Training
Deliverables:
- System Architecture Document
- Database Schema Specification
- API Design Document
- Hardware Setup Checklist
9.2 Phase 2: พัฒนาระบบหลัก (Core Development) – สัปดาห์ 3–11
9.2.1 ส่วนที่ 1: ระบบ IoT Sensor & Edge (สัปดาห์ 3–5)
กิจกรรม:
- สัปดาห์ที่ 3:
- ขึ้นโค้ด PZEM004T Driver บน ESP32 (อ่านค่า Voltage, Current, Power, Power Factor)
- ขึ้นโค้ด DHT22 Driver สำหรับวัด Temperature & Humidity
- ทดสอบการอ่านค่าผ่าน Serial Monitor
- สัปดาห์ที่ 4:
- เพิ่มฟีเจอร์ MQTT Communication (ESP32 → MQTT Broker)
- ทดสอบ Publishing ข้อมูลไปยัง Mosquitto Broker
- ปรับแต่ง QoS, Topic Naming Convention, และ Payload Format
- สัปดาห์ที่ 5:
- ติดตั้ง InfluxDB และ Mosquitto บน Raspberry Pi / Mini PC
- สร้าง MQTT Subscriber ที่ Subscribe Topic ทั้งหมด และ Insert ลง InfluxDB
- ทดสอบ End-to-End: Sensor → ESP32 → MQTT → InfluxDB
Deliverables:
- IoT Firmware Code (Arduino Sketch) พร้อม Comments
- MQTT Configuration Files
- Data Collection Demo (กราฟข้อมูล InfluxDB ทำงานมา 48 ชั่วโมง)
9.2.2 ส่วนที่ 2: ระบบ Web Dashboard (สัปดาห์ 6–8)
กิจกรรม:
- สัปดาห์ที่ 6:
- สร้าง Node.js API Server ที่ Query Data จาก InfluxDB
- เขียน API Endpoints:
/zones/{zoneId}/power,/zones/{zoneId}/temperature,/zones/{zoneId}/summary - Implement Authentication & Authorization (เบื้องต้น)
- สัปดาห์ที่ 7:
- สร้าง React Frontend Dashboard พร้อม Layout หลัก
- Implement Real-time Data Display โดยใช้ WebSocket หรือ Polling
- สร้างกราฟเรียลไทม์โดยใช้ Chart.js (Power, Temperature, Humidity)
- สัปดาห์ที่ 8:
- เพิ่ม Features: Tabular Data View, Daily/Weekly/Monthly Summary
- เพิ่ม Features: Occupancy Status Display, Control Buttons (Turn On/Off)
- ทดสอบ Dashboard แบบ Full Cycle: ส่งข้อมูลจาก Sensor → แสดงบน Dashboard
Deliverables:
- API Server Code (Node.js + Express)
- React Dashboard Source Code
- Deployment Instructions (Docker / Manual)
9.2.3 ส่วนที่ 3: ระบบ AI Forecasting (สัปดาห์ 9–11)
กิจกรรม:
- สัปดาห์ที่ 9:
- ดึง Historical Data จาก InfluxDB (อย่างน้อย 2–4 สัปดาห์)
- Data Preprocessing: Normalization, Feature Engineering (Time-based features: hour, day-of-week, month)
- Train-Test Split (80-20 หรือ 70-30)
- สัปดาห์ที่ 10:
- สร้าง LSTM Model ใน Python (Keras/TensorFlow)
- Hyperparameter Tuning: Learning Rate, Epochs, Batch Size, LSTM Units
- Evaluate Model: MAE, RMSE, R², MAPE บนชุดข้อมูล Test
- สัปดาห์ที่ 11:
- Deploy LSTM Model ไปยัง Edge Server (Serialization: Save Model as .h5 หรือ .pb)
- Integrate Model ใน Python Backend เพื่อ Inference Real-time (Forecast 24 ชั่วโมงข้างหน้า)
- ทดสอบ Inference Latency เพื่อให้แน่ใจว่า < 2 วินาที
Deliverables:
- Python Training Script พร้อม Data Processing
- Trained LSTM Model (.h5 / .pb file)
- Model Evaluation Report (MAE, RMSE, R², Charts)
- Python Inference Service Code
9.3 Phase 3: ทดสอบและปรับปรุง (Testing & Refinement) – สัปดาห์ 12–15
9.3.1 สัปดาห์ที่ 12: Integration Testing
กิจกรรม:
- ทดสอบการทำงาน End-to-End ของทั้งระบบ: Sensor → Edge → AI → Dashboard
- ตรวจสอบ Data Integrity: ข้อมูลจาก Sensor ถึง Dashboard ถูกต้องหรือไม่
- ทดสอบ Forecasting Accuracy บนข้อมูลจริง และเทียบกับค่าจริงที่เกิดขึ้นจริง
Deliverables:
- Integration Test Report
- Screenshots/Videos แสดง Full System Workflow
9.3.2 สัปดาห์ที่ 13: System Refinement & Optimization
กิจกรรม:
- ปรับปรุง LSTM Model: Fine-tune hyperparameters, เพิ่ม Features ใหม่ (เช่น Occupancy Sensor ข้อมูล)
- ปรับปรุง Dashboard: UI/UX, Responsiveness, Loading Time
- เพิ่ม Features: Alert Notification (ผ่าน LINE Notify), Export Data เป็น CSV
Deliverables:
- Updated LSTM Model & Training Script
- Updated Dashboard Code
- Feature Enhancement Document
9.3.3 สัปดาห์ที่ 14–15: Field Testing & Performance Measurement
กิจกรรม:
- ติดตั้งระบบในพื้นที่ทดสอบจริง (อาคารเรียน/ห้องปฏิบัติการ)
- เก็บข้อมูลพลังงาน 3–5 วันอย่างต่อเนื่อง
- วัดผลการพยากรณ์: เปรียบเทียบ Forecast Power กับ Actual Power
- คำนวณผลประหยัดพลังงาน (หาก Implement Load Shifting)
- เก็บ Feedback จากผู้ใช้งาน
Deliverables:
- Field Testing Report พร้อมข้อมูลเชิงลึก
- Performance Metrics (Forecast Accuracy, Response Time, Availability)
- User Feedback Summary
9.4 Phase 4: สรุปและมอบงาน (Documentation & Handover) – สัปดาห์ 16–17
9.4.1 สัปดาห์ที่ 16: Documentation & Preparation
กิจกรรม:
- เขียน Technical Documentation ครบถ้วน:
- System Architecture Document
- Installation & Deployment Guide
- User Manual (Dashboard Usage)
- Developer Guide (API Reference, Code Structure)
- Troubleshooting Guide
- บันทึก Hardware Setup & Wiring Diagram
- จัดเตรียม Demo Video (5–10 นาที) แสดงระบบทำงาน
- เตรียม Presentation Slides
Deliverables:
- Complete Documentation Package (PDF)
- Installation Checklist
- Demo Video
- Presentation Slides
9.4.2 สัปดาห์ที่ 17: Final Demo & Presentation
กิจกรรม:
- Dry Run Presentation ต่อ Advisor/ผู้ทรงคุณวุฒิ
- Final System Demonstration (Live Demo หรือ Video)
- นำเสนอผลลัพธ์: Energy Savings, Cost-Benefit Analysis, CO₂ Reduction
- รับ Feedback และจัดทำข้อเสนอแนะสำหรับพัฒนาต่อ
Deliverables:
- Final Project Report
- Presentation Slides (PDF)
- System Ready for Handover
9.5 ไทมไลน์โดยรวม (Consolidated Timeline)
| Phase | สัปดาห์ | กิจกรรมหลัก | Milestone |
|---|---|---|---|
| Planning | 1–2 | ซื้ออุปกรณ์, ศึกษา, ออกแบบ | System Architecture Done |
| IoT Development | 3–5 | Sensor Driver, MQTT, InfluxDB | End-to-End Data Collection Working |
| Dashboard Dev | 6–8 | API Server, React Frontend | Dashboard Displaying Real-time Data |
| AI Development | 9–11 | LSTM Training, Integration, Testing | Forecasting Model Deployed |
| Integration Testing | 12 | Full System Testing | All Components Integrated |
| Refinement | 13 | Model Optimization, UI Improvement | Enhanced Features Complete |
| Field Testing | 14–15 | Real-world Testing, Measurement | Performance Metrics Collected |
| Documentation | 16 | Technical Docs, Demo Prep | Complete Documentation |
| Final Demo | 17 | Presentation, Handover | Project Complete |
9.6 ความเสี่ยง (Risk Assessment) และแนวทางบรรเทา
| ความเสี่ยง | ความรุนแรง | แนวทางบรรเทา |
|---|---|---|
| Hardware Defect | Middle | ซื้ออุปกรณ์สำรองเพิ่มเติม 20% |
| Data Quality Issues | High | Implement Data Validation & Cleaning ตั้งแต่สัปดาห์ 3 |
| ML Model Accuracy < 90% | High | เตรียม Alternative Model (Hybrid LSTM+GB) ในสัปดาห์ 10 |
| Integration Issues | Middle | ทำการทดสอบ Integration ตั้งแต่ช่วงต้น ไม่ปล่อยไว้ถึงท้าย |
| Latency Issues (> 2 วินาที) | Middle | Implement Caching, Optimize Database Queries |
| Installation in Building | Middle | ประสานงานกับผู้ดูแลอาคารล่วงหน้า (สัปดาห์ 1–2) |
9.7 Resource Allocation & Responsibility
| Component | Owner | Timeline | Output |
|---|---|---|---|
| Hardware & Sensor | Responsible 1 | Wk 1–2, 14–15 | Functional IoT Node |
| Firmware & Edge | Responsible 1, 2 | Wk 3–5, 13 | MQTT + Data Ingestion |
| Backend API | Responsible 2, 3 | Wk 6, 9–11 | REST API + ML Inference |
| Frontend Dashboard | Responsible 3, 4 | Wk 6–8, 13 | React Dashboard |
| ML Model | Responsible 2 | Wk 9–11, 13 | LSTM Model + Deployment |
| Testing & Documentation | All | Wk 12–17 | Report + User Guides |
เสริม
ไม่ให้ใช้คำว่า “ศึกษา” โดยให้มองในมุมมองของตัว “โครงงาน” อย่างเดียว โดยต้องระบุให้ได้ว่าในแต่ละสัปดาห์ควรจะมีงานหลักงานย่อยอะไรบ้าง และงานย่อยแต่ละอย่างควรจะต้องเสร็จในสัปดาห์ไหนบ้าง
การแบ่งที่ชัดเจน ควรแบ่งเป็นเฟส ให้กรรมการทราบว่าแต่ละเฟสเราจะทำอะไรบ้าง ให้แตกงานหลักและงานย่อยออกมาให้ครบถ้วนตั้งแต่ส่วนนี้เลย เพราะตอนลงมือทำโครงงานจริงเราจะไม่มานั่งคิดกระบวนการส่วนนี้อีกต่อไปแล้ว เราจะทำงานตามแผนงานที่วางไว้เลย
10. ประโยชน์ที่คาดว่าจะได้รับ
โครงงาน Smart Energy Insight คาดว่าจะส่งมอบประโยชน์ในหลายมิติ ทั้งต่อสถาบันการศึกษา ผู้ใช้งาน ชุมชนวิชาการ และสังคมโดยรวม
10.1 ประโยชน์ต่อสถาบันการศึกษา
การนำระบบ Smart Energy Insight มาใช้ในอาคารเรียนหรือห้องปฏิบัติการจะช่วยลดค่าใช้จ่ายด้านพลังงานไฟฟ้าได้อย่างน้อย 20% ต่อปี เมื่อคำนวณจากอาคารที่มีค่าไฟฟ้าเฉลี่ย 50,000-100,000 บาทต่อเดือน การประหยัด 20% จะทำให้ลดค่าใช้จ่ายได้ประมาณ 120,000-240,000 บาทต่อปีต่ออาคาร นอกจากนี้ยังช่วยให้มหาวิทยาลัยมีข้อมูลเชิงลึกเกี่ยวกับรูปแบบการใช้พลังงาน สามารถวางแผนงบประมาณและบำรุงรักษาอุปกรณ์ไฟฟ้าได้อย่างมีประสิทธิภาพ และสนับสนุนเป้าหมาย Green Campus หรือ Net Zero Campus ของมหาวิทยาลัย
10.2 ประโยชน์ต่อนักศึกษาและบุคลากร
ผู้ใช้งานในอาคาร (นักศึกษา อาจารย์ เจ้าหน้าที่) จะได้รับประโยชน์จากสภาพแวดล้อมที่สะดวกสบายมากขึ้น เนื่องจากระบบสามารถปรับอุณหภูมิและแสงสว่างให้เหมาะสมกับการใช้งานจริง นอกจากนี้ยังสร้างความตระหนักรู้เกี่ยวกับการใช้พลังงานผ่าน Dashboard ที่แสดงข้อมูลแบบเรียลไทม์ ส่งเสริมพฤติกรรมการประหยัดพลังงานในระยะยาว
10.3 ประโยชน์ทางวิชาการและการเรียนรู้
โครงงานนี้จะเป็นกรณีศึกษา (Case Study) ที่มีคุณค่าสำหรับการเรียนการสอนในหลายรายวิชา ได้แก่ Embedded Systems, IoT Applications, Machine Learning, Software Engineering และ Energy Management นักศึกษาที่พัฒนาโครงงานจะได้รับทักษะเชิงปฏิบัติในการออกแบบระบบ Full-stack ตั้งแต่ Hardware, Firmware, Backend, Frontend จนถึง AI/ML ซึ่งเป็นทักษะที่ตลาดแรงงานต้องการสูง นอกจากนี้ยังสามารถต่อยอดเป็นงานวิจัยหรือบทความวิชาการในอนาคต
10.4 ประโยชน์ต่อสังคมและสิ่งแวดล้อม
การลดการใช้พลังงาน 20% ในพื้นที่ทดสอบจะช่วยลดการปล่อยก๊าซ CO₂ ประมาณ 40-60 ตันต่อปี สนับสนุนเป้าหมายการพัฒนาที่ยั่งยืน (SDGs) โดยเฉพาะ SDG 7 (Affordable and Clean Energy), SDG 11 (Sustainable Cities), และ SDG 13 (Climate Action) หากระบบนี้ถูกขยายไปยังอาคารอื่น ๆ ในมหาวิทยาลัยหรือสถาบันอื่น ผลกระทบเชิงบวกต่อสิ่งแวดล้อมจะเพิ่มขึ้นอย่างมีนัยสำคัญ
10.5 ประโยชน์เชิงเศรษฐกิจและการต่อยอด
ระบบต้นแบบที่พัฒนาขึ้นสามารถต่อยอดเป็นผลิตภัณฑ์เชิงพาณิชย์หรือบริการ Energy-as-a-Service สำหรับอาคารอื่น ๆ ในอนาคต สร้างโอกาสในการ Spin-off เป็น Startup หรือโครงการความร่วมมือกับภาคเอกชน นอกจากนี้ยังเป็นต้นแบบที่สามารถ Replicate ไปยังมหาวิทยาลัยอื่น โรงเรียน โรงพยาบาล หรืออาคารสำนักงานได้โดยง่าย เนื่องจากใช้เทคโนโลยี Open-source และมีต้นทุนต่ำ
เสริม
ให้คิดว่าถ้าโครงงานนี้ทำเสร็จสิ้นสมบูรณ์ไปแล้ว จะมีใครได้รับประโยชน์อะไรจากโครงงานนี้บ้าง ให้คิดในมุมมองว่าโครงงานนี้ได้ถูกเอาไปใช้งานเรียบร้อยแล้วด้วย
11. ความร่วมมือกับหน่วยงานอื่น
โครงงาน Smart Energy Insight มีศักยภาพในการสร้างความร่วมมือกับหน่วยงานทั้งภายในและภายนอกมหาวิทยาลัย เพื่อเพิ่มคุณค่าและความสำเร็จของโครงงาน
11.1 หน่วยงานภายในมหาวิทยาลัย
กองอาคารสถานที่และสิ่งแวดล้อม เป็นหน่วยงานหลักที่จะให้ความร่วมมือในการเข้าถึงพื้นที่ทดสอบ (อาคารเรียน ห้องปฏิบัติการ) การติดตั้ง IoT Sensor และการเชื่อมต่อกับระบบไฟฟ้าของอาคาร รวมถึงการให้ข้อมูลประวัติการใช้พลังงานย้อนหลังเพื่อใช้ในการ Train โมเดล AI
สาขาวิศวกรรมไฟฟ้าและวิศวกรรมคอมพิวเตอร์ สามารถให้คำปรึกษาเกี่ยวกับระบบไฟฟ้าของอาคาร มาตรฐานความปลอดภัย และการติดตั้ง Current Transformer อย่างถูกต้อง รวมถึงอาจมีนักศึกษาหรืออาจารย์ที่สนใจร่วมพัฒนาส่วน Hardware
ศูนย์คอมพิวเตอร์และเทคโนโลยีสารสนเทศ ให้การสนับสนุนด้านโครงสร้างพื้นฐานเครือข่าย การเชื่อมต่อ WiFi สำหรับ IoT Device และการจัดสรร Server สำหรับ Deploy ระบบ
11.2 หน่วยงานภายนอก
การไฟฟ้าส่วนภูมิภาค (กฟภ.) หรือการไฟฟ้านครหลวง (กฟน.) อาจให้การสนับสนุนข้อมูล Tariff Structure, Time-of-Use (TOU) Rate และคำแนะนำด้าน Demand Response Program ซึ่งจะช่วยให้ระบบ AI สามารถ Optimize การลดโหลดได้อย่างมีประสิทธิภาพ
กรมพัฒนาพลังงานทดแทนและอนุรักษ์พลังงาน (พพ.) เป็นหน่วยงานที่มีแนวนโยบายส่งเสริมการอนุรักษ์พลังงานในอาคาร อาจให้การสนับสนุนด้านข้อมูล เกณฑ์มาตรฐาน และอาจเป็นช่องทางในการเผยแพร่ผลงาน
บริษัทเอกชนด้าน IoT และ Smart Building เช่น KDDI Thailand, Delta Electronics, หรือ Startup ด้าน PropTech อาจเป็นพันธมิตรในการต่อยอดเชิงพาณิชย์หรือให้การสนับสนุนอุปกรณ์
เสริม
หากมีร่วมงานกับหน่วยงานอื่น ให้ระบุในส่วนนี้ให้เรียบร้อย หากไม่มีก็ให้ใส่หลักสูตรและมหาวิทยาลัยอย่างเดียวก็ได้
12. งบประมาณ
12.1 งบประมาณด้านฮาร์ดแวร์
| รายการ | จำนวน | ราคาต่อหน่วย (บาท) | รวม (บาท) |
|---|---|---|---|
| ESP32 Development Board | 5 | 350 | 1,750 |
| PZEM-004T v3.0 Energy Meter Module | 5 | 450 | 2,250 |
| Current Transformer (CT) 100A | 5 | 150 | 750 |
| DHT22 Temperature & Humidity Sensor | 5 | 120 | 600 |
| PIR Motion Sensor HC-SR501 | 5 | 50 | 250 |
| Relay Module 4-Channel 5V | 3 | 150 | 450 |
| Raspberry Pi 4 Model B 4GB (Edge Server) | 1 | 2,500 | 2,500 |
| MicroSD Card 64GB (สำหรับ Raspberry Pi) | 2 | 350 | 700 |
| Power Supply 5V 3A | 5 | 150 | 750 |
| Jumper Wires, Breadboard, Enclosure | 1 ชุด | 500 | 500 |
| รวมงบประมาณฮาร์ดแวร์ | 10,500 |
12.2 งบประมาณด้านซอฟต์แวร์และบริการ
| รายการ | ระยะเวลา | ราคา (บาท) |
|---|---|---|
| Domain Name (.com หรือ .th) | 1 ปี | 500 |
| Cloud Server (สำหรับ Backup/Demo) | 6 เดือน | 1,800 |
| LINE Notify API | ฟรี | 0 |
| InfluxDB, Mosquitto, Node.js, React.js | Open-source | 0 |
| TensorFlow/Keras, Python | Open-source | 0 |
| รวมงบประมาณซอฟต์แวร์ | 2,300 |
12.3 งบประมาณด้านอื่น ๆ
| รายการ | รายละเอียด | ราคา (บาท) |
|---|---|---|
| ค่าเอกสารและการพิมพ์ | รายงาน, Poster, เอกสารประกอบ | 1,500 |
| ค่าอุปกรณ์สำรอง | สำหรับกรณีอุปกรณ์เสียหาย (~15%) | 1,500 |
| ค่าใช้จ่ายเบ็ดเตล็ด | สายไฟ, อุปกรณ์ติดตั้ง, ค่าเดินทาง | 1,200 |
| รวมงบประมาณอื่น ๆ | 4,200 |
12.4 สรุปงบประมาณรวม
| หมวด | จำนวน (บาท) |
|---|---|
| ฮาร์ดแวร์ | 10,500 |
| ซอฟต์แวร์และบริการ | 2,300 |
| อื่น ๆ | 4,200 |
| รวมทั้งสิ้น | 17,000 |
เสริม
ให้ระบุออกมาเป็นหมวดหมู่ และลงรายละเอียดอย่างชัดเจน เพื่อให้รู้ว่าโครงงานนี้จะต้องใช้งบในการจัดซื้ออะไรบ้าง ใส่มาให้ครบถ้วน
13. การวัดและประเมินผล
การประเมินผลโครงงาน Smart Energy Insight จะดำเนินการทั้งเชิงปริมาณและเชิงคุณภาพ เพื่อให้ครอบคลุมทุกมิติของความสำเร็จ
13.1 การประเมินเชิงปริมาณ (Quantitative Evaluation)
13.1.1 ประสิทธิภาพของระบบ IoT และ Data Collection
| ตัวชี้วัด | วิธีการวัด | เกณฑ์ความสำเร็จ |
|---|---|---|
| Data Accuracy | เปรียบเทียบค่าที่วัดได้กับ Reference Meter | Error ≤ 5% |
| Data Completeness | คำนวณ % ของข้อมูลที่เก็บได้ต่อวัน | ≥ 95% |
| Response Time | วัดเวลาจาก Sensor ถึง Dashboard | ≤ 2 วินาที |
| System Uptime | คำนวณ % ของเวลาที่ระบบทำงาน | ≥ 99% |
13.1.2 ประสิทธิภาพของ AI Forecasting Model
| ตัวชี้วัด | วิธีการวัด | เกณฑ์ความสำเร็จ |
|---|---|---|
| Mean Absolute Error (MAE) | คำนวณค่า MAE ระหว่าง Predicted vs Actual | ≤ 10% ของค่าเฉลี่ย |
| Root Mean Square Error (RMSE) | คำนวณค่า RMSE | ≤ 15% ของค่าเฉลี่ย |
| R² Score (Coefficient of Determination) | คำนวณค่า R² | ≥ 0.90 |
| Mean Absolute Percentage Error (MAPE) | คำนวณค่า MAPE | ≤ 10% |
13.1.3 ผลลัพธ์ด้านการประหยัดพลังงาน
| ตัวชี้วัด | วิธีการวัด | เกณฑ์ความสำเร็จ |
|---|---|---|
| Energy Reduction (%) | เปรียบเทียบการใช้พลังงานก่อน-หลังติดตั้งระบบ | ≥ 20% |
| Cost Savings (บาท/เดือน) | คำนวณจากค่าไฟที่ประหยัดได้ | ≥ 10,000 บาท/เดือน (สำหรับอาคารขนาดกลาง) |
| CO₂ Reduction (kg/ปี) | คำนวณจากสูตร: kWh × 0.5 kg CO₂/kWh | ≥ 40,000 kg/ปี |
| Payback Period | คำนวณ: ต้นทุนระบบ ÷ ค่าไฟที่ประหยัด/เดือน | ≤ 3 เดือน |
13.1.4 ประสิทธิภาพของ Dashboard และ Control System
| ตัวชี้วัด | วิธีการวัด | เกณฑ์ความสำเร็จ |
|---|---|---|
| Page Load Time | วัดเวลา Load หน้า Dashboard | ≤ 3 วินาที |
| Control Command Success Rate | % ของคำสั่งควบคุมที่สำเร็จ | ≥ 98% |
| Alert Notification Latency | เวลาจากเกิด Event ถึงได้รับ Notification | ≤ 30 วินาที |
13.2 การประเมินเชิงคุณภาพ (Qualitative Evaluation)
13.2.1 ความพึงพอใจของผู้ใช้งาน
วิธีการ: จัดทำแบบสอบถาม (Questionnaire) และสัมภาษณ์ผู้ใช้งาน (เจ้าหน้าที่ดูแลอาคาร, อาจารย์, นักศึกษา) ภายหลังการใช้งานระบบอย่างน้อย 2 สัปดาห์
หัวข้อประเมิน:
- ความง่ายในการใช้งาน Dashboard (Usability)
- ความเข้าใจข้อมูลที่แสดง (Understandability)
- ความพึงพอใจต่อคำแนะนำของ AI (Recommendation Satisfaction)
- ความน่าเชื่อถือของระบบ (Reliability Perception)
- ความตั้งใจที่จะใช้งานต่อ (Intention to Continue Use)
เกณฑ์ความสำเร็จ: คะแนนความพึงพอใจเฉลี่ย ≥ 4.0 จาก 5.0 (Likert Scale)
13.2.2 การประเมินโดยผู้เชี่ยวชาญ
วิธีการ: เชิญผู้เชี่ยวชาญด้านวิศวกรรมคอมพิวเตอร์ วิศวกรรมไฟฟ้า และการจัดการพลังงาน มาประเมินระบบ
หัวข้อประเมิน:
- ความถูกต้องทางวิศวกรรมของสถาปัตยกรรมระบบ
- คุณภาพของ Code และ Documentation
- ความเหมาะสมของ AI Model ที่เลือกใช้
- ความเป็นไปได้ในการ Scale และ Replicate ไปยังอาคารอื่น
- ความปลอดภัยและความน่าเชื่อถือของระบบ
เกณฑ์ความสำเร็จ: ได้รับการประเมินในระดับ “ดี” หรือ “ดีมาก” ในทุกหัวข้อ
13.2.3 การประเมินความสมบูรณ์ของ Deliverables
วิธีการ: ตรวจสอบ Checklist ของ Deliverables ที่กำหนดไว้ในแผนการดำเนินงาน
Deliverables ที่ต้องส่งมอบ:
| Deliverable | เกณฑ์ความสำเร็จ |
|---|---|
| Source Code (Frontend, Backend, Firmware) | ครบถ้วน, มี Comments, ผ่าน Code Review |
| Trained AI Model (.h5 file) | Accuracy ≥ 90% บน Test Set |
| System Architecture Document | ครบถ้วน, ชัดเจน, มี Diagram |
| Installation Guide | สามารถติดตั้งตามได้ภายใน 2 ชั่วโมง |
| User Manual | ครอบคลุมทุก Features, มี Screenshots |
| Demo Video | 5-10 นาที, แสดงระบบทำงานครบถ้วน |
| Final Report | ≥ 60 หน้า, ครบทุกหัวข้อตาม Template |
13.3 กรอบเวลาการประเมิน
| ระยะ | สัปดาห์ | กิจกรรมการประเมิน |
|---|---|---|
| ระหว่างพัฒนา | 5, 8, 11 | Unit Testing, Integration Testing |
| ก่อนติดตั้งจริง | 12 | System Testing, Performance Benchmarking |
| หลังติดตั้งจริง | 14-15 | Field Testing, Data Collection |
| สิ้นสุดโครงงาน | 16-17 | User Satisfaction Survey, Expert Evaluation |
เสริม
แบ่งออกเป็นการวัดผลเชิงปริมาณ และ เชิงคุณภาพ ให้ศึกษาจากตัวอย่างได้เลย
