Dane z monitoringu konstrukcji bronią się w sporze wtedy, gdy da się odtworzyć całą drogę od czujnika do wykresu: kto i kiedy wykonał odczyt zerowy, jaki czujnik z jaką kalibracją mierzył, kiedy przyszła każda ramka danych, jak wyglądała wartość surowa przed przeliczeniem oraz kto i kiedy zareagował na alarm. Sam wykres, choćby ładny, tego nie udowodni.
W skrócie
- Spór nie toczy się o to, czy masz wykres, tylko o to, skąd wykres się wziął i czy można mu wierzyć.
- Wiarygodny zapis ma osiem cech: stan wyjściowy, identyfikację i kalibrację czujnika, spójny czas, surowe dane obok przeliczonych, ślad zmian, log komunikacji, ślad decyzji ludzi oraz eksport i retencję.
- Log komunikacji z surowymi ramkami odpowiada na pytanie „co, kiedy i z jakiego urządzenia przyszło” – arkusz kalkulacyjny tego nie potrafi. W wielu platformach surowe ramki żyją jednak krócej niż pomiary; jeśli mają być dowodem, okres ich przechowywania ustal w umowie.
- Potwierdzenie alarmu (kto, kiedy) i wyciszenie z terminem to zapis tego, co ludzie zrobili z informacją, a nie tylko tego, co pokazały czujniki.
- Retencję, eksport i dostęp stron ustala się w umowie przed montażem, nie po pierwszym piśmie pełnomocnika. Trzech rzeczy nie zrobisz wstecz: odczytu zerowego, logu i śladu decyzji.
Spór zaczyna się od pytania „skąd pan to wie?”
Jeśli byłeś kiedyś na sali rozpraw albo na spotkaniu z rzeczoznawcą drugiej strony, znasz to. Przedstawiasz wykres pochylenia ściany kamienicy obok wykopu. Linia jest płaska. I padają pytania: skąd pan wie, że ten czujnik w ogóle działał, kiedy był kalibrowany i dlaczego w tabeli jest luka między wtorkiem a czwartkiem? W tym momencie wykres przestaje być dowodem, a staje się twierdzeniem.
Pewnie właśnie tego się boisz: że po piśmie od pełnomocnika sąsiada zostaniesz z wykresem, którego nikt nie uzna, i z tabelą, której nie potrafisz obronić. Ten lęk jest zdrowy, bo da się go zamienić w listę kontrolną. Dowodem jest to, co potrafisz pokazać za wykresem – a to można przygotować z wyprzedzeniem.
Dane z monitoringu jako dowód to zapis pomiarów wraz z informacjami, które pozwalają osobie trzeciej odtworzyć, jak zapis powstał, i ocenić, czy można mu wierzyć. Łańcuch dowodowy danych pomiarowych to udokumentowana droga każdej liczby od czujnika, przez transmisję i przetwarzanie, po archiwum, z którego ktoś ją po latach czyta. Podstawy SHM znajdziesz w kompletnym przewodniku po monitoringu konstrukcji.
Odpowiedzialność za szkodę wyrządzoną sąsiedniej nieruchomości opiera się najczęściej na przepisach Kodeksu cywilnego o czynach niedozwolonych: art. 415 (zasada winy) oraz art. 435 § 1 (zasada ryzyka prowadzącego przedsiębiorstwo wprawiane w ruch siłami przyrody). Sądy zaliczają do takich przedsiębiorstw firmy budowlane, w tym generalnych wykonawców – tak orzekł Sąd Najwyższy w wyroku z 17.03.2022 r. (II CSKP 482/22) w sprawie o uszkodzenie budynku sąsiedniego przez roboty na sąsiedniej działce. Art. 147 KC zakazuje z kolei właścicielowi prowadzenia robót ziemnych w sposób grożący sąsiednim nieruchomościom utratą oparcia, a do obowiązków kierownika budowy (art. 22 Prawa budowlanego) należy m.in. prowadzenie dokumentacji budowy oraz wstrzymanie robót w razie stwierdzenia możliwości powstania zagrożenia.
Ciężar udowodnienia faktu spoczywa na tym, kto z niego wywodzi skutki prawne (art. 6 KC), ale przy zasadzie ryzyka zwalnia tylko siła wyższa albo wyłączna wina poszkodowanego lub osoby trzeciej – w praktyce to wykonawca będzie chciał wykazać, że szkoda nie ma związku z jego robotami. Bez danych nie ma czym. Szerzej o tym piszemy we wpisie o monitoringu budynków sąsiednich podczas budowy. To samo dotyczy właściciela hali, który po zdarzeniu musi pokazać, że między kontrolami okresowymi z art. 62 Prawa budowlanego reagował na sygnały.
Jak biegły czyta takie dane
Biegły powołany przez sąd w sprawie wymagającej wiadomości specjalnych (art. 278 KPC) albo rzeczoznawca jednej ze stron nie zaczyna od wykresu. Zaczyna od pytań o metodę. Pierwsze: dokumentacja stanu wyjściowego i schemat rozmieszczenia czujników. Drugie: świadectwa kalibracji i sposób przeliczania surowego sygnału na jednostki fizyczne. Trzecie: ciągłość zapisu i wyjaśnienie każdej luki. Dopiero czwarte: to, co pokazują wartości.
Jeśli na którymś z trzech pierwszych pytań odpowiedź brzmi „nie wiem, to robił podwykonawca”, wartość dowodowa reszty spada, choćby liczby były korzystne. Biegły zapyta też, czy progi z dnia zdarzenia były takie same jak dziś i czy czas systemu zgadza się z dziennikiem budowy. Co z tego dla Ciebie: przygotuj odpowiedzi na te cztery pytania, zanim ktoś je zada. Reszta tego tekstu jest o tym, jak.
8 cech wiarygodnego zapisu pomiarowego
Poniższa tabela to lista kontrolna wypracowana na sporach, nie wzięta z normy. Trzecia kolumna jest najważniejsza: to pytania do dostawcy monitoringu przed podpisaniem umowy, nie po.
| # | Cecha zapisu | Co to znaczy w praktyce | Jak to zweryfikować u dostawcy |
|---|---|---|---|
| 1 | Odczyt zerowy i inwentaryzacja stanu wyjściowego | Stan obiektu i czujników przed robotami: wartości początkowe kanałów, data, osoba, zdjęcia istniejących rys | Poproś o zanonimizowany protokół odczytu zerowego; zapytaj, czy wartość zerową da się później „przesunąć” bez śladu |
| 2 | Kalibracja i identyfikacja czujnika | Każdy kanał ma numer seryjny czujnika, typ, współczynniki kalibracyjne, datę kalibracji i lokalizację na obiekcie | Zapytaj, gdzie widać numer seryjny i współczynniki kanału i czy po wymianie czujnika historia rozdziela stary i nowy egzemplarz |
| 3 | Znaczniki czasu spójne, z jawną strefą czasową | Każdy odczyt ma czas pomiaru z jednoznaczną strefą (najlepiej UTC w bazie, strefa lokalna tylko w prezentacji); zegary urządzeń są pilnowane; system nie gubi godziny przy zmianie czasu | Poproś o dane z nocy zmiany czasu letniego na zimowy – jeśli ta sama godzina występuje dwa razy bez rozróżnienia, masz odpowiedź; zapytaj, co się dzieje z ramką z rozjechanym zegarem |
| 4 | Surowe dane obok przeliczonych | System przechowuje wartość z czujnika (np. częstotliwość struny) i wartość przeliczoną (µε, mrad, mm) oraz użyte współczynniki | Zapytaj, czy pobierzesz wartość surową dla dowolnego odczytu i czy po zmianie kalibracji źródło zostaje nienaruszone |
| 5 | Niezmienność zapisu lub pełny ślad zmian | Danych historycznych nie da się edytować po cichu; każda korekta (odczyt oznaczony jako błędny, zmiana progu, zmiana współczynnika) ma autora, czas i wartość przed i po | Zapytaj wprost: kto może zmienić lub usunąć odczyt historyczny, czy pomiary da się wpisać ręcznie i czy po zmianie progu zostaje widoczny ślad |
| 6 | Log komunikacji z urządzeń | Zapis każdej transmisji: z jakiego urządzenia, kiedy, co zawierała ramka, czy została przyjęta – a więc i zapis tego, że danych nie było | Poproś o podgląd logu na prezentacji; zapytaj, ile dni jest przechowywany – zwykle krócej niż pomiary – i czy da się go pobrać |
| 7 | Ślad decyzji ludzi – kto potwierdził alarm i kiedy | Dla każdego alarmu: kiedy powstał, w jakim stanie, kto go przejął i kiedy, czy i do kiedy wyciszono | Zapytaj, czy historia alarmów jest widoczna z kontami osób i czasami akcji, a nie samą adnotacją „alarm zamknięty” |
| 8 | Eksport w otwartym formacie i retencja | Dane, log i historia alarmów do pobrania w formacie czytelnym bez oprogramowania dostawcy; określony okres przechowywania i los danych po umowie | Poproś o przykładowy eksport; zapytaj, co dzieje się z danymi po wygaśnięciu subskrypcji – to zapis do umowy |
Jeśli dostawca odpowiada bez zastanowienia i pokazuje to na ekranie, jesteś w dobrym miejscu. Jeśli odpowiedź brzmi „to można dorobić”, zapisz ją w umowie jako zobowiązanie z terminem. Jeśli brzmi „tego nie mamy, robimy to inaczej” – to też dobra odpowiedź, bo wiesz, co sam musisz uzupełnić (np. cyklicznym eksportem do własnego archiwum). Szerszy zestaw pytań – o ingest, alarmy, role, hosting i koszt całkowity – znajdziesz we wpisie jak wybrać platformę monitoringu konstrukcji: checklista 30 pytań.
Surowe ramki i log komunikacji – dlaczego wykres z Excela to za mało
Arkusz kalkulacyjny nie jest zły. Problem leży w tym, czego arkusz nie niesie: kontekstu powstania liczby.
Surowa ramka, wartość przeliczona, kalibracja
Surowa ramka to dokładna treść komunikatu, który urządzenie pomiarowe (rejestrator, hub, czujnik z własną transmisją) wysłało do platformy – z identyfikatorem urządzenia, czasem i wartościami w postaci, w jakiej wyszły z przetwornika. Wartość przeliczona to ta sama informacja po zastosowaniu wzoru kalibracyjnego i korekt (temperatura, odczyt zerowy). Między jedną a drugą jest matematyka, która może być poprawna albo nie – i to ona jest najczęściej przedmiotem sporu ekspertów.
Przykład ilustracyjny: czujnik strunowy (vibrating wire) zwraca częstotliwość drgań struny; odkształcenie liczy się z różnicy kwadratów częstotliwości bieżącej i zerowej pomnożonej przez stałą czujnika z karty producenta, a potem koryguje o temperaturę. Jeśli masz tylko kolumnę „odkształcenie [µε]”, a rzeczoznawca zapyta o stałą i o to, czy kompensacja temperatury działała od początku, odpowiesz tylko wtedy, gdy platforma trzyma częstotliwość i temperaturę obok wyniku. Stąd wymaganie nr 4 z tabeli: korekta kalibracji po roku nie powinna nadpisać historii, tylko zostawić źródło i ślad, kto i kiedy ją wprowadził.
Log komunikacji: co, kiedy, z jakiego urządzenia
Log komunikacji to chronologiczny zapis transmisji między urządzeniami w terenie a platformą: czas odbioru, identyfikator urządzenia, treść ramki, wynik przyjęcia. Pełni trzy funkcje dowodowe.
Po pierwsze, potwierdza pochodzenie. Wartość w tabeli mogła zostać wpisana ręcznie; ramka w logu przyszła z konkretnego urządzenia o konkretnej godzinie, w postaci, której nikt nie formatował.
Po drugie, rozdziela czas pomiaru od czasu odbioru. Urządzenia buforują dane przy braku zasięgu i wysyłają je później. Bez dwóch czasów nie odróżnisz „czujnik zmierzył to o 14:15” od „dane dotarły o 14:15”, a w sporze o to, czy wstrzymałeś roboty w porę, to ma znaczenie. Dobra platforma pilnuje przy tym zegara urządzenia względem własnego i nie przyjmuje ramek z rozjechanym czasem – dzięki temu „14:15” znaczy to samo na każdym czujniku.
Po trzecie, dokumentuje brak. Luka w danych zawsze zostanie wykorzystana przez drugą stronę („akurat wtedy nie było pomiarów”). Log pokazuje, czy urządzenie milczało (brak ramek), czy wysyłało dane, których platforma nie przyjęła (ramki odrzucone – i dlaczego), czy przyszły później z bufora. To trzy różne historie. Stan NO_DATA, czyli sygnalizowany przez platformę brak odczytów z kanału w oczekiwanym oknie czasowym, jest informacją, a nie samym brakiem informacji: jeśli został oznaczony, powiadomiony i potwierdzony, masz zapis, że o luce wiedziałeś i zareagowałeś.
Jedna rzecz, o której dostawcy mówią niechętnie: surowe ramki zajmują dużo miejsca, więc platformy przechowują je zwykle krócej niż pomiary – dni lub tygodnie, nie lata. Pomiary przeliczone zostają, log znika. Jeśli log ma być dowodem, masz dwie drogi: zapisać w umowie dłuższą retencję dla konkretnego projektu albo cyklicznie pobierać log do własnego archiwum. Co z tego dla Ciebie: zanim podpiszesz umowę, obejrzyj log na ekranie i zapytaj, ile dni żyje.
Alarm, potwierdzenie, wyciszenie: ślad decyzji ludzi
Czujniki nie podejmują decyzji. Decyzje podejmują ludzie, a spór prawie zawsze dotyczy decyzji: czy wiedziałeś, kiedy wiedziałeś i co zrobiłeś. Dlatego historia alarmów jest tak samo ważna jak historia pomiarów. Na ślad decyzji składają się trzy elementy.
Potwierdzenie alarmu to zarejestrowana w platformie czynność, w której konkretna osoba przyjmuje zgłoszenie i bierze za nie odpowiedzialność. Zapis „alarm WARNING na kanale X powstał o 06:42, SMS wysłano do osób upoważnionych, o 06:51 przejął kierownik robót” mówi więcej niż cała tabela wartości. Brak potwierdzenia przez wiele godzin też jest zapisem – niewygodnym, ale uczciwym.
Wyciszenie z terminem to świadoma decyzja, że alarm nie będzie powtarzał powiadomień przez określony czas, z datą, po której wraca, i z powodem odnotowanym w platformie lub w dzienniku budowy (np. „planowane prace przy czujniku”). Wyciszenie bez terminu i bez powodu jest w sporze najgorszym możliwym wpisem: wygląda jak wyłączenie dzwonka, bo przeszkadzał.
Eskalacja to z góry ustalona ścieżka: kto dostaje informację, jeśli pierwsza osoba nie potwierdzi w określonym czasie, i kto decyduje o wstrzymaniu robót. Nie każda platforma prowadzi ją automatycznie. Jeśli Twoja nie prowadzi, ścieżkę zapisujesz w procedurze (drugi numer w gronie powiadamianych, telefon od dyżurnego), a dowodem pozostaje to samo: czas powstania alarmu, czas potwierdzenia i zapis tego, co zrobiono potem.
Przykład ilustracyjny – jeden alarm, trzy wersje dokumentacji:
- Wersja A: „Dnia 12 marca zanotowano przekroczenie progu ostrzegawczego. Kierownik budowy został poinformowany telefonicznie.” Zapis w dzienniku budowy, z pamięci, bez godziny.
- Wersja B: wydruk z arkusza, w którym wiersz z 12 marca jest podświetlony na żółto.
- Wersja C: historia alarmu w platformie: czas powstania, progi z tego dnia, czas i konto osoby potwierdzającej, wyciszenie do konkretnej godziny, powrót do stanu OK – plus wpis w dzienniku budowy z godziną: „wstrzymano wykop w sekcji 3, wezwano geotechnika”.
Wersja C nie gwarantuje wygranej. Pokazuje jednak, że organizacja miała procedurę i ją wykonała, a o to w sporach o należytą staranność chodzi najczęściej. Jak zbudować progi i procedurę, które zostawiają taki ślad, opisujemy we wpisie o progach ostrzegawczych i alarmowych.
Retencja i eksport – co zapisać w umowie
Najczęstszy błąd nie jest techniczny. Pytanie „gdzie będą te dane za trzy lata?” pada po raz pierwszy, gdy przychodzi wezwanie. Tymczasem roszczenia o naprawienie szkody z czynu niedozwolonego przedawniają się co do zasady z upływem 3 lat od dnia, w którym poszkodowany dowiedział się o szkodzie i sprawcy, nie później niż 10 lat od zdarzenia, a przy szkodzie ze zbrodni lub występku – 20 lat (art. 442¹ KC). Budowa kończy się po miesiącach. Dane muszą przeżyć kontrakt.
Poniżej klauzule do rozważenia w umowie z wykonawcą monitoringu albo dostawcą platformy – lista inżyniera do rozmowy z prawnikiem, który nada jej brzmienie.
- Okres retencji liczony od zakończenia monitoringu, osobno dla: pomiarów surowych i przeliczonych, logu surowych ramek (zwykle najkrótszy – wpisz liczbę miesięcy albo obowiązek cyklicznego eksportu), historii alarmów oraz zdarzeń dynamicznych (drgania), które zajmują najwięcej miejsca.
- Zakres eksportu: pomiary surowe i przeliczone, współczynniki kalibracyjne i równania przeliczeniowe, konfiguracja progów z historią zmian, historia alarmów z akcjami użytkowników, log komunikacji – w formacie otwartym, czytelnym bez oprogramowania dostawcy; termin dostarczenia na żądanie i ewentualny koszt.
- Dostęp stron: kto ma konto i z jakimi uprawnieniami (inwestor, wykonawca, inspektor nadzoru, ewentualnie właściciel sąsiedniego obiektu w trybie „tylko odczyt”) i czy platforma pozwala ograniczyć taki dostęp do jednego projektu.
- Los danych po wygaśnięciu umowy: przekazanie kompletnego archiwum, termin, potwierdzenie odbioru, moment, od którego dostawca może dane usunąć; kto jest właścicielem danych (zwykle zamawiający).
- Dokumentacja stanu wyjściowego jako załącznik: protokół odczytu zerowego, schemat rozmieszczenia czujników, świadectwa kalibracji, zdjęcia; zobowiązanie do zachowania śladu każdej późniejszej zmiany progów i współczynników.
- Procedura reagowania jako załącznik: progi, lista powiadamianych, czasy potwierdzenia, ścieżka eskalacji (w platformie lub poza nią), uprawnienia do wyciszania, odpowiedzialność za reakcję na NO_DATA.
- Dane osobowe: jeśli w platformie są numery telefonów i adresy e-mail odbiorców alarmów, dostawca hostujący dane działa jako podmiot przetwarzający i potrzebna jest umowa powierzenia zgodna z art. 28 RODO.
Nie każda klauzula jest potrzebna zawsze. Obok zabytkowej kamienicy przydadzą się wszystkie. Na monitoringu dźwigarów własnej hali – co najmniej retencja, eksport i ślad decyzji; o tym, co trzymać na wypadek kontroli lub incydentu, piszemy we wpisie o przeglądach okresowych z art. 62 a monitoringu ciągłym. Co z tego dla Ciebie: wydrukuj tę listę i zabierz na spotkanie z dostawcą – pół godziny rozmowy teraz to tygodnie mniej w sporze.
Trzy rzeczy, których nie zrobisz wstecz
Koszt zaniechania w tym temacie nie polega na tym, że zapłacisz więcej. Polega na tym, że pewnych rzeczy po prostu nie będzie dało się zrobić, gdy już będą potrzebne.
Pierwsza: odczyt zerowy. Stan obiektu sprzed robót istnieje tylko przed robotami. Rysy zinwentaryzowane po pierwszym piśmie sąsiada są już „Twoje”, bo nie udowodnisz, że były wcześniej.
Druga: log surowych ramek. Jeśli platforma przechowuje go domyślnie przez kilka dni, to w dniu, w którym spór się zaczyna, logu z dnia zdarzenia zwykle już nie ma. Dłuższą retencję albo cykliczny eksport ustalasz przed montażem, nie po.
Trzecia: ślad decyzji. Potwierdzenia alarmu nie dopiszesz po fakcie, a dziennik budowy „z pamięci, bez godziny” broni się słabo. Procedura – kto potwierdza, w jakim czasie, kto dzwoni dalej – musi istnieć w dniu, w którym alarm powstaje.
Dlatego moment na tę rozmowę jest jeden: przed podpisaniem umowy na monitoring, a najpóźniej przed pierwszym wykopem. Wszystko, co ustalisz później, będzie już tylko ograniczaniem strat.
Scenariusz hipotetyczny: roszczenie sąsiada a dziennik monitoringu
Scenariusz jest hipotetyczny: nie opisuje żadnego rzeczywistego obiektu, wdrożenia ani sporu, a wartości i terminy są przykładowe.
Wyobraź sobie wykop z dwiema kondygnacjami podziemnymi, kilka metrów od przedwojennej kamienicy. Przed robotami wykonano inwentaryzację stanu wyjściowego: opis i zdjęcia istniejących rys, protokół odczytu zerowego dla czujników pochylenia na ścianie szczytowej kamienicy i na obudowie wykopu, szczelinomierzy na trzech rysach i czujnika drgań w piwnicy. Odczyty domyślnie co 15 min lub częściej, progi ustalone przez projektanta zabezpieczenia wykopu. Cztery miesiące później właściciel kamienicy zgłasza nowe pęknięcie w klatce schodowej i żąda odszkodowania, wskazując roboty ziemne jako przyczynę.
Co pokazuje dziennik monitoringu w tym scenariuszu:
- Dokumentację stanu wyjściowego z datą sprzed wykopu, w której rysa w klatce schodowej nie występuje (albo występuje – wtedy spór wygląda inaczej, ale wiesz to pierwszy).
- Ciągłość pomiarów pochylenia ściany: zmiany w rytmie dobowym skorelowane z temperaturą (wykres wieloosiowy), bez trwałego trendu; jedna przerwa w transmisji oznaczona jako NO_DATA, potwierdzona przez kierownika w ciągu godziny, z wpisem o wymianie zasilania; dane z bufora dosłane po przywróceniu łączności z oryginalnymi znacznikami czasu – i ramki w logu komunikacji, bo umowa przewidywała jego retencję na czas budowy.
- Jeden alarm ostrzegawczy na szczelinomierzu w tygodniu głębienia do poziomu drugiej kondygnacji: czas powstania, potwierdzenie, wyciszenie na 48 godzin, wpis w dzienniku budowy o wstrzymaniu prac w sekcji i wezwaniu projektanta, powrót do stanu OK po dwóch dobach.
- Zdarzenia drganiowe w dniach pracy walca: zapisane przebiegi, wartości szczytowe poniżej granic przyjętych na podstawie PN-B-02170 dla tej klasy budynku (więcej we wpisie o monitoringu drgań budynków przy budowie) – do wglądu dla biegłego.
Czego dziennik monitoringu nie pokazuje i czego nie należy z niego wyciągać:
- Nie dowodzi, że pęknięcie nie powstało. Dowodzi, że w punktach pomiarowych, w zakresie mierzonych wielkości, nie zarejestrowano zmian przekraczających progi. Jeśli rysa jest daleko od czujników, biegły słusznie zapyta, dlaczego tam nie mierzono – i tu wraca znaczenie projektu rozmieszczenia czujników.
- Nie zastępuje oceny przyczyn przez rzeczoznawcę budowlanego. Monitoring dostarcza faktów o zachowaniu obiektu w czasie; interpretacja przyczyn (wiek budynku, instalacje, przebudowy, warunki gruntowe) należy do eksperta.
- Nie wypowiada się o okresach, których nie obejmuje. Jeśli monitoring ruszył dwa tygodnie po starcie robót, te dwa tygodnie są bez zapisu i trzeba to uczciwie powiedzieć.
Dziennik nie „wygrywa sprawy”. Przenosi rozmowę z poziomu „pan twierdzi, a ja twierdzę” na poziom „oto zapis, proszę go zakwestionować”. To duża różnica w kosztach, czasie i stresie, nawet przy ugodzie.
Jak to wygląda w Inclify
Platforma Inclify zapisuje surowe ramki żądanie/odpowiedź z urządzeń wraz z metadanymi: co, kiedy i z jakiego urządzenia przyszło; administrator może je obejrzeć i pobrać dokładną treść ramki w panelu. Dotyczy to zarówno czujników zainstalowanych przez zespół Inclify, jak i rejestratorów klienta podłączonych przez HTTP/JSON. Uczciwie: log surowych ramek jest przechowywany domyślnie przez 7 dni (okres jest konfigurowalny) – jeśli ramki mają mieć wartość dowodową w Twoim projekcie, dłuższą retencję albo cykliczne pobieranie trzeba zapisać w umowie. Pomiary – wartości surowe z rejestratora i wartości przeliczone równaniami projektu – są przechowywane w bazie szeregów czasowych w UTC bez automatycznego usuwania (starsze dane są kompresowane, nie kasowane).
Znacznik czasu pomiaru nadaje urządzenie w UTC; platforma nie przyjmuje ramek, których zegar rozjechał się z serwerem o więcej niż 30 s, i odsyła urządzeniu poprawny czas, a zaległości z bufora urządzenie dosyła z oryginalnymi znacznikami. Pomiary wchodzą wyłącznie kanałem urządzeń – nie ma formularza ręcznego wpisu ani importu plików. Zmiany konfiguracji (równań, w których siedzą współczynniki kalibracji i kompensacji, progów, urządzeń, użytkowników) trafiają do dziennika audytu z wartością przed i po; platforma nie ma funkcji przywracania stanu sprzed zmiany.
Każdy kanał ma stany OK / WARNING / ALARM / NO_DATA. Potwierdzenie alarmu zapisuje, kto i kiedy je wykonał, wyciszenie zawsze ma termin (od minuty do roku), a przejścia między stanami są zapisywane w historii alarmu. Powiadomienia SMS i e-mail trafiają do użytkowników według ich preferencji; automatycznej eskalacji do kolejnych osób nie ma – ścieżkę zapisujesz w procedurze. Uprawnienia mają trzy poziomy (superadministrator, administrator klienta, użytkownik tylko do odczytu), a dane każdego klienta są odizolowane; nie ma ról per projekt, więc dostęp dla osoby spoza Twojego zespołu omówimy indywidualnie.
Dane z tabel eksportujesz do CSV, wykres zapisujesz jako obraz, sygnały dynamiczne do XLSX (PDF nie ma), a raport SLA danych pokazuje kompletność, luki i świeżość zapisu. Więcej na stronie monitoringu w platformie. Zakres eksportu i okres retencji zapisujemy w umowie – zapytaj o nie wprost, jak każdego dostawcę według tabeli powyżej.
FAQ
Czy dane z monitoringu konstrukcji są dowodem w sądzie?
Mogą być. Sąd cywilny ocenia dowody swobodnie, a zapisy elektroniczne i wydruki z systemów pomiarowych przeprowadza się jako dowody z innych dokumentów lub innymi środkami dowodowymi (art. 308–309 KPC); ich interpretacją zajmuje się zwykle biegły (art. 278 KPC). O wartości dowodowej decyduje możliwość odtworzenia, jak zapis powstał: kalibracja, czas, surowe dane, ciągłość, ślad zmian.
Co to jest odczyt zerowy i dlaczego jest tak ważny?
Odczyt zerowy to udokumentowany stan czujników i obiektu przed rozpoczęciem robót lub monitoringu: wartości początkowe każdego kanału, data, osoba, zdjęcia istniejących uszkodzeń. Wszystkie późniejsze zmiany liczone są względem niego. Bez odczytu zerowego nie wykażesz, że rysa istniała wcześniej ani że pochylenie nie wzrosło – każda zmiana staje się „Twoja”. Po starcie robót nie da się go już wykonać.
Czy wykres z Excela wystarczy jako dokumentacja monitoringu?
Arkusz pokazuje wartości, ale nie niesie informacji o ich pochodzeniu: z jakiego urządzenia przyszły, kiedy, w jakiej postaci surowej, jakim wzorem je przeliczono i czy ktoś je potem edytował. Jako ilustracja do opinii jest w porządku; jako samodzielny dowód jest łatwy do zakwestionowania. Potrzebny jest dostęp do surowych danych, historii zmian i logu komunikacji.
Jak długo przechowywać dane z monitoringu po zakończeniu budowy?
Nie ma jednej wartości. Punktem odniesienia są terminy przedawnienia roszczeń z czynów niedozwolonych (art. 442¹ KC): 3 lata od dowiedzenia się o szkodzie i sprawcy, nie dłużej niż 10 lat od zdarzenia, a przy przestępstwie 20 lat – oraz wymagania kontraktu i ubezpieczyciela. Okres retencji zapisz w umowie z dostawcą, liczony od zakończenia monitoringu, razem z obowiązkiem przekazania archiwum.
Czy przerwa w transmisji przekreśla wartość dowodową zapisu?
Nie, jeśli przerwa jest udokumentowana: platforma oznaczyła stan NO_DATA, ktoś to potwierdził, znana jest przyczyna i czas powrotu łączności, a dane z bufora dosłano z oryginalnymi znacznikami czasu. Wartość dowodową przekreśla raczej luka, o której nikt nie wiedział, albo luka „wyczyszczona” w arkuszu, bo psuła wykres.
Kto powinien mieć dostęp do danych z monitoringu w czasie budowy?
Co najmniej inwestor, wykonawca i inspektor nadzoru – z rolami odpowiadającymi odpowiedzialności (kto może zmieniać progi i wyciszać alarmy, kto tylko czyta). Rozważ dostęp „tylko odczyt” dla właściciela sąsiedniego obiektu; często zapobiega to sporowi, zanim powstanie – ustal wcześniej, czy platforma potrafi ograniczyć taki dostęp do jednego projektu. Zakres dostępu i własność danych zapisz w umowie.
Zastrzeżenie: ten tekst ma charakter informacyjny i techniczny, nie stanowi porady prawnej; stan prawny na 22.08.2026. Zapisy umowne i ocenę sytuacji prawnej skonsultuj z prawnikiem.
Źródła i dalsza lektura
- Ustawa z dnia 23 kwietnia 1964 r. – Kodeks cywilny (art. 6, 147, 415, 435, 442¹) – isap.sejm.gov.pl
- Ustawa z dnia 17 listopada 1964 r. – Kodeks postępowania cywilnego (art. 278, 308, 309) – isap.sejm.gov.pl
- Ustawa z dnia 7 lipca 1994 r. – Prawo budowlane (art. 22, 61, 62) – isap.sejm.gov.pl
- Wyrok Sądu Najwyższego z 17 marca 2022 r., II CSKP 482/22 (przedsiębiorstwo budowlane jako wprawiane w ruch siłami przyrody; uszkodzenie budynku sąsiedniego) – sn.pl
- Rozporządzenie (UE) 2016/679 (RODO), art. 28 – eur-lex.europa.eu
- PN-B-02170:2016-12 Ocena szkodliwości drgań przekazywanych przez podłoże na budynki – sklep.pkn.pl
- Dokumentacja techniczna producentów czujników strunowych (wzory przeliczeniowe) – geokon.com
Co dalej
Jeśli przed Tobą wykop obok cudzego budynku albo podpisanie umowy na monitoring, przejrzyj tabelę ośmiu cech z dostawcą teraz – przed pierwszą łyżką koparki, bo odczytu zerowego i logu nie zrobisz wstecz. Jeśli chcesz zobaczyć log komunikacji z surowymi ramkami, dziennik audytu, historię alarmów z potwierdzeniami i eksport na projekcie podobnym do Twojego – umów rozmowę. Odpowiadamy w ciągu 24 godzin, a jeśli masz już czujniki i rejestratory, podłączenie do platformy na jednym obiekcie pilotażowym trwa kilka dni.