Obejrzymy wasze urządzenia i powiemy, co naprawdę da się z nich odczytać
Z dokumentacji sterowników i ze składu waszego parku: które odczyty są dostępne od razu, gdzie trzeba będzie zamontować czujniki i którymi ustawieniami da się sterować zdalnie.
Urządzenia stoją na obiektach, a wy jesteście w biurze. Zakładamy na nie czujniki, podłączamy je do internetu i wyświetlamy odczyty w jednym programie, który otwiera się w przeglądarce. Jeśli temperatura wyjdzie poza granice, drzwi zostaną otwarte albo zniknie zasilanie, odpowiedzialny pracownik dostaje wiadomość natychmiast, a nie dowiaduje się rano po zepsutym towarze.
Mówiąc prosto: na urządzeniach montuje się małe przyrządy, które nieprzerwanie mierzą to, co ważne — temperaturę wewnątrz komory, czy drzwi są otwarte, czy jest zasilanie, czy pracuje sprężarka. Raz na minutę pomiary idą przez internet na serwer. Otwieracie przeglądarkę i widzicie stan każdego urządzenia na każdym obiekcie.
IoT oznacza internet rzeczy. Chodzi o to, że zamiast człowieka chodzącego z zeszytem i zapisującego odczyty, urządzenia same wysyłają je do oprogramowania. Nie trzeba w tym celu nic robić: dane przychodzą same, całą dobę, także nocą i w weekendy.
Główna różnica wobec zwykłego ekranu z liczbami polega na tym, że system nie czeka, aż ktoś na niego spojrzy. Porównuje każdy pomiar z normą, którą ustaliliście dla tego urządzenia. Jeśli norma zostanie naruszona, znajduje w kartotece pracownika odpowiedzialnego za ten obiekt i wysyła wiadomość jemu.
Przykład. W komorze mroźniczej w magazynie dopuszczalne jest −18 °C. O 21:04 czujnik melduje −16,8 °C. Nikt w tej chwili nie patrzy na ekran. Piętnaście minut później temperatura wciąż rośnie — system tworzy zdarzenie, zapisuje w nim numer komory, adres magazynu, godzinę i wartość bieżącą, i wysyła wiadomość do dyżurnego magazynu. O 21:33 ten przyjeżdża i znajduje niedomknięte drzwi śluzy. Towar jest cały.
Żadnego urządzenia nie trzeba wymieniać. Lodówka, automat vendingowy, pompa albo centrala wentylacyjna zostają na miejscu — dokłada się to, czego im brakuje: czujniki, urządzenie łączności i oprogramowanie, w którym cały park widać jedną listą.
Każdy projekt zaczyna się od trzech pytań: co fizycznie da się na tym urządzeniu zmierzyć; jak dane opuszczą obiekt i trafią do internetu; kto odpowiada za odchylenie i ile ma minut na reakcję. Dopóki trzecie pytanie nie ma odpowiedzi, dostajecie ładny ekran z liczbami, a nie system, który czemukolwiek zapobiega.
| Co jest zrealizowane | Do czego to się sprowadza |
|---|---|
| Odczyt widać na ekranie w czasie rzeczywistym | obserwacja |
| Odczyt zapisuje się w historii z dokładną godziną | podstawa |
| Wyjście poza normę zapisuje się jako osobne zdarzenie | podstawa |
| Zdarzenie ma konkretnego pracownika i termin reakcji | monitoring |
| Reakcja pracownika zapisuje się i zamyka zdarzenie | monitoring |
Granica biegnie wzdłuż dwóch rzeczy: zdarzenie ma człowieka i ma termin. Ekran pokazujący bieżącą temperaturę sam z siebie niczego nie ratuje — dopóki nikomu nie polecono się tym zająć, odchylenie pozostaje kreską na wykresie. Dlatego norma, osoba odpowiedzialna, termin reakcji i oznaczenie zamknięcia są obowiązkowymi polami systemu, a nie opcjonalnymi ustawieniami.

