การย้ายระบบ Siemens PLC ในโรงงานไทยจาก S7-300 และ ET 200M ไปสู่ S7-1500 และ ET 200MP หรือรุ่นเป้าหมายอื่นที่ผ่านการตรวจสอบ ไม่ได้จบแค่การเปลี่ยนหมายเลขรุ่นของ CPU และ I/O โครงการต้องควบคุมช่วงหยุดผลิต ความปลอดภัยของเครื่องจักร การสื่อสารกับระบบอื่น ทรัพย์สินซอฟต์แวร์เดิม FAT/SAT แผนย้อนกลับระบบ ความพร้อมของทีมซ่อมบำรุง และ OT cybersecurity บทความนี้เรียงขั้นตอนตั้งแต่สำรวจหน้างาน กำหนดขอบเขต ย้ายโปรแกรม ไปจนถึงตรวจรับและส่งมอบ
เหตุใดการอัปเกรด Siemens PLC จึงไม่ใช่แค่เปลี่ยนฮาร์ดแวร์
ยิ่งเครื่องจักรที่ใช้ S7-300 ทำงานมานานและดูเสถียร ก็ยิ่งมีความรู้หน้างานที่ไม่อยู่ในแบบ เช่น ค่า timer ที่แก้ตอน commissioning ลำดับการกู้คืนที่ช่างใช้จริง วิธีใช้งานพิเศษบน HMI รูปแบบข้อมูลที่ระบบผลิตคาดหวัง หรือ interlock ที่เกิดเฉพาะตอนหยุดเครื่อง รายการวัสดุอย่างเดียวไม่สามารถอธิบายพฤติกรรมเหล่านี้ได้
บล็อกทางการของ Siemens อธิบายว่า มีการประกาศยุติการทำตลาดผลิตภัณฑ์ในกลุ่มระบบ S7-300 และ ET 200M เมื่อ 1 ตุลาคม 2023 และช่วงความพร้อมของอะไหล่ซึ่งโดยหลักกำหนดไว้ 10 ปี เริ่มนับจากประกาศดังกล่าว แต่อาจสิ้นสุดเร็วกว่านั้นเนื่องจากการขาดแคลนชิ้นส่วนอิเล็กทรอนิกส์ 1 ตุลาคม 2025 คือวันที่ยกเลิกรหัสรุ่น หลังจากนั้นอุปกรณ์จะอยู่ในสถานะอะไหล่ และอาจส่งซ่อมหรือแลกเปลี่ยนกับชิ้นส่วนที่เสียได้ตามเงื่อนไข โดยทั่วไปวงจรชีวิตผลิตภัณฑ์สิ้นสุด 10 ปีหลังประกาศยุติการทำตลาด ข้อมูลนี้ไม่ใช่การรับประกันการส่งมอบสำหรับทุกรหัสสั่งซื้อ ทุกประเทศ ทุกสถานะสต็อก หรือทุกวันที่ต้องการ สำหรับโครงการในไทย ควรยืนยัน MLFB/หมายเลขสั่งซื้อที่ถูกต้อง สถานะรุ่นทดแทน และวันที่ต้องการใช้งานกับ Siemens หรือช่องทางที่ได้รับอนุญาตก่อนล็อกแผนหยุดผลิต
ประกาศวงจรชีวิตไม่ได้หมายความว่าอุปกรณ์ติดตั้งเดิมจะหยุดทำงานในวันนั้น แต่เป็นข้อมูลให้โรงงานตัดสินใจล่วงหน้า ก่อนที่ความขัดข้องจะบังคับให้เปลี่ยนระบบแบบฉุกเฉิน การเก็บอะไหล่และการวางแผนย้ายระบบเป็นมาตรการคนละเรื่อง อะไหล่ไม่สามารถชดเชย source program ที่หายไปหรือความรู้กระบวนการที่สูญหาย และการเปลี่ยนระบบโดยไม่สำรวจให้ครบก็อาจทำให้ระบบใหม่ทำพฤติกรรมเดิมที่ถูกต้องไม่ได้
กำหนดวัตถุประสงค์ให้จบในประโยคเดียว
ตัวอย่างวัตถุประสงค์ที่ใช้ได้จริงคือ:
รักษาฟังก์ชันการผลิตและความปลอดภัยที่ได้รับอนุมัติของเครื่องเดิม พร้อมย้ายไปสู่ PLC, remote I/O และสภาพแวดล้อมวิศวกรรมที่บำรุงรักษาได้ โดยมีหลักฐานและเวลาเพียงพอที่จะตรวจรับระบบใหม่หรือกู้คืนระบบเดิมภายในช่วงหยุดที่ตกลงกัน
คำว่า “ทำให้ทันสมัย” กว้างเกินไป การเพิ่มกำลังผลิต ปรับหน้าจอ ทำมาตรฐานโปรแกรม หรือเพิ่มการเก็บข้อมูลอาจมีประโยชน์ แต่ควรแยกจากข้อกำหนดที่จำเป็นต่อการย้ายระบบ หาก conversion และ improvement อยู่ในรายการทดสอบเดียวกัน เมื่อมีปัญหาจะระบุได้ยากว่าเป็นการถ่ายทอดข้อกำหนดเดิมไม่ครบ หรือเป็นข้อผิดพลาดของฟังก์ชันใหม่
เริ่มโครงการอุปกรณ์เก่าด้วยสามมุมมอง: ของจริง ซอฟต์แวร์ และการปฏิบัติงาน
ก่อนขอราคาคงที่ ควรตกลงผลลัพธ์ของการสำรวจหน้างาน ภาพถ่ายอย่างเดียว ไฟล์ PLC อย่างเดียว หรือแบบไฟฟ้าอย่างเดียวไม่พอ ต้องเชื่อมอุปกรณ์จริง ทรัพย์สินซอฟต์แวร์ และวิธีทำงานด้วย equipment tag เดียวกัน พร้อมระบุว่าส่วนใดยืนยันแล้วและส่วนใดยังเป็นสมมติฐาน
สำรวจของจริง: ตามความสัมพันธ์ ไม่ใช่ดูเฉพาะป้ายในตู้
บันทึก CPU, power supply, rack, signal module, interface module, communication processor, terminal, slot สำรอง, grounding และระบบ 24 VDC ติดตาม ET 200M ที่อาจกระจายในตู้อื่นหรืออยู่ภายในส่วนเครื่องจักร ทำแผนที่ Profibus, PROFINET, Industrial Ethernet, serial link และ gateway ของผู้ผลิตรายอื่นไปจนถึงคู่สื่อสารจริง
จำนวน I/O ไม่ใช่แบบวิศวกรรมไฟฟ้า ต้องบันทึกแรงดันและ polarity การแยกวงจร diagnostics ชนิดสัญญาณ analog การ scaling และ resolution, thermocouple/RTD, pulse, high-speed counter, positioning, redundancy และข้อกำหนดพื้นที่อันตราย แม้มีรุ่นที่ทำหน้าที่แทนได้ แต่ความต่างของ front connector, terminal allocation, ความร้อน พื้นที่ และความยาวสายอาจทำให้ต้องแก้ตู้
| หัวข้อสำรวจ | หลักฐานขั้นต่ำที่ต้องเก็บ | การตัดสินใจที่รองรับ |
|---|---|---|
| PLC และ I/O | หมายเลขสั่งซื้อ FW slot สถานะ อะไหล่ | คงไว้ แปลง หรือออกแบบใหม่ |
| Network | node, media, address, คู่สื่อสาร, protocol, timing | คง gateway หรือย้ายแบบ native |
| ตู้และสาย | ขนาด แหล่งจ่าย grounding terminal สาย สภาพแวดล้อม | เปลี่ยนแผ่นติดตั้ง ใช้ adapter หรือเดินสายใหม่ |
| Drive/เครื่องมือวัด | drive, servo, instrument, parameter, tool | ความเข้ากันได้ด้านควบคุม สื่อสาร และกู้คืน |
| Safety | E-stop, guard, light curtain, safety PLC/relay, record | ขอบเขต safety ผู้มีอำนาจ และ revalidation |
สำรวจซอฟต์แวร์: พิสูจน์ว่ากู้คืนได้ ไม่ใช่เพียงมีไฟล์ backup
โฟลเดอร์บนคอมพิวเตอร์ซ่อมบำรุงอาจไม่ใช่ master ที่กู้คืนได้ ต้องตรวจว่า offline project ตรงกับ CPU ที่กำลังรัน และมี symbol, comment, library, source, user block, communication configuration, HMI project, recipe, drive parameter และข้อมูลควบคุม credential ครบหรือไม่ Protected block และ library ของบุคคลที่สามต้องตรวจทั้งสิทธิทางสัญญาและเงื่อนไขทางเทคนิคสำหรับการย้าย compile และบำรุงรักษา
ทดลองเปิดคอมพิวเตอร์วิศวกรรมเดิม และตรวจว่า OS, STEP 7, option package, adapter และ license ใช้งานได้ การเก็บไฟล์อย่างเดียวไม่ใช่ disaster recovery หากโรงงานเปิดหรือ download ไม่ได้ หน้าผลิตภัณฑ์ TIA Portal ปัจจุบันของ Siemens ระบุ V21 แต่ไม่ได้พิสูจน์ว่า V21 จะเปิด แปลง license หรือ commissioning ระบบ legacy ทุกแบบโดยอัตโนมัติ ต้องตรวจตาม CPU, module, FW, OS, license และ option เช่น Safety หรือ Drive พร้อมบันทึก toolchain ที่ใช้จริง
สำรวจการปฏิบัติงาน: เปลี่ยนความรู้หน้างานให้เป็นข้อกำหนดที่ทดสอบได้
สังเกตการ start/stop ปกติ การเปลี่ยนรุ่นงาน การกู้ alarm วัตถุดิบหมด ไฟกลับมา utility หาย การสื่อสารขาด และ sensor เสีย ถาม operator ว่ามีการกระทำใดที่หลีกเลี่ยง และถามช่างว่าดูอะไรเป็นอันดับแรกเมื่อเกิด alarm สำคัญ รวมถึงสิ่งที่ต้องยืนยันก่อน restart
อย่าใช้คำอธิบายจากคนเดียวเป็นข้อกำหนดสุดท้าย ควรเทียบกับโปรแกรม PLC, HMI, แบบไฟฟ้า, I/O และพฤติกรรมเครื่องจริง ความเห็นไม่ตรงกันไม่ใช่ความล้มเหลว แต่เป็นการพบความเสี่ยงก่อนเริ่ม shutdown บันทึกเป็นประเด็นเปิดพร้อมผู้รับผิดชอบและจุดเวลาตัดสินใจ

