Kuidas valideerida koostöörobotite rakendusstandardeid 2026. aastal digitaalsete kaksikute abil

1. aasta koostöörakenduste standarditega vastavusse viimiseks peavad OEM-tootjad valideerima kogu robotrakenduse, mitte ainult robotkäe. Praktikas tähendab see PLC ohutusloogika, tsoonide seire, peatumiskäitumise ja tööruumi interaktsioonide testimist digitaalse kaksiku abil, mis näitab, kas kavandatud ohutusjärjestus vastab masina füüsilisele käitumisele.

Koostöörobot ei ole automaatselt ohutu koostöörakendus. See eristus on 2026. aasta arutelude keskmes ja just siin tekivad sageli nõrgad ohutuseeldused.

Hiljutine Ampergon Vallis valideerimiskatse kaubaaluste virnastamise stsenaariumis näitas, et simuleeritud LiDAR-tsooni rikkumine kiirusel 1,6 m/s nõudis juhtimisjärjestuses täiendavat 140 ms aeglustusvaru, et vältida virtuaalset kokkupõrget. [Metoodika: 12 korduvat katset ühe kaubaaluste virnastaja digitaalse kaksiku ülesandega, võrrelduna sama loogikaga ilma lisatud aeglustusvaruta, vaadeldud 2026. aasta I kvartalis.] See toetab ühte kitsast punkti: ajastusvarud, mis näivad staatilises loogikaülevaates vastuvõetavad, võivad ebaõnnestuda, kui liikumine ja inerts on modelleeritud. See ei toeta ühtegi üldist väidet kõigi robotielementide, kõigi koormuste ega ametliku vastavuse kohta.

Praktiline probleem on lihtne. Ohutusloogika, mis näeb redeldiagrammi redaktoris korrektne välja, võib reaalses tööruumis siiski hiljaks jääda.

Ohutu robot ja ohutu koostöörakendus ei ole sama asi. ISO 10218 raamistiku ja sellega seotud koostööjuhiste kohaselt hinnatakse ohutust rakenduse tasemel, mitte ei anta seda ainult manipulaatori põhjal.

See tähendab, et ohutusjuhtum peab hõlmama kogu töötavat süsteemi:

• robotmanipulaatorit,
• lõppseadet või tööriistu,
• töödeldavat detaili või koormat,
• tööruumi paigutust,
• seirearhitektuuri,
• ja juhtimisloogikat, mis reguleerib interaktsiooni olekuid.

See on oluline, sest koostööks turustatav robotkäsi võib muutuda ohtlikuks, kui see kannab teravat haaratsit, keevituspõletit, rasket kasti või jäika lehtmetallist osa. Sisemine jõu piiramine ei neutraliseeri kõiki rakendusega seotud ohte.

Kolm rakenduse elementi, mis muudavad ohutusjuhtumit

Rakenduse tasemel riskipilt muutub oluliselt, kui lisatakse järgmised elemendid:

- Manipulaator: Ulatus, kiirus, peatumiskäitumine, telje liikumine ja juhtimisliidesed. - Lõppseade/tööriistad: Muljumiskohad, teravad servad, termilised ohud, salvestatud energia, vaakumi kadu või haaramise ebaõnnestumine. - Töödeldav detail/koormus: Mass, geomeetria, inerts, kukkumisoht ja sekundaarse kokkupõrke oht.

ISO/TS 15066 kasutatakse tavaliselt juhisena koostööks, eriti seoses kokkupuutepiirangute ja rakenduse hindamisega, samas kui ISO 10218-1 ja ISO 10218-2 määratlevad laiema roboti ja integratsiooni raamistiku. Peamine insenertehniline järeldus on stabiilne: integraator peab valideerima rakenduse käitumise kontekstis, mitte lihtsalt pärima robotitootja turunduskeelt.

Neli koostöörežiimi on ohutusega seotud seiratud seiskamine (Safety-Rated Monitored Stop), käsitsi juhtimine (Hand Guiding), kiiruse ja vahemaa seire (Speed and Separation Monitoring) ning võimsuse ja jõu piiramine (Power and Force Limiting). Need on standardsed võrdlusrežiimid, mida kasutatakse koostöörobotite rakenduste kavandamisel.