Granice możliwości wyznacza urządzenie, a nie oprogramowanie: odczytać da się tylko to, co ono mierzy albo co zmierzy czujnik, a zmienić tylko to, na co pozwala jego sterownik. Co jest dostępne w waszym modelu, ustala się z dokumentacji producenta na etapie obserwacji.
Cała droga jednego pomiaru — od urządzenia na lodówce do wiadomości na telefonie. Niżej na stronie każde z tych sześciu ogniw omawiamy dokładniej.

To, co się obserwuje: komora chłodnicza, witryna, zamrażarka, automat vendingowy, pompa, centrala wentylacyjna, linia produkcyjna. Każde urządzenie zapisuje się w systemie jako osobną kartę — co to jest, na którym obiekcie stoi, co mówi jego karta katalogowa i kiedy było ostatnio serwisowane.
Przyrządy, które mierzą. Czujnik to małe urządzenie mierzące jedną wielkość: temperaturę, wilgotność, ciśnienie, prąd, czy drzwi są otwarte, czy jest napięcie. Sterownik to własny mózg urządzenia: w niektórych modelach potrafi on przekazywać na zewnątrz swoje odczyty i kody błędów, a wtedy dodatkowe czujniki nie są potrzebne. Tam, gdzie nie potrafi, montujemy własne.
Jak odczyty trafiają do internetu. Na obiekcie instaluje się małe urządzenie łączności: zbiera pomiary z czujników i wysyła je na serwer kablem internetowym, przez Wi-Fi albo przez kartę SIM. Jeśli internet padnie, pomiary gromadzą się w jego pamięci i wychodzą po powrocie połączenia. Milczenie samego urządzenia też liczy się jako alarm.
Miejsce, w którym żyją dane. Serwer to komputer w zabezpieczonym centrum danych, pracujący całą dobę. „W chmurze” oznacza, że nie stoi w waszym biurze: nie ma czego kupować, chłodzić ani serwisować, a do oprogramowania da się dostać z dowolnego miejsca. Serwer przyjmuje pomiary, przechowuje je w historii, porównuje z normami i zamienia odchylenie w zdarzenie.
Program, który widzicie. Otwiera się w przeglądarce na komputerze albo telefonie po loginie i haśle — nie ma czego instalować. Na jednym ekranie: obiekty, urządzenia, bieżące odczyty i lista otwartych odchyleń. Urządzenia różnych marek wyglądają tak samo.
Wynik całego łańcucha: wiadomość do konkretnego pracownika, wykresy i dzienniki do wyjaśniania, raporty miesięczne oraz — tam, gdzie sterownik na to pozwala — zmiana ustawień urządzenia prosto z panelu.
Częstotliwość pomiarów i dopuszczalne granice ustala się osobno dla każdego typu urządzeń, a nie jedną liczbą dla całej sieci. Zamrażarka, witryna chłodnicza z daniami gotowymi i magazynowa komora chłodnicza różnią się i tym, jaka temperatura jest normalna, i tym, jak długo wolno ją przekraczać.
Chłodnictwo to obszar, w którym monitoring zwraca się najszybciej, bo naruszenia reżimu nie widać gołym okiem. Nikt nie zauważa uchylonych na noc drzwi, a rano decyzja jest już podjęta za was.
Przykład. W piątek wieczorem w komorze mroźniczej pada sprężarka. W nocy towar się rozmraża, w sobotę częściowo zamraża ponownie, a w poniedziałek partia idzie na odpis. Przy monitoringu wiadomość o awarii przychodzi w piątek o 21:00, a sprawa kończy się telefonem do firmy serwisowej.
Urządzenia też bywają różne. Zamrażarka i witryna chłodnicza z daniami gotowymi nie mają wspólnej ani dopuszczalnej temperatury, ani szybkości jej naruszenia, ani kosztu błędu. Dlatego normę ustala się dla każdego urządzenia, a nie raz dla całej sieci — z uwzględnieniem tego, co jest w środku przechowywane.
Co da się odczytać z urządzenia chłodniczego:
Zestaw zależy od konkretnego modelu. Jeśli fabryczny sterownik udostępnia wartości i kody błędów, system odczytuje je bezpośrednio. Jeśli nie, montuje się zewnętrzne czujniki temperatury, drzwi i zasilania. Co jest dostępne w waszym urządzeniu, ustala się z jego dokumentacji na etapie obserwacji, a nie obiecuje z góry.

