ArchiSense и СФИУЗ: новые подходы к техническому обследованию зданий

Метрология, калибровка, неопределённость

Бюджет неопределённости

Обеспечение достоверности данных – это основа мониторинга. Каждое измерение должно сопровождаться оценкой погрешности (неопределенности). Согласно международным рекомендациям (например, ISO GUM: Guide to the Expression of Uncertainty in Measurement), следует строить бюджет неопределенности, то есть выявлять все значимые источники ошибок и их вклады. Например, при измерении прогиба балки с помощью LVDT: источники – это калибровочная погрешность LVDT (скажем, ±0.2%), нестабильность температуры (коэффициент 0.01 мм/°C при изменении на ±5° C), цифровой квантование (±0.01 мм), шум (СКО 0.005 мм). Объединяя эти компоненты статистически (коррелированные алгебраически, некоррелированные корнем суммы квадратов), получают совокупную стандартную неопределенность, которую затем масштабируют нужным коэффициентом доверия. В отчете по мониторингу эти оценки должны быть явно указаны. Важный принцип трассируемость измерений к эталону – это значит, что каждое значение можно, в принципе, проследить до государственных или международных эталонов через непрерывную цепочку калибровок. Например, тензодатчик откалиброван усилием 1000 кН, которое мерилось образцовым датчиком силы, который, в свою очередь, поверен на национальном эталоне силы (первичном рычажном прессовом механизме и пр.). Трассируемость обеспечивает сопоставимость данных разных систем мониторинга и юридическую силу данных (особенно важно для арбитража, данные часто используются в судебных разбирательствах аварий). Для обеспечения трассируемости все калибровки должны выполняться по методикам, отраженным в нормативных документах (ГОСТ, ISO) и подтверждаться сертификатами калибровки. Периодически система мониторинга должна проходить метрологический контроль: например, раз в год поверка или калибровка ключевых каналов. При этом часть оборудования может метрологочески не аттестовываться (например, уникальные системы, которые невозможно целиком поверить), тогда отдельные компоненты (датчики) поверяются, а система в целом проверяется по сходству результатов с другими измерениями (валидация).

Межкалибровка, полевые проверки, валидация

Помимо лабораторной калибровки, практикуется взаимная калибровка датчиков на месте установки. Если рядом установлены два разных типа датчиков, измеряющих одну величину, их показания за период сравниваются, особенно выявляется возможная систематическая разница (более надежный датчик служит эталоном для поправки второго). Например, виброускорение может измеряться одновременно MEMS и пьезоакселерометром, а по результатам построения регрессии можно откорректировать чувствительность MEMS. Полевые проверки проводятся, чтобы убедиться в исправности системы без демонтажа. Для датчиков перемещений и деформаций часто применяют имитацию нагрузки: к конструкции прикладывают небольшое известное возмущение и смотрят, отразилось ли оно на сенсорах. Например, на перекрытии можно ненадолго поставить измеренный груз 500 кг, тензодатчики должны показать увеличение деформации, а наклономеры прогиб определенной величины, совпадающей с расчетом. Если расхождение велико, возможна рассоединение датчика или сбой. Также используются диагностические модули, некоторые контроллеры умеют прозванивать цепи датчиков, измерять их сопротивление в паузах (выявляя обрыв, замыкание, потерю сигнала). Межкалибровка может означать и то, что два датчика меняются местами или один и тот же калибровочный сигнал подается на несколько каналов, например, имитатор термопары подключается ко всем термовходам, и проверяется, что все они показывают в пределах допуска. Для систем, работающих годами, полезны валидационные стенды, например, для датчиков вибрации: портативный вибростенд (шэйкер) прикладывается прямо к датчику на конструкции, генерируя стандартный сигнал (скажем, 1 м/s² на 10 Гц), и проверяется отклик всей цепи вплоть до записи в базе данных. Если отклонение> 5% – рекомендуется ремонт или рекалибровка. Валидация результатов также включает сопоставление с ожидаемым поведением: например, если в мороз здание должно сжиматься, а датчики показывают удлинение – вероятно, ошибка в знаке или сбой. Таким образом, поддерживается качество данных: непрерывный контроль корректности, автоматические и ручные калибровки, резервирование датчиков позволяют доверять полученным трендам и аномалиям.

