Generative AI สำหรับเขียนโปรแกรม PLC | ขอบเขตงาน การตรวจสอบ และ RFP สำหรับโรงงานในไทย

บทนำ: เรื่อง 3 ข้อที่ควรกำหนดก่อนใช้ Generative AI กับโปรแกรม PLC

คำถามว่าจะใช้ Generative AI กับโปรแกรม PLC ได้หรือไม่ มีเข้ามามากขึ้นเรื่อย ๆ ไม่ว่าจะเป็นปัญหาอ่านโปรแกรมแลดเดอร์ (Ladder) ที่ผู้รับผิดชอบคนก่อนทิ้งไว้ไม่ออก คอมเมนต์ในโปรแกรมยังเป็นภาษาญี่ปุ่นจนช่างซ่อมบำรุงชาวไทยอ่านไม่ได้ หรือแม้เป็นงานแก้ไขดัดแปลงเล็ก ๆ ก็ต้องรอใบเสนอราคาและตารางงานจาก SI (System Integrator) ภายนอก ในช่วงปี 2024 ถึง 2026 ผู้ผลิต PLC และอุปกรณ์ FA รายหลักต่างทยอยประกาศฟังก์ชัน Generative AI ออกมา บางรายวางจำหน่ายแล้ว บางรายยังอยู่ระหว่างการพัฒนา

บทความนี้มองว่า สิ่งที่ควรกำหนดก่อนนำมาใช้ไม่ใช่ชื่อเครื่องมือ แต่เป็น 3 เรื่องต่อไปนี้

• (1) ขอบเขตงานที่ให้ AI ทำ (จะเริ่มจากงานใดระหว่างการเขียนโปรแกรมใหม่ การแก้ไขดัดแปลง การอ่านทำความเข้าใจโค้ดเดิมและใส่คอมเมนต์ การรีวิว การสร้างเทสต์ และการจัดทำเอกสาร)
• (2) ขั้นตอนการตรวจสอบผลลัพธ์ที่ AI สร้าง (การคอมไพล์ การตรวจแบบสแตติก การจำลองหรือ Virtual Commissioning การทดสอบ FAT และ SAT กับเครื่องจริง และการรีวิวและอนุมัติโดยคน)
• (3) ปลายทางของข้อมูลซอร์สโค้ดและข้อมูลเครื่องจักร (คลาวด์หรือภายในองค์กร ข้อมูลถูกนำไปใช้ฝึกโมเดลหรือไม่ และขัดกับสัญญารักษาความลับกับลูกค้าหรือไม่)

ผู้ผลิตรายหลักที่กล่าวถึงบทบาทของคน ล้วนอธิบายฟังก์ชันโดยมีเงื่อนไขว่าคนต้องยืนยันก่อนนำไปใช้ งานวิจัยก็มีรายงานว่า หากไม่ผนวกเครื่องมือตรวจสอบเข้าไป ก็ยากที่จะได้โปรแกรมที่ใช้งานได้จริงออกมา ในบทคัดย่ออย่างเป็นทางการและตัวบทของมาตรฐานที่เราตรวจดู ไม่พบข้อความที่กำหนดว่าโค้ดที่เขียนด้วย AI ใช้ได้หรือไม่ได้ ในขณะเดียวกัน ไม่ว่าผู้เขียนจะเป็นคนหรือ AI ก็ยังต้องทำให้ความผิดพลาดของลอจิกควบคุมไม่ก่อให้เกิดอันตราย และต้องมีการตรวจสอบการแก้ไขดัดแปลงและการควบคุมเวอร์ชัน ด้วยเหตุนี้ ความเห็นของกองบรรณาธิการบทความนี้คือ ให้เขียนขอบเขตงาน ขั้นตอนการตรวจสอบ และปลายทางของข้อมูลไว้ในกฎภายในบริษัทและ RFP แล้วยืนยันด้วย FAT และ SAT

บทความนี้ไม่ใช่การแนะนำหรือจัดอันดับผลิตภัณฑ์ใด ฟังก์ชันของผลิตภัณฑ์นำเสนอตามคำอธิบายของแต่ละบริษัท การคำนวณต้นทุนในช่วงท้ายเป็นตัวเลขสมมติที่ตั้งขึ้นสำหรับบทความนี้ พื้นฐานของ PLC และแลดเดอร์อธิบายไว้ใน “PLC คืออะไร กลไกพื้นฐานและวิธีเลือก” บทความนี้จึงเน้นเฉพาะสถานการณ์ที่ใช้ Generative AI

ทำไม Generative AI กับโปรแกรม PLC จึงเป็นที่พูดถึงในตอนนี้

เหตุผลคือ ผลิตภัณฑ์ของผู้ผลิตรายหลักทยอยเปิดตัวออกมาในช่วง 1 ถึง 2 ปีที่ผ่านมา ต่อไปนี้คือความเคลื่อนไหวหลักในขอบเขตที่ยืนยันได้ ณ วันที่ 15 ตุลาคม 2026

Siemens อธิบายว่าได้เปิดตัว “Eigen Engineering Agent” ที่งาน Hannover Messe เมื่อวันที่ 20 เมษายน 2026 และเริ่มจำหน่ายตั้งแต่วันเดียวกัน บริษัทระบุว่าการวางจำหน่ายนี้เกิดขึ้นหลังการทดลองนำร่อง (Pilot) กับบริษัทมากกว่า 100 แห่งใน 19 ประเทศ ชื่อผลิตภัณฑ์เปลี่ยนจาก “Industrial Copilot” เป็น “Engineering Copilot TIA” (Preview และเบตา) และปัจจุบันใช้ชื่อ Eigen Engineering Agent บริษัทอธิบายตัวเลขจากผลการทดลองนำร่องว่าประสิทธิภาพงานวิศวกรรมเพิ่มขึ้นสูงสุด 50% ตัวเลขนี้เป็นการรายงานของบริษัทเอง จึงนำไปเปรียบเทียบกับตัวเลขของบริษัทอื่นที่มีเงื่อนไขต่างกันไม่ได้

Rockwell Automation ประกาศขยายความร่วมมือกับ Microsoft เมื่อวันที่ 19 พฤศจิกายน 2024 และอธิบายในประกาศนั้นว่าได้เพิ่ม Copilot ซึ่งเป็น Generative AI เข้าไปในซอฟต์แวร์ออกแบบ FactoryTalk Design Studio หน้าผลิตภัณฑ์ปัจจุบันยังแนะนำ AI Plan & Build Agents และการจำลองบนคลาวด์ (Cloud Emulation) ด้วย

CODESYS Group อธิบายว่าให้บริการ “CODESYS Development System MCP Server” ซึ่งให้ระบบ AI สั่งงานสภาพแวดล้อมการพัฒนาได้ ในฐานะผลิตภัณฑ์แยกเดี่ยว ส่วน Beckhoff ประกาศว่าได้พัฒนา TwinCAT Chat ของปี 2023 ต่อยอดเป็น TwinCAT CoAgent ในเดือนเมษายน 2025 อย่างไรก็ตาม สถานะในหน้าผลิตภัณฑ์ TE1700 ระบุว่า “product announcement” และไม่พบข้อความที่แสดงว่าวางจำหน่ายทั่วไปแล้ว

สำหรับผู้ผลิตญี่ปุ่น Mitsubishi Electric นำเสนอ AI สร้างโปรแกรมแลดเดอร์ และ OMRON นำเสนอ “OMRON Automation Teams (ชื่อชั่วคราว)” ในงานแสดงสินค้า (IIFES 2025) และในการสัมภาษณ์ ทั้งสองรายการเป็นเนื้อหาที่อยู่ระหว่างการพัฒนาตามที่อธิบายในงานแสดงสินค้าและการสัมภาษณ์ และ ณ วันที่ 15 ตุลาคม 2026 ไม่พบการประกาศวางจำหน่าย สำหรับฟังก์ชัน Generative AI ของ KEYENCE ไม่พบการประกาศอย่างเป็นทางการ