Dlatego normy konfiguruje się pod typ urządzenia i pod towar w jego wnętrzu. Bez tego wiadomości zaczynają przychodzić bez przerwy, pracownicy przestają je otwierać — a system pracuje na darmo.
Przyrządy używane w tych grupach są mniej więcej takie same. Różnica leży w dopuszczalnym reżimie, w koszcie błędu i w tym, do kogo idzie wiadomość. Struktura wszędzie jest identyczna: urządzenie, obiekt, odczyty, normy, zdarzenia, osoba odpowiedzialna.

Punkt bez sprzedawcy: po prostu nie ma komu zauważyć, że drzwi się nie domknęły albo że urządzenie stanęło. Sprzęt stoi w biurze, zakładzie albo coworkingu, a pracownik zagląda tam raz na kilka dni. Kontrola temperatury i drzwi jest tutaj jedynym sposobem, żeby dowiedzieć się o problemie na czas.
Głębokie temperatury ujemne i duży zapas chłodu: odchylenie rozwija się powoli i wykrywa przez zepsucie całej partii. Kontroluje się temperaturę, czas przebywania poza normą, pracę sprężarki i odszranianie.
Na sali sprzedaży drzwi otwiera się dziesiątki razy na zmianę, więc reżim jest naruszany bez przerwy. Liczy się zatem nie samo przekroczenie, lecz to, jak długo trwa i jak często powtarza się w ciągu dnia.
Duża objętość z kilkoma strefami o różnych temperaturach: jeden punkt pomiaru nie opisuje komory. Montuje się kilka czujników, a drzwi i zasilanie kontroluje osobno — zatrzymanie komory oznacza utratę całej zawartości, a nie jednej półki.
Kilka komór i agregatów na jednym obiekcie, pracujących na zmiany i całą dobę. Potrzebny jest podział odpowiedzialności według stref, długa historia i raport o zachowaniu reżimu za miesiąc albo kwartał.
Sieć punktów z jednakowym sprzętem: dziesiątki witryn i zamrażarek skrzyniowych pod różnymi adresami. Wartość leży tu w porównaniu — gdzie odchylenia się powtarzają, który punkt systematycznie wypada z reżimu, które urządzenie kwalifikuje się do naprawy.
Przechowywanie surowców i wyrobów gotowych, gdzie reżim jest wymogiem, a nie wygodą. Poza wiadomościami potrzebna jest dowodliwość: wykres każdej komory za okres i zapisy o tym, kto i jak zareagował na odchylenia.
Osobną grupę tworzą urządzenia, których sterownik nigdy nie był projektowany do komunikacji na zewnątrz. Podłącza się je czujnikami zewnętrznymi: temperatury, drzwi, zasilania, poboru prądu. Danych jest mniej niż z urządzenia inteligentnego, ale to, co najważniejsze — reżim, drzwi, zasilanie i sprężarka — widać, a takie urządzenie stoi na wspólnej liście obok pozostałych.
Każdy odczyt żyje w systemie w dwóch postaciach. Pierwsza to sama wartość, którą po prostu przechowuje się w historii. Druga to reguła: przy jakiej wartości i po ilu minutach staje się to odchyleniem, o którym trzeba komuś powiedzieć.
Przykład. Temperaturę −16 °C w komorze mroźniczej przechowuje się zawsze, co minutę. Ale wiadomość wychodzi tylko wtedy, gdy utrzyma się powyżej −18 °C dłużej niż piętnaście minut z rzędu.
Pełna lista tego, co się odczytuje i kontroluje:
Utrata łączności to nie drobiazg, lecz pełnoprawny alarm. Milczące urządzenie nie oznacza „brak danych”, lecz „nic nie wiemy o tym obiekcie”. Temperatura może tam być w normie, a może rosnąć od godziny. Dlatego utrata łączności tworzy takie samo zdarzenie jak alarm temperaturowy, zamiast zostawiać lukę na wykresie.

