Kuidas koostada eksporditav otsustuspakett tööstuslike AI-auditite jaoks

Eksporditav otsustuspakett on dokumenteeritud tõendusmaterjal selle kohta, et pädev insener on enne juurutamist tehisintellektiga toetatud juhtimisloogika üle vaadanud, testinud ja korrigeerinud. Standardi IEC 61508 ja EL-i tehisintellekti määruse kohaselt ei ole keskne küsimus selles, kas tehisintellekt suudab koodi luua. Küsimus on selles, kas organisatsioon suudab tõestada kvalifitseeritud inimjärelevalvet koos jälgitavate valideerimisdokumentidega.

Tööstuslikud AI-auditid ei kuku tavaliselt läbi seetõttu, et mudel kirjutas halva koodirea. Need kukuvad läbi, kuna organisatsioon ei suuda tõestada, et pädeval inimesel oli volitus, väljaõpe ja tõendusmaterjalide ahel, et tuvastada vigane koodirida enne, kui see jõudis reaalajas toimuva protsessini.

See eristus on oluline nii IEC 61508-1 punkti 6 alusel, mis nõuab ohutusega seotud süsteemide elutsüklis osalevate isikute pädevust, kui ka EL-i tehisintellekti määruse artikli 14 alusel, mis nõuab kõrge riskitasemega tehisintellektisüsteemide puhul tõhusat inimjärelevalvet. Tehisintellekt võib luua väljundit, kuid see ei saa kanda vastutust, omada pädevust ega anda allkirjastamisvolitusi.

Ampergon Vallis Metric: Hiljutises 120 juhtimisinseneri hõlmanud sisemises baashindamises, kus kasutati OLLA Lab tarkvara, ebaõnnestusid 41% virtuaalse kasutuselevõtu testidest osalejatel, kes aktsepteerisid tehisintellekti loodud redelloogikat ilma struktureeritud valideerimiseta, kuna puudusid lubavad tingimused, esinesid ebaturvalised olekueeldused või puudulik veakäsitlus. Metoodika: n=120; ülesande määratlus = tehisintellektiga toetatud redelloogika ülevaatus ja kasutuselevõtt ohumärgistusega simulatsioonistsenaariumide põhjal; võrdlusbaas = loodud loogika kontrollimatu aktsepteerimine versus jõustatud loomise-valideerimise-ülevaatuse töövoog; ajavahemik = 2026. aasta I kvartal. See mõõdik toetab struktureeritud valideerimistöövoogude väärtust simulatsioonis. See ei väida, et tegest on tööstusharuülese defektide määraga.

Eksporditav otsustuspakett on kompaktne tõendusmaterjalide kogum, mis näitab, et juhtimisloogika on enne juurutamist või ametlikku heakskiitmist tõestatult pädeva inimese poolt üle vaadatud, vaidlustatud, testitud ja parandatud. IEC 61508 terminoloogias toetab see organisatsiooni väidet süsteemse suutlikkuse, pädeva elutsüklis osalemise ja jälgitava inseneriotsuse kohta.

See ei ole ekraanipiltide galerii. See ei ole ka ebamääraselt rahustavate PDF-failide kaust. See on tõendusmaterjal, mis peab vastu ebamugavale auditi- või ülevaatuskoosolekule.

Kasutatav otsustuspakett peaks sisaldama kuut elementi:

Sõnastage, mida tähendab vastuvõetav käitumine vaadeldavates terminites: käivitustingimused, lubavad tingimused, blokeeringud, väljalülituskäitumine, häireläved ja tõrketurvalised vastused.

Dokumenteerige testimise ajal sisse viidud ebanormaalne seisund: anduri kadumine, klapi kinnikiilumine, ebaõnnestunud tagasiside, aegunud analoogsignaal, võistlusolukord, sidekatkestus või muu sarnane.

Jäädvustage insenertehniline järeldus: mida algne loogika ei arvestanud, mida valideerimine paljastas ja milliseid ülevaatuskriteeriume tuleks edaspidi uuesti kasutada.