ขอกล่าวถึงบริบทฝั่งไทยสั้น ๆ ตามข้อมูลของสำนักงานคณะกรรมการส่งเสริมการลงทุน (BOI) มูลค่าคำขอรับการส่งเสริมการลงทุนในปี 2025 อยู่ที่ 1.8766 ล้านล้านบาท (3,370 โครงการ) เพิ่มขึ้น 67% จากปีก่อน ตัวเลขนี้เป็นตัวเลขตามยอดคำขอ ไม่ใช่มูลค่าที่อนุมัติหรือมูลค่าการลงทุนจริง คำขอ FDI จากญี่ปุ่นอยู่ที่ 119,100 ล้านบาท 311 โครงการ นอกจากนี้ ตามคำอธิบายของสำนักงานกฎหมาย ประกาศ BOI ที่ 4/2569 (ประกาศในราชกิจจานุเบกษาเมื่อวันที่ 31 มีนาคม 2026) มุ่งส่งเสริมการลงทุนด้านระบบอัตโนมัติและหุ่นยนต์สำหรับการผลิตยานยนต์ (ประเภท 3.6 และ 3.8) ส่วนโรงงานชิ้นส่วนยานยนต์ ชิ้นส่วนอิเล็กทรอนิกส์ และอาหาร จะเข้าข่ายโดยตรงหรือไม่นั้น ไม่สามารถยืนยันได้จากเอกสารนี้ ด้านบุคลากร ศูนย์วิจัยกสิกรไทยประเมินว่าไทยต้องการแรงงานทักษะสูงประมาณ 1.1 ล้านคนในช่วงปี 2025 ถึง 2029 ขณะที่สัดส่วนผู้สำเร็จการศึกษาสาย STEM ลดลงจาก 23.2% ในปี 2020 เหลือ 22.3% ในปี 2025 บทความนี้มองว่า เบื้องหลังคือความต้องการเข้าใจโปรแกรมเดิมและแก้ไขดัดแปลงให้เร็วขึ้นแม้เพียงเล็กน้อย ในภาวะที่บุคลากรซึ่งเข้าใจระบบควบคุมมีจำกัด

สิ่งที่ Generative AI ทำได้กับโปรแกรม PLC: งาน 6 ประเภท

จากคำอธิบายของแต่ละบริษัท บทความนี้แบ่งงานด้านโปรแกรม PLC ที่ Generative AI เข้าไปเกี่ยวข้องออกเป็น 6 ประเภท การเลือกว่าจะเริ่มจากงานใดคือจุดตั้งต้นของกฎข้อ (1) ที่จะกล่าวต่อไป

ประเภทที่ 1 คือการเขียนโปรแกรมใหม่ Siemens ระบุในหน้าผลิตภัณฑ์ Eigen Engineering Agent ว่าสร้าง SCL และ LAD ได้ CODESYS อธิบายว่าสร้าง POU และโค้ด PLC ผ่าน MCP Server ได้

ประเภทที่ 2 คือการแก้ไขดัดแปลง Siemens ระบุการแก้ไขโค้ดเดิม ส่วน Mitsubishi Electric นำเสนอเดโมที่เมื่อป้อนแลดเดอร์เดิม คอมเมนต์ และคำสั่งแก้ไขดัดแปลง จะได้แลดเดอร์หลังแก้ไข คำอธิบาย และผังงาน (Flowchart) ออกมา (เป็นเนื้อหาที่อยู่ระหว่างการพัฒนา)

ประเภทที่ 3 คือการอ่านทำความเข้าใจโค้ดเดิมและใส่คอมเมนต์ Rockwell อธิบายว่า สำหรับโค้ดที่คนอื่นเขียน ผู้ใช้สามารถเลือก Rung, Routine, Program หรือทั้งโปรเจกต์ แล้วให้ Copilot แยกส่วนและอธิบายเนื้อหาได้ Siemens ก็ระบุการอธิบายลอจิกเก่า (Legacy Logic) และการใส่คอมเมนต์เป็นฟังก์ชัน CODESYS ก็ระบุการอธิบายโค้ดเดิมเช่นกัน

ประเภทที่ 4 คือการรีวิวและแก้ไขข้อผิดพลาด Siemens ระบุการแก้ไขข้อผิดพลาดจากการคอมไพล์และไวยากรณ์ และการตรวจตาม Style Guide ส่วน CODESYS ระบุการตรวจหาและแก้ไขข้อผิดพลาดในการเขียนโค้ด Copia Automation ระบุในหน้าผลิตภัณฑ์ Copia AI ว่ามีการเสนอแนะเพื่อปรับปรุงคุณภาพ

ประเภทที่ 5 คือการสร้างเทสต์ Siemens ระบุการสร้างลอจิกสำหรับทดสอบ Schneider Electric เขียนในบล็อกทางการว่า Copilot ใช้ไลบรารีที่ผ่านการตรวจสอบแล้วของบริษัทและ Guardrail หลายชั้นในการสร้าง อธิบาย และทดสอบโค้ด PLC

ประเภทที่ 6 คือการจัดทำเอกสารและการแปล Copia Automation ระบุการสร้างเอกสารของโค้ด PLC โดยอัตโนมัติ เช่น Routine คอมเมนต์ และภาพรวม Siemens ระบุการจัดทำเอกสารโปรเจกต์โดยอัตโนมัติ และการแปลข้อความใน PLC และ HMI สำหรับโรงงานที่ต้องการแปลคอมเมนต์ให้ช่างซ่อมบำรุงชาวไทย นี่น่าจะเป็นการใช้งานที่น่าสนใจมาก

นอกจากนี้ Schneider Electric อธิบายในบล็อกทางการว่าลดเวลาพัฒนาได้สูงสุด 30 ถึง 50% ตัวเลขนี้ก็เป็นคำอธิบายของบริษัท จึงนำไปเปรียบเทียบกับตัวเลขของบริษัทอื่นที่มีเงื่อนไขต่างกันไม่ได้

ความยากต่างกันระหว่างแลดเดอร์ (LD) กับ Structured Text (ST)

มีรายงานว่าความง่ายในการใช้ Generative AI แตกต่างกันตามภาษาของ PLC ก่อนอื่นขอยืนยันนิยามของภาษา สำหรับ IEC 61131-3 ฉบับที่ 4 ซึ่งออกเมื่อวันที่ 22 พฤษภาคม 2025 บทคัดย่ออย่างเป็นทางการของ IEC อธิบายว่ามาตรฐานนี้กำหนดไวยากรณ์และความหมายของกลุ่มภาษาที่ประกอบด้วยภาษาข้อความ ST และภาษากราฟิก LD และ FBD ส่วน SFC ถูกนิยามเป็นองค์ประกอบสำหรับจัดโครงสร้างภายในโปรแกรมหรือ Function Block การเปลี่ยนแปลงหลักของฉบับที่ 4 ที่ระบุไว้ ได้แก่ การเพิ่มสตริงแบบ UTF-8

ในงานวิจัย มีหลายบทความที่รายงานผลการสร้างโค้ดภาษาข้อความ ST บทความปี 2023 (งานวิจัยเชิงสำรวจโดยนักวิจัยของ ABB) ทดลอง Prompt 100 รายการใน 10 หมวดกับ GPT-4 และรายงานว่าในหลายกรณีได้ ST ที่ถูกต้องตามไวยากรณ์ อีกบทความหนึ่งในปี 2024 ระบุว่าปัญหาคือ ST ในข้อมูลฝึกที่เปิดเผยต่อสาธารณะมีน้อยและไวยากรณ์ซับซ้อน และรายงานว่าการฝึกโดยใช้ผลตอบกลับจากคอมไพเลอร์ทำให้อัตราการคอมไพล์ผ่านสูงขึ้น

ในทางกลับกัน แลดเดอร์ถือว่ายาก ภายใต้เงื่อนไขของบทความปี 2024 มีรายงานว่า เมื่อให้ตัวอย่างหลายตัว SFC ของข้อกำหนดง่าย ๆ สร้างได้ถูกต้อง แต่การสร้าง LD อัตโนมัติยังมีปัญหาแม้ในกรณีที่ง่ายมาก นักพัฒนาของ Mitsubishi Electric ก็กล่าวในการสัมภาษณ์ในทำนองว่า หากไม่ปรับแต่ง Prompt หรือไม่ใช้ลอจิกภายในของ GX Works3 แล้ว LLM ในปัจจุบันแทบจะสร้างโปรแกรมแลดเดอร์ไม่ได้เลย ในโครงสร้างที่อยู่ระหว่างการพัฒนาซึ่งบริษัทอธิบายในการสัมภาษณ์เดือนมีนาคม 2026 ใช้โมเดล GPT สำหรับแลดเดอร์ และโมเดล Claude สำหรับ ST อย่างไรก็ตาม ผู้ให้สัมภาษณ์เองก็กล่าวว่านี่เป็นโครงสร้างระหว่างการพัฒนา และอาจเปลี่ยนไปตามรูปแบบของบริการ จึงไม่ใช่สเปกของผลิตภัณฑ์

