Millele see artikkel vastab
Artikli kokkuvõte
Hädaseiskamisnuppude ja ohutusblokeeringute korrektne programmeerimine nõuab kaitseorienteeritud PLC-projekteerimise lähenemist: riistvaralised ohutusfunktsioonid peavad kõrvaldama ohtliku energia, samas kui standardne PLC-loogika peab reageerima deterministlikult, katkestama tööolekud ja vältima ootamatut taaskäivitumist. OLLA Lab pakub piiratud simulatsioonikeskkonda nende ebanormaalsete tingimuste käitumise valideerimiseks enne reaalset kasutuselevõttu.
Levinud eksiarvamus on, et „hädaseiskamisnupu programmeerimine“ tähendab, et PLC täidab ohutusfunktsiooni. See ei ole nii. Tunnustatud masinaohutuse tavade kohaselt peab hädaseiskamisfunktsioon olema rakendatud asjakohaselt projekteeritud ohutusriistvara või ohutussertifitseeritud juhtimissüsteemide abil, samas kui standardne PLC-loogika tavaliselt seirab seda ohutusolekut ja reageerib tarkvaraliste käivituskäskude eemaldamise, häirete ja taaskäivitusteede blokeerimisega.
Praktiline lünk ei ole süntaksis. See on vigade käitumises. Algaja programm tõestab sageli, et masin saab käivituda; kaitstav programm tõestab, mis juhtub siis, kui juhe katkeb, kinnitust ei saabu või operaator lähtestab hädaseiskamisnupu.
Ampergon Vallis Metric: OLLA Labi konveieristsenaariumite 5000 kasutaja esitatud redelloogika projekti siseülevaates ei suutnud 68% esialgsetest esitustest hoida mootori tööolekut katkestatuna pärast simuleeritud hädaseiskamisnupu lähtestamist kuni tahtliku taaskäivituskäsu andmiseni. Metoodika: n=5000 õpilaste esmakordset esitust konveieri seiskamise/käivitamise ülesannetes; võrdlusalus = oodatud automaatse taaskäivituse puudumine pärast ohutusoleku taastamist; ajavahemik = 1. jaanuar 2025 kuni 28. veebruar 2026. See toetab kitsast seisukohta levinud koolitusvigade kohta taaskäivitusloogikas. See ei mõõda väliintsidentide määrasid, tehase ohutustulemuslikkust ega tööjõu kompetentsust laiemalt.
Mis on kaitseorienteeritud programmeerimine tööstusautomaatikas?
Kaitseorienteeritud programmeerimine tööstusautomaatikas tähendab redelloogika projekteerimist eeldusel, et seadmed tõrguvad, operaatorid tegutsevad väljaspool järjekorda ning protsessi tagasiside on mõnikord puuduv, hiline või vale. See on normaalne projekteerimise alus, mitte pessimism. Tehased suudavad väga hästi leida selle ühe haru, mida te ei testinud.
PLC-töös on kaitseorienteeritud programmeerimine vahe liikumise võimaldamise ja toimimise kontrollitavuse vahel ebanormaalsetes tingimustes. Esimest on lihtne demonstreerida. Teine on see, mis jääb püsima pärast kasutuselevõttu.
Kaitstav juhtimisprogramm sisaldab tavaliselt:
- selgesõnalisi lubatingimusi käivitamiseks,
- aktiivseid blokeeringuid seiskamiseks või jätkamise takistamiseks,
- toimimise kontrollimise (proof-of-operation) kontrolle,
- ajalõpu käsitlust,
- häirete genereerimist,
- taaskäivitusdistsipliini pärast väljalülitusi või hädaseiskamissündmusi,
- oleku lähtestamise loogikat, mis on tahtlik, mitte kaudne.
See on ka koht, kus Simulation-Ready (simulatsioonivalmidus) vajab täpset määratlust. Ampergon Vallis kasutuses ei ole Simulation-Ready insener keegi, kes lihtsalt tunneb redelsüntaksit. See tähendab inseneri, kes suudab tõestada, jälgida, diagnoosida ja karastada juhtimisloogikat realistliku protsessikäitumise vastu enne, kui see jõuab reaalse protsessini.
Miks tõrkekindel sisendite projekteerimine algab tavaliselt suletud loogikast (NC)
Tõrkekindel diskreetne projekteerimine kasutab kriitiliste seiskamis- ja lubaringide jaoks sageli tavaliselt suletud (NC) väliseadmeid, nii et katkine juhe, toite kadumine või avatud vooluring kalduvad pigem seiskamistingimuse kui käivitustingimuse poole. Põhimõte on lihtne: viga peaks sarnanema ohutu olekuga.
Tarkvaraterminites tähendab see sageli, et PLC näeb tervet ohutusahela olekubitti ainult siis, kui seiratud vooluring on terve. Kui vooluring avaneb ootamatult, bitt langeb. Terve masin ei tohiks sõltuda soovitud pidevusest.
See ei tee standardset PLC-d ohutussertifitseerituks. See muudab standardse PLC reaktsiooni ohutusahelale deterministlikumaks ja hõlpsamini valideeritavaks.
Kuidas struktureerida hädaseiskamisahelat redelloogikas?
Õige struktuur on eraldada ohutusfunktsioon standardsest PLC reaktsioonist. Hädaseiskamisfunktsioon ise peaks kõrvaldama ohtliku energia juhtmega ühendatud ohutusreleede, kontaktorite või selleks otstarbeks projekteeritud ohutus-PLC või ohutuskontrolleri kaudu. Standardne PLC seejärel seirab selle ohutustee abiolekut ja kasutab seda tarkvaraliste käivituskäskude katkestamiseks, lukustuste tühistamiseks, taaskäivituse blokeerimiseks ja operaatori teavitamiseks.
See eristus on oluline, kuna IEC 61508 käsitleb funktsionaalse ohutuse elutsükli distsipliini ja ISO 13850 määratleb hädaseiskamisfunktsiooni kui täiendavat kaitsemeedet, mitte kui tarkvaralist mugavust. Kui standardloogika teeskleb ohutuskihti, on projekt juba viltu läinud.
Praktiline järjestus standardse PLC reaktsiooni jaoks
Tüüpiline mitte-ohutus-PLC rakendus teeb järgmist:
- Seirab ohutusahela tervisebitti, mis on tuletatud ohutusrelee abikontaktist või samaväärsest olekust.
- Paigutab selle biti jadamisi käivitusloaga, nii et tarkvaratee katkeb kohe, kui ohutus kaob.
- Katkestab hoidelülituse (seal-in) või lukustusloogika ohutuse kadumisel.
- Nõuab pärast lähtestamist tahtlikku taaskäivituskäsku, selle asemel et lubada automaatset taaskäivitumist, kui hädaseiskamisnupp on füüsiliselt lähtestatud.
- Teavitab põhjusest, et operaator ja tehnik saaksid eristada hädaseiskamist, lubatingimuse tõrget, blokeeringu väljalülitust ja kontrollimise ajalõppu.
Näide redelloogika mustrist hädaseiskamisteadliku käivitusloogika jaoks
Allpool on lihtsustatud muster standardse PLC-loogika jaoks, mis peegeldab ohutusolekut. See on illustratiivne, mitte ohutussertifitseeritud projekt.
Redelmuster:
- `StartPB` jadamisi `StopPB` ja `EStop_OK`-ga aktiveerib `RunCmd`.
- `RunCmd` koos `StopPB`, `EStop_OK` ja `Permissive_OK`-ga säilitab hoidetee, näiteks `Mtr_SealIn`.
- `Mtr_SealIn` juhib `Motor_Run`.
Tõlgendus:
- `EStop_OK` on tõene ainult siis, kui seiratud ohutusahel on terve.
- Kui `EStop_OK` langeb, katkevad nii käivitustee kui ka hoidetee.
- Kui `EStop_OK` pärast lähtestamist naaseb, mootor ei taaskäivitu automaatselt, välja arvatud juhul, kui `StartPB` antakse uuesti.
See viimane punkt ei ole kosmeetiline. Ootamatu taaskäivitumise vältimine on üks peamisi käitumuslikke nõudeid hädaseiskamisreaktsiooni puhul.
Mis peaks juhtuma pärast hädaseiskamisnupu lähtestamist?
Pärast hädaseiskamisnupu lähtestamist peaks standardne PLC jääma seisatud olekusse, kuni kõik nõutavad taaskäivitustingimused on täidetud ja tehakse tahtlik käivitustoiming. Paljudes süsteemides hõlmab see:
- ohutusahela taastamist,
- seiskamiskäsu tervislikku olekut,
- aktiivse väljalülitustingimuse puudumist,
- järjestuse oleku lähtestamist või kinnitamist,
- operaatori antud taaskäivitust.
Kui teie loogika taaskäivitub, kuna lukustus säilis või kuna käivitustingimust ei tühistatud, ei ole kood „peaaegu õige“. See on ohtlikul viisil vale.
Mis vahe on lubatingimusel (permissive) ja blokeeringul (interlock)?
Lubatingimus on tingimus, mis peab olema tõene enne, kui järjestusel lubatakse käivituda. Blokeering on tingimus, mis peatab, takistab või katkestab toimimise, kui tekib ohtlik või kehtetu tööolek. Algajad ajavad termineid sageli segamini, kuna mõlemad esinevad redelloogikas kontaktidena. Protsess ei hooli sõnavarast, kuid projekti ülevaatus hoolib.
Lubatingimus vs. blokeering
| Loogika tüüp | Funktsioon | Tüüpiline ajastus | Näide OLLA Labis | |---|---|---|---| | Lubatingimus | Käivitus-eelne tingimus, mis peab olema täidetud enne algatamist | Enne käivituskäsku või järjestuse algust | Paagi tase üle miinimumi enne pumba käivitamist | | Blokeering | Aktiivne töötingimus, mis sunnib rikkumise korral seiskama, takistama või välja lülitama | Töötamise ajal | Kõrge väljundrõhk lülitab töötava pumba välja | | Lubatingimus hoidelülituse tähtsusega | Peab olema tõene käivitamiseks ja mõnikord jätkamiseks, sõltuvalt filosoofiast | Käivitus ja võimalik, et töö | Kaitseuks suletud enne tsükli algust | | Väljalülitus / seiskamisblokeering | Sunnib kohesele või järjestikusele seiskamisele | Ebanormaalse oleku ajal | Ületemperatuur või mootori ülekoormuse tagasiside kadumine |
Kasulik projekteerimise eristus
Lubatingimused vastavad: „Kas ma tohin käivituda?“ Blokeeringud vastavad: „Kas ma tohin jätkata?“
See vastandus on kompaktne, kuna see on operatiivselt kasulik. See paljastab ka kiiresti halva loogika.
### Näide: pumba juhtimine
Lihtsa pumba järjestuse jaoks:
- Lubatingimus: Märja kaevu tase üle madal-madal läve. - Lubatingimus: Mootori ülekoormus ei ole rakendunud. - Blokeering: Kõrge väljundrõhu lüliti avaneb töötamise ajal. - Blokeering: Töö kontrollimise tagasiside ei saabu 3 sekundi jooksul. - Taaskäivitusreegel: Pärast väljalülitust nõuda operaatori lähtestamist ja käivituse uuesti andmist.
Siin on juhtimisfilosoofia olulisem kui redelipulkade arv. Lühike programm võib ikkagi olla väga vale.
Kuidas programmeerida lubatingimusi, väljalülitusi ja taaskäivitusloogikat koos?
Kõige puhtam lähenemine on jagada loogika eraldi kihtidesse: käivitusluba, töö säilitamine, väljalülituse tuvastamine ja lähtestamise/taaskäivitamise distsipliin. Nende segamine ühte tihedasse redelipulka säästab vertikaalset ruumi, kuid kaotab selguse. Ekraanid on odavad; ebaselgus on kallis.
Praktiline struktuur näeb välja selline:
1. Käivitusloa kiht
Kasutage spetsiaalset bitti, näiteks `Start_Permissive_OK`, mis on koostatud kõigist nõutavatest eeltingimustest:
- ohutusriistvaralt seiratud hädaseiskamisnupu tervislik olek,
- kommunaalteenused kättesaadavad,
- aktiivne väljalülitus puudub,
- nõutav protsessitingimus olemas,
- režiimi valik kehtiv.
2. Töö säilitamise kiht
Kasutage eraldi bitti, näiteks `Run_Allowed`, mis jääb tõeseks ainult seni, kuni aktiivsed töötingimused on vastuvõetavad:
- blokeeringu väljalülitus puudub,
- seiskamiskäsk puudub,
- kontrollimise ajalõpp puudub,
- järjestuse katkestus puudub.
3. Väljalülituse tuvastamise kiht
Looge selgesõnalised väljalülitusbitid, selle asemel et peita väljalülituse põhjused ühe käivitusredelipulga sisse:
- `Trip_HighPressure`
- `Trip_ProofFail`
- `Trip_Overtemp`
- `Trip_EStopObserved`
This parandab diagnostikat, HMI-sõnumeid ja vea-järgset ülevaatust.
4. Lähtestamise ja taaskäivitamise distsipliin
Nõudke vajadusel käsitsi lähtestamist, seejärel nõudke uut käivituskäsku. Lähtestamine peaks tühistama väljalülitusoleku; see ei tohiks vaikimisi liikumist algatada.
Seda eristust tasub hoida teravana: lähtestamine ei ole taaskäivitamine.
Kuidas OLLA Lab simuleerib suure riskiga tõrketingimusi?
Vigade käsitlust ei saa valideerida „õnnelikul teel“. Peate vea sisestama, jälgima oleku üleminekut ja muutma loogikat, kui reaktsioon on vale. See ongi kogu harjutuse mõte.
Siin muutub OLLA Lab operatiivselt kasulikuks. Selle brauseripõhine redeliredaktor, simulatsioonirežiim, muutujate nähtavus ja stsenaariumipõhised seadmemudelid võimaldavad inseneridel testida ebanormaalseid tingimusi ilma pingestatud seadmeid puudutamata.
Mida OLLA Lab selles töövoos teeb
OLLA Labi tuleks siin hoolikalt positsioneerida. See ei asenda kohapealset kasutuselevõttu, ohutuse valideerimist ega ametlikku funktsionaalse ohutuse hindamist. See pakub riskikindlat harjutuskeskkonda ülesannete jaoks, mis on liiga ohtlikud, liiga häirivad või liiga kulukad, et neid juhuslikult reaalsete varadega harjutada.
Praktilises mõttes võimaldab platvorm kasutajatel:
- koostada redelloogikat veebipõhises redaktoris,
- käivitada ja peatada simulatsiooni ohutult,
- lülitada sisendeid ja jälgida väljundeid reaalajas,
- kontrollida muutujaid, silte, analoogväärtusi ja juhtimisolekuid,
- võrrelda redeli käitumist simuleeritud seadme reaktsiooniga,
- töötada realistlikes tööstuslikes stsenaariumides koos dokumenteeritud ohtude ja kasutuselevõtu märkmetega.
See on õige kasutusjuht: harjutamine, valideerimine ja veateadlik iteratsioon.
Kuidas testida hädaseiskamisreaktsiooni OLLA Labis
Kasulik valideerimisjärjestus OLLA Labis on lihtne:
5. Kinnitage, et:
- käivitusmähis langeb,
- hoidelülitus langeb,
- väljundolek lülitub välja,
- mis tahes väljalülitus- või häireindikaator seadistub ootuspäraselt.
- Koostage mootori käivitamise/seiskamise redelipulk koos hoidelülituse haruga.
- Lisage `EStop_OK` seiratud bitt jadamisi käivitusteele.
- Käivitage simuleeritud masin.
- Simulatsioonirežiimis kasutage muutujate paneeli, et sundida seiratud hädaseiskamisnupu tervislik bitt tõesest väärani.
- Taastage `EStop_OK` tõeseks.
- Kinnitage, et masin jääb seisatuks, kuni antakse uus käivituskäsk.
See järjestus õpetab enamat kui süntaksit. See õpetab taaskäivitusdistsipliini ja olekuteadlikkust.
Miks stsenaariumipõhine vigade sisestamine on oluline
Stsenaariumipõhine simulatsioon on oluline, kuna blokeeringud on kontekstuaalsed. Konveier, tõstejaam, õhukäitlusseade ja segisti ei tõrgu samal viisil ja neid ei tohiks programmeerida nii, nagu nad seda teeksid.
OLLA Labi stsenaariumi struktuur on siin kasulik, kuna see seob loogika järgmisega:
- I/O kaardistused,
- juhtimisfilosoofia,
- ohud,
- järjestuse nõuded,
- analoog- või PID-seosed, kus asjakohane,
- kontrollimise sammud.
See muudab redeliharjutuse kasutuselevõtu prooviks. Erinevus ei ole peen.
Kuidas näeb välja „õige“ hädaseiskamisnupu ja blokeeringu käitumine simulatsioonis?
Õige käitumine tuleks operatiivselt määratleda enne testimise algust. „Näeb hea välja“ ei ole testikriteerium.
Standardse PLC reaktsiooni jaoks seiratud hädaseiskamissündmusele hõlmab õige käitumise toimiv määratlus tavaliselt:
- tarkvaraline käivituskäsk langeb järgmise skannimistsükli jooksul pärast seiratud ohutusoleku kadumist,
- lukustatud tööolek ei säili pärast hädaseiskamissündmust,
- standardloogikaga juhitud väljundid lülituvad asjakohaselt välja,
- häire või sündmuse olek tuvastab seiskamise põhjuse,
- füüsilise hädaseiskamisnupu lähtestamine üksi ei taaskäivita liikumist,
- taaskäivitamine nõuab tahtlikku operaatori tegevust ja mis tahes nõutavat lähtestamisjärjestust.
Lubatingimuse või blokeeringu projekti puhul võib õige käitumine hõlmata ka:
- järjestus ei saa käivituda ebaõnnestunud lubatingimustega,
- aktiivne väljalülitus katkestab tööoleku prognoositavalt,
- kontrollimise tagasiside ajalõpp tuvastatakse konfigureeritud akna jooksul,
- järjestuse olekumasin naaseb pärast väljalülitust määratletud ohutusse olekusse,
- ükski peidetud lukustus või säilitatud bitt ei põhjusta soovimatut taaskäivitumist.
Seetõttu peaks simulatsioon olema tõenduspõhine. Kui vastuvõtukriteeriumid on ebamäärased, on ka testitulemus ebamäärane.
Milliseid insenertehnilisi tõendeid peaks ohutusloogika simulatsioonist säilitama?
Kui soovite demonstreerida tegelikku juhtimisotsustust, säilitage kompaktne insenertehniliste tõendite kogum, mitte ekraanipiltide kaust. Ekraanipilte on lihtne koguda ja lihtne valesti mõista.
Kasutage seda struktuuri:
Täpsustage sisestatud viga: hädaseiskamise kadumine, kontrollimise ebaõnnestumine, rõhu väljalülitus, katkine lubatingimus, anduri kinnijäänud olek, ajalõpp või kommunikatsioonist sõltuv tingimus, kui see on modelleeritud.
- Süsteemi kirjeldus Määratlege masin või protsessielement, selle tööeesmärk, peamised I/O-d ja ohutusega seotud olekud.
- „Õige“ operatiivne määratlus Märkige täpne oodatav käitumine käivitamise, seiskamise, hädaseiskamissündmuse, väljalülituse, lähtestamise ja taaskäivitamise jaoks.
- Redelloogika ja simuleeritud seadme olek Jäädvustage asjakohased redelipulgad, siltide olekud ja simuleeritud masina seisund testi hetkel.
- Sisestatud vea juhtum
- Tehtud parandus Salvestage, mis loogikas muutus pärast vea jälgimist.
- Õppetunnid Võtke kokku projekteerimisviga ja parandatud põhimõte, näiteks „hoidelülituse haru peab ohutusoleku kadumisel katkema“ või „lähtestamisbitt ei tohi toimida taaskäivituskäsuna“.
See pakett on palju usaldusväärsem kui poleeritud galerii. Insenertehnilised tõendid peaksid selgitama käitumist, mitte seda lihtsalt kaunistama.
Millised standardid ja tehnilised piirid on siin olulised?
Peamine piir on see, et standardne PLC redelloogika ei ole asendaja ohutussertifitseeritud hädaseiskamisrakendusele. See on esimene põhimõte.
Teine põhimõte on see, et tarkvara on endiselt oluline, kuna see reguleerib masina deterministlikku reaktsiooni pärast ohutusfunktsiooni toimimist. Praktikas hõlmab see:
- tarkvaraliste käivituslubade katkestamist,
- järjestuse oleku tühistamist seal, kus nõutud,
- ootamatu taaskäivitumise vältimist,
- põhjuse teavitamist,
- korrapärase taastumise toetamist.
Asjakohased viited hõlmavad:
- ISO 13850 hädaseiskamisfunktsiooni ja ootamatu taaskäivitumise vältimise jaoks masina kontekstis.
- IEC 61508 laiema funktsionaalse ohutuse raamistiku ja elutsükli mõtlemise jaoks.
- ISO 13849-1 ja IEC 62061 võivad samuti olla asjakohased masinaohutuse projekteerimisel, sõltuvalt arhitektuurist ja nõutavast jõudluse terviklikkusest.
- Organisatsioonide, näiteks exida, juhised on sageli kasulikud ohutuse elutsükli ja valideerimisdistsipliini praktiliseks tõlgendamiseks.
Lõpetuseks on vajalik hoiatus: simulatsiooni valideerimine on väärtuslik, kuid see ei loo iseenesest SIL-sobivust, PL-saavutust, õiguslikku vastavust ega valmisolekut kohapeal. See parandab loogika kvaliteeti ja kasutuselevõtu valmisolekut. Need on olulised eelised. Need ei ole sama asi mis sertifitseerimine.
Kuidas liikuda akadeemilisest redelloogikast kasutuselevõtu-tasemel vigade käsitluseni?
Üleminek toimub siis, kui lõpetate küsimise ainult selle kohta, kas redelipulk on süntaktiliselt õige, ja hakkate küsima, kas protsessi reaktsioon on tõrke korral kaitstav. See on tõeline lävi.
Kasutuselevõtu-tasemel mõtteviis hõlmab tavaliselt järgmisi harjumusi:
- testige ebanormaalseid olekuid sama tahtlikult kui normaalseid olekuid,
- sundige puuduvaid tagasisidesid ja viivitatud üleminekuid,
- kontrollige, et lukustused katkeksid siis, kui nad peaksid,
- eraldage lähtestamine taaskäivitamisest,
- dokumenteerige väljalülituse põhjused selgesõnaliselt,
- võrrelge kontrolleri olekut simuleeritud seadme olekuga,
- muutke loogikat jälgitud veakäitumise, mitte intuitsiooni põhjal.
See on OLLA Labi piiratud väärtus. See annab inseneridele koha harjutada täpselt neid ülesandeid, mida reaalsed tehased algajate harjutustena pakkuda ei taha: vigade sisestamine, põhjus-tagajärg seoste jälgimine, taaskäivituskäitumise valideerimine ja loogika parandamine enne riistvara kaasamist.
See ei ole glamuurne. See on lihtsalt viis, kuidas ehitatakse pädevat juhtimistööd.
Ampergon Vallis Labi insenerimeeskond on pühendunud tööstusautomaatika ja PLC-kodeerimise parimate tavade edendamisele. Meie eesmärk on pakkuda praktilisi teadmisi, mis aitavad inseneridel luua ohutumaid ja töökindlamaid süsteeme.
Käesolev artikkel on koostatud tuginedes tööstusautomaatika standarditele (ISO 13850, IEC 61508) ja OLLA Labi simulatsioonipõhiste valideerimistöövoogude parimatele tavadele. Sisu on üle vaadatud Ampergon Vallis Labi tehniliste ekspertide poolt, et tagada tehniline täpsus ja vastavus tööstuslikele ohutusnõuetele.