ข้ามไปยังเนื้อหาหลัก

Software / AIoT TH Cloud

ดูข้อมูล ประวัติ และการแจ้งเตือนในที่เดียว

ระบบ Factory Monitoring พร้อม Dashboard ประวัติและแจ้งเตือน และงานเชื่อม SCADA, Factory Control และ OEE ตามขอบเขตโครงการ

ENERGY MONITORING / DEMO
หน้าจอ Demo พลังงาน แสดงกราฟการใช้ไฟและข้อมูลโรงงานจำลอง
ภาพหน้าจอ Demo จริง · ข้อมูลจำลอง เปิด Demo พลังงาน →

AIoT TH Cloud

รายละเอียดและขอบเขตการใช้งาน

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

ช่องทางใช้งาน
Web browser บนคอมพิวเตอร์ แท็บเล็ต และมือถือ
โครงสร้างข้อมูล
Organization → Site → Area → Asset และจุดวัดจาก Gateway
การแสดงผล
ค่าจุดวัด กราฟย้อนหลัง และสถานะการเชื่อมต่อ
การแจ้งเตือน
เกณฑ์ค่าที่ตั้งไว้และอุปกรณ์ขาดการติดต่อ พร้อมช่องทาง LINE และอีเมลตามการตั้งค่า
ผู้ใช้
กำหนดสิทธิ์ตามบทบาทภายในองค์กร
Subscription
เลือก Package รายเดือนต่อไซต์ ดูโควตาและเงื่อนไขล่าสุดในหน้าราคา

ทำงานกับข้อมูลอย่างไร

ลำดับการเตรียมระบบช่วยให้แดชบอร์ดมีความหมายตั้งแต่เริ่มใช้งาน

  • สร้างโครงสร้างไซต์และลงทะเบียน Gateway
  • ตั้งชื่อจุดวัด หน่วย และความสัมพันธ์กับเครื่องจักร
  • ตรวจสอบค่าที่รับได้เทียบกับอุปกรณ์ต้นทาง
  • จัดแดชบอร์ด กำหนดเกณฑ์แจ้งเตือน และผู้รับผิดชอบ

ข้อมูลย้อนหลังและ Package

ข้อมูลละเอียดมีระยะจัดเก็บ 30 วันตามข้อเสนอปัจจุบัน ส่วนข้อมูลสรุป ระยะจัดเก็บเพิ่มเติม และจำนวนจุดวัดขึ้นกับ Package ตรวจสอบเงื่อนไขในใบเสนอราคาก่อนเริ่มโครงการ

  • Lite, Standard, Professional และ Enterprise
  • เลือกตามจำนวน Gateway จุดวัด และความสามารถที่ต้องใช้
  • Demo ใช้ข้อมูลจำลอง เพื่อทดลองอ่านหน้าจอและรูปแบบข้อมูล

ความสามารถที่กำลังพัฒนา

API สำหรับระบบอื่น Advanced dashboards, Flows และ AI insights อยู่ในแผนพัฒนา ไม่ใช่ความสามารถที่เปิดให้ใช้ทั้งหมดในปัจจุบัน

  • ตัวอย่าง AI ใน Demo เป็นสถานการณ์จำลอง
  • การเชื่อม ERP/MES และระบบควบคุมต้องกำหนดขอบเขตโครงการ
  • ดูรายการความสามารถและสถานะในหน้าแพลตฟอร์ม

การใช้งานในโรงงาน

เริ่มจากปัญหาหน้างาน ไปสู่ระบบที่ใช้ได้จริง

ตัวอย่างแนวทางออกแบบระบบ พร้อมอุปกรณ์ ข้อมูล ผู้รับผิดชอบ และเงื่อนไขก่อนเริ่มโครงการ ไม่ใช่ผลลัพธ์จากลูกค้าจริง

DIGITAL TWIN · ข้อมูลจำลอง

digital twin จำลอง: พื้นที่ อุปกรณ์ และเหตุการณ์ในจอเดียว

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

ข้อมูลจำลอง · ไม่เชื่อมอุปกรณ์จริง
โรงงานและพลังงาน · 3D DIGITAL TWINลากเพื่อหมุน · เลื่อนหรือ pinch เพื่อซูม
กำลังเปิดผัง 3D…

สด (จำลอง) · 08:00:00

