Home Solution(ถาม-ตอบ) โปรโตคอลสำหรับController/PLCสำคัญกับต้นทุนและการบำรุงรักษา

EDA International ตัวแทนจำหน่ายเป็นทางการ ICONICS, PRElectronics, M-System, Graphon, ABB

ซอร์ฟแวร์ตรวจสอบ/บริหารงานอุตสาหกรรม วิศวกรรม SCADA/HMI (ICONICS GENESIS32/64), Report Solution, Cloud, อุปกรณ์วัดคุม แสดงผล เทอร์มินัล อุปกรณ์ป้องกันทางอิเล็คทรอนิกส์ 

โปรโตคอลสำหรับController/PLCสำคัญกับต้นทุนและการบำรุงรักษา

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

 

1. ความยุ่งยากในการสื่อสาร

ต่างโปรโตคอลกันจะทำให้การสื่อสารระหว่างกันหรือเชื่อมต่อมายังSCADAมีความยุ่งยากมากขึ้น นึกถึงภาพOPC Serverถ้าต้องต่อกับPLC/Controllerหลากหลายโปรโตคอลก็ทำให้ต้องศึกษาวิธีการสื่อสารมากขึ้น ใช้การคอนฟิกหลายรูปแบบขึ้น การสื่อสารระหว่างControllerยิ่งทำไม่ได้หากไม่มีCommunication Moduleของโปรโตคอลนั้นๆ

2. งบประมาณบานปลาย

ต้องซื้อซอร์ฟแวร์เช่นOPC Server/Driverที่เข้ากันได้กับโปรโตคอลนั้น ๆ หลายชุด

3. บำรุงรักษายาก

ต้องมีรูปแบบการบำรุงรักษาหลากหลายขึ้น มีSpare partมากขึ้นเช่นCommunication Module, Signal Surge, ฯลฯ ต้องมีคู่มือของแต่ละโปรโตคอล ต้องทำความเข้าใจทั้งหมด

การป้องกัน/แก้ไข

หากต้องการลดความหลากหลายของโปรโตคอลมีแนวทางดังนี้

- เริ่มตั้งแต่การออกแบบให้เลือกอุปกรณ์ที่มีโปรโตคอลพื้นฐานและเปิดกว้างที่สุดเช่นModbus ซึ่งครอบคลุมในท้องตลาดมากที่สุุด กรณีPLCที่ไม่มีModbusมาให้ก็เลือกเป็นOptionเพิ่มได้

- ถ้าแก้ไขไม่ได้เพราะมีPLC/Controllerอยู่แล้ว และมีโปรโตคอลหลากหลายให้เลือกใช้Protocol ConverterหรือHMIที่รับโปรโตคอลได้หลากหลายแล้วเชื่อมต่อกับSCADAทีเดียว

- PLC/Controllerเก่าๆ หากเปลี่ยนได้ก็ทำการเปลี่ยนไปใช้โปรโตคอลที่เปิดกว้างและเราใช้งานอยู่ส่วนใหญ่ (หากไม่ใช่รุ่นCompactเล็กๆ มักจะสามารถซื้อOption cardโปรโตคอลที่ต้องการมาใส่ได้)

ทั้งนี้ขึ้นอยู่กับความต้องการและความสะดวกของการบริหารจัดการของเราเป็นหลัก หากเราพิจารณาแล้วว่าโปรโตคอลที่เราใช้งานอยู่ไม่หลากหลายเกินไป(คุมงบในการรักษา/พัฒนาได้?)และสามารถจัดการได้ มีแนวทางที่สามารถต่อกับSCADAได้อยู่แล้ว เราก็ไม่ต้องกังวลเรื่องดังกล่าวนี้ แต่ก็ควรพิจารณาการปรับเปลี่ยน รวมศูนย์ หรือต่อขยายระบบในอนาคด้วย

 

 

สิ่งที่น่าสนใจ

DS3 surge protection หลากหลายแบบ