Är industrirobotar och kobotar viktiga produkter enligt CRA?

Hur klassificerar du en utgåva av en industrirobot eller kobot?

Börja med erbjudandet, inte armens hårdvara. En 6-axlad arm som säljs till en systemintegratör och samma arm som säljs som en komplett kobotcell till en liten verkstad är olika CRA-produkter. Vägen beror på vad köparen betalar för, vilken styrenhet och operatörspanel som följer med, och om tillverkaren också levererar flottmolnet, säkerhetskonfigurationen och OTA-uppdateringsvägen.

Figuren ovan bär vägvalet. Matrisen nedan bär avgränsningsmemot: när en variant är vald är detta de bevisningsrader som tillverkaren bör kunna fylla i för den specifika varianten.

Använd hjälpmedlet för vägval före du skriver avgränsningsmemot, inte som ersättning. Memot behöver fortfarande den exakta armmodellen, last och räckvidd, styrskåpet, operatörspanelen, programmeringsmiljön, säkerhetskonfigurationens omfattning, flottmolnet, OTA-tjänsten och den avsedda användningen. För en komplett kobotcell, namnge det kollaborativa driftläge som köparen förlitar sig på: hastighets- och separationsövervakning, kraft- och hastighetsbegränsning, handguidning eller säkerhetsklassad övervakad stopp.

Kontrollera sedan om en annan listad funktion gör det verkliga arbetet. CRA behandlar en produkt som viktig när dess kärnfunktion motsvarar en listad kategori; att bädda in en styrenhet flyttar inte i sig en robot till en viktig kategori. Om erbjudandet i huvudsak är en brandväggsgateway, en VPN-utrustning, ett nätverkshanteringssystem, en SIEM-koppling eller en härdad styrenhet byggd kring ett manipuleringsskyddat chip, klassificera den kärnfunktionen först och behandla armen som ett tillbehör.

För komponentförsäljning, tvinga inte in den i kategorin komplett cell. En robotarm som säljs till en systemintegratör är fortfarande en produkt med digitala element och behöver fortfarande bevisning för säker utformning, en uppdateringsväg, en process för sårbarhetshantering, ett uttalande om supportperiod och integratörsriktad dokumentation. Vägen förblir standard; ansvaret delas med integratören.

Klassificeringsmemot bör besvara fyra frågor:

1. Säljs utgåvan som en robotarm, en komplett kobotcell eller en robot integrerad inuti en annan maskin?
2. Är robotrörelse produktens kärnfunktion, eller är det en annan listad funktion (brandvägg, VPN, nätverkshantering, säkerhetsrelaterad mikrokontroller) som gör det verkliga arbetet?
3. Vilka digitala element levereras för den avsedda funktionen: armens firmware, säkerhetskonfiguration, operatörspanel, programmeringsmiljö, OTA-tjänst, flottmoln och process för sårbarhetshantering?
4. Vilka system ligger utanför tillverkarens erbjudande: kundens celllogik, kundens säkerhets-PLC, fabriksnätverk, tredjepartsprogram för bildgivare, kundens MES eller SCADA?

Vad hör hemma inom robotproduktens avgränsning?

För en robottillverkare är efterlevnadsavgränsningen sällan bara armen. Den bör följa produkten som släpps ut på marknaden och de digitala element som behövs för den avsedda rörelse- och säkerhetsfunktionen.

Hantera dessa som normalt inom robottillverkarens avgränsning: armens firmware, ledstyrenhetens firmware, styrskåpets driftmiljö, säkerhetsstyrenhetens firmware, operatörspanel, programmeringsmiljö, OTA-tjänst och process för sårbarhetshantering.

Hantera dessa som normalt utanför om inte tillverkaren säljer dem som del av erbjudandet: kundens celllogik, kundskriven säkerhetskonfiguration, fabriksnätverk, tredjepartsverktyg på armen, tredjepartsprogram för bildgivare, kundens MES eller SCADA och kundens säkerhets-PLC.

Vilken väg för bedömning av överensstämmelse gäller?

Vilka arkitekturkontrollpunkter hör hemma i robotdossiret?

Utgåvedossiret för roboten bör följa den faktiska maskinen, inte en generell OT-checklista. En fristående arm som säljs till en integratör, en kraftbegränsad kobotcell som säljs till en SMF, en robot inbyggd i en förpackningslinje och en robot för renrum med bildgivare kan dela en klassdiskussion samtidigt som de behöver olika tekniska register.