ผัง 3D จำลอง ไม่ใช่พิกัดจริง · ป้ายบนฉากแสดงค่าจาก digital twin จำลอง · เลือกอุปกรณ์บนฉากหรือจากโครงสร้าง twin

กำลังไฟฟ้ารวม62.0 kW
อุณหภูมิ M-0246.0 °C
การสั่นสะเทือน M-022.10 mm/s

WHAT-IF · จำลอง

เทียบแผนปัจจุบันกับทางเลือก · 30 นาทีจำลองข้างหน้า

แผนปัจจุบัน

M-01 ทำงาน

พลังงานใน 30 นาที
31.1 kWh
กำลังไฟฟ้าสูงสุด
64.7 kW

ทางเลือก

M-01 หยุด

พลังงานใน 30 นาที
17.4 kWh
กำลังไฟฟ้าสูงสุด
36.2 kW
กำลังไฟฟ้ารวม (kW)

คำนวณจากแบบจำลองในเบราว์เซอร์ เพื่อเทียบผลของการเลือก ไม่ใช่การพยากรณ์ของไซต์จริง

ประวัติการตรวจสอบและคำสั่ง

เลือกอุปกรณ์บนฉาก แล้วกดตรวจสอบหรือควบคุม

เส้นทางข้อมูล

PLC / Meter → Modbus TCP / RS485 → Gateway → MQTT TLS :8883 → Monitor

CCTV ใช้เครือข่าย IP ผ่าน PoE / NVR แยกจาก LoRaWAN; ภาพในฉากเป็นภาพประกอบ ไม่มีวิดีโอสด

สิ่งที่เจ้าหน้าที่เห็น

เชื่อมค่าพลังงานและสถานะเครื่องกับตำแหน่งหน้างาน เพื่อให้ช่างตรวจอุปกรณ์ที่เกี่ยวข้อง

ตัวอย่างการออกแบบระบบรู้ว่าโรงงานใช้พลังงานตรงไหน และช่วงใด
ภาพอ้างอิงการรวบรวมข้อมูลพลังงานจากหลายโรงงาน

ตัวอย่างระบบ: ตู้เมน + ไลน์ผลิต + ระบบลมอัด

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

สมมติโรงงานต้องการติดตามมิเตอร์ 3 จุด เริ่มจากดูค่าและประวัติของแต่ละจุดก่อน งานคำนวณต้นทุนหรือพลังงานต่อชิ้นต้องมีข้อมูลและสูตรที่ตกลงเพิ่ม ไม่ถือว่ารวมอัตโนมัติ

ปัญหาที่พบ และแนวทางแก้ไข

เห็นค่าไฟรวม แต่ระบุจุดใช้ไฟสูงไม่ได้

ทีมต้องไล่หาสาเหตุจากหลายตู้ และอาจเลือกแก้จุดที่ไม่ใช่ต้นเหตุ

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

จดมิเตอร์ด้วยมือคนละเวลาและคนละไฟล์

เทียบข้อมูลยาก และไม่รู้ว่าค่าที่ต่างกันเกิดจากช่วงเวลาหรือโหลดจริง

แนวทางแก้ไข · อ่านค่าจากมิเตอร์ที่รองรับผ่าน Gateway กำหนดชื่อ หน่วย และเวลาให้เป็นมาตรฐาน พร้อมตรวจค่ากับหน้าจอมิเตอร์

รู้ว่าโหลดผิดปกติเมื่อจบกะไปแล้ว

ทีมไม่มีข้อมูลช่วงเกิดเหตุเพื่อใช้ตัดสินใจว่าจะตรวจอุปกรณ์ใดก่อน

แนวทางแก้ไข · กำหนดเกณฑ์จากรูปแบบใช้งานของไซต์ ส่งการแจ้งเตือนตามขอบเขตที่เปิดใช้ และให้ผู้รับผิดชอบตรวจสอบหน้างาน

อุปกรณ์และส่วนประกอบ

  • มิเตอร์ที่รองรับ 3 จุด: เมน ไลน์ผลิต และคอมเพรสเซอร์
  • Industrial Gateway ที่มีพอร์ตตรงกับมิเตอร์ พร้อมไฟเลี้ยงและเครือข่าย
  • Cloud จัดจุดวัดตาม Site / Area / Asset
  • Dashboard ประวัติและการแจ้งเตือนตาม Package