บทความวิจัยที่กล่าวถึงในที่นี้เป็นของปี 2023 ถึง 2025 และโมเดลที่ใช้ไม่ใช่โมเดลล่าสุดในปัจจุบัน ถึงอย่างนั้น บทความนี้มองว่าข้อมูลเหล่านี้ใช้เป็นเหตุผลประกอบแนวคิดได้ว่า ในโรงงานที่ใช้แลดเดอร์เป็นหลัก การเริ่มจาก “การอ่านทำความเข้าใจ” ง่ายกว่าการเริ่มจาก “การสร้าง”

ข้อจำกัดที่งานวิจัยชี้ และแนวคิดการผนวกการตรวจสอบเข้าไป

สิ่งที่งานวิจัยแสดงซ้ำ ๆ คือ ผลลัพธ์จะดีขึ้นเมื่อไม่ใช้ LLM เพียงลำพัง แต่ใช้ร่วมกับกลไกการตรวจสอบ

LLM4PLC (บทความปี 2024) เขียนว่า LLM ในขณะนั้น เช่น GPT-4 ไม่สามารถสร้างโปรแกรมที่ใช้งานได้สำหรับระบบควบคุมอุตสาหกรรม จึงเสนอกลไกแบบวนซ้ำที่ใช้เครื่องมือตรวจสอบภายนอก ได้แก่ ตัวตรวจไวยากรณ์ คอมไพเลอร์ และตัวตรวจสอบ SMV ร่วมกับผลตอบกลับจากผู้ใช้ ภายใต้เงื่อนไขของบทความปี 2024 (ใช้ชุดทดสอบการผลิตของ FischerTechnik และใช้ GPT-3.5, GPT-4, Code Llama เป็นต้น) รายงานว่าอัตราการสร้างสำเร็จเพิ่มจาก 47% เป็น 72% และคะแนนประเมินคุณภาพโค้ดโดยผู้เชี่ยวชาญเพิ่มจาก 2.25 เป็น 7.75 จากคะแนนเต็ม 10 ตัวเลข 72% เป็นกรณีที่ผนวกเครื่องมือตรวจสอบและผลตอบกลับเข้าไปแล้ว ไม่ใช่ประสิทธิภาพของ LLM เพียงลำพัง และอีกประมาณ 30% ยังล้มเหลว

Agents4PLC (บทความปี 2024) เป็นกลไกที่แบ่งงานการสร้าง การคอมไพล์ การตรวจสอบเชิงรูปนัย (Formal Verification) และการดีบักให้ LLM Agent หลายตัว เพื่อสร้างวงจรปิด (Closed Loop) โดยใช้ nuXmv และ PLCverif ในการตรวจสอบเชิงรูปนัย บทความเองเขียนไว้ว่าโค้ดที่สร้างด้วย LLM มีความไม่แน่นอนสูง บางครั้งคอมไพล์ไม่ผ่านหรือไม่เป็นไปตามข้อกำหนด และยังระบุเป็นปัญหาด้วยว่าการนิยามข้อกำหนดเชิงรูปนัยเองก็เป็นเรื่องยากสำหรับผู้ใช้

Spec2Control (บทความปี 2025 โดยนักวิจัยของ ABB) สร้างลอจิกควบคุมแบบกราฟิกของระบบควบคุมกระบวนการ (DCS) จากข้อกำหนดที่เขียนเป็นภาษาธรรมชาติ และภายใต้เงื่อนไขของบทความปี 2025 รายงานว่าสร้างการเชื่อมต่อของกลยุทธ์ควบคุมได้ถูกต้อง 98.6% นี่คือผลสำหรับ DCS จึงไม่ใช่ตัวเลขที่นำไปใช้กับแลดเดอร์ของ PLC แบบ Discrete ในโรงงานได้โดยตรง

Fraunhofer IKS ของเยอรมนีอธิบายว่า ในโครงการวิจัยระยะ 3 ปีที่เริ่มในเดือนมกราคม 2025 กำลังสร้างเกณฑ์มาตรฐาน (Benchmark) สำหรับวัดความน่าเชื่อถือของโค้ดควบคุมที่ AI สร้าง โดยประเมินโค้ด ST ที่สร้างขึ้นใน 3 ขั้น ได้แก่ การวิเคราะห์แบบสแตติก Unit Test ที่ AI สร้างจากข้อกำหนด และการจำลองด้วย Soft PLC ร่วมกับ Digital Twin ของเครื่องจักร สถาบันยังชี้ว่า เนื่องจากโค้ดอุตสาหกรรมจำนวนมากเป็นทรัพย์สินทางปัญญาของบริษัท จึงยังขาด Benchmark สำหรับ ST

เมื่อแปลงเรื่องเหล่านี้เป็นงานจริงในโรงงาน ก็จะได้ลำดับดังนี้ คือ ยืนยันผลลัพธ์ที่ AI สร้างตามลำดับว่า “คอมไพล์ผ่านหรือไม่” “เป็นไปตามกฎที่กำหนดหรือไม่” “ทำงานตามเจตนาในการทดสอบหรือไม่” “ทำงานร่วมกับเครื่องจักรในการจำลองได้หรือไม่” และ “คนอ่านแล้วอธิบายได้หรือไม่” จากนั้นจึงไปสู่ FAT และ SAT กับเครื่องจริง บทความนี้เรียกลำดับนี้ว่า Verification Pipeline (สายการตรวจสอบ)

สถานะการให้บริการของผู้ผลิตรายหลัก และฟังก์ชันที่แต่ละบริษัทอธิบาย

ตารางต่อไปนี้สรุปสถานะของผู้ผลิตรายหลัก โดยเรียงชื่อผู้ผลิตตามลำดับตัวอักษร ไม่ได้แสดงความเหนือกว่าหรือการแนะนำ สถานะการให้บริการเป็นขอบเขตที่ยืนยันได้ ณ วันที่ 15 ตุลาคม 2026 ช่องที่ยืนยันไม่ได้ระบุว่า “ไม่พบในเอกสารทางการ”

ข้อควรระวังในการอ่านตารางมี 3 ข้อ

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

ข้อที่สอง อย่านำการจัดการข้อมูลของบริษัทหนึ่งไปใช้กับบริษัทอื่น ข้อความ “ไม่ใช้ฝึกโมเดล” และ “เก็บไว้ในเครื่อง” เป็นข้อความในเอกสารทางการของ Siemens Eigen นอกจากนี้ “ไม่เก็บไว้บนคลาวด์” ไม่ได้มีความหมายเดียวกับ “ไม่ประมวลผลบนคลาวด์” Siemens อธิบายว่ารุ่น Preview ซึ่งเป็นรุ่นก่อนหน้า มีโครงสร้างที่ใช้ Microservice และ LLM บนคลาวด์

ข้อที่สาม คำอธิบายของทุกบริษัทที่กล่าวถึงบทบาทของคน ล้วนมีเงื่อนไขว่าคนต้องยืนยัน Schneider Electric เขียนในบล็อกทางการว่า “ไม่ใช่การเขียนโค้ดด้วย AI แบบทำงานเองโดยอิสระ (Autonomous) แต่เป็นเวิร์กโฟลว์ที่ AI ช่วยโดยคนยังคงควบคุม” Rockwell อธิบายว่าวิศวกรจะรีวิวและแก้ไขข้อเสนอก่อนนำไปใช้ ข้อกำหนดการใช้งานของรุ่น Preview ของ Siemens ระบุชัดว่าไม่ได้ตั้งใจให้นำเนื้อหาที่สร้างขึ้นไปใช้ในการผลิตจริง สำหรับ Eigen รุ่นผลิตภัณฑ์ บริษัทก็อธิบายว่าจะตรวจสอบตัวเองซ้ำจนถึงสถานะที่พร้อมให้รีวิว ผลลัพธ์จึงมีเงื่อนไขว่าต้องผ่านการรีวิวโดยคน นักพัฒนาของ Mitsubishi Electric กล่าวในทำนองว่า ไม่ได้คาดการณ์การใช้งานแบบเขียนคำตอบของ Generative AI ลงเครื่องจักรโดยไม่ยืนยันก่อน OMRON กล่าวในการสัมภาษณ์ว่า “AI เกิดอาการหลอน (Hallucination) จึงไม่สามารถให้ผลลัพธ์ที่ถูกต้อง 100% ได้ในทางเทคนิค”

