Kuidas programmeerida deterministlikku vetot ohutus-PLC-s AI-hallutsinatsioonide ülekirjutamiseks

Tööstusautomaatikas AI-hallutsinatsioonide ülekirjutamiseks peavad insenerid paigutama tehisintellekti deterministliku PLC-veto taha. PLC peab enne mis tahes täitmist kontrollima AI nõutud käske fikseeritud piirväärtuste, olekupõhiste lubatavustingimuste ja juhtmega ühendatud ohutusfunktsioonide suhtes. See kihiline kaitse eraldab tõenäosusliku optimeerimise deterministlikust täitmisest.

Tehisintellekt ei muutu ohutuks seetõttu, et see kõlab enesekindlalt. Tööstusjuhtimises ei ole enesekindlus kontrollmuutuja.

Insenertehniline konflikt on lihtne: LLM-id ja agent-AI süsteemid on tõenäosuslikud ja mittedeterministlikud, samas kui PLC-d täidavad loogikat korduvate skannimistsüklitega ja piiratud käitumisega. See erinevus ei ole filosoofiline. See on arhitektuurne ja ohutusega seotud kontekstides otsustav.

Hiljutises 500 simuleeritud AI-genereeritud seadeväärtuse anomaalia sisemises partiis, mis läbisid OLLA Lab digitaalse kaksiku valideerimise töövoo, blokeeris PLC-poolne muutumiskiiruse piiraja koos selgete olekupõhiste lubatavustingimustega 100% katastroofilistest piiridest väljas olevatest käskudest enne, kui need aktiveerisid virtuaalsed klapi- ja mootorimudelid. Metoodika: n=500 süstitud anomaaliajuhtumit piiratud kiiruse, rõhu ja klapi asendi ülesannete lõikes; võrdlusalus = AI nõutud käsu otsene edastamine simuleeritud täiturmehhanismi sildile; ajavahemik = Ampergon Vallis siselabori katsed, mis viidi läbi 2026. aasta I kvartalis. See toetab deterministliku kontrolli väärtust simulatsioonis. See ei kujuta endast IEC 61508 sertifikaati, SIL-tõendusmaterjali ega väidet kõigi tehasearhitektuuride kohta.

Praktiline vastus ei ole AI keelamine. See on AI-le otsese täitmisvolituse keelamine ja nõudmine, et PLC hoiaks püsivat deterministlikku vetot.

AI-hallutsinatsioonid vajavad deterministlikku vetot, kuna AI väljundid ei ole garanteeritult piiratud, korratavad ega skannimissünkroonsed viisil, nagu PLC täitmine peab olema.

Juhtimissüsteemis on ebaturvaline käsk ebaturvaline isegi siis, kui see on genereeritud statistiliselt muljetavaldava mudeli poolt. Klapile ei lähe korda, et märgi tõenäosus tundus veenev.

IEC 61508 ja ISO 13849 on üles ehitatud prognoositava käitumise, määratletud rikete käsitlemise ja teadaolevate ohutute olekute ümber. Ohutusega seotud juhtimisfunktsioonid peavad ebaõnnestuma viisil, mida saab analüüsida, piirata ja valideerida. Praegused LLM-tüüpi süsteemid ei vasta sellele tasemele, kuna nende rikkerežiime ei saa ammendavalt iseloomustada viisil, mida deterministlik ohutusloogika nõuab. See on tegelik probleem: mitte see, et AI on uus, vaid see, et AI ei ole süstemaatiliselt piisavalt piiratud, et omada lõplikku täitmisteed.

Skannimistsükkel vs. järeldusmootor

PLC täidab loogikat tsükliliselt. See skannib sisendeid, lahendab loogikat, uuendab väljundeid ja kordab seda teadaoleva intervalliga, sageli millisekundite vahemikus, sõltuvalt platvormist, ülesande struktuurist ja koormusest.

AI järeldusmootor ei käitu nii. Selle reageerimisaeg varieerub sõltuvalt mudeli suurusest, arvutusressursside kättesaadavusest, võrgutingimustest, orkestreerimise üldkuludest ja viiba keerukusest. Isegi kui keskmine latentsusaeg tundub vastuvõetav, jäävad halvima stsenaariumi ajastus ja väljundkäitumine probleemiks.

See tekitab kahte tüüpi riske:

- Ajastusrisk: AI vastus võib saabuda hilja, vales järjekorras või kehtetu masinaoleku ajal. - Sisu risk: AI vastus võib nõuda võimatut, ebaturvalist või kontekstipimedat toimingut.