Poziomy są cztery, a poziom decyduje o tym, kogo i jak system niepokoi:
Każdy obiekt w systemie ma odpowiedzialnego pracownika, a każdy typ zdarzenia własną regułę doręczania. System nie wysyła wszystkiego do wszystkich: patrzy, na którym obiekcie jest odchylenie, jakiego jest typu i która jest godzina, i według tej reguły wybiera adresata.
Jeśli pracownik nie przyjął zdarzenia w wyznaczonym czasie, przechodzi ono automatycznie do następnej osoby w łańcuchu. Nocą, w weekendy i w święta adresat może być inny — to też konfiguruje się z góry.
Typ, urządzenie i obiekt, godzina początku i końca, odczyty w chwili powstania, do kogo i kiedy poszła wiadomość, kto ją przyjął, co zrobił i czym się to skończyło. Tyle wystarczy, żeby miesiąc później zbadać przypadek z zapisów, a nie z tego, co pamięta zmiana.
| Warunek | Czas utrzymywania | Zdarzenie |
|---|---|---|
| Temperatura powyżej górnej granicy reżimu | 15 min | ostrzeżenie |
| Temperatura powyżej granicy | 45 min | alarm |
| Drzwi otwarte nieprzerwanie | 5 min | ostrzeżenie |
| Temperatura rośnie przy zamkniętych drzwiach | 10 min | alarm |
| Brak napięcia przy urządzeniu | 1 min | alarm |
| Sterownik zwrócił kod błędu | natychmiast | alarm |
| Urządzenie nie melduje się | 20 min | alarm |
| Sprężarka pracowała dłużej niż zwykle w ciągu doby | 24 godziny | do serwisu |
Ekran z systemu; wartości są poglądowe. Kolumna z czasem utrzymywania to okres, przez jaki system czeka przed podniesieniem alarmu. Bez niego załadunek towaru, normalne odszranianie i sprzątanie sali sprzedaży dawałyby strumień fałszywych alarmów, po którym wiadomości przestaje się czytać.
Każdy przypadek idzie tą samą drogą: coś zmieniło się na urządzeniu → system zapisał to jako zdarzenie → konkretny pracownik dostał wiadomość. Różni je tylko przyczyna i adresat.
Co się dzieje: czujnik zameldował otwarcie drzwi i dłużej, niż wolno, nie melduje ich zamknięcia. Co robi system: tworzy zdarzenie „drzwi otwarte dłużej niż norma” z numerem urządzenia, adresem obiektu i godziną początku. Kto się dowiaduje: pracownik na punkcie — wiadomość pokazuje, jak długo drzwi są już otwarte. Zdarzenie nie zamknie się, dopóki drzwi nie zostaną zamknięte.
Co się dzieje: pomiary pokazują stały wzrost przy zamkniętych drzwiach. Co robi system: zapisuje odchylenie z wartością bieżącą i tempem wzrostu. Kto się dowiaduje: osoba odpowiedzialna za obiekt dostaje ostrzeżenie — towar jest jeszcze dobry i jest czas na reakcję. Jeśli wzrost trwa, ostrzeżenie zamienia się w alarm i idzie do kilku pracowników.
Co się dzieje: urządzenie milczy dłużej niż dopuszczalny odstęp. Co robi system: tworzy alarm — nie „brak danych”, lecz alarm: nie wiadomo, co dzieje się na obiekcie. Kto się dowiaduje: ci sami pracownicy co przy alarmie temperaturowym, bo skutki mogą być takie same.
Co się dzieje: urządzenie samo zwraca kod usterki. Co robi system: zapisuje kod tak, jak jest, i rozszyfrowuje go z dokumentacji tego modelu. Kto się dowiaduje: błąd pojawia się w karcie urządzenia razem z historią — ile razy ten sam kod przyszedł już z tego urządzenia.
Co się dzieje: oznaki potrzeby odszraniania — sygnał sterownika, czas pracy albo kształt cyklu temperaturowego — wychodzą poza normę. Co robi system: tworzy zadanie, a nie alarm. Kto się dowiaduje: odpowiedzialny pracownik — w zadaniu jest napisane, jakie to urządzenie, na którym obiekcie i do kiedy.
Co się dzieje: przy urządzeniu nie ma napięcia. Co robi system: tworzy alarm z dokładną godziną zaniku; temperatura zapisuje się dalej, dopóki urządzenie łączności pracuje na własnej baterii. Kto się dowiaduje: wiadomość wychodzi natychmiast — to na jej podstawie podejmuje się decyzję o wywiezieniu towaru, a nie o tym, kiedy wezwać naprawę.
Ekran z systemu; liczby są poglądowe. Ważna jest tu nie wiadomość, lecz ostatni wiersz: powód i czas trwania trafiają do historii tej komory. Jeśli „niedomknięte drzwi śluzy” zdarzy się w miesiącu jeszcze trzy razy, wyjdzie to w raporcie, zamiast zostać zapomniane razem ze zmianą.
System jest potrzebny wszędzie tam, gdzie urządzenia pracują bez stałego nadzoru, a awarię zauważa się po skutkach. Zestaw odczytów i koszt błędu się zmieniają — struktura systemu pozostaje ta sama.

