Kuidas tõestada, et tehisintellekti loodud redelloogika vastab IEC 61508 3. osa nõuetele

Tehisintellekti loodud redelloogika hindamiseks vastavalt IEC 61508 3. osale peaksid insenerid testima deterministlikku käitumist, reageerimist riketele ja jälgitavust simulatsiooni, mitte ainult viipade (prompts) kaudu. OLLA Lab pakub piiratud valideerimiskeskkonda, kus loogikat saab katsetada realistliku masina käitumise suhtes, jälgida rikketingimustes ja dokumenteerida auditeerimiseks valmis tõendusmaterjalina.

Tehisintellekti loodud redelloogika ei kuku auditil läbi seetõttu, et see on "tehisintellekt". See kukub läbi, kuna funktsionaalne ohutus nõuab deterministlikku, jälgitavat ja kontrollitavat käitumist, samas kui LLM-i väljund on tõenäosuslik, kuni insener selle piiritleb ja tõestab.

Hiljutine Ampergon Vallis'e siseanalüüs näitas, et 68% 500-st tehisintellekti loodud mootori juhtimise rutiinist ei läbinud piiratud prognoositavuse kontrolli simuleeritud anduri kadumise tingimustes, kuni insener need käsitsi piiritleb [Metoodika: n=500 genereeritud mootori käivitamise ja lubavate/blokeerivate rutiinide testimine OLLA Lab simulatsioonis, võrdlusalus = deterministlikud vastuvõtukriteeriumid, mis on tuletatud eelnevalt määratletud järjestusest ja rikkereageerimise ootustest, ajavahemik = jaanuar-märts 2026]. See mõõdik toetab ühte kitsast punkti: piiritlemata tehisintellekti väljund rikub simulatsioonis sageli prognoositavat rikkekäitumist. See ei toeta väidet kogu PLC-koodi, kõigi tarnijate või ametliku sertifitseerimise tulemuste kohta.

See eristus on oluline. Viipa (prompt) ei saa auditeerida. Auditeerida saab ainult saadud loogika deterministlikku täitmist simuleeritud füüsilistes piirangutes. Süntaks on odav; juurutatavus mitte.

Tehisintellekti loodud loogika kukub IEC 61508 3. osa audititel läbi, kuna standard tegeleb tarkvara käitumise süsteemse terviklikkusega, mitte sellega, kui kiiresti kood loodi. IEC 61508-3 nõuab, et tarkvara oleks määratletud, struktureeritud, kontrollitud ja põhjendatud viisil, mis toetab prognoositavat toimimist määratletud tingimustes ja määratletud riketes.

Põhikonflikt on lihtne. LLM-id genereerivad treeningandmete mustrite põhjal tõenäolisi järgmisi tokeneid. Ohutustarkvara peab teadaolevates protsessitingimustes tootma piiratud ja selgitatavaid olekusiirdeid. Üks on tõenäosuslik genereerimine; teine on deterministlik vastutus.

Seetõttu ei ole viipade ajalugu vastavuse tõendusmaterjal. Viip võib selgitada kavatsust, kuid see ei tõesta skannimistsükli käitumist, rikete käsitlemist, ohutusseisundisse üleminekut ega ajastuse vastavust.

Praktilised tõrkeviisid on juhtimisinseneridele tuttavad:

• lubavad signaalid, mis aktiveeruvad õigesti, kuid ei deaktiveeru deterministlikult
• lukustatud bitid, mis säilivad ebanormaalsetes taaskäivitustingimustes ilma selge lähtestamisloogikata
• häirete käsitsemine, mis tuvastab halva väärtuse, kuid ei sunni ohutut reageerimist
• analoogvõrdlused ilma vahemikust väljaspool oleva käsitsemiseta
• samm-loogika, mis töötab "õnnelikus rajas", kuid puruneb asünkroonsete sisendite korral
• ülemäära keerulised redelstruktuurid, mis varjavad kontrollimist