Juhtimisinseneride jaoks on oluline eristus see, et need ei ole lihtsalt sildid. Need eeldavad erinevaid seirearhitektuure, erinevat juhtimiskäitumist ja erinevaid valideerimiskohustusi.

1. Ohutusega seotud seiratud seiskamine (SMS)

Ohutusega seotud seiratud seiskamine tähendab, et robot peatub, kui inimene siseneb koostööruumi, samas kui liikumise taaskäivitamine on kontrollitud ja tingimuslik.

Tüüpilised juhtimisega seotud tagajärjed hõlmavad:

• ohutussisendit skannerist, väravast või tsooniseadmest,
• ohutu seiskamise käskude teed,
• lähtestamise ja taaskäivitamise lubasid,
• tõendit, et liikumine jääb blokeerituks, kui personal on kohal.

2. Käsitsi juhtimine (HG)

Käsitsi juhtimine võimaldab operaatoril roboti liikumist otse juhtida, kasutades spetsiaalset lubavat seadet ja piiratud töötingimusi.

Tüüpilised juhtimisega seotud tagajärjed hõlmavad:

• lubava seadme valideerimist,
• piiratud töörežiimi valikut,
• piiratud kiiruse või jõu käitumist,
• juhendatud üleminekut käsitsi juhtimise režiimi ja sellest välja.

3. Kiiruse ja vahemaa seire (SSM)

Kiiruse ja vahemaa seire tähendab, et roboti kiirust kontrollitakse dünaamiliselt nii, et robotisüsteemi ja inimese vahel säilitatakse minimaalne kaitsekaugus.

Tüüpilised juhtimisega seotud tagajärjed hõlmavad:

• piirkonnaskanneri või visuaalsete tsoonide sisendeid,
• kiiruse vähendamise olekuid,
• ohutu seiskamise olekuid, kui vahemaa on rikutud,
• dünaamilisi üleminekuid normaalse, vähendatud ja peatatud liikumise vahel.

4. Võimsuse ja jõu piiramine (PFL)

Võimsuse ja jõu piiramine tähendab, et rakendus on kavandatud nii, et kokkupuute korral jääb see määratletud tingimustel vastuvõetavatesse biomehaanilistesse piiridesse.

Tüüpilised juhtimisega seotud tagajärjed hõlmavad:

• valideeritud jõu- või pöördemomendi piiranguid,
• koormuse ja tööriistade piiranguid,
• kiiruse piiranguid,
• rakendusepõhist vigastusohu hindamist.

PFL-i mõistetakse sageli valesti kui "robotit on ohutu puudutada". See on liiga üldine, et olla kasulik. Tegelik küsimus on selles, kas rakendus jääb määratletud töötingimustes vastuvõetavatesse piiridesse.

SSM-loogika programmeerimine nõuab enamat kui skanneri biti sidumist seiskamismähisega. Loogika peab arvestama inimese lähenemist, roboti kiirust, reageerimisaega, peatumisteekonda ning hoiatuse, vähendatud kiiruse ja seiskamise olekute vahelisi üleminekureegleid.

Levinud kaitsekauguse valem on:

S = (v_h × T_r) + (v_r × T_r) + C

Kus:

• S = kaitsekaugus
• v_h = inimese lähenemiskiirus
• v_r = roboti lähenemiskiirus
• T_r = süsteemi kogureageerimisaeg
• C = täiendav sissetungi või mõõtmise kompensatsioonitegur

Täpne rakendusmeetod sõltub seirearhitektuurist ja kohaldatavast riskihindamisest, kuid insenertehniline põhimõte on stabiilne: kui reageerimisaega alahinnatakse, ei ole kaitsekaugus usaldusväärne.

Mida peaks redeldiagrammi loogika SSM-rakenduses tegema?

Vähemalt peaks redeldiagrammi loogika haldama järgmisi olekuüleminekuid:

- Normaalne töö: Täiskiirusel liikumine on lubatud, kui ükski kaitsetsoon ei ole rikutud. - Hoiatustsooni sisenemine: Käsk vähendada kiirust ja kontrollida, kas robot kinnitab vähendatud kiiruse olekut. - Kaitsetsooni sisenemine: Käivitada nõutav ohutu seiskamise funktsioon ja blokeerida ohtlik liikumine. - Tsoon vaba: Hoida taaskäivitamise tingimusi, kuni lähtestamine, kinnitus või protseduurilised load on täidetud. - Rikkeolek: Vaikimisi ohutusse olekusse, kui skanneri tervis, side või ohutussisendi kehtivus on kadunud.

