Kuidas parandada vooluhulga summeerija vigu PLC täisarvu- ja reaalarvumatemaatikas

PLC-de vooluhulga summeerimise vead tulenevad tavaliselt kahest erinevast matemaatilisest tõrkest: täisarvude kärpimisest ja ühekordse täpsusega ujukomaarvude täpsuse kadumisest. INT-tüüpi muutujad hülgavad murdarvulise vooluhulga, samas kui 32-bitised REAL-tüüpi muutujad võivad lõpuks lõpetada väikeste juurdekasvude registreerimise suure kogusumma taustal. Usaldusväärne summeerimine nõuab andmetüüpide distsipliini, ületäitumise (rollover) disaini ja simulatsioonipõhist valideerimist.

Vooluhulga summeerija võib olla vale isegi siis, kui transmitter, pump ja torustik toimivad korrektselt. Viga on sageli PLC aritmeetilises mudelis, mitte protsessis. See eristus on oluline, sest vigane matemaatika on vaiksem kui vigane riistvara.

OLLA Labi simuleeritud 24-tunnise pumpamise käigus, testides 16-bitist INT-summeerijat korduva 0,4-gallonise juurdekasvuga, registreeris akumulaator 0 gallonit, samal ajal kui simuleeritud protsess liigutas 576 gallonit. Metoodika: valimi suurus = 1 kontrollitud simulatsiooniülesanne korduvate fikseeritud juurdekasvudega; võrdlusalus = eeldatav aritmeetiline akumulatsioon 0,4 gallonit 1440 minuti jooksul; ajaaken = 24 simuleeritud tundi. See toetab ühte kitsast punkti: täisarvu kärpimine võib deterministlikus testjuhtumis põhjustada murdarvulise vooluhulga täieliku kadumise. See ei määra universaalset välitõrgete määra.

Siin muutub „süntaks versus juurutatavus“ reaalseks. Programmirida võib tunduda korrektne, kompileeruda veatult ja siiski eksitada operaatoreid nädalaid.

Kärpimisvead tekivad siis, kui PLC salvestab või töötleb murdarvulist vooluhulka täisarvu andmetüübiga, mis ei suuda kümnendkohti esitada. Kui saabuv juurdekasv on 0,8 ja sihtkoht on INT, siis murdosa visatakse ära enne, kui see üldse inventari jõuab.

IEC 61131-3 keskkondades on see andmetüübi tavapärane käitumine. Viga on eelduses, et protsess andestab selle.

16-bitiste märgiga täisarvude piirangud

Märgiga 16-bitisel täisarvul (`INT`) on piiratud vahemik:

- Miinimum: `-32 768` - Maksimum: `32 767`

Kui summeerija akumuleerib impulsside loendusi või skaleeritud mahtu otse `INT`-tüüpi muutujasse, ilmnevad kiiresti kaks tõrkerežiimi:

- Ületäitumine (Overflow): kui väärtus ületab `32 767`, hüppab see negatiivsesse vahemikku või tekitab vea, sõltuvalt platvormi käitumisest ja käsuhaldusest. - Murdosa kustutamine: iga väärtus alla 1,0 kärbitakse, kui see teisendatakse või kirjutatakse täisarvulisse sihtkohta.

Impulss-ühiku rakenduse puhul võib ületäitumine toimuda üllatavalt kiiresti. Analoogsignaalist tuletatud inkrementaalse summeerija puhul võib kärpimine toimuda igal skaneerimistsüklil. Üks on dramaatiline; teine on sageli raskemini märgatav.

Miks täisarvulised summeerijad kustutavad vaikimisi reaalse vooluhulga

Täisarvumatemaatika ei „ümarda natuke“. See eemaldab jäägi. Kui teie loogika arvutab:

• `Flow_Increment = 0,8 gallonit skaneerimistsükli kohta`
• `Total_INT = Total_INT + Flow_Increment`

siis tegelik liitmine muutub järgmiseks:

• `Total_INT = Total_INT + 0`

Protsess liigutas vedelikku. PLC ei registreerinud midagi.

