Analiza danych · Automatyzacja · Projekt w budowie

Analiza zbiorników na olej przepracowany — od odczytu poziomu do decyzji o zbiorniku

Zbiorniki z czujnikami poziomu stoją u klientów i nadają raz na dobę. Metoda odróżnia prawdziwe odbiory od zakłóceń czujnika, liczy napływ i podpowiada, które zbiorniki warto utrzymać. Status: w budowie — metoda analityczna sprawdzona na danych historycznych.

Klient
RAN-SIGMA Sp. z o.o.
Branża
Gospodarka odpadami
Rok
2026
Narzędzie
Python na serwerze firmy
Status
W budowie · metoda sprawdzona na danych z 2025 i I półrocza 2026

Wyzwanie

Zastrzeżenie: RAN-SIGMA to firma, którą zarządzam. Ten system powstał najpierw na własne potrzeby i dopiero sprawdzony trafił do oferty — tak samo testuję każde rozwiązanie, zanim zaproponuję je klientowi.

RAN-SIGMA stawia u klientów zbiorniki na olej przepracowany z czujnikami poziomu. Czujnik nadaje raz na dobę do portalu producenta, a portal pokazuje migawkę: ile jest w zbiorniku dziś. Nie odpowiada na pytania, które decydują o opłacalności: ile oleju naprawdę napływa do danego zbiornika w roku, kiedy były odbiory, czy utrzymywanie zbiornika u tego klienta się zwraca i który zbiornik lepiej przenieść gdzie indziej.

Dane z czujników mają też własne pułapki. Zdarzają się odczyty zerowe, po których poziom wraca co do litra w ciągu doby, czyli zakłócenia techniczne, nie odbiory. W punktach, gdzie zbiornik jest opróżniany i szybko napełniany, spadek poziomu nie musi oznaczać odbioru przez firmę. Przerwy w transmisji zostawiają luki, w których liczba zdarzeń jest nieznana. Liczenie „na oko" z portalu dawało wyniki różniące się kilkukrotnie w zależności od tego, co uznać za odbiór.

Co już działa: metoda analityczna

Pierwszym etapem nie był bot, tylko metoda. Portal producenta eksportuje historię poziomu każdego zbiornika za dowolny okres. Na eksportach z 2025 roku i pierwszego półrocza 2026 powstała i została sprawdzona analiza, która z surowych odczytów wyprowadza zdarzenia i oceny.

Rozpoznanie eksportu po zawartości

Plik jest rozpoznawany po układzie arkuszy i nagłówków, nie po nazwie. Każdy arkusz to jeden zbiornik z pojemnością i serią odczytów. Plik niekompletny albo nieczytelny trafia do kwarantanny z opisem powodu, zamiast psuć wynik.

Ledger odczytów z deduplikacją

Kolejne eksporty nakładają się w czasie. Ledger trzyma jeden odczyt na zbiornik i czas, wykrywa konflikty między plikami i zostawia je do rozstrzygnięcia przez człowieka, nie nadpisuje po cichu. Surowe eksporty zostają w archiwum z sumą kontrolną.

Odfiltrowanie zakłóceń czujnika

Odczyt zerowy z powrotem do poprzedniego poziomu w ciągu doby to artefakt techniczny i jest usuwany, ale liczony w raporcie jakości. Nagły spadek z szybkim powrotem w kilka dni to epizod niejednoznaczny: zostaje w danych, nie liczy się jako odbiór i czeka na uzgodnienie z dokumentami przekazania odpadu.

Rozpoznanie odbiorów i napływu

Spadek poziomu powyżej progu wyliczonego z szumu danego czujnika to zdarzenie: potwierdzone, niepotwierdzone (odbiór i napływ w tej samej dobie) albo w luce transmisji. Z reszty serii wynika napływ, tempo i prognoza, kiedy zbiornik będzie pełny.

Ocena jakości danych per zbiornik

Pokrycie odczytami, długość przerw, liczba artefaktów i podejrzany czujnik składają się na ocenę jakości. Zbiornik ze słabymi danymi nie dostaje rekomendacji, tylko zadanie weryfikacji obiektu. Metoda nie udaje, że wie więcej, niż mówią dane.

Co powstaje: automatyzacja i zasilanie CRM

Etapy poniżej są zaprojektowane i czekają na decyzje wdrożeniowe. Nie działają jeszcze produkcyjnie.

Nocny import eksportu

Bot ma co noc pobierać z portalu historię z ostatniego tygodnia, żeby okna nakładały się i pokrywały przerwy w transmisji. Konto techniczne tylko do odczytu, praca na serwerze firmy, żadnych danych klientów w chmurze zewnętrznej.

Codzienny feed do CRM

Automat ma przekazywać do CRM stan każdego zbiornika: poziom, procent pojemności, wykres z ostatnich tygodni i prognozę pełności. Te dane trafią na kartę zbiornika, na mapę zbiorników i na mapę odbiorów, z której planowane są trasy. CRM nie liczy nic sam; jedno źródło prawdy to ledger automatu.

Karta przeglądu i decyzja

Dwa razy w roku każdy zbiornik ma dostać kartę z liczbami z czujnika, oceną jakości danych i rekomendacją regułową. Właściciel obszaru wpisuje decyzję: utrzymać, obserwować, wycofać albo przenieść. Lista decyzji zasila wycofania i fakturowanie. Próg opłacalności jest ustawieniem w CRM, nie liczbą wpisaną w kod.

Co rozstrzyga automat, a co człowiek

Automat: zdarzenia i ocena jakości danych

Z surowych odczytów program wyprowadza zdarzenia i ocenę jakości danych; rekomendacja z priorytetem powstanie w etapie karty przeglądu, który jest w budowie. Liczby są odtwarzalne: ten sam plik daje ten sam wynik co do litra, a każda zmiana metody jest porównywana z liczbami referencyjnymi z danych historycznych.

