BMS แห่งอนาคต: ไม่ใช่แค่ตัวเลข แต่คือการจัดการที่ใช้ได้จริง

จักรพันธ์ ภวังคะรัตน์

Head of Property Management, JLL Thailand

เลขาธิการ สมาคมบริหารทรัพย์สินแห่งประเทศไทย

6 September 2025

Designing Building Management Systems from Real Operational Needs

บทนำ: ทำไม BMS ต้องเปลี่ยนมุมมอง

ระบบ Building Management System (BMS) เริ่มต้นขึ้นในยุค 1980–1990 เพื่อรวมระบบควบคุมต่าง ๆ ของอาคารเข้าไว้ด้วยกัน เช่น ระบบปรับอากาศ, ระบบไฟฟ้า, ระบบสุขาภิบาล, ระบบลิฟต์ ฯลฯ จุดประสงค์ดั้งเดิมคือ “ให้วิศวกรควบคุมอาคารจากศูนย์กลางได้สะดวก”

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

• วิเคราะห์การใช้พลังงาน

• คาดการณ์การซ่อมบำรุง

• แจ้งเตือนฉุกเฉินแบบ Real-time

• เชื่อมต่อกับระบบ IT และ IoT

• รองรับ Digital Twin และหุ่นยนต์บริการในอนาคต

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

ผลลัพธ์คือ BMS ที่มีข้อมูลเยอะเกินไปแต่ใช้ไม่ได้ประโยชน์, หน้าจอซับซ้อนจนวิศวกรงง, และไม่สามารถตอบโจทย์ด้านประสิทธิภาพพลังงานหรือความปลอดภัยได้จริง

ดังนั้น การออกแบบ BMS ที่ “ถูกบริบทอาคารจริง” จึงเป็นเรื่องจำเป็นอย่างยิ่ง หากเราต้องการให้อาคารเป็น Smart Building ที่ทำงานได้จริง ไม่ใช่แค่บนกระดาษ

1. ความเข้าใจผิดที่พบบ่อยของสเปค BMS แบบกลาง

1.1 เก็บข้อมูลทุกอย่าง แต่ไม่ได้ใช้

สเปคกลางมักระบุว่า “ต้องเก็บ datapoint ครอบคลุมทุกระบบ” ผลคือ datapoint หลักหมื่น แต่ทีม FM ใช้จริงไม่ถึง 10%

1.2 หน้าจอกราฟิกซับซ้อน

มีไอคอนเยอะ สีสันเต็มจอ แต่ไม่มีใครรู้ว่าต้องดูตรงไหน เวลามี Alarm เกิดขึ้นก็หาไม่เจอ

1.3 ไม่มีการแจ้งเตือนฉุกเฉิน

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

1.4 ไม่รองรับการ Remote

ในยุค Hybrid Work วิศวกรไม่จำเป็นต้องนั่งใน Control Room ตลอดเวลา แต่สเปคกลางดั้งเดิมไม่เคยระบุ Remote Web Access

1.5 Lock-in Vendor

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

2. Framework การออกแบบ BMS ให้ถูกบริบท

2.1 เริ่มจาก Use Case

• ออฟฟิศ: ต้องรู้พลังงานรายชั้น, อุณหภูมิ/ความชื้นตามโซน

• โรงพยาบาล: ต้องมอนิเตอร์ไฟฟ้าและ HVAC ในห้องผ่าตัด, ICU

• โรงงาน: ต้องเก็บข้อมูลสภาพแวดล้อมเพื่อ QA/Compliance

• ศูนย์การค้า: ต้องเห็นพลังงาน Anchor Tenant vs Specialty Shop

2.2 นิยาม KPI

• kWh/m² ต่อเดือน

• Chiller Plant Efficiency (kW/RT)

• Indoor Air Quality: CO₂, PM2.5

• Uptime ของระบบไฟฟ้า > 99.99%

2.3 กำหนด Datapoint ที่จำเป็น

• Chiller Plant: ΔT, kW/RT, Valve Position

• AHU: Supply/Return Air Temperature, Filter ΔP

• UPS: Battery Voltage, Runtime Remaining

• Lighting: kWh รายชั้น

2.4 Alarm Hierarchy