กฎข้อ (1): กำหนดขอบเขตงานที่ให้ AI ทำ

กฎข้อแรกคือ จะให้ AI ทำงานใด เมื่อจัดระเบียบความง่ายในการเริ่มและน้ำหนักของการตรวจสอบตามงาน 6 ประเภท จะได้ดังตารางต่อไปนี้ นี่คือแนวคิดของบทความนี้ที่อิงจากคำอธิบายของแต่ละบริษัทและงานวิจัย ไม่ใช่การประเมินเชิงตัวเลข

บทความนี้มองว่า ก้าวแรกที่เริ่มได้ง่ายคือ “การอ่านทำความเข้าใจโปรแกรมเดิมและใส่คอมเมนต์” ด้วยเหตุผล 3 ข้อ

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

ข้อที่สอง มีความต้องการสูง Mitsubishi Electric อธิบายว่า หลังงาน IIFES 2025 ได้เริ่มพัฒนาฟังก์ชัน “สร้างคำอธิบาย” สำหรับแลดเดอร์และ ST ด้วย โดยให้เหตุผลว่ายอมรับได้ง่ายกว่าการสร้างโปรแกรมซึ่งรับประกันความน่าเชื่อถือได้ยาก OMRON กล่าวในการสัมภาษณ์ว่า จากการสำรวจของบริษัท การนำทรัพย์สินโปรแกรมเดิมกลับมาใช้มีตั้งแต่ 80% ขึ้นไปของกรณีทั้งหมด และนำเสนอฟังก์ชันที่ค้นหาแลดเดอร์เดิมแล้วให้ AI อธิบาย (ทั้งหมดนี้เป็นการสำรวจและคำอธิบายของบริษัท ไม่ใช่สถิติของอุตสาหกรรม) Rockwell และ Siemens ก็ระบุฟังก์ชันอธิบายโค้ดเดิมในผลิตภัณฑ์ที่วางจำหน่ายแล้ว

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

สำหรับวงจรที่เกี่ยวกับความปลอดภัย ก็มีทางเลือกที่จะกันไว้นอกขอบเขตงานที่ให้ AI ทำในระยะนี้ การจัดการเรื่องความปลอดภัยจะกล่าวโดยละเอียดในบทหลังของบทความนี้

ขั้นตอนการยืนยันในสถานการณ์ที่ต้องรับช่วงโปรแกรมจากผู้รับผิดชอบคนก่อน จัดระเบียบไว้ใน “การรับช่วงโปรแกรม PLC ของ Mitsubishi” แม้จะใช้ Generative AI เร่งการอ่านทำความเข้าใจ หลักพื้นฐานของการรับช่วงงาน เช่น การสำรองข้อมูล (Backup) และการยืนยันว่าเครื่องจริงกับซอร์สโค้ดตรงกัน ก็ยังคงเหมือนเดิม

กฎข้อ (2): กำหนดขั้นตอนการตรวจสอบผลลัพธ์ที่ AI สร้าง

กฎข้อที่สองคือ จะยืนยันผลลัพธ์ที่ AI สร้างอย่างไร จากงานวิจัยและคำอธิบายของผู้ผลิต บทความนี้แนะนำให้เขียน 6 ขั้นตอนต่อไปนี้เป็นขั้นตอนปฏิบัติภายในบริษัท

ขั้นที่ 1 คือการคอมไพล์ ยืนยันว่าผ่านในสภาพแวดล้อมการพัฒนาโดยไม่มีข้อผิดพลาดทางไวยากรณ์ Siemens และ CODESYS ระบุการแก้ไขข้อผิดพลาดจากการคอมไพล์และข้อผิดพลาดในการเขียนโค้ดเป็นฟังก์ชัน

ขั้นที่ 2 คือการตรวจแบบสแตติก ยืนยันว่าเป็นไปตามสไตล์ของบริษัท เช่น กฎการตั้งชื่อ วิธีเขียนคอมเมนต์ และขอบเขตของคำสั่งหรือดีไวซ์ที่อนุญาตให้ใช้ Siemens ระบุการตรวจตาม Style Guide เป็นฟังก์ชัน หากกฎของบริษัทยังไม่ได้ทำเป็นเอกสาร สิ่งแรกที่ต้องทำคือจัดทำเอกสารนั้น

ขั้นที่ 3 คือการทดสอบ สร้างกรณีทดสอบ (Test Case) จากข้อกำหนด แล้วยืนยันว่าขาเข้าและขาออกเป็นไปตามเจตนา หากให้ AI สร้างเทสต์ คนต้องยืนยันตัวเทสต์นั้นด้วย

ขั้นที่ 4 คือการจำลองและ Virtual Commissioning ใช้งานร่วมกับ Soft PLC หรือโมเดลของเครื่องจักร เพื่อยืนยันจังหวะเวลา (Timing) และ Interlock Rockwell อธิบายว่าใน FactoryTalk Design Studio v2.06 ได้ผนวกการจำลองบนคลาวด์ผ่าน “FactoryTalk Logix Echo as a Service” ทำให้สร้างและตรวจสอบลอจิกควบคุมได้โดยไม่ต้องรอฮาร์ดแวร์ OMRON กล่าวในการสัมภาษณ์ถึงแนวคิดในเฟส 1 ที่จะทำ PLC แบบเสมือน (Virtualization) เพื่อตรวจสอบผลลัพธ์ที่ AI สร้าง (เป็นเนื้อหาที่อยู่ระหว่างการพัฒนา) วิธีดำเนินการ Virtual Commissioning ดูได้ที่ “การจำลองหุ่นยนต์และ Virtual Commissioning“

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

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

หลังจาก 6 ขั้นตอนนี้ จึงไปสู่ FAT และ SAT กับเครื่องจริง ขั้นตอนที่จำเป็นแตกต่างกันตามประเภทงาน แนวคิดคือ หากเป็นการอ่านทำความเข้าใจและใส่คอมเมนต์ การยืนยันโดยคนในขั้นที่ 5 จะเป็นหลัก ส่วนการแก้ไขดัดแปลงหรือการเขียนโปรแกรมใหม่ต้องผ่านทุกขั้นตอน

กฎข้อ (3): กำหนดปลายทางของข้อมูลซอร์สโค้ดและข้อมูลเครื่องจักร

กฎข้อที่สามคือ จะส่งซอร์สโค้ด PLC และข้อมูลเครื่องจักรไปที่ใด ในเรื่องนี้แต่ละเครื่องมือออกแบบต่างกัน จึงตัดสินจากหลักการทั่วไปไม่ได้

ในฐานะแนวคิดของหน่วยงานภาครัฐ มีแนวทางร่วม “Principles for the Secure Integration of Artificial Intelligence in Operational Technology” ที่ 9 หน่วยงาน รวมถึง CISA ของสหรัฐฯ ออกเมื่อวันที่ 3 ธันวาคม 2025 แนวทางนี้มุ่งไปที่ผู้ประกอบการโครงสร้างพื้นฐานสำคัญ และเป้าหมายหลักคือ AI ที่ใช้งานอยู่ในระหว่างการเดินระบบ ไม่ใช่เอกสารที่กำกับการช่วยเขียนโค้ด PLC อย่างไรก็ตาม ใช้อ้างอิงเป็นแนวคิดในการจัดการข้อมูล OT ได้ แนวทางนี้ขอให้ไม่แบ่งปันข้อมูลลับกับโมเดล AI ที่โฮสต์อยู่ภายใต้การควบคุมของภายนอก และให้ทราบว่าผู้ให้บริการ AI เข้าถึงและใช้ข้อมูล OT อย่างไร โดยระบุ “ข้อมูลการกำหนดค่าทางวิศวกรรม (Engineering Configuration Data)” เป็นข้อมูลที่ควรปกป้องเป็นลำดับต้น และยกตัวอย่าง ได้แก่ แผนผังเครือข่าย ทะเบียนทรัพย์สิน เอกสารลำดับการเดินเครื่อง ข้อมูลด้านความปลอดภัย แผนผังลอจิก และวงจรไฟฟ้า นอกจากนี้ยังแนะนำให้ยืนยันกับผู้ให้บริการในเรื่องนโยบายการใช้ข้อมูลรวมถึงการใช้ฝึกโมเดล ความสามารถในการทำงานแบบ On-premises หรือโดยไม่ต้องเชื่อมต่อตลอดเวลา และเงื่อนไขในการปิดใช้งานฟังก์ชัน AI เป็นต้น

