Millele see artikkel vastab
Artikli kokkuvõte
Kaitsev PLC-programmeerimine tähendab tõestamist, et lubavad tingimused, blokeeringud, hädaseiskamise lähtestusloogika ja PID-väljundi piirajad viivad seadmed rikkeolukorras ohutusse olekusse. Inseneri ülesanne ei ole ainult korrektse redeldiagrammi (ladder) süntaksi kirjutamine, vaid ka rikketeadliku käitumise valideerimine realistliku protsessi vastuse suhtes enne juurutamist.
Levinud eksiarvamus on, et redelprogramm on „ohutu“, kui järjestus töötab ideaaljuhul. See ei ole nii. Ohutusega seotud juhtimiskäitumine määratakse sellega, mida loogika teeb, kui sisendsignaal kaob, kui järjestuse keskel tekib tõrge või kui analoogväärtus on vale.
Hiljutine Ampergon Vallis'e sisemine võrdlusuuring toetab seda eristust: OLLA Lab'i kasutuselevõtu stsenaariumides loodud 2500 simuleeritud pumba käivitusjärjestuse analüüsis selgus, et 68% esialgsetest redeldiagrammidest puudus käsitsi lähtestamise lukustus pärast hädaseiskamist [Metoodika: 2500 õppija ja praktiku simulatsioonijooksu; ülesandeks oli pumba käivitusjärjestuse rakendamine koos hädaseiskamise taastamisloogikaga; võrdlusaluseks oli standarditele vastav taaskäivitus, mis nõuab teadlikku käsitsi lähtestamist; ajavahemik jaanuar–märts 2026]. See mõõdik toetab ühte kitsast punkti: taaskäivitusloogikat rakendatakse simulatsioonis sageli valesti. See ei mõõda välijuhtumite määra, standardite järgimist tööstuses ega operaatori pädevust.
Selles artiklis tähendab „simulatsioonivalmidus“ midagi operatiivset: insener suudab juhtimisloogikat tõestada, jälgida, diagnoosida ja tugevdada realistliku protsessikäitumise vastu enne, kui see jõuab reaalsesse protsessi. Süntaks on vaid sisseastumiseksam. Kasutuselevõtu otsustusvõime on töö ise.
Mis vahe on lubaval tingimusel ja blokeeringul?
Lubav tingimus (permissive) on eeltingimus, mis on vajalik enne, kui järjestusel lubatakse käivituda. Blokeering (interlock) on pidevalt hinnatav tingimus, mis on vajalik järjestuse töö jätkamiseks; kui seda rikutakse, peab süsteem liikuma määratletud ohutusse olekusse.
See eristus on sõnastuses lihtne, kuid rakendamisel sageli valesti käsitletud. Redeldiagrammi lüli näeb sageli korralik välja, kuid masin ei ole veendunud.
Lubavad tingimused on käivitustingimused
Lubavaid tingimusi kontrollitakse enne toimingu, režiimi või järjestuse sammu algatamist.
- Eesmärk: vältida käivitamist, kui nõutavad tingimused ei ole täidetud - Hindamispunkt: tavaliselt käivituspäringu, sammu ülemineku või režiimi sisenemise ajal - Tüüpilised näited:
- Paagi tase üle miinimumi enne pumba käivitamist
- Õhurõhk normis enne silindri liikumist
- Ajam valmis enne konveieri lubamist
- Retsept laaditud enne partii algatamist
Protsessiohutuse keeles ei ole lubavad tingimused samad, mis kaitsvad väljalülitused (trips). IEC 61511-ga kooskõlas oleva mõtlemise kohaselt on need lubavad tingimused, mitte viimane kaitsebarjäär.
Blokeeringud on pidevad töötingimused
Blokeeringuid hinnatakse töö ajal pidevalt ja need peavad rikkumise korral sundima ohutu reaktsiooni.
- Eesmärk: peatada, blokeerida või pingest vabastada seadmed, kui ilmneb ohtlik või kehtetu olek - Hindamispunkt: pidevalt aktiivse oleku ajal - Tüüpilised näited:
- Kõrge-kõrge rõhu tõrge sulgeb etteandeklapi
- Mootori ülekoormuse rike katkestab tööjuhise
- Kaitseukse avamine eemaldab liikumisloa
- Madala vooluhulga blokeering keelab küttekeha
Lubav tingimus ütleb: „võid alustada“. Blokeering ütleb: „võid jätkata ainult seni, kuni see jääb tõeks“. See ei ole semantika. See on erinevus korrektse käivitusloogika ja tegeliku rikkekindluse vahel.
Kuidas see redeldiagrammis välja näeb
Eristus muutub selgemaks, kui see kaardistada lüli käitumisega:
- Käivitusnupp (PB): `XIC` - Valitud automaatrežiim: `XIC` - Minimaalne tase normis: `XIC` - Aktiivne tõrge puudub: `XIO` tõrkebitil, kui tõrgebitt on rikke korral tõene
- Lubava tingimuse muster
- Väljundmähis või töö lukustus pingestub ainult siis, kui kõik käivitustingimused on tõesed
- Olemasolev töö lukustus või järjestuse aktiivne bitt jääb pingestatuks ainult siis, kui: - Rõhk normis: `XIC` - Ülekoormus puudub: `XIC` - Hädaseiskamine korras: `XIC` - Kaitse suletud: `XIC`
- Blokeeringu muster
- Iga rikutud tingimus katkestab lüli ja sunnib ohutu oleku
OLLA Lab'i stsenaariumi dokumentatsioonis saab kasutuselevõtu märkmeid kasutada nende kategooriate selgeks eraldamiseks: mis peab olema tõene käivitamiseks, mis peab jääma tõeseks töötamiseks ja millisesse olekusse peaks digitaalne kaksik rikkumise korral sisenema. Siin muutub OLLA Lab operatiivselt kasulikuks.
Kuidas programmeerida nõuetele vastavat hädaseiskamisahelat redeldiagrammis?
Nõuetele vastav hädaseiskamise rakendus peab vältima automaatset taaskäivitamist pärast seiskamisseadme lähtestamist; taaskäivitamine nõuab teadlikku käsitsi toimingut. See põhimõte kajastub masinaohutuse praktikas vastavalt standarditele nagu IEC 60204-1 ja NFPA 79.
Esimene parandus on oluline: hädaseiskamisfunktsioon ei ole lihtsalt „seiskamisnupp redeldiagrammis“. Ohutusfunktsioon saavutatakse peamiselt nõuetekohaselt kavandatud riistvaraarhitektuuri ja vajaduse korral ohutushinnatud komponentidega. Standardne PLC-loogika võib jälgida olekut, hallata taaskäivitusrežiimi ja koordineerida mitteohutuslikke juhtimistoiminguid, kuid see ei asenda ohutushinnatud funktsiooni. Nende kihtide segiajamine on see, kuidas kallid vead muutuvad õppetundideks.
Välja olek ja loogika olek ei ole vastandid juhuslikult
Rikkekindlas väljajuhtmestikus kasutatakse tavaliselt normaalselt suletud (NC) hädaseiskamiskontakti, nii et tervislik olek tagab pidevuse.
- Välisseadme olek: NC-kontakt suletud, kui on ohutu - PLC sisendi olek: sisend loeb `1`, kui ahel on korras - Rikkekäitumine: hädaseiskamise vajutamine, toite kadumine või juhtme katkemine viib sisendi olekusse `0`
Seetõttu kasutab loogika hädaseiskamise tervisliku sisendi puhul sageli `XIC`-käsku. Käsk ei peegelda füüsilist kontaktisümbolit. See kontrollib, kas PLC näeb tervislikku `1`.
Nõutav taaskäivituskäitumine
Korralik taaskäivitusmuster peab tegema kolme asja:
- Katkestama töötingimuse kohe, kui hädaseiskamise tervislik signaal muutub vääraks
- Lukustama taaskäivituse pärast hädaseiskamise taastamist
- Nõudma käsitsi lähtestamist või uut käivituskäsku enne liikumise või protsessi jätkumist
Kui masin jätkab automaatselt tööd, kui seenenupp välja tõmmatakse, on loogika põhilise taaskäivitustesti läbi kukkunud. Lüli võib olla süntaktiliselt kehtiv. Käitumine on ikkagi vale.
Tüüpiline redelstruktuur
Standarditele vastav juhtimismuster sisaldab sageli:
- 1. lüli: Hädaseiskamise tervislik olek
- `XIC ESTOP_OK` juhib vajadusel sisemist tervislikku bitti
- 2. lüli: Rikke või lähtestamist nõudev lukustus
- `ESTOP_OK` kadumine määrab `RESET_REQUIRED` biti
- `RESET_REQUIRED` jääb lukustatuks, kuni operaator vajutab `RESET_PB`
- 3. lüli: Tööjuhise kinnistamine (seal-in) - väljund: `RUN_CMD`
- `XIC START_PB`
- `XIC ESTOP_OK`
- `XIO RESET_REQUIRED`
- `XIO TRIP_ACTIVE`
- kinnistusharu ümber käivituse, kasutades tööjuhise bitti
- 4. lüli: Käsitsi lähtestamine
- `XIC RESET_PB`
- `XIC ESTOP_OK`
- vabastab `RESET_REQUIRED`
See on üks rakendusmuster, mitte universaalne mall. Nõutav käitumine on tõeline test: hädaseiskamise tervisliku oleku kadumine peab pingest vabastama ja taastamine ei tohi põhjustada automaatset taaskäivitamist.
Miks on PID-väljundi piiramine protsessiohutuse jaoks hädavajalik?
PID-väljundi piiramine on manipuleeritava muutuja range piiramine, et kontroller ei saaks käskida väljaspool määratletud ajami või protsessi piire. Ilma selleta võib silmus nõuda füüsiliselt mõttetut või mehaaniliselt kahjulikku väljundit.
See on oluline, sest analoogrikked ebaõnnestuvad vähem dramaatiliselt kui diskreetsed väljalülitused. Need lihtsalt suruvad protsessi pikemaks ajaks vales suunas, mis on sageli hullem.
Mida piiramine matemaatiliselt tähendab
Kui piiramata kontrolleri väljund on:
MV_raw(t) = Kp e(t) + Ki ∫e(t)dt + Kd de(t)/dt + Bias
siis piiratud väljund on:
MV(t) = min(MV_max, max(MV_min, MV_raw(t)))
Kus:
- `MV_raw` = piiramata manipuleeritav muutuja
- `MV_min` = alumine väljundpiir
- `MV_max` = ülemine väljundpiir
Operatiivselt ei tohi lõplikule juhtimisseadmele saadetud käsk ületada määratletud piire, isegi kui veaterm jätkab kasvamist.
Miks on piiramata väljund ohtlik
Piiramatu PID-käitumine põhjustab vähemalt kolm praktilist probleemi:
- Ajami küllastumine
- Klapi, VFD-viite, siibri või küttekeha käsk juhitakse väljapoole ettenähtud vahemikku
- Isegi kui riistvara väärtust tagasi skaleerib, võib kontroller jätkata integreerimist, nagu oleks rohkem autoriteeti
- Protsessi kahjustamine
- Küttekeha võib jääda maksimaalsele väljundile piisavalt kauaks, et toodet rikkuda
- Etteandeklapp võib ajada anuma ülevoolu või rõhu tõusuni
- Eksitav diagnostika
- Silmus tundub „agressiivne“, kui tegelik probleem on selles, et kontroller nõuab võimatut väljundit
110% käsk 100% klapile ei ole täiendav juhtimine. See on lihtsalt kontroller, mis teatab, et on reaalsusest väljunud.
Anti-windup on kaasnev juhtimismeetod
Väljundi piiramine ilma anti-windup-funktsioonita on puudulik. Kui integraalterm jätkab akumuleerumist ajal, mil väljund on piiril kinni, salvestab kontroller vea, mis tuleb hiljem „lahti kerida“, põhjustades sageli ülereguleerimist ja aeglast taastumist.
Levinud anti-windup-lähenemised hõlmavad:
- Integraali hoidmine: integreerimise peatamine, kui `MV` on piiril ja viga sunniks seda veelgi enam küllastumisse - Tagasiarvutamine: piiratud ja toorväljundi vahe tagasisöötmine integraatorisse - Tingimuslik integreerimine: integreerimine ainult siis, kui ajami autoriteet on veel saadaval
Paljude koolitus- ja kasutuselevõtujuhtumite puhul on operatiivne määratlus piisav: kui väljund on piiratud kõrgel, ärge jätkake positiivse vea integreerimist; kui piiratud madalal, ärge jätkake negatiivse vea integreerimist.
Praktilised piiramise näited
Tüüpilised piiramisvahemikud sõltuvad protsessist ja lõppseadmest:
- Klapi käsk: `0% kuni 100%` - Küttekeha väljund: `0% kuni 80%`, et kaitsta toodet või seadmeid - Minimaalne retsirkulatsiooniklapp: `20% kuni 100%`, et säilitada pumba kaitsevool - Ventilaatori kiiruse viide: `30% kuni 95%`, et vältida seiskumist või ebastabiilset madala otsa tööd
Need on insenertehnilised piirid, mitte esteetilised eelistused. Protsess selgitab neid tavaliselt, kui keegi vaevub küsima.
Kuidas seda OLLA Lab'is jälgida
OLLA Lab'i PID-juhtpaneeli ja muutujate paneeli saab kasutada järgmise jälgimiseks:
- protsessi muutuja hälve
- seadeväärtuse jälgimine
- kontrolleri väljund
- analoogsignaali muutused
- väljundi küllastumine
- vastus enne ja pärast piiramisloogika lisamist
Riskivabas simulatsioonis saate tahtlikult tekitada saatja madala rikke, jälgida silmuse liikumist maksimaalse nõudluse suunas, seejärel lisada väljundpiirangud ja võrrelda digitaalse kaksiku vastust. See on kasulik kasutuselevõtuloogika harjutus. See ei ole SIL-i valideerimise töövoog ja seda ei tohiks sellisena kirjeldada.
Kuidas programmeerida kaitsvaid blokeeringuid ebanormaalsete olekute jaoks?
Kaitsev PLC-programmeerimine tähendab loogika kirjutamist olekute jaoks, mida operaatorid ei soovi, kuid mida tehastes ikka juhtub. Järjestus, mis töötab ainult siis, kui iga andur käitub korrektselt, ei ole tugev juhtimisloogika.
Alustage määratletud ohutu olekuga
Iga blokeering peaks vastama konkreetsele ohutule reaktsiooni.
Näited:
- Pumbasüsteem: pumba seiskamine, väljalaskeklapi sulgemine, operaatori teavitamine - Kütteplokk: kütte lubamise eemaldamine, vajadusel puhastuse või tsirkulatsiooni säilitamine - Konveieriliin: liikumiskäsu eemaldamine, rikkemärgutule aktiivsena hoidmine - Paagi täitesüsteem: sisselaskeklapi sulgemine, taaskäivitamise blokeerimine kuni kinnituseni
Ohutu olek peab olema süsteemiti määratletud. „Kõige peatamine“ ei ole alati ohutu. Mõnikord on see lihtsalt dramaatiline.
Ehitage blokeeringud kui jälgitav loogika, mitte kui ebamäärane kavatsus
Kaitstav blokeeringu disain sisaldab tavaliselt:
- päästikutingimust
- nõutavat toimingut
- lukustuskäitumist (kui on)
- lähtestamistingimust
- operaatori märguannet
- valideerimismeetodit simulatsioonis või FAT-is
Näiteks:
- Päästik: `PRESSURE_HH = 1` - Toiming: `PUMP_RUN_CMD` vabastamine, `FEED_VALVE_CMD` sulgemine - Lukustus: `HH_PRESS_TRIP` määramine - Lähtestamine: operaatori lähtestamine lubatud alles pärast rõhu naasmist alla lähtestusläve - Märguanne: häirebitt ja HMI-teade - Valideerimine: kõrge-kõrge rõhu sisestamine simulatsioonis töö ajal ja seiskamisteekonna kinnitamine
See on detailsuse tase, mis muudab juhtimisnarratiivi testitavaks.
Kasutage lubavaid tingimusi ja blokeeringuid koos, mitte vahetatavalt
Tugev järjestus kasutab sageli mõlemat:
- Lubav tingimus enne käivitamist
- imemistaseme piisavus
- aktiivse ülekoormuse puudumine
- allavoolu klapi kättesaadavus
- Blokeering töö ajal
- madala imemise tõrge
- ülekoormuse tõrge
- kõrge väljalaskerõhu tõrge
- hädaseiskamise tervislik olek
Kui paagi madalat taset kontrollitakse ainult käivitamisel ja mitte kunagi töö ajal, ei ole loogika „lihtsam“. See on lõpetamata.
Kuidas OLLA Lab simuleerib ohtlikke kasutuselevõtu stsenaariume?
Riskivaba virtuaalne kasutuselevõtukeskkond võimaldab inseneridel sisestada rikkeid, jälgida seadmete vastust, muuta loogikat ja käivitada täpne stsenaarium uuesti, ilma et inimesed või riistvara satuksid tarbetusse ohtu. See on piiratud väärtuspakkumine.
Te ei õpeta rikkekäsitlust reaalsel seadmel improviseerides. Tehased ei ole üldiselt vaimustuses sellest, et neid kasutatakse õppevahenditena.
Ohutu rikete sisestamine
OLLA Lab'i simulatsioonirežiimis saavad kasutajad käivitada loogikat, lülitada sisendeid ja kontrollida muutujate olekuid ilma füüsilise riistvarata. See toetab ebanormaalsete tingimuste sihipärast testimist, nagu:
- juhtme katkemise ekvivalendid
- anduri kadumine
- hädaseiskamise aktiveerimine aktiivse järjestuse ajal
- tõestus-tagasiside rike
- analoogkõikumised väljaspool normaalset töövahemikku
- häire- ja tõrkeläved
Insenertehniline väärtus on korratavus. Sama riket saab pärast iga loogikamuudatust uuesti sisse viia, kuni vastus on õige.
Digitaalse kaksiku valideerimine
Digitaalse kaksiku valideerimine tähendab selles artiklis redeldiagrammi oleku käitumise võrdlemist realistliku virtuaalse seadmemudeliga, et kontrollida, kas juhtimisloogika annab soovitud füüsilise tulemuse.
See määratlus on tahtlikult kitsas. See ei tähenda, et mudel on täielik füüsikaliselt täiuslik koopia, ega viita ametlikule vastavusele seose kaudu.
OLLA Lab'is võib see hõlmata jälgimist, kas:
- pump käivitub ainult siis, kui lubavad tingimused on täidetud
- paagi taseme vastus vastab kästud klapi olekutele
- järjestus peatub tõrke korral õigesti
- blokeering viib seadmed ettenähtud ohutusse olekusse
- PID-muudatused muudavad protsessi vastust nähtaval, testitaval viisil
Miks see on kasutuselevõtu otsustusvõime jaoks oluline
Kasutuselevõtu ebaõnnestumised tulenevad sageli koodi oleku ja seadme oleku mittevastavusest.
Tüüpilised näited hõlmavad:
- tööbitt on tõene, kuid puudub tõestus-tagasiside
- klapi käsk on avatud, kuid protsessi muutuja ei liigu
- järjestuse samm edeneb ilma füüsilise tingimuse täitmiseta
- lähtestusloogika kustub liiga vara ja võimaldab soovimatut taaskäivitamist
Veebipõhine redeldiagrammi redaktor üksi ei paljasta neid mittevastavusi eriti hästi. Simulatsioonikeskkond koos I/O nähtavuse ja seadmete vastusega aga küll. See on praktiline eristus.
Mida tähendab „simulatsioonivalmidus“ automaatikainseneri jaoks?
„Simulatsioonivalmidus“ tähendab, et insener suudab tõestada, et juhtimisloogikat on testitud realistliku protsessikäitumise, ebanormaalsete olekute ja taastumisteede suhtes enne reaalse süsteemi puudutamist. See on võimekuse määratlus, mitte kompliment.
Operatiivselt suudab simulatsioonivalmis insener:
- luua redeldiagrammi loogikat, mis on seotud nimega I/O ja protsessi tingimustega
- määratleda enne testimist, mida „õige“ käitumine tähendab
- sisestada realistliku rikke ja jälgida vastust
- tuvastada mittevastavuse kavandatud ja tegeliku käitumise vahel
- muuta loogikat
- käivitada stsenaarium uuesti ja dokumenteerida tulemus
See on lähemal kasutuselevõtu praktikale kui klassiruumi süntaksi harjutustele. Süntaks on oluline. Juurutatavus on veelgi olulisem.
Nõutav insenertehniliste tõendite kogum
Kui soovite oma oskusi usaldusväärselt demonstreerida, koostage kompaktne insenertehniliste tõendite kogum, mitte ekraanipiltide galerii.
Kasutage seda struktuuri:
Dokumenteerige tutvustatud ebanormaalne tingimus: anduri kadumine, hädaseiskamine, ülekoormus, tõestuse puudumine, analoogkõikumine.
See vorming on kasulik, kuna see peegeldab seda, kuidas tegelik insenertehniline ülevaatus toimib: süsteemi kavatsus, testitingimus, vaadeldud tulemus, korrigeeriv toiming. Ekraanipildid võivad kaasa tulla, kui nad käituvad viisakalt.
- Süsteemi kirjeldus Määratlege masin või protsessiüksus, selle juhtimiseesmärk ja töökontekst.
- „Õige“ käitumise operatiivne määratlus Märkige täpne oodatav käitumine normaalses töös ja rikke korral.
- Redeldiagrammi loogika ja simuleeritud seadme olek Näidake lüli loogikat ja vastavat seadme või protsessi olekut simulatsioonis.
- Sisestatud rikkejuhtum
- Tehtud muudatus Salvestage loogikamuudatus, mis korrigeeris käitumist.
- Õppetunnid Selgitage, mida algne loogika ei arvestanud ja mida muudetud versioon nüüd tõestab.
Kuidas valideerida hädaseiskamist, blokeeringut või PID-piirajat enne juurutamist?
Valideerimine peaks testima käitumist, mitte ainult lüli välimust. Küsimus ei ole selles, kas loogika kompileerub. Küsimus on selles, kas protsess siseneb määratletud rikke korral nõutavasse ohutusse olekusse.
Minimaalsed valideerimiskontrollid diskreetse ohutusega seotud juhtimiskäitumise jaoks
Hädaseiskamise ja blokeeringuga seotud loogika puhul kontrollige vähemalt:
- tervisliku signaali kadumine pingest vabastab mõjutatud käsu
- tervisliku signaali taastamine ei põhjusta automaatset taaskäivitamist
- käsitsi lähtestamine on nõutav seal, kus see on määratletud
- tõrke märguanne on nähtav ja lukustatud vastavalt kavatsusele
- lähtestamine on blokeeritud, kuni ohutusse olekusse naasmise tingimused on täidetud
- järjestuse sammu loogika ei möödu tõrke teekonnast
- tõestus-tagasiside rikked tuvastatakse vajaduse korral
Minimaalsed valideerimiskontrollid PID-piiramise käitumise jaoks
Analoogjuhtimise puhul kontrollige vähemalt:
- väljund jääb määratletud min/max piiridesse
- kontrolleri käitumine küllastumisel on jälgitav
- integraal-toime ei jätka sügavamale küllastumisse tungimist ilma juhtimisautoriteedita
- taastumine pärast küllastumist on stabiilne ja piiratud
- häire- ja tõrkeläved jäävad piiramispiiridega kooskõlaliseks
Märkus standardite kohta
IEC 61511 pakub protsessiohutuse raamistikku ohutusfunktsioonide, nõutavate toimingute ja elutsükli distsipliini määratlemiseks protsessitööstuses. IEC 60204-1 ja NFPA 79 määratlevad masinatega seotud elektriohutuse ootused, sealhulgas seiskamis- ja taaskäivituskäitumise. Ükski neist standarditest ei ole rahul optimismiga ja ükski neist ei ole asendatav simulaatoriga. Simulaator on harjutuskeskkond. See on väärtuslik just seetõttu, et see on piiratud.
Kokkuvõte
Kaitsev PLC-programmeerimine on distsipliin, mille eesmärk on panna juhtimisloogika ohutult ebaõnnestuma, teadlikult taastuma ja prognoositavalt käituma, kui protsess koostööd ei tee. Praktikas tähendab see lubavate tingimuste eraldamist blokeeringutest, hädaseiskamise taaskäivitusloogika rakendamist, mis nõuab käsitsi toimingut, ja PID-väljundite piiramist, et analoogsilmused ei annaks käske väljaspool füüsilisi või protsessipiire.
OLLA Lab sobib sellesse töövoogu kui riskivaba virtuaalne kasutuselevõtukeskkond. See võimaldab inseneridel testida I/O käitumist, rikkekäsitlust, digitaalse kaksiku vastust ja loogikamuudatusi enne juurutamist. See on usaldusväärne kasutusjuhtum. See ei ole sertifitseerimise otsetee, funktsionaalse ohutuse lahendaja ega asendus korralikule disainiülevaatusele.
Jätka avastamist
Interlinking
Related link
Täiustatud protsessijuhtimise ja PID-simulatsiooni keskus →Related link
Kuidas testida PLC „mis-siis-kui“ stsenaariume VR-is rikkeanalüüsiks →Related link
Vältige PID-aliasingut PLC-des Nyquisti ja skaneerimisaja testimisega →Related reading
Avastage interaktiivseid ohutuse kasutuselevõtu stsenaariume OLLA Lab'is ↗