• P1 = วิกฤติ ต้องแจ้ง SMS/Push ภายใน 1 นาที

• P2 = สำคัญ ต้องแจ้งอีเมล/จอ

• P3 = ทั่วไป แสดงในจออย่างเดียว

2.5 Open Protocol & API

• Backbone รองรับ BACnet/Modbus/OPC UA

• เปิด API สำหรับ FMS/IoT/Digital Twin

3. Analytics และ Predictive Maintenance

BMS ที่ถูกบริบทต้องเป็น เครื่องมือคาดการณ์ ไม่ใช่แค่เครื่องมือเฝ้าดู

3.1 Monitoring

• แสดงค่าปัจจุบันของระบบหลัก

3.2 Charting

• เทียบค่า 2–3 ตัวพร้อมกัน เช่น Supply Temp vs Return Temp

3.3 Trending

• ดูย้อนหลัง 1 วัน, 1 สัปดาห์, 1 เดือน เพื่อเห็น pattern

3.4 Predictive

• ตัวอย่าง: ΔP across filter เพิ่มขึ้นเรื่อย ๆ → แจ้งเตือนให้เปลี่ยนฟิลเตอร์ภายใน 1 สัปดาห์

• ตัวอย่าง: ΔT Chiller ลดลงต่อเนื่อง → เตือนว่าประสิทธิภาพกำลังตก

3.5 Case Study

โรงพยาบาลเอกชน ใช้ Trend ΔP filter → เปลี่ยนเฉพาะตอนจำเป็น แทนที่จะเปลี่ยนตามรอบทุก 3 เดือน → ประหยัดค่าใช้จ่ายปีละ 15%

4. Alarm, Notification, Remote

4.1 Alarm Hierarchy

• ต้องแบ่งชัดเจนว่า Alarm ไหนต้องแจ้งทันที

• ลด False Alarm เพราะถ้ามีเยอะเกิน คนจะไม่สนใจ

4.2 Notification Channel

• SMS สำหรับ P1

• Mobile App Push สำหรับ P1/P2

• Email สำหรับ P2/P3

4.3 Remote Monitoring

• วิศวกรเข้าเว็บ BMS จากที่บ้านได้

• Vendor เข้ามาดู trend เพื่อเตรียมอะไหล่ก่อนเข้าซ่อม

4.4 Case Study

โรงงานอิเล็กทรอนิกส์ → Pump Failure Alarm ตอนตี 2 → SMS แจ้งหัวหน้าวิศวกร → เปิด Remote → สั่งปิด pump สำรองทันที → ป้องกันการผลิตหยุด

5. Open Protocols และ Data Integration

5.1 ปัญหา Lock-in

• Vendor ปิด protocol → ค่า service สูง

• อัพเกรดยาก

5.2 Open Protocol

• BACnet/Modbus/OPC UA = มาตรฐานเปิด

• ทำให้อาคารเลือกอุปกรณ์ข้ามแบรนด์ได้

5.3 Integration

• เชื่อมกับ FMS → สร้าง Work Order อัตโนมัติ

• เชื่อมกับ IoT → ใช้ Sensor เสริม เช่น Occupancy, IAQ

• เชื่อมกับ Digital Twin → ใช้ Simulation

5.4 Case Study

อาคารสำนักงานเกรดเอ ใช้ BACnet Backbone → สามารถติดตั้ง Smart Sensor ใหม่ภายหลัง โดยไม่ต้องเปลี่ยนระบบหลัก

6. Sub-metering และ Energy Transparency

6.1 ทำไมต้อง Sub-metering

• เพื่อ Energy Audit

• เพื่อ คำนวณค่าใช้จ่ายส่วนกลางอย่างโปร่งใส

• เพื่อ Tenant Engagement

6.2 หลักการออกแบบ

• จำแนกตาม โหลด: Chiller, Lighting, Plug Load

• จำแนกตาม พื้นที่: รายชั้น, รายโซน, รายผู้เช่า

6.3 Data Export

• อัตโนมัติ CSV/XLS

• ใช้กับ Excel, Power BI, หรือ Energy Dashboard

6.4 Case Study

ศูนย์การค้าแห่งหนึ่ง → ติด Sub-metering รายผู้เช่า → สามารถเจรจาค่าใช้จ่ายส่วนกลางได้อย่างโปร่งใส → ลดข้อร้องเรียน 80%