Надежность датчиков и обслуживания

Многолетняя эксплуатация множества сенсоров ставит вопрос об их надежности. Здесь применяются методы анализа отказов и планирования обслуживания, аналогичные промышленным. Например, выполняется FMEA (Failure Mode and Effects Analysis) анализ возможных отказов компонентов и влияния на систему. Для каждого типа датчика перечисляют возможные отказовые ситуации, такие как обрыв линии, дрейф чувствительности, шум, заклинивание механической части и т.п., и предполагаемые эффекты (например, обрыв кабеля тензодатчика приведет к нулевым показаниям, которые система распознает как ошибку по отсутствию вариаций). На основе FMEA разрабатываются меры: установка дублирующих датчиков в критических местах, периодический прогон диагностического сигнала, сигнализация при выходе параметров за правдоподобные пределы. Показатели надежности, такие как MTBF (Mean Time Between Failures) среднее время наработки до отказа используются для планирования замены. Например, если по паспорту MTBF датчика давления 100 тысяч часов (~11 лет), то через 8—10 лет его стоит заменить превентивно, не дожидаясь, пока он выйдет из строя. MTTR (Mean Time To Repair) – среднее время восстановления, тоже важно, система должна быть спроектирована так, чтобы датчик можно было заменить или починить в разумный срок (например, закладные кабели должны быть доступны, должны быть резервные каналы). Если MTTR слишком велик (скажем, чтобы заменить датчик внутри фундамента надо останавливать эксплуатацию на месяц), то надо ставить несколько датчиков заранее. Постепенная деградация сенсоров (коррозия корпуса, выцветание маркировки, старение электроники) учитывается через регламент обслуживания. В него включают регулярные осмотры (раз в год визуально проверить состояние, герметичность вводов), чистку (например, очистка наклономеров от грязи, чтобы они правильно показывали), поверку на месте. Некоторые датчики требуют периодической замены расходников: например, электрохимические сенсоры газа имеют срок службы 5 лет, потом электролит истощается и нужно заменить сенсорный модуль. Всё это включается в план ТО (технического обслуживания) системы мониторинга. Экономически обоснованно многие замены делать по состоянию, а не по жесткому графику, здесь опять выручает сам мониторинг, например, рост разброса показаний нулевого датчика может служить индикатором деградации (увеличился шум и вероятно, сенсор на пределе). Значит, пора заменить, даже если срок по паспорту не вышел. Информация о надежности собирается в процессе эксплуатации: в базе данных хранится история отказов и ремонтов, по которой можно вычислить фактические показатели надежности и скорректировать стратегии. Например, если оказалось, что влагомеры на фасаде массово выходят из строя через 3 года (вода проникает в корпус) либо нужно улучшить герметизацию, либо планово менять каждые 2.5 года до отказа. В конечном счете, работоспособность всей системы мониторинга определяется надежностью самых слабых звеньев, обычно это полевые сенсоры и линии связи. Поэтому при проектировании стремятся минимизировать их количество в сочетании с достаточным охватом. А при эксплуатации выстроить процесс обслуживания, когда замена вышедшего из строя датчика не затягивается: хранится необходимый запас ЗИП, заключены договоры с сервисными организациями, а критичные датчики задублированы либо мгновенно переключаются на резервный (что аналогично принципу fail-operational в автоматике система остается работоспособной даже при отказе). Хорошо спроектированная система SHM за счёт самоконтроля и продуманной сервисной стратегии способна функционировать десятилетиями, предоставляя надежные данные.

Часть IV. ArchiSense: платформа умного мониторинга

Системная архитектура ArchiSense

Рисунок 7. Рабочий стол системы ArchiSense

Узлы сбора данных и edge-контроллеры