ข้อมูลที่ใช้ติดตาม

  • กำลังไฟฟ้า kW และพลังงานสะสม kWh
  • แรงดัน กระแส และ Power factor หากมิเตอร์เปิดให้อ่าน
  • เวลาอัปเดตล่าสุดและสถานะการเชื่อมต่อ

เส้นทางข้อมูล

  1. มิเตอร์ไฟฟ้า
  2. RS485 / Ethernet
  3. Industrial Gateway
  4. AIoT TH Cloud
  5. Dashboard / แจ้งเตือน

กระบวนการทำงานและผู้รับผิดชอบ

  1. กำหนดขอบเขตวงจร

    วิศวกรไฟฟ้า

    เลือกจุดที่ต้องเทียบ ระบุว่ามิเตอร์ใดเป็นเมนหรือย่อย เพื่อไม่รวมพลังงานซ้ำ

  2. ตั้งค่าการอ่าน

    ผู้ดูแลอุปกรณ์

    ตรวจ register หน่วย CT ratio และรอบอ่านตามรุ่นมิเตอร์และการใช้งาน

  3. ตรวจค่าต้นทาง

    ผู้ติดตั้ง + ทีมโรงงาน

    เทียบค่าบน Dashboard กับมิเตอร์ในช่วงเวลาเดียวกัน และบันทึกข้อคลาดเคลื่อน

  4. ติดตามรูปแบบโหลด

    วิศวกรพลังงาน

    ดูค่าปัจจุบันและประวัติร่วมกับตารางเดินเครื่อง ไม่สรุปประสิทธิภาพจากยอดรวมอย่างเดียว

  5. ตรวจเหตุแจ้งเตือน

    ซ่อมบำรุง

    เมื่อได้รับแจ้ง ให้ตรวจอุปกรณ์และเงื่อนไขการผลิตก่อนตัดสินใจปรับการใช้งาน

  6. ทบทวนผลปรับปรุง

    หัวหน้าฝ่ายผลิต

    เปรียบเทียบช่วงที่มีบริบทใกล้กัน บันทึกสิ่งที่เปลี่ยนและข้อมูลที่ยังขาด

ช่วยโรงงานแต่ละฝ่ายอย่างไร

วิศวกรรมพลังงาน

ช่วยชี้ช่วงเวลาและพื้นที่ที่ควรสำรวจโหลดเพิ่มเติม

ซ่อมบำรุง

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

ฝ่ายผลิต

ใช้ข้อมูลประกอบการทบทวนการเปิดเครื่องและการเปลี่ยนกะ

ผู้บริหาร / วางแผนต้นทุน

มีข้อมูลวัดจริงประกอบข้อเสนอปรับปรุง โดยยืนยันสูตรต้นทุนแยกต่างหาก

เหมาะกับใครบ้าง

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

ตรวจรับอย่างไรว่าใช้งานได้

  • ค่าบน Dashboard ตรงกับหน่วยและสเกลของมิเตอร์
  • ตรวจพบข้อมูลค้างหรือขาด และอธิบายเวลาอ้างอิงได้
  • ผู้รับผิดชอบค้นประวัติเหตุการณ์และทดสอบรับแจ้งได้ตามขอบเขต
คุยรายละเอียดหน้างาน
ตัวอย่างการออกแบบระบบเห็นสถานะเครื่องจักร และมีข้อมูลย้อนดูตอนเกิดเหตุ
ภาพอ้างอิงการเชื่อมต่ออุปกรณ์อุตสาหกรรมกับ Gateway และระบบข้อมูล

ตัวอย่างระบบ: ไลน์บรรจุที่มีเครื่องจักรหลายสถานี

เชื่อมสัญญาณจาก PLC หรือเซ็นเซอร์ เพื่อให้ฝ่ายผลิตและซ่อมบำรุงเห็นข้อมูลชุดเดียวกัน ก่อนนำไปพัฒนาการวิเคราะห์ประสิทธิภาพ

ตัวอย่างสมมติใช้สถานีป้อน บรรจุ และแพ็ก ทีมเริ่มจากอ่าน Run / Fault และตัวนับที่ PLC เปิดให้เข้าถึง ไม่แก้ระบบควบคุมเดิมโดยอัตโนมัติ และไม่ใช้สถานะ Offline แทนเหตุเครื่องหยุด

ปัญหาที่พบ และแนวทางแก้ไข

ต้องเดินดูเครื่องเพื่อรู้ว่าเครื่องใดทำงานอยู่

หัวหน้ากะไม่เห็นภาพเดียวกันเมื่อดูแลหลายจุด

