Istniejące czujniki i rejestratory podłącza się do platformy online bez wymiany sprzętu: rejestrator lub hub wysyła odczyty przez HTTP w formacie JSON, a platforma je przyjmuje, przelicza, pilnuje progów i pokazuje na wykresach. Warunkiem jest uzgodniony kontrakt danych – identyfikator urządzenia i kanału, czas pomiaru w UTC, surowa wartość. Jeśli obiekt ma już czujniki, podłączenie do Inclify trwa kilka dni, a stary system przez ten czas pracuje równolegle.
W skrócie
- Czujniki, rejestratory i oprogramowanie to osobne warstwy. Zmiana platformy nie wymaga wymiany czujników, jeśli rejestrator lub hub potrafi wysłać dane przez HTTP/JSON.
- Są trzy punkty wpięcia: rejestrator z własną wysyłką HTTP, hub postawiony obok rejestratora, który tego nie potrafi, oraz historia wyeksportowana z dotychczasowego systemu i dosłana tym samym kanałem.
- Kontrakt danych ma siedem pól: urządzenie, kanał, czas pomiaru w UTC, wartość surowa z jednostką, miejsce kalibracji, stan urządzenia, reguła jednoznaczności odczytu i ramka surowa do audytu.
- Pilot równoległy: stary system pracuje, nowa platforma dostaje kopię danych, po 2–4 tygodniach porównujesz szeregi kanał po kanale i dopiero wtedy przełączasz powiadomienia.
- Najczęstsze pułapki to czas lokalny zamiast UTC, pomieszane jednostki, podwójna kalibracja, luki bez stanu NO_DATA, duplikaty i ramki przychodzące poza kolejnością.
Nie musisz wymieniać czujników, żeby zmienić oprogramowanie
System pomiarowy na obiekcie składa się z czterech warstw: czujników, rejestratorów lub hubów, transmisji i oprogramowania. Każda starzeje się w innym tempie. Czujnik strunowy (vibrating wire) zabetonowany w dźwigarze potrafi pracować stabilnie ponad 20 lat. Rejestrator – do pierwszej awarii modemu. Oprogramowanie zmienia się najczęściej: kończy się licencja, producent wycofuje wersję, odchodzi jedyny człowiek, który umiał je obsługiwać, albo potrzebujesz alarmów z procedurą i raportów, których ten program nie ma.
Rejestrator danych to urządzenie, które w ustalonym interwale odpytuje podłączone czujniki, zapisuje odczyty w pamięci i – jeśli ma modem lub inne łącze – przekazuje je dalej. Hub pomiarowy to urządzenie lub oprogramowanie pośredniczące, które zbiera odczyty z jednego lub wielu rejestratorów albo bezpośrednio z czujników i wysyła je do platformy jedną, ujednoliconą drogą. Platforma monitoringu to oprogramowanie online, które przyjmuje dane, przelicza je, przechowuje, porównuje z progami, powiadamia ludzi i wizualizuje wyniki.
Dopóki te warstwy są rozdzielone, możesz wymienić jedną bez ruszania pozostałych. Problem zaczyna się, gdy oprogramowanie jest przywiązane do producenta czujników albo rejestratora – wtedy zmiana „tylko programu” wygląda jak wymiana całego systemu, choć na obiekcie nic się nie zmienia. O tym, jak rozpoznać takie przywiązanie przed zakupem, piszemy w checkliście 30 pytań do dostawcy platformy, a o różnicy podejść między platformą ogólną a polskim SaaS – w porównaniu Vista Data Vision i Inclify.
Jeśli Twój stary system działa, prawdopodobnie masz dwie obawy. Pierwsza: że migracja to projekt na miesiące, w trakcie którego obiekt zostaje bez nadzoru. Druga: że po przełączeniu stracisz historię – odczyt zerowy, tło sezonowe, lata danych, które są jedynym dowodem, jak konstrukcja pracowała. Obie obawy są zasadne i obie da się kontrolować: stary system wyłączasz dopiero po porównaniu obu szeregów kanał po kanale, a historię przenosisz z oryginalnymi znacznikami czasu, zanim cokolwiek przełączysz. O tym, jak to zrobić krok po kroku, jest reszta tego tekstu.
Wyobraź sobie geotechnika, który przejmuje obiekt po poprzednim wykonawcy monitoringu: kilkadziesiąt czujników strunowych, dwa rejestratory z modemami i oprogramowanie producenta na jednym laptopie. Czujniki są dobre, rejestratory działają. Brakuje warstwy, która pokaże dane online, wyśle SMS przy przekroczeniu progu i zostawi ślad, kto na niego zareagował. To sytuacja, w której podłącza się istniejący system do platformy zamiast projektować go od zera. Pełne tło tematu znajdziesz w przewodniku po monitoringu konstrukcji.
O powodzeniu decydują trzy rzeczy: czy rejestrator sam potrafi wysyłać dane przez HTTP albo da się obok niego postawić hub, który to zrobi; czy znasz konfigurację kanałów i współczynniki kalibracji każdego czujnika, a nie same wartości z wykresu; czy masz dostęp do historii odczytów, bo bez niej nowa platforma startuje bez odczytu zerowego i bez tła sezonowego. Dla Ciebie oznacza to jedno: zanim zadzwonisz do dostawcy, zrób inwentaryzację tych trzech rzeczy – to ona, a nie oprogramowanie, wyznacza tempo podłączenia.
Trzy punkty wpięcia
Istniejący system pomiarowy wpina się do platformy online w trzech miejscach. Dwa pierwsze odpowiadają na pytanie „co dzieje się teraz” i różnią się tym, kto fizycznie wysyła dane. Trzecie odpowiada na pytanie „co działo się wcześniej”.
1. Rejestrator z własną wysyłką HTTP/JSON
To najkrótsza droga. Rejestrator w ustalonym interwale (w systemach Inclify domyślnie co 15 minut lub częściej, platforma przyjmie dowolny krok) wysyła żądanie HTTP na adres platformy z dokumentem JSON: kto wysyła, kiedy zmierzono, z jakiego kanału, jaka wartość. Wystarczy wpisać w rejestratorze adres, identyfikator urządzenia i format ramki. Platforma odpowiada, czy ramkę przyjęła; jeśli nie – podaje powód, żeby urządzenie wiedziało, co poprawić.
Czas pomiaru i czas odbioru to dwa różne czasy. Po przerwie w łączności rejestrator dosyła bufor hurtem i platforma musi układać ramki według czasu pomiaru, nie odbioru. Wracamy do tego w pułapkach.
2. Hub obok rejestratora, który HTTP nie potrafi
Większość starszych rejestratorów nie ma wbudowanej wysyłki HTTP/JSON. Mają za to inną, udokumentowaną drogę wyjścia danych, i to ją wykorzystuje hub – niewielki komputer przemysłowy lub bramka postawiona obok. Hub czyta rejestrator jego własnym sposobem, a dalej wysyła już ujednolicony JSON. Z punktu widzenia platformy obie konfiguracje wyglądają tak samo: jeden kontrakt danych zamiast osobnej integracji dla każdego producenta.
Skąd hub bierze dane, zależy od tego, co już stoi na obiekcie. Rejestratory Campbell Scientific obsługuje się oprogramowaniem LoggerNet, które według producenta odpowiada za programowanie, komunikację i pobieranie danych z rejestratorów na komputer – hub czyta to, co LoggerNet pobrał. Sieci Geokon obsługuje program Agent, który zbiera dane, przelicza je na jednostki inżynierskie i eksportuje do kilku formatów plików, ręcznie lub automatycznie. Bramki Worldsensing CMT Edge udostępniają zebrane dane przez FTP/FTPS, Modbus TCP, API i klienta MQTT. W każdym z tych przypadków hub jest tłumaczem między formatem producenta a kontraktem platformy – i dlatego nie ruszasz ani czujników, ani rejestratorów.
3. Historia z dotychczasowego systemu dosłana tym samym kanałem
Bieżące dane bez historii to wykres, który zaczyna się dziś. Do ustawienia sensownych progów potrzebujesz tła – co najmniej jednego pełnego cyklu sezonowego – a do obrony danych w sporze odczytu zerowego i ciągłości od początku pomiarów. Dlatego trzecim punktem wpięcia jest historia wyeksportowana z dotychczasowego systemu.
W praktyce: eksportujesz historię ze starego oprogramowania w takiej formie, jaką ono oferuje, mapujesz pola na ten sam kontrakt danych co dla danych bieżących i wysyłasz do nowej platformy tym samym kanałem HTTP/JSON z oryginalnymi znacznikami czasu. Historia i bieżące pomiary przechodzą wtedy przez ten sam walidator i lądują w tym samym modelu danych – nie ma osobnego „importu”, który mógłby coś zinterpretować inaczej. W Inclify ta droga jest standardem: platforma nie ogranicza wieku dosyłanych odczytów, a odczyt o tym samym urządzeniu, kanale i czasie pomiaru jest nadpisywany, nie dublowany, więc historię można dosłać w partiach i powtórzyć bez szkody. Platforma nie ma za to importu plików CSV/XLSX ani formularza do ręcznego wpisywania serii – jedyna droga do bazy to kanał HTTP/JSON, i dotyczy to także historii.
Skąd wziąć eksport? Zależy od starego systemu. Vista Data Vision udostępnia API do odczytu danych serii (w dokumentacji: maksymalnie 20 identyfikatorów zmiennych na zapytanie i 10 000 wartości na zmienną), oprogramowanie producentów rejestratorów ma zwykle eksport do plików, a w najgorszym razie historia leży w pamięci rejestratora lub w bazie na laptopie. Jeśli stary system nie ma żadnego eksportu, to informacja sama w sobie – właśnie przed tym ostrzega pytanie o eksport w checkliście wyboru platformy. I jeśli masz wybór, eksportuj wartości surowe razem ze współczynnikami kalibracji zamiast samych wartości przeliczonych: surowe da się przeliczyć ponownie po rekalibracji, przeliczonych nie da się „odkalibrować”.
| Punkt wpięcia | Na jakie pytanie odpowiada | Kiedy go potrzebujesz | Na co uważać |
|---|---|---|---|
| Rejestrator → HTTP/JSON | co dzieje się teraz | gdy rejestrator ma wysyłkę HTTP | bufor po przerwie, czas pomiaru vs odbioru, zegar urządzenia |
| Hub obok rejestratora → HTTP/JSON | co dzieje się teraz | gdy rejestrator umie tylko pliki, FTP, Modbus lub własny protokół | hub jako drugi cel, żeby stary system dalej dostawał dane |
| Historia tym samym kanałem | co działo się wcześniej | gdy obiekt ma już pomiary; do progów i dowodu | jednostki i kalibracje historii vs bieżących, strefa czasu eksportu |
Pomiary wykonywane ręcznie – niwelacja reperów, przejazd sondą inklinometryczną, odczyt szczelinomierza – nie mają w Inclify osobnego wejścia. Jeśli chcesz je zestawiać z automatyką, trafiają do platformy tą samą drogą co wszystko inne: jako osobny kanał wysłany przez hub lub skrypt po stronie użytkownika, z czasem pomiaru w UTC.
Co musi mieć kontrakt danych
Kontrakt danych to uzgodniony na piśmie opis tego, co urządzenie wysyła do platformy, w jakiej formie, jak często, oraz co platforma odpowiada. Bez niego integracja jest ustną umową między dwoma inżynierami, która kończy się w dniu, w którym jeden z nich zmienia pracę. Poniższa tabela to minimum, którego wymagaj od każdej strony – od producenta rejestratora, od dostawcy huba i od platformy. Przykłady są ilustracyjne. Dla instalacji vibrating wire tę mapę rozwija szczegółowy poradnik o integracji rejestratora czujników strunowych, w tym o Hz, digits, termistorze i ryzyku podwójnego przeliczenia.
| Pole | Przykład (ilustracyjny) | Po co |
|---|---|---|
| Identyfikator urządzenia | dvc01 albo numer seryjny rejestratora |
Wiąże ramkę z konkretnym urządzeniem; bez tego nie rozróżnisz dwóch rejestratorów na jednym obiekcie ani nie odpowiesz „z czego to przyszło”. |
| Identyfikator kanału / czujnika | CH001 plus w konfiguracji numer seryjny czujnika |
Mapowanie na kanał w platformie; mapowanie powinno przeżyć wymianę rejestratora – numer seryjny czujnika jest trwalszy niż numer portu. |
| Czas pomiaru w UTC | 2026-03-29 01:15:00 (UTC) |
Czas pomiaru (nie odbioru), bez dwuznaczności przy zmianie czasu letniego, porównywalny między urządzeniami i z danymi zewnętrznymi. |
| Wartość surowa i jej znaczenie | 2456.3 z kluczem frequency dla czujnika strunowego |
Pozwala przeliczyć odczyt ponownie po rekalibracji; to warstwa dowodowa. |
| Miejsce kalibracji | „przelicza platforma równaniami projektu” albo „przelicza rejestrator, platforma dostaje µε” | Jedno miejsce prawdy o kalibracji; bez tej decyzji grozi przeliczenie podwójne albo żadne. |
| Stan urządzenia / jakość | measuring, error; brak ramki = NO_DATA po stronie platformy |
Odróżnia „brak danych” od „zero”; luka jest widoczna jako luka, a awaria jako awaria. |
| Jednoznaczność odczytu i ramka surowa | reguła „urządzenie + kanał + czas pomiaru = jeden odczyt” plus oryginalny ładunek w logu | Wykrywanie duplikatów, odtworzenie kolejności, audyt „co dokładnie przyszło”; ramka surowa to to, co pokażesz biegłemu. |
Dla ilustracji – uproszczona struktura ramki numerycznej, jaką przyjmuje Inclify (kontrakt zgodny z SHMmonitor 1.1; część pól urządzenia pominięta, wartości przykładowe):
{
"device": {
"id": "dvc01",
"type": "rejestrator-VW",
"currenttime": "2026-03-29 01:15:20"
},
"data_type": "numeric",
"measurements": [
{
"datetime": "2026-03-29 01:15:00",
"keys": ["frequency", "temperature"],
"channels": [
{ "id": "CH001", "data": [2456.3, 12.6] },
{ "id": "CH002", "data": [2391.8, 12.4] }
]
}
]
}
Trzy rzeczy w tej ramce są istotne dla migracji. datetime to czas pomiaru w UTC, currenttime to zegar urządzenia – platforma porównuje go ze swoim i jeśli różnica przekracza 30 s, odrzuca ramkę z kodem invalid_device_time i odsyła właściwy czas do ustawienia. Lista keys mówi, co znaczą kolejne liczby w data każdego kanału; niezgodna długość obu list kończy się odrzuceniem całej ramki, bo platforma woli odmówić niż zgadywać. Wartości są surowe z rejestratora – przeliczenie na µε, mrad czy kPa wykonują równania projektu w platformie.
Kontrakt ma też drugą stronę: co platforma odpowiada. Minimum to potwierdzenie przyjęcia albo odrzucenie z czytelnym powodem (nieznane urządzenie, zły czas, niezgodne listy), żeby urządzenie wiedziało, czy ma ponowić wysyłkę. W Inclify dochodzi jeszcze jedno: przy zgłoszeniu urządzenia platforma odsyła, od którego momentu brakuje jej danych z danego rodzaju pomiarów, więc rejestrator sam dosyła zaległości po przerwie. Do kontraktu należy też retencja: jak długo platforma przechowuje surowe ramki (w Inclify domyślnie 7 dni, konfigurowalnie; same pomiary nie są automatycznie usuwane) i w jakiej formie oddaje dane, gdy umowa się kończy – to zapis do umowy, o czym szerzej w tekście o danych z monitoringu jako dowodzie w sporze.
Pilot równoległy krok po kroku
Pilot równoległy to okres, w którym dotychczasowy system nadal pracuje i pozostaje źródłem decyzji, a nowa platforma odbiera kopię tych samych danych, żeby można było porównać oba systemy bez ryzyka dla obiektu. To praktyka inżynierska, nie gwarancja wyniku – opisujemy metodę, nie statystykę z wdrożeń. Dla Ciebie najważniejsze jest to, że w żadnym kroku nie wyłączasz tego, co działa.
- Inwentaryzacja. Lista czujników z numerami seryjnymi, przypisanie do portów rejestratora, współczynniki kalibracji i odczyty zerowe, wersje oprogramowania rejestratorów, kto ma hasła i karty SIM. Braki wychodzą właśnie teraz.
- Uzgodnienie kontraktu danych. Tabela z poprzedniej sekcji, pole po polu, plus decyzja, kto wysyła: rejestrator sam czy hub pośredniczący, i kto przelicza: rejestrator czy platforma.
- Wysyłka kopii. Stary system odbiera jak dotąd. Nowa platforma dostaje kopię – jako drugi cel wysyłki w rejestratorze albo przez hub, który czyta rejestrator równolegle. Starego systemu nie wyłączasz.
- Historia i mapowanie. Eksportujesz historię i dosyłasz ją tym samym kanałem z oryginalnymi znacznikami czasu. Każdy kanał dostaje w platformie nazwę, równanie przeliczające (jeśli platforma ma przeliczać) i progi WARNING/ALARM przepisane z planu monitoringu. Z historią progi od razu mają tło sezonowe, a wykres nie zaczyna się od dzisiaj.
- Okres równoległy 2–4 tygodnie. Tyle zwykle trzeba, żeby zobaczyć kilka cykli dobowych, jedną przerwę w łączności i – jeśli się trafi – jedno prawdziwe przekroczenie progu. Obserwujesz kompletność (przy odczycie w domyślnym interwale 15 minut doba to 96 ramek na kanał – arytmetyka, nie wynik), zgodność wartości i zachowanie alarmów.
- Porównanie kanał po kanale. Dla tych samych danych surowych różnica między systemami powinna wynosić zero. Stała różnica wskazuje na jednostki, kalibrację lub odczyt zerowy; przesunięcie w czasie – na strefę czasową; luka w jednym systemie, której nie ma w drugim – na bufor lub transmisję.
- Decyzja i przełączenie. Ustalasz datę, od której SMS-y i e-maile idą z nowej platformy, kto je dostaje i kto potwierdza. Stary system zostawiasz w trybie odczytu do końca uzgodnionej retencji.
Protokół z pilota – co porównano, jakie były różnice, jak je wyjaśniono – dołącz do dokumentacji monitoringu. W sporze to odpowiedź na pytanie, czy zmiana oprogramowania nie zmieniła danych.
Typowe pułapki
Większość problemów przy podłączaniu istniejącego systemu nie dotyczy transmisji. Dotyczy znaczenia danych: kiedy zmierzono, w czym, i czy ktoś już to przeliczył.
Strefy czasowe, czas letni i zegar rejestratora
Rejestrator ustawiony na czas lokalny dwa razy w roku produkuje dane, których nie da się jednoznacznie ułożyć: w ostatnią niedzielę października godzina między 2:00 a 3:00 występuje dwukrotnie, a w ostatnią niedzielę marca nie występuje wcale. Na wykresie pochylenia zestawionym z temperaturą z innego źródła przesunięcie o godzinę wygląda jak opóźnienie reakcji konstrukcji, którego nie ma. Zasada: urządzenie wysyła czas w UTC, platforma wyświetla w strefie użytkownika. Osobna sprawa to zegar rejestratora, który powoli ucieka – po roku bez synchronizacji minuty różnicy rozjeżdżają korelacje między urządzeniami. Platforma, która porównuje zegar urządzenia ze swoim i odsyła poprawny czas, łapie to od pierwszej ramki; bez tego dowiesz się, gdy biegły zapyta, dlaczego dwa wykresy się nie zgadzają.
Jednostki
Pochylenie w mrad, stopniach czy w sinusie kąta; odkształcenie w µε czy w mm/m; ciśnienie w kPa czy w metrach słupa wody; temperatura w °C czy w omach termistora. Ten sam kanał w starym systemie i w nowej platformie może mieć inne jednostki i obie wartości będą „prawidłowe”. Przykład ilustracyjny: 1 mrad to 0,0573°, a przy segmencie 1 m około 1 mm przemieszczenia – jeśli jeden system pokazuje mrad, a drugi stopnie, progi przepisane „jeden do jednego” różnią się około siedemnastokrotnie. Znaczenie każdej liczby ma być częścią kontraktu, nie założeniem.
Kalibracje wpisane w rejestratorze vs w platformie
Czujnik strunowy daje częstotliwość. Odkształcenie powstaje z wzoru: współczynnik kalibracji razy różnica między odczytem bieżącym a zerowym, plus poprawka temperaturowa. To przeliczenie może wykonać rejestrator, hub albo platforma – ale tylko jeden z nich. Jeśli rejestrator wysyła wartość przeliczoną, a platforma ma te same współczynniki w równaniach i przelicza ponownie, dostajesz wartość przeliczoną dwukrotnie: wygląda wiarygodnie i jest bezużyteczna. Ustal na piśmie, gdzie mieszka kalibracja. Najbezpieczniej: rejestrator wysyła surowe, platforma przelicza, a równania i ich zmiany zostają w dzienniku audytu z wartością przed i po.
Luki i NO_DATA
Brak ramki to nie jest wartość zero ani „ostatnia znana wartość”. Platforma powinna po ustalonym czasie bez danych oznaczyć kanał stanem NO_DATA i traktować to jako zdarzenie do obejrzenia: wyczerpana bateria, przerwana antena, zapchany bufor, skończony pakiet w karcie SIM. Jeśli stary system rysował linię ciągłą przez luki, po migracji wykres „pogorszy się” wizualnie – i to dobra wiadomość, bo dopiero teraz widzisz, kiedy obiekt był bez nadzoru. Jak ustawić ten stan obok progów WARNING/ALARM, opisujemy we wpisie o progach ostrzegawczych i alarmowych.
Duplikaty
Urządzenie, które nie dostało potwierdzenia, ponawia wysyłkę – to poprawne zachowanie. Ale jeśli platforma przyjęła ramkę, a potwierdzenie zgubiło się po drodze, ta sama ramka przychodzi drugi raz. Bez reguły jednoznaczności duplikat ląduje w bazie i psuje średnie, liczbę odczytów i SLA kompletności danych. Są dwie drogi: numer sekwencyjny w ramce albo reguła „to samo urządzenie + ten sam kanał + ten sam czas pomiaru = ten sam odczyt”, przy której powtórzona ramka nadpisuje poprzednią zamiast ją dublować. Inclify stosuje tę drugą – dlatego dosłanie historii dwa razy nie robi szkody. Zapytaj dostawcę, którą stosuje jego platforma; odpowiedź „żadnej” to czerwona flaga.
Kolejność ramek
Po przerwie w łączności bufor wysyła zaległe ramki, często w odwrotnej kolejności lub przemieszane z bieżącymi. Platforma układająca dane według czasu odbioru pokaże „skok” wartości, którego nie było; platforma układająca według czasu pomiaru – i trzymająca osobno czas odbioru w logu komunikacji – pokaże uzupełnioną lukę. Zapytaj o to wprost przy pilocie: „co się stanie, gdy rejestrator dośle 6 godzin danych naraz?”.
Jak to wygląda w Inclify
Inclify przyjmuje dane z istniejących hubów i rejestratorów przez HTTP/JSON – to standardowa droga integracji, a nie osobny projekt dla każdego obiektu. Każda wymiana z urządzeniem trafia do logu komunikacji z surową treścią żądania i odpowiedzi: administrator widzi, co przyszło, kiedy i z jakiego urządzenia, i może pobrać dokładnie tę ramkę – przy sporze albo przy szukaniu błędu kalibracji oszczędza to godziny zgadywania (log jest przechowywany przez skonfigurowany okres, domyślnie 7 dni). Czas w bazie jest w UTC, wyświetlany w strefie użytkownika. Gdy kanał przestaje nadawać, po ustawionym oknie dostaje stan NO_DATA obok stanów OK / WARNING / ALARM i jest widoczny jak każde inne zdarzenie. Historię dosyłasz tym samym kanałem co dane bieżące, z oryginalnymi znacznikami czasu – bez limitu wieku, z nadpisywaniem zamiast dublowania.
Typ urządzenia w platformie jest opisowy, więc mieszany park czujników z kilku lat i od kilku producentów nie jest przeszkodą; zespół Inclify od 15 lat dobiera i montuje ponad 40 typów czujników – strunowe, inklinometry (w tym łańcuchowe / in-place), tensometry, MEMS, piezometry, czujniki temperatury, indukcyjne, piezoelektryczne, elektrooporowe – więc rejestratory z Twojego obiektu zwykle nie są pierwszymi, z którymi rozmawia. Jeśli obiekt ma już czujniki i rejestratory, podłączenie trwa kilka dni, a pilot na jednym obiekcie jest jednym z trzech standardowych modeli współpracy. Przegląd modułów platformy znajdziesz na stronie platformy Inclify.
FAQ
Czy muszę wymienić rejestratory, żeby przejść na platformę online?
Nie, jeśli rejestrator potrafi wysyłać dane przez HTTP w formacie JSON albo można obok niego postawić hub, który go odczyta i wyśle dane dalej. Czujniki i rejestratory to warstwa sprzętowa, platforma to warstwa oprogramowania – zmieniasz jedną bez ruszania drugiej. Wymiana sprzętu ma sens tylko wtedy, gdy rejestrator jest niesprawny albo nie da się z niego wydobyć danych w żaden sposób.
Co to jest kontrakt danych i dlaczego czas ma być w UTC?
Kontrakt danych to pisemne uzgodnienie, jakie pola, w jakiej formie i jak często urządzenie wysyła do platformy oraz co platforma odpowiada. Czas pomiaru w UTC usuwa dwuznaczność zmiany czasu letniego, pozwala porównywać dane z różnych urządzeń i ze źródłami zewnętrznymi, a platforma i tak wyświetla go w strefie użytkownika. Czas lokalny w rejestratorze to jedna z najczęstszych przyczyn „niewyjaśnionych” przesunięć na wykresach.
Jak długo trwa podłączenie istniejącego systemu pomiarowego do Inclify?
Jeśli obiekt ma już czujniki i rejestratory, podłączenie do platformy trwa kilka dni: uzgodnienie kontraktu danych, konfiguracja wysyłki z huba lub rejestratora, mapowanie kanałów i progów. Pełne wdrożenie z doborem i montażem czujników to od kilku do kilkunastu tygodni. Pilot równoległy, w którym stary system nadal pracuje, zwykle planuje się na 2–4 tygodnie – to praktyka, nie wymóg.
Jak przenieść historię pomiarów do nowej platformy i czy nic nie stracę?
Wyeksportuj historię z dotychczasowego systemu, najlepiej wartości surowe razem ze współczynnikami kalibracji i odczytem zerowym, zmapuj pola na ten sam kontrakt danych co dla danych bieżących i wyślij tym samym kanałem HTTP/JSON z oryginalnymi znacznikami czasu w UTC. W Inclify nie ma limitu wieku odczytów, a powtórzony odczyt nadpisuje poprzedni, więc historię można dosyłać partiami. Zweryfikuj jednostki i strefę czasu eksportu, bo historia i dane bieżące muszą leżeć na jednej osi. Stary system wyłączasz dopiero po porównaniu obu szeregów.
Czy mogę wgrać plik CSV albo wpisać pomiary ręcznie?
W Inclify nie – platforma nie ma importu plików CSV/XLSX ani formularza do ręcznego wpisywania serii pomiarowych. Jedyna droga do bazy to kanał HTTP/JSON, ten sam dla danych bieżących, historii i pomiarów wykonywanych ręcznie (wysyła je hub lub skrypt po stronie użytkownika jako osobny kanał). To świadome uproszczenie: jeden walidator, jeden model danych, jeden log komunikacji – bez drugiej ścieżki, którą dane mogłyby wejść inaczej zinterpretowane.
Czym jest pilot równoległy i ile powinien trwać?
Pilot równoległy to okres, w którym dotychczasowy system nadal pracuje i pozostaje źródłem decyzji, a nowa platforma odbiera kopię tych samych danych. Po 2–4 tygodniach porównujesz kanał po kanale wartości, kompletność i zachowanie alarmów, wyjaśniasz każdą różnicę (jednostki, kalibracja, strefa czasu, bufor) i dopiero wtedy przełączasz powiadomienia. Protokół z pilota zostaje w dokumentacji jako dowód, że zmiana oprogramowania nie zmieniła danych.
Tekst ma charakter informacyjny i techniczny; nie stanowi porady prawnej – zapisy o retencji, eksporcie i dostępie do danych w umowie z dostawcą monitoringu skonsultuj z prawnikiem.
Źródła i dalsza lektura
- RFC 3339 Date and Time on the Internet: Timestamps (profil ISO 8601 stosowany w internecie) – datatracker.ietf.org/doc/html/rfc3339
- ISO 8601 Date and time: Representations for information interchange – norma zapisu daty i czasu (bez linku)
- Campbell Scientific – LoggerNet (oprogramowanie do programowania, komunikacji i pobierania danych z rejestratorów): campbellsci.com/products/loggernet; KonectGDS (usługa chmurowa, na stronie producenta oznaczona jako „Limited availability”): campbellsci.com/konectgds
- Geokon – Agent, oprogramowanie do konfiguracji, zbierania i eksportu danych z sieci GeoNet i rejestratorów LC2: geokon.com/8800-GNA
- Worldsensing – CMT Edge (eksport danych przez FTP/FTPS, Modbus TCP, API, MQTT): worldsensing.com/product/cmt-edge/
- Vista Data Vision (Bentley) – dokumentacja: źródła danych i import plików (help.vistadatavision.com/data-source/data-source), API do odczytu danych serii (help.vistadatavision.com/web-interface/api; specyfikacja apidocs.vdvcloud.com)
- J. Dunnicliff, Geotechnical Instrumentation for Monitoring Field Performance – rozdziały o rejestracji i zarządzaniu danymi (bez linku)
- Inclify – Monitoring konstrukcji (SHM): kompletny przewodnik
- Inclify – Z czego składa się koszt monitoringu konstrukcji (TCO) – gdzie w koszcie leży rejestrator, hub i transmisja
Co dalej
Jeśli masz obiekt z czujnikami i rejestratorami, a brakuje Ci warstwy, która pokaże dane online, wyśle SMS i zostawi ślad decyzji – zaproponujemy pilot na tym jednym obiekcie: podłączenie istniejącego systemu w kilka dni, dosłanie historii tym samym kanałem, okres równoległy ze starym oprogramowaniem i porównanie kanał po kanale. Niczego nie wymieniasz i niczego nie wyłączasz, dopóki sam nie zobaczysz, że oba szeregi się zgadzają. Najlepszy moment to teraz, póki stary system jeszcze działa i da się z niego wyeksportować historię – po awarii laptopa z bazą albo po wygaśnięciu licencji będzie trudniej. Przygotuj listę czujników i rejestratorów, resztę ustalimy razem. Umów rozmowę o pilocie – odpowiadamy w 24 godziny.