ArchiSense – это условное название интегрированной платформы мониторинга здания, включающей аппаратные и программные компоненты. Архитектура обычно многоуровневая. Нижний уровень сами сенсоры и первичные преобразователи, распределенные по объекту. Они могут подключаться к локальным узлам сбора данных (ДСУ – датчики, сбор, управление). Эти узлы представляют собой небольшие контроллеры на краю (edge), размещенные, например, по техническим этажам или зонам объекта. Каждый такой контроллер собирает данные с группы датчиков поблизости (по проводной связи или беспроводной) и выполняет предварительную обработку: оцифровку, фильтрацию, агрегирование. Кроме того, на контроллеры возложены функции локальных триггеров событий, они могут анализировать поступающие значения и при наступлении заданных условий (превышение порога, появление резкого всплеска, пропадание сигнала) немедленно реагировать, сохранить фрагмент с высокой частотой, отправить тревожное сообщение на верхний уровень. Это позволяет разгрузить сеть и центральный сервер, не передавать гигантские потоки постоянно, а только полезную информацию. Локальные вычисления близки к концепции фог- и edge-computing, когда часть интеллектуальной обработки выдвигается ближе к сенсорам. Как отмечено в исследованиях по безопасности, edge-контроллерный слой собирает данные с датчиков, выполняет первичную фильтрацию и пороговый анализ, а также при необходимости передает управляющие команды обратно на сенсоры (например, изменить частоту сбора). В связке с ними может работать контроллер управления – это устройство, получающее команды от центральной системы и способное замыкать локальные исполнительные механизмы (включить сигнализацию, перекрыть клапан и т.д.).

Средний уровень – это шлюзы связи и сервер сбора данных. Edge-узлы соединяются с верхним уровнем по различным каналам, зачастую через шлюз это устройство, конвертирующее протоколы. Например, беспроводные датчики связываются с ближайшим шлюзом, который уже через Ethernet или сотовую сеть подключен к центральному серверу. Центральный сервер (или кластер) выполняет роль хранилища и процессора данных. В ArchiSense центральный компонент – это программное обеспечение, реализующее сбор временных рядов, хранение, обработку, визуализацию и обмен с внешними системами. Сервер может быть физически расположен на объекте (например, промышленный компьютер в диспетчерской) или в дата-центре (облачное решение).

Для повышения надежности архитектура ArchiSense предусматривает резервирование, а именно ключевые узлы дублированы, а связь построена с автономными сценариями. Мы считаем, что данный вариант является максимально безопасным и надежным. Например, если центральный сервер потеряет связь с некоторыми контроллерами, они могут автономно работать и записывать данные локально (на SD-карту) в течение некоторого времени, а затем переслать по восстановлении связи. Если отказывает отдельный сенсор, система отмечает канал как неисправный, но на основе соседних датчиков и моделей может иногда экстраполировать данные, пока ведутся ремонтные работы.

Беспроводная и проводная связь

Передача данных от сотен сенсоров непростая задача, особенно если требуется реальное время. ArchiSense может использовать комбинацию протоколов. Для локальных сетей датчиков часто применяются легковесные IoT-протоколы: MQTT (publish/subscribe модель над TCP/IP), CoAP (Constrained Application Protocol, аналог HTTP over UDP для упрощенных узлов), или AMQP (Advanced Message Queuing Protocol) для гарантированной доставки в более требовательных сценариях. Например, edge-контроллер может выступать MQTT-клиентом, публикующим топики с данными сенсоров (например building1 / floor2 / strain / beam12 = 150 µ) на MQTT-брокер на сервере. MQTT хорош своей малой нагрузкой и возможностью работать при нестабильной связи, контроллер буферизует сообщения и отсылает при подключении. CoAP может использоваться, когда нужно прямое обращение «запрос-ответ» к датчику (например, запросить разово его состояние), он эффективен по UDP и подходит для сетей с минимальными ресурсами. AMQP более тяжеловесен, но обеспечивает очереди, транзакционность его могут использовать подсистемы ArchiSense для интеграции с корпоративными шинами данных, где нужна надежность доставки.

Хранилище временных рядов и каталог данных

Серверная часть ArchiSense отвечает за приём и долговременное хранение данных. Поскольку данных много, и они имеют временную природу, используют специализированные СУБД временных рядов (Time Series Database), например, InfluxDB, TimescaleDB, либо распределённые хранилища (Apache Kafka + Hadoop и пр.). В них данные хранятся как точки во времени: метка + значения + теги (идентификаторы датчика, объекта). Такой подход оптимизирован по скорости записи и агрегирования по времени. Для каждого канала (датчика) создается временной ряд, многие СУБД позволяют автоматически вычислять агрегаты (например, среднее за час) и хранить их для ускорения аналитики. Кроме сырых данных, база содержит события (events), пометки о наступлении какого-то факта (сработал порог, произведена калибровка, датчик вышел из строя). Важным компонентом является каталог сенсоров – это метаданные обо всех датчиках и каналах системы. Каждый датчик описывается: тип, модель, серийный номер, расположение (привязка к элементу конструкции или координатам), единицы измерения, диапазон, дата последней калибровки, статус (в строю или отключён). Это можно рассматривать как базу данных устройств (CMDB), связанная с BIM-моделью. Система ArchiSense предоставляет интерфейс для доступа к этим данным: так, аналитический модуль может запросить список всех температурных датчиков на 5 этаже или все датчики типа «тензодатчик» с шагом измерения 1 минута, и затем получить по ним данные.