1. Süsteemi kirjeldus Määratlege juhitav masin, protsessielement või seadme töö, sealhulgas kavandatud töörežiimid, kriitilised seadmed ja asjakohased ohud.
2. „Õige“ toimimise operatiivne määratlus
3. Redelloogika ja simuleeritud seadme olek Säilitage juhtimisloogika versioon koos vastava simuleeritud I/O-oleku, järjestuse oleku, analoogväärtuste ja operaatori tingimustega, mida valideerimise ajal kasutati.
4. Sisestatud rikkumise juhtum
5. Tehtud parandus Salvestage, mis loogikas muutus, miks see muutus ja millist ohtu või rikkerežiimi parandus käsitles.
6. Õppetunnid

Millised on auditi jaoks valmis paketi kolm sammast?

Auditi jaoks valmis pakett toetub tavaliselt kolmele sambale:

Loogika peaks vastama juhtimisnarratiivile, põhjus-tagajärg maatriksile, järjestuse kirjeldusele või funktsionaalsetele nõuetele. Kontekstita koodirida on vaid dekoratsioon.

• Jälgitavus

Pakett peaks näitama, et loogikat testiti normaalsetes ja ebanormaalsetes tingimustes, mitte ainult ei kompileeritud või visuaalselt kontrollitud.

• Valideerimistõendid

Organisatsioon peaks suutma näidata, et ülevaatust teostav insener mõistis protsessi, tundis ära ebaturvalised eeldused ja tegi põhjendatud parandusi.

• Pädevusdokumendid

Peamine eristus on lihtne: loodud väljund ei ole tõendusmaterjal; ülevaadatud käitumine on.

EL-i tehisintellekti määrus nõuab dokumenteeritud inimjärelevalvet, kuna kõrge riskitasemega süsteemid võivad toota väljundeid, mis näivad usutavad, kuid jäävad operatiivselt ebaturvalisteks, puudulikeks või kontekstipimedateks. Tööstuslik juhtimisloogika on selle selge näide. Redeldiagrammi rutiin võib näida süntaktiliselt kehtiv ja siiski ebaõnnestuda esimese tõsise ebanormaalse seisundi korral.

Artikkel 14 ei küsi, kas inimene oli nominaalselt „ahelas“. See küsib, kas süsteem võimaldab tõhusat järelevalvet inimestelt, kellel on vajalik pädevus, väljaõpe ja volitused. Automatiseerimises tähendab see, et inimene, kes ülevaatust teostab, peaks suutma:

• kontrollida kavandatud loogikat,
• mõista protsessi tagajärgi,
• testida ebanormaalseid olekuid,
• sekkuda enne juurutamist,
• tühistada ebaturvalist käitumist,
• ja dokumenteerida aktsepteerimise või tagasilükkamise alused.

See on kõrgem latt kui lihtsalt nupule „kinnita“ vajutamine.

Mida tähendab „inimjärelevalve“ vaadeldavates insenertehnilistes terminites?

Tööstusautomaatikas tuleks inimjärelevalvet määratleda vaadeldavate käitumismustrite kaudu:

• I/O põhjuslikkuse jälgimine sisendmuutusest väljundtoiminguni,
• lubavate tingimuste ja blokeeringute kontrollimine vastavalt juhtimisfilosoofiale,
• ohutu käivitamise, seiskamise ja rikkereageerimise kontrollimine,
• signaali kadumise ja halva oleku tingimuste testimine,
• häire- ja väljalülituskäitumise kinnitamine,
• ja sellise loogika tagasilükkamine, mida ei saa deterministlikult selgitada.

Kasulik vastand on mustandi loomine versus deterministlik veto. Tehisintellekt võib luua mustandi. Insener peab suutma põhjendatult vetostada.

Miks on tehisintellektiga loodud redelloogika tööstuskeskkonnas eriti tundlik?