IEC 61508 kasutab elutsükli tegevustes erinevat terminoloogiat, kuid insenertehniline nõudlus on järjepidev: tarkvara käitumine peab olema põhjendatud, testitav ja ohutuseesmärgiga jälgitav. Tehisintellekt võib loogikat koostada. See ei saa süsteemset võimekust entusiasmi kaudu pärida.

Siin muutub OLLA Lab operatiivselt kasulikuks. Selle roll ei ole tehisintellekti koodi sertifitseerimine. Selle roll on pakkuda riskipiiratud keskkonda, kus insenerid saavad käivitada genereerimise-valideerimise tsükli, jälgida skannimiskäitumist, esile kutsuda rikkeid, võrrelda redeli olekut simuleeritud seadme olekuga ja dokumenteerida, mida loogika tegelikult teeb.

"Simulatsioonivalmidus" tähendab, et insener suudab juhtimisloogikat tõestada, jälgida, diagnoosida ja karastada realistliku protsessikäitumise vastu enne, kui see jõuab reaalprotsessini.

See määratlus on operatiivne, mitte püüdluslik. Simulatsioonivalmidusega insener suudab:

• määratleda, milline näeb välja õige käitumine enne testimise algust
• käivitada loogikat masina või protsessi mudeli, mitte eelduste vastu
• jälgida I/O-d, sisemisi bitte, analoogväärtusi ja järjestuse olekut täitmise ajal
• sisestada ebanormaalseid tingimusi, nagu anduri kadumine, aegunud tagasiside, toite tsükliline sisse-välja lülitamine ja lubava signaali kadumine
• tuvastada, kus redeli olek erineb eeldatavast seadme käitumisest
• muuta loogikat ja testida uuesti, kuni käitumine on piiratud ja selgitatav

See on tõeline erinevus redeli süntaksi ja kasutuselevõtu otsustusvõime vahel. Paljud inimesed oskavad redelipulka joonistada. Vähemad oskavad selgitada, miks pump peaks pärast ebaõnnestunud tõestust taaskäivitamisest keelduma või miks lubav signaal peab pärast riket käivituskäsu tingimusteta vetostama.

Alltoodud "16 sammast" on praktiline insenertehniline süntees, mis on tuletatud IEC 61508-3 tarkvara ohutuse elutsükli ootustest, eriti standardi rõhuasetusest korrektsusele, kontrollitavusele, rikete vältimisele ja distsiplineeritud disainile. Need ei ole standardist sõna-sõnalt võetud loetelu. Need on tööstruktuur hindamaks, kas tehisintellekti loodud redelloogika liigub auditeeritava ranguse suunas.

### 1. rühm: Arhitektuur ja determinism

Kõik määratletud töörežiimid, käivitusolekud, seiskamisolekud ja ebanormaalsed olekud on käsitletud.

• 1. Täielikkus

Loogika vastab kavandatud juhtimisfilosoofiale ja ohutusnõuetele.

• 2. Korrektsus

Täitmiskäitumine on samades tingimustes piiratud ja korratav.

• 3. Prognoositavus

Disain väldib sisemisi vastuolusid, soovimatut lukustumist, ummikseisu sarnaseid järjestuse seiskumisi ja ebastabiilseid olekuinteraktsioone.

• 4. Sisemiste rikete puudumine

Keerukus on minimeeritud, et loogika jääks ülevaadatavaks ja testitavaks. Tehisintellekt ebaõnnestub siin sageli, luues keeruka loogika, mis kompileerub, kuid mida on raske põhjendada.

• 5. Lihtsus

### 2. rühm: Rikkekindlus ja reageerimine

Loogika käsitleb kehtetuid, mürarikkaid, puuduvaid või vahemikust väljas olevaid sisendeid ilma määratlemata käitumiseta.

• 6. Tugevus (Robustsus)

Programm tunneb aktiivselt ära rikkis andurid, puuduvad tõestussignaalid, halvad analoogväärtused või side katkemise, kus see on asjakohane.

• 7. Rikke tuvastamine