Näide redeldiagrammi loogikast ohutustsooni rikkumise korral

|---[ LiDAR_Healthy ]---[ Safety_Zone_Breach ]-----------------(TON Debounce_150ms)---| |---[ Debounce_150ms.DN ]--------------------------------------(CMD_Safe_Stop_Cat1)---| |---[ Debounce_150ms.DN ]--------------------------------------(INH_Motion_Enable)----| |---[/ LiDAR_Healthy ]-----------------------------------------(CMD_Safe_Stop_Cat0)---| |---[ Warning_Zone_Breach ]---[/ Safety_Zone_Breach ]---------(CMD_Reduced_Speed)----|

See muster on tahtlikult lihtne. Reaalses projektis peavad seiskamiskategooria, diagnostiline katvus, lähtestamiskäitumine ja ohutusarhitektuur vastama riskihindamisele ja ohutusega seotud alamsüsteemi kavandile.

Debounce-taimer väärib lühikest kommentaari. See on mõeldud mürarikastest tsooniüleminekutest tingitud häirete vähendamiseks, mitte ohtliku signaalitee põhjendamatuks viivitamiseks. Ohutusfiltreerimist tuleb põhjendada.

Kuidas peaksid insenerid käsitlema vaigistusloogikat (muting)?

Vaigistusloogika peab eristama oodatud materjali liikumist inimese sissetungist, ilma et see nõrgendaks kaitsefunktsiooni. See tähendab tavaliselt:

• konkreetse konveieri või etteande tingimuse määratlemist, mis lubab vaigistamist,
• vaigistamise piiramist ajaliselt ja suunaliselt,
• tõestamist, et inimese sisenemine tekitab endiselt nõutava kaitsemeetme,
• häire andmist või rikke tekitamist ebanormaalse vaigistuse kestuse korral.

Digitaalsed kaksikud on praktikas vajalikud, sest staatiline loogikaülevaade ei suuda tõestada liikumise ohutust realistlikes rikketingimustes. Koostöörakenduste puhul ei ole asjakohane küsimus ainult "mida PLC kavatseb?", vaid "mis juhtub füüsiliselt enne, kui masin jõuab ohutusse olekusse?".

Selles artiklis tähendab digitaalse kaksiku valideerimine: PLC redeldiagrammi loogika sidumist kinemaatikaga 3D-mudeliga, et jälgida erinevust kavandatud ohutusjärjestuse ja füüsilise aeglustuskäitumise vahel rikkeoleku ajal.

See on operatiivne määratlus.

Mida digitaalse kaksiku valideerimine suudab näidata, mida staatiline ülevaade sageli ei näe

Nõuetekohaselt konfigureeritud simulatsioon võib paljastada:

• aeglustusviivituse pärast seiskamiskäsku,
• koormusest sõltuvad peatumiserinevused,
• tsooni rikkumise ajastusvead,
• skanneri signaali kadumise käitumise,
• võistlusolukorrad kiiruse vähendamise ja seiskamiskäskude vahel,
• taaskäivitamise lubade vead,
• redeldiagrammi oleku ja füüsilise seadme oleku mittevastavuse.

Siin muutub OLLA Lab operatiivselt kasulikuks.

OLLA Labi on siinkohal kõige parem mõista kui piiratud valideerimis- ja harjutuskeskkonda. Insenerid saavad luua redeldiagrammi loogikat brauseris, käivitada seda simulatsioonirežiimis, kontrollida I/O-d ja muutujaid ning jälgida mõju 3D- või WebXR-seadmete mudelitele, mis esindavad realistlikke tööstuslikke stsenaariume. Selles töövoos ei ole toode vastavuse generaator ega asendus ametlikule ohutushindamisele. See on koht, kus saab ohutult ja korduvalt esile kutsuda ebanormaalseid tingimusi enne, kui füüsiline kasutuselevõtt muutub kulukamaks.

Miks on ainult füüsiline testimine halb esimene samm