คำอธิบายของผู้ผลิตแตกต่างกันไป Siemens อธิบายเกี่ยวกับ Eigen ว่าเก็บ Prompt ขาเข้าและขาออกไว้เฉพาะในเครื่อง และไม่นำโค้ด PLC หรือไฟล์โปรเจกต์ไปใช้ฝึกโมเดล อย่างไรก็ตาม แม้จะมีข้อความว่าข้อมูลของลูกค้าใน EU ประมวลผลภายใน EU แต่ยืนยันพื้นที่ประมวลผลของลูกค้าในไทยไม่ได้ CODESYS อธิบายว่า MCP Server สื่อสารได้ทั้งกับ AI บนคลาวด์และ LLM ภายในองค์กร OMRON กล่าวถึงบริการที่อยู่ในแผนว่าออกแบบให้ไม่นำข้อมูลไปฝึก LLM และไม่เก็บข้อมูลไว้บนเซิร์ฟเวอร์คลาวด์ สำหรับ Rockwell, Schneider Electric, Mitsubishi Electric และ Copia Automation ไม่พบข้อความทางการที่ระบุชัดว่านำข้อมูลไปใช้ฝึกโมเดลหรือไม่

ขอจัดระเบียบความสัมพันธ์กับพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลของไทย (PDPA) ไว้ด้วย PDPA เป็นกฎหมายที่คุ้มครองข้อมูลที่ระบุตัวบุคคลที่ยังมีชีวิตอยู่ได้ โดยปกติแล้ว ซอร์สโค้ด PLC และข้อมูลเครื่องจักรน่าจะไม่ถือเป็นข้อมูลส่วนบุคคล บทความนี้มองว่า การจะส่งไปยัง AI บนคลาวด์หรือไม่ เป็นเรื่องของความลับทางการค้า สัญญารักษาความลับกับลูกค้า และทรัพย์สินทางปัญญาเป็นหลัก อย่างไรก็ตาม ต้องระวังว่าหากคอมเมนต์มีชื่อพนักงาน หรือหากส่งลอจิกหรือ Log ที่จัดการรหัสพนักงาน ก็อาจอยู่ในขอบเขตของ PDPA ได้

ในทางปฏิบัติ ให้ยืนยันประเด็นต่อไปนี้ก่อนส่ง มีแบบหรือข้อกำหนดที่ได้รับฝากจากลูกค้าปนอยู่หรือไม่ สัญญารักษาความลับจำกัดการเปิดเผยต่อบุคคลที่สามหรือไม่ มีข้อมูลส่วนบุคคล เช่น ชื่อพนักงาน อยู่ในคอมเมนต์หรือไม่ และตามการจัดชั้นข้อมูลของบริษัท ข้อมูลระดับใดที่อนุญาตให้ส่งไปยัง AI ภายนอกได้ ภาพรวมของวิธีส่งข้อมูลให้ Generative AI อธิบายไว้ใน “มาตรการป้องกันข้อมูลรั่วไหลจาก Generative AI” หากไม่ต้องการให้ข้อมูลออกนอกบริษัท ทางเลือกในการรันโมเดลภายในบริษัทดูได้ที่ “การนำ Local LLM มาใช้“

โปรแกรมที่เกี่ยวกับความปลอดภัยและความสัมพันธ์กับมาตรฐาน

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

ตามบทคัดย่ออย่างเป็นทางการของ IEC 61508-3 (ข้อกำหนดด้านซอฟต์แวร์) มาตรฐานนี้ครอบคลุมข้อกำหนดสำหรับซอฟต์แวร์ที่ใช้พัฒนาระบบที่เกี่ยวกับความปลอดภัย และเครื่องมือสนับสนุน เช่น เครื่องมือพัฒนาและออกแบบ ตัวแปลงภาษา และเครื่องมือทดสอบ IEC 61508 แบ่งเครื่องมือสนับสนุนแบบออฟไลน์เป็น T1 ถึง T3 โดย T3 คือเครื่องมือที่สร้างผลลัพธ์ซึ่งมีส่วนต่อโค้ดที่รันจริงทั้งทางตรงหรือทางอ้อม และต้องมีหลักฐานว่าเป็นไปตามข้อกำหนด เราไม่พบเอกสารของมาตรฐาน หน่วยงานภาครัฐ หรือหน่วยรับรองที่ระบุว่า Generative AI จัดอยู่ในประเภทใด บนพื้นฐานนี้ บทความนี้อนุมานว่า หากผลลัพธ์ของ AI กลายเป็นโค้ดที่รันจริงโดยตรง ก็อาจถูกขอเหตุผลในการเลือกเครื่องมือและการตรวจสอบตามแนวคิดเดียวกับคอมไพเลอร์ นี่เป็นการอนุมาน ไม่ใช่การยืนยันว่าเป็นข้อกำหนดของมาตรฐาน

ISO/IEC TR 5469:2024 เป็นรายงานทางเทคนิค (Technical Report) ที่ครอบคลุมกรณีใช้ระบบ AI ในการออกแบบและพัฒนาฟังก์ชันที่เกี่ยวกับความปลอดภัยด้วย แต่ไม่ใช่มาตรฐานข้อกำหนดที่ต้องปฏิบัติตาม ISO 13849-1:2023 และ IEC 62061:2021 กำหนดข้อกำหนดในการออกแบบระบบควบคุมที่เกี่ยวกับความปลอดภัยของเครื่องจักร แต่บทคัดย่ออย่างเป็นทางการไม่มีการกล่าวถึง Generative AI

หากผลิตเครื่องจักรสำหรับตลาดยุโรป ระเบียบเครื่องจักรของ EU (EU) 2023/1230 ก็เกี่ยวข้องด้วย คณะกรรมาธิการยุโรประบุชัดว่าจะบังคับใช้ระเบียบนี้ตั้งแต่วันที่ 20 มกราคม 2027 ภาคผนวก III ข้อ 1.2.1(c) กำหนดว่าความผิดพลาดในลอจิกของระบบควบคุมต้องไม่นำไปสู่สถานการณ์อันตราย ประเภทที่กำหนดให้ต้องประเมินความสอดคล้องโดยบุคคลที่สาม คือชิ้นส่วนหรือระบบความปลอดภัยที่มีพฤติกรรมวิวัฒน์ตัวเองด้วย Machine Learning ส่วนอารัมภบทข้อ (55) ระบุว่า ข้อกำหนดการประเมินโดยบุคคลที่สามนี้ไม่ใช้กับซอฟต์แวร์ที่เรียนรู้หรือวิวัฒน์ไม่ได้ และถูกโปรแกรมไว้เพียงให้ทำฟังก์ชันอัตโนมัติเฉพาะอย่าง โปรแกรม PLC ที่เขียนด้วย Generative AI แล้วถูกตรึงไว้ ตัวมันเองไม่ได้เรียนรู้หรือวิวัฒน์ จึงอ่านได้ว่าไม่จัดเป็นแบบวิวัฒน์ตัวเองตามถ้อยคำนี้ อย่างไรก็ตาม นี่เป็นการตีความของบทความนี้ ไม่ใช่ความเห็นของหน่วยงานกำกับ และข้อกำหนดเรื่องการป้องกันความผิดพลาดของลอจิกใช้บังคับไม่ว่าจะเขียนด้วย AI หรือไม่

ครั้งนี้เราไม่พบความเห็นอย่างเป็นทางการจากหน่วยรับรอง เช่น TÜV เกี่ยวกับการใช้โค้ดที่ AI สร้างในซอฟต์แวร์ที่เกี่ยวกับความปลอดภัย วิธีดำเนินการ Validation ของ Safety PLC อธิบายไว้ใน “การตรวจสอบความถูกต้อง (Validation) ของ Safety PLC” แนวคิดของบทความนี้คือ เส้นแบ่งที่เข้าใจง่ายคือ ในระยะนี้ให้กันวงจรที่เกี่ยวกับความปลอดภัยไว้นอกขอบเขตงานที่ให้ AI ทำ และหากจะใช้ ก็ให้ผ่านขั้นตอนการตรวจสอบและอนุมัติเดียวกับซอฟต์แวร์ที่เกี่ยวกับความปลอดภัยตามปกติ

ความปลอดภัยไซเบอร์ OT และการควบคุมเวอร์ชัน

เมื่อใช้ Generative AI ซอร์สโค้ดจะถูกเปลี่ยนเร็วขึ้นและบ่อยขึ้น การบันทึกและปกป้องการเปลี่ยนแปลงจึงยิ่งสำคัญ