จาก S7-300 สู่ S7-1500: แยก conversion ออกจาก redesign
คู่มือ migration ทางการของ Siemens ให้ข้อมูลความต่างด้านฮาร์ดแวร์ ซอฟต์แวร์ และการแปลงโครงการ อย่างไรก็ตาม คู่มือนี้มีข้อความคาดการณ์ในอดีต รวมถึงข้อความที่อ้างช่วงเวลาก่อนปี 2020 ห้ามนำข้อความดังกล่าวมาใช้เป็นสถานะผลิตภัณฑ์ในปี 2026 ใช้คู่มือสำหรับแนวคิดทางเทคนิค แล้วตรวจวงจรชีวิต ความเข้ากันได้ และการสนับสนุนจากข้อมูลปัจจุบันและคู่มือของรุ่นที่เลือกจริง
ทำ hardware mapping ที่แสดงความต่าง ไม่ใช่ตารางทดแทนสองคอลัมน์
สำหรับ BOM เดิมแต่ละรายการ ให้บันทึกหน้าที่ รุ่นเป้าหมาย ความต่าง อุปกรณ์เพิ่ม หลักฐาน และผู้อนุมัติ ตาราง “รุ่นเก่า/รุ่นใหม่” อย่างเดียวจะทำให้แหล่งจ่าย terminal shield สาย protocol ขนาด และพฤติกรรม diagnostics หลุดไป เลือก CPU จากโปรแกรมจริง รอบการทำงาน ภาระสื่อสาร motion, safety และการขยายในอนาคต ไม่ใช่คำกล่าวทั่วไปว่า CPU ใหม่ “เร็วกว่า”
ET 200M ไป ET 200MP ก็เช่นกัน จำนวน channel เท่ากันไม่ใช่หลักฐานว่าเทียบเท่า การเก็บสาย field เดิม การใช้ชิ้นส่วน transition หรือเดินใหม่จาก terminal ทำให้ขั้นตอน shutdown และการบำรุงรักษาระยะยาวต่างกัน Adapter อาจลดงานหน้างานในกรณีที่เหมาะสม แต่ยังต้องประเมินการจัดหาในอนาคต พื้นที่ จุดต่อเพิ่ม และความเข้าใจของช่าง
| ด้าน | เน้น conversion เมื่อ | พิจารณา redesign เมื่อ |
|---|---|---|
| I/O | ต้องรักษาพฤติกรรมไฟฟ้าและจำกัดการเปลี่ยน | ต้องเปลี่ยนวิธีสัญญาณ diagnostics ตู้ หรือการขยาย |
| Communication | คู่สื่อสารหยุดไม่ได้และต้องใช้ bridge ชั่วคราว | ต้องยกเลิก media/protocol เดิมและรวมมาตรฐานบำรุงรักษา |
| Software | ต้องถ่ายทอด sequence ที่อนุมัติแบบติดตามได้ | standardization และ diagnostics เป็นข้อกำหนดใหม่ที่อนุมัติแล้ว |
| HMI | ต้องคง navigation และวิธีใช้งานเดิม | ต้องแก้หน้าจอ สิทธิ ประวัติ ภาษา และวงจรชีวิต terminal |
Compile ผ่าน ไม่ได้แปลว่าเจตนาของเครื่องเทียบเท่า
ตรวจ semantics ของ instruction, addressing, data type, initial value, retentivity, startup, timer/counter, indirect addressing, system function, diagnostics, communication block, interrupt และลำดับการประมวลผล วัด performance บน CPU เป้าหมายเมื่อมีผลต่อข้อกำหนด ห้ามใส่เปอร์เซ็นต์เพิ่มความเร็วที่ไม่มีหลักฐานใน business case
โปรแกรม legacy มักพึ่ง absolute address และ shared DB การเขียนใหม่ทั้งหมดให้เป็นโครงสร้าง optimized ของ S7-1500 อาจบำรุงรักษาง่ายขึ้น แต่ขยายพื้นที่การเปลี่ยนแปลง หากความเสี่ยง shutdown สูง ให้สร้าง baseline ที่รักษาพฤติกรรมเดิมก่อน และแยก refactoring/ฟังก์ชันใหม่เป็น branch ข้อกำหนด และ test scope คนละชุด
ทำ change ledger ที่คนอ่านได้ควบคู่กับ log ของ conversion tool เชื่อมฟังก์ชันที่ลบ instruction ที่แทน DB/tag ที่เปลี่ยน และ manual edit เข้ากับเหตุผลและการทดสอบ Ledger นี้ช่วยป้องกัน FAT ตกหล่นและใช้ฝึกทีมซ่อมบำรุงไทยได้
อย่าวางการสื่อสารไว้ท้ายโครงการดัดแปลงระบบควบคุม
PLC ที่รันได้ลำพังยังไม่ใช่เครื่องผลิต หากสื่อสารกับ HMI, SCADA, MES, PC, robot, drive, instrument หรือ controller อื่นไม่ได้ ตั้งแต่ต้นโครงการให้ทำ matrix ของคู่สื่อสาร ทิศทาง ข้อมูล timing พฤติกรรมเมื่อผิดปกติ และขอบเขตความรับผิดชอบ
สร้าง communication matrix
สำหรับแต่ละคู่ บันทึก protocol, media, IP/node, tag/data area, handshake, timeout, reconnect, time synchronization และ safe behavior เมื่อขาดการสื่อสาร หากระบบระดับบนอ่าน absolute address ของ PLC การปรับ DB จะกระทบนอกตู้ หากคง gateway ต้องระบุเจ้าของ configuration และวิธีกู้คืน
ตัดสินใจเรื่อง HMI เป็นขอบเขตแยก หากคง HMI เดิม ให้ทดสอบ driver, address, alarm, recipe และ user role กับ PLC ใหม่ หากเปลี่ยนพร้อมกัน ต้องควบคุมการเปลี่ยนงานของ operator ด้วย screen comparison, ภาษา, สิทธิ, history, input limit และการป้องกันกดผิด อ่านเพิ่มได้ใน คู่มือพัฒนาหน้าจอ HMI สำหรับโรงงานไทย
เลือก staged migration หรือ single outage จากข้อจำกัดของโรงงาน
Staged migration สร้างขอบเขตระหว่างระบบเก่ากับใหม่แล้วเปลี่ยนทีละส่วน ช่วยแบ่งความเสี่ยง shutdown แต่เพิ่ม conversion ชั่วคราว การดูแลสองระบบ และ boundary test ส่วน single outage ลดสถาปัตยกรรมชั่วคราว แต่รวมงานและการตรวจรับไว้ในช่วงเดียว ให้เลือกจากการแบ่งเครื่องได้หรือไม่ เวลาหยุด ความพร้อมวัสดุ rollback และอำนาจตรวจรับ ไม่ใช่จากความชอบทั่วไป