Отдельно продумывается схема версионирования и аудита данных. Поскольку данные мониторинга могут использоваться в официальных отчётах и даже суде, важно хранить исходные неизменённые данные (raw) и все произведённые над ними преобразования. Если производится корректировка, то исходные значения не удаляются, а создаётся новая версия, а старая помечается как не использовать. В современных СУБД реализуют концепцию версионированных таблиц, позволяющих запросить данные на любую дату прошлого с учётом того, что было тогда известно. Это важно для трассируемости изменений, можно показать, что неугодные данные не потеряли, а учли с объяснением причины. Аудит подразумевает ведение журнала всех действий пользователей, кто и когда изменил настройки датчика, откорректировал данные или подтверждал тревогу. ArchiSense, как платформа, регистрирует эти события. Журнал и версии помогают соблюсти требования стандартов.

В системе также реализуется резервное копирование: периодически вся база (или её критические части) копируются на резервный сервер. При отключении основного, резервный может принимать данные (возможно, с некоторой деградацией функций реального времени). Реализация хранением и доступом сильно зависит от масштаба системы: у небольшого здания – это может быть просто SQLite база на одном ПК, у моста – это распределённое облачное хранилище с веб-интерфейсом. Однако принципы единны, оптимизация под временные ряды, хранение отношений «датчик-элемент конструкции», версии и аудит.

Аналитика и ИИ в ArchiSense

Контроль качества данных

Перед использованием собранных данных их необходимо подвергнуть контролю качества. Во-первых, выявляются пропуски данных (missing data) это периоды, когда от датчика не было показаний. Причины от сбоя связи до отказа сенсора. ArchiSense автоматически маркирует такие интервалы, и, если это критичный канал, может выдавать оповещение при пропуске больше заданного интервала. Пример: наклономер должен давать данные раз в минуту, если нет данных 10 минут это сигнал тревоги о возможной неисправности. Во-вторых, отслеживаются выбросы (outliers) это разовые невероятные скачки измерений, обычно из-за помех или ошибок. Например, если тензодатчик обычно показывал ~100 με, а в одном отсчете дал 5000 με и вернулся назад – скорее всего, это выброс. Используют несколько подходов: простые пороговые (отсекание значений вне физических границ), статистические, например, по методу межквартильного размаха или по 3σ отклонению от скользящего среднего. Также применяют правило монотонности: некоторые данные не могут резко меняться (осадка фундамента не может прыгнуть вверх, только плавно вниз). Обнаруженные выбросы помечаются флагом, исключаются из аналитических расчетов и могут замещаться оценками, например, линейной интерполяцией соседних корректных точек. Далее, контролируется дрейф нуля и чувствительности (bias, drift). Для этого иногда в систему включают «нулевые каналы» – это датчики, которые не должны испытывать воздействий. Если они начинают показывать не ноль, значит, сдвинулась нулевая линия. По ним и по статистике остальных можно судить о необходимости ретрокалибровки. Например, если все термометры вдруг показывают +3° C, а должно быть ~0° C (снег, мороз), вероятен систематический дрейф, поправка. Однако чаще дрейф учитывают при плановом обслуживании. Синхронизация каналов: ArchiSense следит, чтобы данные, помеченные одним моментом времени, действительно относятся к одному физическому времени. При объединении разнородных источников (геодезия, датчики, метеоданные) могут быть рассогласования часов. Платформа либо приводит все к единому временному стандарту (UTC с поправкой часового пояса), либо к меткам от главного сервера. Если замечено постоянное рассогласование (например, один сенсор всегда на 2 секунды позже), вносятся поправки автоматически при записи. Наконец, фильтрация шума: для некоторых каналов сырой сигнал очень шумный, и хранят или анализируют сглаженный. Используются цифровые фильтры – это скользящее среднее, медианный фильтр (для выбросов), более сложные калмановские фильтры. При этом оригинал все равно сохраняется, чтобы не потерять информацию. В рамках DQA система формирует отчеты о качестве, процент пропусков, число выбросов за сутки, текущий дрейф. Если показатели выходят за нормы (например, больше 5% выбросов) выдается предупреждение операторам, поскольку это может говорить о начале отказа датчика или о внешнем воздействии, например, заливание водой вызывает шум. Таким образом, прежде чем данные пойдут в глубокий анализ, они очищены и приведены к сопоставимому виду, что предотвращает ложные выводы. Согласно опыту, до 5—10% сырого объема данных SHM могут быть помечены как некорректные и требуют внимания или коррекции.