See on levinud disainiviga, kui insenerid skaleerivad 4–20 mA vooluhulga signaali insenerühikutesse, jagavad ajabaasiga ja kirjutavad tulemuse täisarvulisse akumulaatorisse. Programmirida võib olla süntaktiliselt korrektne, kuid summeerija on juba kompromiteeritud.

Miks skaneerimissagedus probleemi süvendab

Kiired skaneerimistsüklid suurendavad tõenäosust, et iga juurdekasvuline maht on väike. See tähendab, et rohkem liitmisi jääb alla 1,0 insenerühiku ja läheb kaduma, kui sihtkoht põhineb täisarvudel.

Kõrge eraldusvõimega summeerija nõuab seetõttu enamat kui lihtsalt ADD-plokki. See nõuab kooskõla järgmiste tegurite vahel:

• signaali skaleerimine,
• skaneerimisintervall,
• insenerühikud,
• akumulaatori andmetüüp.

32-bitine REAL lahendab murdosa probleemi, kuid toob kaasa teistsuguse tõrke: täpsuse kadumine suurte akumuleeritud väärtuste korral. Kui summa muutub piisavalt suureks, ei muuda väikesed saabuvad juurdekasvud enam salvestatud numbrit.

See on IEEE 754 käitumine, mitte tingimata tarkvaraviga. Nii toimib ühekordse täpsusega ujukomaarv.

Ujukomaarvu täpsuse piirang

Enamik PLC `REAL`-tüüpi muutujaid on IEEE 754 ühekordse täpsusega ujukomaarvud. Praktilises inseneritöös pakuvad need umbes 7 olulist kümnendkohta täpsust.

See tähendab, et vähima esitatava muutuse suurus sõltub juba salvestatud numbri suurusjärgust.

Näited:

• `10,0` lähedal on `0,01` lisamine tavaliselt esitatav.
• `1 000 000,0` lähedal võib `0,01` olla liiga väike, et salvestatud väärtust muuta.
• Suuremate summade puhul võivad isegi mõõdukad juurdekasvud „alla neelatud“ saada.

Summeerija ei ebaõnnestu seetõttu, et protsess peatus. See ebaõnnestub, kuna akumulaatori numbriline eraldusvõime on muutunud jämedamaks kui lisatav juurdekasv.

Kuidas „allaneelamise“ efekt välja näeb

Klassikaline sümptom on lihtne:

• vooluhulga transmitter näitab aktiivset voolu,
• pump töötab,
• protsess liigutab füüsiliselt toodet,
• kuid SCADA summeerija joon on lame.

Sel hetkel kahtlustavad operaatorid sageli sidet, ajalooandmete (historian) viivitust või mõõteriistade triivi. Mõnikord on probleem palju vähem glamuurne: akumulaatoril on saanud otsa kasulik detailsus.

`REAL`-tüüp suudab esitada suuri numbreid või väikeseid juurdekasve piisavalt hästi paljude ülesannete jaoks. See ei suuda teha mõlemat lõputult kasvavas summeerijas ilma disainikontrollita.

Miks see on oluline partiide, kommunaalteenuste ja arvelduslähedase aruandluse puhul

Mitte iga summeerija ei ole rahaliselt kriitiline, kuid paljud on operatiivselt olulised. Akumuleeritud vooluhulga vead võivad moonutada:

• partii saagikuse arvutusi,
• kemikaalide doseerimise andmeid,
• veebilansi aruandlust,
• CIP-kasutuse hinnanguid,
• paagi inventuuri lepitamist,
• läbilaskevõimega seotud hooldusotsuseid.

See artikkel ei esita väidet vastavuse kohta arveldusmõõtmistele. See esitab kitsama insenertehnilise väite: kui akumulaatori arhitektuur on nõrk, võib raporteeritud maht oluliselt erineda füüsilisest reaalsusest.

Õige vastus sõltub sellest, mida te akumuleerite: impulsse, skaleeritud insenerühikuid või murdarvulisi ajasammude juurdekasve. Puudub üks universaalne muutuja valik, kuid on olemas kaitstavad mustrid.