Kiirete tsoonirikkumiste füüsiline testimine on piiratud ilmselgete kitsaskohtadega:

• see seab personali ja seadmed välditavale ohule,
• seda on raske identse ajastusega korrata,
• see võib riistvara kahjustada,
• see julgustab meeskondi testima ainult "mõistlikke" juhtumeid,
• ja see toimub sageli liiga hilja, pärast seda, kui mehaanilised ja ajakavaga seotud kohustused on juba fikseeritud.

Mida tähendab "simulatsioonivalmidus" selles kontekstis

Simulatsioonivalmidus ei tähenda PLC süntaksi tundmist või 3D-vaaturis mugavalt tundmist. See tähendab, et insener suudab tõestada, jälgida, diagnoosida ja karastada juhtimisloogikat realistliku protsessikäitumise vastu enne, kui see jõuab reaalprotsessini.

Simulatsioonivalmidusega inseneri jälgitavad käitumisviisid hõlmavad:

• "õige" määratlemist enne testimist,
• I/O muutuste jälgimist läbi redeldiagrammi oleku ja masina reaktsiooni,
• rikete tahtlikku sisestamist,
• käsuoleku võrdlemist simuleeritud seadme olekuga,
• loogika muutmist pärast ebanormaalset käitumist,
• ja dokumenteerimist, miks muudatus parandab juhtimistulemust.

OEM-tootjad saavad kasutada OLLA Labi riskikontrollitud liivakastina kõrge riskiga loogikakäitumiste harjutamiseks, mida on raske, kulukas või ohtlik esmalt füüsilisel riistvaral testida.

Toote dokumenteeritud ulatuse piires hõlmab see:

• redeldiagrammi loogika koostamist veebipõhises redaktoris,
• loogika käivitamist ja peatamist simulatsioonirežiimis,
• sisendite lülitamist ja väljundite jälgimist,
• muutujate, analoogväärtuste ja PID-ga seotud olekute jälgimist,
• loogika valideerimist 3D- või WebXR-masinamudelite vastu,
• ja stsenaariumipõhiste järjestuste, ohtude, blokeeringute ja kasutuselevõtu märkmete läbitöötamist.

Koostöörakenduste puhul toetab see praktilist valideerimise töövoogu, näiteks:

1. Koostage ohutusega seotud olekuloogika hoiatuse, vähendatud kiiruse, seiskamise, lähtestamise ja rikketingimuste jaoks.
2. Siduge loogikakäitumine masina stsenaariumiga, mis hõlmab liikumist ja tööruumi interaktsiooni.
3. Sisestage skanneri rikkumised, side kadumine, koormuse muutused või taaskäivitamise äärmuslikud juhtumid.
4. Jälgige, kas simuleeritud masina olek vastab kavandatud ohutusjärjestusele.
5. Muutke ajastust, lubasid või rikete käsitlemist.
6. Säilitage tõendusmaterjal.

Väärtus ei seisne selles, et simulatsioon asendab kohapealset testimist. Väärtus seisneb selles, et see kõrvaldab välditava teadmatuse enne kohapealse testimise algust.

Simulatsioon peaks aitama kaasa vastavusotsuse paketile kui insenertehniline tõendusmaterjal, mitte kui dekoratiivne lisa. Audiitoreid ja ohutuse hindajaid veenab jälgitav arutluskäik, piiratud testitõendid ja muudatuste ajalugu, mitte kaustatäis ekraanipilte.

Kasutage seda kompaktset tõendusstruktuuri:

1) Süsteemi kirjeldus

Dokumenteerige:

• lahtri eesmärk,
• roboti ülesanne,
• tööriistad ja koormus,
• seireseadmed,
• ohutusfunktsioonid,
• töörežiimid,
• ja kavandatud inimese interaktsiooni piir.

2) "Õige" operatiivne määratlus

Määratlege jälgitavad läbimiskriteeriumid, näiteks:

• vähendatud kiiruse käsk toimub hoiatustsooni tingimustes,
• ohtlik liikumine on blokeeritud kaitsetsooni rikkumisel,
• taaskäivitamine nõuab lähtestamist ja kõigi lubade tõesust,
• skanneri tervise kadumine sunnib süsteemi ohutusse olekusse,
• simuleeritud peatumiskäitumine jääb kaitstud ümbriku sisse.