แนวทางแก้ไข · กำหนดสถานะที่ PLC เปิดให้อ่าน แล้วแสดงค่าตามเครื่องจักรพร้อมเวลาอัปเดต

ข้อมูลหยุดเครื่องมาจากการจำหรือบันทึกย้อนหลัง

ทีมเริ่มตรวจปัญหาโดยไม่มีเวลาและสัญญาณต้นทางประกอบ

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

ต้องการ OEE แต่มีเพียงสัญญาณ Run

คำนวณตัวเลขได้แต่ความหมายอาจไม่ตรงการผลิตจริง

แนวทางแก้ไข · แยกโครงการอ่านข้อมูลออกจากงานวิเคราะห์ กำหนดกะ จำนวนผลิต ชิ้นดี และ ideal cycle time ก่อนตกลงสูตร OEE

อุปกรณ์และส่วนประกอบ

  • PLC หรือเซ็นเซอร์ที่ให้สถานะตามที่ตกลง
  • Gateway พร้อม Ethernet / RS485 หรือ Digital input ที่ตรงกับสัญญาณ
  • Cloud จัด Asset แยกตามสถานี
  • Dashboard ดูค่าและประวัติร่วมกับทีมผลิตและซ่อมบำรุง

ข้อมูลที่ใช้ติดตาม

  • Run / Stop / Fault ตามนิยามที่ยืนยันกับผู้ดูแลเครื่อง
  • ตัวนับผลิต อุณหภูมิ หรือกระแสเฉพาะที่มีแหล่งข้อมูล
  • สถานะ Gateway และเวลาอัปเดต แยกจากสถานะเครื่อง

เส้นทางข้อมูล

  1. PLC / Sensor
  2. ค่าหรือสถานะที่อ่านได้
  3. Gateway
  4. Cloud แยกตาม Asset
  5. หน้าจอฝ่ายผลิต

กระบวนการทำงานและผู้รับผิดชอบ

  1. นิยามสถานะ

    ผลิต + ผู้ดูแล PLC

    ตกลงว่า Run, Stop และ Fault หมายถึงอะไร รวมถึงช่วงเปลี่ยนสินค้าและหยุดตามแผน

  2. จัดทำรายการสัญญาณ

    วิศวกร Automation

    ระบุ address ชนิดข้อมูล หน่วย และวิธีอ่านที่ไม่กระทบงานควบคุม

  3. ตรวจเหตุการณ์จริง

    ผู้ติดตั้ง + Operator

    เทียบสถานะบนหน้าจอกับการทำงานของเครื่องในช่วงทดสอบที่ตกลง

  4. ติดตามระหว่างกะ

    หัวหน้ากะ

    ดูสถานะและความสดของข้อมูล ใช้ประวัติช่วยเลือกช่วงที่ต้องตรวจสอบ

  5. หาสาเหตุหน้างาน

    ซ่อมบำรุง

    ตรวจเครื่องและบันทึกสาเหตุในกระบวนการของโรงงาน ไม่สรุปจากสัญญาณเดียว

  6. ทบทวนข้อมูลสำหรับวิเคราะห์

    วิศวกรรมการผลิต

    ยืนยันข้อมูลผลิต กะ และสูตรก่อนพัฒนารายงาน downtime หรือ OEE เพิ่มเติม

ช่วยโรงงานแต่ละฝ่ายอย่างไร

หัวหน้ากะ / ฝ่ายผลิต

เห็นค่าตามสถานีและมีเวลาอ้างอิงเมื่อประสานงาน

ซ่อมบำรุง

ใช้สัญญาณย้อนหลังประกอบการตรวจสาเหตุ แทนการเริ่มจากความทรงจำอย่างเดียว

วิศวกร Automation

มี point list และนิยามสัญญาณร่วมกันสำหรับดูแลและขยายระบบ

ผู้จัดการโรงงาน

เข้าใจว่าข้อมูลใดมีจริง และข้อมูลใดยังขาดก่อนลงทุนวิเคราะห์ประสิทธิภาพ

เหมาะกับใครบ้าง

  • โรงงานที่มี PLC หรือสัญญาณสถานะที่สามารถเปิดให้อ่านได้
  • ทีมผลิตและซ่อมบำรุงที่พร้อมตกลงนิยามสถานะร่วมกัน
  • ผู้ที่ต้องการเริ่มเก็บข้อมูลพื้นฐานก่อนทำ downtime หรือ OEE ตามขอบเขตเพิ่มเติม

