技術文章AI 工具
首頁 › 技術文章 › AI PLC 程式驗證

我們怎麼驗證 AI 產生的 PLC 程式

易歐特科技 · 平台技術 · 四層驗證管線的實作與實測

市面上的 AI PLC 工具,幾乎沒有一家願意告訴你「他們怎麼確認產出的東西是對的」。有的宣稱「99.9% 準確率」,有的說「維持 IEC 61508」——但都拿不出方法,也拿不出數字。

這篇把我們的做法完全攤開:四層驗證、每一層用什麼工具、以及我們實際踩到的坑。 包括那些讓我們自己難堪的部分。

先講一個所有人都不想承認的事實

今天沒有任何 AI 能可靠地自主產生 PLC 程式。一個都沒有。

這不是我的意見,是公開文獻的數字:

· Siemens Technology 的研究(arXiv 2410.22159):經過編譯器回饋訓練後,「編譯成功 且 語意正確」的比例是 39%。
· Agents4PLC(浙江大學,arXiv 2410.14209):多代理 + 形式驗證,通過率簡單題 50%、中等題 28.6%——而且 benchmark 只有 23 題。
· AutoPLC 宣稱的「90%+」是編譯成功率,不是正確率。別讓人拿這個數字唬你。

所以誠實的產品定位只有一個:AI 產生初稿,人工必須審查。
任何宣稱可以取代工程師的說法,第一次出事就會結束——而 PLC 出事的代價是設備、產線,有時候是人。

在這個前提下,我們能做的是:盡可能提高初稿的品質,並且把「哪裡可能有問題」明確地告訴你。

第一層:真實的 IEC 61131-3 編譯器

最便宜、效果最大的一步,而且大部分競爭對手沒做。

把編譯器放進迴圈,效果是數量級的。三組獨立研究都證實:

研究做法編譯成功率
Siemens Technology編譯器回饋訓練7% → 70%
LLM4PLC(UC Irvine)語法+編譯器+模型檢查47% → 72%
Agents4PLC(浙大)多代理+驗證器迴圈87.5% → 100%

我們的做法: AI 產生 ST 之後,把它送進 matiec(開源的 IEC 61131-3 編譯器,GPLv3)實際編譯。編不過,就把編譯器的原始錯誤訊息餵回去請 AI 修,再編一次。

重試不扣你的點數。 那是我們的品質成本,不是客戶的。

踩到的坑:註解方言

matiec 只認 IEC 標準的 (* ... *) 註解,不吃 // 行註解。

但 TIA Portal、CODESYS、GX Works3 全都支援 //,AI 也習慣這樣寫。

結果:程式明明沒錯,卻一直報 unclosed variable declaration——大量假警報。

解法: 送去編譯前先把 // 轉成 (* *),但只轉換「送去檢查的副本」。你拿到的程式碼原封不動保留 //——因為你的目標平台本來就吃得下。

我們另外寫了測試,確保它不會把 a / b(除法)或字串裡的 // 誤判成註解。

更危險的坑:只看 exit code

我們原本只檢查編譯器的離開碼(exit code)。測試發現:它會在有錯誤的情況下仍然回報成功。

這是最危險的一種 bug——它讓你更有信心地交出錯的東西。

那個綠色的「✅ 已通過編譯器驗證」標章,會是假的。

修正:「通過」必須同時滿足「離開碼為 0」且「輸出裡沒有任何 error」。

第二層:PLCopen 規範檢查

編譯器只回答「編不編得過」。這一層回答「寫得好不好」。

我們接上 iec-checker(LGPL-3.0),它實作了 PLCopen Software Construction Guidelines 的檢查規則:未宣告的變數、未初始化就使用、不可達的程式碼、遞迴呼叫……

踩到的坑:假警報會殺死整個功能

iec-checker 的 PLCOPEN-CP3(「變數未初始化就使用」)在 PLC 情境下,誤報率接近 100%。

一段完全正確的雙泵交替程式,它報了 15 項——全部是假的。

為什麼?因為這條規則的前提,與 PLC 的執行模型不相容:

· 輸入變數的值由現場硬體寫入,程式裡本來就不該給初始值
· 輸出與狀態變數跨掃描週期保持——而自保持電路的本質,就是「先讀自己、再寫自己」。CP3 會把每一個正確的自保持,都當成錯誤。

在一般程式語言裡它是對的。在 PLC 裡它是錯的。
我們第一次的解法是錯的,值得寫出來。

我們原本試圖用變數名稱過濾——認出 X000、Y000 這種元件編號就跳過。

然後 AI 換了寫法,用符號名(xStart、xBlower1Run),過濾器整個漏光,15 項全部湧出來。

那時才想通:我們在治標。 問題不是「哪些變數是 I/O」,問題是這條規則的前提本身就不成立。

最後的解法:整條停用,並在畫面上誠實說明為什麼。 其餘 25 條規則保留。

會誤報的檢查,比沒有檢查更糟——它會讓客戶連真正的警告一起忽略。
這跟我們在養殖場電子圍籬那篇講的是同一件事:一套整晚誤報的圍籬,遲早被主人自己關掉——然後就在關著的那一晚被偷。