Алгоритмы обнаружения аномалий

Главная задача мониторинга – это обнаружение аномальных ситуаций (повреждение, перегрузка) на основе сенсорных данных. Для этого в ArchiSense реализован многоуровневый подход к поиску аномалий. Простейший уровень, пороговые правила: для каждого датчика или индикатора заданы безопасные пределы. Например, прогиб балки не должен превышать l/250, или виброскорость 5 мм/с по ГОСТ. Если значение переходит порог, фиксируется событие. Преимущество – это простота и ясность (меньше ложных срабатываний при правильно выбранных порогах). Недостаток – это не ловит постепенные деградации, если они остаются ниже порога, и не учитывает корреляции между параметрами. Поэтому вводят более умные статистические методы. Один из них модели временных рядов (ARIMA, ETS) для прогноза поведения и сравнения с фактом. Например, ARIMA-модель обучается на прошлых данных температуры и деформации и прогнозирует, какой должна быть деформация сейчас. Если фактическая намного отличается от предсказанной – это аномалия. Такие методы хорошо работают для стационарных или сезонных процессов (температура, осадка с годовым циклом), по ним строят прогноз с доверительным интервалом, и если реальный тренд выходит за доверительный интервал – сигнал. Применение сезонно-трендовых декомпозиций (например, STL) позволяет отделить долговременный тренд и выявить аномальный скачок поверх тренда. Также, ARIMA с внешними регрессорами (ARIMAX) используется для детектирования аномалий через анализ остатков, так, в работах показано, что ARIMAX-модель, учитывающая сезонные факторы, может эффективно распознавать аномальные отклонения по статистическим тестам на остатки. Следующий уровень, машинное обучение для outlier detection. ArchiSense может применять обучение без учителя на исторических «нормальных» данных: методы Local Outlier Factor (LOF), Isolation Forest и их аналоги. LOF оценивает локальную плотность данных вокруг точки и сравнивает с плотностью соседей: если точка сильно разреженно расположена – это выброс. Isolation Forest строит случайные решающие деревья, пытаясь отделить точки; точки, которые изолируются за мало шагов (легко изолируемые) – считаются аномалиями. Эти методы способны обнаруживать сложные взаимосвязанные аномалии, например, невзаимосвязанный с температурой рост деформации: когда обычно деформация ростом 1 мм соответствует +10° C, а тут 3 мм при том же изменении температуры – алгоритм ловит как аномальный мульти-вариативный вектор. Преимущество – это не нужно задавать конкретный порог, система сама «понимает» норму по данным. Недостаток – это возможны ложные срабатывания при смене режима работы здания (например, включили новое оборудование, изменился характер вибраций, для алгоритма это может выглядеть как аномалия, хотя всё нормально). Поэтому по возможности модели периодически переобучают, либо используют адаптивные пороги. Еще более продвинутый уровень, глубинные нейросети, обученные выделять особенности (feature extraction) и распознавать паттерны. Популярны автоэнкодеры – это нейросеть, сжимающая входной многомерный сигнал в латентное пространство и потом восстанавливающая. Если подать на обученный автоэнкодер нормальный сигнал, он восстановит хорошо, а аномальный плохо (большая ошибка). Это служит признаком аномалии. Также применяются LSTM сети для временных рядов, которые прямо прогнозируют следующий шаг и сигнализируют о всплеске ошибки предсказания (как вариант – LSTM-автоэнкодер, объединяющий оба подхода). Например, LSTM, обученная на нормальных вибросигналах моста под обычным трафиком, заметит резкий выброс в момент аварии (пролом настила), потому что это событие никогда не видели раньше, и модель выдаст большую ошибку. Глубокие модели могут улавливать сложные взаимосвязи и нелинейности, однако их внедрение требует больших объемов обучающих данных и осторожности с интерпретацией (так называемый «black box»). В практике SHM часто комбинируются подходы: сначала простые пороги (для явно аварийных ситуаций), затем статистика (для трендов), и параллельно ML, дающие ранние предупреждения. Например, ArchiSense может выдавать предупреждения уровней: информационное (сработал ML-алгоритм, нужна проверка инженером), предупреждение (превышен статистический прогноз, высокая вероятность проблемы) и авария (достигнут явный порог, необходимо немедленное действие). Такой многоступенчатый подход снижает риск пропустить проблему и уменьшает число ложных тревог, что важно для доверия к системе пользователями.