PLC suudab taluda viivitatud või tagasilükatud päringuid. Pumbasüsteem ei talu fantaasiat.

Mida standardid tegelikult nõuavad?

Standardid nõuavad prognoositavat ohutuskäitumist, mitte moekat tarkvara.

Kõrgel tasemel:

• IEC 61508 käsitleb elektriliste, elektrooniliste ja programmeeritavate elektrooniliste ohutusega seotud süsteemide funktsionaalset ohutust.
• ISO 13849 käsitleb juhtimissüsteemide ohutusega seotud osi, eriti masinate kontekstis.
• Mõlemad raamistikud sõltuvad määratletud arhitektuuridest, valideeritud käitumisest ja teadaolevatest vastustest rikketingimustele.

See ei tähenda, et iga mittedeterministlik tarkvarakomponent on tööstuslikus virnas kõikjal keelatud. See tähendab, et mittedeterministlikke komponente ei tohiks käsitleda lõpliku ohutusasutusena. Erinevus on oluline. Taju ja optimeerimine võivad olla tõenäosuslikud; veto ja väljalülitustee ei saa seda olla.

Deterministlik veto on kõvakodeeritud, skannimistsükliga seotud loogikastruktuur, mis hindab nõutud käsku ja blokeerib, piirab või kirjutab selle üle, kui käsk rikub füüsilisi piiranguid, protsessipiiranguid või masina oleku lubatavustingimusi.

See on operatiivne määratlus, mitte loosung. Deterministlik veto peab olema loogikas jälgitav ja rikkejuhtumite suhtes testitav.

Praktikas sisaldab deterministlik veto sageli:

- Piirväärtuste kontrolli: lubatud piiridest kõrgemate või madalamate väärtuste tagasilükkamine või piiramine - Muutumiskiiruse piiramist: järskude muutuste vältimine väljaspool ohutuid kaldemäärasid - Olekupõhiseid lubatavustingimusi: käskude lubamine ainult kehtivates tööolekutes - Tõestus- ja tagasisidekontrolle: kinnituse nõudmine välisseadmetelt enne järjestuse edendamist - Alarmi ja väljalülituse käitlemist: ohutu reageerimise sundimine ebanormaalsetes tingimustes - Režiimi isoleerimist: kaug- või AI-nõutud toimingute vältimine kohalikus, hooldus- või rikkerežiimis

Kui AI nõuab 150% ajami kiirust ja PLC piirab selle konfigureeritud maksimumini, tõstes samal ajal alarmi, siis veto töötas. Kui AI saab kirjutada otse väljundpilti, on arhitektuur vale.

Operatiivsed määratlused, mis on olulised

Neid termineid kasutatakse sageli lõdvalt. Seda ei tohiks teha.

- Deterministlik veto: PLC-loogika, mis hindab välist või AI-genereeritud päringut igal skannimisel ja blokeerib ebaturvalise täitmise selgete piiride, lubatavustingimuste ja rikkereeglite kaudu. - Kihiline kaitse: arhitektuurne eraldatus AI/IT-funktsioonide vahel, mis soovitavad või optimeerivad, ning PLC/OT-funktsioonide vahel, mis kontrollivad, täidavad ja jõustavad ohutuspiire. - Simulatsioonivalmidus (Simulation-Ready): võime jälgida I/O põhjuslikkust, jälgida ebanormaalset käitumist, süstida rikkejuhtumeid, diagnoosida juhtimisreaktsiooni ja muuta loogikat virtuaalses keskkonnas enne füüsilise riistvara puudutamist.

„Simulatsioonivalmidus“ ei ole lühend sõnast „oskab kirjutada redelloogika süntaksit“. See tähendab, et insener suudab tõestada käitumist pinge all. Süntaks on odav; juurutatavus ei ole.

Õige kihiline kaitsearhitektuur annab AI-le mõju ilma sellele kontrollimatut volitust andmata.

Eraldus peaks olema selge:

### 1. kiht: AI-agent tajumiseks või optimeerimiseks

See kiht võib:

• hinnata nõudlust,
• soovitada seadeväärtusi,
• soovitada marsruutimist,
• klassifitseerida töötingimusi,
• genereerida kavandiloogikat või operaatori juhiseid.

See kiht peaks kirjutama ainult vahemälusiltidesse, sõnumistruktuuridesse või järelevalvepäringu muutujatesse. See ei tohiks kirjutada otse füüsilistesse väljunditesse või ohutusmällu.