Kasutage võimalusel DINT-tüüpi täisarvuliseks akumuleerimiseks

Kui allikaks on impulssvoog ja iga impulss tähistab fikseeritud kogust, on `DINT` tavaliselt ohutum kui `INT`.

Miks:

• 32-bitine märgiga `DINT` ulatub `-2 147 483 648` kuni `2 147 483 647`.
• See lükkab ületäitumist `INT`-iga võrreldes märkimisväärselt edasi.
• See säilitab täpsed täisarvulised loendused.

Impulsside summeerimiseks on täisarvude loendamine täisarvudena tavaliselt kõige puhtam disain.

Kasutage REAL-tüüpi ettevaatlikult murdarvuliseks tööakumulatsiooniks

Kui allika juurdekasv on murdarvuline, võib `REAL` olla kasulik tööakumulaatorina, mitte alati ainsa eluaegse summeerijana.

Head kasutusjuhud:

• lühiajalise murdarvulise vooluhulga akumuleerimine,
• vahesumma hoidmine enne ületäitumist,
• operaatorile nähtavate päeva- või partiisummade toetamine piiratud lähtestamisintervallidega.

Riskantne kasutusjuht:

• lasta ühel 32-bitisel REAL-tüüpi muutujal lõputult kasvada, lisades samal ajal väga väikeseid juurdekasve.

See on koht, kus täpsuse erosioon muutub disainiprobleemiks, mitte teoreetiliseks.

Kasutage LREAL-tüüpi, kui teie platvorm seda toetab ja rakendus seda õigustab

64-bitine `LREAL` pakub palju suuremat täpsust ja vahemikku kui 32-bitine `REAL`. Platvormidel, mis toetavad seda usaldusväärselt kontrolleri, HMI, ajalooandmete ja liideste kihtides, on see sageli puhtam lahendus pikaajaliseks murdarvuliseks summeerimiseks.

Kuid „toetamine“ peab tähendama täielikku tuge:

• kontrolleri käsu käitumine,
• andmete transport,
• SCADA/HMI ühilduvus,
• ajalooandmete salvestustüüp,
• aruandluskihi tõlgendus.

Matemaatiliselt usaldusväärsest kontrolleri muutujast ei piisa, kui ülejäänud süsteem selle vaikimisi madalamaks teisendab.

Kaskaadne ületäitumisega summeerija eraldab murdarvulise akumulatsiooni pikaajalisest salvestamisest. See muster on sageli vastupidavam kui ühe pidevalt kasvava ujukomaarvu hoidmine.

Disainipõhimõte on lihtne:

• akumuleerige väikesed juurdekasvud murdarve toetavasse registrisse,
• kandke suuremad tükid üle pika vahemikuga täisarvulisse summasse,
• jätke murdarvulisse registrisse alles ainult jääk.

See vähendab tõenäosust, et pisikesed lisamised kaovad väga suure ujukomaarvu taustal.

Näidisloogika muster

1. samm: Akumuleerige toorvooluhulga juurdekasv REAL-tüüpi töösummasse.

`ADD Flow_Increment, Working_Total_Real, Working_Total_Real`

2. samm: Kontrollige, kas töösumma on saavutanud ülekande läve.

`CMP Working_Total_Real >= 100.0`

3. samm: Kandke läviväärtus pika vahemikuga täisarvulisse peamisse summasse.

`ADD 100, Master_Total_DINT, Master_Total_DINT`

`SUB Working_Total_Real, 100.0, Working_Total_Real`

Miks see muster töötab

Insenertehniline kasu on numbriline stabiilsus.

Kaskaadne disain annab teile:

• murdosa säilimise tööregistris,
• pika vahemikuga salvestuse täisarvulises peamises summas,
• vähenenud ujukomaarvu täpsuse kadumise, kuna REAL-tüüpi vahesumma püsib suhteliselt väiksena,
• selge auditeeritavuse selle kohta, kuidas summa on koostatud.

Mustrit saab laiendada ka järgmisega:

• partiisummad,
• igapäevased lähtestamisregistrid,
• püsimälus säilitatavad summad,
• häirekontrollid ületäitumise anomaaliate jaoks,
• järjestuse blokeeringud, mis takistavad uuendusi mõõteriista kehtetute olekute ajal.

Mida tähendab „õige“ summeerija disaini puhul

Summeerija ei ole „õige“ sellepärast, et programmirida kompileerub või HMI number muutub. See on õige siis, kui loogika vastab operatiivsele definitsioonile, näiteks:

• akumuleeritud maht vastab eeldatavale aritmeetikale määratud tolerantsi piires,
• ületäitumise käitumine on välditud või selgesõnaliselt hallatud,
• kehtetud sisendolekud ei tekita valet akumulatsiooni,
• lähtestamise käitumine on kontrollitud ja auditeeritav,
• pikaajaline täpsus jääb aruandluse eesmärgile vastavaks.

See on standard, mis on kasutuselevõtul oluline.

OLLA Lab on siin kasulik kui piiratud valideerimiskeskkond, mitte kui oraakel. Selle väärtus seisneb selles, et insenerid saavad jälgida skaneerimistsükli-põhist käitumist, manipuleerida sisenditega ohutult ja võrrelda redelloogika olekut simuleeritud protsessi käitumisega enne, kui reaalne süsteem vea pärib.

Praktiliselt tähendab see, et saate testida, kas summeerija matemaatika käitub realistlikes töötingimustes korrektselt, selle asemel et usaldada visuaalselt korras programmirida.

Mida OLLA Lab muudab jälgitavaks

Kasutades redelloogika redaktorit, simulatsioonirežiimi ja muutujate paneeli, saab kasutaja:

• ehitada summeerija, kasutades `INT`, `DINT`, `REAL` või segatüüpi loogikat,
• sisestada fikseeritud või muutuvaid vooluhulga juurdekasve,
• jälgida akumulaatori väärtusi reaalajas,
• võrrelda sisendi käitumist väljundi matemaatikaga,
• kiirendada simulatsiooni, et paljastada pikaajalised täpsusprobleemid kiiremini.

See on operatiivselt kasulik, sest paljud neist tõrgetest on välitingimustes aeglased. Simulatsioonis muutuvad need kontrollitavaks.

„Simulatsioonivalmiduse“ operatiivne definitsioon

Selles kontekstis tähendab simulatsioonivalmidus, et insener suudab:

• tõestada kavandatud juhtimiskäitumist,
• jälgida iga sisendi ja oleku ülemineku mõju,
• diagnoosida numbrilisi ja järjestusvigu,
• karastada loogikat realistliku protsessikäitumise vastu,
• dokumenteerida, miks muudetud loogika on usaldusväärsem enne, kui see jõuab reaalse protsessini.

See ei tähenda kohapealset pädevust, sertifitseerimist ega automaatset valmisolekut järelevalveta kasutuselevõtuks. Simulatsioon on proov, mitte juriidiline vabastus.

Praktiline OLLA Labi valideerimise töövoog

Kasulik valideerimisjärjestus OLLA Labis oleks:

1. Looge simuleeritud vooluhulga allikas teadaoleva juurdekasvulise käitumisega.
2. Ehitage üks summeerija, kasutades `INT`-tüüpi, ja teine, kasutades `REAL`-tüüpi.
3. Käivitage mõlemad identsete juurdekasvudega.
4. Jälgige kärpimist täisarvulises teekonnas.
5. Suurendage REAL-tüüpi akumulaatorit, kuni väikesed juurdekasvud lõpetavad summa muutmise.
6. Asendage disain kaskaadse ületäitumise või kõrgema täpsusega strateegiaga.
7. Käivitage stsenaarium uuesti ja võrrelge tulemusi.

See on koht, kus OLLA Lab muutub operatiivselt kasulikuks. See annab nähtavuse tõrgete klassile, mis sageli elavad üle lauaarvuti ülevaatuse ja muutuvad ilmseks alles siis, kui inventuuri lepitamine muutub keeruliseks.

