Dlaczego temat otwartych modeli w kontroli jakości w ogóle się pojawił
Presja kosztowa i zmęczenie licencjami komercyjnych systemów wizyjnych
Działy produkcji od kilku lat działają pod coraz większą presją kosztową. Z jednej strony rosną koszty energii, pracy i materiałów, z drugiej – wymagania klientów dotyczące jakości i śledzenia partii są coraz ostrzejsze. W tej sytuacji każda faktura za kolejne licencje na komercyjne systemy wizyjne zaczyna być kwestionowana dużo mocniej niż kiedyś.
Typowy scenariusz: istniejący system wizyjny działa, ale trzeba dodać nową funkcję – np. bardziej zaawansowaną kontrolę powierzchni albo dodatkową stację inspekcji. Dostawca proponuje dokupienie modułu analizy defektów, dodatkowych licencji na oprogramowanie i być może nowego kontrolera. Całość kosztuje kilka lub kilkanaście razy więcej niż sama kamera przemysłowa, a i tak nie daje pełnej gwarancji, że poradzi sobie z nieregularnymi defektami.
W tym samym czasie inżynier procesu lub automatyk znajduje w sieci repozytorium z modelem YOLO wyszkolonym do detekcji pęknięć w materiałach. Szybko liczy: kamera + komputer przemysłowy + własna praca + brak opłat licencyjnych. Porównanie zaczyna wyglądać atrakcyjnie, szczególnie dla mniejszych firm lub linii pilotażowych, gdzie każdy dodatkowy koszt mocno boli wynik finansowy.
Otwarte modele wizyjne w produkcji pojawiają się więc nie tylko jako ciekawostka technologiczna, ale bardzo konkretny sposób na obniżenie kosztu wejścia w automatyczną kontrolę jakości oraz uniezależnienie się od polityki licencyjnej jednego dostawcy.
Rozwój otwartych modeli i narzędzi: YOLO, Segment Anything, CLIP
Jeszcze kilka lat temu modele open source do detekcji defektów były trudne w użyciu i wymagały zespołu badawczego. Dzisiaj projekty takie jak YOLOv5/v8, Segment Anything, CLIP czy gotowe biblioteki OCR mają dokumentację, samouczki, a często także przykładowe skrypty do wykrywania wad na liniach produkcyjnych. To zmienia zasady gry.
Modele z rodziny YOLO pozwalają relatywnie szybko zbudować system, który wykrywa brakujące elementy, wycieki, wtrącenia czy błędnie włożone części. Segment Anything potrafi automatycznie wyciąć obszar zainteresowania, co przydaje się np. przy analizie powierzchni z wieloma odbiciami. CLIP umożliwia łączenie obrazu z opisem tekstowym, co wykorzystuje się choćby w elastycznej klasyfikacji typów defektów.
Do tego dochodzą dojrzałe frameworki: PyTorch, TensorFlow, OpenCV, biblioteki jak Ultralytics YOLO oraz narzędzia MLOps. Dostępne są także projekty społecznościowe computer vision, w których inżynierowie z różnych branż dzielą się gotowymi konfiguracjami, skryptami i pomysłami na wdrożenie AI do inspekcji wizyjnej.
Nowe kompetencje w zakładach: od „informatyka fabrycznego” do zespołu AI
Jeszcze niedawno typowy „informatyk fabryczny” zajmował się głównie serwerami, siecią i czasem oprogramowaniem MES. Dziś w wielu zakładach są osoby, które:
programują w Pythonie,
potrafią uruchomić kontener Dockera,
eksperymentują z frameworkami deep learning,
mają styczność z adnotacją danych i trenowaniem modeli.
Do tego dochodzą inżynierowie utrzymania ruchu, którzy potrafią czytać kody w GitHubie i łączyć otwarte biblioteki z istniejącą automatyką. Taki miks kompetencji powoduje, że pomysł „zróbmy to sami na open source” przestaje być mrzonką, a staje się realnym projektem pilotażowym.
Historia z praktyki: średniej wielkości zakład produkcyjny z branży tworzyw sztucznych. Oficjalny system wizyjny producenta maszyn nie radził sobie z mikro-ryskami na błyszczącej powierzchni. Automatyk i programista IT przygotowali eksperymentalny system z użyciem YOLOv8 i prostego interfejsu webowego. Po kilku iteracjach i zebraniu danych z produkcji docelowo model open source przejął główną funkcję detekcji wad, a system komercyjny został jako „backup” i narzędzie audytowe.
Gdzie open source w kontroli jakości ma największą szansę
Otwarte modele wizyjne nie zawsze od razu zastąpią komercyjne systemy wizyjne, ale świetnie nadają się jako:
rozwiązania na małe linie pilotażowe,
systemy dla krótkich serii i częstych zmian produktu,
narzędzia do szybkiego prototypowania nowych koncepcji kontroli,
dodatkowy moduł „drugiej opinii” przy krytycznych kontrolach.
Przy produkcji małoseryjnej i częstych zmianach asortymentu sztywne licencje funkcjonalne i kosztowne modyfikacje komercyjnych systemów szybko stają się barierą. Otwarte modele AI pozwalają eksperymentować, bez każdorazowego angażowania dostawcy i długich cykli wdrożeniowych.
Co sprawdzić na starcie: motywacja i priorytety
Przed wejściem w projekty open source w kontroli jakości opłaca się jasno odpowiedzieć na kilka pytań. To pomoże uniknąć rozczarowań i nieporozumień na linii produkcja–IT–zarząd.
Krok 1: Określ główny motyw:
obniżenie kosztów licencji,
większa elastyczność i szybkość zmian,
uniezależnienie się od jednego dostawcy,
rozwój kompetencji wewnętrznych w obszarze AI.
Krok 2: Zdefiniuj, co musi zostać na pewno:
konkretne normy jakościowe,
wymogi audytowe klienta lub jednostki certyfikującej,
integracja z istniejącymi systemami (PLC, MES, ERP).
Krok 3: Ustal, kto jest właścicielem projektu i kto podejmuje decyzje techniczne oraz biznesowe.
Co sprawdzić: czy zespół nie spodziewa się jednocześnie radykalnej oszczędności, pełnej elastyczności, braku nakładu pracy i certyfikacji na poziomie systemu „z pudełka”. Taki komplet wymaga już bardzo dojrzałego podejścia do MLOps i kilku przemyślanych pilotaży.
Jak działają tradycyjne komercyjne systemy wizyjne w kontroli jakości
Typowa architektura: od kamery po licencje funkcjonalne
Komercyjne systemy wizyjne w kontroli jakości zwykle opierają się na dość przewidywalnych elementach sprzętowych i programowych. Standardowy zestaw obejmuje:
kamerę lub kamery przemysłowe (obsługujące np. GigE, Camera Link),
dedykowane oświetlenie (pierścieniowe, liniowe, kopułowe, czasem z kontrolą natężenia),
kontroler wizyjny lub przemysłowy PC (często z zainstalowanym systemem dostawcy),
oprogramowanie producenta systemu wizyjnego,
licencje funkcjonalne na konkretne moduły (np. pomiary 2D, OCR, narzędzia powierzchniowe).
Konfiguracja odbywa się zazwyczaj w graficznym środowisku dostawcy: inżynier wybiera z listy narzędzia, łączy je w sekwencję, ustawia parametry progów i tolerancji, definiuje wyniki „OK/NOK” i sygnały do sterownika. Dzięki temu wdrożenie dla prostych zadań (mierzenie średnicy, sprawdzanie obecności otworu, odczyt kodów) może być wykonane w kilka dni.
Model biznesowy opiera się jednak na licencjach. Dodatkowy typ analizy lub kolejna kamera często wymagają kupienia nowej licencji lub podniesienia poziomu istniejącej. Z punktu widzenia stabilności jest to plus – użytkownik wie, co ma i za co płaci – ale z perspektywy szybkich eksperymentów bywa to barierą.
Podejście regułowe: kiedy prostota jest zaletą, a kiedy przeszkodą
Większość komercyjnych systemów wizyjnych historycznie bazuje na narzędziach regułowych: filtrach, progach, prostych analizach geometrycznych. Typowy zestaw „pudełkowych” funkcji obejmuje m.in.:
detekcję krawędzi i pomiar odległości,
sprawdzanie obecności/braku elementów na podstawie kontrastu,
odczyt kodów 1D/2D i prosty OCR,
porównanie obrazu z „złotym wzorcem”,
analizę histogramów jasności i prostych cech tekstury.
Takie podejście ma kilka dużych zalet:
jest stosunkowo łatwe do audytu – zasady są jawne, można je opisać w procedurze,
zapewnia dobrą powtarzalność dla stabilnych procesów,
wdrożenie można przeprowadzić bez głębokiej znajomości AI.
Problem pojawia się, kiedy defekty są nieregularne, subtelne, a tło zmienne – np. mikrorysy na błyszczącej powierzchni, niestandardowe plamy na teksturze drewna albo „miękkie” odkształcenia elementów z tworzywa. Reguły stają się skomplikowane, mnożą się wyjątki, rośnie liczba fałszywych odrzuceń lub przepuszczeń. Wtedy tradycyjny system zaczyna ciążyć, a nie pomagać.
Mocne strony systemów komercyjnych w kontekście produkcji
Komercyjne systemy wizyjne nie bez powodu dominują w wielu zakładach. Mają kilka przewag, które trudno zrealizować „od zera” na open source:
Stabilność i wsparcie: dostawca odpowiada za aktualizacje, poprawki, kompatybilność sprzętu.
Gotowe certyfikacje: niektóre systemy mają udokumentowane wdrożenia w środowiskach regulowanych (np. farmacja, automotive).
Łatwiejszy audyt: narzędzia regułowe są z natury bardziej przejrzyste – można sprawdzić, dlaczego dana sztuka została odrzucona.
Rozbudowane narzędzia diagnostyczne: logi, wizualizacja historii kontroli, integracja z systemami raportowania.
Dla wielu firm z branż mocno regulowanych (np. medyczna, spożywcza, automotive) to właśnie te cechy są kluczowe. Dopiero na drugim miejscu pojawia się elastyczność czy koszty licencji.
Ograniczenia i „punkty bólu” tradycyjnych systemów
Mimo zalet, komercyjne systemy wizyjne mają kilka typowych słabości, które prowadzą firmy do rozważań nad otwartymi modelami AI:
Sztywność konfiguracji: dodanie nowego typu defektu lub zmiana produktu wymaga często ingerencji integratora lub dostawcy.
Wysokie koszty rozbudowy: nowe stanowiska, dodatkowe kamery, zaawansowane moduły analityczne – wszystko osobno licencjonowane.
Ograniczona obsługa nieregularnych wad: skomplikowane, „miękkie” defekty są trudne do opisania prostymi regułami.
Uwiązanie do jednego ekosystemu: kamery, kontrolery i oprogramowanie często są powiązane i trudno je mieszać z rozwiązaniami innych dostawców.
Dodatkowo, kiedy linia produkcyjna przechodzi częste przezbrojenia, każda zmiana parametrów kontroli może wymagać ingerencji specjalisty z uprawnieniami do oprogramowania. To powoduje przestoje lub ryzyko błędnej konfiguracji pod presją czasu.
Co sprawdzić w obecnym systemie przed myśleniem o AI
Zanim padnie decyzja „zastępujemy wszystko otwartymi modelami AI”, lepiej precyzyjnie zdiagnozować, co konkretnie w obecnym systemie przeszkadza.
Fałszywe odrzuty: czy główny problem to zbyt duża liczba dobrych sztuk odrzucanych jako NOK?
Brak możliwości rozbudowy: czy ograniczeniem jest liczba kamer, typy analiz, brak OCR lub brak narzędzi do nieregularnych powierzchni?
Koszty: czy największym kosztem są licencje, serwis, czy może konieczność wzywania integratora przy każdej zmianie?
Integracja: czy obecny system trudno połączyć z MES/ERP lub zdalnym monitoringiem jakości?
Co sprawdzić: które z tych problemów da się rozwiązać w ramach obecnego systemu (np. aktualizacją, zmianą konfiguracji), a które rzeczywiście wymagają innego podejścia – być może właśnie wdrożenia AI do inspekcji wizyjnej na bazie otwartych modeli.
Źródło: Pexels | Autor: Jonathan Borba
Czym są otwarte modele AI wizyjnej i z czego się składają
Sieci neuronowe do detekcji, segmentacji i klasyfikacji
Otwarte modele AI wizyjnej to przede wszystkim sieci neuronowe wyszkolone do rozpoznawania wzorców na obrazach. W kontroli jakości najczęściej używa się trzech typów zadań:
Klasyfikacja: przypisanie całemu obrazowi lub fragmentowi etykiety typu „OK” / „NOK” lub „defekt A / defekt B”.
Detekcja obiektów: znalezienie i oznaczenie prostokątami miejsc, w których występują defekty (np. brak śruby, pęknięcie, wyciek).
Segmentacja: podział obrazu na piksele należące do defektu i tła (przydatne przy analizie powierzchni, powłok, spoin).
Modele anomalii i uczenia nienadzorowanego
W kontroli jakości coraz częściej wykorzystuje się też modele, które nie wymagają pełnego, ręcznego opisywania każdego typu defektu. Działają one inaczej niż klasyczne klasyfikatory:
Uczenie na „samych dobrych sztukach”: model uczy się, jak wygląda poprawny produkt w różnych wariantach i warunkach.
Wykrywanie odstępstw: wszystko, co za bardzo odbiega od wzorca, oznaczane jest jako potencjalna anomalia.
Mapa odchyleń: część modeli zwraca nie tylko informację „OK/NOK”, lecz także mapę ciepła pokazującą, gdzie wystąpił problem.
Takie podejście jest szczególnie przydatne, gdy:
liczba możliwych typów defektów jest duża i zmienna,
defekty pojawiają się rzadko i trudno zebrać ich reprezentatywny zestaw,
proces jest stosunkowo stabilny, ale wymaga „czujności” na wszystko, co inne niż zwykle.
Typowy błąd: oczekiwanie, że model anomalii „zrozumie” każdy nietypowy wzór jako defekt. Bez dobrej bazy poprawnych danych i kontroli warunków oświetlenia potrafi zgłaszać liczne fałszywe alarmy.
Co sprawdzić: czy na linii dostępne są setki lub tysiące zdjęć naprawdę dobrych sztuk z różnych zmian i partii, a także czy można utrzymać stabilne oświetlenie – modele anomalii są na to bardzo wrażliwe.
Ekosystem open source: frameworki, biblioteki i narzędzia MLOps
Otwarte modele nie działają w próżni. Za nimi stoi cały ekosystem narzędzi, z których trzeba złożyć działający system kontroli jakości. W praktyce oznacza to kilka warstw:
Frameworki deep learning: PyTorch, TensorFlow, JAX – odpowiadają za trenowanie i uruchamianie modeli.
Gotowe implementacje modeli: m.in. YOLO, Detectron2, MMDetection, Segment Anything – skracają czas startu.
MLOps: narzędzia typu MLflow, DVC, Kubeflow, Weights & Biases do śledzenia eksperymentów, wersjonowania danych i modeli.
Każdy z tych klocków jest osobnym projektem, z własnym cyklem życia i dokumentacją. To daje elastyczność, ale wymaga też kompetencji zespołu i konsekwentnego podejścia do zarządzania wersjami.
Co sprawdzić: czy w zespole jest przynajmniej jedna osoba, która rozumie różnicę między frameworkiem, biblioteką przetwarzania obrazu a platformą MLOps, i potrafi je spiąć w jedną całość bez „instalowania wszystkiego, co się da”.
Sprzęt pod otwarte modele: GPU, edge, akceleratory
Komercyjne systemy często przychodzą w formie gotowego kontrolera. Przy otwartych modelach tę odpowiedzialność bierze na siebie zespół projektowy. Trzeba świadomie dobrać sprzęt:
GPU w serwerowni: dobre, gdy obrazy mogą być przesyłane siecią, a opóźnienie rzędu setek milisekund nie jest krytyczne.
Edge AI (Jetson, TPU, akceleratory PCIe): sprawdza się, gdy kontrola musi być blisko linii, z niskim opóźnieniem i ograniczonym ruchem sieciowym.
CPU-only: możliwe tylko przy lekkich modelach, mniejszej rozdzielczości i niezbyt wyśrubowanych czasach cyklu.
Krok 1 to oszacowanie wymaganego throughputu: ile obrazów na sekundę trzeba przetworzyć z marginesem bezpieczeństwa. Krok 2 – określenie budżetu energetycznego i miejsca w szafach sterowniczych. Krok 3 – uwzględnienie serwisu: kto wymieni padniętą kartę GPU na produkcji o 2:00 w nocy.
Co sprawdzić: realny czas przejazdu produktu pod kamerą, maksymalną dopuszczalną latencję decyzji „OK/NOK” oraz to, czy zakład ma procedury serwisowe dla sprzętu z GPU (chłodzenie, kurz, restart, monitoring).
Główne różnice: otwarte modele vs systemy komercyjne – gdzie kto wygrywa
Elastyczność vs gotowość „z pudełka”
System komercyjny to gotowy produkt: instalacja, konfiguracja, szkolenie i system zwykle działa. Elastyczność jest ograniczona do funkcji przewidzianych przez dostawcę.
Otwarty model to zestaw klocków. Można zbudować rozwiązanie skrojone pod konkretną linię, łączyć różne typy modeli, implementować własne metryki jakości. Ceną jest jednak czas i odpowiedzialność za integrację.
W praktyce:
dla prostych, powtarzalnych zadań (odczyt kodu, pomiar geometrii) system komercyjny zazwyczaj wygrywa czasem wdrożenia,
dla nieregularnych defektów i częstych zmian asortymentu przewagę ma podejście oparte na otwartych modelach.
Co sprawdzić: czy główna potrzeba to „uruchomić szybko i stabilnie”, czy raczej „móc zmieniać i rozwijać bez proszenia dostawcy o ofertę na każdą modyfikację”.
Kontrola nad algorytmem i danymi
W systemach komercyjnych algorytmy są zamknięte. Użytkownik widzi parametry, ale nie ma dostępu do kodu. Dane zwykle da się wyeksportować, lecz formaty i integracje bywają ograniczone.
Przy otwartych modelach:
masz pełny dostęp do kodu i struktury modelu,
możesz sam decydować, gdzie i jak przechowywać obrazy oraz etykiety,
łatwiej spełnić nietypowe wymagania audytowe (np. niestandardowe raporty, historie decyzji, wersjonowanie modeli).
Dla branż z bardzo czułymi danymi (np. farmacja, obronność) kontrola nad tym, gdzie fizycznie znajdują się dane z linii i kto ma do nich dostęp, często przeważa szalę na korzyść otwartych rozwiązań.
Co sprawdzić: wymagania klientów i audytorów dotyczące przechowywania obrazów, czasu retencji i możliwości odtworzenia procesu decyzyjnego sprzed kilku lat.
Koszty licencji vs koszty kompetencji i utrzymania
Na pierwszy rzut oka otwarte modele wyglądają taniej: brak opłat licencyjnych za każde stanowisko. Jednak w praktyce bilans bywa bardziej złożony.
System komercyjny: płacisz za licencje, opcjonalnie za serwis i wsparcie, ale mniejszy jest koszt budowy kompetencji wewnętrznych.
Otwarte modele: nie płacisz za samo oprogramowanie, lecz inwestujesz w zespół (data scientist, inżynierowie MLOps, integratorzy) i w infrastrukturę.
Krok 1 to policzenie TCO (Total Cost of Ownership) na kilka lat: sprzęt, licencje, roboczogodziny, przestoje. Krok 2 – porównanie scenariusza „kupujemy gotowe i rozbudowujemy” z „budujemy kompetencje i rozwijamy sami”.
Co sprawdzić: czy firma ma już zespół AI/inżynierii danych, którego koszty i tak są ponoszone, czy dopiero trzeba go zbudować „pod projekt wizyjny”.
Skalowalność i powtarzalność wdrożeń
Dla jednego stanowiska różnice mogą wydawać się niewielkie. Schody zaczynają się, gdy trzeba powielić system na kilkadziesiąt kamer i kilka zakładów.
Systemy komercyjne często mają gotowe narzędzia do klonowania konfiguracji, zarządzania licencjami i centralnego nadzoru, ale każda dodatkowa instancja generuje koszt licencyjny.
Otwarte modele wymagają zbudowania własnej „fabryki wdrożeń” (skrypty, kontenery, CI/CD dla modeli), ale potem kopiowanie rozwiązań między liniami jest tańsze operacyjnie.
Typowy błąd to potraktowanie pierwszego pilotażu na open source jak jednorazowego projektu, bez myślenia o tym, jak zreplikować system w innych lokalizacjach i jak nim potem zarządzać.
Co sprawdzić: plany rozwoju zakładu na 2–3 lata: ile nowych linii lub produktów dojdzie, ile stanowisk wizyjnych może powstać, jaka jest strategia globalna firmy (centralizacja vs autonomia zakładów).
Audytowalność, wyjaśnialność i zgodność z normami
W środowiskach regulowanych liczy się nie tylko to, czy system działa, ale czy można udokumentować, jak działa. Systemy regułowe mają przewagę, bo decyzje można opisać prostymi, deterministycznymi regułami.
Modele AI typu deep learning są trudniejsze do wyjaśnienia, ale otwartość kodu pomaga:
można zaimplementować własne logowanie wejść/wyjść modelu,
da się przechowywać wersje modeli wraz z zestawami walidacyjnymi,
możliwe jest generowanie dodatkowych artefaktów (np. map ciepła, metryk zaufania), które ułatwiają audyt.
Dodatkowo pojawiają się wymagania norm ISO, IATF czy GAMP. Komercyjni dostawcy często mają gotowe dokumenty walidacyjne, natomiast dla otwartych modeli taki pakiet trzeba przygotować samodzielnie.
Co sprawdzić: czy dział jakości i compliance akceptuje użycie modeli uczenia maszynowego w procesie decyzji „OK/NOK” i jakie dodatkowe dowody poprawności będą wymagane (raporty walidacyjne, testy okresowe, procedury rekwalifikacji modelu).
Źródło: Pexels | Autor: Avinash Kumar
Kiedy otwarty model może realnie zastąpić komercyjny system
Scenariusz 1: trudne, nieregularne defekty powierzchni
Typowy przypadek to inspekcja spoin, powierzchni malowanych, elementów z tworzyw sztucznych, drewna czy polerowanego metalu. Defekty są „miękkie”: zacieki, nadtopienia, rysy o zmiennym kształcie.
Krok 1: zebrać reprezentatywny zestaw obrazów z realnej linii, najlepiej z różnych zmian i partii materiału. Krok 2: wspólnie z działem jakości zdefiniować, co jest jeszcze akceptowalne, a co już defektem – ustalić granicę. Krok 3: przygotować dataset z oznaczeniem defektów (segmentacja lub detekcja) i przetestować kilka architektur otwartych modeli.
W takim scenariuszu tradycyjne narzędzia progowe i „złote wzorce” szybko się wyczerpują, a dobrze wytrenowany model segmentacji anomalii potrafi stabilnie rozróżniać drobne różnice, których człowiek uczy się latami.
Co sprawdzić: czy obecny system ma problem głównie z nieregularnymi powierzchniami, a nie z integracją czy prostymi pomiarami. Jeśli tak – to dobry kandydat na pilotaż z otwartym modelem.
Scenariusz 2: częste zmiany asortymentu i krótkie serie
W zakładach, które produkują wiele wariantów produktów w krótkich seriach, każda zmiana magazynu części powoduje serię modyfikacji w systemach wizyjnych. Przy podejściu regułowym oznacza to ciągłe strojenie progów i regionów zainteresowania.
Otwarte modele dają inną ścieżkę:
można zbudować model, który rozpoznaje typ produktu i wybiera odpowiednią konfigurację kontroli,
można szkolić modele przyrostowe – dodając nowe warianty bez przeuczania wszystkiego od zera,
część decyzji można zautomatyzować, opierając się na uczeniu z danych zebranych w trakcie produkcji.
Przykład z praktyki: firma produkująca wiązki kablowe dla kilku OEM-ów automotive, gdzie co kilka dni zmienia się konfiguracja złącz. System na open source (detekcja elementów + klasyfikacja konfiguracji) okazał się tańszy w utrzymaniu niż każdorazowe wdrażanie nowych presetów w systemie komercyjnym.
Co sprawdzić: ile realnie zmian receptur jest w ciągu miesiąca i ile roboczogodzin zajmuje każda modyfikacja w obecnym systemie. To pokaże, czy inwestycja w elastyczny model ma sens.
Scenariusz 3: potrzeba głębszej integracji z systemami IT/OT
Jeśli dział IT chce mieć spójny ekosystem danych (MES, ERP, systemy traceability, monitorowanie OEE), zamknięty system wizyjny bywa trudny do wpięcia. API jest ograniczone, logika zostaje w „czarnej skrzynce”.
Przy otwartych modelach można:
udostępnić wyniki inspekcji jako mikroserwis z jasnym API,
zapisywać pełną historię decyzji w centralnym data lake,
łączyć dane z kamer z danymi procesowymi (temperatury, prędkości, operator, partia materiału) do dalszej analizy.
Taka integracja otwiera drogę do bardziej zaawansowanej analityki: korelacji typów defektów z parametrami procesu, predykcji awarii, dynamicznego dostosowania parametrów linii.
Co sprawdzić: czy architektura IT/OT firmy zakłada centralizację danych i czy obecne systemy wizyjne nie są już dziś „wyspami” bez wygodnego dostępu do danych historycznych.
Scenariusz 4: projekty R&D i linie pilotażowe
Na etapach rozwoju produktów i procesów często trzeba szybko testować nowe metody inspekcji, bez długich procedur zakupowych i kontraktów serwisowych. Linia pilotażowa jest dobrym miejscem na eksperymenty z otwartymi modelami.
Scenariusz 5: nietypowe sensory i konfiguracje kamer
Gdy w grę wchodzą kamery liniowe, hyperspektralne, obrazy z rentgena, termowizji czy połączenia kilku kamer w jedną scenę 3D, gotowe pakiety komercyjne często zaczynają się „krztusić”. Producent systemu wizyjnego oferuje wsparcie głównie dla standardowych matryc 2D i kilku sprawdzonych interfejsów.
Przy otwartych modelach można pójść inną drogą:
zintegrować niestandardowe sterowniki kamer bez czekania na nową wersję oprogramowania dostawcy,
łączyć różne modality (np. RGB + IR + głębia) w jednym modelu lub pipeline’ie,
tworzyć własne reprezentacje danych (np. projekcje 3D na obraz 2D) dopasowane do konkretnego procesu.
Krok 1: ustalić, jakie dokładnie dane daje kamera/sensor (format, częstotliwość, opóźnienia). Krok 2: zbudować prosty pipeline akwizycji w środowisku open source i sprawdzić stabilność. Krok 3: dopiero na tej bazie dobrać architekturę modelu – czasem wystarczy klasyfikacja 2D, czasem potrzebny jest model sekwencyjny lub 3D.
Typowy błąd to kupno zaawansowanej kamery z myślą „system wizyjny to jakoś obsłuży”, a potem odkrycie, że oprogramowanie nie wspiera danego trybu i trzeba mocno naginać założenia projektu.
Co sprawdzić: dokumentację techniczną kamer i czujników, listę oficjalnie wspieranych urządzeń przez rozważane systemy komercyjne oraz dostępność bibliotek do obsługi tych urządzeń w środowisku open source.
Scenariusz 6: potrzeba szybkiego prototypowania i iteracji
Są projekty, w których wymagania zmieniają się co kilka tygodni. Dział jakości testuje nowe kryteria, produkcja zmienia parametry procesu, klient końcowy doprecyzowuje specyfikację. W takim otoczeniu klasyczne wdrożenie komercyjnego systemu, z wielomiesięcznym cyklem zmian, staje się hamulcem.
Otwarte modele dobrze się sprawdzają, gdy trzeba:
szybko zweryfikować kilka koncepcji inspekcji na tym samym zbiorze danych,
przetestować różne progi czułości i polityki podejmowania decyzji „OK/NOK”,
łączyć podejście regułowe z modelem AI w jednym prototypie.
Krok 1: zbudować minimalne środowisko testowe – jedna kamera, prosty interfejs użytkownika, repozytorium obrazów. Krok 2: ustalić cykl iteracji (np. co tydzień nowa wersja modelu na osobnej gałęzi w repozytorium). Krok 3: wspólnie z produkcją i jakością testować kolejne warianty kryteriów i logiki decyzji.
Błąd, który często się pojawia, to zbyt duża formalizacja prototypu – rozbudowane GUI, skomplikowana logika PLC – zamiast szybkiego testu, czy model w ogóle „widzi” defekty lepiej niż człowiek.
Co sprawdzić: ile razy w roku zmieniają się wymagania jakościowe oraz ile czasu mija dziś od pomysłu na zmianę inspekcji do jej wdrożenia na linii.
Scenariusz 7: brak odpowiedniego rozwiązania na rynku
Zdarzają się aplikacje, gdzie po prostu nie istnieje gotowy, komercyjny pakiet „z półki”. Przykłady to inspekcja bardzo specyficznych struktur (np. tkanki kompozytowej), analiza mikrodefektów przy ekstremalnych powiększeniach czy łączenie obrazu z danymi z innych czujników procesu.
W takich przypadkach otwarty model jest często jedyną realistyczną drogą. Producent standardowych systemów wizyjnych może zaoferować rozwój dedykowanego modułu, ale:
czas realizacji jest długi,
koszty są wysokie i trudne do przewidzenia,
efekt końcowy bywa równie „prototypowy” jak rozwiązanie na open source, ale bez pełnej kontroli po stronie użytkownika.
Krok 1: jasno opisać problem w kategoriach danych wejściowych i wyjściowych (co jest obrazem, jaka ma być etykieta lub decyzja). Krok 2: zbudować mały, ale czysty zbiór danych do eksperymentów. Krok 3: zaangażować zespół data science lub partnera zewnętrznego i przeprowadzić krótki projekt proof-of-concept, zanim zapadnie decyzja o dużej inwestycji.
Co sprawdzić: czy istnieje choć jedno komercyjne wdrożenie podobnej aplikacji oraz jakie były jego ograniczenia (koszty, czasy cyklu, stabilność). Jeśli nie – lepiej założyć, że będzie to projekt badawczo-rozwojowy, a nie klasyczne „wdrożenie z katalogu”.
Scenariusz 8: rozwój własnego produktu z funkcją wizji
Coraz więcej firm produkcyjnych i integratorów tworzy własne rozwiązania – od stanowisk pomiarowych po całe maszyny – które później sprzedaje klientom. W takim modelu biznesowym licencje per stanowisko/instalację stają się problemem, bo obniżają marżę i komplikują ofertę.
Otwarte modele umożliwiają:
wbudowanie funkcji wizji w produkt bez płatności za każdą instancję,
dostosowanie algorytmu do specyfiki branży i zachowanie know-how w firmie,
budowę własnych „cegiełek” – bibliotek i modeli, które później można ponownie wykorzystywać w kolejnych projektach.
Krok 1: zdefiniować, które elementy rozwiązania mają być powtarzalne (platforma) a które projektowane indywidualnie. Krok 2: wybrać stos technologiczny i modelowy, który będzie można utrzymywać przez kilka lat. Krok 3: zorganizować proces aktualizacji modeli w już sprzedanych urządzeniach (mechanizm aktualizacji oprogramowania, testy regresji, dokumentacja zmian).
Co sprawdzić: strukturę kosztów projektów dla klientów końcowych i potencjalny wpływ opłat licencyjnych na konkurencyjność oferty, a także gotowość firmy do stania się „dostawcą oprogramowania”, a nie tylko maszyn.
Jak przygotować organizację do wdrożenia otwartych modeli wizyjnych
Krok 1: diagnoza dojrzałości danych i procesów
Zanim powstanie pierwszy model, trzeba odpowiedzieć na proste, ale kluczowe pytania: gdzie są dziś dane z kamer, jak są opisywane, kto za nie odpowiada i co dzieje się z nimi po decyzji „OK/NOK”. Bez tego nawet najlepsza architektura modelu nie zadziała stabilnie.
Pomaga przegląd w czterech obszarach:
zbieranie danych: czy obrazy z linii są archiwizowane, jak długo, z jakim opisem (produkt, partia, operator),
jakość danych: czy kamery są skalibrowane, oświetlenie stabilne, a parametry linii powtarzalne,
proces jakości: jak wyglądają kryteria akceptacji – czy są spisane, mierzalne, czy zależą głównie od „oka doświadczonego operatora”,
odpowiedzialność: kto w zakładzie podejmuje decyzje o zmianach kryteriów i konfiguracji systemu wizyjnego.
Typowy błąd to rozpoczęcie projektu AI bez uzgodnionych definicji defektów. Każdy inżynier „wie swoje”, dataset jest niespójny, a model wydaje się „dziwnie zachowywać”, choć w rzeczywistości odzwierciedla chaos w danych.
Co sprawdzić: czy firma jest w stanie w ciągu tygodnia przygotować reprezentatywny, dobrze opisany zestaw obrazów z ostatniego okresu produkcji dla wybranego przypadku użycia.
Krok 2: zespół i role – kto za co odpowiada
Wdrożenie otwartego modelu nie musi oznaczać zatrudniania dużej grupy data scientistów, ale ktoś musi przejąć odpowiedzialność za kluczowe obszary. Najprościej podzielić zadania na cztery role (mogą je pełnić te same osoby, o ile mają kompetencje):
właściciel procesu (jakość/produkcja): definiuje wymagania, kryteria akceptacji, akceptuje wyniki walidacji,
inżynier wizji/automatyki: odpowiada za kamery, oświetlenie, integrację z PLC i bezpieczeństwo maszynowe,
data scientist/inżynier ML: projektuje i trenuje modele, przygotowuje pipeline’y danych,
inżynier IT/MLOps: dba o infrastrukturę, wdrożenia na serwerach/brzegach, monitorowanie i backup.
Krok 1: nazwać te role w organizacji i przypisać do konkretnych osób. Krok 2: ustalić przepływ pracy – kto uruchamia zbieranie danych, kto oznacza defekty, kto uruchamia trening modelu, kto akceptuje jego wejście w produkcję. Krok 3: zdefiniować czynności utrzymaniowe – kto reaguje na spadek skuteczności, kto planuje re-trening, kto aktualizuje dokumentację.
Co sprawdzić: czy te role są dziś faktycznie obsadzone (nawet częściowo), czy wdrożenie otwartego modelu nie kończy się tym, że „wszyscy robią wszystko po trochu i nikt za nic nie odpowiada”.
Krok 3: standardy datasetów i etykietowania
Bez spójnego sposobu opisywania obrazów projekty szybko się rozjeżdżają. Inny zespół liczy defekty na sztukę, inny na powierzchnię, ktoś inny – na długość rysy. Przy powrocie do starego projektu po roku trudno cokolwiek odtworzyć.
Dobrym podejściem jest ustalenie kilku prostych zasad:
minimalny zestaw metadanych dołączanych do każdego obrazu (produkt, partia, data, linia, numer stanowiska),
format etykiet (np. bounding box, maska segmentacyjna, klasy etykiet),
konwencje nazewnicze (np. „surface_scratch_minor”, „surface_scratch_major” zamiast dowolnych opisów słownych).
Krok 1: wybrać narzędzie do etykietowania (open source lub komercyjne) i dopasować go do własnego schematu danych. Krok 2: przeszkolić małą grupę osób z działu jakości, jak oznaczać defekty w sposób powtarzalny. Krok 3: wykonać test spójności – dać ten sam zestaw obrazów kilku osobom i porównać, jak różnią się etykiety.
Co sprawdzić: czy organizacja ma jeden repozytorium datasetów (z backupem i wersjonowaniem), czy dane są porozrzucane po dyskach lokalnych i pendrive’ach.
Krok 4: wybór technologii – od hardware’u po frameworki
Przy otwartych modelach technologia nie jest „domyślna” jak w przypadku gotowego systemu. Trzeba ją dobrać świadomie, tak aby dało się ją utrzymać w perspektywie kilku lat.
Podstawowe decyzje:
sprzęt inferencyjny: CPU, GPU, akceleratory brzegowe (np. moduły z TPU/NPU),
system operacyjny: zazwyczaj Linux jako standard dla środowisk produkcyjnych opartych o open source,
framework ML: PyTorch, TensorFlow, ONNX Runtime lub lekkie biblioteki do inferencji na brzegu,
warstwa orkiestracji: kontenery (Docker), ewentualnie Kubernetes dla większych środowisk.
Krok 1: oszacować wymagania wydajnościowe (czas reakcji, liczba kamer, rozdzielczość, złożoność modelu). Krok 2: przygotować prosty benchmark – ten sam model uruchomiony na różnych konfiguracjach sprzętu i frameworków. Krok 3: wybrać stos, który zapewnia zapas wydajności i jest zgodny z polityką IT (aktualizacje, bezpieczeństwo, support).
Co sprawdzić: czy dział IT akceptuje proponowane technologie, czy w firmie jest już doświadczenie z danym systemem Linux, kontenerami i monitoringiem usług.
Krok 5: proces walidacji i rekwalifikacji modelu
Model AI nie jest statycznym „programem”. Z czasem starzeje się razem z procesem – zmienia się dostawca materiału, narzędzia się zużywają, a operatorzy inaczej ustawiają maszynę. Bez jasnego procesu walidacji łatwo wpaść w pułapkę cichego spadku jakości decyzji.
Praktyczny schemat może wyglądać tak:
walidacja wstępna: przed pierwszym wdrożeniem na linii – na osobnym zbiorze walidacyjnym, z udziałem działu jakości,
walidacja okresowa: np. raz na kwartał – test modelu na świeżym zbiorze obrazów reprezentujących bieżącą produkcję,
rekwalifikacja: procedura wejścia nowej wersji modelu na linię (test A/B, tryb „shadow mode”, zatwierdzenie przez właściciela procesu).
Krok 1: uzgodnić minimalne metryki skuteczności (np. maksymalny dopuszczalny poziom fałszywych odrzutów i przepuszczonych defektów). Krok 2: zdefiniować, jak duża zmiana metryk wymusza re-trening lub powrót do poprzedniej wersji. Krok 3: zautomatyzować jak największą część testów – skrypty porównujące wyniki kolejnych wersji modelu na tych samych danych.
Co sprawdzić: czy dział jakości akceptuje koncepcję zmiennych w czasie modeli oraz czy ma jasne kryteria, kiedy „coś jest nie tak” z decyzjami systemu wizyjnego.
Krok 6: bezpieczeństwo, ciągłość działania i plan awaryjny
System AI wpięty w decyzję „OK/NOK” staje się elementem krytycznym procesu. Jeśli przestanie działać, linia może stanąć lub – co gorsza – zacząć przepuszczać wadliwe produkty. Dlatego przy otwartych modelach trzeba szczególnie zadbać o mechanizmy awaryjne.
Najczęściej zadawane pytania (FAQ)
Czy otwarte modele AI (np. YOLO) mogą realnie zastąpić komercyjne systemy wizyjne w kontroli jakości?
Tak, ale zwykle nie od razu i nie we wszystkich zastosowaniach. Otwarte modele świetnie sprawdzają się jako główny system na małych liniach pilotażowych, przy produkcji małoseryjnej oraz tam, gdzie często zmienia się asortyment. W takich scenariuszach elastyczność i brak opłat licencyjnych dają duży efekt biznesowy.
Na liniach krytycznych dla bezpieczeństwa, podlegających ścisłym audytom lub certyfikacji, częściej stosuje się układ mieszany: model open source jako „silnik” detekcji defektów, a komercyjny system wizyjny jako backup, narzędzie audytowe lub warstwa raportowo‑integracyjna.
Co sprawdzić: czy proces jest na tyle stabilny i dobrze opisany, żeby wytrzymać eksperyment z nowym rozwiązaniem, oraz czy brak „papierowej” certyfikacji dostawcy nie zablokuje odbioru systemu przez klienta lub jednostkę certyfikującą.
Jakie są główne korzyści z użycia otwartych modeli wizyjnych zamiast komercyjnych systemów?
Najczęściej wymieniane plusy to niższy koszt wejścia (brak licencji funkcjonalnych), większa elastyczność zmian i brak uzależnienia od jednego dostawcy. Kamera + komputer przemysłowy + praca własnego zespołu często wychodzi taniej niż rozbudowa istniejącego systemu o nowe moduły analizy czy dodatkowe stanowiska.
Dodatkowo zespół wewnętrzny zdobywa kompetencje w obszarze AI: uczy się adnotacji danych, trenowania modeli i integracji z automatyką. Przy kolejnych projektach oznacza to krótszy czas reakcji – nowy typ defektu można obsłużyć iteracją modelu, a nie kolejną fakturą za licencję.
Co sprawdzić: czy oszczędność na licencjach nie zostanie „zjedzona” przez brak kompetencji w zespole, chaotyczny rozwój skryptów i problemy z utrzymaniem rozwiązania w ruchu 24/7.
W jakich zastosowaniach open source w kontroli jakości sprawdza się najlepiej?
Otwarte modele mają największy sens tam, gdzie tradycyjne, regułowe narzędzia wizyjne dochodzą do ściany albo ich modyfikacja jest zbyt droga. Chodzi m.in. o nieregularne defekty na powierzchniach (mikro‑ryski, wtrącenia, wycieki), różnorodne warianty produktu oraz krótkie serie, które ciągle się zmieniają.
Praktyczny podział:
krok 1: użyj open source do pilotażu i szybkiego prototypu nowej koncepcji kontroli,
krok 2: przenieś sprawdzone rozwiązanie na małą linię lub stanowisko testowe,
krok 3: dopiero po kilku miesiącach stabilnej pracy rozważ rozszerzenie na więcej linii.
Co sprawdzić: czy zadanie kontroli wymaga elastycznego „rozumienia” obrazu (AI), czy da się je prosto opisać progami, filtrami i pomiarami – wtedy klasyczny system komercyjny może być szybszy we wdrożeniu.
Jak zacząć wdrażać YOLO, Segment Anything czy CLIP w zakładzie produkcyjnym?
Najprościej zacząć od małego, niekrytycznego projektu pilotażowego. Schemat jest zwykle podobny:
krok 1: wybierz konkretne zadanie (np. detekcja brakującej śrubki, pęknięcia, wycieku),
krok 2: zbierz reprezentatywne zdjęcia OK/NOK z realnej produkcji,
krok 3: wykonaj adnotację danych (oznaczenie defektów),
krok 4: użyj gotowego repozytorium (np. Ultralytics YOLO) i wyszkol model,
krok 5: zbuduj prosty interfejs testowy (np. web) i podłącz kamerę.
Na początku lepiej nie zaczynać od integracji z PLC i MES, tylko od „off‑line” analizy zarejestrowanych obrazów. Dopiero gdy model osiąga sensowną skuteczność i stabilność, ma sens łączenie go z automatyką linii i logiką decyzji OK/NOK.
Co sprawdzić: czy ktoś w zespole faktycznie potrafi pracować z Pythonem, Dockerem i GitHubem oraz czy produkcja jest gotowa na fazę testów, w której model będzie się jeszcze mylił.
Jakie kompetencje są potrzebne w firmie, żeby utrzymać system kontroli jakości oparty na open source?
Potrzebny jest miks IT, automatyki i podstaw data science. Zespół minimalny to zwykle:
osoba techniczna z IT (Python, kontenery, podstawy ML, praca z repozytoriami),
automatyk lub inżynier UR, który rozumie PLC, czasy cyklu, sygnały I/O,
ktoś z jakości lub produkcji, kto umie jasno zdefiniować kryteria OK/NOK i normy.
Dobrym sygnałem jest sytuacja, w której „informatyk fabryczny” potrafi uruchomić projekt YOLO z GitHuba, a automatyk rozumie podstawy struktury kodu i logiki integracji. Wtedy projekt open source przestaje być pojedynczym „eksperymentem entuzjasty”, a staje się kompetencją organizacji.
Co sprawdzić: kto będzie właścicielem projektu (decyzje techniczne i biznesowe) oraz czy w grafiku tych osób jest realnie czas na rozwijanie i utrzymanie systemu, a nie tylko gaszenie pożarów.
Jakie są największe ryzyka przy zastępowaniu komercyjnego systemu wizyjnego otwartym modelem?
Najczęstsze problemy to: przeszacowanie możliwości zespołu, brak jasnej odpowiedzialności, niedoszacowanie pracy przy zbieraniu i adnotacji danych oraz zderzenie z wymaganiami audytowymi klienta. Często pojawia się też „lista życzeń”: pełna elastyczność, ogromne oszczędności, zero nakładu pracy i od razu poziom stabilności systemu „z pudełka”. Taki zestaw jest nierealny na pierwszym projekcie.
Dobrą praktyką jest podejście etapowe:
krok 1: projekt pilotażowy bez wyłączania istniejącego systemu komercyjnego,
krok 2: dłuższy okres pracy równoległej (open source jako „druga opinia”),
krok 3: dopiero po udokumentowaniu wyników – ewentualne przejęcie roli głównego systemu.
Co sprawdzić: jakie wymogi formalne (certyfikaty, audyty, SLA) są narzucone przez klientów i normy branżowe oraz czy da się je spełnić, korzystając z rozwiązań open source i własnych procedur walidacji.