ตรวจรับอย่างไรว่าใช้งานได้

  • สถานะบน Dashboard ตรงกับเครื่องในกรณีทดสอบ
  • แยกเครื่องหยุดออกจาก Gateway ขาดการเชื่อมต่อได้
  • มีรายการสัญญาณและนิยามที่ผู้ดูแลเครื่องยอมรับ
คุยรายละเอียดหน้างาน
ตัวอย่างการออกแบบระบบติดตามปั๊ม ถังน้ำ และจุดวัดที่กระจายอยู่หลายพื้นที่
ภาพอ้างอิงการติดตามระดับน้ำ อัตราการไหล และสถานะปั๊ม

ตัวอย่างระบบ: ถังพักน้ำและสถานีปั๊มของโรงงาน

ให้ทีมเห็นค่าล่าสุด เวลาอัปเดต และสถานะการเชื่อมต่อ ก่อนเลือกจุดที่ต้องเข้าตรวจหน้างาน

ตัวอย่างสมมติมีถังพักและสถานีปั๊มที่อยู่คนละจุด อุปกรณ์แบบสายอาจอ่านผ่าน Industrial Gateway ส่วนเซ็นเซอร์ LoRaWAN ต้องมี Gateway, Network Server และตัวแปล payload ที่รองรับ ก่อนส่งข้อมูลเข้าระบบที่ตกลง

ปัญหาที่พบ และแนวทางแก้ไข

ต้องเดินทางไปดูระดับน้ำหรือแรงดันทุกจุด

ใช้เวลาของผู้ดูแล และยังอาจพลาดเหตุการณ์ระหว่างรอบตรวจ

แนวทางแก้ไข · เลือกเซ็นเซอร์และช่องทางสื่อสารตามหน้างาน ส่งค่ามารวมตามสถานี พร้อมคงแผนตรวจอุปกรณ์จริง

ตัวเลขยังแสดงอยู่แม้อุปกรณ์ขาดการติดต่อ

ผู้ใช้เข้าใจผิดว่าค่าเก่าคือสถานะปัจจุบัน

แนวทางแก้ไข · แสดงเวลาอัปเดตและตรวจการขาดการเชื่อมต่อ แยกการแจ้งค่าผิดเกณฑ์ออกจากการไม่มีข้อมูล

ไม่รู้ว่าแจ้งเตือนแล้วใครต้องรับผิดชอบ

มีข้อมูลแต่ไม่มีขั้นตอนตรวจสอบและประสานงาน

แนวทางแก้ไข · กำหนดเจ้าของสถานี ผู้รับแจ้ง และวิธีตรวจสอบก่อนเริ่มใช้งาน แล้วทดสอบร่วมกับทีมจริง

อุปกรณ์และส่วนประกอบ

  • เซ็นเซอร์ระดับน้ำ แรงดัน หรืออัตราการไหลตามโจทย์
  • Gateway แบบสาย หรือชุด LoRaWAN ตามเครือข่ายเซ็นเซอร์
  • แหล่งจ่ายไฟ อุปกรณ์ติดตั้ง และ uplink ที่เหมาะกับไซต์
  • Cloud แยกสถานี พร้อมประวัติและการแจ้งเตือนตามขอบเขต

ข้อมูลที่ใช้ติดตาม

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

เส้นทางข้อมูล

  1. เซ็นเซอร์ / มิเตอร์
  2. แบบสาย หรือ LoRaWAN + Network Server
  3. เครือข่ายที่ไซต์รองรับ
  4. Cloud แยกสถานี
  5. ผู้ดูแลตรวจสถานะ