Jeśli co najmniej trzy z pięciu punktów pasują do waszej sytuacji, zwrot da się policzyć z konkretnych strat, które już ponieśliście w minionych okresach — odpisanego towaru, przestojów, wyjazdów na darmo.
Vending i mikromarkety: moduł telemetryczny, oprogramowanie na urządzeniu i zbieranie zdarzeń — sprzedaż, błędy mechanizmu, temperatura, otwarcia drzwi, stan modułów płatniczych i łączności — zbudowaliśmy sami i opisaliśmy w sekcji o stronie o systemach samoobsługowych. Pozostałe kierunki z listy to ten sam schemat zastosowany do innego typu urządzeń.
Prawdziwy park prawie nigdy nie jest jednorodny. Na jednym obiekcie stoją urządzenia różnych roczników i różnych producentów: jedne mają sterownik, który potrafi przekazywać dane na zewnątrz; drugie mają sterownik, który mówić nie potrafi; a trzecie nie mają nic poza sekcją zasilania.
Stąd zwykły obraz: cztery programy dla czterech typów urządzeń, każdy z własnym loginem, własnymi oznaczeniami stanów i własnymi powiadomieniami. Żaden z nich nie daje całościowego obrazu obiektu, a porównanie ze sobą dwóch urządzeń różnych marek jest w ogóle niemożliwe.
Co robimy w takiej sytuacji:
Czego nie deklarujemy z góry. Nie deklarujemy obsługi konkretnych marek urządzeń i protokołów przemysłowych przed obserwacją. Lista tego, co da się odczytać i czym da się sterować, jest wynikiem pracy z dokumentacją waszego parku i sprawdzenia na obiekcie, a nie wierszem w prezentacji. Jedyne, co ma za sobą gotową realizację, to warstwa vendingowa: nasz własny moduł telemetryczny ze sterownikami MDB i EVA-DTS, opisany w sekcji o stronie o systemach samoobsługowych.

Zmiana ustawień urządzenia z przeglądarki nie zawsze jest możliwa. To cecha urządzenia, a nie oprogramowania, i przypadki są trzy:
Programowo się tego nie obejdzie. Dlatego listę dostępnych poleceń podajemy po obserwacji, a nie przed nią.
Mieszankę marek rozwiązuje się nie na obiekcie, lecz wewnątrz oprogramowania: dla każdego typu urządzeń pisze się tłumacza, a dalej wszystko jest jednakowe. Dlatego nowy typ podłącza się, pisząc jeden moduł, a nie przebudowując panel, reguły i raporty.