ภาคผนวก III ข้อ 1.1.9 ของระเบียบเครื่องจักรของ EU กำหนดให้ระบุซอฟต์แวร์และข้อมูลที่สำคัญต่อความสอดคล้อง ปกป้องจากการเปลี่ยนแปลงโดยมิชอบหรือโดยบังเอิญ และเก็บหลักฐานการเปลี่ยนแปลงซอฟต์แวร์ ข้อ 1.2.1(f) กำหนดให้เปิดใช้ Log ที่ติดตามเวอร์ชันของซอฟต์แวร์ความปลอดภัยที่อัปโหลดหลังวางตลาดและข้อมูลการแทรกแซงเป็นเวลา 5 ปี แม้ไม่ใช่เครื่องจักรสำหรับตลาดยุโรป แนวคิดที่บันทึกเวอร์ชันและเหตุผลของการแก้ไขดัดแปลงก็ใช้เป็นแนวทางการควบคุมเวอร์ชันสำหรับโรงงานที่ใช้ AI ได้

IEC 62443-4-1 เป็นมาตรฐานที่กำหนดข้อกำหนดของกระบวนการพัฒนาผลิตภัณฑ์สำหรับระบบควบคุมอุตสาหกรรมอย่างปลอดภัย อย่างไรก็ตาม บทคัดย่ออย่างเป็นทางการระบุว่าใช้กับผู้พัฒนาและผู้บำรุงรักษาผลิตภัณฑ์ ไม่ใช้กับ Integrator หรือผู้ใช้ บทความนี้มองว่า มาตรฐานนี้ไม่ได้บังคับกับโรงงานหรือ SI โดยตรง การใช้ที่เหมาะสมคือใช้เป็นข้อมูลประกอบการคิดว่าจะขออะไรจากผู้ผลิตที่ออกเครื่องมือซึ่งมีฟังก์ชัน AI

สิ่งที่ควรกำหนดไว้ในทางปฏิบัติมีดังนี้ เก็บสำรองซอร์สโค้ดไว้ทั้งก่อนและหลังการแก้ไขดัดแปลง ยืนยันเป็นระยะว่าโปรแกรมในเครื่องจริงกับซอร์สโค้ดในเซิร์ฟเวอร์ตรงกันหรือไม่ ทราบว่าเครื่องมือ AI เชื่อมต่อกับสภาพแวดล้อมการพัฒนาหรือ PLC ด้วยสิทธิ์ระดับใด และหากใช้กลไกที่ให้ AI ภายนอกสั่งงานสภาพแวดล้อมการพัฒนาได้ เช่น MCP ให้จำกัดขอบเขตที่สั่งงานได้ ความปลอดภัยเมื่อใช้ AI Agent ในโรงงาน จัดระเบียบไว้ใน “ความปลอดภัยของ AI Agent ในโรงงาน“

ข้อควรระวังเมื่อใช้ในการย้ายโปรแกรมตอนอัปเกรดหรือเปลี่ยน PLC

Generative AI เริ่มถูกนำมาใช้ในงานย้ายโปรแกรมเก่าไปยังสภาพแวดล้อมใหม่ เมื่ออัปเกรด PLC หรือเปลี่ยนผู้ผลิตด้วย

CODESYS แนะนำ SyntaxShift ของ KS Solutions AG ในฐานะโซลูชันภายนอก ซึ่งใช้ AI แปลงระหว่าง IL หรือ SCL ของ Siemens กับ ST ของ CODESYS และหน้าของบริษัทอธิบายว่า “จะมาใน CODESYS Store เร็ว ๆ นี้” Siemens ระบุฟังก์ชันของ Eigen ได้แก่ การอธิบายลอจิกเก่าและใส่คอมเมนต์ และการย้ายจาก VBScript ไปเป็น JavaScript ใน WinCC Unified

เมื่อใช้ในการย้ายโปรแกรม สิ่งสำคัญคือต้องปฏิบัติต่อผลการแปลงเหมือนโปรแกรมที่เขียนขึ้นใหม่ ตรวจส่วนต่าง (Diff) ระหว่างก่อนและหลังการแปลงว่า การกำหนด I/O การตั้งค่า Timer และ Counter และการทำงานเมื่อเกิดความผิดปกติตรงกันหรือไม่ จากนั้นจึงผ่านขั้นตอนการตรวจสอบตามกฎข้อ (2) แล้วไปสู่การยืนยันกับเครื่องจริง ลำดับที่อาจพิจารณาได้อีกแบบคือ ใช้ AI อ่านทำความเข้าใจโปรแกรมเก่าและใส่คอมเมนต์ก่อน จัดทำข้อกำหนดเป็นเอกสาร แล้วจึงย้าย

การตัดสินใจว่าจะอัปเกรดหรือไม่และเมื่อใด อธิบายไว้ใน “การตัดสินใจอัปเกรดและเปลี่ยน PLC“

ข้อตกลงเมื่อให้ผู้รับจ้างภายนอกหรือ SI ใช้ Generative AI

แม้บริษัทจะไม่ได้ใช้ Generative AI เอง แต่ SI ที่รับจ้างอาจใช้ ในฐานะผู้ว่าจ้าง บทความนี้แนะนำให้ตกลงประเด็นต่อไปนี้ไว้

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

ข้อที่สอง การบันทึกส่วนที่ AI สร้าง ให้ระบุส่วนที่ AI สร้างหรือแก้ไขดัดแปลงไว้ในคอมเมนต์หรือบันทึกการเปลี่ยนแปลง ให้รู้ได้ว่าเป็นส่วนใด

ข้อที่สาม ผู้รับผิดชอบการรีวิว หากเขียนในสัญญาว่า ไม่ว่าจะใช้ AI หรือไม่ ผู้รับจ้างเป็นผู้รับผิดชอบเนื้อหาของโปรแกรมที่ส่งมอบ ความเข้าใจผิดจะลดลง

ข้อที่สี่ การส่งมอบซอร์สโค้ด ให้ส่งมอบซอร์สโค้ดเวอร์ชันเดียวกับที่เขียนลงเครื่องจริง พร้อมคอมเมนต์

ข้อที่ห้า ภาษาของคอมเมนต์ สามารถขอให้ใส่คอมเมนต์เป็นภาษาไทยหรือภาษาอังกฤษ เพื่อให้ช่างซ่อมบำรุงชาวไทยอ่านได้ แม้จะใช้ฟังก์ชันแปลของ Generative AI คนก็ต้องยืนยันคำแปลของชื่อสัญญาณและศัพท์เทคนิค

วิธีเลือกผู้รับจ้างและขั้นตอนการว่าจ้างโดยทั่วไป อธิบายไว้ใน “การจ้างพัฒนาโปรแกรม PLC จากภายนอก“

ข้อกำหนดที่ควรเขียนใน RFP และเกณฑ์การตรวจรับ FAT และ SAT

ไม่ว่าจะนำเครื่องมือมาใช้เอง หรืออนุญาตให้ผู้รับจ้างใช้ Generative AI การเขียนข้อกำหนดไว้ใน RFP จะทำให้การเปรียบเทียบและการตรวจรับง่ายขึ้น วิธีจัดทำกฎการใช้งานภายในบริษัท ดูเพิ่มเติมได้ที่ “กฎการใช้ Generative AI ภายในบริษัท“

ใน FAT (การทดสอบตรวจรับที่โรงงานผู้ผลิต) ให้เตรียมคำสั่งแก้ไขดัดแปลงที่เป็นตัวแทนไว้จำนวนหนึ่ง แล้วยืนยันประเด็นต่อไปนี้ คอมไพล์ผ่านหรือไม่ เทสต์ที่เตรียมไว้ผ่านหรือไม่ ทำงานตามเจตนาในการจำลองหรือไม่ และผู้รับผิดชอบอ่านลอจิกนั้นแล้วอธิบายได้หรือไม่

ใน SAT (การทดสอบตรวจรับที่หน้างาน) ให้ยืนยันการทำงานกับเครื่องจริง ยืนยันกรณีผิดปกติ และยืนยันขั้นตอนการย้อนกลับไปเวอร์ชันเดิมเมื่อเกิดปัญหา