### 2. kiht: Deterministlik veto PLC-s

See kiht hindab AI-päringut fikseeritud insenerireeglite suhtes, nagu:

• maksimaalsed/minimaalsed lubatud väärtused,
• kehtivad masinaolekud,
• blokeeringud,
• lubatavustingimused,
• järjestuse sammu nõuded,
• alarmi- ja väljalülitustingimused,
• muutumiskiiruse piirangud.

Siin muutub käsk kas vastuvõetavaks, muudetuks või tagasilükatuks.

### 3. kiht: Juhtmega või sertifitseeritud ohutuse täitmise tee

See kiht sisaldab vastavalt vajadusele:

• hädaseiskamisahelaid,
• ohutusreleesid,
• ohutus-PLC ülesandeid,
• kontaktoreid,
• STO-ahelaid,
• kaitseblokeeringuid,
• sõltumatuid väljalülitusfunktsioone.

See kiht peab jääma väljapoole AI mälukaarti ja väljapoole igasugust tarkvaralist järelevalveoptimismi. Juhtmega ohutus on olemas, sest tarkvara arendab aeg-ajalt arvamusi.

Te programmeerite veto, sundides iga AI-nõutud käsu läbi selge kontrolliloogika, enne kui see saab mõjutada lõplikku kontrollmuutujat.

Peamine disainipõhimõte on lihtne: AI-päringud on ettepanekud, mitte väljundid.

Seadeväärtuse piiraja rakendamine

Piirväärtuste piiraja takistab võimatute või ebaturvaliste väärtuste jõudmist täiturmehhanismi käsuni.

Kasutage sellist struktuuri:

Struktureeritud teksti / redelloogika tõlke näide:

IF AI_Requested_Speed > Max_Allowable_Speed THEN Actual_Drive_Speed := Max_Allowable_Speed; Set Alarm_AI_Hallucination_Over_Speed; ELSIF AI_Requested_Speed < Min_Allowable_Speed THEN Actual_Drive_Speed := Min_Allowable_Speed; Set Alarm_AI_Hallucination_Under_Speed; ELSE Actual_Drive_Speed := AI_Requested_Speed; END_IF;

See on minimaalne muster, mitte valmis arhitektuur.

Tootmisele orienteeritud rakendus lisab tavaliselt:

- režiimi kontroll: aktsepteerige AI-päringuid ainult automaatrežiimis - oleku lubatavustingimus: aktsepteerige päringuid ainult siis, kui masin on kehtivas järjestuse olekus - ROC-piiraja: piirake muutust skannimise või sekundi kohta - kvaliteedibitt: lükake tagasi aegunud, kehtetud või usaldamatud ülesvoolu andmed - ajalõpu käitlemine: pöörduge tagasi varuväärtuse juurde, kui päringuvoog katkeb - alarmi lukustamine ja operaatori nähtavus: tehke tagasilükkamine nähtavaks ja ülevaadatavaks

Täielikum juhtimistee näeb sageli välja selline:

1. Võta vastu `AI_Requested_Speed`
2. Valideeri allika kvaliteet ja värskus
3. Kinnita `System_Auto = TRUE`
4. Kinnita, et kõik lubatavustingimused on tõesed
5. Piira insenertehnilise miinimumi/maksimumini
6. Rakenda ROC-piirang
7. Kirjuta `Actual_Drive_Speed_Command`
8. Väljalülitus või blokeerimine, kui ohutusahel on avatud

Mida peaks redelloogika jõustama enne AI-käsu edastamist?

PLC peaks jõustama samu asju, mida ettevaatlik kasutuselevõtu insener küsiks enne seadmete pingestamist:

• Kas masin on õiges režiimis?
• Kas järjestus on õiges etapis?
• Kas kõik lubatavustingimused on täidetud?
• Kas tagasisided on terved?
• Kas nõutud väärtus on füüsiliste piiride piires?
• Kas nõutud muutus on selle protsessi jaoks usutav?
• Kas on aktiivseid väljalülitus- või ohutustingimusi?

See viimane küsimus kipub olema olulisem kui arhitektuuriskeem.

Peamine hädaseiskamisahel

Peamine hädaseiskamisahel peab asuma väljaspool AI volituste piiri, kuna hädaseiskamiskäitumine ei saa sõltuda järelduse kvaliteedist, võrgu ajastusest või järelevalvetarkvara olekust.