Sterowniki potrafiące przekazywać dane na zewnątrz; sterowniki bez takiej możliwości; czujniki zewnętrzne; urządzenia łączności. Każde ma własny format, własne jednostki miary, własne oznaczenia stanów i własną częstotliwość meldowania.
Dla każdego typu źródła pisze się osobny moduł: potrafi on pobrać dane właśnie z niego i przekształca je w jeden format wewnętrzny. Urządzenia się nie zmienia — dostosowuje się oprogramowanie. Taki moduł nazywa się adapterem.
Jednakowe jednostki miary, jedna lista stanów, jednakowy opis zdarzenia. Potem komorę chłodniczą i pompę opisuje się tym samym językiem, a reguły norm pisze raz dla wszystkiego, a nie osobno dla każdej marki.
Jeden ekran dla całego parku: obiekty, urządzenia, odczyty, otwarte odchylenia, historia, raporty i dostępne polecenia. Pracownik pracuje w jednym programie, zamiast przełączać się między czterema.
| Źródło danych | Co da się odczytać | Sterowanie | Stan |
|---|---|---|---|
| Sterownik potrafiący przekazywać dane na zewnątrz | wartości, tryby, kody błędów | częściowo, zgodnie z dokumentacją | online |
| Sterownik, który niczego nie udostępnia | przez czujniki zewnętrzne | nie | online |
| Czujniki zewnętrzne na urządzeniu łączności | temperatura, drzwi, zasilanie, prąd | nie | ostrzeżenie |
| Moduł telemetryczny vendingu | sprzedaż, błędy mechanizmu, temperatura, drzwi | tak | offline |
Ekran z systemu; skład jest poglądowy. W panelu wszystkie cztery wiersze wyglądają tak samo — różnica zostaje tylko w kolumnach „co da się odczytać” i „sterowanie”, czyli w tym, na co źródło fizycznie pozwala. O tym, czy sterowanie istnieje, decyduje sterownik urządzenia, a nie oprogramowanie.
Panel otwiera się w przeglądarce po loginie i haśle — jak zwykła strona internetowa. Nie ma czego instalować, a działa też z telefonu.
Pierwszy ekran. Liczniki u góry: ile urządzeń jest teraz online, ile milczy, ile odchyleń jest w tej chwili otwartych. Niżej lista obiektów, a pod każdym jego urządzenia; każde ma stan oznaczony kolorem (norma, ostrzeżenie, alarm, offline) i wartość bieżącą.
Karta urządzenia otwiera się po kliknięciu dowolnego urządzenia. Zbiera wszystko, co wiadomo o tej lodówce albo tym agregacie:
Ustawienia robi się raz i od tej pory działają same: normy i czasy utrzymywania według typu urządzeń; osoby odpowiedzialne i reguły doręczania wiadomości według obiektu, typu zdarzenia i pory dnia; role pracowników — kto co widzi i kto co może; grupy i filtry według obiektu, regionu i typu urządzeń.
Po co przechowuje się historię. To każdy pomiar i każde zdarzenie, przechowywane z dokładną godziną i dostępne w każdej chwili. Potrzebna jest do pięciu rzeczy:
Osobne słowo o wykresach: są do wyjaśniania, a nie do sprawozdawczości. Gdy na linii temperatury zaznaczone są otwarcia drzwi, załączenia sprężarki i zaniki zasilania, przyczyna odchylenia czyta się od razu — nie trzeba zestawiać czterech różnych ekranów.

Jeśli sterownik poleceń nie przyjmuje, sekcja sterowania po prostu nie pojawia się na karcie. Nie ma tam martwego przycisku — po to, żeby zmiana nigdy nie odniosła wrażenia, że stąd da się urządzeniem sterować.
Na jednym obiekcie z pięcioma lodówkami sprawdzi się każde podejście, nawet zeszyt. Różnica zaczyna się przy pięćdziesięciu urządzeniach i przy pięciuset: lista przestaje mieścić się na ekranie, wiadomości zlewają się w strumień, a pracownik odpowiedzialny za wszystko przestaje odpowiadać za cokolwiek konkretnego.
Przykład. W nocy w jednym z punktów wyłączają prąd. Bez konfiguracji system wysłałby trzydzieści osobnych alarmów — po jednym na urządzenie — a cała reszta utonęłaby w tym strumieniu. Z konfiguracją przychodzi jedna wiadomość: ten obiekt, utrata zasilania, dotyczy 30 urządzeń.
Co zmienia się w miarę wzrostu parku:
Ekran z systemu; liczby są poglądowe. Kolejność liczb nie jest przypadkowa: na pierwszym miejscu stoi nie wielkość parku, lecz to, ile obiektów jest w tej chwili bez obserwacji. Sześć milczących urządzeń to sześć punktów, o których nic nie wiadomo.