Człowiek: decyzja i uzgodnienie

Decyzja o zbiorniku należy do właściciela obszaru. Epizody niejednoznaczne rozstrzyga porównanie z kartami przekazania odpadu, nie algorytm. Konflikt między dwoma eksportami zamyka człowiek, a odrzucona wartość zostaje w ledgerze do audytu.

Na czym sprawdzono metodę

Zamiast jednej liczby z portalu firma ma dla każdego zbiornika serię zdarzeń z datami, oddzielone zakłócenia czujnika i ocenę, na ile danym można ufać. Dopiero na tym da się oprzeć decyzję, który zbiornik utrzymać, a który przenieść. Metoda została przeliczona na eksportach z 2025 roku i pierwszego półrocza 2026 i poprawiona w kilkudziesięciu rundach recenzji, zanim ktokolwiek zaczął pisać bota.

18 mies.
danych historycznych (2025 i I półrocze 2026), na których sprawdzono metodę
3 klasy
zdarzeń: potwierdzone, niepotwierdzone, w luce transmisji
2 klasy
zakłóceń odróżnione od odbiorów: artefakt czujnika i epizod niejednoznaczny

Co zmienia metoda

  • Migawka z portalu — zastąpiona historią zdarzeń z datami dla każdego zbiornika
  • Zakłócenia liczone jako odbiory — artefakty czujnika odfiltrowane, epizody niejednoznaczne odłożone do uzgodnienia
  • Decyzja na wyczucie — zastąpiona kartą z liczbami, oceną jakości danych i rekomendacją regułową

Granice metody

Czujnik nadaje raz na dobę, więc odbiór i napełnienie w tej samej dobie są dla metody niewidoczne albo niepotwierdzone. Tego ograniczenia nie da się obejść analizą; rozstrzyga je uzgodnienie z dokumentami przekazania odpadu. Podobnie luka w transmisji dłuższa niż półtorej doby oznacza, że liczba zdarzeń w niej jest nieznana i metoda mówi to wprost, zamiast zgadywać.

Drugie ograniczenie jest organizacyjne: rekomendacja jest tyle warta, ile mapa przypisań zbiornik–klient–rola. Zbiornik bez dowiązania dostaje kartę bez rekomendacji i decyzję „wstrzymana" z terminem uzupełnienia.

Czego tu nie ma

Na tej stronie nie ma nazw klientów, liczby zbiorników, wolumenów w litrach, stawek ani progów opłacalności. Pokazujemy metodę i architekturę, bo to one są przenośne na inne floty pojemników z czujnikami. Dane operacyjne RAN-SIGMA pozostają wewnątrz firmy.

Pytania i odpowiedzi

Pytania o ten projekt

Dlaczego nie wystarczy portal producenta czujników?

Portal udostępnia historię surowych odczytów poziomu, ale nie zamienia jej w rejestr zdarzeń ani decyzji. Nie odróżnia odbioru od zakłócenia czujnika, nie liczy napływu w okresie, nie ocenia jakości danych i nie ma miejsca na decyzję o zbiorniku. Do zarządzania flotą zbiorników potrzebna jest historia zdarzeń, a tę trzeba wyprowadzić z surowych odczytów.

Czym jest artefakt czujnika i jak metoda go rozpoznaje?

To odczyt zerowy, po którym poziom wraca do wartości sprzed co do litra w ciągu doby. Prawdziwy odbiór nie zachowuje się w ten sposób. Takie epizody są usuwane z serii, ale liczone w raporcie jakości, a czujnik z wieloma artefaktami dostaje status podejrzanego i zadanie weryfikacji.

Jak metoda odróżnia odbiór od wypadnięcia czujnika na kilka dni?

Spadek do zera z powrotem do poprzedniego poziomu w kilka dni to epizod niejednoznaczny. Zostaje w danych, ale nie liczy się jako odbiór. Rozstrzyga porównanie z kartami przekazania odpadu za ten okres, bo tylko one mówią, czy odbiór naprawdę się odbył.

Co dostanie CRM po wdrożeniu nocnego importu?

Dla każdego zbiornika: ostatni potwierdzony poziom, procent pojemności, wykres z ostatnich tygodni, prognozę pełności i status danych. Te same wartości pojawią się na karcie zbiornika, na mapie zbiorników i na mapie odbiorów, z której planowane są trasy. CRM niczego nie liczy sam; pokazuje wynik automatu.

Na jakim etapie jest projekt?

Metoda analityczna jest sprawdzona na eksportach z 2025 roku i pierwszego półrocza 2026 i ma liczby referencyjne, z którymi porównuje się każdą zmianę co do litra. Nocny import, codzienny feed do CRM i cykl przeglądów są zaprojektowane i czekają na decyzje wdrożeniowe właścicieli. Ta strona będzie aktualizowana wraz z postępem, a status w nagłówku odpowiada stanowi faktycznemu.

Czy to zadziała dla innych pojemników z czujnikami?

Metoda nie zależy od branży: potrzebuje serii poziomów z pojemnością i datami. Progi zdarzeń liczy z szumu każdego czujnika osobno, więc dopasowuje się do sprzętu. Zmienia się tylko parser eksportu z danego portalu i mapa przypisań pojemnik–klient.

Masz pojemniki u klientów i czujniki, którym nie do końca ufasz?

Na pierwszej rozmowie sprawdzamy, jaki eksport daje Twój portal i czy da się z niego wyprowadzić historię zdarzeń. Jeśli tak, metoda jest do przeniesienia.

Szczegóły projektu

Technologie

Python · openpyxl · czujniki Kingspan Watchman · Supabase (CRM) · Playwright (planowane)

Zakres prac