Programmirida ekraanipilt ei ole insenertehniline tõendusmaterjal. See on illustratiivne ainult siis, kui see on seotud käitumise, tõrke sisestamise ja muudatuste ajalooga.

Kui soovite demonstreerida tõsist juhtimistööd, kasutage kompaktset tõendusmaterjalide paketti, mis koosneb kuuest osast:

Dokumenteerige täpne sisestatud viga: täisarvu kärpimine, ületäitumine, ujukomaarvu allaneelamine, vale skaleerimine või lähtestamise võistlusolukord.

Selgitage disainimuudatust: `DINT`-le üleminek, `LREAL`-i kasutuselevõtt, kaskaadne ületäitumine, läve ülekandmise loogika või väravaga akumulatsioon.

1. Süsteemi kirjeldus Määratlege protsessi kontekst, signaaliallikas, ühikud, skaneerimise eeldused ja summeerimise eesmärk.
2. „Õige“ operatiivne definitsioon Määratlege eeldatav aritmeetiline käitumine, tolerants, lähtestamise reeglid ja kehtetu oleku käsitlus.
3. Redelloogika ja simuleeritud seadmete olek Näidake loogikat ja vastavat simuleeritud protsessi käitumist koos, mitte eraldi.
4. Sisestatud tõrkejuhtum
5. Tehtud muudatus
6. Õppetunnid Jäädvustage, mida test tõestas, millised eeldused ebaõnnestusid ja mis peaks saama disainistandardiks.

See struktuur on lähemal kasutuselevõtu tõendusmaterjalile kui lihtsale portfoolio hetktõmmisele.

Aluseks olev andmetüüpide käitumine põhineb tööstusliku programmeerimise ja numbrilise arvutamise põhimõtetel, mitte platvormi folklooril.

Asjakohased tugipunktid on:

• IEC 61131-3 PLC programmeerimiskeelte ja andmetüüpide konventsioonide jaoks, mida kasutatakse tööstuslikes juhtimissüsteemides.
• IEEE 754 ujukomaarvude aritmeetika käitumise jaoks, sealhulgas piiratud täpsuse ja esituspiirangute jaoks.
• IEC 61508 laiema põhimõtte jaoks, et programmeeritavate süsteemide süstemaatilised disainivead tuleks tuvastada ja kontrollida distsiplineeritud inseneriprotsesside kaudu.
• Simulatsiooni ja digitaalse kaksiku kirjandus tööstusautomaatikas, mis üldiselt toetab modelleeritud keskkondade kasutamist juhtimiskäitumise valideerimiseks enne juurutamist, eriti kui reaalne testimine on kulukas või riskantne.

See artikkel ei väida, et simulaator üksi tagab vastavuse, ohutuse terviklikkuse või välitingimustes aktsepteerimise. See esitab kitsama väite: simulatsioon parandab deterministlike loogikatõrgete jälgitavust, mida on muidu hilises faasis kulukas tuvastada.

Vooluhulga summeerija vead on sageli põhjustatud halbadest andmetüüpide valikutest. `INT`-tüüpi muutujad kustutavad murdosad, `REAL`-tüüpi muutujad võivad lõpuks kaotada väikesed juurdekasvud suurte summade taustal ja mõlemad tõrked võivad jääda nähtamatuks piisavalt kaua, et kahjustada aruandlust, inventuuri usaldusväärsust ja operaatori usaldust.

Insenertehniline lahendus on põhimõtteliselt lihtne: kasutage signaali jaoks õiget numbrilist arhitektuuri, määratlege enne kasutuselevõttu, mida „õige“ tähendab, ja valideerige käitumist koormuse all. See on erinevus redelprogrammi, mis lihtsalt töötab, ja juhtimisstrateegia vahel, mis püsib tootmises usaldusväärsena.

- IEEE Std 754-2019 — Ujukomaarvude aritmeetika - IEC 61131-3 — PLC programmeerimiskeeled - IEC 61508 Funktsionaalse ohutuse ülevaade - Kritzinger et al. (2018), Digitaalne kaksik tootmises (IFAC) - Tao et al. (2019), Digitaalne kaksik tööstuses (IEEE TII)