Tehisintellektiga loodud redelloogika on tundlik, kuna redelprogrammid asuvad füüsilistele tagajärgedele väga lähedal. Puuduv lubav tingimus ei ole lihtsalt tarkvaraviga. See võib muutuda ootamatuks mootori käivitumiseks, kuivalt töötavaks pumbaks, ületäitunud mahutiks või järjestuse ummikuks taaskäivitamisel.

Probleem on harva selles, et tehisintellekt „ei tunne redelloogikat“. Probleem on selles, et see ei oma tehase konteksti, hoolduse reaalsust, instrumentide rikkemustreid ega kohaspetsiifilist juhtimisfilosoofiat. Need detailid määravad sageli, kas loogika on juurutatav. Süntaks on odav; kasutuselevõtu vead ei ole.

„Simulatsioonivalmidus“ tuleks määratleda operatiivselt, mitte retooriliselt. Simulatsioonivalmidusega insener suudab tõestada, jälgida, diagnoosida ja tugevdada juhtimisloogikat realistliku protsessikäitumise vastu enne, kui see jõudis reaalajas toimuva protsessini.

See määratlus nihutab arutelu teadlikult süntaksilt eemale. Teadmine, kuidas kontakte ja mähiseid paigutada, on kasulik. See ei ole sama, mis olla valmis järjestust rikketingimustes valideerima.

Simulatsioonivalmidusega insener peaks suutma:

• selgitada, mida iga koodirida tegema peab,
• ühendada redelloogika oleku seadme olekuga,
• jälgida silte, analoogväärtusi ja järjestuse üleminekuid,
• sisestada realistlikke rikkeid,
• tuvastada ebaturvalist või puudulikku käitumist,
• parandada loogikat,
• ja kontrollida, et parandus kõrvaldas vea ilma uut tekitamata.

See on tegelik eristus: süntaks versus juurutatavus.

Millised käitumismustrid näitavad simulatsioonivalmidust?

Kõige tugevamad näitajad on praktilised ja vaadeldavad:

• Insener suudab testida peamise/reservpumba rutiini ebaõnnestunud taseme tagasiside korral.
• Insener suudab tuvastada, miks mootori sulgemistee ignoreerib pärast käivitamist lubavat tingimust.
• Insener suudab tuvastada, et PID-ahel „töötab“ numbriliselt, kuid juhib ebaturvalist protsessiolekut, kuna instrumendi skaleerimine on vale.
• Insener suudab võrrelda simuleeritud seadme liikumist või protsessiolekut redeljärjestusega ja märgata mittevastavusi.
• Insener suudab dokumenteerida rikke, paranduse ja kordustesti tulemuse.

Inimene, kes oskab ainult koodirida kirjutada, õpib süntaksit. Inimene, kes oskab seda lõhkuda, parandada ja riski selgitada, läheneb kasutuselevõtu otsustusvõimele.

Tööjõu pädevust tuleks testida ülesannete täitmise kaudu ja säilitada dokumentidena. Seda ei saa tuletada tööriistadele juurdepääsust, kursuste läbimisest või enesekindlusest.

Tehisintellektiga toetatud programmeerimise puhul peaks pädevuse jälgimine keskenduma sellele, kas insener suudab masinloodud loogikat realistlikes protsessitingimustes üle vaadata ja korrigeerida.

Kaitstav pädevuse töövoog sisaldab:

Määrake ohuga seotud juhtimisprobleem koos määratletud eesmärkide, blokeeringute ja ebanormaalsete olekutega.

• Stsenaariumi määramine

Esitage tehniliseks ülevaatuseks kas tehisintellekti loodud rutiin või tahtlikult puudulik rutiin.

• Baasloogika ülevaatus

Nõudke, et insener käivitaks loogika simulatsioonis, lülitaks sisendeid, jälgiks väljundeid ja kontrolliks muutujaid.

• Simulatsiooni teostamine

Tutvustage realistlikke rikkejuhtumeid, nagu anduri kadumine, ebaõnnestunud tõestus, analoogtriiv või kinnikiilunud ajami käitumine.

• Rikke sisestamine