1. Rörelsebehörighetsväg. Identifiera varje väg som kan ändra rörelse, parametrar eller säkerhetskonfiguration: operatörspanel, programmeringsstation, leverantörens moln, leverantörens servicetunnel, USB-överföring, fältbuss från cellstyrenheten och eventuell kanal för fjärrassistans.
2. Lokal exponering. Efter idrifttagning och efter varje uppdatering, skanna styrenheten efter åtkomliga tjänster. Utgåvedossiret bör visa vilka tjänster som är åtkomliga, vilka som kräver autentisering och vilka som är avstängda som standard.
3. Kundsystem. Behandla kundens celllogik, kundens säkerhets-PLC, fabriksnätverk, tredjepartsprogram för bildgivare och MES eller SCADA som utanför robottillverkarens produkt om inte tillverkaren säljer det lagret.
4. Uppdateringsbehörighet. Behandla uppdateringsbehörighet som ett tvåvägsutbyte: styrenheten kontrollerar eller tar emot uppdateringsmetadata, och uppdateringstjänsten returnerar ett signerat firmwarepaket för den exakta styrenhetsvarianten och säkerhetsfirmware-revisionen. Behåll register över signerade uppdateringar, nedgraderingsavslag, maskinpåverkan, återställning och rollback med utgåvan.
5. Leverantörsindata. Ge servo-MCU, givare, säkerhets-MCU, fältbusstack, bildgivarmodul, RT-operativsystem och programmeringsmiljö en namngiven ägare, version, övervakning av råd och utgåvebeslut.
6. Supportåtkomst. Servicetunnlar, diagnostik och fjärrassistanssessioner bör inte bli en andra rörelsebehörighetsväg. Behåll register över tunnelavstängning, redaktion och granskningsstickprov.
7. Loop efter marknadsplacering. Sårbarhetsrapporter, allvarliga incidenter, leverantörsråd och fältfel bör uppdatera hotlistan, registret över kvarstående risk, utgåvedossiret och nästa utgåvegrindbeslut.

Celldiagrammet nedan är avsiktligt bredare än det utarbetade exemplet. Använd det som en gränskontroll för produktfamiljen innan du smalnar av dossiret till den exakta levererade varianten: en 6-axlad arm, en kobot, en variant för renrum, en variant för palletering, och en robot som säljs tillsammans med ett verktyg behöver olika bevisning.

Verkliga OEM-styrenheter som passar denna layout inkluderar ABB OmniCore, KUKA KR C5 (KSS) och KUKA-styrenheter som kör iiQKA.OS, FANUC R-30iB Plus, Yaskawa YRC1000 och Universal Robots PolyScope X. Uppdelningen ovan delas av dem alla: tillverkarens produktdossier håller armen, styrenheten och programvaruavgränsningen på enheten; kundens celllogik, fabriks-LAN och kundägda verktyg stannar utanför om inte tillverkaren också säljer det lagret.

Hur bygger du robotens riskbedömning?

Använd detta exempel för att förstå det förväntade djupet, inte som text att klistra in i en utgåvedossier. En robottillverkare behöver fortfarande köra bedömningen mot sin egen arm, ledmotorer, styrenhet, säkerhetsstyrenhet, operatörspanel, programmeringsmiljö, flottmoln, leverantörer, säljpåståenden, supportperiod och utgåveprocess.

Vilken produkt bedömer vi?

Illustrativt exempelprodukt, inte en verklig enhet: ExampleCo CR-12, en 6-axlad ledad industrirobotarm med 12 kg last och 1300 mm räckvidd, med ett valfritt kraftbegränsat kollaborativt läge. Den levereras med armen, ett styrskåp, en operatörspanel, en valfri 2D-bildgivarsensor, en programmeringsmiljö, signerade OTA-uppdateringar och en anslutning till tillverkarens flottmoln. Den säljs till små och medelstora tillverkare som en komplett cell, och till systemintegratörer som komponent för större maskiner.

Produktavgränsningen för detta exempel inkluderar armen, ledmotorerna, styrskåpet, säkerhetsstyrenheten, operatörspanelen, programmeringsmiljön, OTA-tjänsten, leverantörens molnanslutning, kontakten för sårbarhetsrapportering och redovisningen av supportens slut. Den inkluderar inte kundens celllogik, kundens säkerhets-PLC, fabriksnätverk, tredjepartens MES eller SCADA, tredjepartsverktyg på armen, installation av staket och ljusridå, eller någon AGV- eller AMR-bas.

Produkten är avsedd för inomhus industriell användning av utbildade operatörer och integratörer. Den är inte avsedd för medicinsk eller kirurgisk robotteknik, servicerobotar, utbildningsrobotar eller någon konsumentanvändning.