Идентификация мод по сети датчиков

ArchiSense может отслеживать изменение модальных характеристик во времени автоматически. Имея сеть датчиков (например, 12 акселерометров по этажам здания), система периодически (раз в сутки или непрерывно в скользящем окне) выполняет операционную модальную идентификацию (OMA) и извлекает основные собственные частоты и формы. Затем эти моды сопоставляются (tracked) с базовыми через критерий MAC. Например, изначально у здания первая частота 0.5 Гц, вторая 1.2 Гц. Спустя год OMA показывает пики на 0.48 и 1.17 Гц с немного другим демпфированием. Система через максимальный MAC определяет, что это те же моды, и строит тренд: частота №1 снизилась на 4%, частота №2 на 2.5%, демпфирование №1 выросло с 2% до 3%. Сдвиг частот часто указывает на размягчение конструкции, либо появление трещин, либо снижение жесткости грунта основания, либо добавление массы (например, надстройка оборудования). Рост демпфирования может свидетельствовать о зарождении микроповреждений (они рассеивают энергию) или об изменении контактных условий узлов. В ArchiSense реализованы алгоритмы кластеризации мод по времени (методы модального трекинга), например, каждый новый набор мод сравнивается с несколькими предыдущими, чтобы отстроиться от ложных мод (спуриев) и стабилизировать результаты. В итоге получается временной ряд модальных параметров. Его уже можно анализировать на предмет тенденций (трендов) и аномалий. Например, если частота начала систематически снижаться быстрее, чем можно объяснить сезонным эффектом (частоты часто слегка падают зимой, когда материал охлаждается, и поднимаются летом, но это периодично), система выдаст предупреждение. Данная функциональность, одно из проявлений создания «цифрового двойника» динамики конструкции, который обновляется по данным. Реализовать её достаточно сложно, но существующие пакеты (например, ArTeMIS или собственные модули на Python) могут быть интегрированы. Так, измеренные сигналы акселерометров экспортируются в модуль OMA, который возвращает набор частот, форм (вектор из значений по датчикам) и демпфирований. Далее скрипт ArchiSense сравнивает формы через MAC и относительные изменения частот. Если MAC <0.8 с предыдущими – возможно, появилась новая мода или данные слишком зашумлены. Тогда сигнализируется неопределенность. Если MAC высок, и частота изменилась более чем на допустимы Δf, фиксируется Modal Anomaly Event. Преимущество метода мод чувствительность к распределенным изменениям: даже если ни один датчик по отдельности не показал яркой аномалии, все вместе, влияя на моды, могут выявить проблему. Например, равномерное снижение жесткости нескольких колонн на 5% трудно заметить по локальным датчикам, а первая форма прогиба уже просядет заметно. В литературе показано, что отслеживание модальных частот – мощный индикатор повреждений, но также зависит от окружающих условий (влажности, температуры). Поэтому ArchiSense дополнительно делает корреляционный анализ с факторами окружающей среды: т.е. пытается учесть, что, скажем, при +30° C бетон менее жесткий, и частота падает сама собой. Такие зависимости можно либо вычесть (модель регрессии), либо по крайней мере отделять как сезонные колебания. При построении тревожных критериев используют нормированные показатели: например, модальный коэффициент повреждения