ให้ฟังก์ชัน Safety มีเส้นทางอนุมัติแยก
เมื่อเกี่ยวข้องกับ E-stop, guard door, light curtain, two-hand control หรือ safe speed/position ห้ามแก้ safety แบบ “พ่วง” ไปกับงาน PLC ทบทวน safety requirement, circuit, safety PLC/relay, machine risk assessment, validation record, กฎหมายและกฎโรงงาน ผู้มีคุณสมบัติและความรับผิดชอบชัดเจนต้องอนุมัติขอบเขตการเปลี่ยน
การผ่าน normal I/O check ไม่ใช่ safety validation ต้องติดตาม requirement, design, implementation, verification, validation และ change evidence หากมี safety program, license, signature หรือ protected access ให้เตรียม toolchain และผู้มีสิทธิก่อน shutdown
Rollback ต้องคงความปลอดภัยด้วย สายชั่วคราวหรือ jumper ต้องมีการอนุญาต ระบุชัด ตรวจอิสระ และยืนยันการถอดออก อย่าพึ่งการปิดอุปกรณ์แบบไม่เป็นทางการ “เพื่อทดลองเครื่อง” แต่กำหนด test mode และ risk control ที่อนุมัติในช่วงออกแบบ
รวม OT cybersecurity ไว้ในการย้าย Siemens PLC
PLC ใหม่ไม่ควรรับ flat network และ shared password เดิมมาทั้งหมด และไม่ควรนำมาตรการ IT มาใช้โดยไม่คิดถึง availability กับ safety ของการผลิต NIST SP 800-82 Rev. 3 ซึ่งเผยแพร่ใน กันยายน 2023 อธิบายการรักษาความมั่นคง OT ภายใต้ข้อกำหนดด้าน performance, reliability และ safety ส่วนภาพรวมสาธารณะของ ISA/IEC 62443 เน้นการดูแลตลอด lifecycle และความรับผิดชอบร่วมของ asset owner, supplier, integrator และ service provider
รายการ security ขั้นต่ำในข้อกำหนด migration
- อัปเดต asset register และ network drawing ก่อน/หลัง พร้อมปิดจุดต่อชั่วคราวหรือไม่มีผู้ดูแล
- กำหนดสิทธิตามบทบาทสำหรับ PLC, HMI, engineering station, gateway และ remote support
- บันทึก communication flow ที่อนุญาต และลด path/service ที่ไม่จำเป็น
- กำหนดขอบเขต backup ที่เก็บ ขั้นตอน restore การทดสอบ restore และการอนุมัติการเปลี่ยน
- มอบหมายผู้ประเมินประกาศช่องโหว่และ FW/software update จาก vendor
- ควบคุมตัวตน การอนุมัติ ช่วงเวลา บันทึก และการยกเลิก remote support
- เก็บ time synchronization, event, alarm และ change history เพื่อการสอบสวน
มาตรการต้องใช้งานได้จริงในโรงงาน บัญชีรายบุคคลที่ไม่มีวิธีกู้คืนยามกลางคืนยังไม่พอ ขณะที่ใช้ shared administrator ทุกวันก็ระบุตัวผู้เปลี่ยนไม่ได้ จึงต้องออกแบบ emergency elevation, การเก็บ credential และบันทึกการใช้
การอ้าง NIST หรือ ISA/IEC 62443 ไม่ได้ทำให้ “compliant” หรือ “certified” โดยอัตโนมัติ คำกล่าวดังกล่าวต้องมี scope, requirement, assessment method และ evidence จุดเริ่มที่ใช้ได้จริงคือบันทึกว่าโครงการรับข้อกำหนดใด และใครยอมรับ residual risk แต่ละรายการ
ขั้นตอนโครงการ PLC upgrade และ replacement
วางแผนตาม decision gate ไม่ใช่จำนวนวันมาตรฐาน ระยะเวลาขึ้นกับ source, communication, safety, งานตู้, วัสดุ, shutdown และการตรวจรับ ลำดับด้านล่างเป็นโครงสร้าง ไม่ใช่ระยะเวลามาตรฐาน
เริ่มโครงการและสำรวจ
กำหนดขอบเขตระหว่าง asset owner, production, maintenance, quality, safety, IT/OT, machine builder และ SI สำรวจของจริง ซอฟต์แวร์ และการทำงาน ใส่สิ่งที่ยังไม่รู้ใน risk register ยืนยันกฎ shutdown ช่วงห้ามหยุด และผู้อนุมัติ release การผลิต
Basic/detail design
จัดทำ target architecture, BOM, งานตู้, I/O, communication, safety scope, software strategy, HMI, security, test strategy และ rollback แยก equivalent behavior กับ improvement และเขียน acceptance criteria ก่อนเริ่ม implement
Offline implementation และ review
สร้าง hardware, PLC, HMI และ communication configuration เก็บ conversion log และหลักฐาน manual change ตรวจ warning, library, license และ FW combination ทบทวน state transition ของ sequence สำคัญกับเจตนาระบบเดิม
FAT
ใช้ I/O จริงเท่าที่เหมาะสม simulation, signal injection และ peer emulation ทดสอบ normal, abnormal และ recovery รายการที่พิสูจน์ใน FAT ไม่ได้ต้องเป็น SAT carry-over พร้อมเหตุผล การเตรียม และวิธีตัดสิน ไม่ใช่ถือว่าผ่าน
Site changeover และ SAT
ทำตามกฎโรงงาน เช่น lockout/tagout ดำเนินการ backup, labeling, removal, installation, electrical check ที่จำเป็น, power-up, I/O check, dry run, material run, quality confirmation และ production release ผ่าน gate ที่มีผู้อนุญาต
Stabilization และ handover
ปิดหรือยอมรับ open item อย่างเป็นทางการ ส่งมอบ source ที่ restore ได้ backup แบบ license credential control การอบรม อะไหล่ ช่องทาง support และ change management การที่เครื่องรันได้อย่างเดียวไม่พอหากไม่มี master และเอกสารที่อนุมัติ
เนื้อหาที่ต้องตรวจรับใน FAT/SAT
สร้าง test จาก machine requirement ไม่ใช่จากโครงสร้างโปรแกรมของผู้เขียน คำว่า “เช็ก I/O ทั้งหมด” หรือ “เช็ก Auto” ยังไม่ใช่เกณฑ์ objective แต่ละ test ควรมี prerequisite, action, expected result, evidence, authority, result และ deviation
| ด้านทดสอบ | หลักฐานที่เหมาะกับ FAT | หลักฐานจริงที่ต้องมีใน SAT |
|---|---|---|
| Hardware | configuration, FW, diagnostics, simulated I/O, panel wiring | ทุก field signal, polarity, range, terminal, environment |
| Sequence | state, interlock, timer, fault, recovery | response จริง การชน วัตถุดิบ และ utility |
| Communication | แลกข้อมูลกับ peer จริง/จำลอง | peer จริงทั้งหมด disconnect/reconnect ข้อมูลและเวลา |
| HMI | screen, role, limit, alarm, language | การมอง การใช้งาน ขั้นตอนหน้างาน และ terminal อื่น |
| Safety | pre-check ตาม safety plan ที่อนุมัติ | validation และ evidence ภายใต้ผู้มีอำนาจ safety |
| Maintenance | backup, diagnostics, review ขั้นตอนเปลี่ยน | ทีมท้องถิ่นสาธิต restore และ fault isolation |
ทดสอบ abnormal recovery ไม่ใช่ดูแค่ว่า alarm ขึ้น
เลือก sensor mismatch, link failure, power cycle, E-stop, blockage, drive fault หรือคำสั่งจากระบบบนหายตาม risk ของเครื่อง ตรวจการ detect, safe output, สาเหตุที่เข้าใจได้ การไม่ restart เองโดยไม่ตั้งใจ การ recover แบบควบคุม และการเก็บ record
ทำ acceptance basis ให้ลงนามได้ก่อน shutdown
คำว่า “เหมือนเดิม” จะโต้แย้งได้หากสภาพเดิมไม่เคยบันทึก Production, quality, maintenance, safety และ project authority ควรตกลงเงื่อนไข provisional run, conditional acceptance และ final acceptance หากต้องใช้หลักฐานคุณภาพ ให้กำหนดวิธีวัดและผู้ตัดสินที่ได้รับอนุมัติ
ทำ rollback ให้เป็น work package ที่ปฏิบัติได้
“ถ้ามีปัญหาก็ใส่ของเดิมกลับ” ไม่ใช่แผน ต้องพิสูจน์ว่าสายเดิมกลับได้ software/parameter เดิม download ได้ และตัดสินใจก่อนเวลาที่เหลือไม่พอกู้คืน
ชุด rollback
- CPU, I/O, communication unit, connector และสายเดิมที่ผ่านการตรวจใช้งาน
- Backup เวอร์ชันที่รันสำหรับ PLC, HMI, drive, gateway พร้อม tool environment ที่ใช้ได้
- รูปก่อนแก้ บันทึกสาย/terminal address และ parameter
- ขั้นตอน changeover/restore เครื่องมือ label และบันทึกตรวจอิสระ
- Decision gate ผู้ตัดสินที่ได้รับอนุญาต การสื่อสารกับ production และ restart test
- ระยะเก็บระบบเดิมและผู้อนุมัติการทิ้งหรือใช้ซ้ำ
กำหนด rollback gate โดยคำนวณย้อนจากช่วงหยุดที่โรงงานอนุญาต เวลาที่แน่นอนเป็นข้อมูลเฉพาะโครงการ ไม่ควรยืมตัวเลขชั่วโมงทั่วไปจากบทความ