Raporty eksportują się do pliku i mogą budować się automatycznie według harmonogramu — na przykład pierwszego dnia każdego miesiąca. Dla warstwy chłodniczej taki raport jest zarazem dowodem warunków przechowywania za okres.
Uprawnienia nadaje się według tej samej struktury: pracownik punktu widzi tylko własne urządzenia, kierownik działu — wszystkie obiekty swojego typu, dyspozytor — podsumowanie całej sieci. Podgląd, przyjmowanie zdarzenia i sterowanie zdalne są rozdzielone, a nie nadawane jednym pakietem.
Czujniki i sterowniki
Przesyłanie do chmury
Jeden panel
Wiadomości i raporty
Podstawowa praca systemu opiera się na prostych regułach: ta wartość dłużej niż tyle minut = ta wiadomość do tej osoby. To wystarcza, żeby pokryć sytuacje awaryjne, i od tego zaczyna się każde wdrożenie.
Gdy nazbiera się miesięcy historii, można nadbudować nad nią analizę danych. Szuka ona nie przekroczenia granicy, lecz zmiany w nawykowym zachowaniu konkretnego urządzenia.
Przykład. Sprężarka zwykle osiąga tryb pracy w osiem minut. Od trzech tygodni potrzebuje dwunastu. Żadna granica nie została przekroczona i żadna wiadomość według reguł by nie poszła — ale urządzenie wyraźnie zmierza do awarii i lepiej zająć się nim, zanim stanie w weekend.
Granicę mówimy wprost. Przewidywanie awarii to coś, co staje się możliwe na zgromadzonych danych, a nie funkcja działająca od pierwszego dnia. Potrzebna jest historia nie tylko odczytów, lecz także samych awarii: bez prawdziwych przypadków nie ma na czym nauczyć modelu. Dlatego w projekcie jest to osobny etap po tym, jak zbieranie danych popracuje przez pewien okres, a nie pozycja w pierwszym wydaniu.
Pokrewnym kierunkiem jest wdrożenie sztucznej inteligencji w procesy biznesowe, gdzie to samo podejście stosuje się do danych z zamówień, zgłoszeń i dokumentów.

Nic z tego nie zastępuje reguł alarmowych: reguły reagują w minutach, analiza pracuje w horyzoncie tygodni. Potrzebne są obie warstwy i wdraża się je dokładnie w tej kolejności.
Etapy idą dokładnie w tej kolejności. Pominięcie obserwacji jest najczęstszym powodem, dla którego system powstaje wokół urządzeń nieudostępniających potrzebnych danych.
Przegląd parku: modele, sterowniki, dokumentacja, co fizycznie da się odczytać z każdego urządzenia, czy na obiektach jest internet. Wynikiem jest lista tego, co dostępne od razu, i tego, co trzeba będzie pokryć czujnikami zewnętrznymi.
Jeden obiekt i kilka urządzeń: montaż, sprawdzenie wymiany na żywym sterowniku, dostrojenie norm i czasów utrzymywania do rzeczywistego zachowania urządzeń, a nie do dokumentacji.
Kto odpowiada za które obiekty, które zdarzenia idą do kogo, co liczy się jako alarm, a co jest tylko notatką. Tutaj konfiguruje się także eskalację i scalanie jednakowych zdarzeń; inaczej strumień wiadomości zdewaluuje system w ciągu miesiąca.
Pozostałe obiekty idą po sprawdzonym schemacie, a nowe typy urządzeń dochodzą jako osobne moduły wymiany. Dalej gromadzi się historia i pojawiają się raporty okresowe oraz analiza danych.
Napiszcie, jakie urządzenia stoją na waszych obiektach, ile ich jest i o których problemach dowiadujecie się dziś dopiero po skutkach. Powiemy, co naprawdę da się z nich odczytać, gdzie potrzebne będą czujniki zewnętrzne i od czego warto zacząć pilotaż.