Innan du skriver hottabellen, testa de tre vägar som vanligtvis driver robotens riskbedömning: programladdning och panelbehörighet, gränsen mellan säkerhet och cyber, och integratörsöverlämningen. Dessa diagram förvandlar det utarbetade exemplet till tekniska frågor i stället för en generell hotlista.

Produktdossierregister: de fem stegregistren plus de fem negativa testresultaten N1–N5 utgör tillverkarens tidslinje för behörighetsändringar. Behåll dem i produktdossiret så att en granskare kan se vem som höll rörelse- eller säkerhetsbehörighet vid varje övergång.

Ägarskap är en separat kontroll från programladdning. En styrenhet kan ha signerade uppdateringar och ändå misslyckas om en servicetunnel förblir öppen efter underhåll, eller om en gammal programmeringsstation fortsätter skriva till den efter en kundöverföring.

Hur skiljer sig attackytan hos en inhägnad industrirobot från en kobots?

Sidan behandlar båda under samma CRA-kategori eftersom de är det: en industrirobot under cyberresilienslagret, inte en smart hem-produkt. Riskprofilen är dock olika, och hotlistan bör återspegla det.

För den utarbetade ExampleCo CR-12 betonar den inhägnade konfigurationen programmeringsstationens behörighet, återställningsplatsens integritet och byte av inloggningsuppgifter vid avveckling. Kobotkonfigurationen lägger till autentisering av bildgivarindata, kalibreringsdataintegritet, manipuleringstestning av separationsövervakning och en panelens rollagring per operatör som förstaklassiga frågor.

Vilka tillgångar skyddar vi?

Börja riskbedömningen med tillgångar eftersom robothot inte alla handlar om samma sak. En förlust av rörelseintegritet, en kompromettering av säkerhetskonfigurationen och ett övertagande av programmeringskanalen behöver olika kontroller och olika utgåveregister.

Var är de huvudsakliga förtroendegränserna?

För detta exempel bör tillverkaren modellera minst fem miljöer. Poängen är inte att rita varje tråd; den är att separera platser där angriparens möjlighet ändras: inuti skåpet, på panellänken, på fabriksnätverket, i tillverkarens backend och på programmeringsstationen.

Säkerhetsstacken och cyberstacken är inte samma projekt. De delar bevisning vid specifika punkter; dossiret måste vara tydligt om vem som äger vilken klausul.

Vilka hot bör utvärderas först?

Detta exempel börjar med fjorton produktspecifika hot. Poängen är inte att vara uttömmande; den är att visa den nivå av spårbarhet som en tillverkare bör kunna försvara.

Titta sedan på integratörsöverlämningen separat. Vem räknas som tillverkare för den resulterande cellen, och vilka register måste följa med den.

Hur bör de inledande riskerna rangordnas?

Använd en stege för utgåvegrindar så att varje risk inte får samma beslut:

Vilka designkontroller ändrar riskbilden?

Kontrollistan bör vara spårbar tillbaka till R-ID:n, men den bör inte läsas som en generell checklista för säker utveckling. För varje kontroll bör tillverkaren kunna visa testet, designanteckningen eller driftregistret som bevisar att kontrollen finns för just denna utgåva.

Vilken kvarstående risk återstår efter kontroller?

Efter kontroller bör tillverkaren köra om bedömningen i stället för att markera hot som klara. I detta exempel förblir leverantörssårbarhetsvägen, integratörsöverlämningen och den långa produktlivslängden aktivt hanterade under supportperioden. Den kvarstående risken är acceptabel endast om tillverkaren kan visa att processer för övervakning, triage, leverans av signerade uppdateringar, integratörsmeddelande och korrigerande åtgärd faktiskt fungerar.

Hur bör råd från flottmolnet routas?

Riskbedömningen ovan körs på ett robotskåp. Rådroutningen körs över hundratals. När tillverkarens flottmoln betjänar flera integratörer och flera operatörsplatser är frågan inte "är molnet säkert" utan "när en 24-timmars sårbarhetsvarning utlöses, vem i kedjan hör det och vem godkänner uppdateringsfönstret för varje plats".

Utgåveregister. En routingskarta för flottmolnet som för varje integratör och operatör på anslutningslistan namnger kontakten för 24-timmars sårbarhetsvarningar, ägaren av underhållsfönstret, rollback-behörigheten och kvarstående råd som fortfarande är öppna. Utan denna karta löper deadlinen mot en saknad mottagare.

Vilka valideringsgrindar körs före utgåva?

Undvik en generell "säkerhetsgranskad" grind. Använd en inventering av utgåvegrindar med felläge, designkontroll och bevisartefakt för varje beslut som kan stoppa robotleveransen.