ประเมินค่าใช้จ่ายและระยะเวลาด้วยตัวแปร ไม่ใช่ราคาเหมารวม
ไม่สามารถให้ราคาและเวลาหยุดมาตรฐานอย่างรับผิดชอบก่อนสำรวจ แยกค่าใช้จ่ายเป็น hardware, panel/wiring, software, communication, HMI, safety, test, site work, training, spares, logistics และ risk response แยก schedule เป็น design, procurement, implementation, FAT, shutdown preparation, SAT และ stabilization
| ตัวแปรประมาณการ | ช่องโครงการ | หลักฐานลดความไม่แน่นอน |
|---|---|---|
| ขอบเขตติดตั้ง | เครื่อง/ตู้/CPU/remote I/O/peer [กรอก] | survey register, รูป, แบบ |
| Software asset | source ตรงกัน comment protection library [กรอก] | online comparison, restore trial |
| Modification | terminal reuse, rewiring, panel, HMI [กรอก] | BOM, layout, wiring plan |
| Acceptance | FAT, SAT, safety, quality, communication, training [กรอก] | acceptance specification ที่อนุมัติ |
| Outage | window, release condition, rollback limit [กรอก] | production plan, runbook ที่อนุมัติ |
| เงื่อนไขไทย | กฎงาน ทางเข้า ภาษา permit logistics [กรอก] | กฎโรงงานและ local-owner review |
ราคาฮาร์ดแวร์ต่ำอาจถูกกลบด้วยงานเดินสายและ debug หน้างานมาก การใช้ transition component หรือ pre-test อาจลดความไม่แน่นอนในงานที่เหมาะสม ควรเทียบงานรวมจนถึงสภาพที่ผลิตยอมรับและ operational risk ที่เหลือ ไม่ใช่ใบราคาชิ้นส่วนอย่างเดียว ประโยชน์เชิงตัวเลขต้องมาจาก work breakdown และหลักฐานทดสอบของเครื่องนี้
การส่งมอบโปรแกรม PLC ในโรงงานไทย
โครงการมักเชื่อมผู้รับผิดชอบเครื่องจากญี่ปุ่น ฝ่ายผลิตและซ่อมบำรุงไทย ผู้ผลิตเครื่อง SI ท้องถิ่น และ IT ปัญหาใหญ่มักเป็นเจ้าของข้อมูลไม่ชัด ไม่ใช่ภาษาอย่างเดียว การประชุมสองภาษาไม่พอหาก alarm แบบ source comment ขั้นตอนซ่อม และ change request ไม่ใช้ baseline เดียวกัน
กำหนด handover package ใน specification
รวม editable source ของ PLC/HMI/drive/gateway, compiled deliverable, tool/version, license, credential-control method, BOM, drawing, network/I/O, communication matrix, FAT/SAT evidence, backup/restore, change history, spare และ training evidence
หาก protected software หรือ third-party IP ทำให้ส่ง source ทั้งหมดไม่ได้ ต้องกำหนดว่าซ่อมอะไรได้ ใครตอบ ภายใต้เงื่อนไขใด และมี escrow หรือ recovery route หรือไม่ อ่านหลักการ governance เพิ่มได้ใน คู่มือส่งมอบโปรแกรม PLC สำหรับโรงงานไทย
แยกการอบรม operator, diagnostics และ change control
Operator ต้องเข้าใจ display, alarm, เงื่อนไข recovery และการกระทำต้องห้าม ช่างต้องฝึก online diagnostics, เปลี่ยน module, backup, communication check และ fault isolation ผู้แก้โปรแกรมต้องรู้ request, review, test, version control และการทำ emergency change ให้เป็นทางการ
การอบรมเสร็จเมื่อผู้รับผิดชอบทำขั้นตอนที่อนุมัติและบันทึกได้ ไม่ใช่แค่เข้าห้องเรียน ปรับสื่อให้เข้ากับบทบาท escalation กะ และกฎโรงงานไทย สำหรับการว่าจ้างและทำมาตรฐานในภาพรวม ดู แนวทางพัฒนาซอฟต์แวร์ควบคุมเครื่องจักรในไทย
Checklist ก่อนสั่งซื้อ
- ยืนยันหมายเลขสั่งซื้อ FW และ as-built ของ S7-300/ET 200M จากของจริง
- เทียบ running CPU กับ offline source
- พิสูจน์ว่าเปิด legacy project และ download ได้เมื่อจำเป็นด้วย license ที่ใช้ได้
- ทำรายการคู่สื่อสาร HMI, SCADA, PC, drive, controller และ instrument ทุกตัว
- กำหนด safety boundary, authority และ revalidation
- แยก equivalent migration ออกจาก improvement
- ตรวจ BOM difference, ขนาด, supply, terminal, wiring และ environment
- แยกสิ่งที่ FAT พิสูจน์ได้กับ SAT-only
- กำหนด pass, conditional acceptance, rollback trigger และผู้มีอำนาจ
- ทดสอบ backup และ restore environment ทั้งเก่าและใหม่
- กำหนด OT asset, flow, account, remote access, log และ backup
- รวม permit, outage, ภาษา, training และ support escalation ของโรงงานไทย
- กำหนดเจ้าของ source, drawing, license, record และ spare
รูปแบบความล้มเหลวที่พบบ่อยใน PLC upgrade และ replacement
หลายปัญหาเริ่มจากสมมติฐานที่ยังไม่ยืนยัน มากกว่าความสามารถของ programmer ใบเสนอราคาระบุว่า “มี source” แต่เมื่อเริ่มงานจึงพบว่าไม่ตรงกับ running CPU มีคู่สื่อสารตกหล่นหนึ่งระบบและเพิ่งรู้ใน SAT ว่าระบบผลิตอ่านข้อมูลไม่ได้ หรือสำรวจป้ายในตู้ครบแต่ลืม ET 200M ในอีกอาคาร การเขียนโปรแกรมให้เร็วขึ้นแก้เงื่อนไขเหล่านี้ไม่ได้ ต้องแยก fact ที่ยืนยันแล้ว unknown และ assumption พร้อมกำหนดวิธีปรับ scope ราคา และ schedule เมื่อ assumption เปลี่ยน
คำว่า “เทียบเท่าระบบเดิม” มีความหมายต่างกันในแต่ละฝ่าย
Production อาจหมายถึง throughput วิธีใช้งาน และคุณภาพไม่เปลี่ยน Maintenance อาจหมายถึงตาม alarm ไปถึงสาเหตุและกู้คืนได้ Quality ต้องการการควบคุม parameter สำคัญและ record ส่วน Safety ต้องการ requirement และ validation evidence ดังนั้นให้แตกคำว่า equivalent เป็น acceptance requirement รายฝ่าย กำหนดว่าจะพิสูจน์ใน FAT หรือ SAT พร้อม evidence และ authority
แก้ของเก่าและใหม่พร้อมกันจนตาม change ไม่ได้
การจัด comment, tag, DB, HMI, communication และ sequence ใหม่พร้อม migration อาจทำให้ระบบดูดีขึ้น แต่หาสาเหตุ fault ยากขึ้น แบ่ง change เป็น mandatory compatibility, maintenance improvement, production improvement หรือ security treatment แล้วเชื่อม change ID กับ test แม้ทำใน outage เดียวกัน การแยก logical change set ช่วย diagnosis ใน FAT และ conditional acceptance
FAT กลายเป็นการสาธิต
การแสดงเฉพาะ normal operation ที่ผู้สร้างถนัด แล้วลองรายการที่ลูกค้านึกได้ในวันนั้นไม่ใช่ acceptance ควร review FAT specification ล่วงหน้ากับ machine requirement, change ledger, communication matrix, I/O, safety scope และ alarm สามารถเพิ่ม test ที่มีประโยชน์ได้ แต่ห้ามแทนรายการที่ตกลงไว้ และต้องแยก “fail” ออกจาก “ยังไม่ได้ทดสอบ”
สับสนระหว่าง changeover เสร็จกับ production release
Power-on และวิ่ง Auto หนึ่งรอบไม่ได้แปลว่าอนุญาตผลิตเสมอ อาจยังมี quality check, abnormal recovery, ส่งเวรกะ, backup, temporary change, enhanced monitoring และ support coverage ให้ใช้ gate แยกสำหรับ technical completion, conditional production และ final acceptance พร้อม open item และ owner ทุก gate
ย้ายอุปกรณ์ rollback ออกเร็วเกินไป
หากย้าย CPU และสายเดิมหลังเครื่องใหม่วิ่งได้ไม่นาน อาจกู้คืนไม่ได้เมื่อ defect เฉพาะเงื่อนไขปรากฏภายหลัง กำหนดระยะเก็บจาก acceptance coverage, representative production, quality approval และ open issue ไม่ใช่เวลาที่ผ่านไปอย่างเดียว ระบุและควบคุมของเดิมไม่ให้ถูกนำไปใช้เป็นอะไหล่เครื่องอื่น
| สัญญาณเตือน | คำถามที่ต้องถามเร็ว | เอกสารป้องกัน |
|---|---|---|
| Source ไม่แน่นอน | เทียบ online และ restore test แล้วหรือยัง | Software register, comparison record |
| คู่สื่อสารตกหล่น | ใครอนุมัติ peer ทิศทาง และ failure behavior ครบ | Communication matrix, network drawing |
| Change มากเกิน | แยก mandatory migration จาก improvement ได้หรือไม่ | Change ledger, requirement-test mapping |
| Acceptance ใช้ความรู้สึก | Expected result, evidence, authority ตกลงหรือยัง | FAT/SAT specification, deviation record |
| กู้คืนไม่ได้ | ใครพิสูจน์ขอบเขตการ restore ระบบเดิม | Rollback procedure, decision gate |
คำถามที่พบบ่อย
S7-300 จะหยุดทำงานหลัง 1 ตุลาคม 2025 หรือไม่?
ไม่ใช่ 1 ตุลาคม 2025 เป็นวันที่ยกเลิกรหัสรุ่น ไม่ได้หมายความว่าระบบติดตั้งจะหยุดในวันนั้น บล็อกทางการของ Siemens ระบุว่าประกาศยุติการทำตลาดเกิดขึ้นเมื่อ 1 ตุลาคม 2023 และช่วงความพร้อมของอะไหล่โดยหลัก 10 ปีเริ่มนับจากประกาศนั้น แต่อาจสิ้นสุดเร็วกว่าจากการขาดแคลนชิ้นส่วนอิเล็กทรอนิกส์ หลังวันที่ยกเลิกรหัสรุ่น อุปกรณ์จะอยู่ในสถานะอะไหล่ และอาจซ่อมหรือแลกเปลี่ยนได้ตามเงื่อนไข โดยทั่วไปวงจรชีวิตสิ้นสุด 10 ปีหลังประกาศยุติการทำตลาด ทั้งนี้ไม่รับประกันทุกรหัส ประเทศ สต็อก หรือเวลาส่งมอบ จึงต้องตรวจหมายเลขสั่งซื้อจริงและวางแผนทั้งอะไหล่กับ migration
แปลงโปรแกรมอัตโนมัติก็เพียงพอสำหรับ PLC update/replacement หรือไม่?
ไม่พอ การแปลงเป็นจุดเริ่ม ต้องตรวจ instruction, data, retention, startup, timing, communication, HMI, safety, diagnostics และ library แล้วทำ FAT/SAT ตาม requirement Compile ผ่านกับพฤติกรรมเทียบเท่าเป็นคนละข้อพิสูจน์
TIA Portal V21 รองรับ legacy project ทุกโครงการหรือไม่?
สรุปแบบนั้นไม่ได้ ความเข้ากันได้ขึ้นกับ CPU, module, FW, OS, license, option package และสภาพแวดล้อมเดิม ต้องตรวจข้อมูลทางการและทดสอบกับสำเนาที่ควบคุม
ควรทำมาตรฐานโปรแกรมทั้งหมดพร้อมดัดแปลงระบบควบคุมหรือไม่?
อาจช่วยบำรุงรักษา แต่เพิ่มพื้นที่การเปลี่ยน หาก shutdown จำกัด ให้ตั้ง baseline แบบ equivalent ก่อน และแยก standardization เป็น requirement/test อีกชุด หาก redesign ทั้งหมด ต้องมี requirement, acceptance และ rollback ของตัวเอง
ค่าใช้จ่ายและเวลาหยุดของการอัปเกรดอุปกรณ์เก่าเท่าไร?
ไม่มีตัวเลขเดียวที่รับผิดชอบได้ เพราะ I/O, communication, safety, source, งานตู้ วัสดุ test และเงื่อนไขหน้างานต่างกัน ต้องทำ survey, BOM, communication matrix, acceptance specification และ runbook แล้วประมาณแต่ละ work package
การทำให้ทีมไทยดูแลโปรแกรม PLC เองต้องมีอะไร?
ต้องมี editable master ที่ควบคุมได้ tool/license ที่ใช้งานได้ version control, backup/restore, เอกสาร diagnostics ที่เข้าใจได้ การอบรมตามบทบาท และ change approval ควรให้ทีมท้องถิ่นสาธิต diagnosis กับ restoration ใน acceptance
OT cybersecurity แยกเป็นสัญญาอื่นได้หรือไม่?
การประเมินโดยผู้เชี่ยวชาญอาจแยก scope ได้ แต่การออกแบบ migration ห้ามละเลย asset, flow, account, remote access, backup, log และ update governance ส่วนคำกล่าว compliance/certification ต้องมี scope และ evidence ชัดเจน
สรุป: ทำ Siemens PLC migration ให้เป็นโครงการ “ตรวจรับได้หรือกู้คืนได้”
การย้าย S7-300/ET 200M ในไทยควรเริ่มจากสำรวจของจริง ซอฟต์แวร์ และการทำงาน แล้วรวม hardware mapping, software ที่รักษาพฤติกรรม, communication, safety, OT security, FAT/SAT, training และ handover เป้าหมายไม่ใช่เลือกเพียงรุ่นใหม่ แต่คือรักษาฟังก์ชันที่อนุมัติ ติดตามทุกการเปลี่ยน ตัดสินด้วยหลักฐาน และกู้ระบบเดิมได้อย่างปลอดภัยหากไม่ผ่าน gate ที่ตกลง
TOMAS TECH สามารถช่วยได้ตั้งแต่ช่วงที่ยังไม่ชัดเจนเรื่องรุ่นจริง คุณภาพ source หรือขอบเขตตรวจรับ ตั้งแต่สำรวจโรงงานไทย วาง migration strategy, FAT/SAT และ handover เราจะตรวจสินทรัพย์และข้อกำหนดจริงก่อนกำหนดรุ่นทดแทน ปรึกษาการย้าย Siemens PLC
แหล่งข้อมูลทางการ
- Siemens Blog: วงจรชีวิต S7-300 และ ET 200M
- Siemens: Migration Guide SIMATIC S7-300 to S7-1500
- Siemens SCE Technical Support
- Siemens: TIA Portal
- Siemens: SIMATIC S7-1500 Controller
- NIST SP 800-82 Rev. 3
- ISA: ภาพรวม ISA/IEC 62443
บทความนี้เป็นแนวทางวางแผนทั่วไป ไม่ใช่การรับประกัน compatibility, machine-safety validation, standards certification, supply หรือ schedule โปรดยืนยันเอกสารปัจจุบันและเงื่อนไขหน้างานของอุปกรณ์จริง และรับการอนุมัติจากผู้มีคุณสมบัติและความรับผิดชอบ