7. Design of Graphics / Single Pane of Glass

7.1 หลักการออกแบบหน้าจอ

• เริ่มจาก System Map → Floor → Equipment

• ใช้สีมาตรฐาน: เขียว = ปกติ, แดง = Fault

• Overlay Trend 3–4 ค่า

7.2 Single Pane of Glass

• Alarm → Trend → SOP → Work Order

• ลดเวลาแก้ปัญหาจาก 2 ชั่วโมง → 15 นาที

8. Acceptance Criteria / Test Script

8.1 FAT (Factory Acceptance Test)

• ทดสอบจุด datapoint ครบ

• Export CSV ได้

8.2 SAT (Site Acceptance Test)

• จำลอง Alarm → SMS แจ้งวิศวกร

• เปิด Remote ได้จริง

8.3 UAT (User Acceptance Test)

• ทีม FM ใช้งานจริงตาม Use Case

• ผ่านเมื่อวิศวกรยืนยันว่า “ใช้งานได้”

9. Case Studies

9.1 สำนักงาน

• เดิมใช้สเปคกลาง → datapoint 50,000 → ใช้จริงไม่ถึง 2,000

• หลังปรับเป็น “ถูกบริบท” → ลดเหลือ 10,000 datapoint → ใช้งานจริง 80%

9.2 โรงพยาบาล

• BMS monitor Generator, UPS, ICU AHU

• Alarm SMS → ลด downtime ห้องผ่าตัดเหลือ < 5 นาที

9.3 ศูนย์การค้า

• Sub-metering รายผู้เช่า

• Audit Energy → เจรจาค่าใช้จ่ายส่วนกลางได้ง่าย

9.4 โรงงาน

• Monitor ΔT, ΔP, Air Quality

• Predictive Maintenance → ลด downtime 25%

10. อนาคตของ BMS

10.1 AI & Predictive Analytics

• AI วิเคราะห์ Trend → เตือนล่วงหน้า

• ลด OPEX

10.2 Digital Twin

• BMS + BIM + IoT → เห็นอาคารเสมือน

• Simulation → คาดการณ์ก่อนปรับจริง

10.3 Robotics-Ready

• หุ่นยนต์ทำงานร่วมกับ BMS

• เช่น หุ่นยนต์ออกทำความสะอาดเมื่อโหลดไฟฟ้าต่ำ

10.4 Carbon Neutral

• BMS คุมพลังงาน → รายงานคาร์บอนฟุตพริ้นต์

• รองรับ ESG

11. Checklist 15 ข้อ

1. กำหนด Use Case ก่อนสเปค

2. นิยาม KPI ชัดเจน

3. ระบุ datapoint จำเป็น

4. ตั้ง Alarm Hierarchy

5. รองรับ SMS/Push

6. Remote Monitoring

7. Analytics ครบ

8. Export CSV/XLS อัตโนมัติ

9. Sub-metering ตามโหลด/พื้นที่

10. Open Protocol (BACnet/Modbus/OPC UA)

11. เปิด API สำหรับ FMS/IoT

12. Graphics เข้าใจง่าย

13. Single Pane of Glass

14. Acceptance Criteria ชัดเจน (FAT/SAT/UAT)

15. เตรียมต่อยอดสู่ AI/Digital Twin

สรุป: จากสเปคกลาง → BMS ที่ถูกบริบทจริง

การออกแบบ BMS ที่ถูกบริบทคือการเปลี่ยนวิธีคิดจาก “ทำตามสเปค” → “ออกแบบให้ใช้งานจริง” อาคารที่ทำได้จะมีระบบที่

• ใช้ข้อมูลเป็นประโยชน์จริง

• แจ้งเตือนและแก้ปัญหาได้ทันเวลา

• เปิดกว้างต่อการเชื่อมต่อในอนาคต

• ลดต้นทุน OPEX

• เพิ่มมูลค่าทรัพย์สิน

พูดได้ว่า BMS ที่ถูกบริบทอาคารจริง คือ กุญแจสู่ Smart FM และ Smart Building ที่แท้จริง ไม่ใช่แค่คำโฆษณา