Czy roboty przemysłowe i coboty to produkty ważne według CRA?
Podsumowanie
Ten przewodnik prowadzi fikcyjną wersję cobota od klasyfikacji przez granicę produktu, ocenę ryzyka, SBOM, podpisanie wydania, zgłaszanie podatności aż po przekazanie między operatorami gospodarczymi. Ta sama struktura sprawdza się dla 6-osiowego ramienia, celi współpracującej lub kontrolera robota sprzedawanego z opcjonalną wizją i usługami chmury floty.
- Ścieżka standardowa jest punktem wyjścia. Roboty przemysłowe i coboty nie figurują dziś na listach CRA produktów ważnych ani krytycznych. Traktuj jako odrębną klasyfikację każdą ofertę, w której dominują funkcje zapory, zarządzania siecią lub kontrolera odpornego na ingerencje.
- Zacznij od memorandum granicznego. Nazwij dokładnie wariant: ramię, szafa sterownicza, panel programowania, opcje magistrali polowej, środowisko uruchomieniowe, łącznik floty lub chmury, przewidziane zastosowanie, dostarczone elementy cyfrowe, okres wsparcia i powód wybranej ścieżki.
- Cyberbezpieczeństwo i bezpieczeństwo maszyn krzyżują się od 2027 r. Norma ISO 10218-1:2025 dokłada wymagania cyberbezpieczeństwa tam, gdzie wpływają na bezpieczeństwo robota, a Rozporządzenie Maszynowe obowiązuje od 20 stycznia 2027 r. Dokumentacja CRA i dokumentacja bezpieczeństwa dzielą w tych punktach wspólne dowody.
- Wsparcie wymaga wiarygodnej daty. Okres wsparcia wynosi co najmniej pięć lat, chyba że przewidziany czas użytkowania jest krótszy. Wiele robotów pracuje w fabryce znacznie dłużej, więc dokumentacja musi wskazać okno, które producent jest w stanie utrzymać, i ogłosić datę końca wsparcia przed zakupem.
- Zarządzanie podatnościami to model operacyjny. Dokumentacja musi wskazać, kto odbiera alerty, kto zatwierdza okna serwisowe, kto może wycofać aktualizację i jak pozostają widoczne ostrzeżenia rezydualne.
- Przekazanie też jest dowodem. Producent zachowuje dokumentację produktu; integrator zachowuje dokumentację gotowej celi, gdy wychodzi pod jego nazwą; operator eksploatuje celę. Każde przekazanie się dokumentuje, nie przerzuca nieformalnie na klienta.
Jak klasyfikować wydanie robota przemysłowego lub cobota?
Zacznij od oferty, nie od ramienia. 6-osiowe ramię sprzedane integratorowi i to samo ramię sprzedane jako kompletna cela cobota małemu warsztatowi to różne produkty CRA. Ścieżka zależy od tego, co kupuje klient, jaki kontroler i panel programowania dostarcza producent oraz czy producent dostarcza także chmurę floty, konfigurację bezpieczeństwa i ścieżkę aktualizacji OTA.
Rysunek ustala ścieżkę. Macierz ustala memorandum graniczne: po wybraniu wariantu, są to wiersze dowodowe, które producent powinien wypełnić dla danego wariantu.
Sprzedaż jako komponent; integrator buduje celę.
Ramię, kontroler, panel programowania, środowisko uruchomieniowe, opcje magistrali polowej, podpisane aktualizacje, proces zarządzania podatnościami i instrukcja dla integratora.
Uprawnienia zapisu stacji inżynierskiej, slot odtwarzania, ekspozycja magistrali polowej, śledzenie ostrzeżeń dostawców i rotacja poświadczeń przy wycofaniu celi.
Współpracujące ramię o ograniczonej sile, konfiguracja gotowa do użytku, opcjonalna wizja i chmura floty.
Ramię, kontroler, panel programowania, konfiguracja bezpieczeństwa, sensor wizji, środowisko uruchomieniowe, łącznik chmury floty i usługa OTA.
Tryb współpracujący, rola operatora we wspólnej przestrzeni, uprawnienia chmury floty, konta panelu i ścieżka podpisanego firmware bezpieczeństwa.
Odsprzedaż w linii pakującej lub maszynie procesowej pod oznakowaniem CE integratora.
Producent robota zachowuje w swojej dokumentacji ramię, kontroler, panel programowania i dostarczone oprogramowanie. Gotowa maszyna ma własną dokumentację pod oznakowaniem CE integratora.
Ostrzeżenia dostawców dla RT OS, magistrali polowej i wizji; spójność deklaracji zgodności dostawców; ekspozycja podczas integracji; dopasowanie wsparcia z producentem maszyny.
Co wchodzi w granicę produktu robota?
Dla robota lub cobota granica nie zawsze pokrywa się z ogrodzeniem celi. Pokrywa się z tym, co producent dostarcza i utrzymuje: ramię, szafa sterownicza, firmware, środowisko uruchomieniowe, panel programowania, podpisane aktualizacje, łącznik chmury i dokumentacja użytkownika. To, co wnosi klient lub integrator, leży domyślnie poza granicą, chyba że producent dostarcza to jako część oferty.
Jaka ścieżka oceny zgodności obowiązuje?
Roboty przemysłowe i coboty nie figurują dziś na listach CRA produktów ważnych ani krytycznych, więc ścieżka standardowa jest hipotezą planistyczną. Producent może wybrać kontrolę wewnętrzną, badanie UE typu wraz ze zgodnością z typem, pełne zapewnienie jakości lub mający zastosowanie europejski program certyfikacji cyberbezpieczeństwa. Wybór nie zależy od stosowania norm zharmonizowanych.
Warunek „pełnego stosowania norm" należy do ścieżki rezerwowej dla produktów ważnych, nie do ścieżki domyślnej. Gdyby przyszła aktualizacja dodała podprodukt robota lub cobota do tej listy, a dostępne normy lub programy nie obejmowały istotnych wymagań zasadniczych, producent potrzebowałby ścieżki oceny przez stronę trzecią dla nieobjętej części. Lista nie zawiera dziś robotów.
Rozporządzenie Maszynowe 2023/1230 obowiązuje od 20 stycznia 2027 r. i zawiera wymagania bezpieczeństwa pokrywające się z dowodami cyber, zwłaszcza ochronę przed zakłóceniem i niezawodność systemów sterowania. Traktuj dokumentację CRA i dokumentację bezpieczeństwa maszyny jako dwie nitki tej samej teczki produktowej.
Które kontrole architektury należą do dokumentacji robota?
Dokumentacja musi pokazywać, jak producent panuje nad punktami, w których polecenie cyfrowe może zmienić ruch, konfigurację bezpieczeństwa lub stan aktualizacji.
| Punkt architektury | Co się sprawdza | Minimalny dowód |
|---|---|---|
| Kontroler i CPU ruchu | Kto może zapisywać logikę, parametry i firmware | Model uprawnień, podpis firmware, dziennik zmian |
| Panel programowania | Które role mogą poruszać robotem, ładować program lub zmieniać tryb | Macierz ról, dowód poświadczeń, audyt sesji |
| Magistrala polowa | Jaki ruch może wpływać na cykl ruchu | Lista protokołów, reguły segmentacji, próba ramek anomalii |
| Chmura floty | Jakie uprawnienia zdalne istnieją dla aktualizacji i telemetrii | Mapa punktów połączenia, certyfikaty, okno serwisowe, wycofanie |
| Serwis lokalny | Jak kontroluje się USB, odtwarzanie i tunele tymczasowe | Tryb serwisowy, dziennik interwencji, dowód automatycznego zamknięcia |
Jak zbudować ocenę ryzyka robota?
Jaki produkt oceniamy?
Przykład używa kompletnej celi cobota sprzedanej MŚP: ramię o ograniczonej sile, kontroler, panel programowania, przygotowana konfiguracja bezpieczeństwa, opcjonalna wizja, łącznik chmury floty, podpisane aktualizacje i dokumentacja użytkownika. Nie ocenia ani pełnej linii zakładowej, ani celi zaprojektowanej przez integratora, poza punktami przekazania.
| Decyzja zakresu | Wybór przykładu | Dlaczego ma znaczenie |
|---|---|---|
| Wariant | Kompletna cela cobota | Producent zachowuje całość dokumentacji produktu |
| Granica cyfrowa | Kontroler, panel, firmware, wizja, chmura, OTA | To, co może zmienić ruch, konfigurację lub dostępność |
| Klient | MŚP-operator | Mniejszy zespół bezpieczeństwa, większa zależność od producenta |
| Integrator | Może instalować, nie zmienia oznaczenia produktu | Przekazanie istnieje, ale nie przesuwa automatycznie dokumentacji |
Przed zapisaniem tabeli zagrożeń sprawdź trzy ścieżki, które najczęściej decydują o ryzyku robota: ładowanie programu i uprawnienia panelu, granicę między bezpieczeństwem funkcjonalnym a cyberbezpieczeństwem oraz przekazanie integratorowi. Rysunek zmienia przykład w pytania inżynierskie, nie w generyczną listę zagrożeń.
Jak zmienia się powierzchnia ataku między robotem ogrodzonym a cobotem?
| Powierzchnia | Robot przemysłowy ogrodzony | Cobot o ograniczonej sile |
|---|---|---|
| Bliskość człowieka | Wyłączona przez ogrodzenie, kurtynę lub blokadę | Ciągła; monitorowanie siły, prędkości lub separacji wchodzi w skład dokumentacji bezpieczeństwa |
| Dostęp do panelu | Zwykle wewnątrz zamkniętej celi | Wspólna przestrzeń, często z aktywną rolą operatora |
| Wejście wizji | Opcjonalne i miejscowe | Częste, czasem centralne dla bezpieczeństwa i operacji |
| Teleoperacja | Rzadsza | Coraz powszechniejsza w wybranych liniach |
| Najczęstszy aktor | Serwis, inżynieria lub integrator | Operator, stacja zdalna lub nadużycie wspólnej roli |
Jakie aktywa chronimy?
| Aktyw | Dlaczego ma znaczenie | Przykład dowodu |
|---|---|---|
| Uprawnienia ruchu | Zmieniają trajektorię, prędkość lub tryb | Macierz ról, dowód sesji, blokada trybu |
| Firmware bezpieczeństwa | Wpływa na zatrzymanie, prędkość, separację i blokady | Podpis, wspólny przegląd bezpieczeństwa funkcjonalnego i cyber |
| Programy robota | Mogą wprowadzić niebezpieczne ruchy lub przerwy | Walidacja parsera, kontrola źródła, dziennik ładowania |
| Poświadczenia panelu | Pozwalają na lokalne zmiany w produkcji | Rotacja początkowa, ważność, audyt operatora |
| Łącznik chmury | Może rozdzielać ostrzeżenia, aktualizacje lub tunele | Certyfikaty, lista punktów połączenia, dowód wycofania |
| Komponenty software | RT OS, wizja, magistrala polowa i biblioteki mają podatności | SBOM, śledzenie ostrzeżeń, decyzja o łatce |
Gdzie leżą główne granice zaufania?
| Granica | Przejście | Pytanie ryzyka |
|---|---|---|
| Producent do integratora | Instrukcja, pakiet importera, konfiguracja bezpieczeństwa i ostrzeżenia | Co się dostarcza, a co pozostaje na zewnątrz? |
| Integrator do operatora | Zainstalowana cela, role, okna serwisowe | Kto może zmieniać ruch po dostawie? |
| Stacja inżynierska do kontrolera | Projekt, program, firmware, parametry | Jaki test blokuje zapis poza sesją? |
| Chmura do floty | Ostrzeżenia, aktualizacje, certyfikaty, tunele | Jakie uprawnienia zdalne istnieją i jak się je cofa? |
| Dostawca do producenta | Komponenty, biblioteki, firmware zewnętrzny | Jak wykrywać ostrzeżenie dotyczące robota? |
Które zagrożenia ocenić w pierwszej kolejności?
| ID | Zagrożenie | Aktyw | Granica |
|---|---|---|---|
| R1 | Konto fabryczne lub integratora pozostaje aktywne po dostawie | Uprawnienia ruchu | Integrator do operatora |
| R2 | Stary pakiet firmware zostaje zaakceptowany podczas odtwarzania | Integralność firmware | Serwis lokalny |
| R3 | Chmura floty otwiera tunel poza oknem serwisowym | Uprawnienia zdalne | Chmura do floty |
| R4 | Zmanipulowany projekt zmienia logikę prędkości lub separacji | Bezpieczeństwo współpracujące | Stacja inżynierska |
| R5 | Wygasły certyfikat blokuje ostrzeżenia lub aktualizacje | Dostępność | Chmura |
| R6 | Operator nie odbiera w porę ostrzeżenia o podatności | Zarządzanie podatnościami | Producent do operatora |
| R7 | Dostawca publikuje ostrzeżenie dla RT OS lub wizji i nie zostaje wykryte | Komponenty | Dostawca do producenta |
| R8 | Ramka magistrali polowej powoduje awarię CPU ruchu lub przeciążenie cyklu | Dostępność ruchu | Magistrala polowa |
| R9 | Obraz USB odtwarzania zostaje zastosowany bez audytu | Integralność firmware | Nośnik serwisowy |
| R10 | Pakiet diagnostyczny ujawnia nazwy programów, certyfikaty lub sieć | Dane serwisowe | Portal wsparcia |
| R11 | Podatność w RT OS, magistrali polowej lub wizji nie zostaje wykryta w okresie wsparcia | Komponenty firmware | Ostrzeżenia dostawców |
| R12 | Przekazanie klienta zostawia aktywną wcześniejszą stację inżynierską | Poświadczenia | Wycofanie z eksploatacji |
| R13 | Parser środowiska uruchomieniowego zawodzi lub wykonuje niebezpieczne treści ze zniekształconego projektu | Integralność narzędzi | Import projektu |
| R14 | Integrator łączy ramię z PLC bezpieczeństwa innego dostawcy bez aktualnego dowodu | Zgodność dostawcy | Przekazanie celi |
Jak ustalić priorytety początkowych ryzyk?
Użyj drabiny decyzyjnej. Nie wszystkie ryzyka wymagają tej samej odpowiedzi.
| Wynik rezydualny | Dlaczego pozostaje | Dowód operacyjny |
|---|---|---|
| Długa łatka | Komponent dostawcy nie ma jeszcze poprawki | Ostrzeżenie komponentu, łagodzenie tymczasowe, data przeglądu |
| Zmiana klienta | Operator chce zintegrować własną stację | Memorandum graniczne, notatka zakresu, instrukcja wsparcia |
| Okno łatki | Zakład wymaga okna i walidacji | Ostrzeżenie z wpływem na maszynę, łagodzenie, wycofanie |
| Fizyczny dostęp serwisowy | Szafy, panele i stacje są dostępne podczas serwisu | Ograniczenia trybu serwisowego, próbka audytu, blokada debug |
Które kontrole projektowe zmieniają ryzyko?
| Kontrola | Co redukuje | Dowód |
|---|---|---|
| Podpisany firmware z odrzucaniem starszych wersji | Stare lub zmanipulowane pakiety | Dziennik próby aktualizacji, hash, wynik odrzucenia |
| Poświadczenia per urządzenie i rotacja początkowa | Konta dzielone fabrycznie | Dziennik wdrażania, dowód pierwszego rozruchu |
| Oddzielne role operatora, utrzymania i inżynierii | Zmiany ruchu poza rolą | Macierz uprawnień i audyt |
| Okna serwisowe dla chmury i tuneli | Otwarte uprawnienia zdalne | Dziennik okna, automatyczne zamknięcie, wycofanie |
| SBOM i śledzenie dostawców | Ostrzeżenia nie docierają do zespołu | SBOM, źródła ostrzeżeń, decyzja klasyfikacji |
Jakie ryzyko rezydualne pozostaje po kontrolach?
Po zastosowaniu kontroli producent musi nazwać, co pozostaje żywe i dlaczego. W tym przykładzie ryzyko podatności dostawcy pozostaje, ponieważ robot zależy od RT OS, wizji i magistrali polowej stron trzecich. Ryzyka nie akceptuje się w abstrakcji: wiąże się je ze śledzeniem ostrzeżeń, podpisywaniem pakietów, oknami serwisowymi, komunikacją z integratorami i testami naprawczymi. Udokumentowane łagodzenie musi pokazać, że proces istnieje, zanim ruszy produkcja.
Jak mają krążyć ostrzeżenia z chmury floty?
Wcześniejsza ocena mieszka w szafie robota. Trasowanie ostrzeżeń mieszka w setkach robotów. Gdy chmura floty producenta obsługuje wielu integratorów i zakładów, pytanie nie brzmi tylko, czy chmura jest bezpieczna. Pytanie brzmi, kto odbiera ostrzeżenie o podatności w ciągu 24 h i kto zatwierdza okno aktualizacji dla każdej lokalizacji.
| Topologia floty | Kto stoi między producentem a użytkownikiem końcowym | Co się zmienia w dokumentacji |
|---|---|---|
| Operator jednej lokalizacji, bezpośrednio od producenta | Producent → operator | Ostrzeżenie trafia do zespołu utrzymania operatora; jeden kanał wystarczy |
| Operator wielolokalizacyjny z centralną inżynierią | Producent → centralna inżynieria → zakłady | Dokumentacja musi rejestrować kontakt centralny, aby ostrzeżenie nie zginęło w lokalnej skrzynce |
| Flota zarządzana przez OEM | Producent → operacje OEM → operatorzy końcowi | OEM przekazuje ostrzeżenia z wpływem na maszynę, ale producent potrzebuje drogi do dotkniętych użytkowników |
| Flota zarządzana przez integratora | Producent → integrator → MŚP-użytkownicy | Ostrzeżenie producenta zasila własny proces integratora, gdy ten sprzedaje pod własną marką |
| Flota flot | Chmura producenta ↔ chmura OEM ↔ chmura integratora ↔ operator | Udokumentuj, który łańcuch jest kontraktowy i który pokrywa powiadomienia regulacyjne oraz użytkowników |
Rejestr wydania. Mapa trasowania chmury floty musi nazwać, dla każdego integratora i operatora z listy: kontakt do alertów 24-godzinnych, właściciela okna serwisowego, uprawnienia do wycofania i otwarte ostrzeżenia rezydualne.
Jakie bramy walidacji zamknąć przed wydaniem?
Unikaj generycznej bramy „bezpieczeństwo sprawdzone". Zastosuj inwentarz bram z trybem awarii, kontrolą i dowodem dla każdej decyzji blokującej wysyłkę.
| Brama | Awaria, która blokuje | Dowód |
|---|---|---|
| Zamknięcie wariantu | Nie wiadomo, co się sprzedaje | Memorandum graniczne i ścieżka |
| Uprawnienia ruchu | Niewłaściwa rola może zmienić trajektorię lub tryb | Test negatywny i audyt |
| Firmware bezpieczeństwa | Aktualizacja zmienia logikę bezpieczeństwa bez przeglądu | Wspólny przegląd i podpisany test |
| Magistrala polowa | Ramki anomalii wpływają na cykl lub dostępność | Test magistrali i segmentacja |
| Chmura i OTA | Chmura zachowuje uprawnienia bezterminowo | Okno, certyfikaty, wycofanie |
| Dokumentacja | Brak kontaktu, wsparcia lub instrukcji | Indeks dokumentacji i pakiet importera |
Kto bierze rozwój robota od koncepcji po wsparcie?
Zastosuj tor odpowiedzialności. Każda faza ma głównego właściciela, prowadzony rejestr i bramę przeglądu. Wydanie nie zamyka się, dopóki każda faza nie zostawia śladu.
Jakie rejestry dowodowe wchodzą do dokumentacji?
Lista poniżej to widok do recenzji. Mrozi tożsamość produktu, kontrole bezpieczeństwa i obowiązki posprzedażowe. Każdy wiersz musi wskazywać prowadzony rejestr, nie folder rozproszonych zrzutów ekranu.
| Rejestr dowodowy | Co opisuje dla robota przemysłowego lub cobota |
|---|---|
| Tożsamość produktu | Model ramienia, udźwig, zasięg, szafa sterownicza, panel programowania, gałąź firmware, środowisko uruchomieniowe, sensor wizji, opcje magistrali, serwis sprzętu |
| Przewidziane zastosowanie | Praca współpracująca lub ogrodzona, udźwig, aplikacja, tryb operatora, wzorzec użycia i wariant |
| Dokumentacja cyberodporności | Ścieżka klasyfikacji, granice, lista zagrożeń, kontrole zaufania i decyzje rezydualne |
| Inwentarz komponentów | CPU ruchu, system operacyjny czasu rzeczywistego, stos magistrali polowej, stos slave EtherCAT, firmware bezpieczeństwa, środowisko uruchomieniowe, biblioteki, moduł wizji |
| Bezpieczna konfiguracja domyślna | Brak wspólnych sekretów, unikalne konta, blokada starszych wersji, OPC UA bezpiecznie domyślnie, serwis po uruchomieniu |
| Mechanizm aktualizacji | Podpisany firmware, wycofanie, mapa wpływu na maszynę, kontakt do klienta i dowód chmury |
| Zarządzanie podatnościami | Polityka ujawniania, pojedynczy kontakt, przepływ klasyfikacji, śledzenie ostrzeżeń komponentów i integratorów |
| Instrukcje użytkownika | Bezpieczne uruchomienie, zarządzanie rolami, wycofanie, okna aktualizacji, granice serwisu |
| Identyfikowalność i kontakt | Typ, partia lub seria, dane producenta, data końca wsparcia i kontakt do zgłoszeń podatności |
Co wchodzi w SBOM robota?
CRA wymaga SBOM-u czytelnego maszynowo, który identyfikuje komponenty i obejmuje co najmniej zależności pierwszego poziomu, ale nie ustala jeszcze jednego formatu. Dopóki Komisja nie doprecyzuje szczegółów, producenci wybierają zwykle CycloneDX lub SPDX. Przekrojowa wskazówka jest w przewodniku SBOM; ta sekcja obejmuje drzewo właściwe dla robota.
Wydanie robota dostarcza zwykle kilka elementów cyfrowych o oddzielnych cyklach aktualizacji, nie jeden binarny plik. Dwa wzorce spełniają minimum: SBOM produktu z sekcjami na element lub SBOM na dostarczany element cyfrowy aktualizowany przy każdym wydaniu. Każdy z nich się sprawdza, jeśli SBOM jest czytelny maszynowo i obejmuje zależności pierwszego poziomu.
Rejestr SBOM: SBOM czytelny maszynowo w CycloneDX lub SPDX, obejmujący co najmniej zależności pierwszego poziomu. Dla robotów to zwykle SBOM produktu z sekcjami na element lub SBOM na dostarczany element cyfrowy. Głębsze zależności tranzytywne są zalecane, gdy system buildu potrafi je wytworzyć.
Co sprawdza podpis wydania?
Zanim robot trafi na rynek UE, podpis musi zamknąć te same cztery rejestry pytań Q1-Q4. Inwentarz nie mieszka w abstrakcyjnym dowodzie powyżej. Ta tabela obejmuje tylko cztery decyzje blokujące wydanie.
Podpisanie wydania: cztery rejestry blokujące wyjście
- Q1 Memorandum klasyfikacji. Dlaczego produkt jest tak klasyfikowany: przewidziane zastosowanie, kontekst sprzedaży, dostarczone elementy cyfrowe i wybrana ścieżka standardowa.
- Q2 Inwentarz wysyłanych elementów. Co dokładnie się wysyła: ramię, kontroler, panel programowania, wizja, firmware, chmura, biblioteki, instrukcje i warianty.
- Q3 Pakiet dowodów bezpiecznej konfiguracji domyślnej. Poświadczenia per urządzenie, profil OPC UA, odrzucanie starszych wersji, blokada debug i tryb serwisowy.
- Q4 Proces zarządzania podatnościami. Publiczny kontakt, polityka ujawniania, klasyfikacja, śledzenie komponentów, integratorów i gotowość do zgłoszeń.
Wcześniejsze sprawdzenia: cztery rejestry muszą się znaleźć w mniej niż minutę; teczki muszą być przypięte do gałęzi firmware i bazowej linii dostawców; musi być wyznaczony właściciel alertów 24 h i 72 h.
Brama podpisu: brak jednego rejestru oznacza brak podpisu wydania.
Rejestr deklaracji: skorzystaj z głównego przewodnika deklaracji zgodności UE dla szablonu i wymaganych pól. Dla wydania robota tożsamość produktu musi ustalić ramię, szafę sterowniczą, panel programowania, gałąź firmware, dostarczone opcje i odniesienie do okresu wsparcia. Jeśli ta sama deklaracja obejmuje także prawodawstwo maszynowe, nazwij tę ścieżkę i utrzymaj dopasowanie dokumentacji technicznej robota i dokumentacji bezpieczeństwa maszyny.
Jak przekazać robota importerowi, dystrybutorowi, integratorowi i operatorowi?
Dokumentacja musi czynić weryfikowalne przekazanie od producenta do importera, dystrybutora, integratora jako producenta maszyny oraz użytkownika końcowego. Dla robotów i cobotów słabym punktem nie jest zwykle samo oznakowanie CE. Częściej jest to pytanie, czy wysyłka, instrukcja, chmura floty, usługa OTA i przekazanie integratorowi nadal odpowiadają ocenionemu wydaniu.
Przekazanie operatorów gospodarczych: role, sprawdzenia i sąsiednie reżimy
- 01 Producent. Utrzymuje pakiet wydania: deklarację, CE, indeks dokumentacji, okno wsparcia i kontakt do zgłoszeń podatności.
- 02 Importer. Weryfikuje pakiet, CE, indeks, datę wsparcia i kontakt. Wstrzymuje wysyłkę przy wątpliwościach co do identyfikowalności, poświadczeń, konta chmury lub kanału aktualizacji.
- 03 Dystrybutor. Sprawdza widoczne CE, dostarczone dokumenty, identyfikowalność dla operatora, wsparcie i deklaracje aktualizacji. Wstrzymuje sprzedaż, jeśli ogłoszenie ukrywa operatorów, przesadnie obiecuje wsparcie lub zaprzecza deklaracji.
- 04 Integrator. Łączy ramię z bezpieczeństwem, wizją i logiką celi. Jeśli cela wychodzi pod jego nazwą, integrator staje się producentem celi.
- 05 Operator. Odbiera ostrzeżenia, aplikuje aktualizacje w oknach serwisowych i zgłasza problemy. Nie jest producentem.
Sprawdzenie A: przedstawiciel i powiadomienie spoza UE. Mandat przedstawiciela autoryzowanego jest opcjonalny. Producenci bez głównego miejsca prowadzenia działalności w Unii stosują kaskadę punktu powiadomienia do wyboru CSIRT koordynującego.
Sprawdzenie B: nowi producenci. Importer lub dystrybutor sprzedający pod własną nazwą, lub modyfikujący robota istotnie, staje się producentem tej oferty. Inne strony przechodzą tę linię tylko, gdy zmiana jest istotna.
Sąsiednie reżimy: Rozporządzenie Maszynowe od 20 stycznia 2027 r., ISO 10218-1:2025, NIS2 dla operatorów infrastruktur krytycznych i Rozporządzenie o AI dla zastosowań z AI.
Wiersze poniżej to wersja krótka: co weryfikować, kiedy wstrzymać i kiedy robot wymaga nowej analizy roli. Pełny przekrój ról jest w kto musi spełniać CRA.
Przyjęcie przez importera
Zweryfikuj deklarację, kontrolę CE, indeks dokumentacji, okres wsparcia, kontakt do zgłoszeń podatności, tożsamość importera i instrukcję w języku docelowym. Wstrzymaj przy wątpliwościach co do pakietu, identyfikowalności, modelu poświadczeń panelu, konta chmury lub kanału aktualizacji.
Należyta staranność dystrybutora
Sprawdź widoczne CE, dostarczone dokumenty, identyfikowalność dla operatora, wsparcie i deklaracje aktualizacji. Wstrzymaj, jeśli oferta ukrywa operatorów, przesadnie obiecuje wsparcie, zaprzecza deklaracji lub jest dalej sprzedawana mimo znanej podatności.
Integrator jako producent maszyny
Integrator łączący ramię z bezpieczeństwem, wizją i logiką celi staje się producentem maszyny, gdy cela wychodzi pod jego nazwą. Producent robota pozostaje producentem komponentu dla ramienia, kontrolera i dostarczonego oprogramowania.
Importer lub dystrybutor pod własną marką
Importer lub dystrybutor wprowadzający robota na rynek Unii pod własną nazwą lub marką staje się producentem tej oferty. To samo dotyczy istotnej modyfikacji robota już wprowadzonego do obrotu: firmware z własną marką, nowa tożsamość panelu, nowa chmura floty, nowy kanał aktualizacji, nowa konfiguracja bezpieczeństwa lub nowa przewidziana finalność.
Inny odsprzedawca po istotnej modyfikacji
Strona trzecia, która nie jest producentem, importerem ani dystrybutorem, staje się producentem dopiero przy istotnej modyfikacji robota przed udostępnieniem. Rola dotyczy zmienionej części lub całego produktu, jeśli zmiana wpływa na cyberbezpieczeństwo całości.
Przedstawiciel autoryzowany i powiadomienie spoza UE
Producent może wyznaczyć przedstawiciela autoryzowanego pisemnym mandatem; to opcja, nie obowiązek wynikający z bycia poza UE. Wybór punktu powiadomienia wynika z innego faktu: braku głównego miejsca prowadzenia działalności w Unii. Kaskada CRA zaczyna się od przedstawiciela, dalej importer, potem dystrybutor i wreszcie największa baza użytkowników.
Sąsiednie reżimy
Prowadź oddzielne oceny dla Rozporządzenia Maszynowego, ISO 10218-1:2025, NIS2 i Rozporządzenia o AI. Mogą dzielić dowody, ale nie zastępują dokumentacji CRA.
Najczęstsze pytania
Czy roboty przemysłowe i coboty są produktami ważnymi lub krytycznymi według CRA?
Nie z racji kategorii robota. Roboty przemysłowe i coboty nie figurują dziś na listach CRA produktów ważnych ani krytycznych. Roboczą hipotezą jest ścieżka domyślna. Ścieżka zmienia się tylko, gdy w ofercie dominuje funkcja z listy, na przykład robot sprzedawany przede wszystkim jako zapora, system zarządzania siecią lub kontroler odporny na ingerencje. Nie istnieje kategoria „robot", która automatycznie wymuszałaby ścieżkę krytyczną.
Czy 6-osiowe ramię robota wymaga jednostki notyfikowanej?
Nie z racji bycia ramieniem robota. W ścieżce domyślnej producent może użyć kontroli wewnętrznej, badania UE typu z oceną zgodności z typem, pełnego zapewnienia jakości lub mającego zastosowanie europejskiego programu certyfikacji. Jednostka notyfikowana wchodzi tylko tam, gdzie wymaga tego ścieżka. Warunek pełnego stosowania norm należy do ścieżki rezerwowej dla produktów ważnych klasy I, nie do domyślnej.
Czy Rozporządzenie Maszynowe obejmuje już warstwę cyber?
Obejmuje fragment, nie całość. Rozporządzenie Maszynowe zawiera wymagania bezpieczeństwa związane z zakłóceniem systemów sterowania i niezawodnością sterowania. CRA dokłada warstwę cyberodporności: postawę bezpieczeństwa, proces obsługi podatności, wsparcie, SBOM i dokumentację techniczną. Traktuj je jak dwie powiązane teczki.
Kto jest producentem, gdy integrator buduje celę?
Jeśli integrator sprzedaje gotową celę pod swoją nazwą, integrator jest producentem tej celi. Producent robota utrzymuje swoją dokumentację dla ramienia, kontrolera i dostarczanego oprogramowania. Jeśli integrator jedynie instaluje celę pod marką producenta, udokumentuj przekazanie i granice, ale nie wymyślaj zmiany roli, której nie ma.
Czy cobot dla warsztatów MŚP wpada do tej samej kategorii co robot ogrodzony?
Tak, o ile żadna funkcja z listy nie dominuje w ofercie. Różnica leży w ocenie ryzyka, nie w wyjściowej kategorii CRA. Cobot ma zwykle więcej ekspozycji na człowieka, więcej współdzielonych ról i większą zależność od producenta w zakresie ostrzeżeń, wsparcia i aktualizacji.
Co, jeśli robot zawiera wizję, AI lub teleoperację zdalną?
Nie zmienia to automatycznie kategorii CRA. Zmienia granicę i listę zagrożeń. Wizja dokłada kamery, SDK i modele; teleoperacja dokłada uprawnienia zdalne; AI może uruchomić analizę według Rozporządzenia o AI, jeśli przekroczy jego progi. Każdy element musi pojawić się w memorandum granicznym i SBOM-ie.
Czy chmura floty zmienia granicę produktu?
Tak, gdy chmura jest dostarczana przez producenta i konieczna dla ostrzeżeń, aktualizacji, certyfikatów, telemetrii lub tuneli. W tym przypadku łącznik chmury i jego uprawnienia są częścią dokumentacji producenta. Jeśli chmura należy do klienta lub integratora, udokumentuj przekazanie i granice.
Co musi obejmować ocena ryzyka CRA dla robota?
Musi pokrywać ruch, firmware bezpieczeństwa, panel programowania, stację inżynierską, magistralę polową, chmurę, serwis lokalny, komponenty dostawców, wycofanie z eksploatacji i komunikację o podatnościach. Pytanie nie brzmi tylko, czy jest szyfrowanie. Pytanie brzmi, kto może zmienić ruch, konfigurację bezpieczeństwa lub dostępność.
Ile szczegółów wymaga model zagrożeń?
Tyle, by uzasadnić decyzje wydania. Generyczne zdanie o „dostępie nieautoryzowanym" nie wystarcza. Użyteczny wpis nazywa aktyw, granicę, tryb awarii, kontrolę, test i decyzję rezydualną: na przykład „stary pakiet firmware zostaje zaakceptowany podczas odtwarzania; łagodzenie przez podpis i odrzucanie starszych wersji; test w trybie odtwarzania".
Które ryzyka oceniamy w pierwszej kolejności?
Zacznij od tych, które zmieniają ruch lub bezpieczeństwo: poświadczenia fabryczne, aktualizacje firmware, uprawnienia chmury, ładowanie programów, role panelu i magistralę polową. Następnie pokryj dostępność, dane serwisowe, ostrzeżenia dostawców i wycofanie z eksploatacji.
Jak wygląda dobry przykład wpisu ryzyka?
„Zniekształcony projekt robota powoduje awarię parsera lub ładuje niezwalidowaną trajektorię ze stacji inżynierskiej. Aktyw: uprawnienia ruchu. Granica: stacja inżynierska do kontrolera. Kontrola: walidacja formatu, podpis projektu, rola inżynierska i test negatywny. Dowód: raport parsera, dziennik odrzucenia i audyt sesji."
Kiedy aktualizować ocenę ryzyka?
Aktualizuj ją, gdy zmienia się stan wydany: nowy model kont panelu, nowa magistrala polowa, zmiana chmury, firmware bezpieczeństwa, środowisko uruchomieniowe, moduł wizji, debug lub wycofanie z eksploatacji. Wcześniejsza data ma znaczenie: obowiązki zgłaszania zaczynają obowiązywać 11 września 2026 r., przed pełnym stosowaniem CRA 11 grudnia 2027 r. Ocena, polityka ujawniania i pojedynczy kontakt muszą działać przed tą datą.
Jaki jest pierwszy dowód, który musi przygotować producent robotów?
Memorandum graniczne. Nazwij dokładnie produkt, co się dostarcza, co pozostaje na zewnątrz, co integruje klient, co utrzymuje producent i jaką ścieżkę zgodności się stosuje. Bez tego rejestru SBOM, ocena ryzyka i przekazanie integratorowi tracą zakotwiczenie.
Co, jeśli wykryta zostanie podatność po wydaniu?
Producent musi działać niezwłocznie, gdy produkt lub procesy nie spełniają wymogów: poprawka, wycofanie z rynku lub wycofanie produktu, gdy to konieczne. W praktyce dokumentacja wymaga przygotowania do sekwencji zgłoszeń: alert 24-godzinny dla aktywnie wykorzystywanej podatności, zgłoszenie 72-godzinne, raport końcowy, gdy dostępny jest środek naprawczy lub łagodzący, oraz powiadomienie użytkowników. W robotach poprawka to zwykle podpisana aktualizacja z notatką o wpływie na maszynę i propozycją okna serwisowego; wycofanie z rynku zostaje na przypadki, których nie da się bezpiecznie zaktualizować w polu.