ค่าตัวเลขที่ใช้เป็นเกณฑ์ผ่าน (เช่น สัดส่วนที่ผ่านการตรวจสอบ หรือเวลาที่คนใช้แก้ไข) ให้เขียนค่าที่ตกลงกันภายในบริษัท บทความนี้ไม่แนะนำค่าที่เจาะจง วิธีกำหนดว่าจะจบการทดลอง (PoC) เมื่อใดแล้วไปสู่การใช้งานจริง อธิบายไว้ใน “เกณฑ์การจบ AI PoC“

การคำนวณต้นทุนและผลตอบแทนแบบจำลอง (ตัวเลขสมมติ)

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

สมมติว่าเป็นโรงงานชิ้นส่วนยานยนต์ญี่ปุ่นในไทย มีผู้รับผิดชอบงานควบคุมในฝ่ายวิศวกรรมการผลิต 3 คน ใช้ PLC หลายผู้ผลิตปะปนกัน และจ้าง SI ภายนอกทำงานแก้ไขดัดแปลงเล็ก ๆ

ต้นทุนรายปีที่เป็นสมมติฐานมี 2 รายการ A และ B นับเป็นงานคนละอย่าง ไม่ได้นับต้นทุนเดียวกันซ้ำ 2 ครั้ง

• A เวลาภายในบริษัทที่ใช้อ่านทำความเข้าใจโปรแกรมเดิมและจัดทำเอกสาร ปีละ 600 ชั่วโมง ที่ชั่วโมงละ 500 THB เท่ากับ 300,000 THB/ปี
• B ค่าจ้างภายนอกสำหรับงานแก้ไขดัดแปลงเล็ก ๆ ปีละ 20 งาน งานละ 40,000 THB เท่ากับ 800,000 THB/ปี
• รวม 1,100,000 THB/ปี

มาตรการได้แก่ การนำเครื่องมือ Generative AI มาใช้ สภาพแวดล้อมการตรวจสอบ กฎภายในบริษัทและการฝึกอบรม และการจัดระเบียบซอร์สโค้ดและการควบคุมเวอร์ชัน

• ค่าใช้จ่ายเริ่มต้น 520,000 THB ประกอบด้วย สภาพแวดล้อมการตรวจสอบ (Soft PLC หรือการจำลอง และขั้นตอนการทดสอบ) 220,000 THB การจัดทำกฎภายในบริษัทและการฝึกอบรม 150,000 THB และการจัดระเบียบซอร์สโค้ดและการควบคุมเวอร์ชัน 150,000 THB
• ค่าดำเนินการรายปี 90,000 THB/ปี ประกอบด้วย ค่าใช้เครื่องมือ (สมมติ) 60,000 THB และชั่วโมงงานรีวิวเพิ่มเติมสำหรับผลลัพธ์ที่ AI สร้าง 30,000 THB

ในกรณีฐาน หากลดเวลาของ A ได้ 40% จะได้ผล 120,000 THB/ปี หากทำงาน B ปีละ 5 งานเองภายในบริษัท ค่าจ้างภายนอกจะลดลง 200,000 THB แต่มีชั่วโมงงานภายใน 5 งาน × 40 ชั่วโมง × 500 THB = 100,000 THB จึงได้สุทธิ 100,000 THB/ปี ผลรวมคือ 220,000 THB/ปี เมื่อหักค่าดำเนินการ 90,000 THB/ปี ผลสุทธิคือ 130,000 THB/ปี และคืนทุนค่าใช้จ่ายเริ่มต้น 520,000 THB ได้ใน 4.0 ปี

ในกรณีผลน้อย (A ลดได้ 20% และ B ทำเองได้ปีละ 2 งาน) A ได้ 60,000 THB ส่วน B คือค่าจ้างภายนอกที่ลดลง 80,000 THB หักชั่วโมงงานภายใน 40,000 THB เหลือ 40,000 THB ผลรวมคือ 100,000 THB/ปี ผลสุทธิเหลือเพียง 10,000 THB/ปี และระยะคืนทุนคือ 52.0 ปี ซึ่งในทางปฏิบัติคือคืนทุนไม่ได้

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

ขอกล่าวถึงข้อมูลราคาที่เปิดเผยด้วย Eigen Engineering Agent ของ Siemens แสดงราคาในหน้าจำหน่ายของ Siemens Digital Exchange (S-DEX) ว่าค่าสมาชิกรายปี USD 2,100 (หลังทดลองใช้ฟรี 1 เดือน) นี่คือราคาที่แสดงสำหรับพื้นที่เรียกเก็บเงินในสหรัฐฯ (ณ วันที่ 15 ตุลาคม 2026 และอาจยังไม่รวมภาษี) เรายังไม่ได้ยืนยันราคาและเงื่อนไขการจำหน่ายในไทย หน้าเดียวกันอธิบายว่า 1 Seat กำหนดผู้ใช้ได้สูงสุด 3 คน และใช้งานพร้อมกันได้ 1 คน FactoryTalk Design Studio ของ Rockwell มีช่วงทดลองใช้ฟรี 90 วัน แต่ไม่พบราคาที่เปิดเผย CODESYS อธิบายว่า MCP Server ให้บริการรวมอยู่ใน Professional Developer Edition แต่ไม่พบราคาที่เปิดเผย สำหรับ Beckhoff, Copia Automation, Schneider Electric, Mitsubishi Electric และ OMRON ก็ไม่พบราคาที่เปิดเผยเช่นกัน

คำถามที่พบบ่อย

Generative AI สร้างโปรแกรม PLC ได้หรือไม่

มีสถานการณ์ที่สร้างได้ แต่ควรมองว่าเป็นร่างหรือข้อเสนอการแก้ไขดัดแปลงที่มีเงื่อนไขว่าคนต้องยืนยัน ทุกบริษัทที่กล่าวถึงบทบาทของคน ล้วนอธิบายฟังก์ชันโดยมีเงื่อนไขว่าคนต้องรีวิวก่อนนำไปใช้ งานวิจัยก็รายงานว่าอัตราความสำเร็จสูงขึ้นเมื่อใช้กลไกที่ผนวกเครื่องมือตรวจสอบ แต่แม้ภายใต้เงื่อนไขของบทความปี 2024 ก็ยังมีกรณีที่ล้มเหลวประมาณ 30%

แลดเดอร์กับ ST แบบใดสร้างด้วย AI ได้ง่ายกว่า

ในงานวิจัย มีหลายบทความที่รายงานผลการสร้าง ST ในทางกลับกัน ภายใต้เงื่อนไขของบทความปี 2024 การสร้างแลดเดอร์ (LD) อัตโนมัติยังมีปัญหาแม้ในตัวอย่างที่ง่ายมาก Mitsubishi Electric ก็กล่าวในทำนองว่า LLM ทั่วไปที่ไม่ได้ปรับแต่งแทบจะสร้างแลดเดอร์ไม่ได้ อย่างไรก็ตาม บทความวิจัยเป็นของปี 2023 ถึง 2025 และโมเดลไม่ใช่รุ่นล่าสุด

นำโปรแกรมที่ AI สร้างไปใช้ตามที่ได้มาเลยได้หรือไม่

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

มาตรฐานความปลอดภัยห้ามใช้โค้ดที่ AI สร้างหรือไม่

ในบทคัดย่ออย่างเป็นทางการและตัวบทของมาตรฐานความปลอดภัยที่เราตรวจดู ไม่พบข้อความที่ห้ามหรืออนุญาตโค้ดที่เขียนด้วย Generative AI อย่างไรก็ตาม ไม่ว่าผู้เขียนจะเป็นคนหรือ AI ก็ต้องมีการตรวจสอบซอฟต์แวร์ เหตุผลในการเลือกเครื่องมือ และมาตรการรับมือความผิดพลาดของลอจิกควบคุม บทความนี้เสนอทางเลือกที่จะกันวงจรที่เกี่ยวกับความปลอดภัยไว้นอกขอบเขตงานที่ให้ AI ทำในระยะนี้

ส่งซอร์สโค้ด PLC ไปยัง AI บนคลาวด์ได้หรือไม่

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

ใช้อ่านทำความเข้าใจแลดเดอร์เดิมได้หรือไม่

ใช้ได้ บทความนี้มองว่า ก้าวแรกที่เริ่มได้ง่ายคือการอ่านทำความเข้าใจและใส่คอมเมนต์ เพราะผลลัพธ์ที่ AI สร้างไม่เปลี่ยนการทำงานของเครื่องจักร และคนยืนยันได้โดยเทียบกับต้นฉบับ Rockwell และ Siemens ระบุฟังก์ชันอธิบายโค้ดเดิมในผลิตภัณฑ์ที่วางจำหน่ายแล้ว ส่วน Mitsubishi Electric และ OMRON ก็นำเสนอฟังก์ชันอธิบายในฐานะเนื้อหาที่อยู่ระหว่างการพัฒนา