Ohtlikud väljundid eemaldatakse deterministliku veto-loogika abil, kui ohutustingimusi rikutakse.

• 8. Ohutusseisundisse üleminek

Mittekriitilised funktsioonid ebaõnnestuvad kontrollitud viisil, säilitades samal ajal olulise ohutu käitumise.

• 9. Graatsiline degradeerumine

Muutujad, säilitatud olekud ja kriitilised väärtused on kaitstud soovimatu rikkumise või väärkasutuse eest.

• 10. Andmete terviklikkus

Loogika reageerib nõutava protsessi ohutusaja jooksul ega tugine piiramatutele täitmise eeldustele.

• 11. Ajastuse piirangud

### 3. rühm: Kontrollimine ja jälgitavus

Iga ohutuse seisukohalt oluline redelipulk, blokeering, häire või järjestuse samm kaardistatakse tagasi määratletud nõude või ohu kontrollimise juurde.

• 12. Jälgitavus

Funktsioonid on jaotatud nii, et neid saab eraldi üle vaadata ja testida.

• 13. Modulaarsus

Loogikat saab katsetada määratletud stsenaariumide korral ja näidata, et see vastab eeldatavatele tulemustele.

• 14. Kontrollitavus

Tulevased insenerid saavad koodist aru, seda tõrkeotsida ja ohutult muuta.

• 15. Hooldatavus

Kaitset volitamata sundimise või ohtliku muutmise eest arvestatakse seal, kus tarkvara terviklikkus kattub küberturvalisuse praktikaga, sealhulgas IEC 62443 muredega.

• 16. Turvateadlik kontrolli terviklikkus

Need sambad on olulised, sest IEC 61508-le ei avalda muljet kood, mis tavaliselt töötab. Ohutustarkvara hinnatakse määratletud käitumise järgi määratletud stressi korral.

Auditeerimiseks valmis artefakt ei ole ekraanipilt, viipade logi ega ebamäärane testmärkus. Selles kontekstis tuleks seda määratleda kui ajatempliga varustatud simulatsiooniaruannet, mis võrdleb kavandatud juhtimisjärjestuse käitumist täheldatud olekumuutustega esilekutsutud rikketingimuste ajal.

See määratlus hoiab tõendusmaterjali seotuna täitmisega. See hoiab ka tooteväited piiratuna. OLLA Lab saab toetada selle tõendusmaterjali tootmist, pakkudes simulatsiooni, muutujate nähtavust, stsenaariumi struktuuri ja realistlikke masinamudeleid. See ei ole ise vastavusasutus.

Kasulik auditeerimiseks valmis artefakt peaks sisaldama:

1. Süsteemi kirjeldus Millist seadet või protsessi juhitakse, sealhulgas peamine I/O, järjestuse kavatsus ja töörežiimid.
2. Õige käitumise operatiivne määratlus Eeldatav käitumine tavatöös ja ebanormaalsetes tingimustes.
3. Redelloogika ja simuleeritud seadme olek Testitav redeliloogika ja vastav masina või protsessi reaktsioon simulatsioonis.
4. Sisestatud rikkejuhtum Täpne ebanormaalne tingimus, mis on sisse viidud, näiteks juhtme katkemine, ebaõnnestunud tõestus, analoogväärtus vahemikust väljas või toite taastumine.
5. Tehtud muudatus Mis muutus loogikas pärast rikke täheldamist.
6. Õppetunnid Mida rike paljastas eelduste, järjestuse disaini, blokeeringute või hooldatavuse kohta.

See kuueosaline struktuur toodab insenertehnilist tõendusmaterjali, mitte ekraanipiltide galeriid. Audiitorid ja vanemülevaatajad vajavad otsuste tegemise rada. Samuti inimesed, kes koodi hiljem pärivad.

Dokumentatsioon peaks olema valideerimise kõrvalsaadus, mitte tagantjärele tehtav koristusharjutus. Kui testimisprotsess on õigesti struktureeritud, saab tõendusmaterjali paketi koostada töövoost endast.

Praktiline töövoog näeb välja selline:

1. Määratlege kavandatud järjestus ja ohutusreaktsioon Märkige, mida seade peaks tegema töö-, seiskamis-, käivitus-, väljalülitus- ja rikketingimustes.
2. Koostage või importige redelloogika See võib sisaldada tehisintellekti loodud mustandloogikat, kuid mustand on alles lähtepunkt.
3. Käivitage loogika simulatsioonirežiimis Käivitage programm, jälgides samal ajal sisendeid, väljundeid, sisemisi silte, analoogväärtusi ja järjestuse bitte.
4. Sisestage rikkeid tahtlikult Kasutage muutujate juhtelemente, et simuleerida juhtmete katkemist, ebaõnnestunud piiranguid, aegunud tõestusi, lubava signaali kadumist, analoogekskursioone või taaskäivitustingimusi.
5. Võrrelge eeldatavat ja täheldatud käitumist Salvestage, kas simuleeritud seade siseneb õigesse ohutusseisundisse ja kas sisemine loogika vastab juhtimisfilosoofiale.
6. Muutke loogikat ja testige uuesti Lisage vajadusel deterministlikud vetod, lähtestamise käsitsemine, rikete lukustamine või järjestuse kaitsed.
7. Eksportige testikirje Säilitage stsenaariumi eesmärk, rikkejuhtum, täheldatud olekumuutused ja lõplik aktsepteeritud loogika käitumine.

OLLA Labis toetavad seda töövoogu redeliredaktor, simulatsioonirežiim, muutujate paneel, stsenaariumi struktuur ja digitaalse kaksiku kontekst. Põhipunkt ei ole see, et platvorm tegeleb vastavusega. Põhipunkt on see, et see pakub deterministlikku vaatluskeskkonda, kus tarkvara käitumist saab testida realistlike protsessitingimuste suhtes.

Kompaktne näide deterministlikust veto-loogikast on allpool:

[Keel: Redeldiagramm (Ladder Diagram)] // Näide: deterministlik veto, mis tühistab genereeritud käivitusloogika // Kui AI_Run_Cmd on tõene, kuid Safety_Permissive langeb, // peab Motor_Out tingimusteta lukust lahti tulema.

|---[ AI_Run_Cmd ]----[ Safety_Permissive ]-----------( Motor_Out )---| | | |---[/Safety_Permissive ]--------------------------------(U Motor_Out)-|

Oluline omadus siin ei ole stilistiline elegants. See on see, et lubava signaali kadumisel on selge, testitav ja tingimusteta tagajärg.

OLLA Lab valideerib käitumist, mitte sertifitseerimise staatust. See on õige piir.

Süsteemne võimekus IEC 61508-s sõltub distsiplineeritud arendus- ja kontrollimistavadest, mis vähendavad süsteemseid rikkeid. Veebipõhine simulaator ei saa süsteemset võimekust iseenesest anda, kuid see võib pakkuda keskkonda, mis on vajalik jälgimaks, kas rakendatud loogika käitub viisil, mis on kooskõlas nende distsiplineeritud tavadega.

Praktiliselt toetab OLLA Lab seda, võimaldades inseneridel:

• koostada redelloogikat standardsete juhtimiselementidega, sealhulgas kontaktid, mähised, taimerid, loendurid, komparaatorid, matemaatilised funktsioonid ja PID-juhised
• täita loogikat simulatsioonis ilma füüsilise riistvarata
• jälgida ja manipuleerida muutujaid, I/O-d, analoogväärtusi ja PID-ga seotud parameetreid
• testida loogikat realistlike tööstuslike stsenaariumide, mitte abstraktsete mänguprobleemide suhtes
• võrrelda redeli olekut 3D- või WebXR-seadme käitumisega, kui see on saadaval
• harjutada ebanormaalseid tingimusi, mida oleks ohtlik või kallis esile kutsuda reaalses tehases

