APY PREMIUM GROUPโปรเจกต์ใหญ่ชิ้นแรกของ APY คืองานที่ไม่ได้อยู่ในโรงงานเดียว แต่กระจายอยู่กว่า 40 ไซต์ทั่วประเทศ — ระบบ SCADA สำหรับกรมการข้าว โดยมี เจริญโภคภัณฑ์วิศวกรรม (CPE) เป็นผู้รับเหมาหลัก และ APY รับผิดชอบงานระบบควบคุมและมอนิเตอร์ บทความนี้เล่าว่างานแบบ "หลายไซต์" ต่างจากงานโรงงานเดียวตรงไหน เราออกแบบอย่างไร และมีเช็กลิสต์อะไรที่โรงงานควรเตรียมก่อนเริ่มงานลักษณะนี้ (ขอสงวนรายละเอียดเชิงพาณิชย์และข้อมูลเฉพาะของลูกค้า)
ภาพรวมโปรเจกต์
| หัวข้อ | รายละเอียด |
|---|---|
| ลูกค้าปลายทาง | กรมการข้าว |
| ผู้รับเหมาหลัก | บริษัท เจริญโภคภัณฑ์วิศวกรรม จำกัด (CPE) |
| ปีที่ดำเนินการ | 2020 — โปรเจกต์ขนาดใหญ่โครงการแรกของ APY |
| ขอบเขต | ระบบ SCADA และมอนิเตอร์เครื่องจักรกว่า 40 ไซต์ กระจายทั่วประเทศ |
| แพลตฟอร์ม | AVEVA Wonderware (AVEVA Edge) ทำงานร่วมกับ PLC Mitsubishi |
| บทบาทของ APY | ออกแบบระบบ พัฒนาแอปพลิเคชัน SCADA ทดสอบ และ commissioning หน้างาน |
โจทย์: มอนิเตอร์สิ่งที่อยู่คนละจังหวัด
ในโรงงานเดียว ถ้าหน้าจอมีปัญหา วิศวกรเดินไปดูได้ใน 5 นาที แต่พองานกระจายเป็นหลายสิบไซต์ทั่วประเทศ ทุกอย่างเปลี่ยนสมการหมด — ค่าเดินทางกลายเป็นต้นทุนก้อนใหญ่ การแก้ปัญหาเล็กๆ หนึ่งครั้งอาจกินเวลาสองวัน และ "ความไม่เหมือนกัน" ของแต่ละไซต์คือศัตรูตัวจริง
สิ่งที่ทำให้งานหลายไซต์ยากไม่ใช่เทคโนโลยี SCADA แต่คือ การทำซ้ำให้ได้คุณภาพเท่ากันทุกที่ ภายในเวลาและงบที่จำกัด
งานโรงงานเดียว vs งานหลายไซต์ ต่างกันอย่างไร
| ประเด็น | โรงงานเดียว | หลายสิบไซต์ |
|---|---|---|
| การออกแบบหน้าจอ | ออกแบบเฉพาะหน้างาน ปรับหน้างานได้ | ต้องทำเป็น เทมเพลตมาตรฐาน แล้ว deploy ซ้ำ ไม่งั้นดูแลต่อไม่ไหว |
| การตั้งชื่อ Tag | ยืดหยุ่นได้ | ต้องมี naming convention ตายตัวตั้งแต่ไซต์แรก ไม่งั้นรายงานรวมทำไม่ได้ |
| เครือข่าย | LAN ภายในเสถียร | ต่างจังหวัด อินเทอร์เน็ตไม่แน่นอน ต้องออกแบบให้ ทำงานต่อได้เมื่อสายหลุด |
| การแก้ปัญหา | เดินไปดูได้ | ต้องมี remote access + log ที่อ่านรู้เรื่อง ไม่งั้นค่าเดินทางกินกำไร |
| การส่งมอบ | ทดสอบครั้งเดียว | ต้องมี ชุดทดสอบมาตรฐาน (commissioning checklist) ใช้ซ้ำทุกไซต์ |
| การอบรม | อบรมทีมเดียว | ผู้ใช้หลายสิบทีม ระดับความรู้ต่างกันมาก ต้องออกแบบให้ ใช้ง่ายโดยไม่ต้องอบรมนาน |
วิธีที่เราออกแบบ
1. สร้างเทมเพลตก่อน แล้วค่อยขยาย
เหตุผลหลักที่เลือกทำงานบน AVEVA Wonderware (AVEVA Edge) คือความคล่องตัวในการทำโปรเจกต์ต้นแบบแล้วนำไปใช้ซ้ำ — เราสร้างไลบรารีสัญลักษณ์และหน้าจอมาตรฐานของอุปกรณ์แต่ละชนิดไว้ชุดเดียว แล้วโคลนโปรเจกต์ต้นแบบไปยังไซต์ที่เหลือ โดยเปลี่ยนเฉพาะรายการแท็กและพารามิเตอร์เฉพาะไซต์ เมื่อต้องแก้ภายหลัง แก้ที่ต้นแบบแล้วกระจายลงไป แทนที่จะไล่แก้ทีละหน้าจอ 40 รอบ นี่คือความต่างระหว่างงานที่ดูแลต่อได้กับงานที่กลายเป็นภาระ
2. ล็อกมาตรฐานการตั้งชื่อและโครงสร้างข้อมูลตั้งแต่ไซต์แรก
ทุกจุดข้อมูลถูกตั้งชื่อตามรูปแบบเดียวกัน (ไซต์ / พื้นที่ / อุปกรณ์ / สัญญาณ) ทำให้ภายหลังสามารถดึงข้อมูลข้ามไซต์มาเปรียบเทียบได้โดยไม่ต้องเขียนโค้ดแปลงชื่อ — งานที่ข้ามขั้นตอนนี้มักจบด้วยการ "รื้อทำใหม่" ตอนลูกค้าขอรายงานภาพรวม
3. ออกแบบให้ไซต์ทำงานได้เองเมื่อสายหลุด
ระบบที่หน้างานต้องทำงานต่อได้แม้ลิงก์กับส่วนกลางขาด และเมื่อเชื่อมกลับได้ต้องส่งข้อมูลที่ค้างขึ้นไปให้ครบ การมองข้ามข้อนี้คือสาเหตุอันดับต้นๆ ที่ทำให้รายงานรวมของงานหลายไซต์ "มีรู"
4. ทำชุด commissioning ให้เหมือนกันทุกไซต์
เช็กลิสต์ทดสอบชุดเดียวกัน ฟอร์มส่งมอบชุดเดียวกัน รูปถ่ายหน้างานตามรายการเดียวกัน — ทำให้ทีมที่ไปคนละไซต์ส่งมอบได้คุณภาพใกล้เคียงกัน และเมื่อมีปัญหาย้อนกลับ ก็มีหลักฐานว่าตอนส่งมอบสภาพเป็นอย่างไร
เช็กลิสต์ 10 ข้อ ก่อนเริ่มโปรเจกต์ SCADA หลายไซต์
- รายชื่อไซต์และการจัดกลุ่ม — ไซต์ไหน "เหมือนกัน" และไซต์ไหนเป็นข้อยกเว้น จัดกลุ่มให้ชัดก่อนออกแบบ
- สำรวจหน้างานตัวอย่างอย่างน้อย 2–3 ไซต์ — เลือกไซต์ที่ใหญ่ที่สุดและเก่าที่สุด เพราะปัญหาจะโผล่ที่นั่น
- รูปถ่าย nameplate ของ PLC/อุปกรณ์ทุกไซต์ — ยี่ห้อ รุ่น เฟิร์มแวร์ พอร์ตสื่อสารที่มี
- นิยามจุดข้อมูลที่ "ต้องมี" จริงๆ — จำนวน Tag คือตัวคูณของทั้งไลเซนส์และชั่วโมงงาน
- มาตรฐานการตั้งชื่อ — ตกลงให้จบก่อนไซต์แรกเริ่มงาน
- เส้นทางเครือข่ายของแต่ละไซต์ — ใครดูแล ใครเปิดพอร์ตให้ นโยบายความปลอดภัยเป็นอย่างไร
- สิทธิ์การเข้าถึงระยะไกล — ตกลงกับฝ่าย IT ตั้งแต่ต้น ไม่ใช่ตอนระบบมีปัญหา
- ใครเป็นเจ้าของข้อมูลและเซิร์ฟเวอร์ส่วนกลาง — on-premise หรือ cloud นโยบายสำรองข้อมูลอย่างไร
- แผนอบรมและคู่มือ — หลายสิบทีม ต้องการเอกสารสั้น อ่านแล้วใช้ได้ทันที
- แผนขยายในอนาคต — จะเพิ่มไซต์อีกไหม บอกตั้งแต่แรกเพื่อออกแบบเผื่อ โดยไม่ต้องจ่ายเผื่อ
สิ่งที่เราได้จากโปรเจกต์นี้และใช้ต่อมาถึงวันนี้
งานนี้กลายเป็นรากฐานวิธีทำงานของ APY ในเวลาต่อมา — แนวคิดเทมเพลตมาตรฐาน การตั้งชื่อที่เป็นระบบ และชุดส่งมอบที่ทำซ้ำได้ ถูกนำไปใช้กับงานถัดๆ มา ทั้งงานในเครือ CP งานมอนิเตอร์โซลาร์ฟาร์มหลายสิบไซต์ และงาน Power Monitoring ในโรงงานอุตสาหกรรม
ถ้าโรงงานหรือองค์กรของคุณกำลังมองงานลักษณะนี้ — หลายอาคาร หลายสาขา หรือหลายจังหวัด — หัวใจไม่ได้อยู่ที่การเลือกซอฟต์แวร์ยี่ห้อไหน แต่อยู่ที่การออกแบบให้ ไซต์ที่ 40 ติดตั้งง่ายพอๆ กับไซต์ที่ 1 ดูรายละเอียดบริการได้ที่หน้า ระบบ SCADA & HMI และหน้า ระบบควบคุม PLC
สรุป
งาน SCADA หลายไซต์ไม่ใช่งานโรงงานเดียวคูณสี่สิบ แต่เป็นงานคนละประเภทที่ต้องคิดเรื่อง "การทำซ้ำ" ตั้งแต่บรรทัดแรกของการออกแบบ ทีมที่วางเทมเพลต มาตรฐานชื่อ และชุดส่งมอบไว้ดีตั้งแต่ต้น จะส่งมอบได้เร็วขึ้นเรื่อยๆ ตามจำนวนไซต์ ส่วนทีมที่เริ่มแบบ "ทำไปแก้ไป" จะช้าลงเรื่อยๆ — ความต่างนี้เห็นชัดที่สุดตอนไซต์ที่ 10 เป็นต้นไป