Kui "õige" ei ole määratletud jälgitavates terminites, ei ole test kuigi kasulik.

3) Redeldiagrammi loogika ja simuleeritud seadme olek

Säilitage:

• testitud redeldiagrammi versioon,
• muutuja ja I/O olek igal üleminekul,
• vastav masina liikumine või seiskamiskäitumine digitaalses kaksikus,
• ja kõik asjakohased analoog- või ajastusväärtused.

See on peamine võrdlus: redeldiagrammi olek versus seadme olek.

4) Sisestatud rikkejuhtum

Märkige täpselt, mida sisestati, näiteks:

• hoiatustsooni rikkumine täiskiirusel liikumise ajal,
• kaitsetsooni rikkumine maksimaalse koormuse liikumise ajal,
• skanneri side kadumine,
• vale-vaba üleminek,
• taaskäivitamise taotlus puudulike lubadega,
• või vaigistamine aktiivne ootamatu inimese sisenemise ajal.

5) Tehtud muudatus

Dokumenteerige tegelik insenertehniline muudatus:

• debounce-reguleerimine,
• seiskamiskategooria muutus,
• muudetud kiiruse vähendamise lävi,
• lisatud tervisekontrolli luba,
• lähtestamisjärjestuse korrigeerimine,
• või muudetud blokeeringu struktuur.

6) Saadud õppetunnid

Jäädvustage, mida test paljastas, näiteks:

• reageerimisaja eeldused olid optimistlikud,
• koormuse inerts muutis ohutut ajastusvaru,
• skanneri tervis vajas selgesõnalist rikete käsitlemist,
• või olekuüleminekud olid loogiliselt kehtivad, kuid füüsiliselt hilinenud.

See tõendusmaterjal on üldiselt usaldusväärsem kui lihvitud armatuurlaud, mille taga puudub testiloogika.

Standardite alus peab olema selgesõnaline. Koostöörakendused asuvad roboti ohutuse, funktsionaalse ohutuse ja rakendusepõhise riskihindamise ristumiskohas.

Tavaliselt asjakohased viited hõlmavad:

• ISO 10218-1 / ISO 10218-2 tööstusrobotite ja integratsiooni ohutusnõuete jaoks.
• ISO/TS 15066 koostöörobotite rakenduste juhiste jaoks.
• IEC 61508 elektri-, elektroonika- ja programmeeritavate süsteemide laiema funktsionaalse ohutuse raamistiku jaoks.
• Tehnilised juhised organisatsioonidelt nagu exida ja tunnustatud masinaohutuse praktikud rakendamise tõlgendamiseks.
• Eelretsenseeritud kirjandus digitaalsete kaksikute, küberfüüsilise valideerimise ja tööstusliku simulatsiooni kohta allikatest nagu IFAC-PapersOnLine, Sensors ja seotud tootmissüsteemide ajakirjad.

Hoiatus on väärt selgelt väljaütlemist: ükski simulaator, sealhulgas OLLA Lab, ei anna vastavust seose kaudu. Vastavus sõltub terviklikust rakenduse kavandist, riskihindamisest, rakendatud ohutusarhitektuurist, valideerimiskirjest ja lõplikest paigaldustingimustest.

OEM-meeskonnad peaksid lõpetama küsimise, kas robot on koostöövõimeline, ja hakkama küsima, kas rakenduse käitumine on rikketingimustes tõestatavalt ohutu.

Praktiline järjestus on:

• määratlege koostöörežiim,
• tuvastage kaitsefunktsioonid,
• modelleerige peatumis- ja vahemaakäitumist,
• valideerige redeldiagrammi loogikat realistliku masina liikumise vastu,
• sisestage ebanormaalsed olekud enne kohapealset kasutuselevõttu,
• ja säilitage jälgitav tõendusmaterjali pakett.

See on erinevus usutava ja kaitstava projekti vahel.

- ISO 10218 robotite ja robotseadmete standardite leht - ANSI/RIA R15.06 ülevaade - IEC 61508 Funktsionaalse ohutuse ülevaade - NIST Cybersecurity Framework 2.0 - Digitaalse kaksiku alused (IEEE Access)