Nõudke loogika parandamist ja teist valideerimiskäivitust.

• Parandamine ja kordustest

Säilitage inseneri esitatud töö, hindamistulemus, kommentaarid ja lõpetamise tõendid pädevusdokumendina.

• Salvestatud hindamine

Mida peaks pädevusdokument tegelikult tõestama?

Pädevusdokument peaks tõestama kolme asja:

• insener mõistis kavandatud protsessikäitumist,
• insener tundis ära, millal loogika rikketingimustes seda käitumist rikkus,
• ja insener tegi tehniliselt põhjendatud paranduse.

See ei peaks tõestama ainult kohalolekut, redaktori tundmist või võimet reprodutseerida etteantud näidet.

OLLA Lab on siinkohal kasulik, kuna see pakub veebipõhist keskkonda, kus redelloogika, simulatsioon, I/O jälgimine, stsenaariumi struktuur ja hindamistöövoogud saab ühendada üheks ülevaatusteeks. Selle roll on piiritletud: see on valideerimis- ja harjutuskeskkond kõrge riskiga ülesannete jaoks, mitte otsetee sertifitseerimisele, kohapealsele volitamisele või ametlikule vastavusele iseenesest.

See piir on oluline. Head tööriistad toetavad tõendusmaterjali. Need ei asenda otsustusvõimet.

Praktilises mõttes saab OLLA Lab toetada pädevuse jälgimist järgmiselt:

• brauseripõhine redelloogika redaktor standardsete juhistüüpidega,
• simulatsioonirežiim käivitamise/seiskamise testimiseks ja sisendite lülitamiseks,
• muutujate ja I/O nähtavus sildi-oleku kontrollimiseks,
• stsenaariumipõhised tööstuslikud harjutused koos ohtude, järjestamise ja kasutuselevõtu märkmetega,
• koostöö- ja jagamistöövoogud ülesannete määramiseks ja ülevaatamiseks,
• hindamistöövoogud jõudlustõendite säilitamiseks.

Kuidas näeb pädevusharjutus välja OLLA Lab tarkvaras?

Usaldusväärne harjutus võib järgida seda mustrit:

• määrake peamise/reservpumba juhtimise stsenaarium koos taseme lubavate tingimuste ja rikkeolekutega,
• esitage osaliselt loodud või tahtlikult vigane redelrutiin,
• nõudke õppijalt rutiini käivitamist simulatsioonis,
• kasutage muutujate paneeli tasemesiltide, pumba tõestuste, häirete ja väljundkäskude kontrollimiseks,
• sisestage ebaõnnestunud tõestus või vale taseme sisend,
• nõudke loogika parandamist,
• hinnake tulemust vastavalt oodatud ohutule käitumisele,
• eksportige ülevaadatud esitus dokumendina.

Siin muutub OLLA Lab operatiivselt kasulikuks. See muudab „õpilane parandas selle“ jälgitavaks artefaktiks koos konteksti, testitingimuste ja ülevaatuse tulemusega.

OLLA Lab genereerib eksporditavaid pädevusdokumente, ühendades stsenaariumi määratluse, loogika esitamise, simulatsioonitõendid ja juhendaja ülevaatuse säilitatavaks kirjeeks, mida saab hoida väljaspool reaalajas toimuvat koolitust. Artefakt ei ole ainult platvorm ise; see on töövoo kaudu toodetud pakett.

Administraator või juhendaja saab OLLA Labi abil väljastada ülesande, nõuda valideerimisetappe, vaadata üle esitatud loogika ja säilitada hinnatud tulemuse osana auditeeritavast koolitusdokumendist. Sõltuvalt töövoo ülesehitusest võib selle kirje eksportida või kompileerida vormingutesse, mis sobivad sisemiste kvaliteedisüsteemide, auditi ettevalmistamise või vastavuskontrolli jaoks.

Kasulik eksporditav dokument peaks hõlmama:

• stsenaariumi nimi ja versioon,
• määratud eesmärk,
• I/O kaardistus ja juhtimisfilosoofia viide,
• esitatud redelloogika versioon,
• testitud rikkejuhtum,
• täheldatud rikkekäitumine,
• paranduste ajalugu,
• hindamistulemus ja juhendaja kommentaarid,
• praktikandi identiteet ja lõpetamise ajatempel.

Miks see audiitorite jaoks oluline on?

Audiitorid ei otsi platvormi demot. Nad otsivad tõendeid selle kohta, et organisatsioon suudab näidata:

• kes ülevaatuse teostas,
• mida neil paluti valideerida,
• millist ebanormaalset seisundit testiti,
• milline defekt leiti,
• kuidas see parandati,
• ja kas ülevaataja oli pädev seda otsust tegema.

See ongi otsustuspakett. Eksportimine on oluline, sest mälu ei ole kontrollimehhanism.

Head valideerimistõendid näitavad protsessi käitumist väljakutse korral, mitte ainult koodi puhkeolekus. Pakett peaks näitama, et insener testis loogikat tingimustes, mis on operatiivselt olulised.

Kasulikud tõendid hõlmavad:

• käivitamine kõigi lubavate tingimuste korrasolekul,
• käivituskatse ühe lubava tingimuse puudumisel,
• seiskamiskäsu käitumine,
• taaskäivitamise käitumine pärast rikke lähtestamist,
• anduri või tõestuse tagasiside kadumine,
• analoogkõikumised üle häire- ja väljalülituslävede,
• järjestuse üleminekud viivitatud või puuduva seadme vastuse korral,
• lõppolek pärast ebanormaalset seiskamist.

Eesmärk ei ole luua tohutut toimikut. Eesmärk on näidata, et loogikat testiti seal, kus see kõige tõenäolisemalt ohtlikult või eksitavalt ebaõnnestub.

### Näide: usutavast koodireast kaitstavani

Allpool on kompaktne illustratsioon erinevusest loodud loogika, mis näib mõistlik, ja valideeritud loogika vahel, mis peegeldab protsessi piiranguid.

AI hallutsinatsioon: Standardne sulgemisloogika (ebaõnnestub puuduva lubava tingimuse korral)

XIC Start_PB OTE Motor_Run XIC Motor_Run XIO Stop_PB OTE Motor_Run

Inimese valideeritud loogika: Lubav ja rikketeadlik käivitustee

XIC Start_PB XIC Safety_OK XIO Fault_Active OTE Motor_Run XIC Motor_Run XIO Stop_PB XIC Safety_OK XIO Fault_Active OTE Motor_Run

Esimene versioon ei ole „vale“ klassiruumi mõttes. See on puudulik tööstuslikus mõttes. Sealt paljud probleemid algavad.

Parimad rikkejuhtumid on need, mis paljastavad ebaturvalised eeldused juhtimisfilosoofias, järjestusloogikas või instrumentide mudelis. Need tuleks valida protsessi tagajärgede, mitte mugavuse põhjal.

Levinud väärtuslikud rikkejuhtumid hõlmavad:

• ebaõnnestunud käivitustõestus mootoritel või pumpadel,
• klapi käsk väljastatud ilma asendi kinnituseta,
• taseme, rõhu või temperatuuri saatja kadumine,
• analoogsignaal külmunud usutava, kuid vale väärtuse juures,
• hädaseiskamis- või väljalülitusahela aktiveerimine järjestuse sammu ajal,
• võistlusolukorrad režiimi ülemineku ajal,
• taaskäivitamine pärast toite- või sidekatkestust,
• PID-ahel, mis töötab vale skaleerimise või kehtetute seadeväärtuse eeldustega.

Kompaktne pakett ei vaja iga võimalikku riket. See vajab rikkeid, mis kõige tõenäolisemalt paljastavad, kas ülevaataja mõistab protsessi ja kaitsemeetmeid.

Kompaktne insenertehniliste tõendite kogum peaks olema struktureeritud nii, et teine ülevaataja saaks otsustustee ilma oletusteta rekonstrueerida. Ülaltoodud kuueosaline struktuur on tõhus, kuna see sunnib selgusele.