เครื่องมือ Generative AI สำหรับโปรแกรม PLC มีค่าใช้จ่ายเท่าไร

ราคาที่เปิดเผยที่ยืนยันได้มีเพียง Siemens Eigen Engineering Agent ราคาที่แสดงสำหรับพื้นที่เรียกเก็บเงินในสหรัฐฯ (ณ วันที่ 15 ตุลาคม 2026 และอาจยังไม่รวมภาษี) คือปีละ USD 2,100 เรายังไม่ได้ยืนยันราคาในไทย และไม่พบราคาที่เปิดเผยของบริษัทอื่น นอกจากค่าเครื่องมือแล้ว ยังมีค่าใช้จ่ายด้านสภาพแวดล้อมการตรวจสอบ การฝึกอบรม การจัดระเบียบซอร์สโค้ด และชั่วโมงงานรีวิวเพิ่มเติมด้วย

สรุป

• สิ่งที่ควรกำหนดก่อนนำ Generative AI มาใช้กับโปรแกรม PLC ไม่ใช่ชื่อเครื่องมือ แต่เป็น 3 เรื่อง ได้แก่ (1) ขอบเขตงานที่ให้ AI ทำ (2) ขั้นตอนการตรวจสอบผลลัพธ์ที่ AI สร้าง และ (3) ปลายทางของข้อมูลซอร์สโค้ดและข้อมูลเครื่องจักร
• สถานะการให้บริการของผู้ผลิตรายหลักมีทั้งที่วางจำหน่ายแล้ว ที่ประกาศอย่างเดียว และที่อยู่ระหว่างการพัฒนาปะปนกัน ทุกบริษัทที่กล่าวถึงบทบาทของคน ล้วนอธิบายฟังก์ชันโดยมีเงื่อนไขว่าคนต้องยืนยัน
• งานวิจัยรายงานว่าผลลัพธ์ดีขึ้นเมื่อผนวกเครื่องมือตรวจสอบ และถือว่าแลดเดอร์สร้างได้ยากกว่า ST
• บทความนี้มองว่า ก้าวแรกที่เริ่มได้ง่ายคือการอ่านทำความเข้าใจโปรแกรมเดิมและใส่คอมเมนต์
• การตรวจสอบให้เขียน 6 ขั้นตอน ได้แก่ การคอมไพล์ การตรวจแบบสแตติก การทดสอบ การจำลอง การรีวิวและอนุมัติโดยคน และการควบคุมเวอร์ชัน ไว้เป็นขั้นตอนปฏิบัติ แล้วยืนยันด้วย FAT และ SAT กับเครื่องจริง
• การจัดการข้อมูลแตกต่างกันในแต่ละบริษัท ให้ยืนยันพื้นที่ประมวลผล การนำไปใช้ฝึกโมเดล และการเก็บ Log ผ่านเอกสารทางการและสัญญา
• ในบทคัดย่ออย่างเป็นทางการและตัวบทของมาตรฐานความปลอดภัยที่เราตรวจดู ไม่พบข้อความที่กำหนดว่าโค้ดที่ AI สร้างใช้ได้หรือไม่ได้ มาตรการรับมือความผิดพลาดของลอจิกและการตรวจสอบการแก้ไขดัดแปลงจำเป็นต้องมี ไม่ว่าผู้เขียนจะเป็นใคร
• ในการคำนวณสมมติ หากผลน้อยก็คืนทุนไม่ได้ ก่อนนำมาใช้ให้นับจำนวนงานแก้ไขดัดแปลงและเวลาที่ใช้อ่านทำความเข้าใจ และวัดผลใน PoC ก่อนนับเป็นผลตอบแทน

TOMAS TECH รับปรึกษาตั้งแต่ขั้นต้น เช่น การพิจารณาว่าจะเริ่มทดลอง Generative AI จากงานใด การจัดระเบียบขั้นตอนการตรวจสอบและปลายทางของข้อมูลซอร์สโค้ด และการจัดทำข้อตกลงกับผู้รับจ้างภายนอก แม้ในกรณีที่โรงงานในไทยใช้ PLC หลายผู้ผลิตปะปนกัน เราก็พร้อมเริ่มจากการจัดระเบียบสถานะปัจจุบันไปด้วยกัน ติดต่อสอบถามได้ที่นี่

แหล่งอ้างอิง

• Siemens bringt „Eigen Engineering Agent” auf den Markt (2026-04-20) / Siemens AG
• Eigen Engineering Agent (หน้าผลิตภัณฑ์) / Siemens
• Data security, Eigen Engineering Agent (Doc v1.5.1) / Siemens
• Eigen Engineering Agent (หน้าจำหน่าย S-DEX) / Siemens
• Engineering Copilot TIA Standard (Preview) / Siemens
• Rockwell Automation and Microsoft Deliver on a Shared Vision (2024-11-19) / Rockwell Automation
• FactoryTalk Design Studio (หน้าผลิตภัณฑ์) / Rockwell Automation
• TwinCAT Chat: Using innovative chatbot technology in TwinCAT engineering / Beckhoff
• TE1700 TwinCAT 3 CoAgent for Engineering / Beckhoff
• Engineering at scale: How AI is transforming PLC coding (2025-11-14) / Schneider Electric Blog
• CODESYS AI-supported Engineering / CODESYS Group
• ทำไม Mitsubishi Electric จึงท้าทายการพัฒนา AI สร้างโปรแกรมแลดเดอร์ (1/2) (บทความภาษาญี่ปุ่น) / MONOist
• ทำไม Mitsubishi Electric จึงท้าทายการพัฒนา AI สร้างโปรแกรมแลดเดอร์ (2/2) (บทความภาษาญี่ปุ่น) / MONOist
• “อีก 10 ปีข้างหน้ายังอ่านโปรแกรมแลดเดอร์นั้นออกหรือไม่” การใช้ AI ในมุมมองของ OMRON (1/2) (บทความภาษาญี่ปุ่น) / MONOist
• “อีก 10 ปีข้างหน้ายังอ่านโปรแกรมแลดเดอร์นั้นออกหรือไม่” การใช้ AI ในมุมมองของ OMRON (2/2) (บทความภาษาญี่ปุ่น) / MONOist
• OMRON เพิ่มประสิทธิภาพด้วย “ทีม Generative AI” พร้อมการค้นหาทรัพย์สินโปรแกรมแลดเดอร์ (บทความภาษาญี่ปุ่น) / MONOist
• Copia AI / Copia Automation
• LLM4PLC: Harnessing LLMs for Verifiable Programming of PLCs / arXiv
• Agents4PLC: Automating Closed-loop PLC Code Generation and Verification / arXiv
• ChatGPT for PLC/DCS Control Logic Generation / arXiv
• Exploring LLM Support for Generating IEC 61131-3 Graphic Language Programs / arXiv
• Training LLMs for Generating IEC 61131-3 Structured Text with Online Feedback / arXiv
• Spec2Control: Automating PLC/DCS Control-Logic Engineering / arXiv
• Industrial Automation, Setting the Standard for AI-Generated Control Code / Fraunhofer IKS
• IEC 61131-3:2025 Programmable controllers, Part 3 Programming languages / IEC Webstore
• IEC 61508-3:2010 Functional safety, Part 3 Software requirements / IEC Webstore
• ISO 13849-1:2023 Safety-related parts of control systems / ISO
• IEC 62061:2021 Safety of machinery / IEC Webstore
• ISO/IEC TR 5469:2024 Artificial intelligence, Functional safety and AI systems / ISO
• IEC 61508, Why tool qualification / UL (เอกสารเผยแพร่โดย 61508 Association)
• Regulation (EU) 2023/1230 on machinery / Publications Office of the EU
• Machinery / European Commission
• IEC 62443-4-1:2018 Secure product development lifecycle requirements / IEC Webstore
• Principles for the Secure Integration of AI in Operational Technology / CISA และหน่วยงานอื่น
• Thailand’s Investment Applications Reach New Highs in 2025 / BOI
• Thailand Unveils New Incentives for Automotive and HEV/PHEV Manufacturing / Tilleke & Gibbins
• AI boom leaves Thai graduates facing a tougher job hunt / The Star
• What to Expect When the PDPA B.E. 2562 Is Fully Enforced in June 2022 / Gala & Associates