Vem äger robotutvecklingen från koncept till support?

Ledägarskapet skiftar när roboten rör sig från produktdefinition till levande support. Använd denna räls för att tilldela en ledare, ett underhållet register och en granskningsgrind vid varje steg medan produkten ändras.

Ägarskapsregel: detta är en ledkedja, inte en fullständig ansvarsmatris. Varje ledare äger det underhållna registret medan roboten ändras; supportfynd loopar tillbaka till nästa avgränsningsmemo för varianten och hotlista.

Frys avgränsningen före arkitekturarbetet, frys designintentionen före implementering, frys kandidaten före verifiering, frys beslutet före utgåva, och håll utgåvan i drift genom supportperioden. Inkommande rapporter, leverantörsråd, incidentutfall och regressionsresultat öppnar nästa avgränsningsmemo, hotlista och komponentregister.

Vilka bevisningsregister hör hemma i dossiret?

Dossiret bör låta en granskare följa robotbeslutet från produktidentitet till säkerhetskontroller. Varje rad nedan bör peka till ett underhållet register, inte till en mapp med osammanhängande skärmbilder.

Vad ingår i en SBOM för robotar?

CRA kräver en maskinläsbar SBOM som identifierar produktens komponenter och täcker minst beroenden på toppnivå, men namnger inte ett fast format än. Tills kommissionen specificerar mer detalj väljer robottillverkare normalt CycloneDX eller SPDX. Detaljerna om SBOM-mekanik över produkter finns i den dedikerade SBOM-guiden; detta avsnitt täcker robotspecifika trädet.

En robotutgåva levererar vanligtvis flera digitala element med separata uppdateringscykler, inte en binärfil. Två implementeringsmönster uppfyller CRA:s minimum: en SBOM på produktnivå med elementseparerade sektioner (varje rörelse-CPU, säkerhetsstyrenhet, RT-OS och paneliometernyverversion fastlåst), eller en SBOM per levererat digitalt element som uppdateras vid varje utgåva. Båda mönstren är godtagbara så länge SBOM:en är maskinläsbar och beroenden på toppnivå täcks.

SBOM-register: en maskinläsbar SBOM i CycloneDX eller SPDX som täcker minst beroenden på toppnivå. Rekommenderade mönster för robottillverkare: en SBOM på produktnivå med elementseparerade sektioner, eller en SBOM per levererat digitalt element som uppdateras vid varje utgåva. Djupare transitiva beroenden rekommenderas där byggsystemet kan producera dem. Para SBOM:en med övervakningsregistret för komponentråd (bevisningskartans rad "Komponentförteckning") så att en granskare kan se vilket bibliotek en känd sårbarhet landar i och vilken utgåva som stänger den.

Vad kontrollerar utgåvegodkännandet?

Innan roboten släpps på EU-marknaden bör godkännandet stänga samma fyra registermappar som SVG:n nedan namnger Q1 till Q4. Den fullständiga dossierinventeringen finns i bevisningskartan ovan; denna tabell är bara de fyra utgåvespärrade frågorna.

Godkännandegrind: om ett register saknas är utgåvan inte godkänd.

Försäkran-register: använd huvudguiden för EU-försäkran om överensstämmelse för mallen och obligatoriska fält. För en robotutgåva bör produktidentiteten fastlåsa armen, styrskåpet, operatörspanelen, firmwaregrenen, levererade tillval och referensen till supportperioden. Om samma försäkran också täcker maskinlagstiftning, namnge den vägen i försäkran och håll robotens tekniska dossier och maskinsäkerhetsdossiret samstämmiga.

Hur lämnas roboten över till importör, distributör, integratör och operatör?

Utgåvedossiret bör göra överlämningen från robottillverkare till importör, distributör, integratör-som-tillverkare och slutanvändare testbar. För robotar och kobotar är den svaga punkten vanligtvis inte CE-märket ensamt; det är om leveransen, manualen, flottmolnet, OTA-tjänsten och integratörsöverlämningen fortfarande matchar den bedömda utgåvan.

Överlämningsgrind: flytta inte roboten från leverans till listning när paketet, spårbarheten, supportuttalandet, flottmolnet, uppdateringskanalen, rollidentiteten eller en känd sårbarhet är i konflikt med den bedömda utgåvan.

Raderna nedan är den korta versionen: vad som ska verifieras, när det ska pausas, när roboten behöver en ny rollanalys. Detaljerna om utlösare för roller över produkter (tillverkare, importör, distributör, auktoriserad representant, förvaltare av öppen källkod) finns i Vem måste följa CRA.