第三層:把程式真的跑起來(這一層沒有人做)

前面兩層都只回答「寫得對不對」。都沒有回答最重要的那個問題:

它做的事,對不對?

做法

1. matiec 把 ST 編譯成 C         (iec2c 本來就是做這件事)
2. 產生一支 C 測試骨架:
     - 建立程式實例
     - 設定輸入變數
     - 執行 N 次「掃描週期」
     - 讀取輸出變數,比對預期
3. gcc 編譯、實際執行
4. 回報每個情境的 PASS / FAIL

這等於在雲端跑了一台虛擬 PLC。

實際輸出長這樣

需求:馬達啟停自保持,含過載保護

PASS  按下啟動,馬達應運轉
PASS  放開啟動鈕,馬達應維持運轉(自保持)
PASS  按下停止鈕,馬達應停止
PASS  過載跳脫時,馬達應停止
PASS  未按啟動鈕時,馬達應保持停止

注意第二個情境——「放開啟動鈕,輸出應維持」。這正是自保持電路的核心,也是新手最常漏掉的一行 OR。靜態檢查只能猜,執行測試可以證明。

踩到的坑(這些文件裡沒寫)

這些只有真的編一次、跑一次才會知道。

誠實的邊界——這段請務必看完

測試情境是 AI 依照你的需求描述設計的。所以它驗證的是:

「程式是否符合 AI 對需求的理解」
而不是
「程式是否符合你的真實意圖」

這兩者的差距,就是你必須親自審查的理由。

沒過 = 幾乎確定有問題。
過了 = 值得高興,但不是保證。

實機或模擬器驗證,永遠不能省。

第四層:現場規則(這一層是我們自己的)

前三層都是「通用的正確性」。但 PLC 有一大類問題,是編譯器與規範檢查都看不出來的——因為它們不是程式錯誤,是工程錯誤。

所以我們把 10 年現場經驗寫成了確定性的規則:

規則為什麼編譯器抓不到
雙線圈(同一輸出寫兩次)語法完全合法。但後面那個會默默蓋掉前面,線上監看還看起來是對的
安全訊號用了常開接點語法合法。但線一斷,你按停止鈕也停不下來
正反轉沒有互鎖語法合法。但兩個接觸器同時吸合 = 三相電源相間短路
三菱定時器時基T200 K20 是 0.2 秒不是 2 秒。寫錯就是差 10 倍
品牌指令混用三菱程式裡出現西門子的 MOVE
ST 用 WHILE 等外部條件語法合法。但會觸發看門狗,讓 PLC 停機
累計量用 INT語法合法。但 32767 之後會翻成負數
為什麼是「規則」,不是「再叫一個 AI 看一遍」?

因為兩個語言模型會犯同一類的錯——它們都在看文字,沒有在看設備。

規則是確定性的:100% 會執行、每次結果都一樣、不會被寫得很漂亮的程式碼騙過去。

而且這份清單會愈長愈值錢。我們每在現場遇到一個新的坑,就加一條規則、補一個測試。

四層總覽

層回答的問題工具
① 編譯器編不編得過?matiec(真實 IEC 61131-3 編譯器)
② 規範檢查寫得好不好?iec-checker(PLCopen 官方規則)
③ 行為測試做的事對不對?matiec → gcc → 實際執行
④ 現場規則會不會在現場出事?易歐特 10 年、100+ 案例累積

最後,講一件我們自己很難堪的事

上面每一個「坑」,都是測試抓到的——不是我們想到的。

最誇張的一個:編譯修正那一輪,模型有時候會回「錯誤原因是…」這種說明文字,而我們的程式直接把它當成程式碼塞回去。

如果沒有寫測試,客戶拿到的 ST 開頭會是一段中文解釋。而我們永遠不會知道。

這就是為什麼我們相信「可重複的驗證」比「更聰明的模型」重要。

模型會進步,但它永遠不會告訴你它哪裡錯了。測試會。

小結

AI 產生的 PLC 程式,到底能不能信?

我們建了一套 20 題基準測試,題目全部來自真實案場,並且公開了完整結果——包含難看的那幾項: 編譯通過率 80~95%、品牌指令混用 0%、整體全對 55~65%。

還有一個對我們自己不利的發現:AI review 幫得上找出可疑點,但 finding 本身也會誤報、必須經規則層與測試結果校正;它更不能可靠地「修好」程式。

→ 我們把 AI 寫 PLC 的準確率量出來了:20 題基準測試

每一份 ST,都經過真實編譯器編譯,並實際執行驗證

這不是行銷詞。你可以現在就試——產生任何一段程式碼,結果上方會顯示編譯器驗證、PLCopen 規範檢查、以及行為測試的逐項 PASS/FAIL。有問題的地方我們會直接告訴你。

免費試用 AI PLC 工具 →

免費會員每月 15 點 · 不需信用卡 · 產生失敗不扣點

易歐特科技有限公司 · 工業自動化 PLC 程式設計與環控系統整合 · 委託開發