Kasutage seda malli:

Näide: Dupleks-pumpla koos peamise/reservpumba, kõrge taseme häire, käivitusvea häire, HOA-režiimide ja ülevooluriskiga.

Näide: Pump käivitub ainult siis, kui automaatrežiim on aktiivne, tase ületab käivitusläve, ükski blokeering pole aktiivne ja tõestus on saadud lubatud aja jooksul; tõestuse ebaõnnestumine käivitab häire ja takistab korduvaid ebaturvalisi taaskäivitusi.

Näide: Peapumba käsk väljastatud, kuid töötamise tõestus jääb 5 sekundiks valeks.

Näide: Lisatud käivitusvea taimer, töötamise vea häire, peapumba blokeering ja reservpumba ülevõtmistee.

Näide: Algne loogika eeldas, et käsk tähendab liikumist; parandatud loogika eraldab käsu oleku kontrollitud seadme olekust.

1. Süsteemi kirjeldus
2. „Õige“ toimimise operatiivne määratlus
3. Redelloogika ja simuleeritud seadme olek Lisage redelversioon, siltide loend, mahuti algtase, režiimi olekud, tõestuse tagasiside olekud ja testi ajal kasutatud häiretingimused.
4. Sisestatud rikkumise juhtum
5. Tehtud parandus
6. Õppetunnid

See vorming on kompaktne, loetav ja eksporditav. Seda on ka raskem kasutada ilma tegelikku ülevaatustööd tegemata.

Standardite alus on lihtne. IEC 61508 nõuab pädevaid isikuid kogu ohutuse elutsükli vältel ja EL-i tehisintellekti määrus nõuab kõrge riskitasemega tehisintellektisüsteemide puhul tõhusat inimjärelevalvet. Need kohustused ei kao, kuna LLM koostas esimese mustandi.

Laiem insenertehniline kirjandus toetab samuti simulatsioonipõhist valideerimist ja digitaalse kaksikuga toetatud koolitust kui kasulikke meetodeid rikkemõistmise, protsessi nähtavuse ja kasutuselevõtu ettevalmistamise parandamiseks, kui neid kasutatakse selge ülesande kavandamise ja piiritletud väidetega. Oluline täpsustus on see, et simulatsioon toetab pädevuse arendamist ja tõendite genereerimist; see ei anna automaatselt kohapealset pädevust ega regulatiivset vastavust.

Selles mõttes täidab OLLA Lab usaldusväärset rolli. See annab meeskondadele koha selliste ülesannete harjutamiseks, mis on liiga riskantsed, liiga kallid või liiga häirivad reaalsetel seadmetel harjutamiseks: loogika valideerimine, põhjus-tagajärg seoste jälgimine, ebanormaalsete tingimuste käsitlemine ja juhtimiskäitumise parandamine pärast rikkeid.

Nad peaksid lõpetama tehisintellekti järelevalve käsitlemise poliitilise lausena ja hakkama seda käsitlema tõendite töövoona. Kui teie organisatsioon kasutab tehisintellekti tööstusliku loogika abistamiseks, vajate korratavat meetodit, et näidata, et inimesed vaatasid, vaidlustasid ja parandasid seda loogikat realistlikes tingimustes.

Praktiline lähtepunkt on:

• määratleda otsustuspaketi struktuur,
• valida ohuga seotud stsenaariumid,
• nõuda ebanormaalse oleku testimist,
• hinnata ülevaatusülesannet, mitte koodi välimust,
• säilitada paranduste rada,
• ja eksportida tulemus organisatsiooni pädevuse jälgimise süsteemi.

Auditi probleem ei ole müstiline. See on protseduuriline.

- 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)

OLLA Labi insenerimeeskond ja Ampergon Vallis Labi ohutusspetsialistid.

Käesolev artikkel on kontrollitud vastavalt IEC 61508 ohutusstandarditele ja EL-i tehisintellekti määruse nõuetele.