Praktikas:

• Hädaseiskamisteekond peaks olema juhtmega ühendatud või käsitletud sertifitseeritud ohutusfunktsioonis vastavalt rakenduse nõuetele.
• AI-süsteem ei tohiks hädaseiskamisolekusse kirjutada ega seda summutada.
• Standardne juhtimisülesanne võib hädaseiskamisolekut jälgida, kuid see ei tohiks olla selle ainus valvur.
• Iga AI-nõutud käsk peab kahjutult kokku kukkuma, kui hädaseiskamisahel avaneb.

Kasulik reegel on järgmine: kui võrgu tõrge, mudeli viga või parseri rike suudab liikumist lubatuna hoida, ei ole disain valmis.

Te testite seda, süstides ebanormaalseid käske ja tõestades, et PLC reaktsioon jääb nendes tingimustes piiratuks, jälgitavaks ja õigeks.

Siin peatuvad paljud meeskonnad liiga vara. Puhas nominaalne käivitamine ei tõesta peaaegu midagi.

Vähemalt testige neid juhtumeid:

• AI-päringud üle maksimaalse lubatud väärtuse
• AI-päringud alla minimaalse lubatud väärtuse
• järsud sammmuutused väljaspool ohutut kaldemäära
• käsud, mis on antud vales masinaolekus
• käsud, mis on antud ajal, kui lubatavustingimus on väär
• aegunud või külmunud ülesvoolu väärtused
• võnkuvad või mürarikkad päringusignaalid
• hädaseiskamine või väljalülituse aktiveerimine aktiivse AI-päringu ajal

Iga juhtumi puhul kontrollige:

• lõplikku täiturmehhanismi käsku,
• alarmi käitumist,
• järjestuse käitumist,
• operaatori nähtavust,
• taastumiskäitumist pärast rikke kõrvaldamist.

Veto, mis piirab õigesti, kuid jätab järjestuse ebakõlalisse olekusse, on vaid pool lahendust.

OLLA Lab on siin kasulik kui piiratud valideerimiskeskkond, kus insenerid saavad süstida halbu käske, jälgida seadmete reaktsiooni ja muuta redelloogikat enne, kui kaasatakse reaalne riistvara.

See positsioneerimine on oluline. OLLA Lab ei ole ohutuse sertifitseerija ega asenda ametlikku valideerimist sihtplatvormil. See on praktiline keskkond suure riskiga kasutuselevõtuloogika harjutamiseks kontrollitud viisil.

OLLA Labis saavad insenerid:

• luua redelloogikat veebipõhises redaktoris,
• käivitada simulatsiooni ilma füüsilise riistvarata,
• jälgida silte, I/O-d, analoogväärtusi ja PID-ga seotud muutujaid,
• kasutada stsenaariumipõhiseid seadmemudeleid,
• võrrelda redeli olekut simuleeritud masina käitumisega,
• muuta loogikat pärast rikkejuhtumi jälgimist.

Selle artikli kasutusjuhtumi jaoks on asjakohane töövoog lihtne:

1. Loo vahesilt, näiteks `AI_Requested_Speed`
2. Suuna see silt läbi piiraja ja lubatavustingimuste loogika
3. Jälgi tulemuseks olevat `Actual_Drive_Speed_Command`
4. Süsti ebanormaalseid väärtusi või ebastabiilseid mustreid
5. Kinnita, et simuleeritud mootor, pump või klapi mudel ei ületa kunagi ohutuid piire
6. Vaata üle alarmid ja muuda loogikat

Siin muutub OLLA Lab operatiivselt kasulikuks. Te ei saa vastutustundlikult testida hallutsinatsioonilist 200% klapi avamise käsku reaalprotsessil, et näha, mis juhtub. Uudishimu on väärtuslik; painutatud riistvara on kallis.

Mida „Simulatsioonivalmidus“ praktikas tähendab

Insener on simulatsioonivalmis, kui ta suudab virtuaalses keskkonnas teha kõike järgmist:

• jälgida põhjus-tagajärg seost sisendist väljundini,
• jälgida, kas lubatavustingimus või blokeering blokeeris täitmise,
• tuvastada täpne redelipulk või tingimus, mis reaktsiooni tekitas,
• võrrelda juhtimisloogika olekut simuleeritud seadme olekuga,
• süstida riket ja selgitada sellest tulenevat käitumist,
• muuta loogikat ja testida uuesti, kuni reaktsioon on piiratud ja korratav.