กระบวนการทำงานและผู้รับผิดชอบ

  1. สำรวจจุดติดตั้ง

    สาธารณูปโภค + IT

    ระบุสถานี ไฟเลี้ยง ระยะเข้าถึง ตำแหน่งเสา และข้อจำกัดสัญญาณ

  2. เชื่อมข้อมูลเซ็นเซอร์

    ผู้ติดตั้ง

    ตรวจพอร์ตหรือย่านความถี่ และแปลข้อมูลให้ตรงหน่วยก่อนเชื่อม Dashboard

  3. ทดสอบความต่อเนื่อง

    ทีมหน้างาน

    ทดสอบค่าจริง การขาดการเชื่อมต่อ และการกลับมาออนไลน์ตามแผนที่ปลอดภัยของไซต์

  4. ติดตามค่าและเวลา

    ผู้ดูแลสถานี

    อ่านค่าคู่กับเวลาอัปเดต ไม่ใช้ตัวเลขค้างเป็นข้อมูลสำหรับตัดสินใจทันที

  5. แจ้งและเข้าตรวจ

    ผู้รับผิดชอบเหตุการณ์

    ตรวจชนิดเหตุและประสานคนหน้างาน การสั่งปั๊มยังใช้ขั้นตอนควบคุมที่ได้รับอนุญาต

  6. ทบทวนการดูแลไซต์

    หัวหน้าสาธารณูปโภค

    ใช้ประวัติประกอบแผนตรวจและบำรุงรักษา พร้อมบันทึกปัญหาเครือข่ายหรืออุปกรณ์

ช่วยโรงงานแต่ละฝ่ายอย่างไร

สาธารณูปโภค

เห็นสถานีที่มีข้อมูลขาดหรือค่าที่ต้องตรวจสอบก่อนจัดลำดับงาน

ซ่อมบำรุง

มีค่าและเวลาอ้างอิงประกอบการเตรียมเข้าหน้างาน

IT / เครือข่าย

แยกปัญหาการรับข้อมูลออกจากปัญหา uplink และสิทธิ์เครือข่าย

ผู้ดูแลหลายไซต์

ใช้ชื่อสถานีและผู้รับผิดชอบร่วมกันในการสื่อสาร ไม่พึ่งคำบอกเล่าอย่างเดียว

เหมาะกับใครบ้าง

  • โรงงานที่มีถังน้ำ ปั๊ม หรือระบบสาธารณูปโภคหลายจุด
  • ไซต์ที่มีช่องทางส่งข้อมูลและสามารถจัดไฟเลี้ยงอย่างเหมาะสม
  • ทีมที่มีผู้รับผิดชอบรับแจ้งและเข้าตรวจได้ โดยไม่ใช้ Cloud แทนระบบควบคุมความปลอดภัย

ตรวจรับอย่างไรว่าใช้งานได้

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

รายละเอียดและแนวทางเลือก

จากค่าที่อ่านได้สู่ข้อมูลที่ใช้งานร่วมกัน

ตั้งโครงสร้างข้อมูลก่อนสร้าง Dashboard

กำหนด Site, Area และ Asset ให้สอดคล้องกับผู้รับผิดชอบจริง จุดวัดแต่ละจุดต้องมีชื่อและหน่วยที่สม่ำเสมอ การตั้งค่าเช่นนี้ช่วยให้ทีมอ่านกราฟจากหลายเครื่องจักรได้โดยไม่ต้องตีความชื่อใหม่ทุกครั้ง

  • แยกไซต์ตามการใช้งานและ Package
  • จัดกลุ่ม Asset ตามเครื่องจักรหรือวงจร
  • ตรวจหน่วย เวลา และแหล่งข้อมูลให้ตรงกัน

ออกแบบการแจ้งเตือนให้มีผู้รับผิดชอบ

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

  • กำหนดจุดวัดและช่วงค่าที่ต้องติดตาม
  • แยกเหตุการณ์ข้อมูลผิดปกติจากการขาดการเชื่อมต่อ
  • ทดสอบช่องทางแจ้งเตือนและสิทธิ์ของผู้รับ

อ่านขอบเขตระบบก่อนเปิดใช้งาน หรือนำตัวอย่างไปวางแผนโครงการของคุณ

คำถามเกี่ยวกับหน้านี้

ซอฟต์แวร์สั่งงานอุปกรณ์ได้หรือไม่

ขอบเขตระยะแรกเน้นอ่านและติดตามข้อมูล การสั่งงานอุปกรณ์ต้องตกลงการออกแบบและขอบเขตเพิ่มเติม ไม่ควรใช้ Dashboard แทนระบบควบคุมความปลอดภัยหน้างาน

หลายไซต์ใช้ Package เดียวกันหรือไม่

ไม่จำเป็น แต่ละไซต์เลือก Package ตามจำนวน Gateway จุดวัด และฟีเจอร์ที่ใช้ สิทธิ์ของไซต์หนึ่งไม่ขยายให้ข้อมูลของทุกไซต์โดยอัตโนมัติ

เลือก Hardware และ Software ให้ทำงานร่วมกัน

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