See on oluline, sest matemaatiline üksuse korrektsus ei ole tööstusliku juhtimise jaoks piisav. Redelipulk võib olla süntaktiliselt kehtiv ja siiski protsessis ebaõnnestuda. Digitaalse kaksiku valideerimine on kasulik just seetõttu, et see paljastab tarkvara oleku ja simuleeritud füüsilise oleku vahelise interaktsiooni.

Operatiivselt tähendab digitaalse kaksiku valideerimine siin redelloogika käivitamist realistliku masina või protsessi mudeli vastu ja jälgimist, kas eeldatav seadme käitumine, järjestuse edenemine, blokeeringud, häired ja ohutusseisundisse üleminekud toimuvad nii normaalsetes kui ka rikketingimustes.

Realistlikud stsenaariumid paljastavad juhtimiseeldused, mida üldised harjutused varjavad. Mootori käivitamise õpetus võib õpetada "seal-in" loogikat. See ei õpeta tavaliselt ebaõnnestunud tõestust, taaskäivitamise keelamist, juht-järgija (lead-lag) arbitraaži, analooghäire surnud tsooni või seda, mis juhtub, kui operaatori käsk põrkub väljalülitustingimusega.

Seetõttu on stsenaariumi kontekst oluline. OLLA Labi dokumenteeritud eelseadistused vee, reovee, HVAC, tootmise, ladustamise, toidu ja joogi, kommunaalteenuste, keemia ja farmaatsia valdkonnas on kasulikud mitte seetõttu, et neid on palju, vaid seetõttu, et need sunnivad loogika operatiivsesse konteksti.

Erinevad stsenaariumid õpetavad erinevaid ohutus- ja kasutuselevõtumustreid:

• Pumpamissüsteemid õpetavad juht-järgija rotatsiooni, madala taseme kaitset, ebaõnnestunud käivitamise tuvastamist ja ületäitumise riski.
• Konveierid ja pakendamisliinid õpetavad ummistuste tuvastamist, järjestuse lubavaid signaale ja koordineeritud seiskamiskäitumist.
• HVAC ja õhukäitlussüsteemid õpetavad blokeeringuid, ventilaatori tõestust, siibri asendi loogikat ja häirete käsitsemist.
• Protsessiseadmed (skids) õpetavad analooglävesid, PID-interaktsiooni, väljalülitusloogikat ja kontrollitud seiskamist.
• Vee- ja reoveesüsteemid õpetavad taseme juhtimist, töötsüklite vahetamist, häirete prioriseerimist ja protsessi järjepidevust seadmete rikete korral.

Siin aitavad ka juhendatud koostamisjuhised. Kiirkäivitused, I/O-kaardid, juhtimisfilosoofia märkused, blokeeringud, siltide sõnastikud ja kontrollimisetapid annavad insenerile struktureeritud aluse käitumise tõestamiseks. See on kasulikum kui kellegi viskamine tühja redaktorisse ja selle realismiks nimetamine.

Rikete testimine peaks olema kavandatud jälgitava protsessiriski, mitte selle ümber, mida tehisintellekt juhtus genereerima. Õige küsimus ei ole, kas kood töötab, vaid mis juhtub, kui protsess valetab, seiskub või kaob?

Distsiplineeritud rikketestide komplekt peaks sisaldama vähemalt:

• lubava signaali kadumine aktiivse töö ajal
• ebaõnnestunud tagasiside või tõestussignaal
• analoogsignaal kõrge, madal, külmunud või vahemikust väljas
• toite tsükliline sisse-välja lülitamine või taaskäivitamine säilitatud bittidega
• asünkroonne operaatori käsk järjestuse ülemineku ajal
• side katkemine või aegunud andmed, kus see on asjakohane
• andurite erimeelsused, kus on olemas koondavad või kinnitavad signaalid

Iga juhtumi puhul peaks insener määratlema:

• eeldatava ohutu reaktsiooni
• maksimaalse vastuvõetava reageerimisaja
• jälgitavad sildid ja väljundid
• läbimise, läbikukkumise ja muutmise kriteeriumid

