Analiza danych z monitoringu konstrukcji — od równania do alertu.
Surowy odczyt czujnika to jeszcze nie informacja. Inclify przelicza kanały własnymi równaniami względem pomiaru referencyjnego, pilnuje progów ostrzegawczych i alarmowych — i powiadamia właściwych ludzi SMS-em, e-mailem lub pushem.
Twoje wzory, nie nasze założenia
Każdy projektant liczy inaczej. Zamiast sztywnych przeliczników dostajesz silnik równań, w którym zapiszesz dokładnie tę formułę, którą przyjęto w projekcie monitoringu.
- Własne równania na kanałach pomiarowych: funkcje matematyczne, statystyka, stałe projektu
- Pełnoekranowy edytor z walidacją na żywo — błąd składni czy brakującą zależność widać przed zapisem
- Wyniki liczone względem pomiaru referencyjnego (baseline) per projekt i per czujnik
- Zmiana baseline'u lub równania = automatyczne przeliczenie kanału
Pierwszy stabilny pomiar kanału staje się punktem zerowym — bez ręcznej konfiguracji przy uruchamianiu projektu.
Punkt odniesienia z konkretnej chwili — np. sprzed rozpoczęcia robót w sąsiedztwie albo po zakończeniu naprawy.
Wartość referencyjna wpisana wprost — gdy zero definiuje projektant, a nie historia pomiarów.
Pomiary zerowe z wcześniejszego systemu lub kampanii pomiarowej wgrywasz plikiem — ciągłość odniesienia zostaje zachowana.
Trzy typy alarmów, jeden cykl życia
Alarm, którego nikt nie potwierdził, to alarm, który nie zadziałał. Dlatego oprócz progów platforma pilnuje całego procesu obsługi.
Progowy
Progi ostrzegawcze i alarmowe na dowolnym kanale — surowym lub przeliczonym równaniem. Osobne poziomy dla stanu WARNING i ALARM.
No-data
Kontrola braku danych: gdy czujnik lub rejestrator milknie, platforma zgłasza to tak samo poważnie jak przekroczenie progu. Cisza na kanale to też sygnał.
Dynamiczny (FFT)
Progi na wynikach analizy drgań: RMS, wartościach szczytowych i widmie. Zdarzenie dynamiczne oceniane automatycznie, nie po fakcie.
Cykl życia alarmu
- Stany OK / WARNING / ALARM widoczne na dashboardach w czasie rzeczywistym
- Potwierdzanie alarmów — wiadomo, kto i kiedy przejął zgłoszenie
- Wyciszanie na czas prac serwisowych, bez wyłączania monitoringu
- Pełna historia zdarzeń alarmowych i powiadomienie testowe do weryfikacji konfiguracji
Kanały powiadomień
- SMS — dociera także tam, gdzie nie ma zasięgu danych ani zainstalowanej aplikacji
- E-mail — z kontekstem zdarzenia, do skrzynek zespołu i dokumentacji
- Push — natychmiast na telefonie osób dyżurujących
- Powiadomienia w czasie rzeczywistym, do osób przypisanych w projekcie — zgodnie z rolami i izolacją danych organizacji
Od progu do zamknięcia zgłoszenia
Alarm w Inclify ma stan, historię i właściciela. Poniżej wszystko, co dzieje się między przekroczeniem progu a powrotem kanału do normy.
Cztery stany, w tym osobny dla ciszy na kanale. Brak danych nie chowa się pod stanem OK — jest widoczny jako odrębna sytuacja do obsłużenia.
Powrót do stanu OK wymaga zejścia poniżej progu o zadany margines. Kanał drgający wokół wartości granicznej nie generuje serii alarmów i odwołań.
Okno czasowe oceny ustawiane per alarm — od reakcji na pojedynczy odczyt po ocenę zachowania kanału z całej doby.
Alarm może pilnować odczytu wprost z czujnika albo wartości po równaniu obliczeniowym — zależnie od tego, co w projekcie jest wielkością kontrolowaną.
Potwierdzenie zapisuje, kto przejął zgłoszenie. Wyciszenie ma datę końca — po niej alarm sam wraca do pracy, bez pamiętania o odwieszeniu.
Minimalny odstęp między powiadomieniami z tego samego alarmu. Jedno zdarzenie to jedna wiadomość, a nie kilkadziesiąt SMS-ów w nocy.
Każda zmiana stanu, potwierdzenie, wyciszenie i wysłane powiadomienie w jednej osi czasu — materiał na rozliczenie zdarzenia po fakcie.
Każdy sam wybiera kanał powiadomień, minimalny stan, od którego chce być budzony, subskrybowane projekty i wyciszone alarmy.
Powiadomienie testowe
Konfigurację sprawdzasz wysyłką testową, a nie pierwszym prawdziwym przekroczeniem progu. Numer z literówką wychodzi na jaw w dniu wdrożenia.
Ocena odporna na wyścigi
Jednoczesne oceny tego samego alarmu są szeregowane blokadą doradczą, spóźnione wyniki odrzucane, a powiadomienie zapisywane w tej samej transakcji co zmiana stanu. Nie ma alarmu bez powiadomienia ani powiadomienia bez alarmu.
Sześć raportów, sześć konkretnych pytań
Osobna zakładka w panelu, jedno okno analizy dla wszystkich raportów: 1 d, 7 d, 14 d, 30 d lub 90 d.
Analiza AI
Statystyki per zmienna, ostatnie 24 h odniesione do okna bazowego, wykryte skoki i martwe kanały — a na wierzchu narracja, lista ustaleń i ranking rekomendacji.
Dług kalibracji
Ocena punktowa dla każdego kanału i rekomendowana data przeglądu. Zamiast „kiedyś trzeba objechać czujniki” dostajesz listę w kolejności.
Kompensacja temperatury
Rozdzielenie wpływu temperatury od rzeczywistej zmiany zachowania konstrukcji — na danych z wybranego okna, kanał po kanale.
Ryzyko 7 / 30 dni
Wskaźnik i poziom ryzyka dla każdego kanału wraz z szacowanym czasem do zdarzenia w dniach. Podstawa do ustawienia kolejności działań.
Strojenie alarmów
Szacunek liczby alertów na tydzień przed zmianą i po zmianie progu — a jeśli liczby się zgadzają, sugerowane progi zastosujesz jednym kliknięciem.
SLA danych
Liczba próbek względem oczekiwanej, rzeczywista kadencja odczytów, p95 opóźnień i lista luk. Twarda podstawa rozmowy o kondycji instalacji.
Liczby liczy baza. Model tylko je opisuje.
Warto wiedzieć, gdzie w tym raporcie kończy się arytmetyka, a zaczyna język. Dlatego rozpisujemy to wprost.
Co liczy baza
- Zapytanie po tabeli wartości przeliczonych: statystyki osobno dla każdej zmiennej projektu
- z-score ostatnich 24 h względem okna bazowego — 7 d, 1 mies., 2 mies. lub 90 d
- Wykrywanie skoków wartości i kanałów, które przestały się zmieniać
- Ranking anomalii — to on decyduje, o czym w ogóle będzie mowa w raporcie
Co pisze model
- Model językowy dostaje gotowe, policzone wcześniej anomalie — nie surowe pomiary
- Na ich podstawie powstaje narracja, lista ustaleń i ranking rekomendacji
- Każda rekomendacja ma tę samą strukturę: działanie, cel, dowód z danych
- Gdy model jest niedostępny, raport i tak powstaje — w deterministycznej wersji tekstowej, na tych samych liczbach
Raport nie zastępuje oceny inżyniera. Skraca drogę do miejsca, od którego ta ocena się zaczyna.
Analizy, które oszczędzają godziny przeglądania wykresów
Zestaw analiz liczonych na danych projektu — rzeczowo i powtarzalnie, jako wsparcie oceny inżyniera, nie jej zamiennik.
Zbiorcza ocena stanu projektu monitoringu na podstawie alarmów, kompletności danych i zachowania kanałów — jeden rzut oka zamiast przeglądu wszystkich wykresów.
Odczyty odstające od dotychczasowego zachowania kanału oraz czujniki, które przestały nieść informację — wskazywane automatycznie, do weryfikacji przez inżyniera.
Rozdzielenie wpływu temperatury °C od rzeczywistej zmiany zachowania konstrukcji — mniej fałszywych alarmów w upał i mróz.
Ocena trendów kanałów w horyzoncie 7 i 30 dni względem progów projektu — które kanały wymagają uwagi w pierwszej kolejności.
Kompletność odczytów, luki, opóźnienia i stabilność transmisji per kanał — twarda podstawa do rozmowy o kondycji instalacji pomiarowej.
Każda zmiana progu, równania czy baseline'u zapisana: kto, co, kiedy. Wyniki analiz zawsze da się powiązać z konfiguracją, na której powstały.
Analityka jest tak dobra, jak dane, które dostaje
Czujniki i akwizycja
Ponad 40 typów czujników, odczyty domyślnie co 15 min lub częściej i cztery drogi danych: REST, CSV/XLSX, FTP, istniejące rejestratory.
Czujniki do monitoringu konstrukcji →Monitoring i dashboardy
Ponad 35 typów widżetów, aktualizacje w czasie rzeczywistym i eksporty CSV/XLSX — wyniki analiz widzisz tam, gdzie resztę danych.
Monitoring konstrukcji online →Cała platforma
Pełna droga danych: od czujnika, przez równania i progi, po dashboardy, alerty i partycjonowaną bazę pod miliardy rekordów.
Przegląd platformy →Pokaż nam swoje progi i równania
Na demo skonfigurujemy przykładowy alarm od równania po powiadomienie testowe — na realnym projekcie, nie na slajdach.