See on künnis, mis on kasutuselevõtu ettevalmistamisel oluline. Mitte „oskab paigutada taimeri juhise“, vaid „oskab tõestada, miks masin liikus või ei liikunud“.

Õige artefakt on kompaktne insenertehniliste tõendite kogum, mitte ekraanipiltide galerii.

Kasutage seda struktuuri:

Määratlege, mida vastuvõetav käitumine tähendab jälgitavates terminites: lubatud vahemik, kehtivad olekud, oodatud alarmi reaktsioon, väljalülituskäitumine ja taastumiskäitumine.

Dokumenteerige täpne ebanormaalne sisend: ülekirjutamise päring, kehtetu oleku käsk, aegunud silt, mürarikas signaal või hädaseiskamine liikumise ajal.

Salvestage, mis loogikas muutus: lisatud piiraja, karmistatud lubatavustingimus, sisse viidud ajalõpp, lukustatud alarm, kohandatud ROC-piirang.

1. Süsteemi kirjeldus Määratlege masin või protsessielement, kontrollitav muutuja, töörežiimid ja asjakohane ohutuspiir.
2. „Õige“ operatiivne määratlus
3. Redelloogika ja simuleeritud seadme olek Näidake juhtimisloogikat koos simuleeritud täiturmehhanismi või protsessi reaktsiooniga, et põhjuslik ahel oleks nähtav.
4. Süstitud rikkejuhtum
5. Tehtud muudatus
6. Õppetunnid Märkige, mida rike paljastas ja milline disainireegel sellest nüüd tuleneb.

See loob tõendusmaterjali, mida teine insener saab üle vaadata, vaidlustada ja reprodutseerida. See on standard, mille poole tasub püüelda.

Kõige levinum viga on lubada AI-l valideerimiskiht vahele jätta.

Muud korduvad vead on:

• AI väljundi kirjutamine otse täiturmehhanismi käsusiltidesse,
• AI keskmise jõudluse käsitlemine ohutusargumendina,
• aegunud andmete tuvastamise unustamine,
• olekupõhiste lubatavustingimuste väljajätmine,
• HMI-alarmidele lootmine kõvade täitmisplokkide asemel,
• liiga suure usalduse panemine simulatsiooni ilma platvormispetsiifilise lõpliku valideerimiseta,
• genereeritud redeli ja valideeritud redeli segiajamine.

Genereeritud redelipulk ei ole tõestatud redelipulk. Tööstusjuhtimist reguleerib endiselt see, mida masin tegelikult teeb.

Õige muster ei ole „AI juhib tehast“. Õige muster on „AI võib soovitada, kuid PLC otsustab ja ohutuskiht saab ikkagi öelda ei“.

Deterministlik veto on insenertehniline mehhanism, mis muudab selle piiri reaalseks. See muudab piiramatud päringud piiratud juhtimiskäitumiseks piirajate, lubatavustingimuste, blokeeringute ja sõltumatute ohutusfunktsioonide kaudu. Nii hoiate tõenäosusliku tarkvara füüsiliseks intsidendiks muutumast.

OLLA Lab sobib sellesse töövoogu kui harjutus- ja valideerimiskeskkond. See võimaldab inseneridel harjutada ebamugavaid juhtumeid – halvad seadeväärtused, kehtetud olekud, mürarikkad signaalid, ebaõnnestunud lubatavustingimused, hädaseiskamised – ilma reaalset seadet testpingina kasutamata. See on usaldusväärsem tee kasutuselevõtu otsustusvõimeni kui süntaksi päheõppimine ja lootmine, et esimene tõeline rike on õrn.

See artikkel on koostatud Ampergon Vallis Lab inseneride poolt, keskendudes tööstusautomaatika ja tehisintellekti integreerimise ohutusküsimustele.

Artikli tehnilised väited põhinevad IEC 61508 ja ISO 13849 standardite üldistel põhimõtetel ning OLLA Lab simulatsioonikeskkonna 2026. aasta I kvartali katseandmetel.

- IEC 61131-3: Programmeeritavad kontrollerid — Osa 3: Programmeerimiskeeled - IEC 61508 ülevaade (funktsionaalne ohutus) - NIST AI riskijuhtimise raamistik (AI RMF 1.0) - Digitaalne kaksik tootmises: kategooriline kirjanduse ülevaade ja klassifikatsioon (IFAC, DOI) - Digitaalne kaksik tööstuses: tipptasemel ülevaade (IEEE, DOI)