OLLA Labi muutujate paneel on siin kasulik, kuna see võimaldab sisendite otsest manipuleerimist ja oleku nähtavust täitmise ajal. See toetab rikete sisestamist, siltide jälgimist ja korratavat kordustestimist. Jällegi, väärtus on piiratud: see on kontrollitud valideerimiskeskkond kõrge riskiga kasutuselevõtu ülesannete jaoks, mitte asendus ametlikule kohapealsele vastuvõtule, riistvara kontrollimisele või pädevusele reaalprotsessis.

Otsusepakett on koostatud tõestusmaterjal, mis selgitab, miks lõplik loogika on vastuvõetav. Selles artiklis tuleks agentset orkestreerimist mõista kitsalt kui inseneri tegevust genereeritud loogika juhendamisel, selle testimisel määratletud stsenaariumide vastu, ohtliku käitumise tagasilükkamisel ja aktsepteeritud muudatuste taga oleva põhjenduse säilitamisel.

Kaitstav otsusepakett peaks sisaldama:

• juhtimiseesmärki
• ohutusega seotud nõudeid või ohtude leevendamist
• redelloogika muudatuste ajalugu
• kasutatud simulatsioonistsenaariumi
• sisestatud rikkejuhtumeid
• täheldatud tulemusi
• aktsepteeritud lõplikku käitumist
• lahendamata eeldusi või piiranguid
• allkirjastamise alust järgmisse ülevaatusetappi liikumiseks

OLLA Lab panustab sellesse paketti, andes struktuuri koostamise-kontrollimise tsüklile juhendatud stsenaariumide, muutujate nähtavuse, simulatsiooni täitmise ja digitaalse kaksiku konteksti kaudu. See aitab inseneridel toota tõendusmaterjali, mida saab üle vaadata. See on kasulik lävi.

Tehisintellekt võib kiirendada mustandite genereerimist, kuid see ei vähenda tõendamiskoormust. Ohutusega seotud tarkvaras on kiirus ilma tõendusmaterjalita vaid kiirem tee kontrollimata loogikani.

Praktilised reeglid on lihtsad:

• käsitlege genereeritud redelloogikat mustandina, mitte kunagi aktsepteeritud tõena
• määratlege õige käitumine enne testimist
• valideerige protsessikäitumise, mitte ainult redelipulga välimuse vastu
• sisestage rikkeid meelega
• säilitage ajatempliga tõendusmaterjal eeldatava ja täheldatud reaktsiooni kohta
• muutke determinismi, loetavuse ja jälgitavuse nimel
• hoidke iniminsener vastutavana aktsepteerimise eest

See on tõeline genereerimise-valideerimise tsükkel. See on vähem glamuurne kui väited, et tehisintellekt kirjutab PLC-koodi, ja kasulikum ohutustöös.

- Lugege artiklit "The Deterministic Veto: Programming Safety PLCs", et saada põhjalikum ülevaade kõvadest blokeeringutest ja tingimusteta ohutu oleku loogikast.

• Minge tagasi "Future of Automation Hub" juurde, et saada lisateavet vastupidavate inseneritöövoogude ja simulatsioonipõhise valideerimise kohta.
• Vaadake üle "EU AI Act High-Risk Compliance", kui teie automatiseerimise töövoog peab vastama ka tekkivatele tehisintellekti juhtimise nõuetele.
• Kas olete valmis rikkekäitumist otse testima? Avage OLLA Labis "Safety Interlock Scenario" ja valideerige loogikat simuleeritud masinamudeli vastu.

- IEC 61131-3: Programmeeritavad kontrollerid — 3. osa: 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 (IEEE, DOI)

Ampergon Vallis Labi insenerimeeskond, kes keskendub tööstusliku automatiseerimise ohutuse ja tehisintellekti integreerimise metoodikatele.

Artikkel on koostatud tuginedes IEC 61508-3 standardi nõuetele ja Ampergon Vallis'e 2026. aasta siseanalüüsi andmetele. Kõik tehnilised soovitused on valideeritud OLLA Labi simulatsioonikeskkonnas.